There is a difference. vi vs emacs is about preference as is GNOME vs KDE. All can exist side by side and the fans can duke it out.
Wayland is replacing Xorg. It is not a choice between the two. It is a choice between the future or the past. That is a more bitter pill for those that choose the past.
X11 the protocol will be around for quite a while. Xwayland has no end date in sight. But the Xorg display server is going to be parked on the history shelf next to SystemV UNIX. You can still run UnixWare today but UnixWare vs Fedora (or RHEL) is not a real fight.
Wayland vs Xorg is not a fight either. Wayland is not just winning. It has already won.
Outside of Xwayland, nobody is going to invest in Xorg going forward. Most Linux desktop users have already moved to Wayland. It will be almost 100% by the end of the year. BSD and other POSIX operating systems will follow.
The BSD folks say that they will maintain Xorg themselves into the future. We will see. My guess is that it will increasingly be an option for legacy hardware only.
Arch users do not consider EOS as Arch but it absolutely is.
EndeavourOS uses the vanilla Arch kernels, the vanilla Arch repos, and the AUR. There are only a handful of packages in the EOS repos and the majority of them are theming or utils that are what you would use on Arch as well (like yay and paru). There are a few quality of life utils that are totally optional and most EOS users are probably not even aware of. Plus, I suppose, the EOS keyring and a couple of packages so that the distro identifies as EOS instead of Arch. Distro identification is the only thing that “overrrides” anything in the Arch repos.
I describe EOS as an opinionated Arch installer with sensible defaults. Once installed, it is just Arch.
It is trivial to revert EOS to vanilla Arch if you want to. I don’t think it even requires a reboot.
I have never had anything in Arch take months to fix. One tip I would have is to use both the latest kernel and an LTS. If something “breaks” with a kernel module, just boot into LTS and it is probably fine there. I also had an issue with WiFi for about a week but a quick reboot into LTS and I was good to go immediately. When I tried the latest kernel two weeks later, it had been fixed there. Something similar happened with my FaceTimeHD camera. Same solution.
My current Linux distro uses APK 3 as a package manager. Updates are already atomic without the downsides of an immutable distro.
There are situations where immutable distros make sense but, for my desktop, it feels like a lot of compromise for benefits that do not move the needle for my use case.
Security is also a focus of my distro. My desktop does mot run any server workloads. I mess with it and tinker but I already use Distrobox and a COW file system. And I run two kernels, one bleeding edge (day-to-day) and one LTS (recovery). Recovering from breakage is just not a headline issue.
I guess the other factor is that I have limited time. So, my “tinker” budget is already spent. Playing with immutable distros may change my mind about them but they are far enough down the list that it may be some time before I do.
Bootable containers are something I want to play with though.
Just recently repartitioned my MacBook:
1 GB for EFI (vfat)
2 GB for /boot (ext4)
11 GB for swap
224 GB for / (bcachefs)
Grub cannot load a kernel off bcachefs so I need ext4 to bridge the gap. Once the kernel is loaded, it has no problem using bcachefs as root.
This is a laptop. On a desktop that can handle more drives, I would split /home onto a drive of its own.
I agree with you. But there is Distrobox if you want to “bring your distro”
The best R5 SoC is about as fast as a Pi 4 and better in many ways but also much more expensive.
https://www.eswincomputing.com/en/bocupload/2024/06/19/17187920991529ene8q.pdf
R5 is improving faster than ARM. There are more companies designing R5 chips than ARM. The R5 software ecosystem is essentially ready and waiting.
For many workloads, the GPU or DSP is more important than the CPU. R5 is becoming viable for these use cases.
Automotive, automation, quality control, robotics, aI, are all within reach. The SBC market is just the mainstream version of that. And desktops are just further along the price / performance curve from there.
Chip designs take time. Then people need to license and manufacture them. We may see marketable performance on servers this year.
For SBCs, the performance has gotten to usable but price / performance sucks. That is a bit of a chicken / egg popularity problem so timing is tough to call. The rift between the US and China is slowing things down. We would have the Milk-V OASIS otherwise.
Desktop is really tough to call timing. The tech could probably be there next year. As ARM is showing though, you need a desktop OS (with market share) to drive that market. It is not going to be Apple. Microsoft cannot even make ARM work. So desktop Linux hardware on RISC-V may be a while.
Some Android phones and tablets could go RISC-V in 2026. If that happens, the same chips could appear on ITX boards for enthusiasts.
Qualcomm could surprise with RISC-V support after what ARM did to them. AheadComputing or somebody else could surprise as well. Mostly likely though, it is just going to take time.
You can run RISC-V on a “desktop” today if you want . Grab a ROMA II or Framework 13. Expect it to be slow.
Probably best he stops answering questions now. Stating positions will only limit his flexibility next election.
This one is already lost.
People recommend Mint mostly as a better Ubuntu I think. Ubuntu is still the most popular and, increasingly, not the best distro to start with.
Fedora currently fills the space that Ubuntu used to fill. Probably the biggest caveat with Fedora now is the lack of codecs by default.
Arch benefits not just from documentation but from its repo. Whatever you get told you need, it is always a relief to find it waiting there for you already tuned for your distro.
My current distro uses APK 3 as a package manager and that is already atomic. So I guess my current setup works fine, without any of the other hassles and limitations.
ffmpeg will do CPU detection and use features like AVX2 if available even on vanilla distros.
Makes very little difference
What did maximum even mean when you have a “virtual desktop” that was 4x times the size of your actual display. Because that is the kind of nonsense we used to do on Linux (because you you could and the other guys could not).
Linux was exciting but time consuming and not all that useful.
I used to bike into University, spend half the night downloading disk images of SLS, spend hours more installing, and spend hours more getting the X config timings working for my monitor. But when I was finally able to use the same window manager config as the Sun workstations at school I felt like King of the World! But what was I actually doing with it? Xterm and an ancient version of GCC.
That said, I created my own basic Shell in the early days and a few little utilities. So I learned a lot. I do not think I would even have attempted many things without the technical confidence that just being a Linux user brought. There was the feeling that you could do anything even though you were hardly doing anything. And new capabilities were constantly arriving so that feeling lasted years.
To understand how to interpret these complaints, we need to understand that Flatpak works by essentially installing a second set of libraries for your apps to run on. The apps run in a container (much like Docker) on top of these libraries. Flatpak uses the kernel and display server from your main distro but otherwise Flatpak is like a second distro unto itself.
So, if you only install a Flatpak app or two, it is very true that they will require quite a large number of support libraries to run (just like running one app on your distro is more distro than app space wise). However, as you add more apps, they they resuse the libraries that the first apps installed.
Because Flatpak installs all its own support libraries, the apps run the same on all distros (which is the point).
So, Flatapak does duplicate the libraries on your system out of necessity. Because your Flatpak apps does not use any of the libraries from your host system. However, they are only installed once inside the Flatpak environment.
The comments about vulnerabilities are neither here nor there. You have to trust your distro. You have to trust Flatpak (as a second distro). Both are subject to vulnerabilities and supply chain attacks but neither more than the other. Flatpaks are technically after as the container environment they run in “sandboxes” your Flatpak apps. In practice though, they require enough permissions that the sandbox is trivial to escape. So not much difference.
Flatpak is literally installing a second Linux distribution on your machine, just without a kernel. All the dependencies right down to the C library are installed in the Flatpak environment. This why you can run a Glibc Flatpak on a musl distro.
Microsoft could support Flatpak “natively” on Windows. It could use the same kernel and GUI glue that WSL uses but you have no need of specifying a distro or getting to the command-line. The experience could just be that you go into Flathub, install and remove apps, and everything would just work.
Apple could do the same with macOS.
If they did that, Flatpak could be a universal app distribution method on all three systems. Devs would only have to create and maintain a single version if they wanted.
Microsoft will not do that of course. If it really was a brainlessly simple alternative application store, they could OS/2 themselves and loose control of the platform.
Too bad though. It would be cool. No reason it could not be done independent of Microsoft of course but it would never be as popular if it was not built in.
Don’t confuse intelligence with knowledge. He blindly believed everything they taught him in engineering as well.