In order to get *good* random passwords, we want the equivalent of /dev/urandom. Microsoft provides the CryptoAPI, which includes the CryptGenRandom() API. I developed a DLL plugin for NSIS called Pwgen that collects entropy from the OS and generates a random password, restricted to the 62-character set of alphanumerics.

You can download pwgen-001 directly from me. I also recommend the official Pwgen plug-in wiki page on the NSIS wiki and the discussion thread on the Winamp NSIS forum.

I love Qt, because when I'm paid to write software to run on Microsoft Windows, I write that software on Linux, compile it on Linux, test it on Linux, and then the last step is to cross-compile it to Windows and test it inside a kvm virtual machine. I barely have to touch Windows with a 10 foot pole.

I'm not extremely fond of C++, but Qt makes C++ tolerable. The toolkit is quite honestly miles beyond Gtk+, a statement I make having written a Gtk+ app before, a number of glib apps, and being very fond of C. They're now shipping Webkit and an XQuery processor, and your application scan be styled (on the fly) with CSS.

Presently, my primary frustration is with the garage door opener market. There have been many technologies and protocols used by wireless garage door openers over the last decades. One of the consequences of this is vast incompatibility.

This bit me in the ass once when I cluelessly purchased a Genie-brand remote to open a Chamberlain Security+ door. That was actually a while ago, but I've now got a useless Genie remote. I ended up with the proper Chamberlain Security+ remote. It's a bulky unit, which is frustrating when space in my Miata is at a premium.

I moved to a new apartment recently. The garage door opener in this apartment is a LiftMaster, also bearing the Chamberlain name. Pleased that I wouldn't need to buy a new controller, I attempted to link my remote to the door with no success. Apparently, the "billion code" technology in this unit is obsolete.

Frustrated, I tried Home Depot, hoping to find a decent controller that would open both the new garage door and the old one. My purchasing choices were limited between mini-remotes (in a form factor I would much prefer) that wouldn't open the apartment garage door, equally bulky units that would only open the apartment garage door and not the old one, or an absolutely large "Clicker" with two buttons that was allegedly compatible with both.

I had the Clicker in my hand, about to give in and fork over the $20, but I was too disgusted with the size of the unit to make the purchase. I reasoned that I must be able to find a better unit on the Internet.

Unfortunately, it looks like I'm not in luck -- not in the slightest. Just shopping for an opener is a challenge -- the brand names, the color-coded learning buttons, frequencies, and manufacturing years all create a muddled mess. And just in case the shopping experience doesn't make you want to vomit, you'll find that nearly all of the devices will.

At this point, I have to step back and catch my breath. It's a fucking garage door opener -- a very simple RF device! Why are they all so bulky? You could probably cram 2... maybe 4 embedded Linux systems in the Clicker. Actually, with some of the "Linux in an ethernet connector" technology, you might be able to get 8 or 10 in there.

It's also gross that the landscape is littered with incompatible devices. I'm particularly surprised that Chamberlain doesn't sell a reasonably-sized opener that will open both their new and old doors. Perhaps what's holding back the market for a sane universal remote is that companies like Chamberlain would rather file disgustingly frivilous lawsuits against competitors making compatible openers than do any kind of real innovation themselves.

At times like this, I wish the landscape could all be blamed on one incompetent engineer or clueless manager - someone I could walk up to, then proceed to punch squarely in the face. But alas; I'm dealing with companies, industry and government. You can't punch a patent law and you can't punch proprietary "intellectual property." All you can do is hope that some day, the industry will behave more like the software industry is beginning to behave, by implementing open standards that benefit customer and the market alike.

I've been a pack-rat of tangible things, and so I've been throwing away much I feel is now unnecessary (such as old issues of PC Gamer from my years of youth). But no matter how much ends up in the garbage, there is always more work to be done.

Lately I've taken a diversion to cleaning up my PC. This is going to be a much more difficult challenge: data is easier to pack-rat than physical goods, because all the data I have fits into a power-sucking RAID array inside a small tower. But I have identified one area where I can make progress, and so I have.

Over the last few years, I went on a subscription spree. I signed up for the mailing lists of KDE, xorg, the Linux kernel, hal, dbus, Familiar, mod_perl, Apache, Gentoo, and others. I am genuinely interested in what is going on in each of these fronts, but I barely have the time left to read lkml, much less any of the others.

I let messages accumulate from these lists into a set of Maildir folders underneath one of my email accounts. My mailer (KMail) wept visibly trying to keep up with all these messages. Strange glitches were common. Kontact, the organizer application that wraps KMail, consumed on average 25% of my available page frames (2 GB). I mitigated the glitches with a Perl script that would archive the messages of high traffic mailing lists into an archive subfolder, keeping only the most recent 2000 in the main folder, but the memory usage remained.

