The Linux Thread - The Autist's OS of Choice

[Susanna]

Not really. /bin and /sbin were stuff needed to boot and were on the root drive/partition.
/usr was less critical stuff and would be available once the /usr partition was mounted.
/sbin was supposed to be critical statically linked stuff that would be usable in case you blew up the dynamic linker/libc/whatever. Obviously that's sort of morphed into "stuff for the superuser"
We didn't always have 4T boot drives.
My lawn something something.

Yeah, but even in the early 90s boot drives were sufficiently large that you didn't need to do this any more, it's kind of silly to still be following this concept in the current year. We wouldn't really lose anything changing from /usr/bin et al to, say, /apps, especially not if you symlink the old directories to the new one (for a couple years at least). Same for /etc/ to /config/ or /run/media/$USER/$VOLNAME to /disks/$VOLNAME.

It's a necessary step to implement signed, read only root images, which he wants because it will make his laptop boot ever so slightly faster, and Rh wants because it grants them more control over their customers.

Nobody cares about booting a second faster, people are opposing this change solely because it's Red Hat and Poettering. Which is silly, because it's a positive change.
I want signed, read-only root images because it means SecureBoot compatibility and more security. As it is you can fairly easily replace someone's kernel image with a new one because running Linux means you either have to turn off a lot of these securities yourself, or your motherboard vendor did that for you. Even I have the technical know-how to inject something that makes the kernel fork an arbitrary process, imagine how much worse an actual hacker could do.

 

[DavidS877]

Yeah, but even in the early 90s boot drives were sufficiently large that you didn't need to do this any more, it's kind of silly to still be following this concept in the current year. We wouldn't really lose anything changing from /usr/bin et al to, say, /apps, especially not if you symlink the old directories to the new one (for a couple years at least). Same for /etc/ to /config/ or /run/media/$USER/$VOLNAME to /disks/$VOLNAME.

The MacOS thread is over there ----------------->
Stop trying to shit up Unix.

 

[Betonhaus]

Nobody cares about booting a second faster, people are opposing this change solely because it's Red Hat and Poettering. Which is silly, because it's a positive change.
I want signed, read-only root images because it means SecureBoot compatibility and more security. As it is you can fairly easily replace someone's kernel image with a new one because running Linux means you either have to turn off a lot of these securities yourself, or your motherboard vendor did that for you. Even I have the technical know-how to inject something that makes the kernel fork an arbitrary process, imagine how much worse an actual hacker could do.

Pretty sure you can already have Secure Boot, tho that depends on the distro and how you use it.

 

[Miller]

Which Linux distro is the gigachad of linux distros and not a femboy linux distro?

Linux Mint, if you have been disliking Isreal long before it became trendy to not like that country.

 

[Susanna]

Pretty sure you can already have Secure Boot, tho that depends on the distro and how you use it.

Sort of, but actually no. What they're doing is either signing a "shunt" (a small efi binary that loads another binary and then exits), or signing a given kernel image (initramfs or vmlinuz). The root image doesn't get signed. In the case of the shunt, normally the binary it loads is simply the kernel, so injecting my own code into that is trivial. In the case of a signed kernel, I'd simply have to inject my code somewhere else, such as getty. So you see, neither one is really much security at all. Granted Linux is far ahead of macOS and Windows in terms of full system encryption, but if you can get your code into memory with the shim or the kernel, the system is still compromised.

The MacOS thread is over there ----------------->
Stop trying to shit up Unix.

Just because I'm primarily a mac user doesn't mean I'm not also a Linux user. My server and my desktop workstation both run Linux, I use it all the time, I have as much right to have opinions on it as you do.

 

[i440BX]

Another Linux Youtuber dunking on LunDuke: Chris Titus Tech :
I didn't watch it, but I will assume the worst...

 

[std::string]

Sort of, but actually no. What they're doing is either signing a "shunt" (a small efi binary that loads another binary and then exits), or signing a given kernel image (initramfs or vmlinuz). The root image doesn't get signed. In the case of the shunt, normally the binary it loads is simply the kernel, so injecting my own code into that is trivial. In the case of a signed kernel, I'd simply have to inject my code somewhere else, such as getty. So you see, neither one is really much security at all. Granted Linux is far ahead of macOS and Windows in terms of full system encryption, but if you can get your code into memory with the shim or the kernel, the system is still compromised.

DRTM is currently being worked on, and with a true immutable OS the getty attack vector wouldn't work.

So give it a few years

 

[Betonhaus]

DRTM is currently being worked on, and with a true immutable OS the getty attack vector wouldn't work.

So give it a few years

Maybe it'll work best for some slow-moving and stable system, where the core of the os is in an encrypted and signed SquashFS file?

How about something that's a bit like Blackberry OS, where the initially booted code focuses solely on verifying the signature of files, and the major components of the OS and all apps are signed SquashFS binaries that get blocked if the signature is incorrect?

 

