Thursday, July 1, 2021

The Impending Doom of Your Operating System Going to or Past 11, Versus the Lush Oasis of Open Source Systems

Will the uncertainty over forced obsolescence of fairly recent hardware force Microsoft and Apple users to switch to open source alternatives?

During the last few weeks several items of computing hardware in our household had reached the point in their lifetime when it made sense to trade in for upgrades. published a Norwegian version of this articleEn skummel fremtid med operativ­system som går til 11 eller forbi, eller en rolig oase med fri programvare?

I've written articles about my last two major laptop upgrades and each time detailed (in 2010 and 2017, respectively) how to deal with hardware that was new enough that I had no way to be certain it would work optimally with my chosen operating system, OpenBSD

I have tended to jump from snapshot to snapshot, generally following whatever was -current on OpenBSD/amd64. There were other upgrades during that time, but those were straightforward enough that I did not see a need to write about them.

This time around, even though the process involved interactions with OpenBSD developers via the bugs@ mailing list and even trying two separate models from the same manufacturer before settling on what I wanted, I considered just letting this upgrade round just pass relatively undocumented. There was simply not enough drama involved in the process to make for interesting reading or an inspired writing process. 

But then came the announcements from Apple and Microsoft of their operating systems going past 11 or to 11 respectively, spaced not too many weeks apart. In both cases, the announcements indicated that the new operating system versions would not work with older hardware.

At their WWDC event in early June 2021, Apple announced new versions of their system with somewhat vague but only thinly veiled formulations that specific new features of the upcoming system would only be available on the newer ARM architecture "Apple silicon" hardware.

Then a few weeks later into June 2021, Microsoft announced their Windows 11, and the announcement included some fairly confusing statements that seemed to indicate at first that Windows 11 would only work well or at all on hardware based on Intel's 8th generation Core processors or equivalent.

Apple is almost a year into their announced two year transition from Intel-supplied processors, with a base architecture generally known as AMD64, to their own Apple-designed ARM64-based system on a chip cores. Apple has generally kept some level of support for Macs for seven years after release, and with a transition to a new architecture underway, it becomes even less surprising that support for older devices will gradually erode and that some new system features will only be available on newer model hardware.

This contrasts sharply with Microsoft's situation, with the company not really dependent on hardware sales and not with any announced or unannounced but apparent move to a different architecture. Whatever the reason for the cutback in support, the initial response from the public seemed to indicate that there now was a real fear that on installing the new software, upgrading Windows users would be faced with something like

(which is in fact an OpenBSD panic) unless they upgrade to newer hardware before trying the new software release.

The fear of abandonment seemed real and echoed the feelings I have had myself over the years when getting new hardware to run a free operating system on.

The previous articles chronicle some of the experimenting that was needed in the past to make OpenBSD work when the hardware was newer than what yet had time to reach the developers. But in the end we could always be quite certain that we could make what we were interested in work, given time and perhaps some interaction with developers, or if you were up to it, becoming a developer yourself.

Anyway, over time the chance that things would just work increased, and your sweet spot for some time was buying hardware that was released within the last couple of years before the operating system release you were installing.

Hardware drivers would generally be kept in and maintained as long as they appeared to be useful. In general a driver would only be retired from the tree if it was useful only to an architecture that was going out of support such as OpenBSD/vax which went to the attic after the OpenBSD 5.9 release in 2016.

The major lesson here is that the free systems like OpenBSD, Linux or others would keep hardware support around as long as it appears to be useful to somebody, somewhere. 

If major players like Microsoft choose to simply abandon users who do not have the latest hardware to stagnation plus only security updates, moving to a free software alternative may very well be a viable option for users who are not willing to abandon not very outdated hardware as long as their typical use case allows.

In my own experience, with hardware that has been on the market for about a year or possibly more you will encounter few to no problems making things work. My most recent Linux experience on laptops is with 9th and 11th generation Intel Core hardware, both of which will serve you well, including multimedia setups, excluding only those that explicitly tell you that you are on your own (Netflix being a case in point).

Now for an incrementally geekier part. If you are not that interested in OpenBSD, please feel free to skip.

But if you were waiting for the promised OpenBSD on newer hardware runthrough, you will get the fuller picture by reading the following and by looking up the details in the mailing list archives via the links and links in those messages.

The thread AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install - how to debug chronicles the interactions from "machine installs but does not survive first boot" through finding that the machine's BIOS announced but did not actually implement some features, and the subsequent changes that went in to the mainstream OpenBSD kernel, if I remember correctly just in time to be included in OpenBSD 6.9.

However, as can be seen in ASUS ZenBook X freezes, there were problems in the DRM/xorg area that would prove too hard to debug. Do read the whole thread, it contains useful debug info for when you get into a similar situation yourself.

