|
| Greg's diary |
| December 2019 |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sunday, 1 December 2019 | Dereel | Images for 1 December 2019 |
| Top of page | ||
| next day | ||
| last day |
|
Garage sales, day 2
|
Topic: general | Link here |
After yesterday's fun with garage sales, we had had enough. But one was still of interest, at 111 Stones Road, almost our next-door neighbour (only 800 m away). Up early to take a look, but ultimately didn't find much of interest. It seems that things were hopping yesterday morning, though.
|
Recovering lagoon, day 2
|
Topic: technology, opinion | Link here |
On with the recovery of lagoon today. In principle, it's simple. Change /boot/loader.conf on the first bootable partition:
=== root@lagoon (/dev/pts/3) /usr/src 36 -> rcsdiff -wu /destdir/boot/loader.conf
--- /destdir/boot/loader.conf 2017/10/04 22:51:33 1.1
+++ /destdir/boot/loader.conf 2019/12/01 01:06:44
@@ -1,5 +1,5 @@
-currdev=disk0p1
-rootdev=disk0p1
+currdev=disk0p4
+rootdev=disk0p4
Copy or merge the important files in /etc/ to the new root partition, and we're away.
Oh. The loader can't find the root partition. Somehow I had messed up my file systems, and the new /etc/fstab still reflected the old Vultr system:
# Device Mountpoint FStype Options Dump Pass#
/dev/ufs/rootfs / ufs rw 1 1
Yes, that didn't work. Quite a few files in /etc/ still needed updating, including files not under revision control. Morale: save all config files in RCS, even if they're not changed. That way I at least have an indication of what else I needed to do.
And apart from that? Email continues to be a pain, and I got messages that I didn't expect:
Dec 1 13:12:52 lagoon sm-mta[1144]: alias database /etc/mail/aliases.db out of date
And strangely it stayed that way after running newaliases:
=== root@lagoon (/dev/pts/3) /usr/src 42 -> l /etc/mail
...
-rw-r--r-- 1 root wheel 1,698 1 Dec 10:22 aliases
-rw-r----- 1 root wheel 131,072 8 Nov 15:22 aliases.db
But clearly I need to spend more time going through the postfix configuration with a fine tooth comb. /usr/local/etc/postfix/main.cf is currently at revision 1.18
revision 1.18
date: 2007/03/08 04:43:19; author: grog; state: Exp; lines: +6 -5
Adapt to local environment.
...
revision 1.1
date: 2001/02/06 01:31:46; author: grog; state: Exp;
Initial revision
Interestingly, it really seems that it hasn't changed in nearly 13 years, since before we moved to Dereel.
|
Google: don't obfuscate
|
Topic: technology, opinion | Link here |
Juha Kupiainen came up with some interesting information today: Google Slammed Over Chrome Change That Strips 'www' From Domain URLs . But it seems that Google doesn't care:
When asked about this change in a long discussion thread on a mailing list, a Google staffer wrote: "www is now considered a 'trivial' subdomain, and hiding trivial subdomains can be disabled in flags (will also disable hiding the URL scheme)..."
They may consider that to be the case. They clearly haven't considered the DNS implications of using the domain name as the web server name. And it still violates POLA. Fortunately, somebody has come up with instructions on how to stop it doing this stuff. Hopefully it will still work if I ever find myself forced to use Chrome.
|
Rusty Wrench again
|
Topic: photography, technology, opinion | Link here |
Mail from Linux Australia today, soliciting nominations for next year's “Rusty Wrench Award”:
The Rusty Wrench Award is Australia's highest honour for community contributions to the Open Source movement in the country. It was eponymously named after luminary Rusty Russell, one of Australia's most prominent contributors and community members, founder of linux.conf.au (as CALU, in 1999), and the inaugural recipient of the award.
And how about that, I was there at the first presentation, nearly 15 years ago at the conference dinner for linux.conf.au. And though I didn't mention it in my diary at the time, I did take a photo:
Not a very good photo; this was 2005, after all, and my camera (Nikon “Coolpix” 880, with only 3 megapixels, and already a few years old) was not the best. But that's not the original image; I have enhanced it (if that's the correct word) with DxO PhotoLab. Originally it looked like the left-side image (run the cursor over an image to compare it with its neighbour):
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Things would be even better if Ashampoo optimizer would still work, but in this specific case the new “green background” bug makes it unusable.
|
Flowering Solanum?
|
Topic: gardening, photography, opinion | Link here |
Nine months ago I noticed some particularly active Solanum laciniatum bushes. But today they're flowering even more:
|
||||||||||||||||||||||||
Where? Walking past, the flowers reach out and grab you. Why is there nothing to be seen in a photo? Yes, they're there, but somehow the photo (any photo) hides them.
|
First tomato of summer
|
Topic: gardening | Link here |
It's only been a couple of weeks since I planted this tomato plant, a „Riesentraube“:
|
||||||||||||||||||||||||
I wonder how long before it will bear usable fruit.
|
Food poisoning from raw fish?
|
Topic: food and drink, opinion | Link here |
When I answered questions on Quora, one of the recurring questions related to food poisoning. Eat food that hasn't been cooked to at least 145° and you run the risk of food poisoning.
One thing is common to all these questions, and the temperature itself shows it: clearly 145° is not a normal temperature for anything you eat. It uses the old Fahrenheit scale (and corresponds to about 63° C). It seems that this phobia is a very US American thing, and the idea of eating undercooked or even uncooked food (like the sashimi that we ate yesterday) probably sets off people's reactions without them actually having to eat anything.
But this morning I got up and discovered that Yvonne had forgotten to put the leftover sashimi into the fridge. Had it? Took a sniff. No, seemed perfectly normal. So I put it in the fridge and we ate it in the evening. Admittedly I had a few misgivings, but again, it tasted normal. And we had no ill effects.
How dangerous are raw animal foodstuffs really? Under what circumstances could you get sick from food that tastes normal?
| Monday, 2 December 2019 | Dereel | Images for 2 December 2019 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
Understanding postfix
|
Topic: technology, opinion | Link here |
So lagoon is up and running, and so far Yvonne hasn't found anything wrong. But there's still the mail configuration to worry about, and it occurs to me that I haven't really ever understood postfix. That's why I still use a configuration that I cobbled together 18 years ago, and which I have been hacking ever since.
Today I had two main problems. Firstly, I don't really understand postfix's main.cf configuration file. I've told it to use a virtual map for delivery outside the local system:
# $Id: transport,v 1.5 2012/07/10 02:44:24 grog Exp $
# While they're blocking 25
* smtp:eureka.lemis.com
postmap then converts this to a database format. That works, but postfix ignores it! Configuration issue? I have:
transport_maps = hash:/usr/local/etc/postfix/transport
And that's also what's in my other configuration files. But on lagoon what I get is:
Dec 2 12:09:36 lagoon sm-mta[4995]: xB219aVd004995: from=<grog@lagoon.lemis.com>, size=377, class=0, nrcpts=1, msgid=<201912020109.xB219Z8P004994@lagoon.lemis.com>, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
Dec 2 12:09:36 lagoon sendmail[4994]: xB219Z8P004994: to=grog@freebsd.org, ctladdr=grog (1004/1000), delay=00:00:01, xdelay=00:00:00, mailer=relay, pri=30045, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (xB219aVd004995 Message accepted for delivery)
Dec 2 12:09:48 lagoon sm-mta[4997]: STARTTLS=client, relay=mx1.freebsd.org., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Dec 2 12:09:51 lagoon sm-mta[4997]: xB219aVd004995: to=<grog@freebsd.org>, ctladdr=<grog@lagoon.lemis.com> (1004/1000), delay=00:00:15, xdelay=00:00:15, mailer=esmtp, pri=30377, relay=mx1.freebsd.org. [96.47.72.80], dsn=2.0.0, stat=Sent (Ok: queued as 47R6Tn5KDjz4Slv)
Oh. Not what I intended, but what I wanted. Looking at the message when it came back confirmed:
Received: from lagoon.lemis.com (167-179-139-35.a7b38b.mel.nbn.aussiebb.net [167.179.139.35])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
server-signature RSA-PSS (4096 bits)
client-signature RSA-PSS (2048 bits) client-digest SHA256)
(Client CN "guest.localhost", Issuer "guest.localhost" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id 47R6Tn5KDjz4Slv
for <grog@freebsd.org>; Mon, 2 Dec 2019 01:09:48 +0000 (UTC)
(envelope-from grog@lagoon.lemis.com)
In other words, my network link no longer blocks SMTP. That's excellent news—if it lasts. It means that I no longer have to use this kludge mail tunnel to www.lemis.com. But it doesn't help in the slightest in understanding what postfix is doing.
By comparison, the other problem hasn't gone away. newaliases, once the part of sendmail responsible for creating /etc/mail/aliases.db, is now a new alias for postfix, and though it complains about the content of aliases, it doesn't change that file. This is not related to the upgrade of lagoon; it happens exactly the same way on eureka:
=== root@eureka (/dev/pts/6) ~ 116 -> newaliases
postalias: warning: /etc/aliases.db: duplicate entry: "mailer-daemon"
postalias: warning: /etc/aliases.db: duplicate entry: "postmaster"
...=== root@eureka (/dev/pts/6) ~ 117 -> l /etc/mail
...
-r--r--r-- 1 root wheel 13,350 3 Dec 11:26 aliases
-rw-r----- 1 root wheel 131,072 30 Dec 2013 aliases.db
This doesn't matter for postfix, but there are other programs, like mail(1), that look at /etc/aliases.db and complain:
Dec 2 12:09:03 lagoon sm-mta[4988]: alias database /etc/mail/aliases.db out of date
That's really a problem, since I can't find a way to rebuild the file, and messages that should end up with me go to root instead. More head-scratching.
|
Microwave oven usability
|
Topic: food and drink, opinion | Link here |
Since we got our first “inverter” microwave oven over 12 years ago, we've found one of the best features to be the fact that you can soften butter with them. As a result, we've ensured that the two successor machines are also “inverter” machines.
But the newest, the Sharp R350EW, bought in August, doesn't seem to do it as well as its Panasonic predecessors:
|
|||||||||||||||||||||||
That was done at 100 W, the same rating as the Panasonics, for 90 seconds. It seems that the power distribution of the Sharp is not as uniform. Presumably the hole is in the exact centre of the turntable, where rotation doesn't help. And so it seems that putting the butter to one side would work around the problem. So would doing it in the newer Panasonic oven, which is still in service.
| Tuesday, 3 December 2019 | Dereel | Images for 3 December 2019 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
lagoon again
|
Topic: technology, opinion | Link here |
Basically things are working on lagoon now. Email continues to be a problem, but I have workarounds for the time being, and I'll need to spend more time to consider all the issues.
Apart from that, there are things like the nightly backups. They're run from a cron job in /etc/crontab:
0 21 * * * root /home/local/bin/cleanup
But for some reason it doesn't get started, and there's no obvious reason why not.
As expected, there were problems running my photo software. The strangest one was:
=== yvonne@lagoon (/dev/pts/1) ~/Photos/20191203 26 -> for i in `ls *.jpeg *.gif *.png 2>/dev/null`; do echo $i; done | by 2 /Photos/Tools/mktinysmall.php /Photos/Tools `pwd` tiny 67500; MYDIR=`pwd`; IMAGELINKS=`pwd`/Imagelinks; if [ -f $IMAGELINKS ]; then (cd ~/public_html/Photos/`basename $MYDIR`/tiny && checkimagelinks $IMAGELINKS tiny); fi
sh: /Photos/Tools/mktinysmall.php: not found
sh: /Photos/Tools/mktinysmall.php: not found
sh: /Photos/Tools/mktinysmall.php: not found
sh: /Photos/Tools/mktinysmall.php: not found
Huh? That file is there. Isn't it? Yes:
=== yvonne@lagoon (/dev/pts/1) ~/Photos/20191203 27 -> l /Photos/Tools/mktinysmall.php
-r-xr-xr-x 1 grog lemis 1,927 16 Feb 2013 /Photos/Tools/mktinysmall.php
So what's the problem? Pull it out of the loop and try again:
=== yvonne@lagoon (/dev/pts/1) ~/Photos/20191203 25 -> /Photos/Tools/mktinysmall.php
bash: /Photos/Tools/mktinysmall.php: /usr/local/bin/php: bad interpreter: No such file or directory
Aaah! Missing port. Now wasn't the message from sh helpful? OK, off to install.
=== root@lagoon (/dev/pts/3) ~ 110 -> pkg install php
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'php' have been found in the repositories=== root@lagoon (/dev/pts/3) ~ 112 -> pkg search php | wc -l
2843
Which of the 2,843 php ports should I install? How I wish that there were a canonical port name for these things! They seem to have managed it for Emacs. Why not for PHP?. Finally found php74 and installed it, and despite my concerns (much newer version) it worked as expected. But it shouldn't be such a pain.
|
Email requirements
|
Topic: technology, opinion | Link here |
Email proves to be a bigger problem than I had expected. I need to take a step back and think what I really need, and then how I achieve it. There are at least three separate configurations:
Firstly, the main email configuration at eureka, externally better known as mx0.lemis.com. This is the final destination for all mail to lemis.com. What do I need?
Send mail to the outside world with a uniform domain name @lemis.com. This is not the standard, which leaves the complete hostname (for example @lagoon.lemis.com). This is not just cosmetic: lagoon.lemis.com is not accessible from the outside world.
Accept all valid mail. I'm pretty sure that this is a standard configuration, but it needs to be understood, since it's not the case for higher-level MX systems.
Reject spam. The tools that postfix provides are pretty minimal, but they're there. There are three basic approaches: check the recipient, check the sender and check the client MTA. I have these in place for incoming mail, though many are out of date. For example, my access file is at least 13 years old and refuses domain names like 123bizweb.com, 1-GLOBAL.COM and 1STFAMILY.COM, all of which have probably been there for the best part of 20 years. Do they still send spam? 123bizweb.com doesn't: it no longer exists. Who knows about the others? So at the very list I need to go through these files, and they're not short:
=== root@eureka (/dev/pts/11) /usr/local/etc/postfix 504 -> wc -l access accept-to client-access
Probably the best approach is to start again.
Another tool is checking consistency. There are plenty of issues there, like SPF compliance (broken by many mailing lists), reverse lookup (does anybody not provide that any more?) and MTA name checking, of which I have fallen foul myself. But that's for later.
Then there are the higher-order MX servers. This currently “works”, though I'm not convinced that everything works well. They require
Finally, other machines, both local (lagoon) and remote (ffm.lemis.com for example). It's not clear that I even need an MTA on lagoon, but the principle is the same, and I should have an MTA on ffm and possibly other external servers that I may create. In principle, they only need to send. That should be an out-of-the-box configuration, but I need to reconsider after I have done the other two.
|
YouTube reviews: fake news?
|
Topic: photography, technology, opinion | Link here |
I've already taken Tony Northrup to task for his misinterpretation of “ISO” and his claims of the demise of the Micro Four Thirds system. In the latter case, in particular, I suspected that he was paid to spread rumours, as he did two weeks ago again about Olympus closing their camera business.
But it seems that he doesn't just have it in for Olympus. He also has a clip Nikon is DYING “(but it's not too late)”, and most intriguingly, Are DSLR Cameas DEAD?!.
That seemed worth watching. It seems that Ricoh (the only serious camera maker without a mirrorless offering) has claimed Ricoh Thinks Mirrorless Shooters Will Switch Back to DSLRs in 1-2 Years. They're not alone: yes, Tony says, DSLRs will make a comeback.
His argumentation is amazing. He compares mirrorless cameras (a clear technological advance) with DVD Audio and Super Audio CD (attempts at marketing fragmentation). He looks at numbers based on Amazon's top 100 list, noting in passing that CIPA has other figures.
I didn't know about Amazon's top 100 list, so I went looking. Yes, it's interesting, and it's based on Amazon's recent sales. But there are separate lists for DSLRs and mirrorless cameras, and the lists are updated every hour, clearly reflecting recent sales (though it's clear that that doesn't need to mean exactly the sales in the previous 60 minutes). But there are so many reasons not to use it as reflective of real sales.
From this dubious base he makes projections and claims that lens makers will be reluctant to bring out new lenses for mirrorless cameras, ignoring the large number that have been introduced: DSLR lenses fit mirrorless too, mirrorless don't fit DSLRs.
What's completely missing from his argumentation (and from Ricoh's claims, for that matter) are hard technical facts. How will any DSLR maker be able to bring out lenses like Nikon's 58 mm f/0.95 Noct? Or any number of other lenses too difficult to make with DSLRs? How do you do macro work, where a DSLR viewfinder is too dim? How do you do video? (Answer to that one: simulate a mirrorless camera, because that's all you have when you flip the mirror to take video with a DSLR).
The bottom line, though, is that many people listen to people like Northrup. He's a marketing factor, and he's clearly available for hire. I don't think it's worth listening to anything he has to say any more.
|
New wildflowers
|
Topic: gardening | Link here |
I would have thought that by now I had seen most of the wildflowers that there are around here. But I don't think that I've seen these ones (in Westons Road) before:
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
| Wednesday, 4 December 2019 | Dereel | Images for 4 December 2019 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
lagoon continued
|
Topic: technology, opinion | Link here |
OK, lagoon is up and running, but I had had some strange problems installing the userland after the last buildworld, probably as a result of moving file systems around. OK, update and build the latest FreeBSD 12-STABLE.
It crashed on me! And in a way I know:
Dec 4 09:05:05 lagoon kernel: pid 4073 (c++), jid 0, uid 0, was killed: out of swap space
Dec 4 09:05:07 lagoon kernel: pid 4082 (c++), jid 0, uid 0, was killed: out of swap space
Huh? I have 20 GB of swap! Don't I?
=== root@lagoon (/dev/pts/3) /usr/src 140 -> pstat -s
Device 1048576-blocks Used Avail Capacity
/dev/ada0p3 0 0 0 98%
Huh? Oh: /etc/fstab contains:
# Device Mountpoint FStype Options Dump Pass#
/dev/ada0p1 /destdir ufs rw 1 1
/dev/ada0p3 none swap sw 0 0
/dev/ada0p4 / ufs rw 1 2
That makes sense. All my system disks have the same partitioning: partition 1 is the first root file system, partition 2 is the boot partition, partition 3 is swap, partition 4 is the second (alternative) root file system, the one I'm using now, and partition 5 is the (big) remainder file system. But gpart sees a different view:
=== root@lagoon (/dev/pts/3) /usr/src 145 -> gpart show
=> 40 3907029088 ada0 GPT (1.8T)
40 83886080 1 freebsd-ufs (40G)
83886120 41943040 2 freebsd-swap (20G)
125829160 1024 3 freebsd-boot (512K)
125830184 83885048 4 freebsd-ufs (40G)
209715232 3697313895 5 freebsd-ufs (1.7T)
It seems that I partitioned lagoon before I settled on this scheme, and here swap is partition 2. But for convenience I copied the fstab from teevee. And it seems that swapon was clever enough not to use the partition.
Or was it? The summary at the end of the aborted kernel build showed 6 page swaps. Why the 0 in the output of pstat? Because BLOCKSIZE was 1048576 (1 MB), and the partition was only 512 kB in size.
So: did I swap to the boot code or not? Copied the partition to a file and compared with the boot partitions on teevee and subsequently on eureka:
=== root@eureka (/dev/pts/6) /var/tmp 149 -> cmp bootpartition.eureka bootpartition.teevee
bootpartition.eureka bootpartition.teevee differ: char 28, line 2=== root@eureka (/dev/pts/6) /var/tmp 150 -> cmp bootpartition.eureka bootpartition.lagoon
bootpartition.eureka bootpartition.lagoon differ: char 1815, line 18=== root@eureka (/dev/pts/6) /var/tmp 151 -> cmp bootpartition.teevee bootpartition.lagoon
bootpartition.teevee bootpartition.lagoon differ: char 28, line 2
That doesn't help much. OK, reinstall the boot code and try again:
=== root@lagoon (/dev/pts/3) /usr/src 16 -> gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 3 ada0=== root@lagoon (/dev/pts/3) /usr/src 17 -> dd if=/dev/ada0p3 of=/eureka/home/var/tmp/bootpartition-2.lagoon
...=== root@eureka (/dev/pts/6) /var/tmp 152 -> cmp bootpartition*lagoon
bootpartition-2.lagoon bootpartition.lagoon differ: char 28, line 2
So at the very least the bootcode that I just installed is different from what was there before. Was the old code still OK? Hard to say, but it's so easy to reinstall, and so hard to recover if you have a machine with no boot code.
|
More mail forwarding insights
|
Topic: technology, opinion | Link here |
I worked around my problems with /etc/mail/aliases on lagoon by creating a file /root/.forward that forwarded all email to groggyhimself@eureka.lemis.com. And that works, and I'm getting root mail for lagoon again. And then on a hunch I did:
=== root@lagoon (/dev/pts/3) /usr/src 6 -> diff /destdir/root/.forward ~/.forward=== root@lagoon (/dev/pts/3) /usr/src 7 ->
That's exactly what I did last time! So it's quite possible that mail on lagoon hasn't been working properly for a long time.
|
/etc/crontab problems: solved?
|
Topic: technology, opinion | Link here |
Why isn't cron on lagoon honouring the contents of /etc/crontab? Spent some time RTFMing, without any obvious insights. And then I checked the log files:
Dec 2 09:43:00 lagoon /usr/sbin/cron[900]: (*system*) RELOAD (/etc/crontab)
OK, clearly it's looking at /etc/crontab, and presumably it's doing it automatically. But that was 2 days ago, and it was the only time. When does it reload? When the file is updated, in other words when the modification time stamp increases?
=== root@lagoon (/dev/pts/0) /etc/X11 20 -> l /etc/crontab
-rw-r--r-- 1 root wheel 768 30 Jun 2018 /etc/crontab
That makes sense. I had copied it from the old partition with cp -p, so the modification timestamp was unchanged. And when?
=== root@lagoon (/dev/pts/0) /etc/X11 21 -> l -c /etc/crontab
-rw-r--r-- 1 root wheel 768 2 Dec 22:14 /etc/crontab
Problem solved, indirectly, on rebooting the new system.
|
X problems
|
Topic: technology, opinion | Link here |
One of the puzzling things I had with lagoon was still outstanding when I started the upgrade: Two years ago I put in the current display card, which identifies as:
[ 1606.734] (II) NVIDIA(0): NVIDIA GPU GeForce GT 710 (GK208) at PCI:1:0:0 (GPU-0)
That's very convenient, because on teevee I had:
[ 18.506] (II) NVIDIA(0): NVIDIA GPU GeForce GT 710 (GK208) at PCI:1:0:0 (GPU-0)
In other words, exactly the same hardware. The fact that it worked so well in teevee was the main reason I put one in lagoon. But it didn't work! At the time I just gave up and installed the standard nv driver.
Clearly a cop-out. So today I tried again, again ending in failure. In the process I saw a message in /var/log/Xorg.0.log that I have never seen before:
[ 1605.758] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[ 1605.758] (WW) Disabling Keyboard0
[ 1605.758] (WW) Disabling Mouse0
And sure enough, keyboard and mouse were dead in the water.
The remaining content of the log file is similar to what I had 2 years ago, but different enough to be hard to interpret. But it seems that the big difference is here:
[ 1606.735] (II) NVIDIA(0): Validated MetaModes:
[ 1606.735] (II) NVIDIA(0): "NULL"
That contrasts with the contents of the file on teevee:
[ 33.442] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:1:0:0
[ 33.442] (--) NVIDIA(0): CRT-0
[ 33.442] (--) NVIDIA(0): CRT-1
[ 33.442] (--) NVIDIA(0): DFP-0
[ 33.442] (--) NVIDIA(0): DFP-1 (boot)
...
[ 33.443] (II) NVIDIA(0): Detected PCI Express Link width: 16X
[ 33.463] (--) NVIDIA(GPU-0): CRT-0: disconnected
[ 33.463] (--) NVIDIA(GPU-0): CRT-0: 400.0 MHz maximum pixel clock
[ 33.463] (--) NVIDIA(GPU-0):
[ 33.464] (--) NVIDIA(GPU-0): CRT-1: disconnected
[ 33.464] (--) NVIDIA(GPU-0): CRT-1: 400.0 MHz maximum pixel clock
[ 33.464] (--) NVIDIA(GPU-0):
[ 33.467] (--) NVIDIA(GPU-0): DFP-0: disconnected
[ 33.467] (--) NVIDIA(GPU-0): DFP-0: Internal TMDS
[ 33.467] (--) NVIDIA(GPU-0): DFP-0: 330.0 MHz maximum pixel clock
[ 33.467] (--) NVIDIA(GPU-0):
[ 33.482] (--) NVIDIA(GPU-0): XXX TV (DFP-1): connected
[ 33.482] (--) NVIDIA(GPU-0): XXX TV (DFP-1): Internal TMDS
[ 33.482] (--) NVIDIA(GPU-0): XXX TV (DFP-1): 230.0 MHz maximum pixel clock
[ 33.482] (--) NVIDIA(GPU-0):
[ 33.485] (II) NVIDIA(0): Validated MetaModes:
[ 33.485] (II) NVIDIA(0): "DFP-1:1920x1080"
[ 33.485] (II) NVIDIA(0): "DFP-1:1280x720"
In other words, no mention of any devices attached to the card. Why? At first I thought that it might be that the monitor wasn't providing any EDID data, but that wouldn't explain the reference to non-existent devices like CRT-0 on teevee. I still have the old card from teevee, so I should try that out.
|
Revenge through spam
|
Topic: technology, general, opinion | Link here |
I can't be the only person who is receiving torrents of spam from RAY-BAN and UGG BOOTS. Time to update my ~/.procmailrc file. Why do renowned companies resort to such tactics?
Why, do renowned companies resort to such tactics? While looking at things to filter on, noticed that the headers appear to have nothing to do with the companies:
From: "RAY-BAN[2019]" <obama@dgpcm.com>
From: "RAY-BAN" <lucy@roses18.com>
From: "RAY-BAN[2019]" <coupons@dgpcm.com>
From: "UGG BOOTS" <lucy@shqmcg.com>
And so on. Interestingly, the domain part of the email address is correct, and they're presumably expecting people to use toy MUAs that are too polite to show the originator's email address. So whoever is sending these messages appears to have nothing to do with the companies they claim to represent. Are they trying to get them to pay to stop?
|
Leonid does a runner
|
Topic: animals, opinion | Link here |
For a couple of months now we've been letting Leonid run free when we walk the dogs. We only want one to go free so that they won't feel obliged go head off together into the Wild Blue Yonder. Originally we had decided to let Nikolai run free, but on that occasion he got bitten by an electric fence, and I had to save him. Since then he feels insecure if he's not on a lead.
So it's Leonid. But today he misbehaved: for no obvious reason, he ran down the driveway of Fay (neighbour in Grassy Gully Road, whose surname I have forgotten). Wouldn't come back, and I had to go and get him. Fortunately there was a gate at the other end, so I was able to catch him. But that's really disappointing. Should we keep him on a lead from now on?
| Thursday, 5 December 2019 | Dereel | Images for 5 December 2019 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
Peace!
|
Topic: general | Link here |
It's been a busy week, but finally the activity is subsiding. All I really did today was to write my diary. And it's so relaxing.
|
Harrisons Road house
|
Topic: general, Stones Road house | Link here |
We're observing the progress of the new house by JG King in Harrisons Road. It started construction about 2 weeks earlier than our house five years ago. Now they've started bricking:
|
|||||||||||||||||||||||
Is the time gap between the houses widening? No, on checking it seems that they started bricking our house on 16 December 2014. I still think they'll move in round Anzac Day or a couple of days earlier.
| Friday, 6 December 2019 | Dereel | Images for 6 December 2019 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
|
TIO complaint
|
Topic: technology, general, opinion | Link here |
Yvonne in round 10:00 this morning with the sad news “We're off the net!”. And so it was. NBN planned outage? Presumably. It would be difficult to recognize an unplanned outage, since just about the whole day, every day, is slated for a “planned outage”.
Fortunately it was relatively short, barely half an hour, but it reminded me that I had set a deadline of last week for some kind of action to be taken. Of course none was. So: off to http://www.tio.com.au/ to enter a complaint.
That in itself was a problem. They wanted all sorts of information that made little sense in context, but then there was a box to enter the details of the complaint. OK, wrote that out and stored it where people can find it. Then tried to paste it in to the box. Sorry, only 1200 characters (about 40%) allowed. OK, paste the first two paragraphs and point to the online version.
Finally “SEND”. Sorry, we don't support this browser. Please upgrade to a supported browser:
|
|
|||||||||
Now isn't that fun? Why didn't they say before? And what are their supported browsers? There was a link, but I didn't follow it, and I closed the window.
Finally found a browser that met TIO's approval and sent the complaint off. Got an automated reply assigning number 2019/12/02636. I hope that the 02636 don't refer to the number of complaints received so far this month. It reinterpreted “when did you become aware of the complaint?” (March 2015, and in itself the question is strange) as “Complaint date”, which potentially could be a problem: at https://www.tio.com.au/complaints-we-can-and-cant-take I read:
We deal with complaints about things that happened, or that you became aware of, within the last two years. We may still be able to help with complaints that are up to six years old, depending on the reason for the delay. Contact us if you’re unsure if we can help.
I think there's a valid case here: I was told that it would stop, and it didn't.
And then there was this question:
|
|||||||||||||||||||||||
But what arrived on the copy was:
Your preferred outcome The RSP can't do anything. This is a problem with the NBN.
They also mangled my carefully written text by removing all white space except single spaces, making it almost illegible. But I suppose they're used to reading the vomit that such systems produce.
Here's the content of the complaint:
This complaint relates to the NBN fixed wireless “service” in Dereel, which I have been using since December 2013. It is the only Internet service available, and the reliability is the worst I have experienced in 30 years using the Internet. I first noticed this problem in June 2014 (http://www.lemis.com/grog/diary-jun2014.php#D-20140607-015618).
Most of the unreliability comes from NBN “scheduled maintenance”, which they have been performing on a regular basis for several years now, causing regular outages of up to 8 hours during the daytime, effectively taking the service offline for a whole day (for example, from 17 October 2019 08:38:34 to 17 October 2019 16:29:26). Since August 2016 I have received a total of 81 outage notifications from my RSP, and there have been some for which I have not been informed, such as on 23 April 2018 (http://www.lemis.com/grog/diary-apr2018.php#D-20180424-001301). I have a complete list of outages at http://www.lemis.com/grog/nbnstats.php which currently shows a total of 418 outages amounting to 11 days, 6½ hours.
The first time I complained was on 13 April 2018 (http://www.lemis.com/grog/diary-apr2018.php#D-20180414-015333), when I was told that these outages were necessary to improve service in the future. But they have been continuing for over 2 years now, and there are always new outages on the horizon. Both the frequency and duration of the outages are on the increase. For the months of July 2019 to October 2019 there were a total of nearly 39 hours of outages, an availability of only 98.52%, or an average of 26 minutes of downtime every day. Currently (6 December 2019) there are three outages scheduled for the next 2 weeks, covering a time frame of 12 days, and with potential outage durations of up to 12 hours. I can't recall a time when there has not been at least one outage scheduled.
I lodged a formal complaint with Aussie Broadband on 3 July 2019 (http://www.lemis.com/grog/diary-jul2019.php#D-20190704-050320), when I was told to expect a call back from the NBN within 1 to 2 weeks, with the fault number #6275739. I didn't hear back.
On 14 November 2019 I checked the progress of the fault number, and couldn't find it. I contacted Aussie Broadband repeatedly, but did not get an explanation for the disappearance of the fault. Instead they raised a new complaint with the NBN, #11411861. I asked for a response by CoB 29 November. So far I have had no contact.
I find this level of service completely unacceptable. While I appreciate that it's not possible to maintain 100% reliability, I find that the current situation is not even close to reliable. If I had an alternative, I would probably take it. As a state-sponsored monopolist, I consider that the NBN has a responsibility to improve its services. There is a Telstra mobile phone tower next to the NBN tower. It uses very similar technology, and I haven't heard of any outages with it.
I fear I won't get much satisfaction.
|
Prima Taste Prawn Mee
|
Topic: food and drink, opinion | Link here |
Last time I was in Geelong I bought a couple of spice mixes to try out, along many established ones. Two were from Prima Taste. Today I tried their Prawn Mee:
|
|||||||||||||||||||||||
The most obvious thing that occurred to me was the price. $8 for 3, maybe 4 portions! Add to that meat and prawns and it's really quite expensive.
On the positive side, they go to a lot of trouble. Most of these things are a single sachet; this one had four, including chili powder, fried shallots and garlic powder (!). OK, make it up, three portions. The results: boring! Also not enough. Somehow they have completely missed the mark.
I also have a laksa from them. I wonder what that will be like.
|
Sick curry tree
|
Topic: gardening | Link here |
Since I've had my curry tree (Murraya koenigii), I've had problems with it. It's particularly prone to mites, and I have been spraying it with pyrethrum at regular intervals. But it didn't help much, and a few months back a salesman at Formosa gardens suggested a very expensive product which proved to be soap water.
Repeated applications. To no avail:
|
|||||||||||||||||||||||
OK, time to clean it out completely and repot it. I don't think it's going to die, but it's certainly not doing well. Does it still have mites?
|
|||||||||||||||||||||||
It's difficult to decide if there's anything alive in that mess. It could just be soap film. Too much, maybe?
Mick Solly, the gardener, was also here today, and spent 5 hours weeding, notably removing the yellow-flowering “ground cover” that he had so carefully planted: it had grown to 40 cm high and completely smothered other things, notably (to his pain; he doesn't use gloves) the cacti.
| Saturday, 7 December 2019 | Dereel | Images for 7 December 2019 |
| Top of page | ||
| previous day |
|
More grid power failures
|
Topic: Stones Road house, general | Link here |
Another two grid power failures today between 11:36:44 and 11:49:50, each a couple of seconds long, but proof that they were real failures and not brownouts. The PV system has made itself paid for the peace of mind it brings, though today might also be the first day where we had a net credit with Red Energy, our grid power supplier: we consumed 5.3 kWh from the grid (so early in the morning, before the break of day), and fed back 24.5 kWh, corresponding to the price of about 10 kWh from the grid.
|
More signs of summer
|
Topic: gardening | Link here |
Gradually it's getting warmer, and about time too. While Sydney burns, we have been subject to cool and moist weather. But the garden is showing that things are improving. The outside clone of the “Uncle Max” Hibiscus rosa-sinensis is gradually producing buds:
|
||||||||||||||||||||||||
One of the Strelitzia reginae (Strelitziis reginarum?) is flowering, and the Strelitzia nicolai apprear so be progressing in that direction:
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
And the chili plant that got burnt by fertilizer seems to be shaking it off:
|
|||||||||||||||||||||||
Further afield, we've found two more flowering bushes at the end of Bliss Road:
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
The first appears to be a Carpobrotus species, and the second an Alyogyne. But I've never seen either in white before. I took a couple of stems of the first, which should grow; I'll have to find a supplier for the Alyogyne.
|
Exposure compensation
|
Topic: photography, opinion | Link here |
I took the photos of the garden flowers with the OM-D E-M1 Mark I, and somehow the viewfinder image didn't look right. Neither did the results. Then I realized: the camera was set to manual exposure, and the photos were overexposed by up to 3 EV.
OK, I can compensate in post-processing. But 3 EV? Tried, and they didn't look too bad, but there was no reason not to Do It Right, so out and took the photos again. Here a comparison of the results:
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
The first pair were really 3 EV apart, and it shows. My attempts at compensation could have been better, but the first is almost acceptable. The second pair were only 1.4 EV apart.
But a lot depends on what I'm aiming for. On a second attempt, I got:
|
|||||||||||||||||||||||
|
||||||||||||||||||||||||
|
|||||||||||||||||||||||
|
||||||||||||||||||||||||
That looks better, but the background of the chili shows a non-recoverable problem: the label is burnt out. There's nothing you can do about that.
|
ALDI “Salmon Wellington”
|
Topic: food and drink, opinion | Link here |
A couple of weeks ago Yvonne bought a deep-frozen “Salmon Wellington” at ALDI, and today we ate it.
I should have been warned by the description: “with cheese & dill sauce”. What an idea! It was intended to be put in the oven and baked (50 minutes, 185° in a fan oven). Presentation wasn't good. The pastry was cracked and broken, and the fish fillet itself was offset by about 3 cm from the middle:
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
The cooking time proved not to be enough: the pastry was still pale. So I grilled it for a while, and after another 10 minutes it looked the kind of colour we wanted.
Cheese & dill sauce? What I found was a completely inappropriate béchamel with little to no taste to it:
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Without the slime it didn't taste too bad, but it would have been cheaper and more flexible to buy some salmon and bake it, probably with a different sauce.
|
Baking peanuts
|
Topic: food and drink, opinion | Link here |
At the end of last month I noted that air fryers aren't ideal for roasting peanuts. But I've never had really good results in the oven, either. Since we needed it on anyway for the salmon, I heated it up half an hour before and tried baking peanuts in it. 160°? 10 minutes? Not nearly enough. Another 10 minutes? Still not enough. Out of time: I had to put in the salmon, which wanted 185°, so I moved them down a notch. And after another 10 minutes they were almost overcooked.
My guess is that they're particularly temperature-sensitive. Next time I'll think of going for 170° and maybe 20 minutes.
| Top of page | Previous month | Greg's home page | Today's diary entry | Greg's photos | Copyright information |
