19 ms·

I'm looking forward to 2 or 3 years from now when we can look back and laugh at all the fear and apprehension about systemd. That said though, I did just recen

by tdicola 11y ago

I'm looking forward to 2 or 3 years from now when we can look back and laugh at all the fear and apprehension about systemd. That said though, I did just recently upgrade to Ubuntu 15.04 (which is all systemd now) and it is noticeably slower to boot up compared to my old upstart-based 14.04 LTS install. Hopefully there's some more optimization that needs to be done to bring the boot-up speed to parity with the previous versions.

blueflow 11y ago
I really like that you can now use systemd-cat with logfiles because regular cat doesn't fit anymore.
- blackle 11y ago
  really unix philosophy, isn't it?
  - andrewstuart2 11y ago
    I'm not sure the systemd guys want to build with the unix philosophy. I don't have a definitive source (maybe SE radio podcast?) but I seem to remember one of the authors saying as much. They're more interested in what Linux can become than what unix was. Not that I agree, but I believe that's what they said.
    - agumonkey 11y ago
      Lennart Poettering has a different view on Unix philosophy, it's more 'make it interesting and do what you need to'. I think nobody is right or wrong. This is all growing pain and, as I often say, at the right time I'm sure there will be tinier systemd-like built to be more Unixy (as in 'small set of smaller composable tools').
      - blueflow 11y ago
        Something like systemd except being ONLY an init system would be really great.
        rascul 11y ago
        http://uselessd.darknedgy.net http://uselessd.darknedgy.net
        mercurial 11y ago
        This looks surprisingly tempting. I agree with a lot of the ideas behind systemd, but at the rate it is growing, I'm going to type this in systemd-firefox in systemd-xmonad in six months. How stable is it in practice?
        chris_wot 11y ago
        I can't see why most people would want that, with the exception of replacing journald. Why strip out device init, or even timers? Swap init is less useful, but I don't see the harm. What is it that makes uselessd attractive? And why do you consider systemd to be bloated?
        mercurial 11y ago
        I like my init system to be an init system. However, the scope of systemd seems to expand monthly. I mean, you get an ntp client, a dhcp client, a logging system, and they apparently want to expand into containerized applications? I'd rather have a project with a smaller, well-defined scope.
        chris_wot 11y ago
        You can turn these services off :-) http://0pointer.de/blog/projects/three-levels-of-off http://0pointer.de/blog/projects/three-levels-of-off
    - pdkl95 11y ago
      Most of the systemd people arguing about the unix philosophy have no idea what that philosophy is[1]. A common argument is to insist that breaking up systemd into a separate binaries made "not monolithic", while ignoring that the design is still totally interdependent. Linux has become a victim of it's own success. It's popularity has brought in a new generation of people that learned about computers from Microsoft and Apple and they are bringing the "design" ideas of that world with them because they usually have never learned the basics of what unix is and why so many people use it. Don't get me wrong - if they want to make a community-developed OS in the windows-style, they should! If that solves their problems better than a unix, then I wish them well and hope the project succeeds. The problem I have is that instead of starting/forking their own project, they are trying to trying to redirect Linux at the expense of those of us that have been here since the kernel 1.2.13 days[2] because it was a unix. Instead of being a separate project, we get to deal with misinformation and bad design, while being labeled a "hater" for wanting to use a working unix instead of the systemd vision of the future[3]. /Sigh/ "Those who do not understand Unix are condemned to reinvent it, poorly." (Henry Spencer) [1] http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s06.html [2] Slackware was already on version 3.0! [3] http://0pointer.de/public/gnomeasia2014.pdf http://0pointer.de/public/gnomeasia2014.pdf
      - vezzy-fnord 11y ago
        In all honesty, people who want a working Unix would have went to a BSD or Solaris variant a while ago. GNU/Linux, although historically mostly abiding by Unix principles, has always had syncretic aspects as early as the desktop environments experimenting with various fat RPC protocols over 15 years ago, and likely other precedents earlier. The introduction of the various storage abstraction layers like devfs and HAL, plus all the other monolithic subsystem daemons in the form of the *kits that emerged early on, foreshadowed what would come today, even if they were mostly manageable back then.
        rpcope1 11y ago
        >The introduction of the various storage abstraction layers like devfs and HAL, plus all the other monolithic subsystem daemons in the form of the *kits that emerged early on, foreshadowed what would come today, even if they were mostly manageable back then. This seems strangely backwards -- a lot of the "let's make this into files" philosophy like devfs, /proc, et. al. borrows from Plan 9, which is arguably more Unix than Unix; systemd on the other hand...
  - chris_wot 11y ago
    Sounds exactly like the Unix philosophy - cat is to concatenate files or standard input to standard output. If you took the binary format of systemd log files then it would output binary data to stdout. Possibly you are unhappy with binary logs - I'm not very enamoured with them either. Perhaps you don't like the name of that executable. But you can't say it isn't doing the one thing - your issue is not around the Unix philosophy but rather the design decisions of systemd.
    - mveety 11y ago
      That's because cat is unixy. You can concatenate any file to any file with it. That doesn't mean those files are unixy, it means the program is unixy.
      - chris_wot 11y ago
        Not sure I understand your point. You just stated the purpose of cat, the tool being criticised isn't cat (so badly named) but does one job well - output binary logs into textual form onto standard output.
    - mbrubeck 11y ago
      Doug McIlroy (the inventor of Unix pipes) included this in his description of "the Unix philosophy": > Write programs to handle text streams, because that is a universal interface. ESR expanded on this in the "Unix Philosophy" chapter of The Art of Unix Programming: > Unix tradition strongly encourages writing programs that read and write simple, textual, stream-oriented, device-independent formats. > Before devising a tricky binary format to pass data around, it's worth experimenting to see if you can make a simple textual format work and accept a little parsing overhead in return for being able to hack the data stream with general-purpose tools. (And no, journalctl and systemd-cat don't fully replace the ability to run text-processing programs like grep, head, tail, etc. directly on the stored data.)
      - danieldk 11y ago
        Well, I guess you are also against SQL databases, aren't you ;). grep, head, tail, etc. work great when you have a small amount of logs. But if you have a production system with lots of logging data, processing plain text can become too slow and/or icky parsing-wise.
