Live data from Hacker News

Never update anything

blog.kronis.dev

221–230 of 288 posts

Re: Never update anything

#221
It is so wrong to desire to return to handwritten Javascript and libraries like jQuery?

I don't do much fronted today and the reason are the frameworks.

I still do it but I use Blazor to generate web assembly.

Re: Never update anything

#222
post #119

Earlier quoted context omitted.

Having always been fullstack even in my current large traditional bank, I see both codebases in Java 6 and maven poms that are a paradise to change (and a java 8 upgrade is often trivial and sufficient to get most of the nice candies you really need), and yarn/npm frontend projects that cant be even rebuilt two weeks later, everyone insanely writing auto updating version descriptor (^2.0.4 with the ^). I cannot under…

The small dependency thing is a sad artifact of the days when most JavaScript libraries were built to run on the browser. In that context, prior to the days of mature tools to do things like tree-shaking to remove unused code, the easiest way to make things smaller was to make JS modules as small as possible so code could opt-in to subsets of a library it wanted to use. Fast forward 5 or 8 years and we have a very fr…

> the easiest way to make things smaller was to make JS modules as small as possible so code could opt-in to subsets of a library it wanted to use

Also due to JS having a very small stdlib. Compare built-in functions to eg Kotlin, its a different world.

Re: Never update anything

#223
post #209

Earlier quoted context omitted.

> I cannot understand what idiot thought it d be fancy cutting everything into mini dependencies that update every day without you knowing made by amateurish hipsters who transitive depend on each other like their life depended on it. I'm not sure you're thought things through in your comment, and that you are being fair or reasonable. No one cuts "everything into mini dependendencies". You have dependencies you reus…

> With JavaScript/NodeJS + npm you only shoot yourself in the foot that way if you purposely aim at your foot, remove the safety, and press the trigger really hard. Eh, no. You'll get shot no matter what, even if you have no gun. For example, let's imagine you now have your version locked down codebase and after a month you want to install a new package. This one is only compatible with XYZ V1 while what you have is…

