Calamares uses the QML / Qt toolkit. Most of the people involved in Calamares are also involved in the KDE Project.
XFCE use the GTK toolkit.
So, it is totally reasonable to say that KDE is “more native”.
While Wayland maybe a factor, KDE itself will not be fully Wayland compatible until Plasma 6 next year. So that does not really explain the timing of this move.
I use XFCE myself so I am a bit nervous about the change. We will see.
The only benefit that OpenOffice had was the name. Given the momentum that LibreOffice had early on, OpenOffice should clearly have joined with them and maybe ceded the name.
I am glad that LibreOffice did not try to merge back with OpenOffice as clearly it remains a poorly managed project. The continued existence of OpenOffice is doing tremendous damage to the wider ecosystem. The fact that Apache continues to promote the project not only reflects badly in them but show what poor stewards they are. I would not have wanted their lead ship to have hampered the subsequent success of LibreOffice. The whole episode just proves that LibreOffice was right to break away and not just because of Oracle.
I have noticed that one of the groups that does not seem to be complaining about Wayland are the toolkit folks. GTK added support back in GTK3. Qt added it. Enlightenment added it. They must have jumped on it for a reason.
When you look at the Wayland readiness docs for things like XFCE, it stands out that all the apps are already ready ( because they are GTK based in this case ).
You can remove the /s.
With GNOME and KDE going Wayland only, it is all but over for X. Qt, GTK, and Electron already work on Wayland so most apps are ready. Cinnamon, XFCE, Enlightenment, and MATE all have Wayland plans now. There are a few compositor libraries that other window managers and desktop environments can leverage.
NVIDIA is slowly getting their act together. Many of the legitimate complainants are being addressed. There are desirable features starting to appear that are Wayland only. Even non-Linux systems are adding Wayland support.
It is hard to believe after so many years but I think that, by Christmas 2024, most Linux users will have stopped using X and maybe even stopped talking about it.
Many people have predicted the death of the small, independent window manager with the coming of Wayland. I have heard multiple times that only large projects like GNOME and KDE would be able to take on the burden of making a compositor.
Now, I do think that lots of no longer actively developed window managers could get left behind. But the idea that it will be too complicated to create a window manager now is turning out to be wrong.
First, fewer desktop environments are getting left behind than feared. XFCE, Cinnamon, and MATE all seem to have Wayland plans now.
The big change is the appearance of not one but multiple compositor libraries designed to make it easier to create a window manager for Wayland. Some of them look like they might make it easier than it was under X. The approach taken by this one makes the idea of hacking around with it very inviting.
Although having to create a compositor has made things difficultly until now, I think the idea of decoupling the compositor for Wayland is going to look smart in the long run.
Being separate from Wayland, compositor devs are free to experiment and window manager authors can select the one that best maps to their goals.
I was reading up on Oasis Linux yesterday. It comes with a Wayland compositor ( SWC ) and tiling window manager ( Velox ) that are less than 20,000 lines of code combined!
It would not be practical for a light-weight distro to trim down Xorg like that. But I the compositor is separate, it can be either smaller or feature rich. SWC is XWayland compatible but obviously that is going to add more size if you need it.
Looking forward to the window manager innovation that projects like Louvre enable.
I suspect it is a combination of its being free, working well on older hardware, and the tech literacy in India.
Software development and engineering are important aspects of the Indian economy. Linux is arguably the best platform for that kind of work, especially in the cloud. Tech support of those kinds of systems require the same skills.
Given how well Linux runs on older machines, I consider low Linux penetration a hallmark of rich countries.
In my own household, Linux goes on all the older hardware ( including Macs ). That has really extended the length of time before hardware needs to be replaced. It also means that, over time, the percentage of active equipment using Linux has increased.
Great to see this perspective from a developer and it totally makes sense. I think the Firefox browser has encountered essentially the exact same thing. Linux support may be a strategic advantage for devs that embrace it.
That does not mean that every developer will find the same thing though. Proton and Unity have many, many Linux specific ( or at least non-Windows ) bugs I am sure. It would be easy to bemoan these. It takes a different kind of mind-set to see working around these kinds of issues as valuable. Even rarer are devs that take the opportunity to address bugs in the underlying tech ( outside the game - eg. in Proton ).
I suspect though that many non-Windows bugs are actually due to defects in the game. They are just not manifesting yet or in the same way. The fact that Linux exposes these is again an opportunity in the way the author of this post points out.
In other words, cross-platform deployment is an opportunity for a stronger product. Access to an engaged community with strong communication skills and technical chops is a bonus.
Hopefully more devs start to see the world this way. Great article.
If you game on Linux, you are almost certainly using it.
I love your comment. Without thinking, I instinctively agreed with you. Then I was like, “wait, why wouldn’t you just run that software on Windows?”. So now I am wondering if you are predicting such a mass migration off Windows that all these Windows apps become abandonware.
Probably though, part of what you are saying is that it may be easier to maintain compatibility with older software via WINE than on Windows itself.
64 years from now, when ReactOS comes out of beta, it will be great for that as well.
Microsoft must make 40% of their revenue off of Azure at this point. I would not be surprised if more than 50% of that is on Linux. Windows is probably down to 10% ( around the same as gaming ).
https://www.kamilfranek.com/microsoft-revenue-breakdown/
Sure there are people in the Windows division who want to kill Linux and some dev dev folks will still prefer Windows. At this point though, a huge chunk of Microsoft could not care less about Windows and may actually prefer Linux. Linux is certainly a better place for K8S and OCI stuff. All the GPT and Cognitive Services stuff is likely more Linux than not.
Do people not know that Microsoft has their own Linux distro? I mean an installation guide is not exactly their biggest move in Linux?
Which two terms? Everyone has an agenda but I am not sure what I am being accused of here. Do you mean Free Software vs Open Source? The FSF goes to great lengths to distinguish between those two terms:
https://www.gnu.org/philosophy/open-source-misses-the-point.en.html
I am pretty sure my usage is consistent with the owners and creators of those terms. Have I made an error?
I realize that the major point of GIMP 3 is the port to GTK3. That said, I feel like colour spaces are what people have been waiting for and probably the most significant deficiency that keeps GIMP from being treated as a professional tool.
If they are really this close, why not set the GIMP 3 release date for when colour management is ready?
Non-destructive editing will be huge as well. GIMP 3 is really going to be a crazy leap forward. It is going to be amazing to finally get access to all this work that has been walled off for decades.
The bug situation sounds terrible. Honestly though, they should just get 3 out and then make bug fixing the number one job until it gets into better shape.
Not only is it a small team but right now there are basically two different projects ( 2 and 3 ). With only one code base, perhaps the pace of progress can improve.
Hopefully the move to GTK4 is easier.