Slackware v Ubuntu: Not What You Might Think - Part 3

When it comes to system configuration, Ubuntu and Slackware could hardly be more different. Ubuntu uses GUIs for everything and Slackware doesn't use any. Interestingly, both distributions are aiming for an easy and straightforward configuration. Again, it's only different methods to, ultimitly, the same end. I'll tackle the pros and cons of Ubuntu first.

Configuring in Ubuntu is very guided process. Open this window, check this box, click this button and you're done. This has some pretty clear advantages. My wife, for instance, has no idea how to use the command line in Linux but still wants to be able to connect to the internet. In Ubuntu this isn't a problem for her. In Slackware she would, most likely, never figure it out, give up and end up calling me at work to help walk her through fixing it.

There are some real disadvantages to this method though. The biggest one is something that *nix users have known for years. You will never (well I shouldn't say never, but almost never) find a GUI that provides all the functionality of the command line. It just doesn't happen. What if I don't want certain web related services to have access to that NIC? What if I need to do ip forwarding or configure detailed firewall rules? Ubuntu does not have readily availible GUI answers to these problems.

On a related note, while many times it is easy as knowing which config files to edit in Ubuntu to achieve these goals, many users who have come to rely on an interface will either have no idea what to do with these files or even know that they exist.

This is where Slackware pulls ahead. In Slackware you won't find pretty interfaces waiting to walk you through the process of setting up different aspects of your machine. Some are included with KDE and some of those are useful. Not all of them work with Slackware, however. The KDE wifi manager is a great example. It is, at least at this time and to my knowledge, incompatible with Slackware. Someone wanting to configure their internet with this tool on Slackware is going to be disappointed.

But all is not lost. Editing configuration files in Slackware is incredibly easy. Well commented files and a little bit of Linux knowledge make changes rather straight forward. One of the huge benefits here is that you will know how to do things this way. Different distributions use different programs and different GUI based methods for system configuration. Knowing how to handle edits at the command line will make moving between these differences a non issue.

This was, in the end, one of the reasons that moved me to Slackware. I don't want to mess around with a dialog box setting configuration options only to discover later that several features are not represented by that window. It takes less time in the long run, for me anyways, to edit a group of files then to find and use programs to edit each one for me.

Again here which is better is simply a matter of which you prefer. They are both simple and easy solutions. I will revisit this topic at some point in the near future but for now I leave you with this;

I would recommend either of these distributions to anyone looking to start using Linux. It all depends on what they really want out of it. If they want to use Linux as a safe and effective operating system with little in the way of new learning then Ubuntu is surely a good way to go. If they want to _know_ Linux, well for that it's tough to beat Slackware.

Whatever Happened to the Ibex Review?

I realize I left anyone anticipating my review of Ibex hanging. There will not be a review until the production version is out. I simply don't have the time to constantly troubleshoot a system just to do a review right now. Frankly there were still a ton of rather critical bugs as of alpha 6 that made broad use of the system troublesome. I was doing my part and submitting bug reports but again, I just don't have the time right now.

For anyone having a problem with jockey-gtk,

I still constantly see new people reporting this bug on the launchpad for Ibex. The bug has been fixed and a patch is availible. It seems to be a rather common (and rather annoying) bug. So if you're experiencing a dbus error with jockey-gtk go to the Ibex launchpad and grab the patch.

Slackware v Ubuntu: Not What You Might Think - Part 2

So where does Slackware fall in those regards we talked about with Ubuntu last? That is, on package installation and repositories.

Well that package installation process for Slackware is just as simple as it is for Ubuntu. It's just a different kind of simple. The command line tool pkgtool is run and packages installed locally. There is no default ability to install over the network and there is no dependency resolution. A few simple add on tools like slackpkg (available in the extras parts of the Slackware repository) and sbopkg (availible online) allow for a bit more elbow room but still keep things rather simple.

I am aware, by the way, of a package called slapt-get that resolves dependencies within Slackware but I have yet to use it and probably won't. Not on my production machine anyways.

The lack of dependency resolution is a real gift in my book. I don't much like systems that try and automatically add more software for me, even if I do get to confirm it. If I need or want something else besides the package I'm installing I'll fetch it myself. This isn't even too troublesome for a beginner to Linux as the readme files of almost all packages list dependencies so you know what else you need to get to make it run. I have, so far, only run into one package that did not correctly list these in the readme file. Well it may have, it's a tough case to judge. It required an additional package for the build though not to run. While in some cases this can lead to frustration in not being able to get a package to work, it also relieves the frustration of having your package manager or system broken when it automatically installs something that doesn't play well on your machine.

On the repository side of Slackware you have relatively few choices compared to other major distributions. This can cause some problems but isn't too cumbersome. The plus side here is that you probably don't need access to the 25,000+ packages of Debian to get the software you want or need thereby making searches much faster. The down side is that most things that can't be found in the official repository or on the slackbuild repository (Managed by some Slackware developers but not official. Use sbopkg to automatically fetch and install packages from this source) will need to be compiled from source.

I, for one, don't usually mind compiling from source. It allows greater control over the outcome and it's really not as hard as many people make it out to be. Most programs can be compiled by following three steps as root. Jump into the directory containing the top level of the source code and use these three commands.

1) $ ./configure (options) [Discover options with ./configure --help]