This is a far bigger problem in the Java world. Maven will just pick at sort of random (it's deterministic but hard to predict and mostly invisible).

On the JS side there's a way deal with that if people use modules. Good dependencies don't clobber the global namespace. Multiple versions can exist side by side. It'll just make your build bigger.

Re: Never update anything

#224
post #98

"When your company won't be the first to market, because about 20% of your total development capacity needs to spent on keeping up" In the world of JS and Typescript this ratio looks more like 80%. I swear that node hipsters at my last job spent four out of five of their working days wrangling with dependencies or their transpilers, linters, packagers, bundlers and whatever the hell else needs to happen to actually m…

Having always been fullstack even in my current large traditional bank, I see both codebases in Java 6 and maven poms that are a paradise to change (and a java 8 upgrade is often trivial and sufficient to get most of the nice candies you really need), and yarn/npm frontend projects that cant be even rebuilt two weeks later, everyone insanely writing auto updating version descriptor (^2.0.4 with the ^). I cannot under…

> I see both codebases in Java 6 and maven poms that are a paradise to change (and a java 8 upgrade is often trivial and sufficient to get most of the nice candies you really need)

Using Java 6 is major red flag. Even Java 8 should be red flag nowadays, if it weren't so extremely common. Both versions no longer receive any security updates or bug fixes. If an organisation doesn't care to put a system on a platform with active security updates that tells me one of three things:

1. The system is unimportant and is basically value-less. I don't want to work on systems like that. 2. The engineers are incompetent and lack even the most rudimentary learning skills (or will) to follow even the most basic updates on the tech they use every day. I don't want to work with people like that. 3. Engineering management is too incompetent to listen to very important messages from their team. The system likely has major issues and a fear of fixing even minor technical debt. I don't want to work in an environment like that.

It's not seldomly more than one of these.

Re: Never update anything

#225
post #224

Earlier quoted context omitted.

Having always been fullstack even in my current large traditional bank, I see both codebases in Java 6 and maven poms that are a paradise to change (and a java 8 upgrade is often trivial and sufficient to get most of the nice candies you really need), and yarn/npm frontend projects that cant be even rebuilt two weeks later, everyone insanely writing auto updating version descriptor (^2.0.4 with the ^). I cannot under…

> I see both codebases in Java 6 and maven poms that are a paradise to change (and a java 8 upgrade is often trivial and sufficient to get most of the nice candies you really need) Using Java 6 is major red flag. Even Java 8 should be red flag nowadays, if it weren't so extremely common. Both versions no longer receive any security updates or bug fixes. If an organisation doesn't care to put a system on a platform wi…

Java 8, if you use corretto, is supported until 2026. It's totally fine to use and support. And java being java and jumping to 11 won't be that bumpy either.

Re: Never update anything

#226
post #121
post #117

Earlier quoted context omitted.

Mac and Linux do the same thing. I know people who still prefer the OSX 10.3 and the GNOME2 GUIs, or for instance the way nytimes.com looked back in 2010. That's the problem with making GUIs the thing you love. Some goons stop by your home every few years and toss up the furniture. Apple is the gold standard since it pretty much looks the same as it did in the 80's and each major version tunes subtle things. Microsof…

> Mac and Linux do the same thing The earlier responses in the thread were talking about forced upgrades. I'm not sure about MacOS since I don't use it much, but most Linux distros do not forcibly apply upgrades like Windows does; you can continue to use old packages and even reboot the machine indefinitely. Sure, you might not get security fixes or keep unrelated packages up to date beyond a certain point, but that'…

> I'm not sure about MacOS since I don't use it much, but most Linux distros do not forcibly apply upgrades like Windows does;

Eh, not very accurate in my opinion. If you want to use the latest software you are very much forced to upgrade Linux because they have no concept of separating the platform from the applications that run on it. Either everything is bleeding edge or nothing is. Or you compile things from source like it is 1979.

There are Windows programs released today that will run just fine on Windows 7. How many Linux programs released today will run on Karmic Koala without recompilation?

Re: Never update anything

#227

Timely. I was recently force upgraded to Win11. Today in fact. Last week I force-downgraded after I got an exception because it is my busy time of year. That exception was not respected and I realized fighting it weekly would be the same time investment as fixing compatibility issues. "What compatibility issues? Win11 is fine, I have had no problems." My coworkers say. Well on Day 1, 2 pretty important pieces of soft…

Might come in useful to others on Win11: To get the snipping tool working, close the snipping tool, manually set the date to around the start of October. Reopen the snipping tool and it should be working. The date can now be set back.

The mind boggles at imagining the code that could possibly be responsible for this behavior.

Re: Never update anything

#228
post #175

Earlier quoted context omitted.

"Breaking" is undefinable. I remember reading about some user complaining that a small bugfix broke their work setup because it fixed a bug that used to make the CPU go 100% when the spacebar was held. The user would hold it with a weight and get the CPU to make heat that way. The small fix broke his experience. There are many other examples of this. Breaking compatibility by fixing bugs people rely on for instance.…

> "Breaking" is undefinable. I remember reading about some user complaining that a small bugfix broke their work setup because it fixed a bug that used to make the CPU go 100% when the spacebar was held. The user would hold it with a weight and get the CPU to make heat that way. The small fix broke his experience. You confused XKCD with reality: https://xkcd.com/1172/ >

Oh that's where i read that. Thanks!

I believe the point i made still stands though

Re: Never update anything

#229

> Docker Desktop doesn't let you decide whether you want updates or not, unless you pay them This made me uninstall Docker Desktop.

Most of my experience with Docker Desktop is on a Mac behind a corporate proxy. I swear with every update they either removed my proxy settings or changed the behavior of how docker build and docker runtime inherited the proxy settings. It was maddening because inevitably everyone on the team had different versions and therefore different behaviors. Took away the whole point of having a common tooling container.

Re: Never update anything

#230
post #158

Earlier quoted context omitted.

Having always been fullstack even in my current large traditional bank, I see both codebases in Java 6 and maven poms that are a paradise to change (and a java 8 upgrade is often trivial and sufficient to get most of the nice candies you really need), and yarn/npm frontend projects that cant be even rebuilt two weeks later, everyone insanely writing auto updating version descriptor (^2.0.4 with the ^). I cannot under…

If you can't get reproducible builds the team doesn't know how to use lock files properly. Don't go blaming it on the stack.

What's your workflow with lock files? Do you force them in CI/prod only or also in dev?

I'm tempted to enforce lockfiles at every stage of the product cycle, making upgrades an explicit action, rather than the side-effect/byproduct of another action. Does it make sense? What do you think?

Post reply on HN