PackageUpdateGUIIssues written at 23:09:03; Add Comment
How not to improve your package updater application
Earlier today I tweeted:
Now I feel like explaining that (in the spirit of an earlier entry). First,
In Fedora 15, the (Gnome) interface for it has two relatively minor issues (which you can actually see in the current screenshots on the PackageKit website): it doesn't group the updates into separate sections for security updates, bugfix updates, and regular updates, and it always shows the 'Details' area even if you're not interested in it. In the Fedora 16 version, someone decided to fix these problems. To properly appreciate the result, I must show you a picture (which I am not going to inline here because it's too big): a screenshot of the Fedora 16 gpk-update-viewer.
The Fedora 16 version has certainly fixed those two little problems; the Details area can now be folded away, and updates are now grouped. However this 'improvement' has created all of the following issues, many of them disastrous:
Since the entire reason I'm running
And on a slightly more minor gripe, the Fedora 16 version always starts up with a completely crazy window size when I run it under fvwm in my normal configuration. No other Gnome program seems to have this problem and the Fedora 15 version was (and is) fine.
(Fedora 15 has gnome-packagekit 3.0.0; Fedora 16 has 3.2.1. Sadly the Fedora 15 binary doesn't work on Fedora 16, but maybe I can recompile the old version from source.)
SystemdRestartEnvironment written at 00:06:53; Add Comment
A quiet advantage of the systemd approach to service management
One of the ways that things like
There is a somewhat subtle advantage to having systemd do this, one that I have been quietly appreciating lately: your shell environment never leaks into restarted services.
(Even logging in directly as root or using '
This issue is somewhat near and dear to my heart because I retain a
fairly customized environment even when I
(There are sometimes drawbacks to this approach; for example, you can't quickly increase the number of open file descriptors a daemon can have by changing your root shell's ulimit and then restarting the daemon, or set special debugging flags in the environment. I haven't found these drawbacks to be an issue in practice so far.)
(This entry was brought to you by me spending a bunch of time today
LinuxGPTAndEFI written at 01:16:37; Add Comment
The current state of GPT, EFI, and Linux
I'm in the process of migrating my office machine's Linux installation from an old, small pair of disks to a newer and somewhat larger pair of disks. As part of this I have been doing a bunch of reading about the current state of PC technology as far as partitioning and booting goes, because getting new machines recently has made me clearly aware that BIOSes have come a long way from the old days.
There are two parts of the new world, GPT and (U)EFI. GPT is a new scheme for disk partitioning, replacing the MBR partition table and primary and extended partitions; UEFI is a new scheme for booting machines, replacing the old BIOS MBR booting. Booting with UEFI requires a GPT partition table as well as a UEFI-aware BIOS but the reverse is not the case; using GPT does not require booting with UEFI or a GPT-aware BIOS. There are two reasons to use GPT, either if you have a disk over 2TB or so (dealing with this is what GPT was introduced for) or if you ever want to boot from the disk using UEFI.
As far as I can tell, at the moment your best option for booting Linux (if you have a choice) is still old fashioned BIOS MBR booting, not UEFI boot. Many Linux distributions are in the process of switching to Grub 2, but Grub 2's UEFI support is still apparently unreliable which leaves you using various other options which are likely to be less well-supported, and in general EFI booting in Linux is still relatively young. If you're a future-looking person you can start experimenting with UEFI booting on a UEFI-capable machine, but MBR booting is going to be the easier and better way to go for now because it's still the majority choice.
My new disks are nowhere near large enough to require GPT, but I'm going to use GPT partitioning anyways for future-proofing. My new office machine supports but doesn't require UEFI booting (and I'm happy with BIOS MBR booting). However, I seem to keep disks for quite some time so it's quite possible that I'll still be using these disks when I want (or need) to switch to UEFI booting (either due to a new machine or new versions of Linux). And if I want to boot these disks with UEFI someday, I need to partition them with GPT now and set up appropriate UEFI boot partitions.
(My current disks are now slightly more than five years old and have been transplanted between three machines. Barring disk failure I suspect that the new disks will have a similar lifespan, especially since I hate reinstalling machines from scratch.)
From what I can tell (eg from the gdisk documentation), a future-proof GPT disk partitioning scheme needs two special partitions: a BIOS boot partition (gdisk code EF02) and an EFI System Partition (gdisk code EF00), probably with the ESP as the first partition on the disk. The BIOS boot partition is used to give the MBR bootloader somewhere that's guaranteed safe to store its second stage code; the EFI System Partition is where EFI bootloaders go (and where the BIOS will find them). I'm currently planning to make these 4 Mbytes and 256 MBytes respectively. This is probably overkill for both, especially since I don't plan to multiboot several OSes on my machine.
(The gdisk documentation seems to be an excellent reference for all of this; it's been my primary source.)
* * *