License: Proprietary (MIT)

Are you feeling alright, AlternativeTo?

Define ‘sold’ because everyone has its own understanding of what that term means. What are you worried about?

My first recommendation is to just use graphical environment. My second is to try fbterm.

Terminal and console are two different things. Console is what you get if your computer boots up in text mode. Terminal is what you start inside graphical environment (X or Wayland). Which one are you having issues with? What does echo $TERM output? If it’s the former, how are you watching videos exactly? O_o If it’s the latter, setfont won’t do anything; you need to look at configuration of your terminal emulator or try a different one.

I would go with Debian package but for me the primary consideration is how much I care about having the latest version of given software. Often I don’t really care that much. Although it needs to be said that I’m on Debian testing.

With gl/Vulcan and some other libraries that’s pretty challenging to do if your goal is to become more portable not less portable.

I still don’t see how this is different from Windows. Games on Windows ship with DirectX. Ship whatever graphics libraries you need if you’re worried about ABI breaking.

Shipping also sort of different libraries with your proprietary game could also be a licensing issue.

No, it’s not. Any library you’re dynamically linking to that’s present in a Linux distribution, you can distribute yourself.

Linux ABI compatibility is a fuck.

I’m never convinced by this argument. If game developers have problems with ABI they can do what they’re already doing on Windows: ship their game with all the dependencies. Casual gamer’s Windows system might have more versions of Microsoft Visual C++ Redistributable than they have games installed. This had been my experience.

• My rule of thumb is at least 2GB of RAM per compilation jobs. Even if you have more cores, the jobs may start swapping or crashing slowing down the build in the end. This may of course depends on the size of the project.
• Disable LTO during development. Is it only when you’re ready to release your binary.
• If your editor doesn’t keep up, disable fancy IDE features such as Rust analyser. Run checks periodically the same way you run test.

Who do I message to replace the pie chart for oldest Rust version used with a cumulative distribution graph? Even legend is a mess on that one.

That’s also my thinking, but it does add some visual clutter plus wouldn’t the counterargument be that people who really care can use their own user styles or extensions, or look at the status bar?

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.

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

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.