Marc's Public Blog

Video demo:

got some night training at the same time, did ok on my night landing

here is my blog on the first 10 years (clickme)

Here are all my bestof pictures from the last 20 years: https://photos.app.goo.gl/8EZeGWW6KurJiCAE6

Anyway, here are the 20 year stats:

So yeah, it's really not a lot, but I made the flights count. I also should note that I stopped doing lots of training flights just because, or staying current just to stay current, or getting checked out in more planes that I would reasonably not be able to fly. At this point I pretty much only fly C182, or a 172 when I have to. For the distances I fly, staying current in SR22, the higher prices and lesser availability aren't really worth it (it's the how much time are you saving in flight vs the higher time you spent to be able to save that time).

Highlights for the second 10 years:

Only one unexpected experience in these last 10 years:

So just like I said 10 years ago, I'm going to continue to fly when it makes sense, but it's not my main hobby and I don't see the need to fly myself with weather restrictions if I can fly commercial to the same place (LA area) for a 5th or 10th of the price. But it's nice to know that if there is somewhere unusual to go or the zombie apocalypse happen and all commercial planes are taken down, I have options left :)

And as parting words, some of my bestof bestof pictures:

night flight back from Palm Springs to Palo Alto

Vintage pictures:

the horse racetrack by 101 that is now gone

Moffett Hangar One

Google new campus

and another new campus on the Moffett side

Apple Spaceship Rainbow

Busy SFO

Typical SF day :)

track day at buttonwillow

some dot.com had a small self driving car test track just in front of KPAO

Plane graveyards:

Mountain flying to/from Burning Man:

Squawpine aka Palisades

Back side of Flatstar (the less flat side)

Welcome home :)

5302N that took me there multiple times until an engine failure

Mountain flying to/from Mammoth:

A very cool flying trip to Madras for the total Eclipse

got to see Lassen on the way

Edwards AFB:

Flight from Duxford plane museum to Cambridge:

Hawaii Big Island:

Flight to Oceano and Hearst Castle

wildflowers

Here is to many more years:

so long

A Story About ‘Magic'

Some years ago, I (GLS) was snooping around in the cabinets that housed the MIT AI Lab's PDP-10, and noticed a little switch glued to the frame of one cabinet. It was obviously a homebrew job, added by one of the lab's hardware hackers (no one knows who).

You don't touch an unknown switch on a computer without knowing what it does, because you might crash the computer. The switch was labeled in a most unhelpful way. It had two positions, and scrawled in pencil on the metal switch body were the words ‘magic' and ‘more magic'. The switch was in the ‘more magic' position.

I called another hacker over to look at it. He had never seen the switch before either. Closer examination revealed that the switch had only one wire running to it! The other end of the wire did disappear into the maze of wires inside the computer, but it's a basic fact of electricity that a switch can't do anything unless there are two wires connected to it. This switch had a wire connected on one side and no wire on its other side.

It was clear that this switch was someone's idea of a silly joke. Convinced by our reasoning that the switch was inoperative, we flipped it. The computer instantly crashed.

Imagine our utter astonishment. We wrote it off as coincidence, but nevertheless restored the switch to the ‘more magic’ position before reviving the computer.

A year later, I told this story to yet another hacker, David Moon as I recall. He clearly doubted my sanity, or suspected me of a supernatural belief in the power of this switch, or perhaps thought I was fooling him with a bogus saga. To prove it to him, I showed him the very switch, still glued to the cabinet frame with only one wire connected to it, still in the ‘more magic’ position. We scrutinized the switch and its lone connection, and found that the other end of the wire, though connected to the computer wiring, was connected to a ground pin. That clearly made the switch doubly useless: not only was it electrically nonoperative, but it was connected to a place that couldn't affect anything anyway. So we flipped the switch.

The computer promptly crashed.

This time we ran for Richard Greenblatt, a long-time MIT hacker, who was close at hand. He had never noticed the switch before, either. He inspected it, concluded it was useless, got some diagonal cutters and diked it out. We then revived the computer and it has run fine ever since.

