Progress. Oh, dear lord. Progress...

Apparently it's now called OpenEdge.

I'd say the execs are trying to find a way to deal with Kotick.

You mentioned logging serialized objects. In Java, that's pretty much putting binary - well, java bytecode - directly into the log since Java has ways to save/load serialized classes.

That's actually what caused a massive security flaw in Apache Struts years ago as people were serializing a Java class and then including it in the headers of HTTP requests. Which meant the server would run the class before checking the user permissions.

I doubt it took much time at all. JNDI already existed to handle the remote fetch and execute. Log4j just used JNDI.

As for why they did that. I'm going on a hypothetical here. Assume someone has 100 servers and they want to send an email when something happens. So they code up a e-mailer class that would now have to be pushed out to all 100 servers on every patch.

How about instead of updating all 100 servers, we have the servers pull down the e-mailer when that thing happens. That way we don't have to patch all 100 servers every time, they will all pull the update automatically. Marvelous! Time saved! Scheduling update windows no longer needed!

Corporate environments already use internet proxies. Creating a thin-client/proxy combination - which is exactly what this sounds like - isn't a terrible idea. Assuming that the corporation can own the server and only serve clients inside their network.

Anyone expecting to use this from home is mad.

Seriously? Compiling is translating the higher level language down to the byte-code. Assembler is mnemonics for the byte-code instructions.

You can't simply "change it's back end" without knowing the assembler for the target architecture.

Every compiler uses assembly. Every interpreter uses assembly.

The issue is when something goes wrong. I've seen plenty of mirrors with scratches and cracks that work fine. Scratch or bang that tiny camera lens and you lose the rear-view.

High-tech solutions just don't have safe fall-backs.

When Linux can run all of my games, I'll switch.

Until then, I'm stuck.

Damnit. I logged in to upvote this and it's already maxed.

A terminal is not an OS level function. And even if it were, the window containing the terminal (assuming GUI) is not.

The console - no GUI - should remain available but I haven't tried it in a while.

It is about performance or how the user will perceive the performance.

The apps that are active can allocate more RAM and be more responsive since they don't have to wait for the sleeping app to be swapped out. The user sees that as better performance.

And there's a major part of my problem with IoT. There's a backdoor waiting to be exploited.

As long as everyone keeps doing it in their own way, Linux will never supplant Windows.

Let's think about cars for a minute. If you move from a Honda to a Chevy, will you be able to drive it? Or would you have to learn a new interface before starting the engine?

Every time this comes up, I have to point to Eric Raymond's Luxury of Ignorance article. It's the perfect example of why Linux will never take over the desktop. And it was written 12 years ago. We still haven't learned.

Right. But to bring this back to the original line of thought, would you expect Joe User to be able to do this? Do you want Joe User poking around with kernel compiling?

The problem is that the people who are developing the code don't understand how stupid Jow User can be. But here's the thing, Joe User is right.

Do you drive a car? Could you change the oil? Change a tire? Change a headlight? Change the brake pads?

Should you have to know how in order to drive a car?

Then why the fuck do we keep expecting Joe User to understand how to update the kernel and rebuild the necessary drivers?

Nobody wants to admit they still use it. It's sliding into COBOL territory...