Diag| Considering item [tag:pappp.net,2026-08-16:/2505129] "Access to telemetry data: Automotive industry criticizes intelligence reform"
Diag| Considering item [tag:pappp.net,2026-08-12:/2504187] "License plate reader searches should require a warrant"
Diag| Considering item [tag:pappp.net,2026-08-07:/2502960] "2027 memory capacity is reportedly sold out"
Diag| Considering item [tag:pappp.net,2026-08-05:/2502506] "Sycophantic AI Decreases Prosocial Intentions and Promotes Dependence (2025)"
Diag| Considering item [tag:pappp.net,2026-08-04:/2502146] "All of Winona Police Department's Flock cameras cut down and stolen"
Diag| Considering item [tag:pappp.net,2026-08-03:/2501883] "Celebrating 45 Years of Kermit with the First New C-Kermit Release in 15 Years"
Diag| Considering item [tag:pappp.net,2026-08-02:/2501525] "MkLinux and the pimped-out Apple Workgroup Server 9150"
Diag| Considering item [tag:pappp.net,2026-08-02:/2501516] "ASRock BC-250: Building the Budget Steam Machine"
Diag| Considering item [tag:pappp.net,2026-07-31:/2501295] "Google plans to exempt sanctioned nations from Android developer verification"
Diag| Considering item [tag:pappp.net,2026-07-28:/2500259] "College prof hides prompt to catch AI cheaters, finds human nature is pretty much as we thought"
Diag| Considering item [tag:pappp.net,2026-07-28:/2500268] "Now is the time to give LLMs access to the ACM digital library"
Diag| Considering item [tag:pappp.net,2026-07-22:/2498801] "John C. Dvorak has died"
Diag| Considering item [tag:pappp.net,2026-07-22:/2498669] "Passkeys were invented by engineers with zero understanding of consumer brain"
Diag| Considering item [tag:pappp.net,2026-07-19:/2497943] "Automated Pressure Advance Using a Bed-Leveling Sensor"
Diag| Considering item [tag:pappp.net,2026-07-19:/2497945] "Building an Arch Linux Aarch64 Port for Holo Core"
Diag| Considering item [tag:pappp.net,2026-06-18:/2488796] "What was nice about the UI of Windows 2000"
Diag| Considering item [tag:pappp.net,2026-06-17:/2488496] "Lore – Open source version control system designed for scalability"
Diag| Considering item [tag:pappp.net,2026-06-16:/2488199] "Linux kernel 7.1 sends Intel 486 support to silicon heaven"
Diag| Considering item [tag:pappp.net,2026-06-15:/2487839] "Fox is buying Roku"
Diag| Considering item [tag:pappp.net,2026-06-14:/2487662] "Any road followed precisely to its end leads precisely nowhere."
Diag| Considering item [tag:pappp.net,2026-06-19:/2489115] "I used sound waves to make espresso"
Diag| Considering item [tag:pappp.net,2026-06-10:/2486637] "German court rules Google is liable for whatever Google’s “AI” generates"
Diag| Considering item [tag:pappp.net,2026-06-01:/2484373] "Microsoft is intentionally bricking all Office for Mac 2019/2021 installations"
Diag| Considering item [tag:pappp.net,2026-06-01:/2484272] "Nvidia's Grace Blackwell superchips are officially coming to the PC with RTX Spark notebooks"
Diag| Considering item [tag:pappp.net,2026-05-30:/2483921] "Adding Linux support back for the BASIC (free) version of Vivado"
Diag| Considering item [tag:pappp.net,2026-05-30:/2483835] "Proposed new US funding rules: We can cancel any grant at any time"
Diag| Considering item [tag:pappp.net,2026-05-27:/2483228] "The exemptions in age-verification laws for open source operating systems are bad, actually"
Diag| Considering item [tag:pappp.net,2026-05-31:/2484064] "Mysteries of the Griffin iMate"
Diag| Considering item [tag:pappp.net,2026-05-23:/2482255] "AMD (Xilinx) is Excluding Linux From the Free Tier For Its FPGA Dev Tool"
Article note: It has always been bullshit to technologically and FUD harass things-not-Microsoft on PC-like platforms, not an actual security feature.
If they ever actually revoke issued keys, they brick deployed systems and get blowback.
An industry-wide standard Microsoft invented to protect Windows, and later Linux, devices from firmware infections has been trivial to bypass for 13 of its 14 years of existence. The discovery was made by researchers at security firm ESET after identifying 11 firmware images, at least one from 2013, that were known to be defective but remained signed by the software company anyway.
The images are known as shims, which were invented to extend Secure Boot to Linux devices and utility software. Using a technique simple enough to be performed by novice hackers, these old, forgotten shims can be used to completely circumvent the protection, which is embedded into the UEFI (Unified Extensible Firmware Interface) of the device's motherboard. The gaffe is the result of the failure by Microsoft, which oversees the signing of shims, to revoke the publicly available images once vulnerabilities were found in them.
Threat extends to Windows and Linux users
The threat extends to Windows and Linux users alike, since the shim can be installed on devices running both operating systems. From there, an attacker can subvert the mandated chain of digitally signed firmware to install malicious firmware that loads early in the boot process and persists after either the OS is reinstalled or a hard drive is replaced.
Article note: I hate to "please do extra work I'm not volunteering to do" this, but I'm curious how compositors other than kwin_wayland (tested here, also my usual environment lately for this and other reasons) do. The compositor to compositor platform inconsistency in wayland is still a nuisance.
Article note: Oh boy, fingerprinting that will get human Linux users treated like scrapers, being called out by a scraper vendor.
AI fuckers continuing to ruin everything.
Article note: I love how people periodically figure this out. In the "Big Data" boom era it was usually "Laptop with basic unix utility pipeline beats hadoop cluster" but the principle is the same: Distributed systems are fucking expensive, deeply fiddly methods of last resort when you can't do what you need any other way, and are willing to pay for massive amounts of hardware and engineering.
Getting local parallelism right is hard enough.
I've spent plenty of time helping wrangle problems on to clusters, and increasingly my impulse is "probably don't" for any problem that isn't inherently embarrassingly parallel (island GA, mote carlo trials, etc.)
Article note: Neat! It's amazing how many "Still chasing the same dream 50 years later" things there are in computing, and how little attention people pay to the previous attempts.
For the first time, the source code of KSOS, backed by the US Department of Defense in the late 1970s and 1980s, is available to the public in the archives of The Unix Heritage Society (TUHS). TUHS volunteers preserve the historical source code and documentation of the original UNIX – or as much of it as is left. A few days ago, in an email to its mailing list, TUHS founder Warren Toomey announced the addition of KSOS to the collection. "KSOS was the US Department of Defense (DoD) Kernelized Secure Operating System (KSOS, formerly called Secure UNIX). KSOS is intended to provide a provably secure operating system for larger minicomputers," he wrote. Despite its age, KSOS sounds surprisingly modern. It was a Unix-compatible OS, implemented in a type-safe programming language, Modula, rather than C. Modula was the late great Niklaus Wirth's successor to Pascal and, in turn, the forerunner to Modula-2 – which we described when it was added to the GNU Compiler Collection in 2022. KSOS was designed to be formally verifiable, so that it could be trusted for use in highly secure systems. It ran on commodity hardware, and its development was sponsored by the US DOD. Very few OS kernels have been formally verified, and one of the best-known modern examples is the seL4 microkernel, as used in the Ironclad OS we covered last year, and also in the new QSOE RISC-V RTOS. KSOS isn't some cutting-edge experimental new Rust effort, like the Asterinas project we described last year or the even newer Maestro project. What became KSOS started in 1978 at Ford Aerospace (yes, that Ford). On the team were Peter Neumann, who later ran the RISKS Digest – The Register was quoting him in 2004 – and Tom Perrine, who described it and its modern relevance in a 2002 article for the USENIX journal ;login:. It's titled "The Kernelized Secure Operating system (KSOS)" [PDF], and at only three and a bit pages long, it's well worth a read. Even then, 24 years ago, projects were struggling to reinvent things KSOS did successfully a couple of decades earlier. That's even more true today. To learn more about how KSOS worked, there's a 1978 Executive Summary [PDF] – which, despite its title, runs to 15 pages. Clearly, executives back then had longer attention spans. Perrine gave a talk about KSOS at DEF CON 20 in 2012, which you can watch on YouTube. KSOS isn't forgotten. For instance, it came up in a talk at last year's FOSDEM: Confidential Computing's Recent Past, Emerging Present, and Long-Lasting Future. Page 8 of the slide deck [PDF] says KSOS was "among the first security-focused kernels, emphasizing formal verification" and "source code was publicly available, rejecting 'security through obscurity.'" KSOS was not confined to academic research. It was used in production. Last October, Perrine explained more in another TUHS email: "KSOS – for PDP-11, originally developed by Ford Aerospace, and then extended at Logicon. It did have a supervisor-mode UNIX-system-call-compatible system. Later, there was also a userland library that implemented something that mostly matched the UNIX system calls. It had no kernel code in common with UNIX. It was written in Modula. "KSOS was used in the Trusted Downgrade System of the multi-level-secure 'all-source' intel fusion system that Logicon built for a few agencies. ACCAT-GUARD and USAFE-GUARD, for example. "KSOS-32 – a VAX 'port' of KSOS (which was then retconned as 'KSOS-11'). The Modula code from -11 was run though Emacs macros to produce Modula-2, and then parts were rewritten as needed. "I worked on both systems at Logicon." It's Perrine we have to thank for KSOS reappearing in public view after 38 years – he found an old tarball of the source code, and with the help of John O Goyo and Thalia Archibald, it made its way to the TUHS code archive. Now there’s a new quest: find the original compiler used to build it. One thing that may help slightly is that KSOS was not self-hosting: it was compiled under UNIX. We have mentioned TUHS's important work before: for instance, when a tape of UNIX V4 was found in University of Utah boffin Robert Ricci's department — and successfully recovered. Bootnote Mr Goyo also found time to email The Reg FOSS desk about the recovery, for which we thank him. ®
Article note: What year is it? They had most of their claims dismissed, lost on standing, lost on merits, lost their parallel case with Novell, have been sold twice, but are apparently still trying to troll. 23 years later.
The (notional) roots are Project Monterey, which was a 90s/early 2000s unified UNIX project that was doomed from the start, flopped, and was caught up in the Itanium failbus.
The ancient dispute over ownership of UNIX, and perhaps Linux too, has returned to court. Again. As The Register has explained many, many, times since this matter first went to court in 2003, the roots of the case are the 1998 alliance between IBM and a company called the Santa Cruz Operation which sold a version of UNIX for x86 CPUs. Those two companies, plus Intel and Sequent, created “Project Monterey” – an effort to create a unified version of UNIX that could run on multiple processors. By 2001, Project Monterey was close to delivering a unified UNIX, an achievement made possible by blending code from IBM and SCO. By then, a little project called “Linux” already ran on multiple processors. Big Blue decided Linux was the future and bailed from Project Monterey – then allegedly contributed some Monterey code to the open-source project and to its own AIX and Z operating systems. SCO felt it owned some of that code, so sued IBM. SCO and its successors struggled to survive, but interested parties kept the lawsuit alive because the chance to emerge as owner of parts of the Linux codebase, and IBM’s code, had the potential to turn into a colossal payday. The case and its successors ended in 2021, with a settlement that saw litigants agree to end the matter without IBM admitting fault. But by then, SCO had sold its software to a biz called Xinuos that decided to fight on. The Xinuos case has burbled along quietly since, and on June 22nd reached the milestone of a hearing. The matter has become a little more modern, if only because this hearing was held online and the presiding judge appeared to unwittingly be on mute at one point. But the arguments otherwise seemed to revisit Project Monterey, debated the relevance of past litigation, contested who owned what, when they owned it, and how they could prove it. Xinuos argued IBM never had a license for SCO code. Big Blue argued that it did nothing wrong. The core issue seems to be whether Xinuos even has the right to litigate the matter, or if some ancient legalese in the original agreements means the window for legal argument has long since expired. The matter continues and appears likely to do so until either the heat death of the universe or the year of Linux on the desktop – whichever comes sooner. ®
Article note: Brought to you by the people who are retroactively deleting hundreds of movies from customer libraries. I'm so glad I grew up before this kind of bullshit was feasible enough to be normalized.