The Linux Thread - The Autist's OS of Choice

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
i think karl jobst is currently trying to sue billie mitchell from australia to florida and is running into that problem just snail mailing the documents lol
Well, Karl is a complete lunatic that has acting totally irresponsibly and irrationally.

I don't like any of the Linux Tubers barring maybe a handful of them (I generally ignore their content), but none of them seem like lunatics. Almost all of them are standard shit-libs.
 
But like I've been saying, this isn't some obscure behavior pacman has, it's pretty much standard practice for a package manager. Anyone who has used any distro other than debian. Particularly ones that expect you to know how at least a little about managing your system (and even ones that might not). Pretty much do the same thing.
Interesting, I guess Red Hat does this too.

This just means that everyone not following Debian practice is wrong (and that the main Debian team will probably fuck things up to match the less careful distributions in future).

It's not 'knowing a lot about managing your system' to have to waste time combing through the output of an update/upgrade command, by the way- it's just inefficient.
 
Semi-related, but how do I set up a TOR bridge on Linux Mint?
The instructions are here:
Assuming that it is publicly available, you would definitely want to set up the Tor repos to get semi-up-to-date versions of Tor stuff. That's here:
(But you would replace the 'DISTRIBUTION' in the sources.list with the equivalent Ubuntu version for your version of Linux Mint, not whatever Mint calls its variant of Ubuntu internally- i.e. 'noble' for the latst version)
 
Well, Karl is a complete lunatic that has acting totally irresponsibly and irrationally.

I don't like any of the Linux Tubers barring maybe a handful of them (I generally ignore their content), but none of them seem like lunatics. Almost all of them are standard shit-libs.
The vast majority of them are far-left.
I try to avoid politics most of the time irl, but last time one mentioned my ideology and i said "hey that's me :)", The guy immediately said : "I won't shake your hand anymore" as if i had killed his dog. He is anarcho-something.
 
Anyone here who uses GNU Guix unironically as a package manager? Do you like it/hate it? Is it better than other package managers?
 
You must not use sed for searching and replacing text in files where lines are larger than 2GB in length. That was crashing. Nasty bug, that.
https://lists.gnu.org/archive/html/sed-devel/2026-04/msg00027.html I mean, there are some 'security bugs' fixed, in that the (non-POSIX) --follow-symlinks option (used with the in place editing flag) had a race condition where if you ran sed against a symlink and changed the symlink to point somewhere else it would read data from the initial target of the symlink and write it to the new target.
So this is the power of Mythos.
 
Anyone here who uses GNU Guix unironically as a package manager? Do you like it/hate it? Is it better than other package managers?
I've used it for nearly a decade. It has many of the autisms I like: reproducibility, free software, bootstrappability, hurd, etc.

YMMV, though - for me, the fact that I can pass --no-substitutes, sever all dependency on upstream at any time, and still build every package from source from scratch starting from a tiny 357-byte binary authored in commented hexadecimal is an excellent feature. For most people, though, that's not a feature they would ever willingly choose to use.

I've said it before, but the Guix user experience is that it is magic and amazing if you stay on the beaten path, paved with the blood and sweat of thousands of GNUisances gone before. Venture off it and you realize that Guix is so powerful because its approach to packaging is more or less "GIVE ME HARDER BATTLES". Every place that any package refers to hardcoded filesystem paths has to be patched. Interpreters and runtimes that don't have an RPATH-like feature need to have all programs for them wrapped in shell scripts that set up the environment properly. GCC (and other tools) need to be patched so that strings are always stored contiguously in compiled output files so that references to inputs can be found, recorded, and patched for garbage collection and grafts. Source needs to be verified, hashed, and recorded in package definitions, and if the upstream source ever gets modified in-place, the source will fail to download due to a hash mismatch. And that actually happens annoyingly frequently for dumb shit like "a boost patch was modified in place to remove a trailing whitespace on line 6 of a 17 line diff file". The pure functional nature of it means that actually modifying something low in the dependency graph means that now everything that depends on it is now a different package that needs to be rebuilt. If it's a change that only needs to be present at runtime instead of build-time, like security updates, you can use grafts, though.

The packaging standards require things like running the test suite wherever possible and ensuring it passes. If you ever try building the world yourself in guix, you will learn to despise the people who write tests that fail 80% of the time. And you will learn to hate Rust with a burning passion (enjoy building 20 versions of it in a row because they cannot ever, EVER say no to using shiny new thing). Almost nothing works on x86-32 these days because of it. Oh, and Python. The flaky tests are almost always either Python or GNOME. Just recently I had the displeasure of having to try building evolution-data-server because something depended on it. There was a single test that would always fail no matter what, even with hundreds of retries. Eventually I got fed up and went to the trouble of debugging it. It turns out that the test would cause fdatasync to be called 1281 times, and it required the test to succeed in... 10 seconds. So if your average seek time is above 7.8 milliseconds (i.e. you are using a hard drive), it is literally impossible to pass the test.

To answer your question, yes, I like Guix, but it inspires a lot of hate in me. Other package managers seem extremely limited by comparison (seriously, requiring root just to upgrade *your user's* packages?), but to be fair, I haven't done much comparing recently.
 
Interesting, I guess Red Hat does this too.

This just means that everyone not following Debian practice is wrong (and that the main Debian team will probably fuck things up to match the less careful distributions in future).

It's not 'knowing a lot about managing your system' to have to waste time combing through the output of an update/upgrade command, by the way- it's just inefficient.
No you don't have to comb through the output. Like I said, every once in a while you just run the command that checks if you have any pacnew files on your system. You don't even need to pay attention to the output of the command. Although its not like you have to look hard. I'm pretty sure it shows it on the last line, or something like that when it does give you a warning about it.
 
Back
Top Bottom