Greg's diary, recent entries

Tuesday, 14 July 2026	Dereel
		Top of page
		next day
		last day

Firefox: enough!

Topic: technology, opinion

Link here

Tried once again to recharge Yvonne's phone today. Once again it hung submitting the order. OK, try with chromium instead of firefox. Slow (almost certainly the site), but it worked.

This isn't the first time that I've had problems like that with firefox. I have hated it since I first used it, over 20 years ago. It shows other issues, like random loss of page navigation and misplaced button sensitivity areas. Why haven't I got rid of it long ago?

The answer is simple: I can't get chromium, the obvious alternative, to work with multiple instances. Time to ask the twins, who should have a vested interest. They came up with a number of suggestions, some contradictory, but ultimately I was able to start multiple instances. I'm still trying to get my head around it, but in essence it seems that I need to remove the singletons and use separate configuration directories for each instance. firefox does that too, but it doesn't require as much fiddling.

Done? No, I also need to invoke the browser from Mutt. And once again it's a can of worms. The twins tell me to put this in ~/.muttrc (after substitutions for my environment):

text/html; chrome --display=:0.2 --user-data-dir=~/.config/chromium-2 %s; test=test -n "$DISPLAY"; nametemplate=%s.html

Part of that (the nametemplate) is to work round breakage in chromium: it ignores the content of the file it's displaying and goes by the “extension”, which must be .html. By contrast, with firefox, my .mailcap contains

text/html; /home/local/bin/dobrowser %s; copiousoutput

OK, dobrowser is a copout, but it's just so that I can access the file elsewhere. It contains:

WEBPAGE=/eureka/home/var/tmp/mutt-firefox/`basename $1`.html mv $1 $WEBPAGE /usr/local/bin/firefox $WEBPAGE

But that doesn't matter. Gemini's invocation doesn't work. Instead I kept the dobrowser approach and change the last line to:

chrome --display=:0.2 --user-data-dir=/home/grog/.config/chromium-2 $WEBPAGE

And that seems to work. But what a mess by comparison. Clearly chromium is firmly entrenched in the Microsoft space, even worse than firefox.

Warning! Breakin!

Topic: technology, opinion

Link here

Message from eBay today:

We noticed a new sign-in on your account at ebay.com.au. Here are the details: Time of sign-in 14/07/2026 11:57 AM AEST Device Linux (Chrome 143.0) Approximate location Sydney, New South Wales, Australia If this was you, there’s nothing you need to do. If it wasn’t, please change your password right away.

Now isn't that accurate and helpful? The “device” hadn't changed, just the browser, located 1,000 km to the south-west of Sydney, in a different state, and running on a different operating system. If they're going to warn, why can't the finally report correctly and with more details (IP address comes to mind)?

Clue to Emacs indentation problems

Topic: technology, opinion

Link here

Reading my diary for 20 years ago, found a reference to my Emacs indentation macros. It's not clear that it's what I was using before the last update, but the clue might be in where I kept it. It still works on eureka, so I haven't lost it.

Wednesday, 15 July 2026	Dereel
		Top of page
		previous day

A day spent fighting chrom*

Topic: technology, opinion

Link here

My transition from firefox to Chromium continues. It's almost working, but fixing the remaining issues took up most of the day.

What's the problem? Somehow the name is symptomatic. What's it called? It seems that though the name is Chromium, it calls itself chrome, really the name of a different product. And it's firmly entrenched in the Microsoft mentality. I spent a lot of time trying to get Mutt to display on a chrom* window. Yes, I had done it yesterday, but it was less than ideal. It creates a new window rather than a new tab. I can live with that, but it holds on to the mutt session until it is done, and if I press ^C on the mutt window, the chrom* window closes. And in the process it creates an amazing amount of vomit on the mutt window, including:

[-- Autoview using /home/local/bin/dobrowser '/home/grog/mutt-hydra-1004-41029-12055955194787228941' --] [-- Autoview stderr of /home/local/bin/dobrowser '/home/grog/mutt-hydra-1004-41029-12055955194787228941' --] [42405:66144074215440:0715/133857.553950:ERROR:dbus/bus.cc:406] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [42405:66144074133520:0715/133857.598521:ERROR:dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path=/org/freedesktop/DBus: unknown error type: [42405:66144074133520:0715/133857.607001:ERROR:dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.DBus.Properties.GetAll: object_path= /org/freedesktop/UPower/devices/DisplayDevice: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not [42405:66144074223632:0715/133900.384970:ERROR:google_apis/gcm/engine/registration_request.cc:292] Registration response error message: DEPRECATED_ENDPOINT

OK, that's simple. Background it:

chrome --new-tab --display=:0.2 --user-data-dir=/home/grog/.config/chromium-2 $WEBPAGE &

But it didn't work. mutt was still suspended! How could that happen? Much more interaction with Google Gemini, receiving suggestions which were mostly wrong and included things like the /proc file system and interaction with systemd, which I thought was not universal even on Linux. The invalid suggestions were still interesting for the approaches that I wouldn't have considered. And somehow it's far too cosy with D-Bus and other strange things.

OK, how about the man page?

=== grog@hydra (/dev/pts/39) ~ 163 -> man chromium No manual entry for "chromium" === grog@hydra (/dev/pts/39) ~ 164 -> man chrome @@PACKAGE(1) USER COMMANDS @@PACKAGE(1) NAME @@PACKAGE - the web browser from Google SYNOPSIS @@PACKAGE [OPTION] [PATH|URL] DESCRIPTION See the Google Chrome help center for help on using the browser. <https://support.google.com/chrome/> OPTIONS @@MENUNAME has hundreds of undocumented command-line flags that are added

Now doesn't that give the impression of a polished, complete product? That's especially the case because, of all the hundreds of flags, it describes exactly nine, including --version. But the twins have help available:

It is widely used by developers because it stays continuously up to date and lists thousands of available switches, along with explanations and their origin files in the Chromium codebase

It tells me:

These are the 1,349 command line switches and 3,086 feature flags defined in Chromium as of July 15, 2026.

But it only showed four switches! Clearly others are hidden in a non-intuitive manner, but I am clearly not modern enough to understand.

In the end, I gave up. The only improvement was invoking a daemon to help me:

daemon -f chrome --new-tab --display=:0.2 --user-data-dir=/home/grog/.config/chromium-2 $WEBPAGE &

After that, things almost worked. I couldn't get it to attach to an open window. Well, maybe not. The first display always opened a new window, but after daemonizing the instance, subsequent invocations opened a new tab in that window.

What to do with makefs?

Topic: technology, opinion

Link here

I still have this open bug report about makefs, a program that builds a file system in a file and then populates it. The delay is at least partially due to laziness, but the more I think about it, the more I wonder what use it is.

We already have a program called newfs that does the first half of the task on a device, and last week Kirk McKusick pointed that out. But what neither of us knew was that newfs will happily build a file system in a file. I tried it out then and ran into minor problems, like incorrect summary information even after fsck:

=== root@dereel (/dev/pts/5) ~ 53 -> truncate -s 512k foo === root@dereel (/dev/pts/5) ~ 56 -> /hydra/home/grog/work/newfs/newfs.full ~/foo /root/foo: 0.5MB (1024 sectors) block size 32768, fragment size 4096 using 1 cylinder groups of 0.50MB, 16 blks, 128 inodes. with soft updates super-block backups (for fsck_ffs -b #) at: 192 === root@dereel (/dev/pts/5) ~ 57 -> mdconfig -a -t vnode -f ~/foo md0 === root@dereel (/dev/pts/5) ~ 59 -> mount /dev/md0 /mnt2 === root@dereel (/dev/pts/5) ~ 61 -> df /mnt2 Filesystem 1048576-blocks Used Avail Capacity Mounted on /dev/md0 0 0 0 3% /mnt2

Why are all the block counts 0? Because I said so (via the BLOCKSIZE environmental variable): I'm counting in megabytes, and this file system is smaller than one megabyte. Count in kilobytes and all seems well:

=== root@dereel (/dev/pts/5) ~ 62 -> df -k /mnt2 Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/md0 316 8 284 3% /mnt2 === root@dereel (/dev/pts/5) ~ 63 -> ls -l /mnt2 total 1 drwxrwxr-x 2 root operator 512 16 Jul 12:42 .snap

So what do we need? The commands above are sufficient to create the file system. Then the data needs to be copied; we have plenty of commands for that. And then destroy the vnode device. A simple shell script should be enough. But maybe I'm missing something: there are a surprising number of reports open about makefs. Maybe I should first find out why before removing it from the tree.