19 Nov 2022, 11:11

Over to Mastodon, I guess

It took me quite a while to realize that I have been here before.

When Google+ (the greatest social network I have used, by the way) was killed, somebody spun up Pluspora as a refuge. It was a Pod of something called diaspora. It was nice in the beginning, then gradually I interacted with it less – since, TBH, there wasn’t much content, and I also didn’t post much. Eventually, the person running the Pod died, and their family ended up switching it off.

So when that guy bought Twitter and proceeded to run it into the ground at unprecedented speed, the number of Twitter postings saying “find me on Mastodon @x@y.z” multiplied on my timeline.

Also, at work, we occasionally had a moment where we all shared our gratitude not to work for Twitter. But I digress.

Being a NetBSD dev, it seemed natural to me to register an account on mastodon.sdf.org. SDF was founded as a Public Unix System, giving out free shell accounts to people. They have been running on NetBSD for many years and form a valuable part of the NetBSD community.

The beginning was rough: The SDF Mastodon server had surpassed 15,000 users, just days after breaking through the 10,000 mark. Service was slow, there were lots of errors, and it was generally not super pleasant. However, within a few days, the SDF admins started adding a LOT more hardware to the service, and these days, latency and functionality are top-notch. I think instead of paying $8 for a blue checkmark, that money is better spent with a recurring SDF donation!

The Fediverse

I alluded to this earlier, but diaspora and Mastodon are part of the Fediverse, so they federate. Just like in email, you can follow people from other servers, even using different software. For instance, Mastodon has a 500-character limit for posts, but you could follow someone using Plume for blogging, and their full blog posts would appear right on your timeline. Or I suppose you could follow someone’s PeerTube channel and have their videos appear on your timeline.

This is also how I eventually realized “Mastodon” and “diaspora” are really the same network: in the federated (global) timeline, a number of bots and people I already knew appeared.

Coming over

If you are looking to come over to Mastodon, you probably want to do the following things:

  1. Create an account on some server. It’s nice if you like the “theme” or the other people on the same server, since then you can look at the list of all public local posts when you are looking for something to read.
  2. Add your new address to your Twitter account – name, bio, link, all are fine.
  3. Head over to https://fedifinder.glitch.me and let it find the Fediverse accounts for all the folks you follow on Twitter. You can download a CSV and import it in the Mastodon settings page, making you follow everyone automatically.

Side note

diaspora still exists. Hilariously, if you follow the “Sign up now!” link on their homepage, you eventually arrive at https://diaspora.fediverse.observer/go&software=diaspora, which lists … no open Pods for signup.

13 Oct 2022, 18:23

Using a Mi Band with Strava

I have used a Mi Band as a smartwatch / fitness tracking device for the last couple years. Compared to, say, a Wear OS device, it offers a vastly better deal:

  • It’s cheap, at around 30-40 CHF.
  • The battery lasts several weeks.
  • It shows the time and tracks steps and movement.

The Wear OS device costs 5-10 times as much and needs daily charging. To be fair, in addition to showing the time and tracking fitness data, it does many other things that I don’t need.

My old Mi Band would no longer hold a charge, so I upgraded to the Mi Band 6, the latest iteration. I had read that it would be compatible with Strava, which I like for tracking bike rides. Turns out it is, but only around several corners!

The native app for the Mi Band is called Zepp Life, formerly known as Mi Fit. There is a separate app called Mi Fitness that is completely different (but also supports the Mi Band for some reason?). You can track workouts in Zepp Life but they do not appear anywhere else by default, except (maybe) in Apple Health on iOS. Zepp Life requires a Mi account.

The trick is one more app

You need to connect your Mi account to your Strava account to make workouts sync across the two. But Zepp Life does not support this. However, there is the following amazing workaround:

  1. Install the Zepp app (which apparently used to be called Amazfit).
  2. Log in to Zepp with your Mi account, the same as in Zepp Life.
  3. In the Zepp app, connect the Mi account to Strava by logging in to Strava from Zepp’s “Integration” settings menu.

