Hacker News Reader

Comment by captainmuon | Hacker News Reader

I don't know, as a software author myself I don't like the "modern" way of thinking. I like to write an application once, and then be able to update the dependencies and it will still work later, because the dependencies use a stable and sensible interface.

I remember writing a couple of apps in the early GTK 2 days, in PyGtk, and they would still run with the very latest GTK 2 version. Due to pythons dynamic nature, I could even get them to run on older GTK versions (when I needed to run on CentOS) by providing polyfills for the one or two missing methods.

I get that compatibility shifts the maintenance burden to the library developers but that complexity has to go somewhere, and I'd prefer it centralized.

View on HN

It's kind of astonishing to me that I can run software written 30 years ago in C without changing anything, yet I can't expect a node project written last week with the exact same functionality to work today without a huge test suite.

Progress!

What amazes me more is that there are people actively arguing that this is a good thing. You see developers spend huge amounts of time chasing down obscure dependency issues and begging on forums for help with how library X works with version Y on platform Z, yet many of these same folks will come online and tell you that this is a great thing.

It's like many of us (and I include myself in this observation) are unable to step outside our own work and see how we actually spend our time. We become so obsessed on the goal that we lose track of how many new obstacles we put in our own way year-after-year.

I’m half convinced that developers self-inflict incidental complexity to justify their job at some level. And also because they have a poor technical aesthetic and don’t know that it can be better.

I caught myself thinking this as well. TBH, I feel the same about most professions, politicians in primis. But if I have to think rationally "Never attribute to malice that which is adequately explained by stupidity"

Why?

> Why?

Malice implies intent, which absent supporting evidence may be an unwarranted assumption. This is a form of attribution bias.

For that matter, assuming stupidity can be an attribution bias as well, as the action being judged may be random, ill-informed, or otherwise subject to additional context of constraints or circumstances we aren't privy to.

Yeah. I don’t see it as stupidity, but entirely rational behavior in the face of complex existential issues.

> I like to write an application once, and then be able to update the dependencies and it will still work later, because the dependencies use a stable and sensible interface.

as a software user I really hate using an app and having its GUI randomly change even if the app wasn't updated, just because the linux distro changed some lib underneath

Why do you want updates if not for that.

The reason one updates the distribution is to get new features or fixes. It would be a friggin disaster if only this program got the fixes, but not that program, so now they can't agree on the clipboard format, for example.

A lot of users don't want updates. They just want their software to work and do whatever they're using it for.

As a practical matter, software that is network-accessible or deals with data from outside sources may well need a security patch from time to time. Those updates are good for almost everyone, but by their nature, they should also be transparent to users.

It's a different story when you're talking about changing functionality that is visible to the user. Almost everyone hates it when UI elements like menus or toolbars or dialog layouts or shortcut keys get changed from what they're used to, particularly if there is no apparent reason for the change.

> As a practical matter, software that is network-accessible or deals with data from outside sources may well need a security patch from time to time.

This is as good argument as any for allowing the dependencies to be updated without updating the main software.

> A lot of users don't want updates. They just want their software to work and do whatever they're using it for.

>As a practical matter, software that is network-accessible or deals with data from outside sources may well need a security patch from time to time. Those updates are good for almost everyone, but by their nature, they should also be transparent to users.

That's a problem of the system you're using. I use Debian stable for my servers because you can only allow security patches: https://wiki.debian.org/UnattendedUpgrades

My business servers typically run Debian Stable for exactly this reason. Most platforms, sadly, are not as reliable in this respect as Debian's.

In particular, big consumer platforms like Windows, iOS and Android have all been horrendous when it comes to conflating essential updates for things like security patches or catastrophic data loss bugs with arbitrary updates that change behaviour and move UIs around.

> A lot of users don't want updates. They just want their software to work and do whatever they're using it for.

True. But these updates often are what keeps the software working, as software doesn't usually live in complete isolation from the rest of the system. Not having to rely on the system dependecies helps in decoupling and being able to update in a more controlled fashion.

If you have to fear with every update that something is taken away from you, then maybe you are just getting your software from the wrong people?

I'm not sure I follow. You have to update to keep the software working when you update? Why not just not update by not updating and just keep using the software that works?

The point they are making is that the software generally don't run in isolation. It might be true in some rare cases, but often computer are connected to network and need to read files that weren't created on the same computer.

You can probably use a computer with software from 20 years ago, but don't expect the web to work well, and to be able to open files made with recent software for example.

