Imagine, purely hypothetically, that you were a kernel hacker working for Red Hat and for whatever reason you wanted to find a new challenge at a company with a strong committment to open source. What are the possibilities?

To begin with, as the statistics from the Linux Foundation's 2016 report demonstrate, you have to be stark raving mad to leave Red Hat. If you do, Intel and AMD look interesting (hello, Alan Cox). IBM is not bad, although since yesterday, you don't need to quit Red Hat to work for IBM anymore. Even Google, famous for being a black hole that swallows good hackers who are never heard from again, manages to put up a decent showing, Fuchsia or no. Facebook looks unimpressive (no disrespect to DaveJ intended).

Now, the no-shows. Both of them hail from Seattle, WA: Microsoft and Amazon. Microsoft made an interesting effort to adopt Linux into its public cloud, but their strategy was to make Red Hat do all the work. Well, as expected. Amazon, though, is a problem. I managed to get into an argument with David "dwmw2" Woodhouse on Facebook about it, where I brought up a somewhat dated article at The Register. The central claim is, the lack of Amazon's contribution is the result of the policy rolled all the way from the top.

(...) as far as El Reg can tell, the internet titan has submitted patches and other improvements to very few projects. When it does contribute, it does so typically via a third party, usually an employee's personal account that is not explicitly linked to Amazon.

I don't know if this culture can be changed quickly, even if Bezos suddenly changes his mind.

In a comment on the death of G+, elisteran brought up something that long annoyed me out of all proportion with its actual significance. What do you call a collection of servers communicating through NNTP? You don't call them "INN", you call them "Usenet". The system of hosts communicating through SMTP is not called "Exim", it is called "e-mail". But when someone wants to escape G+, they often consider "Mastodon". Isn't it odd?

Mastodon is merely an implementation of Fediverse. As it happens, only one of my Fediverse channels runs on Mastodon (the Japanese language one at Pawoo). Main one still uses Gnusocial, the anime one was on Gnusocial and migrated to Pleroma a few months ago. All of them are communicating using the OStatus protocol, although a movement is afoot to switch to ActivityPub. Hopefully it's more successful than the migration from RSS to Atom was.

Yet, I noticed that a lot of people fall to the idea that Mastodon is an exclusive brand. Rarely one has to know or care what MTA someone else uses. Microsoft was somewhat successful in establishing Outlook as such a powerful brand to the exclusion of the compatible e-mail software. The maintainer of Mastodon is doing his hardest to present it as a similar brand, and regrettably, he's very successful at that.

I guess what really drives me mad about this is how Eugen uses his mindshare advanage to drive protocol extensions. All of Fediverse implementations generaly communicate freely with one another, but as Pleroma and Mastodon develop, they gradually leave Gnusocial behind in features. In particular, Eugen found a loophole in the protocol, which allows to attach pictures without using up the space in the message for the URL. When Gnusocial displays a message with attachment, it only displays the text, not the picture. This acutally used to be a server setting, in case you want to safe your instance from NSFW imagery and save a little bandwidth. But these days pictures are so prevalent, that it's pretty much impossible to live without receiving them. In this, Eugen has completed the "extend" phase and is moving onto "extinguish".

I'm not sure if this a lost cause by now. At least I hope that members of my social circle migrate to Fediverse in general, and not to Mastodon from the outset. Of course, the implementation does matter when they make choices. As I mentioned, for anything but Linux discussions, pictures are essential, so one cannot reasonably use a Gnusocial instance for anime, for example. And, I can see some users liking Mastodon's UI. And, Mastodon's native app support is better (or not). So yes, by all means, if you want to install Mastodon, or join an instance that's running Mastodon, be my guest. Just realize that Mastodon is an implementation of Fediverse and not the Fediverse itself.

Reactions by G+ inhabitants were better than expected at times. Here's Jon Masters:

For the three people who care about G+: it's closing down. This is actually a good thing. If you work in kernel or other nerdy computery circles and this is your social media platform, I have news for you...there's a world outside where actual other people exist. Try it. You can then follow me on Twitter at @jonmasters when you get bored.

Rock on. Although LJ was designed as a shitty silo, it wasn't powerful enough to make itself useless. For example, outgoing links aren't limited. That said, LJ isn't bulletproof: the management is pushing the "new" editor that does not allow HTML. The point is though, there's a real world out there.

And, some people are afraid of it, and aren't ashamed to admit it. Here's Steven Rostedt in Jon's comments:

In other words, we are very aware of the world outside of here. This is where we avoided that world ;-)

