On Fri, Feb 24, 2012 at 04:20:47PM +0200, Uoti Urpala wrote: > Roger Leigh wrote: > > I certainly don't think it's fair for fairly niche platforms to hold > > back Linux indefinitely. There is a high cost on maintainers to > > support these platforms, and it would be an ideal situation if > > systemd or upstart were sufficiently portable to run on them, even > > if they didn't support all the Linux-specific features they offer > > Portability is not necessarily a positive attribute. When you're talking > about standard functionality available on all platforms, it's cleaner to > write it using standard interfaces that work everywhere. But if the > platforms do not support the same things, then portability often > requires platform-specific hacks, special cases and limitations. A > systemd that tried to work on BSD kernel would be less reliable, less > maintainable and harder to debug. I wouldn't want my Linux system to run > an init process hacked for BSD portability.
All our software has some element of portability hacks in it. Here's a trivial one from schroot: #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) (this->get_device()).is_character() #else (this->get_device()).is_block() #endif Disc devices are character on FreeBSD, rather than block. So we work around that fact. Big deal. Once that's done, it works perfectly on both platforms. Taking the stance that there must never, ever, be any platform- specific hacks is both extreme and counter-productive. If you want your software to be usable outside your own world, you have to make some compromises. > > [note: it's somewhat desirable for them to be optional on Linux > > too, to prevent feature lock-in and future compatibility problems]. > > Unix kernel development outside Linux is pretty limited, especially > development for features other than server use. I think "avoid requiring > Linux-specific features" would turn into "avoid technology developed > after the 90s". This is missing the point. I'm not saying "don't use Linux-specific features", I'm saying that use of Linux-specific features should be /optional/, even on Linux. Only use them if present. Let's take cgroups as an example. They are an optional feature even on Linux. By mandating them systemd may be painting itself into a corner given that they might be removed or replaced with something better in the future. If they are present, by all means use the facility. But don't create the seed of a future maintenance nightmare. This doesn't just affect systemd, it affects the kernel indefinitely since we can't break working systems by removing the feature. This applies to all use of Linux-specific APIs: don't be too clever--it will come back to bite somewhere down the line. Asking this sort of question about systemd isn't stupid--there are long-term issues which could arise from short-sighted decisions by the systemd developers in the short-term. It would greatly ease its adoption if they would be given due consideration. And this includes portability to other systems just as much as it does to future versions of Linux. I would love Debian to adopt systemd (or an equivalent). But I really can't see that happening without a change in attitude by upstream. Portability to other systems is really just a special case of portability to future versions of the Linux kernel. Things can and will change, and systemd needs to make sure it doesn't break horribly when it happens. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120224212719.gj24...@codelibre.net