OSnews

This article is a partial-rebuttal/partial-confirmation to KGOnTech's Apple Vision Pro's Optics Blurrier & Lower Contrast than Meta Quest 3, prompted by RoadToVR's Quest 3 Has Higher Effective Resolution, So Why Does Everyone Think Vision Pro Looks Best? which cites KGOnTech. I suppose it's a bit late, but it's taken me a while to really get a good intuition for how visionOS renders frames, because there is a metric shitton of nuance and it's unfortunately very, very easy to make mistakes when trying to quantify things. This post is divided into two parts: Variable Rasterization Rate (VRR) and how visionOS renders frames (including hard numbers for internal render resolutions and such), and a testbench demonstrating why photographing the visual clarity of Vision Pro (and probably future eye tracked headsets) may be more difficult than a DSLR pointed into the lenses (and how to detect the pitfalls if you try!). Shiny Quagsire I did it. I think I managed to find an article that isn't just over my head, but also over most of your heads. How's that feel?

Window management in Emacs gets a bad rap. Some of this is deserved, but mostly this is a consequence of combining a very flexible and granular layout system with rather coarse controls. This leaves the door open to creating and using tools for handling windows that employ and provide better metaphors and affordances. As someone who's spent an unnecessary amount of time trying different approaches to window management in Emacs over the decades, I decided to summarize them here. Almanac might be overstating it a bit - this is a primer to and a collection of window management resources and tips. Karthik Chikmagalur I honestly had no idea Emacs was this... Advanced, complex, and feature-laden. I mean, I thought Emacs' complexity was just a meme, but reading this article it seems the memes don't do it justice.

Disassembly and enhancements for Apple II DeskTop (a.k.a. Mouse Desk), a Finder"-like GUI application for 8-bit Apples and clones with 128k of memory, utilizing double hi-res monochrome graphics (560*192), an optional mouse, and the ProDOS 8 operating system. Apple II DeskTop GitHub page The goal of this project is to reverse-engineer Apple II DeskTop, and fix bugs and enhance it in the process. I didn't actually know that the Apple IIgs initially shipped with this instead of the 16 bit GS/OS, which is the operating system I personally associate with the IIgs. Apple II DeskTop was largely 8 bit, and built on top of ProDOS 16, and didn't really take full advantage of the IIgs hardware. It wasn't until version 4.0 of the system software that the IIgs switched over to GS/OS. The latest release is v1.4-alpha9, released a few days ago. Apple II DeskTop is still entirely compatible with Apple II machines and clones from before the IIgs, as well, and it runs in emulators, too. We actually already covered this project a few years ago, but a reminder that this exists never hurt anyone.

If you remember a time when using floppy disks didn't seem weird, you're probably at least 30 years old. Floppy disks or diskettes emerged around 1970 and, for a good three decades or so, they were the main way many people stored and backed up their computer data. All the software and programmes they bought came loaded onto clusters of these disks. They are a technology from a different era of computing, but for various reasons floppy disks have an enduring appeal for some which mean they are from dead. Chris Baraniuk at the BBC Articles such as these in more mainstream media are always incredibly odd to me. Nobody bats an eye at someone lovingly maintaining a classic car, or restoring an old house, or a group of people petitioning a local government to not demolish a beloved old building or whatever, but as soon as computer technology is involved, so many people find it incredibly weird that classic computer technology, too, can be worth saving. It highlights how society views technology - disposable, replaceable, worthless, to be dumped and forgotten about as soon as something newer comes along. Even after at least two decades of articles like this, they keep being essentially republished with the same words, the same storylines about these weird people who keep using - get this! Look at these idiots! - older technology when faster, newer, shinier stuff is readily available. I'm glad the retrocomputing community seems to be growing by the day, and there's now definitely a large enough internationally connected group of people and organisations to maintain our old computers and related hardware and software.

Starting in the release 560 series, it will be recommended to use the open flavor of NVIDIA Linux Kernel Modules 119 wherever possible (Turing or later GPUs, or Ada or later when using GPU virtualization). NVIDIA developer forums Slowly but surely, NVIDIA is taking a more favourable position towards open source. It still feels surreal.

So I got accepted into GSoC again! I'm going to be working on WebKit2. But what is WebKit2, or even WebKit, for that matter? Well, WebPositive uses WebKit to render its web pages. Currently, we use the WebKitLegacy API to communicate with WebKit. It would be nice to switch to the newer version: WebKit2. However, our port of WebKit2 still needs work. At present, it has lost its ability to even render any webpage at all! So, getting WebKit2 to work will be the primary goal of my GSoC project. If there's time left, I might be able to integrate it into WebPositive. The advantages WebKit2 has for WebPositive will be mostly invisible to end-users. The code will hopefully be more maintainable than the deprecated WebKitLegacy and we'll get access to several newer APIs such as the ad-blocking API. Perhaps the most visible change: problems in one part of the code should be less likely to crash the whole browser. Zardshard on the Haiku website The current state of WebPositive, the only native Haiku web browser, is emblematic of why I have personally lost all interest in the successor to what is still my favourite operating system of all time. Haiku OS supports several browsers, and if you read any forum post about which browser to use, or watch any of the enthusiastic Haiku videos by the insanely awesome Action Retro, they'll all advise you to use any of the non-native Qt or GTK browsers instead - because WebPositive just can't compete with the ported, non-native browsers. Since everybody using Haiku is opting to use the better ported browsers, WebPositive has fallen even more by the wayside; now it has to play catch-up, and by the time WebKit2 has been properly ported and bug-tested, and has been integrated into WebPositive, which then has to be bug-tested as well, we're going to be months, if not years, down the line. In the meantime, the ported browsers will have been regularly updated with newer, better versions. Unless the focus for the single most important application of any general purpose desktop operating system is placed solely on WebPositive, it simply won't be able to keep up with the ported browsers. Why even work on WebPositive at all at that point? It's not like anyone is using it, so why bother? And this highlights a problem for people like me, who prefer to have native Haiku applications instead of ports of software I can already run elsewhere. As a former BeOS user, I am not interested in a vessel for running Qt applications that I can, in all likelihood, run better on Linux. Why would I go through the trouble of assembling a machine with hardware Haiku supports, only to then run the same applications I'm already running on Fedora or OpenBSD, but worse? If you browse through Haiku Depot today, it feels like the vast majority of modern, maintained, and working software are ports of Qt (and GTK) software we already know and love from other, more mature, more stable, more usable, and more feature-rich platforms. Haiku has chosen to pour a lot of energy and manpower into becoming an operating system designed to run ported, often Qt, applications, but the downside to that is that new and maintained native Haiku applications, that play to the strengths of the platform, are few and far between. A Haiku developer once told me that real people use Haiku every day, and they need real applications, and ported applications make it possible for not only Haiku developers themselves, but also normal users, to run and use Haiku every day. This is a valid argument that I fully understand and agree with - it just means Haiku isn't for me. And while that's sad for me, it's entirely fine. Haiku's developers have chosen to focus on building a daily-drivable operating system with tons of ported applications, instead of an ideologically pure operating system you can't really use because it only has like 4 native applications and nothing else. And that's a valid, smart, and practical choice that I fully respect and understand, even if it means Haiku isn't really a BeOS successor anymore.

