Comment by j1elo | Hacker News Reader

Comment by j1elo | Hacker News Reader

Parent Full thread

Coincidentally, yesterday I was talking with a friend about which terminal we use, and how I went from the default gnome-terminal to the more capable konsole, moved by a silly bug: "Select all" doesn't select _all_ text, but only the text that is currently under view [1].

That's caused by a "temporary" fix in an underlying library, which seems was not so temporary, given that it got into the feature freeze and release of the Ubuntu LTS I use.

This means that for the whole support period of any distro that bundled the broken feature, users will find it and have to work around it, over and over.

Can you imagine if that was for a century?

I think distros should relax their policies and not only accept changes to fix security vulnerabilities (as is the case now), but also to fix promised features that shipped in a broken state. Otherwise, once some broken software ships, it stays broken for the whole lifecycle of the distro, which is bonkers.

[1]: In case anyone can provide further feedback, ideas for the author on how to fix it, or any help. https://gitlab.gnome.org/GNOME/vte/-/issues/2504

> Can you imagine if that was for a century?

If i had to keep a software stack for a century, i wouldn't pick GNOME. Generally you'd avoid any software project that has the faintest smell of "move fast and break things".

-- ex GNOME user

I wouldn't pick anything Linux in general if moving fast and breaking things is problematic.

I'm still looking, do you have recommendations?

The BSDs, OpenBSD in particular, are built for long-term. Any change is evaluated multiple times before being integrated. From the point of view of Linux they can seem outdated/old/lagging, but from their point of view they just work.

That's not true. Just because from the user perspective it seems not much is changing, there are tons of changes underneath. They don't guarantee user space stability like Linux does, so they can move faster (including upstreaming changes from ports). They only support the last 2 releases. Considering that there is a release every 6 months, that's 1 year of "LTS".

I love BSDs. I started my career with them. However, I don't think this long-term-sh view is actually conscious on their part. They simply have fewer people to work on new things so things lag a lot. It's more of a side effect.

This is a misconception. The "lag a lot" is very much debatable. For a lot of areas, specifically OpenBSD, is pushing the boundaries[1], not lagging behind. That's why they don't guarantee user space stability or even ABI stability inside the kernel, to move faster. Just check this recent case[2] about Linux is not enforcing IBT/BTI on its binaries and this being a known problem since 2001, while OpenBSD is solving this.

But again, people have different conceptions of lagging behind. Some people think not having a graphical installer is to "lag behind", when this is pretty much a design decision and not a problem of fewer people working on new things.

[1] https://www.openbsd.org/innovations.html [2] https://undeadly.org/cgi?action=article;sid=20230714121907

It's not about the installer (who even uses those anymore?), it's about features and power.

Linux has had a lot of work done to support complex features and scaling in a number of aspects, whereas OpenBSD has not. In fact, the insistence on security and keeping things conceptually simple, almost inevitably means they pass on some significant improvements. When you want pure power, OpenBSD is just not the best choice, for example; and the virtualization stack is very primitive.

OpenBSD rather notably and explicitly lacks any notion of "LTS" (all releases are unsupported after a year) and is perfectly happy to break things without much of a grace period (prime example being the switch to a 64-bit time_t for all platforms).

That said, the upgrade process (like most things) is thoroughly documented every release, and a given release will continue to chug along for years, so I can see where you're coming from there.

They guarantee even less stability than Linux, what are you talking about ?

Windows' legendary backward compatibility.

If we're talking Linux desktops, I've heard Xfce referred to as the Debian of DEs, and I have to agree.

Fairly slow incremental changes over time, and no real surprises on a new release.

It's incredibly boring, but in the right way.

Maybe the framing shouldn't be "move fast and break things" but more of a computing as pop culture roughly from Alan Kays saying.

Gnome has adapted to changes in computing form factors, supporting more mobile setups (touch and tablet) that emerged over the past 15 years while other DEs may mature around a Desktop/Laptop setup.

- mostly happy Gnome user

Every time I update to a new GNOME version, the Power menu shifts around. I keep having to relearn where things like the Lock Screen button is. I don't understand who keeps remaking these decisions or why...

My theory is that MS pays deep cover moles to infiltrate GNOME and sabotage it from within.

It's less sad than thinking that they do it to themselves.

Software should be reliable, but I'm not fond of LTS. As a developer, I'm fine with 3 years of support, security or otherwise.

The decade of (security) fixes (free or otherwise) smells like neglect. This is probably fine with 80s or even 90s software. But for internet connected devices I think it's bonkers to expect others to maintain and support the foundation of your software.

That is, assuming the software is functionally done, finished and no longer maintained. If whatever you meant to build, is still maintained and actively supported, it should not be too much to expect the OS to evolve with it. Upgrade to the latest platform every now and then.

Yes, migrations can be painful, but grow up: test thoroughly and get your ducks in a row. If that's too much to ask, you're simply lifting beyond your weight.

> assuming the software is functionally done, finished and no longer maintained

This ties in very well with a discussion that happened a couple days ago about whether the concept of "finished software" even exists:

https://news.ycombinator.com/item?id=36877363

> As a developer, I'm fine with 3 years of support, security or otherwise.

There's the problem: developers primarily think of themselves, expecting end users to be power users not unlike developers.

That doesn't hold. Developers can handle change & a rapid upgrade cycle. End users... not so much. Or not at all.

The only updates end users care for are risk-free, invisible, hassle-free (as in: automatic) updates that plug security holes, correct broken functionality, or minor feature updates that don't interfere with anything already there. For example drivers that support new hardware which uses existing system bus w/ existing software infrastructure.

Update can't fit into this frame? Then put it in next, feature-breaking release. Not in currently-stable, supported one.

Imho, Linux currently has a pressing need for community maintained distro with 10y+ LTS cycle. Or existing distro that offers 10y+ support on selected releases. Such distro could easily send RHEL into obscurity.

I'll add that even for developers or power users, very few are in that category for more than a couple of areas. There are some things I know about but that leaves 99 percent of my box where I'm relying on others.

What you're basically saying is you want developers to volunteer to give up their ability to advance their own careers writing features, and only fix security bugs in old junk that isn't entirely broken instead. You'd have better luck getting them to volunteer to be maids. If you want long-term community-driven support, then you'll stand a better chance getting it from developers focusing on making new things that are backwards compatible, rather than asking maintainers to keep old stuff alive forever. For example, Cosmopolitan Libc uses modern GCC11 to build binaries that support running on every distro all the way back to RHEL5, and I think that's the thing you actually want, except it's something you'll never see happen from distros, because they operate by a different set of incentives.

Sure, and that's what most do. But they don't actually derive any value from it - it's just busy work because others want the new features. If we could have 50 years of secure Windows XP or Linux 3.something, lots of software teams would be freed from periodic migrations to just building more features.

Windows XP was essentially an LTS as it did get 12 years of support.

However there were plenty of severe flaws that couldn't be fixed without some fundamental changes.

What people appear to want is all the problems fixed, but none of the hassle of actually having anything change to accommodate these fixes.

> but also to fix promised features that shipped in a broken state

fixing bugs sucks. That's why rewrite the whole thing.

Reply on news.ycombinator.com