HN user

g051051

1,572 karma
Posts0
Comments602
View on HN
No posts found.

Why not have the LLM go straight to LLVM IR? What would a program look like when you remove all (or most) of the layers of abstraction needed by humans? Or are LLMs too contaminated by the training data to do this? I almost wish I could try this.

When I first started, I was enamored with technology and programming and computer science. I’m over it.

Wow, that is incredibly sad to hear. I'm 40+ years in, and still love all of that.

I have an experimental project where I was asking various LLMs/tools (ChatGPT, Cursor, Google, Lovable) to implement an old game for me. They all failed spectacularly in various ways. For example, when trying to debug an issue, got into a loop making the same sets of mistakes over and over again. Or "solving" a problem by removing an implementation, or claiming something was fixed but all it did was stop checking the error. It's been disastrous.

I've had better success with LLMs as just a supercharged search engine, but only after I went through several rounds of adding instructions to prevent hallucinations and lies.

I also asked one to create a tutorial for me to follow in regards to a complicated game I'm trying to understand. It lied repeatedly, making up features and telling me to set options that just didn't exist.

My boss loves LLMs and claims it really improved his productivity, but the stuff he's talking about is JS stuff. When he (and I as well) try to use it with Java the viability of the results drops off dramatically.

As I commented in the other post, it killed mine at work, because my boss is pushing "AI" really hard on the devs. Fortunately, he's now seeing enough evidence to counteract the hype, but it's still going to be present and dragging down my work. But it my off time, I only experiment with LLMs to see if they're getting better. Spoiler alert: they aren't, at least not for the kind of things I want to do.

I'm 62, and it's had the opposite effect on me. I've never stopped loving writing code, learning new things, trying random stuff, etc. I code all day, and spend more time playing with stuff in the evenings (the main difference is I'm sipping some scotch while I do it). Having to use LLM's at work has sucked most of the joy out of my work. Fighting with them, keeping them on track, catching hallucinations before they go too far, wasted effort...it's exhausting me like nothing else in my 40+ year career.

"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should."

Pretty neat, though.

I had (probably still have) a similar-ish problem. I have an old nVidia Shield handheld that I bought a wired ethernet adapter for. Something about that adapter would kill my network dead after a random interval. It took a while to figure out what device was causing it, and unplugging the adapter would instantly cause the network to come back to life. I never figured out what the root cause was, I just stopped using the adapter.

It's unlikely that "regulators" had anything to do with it, given the quick resolution. I'd be more inclined to think that Epic went back to Apple hat-in-hand and begged to be let back in, probably promising to muzzle Sweeney.

And they should have been held accountable, were they?

Huge stock hit (since recovered, of course), top executives lost their jobs, fines, had to give away a paid product, extra oversight, cost of fixing security, several rounds of layoffs for the employees, etc.

It is not unreasonable then we should actually physically destroy their premises and all related collected information as an active threat to the nation

This is why we can't get real, meaningful change. No wonder our "leaders" think so little of us.

You told a reporter that story. The reporter, _without verifying it_, then tells his newspaper that the story you told is true and he's verified it (which is a lie). Now the newspaper publishes it. Who's responsible?

They do not publish fraudulent data. They publish data provided by the credit grantors. If the credit grantors don't do their due diligence, that's on them, not the CRA. And if credit grantors fail to due that due diligence often enough, they get kicked out.

other sources which leaked or sold it to them.

Every data source (such as a bank or credit card) provides that data to CRAs because consumers granted permission to do so when entering into a business relationship. Either that, or it's publicly available data purchased from aggregators.

Update their dependencies within two months of a critical security vulnerability being patched (Mar 10 to May 12).

They thought they did, but failed.

