I just read the following news about OpenSUSE Leap on Distrowatch:
While SUSE has been quiet about what exactly will happen next, it looks like SLE will become a minimal, transactional base, downstream of openSUSE Tumbleweed. Meanwhile Leap may be phased out, though confirmation has not yet been published about these plans.
For the record, OpenSUSE Leap + KDE is running perfectly in our local school. What is it with distribution maintainers jumping ship and pulling the carpet from under our feet? Two years ago CentOS went down the drain (or more like up the drain to be exact). Now it looks like SUSE wants to improve Leap to death.
Tumbleweed is not an option. You don’t use rolling releases on production machines. Never ever. I know, I ran Arch on production desktop clients back in 2006.
Any sense of perennity anyone? Or do we all have to move to Debian?
Distrowatch keeps posting these articles about openSUSE dying or SUSE in general croaking every few years when they want to get more hits.
At least they’re not as bad as Roy, even though they’re typically hyperbole about everything - much like Register which I wouldn’t even use to wipe my butt if it came in physical form.
An elephant in the room – which is affected all Linux distributions.
Initially the versions of script languages Python and Ruby …
Currently, it comes down to, the problems and issues around the installed versions of Python and Ruby being used by the system as such and, the Python and Ruby versions needed by some applications and, how to deal with the resulting version mismatches …
And, how to deal with with the Server versus Desktop scenarios …
[HR][/HR]Unfortunately, the Conference Videos are not yet available but, mailing lists related to the ALP project are being put in place and, at the conference there was a call for volunteers …
There’s a special place in hell for folks who argue against stable releases, where they spend a few millions years managing thousands of desktop clients with regular driver breakage, inconsistent APIs, unresolved dependencies, obsolete syntax and other daily surprises.
Hi, -yes. Scaring. It’s supposed to be what the market/customers want. Ordinary users? I don’t know enough yet but,., Developers in the free run and promises.
Yes, but, the Elephant in the room of stable releases of every Linux distribution is, currently, some dependency issues with Python and Ruby versions …
And, the simple fact that, the Ruby version being used by system components of stable releases is End-Of-Life …
And, some conflicts between the Python version used by Kernel/System components and, the Python version required by some newer applications …
The Server world is possibly more affected than the Desktop world because, some large customers have Python scripts performing major tasks which are not compatible with newer Python versions …
[HR][/HR]We’ll have to make a decision as to what’s more important –
Systems doing useful work and generating revenue or,
Newer applications which assume that, the newest version of the scripting language is always installed and available … >:)
Interesting discussion. It seems like a difficult problem to tackle. I’m preety sure openSUSE folks will make a reasonable decision so I’m not too worried
Definitely an interesting discussion and I see a lot of this around the internet. I don’t work for SUSE and I haven’t been a user for that long, so take what I say with a grain of salt.
I find it hard to believe that SUSE would be killing Leap off for multiple reasons.
1.) They literally just finished fully integrating Leap with SLE in 15.3
2.) One of the points of that was to make “upgrading” from Leap to SLE easier I think
3.) Packagehub - this is a big boost for SLE in many ways and is basically the Leap Backports repo if I understand correctly. It’s entirely maintained by openSUSE and would be bad for SLE if this integration was removed
4.) I’m sure there are other reasons that I don’t know about
Yes, Leap is going to be different in some ways. But I just can’t see it getting killed off. And knowing what I know about openSUSE, the upgrade from 15.5 to 16 is going to be a breeze like all the others. Not only am I not worried in the slightest bit, I’m excited about the changes. It sounds great to me!
Weird thread … I’m not sure I even totally understand it …
But just a few thoughts as to the future of leap … hope it helps.
Leap is currently an extended (read: desktop / average user ) version of SLES. RHEL (Redhat Enterprise Edition Linux) and SLES (Suse Linux Enterprise Sever) have largely replaced the big OS names of yesterday (SunOS, Solaris, Irix, AIX, HPUX, …, … , … ). GNU/Linux is what runs the internet! GNU/Linux is at the heart of many big corporate and research IT infrastructures (as well as some still very cool quasi legacy IBM Mainframe stuff, that run “linux” personalities and such). In addition to being ROCK stable, Leap is just a really great OS … I don’t think you can wrong with it.
Flatpak (and I do generally hate flatpak) provides a robust means to support legacy apps. A stupid personal example: I use a flatpak to provide “displaycal”, which is essential software to me, but is no longer supported, or even installable as it is based on python2.
In the world of *nix/open/gnu … there are many ways to skin a cat as things change.
Reality today:
charles@orca$ cat "food in tins"
cat: 'food in tins': No such file or directory
As I remember fondly, the same from SunOS once upon a time:
charles@orca$ cat "food in tins"
cat: can not open "food in tins"
Some more information about Transactional Systems and Containerised Systems – <https://yast.opensuse.org/blog/2022-09-22/yast-report-2022-9>.
[HR][/HR]And, digging deeper into Transactional Systems and Containers, it seems that, the idea is, to allow those applications which need newer libraries than the default libraries supplied with the base system, to run in a Container which, contains the needed library versions.
Sounds like Flatpak but, it ain’t –
It seems that, you’ll be able to point YaST – or the successor to YaST – to a Container and, associate all the applications with versions which need the newer libraries to that Container.
[INDENT=2]In other words, a new abstraction layer within the system …
[/INDENT]
[HR][/HR]Sounds almost like “Bye, bye, library version mismatch woes” – which isn’t a bad idea IMHO but, I suspect that, we’ll have to wait and see …
About 20 years ago, when version mismatch was a very common problem between Linux applications, I participated in a forum discussion wherein I pointed out the virtue that DOS has: you can put all the files for an application in a directory (and subs) so there is no dependency on files from other parts of the file tree. For example, I’ve used the contact manager ACT, Ver. 2 for DOS for more than 30 years. My 7000 contacts, activities, notes, etc. moved easily from machine to machine under DOS and Windows. Twenty years ago I switched to Linux and DOSemu. Act still moves easily from machine to machine without any concern for software versions. Now that’s a stable release
A container, as I understand it (not a programmer), does the same. Sounds like the future to me.
