Got Slasti 2.1 released today, the main feature being a support for Python 3. Some of the changes were somewhat... horrifying maybe? I tried to adhere to a general plan, where the whole of the application operates in unicode, and the UTF-8 data is encoded/decoded at the boundary. Unfortunately, in practice the boundary was rather leaky, so in several places I had to resort to isinstance(). I expected to always assign a type to all variables and fields, and then rigidly convert as needed. But WSGI had its own ideas.

Overall, the biggest source of issues was not the py3 model, but trying to make the code compatible. I'm not going to do that again if I can help it: either py2 or py3, but not both.

Finally updated my laptop to F28 and ssh connections started hanging. They hang for 15-20 seconds, then unstuck for a few seconds, then hang, and so on, cycling. I thought it was a WiFi problem at first. But eventually I narrowed it down to IPv6 ND being busted.

A packet trace on the laptop shows that traffic flows until the laptop issues a neighbor solicitation. The router replies with an advertisement, which I presume is getting dropped. Traffic stops — although what's strange, tcpdump still captures outgoing packets that the laptop sends. In a few seconds, the router sends a neighbor solicitation, but the laptop never replies. Presumably, dropped as well. This continues until a router advertisement resets the cycle.

Stopping firewalld lets solicitations in and the traffic resumes, so obviously a rule is busted somewhere. The IPv6 ICMP appears allowed, but the ip6tables rules generated by Firewalld are fairly opaque, I cannot be sure. Ended filing bug 1591867 for the time being and forcing ssh -4.

UPDATE: Looks like the problem is a "reverse path filter". Setting IPv6_rpfilter=no in /etc/firewalld/firewalld.conf fixes the the issue (thanks to Victor for the tip). Here's an associated comment in the configuration file:

# Performs a reverse path filter test on a packet for IPv6. If a reply to the
# packet would be sent via the same interface that the packet arrived on, the
# packet will match and be accepted, otherwise dropped.
# The rp_filter for IPv4 is controlled using sysctl.

Indeed there's no such sysctl for v6. Obviously the problem is that packets with the source of fe80::/16 are mistakenly assumed to be martians and dropped. That's easy enough to fix, I hope. But it's fascinating that we have an alternative configuration method nowadays, only exposed by certain specialist tools. If I don't have firewalld installed, and want this setting changed, what then?

