Both are great projects really, and big projects at that - big stacks, lots of moving parts.

Whereas GNOME tries to be more uniform, Plasma tries to be more bespoke.

I don’t care which one you use, really. I just love GNOME design principles and it’s desktop paradigm.

Is GNOME a perfect project? No. But when these troglodytes crawl out of their discord servers, I just can’t help but be infuriated by their pure malice and ignorance.

So fuck em. I’m done with this thread.

You have a nice day now, y’hear?

“16 years of paving the way for Plasma”.

There, fixed that for you.

Huh, I guess you’re getting to them then with your massive winging. Guess you’ll get your Rube Goldberg desktop you want and still complain.

“most very useful”.

List. Tell me which ones.

Oh noes! Design spec?!? :( STANDARDS AND ETHICS?!?! No! I Want you to install my halfass, broken solution instead of waiting for a proper solution to come along! I’m such a special boy and know coding better than you! HOW DARE YOU HAVE PLANS!! /s

Like some of you are buffoons and need to go use something like Plasma instead. I love Plasma, not pushing that down, it’s just that if you don’t know the modus operandi of GNOME in 2024 already, you might as well give up trying.

At the very least give up complaining. You wouldn’t have Wayland if it weren’t for WONTFIX, ya daft cunts.

Hey, look who’s no longer pushing the envelope… come on irrelevancy…

I’ve had nothing but good experiences with Flatpaks/Flathub and bad experiences with AUR/nixpkgs.

Fedora also has it’s own Flatpak repo now with it’s own runtime.

haha also nix… because I horde dependencies.

Sun Microsystems was once the great hope of the computing world, and technically the JVM was first to normalise the use of VM’s, albeit from a containerised perspective. It was Docker before docker, in some sense.

This coupled with Solaris and the SPARC systems that were Java-native (whatever that means) enabled this type of containerisation from a hardware level, which again: was a huge thing.

But, Sun turned for the worse once the JVM hit browsers and server stacks. That’s when their SaaS model was envisioned, that was the precursor to the acquisition by Oracle.

So it started nicely, but hit the enshitification velocity somewhere in the early 2000s.

haha java is terrible, mostly because of who owns it.

haha but using a FLOSS system is… change my mind.

This is my problem, perhaps not with nixpkgs, but nixpkgs:nixos-stableunstable. Throughout history the call to fame for distribution is not all the fancy bells and whistles, but the cohesiveness and stability of the stack - the entire stack.

I’m not saying this is a flaw of nixpkgs, but rather a fair amount of technical debt on the of part NixOS maintainers and developers. It’s a vast movable system of modules, while being immutable at the same time. It ain’t easy. So more contribution is needed.

I’m happy that people join and help with that. I’ll still use NixOS and nixpkgs for embedded, specialised cases, even as servers, but I’m not going to run it on a workstation. But, I’m hopeful for the future. I’d like to run it, but not yet.

It’s not really necessary anyways, nix can run on any system… now onto my adventures of bringing nix to an immutable Fedora system without a container or VM lol

Me: *declares an app*\

nixpkgs: Oh what’s that, you wanted an entire extra desktop stack inside a separate closure? Yes, sir!

Me: plz no

You do know there are left wing people out there who own guns and go to the range, right? Because when them nationalists show up in their leather boots, knocking on doors, they won’t give a damn if you’re a pacificist. They gonna go pop-pop-pop.

Learn from the black panthers. If proliferation of guns is the standard, abstaining will only make you - and your children - a juicier target.

But, even if you’re anti-guns, there’s one more thing.

One talking point you could use with pro-gun people though, even if you’re anti-gun…

“So let me get this straight… you’re against the government taking away your guns, but for the government taking away your encryption?”

Say it with me now:

THE RIGHT TO ENCRYPT SHALL NOT BE INFRINGED

“…daughter dearest.”

“Wow, this guy programs.”

“Run, my little QA team. Do my bidding.”

Truefax

…yes, I know. I’m one of them. Used to compile my OS and everything.

Systemd is still better than init/daemons, categorically.

…NixOS is the new Arch Linux. Change my mind.

TL;DR init system, services, sockets, slices, logs, boots, VM’s, containers… and that’s fantastic, for monolithic systems. journalctl go brrrr

Strap in, folks. Old timer with a gavel to slam.

When systemd is unfolded in full, people are sort of apt when they jokingly say “-Linux, or what I’d like to call gnu/systemd/Linux”. Some scream at the top of their lungs, yearning back to rc.0 days, “when everything was much simpler”… this is where the gavel comes down. There are so many improvements they are hard to list and if you asked me if I could go back, only with modern software, I would say nay… and here’s why:

Running services is a whole mess more than just running background apps, and it’s intrinsically intertwined with what is known as the init system - no matter what some people may think. Init is the process of initializing (or bootstrapping) an operating system, and services are background services, but both are about managing the processes within the Linux stack - or the thread. Some say that systemd is doing more than it should, but systemd is not “crossing streams” when both init processes and services need to be managed in concert depending upon the way a system inits - because there’s more than one way to init.

systemd manages init through scopes, slices and services, which combined create the hierarchy of processes used to bootstrap a system, get things up and running, with their relative permissions, in a given state, to facilitate a running and functioning system. Socket units handle socket files or destinations, and timer units handle event driven processes.

It all comes together into a dependency chain that defines your running system, which is testable and manageable from a set of tools. systemctl is used to manage a running system, and I think it does a great job of it. Imagine fail testing a bunch of non-standardised, random rc bash script files that aren’t distro agnostic, along with whatever daemon runner you were using. It was a mess, and systemd sought to fix that - which imho it has. We view a booted Linux system and it’s process tree much differently through the systemd lens, which gives us a newfound focus that helps us better manage a running system.

Also, logs are binary now… you’re all so spoiled and you don’t even know it. Do you remember 20GB txt files you absolutely had to open? Pepperidge farm remembers. Which brings us journalctl, which is just so good. It’s the swizz army knife of Linux logs. You can point it at anything. Specify -k for dmesg, a service using --unit, point to a binary in /usr/bin, select previous boot with -b -1, -f for follow, -e take me to the end of a log. If you haven’t learned how to use this tool, you are running blind. It whips every dang logging system out there. Going from systemd to windows events feels like going from a soft mattress to the inside of an iron maiden.

systemd-boot is blazing fast. Don’t get me wrong, Grub2 is still fantastic as well (Apple seems to think so at least), but considering ease of us - as I often do - I’m inclined to prefer systemd-boot because of bootctl, because like journalctl, it’s a wonderful piece of kit for managing, analyzing and failtesting boot images, provides UEFI functionality and being a sort of one-stop shop for the boot process.

Now we we’re seeing systemd managing VM’s (machinectl) and containers (containerctl), and honestly I’m all for it. Make my life easier. Please. Standardise that mess. And since it is standard, everyone supplies systemd units and because of the nature of systemd and it’s designs, it’s all fail-safed to hell and back. This is good. We want this. At least on the desktop, workstation, even some servers. For containers, embedded, not so much, as they aren’t monolithic systems. That being said, NixOS has proven that systemd isn’t a barrier to entry for new system paradigms either, so I feel those fears were unfounded.

You get the theme here. Systemd is a system management suite, and not just a service runner or init system. It seems to grow and grow out of proportion, but at the end of the day, it’s about getting the system(s) and software up and running, as well as managing those processes and figuring out where problems lie. That’s what systemd does. It’s become part and parcel of a fully monolithic Linux stack, and in my opinion it’s a great project that makes our lives much easier.

To me systemd is zen. It’s the cup of tea Linux always needed, and I’m not ashamed to say so.