Blog Day!

Blog Day is supposed to be a day to introduce you to other blogs you may not have heard of before. Perhaps you have heard of these, perhaps not – I’ll try to stick to ones that are in different subject areas and are perhaps lesser known. Here are some that I’m reading:

More about Blog Day is here.

Is FreeBSD a better choice for the desktop? (or dispelling myths)

It’s strange I should come across this article in one of my favorite blogs just after I switched from my FreeBSD desktop to Kubuntu. I’m also surprised at the lack of knowledge and the propagation of some long-standing myths about Linux and FreeBSD for that matter.

There are some ways that FreeBSD (or better put, BSD) is better than Linux – but the comparisons must be valid and appropriate without myths and falsehoods.

Perhaps the primary myth is that FreeBSD is a complete operating system and Linux is a boat-load of different distributions in all different flavors with different setups and so on. However, FreeBSD also has a large number of alternatives, including OpenBSD, NetBSD, PCBSD, DesktopBSD, PicoBSD, and Dragonfly BSD to name just a few.

Another comparison is that FreeBSD is put together by the FreeBSD Core team and that this is better than Linux (which has a “benevolent dictator” model). There’s no discussion of OpenBSD, for instance, which also follows this “benevolent dictator” model. There’s also no comparison to Red Hat Enterprise Linux, for example, which has a large number of people working towards putting together a complete distribution, not just the kernel.

The documentation is definitely an argument in favor of BSD – virtually everything that is in the system anywhere is documented in the online documentation, and the FreeBSD Handbook is without equal. It can be proven programmatically that there are commands in Red Hat (or other distributions) that are not documented. I daresay that the FreeBSD documentation beats other BSD variants as well.

Another benefit of FreeBSD specifically is the vast number of ports available. There are more ports for FreeBSD than any other system but Debian GNU/Linux. The sheer amount of packages available in both environments has made them appealing to me – and perhaps to others. Where else are you going to get Steel Bank Common Lisp for example? Both Debian and FreeBSD have it.

The article specifically asked about FreeBSD for the desktop: FreeBSD is definitely not ready for the desktop at all. When I installed it for my desktop (twice now), the basics are there certainly – but there were numerous problems that I had to overcome. Among them, I had to set up my own system bootsplash, and had to configure and set up my own login screen (kdm). USB devices plugged in weren’t properly recognized. Hibernation and sleep didn’t work. Flash doesn’t work. Unlike what has been said before, the drivers are much less available than they are for Linux: hardware manufacturers don’t see a need to support BSD, and many new UNIX users (and developers) don’t see a need to use anything but Linux. Wireless support is perhaps an exception, but that development is centered in OpenBSD, not FreeBSD.

There is also, in my mind, a benefit to BSD that goes often unmentioned: it has the smallest kernel of the open source UNIX and Linux kernels out there today. FreeBSD and OpenBSD will run in smaller environments that Linux won’t: on my 512M laptop, a Compaq Armada E500, Fedora 5 would crash during the install (not enough memory) – whereas the much more current FreeBSD 6.2 installed just fine.

Now, when I installed Kubuntu onto a Compaq nc4010 with 1G of memory, it went will – and it recognized everything – wireless, hibernate, bluetooth, USB devices, PCMCIA, video display, power capabilities, etc. – all without special configuration. (I might note that, here too, on this machine Fedora crashed – this time the Live USB Fedora 9 crashed during exit – sigh…) Preconfigured and tested support for Flash, Java, and MP3s was a click away.

When it comes to the desktop, FreeBSD has a long way to go (perhaps PCBSD is a lot better?). However, on the server end, I would propose that FreeBSD is a better way to go than Linux in many cases (except for OpenBSD might, in my opinion, be even better). It is unfortunate that none of the BSD variants are often considered for enterprise server use – especially considering FreeBSD is commonly found in NetCraft‘s list of top uptime.

Putting Linux on a Compaq nc4010

The HP/Compaq nc4010 is a business-class laptop with no CDROM, no DVD, and no floppy – but with network, modem, USB ports, SD slot, and PCMCIA slot. The system has a 1.7GHz Pentium M – snappier than a Pentium II for sure. It will also boot from the network with PXE or from the USB ports.

Booting this platform is the most difficult part. I didn’t try using PXE, because although I was once set up for PXE on my home network, I don’t have the distributions (Kubuntu and Fedora) set up for installing from PXE and it seemed like a bigger headache than try to make it boot through USB. USB booting is not (apparently) enabled by default; it requires setting USB to use Legacy in the BIOS settings – and in my case, it also required playing with the setting for Quickboot: I had turned it off, but upon re-enabling it the system booted from a USB key.

I tried using Fedora 9, but the Live USB version come up in a lower resolution and crashed upon exiting. I tried also Kubuntu Hardy (8.04.1) and it worked beautifully.

Loading Kubuntu was a breeze – and recognized all of the capabilities of the laptop (amazing!). USB works, network works (albeit with proprietary drivers), PCMCIA works – it just works. Even hibernate works (although suspend may not).

I’ve never quite liked Ubuntu, and I mostly chalked that up to its standard themes (brown and orange) and its use of Gnome and so on – never fully experiencing Ubuntu and always wanting to get a better feel for it. I’ve tried running Kubuntu (which uses KDE) before, but never as an “active” desktop.

