Tue, 22 Jan 2013
New GPG Key (please re-sign it!)
My PGP key is almost 16 years old now - it has been created on 1997-03-15. It is a 1024-bit RSA key, which is not so strong by today's standards. So I have generated a new GPG key 4096R/A45477D5. I plan to phase out my other two keys, 1024R/D3498839, and 1024R/F0BEFD45 in the near future, and publish revocation signatures for them. My new GPG public key signed by both old keys is available at the following locations:
The fingerprint of the new key is:
B634 17E5 731B 4F42 69FA 57FF 9453 3581 A454 77D5
I hereby ask everybody who has signed some of my previous keys, or who has any means of verifying the above fingerprint by an independent channel (e.g. over the phone) to sign my new key and send me a signature. It is possible to do this in Linux using the following steps:
1. Obtain my public key
gpg --keyserver pgp.mit.edu --recv-key A45477D5
or use another keyserver instead of
pgp.mit.edu, or get the key from our webserver
wget -O - https://www.fi.muni.cz/~kas/pgp-A45477D5.txt | gpg --import
2. Display the fingerprint
gpg --fingerprint A45477D5
Verify the fingerprint (should be the same as above; you can also call me over the phone).
3. Sign the key
gpg --sign-key A45477D5
4. Export the key
gpg --armor --output A45477D5-signed.txt --export A45477D5
Now send the resulting file
A45477D5-signed.txt to me. Thanks!
NOTE: The plain-text version of this blog post, signed by my old key
1024R/D3498839, is available here.
Thu, 17 Jan 2013
Fedora 18 has finally been released after being delayed several times. So far my experience is not so bad - upgraded systems mostly work. What are the biggest problems?
Most of them of course are in the rewritten Anaconda/FedUp combo. In my opinion, developers should be explicitly told to not rewrite things from scratch, if there is at least a small possibility of getting to the similar set of features with incremental modifications. The problem is that the previous codebase mostly works, and have lots of working features even for many corner cases. This resembles the infamous gdm-2.20 rewrite. Here is the list of problems I have ran into so far, using F18 on my laptop, on my workstation at work, and on a testing virtual machine:
- Gdm still cannot set the X server command line options, even though the developers promised the feature to be restored more than three years ago.
- FedUp provides no visual feedback about the progress of update. Who the f* wants to see the flashing Fedora logo during the upgrade, instead of some meaningful information? Are we trying to emulate MacOS or what?
- The new Anaconda cannot setup the storage the way user wants it to be set up, even though the old version worked even in this case. The developers response? Use Kickstart.
- Anaconda can select only one desktop environment for the installation. The response is the same as above. WTF?
- On my laptop, there was no way to select the correct time zone using mouse.
- Configuration files are being gradually
systemdservices, which communicate over D-Bus, and have their configuration stored elsewhere. Replacing a three-line
/etc/sysconfig/clockwith a permanently running daemon which needs its own command-line utility which talks to it over D-Bus seems really questionable for me.
- My laptop is switching off when I close the lid. Apparently, another
systemdcomponent is doing this. Here is the workaround.
- Jindřich's TeXlive page is yet to be updated for F18. There is the texlive-release.rpm package, but it points to a non-existent directory. I have yet to solve this.
- On the positive side,
systemctlno longer needs the
.servicesuffix for the services.
To sum it up, we are slowly heading to the distribution where
grep(1) are no longer the sysadmin's friends, and
the sysadmin will need to use the specific D-Bus interfaces to talk to the
most parts of the system. It is kind of sad.
Wed, 02 Jan 2013
I wish happy year 2013 to everyone who reads this blog.