The Geek and the pseudo inclusive peer pressure

Discrimination based on social skills and social groups exists and geeks experience it a lot.

One facet of it is the pseudo inclusive peer pressure.

The desire to belong to a group is strong in anyone so people would accept many things just to fit in.

At the same time, a few understand this game quite well, can get meta about it and specifically target geeks to mock them by appearing to be inclusive.

Nothing causes more pleasure to such dark 'master minds' than tricking a geek into ridiculing itself!

Not only for the ridicule but for the mere fact that the geek believed they would thus become part of the in-group: this was never on the table! They will never be part of the in-group!

After a few such experiences some geeks develop a good sense for this situation.

There is no surprise then that some react quite hard in the grown up world. Their senses are screaming: it's a trap!

But the master minds are also grown ups now, and they want small things, all in the name of being inclusive.

Open Source sustainability is not about the individual

There was a lot of buzz a while back about Open Source sustainability. Small and large companies as well as individuals discovered it's near impossible to survive financially doing Open Source.

It occurred to me that this might be an emergent property of Open Source and a reason why many foundations (like Apache) as well as users intuitively look at the "community" first.

The community is like a swarm, a Redundant Array of Individual Contributors (RAIC) that carries on regardless if a particular individual drops out. So, a "good" Open Source project is one where the community achieved this chain reaction while the others are at a stage where individual contributors make or break the project.

This conclusion is quite ruthless about a specific company or individual though: the better your Open Source project is, the more precarious your position.

The role of BDFL (Benevolent dictator for life) might be the only one guaranteeing some stability for an individual, but this means the swarm can only sustain one queen (I mean, dictator). Conceptually this role might be required to provide some coherence to the swarm.

Instant Thought: another open source supply chain attack

It seems not a day goes by without another open source supply chain attack.

The latest, uncovered by the security researcher "JK" is called "Instant Thought" and was noticed in the most popular Java IDE, combined the the very popular build system Gradle.

One might assume that just opening a Gradle project to read the source code is a safe operation, but Instant Thought shows this is not the case.

Gradle projects might have an unassuming settings.gradle file with a tiny block which gets executed by the IDE as soon as the project is loaded.

Root cause analysis showed the problem is the gradle.projectsLoaded hook which is able to run code with the full permissions of the user account:

gradle.projectsLoaded { g ->
  // do bad things
}

"This is not unlike the Word macro viruses seen in late '90s" said another analyst. "Which just shows how behind the times the IDEs are with security".

It is not clear how widespread Instant Thought is but suffice to say developers have to think long and hard before executing or even opening unknown projects.

According to the vendor, this is a low priority issue: "[Our IDE] automatically configures the project during the import (which is quite similar to executing gradle command) and it causes the code execution. The current behaviour seems not to be a high severity security problem thus it won't be fixed in the near future."

Roam Like at Home is a regression for Romania

On June 15th 2017 the EU launched "Roam Like at Home", a set of rules that removed roaming charges. It was a great idea to harmonise telecom infrastructure and remove another invisible border separating people within the EU.

Romania was hit particularly bad by these rules. They introduced new borders where before there were none.

Previously, roaming was available to any telecom user either on a subscription plan or on a pre-paid card in Romania. The only limitation was that, rarely, the operator might ask for a warranty (say, 100 euro) so you don't rack up too many fees while abroad.

Internet and mobile services are particularly cheap in Romania and fast. We used to be ranked on the 5th place world wide based on internet speed alone.

So, by having such cheap prices a problem for Romanian telecom operators was that this might encourage abuse from Romanians going abroad and downloading too much, or by other EU people buying Romanian SIM cards to use instead of their expensive national SIM cards.

In order to contain this potential problem the EU was flexible with the "Roam Like at Home" rules and allowed a "fair use policy".

But the biggest blow was that the EU allowed contracts without roaming services. Guess what all Romanian telecom operators started rolling out immediately? They removed roaming from all the subscription plans under a price they considered acceptable!

A reasonable, entry-level, subscription plan that would have had roaming before 2017 suddenly became useless when crossing the border.

Note that without roaming nothing works! You have no data but no calls or SMS either. You are stranded with a non-functioning telephone in another EU country. This was an "interesting" experience for Romanian tourists early 2018. All they could call is 112.

Getting roaming temporarily on a subscription plan is just not possible anymore. Either you upgrade the whole plan to a more expensive one, forever, or you have no phone abroad.