It took forever to come to the common-sense realization that there was no way on Earth I could personally consume all this information. When I decided to go on an unsubscription spree, I had over 170,000 unread messages. Deleting them brought Kontact's RSS to 5%, and became one more step in my ongoing process of learning to pick my battles.

I've decided to keep my subscription to two lists: lkml, and cryptography@metzdowd.com. I don't really have the time to read either of them right now, but I couldn't let these ones go. :P

I consider myself lucky that I don't face perfectionism when I'm hacking a quick and dirty Perl script together (else, I'd be a very dysfunctional admin). As many admins, I have a large ad-hoc collection of Perl scripts doing various jobs for me (such as tweaking domain settings en masse on Joker), and though I tend to start at the very least with use strict;, my scripts still end up being an undocumented mess with dangling code and an arbitrary mixture of spaces and tabs (from when I use Konsole's copy-paste to go from vim on one terminal to another). These scripts require a little love to modify and maintain, but they do their short-term jobs very well.

When it comes to "real" software development, however, I hold myself to a very high standard, and hence it always makes me uncomfortable when I'm relying on someone else's code that might be good but lacking. I'm encountering a nice patch of that now.

In short, I'm having to take another route. Considering that my immediate need for a toolkit is based on the need for a cross-platform API (and the opportunity to avoid Microsoft's hatchet job on the C and POSIX standards), the alternative that most quickly rises into the picture is the GNOME libraries. GNOME doesn't offer a unified toolkit; rather, it looks like I'll have to work with GTK, GLib, Cairo, GNet and possibly others.

That's a pretty substantial amount of unfamiliar territory for a project on as tight a timeline as this one. The irritation of having so many libraries is that while the individual libraries seem to have reasonable API documentation, I have yet to find a good cohesive document that shows just how it all fits together. While the documentation available for these libraries (and for GNOME) is good, I find myself missing the comprehensive documentation offered by Qt.

I'm also having to gamble a bit that I don't step onto a portability landmine in my development. These libraries are supposed to be portable, but there are areas (such as GTK/Cairo integration) where I'm coding with my fingers crossed, hoping I won't encounter any oddball issues trying to build or run the result on Windows.

I'm also quietly weeping that while Cairo is good, it doesn't appear to hold even the slightest candle to Arthur, Qt's paint system. I was really hoping to have a reasonably easy time adding serious graphics sophistication to the visual presentation of my application.

But what really gets me during the development process is when I run into design decisions in the underlying libraries that make me want to choke the original developer. In GLib, it appears that memory allocation failures are handled by terminating the process rather than passing back a NULL pointer. This may make some people's lives easier, but it drives me bonkers. To me, writing code that can survive memory allocation failures is almost always worth doing. When you adopt a library that decides differently, you're pretty much stuck with their decision.

I'm also a bit unhappy with what I'm seeing in the g_list doubly-linked list API reference. If you want to delete an element, the "normal" functions to do so appear by their description to be O(n). They do offer a function which removes an element via its node pointer, but the only way it appears you can get a node pointer when populating the list is if you allocate the nodes yourself and forego using the convenience functions they offer in favor of g_list_concat.

There are a couple of considerations here that I have to remind myself of. One is that these little things don't matter too much in the grand scheme of things; GLib is good, and it is going to save me some time. GLib is also free, and when I'm not an active contributor to the library, it's best to be kind when throwing stones. But encountering these sorts of small gotchas is one of the things that keeps me smoking and leads to my desire to reinvent the wheel from time to time, just to make the spokes shine a little brighter.

You know... perfectionism isn't always a bad thing, it's just quite incompatible with deadlines.

Very good response from the CEO of a company Linus accused (to the extent of sounding like FUD) in the mail thread. The Linus mail would made some think he's getting increasingly scared of OpenSolaris. He was a more reasonable guy sometime back. Anyhow, hope the dinner works out well for both of you.

You might not find this one as hilarious as I do until you read what Linus said in full.

I think Linus' comments on Solaris show just how out of touch he is with other operating systems and the reason Linux has plateaued technically as an OS.

Linus' says ZFS is the only thing interesting about Solaris? That's one thing more than Linux has going for it.

Yes, Linux has nothing going for it whatsoever. Microsoft's fear of Linux is actually just an elaborate piece of comedy paid for by its shareholders.

I really get amused when some one mentions that they use Linux because it is free and it is open source. My immediate naïve question to them would be is – so which Linux do you use? The answer 99.99% would be – RedHat or Novell!! They do not realize that they “paid” RedHat or Novell for the distribution. So Johnathan is right RedHat and Novell hurt Sun more than what Linux did to Solaris. So did Sun really learn from RedHat regarding packaging or distributing an operating system? No it did not, it never will.