Remarkably, the problem was reported first in March (it's June now). This tells me that most likely the erroneous check itself is in the kernel somewhere, and firewalld is not at fault, which is why Erik isn't fixing it. He should've reassigned the bug to kernel, if so, but...

The commit cede24d1b21d68d84ac5a36c44f7d37daadcc258 looks like the fix. Unfortunately, it just missed the 4.17.

Colleagues working in space technologies discussed recently if fundamental education were necessary for a programmer, so just for a reference, here's a list of fundamental-ish areas I had trouble with in practice over a 30 year career.

Statistics. This should be obvious. Although in theory I'm educated in the topic, I always had difficulty with it, and barely passed my tests, decades ago.

Error correction. To be entirely honest, I blew this. Every time I had to do it, I ended either using Phil Karn's library, or relying on Kevin Greenan's erasure coding package. I think the only time I implemented something that worked was the UAT.

The DSP on Inphase/Quadrature data. This one is really vexing. I ended with some ridiculous ad-hoc code, even though it's very interesting. In my excuse, there were some difficult performance constraints, so even if I knew the underlying math, there would be no way to apply it.

Other than the above, I don't feel like I was held back by any kind of fundamental background, most of all not in CS. About the only time it mattered was when an interviewer asked me to implement an R-B tree.

The domain now redirects to Wayback Machine. The last captured post is the official farewell message from June 22.

Personally, I would prefer people hack upon trust metrics than blockchain. But they did not agree, and personally I've done nothing to advance the field, so I don't have room to complain. And now the flagship open-source implementation is no more (well, of course Google still exists and so the trust metrics stay with us; possibly even get developed further).

As seen at a blog about cars:

Every software shop from Hyderabad to Cleveland now faithfully, and idiotically, replicates a cargo-cult version of the “standups” and “kanban methods” that were designed to work on a factory floor.

The “standups” are particularly miserable: Toyota’s version was best understood as a five-minute meeting where any potential issues in a given assembly-line department would be sorted out before the shift began, but under the corrupting influence of IBM, Accenture, and other “body shops,” the concept has degenerated into a 45-minute hellscape of offshore “engineers” mumbling a list of their miniature accomplishments out of a speakerphone while everybody else shifts from leg to leg and attempts not to fall asleep.

Shit, man. If even a pro racer turned autojourno can tell, we in software are past the point of ridiculous. That said, morning assembly is nothing new - it was a thing in the 1950s, long before Toyota. It even had native names: in Russia it was called "lineyka", in Japan it was "cho~rei".

Not being a native speaker, I get amusing results sometimes when searching on Amazon. For example, "floor scoop" brings up mostly fancy dresses. Apparently, a scoop is a type of dress, which can be floor-length, and so. The correct request is actually "dust pan". Today though, searching for "Peliton termite" ended with a bunch of bicycle saddles. Apparently, Amazon force-replaced it with "peloton", and I know of no syntax to force my spelling. I suspect that Peliton may have trouble selling their products at Amazon. This sort of thing is making me wary of Alexa. I don't see myself ever winning an argument with a robot who knows better, and is implemented in proprietary software that I cannot adjust.

UPDATE: The "plus prefix" works, e.g. "+peliton" (thanks to elisteran).

Today, I want to build a satellite that receives ADS-B signals from airplanes over the open ocean, far away from land. With a decent receiver and a simple antenna, it should be possible on a gravity-stabilized cubesat. I know about terrestrial receivers picking signals 200..300 km out, surely with care one can do better. But I highly doubt that it's possible to finance such a toy — unless someone has already done that. I know that people somehow manage to finance AIS receivers, which are basically the same thing, only for ships. How do they do that?

UPDATE: Reportedly, hosted payloads by Aireon on Iridium NEXT satellites do ADS-B. The working altitude of the previous generation of Iridium was 780 km, the NEXT is probably the same.

Oh Microsoft, you card:

[Azure Sphere OS] combines security innovations pioneered in Windows, a security monitor, and a custom Linux kernel [...]</p>

Kinda like Oracle shipping "Unbreakable Linux". Still in the "embrace" phase.

Liferea irritated me for many years with a strange behavior when dragging a subscription. You mouse down on the feed, it becomes selected — so far so good. Then you drag it somewhere — possibly far off screen, making the view scroll — then drop it. Drops fine, updates the DB, model, and the view fine. But! The selection then jumps to a completely random feed somewhere.

Well, it's not actually random. What happens instead, the GtkTreeView implements DnD by removing a row, then re-inserting it. When a selected row is removed, obviously the selection has to disappear, but instead it's set to the next row after the removed one. I suppose I may be uniquely vulnerable to this because I have 300+ feeds and I drag them around all the time. If Liferea weren't kind enough to remember the preferred order, this would not matter so much.

I meant to fix this for a long time, but somehow a wrong information got stuck in my head: I thought that Liferea was written in C++, so it took years to gather the motivation. Imagine my surprise when I found plain old C. I spent a good chunk of Sunday figuring out GTK's tree view thingie, but in the end it was quite simple.

Recently it became common to see a mocking of startup founders that add "blockchain" to something, then sell it to gullible VCs and reap the green harvest. Apparently it has become quite a thing. But now they went a step further.

The other day I was watching some anime at Crunchyroll, when a commercial came up. It pitched a fantasy sports site "with blockchain technology" and smart contracts. The remarkable part about it is, it wasn't aimed at investors. It was a consumer advertisement. Its creators apparently expect members of the public — who play fantasy sports, no less — to know that blockchain exists and think about it in positive terms.

Remarks of our CEO, as captured in an interview by TechCrunch:

The other major open-source project Red Hat is betting on is OpenStack . That may come as a bit of a surprise, given that popular opinion in the last year or so has shifted against the massive project that wants to give enterprises an open source on-premise alternative to AWS and other cloud providers. “There was a sense among big enterprise tech companies that OpenStack was going to be their savior from Amazon,” Whitehurst said. “But even OpenStack, flawlessly executed, put you where Amazon was five years ago. If you’re Cisco or HP or any of those big OEMs, you’ll say that OpenStack was a disappointment. But from our view as a software company, we are seeing good traction.”

He's over-simplifying things for the constraints of an interview: the last sencence needs unpacking. Why do you think that "traction" happens? Because OpenStack gives its users something that Amazon does not. For example, Swift isn't trying to match features of S3. Attempting to do that would cause the exact lag he's referring. Instead, Swift works to solve the problem of people who want to own their own data in general. So, it's mostly about the implementation: how to make it scalable, inexpensive, etc. And, of course, keeing it open source, preserving user's freedom to modify. This is why often you see people installing a truncated OpenStack that only has Swift. I'm sure this applies to other parts of OpenStack, in particular the SDN/NFV.

I decided to build Liferea over the weekend, and the build crashes at the introspection phase.

Apparently, GTK+ programs are set up to introspect themselves: basically the binary can look at its own types or whatnot, then output the result. I'm not quite clear what the purpose of that is, the online docs imply that it's for API documentation mostly. Anyhow, the build runs the liferea binary itself, with arguments that make it run the introspection, then this happens:

(gdb) where
#0  0x00007fa90a2a93b0 in wl_list_insert_list ()
    at /lib64/libwayland-server.so.0
#1  0x00007fa90a2a4e6f in wl_priv_signal_emit ()
    at /lib64/libwayland-server.so.0
#2  0x00007fa90a2a5477 in wl_display_destroy ()
    at /lib64/libwayland-server.so.0
#3  0x00007fa916d163d9 in \
  WebCore::PlatformDisplayWayland::~PlatformDisplayWayland() () at \
  /lib64/libwebkit2gtk-4.0.so.37
#4  0x00007fa916d163e9 in \
  WebCore::PlatformDisplayWayland::~PlatformDisplayWayland() () at \
  /lib64/libwebkit2gtk-4.0.so.37
#5  0x00007fa91100cb58 in __run_exit_handlers () at /lib64/libc.so.6
#6  0x00007fa91100cbaa in  () at /lib64/libc.so.6
#7  0x00007fa911e9d367 in  () at /lib64/libgirepository-1.0.so.1
#8  0x00007fa91197d188 in parse_arg.isra () at /lib64/libglib-2.0.so.0
#9  0x00007fa91197d8ca in parse_long_option () at /lib64/libglib-2.0.so.0
#10 0x00007fa91197f2d6 in g_option_context_parse () at \
  /lib64/libglib-2.0.so.0
#11 0x00007fa91197fd84 in g_option_context_parse_strv ()
    at /lib64/libglib-2.0.so.0
#12 0x00007fa912164558 in g_application_real_local_command_line ()
    at /lib64/libgio-2.0.so.0
#13 0x00007fa912164bf6 in g_application_run () at /lib64/libgio-2.0.so.0
#14 0x000000000041b9ff in main (argc=2, argv=0x7fff2e1203d8) at main.c:77

As much as I can tell, despite being asked only to do the introspection, Liferea (unknowingly, through GTK+) pokes Wayland, which sets exit handlers. However, Wayland is never used (introspection, duh), and not initialized completely, so when its exit handlers run, it crashes.

Well, now what?

I supplse the cleanest approach might be to modify Glib so it avoids provoking Wayland when merely introspecting. But honestly I have no clue about desktop apps and do not know where to even start looking.

UPDATE: Much thanks to Branko Grubic, who pointed me to a bug in WebKit. Currently building with this as a workaround:

--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -82,6 +82,7 @@ INTROSPECTION_GIRS = Liferea-3.0.gir
 
 Liferea-3.0.gir: liferea$(EXEEXT)
 INTROSPECTION_SCANNER_ARGS = -I$(top_srcdir)/src --warn-all -......
+INTROSPECTION_SCANNER_ENV = WEBKIT_DISABLE_COMPOSITING_MODE=1
 Liferea_3_0_gir_NAMESPACE = Liferea
 Liferea_3_0_gir_VERSION = 3.0
 Liferea_3_0_gir_PROGRAM = $(builddir)/liferea$(EXEEXT)

Seen at the webpage for RancherOS:

Everything in RancherOS is a Docker container. We accomplish this by launching two instances of Docker. One is what we call System Docker, the first process on the system. All other system services, like ntpd, syslog, and console, are running in Docker containers. System Docker replaces traditional init systems like systemd, and can be used to launch additional system services.

Remember how FAA shut down the business of NavWorx, with heavy monetary and loss-of-use consequences for its customers? Imagine receiving a letter from U.S. Government telling you that your car is not compatible with roads, and therefore you are prohibited from continuing to drive it. Someone sure forgot that the power to regulate is the power to destroy. This week, we have this report by IEEE Spectrum:

IEEE Spectrum can reveal that the SpaceBees are almost certainly the first spacecraft from a Silicon Valley startup called Swarm Technologies, currently still in stealth mode. Swarm was founded in 2016 by one engineer who developed a spacecraft concept for Google and another who sold his previous company to Apple. The SpaceBees were built as technology demonstrators for a new space-based Internet of Things communications network.

The only problem is, the Federal Communications Commission (FCC) had dismissed Swarm’s application for its experimental satellites a month earlier, on safety grounds.

On Wednesday, the FCC sent Swarm a letter revoking its authorization for a follow-up mission with four more satellites, due to launch next month. A pending application for a large market trial of Swarm’s system with two Fortune 100 companies could also be in jeopardy.

Swarm Technologies, based in Menlo Park, Calif., is the brainchild of two talented young aerospace engineers. Sara Spangelo, its CEO, is a Canadian who worked at NASA’s Jet Propulsion Laboratory, before moving to Google in 2016. Spangelo’s astronaut candidate profile at the Canadian Space Agency says that while at Google, she led a team developing a spacecraft concept for its moonshot X division, including both technical and market analyses.

Swarm CFO Benjamin Longmier has an equally impressive resume. In 2015, he sold his near-space balloon company Aether Industries to Apple, before taking a teaching post at the University of Michigan. He is also co-founder of Apollo Fusion, a company producing an innovative electric propulsion system for satellites.

Although a leading supplier in its market, NavWorx was a bit player at the government level. Not that many people have small private airplanes anymore. But Swarm operates at a different level, an may be able to grease a enough palms in the Washington, D.C., enough to survive this debacle. Or, they may reconstitute as a notionally new company, then claim a clean start. Again unlike the NavWorx, there's no installed base.

I'm just back from OpenStack PTG (Project Technical Gathering) in Dublin, Ireland and while I was there, Firefox reported wrong TLS certificates for some obscure websites, although not others. Example: zaitcev.us retains old certificate, as does wrk.ru. But sealion.club goes bad. I presume that Irish authorities and/or ISPs deemed it proper to MITM these sites. The question is, why such a strange choice of targets?

The sealion.club is a free speech and discussion site, named, as much as I can tell, after an old (possibly classic or memetic) Wondermark cartoon. Maybe the Irish just hate the free speech.

Or, they do not MITM sites that have TLS settings that are too easy to break... and Gmail.

Check out what I found at Pogo Linux (h/t Bryan Lunduke):

ARM R150-T62
2 x Cavium® ThunderX™ 48 Core ARM processors
16 x DDR4 DIMM slots
3 x 40GbE QSFP+ LAN ports
4 x 10GbE SFP+ LAN ports
4 x 3.5” hot-swappable HDD/SSD bays
650W 80 PLUS Platinum redundant PSU
$5,638.82

The prices are ridiculouts, but at least it's a server with CentOS.

I'm tinkering with OpenStack TripleO in a simulated environment. It uses a dedicated non-privileged user, "stack", which can do things such as list VMs with "virsh list". So, yesterday I stopped the undercloud VM, and went to sleep. Today, I want to restart it... but virsh says:

error: failed to connect to the hypervisor
error: Cannot create user runtime directory '/run/user/1000/libvirt': Permission denied

What seems to happen is that when one logs into the stack@ user over ssh, systemd-logind mounts that /run/user/UID thing, but if I log as zaitcev@ and then do "su - stack", this fails to occur.

I have no idea what to do about this. It's probably trivial for someone more knowledgeable to throw the right pam_systemd line into /etc/pam.d/su. But su-l includes system-auth, which invokes pam_systemd.so, and yet... Oh well.

Flying a photoshoot of the Carlson, I stuffed my Nexus 7 under my thighs and cracked the screen. In my defense, I did it several times before, because I hate leaving it on the cockpit floor. I had to fly uncoordinated for the photoshoot, which causes anything that's not fixed in place slide around, and I'm paranoid about a controls interference. Anyway, the cracked screen caused a significant dead zone where touch didn't register anymore, and that made the tablet useless. I had to replace it.

In the years since I had the Nexus (apparently since 2014), the industry stopped making good 7-inch tablets. Well, you can still buy $100 tablets in that size. But because the Garmin Pilot was getting spec-hungry recently, I had no choice but to step up. Sad, really. Naturally, I'm having trouble fitting the M3 into pockets where Nexus lived comfortably before. {It's a full-size iPad in the picture, not a Mini.}

