Search Results: "ron"

14 August 2006

Gunnar Wolf: 1st Debianmexico bug squishing party!

We had a very nice day of work, following Rodrigo's BSP invitation to the debianmexico list. The day started at 10 AM, when Rodrigo and I arrived to Nul-unu. After a small time setting up some cables and some coffee, we sat down and started working our way through the BTS. Soon afterwards the rest of the crew arrived. We were seven people. We spent the day not only bug-squishing, but giving informal talks and one-to-one lectures on how Debian's processes work, on how the BTS (and the BSPs) work. The bug list is not impressive, and they were not very difficult bugs to fix, but it's a very good step towards establishing a working, strong Debian community in Mexico. We closed bugs #379589, #382715, #374663, #380872, #382399, #382322, #382096, #335765, #368745, #368207, #382039 and #381130. There is a document in preparation, as ngel felt the need for a simple process documenting how to fix bugs, and there is even a video, that To o promised to have ready soon, for some definition of soon.
...Nice chat, nice company, entertaining Sunday. And nice way to wish a happy birthday to Debian, even if it is a couple of days in advance.

13 August 2006

Clint Adams: Waiting for something to break

Looking out over Toronto from the top of the CN Tower, and still running for public office, I realize that I have taken several actions in my life for which I owe public apologies. Once, I blamed the entire history of Middle East politics on a hapless middle-aged retard just because he said that he liked malls. He is currently awaiting trial at the International Criminal Court in rainy The Hague. I would like to apologize to the people of the Netherlands for my part in inflicting an American on them. When I was 55, I strapped a large snowboard to each foot and sat in the middle of a narrow trail in Vermont, just to be a dick. I would like to apologize to all the skiers who injured themselves fatally in attempts to avoid me. Four hours later, I tried the same on a mountain in Utah. I would like to apologize to the American people for failing to injure any Mormons in that endeavor. In order to console myself, I broke into a beer brewery and upped the alcohol content to 4% by weight, in contravention of state law. I would like to apologize for wasting alcohol on the people of Utah. When I was three, my cousin hung up on an imaginary phone call with Mr. President and proceeded to place an imaginary phone call to Mr. Government. I became so overcome by stress from her antics that I cast away her mock aloe, peddled my tricycle to Boston, and pissed all over the First Church of Christ, Scientist. I would like to apologize for not having waited several years in order to piss on some Scientologists instead. I would like to apologize to Uncle Bill for having dragged his name into this blog entry, especially in such close proximity to the Scientologists, who hate him with aplomb. I would like to apologize for having re-enacted this episode every month since then, despite the protests of Mr. "I-am-not-a-Jew" Schwartz et al. Several years later, I defecated on the streets of Hoboken, Jersey City, Atlantic City, and Camden during rush-hour traffic. I would like to apologize for not doing this in every city in New Jersey (Newark in particular). Last month on a flight to Dar-us-Salaam, I noticed that Steve Martin was sitting across the aisle from me. While he was sleepily drooling into his pillow, I swiped his notebook. I would like to apologize to Steve Martin for plagiarizing this blog entry verbatim. I would also like to apologize for having sex with his wife Karen seventeen times. I would like to apologize to Karen for having sex with her three times without her consent, and I would like to apologize to both Steve and Karen for having sex with their children while pretending they were members of the Plimpton family. I would also like to apologize for having sex with their elderly Hawaiian turtle, whom I mistakenly believed was dead. In 1981, I dined at Sammy's Roumanian Steakhouse while wearing a purple zoot suit with a silver see-through mesh tank top. I would like to apologize to the Romanian people, the denizens of Chrystie Street, the City of New Orleans, the poblano farmers, the shiksa that gave me a lapdance, and the marmot named Stu who saw the pictures on the website of a Jewish dog rapist and promptly choked to death on his own vomit. In 1987, I dined at a Benihana with a girl who would later get tattoos and piercings. We sat at a hibachi with a truckload of Italian tourists who spoke no English at all. I would like to apologize for laughing hysterically at them when one asked, Du sprichst Deutsch? , and for getting blood all over the teppanyaki when I slit their throats after another asked, Quel pays ? On New Year's Eve in 1989, I dined at the same Benihana with a different girl whose command of Japanese was incomplete. When a middle-aged drunken British woman jammed her tongue into my mouth, a Brooklyn school bus driver laughed at me. After leaving the restaurant, he offered me a Werther's Original candy to get the taste of old woman out of my mouth. I would like to apologize for following him home and forcing him to watch the same episode of Full House over and over again for 37 hours. I would also like to apologize to Girl Scout Troop 5166 for calling them a bunch of stupid whores. While they still are a bunch of stupid whores, there was no way I could have known that at the time. Furthermore, when I was growing up, the term stupid whore approximated the use of Khidir beneath Momouteh and Shaka, when the walls fell. Finally, I would like to apologize for making a Star Trek reference when I could have said that thing about porchmonkeys instead. Now on with the campaign!

12 August 2006

Daniel Burrows: Giving away secrets

Erich Schubert writes that


Oh, and I actually doubt that ATI would give away much secrets if it would allow distributing the existing opensource X drivers. It's not as if the specs of their CPU would be a huge surprise to Nvidia. Some actually say nvidia builds the better graphics cards. And Intel does even give away source code. We're not talking about chip design here, or driver optimizations. Just the plain registers and ports.


-- note: what follows is just my opinion and I'm wrong on a regular basis, so take it with a grain of salt --

The problem here is you aren't thinking like a corporation. As far as I can figure, the corporate view here is that you have two options:

(a) Keep the secrets you have. This is the status quo, you know how to make money here, and no-one else can benefit from your secrets even if you yourself can't.

(b) Give away your secrets. This always carries a risk that someone else will find a more clever (=profitable) way to use your secrets than you; thus, companies try to avoid this unless they absolutely have to.


I personally agree that the risk to ATI appears small. However, just to throw out a hypothetical, giving away their register specs would allow other companies to build cards that are register-compatible with ATI's. (Remember the ne2000?) Obviously this would be good for you and me -- but it's almost certain to drive down ATI's profits at least a little by providing more direct competition in the market for graphics cards; thus it's not good for ATI. This may be a far-fetched or overblown concern, but ATI will need a reason to "go uphill" against it when their current strategy seems to be doing just fine.

Intel, on the other hand, is in a different situation; as far as I know, they generally are playing catchup in the graphics area to NVIDIA and ATI, and as a result, they have more to gain and less to lose by opening their specs. [UPDATE] And as I mentioned in my previous post on this topic, the types of cards Intel sells are probably more interesting to free software users than the cards ATI sells. (I'm sorry you don't have any Intel cards -- they seem to have come automatically with most of the new computers I've seen lately, so I assumed it was a trend!)

Daniel Burrows: Explaining Network Neutrality

One of the problems with network neutrality is that people outside the technology industry often can't follow the arguments back and forth because of the complexity of the terms involved. On my vacation last week, I found myself discussing this topic with my ~80-year-old grandparents. Now, Grandpa and Grandma have no clue about technology, but they aren't dumb; they are both retired educators and follow current events (especially politics) with a strong interest. In my effort to explain just what the fuss is about, I had a sudden brainstorm and came up with the following analogy, which I post here for anyone who cares to use it:


Imagine that your power company decides that it wanted to open a line of supermarkets. At the same time, it sends out an announcement that supermarkets (due to their refrigeration requirements) are particularly heavy users of the electrical system, and as a result, the power company will add a 15% surcharge to the power bills of any building that it deems to be a supermarket. Of course, the power company's own supermarkets are exempt from this fee. When the existing supermarkets complain, the power company says that they're asking for special treatment and trying to get electricity "for free" and that if they don't like its terms, they should buy their power from someone else.


Obviously this greatly simplifies the technical issues involved, but it's the best illustration of at least one aspect of the problem that I've been able to come up with. I've enabled comments for this post, so feel free to add your own suggestions.

Evan Prodromou: 25 Thermidor CCXIV

Maj went out for her birthday party with a passel of ladies, so I stayed home and ate pizza and watched Twelve Monkeys with the baby. We had a good time, but as the baby is approaching 1 years old, my going-to-sleep tricks are becoming somewhat outdated. My main way to put the baby to sleep is to walk her from the front door of our apartment all the way back to the laundry room, and then turn around and walk out to the front door again. I sing during the entire process, mostly Neil Young and Johnny Cash tunes, but also a mix of 80s pop, reggae, songs, and goofy children's songs. Really, it's anything I can remember the words to, or that I can bridge over with some ad-libbing. This worked pretty well when she was teensy-tiny, and it's still the best way for me to get her to sleep. But as she's approaching 15kg, it's getting to be a serious workout for me to slog up and down the hallway 50 times belting out Take the Skinheads Bowling at high volume. We have a few baby books on how to get a child to sleep easier, but I've been taking the path of least resistance. I'll probably have to take the plunge and get her to fall asleep in bed soon -- which will probably mean some angry baby moments. Still, putting the baby to sleep is one of the most satisfying things in my life right now -- I highly recommend it. tags:

Programmer hierarchy Luke Welling's programmer hierarchy, based on The Brunching Shuttlecocks' classic Geek Hierarchy, is humorous and accurate. tags:

Tag improvements So, I've made some improvements to the tagging system on this blog. Instead of doing a full-text search at runtime to lookup which pages contain which tag, I instead keep a map of tags to page names in a separate db, and then look up in that index at runtime. The bummer is that I'm not figuring out a way to keep that db up-to-date easily. The best action, of course, would be to have the tags db updated at write time, but I can't figure out how to make that work. I tried it with a write macro, but you can't get the title of the current page with a write macro, unfortunately. I might just add a hook to the commit action -- that's about all I'm coming up with right now. It's annoying that Wiliki doesn't have hooks enabled anywhere. Gar. tags:

Steve Kemp: I ll be so alone without you

My migration to the new Xen host is 75% complete. DNS changes appear to have finished and I’ve moved all the websites that I intended to move successfully. (Including databases & etc.) I’ve got three domains to move still, but I’m being very careful with them since they tie into “local” things like CVS repositories, or mailing lists + archive creation. The website migrations appear to have been a success, although I only noticed a couple of problems just now. In all cases my problems were: I’ve tested all the areas I can think of testing now. (e.g. “find /home/www -name ‘*.cg’ -print”; then executing each one in turn!) The next job will be the mail setup. My plan:

11 August 2006

Erich Schubert: XFS woes

I'm going to join madduck, Gunnar Wolf and Julien with their negative experiences with XFS. The celeron 412 I mentioned before had an XFS filesystem since a few years. It replaced a raisswolffs. It certainly worked better than raiser. But as said, that old machine has been crashing, and when I copied over the data for my dad to his new machine, I noticed that his .gconf file was destroyed by XFS. All 0-bytes, typical for XFS. If the file is damaged, just fill it up with zeroes? I've seen 0-bytes a couple of times before in log files on XFS partitions that were open during a crash. It sucks that gconf didn't keep a backup. Anyway, the .gconf file includes his evolution configuration, amonst other stuff. Thats how we noticed (apart from all other gnome settings being gone, too), since restoring evolution was the top priority item for me. Fortunately, I picked ext3 when setting up the new system. I never had experiences with ext2 or ext3 as bad as with xfs. Or reiserfs, which just trashed the whole filesystem when I ran "reiserfsck". Thats not what a fsck is supposed to do, is it?

Uwe Hermann: Free Software News and Advancements

No, I'm not dead, just very very busy... There have been quite a few interesting new Free Software projects and news popping up recently (or I only recently noticed them):

Zak B. Elep: ntfs-3g Love

Yesterday I was back again at the Parish to continue working on arete, the newly-installed Ubuntu Dapper machine. I was back because I had to continue migrating my father’s files from Windows to the new setup, since he wanted to try out Scribus as a replacement for his MS Publisher system for writing the parish newsletter. Anyhow, this reason, coupled with my own urge to seriously try out Ubuntu Dapper (I was running Kubuntu Dapper, doh) made me spend the whole day trying out something new. ;-) As I was looking at Dad’s documents folder, I realized that I had a problem: there are so many files here, some of them sizing up from tens to hundreds of megs (actually, stuff worked on thru the Gimp,) and knowing well that disk drive space was at a premium (arete had an 80G drive, yes, but nevertheless its already cramped,) I simply couldn’t accept copying the files from the XP’s NTFS C:\ to arete’s ext3 /home. Moving wasn’t an option either; although Dad would very much like to try out Ubuntu, he still had some projects (especially the newletter) that needed, uhm, proprietary software to work (sigh.) Thus, remembering that Linux already had some way of reading NTFS partitions, I promptly Googled about it. I also knew that the Linux-NTFS guys (who made the ntfsprogs suite and kernel module) were already working on getting full read/write NTFS support on Linux, but it didn’t occur to me that they were able to get a working implementation done so soon… Enter ntfs-3g: the third generation Linux-NTFS driver. Weighing in at around 550K, this seems to be the one thing that I need for my problem. From the looks of it, ntfs-3g can both read from and write to NTFS partitions, allowing one to create, delete, and update files and directories on the system; it can even allow access to certain metadata that even Windows XP hides from its users. Furthermore, its built from the ground up as a filesystem-in-userspace driver, using the Linux fuse subsystem. It certainly looks very attractive indeed. So, being the sysadmin for arete that I was, I quickly decided to give ntfs-3g a try. After all, it was a simple matter of grabbing the tarball, then reading the README, then doing the three-step tango of ./configure; make; sudo make install, then calling ntfs-3g /dev/hda1 /media/hda1 -o umask=007 as root. Right? Wrong. I quickly ran into a trio of subproblems: first, I needed fuse (>= 2.5.0); the one Dapper had on its official archives was 2.4.2 . So, naturally, I had to make a quick backport of the fuse source from Edgy (2.5.3), but I at this point I ran into the second problem: for Eggy’s fuse to get busted, I needed the new makedev (2.3.1) as well. Forgetting to do apt-get -f install for the moment, I grabbed Edgy’s makedev and proceeded backporting it, which ran me against the last problem: I also needed the newest sysvinit (2.86.ds1). In short, I needed to do a trio of backports first before being able to build ntfs-3g. My own fuse was almost ready to explode. Fortunately, everything went fine after the backports (thank goodness for my being a Debian package maintainer and MOTU,) so I didn’t break my own fuse after all. Soon after, I was reading and writing stuff to and from /media/hda1 without so much as batting an eyelash. Dad was definitely pleased, since that meant that he no longer had to dread the thought of having to maintain two separate document trees and cause him pain and gnashing of teeth. I was glad too, since I no longer had to dread the thought of having to hack on this today, causing me to disrupt my Summer of Code schedule. But, being the packager that I was, I realized that I could make the world a better(?) place by turning ntfs-3g from a regular Joe source to a real Debian/Ubuntu package. While I was happily waiting for ntfs-3g’s build to complete, I happened to pass by a certain HOWTO on the Web using pre-built fuse and ntfs-3g Ubuntu packages. I grabbed those packages, and took a look at them, and while they were pretty much useful, the ntfs-3g package certainly did not look to pass the gold(?) standards of Debian and Ubuntu: the ntfs-3g package was a single binary package, shipping both a shared library and its headers, coupled with the working binaries. It had outdated FSF addresses too, which my bugging Lintian pointed out to me. With some more extra time to spare on arete, I decided to go ahead and build proper a proper source package for ntfs-3g, producing the three binary packages ntfs-3g (containing ntfs-3g and mount.ntfs-3g,) libntfs-3g0 (depended on by the former package,) and libntfs-3g-dev (containing the include headers.) CDBS and debhelper definitely made this easy pickings, and made my life with ntfs-3g easier. And, I’m going to make everyone else’s life with ntfs-3g easier, by making this package available for nit-picking. ;-) I won’t pretend this to be getting into the official Debian and/or Ubuntu archives for the moment, since the upstream authors have explicitly stated that ntfs-3g will be eventually merged into the existing ntfsprogs suite, thereby making my packaging of ntfs-3g obsolete sometime soon; furthermore, the binary packages up there are built against Debian unstable and Ubuntu Edgy, so anyone looking for a Dapper solution can read this post first to avoid reinventing the wheel. But if anyone needs a good solution for NTFS read/write right now (or, if somebody else has time to kill in testing ntfs-3g,) then here’s a good one for you. Caveat emptor!  Ok, next up: finishing my SoC work…

