It’s good to see that those folks who used to write Cliff’s Notes have found work – They’re now writing movie descriptions. Note that you are allowed an unlimited amount for the description – I’ve seen over 10 pages worth for a Law and Order episode. I guess poor Marie just doesn’t stack up, the next 2 pages only continue with the actor’s names, and the director.

I can’t believe I am still running a self-serving tech/nerd blog this many years later.. I’ve gone from a text based personal resume, to an Open Source system I created to share my ported software (to unpopular platforms, such as Solaris x86 and MacOS X (at the time)), then eventually opting to no longer support my tools in the ideal of making money by writing code – exporting that and moving into another system (after testing serveral others). Gee, alot happens in ten years.

In other news, I’ve been using OpenSUSE 11.0 since late June on a testing/dev system, and it is incredibly stable. Not only does it offer a newer kernel base (2.6.25.x), but it touts KDE4, KDE 3.5.9, and GNOME 2.2. Yep, you can roll your own; this isn’t Xubuntu.

The whole system is incredibly stable, and as much as I can not stand the over-engineered ‘Zypper’ system, ‘Smart’ is quite comparable to apt, and is just as fast.

Despite the Zypper hate already, it has some great new BSD-like features such as ‘dist-upgrade’, which should FINALLY offer OpenSUSE the ability to upgrade (at least between minor revisions) without doing a reformat/reinstall. Yes, SuSE users, it’s no longer 1996!

It’s incredibly stable, well-supported, and is leaps above what Ubuntu offers – and I admit that, being a Debian user for years. My laptop had the proper drivers, and could even sleep to RAM without messing around with kernel internals.

It’s about time; OpenSUSE has made Linux closer to being entirely desktop ready than even the ‘Friendly’ Ubuntu. Game’s on.

An often-overlooked Linux distribution (likely due to being purchased by Novell, whom many self-professed Linux users find a reason to detest) is openSUSE; a free distribution, supported and partially developed by Novell.

I tend to be fairly software-eclectic: I’ll try anything once, because chances are – I will see it again. I can hold my own with RedHat distributions, Debian distributions, various forms of BSD, and, now, I have finally cut my teeth on SUSE. The last time I looked at SUSE, it was Slackware based, only, in German.

The times have truly changed. It’s certainly no Slackware.

I burned a Live CD of openSUSE 10.3, and stuck it into my Vostro 1400. It just.. worked. It booted, and I was in a KDE menu with my wireless online within 20 seconds.

(Not even the famed “easy to use” Ubuntu worked properly on the initial boot/install of this machine: Ubuntu screwed up the video settings, installing a VESA driver, and somehow managed to wedge itself when trying to load the ipw3945 wireless driver. Then, when I decided I wanted to be able to ‘sleep’ the laptop, I had to make my own ACPI scripts; none of those included with Ubuntu would work.)

Feeling a bit cocky, I took it upstairs to boot on my “brand new” (six months old) Inspiron 530 Quad Core based desktop. Not only did it work (although for obvious reasons, it used the open source driver rather than the proprietary NVidia one by default), but it saw that I had placed a $20 TV card into a PC slot, so it automatically put KDETV in my applications menu. How cool is that? I had to reload the module with the proper card, and tuner id – which took about 5 seconds in YaST2. I spent about two hours figuring all of the system settings, V4L2 drivers, etc, prior to it to work before. Wow. What else can this do?

I have not used the GNOME release of openSUSE, as I love the elegance – and the fact that KDE applications are closely tied together, not only with the desktop, but themselves. openSUSE has it’s own menu that’s fired off of kicker (one right click away from the usual KDE menu), which is pretty damn useful when you get used to it. It’s like having QuickSilver built into kicker.

Now, the bad side of openSUSE:

The package management system is so overengineered, it’s pathetic. Each subsystem can have it’s own repository for any purpose; I have one specifically for ‘Wine’, and another for ‘Mutt’. That seems a bit much. Your package management system doesn’t need to be a gateway to SVN, nor should it be. It’s slow. Zypper is so damn slow, it took 30 seconds to look for new patches with a very modest set of repositories. There is a secondary tool that can be installed, and used, called ‘smart’, which is somewhat similar to ‘apt-get’ on Debian systems. It is much, much faster, but non standardized upon, yet.

There’s no real way to ‘upgrade’ between versions. The official stance of many openSUSE users is to ‘Have /home on a new partition, format the rest, and start over.’ It’s not 1996; there’s no reason we should need to do this.

Everything is customized, sometimes it’s in an odd way. The Apache2 distribution in openSUSE is beyond pedantic: It’s obnoxious to configure with their distribution layout.

Everything important is controlled by a combination of shell scripts, and messy GUI utilities. If you don’t do it from YaST, you’ll do it in YaST2. There is no other option. You are now part of the YaST borg.

The polished applications and care put into the system still outshine the above issues; if openSUSE gets a managable packaging system that mortals can use – it might just make it. If you haven’t already, try it out. You might just like it. I did, and I am now without a Debian based system in my office for the first time in years.

