The Linux Thread - The Autist's OS of Choice

[Knight of the Rope]

Slackware 15.0 was released today. DistroTube proven wrong again.

Holy shit, it is! They've even got an update on their sleek 1990s website.

It might be time to spin up a VM and give 'er a whirl.

If you're even using TeX editors at all you already know this though.

Not if you're a retard.
Source: Am retard, didn't know

 

[teriyakiburns]

The emergency laptop I bought to replace my dying work machine came with Neon installed (check out slimbook.es if you want decently specced linux laptops) which is a pretty decent kde ubuntu spin, despite the systemd cancer that infests all of them. Not perfect for my needs, but it'll be great when I'm travelling to clients. I coped and I sneeded, and dealt with it as best I could.

Cue six months later, the prices of various hardware btis have dropped enough (and they're available enough) that I can put together a new workstation beast. I figure I'll throw neon on it to ease the faff of transferring and then figure out how to excise systemd later. I need to work, after all. Only thing that I didn't configure properly in the transfer was docker (inb4 "lol docker scrub learn2baremetal"). It's installed, but my user wasn't in the docker group for some reason. Fine. usermod, newgrp, all that jazz. Restart docker. Still no access. Restart X; maybe my session is being held somewhere. Nope! Somehow, because its process is managed by systemd, I can't get my user to interact with docker without restarting the bloody computer like some sort of windows pleb. I never had this problem using devuan; adding a user to daemon's group restarting the shell session was usually enough. Sometimes restarting the daemon might be needed. Hell, not even windows has this problem any more.

Fucking systemd, man.

 

[Trigger Me Timbers]

Anyone who has issues with Arch fucking deserves 100% of it.

 

[AmpleApricots]

I was setting up a kernel configuration for my Celeron Netbook and had the hardest time getting the sound to work. Turns out, you have to actually activate the SoC driver for Skylake, *not* for what the chip actually is. (Gemini Lake) Teaches me to believe words to be what they say they are.

Kernel configuration turned into kind of a mess in recent years. Weird dependencies of (partitally hidden) options on each other which are really logically not follow-able anymore if you don't happen to be a kernel developer working on that particular part of the kernel or dig through the source/developer mailing lists. It's not entirely terrible yet but it also used to be better. Well, I guess hardware got more complex. With a custom initramfs and most hardware options and needed firmware, microcode, a few out-of-tree features patched in etc. compiled in, I have a kernel weighting in at 11 MB so far, half of that being the initramfs with a few tools I need before mounting root, so the kernel itself is maybe ~5 MB big with all options needed for this hardware. I thought it'd be worse to be honest, but I'm used to that absolutely gargantuan AMD graphics driver stuff. Still gigantic compared to what used to be. (It's compressed after all) What I found interesting is that the Ubuntu default distribution I tried on the hardware first didn't add the firmware for HEVC/H.265 out of the box, so the chip couldn't do that in hardware there. It taints the kernel when it's added (as of 5.16) but from all I tested, it seems to work just fine. So that's a heads-up if you use a goldmont refresh chip as media player.

Also a weird experience I made with that Ubuntu (Lubuntu or whatever) installation is that system load on X11 desktop (not doing anything, the desktop just being there) would hover around ~1.32 which is considerable for a dual core system. With my current gentoo installation (just runit&bare essential services&mdev&JWM) it sits in the 0.00-0.10 range. What are these people doing?

 

[Kosher Dill]

Here's my Linux curiosity of the moment.
Apparently there are a fair number of applications out there that like to use the GNOME keyring to store logins. Ordinarily the login keyring is unlocked when you enter your password.
However: what if you're running a passwordless system with a Yubikey, smart card, facial recognition, anal probe, or whatever? In that case, the keyring doesn't unlock when you unlock the computer, because it is literally expecting a password only, not a "credential" generally speaking.

Some guy made a workaround here:

https://git.recolic.net/root/gnome-keyring-yubikey-unlock

Essentially: encrypt a keyring/password pair (not necessarily related to any user's password) on disk with GnuPG, set up your 2FA device as a GPG smart card, and then set up scripts to automatically decrypt the file with the smart card and pipe the result into the keyring unlock process whenever you unlock your machine.

It's clever but it rubs me the wrong way.

 

[AnOminous]

This will guarantee no socked programmers work on your OS, but beware, if you work on it too much, eventually there may be one...

The problem with troons is you can't even keep them out. Someone can start out normal and then just suddenly troon out and turn into an insane, destructive moron from social media disease.

Fucking systemd, man.

This shit is like the OS version of Californication where people escape from some horrible shit, and then implement the exact same horrible shit in the place they escaped to. Pure cancer.

 

[teriyakiburns]

Here's my Linux curiosity of the moment.
Apparently there are a fair number of applications out there that like to use the GNOME keyring to store logins. Ordinarily the login keyring is unlocked when you enter your password.
However: what if you're running a passwordless system with a Yubikey, smart card, facial recognition, anal probe, or whatever? In that case, the keyring doesn't unlock when you unlock the computer, because it is literally expecting a password only, not a "credential" generally speaking.

Some guy made a workaround here:

https://git.recolic.net/root/gnome-keyring-yubikey-unlock

Essentially: encrypt a keyring/password pair (not necessarily related to any user's password) on disk with GnuPG, set up your 2FA device as a GPG smart card, and then set up scripts to automatically decrypt the file with the smart card and pipe the result into the keyring unlock process whenever you unlock your machine.

It's clever but it rubs me the wrong way.

Gnome keyring seems to be a never-ending tale of woe (not unlike systemd, come to think of it). I've had a persistent problem with (gh) skype, which demands gnome keyring to work. It saved creds for about a week, then arbitraily stoppedworking for no obvious reason, and now I have to enter the details manually every time I start it up.

The problem with troons is you can't even keep them out. Someone can start out normal and then just suddenly troon out and turn into an insane, destructive moron from social media disease.

This shit is like the OS version of Californication where people escape from some horrible shit, and then implement the exact same horrible shit in the place they escaped to. Pure cancer.

Half the time it's just a wrapper, too. Like pulseaudio. It's a wrapper around alsa, in effect; it claims to be everything under the fucking sun, but all it ultimately does is provide a way to pipe multiplexed audio to alsa - something that was entirely possible to do with alsa alone, if only any of the distro maintainers bothered to read the bloody man page. Not Invented Here is the bane of the entire open source ecosystem and it drives me insane.

 

[DavidS877]

Half the time it's just a wrapper, too. Like pulseaudio. It's a wrapper around alsa, in effect; it claims to be everything under the fucking sun, but all it ultimately does is provide a way to pipe multiplexed audio to alsa - something that was entirely possible to do with alsa alone, if only any of the distro maintainers bothered to read the bloody man page. Not Invented Here is the bane of the entire open source ecosystem and it drives me insane.

Pulseaudio should have been a pretty GUI that wrote asound config files. MAYBE a daemon that monitored device plug and unplug and reconfigured things 'smartly'.

Systemd should be shot into the sun.

My favorite is when I unmount a drive, replace it, update the UUID and mount it again and there's no error, but it doesn't mount. Turns out it does mount, and then systemd 'helpfully' unmounts it since it's the wrong UUID vs what it had cached or something. Seems like 'daemon-reload' 'fixes' it. I also enjoy it ignoring my DHCP provided DNS and NTP servers. I paid a lot of money to have a Raspberry Pi do NTP and DNS and damned if I'm not going to get my $35(plus GPS module) out of it.

 

[ellroy]

Stability and software variety are my two primary objectives. I really couldn't give less of a toss about the latest-and-greatest, but a rocksolid version of whatever arbitrary software I should take a liking to needs to be in the repos. I absolutely do not want to deal with shit like "we crashed X11 because some fuckhead maintainer simultaneously got a wild hair up his asshole yet also was unwilling to do his homework on properly integrating these changes....have fun using only the terminal to dig yourself out, sucks to be you!"

You're halfway there then. You'll get stability but not the software variety unless you are just interested in running proprietary coding software like Xilinx's FPGA IDE.

 

[Kosher Dill]

Gnome keyring seems to be a never-ending tale of woe

The more I look into it, the more it seems like the most practical solution is to just set the login keyring's password to blank, let the keyring file be stored in plaintext, and "kick the problem upstairs". The filesystem permissions, disk encryption, and physical control of the machine (in that order) will have to suffice.
And really, it's no worse than on Windows, where the "encryption" on saved logins is typically just a speed bump.

 

[AmpleApricots]

Systemd should be shot into the sun.

systemd is basically svchost.exe. Red Hat really, really wants a wrapper around the Linux kernel. If they manage to put themselves between the Linux kernel and userland, they have full control while doing none of the work. (Not entirely accurate I know, they're heavily involved in many projects including the kernel - but you get what I mean) Underhanded walled-garden shit like this is right up IBM's alley too, that's why they probably bought them out.

 

[NewRetroVagina23]

You're halfway there then. You'll get stability but not the software variety unless you are just interested in running proprietary coding software like Xilinx's FPGA IDE.

What would you suggest, then? SUSE? I hear Fedora has hangups about emulators and things of that nature.

 

[ellroy]

What would you suggest, then? SUSE? I hear Fedora has hangups about emulators and things of that nature.

Rocky Linux if you want to sniff out packages like a truffle pig. Ubuntu LTS if you want a plethora of software and can handle a small decrease in stability. Debian is a great choice too. I just think the sun has set for RPM based systems with how Red Hat has been acting.

 

[Frail Snail]

Half the time it's just a wrapper, too. Like pulseaudio. It's a wrapper around alsa, in effect; it claims to be everything under the fucking sun, but all it ultimately does is provide a way to pipe multiplexed audio to alsa - something that was entirely possible to do with alsa alone, if only any of the distro maintainers bothered to read the bloody man page. Not Invented Here is the bane of the entire open source ecosystem and it drives me insane.

Don't forget the new wrapper in town that also tries to be its own thing - pipewire. At least it seems to be better than pulseaudio.

 

[PFM]

Came across this little tool a few weeks ago and it can come in handy, especially for the newbies here. I've been using linux for over a decade now and still consider myself a newbie.

 

[seri0us]

The other day I had audio issues and at least partially because of all the linux audio horror stories I've heard, I tried messing with the software-side for at least an hour. Turns out the port was just dirty or something.

 

[Dread First]

Holy shit, it is! They've even got an update on their sleek 1990s website.
View attachment 2951952

Holy shit! I remember when Slackware 14 first came out when I was a wee freshman in college! This is definitely gonna be a trip down memory lane... though I'll probably end up getting sick of Slackware because of its "all or nothing" approach to resolving software dependencies. I know that options like slapt-get, Slackbuilds, and slackpkg exist, but they're just so ugly and unintuitive compared to having y'know... actual goddamn dependency resolution in the first place. I will say that having old-fashioned BSD-style init scripts like in the classic days of Arch Linux will definitely be fun to mess around with again though.

 

[Dick Justice]

I'm a huge fan of Fedora but it does have its problems. Moving to Wayland on the KDE spin for 34 was too soon. The devs really like being cutting-edge even when it's not a great idea.

tbh I'm calling that a feature, not a bug. A distro that focuses on moving fast and breaking things above all else is very cool as long as you know what you're getting into and if you bought a rake for daily use you're going to have accept the inevitability of one day stepping on it.

 

[Dread First]

tbh I'm calling that a feature, not a bug. A distro that focuses on moving fast and breaking things above all else is very cool as long as you know what you're getting into and if you bought a rake for daily use you're going to have accept the inevitability of one day stepping on it.

I have nothing against bleeding-edge distros, but I really wish that Fedora would just drop the versions altogether and go full-on rolling release like Arch Linux, openSUSE Tumbleweed, Debian Sid, or FreeBSD-CURRENT. Also, minor gripe of mine but I personally prefer running Arch over Fedora considering how the ArchWiki is (or at least was) the most comprehensive online documentation for any Linux distro ever and the fact that the developers are pretty good at preemptively warning people about specific issues that can bork your system. Also, Pacman >>> YUM/RPM/DNF.

 

[Ahriman]

Another look at Qubes OS.