One thing I've realized about the Linux community through all this systemd flame warring is how unbelievably conservative a large subsection of it is. There's this huge so-called "neckbeard" continent that views anything architecturally beyond the 1980s as a huge affront to Unix. IMHO I kind of shrug at this, since Unix was never really all that great to begin with. Unix won because the only commercially viable and w…
People who aren't extremely familiar with how the Linux init system works and whose job doesn't include keeping the servers stable don't see why the neckbeards are up in arms about systemd, but there's good reason. Many peoples' jobs depends on making sure the servers are working, and knowing how the servers work is a big part of their job (and sanity). In its current incarnation, systemd changes the fundamentals of…
Systemd redux: The end of Linux
21–30 of 464 posts
Re: Systemd redux: The end of Linux
#22One thing I've realized about the Linux community through all this systemd flame warring is how unbelievably conservative a large subsection of it is. There's this huge so-called "neckbeard" continent that views anything architecturally beyond the 1980s as a huge affront to Unix. IMHO I kind of shrug at this, since Unix was never really all that great to begin with. Unix won because the only commercially viable and w…
But lets say you are building a highly specialized application. You are going to be making quite a few customizations which are far more manageable through a shell scripting environment than by customizing a bunch of binaries.
I assume that Redhat is going to cover a lot of the bases for most users out there. But for those of us in highly customized environments it's going to suck.
Re: Systemd redux: The end of Linux
#23Re: Systemd redux: The end of Linux
#24Can someone put in Layman's terms what the change entails and why it would be the end of Linux?
All Unix-based systems start by running a single process known as 'init' which is responsible for setting up the system, starting all other programs, and managing various services as they run. The change under contention is the widespread inclusion of a relatively new piece of software called systemd, which replaces the historically popular sysvinit, Ubuntu's alternative known as upstart, and various other competing systems. All of these are different approaches to building an init system.
In contrast to some of the other systems, systemd is written less in terms of traditional Unix-style tools (like pipes and plain text files for storage), choosing instead to build on newer and more elaborate communication interfaces and store in specially designed binary formats. Systemd consists of a large family of interrelated pieces of software, many of which are nominally optional but generally expect to be used together. One point of contention is whether systemd is "too large", as proponents argue that developing these pieces together will increase their quality, while detractors argue that this makes it too difficult to substitute components if necessary and that these pieces should not be part of the same conceptual package.
Additionally, the architectural choices of a large, widely-used package integral to the functioning of a running system will influence the design and assumptions of other pieces of software and even Linux itself. Already, the Linux kernel has incorporated the newer communication systems used by systemd into the operating system itself (the mentioned KDBus), which many believe to be a sign that the inclusion of systemd will change the way that Linux operates and the way programs expect to interact with the kernel and with each other.
An important factor here, whether good or bad, is that these choices make Linux into a very different system than it has been historically, and very different than other Unix variants. Proponents argue that this is a step forward, as the facilities offered by Linux historically might not be appropriate tools for the current uses of Linux. Detractors disagree. Either way, the conclusion is that systemd is a change in the way the operating system is structured and used which has been a major point of contention in some communities.
Re: Systemd redux: The end of Linux
#25Everything I read about SystemD is negative. Negative on the technology, negative on the people who created it. Nothing positive. How is it that SystemD is about to dominate the market? Who is driving SystemD adoption, and why?
It hinges upon the fact that people are more likely to be vocal when they don't like something than when they do. Consider online reviews: are you more likely to review a product when it's worked fine as you expected or when it died a month after you got it? systemd has both good aspects (e.g. faster boot times and removal of the nasty nest of shell scripts) as well as bad ones (incredibly monolithic). There are argu…
What one person finds nasty another may find sexy.
Re: Systemd redux: The end of Linux
#26One thing I've realized about the Linux community through all this systemd flame warring is how unbelievably conservative a large subsection of it is. There's this huge so-called "neckbeard" continent that views anything architecturally beyond the 1980s as a huge affront to Unix. IMHO I kind of shrug at this, since Unix was never really all that great to begin with. Unix won because the only commercially viable and w…
If you want to see the ultimate extent of this, look at the Wii and Wii U. Each game ships with an "IOS": effectively an OS kernel+initrd update package. Every game boots to the newest IOS available, so if one game updates to IOS v6653, then another game that only shipped with IOS v6652 will find the newer version on disk and use it.
However, a game's IOS requirement doesn't just have a version; it also has a slot. Each console has space for 256 individual copies of IOS, which are each independently versioned. So if two games both use IOS[58], then the game providing v6653 will overwrite v6652 on disk, and then the game providing v6652 will boot into v6653. But if one game is providing a version of IOS[58], and the other is providing a version of IOS[61], then their effects on one-another are isolated.
You can think of it a bit like the IOS codebase having 256 branches, and each piece of software being able to specify which branch of the kernel it was developed on. It gets the newest kernel released on that branch.
This allows a sort of "move fast and break things" approach to kernel development, where a kernel can be hacked to support new software in a way that breaks old software: you just stick your modified kernel into an as-yet-unused IOS slot, and old software will have nothing to worry about. This approach has resulted in my own (pretty unused) Wii U having ~73 different IOS slots populated with kernels.
Interestingly, if you think about it, this is pretty much a continuation of what Nintendo was allowing developers to do before: shipping random collections of chips in their own cartridges that DMA to the console, effectively creating their own extended console to run upon. Allowing your software to ship its own kernel is basically the software equivalent.
Re: Systemd redux: The end of Linux
#27One thing I've realized about the Linux community through all this systemd flame warring is how unbelievably conservative a large subsection of it is. There's this huge so-called "neckbeard" continent that views anything architecturally beyond the 1980s as a huge affront to Unix. IMHO I kind of shrug at this, since Unix was never really all that great to begin with. Unix won because the only commercially viable and w…
Well, here's the basic deal. If we're talking about common servers, common desktop, etc then systemd is an excellent replacement. It covers the base of users quite well. But lets say you are building a highly specialized application. You are going to be making quite a few customizations which are far more manageable through a shell scripting environment than by customizing a bunch of binaries. I assume that Redhat is…
Re: Systemd redux: The end of Linux
#28It has been said before, but it deserves mention, there are alternatives to Systemd out there, like OpenRC which has been around for a while, and other, newer projects like Uselessd. Of course, whether those other options will be as well supported and developed as systemd remains to be seen.
http://blogs.gnome.org/ovitters/2013/09/25/gnome-and-loginds...
Re: Systemd redux: The end of Linux
#29Earlier quoted context omitted.
It hinges upon the fact that people are more likely to be vocal when they don't like something than when they do. Consider online reviews: are you more likely to review a product when it's worked fine as you expected or when it died a month after you got it? systemd has both good aspects (e.g. faster boot times and removal of the nasty nest of shell scripts) as well as bad ones (incredibly monolithic). There are argu…
"removal of the nasty nest of shell scripts" What one person finds nasty another may find sexy.
Re: Systemd redux: The end of Linux
#30Now im not saying that i like systemd in general - for the reasons the author explains I don't really like it. Systemd could have been way better if it wasnt for the political shit and attempts to take control over distros, kernel, etc.
That said it has some features I do like. Likewise for kdbus. This is like Chrome vs Firefox. People would like to support Firefox better. But Chrome and Google apps do enough of what they want right now to go with the solution they don't really approve of - I'll say it again: it works.