[Fri Dec 30 17:20:37 CST 2011]

As I mentioned earlier, I recently helped my oldest son install Debian Squeeze on an old Dell Latitude D610 laptop. Before starting the actual installation, we had to decide about the overall disk layout. So, back to making a decisin about where to locate the swap partition (among other things, of course) and reading the SwapFaq document from the Ubuntu documentation website (which, by the way, doesn't truly tell you where to locate the partition on the disk). However, this other entry from LinuxQuestions.org certainly hit the nail on the head:

Where to place your swap partition depends in the first place on how many disks
you have.

The most important thing you have to bear in mind is that the harddisks have to
move the heads and this costs time.

The plates (there more than one to conform what we know as a 'hard disk') spin
faster on the border as in the middle. But having only one disk the key
bottleneck is not this speed difference but the time lost in moving the heads
form one part of the disk to the other. What we need to search is a way to
minimize head movement placing the swap partition in a proper place.

If we have two or more disks the obvious place are the first sectors of the
disk taking also advantage of paralelization, so one head on one disk can
always be there writing into the swap while the other on the other disk is
reading or writing somewhere else.

But this advantages disappear if we only have one disk. then the approach is
radically different: With a single disk we need to minimize the travel time of
the heads as much as we can. And we can achieve this using the middle of the HD
as a swap partiion. This way there will always be a header near and the time
spent for a head coming from either the border or the center is only half as
much as if you place it at the beginning or the end.

Placing a swap aprtition at the end of a disk is always a bad idea as you won't
get the advantage of the reduced travel time of the heads and you will also get
an extra penalty in speed and block density.

So the thumbrule is:

o One HD swap in the middle
o Multiple Hardisks swap in the first sectors


This can improve the speed of disk transaction on systems which makes a heavy
use of swapping; old systems with less than 64MB of (slow)RAM... In more or
less modern systems swap space is almost a relic from the past which we use
more as a tradition. So on one of my machines (Duron 1.3 GHz, 758RAM DDR 333,
2xSeagate ATA100 40GB HD's) I never have used more than a 1%-4% of my 0.5GB of
swap space. As you see there not much use in faster disk access when we aren't
indeed using this space at all.

So if you have plenty of RAM (this means more than 128MB) using an alternative
solution could be the right solution. This alternative is to use the dynamic
swapping daemon instead of a fixed swap partion, the swapd. This daemon takes
care of using the part of the disk which fits best to it's needs to place
temprorary swap files, so you don't have to bother about where to place them.
Drawback is that you have to recompile the kernel.

So, swap partitions make only sense in old low-ram systems and in laptops where
the swap partition is used as susend-to-disk storage.

Chapeau! {link to this entry}

[Fri Dec 30 17:17:28 CST 2011]

I came across an interesting article on the deprecated Linux networking commands and their replacements. I, for one, was not even aware they were being deprecated. Not only that but, to be quite honest, my first impression was that the new ip command that will replace ifconfig is actually a step back. I'm afraid that, as long as I can, I will continue using the old commands. Sorry. {link to this entry}

[Fri Dec 30 17:05:25 CST 2011]

I just helped my oldest son install Debian Squeeze on a Dell Latitude D610 and everything seemed to work fine until we made it to the part where the installer was supposed to write GRUB to the MBR. At that point, it bombed out on us? What happened? Easy. We were installing from a USB thumb drive which was seen by the kernel upon boot as the /dev/sda device. When it reached the point where it was supposed to write GRUB to the MBR, it failed. But that is not all. There was an option to continue installing the OS without writing GRUB to the MBR. However, once we rebooted the laptop, it would just stay at the GRUB prompt (most likely from a previous install). It didn't know what to do. The solution? I had to boot from the USB thumb drive once again, select rescue mode and then, at the root shell prompt, run:

# grub-update

# grub-install /dev/sda

That seemed to take care of things. The laptop booted into multiuser mode just fine. {link to this entry}

[Thu Dec 29 11:41:46 CST 2011]

An email from Ben Hutchings sent to the debian-release mailing list provides a good window to illustrate how the whole kernel development process is based on such a collaborative effort that even the decision of what kernel version a given distro will run depends on a team effort that goes beyond the limits of a particular company or project:

Given a freeze in June 2012, we will have a choice between these Linux
releases (with estimated dates):

3.2 (December 2011)
3.3 (March 2012)
3.4 (May/June 2012)

Some other distributions with long-term support will be using:

Oracle Linux 6:   2.6.32+ (RHEL-compatible), 2.6.39 (UEK)
RHEL 6:           2.6.32+
SLE11 SP2:        3.0
Ubuntu 12.04 LTS: 3.2

Mandriva and Slackware are supposed to have long-term support; should we
try to find out what they're doing?

Greg K-H will be supporting 3.0 and I believe there will also be a
3.0-rt longterm series.  However, this was far too early a release to
use in wheezy.

If we go with 3.2 then we can work with Ubuntu and someone from either
kernel team can run a longterm update series (Greg is happy for people
do this using much of the same kernel.org infrastructure).  But it's
still going to be a year or so old by the time we release (no worse than
for squeeze, but no better).

If we go with 3.3 or 3.4 then we can release with more features and have
less backporting work to do.  But we are also likely to get far less
help with bug fixing (including regression testing).  It is possible
that SUSE could use 3.4 for the next SLE service pack, but I doubt we
would know that until some time after our freeze date.

Ben.

The key, to me, is the comment about how choosing a newer kernel will mean that the new Debian release will have more features but, on the other hand, their developers will not have so much help to debug problems that users may run into. On the other hand, if they choose an older release, it will be easier to find that help. Or, as I said above, clear evidence that, no matter how much competition we think there is among the different Linux vendors and distros, they still work with each other most of the time in order to sort things out, to the point that they take this into account when making a decision about the software versions they will be bundling. {link to this entry}

[Wed Dec 28 16:19:35 CST 2011]

Well, there is finally a Spotify client for Linux. It installed fine on my laptop running Debian Squeeze. This is what I had to do. First of all, I edited the /etc/apt/sources.list file to add the following line:

deb http://repository.spotify.com stable non-free

Once I had that in place, I just had to run the following commands as root:

# apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 4E9CFF4E

# apt-get update

# apt-get install spotify-client-qt

That's it! You will now find the application under the Sound & Video category in the applications menu. Here is a screenshot:

It runs pretty well, although it is quite obvious that the menus and overall looks are not native. In that sense, it feels "weird". However, Linux users are quite used to that by now. {link to this entry}

[Fri Dec 23 11:55:41 CST 2011]

I have been running Firefox 9 for the last couple of days, and I do like what I see. These guys have been improving the overall quality of the browser in the last few releases. Here is their promotional video, which could perfectly apply to other open source projects, of course. Many thanks to the folks who work at the Mozilla Foundations and everyone who volunteers their work to put together such an awesome browser.

{link to this entry}

[Wed Dec 21 11:02:16 CST 2011]

I am glad to read that the Mozilla Foundation has announced today the release of Firefox 9, as well as the renewal of the deal with Google to continue financing its efforts. Needless to say, it is the latter issue that had me worried about the future of the main open source browser. Since Chrome is becoming so popular, it wouldn't have surprised me to see Google ending the deal to support the Mozilla Foundation, therefore leading them pretty much to extinction. So, it is nice to see that Google continues sticking to its "do no evil" principles, at least for the time being. {link to this entry}

[Wed Dec 21 10:37:24 CST 2011]

Canonical announced a few days ago that it will stop hosting the Sun Java JDK on their repos:

The Canonical partner archive currently contains Oracle's Sun Java JDK
packages (sun-java6) for Ubuntu 10.04 LTS, Ubuntu 10.10 and Ubuntu 11.04.

As of August 24th 2011, we no longer have permission to redistribute new
Java packages as Oracle has retired the "Operating System Distributor
License for Java" [1][2].

Oracle has published an advisory about security issues in the version of
Java we currently have in the partner archive [3]. Some of these issues are
currently being exploited in the wild.

Due to the severity of the security risk, Canonical is immediately
releasing a security update for the Sun JDK browser plugin which will
disable the plugin on all machines. This will mitigate users' risk from
malicious websites exploiting the vulnerable version of the Sun JDK.

In the near future (exact date TBD), Canonical will remove all Sun JDK
packages from the Partner archive. This will be accomplished by pushing
empty packages to the archive, so that the Sun JDK will be removed from all
users machines when they do a software update. Users of these packages who
have not migrated to an alternative solution will experience failures after
the package updates have removed Oracle Java from the system.

If you are currently using the Oracle Java packages from the partner
archive, you have two options:

1- Install the OpenJDK packages that are provided in the main Ubuntu
   archive. (icedtea6-plugin for the browser plugin, openjdk-6-jdk or
   openjdk-6-jre for the virtual machine)
2- Manually install Oracle's Java software from their web site [4].

For more information, please consult the wiki page on the subject [5].

We apologize for any inconvenience this may cause, and thank you for your
understanding.

[1] - http://jdk-distros.java.net/
[2] - http://robilad.livejournal.com/90792.html
[3] - http://www.oracle.com/technetwork/topics/security/javacpuoct2011-443431.html
[4] - http://www.oracle.com/technetwork/java/javase/downloads/index.html
[5] - https://wiki.ubuntu.com/LucidLynx/ReleaseNotes/Java6Transition

Once again, it becomes clear that being picky about licensing issues is not as meaningless as some people may think, in spite of all their jokes about Richard Stallman and the Debian project, for example. {link to this entry}

[Wed Dec 7 13:35:01 CST 2011]

I spent a good amount of time this morning trying to get VNC to work on a RHEL system. Apparently, Red Hat is now using a package called TigerVNC for this purpose. Here is a good explanation of how to install and configure things, although in my case I had to make some small changes. I just needed to connect to the RHEL system remotely in order to test a problem with Virtual Box in a perfectly secure environment, so using the root account was good enough for me. Here is a quick list of the steps I had to follow:

# yum install tigervnc-server* -y

# chkconfig vncserver on

# vncpasswd
password: ********
retype password: ********

# vim /etc/sysconfig/vncservers

VNCSERVERS="2:root"
VNCSERVERARGS[2]="-geometry 800x600"

:wq!

# service vncserver start

Notice that I chose to remove the -nolisten tcp -localhost options for the $VNCSERVERARGS, which is insecure. As I mentioned above, I was doing all this in a secure environment. It would not work without that in my case, although you should look into the -via option to the vncviewer command if you plan to use this in production. {link to this entry}

[Tue Dec 6 16:59:15 CST 2011]

Uh-oh. I just read that the deal between the Firefox Foundation and Google that provided US $100 million to the foundation in exchange for using the Google search engine as the default in their browsers ended in November. Apparently, it has not been renewed since. After all, now that Google Chrome has become so popular, why would they even bother to pay? So, who cares? Well, the problem I see is that Chrome is not open source, as far as I know. In other words, we may be quickly moving towards a situation where Microsoft's Internet Explorer and Chrome pretty much have all the market to themselves and neither is open source. I don't know about you, but I don't like it, which is why I keep sticking to Firefox no matter what. {link to this entry}

[Thu Dec 1 18:05:32 CST 2011]

Difficult as it may be to believe, I had not realized until now that both Ubuntu and Debian come by default with the dash shell, instead of bash. According to the entry in Wikipedia:

Dash is a direct descendant of the NetBSD version of the Almquist shell (ash). It was ported to Linux by Herbert Xu in early 1997. It was renamed to dash in 2002.

(...)

Dash is a modern replacement for ash in Debian and was expected to be the default /bin/sh for Debian Lenny. Dash has been the default /bin/sh in Ubuntu since the 6.10 release in October 2006. During the transition by Ubuntu, numerous scripts making use of Bash-scpeific functionality (but not declaring it) were discovered. To avoid errors, Bash-specific scripts can be modified to be compatible with the appropriate standard, or explictly declare their use of bashisms by explictly setting the interpreter to bash via the shebang line: #!/usr/bin/env bash

Like I said, I had not even noticed. Sure, I knew that bash was not there by default and it was the first thing I always installed from the repos right after installing a Debian or Ubuntu system from scratch, but I had not bothered to see what they had replaced it with by default. I just assumed it would be an old plain shell of sorts. {link to this entry}