Archive for the ‘debian’ Category

More ratmenu tips

May 18, 2010

I see I’ve been getting a lot of hits in the past few days for searches related to ratmen, ratmenu, and 9menu. As I’ve written before, these work very similarly. In a nutshell, you use these to create shell scripts to provide menus for ratpoison or other window managers.

What can you do with these menus? Whatever you want. You can use standard application-centric menus to open whatever application. You can customize them so you open specific files in certain applications. You can start or stop processes (mind your permissions; gksu/gksudo are beneficial if you’re going to start/stop/restart daemons like sshd, cupsd, httpd, etc.). These can then be launched via keybindings set up in .ratpoisonrc or whatever configuration file your chosen window manager uses (a few years ago, I used ratmen with oroborus since oroborus lacks a menu; I set keybindings for ratmen in my .oroborusrc).

This example is more ratpoison-specific because some of the commands in this particular menu (~/bin/menu_sys.sh) pipe out to the ratpoison status message area. I wanted a menu with system commands and to get information quickly even if I’m not sitting in front of an open terminal, so, for instance, I can see what’s happening or running while working in OpenOffice.org or gimp or a browser. If you’re using ratmen(u)/9menu in other window managers, you could send to xmessage or zenity or whatever you want.

#!/bin/sh

ratmenu -fg "#ffa500" -bg "#444444" -align center -style dreary \
"netstat" "ratpoison -c 'echo $(netstat -a | head -n 18)'" \
"top" "ratpoison -c 'echo $(top -b -n 1 | head -n 24)'" \
"w" "ratpoison -c 'echo $(w)'" \
"free" "ratpoison -c 'echo $(free -mt)'" \
"mount" "ratpoison -c 'echo $(mount)'" \
"ssh?" "ratpoison -c 'echo $(ps aux | grep -i ssh)'" \
"screen -list" "ratpoison -c 'echo $(screen -list)'" \
"screen(s) ps?" "ratpoison -c 'echo $(ps aux | grep -i screen)'" \
"mount sda1" "pmount /dev/sda1" \
"umount sda1" "pumount /dev/sda1" \
"who" "ratpoison -c 'echo $(who)'" \
"last -20" "ratpoison -c 'echo $(last -20)'" \
"temperature" "ratpoison -c 'echo $(cat /proc/acpi/thermal_zone/THM/temperature)'" \
"battery" "ratpoison -c 'echo $(cat /proc/acpi/battery/BAT0/state)'" \
"cpu info" "ratpoison -c 'echo $(cat /proc/cpuinfo)'" \
"uname" "ratpoison -c 'echo $(uname -a)'"

The first line, of course, is the shebang. The next line runs ratmenu (or ratmen or 9menu), and I have this menu set up with a light orange on dark grey background with the “dreary” menu style allowed in ratmenu (the difference between dreary and snazzy is how the menu selection works; in snazzy, the menu choices scroll up or down to a fixed reversed selection, while in dreary the choices are fixed or static and the reversed selection choice scrolls up or down as you navigate it with the up/down arrows). Then come your menu options. As this is a shell script, it can be written in one line or in multiple lines as above. If it’s in multiple lines, separate them with backslashes so the script is read by the shell as one line (no backslash on the last line).

I also use a separate menu for work documents so they can be opened in either emacs or OOo or gimp as needed. My previous ratpoison entry (ratpoison, xnest, jwm, GIMP) noted that I chose to start using GIMP under another window manager using xnest. I sometimes use GIMP to clean up charts and such for work. In order to keep all the work stuff together and to not have to toggle between the xnest window and everything else, I have separate options in my work menu to open things in the X display with my alternate window manager (currently oroborus). In other words, that menu allows me to stay within oroborus (or jwm or twm or whatever) so I can see, for example, how charts look in documents, while ratpoison continues managing everything else. I still have entries that open things in more standard fashion so that it’s all under ratpoison rather contained in another xnest’ed window manager.

Finally, if you’re using Debian and want to override the recommended 9menu when you install ratpoison and use ratmenu instead, use aptitude (as root or via sudo):

aptitude install -R ratpoison ratmenu

For what it’s worth, I have “sudo aptitude install -R” aliased in my .bashrc (alias debinstall=”sudo aptitude install -R”) so I don’t end up installing more than I absolutely have to.

Finally, understanding how to use a powerful text editor like emacs or vim comes in very handy when editing menus like these, especially if you’re setting up to open specific files with identical or similar commands. I’ll usually go through a process of getting a file list from a directory and then recording a macro to insert text down each line to set up the menu. It’s easier and much faster to either pipe a list of files or insert them within the editor (in emacs: C-u M-! ls /path/to/dir — or, my preference, C-u M-! find ~/ -name “*.m3u”to get full paths) and then do the most repetitive things, such as add commands and shell punctuation, via macro.

