[3/*] With just one tool, the build has an over 95% chance of working after five year. With ten tools, it has only a 60% chance! And that's with every tool having a _99%_ chance of remaining working (meaning no breaking changes to the tool that affect the build in question).
-
-
I think at least part of it seems to be the perpetual problem of keeping a site running that has evidently grown so large they can no longer even guarantee that it does the right thing every time, only that it *eventually* does the right thing
-
There's probably a high degree of correlation between these two phenomena
End of conversation
New conversation -
-
-
I have wrote about this issue last yearhttps://www.emadelsaid.com/on-modern-web-applications-stability/ …
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Yep. I've seen this happen. The devs are on a treadmill, updating deps all the time. This is why I take all the dependencies and freeze them. I still use Qt 5.4 and Ubuntu 14.04 for linux builds of MultiMC. I'll update when I consider it necessary... not when a number goes up.
-
For this, you need stable ABI guarantees. Qt does that. So I can build with a 6 year old version and it runs with the current ones people actually have. There was one case of a crash bug introduced by upstream (Qt) in 6 years. They fixed it. Everything else just worked.
End of conversation
New conversation -
-
-
that is a bit simplistic conclusion. Lockfiles are a thing, if your codebase uses them then your dependency is your compiler/runtime/os + your dependency management service. If you commit your deps you eliminate your reliance on the dependency management service
-
you can replace your compiler/runtime/os with a docker image which could also be comited
- Show replies
New conversation -
-
-
I guess a dep has to promise that the features it provides out weighs the maintenance cost it incurs. Which for postgres might make sense, but for others it does not.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
For the build tools, you could put that in a Docker image as it is today, and use that same image in 5 years, and the tools will be exactly the same. Of course, then you miss out on updates that could be valuable. Not the prettiest solution, but might work? Any comments on this?
-
Security issues are always popping up in dependencies, and someone always wants to add another dependency that requires a later version of something else. In theory you can just keep using the same versions, but in reality there's always a reason you need to update.
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.