>You can probably use a computer with software from 20 years ago, but don't expect the web to work well, and to be able to open files made with recent software for example.

There's no real reason why this can't be the case, or at least graceful degradation. The sole reason is because it's all ultimately a battle for control of your computer. Thanks, capitalism

Because ultimately you have no idea what you are doing, unless you spend your whole day tracking what is going on with the (often hundred) pieces that make up the software you are using.

There might be an error in the software you are using that malware or hackers can use to run abitrary code on your machine. Unless you keep your software up to date or manually make sure the updates are not for security purposes, those who not update increase their exposed surface.

Then imagine you don't update your software, but (because of security reasons) you update your operating system. Suddenly your (back then working) software finds itself in a changed environment. If you are lucky it works, but just as well it can stop working (or create new security holes because the software relied on something in the OS that changed).

I know people who e.g. run 10 year old Audio programs or stuff. But they do so on a computer with a 10 year old OS that is not allowed to connect to the internet. This is a good strategy.

> Why do you want updates if not for that?

For security patches - that is by far the most important issue, followed by (in order) non-security bug fixes and finally non-breaking enhancements. What is definitely not wanted are regressions, which, in my book, includes cryptic changes to the way one does a task, even if it is still possible.

And the first of these is, of course, a strong argument against bundling, while the last of these is the thing that most motivates bundling.

It is unfortunate that this is being presented in an us-versus-them way, when cooperation for the common good is needed.

Yeah but isn't one point of updating to get UI improvements?

If you install a new theme, I expect the UI of apps to change. I recall there were updates that allowed you to drag a window from the titlebar, add overlay scrollbars, get a macOS-like menu and so on.

(I might be showing my age here but I recall how excited everybody was when Windows 95, 98, 2000, XP came out, just because they looked fresher. You didn't need to force updates on people, people were excited to pay $200 to run the same apps on a fancier OS. I wonder when that changed.)

The alternative is asking dependencies to never ever make any breaking changes anywhere.

This is not sustainable long term. It forces library authors to grow APIs purely additively, which eventually makes them overcomplicated and full of traps that can't be fixed, e.g. look at X11 and its recurring drama of screensaver lock security.

Library authors have to eventually clean stuff up. Ossified applications have to eventually update. Semver just adds a way to coordinate it.

This argument is sensible, but given that applications outlive both hardware and operating systems, the alternative is users keeping whole operating systems around forever without updating them.

The Linux kernel is one opposite example. They are pretty hard line about never breaking userspace APIs. It is overcomplicated and full of traps though. For most end users it's still worth it.

The reason you took X11 as an example is because it's still around, all modernized APIs that leveraged broken backwards compatibility are long gone by now.

There is a solution to the additive API problem, but C and C++ do not allow it. The solution is to create separate modules like x11/v1, x11/v2, etc. which live in the same distribution. It is therefore permitted for module A to use x11/v1, module B to use x11/v2, and module C to use both A and B (you may need to also provide a shim between common types like a to_v1 function). In this setup x11_v2 probably exposes many of the same bindings as v1, but that is ok since it is low effort to wrap a function or to re-export a private module with the common bindings.

This doesn't work in C/C++ due to how the C ABI works. There needs to be an easy way to say that even though A and B both have a foo function they are not the same foo and a way for module C to use both versions of foo by renaming one of them in its source. This is the greatest sin of the C ABI in my opinion, not even the lack of overloads.

I think if you use dynamic linking, it is in principle possible for module A to use v1 internally, and for module C to use v2, and neither to know about the other. But you can't use global objects, and you can't share objects from the internal libraries between modules. And the dynamic linker on Linux at least tries to reuse symbols, so it doesn't work by default. This was a big problem in the Gtk2 / Gtk3 transition, where you could not use both in the same process. I think there is a flag to prevent symbol reuse, though.

This is a solved problem with symbol versions and symbol aliases, which are used extensively by libaries like glibc that care about providing a stable ABI.

For C++, GCC and Clang also provide the abi_tag attribute:

> The abi_tag attribute can be applied to a function, variable, or class declaration. It modifies the mangled name of the entity to incorporate the tag name, in order to distinguish the function or class from an earlier version with a different ABI; perhaps the class has changed size, or the function has a different return type that is not encoded in the mangled name.

This was introduced to allow mixing pre-C++11 and post-C++11 std::string and std::list implementations in one libstdc++.so but is more general.

The other solution is of course a new SOVERSION but that does not allow two different versions to be used in the same process as ELF symbols are a process-global namespace.

Reply on news.ycombinator.com