It took me less than a minute to do a 100+ line ratmenu for my playlists since every command option is the same (“mocp -cap /path/to/file.m3u” \).

The important thing is to set things up so it’s easy to use and uses the least amount of work.

ratpoison, xnest, jwm, GIMP

May 5, 2010

First of all, I know ratpoison has temporary window manager (tmpwm) and new manager (newwm) options. As the ratpoison manual says, “These commands should be used sparingly. They were created to allow users to understand how a poorly designed program is intended to function so they can build a replacement or patch an existing alternative’s missing functionality.”

In the meantime, we users are usually stuck using the applications as they’re (crummily) designed.

I don’t want to leave ratpoison just to use certain “poorly designed programs” (GIMP, etc.) so I was looking for ways to open said applications (which usually open with multiple windows) and allow those apps to function “normally” as if they were no longer under the control of a tiling manager like ratpoison. Switching window managers via newwm/tmpwm means everything then gets controlled by the other window manager rather than ratpoison. Why should everything have to suffer as a result of running a couple offending applications? That’s dumb.

After a bit of experimentation and searching, I settled on using xnest. I already had jwm installed on my laptop so I did a few things to get it all working properly. This will work with any preferred window manager. You could use twm (which gets installed in a standard Debian install) or fluxbox or whatever you want.

The first thing to do is install xnest (in Debian: aptitude install -R xnest) if it’s not already installed.

I decided to configure this to run from a shell script using a separate .xinitrc file (.xinitrc-tmpwm to be exact). That file is pretty simple and since it’s only being used to launch GIMP for now it’s very short and to the point (don’t forget ampersands if you use more than one line):

xsetroot -solid grey13 &
gimp &
jwm

This is launched from another file (~/bin/nest-jwm-in-rp.sh):

#!/bin/sh
exec xinit ~/.xinitrc-tmpwm -- /usr/X11R6/bin/Xnest :1 -ac -geometry 1280x800

This will then start gimp atop jwm in xnest at the full display resolution of my laptop screen. It also means I can start and run whatever applications in jwm I might want. I’m still managing everything via ratpoison and my ratpoison keybindings override any set for jwm. Here you can see the ratpoison window list invoked while opened to my browser:

I can switch to the xnest window and there’s GIMP in jwm (with getting another ratpoison window list):

And like I wrote above, all my ratpoison commands work and supersede jwm. Here’s the result of using ratmenu to send a message about mocp (mocp -i/mocp –info) to ratpoison’s status bar:

And finally, if you want to use another window manager it’s as easy as changing the last line in the .xinitrc. Use twm, fluxbox, flwm, fvwm, whatever.

That’s just GIMP in twm with mocp –info, all managed by ratpoison. Lovely. You probably won’t see this kind of stuff on distrowatch anytime soon, players.

I know ratpoison isn’t for everyone. Some applications can really drive users nuts because the developers make presumptions that don’t work properly for how users want to use the software (the next release of GIMP is supposed to have a one-window option which will make it a lot easier for real people to use). Whether you choose to use ratpoison options like tmpwm or newwm, or an external option like xnest, there are ways to get around crazy multi-windowed applications. I like this approach because it allows me to “contain” those applications in one window under ratpoison where they can float around as intended while managed by a separate window manager. It’s not perfect, but it works pretty well.

UPDATE: For what it’s worth, I’ve now removed jwm and will just use twm for GIMP, Skype, and/or anything else requiring more than one window to function.

ratpoison, ratmen, mocp fun

April 24, 2010

I’ve posted before about why I like combinations like mocp, ratpoison, and ratmen(u). So why am I posting about this when I’ve covered similar things before? Because I’m getting occasional hits for “ratpoison audio level” and such things.

An important thing to remember about ratpoison is that it adheres to the Unix paradigm of doing one task very well and simply. As such, it doesn’t come with lots of add-ons and BS — it just manages windows with plenty flexibility. There are applications and utilities that lend themselves very well to ratpoison to manage other tasks like menus and playing audio which have nothing whatsoever to do with managing windows. Both ratmen(u) and mocp are examples, respectively.

Your distro or your flavor of BSD already contains utilities you can use to manipulate things like audio levels or other adjustments (I prefer ossmix or amixer to the mocp audio controls below but I want to show what I consider an easier way since those hitting this blog looking for search terms like those above most likely will be overwhelmed by more complex/granular utilities which vary depending how distros are assembled). Such command-line resources lend themselves well to scripting. And 9menu, ratmenu, and ratmen are scripting tools which work very well with window managers — like ratpoison — which allow users to set keybindings. This isn’t specific to ratpoison and could be made to work in just about any window manager (I’ve posted before about using ratmenu in oroborus and jwm; I’ve also written here about using command-line tools from within window manager menus).

