5 ms·

The dispute here is philosophical. You want a distribution that follows The Unix Way. Where init does its little job and dbus does its little job and so on. Sma

The dispute here is philosophical. You want a distribution that follows The Unix Way. Where init does its little job and dbus does its little job and so on. Small, simple tools. But there is another way. A way that believes that when you unite the core tools into one powerful process you can do cool things. These cool things have been proven, from the basics like faster boot times, to more advanced features like saving/restoring random seeds, automount, SELinix integration, and so on. You are arguing "this isn't Unix!!!" but that is the whole point. You can win an argument with a mountain climber by pointing out he is going downhill, but not a skier; since for a skier, going downhill is the point. These Linux distributions are not temporarily disoriented mountain climbers accidentally heading away from Mt. Unix. They are deliberately skiing away from it at a high rate of speed. What they will find at the bottom of the slope is an interesting question, but simply pointing out that their strategy is bad for mountain climbing is neither here nor there. What I am saying is, if you want to run an OS that believes in the Unix Philosophy, the shortest path is to install Unix. You are going to have about as much luck convincing Fedora that they ought to be Unix as you would convincing Redmond.

nailer 13y ago
There's also a huge amount of redundancy inside, and between: - SysVinit - xinetd - atd - crond - supervisor - syslogd and the other things systemd replaces. 'Small, single purpose tools' is Unix philosophy. But DRY is engineering philosophy. Each repeated piece of logic doubles the scope for errors. One could also argue that 'doing one thing well' is handling services.
- pipy 13y ago
  Systemd is controlled by Red Hat in a way in which critical system components including kernel haven't been controlled before. Not by single corporate entity. That's what we know about this company from an old (2007) article: > “When we rolled into Baghdad, we did it using open > source,” General Justice continued. “It may come as a > surprise to many of you, but the U.S. Army is “the” single > largest install base for Red Hat Linux. I'm their largest customer.” [1] It is better to go with a grass-roots solution, even the one technically inferior, that isn't being influenced by one single vendor or government (especially the one that has a tendency to indiscriminately infect other people's systems [2]). Also, the Interface Stability Promise [3] by systemd team is just a promise, nothing more. Will Red Hat keep it if it is to decide at some point, that it no longer serves it's bottom line? I wonder if it can be considered legally binding. [1] http://archive09.linux.com/feed/61302 http://archive09.linux.com/feed/61302 [2] https://www.youtube.com/watch?v=vILAlhwUgIU https://www.youtube.com/watch?v=vILAlhwUgIU [3] http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/ http://www.freedesktop.org/wiki/Software/systemd/InterfaceSt... Originally posted in this thread: https://news.ycombinator.com/item?id=7210064 https://news.ycombinator.com/item?id=7210064
  - Tuna-Fish 13y ago
    You do understand that systemd is open source, right? If they decide to leverage their "control" into something the rest of the community doesn't like, we fork it.
    - pipy 13y ago
      > If they decide to leverage their "control" into something the rest of the community doesn't like, we fork it. I hope so. My concern is that when we'll see systemd grow in size and more and more software depend on it's interfaces and components (as in GNOME with logind) at the certain point it could take an insurmountable amount of resources to maintain the fork. At this point it might be easier to give up on Linux and build around some other kernel and userland, I hope this will never happen, though. Also, there is a difference between steering the developments in the preferred direction and outright destructive actions. As in https://en.wikipedia.org/wiki/Boiling_frog https://en.wikipedia.org/wiki/Boiling_frog.
  - nailer 13y ago
    Interesting. Most of my work with Systemd has been via CoreOS, which is linked to GregKH, who was actually a SuSE dude.
- jude- 13y ago
  > There's also a huge amount of redundancy inside, and between, SysVinit, atd, crond, supervisor, syslogd and the other things systemd replaces. Such as? I'm pretty sure code shared between these systems lives in (or could easily be moved to) shared libraries, specifically to avoid this problem. But this is orthogonal to the design of the init system. > But DRY is engineering philosophy. Each repeated piece of logic doubles the scope for errors. While DRY is a great engineering principle within the scope of a single project, it doesn't justify excluding alternative implementations or entangling unrelated concerns. Specifically, DRY is not an excuse to forbid competing init system implementations, even though having more than one creates code redundancy. Moreover, "doubling the scope for errors" is meaningless from the user's perspective in the context of init systems: if there are X errors in systemd and Y errors in OpenRC, I will not be plagued by X+Y errors because I will only be running one of them at a time. > One could also argue that 'doing one thing well' is handling services. Ah, but "handling services" is not a well-defined task. To some, it means doing something like what sysvinit does--reaping orphaned processes and nothing more. To others, it means doing something like what systemd does--not only managing processes, but also managing devices, sessions, storage, power management, cgroups, system IPC, and network interfaces (and possibly more in the future).
  - Tuna-Fish 13y ago
    > Specifically, DRY is not an excuse to forbid competing init system implementations No-one is forbidding anything. You can run Debian with any init you choose. All we ("systemd proponents") want is that when upstream software decides to depend on something systemd provides, the debian maintainers don't have to (they can, if they feel like it) bend over backwards to replicate all systemd features for non-systemd platforms. Not demanding unpaid volunteers to do extra work is not the same thing as forbidding other init systems.
    - jude- 13y ago
      > You can run Debian with any init you choose. When layers above the init system begin to make hard dependencies on it, this will be unavoidable in practice. This is the problem, since it either takes away my choice in init system, or requires unpaid volunteers to work on removing the dependency. Neither is desirable, and the grandparent's argument is that this could all have been avoided if the systemd developers had made better design choices. Don't get me wrong, I want systemd to be an option. I like the idea of using cgroups to manage services. I do it every day. What I do not want, however, is for systemd to be a requirement for having a working system.
mjn 13y ago
In userspace the Unix way is about disconnected utilities connected by pipes, but that hasn't been uniformly true at more of the "system" level (well, GNU did originally have that philosophy all the way through, even down to the kernel, but most Unixen haven't). The BSDs, for example, generally pride themselves on tighter coupling in the core OS than Linux has traditionally had. You can swap out some components from a default FreeBSD install, mostly more application-level ones (sendmail->postfix, clang->gcc), but the base system is integrated and does things one way, supporting some customization but not every kind of wholesale surgery you might want to do on it. You certainly can't swap out the init system for another one in any kind of supported way. The same is pretty much true of most other Unixen, such as Solaris (which has a pretty integrated init system, too). I generally like the utilities+pipes model, but for system stuff it's seemed like false advertising to me for a long time anyway: the Linux kernel is monolithic, and many of its features (like cgroups) don't make much sense unless you have some userspace counterpart configuring/arbitrating them and a uniform way of making sure everything gets set up consistently. Traditionally this is handled by a tangle of shell scripts with distribution-specific conventions to make sure they don't step on each other's feet (Debian has piles of this in Debian policy). That's a unified system in practice, because you can't really arbitrarily rewrite the init/configure/reconfigure scripts or swap things out and still have a working system that is Debian-integrated. The scripts are literally separate files on disk, but in practice they're a spaghetti-code implementation of Debian Configuration, a monolithic system that handles initialization and services and package configuration and can't be modified without extreme care if you want things to keep working in the way all the other packages (and apt, dpkg-reconfigure, the diversions system, etc.) expect.
pdkl95 13y ago
I would generally agree with this. This philosophy (along with it being Free Software) is why I chose to migrate to Linux in the first place, so long ago: it was Unix. Ya, ya, "Unix-like", technically, due to the trademark on Unix. That last statement is very strange: > Fedora that they ought to be Unix As somebody who wore an authentic Red Hat fedora for many years, this makes no sense. They've certainly called themselves a unix (in the generic, no trademark), and alternative to Unix (tm, aka Solaris, HP-UX, and others derived from Bell Labs IP) http://www.redhat.com/solutions/migration/migrate-from-unix-platforms/ http://www.redhat.com/solutions/migration/migrate-from-unix-... Wikipedia, on fedora: "OS family: Unix-like" etc When the term "Linux" is used in general, we mean a unix. The distinction has only ever a trademark thing. So yes, refugees from Windows coming over to distros that have always been unix(-like) and trying to change them into the some sort of Windows-like junk is a problem. Some of us left that world of bad design little choice a long time ago, and have no intention of returning.
- coldtea 13y ago
  >When the term "Linux" is used in general, we mean a unix. The distinction has only ever a trademark thing. Not really. The implementation of the kernel, userland features etc are quite different between traditional derived unices and Linux. But it sure is a full blown POSIX.