Returning that system to the shop for a refund while I was still fiddling with the finer points of the next system was an interesting experience in itself.

I tried to restore the system to its pre-OpenBSD state before returning it, but as it turns out the Windows 10 install image Microsoft supplies will not be able to complete an install by itself.

Rather, it will prompt you for hardware driver you are supposed to have to hand for this system.

As a result of this, the machine still had OpenBSD installed -- with my user and home directory removed and only root as an active user -- when I handed the machine in for the refund, and it was immediately clear that the support techs had never seen anything more Unixy than macOS before. Fortunately this only lead to a short delay in the issuing the refund (but I now have a 1 year PC and Mac Support contract which I do not know that I actually need).

Anyway, I had already discovered an offer for a slightly more expensive model with better features, so ordered and took delivery of the machine described in ASUS ZenBook S: SSD unrecognized, possible new iwx variant, which chronicles the relatively light debugging needed to get the system in shape.

In short, after receiving the package with the new machine late in the afternoon, I spent a few hours trying to work around a few items that lead to rather puzzling failures at first, but fortunately they were all relatively easy to fix with a little help from OpenBSD developers who read the bugs@ list.

The first hurdle was that the system apparently did not recognize the built in SSD. This turned out to a matter of finding the BIOS option for turning off RAID controller functionality, which anyway does not make a whole lot of sense in a system where it is physically impossible to fit more than one storage device on a permanent basis.

The option turned out to live in the BIOS' Advanced menu, labeled VMD setup menu, where you set the Enable VMD controller option to Disabled. Once that is done, the SSD shows up as a regular NVMe device:

nvme0 at pci3 dev 0 function 0 "Intel NVMe" rev 0x03: msix, NVMe 1.3
nvme0: INTEL SSDPEKNW010T8, firmware 004C, serial BTNH03460GYE1P0B
scsibus1 at nvme0: 2 targets, initiator 0
sd0 at scsibus1 targ 1 lun 0: <NVMe, INTEL SSDPEKNW01, 004C>
sd0: 976762MB, 512 bytes/sector, 2000409264 sectors

This made it possible to install on the internal SSD proper, and the next issue was that this 11th generation Intel Core system needed a newer revision (version 5.10) of the Linux-derived DRM code. At the time (and still at the time of writing) Jonathan Gray maintained an as-not-yet-committed branch of the OpenBSD kernel with the code I needed in. The reason this DRM code version was not committed to the main tree was that the newer code caused some regressions on older hardware.

On my system, it looked like the stock kernel would panic when loading the iwx(4) driver, but booting the test kernel Jonathan supplied cured that problem, and I have been running once a week checkouts of the drm510 kernel on top of sysupgraded snapshots since.

However, even with the iwx(4) driver now loading, the wireless network device did not work. 

Running doas fw_update -v revealed that several of the relevant firmware files had been corrupted, and after doas fw_update -d iwx and re-installing (doas fw_update iwx), doas /etc/netstart iwx0 worked as expected and with excellent performance.

In the meantime it had turned out that not only was the audio parts of the system in fact supported (it only needed a one line patch to enable it), only minor manipulation to configuration files would make the audio output signal switch correctly between the internal speaker and my headphones, and that for video conferencing a low cost full duplex USB headset was the better choice.

So now I have a gorgeous, lightweight 13.9 inch laptop running OpenBSD with Xorg running with a 3300x2200 pixel resolution and everything I care about working. With a little attention to proper testing, we have reason to believe that all of this will be properly supported without regression for older hardware versions in the upcoming OpenBSD 7.0 release.

As I had hinted earlier, you may very well find yourself better served and supported by the open source operating system of your choice and its developers and users than you can reasonably expect from the commercial, proprietary options.

If you have questions about anything in this article, OpenBSD or other free systems, please let me know in comments here, seek out a local-to-you user group (the ones I am most involved in are NUUG, the national Norwegian Unix User Group, and BLUG, the Bergen (BSD and) Linux User Group), or drop me an email. If you choose the last option, please read my read me first document before sending a second message.

Update 2021-07-07: As reported in the following tweet, the DRM 5.10 update is now in, and I can go back to quiet sysupgrade(8) from snapshot to snapshot:

Which also means OpenBSD 7.0 will seriously rock on this and similar machines.

Saturday, May 15, 2021

Are you aware what you lose by just clicking OK to get started using something?

The right to privacy, the right to repair and the right to choose your tools for tasks at hand are aspects of the same. A new court ruling in Italy could help us regain righs that we were manipulated into giving up.

It's likely you do not spend much time thinking about the fact that if you are an ordinary IT user in an industrialized country, you have most likely have been tricked into giving up rights. This happens on a scale that should be worrying to anyone concerned about human rights in general.

