That is a sentiment that I partially agree with. I frequently argue that iOS (for example) represents more than a decade of investment, so we can’t expect an alternative to pop up overnight.
However using a Linux desktop simply is not a step in any particular direction. It is especially meaningless for non-developers to do if one of the other platforms just works for them.
Steps in the right direction involve developing software to solve the problems that the corporate operating systems have in fact solved.
It works both ways: Windows (or Mac) are meaningless to any user, who can be served by Linux.
The first step in solving problems that corporate OSes have solved is identifying them. For example, one of the problems is stable/versioned/sandboxable/distro-agnostic ABIs and that is something that is being worked on and they are quite usable nowadays. The related problem is, that the corporate-software is ignoring them (how many conference solution support Pipewire for desktop sharing? Or Wayland in Chrome? Heck, VA in Chrome? Exactly... but whatever Apple comes with, they support within weeks).
Is it? For few things yes (OpenGL or 32-bit depreciation); other things are simply not found in the new releases (Kerberos Ticket Viewer, TWAIN). Then there's a middle ground, where there is a window of few months to make significant architectural changes to your product (see VPNs and personal firewalls).
So excuse me, I'm going to look for a new release of Cisco VPN that works with Big Sur. Of course, it is customer's VPN, and they don't care that their vendors might use Mac, so no help from them, it is my problem now.
> Even if a small number of security related technologies have a smaller deprecation window, the others have very long ones.
It uses mechanism that was introduced in Mojave, so that deprecation window was very fast. Definitely faster than Cairo, which has already more than decade and half under it's belt.
There are alternatives to Cairo, but not drop-in ones; they would require porting (Skia, for example). Other than that, Cairo is basically "done". Yeah, there is occasional need for release with small fixes, but as a software-based rendering library it is not going anywhere. Not that announcing deprecation is otherwise widely respected; the Xorg-server was declared obsolete years ago, the last major release was in 2018, but hey, some still think there's a future and in a few years are going to be surprised by "sudden abandonment".
What are you talking about. Mojave is 2 years old. That isn’t a particularly small window. Even with the 2 year window on MacOS, an alternative was delivered.
But you are confirming the point - nobody even knows what is deprecated or what the alternatives are.
You still haven’t answered the question of how someone is supposed to tell whether Cairo is supported or not.
Is it done? How do you know. Does it need to be developed further? It sounds like it does since people say it’s very slow compared to skia.
It seems like you think you know what the status of things are, but other people don’t. How can that be?
> What are you talking about. Mojave is 2 years old. That isn’t a particularly small window. Even with the 2 year window on MacOS, an alternative was delivered.
2 years/2 releases is small window. Alternative was delivered, but it also is no drop-in one. Just lika Skia vs Cairo, requires porting/reachitecting and might not have 100% coverage for what the old solution did. You might have noticed, that in Big Sur there is a list of system apps that ignore VPNs and filtering. That's a problem.
> But you are confirming the point - nobody even knows what is deprecated or what the alternatives are.
Because it works differently. There is no dictator (vendor controlling access) telling you what you are going to use whether you like it or not, and present it as a done thing. Instead, it works by forming a consensus (not 100%, mind you), whether something is needed or not. The community around a piece of a stack might arrive at a conclusion that given piece is no longer maintainable, and make something new (i.e. Xorg-server vs Wayland compositors, or systemd vs sysv-init) and then it will bubble through as distributions adopt it - either because the new solution is maintained and the old one is not, or because the new one solves their problems better than the old one.
> You still haven’t answered the question of how someone is supposed to tell whether Cairo is supported or not.
Supported by whom? In this case, the original maintainer is no longer around. But that's not a problem, distributions will support whatever they ship, so if you have an application that uses it, it will continue to work.
Should you use it for a new project? No. But that was true for years. Cairo is 2000-era software library. Consider it equivalent to QuickDraw, you would not use it for a new software either. Gtk (which was issue here on HN recently) uses it for software fallback (and they've made part of their API, so they've locked themselves in; changing it would mean they would have break their ABI. On the upside, that means that there always be some support). Firefox abandoned Cairo years ago, in favor of Skia, and so did LibreOffice in the last release.
So it shows, that a library or piece of a stack might be deprecated for years, but there might be someone somewhere who really needs it and is willing to keep it on life support (exactly just like Gtk needs Cairo). So the question for you, as someone who requires support, is: what level of support you require and what are you willing to pay (not means in purely monetary sense; though when users are expected to pay for continual support, what's wrong with expecting that on different layer of the stack?) for getting that? Because you can always get it supported; or support it yourself, if you really needed. No one is going to kick it from underneath.The source will still be available, and it is always possible to fix it when needed. You will be never completely denied access as is the case in proprietary stacks.
> It sounds like it does since people say it’s very slow compared to skia.
It is going to stay slow (unless someone invests heavily into it; which is not probable). It is a software library, deliberately; if you want hardware acceleration, switch to Skia, and accept the tradeoffs that come with hw accel.
> It seems like you think you know what the status of things are, but other people don’t. How can that be?
Simple. I asked.
There are many venues, where you can ask. These people will tell you. However, due to having no dictator mentioned above, their answer on roadmap-like questions might be: "depends on the community adoption".
In the previous comments, I've pointed an alternative several times, including what other applications use. So yes, Linux does have good option right now.
