5 h 23 min 30 s

5 hours, 23 minutes and 30 seconds is the average time it takes for a Mono apologist to scrutinize a complex legal document, determine there are no tricks whatsoever in the text or in its relationship with the patent provisions in GPL (like those we’ve seen elsewhere) and rub it in your face:

Sorry to disappoint you, but I didn’t go to law school, I just don’t know what we can expect from this announcement, and I don’t think I’m qualified to make myself a solid opinion. So what I will do is wait until a reputable, unbiased source like the Software Freedom Law Center makes a statement saying everything looks pretty nice and GPL-compatible, and then join you in your spiteful “celebration”.

The Intel Legacy Horror Show

Most people would agree that the x86 design is full of legacy junk. But to truly understand this, I think one has to dive in and see for himself. I’d like to talk about my little journey of discovery, in which I learnt the horrors of i8086 legacy.

Roughly three weeks ago, I decided it would be a nice experiment to pick GRUB 2 and make an i386 firmware out of it. GRUB can already run as a standalone bootloader and be part of your firmware when you combine it with coreboot (which initializes the motherboard), but I wanted to have an easy way to test this standalone mode in QEMU. The result (which, btw, is packaged in Debian as grub-firmware-qemu) behaves in exactly the same way a coreboot/GRUB would (except, of course, that it will only work in QEMU).

Initially I thought this would be piece of cake. In QEMU there’s no motherboard to initialize, so basically the steps would be:

– Process the VGA rom with a far call.
– Switch to protected (i386) mode.
– Done! Jump to grub_main() and start as usual.

Hah! So far from reality. First of all, we start with code segment 0xf000, offset 0xfff0, which corresponds to virtual address 0xffff0. Our ROM is I/O mapped in the 0xf0000-0×100000 range. So we’re at exactly 16 bytes before the end of our code. With no room for anything, all we can do is jump.

Not so bad, right? Let’s jump to the beginning of our whole ROM image, and put the initialization code there?

No way. The 0xf0000-0×100000 range in which we’re mapped is just 64 kiB in size, and our image might be bigger (we generate it dynamically with grub-mkimage, and can even include an embedded filesystem). Only the high 64 kiB are mapped there. The rest of our code is near the top of virtual memory, which we can’t access yet because we’re still in i8086 mode (and 640 kiB are enough for everybody, remember?).

I opted for creating a small image with entry code, boot.img, using a hardcoded size (512 bytes). This image will later be picked by grub-mkimage and allocated at the end of our ROM. So we do a relative jump to the beginning of this image:

. = GRUB_BOOT_MACHINE_SIZE – 16
jmp _start
. = GRUB_BOOT_MACHINE_SIZE

and proceed with (finally!) processing the VGA rom:

/* Process VGA rom. */
call $0xc000, $0×3

and switching to 32-bit i386 mode:

/* Transition to protected mode. We use pushl to force generation
of a flat return address. */
pushl $1f
DATA32 jmp real_to_prot
.code32
1:

But before we leave boot.img, we need to figure out where’s the rest of our code. It’s not relative to our current location because, ugh, the beginning of our ROM was truncated.

We know it’s mapped at the top of memory, and for the sake of simplicity (which was greatly missed in this experience), its 32-bit entry point is at the beginning of it. So we only need to substract the ROM size to the 4 GiB barrier. But all this was already known by grub-mkimage when generating our ROM. And it was kind enough to embed this address in a variable:

movl grub_core_entry_addr, %edx
jmp *%edx

Problem is, our toolchain puts the BSS right after our code, which ends really close to the 4 GiB limit. It might not even fit in memory! There’s a chance that it might do, depending on the size of our module selection (GRUB modules are placed right after the main body of code), but no garantee about it! Isn’t the top of memory a practical location?

So let’s relocate elsewhere. Recipe for relocation: current location, destination address, size. Our destination address is somewhat arbitrary, we just pick whatever we used at link time. We’ve known our size since grub-mkimage generating this ROM, so we arranged to have it embedded in a variable, like we did for boot.img:

