Unusual, Obscure, and Useful Linux Distros

angry tapir writes "Most people will be familiar with some of the big names when it comes to Linux — distributions like Ubuntu, Red Hat Enterprise Linux, Debian, and Mandriva. Most of the well-known Linux distros are designed to be used as general-purpose desktop operating systems or installed on servers. But beyond these distros are hundreds of others either designed to appeal to very specific audiences or to fulfill the somewhat niche needs of some users. We rounded up some of the most interesting Linux distributions that you might not have heard of."

Comments

Re:What is the definition of 'distro'?

[JWSmythe]

It only took 12 hours for the site to load, but lets have a look at the "distro" and their roots.

Damn Vulnerable Linux unknown
Tinfoil Hat Linux unknown
CAINE Ubuntu
CAELinux Ubuntu
Ubuntu Christian Edition Ubuntu
live.linuX-gamers.net unknown
Parted Magic Ubuntu
GMusix GNU+Linux Debian
Zeroshell Linux LFS methods (i.e., actually rolled themselves)
Mythbuntu Ubuntu
Damn Small Linux Debian
Tiny Core Linux unknown

Ubuntu 41.6%
Debian 16.6%
--------------
Known Distros 58.3%

Unknown distros 33.3%
Original works 8.3%

Feel free to reply with updates if you know the origin of the unknown's.

I know from personal experience, rolling your own distro is hard work. I tried, using other distros (Slackware and LFS methods) as a guide. Just taking someone elses patched beyond usefulness sources and calling them your own isn't your own work. You aren't building, and you can't go back to the original author and submit a fix. Mine was to stay true to the original author's work, since I've seen so many problems which are directly (correctly) attributed to some distro haphazardly patching (and breaking) things.

I spent a lot of spare time writing and rewriting build scripts, hunting down sources (real quick, where is the authors site for the most current version of "ps"?), building a build environment, building the sources into installable packages. It sounds like an awful lot of fun, until you've already spent a month putting things together, and you've just gotten past the low level stuff (basic system utilities, filesystem utilities, compilers, major required libraries, and the boot loader of your choice). Wow, a month later, and we don't even have X, a desktop manager, or occasionally useful things like a web browser. Now you have to go back and check all your versions against the current version available from the author. Unless you have a rather dedicated team of folks with no day jobs nor personal lives, you'll spend your days just verifying that your packages are built from current sources.

God forbid there's a change in say glibc, which breaks some other application. Now you're notifying the author of the application, which can be a job in itself to go back and forth with them about what distro you're running (built it myself). Oh, you're own? That's good and bad. What versions of the compiler and required libraries are you using? "Sign up to my mailing list, so we can all work on it." Two weeks later, you may have a patch which may become a released version two more weeks later. If you're a good guy, and somehow have way too much time on your hands, well versed in every programming language and methodology, a genetic disposition to not sleeping, and a serious speed habit, you may be patching it yourself, and handing that patch up to the author. What? Your patch was refused because it didn't follow his methodology? It doesn't work in recursion and will break older distros (like the one right before the glibc update). Now you've fallen into what others do. I'll patch mine, but just this one, I swear. It'll be the authors true code when he releases the right fix. On to the next!