I'm just describing what an actual career looks like beyond the first 5 years of grinding away at a startup and then giving into "the man" or whatever.
I guess it's true that corporate doesn't like hiring junior devs, but I'm not sure it was ever any other way. I'm not seeing where the fire is at. Corporate won't pay you SV wages either, but it's still respectable six-figures. You probably don't get stock either, but everyone gets a management bonus unless they're contractors. This is just basic middle america and it's the vast majority of the workforce.
I'm not trying to piss anyone off when I say this, but all the scifi doomer shit is wildly out of touch and preys on the inexperienced. You should question who is behind it.
fwiw, I was challenging you because your assumptions are not at all what I see around in teams across companies I work with. so was taking the other side and trying to probe further.
Unless we're talking 0-day/CVE, running an unprivileged container is as trustable as a VM. The only difference is how strictly you want to hold the memory/CPU bar. Infact on linux, containers are more lightweight than VMs.
LLMs are great at finding 0-day, and people are rubbish at updating their containers and hosts to patch b-day.
Containers have access to the kernel ABI, and as shown in the latest kernel exploits, all the memory handling surface that exposes. The virtualisation interface, offering fewer services, is significantly harder.
Containers are obviously lighter than VMs, both to start and to schedule, but firecracker is pretty fast. gVisor pays overhead per syscall vs at startup.
Got it. 0 days are possible so throwaway containerization. You should blog about it, will help millions of developers and companies. Heck, even consult with the hyperscalers - they will be riddled with their workloads.
get a few personal gmail accounts's gemini API key, and you have 1000s of free LLM calls to flash-lite models, which are more than upto this task. one time run, and save it to your db.
Author here. At least for databases, AGPL (or stricter) has become standard. The issue is it's so easy for megacorps (Amazon, Google, etc) to take a permissively licensed product and monetize it at the expense of the original standard.
For instance, Mongo, Cockroach, and Materialize have all gone source available. We picked AGPL because it's the best balance between open source and prevents Amazon from just repackaging it and selling it.
If AGPL is an issue for anyone, we would be happy to dual-license under a commercial license.
There is nothing wrong with wanting to be compensated for your work, but for people like myself which use a cloud managed DB solution (GCP CloudSQL PostgreSQL) it means something like this would never be available.
I consider AGPL a poison pill in my work. That is not true with a suitable commercial license, although I expect a lot more commercial product (support/features/etc). As you note, your objective is to prevent commercialization of your software, but radically speeding up analytics is primarily a concern of large organizations so it seems like a mismatch in purpose.
The whole point is to force the cloud providers to go through a contract negotiation for licensing rather than keep the door open for them. Nothing prevents the parent project from specially licensing to individual parties.
The issue is that AGPL is flatly banned at many companies, so now any company that even wants to test this database out is going to have to seek a contract, which they won't.
Most of the same incentives of typical OSS contribution? It's not like other OSS projects pay out any earnings made with the product evenly across contributors.
Also, from the trajectory of the project it doesn't look like they are significantly deoendent on outside code contributions.
Sure, that's your prerogative, and kudos for not talking up open source. I'm not amazon size so can't use it, and AGPL is a no go for DB, don't want to be forced to open source my app because I use this!
Why would AGPL force you to open source your app? Unless you literally compile your app with pgrust by modifying the pgrust source code, you're safe. Clients aren't bound by the AGPL because they aren't derived works.
AGPL is untested in courts. There is no definitive definition of what could be considered within the blast radius such that it would require AGPL licensing.
There's a reason AGPL is banned at Google and most sane companies. It's simply too dangerous.
You can't simply say "clients aren't bound" because it depends.
I'd rather see the BSL used here to be perfectly honest. At least it's simple.
While the AGPL is untested, what a derived work is is less so. It is entirely outside the bounds of the intentions of the authors of the AGPL for clients to be infected.
Oh bummer. I was really excited about pgrust but AGPL is a dealbreaker. Not for me personally, but it will never see wide adoption because it’s a banned license in most corporate environments. Lack of path to wide adoption means it’s dead in the water.
It’s weird because those who actually care about optimized pg gains are most likely large corporate customers. Why make a product targeting them and license it in such a way they’ll never use it?
This also hard blocks upstreaming any beneficial features into core Postgres.
> It’s weird because those who actually care about optimized pg gains are most likely large corporate customers. Why make a product targeting them and license it in such a way they’ll never use it?
Wait, sorry, you're asking why make something enterprise customers might pay for, and then not give it away to them for free?
One path for developers who don't want to make a charitable donation to their friendly Fortune 500 is to pick a free software license unpalatable to corporate lawyers and then charge corpos for a commercial dual-license.
You are free to volunteer your time to Amazon, no one is stopping you. They would probably accept cash donations as well.
I feel like you're just restating the premise, which I'm explaining won't work or at least will see significant challenges. Companies won't touch your software, whether you support a corporate license or not, and you have no way to enter the company because of that license.
It's not insurmountable. Lots of companies have been built on AGPL or adjacent licenses. It's just a meaningful hurdle. People can do whatever they want, your framing of "oh just give your money to corporations" is ridiculous as I'm not advocating for anyting like that.
You're advocating for a corporate-friendly zero-money license. I don't know what you want to call that other than "giving away your work to help sponsor enterprise software"
AGPL seems like the right choice to me. I’m tired of companies like PlanetScale taking PostgreSQL, building a business on top of it, and then acting like PostgreSQL is theirs to control.
Its 300x faster for certain tests. I could pretty easily craft tests that do this on two different systems. The author mentioned this when they talked about being able to fit an entire ResultSet into memory. That's the real trick with performance. Very few workloads are CPU bound anymore (linear algebra on the CPU for example). Almost all workloads are memory bound. So its all about moving data from memory to network, back to memory and back to network, over and over again through your microservices or DBs. If the entire working set can fit in memory, you get at least a 10x performance boost. If you have to keep even a part of the working set on disk, its a huge performance loss. And the larger fraction of the working set on disk, the worse the performance loss.
PS Learn how DBs do joins for more information. Specifically the differences between hash joins, merge joins and nested loop joins. They are basically fancy ways to page part of your working set to disk at huge performance penalties.
PPS As memory gets more expensive, these techniques get more valuable. When it gets cheap, they lose value.
License policies are made by lawyers not by programmers. And their competition will be in the exact same boat (different lawyers though). AGPL is so toxic that it tends to be checked for during M&A processes so even if the current batch of lawyers is ok with it there is a chance that a later batch of lawyers is not. Given that the target audience for this project is the larger companies you are going to end up with a very nice project and zero actual users or you will end up with AWS et all stealing your work. Databases are very hard to do successfully commercially, at a minimum you should dual license them (AGPL for 'home' use and commercial licensing for parties that will want to buy the upside but they'll demand support and other stuff besides).
This is the case when you have your own datacenter. This isn't as big a problem in the cloud. There are ways to write licenses that prevent cloud providers from stealing while allowing customers to use the software and being required to pay for it. The problem with the AGPL has to with its viral nature, not its provisions to prevent cloud vendor theft.
A project can probably use the EUPL instead of the AGPL (EUPL is to AGPL, as MPLv2[0] is to GPL). Basically, EUPL is file-based, not project based, and so it is not aggressively viral. You can use the EUPL code any way you want, as long as you make the original code available, plus any modification to the original files.
[0]: With Exhibit B, which prevents relicensing to GPL. It is also analogous to CDDL.
This is the difference. This guy took an existing source base, had Claude find specific bugs, then had Claude fix a specific bug which was then reviewed by a person. We also don't know if these changes introduce new problems yet. You are suggesting letting Claude write an entirely new source base. That's light-years away from what happened here.
What? This project is literally an LLM port of Postgres from C to Rust. The name "pgrust" is a hint, if somewhat subtle.
There is also zero evidence a human has reviewed a meaningful amount of the code generated for the port, let alone the original C code from Postgres, given the size/scale of the project and the how quickly it was produced.
No. This is system code. You let an LLM loose on it, it probably fixed 20 bugs and introduces 200 more plus 5 different performance regressions. In all fairness, your average app programmer would have the same problems. That's why it takes so long to learn to be a system programmer and why it takes so long to do anything on a systems source base. For reference, systems are OSes, DBs and compilers (although compilers are very different in many ways).
Also, you can successfully sell a systems project that is only 10% faster. 30000x faster and they are throwing illegal and debauched things through your window to get access to your improvements.
You're screaming into the wind. LLMs are coming for "system code" along with everything else. It no longer takes time to learn to be a systems programmer, or time to do things on a systems codebase. You can complain about the bugs the bots introduce but no one will care, least of all the bosses who are sick of paying for slow, expensive system programmers.
The brittleness and difficult of writing the code. The extra complexity. The cost of bugs. And ease of creating performance degradations. If you are even asking that question, you probably don't have the experience to even have an opinion on this.
Most systems code has to be "canonical". That means it can't be improved. Imagine the most difficult PR review you have ever had. Now give the reviewers OCD and an extra 30 IQ points. And every single code change has to live up to this standard. That's what it has to do with this.
> The brittleness and difficult of writing the code. The extra complexity. The cost of bugs. And ease of creating performance degradations. If you are even asking that question, you probably don't have the experience to even have an opinion on this.
You didn't express anything unique to systems engineering.
So, keyword 'rational', I'm not sure any sufficiently large company is a rational actor.
Yes, at [tech corp dayjob], any dependency is likely to be banned for arbitrary reasons if you bring it to the attention of the wrong people. It doesn't have to go against any of our policies e.g. don't mention anything with GPL in the name around the "risk" people. In fact, do not ever talk to the "risk" people and hope they don't talk to you.
Latest news: Apparently, devtools are a legal risk. Basic reverse-engineering of client-side JS is now banned.
The delusions really seem to scale with headcount.
Good news, we now know up front what an independent port would cost, and it’s not much. So no reason AWS, Google, and friends couldn’t bang out their own port if they want, binary-compatible with this one.
What we don’t know for sure is whether there is any copyright for LLM-generated code. The license might be irrelevant!
Most official Rust projects are dual MIT/Apache licensed by convention [1] (and most Rust libraries from third parties I've seen that are open source MIT follow the MIT/Apache dual license), so seems like this library shouldn't just be AGPL for a typical political choice of a Rustacean?
Someone who likes Shakespeare is going to be able to talk about what they like about Shakespeare, his impact on language, his works, and so on.
Someone who likes Austen is going to be able to talk about the themes of the books, how funny Pride and Prejudice is, maybe how Jane Austen's position in society informed her works, etc.
How is anyone going to be able to do the same for an AI generated book? "Reading book 894 from batch 60 of the Booktron V2.46.01 collection was formitive for me, it was very reminiscent of the early works from the Automatic Grammatizator." Is this really a discussion we expect will be had in schools, or in any art discussion? Absolutely not.
This would have been a much better comment as is, originally, instead. I disagree with your thesis, but at least it would have been worth engaging with.
Which is all of our industry. You're lucky if you're in a pocket outside of timr crunch.