VARIABLE(grub_kernel_image_size)
.long 0

Whoops, too bad, we can’t even read it, because… memory access is always absolute, and we don’t know its absolute location, so we need to make this position-independant in some way. Fortunately, we know that ROM size is a multiple of 64 kiB, so we obtain %eip and round it:

/* Relocate to low memory. First we figure out our location.
We will derive the rom start address from it. */
call 1f
1: popl %esi

/* Rom size is a multiple of 64 kiB. With this we get the
value of `grub_core_entry_addr’ in %esi. */
xorw %si, %si

At last! We can read grub_kernel_image_size:

/* … which allows us to access `grub_kernel_image_size’
before relocation. */
movl (grub_kernel_image_size – _start)(%esi), %ecx

and then proceed to relocate,

movl $_start, %edi
cld
rep
movsb
ljmp $GRUB_MEMORY_MACHINE_PROT_MODE_CSEG, $1f
1:

zero the BSS, and jump to grub_main():

/*
* Call the start of main body of C code.
*/
call EXT_C(grub_main)

the rest is business as usual.

So, was it so hard to just map the damn thing at a fixed address, say, 0xf0000, without truncating it or using weird memory locations, and use this same address as entry point?

I think I learnt my lesson: never underestimate what 30 years of legacy constraints can do to your sanity. Well, for what is worth, it was a nice learning experience, with a byproduct you might find useful and/or interesting yourself.

Gnote

Well, it seems that since last saturday, Gnote is now the default option in Debian for those platforms where Mono unportability prevents Tomboy from being used, namely: alpha, hppa, m68k, mipsel, mips, hurd-i386 and kopensolaris-i386.

I explained before that I’m skeptical about whether a note-taking application ought to be pulled to the default package selection for desktop installs. But this is not what I wanted to talk about today. What bothers me is that the same person who decided Gnote is a suitable replacement for Tomboy on these architectures, also has these things to say:

GNote was written for bad reasons, without even respecting the GPL copyright requirements. But more importantly, its maintenance model is going to make it only follow behind the Tomboy lead, as any code changes in Tomboy will need to be translated to C++. It also supports less languages and less features. Furthermore, it was introduced in Debian for political reasons, by a maintainer who doesn’t use it and isn’t involved in GNOME maintenance.

It is not what he said in itself that bothers me. I put aside that Hubert wasn’t asked at all about his reasons before judging them, and the fact that those accusations of copyright violation are completely bogus, among other things.

What really bothers me here is that all those perceived problems magically disappeared when promoting Tomboy was at stake. How can we expect sane judgement here?

I suppose that if people who care about politics are “toxic”, then anti-politics must be sanity. Except anti-politics are in fact a form of politics. Twisted, I know, but that’s just like human mind is sometimes. For those who are still wondering why, this might help explaining.

Anyhow, no matter the reasons I feel it’s my responsibility to stand for this decision. I’m looking forward to a Gnote that is well tried and tested on all Debian architectures, with complete documentation and localization support that is improving every day. You too can help by trying and testing Gnote, specially on the aforementioned platforms.

What does RAND mean?

Apparently, it must mean something, because I find it being referenced in (supposedly serious) discussions about .NET licensing.

The acronym literally translates as “Reasonable And Non-Discriminatory”. So far so good. Except I don’t have a clue what it means. What does “reasonable” mean when applied to a patent licensing policy? Well, according to my own interpretation of this word, a licensing policy is reasonable when it prevents the patent from being used to impose a tax on any users of any program. But this is just my point of view on what is reasonable. Can you expect patent holders to agree with your point of view on what “reasonable” means when interpreting their own promises?

Obviously, only if you trust them, which beats the point of them issuing promises in the first place. This is why some of us reject the “RAND” term. It’s essentially deceitful, because it implies there’s an agreement on what is reasonable and what isn’t. The proposed alternative, UFO (for “uniform fee only”) has a clear meaning, and it usually corresponds with what patent lawyers mean when they say their policy is “reasonable” (mind you, I don’t consider uniform taxation reasonable at all).

