[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: portability improvements for non-Linux systems
From:       Rob Landley <rob () landley ! net>
Date:       2010-03-30 3:57:30
Message-ID: 201003292257.30837.rob () landley ! net
[Download RAW message or body]

On Wednesday 24 March 2010 07:14:37 Jérémie Koenig wrote:
> Hello,
>
> As part of my preparation for porting debian-installer to the Hurd (as
> a Debian GSoC project),

Why?

> I'm not sure whether non-Linux support in general, and Hurd support in
> particular, is a priority as far as your project is concerned, however
> I would be grateful if you could review those and consider including
> them.

It's really up to Denys, but... why Hurd?  I honestly don't understand why 
anyone, anywhere, would care about that project anymore.

There are plenty of non-Linux projects I can understand people being 
interested in, but you have to dig down a long, long way to get to The Hurd.  
Starting with the more interesting stuff (and skipping the closed source stuff 
entirely):

Darwin would be pretty interesting, because that's MacOS X.  If I ever wind up 
getting a Mac (which I've been vaguely planning to do ever since GPLv3 came 
out, but haven't done yet), I may port it myself.  Lots of users, and the 
iPhone is huge.  (Ok, it's only interesting because of a closed source thing 
built on top of it, but still.)

Various "bare metal" variants like newlib/libgloss take the embedded thing and 
run with it.  The Linux kernel _is_ currently a megabyte with "allnoconfig", 
wanting to run on the bare metal is an understandable impulse, and a lot of 
people do "boot to ELF and have libc talk to the hardware".  It's generally 
single process nommu, but we've already got some rudimentary nofork support in 
the shell.

Android has significant corporate backing (even if they've stupidly paintained 
themselves into a corner as far as the Linux community is concerned, which is 
probably going to come back and bite them hard in a year or two).  The tweaks 
to support android are slightly _less_ stupid than SELinux support (which is  
definitely damning with faint praise).

Minix at least has a reason to exist (it's a teaching tool, intentionally kept 
small enough that you can read and understand its entire source code in a 
single semester).  If they were interested in using busybox source for 
educational purposes, I could see somebody maintaining a port.  (Hey, students 
cleaning up our code for readability.  We could do worse.)

FreeBSD probably comes next, although the interest is definitely starting to 
flag by now.  On the plus side it might share a lot of code with MacOS X.  On 
the minus side, it will never amount to anything because every time a BSD-
licensed OS gets any sort of commercial viability it has its senior developers 
hired away to work on some proprietary fork by whoever's trying to cash in on 
it this week, and its open source community then spends a decade rebuilding.  
(Examples: Sun hiring Bill Joy in 1982 to work on SunOS, BSDI hiring the 
remains of the CSRG around 1990 to do a proprietary BSD/386 and thus derailing 
Bill Jolitz' open source work for a fairly critical couple years, Apple hiring 
Jordan Hubbard and such to work on MacOS X around 1998...)  Maybe the fourth 
(fifth?) time's the charm, but BSD is actually _less_ popular today than it was 
a quarter-century ago, and it's hard to get particularly excited about that.  
(It also isn't used much in the embedded world, either.) 

OpenBSD, NetBSD, Dragonfly BSD, and so on are similar but less interesting than 
FreeBSD because even fewer people actually use them anymore.  OpenBSD had to 
do a "save us from going under or we'll take OpenSSL with us" begathon a few 
years ago, NetBSD was declared moribund by one of its founders, and Dragonfly 
was apparently started rather than participate in any of the other existing 
projects.  Still, people submit patches from time to time.

OpenSolaris is less interesting than any of the above, since its userbase 
largely seems to consist of people like Jorg Schilling who hate each other, 
the Project Indiana status page was last updated in 2008 and I'm not sure what 
their direction is supposed to be now, and now with Oracle having bought the 
sucker its future would be in doubt even if it hadn't been essentially 
stillborn.

_All_ of that is more interesting than The Hurd.  The hurd has never been used 
to actually do anything, that I am aware of.  It's never even been a serious 
basis for research, it's not a teaching tool, it has no production niche on 
desktop, server, embedded, supercomputing...  It exists because Richard 
Stallman has a massive "not invented here" thing going on with both Linux 
_and_ BSD.  He wanted to respond to AT&T's license change back in 1983, made 
an incredibly bad technical decision rewriting the monolithic alix kernel into 
a microkernel (see the tanenbaum-torvalds debate for why that's a bad idea for 
anything _other_ than a teaching tool), and twenty years later he refuses to 
admit that the project _died_ in the late 80's.  It's like one of those people 
living with the mummified corpse of a relative and pretending they're still 
alive.  It's embarassing.

Now I admit it's hard to kill an open source project.  FreeDOS development is 
still active, the ELKS project ported Linux (more or less) to the 16-bit 8086, 
Haiku is doing a decent job of cloning BeOS, AROS is trying hard to clone 
AmigaOS, and so on.  Presumably all this is for the same reason there are 
multiple emulators for the MITS Altair, and an actively developed multitasking 
operating system for the commdore 64: http://en.wikipedia.org/wiki/GeckOS

But given a choice between The Hurd vs Geckos, the latter seems like a 
slightly more interesting project...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

[prev in list] [next in list] [prev in thread] [next in thread]