Consider the situation when you want to start using something you are interested in, either a computer of some sort such as a PC, tablet or phone, or a network based service.

First, look at what happens when you get get your new computer, tablet or telephone and start unboxing. One of the very first things after you have powered the device on, and certainly before you get any opportunity to use the thing for whatever you want to do, is that you are required to accept a legally binding agreement that has been designed by and for those who manufactured the equipment. In order to be able to use the thing you bought, you are required to accept an agreement that governs what you are able to do with the device.

With some devices you will be presented with several separate agreements, each with its own registration of whether you accept the terms or not.

Some of the agreements set limits on what you can use the device for, while others grant the supplier or cooperating parties permission to collect information about you and what you do with the device.

Most of those yes/no style questions will give the impression that you have a real choice to not agree to the terms, but you will find that you probably will not go on to getting a device that is in fact usable for the intended use until you have agreed to the terms of all of the agreements.

One of the more visible consequences of the COVID 19 crisis is that a larger subset of us were forced into an almost totally digital existence, where communication for work and school happens via digital devices and via services that are provided according to terms dictated by the service providers. Some of us have led a mostly digital existence for years already, but for a large chunk of the population this is a totally new set of circumstances and it is slowly dawning on an increasing number of people that important freedoms and rights may be on a path towards extinction.

This is not a new set of problems. Among IT professionals, many of us have for years been warning that crucial human rights or civil rights are being slowly worn away, largely to the benefit of a few corporations and their owners.

When you turn on a new computer or phone for the first time, most likely you will be asked right away to accept an "end user license" for the operating system, that is, the software that controls the device. In its simplest form, a license is a document that specifies the terms that govern granting other someone other than a work's author (here the software developers) permission to produce copies of the work. 

However, in many cases the license document contains far more wide reaching terms and permissions. We often see that the license agreement grants you a right to not accept the terms for using the operating system and delete or return any copies delivered with the device and get a refund, but you retain the right to use the physical device. 

Some of us have bought PCs or other devices and managed to install an operating system that was not supplied with the device, choosing to live our digital lives using free alternatives such as Linux or OpenBSD. Some of us do this in order to gain more direct control of the tools we use.

If we have tried to get a refund for an unused operating system license, most of us have not been sucessful. But we will return to that matter shortly.

If you have successfully installed a free alternative to the operating system that came with your device, you have contributed to strengthening the right to choose your tools, the right to repair and to make your own decisions about your possessions. But unfortunately this is not the only part of your digital life where your rights are in grave danger.

Regardless of whether you accepted the end user license earlier or not, you will soon encounter software or network based services that present end user agreements of their own. There is a considerable chance that you will just click OK without reading the conditions of that agreement.

Please take a break from reading this and go check what conditions you have actually agreed to. More likely than not, you will find that both operating system suppliers and social media services have had you give them permission to record what you do when you use the system or the service. For good measure, please take the time to check the conditions for all products and services you have registered for. Most likely not just one, but a large majority of the services and products you use on a network connected device have granted themselves the right to record and store data on your behavior. If you use the device to anything privacy relevant or involving sensitive information it is well worth checking how consequences those agreements bear ouut for your right to privacy.

