5 ms·

I've found systemd to be fast and stable on Arch. There's a learning curve associated with a new way of doing old things. That doesn't bother me that much bec

by loudmax 13y ago

I've found systemd to be fast and stable on Arch. There's a learning curve associated with a new way of doing old things. That doesn't bother me that much because this is how progress happens. What I find far more disconcerting is that systemd seems to eschew core Unix philosophy (http://www.faqs.org/docs/artu/ch01s06.html http://www.faqs.org/docs/artu/ch01s06.html): This is the Unix 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. Systemd does none of these. Well, maybe it works with other programs... it really feels like it's own world.

hga 13y ago
That philosophy, which has many merits, was nonetheless a virtue forced by necessity. UNIX(TM) is Multics with, as the name implies, various important features ... omitted in squeezing down a big system, for a multiple 32 bit CPU mainframe architecture, to minicomputers. The first PDP-11 they used, which was not the first PDP model used, was the original, later named the PDP-11/20, which had 56KiB maximum of memory (above was reserved for memory mapped devices, an innovation of the architecture). The 2nd, where they really got going, was the PDP-11/45, which allowed any one program 64 KiB of code and the same of data, but due to its paging architecture the data was divided into 8 KiB of stack and 56 KiB for normal user data. So now that we use computers with as much or more L1 and L2 cache, we can, if warranted, ignore that philosophy. Don't know if that's the case here, the gravamen is that systemd's development team is grossly irresponsible. Which could be reflected in its architecture, but even if it was more in the traditional UNIX(TM) philosophy, their being that way would be as bad. I just hope the next version of Debian is not a disaster, would not like moving off of it, not that I'm entirely satisfied with it.
- killnine 13y ago
  So wait, some geniuses came along and banged out the OS of the future, in the smallest purest form they could, and now decades later, just because our computers have improved, you think it logical to ditch the philosophy that got us here???
  - peawee 13y ago
    More like "some geniuses came along and banged out an OS that would suit their needs on the limited hardware they had on hand"
    - felixgallo 13y ago
      The philosophy applies no matter how much hardware you have.
      - hga 13y ago
        Not going to directly reply to the reading comprehension impaired, but my point is that part of the philosophy was required. To print technical papers to a phototypesetter, one of the first use cases for which the UNIX project got serious funding, required a pipeline so that, as I remember, tables, equations and basic formatting were all separate programs piping their output to the next, with troff at the end (as I recall, I only used nroff in one step to a Xerox daisy wheel printer for one paper before I moved to Scribe and then TeX to a laser printer). No one single program doing all that could fit into the 11/45's split I&D address space as described above. Now we can and have made individual programs bigger, but the philosophies of doing a limited number of things well and communicating by plain text are still very solid for many applications (but, not, say, many of the use cases of Photoshop/GIMP etc. Or a browser. Or (in)famously, the linux kernel itself). How much they should apply to system initialization and daemon management etc. I just don't know, haven't examined the issue. Not entirely, I would hazard a guess, certainly nothing I can think of that looks like the chain ending in troff. That the creators of systemd are reported to have ignored this philosophy does not automatically make it bad. Their reported consistent bad behavior (from people I know and trust, at least in the case of Ted Ts'o) would seem to make it automatically problematical. That Linus felt compelled to revoke this person's kernel commit privileges (https://news.ycombinator.com/item?id=7522791 https://news.ycombinator.com/item?id=7522791) is also telling. Or let's put it this way: a program like systemd must, by definition, "play well with others", that's its job after all. That main developers can't do that in the real world is a very bad sign.
    - dredmorbius 13y ago
- dredmorbius 13y ago
  NB: Richie and Thompson did their development on the PDP-7, not the PDP-11, though the latter was an exceptionally popular system to run Unix on later (and was my first exposure to it). http://www.unix.org/what_is_unix/history_timeline.html http://www.unix.org/what_is_unix/history_timeline.html
  - hga 13y ago
    "The first PDP-11 they used, which was not the first PDP model used" The path, as I remember, was a side project sort of thing with that PDP-7, then they started getting real money for the project, first for a PDP-11(/20), then a PDP-11/45. Ah, I should point out that I think it wasn't until the PDP-11/45 that they could put a lot of memory on the whole system, with the kernel and each process potentially having the 64/56/8KiB code/data/stack address space. The total memory you could put on a PDP-11/20 was 57KiB, and while I don't know how much was on that PDP-7, Wikipedia says the total was 64Ki 18 bit words.
    - dredmorbius 13y ago
      Right. The history link I posted shows much of the early HW history. I posted my note just because your language wasn't quite clear. Though properly parsed, it makes sense ;-)
