Archive for the ‘damn small linux’ Category

Addressing More Search Engine Hit Topics

May 7, 2010

I continue to get frequent traffic relating to Damn Small Linux. Some of the more common search engine hits are like this one this morning:

damn small linux dead?

The answer to that is, “Yes.” If John Andrews is doing any work on it, he’s not been very open about it in the DSL forums. In fact, his last message about DSL’s future was in December of 2008. I also haven’t seen any posts about new extensions, updates, anything.

I also get lots of hits about ext4 support in DSL. As I wrote back on April 18th, DSL had limited filesystem support in its base and even via extensions. I don’t know if ext4 can even be supported with a 2.4 kernel.

Which brings up another area of DSL-related hits here. There seems to be some interest in a 2.6 version of DSL. That’s funny because there was a 2.6 side project called DSL-N. As it hasn’t been updated in years, either, consider it dead.

Anyone desiring “updated” DSL would do well to consider TinyCore, which is developed by Robert Shingledecker, who was responsible for most of the innovations and development that made DSL popular, and a very talented team he’s assembled. Its philosophy is a bit more radical due to its modularity than  DSL but anyone who ever got into DSL should find the transition easy.

Finally, I have good news for people ending up here looking for information about Scientific Linux 5.5. I saw yesterday that it’s out of beta and the mirrors now have release candidate 1. I can’t speculate when it’ll hit release and it should be a few days later if you want a SL55 live CD image. CentOS 5.5 should be out soon, too; Karanbir Singh’s latest update was, “We are working up to a release in the next few days.”

Fixed and Opened “My DSL Pages”

April 19, 2010

I’ve taken care of one of the things that’s been on my to-do list for way too long by fixing and making “My DSL Pages” public. It had been set on private due to a number of issues with the page. Some of the older content from my previous host’s demise remains broken, but I think I now have each page linked correctly on that one.

Some of the content is related more generically towards JWM and other things which go beyond the narrow focus of DSL so at least it still has some use and life after DSL’s untimely demise. Many of those pages continue to receive hits on a frequent basis both from search engines and from links at the DSL forums; I guess it’s being put to use (whether it’s good or not is probably very subjective).

DSL and ext4 filesystem

April 18, 2010

Did that title get your attention?

Just a quick note based on something I’ve been seeing a lot more of lately in search engine hits to this blog. I’m getting daily hits for at least three of the four words in the title of this entry. Some days it’s just one or two. Some days it’s quite a bit more.

First and foremost, Damn Small Linux is dead. It has not been updated in over a year despite the founder’s claim in December of 2008 that he was looking into how he was going to move forward with development. Second, I don’t think ext4 is even supported in kernel 2.4. That means you’ll more than likely need to upgrade kernels (even if 2.4 does have support for ext4 now). If you have to upgrade to a 2.6 kernel, you’re probably still screwed because it’s not as simple as swapping out kernels. That’s probably more true for something like DSL which really needs some freshening up in the base anyway.

I don’t know if people are looking to mount existing ext4 partitions as ext3 under DSL or if they want to use ext4 as a filesystem for DSL. In my opinion, either way is foolish. DSL had very limited filesystem support in the base and beyond a few filesystem tools extensions. Regardless, you’re probably better off looking for more sensible alternatives that wouldn’t require the work DSL would just to handle ext4 partitions.

Update 20100209 – Debian Lenny, TinyCore, emacs, ratpoison, oroborus, and security of small distros

February 9, 2010

I’ve intended to sell this thing but haven’t yet. I updated my AA1 page last week to reflect the fact that I really don’t run Linux on it anymore. I still have {Tiny,Micro}Core set up on it, but I’ve booted that maybe three times in the past few months including once this morning to get my emacs-related files. I don’t know if the issues with wireless were related to the network stack, the ath5k driver itself, wpa-supplicant, or a combination of factors. For the last time, it’s NOT a hardware issue because the problem never happened (meaning started) under Windows; it only happened (started) under Linux and persisted after rebooting. I occasionally boot TinyCore from a USB stick on my other computers (see below).

New Desktop/Workstation
It came with Windows XP Pro installed. I first installed Scientific Linux 5.4 via the live CD, which provides a Gnome desktop. I’ve already posted about adding an old hard drive that had OpenBSD 4.3 on it, on which I installed NetBSD 5.0.1 after backing up $HOME. I’ve been too busy to even update SL54 (which I know has updates because I was also running it on my new-old laptop for a while), let alone configure NetBSD beyond the basics (e. g., setting up my network card even though it’s not yet networked, SSH, etc.). I’d hoped to set it up further this past weekend but I’ve been eye-deep in a stack of reports to edit and charts to generate.

