That’s mostly fluff though. Like you show, the core is either Linux or bsd and gnu, and then you have a handful of families.
That’s not fragmentation, that’s freedom.
And compatibility is a big factor too. Because of gnu and posix basically, almost anything that works on one distro will work on another.
Imagine if each distro was completely locked from anything on another one. That would be fragmentation, and we wouldn’t be talking about it, because it would be shit.
My distro recently dropped support for gtk+2 (which I am fairly pissed about, since it’s the last good version of GTK+)
Stuff like this completely throws the shared libraries idea in the bin. There are lots of benefits, sure, but none of them matter when your program won’t even start.
Please name and shame your distro. GTK2 is a core component of userspace for many users, just as important as glibc and bash. Maintaining it might be annoying, but it’s the lesser of two evils.
My distro (Void Linux) dropped support for qt4 a few years back. Now I’m running QUCS in wine. “win32 is the only stable ABI in Linux”
(And yes you’re right 2 is the last good version of GTK+. Gtk3 and 4 look and feel so much worse, they make me feel like I’m being punished.)
False alarm! I’m on Void Linux too, gtk2 is alive and well! I was just being an idiot and searching for gtk2 while the real package is called gtk+2. I absolutely agree about gtk3 and gtk4. With gtk4 its like they didn’t even bother. Client-side window shadows?!? seriously???. I personally prefer CLI and TUI for my apps, but gtk2 would be my second pick if I ever need to develop a GUI app. Partly because if my app ever gets popular, it would piss off a lot of those updooter types. I would love to use something even more minimalist like nuklear but sadly that’s missing a lot of actually useful desktop integration like IME support (as far as I understand).
A method I have not seen mentioned yet (for when you have an old precompiled version of an app):
Identify the missing libs. You can run the program, but sometimes it’s easier to use ldd
Use your web browser to download the missing libs from Debian’s repos (stable or older if need be). Unfortunately you often also have to grab their deps too.
Extract the .debs
Move all of the .so files into the same folder as the old program you are trying to run
export LD_LIBRARY_PATH="$(pwd)"
Now try running the app
It often takes a bit of fiddling, but it’s worked for me a few times and you only need to fetch the few libraries you are missing. For bigger things however it can be a dependency hell, you might as well use the distro’s actual package manager inside a chroot.
Note: You don’t need to be using Debian as your host distro, I don’t. As long as it’s a glibc based distro you should be mostly fine (glibc is mostly backwards compatible)
Yes, there is a little colony of gnomes sitting inside the machine. They are the ones doing all the heavy calculations. The bitcoin boom burned out so many of them it’s a total disaster. Currently you could consider them kind if endangered I guess.
Oh fk now thinking about it, me starting to use an Arch based distro and starting going to laser epilation pretty much happened at the same time period. Save me…
LUKS doesn’t protect you from an evil maid attack. It hides your data when your stuff gets stolen in a powered off state, but it provides neither verification of data, nor does it provide verified/secure/safe boot.
In simple terms: the very first thing which gets loaded needs to be unencrypted (barring some exceptions I will omit here), which can get replaced with an evil version by the evil maid.
Is it even possible to mitigate such an issue? Will resetting the bios by removing the cmos battery not also disable password protection in the bios thus making it possible to disable secure boot?
And at that point could they not just use a hardware keylogger or something?
Yes, with a TPM. A TPM (2.0) can seal secrets and only release it when a machine fulfills certain configuration and state requirements (saved into registers called PCRs).
For example: make the decryption key one part dependant on a passphrase you memorized (to not only rely on a TPM), and one part on something saved in a TPM. If you select the correct PCRs when saving the latter, and your TPM works as advertised (and doesn’t offer an easy way to eavesdrop/fool it), removing the battery would make the TPM not release the secret (if removing the battery even still works on modern machines).
However, this depends on having a unified kernel image, having configured dm-verity and maybe more stuff I don’t recall right now. Probably should also make sure you don’t allow Microsoft’s Secure Boot keys and instead only your own. I hope this will get easier in the future, but I know SystemD is actively developing useful tools for that (e.g. ukify).
That all doesn’t mean the critique of TPMs (intransparent, proprietary) is invalid. Maybe we’ll have OpenTitan based TPMs at some point?
linuxmemes
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.