I love ratpoison because it pretty much stays out of my way and gives me a full view of what I’m doing. I also love ratmen(u) — 9menu, which is “recommended” when using Debian apt-get/aptitude, works similarly so I suppose I should include it here — because it can be used however a user sees fit. Want to just have a choice of applications like most default window manager menus? Just do that. Want something that opens specific files in a certain manner in a particular application? You can do that. Mix and match. It gives you the full flexibility to do whatever you want.

That lends itself very well to console and command-line applications (not the same: console applications typically are built on libraries like curses to provide a more complex user interface while command-line applications are run straight from the command-line without an interface; some applications — including graphical ones — allow for command-line invocation of certain features). Not all console applications have such command-line options, but mocp does.

Building a ratmen(u) can be as simple or complex as you desire. In this case, I wanted one I could bind to one particular set of keys (meta-Y) to manage mocp functions; I’ve also done the same when running mpd, but I find myself using mocp more often. I also have another (bound to meta-M; mnemonic = music) which has some of my favorite streams and playlists set up in it. This allows me to fully control things as I desire without having to find whatever interface it’s playing in and then fiddle around with settings to play what I want, stop it, etc. I also have a menu set up to adjust PCM volume levels via mocp as well (mocp server doesn’t need to run to use it so it works for other apps which play back audio/video). So I can control all aspects of audio with simple menus rather than convoluted user interfaces which don’t work so well with keystrokes and require use of a mouse.

Here’s the menu I use to control mocp play, start, etc. It’s pretty straightforward. Remember that ratmen/ratmenu/9menu are normally run as shell scripts which need to be set executable.

I have it set up in my .ratpoisonrc to launch on the keybinding noted above. When I hit its binding, I get my menu atop whatever is open (if anything’s open at all):

I’m listening to a stream (Sky Smooth Jazz), so let’s say I want stream information and song title. Or I want to see the state of mocp (whether it’s playing, stopped, etc.). I can select the first choice here, which I have set up to give me the information in a ratpoison status line message:

That could be narrowed down via grep for artist/title or just state. Depends what you want.

The menu for my playlists and streams just uses the mocp options to clear (-c) the playlist, add  (-a) a stream or playlist, and play (-p). I also have options to add playlists to the current one, etc. This integrates well with a shell wrapper I use for playing streams from my browser which is straightforward and set up as my default “player” for pls, m3u, etc.:

#!/bin/sh
mocp -cap "$@"

That keeps stupid windows from opening up and getting in my way while I’m doing other things.

Like I wrote above, I also have an audio control menu which is built similarly. You could use whatever audio control software you have installed on your system to manage MASTER and PCM levels or you can use something like application mixer settings available through command line — depends what your preferred application allows. For this quick example, I decided to use the mocp controls since it’s simple and I also added an option to open a terminal with alsamixer for more control options. I also gave myself enough variables to get a desirable volume within a few keystrokes. There are much more clever ways to script such a thing, but this is just a quick example.

#!/bin/sh
# my  audio control ratmenu

ratmenu -fg cyan -bg blue -align center  \
"mute" "mocp -v 0" \
"volume 67" "mocp -v 67" \
"volume 80" "mocp -v 80" \
"volume +10" "mocp -v +10" \
"volume +5" "mocp -v +5" \
"volume +1" "mocp -v +1" \  
"volume -15" "mocp -v -15" \
"volume -5" "mocp -v -5" \
"volume -2" "mocp -v -2" \
"alsamixer" "xterm -e alsamixer"

As I noted above, you can set up such adjustments for both PCM and MASTER with tools you already have installed. Those will work without regard for what you use to listen to music — whether XMMS, cmus, mp3blaster, mocp, mpc, etc. — but vary in difficulty in setting up.

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.

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 20100304 – Debian Updates cups and sudo, Etc.

March 4, 2010

Over the past couple days, updates have been made available for sudo and cups. Make sure you keep your system patched no matter what operating system you use.

http://www.debian.org/security/2010/dsa-2007
http://www.debian.org/security/2010/dsa-2006

No changes in my own systems. My desktop remains unused. I’ve yet to sell my AA1 (let alone get it ready to sell). I’m still running Lenny on my laptop, still have Gnome bloatware installed even though I’ve been using ion2 and ratpoison recently. The latter remains my favorite, though I like ion* as well. I “fixed” the issue with byte-compiling mingus (mpd client) by installing the GTK version of emacs 22; now I run “emacs -nw” in screen. I’ll probably switch back to the backports version (23) or do a clean minimal net-install, like I should’ve done even though I needed everything ready-to-roll when I installed last time. I may have more time to fiddle with everything after next weekend.

But that’s what I always think.

 07:02:22 up 19 days, 21:10,  4 users,  load average: 0.05, 0.04, 0.10

Not bad for a laptop.

--
posted from weblogger.el

Debian Updates OpenOffice.org

February 13, 2010

Awoke this morning to find that Debian has patched OpenOffice.org for multiple issues. Also, don’t forget Debian stops security updates for Etch in a couple days.

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.