New-Old Laptop
I’m still using Debian Lenny, which I installed using net install. I let it go ahead and install the default Gnome desktop even though I initially thought about just doing a minimal installation and adding what I wanted. One of the reasons I did that is because life has been so hectic the past 18-24 months that I care a lot less about bloat than I do about the convenience factor and having everything ready to roll. Otherwise I’d already have the other computer set up and ready to roll, no?

I have switched some apps around, though. I was using xemacs but decided instead to revert to GNU emacs 21.4 from backports so I’ll have more of the modes I’ve come to take for granted and which require either finding via apt or from their developers. I’m posting this now via weblogger.el (which I’ll have to clean up later) from within emacs. I’ve also installed oroborus and am using it instead of metacity within Gnome (edit ~/.gnomerc to include a line “export WINDOW_MANAGER=oroborus”); this is RAM-sparing to some degree but not nearly enough. I already have ratpoison installed as well, and will more likely than not start paring down on the Gnome bloat as I find time. I’ve been running ratpoison mostly under another user account.

Other Computers
My ancient ThinkPad got a minimal install of Debian Lenny several months ago but hasn’t been booted in at least a month. I may use it for TinyCore. Or as I’d intended with Lenny just to be a temporary HTML/blog server for home use. I may just use MicroCore if I do that.

Nothing to report on my old MMX box. I haven’t booted it in so long I don’t even remember what it has on it.

Unfinished Business
Speaking of {Tiny,Micro}Core, I started on a screencast/presentation back before Christmas that I alluded to at least once here. I’ve been too busy to finish it. It’s in response to a question that was asked at the TCL forums about using TCL as an enterprise Linux replacement. I wanted to demonstrate beyond the more obvious answers why I thought it was unsuitable and worked out a quick and dirty concept to show how vulnerable such a distro — based basically on one file — could be. This kind of goes beyond the security of the image being read-only and, accordingly, being able to reboot into its original state; instead, I wanted to see how difficult it would be to take advantage of the fact that the image is on a read-write partition which can be mounted by user tc locally or remotely and then replaced. My little POC requires user interaction at this stage (which was in maybe 20 minutes’ work) to basically get a corrupt image to replace the original so that each subsequent booting of it isn’t actually the “pristine” original tinycore.gz image but instead the corrupted one (which could have any variety of “reconfigurations” in it, but mine basically pings another computer when it has an IP and has a message stored in a file stating what changes have been made to the original image).

I haven’t decided if I’ll go through and see if I can get it to work remotely without user interaction. Even if I do that, I won’t post it here. Sorry, kiddies.

Since these small image-based distros typically lack logging facilities, it would be trivial to pull this off and possibly leverage vulnerabilities in various packages to further make a mess of it. The smaller the distro’s base image, I think the less noticeable it would be. With my download speed, I can download the TinyCore image in just a few seconds.

Also, I tested this on USB. It’s trivial to test if something has been booted from sd{a,b} and contains a directory named boot containing a file called tinycore.gz. The same applies to other small distros which similarly use one file to store the operating system, allows full sudo (or, in the case of some like Puppy, root only), etc. Even though something is running from RAM, it’s still found on a storage device attached to the computer and can be mounted (unless it’s quickly removed). So I don’t think this is inherently more secure than anything else (or inherently secure at all), and the smaller size could be a disadvantage since it would take less time to download and be less likely to be detected by most users.

As improbable as it is that such things can be accomplished without some kind of user interaction or physical contact with a USB stick to install a corrupted image, it’s still possible. Add in potential vulnerabilities from various packages — including browsers, improperly set up servers, etc. — and the possibilities increase both locally and remotely.

No, the sky is not falling, but there is a potential for risk even though the image itself is read-only. The image may be, but its partition isn’t. The risk may be acceptable for most uses. It isn’t acceptable for enterprise use — not without some kinds of safeguards that enterprise distros have to help reduce problems like this from occurring.

