In 1979, VisiCalc was released for the Apple II, and to this day, many consider it the very first spreadsheet program. Considering just how important spreadsheets have become since then – Excel rules the world – the first spreadsheet program is definitely an interesting topic to dive into. It turns out that while VisiCalc was the first spreadsheet program for home computers, it’s not actually the first spreadsheet program, period. That honour goes to LANPAR, created ten years before VisiCalc.

Ten years before VisiCalc, two engineers at Bell Canada came up with a pretty neat idea. At the time, organizational budgets were created using a program that ran on a mainframe system. If a manager wanted to make a change to the budget model, that might take programmers months to create an updated version.

Rene Pardo and Remy Landau discussed the problem and asked “what if the managers could make their own budget forms as they would normally write them?” And with that, a new idea was created: the spreadsheet program.

The new spreadsheet was called LANPAR, for “LANguage for Programming Arrays at Random” (but really it was a mash-up of their last names: LANdau and PARdo).

↫ Jim Hall at Technically We Write

While there wasn’t a graphical user interface on the screen with a grid and icons and everything else we associate with a spreadsheet today, it was still very much a spreadsheet. Individual cells were delinianated with semicolons, you could write down formulas to manipulate these cells, and the program could do forward referencing. The idea was to make it so easy to use, managers at Dell Canada could make budgeting changes overnight, instead of having programmers take weeks or months to do so.

I’m not particularly well-versed in Excel and spreadsheets in general, but I can definitely imagine advanced users no longer really seeing the grids and numbers as individual entities, instead visualising everything much more closely to what LANPAR did. Like Neo when he finally peers through the Matrix.

Jamie Zawinski, one of the founders of Netscape and later Mozilla, has dug up the original versions of the iconic Mozilla dinosaur logos, and posted them online in all their glory. While he strongly believes Mozilla owned these logos outright, and that they were released as open source in 1998 or 1999, he can’t technically prove that.

It has come to my attention that the artwork for the original mozilla.org “dinosaur” logo is not widely available online. So, here it is.

As I explained in some detail in my 2016 article “They Live and the secret history of the Mozilla logo”, I commissioned this artwork from Shepard Fairey to use as the branding of the newly-founded mozilla.org and our open source release of the Netscape source code, which eventually became Firefox. This happened in March 1998.

↫ Jamie Zawinski

The original Mozilla dinosaur logos are works of pure art. They sure don’t make logos like this anymore.

In recent years, things have not been going well for Mozilla. Firefox’s market share is a rounding error, and financially, the company is effectively entirely dependent on free money from Google for making it the default search engine in Firefox. Mozilla’s tried to stem the bleeding with deeply unpopular efforts like focusing on online advertising and cramming more and more “AI” into Firefox, but so far, nothing has worked, and more and more of the remaining small group of Firefox users are moving to modded versions of Firefox without the “AI” nonsense and other anti-features.

The task of turning the tide is now up to Mozilla’s new CEO, Anthony Enzor-DeMeo, who took up the role starting today. In his first message to the public in his new role as CEO of Mozilla, he lays out his vision for the future of the company. What are his plans for Mozilla’s most important product, the Firefox web browser?

Firefox will grow from a browser into a broader ecosystem of trusted software. Firefox will remain our anchor. It will evolve into a modern AI browser and support a portfolio of new and trusted software additions.

↫ Anthony Enzor-DeMeo

So far, the “AI” additions to Firefox have not exactly been met with thunderous applause – to put it mildly – and I don’t see how increasing these efforts is going to magically turn that sentiment around. I’d hazard a guess that Firefox users, in particular, are probably quite averse to “AI” and what it stands for, further strengthening the feeling that the people leading Mozilla seem a little bit out of touch with their own users. Add to this the obvious fact that “AI” is a bubble waiting to pop, and I’m left wondering how investing in “AI” now is going to do anything but make Mozilla waste even more money.

I don’t want Firefox to fail, as it is currently the only browser that isn’t Chrome, Chrome in a trench coat, or Safari, but it seems Mozilla is trying to do everything to chase away what few users Firefox had left. In the short term, we can at least use modified versions of Firefox that have the “AI” nonsense and other anti-features removed, but for the long term, we’re going to need something else if Mozilla keeps going down the same path it’s been going in recent years. The only viable long-term alternative is Servo, but that’s still a long way off from being a usable day-to-day browser.

The browser landscape ain’t looking so hot, and this new Mozilla CEO is not making me feel any better.

Back in 2017 I wrote about a technique for creating closures in C using JIT-compiled wrapper. It’s neat, though rarely necessary in real programs, so I don’t think about it often. I applied it to qsort, which sadly accepts no context pointer. More practical would be working around insufficient custom allocator interfaces, to create allocation functions at run-time bound to a particular allocation region. I’ve learned a lot since I last wrote about this subject, and a recent article had me thinking about it again, and how I could do better than before. In this article I will enhance Win32 window procedure callbacks with a fifth argument, allowing us to more directly pass extra context. I’m using w64devkit on x64, but the everything here should work out-of-the-box with any x64 toolchain that speaks GNU assembly.

