Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why systemd?

blog.jorgenschaefer.de

Post reply on HN
Print view View original

31–40 of 263 posts

Re: Why systemd?

#31

Post by nisa »

audidude wrote: post #27
nisa wrote: post #18

Earlier quoted context omitted.

Opaque C code that sits in lots of spread binaries and some end-user documentation in man pages don't help you a lot if have to debug an issue. It's okay from a user perspective but with systemd (or other complex systems that rely on in this principle) you need to start reading c-code, start gdb, deal with dbus... if it's a toolbox of scripts a `grep -r ` is often the first step on the way to understand and learn som…

> Opaque C code that sits in 20 binaries and some man pages don't help you a lot if have to debug an issue. It's okay from a user perspective but with systemd (or other systems that rely on in this principle) you need to start reading c-code, start gdb, deal with dbus... if it's a toolbox of scripts a `grep -r ` is often the first step on the way to understand and learn something and fix the problem. What's opaque ab…

> What's opaque about Free and Open Source C code?

Everything if you are sysadmin/developer trying to fix an issue. At first you need debugging symbols to pinpoint the problem, then you need to read the source.. it all takes time. E.g. you need to learn about dbus-monitor and dbus calls and need to grasp some internal concepts of systemd if something goes wrong. It takes time and patience you usally don't have or don't want to spend on such details. For comparison i.e. FreeBSD rc is only shell-scripts: http://www.freebsd.org/cgi/man.cgi?rc(8)

I don't want to say that one is better than the other but the latter is for most folks far easier to debug and modify than the first. However as I've said it only really matters for few people. But I can understand that they are not particularly happy about this new complexity. And bugs happen.

Re: Why systemd?

#32

Post by ultramancool »

AceJohnny2 wrote: post #29
Sanddancer wrote: post #22

Earlier quoted context omitted.

named pipes, posix ipc, signals, etc. There are quite a few existing communications methods that can be used for this purpose.

OK, and how do you format the data you send across, or find out which functions the daemon supports and trigger them?

Classic sysvinit or BSD-style init doesn't rely upon this sort of functionality at all. Just some simple scripts. No need to complicate it any further. A few signals are all that are needed.

Re: Why systemd?

#33

Post by elehack »

jude- wrote: post #25
elehack wrote: post #23

Earlier quoted context omitted.

Not quite. I'm saying that systemd makes the Linux kernel's feature set and capabilities visibly usable from user-space. For (nearly) the first time, it feels like it matters that I'm using Linux. Linux is still Linux without systemd, it just doesn't provide as much benefit (aside from device support and compatibility) over, say, FreeBSD without software that takes advantage of its feature set.

What stopped you from using Linux-specific features before systemd? They were accessible from userspace well before systemd came along.

The lack of documented software that used them to enable useful (to me) functionality.

I was using some of them, such as kvm for my virtualization and lvm for disk management. But systemd still had a substantial 'oh, wow, Linux lets process management be this easy and powerful?' factor, showing me something new that I hadn't seen in my use of any other system (FreeBSD, OpenBSD, Windows, a touch of Mac).

Re: Why systemd?

#34

Post by kiyoto »

drdaeman wrote: post #19
ultramancool wrote: post #5

Am I the only one who's disgusted with this bloated, convoluted, dbus-dependent pile of crap? I mean, c'mon, binary log files? I'll pass, thanks. It replaces way more than it needed to. I prefer the BSD-style philosophy, nice, simple rc.conf, used to run Arch till it got infected with this garbage too. It slowly progressed away from it's BSD-style roots. So recently, I just gave up and moved to FreeBSD. Not a single…

I think I'm mostly fine with journald (as a concept). At least I can explain reasoning for it to myself. A switch from non-structured to structured data provides a significant advantage, and indexes are useful. At least I had too many times grepping a multi-gigabyte log file. Sure, relatively modern (RFC5424) syslog protocol has structured data too, but in my experience most software had never bothered to use it. So,…

>Sure, relatively modern (RFC5424) syslog protocol has structured data too, but in my experience most software had never bothered to use it. So, forcing a switch through introducing another protocol that has structured data baked-in isn't a too terrible idea.

I agree. There is a strong need for common interface(s), and that's a strong part of the motivation behind Fluentd/Kafka/etc. www.fluentd.org/blog/unified-logging-layer

Re: Why systemd?

#35

Post by audidude »

nisa wrote: post #31
audidude wrote: post #27

Earlier quoted context omitted.

> Opaque C code that sits in 20 binaries and some man pages don't help you a lot if have to debug an issue. It's okay from a user perspective but with systemd (or other systems that rely on in this principle) you need to start reading c-code, start gdb, deal with dbus... if it's a toolbox of scripts a `grep -r ` is often the first step on the way to understand and learn something and fix the problem. What's opaque ab…