Julien Danjou: Novell and RedHat fighting about Xen

Some days ago, RedHat claims that Xen is not ready yet for production environment. Now, Novell strikes back and defend their inclusion of Xen in their latest SUSE release. That's so funny, because in fact they don't give any concret argument. RedHat says that it's not mature, and Novell just answers that they've contributed to the code. As a member of the Debian Xen team, I'll arbitrate between us. Xen is nowadays deployed in a lot of solution and in a lot of system architecture. I don't think this is because the Xen technology is mature, but only because it's the solution which fit the best the need of virtualization (and cost rationalisation) that organizations may have. Xen can not pretend to be stable, mature, or whatever you want, because it is still not integrated into the Linux kernel tree, and thus far for a good reason: the API/ABI is not yet stable.
I know that in theory it is, but in fact it's quite wrong and you cannot rely on that specification. Xen works fine but from a developer point of view it is not in a stable and fixed shape. It seems that Linus and others kernel people are not very happy to integrate directly Xen into the mainline kernel, and I can understand them, since this technology is rather new. I don't think Xen will be a suitable solution which can be deployed for years until Linus decide to integrate a virtualization system into the Linux kernel. Furthermore, Xen is still a huge source tarball of mess with a big kernel patch. And even if I really think that Xen will be the adopted solution for everyone, it won't be in its current state. So, I think RedHat is pretty right. Just think about the Xgl/AIGLX stuff, that's quite again the same behavior between this two companies.