We still don't know how the switch crashed the machine. There is a theory that some circuit near the ground pin was marginal, and flipping the switch changed the electrical capacitance enough to upset the circuit as millionth-of-a-second pulses went through it. But we'll never know for sure; all we can really say is that the switch was magic.

I still have that switch in my basement. Maybe I'm silly, but I usually keep it set on ‘more magic’.

1994: Another explanation of this story has since been offered. Note that the switch body was metal. Suppose that the non-connected side of the switch was connected to the switch body (usually the body is connected to a separate earth lug, but there are exceptions). The body is connected to the computer case, which is, presumably, grounded. Now the circuit ground within the machine isn't necessarily at the same potential as the case ground, so flipping the switch connected the circuit ground to the case ground, causing a voltage drop/jump which reset the machine. This was probably discovered by someone who found out the hard way that there was a potential difference between the two, and who then wired in the switch as a joke.

After upgrading my main server from amd64 to arm64 (rPi), I was forced to re-install all of linux, first time in 25+ years for that server, which included upgrading every single linux package I had t o Debian/Trixie (13). Those upgrades are always "interesting" when you have a lot of history and state, but turns out it went pretty well, except for exim4.

As much as I'm thankful for exim4 and its developers, and all the work they do, I respecfully think the way they implemented tainting on $local_part, the name of the recipient, was poor and with no regard to the cost of countless admins whose configs got broken. Namely:

Exim posts:

So here is what I figured out in the end, after way too many hours (probably more than 10h at this point, which is totally not cool, uprades should not cause downtimes of 10h plus that amount of lost admin time in debugging, research, and fixing): Exim seems to have totally over-reacted to the local_part untrusted data problem, given literally no way to the admin to clean up the variable on their own with a safe regex, maybe provided by exim itself, and seems to force the admin to compare local_part against trusted data on the server only, or it will simply remain tainted and unusable. This is way over the top, especially when you can run a command in pipe without suffering from shell quoting issues.

The solution I found after help from others, is:

mm21_director:
  debug_print = "R: mm21_director for $local_part@$domain"
  driver = accept
  # black magic to populate local_part_data, the untainted version of local_part
  local_parts = dsearch,filter=dir;MAILMAN_HOME/lists
  require_files = MAILMAN_HOME/lists/${lc::$local_part_data}/config.pck
  local_part_suffix = "-bounces:-bounces+*:-confirm+*:-join:-leave:-owner:-request:-admin"
  transport = mm21_transport
.endif

mm21_transport:
  debug_print = "T: mm21_transport for $local_part@$domain"
  driver = pipe
  # In case you wonder, substr_2 removes the leading '-'
  # and the regex removes optional +foo=hostname that can be after -bounce
  # (if you use VERP) -- Marc
  command = MAILMAN_WRAP "${if def:local_part_suffix{${substr_2:{${sg{${lc:$local_part_suffix}}{\\\\\+.*}{}}}}{post}}"
${lc:$local_part_data}
  current_directory = MAILMAN_HOME
  home_directory = MAILMAN_HOME
  user = MAILMAN_UID
  group = MAILMAN_GID

What I had to fix is add "local_parts = dsearch,filter=dir;MAILMAN_HOME/lists" which was 100% required for local_part_data to be populated. Without that, local_part_data is and remains NULL.
It's disappointing how non trivial and over complicated this is, and most importantly how there was no "MUST READ THIS TAINTED UPGRADE" document with proper detailled info around this in one place (not scattered around a very big manual), along with the most common solutions to the very extreme new tainted restrictions.

Useful links I saved along the way:

It's been a while since I've been in XKCD 349 land :) Actually it's a good thing because honestly, it's really not fun and I enjoy other hobbies in my life, too :)

The power of linux is I never really had to re-install my linux system I built in 2000 or so because Debian is just that good. I did do an upgrade from i386 to amd64, but that was possible thanks to biarch in debian and a fancy and impressive in place binary upgrade from ia32/i386 to amd64.

Now, because of this little problem where my amd64 capable server from 2019 was taking way too much power (400W or so), I decided to replace it with an rPi5 which is almost 3 times faster for 20 times less power.