On paper (yes, I'm sounding old fashioned on purpose) residents of the EU and EEA attached countries have a right to get a copy of data stored about us and if needed get any errors corrected or even have data deleted accordign to the EU General Data Protection Regulation, known as the GDPR. I

f you found something while checking the agreements on your break from reading this feels concerning or makes you unsure, you would to well to exercise your right to viewing, copying, correction or deletion. If you do not get any meaningful response, your best path of action is to contact the local-to-you Data Protection Authority (in Norway, that is Datatilsynet) or the local-to-you Consumer Protection Agency (again in Norway we have Forbrukertilsynet), both should be able and willing to offer assistance.

But what then, of the right to repair or the right to choose one's own tools? The good news is that there is reason to hope. After a complex and long winded process an Italian court recently decided not only did a Linux enthusiast have the right to install Linux on a new Lenovo computer, the customer also had the right to get the price of the unused operating system refunded. Unfortunately Lenovo had attempted to not live up to their obligations as specified by the end user license presented to the customer, and they were fined the amount of 20,000 Euros.

A decision of this category is apparently not automatically a binding legal precedent in other European countries, and we are aware of decisions in other countries that did not grant the customer the right to treat a computer and its operating system as separate items. As the Norwegian association of Unix and free software users (Norwegian Unix User Group - NUUG) we are now entering in a cooperative effort coordinated by the Free Software Foundation Europe (FSFE) to protect and defend your right and mine to privacy, the right to repair and the right to choose the tools we use to manage our digital existence.

If any of the things you just read makes you concerned, confused, angry or just eager to help strengthen our civil rights and human rights in the digital domain, we will be very happy to hear from you.

Peter N. M. Hansteen
Board Chair of the Norwegian Unix User Group (NUUG)

The Italian court decision that offers some hope is described in some detail on the FSFEs web: Refund of pre-installed Windows: Lenovo must pay 20,000 euros in damages

This article originally appeared 2021-05-15 in Norwegian on NUUG's news web "2021-05-15 - Vet du hva du mister når du bare klikker OK for å komme i gang med å bruke noe?"

Monday, February 22, 2021

RFC7505 Means Yes, Your Domain Can Refuse to Handle Mail. Please Leave Us a TXT If You Do.

If you do not want a domain to receive any mail, there is a way to be at last somewhat civil about it. There's a different DNS trick for that.

It used to be that if you went to the trouble of registering a domain, one of the duties that came with it was set up somewhere to receive mail.

A number of networking professionals, myself included, have been know to insist that not only should a valid domain receive mail, at least a significant subset of the identities listed in RFC2142 (dated May 1997) should exist and mail sent there should be read at some reasonable interval.

Then of course we all know that a number of things happened in networking in the years between 1997 and today.

As regular or returning readers of this column will be aware, one of the phenomena that rose to become a prominent irritation and possible risk factor was spam, otherwise known as unsolicited commercial email, and of course some of the unsolicited traffic carried payloads that were part of various kinds of criminal activity.

I have written fairly extensively on how to suppress spam and other malicious traffic and have fun doing so, all the while assuming that if you run a domain you will want at least some mail to have a chance of making it to an inbox that is actually read by a person or perhaps processed by your robotic underlings.

Then there is that other consideration that with the proliferation of top level domains means that organizations that own trademarks and would in the early days see the need only for .com or .net domain (the latter was in fact originally intended for organizations involved in networking) or perhaps a country domain such as a .no or .se one would tend to hoard domains in other top level domains too.

There are of course those who try to exploit trademark protection too, as we have seen in among other things my brush with a certain Chinese registrar or that time when what could only be seen as an extortion attempt a little too forcefully telemarketed landed me an otherwise white-elephant .se domain.

Now with the combination of potentially for most practical purposes redundant domains and the likely burden of handling spam for the same, it is understandable that attitudes started to shift. Finally in June 2015 RFC7505 was issued, with a simple and practical solution, dubbed the NULL MX record. The RFC explains how to set one up, though in language that is not too easy to penetrate.

For any domain that runs a mail service, there should be at least one MX record. Looking up, say, with dig mx yields a response where the answer section gives

;; ANSWER SECTION: 300 IN MX 1 300 IN MX 5

In your zone file, you would probably have similar lines, likely with only the MX <priority> hostname part on the actual line, the rest taken care of by the zone file it's all wrapped in.

If you want to make your domain an RFC7505-adherent one, you would remove your current MX records and replace with

MX 0 .

I did that for my little white elephant domain last week, since I did not by then remember when I last received anything sensible via that domain. 

So if you run dig mx now, it will yield


Which means nobody will ever see mail you attempt to send to The delivery will fail immediately and produce a bounce message that likely references the RFC if your mailer is a reasonably recent version.

But while I was doing the change it struck me that it would be useful to let the world know why I did not want that domain to handle mail. Fortunately there is already an appropriate DNS record type for the purpose: the TXT record.

TXT records are used for some specific purposes such as the SPF records used to list allowed outoing SMTP senders for the domain, and a few other variants tied to specific services. But fundamentally a TXT record is simply a string of characters most applications will not actually attempt to handle. This means you have the option of fitting a message on your own in one. Now, if you do a lookup on that white elephant domain's TXT records, you will get

;; ANSWER SECTION: 300 IN TXT "v=spf1 -all" 300 IN TXT "This exists only because happened." 300 IN TXT "For actual contact info please check the corresponding net domain."

Note the first TXT record here, which carries the domain's SPF specification that had been in place for a while already. It says essentially in terse if eloquent SPF speak, "This domain does not send mail".

So wrapping up, with these simple changes, quick to implement if you are in a position to edit your DNS zones we achieved:

  • Ridding ourselves of an entry point that produced only annoyances
  • Letting the world know (or at least the subset that knows how to operate common DNS tools) what the status of the mail service is and why, plus a small hint on how to make contact in case that is actually required.
A little DNS will sometimes go a long way.

A big Thank You to Security Evangelist Per Thorsheim (yes, that is his actual title) who brought RFC7505 to my attention again with this somewhat shorter blog post in Norwegian (also in English here).

Update 2021-02-23: After gentle prodding in this tweet (via JP Mens)
-- also preserved as a screenshot - 

I added a dmarc record for the domain too (kind of overkill, but can't hurt I suppose).