So weak. Jon is titan among his entourage.

Kir enumerated escape plans thus (in my translation):

Where to run, unclear. Not wanting to Facebook, Telegram is kinda a marginal platform (although Google+ marginal too), too lazy to stand up a standalone. Nothing but LJ comes to mind.

One thing that comes across very strongly is how reluctant people are to run their own infrastructure. For one thing, the danger of a devastating DDoS is absolutely real. And then you have to deal with spam. Those who do not have the experience also tend to over-estimate the amount of effort you have to put into running "dnf update" once in a while.

Personally, I think that although of course it's annoying, the time wasted on the infra is not that great, or at least it wasn't for me. The spam can be kept under control with a minimal effort. Or, could be addressed in drastic ways. For example, my anime blog simply does not have comments at all. As far as DoS goes, yes, it's a lottery. But then the silo platform can easily die (like G+), or ban you. This actually happens a lot more than those hiding their heads in the sand like to admit. And you don't need to go as far as to admit to your support of President Trump in order to get banned. Anything can trigger it, and the same crazies that DoS you will also try to deplatform you.

One other idea I was very successful with, and many people have trouble accepting, is having several channels for social posting (obviously CKS was ahead of the time with separating pro and hobby). Lots and lots of G+ posters insist on dumping all the garbage into one bin, instead of separating the output. Perhaps now they'll find a client or device that allows them switch accounts easily.

Back in July, Economist wanted to judge a popularity of programming languages and used ... Google Trends. Python is rocketing up, BTW. Go is not even mentioned.

Unexpectedly in the fediverse:

[...] in my experience, postgres crashes less, and the results are less devastating if it does crash. I've had a mysql crash make the data unrecoverable. On the other hand I have a production postgres 8.1 installation (don't ask) that has been running without problems for over 10 years.

There is more community information and more third-party tools that require mysql, it has that advantage. the client tools for mysql are easier to use because the commands are in plain english ("show tables") unlike postgres that are commands like "\dt+". but if I'm doing my own thing though, I use postgres.

Reiser, move over. There's a new game in town.

The Huawei M3 gave me an unpleasant surprise a short time ago. I had it in my hands while doing something and my daughter (age 30) offered to hold it for me. When I received it back and turned it on, it was factory reset. What happened?

It turned out that it's possible to reset the blasted thing merely by holding it. If someone grabs it and pays no attention to what's on the screen, then it's easy to press and hold the edge power button inadvertently. That brings up a dialog that has 2 touch buttons for power off and reset. The same hand that's holding the power touches the screen and causes the reset (a knuckle where the finger meets the palm does that perfectly).

The following combination of factors makes this happen. 1. Power button is on the edge, and it sticks out. Some tablets like Kindle or Nexus have edges somewhat slanted, so buttons are somewhat protected. Holding the tablet across the face engages the power button. They could at least place the power button on the short edge of the device. 2. The size of the tablet is just large enough that a normal person can hold it with one hand, but has to stretch. Therefore, the base knuckles touch the surface. On a larger tablet, a human hand is not large enough to hold it like that, and on a phone sized device the palm cups, so it does not touch the center of the screen. 3. The protection against accidental reset is essentially absent.

Huawei, not even once.

Google, bring back the Nexus 7, please.

Usually I do not watch TV, but I traveled and saw a few of them in public food intake places and such. What caught my attention were ads for robotics companies, aimed at business customers. IIRC, the companies were called generic names like "Universal Robotics" and "Reach Robotics". Or so I recall, but on second thought, Reach Robotics is a thing, but it focises on gaming, not traditional robotics. But the ads depicted robots doing some unspecified stuff: moving objects from place to place. Not dueling bots. Anyway, what's up with this? Is there some sort of revolution going on? What was the enabler? Don't tell me, it's all the money released by end of the Moore's Law, seeking random fields of application.

P.S. I know about the "Pentagon's Evil Mechanical Dogs" by Boston Dynamics. These were different, manipulating objects in the environment.

A couple Fedora releases back, I noticed that my laptop stopped using IPv6 to access dual-hosted services. I gave RFC-6724 a read, but it was much too involved for my small mind. Fortunately, it contained a simplified explanation:

Another effect of the default policy table is to prefer communication using IPv6 addresses to communication using IPv4 addresses, if matching source addresses are available.

My IPv6 is NAT-ed, so the laptop sees an RFC-4193 address fc00::/7. This does not match the globally assigned address of the external service. Therefore, a matching source address is not available, and things develop from there.

For now, I forced RFC-3484 with gai.conf. Basically, reverted to Fedora 26 behavior.