Despite the different binary arch, migrating was not a huge deal, although I still had ancient stuff running python2 that took a while to upgrade, but I figured it was time to get rid of python2 which has been gone from debian for a while (I went to trixie, v13, and it was removed after bulleye, 3 versions ago).
I was almost done with my upgrade and everything being back up, and then came the subject of mailman. Oh, no, mailman!
I used to be a mailman expert in 1999-2000 (yes, really, haha), knew the code well, but it's been 25 years and I've kept using it to run a few lists, but otherwise haven't touched in 25 years.

Of course, by now there is mailman3 that uses python3, but installing that on debian installed dozens of python packages, a new database system and god knows what I just didn't want or didn't need. Worse, I remembered that I have a fancy exim4 config that detects the mailman .pck files and auto provisions lists and aliases. Also, I changed the web interface a bit.

As much as its is yucky, I'm already 3 days into this full server upgrade and not wanting to spend a day or more to learn this new mailman3 and migrate to it, simply because it's not worth my time and I'm just happy to keep my few lists running as is.

So here is what I had to do:

Installing python2 was not too hard, I just had to bring back an old installation for bullseye:

magic:/usr/bin# cat /etc/apt/sources.list.d/debian_bullseye_python2.sources 
Types: deb
URIs: http://deb.debian.org/debian

Suites: bullseye
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.pgp

apt-get install python2.7-minimal
magic:/usr/bin# ln -s python2.7 python2

Amazingly the packages were built well enough that they installed without fuss on trixie, including some dependencies:

moremagic:/etc/apt# apt-get install python2.7-minimal
apt-get defauts to bookworm/stable but system upgraded to trixie/testing 2024/10. May need to use sid if packages will not install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libpython2.7-minimal
Suggested packages:
  binfmt-support
Recommended packages:
  libpython2.7-stdlib python2.7
The following NEW packages will be installed:
  libpython2.7-minimal python2.7-minimal
0 upgraded, 2 newly installed, 0 to remove and 45 not upgraded.
Need to get 1,593 kB of archives.
After this operation, 6,393 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
moremagic:/etc/apt#

Now, mailman2 is python, so we're good, right? Well, not quite. There were some cgi binaries that hardcoded stuff for safety, and were obviously i386 on my system (~mailman/mail/mailman and ~mailman/cgi-bin/*).
I did have server backups going back to 2002 (not bad, haha, and yes they really still work), so I found the source I used back then, but then I realized that trying to rebuild the whole thing might take a while since it's all ancient configure, ancient python, and so forth. Just yesterday I had to rebuild ancient C, and its bundled configure crashed because its "is gcc there" test was not compliant anymore and told me my gcc could not build binaries when in fact the configure gcc test was so old that it was broken, and I just removed it (the rest actually built).

configure:1004: gcc -o conftest    conftest.c  1>&5
configure:1001:1: error: return type defaults to 'int' [-Wimplicit-int]
 1001 | main(){return(0);}
      | ^~~~
configure: failed program was:

After the source failing to build right away due to missing ancient python stuff, I asked myself "eh, can I maybe just get those i386 binaries work on arm64 as is?". And the answer is, yes:

magic:/var/local/mailman/mail# ./mailman 
bash: ./mailman: cannot execute binary file: Exec format error

# install binary emulator, not fast but more than good enough for my needs:
magic:/lib# apt-get install qemu-user-static
The following additional packages will be installed:
  qemu-user qemu-user-binfmt
The following NEW packages will be installed:
  qemu-user qemu-user-binfmt qemu-user-static
Do you want to continue? [Y/n] y
Get:1 http://deb.debian.org/debian trixie/main arm64 qemu-user arm64 1:10.0.3+ds-0+deb13u1 [64.1 MB]
Get:2 http://deb.debian.org/debian trixie/main arm64 qemu-user-binfmt arm64 1:10.0.3+ds-0+deb13u1 [2,068 B]
Get:3 http://deb.debian.org/debian trixie/main arm64 qemu-user-static arm64 1:10.0.3+ds-0+deb13u1 [55.1 kB]

