Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Never Update Anything

blog.kronis.dev

Post reply on HN
Print view View original

71–80 of 121 posts

Re: Never Update Anything

#71

Post by Joel_Mckay »

graemep wrote: post #64
Joel_Mckay wrote: post #23

Earlier quoted context omitted.

Apache is stable for wrapping mixed services, but needs a few firewall rules to keep it functional (slow loris + mod_qos etc.) =) Ubuntu LTS kernels are actually pretty stable, but containers are still recommended. ;)

What exactly do you do to protect Apache from slow loris? Its my main reason for not using Apache.

There are several different ways, but the easiest is mod_reqtimeout/mod_qos/mod_security. Check your install with "sudo apache2ctl -M", and there should be several legacy tutorials available (I'd ignore deprecated mod_antiloris.)

Rate-limiting token-bucket firewall settings are a personal choice every team must decide upon (what traffic is a priority when choking bandwidth), and often requires tuning to get it right (must you allow mtu fragging for corporate users or have a more robust service etc.) These settings will also influence which events trip your fail2ban rule sets.

Have a great day, =)

Re: Never Update Anything

#72

Post by canpan »

dzonga wrote: post #44

java over golang lol. when golang has literally been version stable for over a decade now

I think the article is interesting. But you are right, golang is the one language I would recommend to someone who does not like updates.

Re: Never Update Anything

#73

Post by dasil003 »

chrisjj wrote: post #60
dasil003 wrote: post #42

Earlier quoted context omitted.

I never worked on games, but I did do a streaming video app for PS3 in 2010, during the time period when it was arguably the best media center box available. Working with Sony (SCEE) on this was eye opening how their QA process was set up. Essentially you formally submitted the compiled app (C++ and Flash!) to them, and then tickets would come back and you'd have to address them. QA was a separate org so you never re…

> then tickets would come back Luxury! With Nintendo you'd often get only one ticket. Any further bugs would cost you further submissions, and months of slippage.

Thanks for jogging my memory! I believe we did two rounds of QA, the first was unlimited but shallow and high latency, the final QA I believe was called Format QA and there was a quota, if you had more than 6 issues or something you were rejected and had to go back into the queue (for months).

Re: Never Update Anything

#74

Post by userbinator »

There is also another type of update: security updates that don't actually matter in the environment that the software is used in. The question of whether the "new features" are for or against the user is another point to ponder.

Re: Never Update Anything

#76

Post by augusto-moura »

KronisLV wrote: post #19
cjalmeida wrote: post #15

Earlier quoted context omitted.

>might need to migrate over to something else for the blog, with a proper cache Never Update _Anything_ :)

I am very much tempted not to because it works under lower loads, could just put it on a faster server, but how could I pass up the chance to write my own CMS (well, a better one than the previous ones I've done)? That's like a rite of passage. But yes, the irony isn't lost on me, I just had to go for that title.

If you are using open source you can always support your own old versions ~joking but not really~

Of course security updates are very hard, but if an old version has some good community you have the option of forking or upstreaming the updates yourself

Re: Never Update Anything

#77

Post by yjftsjthsd-h »

Plasmoid wrote: post #66

I was working at a place that delivered onprem software. One customer asked us "We like features of version N but we're running N-1. Can you backport them so you don't have to upgrade?". I replied we'd already done that, it was called version N.

I mean... there could be a case for "does this feature really require breaking changes?" that would distinguish those.

Re: Never Update Anything

#78

Post by palata »

SoftTalker wrote: post #8

"In my eyes it could be pretty nice to have a framework version that's supported for 10-20 years and is so stable that it can be used with little to no changes for the entire expected lifetime of a system." This is what applications used to be like, before the web and internet hit and regular or even push updating became easy. It was simply so difficult and expensive to provide updates once the software was in the cu…

> For the most part, you bought software, installed it, and used it. That was it. It never changed, unless you bought it again in a newer version

And it was much better than the current situation, if you ask me.

Re: Never Update Anything

#79

Post by specialist »

dasil003 wrote: post #42
tivert wrote: post #26

Earlier quoted context omitted.

> Frequent updates, in the old days, meant that a vendor had poor QA. I think that's probably still the case most of the time today, too. The internet has normalized poor QA. The bosses don't give a shit about QA anymore because it's so cheap to just push out a patch. I mean just look at old video game magazines that talked about the software development process: the developers would test the hell out of a game, then…

I never worked on games, but I did do a streaming video app for PS3 in 2010, during the time period when it was arguably the best media center box available. Working with Sony (SCEE) on this was eye opening how their QA process was set up. Essentially you formally submitted the compiled app (C++ and Flash!) to them, and then tickets would come back and you'd have to address them. QA was a separate org so you never re…

aka acceptance testing

aka The Correct Answer™

For the products I managed in the 90s, I put QA/Test in charge of releases. Very unusual. The results were awesome.

Re: Never Update Anything

#80

Post by palata »

> My experience shows that oftentimes these new and supposedly backwards compatible features still break old functionality.

Well that's the first issue: downright malpractice. Developers should learn how to know (and test) whether it is a major change or not.

The current situation is that developers mostly go "YOLO" with semantic versioning and then complain that it doesn't work. Of course it doesn't work if we do it wrong.

Post reply on HN