I started playing around with secure boot, with the ultimately goal of setting it up on my laptop. I experimented in a libvirt/qemu VM and to my surprise a custom secure boot is rather easy (the Secure Boot page on the Arch Wiki suggests quite the contrary), thanks to dracut and a fairly recent tool named
sbctl which just recently had it’s first release.
Installing Arch on a LUKS-encrypted dsik traditionally required a few careful configuration steps to configure the proper root device for booting; if any of these steps was omitted or done wrongly the system would fail to boot. With systemd and dracut however a LUKS-encrypted Arch system can boot safely and reliably without any configuration:
The following commands demonstrate a fresh Arch installation from the Arch installation media into a libvirt VM. Installing to a pristine physical machine or a different virtual machine provider should require only minimal changes; adapting an existing system may be more difficult and require more work.
Observations from using systemd-homed for a couple of days:
I like Arch Linux and use it for my systems whereever possible. In this post I’ll briefly go through my preferred Arch Linux setup.
UTC is the worst; and it’s going to get way worse:
Some time in the 22nd century, two leap seconds will be required every year. The current use of only the leap second opportunities in June and December will be insufficient, and the March and September options will have to be used. In the 25th century, four leap seconds will be required every year, so the current quarterly options will be insufficient. Thereafter there will need to be the possibility of leap seconds at the end of any month. In about two thousand years, even that will be insufficient, and there will have to be leap seconds that are not at the end of a month. In a few tens of thousands of years (the timing is uncertain), LOD will exceed 86,401 s, causing UTC to require more than one leap second per day.
In 40.000 years People will hate us for three things: Global warming, Nuclear waste, and UTC LEAP SECONDS!
Last week I got a big PDF with documentation about the almost-but-not-quite-entirely-unlike-REST HTTP API of an external partner. In the section about restrictions of their HTTP API:
For this functionality we recommend to use the SOAP API. This *convenient* interface offers almost *unlimited* possibilities to integrate Foo.
Emphasis mine. I have different memories of SOAP.
Emacs isn't just an editor, it’s an entire Emacs Lisp interpreter and environment. We can use Emacs Lisp not only to extend and customize our beloved editor, but also to write entire programs and applications. Nic Ferrier’s elnode server is the most ambitious Emacs Lisp application of this sort, but we can start at a smaller scale and try to write our shell scripts and tools with Emacs Lisp.
However, it turns out that writing programs in Emacs Lisp is more intricate than it looks at a first glance. Emacs decades-long history as interactive application have left deep marks in Emacs and Emacs Lisp, which make independent noninteractive scripts difficult.