61–70 of 166 posts
Earlier quoted context omitted.
The linux world is busy getting shit done. Ignore the children arguing over init systems.
Edit: not a thread I should have let myself get dragged into. Suffice it to say, market share is not the same as quality.
Earlier quoted context omitted.
The argument is not about the init system. systemd’s is probably fine. It’s about an ever expanding take-over of userspace by a single module, which is not the Unix way. And about a high-handed project leader who is paid by Redhat to do it full time.
Agreed 100%. Systemd is a pretty good init system IMO. Service files are good, timers are good, dependency-based init is good. Easy sandboxing is nice. I absolutely _don't_ think that my init system should also be my bootloader. It also shouldn't manage my network configuration, or be responsible for controlling the system clock. And it shouldn't assert control of my home folders. And it shouldn't be spidering its wa…
Earlier quoted context omitted.
If someone is able to create something that is half as good as systemd then distros will switch time it. The thing is that systemd solves a lot of problems for distros in a good enough way (frankly, currently in a way that is better than any existing alternative) that they are happy to have systemd deal with those issues while they focus on the stuff the distro makers are interested in.
What is desireable to a distro maintainer is offten not what is desireable to a user or admin. Systemd favors the distro maintainer and cloud application service provider, and maybe the appliance manufacturer. It's the exact opposite of a useful tool empowering the the individual.
Sad Gentoo didn't get more mention. Been using that w/OpenRC since before systemd existed and it's still my solid daily driver.
I realize that Gentoo became a meme at some point, but it also seems that it might have transcended to the level of infrastructure. Thus, you rarely ever heard about it for the same reason you don't hear people talk about hammers -- it is doing its job running tens (hundreds?) of millions of chrome books among other things.
No flare, nothing fancy, it has solved a whole bunch of packaging, deployment, and environment control problems and gotten out of the way of its users (mostly ... chuckle), and it did it all with a pile of bash scripts and a little python here and there. Want to use systemd because you have a use case that would benefit from it? Go right ahead! The engineering work is done, no need for fights on the mailing list. Don't want to use systemd? `eudev` to the rescue! There are sound engineering reasons for not using systemd while also wanting to use some other (seemingly) completely unrelated piece of software that just happens to have a dependency on the kitchen sink.
Despite being a rolling release distribution, I find that the UX and workflows are more stable over long periods of time than any of the more popular LTS style distros. When I started fiddling with Ubuntu so that I could help my colleagues debug issues it took me an embarrassingly long time to realize that there isn't really such a thing as Ubuntu, just 14.04, 16.04, 18.04, etc. Each is some different form the other that stack overflow questions from one LTS are often simply wrong for another.
Writing this I wonder whether rolling release distros aren't effectively the original form of chaos engineering -- if everything is going to be changing all the time then it forces the developers to solve a different and perhaps more fundamental set of problems and ultimately leads to greater stability in the long run.
Android - anyone? Android is linux, it's init is simple and the user experience obviously successful. There is a ton here for other distros to learn and improve on.
> and the user experience obviously successful That's... one point of view. Another is that Android is very successful at content consumption while falling short at more complex workflows, possessing a remarkably fragmented ecosystem, failing to deliver security updates to most of its users in a reasonable timeframe if at all, and possessing little to no flexibility at the lower layers (ex. supporting BTRFS or ZFS).
No shit, it's a telephone OS. I'm pretty sure 'complex workflows' weren't one of the design goals for Android - nearly everyone has devices much more suited to that task.
Maybe I'm just out of the loop but what is the controversy regarding systemd?
The latest round of controversy is probably because They're pushing the new 'homed' component, which is supposed to change up how home directories (and user accounts) are managed. It's supposed to enable easier encryption of home directories, but breaks ssh logins. Therefore it's probably only suitable for multi-user systems (which need to protect home directoried from other users) that are also never accessed remote…
Earlier quoted context omitted.
If the issue is a single module take over of userspace then I have good news for you. The systemd project is made up of multiple modules handling differing tasks not all of which you have to use.
Modules which only work with their own other modules and fail to work with other people's modules aren't modules, they're a monolith.
Earlier quoted context omitted.
The linux world is busy getting shit done. Ignore the children arguing over init systems.
It's rarely the adult in the room who calls other people names like children.
Or,
Unlike children, who call other people names, the adult in the room rarely does?
Earlier quoted context omitted.
The linux world is busy getting shit done. Ignore the children arguing over init systems.
The argument is not about the init system. systemd’s is probably fine. It’s about an ever expanding take-over of userspace by a single module, which is not the Unix way. And about a high-handed project leader who is paid by Redhat to do it full time.
You confuse Systemd the init system with Systemd the project.
The Systemd project can be described as "GNU coreutils but for low-level system components". People hear about all the tools that the Systemd project maintains and think that all that functionality is built into the init system, when the reality it's >50 separate binaries, the majority of which (like systemd-boot or systemd-resolved) are completely optional and aren't even installed by most distributions.
And while I understand that some parts, like journald, are not so independent - it's still not "a single module" in a way that prevents it from being unix-y. The Unix philosophy is about separation of concerns, not having a bunch of interchangable options for low-level system components.
Earlier quoted context omitted.
The argument is not about the init system. systemd’s is probably fine. It’s about an ever expanding take-over of userspace by a single module, which is not the Unix way. And about a high-handed project leader who is paid by Redhat to do it full time.
Agreed 100%. Systemd is a pretty good init system IMO. Service files are good, timers are good, dependency-based init is good. Easy sandboxing is nice. I absolutely _don't_ think that my init system should also be my bootloader. It also shouldn't manage my network configuration, or be responsible for controlling the system clock. And it shouldn't assert control of my home folders. And it shouldn't be spidering its wa…
Good thing it's not?
systemd-boot is an entirely different binary, it's not even installed by default by any large distro I know of. The only commonality between them is that they are developed under the same broad project umbrella, just like "cp" and "ls" and "cat" are all part of the GNU coreutils umbrella.
This is a theme for an entire class of incorrect complaints about systemd -- the misconception that just because a tool is called systemd-$thing means it's part of the systemd init system, rather than "a tool developed by the systemd project".