> don't see why it requires any people at all. It wouldn't even have to be done by OpenAI. Given a list of vulnerabilities
Who would put together that list unless individuals at OpenAI does it? It's not like we have machines that can think kind of like humans and do a bunch of stuff automagically.
Depending on what "generation of developers" you belong to, this could differ by decades :) Are you talking about LLMs probably? At that point, "awesome" lists were already mostly used for spam and marketing, none of the original "curated list" concept remained at this point.
I think I noticed awesome-lists changing from "Here is a curated list of AWESOME software" to "Here is a list of every software ever built, related in any way" somewhere around 2015 (thanks IM logs!), which must have been pretty shortly after the concept was introduced even, but can't remember when that was.
I recently came across some notes from a lecture I went to at Los Alamos in 2013 where the lecturer (Steven Brumby) said "it's out of fashion to call it AI now so I guess this is machine learning" .
The "actual awesome" lists were awesome, as every single software linked in those were good software.
But yeah, once "influencer developers" got a hold of the concept, misunderstood it to be an index rather than a curated list, it stopped loosing any value the concept had.
Now it's just random individuals who want to "own" a collection, but have zero care about the quality, and just merge whatever additions.
FWIW, I appreciate their contributions to the ecosystem, in the sense that you can just take whatever they're doing, multiply by -1 in each dimension, and there you have your steering vector towards good ideas.
That is genuinely useful and provides a lot of value.
I used to be the editor of a newspaper. Eventually, actually reviewing all the articles in the newspaper took too long time, so instead of shutting down the newspaper, I just started accepting every single article, eventually everyone stopped reading it.
Easier than everyone just doing nothing and jaywalking until magically a crosswalk appear? Doesn't sound like it to me, law of least effort and all that.
Harsh limit. And other api sources are like $299.00 plus a month so we have to work around what access we have. Results are noisy and have to be filtered the right way.
Someone not following KISS, might install Windows Server + tons of bloated applications, in order to serve a .asp server, which serves JSON that never changes, or something similarly stupid.
Meanwhile, the KISS developer would put static .json files on a CDN or self-hosted Varnish or whatever, and call it a day.
The first opened up a whole can of potential venues for exploitation, while the second might only have opened up one potential venue for exploitation.
If I enter a "Make pottery" monthly challenge locally, and show up with a robot that produces mugs, I'm sure it'd spawn some interesting conversation nonetheless, but I'd also expect the organizers to tell me I didn't quite get the spirit of what they're doing.
It's pretty much the same here. The purpose of these "jams" or "challenges" isn't to see if LLMs can do those things, obviously they can, we all know this already. The point is for you to personally challenge yourself, and improve yourself. That's the spirit at least.
You don't even have to migrate off GitHub if you don't want to.
Begin by refactoring the deployments so they're driven by checked in shellscripts, that accepts a git reference to deploy (prefer immutable commit SHAs over mutable branches/tags). Make it use the stuff it already has checked in, and make the actual GitHub Actions stuff as small and concise as possible, ideally each "run" should just call a shellscript with the git reference.
Then move so the deploys happen not on GitHub Actions itself, but on a "intermediate deploy host" that has the source code and access to the credentials you need, and make this host have one secure entrypoint, where someone (or something) can enter and run shellscripts, after pushing their code as a normal git push. Then switch so the deploys from GitHub Actions instead use this new host to do the deploys. Lock down this host hard.
When GitHub and/or GitHub Actions go down, the developer responsible for deploying stuff, should be able to get temporary git and ssh access to this host, can push any git data straight to the host, and their user on this host can run the deploy scripts. Keep in mind that nothing in your deployment process should depend on stuff that isn't also available on this "deploy host", if you have multiple synced repositories and so on.
Now things mostly work the same as people are used to, with the added benefit that when things go down again (like next week), you'll still be able to continue to deploy stuff.
I've done this refactor/migration for tens of companies in the last year, more or less following this exact template for all of them, with no issues reported from either of them, but lots of praise :)
Who would put together that list unless individuals at OpenAI does it? It's not like we have machines that can think kind of like humans and do a bunch of stuff automagically.
reply