↫ Chris Wellons

Sometimes, people get upset when I mention something is out of my wheelhouse, so just for those people, here’s an article well outside of my wheelhouse. I choose honesty over faking confidence.

There’s a new Haiku monthly activity report, and this one’s a true doozy. Let’s start with the biggest news.

The most notable development in November was the introduction of a port of the Go programming language, version 1.18. This is still a few years old (from 2022; the current is Go 1.25), but it’s far newer than the previous Go port to Haiku (1.4 from 2014); and unlike the previous port which was never in the package repositories, this one is now already available there (for x86_64 at least) and can be installed via pkgman.

↫ Haiku activity report

As the project notes, they’re still a few versions behind, but at least it’s a lot more modern of an implementation than they had before. Now that it’s in the repositories for Haiku, it might also attract more people to work on the port, potentially bringing even newer versions to the BeOS-inspired operating system. Welcome as it may be, this new Go port isn’t the only big ticket item this month.

Haiku can now gracefully recover from an app_server crash, something it used to be able to do a long time ago, but which was broken for a long time. The app_server is Haiku’s display server and window manager, so the ability to restart it at runtime after a crash, and have it reconnect with still-running applications, is incredibly welcome. As far as I can tell, all modern operating systems can do this by now, so it’s great to have this functionality restored in Haiku.

Of course, aside from these two big improvements, there’s the usual load of fixes and changes in applications, drivers, and other components of the operating system.

Alpine Linux maintainer Ariadne Conill has published a very interesting blog post about the shortcomings of both sudo and doas, and offers a potential different way of achieving the same goals as those tools.

Systems built around identity-based access control tend to rely on ambient authority: policy is centralized and errors in the policy configuration or bugs in the policy engine can allow attackers to make full use of that ambient authority. In the case of a SUID binary like doas or sudo, that means an attacker can obtain root access in the event of a bug or misconfiguration.

What if there was a better way? Instead of thinking about privilege escalation as becoming root for a moment, what if it meant being handed a narrowly scoped capability, one with just enough authority to perform a specific action and nothing more? Enter the object-capability model.

↫ Ariadne Conill

To bring this approach to life, they created a tool called capsudo. Instead of temporarily changing your identity, capsudo can grant far more fine-grained capabilities that match the exact task you’re trying to accomplish. As an example, Conill details mounting and unmounting – with capsudo, you can not only grant the ability for a user to mount and unmount whatever device, but also allow the user to only mount or unmount just one specific device. Another example given is how capsudo can be used to give a service account user to only those resources the account needs to perform its tasks.

Of course, Conill explains all of this way better than I ever could, with actual example commands and more details. Conill happens to be the same person who created Wayback, illustrating that they have a tendency to look at problems in a unique and interesting way. I’m not smart enough to determine if this approach makes sense compared to sudo or doas, but the way it’s described it does feel like a superior, more secure solution.

System76, creator of Pop!_OS and prominent Linux OEM, has just announced the release of Pop!_OS 24.04 LTS – normally not something I particularly care about, but in this case, it comes with the first stable release of COSMIC Desktop. COSMIC is a brand new desktop environment by System76, written in Rust, and after quite some time in development, it’s now out in the wild as a stable release.

Today is special not only in that it’s the culmination of over three years of work, but even more so in that System76 has built a complete desktop environment for the open source community. We’re proud of this contribution to the open source ecosystem. COSMIC is built on the ethos that the best open source projects enable people to not only use them, but to build with them. COSMIC is modular and composable. It’s the flagship experience for Pop!_OS in its own way, and can be adapted by anyone that wants to build their own unique user experience for Linux.

↫ Carl Richell

You don’t need to run Pop!_OS to try out COSMIC, as it’s already available on a variety of other distributions (although it may take a bit for this stable version to land in the respective repositories).

I’m sure most of us here are aware of the bright red-and-yellow colour scheme called “Hot Dog Stand”, included in Windows 3.1. While it’s not the only truly garish colour scheme included in Windows 3.1, its name probably did a lot to make it stand out from the others. There’s been a ton of speculation about the origins of the colour scheme, and why it was included in Windows 3.1, but it seems nobody ever bothered to look for someone who actually worked on the Windows 3.1 user interface – until now.

PC Gamer’s Wes Fenlon contacted Virginia Howlett, Microsoft’s first user interface designer who joined the company in 1985, and asked her about the infamous colour scheme. It turns out that the origin story for the infamous colour scheme is rather mundane. In Howlett’s own words:

