I put a chapter of a paper I wrote in 2016 into GPTZero and got the probability breakdown 90% AI, 10% human. I am 100% human, and I wrote it myself, so I guess I'm lucky that I didn't hand it in this year, or I could have gotten accused of cheating?
That's more an indictment of the accuracy of such tools. Writing in a very 'standard' style like found in papers is going to match well with the LLM predictions, regardless of origin.
I met a dev who's mom had been working on legacy banking systems her whole career. She had started in the eighties and she still did some urgent jobs at a crazy rate despite officially having retired.
My stepmom who retired five years ago, did COBOL dev as part of her banking job until 2002ish and then she was full-time management track. In her bank, most of the work had been integrated with Java, and the Java was done by outsourced Indian teams. At the time she retired she felt the Indian teams had been failing for years to meet objectives, and finally management was seeing it. Additionally everybody who knew the COBOL side of things was retiring at the same time as she was and she did not want to know what the system would look like in five years.
My mother used to teach Cobol back in the 80’s in Brazil but later she transitioned into management and haven’t touched a line of code for more than 30 years, she can’t even speak english wtf
I would have flagged that they're logging their Redis URL, if I was reviewing this. Most of the time this includes credentials.
Normally I think it's a bit rude to criticize the code of blog posts, bit I thought it was relevant here for these reasons:
"I often don’t even remove when I’m done debugging because they’re now valuable in prod" - think about where your production credentials end up. Most of the time, logging them won't hurt, just like keeping your password on a post-it doesn't hurt most of the time.
The arguments about letting an AI reduce the mental overhead is compelling, but this shows one of the (often mentioned) risks: you didn't write it so you didn't consider the implications.
Or maybe the author did consider it, and has a lot of good arguments for why logging it is perfectly safe. I often get pushback from other devs about stuff like this, for example:
- We're the only ones with access to the logs (still, no reason to store credentials in the logs)
- The Redis URL only has an IP, no credentials. (will we remember to update this log line when the settings.redis_url changes?)
- We only log warnings or higher in production (same argument as above)
Maybe I should stop worrying and learn to love AI? Human devs do the same thing, after all?
Virtualization really helps. We have a lot of weird software which requires hardware dongles, but they're all USB dongles and they're all virtualized, one of the DC racks has a few U worth of just USB socket -> dongle wired up so that if we spin up a VM it can say "Hey, give me a USB socket with a FooCorp OmniBloat dongle on it" and get one unless they're all used.
Interoperability exception might allow this in exigent circumstances when you do have a valid license, but I wouldn’t do this without running it by the software vendor whose license you are using. In a recovery situation, you’ll probably need to be on the phone a lot, so I can see how you might think it’s quicker to bypass the license check, but that is one person giving some or all of their attention just to that. Disaster recovery isn’t a one person job unless that one person was the whole team anyway, so I think this idea needs to be calibrated somewhat to expectations.
it really depends on the scenario but if the application was dockerized and they had an image, it would be just starting it again, somewhere else.
Possibly with the same network settings if the licensing check was based on that.
But of course it can easily go south, though testing the recovery of a container based off an image and mounted volume is simple and quickly shows you if it works or not.
But of course it may work today but not tomorrow because the software was not ready for Y2K and according to it we are in the XX century or something and the license is 156 years ... young. Cannot allow this nonsense to proceed, call us at <defunct number>
"hardware" does not mean "bare metal". It could be a MAC, a serial number or similar things that may be linked to a generic or clonable value in virtualization.
To some extent, yes -- having developed apps that were dockerized, and having managed virtualization systems (ESXi and similar), as well as docker engines.
Yeah, I think the author was referring to community posts. The linked FAQ article says this:
"Your personal information is removed, but some content you’ve posted in community areas is not. This includes things like discussion posts, or content that you posted in Steam community hubs, as well as comments you made on other Steam account’s profiles."
It's solid wood, so it'll probably last another 40 years at least.
reply