Sunday, October 5, 2008

Reasons _Not_ to Use Linux?

Perhaps the best blog post I have ever seen on reasons _not_ to use Linux. Funny and dementedly true. Find it at Original Content on tuxmachines.org or click this handy link.

http://www.tuxmachines.org/node/30354

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.

Saturday, October 4, 2008

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.

Thursday, October 2, 2008

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.

Saturday, September 13, 2008

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.

Thursday, September 11, 2008

Inroducing BrowserBox WM

The BrowserBox window manager project has now started. This aims to be a lightweight desktop environment with integrated net capabilities. Some of the planned features include:

- Desktop integration with Google Gadgets
- Desktop configurable with html, javascript, and ruby on rails
- Configuration tools for the desktop for those with less programming skills or none at all
- Desktop integration with the Gecko web browser engine

The basic idea behind it all is to allow for seamless integration between the world wide web and dynamic content on the desktop.

The project is based on the blackbox window manager and is currently in the planning stages and will being development shortly.

This project is currently looking for volunteers to help!
Positions available include:

- C++ Programmers: Must be competent with C++ and have some GUI design knowledge
- Perl Programmers: Must be able to write automated configuration scripts
- Web Designers: Must be able to work well with HTML or XHTML and Java
- Graphic Designers: To design default themes and logos

If you are interested in volunteering for the project please e-mail me at hpypenguin [at] users [dot] sourceforge [dot] net for more information or with details of your experience.

Wednesday, September 10, 2008

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.

Tuesday, September 9, 2008

Five Window Managers You Should Try

1.) FVWM - http://www.fvwm.org
A lightweight highly customizable window manager for the minimalist in all of us. It can be tweaked and turned into just about anything you want it to be. Although I found one of it's forks, FVWM-Crystal, to be more to my liking, there's no denying that this is the base that makes Crystal such a joy to use.

2.) IceWM - http://www.icewm.org
My personal favorite and the window manager that runs my infamous development oriented laptop from the recent How-tos. Easy to configure and easy to use. This manager is compliant enough with gnome (and even have an official gnome support version) that I was able to run a bunch of gnome apps and even the gnome menu bar within it without a hitch. Lightest memory footprint I've recorded occupying only 3.9% of my laptops 512MB RAM at the most. Anyone looking for sheer performance and a remarkably easy setup would do well to look at this. Check out the IceWM Configuration How-to on this site for tips if you need help.

3.) Enlightenment - http://www.enlightenment.org
I didn't like it but what do I know. One of the more popular lightweight environments availible. While I had a multitude of problems with it sheer number of users alone justifies at least taking a look. It's a real hit and miss on this one. You either love it or hate it. I will say that it can be made to look exceptionally nice when the effort is put in.

4.) Fluxbox - http://fluxbox.sourceforge.net
The ultimate in simplicity. Designed to be as usable as possible, any sort of attractiveness seems to be an after thought. Which as far as I'm concerned is a good thing. When testing this window manager I was pleased with the results but I suffered from extreme configuration issues. My laptop wouldn't do much with it even after fetching the latest version off the website. I'm still not entirely sure what the problem was. So I had to run it on one of my testing desktops. As a result the test results are somewhat tough to analyze as that desktop has far more processing power then my laptop does. Suffice to say it was pleasant enough and I'm confident that when and if I work those issues out that it will run well on the laptop too.

5.) Wm2 - http://www.all-day-breakfast.com/wm2/
If all you really want is frames around your X programs, that's about all you're gonna find here. That is it's one and only selling point. There's a narrow niche for this window manager but a real one. If you hate extras of any kind this is the one for you.

There you have it. If you think I left one or two off let me know!

Until then.

Sunday, September 7, 2008

Configuring IceWM: Basics

When I started using IceWM I found little in the way of straight forward tutorials for configuring it. The documentation available from the website is suitable for most cases but certainly lacking in some regards. So I'm going to present some tips on configuring this handy window manager as easily as possible.

First things first. I would recommend against using IceConf. This program is a gui that gives you some options and will automatically generate config files for you. I advise against it because the options it lists are not comprehensive, not very well explained and the files it generates may leave off certain features enabled by default that you may wish to keep but not know how to implement yourself. Foremost of which is the right-click menu. This menu goes away after using IceConf and when I started tweaking and configuring my window manager I didn't know how to get it back. Nor was the preferences file generated by the program commented well enough to let me know what I needed to change to fix it.

Now that that's out of the way let's get started. These directions are for Debian based systems and file paths as well as some commands may be different on other distributions. First make a new directory in your home folder called '.icewm'. Now copy the contents of '/usr/share/icewm/' into the new directory '.icewm'. These are the default config files for the window manager. Editing the ones in your home folder not only means that you will have backups and that on a multi-user station you won't be messing with other people's settings. At some point you may want to add a file called 'startup' but we'll get to that later.