scrollaway 13y ago
There are excellent reasons to ignore the UNIX philosophy. "Do one thing and do it well" is fantastic and resonates a lot with us, programmers. The truth however is that this is not how an OS works. systemd does a lot of things because the systemd project is tackling a lot of issues on Linux. And as any of us will know and have experienced, when refactoring something it tends to be very cascading. So systemd has all these inter-dependencies with tools and concepts that the same developers worked on. systemd-logind, systemd-journal, systemd-networkd, kdbus, etc etc. Here's a fact: my systemd-powered machines have never worked so well and completely out of the box! These guys are doing amazing work, they are making Linux into a very, very serious competitor with today's desktop and mobile (incl laptop) machines. They are doing the dependencies too tightly, yes. They don't care enough about the possibility of other people reimplementing parts of what they do. But their actual achievements are incredible. I have a huge respect for what they do. That said... I have very little respect for them. The ability to separate a person from what they do seems to be a rare quality this way, despite what everyone claims (what with the Brendan Eich issue and such). The fucking attitude in these projects is disgusting. And these people don't actually understand that they are universally hated for behaving like children over such stupid issues. They live in a different world. And this is all just what you see externally. Internally, it's free-for-all retardfest... Fucking human nature, man. I've never been so uneasy as in the last few weeks... I can swear things used to be better but maybe I can just see things more clearly now.
- krick 13y ago
  I don't disagree with what you say, but it feels like a lot more important issue than you describe it. The whole systemd thing was intended to rewrite some pretty complex stuff that works already, but as it turned out over time does many things wrong. And do it right™ this time. Keywords: "rewrite", "already works", "right". And I personally believe it's a good idea, because what is done wrong at low level produces more and more work, complexity and errors on higher levels. Very hard to achieve, but essentially good. Now, the complex system with good API and architecture, but not-so-perfect internals is hard, but possible to fix and improve over time. System with bad API is essentially impossible to fix, ever. People that write optimal code without bugs, but terrible APIs and don't care about what others feel about that simply cannot "do it right™". Yeah, it may work well out of the box, but the progress goes on and after 5-10 years community will struggle to implement something new and important on top of that systemd and feel that only way to stop the pain is to replace it with some systemπ and do it right™, and people will remember 2014 year and say: "Well, we had that story with systemd already. It turned out to be no good! We'll make do without doing stuff right™." Thinking about it I feel sad regardless it may work smooth out of the box at the moment.

by loudmax 13y ago

hga 13y ago

That philosophy, which has many merits, was nonetheless a virtue forced by necessity. UNIX(TM) is Multics with, as the name implies, various important features ... omitted in squeezing down a big system, for a multiple 32 bit CPU mainframe architecture, to minicomputers. The first PDP-11 they used, which was not the first PDP model used, was the original, later named the PDP-11/20, which had 56KiB maximum of memory (above was reserved for memory mapped devices, an innovation of the architecture). The 2nd, where they really got going, was the PDP-11/45, which allowed any one program 64 KiB of code and the same of data, but due to its paging architecture the data was divided into 8 KiB of stack and 56 KiB for normal user data. So now that we use computers with as much or more L1 and L2 cache, we can, if warranted, ignore that philosophy. Don't know if that's the case here, the gravamen is that systemd's development team is grossly irresponsible. Which could be reflected in its architecture, but even if it was more in the traditional UNIX(TM) philosophy, their being that way would be as bad. I just hope the next version of Debian is not a disaster, would not like moving off of it, not that I'm entirely satisfied with it.

