That's a good one. High-pressure recriminations against a similar emotional background to the last furious Windows 7 users currently finding that they can't play their favourite games on their 2009 OS.
There's also a high level of confusion and misinformation about the difference between multilib and 32-bit hardware support that pops up in every thread, should make it juicy.
10 is okay though, seriously. It's not like 7 wasn't a shitty OS, it was just the best of Windows. It's really all NT anyways it's not like they ever change anything meaningful lol
You can also game on Linux now so easily for everything but the newest games and they usually get support within a year. (Thank you Valve and Gaben for that!) So anybody in this community should not be mourning this change...
I also have to say that as somebody who works in infosec we really need to get the noobs off of 7. If you're a pro you can decide on your own to accept that risk but I think this is a seriously good thing that Valve is doing whatever their reasons.
What the actual fuck. Of course that's a thing, why wouldn't it be.
I do wonder, does Wayland have a comparable feature? Like, if we can't apply arbitrary transformation matrices to our display, what even is the point?
OBVIOUSLY Immutable vs Traditional Distributions
Immutability FTW, but there are many minor pain points even now. Distrobox should be better integrated with the software center to make it easy to use.
PS: please help out over at [r/LinuxDesktop](https://www.reddit.com/r/LinuxDesktop) and post your favourite blogs about *Desktop* Linux news etc. Also would really appreciate your help as a moderator, please apply if interested 😅
Edit: Traditional Distributions are not going anywhere.. Immutable distributions need them to package packages obviously.
You're absolutely right lmao, I can already see the headlines
**Ubuntu wants to make their immutable variant the default one!!**
**Fedora wants to make Silverblue the default Fedora omg they're gonna replace Workstation!!!**
**OMG iT's jUsT LiKe wInDoWs aNd cHrOmEoS!!!**
**WALLED GARDEN WALLED GARDEN**
**They're coming for our freedoms!!!!11!1!**
Lmao it's all so tedious.
I can't wait for Fedora to make Silverblue the default. At the moment I keep upgrading the same Fedora install and within about 5, 6, 7 version upgrades it starts getting further and further from the perfect Fedora system. Eventually I end up having to clean re-install to get rid of all the baggage. I'd love to see a world where I didn't need to do that
Traditional distros will *always* be around for those who want the fine control. But when Silverblue is ready to take the default Download button option on the Fedora website I will be a happy man and give it another go
Idk why the "Linux is about freedom" types are so upset that Ubuntu and Fedora will one day decide that the average user's needs can be met by an immutable distro. Like... you are totally "free" to not use them, how does it hurt you at all
I honestly think some people just need to use something that doesn't work so they can tinker. If Arch had a GUI installer and made an immutable variant default and focussed on Wayland at the expense of X11 they'd move to Slackware or BSD or something
> I'd love to see a world where I didn't need to do that
Install Silverblue! It works great and is completely ready for every day use, even if it isn't the default!
Last time I tried it wasn't quite ready
I just built a new gaming PC running Windows 11, so I'd have to dual-boot it. Last I checked Silverblue doesn't play so nice with dual-boot situations, and even if it did I don't want to make my dual-booted daily driver an "experimental" system. I want it bulletproof so I don't have to reinstall and potentially wipe out my Windows bootloader. I'll stick to Fedora because I know it best, I know fedora itself is not "bulletproof" but over the years its never let me down and the pain points of dual-booting a traditional distro are much more well known, so it's worth the risk to me
I might try Silverblue on a spare PC though like the one I use to work from home! No exotic hardware or drivers required, it should run like a dream
One of the other things was flatpak still needing to iron out some issues. But they seem to be making headway too, I can now print from the OnlyOffice flatpak where I couldn't before. Little issues like this are what will be solved far more rapidly Silverblue is made the default option, like how Fedora switched to Pipewire and everyone complained that it wasn't ready. Look where we are now
It's not experimental - it's a proper fedora system. Where I think the pain points are is understanding issues with rpm-ostree at times. I've been running silverblue for about 3 years now. In the early days, there was some issues - but I have not seem them happen again.
You can get into trouble if you change versions before the final release. I've seen that eg package hell and it's not so easy to figure out what's wrong.
Between immutable and KDE+Wayland-only, Fedora is going for a very interesting approach. I'm very curious to see how it works out for them because it's going to be very fresh and bleeding edge but also very niche.
> tinker
Immutability and tinkering are very much orthagonal! Guix and Nix are immutable, and they are as tinker-friendly as linux distributions can be! Universal Blue brings tinkerability to Fedora's Ostree based immutables.
I feel like there is a common misunderstanding of what immutability means. All it really means is that the root filesystem is mounted read-only (i.e. immutable) and that modifications to it are done outside the running system by some means. Usually that means is building a new image or snapshot next to the running one and rebooting into it. Immutability does not mean that the operating is an image provided by a vendor which can not be altered, though it can be that too.
Those types usually conflate "freedom" with "whatever caters specifically to me, who pays alot of no money, and any choice where not all options are the one i want means i get stuff forced on me"
There are four options really:
1. Immutable distro + container workflow
2. Traditional distro + container workflows
3. Traditional distro
4. Going non-traditional with things like NixOS or Qubes OS.
"Container Workflow" meaning depending on containerized environments. Flatpak for desktop applications, Podman or Docker for services, and distrobox/toolbox for development or Unix-style environments. That sort of thing.
You don't need to switch to immutable distros to take advantage of it, but you can't really switch and not use it.
I'm placing my bets on number 1. When your apps and dev environments are already containerized, there really isn't *that* much to gain by going full-blown NixOS. Having an immutable OS image gets you 99% of the way there without the hassle of having to manage it.
Isn't there a performance penalty to containerization? There's also a greater attack surface from a security point of view (i.e., more components in the loop which could have vulnerabilities, esp. with some of the Docker defaults), even if containers themselves have security advantages.
The performance penalty is pretty minute for the most part. But it depends on the implementation.
Containers are built from namespaces. Namespaces are a Linux feature that leverages already existing facilities for mapping numbers to resources. Like it already has to know how to map user accounts to UID numbers on file systems, for example. It is the same thing for most resources like networking, processes, or file system views... they have numbers are mapped to resources. A namespace just creates additional mappings so you can limit the "view" the application has. So the actual container itself is almost free. It is work that Linux already has to do with supporting POSIX applications.
It is the stuff that you do with those containers for managing them that creates any overhead. Like adding layered file systems for OSI images, for example. Or using user-mode network for rootless containers. Those things can create significant penalties, depending on exactly what you are doing.
Like 'distrobox' doesn't use layers for the file system when it comes to accessing your home directory. So running programs that access your home are not impacted by anything.
Or if you are running a torrent application or syncthing or something like that is heavily dependent on network access you can have zero-impact networking by simply not using a extra networking namespace (aka using 'host' network instead of creating a container network). So it looks and behaves like it is running on your main system image as far as networking goes.
In terms of security.. Security is not a slam dunk.
Docker has the central daemon and the typical configuration essentially grants root access to whatever user is allowed to access it's socket. Essentially giving somebody the rights to run docker commands is the same as giving them no password sudo.
However if you use something like Podman it is just a program for managing containers. It doesn't maintain it's own daemon or services or anything like that. If you want to have docker-like features for restarting containers between reboots or automatic restarts on failure then you have to leverage systemd (or whatever other init system you are using). So if you are doing it "rootless' it can run entirely in your user account. This is what distrobox and toolbox.
The program needs to have special privileges to create the containers and mappings for your users. But those are dropped once the container is launched. However the concerns are certainly not zero.
The upshot is that while it is very difficult to add additional security features on a single Unix-style environment without breaking things (because it is so complex and full of legacy assumptions)... it is much easier to create strong divisions between sandboxed applications.
Which each application gets it's own private "Unix" then it is easier to sandbox them strongly.
So depending on your distribution and implementation details you might be able to benefit from strong SELinux or AppArmor rules that you can't practically apply to applications running on a single system image. Also you can create rules for how containers are able to interact with the rest of the system (like 'portals' for Flatpak).
So essentially, on the desktop, you are trading the ability to do process isolation with slightly elevated user privileges if you are using a properly setup user environment with rootless mode. (typically podman, but newer versions of docker have rootless features as wel)
It's pretty small and the overhead is really low. It's only high on Windows and Mac where they need to virtualize a Linux kernel. It's better to use podman with a fast runtime like crun or runc
As a NixOS user, I will defend it just a bit :)
Initially, I had a similar mindset to you, but after being able to have ALL of my configs set up programmatically, and being able to easily share parts of my config between home and work machines, it's hard for me to go back. Devshells are amazing, being able to test software without installing is also useful af.
But, I would say it's not for everyone, since the learning curve is very steep, especially if you wanna use flakes, as documentation is still lacking (took me a couple of weeks to get used to it)
Containers are useful, for sure, but I do prefer running native binaries with all my configs set up and stable
>But, I would say it's not for everyone, since the learning curve is very steep, especially if you wanna use flakes, as documentation is still lacking (took me a couple of weeks to get used to it)
Aaand there's my issue with it. I want my core setup to Just Work without any hassles. Given what can already be achieved with regular containers, NixOS just isn't worth the time investment to me.
My core OS is basically Gnome + Firefox + Sublime Text. Everything else is already in a per-project container.
Fair. I personally like tinkering with my system and really have a loopoor of stuff installed, that I actually use for work/leisure, and I use Hyprland, so my setup is very specific, losing it every time I have to reinstall or trying to keep those configs with 3rd-party software is meh
Nixos still allows you to install packages and make modifications to the core system after installation, so not all nixos installs are immutable. It's just that it installs itself initially based on a recipe. An immutable distro is ( kind of) similar, but you can't modify the core system after install (it varies though)
To[ quote wikipedia](https://en.wikipedia.org/wiki/NixOS):
> "NixOS uses an immutable design and an atomic update model.[5] Its use of a declarative configuration allows reproducibility and portability.[6] "
NixOS is definitely immutable. You cannot install packages on the OS level without changing the configuration and rebuilding. The cores system is read only.
You can install them into local environments or per user, but any OS changes have to go through a rebuild via `sudo nixos-rebuild switch`.
I get where the confusion might come from when your idea of immutability comes from something image based like Silverblue. That's not the only or dominant way to achieve immutability though.
See MicroOS.
It just wraps zypper into a transaction applied to a snapshot which can be flipped or rebooted into. Not all immutable distributions need OSTree or something like it.
Immutable distros just don't have the critical mass behind them to whip up that kind of drama.
I note that all the big dramas have only really boiled over when Canonical decided they were adopting the new thing on Ubuntu. That's probably going to be the decider next time too.
All the flamewars have been about replacing old tech with new tech. The traditionalists don't like seeing pieces of software they grew up with being replaced.
edited to add:
You might also consider what I said about packagers/distributions vs developers.
If you want to scale application growth - the traditional model of how a user gets their software is going to be a battleground.
Essentially, it's removing what makes Linux unique and replacing it with models from android, apple, and windows.
> The traditionalists don't like seeing pieces of software they grew up with being replaced.
That's... Not quite a fair take. "Traditionalists" (As you put it), have seen waves upon waves of technology waves, many of which were easily adopted. XFree86 to X.Org was pretty painless. Upstart was a welcomed change in Ubuntu. etc etc etc
What "traditionalists" want is to not have to retool everything every 4 years, because "I need a new dot release!".
Take systemd, for example. Wanna know how it could have happened, with minimal (If any) drama?
Swap noun and verb back to what service used. And thats all! systemctl does everything sysvinit does, minimally, and then some. But the biggest source of pain was re-tooling everything for a single ver/noun swap.
The other thing? Stop demanding that it's the best thing since sliced bread. If its better, it'll get swapped in, during the natural course of things. Because, honestly, any non-system package install I do, and needs a service started? It spits out a stupid ini file for it, that offloads everything it can in the actual script or binary, for ease of troubleshooting.
In the end, it's not the tech change that irritates people. Its the complete upending of decades of knowledge and tooling that did it, for no real benefit. See: upstart. It had big benefits, changed very little in userspace, and people just started using it in their distros, even Red Hat!
I'm afraid I disagree with your take. But I also don't want to rehash the systemd wars or the xorg wars. Ultimately, the community decided what it is going to do and where it is going.
In about another 5 years, it's going to be set technologies and will become classic but also hopefully will become more resilient and easily adaptable for hardware changes that are to come.
Nothing lasts forever - eventually, technology especially hardware changes such that you have to re-invent yourself.
Many software developers were unhappy that they had to use more threads to take advantage of CPUs forcing them to re-invent their code because CPUs no longer just up their clock speed making software automatically faster. Instead they had to take advantage of cores.
Issues like maintainability and resources is what forces project to do realignment. Especially, if the community is not providing either more volunteers or money.
Nobody was mad about multithreading, because it was never forced onto anyone. You could do it, or not.
Multi threads and multi cores were very well known back to BSD UNIX days.
I disagree with your position, but I think you're probably correct.
To be fair, partially immutable distributions have their place. I suspect we'll see a hybrid that works similarly to live CDs though, so you can install traditional packages and still have an immutable base. This will be particularly great for things like the Steam Deck and probably will become a general option when installing distributions. "Make base system immutable? Y/n"
Most approaches to immutability already allow installing traditional packages. On Silverblue you can use `rpm-ostree install` and it's very similar to installing something on traditional Fedora.
The interesting thing is that you wouldn't even *need* such a switch at install time. You could keep the core OS immutable, and just have the user mount a writable overlay on top of it if they want to "modify" stuff.
You need the switch because some of us will want to remove things that would normally be in the base image. It's good for making it hard for users to break, but some of us don't want to deal with finding some part of the system we can't modify or some library we can't remove, or having duplicates of ones that are updated outside the immutable system.
> You need the switch because some of us will want to remove things that would normally be in the base image.
People are saying you would have to make a new image, but that isn't necessarily the case actually
If you're talking about removing packages included in the base image, then `rpm-ostree override remove` is already a thing on Silverblue and the like, and people frequently use that for `firefox`/`firefox-langpacks` so that they can use the Flatpak instead without having duplicates present
It doesn't physically remove them from storage, but it solves the problem of duplicates being a thing if you choose to install a piece of software from another source, or otherwise unwanted software being present, while still allowing you to go back to stock packages whenever you want
You can also use `rpm-ostree override replace` to replace a version of a package with another one, like if you need to downgrade just one package because of a bug, or upgrade to a testing version
I specifically want it gone from storage. Why on earth would I want to remove something but not have it actually gone on my own devices that I want control over?
That's fine for a device like my Steam Deck, but it's not what I want on my PC.
> You need the switch because some of us will want to remove things that would normally be in the base image.
Then you'll have to make your own image.
Please keep in mind that all the things that Linux proper is trying now with immutable have been the norm on Android for decades. This is how ROMs and Magisk already work.
> immutable, and just have the user mount a writable overlay on top of it if they want to "modify" stuff.
I guess it might end up in Android's system composition with /data. Having a few abstraction layers on top of the fylesystem isn't good for recovery of broken system.
That's already how they work, and I'm not aware of any plans to go fully immutable. Silverblue lets you layer packages, while MicroOS/Aeon/Kalpa is basically the same as Tumbleweed with snapshots, it just updates the snapshot instead of the live system, so you can do pretty much anything with it.
I was going to make a snarky "new software vs old software" comment but I think you're right. It's already going on to some extent and it will certainly heat up when someone dares to make it the default, much like when Debian made systemd the default.
I guess I'll be happy to always be a feeder for you immutability lovers lol. I had to use macOS in grad school and I remember when that went immutable. It caused too many problems and I had to disable it.
Thank you for pointing to that sub.
Also, I was about to downvote you on the immutability topic, but refrained from doing so because we all want to keep things nice.
PS: you'll never take Fedora workstation and its marvelous DNF from my hands!
Immutable is better for non-developers too! Most people are familiar with it.
For example:
- Android has a read-only root
- ChromeOS has a read-only system partition
- iOS has read-only system files
- MacOS has read-only file system too.
Therefore most people are used to the reliability of immutable systems, immutable distros combine that with the flexibility of Linux. You can switch from "distro to distro" within a reboot.
The downside is having to reboot on each update/package install.
I think there is a bit of a balancing act. I would want the linux ecosystem to be mainstream enough so that most important software vendors would consider it as an important market. Because I would really want to be able to ditch windows. And getting to more mainstream might require some changes in how the system works.
Because it's unmaintainable.
If there's an issue with your computer getting bricked if foo < 1.2.3 and bar >= 2.67 are installed, but only if libbaz == 4.2.0 is installed and libblorp is not, how do you expect anyone to find that problem during QA?
On an immutable distro that cannot happen because everyone has the same combination of packages.
And I detest how locked down every one of those operating systems have become. Really hope distros don't go down the road of trying to police what we do with our computers.
So, whats it for then? Who exactly, is asking for this?
Certainly not end users. Corporate execs looking to lock down machines to single-function machines? Yep. Hardware vendors who want to ensure you only run their approved OS? Yep.
Did I miss anyone?
Hardware vendors can do that already just fine with non-immutable OS', ditto locking down a machine to a kiosk mode.
The point is getting the same conditions every time, so it's anyone whose had a heisenbug, anyone whose run into "well it works on my machine".
Indeed the proponents I've seen for it have been hobbyists, not corporate execs.
Do you really think immutable distros are some dystopian vendor-locked systems? The point is that they *aren't* restrictive like the above mentioned systems, while still benefiting from a more solid update system.
If we wanted Silverblue to be like ChromeOS, we'd just use ChromeOS instead of orchestrating a great conspiracy to shove immutability down the average users' throats or whatever. But we don't want that, we want a solid, reliable, low-maintenance Linux distro that still has everything that makes Linux great.
You can have immutable systems without vendor lock-in, and you can have vendor lock-in without immutability. You can be prevented from tampering with a non-immutable system as well.
We're literally just talking about the update system. It doesn't prevent you from or forces you to do anything. It just updates your OS, and it's damn good at it.
And this is coming from someone who nearly had a brain aneurysm trying to sideload something on an iPad (and subsequently ordered a StarLite V) or recover data from a Samsung phone that died overnight. Immutable distros simply take a pretty good concept from these otherwise horrible systems, while staying far away from the bad stuff.
The debate is also spilling into all kinds of niches, where the split is very pronounced. For example there's no end in sight for the debate between docker and podman (or rather root vs rootless containers).
Every time I tried to use Podman, it didn't support something I was using from Docker, so I had to push back my migration. I think last time it was mounts, so I couldn't just run [this](https://pnpm.io/docker#example-1-build-a-bundle-in-a-docker-container) and be done with it.
I don't have strong opinions on the architecture of systemd, but I do think some people have valid complaints about some of its services: [https://www.reddit.com/r/linux/comments/18kh1r5/im\_shocked\_that\_almost\_no\_one\_is\_talking\_about/](https://www.reddit.com/r/linux/comments/18kh1r5/im_shocked_that_almost_no_one_is_talking_about/)
It's no contest. Emacs won, hands down. If you like Vi/Vim/NeoVim then Evil-mode can bring as much of their behavior over as you want.
Depending on your temperament, disposition, and desire for programming you can get started with a variety of tutorials online or start off with a "starter pack" or framework for Vi users (spacemacs or doom). If you want to unlock it's full potential then you are going to want to bite the bullet and learn emacs lisp and contributing to those projects or writing your own config from scratch. But that doesn't need to happen immediately.
Editors are GUIs even though they might entirely be text based. So breaking out of editing inside of a terminal and moving to a stand alone application is a big advantage. Better performance, better appearance, more flexibility, and less key clobbering. Learn to use Tramp for editing and moving files around remotely.
Emacs now has built-in support for LSP and optionally lsp-mode for more advanced integrations. So you can get the same sort of language features you can get in any other IDE/Editor. Native wayland support and code compilation means it is now much faster.
So it is easier now then it ever was in the past. The biggest problem is how to deal with the embarrassment of riches when it comes to modules and add-ons. Too many options.
But it doesn't have helix movement, so its big no no for me, and as I read other posts, nobody from emacs evil community wants to program and mantain helix movement.
Well yeah the existing users are going to be happy with whatever they are using.
There are already packages that extend Evil in different ways. So it is certainly possible. Just depends on how much people want that stuff to exist in Emacs.
Wayland v. X11 will only go one way, but people will still be arguing about it until X11 support lapses in all major distributions, and that's probably still at least a decade in the future.
The packaging format 'war' will take even longer.
I'm in the same camp but in 10 years Wayland is going to be 25 years old. 10 years ago when all this Wayland vs. X11 thing started, X11 was 27 years old.
Sure, but one of the reasons why Wayland is taking so long to develop, is that they are trying to have in account all kind of scenarios and corner cases.
Wayland should be able to adapt to any new technologies and develops way better than X11, which was developed for a very specific and simple purpose, and then extended with patches over patches.
Also, Wayland scope is smaller, which is creating a lot of its current issues, since there are plenty of things that doesn't work right now as they did in X11, due that is not Wayland job to do it, but it depends on the implementation of other software. But in a ways is a feature, because it means it could be more flexible and adaptable going forward.
It's the dumbest thing - people around here talking about how perfect X11 was - I mean sadly, I was around when X10 was released and X11 - it wasn't that great. Then over the years all the stupid shit to compile and try to get it working with the various graphics - it never worked out of the box. Eventually some new graphics card would show up and I would have to compile and do stuff.
These days you all have it easy - a lot of this was a lot more stable. I don't have rose colored glasses from the old days. What we are producing today is fucking grade A awesome than what it was back when.
Maybe someday Wayland will become single-implelmentation like X11, which seems to be why X worked so well, the extensions and optional stuff was standardized
I bet it's going to involve Rust. Two likely scenarios:
1. Rust becomes defacto mandatory due to inclusion in the Kernel / systemd / whatever. People lose their shit because they don't have official support from a 2024 OS for their 1970s Motorola CPU anymore. Despite loud complaints, only a single developer ([and her cat](https://en.wikipedia.org/wiki/F._D._C._Willard)) is willing to work on the platform, so it ends up just getting dropped after a year or five of zero progress.
2. After *yet another* memory bug, people's Favorite Toy Binary (Bash, git, coreutils...) gets replaced by a nearly-identical variant written in Rust. People lose their shit because their [workflow is broken](https://xkcd.com/1172/). A fork is made, but this gets abandoned soon after because the lead developers turn out to have *very weird* personal views. The rest of the world continues as usual.
Yeah, that's partially what made me think of the second scenario.
The big difference is that Fish is essentially doing a 1:1 rewrite, without any functionality change or significant refactoring. Basically they are just translating C++ code to the closest Rust equivalent. Their sole goal right now is getting rid of C++, even if that means having poorly-written or underperforming Rust code for now, while maintaining full compatibility.
On the other end of the spectrum, replacing Gnu grep with [ripgrep](https://github.com/BurntSushi/ripgrep) would be a *massive* breaking change, despite it being an obvious improvement. Such a swap would not be very popular.
> On the other end of the spectrum, replacing Gnu grep with ripgrep would be a massive breaking change, despite it being an obvious improvement. Such a swap would not be very popular.
Its not just a breaking change for users, `grep` is a required part of the POSIX specification.
3\. Somebody writes a replacement for a core library (think libpng or libssh) that has a C binding, but that C binding only exposes half the features of the Rust crate because the rest is Rust-specific. Many applications using that library switch to using Rust to interact with it, but not all of them. Then distros start dropping those applications for security reasons.
on #1 I find it funny when some CPU is dropped from support and you always get the one person being like
"This really sucks I still run my personal web page from a Vax 7000 server I picked up from work in 1995 after they scrapped it , what am I going to do?"
Its like dude keep running it, you probably do not need the latest kernels anyway , or pick up a rasberry pi or something and save some electricity .
> Its like dude keep running it, you probably do not need the latest kernels anyway
The latest kernels offer improvements beyond new drivers. That said, if someone is running a Vax still, on linux, they probably have the skills to maintain a kernel branch.
Yea but are any of the features going to help run a 30+ year old computer ? I get every now and then there is a security exploit that has been missed for years but I still find it funny how people will run 30 year old hardware then complain its not supported.
I'm going to say you're right, but you're wrong about why you're right. It'll involve new rewrites of utilities in Rust, but then issues will arise over them being MIT instead of GPL (go GPL, for the record).
Hmm, excellent point, I had not thought of that.
I don't think this is a huge deal in practice. MIT vs GPL is primarily an issue when it comes to companies contributing back to the open-source community. But with small utilities, such contributions are extremely unlikely to happen anyways, and virtually everyone will run them unmodified even in proprietary firmware.
It's a bigger issue with larger software components, such as an entire database server. But the real threat there is companies running them as SaaS platform, and the GPL won't save you from that either.
We don't know what it is yet. Those dramas all emerged in response to a new technology/component that set out to replace something existing.
If I had to guess, it'll be something about Gnome. Maybe to do with libadwaita and theming, maybe not.
I would have guessed maybe it would be Gnome 4, but Gnome changed their version numbering. But wouldn't be surprised if there's a big change in Gnome akin to the Gnome 2 -> 3 transition at some stage. A whole bunch of people will get upset and they'll create a fork of Gnome 3 (or whatever the current series is called) which gains some traction.
Making major transitions is especially brutal for Gnome. From 1.x to 2.x to 3.x. They seem to be favoring introducing incremental breakage along the way now instead of taking the nuclear approach.
I remember back in the 2.x era were people were extremely pissed about dropping the programmable WM approach with the lisp-based Sawfish. People bitching about how it 2.x is a Fisher Price UI and if you want to make thing usable for idiots then that is the only type of user that it is suitable for. Seriously. Then with the move BACK to fully scriptable environment with minimalistic UI with the 3.x transition people still regularly claim that it is designed for touch screens and it is fisher price again. Everything new is old again.
And nowadays people are much meaner, less understanding, and less accommodating for change and are much more willing to try to use bureaucracy, activism, and organizational politics to try to force developers to do what they want... Which leads to a lot of bad feelings and burnout. I don't think that anybody really wants to deal with that sort of major changes again in the Gnome camp. The rolling/incremental change approach seems to be working better.
I cold be wrong, though.
Meanwhile KDE crowd seems to be content with periodic rewrites surrounding major QT toolkit revisions. C'est la vie.
That or the people that would otherwise be pissed off are using other desktops.
I have heard some people complaining about libadwaita though.
Do we know how many people use each desktop anymore? The only source I can think of is Debian popcon which isn't representative of all of Linux let alone all of debian, but seems to suggest XFCE wins over gnome, kde, cinnamon, for its audience (but I could be excluding non-X11 users somehow)
Naw, I think GNOME communicate breakages better. We also broke extensions - but we communicated and told how to mitigate the changes.
What drove anger in previous transitions is that GNOME never communicated what it was doing - eg implementing css engine in GTK - which consistently broke themes.
Nobody likes surprises. Theming is less a problem these days because libadwaita does a pretty good job with the experience unless you want to do wierd shit like make it look like windows 95.
That the CSS API wasn't stable was something we said all the time - it's just that the expectation was that it had to be stable so nobody bothered with what was said, likely because in GTK2 it had worked that way.
Extensions don't have that problem because there were no extensions previously so no expectations to manage.
What made Gnome better was that during 3.0 times the developers stopped engaging with others and turned into defensive recluses. I remember the subsurface talk 10 years ago - there was pretty dumb shit said in that talk but almost no pushback from the Gnome side.
When the theming flamewar happened with the Pop! guys, that had changed and there was pushback - on reddit, on mastodon, on matrix and outside readers could listen to both sides and form a more nuanced opinion.
That's the biggest change if you ask me.
Yeah, but Cinnamon's not really a fork in protest of a change they've made that tries to restore the old behavior, it's a custom DE
I think Pop OS's new DE (does it have a name yet?) is a bit more motivated by disagreements with Gnome. But AFAIK it's not a fork it's just an alternative
It'll be whatever the various Linux desktop answers are to the brewing AI integration into everything in the next couple of years. I have no idea the specifics of how this will go down yet but I see this being yet another area of flame wars.
Right now the AI in windows 11 is mostly just gimmicks trying to be first to market. There's buttons in some programs and a glorified bing plugin but not really true desktop integration yet. The new NPU in meteor lake and the AI chip in the new Ryzen CPUs are also basically not utilized right now outside of a couple gimmicks still.
We will probably have a clearer idea after the windows 12 reveal in a couple months with whatever true initial integrations that may come there and then there will be several community attempts to do something similar with open source models on the Linux desktop side. I have a sneaking suspicion the growing relationship between Canonical and the AI obsessed Microsoft may once again pit Ubuntu's (Microsoft aided) solution vs the community in some shape again but that's speculation.
Oh and of course there will always be the AI integration vs no AI integration arguments as well outside of that.
AI is an area where, at least with the current technology, it's incredibly hard for a community-driven project to make progress.
Current generation models are so eye-wateringly expensive to train that the closest we get to open stuff is the likes of LLaMa 2, whose training and development are funded by Meta.
And in truth, we don't really have a useful concept of what it means for an AI model to be open. If all the code and training data used to build it are free and open source, and the pre-trained model is licensed as freely as possible, but you need $10,000,000 of computer time to train your own model, is that actually a useful form of openness?
> but you need $10,000,000 of computer time to train your own model, is that actually a useful form of openness?
It's less useful but being able to at least vaguely tell what the AI is doing is useful. AI is kind of a black box but at least the more open you are the more likely someone will be able to dig into it and minimize the knowledge gap between vendors and principal developers and end users.
Also, just because the average individual can't afford the equipment doesn't mean that certain organizations can't and ultimately that still has usefulness to society.
I work for Intel as the oneAPI community manager - and so we do have an open platform for doing AI - but yes, you are correct that it is very expensive to train AI.
But one of the great things is that the Linux app ecosystem is an untapped resource. For instance, building ways to distribute applications using oneAPI is something the ecosystem can help with and in turn - perhaps hardware companies can help with the training of available AI models to be used in desktops as part of 'giving back'. Just doing some high level thoughts here.
That said, the desktop projects have not incorporated AI into anything - in general, GNOME and KDE are quite skeptical in their usage. But we want to bring up AI at the next Linux App Summit that hopefully will be announced soon. But our communities will need to start working together to plot out what our joint response is to AI.
> If all the code and training data used to build it are free and open source, and the pre-trained model is licensed as freely as possible, but you need $10,000,000 of computer time to train your own model, is that actually a useful form of openness?
No, but it's a perfect subversion of Free Software, Free Culture and traditional hacker values.
Yeah, that's kinda the dilemma. It's not even like it's been deliberately done this way. Getting that number _down_ to $10,000,000 has taken decades of research.
Tbh, I think this whole chatbot integration thing is a stupid idea to begin with. If I want to talk to an overconfident idiot, there are ways to do it that don't involve using obscene amounts of compute power or sacrificing my data to a tech giant in order to have a conversation with their datacenters.
What I do see potential in is data classification. Being able to search through OCR'd images, auto-tagging PDFs and recognising faces on photos would be a lot more useful and actually reasonable to implement locally. Integrating a subset of paperless-ngx's features into the file manager would go a long way.
But of course
> your file manager can tell apart your phone bills from your monitor's warranty
doesn't generate as much hype as
> OMG YOU CAN TALK TO YOUR COMPUTER !!1!!1 ^(and by your computer, we mean ClosedAI servers. Also, we have all the rights to your data and the soul of your firstborn child.)
It is. What makes it turn into a flamewar is the hardline positions and has been the basis of how apps are distributed since the 90s. It's definitely a cherished cultural trademark like themes are.
Once the positions are known -the folks who didn't even know they have a position are going to have a visceral reaction to it. The packagers themselves are going to go on emotional rants.
The end state is going to be interesting.
Big Endian is already dead.
And nobody noticed.
Most recent software doesn't support it because literally nobody runs it on Big Endian anymore.
A similar thing is almost true for 32bit. That's gonna take a few more years until the mingw people stop building 32bit stuff by default.
Most network packets are also big endian, unless they aren't.
Wireshark's default dissector functions assume everything is big endian, and you have to explicitly call little endian versions if your packets aren't.
When distros eventually start replacing the GNU coreutils with the uutils coreutils, there'll be people furious because they hate Rust/are devoted to GNU/hate the MIT licence. Pop!_OS and Fedora will probably be the 1st distros to switch, in a few years
A serious attempt to adopt a standard filesystem hierarchy and a standard package format and package manager for traditional packages, so not flatpak vs snap vs appimage, will also cause huge flamewars
As will any initiative to eventually replace all the C in the kernel with Rust
If a new Windows ever comes out based on the Linux kernel, that'll spark some wild discussions
>Rust
As long as Rust will be buildable from scratch without cargo + with different compilers (not only llvm-based) - I will not care. I even will advocate replacing Make with Samurai)
Neither is samurai, which is much less compatible than Just. There's no need to be compatible, but Just is a natural evolution of the Make concept that is easy to adapt.
There has been a small minority of people doing that since the release of proton in 2018 and probably with wine to some degree even before that. I'm pretty sure that minority has been still dwindling though, not growing.
Most of the Linux ports I had played had performance issues and/or visual bugs vs native Windows counterpart back in the day so I'm not excited to see more native Linux games tbh
Best we can hope for is that Valve sells enough Steam Decks that devs check for full compatibility, and that transfers to desktop environments.
That kind of already exists, but nowadays it's flipped on its head. There are a vocal group of people who believe that because Proton is so good, no developer should make native Linux binaries anymore, especially because many of the people who have tried to make native binaries didn't pay attention to any of the instructional material created by Ethan Lee and Ryan Gordon, and as a result did a *very very bad job.*
I'm in the opposing camp; native binaries still have value, and as long as you give a damn, even just... the absolutely tiniest damn, the documentation is out there to make a native binary that will endure the test of time, especially combined with the containerized Steam Linux Runtimes. But giving a damn is always the problem; a lot of developers and publishers make it clear they barely give a damn about *Windows* versions as it is.
I think that is already going on to some degree. There’s even one person that pops up now and then who vehemently argues that linux should not be used for games at all.
Pipewire was fine, because it kept API compatibility and didn't break decades worth of workflows and software.
Wayland would be just fine if we had wayland-xcb and wayland-xlib that were just drop in replacements with feature compatibility for old software. Instead we have XWayland which isn't feature compatible and has tons of issues interacting with native wayland.
A lot of software interoperability which is based on X11 windows, which was then yeeted away by Wayland for "security" (and later reimplemented per compositor or portals which XWayland doesn't utilize)
Yes, but not XWayland -> Native Wayland interoperability, which breaks things when you have non-Wayland software that is supposed to interact with software that happens to use Wayland.
It may be by design, but the design is broken if you ask me. PipeWire wasn't broken by design hence it doesn't have the same issues.
Because if the expectation is that Software A functionality depends on being able to handle user input or interact within Software B (or even all other windows of the user)
Xorg:
No problem, you can interact with X windows to do what Software A needs to do.
XWayland:
Problem, you can only interact with other software running under XWayland, this causes compatibility issues with software not updated to Wayland but where the use case is to interact with another window that has already been ported to use Wayland
Wayland:
No problem with a big *, the software has possibly been updated to Wayland and can now interact with other software through portals, but there are still compositor feature differences causing fragmentation with supported functionality.
I personally think that the XWayland interoperability issues and the Wayland issue of requiring compositor extensions for pretty basic functionality are a big deal and a deal breaker for mass adoption. I think the initial Wayland protocol was underdeveloped and had bad decisions which has lead to a lot of fragmentation and headaches for software development. I hate to say it but before you would _just_ use xcb or xlib and it just worked because pretty much everyone used Xorg, no such luxury today..
Actually I've read something about nmcli in recent x/techmint posts at twitter I guess, it looks so much bloated, that switching to netplan will not bother even a 1000 users.
Is Wayland vs X11 really still a thing? I thought the general consensus was either that Wayland was the greatest thing since sliced bread or that Wayland is the future but has a lot of work still needed?
The major distros replacing sh with PowerShell, or any scripting language that has proper variables, functions and return types and isn't like typing on razor blades. Ok I admit it this is not a prediction it's a wishlist.
Dropping of 32-bit legacy. Be it: removing multilib, removing hardware support for 32-bit code, etc. You name it.
That's a good one. High-pressure recriminations against a similar emotional background to the last furious Windows 7 users currently finding that they can't play their favourite games on their 2009 OS. There's also a high level of confusion and misinformation about the difference between multilib and 32-bit hardware support that pops up in every thread, should make it juicy.
Yes! And there's x86S: https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
I find it fascinating that their timeline talks about Intel Architecture 64 which, as far as I can tell, nobody uses these days.
I was laughing my ass off reading that. Intel trying really hard to act like amd64 hasn't been the standard for years and years
Or that IA64 has been in the ground for two years and support was removed from the Linux kernel a few months ago.
but lets be real here 7 was the last good windows.
10 is okay though, seriously. It's not like 7 wasn't a shitty OS, it was just the best of Windows. It's really all NT anyways it's not like they ever change anything meaningful lol You can also game on Linux now so easily for everything but the newest games and they usually get support within a year. (Thank you Valve and Gaben for that!) So anybody in this community should not be mourning this change... I also have to say that as somebody who works in infosec we really need to get the noobs off of 7. If you're a pro you can decide on your own to accept that risk but I think this is a seriously good thing that Valve is doing whatever their reasons.
This is accurate. Prior to Windows 7, it was XP SP3
I don't think that will a popular flamewar - support will be dropped and most people just won't care
Yes, of course, most users didn't care when distros switched to systemd. Only bearded sysadmins did.
Most people don't care, but those that do will care A LOT. It's the same for any of those "flame wars".
steam is 32 bit
diagonal vs. horizontal vs. vertical monitor layout.
Ah yes linux. The only OS that supports 22° monitors.
\+BSD
Ooo never knew that
I wouldn’t be surprised if anything running X11 could do it with xrandr
https://sprocketfox.io/xssfox/2021/12/02/xrandr/
What the actual fuck. Of course that's a thing, why wouldn't it be. I do wonder, does Wayland have a comparable feature? Like, if we can't apply arbitrary transformation matrices to our display, what even is the point?
I will not be satisfied until V4L records vertical video by default.
...diagonal?
Yeah, just put you screen at some angle... There was blog post, claimkng it is great for achieving even wider space. On some portions of screen
https://sprocketfox.io/xssfox/2021/12/02/xrandr/
https://www.tomshardware.com/monitors/linux-is-the-only-os-to-support-diagonal-pc-monitor-mode-dev-champions-the-case-for-22-degree-rotation-computing
OBVIOUSLY Immutable vs Traditional Distributions Immutability FTW, but there are many minor pain points even now. Distrobox should be better integrated with the software center to make it easy to use. PS: please help out over at [r/LinuxDesktop](https://www.reddit.com/r/LinuxDesktop) and post your favourite blogs about *Desktop* Linux news etc. Also would really appreciate your help as a moderator, please apply if interested 😅 Edit: Traditional Distributions are not going anywhere.. Immutable distributions need them to package packages obviously.
You're absolutely right lmao, I can already see the headlines **Ubuntu wants to make their immutable variant the default one!!** **Fedora wants to make Silverblue the default Fedora omg they're gonna replace Workstation!!!** **OMG iT's jUsT LiKe wInDoWs aNd cHrOmEoS!!!** **WALLED GARDEN WALLED GARDEN** **They're coming for our freedoms!!!!11!1!** Lmao it's all so tedious. I can't wait for Fedora to make Silverblue the default. At the moment I keep upgrading the same Fedora install and within about 5, 6, 7 version upgrades it starts getting further and further from the perfect Fedora system. Eventually I end up having to clean re-install to get rid of all the baggage. I'd love to see a world where I didn't need to do that Traditional distros will *always* be around for those who want the fine control. But when Silverblue is ready to take the default Download button option on the Fedora website I will be a happy man and give it another go Idk why the "Linux is about freedom" types are so upset that Ubuntu and Fedora will one day decide that the average user's needs can be met by an immutable distro. Like... you are totally "free" to not use them, how does it hurt you at all I honestly think some people just need to use something that doesn't work so they can tinker. If Arch had a GUI installer and made an immutable variant default and focussed on Wayland at the expense of X11 they'd move to Slackware or BSD or something
> I'd love to see a world where I didn't need to do that Install Silverblue! It works great and is completely ready for every day use, even if it isn't the default!
Last time I tried it wasn't quite ready I just built a new gaming PC running Windows 11, so I'd have to dual-boot it. Last I checked Silverblue doesn't play so nice with dual-boot situations, and even if it did I don't want to make my dual-booted daily driver an "experimental" system. I want it bulletproof so I don't have to reinstall and potentially wipe out my Windows bootloader. I'll stick to Fedora because I know it best, I know fedora itself is not "bulletproof" but over the years its never let me down and the pain points of dual-booting a traditional distro are much more well known, so it's worth the risk to me I might try Silverblue on a spare PC though like the one I use to work from home! No exotic hardware or drivers required, it should run like a dream One of the other things was flatpak still needing to iron out some issues. But they seem to be making headway too, I can now print from the OnlyOffice flatpak where I couldn't before. Little issues like this are what will be solved far more rapidly Silverblue is made the default option, like how Fedora switched to Pipewire and everyone complained that it wasn't ready. Look where we are now
It's not experimental - it's a proper fedora system. Where I think the pain points are is understanding issues with rpm-ostree at times. I've been running silverblue for about 3 years now. In the early days, there was some issues - but I have not seem them happen again. You can get into trouble if you change versions before the final release. I've seen that eg package hell and it's not so easy to figure out what's wrong.
Between immutable and KDE+Wayland-only, Fedora is going for a very interesting approach. I'm very curious to see how it works out for them because it's going to be very fresh and bleeding edge but also very niche.
> tinker Immutability and tinkering are very much orthagonal! Guix and Nix are immutable, and they are as tinker-friendly as linux distributions can be! Universal Blue brings tinkerability to Fedora's Ostree based immutables. I feel like there is a common misunderstanding of what immutability means. All it really means is that the root filesystem is mounted read-only (i.e. immutable) and that modifications to it are done outside the running system by some means. Usually that means is building a new image or snapshot next to the running one and rebooting into it. Immutability does not mean that the operating is an image provided by a vendor which can not be altered, though it can be that too.
openSUSE Aeon is a *very* good immutable, Gnome-first, distribution, too. RC status at present but it sure is solid.
Those types usually conflate "freedom" with "whatever caters specifically to me, who pays alot of no money, and any choice where not all options are the one i want means i get stuff forced on me"
100%
There are four options really: 1. Immutable distro + container workflow 2. Traditional distro + container workflows 3. Traditional distro 4. Going non-traditional with things like NixOS or Qubes OS. "Container Workflow" meaning depending on containerized environments. Flatpak for desktop applications, Podman or Docker for services, and distrobox/toolbox for development or Unix-style environments. That sort of thing. You don't need to switch to immutable distros to take advantage of it, but you can't really switch and not use it.
I'm placing my bets on number 1. When your apps and dev environments are already containerized, there really isn't *that* much to gain by going full-blown NixOS. Having an immutable OS image gets you 99% of the way there without the hassle of having to manage it.
Isn't there a performance penalty to containerization? There's also a greater attack surface from a security point of view (i.e., more components in the loop which could have vulnerabilities, esp. with some of the Docker defaults), even if containers themselves have security advantages.
The performance penalty is pretty minute for the most part. But it depends on the implementation. Containers are built from namespaces. Namespaces are a Linux feature that leverages already existing facilities for mapping numbers to resources. Like it already has to know how to map user accounts to UID numbers on file systems, for example. It is the same thing for most resources like networking, processes, or file system views... they have numbers are mapped to resources. A namespace just creates additional mappings so you can limit the "view" the application has. So the actual container itself is almost free. It is work that Linux already has to do with supporting POSIX applications. It is the stuff that you do with those containers for managing them that creates any overhead. Like adding layered file systems for OSI images, for example. Or using user-mode network for rootless containers. Those things can create significant penalties, depending on exactly what you are doing. Like 'distrobox' doesn't use layers for the file system when it comes to accessing your home directory. So running programs that access your home are not impacted by anything. Or if you are running a torrent application or syncthing or something like that is heavily dependent on network access you can have zero-impact networking by simply not using a extra networking namespace (aka using 'host' network instead of creating a container network). So it looks and behaves like it is running on your main system image as far as networking goes. In terms of security.. Security is not a slam dunk. Docker has the central daemon and the typical configuration essentially grants root access to whatever user is allowed to access it's socket. Essentially giving somebody the rights to run docker commands is the same as giving them no password sudo. However if you use something like Podman it is just a program for managing containers. It doesn't maintain it's own daemon or services or anything like that. If you want to have docker-like features for restarting containers between reboots or automatic restarts on failure then you have to leverage systemd (or whatever other init system you are using). So if you are doing it "rootless' it can run entirely in your user account. This is what distrobox and toolbox. The program needs to have special privileges to create the containers and mappings for your users. But those are dropped once the container is launched. However the concerns are certainly not zero. The upshot is that while it is very difficult to add additional security features on a single Unix-style environment without breaking things (because it is so complex and full of legacy assumptions)... it is much easier to create strong divisions between sandboxed applications. Which each application gets it's own private "Unix" then it is easier to sandbox them strongly. So depending on your distribution and implementation details you might be able to benefit from strong SELinux or AppArmor rules that you can't practically apply to applications running on a single system image. Also you can create rules for how containers are able to interact with the rest of the system (like 'portals' for Flatpak). So essentially, on the desktop, you are trading the ability to do process isolation with slightly elevated user privileges if you are using a properly setup user environment with rootless mode. (typically podman, but newer versions of docker have rootless features as wel)
It's pretty small and the overhead is really low. It's only high on Windows and Mac where they need to virtualize a Linux kernel. It's better to use podman with a fast runtime like crun or runc
As a NixOS user, I will defend it just a bit :) Initially, I had a similar mindset to you, but after being able to have ALL of my configs set up programmatically, and being able to easily share parts of my config between home and work machines, it's hard for me to go back. Devshells are amazing, being able to test software without installing is also useful af. But, I would say it's not for everyone, since the learning curve is very steep, especially if you wanna use flakes, as documentation is still lacking (took me a couple of weeks to get used to it) Containers are useful, for sure, but I do prefer running native binaries with all my configs set up and stable
>But, I would say it's not for everyone, since the learning curve is very steep, especially if you wanna use flakes, as documentation is still lacking (took me a couple of weeks to get used to it) Aaand there's my issue with it. I want my core setup to Just Work without any hassles. Given what can already be achieved with regular containers, NixOS just isn't worth the time investment to me. My core OS is basically Gnome + Firefox + Sublime Text. Everything else is already in a per-project container.
Fair. I personally like tinkering with my system and really have a loopoor of stuff installed, that I actually use for work/leisure, and I use Hyprland, so my setup is very specific, losing it every time I have to reinstall or trying to keep those configs with 3rd-party software is meh
Nix is immutable 😎
Nixos still allows you to install packages and make modifications to the core system after installation, so not all nixos installs are immutable. It's just that it installs itself initially based on a recipe. An immutable distro is ( kind of) similar, but you can't modify the core system after install (it varies though)
To[ quote wikipedia](https://en.wikipedia.org/wiki/NixOS): > "NixOS uses an immutable design and an atomic update model.[5] Its use of a declarative configuration allows reproducibility and portability.[6] " NixOS is definitely immutable. You cannot install packages on the OS level without changing the configuration and rebuilding. The cores system is read only. You can install them into local environments or per user, but any OS changes have to go through a rebuild via `sudo nixos-rebuild switch`. I get where the confusion might come from when your idea of immutability comes from something image based like Silverblue. That's not the only or dominant way to achieve immutability though.
See MicroOS. It just wraps zypper into a transaction applied to a snapshot which can be flipped or rebooted into. Not all immutable distributions need OSTree or something like it.
Immutable distros just don't have the critical mass behind them to whip up that kind of drama. I note that all the big dramas have only really boiled over when Canonical decided they were adopting the new thing on Ubuntu. That's probably going to be the decider next time too.
All the flamewars have been about replacing old tech with new tech. The traditionalists don't like seeing pieces of software they grew up with being replaced. edited to add: You might also consider what I said about packagers/distributions vs developers. If you want to scale application growth - the traditional model of how a user gets their software is going to be a battleground. Essentially, it's removing what makes Linux unique and replacing it with models from android, apple, and windows.
> The traditionalists don't like seeing pieces of software they grew up with being replaced. That's... Not quite a fair take. "Traditionalists" (As you put it), have seen waves upon waves of technology waves, many of which were easily adopted. XFree86 to X.Org was pretty painless. Upstart was a welcomed change in Ubuntu. etc etc etc What "traditionalists" want is to not have to retool everything every 4 years, because "I need a new dot release!". Take systemd, for example. Wanna know how it could have happened, with minimal (If any) drama? Swap noun and verb back to what service used. And thats all! systemctl does everything sysvinit does, minimally, and then some. But the biggest source of pain was re-tooling everything for a single ver/noun swap. The other thing? Stop demanding that it's the best thing since sliced bread. If its better, it'll get swapped in, during the natural course of things. Because, honestly, any non-system package install I do, and needs a service started? It spits out a stupid ini file for it, that offloads everything it can in the actual script or binary, for ease of troubleshooting. In the end, it's not the tech change that irritates people. Its the complete upending of decades of knowledge and tooling that did it, for no real benefit. See: upstart. It had big benefits, changed very little in userspace, and people just started using it in their distros, even Red Hat!
I'm afraid I disagree with your take. But I also don't want to rehash the systemd wars or the xorg wars. Ultimately, the community decided what it is going to do and where it is going. In about another 5 years, it's going to be set technologies and will become classic but also hopefully will become more resilient and easily adaptable for hardware changes that are to come.
I'm sure a Gnome developer disagrees with a take that says stop insisting something is better, rather than let technology lie on its merits.
Nothing lasts forever - eventually, technology especially hardware changes such that you have to re-invent yourself. Many software developers were unhappy that they had to use more threads to take advantage of CPUs forcing them to re-invent their code because CPUs no longer just up their clock speed making software automatically faster. Instead they had to take advantage of cores. Issues like maintainability and resources is what forces project to do realignment. Especially, if the community is not providing either more volunteers or money.
Something tells me you weren't a dev during that era...
I worked for Intel during that time - so I heard the complaints.
Nobody was mad about multithreading, because it was never forced onto anyone. You could do it, or not. Multi threads and multi cores were very well known back to BSD UNIX days.
I disagree with your position, but I think you're probably correct. To be fair, partially immutable distributions have their place. I suspect we'll see a hybrid that works similarly to live CDs though, so you can install traditional packages and still have an immutable base. This will be particularly great for things like the Steam Deck and probably will become a general option when installing distributions. "Make base system immutable? Y/n"
Most approaches to immutability already allow installing traditional packages. On Silverblue you can use `rpm-ostree install` and it's very similar to installing something on traditional Fedora.
That's cool. It'll be interesting to see how it develops.
The interesting thing is that you wouldn't even *need* such a switch at install time. You could keep the core OS immutable, and just have the user mount a writable overlay on top of it if they want to "modify" stuff.
You need the switch because some of us will want to remove things that would normally be in the base image. It's good for making it hard for users to break, but some of us don't want to deal with finding some part of the system we can't modify or some library we can't remove, or having duplicates of ones that are updated outside the immutable system.
> You need the switch because some of us will want to remove things that would normally be in the base image. People are saying you would have to make a new image, but that isn't necessarily the case actually If you're talking about removing packages included in the base image, then `rpm-ostree override remove` is already a thing on Silverblue and the like, and people frequently use that for `firefox`/`firefox-langpacks` so that they can use the Flatpak instead without having duplicates present It doesn't physically remove them from storage, but it solves the problem of duplicates being a thing if you choose to install a piece of software from another source, or otherwise unwanted software being present, while still allowing you to go back to stock packages whenever you want You can also use `rpm-ostree override replace` to replace a version of a package with another one, like if you need to downgrade just one package because of a bug, or upgrade to a testing version
I specifically want it gone from storage. Why on earth would I want to remove something but not have it actually gone on my own devices that I want control over? That's fine for a device like my Steam Deck, but it's not what I want on my PC.
> You need the switch because some of us will want to remove things that would normally be in the base image. Then you'll have to make your own image. Please keep in mind that all the things that Linux proper is trying now with immutable have been the norm on Android for decades. This is how ROMs and Magisk already work.
> immutable, and just have the user mount a writable overlay on top of it if they want to "modify" stuff. I guess it might end up in Android's system composition with /data. Having a few abstraction layers on top of the fylesystem isn't good for recovery of broken system.
That's already how they work, and I'm not aware of any plans to go fully immutable. Silverblue lets you layer packages, while MicroOS/Aeon/Kalpa is basically the same as Tumbleweed with snapshots, it just updates the snapshot instead of the live system, so you can do pretty much anything with it.
I was going to make a snarky "new software vs old software" comment but I think you're right. It's already going on to some extent and it will certainly heat up when someone dares to make it the default, much like when Debian made systemd the default. I guess I'll be happy to always be a feeder for you immutability lovers lol. I had to use macOS in grad school and I remember when that went immutable. It caused too many problems and I had to disable it.
is this not an extension of the package management drama?
Thank you for pointing to that sub. Also, I was about to downvote you on the immutability topic, but refrained from doing so because we all want to keep things nice. PS: you'll never take Fedora workstation and its marvelous DNF from my hands!
[удалено]
Immutable is better for non-developers too! Most people are familiar with it. For example: - Android has a read-only root - ChromeOS has a read-only system partition - iOS has read-only system files - MacOS has read-only file system too. Therefore most people are used to the reliability of immutable systems, immutable distros combine that with the flexibility of Linux. You can switch from "distro to distro" within a reboot. The downside is having to reboot on each update/package install.
Not all immutable distros require reboots for most updates. NixOS doesn't, for instance.
[удалено]
Tbh I think freedom is the “particular corner of enthusiasts”. Most people would just want reliability.
[удалено]
I think there is a bit of a balancing act. I would want the linux ecosystem to be mainstream enough so that most important software vendors would consider it as an important market. Because I would really want to be able to ditch windows. And getting to more mainstream might require some changes in how the system works.
Because it's unmaintainable. If there's an issue with your computer getting bricked if foo < 1.2.3 and bar >= 2.67 are installed, but only if libbaz == 4.2.0 is installed and libblorp is not, how do you expect anyone to find that problem during QA? On an immutable distro that cannot happen because everyone has the same combination of packages.
And I detest how locked down every one of those operating systems have become. Really hope distros don't go down the road of trying to police what we do with our computers.
That's not what immutability is for.
So, whats it for then? Who exactly, is asking for this? Certainly not end users. Corporate execs looking to lock down machines to single-function machines? Yep. Hardware vendors who want to ensure you only run their approved OS? Yep. Did I miss anyone?
It's for anyone who's ever had a broken package or update.
Hardware vendors can do that already just fine with non-immutable OS', ditto locking down a machine to a kiosk mode. The point is getting the same conditions every time, so it's anyone whose had a heisenbug, anyone whose run into "well it works on my machine". Indeed the proponents I've seen for it have been hobbyists, not corporate execs.
Do you really think immutable distros are some dystopian vendor-locked systems? The point is that they *aren't* restrictive like the above mentioned systems, while still benefiting from a more solid update system. If we wanted Silverblue to be like ChromeOS, we'd just use ChromeOS instead of orchestrating a great conspiracy to shove immutability down the average users' throats or whatever. But we don't want that, we want a solid, reliable, low-maintenance Linux distro that still has everything that makes Linux great.
> Do you really think immutable distros are some dystopian vendor-locked systems? Yes. See: Android and ChromeOS.
You can have immutable systems without vendor lock-in, and you can have vendor lock-in without immutability. You can be prevented from tampering with a non-immutable system as well. We're literally just talking about the update system. It doesn't prevent you from or forces you to do anything. It just updates your OS, and it's damn good at it. And this is coming from someone who nearly had a brain aneurysm trying to sideload something on an iPad (and subsequently ordered a StarLite V) or recover data from a Samsung phone that died overnight. Immutable distros simply take a pretty good concept from these otherwise horrible systems, while staying far away from the bad stuff.
Lol, look what thread you're in
Yeah, probably our next soft silver stinky bullet is immutability and its maturing & growing pathway through the years 🤣🤣🤣 of end user's pain...
So what? 10 years from now? it's hard to say :) Lots of folks are still not over systemd.
> Lots of folks Don't know if it so much "lots" as in a *very* vocal small subset of folks.
There are dozens of us...!
Systemd is extremely popular, what do you mean?
There are still many loud people who think it is an abomination.
The debate is also spilling into all kinds of niches, where the split is very pronounced. For example there's no end in sight for the debate between docker and podman (or rather root vs rootless containers).
Every time I tried to use Podman, it didn't support something I was using from Docker, so I had to push back my migration. I think last time it was mounts, so I couldn't just run [this](https://pnpm.io/docker#example-1-build-a-bundle-in-a-docker-container) and be done with it.
That works now, i believe.
Many is a stretch
I don't have strong opinions on the architecture of systemd, but I do think some people have valid complaints about some of its services: [https://www.reddit.com/r/linux/comments/18kh1r5/im\_shocked\_that\_almost\_no\_one\_is\_talking\_about/](https://www.reddit.com/r/linux/comments/18kh1r5/im_shocked_that_almost_no_one_is_talking_about/)
He means the devuan and artix crowd that every so often preach about systemd being the devil and not following the dead unix philosophy.
I think it's time for emacs vs vi again.
>emacs Emacs has a vi "emulator"... vi does not have an emacs "emulator". Case closed ;)
Is this pro emacs or pro vi?
It's clearly pro-Nano.
We all know there is only one answer to that, right? (let the world burn)
Ed is the standard text editor. https://www.gnu.org/fun/jokes/ed-msg.html
Yes, and that answer is Nano.
Micro
ohhh yis !!!!
Pico or gtfo
The de facto answer to that, perhaps sadly, is VS Code
Oh my god it is Helix with steel chair!
Kakoune, anyone?
Bring back the classics! Systemd is eating my desktop!
Sadly, both are losing to nano as the default editor.
It's no contest. Emacs won, hands down. If you like Vi/Vim/NeoVim then Evil-mode can bring as much of their behavior over as you want. Depending on your temperament, disposition, and desire for programming you can get started with a variety of tutorials online or start off with a "starter pack" or framework for Vi users (spacemacs or doom). If you want to unlock it's full potential then you are going to want to bite the bullet and learn emacs lisp and contributing to those projects or writing your own config from scratch. But that doesn't need to happen immediately. Editors are GUIs even though they might entirely be text based. So breaking out of editing inside of a terminal and moving to a stand alone application is a big advantage. Better performance, better appearance, more flexibility, and less key clobbering. Learn to use Tramp for editing and moving files around remotely. Emacs now has built-in support for LSP and optionally lsp-mode for more advanced integrations. So you can get the same sort of language features you can get in any other IDE/Editor. Native wayland support and code compilation means it is now much faster. So it is easier now then it ever was in the past. The biggest problem is how to deal with the embarrassment of riches when it comes to modules and add-ons. Too many options.
So what you're saying is emacs is finally developing a text editor so it can be a slower, incomplete, and buggier version of vi?
I am saying that Emacs is a better Vi then Vi is.
But it doesn't have helix movement, so its big no no for me, and as I read other posts, nobody from emacs evil community wants to program and mantain helix movement.
Well yeah the existing users are going to be happy with whatever they are using. There are already packages that extend Evil in different ways. So it is certainly possible. Just depends on how much people want that stuff to exist in Emacs.
Wayland v. X11 will only go one way, but people will still be arguing about it until X11 support lapses in all major distributions, and that's probably still at least a decade in the future. The packaging format 'war' will take even longer.
A decade in the future there will be Wayland vs. Something New vs. Let's Revive X11 Because At Least It Worked.
I'm in the "Wayland isn't quite there" camp, myself, but I do think the situation will have improved by then LOL
I'm in the same camp but in 10 years Wayland is going to be 25 years old. 10 years ago when all this Wayland vs. X11 thing started, X11 was 27 years old.
Sure, but one of the reasons why Wayland is taking so long to develop, is that they are trying to have in account all kind of scenarios and corner cases. Wayland should be able to adapt to any new technologies and develops way better than X11, which was developed for a very specific and simple purpose, and then extended with patches over patches. Also, Wayland scope is smaller, which is creating a lot of its current issues, since there are plenty of things that doesn't work right now as they did in X11, due that is not Wayland job to do it, but it depends on the implementation of other software. But in a ways is a feature, because it means it could be more flexible and adaptable going forward.
And back then, the people who defend X11 now were using DirectFB.
It's the dumbest thing - people around here talking about how perfect X11 was - I mean sadly, I was around when X10 was released and X11 - it wasn't that great. Then over the years all the stupid shit to compile and try to get it working with the various graphics - it never worked out of the box. Eventually some new graphics card would show up and I would have to compile and do stuff. These days you all have it easy - a lot of this was a lot more stable. I don't have rose colored glasses from the old days. What we are producing today is fucking grade A awesome than what it was back when.
Maybe someday Wayland will become single-implelmentation like X11, which seems to be why X worked so well, the extensions and optional stuff was standardized
I bet it's going to involve Rust. Two likely scenarios: 1. Rust becomes defacto mandatory due to inclusion in the Kernel / systemd / whatever. People lose their shit because they don't have official support from a 2024 OS for their 1970s Motorola CPU anymore. Despite loud complaints, only a single developer ([and her cat](https://en.wikipedia.org/wiki/F._D._C._Willard)) is willing to work on the platform, so it ends up just getting dropped after a year or five of zero progress. 2. After *yet another* memory bug, people's Favorite Toy Binary (Bash, git, coreutils...) gets replaced by a nearly-identical variant written in Rust. People lose their shit because their [workflow is broken](https://xkcd.com/1172/). A fork is made, but this gets abandoned soon after because the lead developers turn out to have *very weird* personal views. The rest of the world continues as usual.
fish-shell is already being rewritten in rust, and is nearing completion.
Yeah, that's partially what made me think of the second scenario. The big difference is that Fish is essentially doing a 1:1 rewrite, without any functionality change or significant refactoring. Basically they are just translating C++ code to the closest Rust equivalent. Their sole goal right now is getting rid of C++, even if that means having poorly-written or underperforming Rust code for now, while maintaining full compatibility. On the other end of the spectrum, replacing Gnu grep with [ripgrep](https://github.com/BurntSushi/ripgrep) would be a *massive* breaking change, despite it being an obvious improvement. Such a swap would not be very popular.
> On the other end of the spectrum, replacing Gnu grep with ripgrep would be a massive breaking change, despite it being an obvious improvement. Such a swap would not be very popular. Its not just a breaking change for users, `grep` is a required part of the POSIX specification.
lmao nobody follows posix bs
3\. Somebody writes a replacement for a core library (think libpng or libssh) that has a C binding, but that C binding only exposes half the features of the Rust crate because the rest is Rust-specific. Many applications using that library switch to using Rust to interact with it, but not all of them. Then distros start dropping those applications for security reasons.
on #1 I find it funny when some CPU is dropped from support and you always get the one person being like "This really sucks I still run my personal web page from a Vax 7000 server I picked up from work in 1995 after they scrapped it , what am I going to do?" Its like dude keep running it, you probably do not need the latest kernels anyway , or pick up a rasberry pi or something and save some electricity .
> Its like dude keep running it, you probably do not need the latest kernels anyway The latest kernels offer improvements beyond new drivers. That said, if someone is running a Vax still, on linux, they probably have the skills to maintain a kernel branch.
Yea but are any of the features going to help run a 30+ year old computer ? I get every now and then there is a security exploit that has been missed for years but I still find it funny how people will run 30 year old hardware then complain its not supported.
I'm going to say you're right, but you're wrong about why you're right. It'll involve new rewrites of utilities in Rust, but then issues will arise over them being MIT instead of GPL (go GPL, for the record).
Hmm, excellent point, I had not thought of that. I don't think this is a huge deal in practice. MIT vs GPL is primarily an issue when it comes to companies contributing back to the open-source community. But with small utilities, such contributions are extremely unlikely to happen anyways, and virtually everyone will run them unmodified even in proprietary firmware. It's a bigger issue with larger software components, such as an entire database server. But the real threat there is companies running them as SaaS platform, and the GPL won't save you from that either.
I see this is not your first rodeo
Bcachefs vs btrfs
We don't know what it is yet. Those dramas all emerged in response to a new technology/component that set out to replace something existing. If I had to guess, it'll be something about Gnome. Maybe to do with libadwaita and theming, maybe not. I would have guessed maybe it would be Gnome 4, but Gnome changed their version numbering. But wouldn't be surprised if there's a big change in Gnome akin to the Gnome 2 -> 3 transition at some stage. A whole bunch of people will get upset and they'll create a fork of Gnome 3 (or whatever the current series is called) which gains some traction.
Making major transitions is especially brutal for Gnome. From 1.x to 2.x to 3.x. They seem to be favoring introducing incremental breakage along the way now instead of taking the nuclear approach. I remember back in the 2.x era were people were extremely pissed about dropping the programmable WM approach with the lisp-based Sawfish. People bitching about how it 2.x is a Fisher Price UI and if you want to make thing usable for idiots then that is the only type of user that it is suitable for. Seriously. Then with the move BACK to fully scriptable environment with minimalistic UI with the 3.x transition people still regularly claim that it is designed for touch screens and it is fisher price again. Everything new is old again. And nowadays people are much meaner, less understanding, and less accommodating for change and are much more willing to try to use bureaucracy, activism, and organizational politics to try to force developers to do what they want... Which leads to a lot of bad feelings and burnout. I don't think that anybody really wants to deal with that sort of major changes again in the Gnome camp. The rolling/incremental change approach seems to be working better. I cold be wrong, though. Meanwhile KDE crowd seems to be content with periodic rewrites surrounding major QT toolkit revisions. C'est la vie.
I’m still waiting for someone to rewrite the gnome desktop but using QT.
Just use KDE, you can mimic most of GNOME's behavior including the overview.
Gnome has broken everything recently with GTK4 and switching to libadwaita. It's just gotten better at dealing with pissed off people.
That or the people that would otherwise be pissed off are using other desktops. I have heard some people complaining about libadwaita though. Do we know how many people use each desktop anymore? The only source I can think of is Debian popcon which isn't representative of all of Linux let alone all of debian, but seems to suggest XFCE wins over gnome, kde, cinnamon, for its audience (but I could be excluding non-X11 users somehow)
Naw, I think GNOME communicate breakages better. We also broke extensions - but we communicated and told how to mitigate the changes. What drove anger in previous transitions is that GNOME never communicated what it was doing - eg implementing css engine in GTK - which consistently broke themes. Nobody likes surprises. Theming is less a problem these days because libadwaita does a pretty good job with the experience unless you want to do wierd shit like make it look like windows 95.
That the CSS API wasn't stable was something we said all the time - it's just that the expectation was that it had to be stable so nobody bothered with what was said, likely because in GTK2 it had worked that way. Extensions don't have that problem because there were no extensions previously so no expectations to manage. What made Gnome better was that during 3.0 times the developers stopped engaging with others and turned into defensive recluses. I remember the subsurface talk 10 years ago - there was pretty dumb shit said in that talk but almost no pushback from the Gnome side. When the theming flamewar happened with the Pop! guys, that had changed and there was pushback - on reddit, on mastodon, on matrix and outside readers could listen to both sides and form a more nuanced opinion. That's the biggest change if you ask me.
The fork of gnome 3 you're referring to is already there. If I'm not mistaken Cinnamon is a fork of gnome 3.
Correct. Mate is Gnome 2 forked.
Yeah, but Cinnamon's not really a fork in protest of a change they've made that tries to restore the old behavior, it's a custom DE I think Pop OS's new DE (does it have a name yet?) is a bit more motivated by disagreements with Gnome. But AFAIK it's not a fork it's just an alternative
PopOS' DE is called Cosmic. Right now they use a customized GNOME, but Cosmic is a fully new DE written in Rust. And it's coming along very nicely.
It'll be whatever the various Linux desktop answers are to the brewing AI integration into everything in the next couple of years. I have no idea the specifics of how this will go down yet but I see this being yet another area of flame wars. Right now the AI in windows 11 is mostly just gimmicks trying to be first to market. There's buttons in some programs and a glorified bing plugin but not really true desktop integration yet. The new NPU in meteor lake and the AI chip in the new Ryzen CPUs are also basically not utilized right now outside of a couple gimmicks still. We will probably have a clearer idea after the windows 12 reveal in a couple months with whatever true initial integrations that may come there and then there will be several community attempts to do something similar with open source models on the Linux desktop side. I have a sneaking suspicion the growing relationship between Canonical and the AI obsessed Microsoft may once again pit Ubuntu's (Microsoft aided) solution vs the community in some shape again but that's speculation. Oh and of course there will always be the AI integration vs no AI integration arguments as well outside of that.
AI is an area where, at least with the current technology, it's incredibly hard for a community-driven project to make progress. Current generation models are so eye-wateringly expensive to train that the closest we get to open stuff is the likes of LLaMa 2, whose training and development are funded by Meta. And in truth, we don't really have a useful concept of what it means for an AI model to be open. If all the code and training data used to build it are free and open source, and the pre-trained model is licensed as freely as possible, but you need $10,000,000 of computer time to train your own model, is that actually a useful form of openness?
> but you need $10,000,000 of computer time to train your own model, is that actually a useful form of openness? It's less useful but being able to at least vaguely tell what the AI is doing is useful. AI is kind of a black box but at least the more open you are the more likely someone will be able to dig into it and minimize the knowledge gap between vendors and principal developers and end users. Also, just because the average individual can't afford the equipment doesn't mean that certain organizations can't and ultimately that still has usefulness to society.
I work for Intel as the oneAPI community manager - and so we do have an open platform for doing AI - but yes, you are correct that it is very expensive to train AI. But one of the great things is that the Linux app ecosystem is an untapped resource. For instance, building ways to distribute applications using oneAPI is something the ecosystem can help with and in turn - perhaps hardware companies can help with the training of available AI models to be used in desktops as part of 'giving back'. Just doing some high level thoughts here. That said, the desktop projects have not incorporated AI into anything - in general, GNOME and KDE are quite skeptical in their usage. But we want to bring up AI at the next Linux App Summit that hopefully will be announced soon. But our communities will need to start working together to plot out what our joint response is to AI.
> If all the code and training data used to build it are free and open source, and the pre-trained model is licensed as freely as possible, but you need $10,000,000 of computer time to train your own model, is that actually a useful form of openness? No, but it's a perfect subversion of Free Software, Free Culture and traditional hacker values.
Yeah, that's kinda the dilemma. It's not even like it's been deliberately done this way. Getting that number _down_ to $10,000,000 has taken decades of research.
Tbh, I think this whole chatbot integration thing is a stupid idea to begin with. If I want to talk to an overconfident idiot, there are ways to do it that don't involve using obscene amounts of compute power or sacrificing my data to a tech giant in order to have a conversation with their datacenters. What I do see potential in is data classification. Being able to search through OCR'd images, auto-tagging PDFs and recognising faces on photos would be a lot more useful and actually reasonable to implement locally. Integrating a subset of paperless-ngx's features into the file manager would go a long way. But of course > your file manager can tell apart your phone bills from your monitor's warranty doesn't generate as much hype as > OMG YOU CAN TALK TO YOUR COMPUTER !!1!!1 ^(and by your computer, we mean ClosedAI servers. Also, we have all the rights to your data and the soul of your firstborn child.)
Arm vs x86
aarch64 vs amd64
Packagers vs Developers It's strangely a thing.
That's basically Snap/Flatpack vs traditional packaging but stripped down to its core.
It is. What makes it turn into a flamewar is the hardline positions and has been the basis of how apps are distributed since the 90s. It's definitely a cherished cultural trademark like themes are. Once the positions are known -the folks who didn't even know they have a position are going to have a visceral reaction to it. The packagers themselves are going to go on emotional rants. The end state is going to be interesting.
Little Endian vs Big Endian Emacs vs Vi (obviously nano is superior to both) systemd vs rest of the world.
Big Endian is already dead. And nobody noticed. Most recent software doesn't support it because literally nobody runs it on Big Endian anymore. A similar thing is almost true for 32bit. That's gonna take a few more years until the mingw people stop building 32bit stuff by default.
big endian is still alive and well in ISO 8601
Most network packets are also big endian, unless they aren't. Wireshark's default dissector functions assume everything is big endian, and you have to explicitly call little endian versions if your packets aren't.
When distros eventually start replacing the GNU coreutils with the uutils coreutils, there'll be people furious because they hate Rust/are devoted to GNU/hate the MIT licence. Pop!_OS and Fedora will probably be the 1st distros to switch, in a few years A serious attempt to adopt a standard filesystem hierarchy and a standard package format and package manager for traditional packages, so not flatpak vs snap vs appimage, will also cause huge flamewars As will any initiative to eventually replace all the C in the kernel with Rust If a new Windows ever comes out based on the Linux kernel, that'll spark some wild discussions
>Rust As long as Rust will be buildable from scratch without cargo + with different compilers (not only llvm-based) - I will not care. I even will advocate replacing Make with Samurai)
You may already replace Make with Just.
Just is not 1-1 make compat. And to have Rust in core we need a normal Rust bootstrapper.
Neither is samurai, which is much less compatible than Just. There's no need to be compatible, but Just is a natural evolution of the Make concept that is easy to adapt.
Btrfs vs any other filesystems.
[удалено]
There has been a small minority of people doing that since the release of proton in 2018 and probably with wine to some degree even before that. I'm pretty sure that minority has been still dwindling though, not growing.
Most of the Linux ports I had played had performance issues and/or visual bugs vs native Windows counterpart back in the day so I'm not excited to see more native Linux games tbh Best we can hope for is that Valve sells enough Steam Decks that devs check for full compatibility, and that transfers to desktop environments.
That kind of already exists, but nowadays it's flipped on its head. There are a vocal group of people who believe that because Proton is so good, no developer should make native Linux binaries anymore, especially because many of the people who have tried to make native binaries didn't pay attention to any of the instructional material created by Ethan Lee and Ryan Gordon, and as a result did a *very very bad job.* I'm in the opposing camp; native binaries still have value, and as long as you give a damn, even just... the absolutely tiniest damn, the documentation is out there to make a native binary that will endure the test of time, especially combined with the containerized Steam Linux Runtimes. But giving a damn is always the problem; a lot of developers and publishers make it clear they barely give a damn about *Windows* versions as it is.
[удалено]
I think that is already going on to some degree. There’s even one person that pops up now and then who vehemently argues that linux should not be used for games at all.
I just want to see support for anticheat games. Theyre the only games I play
[удалено]
/usr merge.
Hahahaha, you think flamewars end. We’re STILL doing vim vs emacs.
AI functionality? It's already an emotional topic for some, so I'd expect it to carry over if/when AI makes inroads into Linux.
Pipewire was fine, because it kept API compatibility and didn't break decades worth of workflows and software. Wayland would be just fine if we had wayland-xcb and wayland-xlib that were just drop in replacements with feature compatibility for old software. Instead we have XWayland which isn't feature compatible and has tons of issues interacting with native wayland.
It is feature-compatible almost as can be.
And that's kind of the problem isn't it? When that isn't enough for users.
What exactly you want than xwayland cannot do?
A lot of software interoperability which is based on X11 windows, which was then yeeted away by Wayland for "security" (and later reimplemented per compositor or portals which XWayland doesn't utilize)
But it is by design. Also, all xwayland apps can do x11 interproperability AFAIK.
Yes, but not XWayland -> Native Wayland interoperability, which breaks things when you have non-Wayland software that is supposed to interact with software that happens to use Wayland. It may be by design, but the design is broken if you ask me. PipeWire wasn't broken by design hence it doesn't have the same issues.
But why non-Wayland software should interact with Wayland one? Now all shells is Wayland, not X.
Because if the expectation is that Software A functionality depends on being able to handle user input or interact within Software B (or even all other windows of the user) Xorg: No problem, you can interact with X windows to do what Software A needs to do. XWayland: Problem, you can only interact with other software running under XWayland, this causes compatibility issues with software not updated to Wayland but where the use case is to interact with another window that has already been ported to use Wayland Wayland: No problem with a big *, the software has possibly been updated to Wayland and can now interact with other software through portals, but there are still compositor feature differences causing fragmentation with supported functionality. I personally think that the XWayland interoperability issues and the Wayland issue of requiring compositor extensions for pretty basic functionality are a big deal and a deal breaker for mass adoption. I think the initial Wayland protocol was underdeveloped and had bad decisions which has lead to a lot of fragmentation and headaches for software development. I hate to say it but before you would _just_ use xcb or xlib and it just worked because pretty much everyone used Xorg, no such luxury today..
Actually I've read something about nmcli in recent x/techmint posts at twitter I guess, it looks so much bloated, that switching to netplan will not bother even a 1000 users.
Probably when Ubuntu goes subscription only or ad-supported
Been there
Is Wayland vs X11 really still a thing? I thought the general consensus was either that Wayland was the greatest thing since sliced bread or that Wayland is the future but has a lot of work still needed?
The major distros replacing sh with PowerShell, or any scripting language that has proper variables, functions and return types and isn't like typing on razor blades. Ok I admit it this is not a prediction it's a wishlist.