2) $ make

3) $ make install

For 90% (if not higher) of the programs I have compiled that's all it takes. The second most common method I have seen will use the command 'ant' followed by something like './install.sh' but it's still fairly straight forward.

The big negative here is that it can be very time consuming. My only real grudge against installing things from source is how long it takes. When I bring a new system up in Ubuntu I can have everything I need or want installed on it in roughly 11 hours (including downloads). I am still working on that goal for my Slackware system after three days. Granted if I skipped work it may well be done right now but it's a process that has to be monitored constantly which is both good and bad for what is, I hope, obvious reasons.

Part 3 will go into configuration on both distributions.

Slackware v Ubuntu: Not What You Might Think - Part 1

Slackware and Ubuntu share a common line of thinking. They both aim to be simple. However, they have different approaches to simplicity and different target audiences.

Ubuntu wants to be simple for end users switching from Windows. Everything has a dialog box. Installation of additional packages is straightforward and simple. You can throw the disk in the drive, boot and go.

Slackware wants to be simple for Linux users. BSD style init scripts that are easy to edit. A package management system that won't install anything you don't expressly tell it to. A setup environment that allows someone in the know to install exactly what they want and nothing else.

Two days ago I installed Slackware 12.1 for production use on one of my computers. This marked the first time since I started using Linux (roughly four years ago) that I would be using something other then Debian or a Debian based system on a production machine. The reasons for the change were immense. What I'm going to go into here is some of the highlights and drawbacks of two distributions that strive to be simple and why I would ultimately recommend them both to a new Linux user.

Ubuntu has a lot going for it with a new convert to the Gnu way of computing. For someone who isn't much of a computer person it is, perhaps, the best option as far as Linux goes. It remains installed on one of my computers to this day so that my wife can use it without needing to call her tech support (myself) while I'm at work. I'll look briefly at each feature that is easy to use and why it can be a problem.

Installing extra packages in Ubuntu is pretty damn easy. Using software like Synaptic extra programs can be added with as little as three or four mouse clicks. There is no need to worry about dependencies and conflicts as these are automaticly resolved for you. Repositories give you access to over 25,000 packages meaning you can probably find what you're looking for somewhere in the heap.

Auto dependencies and conflict resolution can be devastating. The system is not always right, for one. Part of what I do is break machines. It's how I constantly develop my ability to fix them. My record for breaking a fresh install of Ubuntu is only 30 minutes. It was the package manager that broke it. The system required a rescue boot to recover. The problem? The auto conflict resolution decided that the gnu c library should be removed. The system was near useless after. Now someone who knows Linux well enough to know that it's not a good idea to remove that could have prevented this. However, someone who is not well versed in what packages are necessary would have surely allowed their removal and therefore lost the system.

As a side note, the fastest I ever killed an installation was actually during an installation and not on purpose. Apparently earlier version of OpenSuse did not mix well with tablet laptops.