The first file you probably want to edit is called 'preferences'. It can be easily modified using your favorite text editor by simply uncommenting and/or changing the boolean operator of a given function. The file is well commented and functions are well explained in most cases. If you don't know and can't figure out what something does you have two choices. To be on the safe side don't touch it and assume it doesn't matter much anyways or if your willing to take a bit of a risk mess with it and see what happens. I strongly encourage the latter. After all you can always change it back and you have backups handy just in case, may as well have some fun. Besides almost all of the options in the file have to do with things like color, size and style. It's doubtful that you're going to break anything by changing these values.

The next file is called 'keys'. This allows you to change the key bindings within the environment. Again it's pretty self explanatory. Modifiers available include Alt, Ctrl, Shift, Meta, Super, and Hyper. To add a key binding on a new line type

key "$key1+$key2+key3.." $command

where $key(n) are the keys to use for the bindings and $command is the command with options to execute. The keys to use must be surrounded by double quotes. The command should not be quoted. I find this to be the most useful section to configure. Since I have IceWM on a laptop and the mouse is awful this allows me to bypass using it completely if I so choose (and I do, because I hate the built in mouse on laptops, all of them)

The last file you're most likely going to want to edit is called 'menu'. This file controls what is displayed in your start menu. This is also pretty darn easy to edit. Notice a theme here? It's really quite simple to make tons of changes. To add a program to the menu find the section you would like it to go under and on a new line but staying inside the {} brackets type:

prog "$Name" $Icon $Command

where $Name is the name you would like to appear in the menu, $Icon is the path to the icon to be used (or in in lieu of using an icon type '-' without the quotes of course) and $Command is the command with options to execute. To add a menu or sub menu type:

menu "$Name" folder {
$prog1 line
$prog2 line
....
$prog(n) line
}

where $Name is the name of the menu and $prog(1, 2, n) are the lines for the programs you would like to appear in that menu as described above. Menus can be nested inside other menus too. Anything that appears within the {} brackets of a menu will appear under that menu and that goes for separate menus as well. Here's an example taken from my menu file:

menu "Development" folder {
menu "Math and Science" folder {
prog "Octave" octave octave-2.9.12
prog "Maxima" maxima maxima
prog "R" R R
prog "SciLab" scilab scilab
}
menu "IDEs" folder {
prog "Geany" geany geany
prog "Eclipse" eclipse eclipse
}
menu "Help and Documentation" folder {
prog "DHelp" dhelp dhelp
prog "DWWW" dwww dwww
}
}

If you can't tell from the example this creates a menu called 'Development' that then has three submenus; 'Math and Science', 'IDEs' and 'Help and Documentation'. The quotes around the names of the programs and menus are not strictly necessary unless there is a space in the name. They are included for consistency.

The last file I'm going to cover here is called 'toolbar'. It is edited in the exact same way as the 'menu'. The difference here is that changes applied to this file appear on the toolbar itself rather than in the menu.

Well that wraps it up for today. At some point I'll cover some more advanced configuration methods for IceWM including using the startup file and building themes. 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.


Saturday, September 6, 2008

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


Sunday, August 31, 2008

Windows v Linux: Part 2

This post removed due to a decision that the content did not fit with how this site aims to present itself. The link will remain for archival reasons. Thank you.

Tuesday, August 12, 2008

Windows v Linux

"Also, the kindred trends of Web 2.0 and cloud computing -- which rely more on Internet-connected services than powerful operating systems -- are making Windows less important than it used to be."

Somebody needs to explain this to me. Taken from a Yahoo Business article, the author it seems it hardly up to speed on software technology.

What I mean by that is the reference to Windows as a more powerful operating system then Linux. When did that happen? If the power of an OS is interpreted as it's ability to run the most pay-to-use software well then yes I suppose then Windows would win. Even that gap is closing, however, as software like WINE makes it easier then ever to get Windows based software to run under Linux. Actually in one interesting example. A game I own, Elder Scrolls III, would not run under Windows XP no matter how many tweaks and changes I made but ran fine right after install in Linux using WINE.

Back to the point. There is nothing I can think of to say that Linux is underpowered compared to Redmon's offerings. Linux is more stable, more secure and more adaptable then Windows has ever been or may ever be.

I can tweak my favorite distro and get it to run on an old Compaq that has only 24MBs RAM and Pentium II. Show me a way to do that with Vista.