As its first alpha release is closing in, we have another monthly update about COSMIC, System76's new Linux desktop environment written in Rust. This month, they've further polished and shored up their application store, imaginatively named COSMIC App Store, and it's supposedly incredibly fast - something I can't say for its GNOME and KDE counterparts, which tend to be so slow I've always just defaulted to updating through the command line, mostly. The file manager now has support for GVfs (GNOME Virtual file system) for making external storage like USB drives work properly, and Greeter login screen, Edit text editor, drag and drop, and copy/paste have been improved in various ways as well. Theming has seen a lot of work this month, with support for icon themes added to the App Library, fixed applet sizes, and more tweaks, while light themes have been disabled for now to fix a number of issues with colour selection being too dark. There's also display mirroring now, which even works when the individual displays have different resolutions, orientations, and refresh rates. Pop!_OS is now also being built for ARM64, which makes sense because System76 is now also selling ARM servers. There's also a bunch of work being done by the community as the alpha release nears.

X Server is slowly being deprecated in the Linux world and being replaced Wayland. Still X11 is an interesting protocol to look at from the perspective of binary communication and management of resource which require fast speeds. In this post I tried to cover basic information and create a simple but working app that is simple, defined in single file and easily compiles. No external code except libc was used. I find it fascinating when you can open black boxes and see how gears move each other. Hereket As much as the time of X has come and is now finally in the process of going, it's still an incredibly powerful set of tools that even in a bare state can do way, way more than you think. X has come with its own window manager - twm - for decades, and it includes several basic applications like xedit, xclock, xterm, xeyes. Twm is actually pretty cool, and includes some features, like iconify to desktop, that I wish still existed in modern desktop environments. It's quite bare-bones, though, and I doubt there's anyone out there unironically using it today. As the linked article notes, even without advanced, complex libraries, toolkits, desktop environments, and so on, it's entirely possible to create fully functional windows and applications with X. Of course, this makes perfect sense and shouldn't be surprising - it's the X Window System, after all - but you so rarely hear or read about it that you'd almost forget and just assume something like GNOME or KDE is an absolute requirement to use X.

We've been on the lookout for the arrival of the ChromeOS App Mall for a few months now. First discovered back in March, the new App Mall is arriving to do one, simple task: put the apps users want in one place to be found a Chromebook. While we have access to web apps, PWAs, Android apps and Linux apps on Chromebooks, it's not always clear how to go about finding them. Should you install the web version or the Play Store version? Which Play Store apps install a PWA versus an Android app? Where should you go to find the right one for you? Robby Payne at Chrome Unboxed ChromeOS definitely needs a more unified, single place to find applications, and this seems like exactly what's happening here.

Yuxuan Shui, the developer behind the X11 compositor picom (a fork of Compton) published a blog post detailing their experiences with using GitHub Copilot for a year. I had free access to GitHub Copilot for about a year, I used it, got used to it, and slowly started to take it for granted, until one day it was taken away. I had to re-adapt to a life without Copilot, but it also gave me a chance to look back at how I used Copilot, and reflect - had Copilot actually been helpful to me? Copilot definitely feels a little bit magical when it works. It's like it plucked code straight from my brain and put it on the screen for me to accept. Without it, I find myself getting grumpy a lot more often when I need to write boilerplate code - Ugh, Copilot would have done it for me!", and now I have to type it all out myself. That being said, the answer to my question above is a very definite no, I am more productive without it". Let me explain. Yuxuan Shui The two main reasons why Shui eventually realised Copilot was slowing them down were its unpredictability, and its slowness. It's very difficult to understand when, exactly, Copilot will get things right, which is not a great thing to have to deal with when you're writing code. They also found Copilot incredibly slow, with its suggestions often taking 2-3 seconds or longer to appear - much slower than the suggestions from the clangd language server they use. Of course, everybody's situation will be different, and I have a suspicion that if you're writing code in incredibly popular languages, say, Python or JavaScript, you're going to get more accurate and possibly faster suggestions from Copilot. As Shui notes, it probably also doesn't help that they're writing an independent X11 compositor, something very few people are doing, meaning Copilot hasn't been trained on it, which in turn means the tool probably has no clue what's going on when Shui is writing their code. As an aside, my opinion on GitHub Copilot is clear - it's quite possibly the largest case of copyright infringement in human history, and in its current incarnation it should not be allowed to continue to operate. As I wrote over a year ago: If Microsoft or whoever else wants to train a coding AI" or whatever, they should either be using code they own the copyright to, get explicit permission from the rightsholders for AI" training use (difficult for code from larger projects), or properly comply with the terms of the licenses and automatically add the terms and copyright notices during autocomplete and/or properly apply copyleft to the newly generated code. Anything else is a massive copyright violation and a direct assault on open source. Let me put it this way - the code to various versions of Windows has leaked numerous times. What if we train an AI" on that leaked code and let everyone use it? Do you honestly think Microsoft would not sue you into the stone age? Thom Holwerda It's curious that as far as I know, Copilot has not been trained on Microsoft's own closed-source code, say, to Windows or Office, while at the same time the company claims Copilot is not copyright infringement or a massive open source license violation machine. If what Copilot does is truly fair use, as Microsoft claims, why won't Microsoft use its own closed-source code for training? We all know the answer. Deeply questionable legality aside, do any of you use Copilot? Has it had any material impact on your programming work? Is its use allowed by your employer, or do you only use it for personal projects at home?

Today we're pleased to announce the beta release of Raspberry Pi Connect: a secure and easy-to-use way to access your Raspberry Pi remotely, from anywhere on the planet, using just a web browser. It's often extremely useful to be able to access your Raspberry Pi's desktop remotely. There are a number of technologies which can be used to do this, including VNC, and of course the X protocol itself. But they can be hard to configure, particularly when you are attempting to access a machine on a different local network; and of course with the transition to Wayland in Raspberry Pi OS Bookworm, classic X remote desktop support is no longer available. We wanted to be able to provide you with this functionality with our usual it just works" approach. Enter Raspberry Pi Connect. Gordon Hollingworth Pi Connect uses WebRTC, and a daemon running on your Pi listens for incoming screensharing requests from the Raspberry Pi website to connect the VNC server on your Pi to the VNC client running in your browser. The service is in beta, it's free, but the one major downside is that for now, there's only one TURN server for this service, located in the UK, but they might set up more of them if demand is high enough. If you want to try this service on your own Pi running Raspberry Pi OS, you're going to need to be using a Raspberry Pi 5, 4, or 400, using the latest version of the operating system running Wayland. Update your operating system, install the rpi-connect package, reboot, and you're good to go.

