Hacker News Reader

Comment by userbinator | Hacker News Reader

It's really disturbing that software is the only thing whose stability seems to be decreasing very significantly over time, and dragging down everything that it's embedded in.

Who wants constant changes and breakage? Who wants software that's in constant need of updating? I'm pretty sure it's not the users.

View on HN

The point of LTS kernels is that they do get constant updates ie that security patches are backported. There is no world in which you can avoid updating frequently.

There are many more updates than security updates coming to LTS kernels all the time.

Kernel updates are more often than not even categorized in any way. Only for very prominent vulnerabilities the security impact is clear to a larger audience.

Upstream seems downright hostile to classifying patches as security.

Nearly any bug could be a security risk.

Could be yep, the delicate dance of writing in C.

So does it mean that linux is rolling out updates but these updates do not consider security? Just curious about this thing, I just started using linux and this topic is interesting for me

It means that there are bug fixesall the time, but most of the time no one sorts these into "security" and "non-security" categories.

I remember a message (I can't find it back right now) where this is explained. Basically the thinking is that a lot of bugs can be used to break security, but sometimes it takes a lot of effort to figure out how to exploit a bug.

So you have some choices:

* Research every bug to find out the security implications, which is additional work on top of fixing the bug.

* Mark only the bugs that have known security implications as security fixes, basically guaranteeing that you will miss some that you haven't researched.

* Consider all bugs as potentially having security implications. This is basically what they do now.

I understand the sentiment, while also looking at our computing devices' market where the fight for repairability is pretty harsh and far from a given.

Same for cars that are becoming less and less repairable and viable in the long term, medical devices are now vulnerable to external attack vectors to a point the field didn't predict, and I'd assume it's the same in so many other fields.

One could argue those are all the effect of software getting integrated into what where "dumb" devices, but that's also the march of progress the society is longing for...where to draw the line is more and more a tough decision, and the need for regulation kinda puts a lot of the potential improvements into the "when hell freezes" bucket. I hope I'm deeply mistaken.

There's always time to refactor and tinker with incomplete migration, always time to debug and patch and fuss with updates, but never time to sit down, gather all the requirements, redesign, and reimplement.

Ultimately it's just a question of objectives. Usually software isn't written for its own sake. It's written to achieve a goal, meet a customer need, generate revenue, prove a market, etc. You can achieve those goals without gathering all the requirements, redesigning and re-implementing most of the time. Not in aerospace, or biomedical maybe, where we are willing to pay the outlandish velocity penalties. But most of the things we do aren't that.

Generally, if you want to build a pristine, perfect snowflake, a work of art, then you'll be the only one working on it, on your own time while listening to German electronica, in your house. [1] Nothing wrong with that - I have a few of those projects myself - but I think it's important to remember.

Linux is hoping to adjust the velocity-quality equilibrium a little closer to velocity, and a little further from quality. That's okay too. Linux doesn't have to be everything to everyone. It doesn't have to be flawless to meet the needs of any given person.

[1] https://www.stilldrinking.org/programming-sucks

> Not in aerospace, or biomedical maybe, where we are willing to pay the outlandish velocity penalties.

… because we really needed X version of software out yesterday? This incredible “velocity” that you speak of has created monstrous software systems, that are dependency nightmares, and are obtuse even for an expert to navigate across. In the rush to release, release, release, the tech sector has layered on layers of tech debt upon layers of tech debt, all while calling themselves “engineers”… There’s nothing to celebrate in the “velocity” of modern software except for someone hustling a dollar faster than someone else.

I for one enjoy the fact that AMD GPU drivers have been upstreamed.

Gathering requirements doesn't have to take months. It can take hours or a few days. You can even do it in the middle of maintaining a product, e.g. as part of steps towards addressing a feature request or a refactoring. It doesn't strike me as unreasonable that in the 50 years of building UNIX-style kernels, and the 30+ year development of Linux to have someone write down some functional requirements somewhere.

The software version of "There's always time to do it twice, but never time to do it right?"

That is how C rolls. In theory you need to formally verify every single C program to ensure that it does not violate memory safety. Yes, that is akin to the same straightjacket that people complain about in that iron oxide language.

If you think about the fact that higher level languages are largely a 1950s innovation, it helps.

Disciplines that are 70 years old are not likely to be stable.

Reply on news.ycombinator.com