How to install Ubuntu Linux on the decTOP SFF computer
I recently bought a decTOP small form factor (SFF) computer. My goal was to build a cheap, fanless, quiet, and low power consumption Linux server. For $99 plus the cheapest available shipping, $40, my machine arrived 11 days after I placed the order.
This is a tiny computer, about the size of a Mac Mini. But, because it has no fan, it runs a bit quieter and, with the help of a 1-watt, 366 MHz CPU, consumes only 8 watts. For comparison, the G4 Mac Mini consumes about 20-30 watts, depending on load.
The decTOP comes with 128 MB of RAM in its sole SO-DIMM slot and a 10 GB 3.5 inch hard drive. I understand that it's a simple matter to replace the drive and to upgrade the memory to a maximum of 512MB.
It also comes with no operating system and the ability to boot only from a USB drive. This article details the steps I used to build the USB boot/installation drive and install Ubuntu 6.06 on the decTOP.
There is another article -- with additional decTOP links -- here on installing Ubuntu 6.06 on the decTOP with the aid of a Windows system. Fortunately ;), I run Mac OS X and Linux (Ubuntu 7.04), so that article didn't work for me. I did the installation of the Ubuntu 6.06 LTS Server Edition using my Ubuntu Linux box and a 1 GB USB flash drive -- although a 512 MB USB drive should work as well.
- Download the Ubuntu 6.06 server ISO image from the Ubuntu download page. Depending on your plans for the decTOP, you might want to choose the desktop version. Unless you have already upgraded your decTOP's memory, however, you'll want to stick with the 6.06 releases.
- Install the mbr, mtools, and syslinux packages on the Linux system you'll be using to prepare the USB drive. If you run Ubuntu or some other Debian-derived system, the following commands may do the work for you.
apt-get install mbr
apt-get install mtools
apt-get install syslinux
- Partition the USB drive with a single FAT-16 partition. I used the fdisk 'n' command to make the new primary partition 1. The fdisk 't' command can be used to change the partition type to FAT-16. My device name was /dev/sda.
- Make the FAT-16 partition the active partition. I used the fdisk 'a' command.
- Install a master boot record on the USB drive.
- Install syslinux on the USB drive. Note that the USB drive should not be mounted when you do this.
syslinux -s /dev/sda1
- Create a mountpoint and mount the ubuntu ISO image using the loopback device.
mount -o loop -t iso9660 ubuntu.iso /iso
- Create a mountpoint and mount the USB flash drive.
mount /dev/sda1 /usb
- Copy the contents of the ISO image to the USB drive. This will take some time.
cp -r . /usb/
- Copy the /usb/dists/dapper directory into a new /usb/dists/stable directory.
cp -r dapper/* stable
- Copy several files from /usb/install to the /usb root directory.
cp /usb/install/vmlinuz /usb/
cp /usb/install/mt86plus /usb/
cp /usb/install/initrd.gz /usb/
- Install the following text into a file named syslinux.cfg in the /usb root directory.
append initrd=initrd.gz ramdisk_size=24000 root=/dev/ram rw
- Flush all writes, unmount, and remove the USB drive. After the sync step, wait for all of the data to be written to the USB drive.
- Connect the ethernet adapter to the decTOP and connect it to your network to allow automatic configuration of the network interface.
- Insert the USB drive into the decTOP and power it up. The decTOP should automatically boot from the USB drive and start the Ubuntu installation.
- Answer only the first two questions concerning language selection and go to the next step, below.
- Press Alt-F2 (hold down the Alt key and press the F2 function key) to open a shell. Then press enter to start the shell.
- Create a /cdrom and a /dev/cdroms directory in the installation ramdisk
mkdir /cdrom /dev/cdroms
- Go to the /dev/cdroms directory and build a symlink from /dev/sda1 (that is likely the device name of your USB boot partition) to /dev/cdroms/cdrom0.
ln -s ../sda1/cdrom0
- While still in the shell, mount the USB drive to mimic an installation CD-ROM.
mount -t vfat /dev/cdroms/cdrom0 /cdrom
- Return to the installation program with Alt-F1 and continue the installation.
From this point, the process should be identical to a routine CD-ROM installation.
For a grand total of $140 and 8 watts of power consumption, I now have a near-silent Linux server running 24/7. You can telnet to it here and marvel at its blinding speed running a 250,000-sector Space Tyrant game.
|mail this link | permapage | score:9577 | -Ray, August 16, 2007 (Updated: April 26, 2011)|
Librenix T-Shirts and Coffee Mugs!
|For today's example of my (semi)elite C programming skilz, I submit for your inspection the Librenix T-Shirts! Yes, I created the images on these shirts and coffee mugs entirely with C code. While the code isn't up to the standards *cough* of my open source Space Tyrant project, at least the output is colorful and not entirely textual!|
click either image to see the T-Shirts, Coffee Mugs, etc.
(If you like the images but don't care for 'librenix' on your shirt, these same styles are available for all 50 US state names as well as with the signs of the zodiac here)
(and here are some modern prints)
|mail this link | permapage | score:9490 | -Ray, June 6, 2010 (Updated: May 13, 2014)|
Beneficial Computer Viruses
|An article on last week's front page of SecurityPortal entitled Reflections on the Strange, Perplexing, Interminable, and Most Lamentable Phenomenon Known as the Viral Wars contains an alarming suggestion. |
It proposes that we..."Develop antiviral viruses (antibodies) that are polymorphic and mobile. Roaming the Internet they would seek out and destroy new viral strains. (SARC is doing some interesting work in this area. More needs to be done though.)". There are several problems with this idea.
First, it ignores the basic problem with viruses -- that they run on other people's computers without authorization. Presumably, a "beneficial" virus would propagate by similarly illegitimate means, but carry a "good" payload rather than a destructive one. For that reason, I believe that anyone who releases such a "good" virus should be charged with the same offense as one releasing a "bad" virus, although with reduced penalties for its perhaps lesser damage and less deliberately destructive intent.
Note that the good virus would not only propagate and execute without permission, but would also consume network bandwidth, processor cycles, memory, and disk space. Resulting, inevitably, in the denial of the system owner from using those resources. That is what is commonly called a "denial of service" attack, or DoS.
Next, there is the non-trivial problem of identifying malicious programs. Identifying a known, existing virus is easy in comparison to programmatically distinguishing between unknown good and bad code. Since many legitimate programs contain several ways to damage or remove files, the simple ability to delete and modify files cannot alone identify a program as bad. So, perhaps the good virus would limit itself to wiping out only programs that it could (somehow) identify as capable of replication by combining its own code with that of another program. That would surely be inconvenient for the makers of self-extracting archive software. But, assuming that that obstacle could be overcome, how would a good virus tell another good virus from a bad one? Both behave similarly, including the practice of damaging or destroying other files. Imagine the resources wasted in unintentional global wars between various strains of good viruses! We can only hope that all creators of such good viruses carefully write their code to recognize every other species of good virus -- a task made difficult or impossible by the fact that the good viruses would be cleverly polymorphic.
Note that, for liability reasons, good viruses would have to be very nearly perfect. To have them mistakenly delete a recently patched copy of Microsoft Word could be very inconvenient.
And, of course, let's not overlook the possibility of mutant evil strains of the so-called good virus -- strains created by shady programmers who would not otherwise be capable of writing such sophisticated code. The new evil -- and polymorphic -- strains would likely be mis-identified as good by unmodified good viruses yet carry a very destructive payload. A payload which could include the killing of all the unsuspecting good viruses that it can so easily identify.
Then, some time in the future, we will pause for a moment of silence while we remember the deceased good viruses that first invaded our computers, escalated the virus wars, then gave their very essence to improving the breed of their sworn enemies before being themselves ruthlessly destroyed by derivatives of their own code.
|mail this link | permapage | score:9435 | -Ray, June 26, 2000 (Updated: January 1, 2003)|
Tutorial: Introduction to Linux files
|This newbie-level Linux tutorial is an introduction to handling files from the Linux command line. It will cover finding files, determining their type, renaming, copying, examining their attributes, reading their contents, and, in the case of binary files, how to get clues to learn something more about them. Further reading will be suggested for editing files since that topic is beyond the scope of this article. |
The reader of this tutorial is expected to have access to a Linux system and to perform the example commands as we progress through the tutorial. Once logged in to your Linux system, open a terminal session. Under Red Hat Linux, terminal is found in the 'system tools' section of the menu. (Your system may, alternatively, use a terminal program called 'konsole', 'xterm', or 'shell'. Look around your system for a menu with 'tools' or 'utilities' in the name if necessary.)
ls: Listing files
Let's start with the ls command. ls is an abbreviation for list files. Type ls now, then press the 'enter' key to see the names of the files in your current directory. The results from my 'tmp' directory are listed in bold below:
$ ls /tmpNote that I said 'your current directory'. To get the a listing of files in another directory, enter ls [dir] where [dir] is the name of the directory you wish to look at. For example, to see the file names in your top level directory, '/', type the following:
$ ls /For more information on the files, use one or more of the ls command line switches. Here I use ls with the -l switch for a 'long' listing:
bin dev home mnt
proc sbin tmp var boot etc
initrd lib opt root sys usr
$ ls -lNote that with the -l switch we get the file permissions, the inode links, the owner and group names, the file size in bytes, and the timestamp of the file as well in addition to the name. The ls command has many more options. Type man ls for a full list of options.
-rw-r--r-- 1 root root 9649
Mar 28 02:47 tardir.0.log
file: What is this file?
Linux also provides a handy command to help determine what type of files you are dealing with:
$ file tardir.0.logThe Linux (and Unix) file command knows about, and can detect, many different file types. In our example, file tells us that tardir.0.log is a simple ASCII text file.
tardir.0.log: ASCII text
less: Paging through a file
Now, to actually look at the contents of a text file, we have many options. The most common is the more command and a more elaborate, newer command is less. I like less because it lets you use the arrow keys for scrolling and the pgup/pgdn keys for paging through the file. The following is a condensed page from the command less tardir.0.log:
home/tfr/From the ':' prompt we can page or scroll forward or backward. We can also type /star to search for the next occurrance of the string 'star'. Enter man more or man less for more information on the more or less commands, respectively.
[ . . . ]
mv: Renaming a file
Now, suppose we want to rename a file. Under Linux (and Unix) we 'move' it with the mv command as follows:
$ lsNote that the mv command only produces output when there is an error. In this case, we encountered no error so mv quietly performed its work.
$ mv tardir.0.log tar.log
cp: Copying files
To make an actual copy of a file, we use the cp command. For example, to make a backup copy of tar.log named tar.log.2, we enter the following:
$ cp tar.log tar.log.2Again, we get no output to the screen when the cp command is used without error. We had to use the ls command to see the result of the command. Enter man cp for more details of the cp command.
strings: Looking for text in a binary file
Now, to actually look inside an unknown binary file for text strings there is a command called, appropriately enough, strings. For example, if we run the strings command on the 'echo' program, we get, in part, the following:
$ strings /bin/echoType man strings for more information.
Copyright (C) 2004 Free
Software Foundation, Inc.
Written by %s, %s, %s,
%s, %s, %s, %s,
%s, %s, and others.
grep: Finding particular strings in a file
To look for a particular text string in a file, we use the grep command:
$ grep html tar.logAnd, of course, man grep will retrieve additional instructions for the grep command.
find: Finding files by name
To find all files with a particular name on your system, use the find command. For example, to find files named 'echo', enter the following:
$ find / -name 'echo'Further, to find all files in the /var filesystem with the string 'echo' in their names, enter this:
$ find /var -name '*echo*'
To get started editing text files try this tiny vi tutorial. After going through the quick tutorial, you can click the contents button and reach an advanced vi tutorial as well as other vi information.
For information on moving around in a Linux filesystem try this Introduction to Linux in ten commands. That article also provides additional examples on some of the commands covered here.
|mail this link | permapage | score:9426 | -Ray, April 2, 2005||