In the event of a breach, detect it within a reasonable timeframe (76 days is not reasonable when you're the Fort Knox of financial information).

Impossible to guarantee. A sophisticated enough attack might never be detected, regardless of the competence of the security department.

Have a reasonably well-segmented network such that a compromise in a single user-facing web app doesn't lead to your entire network being compromised.

It is impossible to so completely segment a network. If I can get the data via an authorized program, that means there's a path between networks and a hacker can potentially exploit that path.

The moment credit agencies started running their own monitoring services, it seemed like they were openly admitting that they were defaming people. I still do not understand why this is legal.

If you're signed up for credit monitoring, you get notified when your credit info gets changed, so you have a chance to react if it's an error (or fraud). How is that defamation? Why would it be illegal?

They have successfully convinced the public that identity theft is a separate and distinct crime done exclusively by one person to another rather than simply fraud that they are aiding and abetting.

This demonstrates a fundamental misunderstanding of how credit reporting works.

When "identity theft" occurs, it's important to realize that the credit reporting firms are not involved. That is solely due to failures, at the institutions that actually grant credit, to verify the identity of the person they are interacting with.

The flow goes: a fraudster uses harvested data to impersonate someone to a credit grantor, such as a credit card company. The credit grantor, accepting this identity at face value, asks the credit reporting agency (CRA) about the credit rating of the impersonated entity. The CRA says "Joe Victim has a relatively low risk of fraud". So the identity theft has already occurred before the CRA is even consulted.

Later on, when the fraudster fails to pay as agreed, the credit grantor incorrectly reports to the CRA that the fraud was caused by Joe Victim. Again, the CRA is just relying on the data provided to them by their clients.

I went round and round with AMD support between December 2022 and April 2023, explaining exactly where the issue was, sending the event logs showing the driver was being blocked because of the signature, sent screenshots of the certificates showing the expired dates, etc. I kept getting sent to random articles, told to do useless steps, the usual stuff you get from "technical" "support" nowadays. Eventually they acknowledged the problem, and said that it would be fixed in an upcoming update:

I've now looked into this and we are already aware of this issue and have an engineering ticket logged against it.

It is only affecting the older Ryzen and Threadripper parts and it occurred since Ryzen Master Tool (RMT) received a significant update to improve the look and feel of the application.

We do have a fix planned that will be incorporated into a future release build of Ryzen Master Tool, however I don't have a specific date of when that build will become public for you to download.

The initial estimate is mid July, however this could change. My recommendation is to periodically check our website for the Ryzen Master Tool release notes as the issue will be documented as a fixed issue when the build becomes publicly available.

I check regularly, and I haven't seen a new version released that mentioned this. Plus, never versions don't work with the VBS bypass hack I was using.

And here's the email that finally got them to even admit it was a problem:

Again, I'm frustrated. I've clearly explained over and over that the VBS setting doesn't affect this problem. So having you come back and say "this is expected behavior" is infuriating. You insisted I send my system info, which clearly showed VBS is off.

I say again: even with VBS disabled, the driver won't load unless you ALSO disable the driver blocklist. And once again, forcing users to bypass important security features is borderline negligence, when this could easily be solved by getting the driver signed correctly.

The true culprit is the expired/revoked signature on the driver. You can see this in the event log (as I included in my last message) showing the driver being rejected from loading into Windows because of the failed signature. The purpose of the VBS check is clearly because this used to cause the driver blocklist to be enabled, so disabling VBS also disabled the driver blocklist. THIS IS NO LONGER TRUE. Recent Windows updates have made the blocklist enabled by default, so that the only way to run Ryzen Master on affected systems is to disable both VBS (to get through the check) and disable the driver blocklist (to allow the driver to load).

Fun fact: Ryzen Master needs a kernel driver installed in order to function. This driver was signed with a cert that expired a while back. For years they required you to disable virtualization based security (because as a side effect it would also disable driver signature enforcement). When this first popped up, rather the fix the signature, they added a check to detect VBS and block starting if it's enabled. Then Microsoft made VBS and DSE separate settings, so now it gives a misleading error message. There was a patcher program that would workaround the issue, but it doesn't work for the most recent versions, unfortunately.

Is agile still appropriate today?

It was never appropriate. It was created by consultants to sell consulting services. In that way, it's a huge success. As a practical development methodology, it's always been a disaster.

The last two organizations I worked for had full QA teams with people who wrote the tests, not just test plans. The devs sometimes provided features to facilitate it, but the QA teams were the ones that constructed the tests, ran them, and decided if the software was ready to be released. Some things had manual tests, but a large percentage was fully automated.

Really? Then show me a video that doesn't look like what I described, if you want to be taken seriously. That demo is, what, 5 clicks with a decent gui builder?

The initial vulnerability was in the "modern" web application that fronted the legacy mainframe application. It was completely patchable, but was missed as described in the article.