Archive for the 'p.d.o' Category

This french phrase is one of the favourites of our (not for much longer) president, Jacques Chirac.

It could be translated as 'The taller the tale, the more likely people will believe in it'.

It fits perfectly to Microsoft's latest F.U.D.

Dear lazyweb,

A while ago, there was a PR announcing that VMware was opening its VMDK specification with GPL compatible licensing. While anyone can get the specification document, provided they fill a form, I haven't seen any note, on the document itself or anywhere else than the PR that this indeed allows an open source implementation.

The only thing that remotely ressembles licensing of the document could be

To ensure that readers of this specification have access to the most current version, readers may download copies of this specification from www.vmware.com and no part of this specification (whether in hardcopy or electronic form) may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of VMware, Inc., except as otherwise permitted under copyright law. Please note that the content in this specification is protected under copyright law even if it is not distributed with software that includes an end user license agreement.

This specification and the information contained herein is provided on an “AS-IS” basis, is subject to change without notice, and
to the maximum extent permitted by applicable law (...)

But this is more about the document itself than about the use of the specification. IANAL, but without more terms, the point of being able to read this specification is moot. It could even be patented and enforced...

Anyone with a better clue ?

Sun recently fixed a pretty interesting in.telnetd vulnerability. 24 hours to deal with the bug. Kudos.
A week before that, Sun fixed a (okay, local) vulnerability ... discovered in 2002... hum.

The QEMU Accelerator version 1.3.0pre10 is available in Open Source under the GNU General Public License. A detailed technical specification and API description is available.

That is great news. Now what I'd like to see is an unification of /dev/kvm and /dev/kqemu interfaces, so that the same frontend could be used for VT-supporting and VT-less architectures.

I've done this exercise a long time ago, but I think last time was before the first post with WordPress. So here it is: my improbable (or not) best of search engines keywords for january (provided by webalizer).

"新年おめでとう" - 明けまして !
"debian fundamentalism" - where ?
"asa dotzler troll" - did Blake Ross post here ?
"could have agree with you anymore" - all your opinion are belong to you
"do i need firefox if i have iceweasel" - firewhat ?
"your name in firefox 2" - I know
"lifelike androids" - paranoid ones are better
"dumb ass" - still ?
"blitzer blog" - wrong address
"a lot of horse facts" - i don't know what to say
"damage harddisk instantly" - drop your laptop from the 10th floor
"iceape vs iceweasel" - none of the above
"do you like the american accent" - no
"facts about the horse" - what is it with the horse ?
"feliz año nuevo happy new year 明けましておめでとう" - Bonne année !
"free mozilla firefox" - as in beer ?
"icebrowser community edition" - nice one
"normal life" - what is it ?
"shake laptop crash hard drive" - shake it the other way
"trademark versus copyright", "trademark vs copyright", "trademark vs copyright vs gpl", "trademark vs reserved", "trademarked and copyrighted logo", "registered trade mark vs copyright" - ask mozilla, they are knowledgeable
"what should stop working" - you
"what is a patent" - something I hate (I'll tell you stories about that soonish)
"why does debian call firefox iceweasel", "why does debian name firefox iceweasel", "why iceweasel debian instead firefox" - because we can't call/name it firefox
"will flashplayer work with iceweasel" - why not ?

For a reminder of the situation, see also:

• Playing evil with VMWare ESX Server, and
• Playing evil with VMWare ESX Server, part 2

I finally had time at work to implement a solution for the problem. The result is a bit less than 400 lines of code, which I hope to be able to make free-as-speech. I'll probably have tons of paperwork to do with my employer before that can happen...

The program implements a fuse filesystem that you feed with a raw device image file (but I'm willing to implement more image file formats), and that shows the individual partitions as separate files, named "partn.fstype". These files can then be mounted via loopback devices the standard way (which was not possible on vmfs for the reason you can find in my first post on the subject), with the benefit of not requiring offset adjustments (as when you want to mount partitions from a disk image), or some loopback device hack.

Additionally, it has an internal Copy-On-Write mechanism so that it is possible to mount "dirty" ext3 filesystems (e.g. a snapshot of a mounted filesystem) without modifying the original disk image. Note that there is no way, yet, to keep these writes after unmounting the fuse filesystem.

It uses libparted to handle the partition table reading, which means it will read any disk label types parted supports, such as BSD labels, sun partition tables, and so on. It doesn't support LVM, though.

Unfortunately, VMWare ESX server 3.0 being based on RedHat Enterprise Linux 3, only an ancient version of libparted is available. By the way, this version (1.6.3) had a pretty bad bug that made it impossible to use it for regular files instead of devices: it was trying to do a BLKGETSIZE (or was it HDIO_GETGEO ?) ioctl on it. To workaround this, I implemented my own PedArchitecture. It was somehow a revelation, because with similar mechanism, I can implement support for different disk image types :).

Anyways, there have been quite some API changes in-between, so some updates will have to be done to the code...

In other news, I started working on ext3rminator again. There may be a new release in a few weeks.

Update: Thinking again about the ioctl issue, I'm wondering if vmfs couldn't be responsible (again) for the failure, actually... I'll check that on monday.

Marc, this is not a problem with the Debian BTS, but with BTS in general. What you describe also happens with Mozilla and Gnome BTS, speaking of those I know. The Mozilla Bugzilla is indeed an example of what NOT to try to replicate, it's probably even worse than the Debian BTS.

Or, if you really want to, be careful that, if /usr/lib/iceape/chrome is a directory (and not a symbolic link), your working directory is /usr/lib/iceape/chrome, or you will end up with the content of your current directory in /usr/share/iceape/chrome, which may be a big issue if you run apt-get from /.

If /usr/lib/iceape/chrome is a symbolic link, no worry, just ignore this message.

Thank you for your attention, and very sorry :(

Update : That's in such cases that you'd like special crafted tools to rebuild packages without the need to rebuild the whole thing when it comes to just change maintainer scripts (pre/postinst, pre/postrm...). Fortunately, I have pbuilder configured with ccache, but that doesn't help the buildds with their build job.

I don't know if I should be proud of this...

Yeah, I know, I wrote it in the first place, but still...

I finally gave a try to my pervert solution.
Using unionfs led to a kernel oops on the service console (which means it brought VMs down, too).
funionfs, as a fuse filesystem, could not lead to the same result, but i had some issues with it:

• result of lseek() being put in an int variable while _FILE_OFFSET_BITS is set to 64... impossible to seek at more than 2GB of data, which ext3 recovery needed to do...
• when opening read/write a file (which the loopback device does), it attempts to open read/write the original file on the read-only directory, which leads to EBUSY when the file is opened elsewhere (i.e. by VMWare ESX Server).

Once these issues solved, it ... doesn't work. The problem is funionfs doesn't handle files that are partially written to: it creates a new file in the r/w directory, and writes exactly what has been requested, creating a sparse file. On subsequent reads, it gets the data from that sparse file. This means most of the data, except data that has been written, is zeroed.
I'm afraid there's nothing better to do than take a somewhat arbitrary chunk size, write to the sparse file by chunks (reading missing data from the original file if necessary), and keep a bitmap of the chunks that have been written to the new file...
I should check what the original unionfs does with this.