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:The abbreviated list

[Vectormatic]

What surprises me is no SLAX. When i first found it SLAX was a very usable live-cd which would fit on those tiny 8cm CDs (before large enough USB sticks were affordable enough to just have a few in your bag) and had an easy startup option to load the entire image into ram

Then i check it a few months ago, it now offers an interface on the website to select from a very large library of software, click the boxes you want and presto, instant live-image completely to your own taste

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!

Re:mod up

[JWSmythe]

I only did it to differentiate between those who have chosen to use Ubuntu, and those who didn't. I know Ubuntu is a pretty skinned Debian with some extra patches. Ubuntu patches on top of Debian patches, on previously good code, what could possibly go wrong. Oh, lots.

    It's similar to CentOS being a patched derivation of RHEL. It's another layer of people messing with perfectly good code, and making it not so perfectly good. In the list provided, there were no CentOS, RHEL, nor Fedora variations, so I didn't mention them.

    I'm anything but a fan of messing with someone else's code, unless it's for internal use. Sure, I'll make my own changes to your code, but I won't then distribute it as if it was as good as the original. I know there are a lot of authors and software companies/groups who agree with me on that. My changes are usually performance patches (as necessary), and usually commented in the code that the change may be acceptable. For example, here's one I use on Apache for my web servers:

cd apache_$apache/src/include ; cat httpd.h | sed -e s/HARD_SERVER_LIMIT\\ 256/HARD_SERVER_LIMIT\\ 4096/g > httpd.h.new ; mv httpd.h.new httpd.h.

    (that's just one line of my 152 line Apache/PHP/mod_ssl build script. It's 76 lines without the comments and stdout messages showing the status of the build)

  I don't pass it off my Apache as the official Apache version though. It's known if you use my Apache/PHP/mod_ssl build script, it will make some minor changes like this. If you use my build of Apache, it's a given I've made some changes. It's amazing, I can drop this on just about any server, and it's blazing fast compared to the RH provided one. I can't comment on what changes Debian or Ubuntu make to their installed version of Apache, I haven't needed to deal with that yet for a high load production environment.