The U.S. has revoked licenses that allowed companies including Intel and Qualcomm to ship chips used for laptops and handsets to sanctioned Chinese telecoms equipment maker Huawei Technologies, three people familiar with the matter said. Alexandra Alper, Fanny Potkin, David Shepardson The timing of this news is very interesting, as despite the massive sanctions the United States levied against Huawei, the company seems to be doing really well, with its smartphone business seeing massive gains in the Chinese market, at the expense of everyone else. This proves that Huawei does not need access to western chips and technologies to be successful, which must definitely sting in the US and Europe. Strong financial results, using hardware and chips designed not by western companies but by Chinese ones, combined with the only mobile operating system that has any serious potential to at least somewhat threaten Android and iOS. The various sanctions were clearly intended to hurt Huawei and possibly contain it to just China, but it seems they're not having their desired effect at all.

NetBSD 10 and NetBSD 9.4 were only recently released, leaving one final branch to receive what will be its last update: NetBSD 8.3. NetBSD 8.0 was originally released in 2018, so this final release marks six years of updates, which is a good track record, especially now that two newer main releases are available to choose from. With 8.3 being the final release, this means no more regular or security updates, pkgsrc no longer supports the 8.0 branch either - so yeah, time to upgrade. NetBSD 8.3 brings various updates and bug fixes for libX11, xterm, tmux, and httpd, and the root name servers and time zone data have been updated to their latest iterations as well. There's of course a full list of changes to peruse through if you want to know every little detail that's changed. You can update your installation in-place, of course, or download the installation media for 8.3 from one of the many mirrors.

This is the story on how I spent far too much money and time getting a scanner to work over iSCSI so that I could prove Chris O" wrong on StackExchange. The TL;DR is that yes scanners work fine over iSCSI. xssfox The next step is connecting a bunch of flatbed scanners to a disk array enclosure, but that turns out to be quite an expensive little exercise. Regardless, this is absolutely wild, and I love it when people go to great lengths just to prove that something pointless can actually be done. Bravo.

Jolie crystallises the programming concepts of service-oriented computing as linguistic constructs. The basic building blocks of software are not objects or functions, but rather services that can be relocated and replicated as needed. A composition of services is a service. Jolie website Jolie is open source and available on GitHub.

But today we got our hands on LPCAMM2 for the first time, and this looks like the future to us. LPCAMM2 is a totally modular, repairable, upgradeable memory standard for laptops, using the latest LPDDR chips for maximum speed and efficiency. So instead of overpaying (or under-speccing) based on guesswork about your future memory needs, you'll hopefully be able to buy your next laptop and then install more RAM as needed. Imagine that! Carsten Frauenheim LPDDR memory, used in modern laptops, has been difficult - or impossible - to upgrade because its low power nature means it needs to be located as close to the processor as possible with short traces, since the longer the traces, the more power is needed to maintain signal integrity between the processor and RAM. This would defeat the entire purpose of low-power DDR memory to begin with. Originally developed by Dell and eventually adopted by JEDEC and the wider industry, LPCAMM2 solves this problem by using screw-down RAM modules located right next to the processor. These modules can, like regular memory modules, be replaced and upgraded when needed or desired. This is a great leap forward, and I really, really hope we're going to see quick, widespread adoption.

GCC 14.1 has been released, and it should come as no surprise that the new features are not exactly something I, someone who doesn't program, can properly parse. So, here's the three items GCC itself thought were important to list first. The C frontend when targeting standards newer than C89 now considers many non-standard constructs as errors that were previously only warnings. See https://gcc.gnu.org/gcc-14/porting_to.html#warnings-as-errors for more details. C23 _BitInt Bit-precise integer types are now supported, for now only on IA-32, x86-64 and AArch64. The C++ frontend now implements several C++26 features, some missing C++23 bits and defect report resolutions. Diagnostics involving C++ templates now quote source from the instantiation context. The libstdc++exp.a library now includes all symbols for the Filesystem TS and the experimental symbols for the C++23 std::stacktrace class, so -lstdc++exp can be used instead of -lstdc++fs. The libstdc++_libbacktrace.a library is not longer installed. Improved experimental support for C++20, C++23, and C++26. Updated parallel algorithms that are compatible with oneTBB. GCC 14.1 release announcement GCC 14.1 is available for download, of course, but most of us will get it once it hits our distribution's package repositories.

We're all aware of Stack Overflow - it's a place where programmers and regular users can ask technical questions, and get answers from anyone who thinks they know the answer. Stack Overflow has become so ubiquitous among programmers and developers, the concept of I just copied the code off Stack Overflow" has become a consistent meme to indicate you don't fully grasp how something works, but at least it works. If you've ever contributed answers to Stack Overflow, you might want to consider deleting them, altering them, or perhaps even go as far as request a GDPR removal if you're in the European Union, because Stack Overflow has just announced a close partnership with AI" company OpenAI (or, more accurately, Open" AI"). Stripped of marketing speak, the gist is exactly as you'd expect: OpenAI will absorb the questions and answers on Stack Overflow into its models, whether their respective authors like it or not. As much as you may want to try and delete your answers if you're not interesting in having your work generate profit for OpenAI, deleting popular questions and answers is not possible on Stack Overflow. The other option is altering your answers to render them useless, but it seems Stack Overflow is not going to allow you to do this, either. Ben Humphreys tried to alter his highest-rated answers, and Stack Overflow just reverted them back, and proceeded to ban him from the platform. Stack Overflow does not let you delete questions that have accepted answers and many upvotes because it would remove knowledge from the community. So instead I changed my highest-rated answers to a protest message. Within an hour mods had changed the questions back and suspended my account for 7 days. Ben Humphreys Now that they've made what is most likely an incredibly lucrative deal with OpenAI that's going to net Stack Overflow's owners boatloads of money, they obviously can't let users delete or alter their answers to lower the monetary value of Stack Overflow's content. Measures to prevent deletion or alteration are probably one of the clauses in the agreement between Stack Overflow and OpenAI. So there's likely not much you can do to not have your answers sucked into OpenAI, but you should at least be aware it's happening in case of future answers you might want to contribute.

I want to run GoToSocial on some *BSD system. Because I am who I am, I went for using NetBSD 10.0 . And because my hypervisor is running bhyve on OmniOS , you get the title of this blog post. Don't get too anxious, it is quite straightforward. So let the journey begin. Joel Carnat Bhyve is a hypervisor originating from FreeBSD, while OmniOS is a distribution of illumos, a continuation of the last open source Solaris release from Oracle. GoToSocial, meanwhile, is an ActivityPub social network server, so it belongs in the same family as Mastodon, Glitch, Akkoma, and countless others. This guide makes this whole process look like a piece of cake, so if you've ever been interested in running your own ActivityPub server - read on. On a slightly related sidenote, there's no OSNews AT instance, partly because I don't want to deal with the moderation and costs, and partly because I'm incredibly happy being a member of Exquisite, a Glitch instance running on OpenBSD, managed by OpenBSD enthusiasts. Never say never, of course, but the odds of seeing an OSNews AT instance in the future are very slim.