So whenever you read about Microsoft promising a license under “reasonable” terms to anyone who asks for it, as if being reasonable had some sort of standard meaning, don’t fall for the trap. Stop for a while, check what they’re actually delivering (or whether they’re delivering anything at all) and consider what “reasonable” means to you.

Mono is not a patent threat for Debian

I read Richard Stallman’s post in which he expresses his concern about a serious danger with reliing on .NET for free software development. I think Richard makes very good points here, and I do agree that there’s a serious danger, but I don’t think Microsoft would ever bring all .NET implementations underground. If you think that, my opinion is you’re underestimating them.

Microsoft is smarter than that. They are a sworn enemy of free software, they’re ruthless, and they know all the anti-competitive tactics in the IT world. There’s no doubt they want to make our community divided and helpless. And when they look at the free software development ecosystem, they see two big groups:

A- Highly profitable vendors like Red Hat or Sun/Oracle.
B- Non-profit communities like Debian or Ubuntu (technically, Canonical is a for-profit venture, but they operate at loss).

There’s also 3rd parties that sell hardware or services and contribute “collateral” improvements to our codebase. I’ll ignore those for the sake of simplicity.

It would be silly to try harm group B with their patents, since it’s composed of grass-root efforts which can’t be unrepairably injured just by bringing a company out of bussiness. Besides, group B actually helps them promote their patent-encumbered standards. Why attack those who are helping you?

Ah, but as for group A, maybe they could use patents to shut it down? Perhaps, but I think they’re even smarter than that. Sun Tzu said: “When you surround an army, leave an outlet free. Do not press a desperate foe too hard.” If Mono-based applications become a significant competitive advantage (and it is in their agenda that they do), and their competitors are forbidden from using them, they will put all their effort in pushing for alternatives, even at great expense. I really think they know better.

I recently came across this very interesting article, written in 1999, which details the tactics used by Microsoft to fight IBM. They obviously saw OS/2 as a threat. Back then, Windows 95 was the trading token. They could have caused IBM a great deal of harm shall they refused to license it to them, but it seems the idea of subjugating IBM was more appealing. This is how Garry Norris (IBM) put it:

“Microsoft repeatedly said we would suffer in terms of prices, terms, conditions and support programs, as long as we were offering competing products.“

“[Microsoft] insisted that IBM sell 300,000 copies of Windows 95 in the first five months or face a 20 percent price increase“

Nice deal, eh? Make your dependancy on Windows 95 stronger, or else we’ll use your existing dependancy on Windows 95 against you. No surprise IBM abandoned the PC market. Are Red Hat and Sun/Oracle set on the same direction?

Draw your own conclussions. In my point of view, projects like Debian and Ubuntu are completely safe from direct patent threat. Should we care if Red Hat or Sun/Oracle succumb? Perhaps not, after all, what are they doing for us?

what a good patent covenant looks like

My friend Stefano Forenza just wrote a blog post in which he gives (among a whole lot other things) an excellent example on what a good patent covenant is supposed to look like:

Subject to the terms and conditions of this License, Google and its affiliates hereby grant to you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this License) patent license for patents necessarily infringed by implementation of this specification.

If you institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the implementation of the specification constitutes direct or contributory patent infringement, then any patent licenses for the specification granted to you under this License shall terminate as of the date such litigation is filed.

I like this: short, straight to the point, unambigous. I wish other companies could take inspiration from Google for their own covenants.

greetings from a windmill

KiBi, you got it backwards. I’m the windmill. But well, at least you got a sense of humor.

Anyways, nice picture. Send my regards to your minion.

Mono in the default install?

Heya,

For those who haven’t been following closely, the explanation behind Jo Shields’ recent post instructing us on the greatness of Mono and the Microsoft .NET approach to software development could be found in the fact that Josselin Mouette has decided that Mono must be part of the default desktop install for Debian Squeeze.