I can aquire every piece of software I need to make any of my machines peform there intended functions effiecently for free. Distributions are chosen based on the needs of the machine or a fresh kernel is compiled. Software is a sudo apt-get install away. A little time and that spare box I had lying around became a local DHCP and FTP server. For no additional cost. To avoid 'piracy' with Vista (or XP for that matter) would have required purchasing another license. Then the software from whatever vendor to run it.

I can easily run any intense number crunching task under Linux. If you want to talk raw power just look at some of the benchmarks availible comparing Linux and Vista. Without all the bloat that is Windows all of the programs I've tested run faster on a Linux box specced the same.

I have far less fear running a Linux box online as well. Of course I understand net secuirty and keep my iptables up to date and an anti-virus daemon running via clamav, but I do all of these things for the one remaining Windows computer in the house as well and that one picks up over 100 instances of spyware and viruses a month. This may be partially due to the user of that machine, but still. My Linux computers have all together been infected... zero times. (And I have nine of them)

So explain to me please, how Windows is the more 'powerful' operating system. I can do more better, faster, easier, and cheaper with Linux and it wasn't even that hard to learn.

Friday, August 8, 2008

First Impressions: PC-BSD

To make sure that I was getting a solid look at the whole Unix like community and not just Linux I decided to install PC-BSD on my test machine and give it a spin. I chose PC-BSD because it seems like the best distribution to use as an introduction to BSD. The website touts simplicity for the end user and an easy to use graphical install.

Windows users will feel right at home using PC-BSD. After all it took far more work then it should have and a risky maneuver to get it to dual boot with Linux. It was clunky and slow within the desktop. And it assumed that the end user on the machine was a complete idiot to the point that on typing a sudo command A message came up before the password prompt that basically suggested that I should be briefed by my sysadmin before sudoing. Not to mention the fact that even though only one user was set up aside from root it was not an admin account by default.

The installation was simple enough. I have to give it credit for being the fastest and most painless install I've seen that wasn't a mini-distro. I didn't test the partitioning system for fear of destruction so I had made a partition earlier in gparted. Per the official install guide I did not install the boot loader as the guide suggested that doing so would over write my MBR and therefore grub. Installation all said and done I jumped into the menu.lst of grub and added the appropriate entry. A quick restart and I was to be on my way.

Except not. It wouldn't boot. At all. After hours of manipulating the grub entry and scouring the web looking for help I decided it was time to attempt another installation. I wiped the partition and tried it again. This time at the prompt I installed the boot loader. I consider this to be a somewhat risky maneuver as it could have left me without grub on my MBR, leading to much pain and suffering later trying to get it back. I read several forum posts where this had happened just that way to users trying to dual boot Linux and PC-BSD.

Well as luck would have it it worked. I was finally able to boot into my new OS. Upon boot I was eventually greeted with the familiar desktop of KDE 3.5.9. I chose a slightly older version of PC-BSD as the new one, version 7, comes with KDE 4.1. I don't know what it is about the new 4.x series of KDE but I have managed to crash it dozens of times doing such benign things as opening the file manager so I have utterly rejected using it.

The first problem I noted with this OS was that it used KDE. This in itself is not a problem except that KDE is not my preferred desktop. I'll generally use XFCE and in some cases Gnome. Lo and behold according to the official PC-BSD documentation a substantial amount of Gnome based software is unsupported in PC-BSD and may not run at all.

I consider this to be a serious drawback because it has taken away an element of freedom in what I want to run on my system.

Another obvious play to Window's users is the installation method preferred by PC-BSD. It's called PBI. You download a PBI file and then run it as an executable. It then automatically installs the software for you. If your coming to PC-BSD from Windows this should be great. I guess. As a Linux user I don't really understand the point in making it take longer to install a program I want to use. If I want to install emacs for instance, I'll have to find it online in the PC-BSD directory, wait for it to download, and then run the file. In Linux I would just pop open a virtual terminal and run sudo apt-get install emacs and then go back to whatever I was doing while I waited for it to finish. There is nothing streamlined about having to monitor the download progress of an app and then find and execute it's file to get it going.

Of course the OS does allow for the more traditional means of installation. You can use packages and ports to install instead. Installing from packages seemed like a bit much as well under these circumstances as there is no included package manager. While many advanced users will feel perfectly at home without one it's something that I generally like to have and I know many others do too. For instance when I first set up a new computer I'll open up synaptic select everything I know I'm going to need or want and then let it go for a few hours. Initial installs on some of the computers I've worked on have required over 1,200 packages. I wouldn't want to do that without the help of a package manager and I certainly wouldn't want to do that with PBIs.

