In this meme template both the lowest and highest IQ should say the same thing

What‘s wrong with installing software from a package manager when the package I need is on there and has a decently up to date version? If its not on there I can still build from source.

When I‘m in a situation where I just need a specific lib or cli tool or whatever and don‘t have time to potentially debug a niche compile error, installing from a package manager is more convenient and saves time.

Except snap, which can burn in hell.

Regardless of whose fault it is, it’s unacceptable that half the people with a discrete GPU have nigh incompatible hardware. It’s more akin to using snow tires breaking your car than a jet engine.

It works but it kinda forgets the monitor layout, especially if you remove the computer from the dock while the os is sleeping.

It is a pain in the ass to set it up again, especially since it thinks it is a great idea to use the inbuilt monitor, even though the lid is shut.

Also when you undock when suspended sometimes it forgets to check after waking up, and some programs, especially fullscreen video playback has a tendency to continue on a “ghost display”

Overall it is livable but annoying especially because 33% of times it just works.

Also this is xfce. Cinamon and Mate may be much better.

I think by default the debain installer doesn’t have any proprietary code.

Cmon, this might have been true 15 years ago, but my grandma has been using Mint for 5 years + and TRUST ME she don’t know shit about Bash. Big distros work OOTB today, as soon as you stick to regular use you’ll never see a shell in your life.

@kmkz_ninja @OrnateLuna

I know people who use linux mint (or other distros that aim at user friendliness) who literally never have to touch the command line. This claim that you need to use the command line was true 5 years ago, but today it is largely false.

I am in a Linux User Group and I am literally the only person who uses a tiling window manager (I use hyprland) instead of DEs like kde, gnome, cinnamon, etc.

“Seriously, why is it such a confusing prospect to Linux users that Linux is difficult?”

Because honestly? It really isn’t. A couple of years ago, maybe it was hard, but now, Linux is easy to pickup and learn; so easy even someone like me who has zero programming/coding skills (not my profession) and still kinda thinks typing stuff into the terminal is basically black magic was able to pick it up and adopt it with very little hiccups and set it up for my ma on a seperate computer with no problems on her end. Unlearning Windows? That’s the hard bit, especially if you go into Linux (or even Mac, as was the case with me a long time ago) thinking it’s Windows with another skin instead of different beast althogether that has it’s own quirks one needs to get used to, just like with anything new (and just how the majority are used to Windows’s own quirks). That’s where you’ll start having a bad time.

Most people don’t want to have to use a cmd line to use their PC.

“I don’t want know that car needs oil changes, I just want turn key and go”

“Uh oh, car no start.”

/throws car in trash and buys a new one

The best know how to tread the line perfectly. Some say that even they don’t know if they’re serious.

Haha 😀 This is Linux memes community afterall ƪ(˘⌣˘)ʃ

No, there’s a pretty important difference.

XD

I’m saying that’s a way I might personally consider going if I were to set up a new computer. Rock solid base that you can still get normal packages and binaries to run on without much hassle if needed, plus Nix with more up-to-date packages that you can customize however you find most useful.

Personally I have a mix of rolling/regular repos, AUR, Nix, Flatpak, and static binaries. They all have their uses, TBH.

Disk space is an issue… I’ve seen the OS take as much as 100 GB. But in a world of 2TB SSDs for $100, is that a big deal?

Yes? Storage used for the OS is space not used for projects, entertainment, docs, redundancy, snapshots, avoiding fragmentation (EXT4), etc. Money spent on SSDs is money not spent on going out, food, meeting people, basic needs, other hardware, etc.

I don’t see why NixOS would be any worse for the lifetime of a disk than other distros.

Untested, but I’d assume high space use combined with high update frequency, plus occasional builds-from-source and multiple simultaneous package versions, means more disk writes.

Biased, maybe, because manual GC means you see disk use tick up more than in other package managers, and also because I personally repeatedly rebuilt a custom gigabyte-sized Derivation dozens/hundreds of times. But I think it’s a reasonable point of caution.

I’ve only hit binary cache missed for packages I created, or where I changed build options.

