Hey there @CubicleNate , thanks a lot for the mention of SpiralLinux! I would be interested in knowing how it works on one of Dan Kelly’s famous “potatoes”, especially the ones with Broadcom WiFI, I think it has a decent chance of supporting it out-of-the-box.
I would like to share your optimism about the future of ALP eventually satisfying openSUSE Leap users’ needs and preferences. But everything seems to be pointing to a radical change to SLE within a few years, motivated by SUSE’s corporate and profit interests. I’ll reserve my opinion on that last part. But at least at this juncture it doesn’t look too promising for use as a flexible general desktop operating system:
MRAZOR12
They [SUSE] said there is no plan to abandon the desktop workflow.
rbrownsuseMicroOS (Desktop & Server) Release Manager
There is no plan to abandon it, sure
But it’s also not an area of priority
So there’s that. Regarding the question “Why not Fedora?” for the SpiralLinux base, good question. @MichaelTunnell had the same question on This Week in Linux 202, here’s my response:
I do not want to make a big fuss about it but I read one of your concerned posts here in another thread and it seems to be you are right.
Now I cannot find it anymore and usually I do not trust, read and follow some random Reddit threads, but Richard Brown himself said in one of them that Leap is indeed going away. It is buried in all those posts in r/openSUSE.
As for why not Fedora in the case of SpiralLinux, I totally get it. One branch of Gecko is using Leap and therefore Debian stable makes sense. Fedora with its release cycle is not appropriate for such a case and now my opinion, it never was.
I get that Fedora is cool but the support for one release is too short. I am also biased as a Debian user.
So I applaud your efforts for such an interesting take on Debian and only using Debian’s default repositories. A lot of Debian spins are “FrankenDebians” like e.g MX Linux* that you cannot upgrade to the next version, at least not officially, because of all the added third party software. In your case that should be possible. Personally I do not use Flatpaks and snapshots, but this makes SpiralLinux a very modern Debian derivative.
*There is nothing wrong with MX Linux per se. The project does not hide its upgrade policy. You could take any other Debian based distribution for this example.
I think this is an interesting idea, the “death of Leap” but I really think that this is a bit of an alarmist response to the changes being made. Perhaps it is just my “normalsy” bias but since Leap is a community run project and openSUSE has historically kept the community’s desires at its core, the final result of the changes they make, incorporating the immutable characteristics for the root system will likely be done in such a way that won’t “Kill” Leap but rather move it to the next level. Tech continues to change, grow and morph to the changing requirements and demands on our technology. That said, I still fully support the idea of developing SpiralLinux. I think there needs to be something on the Debian side of things that push in a lot of these more modern technologies and methods into that part of the Linux world.
Well, Richard Brown rather undiplomatically described openSUSE Leap as being in a “parasitic” relationship with SUSE. And openSUSE Leap is actually a downstream product of SLE, whereas Tumbleweed is the upstream that contributes to the next SLE release. So as offensive as his comments have been, it appears accurate that openSUSE Leap (not Tumbleweed) is only a community project in the sense that it has a community of users that benefit from SUSE’s code dumps. SUSE has confirmed that it will no longer be sharing its packages with the openSUSE project after SLE 15 SP5, so that would spell the end of the line for openSUSE Leap after version 15.5. Unfortunately it’s not just conjecture at this point, it’s straight from the horse’s mouth. They even said that to reduce pushback from the community they’ll probably still have “Leap” in the name of the new product based on ALP. But it will bear no resemblance to the traditional slow-moving OS that we currently know as Leap.
Of course, this is all moot for users that actually want a new-age buzzword-compliant Linux OS with an immutable filesystem, nuclear updates, and container-based everything, as that is what SUSE is going to turn their enterprise product into, and they will be sharing it with openSUSE.
I can’t say I am on top of everything in the openSUSE project but with my involvement with the project, I have seen more of a merger between Leap and SLE to the point where the variation is just some branding and community packages. I guess time will tell. Everything in the world is constantly in flux.
I can’t say I agree with any one member of any project 100% (except maybe @MichaelTunnell, he’s pretty cool ) but I have to say I do agree with moving everything to the rolling model as opposed to a static release. In my mind, some aspect of that would reduce the technical liabilities of all these projects that is required to keep older releases properly patched.
Now, this is the opinion of someone that does nothing when it comes to the technical underpinnings, only reading the opinions of various people that do.
I am kind of an optimist. openSUSE has done me well with all their changes over the last 12 years I have been using it so I appreciate how they keep the train rolling.
Hey again @CubicleNate , yep, that’s what I’ve seen as well. That to me is the most important aspect that practically guarantees that Leap as we know it will be going away in a few years, because SLE itself will be changing into a totally different product. So to make Leap stay the same as it is now would require a completely new community model of people willing to maintain what would essentially be a fork of the current Leap/SLE15. And due to the difficulties of patching old code and backporting fixes as you mentioned, that absolutely isn’t going to happen. So Leap will go wherever SLE goes, and SLE will be turned into a totally different sort of product.
Some people have compared this situation to the Redhat / CentOS debacle that lead to the creation of AlmaLinux and Rocky that continued the CentOS mission after CentOS went in a different direction. But from what I can tell, that’s not a comparable situation with what is going to happen to openSUSE / SUSE. The thing that made AlmaLinux and Rocky possible is the fact that Redhat is continuing to develop RHEL in the same general direction and its sources are still available, so when the downstream CentOS went away those new distros picked up the slack. But that won’t be possible for openSUSE to do based on SLE, because the parent enterprise distro itself is changing course.
This is similar to one of the things I appreciated about GeckoLinux: aside from packman (a respected and widely used community repository) no extraneous custom packages replacing anything in the canonical openSUSE repositories.
The only complaint I have about your @GeckoLinux spins is that I dislike your theming and interface modifications. A minor quibble to be sure.
SpiralLinux is definitely a welcome addition to the Debian-based world.
The only complaint I have about your @GeckoLinux spins is that I dislike your theming and interface modifications. A minor quibble to be sure.
And it’s basically the exact same theming in SpiralLinux too. I don’t necessarily think they’re the most attractive icons either, but it’s really a matter of function over form. I only use icon packs that are in the source distro’s repositories, and all the ones I tried had issues with missing icons or illegible icons with the dark panel color that comes from Numix, so Faenza is the only viable option that I know of.
I have the same thing happening here on my Debian installs. I use only the repo’s themes and icons and it can be limited, so I am stuck with either Numix or Greybird.
Yeah, I have a personalized theme that I created with oomox that I install to /usr/share/themes on my personal systems, and fortunately GTK3 has become pretty stable during the past few years and personalized themes basically just work from one release to the next. I just needed a sane default from the Debian repos for SpiralLinux, and so I chose Numix because it has the best font color contrast.
) but I have to say I do agree with moving everything to the rolling model as opposed to a static release. In my mind, some aspect of that would reduce the technical liabilities of all these projects that is required to keep older releases properly patched.