Why I won't use Leap 16.0

English Open Chat
1

I have been a Linux user for almost 30 years, starting way back with “S.u.S.E. LINUX 4.4.1”. I was so glad when I could finally abandon DOS/Windows for good!

Recently I got a new PC, with more disk space, more memory and faster CPU. When openSUSE Leap 16.0 was released this month, I thought this would be a good time to switch from my current Leap 15.3 to the latest, greatest. So I downloaded the Leap 16.0 installer, copied it to a USB stick and fired up my new machine. With large disks and valuable data, using RAID-1 is definitely a good idea. Imagine my surprise when I had to see that Leap 16.0 is unable to set up a RAID-1 from scratch (something Leap 15.3 could do easily). So I learned how to set up a RAID-1 manually (wrote this summary, if anybody is interested) and was able to install Leap 16.0. First impression: incomplete!

All my machines have always run on ISO-8859-1 (or later ISO-8859-15). This codepage is perfectly able to represent the German umlaut characters, and that’s all I need. I don’t need UTF-8, and frankly I don’t like it. Call me old-fashioned, but I like my systems to be “each byte represents exactly one charcater”. So far this worked reasonably up until Leap 15.3 (don’t know about later 15.x versions), although some desktop apps already had problems with file names that contain umlauts, showing the infamous “WTF characters” (those black diamond question marks you get when UTF-8 chokes on ISO-8859-15) instead (and, of course, not loading the file, claiming “it doesn’t exist”). So I try to avoid umlauts in file names as much as possible, but in my photo collection it just looks bad to do so. At least GwenView was still able to handle ISO-8859-15 file names in 15.3, so I could manage my photos.
However, in 16.0 apparently even GwenView now chokes on these characters, and from what I’ve read so far there is no way to make this work any more. There is, apparently, this general movement to force everything, everywhere to UTF-8. I understand that there are languages that can only be represented in UTF-8, but mine is none of them. Second impression: incompatible!

The straw that broke the camels back for me was when I launched KCalc. On 15.3 switching between Hex, Dec, Oct and Bin was done with radio buttons, so a single mouse click would switch the base. I use this a lot to quickly convert numbers. In 16.0 they changed this to a combo-box! And even the hotkeys apparently don’t work as before! Who knows what other things they broke in their attempt to make things “more modern”?! Third impression: unproductive!

The most important thing that keeps me from switching to Leap 16.0 is definitely the lack of support for single byte character sets. If “more modern” means removing features that used to work just fine and made life easy, then I’ll gladly be called “old-fashioned”. I’ll stick to my Leap 15.3 and just copy it over to the new machine.

Leap 16.0 has disappointed me.

1 Like
2

If you still use ISO-8859-1 (Latin 1), you’ve been living in the past for more than 20 years.

9 Likes
3

That is remarkable, on Tumbleweed I see:

Screenshot_20251011_154828

Yes, things change over time, not too bad these 3 things for a distribution that is 3.5 years out of date.

Was not aware of this but but that sounds to me to a good reason to standardize on UTF-8, supporting old functionality is not free.

4

I feel your pain. I wrote my own little tool that shows the relation between decimal, hex and binary and can also do some manipulation:

image
image608×538 31.3 KB

I use it when I’m programming lowlevel stuff.

5

Well the kcalc and UTF-8 critique is not opensUSE-specific. KCalc’s UI changes come from upstream KDE, and openSUSE just packages what the KDE developers release. The same version looks and behaves that way on any distribution using the same KDE Frameworks release.

Likewise, the shift to UTF-8 isn’t unique to openSUSE. It’s now a near-universal standard across all modern Linux distributions (and in Windows as well).

So switching distros won’t avoid these things as such.

3 Likes
6

That’s degrees, radians, and gradians, not hexadecimal, decimal, octal, and binary as the OP was talking about. You see your screenshot in Science Mode, and the base dropdown in Numeral System Mode.

As @deano_ferrari says, though, this is a KDE decision not an openSUSE one, so should probably be taken up on the KDE forum.

Edit: see 507384 – Inconsistent UI: angle mode uses radio buttons, numeral system uses combo box and Draft: Replace angle mode radio buttons with combo box (!189) · Merge requests · Utilities / KCalc · GitLab

7

@kls Switch to GNOME :rofl:

Screenshot From 2025-10-13 11-33-17
Screenshot From 2025-10-13 11-33-171920×1080 301 KB

8

That you even have to write up a way to install 16 on RAID1 is already disappointing, but I appreciate you writing it up. Apparently the distribution architect is on Reddit telling people that agama devs made the decisions they did because some survey was run and “no one” needs my use case (below) but that implies no one “needs” yours also? Sort of disappointing, as RAID 1 was something I wanted to do with 16 now that I have the ability to software RAID from home (RAID 1, not 0). How would any research identify that apparently “no one” needs RAID 1 via mdadm? Because we’re being actively told that apparently our use cases are invalid.

Mine was wanting to do LUKS + LVM but without the hella-slow GRUB2 FDE. There was no way in the installer that I could find to set it up as a simple LUKS + LVM with /boot being unencrypted. (My use case isn’t CIA/FBI so I’m fine with it this way.) I was told on Reddit that a survey was done about use cases and it was decided “no one” does what I do (and based on your input, apparently “no one” uses RAID 1, but the person on Reddit didn’t say that directly).