The grabber in Windows 3.1 was improved to save and restore the index register as well, but it does not attempt to restore the flip-flop state, which is significant. The problem with the VGA emulation was that it erroneously applied the flip-flop state to reads from port 3C0h, and Windows 3.1 would save the wrong index register value... but only the second time through, because the flip-flop state was different at that point. That is to say, the Windows 3.1 standard mode grabber read from port 3C0h to query the attribute controller index register state, but the emulation returned the currently selected data register contents instead. And then, when restoring the attribute controller index register the next time around, the register would be restored to the wrong value which didn't have bit 5 set, causing the screen to go blank. Michal Necasek It's not every day that you learn how an aspect of the workings of VGA causes a blank screen under very specific circumstances when running Windows 3.1 in Standard mode under emulation, and that this specific aspect of the workings of VGA was implemented to maintain backwards compatibility with EGA. Absolutely bonkers.

In addition to Linux 6.10 expected to drop support for very old DEC Alpha processors (EV5 and earlier), it looks like the PowerPC 40x (early PowerPC 400 series) processor and platform support will be retired too. Back in 2020 was a proposal for dropping PowerPC 40x support from the Linux kernel given that the code was orphaned for a long time with no apparent users. The PowerPC 40x processors were found in thin clients, set-top boxes, and other devices during the 90's. Finally now it looks like that the PowerPC 40x removal is set to happen. Michael Larabel Spring cleaning in the hardware support department. I wonder what has more users - Windows on ARM, or Linux on PowerPC 40x.

Windows 11 supports a variety of ARM processors from Qualcomm. According to the official documentation, you need a computer with the Snapdragon 850 processor inside or newer to run the current operating system officially. However, customers with PCs powered by the Snapdragon 835, the original Windows on ARM chip from 2016, can bypass hardware requirements and install Windows 11 at their own risk. Sadly, those days will be ending soon. Starting with Windows 11 version 24H2, Microsoft's operating system requires ARM v8.1 to run. An attempt to boot it from a device with an ARM v8.0-based processor results in system crashes. For reference, the Snapdragon 835 from 2016 is a chip with Kryo 280 cores, which are derivative of ARM's Cortex-A73 cores. Taras Buria at Neowin I'm sure all three Windows on ARM users are devastated.

Snikket is a FOSS project for creating private chat spaces for small groups, such as families, friends, or clubs. It doesn't depend on a phone number, doesn't upload address books anywhere, and doesn't sell data to advertisers. It supports all the features you expect, including media and voice messages, audio and video calls, end-to-end encryption, group messaging, and more. Use it from multiple devices at once with the official apps, or even with unofficial, third-party apps. Snikket is easy to self-host, and professional managed hosting is also available. Our previous sponsor, JMP, opted to donate a free week's sponsorship to Snikket, which any paying OSNews sponsor can opt to do. This is our very small way of giving something back to the countless open source and/or smaller projects out there. Thank you Snikket for sponsoring OSNews!

That's right: it's PowerPC, the most unloved of the architectures CE ever ran on - in fact, this is the first PowerPC Windows CE device I've ever found, and I'm the self-described biggest pro-PowerPC bigot in the world. Here's an unusual form factor Windows CE device, running on the operating system's least used CPU, from a storied computer company near the end of its run, intended for medical applications, produced in very small numbers and cancelled within months. What are we going to do with it? Well, what do you think we're gonna do with it? We're going to program it, so that we can finally have some software! And, of course, since this wacky thing was there at the bitter end, we'll talk more about the last days of Data General and what happened next. Cameron Kaiser I knew Windows CE supported PowerPC, but I never knew any PowerPC-based Windows CE devices ever actually shipped and made it to market. Only Windows CE 2.0 seems to have supported the architecture, and it seems to have been eliminated in 3.0 and 4.0, so it's not surprising there weren't many PowerPC Windows CE devices out there. The device that's the subject of this article, too, only lasted on the market for a few months, so it's definitely a rarity.

Still rocking your Palm OS device, but mutter under your breath every time you need to log into a website or service with two-factor authentication? Sick of carrying around an Android or iOS device just so you can log in on your Palm PDA? Worry no more, your prayers have been answered, you can finally throw that Android or iOS garbage into the sun. Get your 2-factor codes on your Palm, just like Google Authenticator. Unlike Hotpants (an old port of a J2ME phone app), this version takes up much less space and supports all Palm OS versions. Nathan Korth You can now generate 2FA codes on your Palm device. This is wild, and I absolutely love it. I might if set it up on one of my dozens of Palm OS devices and just put it next to my keyboard for easy access. There's no cooler way to handle 2FA than this.

We'd like to thank this past week's sponsor JMP for sponsoring OSNews. As a reminder, JMP is a fully FOSS service providing a way to get a real phone number that operates over the internet using XMPP. They provide numbers in the USA and Canada with everything you need to access SMS/MMS/etc. and voice calls using your XMPP (or SIP) clients of choice across all your devices. They are committed to growing the use of open communications technology such as XMPP, ultimately working to help people move their communication off the unencrypted telephone network and onto the federated, encrypted, and diverse Jabber network. Once again, thanks to JMP for sponsoring OSNews!

But the biggest differential factor between BSDs and GNU/Linux is the way it is structured. In Linux, all components are designed to work together, but are completely separate. You've got the kernel, init systems, multimedia daemons, userland, bootloader, virtualization and containerization mechanisms, package managers, and so on. They are all separate projects with their own goals and are operated by separate entities. This is why we've got different Linux Distributions instead of Operating System. Everyone can take the kernel, start adding components on top of it, and a few minutes later the DistroWatch is even harder to keep up with. Each BSD on the other hand is designed as single system. All components are created and developed together. Things work together perfectly, because they are designed, coded, tested and released as one. Micha Sapka As I've mentioned here and there over the past few weeks, I've been exploring the world of BSD lately, and after bouncing of FreeBSD I've found a very happy home on OpenBSD. Now, this doesn't mean I'm now a full-time OpenBSD user or anything like that - Linux is the main operating system on my gaming PC, my laptop, and my workstation, and that's not going to be changing any time soon. However, after installing, exploring, and using OpenBSD on a machine cobbled together from spare and older parts, I can definitely see the appeal. OpenBSD feels more coherent than a Linux distribution - I use Fedora KDE, if that matters - and the various lower-level systems seem to talk to each other in ways that make more intuitive sense than the individually developed systems in a Linux distribution do. Diving into the command-line interface of a Linux distribution can sometimes feel confusing because different tools use different conventions, because they're developed by entirely different people and projects, with different ideas about how flags should work, how output should be presented, and so on. On OpenBSD, it seems much easier to carry over something you learn from one tool to the next. I simply feel more secure and knowledgeable, even if it's still the same idiot me. The documentation plays a big role here. They're in one place, written in a consistent style, and reference each other left and right, making it easy to find your way around to other commands or tools you haven't yet considered using. On Linux, you're going from one project's documentation to another project's documentation, and not only will the style change, the quality will also vary greatly. That's not to say everything's perfect on OpenBSD - it's clearly a hardened server operating system, and its focus on security will definitely throw up annoying hurdles if you're just trying to do workstation things. Firefox, for instance, is hobbled by strict security rules through unveil, which makes perfect sense for what OpenBSD is first and foremost trying to be, but if you're just a regular user like me, it's annoying that Firefox can only access ~/Downloads, or that it can't set itself as the default browser so unless you disable that check, Firefox will keep complaining about it. Diving into Firefox and unveil is on my list, though, because you should be able to fix' this. Furthermore, while every piece of software, or an equivalent, is pretty much always available for Linux, on OpenBSD it's more hit and miss, and it seems to take a bit longer for new releases of especially bigger software packages to get updated. I mean, there's obviously no Steam on OpenBSD, but smaller, less well-known projects generally also don't support OpenBSD, so you're either going to be compiling things yourself or hope someone packages it up for OpenBSD. Then there's the various vanity things we've come to expect from modern Linux distributions, like slick, fully graphical boot and shutdown sequences, detailed graphical tools for managing your packages, graphical firmware and driver managers, and so on. OpenBSD has none of these things, and while that's no issue for me, I can see how it would throw other people off. FreeBSD, OpenBSD, NetBSD, and the few others often kind of get lost in all the Linux, Windows, and macOS violence, and to be quite honest - I feel like many people in the BSD community seem mostly okay with that. If you've never spent any serious time using any of the BSDs, but you're interested in operating systems and don't mind spending a few hours learning how to manipulate your system through CLI tools - dive in. There's a ton of fun to be had, and things to learn. For now, I'm continuing my exploration of OpenBSD, and if things keep going as well as they are, I may consider at least switching over the workstation in my office from Fedora KDE to OpenBSD - but I highly doubt it'll ever make its way to my gaming desktop or my laptop.

