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.

Digi.no published a Norwegian version of this article: En 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.

Note: This piece is also available without trackers but classic formatting only here.

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), followed by doas /etc/netstart iwx0 my my 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:

Following this commit https://t.co/Qn8QLQcbmH (the DRM 5.10 update), a simple sysupgrade was all that was needed for the machine from https://t.co/znXV6lRLNn to just work with the latest #OpenBSD snapshot. Thanks again to jsg@ and all #OpenBSD developers!

— Peter N. M. Hansteen (@pitrh) July 7, 2021

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

---

If you found this piece to be useful, informative, annoying or would for some other reason like to contact me or comment, please do.

You might also be interested in reading selected pieces via That Grumpy BSD Guy: A Short Reading List (also here).

---

What have the black boxes wrought

How compartmentalization turned into a security disaster. Greed, incompetence and dishonesty was involved. 

IT security or the lack of any such thing has grabbed headlines lately here in Norway. A series of high profile public institutions have seen large scale worm infections on their Microsoft based networks. 

Late last year the regional government agency responsible for essentially all health care in the western part of the country had a worm infection so bad they essentially shut down their network as a preventive measure. 

During the last few weeks, the national police force, of all thinkable organizations, has seen not one, but two large-scale incidents. Use of Microsoft products and sloppy system maintenance are both pervasive enough that similar incidents are likely happening right now elsewhere, somewhere near you too. 

The news reports about the Norwegian police force's IT problems contained one item that was particularly shocking to IT types like me: 

Apparently large parts of the bureaucracy that is responsible for the confidential and correct processing of criminal matters and all sorts of sensitive personal information associated with the crimes runs essential services on Microsoft Windows NT 4.0. 

That version of the Microsoft product is so old it is officially abandonware, and early reports of the police network problems included the oldish news that even the antiware vendors have stopped supporting the system. 

Later reports had police IT department officials claim that the worm infections were not that much of a security problem, since at this point all the worm actually did was spread. Break out the popcorn, boys and girls: In an upcoming episode, we will see how the worm infected Windows machines the Royal Norwegian Police did not find or couldn't clean well enough are used in the perpetration of some cybercrime or other. 

 It's all pretty sickening, and at this point it would be rather tempting to spend the rest of the column ranting about the general stupidity of Windows users. But a smarter approach is to see if there is a lesson to be learned. 

To do that, we need to backtrack quite a bit and look at the cult of the little black boxes. 

The cult of the little black boxes, and Microsoft the 1980s corporation 

We need to go back and take in what the world was like in the nineteen-eighties. This was back when the world was divided into real computers (from the likes of IBM, Digital, and regional quasi-monopolies like our own Norsk Data) and those annoying toys called 'personal' microcomputers, where the 'IBM PC compatibles' had emerged as the surprise leader of the pack. 

Computer networks were usually private, corporate things and rarely interconnected much, with the rare exception of those institutions that were part of the US Department of Defense science experiment that was becoming known variously as ARPANET or 'the Internet'. 

If you took your programming classes back in the nineteen-eighties, you likely know that we were taught that black boxes were good. 

Compartmentalization was the order of the day, meaning that as a developer you were supposed to create code with a well defined inteface, so anybody interacting with your code would be presented with a cleanly predictable result to any given input. 

Your code should be a black box and for any particular specificiation there could be written several interchangeable modules to fit the bill. 

So far so good, predictability is nice and with compartmentalization comes, we hope at least, clear chains of responsibility. 

But several factors combined to take the cult of the black boxes and turn it into a corporate culture at a corporation that was growing from a handful of furry hackers into a corporation at the time, namely Microsoft. 

Microsoft' early successes all came from writing software for single-user systems that were so limited that working around the limitations of the hardware became much of a lifestyle. 

At the start of the decade, networking on microcomputers in Microsoft's range was pretty much out of the question, and by the end of the eighties any sort of connectivity (even dial-up) was still an expensive optional extra that was still too hard to configure for most people. 