I guess I will be putting in respectful requests on agama’s bug tracker / feature requester for a better partitioner.

9

@oneeyedcat Hi and welcome to the Forum :smile:
Well there was the Alpha, Beta and RC testing (and engineering meetings) where this could have been covered? All hindsight now…

I’m mainly using desktops, the two primary ones both have hardware RAID controllers which makes life easy…

Thankfully the Agama installer has the option to do some command line foo to add RAID, was nice to ssh in from another system to setup Software RAID.

2 Likes
10

Any development team that thinks they get the input of enterprise and home users who have lives and are too busy to test RCs on home (for instance, they need packman stuff) or at work (too busy / not allowed to test in a production environment) needs to reconsider. If I told, for instance, a small business I work at that they needed to install a release CANDIDATE without packman support, they’d tell me no, and if I pushed the issue, I’d likely get fired from the sysadmin role in that small business.

As well, why would a home user use an RC if they are a busy professional, or in this case due to the downturn in the economy, are working 2+ jobs to survive?

This only reveals that, in my polite opinion, the development team for opensuse and/or agama only THINK they got good info from their users, when in reality those who use release candidates are a SUBSET of their users, not typical of all their users. Also, why would many people be using RCs anyways if they prefer “bleeding edge” when slowroll and tumbleweed exist? So yeah, not to be rude to anyone, I just think the “sampling” the dev teams got from RC candidate use was definitely not a good representative of their user base. I say this in the sense of statistical research concepts. If this were a scientific paper, I would accuse it of a sampling error.

11

IMHO any business should be looking at Fluendo for codecs, likewise if your supporting a business then you should have a lab to test? Likewise flatpaks at a user level is way easier to fix than at a system level relying on literally a one person show and a hodgepodge of hardware is recipe for disaster. Note I am an Admin on that site to the build system…

Likewise you have until April next year so don’t upgrade?

1 Like
12

My initial rant in this thread resulted from the fact that the very first thing I needed to do to install Leap 16.0 (setting up two disks as RAID-1) was not possible with the new installer. Good old YaST was gone, without even an option to fall back to it. So I had to set up the RAID-1 manually. After successful installation I saw that I would now be forced to convert everything to UTF-8, which I absolutely don’t want to do. After trying to copy my existing Leap 15.3 installation to my new PC hardware, I had to accept that that distro couldn’t support the new SSDs and NVMes. So I patched Qt6 to make it work with Latin1 (iso8859-1) again (at least for the applications I use).

Well, the only thing SUSE is to blame for is having replaced YaST with an incomplete “Agama”, without offering a fallback option.

So, after these initial hickups, I guess I’ll be using Leap 16.0 after all…

13

That’s not correct. It is possible with the new installer, it is just not supported by the GUI. Agama is more than what you see in the web browser. You can edit and load installation profile with MD RAID; you will not see it in GUI:

image
image859×413 26.3 KB

but the settings are there and will be applied. The below profile is incomplete (no sizes etc), it just illustrates the overall structure.

    "drives": [
      {
        "search": {
          "condition": {
            "name": "/dev/sda"
          },
          "ifNotFound": "error"
        },
        "partitions": [
          {
            "alias": "sda-root"
          },
          {
            "alias": "sda-swap"
          },
          {
            "alias": "sda-home"
          },
        ]
      }
    ],
    "volumeGroups": [],
    "mdRaids": [
      {
        "devices": [
          "sda-root"
        ],
        "level": "raid0",
        "encryption": {
          "luks2": {
            "password": "xx"
          }
        },
        "filesystem": {
          "reuseIfPossible": false,
          "label": "",
          "path": "/",
          "mountOptions": [],
          "mkfsOptions": [],
          "type": "xfs"
        }
      },
      {
        "devices": [
          "sda-swap"
        ],
        "encryption": {
          "luks2": {
            "password": "xx"
          }
        },
        "level": "raid0",
        "filesystem": {
          "reuseIfPossible": false,
          "path": "swap",
          "mountOptions": [],
          "mkfsOptions": [],
          "type": "swap"
        }
      },
      {
        "devices": [
          "sda-home"
        ],
        "level": "raid0",
        "encryption": {
          "luks2": {
            "password": "xx"
          }
        },
        "filesystem": {
          "reuseIfPossible": false,
          "label": "",
          "path": "/home",
          "mountOptions": [],
          "mkfsOptions": [],
          "type": "xfs"
        }
      }
    ]
14

Well, if it’s not in the GUI, it doesn’t exist. How should the user (who never before had even heard of “Agama”) know that there is some file they need to edit to get there?

Sorry, but I can’t help feeling that dropping YaST in favor of a half baked newbie was a bad decision.

2 Likes
15

@kls openSUSE has always had automation tools for installation, autoYaST and with MicroOS Ignition/Combustion, now with the Agama Installer - Profiles… Then there is always athe ability to create your own images on the openSUSE Build Service.

For the newcomer, seems to me Agama has the right mix of options… For advanced installations, features are available as indicated by @arvidjaar

1 Like