Broken packages are, if anything, less of a problem [than] with Debian. Debian has lots of packages that are…not broken, but incomplete, requiring lots of manual config or whatever.

Maybe this is a NixPkgs vs NixOS thing. Also, using Nix mostly to supplement packages I hadn’t already installed through my distro probably meant I hit more fringe areas. But I’ve even encountered cache misses and failed builds for some pretty big Python libraries on certain commits.

Debian-based out-of-the-box functionality for stuff is indeed also Not Great, IIRC— Stable, but yeah, sometimes maybe a bit “incomplete”. Actually, Arch-based has worked well IME.

And on the flip side: you can change package build options! Neat!

But oh man…you should’ve seen how trivial it was to switch from PulseAudio to PipeWire (including Jack support etc), leaving no trace that Pulse was ever installed… Or switching from X to Wayland, on a system that I’ve been doing rolling updates on since 2017, all with a clear conscience… It’s beautiful.

Yeah. I personally don’t care about that stuff unless it directly impacts something I’m working on.

And that’s why I say Nix is a great tool for package management, but not something I’d personally want to use as an OS base. When you’re already elbow-deep in the plumbing anyway, Nix makes it way easier to swap components out. But when you just want to install and use an application, editing Nix configs feels like more work, and it’s so much easier to just pacman/yum/apt-get install firefox or whatever and get on with your day.

Plus, some specific red flags surrounding stability and interoperability:

1. ALSA is apparently hardcoded to just straight-up not work with a Nix root. Not sure how NixOS handles it, but in my specific use case, I had to symlinkJoin{paths=[alsa-lib alsa-plugins]} so they could find each other. Pretty sure it took a lot of strace -f -e trace=file and nix-locate for me to figure this one out, just to get sound working.

2. QtWebEngine/Chromium has to be run through some kind of sed -e "whatever.so" to “Patch library paths in Chromium sources” in order to even run, because it’s also hardcoded to just not work with a Nix root. IIRC, this one I figured out by just straight-up grepping on the compiled binaries after seeing the errors in strace or whereever. Seems a bit ridiculous, using a RegEx to patch a web browser when installing it so it can even run.

3. Binaries aren’t safe either, because they probably need patchelf to be able to run on Nix.

4. Flakes are apparently hosted as user repositories on a Microsoft-owned website, and can just randomly disappear sometimes.

5. Qt generally takes a ton of extra steps to be able to run on Nix. And have you actually ever opened the wrapper the Nix hooks generate to see what it’s actually doing? For one of my applications just now, you get a 43kb Bash script with apparently 581 assignments to just a handful of QT and XDG-related environment variables.

6. OpenGL doesn’t look safe either. Nix handles the drivers its own way, so to get OpenGL for Nix packages to work on other systems, you have to jump through some hoops. I assume the same amount of work in the opposite direction would be needed to use EG proprietary or statically compiled graphics applications on NixOS too.

7. Running precompiled binaries on Nix looks… Involved, as well. Sure, there’s tools to automate it. But that only hides the complexity, and adding an opaque dependency sorta defeats the entire purpose of configurability and composability IMO.

I’m sure most of these problems are “solved”, in the sense that NixOS implements workarounds that are the default when you install the affected derivations, and there are wrappers written for most other cases. But all of that adds maintenance, fragility, and complexity. It remarkably works well enough for userspace, but stuff like this still feels a bit house-of-cards-y for the basic OS and desktop. It’s not Nix’s fault, but so much of the work that goes into Nix seems to be just to force software that was never designed for it to run on it. Ultimately, the Linux FHS has momentum and adoption. Nix’s technical design might be compelling, but so are interoperability, stability, and simplicity.

The NixOS enthusiasts are doing a lot of technically interesting work, but I personally find the results of that work most useful outside the NixOS ecosystem. And I do think Nix as a package manager is really great. Ever since I’ve installed it, I’ve basically incorporated it as a major component or tool in every sizable software project I’ve since started. But I just personally wouldn’t want to base an entire OS on it.

New distro smell hahah exactly, that’s perfect.

I’d say EndeavorOS is the way to go. So far I haven’t had nearly as many issues as I had with Manjaro