Return of the Christmas Tree Project (ch 5): More LEDs!

It's been two years since I started my Christmas tree project. Last year, I didn't work on the project at all, but this year, we're back in full force. And I bought more led lights to put in my tree. In fact, we'll be doing five times as many LEDs as before!

Because it had been so long and because I had moved since I worked on it last, the first thing was to get the project up and running again. And the first thing to work on was my Raspberry Pi. Unfortunately, the sd card in the Pi that I was using before had gotten corrupted.

I spent quite a bit of time looking for my card reader, but all it did was confirm that the sd card did not work at all. Luckily having found the card reader also made it very easy to get a new sd card ready. The next thing was to find the code. It wasn't on my desktop, so it had to be on my private git server. However, that server failed a while ago, so I had to track down the storage I used in that server. This took some effort, but I found it eventually. And then it turned out that the code wasn't on there either...

The code had apparently only been on the sd card, so I would have to write it again. The amount and complexity of the code was such that that was feasible enough, but it was still a bummer. I took a look at the code from the project that had been the inspiration for this one to look at what libraries had been used. Looking at that repository made me remember that I had shared my own code with the world as well. And that was where the code was! You see, I only kept my private projects on my private git server. My public projects were all on GitHub. And indeed, the lost code was right there on GitHub.

It seems that I did have some code that was only on the sd card. In particular, I seem to be missing the three dimensional effects that I wrote. One was a rainbow effect and that should be easy enough to recreate, especially because the one effect that I still have does have much of the general structure I'd want to use. The other effect was an effect that never really worked that well, and isn't really that much of a loss.

With the pi running again and the code being back in my possession, I could get to working on the thing again. I was unsure if I would be able to run all the LEDs from one power source, so that was the first thing to test. I connected all my new LEDs and set them to white light at 25% brightness.

Several interpretations of white...

To be fair, all lights turned on and all of them being white is the worst case. But, 25% brightness is roughly 75% below the worst case. And the results were pretty bad. However, this looked like the power adapter was handling it just fine. Instead, it looked like voltage drop to me, which is not related to the adapter but to the lights and the wires between them.

So, I rigged up a quick test and saw that indeed, things looked a lot better if I connected the power source to each string of lights separately, even if it was still the same single adapter. The light strings do have extra wires that help you do this, but the bare wires aren't too easy to use. So, I decided to take some of my Dupont cables, cut them in half and splice the halves onto those wires to make them much easier to use. Using these tools and this skill set was a lot of fun, which surprised me because I had forgotten how much I liked doing this.

A bit of solder

Some tape

And some more tape

I added a breadboard to map from one input coming from my micro-usb breakout boar to multiple wires going to the different strings. This actually made for a surprisingly good setup.

Now, that's what I'd call white

I also worked a bit on my code. I took some of my old one-dimensional code and cleaned it up. I also wrote a simple rainbow effect. It's not as good as an effect that includes a tree and coordinates of the LEDs, of course, but it's still quite nice. And I did use some of the lessons I remembered from making the rainbow effect for in the tree two years ago.

