FreeBSD includes a kernel, drivers, and userland utilities under one project. If your complaint is that systemd is "bloated", it doesn't make any sense why you would want to switch to a system that's even more "bloated".
It looks like it won't be so simple for Steam. I just found out a couple of days ago that Steam only uses CEF to render the main content, and it actually looks like it's using GTK2 to render the window.
Maybe the Nix package manager / NixOS is what you're looking for? I think it takes the best features from both worlds.
Every package installed with Nix is isolated into content-addressable* directories, so for example, my install of Firefox is located at /nix/store/c7pmng2x05dkigpbhnjs8fdzd8kk31np-firefox-85.0.2/bin/firefox. This is pretty inconvenient to use directly, so Nix generates a profile that symlinks all your packages into one place (eg. /run/current/system/sw, ~/.nix-profile), and then environment variables like PATH can just include <PROFILE_DIR>/bin.
With this approach, I can have multiple versions of the same package installed simultaneously, without them conflicting with each other. Like in a traditional distro, any dependencies that are shared between packages aren't duplicated, but if a package needs to explicitly depend on a different version, it can.
Also, because Nix is designed as a functional package manager for building packages from source (even though it has a binary cache), you can trace back exactly what sources were used to build your package and its dependencies, all the way back to the bootstrap binaries used to build any self-hosting compilers (gcc, rust, openjdk, ...)
* Most packages use a hash that's generated from the inputs used to build it, rather than the output that's generated.
> However, the crux of my argument is that it’s easy enough to emulate this construction in other languages.
It's also easy enough to emulate all control flow statements with goto. Tagged unions are valuable because they help communicate restraints. Not only to other developers, but also to the compiler.
X only allows setting a DPI per "display", but not per screen (multiple monitor setups where you can drag windows between screens use one X "display"). So you have to resort to these hacks.
It could, depending on your use case, but normally all packages from nixpkgs share the same libcurl, so when libcurl is updated, all packages that depend on it will also be updated.
The old libcurl will still exist on your system to allow you to rollback to previous states of your system, but you can always run nix-collect-garbage if you want to free up disk space.
This is similar to the situation in Arch Linux where pacman keeps all downloaded packages, and you have to run paccache if you want to free space.
It sounds like your definition of stable applies to a very limited set of programming languages. The only thing I can think of that would fit that definition is C.
Have you seen how many new features have been added to C++20? (which is probably the closest language to Rust) Not to mention any of the dynamically typed languages.
I prefer using dap-mode. It has a much nicer interface that's consistent across multiple debuggers. I use it for C, C++, Rust (Native Debug + gdb) and Python (debugpy).
No, but you can always encode this augmented information in types to make it explicit, and possibly help the compiler make optimizations. Using a weaker type when you can use a stronger type is just as bad as removing type information.
Just don't construct SQL queries by directly concatenating user input. It's easy to mess up or use the wrong escape function, so always use prepared statements anywhere you want to pass user defined data.
You can usually grep or even use static code analysis to help find where your existing code is using "tainted" data to construct a query.
Also, if you use an ORM, you'll generally be working at a high enough level where SQL injection is impossible (unless there's a bug or design flaw in the ORM); since you won't be directly dealing with text queries.
There absolutely is a survival bias. I should have phrased my comment better because my point wasn't that all trans people get stronger by what they go through.
I was trying to say that the comment isn't transphobic at all, and if people think stuff like this is the reason why trans people kill themselves then they're probably blind to the actual transphobia that happens in the world.
Also, I strongly believe that we shouldn't be restricting language out of fear of being offensive, because then people become too afraid to talk about important issues.
I'm trans and I've struggled so much with gender dysphoria, but this doesn't bother me at all.
I don't get why there's this stereotype of trans people being so fragile. All the trans people I know are stronger because of what they've been through.
I don't think you deserve to be down voted for this. You bring up a valid concern. Although, I don't agree that this project should be outright dismissed either.
So many times, I've run into the issue where I've wanted to chain a set of commands with a concise syntax (specifically in Python) without having to shell out to bash.
What I really like about this library is that it gives you the concise composability of bash, without having to deal with its pitfalls (eg. variable escaping, lack of Windows support, clunky interface for anything that's not a command invocation...).
Using a DSL will always come with certain tradeoffs, and it won't be the best solution for every use case, but I think this library fills a certain need very well.
While reading this I thought it sounded familiar, and realized this is exactly what happens in the Grey's anatomy episode "Love Turns You Upside Down". Interesting that it was based on a real life situation, it seems like a lot of episodes are.