Today we assigned an IP address to a gas tank.
Yay.
Today we assigned an IP address to a gas tank.
Yay.
By now, I’m sure you all have read about the OpenSSL bug discovered in Debian.
There’s a lot being written about it. There’s a lot of misinformation floating about, too. First thing to do is read this post, which should clear up some of that.
Now then, I’d like to think a little about a few things people have been saying.
People shouldn’t try to fix bugs they don’t understand.
At first, that sounds like a fine guideline. But when I thought about it a bit, I think it’s actually more along the lines of useless.
First of all, there is this problem: how do you know whether or not you understand it? Obviously, sometimes you know you don’t understand code well. But there are times when you think you do, but don’t. Especially when we’re talking about C and its associated manual memory management and manual error handling. I’d say that, for a C program of any given size, very few people really understand it. Especially since you may be dealing with functions that call other functions 5 deep, and one of those functions modifies what you thought was an input-only parameter in certain rare cases. Maybe it’s documented to do that, maybe not, but of course documentation cannot always be trusted either.
I’d say it’s more useful to say that people should get peer review of code whenever possible. Which, by the way, did occur here.
The Debian maintainer of this package {is an idiot, should be fired, should be banned}
I happen to know that the Debian programmer that made this patch is a very sharp individual. I have worked with him on several occasions and I would say that kicking him out of maintaining OpenSSL would be a quite stupid thing to do.
He is, like the rest of us, human. We might find that other people are considerably less perfect than he.
Nobody that isn’t running Debian or Ubuntu has any need to worry. This is all Debian’s fault.
I guess you missed the part of the advisory that mentioned that it also fixed an OpenSSL upstream bug (that *everyone* is vulnerable to) that permitted arbitrary code execution in a certain little-used protocol? OpenSSL has a history of security bugs over the years.
Of course, the big keygen bug is a Debian-specific thing.
Debian should send patches upstream
This is general practice in Debian. It happens so often, in fact, that the Debian bug-tracking system has had — for probably more than a decade — a feature that lets a Debian developer record that a bug reported to Debian has been forwarded to an upstream developer or bug-tracking system.
It is routine to send both bug reports and patches upstream. Some Debian developers are more closely aligned with upstream than others. In some cases, Debian developers are part of the upstream team. In others, upstream may be friendly and responsive enough that Debian developers run any potential patches to upstream code by them before committing them to Debian. (I tend to do this for Bacula). In some cases, upstream is busy and doesn’t respond fast or reliably or helpfully enough to permit Debian to make security updates or other important fixes in a timely manner. And sometimes, upstream is plain AWOL.
Of course, it benefits Debian developers to send patches upstream, because then they have a smaller diff to maintain when each new version comes out.
In this particular case, communication with upstream happened, but the end result just fell through the cracks.
Debian shouldn’t patch security-related stuff itself, ever
Well, that’s not a very realistic viewpoint. Every Linux distribution does this, for several reasons. First, a given stable release of a distribution may be older than the current state of the art upstream software, and some upstreams are not interested in patching old versions, while the new upstream versions introduce changes too significant to go into a security update. Secondly, some upstreams do not respond in a timely manner, and Debian wants to protect its users ASAP. Finally, some upstreams are simply bad at security, and having smart folks from Debian — and other distributions — write security patches is a benefit to the community.
A little while back, I wrote a blog post called DjVu: Almost Awesome, where I pointed out the strengths of the three DjVu family of formats, but lamented the fact that there was no Free Software to create DjVu files in the most interesting format, DjVu Document.
Well, now there is: pdf2djvu is out and works, and it’s been ITP’d to Debian, too.
As a very quick recap, DjVu is a family of raster image codecs that often creates files much smaller than PDFs, PNGs, TIFFs, etc. It has a ton of advanced features for things like partial downloads from websites. It’s pretty amazing that a raster format can create smaller files than PDFs, even at 300 or 600dpi resolutions in the output. Of course, for some ultra-high-end press work, PDF would still be needed, but DjVu is quite compelling for quite a few uses. Since it is a raster format, it is simpler to decode and is not subject to local system variations, such as installed fonts, like PDF is.
Which brings me to the scourge of PDF. Recently we got a trouble ticket at work from someone saying there was a bug with our Linux environment because Linux users didn’t see the correct results when they opened his PDF file. A quick inspection with some of the xpdf utilities (pdffonts, to be specific) revealed that the correct fonts were not embedded in the file. The user didn’t believe me, and still wanted to blame Linux, saying that it worked fine on his PC with Acrobat. So I tried opening the file on a Windows 2003 terminal server, and it looked worse there than it did with any Free Linux viewer — really quite terribly corrupted. He still wasn’t entirely convinced, until he happened to try printing the file in question, and even Acrobat couldn’t print it right.
PDF was supposed to be a “read anywhere” format that produces exact results. But it hasn’t really lived up to that. Font embedding is one reason; the spec lists a handful of fonts that are allowed to not be embedded, but it is routine for some reason to violate that and fail to embed quite a few more. Then you have to deal with font substitution on the receiving end, which is inexact at best. Then you have all sorts of complex differences between versions, and it becomes quite the mess. (And don’t even get me started on broken PDF editors, such as the ones Adobe sells…) Somehow, quite a few people seem to have this idea built up in their heads that PDF is both an exact format, and an editable format, when really it is neither. (Last week, I was asked to convert a PDF file to a Word document. Argh.)
DjVu keeps looking more and more pleasant to my eyes.
In the recent interview with InformIT, Donald Knuth said:
I also must confess to a strong bias against the fashion for reusable code. To me, “re-editable code” is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.
I have tried in vain to locate any place where he talks about this topic at greater length. Does anyone have a link?
Every so often, I come across some utility that need. I think it must have been written before, but I can’t find it.
Today I needed a tool to take a set of files and split them up into directories in a size that will fit on DVDs. I wanted a tool that could either produce the minimum number of DVDs, or keep the files in order. I couldn’t find one. So I wrote datapacker.
datapacker is a tool to group files by size. It is perhaps most often used to fit a set of files onto the minimum number of CDs or DVDs.
datapacker is designed to group files such that they fill fixed-size containers (called “bins”) using the minimum number of containers. This is useful, for instance, if you want to archive a number of files to CD or DVD, and want to organize them such that you use the minimum possible number of CDs or DVDs.
In many cases, datapacker executes almost instantaneously. Of particular note, the hardlink action can be used to effectively copy data into bins without having to actually copy the data at all.
datapacker is a tool in the traditional Unix style; it can be used in pipes and call other tools.
I have, of course, uploaded it to sid. But while it sits in NEW, you can download the source tarball (with debian/ directory) from the project homepage at http://software.complete.org/datapacker. I’ve also got an HTML version of the manpage online, so you can see all the cool features of datapacker. It works nicely with find, xargs, mkisofs, and any other Unixy pipe-friendly program.
Those of you that know me will not be surprised that I wrote datapacker in Haskell. For this project, I added a bin-packing module and support for parsing inputs like 1.5g to MissingH. So everyone else that needs to do that sort of thing can now use library functions for it.
Update… I should have mentioned the really cool thing about this. After datapacker compiled and ran, I had only one mistake that was not caught by the Haskell compiler: I said < where I should have said <= one place. This is one of the very nice things about Haskell: the language lends itself to compilers that can catch so much. It’s not that I’m a perfect programmer, just that my compiler is pretty crafty.
I’ve been writing a bit about Trac and Redmine lately. For approximately the 1/3 of the publically-available software that I’ve written, I maintain a Trac site for it at software.complete.org. This 1/3 is generally the third that has the most interest from others, and there’s a bug tracker, wiki, download area, etc.
Trac is nice, and much nicer than one of the *Forge systems for a setup of this scale. But it has long bugged me that Trac has no integration between projects. To see what open bugs are out there on my software, I have to check — yes — 17 individual bug trackers.
To keep track on the wikis to make sure that nobody is adding spam, I have to subscribe to 17 different RSS feeds.
It took me some time just to hack up a way so I didn’t have to have 17 different accounts to log in to…
So, mainly, my use case for Trac isn’t what it was intended for.
Enter Redmine. It’s similar in concept to Trac — a lightweight project management system. But unlike Trac, Redmine allows you to have separate projects, but still manage them all as one if you please.
Redmine didn’t have Git support in its latest release, but there was a patch in Redmine’s BTS for it. I discussed why it wasn’t being applied with Redmine’s author, and then went in and fixed it up myself. (I used Git to make a branch off the Redmine SVN repo — very slick.) Unlike Trac’s Git support, Redmine’s is *fast*. I tested it against a clone of the Linux kernel repo on my local machine.
There are a few things about Redmine I don’t like, but I have learned that they mainly have to do with Ruby on Rails. As someone pointed out on Planet Debian lately (sorry, can’t find the link), the very nature of Rails makes it almost impossible for OS developers like Debian to include Rails apps in the distribution.
Not only that, but it seems like Rails assumes that even if you are just going to *use* an app, you know how to *write* one. For instance, this is pretty much the extent of documentation on how to set up a Rails app to be able to send out mail:
# See Rails::Configuration for more options
And of course, googling that turns up nothing useful.
Redmine is a rails app, so it cannot escape some of this. It seems to be a solid piece of work, but Rails seems to make things unnecessarily complex. That, and I’ve found some bugs in the underlying Rails infrastructure (like activerecord not quoting the schema name when talking to PostgreSQL) that make me nervous about the stack.
But the site is up and running well now, so I’m happy, and am planning to keep working with Redmine for quite some time.
Many of you have seen the net classic If Operating Systems Were Airlines. Today, let’s consider what the world might be like if version control systems were airlines…
Before anyone gets mad, this is all in fun, OK?
RCS Airlines: One of the first airlines, from way back when this whole aviation thing was new and exciting. Each RCS flight carries exactly one passenger, which RCS believes is a superior way to fly. Although most RCS airplanes are rusty and battered today, RCS Airlines still retains its historic dedication to security. Each airplane is kept locked as much as possible for safety. Occasionally flights will be delayed for hours because the pilot can’t open the locked plane. When this happens, the pilot will frantically try to get the cell phone number of whoever it is that has locked the plane. When the plane finally gets unlocked, you may be tempted to ask why it was locked for so long. Veteran RCS users have learned that the answer is usually disgusting, and never ask anymore. Main competitor: CP/M airlines.
CVS Airlines: Founded on the belief that they could be more efficient than RCS by carrying multiple passengers per flight. They still carry each passenger in a separate RCS-built airplane, but the airplanes fly in a goose-like “,V” formation. Watch out for layovers, though. It can take hours to merge new passengers into the formation properly, and it might take several attempts to take off afterwards.
CVS flights often feature fights over who gets to fly. CVS piloting fights are legendary; rumor has it that OpenBSD got started after CVS airlines refused to allow a passenger to board on the grounds that he had in the past refused to stow his tray table in the upright and locked position.
CVS airlines mostly counts as customers the “over-50” crowd who grew up using CVS and don’t like change. Its in-flight magazine features advertisements for balding-reversal treatments and uuencode tools.
Main competitor: AIX airlines.
Subversion Airlines: Started by some grey-haired CVS executives with long, wispy beards, Subversion airlines got started by trying to be “CVS, but better”. Subversion airlines was the first major airline to use planes that seat more than one passenger. Unlike CVS airlines, all passengers on a Subversion flight travel in the same plane.
Subversion airlines is famous for its Soviet-like centralized control. All operations must be approved by the Kremlin, and you are allowed, by the grace of the Party Leader, to gaze at the massive airplanes. Those that have served the Party and Airline well for many years are allowed to enter the Great Shrine of the First-Class Comitter, and actually make changes to the airplanes themselves. Plainclothes Subversion Airlines security agents lurk on every flight, and you should not be surprised to be thrown out an airplane window if you make a joke in bad taste about the pilot’s flying skills.
Subversion airlines thrives on the concept that “photocopying is cheap”. You are encouraged to make photocopies of your ticket, or to photocopy your photo ID, and give copies of each to as many people as you can. At checkin time at the gate, if more than one person arrives with a copy of the same ticket, they are ushered into the “merging room” and each person is given a brick. The door is closed, something magical occurs, and the one person that emerges still able to walk is allowed to board the plane.
Main competitor: Windows airlines with no Administrators allowed.
tla airlines: Founded by one of those eccentric British noblemen, Lord Tom’s airline is the utopian philosopher’s airline. Chafed by the heavy-handed control of Subversion Airlines, tla airlines wants every passenger to be created equal. As you approach the gate area in the terminal, you will find many philosophers occupying the gate area, extolling the virtues of tla airlines. They compare tla airlines to reaching out and touching the heavens, leaving behind the bonds of a ground-based life, actually merging with the stars. Oh, the gorgeous beauty of it all! The things we will see!
As you see people arriving from another flight, you observe that some of them have burn marks. One of them comments that “merging with the stars doesn’t work.” Immediately, a dozen philosophers get in a fight with him, claiming that he simply doesn’t understand what it means to merge with the stars, and that if he gets his inner being in the proper state first, he’ll have a much better experience.
As you board the tla airplane, you obvserve that the jetway is a mile long. The airplane itself reminds you of something of a cross between a gothic cathedral and a level of Doom. There are spectacular archways everywhere, sometimes where they don’t really belong. Each archway is supported by ornate curly braces which you don’t normally see on airplanes, and frankly, you’d rather not, because they look all pointy and confuse the kids.
As you arrive as your destination terminal, you see it too is full of philosophers, most of them dining.
Main competitor: VMS airlines.
Darcs Airlines: Unlike every other airline, this one uses physicists instead of engineers to design its airplanes. One brilliant Darcs physicist has finally come up with The Theory of Everything, and as such, Darcs knows where you want to go before even you do. Darcs airlines prides itself on customer service, and asks your preference for even the tiniest details about your trip.
Each seat pocket features a copy of the Theory of Everything for your reading enjoyment, but nobody actually understands it.
Occasionally, you will find that Darcs pilots get into angry conflicts with the control tower in mid-flight. This results in the control tower revoking your permission to land. Legend has it that one Darcs pilot of a plane with exceptionally large fuel tanks actually resolved his conflict with the tower and landed two weeks after taking off. Experienced Darcs users board with several parachutes: one for themselves, and a few more for the newbies.
The Darcs physicists claim that the Theory of Everything predicted the pilots would act this way, and that all pilots eventually act this way throughout the entire universe. They toil day and night finding a way to adjust the gravitational constant of the universe, thereby reducing the anger factor of the pilots.
Main competitor: OS/2 airlines.
bzr airlines: Founded by a South African who had been injured by a curly brace on tla airlines, bzr airlines aims to be “tla done right”. They have shortened the jetway, gotten rid of the curly braces, chased out the philosophers, and no longer have a vision of merging with the stars. Many that were injured on tla airlines fly bzr airlines, and out of respect for tla airlines, bzr airlines will still honor tla tickets.
bzr passengers consider themselves part of an exclusive club because each flight takes off from a launchpad. They often can be seen standing in the terminal passing out bzr literature, trying to get passengers of other airlines to fly bzr, and can’t understand how other airlines continue to exist while people keep walking past their airplanes.
Main competitor: BeOS Airlines.
Bitkeeper Airlines: One of the world’s faster airlines, Bitkeeper airlines occupied that obscure gate for rich people at the end of the terminal for many years. Tickets on Bitkeeper Airlines were rumored to cost thousands of dollars, and were rare and jealously guarded. Then for awhile, Bitkeeper Airlines started giving away tickets for free, though they also kept around the expensive tickets for those with discriminating tastes. Free tickets were made widely available, but the 3-point type on the back of tickets said that you were never allowed to think about another airline before, after, or during your flight, and some people claimed they actually saw the small print morphing right before their eyes.
Bitkeeper flights often featured arguments over whether people were harboring secret thoughts of other airlines. If you were caught thinking about another airline, you were expected to scream vigorously while being thrown out the escape hatch without a parachute. All of this commotion tarnished the rarified air that the rich people paid to experience, so one day it was decided that there would be a Great Purge, because obviously all free ticket holders had harbored lustful thoughts of other airlines, so they were all thrown off the airplanes simultaneously. Today, people aren’t exactly sure where the Bitkeeper gate is, but everyone suspects it still lurks somewhere.
Main competitor: SCO Airlines.
Mercurial Airlines: The “there’s one right way to do it” airline, Mercurial is a sterile, agile, and shiny airline. Every Mercurial airplane looks identical to every other one, shiny and clean. You could swear that all the passengers look alike too, and as you approach the gate, it seems like you too look like everyone else. Mercurial passengers tend to be a happy bunch, who can’t comprehend anybody that flies Git Airlines. Specks of dirt and dust confuse the pilots, so it is best to make sure you have showered before boarding. It is rumored that, through bolting on more engines, some Mercurial airlines can fly to as many places as Git airlines can, but most Mercurial passengers are content to not worry about that.
Main competitor: Python Airlines.
Git Airlines: The “there’s more than one way to do it” airline, Git flies the world’s largest and fastest airplanes. Git Airlines was founded by some priests who were flying for free on Bitkeeper Airlines and survived the fall after the Great Purge. Git airplanes start as spartan, empty cabins, with no carpeting, chairs, or piloting controls. At the departure gate, each passenger is handed a bag containing 173 standard airplane components, accompanied by a 4×5″ sheet of information on the theory of flight, written in 1950. Once onboard, the passengers use these components to finish out the airplane for flight: installing chairs, rudder controls, etc. Every flight results in a plane assembled in a different way, and passengers on each flight believe they are flying the world’s best airplane. Arguments in the terminal after a flight are common, as passengers from different flights debate the merits of their particular design.
Despite all this, Git planes turn out to be safe, and Git passengers believe they get to their destinations in half the time it takes any other passengers, though sometimes they secretly wonder if the Mercurial flight got there faster. Occasionally, passengers on Git airlines build an airplane that appears to go into a tailspin. When that happens, they simply assemble a tool that lets them go back in time and change history so that it doesn’t crash, although it is rumored that if you are a member of the public watching this happen from the ground, it will lead to seizures.
Git airlines takes special pride in the one piece that passengers don’t have to assemble: the plumbing. Every Git lavatory is equipped with state-of-the-art never-fail plumbing, and the best porcelain washroom fixtures money can buy. None of these cheap plastic toilets like you get on every other airline. Here, we have fine porcelain fixtures.
During a flight, after passengers use the lavatory, they frequently get into arguments with each other about which style of porcelain toilet is the best. These arguments are only resolved by the Zen-like Git Priests, who insist that only inferior passengers need to use a toilet while in the air.
Main competition: Perl Airlines.
I’m really liking this.
So I set up some Git feature branches to help get Redmine patches from their BTS into their SVN trunk faster. (I don’t know why, but it seems to take a *very* long time for that to happen.)
Each BTS patch gets a Git feature branch. My Git repo for this project has about 21 branches in it.
So, I pull upstream into a branch called, well, upstream.
Each feature branch is created off upstream.
Then, the master branch merges all the feature branches in. I wrote a simple git-merge-fb shell script that just runs git-merge for each feature branch. Very simple. I expect to have a git-pull-fb script of some sort that merges upstream into each feature branch when I update against upstream. It could also run a diff at the end to see if there is any difference remaining, and if not, delete the branch.
It’s trivial to give an updated diff to upstream for any given patch: git diff feature-blah..upstream will do it.
I only wish gitweb had a way to do that so I could just hand out a URL that always corresponds to the latest diff against upstream for a given feature. Now that would rock.
A few days ago, I discussed Trac and Redmine. Redmine is a project management tool, similar to Trac, with built-in download tools, bug tracking, etc.
Redmine has a lot of nice features. Chief among them is better integration between multiple projects, so I don’t have to go to 17 separate pages to see the open bugs on my projects.
But I’m worried about the Redmine community. It appears to live in an insular Ruby world, without much participation outside. I wrote about some of those concerns in their forums. I’ve also submitted bugs to Redmine, some with patches.
Also, it’s concerning that, although Redmine includes a very nice forum module, the Redmine forums are still on RubyForge. Also, there are many bugs in the Redmine BTS that have patches but little, if any, comments from the Redmine people that have commit access.
It could just be that Redmine is a fairly new project and just needs some time to get on its feet more. It’s been around since July, 2006, which isn’t all that long on the one hand… or quite awhile, depending on how you look at it.
The git support patch for Redmine looks very nice. However, after a month, it still hasn’t been replied and there’s no indication why. Which also is troubling.
So I think I’ll sit with Trac for a little while until I get a better feel of how Redmine is progressing.
As of today, hg.complete.org is no more. I have removed mercurial and hgwebdir from my server, removed hg from my DNS zone, and converted everything that was in Mercurial over to Git. (Except for hg-buildpackage, which I have orphaned) So there is now stuff at git.complete.org.
I still have a ton of Darcs repos to convert, which will take more time.
Also I have heard a lot of people say that the GitPlugin for Trac is not very good. I have two Trac instances running it: one for commithooks and another for ListLike. Both seem OK so far, but I haven’t pushed them very much yet.