A pre-paid card has more advantages. You can activate a more expensive roaming plan at any time, but you are still penalised by losing all the benefits you had until then, regardless how much the 'national' plan costed or how much you used from it.

In conclusion Roam like at Home reduced the quality of the telecom offer in Romania and introduced a quite visible border separating Romanians from the rest of the EU. One cannot imagine under what scenario the concept of 'roaming services' for SIM cards sold within the EU to EU citizens should even exist.

Another change that this measure did introduce in Romania is a bigger churn on SIM cards and operators. If Romanians manage to separate their identity from the SIM number and the operator is just a dumb carrier then it will not have been all for nothing.

Tarkovsky street art

Source.

Wayback Machine Downloader

Internet Archive's Wayback Machine is a gift to the world. For quick checks you just enter the URL and you get the archived version going years back.

A whole little cottage industry seems to have been formed around the Wayback Machine. They offer you whole-site download and conversions for the low price of $5 or $15 or $45 or however much they can convince you their service is worth.

Among these busy bees, the free Ruby based Wayback Machine Downloader is a little gem.

You just install it then run

wayback_machine_downloader -c 10 -s http://www.example.com

and you get everything! Total cost: $0.

Installing the actual gem on macOS as a non-admin user seems to have contradicting info online. There's a `gem install --local` command but it doesn't seem to do what one expects -- installing in the home folder of the current user.

What did the trick for me was:

gem install -i ~/.gem/ruby/2.3.0/ wayback_machine_downloader

and this after I manually downloaded the proper .gem file from rubygems.org

Some were even recommending to add a http (versus the default https) source to gem but that seemed foolish and even gem itself complained about using http in 2019.

Whatever road you pick with downloading from Wayback Machine, remember all the work the Internet Archive is doing for all this to be available to you and donate to them.

Fair Source and the Fair Source Initiative

There's been some uproar about the MongoDB Server Side Public License which tries to prevent cloud vendors like Amazon take all the money in the MongoDB market.

Many are pointing out that this new license does not respect the Open Source Definition published by the Open Source Initiative.

In truth many users and companies would find the license acceptable. A legal advisor will clear the license, the software will be used and nobody except a vendor in a similar position like Amazon will care.

What this move towards a financially sustainable open source ecosystem needs is branding.

I suggest calling this new type of open source "fair source". Most people and companies understand that some money is necessary to keep a project alive and would find it palatable that the once you are big enough to disrupt the market for the author you should pay.

In order to help smaller companies that do not have a legal advisor at hand, a Fair Source Initiative foundation should be created. This foundation would review such fair source licenses and define them as acceptable or not.

In many ways in the same way as "open source" was introduced to make free software more acceptable to businesses, "fair source" will be about making an open source business model more sustainable.

Open Source was about dethroning the Free Software Foundation. Fair Source must dethrone the Open Source Initiative.

Perhaps the Open Source Initiative board will realize this and redefine the way they classify licenses. Otherwise they will find themselves irrelevant for a buzzing section of the software world.

Apache NetBeans interview

As Apache NetBeans became a top level Apache project and finished the incubation process I was asked for an interview and my photo.

Only a single quote was taken from the interview and used on a not too positive article about NetBeans. The quote was presented as coming from me as a member of the 'Project Management Committee' to give it even more weight.

Bellow is my full interview for historical reference:

> Do you think Apache is the best place for NetBeans?

Churchill said that 'democracy is the worst form of Government except for all those other forms that have been tried from time to time'.

In the current context, there is no better place.

Maybe in some alternate universe Sun Microsystems didn't spend a full $1 billion on MySQL but took a chunk of that to create a NetBeans Foundation that rivals the Eclipse Foundation... but I'm not entirely certain it would have been better for the project.
 
> What kind of future do you anticipate for NetBeans under Apache?

This depends on how Apache and the other Apache projects value NetBeans. There is a lot of integration that would help both the projects and the end users.

The ASF is a large Java house now so having a programming language (Groovy), an IDE (NetBeans), build systems (Ant, Maven) and application runtimes (Tomcat, TomEE) means you can do some interesting things in sync.

If you think about it, the IDE is the last major piece of the puzzle missing from Apache. So now, you can push a new feature all the way to developers using the IDE really easy.

Imagine you want to introduce, say, reproducible builds to the Java developer world. Well, you change the build systems, have the runtimes also reproducible then push this to the default project types in the IDE and suddenly all new Java projects created by developers using the IDE are reproducible. You can really change and educate the world really fast.