There is also a serious drawback to having access to 25,000+ packages. It can make finding the right thing a real pain. The searches do not always turn up what you're looking for and browsing through package by package can take hours.

Continue on to Part 2 to keep reading.

Ubuntu 8.10 Inreped Ibex: Part 1

Alright, I know it's technically Saturday and I said I would have this up on Friday but I ran into some technical difficulties. The update is installing on my test computer as we speak. The problem is that I started the upgrade _Thursday_ night. So far several packages have failed to upgrade properly as well, including update manager. However this is an _alpha_ release (alpha 5) so I expect these problems and won't hold it against them. They will be duly reported.

Well point is that I have nothing really to say tonight. I wish I did. But I don't. Only thing I can really throw in there is that it would be nice if the bandwidth on the Ibex repositories were higher. Upgrading my laptop to 8.04 from 7.10 took roughly four hours total. The massive download _alone_ for Ibex took over 14 hours. Not ok in my book.

More to come as I finally get to rev up the system and take a look around.

Until then.

First Look at Ubuntu 8.10: Intrepid Ibex

Well I had planned on this being the first article I wrote about the forthcoming Ubuntu release but I'm afraid that at this time I can not do that. The upgrade will not properly work on the test desktop I selected. The problem, according to the feedback from update manager, is an inability to correctly modify the repositories prior to the actual upgrade taking place.

When I have time I will look further into the issue and see if there is already a workaround known and if not what I can do to create one.

Until then I have selected another test desktop which will take a full install of Ibex from CD. However, I will not consider these results to be reliable in terms of upgrading as we're talking about different processes being used at this point.

To highlight some on the features of the new version I will be using ext4 with LVM and both Gnome 2.2.3 and KDE 4.1. I've never been a fan of KDE but I suppose it deserves a place in the reviews as many people do like it and use it with Ubuntu on a regular basis.

Bugs found during this test will be listed here and be submitted to the development team.

The desktop that will be used has a Pentium 4 at 2.6Ghz and 2GB DDR400 RAM along with a 30GB and a 60GB IDE Hard Drive. Testing will begin this Friday the 12th and will continue for five days with posts being made at least once a day on the status and results.

Sorry for the delay.

Ah, before I forget the version will be Alpha 5.

Until then.

How to Turn an Older Tablet Notebook Into a Functional Machine: Part 3 Choosing a Window Manager or Desktop

This is part 3 in a series about making some solid use of an older tablet laptop. In part 1 we talked about performing an install over the network and in part 2 we went over configuring wireless and installing some basic packages with a few command line tips for good measure. Now we're going to discuss choosing a window manager or desktop for the system.

Many people will never need a desktop environment. Actually the laptop used for this test went without one for some time after it was setup because I simply had no need to use one. However, as luck would have it some of the programs I wanted to use had to run in x. They were all either IDEs or document viewers for viewing pdf and ps files and there were very few of them. Since only a few programs needed x to run and the laptop isn't exactly top spec I saw no need to go for one of the larger desktop environments like Gnome or KDE. Even Xfce, I decided, was too much when all I wanted to do was run some nicely featured coding environments and view pdf files. The choice was made to use a window manager instead.

A window manager is kind of like a desktop but far more rudimentary. Many of them are still quite capable of looking nice and performing all the tasks you could possibly need them too. They are as a rule harder to configure then the major desktops but more extensible. They are also generally faster and consume less resources, in terms of both memory and storage space.

Choosing a window manager is a very personal choice. Go with whatever works for you and suits your needs. I tried quite a few before I settled on one to use and you probably will too. Check out xwinman.org for a nice site with information and links to various window manager and desktop sites.

The first window manager I tried (from here on noted as simply wm) was Enlightenment. I chose it because I had heard of it. That was my own motivation for using that as a starting point. Suffice to say I did not enjoy it. At all. It did what I needed it to do, I just didn't like the feel.

