All my graphical applications are Flatpaks, I have some command-line tools installed with Homebrew so that I don’t have to layer them and then I have few packages layered which aren’t available in Homebrew. I don’t care much for all the extras that come with something because when I installed Gnome on Arch it would come with quite a bit of dependencies anyways. If I could get a working selinux setup on Arch Linux I would probably switch back to Arch Linux.
SELinux is unrelated to the immutability. All RedHat and Fedora variants have SELinux, including the non-immutable variants.
That being said, if you enjoy the Atomic variants, there is nothing wrong with it objectively speaking. It just isn’t my personal preference.
I know that, I chose to try Fedora Atomic since I had used Workstation before. I like both for having an extra security feature, that being selinux. What I meant was it is basically possible to setup up an Atomic-like setup with Arch Linux without having the Immutable part, I would then just be missing selinux that’s all that I was pointing out which is my personal preferences.
*nix philosophy
- Write programs that do one thing and do it well.
- Write programs to work together.
- Write programs to handle text streams, because that is a universal interface.
System-give-me-the-D basically violates that by trying to do everything. Its primary component is a “system and service manager” — an init system used to bootstrap user space and manage user processes. It also provides replacements for various daemons and utilities, including device management, login management, network connection management, and event logging.
Yes I am a grey beard. When it started to creep into distros my first reaction was, “oh geez, now what? Windows Registry for Linux?” I like the simplicity of SysVinit but whatever, not going fight it.
You can always switch to Artix 
Happy where I am 
SystemD is not a complete deal breaker for me
2 Likes
me either. an init system is a whole other faster animal than systemd, very noticeable when you use it, in every way. Systemd is a bulky affair but I’ve grown used to micromanaging my system with (trimfs, ufw, printers, etc etc) systemctl a lot.
This is my biggest gripe with the Linux Ecosystem.
So many people in Linux communities hate change with passion, and I hate them back for it 
systemd-boot :
“But how will my 25 year old hardware boot?”
x86_64-v* instruction sets :
“And what packages will I use for my 25 year old hardware now?”
modern filesystems :
“ext* works. I don’t understand why people are trying to re-invent the wheel”
Memory-safe development :
“Don’t treat me like a kid! I can manage memory on my own!” (inb4 constant floods of CVEs attesting to that)
And the list goes on and on and on…
1 Like
You young whipper snappers with your mem-safe languages and fancy pants IDE’s with AI integration. All you need is a terminal, Vi and C.
5 Likes
I’ve heard people say its too big. Like million(s)? of lines of code which is kind of hard to audit. Although I like it. systemd-boot is easy to use. System and services are easy for me. Maybe not at first because coming from windows the concepts are foreign.
2 Likes
Well, that knife has two distinct and very sharp edges. Yes, people who hate change just because it is change are looking at it wrong. But as a recently retired software developer I can say that the opposite is also very much a thing: People who embrace change just for the sake of change. IMO this is just as bad as fighting all change. My tendency is to resist change unless I can convince myself that the change is meaningful and useful. (I.e. the “if it ain’t broke, don’t fix it” school). As to systemd, I see nothing wrong with it.
4 Likes
Can you give an example of a few of those applications I want to test something out?
I like the systemd timer. I converted all my user cronjobs to systemd timer which is a big improvement.
4 Likes
I think a large part of the issue was the attitude of the developer. Sometimes it is hard to separate the code from the coder.
That’s a fair argument.
I’m not as much “pro change” as I am “pro progress”.
And the reality is, you can’t make progress without changing.
And sometimes breaking things in the process is what it takes (again, as far as its non-critical stuff)
“If it ain’t broke, don’t fix it” is a perfectly valid approach for critical systems.
But it is sub-optimal for non-critical systems.
It’s perfectly valid to push Debian or Ubuntu Server LTS to become stale to support old systems.
It’s foolish to push Arch or Fedora to become stale to support old systems.
Also I hate the "but muh perfectly fine system from 2000! 
" mentality.
Like, dude, buy an intel N100 and you have a more powerful system at 1/10th the power consumption and stop forcing everyone to care about your e-waste 
Off the top of my head, VMware Workstation Pro, Softmaker Office and Btrfs Assistant. There was more but those are the easy ones to remember.
1 Like
Didn’t you author Btrfs Assistant?
Not that it invalidates your argument of course, just thought that it might have been easier for you (than anyone else) to directly package it as a flatpak to resolve the availability issue
Or is it simply a “level of access” issue required for its utility that flatpak doesn’t offer?
Yes, this. I don’t think it is possible to run Btrfs Assistant in a flatpak.
Thanks! Yeah doesn’t seem to be a straight forward way to get those to work, not even with Distrobox. The latter one can be layered but not really needed with an Atomic distribution but I’m assuming you use it to help others when people have questions about it since you are the maintainer of it
If I were to run such type of software I would probably go back to Arch Linux as well, but I don’t run such type of software and wasn’t when I was using Arch Linux with the exception for btrfs-assistant but don’t need that anymore with Silverblue.
1 Like
I grew up with SysVInit, and frankly, it did the core stuff really well. But anyone who has to deal with Linux at scale, whether that’s cluster management or modern cloud deployments, fully recognises this isn’t “your grandma’s Linux”
While Lennart has a bit of a reputation, and he’s indirectly responsible for me losing some hearing through acoustic shock due to pulseaudio being pushed out with some high severity bugs (volume jumping to 100% randomly while wearing headphones was not something I’d expected to ever happen), systemd was in some ways the best trade-off between the modular, and the integrated, and logging, log analysis, and automation scripting is a hell of lot easier than it was under init.
I get the arguments, do one thing and do it well, vs do everything, and there’s an element of feature-creep in systemd that people aren’t comfortable with, but it’s 2024, systems evolve, improve, diverge, this is where we are right now, and for the average user who sits on email and web all day, with minimal backend management or sysad routines, systemd is a non-event.
1 Like