KainX.Org - Articles

Merging Traffic

KainX — Sun, 23 May 2010 17:06:00 +0100

Merging multiple lanes into a single lane is a challenge that seems overwhelming to many drivers on the road. There are simple, straightforward rules one can follow to maintain maximum efficiency and help alleviate slowdown and delays while causing minimal road rage and inconvenience to other drivers. It would seem that the average driver on the road today is unaware of these rules, so allow me to spell them out for you for the benefit of myself and the rest of the driving public.

Freeway On-Ramps

Sloped downhill whenever possible, the acceleration ramps are for exactly that — acceleration. The most dangerous person on an on-ramp is the moron who puts their turn signal on and slows down, apparently waiting for someone already on the highway to slow down and let them in. If the people already on the highway were supposed to slow down, they'd put up stoplights and make it an intersection. The whole point is for you to get up to proper highway speed on the ramp so that by the time you need to merge, nobody has to slow down for you.

If the ramp is short, and you have to floor it to get up to speed, do it. You are far more likely to cause an accident by merging too slowly than by speeding up quickly. If there's an asshole who won't move over and won't let you in, don't be afraid to use a little bit of the shoulder if needed to get ahead. Only slow down when absolutely necessary.

If the on-ramp happens to be part of a clover-leaf (meaning that the acceleration lane for you turns into a deceleration lane for people exiting, and then subsequently the exit ramp), and if you encounter exiting traffic, the situation must be handled carefully. Try to position your vehicle in between two exiting vehicles so that you can zipper (i.e., alternate). If the exiting vehicle is even with you or behind you, speed up; if they're in front of you, slow down, but speed up if they slow down. In general, you need to be speeding up and moving over, and they need to be slowing down and moving over.

Freeway Off-Ramps

Accidents and Construction Zones

Speed

KainX — Sun, 18 Apr 2010 16:10:00 +0100

Apart from some limited access highways, speed limits have been relatively unchanged for over 30 years now. The current speed limits were assigned before things like anti-lock brakes and traction control had even been heard of. Roads are safer and cars are safer, but our speed limits haven't kept up. Why is that?

Doggedly adhering to an obsolete set of laws is really no different from obeying those "weird/little-known" laws every state has: it just doesn't make sense. I guarantee you there aren't too many Texans abiding by the "take no more than three sips of beer at a time while standing" law, or people in Alabama consciously abstaining from games of Dominoes on Sundays. Silly, obsolete laws should be neither adhered to nor enforced. Unfortunately, the law enforcement community hasn't figured this simple fact out yet.

So how fast should you drive? That depends on the location and conditions. Rule #1 is to keep pace with traffic when you're driving in traffic. If you're doing 55 in a 55 zone while everyone else is doing 80, you're far more likely to cause an accident than if you were doing 80 too. If there's no traffic around, 10-15mph over the posted speed limit is pretty reasonable, up to a limit of 85 (unless you're on a really long, really straight, really level section of highway). Most street vehicles start becoming unstable around 85mph in the presence of wind, turns, etc.

In residential areas, 35-40 is safe for wider streets while 25 is good for the narrower ones. On curves that have yellow speed advisory signs, doing more than 5-10mph above that number requires a car with very good cornering and good tires. If it's raining, stick to the speed limit or slightly below in curves and only slightly above on other roads; if some other driver does something stupid (which they often do), you'll need the extra room to stop.

In the case of snow, all bets are off. Regular powder snow isn't any worse for traction than rain (sometimes better, even), but if the snow is on top of ice, you're going to wind up in a world of hurt if you speed too much. One really good way to get used to driving in the snow and ice is to find an abandoned parking lot, or a lot at night or after store hours, and practice stops, starts, and turns. A little experience goes a long way on slippery pavement.

Tailgating

Package Maintenance with Mezzanine

KainX — Tue, 28 Nov 2006 21:00:00 +0100

Mezzanine is a set of software tools created to make building and maintaining software packages as simple and efficient as possible. It is currently used for maintaining numerous projects from small, self-contained packages to entire distributions. Mezzanine forms the backbone of the package management and build system for cAos Linux, and while this article will focus primarily on using Mezzanine with cAos, its information can be extended to numerous other uses.

The Source Package Module Format