The next step will be to try to cram all these LEDs into my small tree. (I'm at half the number of LEDs Matt Parker used, but my tree is also a lot smaller.) And then I can start using the most essential and complex code I wrote last year to map all the LEDs. I'm happy I won't have to rewrite that code!

Unopiniated variable binding

I'm a bit crazy. I like vanilla front-end work. I just like it when you do not need a compile step and what you've written is what is executed. I've always been like that, even when it made a lot less sense than it does right now, like in the times of Internet Explorer and browsers having lots of incompatibilities and some not supporting standards well at all.

In the light of using vanilla javascript, seeing the technology making progress is really nice. Sometimes, that means that you get shiny new tools built into the browser. Other times it means that you no longer need a library to do what you were already doing. I loved learning about document.querySelector(), as it covered one of the two things I used jquery for. The other thing I used it for was later covered by the fetch api. Learning about css variables was far more exciting to me than learning about the css preprocessors of the time.

When I do use a framework (for personal projects), I like using something that isn't very opinionated. The big front-end frameworks generally tell you how to set up your whole project. I prefer something that I can introduce in that one place if I want. And if the project grows big enough, I will refactor it to have a better structure. I probably end up with something similar to what the frameworks prescribe. Or I might end up with something slightly better or a lot worse. In any case, it'll probably be more tailored to my project.

In the past few years, my goto front-end framework has been Knockout.js. When I was first introduced to it at a previous job, I thought it was just another AngularJS with a slightly different syntax, but in the years after that I started appreciating it for how unopinionated it was. There was one major part of its usage that I didn't like, but adding knockout-es5 solved that. The es5 library doesn't work well with knockout's component functionality, though, which is essential once you start refactoring. So I wrote a script that worked around that. The script was a quintessential hack: it does some pretty ugly manipulation and leaves things in a state where it usually works. Together, all of these basically gave me what I wanted: unopinionated variable binding.

The time to let go of knockout has been steadily approaching for a while, though. There really hasn't been much development of the project for years. The project's website has had trouble several times recently. There is tko.js which aims to be the next version of knockout, but development seems stalled in an alpha state and it doesn't actually address most of what I want to see changed. I just don't really see a path towards not needing the knockout-es5 or my own script on top of it, and both of those feel more like temporary fixes than true solutions. For projects that I expect to live for a long time, it just doesn't seem to be sustainable enough to keep using it.

Recently, I have been working on a very old project. This project is built around the google maps API. Because of that, it doesn't actually do a lot of html manipulation. So, even when redoing most of the project six years ago or so, I just did that little bit of manipulation in vanilla javascript. But now I'm adding features, and some of those do require a lot more manipulation.

That sent me into a bit of a panic. Not using a framework was starting to weigh down the project. Using knockout doesn't feel like a sustainable option, but other frameworks are much more opinionated than I like. Even the ones that are minimal and/or proclaim not to be opinionated require you to work in components and thus don't just drop right into your project to do that one task you need from them. I felt like I was at a crossroad with none of the paths leading where I wanted to go.

I think I have a solution, though. I started looking at WebComponents recently. It's a collection of three javascript APIs that are mostly used by frameworks. That's because using them without one is complicated and doesn't really manage to compete with using a framework. I have been using two of those APIs to prototype what is basically my own framework. It provides the unopinionated variable binding that I was looking for and not much more than that.

It's only some three hundred lines of code, but it's able to bind variables to text, attributes and events, and it's able to repeat parts of your html or remove them. About a third of the code is dedicated to a solution for tables, as the default looping solution clashed with the way those are special in html. And because it is built on top of WebComponents, the system to upgrade to when refactoring is built right in.

There's definitely more to be done. When you use the prototype incorrectly, it doesn't tell you what you need to change. There will probably also end up being more things that the library needs to do to. But I do believe this pretty small prototype already covers most of what I want.

I compared total byte size of my prototype to Alpine.js (just because it came up in a search for small frameworks) and the byte sizes are about the same. That's more impressive than it sounds, because we're comparing a minified and gzipped version of Alpine with the plain sources of my prototype. While size comparisons aren't actually that useful, size does matter. It matters in how sustainable maintaining the code base is. It's also a part of how close it is to vanilla javascript, which is a part of how it stays unopinionated and how it can interoperate with existing codebases and other frameworks. For neither of those it's the whole story, but it is an important part of it.

I think I'll be using this for the time being. And I'm starting to think that a version of this may end up being my tool of choice for a long time to come...

Christmas Tree Project Step 4: Improving the Mapping

Last time, I got the first 3D mapping of the LED coordinates. I wasn't entirely happy with the results, though, so it was time to improve them. So, I started by working on code that I could use to verify the results of the scan. The idea was to turn a few LEDs on at a time, so you can visually verify that those LEDs are in the right order on one of the axes. However, while the y axis is completely obvious, the x and z axes aren't visible in the real world, so that was the first thing I did: create a gradient from red to blue on one of the axes so you could identify the axis.

The x axis

From there, I turned the lights green one by one according to their order on that axis. My original idea was to turn just the light after it and the light before it on, or perhaps a few, but I ended up just turning everything on, with the ones that were before the green LED being red, and the ones after it blue. Then, you could press either space if the LED appeared to have the right coordinate when it came to that axis, or x if it didn't. The software would then remember the incorrect coordinates and write them to a file when done.

Verifying the green LED

A modified version of the mapper can now also be used to scan only the incorrect coordinates. In that case, it will read which LEDs need to be rescanned from the file. It then scans every such LED from all four directions, but only updates the coordinate components of the axes marked as incorrect. With those changes made, I got back to the physical tree and got working on my new coordinates.

I decided not to use my previous mapping results, but start over instead. I had marked the position and orientation of the tree and the camera stand hadn't moved, but the camera wasn't in it in the exact same way. The way the webcam was mounted on the stand was a bit improvised and the webcam was borrowed from my work setup, so it hadn't stayed in the stand and the result was that I didn't put it back in the exact same way.

Improvised does not mean bad!

So, I took a few pictures with the new setup to get the tree properly in frame again and then started scanning. I alternated between judging the coordinates and rescanning them several times until I ended up with something that I was happy with.

Deciding what LED was wrong and what wasn't always obvious. When two LEDs are in the incorrect order, this method just isn't great for determining if the first one or the second one was wrong. When there are more LEDs involved, it gets even more complicated. I did develop a bit of a feeling for it, I just chose for rescanning more than necessary in a number of cases and I restarted the verifying process without saving the results a number of times. I could probably improve things by allowing you to go back in the LED order as well, so I will probably do that if I end up mapping another tree.

I was also important to learn that the result just wasn't going to be perfect. Slight changes in perspective can have big results, and we're already combining several perspectives into one coordinate. Whenever two LEDs were a close call, it was best to just go with whatever result the scan had. The mapping wouldn't be perfect, but it was never going to be perfect and as long as it's close enough, it'll look good, especially considering that the viewer won't have a fixed perspective either.

Finally, there was one LED left that just didn't get a good scan for its Z coordinate. I checked the photos and saw that it was indeed on, but just wasn't visible from either of the two opposite sides. I decided to just set the coordinate manually, so I lit it up as well as some LEDs around it. I identified which were its closest neighbors and gave it a coordinate between them, which I manually put into the output file.

With the new mapping, the next thing to do was of course to run the test effect again. I think the actual changes were relatively small, but the whole effect looks a lot more smooth to me...

(Well, I promise it does in person, at least.)

As before, all the code I wrote for this project can be found on GitHub.

Is the this the end of this project, then? Not just yet. The basic setup is done now, but I do still need to run effects on the thing. I am planning to both write some of my own and run the ones submitted to project that serves as inspiration for this one...

Christmas Tree Project Step 3: Mapping

Spoilers of what I pulled off

With the hardware gathered and the lights working, the next step was to put the lights in the tree. I took a bag of zip ties that I think I bought with the intention of using the for cable management in my computer (I bought way too many, though). For the most part, this was pretty uneventful, but there were a few things that I would do different if I'd do this again. The first is that I would plan it more carefully and use more zip ties and attach in more places. The second is that I dislike the colored wires between the lights, so I think I would sleeve them in something green to make them stand out less.

The colored wires do stand out...

I also wanted wifi on my raspberry pi, so I wouldn't have to run a network cable to it. As I realized last time, the device itself doesn't have wifi hardware, so I went looking for wifi adapters. I found two. Both are old and were probably cheap, but they were worth a shot. The first adapter didn't get recognized by the Raspberry Pi, but the second one worked well and after some messing with the configuration, I was able to freely move the device anywhere I had power.

Getting wifi running

The next part was the real challenge: mapping the LEDs to three dimensional coordinates. I did actually send an email to Matt Parker to see if he could share the code he used for this, but unfortunately, he didn't have it in a usable form. Not wanting to wait, I started working on my own.

Getting the camera to take a picture was both easy and hard at the same time. Basically, copying some code from the internet and saving an image wasn't that hard. However, there were basically three libraries to choose from, and none of them was exactly what I wanted and I definitely didn't like that you have to install non-python dependencies for each of them. In the end, I went with pygame, which uses sdl2 under the hood.

My complete mapping setup

There were also several issues with the camera that I had to solve once I started using it more extensively. The first was that the first photo would often have different brightness at the top than at the bottom, with a clear dividing line about a fifth from the top. However, this didn't show up at first, as it starts happening when you run the program more than once. I solved this by taking an image from the camera on startup, discarding that and then working only with the images taken later on.

The next problem was something I started noticing when I was working on the mapping: the photos taken were often from well before I gave the command, sometimes by ten or more seconds. I got around this by re-initializing the camera every time I wanted to take a picture, as then the picture would always end up being current. To prevent the previous brightness issue, though, I had to discard an image each time I did this.

With the camera working, the next step was to start identifying the LEDs and their location. The idea was simple: turn on a LED, take a picture, identify the brightest pixel in the picture and repeat this for the next LED. I also added a step of drawing some lines on the picture, so I could see the result.

Pretty orange lines

The first result wasn't bad for some of the LEDs, but just going with the brightest pixel didn't quite work for others. So, I changed my code to take the average of several bright pixels. My first implementation was quite bad and allowed a gradual increase in brightness to shift the average towards the top of the image. But even after fixing that, the results weren't to my satisfaction at all. So, I decided to take a different approach. Instead of looking for the brightest pixels, I just look with pixels that are above a hardcoded brightness.

For the most part, that gave pretty good results. However, when a lot of light was being reflected, the reflection of the LED would sometimes throw off the calculation. The way I solved this was by lowering the brightness of the LEDs. Originally, I had assumed that full brightness was a good idea, but in the end about 20% brightness gave better results because there were far fewer reflections that were bright enough to be taken into account.

Next, it was time to do multiple scans and combine the results. Doing multiple scans was straight forward: just put the code in a function and all that function four times, with a bit in between where tell the user to rotate the tree. For combining, I gave each mapping result a score, based on the brightness and on how many pixels were involved. Then, I took the y coordinate from the highest score on any of the four scans, the x coordinate from the best among the front and back scans and the z coordinate from the best of among the left and right scans. And those results I printed to a file.

In order to check the results, I quickly threw together some code that read the file (this was basically a copy-paste job from Matt's code) and then changed the color of each LED in order of either the x, y or z portion of the coordinate. And I must say, I'm not at all displeased with the result. It's not perfect, but it's quite good, especially if you consider this was based on the first time I did a full scan of the tree.

There are still LEDs that pretty clearly have inaccurate coordinates. So, that's what I'll have to do for next time: build the tools to see what LEDs are wrong and correct those...

Oh, also: my code is now on GitHub.

Christmas Tree Project Step 2: The Lights

Last time, we left off with all supplies gathered. Now, it was time to wire things up and get the lights lit up in some pretty colors. First, though, I had to solder headers onto one of the breakout boards. Soldering isn't something I'm great at, but this seemed like a manageable task.

Headers

With that behind me, I could start wiring things up. My first try was to just connect the power wires to the lights. But the result was nothing. However, I didn't know if this was because I had made a mistake, or that they just wouldn't light up until there was a data signal telling them to do so. So, I took out a Raspberry Pi that wasn't doing anything at the moment. After spending way too much time on things that should have been simple (like trying to configure wifi on a device that doesn't have wifi), I managed to get things up and running.

Here, I used a little bit of a trick. In order to make it work. In order to make two power supplies work together nicely, you need to wire up the Grounds. However, the Dupont cables I was using didn't have an easy way to go from the breakout board to the lights and to the Pi. However, the Pi has multiple Ground pins, which are wired up internally, so I connected the Lights to one of them and breakout board to another, basically letting the power flow right through the Pi. Unfortunately, nothing happened yet again.

Nope

Still nope

Now, it was time to do some debugging. I wasn't even sure if I had gotten the right one of the two connectors, so I messed around with that for a bit, but to no avail. Then, I realized that I could just get rid of the power adapter and breakout board for a bit. As long as the power draw wasn't too high, powering the lights from the Pi's 5V rail shouldn't be a problem. And indeed, I got things to light up!

My one LED program works

This meant that the Pi, the code and the wiring were all good. The problem had to be in the adapter or the breakout board. I should probably have gotten out a multimeter and started measuring. I decided to try something else: powering the Pi from the breakout board. This could definitely potentially damage to Pi, I went with it anyway. And I did see that the Pi's power LED only powered up when I was touching the ground pin on the breakout board. Apparently, I had done poor job soldering and there wasn't a good contact there...

Green across the board!

After making sure the soldering job was done properly this time, I hooked things up again. And I got the lights to turn on this time. It seemed that the hardware part of it was done now. And because programming is what I feel comfortable doing, I was quickly writing several effects. These weren't actually getting me closer to my Christmas tree goals, but I liked doing it nonetheless.

The effect that I liked the most was one that picked a random color for the first LED, and another color for the last LED without changing the last LED just yet.  Then, it gradually moved through the lights in the order of the wire to turn them a color that was slightly closer to the color for the other end each time. Once done, it would pick a new color for the first LED, and do the same thing on the way back. I wanted to include a video of that happening, but the effect didn't show too well on video and there were also some interference patterns causing lines of darkness. So, instead, a picture of each LED in a different random color will have to do.

A poor substitute, I know...

Next time, I suppose I'll have to start involving the actual tree.

Christmas Tree Project Step 1: Materials

Early this year, I watched a video by Matt Parker on his project to make a Christmas tree with LED lights. The lights were individually addressable and he mapped their 3D coordinates so he could make effects that followed the tree rather than the wire of the Christmas lights. I was instantly inspired to make something similar. However, I didn't actually see the video until after the holiday season (which is when he posted a follow-up in which he runs people's code on it), so it didn't really make sense to do so at that time.

