Monthly Archive:: December 2024

We’ve talked about Chimera Linux before – it’s a unique Linux distribution that combines a BSD userland with the LLVM/Clang toolchain, and musl. Its init system is dinit, and it uses apk-tools from Alpine as its package manager. None of this has anything to do with being anti-anything; the choice of BSD’s tools and userland is mostly technical in nature. Chimera Linux is available for x86-64, AArch64, RISC-V, and POWER (both little and big endian). I am unreasonably excited for Chimera Linux, for a variety of reasons – first, I love the above set of choices they made, and second, Chimera Linux’ founder and lead developer, q66, is a well-known and respected name in this space. She not only founded Chimera Linux, but also used to maintain the POWER/PowerPC ports of Void Linux, which is the port of Void Linux I used on my POWER9 hardware. She apparently also contributed quite a bit to Enlightenment, and is currently employed by Igalia, through which she can work on Chimera. With the description out of the way, here’s the news: Chimera Linux has officially entered beta. Today we have updated apk-tools to an rc tag. With this, the project is now entering beta phase, after around a year and a half. In general, this does not actually mean much, as the project is rolling release and updates will simply keep coming. It is more of an acknowledgement of current status, though new images will be released in the coming days. ↫ Chimera Linux’s website Despite my excitement, I haven’t yet tried Chimera Linux myself, as I figured its pre-beta stage wasn’t meant for an idiot like me who can’t contribute anything meaningful, and I’d rather not clutter the airwaves. Now that it’s entered beta, I feel like the time is getting riper and riper for me to dive in, and perhaps write about it here. Since the goal of Chimera Linux is to be a general-purpose distribution, I think I’m right in the proper demographic of users. It helps that I’m about to set up my dual-processor POWER9 machine again, and I think I’ll be going with Chimera Linux. As a final note, you may have noticed I consistently refer to it as “Chimera Linux”. This is very much on purpose, as there’s also something called ChimeraOS, a more standard Linux distribution aimed at gaming. To avoid confusion, I figured I’d keep the naming clear and consistent.

While we’re out here raising funds to make me daily-drive HP-UX 11i v1 – we’re at 59% of the goal, so I’m starting to prepare for the pain – it seems you can actually run older versions, HP-UX 10.20 and 11.00 to be specific, in a virtual machine using QEMU. QEMU is an open source computer emulation and virtualization software, first released in 2003 by Fabrice Bellard. It supports many different computer systems and includes support for many RISC architectures besides x86. PA-RISC emulation has been included in QEMU since 2018. QEMU emulates a complete computer in software without the need for specific virtualization hardware. With QEMU, a full HP Visualize B160L and C3700 workstation can be emulated to run PA-RISC operating systems like HP-UX Unix and compatible applications. ↫ Paul Weissman at OpenPA The emulation is complete enough that it can run X11 and CDE, and you can choose between emulating 32bit PA-RISC of 64bit PA-RISC. Devices and peripherals support is a bit of a mixed bag, with things like USB being only partially supported, and audio not working at all since an audio chip commonly found in PA-RISC workstations isn’t supported either. A number of SCSCI and networking devices found on HP’s workstations aren’t supported either, and a few chipsets don’t work either. As far as operating system support goes, you can run HP-UX 10.20, HP-UX 11.00, Linux, and NetBSD. Newer (11i v1 and later) and older (9.07 and 9.05) versions of HP-UX don’t work, and neither does NeXTSTEP 3.3. Some of these issues probably stem from missing QEMU drivers, others from a lack of testing; PA-RISC is, after all, not one of the most popular of the dead UNIX architectures, with things like SPARC and MIPS usually taking most of the spotlight. Absolutely nothing beats running operating systems on the bare metal they’re designed for, but with PA-RISC hardware becoming ever harder to obtain, it makes sense for emulation efforts to pick up speed so more people can explore HP-UX. I’m weirdly into HP-UX, despite its reputation as a difficult platform to work with, so I personally really want actual hardware, but for most of you, getting HP-UX 11i to work properly on QEMU is most likely the only way you will ever experience this commercial UNIX.