Honestly, I think Linux has a growth issue and its vast user base has to be nervous about it. Sun’s investment in Solaris might not have any impact on the share holder value for a while, but Linux has a lot of catching up to do.

Catching up? To Solaris?

For the record, I have respect for Solaris. But it amazes me when people in 2007 are still acting like Linux is a fragile newcomer without any desireable aspects or innovation. Talk about living under a rock.

Wishful thinking? Perhaps. What Henri Richard apparently said was that AMD/ATI would improve relations with the community. Dave Airlie doesn't seem completely convinced:

So a marketing dude said something about open drivers for AMD/ATI gpus and working with the community.

Can people get excited when AMD/ATI actually do something rather than showboat for media headlines?

Like ATI won't let me release my r500 source because I shouldn't have used a utility they gave me under NDA on those cards, now the thing is I done the correct thing and contacted them asking if I could release the code, so far this has just been stonewalled by their Linux driver management and their "legal" department, this isn't the action of a company trying to interact with the community or one that gives a rats arse about community..

I don't know for sure, but Henri Richard's e-mail address might be henri.richard@amd.com. If AMD is indeed interested in improving relations with the community, perhaps we should e-mail them asking for them to clear the release of Dave Airlie's r500 source?

AMD will soon deliver open graphics drivers, said Henri Richard just a few minutes ago, and the audience at the opening keynote of the Red Hat Summit broke into applause and cheers. Richard, AMD's executive vice president of sales and marketing, promised: "I'm here to commit to you that it's going to get done." He also promised that AMD is "going to be very proactive in changing way we interface with the Linux community."

If they make good on this promise, it will be fantastic for GNU/Linux users. Currently, ATI graphics support is very lackluster on the platform. NVIDIA offers a proprietary driver that mostly works, but their closed development has injured the community's ability to advance the state of X.org, and challenged the ability for GNU/Linux distributions to "just work".

I commit that if AMD makes good on this announcement and produces a reasonably working free driver for Linux and X.org, and NVIDIA has not matched their offering at the time I need to upgrade, I will definitely purchase an AMD/ATI card.

I thought about becoming a Joker.com reseller, but becoming a reseller appears to require a $250 deposit. My next step was to start working on a Perl script based on the excellent WWW::Mechanize to help with future changes. Along the way, I started to think about switching registrars.

GoDaddy.com is one of the bigger names these days, but its reputation goes to illustrate the biggest problem I have with the industry. The terms of service agreements you must accept to become a customer are written to favor the provider's whims to an outrageous extent. The truth is that most providers have these kind of crazy agreements, which means you may be pretty cornered when trying to select a provider that will look after your interests. Just because a provider doesn't have any horror stories like GoDaddy.com's termination of Fyodor's seclists.org domain doesn't mean they're not capable, or that they wouldn't buckle in a nanosecond if an attorney waved gracefully to them on the street. Given the incredibly poor terms of service agreements that form the industry standard, it is hardly surprising.

In the end, I decided to stay with Joker.com, specifically because their terms of service agreement is one of the most fair and balanced agreements I've ever seen. If I were Joker, I'd promote the agreement as a feature of being their customer. I'd personally pay a premium for a terms of service agreement, written in plain English, that declares the only reasons a provider can terminate service and is contractually binding on both parties.

What scares me is how claustrophobic I currently feel:

turbotaz ~ # df --si
Filesystem             Size   Used  Avail Use% Mounted on
/dev/md/1              628G   557G    40G  94% /
udev                   1.1G   312k   1.1G   1% /dev
shm                    1.1G      0   1.1G   0% /dev/shm

At the rate I'm currently going, that last 40 GB is going to disappear pretty quickly. I don't have anything I'm particularly happy about deleting... Could we please hurry up and get affordable terabyte drives on the market? I've heard chatter of one or more, but I don't know if they are on shelves yet, and if they are, buying four is probably going to break the bank...

(For the inappropriately curious: no, the space is not occupied by pornography.)

You can use the GCC builtin __builtin_expect to inform the compiler that a certain test is expected to be false most of the time. In doing so, GCC (hopefully) lays out machine code such that the CPU's branch predictor doesn't trip over your assertion and cause a pipeline stall every time it is hit. The Linux kernel does something like this:

Note that the !! is actually two ! operators, which forces the value of the (x) test to be a boolean and avoids a possible warning in certain usages of the unlikely() macro.

So we can define an assertion macro:

#define my_assert(x) \
    do { \
        if (unlikely(!(x))) \
            abort(); \
    } while(0)