- TheCondor 13y ago
  Modern Linux distributions don't tend to honor "The UNIX philosophy" is a common theme these days, or so it is said by a vocal group. The GNU tools tend to be more feature rich then many of their counterparts, often with performance advantages and usability but more is more and more code tends to mean more bugs. Fedora is in many ways the leader of this, it and Ubuntu are symbolic to those folks. The irony here is that they can go fork all of this stuff, it's not like none of it has forked before, if they don't like redhat they can run something else. Getting passed off and forking is also the UNIX way
- drewcrawford 13y ago
  > They've certainly called themselves a unix (in the generic, no trademark), At one point, they probably were a Unix. But Unix as a place and Unix as a goal are two very different things. Both skiers and mountainclimbers find themselves at the tops of mountains. > When the term "Linux" is used in general, we mean a unix. You mean a Unix. I mean Linux. There is no "we". > So yes, refugees from Windows coming over to distros that have always been unix(-like) and trying to change them into the some sort of Windows-like junk is a problem. I don't believe you. Where are these vanguard Unix-style Linux distros? RHEL? Adopting systemd. Debian? Adopting systemd. SUSE? Adopting systemd. These are distributions from the days of old. They have formed a consensus that systemd-style Linux is the future. I mean I think it is fair to say that the Linux community is divided on this issue. But characterizing the systemd/dbus/ufs folks as "Windows refugees" is totally inaccurate. Systemd has the backing of important community members of the Linux community.