The next one I tried was Fluxbox. I should mention here that I started with the version from the repository first. Only if I liked it did I then get the most recent version and configure anything. The version of Fluxbox I got from the repository was useless. Literally. Without configuration I was left with a blank blue screen and a task bar with a clock. No key binding, no way to access programs or a terminal, no nothing. I only wanted a wm so I could run the five programs I had that required one. I wasn't looking to spend a ton of time setting up my wm when I was barely going to use it. Fluxbox was off the list.

The third one I tried was Fvwm-Crystal. Here we had a nice little system going on. I decided I liked it enough to download the newest version and patch it and was left with a nice looking functional desktop. It was already set up with a decent configuration and was easy to edit further. This one got to stay on the list but I wasn't done trying things.

The last one I tried was IceWM. The version from the repository was decent enough so I installed the latest over it. Bingo. I was hooked. Configuration was not as simple as for Fvwm-Crystal but it was still quite easy. Notably the key bindings. A simple configuration file allowed me to set a key binding for everything I wanted to use. No need to navigate or even setup the menus. A Ctrl-alt-e and I launch Eclipse. A Ctrl-t and I get a terminal. Ctrl-alt-h launches dhelp to provide me documentation. This was the one. I even took the few minutes to give it a nice looking theme (blue heart) and a decent background image (using habak). I also set up a pair of terminals that stick to the desktop and are completely transparent to let me monitor the system with 'top' or launch any other program I may need without having yet another window on the screen. All said and done IceWM only occupies 3.4% of my memory and .8% of my cpu at the most. Which leaves things running plenty fast.

Fvwm-Crystal would have been a viable option for me as well. I simply found IceWM to be more to my liking. In terms of technical merits I found them to be roughly even. It was mere preference that led to the final decision.

Making sure that your wm launches when you startx is easy enough. Create a file called .xinitd in your home directory and using your favorite editor add the following.

exec icewm

Or whatever the command is for your wm of choice. It is commonly the wm's name but it may be something else so be sure to reference the documentation that came with it. For instance for Fluxbox the command is 'startfluxbox'. Either way be sure that the first word is exec. That's all you need to do.

Now when you boot your computer you will still be dealing with the command line but you can pop open the wm at any time to use those gtk and qt programs you love so much. Many of these wms are highly customizable and will allow you to build more extensive menus in the event that you want to use a desktop more often then not.

And there you have it. We started with a four year old tablet pc that had no operating system, no bootable media, and not much in the way of performance available and gave it a new life as a mobile development platform. Of course it could be used for many other purposes as well. Including just a regular old laptop, but turning it into this was more fun and taught me a lot along the way. Notably in the way of dealing with problems unique to laptops like battery power and unusual hardware.

We've covered network installation, configuring wireless, some basic packages to install, a few command line tips, and choosing a window manager that runs well on the resources available. I hope you took at least as much from this experiment as I did. Soon to come will be a wireless installation attempt and some tips and tricks on configuring IceWM. Until then.

How to Turn an Older Tablet Notebook Into a Functional Machine: Part 2 Configuring Wireless and Choosing Programs

This is the second part of the mini-series of how-tos on making good use of an older laptop. See Part 1 for information about installing Ubuntu on a laptop with no bootable media options using a network connection.

Now that you have a command line interface and a full blown operating system it's time to get things working the way you want them to. I designed this laptop to be a mobile development platform so all of the choices I made were not just skewed to my personal preferences but also to that end. If you're going to use your laptop for something else your decisions in this regard may vary substantially.

The first thing to do is enable wireless networking. After all, what good is a portable computer if you have to plug in to access the internet. Luckily activating your wireless connection from the command line is fairly straight forward. For the duration of this article a $ is your user name's prompt and a # is the root prompt.

First thing I like to do in Ubuntu before performing admin takes is to sudo into root. This saves a lot of time and potential frustration if you forget to type 'sudo' before a lengthy command that requires it. One of the biggest complaints I hear from more advanced users is the lack of a root account in Ubuntu and the need to sudo into everything. Well this isn't actually the case. There are two easy ways to access the root prompt in Ubuntu. One that uses global settings:

$ sudo su root

And one that preserves any locally set variables you may have:

$ sudo su -l root

