community / off-topic comment:
If you love flatpak and Co., you may be interested in reading the following opinion piece:
1 Like
That is a pretty interesting piece. It is, of course, absurdly one-sided. It is basically a containerized application hit piece.
Ignoring the bias, the real problem is that Linux seems to be moving in the opposite direction from what he is proposing.
It seems like ABI stability is becoming increasingly less of a priority for many desktop oriented distros. Especially as rolling distros continue to become more prevalent. Even Fedora has limited ABI stability long-term.
I hope flatpak will fill in the gap until shared libraries are backward compatible enough, so that apps can switch back to use system libraries again.
In the early dates of .NET, it is not uncommon for one Windows installation to have two or even three versions of .NET runtime installed.
3 Likes
Iām not sure really ā¦ .NET has an interesting cross language library with update to .NET Core, Flatpak and Snap stabilize complexe libraries dependencies with Snap pointing to security issues. I believe that the way to go is C++ STL with version 20 and after pointing to the essential job of the compiler, something close to NVidia Cuda, Intel OneAPI, DP C++. Iām not a specialist, just learning but having apps just turning in the compiler, nowhere else than in memory reminds me of IBM road to memory inception with Power 10 chips ā¦
I also think that the reason behind open source software is the ability to recompile indefinitely ā¦ at one point the compiler will send warnings about outdated this and that needing remedies. That excludes several library versions, you just use the current version approved by consortium of industry leaders or simple users.
Is a compiler open source?
Once upon a time, there was only one UNIXā¢, the Bell Labs version, no variants. Then Bell Labs made it available to some universities, and those universities made some tweaks. Then others decided to create UNIX-like systems, with some minor differences on the layer 2 and 3 APIs. This led to the point where application developers had to āifdefā their C code to allow it to build in different environments. At the point when I chaired the /usr/group POSIX system standardization committee to reunite the environments so that applications could proliferate, the āstandardā joke (pun intended) was that the great thing about standards was that there were so many to choose from.
The battle was won, there became a single standard (taken over by IEEE), for the POSIX operating system (syscalls) and the (C) application interface (libc et al).
Nowadays you can run Linux on almost any hardware platform, and the ease of creating and distributing software that has come from developments in build systems, packaging and distribution process has led to the current huge open source product environment benefiting so many. Iām happy that our small group of UNIX supporters made this early (1980s) standardization effort as a catalyst to where we are today.
Now weāre facing the same proliferation of higher level application class APIs, tons to choose from and all offering improvements over the previous generation. So many (standard) APIs and models to choose from.
The next step for open source developers is to continue to allow interesting new ideas and choices, but to eventually go towards the maturity model, narrowing the contenders for such as audio sources, syncs, filter APIs to something that no longer requires substantial effort from developers chasing the latest new model or API.
Thatās my observation and opinion, as a software developer since 1963 and UNIX lover since 1976.
2 Likes
I was actually pretty interested when I read it and saw āIām going to skip over things which can be fixed, and focus on fundamental flawsā and thenā¦ all the complaints are either āI think it will be too big on diskā or things which actually are being and will be improved.
Itās very expensive to do, and fewer and fewer (paying) customers are demanding it.
And, honestly, developers never wanted that. What they want is āa stack which matches exactly their chosen depsā. The āhereās your ten-year platformā thing comes from an operations side. And, in the modern world, that part of operations does not have the ear of most business deciders.
1 Like
The problem seems choice of API and ease of development frameworks ā¦ Iām just getting into AI and ML as the problem is not tools or what are we looking for but simply how going back to Ars Magna by Cardano published in 1545.
I canāt really comment on the technical side, and donāt know if he is correct in his assessment. I know next to nothing about this. All I can say is that the storage cost of flatpaks/snaps was a big deal to to me, and I was more open to flatpak once I understood how it reused its runtimes, but of course, thatās assuming they are doing it efficiently.
I also agree that this containers aproach adds a lot of complexity, and I donāt know if it could be done in a simpler way.
But I think the author is disregarding reality though. Other than someone who really cares, most app devs just want to ship their app without a hassle, and thats double for proprietary software.
This is the most out of touch thing he said:
How loudly do you think gamers would complain if a distribution upgrade broke their favourite game?
We have a real example of that, Rocket League simply dropped its Linux support because it was a pain to maintain it. Companies wonāt go the extra mile to support a platform they donāt care about.
I donāt agree about that i think the main reason that we donāt get apps in native .Deb and .Rpm for all apps and most of the games are not supporting linux just because the userbase is very low in linux in desktop.but for the time being flatpaks and snaps are required to narrow the gap They will care mark my word and it will happen in next 5years linux will be a major player in the world.
You can read a reply to some assertions on that article.
https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/
3 Likes
I think this one is drifting really, really far off topic, everyone. The original Flatpak article has some pretty close connection since weāre heavily exploring that technology with Silverblue, Kinoite, etc.
But which versions of propriety and/or commercial enterprise OSes are or are not the best seems like a conversation for another space.
4 Likes
So, yeah, Iām going to close this. Right now https://discussion.fedoraproject.org/c/friends/off-topic-tech/58 is probably the closest place we have to a āWatercoolerā area, and feel free to take this there.
Maybe discussion.fpo would have been the better place to have a fruitful discussion. Too bad the topic got hijacked and had to be closed. Canāt wait for a watercooler categoryā¦ Happy Friday!
2 Likes