Kubuntu made a believer out of me. Everything works in the laptop. Even MP3s, Adobe Flash, Java – it all installed cleanly (upon demand) and works out of the box. Installation was extremely simple. The available packages are quite extensive, and include Debian’s packages.

I attribute some of this ease of support (specifically, MP3 support, Flash, Java, proprietary drivers) to the fact that the company behind Ubuntu (Canonical) is not an American company, but a South African company – which has different laws. So they can make it easy to get proprietary “parts” that they could not sell or support otherwise.

I’m switching from my FreeBSD laptop to this one for the most part: this system is smaller, lighter, faster, and has more memory. It was good to build a FreeBSD desktop though – and took more doing than I thought. I wonder what PC-BSD would be like….. Hmm….

How to license your code (a plea)

A lot of software out there that admins use, perhaps especially security software, comes with a license – and often not a standard license like the GPL, the BSD license, the Artistic License, or the Mozilla License. In a corporate setting, each of these licenses should be vetted by the corporate legal department before we as admins can use the software.

The more different licenses there are, the more headaches there are for the admins that must get these licenses okayed by the legal department. Possibly the worst is creating one’s own license on the fly, instead of using a commonly used and accepted license.

There are a large number of already accepted licenses; if you use one of these for your software, then admins that want to use the software may find that the license has already been examined and approved. This makes it easier to get the software into corporations. It also means that all of the hard work that lawyers do to get the license crafted just so has already been done for you.

Here is a list of commonly used and accepted licenses:

The Open Source Initiative (or OSI) has a large list of open source licenses.

Why make it hard for software to be adopted for use in corporate environments when you don’t have to? Select a standard license.

How to change volume names in HP-UX (LVM)

Changing LVM logical volume names in HP-UX is extremely simple: enter into the appropriate volume group directory, and rename both the logical volume file (typically starting with lv) as well as the raw logical volume file (which normally begins with rlv). When both files are renamed appropriately, you are done.

Changing a volume group name is not as easy – not hard, just not as easy. First, you should vgexport the volume group (using the -m option to create a map):

# vgexport -m /opt/vg.map -s vgmine

This deletes the volume group completely from LVM records and from the /dev filesystem tree. It does not, however, change data on the disk – the logical volumes and associated filesystem data are preserved.

Having done this, recreate the volume group with the new name and use vgimport:

# mkdir /dev/vgnew
# mknod /dev/vgnew/group c 64 0x070000
# vgimport -m /opt/vg.map -s /dev/vgnew

This should then import the volume group, and give it the same logical volume names as before. Without the map, the logical volumes would still be present and accounted for and with all data preserved – but the names would be default names (lvol1, lvol2, etc.).

Working in a development environment

In a standard business environment, a production system is one that must be up and stable, and cannot be changed without a lot of forethought and a lot of getting people to coordinate and okay the process. A development system is one that the administrators use to prepare for bringing systems into production.

However, if your users are developers, then things may be different – especially if you are also using the software in a stable environment.

Development, by its nature, produces unstable code which is prone to crashes and other undesirable behavior. This stands the usual system administration goals on their head: your systems, though they are in “production” (that is, they are used by normal users on a daily basis) – these “production” systems behave like test systems in that they are not reliable. With reliability issues, it may seem as if they are not production systems – but they are.

What’s more, there may be actual “production” systems – systems with the same software which is not being developed, but being used. These systems then, are also systems that should not change (in production, we would say), but do not have reliability problems.

Even though the development environment may feel like a test lab at times, with systems going experiencing hangs and so forth, these systems still need to be treated like a normal production system. Never forget that your users, even though they seem to do “bad” things to the system, still rely on the system being there on a daily basis.

It also means that you will have to respond to problems faster, and be proactive in preventing problems – and that you will have more problems to resolve.

In short, the normal software development environment is more challenging to the admins that support this environment – but also more exciting.

Are You Ready for the Onslaught? (or Scaling Your Environment)

Is your environment ready for the onslaught that you may or may not be aware is coming your way?

One commonly known example of this is what is called “the Slashdot effect.” This is what happens when the popular site Slashdot (or others like it) links to a small site. The combined effect of thousands of people attempting to view the site all at once can bring it to its knees – or fill up the traffic quota in a hurry.

Other situations may be the introduction of a popular product (the introductions of the Iphone and of Halo 3 come to mind), or a popular conference (such as EAA‘s Airventure, which had some overloading problems).

Examine what happens each time a request is made. Does it result in multiple database queries? Then if there are x requests, and each results in y queries, there will be x*y database queries. This shows that as requests go up, database queries go up dramatically.

Or let’s say each request results in a login which may be held for 5 minutes. If you get x requests per second, then in 5 minutes you’ll have 300x connections if none drop. Do you have buffers and resources for this?

Check your kernel tunables, and run real world tests to see. Examine every aspect of the system in order to see what resources it will take. Check TCP buffers for networking connections, number of TTYs allowed, and anything else that you can think of. Go end to end, from client to server to back-end software and back.

Some of the choices in alleviating pressure would be using caching proxies, clusters, rewriting software, changing buffers, and others.

James Hamilton already has collected a wide number of articles about how the big guys have handled such scaling problems already (although focused on database response), including names such as Flickr, Twitter, Amazon, Technorati, Second Life, and others. Do go check his article out!