Unusual, Obscure, and Useful Linux Distros 221
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."
Re:These distros should become meta-packages. (Score:3, Interesting)
How do you propose adding to Debian to make tinycore?
Re:The abbreviated list (Score:5, Interesting)
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
Ubuntu for Christians? (Score:3, Interesting)
Re:What is the definition of 'distro'? (Score:5, Interesting)
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!
So, after months, you get a good working environment running, and installable. Wrap it up, give it a version number, and make it available! Now you're just checking several hundred (if it's a thin distro) authors sites daily to make sure that the version you have is current. What? A new release? Great! The README said it was just a simple security patch, nothing to worry about, and it'll make our users safer. We'll just put it in the build environment, and put it out as a patch. Oh, you didn't do enough checking, and missed the fact that zlib 1.2.6rc1 breaks functionality in a dozen other programs. Back to contacting authors with bug reports.
I started on mine because I wanted to use Patrick Volkerding's (Slackware) method, but make sure everything was up to date, all the time, true to the author's code, with our own control over everything just in case something happened.
Doing your own distro is an awful lot of work, and I don't say that from lack of trying. Since my job wanted me to do more productive work for them, our own distro idea was set aside. In reality, it was a good idea for our company, it just wasn't practical. I could hire a staff to work on our distro, except there would be no way in hell to justify the budget for it. Parts of it remained useful. My static binaries were very useful for overwriting horribly patched binaries of other distros (who wants a boot loader that doesn't understand what a SCSI drive is?)
We reevaluated, and decided that Patrick and team over at Slackware really do a great job, and all we'd be doing is trying to duplicate what they've already been doing for years. Other distros have come and gone, but Slackware has always been there for us. Our "distro" became a customized Slackware install. We held it for in-house use only, and only loosely referred to it as our distro, but mainly "our own customized version of Slackware"
If you're going to customize a distro, sell it for what it is. If you made a uber leet customization of some distro, with spiffy keen custom skins, and a cool boot loader, just say so. "This is my customized version of [insert distro here]". If you made a custom installer for Windows, which put your own themes on, and your logo splattered all over it, sure as hell Microsoft would have their lawyers knocking on your door saying "That's ours, stop calling it l33tdoz. Here are our demands for damages. Pay up or spend the rest of your life in court." I know we're in the Linux community, so the ground rules are a bit different, but it's still not fair to the people who are putting the hard work into the project, for you to wrap it in your own pretty wrapper and call it your own, even with a mention on page 15 of your FAQ saying "this distro is based on Ubuntu"
[steps off his soapbox]
Comment removed (Score:2, Interesting)
TA Spring? (Score:3, Interesting)
I haven't checked on the TA-Spring (or simply the spring project) updates anymore... but a year ago, that seemed like one of the best (ever) real time strategy games - as far as I'm concerned up there with the likes of Starcraft... meaning it's up there with the popular windows games.
It has it's problems for the installation (you need separate bots, maps, and sets of units), but that's really why I was hoping to have it included in this gaming distro.
Slackware is even better now... (Score:3, Interesting)
Its always been a great distro for people who just want a stock Unix on their PC rather than a Wannabe-Windows clone but it was frequently a bugger to get some hardware working properly and also Xwin configuration was very tedious. I defected to Suse for a while because of this but now Slackware is more or less plug and play. I installed 13.0 on my Acer laptop and desktop Dell at work and it Just Worked. The only issue I had was with the wifi on the laptop but that was a kernel bug - I compiled a later kernel (yeah, slackware can still be hardcore) and wifi worked fine.
Re:mod up (Score:5, Interesting)
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.
Re:Slackware is even better now... (Score:4, Interesting)
What is it with Slackware that attracts so many wannabe "hacker" types like yourself? Those "Wannabe-Windows clones" you speak of can all be just as "hardcore" (as if compiling a kernel is hardcore in any way), and the only notable architectural difference between Slack and "Wannabe-Windows clones" is that Slack uses a BSD style init instead of the not exactly Windows-like SysV.
Yes, Slack is good and well respected, but I swear that among the clueless faux-elitist morons I've come across, more are using Slack than all the other OSes combined.
Nobody ever gives props to ... (Score:3, Interesting)
Comment removed (Score:3, Interesting)