Samba is "a free software re-implementation of the SMB networking protocol," according to Wikipedia. And now the Samba project "has secured significant funding (€688,800.00) from the German Sovereign Tech Fund to advance the project," writes Jeremy Allison — Sam (who is Slashdot reader #8,157 — and also a long standing member of Samba's core team): The investment was successfully applied for by [information security service provider] SerNet. Over the next 18 months, Samba developers from SerNet will tackle 17 key development subprojects aimed at enhancing Samba's security, scalability, and functionality.

The Sovereign Tech Fund is a German federal government funding program that supports the development, improvement, and maintenance of open digital infrastructure. Their goal is to sustainably strengthen the open source ecosystem.

The project's focus is on areas like SMB3 Transparent Failover, SMB3 UNIX extensions, SMB-Direct, Performance and modern security protocols such as SMB over QUIC. These improvements are designed to ensure that Samba remains a robust and secure solution for organizations that rely on a sovereign IT infrastructure. Development work began as early as September the 1st and is expected to be completed by the end of February 2026 for all sub-projects.

All development will be done in the open following the existing Samba development process. First gitlab CI pipelines have already been running and gitlab MRs will appear soon!
Back in 2000, Jeremy Allison answered questions from Slashdot readers about Samba.

Allison is now a board member at both the GNOME Foundation and the Software Freedom Conservancy, a distinguished engineer at Rocky Linux creator CIQ, and a long-time free software advocate.

An anonymous Slashdot reader writes: Haiku (the MIT-licensed operating system, inspired by BeOS) has released its fifth beta for Haiku R1.

Some new features include improved UI color management, improved dark mode coloring, Tracker improvements, TUN/TAP support for VPN connections, TCP throughput improvements, performance optimizations, UFS2 (BSD's filesystem) read-only support, new FAT filesystem driver, improved hardware support, improved POSIX compliance, improved performance, and more.
Slashdot has been covering the fate of the BeOS since 2000 (as well as the short-lived derivative project ZETA — and Haiku).

And now "With a history of over two decades and previously known as OpenBeOS, today's Haiku is pushing forward..." writes the site NotebookCheck: Haiku is a spiritual successor to BeOS, with a focus on a clean and user-friendly design paired with low system requirements. The minimum system requirements are still an Intel Pentium II/AMD Athlon CPU or better, at least 384 MB RAM, an 800x600 screen, and at least 3GB storage. It works on both 32-bit and 64-bit x86 PCs, and the 32-bit version can run many unmodified BeOS applications. It might be the best desktop open-source operating system not based on Linux or Unix... It works well in a virtual machine like VirtualBox or UTM.

Efforts to add Rust code to the Linux kernel has suffered a setback as one of the maintainers of the Rust for Linux project has stepped down -- citing frustration with "nontechnical nonsense," according to The Register: Wedson Almeida Filho, a software engineer at Microsoft who has overseen the Rust for Linux project, announced his resignation in a message to the Linux kernel development mailing list. "I am retiring from the project," Filho declared. "After almost four years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it's best to leave it up to those who still have it in them."

[...] Memory safety bugs are regularly cited as the major source of serious software vulnerabilities by organizations overseeing large projects written in C and C++. So in recent years there's been a concerted push from large developers like Microsoft and Google, as well as from government entities like the US Cybersecurity and Infrastructure Security Agency, to use memory-safe programming languages -- among them Rust. Discussions about adding Rust to Linux date back to 2020 and were realized in late 2022 with the release of Linux 6.1. "I truly believe the future of kernels is with memory-safe languages," Filho's note continued. "I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix."

Microsoft has decided to donate the Mono Project to the developers of Wine, FOSS that allows Windows applications to run on Unix-like operating systems. "Mono is a software platform designed to allow developers to easily create cross platform applications," notes GameOnLinux's Liam Dawe. "It is an open source implementation of Microsoft's .NET Framework based on the ECMA standards for C# and the Common Language Runtime."

"Wine already makes use of Mono and this move makes sense with Microsoft focusing on open-source .NET and other efforts," adds Phoronix's Michael Larabel. "Formally handing over control of the upstream Mono project to WineHQ is a nice move by Microsoft rather than just letting the upstream Mono die off or otherwise forked." Microsoft's Jeff Schwartz announced the move on the Mono website and in a GitHub post: The Mono Project (mono/mono) ('original mono') has been an important part of the .NET ecosystem since it was launched in 2001. Microsoft became the steward of the Mono Project when it acquired Xamarin in 2016. The last major release of the Mono Project was in July 2019, with minor patch releases since that time. The last patch release was February 2024. We are happy to announce that the WineHQ organization will be taking over as the stewards of the Mono Project upstream at wine-mono / Mono - GitLab (winehq.org). Source code in existing mono/mono and other repos will remain available, although repos may be archived. Binaries will remain available for up to four years.

Microsoft maintains a modern fork of Mono runtime in the dotnet/runtime repo and has been progressively moving workloads to that fork. That work is now complete, and we recommend that active Mono users and maintainers of Mono-based app frameworks migrate to .NET which includes work from this fork. We want to recognize that the Mono Project was the first .NET implementation on Android, iOS, Linux, and other operating systems. The Mono Project was a trailblazer for the .NET platform across many operating systems. It helped make cross-platform .NET a reality and enabled .NET in many new places and we appreciate the work of those who came before us.

Thank you to all the Mono developers!

In Communications of the ACM,/em>, long-time FreeBSD contributor Poul-Henning Kamp mocks the idea that the free and open-source software has "come apart" and "will end in tears and regret." Economists and others focused on money — like my bank — have had a lot of trouble figuring out the free and open source software (FOSS) phenomenon, and eventually they seem to have reached the conclusion that it just makes no sense. So, they go with the flow. Recently, very serious people in the FOSS movement have started to write long and thoughtful opinion pieces about how it has all come apart and will end in tears and regret. Allow me to disagree...
What follows is a humorous history of how the Open Source movement bested a series of ill-conceived marketing failures starting after the "utterly bad" 1980s when IBM had an "unimaginably huge monopoly" — and an era of vendor lock-in from companies trying to be the next IBM: Out of that utter market failure came Minix, (Net/Free/Open)BSD, and Linux, at a median year of approximately 1991. I can absolutely guarantee that if we had been able to buy a reasonably priced and solid Unix for our 32-bit PCs — no strings attached — nobody would be running FreeBSD or Linux today, except possibly as an obscure hobby. Bill Gates would also have had a lot less of our money...
The essay moves on to when "that dot-com thing happened, fueled by the availability of FOSS operating systems, which did a much better job than any operating system you could buy — not just for the price, but in absolute terms of performance on any given piece of hardware. Thus, out of utter market failure, the FOSS movement was born."

And ultimately, the essay ends with our present day, and the phenomenon of companies that "make a business out of FOSS or derivatives thereof..." The "F" in FOSS was never silent. In retrospect, it seems clear that open source was not so much the goal itself as a means to an end, which is freedom: freedom to fix broken things, freedom from people who thought they could clutch the source code tightly and wield our ignorance of it as a weapon to force us all to pay for and run Windows Vista. But the FOSS movement has won what it wanted, and no matter how much oldsters dream about their glorious days as young revolutionaries, it is not coming back; the frustrations and anger of IT in 2024 are entirely different from those of 1991.

One very big difference is that more people have realized that source code is a liability rather than an asset. For some, that realization came creeping along the path from young teenage FOSS activists in the late 1990s to CIOs of BigCorp today. For most of us, I expect, it was the increasingly crushing workload of maintaining legacy code bases...

An anonymous reader quotes a report from ZDNet, written by Steven Vaughan-Nichols: Hold onto your SSH keys, folks! A critical vulnerability has just rocked OpenSSH, Linux's secure remote access foundation, causing seasoned sysadmins to break out in a cold sweat. Dubbed "regreSSHion" and tagged as CVE-2024-6387, this nasty bug allows unauthenticated remote code execution (RCE) on OpenSSH servers running on glibc-based Linux systems. We're not talking about some minor privilege escalation here -- this flaw hands over full root access on a silver platter. For those who've been around the Linux block a few times, this feels like deja vu. The vulnerability is a regression of CVE-2006-5051, a bug patched back in 2006. This old foe somehow snuck back into the code in October 2020 with OpenSSH 8.5p1. Thankfully, the Qualys Threat Research Unit uncovered this digital skeleton in OpenSSH's closet. Unfortunately, this vulnerability affects the default configuration and doesn't need any user interaction to exploit. In other words, it's a vulnerability that keeps security professionals up at night.

It's hard to overstate the potential impact of this flaw. OpenSSH is the de facto standard for secure remote access and file transfer in Unix-like systems, including Linux and macOS. It's the Swiss Army knife of secure communication for sysadmins and developers worldwide. The good news is that not all Linux distributions have the vulnerable code. Old OpenSSH versions earlier than 4.4p1 are vulnerable to this signal handler race condition unless they are patched for CVE-2006-5051 and CVE-2008-4109. Versions from 4.4p1 up to, but not including, 8.5p1 are not vulnerable. The bad news is that the vulnerability resurfaced in OpenSSH 8.5p1 up to, but not including, 9.8p1 due to the accidental removal of a critical component. Qualys has found over 14 million potentially vulnerable OpenSSH server internet instances. The company believes that approximately 700,000 of these external internet-facing instances are definitely vulnerable. A patch, OpenSSH 9.8/9.8p1 is now available. Many, but not all, Linux distributions have made it available. If you can get it, install it as soon as possible. If for whatever reason you're not able to install a patch, Vaughan-Nichols recommends you set LoginGraceTime to 0 in the sshd configuration file and use network-based controls to restrict SSH access, while also configuring firewalls and monitoring tools to detect and block exploit attempts.

An anonymous reader quotes a report from ZDNet: At SUSECon in Berlin, SUSE, a global Linux and cloud-native software leader, announced significant enhancements across its entire Linux distribution family. These new capabilities focus on providing faster time-to-value and reduced operational costs, emphasizing the importance of choice in today's complex IT landscape. SUSE Linux Enterprise Server (SLES) 15 Service Pack (SP) 6 is at the heart of these upgrades. This update future-proofs IT workloads with a new Long Term Service (LTS) Pack Support Core. How long is long-term? Would you believe 19 years? This gives SLES the longest-term support period in the enterprise Linux market. Even Ubuntu, for which Canonical recently extended its LTS to 12 years, doesn't come close.

You may ask yourself, "Why 19 years?" SUSE General Manager of Business Critical Linux (BCL) Rick Spencer, explained in an interview that the reason is that on 03:14:08 Greenwich Mean Time (GMT, aka Coordinated Universal Time) Tuesday, January 19, 2038, we reach the end of computing time. Well, not really, but Linux, and all the other Unix-based operating systems, including some versions of MacOS, reach what's called the Epoch. That's when the time-keeping code in 32-bit Unix-based operating systems reaches the end of the seconds it's been counting since the beginning of time -- 00:00:00 GMT on January 1, 1970, as far as Linux and Unix systems are concerned -- and resets to zero. Just like the Y2K bug, that means that all unpatched 32-bit operating systems and software will have fits. The Linux kernel itself had the problem fixed in 2020's Linux 5.6 kernel, but many other programs haven't dealt with it. Until then, though, if you're still running SLES 15 SP6, you'll be covered. I strongly suggest upgrading before then, but if you want to stick with that distro to the bitter end, you can. The new SLES also boasts enhanced security features like confidential computing support with encryption in memory, utilizing Intel TDX and AMD SEV processors, along with remote attestation via SUSE Manager. Additionally, SLES for SAP Applications 15 SP6 offers a secure and reliable platform for running mission-critical SAP workloads, incorporating innovations from Trento to help system administrators avoid infrastructure issues.

Ancient Slashdot reader ewhac writes: On June 19, 1984, Robert Scheifler announced on MIT's Project Athena mailing list a new graphical windowing system he'd put together. Having cribbed a fair bit of code from the existing windowing toolkit called W, Scheifler named his new system X, thus giving birth to the X Window System. Scheifler prophetically wrote at the time, "The code seems fairly solid at this point, although there are still some deficiencies to be fixed up."

The 1980's and 1990's saw tremendous activity in the development of graphical displays and user interfaces, and X was right in the middle of it all, alongside Apple, Sun, Xerox, Apollo, Silicon Graphics, NeXT, and many others. Despite the fierce, well-funded competition, and heated arguments about how many buttons a mouse should have, X managed to survive, due in large part to its Open Source licensing and its flexible design, allowing it to continue to work well even as graphical hardware rapidly advanced. As such, it was ported to dozens of platforms over the years (including a port to the Amiga computer by Dale Luck in the late 1980's). 40 years later, despite its warts, inconsistencies, age, and Wayland promising for the last ten years to be coming Real Soon Now, X remains the windowing system for UNIX-like platforms.

Liam Proven reports via The Register: The latest version of the systemd init system is out, with the openly confrontational tag line: "Available soon in your nearest distro, now with 42 percent less Unix philosophy." As Lennart Poettering's announcement points out, this is the first version of systemd whose version number is a nine-bit value. Version 256, as usual, brings in a broad assortment of new features, but also turns off some older features that are now considered deprecated. For instance, it won't run under cgroups version 1 unless forced.

Around since 2008, cgroups is a Linux kernel containerization mechanism originally donated by Google, as The Reg noted a decade ago. Cgroups v2 was merged in 2016 so this isn't a radical change. System V service scripts are now deprecated too, as is the SystemdOptions EFI variable. Additionally, there are some new commands and options. Some are relatively minor, such as the new systemd-vpick binary, which can automatically select the latest member of versioned directories. Before any OpenVMS admirers get excited, no, Linux does not now support versions on files or directories. Instead, this is a fresh option that uses a formalized versioning system involving: "... paths whose trailing components have the .v/ suffix, pointing to a directory. These components will then automatically look for suitable files inside the directory, do a version comparison and open the newest file found (by version)."

The latest function, which The Reg FOSS desk suspects will ruffle some feathers, is a whole new command, run0, which effectively replaces the sudo command as used in Apple's macOS and in Ubuntu ever since the first release. Agent P introduced the new command in a Mastodon thread. He says that the key benefit is that run0 doesn't need setuid, a basic POSIX function, which, to quote its Linux manual page, "sets the effective user ID of the calling process." [...] Another new command is importctl, which handles importing and exporting both block-level and file-system-level disk images. And there's a new type of system service called a capsule, and "a small new service manager" called systemd-ssh-generator, which lets VMs and containers accept SSH connections so long as systemd can find the sshd binary -- even if no networking is available. The release notes are available here.

Michael 'Mike' Karels, one of the authors of "The Design and Implementation of the 4.4Bsd Operating System" and a part of the Computer Systems Research Group at Berkeley, who received the USENIX Association Lifetime Achievement Award, has died. Longtime Slashdot reader bplipschitz shared the news.

The FreeBSD Foundation issued a statement in memory of Karels: "We are deeply saddened about the passing of Mike Karels, a pivotal figure in the history of BSD UNIX, a respected member of the FreeBSD community, and the Deputy Release Engineer for the FreeBSD Project. Mike's contributions to the development and advancement of BSD systems were profound and have left an indelible mark on the Project. Mike's vision and dedication were instrumental in shaping the FreeBSD we know and use today. His legacy will continue to inspire and guide us in our future endeavors."

The Dillo browser dates back to 1999, writes the Register, with its own rendering engine. And now Dillo "has returned with a new release, version 3.1.

"It's nearly nine years after version 3.05 appeared on the last day of June 2015." Version 3.1 incorporates dozens of fixes and improvements, as the official announcement describes.

Project lead Rodrigo Arias Mallo announced his resurrection attempt on Hacker News early this year. He has taken the last available code from the project's Mercurial repository, incorporated about 25 outstanding fixes, and added as many again of his own.

Dillo is a super-lightweight graphical web browser for Unix-like OSes, written using the Fast Light Toolkit. The latest version has a number of new features, although one of the most significant is support for Transport Layer Security. TLS is the successor to SSL, with a Microsoft-approved name. Dillo 3.1 supports it thanks to the Mbed-TLS library.
It doesn't support frames, embedded media playback, or JavaSccript — but it can run on very low-end hardware...

Thanks to Lproven (Slashdot reader #6,030) for sharing the news.

An anonymous reader quotes a report from Foss Outpost: Systemd lead developer Lennart Poettering has posted on Mastodon about their upcoming v256 release of Systemd, which is expected to include a sudo replacement called "run0". The developer talks about the weaknesses of sudo, and how it has a large possible attack surface. For example, sudo supports network access, LDAP configurations, other types of plugins, and much more. But most importantly, its SUID binary provides a large attack service according to Lennart: "I personally think that the biggest problem with sudo is the fact it's a SUID binary though -- the big attack surface, the plugins, network access and so on that come after it it just make the key problem worse, but are not in themselves the main issue with sudo. SUID processes are weird concepts: they are invoked by unprivileged code and inherit the execution context intended for 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."

He's saying that sudo is a Unix concept from many decades ago, and a better privilege escalation system should be in place for 2024 security standards: "So, in my ideal world, we'd have an OS entirely without SUID. Let's throw out the concept of SUID on the dump of UNIX' bad ideas. An execution context for privileged code that is half under the control of unprivileged code and that needs careful manual clean-up is just not how security engineering should be done in 2024 anymore." [...]

He also mentioned that there will be more features in run0 that are not just related to the security backend such as: "The tool is also a lot more fun to use than sudo. For example, by default, it will tint your terminal background in a reddish tone while you are operating with elevated privileges. That is supposed to act as a friendly reminder that you haven't given up the privileges yet, and marks the output of all commands that ran with privileges appropriately. It also inserts a red dot (unicode ftw) in the window title while you operate with privileges, and drops it afterwards."

An anonymous reader shares a report: iPerf is a fairly popular cross-platform tool that is used by many to measure network performance and diagnose any potential issues in this area. The open-source utility is maintained by an organization called Energy Sciences Network (ESnet) and officially supports Linux, Unix, and Windows. However, Microsoft has now published a detailed blog post explaining why you should not use the latest version, iPerf3, on Windows installations.

Microsoft has highlighted three key reasons to discourage the use of iPerf3 on Windows. The first is that ESnet does not support this version on Windows, and recommends iPerf2 instead. On its website, ESnet has emphasized that CentOS 7 Linux, FreeBSD 11, and macOS 10.12 are the only supported platforms. Another very important reason not to use iPerf3 on Windows is that it does not make native OS calls. Instead, it leverages Cygwin as an emulation layer, which obviously comes with a performance penalty. This alone means that iPerf3 on Windows isn't really an ideal candidate for benchmarking your network. While Microsoft has praised the maintainers who are trying to get iPerf3 to run on Windows via emulation, another flaw with this approach is that some advanced networking options simply aren't available on Windows or may behave in unexpected ways.

Liam Proven reports via The Register: Bad news for those who want to play with OpenVMS in non-production use. Older versions are disappearing, and the terms are getting much more restrictive. The corporation behind the continued development of OpenVMS, VMS Software, Inc. -- or VSI to its friends, if it has any left after this -- has announced the latest Updates to the Community Program. The news does not look good: you can't get the Alpha and Itanium versions any more, only a limited x86-64 edition.

OpenVMS is one of the granddaddies of big serious OSes. A direct descendant of the OSes that inspired DOS, CP/M, OS/2, and Windows, as well as the native OS of the hardware on which Unix first went 32-bit, VMS has been around for nearly half a century. For decades, its various owners have offered various flavors of "hobbyist program" under which you could get licenses to install and run it for free, as long as it wasn't in production use. Since Compaq acquired DEC, then HP acquired Compaq, its prospects looked checkered. HP officially killed it off in 2013, then in 2014 granted it a reprieve and sold it off instead. New owner VSI ported it to x86-64, releasing that new version 9.2 in 2022. Around this time last year, we covered VSI adding AMD support and opening a hobbyist program of its own. It seems from the latest announcement that it has been disappointed by the reception: "Despite our initial aspirations for robust community engagement, the reality has fallen short of our expectations. The level of participation in activities such as contributing open source software, creating wiki articles, and providing assistance on forums has not matched the scale of the program. As a result, we find ourselves at a crossroads, compelled to reassess and recalibrate our approach."

Although HPE stopped offering hobbyist licenses for the original VAX versions of OpenVMS in 2020, VSI continued to maintain OpenVMS 8 (in other words, the Alpha and Itanium editions) while it worked on version 9 for x86-64. VSI even offered a Student Edition, which included a freeware Alpha emulator and a copy of OpenVMS 8.4 to run inside it. Those licenses run out in 2025, and they won't be renewed. If you have vintage DEC Alpha or HP Integrity boxes with Itanic chips, you won't be able to get a legal licensed copy of OpenVMS for them, or renew the license of any existing installations -- unless you pay, of course. There will still be a Community license edition, but from now on it's x86-64 only. Although OpenVMS 9 mainly targets hypervisors anyway, it does support bare-metal operations on a single model of HPE server, the ProLiant DL380 Gen10. If you have one of them to play with -- well, tough. Now Community users only get a VM image, supplied as a VMWare .vmdk file. It contains a ready-to-go "OpenVMS system disk with OpenVMS, compilers and development tools installed." Its license runs for a year, after which you will get a fresh copy. This means you won't be able to configure your own system and keep it alive -- you'll have to recreate it, from scratch, annually. The only alternative for those with older systems is to apply to be an OpenVMS Ambassador.

Slashdot reader Mononymous writes: The latest release of OpenBSD, the FOSS Unix-like operating system focused on correctness and security over features and performance, has been released. This version includes newer driver support, performance improvements, stability fixes, and lots of package updates. One highlight is a complete port of KDE Plasma 5.

You can view the announcement and get the bits at OpenBSD.org.
Phoronix reports that with OpenBSD 7.5 "there is a number of improvements for ARM (AArch64) hardware, never-ending kernel optimizations and other tuning work, countless package updates, and other adjustments to this popular BSD platform."

"After being in development since 2019, the huge NetBSD 10.0 is out today as a wonderful Easter surprise," reports Phoronix: NetBSD 10 provides WireGuard support, support for many newer Arm platforms including for Apple Silicon and newer Raspberry Pi boards, a new Intel Ethernet drive, support for Realtek 2.5GbE network adapters, SMP performance improvements, automatic swap encryption, and an enormous amount of other hardware support improvements that accumulated over the past 4+ years.

Plus there is no shortage of bug fixes and performance optimizations with NetBSD 10. Some tests of NetBSD 10.0 in development back during 2020 showed at that point it was already 12% faster than NetBSD 9.
"A lot of development went into this new release," NetBSD wrote on their blog, saying "This also caused the release announcement to be one of the longest we ever did."

Among the new userspace programs is warp(6), which they describe as a "classic BSD space war game (copyright donated to the NetBSD Foundation by Larry Wall)."

"On December 28 2023, bugreport 12604 was filed in the curl issue tracker," writes cURL lead developer Daniel Stenberg: The title stated of the problem in this case was quite clear: flag -cacert behavior isn't consistent between macOS and Linux , and it was filed by Yuedong Wu.

The friendly reporter showed how the curl version bundled with macOS behaves differently than curl binaries built entirely from open source. Even when running the same curl version on the same macOS machine.

The curl command line option --cacert provides a way for the user to say to curl that this is the exact set of CA certificates to trust when doing the following transfer. If the TLS server cannot provide a certificate that can be verified with that set of certificates, it should fail and return error. This particular behavior and functionality in curl has been established since many years (this option was added to curl in December 2000) and of course is provided to allow users to know that it communicates with a known and trusted server. A pretty fundamental part of what TLS does really.

When this command line option is used with curl on macOS, the version shipped by Apple, it seems to fall back and checks the system CA store in case the provided set of CA certs fail the verification. A secondary check that was not asked for, is not documented and plain frankly comes completely by surprise. Therefore, when a user runs the check with a trimmed and dedicated CA cert file, it will not fail if the system CA store contains a cert that can verify the server!

This is a security problem because now suddenly certificate checks pass that should not pass.
"We don't consider this something that needs to be addressed in our platforms," Apple Product Security responded. Stenberg's blog post responds, "I disagree."

Long-time Slashdot reader lee1 shares their reaction: I started to sour on MacOS about 20 years ago when I discovered that they had, without notice, substituted their own, nonstandard version of the Readline library for the one that the rest of the Unix-like world was using. This broke gnuplot and a lot of other free software...

Apple is still breaking things, this time with serious security and privacy implications.

jd (Slashdot reader #1,658) writes: The Register has been running a series of articles about the evolution of Unix, from humble beginnings to the transition to Plan9. There is a short discussion of why Plan9 and its successors never really took off (despite being vastly superior to microkernels), along with the ongoing development of 9Front.
From the article: Plan 9 was in some way a second implementation of the core concepts of Unix and C, but reconsidered for a world of networked graphical workstations. It took many of the trendy ideas of late-1980s computing, both of academic theories and of the computer industry of the time, and it reinterpreted them through the jaded eyes of two great gurus, Kenneth Thompson and Dennis Ritchie (and their students) — arguably, design geniuses who saw their previous good ideas misunderstood and misinterpreted.

In Plan 9, networking is front and center. There are good reasons why this wasn't the case with Unix — it was being designed and built at the same time as local area networking was being invented. UNIX Fourth Edition, the first version written in C, was released in 1973 — the same year as the first version of Ethernet.

Plan 9 puts networking right into the heart of the design. While Unix was later used as the most common OS for standalone workstations, Plan 9 was designed for clusters of computers, some being graphical desktops and some shared servers...

Because everything really is a file, displaying a window on another machine can be as simple as making a directory and populating it with some files. You can start programs on other computers, but display the results on yours — all without any need for X11 or any visible networking at all.

This means all the Unixy stuff about telnet and rsh and ssh and X forwarding and so on just goes away. It makes X11 look very overcomplicated, and it makes Wayland look like it was invented by Microsoft.

"As important as its historically underhanded business dealings were for its success, Microsoft didn't have to cheat to win," argues a new article in the Register.

"The Unix companies were doing a great job of killing themselves off." You see, while there were many attempts to create software development standards for Unix, they were too general to do much good — for example Portable Operating System Interface (POSIX) — or they became mired in the business consortium fights between the Open Systems Foundation and Unix International, which became known as the Unix wars.

While the Unix companies were busy ripping each other to shreds, Microsoft was smiling all the way to the bank. The core problem was that the Unix companies couldn't settle on software standards. Independent Software Vendors (ISV) had to write applications for each Unix platform. Each of these had only a minute desktop market share. It simply made no business sense for programmers to write one version of an application for SCO OpenDesktop (also known as OpenDeathtrap), another for NeXTStep, and still another one for SunOS. Does that sound familiar? That kind of thing is still a problem for the Linux desktop, and it's why I'm a big fan of Linux containerized desktop applications, such as Red Hat's Flatpak and Canonical's Snap.

By the time the two sides finally made peace by joining forces in The Open Group in 1996, it was too late. Unix was crowded out on the conventional desktop, and the workstation became pretty much a Sun Microsystems-only play.
Linux's GPL license created an "enforced" consortia that allowed it to take over, according to the article — and with Linus Torvalds as Linux's single leader, "it avoided the old Unix trap of in-fighting... I've been to many Linux Plumbers meetings. There, I've seen him and the top Linux kernel developers work with each other without any drama. Today's Linux is a group effort... The Linux distributors and developers have learned their Unix history lessons. They've realized that it takes more than open source; it takes open standards and consensus to make a successful desktop operating system.
And the article also points out that one of those early Unix desktops "is still alive, well, and running in about one in four desktops." That operating system, of course, is macOS X, the direct descendent of NeXT's NeXTSTEP. You could argue that macOS, based on the multi-threaded, multi-processing microkernel operating system Mach, BSD Unix, and the open source Darwin, is the most successful of all Unix operating systems.

"Bell Labs, the historic headwaters of so many inventions that now define our digital age, is closing in Murray Hill," writes journalism professor Jeff Jarvis (in an op-ed for New Jersey's Star-Ledger newspaper).

"The Labs should be preserved as a historic site and more." I propose that Bell Labs be opened to the public as a museum and school of the internet.

The internet would not be possible without the technologies forged at Bell Labs: the transistor, the laser, information theory, Unix, communications satellites, fiber optics, advances in chip design, cellular phones, compression, microphones, talkies, the first digital art, and artificial intelligence — not to mention, of course, many advances in networks and the telephone, including the precursor to the device we all carry and communicate with today: the Picturephone, displayed as a futuristic fantasy at the 1964 World's Fair.

There is no museum of the internet. Silicon Valley has its Computer History Museum. New York has museums for television and the moving image. Massachusetts boasts a charming Museum of Printing. Search Google for a museum of the internet and you'll find amusing digital artifacts, but nowhere to immerse oneself in and study this immensely impactful institution in society.

Where better to house a museum devoted to the internet than New Jersey, home not only of Bell Labs but also at one time the headquarters of the communications empire, AT&T, our Ma Bell...? The old Bell Labs could be more than a museum, preserving and explaining the advances that led to the internet. It could be a school... Imagine if Bell Labs were a place where scholars and students in many disciplines — technologies, yes, but also anthropology, sociology, psychology, history, ethics, economics, community studies, design — could gather to teach and learn, discuss and research.
The text of Jarvis's piece is behind subscription walls, but has apparently been re-published on X by innovation theorist John Nosta.

In one of the most interesting passages, Jarvis remembers visiting Bell Labs in 1995. "The halls were haunted with genius: lab after lab with benches and blackboards and history within. We must not lose that history."