Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)M
Posts
3
Comments
121
Joined
12 mo. ago

  • I have no issues with the article. I have issue with the post which calls KYC laws evil. That’s what sensational (though maybe a different word would fit better).

    PS. Oh, I see. You came from the recent cross-post at Australia. Observe that poster there used an objective title giving straight numbers. OP here used a completely different title.

  • And if you don’t collect that data, criminals and scammers will use free access to banking system to fund their scams and crimes. Letting people drive cars will obviously lead to accidents and deaths, that’s not a reason to outright ban people from driving. Just like risk of data branches is not a reason to outright call KYC evil.

  • I certainly don’t call that evil. There are many laws that exist solely to help law enforcement, they aren’t automatically evil.

  • You’re just confirming what I’ve written: Problems are companies who nickel-and-dime on security. And yes, we need punishments for data breaches. This has nothing to do with KYC laws being evil. It’s just OP being a money launderer.

  • Criminals also have great time with knives, or rope, or crowbars. Not reason to say all those things are evil. Problems are companies who nickel-and-dime on security.

  • Web Development @programming.dev

    Styling outbound links, yea or nay?

  • Nothing evil in preventing funding of criminals. GTFO with this sensational subject line.

    PS. To clarify, because there is some confusion, I’m referring to OP using post title starting with: ‘If you had any doubts that Know-Your-Customer laws were evil,’

  • Writing software carries a non-zero risk. If compiling was part of building the package rather than manually committed to the repository, things would work. And that would make the design have no essential binary blob.

  • It is a better approach, it just may be more complex. Only people developing or packaging the library need to compile the message definitions. It’s not a big burden to require than they have protoc installed. The end user will only need to depend on the created package.

  • Also there is strictyaml that validates against schemas. Don’t touch the builtin yaml module.

    Thanks. I’ll include that in an update.

    protobuf needs to be compiled. This introduces possibility of coder error. Just forgetting to compile and commit protobuf files after a change. This affected the electrum btc and ltc (light) wallets.

    Yes, that’s certainly a downside. It also demonstrates one should not commit such generated files. A better approach is to commit the source files (in this instance message definition) and have a compilation step included in the program’s build/install recipe.

    strictyaml

  • Joblib has the same drawback as pickle. From the documentation:

    joblib.dump() and joblib.load() are based on the Python pickle serialization model, which means that arbitrary Python code can be executed when loading a serialized object with joblib.load().

    joblib.load() should therefore never be used to load objects from an untrusted source or otherwise you will introduce a security vulnerability in your program.

  • If you’re serialising trusted data, you can define schema for it and use Protocol Buffers which will not only by safer but also faster. Pretending that you need to be able to serialise arbitrary data hurts everyone.

  • Python @programming.dev

    Stop using pickle already. Seriously, stop it!

    mina86.com /2026/pickle-should-be-a-war-crime/
  • No bytecode compilation by default. pip compiles .py files to .pyc during installation. uv skips this step, shaving time off every install. You can opt in if you want it.

    So it makes installation faster by making runtime slower.

    Ignoring requires-python upper bounds. When a package says it requires python<4.0, uv ignores the upper bound and only checks the lower. This reduces resolver backtracking dramatically since upper bounds are almost always wrong. Packages declare python<4.0 because they haven’t tested on Python 4, not because they’ll actually break. The constraint is defensive, not predictive.

    So it makes installation faster by installing untested code.

    Sounds like a non-starter to me.

  • Interesting. Some years ago I’ve relied on SSHFS to have a decent speed when operating on remote files. I wonder if this might have been a solution as well.

  • Because those recommendations are written for new users. A new user will be better served by a distribution which puts user-friendliness at its forefront. If you’re not a newbie you probably don’t need recommendations because you already know what distributions are available out there.

  • The data is misleading. Obviously there’ll be more requests for domains with low TTL because those domains aren’t cached. The overall conclusion and points of the blog post may be correct, but the presented data doesn’t say anything.

  • I find it funny that just couple weeks ago I’ve written about the format. What’s especially interesting about this format is that it can losslessly transcode JPEG into JPEG XL while offering around 20% file size reduction. It can be used to reduce size of one’s image gallery without any loss of quality.

  • You can just copy the file and set XAUTHORITY as necessary. Just make sure only the desired user can read it.

  • No, do not do that. This gives access to the display to anyone who can connect to it. The proper way is to give the user access to file whose path is in $XAUTHORITY.

  • Capital letters in user names. 🤮

    Debian has torbrowser-launcher you might wanna take a look at that.

    As for the issue, this could be because the user lacks credentials to connect to the display.

  • Linux @lemmy.ml

    Is Ctrl+D really like Enter?

    mina86.com /2025/is-ctrl-d-really-like-enter/