Last weekend was the bi-annual time to roll the main machine and server to the current Ubuntu release, now at 23.04. It must now have been fifteen or so years that I have used Ubuntu for my desktop / server (for “reasons” I may write about another time). And of course it all passed swimmingly as usual.
[ And a small aside, if I may. Among all these upgrades, one of my favourite piece of tech trivia that may well be too little known remains the dedication of the PostgreSQL maintainers installing the new version, now PostgreSQL 15, seamlessly in parallel with the existing one, in my case PostgreSQL 14, keeping both running (!!) on two neighbouring ports (!!) so that there is no service disruption. So at some point, maybe this weekend, I will run the provided script to dump-and-restore to trigger the database migration at my convenience. Happy PostgreSQL on Debian/Ubuntu user since the late 1990s. It. Just. Works. ]
[ Similarly, it is plainly amazeballs how apt
orders and
runs package updates to service to keep running for a maximum amount of
time. This machine acts as e.g. a web server and it was up and
running (as were other services) while thousands of package got
updated/replaced. It is pretty amazing. Whereas on other platforms
people still maintain the “do not ever update anything” we demonstrably
offer the opposite here. Really not too shabby. ]
This time, I had one small hickup. Emacs, now at version 28 bringing
loads of niceties along, would not load. And the error soon lead to a
post on the magit
list where its indefatigable author Jonas Bernoulli suggested a
rebuild (and hence re-compilation of the elisp files). Which I did, and
which allowed a start of VM inside Emacs. So I was happy. But it allowed
it only once for each VM package reinstall. Not good, and I remained
curious.
Some more digging lead to a breakthrough. A post and commit at the Fedora Project indicated that for just VM within Emacs, byte-compilation throws a spanner. Which one can work around by telling Emacs not to compile the files in the VM folder.
So I applied that patch to the VM package in a local build et voilà we have working VM. The world is clearly better when your email client of 25+ years just works. And feels snappier because everything under Emacs28 feels snappier! So I set this up properly and filed Debian Bug Report #1039105.
To which Ian Jackson, the maintainer, replied a few days later nodding that he could reproduce. And that he concurred with the bug report, and was planning to update throughout. And lo and behold this morning’s update reveals that this made into an update for the just-released Debian Bookworm.
So yay. In all these years of Debian maintainership (somewhere between twentyfive and thirty) this may be my first bug report with patch going straight into a stable release. But of course, true and full credit goes of course to Göran Uddeborg for putting it up first for Fedora. Lovely how Open Source can work together. We really should do more, not less, of that. But I digress…
Anyway, in sum: If you try to use VM under the lovely Emacs 28, there is a fix, and if you use it with Debian Bookworm the fix should hit your mirrors soons. Ditto, methinks, for the next Ubuntu release. If you use it under Ubuntu now, the package is (elisp) text-only and can be safely installed on a derivative (which we do not enjoy in general but which is fine here). So enjoy!
If you like this or other open-source work I do, you can now sponsor me at GitHub.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
If MythTV, after an otherwise innocuous kernel upgrade complete with an upgrade of the required ivtv driver, fails to show live tv even though ivtv itself works, check the settings and make sure the second tuner on the pvr500 card doesn't point to nowhere. Still not sure how a kernel upgrade could affect the setting inside the MySQL db, but what can you say.
On the other hand, the upgrade of MythTV itself from 0.19 to 0.20 was seamless. Oh well.
apt-get
install linux-headers-686
really helps: it then really reduces to
cd driver; make; make install
. Thanks to this page
for the reminder.
The next question then is whether the data reveals any pattern, or confirms or denies what we saw so far. The logical step is to compare this across architectures and countries. Following Cleveland and Tufte, we prefer a chart to a table. Below is a dotplot which shows download percentage by architecture, with grouping by country (with code and data for the chart).
This suggests that Sweden and Italy are more alike than different, indicating that maybe neither is all that unique. The UK has many more downloads for what appear to be less used architectures in IT and SE. That is good news inasmuch as it shows that there seem to be some users for just about every architecture. However, it would be nice to get data from maybe one or two more 'big' hosts to corrobate these findings further.
Lastly, some concerns were raised about various biases from local mirrors, web caches, multiple installs and what have you. These are fair questions as they all affect how Debian is obtained, installed and updated. But for as long as we don't know why that should be different across architectures, this is not a concern for the question at hand. The concerns reflect uncertaintly about the absolute level of users, but barring additonal information (or hypotheses), they do not affect the distribution of users across architectures which is what this exercise is about in the first place.
Saving Marco's data to a text file that is read and transformed by a few lines of R yields a nice table with relative usage percentages (taking out the 'all' non-binary architecture) as well as a cumulative sum of relative usage:
edd@chibud:/tmp> R --slave < it.feb.R files.downloaded percent cumulpct i386 1762483 96.6123 96.6123 powerpc 34420 1.8868 98.4991 ia64 18224 0.9990 99.4980 hppa 5985 0.3281 99.8261 sparc 1293 0.0709 99.8970 m68k 987 0.0541 99.9511 alpha 824 0.0452 99.9963 arm 45 0.0025 99.9987 mips 14 0.0008 99.9995 mipsel 6 0.0003 99.9998 s390 3 0.0002 100.0000 total 1824284 100.0000 NA
In other words, the top seven architectures cover 99.996 percent of downloads whereas the remaining four combined are a relatively scant 0.004 percent, or about one in twenty five thousand.
Three cheers for the hard-working Debian admins.
The compromised machines are being rebuilt. In the meantime, accounts as well as backend services are frozen. This affects my email connectivity as just about every past or present email address I have gets re-routed through debian.org. If you contacted me since November 21, 2003, and are waiting for a reply, please be patient. Services are expected to be restored by around the 26th of November. I should be able to reply by the end of the week. Hopefully.
In the meantime, there are two shortcuts. One is my email at work. The other is my account with the address firstname underscore lastname at that big internet portal with the yodel jingle dot com account. That account is still pretty spamfree, hence the caution about the concrete form.
That being said, my thanks go to all the hard working Debian admins for taking care of the infrastructure.