You can just wipe the luks header as a nice middle ground.
Luks uses an anti-forensics algorithm that requires the entire volume key being available to unlock the disk at all (it combines the blocks of the key with some diffuse algorithm and xors stuff together to form the actual master key), so in theory you can just clear one sector of the volume key and the whole thing should be unrecoverable.
What I mean is that if even one block of the key is missing you can't guess the rest easily.
I don't think you understand what these people view as "freedom".
This isn't a simple difference in political beliefs, they believe that certain groups of people are basically subhuman and don't deserve basic human rights.
How can you support that?
It seems there are a lot of far-right extremest trolls/psychopaths on hacker news. What a disgrace.
It also supports running in freestanding setups without an OS, and quite a lot of the language's features still work.
I was extremely surprised by how much functionality is packed into "core", and runs without an OS when using freestanding rust. Even stuff that requires an allocator can run provided you provide your own heap!
A cool example of this was implementing fmt::Write for a memory mapped uart console thing. Then implementing a kprintln! macro that supports all of the formatting machinery that you are use to. This worked without even a heap available.
It's the same argument anti-vaxers love to make. "Well you can still get covid after getting the shot", which is something I read and heard quite a lot. That doesn't make the thing useless.
A stripped down cold build will literally take 90 seconds without caching on modern hardware.
The overwhelming majority of stuff that is being built is drivers, and most of them probably aren't needed for any specific user, so you can disable quite a lot of stuff.
Fwiw a full build of the fedora kernel config takes around 5-10m for my 12core ryzen 3900x, and it's definitely not the fastest CPU around.
Its literally trivially objectively measurable, this isn't something that is based in opinion.
You can throw it up on your own website and simply grep the logs if you don't trust it, or look for the analysis reports from people who have done exactly that.
Like the other commenter said, why would linux.org deploy and leave deployed a technology that did nothing? Do they just enjoy trolling users? I doubt it.
They are actually both much better than the things they replace, but a bunch of whiner babies can't stand the thought of anything changing and will claw and scream while being dragged into the future.
Probably didn't even bother to diagnose the issue. It's hard to tell if it was even wayland related without logs and some digging. But lets just blindly blame wayland cause new thing bad!
I am actually working on my own language, and getting something better than Go is actually not that difficult!
The hard part about making a language is creating the stdlib and tooling and support for the language, but actually creating a language itself that has more features and better features than go can be done by a single person in a few months or a year probably, depending on how much experience they have.
Generics specifically are a great example here. A single person can implement a language with go-level generics fairly easily.
I am able to write rust on a moto g power (a cheap android smartphone) inside of termux, running on battery, in battery saver mode, and cached compile times for every single one of my projects is under 5s easily, if not faster. Fast enough that I don't notice it at all.
Even a "cold" compile was under 1 minute for me, and I have a decent amount of deps.
I guess my projects are fairly small compared to others though so idk.
openrc-init can be used on an upstart system, the daemon manager itself can't but that's because you'd have two different daemon managers. Beyond that there aren't any openrc software components, because it was designed to be a modular init system that just handles what it was intended to handle.
The rest of the system for example chrony, sysklogd, cron, etc run fine on upstart systems, because they aren't tied to systemd and are fully modular.
It's okay to be a monolith, that doesn't make it inherently bad or anything, but we should be honest about it, and it does come with some tradeoffs.
The statistics we have on real world security exploits proves that most security exploits are not coming from supply chain attacks though.
Memory safety related security exploits happen in a steady stream in basically all non-trivial C projects, but supply chain attacks, while possible, are much more rare.
I'm not saying we shouldn't care about both issues, but the idea is to fix the low hanging fruit and common cases before optimizing for things that aren't in practice that big of a deal.
Also, C is not inherently invulnerable to supply chain attacks either!
>The curl|sh workflow is no more dangerous that downloading an executable off the internet
It actually is for a lot of subtle reasons, assuming you were going to check the executable checksum or something, or blindly downloading + running a script.
The big thing is that it can serve you up different contents if it detects it's being piped into a shell which is in theory possible, but also because if the download is interrupted you end up with half of the script ran, and a broken install.
If you are going to do this, its much better to do something like:
sh -c "$(curl https://foo.bar/blah.sh)"
Though ideally yes you just download it and read it like a normal person.