No. It's because you were figuring things out and making terrible decisions 50 years ago. None of you really knew what you were doing. You just called IBM support and had them do things for you, or did what the manual said.

The fact that systems can't be upgraded and have to run in layer after layer of emulation is proof that you did a poor job building a maintainable system. You never changed the program to run on a new system. You always had IBM to save you from doing it by having companies pay them more and more.

Yes. Definitely. Without a doubt.

The problem with these old COBOL systems is that they have decades of patches one on top of another, and very little formal testing. These systems were made in a time long before "modern good practices" were established. They work because the business requirements are straightforward and change very little. And the things they do are relatively simple. The barrier to entry is extremely high. COBOL is not taught anymore, and even if you learn COBOL on your own in Linux, in real life it won't be a Linux OS. It'll probably be several layers of proprietary IBM VM emulation, with Linux running AS/400 running AIX. And on top of that, you have whatever customizations this particular user made. You're a slave of what someone that wasn't necessarily a "wizard" decided 40 years ago.

With a more "modern" language, COBOL can make use of modern "good practices", especially automated testing and such.

the "jump frameworks every couple of years to whatever is trendy" is out of place when you are mentioning Java and C#. Both are well-established languages and have been stable for literally decades now. Java and C# (actually .NET) people are not in the same game as JS developers.

The problem isn't the language, but all of the things that come around it. Using a modern language would, if anything, let you ditch the expensive IBM support contracts for mainframe hardware (and maybe switch to slightly less expensive support contracts for regular hardware)

That's what I got from this.

if anything, it's more vulnerable than on-prem because on-prem very often uses "bad practices" that end up saving you.

For example, it's good practice to have DNS names for everything. Lazy sysadmins will just hardcode IPs instead

But hey, you're immune to DNS failing you if you do this...

It's a solved problem really

OpenAI's Whisper model is excellent at this. it understands lots of languages, dialects, and accents. it just works. Also it's open source unlike everything "Open" AI pushes nowadays.

But other companies insist in using us as training data for their own private models

Or if you have the wrong accent.

Voice Control has always been tuned, in spanish, for either Spain or Mexico.

I'm from Argentina and these things don't understand me. I have to speak in mexican for it to barely understand me.

I'm not going to do that.

I think Temple OS would better suit you. Linux development is full of DEI and all that stuff you hate.

right comment this time

Sorry responded to the wrong comment

I think Temple OS would better suit you. Linux development is full of DEI and all that stuff you hate.

It's not really rescuing them yet. We're doing warranty repairs. The backlight LEDs are driven so hard they fail within the warranty period. It's ridiculous.

We do out of warranty repairs too of course.

As for which TV to buy, it's a difficult question. The grass is always greener on the other side. If you work for Sony you see a lot of Sonys and you'd think Sony is bad.

"Brightness" and "Backlight" are two separate controls in LCD TVs. You can check this with your TV. Go to the menu and you'll see the two separate controls. If you dial down the brightness, the backlight bleed stays the same.

Brightness is a software adjustment that affects the displayed image, and backlight physically turns down the LED intensity.

Shit-grade TVs don't control the LED intensity. They run them at 100% all the time and just software-dim the picture.

my dad is a TV service person here in Argentina. We work for that major dutch brand that is now owned by a chinese holding company.

90% of today's repair work is disassembling the entire display panel and replace individual LEDs. the other 10% is telling people their problems are due to bad wifi reception.

once that's done, replace the PSU's feedback resistor to run the new LEDs at a lower current

pro tip: as soon as you buy a TV, open it up and replace that resistor. Sure, your warranty will be voided, but you won't need it if you run the LEDs at 90% instead of 110%, like they do to stand out at a big box store under bright lights, next to everyone else doing the same.

ah i forgot another surprisingly common failure mode: cats peeing on the screen.

I've tried vibe coding for a small CRUD app at work. First it was fantastic. It generated all of the boilerplate and scaffolding. I was up and running with frontend and backend in 15 minutes.

Then things started falling apart the more you ask the LLM for improvements. It keeps failing, truncates files, edits things that it shouldn't. It even fails to gracefully handle its own API errors and leaves the job unfinished and can't recover itself after this.

Watching the endless stream of characters appearing at 300baud is a test of patience. and you HAVE to constantly look at this. otherwise it'll do unexpected things like infinitely loop and eat up all of your credits.

drive demand for highly skilled software engineers

"lol no"

the plan is to get something that's good enough to stop paying hundreds of thousands a year to highly skilled people, and just pay minimum wage to a vibe coder. Why would you need to be highly skilled to use an automated coding tool? When factories are automated, they require LESS skilled jobs because the more a machine does, the less a human needs to do.

In the past, we used binary blobs behind EULAs from "trusted partners" such as Microsoft, IBM, Oracle....

What they didn't specify was that Microsoft is A trusted partner. Not YOUR trusted partner. They're partners with 3 letter agencies, not you.