71–80 of 102 posts
Earlier quoted context omitted.
Most people now didn't adopt Linux to get away from something, its just the default server OS. (And not desktop).
I think mostly people adopted Linux to get away from paying a lot of per-seat license fees for everything, and to get away from having to buy some vendor's medium iron hardware rather than just using commodity x86 chips.
Assuming that everything the author says turns out true - such as the "big one" exploit - in say an year from now, does anybody know any active popular open source distro that aims to keep systemd away from servers?
Assuming that everything the author says turns out true - such as the "big one" exploit - in say an year from now, does anybody know any active popular open source distro that aims to keep systemd away from servers?
Slackware, CRUX, Funtoo and Gentoo are some distros that follow traditional Unix paradigms and unlikely to adopt systemd.
So... none? Unintegrated desktop linux is painful, and the fixes for it so far have mostly been hacks. Systemd actually attempts to create some kind of modern cohesive system which is a good thing. Maybe you don't see the downsides to the lack of integration because you're just used to putting up with them.
I don't agree with everything he says (the invasion of desktop linux seems completely unsubstantiated) but there are a couple of problems he points out that worry me, and I think we should pay attention. Maturity: it certainly feels rushed that in less than four years systemd went from nothing to the default init system in most Linux distributions (if I'm not mistaken). For something so basic and important you'd thin…
Maturity should not be confused with age. There is certainly positive correlation between the two, but it's not necessarily that strong. A piece of software that has been around for four years and been used by everybody will be more mature than software that has been around for ten but was only used by a small community.
There is also a chicken-and-egg problem here: software needs get widely adopted _before_ it can become mature.
Earlier quoted context omitted.
You're not serious right? MacOS is very much a tightly integrated system.
Mac OS's architecture is totally unlike systemd. Areas of responsibility are implemented by standalone mechanisms that compose to create the larger integrated system and can: 1) Run in isolation from their upstream dependents. 2) Be replaced individually.
And seriously, systemd isn't one single daemon either. It's a collection of daemons running that communicate over a common protocol. It isn't all-or-nothing, either. Only a few of the daemons are considered "core" and the rest are optional. And, because they use a common documented protocol, even the core components can be replaced. You don't hear about alternatives because nobody has really written any, but it doesn't in any way prevent you from doing it.
I think the legitimate concerns about systemd are things like losing portability of stuff like Gnome to BSD and systemd's short history, but it isn't one giant monolith executable or anything like people say.
Earlier quoted context omitted.
You're not serious right? MacOS is very much a tightly integrated system.
Mac OS's architecture is totally unlike systemd. Areas of responsibility are implemented by standalone mechanisms that compose to create the larger integrated system and can: 1) Run in isolation from their upstream dependents. 2) Be replaced individually.
Earlier quoted context omitted.
osx guy here. Yes and no. It's true that OSX uses a variety of separate daemons, that run in different pids. However they are all "required", "packaged together", "part of one source tree" and "shipped by a single vendor". In this respect they are a lot like systemd. In fact it is arguably a lot more integrated. Both Python and Ruby are OSX dependencies. systemd isn't even close to that much of a power-grab.
GNU/Linux requires vi, perl, python... also as dependencies, but they're separate programs, the thing with systemd is that nothing can be separated, you use ALL components at the same time or change OS. Bear in mind that systemd is being integrated with the Linux kernel, so you have to update the kernel in sync with systemd.
Do you have a source for this or is it FUD?
Earlier quoted context omitted.
osx guy here. Yes and no. It's true that OSX uses a variety of separate daemons, that run in different pids. However they are all "required", "packaged together", "part of one source tree" and "shipped by a single vendor". In this respect they are a lot like systemd. In fact it is arguably a lot more integrated. Both Python and Ruby are OSX dependencies. systemd isn't even close to that much of a power-grab.
GNU/Linux requires vi, perl, python... also as dependencies, but they're separate programs, the thing with systemd is that nothing can be separated, you use ALL components at the same time or change OS. Bear in mind that systemd is being integrated with the Linux kernel, so you have to update the kernel in sync with systemd.
I'm just feeding a troll or someone who is really ignorant, but here I go.
No it isn't, and no you don't. Systemd is closely tied to some Linux-specific features, but it generally isn't part of the kernel. And you don't have to update the kernel in sync with systemd. Systemd lives in userland, by definition.
It does impose a minimum kernel version in order for systemd to work, which is something like 2.6.39 (May 2011 vintage). They have bumped up the minimum version a couple times as they needed new features, but you don't have to upgrade both together. I routinely upgrade one or the other separately on multiple systems and distros.
And it bears repeating again... systemd is not one single executable or process. And not all of the components are required, you can turn all but a few core ones off. And the core ones could be replaced if you wanted to, because there's a documented interface that you can implement.
Also, Vi, Python and Perl aren't "required" for GNU/Linux. They're common, but definitely not required. Vi is required if you want to comply with the Single Unix standard, but that is not the same thing. GNU/Linux just refers to pairing the Linux kernel with GNU userspace utilities; it doesn't necessarily dictate any specifics. There are further standards like LSB that attempt to do so but again not relevant. On top of that, Vi, Python and Perl aren't even GNU projects, which is true of a ton of other programs common in Linux distros, which is one reason I personally find the term "GNU/Linux" a bit onerous.
As a user of linux on the desktop, I've never felt a moment of concern over the fact that it takes longer to boot than did Windows. I'm not sure who is panicked by this and I'm distressed that we would solve all of our problems with init by embracing systemd. If Gnome requires systemd, lets drop Gnome.
As a user of computers, I have never once felt that boot time was adequate for any device I have owned.
Boot times may be important for cloud instances, though; the faster you can spawn more nodes to accommodate a load spike, the better. But cloud instances are usually pretty stripped-down, and often get spawned form pre-configured images where much of the discoverable stuff is hardcoded.