coldtea 13y ago
>You are arguing "this isn't Unix!!!" but that is the whole point. You can win an argument with a mountain climber by pointing out he is going downhill, but not a skier; since for a skier, going downhill is the point. Besides Linux is not UNIX either. And it's 2014 already, we found that some UNIX choices (like "don't dictate policy" in X Server were bad) and others led to underpowered tools. It's not like we're still on text terminals, running 2-3 daemons at most, each with simple needs, and most of our work is constrained in the textual domain.
- falcolas 13y ago
  You just described both my development environment, and my production environment. Neither needs an overly complicated init system to work.
  - matt__rose 13y ago
    Really. You develop on the equivalent of a VT100 terminal? You don't use a web browser, or Xwindows, just a tty? Are you sure about that?
sparkie 13y ago
"The Unix Philosophy" is what everyone outside of Unix calls good software design. Using modular, decoupled components is standard industry practice for most developers with just a few years of experience, and these practices have evolved from half a century of engineering experience, such that we know how not to do things, even if there's no right way. You wouldn't make a "god object" in C++ or Java for example, and nor would you tightly couple every class in your OOP system by refusing to provide abstraction boundaries. Well, you might do if you're strapped for time, but you would probably consider it a "hack" that needs amending. That's how some people see systemd, as a hack. It's tightly coupled to the kernel it sits on, and it's a leaky abstraction that exposes much of that to userland processes that depend on the systemd api. In turn, those applications are (or will be) tightly coupled to linux.

nailer 13y ago

There's also a huge amount of redundancy inside, and between: - SysVinit - xinetd - atd - crond - supervisor - syslogd and the other things systemd replaces. 'Small, single purpose tools' is Unix philosophy. But DRY is engineering philosophy. Each repeated piece of logic doubles the scope for errors. One could also argue that 'doing one thing well' is handling services.