Lucas Nussbaum: Ubuntu or Debian, which one has the newest software ?

It is a common belief that Ubuntu provides newer software than Debian. This is of course true when Ubuntu is compared to Debian stable. This is also true for specific software packages, like Gnome. But how does it compare in general ? At the time of the Dapper release, here is how Ubuntu Dapper and Debian Unstable compared wrt source package versions :
In Ubuntu, but not in Debian: 1795
In Debian, but not in Ubuntu: 588
Exact same version: 4361
Same upstream version: 2963
… and same Debian version, but Ubuntu has local changes: 731
… “Debian version” newer in Debian: 2197
… “Debian version” newer in Ubuntu: 35
Different upstream version: 2166
… newer in Debian: 1955
… newer in Ubuntu: 211
So Debian easily wins. But this comparison is unfair, because Debian unstable is a moving target : of course, it’s newer than Ubuntu ! What about Debian testing ?
In Ubuntu, but not in Debian: 2137
In Debian, but not in Ubuntu: 514
Exact same version: 4529
Same upstream version: 2652
… and same Debian version, but Ubuntu has local changes: 775
… newer in Debian: 1816
… newer in Ubuntu: 61
Different upstream version: 1967
… newer in Debian: 1666
… newer in Ubuntu: 301
Yes, Debian still wins. Okay, but Ubuntu Dapper had a particularly long release cycle. What about Ubuntu Breezy, and Debian Testing at the time of the Breezy release ?
In Ubuntu, but not in Debian: 2462
In Debian, but not in Ubuntu: 384
Exact same version: 4586
Same upstream version: 2253
… and same Debian version, but Ubuntu has local changes: 981
… newer in Debian: 1172
… newer in Ubuntu: 100
Different upstream version: 1375
… newer in Debian: 1020
… newer in Ubuntu: 355
Debian testing wins again. Notes: Update: Yes, Scott, I am comparing stable releases on one side, with development versions on the other side. However, I think that it is widely known that Debian testing is usable outside of the Debian development community. I know many people using Debian testing who aren’t Debian developers. And many Ubuntu users, if they weren’t using Ubuntu, but Debian, would probably use Debian testing, not stable. Regarding Ubuntu Edgy, its use is currently strictly limited to the Ubuntu development community, and I don’t know anybody not interested in Ubuntu development running Ubuntu Edgy (that’s also because Ubuntu is released every 6 months, not 18 months, of course). That’s why it’s irrelevant to compare with it.
Also, after a quick poll on IRC, I discovered that many Ubuntu users thought that Ubuntu stable releases had newer software than Debian Testing (that was my exact question). The only point of this blog entry is to prove them wrong. Update 2 : I’ll be on holidays for the next few days, so comments are put in the moderation queue until I come back.

Aigars Mahinovs: British rural public transport

I am writing a collective article about all thing I hate (and a few I like) in UK, but this is too important to let it slide until then - I hate British public transport.
Background information: I live in Cranfield village (ZIP code MK43 0JN, look it up) right in the middle between Milton Keynes and Bedford. Last bus from Milton Keynes to Cranfield leaves MK at 19:20. Last bus from Bedford to Cranfield leaves at 22:40. None of them is late enough for my taste, but most importantly none of them is synchronised with other transport, like trains from London.
The Story: today the sponsors of my Masters project were meeting with a technical evangelist from Google and invited me along to a pub in London. I planed my journey via Bedford. The meeting went well, the time flew by and I found myself taking a Midlands express back to Bedford that left London’s St. Pancras station at 22.00. Needless to say I missed the last bus to Cranfield by 3 minutes. Wonderful.
Of course the good thing was that I had done this walk once before a few weeks ago, when I was returning from getting my new laptop from Newcastle. Then it was a backbreaking 4 hour walk along a highway with a 10+ kg backpack and almost no water. This time I was more prepared - I knew the names of the villages in the area and knew the directions better and I had less weight with me. I also discovered a number of shops and take-away places that were still open at that hour (a rare sight here) and manged to get a sandwich and a bottle of water for the trip. I took a few safe shortcuts and in the end came home in just over 3 hours.
But still that does not change the fact - British public transport sucks, especially in rural areas.