The ports system was far more friendly then either of the other two. You download the ports directory and are then given a nice organized place to browse and install applications using the make install clean command from the terminal. The only real problem I found here was that it was rather slow and again lacked an easy way to organize the ports that you wanted to install or that had already been installed.

A lot of the complaints regarding installation methods may seem absurd to the advanced user but for someone who wants more power but still lacks some of the more technical skills these faults are devastating. There is no clear middle ground in this OS between the novice and the expert.

Having installed a few packages to get things rolling I took it for a spin. I installed the first apps I install on any OS I'm going to tinker with. Emacs and Nethack. The former being my preferred editor for extensive configuration work and the latter being the way I take breaks when I get to the point of preparing to use my machine as a projectile for my home made catapult.

I started tinkering around. Nethack came around quickly. Be it due to how utterly foreign parts of the system seemed compared to the Linux I've come to know and love or because of how utterly inept of a system PC-BSD seems to be, I never finished configuring the system. It was driving me insane.

Final call?

The guys over at the PC-BSD development team don't seem to know who they're targeting with this distro. The complications that came from attempting a dual-boot and the lack of effective documentation would make any Window's user think two or three times before risking there system to giving it a try. More advanced users who know that they can make it work will be left wondering why they bothered, My opinion? If you want BSD go for FreeBSD and skip the bull shit. You'll thank yourself.

Tuesday, August 5, 2008

Linux: Only for Advanced Users?

I was reading an article about the ease of use that is some of the Linux distributions on another blog. The author made some solid points about how modern distros will often take care of most of the setup work for you and still have less bloat and be more secure then Windows could ever hope to be. One of the things he noted was that some of the distros "install your drivers for you."

Needless to say the responses were mixed with many people highlighting that he may have over stated the simplicity of using a Linux system.

The comment that stood out fom me was rather mean spirited and reminded me one more time of the need to break the elitism of the Linux community. I paraphrase.

- Installs your drivers for you? You must be using Ubuntu or you've never been a system administrator. Try downloading the Debain source, bootstrap your computer and compiling it yourself. I bet you'll give up after six months because you can't get anything to work. -

I happen to think that this is the wrong sort of attitude to have. Yes the power of Linux can be best seen through kernel hacking and shell scripting and all that good stuff, but whose to say that other people can't get use of it as well?

When I migrated to Linux I didn't know the first thing about compiling source code let alone the kernel. I had no clue what gcc, binutils, bash, vi, or lisp were. I started with a distribution that was simple to install and simple to use. It remains the primary OS on my main computer so that my wife can use it without having any problems.

As I worked with Linux I started learning all kinds of things I could do with it. I read articles online and online books by the Free Software Foundation and the like. I started looking into Slackware and Linux from Scratch and reading up on kernel hacking and compiling from source. Now I have a computer dedicated to tinkering. Allowing me to freely experiment and find out just what kind of things can be done. I compile from source, I edit config files, and I spend hours at a time trying to find a way to fix whatever bug is preventing me from getting things done the way I want.

However, if Linux was that hard right off the bat I never would have used it. Not as a primary OS anyways. As fed up as I was with Windows there was no way in hell that I would have subjected my wife to months of tinkering and learning just to get things running.

The Linux community has to let people in. Even if all they ever do is run Mandravia or Ubuntu or Fedora and they never even learn what bash is or how to use it, they are contributing to the community just by choosing to use Linux over any other operating system.

My wife will never compile a kernel. I know that for certain. She's only interested in playing games, surfing the web, and writing papers and resumes with our main computer. Then again, she'll never go back to using Windows either. That I think, is what really matters.

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.

Welcome to Free as in Freedom

This blog is the tech only offshoot of Open Source Revolution, a blog about activism that also deals with computer activism such as open source software. As I delved deeper and deeper into tech related articles I decided that they needed a blog of there own. I will no longer be publishing on Open Source Revolution, but Another Angry Veteran will keep up the articles there on non-tech oriented activism.

Now I use Linux, Ubuntu 8.04 actually, so many of the articles here will be strictly Linux oriented. However, I also use variants of FreeBSD and other distributions of Linux as well as some self compiled versions. So expect to find some articles on those topics as well.

My primary focus here will be on technical articles. How-tos, FAQs, links to documentation, tips and tricks, etc. but there will also be reviews and rants as what tech blog would go without those. If you are intrested in writing for the blog or in providing assistantce in any other way you can let me know by commenting. All comments are moderated so this also serves as e-mail notification for me. If you want the comment to be directed to me only and not published just say so in the comment and I won't put it up, just read it.

By tomorrow there should be an article about Ubuntu to start things off. At some point there will be a comic as well but they may take some time as I also do the comic for Another Angry Veteran.

Enjoy