Modern software controls dependencies because it helps software authors

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.

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 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.

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.

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.

Every app has the ground changing under it whenever the kernel updates to a new version.

Yet somehow we can still run binaries from the 90s. The browsers are broken and need to be frozen. Not something that will happen because google, like microsoft before it, benefits from constantly breaking, changing and extending everything to not let anyone catch up to them.

You mention penetration tests here (?), are those really less time consuming and more effective than taking 30 minutes to review a library?

Exactly, the rules here are different and there is monopoly involved. Accountability is dispersed. However, if you freck up here and it shows, you are in the news tomorrow. Good luck finding job after that. On company level, you can be banned for years in entire gov sector.

The big problem with that stance is however, that government usually doesn't do that work, it typically outsources to private companies that work on behalf of mega corps like Oracle, IMB etc. And they produce that "worst example of quality".

So, its not about the type of company its much more complicated.

> In all the private companies I worked either software was maintained or the feature wasn't in use anymore or the entire engineering team was about to be fired or the company itself had 2 months of life.

I am sure this is not the norm either. You say it like there is some kind of sensor telling you when "feature wasn't in use anymore" - for some domains it can be easy, for majority its not however.

Its understandable that people minimize the complexity of things involved here but that doesn't reflect reality.

> I agree on your point regarding security, closing every vulnerability is impossible or not economically sound for many realities.

Indeed. People act here like I said 0 security but I didn't - every professional worth its salt should do common "best practices", but going more then that needs serious thought, budget, planning etc. and it all depends on type of thing you do.

You obviously work in security and want to sell me bs.

> First of all, you seem to make the assumption that when an organization gets compromised, they will know about it.

No, you assume a lot about me while knowing 0. The bigger problem here is that you assume that people in corp care that there are hidden agents taking some data out. Let me open your eyes: they usually don't and ESPECIALLY if its not visible. If you replace their main site front page they will care.

> What valuables does your organization have?

Dude... go read my post again.

> Would you want a bunch of foreign companies sitting in your network, siphoning all your hard work out for free?

I don't care. Its up to my stakeholders, I don't work for my granpas company. WHEN they care, I do it. Mine is to inform. Theirs to decide. Guess what: they always decide against it, naturally, as it costs more otherwise. Security is a feature. It costs money. It can be theoretically done forever and take infinite amount of money. In last decade I had just 1 stakeholder requesting "unbreakable system" and we did the best we could.

Your main mistake seems to be to extrapolate your context to entire world. Context is everything.

You don't even need to have anything valuable in your company for security to matter because your customers' personal data is valuable to them, and by law you have to protect it in many places now.

A security breach must be publicized, and that's a black mark on your company whenever anyone is considering using it in the future. It doesn't even really matter how big that breach is, or what data was stolen.

But even worse, an unethical competitor might hack your data and erase it, leading to lengthy downtime or even permanently lost data.

That's most a server-side focus on security, but even client-side there could be things that allow hackers to mislead or damage your customers.

Libraries are updated constantly as old vulnerabilities are discovered and new methods of attack are invented. Leaving your OS or libraries un-updated is virtually guaranteeing that you end up vulnerable somehow.

The idea that if you don't know about a security problem, you don't need to fix it... Wow, it's just mind-boggling to me.

No it's you who is making assumptions and operating on "it must be this way" sense.

Simply because a project has not had changes in a few years (or even many years) doesn't make the project insecure or bad. Can there be bugs or security issues? Or course, any software can have those, but merely change rate as you see on the project download page has no bearing on that.

The article is saying pin stuff for as long as possible, like the guy replying here who says the version of the logging tool he integrated one time 10 years ago is all he will ever want.

Paid-for or FOSS, after his initial interaction 10 years ago, he is not going to *pay*, encourage, support, find bugs in or send patches to the upstreams. And that's the vast majority of users, me too when I look at the projects I uses and never contribute to.

> Relying on libraries maintained by developers with those incentives might not be appropriate for downstream projects that require stability and longevity.

That's a particularly sniffy approach to FOSS. You would have walked away from the now-dying Xorg back in the day? Gcc?

If people don't contribute to the things they are dependent on, there is no reason to expect them to still be around when they do want more from them.

From the FOSS project perspective these users do not directly manifest themselves in any useful way at all.

The biggest problem caused by using multiple versions of the same library is that object representations are not stable across versions. Let's say you use a library "foo" that creates and manipulates Foo objects. You want to serialize them to JSON, so you use the third-party library "foo-json". If you have foo@2.1.0 and foo-json depends on foo@1.9.7 then foo-serializers will likely fail to serialize the Foo objects created by your application. This is why npm supports peer dependency constraints, though usually they're invisible to you as a user.

There are also performance and cost issues associated with using multiple versions of each library:

1. Starting the application requires loading many of those library versions, so you will have higher start-up latency than if you only had one copy of each library.

2. If the target platform uses method-based JIT compilation (e.g. Java), each of those libraries will be compiled independently when it is used. This can cause the application to feel sluggish between the time it initially starts up and the time that all of the copies of the libraries on the hot path have been compiled.

3. The program needs to be loaded into memory to execute it. You're not only paying for more hard disk space, but also more RAM. The additional memory required can start to add up if you're running enough replicas of the application in production.

For many small applications the performance and cost issues aren't major concerns, but they can become problematic as the application grows.

For the record, I see both sides as having legitimate concerns.

I think that points needs to be made more often.

People focus a lot on active decisions that have the potential to introduce security vulnerabilities, but they underestimate how similar problems may exist in the status quo.

Having a single, only-one-canonical version dependency system is a recipe for package managers that update slowly because any dependency change may break an unrelated package.

Frankly, being able to say "just install every dependency and be done with it" and have Cargo/npm/etc handle all the conflicts implicitly is a huge time-saver. I think people underestimate how valuable that saved time is, both in terms of adding features and maintaining security.

It means that as time passes by, the things that need to be done accumulate and hence the pain of doing them. You don't need evidence for that. Its a common sense.

Otherwise, give one example when waiting for action (and in absence of divine/external intervention) makes it easier. Via this logic we can deduce that there must exist 100% self-fixing entities. I am not aware of any such thing. Many entities have some autocorrection (including us) but up to a certain point and usually (only?) when life is involved.

Or also one of my favorite issues are when dealing with rest APIs. They get flagged deprecated removed etc without remorse that it means that large parts of old software libraries are practically broken without actually being broken. Catching these means running active nightly builds etc if you don’t actively maintain the library on a regular basis. The switch from GitHub to use main as the default branch name for repositories brought a lot of issues with one gradle plugin I wrote because I hardcoded (yes it was my fault here) the value to be “master” which for years was the norm that every repo had one. In hindsight it was a clear oversight from my side because one could have removed the master branch before obviously.

- don't have the dependency in the first place

- supply your own dependencies instead of relying on the environment to provide them for you in ways you can't control

The ideal format for distributing software is a single, self-contained executable program far more often than parts of the developer community would like to admit. So many of these potentially serious problems just don't exist if you use a compiled language and you statically link a controlled set of dependencies at build time.

Obviously you still need to monitor your dependencies for essential updates and then issue updates of your own software to incorporate them when necessary, for example in the event of a security vulnerability being identified and fixed.

And obviously you may still depend on services provided by your host environment that you're communicating with but not incorporating directly.

But at least you always know exactly what your user will be running within your own program, you can test it properly before you ship it, and it won't then mysteriously change because of something they or some other software on their system did that you have no knowledge about or control over.

The problem is people depend on you because you provide X. You thought you provided Y. X was just a small side benefit. As a provider, how do you advanced Y without breaking X?