I’m not knocking these small distros. I think they have a special niche, but too many people think they can be one-size-fits-all. Enterprise-grade distros — including RHEL and its clones, SLED, etc. — have a variety of safeguards that would be “bloat” in something designed to be small and minimal. Adding those things to a minimalist distro would seem to be counter to their very purposes. That includes everything from security enhancements to logging facilities (you really do want to know who logged into which computer at what time on what day, and having every user named “tc” can’t be of much use if you need a chain of custody for various computer records, file records, changes, etc.). Moreover, the packages or extensions these small distros offer typically don’t undergo the same level of testing as in enterprise distros, are more often than not bleeding edge rather than tested and stable versions, and aren’t signed. Even signed/trusted repositories aren’t free from trouble as the RedHat/Fedora people found out a couple years ago when their mirrors were compromised.

I’ll see if I can finish the presentation and get it posted soon. Then again, I thought I would’ve had that done a month ago. Stay tuned.

Not Updating DSL Hard Drive Guide/PDF and Discouraging Hard Drive Installs Due to Security Issues

August 24, 2009

In light of the security issues affecting Linux 2.4 and 2.6 I wrote about yesterday and due to the fact that DSL’s development is inactive (some would conservatively call it “dead”), I’ve decided against posting an updated guide for DSL hard drive installs. I’ve also added new warnings on the page linked on the right.

Some versions of DSL do have at least one of the affected modules in the base. I think it’s unwise to install anything which is no longer under active development, or which is operated by an absentee-owner who’s not exactly maintaining anything but revenue from his online store, ad placement, and clickthroughs. I doubt he’s following any Linux security news to see if his distro might need an update, and I don’t know that he’d get around to updating it anytime soon.

I was going to post a requiem for DSL several months ago when it appeared that it was no longer under development, regardless of what John Andrews may have written some nine months ago now to the contrary. I don’t think it would serve any purpose now. Its main developer has moved on to bigger (make that smaller) and better things.

There are many options which are almost as suitable for older hardware if the goal is a more traditional hard drive installation, but those options will wane in coming years as Linux distros increasingly turn older/legacy hardware into scrap. As I note in the new “warning” on my DSL Hard Drive page, it would be much safer to install DSL via frugal install or even just boot off the CD if possible.

Running monkey httpd on AA1 under crunchbang

August 10, 2009

One of the things I liked about DSL was its inclusion of just about everything you’d ever need whether you wanted to use it as a desktop or a server. I figure from the posts in the forums that desktop use far outpaced server use but it’s quite capable as a server. DSL included everything from SSH and SSL to FTP server to a small HTTP daemon called monkey, which along with any of the other services could be started at boot from a cheatcode.

I think monkey was one of those things that kind of grew on me even though I’d often use thttpd (personal favorite). I’d use it at home for a variety of things including running a local bloxsom blog and hosting family calendars. I’d sometimes use it at work to test things and to set up a temporary server for our group. Despite its tiny size, monkey does CGI and can handle just about whatever you’d want a small HTTP daemon to do without any bloat and with easy configuration. It’s also been rock-solid in my experience, even with moderate traffic. I think you don’t need a full LAMP stack if your needs are fairly simple and you’re not setting up a production server with loads of traffic (and thttpd, which I think is more robust, should suffice if that’s the case).

I needed to look at something and needed to host it on my own network, so I looked to see if monkey is available in the Ubuntu repositories. It is, so I installed it.

The first thing I discovered is that its default conf file (/etc/monkey/monkey.conf) uses port 2001, which is kind of stupid (IMO). I edited it to a more suitable and easily remembered port (8080).

Once it’s set up the way you want, you can start the daemon:
sudo /etc/init.d/monkey start

Actually, you should first check to see if it’s started by default (see below) when you install it. Whether it is or isn’t, it’s safe to issue a stop before starting and/or reconfiguring it if you need to use a different configuration than its default. I think it’s fucked up to set things up to start automatically upon installation or even upon reboot unless/until the user decides to run it. Guess that’s why I still hate Ubuntu and the mindset of the user it attracts (I was going to add a post about this utter shitheadedness affecting the wider Ubuntu community the other day but I’m trying to be more diplomatic — really).

