Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

[nslay]

Everything in /proc is required to be documented. /sys/kernel/debug can have undocumented stuff.

It isn't that difficult or even very slow to parse the files.

From a developer point of view it is much nicer to have them in text. Imagine if it was done like the Windows API. The code would need to look for the size of the output struct and run it through a switch or if/else to figure out which of the many versions of /proc/pid/stat were requested. With the current system new data fields are added to the end and it is the responsibility of the code reading them to ignore fields it doesn't understand.

For some kernel information there are netlink socket APIs to get the data in binary form.

From a developer point of view (and not scripting), it is much nicer to get native information in the native format. Not string parsing. And while Windows API has to deal with different sizes of structs, it's still much better than writing string parsing routines to get system information. It also doesn't imply that a better interface couldn't be developed (e.g. sysctl seems convenient for userspace ... maybe it's a nightmare in the kernel though).

I can see kernel developers caring about the issue you described. But as a userspace developer, I don't care what the kernel does unless it's affecting my code and I don't care if /proc makes the kernel development easier or not ... having to write string parsing routines for basic system information every time is really really lame in my opinion.

But this is now veering completely off topic. I'm very sorry to steer the discussion in this direction, but I couldn't resist.

[nslay]

It is:

I stand corrected then. Since the kernel isn't something you're necessarily going to pipe to other programs, I think this is a special case ... and since almost every other operating system I can think of exports system information to userspace applications with some sort of API (which is much more convenient), I still think parsing text for basic system information really really stupid.

[gamerk2]

I stand corrected then. Since the kernel isn't something you're necessarily going to pipe to other programs, I think this is a special case ... and since almost every other operating system I can think of exports system information to userspace applications with some sort of API (which is much more convenient), I still think parsing text for basic system information really really stupid.

Its really is. Any system information should come across already formatted; the idea you have to parse this information is backward.

[Luke_Wolf]

That doesn't make it any less lame in my opinion. The stupid part is parsing strings for system information and that is not part of the Unix philosophy.

Even though I don't mess with proc myself I gotta agree that having to write string parsers just suck, setting up parsing is one of the most asininely annoying tasks you can make a programmer do. That said if you format the output in JSON or XML then you retain the benefits of text based formats, while making the lives of programmers much much easier, and also allowing you to have a bunch of extra cool features.

[jonte1]

From a developer point of view (and not scripting), it is much nicer to get native information in the native format. Not string parsing. And while Windows API has to deal with different sizes of structs, it's still much better than writing string parsing routines to get system information. It also doesn't imply that a better interface couldn't be developed (e.g. sysctl seems convenient for userspace ... maybe it's a nightmare in the kernel though).

I can see kernel developers caring about the issue you described. But as a userspace developer, I don't care what the kernel does unless it's affecting my code and I don't care if /proc makes the kernel development easier or not ... having to write string parsing routines for basic system information every time is really really lame in my opinion.

But this is now veering completely off topic. I'm very sorry to steer the discussion in this direction, but I couldn't resist.

Well, I'm not a developer myself but I'm one of them that often are called in to clean up. "But as a userspace developer, I don't care what the kernel does unless it's affecting my code and I don't care if /proc makes the kernel development easier or not ... having to write string parsing routines for basic system information every time is really really lame in my opinion."

Or what did you mean?

[schmidtbag]

well 2 facts first

1.) systemd arch full install in x86_64 is less than 20mb, for arm is lot smaller. so i don't see size been a problem specially since any toolkit you use is prolly 20 times bigger
2.) systemd only start PID1 by default(your definition of init system)and journald for logging everything else start and stop ondemand from c/c++/DBUS/etc API, so it doesnt use memory or CPU at all unless is really needed

now the answer will be people won't like it for one simple reason, you break standarization and add an extra step to verify that all submodules are installed in runtime, just to save 10mb tops of hardrive space is just plain crazy

It's not so much the disk space that's the issue, it's what the features do, maintaining the code of those things, and the other system resources those things end up consuming. With Canonical now supporting systemd, it will get bloated much faster. It might not hit 30MB in 5 years, but as long as any of the "unnecessary" features (such as systemd's networking capabilities) get screwed up, it could cause issues for distros like Debian, which will have to stick with a very old outdated version. By separating such things, a distro like debian could still use a much more up-to-date "systemd-core". It's all about maintenance, and something as critical as systemd needs to be fundamentally stable. You can't get that kind of stability out of features that don't HAVE to be there to begin with.

[balouba]

if you don't like /proc, fuck you. thats how unix works and its a lot better than windows system calls AND osx, solaris, openbsd system calls for this.
if you don't like Linus's way of handling things, fuck you. It works way better than anything else. If Linus were to die tomorrow, we'd have a serious problem. People don't filter bullshit enough.

And in case you wonder, bullshit-filtering is a very good use of swear words.

[computerquip]

It's not so much the disk space that's the issue, it's what the features do, maintaining the code of those things, and the other system resources those things end up consuming. With Canonical now supporting systemd, it will get bloated much faster. It might not hit 30MB in 5 years, but as long as any of the "unnecessary" features (such as systemd's networking capabilities) get screwed up, it could cause issues for distros like Debian, which will have to stick with a very old outdated version. By separating such things, a distro like debian could still use a much more up-to-date "systemd-core". It's all about maintenance, and something as critical as systemd needs to be fundamentally stable. You can't get that kind of stability out of features that don't HAVE to be there to begin with.

Good thing you can compile those unneeded features out.

[ryao]

I like Gentoo, and I'm very happy to see that reason is winning and now systemd is on equal footing with OpenRC there. It probably won't ever be the default, yes ? but neither is OpenRC, because Gentoo doesn't have defaults I also have two Gentoo systems I maintain, both use systemd, one of them uses Btrfs with Snapper. So I'm happy that not all Gentoo developers are like ryao...

You might want to rethink when you consider the fact that I am at least willing to tolerate such things in the tree. If the other developers were not like me, these things would *NOT* be in Gentoo at all.

[TheBlackCat]

if you don't like /proc, fuck you. thats how unix works and its a lot better than windows system calls AND osx, solaris, openbsd system calls for this.

You do know that osx, solaris, and openbsd are all unix, while Linux is not, right?