Live data from Hacker News

Without Systemd

without-systemd.org

21–30 of 89 posts

Re: Without Systemd

#21
post #20

Earlier quoted context omitted.

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.

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 a…

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.

Re: Without Systemd

#22
post #16
post #7

Earlier quoted context omitted.

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.

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

That same insanely fast DHCP client library now powers systemd-networkd[1]. We have been using it as the default on CoreOS for quite a number of releases now.

[1] https://coreos.com/blog/intro-to-systemd-networkd/

Re: Without Systemd

#23
post #13
post #2

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 previo…

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…

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.

Re: Without Systemd

#24
I've used distributions w/ systemd on a number of virtual machines, but those have mostly been non-critical machines.

I was slowly moving back to FreeBSD from Ubuntu/Debian. Systemd has moved that timing forward. Boot up time and monolithic systems don't do it for me -- managable sure -- but not my cup of tea.

Re: Without Systemd

#25
post #4

Earlier quoted context omitted.

really unix philosophy, isn't it?

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 Un…

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.

Re: Without Systemd

#26
post #4

Earlier quoted context omitted.

really unix philosophy, isn't it?

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 Un…

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.)

Re: Without Systemd

#27
Voted down once, but most of the comments seem centered on desktop versus actual server installations.

"pulse audio", "gnome 3", etc.

How many people have experience with running systemd based servers in production and, if appropriate, at scale?

Thoughts?

Comparisons with tried and true components like syslog?

Re: Without Systemd

#29

Earlier quoted context omitted.

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 Un…

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 devisin…

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.

Re: Without Systemd

#30
post #9

Earlier quoted context omitted.

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.

Similar feelings here, this "it kinda works"-feeling was the reason why I switched to Linux in the first place. What are your plans? Where do you go when you 'leave'?

I switched all my servers and desktops to FreeBSD. It's like going back in time in many, many good ways (commandline/text-config focus, less magic, etc.), and one bad way (HW support).
Post reply on HN