I do remember some discussion about whether we should include it, and some snarky laughter. But it was not intended as a joke. It was not inspired by any hot dog stands, and it was not included as an example of a bad interface—although it was one. It was just a garish choice, in case somebody out there liked ugly bright red and yellow.

↫ Virginia Howlett, quoted by Wes Fenlon in PC Gamer

Howlett then lists a few other included colour schemes that were just as garish, or even more so, as examples to underline her point. Personally, I’m a huge proponent of allowing users to make their interfaces as ugly and garish as they want, as the only arbiter on what’s on your screen is you, and nobody else. Hot Dog Stand and similar garish themes need to make a comeback, because there’s bound to be some people out there whose vibes align with it.

I have some potentially devastating news for POWER users interested in using FreeBSD, uncovered late last month by none other than Cameron Kaiser.

FreeBSD is considering retiring powerpc64 prior to branching 16, which would make FreeBSD 15 the last stable version to support the architecture. (32-bit PowerPC is already dropped as of FreeBSD 14, though both OpenBSD and NetBSD generally serve this use case, and myself I have a Mac mini G4 running a custom NetBSD kernel with code from FreeBSD for automatic restart.) Although the message says “powerpc64 and powerpc64le” it later on only makes specific reference to the big-endian port, whereas both endiannesses appear on the FreeBSD platform page and on the download server.

↫ Cameron Kaiser

There’s two POWER9 systems in my office, so this obviously makes me quite sad. At the same time, though, it’s hard not to understand any possible decision to drop powerpc64/powerpc64le at this point in time. Raptor’s excellent POWER9 systems – the Blackbird, which I reviewed a few years ago, and the Talos II, which I also have – are very long in the tooth at this point and still quite expensive, and thanks to IBM royally screwing up POWER10, we never got any timely successors. There were rumblings about a possible POWER11-based successor from Raptor back in July 2025, but it’s been quiet on that front since.

In other words, there are no modern powerpc64 and powerpc64le systems available. POWER10 and brand new POWER11 hardware are strictly IBM and incredibly expensive, so unless IBM makes some sort of generous donation to the FreeBSD Foundation, I honestly don’t know how FreeBSD is supposed to keep their powerpc64 and powerpc64le ports up-to-date with the latest generation of POWER hardware in the first place.

It’s important to note that no final decision has been made yet, and since that initial report by Kaiser, several people have chimed in to argue the case that at least powerpc64le (the little endian variant) should remain properly supported. In fact, Timothy Pearson from Raptor Engineering stepped up the place, and stated he’s willing to take over maintainership of the port, as Raptor has been contributing to it for years anyway.

Raptor remains committed to the architecture as a whole, and we have resources to assist with development. In fact, we sponsor several FreeBSD build machines already in our cloud environment, and have kernel developers working on expanding and maintaining the FreeBSD codebase. If there is any concern regarding hardware availability or developer resources, Raptor is willing and able to assist.

↫ Timothy Pearson

Whatever decision the FreeBSD project makes, the Linux world will be fine for a while yet as IBM contributes to its development, and popular distributions still consider POWER a primary target. However, unless either IBM moves POWER hardware downmarket (extremely unlikely) or the rumours around Raptor have merit, I think at least the FreeBSD powerpc64 (big endian) port is done for, with the powerpc64le port hopefully being saved by people hearing these alarm bells.

Secretary of State Marco Rubio waded into the surprisingly fraught politics of typefaces on Tuesday with an order halting the State Department’s official use of Calibri, reversing a 2023 Biden-era directive that Mr. Rubio called a “wasteful” sop to diversity.

While mostly framed as a matter of clarity and formality in presentation, Mr. Rubio’s directive to all diplomatic posts around the world blamed “radical” diversity, equity, inclusion and accessibility programs for what he said was a misguided and ineffective switch from the serif typeface Times New Roman to sans serif Calibri in official department paperwork.

↫ Michael Crowley and Hamed Aleaziz at The New York Times

With the current, rapidly deteriorating state of the Windows operating system, you have to take the small wins you can get: Microsoft is now offering the option of removing “AI” actions from Windows 11’s context menus. buried deep in the Windows 11 Insider Preview Build 26220.7344 release notes, there’s this nugget:

If there are no available or enabled AI Actions, this section will no longer show in the context menu.

↫ Windows Insider Preview release notes

If you then go to Settings > Apps > Actions and uncheck all the “AI” actions, the entire submenu in Windows 11’s context menus will vanish. While this is great news for those Windows users who don’t want to be bothered by all the “AI” nonsense, I wish Microsoft would just give users a proper way to edit the context menu that doesn’t involve third party hackery. KDE’s Dolphin file manager gives me full control over what does and does not appear in its context menu, and I can’t imagine living without this functionality – there’s so many file-related operations I never use, and having them clutter up the context menu is annoying and just slows me down.