That’s it! You can now deinstall Zepp, the connection has been established. Now, you can start a bike ride from Zepp Life or from the band, and the following information will appear in Strava:

  • GPS trace, speed and elevation – as usual
  • Heart rate
  • Cadence (I did not expect this!)

Strava will show “Amazfit” as the data source. You can edit the workout after the fact to add comments, description, photos etc.

Thoughts

Fitness tracking seems like a nice thing. I like having the trace of where I went. I like having the comparison to previous rides along the same stretch of road that Strava provides.

What I don’t like is walled gardens. There are so many of them!

Every manufacturer would like to store your fitness data in their cloud. Your past data, the months or years worth of workouts, all this is a source of vendor lock-in that tech companies are all too eager to embrace. After all, why would you buy a different brand (say, an Android phone when coming from iOS) if you cannot transfer over this history?

There are all sorts of neat statistics available that only make sense if all your fitness data is in the same walled garden and whatever device is always on you. Look at how many kilometers you biked in the last month! You were active on this many days! You used this many calories in your activities today! But if you ever walk around without your phone, or without your fitness band, these activities don’t count for the stats.

This way of coupling accounts via some sort of Auth token so that data automatically transfers over is good, but it should not be so difficult and non-obvious to set it up.

07 Nov 2021, 11:27

go-modules.mk

The BSD build system in general, and pkgsrc in particular, have a large number of Makefiles ending in .mk.

Recently, I was looking at a commit message in Gmail and noticed that these names are linkified. At the time, I was looking at a Go module package, where there is a go-modules.mk file containing details about dependencies. This got me thinking: Why is this file name turned into a link?

It turns out that .mk is the ccTLD of the Republic of North Macedonia! So I did what I had to do: I went to the website of a registrar in Skopje and reserved the go-modules.mk domain.

For the DNS, I created a zone in Google Cloud DNS, which was simple and extremely cheap, on the order of a few cents per month. For the contents, I added the domain as a redirect to my existing blog on the Firebase console.

So there you have it: next time, you see one of those emails, clicking the file name will bring you directly to this blog.

I have not checked if other standard Makefile names are still free as domains. So if you are interested in putting your pages at bsd.prog.mk or similar, here is your chance! :D

04 Mar 2021, 14:06

The Refinery, an Analogy for Distributed Systems

Back when I was in Engineering school, my first-year internship happened in a refinery. In retrospect, this turned out to be extremely relevant for my current job in tech.

The subject of my internship was the optimization of an existing process. The unit had been planned on paper by an engineer on another continent, installed according to specs, and it turned out to be … not working so well.

Don’t believe Tech is unique

A refinery is a distributed system. There are specs and basically internal contracts on each sub-unit regarding the quantity it should process per day, what the requirements for inputs and the desired output characteristics are. Instead of queries, the inputs and outputs are, you know, oil and gas.

There are continuous and batch processes. Just like in tech, the interface between these is the subject of a lot of literature and ops knowledge.

In tech, services have availability and latency SLOs. In a refinery, there are input and output SLOs (plus specs like purity, sulfur content, water content, etc.).

In tech, there are error budgets. In a refinery, you have emission budgets as a limiting factor. You may only send x amount of NOx or SOx or CO2 into the air over the course of the day. You may only go over the target value for n hours per month, otherwise the company pays a fine. The water that leaves the grounds may only be so-and-so polluted and have at most y degrees of temperature, otherwise there is another fine. And so on.

And just like in tech, contractors do the darndest things, although in tech, you rarely get a truckload of methanol dumped into your waste water stream.

Safety and Postmortem culture

In a tech company, we might say that prod is on fire when there is an incident, but in a refinery, things might literally be on fire or explode.

I quickly learned to be distrustful of recently renovated spaces, because that means it may have been blown up recently. My intern office was recently renovated; at some point, they showed me the photos of the incident that had all but destroyed the building the previous year.

The oil and gas industry has had a strong safety culture for years. The postmortem culture that SRE is so proud of had been a thing in the industry for years. Thus, when there was a large fire in a refinery in Texas City (the refinery was run by a competitor!), we got hold of a copy of the postmortem analysis, so that we could learn from it and avoid making the same mistakes. There was a meeting where we went through it together, discussed and acknowledged various lessons.