- the_why_of_y 11y ago
  Sorry, I don't get it - systemd-cat(1) only writes into the journal, it does not read from it, so it is more a replacement for logger(1) than for cat(1) - if you do cat foo >> /var/log/messages, how do you get timestamps on the log entries, and won't your syslog implementation just overwrite that? Does anybody actually do that?
agumonkey 11y ago
Surprising, what does `systemd-analyze blame` says ?
- tdicola 11y ago
  Oh neat, had no idea about that command. Looks like these two are the big time sinks: 6.340s systemd-udev-settle.service 6.232s NetworkManager-wait-online.service Everything after that is under 250ms or so. Interesting that udev and network manager are taking so long during boot.
  - agumonkey 11y ago
    I'm still a systemd noob but I've heard there are ways to avoid blocking on network connectivity. Hopefully you'll forget about that part. udev-settle seems to be a workaround LVM not being event driven enough http://freedesktop.org/wiki/Software/systemd/Optimizations/ http://freedesktop.org/wiki/Software/systemd/Optimizations/ https://bbs.archlinux.org/viewtopic.php?id=189369 https://bbs.archlinux.org/viewtopic.php?id=189369 Using arch, systemd boot time is now almost inexistant (but I have a tiny system with a SSD).
  - vezzy-fnord 11y ago
    udevsettle is a hack that waits for the kevent queue to finish. I believe the justification for it was that certain volume and storage technologies on Linux act in a synchronous probing fashion that expect all devices to be up simultaneously before initializing. It's frequently mentioned as a bottleneck, including here: https://wiki.freedesktop.org/www/Software/systemd/Optimizations/ https://wiki.freedesktop.org/www/Software/systemd/Optimizati... As for NetworkManager's wait online service, see what timeout has been set inside the unit file, and try lowering it. Though I suspect this might be yet another hack implemented as a synchronization point for network-dependent services to initialize properly, given just how finicky it is to define what a "network is up" state actually entails.
  - nextos 11y ago
    NetworkManager, and most other net daemons suck. I had almost lost hope till I found connman [1]. It's implemented by Intel and used in many mobiles. It has it's own _absurdly_ fast DHCP client. It manages many network interfaces flawlessly and it's really lightweight. Give it a try. [1] https://01.org/connman https://01.org/connman