Butenko was simply the most capable programmer that I've ever worked with. He was also very accomplished. I'm sure everyone has an idea what UNIX v7 was. Although BSD, sockets, and VFS were still in the future, it was a sophisticated OS for its time. Butenko wrote his own OS that was about a peer for the v7 in features (including vi). He also wrote a Fortran 77 compiler with IDE, an SQL database, and a myriad other things. Applications, too: games, communications, industrial control.

I still remember one of our first meetings in the late 1983. I wanted someone to explain me the instruction set of Mitra-15, a French 16-bit mini. Documentation was practically impossible to get back then, especially for undergrads. Someone referred me, and I received a lecture at a smoking area near an elevator, which founded my understanding of computer architecture.

The only time I ever got one up, was when I wrote a utility to monitor processes (years later, top(1) does the same thing). Apparently the concept never occurred to Butenko, who was perfectly capable to analyzing the system with a debugger and profiler. Seeing just my UI, he knocked out a clone in a couple of days. Of course, it was superior in every respect.

Butenko worked a lot. The combination of genius and workaholic was unstoppable. Or maybe they were sides of the same coin.

Unfortunately, Butenko was not in with the open source. He used to post to Usenet, lampooning and dismissing Linux. I suspect once you can code your own Linux any time you want, your perspective changes a bit. This was a part of the way we drifted apart later on. I was plugging on my little corner of Linux, while Butenko was somewhere out in the larger world, revolutionizing computer-intermediated communications.

He died suddenly, from a heart failure. Way too early, I think.

Wait, wasn't this supposed to be our future?

The abridged history, as I recall was as follows. Mike Burton started the work to port Swift to Go in early 2016, inside the Swift tree. As such, it was a community effort. There was even a discussion at OpenStack Technical Committee about allowing development in Go (the TC disallowed it, but later posted some conditions). At the end of the year, I managed to write an object with MIME and collapsed the stock Swift auditor (the one in Python). That was an impetus for PUT+POST, BTW. But in 2017, the RAX cabal - creiht, redbo, and later gholt - weren't very happy with trying to supplicate to the TC, as well as the massive overhead of developing in the established community, and went their own way. In addition to the TC shenagians, the upstream Swift at SwiftStack and Red Hat needed a migration path. A Hummingbird without a support for Erasure Coding was a non-starter, and the RAX group wasn't interested in accomodating that. By the end of 2017, they were completely on their own, and started going off at the deep end by adding database servers and such. They managed to throw off some good ideas about what the next-generation replication ought to look like. But by cutting themselves off Swift they committed to re-capturng the lightning in the bottle anew, and they just could not pull it off.

On reflection, I suspect their chances would be better if they were serious about interoperating with Swift. The performance gains that they demonstrated were quite impressive. But their paymasters at RAX weren't into this community development and open-source toys (not that RAX went through the change of ownership while Hummingbird was going on).

I think a port of Swift to Go is still on the agenda, but it's unknown at this point if it's going to happen.

Saw today at a respectable news site, which does not even nag about adblock:

451

We recognise you are attempting to access this website from a country belonging to the European Economic Area (EEA) including the EU which enforces the General Data Protection Regulation (GDPR) and therefore cannot grant you access at this time. For any issues, e-mail us at xxxxxxxx@xxxxxx.com or call us at xxx-xxx-4000.

What a way to brighten one's day. The phone without a country code is a cherry on top.

P.S. The only fly in this ointment is, I wasn't accessing it from the GDPR area. It was a geolocation failure.

See a mailing list message:

I would like to remove myself entirely from the decision process. // I am not going to appoint a successor.

Regarding the Huston missive, two quotes jumped at me the most. The first is just beautiful:

It may be slightly more disconcerting to realise that your electronic wallet is on a device that is using a massive compilation of open source software of largely unknown origin [...]

Yeah, baby. This moldy canard is still operational.

The second is from the narrative of the smartphone revolution:

Apple’s iPhone, released in 2007, was a revolutionary device. [...] Apple’s early lead was rapidly emulated by Windows and Nokia with their own offerings. Google’s position was more as an active disruptor, using an open licensing framework for the Android platform [...]

Again, it's not like he's actually lying. He merely implies heavily that Nokia came next. I don't think the Nokia blunder even deserve a footnote, but to Huston, Google was too open. Google, Carl!

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.

UPDATE: Looks like CKS agrees that compatible code is usually too hard. I'm glad the recommendation to avoid Python 3 entirely is no longer operational.

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.