Game of Trees (Got) is a version control system which prioritizes ease of use and simplicity over flexibility. Got is still under development; it is being developed on OpenBSD and its main target audience are OpenBSD developers. Got uses Git repositories to store versioned data. Git can be used for any functionality which has not yet been implemented in Got. It will always remain possible to work with both Got and Git on the same repository. Game of Trees website OpenBSD is developing Game of Trees because they want a version control system that adheres to OpenBSD coding conventions, implements various OpenBSD security practices, and uses nothing but BSD-licensed code. It's important to note, as its developers make very clear, that GoT is not in any way intended as a replacement for git.

The big question - does all this have a future? The good news is that all new hardware has generic support in X. Someone writes either a modesetting kernel driver or a classical wsdisplay kernel driver and they will be automatically supported by the associated drivers in X. The bad news is that to have applications running we require access to a larger open source ecosystem, and that ecosystem has a lot of churn and is easily distracted by shiny new squirrels. The process of upstreaming stuff to X.Org is an ongoing process, but it's likely we'll run into things that will never be suitable for upstream. Nia Alarie on the NetBSD blog I had no idea NetBSD did such heavy customisations of its X.Org implementation, many of which have never made their way upstream. The project also maintains support for several older GPUs, uses its own input driver, and more - it's quite impressive.

Do any of you remember the browser Dillo? The project's been through a rough few years after the main developer of the layout engine sadly passed away, the lead developer disappeared from the project, the dillo.org domain was lost and taken over by spammers - but now there's new people at the helm, and the browser just released it first new version since 2015. Dillo 3.1.0 brings a whole host of new features and improvements. Dillo is open source, uses the FLTK toolkit, and runs on Linux, BSD, MacOS, Windows (Cygwin), and more.

To support Zero Trust deployments trying to lock down devices to only access approved network destinations, we are announcing the development of Zero Trust DNS (ZTDNS) in a future version of Windows. ZTDNS was designed to be interoperable by using network protocols from open standards to satisfy Zero Trust requirements such as those found in OMB M-22-09 and NIST SP 800-207. ZTDNS will be helpful to any administrator trying to use domain names as a strong identifier of network traffic. ZTDNS integrates the Windows DNS client and the Windows Filtering Platform (WFP) to enable this domain-name-based lockdown. First, Windows is provisioned with a set of DoH or DoT capable Protective DNS servers; these are expected to only resolve allowed domain names. This provisioning may also contain a list of IP address subnets that should always be allowed (for endpoints without domain names), expected Protective DNS server certificate identities to properly validate the connection is to the expected server, or certificates to be used for client authentication. Tommy Jensen on the Microsoft blog If you think I know nothing about programming - wait until you hear me talk about networking. I consider it to basically be arcane magic, and my knowledge doesn't extend much beyond plug in cable to make light blinky" and unplug from power to fix light no blinky". Network administrators are the real heroes in my eyes. Anyway, what I do get from painfully reading this announcement over and over again until my eyes started bleeding is that ZTDNS will give network administrators more finegrained control over which DNS servers and domains are accessible, and perhaps more importantly, it will encrypt traffic between clients and the DNS server. I have no idea if this is unique, or if it even makes any sense to do so, but it seems like a good idea, especially for corporate and government networks. I'm struggling here, y'all. Please help me out.

The notice was filed on developer platform GitHub, which Nintendo claimed housed repositories that offer and provide access to the Yuzu emulator or code based on " which illegally circumvents Nintendo's technological protection measures and runs illegal copies of Switch games." GitHub said it contacted the owners of the repositories to provide an opportunity to make changes" before taking down the repositories, in addition to providing legal resources and information on how to file counter notices. Sophie McEvoy at GamesIndustry.biz The legal troubles around Yuzu are a little nebulous to deal with, as there's a lot of chatter online that Yuzu contains, or at least used, code from leaked Switch SDKs. If that is indeed true - I haven't seen any definitive proof yet - then it makes Nintendo's aggressiveness a lot more understandable, even for someone like me who believes emulation should be 100% legal and accessible.

FreeBSD is working on a graphical installer. Finally. The first hurdle to overcome when testing a new Operating System is to get it installed. What is more, the first impression new users gather from an Operating System is its installation process. The state of the art for Operating System installers nowadays definitely involves a graphical process. This is the case for mainstream systems but also for other UNIX systems comparable to FreeBSD: RedHat Enterprise Linux, Ubuntu, Debian GNU/Linux, or even Devuan GNU+Linux Regardless of the technical level of the actual user, this is how the platform will be compared in the public eye. Instead, with knowledge of the current bsdinstall(8) and bsdconfig(8) utilities, I envisioned a BSD-licensed replacement for Xdialog(1). Just like when invoking bsdconfig with the -X switch for graphical mode, it could be dropped in instead of bsddialog(1) and allow graphical installation - while sharing the infrastructure of the current installer. To avoid confusion with the current implementation of Xdialog from the x11/xdialog port, I have named its replacement gbsddialog(1). It also has to be said that Xdialog is quite obsolete (latest release in 2006) and this shows visually too. Pierre Pronchery in the FreeBSD status report I can't believe it's taken FreeBSD this long to both consider and build a graphical installer. Currently being enveloped in the world of OpenBSD, there's clearly so much the BSD world has to offer to desktop users such as myself, but at the same time, there's a lot of low-hanging fruit that the various BSDs can address to make the experience just that little bit more pleasant. They obviously don't have to - not every project is aiming at desktop use - but it just makes onboarding so much nicer. The next step - perhaps in 2037 - would be to offer a desktop-oriented installation image, with a default desktop environment and settings optimised for desktop use. Right now, a lot of fiddling and optimisation for this use case is left to the user, and for newcomers such as myself this means a lot of reading, making sense of contradictory advice and suggestions, wading through endless, often outdated, online guides, and so on. Now, I don't particularly mind doing this, but I'm sure it's chasing people away who could end up making meaningful contributions. Meanwhile, after trying out FreeBSD for a while a few weeks ago but it not being a good fit for me, I'm now exploring and using OpenBSD and it's been a great experience. Although unlikely, I hope OpenBSD, too, can perhaps consider making some minor affordances to desktop users - because as I've learnt, OpenBSD feels right at home on a desktop, more so than I ever expected.