And education is not to be understated. An IDE suggestion that the developer sees *while editing code* is educational. Want people to use libraries better? A blog post might help, but people have to find it and read it. But if a suggestion about how to use the library better is part of NetBeans, all developers will see it!

It's not clear to me yet if the ASF takes such a holistic approach, but there's a big opportunity here. Everything fits.
 
> What will your project management committee do to advance NetBeans?

This is a hard question for me since I'm not the 'manager' of NetBeans. Nobody is. The whole point under Apache is to participate as individuals, regardless of the employer (that might sometimes be sponsoring said involvement).

So, I don't necessarily see hard targets like under a strictly hierarchical corporation.

Changes happens somewhat chaotically but towards betterment. Many people submit specific bug fixes for their particular problems while other work on more big picture changes (like a new Java version being supported, etc).

On the Java front we have a lot of community members that work on it, a few of them full time as part of their job at Oracle. On PHP we also have some folks, particularly Jun-ichi Yamamoto from Japan. JavaEE is also quite popular. We had people add support for JUnit 5, etc.

Basically the community will self-organize to overcome obstacles. We had somebody fix a really hard bug in the Java profiler. I would have thought that only a handful of core Java developers from Oracle knew how to fix that. But the individual looked into it, worked hard and fixed it! There's a lot of hidden talent like that.
 
> Also, what is the role of the committee?

See https://www.apache.org/foundation/governance/pmcs.html

The PMC decides which new committers get added (which in turn decide how the code is changed) and then votes when a release is to be made as an act of the Apache foundation. We also oversee how the NetBeans trademark is used and basically take care of the NetBeans project and brand as a whole.

> Thank you very much!

No problem. BTW, the individual doing the hard Profiler bugfix I mentioned is called Peter Hull.

The Apache Software Foundation is a record label not a rock band

What shocked me most during my involvement with NetBeans, now an Apache Software Foundation project, is that The Apache Software Foundation is a record label not a rock band.

Imagine you like a given band. You go to their concerts regardless of the location, enjoy their music, buy their records, maybe proudly wear a T-shirt. You deeply care about that band and the band cares about the music they make and their fans.

Once your band joins The Apache Record Label things might seem unchanged. The band still makes good music, released obviously exclusively through their new record label.

But something did change: while the band and the fans care about their future, the record label has a lot of bands to look after and only tangentially cares about a particular band. The band is also not doing much better since all their sales go towards the maintenance of the main music venue, lawyers, trademark protection, distribution fees, etc.

The misunderstanding about The Apache Software Foundation must have been caused by the fact that initially the Foundation was about a big and important project: the Apache HTTP Server. At that time I believe the fate of the project was quite important. Nowadays I believe the Foundation could retire the Apache HTTP Server and survive unscathed.

The other misunderstanding is caused by the fact that the technology landscape has some other software foundations like the FreeBSD Foundation, the OpenBSD Foundation, Mozilla Foundation which are all about a single project. These foundations basically live and die by that project.

It's an odd situation. The Apache Software Foundation provides competent support for its projects but has no skin in the game and if a project fails they will eventually acknowledge it in a board meeting and move on.

There's also no way to directly support a project via the Apache Software Foundation. The Foundation does not sponsor any kind of project software development. All the donations go to infrastructure and administrative costs. But projects rarely hurt for infrastructure while targeted development could help them and their users a whole lot.

NetBeans Web Toolkit

I'm exploring NetBeans Web Toolkit with the articles here

NetBeans Web Toolkit is the new name I'm trying to give to Jaroslav Tulach's HTML/Java API, a rather impressive library that deserves more use.

Guards in Java

Haskell functions have this nice concept called 'guards' which allow you to define a condition and return a value when that condition is true.

For example:

abs n
  | n < 0     = -n
  | otherwise =  n

This makes the code rather readable, especially when you have more guards.

Guards build one upon another since you know that if your guard condition is checked, all the other failed:

something n
  | n < -2 = 10
  -- bellow we know that n > =-2
  | n < 0 = 8
  | otherwise = n

Back in Java land, where I get paid, I sometimes wondered if I should write a method as:

X method(Y param) {
  if (!param.isSomething()) {
    return null;
  } else {
    return param.getX();
  }
}

or if I should write it as

X method(Y param) {
  if (!param.isSomething()) {
    return null;
  }

  return param.getX();
}

I generally prefer the 2nd variant and now I realised these are a form of function guards!

The case of the different jsch 0.1.54 binaries

As part of the Apache NetBeans IP clearance we are combing through all the code and dependencies.