The reason for that is so Tomboy, the note-taking application, can be included now. Well I’m not really sure a note-taking application really needs to be in the default selection, to the point that it justifies dragging ~40 MiB of dependencies into the first CD. However, being the maintainer for Gnote in Debian, there’s one thing I know. I’ll explain with two screenshots:

Well, so which is which again? This is really just the surface. If you try both programs you’ll see that they behave so similarly, to the point that most users couldn’t tell the difference (unless they depend on some of the few less noticeable features of Tomboy that haven’t been ported yet).

I guess somehow I could be persuaded that note-taking is so important it must be in our default package selection, but what is the reason we want to drag all the .NET stack in to get the same functionality? So far I haven’t heard any, I only hear some bragging about this development environment being so “amazingly productive” and then some rant about those detractors being a bunch “trolls” and “back-seat drivers”.

I have to admit, however, that I admire Jo’s sincerity when he makes this point: it’s not the users who want it, it’s the developers. It can’t be denied that .NET was indeed instrumental in the development of Gnote. Perhaps the real usefulness of .NET is in writing new code which can later be ported to C++ in order to run faster, consume less memory and support more architectures. One can only thank them for that.

Correction:50 MiB is the measure in Lenny. With current sid, Tomboy drags in ~40 MiB, not ~50 MiB. Thanks to Jo for letting me^H^H others know.

Can I haz syndication

If you’re reading this from planet.debian.org then I guess I can. Join me in welcoming myself to the interblags

Debian and corporate support

I read about Steven J. Vaughan’s article on which he tries to explain why you don’t see as much corporate support in Debian as you see in other places. The conclusion of Steven’s analisys, it seems, is that Debian is inmature. I will attempt to respond to it from a Debian perspective.

Ok, you don’t really see that adjective mentioned in his article, but it is what every paragraph in it is trying to tell us. Even the one paragraph that contains a positive remark doesn’t escape from a reminder that we always do things “our own, cranky way”. And of course, the article is finished with a sincere recommendation to flee away from Debian. Wow Steven, you must really hate Debian don’t you? Ok, to be fair, I assume you have reasons for what you say. Nevertheless I think those reasons are flawed.

As a Debian developer, I’d like to try my humble attempt at clarifying some of the common misconceptions about what Debian is, that seem to be the basis for Steven’s disapproval of our ways.

The root of the problem seems to be that you measure maturity of an organization by the amount of internal collisions you see from the outside. However, every big organization in the western world has internal disputes. So what is it that makes Debian different?

• We don’t hide problems (remember our Social Contract?). In practice, this works at two levels: 1) we don’t try to hide our internal discussions; and 2) individuals have a general feeling they can speak out (instead of repressing their opinion to avoid displeasing their boss). How many examples of this do you see in corporate world? Right, you can’t see a thing except when you’re inside The Walls.
• Our common goals are quality and freedom. This is what puts us together above our petty differences. Some disagree on what ‘quality’ means; some disagree on what ‘freedom’ means. Some even think the most efficient way to archieve them is to make small compromises. But it still boils down to these. Then, what ties a corporation and prevents it from falling appart? That’s right, money. That is their common goal. Debian benefits from money, equipment and even developers hired to improve specific areas. We’re grateful to those who contribute! But money isn’t everything you see? For one thing, we never let money condition our agenda. We have higher goals here… we deliver sustained quality and freedom; and outsiders can rely on us to continue doing so, no matter if we have funding problems or if -insert evil company based in Redmond here- wants to buy us out.  How many partners can promise such an high reliability?
• Our value is our strong, technically-capable user-developer base. Thousands of enthusiasts working together in furthering our goals. In the article you seem surprised that “despite all this, Debian does keep going”. Well, as long as our highest value stands, Debian will continue to not just keep going, but to show leadership in the development of the codebase that most users (be it individual users or big players like Canonical, HP or IBM) rely on.

I hope this helps you understand Debian a bit better. You don’t have to like what we do; but at least try to respect our position and apply fair judgement to it.