Electric Sheep

I have been burned by *nix hybrids in the past. I had high hopes for the debian BSD project, however actually installing that left me in a pretty unusable state.
Nexenta is currently tempting me, an OpenSolaris/Ubuntu Hybrid with a sun kernel and the ZFS file system, as well as the very usable Gnome interface. It remains in alpha state. The installer is not the ubuntu installer, but instead a text based installer similar to BSD projects. As the sun kernel does not have as much FS support as the linux kernel, your choices are basically ZFS or nothing. Which is not going to make a lot of users happy.
My problem with projects like this is that they don't usually stand a chance of swaying users from each of their component camps. The solaris people are not going to move to Nexenta as there are no man pages (license issues), the GNU people are not going to move due to a lack of apt-get (license issues) and the fact that a majority of GNU people seem to be perfectly content with the highly configurable 2.6 series Linux Kernel.
It remains to be seen when Nexenta moves out of alpha and hits beta status.

In software development, there usually comes a point where you stop working on features that are draining resources, and focus on getting the features that can be finished on time done.
However, I don't see this happening in linux, as there will always be someone using a software project, linux distribution, or project fork that will disagree with the decision to cut it. As the leading figures tend to listen to these users more frequently than not, there is a great deal of effort spent on them that could be better spent on a different area of linux.

Since there is no real one true leader (some would say Linus Torvald, but he really makes strong suggestions, not commmands or decrees) there is no one to force consensus. Take a look on sourceforge for projects that have not been touched in years and you will find more than a couple. As the developers realize just how much effort is required to support different versions of linux, and adapt to changes on dependencies like glibc or gtk, they may realize that if they working this hard they might as well get paid for it. This will lead to both a decrease in the size of the linux volunteer army, and a potentially abandoned project.

The many different distros of linux are both a blessing and a curse. Projects like Slackware are not very user friendly, but still have a very passionate base. But ask yourself, would you rather have a niche distro? or a more complete installer and hardware detection scheme for a more wide-scale distro? Is there even a way to make everyone happy here?

There seem to be two main camps regarding package management.
Install from sources
Install from binaries.

This makes a big difference when one of two things: dependencies and updating.

Now, I prefer the debian way in this case. apt-get install and then apt-get dist-upgrade as wanted. this works for other packages installed the same way, when it causes problems is if you compile something from source on the same system. When debian recently released 4.0, my routine updating of the system caused some problems with software that xenotrope had compiled from source. why? glibc had been updated.

now with the BSD or gentoo way, this wouldn't really be a problem as the binaries would be compiled from source every time. However, this has caused me to get tired of BSD's ports system. installing the simplest package can take ages as all dependencies have to also be compiled. Now the latest version of FreeBSD claims binary installation and updating for its ports system. Arguably apt-get on debian already has this as you can specify apt-get install to install and compile source. are we seeing convergence to a standard?

Elatte may have been what I have been waiting for. Ubuntu with an opensolaris kernel. I had my doubts, as it was in alpha stages, but I have high hopes.

The Good:
Autodetects 64 or 32 bit systems.
Very fast
apt-get dist-upgrade works
runs under vmware

The Bad:
limited selection of software
/proc just ain't the same
no lsmod/rmmod/insmod

I realize the last two of the bad are pretty much no-brainers, but I figure if they made such an effort to make the system linux-like, they would make some kind of virtual redirectors or something. I was amazed at how fast the install and execution were.

further experimentation is necessary.

Behavioral experts agree: you never ask your kid what he wants to wear to school. Children, with their under-developed cognitive skills, don't quite possess the abilities to narrow down the options in their closet and analytically eliminate choices until they can conclusively pick the blue pants and the red shirt.

A young brain just spins its wheels when presented with a seemingly limitless number of choices. It does not know how to perform the process of elimination. Instead, you are supposed to eliminate choices ahead of time. You ask the child "Do you want to wear the red shirt or the green one?" Presenting fewer initial choices makes for an easier problem space for the brain to navigate.

Personally, I have about sixteen different ISOs scattered on my hard drives. I have a couple of Ubuntus for a slew of different architectures, at least five Kubuntu live CDs, a few openSUSE distros, probably two different versions of Arch, and something called "Sabayon". Last time I checked, I still run Windows. I'm happy to download these things left and right — hell, it almost justifies my bizarre obsession with BitTorrent — but I have yet to actually pick a distribution that I can stand.

I don't even have a particular requirement that the ISO I download fit an architecture I currently own. I find myself frequently eying the purchase of a new system or contemplating what it would take to assemble a new PC from parts. Ultimately, I always seem to decide that both of these things demand too much effort, and I subsequently wind up going home to my old, reliable Pentium III and forgetting the whole matter for about two weeks.

x86 has won. Really. Yeah, your port of linux to the PS3, or the ARM, or the toaster, or your dog is neat and all, but are you really going to spend the time and effort making sure it stays maintained?

This past weekend I tried getting X working on an ultrasparc 80. X.org has a wonderful bug where it can't handle how sparc's divide up PCI slots. it isn't rocket science: 0000 or 0001 as the prefix for the address. However this will be broken until (at least) X.org 7.3, which won't really be in any distros until, say, July at the earliest. If you look at the alpha releases of ubuntu, they haven't even bothered to release sparc at the same time as x86 and x64. there are a good number of sparcs out there. So I can only imagine what the story is like on rarer hardware platforms.

My proposal is to consider doing what microsoft did. Microsoft NT used to be available for MIPS, PPC, and X86. It was frustrating as you had to test and maintain all of them. Finally the axe was dropped and x86 became the only survivor (yes yes, later x64 and IA64 were added, but x64 is an extension of x86 and IA64 has intel jumping up and down on its chest to keep the heart beating.

Imagine all the effort and work being done on weird platforms that instead could be done on focusing on x86. You can't use the mac argument anymore as the macs are running on x86. If linux wants to be really dangerous, it needs to focus. Focus on a few key architectures. Go through freshmeat or sourceforge and kill the dying or abandoned projects. lean. mean. fearsome. consolidate your distros to 3 or 4 major ones and let the others inherit from those.

After hemming and hawing for a while, I finally gave in and put DroboApps on the Drobo.
The result:

$uname -a
Linux DroboShare 2.6.12.6-arm1 #1 Fri Sep 12 16:36:22 PDT 2008 armv5tejl unknown

So the droboshare is actually an ARM system? Interesting.
yes, you can run SSH and BASH on it, making it a good emergency system and the /bin directory is populated nicely.

this also allows Jumbo Frames for Gigabit, setting the MTU at around 9000 or so. which I notice has really sped up network communications between my main box and the drobo.

The developer community has not exploded like I thought it would. This may be due to the relatively low number of drobo users, but that number is getting bigger with time. I have no idea about how easy the SDK is to use, but I am tempted to take a look. Folding at home for Droboapps anyone?