| |||||||||||||
If you want portability - use OpenSSH model...If you want portability - use OpenSSH model...Posted Jul 30, 2011 6:40 UTC (Sat) by khim (subscriber, #9252)In reply to: Debian debates systemd by dlang Parent article: Debian debates systemd
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.
(Log in to post comments)
If you want portability - use OpenSSH model... Posted Jul 30, 2011 16:09 UTC (Sat) by jch (guest, #51929) [Link]
> 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?
|
|||||||||||||