Thank you and goodbye

I can understand @Teuniz. I have been using SuSE since 5.4 for work and privately.

I have performed and maintained over 1000 installations to date (SLES, SLES, Leap, RH, CentOS). I have been completely Windows-free at home for almost 4 years. Now I am faced with the problem that my family are just simple users and I don’t want to be constantly fixing errors in TW.

But what has been happening at SuSE / openSUSE over the last two years makes me very suspicious. They are making the same mistake we made over 10 years ago. SuSE and openSUSE are drifting apart. ALP/flatpack are still in beta status. SLE 15.7 but no Leap 15.7! Tumbleweed is too unstable, just look at Optimus laptops with Nvidia as dGPU… Slowroll has alpha status at best. It should have been a Leap 15.7. Then there would have been enough time to get all these things done properly.

Then there’s the whole half-baked thing with the administration tools. Cockpit was never officially available on Leap (tracked until 15.5), YaST and Zypper were very good so far. Now there are new tools that only have alpha status.

The annoying thing is that TW (freshly tested on an Optimus laptop) has a lot of bugs even during installation and QA has failed across the board.

  • Micro repos active, why?
  • Missing meta package to block the nvidia-open-driver (G06 proprietary are mandatory for older G06 chips, yes fully supported by Nvidia)
  • If TW is completely pure Wayland without X11, then nothing?

Firewalld is very good per se, but the package needs to be split up and all these predefined things need to go. Work, Trusted, and Public are enough—even for home use. The rest needs to go into an optional package for lazy people.

When maintainers reject something like this and also fiddle around pointlessly in the functioning YaST LAN without any knowledge of networking (Leap 15.3 Beta: MTU Size default 0, CIDR default /32, dummy eth on bridge not allowed, …)

But I want to mention some positive things:
Patching and upgrading have been working completely in-place since Leap 42.3 on my sytsems. The equalization of Leap and SUSE was one of the big plus points after the RedHat and CentOS debacle. I prefer KDE, and it was very stable and performed well on Leap. I can’t get along with Gnome 3+ at all.

If you wanted something stable, Leap was previously the first choice. Unfortunately, Leap 16 is only in alpha status. Will I warm to it? Now we’re looking around for alternatives such as Debian, Ubuntu LTS, etc.

5 Likes

Slowroll is reasonably new, and may not be considered production-quality as such, but it certainly isn’t “alpha-quality”. I’ve been using it for months without any significant issues as my daily driver. It has slower, curated updates from Tumbleweed, typically fewer kernel/Mesa bumps, and provides a more stable rolling base IMO.

3 Likes

@schoerch um, you realize this is a Community project, so if folks/contributors don’t want to do this, then???

As a contributor to the Project with a number of leaf packages (64 it would seem), I’m happy with that, my focus is on Tumbleweed which for me on GNOME is rock solid, I run optimus/hybrid desktop systems without major issues. Intel ARC (Xe driver) and Nvidia with open driver and cuda (both run files).

Again, no issues with Leap 16.0 it all works for me on GNOME, aside from the update process, but most folks seem focused around Firefox which I don’t use…

3 Likes

I could? Interesting. When i upgraded from Leap 15.5 to Leap 15.6, it forced me to format /home, which i would not call a smooth, continuous upgrade.
Myrlyn is a cool tool - i see no equivalent here on Debian. But Debian does not force a format of /home on me on upgrade.

Yes, it is these little things for Desktop users. :roll_eyes:

I really like firewalld here on Debian. Having the same in OpenSUSE is awesome. The issue i see with Cockpit is it requiring ssh - cool for admins. That architecture approach makes sense for SUSE serving corporations. But why should i as single PC user activate a remote access architecture only for maintaining my system? All admins will say again that a firewall can localise ssh. Cool, but why spend effort on locks for a door when the door is not needed in the first place?

It’s not better here on Debian. Yes, i can avoid ssh (not even content of the default installation) but setting up repositories in Debian is a terminal nightmare.
In summary, it seems to be all a bit mixed pickles across the Linux landscape.

Leap never forced to format the home partition. You simply followed the partitioner suggestion. But it is easy to uncheck the box for formatting.

A vague claim like “it forced me to format /home” is not convincing - it doesn’t tell us what actually happened. In-place upgrades (e.g. 15.5 → 15.6) don’t usually require/involve formatting filesystems, so if the installer suggested that, it was almost certainly due to a specific choice or a mistake in the process. Without details, it’s hard to attribute this to Leap rather than user error.

That’s not strictly true. For Local (single-host) usage, Cockpit runs a web service (port 9090) on the same machine.

1 Like

@malcolmlewis, i have always contributed as a tester and bug reporter whenever I found an error or problem. I also participated in the public beta tests for Leap/SLES/SLED up to Leap 15.3. I’m not a developer, just an admin and user.

I can list a large number of enterprise optimus laptop models (Lenovo, HP, Dell, etc.) that do not work with nvidia-open because their chips are not supported. However, they require the closed source nvidia G06 for vulkan and cuda support. The laptops must therefore be less than 3 years old in order to use the nvidia-open drivers. (Bear in mind that enterprise laptops have tried and tested hardware installed). I have been using several of these enterprise laptops / mobile workstations for over 20 years at multiple and different workplaces with docks, multi-monitors, and KVM switches.

Leap 16 is not Leap 15.x under the hood. I dont use Gnome since 2.x anymore. Why, that’s another topic.

Cockpit is a very good approach, and I already wanted it in Leap over three years ago. I would have liked to have been actively involved in that too. I had already extended the CA management plugin on an RHEL system, as it was removed from YaST in Leap 42.3. Unfortunately, I did not receive any positive feedback to my requests.

1 Like

@schoerch Hi, thanks for your contributions :smile:

The test systems I have with Leap 16.0 use both old (Pascal) and new (Turing) hardware in optimus/hybrid setups, it is no different that a laptop aside from GPU arch/features. I use the rpms in both cases and all worked fine, run zypper inr then install whichever driver open/closed. The Dell OptiPlex XE3 has run both a Quadro P400 and at present a Quadro T400. The XE3 does an automatic switch to the Intel GPU if DP is plugged in, if use discrete GPU then it will switch the Intel GPU to a Display Controller, a very nice feature.

Leap 16.0 always was going to be a different beast compared to the previous Leap releases, this was quite clear from the beginning, hence a recommendation for a fresh install rather than an upgrade. Likewise moving to the likes of SELinux, plan for grub-bls (that 4GB /boot/efi partition) etc.

1 Like