COSMIC Desktop Environment (DE) is a new project by System76, the company behind the popular Linux distribution Pop!_OS. In this tutorial, we will give you an overview about COSMIC DE and its features, and then we will walk you through the steps to install COSMIC Desktop Environment in the latest Fedora 40 Linux system. Senthilkumar Palani at OSTechNix A very easy way to try out the current pre-alpha state of COSMIC. I'll definitely be waiting on a more official release later this year, but man, does COSMIC ever seem way more polished and complete than it has any right to be at this point in time.

Microsoft is making security its number one priority for every employee, following years of security issues and mounting criticisms. After a scathing report from the US Cyber Safety Review Boardrecently concludedthat Microsoft's security culture was inadequate and requires an overhaul," it's doing just that by outlining a set of security principles and goals that are tied to compensation packages for Microsoft's senior leadership team. Tom Warren at The Verge The devil is in the details regarding tying executive pay to security performance, but it we take it at face value and assume good intent - which is a laughable assumption in our corporatist world, but alas - I would like to see more of this. It's high time executives start paying - literally and figuratively - for the failings of the companies and teams they claim to run.

This is, in a way, a mature OS with an ecosystem and an aftermarket. (Which, we feel we must explicitly spell out, means that quite a few of those third-party applications and drivers will cost you money.) There are emulators that will let you run 20th century Acorn apps that you can find online, but this isn't an emulated vintage environment like Amiga Forever. It's not meant for running games from thirty years ago. This is a native bare-metal OS, built on 1980s roots but updated for 21st century hardware. It's also not an experimental project with little practical use, like Redox OS or Serenity OS, interesting though those are. Liam Proven at The Register I grew up with RISC OS and still run a RISC OS machine to this day. As Liam Proven explains affectionately in this article, while as an operating system it's missing many features we now take for granted (memory protection, pre-emptive multitasking, compositing), some of the user interface ideas it implements still manage to feel advanced compared to modern-day desktops (no need for menu bars, no clunky file dialogues, elegant mouse button assignments). The fact it's found a home on the Raspberry Pi and continues to support an active community is testament to its enduring appeal and the amazing work of the RISC OS Open project. Some additional notes from Thom: this new release supports 7 ARM platforms, most notably the Raspberry Pi Zero, 1, 2, 3 and 4 (but not the 5), and it even supports WiFi on the 3 and 4, which is an absolutely incredible achievement. The number of fixed bugs and addressed issues is massive, and there's even more to come later during the year, as The Register's article notes. I was waiting on this release to spur me on to buy a new Raspberry Pi (my only other Pi is our Pi-Hole), so I'll definitely be on the lookout for a good deal. This release deserves my full attention for OSNews.

Sixty years ago, on May 1, 1964, at 4 am in the morning, a quiet revolution in computing began at Dartmouth College. That's when mathematicians John G. Kemeny and Thomas E. Kurtz successfully ran the first program written in their newly developed BASIC (Beginner's All-Purpose Symbolic Instruction Code) programming language on the college's General Electric GE-225 mainframe. Little did they know that their creation would go on to democratize computing and inspire generations of programmers over the next six decades. Benj Edwards at Ars Technica Even I have used BASIC in the past, when I was a child and discovered QBasic (or possibly GW-BASIC, I'm a bit hazy on the details) and started messing around with it. My experiences with BASIC didn't lead to a path of ever more complex programming languages, but for huge numbers of people, it did - it's wild just how many people over a certain age got their programming start with BASIC in the 8 bit home computer era. I mean, 30 GOTO 10 is such a widespread morsel of knowledge it made its way into all kinds of popular media, such as a few Easter egg jokes in Futurama. BASIC has effectively achieved immortality.

Qualcomm's Adreno 6xx architecture has been superseded Adreno 7xx, but it's still used in countless devices, including the current-gen Snapdragon 8cx Gen 3. Here, I'll be looking at the Adreno 640 GPU in the Snapdragon 855. Zarif98 on Reddit kindly provided a OnePlus 7 Pro, and I'll be using that to check out Adreno 640. Compared to the older Snapdragon 821's Adreno 530, Adreno 640 dramatically increases compute throughput while still working within a very constrained power and thermal envelope. Process node improvements help, and TSMC's 7 nm process should be far better than the 14 nm Samsung node used in the Snapdragon 821. But cell phone SoC constraints meant Qualcomm couldn't go around copy-pasting basic GPU building blocks and call it a day. Chips and Cheese Chips and Cheese with another deep dive.

Years of accumulated security debt at Microsoft are seemingly crashing down upon the company in a manner that many critics warned about, but few ever believed would actually come to light. Microsoft is an entrenched enterprise provider, owning nearly one-quarter of the global cloud infrastructure services market and, as of Q1 last year, nearly 20% of the worldwide SaaS application market, according to Synergy Research Group. Though not immune to scandal, in the wake of two major nation-state breaches of its core enterprise platforms, Microsoft is facing one of its most serious reputational crises. David Jones at Cybersecurity Dive It's almost like having the entire US government dependent on a single vendor is a bad idea. Just spitballing here.