AI Shell is an interactive shell that provides a chat interface with language models. The shell provides agents that connect to different AI models and other assistance providers. Users can interact with the agents in a conversational manner. ↫ Microsoft Learn Basically, what Microsoft means with this is a split-view terminal where one of the two views is a prompt where you can ask questions to an “AI”, like OpenAI or whatever. The “AI” features are not actually integrated into your shell, which instead lives in the other view and acts like a completely normal, standard shell. Instead of opening up an “AI” chatbot in a browser window or whatever, you now have it in a split view in your terminal – that’s really all there’s to it here. I’m going to blow your mind here and say that in theory, this could be an actually useful addition to terminals and shells, as a properly vetted and configured “AI” that has been trained on properly obtained source material could indeed be a great help in determining the right terminal commands and options. Tons of people already blindly copy and paste terminal commands from websites even though they really shouldn’t anyway, so it’s not like this introduces anything new here in terms of dangers. Hell, tutorial writers still add -y to dnf or apt-get commands, so it can really only go up from here.

It’s a Christmas miracle! The Moxie, that support robot thing for kids we talked about two weeks ago, seems to be getting a new lease on life. The start-up that makes the Moxie has announced it’s going to not only release a version of the server software for self-hosting, but will also publish all of the source code as open source. We understand how unsettling and disappointing it has been to face the possibility of losing the daily comfort and support Moxie provides. Since the onset of these recent challenges, many of you have voiced heartfelt concerns and offered suggestions, and we have taken that feedback seriously. While our cloud services may become unavailable, a group of former technical team members from Embodied is working on a potential solution to allow Moxie to operate locally—without the need for ongoing cloud connectivity. This initiative involves developing a local server application (“OpenMoxie”) that you can run on your own computer. Once available, this community-driven option will enable you (or technically inclined individuals) to maintain Moxie’s basic functionality, develop new features, and modify her capabilities to better suit your needs—without reliance on Embodied’s cloud servers. ↫ Paolo Pirjanian Having products like this be dependent on internet connectivity is not great, but as long as Silicon Valley is the way it is, that’s not going to change. You can tell from their efforts that the people at Embodied do genuinely care about their product and the people that use it, because they have zero – absolutely zero – financial incentive or legal obligation to do any of this. They could’ve just walked away like their original communication said they were going to, but instead they listened to their customers and changed their minds. Regardless of my thoughts on requiring internet connectivity for something like this, they at least did the right thing today – and I commend them for that.

With more and more Linux distributions – as well as the kernel itself – dropping support for more exotic, often dead architectures, it’s a blessing T2 Linux exists. This unique, source-based Linux distribution focuses on making it as easy as possible to build a Linux installation tailored to your needs, and supports an absolutely insane amount of architectures and platforms. In fact, calling T2 a “distribution” does it a bit of a disservice, since it’s much more than that. You may have noticed the banner at the top of OSNews, and if we somehow – unlikely! -manage to reach that goal before the two remaining new-in-box HP c8000 PA-RISC workstations on eBay are sold, my plan is indeed to run HP-UX as my only operating system for a week, because I like inflicting pain on myself. However, I also intend to use that machine to see just how far T2 Linux on PA-RISC can take me, and if it can make a machine like the c8000, which is plenty powerful with its two dual-core 1.0Ghz PA-RISC processors, properly useful in 2024. T2 Linux 24.12 has just been released, and it brings with it the latest versions of the Linux kernel, gcc, LLVM/Clang, and so on. With T2 Linux, which describes itself as a System Development Environment, it’s very easy to spin up a heavily customised Linux installation fit for your purpose, targeting anything from absolutely resource-starved embedded systems to big hunks of, I don’t know, SPARC or POWER metal. If you’ve got hardware with a processor in it, you can most likely build T2 for it. The project also provides a large number of pre-built ISOs for a whole slew of supported architectures, sometimes further divided into glibc or musl, so you can quickly get started even without having to build something yourself. It’s an utterly unique project that deserves more attention than it’s getting, especially since it seems to be one of the last Linux “distributions” that takes supporting weird platforms out-of-the-box seriously. Think of it as the NetBSD of the Linux world, and I know for a fact that there’s a very particular type of person to whom that really appeals.

