I agree, as I was one of them. Rightfully so, because PHP 20 years ago was the prime example of a complete disaster. Not just occasionally, there were long years of incompatibility, missing implementations, incoherent errors, security issues, fragmentation, etc.
Paid my share of dealing with those problems with PHP 5 and 6 (after coming from PHP 4). I think it became a more sane ecosystem around very late 7.x to 8.
I won't touch PHP ever again, but I'm glad (no irony) that they finally were able to pull it off. There were some good ideas there, then they quickly became victims of their own success.
Nowadays, there's places (Amazon) where PHP is just forbidden at a company-wide level (not joking) because of their early, long-standing reputation of being a mess. Or places where they just gave up and re-implemented their own PHP (Meta). I don't see that changing any time soon.
If you were there, you'd remember the UTF8/Unicode fiasco (how long it took, how many people was both relying and struggling with it, and how they needed to cover it up after even some hosting providers attempted a beta upgrade and had to roll it back).
There was a PHP 6 (I'm including the non-updates in PHP 5 "waiting" for it), they just had to rewrite history as of PR damage control back then. That's what the article you linked describes, pretty much.
> The major short term downside is that open source or personal projects won't be able to afford things like Codex Security.
Realistically, all open-source projects should be forced to have automated scans of this nature before their releases can be shipped. This is something the package managers and github need to figure out. It'd stop the supply chain attacks too.
So first they steal all code and launder it without attribution. Then they release a tool that doesn't find anything in hardened projects and is marketed through secrecy and modern equivalents of Netcraft like this British AI institute.
Then open source projects need a McKinsey-like stamp of approval to even be released.
Sounds like there are many parasites in this process.
You know that open source users are free to scan everything if they want to?
I don't like it either. But what alternative is there when a spaghetti graph of open-source dependencies serves as the backbone for the entire worlds software? I haven't seen or heard of any novel solutions to this problem yet.
Yeah it’s hard to write a loop that makes an adversary agent write and mask malware then runs a scanning agent and if the malware is detected gives the detection details to the adversary agent with instructions to hide it better..
As usual, the attacker only needs to get lucky once.
Well something needs to be done urgently, before hospitals and critical infrastructure start getting ransomware infected on a daily basis. This isn't an unlikely scenario either, all it will take is one well resourced attacker to spin up thousands of decensored agents and have them pumping out attacks 24/7. I'm actually kind of surprised it hasn't already happened. TeamPCP is just the beginning. We're lucky they're not using ransomware, otherwise the carnage would be 100-fold.
Then the corporations, medical system, etc needs to help support the people who make OSS software if they want the immediate, urgent change you're suggesting.
One thing I don't understand with all of these, is how they're handling different worktree infrastructure spin-up?
For example, if I have a webapp, I want each of the worktrees to spin up its own infrastructure, and be accessible on its own unique local url, so that I can see the changes locally for each worktree, or I can have agents automate visual checks using something like agent-browser.
Currently I use docker for my infrastructure, each service running in its own container. I have a script that has a ./app worktree create worktreename. That creates a worktree as "worktreename" and spins up all of my docker infrastructure with prefixes for things like "WORKTREENAME", and I can access all my urls at worktreename.myapp.test (or just myapp.test for the main worktree).
This is working fine for now, but it'd be cool if one of these apps was compatible with this concept so I could move over to that.
I have this issue at work, I asked CC to create a very simple bun CLI tool that can be hard to create, destroy and list worktrees.
The CLI seeds the .env file with a url, db for that worktree and I use Vercels open source package portless to spin up a dev server with unique ports so I get a url per worktree
Check out emdash.sh - each task spins up its own worktree with a bunch of pre-defined environment variables that are injected. This includes `EMDASH_PORT` a uniquey port for a 10 port range. Very useful for running multiple services from a single monorepo.
I ended up trying emdash.sh and superset.sh, both have this feature. I managed to get it to work in superset - for whatever reason the Setup script wouldn't work in emdash. So I'll stick with this for now.
i have shell scripts that create/tear down worktrees. the shell script finds unique unused ports across all existing worktrees and assigns in local .env upon worktree creation. when the worktree gets merged and is torn down the ports get released. secrets that are not worktree-specific i don't keep in local .env i inject via shell.
honestly creating these local scripts for automating the dev work was trivial and they combine well with all other cli tooling. thats why i havent tried any of the GUI apps yet. im not sure they're able to compete with my custom local setup that works exactly the way i want.
Just use direnv? You’ll probably need to adjust the port you are hosting the local page on, but that’s just N=mod(hash based on the worktree name) and then port=default_port+N.
Tell your claude to set this up. Should do it in a single prompt
One thing I don't understand with all of these, is how they're handling different worktree infrastructure spin-up?
For example, if I have a webapp, I want each of the worktrees to spin up its own infrastructure, and be accessible on its own unique local url, so that I can see the changes locally for each worktree, or I can have agents automate visual checks using something like agent-browser.
Currently I use docker for my infrastructure, each service running in its own container. I have a script that has a ./app worktree create worktreename. That creates a worktree as "worktreename" and spins up all of my docker infrastructure with prefixes for things like "WORKTREENAME", and I can access all my urls at worktreename.myapp.test (or just myapp.test for the main worktree).
This is working fine for now, but it'd be cool if one of these apps was compatible with this concept so I could move over to that.
"just" is doing a lot of heavy lifting here. I always automate my repo setup, usually with mise tasks, but there's often assumptions baked in, eg around which ports the app will listen on. It's also still hard to get the agents to use "mise run test" instead of invoking pytest directly. This sounds harder to deal with when you have multiple copies of the test or dev stack running together on the same machine.
They've made a hardware LLM that reaches over 14k TPS on Llama 3.1 8B, and you can try it here: https://chatjimmy.ai/
So clearly hardware LLMs are the future, and the cost will be drastically reduced. But I know that all the AI labs want to create a perception of high prices forever.
Agreed. Considering Anthropic had a sandbox bypass vulnerability in CC for a year, silently patched it, and still hasn't made a disclosure statement, no one on Earth should trust them or believe a word they say. https://www.securityweek.com/anthropic-silently-patches-clau...
They've made a hardware LLM that reaches over 14k TPS, and you can try it here: https://chatjimmy.ai/
It seems most people are not aware of this, and so I think it's important for people to realize what is coming. It also kind of feels like the industry doesn't want people to know about this, because barely anyone talks about it. If they can make these at scale, then the cost of tokens should drop dramatically for the providers. The question is if they pass those savings on.
Imagine the latest Qwen 3.7 running at 14k TPS in agentic loops... Even if the model doesn't get things right, being able to iterate that quickly on "generate code -> unit test" will be absurd.
reply