Posts by Michael Wojcik

Re: Programming is independent from language

I also think it would be relatively easy to make a COBOL to JVM compiler

Writing a COBOL-to-anything compiler is hard. Even if you just stick with a single dialect – say COBOL'2002 (ISO/IEC 1989-2002) without the OO support or optional features – it's a tough language to parse (it's not LL(1)). And a single dialect won't get you far, since non-trivial applications often combine "programs" (what would be object modules in other languages) compiled from sources in a variety of dialects. Then you have to make various implementation decisions because the standard leaves critical aspects up to the implementation.

Once you have a working COBOL compiler, targeting JVM bytecode as a backend is certainly possible. We do it. But it's mostly useful for integrating with other JVM languages, using JVM frameworks, or writing OO COBOL. It doesn't help much with migrating COBOL applications from the mainframe because it's the mainframe environment which really matters to those applications.

Re: Meh

Micro Focus Visual COBOL (the current descendant of the original MF COBOL line, and the flagship COBOL product), now owned by OpenText, still compiles initially to an intermediate representation. That can be interpreted at runtime, or converted to native code (in various object formats), .NET CL, or JVM bytecode. Such "generated" code isn't interpreted at runtime, if it's native (and it's JITted if it's CL or bytecode).

The runtime is typically dynamically loaded, not statically linked.

As an aside, you can decompile COBOL-sourced CL into, say, C# or VB.NET, and it's not awful. It will have a bunch of COBOLisms, but it's readable. If you use the Managed OO COBOL language variant you can actually write OO COBOL for CL that looks very reasonable when decompiled into another .NET language. But traditional procedural COBOL using the idioms of COBOL'74 or COBOL'85, plus the various extensions that vendors loved to toss in, can be very messy when converted to another language.

Re: Curious choice

"COBOL", with two O's.

While the quality of the generated Java source is definitely one area of difficulty, the bigger issues are likely portfolio analysis – we often encounter customers who aren't sure which of their tens of thousands of COBOL programs are actually run in production, or what sources they're built from, reliance on odd aspects of IBM COBOL behavior, and (for the promise of eventual migration away from the mainframe) dependencies on zOS features and subsystems.

People have been selling COBOL-to-Java conversion tools and services for decades. It's rarely gone well, and source language conversion isn't most of the work. So throwing an LLM at that part, even if it doesn't create a dog's breakfast (and I wouldn't count on that), is only optimizing a fraction of the problem.

Re: Skip the Java - go straight to Rust (or whatever the new flavor is today)

Java is thoroughly integrated into the IBM z environment and subsystems such as CICS and IMS. Python and Rust are not, and migrating COBOL mainframe applications to them would be a miserable experience.

For these sorts of applications, the programming language is much less important than integration with the zOS environment.

It's all going to end in tears anyway, for applications of significant complexity. Many of these applications have decades of stovepiped changes to business logic and integration with other applications. They typically have very few tests, accurate specifications, or documentation available. The business processes are defined by what the existing programs do, and nothing else. The first stage of any such migration is application portfolio analysis, even just to identify which programs are actually being run and what sources they probably were built from, and that's a major undertaking in itself. Converting to another language without introducing changes in behavior is very difficult.

And that's not even touching on the vagaries of IBM mainframe COBOL, such as its nested-PERFORM behavior (hint: it's not a stack); or the differences among various IBM COBOL product releases.

Disclaimer: I make wads of filthy lucre from a competing product, so of course I would say that, wouldn't I?

I call bullshit on the "center divider" algorithm anyway. I frequently drive on highways that have mostly have center dividers, with occasional breaks for cross traffic. What is Autopilot going to do – stop working every 10 miles or so when it spots one of those breaks? (Assuming it spots it at all.) It's not a feasible approach.

The whole thing is rubbish.

Re: Risk tolerance

I hate adaptive cruise control. As far as I'm concerned, the whole point of cruise control is that it helps me maintain a constant speed in situations where that's feasible (uncrowded highways). That makes my driving more predictable, which is useful to other drivers. With adaptive cruise control, I'll end up passing a line of people whose cars have slowed down because of one slow vehicle in front, and then they all realize they've slowed, move into another lane, and often end up passing me – just for the whole process to repeat a few miles down the road. It's annoying and increases the probability of an accident.

Re: Epyc fail there

That's possible, of course, but these microarchitectural side channels are really easy to introduce accidentally (they amount to failing to clean everything up), and because there are so many of them they're difficult to find comprehensively. Zenbleed was found by microarchitectural fuzzing (dunno about Inception, as I haven't gotten to the paper yet), which is a stochastic process, not exhaustive. CPU manufacturers have limited resources just like everyone else, and their testing focus will be on getting the correct documented behavior from the chips.

Re: Not quite right

I've had US health care my entire life, under various types of plans – "conventional" (which isn't anymore, and hasn't been for a while), HMO, PPO ... – and none of them have worked the way you describe. With HMOs it is often required to get a referral for out-of-network non-emergency care. All the PPOs I've had have approved payment after treatment, not before; there hasn't been any pre-approvement process.

Re: Millions of Parsecs

[b] bend space and step instantly between origin and destination, [c] use FTL propulsion

Any way of sending any signal faster than C breaks causality. Personally, I'm hoping to keep causality intact; I think that's a much better option than FTL travel.

Re: Really need to fast track a NIST style open radio design competition

Oh, what a load of rubbish.

For one thing, RSA is not an "algorithm[] for streaming data". It's an asymmetric cipher.

DES is certainly too weak (the key's too small, and it's vulnerable to linear cryptanalysis) for modern security, but we had 3DES since 1981, and in a streaming mode (CFB, OFB, and CTR were all documented well before 1994) it's a stream cipher with no published cryptanalysis requiring less than ~2⁸⁴ encryptions if you rotate keys on a reasonable basis (i.e. before 2³² blocks, to prevent Sweet32 attacks).

For TETRA purposes, where attackers have few routes to drive a large number of known-plaintext encryptions, even RC4 would likely be fine.

TEA1 is just a bad, deliberately-broken cipher.

Re: Dumb Questions

Those are good questions.

Not particularly, since they're answered by Ormandy's article. I don't understand why people take the time to post questions but not to check to the primary source.

When vzeroupper is speculatively executed, and then that branch is discarded, the zero-upper bit for that YMM register is cleared. That should restore the previous upper 128 bits of the register; but in some cases that portion of the register file has already been reused by some other thread (because the zero-upper bit was set during spec-ex and the Zen 2 RTT incorrectly considers that committed), and in that case the upper 128 bits that were "restored" to the thread that performed vzeroupper will be the data stored by the other thread.

Re: Parsing the data

how do you make sense of whatever happens to be in the registers when you get the chance to read them?

You do realize there has been a tremendous amount of published research on this, right? That we've had unauthorized-read vulnerabilities for decades, and people have been turning them into exploits for nearly as long?

Tools for extracting useful secrets from corpora of exfiltrated data are widely available. They use pattern-matching and various heuristics.

There are examples of this for Zenbleed specifically in Ormandy's article. This information is not hard to find.

Re: Parsing the data

So how many string operations are likely to be processed as vector operations?

A great many of them. Read Ormandy's article. See his proof-of-concept exploit.

Re: Parsing the data

UTF-8 or sometimes ISO8859 are the order of the day, and just counting along an array of bytes until you get to a zero byte is no longer enough to work out the character length of a string.

It is certainly enough to get the byte length of the string, which is what strlen is mostly used for. There are a vast number of strlen calls taking place in modern OSes. And, in fact, on EBCDIC OSes too, since code point 00 is NUL in EBCDIC as well as in ASCII, and C is quite often used on the remaining EBCDIC systems (z, i, etc).

Re: Also, I just noticed...

As Ormandy points out, there's a lot of code that uses the YMM registers, and a lot of code that uses vzeroupper. glibc's strlen is the example he walks through. Writing Javascript that causes the browser to call strlen should not be difficult. Expanding that into a full exploit might be, though.

As researchers such as Daniel Gruss have shown repeatedly, microarchitectural vulnerabilities often are exploitable in unexpected ways. Assuming this can't be exploited in Javascript would be a large leap of faith.

Re: "But then, you get to, like, 10 million training examples, it becomes incredible"

The aim of getting autonomous vehicles to outperform humans is a low bar.

Yes, but it's still not an easy problem, because of the really, really, really long tail – the vast array of improbable cases.

How many cases of "driving at highway speed and a significant part falls off the vehicle in front" are in Tesla's corpus? That's happened to me a couple of times. How many of "a significant part just fell off this vehicle"? I towed a Jeep once that had a wheel come off after the axle sheared, due to a manufacturing defect. How many of "driving down the highway and there's a vehicle on its side in the passing lane, facing back down the highway"? That's happened to me three times, once at night in a heavy snowstorm. How many of "oil slick on a hill on a curving country road" – I had that once. How many of "some random dude trying to direct traffic around a truck that's double-parked on a city street"?

Have Teslas FSD'd over Hardknott Pass, or other roads with sufficient grade that you can't see the road surface in front of you? I've done a few of those. (Actually I don't know where Tesla camera mounts are; maybe this isn't an issue.)

Humans are rubbish at maintaining vigilance, but surprisingly adaptable to novel situations.

Re: "But then, you get to, like, 10 million training examples, it becomes incredible"

Training on "good drivers" is a fool's errand. They almost never get into trouble, so the AI isn't going to learn anything from them.

I am not a fan of autonomous vehicles, and particularly not of Tesla and Musk; but I don't think this argument is valid. The system isn't, for the most part, learning from drivers. It's learning about driving situations and about probable effects from causes – or more precisely, what the distribution of an event is given the previous window of N events. (Note "event" is defined broadly here, as "a snapshot of input from the sensors". So it will include situational information such as weather.)

When you've trained a system with a large corpus of such events, then you can impose a set of rules on top, telling it how to weigh outcomes.

What the drivers do matters only insofar as their control inputs also constitute events.

In other words, in this sort of training exercise, the system isn't learning how to drive; it's learning what driving is, as a large collection of probability distributions with a time series of inputs as priors.

Re: Extension of the Existing Situation

Why do you think your process of generating a work in the style of another artist is equivalent to a large transformer model doing so, in fact or under the law? That's a rather glaring assumption.

Re: I did something similar

Indeed.

Back when I still regularly read Usenet – which I started on in 1990 (I know, I was late to the party), though I'd used various BBSes and the like before that – there certainly were people whose names I'd learn to recognize. There were some who were famous in that context, like Kibo; there were some whose names I recognized from meatspace, or whose outside activities I'd become aware of over time. There were even a few I eventually met in person, and in a few cases some I formed close relationships with.

Aside from that last group, I'm not sure I'd claim I "connected" with any of them in any significant way. I was interested in what they had to say, perhaps. I learned from them, and perhaps taught some. But the same is true of the thousands of fiction authors whose work I've read, as part of my literature studies or on my own, and I wouldn't claim any connection with them.

How many of these social-media connections have any life outside a few posts? Any actual emotional or intellectual relationship?

Pesce started his piece by suggesting that having a lot of social-media input is (or so he thought at the time) a good way to learn. Well, there are already plenty of excellent ways to learn – far, far more than any of us could possibly explore in our lifetime. I've yet to see any evidence that social media offers anything of substance not to be had elsewhere.

Re: ChatGPT getting dumber at programming

Real greybeards wrote their own much smaller, more elegant, more efficient, and more capable rubbish-code generators decades ago. Copilot et al. are just really expensive reinvented wheels.

You know, I don't think I'm joking about that.

Re: ChatGPT getting dumber at programming

I don't know what you (and five upvoters) have been reading, but it's discussed plenty in the literature already, considering how young this field is.

See for example Will GTP Models Choke On Their Own Exhaust?, a post from Ross Anderson, which links to a paper from his group on arXiv investigating this issue. It's also been raised (in a technically sophisticated fashion) in places like LW posts, so it's not just researchers in their day jobs looking at the problem.

The lay press and J Random Tweeter may not be flagging the issue, but actual, like, researchers are hardly keeping silent about it. Which is hardly surprising since the problem is prima facie evident in the training strategy.

Re: Okay, not going to knock it

I can imagine school children on trips using their imagination, and not needing to have every goddamn thing handed to them on a platter.

Undistinguished vice president analysts? Sure. I mean, can you tell them apart?

Re: WiFi -gap

In fact it doesn't even need air. You can vacuum-gap it. Those crazy electromagnetic fields just don't care.