[Spasticus Autisticus]

Another Linux Youtuber dunking on LunDuke: Chris Titus Tech :
I didn't watch it, but I will assume the worst...

Didn't expect this from Titus, he's usually good at staying away from political shit. It's pretty much just him tut-tutting about Lunduke's political positions post-2020. It's pretty easy to do that when you spent the Summer of Love in a quiet Texas suburb instead of in the middle of fucking Portland.

 

[Prj4MW8iPT3vmFM2rzDc]

Linux Mint, if you have been disliking Isreal long before it became trendy to not like that country.

What if I'm indifferent to whether or not if both Israel and the "Palestinians" some how both (if they were able to acquire a nuke) and erase each other off the face of the planet at the same time, or w/e so long as I never have to hear about either of them ever again?
What Linux distro is specifically supported and updated through the power of Racism, Misogyny, and Transphobia?

 

[Betonhaus]

What if I'm indifferent to whether or not if both Israel and the "Palestinians" some how both (if they were able to acquire a nuke) and erase each other off the face of the planet at the same time, or w/e so long as I never have to hear about either of them ever again?
What Linux distro is specifically supported and updated through the power of Racism, Misogyny, and Transphobia?

Gentoo?

 

[Trans Fat 41g]

Another Linux Youtuber dunking on LunDuke: Chris Titus Tech :
I didn't watch it, but I will assume the worst...

I watched the first few seconds and then stopped.

Stick to your fucking lane, Chris.

 

[Miller]

Another Linux Youtuber dunking on LunDuke: Chris Titus Tech :
I didn't watch it, but I will assume the worst...

I guess Chris Titus wants to be on the "right side", in hope that the KDE soydev won't make a hit piece on him.

 

[Radiator Grilled Cheese]

What Linux distro is specifically supported and updated through the power of Racism, Misogyny, and Transphobia?

I've seen troons use pretty much every distro from the obvious ones like Ubuntu, Fedora, and Debian, to Arch and Gentoo for the memes, even NixOS and Void, but never in my life have I seen a troon use Slackware. I guess Patrick Volkerding and @Sperg Coalition win this round. If you want something more bleeding edge, then try Artix.

 

[Computer Guardian]

I've seen troons use pretty much every distro from the obvious ones like Ubuntu, Fedora, and Debian, to Arch and Gentoo for the memes, even NixOS and Void, but never in my life have I seen a troon use Slackware. I guess Patrick Volkerding and @Sperg Coalition win this round. If you want something more bleeding edge, then try Artix.
View attachment 5995104

God damn, I hardly lurk the Artix Fourms outside of trying to find fixes for shit breaking, but that coming from an actual developer of the distro makes me wonder how "based" him and the other devs besides the times they are forced to confront something like that on thier fourms.

 

[Betonhaus]

I like how Linux Mint has an IRC help hotline built into the welcome app

 

[analrapist]

Vox Day has joined the Mint community: https://voxday.net/2024/05/16/brave-on-linux/

I was unhappy with a cheap Chromebook that I bought to take on the road, so at the advice of a very well-travelled friend, I bought a 7-year-old used, but high-quality laptop for less than one-third the price of the Chromebook, then wiped the hard drive and installed Linux on it, specifically, Mint Cinnamon.

The installation was vastly easier than it was back when I was installing Red Hat 9, and I only ran into two minor issues in the process. [snip]

Computer technology has now reached the point of declining marginal utility for most users, and Windows is becoming ridiculously intrusive, so you can get some real bargains as long as you are willing to enter the tank zone and don’t have any esoteric software requirements.

 

[std::string]

Maybe it'll work best for some slow-moving and stable system, where the core of the os is in an encrypted and signed SquashFS file?

How about something that's a bit like Blackberry OS, where the initially booted code focuses solely on verifying the signature of files, and the major components of the OS and all apps are signed SquashFS binaries that get blocked if the signature is incorrect?

This is conceptually similar to how OpenSUSE MicroOS/SLE Micro works. You could do it using SquashFS but you'd have to make a whole new one every time a package updated and that would get pretty annoying in terms of disk space and bandwidth pretty quickly.

How MicroOS does it is: your foot filesystem is read only. When you update it creates a btrfs snapshot, then updates that (using normal package management tools) and then makes it read only. The root filesystem on disk never changes. When you reboot you'll boot into the new btrfs snapshot that has the updates applied.

Assuming you're only using SuSE's repo (which is, actually, the only thing it officially supports anyway...) there is no way for an attacker to mess with your system binaries.

 

[geckogoy]

How does it prevent the compromised snapshot from just mangling the btrfs snapshots?

 

[jONALD]

Everyone is wrong. Slackware is the best. I know all of my packages and they are all written down in a notebook.
Edit: UEFI can suck a dick, the LILO is my friendly bootloader and it understands the real chad MBR