killnine 13y ago
So wait, some geniuses came along and banged out the OS of the future, in the smallest purest form they could, and now decades later, just because our computers have improved, you think it logical to ditch the philosophy that got us here???
- peawee 13y ago
  More like "some geniuses came along and banged out an OS that would suit their needs on the limited hardware they had on hand"
  - felixgallo 13y ago
    The philosophy applies no matter how much hardware you have.
    - hga 13y ago
      Not going to directly reply to the reading comprehension impaired, but my point is that part of the philosophy was required. To print technical papers to a phototypesetter, one of the first use cases for which the UNIX project got serious funding, required a pipeline so that, as I remember, tables, equations and basic formatting were all separate programs piping their output to the next, with troff at the end (as I recall, I only used nroff in one step to a Xerox daisy wheel printer for one paper before I moved to Scribe and then TeX to a laser printer). No one single program doing all that could fit into the 11/45's split I&D address space as described above. Now we can and have made individual programs bigger, but the philosophies of doing a limited number of things well and communicating by plain text are still very solid for many applications (but, not, say, many of the use cases of Photoshop/GIMP etc. Or a browser. Or (in)famously, the linux kernel itself). How much they should apply to system initialization and daemon management etc. I just don't know, haven't examined the issue. Not entirely, I would hazard a guess, certainly nothing I can think of that looks like the chain ending in troff. That the creators of systemd are reported to have ignored this philosophy does not automatically make it bad. Their reported consistent bad behavior (from people I know and trust, at least in the case of Ted Ts'o) would seem to make it automatically problematical. That Linus felt compelled to revoke this person's kernel commit privileges (https://news.ycombinator.com/item?id=7522791 https://news.ycombinator.com/item?id=7522791) is also telling. Or let's put it this way: a program like systemd must, by definition, "play well with others", that's its job after all. That main developers can't do that in the real world is a very bad sign.
  - dredmorbius 13y ago
dredmorbius 13y ago
NB: Richie and Thompson did their development on the PDP-7, not the PDP-11, though the latter was an exceptionally popular system to run Unix on later (and was my first exposure to it). http://www.unix.org/what_is_unix/history_timeline.html http://www.unix.org/what_is_unix/history_timeline.html
- hga 13y ago
  "The first PDP-11 they used, which was not the first PDP model used" The path, as I remember, was a side project sort of thing with that PDP-7, then they started getting real money for the project, first for a PDP-11(/20), then a PDP-11/45. Ah, I should point out that I think it wasn't until the PDP-11/45 that they could put a lot of memory on the whole system, with the kernel and each process potentially having the 64/56/8KiB code/data/stack address space. The total memory you could put on a PDP-11/20 was 57KiB, and while I don't know how much was on that PDP-7, Wikipedia says the total was 64Ki 18 bit words.
  - dredmorbius 13y ago
    Right. The history link I posted shows much of the early HW history. I posted my note just because your language wasn't quite clear. Though properly parsed, it makes sense ;-)

scrollaway 13y ago

There are excellent reasons to ignore the UNIX philosophy. "Do one thing and do it well" is fantastic and resonates a lot with us, programmers. The truth however is that this is not how an OS works. systemd does a lot of things because the systemd project is tackling a lot of issues on Linux. And as any of us will know and have experienced, when refactoring something it tends to be very cascading. So systemd has all these inter-dependencies with tools and concepts that the same developers worked on. systemd-logind, systemd-journal, systemd-networkd, kdbus, etc etc. Here's a fact: my systemd-powered machines have never worked so well and completely out of the box! These guys are doing amazing work, they are making Linux into a very, very serious competitor with today's desktop and mobile (incl laptop) machines. They are doing the dependencies too tightly, yes. They don't care enough about the possibility of other people reimplementing parts of what they do. But their actual achievements are incredible. I have a huge respect for what they do. That said... I have very little respect for them. The ability to separate a person from what they do seems to be a rare quality this way, despite what everyone claims (what with the Brendan Eich issue and such). The fucking attitude in these projects is disgusting. And these people don't actually understand that they are universally hated for behaving like children over such stupid issues. They live in a different world. And this is all just what you see externally. Internally, it's free-for-all retardfest... Fucking human nature, man. I've never been so uneasy as in the last few weeks... I can swear things used to be better but maybe I can just see things more clearly now.

krick 13y ago
I don't disagree with what you say, but it feels like a lot more important issue than you describe it. The whole systemd thing was intended to rewrite some pretty complex stuff that works already, but as it turned out over time does many things wrong. And do it right™ this time. Keywords: "rewrite", "already works", "right". And I personally believe it's a good idea, because what is done wrong at low level produces more and more work, complexity and errors on higher levels. Very hard to achieve, but essentially good. Now, the complex system with good API and architecture, but not-so-perfect internals is hard, but possible to fix and improve over time. System with bad API is essentially impossible to fix, ever. People that write optimal code without bugs, but terrible APIs and don't care about what others feel about that simply cannot "do it right™". Yeah, it may work well out of the box, but the progress goes on and after 5-10 years community will struggle to implement something new and important on top of that systemd and feel that only way to stop the pain is to replace it with some systemπ and do it right™, and people will remember 2014 year and say: "Well, we had that story with systemd already. It turned out to be no good! We'll make do without doing stuff right™." Thinking about it I feel sad regardless it may work smooth out of the box at the moment.