Either of these commands will bring you to a root prompt that you can then exit from by typing 'exit' or hitting Ctl-d.

Now that your in a root prompt you can configure your network interfaces without having to sudo every time. If you know the essid of the wireless network you need to access you can skip the steps involving iwlist and go straight to iwconfig. Otherwise type:

# iwlist scanning | more

The pipe to more is optional but if there are a lot of networks in range it can be a good idea. Find the one you want to use and note the essid and if it needs an access key or not. Then type:

# iwconfig $eth essid $essid key $key

Where $eth is your wireless interface, discoverable by typing simply iwconfig and viewing the output, $essid is the essid of the network your attempting to connect to and $key is the network access key if required. If the key is in hex you can type it in as is but if it's a passphrase start the key with 's:'. Now when you type 'iwconfig' you should see the choices you made visible for your interface but no ip address. To connect and get an ip assigned via dhcp type:

# dhclient $eth

Where again $eth is your wireless interface. This will broadcast a dhcp request via port 67 to the ap for the essid you specified. One it's complete your internet is up and running.

The next thing to do is install some appropriate applications. I'm going to refrain from discussing window managers or desktops here and save that for part 3. Remember that this laptop was designed to provide essentials for programming and development and not much else.

It should be telling, however, that the first program I install on any new system is Nethack. I just really love to play Nethack. It's also the way I take breaks when things aren't going as planned and I need to relax for a few minutes. For this reason I actually consider it a tool. It's my 'keep phil from breaking the computer' tool. After Nethack there are a few essentials that almost any system ought to have. One of those being an editor. I'm not going to open the can of worms that is the endless debate between vi and emacs. Suffice to say that I use and installed both. For packages whose name you already know and that you know can be found in the Ubuntu repositories you can simply type:

# apt-get install $package

Where $package is the package you want. This will fetch the package from the repositories and install it for you. Otherwise you can launch aptitude by typing 'aptitude' and search for what you want.

Some may ask why I'm bother to go over something as simple as how to install packages if the first part of this how-to required successfully performing a network installation, far from a simple task, and the answer is simply; because you never know. Someone who has little or no command line experience can still figure out how to do a net-boot but may not know how to work with Linux with nothing but a command line handy. It happens. I've seen it.

Some other packages I ensure are installed are gcc, g++, gcj, gfortran, g77, bsh, clisp and associated libraries, a variety of major and minor modes for emacs, octave, maxima, clamav, ruby, perl, python and supporting documentation for all of the above. To break that down a bit:

gcc - The Gnu C Compiler, a true must have for any Linux programmer
g++ - The Gnu C++ Compiler
gcj - The Gnu Java Compiler
gfortran - The Gnu Fortran Compiler
g77 - The gnu Fortran 77 Compiler (I like Gnu compilers what can I say)
bsh - Bean Shell, a java scripting shell
clisp - Common Lisp, an amazingly handy programming language
octave - Octave 2.9.x (The version I'm currently using), a math and science scripting program
maxima - Another math scripting program
clamav - Clam Anti-Virus, just cause your using Linux doesn't mean you shouldn't be careful
ruby, perl, and python - Handy scripted languages used mostly for admin purposes (by me anyways)

That is of course just a sample of what wound up on my system. I just consider these some of the bare minimum packages that should be installed on a system whose purpose is to develop programs. The math and science scripting programs are included as they can serve a valuable place in working out and implementing complex algorithms. Both can be included in C programs. I also tend to leave a lot of leeway for alternate languages to be available even if I don't use them often or at all. For instance I have never and may never use Java but I have some tools to make it available in case I do decide to use it.

Another big thing in my book is ample documentation. It can take up a lot of additional space but I think it's well worth it. Especially for libraries and programs I'm not familiar with. I generally install elinks and dhelp to help organize the documentation that I have on the system. I may also install the docs for programs or libraries that I don't yet have installed to see if they would be a good match.

A complete list of packages installed on my test system would be extensive and far too long for this article. I install quite a bit of source code to reference as well. To me analyzing the way somebody else solves a problem can help me through a slump.

Now for a small section on navigating the command line is your not used to it. I will assume that you're familiar with the basic commands such as; ls, pwd, ps, cp, rm, etc.

There are two ways that I handle using multiple apps at one time. The first is to Ctl-z to put an application to sleep and then '%$app' where $app is the application put to sleep, to bring it back up. The second is to run multiple virtual terminals at a time to allow for rapid switching between active programs without having to put one in the background. I often due this to reference documentation while using a new program or library. Ctl-Alt-F* where * is 1 - 8 allow you to switch between virtual terminals. On a cautionary note I have found that some window managers don't like it if you switch out of them using this method. At least on my laptop, they would refuse to resume properly forcing me to restart x from the command line. So be prepared.

Install and activate laptop-mode-tools. There is no readily available battery monitor on the command line by default. Having your battery run out at a crucial time can be devastating (See Part 1 of this How to). With no way to perform a rescue boot except over the network you really don't want to cause problems for your filesystem. Fixing it can and will be a pain though not terribly difficult if you know what you're doing.

Never underestimate the awesome power of grep for finding what you need. A simple ls -a | grep $string where $string is what your looking for can work wonders. Try not to leave the string too vague though or it won't help much. I also tend to avoid using the -R (recursive) function of ls as it can give me too many useless results.

So there you have it. Some basic setup to get you going. In the next part we'll take a look at choosing a window manager or desktop to suit this machine's needs and all the problems that come with it.

How to Turn an Older Tablet Notebook Into a Functional Machine: Part 1 Initial Boot and Installation

The laptop used for this testing is one fickle beast. Most of these techniques should work on any given system that may be causing you problems but, fair warning, some issues are hardware specific and will need to be tweaked, mostly in minor ways.

The laptop used is a Toshiba Portege M205-s810 with 512MB DDR133 RAM, a 1.5Ghz Intel M CPU and a 60GB hard drive. The system is four years old, has no optical or floppy drive, a broken bios that makes booting from USB next to impossible and no installed operating system (courtesy a series of terrible mistakes I made some time ago, long story but more on that some other time).

The first step was choosing a distribution. I initially wanted to go with Debian as this is the system that I'm most familiar with. Almost every distro that runs in my house is Debian based, the one exception being a Compaq Presario 8600 from 1996 with 24MB of RAM that uses a Slackware based system. After perusing through the Debian web site and various tutorials while I got my bearing I decided that Debian would not be a good match for the system I wanted to build. The reason was a simple one. Before this little experiment I had never so much as attempted to install an OS over the network and I wanted to keep things as simple as possible. OpenSuse would have been a viable option if not for hardware detection issues due to the tablet element of this PC. All said and done I chose Ubuntu to use as the base system. You can get a pre-made package for installing Ubuntu over the network from the official website. (NOTE: Network installations are broken under Hardy so Gutsy must be used for the time being)

Now it came time for the network boot process. There is a handy guide to doing this on the Ubuntu support site. Two guides actually. The caveat here is that not every process is going to work for your setup or your system. The quick guide offered by the official site recommended temporarily shutting down the firewall. Something I would advise against under most circumstances.

This step of the process occupied more of my time then anything else. The endless tweaking of config files, trying a variety of tftp daemons and carefully building firewall rules to cooperate with the installation was maddening. All said and done I spent over 18 hours total working these issues out. It didn't help that my home network is built to be as secure as possible and I didn't spend much time ensuring that adding machines temporarily for this sort of thing would be easy went I set everything up. The lesson here is to think long and hard about the choices you make when building a home network. You may want to spend the extra time to build the scripts necessary to make such changes as painless as possible instead of dealing with it later.

Of course to do this you're going to need a server. As it's only a tftp transfer almost any old server will do so long as it has an NIC and the right tools installed. The tools I used to make this work were dnsmasq and atftp, both of which and be found in the Ubuntu repositories and installed with a simple apt-get from the command line.

The alternate method to how I performed the install requires an ftp or http server as well and a slightly more capable machine as it will need to serve the install program the rest of the files it needs. Again in the name of keeping things simple I chose to perform the install over the internet and cut out that process.

I'm not going to go into detail on making the network boot work because very comprehensive instructions can already be found on the Ubuntu support website. I see no need to repeat them here. I will just say that you need to make sure your firewall rules are properly handled or your in for a world of hurt. I would advise assigning the rules regarding this process by mac address rather then ip for security reasons.

Now, assuming you've succeeded in getting the laptop to boot from your server you should be staring at an installation screen. This is where the first major configuration choices came into play for me. As this laptop was destined to provide a mobile development work station, I did not want it bogged down with a heavy desktop like Gnome or KDE. I even passed on using XFCE as I decided that it was still too memory and space intensive for my liking. Removing the default desktop Gnome after installation is easy but bothersome. Skip this unnecessary hassle and type:

# cli

(where # is the prompt) at the installation prompt to install a command line only system. This will save a good amount of space by not installing Gnome and all it's bloat and simplify the later process of customizing your distribution to your needs and wants. (In all fairness to the good people of the Gnome development team, I use it as my primary desktop on all but two computers I own. It has it's place and my wife and I both love it. Just not on computers that I need to be as fast as possible with limited resources to that end)

Other options are available at this command line including a rescue mode and a shell. If you plan on using your wireless network and have WEP or WPA enabled you will need to enter the shell and load the appropriate modules for 802.11x support. The modules do not come included with the network installation package but can either be added before hand or introduced via USB drive now that the computer will actually read it. I'll admit that rather then go through this ordeal I stuck to installing via Ethernet but at some point I will attempt to do a wireless install and get back to ya'll on how that goes.

The install is mostly automated but several steps can be manipulated by hand if you so choose. It will make an attempt at auto configuring your network connection via DHCP or allow you to enter the information manually. If you attempt a wireless install at this point it will inform you that WEP/WPA support is not enabled. It will work if you turn off encryption on your network but I would advise against that for obvious reasons.

NOTE: I know it sounds stupid but make sure that any removable media is removed before starting the installation process. On my first go around I forgot to remove my USB stick and wound up with GRUB thinking that my USB drive should be the hd0. Not hard to fix but a royal pain. Sometimes it's the simple things that get you.

The installation averaged around 20 minutes to complete on my network and hardware. Yes I said averaged. To ensure that my setup was sound and not just some fluke I attempted and completed the installation a total of five times and also successfully performed one rescue boot. (The rescue boot was not part of the test. I had a kernel oops and a corrupt file system when the four year old battery in my laptop decided to die without warning during package installations)

Once the system reboots you will have a functional command line only Ubuntu system on which to build. Part 2 will talk about setting up wireless and choosing come applications as well as some basic cli tricks that save me a ton of time during set up of fresh systems.

LINKS (In case you missed them in the article)
www.ubuntu.com - The Official Ubuntu Website
https://help.ubuntu.com/community/Installation/Netboot - Network Install Tutorial 1
https://help.ubuntu.com/community/Installation/QuickNetboot - Network Install Tutorial 2

Using Root in Ubuntu

Ubuntu is a great operating system for new comers to Linux. However, many advanced Linux users find it lacking. Still Ubuntu makes a great platform for adapting to the Linux ways and learning some more advanced features.

One of the problems that I ran into quite frequently as a new Ubuntu user was logging into root. You see Ubuntu has no root account as a security measure. Instead everything for admin is done via the command sudo.

The problem with this is that all commands will function properly usung sudo. For instance if you type:

$>sudo cd /etc/sbin

in an attempt to open the sbin folder as a super user you will receive the following error message

$>/bin/sbin 'cd' unknown command

This is because there is no sbin command for cd and sudo calls sbin commands. This can be remedied by typing

$>sudo su -l root

This will log you in as root for that terminal session using your sudo password. This will enable you to access folders and files as root that may not normally work with a simple sudo command. When your done make sure you type

#>exit

To log out of the root user mode.

And there you have it! A nice easy work around to one of the limitations of the Ubuntu system. Note that this will only work on a user account listed as a sudoer. An account without admin access will be unable to sudo at all let alone open a root shell session.