John Goerzen: Whose Distributed VCS Is The Most Distributed?

Lately I have been trying out a number of distributed version control systems (VCS or SCM).

One of my tests was a real problem: I wanted to track the Linux 2.6.16.x kernel tree, apply the Xen patches to it, and pull only specific patches (for the qla2xxx driver) from 2.6.17.x into this local branch. I wanted also to be able to upgrade to 2.6.17.x later (once Xen supports it) and have the version control system properly track which patches I already have.

But before going on, let's establish what it means to be an ideal distributed VCS:


There are also some things that we would generally want:



Evaluation

Let's look at some common VCSs against these criteria. I'll talk about Arch (tla, baz, etc), bzr (bazaar-ng), Darcs, Git, Mercurial (hg), and Subversion (svn) for reference.

1. The fundamental method of collaboration must be a branch
All of the tools pass this test except for svn.

2. Branching should be cheap
Everyone except svn generally does this reasonably well.

The tla interface for Arch had a pretty terrible interface for this, so it took awhile simply due to all the typing involved. That's better these days.

Darcs supports hardlinking of history to other local repositories and will do this automatically by default. Git also supports that, but defaults to not doing it, or you can store a path to look in for changesets that aren't in the current repo. I believe Mercurial also can use hardlinks, though I didn't personally verify that. bzr appears to have some features in this area, but not hardlinks, and the features were too complex (or poorly documented) to learn about quickly.

svn does not support branching across repositories, so doesn't really pass this test. Branches within a repository are not directly supported either, but are conventionally simulated by doing a low-cost copy into a specially-named area in the repository.

3. Merging between branches is intelligent
Arch was one of the early ones to work on this problem. It works reasonably well in most situations, but breaks in spectacular and unintelligble ways in some other situations.

When asked to merge one branch to another, Darcs will simply merge in any patches from the source branch onto the destination which the destination doesn't already have. This goes farther than any of the other systems, which generally store a "head" pointer for each branch that shows how far you've gone. (Arch is closer to darcs here, though ironically bzr is more like the other systems)

Merging between branches in svn is really poor, and has no support for recognizing changesets that have been applied both places, resulting in conflicts in many development models.

4. Inividial changesets should be mergeable without bringing across the whole history
Darcs is really the only one that can do this right. I was really surprised that nobody else could, since it is such a useful and vital feature for me.

Both bzr and git have a cherry-pick mode that simulates this, but really these commands just get a diff from the specific changeset requested, then apply the diff as with patch. So you really get a different changeset committed, which can really complicate your history later -- AND lead to potential conflicts in future merges. bzr works around some of the conflict problems because on a merge, it will silently ignore patches that attempt to perform an operation that has already occured. But that leads to even more confusing results, as the merge of the patch is recorded for a commit that didn't actually merge it. (That could even be a commit that doesn't modify the source.) Sounds like a nightmare for later.

Arch has some support for it, but in my experience, actually using this support tends to get it really confused when you do merges later.

Neither Mercurial nor svn have any support for this at all.

5. Branching preserves full history
git, darcs, and Mercurial get this right. Making a branch from one of these repos will give you full history, including individual diffs and commit logs for each changeset.

Arch and bzr preserve commit logs but not the individual changesets on a new branch. I was particularly surprised at this shortcoming with bzr, but sure enough, a standard bzr merge from a remote branch commited three original changesets into one and did not preserve the individual history on the one commit.

svn doesn't support cross-repo branching at all.

6. Merging preserves full history
Again, darcs, git, and Mercurial get this right (I haven't tested this in Mercurial, so I'm not 100% sure).

Arch and bzr have the same problem of preserving commit logs, but not individual changesets. A merge from one branch to another in Arch or bzr simply commits one big changeset on the target that represents all the changesets pulled in from the source. So you lose the distinctness of each individual changeset. This can result in the uncomfortable situation of being unable to re-create full history without access to dozens of repositories on the 'net.

Subversion has no support for merging across repositories, and its support for merging across simulated local branches isn't all that great, either.

7. It is possible to commit, branch, merge, and work with history offline
Everyone except Subversion does a good job of this.

8. The program is fast enough for general-purpose use
All tools here are probably fast enough for most people's projects. Subversion can be annoying at times because many more svn commands hit the network than those from others.

In my experience, Arch was the slowest. Though it was still fine for most work, it really bogged down with the Linux kernel. bzr was next, somewhere between arch and darcs. bzr commands "felt" sluggish, but I haven't used it enough to really see how it scales.

Darcs is the next. It used to be pretty slow, but has been improving rapidly since 1.0.0 was released. It now scales up to a kernel-sized project very well, and is quite usable and reasonably responsive for such a thing. The two main things that slow it down are very large files (10MB or above) and conflicts during a merge.

Mercurial and git appear to be fastest and pretty similar in performance.

All of these tools perform best with periodic manual (or scheduled cron jobs) intervention -- once a month to once a year, depending on your project's size. Arch users have typically created a new repo each year. Darcs users periodically tag things (if things are tagged as part of normal work, no extra work is needed here) and can create checkpoints to speed checkouts over the net. git and Mercurial also use a form of checkpoints. (not sure about bzr)