magic:/var/local/mailman/mail# ./mailman 
i386-binfmt-P: Could not open '/lib/ld-linux.so.2': No such file or directory

# copied over libraries from an old system:
magic:/lib/i686# l
-rwxr-xr-x 1 root root  171404 Oct 26 16:38 ld-linux.so.2*
-rwxr-xr-x 1 root root 1993968 Oct 26 16:39 libc.so.6*

magic:/lib# ln -s i686/ld-linux.so.2 .
magic:/var/local/mailman/mail# ./mailman 
Usage: ./mailman program [args...]

Success!

Well, now when I connect, I see:

The Mailman CGI wrapper encountered a fatal error. This entry is being stored in your syslog:
Failure to find group name for GID 33.  Mailman
expected the CGI wrapper to be executed as group
"www-data", but the system's web server executed the
wrapper as GID 33 for which the name could not be
found.  Try adding GID 33 to your system as "www-data",
or tweak your web server to run the wrapper as group
"www-data".

Now, this is actually already good: it means the CGI (i386 code) is running on arm64, but indeed there is a library issue because /etc/groups does have "www-data:x:33:". Strace showed it was looking for libnss_files.so.2, which makes sense.

Copied over the lib
magic:/lib# l /lib/i686/libnss_files.so.2 

-rw-r--r-- 1 root root 50812 Oct 26 17:45 /lib/i686/libnss_files.so.2
magic:/var/local/mailman/cgi-bin# su www-data
magic:/var/local/mailman/cgi-bin$ ./listinfo
  File "/var/local/mailman/scripts/driver", line 107
    print 'Status: 405 Method not allowed'
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)?

By now, things are looking better and https://lists.merlins.org/lists/listinfo is returning