badsock 11y ago
I have the feeling that things will settle into a Microsoft-like "things mostly work, most of the time, because so much effort was put into it rather than good design" kind of world. Sort of like how PulseAudio is now. Most people are cool with that kind of OS, so I don't think there will be much more than occasional grumbling. People like me who can't stand it will all have left.
- chris_wot 11y ago
  Pulseaudio had bugs which caused problems, but what in particular is it about the design of PA that is flawed?
  - badsock 11y ago
    Massively overdesigned while trying to solve a problem that almost no one had (network transparency). FreeBSD's implementation of /dev/dsp is a good example of how simple it can be.
    - the_why_of_y 11y ago
      Yes, doing the mixing in kernel space is nice: it's obvious, simple, reliable, monolithic. Unfortunately the Linux developers don't want to go that way, because they think mixing is a problem for user-space.
    - upofadown 11y ago
      Pulseaudio does network audio right and I have been using it for that purpose since it first existed. So from my prospective the mistake was adding in all the other junk. The root cause of all the complexity is (was?) the lack of standardization for hardware interfaces. The lack of some globally usable way of dealing with latency at the OS level is another issue. A thing like Pulseaudio is a natural reaction to the current situation in that it tries to both hide the complexity of the hardware interfaces and deals with the latency issue entirely in one program. So the problem isn't Pulseaudio. The problem is the environment that media is forced to exist in.
nextos 11y ago
I like many things systemd has brought. However, I think the app-ification they are planning to deploy in Linux systems is extremely dangerous. Essentially they are implementing app bundles as containers [1]. All good lessons learnt from package managers? Gone. Nix? Forgotten. Imagine a heartbleed like scenario. In a controlled situation with a distro that uses a package manager this is easy to fix. Just upgrade the compromised package. Now think what happens if you have 20 different containers running 20 different userlands... It's really scary. Linux has become such a nice OS partly because many distros created great package management tools. These systemd guys make things terribly complex for no reason. Systemd itself is a monster running as PID 1, which is not very wise from a security perspective either. Pulseaudio is slow and unreliable. Dbus is quite inefficient. Etc. Things are getting ugly. They are messing up with the Linux userland and ignoring core Unix principles. [1] http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu...
- snogglethorpe 11y ago
  I get the impression, e.g. from Ubuntu's "new package format", that NIH aside (always a big factor with Ubuntu), that many of these efforts are mostly targeting "simple apps", i.e. standalone applications that don't require any kind of complicated wiring into the system. It looks like they'll still need a "real" package format to actually do things like update the system, install kernels, libraries, and dev stuff, etc.
  - digi_owl 11y ago
    Anything about libc will apparently be handled by special "library" packages, or bundled with the "apps" themselves. As for kernels and such, at least with Ubuntu Snappy this will be handles in a ChromeOS like fashion. Dump the updated base system into a separate partition, change the Grub config, reboot. If the system fails to boot up it will either instruct the user (i see no admins, nor "power-users" in this scenario) to pick the failsafe/recover option, or do so automatically. Basically you can forget everything you learned about PC or server. The future is all containers and VMs. The computational equivalent of TV dinners or canned goods.

by tdicola 11y ago

blueflow 11y ago

I really like that you can now use systemd-cat with logfiles because regular cat doesn't fit anymore.

