Archive for the ‘Tiny Core’ Category

Update 20101006: Hardware and Software Changes

October 6, 2010

The past couple months or so have been much more hectic than anticipated due to family health issues. I’ve also experienced a bit of hardware and software trouble and that’s led to some experimentation.

My primary laptop began experiencing issues where my wireless (Broadcom 43xx) would drop off without warning. The first time it happened, I thought the problem was with my router because I was able to scan SSIDs by the time I was aware there was a problem. When the problem next occurred, I checked dmesg and had all kinds of messages which indicated the wifi card was crapping out. The fact that it also happened in a hospital connected through their wifi also indicated the problem wasn’t with my router at home.

Fortunately, I had a backup card from a destroyed laptop I’d found a couple years ago (somoene apparently left a laptop on top of a car or tossed it out of a car; the only parts that were salvageable were the spare memory stick and wireless card). I installed the card and set it up when I rebooted Debian Lenny. Things worked okay for a while but I ran into some glitches with network manager (not sure why) and I was considering various options like reinstalling Debian or trying other distros.

I was going to install Scientific Linux but opted instead for CentOS. There really shouldn’t be much difference since both are RHEL clones and aim for 100% upstream binary compatibility. I’ve been running CentOS 5.5 (standard Gnome desktop) on this laptop for a little over a month now. Nutshell: love it.

The only real issue I’ve had with the “mature” software is getting a newer HP inkjet all-in-one to work — just not possible without updating over what’s available via the repositories. I’ve already done that for my netbook, so I just need to install on my laptop when/if I need to use that printer (I have a couple other printers networked so it hasn’t been a hassle).

Gnome really isn’t my thing even though I’ve come to accept using it. I wish it didn’t require so many resources to do relatively simple things. I’m finally paring some things down.

I installed icewm yesterday. I “borrowed” the Scientific Linux icewm theme — much nicer and cleaner than most I’ve encountered — and switched icons for the menu button (I also did a CentOS one but this is the one I had enabled when I took the screenshot) in that theme. I need to find something lighter than nautilus to manage the desktop. Or just install ratpoison and emacs and be done with it.

With 5.5 (SL and CentOS) comes OpenOffice.org 3.x, which I’m using somewhat reluctantly. I intend to write more about this whole area of software but I just can’t find time. I also want to write an article about shortcomings of OOo and show where and how it’s not a 1:1 replacement for Microsoft Office.

I continue using SL55 on my netbook. I may eventually replace that with CentOS but right now there’s no hurry to change anything. I’m still running Debian (Lenny) on my main home server; I also have CentOS installed on another one but it’s been unplugged since my last trip to care for parents. I have my old ThinkPad set up as a MicroCore media streamer connected to my stereo.

I’m also considering trying other distros on my primary laptop, including TinyCore, again if I can find time. The only time I run TinyCore anymore is from USB and rarely for more than a couple hours. Unfortunately, someone gets sick or needs surgery or dies every time I think I’m going to get finally time to set up something “just right.” Maybe I’ll bite the bullet and take care of it during the next hospital stay (planned later this month) to help kill time and avoid some of the anxiety.

Speaking of which, it could be a while before I get around to more substantive content on here again. It’s not a lack of desire or ideas, it’s just a lack of time.

TinyCore 3.0 Alpha on an Ancient ThinkPad

May 15, 2010

I deleted an earlier post related to my first look at TinyCore 3.0 alpha because I hadn’t had much time to do more than boot it. I still regret I haven’t had much time to set it up and do more with it, but I did more this afternoon than I had in the week or so previously. And I did it on my oldest remaining computer.

I decided to see how well TinyCore 3.0, which is still currently in public alpha testing, would do on my ancient ThinkPad. The worst issue I had was setting it up to boot. I wanted to put TinyCore onto a partition via USB, as that would be better than burning a CD and faster than setting up my network so I could PXE boot it (which I would consider if I had more reason to do so). I presently have SL54 installed on it, so I put tinycore.gz and the TinyCore bzImage in /boot and edited the GRUB menu.lst to boot TinyCore. TinyCore works well like this and can live inside another distro (I’d call it the “parasitic” method for using TC/MC but there has to be a better, more positive way to put it).

TinyCore boots up with a shiny new logo on a medium gray background.

I think it looks nice on other colors, too, but they need to be lighter hues. Like white:

Or even yellowish orange (#ffa500):

I’ll fix the logo soon so it can be used on any background.

I also had to set up X to accomodate the 800×600 resolution because I didn’t set a cheatcode at boot (doh!). I set the desktop color on red for the hell of it.

As this ThinkPad lacks a wired ethernet port and I have no wired ethernet near anywhere I’d use it, I had to manually download the appropriate extensions — in my case, b43-fwcutter.tcz, openssl-0.9.8.tcz, wireless_tools.tcz, wireless-2.6.33.3-tinycore.tcz, and wpa_supplicant.tcz (I also downloaded the zd1211 firmware extension just in case the Broadcom 43xx-based PCMCIA card gave me any crap and I needed to resort to my USB adapter) — to get connected. I then found the proprietary firmware required for the card and copied it to /lib/firmware. I had a copy of my wpa_supplicant.conf already on the USB stick which had my extensions, so I copied it over and set up wpa_supplicant and started udhcpc. I was connected.

I then installed a few quick extensions to test audio. I made my quick wrapper to use mocp for pls streams from shoutcast.com and soon had streaming audio.

As you can see, this is a really old laptop — 500mhz and not very much RAM. It was great under Damn Small Linux back in the day. It still works so it gets re-purposed from time to time. I think I’m most likely going to set it up in my stereo cabinet and use it to stream audio through the stereo and to keep the thing out of earshot because its hard drive is clunky and the fan is really loud. Fortunately, it doesn’t run hot (unless compiling) so I’m not worried about it overheating in there.

I also installed sshfs so I could mount my server locally on the old laptop. I used elinks to open a file locally rather than through the http server (I was basically using elinks as a file browser).

RAM use was pretty high because I installed Opera, elinks, audio drivers, mocp, etc. I don’t think I’d do that again. Especially Opera.

In fact, X is overkill on this. If I set this up as a streaming audio client for the stereo, I’ll likely use MicroCore instead. That’s an article for another day…

Scientific Linux 5.4 (Live/USB) on my Aspire One

April 17, 2010

I ran Scientific Linux for a little while on my new-old laptop and still have it installed on a spare hard drive in my new desktop (though I’ve been running Debian on that for about a month). Really didn’t have much trouble with it — it’s just what one should expect by something that’s oriented for enterprise use: stable, solid, not flashy, not bleeding edge, no drama.

For those who don’t know about Scientific Linux, it’s compiled from RHEL sources so it’s in the same category as CentOS. The biggest difference between CentOS and SL is the former is a community-run project while SL is based at FermiLab. SL has a more scientific orientation than CentOS, with a focus on packages for use in research and writing and less on games and entertainment (though there are concessions to games and entertainment). If the SL repositories are inadequate for your needs, there are optional third-party repositories of RHEL binary-compatible RPMs which should work across the spectrum of RHEL-compatible distros.

I was playing around with distros while watching the NBA playoffs tonight, since the first two games today were routs. I first decided to look at SL54 live CD on my Aspire One. I first tried the Lite image but it lacked wpa_supplicant, so I grabbed the full Gnome image and put it on USB via unetbootin. For what it’s worth, the Lite image uses icewm (which is also on the Gnome live CD) and comes with Firefox, emacs, vim, xfe, and probably other stuff I didn’t bother looking at very closely. Sorry, but there’s only so much I can do without networking. I did log out of icewm to run emacs in console and I can vouch for its stability.

Once I set up a USB stick with the Gnome image, I booted up. It’s straightforward and comforting because I like to see hardware detection instead of some sexy graphics. I encountered one little problem logging in: Scientific Linux live CD has a pre-login option to set keyboard and passwords (passwords are optional). With the small display of my Aspire One and the large text in the dialog, I was unable to see the area where the prompts were. Fortunately, I’ve used this fine little live CD before so I knew US-English keyboard is 1 and I didn’t bother to choose to set a password since I was just seeing how well it would do on the Aspire One. After hitting return, I went to the gdm login and entered “sluser” and I was quickly in  Gnome.

After a quick look at dmesg and lsmod, I quickly set up my wireless. Voila.

It’s been a while since I spent this much time using Linux on the Aspire One. Other than occasionally logging in to my TinyCore/MicroCore install on this thing, I’ve given up running Linux on it. Search my ath5k entries and you’ll see why. I never did sort out whether it was related to the ath5k driver, something in the 80211 MAC stack, or wpa_supplicant — it could be one, it could be a combination, but I know for sure that it isn’t the card (it works flawlessly in Windows no matter how long I’m on it). It’s quite possible if the problem is with wpa_supplicant that “backing down” to an enterprise-oriented distro like Scientific or CentOS might let me run Linux on this thing since wpa_supplicant most likely is a more stable (okay, older) version with certain patches to fix bugs. The problem with testing that tonight is I was on battery and thus not up long enough to see. (I just plugged in again to reboot and post this.)

The only issue I remember under SL54 on my desktop was having to manually update hplip for my printer. The same would apply to CentOS and other RHEL-compatible distros (what does that leave, Oracle?). That’s a minor consideration compared to the issues I had with repeated wifi timeouts under the following distros (not the fault of the distros, just a summary of ones I ran on the AA1):

  • PCLOS (KDE, Xfce/Phoenix, etc.)
  • Fedora (10, 11, 12)
  • Debian (Lenny and Sid)
  • CrunchBang
  • TinyCore/MicroCore

I think that’s it. There were others I ran off USB but never would install because they weren’t ready for prime time. And when I run off USB (as I did tonight), it’s rarely for hours or days on end. It was more like 45 minutes while I shelled in to my desktop and moved files around (including the above screenshots). Like I wrote above, not enough time for the ath5k to race and panic and then no longer be detected.

I didn’t do a full checklist of hardware compatibility but I don’t think this thing would have any unresolved issues (except maybe the stupid card readers). I was a little surprised after the login thing with the keyboard and password prompts that gdm and X ran perfectly and detected the correct resolution. I didn’t look at the webcam. I presume audio works (the error beep sure did) but didn’t bother with that since I already knew I’d have to download codecs to listen to anything other than ogg files (I was watching the games, not interested in streaming or playing anything). As you can see from the wifi icon, my ath5k card was properly detected and nm-applet did a cursory scan to find available networks; I set it up quickly and was networked with WPA.

I’m still determined to run Linux on this thing even though it’s supposedly been for sale for the past couple months. I’ll probably give this USB stick with SL54 a longer look on the AA1 in the coming days to see if I can get the ath5k to time out again. For now, though, I have to get some sleep.

UPDATE: I’ve posted an update/addendum to this post.

Micro Core and GNU screen Fix

April 1, 2010

I finally got around to trying my own GNU screen extension in Micro Core. Same result (fail) as the one in the repository. This is because of the way the permissions are set for /dev/tty1. This is something which the development team could address so that ttys are spawned with appropriate permissions in both Tiny Core (which worked for me) as well as Micro Core (which didn’t).

Suggestions were made in the TCL forums that users could exit the shell and then sign back in. This requires that a password first be set for the $USER (whether tc or whatever the user sets via the user cheatcode) and that a user have access to the box to log out and log back in, or even to use the noautologin cheatcode (which would require that to be set in menu.lst as a default if the user doesn’t have direct access and needs a reboot). Since it’s headless and I don’t have direct access so I’m accessing via ssh, I wanted to get this working so that I wouldn’t have to do any of that.

Here’s my own work-around, pending any changes to inittab and /dev/tty* permissions by the development team. Should work with the extension from the repository just as it did for mine (I didn’t see how the repo version was compiled but I presume it was with screen’s defaults).

After making sure /dev/tty1 was owned by a group $USER (either tc or whatever user= is set to) is in (staff for TCL/MCL, even though I’d prefer a separate group, such as tty, for this — what’s the point in being a “multi-user” system if everything is set up for group staff), I chmod’ed /dev/tty1 to g+rw and I was then able to use /dev/tty1 for screen’s /dev/pts/* (which are owned by $USER.staff while screen is running). This can be done on  the fly or set via /opt/bootlocal.sh so it happens during each subsequent boot. Now screen works and it didn’t require logging out and back in, etc., or making changes to the way {Tiny,Micro}Core boots. Should work similarly if ownership is set to $USER (tc or user= cheatcode, adjust the following accordingly) and then mode set u+rw.

Just add to /opt/bootlocal.sh:

chown root.staff /dev/tty1
chmod g+rw /dev/tty1

or

chown tc.staff /dev/tty1
chmod u+rw /dev/tty1

Note: I’m not too gung ho about having to take additional steps to use an app like this. I also won’t vouch there aren’t any potential security issues arising from my suggestions, especially since Tiny/Micro Core have wide-open sudo privileges and (as I mentioned above) nearly everything is set up so group staff owns so much. If your work/use requires some degree or assurance of security, you might want to consider another distro which has more security features  — including logging (which Tiny and Micro Core don’t have) and more available default groups and less cowboy use of sudo privileges — set up and working by default.

UPDATE: Thanks to maro for yet another way to get around the issue by editing /root/.profile so that /dev/tty1 is chown’ed by $TCUSER.staff. Perhaps the development team will address this so there won’t be any need for remastering or making changes via bootlocal.sh or filetool in the future.

TinyCore/MicroCore tty and GNU screen Fun

March 27, 2010

I mentioned in the second of my desktop posts week before last that I ran into a problem using GNU screen in MicroCore; screen just wouldn’t run on the tty as user tc. I finally had time to report the issue and got a bit of quick feedback with possible workarounds.

I have another one. I just compiled my own version in TinyCore on my AA1 and didn’t have any issues – at least not the way I configured it.

 

I know from packaging screen before (for DSL) that it has a variety of configuration options. One of my preferences is –disable-socket-dir so that screen uses a user (~/.screen) socket directory rather than a system one; the reason I prefer that is because I think processes run by users should be confined to their own directories as much as possible. I don’t know if that would fully resolve the way screen works in relation to how ttys are set up in Tiny/MicroCore since my set up on the AA1 is not standard TinyCore practice: I run with a user= cheatcode, I use a prefix of $HOME/local (which is in my mkshrc PATH), etc. Also, I haven’t completely compared /dev/tty* across versions to see if there are other permission issues/variations involved.

I did note that inittab respawns tty under the user= name (not root) at least in TC 2.2, which was the version I booted from hard drive. I’ll check later after the NCAA tournament using -current from USB, or more likely wait until tomorrow.

Crunchbang Moves to Debian-Squeeze

March 24, 2010

I found this interview of Crunchbang Linux developer Philip Newborough in which he details reasons for building #! on Debian-Squeeze (testing). The first reason he gives is the difference between Debian’s democratic process and Ubuntu’s commercial sponsorship by Canonical, which he likens more to being a “governing party” more interested in “producing a polished end-user system” that often makes the work of derivative projects more difficult. He thinks “that some of [Canonical's/Ubuntu's] recent decisions might not necessarily have been made with the best interest of their users/community at heart.” He also lists other reasons including the ease of the build process under Debian.

I had my own reasons for ditching #! last year, primary among them was an issue related to wireless performance that has less to do with distribution base than (IMO based on reviewing many threads relating to certain hardware combinations) getting the kernel’s wifi driver to work correctly with WPA encryption. I reconsidered using it on my new laptop, but instead chose Debian-Lenny (stable) as it was adequate for my hardware and spared me all the hassles of bleeding edge versions that tend to be found in Ubuntu. I’m quite happy with older software that gets patched for legitimate reasons like security, bugfixes, and real features.

For the moment, I’m running Debian-Lenny on both my laptop and desktop. The desktop is basically being used as a server, without X installed (yet). The only other Linux install I have right now is a small 5GB partition on my Aspire One which is being used for TinyCore and MicroCore. I finally rebooted that the other day and used my USB wifi adapter instead of ath5k.

The main reason I’d probably not care to use #! on my computers full time is because it’s using the testing branch rather than stable. I couldn’t care less if it’s set up on a “corporate” base as it was under Canonical/Ubuntu or a more “democratic” base under Debian. What matters more to me is stability. I hate drama. Debian wins that battle over Ubuntu hands-down, in my opinion. The other potential deal breakers for me are the Openbox/Xfce options. I’d like to see something even more basic than those. I may check it out when it’s at a “stable” release, but probably only via USB stick.

I have my own ideas for what would make it lighter, faster, and less obtrusive to the end user. But that’s a subject for another time when I have… well, time.

Setting Up Desktop – Part 2

March 15, 2010

Had time to kill during a conference call Did some more work on the desktop this afternoon. Decided to scrap Gentoo install after rebooting and realizing I just want it to work ASAP without any fuss.

I decided to set up Micro Core. As I suspected, some of the extensions were problematic. First up was GNU screen since microcore boots with one tty and I need some multiplexin’ action. Unfortunately, screen insisted that it couldn’t even run on my lone tty , at least not as user tc. I could run screen as root but what’s the fun in that? I need to be user tc to use the packaging system. I added ssh and monkey (http daemon). Then I started screwing around with my persistent files and decided this wasn’t what I wanted. I’m not dissing it, but I’m also not using it. It won’t be nomadic, though I will be.

I grabbed my Debian net install mini CD and booted it. In very short order I had it installed with encrypted LVM and swap, no headaches and no convoluted hoops to jump through, with standard file layouts. I quickly added sudo, added myself to sudoers (who the fuck decided on fucking POS nano as $EDITOR?), set up group sudo to require password (one of the uneasy things I decided I wouldn’t compromise with under Micro Core), openssh-server, and am now adding various and sundry packages I need installed.

I got more done in about 30 minutes with aptitude than it took to compile the Gentoo kernel (counting a very hasty run through menuconfig). Yeah, it’s going to have a bit more bloat and it’s not as optimized. I’ll deal with all that when I have time to spend on it.

Maybe another update soon, but I think you can see from the above description that there’s nothing fancy. Hell, I didn’t even install X. Pound for pound, I’m about where I expected to be with Micro Core at this stage — with bash, with openssh, with core utils, with a variety of extensions I wanted to set up in a hurry. I still have tinkering to do, particularly with config files (which I’d have to do anyway no matter which distro I’d settled on) but it’s been a lot faster to get set up and relatively free of hassle and zero — really, zero — drama.

Now if I can find some time to finish this before I head off again…

Setting Up Desktop – Part 1

March 15, 2010

I won’t be using my desktop as a desktop very often but I need to get it up and running. After wavering between what to do with it, I started installing something today at lunch. I hope to have it finished by this weekend. Or sooner. I left in the IDE drives because the big honking SATA drive is being used for NAS until I find a big-enough replacement for that (original crapped out).

Yeah, I know. Geez. I didn’t want to do any work at all. I was going to do a minimal Debian net install and only set up what I want. Then I thought I shouldn’t waste anymore time since I installed NetBSD (and Scientific Linux on the secondary drive). Then I was going to just set up MicroCore with only the things I need it to have, and then do more later when I have time. I think, though, that I want a bit more flexibility than Debian and I want to avoid some of the hacky-ness of {Tiny,Micro}Core and have a full set of utilities instead of busybox. As much as I love the latter, it’s just a bit Rube Goldberg in setting up the way I want it to work (not to mention I’d have to compile quite a few things that I want/need which aren’t in the repository); the remaining Linux partition on my AA1 is TinyCore — which I could only use with a USB wifi adapter anymore since I have zero confidence in the Linux ath5k driver with wpa_supplicant — and by the time I add GNU core utils, compile libarchive, etc., I’m pretty close to a Debian/Slackware minimal install anyway. Aside from portage’s bloat, I think I can keep this pretty lean (which is more a goal than a necessity). If I end up regretting Gentoo, I’ll likely install MicroCore and then screw with it more when (if) I can find more time. If it goes as smoothly as it has so far, I could end up putting it on my laptop, too (I’ve aborted several entries I started about excessive dependencies…).

My kernel is still compiling now. I won’t have much chance to mess with it until later tonight (after 24 at the earliest) and probably won’t touch it again until Wednesday. Hopefully I’ll have a “Part 2″ up in a timely manner. Haha.

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

February 9, 2010

AA1
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.

20091119 Update – AA1, New-Old Laptop, New Desktop, Etc.

November 19, 2009

Slowly getting back into the rhythm of my own life again and finding more time to set up computers. I’m selling my AA1 as I noted in the previous update.

I’m not running Slackware on the new laptop right now. I downloaded PCLOS Zen Mini to see what a stripped down Gnome desktop system would be like. I ended up installing it on the new-old laptop and have added only packages I want/need. Despite my dislike for bloated packaging typically found in binary distros, this is much preferable to installing something that comes with software packages I don’t care for and end up replacing with the ones I want. I don’t know how much longer I’ll run this before changing again. I’m surprisingly pleased with it so far — even with the sizable updates I ran upon installing it — but I think I’m probably going to ditch anything running Gnome or KDE. I saw that Texstar has Xfce and e17 (coming soon?) versions available as well, in addition to LXDE (which just isn’t my cuppa).

I’m currently burning the Fedora 12 Xfce live ISO. I doubt I’ll install it but who knows.

I’ve also been running TinyCore on this laptop via USB. I may end up setting it up on the hard drive at some point.

I’ve also acquired a new desktop to replace my old one. The old one, which had the funkiest parts and configuration I think I’ve ever encountered in an OEM computer, bit the dust and I don’t feel like finding a new power supply for it; it’s not a standard power supply and the model is no longer supported by the manufacturer. I don’t have an OS installed on it yet and probably won’t get to it until this weekend at the earliest (more likely Thanksgiving weekend since my holiday shopping is done). I haven’t made any choices about distros for it yet but maybe I’ll have some time to look around a bit more before I slap in my USB stick and copy TinyCore to that hard drive.


Follow

Get every new post delivered to your Inbox.