pipy 13y ago
Systemd is controlled by Red Hat in a way in which critical system components including kernel haven't been controlled before. Not by single corporate entity. That's what we know about this company from an old (2007) article: > “When we rolled into Baghdad, we did it using open > source,” General Justice continued. “It may come as a > surprise to many of you, but the U.S. Army is “the” single > largest install base for Red Hat Linux. I'm their largest customer.” [1] It is better to go with a grass-roots solution, even the one technically inferior, that isn't being influenced by one single vendor or government (especially the one that has a tendency to indiscriminately infect other people's systems [2]). Also, the Interface Stability Promise [3] by systemd team is just a promise, nothing more. Will Red Hat keep it if it is to decide at some point, that it no longer serves it's bottom line? I wonder if it can be considered legally binding. [1] http://archive09.linux.com/feed/61302 http://archive09.linux.com/feed/61302 [2] https://www.youtube.com/watch?v=vILAlhwUgIU https://www.youtube.com/watch?v=vILAlhwUgIU [3] http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/ http://www.freedesktop.org/wiki/Software/systemd/InterfaceSt... Originally posted in this thread: https://news.ycombinator.com/item?id=7210064 https://news.ycombinator.com/item?id=7210064
- Tuna-Fish 13y ago
  You do understand that systemd is open source, right? If they decide to leverage their "control" into something the rest of the community doesn't like, we fork it.
  - pipy 13y ago
    > If they decide to leverage their "control" into something the rest of the community doesn't like, we fork it. I hope so. My concern is that when we'll see systemd grow in size and more and more software depend on it's interfaces and components (as in GNOME with logind) at the certain point it could take an insurmountable amount of resources to maintain the fork. At this point it might be easier to give up on Linux and build around some other kernel and userland, I hope this will never happen, though. Also, there is a difference between steering the developments in the preferred direction and outright destructive actions. As in https://en.wikipedia.org/wiki/Boiling_frog https://en.wikipedia.org/wiki/Boiling_frog.
- nailer 13y ago
  Interesting. Most of my work with Systemd has been via CoreOS, which is linked to GregKH, who was actually a SuSE dude.
jude- 13y ago
> There's also a huge amount of redundancy inside, and between, SysVinit, atd, crond, supervisor, syslogd and the other things systemd replaces. Such as? I'm pretty sure code shared between these systems lives in (or could easily be moved to) shared libraries, specifically to avoid this problem. But this is orthogonal to the design of the init system. > But DRY is engineering philosophy. Each repeated piece of logic doubles the scope for errors. While DRY is a great engineering principle within the scope of a single project, it doesn't justify excluding alternative implementations or entangling unrelated concerns. Specifically, DRY is not an excuse to forbid competing init system implementations, even though having more than one creates code redundancy. Moreover, "doubling the scope for errors" is meaningless from the user's perspective in the context of init systems: if there are X errors in systemd and Y errors in OpenRC, I will not be plagued by X+Y errors because I will only be running one of them at a time. > One could also argue that 'doing one thing well' is handling services. Ah, but "handling services" is not a well-defined task. To some, it means doing something like what sysvinit does--reaping orphaned processes and nothing more. To others, it means doing something like what systemd does--not only managing processes, but also managing devices, sessions, storage, power management, cgroups, system IPC, and network interfaces (and possibly more in the future).
- Tuna-Fish 13y ago
  > Specifically, DRY is not an excuse to forbid competing init system implementations No-one is forbidding anything. You can run Debian with any init you choose. All we ("systemd proponents") want is that when upstream software decides to depend on something systemd provides, the debian maintainers don't have to (they can, if they feel like it) bend over backwards to replicate all systemd features for non-systemd platforms. Not demanding unpaid volunteers to do extra work is not the same thing as forbidding other init systems.
  - jude- 13y ago
    > You can run Debian with any init you choose. When layers above the init system begin to make hard dependencies on it, this will be unavoidable in practice. This is the problem, since it either takes away my choice in init system, or requires unpaid volunteers to work on removing the dependency. Neither is desirable, and the grandparent's argument is that this could all have been avoided if the systemd developers had made better design choices. Don't get me wrong, I want systemd to be an option. I like the idea of using cgroups to manage services. I do it every day. What I do not want, however, is for systemd to be a requirement for having a working system.

mjn 13y ago

In userspace the Unix way is about disconnected utilities connected by pipes, but that hasn't been uniformly true at more of the "system" level (well, GNU did originally have that philosophy all the way through, even down to the kernel, but most Unixen haven't). The BSDs, for example, generally pride themselves on tighter coupling in the core OS than Linux has traditionally had. You can swap out some components from a default FreeBSD install, mostly more application-level ones (sendmail->postfix, clang->gcc), but the base system is integrated and does things one way, supporting some customization but not every kind of wholesale surgery you might want to do on it. You certainly can't swap out the init system for another one in any kind of supported way. The same is pretty much true of most other Unixen, such as Solaris (which has a pretty integrated init system, too). I generally like the utilities+pipes model, but for system stuff it's seemed like false advertising to me for a long time anyway: the Linux kernel is monolithic, and many of its features (like cgroups) don't make much sense unless you have some userspace counterpart configuring/arbitrating them and a uniform way of making sure everything gets set up consistently. Traditionally this is handled by a tangle of shell scripts with distribution-specific conventions to make sure they don't step on each other's feet (Debian has piles of this in Debian policy). That's a unified system in practice, because you can't really arbitrarily rewrite the init/configure/reconfigure scripts or swap things out and still have a working system that is Debian-integrated. The scripts are literally separate files on disk, but in practice they're a spaghetti-code implementation of Debian Configuration, a monolithic system that handles initialization and services and package configuration and can't be modified without extreme care if you want things to keep working in the way all the other packages (and apt, dpkg-reconfigure, the diversions system, etc.) expect.