blackle 11y ago
really unix philosophy, isn't it?
- andrewstuart2 11y ago
  I'm not sure the systemd guys want to build with the unix philosophy. I don't have a definitive source (maybe SE radio podcast?) but I seem to remember one of the authors saying as much. They're more interested in what Linux can become than what unix was. Not that I agree, but I believe that's what they said.
  - agumonkey 11y ago
    Lennart Poettering has a different view on Unix philosophy, it's more 'make it interesting and do what you need to'. I think nobody is right or wrong. This is all growing pain and, as I often say, at the right time I'm sure there will be tinier systemd-like built to be more Unixy (as in 'small set of smaller composable tools').
    - blueflow 11y ago
      Something like systemd except being ONLY an init system would be really great.
      - rascul 11y ago
        http://uselessd.darknedgy.net http://uselessd.darknedgy.net
        mercurial 11y ago
        This looks surprisingly tempting. I agree with a lot of the ideas behind systemd, but at the rate it is growing, I'm going to type this in systemd-firefox in systemd-xmonad in six months. How stable is it in practice?
        chris_wot 11y ago
        I can't see why most people would want that, with the exception of replacing journald. Why strip out device init, or even timers? Swap init is less useful, but I don't see the harm. What is it that makes uselessd attractive? And why do you consider systemd to be bloated?
        mercurial 11y ago
        I like my init system to be an init system. However, the scope of systemd seems to expand monthly. I mean, you get an ntp client, a dhcp client, a logging system, and they apparently want to expand into containerized applications? I'd rather have a project with a smaller, well-defined scope.
        chris_wot 11y ago
        You can turn these services off :-) http://0pointer.de/blog/projects/three-levels-of-off http://0pointer.de/blog/projects/three-levels-of-off
  - pdkl95 11y ago
    Most of the systemd people arguing about the unix philosophy have no idea what that philosophy is[1]. A common argument is to insist that breaking up systemd into a separate binaries made "not monolithic", while ignoring that the design is still totally interdependent. Linux has become a victim of it's own success. It's popularity has brought in a new generation of people that learned about computers from Microsoft and Apple and they are bringing the "design" ideas of that world with them because they usually have never learned the basics of what unix is and why so many people use it. Don't get me wrong - if they want to make a community-developed OS in the windows-style, they should! If that solves their problems better than a unix, then I wish them well and hope the project succeeds. The problem I have is that instead of starting/forking their own project, they are trying to trying to redirect Linux at the expense of those of us that have been here since the kernel 1.2.13 days[2] because it was a unix. Instead of being a separate project, we get to deal with misinformation and bad design, while being labeled a "hater" for wanting to use a working unix instead of the systemd vision of the future[3]. /Sigh/ "Those who do not understand Unix are condemned to reinvent it, poorly." (Henry Spencer) [1] http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s06.html [2] Slackware was already on version 3.0! [3] http://0pointer.de/public/gnomeasia2014.pdf http://0pointer.de/public/gnomeasia2014.pdf
    - vezzy-fnord 11y ago
      In all honesty, people who want a working Unix would have went to a BSD or Solaris variant a while ago. GNU/Linux, although historically mostly abiding by Unix principles, has always had syncretic aspects as early as the desktop environments experimenting with various fat RPC protocols over 15 years ago, and likely other precedents earlier. The introduction of the various storage abstraction layers like devfs and HAL, plus all the other monolithic subsystem daemons in the form of the *kits that emerged early on, foreshadowed what would come today, even if they were mostly manageable back then.
      - rpcope1 11y ago
        >The introduction of the various storage abstraction layers like devfs and HAL, plus all the other monolithic subsystem daemons in the form of the *kits that emerged early on, foreshadowed what would come today, even if they were mostly manageable back then. This seems strangely backwards -- a lot of the "let's make this into files" philosophy like devfs, /proc, et. al. borrows from Plan 9, which is arguably more Unix than Unix; systemd on the other hand...
- chris_wot 11y ago
  Sounds exactly like the Unix philosophy - cat is to concatenate files or standard input to standard output. If you took the binary format of systemd log files then it would output binary data to stdout. Possibly you are unhappy with binary logs - I'm not very enamoured with them either. Perhaps you don't like the name of that executable. But you can't say it isn't doing the one thing - your issue is not around the Unix philosophy but rather the design decisions of systemd.
  - mveety 11y ago
    That's because cat is unixy. You can concatenate any file to any file with it. That doesn't mean those files are unixy, it means the program is unixy.
    - chris_wot 11y ago
      Not sure I understand your point. You just stated the purpose of cat, the tool being criticised isn't cat (so badly named) but does one job well - output binary logs into textual form onto standard output.
  - mbrubeck 11y ago
    Doug McIlroy (the inventor of Unix pipes) included this in his description of "the Unix philosophy": > Write programs to handle text streams, because that is a universal interface. ESR expanded on this in the "Unix Philosophy" chapter of The Art of Unix Programming: > Unix tradition strongly encourages writing programs that read and write simple, textual, stream-oriented, device-independent formats. > Before devising a tricky binary format to pass data around, it's worth experimenting to see if you can make a simple textual format work and accept a little parsing overhead in return for being able to hack the data stream with general-purpose tools. (And no, journalctl and systemd-cat don't fully replace the ability to run text-processing programs like grep, head, tail, etc. directly on the stored data.)
    - danieldk 11y ago
      Well, I guess you are also against SQL databases, aren't you ;). grep, head, tail, etc. work great when you have a small amount of logs. But if you have a production system with lots of logging data, processing plain text can become too slow and/or icky parsing-wise.
the_why_of_y 11y ago
Sorry, I don't get it - systemd-cat(1) only writes into the journal, it does not read from it, so it is more a replacement for logger(1) than for cat(1) - if you do cat foo >> /var/log/messages, how do you get timestamps on the log entries, and won't your syslog implementation just overwrite that? Does anybody actually do that?

agumonkey 11y ago

Surprising, what does `systemd-analyze blame` says ?