I am not sure how blameless these postmortems are. The problem is that in a real incident, people can get hurt or killed. At some point, it involves responsibility in a legal sense. The director of a unit may be responsible for incidents resulting in damages to others, including in a criminal court. Fortunately (?) for tech, incidents usually do not have this kind of real-world impact.

Dev/Ops Divide

Maybe even more than in tech, there is a divide between “dev” (as in, process engineers and planners) and “ops” (actual operator crews who are literally opening and closing giant valves with their two hands).

As a budding chemical engineer, I interned in process engineering. I quickly found out that many process engineers don’t actually bother finding out how the units they planned perform day to day. On the other hand, the most helpful thing I could do was to sit with the ops in the control room, drink a lot of coffee, and listen to their mental models of the unit. They could perfectly explain it in terms of “when I open this valve too much, the temperature over here jumps up and I have to open this other valve to compensate”. But they cannot tell you why. The trick of the good engineer is to take what you know about physics, thermodynamics, etc. and translate this into an understanding of what actually happens.

Often, what actually happens is not what the planning says. In all cases, there are variables that you did not take into account (outside temperature anyone?).

In addition, some real-world boundary conditions are hard to express in correlation matrices and linear programming models. For example: “If you open this valve too much for too long, the bit in the middle will clog with corrosive white slime deposits”. What kind of coefficient is that?

Your Monitoring is lying

Just like in tech, your monitoring is lying to you! You could have a miscalibrated sensor, but what is more likely is that the sensor is placed in a way that it does not show you the true picture.

In our case, there was a laser measurement in a gas conduit where the laser sometimes passed through the stream of flowing gas and sometimes it didn’t. The wildly fluctuating output has no basis in the actual gas composition. In another part of the unit, a sensor was placed in such a way that it was disturbing the flow, so it was actually modifying the behavior of the system.

My two most important variables (the composition of the feed stock and the composition of ammonia) were not even available as measurements. In a refinery power plant, you burn whatever is left over at that moment. For gas, that may be pure hydrogen, pure butane or anything in between. And don’t get me started on the disgusting sludge they call heavy gas-oil.

As for the concentration of ammonia in the ammonia feed (yes, really), I asked for a manual measurement so I could have at least one data point. They told me it was impossible. I asked why. The answer was “when we open the storage drum, it catches fire. The contents are pyrophoric.” Yay.

Dependencies

The recommendation at the end of my internship was to switch off the unit and to tear it down. My manager agreed but it turned out to be impossible because other units had come to depend on this process to consume their input or output feeds.

So for all I know, the piece of crap unit I tried to optimize in the early 2000s is still there, making the surrounding air just a tiny bit dirtier.

Conclusion

Do not believe that tech is different from other, existing disciplines of engineering. There are other industries that have worked on distributed systems. Many software engineers I know are interested in the aerospace industry for a similar reason, which usually means binging on plane crash documentaries. But throughout many different industries, you can find solutions to many of the same issues that you have with your distributed cloud microservice mesh, or whatever.

08 Sep 2020, 18:19

pkgsrc Developer Monotony

Somehow, my contributions to NetBSD and pkgsrc have become monotonous. Because I am busy with work, family and real life, the amount of time I can spend on open source is fairly limited, and I have two commitments that I try to fulfill:

  1. Member of pkgsrc-releng: I process most of the pull-ups to the stable quarterly branch.
  2. Maintainer of Go and its infrastructure.

Unfortunately, these things are always kinda the same.

For the pull-ups, each ticket requires a verification build to see if the package in question actually works. That time tends to be dominated by Firefox builds, of all things: we fortunately have people that maintain the very regular updates to LTS versions of both firefox and tor-browser, but that means regular builds of those.

As for Go, there are regular updates to the two supported branches (1.14 and 1.15 as of now), some of which are security updates. This means: change version, sync PLIST, commit, revbump all Go packages. Maybe file a pull-up.

This becomes somewhat uninteresting after a while.

What To Do

Honestly, I am not sure. Give off some of the responsibility? There is only one person in the pkgsrc-releng team that actually does pull-ups, and they are busy as well.