On the storage side, we progressed from 128 kilobyte floppies to hard drives of just over a hundred megabytes for personal systems, with the 32 megabyte partition size still a very present limiting factor.

Amazing developments all, but both the applications and the organization grew faster than the hardware could keep up with. 

The organization now had several levels of management, and each one demanded maximum productivity from their underlings. 

Keeping in mind that each programmer or team would be writing little black boxes anyway, it made perfect sense to set up the software production line so each developer only had access to those parts of the system he or she was supposed to be working on. 

That way developers would be concentrating on their main task and minimize time spent waiting for compiles to finish. At predetermined times the developers would then upload the source code for their little black boxes to a central build system. 

The only people who had all the parts of the projects were in fact the custodians of the build system. 

Source code version control systems were made part of the process, but there is anecdotal evidence that the transition from standalone hacking to a version control regime was a rough one for many early Microsoft developers. 

Only a few days ago I offered pretty much the content of the last few paragraphs to a table of youngish free software developers over beer. 

The reaction was quick an unanimous: 

"That way, nobody really knows what's going on in the software". 

That is a very valid point, and it proves how far we've come with free software. 

At the same time there is every reason to believe that the extreme compartmentalization that Microsoft established for its product development in the 1980s was the way things were done there until very recently, if indeed it has changed at all. 