tdicola 11y ago
Oh neat, had no idea about that command. Looks like these two are the big time sinks: 6.340s systemd-udev-settle.service 6.232s NetworkManager-wait-online.service Everything after that is under 250ms or so. Interesting that udev and network manager are taking so long during boot.
- agumonkey 11y ago
  I'm still a systemd noob but I've heard there are ways to avoid blocking on network connectivity. Hopefully you'll forget about that part. udev-settle seems to be a workaround LVM not being event driven enough http://freedesktop.org/wiki/Software/systemd/Optimizations/ http://freedesktop.org/wiki/Software/systemd/Optimizations/ https://bbs.archlinux.org/viewtopic.php?id=189369 https://bbs.archlinux.org/viewtopic.php?id=189369 Using arch, systemd boot time is now almost inexistant (but I have a tiny system with a SSD).
- vezzy-fnord 11y ago
  udevsettle is a hack that waits for the kevent queue to finish. I believe the justification for it was that certain volume and storage technologies on Linux act in a synchronous probing fashion that expect all devices to be up simultaneously before initializing. It's frequently mentioned as a bottleneck, including here: https://wiki.freedesktop.org/www/Software/systemd/Optimizations/ https://wiki.freedesktop.org/www/Software/systemd/Optimizati... As for NetworkManager's wait online service, see what timeout has been set inside the unit file, and try lowering it. Though I suspect this might be yet another hack implemented as a synchronization point for network-dependent services to initialize properly, given just how finicky it is to define what a "network is up" state actually entails.
- nextos 11y ago
  NetworkManager, and most other net daemons suck. I had almost lost hope till I found connman [1]. It's implemented by Intel and used in many mobiles. It has it's own _absurdly_ fast DHCP client. It manages many network interfaces flawlessly and it's really lightweight. Give it a try. [1] https://01.org/connman https://01.org/connman

badsock 11y ago

I have the feeling that things will settle into a Microsoft-like "things mostly work, most of the time, because so much effort was put into it rather than good design" kind of world. Sort of like how PulseAudio is now. Most people are cool with that kind of OS, so I don't think there will be much more than occasional grumbling. People like me who can't stand it will all have left.

chris_wot 11y ago
Pulseaudio had bugs which caused problems, but what in particular is it about the design of PA that is flawed?
- badsock 11y ago
  Massively overdesigned while trying to solve a problem that almost no one had (network transparency). FreeBSD's implementation of /dev/dsp is a good example of how simple it can be.
  - the_why_of_y 11y ago
    Yes, doing the mixing in kernel space is nice: it's obvious, simple, reliable, monolithic. Unfortunately the Linux developers don't want to go that way, because they think mixing is a problem for user-space.
  - upofadown 11y ago
    Pulseaudio does network audio right and I have been using it for that purpose since it first existed. So from my prospective the mistake was adding in all the other junk. The root cause of all the complexity is (was?) the lack of standardization for hardware interfaces. The lack of some globally usable way of dealing with latency at the OS level is another issue. A thing like Pulseaudio is a natural reaction to the current situation in that it tries to both hide the complexity of the hardware interfaces and deals with the latency issue entirely in one program. So the problem isn't Pulseaudio. The problem is the environment that media is forced to exist in.

nextos 11y ago

I like many things systemd has brought. However, I think the app-ification they are planning to deploy in Linux systems is extremely dangerous. Essentially they are implementing app bundles as containers [1]. All good lessons learnt from package managers? Gone. Nix? Forgotten. Imagine a heartbleed like scenario. In a controlled situation with a distro that uses a package manager this is easy to fix. Just upgrade the compromised package. Now think what happens if you have 20 different containers running 20 different userlands... It's really scary. Linux has become such a nice OS partly because many distros created great package management tools. These systemd guys make things terribly complex for no reason. Systemd itself is a monster running as PID 1, which is not very wise from a security perspective either. Pulseaudio is slow and unreliable. Dbus is quite inefficient. Etc. Things are getting ugly. They are messing up with the Linux userland and ignoring core Unix principles. [1] http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu...

snogglethorpe 11y ago
I get the impression, e.g. from Ubuntu's "new package format", that NIH aside (always a big factor with Ubuntu), that many of these efforts are mostly targeting "simple apps", i.e. standalone applications that don't require any kind of complicated wiring into the system. It looks like they'll still need a "real" package format to actually do things like update the system, install kernels, libraries, and dev stuff, etc.
- digi_owl 11y ago
  Anything about libc will apparently be handled by special "library" packages, or bundled with the "apps" themselves. As for kernels and such, at least with Ubuntu Snappy this will be handles in a ChromeOS like fashion. Dump the updated base system into a separate partition, change the Grub config, reboot. If the system fails to boot up it will either instruct the user (i see no admins, nor "power-users" in this scenario) to pick the failsafe/recover option, or do so automatically. Basically you can forget everything you learned about PC or server. The future is all containers and VMs. The computational equivalent of TV dinners or canned goods.