In MySQL, use “utf8mb4” instead of “utf8” (2016)

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by waynesonfire on Wednesday January 12, 2022 @02:56PM (#29911975)

I'm going to use this as an opportunity to vent.

Wouldn't it be a nice world where you can just declare something EOL and it disappears and somehow magically it's not a problem anymore for anyone end-to-end? Thing's just don't work that way. Like, suddenly, a product that was working perfectly fine for who knows how long suddenly needs to modified because some ass-hats thinks that EOL isn't suitable for production.

There are a number of reasons to upgrade a dependency or a product; an EOL label shouldn't be a part of the calculus. EOL may imply certain conditions that may influence the decision to upgrade but for the sake of EOL you can eat a bag of dicks. Think harder why you're proposing an upgrade is needed and how it'll add value to the business. EOL software is perfectly fine especially because it's been battle tested.

We also use log4j 1.x all over the place and I feel zero need to change that.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by dimitrios1 on Wednesday January 12, 2022 @03:05PM (#29912066)

It is perfectly reasonable to continue to use EOL software, but you have to assume maintenance costs in that case. It would be irresponsible to continue to use EOL software as is. EOL is a perfectly natural concept. Nothing in this world lasts forever, including our machines, electronics, cars, batteries, lives, and yes, software.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by rkagerer on Wednesday January 12, 2022 @05:49PM (#29913849)

If software lasted a lifetime, life would be so much easier.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by kortex on Wednesday January 12, 2022 @07:36PM (#29915156)

For the end user, not the maintainers. Who's gonna sign up to keep that ENIAC, PDP-11, ALGOL 58, python2.3, win3.1, etc, code running, stable, and not a source of exploits?

Or do you mean in the abstract, fairy-tale ending sense?

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by dimitrios1 on Thursday January 13, 2022 @03:00PM (#29926007)

I think they meant in the tongue-in-cheek sense.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by Dylan16807 on Wednesday January 12, 2022 @04:55PM (#29913251)

> EOL may imply certain conditions

And "EOL" is a convenient shorthand for those conditions.

Most use cases care about never getting patches for security problems ever again.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by andrewjl on Thursday January 13, 2022 @01:57PM (#29925030)

> There are a number of reasons to upgrade a dependency or a product; an EOL label shouldn't be a part of the calculus.

If the end user of the product or their needs don't matter, sure.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by Shared404 on Wednesday January 12, 2022 @08:48PM (#29915797)

> We also use log4j 1.x all over the place and I feel zero need to change that.

I dunno, a widly known RCE seems a pretty good reason to take something out of production.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by fiddlerwoaroof on Wednesday January 12, 2022 @09:15PM (#29915985)

This is a case of “too old to be vulnerable”: the exploit only affects log4j 2.x

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by Shared404 on Wednesday January 12, 2022 @09:47PM (#29916186)

Ah makes sense. I should've looked it up and double checked before commenting, my bad.

Honestly, in that case I tend to agree with GP. As long as you recognize EOL means you are in charge of supporting it and possibly backporting security fixes and you're okay with that - why not use it?

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by smaudet on Thursday January 13, 2022 @11:39AM (#29922843)

I agree EOL is too often interpreted to mean 'Insecure' - in the case of closed solutions this is absolutely the case (presumably, it is often difficult to audit closed and obfuscated closed source solutions).

In many cases it is not, it is purely a 'ticking time bomb' - if new CVEs or requirements arise which cause issues in EOL versions, you may not even become aware of the vuln.

In counterbalance, new versions of code have new, unknown CVEs, new bugs, etc.

The issue is that of support, the fallacy and process issue is that 'current' support is of greater quality than 'historical' support, or that old software has a disproportionately higher support costs than 'current' software.

The true issue is overdependence on FOSS software and unwillingess to contribute - all software has costs, major vendors are 'coasting' on work provided by free volunteers and panic when those volunteers decide to no longer work for free.

If vendors were doing the legwork necessary to properly inhouse their dependencies, I would wager that much less software would end up discarded in 'fear', for a lack of a better word than this - modern development is supposedly built on features and patches, any codebase should be maintainable for a much longer period than its supposed EOL.

[ Parent | on HN ]

Re:In MySQL, use “utf8mb4” instead of “utf8” (2016) by GoblinSlayer on Thursday January 13, 2022 @05:39AM (#29919181)

I don't see a problem, customer/employer pays and modifications happen.

[ Parent | on HN ]