The most annoying problem that I encountered was Chrome not liking the SSL certificate of www.zaitcev.us. It bails with ERR_SSL_SERVER_CERT_BAD_FORMAT. I have my own fake CA, so I install my CA certificate on clients and I sign my hosts. I accept the consequences and inconventice. The annoyance arises because Chrome does not tell what it does not like about the certificate. Firefox works fine with it, as do other applications (like IMAP clients). Chrome in the Nexus worked fine. A cursory web search suggests that Chrome may want alternative names keyed with "DNS.1" instead of "DNS". Dunno what it means and if it is true.

UPDATE: "Top FBI, CIA, and NSA officials all agree: Stay away from Huawei phones"

I keep waiting for RJ-45 to fail to keep the pace with the gigabits, for many years. And it always catches up. But maybe not anymore. Here's what the connector looks for QSFP-DD, a standard module connector for 400GbE:

Two rows, baby, same as on USB3.

These speeds are mostly used between leaf and spine switches, but I'm sure we'll see them in the upstream routers, too.

When I split off the router, I received a bit of a breather from the Fedora killing i686, because I do not have to upgrade the non-routing server as faithfully as an Internet-facing firewall. Still, eventually I must switch from the ASUS EEEPC to something viable.

So, I considered a NUC, just like the one that Richard W.M. Jones bought. It beats an old laptop in every way. In particular, it's increasingly difficult to disassemble laptops nowadays, and the candidate I have now has is hard drive buried in a particularly vexing way: the whole thing must be taken apart, with a dozen of tiny connectors carefully pried off, before the disk can be extracted. Still, a laptop offers a couple of features. #1: it always has a monitor and keyboard, an #2: it comes with its own uninterruptible power supply. And the cost is already amortized.

Long term, I am inclined to believe that Atwood is right and all user-facing computers will morph into tablets. When that happens, a supply of useful laptops will dry up and I will have to resort to whatever microserver box is available.But that today is not that day.