One interesting thing we bumped into was that the jsch 0.1.54 binary JAR we are using has a different hash (and size) than the binary JAR from Maven Central.

The old hash is 0D7D8ABA0D11E8CD2F775F47CD3A6CFBF2837DA4, the new one is DA3584329A263616E277E15462B387ADDD1B208D.

The binaries are 278,612 bytes vs 280,515 bytes in Maven Central.

Our version is actually the same as the one found on http://www.jcraft.com/jsch/

Also, the Maven JAR is properly signed with the author's CA7FA1F0 key.

This is where it becomes clear that reproducible builds are important. You do not want to have to wonder why a binary differs, especially years later when you are doing a review. And this one is a library doing SSH!

So, why the different binaries?

It seems the original JAR was compiled on Aug 30, 2016 with Java 1.4 (major version 48) while the Maven Central JAR was compiled Sep 3, 2016 with Java 5 (major version 49).

The original JAR also concatenates strings using StringBuffer while the Maven Central JAR uses the newly introduced in 1.5 StringBuilder. Which should also be a bit faster since it's not synchronized.

Next, most of the cypher classes use some reflection via a static static java.lang.Class class$(java.lang.String) method.

What is this? It's just the way class literals worked in Java 1.4. As explained here, in Java 5 the ldc_w instruction was introduced to load a Class object.

In 1.4 the class literal was helped by the compiler by actually introducing the helper Class class$(java.lang.String className) method and replacing the Person.class with a class$("Person") call.

It conclusion, it seems that excluding the Java 1.4 to Java 5 compiler changes, the two JARs are identical. With the Maven Central JAR even a bit better due to StringBuilder being used.

There is no check so far that the sources do produce the specific JAR. This is an exercise left for the reader.

Note: I have also cross-posted this blog post to the Apache NetBeans blog.

Processing a generic Data.Array matrix

I had an interesting Haskell problem the other week: work on columns and rows of a Data.Array i e.

You only have the Ix i, Ord e class constraints, which make sense because the index must be a Data.Ix. The elements also must be Ord to be able to process them.

The thing about Data.Ix is that it's very opaque. It only extends Ord. There is nothing matrix-related in it. One could use Data.Array for a lot of data structures!

But if you do know it's a matrix, although you have no explicit class constraint, there is a nice trick to use: two neighbouring cells will have a Data.Ix.rangeSize of 2!

So, the rows may be extracted by this little function:

byRows :: Ix i => [i] -> [[i]]
byRows indices = incGroupBy isNeighbour $ indices
    where isNeighbour x y = 2 == rangeSize (x, y)

which is called like

process :: (Ix i, Ord e) => Array i e -> Something
process matrix =

    let rows = byRows $ indices matrix
    ...

Note the unknown incGroupBy which is a groupBy that takes pairs incrementally.

That's it! I had a lot of ideas about using rangeSize to figure out the matrix dimensions, but pairing cells this way was really clean.

Retina work

These past months I have done a NetBeans patch for the Apple Retina Display and also made a small Wiki-like site to help me and anyone else interested with finding matching font icons for the NetBeans icons: https://nextbeans.com/retina

The nextbeans.com stack is Angular, Prime NG, nginx, Jetty, Servlets, Spring Framework JDBC, HSQLDB. SSL via Let's Encrypt.  Hosted at Scaleway.

It's a fun project since I got to learn Angular, find a bug and submit a patch for Prime NG, see how Let's Encrypt does free SSL certificates, learn about the EU cookie warning and all the many tiny things that are needed for a site.

Angular in particular and the whole webdev ecosystem was a lot of new information for me. I was changing project configuration as Angular progressed along! Which reminds me: @angular/cli reached 1.0 and I should probably see if I need to tweak something.

Read on JAXenter a longer article about my work.

Machine learning everywhere!

Samsung announced a while back that they used a "Neural Net based predictor" for their CPU branch prediction.

Shortly after that an Intel person claimed it's no big deal because they have also been using a perceptron for some time.

But to me this seemed a rather big discovery! Previously I would have assumed that branch prediction is a super complex algorithm.

Learning that branch prediction is a basic perceptron reduces Intel's perceived strength.

So companies are openly and covertly using machine learning everywhere.

Machine learning is also a perfect fit for companies because there is no moral filter on a neural network and no chance of whistle blowing.

Volkswagen truly missed a golden opportunity here with their diesel scandal.

They should have just trained a neural network on passing the diesel criteria and then have perfect plausible deniability: "the neural network disabled the pollution filters all by itself!"