I'm not usually one who remembers to follow up on such ideas at the right time, but somehow I ended up at the video again a while ago, which was nicely just before Christmas. This time I was in the perfect position to actually make one myself.

Now, Matt has an important tip in his video for projects like this (in a much broader sense): start small cheap. That's not something I'm good at. I like to start on something really big and ambitious and work towards a grandiose goal, and not care too much about the money I'm spending on whatever new project I'm working on. It happens a lot that I then do not finish the project, but that's just something that I've made my peace with. However, I was also struggling with the fact that if I ordered the lights from an affordable place, I might not actually receive them until after Christmas. So, that's why I decided to go back to his tip and actually follow him.

I actually already owned most of the things I needed for the project. About two years ago, I was similarly inspired by a video on YouTube for another project involving Christmas lights, so I had ordered a string similar to the one Matt used, but I never ended up doing anything with them, so I still had them. I also have plenty SBCs and microcontrollers, so that wasn't going to be a problem either. The one thing I still needed was a tree.

The lights

In the video, the simple start was one with a clothes rack standing in for a tree. I didn't want to go quite that simple, I wanted to make a "Minimal Viable Product" this year and then I can see if I want to go bigger and better next year. I did want an artificial tree, though, as I don't want to deal with the mess and I want to make something that I can just retrieve next year (if I don't end up going bigger). I also didn't mind spending a little money on a tree because it was the only part of the project that would cost money. So, I visited a physical store and bought myself a 90cm (2'11") tree.

A 1.5L bottle of Pepsi for scale because I didn't have a banana

The next challenge was the power adapter. It turned out that that I actually had a lot more of those than I thought I did. However, almost all of them were 12V or above, and the lights needed 5V. One adapter that was 5V only supplied 1.2A. Now, the string is going to need about 3A when all lights are fully lit. I can probably get away with a bit less, but 1.2A seemed like it might be pushing it a bit. One other adapter was rated 5V and 3A which is perfect, but it had the drawback that it was a micro-usb cable that had snuck in with my barrel connector adapters.

One clutter of adapters

Micro-usb cables have two problems. The first is that it's not at all easy to connect to the power lines unless you have a proper connector. That problem disappeared when I realized that I had some micro-usb breakout boards that I can use for this. The second problem is that they are pretty infamous for not reaching the Amperage they are rated for. However, I also had a solution for that: tools to see how the adapter does if you draw up to 2A. That wasn't the full 3A, but it would still give me a good idea if the adapter was likely to work.

1.8 Amps...

As it turned out, the adapter fell well short of the 3A with only about 1.8A, but that was at least an amount that is likely to work as I have all my leds go on full white. And if it doesn't work, the advantage of using the micro-usb break-out board is that I can probably find other cables to use, either in my own possession or in a store.

The micro-usb break-out boards

With all the components collected, I guess the only thing left for me to do is to say that this story is... to be continued.

Namespaces and the inevitability of Docker

Today I learned something that I thought I'd share. I was doing some research on sandboxing certain processes in linux for a project that I'm working on when I found out about linux namespaces. These are a kernel feature that allow isolating of resources from the rest of the system. Namespaces usually govern resources that are traditionally shared over the entire system, such as users and groups, the network stack and process identifiers.

The first thing that went through my mind as I read all that was that it all sounded like the things I needed. It will be a definite amount of work to get everything working the way that I want it to, but it sounds like a better than using a sandboxing or containerization tool that isn't made for what I'm trying to do and has other functionality I'll have to work around. Besides, these other tools are usually built on top of the namespaces anyway.

The second thing that went through my mind was that this makes the appearance of Docker a couple of years nothing less than inevitable. The first namespace was added to the linux kernel all the way back in 2008, but it all becomes clear when you read that a pretty hard and very important namespace (the one governing users and groups) was added in 2013. That's the very same year that Docker was started.

Isolating processes from other processes has been something that people have been aiming for for a very long time. One can at the very least trace it back to chroot in the late seventies and early nineties. This was a very limited and perhaps even flawed approach, but it shows that the drive has long since been there. So, then seeing that in the same year that the kernel provided one of the most important pieces of technology this software was created, would seem to imply that if it hadn't been Docker, it would have been someone else who started a similar project with similar functionality under a different name.

Given that the project needed some time to get to a more or less stable state and that it needed good adoption of the kernel that provided the required features, even the sudden popularity explosion of Docker makes a whole lot of sense. After all, this was a technology the world had been looking for decades...

What DuoLingo taught me about Buffy

I am currently learning Danish on Duolingo. Why Danish? Well, that's a weird story.

My first introduction to the language was when I was watching Angel (you know, the Buffy the Vampire Slayer  spinoff). The version I was watching came with subtitles in somewhere near fourteen languages and the only way for me to turn them off was to cycle through all of these. Soon enough, I just gave up on turning them off and stuck with the first one, which was displayed by default. So you could say that Danish's proximity to the beginning of the alphabet is why I am learning language.

The second time I learned some Danish was due to a band (dance act? pop duo?). They're called Infernal and they usually sing in English. They had one hit (From Paris to Berlin) and that's approximately when I started listening to all their music. At some point, though, I found out that they had some songs in Danish under another name (Paw&Lina) as well. I liked two of these songs rather a lot and also looked up the meaning of what I was listening to. So you could say that Infernal is the reason I am learning this language.

Ultimately, though, the reason that I started learning the language is just that I liked it a lot. That's why I started watching a tv show in Danish and started doing Duolingo lessons. I stopped watching the tv show after a while and I also didn't continue putting the time into Duolingo. And then a year or so later, I picked up the app again and dropped it not too long after. My current attempt to learn the language is my third one.

The other day, I was watching some episodes of Buffy with a friend. It also had Danish subtitles, but this was only one of four languages. Moreover, though, my Danish has gotten to the level where I got just enough of it for it too be rather distracting (which also doesn't happen when it truly doesn't take much effort to read what you see, which is not where I'm at at all yet). So, I turned them off. However, yesterday I was actually watching some episodes on my own and I wasn't too bothered by being distracted, so I left them on.

That gets me to today. Today I was doing a quick lesson in between things. And they taught me the very first Danish word that I had learned. One that I had figured out from just the subtitles that first time because it had kept recurring. And then a bit later, the app taught me another word. This time, it was a word that had stood out last night. That was quite the coincidence. Or was it?

The two words were "Boy/Girlfriend" and "friend". I had started on a new category: people. And that's just the thing. Buffy and Angel aren't about the monsters. The monsters basically just provide the backdrop. People - and the relationships between them - are what the shows are really about. So, it makes perfect sense that this was the moment that I started learning words that I already knew.

And at the same time, I realized just how much the show really was about the people...

The Pinebook

In the past, I have written about Single-Board Computers a number of times. Today, I want to do something similar. This time, though, it's a product by a SBC-manufacturer that is still more or less an SBC, but at the same is a lot more than just that. I'm talking about the Pinebook.

So, this manufacturer joined the SBC market with a strong offering: the Pine A64. It was on Kickstarter and it promised to do 4 cores for less money than the Raspberry Pi. Once you started looking at it more closely, you'd find that you probably wanted at least some of the extras and probably wouldn't end up paying less, but the idea was still there.

There was something else that made the Pine A64 stand out. That was that this wasn't going to be just another Raspberry Pi-clone. Most of the other SBCs were either quite a bit more expensive than this thing, or tried to be as close to the Raspberry as possible. Without the word "Pi" in the name and a brand-new form-factor, the Pine A64 made it very clear that it wasn't going to be another clone, which was a rarity for devices that weren't in a different price range all together.

However, it was something else that drew me to the device. It was the HEVC (aka x265) playback support that was promised. This was several years ago and the Raspberry only got HEVC support earlier this year with the RPi 4, so it was something really nice to look forward to. Unfortunately, this turned out to rely on proprietary drivers which basically meant that it only worked on Android, which wasn't really the operating system I wanted to run. I ended up finding this out before the end of the campaign, but decided not to cancel my pledge after all. In the end, though, this is the reason that my Pine A64 has basically been idle ever since I first tried it out just to see if it worked.

But then came the Pinebook. This was basically a Pine A64 (though they made a different board, the main components were all the same) put into a laptop. The whole thing cost only $99 which is incredibly cheap for a laptop. I read about it on a forum I frequented and decided to just go for it. After shipping and taxes, I was down quite a bit more money, but in the end it was still a good deal.

My Pinebook has served me well ever since I got it. It's all about expectations, though. The device isn't really going to play back video well* and it's not going to be flashy or let you have a bazillion tabs open. However, it does extremely well as a digital typewriter, which is what I've mostly been using it as. I've also done some simple GIMP (photoshop but open source, basically) work on it and I've even run some old games in DOSBox.

More importantly, though, I've never been careful with this laptop, which was largely possible because of its price. I've put it in bags I wasn't entirely sure would be handled carefully, I've taken it with me to the strangest places and I've stuffed it in lockers where it barely fit. The result is that the screen is damaged in quite a few places. Of course, the other result is that I've always had a laptop with me when I needed - or even just wanted - it.

In a way, this post may feel a little outdated. That's because the next big thing is the Pinebook Pro, which is a new version of the device that costs twice as much and is meant to be much more usable as a daily driver. I have ordered it and it's supposed to arrive somewhere next month. I might use it to write a sequel to this post at some time. However, I don't think it will completely replace the Pinebook that I currently have, so this piece still feels somewhat relevant to me. And besides, I felt like writing about this device and ultimately, that's what this blog is all about.

*: I should probably check if this is still as bad in newer versions of the software.

Right back at ya!

Some two and a half years ago, I started a three-parter on discrimination on this blog. That was one of the last posts I wrote in a long time. That three-parter was something that had been brewing in my head for a very long time, so I still intend to get back to it eventually and write the remaining two parts. The second part is one that will be more or less the same no matter when I write it, except that I might learn a thing or two and change my opinion a bit. The third part is one that is much more related to the things happening in the world at the moment, so its content will largely be dictated by when I do actually write it.

Today I want to do something different, though. I want to comment on something that I wrote in the first part, and add to it the understanding that I have gained since I wrote it. Let's start by quoting what I wrote in the past.

However, there is this strange other side to [the word nigger], where it is accepted if a black person says it. I would understand this if it was about intention and sometimes a bit of it is about intention. However, the word is also considered racist if it is used by a white person without intending to insult. If anything, the fact that white people cannot use the word while black people can sounds like racism to me.

Jasper Horn right on this blog

I don't really want to get into whether calling someone a nigger is racist. I do think that I can say without evoking any controversy that you generally shouldn't call someone a nigger. Black people generally don't like being called a nigger and that should be more than enough reason not to do so. I think that by extension, we can say that is often okay for one black person to call another black person a nigger. And by putting it like that, I think that we can clearly see that the idea that whites cannot use this term isn't actually racist. After all, it's not that they are actually not allowed to say the word, it's that they shouldn't.

Today, I want to look at why a white person shouldn't call someone a nigger while a black person can do this if they want to. When I wrote that, I didn't understand it at all, and I think that the quote above very much shows that. I think I understand it a bit better now, so that's why I'm writing this.

My understanding of this changed completely when I read something on the internet. I don't know where I read it or who wrote it, but what they had written was that when you can respond with "right back at ya", an insult is much more of a playful thing than an insult.

And that's basically all there is to it. It's basically that any insult doesn't really hit as hard when it could also be used against the one using it. For that, it doesn't matter what the insult itself is. It could be some way in which a person is not neurotypical, it could be related to a hobby that isn't considered normal by the mainstream, it could be almost anything else. The key is that when the one using the insult falls in the same category, they can't really mean it as an insult, so it's playful rather than truly an insult.

Of course, being a white male was the first thing that made it hard for me to understand the way this worked for a word like nigger. However, while I think that made it hard, I also think that nigger is also a more or less unique situation where we took things to the extreme. Just like how I think that for many people the main reason it's a "bad word" is because they have been taught it's a bad word, I think that for most people a black man using the word is accepted behavior because they have been taught it's accepted behavior. And we've taken things to a rather extreme point to begin with by basically saying a word is not okay regardless of context or intention, and making basically implying that it's always just in friendliness when a black guy says the word is a similar extreme to me.

At the end of the day, understanding where this difference in judgement of people based on their skin color helped me understand why this isn't actually a problem. I'm not entirely sure if I think this is a good way to tackle problems, but at least now I understand. And if you didn't before, maybe now you can too.

The Log-in Superposition

Traditionally, a site has exactly two states. You are either logged in, or you are not. All people get the same site when they are not logged in, and they all get a different website when they aren't. Recently, I have noticed some websites taking another approach and introducing that's the middle ground: not entirely logged in, but also not entirely not logged in.

When I say I noticed this recently, I actually meant that I noticed it a while back. In fact, I noticed the same thing on two completely separate sites and one of them seems to have stopped using this paradigm. I just never got around to writing about it. I still think it's an interesting approach, so that's why I'm writing about it now.

As a brief interlude, let me quickly explain the title of this post. Superposition is a term from quantum mechanics and it's all about there being discrete states, but reality actually being a combination of chances it's in each particular state. They are still discrete states and you will never observe anything but any of the states, but you can prove that until you observed it, it's not in any one of the states, but in a superposition of all of these states. It's a very complex thing to wrap your mind around and it doesn't entirely fit here, but I still thought it was a fun thing to make a quick nod at.

So, what is this third state? It's basically where the site thinks it knows who you are, but does not trust this to be the absolute truth. In this state, everyone has their own version of the site, which may contain things like an unread message count, or the quick menu that shows the most recent items you interact with, but it does not allow you to read your messages, reply to them or see the full history of items you interacted with. When getting to a part of the website where you can do with these things, you'll be prompted for your password (often with your email not editable, but a "this is not me" link, because they do imply they know who you are).

Basically it's a hacking risk mitigation strategy. It's allowing you some convenience of remembering you, but recognizes there is some risk in doing that. However, hacking that part of the website is of limited value because it would not allow the hacker to see much information about the user, or take actions on their behalf.

At the end of the day, I'm not entirely sure whether I think this is a good strategy. I think the added convenience is often limited because you'll end up needing to provide your password after all most of the time. Nevertheless, I think it's very interesting. And in a way, it's pretty similar to requiring the current password to set a new one. If I see a good opportunity for doing so, I might implement this myself. Then again, I also might not.

The Burqa Ban

I live in a country where it has recently become illegal to wear a Burqa in public. Well, I think the correct term for the garment most commonly worn in these cases is Niqab, but it is commonly referred to as a Burqa over here ("boerka" in Dutch). Moreover, though, the Burqa alliterates nicely with ban, which is why I picked it for the title, and it's also the translation of a common moniker for the ban in Dutch. In order to be more correct in my text than in my title, I will use the term Niqab in the rest of this post. Of course, the ban does actually cover both garments and so does most of what I have to say, so neither is actually wrong.

I decided to write about this topic after reading an article about a protest against the ban. The whole thing is a difficult matter. It's a complex situation. And I don't really know what to think about it. I see why people are against the ban. I also see why the ban does make some sense. I'm not going to write towards a conclusion because I don't have a conclusion. Still, I felt like writing down my thoughts. And writing on my blog again after it has been far too long is a nice way to do that.

Inequality

I think it's hard to deny that the Niqab is a clear sign of inequality between men and women. While men aren't entirely free to wear whatever they want, they also do not have the same limitations as women. Not being allowed to show your face is a pretty strong restriction.

Of course, this is a much stronger point when you are looking at the Hijab. It's much harder to deny that wearing a Hijab is something that girls and women do not get a say in in many cases, they just have to. This can range from fear of violence from community members if they don't wear it to merely the disapproval of parents. This disapproval can include (fear of) getting disowned, but can also be limited to just the way a parent feels about you. Of course, disapproval by a parent over a simple choice like that can be quite harmful all by itself. Alternatively, it might just be the thing you were brought up to do.

Just the other day, I passed a man with a number of children on my bike. It was a hotter day, so the man was wearing a sleeveless shirt. The boys in the group were dressed less casually, but they were still just wearing shirts. The girls in the group were wearing very long sleeves, clearly not in keeping with the weather, and Hijabs. All of the kids looked like they were in their late single digits or early teen years, so I doubt that they were making independent decisions about this. As I overtook the group, a chill went down my spine because that's not what equality looks like to me.

The Niqab is a more extreme garment. Not showing your hair because you are female just isn't as extreme as not showing your face because you are female. I think either is a clear sign of inequality, but the Niqab is simply more polarizing because it is more extreme, even though it's harder to say to what degree the women in question feel they have no choice but to wear it.

It doesn't really matter to me whether women actually make an independent decision to wear a Niqab - or a Hijab, for that matter. All that does is show that they have been raised in a culture where they are taught it's okay to put such limitations on just one of the two genders. It shows that the inequality is systemic, not that there is none.

A Symbol

At this point, it's clear that the Niqab is a symbol of inequality between men and women. When you consider the limited number of people who wear it and the claim by many that it is their own choice to wear it, it becomes clear that it's not a big part of the inequality itself.

However, I don't think that banning a symbol is the way to go. It's never very effective because it does not address the underlying issue at all. And even if all the main symbols of a problem are banned, new symbols will crop up to take their place. You simply cannot expect the banning of symbols to actually have much effect on a systemic problem.

I don't think inequality between men and women should have a place in our society. There is still a lot of it and we have a long way to go before we have actually banished the inequality all together. I also think that the Niqab and Hijab are indicative of a culture that has more inequality than our "Western" currently does. However, I don't think a ban will change anything, even though I do not have any other ideas on how to get rid of this heightened inequality in this subculture of our own.

Real Motivations

On the other hand, I also think it's clear that this ban is religiously motivated - or perhaps even racially motivated, the two are strongly related here after all. No decent politician will admit that, though. Nevertheless, it is clearly a law introduced to cater to the part of their following that is intimidated by the muslim influence on our culture.

That's the most wrong thing about this ban. Even if the ban can be defended, the real - as I see it - motivation of the ban just cannot. It's one thing to be ineffective by attacking symbols or to end up attacking a problem that isn't really too big because the number of people involved is quite limited, but it's an entirely different thing to be attacking a group of people based on their culture or religion.

Hiding Faces

There are other reasons you can give for the ban, and those are the reasons that make a lot more sense to me. It basically comes down to the reason why I avoided using the word "discrimination" in the previous paragraph. While the law is colloquially known as the Burqa ban, that's not literally what it is. Rather, it is a law disallowing covering one's face. This is not really a new thing, as it wasn't really allowed before either. The new thing is that the freedom of religion does not count as a reason to do it nonetheless.

The balancing of different rights is always something that is required and hard at the same time. One way you have to find this balance is to see where the right of equality cuts into the right to freedom of religion. Another way is to look at how far the right to freedom of religion trumps our laws and cultural norms. To understand that, we have to look at why we do not allow one to cover their face in public places in general.

Whether it's a police officer, a bus driver or your local baker, when you interact with someone, you are creating a sort of contract with a person. In person, this contract traditionally does not include anonymity. The other person knows who they are dealing with and that's generally a good thing. One can easily look at online anonymity to see how it can bring out the worst in people. It's much easier to be rude to someone if you know they can't really recognize you on your next encounter anyway.

Of course, we also behave (somewhat) nicely to people we do not expect to see ever again. Maybe that means that covering you face does not mean you will treat others poorly. However, there's also the fact that it's hard for others to build the rapport with you and understand your intentions when they cannot see your face. Facial expressions are an important part of the way we communicate and taking that away takes away a lot of our ability to figure out someone's true intentions.

The final point is one that perhaps is a little less closely related by the ban because it's not actually related to covering your face. It is related to the rest of the outfit a Niqab often comes with. This is about how when your garb comes with religious protection, it becomes a lot easier to hide things in it. This could mean that you hide the assault rifles you are going to rob a bank with, which you would probably stand out a lot more with when it wasn't just a religious garb you were wearing. It can also refer to petty theft in a grocery store, at which point it becomes a lot harder to check if someone has hidden the item they claim they do not have when there's the protection of a religious garb to hide it with.

I'm not sure how I feel about the last point I raised. It does assume the worst of people. On the other hand, freedom of religion also means a lot of protection when you simply claim to follow a religion without the need to prove that you do. It also doesn't directly relate to the ban on covering your face. Perhaps that's why we shouldn't really take it into account here.

Conclusion

As I promised up front, I don't really have a conclusion.

There are some sensible reasons for the ban, there are some misguided but well-intended reasons for the ban and there are some absolutely horrible reasons for the ban. Unfortunately, I think that the real reasons for politicians that pursued this bad to do so were in the last of the three categories, even if they won't admit it. And that's a very bad thing. Does that reflect on the ban itself? I don't know. It definitely doesn't make it look too good. Yet, the ban itself is separate from the reasoning of the people who supported it. And... well, I just don't know.

Let's talk Discovery

I have been watching Star Trek: Discovery since it started airing, so I've also been having my opinions on the show since that moment. My initial opinion was that the show was nice, but it wasn't all that Trek. However, with half a season (well, more like three fifth, but that's where we're getting the mid-season break) behind us, my views have changed somewhat and I feel it's time to speak up about it.

The show has been getting flak for a number of things since before the first episode aired. The show's main problem has always been its continuity. When photos leaked of actors in Klingon make-up, people weren't even sure whether these were Klingon because they looked rather different from what we'd come to expect from Klingons. The show's look was also criticized for being closer the Kelvin timeline than to what would make sense for the place in continuity this show said it was situated in.

However, when considering all the problems with continuity, you've also got to keep in mind that the franchise already made big changes before. The distinct look of The Original Series wasn't at all preserved for the movies and The Next Generation. Of course, this show takes place much closer to the original, so that's why people want to hold it up to higher standards when it comes to that.

Well, I'm feeling that we should actually just cut them some slack. Take the uniforms, they don't quite fit in with the established timeline. However, it should be noted that the uniform changed a lot in the past as well. Does it really matter, though? At the end of the day, it's more important that today's viewers like these uniforms than that you can imagine them being used at this point in time. In fact, that's always been a main factor in uniform designs. You can't really say that Deep Space 9's change was done for the viewer; it was clearly done to keep up to date with the era of filming the show.

Star Trek: Enterprise tried much harder to fit in its time. It was designed with the idea that this ship predated NCC-1701 (TOS's Enterprise). It featured uniforms that could have been a predecessor to what we'd seen so far, and as more limited with its technology and featured a number of prototypes of what became staples of the franchise later on.

That, I believe, is part of the reason it never really resonated with the public it wanted to have. Or rather, the different kinds of public it wanted to have. It both wanted to cater to new viewers by giving the whole thing a fresh look and a new feel, but at the same time it also worked really hard on making it fit in the timeline. This was most visible when story lines focused on things from other series, but were very restricted in which ways they could do this.

That's why I'm not too bothered by the change in technology. We get joysticks and HUDs, which isn't really in line with the view of the future that The Original Series painted. However, that future was in line with a vision of the future from the sixties. This show is simply more consistent with a current view of the future. It would be in line with the established timeline to show data disks, but people would laugh at it, since we've got more wireless technology today than they even imagined for the future when designing the original Star Trek.

There's still a couple of things that feel out of place. They tried holographic communications in a previous series set over a hundred years after this one, but they couldn't make it work then, so they abandoned it. It's strange that we see it here then. Ultimately, it's not too consequential really. However, the same can't be said for the holodeck that they have introduced without naming it. That would seem a direct violation of chronology. The fact that we now seem to be routinely using warp-capable shuttles also seems somewhat out of place.

The Klingons are something else that seems to have changed more than would seem to be reasonable. To be honest, though, the change is about is as big as the change in them was from The Original Series to the movies and The Next Generation. This also nicely sidesteps the fact that rubber forehead aliens got to be heavily criticized about halfway through The Next Generation-generation of Star Trek shows.

Then, the real problem of the way Klingons look comes in the form of something that Enterprise did. For a very long time, the change was simply chalked up to the fact that the times and budget has changed. The old look of the Klingons was also something that wouldn't have held up in that era of film making. However, Deep Space 9 subtly introduced that the difference actually existed in the show itself, and Enterprise went out of its way to cement the story of how the change happened into the canon of the show.

However, it definitely looks to me that they are going to address this. The virus that caused the change in looks seems to be something that is going to come into focus soon, if you consider one of the fan theories, which since the latest episode seems rather hard to deny. I wouldn't be surprised if they are going to go with the idea that the Klingons looked different before the virus. That would retcon some things, but not nearly as much as the blatant change seems to suggest at first look. Besides, this way we do get Klingons in line with today's production values. I think we owe it Discovery to let them show us how this plays out before judging them too harshly.

That also goes for the cloaking technology that the Klingons possess. Everybody knows they didn't have that technology at this point in time and it's a widely held believe that they acquired the technology from the Romulans. However, in the latest episode, the Klingon cloak seems to get beaten by the federation already, so that might be the reason they abandon it soon after. This might even get them a reason to pursue the technology with the Romulans. We ought to see how this plays out.

In a way, the Spore Drive falls in the same category. However, people complain a lot less about it. That's because it's a universe changing technology and nobody expects the writers to miss that. So, it's more or less a given that they will give a reason for the branch of technology being abandoned sooner or later and nobody believes the writers won't explain to us why that's going to happen.

In general, I rather liked what I've seen. While it's not always perfect Trek, it's solid science fiction nonetheless. On top of that, it has been trying a lot to bring back the Trek even if that took them a couple of episodes to get to. It's a rocky start, but I would say it's in a way more Trek than The Next Generation was during its first season. I mean, it had a very rocky first season as well and it did redefine for a large part what Star Trek was, for which it simply needed time.

That last part is also part of the problem here, I think. I've noticed a number of instances where the new show was made to feel more like The Original Series than anything from The Next Generation era. And well, the latter is far more season and more recent. A lot of people will miss that fact when the series goes further back in Star Trek history.

There are still things I don't like. Mudd's second appearance definitely fits that bill. I mean, I don't really see any mortal - especially one in Federation Space - having such a powerful device. However, omnipotent beings were plot devices in Trek since the sixties, so they're definitely trying. And I liked what I've seen so far, and I'm willing to give the benefit of the doubt when it comes to the future. And I definitely needed something to fill the Dark Matter-sized hole left in my life.

What is discrimination? (part 1)

For a long time now I have wanted to write this blog post. I just never got around to doing it the justice it deserves. It was called "What is racism?" in my head, but just as I was finally starting on it, I realized that it was really about discrimination in general. I will be using both terms, though.. At the end of the day, racism is just a form of discrimination.

Racism ain’t what it used to be. Time was, if you were racist, you bloody well knew it. [..] No more. [..] racism has become recast as a kind of bad etiquette, where merely saying the wrong thing, even unintentionally, is enough to mark you out as a moral leper.

Tom Slater at Spiked-online

A couple of years back, I was riding my bike from the train station to my home. As I live in the Netherlands, there were plenty of other people riding their bikes as well. One of them got me in a bit of an annoyed mood because he delayed me by not indicating that he was taking a right turn at a traffic light. Then, I approached the next traffic light. There was someone else who slowed down because he had to wait for the light to go green. However, he did this on the left side of the bike lane, making it impossible for me to pass him and take the right turn for which there was no wait.

It was at this moment that a comment towards him sprang into my mind. I wanted to say something like "hey, this is the Netherlands and here we ride on the right side of the road". However, I kept my mouth shut and avoided the conflict. It wasn't until a couple of minutes later that I realized how racist that sentence would have sounded if I had actually said it. After all, this guy did look like his parents weren't born in this country.

To me, the statement wasn't racist at all. I hadn't even registered yet that this person looked a bit foreign and I would have said the exact same thing to someone who looked like he had thorough Dutch roots. It was just a way of me ridiculing that the person for not following the single most basic traffic rule. I didn't really think anything of where that person was from, I just made the ridiculous assumption that this was a misunderstanding of the rules and commented on the fact that there are some countries where they drive on the left side of the road.

But then was that comment truly racist? Did it matter that I didn't mean to offend him over his race? Did it matter that I would have said the same thing to someone who looked more like a native? Would it still have been racist if I had said it to someone who looked more native? Would it have mattered whether that person was as native as he looked? Would the same sentence have been racist if it had been uttered by someone who did so because of how the person in question looked?

My personal interpretation of what racism is - and in fact what discrimination is in general - has not lined up with what it popularly is for a long time. Let's take the word "nigger". This is widely recognized as a racist term. This is because of its historic ties of the word to slavery. I am not trying to deny the hurt the use of this word may incur, but I would like to question the fact that just using a word like that is discrimination or racism. To be honest, I think that for many black people there isn't in fact an association to this slavery. They will be offended by the word just because they were taught it is a bad word. Of course, it's also connected to the more recent usage of the same word as a slur and it can hurt in that way. But that use of the word as a slur is also just because people have been taught it's a bad word. Once again, I don't mean to deny the hurt that this word causes, no matter whether it is because of it being a bad word or because it's because there are people that do experience a connection between the word and slavery. I'm not even trying to say it's not a bad word either.

However, there is this strange other side to this word, where it is accepted if a black person says it. I would understand this if it was about intention and sometimes a bit of it is about intention. However, the word is also considered racist if it is used by a white person without intending to insult. If anything, the fact that white people cannot use the word while black people can sounds like racism to me. Of course, as a privileged white male, I don't have much to complain about. I'm really just trying to get to the issue what discrimination and racism are. To me, it really just seems that the word isn't inherently racist.

If it's just about intention, though, things get very hairy. Take the example from the traffic light situation above. My intention was to take a verbal stab at this person without it relating to where he - or his parents - were from. However, he wouldn't have been able to tell that. If there was a third traffic light he had to take and he did the same thing there and someone else made the same comment to him there, but this time with the intention to hurt him based on his race it would have sounded exactly the same. Moreover, it would have felt exactly the same to that person.

What about racist jokes? A racist joke really just evokes a stereotype for the sake of comedy. However, racist jokes are considered a bad thing. They may very well hurt people. However, jokes about dead babies are considered much more acceptable. Not everyone likes these, but they don't carry the same stigma. That's while such a joke can hurt very much to someone who has lost a baby.

Let's take the combination of racism and comedy a bit further. Let's talk about such things in the context of entertainment. The satire of shows like South Park spring to mind immediately. They had a whole thing about gingers not having souls. Basically, their characters were discriminating other characters. It sounds strange to me to call a piece that has fictional characters discriminating other fictional characters as being discrimination itself. However, when episodes on this theme aired, the number of children with red hair being bullied skyrocketed.

Maybe we can shine a different light on this. Imagine you are making a period piece. A movie, let's make it a movie. It's set mid-1900s. Women were discriminated against in that period. Should you not show that in your movie? Is being authentic in that respect discrimination all by itself? Of course there is room for a movie showing those troubles, but say you just wanted to make a police drama set somewhere in that time period. Does that mean you can't show a man being a pig towards the typist woman?

If anything becomes clear to me through all of this, it's that discrimination is not the same as "shouldn't do". Of course you shouldn't discriminate. That's something that's so important that many countries (at least the ones in the West) ingrained this in their constitution. However, there are things that you shouldn't do, but not because they are discrimination. In the extreme, hate-mongering is often not discrimination in itself, but it does move others to discriminate and it should be clear that it's not acceptable behavior.

In my opinion you shouldn't ask yourself if what you're saying is discrimination. It should be clear when it is discrimination and you should know to stay well away from that. However, I do think it's good to ask yourself whether what you're doing is offensive to people. It doesn't even necessarily have to do with something you can discriminate about. Likewise, it's good to ask yourself if what you're doing may validate people hurting others, through discrimination or something else. I'm not against free speech, but I would like those practicing free speech to take their responsibility.

Today, I really just took a look at what I think isn't discrimination. In the next part, I will take a look at what I think is discrimination. I hope you'll join me for that part as well.

MinGW? MinGW-w64? Msys? MSYS2?

I've got a more serious blog post in the pipelines. However, right now, I just want to take a moment and complain about a mess I came across.

So, it's been a while since I have last programmed in C or C++. In fact, I have never done any real C programming and it's been over half a decade since I was serious about a C++ project. I have recently done some Arduino work, but there you don't really have to worry about the compiler yourself, so it's not relevant here. And because the compiler is what I am talking about here, so C++ and C can be thrown on the same pile, as I use the GNU Compiler Collection (gcc) for both.

Man, the gcc for windows situation is a mess...

So, there has always been MinGW and Cygwin. Cygwin is a whole POSIX emulation stack. Programs had to be compiled specifically for running in the Cygwin environment, but it was easy to do this for any linux program. Such programs would always need at least the Cygwin compatibility layer dll to run. Many people also just use Cygwin for a linux-like environment (since the GNU tools provide what many people consider "linux-likeness") on Windows without using the compiler. I've always used some version of msys for this, but I'll get to what that is in a moment.

The other option was MinGW. Rather than a full compatibility layer, it just aims to provide a compiler that can compile things natively for Windows. You will need to talk to the Windows APIs just like you would when using a different c----ompiler like Visual C++. It's just a way to get gcc to compile for Windows.

However, MinGW was married to MSYS. MSYS was forked from Cygwin at some point, but it did away with its compatibility layer. Instead, it used MinGW to compile some of the core GNU utils for native windows. This also gives you sort of a linux-like system on Windows. This was necessary to run mingw and meant that msys was a part of the mingw project. However, you could also use mingw to cross-compile from linux to windows, in which case you didn't need msys.

Unfortunately, mingw only supported 32 bit applications. When I say around the time when this started being an issue, I mean during the days of Windows XP x64 and Windows Vista and 7, which had had 32 bit and 64 bit versions which were both used (yes, a lot has changed since then). So around that time, there was a company that developed a mingw version for 64 bit application in house. At some point, it donated this code to open source and it was tried to merge it with the mingw project. However, this project suspected there were some licensing issues and a rift occurred. A second project started, called mingw-w64. It also had its own msys version (I think) and if I remember correctly it could actually compile for 32 bit and 64 bit applications.

During this time, mingw had a bit of an installer problem. The person who had been maintaining the installer left the project and basically nobody wanted to work with the same installer building tool. This led to the installer version they provided to be horribly out of date. You had to mess around with packages to get a more recent version. They were rather hostile to help offered by volunteers from outside the project, demanding that such help would be maintained by the same person indefinitely. There was some work on a new system inspired by the apt-get interface, but there was no temporary solution in the mean time. This system got done eventually, but by then the project had suffered greatly already.

Enter git. Git is not a compiler. However, it relies on GNU tools to do its job, so it needed some of them to be able to run on Windows. So, they created their own version of msys (msysgit) which makes them relevant to this story. At some point I switched from mingw's msys to msysgit for my "proper command line" needs and since then I haven't really kept up with the mingw project.

That is, until now. I want to make a utility that uses I2C on linux and my best bet seems to be C. So, I went to look for a compiler. What I really need is a cross-compiler from Windows to ARM linux, or perhaps an ARM compiler on the device itself or maybe even a cross-compiler from x64 linux to ARM linux to run from a (virtual or other) linux installation, but I ended up looking at mingw first. I had a very old version installed as part of the haskell project (oh joy!) and a slightly more recent version from my C++ development days. So, I started looking into the mingw situation.

The mingw project seems to have bled to death. Their site is still online, but nothing seems to have happened for them in over three years. In a way, this is logical. They were already struggling in those days and today you don't really have to bother with 32 bit applications anymore as 64 bit is commonplace enough. mingw-w64 is still alive and kicking and it seams to be the way to go. However, there's also msys2.

The project page describes them as a rewrite of msys and they mention the reason for their existence is the fact that the original msys wasn't able to keep up with Cygwin. However, what I think is one of their main accomplishments is that they divorced from mingw. Don't get me wrong, they are still seeing each other, just not living together anymore. The tools are still built with a mingw version (I think the w64 version) and it is still an important way to run mingw, providing support for both (the outdated) mingw and mingw-w64 out of the box. However, they are just not the same project anymore, so the coupling is not as tight anymore (i.e. they are not wearing rings and they are allowed to see other people).

The new msys2 also does away with the apt-get inspired installer in favor of a new port of Arch's package manager, pacman. Oh, and they apparently don't play well with msysgit or the original msys. Things never get simple, do they.

Confused yet? I definitely am!

Edit: It seems there still was an important bit I missed. The more recent version of git for windows (incidentally, called Git for Windows rather than msysgit as the older versions were called) don't actually use their own msysgit anymore. Instead, they are already packaging msys2, which means that I have already been using it for quite some time...