By the mid-1990s when Microsoft had been dragged kicking and screaming into modern-day network environments, and the ongoing saga of internet-enabled malware started in earnest (I've written a summary in a malware paper -- an updated version is available here), with the company moving from early denial of any bugs whatsoever through a near-constant barrage of emergency hotfixes to today's monthly megapatch regime. 

With the source code still a closely guarded (if occasionally leaked) secret, there is really no way for us to know if they've learned any lessons at all. 

One indication that they still have some way to go is this Infoworld article about the state of their protocol documentation (summary: it's not to be trusted at all). As for the state of the source code, all we can do is to study the flow of urgent patches. 

Much better then to learn how it should be done - Say from Theo de Raadt's AsiaBSDCon 2009 presentation about how OpenBSD's release process works, and if you want more of the gory details, do check his classic exploit mitigation presentation. Also, most likely you could do worse than read Damien Miller's OpenSSH security presentation (full text here). 

It's all those little things we do, at FreeCode and in free software in general. If you found this column useful, entertaining or irritating, please drop me a line.

Does anybody here remember Artie Eff?

© 2008 Peter N. M. Hansteen

That's what you thought you heard, right? Actually, this is not Uncle BSDly's nostalgia for a backstreet hoodlum he might have known way back when. It's Uncle BSDly trying to point out what happened the last time a standard was entrusted to that little Seattle company called Microsoft. R-T-F. The Rich Text format.

So the question is,

Does anybody here remember RTF?

---

Note: This piece is also available without trackers but classic formatting only here.

---

It's been a long, long time, so you probably do not remember. But take my word for it, way back when OS/2 was to be the Next Operating System, the Rich Text Format was generally hailed as a Very Good Thing. It was a document and data format which came with a published specification, and the plan was that this was to be the vendor neutral data exchange format for all applications which would talk RTF compatibly and henceforth data destruction due to inane incompatibilities and fuzzy interpretations would be a thing of the past.

The original RTF 1.0 specification has been preserved at sourceforge as http://latex2rtf.sourceforge.net/RTF-Spec-1.0.txt, and our friends at WikiPedia have a short but nice article at http://en.wikipedia.org/wiki/Rich_Text_Format.

I originally started writing that piece at the end of July 2007, before the ISO voting process over Microsofts "Office Open XML" specification had started. I was working on a book at the time, and never got very far with my planned overview with a very personal slant on that file format. The RTF format was actually useful in its time, and how it is constructed and how it was maintained can show us a lot of useful things. Now that it's clear that Microsoft succeeded in getting ISO approval for its specification, it's time to return to that subject.

What a process it has been. Microsoft has succeeded in buying itself an ISO standard. Piece by piece, in a process that included ballot-stuffing, bribes, and the administrative overruling of the relevant technical committee's decision by a national standards body (right here in Norway), Microsoft bought itself or is very close to getting its wholly-owned ISO standard. Nevermind that there is at least one formal investigation by the EU into the process and that the chairman of one national body's technical committee (once again, in Norway) has lodged a formal protest over procedure with ISO.

Microsoft won, and we will all have to learn to live with the consequences.

One of the very effective tactics was to have Microsoft partners sign up as voting members of national standards bodies, with clear instructions on how to vote. This lead to an influx of new voting members in various parts of the standards organization so large that other standardization efforts where Microsoft has no interest at the moment have reportedly ground to a halt. The reason is that what remains of formal procedure in ISO dictates that if enough members of a national body fail to vote on a proposed standard, the standard is not approved and fails by default. So the first victim of Microsoft's ISO takeover is no new standards. Who would want more ISO standards anyway?

And oh yes, Microsoft's main OOXML propagandist in Norway has offered up this document as proof that OOXML has been implemented and is in fact useable in OpenOffice too. It did not open at all in my OpenOffice 2.3 running on OpenBSD 4.3-current, (see here and here for the two stages of the results), and informed sources tell me that the much-ballyhooed formula is not editable when the document is imported into other applications such as Microsoft's own Office 2003 plus the compatibility pack.

And as if to emphasize the fact that all you can guarantee when you call something "XML" is that the data will start with a < and end with a >, this XML document in fact handles the equation part as an embedded binary object, intimately tied to Microsoft's equation editor. I suppose this means that even at 9,000 pages and counting, the spanking new ISO standard does not cover handling equations in a satisfactory manner. All in all, just how much more weirdness this will lead to is hard to predict.

But I digress. As I said earlier, RTF was thought to be a very good thing. The specification was a lot less ambitious and a lot slimmer than the XML based one, and since RTF was the source format for the Microsoft Windows Help file format, recommended for all apps to run on Windows, there were even usable examples documented in one of the several manuals you would get with the Microsoft programming tools.

As you would expect, word processors and other applications were rewritten to be able to read and write RTF. I worked in documentation and localization at the time, and over the years I had a fair amount of exposure to the format and the tools. Basically, any Windows application worth documenting would require an online help system and the source format would be RTF.

Just like an XML file has to start with a < and end with >, RTF files are made up of elements that are delimited by matching { and } curly braces. In principle, you could write valid RTF using any text editor, and the Microsoft documentation would show you how. That fact came in handy a few times when Word managed to mangle some other document with its 'fast save' feature or as punishment for sending the document to be edited at one machine too many during a technical review. The solution to essentially any problem, as long as the .DOC file was possible to open at all, would be to save the document as .RTF, count the number of {s and }s and see if the numbers were equal. If they were not, you would add one of the missing kind at either the top or the bottom, using any straight text editor. The magic would work, or at least put you in a position where you could extract useful data.

Over time you would upgrade to newer tools, and Microsoft's development discipline (amply documentend in the OOXML tomes) would show up at every Word upgrade if you had not been paying attention.

It would go like this: You get the fresh Word version with all the new bells and whistles, and do another revision of the help system for an app. The help compile would break horribly, and after some hair-pulling and tabletop-thumping you would eventually remember that this had in fact happened before.

The definition of RTF had changed.

After a while you would discover that hidden somewhere deep in the new Word's online help or README you would find Microsoft noting that application developers would need to install a newer version of the help compiler to get their RTF to compile. Or to put it slightly differently, the operative definition of what "RTF" is would always be "whatever Word produces when you save as RTF". To their credit, the RTF people at Microsoft would usually publish a new version of the specification some time after a new Word release.

So, we've been there before. "Whatever Microsoft {Word,Excel,PowerPoint} produces" is likely to be the operative definition of what OOXML is, even if the 9,000 pages and counting specification says something subtly different.

With a specification that lets dates be represented in radically different ways depending on context, say if you're saving from a word processor, a spreadsheet or a presentation program, we're in for a lot of entertainment, I'm sure.

The other things I'm sure about are that there will never be an implementation of OOXML as currently written (even if the OpenOffice.org people have made noises that they might try), and that a full implementation of anything vaguely similar will have to come from Microsoft.

Real gluttons for punishment could try the new hobby (or profession, if you can get a sponsor) of tracking the the day to day development in the set of differences between OOXML-as-published and OOXML-as-implemented.

Stuff I'll be getting back to: OpenBSD 4.3 is about to hit a mirror near you and hopefully your mailbox very soon, and more spam follies.

---

Update 2015-04-04: The demonstration document appears to load correctly in LibreOffice 4.3 -- I just tried it, and a screenshot is available here. I have no useful data on when the document became readable for anything not produced by Microsoft. In other news, Microsoft has now announced that an upcoming release of their Office product will be able to read and save ODF files.

---

Does anybody here remember Artie Eff? is © 2008 Peter N. M. Hansteen (published 2025-04-13)

---

You might also be interested in reading selected pieces via That Grumpy BSD Guy: A Short Reading List (also here).

At EuroBSDcon 2026, there will be a Network Management with the OpenBSD Packet Filter Toolset session, a full day tutorial starting at 2026-09-11 10:30 CET. You can register for the conference and tutorial by following the links from the conference Registration and Prices page.

---

BSD is dying, security shot to hell, clamav wins and other tales of depravity and greed

It's been an interesting week, in several ways.

Yesterday's big item was the slashdotted report that BSD is dying, or rather, that some important security related software in among others OpenBSD may, according to a paper by University of Cambridge researcher (and FreeBSD core member) Robert Watson, be vulnerable to a previously unresearched class of vulnerabilities. This time we're talking about a really hard problem which I think hits a lot more than the ones they picked for the tests. Local privilege escalation only, so not the third remote hole in OpenBSD after all. The paper is well worth reading, and if you're a little short of time, the slides will give you the general drift and then some. The sky didn't fall this time either.

Actually totally unrelated, Jason Dixon's BSD is dying talk (see above) is worth a few chuckles. He gave it at BSDCan 2007 too.

Meanwhile, reports say that over at LinuxWorld in San Francisco, they put a ten popular antivirus packages through the paces, and according to this story the free (as in GPL) ClamAV came out on top. Nice to see that the free stuff (which we've been using for years here) is found by independent testing to be as good as we thought it was.

Continuing the "the free stuff is quite good" thread, when I found that I actually needed a Windows machine to do some work from home, I tried getting that Windows laptop to talk to my wireless network at home. Windows didn't recognize the integrated 11b wireless adapter at all, so I dug out the Atheros based DWL-AG650 I'd used with the machine and various BSDs.

No go. Windows did register a new PCCARD inserted, but did not have a usable driver available. The Control Panel showed a generous helping of question marks, with two 'Ethernet Class' devices among them, so it's quite possible that the integrated 11b unit was the other one.

I'm not one who gives up easily, so I went to the D-Link web site for a driver. They did not actually have one on tap (or at least not easily available), since the card is no longer in production, so via the well known search engine starting with G I found something that claimed to be the correct Windows driver. Which installed, but even after a reboot the card management software (why oh why a separate management app for each bit of hardware in your system?) still claimed that no compatible card was present.

A short string of unprintables and 22 minutes later, I had the machine working the-thing-that-needed-windows via Rdesktop on Ubuntu, remote controlling a machine at the office. The moral of the story: If you need Windows, you're better off with Linux and Rdesktop.

Certainly worth a read is the short paper by Sun's Jon Bosak on why Sun voted not to OOXML, at http://www.streamingweb.no/v1-ooxml.pdf.
Well researched and well written, and contains such nuggets as

"On the face of it, this astonishing provision would appear to indicate that the authors of the DIS did not understand the purpose of XML,"

and

"In practice, the effect of radical underspecification is to allow behavioral details to be determined on an ad hoc basis by the dominant software."

This somehow fails to surprise me, it's the story of RTF all over again. I'be been meaning to write about Microsoft vs standards, but in the meantime Jon's paper is well worth reading.

Back to the inevitable spam update (yes, elzapp, I do sometimes blog about something besides spam), the local traplist keeps growing. I sometimes wonder if they've actually looked at what we do here - this morning's batch of fake From: addresses had proofreads49@datadok.no among them.

And accenting one of the points I made in the malware paper that we are making the spammers work ever harder to generally fail to deliver their crap, Bob Beck's traplist keeps growing and has now hit a new all-time high of 125,808 entries.

That number could grow a bit more before they're all done. I do pity those who get billed by unit of data transferred who still don't have a sensible setup in place.

And yes, the book is progressing.

UPDATE 2007-08-14: After a relatively quiet weekend spamwise (Bob Beck's list in the 65,000 to 85,000 range), activity seems to have reached another peak with a total of 141,892 entries trapped at 08:00 CEST this morning. I would have expected to see a corresponding surge in the number of new bogus addresses seen in our greylist, but they did not turn up. We can always hope that this is due to saner spam handling at sites which used to bounce spam back to the From: address.

Linux is easier than Windows, hands down

It all started a few weeks back when my wife and I decided to get her a new laptop. It was also conveniently close to her July 14th birthday and Dell had a huge campaign going in the newspapers. Dell had just started selling laptops with various Linuxes preinstalled, and Ubuntu was the environment of choice, so I felt reasonably sure that the machine would be usable even if the Linux preinstalled option is not available in Norway yet. After all, our daughter had essentially no trouble at all getting her laptop (a sleek little LG number) going with Ubuntu earlier this year.

So I ended up clicking my way on to the Dell web site and ordering an Inspiron 1520 with 1440x900 resolution and the Ruby Red option (actually it's just the lid, but it does look distinctive).

As luck and Dell's suppliers would have it, the color added some time to the delivery. The machine apparently shipped earlier than expected, and arrived here last Monday afternoon, most likely very close to when the plane with my wife and daughter touched down at Madeira.

I had already burned a 7.04 desktop iso to CD and booted from that. As with anything that comes with Microsoft preinstalled, you need to be really careful to hit the right key at the right moment unless you want to do battle with the Microsoft installer.

Eventually I succeeded, though, the thing booted, went into the traditional graphic Ubuntu startup and dropped me to a shell. Odd. Fortunately from my OpenBSD laptop I was able to find this ubuntuforums.org post which explains in some detail what needs to be done. In particular, the piece about how to fix the graphics driver is quite instructive.

Getting things done right when the graphics card and the wireless network card both need proprietary drivers loaded is a little puzzling when the system is supposed to be all graphic and your default network is wireless, but by following the instructions from the forum I made it eventually.

The short version is, in addition to the oddities involved in getting proprietary drivers the machine requires, the Feisty installer kernel for some reason does not have the proper support for the SATA controller in this Dell model.

Going back to the earlier version lets you do a clean upgrade, and to get all the bits working you need to have both the universe and the multiverse repositories in your package manager's configuration. Not hard for somebody who has not yet recycled all the grey cells with Debian etched into them, just a bit tedious, and even though all steps of the process was accompanied by sensible messages from the system, our only live Ethernet is in the attic where the servers live.

Anyway by elevenish in the evening I had the system all installed with native resolution and 32 bit color depth, on the wireless network and Just Working. The process took significantly less time than putting Windows from restore CDs back on the system it came with.

Yet another evening spent on other things than I had intended (such as writing those crucial bits of the book), but seriously folks, you must never miss an opportunity to make your wife happy.

With that out of the way, I can state with even more confidence:

Linux is easier and more user friendly than Windows.

By now I consider that to be documented beyond question.

But for the things I care about, I really prefer OpenBSD or FreeBSD.

Updates: The spamtrap is growing by a few new addresses a day. I sometimes spot them flying by in the xterm where my spamd log is tail -f'd, sometimes I grep them out of the mail server's logs. Some patterns are emerging, but more later when I have more data.