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.