Motif is great, I love how it looks and feels, and I want it to be actively maintained. I want a healthy ecosystem of Motif applications and even window managers and desktop environments, so I can run a real Motif environment. Sadly, while Motif has been open source for a while, the project itself stalled years ago, with little to no activity from anyone involved. That may be changing, as a number of developers decided to take matters into their own hands last year. This fork of Motif was born of a desire to keep Motif (and other X11 technologies) alive and well. The original upstream Sourceforge project hasn’t had any activity in over two years, none of the project admins have been active for at least that amount of time, the official bug tracker has disappeared into the void; and the user forum was closed way back in 2017. Sadly, it appears that the original upstream has abandoned the project. I’ve incorporated some fixes from upstream that have laid dormant for years, a few others from Gentoo, and made a few improvements of my own. I intend to maintain this fork, and in doing so advocate for the continued use of the user interface toolkit that defined an era, and influenced many of the user interfaces that came after it. ↫ Tim Hentenaar at the Motif fork’s GitHub page Some of the people involved are people I know online, so I have a bit of faith in this fork being able to stand the test of time, but of course, managing a complex project like this is hard, so who knows how long the enthusiasm remains. Still, this fork has seen five releases since its inception a little over a year ago, which seems promising. It may seem weird for some to have a love for Motif, but I’m the kind of person who installs weird, outdated corporate and industrial software I don’t understand on my HP c8000 dual PA-RISC workstation running HP-UX just to enjoy the Motif interfaces they sometimes ship. We all have our quirks. From my experiences talking to people online, I know there’s actually a rather solid number of people like me, and I hope that at some point the developers in this group can gain enough critical mass to build something like a basic Linux distribution or desktop environment using the disparate, actively-maintained Motif projects out there that yes, still exist. It’s a long shot, but in today’s computing landscape, where more and more people feel uncomfortable with “modern” software, I really feel like there’s a niche for something like this to exist. A really small niche, surely, but a niche all the same.
If you ask most people which operating system a racehorse uses, most of them would say none. And that’s quite explainable. Horse racing appears as an age-old sport, and on the surface at least, it appears as if it has nothing to do with technology. But in reality, horse racing has become one of the most tech-forward sports out there, with piles of data and information that are processed on every single race. Lightweight GPS units transmit a horse’s position while it’s running, databases process race information, and broadcast systems turn telemetry into graphics. Then we have wagering platforms that handle huge volumes of transactions on big events in the blink of an eye. So horse racing needs a powerful operating system that supports custom integrations and data processing. The truth is that beneath many systems like this sit technologies familiar to almost every modern software engineer, such as Linux. With that said, it is important to mention that racecourses and racing tech suppliers rarely publish a neat diagram highlighting the exact operating system that runs every server. So, let’s find out how Linux, Real-Time OS, and open-source software are helping the horse racing industry do its thing. The Horse Is Now a Moving Internet of Things Device First, let’s talk about how data is gathered and why horse racing companies actually need a good operating system. For instance, the Gmax Race system used by Total Performance data and Equibase places lightweight GPS trackers on horses and streams a bunch of information, including position, speed, stride length, running order, timing, and more. On top of that, this system is designed to operate without relying on ordinary cellular service or racecourse Wi-Fi, and its data can feed television graphics, display boards, and online visualizations. StrideSAFE goes a step further, but from a different, often more important perspective. It is designed to make horse racing safer for horses. Its three-ounce GPS and accelerometer unit collects around 2,400 movement data points per second while a horse races, which allows algorithms to examine even tiny changes in gait that would be extremely difficult to observe with the naked human eye. This technology is already used on big events like the Kentucky Derby and the Breeders’ Cup. But all of this data can also be used for Breeders’ Cup predictions. Expert handicappers often dig deep beneath the surface and want to see how a horse moves and performs before making a bet. Why Is the Software Important? A normal laptop can occasionally pause for an operating-system update without bringing Western civilization to an end. An embedded tracking device has less freedom. It has to wake sensors, timestamp measurements, process signals, manage wireless communication and keep doing those jobs predictably while the horse underneath it is travelling at racing speed. That is the world of real-time computing. A real-time operating system, or RTOS, is designed around predictable timing. Rather than concentrating primarily on giving a user a pleasant desktop experience, it makes sure important tasks happen within defined time constraints. Public documentation does not identify the specific embedded operating system inside Gmax or StrideSAFE units, so naming one would be speculation. But Total Performance Data itself has described embedded real-time systems as directly relevant to its technology. When former Google engineering executive Jeremy Doig joined TPD’s board, he specifically referred to applying his background in “embedded realtime systems” to the company’s live sports telemetry. Then the data leaves the horse and meets Linux. Once information reaches servers, the engineering environment starts looking much more recognisable. Linux has become a standard operating system for servers precisely because it is stable, configurable, and extremely well supported across networking, databases, and cloud infrastructure. Horse-racing companies do not universally reveal their server operating systems, but one unusually transparent example comes from specialist sports technology company Mustard Systems. A current engineering role for its horse-racing team lists a stack including Linux servers, Python, C, Go, PostgreSQL, RabbitMQ, and Kafka. Which makes sense. Racing software often has similar requirements: process large data feeds, store history, move messages rapidly between services, and keep systems available when demand spikes. Why Linux and Open Source Fit Racing So Well Final Thoughts The digital transformation of horse racing is quite easy to miss because the sport is wrapped around that traditional blanket that’s covering all the tech. But technology is already in horse racing, and the operating system is very important in order to process all of that information and make it understandable for humans.
AROS, the open source Amiga OS-compatible operating system, now has images available for the Raspberry Pi 3 (although some people state it also works on the Pi 4), in both 32bit and 64bit versions. According to the AROS team, they are quite stable, but not yet complete, so do know what you’re getting into. Dan Wood posted a YouTube video about these new images, providing much more insight into how well they work if you want more insight into how well they work. The images are, of course, the basic AROS operating system, so expect a rather barebones experience. If you’re used to some of the AROS distributions for x86, which come loaded with software and customisations, these images will feel quite bare to you. It’s going to take some time to port over all of these applications and customisations to the ARM version of AROS, but if and once that happens, I expect more complete images to appear as well. Great news for AROS and the Amiga community in general.
Ah, Japan’s TRON project – every few years someone discovers it anew and it bubbles back up the surface, and deservedly so, as it’s an incredibly interesting operating system project that, like so many others, deserved a better fate. There’s a version of computing history where the desktop OS that won wasn’t Windows. Not because the alternative was Unix-based or because Apple pulled off something different, but because an operating system designed at the University of Tokyo in 1984 was ambitious enough to try to replace the file system with a hypermedia document model, run on a custom Japanese CPU architecture, and encode 1.5 million characters, only to have a US trade report single it out as an unfair trade barrier in 1989. That project was TRON (The Real-time Operating system Nucleus), a real, government-backed Japanese computing initiative whose desktop variant, BTRON, was named in a US trade barrier report and effectively killed before it could reach schools nationwide. Meanwhile, its embedded counterpart, ITRON, quietly became one of the most deployed operating systems in history. TRON’s history has since attracted some genuinely wild conspiracy theories, including one claiming that Japan Airlines Flight 123 was deliberately crashed in order to target the TRON developers on board, despite there being no evidence that any TRON developers were even on the flight. But the strangest part of the story isn’t even a conspiracy theory: BTRON’s hypermedia desktop was decades ahead of what the market could support, and SoftBank founder Masayoshi Son may have helped sink it from the inside. ↫ Adam Conway at XDA The most interesting part of TRON for me was the different ways it treated files and documents compared to other operating systems. Instead of focusing on applications and files as the core interaction points for users, it focused on the document. While most operating systems associate specific files with specific applications, TRON associated individual components of documents with individual handlers. If you want to edit a Word document today, you open Word and do all your editing work inside Word, whether you’re editing blocks of text or an image, or you open entirely different applications when Word’s capabilities for a certain component in a document are too limited. In TRON, you’d open a document, and only once you wanted to edit specific components did it “open” an “application” to perform the editing, without actually leaving the document in question. Want to edit an image inside your document? In most operating systems, you’d have to open a separate image editor, load the relevant image file into it, make your edits, save the image file, and then paste said edited image file back into your document. There’s a considerable amount of overhead here that shouldn’t really exist; a computer is more than smart enough to open up just the editing controls from a different application if need be. In our current paradigm, applications often “solve” this by adding ever more features and controls and tools to cover every possible object or component you might have to deal with, but that just makes applications more complex, more bloated, and more difficult to use. TRON’s approach has been tried in a variety of times and places, but it never caught on. My personal pet theory is that the application-first model is far better at wealth extraction and concentration than TRON’s model, and as such, that’s what we ended up with. If a user’s document and all of its constituent parts are tied to and wrapped up into a single application from a single vendor, it’s much easier to control said user and extract wealth from them than when that user can just pick and choose whatever handler they want to use for whatever object they happen to run into in a document, without having to open tons of different applications and move, copy, and paste stuff all the time. In fact, this is also why consistency in user interface design is now all but dead; application developers and vendors use their own weird, non-standard, custom user interfaces for branding purposes. Sticking to a platform’s standards and conventions makes it harder to stand out and put your “brand” in people’s faces. But I digress. Regardless, I’m not sure if all the stories about the US trying to bury TRON have any real value to them, as even the article itself notes (undoing its own clickbaity headline) that the project already seemed to be in dire straights even before it got a buried mention in some trade document. On top of that, ITRON, the embedded TRON variant, survived and thrives to this very day, powering untold numbers of devices. It seems to have done quite well for itself, supposed US government intervention or no. This article by Steven J. Searle also takes a look at the workstation-focused variant of TRON.
So that is the whole pipeline exercised end-to-end. GrandSlam authenticates the Apple Account and obtains the IDS delegate. authenticateDS and id-register turn the Linux process into a registered Apple messaging identity. The Friends sequence attaches that identity to the existing accepted relationship. A missing-key SubscribeAndFetch makes the sharing device deliver its current P-224 key over APNs/IDS, inside a sender-verified P-256 NGM envelope. A second SearchParty fetch returns the encrypted report, and the P-224 key opens it locally. So yeah, in one sentence: authenticate to Apple’s private services, register the Linux machine as an IDS client, receive the existing Find My share key, and use it to fetch and decrypt a consented friend’s latest location. ↫ Zerotistic I wonder if it would be possible to build a proper third-party client for Apple’s Find My network like this, or if it would be trivial for the company to block it. I’m fairly sure quite a few people would love to be able to keep using Find My when moving away from Apple’s operating systems.
Weather data has become a quiet dependency in plenty of modern software. It turns up in mobile apps, desktop widgets, travel tools, smart-home systems, logistics dashboards, agriculture platforms, and automation scripts that need to react to real-world conditions. For developers, the hard part usually isn’t showing a temperature on a screen. It’s choosing a weather API that returns clean data, covers the right places, handles forecasts and historical records well, and fits the way the application is actually built. The best weather API depends on what the product needs to do. A weekend project might only need a generous free tier and simple JSON responses. A production dashboard may need global coverage, steady uptime, historical data, and formats that are easy to export or analyze. Location-aware apps add another layer, because weather data only becomes useful when it maps cleanly to the users, routes, assets, or regions the software is tracking. What Makes a Weather API Useful for Developers A useful weather API starts with the basics: accurate current conditions, sensible forecast ranges, clear documentation, and easy-to-work-with responses. JSON support is expected in most modern apps, but CSV exports, batch queries, and historical datasets can matter just as much for dashboards, analytics tools, and internal systems. The real test is how well the API fits into the rest of the software. Weather data often ends up inside mobile apps, dashboards, automation scripts, and background services, so it needs to behave like part of the application rather than a feed bolted onto the interface. That puts weather APIs in the same practical world as reliable API management, where data flows, response handling, and integration stability matter as much as the feature list. Developers should also look closely at rate limits, uptime expectations, licensing, attribution rules, and the depth of the API’s historical records. A small side project can survive a missing data point. A logistics dashboard, agricultural planning tool, or operations system needs more predictable behavior. The right API is the one that addresses both the app’s weaknesses and its features. Top Weather APIs for Location-Aware Apps 1. Visual Crossing Best for: Historical weather, forecasts, and analysis-ready data Visual Crossing is a strong overall pick for developers who need weather data that can support more than a basic forecast feature. It combines current conditions, forecasts, historical weather data, and export-friendly formats, making it useful for dashboards, planning tools, logistics systems, research projects, travel apps, and location-aware software. For developers building products around places, routes, assets, or regional conditions, the Visual Crossing global weather API gives applications a practical way to combine current conditions, forecasts, and historical weather across different locations and time periods. Its biggest strength is range. A consumer app might need current conditions and a clean forecast feed. A business dashboard might need historical weather by location or date range. A planning tool might need to compare weather patterns across regions. Visual Crossing fits those different workloads without treating weather as a decorative add-on. It is best suited for projects in which weather data is part of the application’s logic. 2. Open-Meteo Best for: Open-source projects and lightweight weather integrations Open-Meteo is a strong choice for developers who want a straightforward weather API without a heavy commercial setup. It is especially useful for hobby projects, prototypes, open-source tools, and smaller applications where simplicity matters more than enterprise features. Its appeal is directness. Developers can request forecast data without navigating a complicated onboarding process, and the API is easy to test when building small apps, dashboards, and automation scripts. That makes it a good fit for projects that need weather data quickly but do not require deep historical analysis, advanced commercial support, or complex operational forecasting. Open-Meteo works best when the project is lightweight and the requirements are clear. A personal weather widget, a simple travel planner, or a small location-based app can get plenty of value from it. For larger production systems, teams should still review limits, licensing, support expectations, and whether the available data matches the application’s long-term needs. 3. National Weather Service Best for: U.S. public weather data The National Weather Service is the best fit for developers building applications that rely on U.S.-specific weather data. It is especially useful for projects that need public forecasts, observations, alerts, and other weather information tied to American locations. The main advantage is credibility. For apps focused on U.S. users, the National Weather Service provides official public weather data to support civic tools, local dashboards, emergency planning systems, and regional automation. It is not the most flexible option for global applications, but it has a clear role when the software is built around U.S. weather conditions. Developers should treat it as a specialized option rather than a universal weather API. It works well for public-service tools, local weather displays, and U.S.-only applications, but international coverage, commercial support, and broader developer conveniences may require another provider. 4. OpenWeather Best for: General-purpose weather app development OpenWeather is one of the most familiar names in weather APIs, and it remains a practical option for developers who need standard weather data for apps, dashboards, and web tools. It works well for projects that need current conditions, forecasts, and common weather variables without having to build around a highly specialized data workflow. Its biggest strength is familiarity. Many developers have used OpenWeather in prototypes, tutorials, and production applications, which makes it easier to find examples and understand common integration patterns. That can be useful when a team wants a weather API that feels conventional and easy to explain. OpenWeather is best suited for straightforward weather features rather than analytics-heavy use cases. A mobile app, website forecast module, or simple dashboard can get plenty of value from it. Teams that need deeper historical datasets, heavy data exports, or specialized operational forecasting should compare it carefully against more analysis-focused providers. 5. WeatherAPI.com Best for: Straightforward app integrations WeatherAPI.com is a good fit for developers who want a simple way to add weather data to an app without
When I wrote about using Windows 11 for a month as part of the ongoing OSNews fundraiser (keep donating to get me to do the same for macOS!), one of the things I mentioned was that “the modern desktop context menu has its own classic Win32 context menu”. This is, in fact, a long-standing complaint I’ve repeatedly used as the perfect example of just how chaotic and low-quality Windows has become. Thankfully, and naturally I fully attribute this to my repeated complaints (*), Microsoft has been working on a brand new, faster, configurable context menu, and Neowin actually reviewed it. If you ask me, this revamped context menu addresses just about the biggest problem users had with the one in Windows 11, and that is the need to click through more buttons than necessary to do simple things like renaming a file or opening its properties. That problem is now basically gone. I have no issues with the new design. It looks modern, it feels more consistent with the rest of Windows, and even though all the new sections can still make it look a little busy, you now have the option to make it as simple or as button-packed as you want. That should cover most use cases and preferences well. I’d even say that when the new context menu becomes available to everyone, my guide on how to bring back the classic context menu might become obsolete. ↫ Ivan Jenic at Neowin The biggest reason I’m linking to this is not because I care about whatever monster of a context menu Windows users are having to deal with. No, I’m only linking to this because I never in my life imagined I’d be linking to a review of a context menu. I mean, at least it’s not the chess application icon. That would be embarrassing. I get a perverse sense of joy out of this.
A great and concise history of the run-up to MS-DOS 2.0. Yet, there was a nagging feeling that a single-tasking CP/M clone was inadequate for the new generation of personal computers. Digital Research released multi-user, multitasking MP/M-86 in September 1981 and announced the single‑user multitasking Concurrent CP/M in early 1982. In response, Microsoft came up with a plan for tiered approach to its operating systems: single-user/single-tasking MS-DOS at the bottom; multi-user/multitasking XENIX at the top; and in the middle, something called XEDOS: a single-user version of XENIX. This “pyramid of upward-compatible operating systems” was announced in a Byte Magazine editorial in January 1982. ↫ Nemanja Trifunovic I’ve always found this tiered approach fascinating, and the world surely would’ve looked quite different had Microsoft been able to make it work. I doubt Windows NT would ever have existed, and most of the world would probably be running a XENIX-based Windows today (all else being equal, which is of course unlikely and silly). Regardless, MS-DOS 2.0 contained a few UNIX-like utilities to deal with its brand new support for directory trees and other new features, and even had a /dev directory.
If you thought pervert glasses weren’t bad enough, Apple is taking it up a notch by adding cameras to its AirPods. Apple is working on camera-equipped AirPods that appear to be nearly ready to launch, based on a video MacRumors found in the macOS Tahoe 26.7 release candidate. In a short demo, a man holds a book up so the camera in the AirPods can see the title. “With Visual Intelligence, your world becomes savable. See something you like? Just ask me to save it for later,” says the voiceover text. ↫ Juli Clover at MacRumors AirPods are tiny. I’ve seen people use them at the gym. I’ve seen them on playgrounds. I’ve seen them around swimming pools. People use them at the beach. They’re used at schools. In locker rooms. Tiny cameras in tiny AirPods that can photograph anything in front of the user are a pervert’s wet dream. Abusers are going to love this. Why wear bulky glasses anyone can see and try to demand you take off, when you can wear tiny AirPods that have already been fully normalised in society? Was there not a single woman or parent on the team that made this? All over the United States, people are destroying Flock surveillance cameras. More and more communities are rising up and demanding these things removed from their streets and neighbourhoods. The awareness of just how pervasive mass government surveillance has become is growing, and Silicon Valley’s complicity is not exactly a secret. And in this climate of rapidly growing concern and anger, Apple is going to add tiny cameras to its tiny AirPods. Was there not a single person of colour or protester on the team that made this? How detached from reality do you have to be to greenlight something like this? Does anyone – regardless of skin colour, gender, or political leaning – want even more cameras around them?
I was around when Quake was launched, but I was entirely unaware of this story. By June 1996, after three years of hard work, id Software had completed their next title, Quake. As for their previous title, they were going to release both a shareware version and a full version of their game. Since it used a mere 22 MiB of storage, people at id Software had the idea of leveraging the remaining capacity of a CD-ROM. Why not include encrypted versions of the full id catalogue of games? Not only this would cut out the middlemen, it would give instant access to gamers with a simple phone call and a credit card. The concept was implemented. The CD was announced on July 3, 1996 and released on August 30th. The hacker group GNOMON released Quakecrk.zip only 39 days later. The archive contained QCRACK.EXE, a tool allowing to decrypt every single game on the CD-ROM. ↫ Fabien Sanglard The system id employed turned out to be incredibly primitive and simple, and hackers found out quite easily that the system required no secret sauce from id at all – the code you’d get over the phone contained no secret, and all the validation program on the disk did was check to ensure the code received over the phone matched the code generated by the disk. No wonder it took them only 39 days to crack this.
Earlier this year, Natalie Vock made a splash with a set of patches to the Linux kernel that greatly increased performance on AMD GPUs with lower amounts of VRAM. With that work now accepted by upstream, Vock decided to turn their attention to another interesting problem: what if you run out of VRAM, and how can we improve performance when we do? Regardless, what I hope this blogpost can demonstrate is that even if you end up with some memory evicted to system RAM, the slowdown can be manageable. There’s measures that drivers (particularly, the kernel driver) can take to make overcommit work as fast as possible, and even applications can do their part in coordinating with the driver stack to mitigate the effects of their memory being evicted. With everything in place, VRAM overcommit isn’t really as big of a deal as one may think it is at first sight. ↫ Natalie Vock The work Vock has done has already been in SteamOS for a while, and they’re currently in the process of upstreaming it to the vanilla kernel as well. Since this is a complex set of patches and changes, this may take a while, and as such, they’ve prepared custom kernel and Mesa branches for adventurous users. Do note that these branches won’t be maintained much, and are entirely experimental, not as well-tested as the SteamOS kernel, and probably won’t yield the same performance improvements. Still, this is the kind of work that has a material impact for users. Not everyone has a 16GB monster GPU, especially not today with supply chains ravaged and ruined by slopmakers, so it’s great to see the Linux world working to improve performance for everyone, not just the wealthy few.
The Touch Bar arrived in 2016 seemingly already pre-doomed, on a generation of machines that had a “we’ve run out of ideas” smell all around them. The arrow keys were reshaped, the keyboard got a slimming down, and even the beloved MagSafe wasn’t, in fact, safe. All of these changes would prove unpopular and get reverted in time, and the axe would eventually come for the Touch Bar, too. With an enormous benefit of hindsight, a decade after its arrival, and on the (rumored) eve of fully multitouch MacBooks, I wanted to look critically at the Touch Bar in more detail. I put a spicy title above this post, and while I’m not sure I can answer it in the affirmative, I feel I got surprisingly close to that. ↫ Marcin Wichary I have never spent this much reading about and pondering a technology seemingly nobody liked and that I never really used. I still think there’s merit to the idea of screen on a keyboard, but only if the screens are integrated into the individual keys (as some products have tried over the years). Of course, this would also be astronomically expensive, delicate, and virtually impossible to repair, so I’m not sure something like that can be reasonably made at an affordable price.
Version 7.2 of the Linux kernel has been released. Significant features in this release include common attributes support in the bpf()vsystem call, cache-aware load balancing for the CPU scheduler, large-folio support in the Btrfs filesystem, further swap subsystem improvements, improvements to the Landlock security module, support for block devices with inline encryption hardware via the dm-inlinecrypt device-mapper target, and much more. ↫ corbet at LWN.net If you run Linux, you’ll get it sooner or later.
We talked about the latest release of Delphi a few days ago, and that brought me to Hans Otten’s website. This site is about my experience with the Wirth school of languages, based on the ideas and implementations of Prof Niklaus Wirth, Kenneth Bowles, Per Brinch Hansen, colleagues, and their students. And my experience with the various variants, from the P2 and P4 compilers originating in Zürich ETH, via UCSD Pascal P-System to the Borland compilers and Modula and Oberon systems. All applicable to small computers and device control. On this website you will find information on Pascal for small machines, like Wirth compilers, the UCSD Pascal system, many scanned books and other files on UCSD Pascal, Pascal on MSX and CP/M, Delphi programming on PC, Freepascal and Lazarus on Windows and Raspberry Pi, Oberon systems. Many sources of early Pascal compilers! And last but not least my Pascal-M system! ↫ Hans Otten If you’re into Pascal and its related languages and technologies, this is a treasure trove of information.
One of the most surprising aspects of the Nix language is that it is lazy, especially if you have never used a lazy language before. This laziness is what makes much of Nixpkgs possible, and its complexity. I decided to take that idea and make the attribute path a sequence of button presses in Super Mario Bros. 3. Each node in the tree is a frame of the game, and each child is a button press that produces a new frame. Game states are recursive by nature. ↫ Farid Zakaria This has zero practical applications, and yet, it’s absolutely genius. I love this.
Today, you can get low-quality knockoffs of just about any popular smartphone on sites like AliExpress or Temu, whether they be iPhones, Galaxy phones, or whatever else. They have terrible build quality, bottom-of-the-barrel components and specifications, and all run outdated versions of Android – badly. At the same time, various consumer electronics brands, once popular in a bygone era, sell the rights to their brand name to unknown companies, who then put these brands on generic hardware to give their products a sheen of legitimacy. That’s why today, you can still buy Nokia smartphones, Polaroid cameras, and low-effort Hi-Fi equipment from various once-respected brands. None of this is new, however. In the late ’90s and early 2000s, companies were already doing the same thing. In fact, there’s one device from this era which combines both business practices – it’s both a cheap knockoff of a wildly successful device, and it carries a once-revered brand name. Also, just to add some juice, this story involves stolen source code. Let’s take a look at the worst PDA of all time, the Olivetti daVinci. In 1997, Palm launched the Palm Pilot, and it and its successors proved to be a massive hit. Where countless before it had failed, Palm found the magic formula to make pocket computing work. I wrote an in-depth article about Palm over 13 years ago which goes into much (much) more detail, but the reason the Palm Pilot succeeded where things like the Newton, PenPoint OS, and Windows for Pen Computing failed, is that Palm’s founder, Jeff Hawkins, realised that they were competing with paper, not with desktop computers. Instead of trying to shove the capabilities of a full personal computer into a (barely) pockatable device, a pocket computer had to be as fast and convenient as paper, and therefore extremely strict about which features to add, and which to omit. To this day, the entirety of smartphone computing stands on the shoulders of Palm. Palm’s ideas, implementations, approaches, paradigms, and even people were absorbed by Apple and Google, where they shaped both iOS and Android. The phone you’re looking at right now has a ton of Palm DNA in it, still. After all, you’re still using the homescreen-with-apps paradigm Palm already perfected in the late ’90s and early 2000s. The success of the Palm Pilot and its successors did not go unnoticed. Microsoft, most prominently, felt incredibly threatened by Palm’s success: The success of Palm’s products got the attention of Microsoft, and the company pretty much announced it was going to crush Palm. According to Hawkins, Microsoft had a sales conference, where, at some point, a big target appeared on the projector screen, with the Palm logo dead in the centre of it: “we are going to crush and kill these guys”, was the central message. Hawkins recalls that he got condolence letters after that, stating things like “Sorry Jeff. Too bad.” ↫ Thom Holwerda While Microsoft proved to be unable to “kill and crush” Palm, it did manage to build a relatively successful business selling PDAs running various incarnations of Windows CE. Together, Palm and Microsoft dominated the PDA market pretty much throughout its entire existence, and while the market was a mere fraction of the smartphone market of today, other companies still wanted a piece of this pie too. One of these companies was Olivetti, a storied Italian company with a long history making typewriters, computers, and other electronics. I’m not going into detail about Olivetti’s history, but the company was renowned for its attention to design, creating iconic products like the Lexikon 80, Lettera 22, Elea 9003, Programma 101, and so, so many more. Olivetti also entered the personal computer market, first with a variety of custom machines featuring Z80 and later Motorola 68000 processors running a variety of custom operating systems developed by Olivetti (including its own UNIX variant, X/OS). After a few machines using MIPS and Alpha processors in the early ’90s, the company would eventually focus entirely on Intel-based PCs (including this amazing failure) running Windows. Like so many other computer makers from that era, Olivetti eventually left the PC business by selling it off in 1997. To this day, Olivetti PCs tend to cost more on the used market than those from other brands, despite no technical merits dictating so. At around this time, our current story begins. Seeing the success of the Palm Pilot and the emergence of copycat devices running Microsoft’s Windows CE, Olivetti wanted in on the action. And so, in the late ’90s, the company introduced the Olivetti daVinci, a line of PDAs whose software looked suspiciously like Palm OS. There’s not a ton of information out there about the development history, but it seems that while Olivetti designed the hardware, it contracted the development of the operating system out to a company from Hong Kong, Echolink Design. And this is where things went horribly wrong for Olivetti. The software Echolink Design developed for the daVinci didn’t just look like Palm OS, it was Palm OS – at least, according to Palm. After being on the market for about a year, the Palm Pilot maker, then a subsidiary of 3Com, filed for an injunction, alleging that the daVinci operating system designed by Echolink Design contained actual Palm OS source code. In addition, Palm also filed suit against CompanionLink Software, the company that developed the Outlook synchronisation software for the daVinci. Palm won handily, and within a day of the filing, temporary restraining orders were put in place on both Olivetti and CompanionLink, stopping sales of the daVinci and its software dead in its tracks. It seemed to have been a pretty clear-cut case. From The Wall Street Journal at the time: U.S. District Judge James Ware ruled Olivetti’s Royal daVinci organizer contains software that appears to have been copied from the operating system for 3Com’s Palm organizers. Judge Ware said a review by a software expert found the daVinci software contains private Palm code and even grammatical
In the last few days, I built a shoot ’em up game by embedding a tiny custom bytecode VM and rendering the graphics using a fullscreen pixel shader. The result is a 3kB Windows executable. This was done for Langjam Gamejam, a 7-day challenge where you create a programming language and then use it to build a game. The project combines several interests of mine: language tooling, game development, procedural graphics, and demoscene-style size constraints. The game jam format forced me to keep the scope small and explore new ideas. Also, it was fun! ↫ Laurent Le Brun In seven days, Le Brun created a brand new programming language, compiler, bytecode interpreter, a game written in the new language, and rendered it, ending up with a 3kB self-contained executable. It’s amazing what humans can do.
A while back, when chatting with a colleague over their computer, I noticed that a logo did not look exactly the same as it did on mine. It looked thinner on theirs and more faithful to the original image. It was rendered at 15px; here is an upscaled version. If you squint, or take a step back, the one from Chrome looks thicker. A bit weird, but swapping the image for an SVG fixed it. Still, I was curious: why was it rendering like this in the first place? I did some digging and found a nifty optimization that Chrome uses when rendering JPEGs at small scales. ↫ Guillaume Técher I love it when people detail their discoveries like this.
Another month started almost two weeks ago, so we’ve got a new monthly report from Redox, the general purpose operating system written in Rust. The month of July – it seems the report was published with a bit of a delay, regardless of what the date on their site says – brought improvements to the installer, with new options commonly found in most installers, such as a choice of installation method, network-based installation, and more. The Google Summer of Code work on the new CPU scheduler has also been merged, including a number of related performance enhancements. There’s improvements to the ARM port, Amlogic Meson UART ARM64 support, and uutils grep and sed have been successfully built on Redox, replacing their their GNU counterparts in the os-test test suite. In addition, a whole slew of demos were ported as well, from Ratatui demos to various Iced demos covering things like reading QR codes and processing Markdown. Of course, this is all topped off with the usual long list of lower-level, smaller changes and improvements to the kernel, drivers, Relibc, and more.
The OSNews Fundraiser, to celebrate the fact I posted 20000 stories in 21 years, is still underway. The first major incentive was reached, and I, a long-time Linux user, published my experiences using Windows 11 for a month. It wasn’t a success. Keep donating if you want to find out what a Linux user thinks of the current state of macOS! Why support OSNews? I want to make sure I can run OSNews for another two decades and another 20000 posts, and I need your help to do so. Since my wife, who has a tough, underpaid job in elderly care, is largely unable to work due to health reasons caused by that very same job, my income has become a lot more crucial for our kids, my wife, and myself. With OSNews readers being more skeptical of subscription-like things like our Patreon than most people, it’s exactly these one-time donations that make up the bulk of your support. Thank you.
