Despite the warnings on the yum upgrade web page ,I just got through doing a yum upgrade from Fedora 16 to Fedora 17on my office workstation. The short summary is that it went fine.I'd say that it went without problems, but that's not quite true;it went with no more problems than usual for my office workstation.In specific, the directions for using a dracut reboot to execute the /usr merge worked flawlessly.

(Note that I had already transitioned to having a

For reasons beyond the scope of this entry, I've recently been pokingaround Windows 7; specifically I've been poking around the standardWindows 7 backup tool, which is actually pretty decent as these thingsgo. It will pretty effortlessly back your data or your entire systemup to either some sort of disk or to a network share, and then it hasone really nice feature: you can restore your system right from theinstaller . This works basically painlessly; you boot the install CDon a bare metal

Via Hacker News ,I was just reading The TTY demystified , which is adecent introduction to Unix TTYs and a number of their peculiarities.One of the things that it talks about in passing is the linediscipline ; to summarize,the line discipline is the part of the kernel tty driver turns tty inputinto something that you get a line at a time, and that handles thingslike letting you edit the line as you type (by handling, eg, backspace)and also generates various signals when you type special

I've kind of alluded to my views in passing before but since I've already written a certain amount on thesetwo systems (and a chunk of it sort of in favour of Mercurial) I feellike writing about this explicitly, just to be clear.

(You should insert implicit 'in my view' disclaimers in the following ifdesired.)

For my own use, Mercurial is easierto start with and use simply, more user friendly, and more 'humane'(in that in general it

One of the persistent debates in modern version control is betweenmerging changes and rebasing them, with the customary pro-merge argumentbeing that rebasing destroys history. From the developer's view this iscompletely correct; rebasing destroys the history of the changes thatare being rebased, causing them to spring into existence fully-formed.

But there's another view you can have on this; you can have the viewof a user of the repository, someone (or something) who is pulling andtracking the tip/

When I read Matthew Garrett's Implementing UEFI Secure Boot inFedora , a number of thingsstruck me about the situation (for his background on UEFI secure boot,see part 1 , part 2 , more , and especially this ). The basic setup isthat Microsoft is requiring that any hardware that wants to carrya 'Windows 8 ready' logo must support UEFI secure boot and musthave it turned on.

(Actually, when I read Garrett carefully the last bit is not clear. Hesays that if Windows

In theory, UEFI secure booting has the straightforward goal of stopping boot time malware, malwarethat compromises your machine before Windows boots and thus before anyof its protections can kick in (such malware already exists, althoughit's not very common). In practice, secure boot requires that allprivileged code your machine ever runs be signed . Your bootloader mustbe signed, your operating system (Windows or otherwise) must be signed,your hardware drivers must be signed. Wait, what? How did 'prevent boot

First off, as I rambled yesterday ,to say that Solaris has failed here is not to say that our use ofSolaris has been a failure (or that our Solaris machines have been); our fileservers are stable and run (generally)without problems and work. But at the same time it's clear that Solaris has failed to catch on here . The onlystrong reason our fileservers run Solaris is ZFS, and we've noteven running anything close to a current version of Solarism atthat ( cf

In light of my recent entries , people might wonder how we've faredwith operating systems here and whichspecific OSes have succeeded or failed. The necessary disclaimeris that this is all from my personal perspective; my co-workersmight have a somewhat different view of things.

OSes that we've actively done things with while I've been here:

• OpenBSD: clear success within its domain.

  OpenBSD is our automatic choice for anything to do with firewalls(PF just works) and pretty much the default choice