Mezzanine uses a simple storage format called SPM. SPM stands for Source Package Module, and the reason for this simple yet useful format is to group (yet keep distinct) three separate items: the pristine source code, the patches applied to that source code, and instructions for building the package (in the case of RPM packages, the spec file).

The top-level directory, called the module, generally has the same name as the package (e.g., perl). The module contains up to 3 subdirectories: The source is stored in a directory called S, the patches are stored in a directory called P, and the spec file is stored in a directory called F (for spec file, as the 's' in "spec" was already taken for sources).

Note that not all directories need to exist. Packages without patches, for example, do not require a P subdirectory. In particular, if you check out the SPM from CVS, only directories that have files in them will be created.

Once stored in a format Mezzanine can recognize, such as SPM, most common tasks such as building and patching are accomplished quickly and efficiently thanks to Mezzanine's toolset.

Building Packages

Local Mode

If you do not have access to a CVS repository, or don't want one, you may use Mezzanine in local mode. This means that you will take a source RPM package and import it to the current working directory. This example will use the Mezzanine SRPM:

  $ mzimport -L mezzanine-1.7-0.14.src.rpm
  Importing /home/taj/RPM_BUILD/SRPMS/mezzanine-1.7-0.14.src.rpm into mezzanine tree....
  You requested local mode.  You will need to import the new tree by hand (mzimport mezzanine).
  $ ls
  mezzanine

The mzimport command has converted the Source RPM into an SPM tree:

  $ cd mezzanine
  $ find .
  .
  ./S
  ./S/mezzanine.tar.gz
  ./P
  ./F
  ./F/mezzanine.spec

The source and the spec file are there, and if any patches were included in the SRPM, they would be in the P directory. There are none, so it is empty. I will fix that soon. :-)

Inside the module directory (i.e. ...

Packaging from Scratch with Specgen

KainX — Sun, 22 Oct 2006 15:25:00 +0100

One of the most time-consuming activities involved in distribution software packaging is taking a software author's bare tarball and turning it into a clean package. It's also one of the most repetitive; most released open source software builds in a similar manner, meaning that there's a lot of duplication between spec files. Specgen, one of the Mezzanine tools, automates much of the repetitive nature of creating spec files and packages for new tarballs.

Page Contents

From 0 to RPM in 2.2 Seconds...
A Simple Example
In Case of Emergency, Pull Lever
Total Meltdown
Templates and Types
Wrapping Up

From 0 to RPM in 2.2 Seconds...

Creating a new package from a downloaded tarball involves a series of basic steps that goes something like this:

Download tarball.
Unarchive tarball.
Scan package for clues as to how it builds (i.e., configure script, Makefile, Imakefile, etc.).
Look for documentation files which will need to be specially flagged.
Create the spec file, populating the header fields and build instructions based on previous inspections.
Perform a test build to verify the spec file's functionality.
Correct any errors found in the previous step. Lather, rinse, repeat.

Sometimes the last step is completely unnecessary, and sometimes it can be a real doozy. Unfortunately, there's not much I can do about that. But the other steps are exactly why specgen exists: it gets you as far down the road as possible so that you can focus your attention solely on the parts that actually require skill and thought.

A Simple Example

ARPAlert is an ARP table monitoring utility which can notify/alert you when an unauthorized connection is detected on your network. It just so happens that it uses GNU autotools and builds properly, so specgen has no problem with it:

$ specgen http://www.arpalert.org/src/arpalert-1.1.3.tar.gz
Downloading http://www.arpalert.org/src/arpalert-1.1.3.tar.gz................................................................................done.
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.18294
sh-trace: umask 022
sh-trace: cd /var/tmp/mezzanine.temp.build.15458.477c/arpalert/BUILD
sh-trace: cd /var/tmp/mezzanine.temp.build.15458.477c/arpalert/BUILD
sh-trace: rm -rf arpalert-1.1.3
sh-trace: /bin/gzip -dc /var/tmp/mezzanine.temp.build.15458.477c/arpalert/SOURCES/arpalert-1.1.3.tar.gz
...
Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/mezzanine.temp.build.15458.477c/arpalert/buildroot
Wrote: /var/tmp/mezzanine.temp.build.15458.477c/arpalert/SRPMS/arpalert-1.1.3-1.caos.src.rpm
Wrote: /var/tmp/mezzanine.temp.build.15458.477c/arpalert/RPMS/i386/arpalert-1.1.3-1.caos.i386.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.61585
sh-trace: umask 022
sh-trace: cd /var/tmp/mezzanine.temp.build.15458.477c/arpalert/BUILD
sh-trace: cd arpalert-1.1.3
sh-trace: test x/var/tmp/mezzanine.temp.build.15458.477c/arpalert/buildroot '!=' x/
sh-trace: rm -rf /var/tmp/mezzanine.temp.build.15458.477c/arpalert/buildroot
sh-trace: exit 0
$

As we can see from the output of the test build, the build worked. This means that specgen has successfully created a package directory for us (in PDR format) using the automatically-detected package name (arpalert in this case). All that's left is to tweak the 3 bits of data in the spec file that specgen can't automatically populate: "Summary," "Description," and "Group."

$ cd arpalert
$ ls -Fla
total 116
drwxr-xr-x   2 mej mej   4096 Oct 17 12:02 . ...

Bad Example

KainX — Fri, 16 Dec 2005 14:37:00 +0100

"If I Get Paid Lots of Money To Write Articles Online, Why Am I So Dense?"

Andrew Brown of the Guardian wrote an article in which he uses OpenOffice to prove that open source is a failure as a software development method. Without wasting too much time on the obvious logical fallacy of drawing conclusions based on a single, non-representative sample, I will also point out several additional (and less obvious) flaws in his logic and provide counter-examples to help illustrate that Mr. Brown is either woefully misguided or under the influence of a Microsoft payoff.

Of all the myths that have grown up around open source software, perhaps the most pervasive is Eric Raymond's aphorism that "Many eyes make bugs shallow", suggesting that if lots of people can view a program's source code, they will find and fix its errors more quickly than commercial products whose code is jealously guarded. The only problem with this is that it's not true

...Except that it is true. Anyone who has spent any time at all developing software can attest to the fact that it's a lot easier to track down bugs when there are as many sets of eyes as possible looking at the code. In fact, I can't even count the number of times I've stumbled on the most elusive of programming blunders simply by trying to explain to someone else why my code couldn't possibly be doing what it was doing. :-) While I certainly won't claim that it's a sure thing, given the choice between bug-hunting solo or being one member of a team of debuggers, I'll take choice #2 every single time.