With 14.9, Vanguard, Riot's proprietary Anti-Cheat system will be deployed and active in League of Legends. This means that active enforcement of Vanguard will be in effect and working hard to make sure your queues are free from scripters, botters, and cheaters! We recently released a blog detailing the why" behind bringing Vanguard to League that you can check out here. It's a bit of a long read, but it does have some pictures. Lilu Cabreros in the League of Legends patch notes The basic gist is that Vanguard is a closed-source, kernel-level rootkit for Windows that runs at all times, with the supposed goal of detecting and banning cheaters from playing League of Legends. This being a rootkit designed specifically to inject itself into the Windows kernel, it won't work on Linux, and as such, the entire League on Linux community, which has been playing League for years now and even at times communicated with Riot employees to keep the game running, is now gone. Interestingly enough, Riot is not implementing Vanguard on macOS, which League of Legends also supports - because Apple simply doesn't allow it. This is probably the most invasive, disturbing form of anticheat we've seen so far, especially since it involves such a hugely popular game. It's doubly spicy because Riot Games is owned by Tencent, a Chinese company, which means a company owned and controlled by the Chinese government now has rootkits installed on the roughly 150 million players' computers all over the world. While we're all (rightly, in my opinion) worried about TikTok, China just slipped 150 million rootkits onto computers all over the world. One really has to wonder where these increasingly invasive, anti-privacy and anti-user anticheat measures are going from here. Now that this rootkit can keep tabs on literally every single thing you do on your Windows computer, what's going to be the next step? Anticheat might have to move towards using webcams to watch you play to prevent you from cheating, because guess what? The next level of cheating is already here, and it doesn't even involve your computer. Earlier this year, hardware maker MSI showed off a gaming monitor that uses AI" to see what's going on on your monitor, and then injects overlays onto your monitor to help you cheat. MSI showed off how the monitor will use the League of Legends minimap to follow enemy champions and other relevant content, and then show warnings on your screen when enemies approach from off-screen. All of this happens entirely on the monitor's hardware, and never sends any data whatsoever to the computer it's attached to. It's cheating that literally cannot be detected by anything running on your computer, rootkit or not. So, the only logical next step as such forms of cheating become more advanced and widespread is to force users to turn on their webcams, and point them at their displays. I fired up League of Legends today on my gaming computer - which runs Linux, of course - and after the League client installed" the rootkit, it just got stuck in an endless loop of asking me to restart the client. I've been playing League of Legends for close to 14 years, and while I know the game - and especially its community - has a deservedly so bad reputation, I've always enjoyed the game with friends, and especially with my wife, who's been playing for years and years as well. Speaking of my wife - even though she runs Windows and could easily install the rootkit if she wanted to, she has some serious doubts about this. When I explained what the Vanguard rootkit can do, her mouse pointer slowly moved away from the Update" button, saying, I'm not so sure about this..."

Anyone who has spent any time recently using non-GNOME GTK desktop environments, like Cinnamon, MATE, or Xfce, has had to deal with the unfortunate reality of a lot of GTK applications becoming GNOME applications instead, using GNOME's own libadwaita. These applications are hard to theme, and do not integrate at all with the proper GTK applications non-GNOME desktop environments ship with. With how popular GNOME is, this has meant that the number of non-GNOME GTK applications has been dwindling. Linux Mint, the popular Linux distribution that also develops the Cinnamon desktop environment, has long made a bundle of GTK applications called XApps - basically forks of various core GNOME 3.x applications to ensure they would have access to non-GNOME GTK applications. With GNOME effectively forking GTK into its own, unique, GNOME-specific style (like libaidwaita), other GTK environments have suffered, and XApps were intended to close that gap. That hasn't really happened though, as XApps remained mostly a Mint-only thing, managed by Mint, as part of the Mint/Cinnamon GitHub projects. Other distributions and GTK desktop environments, such as Xfce, MATE, Budgie, and so on, didn't really pick them up. The Linux Mint project intends to change that, and will spin off' the XApps into its own, dedicated, independent project to facilitate cross-distribution and cross-DE collaboration, decision-making and development, all in an effort to ensure the long-term viability of non-GNOME GTK desktop environments. They also intend to fork a lot more of the GNOME 3 applications, for the same reason I mentioned earlier: GNOME applications are no longer GTK applications, but GNOME applications - they look and feel horribly out of place in environments that don't use the GNOME-specific libadwaita. As such, Celluloid, GNOME Calculator, Simple Scan, Baobab, System Monitor, GNOME Calendar, File Roller, and Zenity were recently downgraded in Linux Mint to their last GTK 3 versions, and will most likely be forked in the near future. In addition, the Adwaita theme, the default GNOME/GTK theme, will be removed from the list of available themes in Cinnamon 6.2. Adwaita, too, has become increasingly GNOME-only, and thus, increasingly broken on non-GNOME desktop environments. Flat-our removing Adwaita altogether is not possible, since it's a GTK dependency, but hiding it from the theme selector is not an issue, of course. As project lead Clement Lefebvre writes: libAdwaita is for GNOME and GNOME only. We can't blame GNOME for this, they've been very clear about it from the start. It was made specifically for GNOME to have more freedom and build its own ecosystem without impacting GTK. We want to send a strong signal upstream and towards other projects. We cannot and will not support applications which do not support our users and environments. We can't promote applications to our users which don't support our users. The software manager will be vigilant towards that going forward and list compatible software by default. Clement Lefebvre All of this is great news to hear. I've been making extensive use of Xfce on OpenBSD lately, and on the Fedora Xfce spin in the weeks before that, and the situation has become almost comical. If you install any GNOME application on Xfce, theming just breaks down completely, as most themes are either not made to support the massive headerbars GNOME uses, or they do support it but still look horribly out of place compared to the more sane titlebar plus menubar plus toolbar layout of traditional desktop environments like Xfce. I've long been saying that the non-GNOME GTK desktop environments need to work together to formulate an answer to the onslaught of libadwaita and the GNOME-ification of GTK, because each of them risks becoming entirely tied to whatever GNOME and libadwaita decides to do, for better or worse. It seems the Linux Mint team has finally realised this as well, and I really hope - and strongly suggest - Xfce, MATE, and others join them as well. If they don't, there won't be an Xfce in a few years. What's the point in developing Xfce if you're at the mercy of whatever choices GNOME makes?

Another month, another detailed report about the progress made in Redox, the Rust-based operating system. A major improvements this month is support for USB HID, allowing USB keyboards and mice to work on Redox, but the project does note USB hubs are still problematic and might not work properly. Thanks to these USB improvements, Redox' desktop environment Orbital now also ran on ARM64 in Qemu for the first time, which is a great step towards running it on real ARM64 hardware. A massive documentation pass has also taken place, fixing various errors and improving and simplifying the writing. More programs have been ported, of course, and various lower-level improvements and fixes, along with a number of other fixes and changes across the operating system.

Humans speak countless different languages. Not only are these languages incompatible, but runtime transpilation is a real pain. Sadly, every standardisation initiative has failed. At least there is someone to blame for this state-of-affairs: God. It was him, after-all, who cursed humanity to speak different languages, in an early dispute over a controversial property development. However, mankind can only blame itself for the fact that computers struggle to talk to each other. And one of the biggest problems is the most simple: computers do not agree on how to write letters in binary. Cal Paterson For most users, character encoding issues are not something they have to deal with. Programmers and other people who deal with the lower levels of computing, however, deal with this way more often than they should.

Over 35 years ago, these problems with software portability led to the emergence of the first POSIX standard in 1988. The acronym was coined by Richard Stallman, who added X" to the end of Portable Operating System Interface. It's meant to provide a specification of the interface that different Unix operating systems should have in common, including programming languages and tools. It's important to note that the interface is portable, and not the implementation. vorakl While POSIX certainly isn't perfect, and support for it in various operating systems claiming to support POSIX even less so, there's no denying its success. Even if the dream of 100% source code portability isn't possible under POSIX for applications that are a little more complex than basic CLI tools, there's enough portability that platforms like Linux, the various BSDs, macOS, and others, can share quite a bit of code. One of my favourite things about POSIX is that it shows up in the most unexpected of places. Windows, for instance, has had various options for POSIX compatibility, some of which straight from Microsoft itself, like the currently well-known Windows Subsystem for Linux, but also mostly forgotten options like the Microsoft POSIX subsystem that shipped with Windows NT until Windows 2000, or the very rudimentary POSIX compatibility in the Windows C Runtime Library and Windows Sockets API. OS/2 had POSIX compatibility as well, through EMX (Eberhard Mattes eXtender). It gave OS/2 - and MS-DOS - a POSIX API, and even provided access to native OS/2 APIs as well, and could run 32bit applications. You'd be surprised by how many more operating systems offered forms of POSIX compatibility, either out of the box or through first or third party add-ons.