What’s the European Commission to do when one of the largest corporations in the world has not only been breaking its laws continually, but also absolutely refuses to comply, uses poison pills in its malicious compliance, badmouths you in the press through both official – and unofficial – employees? Well, you start telling that corporation exactly what it needs to do to comply, down to the most minute implementation details, and in the process take away any form of wiggle room. Steven Troughton-Smith, an absolute wizard when it comes to the inner workings of Apple’s various platforms and allround awesome person, dove into the European Commission’s proposed next steps when it comes to dealing with Apple’s refusal to comply with EU law – the Digital Markets Act, in particular – and it’s crystal-clear that the EC is taking absolutely no prisoners. They’re not only telling Apple exactly what kind of interoperability measures it must take, down to the API level, but they’re also explicitly prohibiting Apple from playing games through complex contracts and nebulous terms to try and make interoperability a massive burden. As an example of just how detailed the EC is getting with Apple, here’s what the company needs to do to make AirDrop interoperable: Apple shall provide a protocol specification that gives third parties all information required to integrate, access, and control the AirDrop protocol within an application or service (including as part of the operating system) running on a third-party connected physical device in order to allow these applications and services to send files to, and receive files from, an iOS device. ↫ European Commission In addition, Apple must make any new features or changes to AirDrop available to third parties at the same time as it releases them: For future functionalities of or updates to the AirDrop feature, Apple shall make them available to third parties no later than at the time they are made available to any Apple connected physical device. ↫ European Commission These specific quotes only cover AirDrop, but similar demands are made about things like AirPlay, the easy pairing process currently reserved for Apple’s own accessories, and so on. I highly suggest reading the source document, or at the very least the excellent summary thread by Steven, to get an even better idea of what the EC is demanding here. The changes must be made in the next major version of iOS, or at the very latest before the end of 2025. The EC really goes into excruciating detail about how Apple is supposed to implement these interoperability features, and leaves very little to no wiggle room for Apple shenanigans. The EC is also clearly fed up with Apple’s malicious compliance and other tactics to violate the spirit of the DMA: Apple shall not impose any restrictions on the type or use case of the software application and connected physical device that can access or makeuse of the features listed in this Document. Apple shall not undermine effective interoperability with the 11 features set out in this Document by behaviour of a technical nature. In particular, Apple shall actively take all the necessary actions to allow effective interoperability with these features. Apple shall not impose any contractual or commercial restrictions that would be opaque, unfair, unreasonable, or discriminatory towards third parties or otherwise defeat the purpose of enabling effective interoperability. In particular, Apple shall not restrict business users, directly or indirectly, to make use of any interoperability solution in their existing apps via an automatic update. ↫ European Commission What I find most interesting about all of this is that it could have been so easily avoided by Apple. Had Apple approached the EU and the DMA with the same kind of respect, grace, and love Apple and Tim Cook clearly reserve for totalitarian dictatorships like China, Apple could’ve enabled interoperability in such a way that it would still align with most of Apple’s interests. They would’ve avoided the endless stream of negative press this fruitless “fight” with the EU is generating, and it would’ve barely impacted Apple’s bottom line. Put it on one of those Apple microsites that capture your scrolling, boast about how amazing Apple is and how much they love interoperability, and it most likely would’ve been a massive PR win. Instead, under the mistaken impression that this is a business negotiation, Apple tried to cry, whine, throw tamper tantrums, and just generally act like horrible spoiled brats just because someone far, far more powerful than they are told them “no” for once. Now they’ve effectively been placed under guardianship, and have to do exactly as the European Commission tells them to, down to the API level, without any freedom to make their own choices. The good thing is that the EC’s journey to make iOS a better and more capable operating system continues. We all benefit. Well, us EU citizens, anyway.