I remembered this being a ‘never heard more than twice’ song from the 70s. However, it’s become incredibly popular. First, it was remixed for a GAP commercial, then for a commercial advertising anti-allergens.

For the rest of you who just wanted the song, and can live with generic jeans while taking an over the counter Sudafed, it’s by Bill Withers:

This was originally posted by Bret Hubert nearly 6 months ago, but it’s saved me a LOT of time, since he’s rehashed, well, common sense:

“…
Additionally, our database interface needed to offer an extra feature: every once in a while a query comes along that we DO need to wait for, and because of coherency issues, such a query can only be executed once all queries ‘in flight’ have finished.
So we spent some time pondering this, and suddenly it dawned on me that many of the features we needed exactly match the semantics of the venerable UNIX ‘pipe’.
A pipe is normally used to communicate between two processes, as exemplified by this sample shell script command, which shows us the largest directories on a disk:
$ du | sort -n
The program ‘du’ generates a list of directories and their sizes, which is then fed to sort which outputs this in ascending order. However, nothing prohibits us from using a pipe to communicate with ourselves – and as such it might be a might fine conduit to pass database queries through to our database worker thread.
This has some very nice benefits. Pipes are incredibly efficient, since a lot of UNIX performance depends on them. Additionally, they implement sane blocking behaviour: if too much data is stuck in the pipe, because the other process does not take it out again quickly enough, the sending process automatically blocks. The operating system implements high and low water marks to make this (un)blocking happen efficiently.
Furthermore, pipes guarantee that data up to a certain size can either be written as a whole, or not written at all – making sure we don’t have to deal with partial messages.
Finally, pipes automatically detect when the process on the other end of them has gone away, or has closed its end of the pipe.
However, not all is good. In order to transmit something over a pipe, it must be serialised into bytes – we can’t transmit ready to use objects over them. Additionally, because pipes implement ‘stream’ behaviour, we need to delineate one message from the other, because the pipe itself does not say where a message begins and ends – unlike datagram sockets for example.
And this is the clever bit of our idea. As stated above, pipes are usually employed to transmit data from one process to the other. In our case, the pipe goes from one thread of execution to the other – within the same process, and thus within the same memory space. So we don’t need to send serialized objects at all, and can get away with transmitting pointers to objects. And the nice thing is, pointers all have the same (known) length – so we can do away with both delineation and serialisation.
Additionally, pointers are a lot smaller than most messages, which means we can stuff more messages in the same (fixed) size of the pipe buffer.
So, are we done now? Sadly no – we have the additional need to be able to ‘flush the pipe’ in order to perform synchronous queries that we do need to wait for.
This is where things get complicated, but for those who really want to know, I’ll explain it here. It took almost a day of hacking to get it right however, and I’m explaining it for my own benefit as much as for that of the reader, since I’m bound to forget the details otherwise.
If a synchronous query comes along, we need to flush the pipe, but UNIX offers no such ability. Once we’ve written something to a pipe, all the kernel guarantees us is that it will endeavour to deliver it, but there is no system call that allows us to wait for all data to actually be delivered.
So we need to find a way to signal a ‘write barrier’, and the obvious way to do so is to send a NULL pointer over the pipe, which tells the other end we want to perform a synchronous query. Once the worker thread has seen the NULL pointer, it unlocks the single controlling mutex (which is the return signal that says “got you -the pipe is empty”), and then waits for further pointers to arrive.
Meanwhile, the sending thread tries to lock that same mutex immediately after sending the NULL pointer, which blocks since the receiving thread normally holds the lock. Once the lock succeeds, this tells us the worker thread has indeed exhausted all queries that were in flight.
The sending thread now performs its synchronous database work, knowing the database is fully coherent with all queries it sent out previously, and also knowing the worker thread is not simultaneously accessing the connection – since it is instead waiting for a new pointer to arrive.
If our program now wants to perform further asynchronous queries it can simply transmit further pointers to the worker thread – which oddly enough does not need to retake the mutex. This is what caused us many hours of delay, because intuitively it seems obvious that once the sending thread is done, it must release the mutex so the worker thread can retake it.
As it turns out, doing so opens a whole world of nasty race conditions which allow synchronous queries to ‘jump the queue’ of asynchronous queries that are in flight and have not yet arrived.
So, the sequence is that the worker thread only unlocks the mutex, while the sending thread only locks it.
And this basically is it! So how much lines of code did we save by using the magic of UNIX pipes? The pipe handling code takes all of 90 lines, whereas the Distributor code of PowerDNS takes a round 300, even though it does not offer synchronous queries, does not automatically block if too many queries are outstanding, and most certainly couldn’t implement the sensible wakeup ability that UNIX pipes do offer.
Oh, and you might be wondering by now, did it help? Indeed it did – our program is now at least 20 times faster than it used to be, and there was much rejoicing.”