Debian debates systemd

Posted Jul 29, 2011 10:10 UTC (Fri) by danieldk (subscriber, #27876)
In reply to: Debian debates systemd by dlang
Parent article: Debian debates systemd

But the standard can only evolve when at least someone is doing something new. So, either all members of the SUS committee should jointly dream up new features (without real-world evolution), or a member should try a new feature in their system and attempt to standardize it when proven successful.

Now, I don't who are participating in the SUS standard, but at least one vendor of a SUSv3 system (Apple) is adding features (not all in the realm of SUS) that are not standardized rapidly. Also, in GNU systems, there is precedent, e.g. think of gcc extensions to ANSI-C that a lot of software has come to rely on.

Debian debates systemd

Posted Jul 29, 2011 23:59 UTC (Fri) by dlang (guest, #313) [Link] (3 responses)

> But the standard can only evolve when at least someone is doing something new. So, either all members of the SUS committee should jointly dream up new features (without real-world evolution), or a member should try a new feature in their system and attempt to standardize it when proven successful.

yes, people should try out new things and push to get them standardised if they work well.

Linux has been doing this since it started.

> Also, in GNU systems, there is precedent, e.g. think of gcc extensions to ANSI-C that a lot of software has come to rely on.

many of these GCC only features are getting standardized in the latest C spec revisions.

the issue is not the existance of non-standard features, it's in not writing (or being willing to accept patches to provide) fallback routines that will let the software continue to function without these features.

If you want portability - use OpenSSH model...

Posted Jul 30, 2011 6:40 UTC (Sat) by khim (subscriber, #9252) [Link] (2 responses)

the issue is not the existance of non-standard features, it's in not writing (or being willing to accept patches to provide) fallback routines that will let the software continue to function without these features.

This is how OpenSSH is developed. Yet it's the most portable and useful ssh client today. How? Easy: separate team collects patches and publishes "Portable OpenSSH". Which is two times as big as original OpenSSH BTW.

I can see why Poettering does not want to do 2x work (actually more since complexity is growing faster then number of LOC) for the same gain so if other people will want "portable systemd" they'll need to create these fallbacks themselves.

If you want portability - use OpenSSH model...

Posted Jul 30, 2011 16:09 UTC (Sat) by jch (guest, #51929) [Link] (1 responses)

> I can see why Poettering does not want to do 2x work

It's always a dangerous exercice to try to double-guess an author, but from reading the systemd code I get the impression that he's deliberately using non-portable features, with relish. (See for example the systematic use of the "%m" printf descriptor where strerror would do just fine. 302 occurrences.)

The other reason for non-portable code, of course, is that systemd is doing a lot of low-level system stuff that usually belongs in separate utilities. Much of that could probably be compiled out if Poettering were to accept patches that optionally disable parts of systemd functionality.

-- jch

Why should not he?

Posted Jul 30, 2011 19:48 UTC (Sat) by khim (subscriber, #9252) [Link]

It's always a dangerous exercice to try to double-guess an author, but from reading the systemd code I get the impression that he's deliberately using non-portable features, with relish.

Quite acceptable choice if you decided from the start that you want to keep things simpler and don't care about portability.

See for example the systematic use of the "%m" printf descriptor where strerror would do just fine. 302 occurrences.

Yup. This means he was able to save few keystrokes 302 times. Good for him.

The other reason for non-portable code, of course, is that systemd is doing a lot of low-level system stuff that usually belongs in separate utilities.

Yup. But again: separate utilities are useful if they can be tied in different ways. If you only have something in separate utility to make porting easier then you make the whole system more complex for the sake of portability - and we already know Poettering decided to put simplicity ahead of portability.

Much of that could probably be compiled out if Poettering were to accept patches that optionally disable parts of systemd functionality.

Again: it complicates the whole thing for no apparent benefit (if you don't view portability as benefit in itself).

I've pointed to the openssh for this exact reason: portable version is quite literally 2x in size compared to non-portable version. OpenBSD version 5.8 is 81386 lines, portable version 5.8p2 is 169155 lines; of course there are a lot of autogenerated autoconf lines - but even so some 29660 lines change .[ch] code. I'm pretty sure "portable systemd" will differ from "non-portable" one similarly or even more - for the simple reason that it needs to deal with lots of low-level stuff. If people want to see such changes - they can create "portable systemd", no problem, but why should upstrem version be complicated for the sake of 1% of users?