I spent a few hours this weekend converting my entire Fedora Core 3 system over to EVMS.  The advantage over using one of the other alternatives like the bdclaim patch is that EVMS can manage your root filesystem.  This lets you alter the underlying storage of your root filesystem, including “hotswapping” one storage device for another without having to boot to a shell.

It isn’t straightforward getting this working in Fedora Core.  You’ll need to do some initrd hacking to get it up and running. 

Here’s what you need to do.  Note that this assumes that you are running the same kernel that you’ll be booting:

  1. Mount the EVMS initrd as loopback under /tmp/initrd-loop.

    # mkdir /tmp/initrd
    # mount -o loop evms-initrd /tmp/initrd
  2. Delete the /sbin/modprobe symlink from the EVMS initrd and copy it from the Fedora system’s /sbin directory:

    # rm /tmp/initrd/sbin/modprobe
    # cp /sbin/modprobe /tmp/initrd/sbin
  3. Create a /lib/modules/`uname -r` directory in the initrd.

    # mkdir /tmp/initrd/lib/modules/`uname -r`
  4. Copy the device mapper kernel drivers from the root filesystem to the initrd.

    # cp /lib/modules/`uname -r`/drivers/md/* /tmp/initrd/lib/modules/`uname -r`
  5. Run depmod to get the proper modprobe data files.

    # depmod -b /tmp/initrd-loop
  6. In the “load modules” section of linuxrc, add “modprobe dm-mod”.
  7. Add the following lines to linuxrc, just before “Pivot-root to /sysroot”:

    # Mount a new tmpfs filesystem on the new system's /dev/ directory
    mount -t tmpfs none /sysroot/dev
    # Copy the evms and console devices to the new directory
    cp -a /dev/* /sysroot/dev/
Read full post

I’ve had a chance to play around with Fedora Core 4 for a week and it’s turning out to be one of the best Fedora releases out-of-the-box.

It doesn’t look much different that Fedora Core 3 did.  The biggest changes under the hood are the updates to the Xorg and kernel packages, as well as compiling everything for GCC 4.0.  My desktop looks identical to the one that Fedora Core 3 showed me, with the exception of the new “Places” and “Desktop” menus - the two new top-level menus that come from the latest Gnome iteration.

The only kinks I’ve encountered were apt not working without a tweak (adding Apt::State::FirstRun "false"; to the apt.conf file) and some packages not being available in the 3rd-party repositories that I normally use.

I give this release a hearty thumbs-up.

Read full post

I’ve noticed that the quality of stuff being posted on IEBlog is so far below-par that it could be considered dangerous for the future of the web.  Strangely enough, this seems to be an epidemic in web-related Microsoft blogs.

Yesterday, IEBlog posted a link to an article on MSDN on how to add rounded corners to a box.  The methods suggested in the article, however, are the terrible, un-semantic techniques that people were using years ago!  Thankfully, some of the commenters have been calling them out on it:

This is news! People have been doing this for a while, but of course they’re always the extra markup that get’s really messy to manage for large projects. This kind of thing as been around for years. (in fact MSDN nicely outlined all the _wrong_ way’s to do this). You support a lot of things that aren’t in standards, like vbscript and activeX, why not support something that is at least planned and will be in the standards very soon?

Great job at innovation guys!

Dean Edwards (of IE7 fame), stated it well:

I can’t believe you’ve linked to this terrible article. In the days of semantic markup and CSS you are suggesting that web devs alter their data to get a visual effect. Astonishing. I hope that Mr Mielke won’t be allowed to blog again here.

Now, this isn’t the only offence that Microsoft’s web-related blogs have caused.  A number of the blogs have been pushing the mantra that “Javascript closures are harmful”.  The article often follows a pattern:

  • Javascript closures are harmful
  • This is what they do
  • This is the 1990’s way of attaching event handlers via strings
  • IE is buggy and leaks when certain closures are used

Check out this classic post in which the author realizes that power of Javascript closures, but trashes them because IE leaks memory!  Bear in mind that this is an IE-specific leak - no other browser leaks memory when using closures.

This is an extremely powerful functional language feature, but it is important to not misuse it. There are ways to cause memory-leak-like situations using closures.

Don’t use closures unless you really need closure semantics. In most cases, non-nested functions are the right way to go.

Microsoft wants web developers to cut their use of a very powerful development feature because they haven’t been able to fix it.  Contrary to the belief of the IE team, closures are useful in nearly every case that you need an event handler.  Thankfully we have Javascript libraries like the EventCache to clear this stuff up on page unload and prevent many leaks.

Don’t believe Microsoft’s message that closures are inherently buggy - hold their feet to the fire on this one!

Read full post