It has been a couple of years now and the response to these articles is always the same. The person making the comment cannot accept that they produce code with bugs. So the problem has to be that the people being measured in the article must not know what they are doing.

Look at the source of these articles though. We are being asked to believe that the code in Android, Windows, AI frameworks, and databases are all being pumped out by junior devs. It is not that Rust results in fewer bugs than C++ generally, it is that Google engineers have not been properly trained or motivated.

I mean, the denial is Sith level strong in these people.

This is absolute gold.

Exactly what evidence is there that bugs in new code are from new devs? To me, it feels like you have fallen victim to motivated reasoning.

I like the idea of a stable distro as the host OS and Distrobox with Arch and the AUR for applications.

For most of my machines, I do not need the latest kernel or even the latest desktop environment. But it is a pain to have out of date desktop apps and especially dev tools.

I think this strikes a nice balance.

Imagine how much less would get done overall and how many fewer people would participate if we did not let people work on what they wanted to work on.

The only choice left would be to contribute or not and more people would choose not to contribute (probably the choice you have made).

I thought there were two units working now ( maybe not everything ). One Lenovo and one Asus if I recall.

EDIT:

ASUS Vivobook S15 & Lenovo Yoga Slim7x

https://www.phoronix.com/news/Linux-6.11-SoC-Platforms

6.11 is released now.

I will just say that SUSE 4.2 was not built off the same base as SUSE 1.0 either. It is not going to be as clear cut as finding a cloned Red Hat source code repository.

SUSE 4.2 was really version 1.0 of the distribution we call OpenSuse today ). It was a reboot. This version was no longer based on Slackware and it was the first version using RPM.

Debian introduced packages in 1995 ( before Debian 1.0 ). RPM did not appear until Red Hat Linux 2.0 in the fall. SUSE 4.2 came out in 1996 and could have used either one.

I was not trying to cause any offence. Mad respect for SUSE. As I hinted, I was simplifying. It is hard to talk about this stuff both accurately and concisely.

SUSE is certainly not a Fedora “fork” as Fedora Core was not even conceived until considerably later. Neither was OpenSUSE really. So you cannot take my first comment too literally.

Let’s remember how early SUSE was in the Linux timeline. Back then, everybody was downloading their software from the same FTP sites. A huge component of what made a Linux distribution different from an FTP repo was the package manager and those came from Red Hat or Debian.

The provenance of SUSE is also a bit complicated as the first versions were explicitly based on Slackware. Starting with 4.2 ( a made up version number meant as a nod to Douglas Adam’s I think ), SUSE became Jurix + RPM. So it is a Jurix fork in that sense. However, I cannot imagine more than a handful of people ever used Jurix. I would be interested to know the numbers. In contrast, in terms of both users and industry awareness, Red Hat was THE Linux distro back then.

Red Hat was certainly an influence on SUSE beyond the source code. Red Hat and SUSE were not just communities or collections of code. Red Hat and SUSE were two of the earliest company backed distros. Both had clear commercial ambition. It is no accident that they both evolved into explicitly “enterprise” subscription products flanked by explicitly community distros. SUSE and Red Hat were more like each other than they were like other Linux players ( especially in the days before Ubuntu ). It is not far wrong I think to think of SUSE as the Red Hat of Europe with Red Hat attracting American infrastructure giants like Oracle and SUSE becoming the platform for big European players like SAP.

SUSE is not a fork in the sense that we are going to find an import into the source code version control system from Red Hat ( other than RPM itself of course ). Again though, we should note that this is not how stuff worked back then ( see comment about FTP sites ).

RPM could have been a purely technical choice for SUSE but, in my view, they had a clear desire to use Red Hat as a template more broadly. That is what I meant by saying SUSE could be seen as a fork while also acknowledging that the statement is not quite fair ( or perhaps more that it is not technically accurate in the strictest sense of what the work fork means even if it instructive as a historical perspective ).

Do it

At first I was not very impressed. Then I read that that 4004 does not have any AND, OR, or XOR instructions. Yikes.

If it is “full Linux” then the answer is clearly yes. Not very fast I suppose.

OpenSUSE itself could be seen as a fork of Fedora though it is from long enough ago that perhaps that is not fair.

In the beginning there was Slackware ( well, maybe SLS but it is gone now ). Slackware has no packaging system. Most distros want one. Debian is not really a Slackware fork but it was a response to it.

The first two distributions to bring true package management were Debian and Fedora ( well pre enterprise Red Hat really - before Fedora ). So Fedora and Debian are the classic bases for other distros.

Red Hat created the first, and most successful, “enterprise” distribution so lots of people want to clone that.

Ubuntu was the first distro to really succeed at a “mainstream” desktop experience. Ubuntu is itself a fork of Debian but, because of its early success, there are probably more forks of Ubuntu than anything else.

Arch was the next really successful attempt at a new packaging system and a distro for more technical users ( that still wanted a binary package distribution system ). There are forks of Arch but, as the repos are Arch’s biggest strength, few of them deviate too much beyond the installer and default configuration.

If you are going to create a distro based off another one, it is typical to start with the base distro that is how to the package format of your choice.

There are now other distros with their own packaging systems ( eg. Alpine and Void ) but they have not been around as long.

Importantly I think, OpenSUSE is European base and, for a lot of the history of Linux, it was largely an American phenomenon ( yes, I know it was invented in Finland — how long did Linus stay there? ).

Finally, “forking” is often a little more sophisticated now. In the past, you started with some other distro that you liked and changed a few small things that you didn’t. A lot of that is taken care of with repos and spins these days so you so fewer unique distros start life this way. The exception is maybe init systems.

As an example, you could consider Chimera Linux as a successor to Void but it is not really a fork. It uses a different package manager, userland, and init system for example.

OpenSUSE itself has multiple versions. One of them is likely to be close enough for fans that they do not need to splinter off.

The NTFS3 driver in the kernel is about as fast as Ext4 ( and faster than Btrfs ).

Most compatible is FAT32 which is also the most limited.

I am not sure I would trust the WinBtrfs driver with anything important. What problems are you having with NTFS?

Linux has two NTFS stacks: NTFS-3G and NTFS3 ( in the Linux kernel since 5.15 ). NTFS3 is faster and more feature rich I think but that said it also lacks a few things. NTFS-3G is more mature and some people still report it to be more stable.

Rust does not compile down to C. It generates LLVM bytecode the same as Clang does. They both produce native executables. You do not need a C compiler on your system to run Rust binaries.

Typescript produces JavaScript. You need a JavaScript interpreter to execute the output from TypeScript.

Not the same thing.

The answer seems to be yes but I have not seen much detail on what works now and what does not. It also seems that device trees are required for each device and I have only seen that for one ASUS and one Lenevo so far.

If anybody knows more, I would love an update.

Just uninstall eos-hooks and then comment out the eos repos in pacman.conf if you want vanilla Arch. Pretty easy journey. You don’t even have to reboot.

EOS is about 24 additional packages on top of the 70,000 Arch already offers, many of which are already on the AUR ( like yay and paru ). EOS uses the real Arch kernel. Once installed, EOS is Arch in my view.

There are not “two updates”. It is not an OS over an OS. EOS is awesome but it is a glorified Arch installer with opinionated defaults.

I went through this recently and was not able to resolve it. Unfortunately, it looks like there is no way to use Resolve with an iGPU.

They only charge for the “extension pack” ( which is different from “guest additions”