Subversion works so differently from the others that it's hard to compare. (For one, a checkout doesn't bring down any history.)

Conclusions
I was surprised by a few things.

First, that only one system actually got #4 (merging individual changesets) right. Second, that if you had to pick losers among VCSs, it seems to be Arch and bzr -- the lack of history in branching and merging is a really big issue, and they don't seem to have any compelling features that git, darcs, or Mercurial lack. #4 was a unique feature to Darcs a few years ago, but I figured it surely would have been cloned by all the other new VCS projects that have popped up since. It seems that people have realized it is important, and have added token workaround support for it, but not real working support.

On the other hand, it was interesting to see how VCS projects have copied from each other. Everyone (except tla) seems to use a command-line syntax similar to CVS. The influence of tla Arch is, of course, plainly visible in baz and bzr, but you can also see pieces of it in all the other projects. I was also interested to see the Darcs notion of patch dependencies was visible (albeit in a more limited fashion) in bzr, git, and Mercurial.

So, I will be staying with Darcs. It seems to really take the idea of distributed VCS and run with it. Nobody else seems to have quite gotten the merging thing right yet -- and if you are going to make it difficult to do anything but merge everything up to point x from someone's branch, I just don't see how your tool is as useful as Darcs. But I am glad to see ideas from different projects percolating across and getting reused -- this is certainly good for the community.

Updates / Corrections
I got an e-mail explaining how to get the individual patch diffs out of bzr. This will work only for "regular", non-cherry-picked merges, and requires some manual effort.

You'll need to run bzr log, and find the patch IDs (these are the long hex numbers on the "merged:" line) of the changeset you're interested in, plus the changeset immediately before it on the same branch (which may not be on the same patch and may not be obvious at all on busy projects.) Then, run bzr diff -r revid:old-revid-string..new-revid-string.

I think this procedure really stinks, though, since it requires people to manually find previous commits from the same branch in the log.

10 August 2006

Erich Schubert: Going AMD64

Up to now, my dad was using my old desktop PC, a celeron 412 MHz (366 overclocked) with Linux. Unfortunately, this trusty companion started to freeze within a few minutes after boot (even in BIOS). So after some 7 years, a replacement was needed. The guys at the computer shop (Computer Gallerie in munich) tried to convince me that nvidia is best for Linux. Basically I followed this recommendation because ATI isn't better, and there are not Intel-based onboard graphics for AMD. And AMD Sempron sounded like the cheapest CPU. And definitely cheaper than an Intel Core... But dudes: Nvidia is NOT included in the kernel. Trust me on that one. Nvidia is non-free, and their drivers most likely violate the GPL. So I ended up buying an ASRock 939NF4G-VSTA mainboard and an AMD Sempron CPU. 1 GB of RAM, an HDD, an okay housing. Just below 400 Euro, that is what I had expected. After some fighting with the hardware (the HDD didn't fit into its slot, I had to bend away some metal. No docs on which way to put the power LED plug on etc.), I was finally able to boot the system. I used todays daily-build of the netinstall CD image for AMD64. I.e. the to-be etch installer. Worked like a charm. After some downloading over my 2 mbit DSL line the system was up and running. Graphics were VESA, as expected. With some fighting with the annoying non-free Nvidia drivers, I had them working, too. Ethernet worked out of the box; I don't know about S-ATA (a driver is loaded though), temperature sensors seem to work, too. Sound doesn't work yet. The snd_hda_intel driver is loaded, however there is no sound to be heard on any of the 7.1 channels. The mixer only shows "Master" and "Capture" volume controls. If anyone knows how to get sound out of a 
00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)
Subsystem: ASRock Incorporation Unknown device 0888
device, I'd welcome any hints. Kernel is 2.6.17-1-amd64-k8. Maybe I just have to get a newer Alsa with some hardware information on this device? [Update: this is a realtek ALC 888, there is a patch for this to come in 2.6.18...] Anyway, I now have a AMD64 box, and as soon as I've setup some i386 chroot I'll have a useable build-box after all. ;-) And maybe I can do some SELinux testing on it, too. OTOH, I should get myself a diploma thesis topic now, and work on my final thesis.

Martin F. Krafft: Blackouts and encrypted filesystems

After some recent filesystem fun, I now have a laptop with encrypted partitions, using dm-crypt and LUKS, conveniently installed with partman-crypto. Pre-Scriptum: I have updated my previous post about XFS troubles in response to Ingo's statements. Just in case you care... The following post poses a question and a meta-question: As I was cycling home today, I thought about what would happen if my laptop lost power now in the middle of a write operation. Sure, ext3's journal would make sure the filesystem was consistent, but what about the actual data on the disk? Journaling works by writing a change to the journal, then writing it to disk, then deleting the enty from the journal. If the filesystem is mounted and it has entries in the journal, those are "played back", meaning they just get written to disk again, overwriting potentially incomplete data written as the power was lost. Yes, this is simplified, but it'll do for now. With encrypted filesystems, there's an important layer between the filesystem and the physical storage: the encryption algorithm. An encryption algorithm like AES works on blocks, by default 64 bytes in size. 64 bytes are not a whole lot, but given the nature of hard drives, it's not possible to write 64 bytes to the drive atomically [*]. Thus, conceivably, it could happen that your power cuts out after only 32 bytes have been written. I don't believe dm-crypt does journaling for the encrypted data it writes, so effectively, a power loss on systems with encrypted filesystems almost certainly means data loss? Please correct me if I'm wrong! And the meta-question would be: where would I go to discuss such issues? I've abused debian-security previously, the issue seems too general for the dm-crypt mailing list, there is cryptography t metzdowd.com but somehow this does not seem to be a crypto problem... so where would you take this? Let me know...
[*]

