Choosing between portability and innovation

Posted Mar 4, 2011 9:27 UTC (Fri) by liljencrantz (guest, #28458)
Parent article: Choosing between portability and innovation

Rarely tested code is a breeding ground for bugs. Abstraction layers and compatibility layers tend to consist mostly of edge cases and rarely tested code. They cause significant amounts of bugs.

The best approach that I've found is to decide on an API to code against, preferably the API of your main target platform or at least something very similar to it. Any porting effort should then concentrate on providing that same API, even on platforms that are missing critical libraries. The upside of this is that you write your regular code just as if you where only targeting a single platform. Any bugs caused by the porting effort are unlikely to be noticed on the main platform, and neither does most of your users have to pay for the overhead of routing every system call through endless layers of abstraction.

As for whether it is actually worth bothering to port applications to less used platforms, I think the answer has a lot to do with what type of application you're writing. systemd is pretty tightly coupled to the Linux kernel. It relies on many features of the Linux kernel that only have very rough equivalents on other platforms. While it would be possible to provide a unification layer that made systemd run BSD, doing so would likely be more work than rewriting systemd from scratch for BSD. This is not the case for higher level applications like emacs or Firefox. While they occasionally make use of low level kernel interfaces, that is the exception rather than the rule. I think we should accept that some subsystems, even though they run in userland, are tightly coupled to a specific kernel. It makes sense that init should be such a subsystem.

(Log in to post comments)

Choosing between portability and innovation

Posted Mar 4, 2011 12:26 UTC (Fri) by nix (subscriber, #2304) [Link]

Agreed. It's not like sysvinit ran on non-Linux systems either: they all have their own inits.

What *would* be nice is, when systemd calms down a bit and we start to see which of its features are used by other programs, if some other inits could start to gain those features. (I've never heard of another init-like program which could even be described as having features that other programs could use. systemd is a big step forward in that way.)

Choosing between portability and innovation

Posted Mar 4, 2011 17:44 UTC (Fri) by dlang (subscriber, #313) [Link]

I almost agree with you.

the thing is that the API you code to should be flexible and evolve over time, with some of the abstraction layers that others have mentioned being in the API -> platform level

In the end your API may not directly match any of your destination platforms.

the linux kernel does this. Linus has said in interviews that the kernel is not written directly for any type of system, but instead is written for an idealized system that doesn't actually exist, with 'shim code' on every single platform (including x86) to simulate portions of the 'system' the kernel is written for. He says that the kernel is much better as a result of this work.

Choosing between portability and innovation

Posted Mar 9, 2011 17:50 UTC (Wed) by schabi (guest, #14079) [Link]

I agree here.

But note that there is a huge difference between writing "non-portable" code targeted for an idealized platform (with a PAL in place to emulate that platform in the real environment), and writing with portability in mind (hundreds of #ifdefs, missing functionality, etc.).

Choosing between portability and innovation

Posted Mar 9, 2011 23:44 UTC (Wed) by nix (subscriber, #2304) [Link]

Writing with portability in mind does not imply 'missing functionality' (on platforms capable of it), and *certainly* does not imply 'hundreds of #ifdefs'. Indeed, the latter is generally a symptom of software that was not written with portability in mind, but which had limited portability jammed crudely into it at a later date.