Bug in Mailman version 2.1.14
We're sorry, we hit a bug!
Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs.
[html:/pre+

From there, I had to debug some non trivial permission issues which I think were due to qemu not respecting the setgid bit when running i386 code.
magic:~$ /var/local/mailman/mail/mailman post testlist
Group mismatch error.  Mailman expected the mail
wrapper script to be executed as group "mail", but
the system's mail server executed the mail script as
group "www-data".  Try tweaking the mail server to run the
script as group "mail", or re-run configure, 
providing the command line option `--with-mail-gid=www-data'.

This was all because the CGIs had to be SGID mailman and therefore had to be C binaries because python suid/sgid was considered not safe at the time.  This has been fixed many ways in the last 25 years, but I wanted to keep things as is without getting into new rabbiholes :)

Sadly, it went downhill from there and the 2h rabbithole I was trying to avoid, caused me another one I fell into. But it was cool to see I could run intel binaries on rpi5/arm64 when needed

It did how break sgid which is essential for mailman and it turned out the reasonable path of rebuilding since I did have source and even a source tree from 2002 with the right build options still baked in:
magic:/var/local/src/mailman-2.1.7/src# make clean; make; make install
(...)
for f in admindb admin confirm create edithtml listinfo options private rmlist roster subscribe; do     exe=/var/local/mailman/cgi-bin/$f;     /usr/bin/install -c -m 755 $f $exe;     chmod g+s $exe; done
for f in mailman; do     /usr/bin/install -c -m 755 $f /var/local/mailman/mail;     chmod g+s /var/local/mailman/mail/$f; done

Yeah, that took fewer than 5mn and made native binaries. With that the web pages worked right away, but the Email gateway script was still being difficult and exim4 debugging didn't show the output from it, making it hard to debug. This does not even make it clear what the full command line was (need to go in +dall to see it, barely) ro that the command failed.

Works from command line:
magic:~$ id
uid=8(mail) gid=8(mail) groups=8(mail)
magic:~$ ~mailman/mail/mailman post testlist
From: marc@merlins.org
To: testlist@lists.merlins.org
subject: test 7

test

But when sending through exim:
>>>>>>>>>>>>>>>> Exim pid=1720374 (delivery-local) terminating with rc=0 >>>>>>>>>>>>>>>>
mm21_transport transport returned FAIL for testlist@lists.merlins.org
post-process testlist@lists.merlins.org (2)
LOG: MAIN
  ** testlist@lists.merlins.org F=<root@merlins.org> R=mm21_main_director T=mm21_transport: Tainted arg 2 for mm21_transport transport command: 'testlist'

I guess this said what was wrong, but it wasn't clear to me that tainted was an error and not a warning and that it caused the issue. Now this did become another rabbithole I need to solve with exim4 having made tainting a real pain to deal with, especially for the way I'm using exim4's local_part_data, that is still perfectly safe in my use case, but exim4 sadly decided that I cannot be trusted and is forcing an over strict and quite frankly very over bearing tainting system on me that is just breaking me without providing any easy opt out.

I'm honestly not happy with exim4 on that one, especially the complete lack of useful errors in exim logs and poor documentation that gives easy and actionable steps to get out of this hole.

So now, I'm many hours in trying to figure out how to fix exim4 and I'm really really not impressed at how they forced that overbearing tainting mechanism with very little info on how to easily fix things that it broke and that were working safely.

So, exim4 took much longer to fix than it should have, here's a new page on it:
Part #2 was unfortunately much more painful in an unnecessary way due to a poorly made forced API change in exim4

The more Raspberry Pi specific posts are here:

Before you see the non professional looking mess of wires I built with 2 rPi5 and reclaimed/recycled drives (I only bought 2 new boot 2TB NVME for boot as I want those flash drives to work a long time), I considered another Dell server I had laying at home, not even sure where from or why. Looking it up, it was a Dell DSS1510 which seems to be a cheaper version of the R430. It's a very professional looking server with redundant power and all, and I did consider it, especially since Dell seems to use capacitors that don't just die years later and take the motherboard down with it.

room for 8 2.5 Sata flash drives plugged into an unknow raid card

this shows the MB similar to R430 but with lots of stuff missing to save money

Research showed it was a system from 2016, an upgrade from my existing 2006 server :) but at the same time, do I really want to "upgrade" again to a server that is almost 10 years old? The colo I'm in (via.net, now nextlevel), nicely asked me if I could use less power for the monthly rate they are giving me, and this server can still peak at 200W. Even if it only takes a bit more than 100w, my double rPi5 solution takes less than 30W, probably between 10 and 20W when idle, and that's for 2 computers, giving better high availability and failover

Good search said:

With 2 rPi5 I'm actually faster than the DSS 1510 for maybe 1/10th of the power, so not a bad deal :)

So here is the end result I built:

The 2 things I had to engineer is using each server as a serial console server for the other one, as explained on my Using a Raspberry Pi 5 (Rpi5) as a Server With Btrfs, Raid1, Serial Console and Dual NVME/SD Card Recovery Boot blog.
The next thing was how to get 5V power for those sata drives. My first solution was just to steal it from the GPIO port:

But I found a dual sata power cable I had laying around and a 3 pin female plug with the right plastic bits to make it almost impossible to plug backwards (which would likely destroy the drives):

this

to replace that

The last relevant bit is to find those hard to find USB-C power supplies that give 5A on 5V (normally it's 3A max), although you could also get a real 5V power supply and feed the rPi through the GPIO pins, but that would bypass some protections. In the end, my very professional setup that did take many days to build and test, looked like this:

oops, forgot to protect the back so it doesn't short when touching metal, duct tape to the rescue

the new setup on top fo the existing poweredge server running for a while as recovery/emergency

And for shits and giggles, still found an original VA Linux server going strong, as a rack spacer :)

Power Cycling

Moremagic is back!

Now I'm back with 2 servers, on the same network which is not ideal, but they are both redundant filesystem-wise and capable of taking over one another's duties if one were to die (likely the power supply I assume).

Further reading

Xmas trees

On the way back, I hadn't gone to Hakone Gardens in several years, so it was a good time to go back:

eyes are drawn with math, they aren't sprites or animated gifs

So, I already built a 64x64 Matrix the hard way in 2018, including early uses of the ESP32 FastLED parallel output code that was still being written in 2018 when I built it. Building the matrix from scratch with 64 strips laid out one by one, was a pain, it took close to a week just to build. Code-wise, it took a little while, but I had a sweet running 110fps 16 parallel channel output setup, it was lovely.

professional wiring work, haha

yeah, that's why I wanted to use a nice expander board this time around

not counting that I had to add level shifters to get full 110fps speed from 3.3V output to 5V pixels

but eh, it did work and it survived 2 burning mans until the playa ate the pixels from the inside

I was honestly quite sad about my 4096 pixel array that took so much effort having been eaten by the corrosive playa, so when I saw pieces of pre-made matrices at a more reasonable price, I I kind of impulse bought 6 bunches 10x60 pre-made strips of much better quality just before the Trump tariffs came in. It was still $500 just in LEDs tough, but that's actually a good price for that many high quality pixels. I however figured I'd try using pixxelblaze with it because progress and not writing my own code for everything (although it was already written, haha). I also hoped to use the PB expander board to help with wiring.
I also was curious to try out the library of 2D patterns available with pixelblaze. In the end I found around 40 2D patterns that looked decent enough. Is 40 a lot? It's not bad, but when using my own Framebuffer::GFX in C++, I've easily gathered over 200 demos that are overall better due to more speed and obviously a lot faster (almost unlimited speed limited by the LEDs themselves).

I figured I'd live with the limitations of Pixelblaze and the limited amount of demos compared to C++ framebuffers, But things didn't really work out as planned. Namely:

Here are pictures of the build

all 6 sub matrices connected, turns out single power was good enough even if the matrix power wire was a bit thin and ran a bit hot

my 300W 12V power supply was definitely overkill, note the small step down converter to power the 5V PB from 12V

power was good

I tried to split the output in two by using a spare PB pico I had laying around

coordinate mapping was a huge pain due to lack of docs

with 2 devices, without magic in the code, a single PB would not know to display the left or right half

In the end, I gave up and went with a single 3600 pixel output, and make peace with patterns that ran as slow as 3 to 5fps:

I used a 110V power cord to re-inject 12V power in the middle, not fully required but nicer on wires

sadly my setup didn't come with the right plug to connect to the output and backfeed power from the other side, so I made my own from spare connectors

it worked without the power backfeed, but it was better with it

now came the job of connecting 60*5=300 knots between the sub-sections with twisty ties

didn't take too long, time for install

wee!

for a display that doesn't have a framebuffer and things are drawn with math, not bad

and it looks cool from inside the house too :)

Do you want the same demos without spending all the time it took me to download them one by one? Marc's Favorite Pixelblaze 2D demos pbb config you can directly install

The magic file above will install everything you need all at once, you'll just have to re-set Wifi, change the name and resolution.

If anyone is interested, here are the demos I settled on, the ones prefixed with '_' were downloaded from https://electromage.com/patterns :

After leaving Sedona/Flagstaff, quick stop at the Bonito Lava Flow. Didn't have enough time to stay due to a reservation at Lower Antelope Canyon and a 2h drive to get there:

Pretty route on the way, no time to stop, though:

Eventually arrived at Lower Antelope Canyon just in time for the tour with just minutes to spare:

first went to the wrong one

then found the correct one

it's a fair ways down

Then rain happened:

small rivers started to form :)

then it started raining for real ;)

Got exciting in very little time:

Getting tours last minute was hard, so I got one for wind canyon, but it also got flooded, so we went to secret canyon instead:

wider but nice

The nice bonus is the tour company had its own private access to Antelope Canyon:

While in the area, I tried to sign up for real "the wave" without success, but there was this very cool "the new wave" a few minutes outside Page, well worth the visit:

A few more pictures the next day before driving out:

Not far outside Page are Toadstools part of Grand Staircase Escalante NP. Cool walk:

And further up the road, there was Moqui Cave, fun weird quirky place:

this is very random :)

but just next door Sand Caves was a cool visit:

And that was it for the Page Area, next was Zion...

all our local crew was here

I used the opportunity to bring a slightly new outfit version:

The location ended up being pretty full:

It was nice to see Hana again, I do enjoy her ethereal music and singing:

Dave Dresden took over next for some nice classics:

And then was time for Above and Beyood:

nice new graphics