The myth of open source rests on two improbable assumptions. The first is that a significant proportion of users can fix bugs. That is true at the Massachusetts Institute of Technology, where the concept of open source was first formalised in the 1980s by Richard Stallman and others, and it is true in some of the geekier corners of the internet.

Okay, first off, RMS did not formalize open source. He'd be the first to tell you that he's about "free software," which is the computing equivalent of a hippie commune, and not "open source," which is about explaining the strengths of a less shrouded method of developing, testing, and deploying software products to the decision makers in business who don't understand or care about the idealistic politics associated with RMS and the FSF. Using the term "open source" while referring to RMS is like citing the famous "I Have a Dream" speech of David Duke.

Secondly, I don't know a single open source developer (of which I most certainly am one) who actually believes that the majority of users know enough about programming and software engineering to locate and correct erroneous code. I will say vociferously, however, that no one is better at triggering bugs than users who can't code!

But what's missing here is one undeniable fact: open source does not make bugs any harder to find! Let's take his example of OpenOffice. As the article states, Sun employs about 100 full-time developers for OpenOffice. Those 100 people have access to the code and are able to find and fix bugs regardless of whether OO is open or closed source. So at best, the project is no worse off open than closed. The power of open source comes from the fact that more people can access the code. And even if there's only 1 additional person on the entire planet who can help the Sun-employed team find/fix issues, open source is advantageous.

No, it's not always the end-all and be-all solution, but it sure doesn't hurt.

This is important because of the second crucial false assumption: that even if not all users can fix a bug, they can help find them. They can't. Most users just think: "The computer isn't doing what I want."

Same problem as before. Even if 1 additional user can find/fix a bug, the team is better off. There will be users who don't understand problems with software regardless of the development methodology you employ. Mr. Brown implies that making the source available somehow makes users less able to find bugs. Those users who can't, can't, regardless of whether or not the code is accessible. ...