Yes, because it would be crazy to learn keyboard skills for text editing. Such a super great point.

The thing about the vi keystrokes is that almost all programming editors support them. There are few skills that will save you more time and retraining than vi movements as you inevitably move from editor to editor.

Vim, IntelliJ / Rider, and VS Code. If you know the vi movements, you are productive in any of them right away.

Runs fine on Linux.

Well, now you are hitting on my real recommendation which is to use Distrobox. Distrobox allows you to install multiple userlands that are all isolated from each other but all seem native on your system and give you full access to shared files and resources ( even the GUI desktop ).

It is very common to work on something not that just has outdated packages but that targets a specific distribution. If you are building something that will target an Alpine container in the cloud, it is handle to create an Alpine Distrobox to have all the same libraries. Similarly an app might target a specific version of Ubuntu. One of the products I worked on last year was based on Ubuntu 18.04. I could easily create an Ubuntu 18.04 Distrobox to work on that.

Distrobox also means I can prevent the build-up of cruft from all the little specialty tools and dependencies that projects require that I will not need long term. Remove the Distrobox and remove all the junk.

This is different than pure Docker to Podman though since Distrobox still gives you full access to your base system. You only have to install what you uniquely need in Distrobox. So i am not necessarily installing all my tools in Distrobox. Just the specialty ones.

Anyway, this is a more complicated answer and setup. In my view, the host environment still matters a lot and what I said above still stands.

In my view, you need a distro that has up-to-date packages. It also helps to have repos that have all the obscure tools you are going to want to ensure compatibility with everything.

Those two criteria eliminate a lot of distros. Arch or an Arch derivative like EndeavourOS are my picks for these reasons.

Not the OP but he may mean that application authors have unintentionally made Windows a monopoly.

Either way, I am not sure I agree about the intentionality. App devs didn’t slip and support only Windows by accident. They may not have explicitly intended all the consequences of Windows monopoly but one dominant platform is an advantage for the app vendors too. Too many targets to support is part of what keeps commercial software off Linux.

The only ones hurt by a Windows monopoly are the consumers. Well, and commercial Windows alternatives obviously. But all the app makers are fine with it.

Valve ( makers of Steam ) can be seen as an alternative platform for gaming. This is why you see Valve investing so heavily in Linux even though they make all their money on Windows.

I cannot speak for the OP but most of the pepper claiming they are waiting will not switch. They may use an illegally patched or trimmed version of Windows 11. Many won’t even do that.

The biggest risk for Microsoft is that everybody stays on Windows 10 without updates. Or that massive customers will force them to push back the “enterprise” date over and over. To encourage migration, expect Microsoft to make Windows 10 just as bad as 11 before support expires.

Windows is a platform for Office. Linux is not a supported platform for Office. Most businesses will not migrate their desktops off Windows because they will not migrate their workforce off Office.

Beyond that, Windows is not as important to Microsoft as it used to be. The real money makers are Azure and Office. With Azure, they do not care if you run Linux. They even have their own distro ( Azure Linux — previously CBL Mariner ).

Azure is the future ( even for Office ).

Since Windows is less strategic, Microsoft is looking to milk it as a cash cow while they can. So, Product Management is tasked with finding new ways to monetize it. Data is worth a lot of money. The best way to farm data from users these days is to frame it as security ( or AI ).

Expect a lot more SIngle Sign On. Expect a lot more AI. Expect a lot more cloud integration. Expect all of these to focus on data harvesting.

A bit later, expect “services” for Linux that attempt the same. Like Google on Android. This is harder though as Windows does not have monopoly control over Linux as a platform. I am sure they are having many meetings about how to change that.

When it takes 5 days to boot, you don’t have time to wait for IF statements

So you don’t support Wayland yet?

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.

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 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.

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.

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 more feature rich I think but that said it also lacks a few things. NTFS-3G is more mature, reportedly faster ( odd for a FUSE driver ), 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.