Monthly Archive:: April 2024
Humans speak countless different languages. Not only are these languages incompatible, but runtime transpilation is a real pain. Sadly, every standardisation initiative has failed. At least there is someone to blame for this state-of-affairs: God. It was him, after-all, who cursed humanity to speak different languages, in an early dispute over a controversial property development. However, mankind can only blame itself for the fact that computers struggle to talk to each other. And one of the biggest problems is the most simple: computers do not agree on how to write letters in binary. ↫ Cal Paterson For most users, character encoding issues are not something they have to deal with. Programmers and other people who deal with the lower levels of computing, however, deal with this way more often than they should.
Over 35 years ago, these problems with software portability led to the emergence of the first POSIX standard in 1988. The acronym was coined by Richard Stallman, who added “X” to the end of Portable Operating System Interface. It’s meant to provide a specification of the interface that different Unix operating systems should have in common, including programming languages and tools. It’s important to note that the interface is portable, and not the implementation. ↫ vorakl While POSIX certainly isn’t perfect, and support for it in various operating systems claiming to support POSIX even less so, there’s no denying its success. Even if the dream of 100% source code portability isn’t possible under POSIX for applications that are a little more complex than basic CLI tools, there’s enough portability that platforms like Linux, the various BSDs, macOS, and others, can share quite a bit of code. One of my favourite things about POSIX is that it shows up in the most unexpected of places. Windows, for instance, has had various options for POSIX compatibility, some of which straight from Microsoft itself, like the currently well-known Windows Subsystem for Linux, but also mostly forgotten options like the Microsoft POSIX subsystem that shipped with Windows NT until Windows 2000, or the very rudimentary POSIX compatibility in the Windows C Runtime Library and Windows Sockets API. OS/2 had POSIX compatibility as well, through EMX (Eberhard Mattes eXtender). It gave OS/2 – and MS-DOS – a POSIX API, and even provided access to native OS/2 APIs as well, and could run 32bit applications. You’d be surprised by how many more operating systems offered forms of POSIX compatibility, either out of the box or through first or third party add-ons.
Although Google has shown significant progress in recent weeks in improving RISC-V support in Android, it seems that we’re still quite a bit away from seeing RISC-V hardware running certified builds of Android. Earlier today, a Senior Staff Software Engineer at Google who, according to their LinkedIn, leads the Android Systems Team and works on Android’s Linux kernel fork, submitted a series of patches to AOSP that “remove ACK’s support for riscv64.” The description of these patches states that “support for risc64 GKI kernels is discontinued.” ↫ Mishaal Rahman Google provided Android Authority with a statement, claiming that Android will continue to support RISC-V. What these patches do, however, is remove support for the architecture from the Generic Kernel Image, which is the only type of kernel Google certifies for Android, which means that it is now no longer possible to ship a certified Android device that uses RISC-V. Any OEM shipping a RISC-V Android device will have to create and maintain its own kernel fork with the required patches. This doesn’t seem to align with Google’s statement. So, unless Google intends to add RISC-V support back into GKI, there won’t be any officially certified Android devices running on RISC-V. Definitely an odd chain of events here.
JMP is a fully FOSS service providing a way to get a real phone number that operates over the internet using XMPP. They provide numbers in the USA and Canada with everything you need to access SMS/MMS/etc. and voice calls using your XMPP (or SIP) clients of choice across all your devices. They are committed to growing the use of open communications technology such as XMPP, ultimately working to help people move their communication off the unencrypted telephone network and onto the federated, encrypted, and diverse Jabber network. We thank JMP for sponsoring OSNews this week, and they even offer a discount code for OSNews readers who sign up for the service. Use the code OSNEWS for one free month after paying for your account initially.
There’s a new 9front release! So, what exactly is 9front, you may ask? Well, after it became clear that Bell Labs wasn’t doing much with plan9, a group of developers took matters into their own hands and created 9front, a fork of plan9. Their latest release is called DO NOT INSTALL, and brings things like more USB audio support, DNS over TLS, WiFi support for the Raspberry Pi, I2C support, and much more. I’m not particularly well-versed in the world of plan9, and more often than not it feels like a form of high-level programming performance art that I’m just not smart enough to understand. The whole community and its associated web sites have a very unique feel to it, and I always feel like I’m just not cool enough to be part of it. That’s not a dig at the plan9 community – it’s more of an indictment of my lack of coolness. Which really shouldn’t come as a surprise.
Lennart Poettering, main developer of systemd, has announced run0, a systemd-based replacement for the well-known sudo command that fixes many of he inherent issues with the widely used tool to gain temporary elevated privileges. There are various problems with sudo, which basically come down to that it’s a large SUID binary, meaning it consists of privileged code that unprivileged users can run from their own context. This makes sudo a fairly large attack surface, and why OpenBSD uses doas instead; while doas suffers from the same main problem, it’s much smaller and reduces the attack surface considerably. SUID processes are weird concepts: they are invoked by unprivileged code and inherit the execution context intended and controlled by unprivileged code. By execution context I mean the myriad of properties that a process has on Linux these days, from environment variables, process scheduling properties, cgroup assignments, security contexts, file descriptors passed, and so on and so on. A few of these settings the kernel is nice enough to clean up automatically when a SUID binary is invoked, but much of it has to be cleaned up by the invoked suid binary. This has to be done very very carefully, and history has shown that SUID binaries are generally pretty shit at that. ↫ Lennart Poettering Poettering wants to address this problem, and has come up with run0, which behaves like sudo, but works entirely differently and is not SUID. Run0 asks the services manager to create a shell or command under the target user’s ID, creating a new PTY, sending data back and forth from the originating TTY and the new PTY. Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we *do* propagate $TERM, but that’s an explicit exception, i.e. allowlist rather than denylist). One could say, “run0” is closer to behaviour of “ssh” than to “sudo”, in many ways. Except that it doesn’t bother with encryption or cryptographic authentication, key management and stuff, but instead relies on the kernel’s local identification mechanisms. run0 doesn’t implement a configuration language of its own btw (i.e. no equivalent of /etc/sudoers). Instead, it just uses polkit for that, i.e. how we these days usually let unpriv local clients authenticate against priv servers. ↫ Lennart Poettering This approach addresses a whole slew of attack vectors on sudo, and it comes with fun additional features like being able to give your terminal a different background tint when using it, or displaying a little red dot in the terminal window title to further indicate you’re using elevated privileges. It will ship as part of the upcoming release of systemd 256.
Well, this was a wild goose chase of a read. J. B. Crawford dove into the history of something I’ve never heard of – Microsoft At Work – and came away with a story that’ while clearer thanks to his research, is still frustratingly nebulous. I’m still not entirely sure what Microsoft At Work really was, but I think it had the goal of running Windows on communications devices like faxes, to make it easier to share and work on documents across various devices. Crawford did a lot of digging, and eventually settles on what he thinks might be a description of what MAW really consisted of. I am being a bit dismissive for effect. MAW was more ambitious than just installing Windows on a grape. The effort included a unified communications protocol for the control of office machines, including printers, for which a whole Microsoft stack was envisioned. This built on top of the Windows Printing System, a difficult-to-search-for project that apparently predated MAW by a short time, enough so that Windows Printing System products were actually on the market when MAW was announced—MAW products were, we will learn, very much not. MAW devices like the Ricoh IFS77 ran 16-bit Windows 3.1 with a new GUI intended to appear more modern while reducing resource requirements. Some reporters at the time noted that Microsoft was cagey about the supported architectures, I suspect they were waiting on ports to be completed. The fax machine was probably x86, though, as there’s little evidence MAW actually ran on anything else. ↫ J. B. Crawford The ’90s were a wild time, especially as Microsoft, and this MAW project seems to have ’90s written all over it, but I’d still love to learn a lot more about this. I hope this article will bring out some former Microsoft execs or employees who can give us more details, and possibly even some code. I want to know how this works and what it did.
This is a virtual DEC PDP-1 (emulated in HTML5/JavaScript) running the original code of “Spacewar!”, the earliest known digital video game. If available, use gamepads or joysticks for authentic gameplay — the game was originally played using custom “control boxes”. Spacewar! was conceived in 1961 by Martin Graetz, Stephen Russell, and Wayne Wiitanen. It was first realized on the PDP-1 in 1962 by Stephen Russell, Peter Samson, Dan Edwards, and Martin Graetz, together with Alan Kotok, Steve Piner, and Robert A Saunders. ↫ Norbert Landsteiner It’s wild to me that even for the very first video game, they already made what are effectively controllers anyone today could pick up and use. Note that this emulator can run more than just Spacewar!.
Back when I was working on my article about PA-RISC, HP-UX, and UNIX workstations in general, I made extensive use of OpenPA, Paul Weissmann’s invaluable and incredibly detailed resource about HP’s workstation efforts, HP-UX, and tons of related projects and products. Weissmann’s been doing some serious digging, and has unearthed details about a number of essentially forgotten operating system efforts. First, it turns out HP was porting Windows NT to PA-RISC in the early ’90s. Several magazine sources and USEnet posts around 1993 point to HP pursuing a PA-RISC port to NT, modified the PA-RISC architecture for bi-endianess and even conducted a back-room presention at the ’94 Comdex conference of a (modified HP 712?) PA-7100LC workstation running Windows NT. Mentions of NT on PA-RISC continued in 1994 with some customer interest but ended around 1995. ↫ Paul Weissmann at OpenPA The port eventually fizzled out due to a lack of interest from both customers and application developers, and HP realised its time was better spent on the future of x86, Intel’s Itanium, instead. HP also planned to work together with Novell to port NetWare to PA-RISC, but the work took longer than expected and it, too, was cancelled. The most recent secretive effort was the port of HP-UX to x86, an endeavour that took place during the final days of the UNIX workstation market. Parts of the conversation in these documents mention a successful boot of HP-UX on x86 in December of 2009, with porting efforts projected to cost 100M+ between 2010 and 2016. The plan was for mission-critical x86 systems (ProLiant DL980 and Superdome with x86) and first releases projected in 2011 (developer) and 2012 (Superdome and Linux ABI). ↫ Paul Weissmann at OpenPA I’m especially curious about that last one, as porting HP-UX to x86 seems like a massive effort during a time where it was already obvious Linux had completely obliterated the traditional UNIX market. It really feels like the last death saving throws of a platform everybody already knew wasn’t going to make it.
As you may be aware, the GNOME Foundation has operated at a deficit (nonprofit speak for a loss – ie spending more than we’ve been raising each year) for over three years, essentially running the Foundation on reserves from some substantial donations received 4-5 years ago. The Foundation has a reserves policy which specifies a minimum amount of money we have to keep in our accounts. This is so that if there is a significant interruption to our usual income, we can preserve our core operations while we work on new funding sources. We’ve now “hit the buffers” of this reserves policy, meaning the Board can’t approve any more deficit budgets – to keep spending at the same level we must increase our income. ↫ Robert McQueen Learning that the GNOME Foundation can barely scrape by financially makes me irrationally angry. As much as I’ve grown to dislike using GNOME and thus switched all my machines over to KDE, GNOME is still the most popular desktop environment and used extensively by pretty much all the big corporate Linux distributions. How is it possible that this hugely popular and important open source project has to beg individual users for donations like they’re running an independent tech website or something? Where’s all the financial support from Red Hat, IBM, Oracle, Canonical, and so on? If not even an insanely popular project like GNOME can be financially stable, what hope is there for the countless small, unknown open source projects that form the basis of our entire computing world?
In February last year I wrote about running a FreeBSD desktop, and concluded that sometimes you need to give yourself permission to tinker. Well recently I’ve started tinkering with Alpine Linux! It’s been recommended to me for years, so I’m finally getting around to checking it out. There’s a lot to like if you come from BSD, which we’ll dig into here. ↫ Ruben Schade Just a quick look at this unexpectedly popular Linux distribution that really has its own identity.
The Genode project has released Sculpt OS 24.04, the general purpose desktop operating system based on the Genode OS Framework. This release is absolutely jam-packed with new features, improvements, and changes, and it’s hard to know where to begin. One of the biggest new features is support for suspend/resume, an experimental feature for now, for which the developers also made starting and stopping drivers and related components easier straight from the user interface. In addition, NVMe, AHCI, and Intel GPU drivers will resume automatically after a resume. Sculpt OS 24.04 also ships with a brand new audio framework, which brings support for “pluggable drivers, arbitrary sample rates, and the flexible routing and mixing of audio signals”, but the audio driver does need to be manually restarted after a resume. This release also adds support for 4K displays and I2C touchpads, underlining that yes, Sculpt and Genode developers dogfood their operating system on real hardware. Do note that at least for now, the I2C touchpad driver needs to be started manually, so an external mouse will initially be needed. Various images are available for download from the download page.
Microsoft is about to go even more hog-wild with “AI” in Windows, as it intends to start recording everything you do on your Windows computer so “AI” features can find stuff for you. According to my sources, AI Explorer will run in the background and capture everything you do on your computer. It will document and triage everything it sees, no matter what apps or interfaces you’re looking at, and turn them into memories that you can recall at a later point. For example, you can have a conversation with a friend in the WhatsApp app for Windows, and AI Explorer will record and remember the content that was on-screen and process it with AI for you to recall later. AI Explorer can also summarize conversations, emails, web pages, and general UI surfaces just by asking for it during or after the fact. I’m told that much of this experience is rendered on-device and does not reach out to the cloud to process information. This is important for privacy reasons, but also for performance reasons. To reduce latency, AI Explorer will rely on NPU silicon to process content that has been recorded. I also understand that users will be able to filter out specific apps from being recorded by the AI Explorer process, or disable AI Explorer entirely. ↫ Zac Bowden at Windows Central Is this really something people wan to devote constant resources and thus battery life to?Setting aside the privacy implications of something like this, do people really want to have a permanent record of everything they’ve done on their machine? Maybe I’m just the odd one out here, but nothing about this appeals to me in any way, shape, or form. In fact, it’s quite the opposite – something like this would make make me run for the hills, looking for an alternative to the operating system I’m using. And the weasel words “much of this experience is rendered on-device” definitely did not go by unnoticed. This wording makes it very clear at least some data will be sent to Microsoft for processing, and over time, that amount will only increase. No data company has ever reduced the amount of data it captures, after all.
Regarding the release of the MS-DOS 4.00 source code, Michal Necasek makes an excellent point about how just dumping the code in git is a terrible and destructive way to release older source code. It’s terrific that the source code for DOS 4.00/4.01 was released! But don’t expect to build the source code mutilated by git without problems. Historic source code should be released simply as an archive of files, ZIP or tar or 7z or whatever, with all timestamps preserved and every single byte kept the way it was. Git is simply not a suitable tool for this. ↫ Michal Necasek at OS/2 Museum The problems caused by dumping the code in git are quite real. Timestamps are not preserved, and the conversion to UTF-8 is deeply destructive, turning some parts of the code to literal gibberish. It’s a bit of a mess, and the people responsible for these release should be more careful and considerate.
Today, in partnership with IBM and in the spirit of open innovation, we’re releasing the source code to MS-DOS 4.00 under the MIT license. There’s a somewhat complex and fascinating history behind the 4.0 versions of DOS, as Microsoft partnered with IBM for portions of the code but also created a branch of DOS called Multitasking DOS that did not see a wide release. ↫ Scott Hanselman Not only did they release the source code to MS-DOS 4.00, they also released disk images of a very early version of Multitasking DOS, which did not see a wide release, as the article states. I’ve only vaguely heard of MT-DOS over the decades, so I had to do some minor reading and research to untangle what, exactly, MT-DOS really is. Much of this information is probably table stakes for the many older readers we have, but bear with me. MT-DOS, which has the official name MS-DOS 4.0 (often further specified by adding “multitasking” in brackets after the version number) was a version of MS-DOS developed by Microsoft based on MS-DOS 2.0, whose headlining feature was pre-emptive multitasking, which allowed specifically written applications to continue to run in a special background mode. Interestingly enough, it had to perform this multitasking with the same 640k memory limitation as other versions of DOS. Very few OEMs ended up licensing it, and most notably IBM wasn’t interested, so after one or two more OEM-specific versions, it was quickly abandoned by Microsoft. MS-DOS 4.0 (multitasking) is entirely unrelated to the “real” versions 4 of MS-DOS that followed later. The actual version 4 was called MS-DOS 4.00, and it’s the source code to this specific version that’s being released as open source today. MS-DOS 4.00 was quickly followed by 4.01 and 4.01a, but apparently OEMs would confusingly still label 4.01 disks as “MS-DOS 4.0”. The whole MS-DOS 4 saga is quite convoluted and messy, and I’m probably oversimplifying a great deal. Regardless, this code joins the open source releases of MS-DOS 1.25 and 2.0 that Microsoft released years ago.
William Brown, developer of webauthn-rs, has written a scathing blog post detailing how corporate interests – namely, Apple and Google – have completely and utterly destroyed the concept of passkeys. The basic gist is that Apple and Google were more interested in control and locking in users than in providing a user-friendly passwordless future, and in doing so have made passkeys effectively a worse user experience than just using passwords in a password manager. Since then Passkeys are now seen as a way to capture users and audiences into a platform. What better way to encourage long term entrapment of users then by locking all their credentials into your platform, and even better, credentials that can’t be extracted or exported in any capacity. Both Chrome and Safari will try to force you into using either hybrid (caBLE) where you scan a QR code with your phone to authenticate – you have to click through menus to use a security key. caBLE is not even a good experience, taking more than 60 seconds work in most cases. The UI is beyond obnoxious at this point. Sometimes I think the password game has a better ux. The more egregious offender is Android, which won’t even activate your security key if the website sends the set of options that are needed for Passkeys. This means the IDP gets to choose what device you enroll without your input. And of course, all the developer examples only show you the options to activate “Google Passkeys stored in Google Password Manager”. After all, why would you want to use anything else? ↫ William Brown The whole post is a sobering read of how a dream of passwordless, and even usernameless, authentication was right within our grasp, usable by everyone, until Apple and Google got involved and enshittified the standards and tools to promote lock-in and their own interests above the user experience. If even someone as knowledgeable about this subject as Brown, who writes actual software to make these things work, is advising against using passkeys, you know something’s gone horribly wrong. I also looked into possibly using passkeys, including using things like a Yubikey, but the process seems so complex and unpleasant that I, too, concluded just sticking to Bitwarden and my favourite open source TFA application was a far superior user experience.
Gentoo, the venerable Linux distribution which in my headcanon I describe as ‘classy’, has banned any use of “AI”. A proposal by Gentoo Council member Michał Górny from February of this year banning its use has been unanimously accepted by the Gentoo Council. The new policy reads: It is expressly forbidden to contribute to Gentoo any content that has been created with the assistance of Natural Language Processing artificial intelligence tools. This motion can be revisited, should a case been made over such a tool that does not pose copyright, ethical and quality concerns. ↫ Michał Górny We’ll have to see how this policy will be implemented, but I like that Gentoo is willing to take a stand.
It wasn’t too long ago that new Ubuntu releases were major happenings in the Linux world, as it was the default Linux distribution for many, both old and newcomers, in the desktop Linux space. These days, Ubuntu release hit a little different, with Canonical’s focus having shifted much more to the enterprise, and several aspects of the distribution being decidedly unpopular, like the snap package management system. Still, Ubuntu is probably still one of the most popular, if not the most popular, distributions out there, so any new release, like today’s Ubuntu 24.0 LTS, is still a big deal. Ubuntu Desktop brings the Subiquity installer to an LTS for the first time. In addition to a refreshed user experience and a minimal install by default, the installer now includes experimental support for ZFS and TPM-based full disk encryption and the ability to import auto-install configurations. Post install, users will be greeted with the latest GNOME 46 alongside a new App Center and firmware-updater. Netplan is now the default for networking configuration and supports bidirectionality with NetworkManager. ↫ Utkarsh Gupta on ubuntu-announce Of course, all the various other Ubuntu editions have also seen new releases: Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity, and Xubuntu. Yes, that’s a long list. They all mostly share the same improvements as Ubuntu’s main course, but paired with the latest versions of the respective desktop environments instead. Except for Kubuntu. Unlike just about any other major distribution released over the last few months, such as Fedora 40 only a few days ago, Kubuntu does not ship with the new KDE Plasma 6, opting for Plasma 5.27.11 instead. There simply wasn’t enough time between the release of Plasma 6 and the Ubuntu feature freeze, so they made the – in my opinion – understandable call to stick to Plasma 5 for now, moving Plasma 6 to the next release later this year.
Huawei plans to expand its native HarmonyOS smartphone platform worldwide, despite coming under US-led sanctions that have deprived it of access to key technologies. The Chinese tech megacorp released its own phone platform in 2019, the same year that US sanctions blocked Huawei from having further access to Google’s Android software to power its devices. More recently, the company saw its Mate 60 Pro smartphone become the top selling device in China’s huge consumer market, displacing rivals such as Apple’s iPhone. It also has a newer device, the Pura 70, that could pose a bigger threat to Apple sales in the country. ↫ Dan Robinson at The Register If there is one company that has the capabilities and will to truly offer a third alternative, it’s Huawei with HarmonyOS. This company has the full might of the Chinese state behind it, and it clearly has the drive to prove itself after the various sanctions levied against it in recent years that barred it from using Google’s Android. It’s obviously already experiencing major success in its home market, but now the company intends to go global, country by country, to positino HarmonyOS alongside iOS and Android. Huawei basically takes a brute-force approach, explaining that they identify the 5000 most popular applications, which they claim cover 99% of users’ time with their smartphones, and port those over first. I’m not entirely sure how they convince developers to port over their applications, but I’m guessing money is involved. Fair play, I would say – it’s not like anything else is going to break the stranglehold Apple and Google have over the mobile application market. We haven’t really spent much time talking about HarmonyOS in the west in general, and on OSNews in particular, which is a bit of a shame because it has some interesting characteristics. For instance, it has a multi-kernel design, where it uses the Linux kernel on more powerful devices like smartphones and tablets, and the RTOS LiteOS kernel on lower power IoT devices. DSoftBus is another interesting part of the operating system, which allows multiple devices to kind of join together and share data, applications, and control seamlessly. HarmonyOS supports both Android and true HarmonyOS applications, the latter of which are marked with a little logo in the corner of the application icon, but the unique features of HarmonyOS, like DSoftBus, are only accessible to true HarmonyOS applications. Developing these native applications can be done in DevEco Studio, which is built atop IntelliJ IDEA, using ArkUI. Huawei even went so far as to develop its own browser engine for HarmonyOS, which it recently released as open source, called ArkWeb. While HarmonyOS currently still supports running Android applications, this will soon no longer be the case as the company is working on HarmonyOS NEXT, which will remove Android compatibility to focus entirely on true HarmonyOS applications instead. NEXT also does away entirely with the multikernel approach, ditching both the Linux and LiteOS kernels for a new HarmonyOS microkernel, and uses Huawei’s own Cangjie programming language for application development. HarmonyOS NEXT is currently being tested on a variety of Huawei devices, with a beta and final release planned for later this year. It’s just our luck that the only potentially viable competitor to Android and iOS is a party closed-source operating system from China, which will surely bring with it a whole host of security concerns in the west. It’s really difficult at the moment to ascertain just how much of HarmonyOS – and specifically, HarmonyOS NEXT – is available as open source, which is a major bummer. I don’t think I’d ever want to use a (partly) closed source Chinese operating system for anything major in my life, but if it’s open source we could at least see non-Chinese forks that I’d find easier to trust. The road of iOS and Android competitors is littered with the bodies of failed attempts – Symbian, the various iterations of Windows Phone, BlackBerry, Sailfish, Ubuntu Touch, the GNOME/Plasma attempts that just can’t grow beyond proof of concepts – and there is no way to know if Huawei can pull off outside of China what it did with HarmonyOS inside China. Western markets are incredibly weary of anything related to Huawei, and for all we know, this operating system won’t ever even be allowed inside the US and the EU in the first place. Regardless of international politics and the CCP’s brutal, totalitarian, genocidal regime, HarmonyOS NEXT seems like a very interesting platform with fresh ideas, and I’d love to at least try it out once it hits international markets with proper localisation into English. I’ll take a problematic Chinese smartphone operating system competitor over no competitor at all – even if I won’t use it myself, it’ll be at least some form of competition both Apple and Google desperately need.
But just as smartphones would do, PDAs offered a dizzying array of operating systems and applications, and a great many of them ran Palm OS. (I bought my first Palm, an m505, new in 2001, upgrading from an HP 95LX.) Naturally, there’s no way we could enumerate every single such device in this article. So in this Ars retrospective, we’ll look back at some notable examples of the technical evolution of the Palm operating system and the devices that ran it—and how they paved the way for what we use now. ↫ Cameron Kaiser at Ars Technica This sure takes me back to my own in-depth Palm retrospective from – checks notes – 11 years ago (!). It turns out all the images from that article no longer load, so I should set aside some time to fix that up.
