The return of the Unix wars?

Quote: "The notable exception, of course, is Android, but that may well be the exception that proves the rule: only a company with the financial resources of Google can hope to take on responsibility for that much code and hope to maintain it over the long term."

If you start studying (or working with) the internals deep enough, you'll find out that Android is full of stupid technical decisions which cannot be sustainable in the long run. Having a Google-sized budget helps but there are some really weak links in there.

I'll give two examples: the first one is Android's C library, Bionic. It seems like Android wanted to avoid using GNU libc just to avoid the need for having to upstream local changes due to GPL licensing in glibc. So they went ahead and wrote a friggin' C library, arguably the most peripheral and boring of all the software components in an operating system. And also one that's quite laborious to put together and maintain. It takes special character to do that. Ask Ulrich Drepper.

You may argue that Android doesn't need all of glibc or that Bionic does it's job. From a customer perspective that may be true, but a customer does not see the libc anyway. But in reality, there's lots of hard work going on every day to ship products with Bionic. I've been watching that happen a lot recently. A lot of these issues seem to be related to threading and C++ ABI issues. The issues that glibc was struggling with 15 years ago.

Another bad example is Android's 2d graphics library, Skia. It is the reason why Android home screen looks so crappy slow compared to certain competing products. It has a similar API to a lot of graphics packages that were popular in the 1990's. It includes bitmap blitters and so on. They have some optimizations to use NEON SIMD instructions, but it's inherently a software (CPU) graphics lib. The synchronous API offers no opportunity for hardware acceleration. I am under the impression that Skia would be going away from Android and that's a good thing.

I promised two examples, but I'll give one for a bonus: Android's proprietary interprocess communication mechanism that's implemented in the kernel (can't remember it's name). It was designed to avoid a memcpy call when passing stuff from one process to another. That was a reasonable solution with slow uniprocessor computers of early 2000's but that ship has sailed. These days this kind of things are better done in the user space, like Dbus, which is used by most desktop (and some mobile) linux distros.

Whoa, what a rant. But it only tells one thing: I'd much rather work with a GNU/Linux system than an Android one.

From an end user's standpoint, this is completely untrue. Just look at the various package management software and philosophies across all of the distros. It's a mire.

As I've gotten more experienced I have come to appreciate how much some folks care and how little others in the same space do. Makes for an interesting path.

Looking at Linux distros I can easily see folks committing stuff who think Windows 'did it right', the same with folks who felt OSX 'did it right', and yes folks who felt that SunOS/IRIX/Ultrix/What have you 'did it right.' All that really tells you is that there are several right ways. Perhaps most telling is to watch arguments where the parties are arguing from two different places and talking right past each other.

The result however, in a FOSS world, is you get to see all of these visions of what is 'right.' But its not so much a war as it is a sort of dysfunctional anarchy.

In the article, the author notes, but doesn't call out, the difference between a Linux distro and Android, or Tizen, or WebOS, is that the former often has a group of equal committers and the latter has a person/organization that is driving to a particular vision/goal. So while one can rant about how Android sucks as a desktop OS, or Ubuntu sucks as a Phone OS it doesn't really inform the conversation much.

I believe that we will see the emergence of a 'read-only' FOSS project, in the sense that it gains traction, is 'open' in the sense that you can get the code and all, but the leader doesn't allow any outside changes. Android and Chrome both have some of this feel.