Migrating the extra large NetBeans Mercurial repository to Git

Note: This article is a living document and will be updated as I learn new useful information (last update 31st December 2016). I will move the helper scripts to a dedicated repository and copy part of this article into the Apache NetBeans wiki.

Introduction

The NetBeans source code has been stored in a Mercurial repository for almost a decade now.

But starting October 2016 NetBeans is preparing to become an Apache project.

And all incubating projects must store their source code on Apache Software Foundation infrastructure which only provides Subversion or Git hosting.

So, NetBeans must migrate its Mercurial repository to Git.

Size concerns

The NetBeans Mercurial repository covers 17 years of history and has grown to over 3GB.

Apache projects are mirrored on GitHub and they have a limit of 2GB or so. As such, any talk of migration started with ways of reducing the size by potentially splitting up the repository or removing some of the history.

Luckily, it turns out the NetBeans Mercurial server was just using a really old Mercurial version. When Gregory Szorc looked into it we learned that with the format.generaldelta=true and format.aggressivemergedeltas=true flags, the repository drops to about 1GB.

This was great news but, of course, we still have to migrate to Git.

Under Git we have to make sure some compression is applied. This is done with the git gc command which reduces the repository to under 1GB too.

With size out of the way, we can do a straight migration and preserve our mono repository and the whole history.

The case of the corrupted repository

The most important NetBeans repository is releases. This repository holds the release branches such as release82 as well as the current state in the default branch. The main-silver default branch is periodically pushed into the releases/ default branch.

A direct conversion of releases/ is impossible though because the repository is corrupt:

$ hg verify
checking changesets
checking manifests                                                                                                                      

crosschecking files in changesets and manifests                                                                                        

checking files
 applemenu/src/org/netbeans/modules/applemenu/layer.xml@?: rev 12 points to unexpected changeset 149753                                  
 (expected 149755)
 defaults/src/org/netbeans/modules/defaults/Eclipse-keybindings-mac.xml@?: rev 0 points to unexpected changeset 149753                  
 (expected 149755)
 defaults/src/org/netbeans/modules/defaults/Eclipse-keybindings.xml@?: rev 25 points to unexpected changeset 149753                      
 (expected 149755)
 defaults/src/org/netbeans/modules/defaults/mf-layer.xml@?: rev 74 points to unexpected changeset 149753                                
 (expected 149755)
192754 files, 313961 changesets, 1122263 total revisions                                                                                

4 warnings encountered!
4 integrity errors encountered!

Luckily, the corruption seems to be in the default branch.

So, we can get a valid releases/ repository by first making a main-silver clone and then pulling the missing changesets from releases:

mkdir releases.fixed
cd releases.fixed
hg init .
hg pull http://hg.netbeans.org/main-silver
hg pull http://hg.netbeans.org/releases
hg out http://hg.netbeans.org/releases
#nothing should be displayed here
hg verify

hg-fast-export all the way

Now that we have a valid repository we just follow the steps in the official documentation about migrating from Mercurial:

git clone http://repo.or.cz/r/fast-export.git /tmp/fast-export
git init ~/git-releases
cd ~/git-releases
/tmp/fast-export/hg-fast-export.sh -r ~/releases.fixed
git gc --aggressive --prune=now

and then wait 48 hours for it to finish!

.. but first: removing the unnamed heads

Once you do start hg-fast-export.sh you'll notice it fails early with

Error: repository has at least one unnamed head: hg rXXXX

This is caused because Git, unlike Mercurial, does not support unnamed branches.

It's not a big problem for the NetBeans repository because there are very few such commits and basically historical mistakes with no relevance.

I have just removed them altogether with hg strip

Incremental push

Although we have world class internet speed in Romania, I happened to be on a slow connection when the conversion finished. And it is no fun to restart a git push after 400MB have already been uploaded and the connection dropped!

I fixed this by uploading incrementally each month:

echo "Incremental git push"

for year in 2012 2013 2014 2015 2016; do

    for month in 1 2 3 4 5 6 7 8 9 10 11 12; do

SHA=`git rev-list -1 --before="$year-$month-1 12:00" master`

echo "$SHA $year-$month"

  echo git push origin "$SHA:master"

git push origin "$SHA:master"

    done;

done;

Syncing with the old Mercurial repository

Right now the GitHub repositories are just experimental. The real work is still done in the Mercurial repository. As such, I still have to convert the new commits from Mercurial to Git.

hg-fast-export seems designed with this in mind. The -r parameter which specifies the source repository is only needed the 1st time. After that it may be skipped and hg-fast-export will incrementally convert the missing changesets.