pdkl95 13y ago

I would generally agree with this. This philosophy (along with it being Free Software) is why I chose to migrate to Linux in the first place, so long ago: it was Unix. Ya, ya, "Unix-like", technically, due to the trademark on Unix. That last statement is very strange: > Fedora that they ought to be Unix As somebody who wore an authentic Red Hat fedora for many years, this makes no sense. They've certainly called themselves a unix (in the generic, no trademark), and alternative to Unix (tm, aka Solaris, HP-UX, and others derived from Bell Labs IP) http://www.redhat.com/solutions/migration/migrate-from-unix-platforms/ http://www.redhat.com/solutions/migration/migrate-from-unix-... Wikipedia, on fedora: "OS family: Unix-like" etc When the term "Linux" is used in general, we mean a unix. The distinction has only ever a trademark thing. So yes, refugees from Windows coming over to distros that have always been unix(-like) and trying to change them into the some sort of Windows-like junk is a problem. Some of us left that world of bad design little choice a long time ago, and have no intention of returning.

coldtea 13y ago
>When the term "Linux" is used in general, we mean a unix. The distinction has only ever a trademark thing. Not really. The implementation of the kernel, userland features etc are quite different between traditional derived unices and Linux. But it sure is a full blown POSIX.
TheCondor 13y ago
Modern Linux distributions don't tend to honor "The UNIX philosophy" is a common theme these days, or so it is said by a vocal group. The GNU tools tend to be more feature rich then many of their counterparts, often with performance advantages and usability but more is more and more code tends to mean more bugs. Fedora is in many ways the leader of this, it and Ubuntu are symbolic to those folks. The irony here is that they can go fork all of this stuff, it's not like none of it has forked before, if they don't like redhat they can run something else. Getting passed off and forking is also the UNIX way
drewcrawford 13y ago
> They've certainly called themselves a unix (in the generic, no trademark), At one point, they probably were a Unix. But Unix as a place and Unix as a goal are two very different things. Both skiers and mountainclimbers find themselves at the tops of mountains. > When the term "Linux" is used in general, we mean a unix. You mean a Unix. I mean Linux. There is no "we". > So yes, refugees from Windows coming over to distros that have always been unix(-like) and trying to change them into the some sort of Windows-like junk is a problem. I don't believe you. Where are these vanguard Unix-style Linux distros? RHEL? Adopting systemd. Debian? Adopting systemd. SUSE? Adopting systemd. These are distributions from the days of old. They have formed a consensus that systemd-style Linux is the future. I mean I think it is fair to say that the Linux community is divided on this issue. But characterizing the systemd/dbus/ufs folks as "Windows refugees" is totally inaccurate. Systemd has the backing of important community members of the Linux community.

coldtea 13y ago

>You are arguing "this isn't Unix!!!" but that is the whole point. You can win an argument with a mountain climber by pointing out he is going downhill, but not a skier; since for a skier, going downhill is the point. Besides Linux is not UNIX either. And it's 2014 already, we found that some UNIX choices (like "don't dictate policy" in X Server were bad) and others led to underpowered tools. It's not like we're still on text terminals, running 2-3 daemons at most, each with simple needs, and most of our work is constrained in the textual domain.

falcolas 13y ago
You just described both my development environment, and my production environment. Neither needs an overly complicated init system to work.
- matt__rose 13y ago
  Really. You develop on the equivalent of a VT100 terminal? You don't use a web browser, or Xwindows, just a tty? Are you sure about that?

sparkie 13y ago

"The Unix Philosophy" is what everyone outside of Unix calls good software design. Using modular, decoupled components is standard industry practice for most developers with just a few years of experience, and these practices have evolved from half a century of engineering experience, such that we know how not to do things, even if there's no right way. You wouldn't make a "god object" in C++ or Java for example, and nor would you tightly couple every class in your OOP system by refusing to provide abstraction boundaries. Well, you might do if you're strapped for time, but you would probably consider it a "hack" that needs amending. That's how some people see systemd, as a hack. It's tightly coupled to the kernel it sits on, and it's a leaky abstraction that exposes much of that to userland processes that depend on the systemd api. In turn, those applications are (or will be) tightly coupled to linux.