> What's opaque about Free and Open Source C code? Everything if you are sysadmin/developer trying to fix an issue. At first you need debugging symbols to pinpoint the problem, then you need to read the source.. it all takes time. E.g. you need to learn about dbus-monitor and dbus calls and need to grasp some internal concepts of systemd if something goes wrong. It takes time and patience you usally don't have or don…

> I don't want to say that one is better than the other but the latter is for most folks far easier to debug and modify than the first.

Generally bad form to make claims on behalf of "most folks" since you are in fact a single person. It's totally a valid argument if you say this on your own behalf.

And yes, bugs happen. But fixing the C code, is in my experience, much easier than tracking them down in `bash -x`. Especially when dealing with race conditions between services/triggers/device initialization.

Re: Why systemd?

#36

Post by drdaeman »

Sanddancer wrote: post #26
drdaeman wrote: post #19

Earlier quoted context omitted.

I think I'm mostly fine with journald (as a concept). At least I can explain reasoning for it to myself. A switch from non-structured to structured data provides a significant advantage, and indexes are useful. At least I had too many times grepping a multi-gigabyte log file. Sure, relatively modern (RFC5424) syslog protocol has structured data too, but in my experience most software had never bothered to use it. So,…

The biggest problem with dropping the syslog protocol altogether is that there's a huge amount of other stuff that speaks syslog. Things like networking gear use it for the same purposes as a normal *nix box, and getting them to switch is going to be like pulling teeth. With your particular case, I'd say you should look at rsyslog and/or syslog-ng. Both of them have backends that talk with actual databases, so you ca…

Well, journald has syslog compatibility layer and can talk syslog, so supporting any existing software is not an issue. It doesn't speak syslog by itself, so it probably can't forward logs to another networked syslog server, but I don't see anything that prevents implementing this, if necessary.

The point is, journald also introduces a new protocol that's oriented at logging structured data. This way it not just provides a feature, but forces developers to think about structuring their log output in a machine-readable manner. I think that's the excuse that I believe is the journald's raison d'être and that I personally accept.

Just my opinion, though.

Re: Why systemd?

#37

Post by nisa »

audidude wrote: post #30
drdaeman wrote: post #21

Earlier quoted context omitted.

What's wrong with old good Unix pipes?

The don't solve race conditions in peers trying to locate each other (surprisingly difficult). They don't solve a standardized marshaling format. They don't come with an implementation to integrate with main loops for event polling. They don't handle authentication (well, sort of). They have an inherent vulnerability in FD passing where you can cause the peer to lock up. You can get into deadlock situations in your m…

> They have an inherent vulnerability in FD passing where you can cause the peer to lock up.

(It's kind of unfair but I could not resist): Just like dbus today? http://www.ubuntu.com/usn/usn-2352-1/

Re: Why systemd?

#38

Post by brandonmenc »

jude- wrote: post #25
elehack wrote: post #23

Earlier quoted context omitted.

Not quite. I'm saying that systemd makes the Linux kernel's feature set and capabilities visibly usable from user-space. For (nearly) the first time, it feels like it matters that I'm using Linux. Linux is still Linux without systemd, it just doesn't provide as much benefit (aside from device support and compatibility) over, say, FreeBSD without software that takes advantage of its feature set.

What stopped you from using Linux-specific features before systemd? They were accessible from userspace well before systemd came along.

Setting up and running services like the OS does, but as non-root user, is kind of a big deal for my use case.

Perhaps I'm ignorant and this was always possible.

Re: Why systemd?

#39

Post by audidude »

audidude wrote: post #30
drdaeman wrote: post #21

Earlier quoted context omitted.

What's wrong with old good Unix pipes?

The don't solve race conditions in peers trying to locate each other (surprisingly difficult). They don't solve a standardized marshaling format. They don't come with an implementation to integrate with main loops for event polling. They don't handle authentication (well, sort of). They have an inherent vulnerability in FD passing where you can cause the peer to lock up. You can get into deadlock situations in your m…

Exactly (since userspace DBus has to use sockets, kdbus uses memfd). Imagine if you had to fix that in every program that ever wanted to do IPC instead of just one place. Sounds like a security and maintenance nightmare.

Re: Why systemd?

#40

Post by mmagin »

ultramancool wrote: post #32
AceJohnny2 wrote: post #29

Earlier quoted context omitted.

OK, and how do you format the data you send across, or find out which functions the daemon supports and trigger them?

Classic sysvinit or BSD-style init doesn't rely upon this sort of functionality at all. Just some simple scripts. No need to complicate it any further. A few signals are all that are needed.

Simple scripts? Have you looked at the shit in /etc/init.d in a modern linux distribution?

  $ wc -l * | sort -n | tail
   274 exim4
   286 apache2
   290 dnsmasq
   298 nfs-common
   350 clamav-freshclam
   364 udev
   386 checkroot.sh
   420 clamav-daemon
   465 clamav-milter
  9893 total
If you look into these, you'll find tons of near-duplicate code between scripts, and frequently every script reinvents the wheel in one way or another.
Post reply on HN