Once it’s started, you can point your browser to localhost:portnumber (e. g., http://localhost:8080) or even to your IP (if not proxied) to reach it from the Internet. Here’s the default monkey page:


You can set up your own index.html and configure it as you see fit, including starting with a conf file in your home directory. Just copy the default in /etc/monkey to wherever you want to set it up (such as ~/.monkey). My own preference is to set things up in my home directory, so I have ~/www set up with a directory tree suited to my needs.


Another thing (not surprising) I discovered about the Ubuntu package is that it’s set up to start at boot. I moved the S monkey file in my default runlevel (e.g., /etc/rc3.d/) to K. I don’t intend to run a full-time httpd so I’d just as soon start it manually as-needed. It’s not that big but it’s the thought that counts. Keep that in mind when using packages from the bloated distros. (Didn’t I write above that I’m trying to be more diplomatic? See? I didn’t repeat how totally fucked up I think it is to start these kinds of services without users taking full control of them first.)

Also, I noticed {Tiny,Micro}Core doesn’t have a package for monkey yet. I’ll probably add that to my compile list shortly.

From Search Engine Referrals: What is Zero Day and Use TinyCore Instead of DSL

August 9, 2009

I’ve written before how sometimes I see things in my stats that interest me for some reason. Sometimes it appears to be a sign of frustration (search engine terms including profanity) or a subject which I either haven’t addressed or haven’t explained in some detail.


This caught my eye this afternoon. A “zero-day” exploit means a vulnerability is already available (and usually being exploited) in the wild without any kind of warning or notice to the developer of a certain piece of software. It’s most unfortunate because such things are discovered reactively. In contrast, many security experts will disclose vulnerabilities to developers and give them adequate time to patch before going public with details. The disclosure of the DNS cache poisoning vulnerability affecting all operating systems last year is an example of the latter — Dan Kaminsky worked behind the scenes with a team of developers from different operating systems to find a solution before announcing to the world what he’d found. So “zero-day” means there’s no head’s up about a problem, and more often than not someone is already actively (ab)using it.

Also, to anyone who’s interested in Damn Small Linux on a netbook like the Aspire One, forget about it. For starters, it’s no longer under active development. Then there’s the whole problem with various drivers for new devices not in Linux 2.4 at all. So you’re looking at big dead ends right there. Finally, given the number of people who demand aesthetically-pleasing interfaces, you’re going to have the tiny X server in DSL compressing 1024×768 into 1024×600; the result is a squished-looking screen. There’s at least one full X server extension in MyDSL.

A better solution if you want a similar concept as DSL but more modular is to use TinyCore (if you can live with the aforementioned squishy screen) or MicroCore with one of the X extensions (if you want graphics). TinyCore is developed by a team with strong DSL ties (at one time it was called DSLCore). Your AA1 or other netbook will be much better supported with TinyCore. It’s not as easy to configure but it’s not too difficult if you read the documentation.

Update 20090713 am – Miscellaneous

July 12, 2009

I didn’t boot back into #! until late last night. I’ll try to edit the jwmrc later. I’ll add screenshots to the previous entry momentarily.

I still get a ton of hits for DSL-related things. I see in the search engine terms for today that I already have someone looking for how to use DSL to install Debian. Don’t! I can’t believe people still think they can do this but it’s not a jumpstart to a small Debian system. Go read my hard drive install page linked up in the top right-hand corner on my blog (click on the banner to to “home” if you’ve landed here and the links in the right column aren’t visible).

In a nutshell, DSL was based on an old version of Knoppix which was based on a now-deprecated version of Debian. Debian no longer offers any support for that version (which was called Woody). You cannot do a dist-upgrade from DSL to Debian-stable without breaking every freaking thing in the system.

You can still use DSL as it is but it appears development has ended. I haven’t seen if John Andrews has posted a roadmap or even announced what he’s doing development-wise.

If you want a small-ish Debian system, the best idea I’ve seen is Kerry’s which he’s posted in various forums including at DSL, IIRC. I searched and found it at the Ubuntu forums again just now. You can use that with any net-install-able distro like Debian, Ubuntu, Fedora, etc. The BSDs require a bit more work but also can be used to create lighter systems. Etc. If your computer can run Slitaz or a POS distro like Puppy, you can run Tiny Core and build a light system, too.

I’m still a bit anxious about how this Atheros card is performing under Linux. I’d hoped the more recent kernel in #! would resolve the matter. I’d suspended and resumed a few times to see if it would flake out on me, but what happened yesterday was the longest time it had been suspended while running #!.

I’m also noticing that my transfer rate is swinging wildly from 1 mb/s to 54 mb/s. I’m going to have to delve through more bug reports and see wtf is happening. I knew the other stuff I’d experienced with older (and apparently not patched as much as I thought) kernels was a known issue. I haven’t looked to see if any other reports have been filed since the big re-write. I compared my signal using my old ThinkPad which uses a Broadcom card and the wireless signal strength, transfer rate, etc., seems more stable with it.

I also need to double check my warranty. I know it’s supposed to be one year but I don’t remember the fine print to see how nitpicky it is. If it’s voided, I may bust this thing up and find another card.

(Edit: Signal strength and rate isn’t an issue in Windows, only in Linux. I likely won’t change the card unless I decide against upgrading to Windows 7.)

Update 20090627

June 27, 2009

I’m still unable to run yet (lingering fatigue from the flu combined with a heat wave) so my early morning hours are filled with catching up with work. Screwing around with Fedora has been an anti-priorirty until this morning (at 4:30 no less).

I think I booted into Linux three times all week (checked last: four times – twice on Monday, once Tuesday, once this morning). Spent most of the week working within Windows playing catch-up. I never installed Firefox under XP on my AA1; I’ve been using IE8 and Opera instead. I finally installed xulrunner and conkeror, though, yesterday. May install conkeror under Fedora, too.

Here’s GNU screen running mplayer (streaming, emacs opened with probably two dozen more buffers than I’m using or paying attention to (mostly dired — need to see if I can reuse  the same buffer), w3m opened to my blog, and some chatting. This is all within ratpoison, of course. I got rid of that lxpanel thing.


I installed GraphicsMagick instead of imagemagick so my file names are automatically set and everything’s handled with simple keystrokes. I saw that GraphicsMagick did the same things as imagemagick only faster and better with fewer libraries. Not sure how true the claims are but I decided it was worth a try. Only difference I had to adjust to was invoking “gm” before imagemagick command names in my scripts and configuration files (e. g., the aliases and commands I have set up in .ratpoisonrc).

Likely to remove some Gnome bloat sooner than later, but still have some apprehension. I wanted to see where pekwm would fit in comparison to ratpoison and fluxbox. It was much closer to fluxbox so I’ll remove it.

window manager resource use
doesn't include additional/related processes
taken at fresh start
ps aux | grep [window manager name]

lucky13      0.1  0.4  10264  4172 ?        S    04:43   0:00 pekwm
lucky13      1.6  0.4  10808  5068 ?        S    04:46   0:00 fluxbox
lucky13      0.2  0.1   5476  1556 ?        S    04:47   0:00 ratpoison

pekwm with default theme
fluxbox theme "green tea" and very small menu
ratpoison with custom .ratpoisonrc

Not doing anything drastic today beyond tweaking .emacs and moving old scripts to the AA1. I’ve considered upgrading the AA1 to Windows 7 when it’s released (October 22). I’d like to see that everything’s working better under Linux than it has thus far, which is why I still have XP installed and why I’m still leaning towards Windows 7. Right now there are too many things keeping me from considering running Linux-only on this: having to boot with an SD card inserted to use the reader, crazy wireless shit that’s happened on multiple occasions now (changing SSIDs and even disabling the wireless card), etc.

One final note about the DSL hard drive PDF I’ve not been able to finish yet. I don’t know if or when I’ll get around to it between catching up from being sick to vacation to the simple fact that DSL is dead and I think there are too many better options for those who want a traditional hard drive install. I thought interest would wane since DSL’s development has come to a screeching halt (last time I checked, John Andrews had posted no updates, roadmaps, polls for what direction users wanted DSL to go, etc.), but every day I’m getting hits from DSL forum links and from Google searches related to DSL hard drive installs. So maybe I’ll finish it anyway. Even though it’s about half finished (I want to add new screenshots and other images to make it as easy as possible) I’d rather spend that time writing a guide for something under active development. Maybe I’ll post my own poll about all that and see if there’s any interest either way.

Update: First Look Fedora 11 Live CD/USB, Misc Thoughts, cheese Sucks

June 10, 2009

Just a quick update before I get on a conference call. I’ve now booted both the Gnome and KDE versions of Fedora 11 Live from USB thanks to this unetbootin recommendation from scottro. That (old) thread at FedoraForum includes other helpful suggestions netbook users can try if they get bogged down with Fedora images. (Edit: I used unetbootin to successfully get a bootable USB stick with Fedora 11 from within Fedora 10; haven’t tried in Windows.)

Impressions? Well, the KDE version seems more stable than I recall from the prerelease image I ran a couple months back. I didn’t do much with it except look to see which apps it comes with — KOffice and other K-apps instead of OpenOffice. I then booted the Gnome version and it’s not too different from the Fedora 10 selections: AbiWord, evolution, cheese, totem, rhtythmbox, etc. That’s good because I don’t like radical changes. There’s still no hotplug support for the SD card reader (the one on the left side of the AA1 — haven’t tested the multi-card reader yet) unless you boot with a card inserted; I did see that the jmb* module loaded when I later inserted a card after (cardless) boot, it just doesn’t work yet. Beyond that, things seem to be working fairly well.

I was more inclined last night to run a KDE-based system over Gnome, but both are a bit more cumbersome and bloated than I really desire. It’s not so bad with a GB of RAM but I think people delude themselves that Linux is inherently better than Windows on low resource hardware — I think XP’s performance is still a lot better on this AA1 than Linux 2.6, especially with the chronic polling and shit that Gnome does (and KDE, too). That’s why I may go ahead and do a minimal install of something whether it’s Fedora or Debian or Slackware and then install more or less only what I want.

That last point, as it relates to default selections of software, reminds me of how many things I switched around in Fedora 10 on my AA1. I installed to replace AbiWord (because I use it at work and I needed Calc and Base as well), mplayer from rpmfusion in place of totem and cheese (see below), mksh (left bash installed in case any important scripts are full of bash-isms or call directly to /bin/bash), emelfm2 in place of whatever retarded file browser was the default, and a variety of small-ish apps I like to use. And bigger apps like Skype, which works very well now that the microphone is working.

This “cheese” webcam studio or booth thing fucking sucks. I read the FAQ and whatever else I could find to try and get it to record video without stuttering — or even minimal stuttering — but it was still so fucked up even with the smallest possible resolution I could set that I abandoned all hope for it. It basically freezes for a few seconds at the start of a capture and never really gets its shit completely together after that. Looks like the developers were more interested in useless shit like the nifty count down timer and “flash” thing that goes off (not to mention all the “effects”) than getting legitimate core features — like smooth video with properly synced audio — to work correctly. In a way, it’s typical of GNU/Gnome projects where people “major in minors” and the more important things never get finished or it’s a half-assed unfinished project that never fulfills its stated objective (see guile, which was supposed to take on TCL/TK but has languished in near obscurity behind other newer and more relevant languages).

Fortunately, there are things that work a lot better even at the higher resolutions the cam is capable of using. Here’s my alias for recording from the webcam using mplayer/mencoder.

alias record_stream='mencoder tv:// -tv \
driver=v4l2:width=320:height=240:device=/dev/video0:forceaudio:adevice=/dev/dsp \
-ovc lavc -oac twolame -lameopts cbr:br=64:mode=3 -o '

Change the encoders to suit what you have on your system. Type/tab complete the alias in a terminal and add a filename with format type (e. g., record_stream ~/Videos/today01.ogv) after record_stream and use ctrl-c to stop recording. Is it as fancy as something with buttons and can you see yourself? Nope (though it’s possible to run mencoder/mplayer so you can see what you’re recording). The captured video (and synced audio) is of much better quality than I was ever able to get from cheese.

(If you must see yourself before recording you can add an alias like “stream_test=’mplayer -tv driver=v4l2:fps=15 -vo xv tv://'” — you can also add whatever you need to listen to yourself if you need to test the sound, too, but that’s a system setting that you should set to work without constantly screwing around with it.)

I realize people drawn to Puppy and Ubuntu will throw up their hands and yell “WTF” at that, but script it through zenity or something if you think you need a fucking button to click just to do a simple task like capture video from your webcam. It’s easier my way. Really. And you can use whatever codecs you have installed — mpg, mp4, avi, mov, wmv, ogg, whatever.

Anyway, still not committing to Fedora 11 yet because there’s nothing in it that I don’t have working in 10 — just newer version numbers of the same stuff. The only reason I may install it sooner than later is because I want to reclaim space used in various other Linux partitions for one unified install, which kind of mitigates against installing from the live CD anyway because of the quirky requirement that / be ext4 and /boot be ext3, etc. Now that I’ve slept on it, I’m more convinced I want something a bit more conservative with a longer support cycle than Fedora offers. May have more time later to do something.

Still on my to-do list and coming soon: Updated DSL hard drive guide in PDF, even though DSL is pretty much dead. Could have it posted by the end of this weekend.