In a computer architecture course in college, the prof raised the interesting point that between the loss of power and the actual disappearance of all current in the circuits, several million operations are possible on modern machines. I have not yet heard of any computer or hardware device making use of those precious cycles.

Update: actually, several manufacturers are making use of the precious cycles. See for instance this post, which describes some stuff done by SGI. Hanspeter Kunz also adds that harddrives use this time to park their heads.

Martin F. Krafft: Through with XFS

I am through with XFS, once and for all. Well, at least for laptops. I still think it's a good filesystem when you can ensure that the power never goes, and your hardware is reliable, but it's just not adequate for laptops or even desktops. I ran into some serious problems a while ago, but managed to recover. Two nights ago, however, three XFS filesystems on my laptop decided to blow up and left my system thoroughly broken. I guess as the hibernate maintainer, I should really start doing my tests somewhere else than my main system... It all started out with a dist-upgrade and this output: 
dpkg: error processing /var/cache/apt/archives/dpkg_1.13.22_i386.deb
(--unpack): unable to make backup link of
'./usr/share/man/man1/dpkg-deb.1.gz' before installing new version: Unknown
error 990
Looking at /usr/share/man/man1, I started to anticipate the apocalypse: 
# ls -l /usr/share/man/man1
total 7956
?????????? ? ? ?    ? ? ? 7zr.1.gz
?????????? ? ? ?    ? ? ? 822-date.1.gz
?????????? ? ? ?    ? ? ? CA.pl.1ssl.gz
?????????? ? ? ?    ? ? ? Defoma::Common.1.gz
So I look at the log, and amidst kernel oops notices, there's this lovely cookie: 
Filesystem "hda6": Corruption of in-memory data detected.  Shutting down
filesystem: hda6
Filesystem hda6 is /usr, so at that time I figured "it could have been worse", booted to single user, and remade the filesystem with the intention to simply reinstall all packages... when I found /var/lib/dpkg/info to be in similar condition. The rest of /var seemed fine, but I resolved then that there was no hope in reviving this system. Fortunately I brought an external drive that had just enough free space to hold my /home and some other stuff, but since USB is really slow when it comes to shifting large amounts of data, I decided to do something productive in the mean time and to answer some outstanding mails. It wasn't difficult to get SSH back up, so I started to work on a remote machine and used the time efficiently. Some time later, though, I got confused in the mist of screen sessions and was browsing my home directory on the laptop, thinking I was elsewhere (my home directories are mostly synchronised), when I noticed a directory in similar condition as the above. Oh shit. Imagine my pain and fear as I first thought my remote machine was also dying, imagine the sigh when I found out I was on the local filesystem, and imagine the shock when I realised that /home was also affected by the XFS breakage... A glance around /var confirmed that the XFS breakage was actually spreading and had now affected three filesystems on this machine. Fortunately, by that time, I had copied everything to the external drive, and decided to put my laptop and myself to sleep. I woke the next morning to the task of reinstalling the thing and decided to be optimistic about it. After all, a reinstall would mean I could finally try partman-crypto and encrypt my laptop's data to protect against leaking sensitive stuff in the case of loss or theft of my laptop. The installation was not as painless as I had hoped, but that was mainly because I ran into a known problem with the graphical installer and partman-crypto, which does not allow to set up volumes with random encryption keys (e.g. swap; see the forthcoming announcement for the beta3 release of the installer), and a bunch of smaller bugs. I had to restart the installation with the traditional frontend to get what I wanted, but other than that, I was very impressed with what our installer development team has accomplished! And a special round of gratitude to Frans Pop for not losing his patience while helping me on several occasions throughout the process. Now, 24 hours after the incident, I am back to normal with a fresh laptop and no data lost (except for one directory which I pulled from a mirrored remote machine; it had no local modifications (so why did XFS screw it up anyway?)). The fonts are all jaggy, so there's something I have to figure out. All things considered, I am sad to have lost 24 hours, but I can also relax more now, without fear of further XFS breakage or loss of private data. Update: Oh, and despite this, I did choose ext3 for all my laptop's filesystems. JFS was really cumbersome and slow last time I tried it, and I surely would not touch RazorFS after experiencing serious data loss on numerous occasions. Update: Two responses so far. Full ack for Julien (except for him laughing at me), Ingo's post warrants a reply though. First, ext3 is also journaled, and if you're about to say "yeah, but it's a hack on top of ext2, well... ext2 is damn mature, and journaling isn't really rocket science, so that "hack" isn't going to be too complicated. In fact, I like the idea of journaling being an option rather than a built-in feature. Second, of course you're supposed to keep backups. But since you keep backups, my top requirement of a filesystem is not "how to get the data back", but "how to ensure it does not break. If it breaks, I can reinstall and restore from backup, but that's a certain amount of time lost. If it doesn't break, well, that's like stealing a little something back from death then, isn't it? Third, I do follow the linux-xfs mailing list, but so what? I did not have write cache enabled, and I was running the 2.6.17.7 kernel at the time of the mishap. Lastly, you point to "excellent tools" to recover the filesystem. I am not sure how excellent xfs_repair really is when it reports "bad magic number 0x0 on dir inode 4696727" during the run, claims to have fixed it, I mount the filesystem, unmount it, run xfs_repair again and get the same message. No filesystem is perfect, and as we know from Biella's problems (among many others, ext3 is no exception. But we did get her data off! So then it's really an open field again, crap filesystem against crap filesystem. I guess at this point it helps to know that ext3 actually follows VFS semantics, while on XFS, a completed sync() syscall does not actually mean it has written the data to disk (see e.g. #317479). And then there are bugs like #239111... ext3 it is for now. If that let's me down, I'll try JFS. If that fails and noone has actually implemented a proper filesystem, I might have a go myself. Haha. Update: Alceste Scalas adds:
Ingo is right when he says that every filesystem has bugs --- but bugs apart, the design of Ext3 (i.e. its physical-block journaling) makes it a far more reliable choice for desktop and laptop PCs, expecially for people without an UPS. An Ext3 filesystem could only crash because of a bug or an hardware failure, while an XFS filesystem can be trashed even without bugs or hardware failures, due to the unavoidable consequences of a power loss on PC-class hardware.
He also alerted me to this mailing list post, which compares data=ordered journaling of ext3 (which almost noone does for performance reasons) with XFS and RazorFS. Update: You may also be interested in this post. Update: Otavio Salvador points me to this FAQ entry, which SGI must have added very lately. It explains how to deal with the directory corruption that was part of my problem. I guess I would have liked to know earlier, but I consider the outcome with dm-crypt + ext3 a win anyhow.

Bernhard R. Link: Graphic Libraries

Wouter Verhelst asked why simple games are so slow nowadays.

I think the problems are in the libs. All this modern stuff tries to become more and more modern, and get more and more stuff out of all those new render extensions, direct graphics and hardware accelerations. There simply is no way to decide which way is faster, so libraries have to guess. So it is no suprise things go wrong. And the place they go wrong are of course not the fast computers, but the older stuff, that does not has those nifty accelerations and no fast CPU to cancel it out.

Another disadvantage are all those "portable" libaries. SDL for example needs three connections to the X server before it does anything. Three times etablishing a connection, checking of security cookies, and so on. Its API looks like living with windows, or never intended to be use for anything other than full-screen mode. (You want to find out how large the window is? Why should you be able to when you said the window cannot be resized?)

QT likes to use extensions, too. I don't know if it is its fault or newer X servers, but the newer your installation gets, the slower 2D games using QT can become. (Note the can, if you have the right graphics card, lucky you, if you have the wrong one, bad luck). To be fair QT is not supposed or designed for 2D games. On the other hand I don't know what it is supposed to do other than being a C++ compiler benchmark measured in hours.

GTK was such a promising design. Object orientated (widget classes are one of those very few things were object orientated can be used with more advantages than disadvantages) but still plain C, small and looking like designed for X. To be fair, I do not even know how well it performs, as the ever increasing library cancer drives me away. From the "users should not be able to change their homedir, that would be far too much the Unix way" glib, over all this miriad of differt little libraries, all moving all the time, spewing their headers in so many different directories a compiler invocation folds three time around your terminal.

Well, enough ranted. My next graphical program will use Athena Widgets. I only have to hope all this reanimated X development in the last time will not pull xlib away from under out feets in the future...

9 August 2006

Erich Schubert: AMD maybe to opensource ATI drivers?

Now thats what I'd call good news (URL from #debian-devel) This infoworld article claims:
AMD is strongly considering open-sourcing at least a functional subset of ATI's graphics drivers
Well, the article has some other facts wrong:
If AMD's graphics cards were the only ones with open device drivers, it might affect a buying decision or two.
Well, you know. There is not only Nvidia. There is Intel. And for both the R200 ATI Radeon series and the Intel video chipsets there are opensource drivers with 3D acceleration. It's not as if AMD/ATI would be the "only ones". Wait. Intel? Isn't that like the main competitor of AMD... AMD should better try to draw even! But yeah, if AMD would do that, Nvidia would have some issues selling their stuff to Linux users. Manufacturers that try to sell desktop linux computers will prefer AMD if it's better supported out of the box (for servers, neither ATI nor Nvidia is relevant, of course). For example Lenovo is reported to (plan to?) sell Thinkpads with SuSE Linux preinstalled (I'd actually prefer if they would sell them with FreeDOS preinstalled at a lower price); but if they preinstall the NVidia drivers (and some other things such as Intel wireless), they might violate the GPL or some of the other licenses, apparently. I don't know, just hearsay.

Rob Bradford: Bug buddy integration for GNOME Python apps

Just in case you missed it before…Fernando Herrera and Lorenzo Gil came up with a lovely bit of code that allows the parts of the GNOME experience written in Python to send traces via bug-buddy when something goes wrong. Pessulus will soon have this and i’m working on doing it for Deskbar. Update: Forgot the link to the code…bug-buddy-integration.py.

Steve Kemp: maybe of a brain hemorrhage, I haven t decided yet.

The past two days have been fairly busy and now I just want to avoid all computery things for the next week or so. This will almost certainly fail to happen, but I have a low-tech weekend planned which will involve shopping for outdoor gear and loitering outdoors drinking ale. Briefly I’ve: Still todo: I’m almost tempted to use one of those fancy “control panels” for managing a bunch of domains when I move over to the Xen instance. However many of them appear fragile, and contain numerous obvious XSS attacks - these do not fill me with confidence. Perhaps I will investigate more hosting setups soon. At the very least I wish to move towards an SQL-backed virtual hosting setup for email. Ideally exim4, but I’d settle for postfix at a push. So .. lots of research happening, and more to follow. Expect quiet from me for a while.

Next.

Previous.