Monthly Archive:: May 2020

We’ve already talked about snaps on Ubuntu, but it turns out it’s actually way worse than I initially thought. On the latest Ubuntu, if you try to download the .deb version of Chromium using either the Software Store or command line, it acts as an alias to installing the snap version! Essentially, Chromium snap is shoved down your throat even if you explicitly asked for the .deb version. This is not cool Ubuntu – just because Chromium may be easier to maintain as a snap app doesn’t justify this forced behavior. Snap applications auto-update and that’s fine if Ubuntu wants to keep systems secure. But it can’t even be turned off manually. Auto-updating of snaps can only be deferred at best, until at some point, like Windows, it auto-updates anyway. Even on metered connections, snaps auto-update anyway after some time. I only use Ubuntu on my laptop right now – my workstation and main PC run my distribution of choice, Linux Mint with Cinnamon – because the latest version of Ubuntu supports it better than the current Linux Mint release does. As soon as the next version of Mint is out, which will be based on the current Ubuntu version, I’m ditching Ubuntu right away. I don’t like snaps, FlatPaks, AppImage, or any of that other nonsense that do nothing but make a clean .deb/APT-based system more complicated than it needs to be. Debian’s package management system is incredibly robust and easy to fix in the unlikely event something does go wrong, so I simply do not have a need for additional application installation methods that I can’t control through APT. Ubuntu only barely just recovered from the Unity debacle, only for the project to now go down yet another route nobody is asking for.

The ReactOS Build Environment (RosBE), our curated set of compilers and build tools, has just received a major upgrade. After more than 7 years of using the same and now ancient GCC 4.7.2, ReactOS is finally going to be built with the help of a modern compiler (GCC 8.4.0). Among other things, the new version better detects programming mistakes like improperly sized buffers, and comes with improved error messages to pinpoint such mistakes to the corresponding position in code. It also adds support for the latest C and C++ standards, marking a first step towards the introduction of modern C++ concepts into ReactOS. That is one hell of an upgrade, and a much-needed one by the looks of it.

Valve has announced it’s ending support for macOS for SteamVR. SteamVR has ended OSX support so our team can focus on Windows and Linux. We recommend that OSX users continue to opt into the SteamVR branches for access to legacy builds. Users can opt into a branch by right-clicking on SteamVR in Steam, and selecting Properties… -> Betas. Apple announced SteamVR coming to the Mac at WWDC in 2017, so support from Valve lasted for a mere three years. This shouldn’t come as a surprise though, since the macOS ecosystem simply isn’t geared towards gaming and VR in any way, shape, or form. Most Mac users have to settle for Intel integrated graphics, and even the Mac users with a dedicated video card have to settle for subpar and overpriced AMD cards, since Apple refuses to support NVIDIA. On top of that, Apple has deprecated OpenGL and wants developers to use their proprietary Metal API instead. In a world where most game developers use DirectX or OpenGL/Vulkan, that just doesn’t make a lot of sense. And let’s not forget that the writing is on the wall for macOS as a general purpose operating system anyway, since Apple will most likely use the move to ARM processors in Macs to further lock down macOS, making it more like iOS. While macOS might be more popular than Linux in absolute numbers, the cold and harsh truth is that the Linux userbase simply has a far larger group of skilled developers, programmers, and tinkerers willing to put the effort into making non-native games work on Linux and to improve support for things like VR devices. These are exactly the kind of people Apple seems to have a deep-rooted disdain for. Expect more of these kinds of announcements over the coming years, as game companies (and other developers) have to decide whether or not to support an isolated and locked down platform like macOS on ARM – a platform without first-party OpenGL or Vulkan support, with a steward actively pushing you to use a proprietary API that you can’t use anywhere else.

The big news first: a timeline has been set for Beta 2! If all goes well, it will be released by the end of May. Of course, this means everyone has been scrambling for last minute changes this month instead of stabilizing everything. We are now in “soft freeze”, and the branch will be created on Friday. Yes, an actual almost release date for Haiku’s second beta release.