There’s more substantial and important changes in this Insider Preview Build too, most notably the rollout of the Update Orchestration Platform, which should make downloading and installing application updates less cumbersome, but since it’s a new feature, application won’t support it right away. This release also brings the new Windows MIDI Services, and Microsoft hopes this will improve the experience for musicians using MIDI 1.0 or MIDI 2.0 on Windows. There’s a slew of smaller changes, too, of course.

I’m not exactly sure when these new features will make their way to production installations – who does, honestly, with Microsoft’s convoluted release processes – but I hope it’s sooner rather than later.

When Mac OS X was designed, it switched to the bundle structure inherited from NeXTSTEP. Instead of this multitude of resources, apps consisted of a hierarchy of directories containing files of executable code, and those with what had in Mac OS been supporting resources. Those app bundles came to adopt a standard form, shown below.

↫ Howard Oakley

A short, but nonetheless informative overview of the structure of a macOS application. I’m sure most people on OSNews are aware that a macOS application is a bundle, which is effectively a glorified directory containing a variety of files and subdirectories that together make up the application. I haven’t used macOS in a while, but I think you can right-click on an application and open it as a folder to dig around inside of it.

I’m trying to remember from my days as a Mac OS X user – 15-20 years ago – if there was ever a real need to do so, but I’m sure there were a few hacks you could do by messing around with the files inside of application bundles. These days, perhaps with all the code-signing, phoning-home to Apple, and other security trickery going on, such acts are quite frowned upon. Does making any otherwise harmless changes inside an application bundle set off a ton of alarm bells in macOs these days?

OSNews is funded entirely by you, our readers. There are no ads on OSNews, we are not part of a massive corporate publishing conglomerate like virtually every other technology news website, there are no wealthy (corporate) benefactors – it’s just whatever funds you, our readers, send our way. As such, I sometimes need to remind everyone about this, and December, the holiday month, seems as great a time as any to do this.

If you want to support a truly independent technology news website, free from the corrupting influences of corporate interests, advertising companies, managers pushing “AI”, and all the other nonsense destroying the web we once loved, you can do so by donating to keep OSNews alive. This gives me the time and means to write 9000 words about dead computer ecosystems, and I’m already working on an article about the next final UNIX workstation.

• If you want to make a single, non-recurring donation, you can donate to the OSNews Ko-Fi. Every amount, large or small, is deeply appreciated.
• If you want to make recurring donations, you can become an OSNews Patreon.
• You can also buy some OSNews merch! We’ve got some great shirts and mugs with awesome designs, and every individual purchase nets OSNews about $8.

Every single donation, large or small, is deeply appreciated and keeps the lights on around here. There aren’t many websites like OSNews left, especially not independent ones that answer to nobody. Your support keeps OSNews going, with June 2026 marking a special moment for me: it will mark twenty years since I took over this place. I’m not expecting a party – you’re paying me to work, not to party – but it is still a meaningful anniversary for me personally.

Some of you may be aware of rePalm, a project by Dmitry Grinberg to port the PalmOS to various devices it was never supposed to run on. We covered rePalm back in 2019 and again in 2023. His latest project involved porting PalmOS to a set of digital toys that were never intended to run PalmOS in any way.

Fisher-Price (owned by Mattel) produced some toys in the early 2000 under the Pixter brand. They were touchscreen-based drawing toys, with cartridge-based extra games one could plug in. Pixter devices of the first three generations (“classic”, “plus”, and “2.0”) featured 80×80 black-and-white screens, which makes them of no interest for rePalm. The last two generations of Pixter (“color” and “multimedia”) featured 160×160 color displays. Now, this was more like it! Pixter was quite popular, as far as kids’ toys go, in USA in the early 2000s. A friend brought it to my attention a year ago as a potential rePalm target. The screen resolution was right and looking inside a “Pixter Color” showed an ARM SoC – a Sharp LH75411. The device had sound (games made noises), and touch panel was resistive. In theory – a viable rePalm target indeed.

↫ Dmitry Grinberg

Considering the immensely limited ARMv7 implementation he had to deal with – no cache, no memory management unit, no memory protection unit – it’s a miracle Grinberg managed to succeed. To make matters even harder, the first revision boards of the “color” model only had 1MB of flash, which is incredibly small even for PalmOS 5, so he had to rewrite parts of it to make it fit. Implementing communication over infrared was also a major difficulty, but that, too he managed to get working – on a device that doesn’t have IrDA SIR modulation. Wild.

Grinberg went above and beyond, making sure the buttons on the devices work, developing and building a way to put PalmOS on a “game” cartridge, reverse-engineering the display controller to make sure things like brightness adjustment works, adding screen type detection for that one small run of Pixter Color devices that came with a TFT instead of an STN screen, and so, so much more. Until you read the article, you have no idea how much work Grinberg put into this project.

I continue to be in awe of Grinberg’s work every time I come across it.