Although Google has shown significant progress in recent weeks in improving RISC-V support in Android, it seems that we're still quite a bit away from seeing RISC-V hardware running certified builds of Android. Earlier today, a Senior Staff Software Engineer at Google who, according to their LinkedIn, leads the Android Systems Team and works on Android's Linux kernel fork, submitted a series of patches to AOSP that remove ACK's support for riscv64." The description of these patches states that support for risc64 GKI kernels is discontinued." Mishaal Rahman Google provided Android Authority with a statement, claiming that Android will continue to support RISC-V. What these patches do, however, is remove support for the architecture from the Generic Kernel Image, which is the only type of kernel Google certifies for Android, which means that it is now no longer possible to ship a certified Android device that uses RISC-V. Any OEM shipping a RISC-V Android device will have to create and maintain its own kernel fork with the required patches. This doesn't seem to align with Google's statement. So, unless Google intends to add RISC-V support back into GKI, there won't be any officially certified Android devices running on RISC-V. Definitely an odd chain of events here.

JMP is a fully FOSS service providing a way to get a real phone number that operates over the internet using XMPP. They provide numbers in the USA and Canada with everything you need to access SMS/MMS/etc. and voice calls using your XMPP (or SIP) clients of choice across all your devices. They are committed to growing the use of open communications technology such as XMPP, ultimately working to help people move their communication off the unencrypted telephone network and onto the federated, encrypted, and diverse Jabber network. We thank JMP for sponsoring OSNews this week, and they even offer a discount code for OSNews readers who sign up for the service. Use the code OSNEWS for one free month after paying for your account initially.

There's a new 9front release! So, what exactly is 9front, you may ask? Well, after it became clear that Bell Labs wasn't doing much with plan9, a group of developers took matters into their own hands and created 9front, a fork of plan9. Their latest release is called DO NOT INSTALL, and brings things like more USB audio support, DNS over TLS, WiFi support for the Raspberry Pi, I2C support, and much more. I'm not particularly well-versed in the world of plan9, and more often than not it feels like a form of high-level programming performance art that I'm just not smart enough to understand. The whole community and its associated web sites have a very unique feel to it, and I always feel like I'm just not cool enough to be part of it. That's not a dig at the plan9 community - it's more of an indictment of my lack of coolness. Which really shouldn't come as a surprise.

Lennart Poettering, main developer of systemd, has announced run0, a systemd-based replacement for the well-known sudo command that fixes many of he inherent issues with the widely used tool to gain temporary elevated privileges. There are various problems with sudo, which basically come down to that it's a large SUID binary, meaning it consists of privileged code that unprivileged users can run from their own context. This makes sudo a fairly large attack surface, and why OpenBSD uses doas instead; while doas suffers from the same main problem, it's much smaller and reduces the attack surface considerably. SUID processes are weird concepts: they are invoked by unprivileged code and inherit the execution context intended and controlled by unprivileged code. By execution context I mean the myriad of properties that a process has on Linux these days, from environment variables, process scheduling properties, cgroup assignments, security contexts, file descriptors passed, and so on and so on. A few of these settings the kernel is nice enough to clean up automatically when a SUID binary is invoked, but much of it has to be cleaned up by the invoked suid binary. This has to be done very very carefully, and history has shown that SUID binaries are generally pretty shit at that. Lennart Poettering Poettering wants to address this problem, and has come up with run0, which behaves like sudo, but works entirely differently and is not SUID. Run0 asks the services manager to create a shell or command under the target user's ID, creating a new PTY, sending data back and forth from the originating TTY and the new PTY. Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we *do* propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist). One could say, run0" is closer to behaviour of ssh" than to sudo", in many ways. Except that it doesn't bother with encryption or cryptographic authentication, key management and stuff, but instead relies on the kernel's local identification mechanisms. run0 doesn't implement a configuration language of its own btw (i.e. no equivalent of /etc/sudoers). Instead, it just uses polkit for that, i.e. how we these days usually let unpriv local clients authenticate against priv servers. Lennart Poettering This approach addresses a whole slew of attack vectors on sudo, and it comes with fun additional features like being able to give your terminal a different background tint when using it, or displaying a little red dot in the terminal window title to further indicate you're using elevated privileges. It will ship as part of the upcoming release of systemd 256.

Well, this was a wild goose chase of a read. J. B. Crawford dove into the history of something I've never heard of - Microsoft At Work - and came away with a story that' while clearer thanks to his research, is still frustratingly nebulous. I'm still not entirely sure what Microsoft At Work really was, but I think it had the goal of running Windows on communications devices like faxes, to make it easier to share and work on documents across various devices. Crawford did a lot of digging, and eventually settles on what he thinks might be a description of what MAW really consisted of. I am being a bit dismissive for effect. MAW was more ambitious than just installing Windows on a grape. The effort included a unified communications protocol for the control of office machines, including printers, for which a whole Microsoft stack was envisioned. This built on top of the Windows Printing System, a difficult-to-search-for project that apparently predated MAW by a short time, enough so that Windows Printing System products were actually on the market when MAW was announced-MAW products were, we will learn, very much not. MAW devices like the Ricoh IFS77 ran 16-bit Windows 3.1 with a new GUI intended to appear more modern while reducing resource requirements. Some reporters at the time noted that Microsoft was cagey about the supported architectures, I suspect they were waiting on ports to be completed. The fax machine was probably x86, though, as there's little evidence MAW actually ran on anything else. J. B. Crawford The '90s were a wild time, especially as Microsoft, and this MAW project seems to have '90s written all over it, but I'd still love to learn a lot more about this. I hope this article will bring out some former Microsoft execs or employees who can give us more details, and possibly even some code. I want to know how this works and what it did.

This is a virtual DEC PDP-1 (emulated in HTML5/JavaScript) running the original code of Spacewar!", the earliest known digital video game. If available, use gamepads or joysticks for authentic gameplay - the game was originally played using custom control boxes". Spacewar! was conceived in 1961 by Martin Graetz, Stephen Russell, and Wayne Wiitanen. It was first realized on the PDP-1 in 1962 by Stephen Russell, Peter Samson, Dan Edwards, and Martin Graetz, together with Alan Kotok, Steve Piner, and Robert A Saunders. Norbert Landsteiner It's wild to me that even for the very first video game, they already made what are effectively controllers anyone today could pick up and use. Note that this emulator can run more than just Spacewar!.