Recently in Nano Category

(Yes, I do have the OpenBSD T-shirt with this design. It doesn't get more geeky.)

I'm getting ready to give the $0 Laptop (Gateway Solo 1450) to our daughter to run her educational games (Childsplay, Gcompris, TuxPaint) on Ubuntu Hardy with the non-crashing Xfce window manager instead of the crashy version of GNOME in this Ubuntu build.

To replace that machine for me, I pulled a Toshiba Satellite 1101-S101 laptop from the boneyard.

With a 1.3 GHz Celeron processor, 248 MB RAM (how it has this amount, I don't know) and a 20 GB hard drive, the specs are pretty similar to the Gateway, except for the Gateway's 1 GB of memory, which I'll probably split between the two machines.

The Toshiba came to me with Windows XP, and this time I wanted to preserve Windows and dual-boot it with a FOSS OS. The CD/DVD drive is extremely flaky. I think it's dying. It does better with "commercial" CDs, and I did get it to boot Partition Magic so I could shrink the NTFS Windows partition and set it up for Linux.

The only Linux CD I could boot was Debian's Etch and a Half. Something was squirrely on our network, and I couldn't get DNS working in the installer. I could've done a minimal install, fixed /etc/resolv.conf and then brought the rest of Debian into the box, but I took this opportunity to go in a different direction.

With all the CPU fan issue on the Gateway, I could never run OpenBSD (or NetBSD or even FreeBSD after the first boot) because I couldn't get the noisy CPU fan under control.

I powered up the Toshiba, which couldn't get networking in Windows either. Since I don't yet have the administrator password, I couldn't update the DNS settings.

I went to an OpenBSD mirror and downloaded a floppy image plus a DOS/Windows utility that helped me create a bootable OpenBSD install floppy. (Before anybody mentions this, I know I could've just as easily created a Debian boot floppy.)

The Toshiba successfully booted off the OpenBSD floppy, and I was able to plug in a mirror and do a full install over the network.

This was my first dual-boot install of OpenBSD, and after the install was done, the machine wouldn't boot at all. I hadn't installed a bootloader and thought the box would boot into Windows, where I planned to modify that bootloader to choose between Windows XP and OpenBSD. Instead I got a "no operating system" message.

And I don't have a Windows XP disc from which to "repair" the master boot record.

So I rebooted with the OpenBSD floppy, dropped down to a shell and added the OpenBSD bootloader at the prompt:

# fdisk -u wd0

Then I rebooted and was in OpenBSD. There is a GRUB package for OpenBSD, and I'll probably install that so I can easily dual-boot either Windows and OpenBSD or eventually Linux and OpenBSD. There are other alternatives as far as bootloaders go, but my familiarity with GRUB is what is governing my decision in this case.

I'm also going to add rsync as well. I have no skills when it comes to OpenBSD's dump and restore utilities, so having rsync is another plateful of Linux-like comfort food that will help me get along in OpenBSD.

Other packages I've installed thus far: nano, mc (the Midnight Commander file manager), Rox-filer (my favorite X file manager), Geany (X text editor) and the Firefox (I probably should've gotten the version with Java, but I'm going to try to add the Java developer's kit and get the Java runtime that way) and Opera Web browsers.

Opera came via a port and not a precompiled package, and it took a lot longer to install this time than the last time I installed it in OpenBSD (on the Compaq Armada 7770dmt), if I recall correctly.

When you download the ports tree and install from there, everything is fetched for you and compiled when needed. Looking at all the output in the terminal, it looks like these ports could never work, but in my experience with OpenBSD they always do. This time was no different. It took maybe 45 minutes to get all the dependencies plus Opera, but after that it worked immediately.

I've grown accustomed to OpenBSD's default window manager, Fvwm2, and I'll probably stick with it for at least awhile before adding any others. Unlike Debian, Ubuntu, Slackware, etc., installing an app in OpenBSD doesn't automatically update the menus, so you have to manage this yourself. Getting into the guts of the .fvwmrc file is more instructive than not, and once I figured out how to do it, it got less arduous.

I still don't like waiting for ports to download, compile and install, so having 4000+ precompiled packages for i386 is a very good thing.

After a year of strugging with and complaining about the Gateway fan blasting away under OpenBSD, I couldn't believe that I was running OpenBSD 4.4 on the Toshiba with no CPU fan problem whatsoever. Everything from autoconfiguration of my two network interfaces (one Realtek 8189 wired Ethernet, the other an Orinoco WaveLAN PCMCIA wireless) to a perfect xorg.conf made this OpenBSD install go .

I haven't checked audio yet, but I've never had OpenBSD fail to configure the sound card.

I've always read that most OpenBSD developers use laptops to code in the OS, and now that I have this Toshiba running OpenBSD better than anything I've tried before, I'm amazed at how well it installs and runs on this specific platform.

I've probably written a half-dozen posts about exactly why I'm running OpenBSD, and I'll probably write another one as time allows in the week ahead.

And I'll be either ordering a CD set or contributing directly to the OpenBSD project in the days ahead.

The extremely lightweight Swiss GNU/Linux distribution Slitaz burst upon the scene in March of this year promising to be easy on system resources yet possessing enough power in the form of basic applications to actually get things done.

In my original non-review, I couldn't really get Slitaz running on any of three PCs, so I ended it this way:

Hopefully they'll get it right with SliTaz 1.1 (or 2.0), but for now, it's a distro with a lot of promise but not a whole lot of delivery -- at least for me.

But there was also this:

I'll try it in the $15 Laptop (based on a Pentium II MMX and with the Orinoco WaveLAN wireless card) ...

Coincidentally, I've been looking for new distros to run on the $15 Laptop (Compaq Armada 7770dmt), and I decided to finally give Slitaz a spin in it.

It works.

And so far, it's quicker than anything I've tried on it before. The closest thing I can compare it to is Damn Small Linux.

As of DSL version 4.4, both have the "Bon Echo" version of Firefox, with Slitaz using a more-recent build of what basically is Firefox.

Having Firefox named Bon Echo presents one problem: It's harder to install Google Gears, which would enable Google Docs to function in offline mode. I'm sure there's a way to do it, but so far that's been the big stopper for me with DSL (and now Slitaz).

Another stopper: Slitaz seems to want the user to store data on a USB-connected drive. But this laptop, made somewhere around 1999, doesn't have USB. Hell, it doesn't have Ethernet. My connectivity comes via a Orinoco WaveLAN Silver PCMCIA card, and even if I did have a WiFi signal, which I don't, I'm not sure Slitaz 1.0 supports wireless connectivity. Otherwise, I'd be trying some packages from the Slitaz repository.

But in its "raw" configuration, Slitaz is a 25 MB ISO — smaller than Puppy Linux and Damn Small Linux, and with fewer apps as well.

The beauty of it is that Slitaz 1.0 is running entirely in RAM — and I've only got 144MB on this laptop.

Again: 144MB and running entirely in RAM. I don't think there's a system out there with X that'll do this without tapping into Linux swap (although Damn Small Linux might be coming close).

Like Puppy and DSL, Slitaz is based on the JWM window manager, which has plenty of features and lots of speed to go with it. Right-clicking gets you a small menu, but for the full menu, you need to left-click on the Slitaz spider icon at the top of the screen.

Slitaz is lean but does have enough apps to get by.

Besides Firefox/Bon Echo (version 2.0.0.12 on the live CD), there's:

• My favorite development editor Geany
• The mhWaveEdit audio editor (at least that's what I think it is)
• emelFM2 file manager
• Clex File manager
• mtPaint image editor (one of my favorites)
• Grab screenshot
• GPicView Image Viewer
• Gparted partition manager
• Htop processes viewer
• Lighttpd Web server
• gFTP client
• Grsync
• LostIRC
• Retawq Web browser
• Scpbox secure copy app
• Transmission Bittorrent app
• ePDFView PDF viewer
• Listpatron (I can't figure out what this does, but it appears to "make lists")
• OSMO personal organizer
• SQlite database
• Wikiss PHP Wiki
• Bc calculator
• Burn ISO
• ISO Master
• Leafpad editor
• Nano editor
• Xpad sticky note editor
• Xterm

I'm not sure yet how extensive the Web-server capabilities of Slitaz are as yet, but it does have the Lighttpd server, SQLite database, along with PHP, so you can seemingly roll out a dynamic Web page on the system as configured.

Once I get to a live Internet connection on the Compaq, I plan to check out the Slitaz repository, which has some applications that aren't on the live CD, including Abiword and the GIMP.

I'll have to deal with how to save my settings in Slitaz without USB, but in that quest, I found a great utility called Mountbox that enabled me to easily mount partitions from my hard drive and then look at them with emelFM2. Not that it's hard to mount partitions from live CDs, but this app is as good as the mount tools in Puppy or DSL, and I'm glad to have it.

However, upon mounting a hard-drive partition, I could see all the files there, but I was unable to write a new file to it. That's something I'll have to work on.

(Hint: When you boot Slitaz, the standard user is hacker, with no password. Root's password is root.)

After a read through the online documentation, I settled on the following boot codes for my laptop:

boot: slitaz vga=788 lang=en kmap=us home=hda3 sound=noconf

I was still asked by the system (in French, no less) what resolution to use for X. But the boot process was a bit quicker, since I wasn't asked this time to choose a language or keyboard, nor was I asked to configure sound, something that didn't work automatically (and never does for this laptop in Linux).

I created a file, saved it in the Slitaz filesystem and rebooted without the cheat codes. The file wasn't there. I tried again with the boot codes, and my file was there. The same thing worked for a Firefox bookmark. As long as I used the home=hda3 boot code (since hda3 was the hard drive partition I chose on which to put my Slitaz save file) when booting, everything works.

So it turns out you don't need a USB drive to save files in Slitaz.

There's a "Cooking" release of Slitaz that looks much changed from the 1.0 release, and I will try it soon and hope that perhaps some and hopefully many of my problems will be addressed. It uses Openbox instead of JWM, features desktop icons, uses HAL to automatically mount media and even has Firefox 3.

Another addition, among many, to the latest build of Slitaz is wireless support. Again, I'll have to burn a disc tonight and give it a try when I'm near a WiFi signal.

Thus far, Slitaz 1.0 is absolutely the fastest operating system I've ever used. While it's still fairly young, it boasts of a lot of functionality, and if it runs on your particular hardware, it's a live CD that's well worth having in your laptop bag.

I'd love to have another alternative to Puppy Linux and Damn Small Linux, both extremely lightweight — and extremely well-formed — distributions designed to be run as live CDs (but also capable of being installed to the hard drive). And again, running entirely in RAM with only 144MB is as lightweight as they come.

Right now, I can't use Slitaz with the same "expertise" with which I can use Puppy or DSL. But for a quick-booting, quick-working live CD, Slitaz does exceedingly well for such an early stage in its life.

I'll be watching Slitaz very closely, and I expect big things for it in the future, should development continue — and I really do hope it does.

Point of order: According to the boot screen, Slitaz stands for "Simple, Light, Incredible, Temporary Autonomous Zone."

So far, Slitaz lives up to that name.

More on Slitaz:
Slitaz on Distrowatch
Distrowatch review of Slitaz
My first Slitaz post from April 2008
K.Mandla's review of Slitaz
TechieMoe review of Slitaz
TechSource review of Slitaz

I did a Debian Etch install on one of my test machine drives recently, and today I added the openssh-server package so I could play around with PuTTY and Xming.

Once I installed openssh-server (I used Synaptic, in case you were wondering), using PuTTY to start the connection, I was asked whether or not I expected the encryption key to change (I was, since this is the Debian install, not OpenBSD, which I've been using until now).

One bonus of using this Debian Etch install: The OpenBSD drive is noisy, which probably means it's gonna go. The drive on which I installed Etch is much quieter. I probably need to get some newer, bigger drives ... or a whole new test box, but that's another story for another time.

Quirks in Debian Etch with openssh-server: I can run X apps, no problem. When I run:

$ nautilus &

... I get a huge window with the entire GNOME desktop, minus the toolbars. And I can't close that window -- Xming won't let me, I think. X-ing it out doesn't work. I had to kill the process in my PuTTY terminal. (Note: $ startx & does not work ...)

Speaking of security: OpenBSD is known for its security above all else. Here's how using openssl openssh (which was created by the OpenBSD team) differs -- at my lowly level, anyway -- between OpenBSD and Debian Etch:

In OpenBSD: The sshd server is included in the standard install. But it can't be used until rootly powers are used to implement it. Running X over ssh is not allowed until the appropriate configuration changes are made. But root logins are allowed over ssh by default; the administrator, however, can choose to block root login (which I did).

In Debian: Debian installs without the ssh server installed. So without the administrator specifically installing openssh-server, nobody can ssh into the box. But once that package is installed, Debian automatically allows ssh logins -- and X logins as well. As with OpenBSD in its default state, root logins are permitted over ssh until that feature is turned off in /etc/sshd_config.

I don't understand all the lines in sshd_config, but I probably should get better acquainted with each and every one of them.

Speed? It could be the fact that this Debian Etch box has the GNOME desktop, and I've been running OpenBSD either from the console or the default Fvwm window manager, but everything happens a lot faster with the OpenBSD install (hardware is the same for both). I could modify Debian to boot to a console instead of GDM, and that might speed it up a bit (memory is 256 MB), but whatever the reason, thus far OpenBSD is a bit smoother. (Later, things seemed to run a bit better when I didn't log in on the Debian box and hence didn't have GNOME running).

More on security: If this box wasn't just something for me to play with on the local network, the stakes would be a lot higher. I suppose not having sshd is pretty good security when compared to having sshd installed but not enabled. And I also suppose that installing sshd (openssh-server) means that you want to actually use it. But in the case of both OpenBSD and Debian, I wonder why root logins over SSH are enabled by default. If anything, I'd expect OpenBSD to disallow them until the administrator of the box decides to turn that feature on.

And since you can always use su or sudo (Ubuntu has conditioned me to like sudo, and I always add myself to the sudoers list with visudo, there's really no reason for a root login over ssh.

Side note: Debian doesn't automatically add the primary user to the sudoers list, something I always do because on many occasions I'd rather use sudo than su.

Ubuntu, by default, disables root logins entirely and only offers sudo. It makes setting root's crontab a pain in the ass. I use sudo -i crontab -e to get into root's crontab in Ubuntu.

Side note to a side note: While I can fake my way around vi, I like it when nano is the default editor and crontab -e brings up nano instead of vi. The one thing I don't like about nano is that when you wrap text, actually linefeeds are inserted. At least in vi you can have the text break in the middle of a word without turning word wrap on (although you are able to do so if you want wrapped text). The one thing I like in X editors is the ability for text to look wrapped without actually being wrapped.