This way, if the assertion fails, we call abort() which sends SIGABRT to the process and terminates dumping core. But what if this is a production process? An assertion failure would bring down the system! If the assertion failure could be caused by specially crafted user input, the bug is downgraded to a denial of service attack, which is still a security problem. So the temptation would be to structure your code such that an assertion failure in production mode results in simply aborting the current operation. This way, you don't go forward to undefined results, and you don't dump core and lose the process. You can emit a log message notifying that the error has been encountered.

That said, core dumps can be very helpful in finding a problem. But it's not that easy: if a user is running the software in full production, they might not be keen on the idea of running a version of the software that will core dump on the assertion failure. If you can't reproduce the problem locally, tracking down the source of the problem can be very difficult.

You want a core dump, but the user doesn't want their process to go down. I have an idea for what you might do in this situation. First we arrange an atomic counter in process-global memory:

pthread_mutex_t abort_lk = PTHREAD_MUTEX_INITIALIZER;
int nr_aborts;

Now we implement both logic paths (abort the request and abort the process):

pid_t pid;
int do_abort = 0;

/* assertion: make sure ptr is not null */
if (unlikely(ptr == 0)) {
    pthread_mutex_lock(&abort_lk);
    if (nr_aborts < 5) {
        nr_aborts++;
        do_abort = 1;
    }
    pthread_mutex_unlock(&abort_lk);

    if (do_abort) {
        pid = fork();
        if (pid <= 0)
            goto error;
        nice(19);
        chdir("/somewhere/for/core/dumps");
        abort();
    }

    goto error;
}

Upon assertion failure, we fork a child process, which immediately sends itself SIGABRT. We create a ceiling on the number of times we'll core dump (the nr_aborts counter) so that we don't allow a mischevious attacker (or some other bug) to cause the disk to fill with cores. We also choose the lowest priority for our sacrificial process to attempt to minimize interruption to the system.

The parent simply aborts the current operation and emits a log message, and a core dump is generated containing roughly the same state the process was in when the assertion failure happened. The Linux kernel (and probably others) even help us out here: when you call fork(), you get a child process and the VM is initially shared with the parent but marked copy-on-write. As the parent continues to execute, it will touch pages in the VM causing the OS to have to do some duplication of pages (interrupting the parent thread of execution each time a new page is touched), but much of the memory will be shared as it is being written to disk by the child.

Potential gotchas I can think of come in two flavors: multi-threading and the OOM killer. A pthreads process that calls fork() will only fork the calling thread (and the whole VM, file descriptors, etc. of the process as well). This isn't necessarily that big of a problem: the state you are most likely interested in exists within the thread where the assertion failed anyway, making visibility into the other threads of the process less important.

The OOM killer issue, however, is more concerning. This method of fork() and abort() makes use of copy-on-write, but the process dirtying the shared pages the most is going to be the parent (which hopes to continue executing just as before). If the operating system uses VM overcommit, it might run out of pages when it needs to create a copy. When this situation happens, if the operating system cannot release any of its own memory, and cannot otherwise swap, some (seemingly arbitrary) process must die immediately. This logic is not specified as part of any contract to user-space; different versions of the operating system are liable to do different things. One would hope the parent process doesn't take the SIGKILL.

I have found that Radiant (a content management system) and Open Source Web Design (a collection of free/libre website layouts) have saved me a tremendous amount of time in bringing my personal domain back online.

Many of these people believe that developers that release GPL code are being silly by not giving up all rights to the code they release. If these feelings ring true with you, please remember that it is the authors (copyright holders) of a program that have the full right to decide how to license their product. You see this with Microsoft and Apple, for example - except they don’t use the GPL; rather, they use licenses that seek to criminalize and/or restrict many ethically honest uses of their product.

We choose the GPL (copyleft) because we care about the freedoms of our end users and fellow developers. The license is merely designed to ensure that our work cannot be appropriated into any system that is not free. Since the GPL must apply to derived works, it is often further argued that we’re constraining our work to one idea of freedom. While such a remark is correct, it betrays further confusion about what we’re trying to do.

You see, these discussions are sometimes mixed in with secondary discussions of theoretical ways a developer could try and work around the wording of the GPL to avoid its clear intent. This practice is, of course, dishonest. And it demonstrates just why we have to enforce the GPL specifically on derived works. There are always a small number of folks looking to exploit our work in a manner that is obviously contrary to the simple ‘fairness’ under which we have released it. By weakening the GPL’s requirements on derived works, we would open ourselves and our users up to many other opportunities for harmful exploitation.

It is the right of every developer to license their work how they see fit. (If you’re an agent like Microsoft, and you’re actually selling a product, you’ll be subject to more actual and possible regulation to make sure you uphold your consumer’s legal rights.) Asking any developer to release their hard work into the public domain, simply because you find the terms of the GPL unreasonable, is not in and of itself morally bankrupt; however, as soon as your request becomes an expectation, you’re crossing the line.