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!

Each S1012 node has a single Power10 processor, which can have 1, 4, or 8 cores activated, which suggests that it is the same single chip module (SCM) implementation of the Power10 processor that was used in the Power S1022s entry machine. The Power S1012 node has four ISDIMM memory slots (using the differential signaling created by Big Blue for its Power10 memory) with a maximum capacity of 256 GB. The node has four half-height, half-length PCI-Express 5.0 slots and room for four NVM-Express U.2 drive bays that come in a maximum 1.6 TB capacity each for a total of 6.4 TB of storage.

[…]

The eight-core version of the Power10 SCM is only available in the rack configuration, while the one-core and four-core versions are available in rack or tower configurations. The four-core and eight-core versions can run IBM i, AIX, or Linux, but the one-core version can only run IBM i and it has its main memory capped at the same 64 GB that other single-core Power Systems machines have been subjected to. We have suggested that 128 GB or even 256 GB is more appropriate given modern workloads, but Big Blue is standing its ground here. If you need more memory than 64 GB, then this machine is not for you.

↫ Timothy Prickett Morgan at IT Jungle

I understand full well that these machines are by no means meant for people like you and I, sitting at home playing with our toys. That being said, I still wish there was some way for IBM to offer unique hardware like this – perhaps in a more standard, paired-down configuration – so more people than just enterprises could explore and use them.

It wouldn’t make any economic sense for IBM to do so, and even in a more standard, paired-down configuration they’d probably still be ungodly expensive, but when I look at this unique tower, with its POWER10 hardware and the ability to run AIX, desires are stirred within me that are banned in at least 46 countries. Such a machine would surely be wasted on someone like me, who would just be shoehorning whatever desktop tasks he could into it, but what a grand ol’ time we would have.

There is absolutely, positively, unequivocally zero percent chance IBM would ever send one of these over for review to someone like me, but I wonder if I should try anyway. I’ve got nothing to lose. Does anyone here work at IBM? Perhaps IBM wants to sponsor OSNews? How about like 12 weeks of free sponsorships in exchange for a tower model of the Power S1012? I also have two POWER9 machines to compare it to!

It’s the only way you’ll ever get a Power S1012 screenfetch screenshot go viral on nerd social media, and we all know that deep down, that’s all you IBM folks really want.

MacRelix is a Unix-like environment that runs in classic Mac OS.

MacRelix natively supports classic 68K and PPC Mac OS, as well as Mac OS X on PPC via Carbon.

↫ MacRelix website

The creator of MacRelix, Josh Juran, published an article in 2019 detailing the origins of the project. As a Mac OS developer, he was so unhappy with both CodeWarrior and Apple’s Macintosh Programmer’s Workshop (MPW), that he set out to create what would become MacRelix in 1999. Reading through the limitations and roadblocks he experienced with CodeWarrior and MPW, it’s not hard to see why he got frustrated – CodeWarrior’s targets were apparently a mess and a half to deal with.

Then came target multiplication. Whereas the initial CodeWarrior developer releases shipped with each combination of language (C and Pascal) and architecture (68K and PPC) supported in a separate application, a later version of the IDE unified these, allowing the developer to have a single project file per project. To allow the same project to be built for both 68K and PPC architectures, the project data model included targets: One target would compile for 68K and link against 68K libraries, another would do the same for PPC. Targets could also be used to select an optimized build versus one for debugging. Combining both dichotomies yields four targets: 68K debug, 68K optimized, PPC debug, and PPC optimized. Then if your project involves multiple executables, like a code resource or shared library in addition to an application, you now have eight targets. Or, if you support one of, say, 68020 optimization, profiling, or a third executable, make that twelve. Or, for all of them, twenty-seven.

↫ Josh Juran

Changing an option in your application required you to change it in every single target, too, which I can easily see is incredibly frustrating. MPW, for its part, was a massive improvement, he argues, but while it was clearly inspired by UNIX, it didn’t seem to actually implement any of the features and characteristics of UNIX.

However, very much unlike Unix, the MPW Shell had only a single thread of execution — only one program could be running at once. Not only that, but there was no way for MPW’s compiled plugins (called tools) to invoke other tools or scripts — not even via system() (which blocks the calling program until the called program exits). Therefore, Make couldn’t actually do anything, but only printed out the commands for the user to run manually. You could code in Perl instead of the built-in language, but then your scripts couldn’t run other programs — only MPW shell scripts could do that.

↫ Josh Juran

The limitations Juran was experiencing with these two tools pushed him to create his own solution, which went well beyond what MPW offered, even in 2019 when this article was published.

Nowadays, MacRelix has pipes, signals, system calls, TCP sockets, and more. It works on both 68K and PowerPC Mac systems and builds as Carbon to run natively in OS X. It can be used on any Mac OS version from System 7 to Mac OS X 10.6 “Snow Leopard” (after which Apple removed the Rosetta PowerPC emulator). I haven’t implemented fork() yet, but I know how to do it. In addition to a Unix-like file system interface (which even handles long names by storing them in Desktop database comment fields)), MacRelix has a /proc filesystem (with human readable stack crawls) and also maps various parts of Mac OS (e.g. the ROM image in /sys/mac/rom).

↫ Josh Juran

I had never heard of MacRelix, but it seems like an amazing tool Juran put a lot of thought, effort, and love into. Sadly, with the number of PowerPC Mac OS X users being vanishingly small, and the number of classic Mac OS users even smaller so, the future of MacRelix seems uncertain. I wonder what parts of it can be salvaged and upgraded to work on ARM macOS or even Intel macOS, because I think the ideas and concepts are incredibly cool.

A related project by Juran is something called FORGE, a portable windowing API that used a virtual file system, meaning that instead of using functions as objects, it uses files. Juran mentions the example of a window title – which is a file, and if you want to change the title of that window you just change the file, which will be instantly reflected in the GUI. Here’s a Hello World example:

cd $FORGE/gui/port/hello        # select a window port named "hello"
exec 9> lock                    # exclusively retain the port for our use
ln new/caption view             # add a caption as the window’s view
echo Hello world > v/text       # set the caption text
touch window                    # create the window

Even though I’m not a programmer, this little tidbit of code makes perfect sense to me, and I understood it instantly. Of course, anything more complex will quickly leave my wheelhouse, but intuitively, I really like this. FORGE exists as a prototype inside MacRelix, so you can play with this concept while using MacRelix.

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?

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.

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.

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?

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.

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.