So, it's just a matter of:

cd ~/releases.fixed

hg pull

cd ~/git-releases

hg-fast-export.sh

git push

Note that a pull on releases/ will bring back the stripped commits...

Saving hg-fast-export state

I did run into a deadlock while incrementally converting with hg-fast-export.

The only solution seemed to be to redo the conversion.

At 48 hours per full repository this doesn't seem like fun, so I recommend periodically saving these files from the .git folder: hg2git-heads, hg2git-mapping, hg2git-marks and hg2git-state.

Make sure not to ignoreCase

I discovered that on macOS core.ignoreCase is true which means that changesets that only change the case of a file name will produce an incorrect git changeset.

So on macOS the option needs to be explicitly set to false:

git config core.ignorecase false

Minimal NetBSD for Raspberry Pi 2

For no reason other than fiddling with the NetBSD codebase and build system plus the desire to reduce the world bandwidth waste, I've published a minimal NetBSD image for the Raspberry Pi 2 containing only the base set.

You only have to download this 76MB compressed image which becomes under 500MB uncompressed so it fits any recent microSD card you have in your drawer.

I have successfully used such a NetBSD system as a customer proxy of sorts this whole year.

Because lots of times you just need a machine with SSH and a shell.

Of course, my patches are minor, it's not like I managed to fit NetBSD onto a floppy disk but I liked doing it none the less!

NBnotify - Native NetBeans Notifications

NBnotify is back with a vengeance: Windows, macOS and Linux notifications from NetBeans plus the very useful build notifications!

NBnotify started 6 years ago as a way to integrate NetBeans with OSX and to provide me with build notifications.

I have almost always used a MacBook Pro as a work laptop for my customers so it was important that NetBeans is hooked up into the Mac ecosystem.

Back then Growl was the rage, providing customizable notifications for a myriad of Mac applications.

NBnotify entered into a short limbo while I was busy doing NetBeans customizations, Javascript type inference, JDBC drivers, ANTLR parsers and all in all Java code for paying customers...

But as soon as I had some free time this winter I had to bring it up to date!

And not only that -- but I've added first Linux and then Windows support too!

Actually, since NBnotify natively binds to libnotify it should work on BSD systems too.

So, if you are using NetBeans, you have to use NBnotify!

NBnotify is closed source, but only because it was an experiment in the market for NetBeans plugins and productization.

As soon as the NetBeans codebase is donated to Apache and we can start work, I plan on slowly integrating these native notifications into NetBeans proper and open-source the plugin.

NBnotify was always a missing core feature of NetBeans.

NetBSD cross compilation is a marvel

While trying to get a patched variant of NetBSD 7.0.2 to run on my Raspberry Pi 3 I had to build NetBSD many times.

And it was pretty amazing how this all worked.

You have a single entry point: ./build.sh And it does everything! It builds the kernel, the userland apps up to the install image you write on the microSD card.

Of course, having a top-level script that does everything is nothing new, it's basically the second question in the Joel Test.

What is amazing is the cross-compilation.

You have an x64 machine and build.sh will happily create the install image for any supported platform.

The Raspberry Pi image is just:

./build.sh -m evbarm -a earmv7hf -u -U release

then you look into the release dir, find arm7.img.gz and you are ready to go.

I ran the builds on a NetBSD virtual machine, but apparently build.sh will happily run with some small preparation even on Linux or macOS.

NetBSD on Raspberry Pi 3

I have used quite successfully a Raspberry Pi 2 running NetBSD 7 as a customer proxy and I assumed 7.0.2 would run on a Raspberry Pi 3.

As it turns out, the Raspberry Pi 3 ARM Cortex-A53 processor is different enough from the previous Cortex A7 processor we have on the Pi 2 that it needs some kernel changes.

And while the bleeding edge NetBSD current- does work on the Raspberry Pi 3, the stable NetBSD 7.0.2 does not.

I even tried to compile my own NetBSD 7.0.2 and backport the patch that added Pi 3 support, plus up-to-date firmware, but it seems it's not sufficient. There are probably more related commits that need backporting.

So, if you have a Raspberry Pi 3 you can only use current- builds. Go on the nightly build server, grab an .img.gz and test it out!

But if you want a stable NetBSD release, you'll have to wait some more or get a Raspberry Pi 2 instead.

Getting the Raspberry Pi 2 is not such a bad thing because the Raspberry Pi 3 wireless will probably not work for a while anyhow.