I seem to remember the ML guys went down this route. I believe they called it regions.
From what little I read in the literature I seem to recall that there were enough programs with quite a bit more memory usage that they decided this approach was a dead end.
Yes, ML Kit region inference is probably the closest prior art to Goose.
Back then though, they couldn't lean on large 64-bit address spaces like Goose can. They implemented all of this with a chain of blocks of memory instead, and tracked most of it at runtime that Goose now does at compile time.
At some point I emailed Linus to ask for his advice but he never replied. That was a personal initiative though, not on behalf of Docker.
I did speak to Greg several times.
I think over the years there was natural overlap, people who contributed to Docker would also be kernel contributors. Especially when we spun out runc, containerd, which created a more vendor-neutral space for maintainers to focus on the bottom of the userland stack with minimum drama.
To the extent that Red Hat employees overlap with kernel folks, that made it more difficult to collaborate since Red Hat was overtly aggressive towards Docker, and generally made our engineers feel unwelcome on "Red Hat turf". I discovered that they had devolved into a toxic company with a facade of benevolence. This made me sad because Red Hat was an inspiration to me. One of those "don't meet your heroes" situations.
Since 2006 first as part of the Ottawa Linux Symposium and later as part of the Linux Plumbers Conference we had yearly in person meetings.
We had public discussions on the Linux Kernel mailing list and later on the containers list.
It was a collaborative effort from vserver, openvz, IBM, and Linux Networx, and google. I think those were all the original groups, my apologies if I have forgotten someone.
After Docker made a splash I occasionally asked other developers if they had any contacts at Docker. To the best of my knowledge we never received a bug report, or a feature request. No one from Docker ever showed up at any of our meetings.
I know at one point I wanted to let someone know that Docker they were holding the pieces wrong when it came to security.
Eventually I think one of the OpenVZ guys wound up working for Docker for a time. But that was quite late in the timeline.
I was passing through RedHat about the time of the spat you mention. My impression at the time was that Docker never worked well with anyone, and after some frustrations trying to cooperate the RedHat userspace folks decided it was easier to get a real standard without Docker.
At that point I had gotten the unprivileged user namespace support into RedHat's kernel and changed a lot of minds about it's utility.
I don't remember Docker ever picking up unprivileged user namespace support and as a result was a security disaster waiting to happen.
It felt to me like Docker treated the userspace API for containers like most folks treat the POSIX API. Fixed in stone. In fact there was a lot of wiggle room, and opportunity to shape things for anyone who was willing to dive deep into the technical details.
Red Hat was frustrated with us because they were used to calling the shots. They couldn't fathom that we would refuse a pull request from them. Well guess what, every project is entitled to saying no. And Red Hat's contributions were just overall not good, or they didn't bother to consult with the maintainers on our design principles - like independence from the underlying OS distro.
You're reminding me why working with that company was such a pain. Always with the fucking superiority complex and passive aggressive drama.
As for a "security disaster waiting to happen". My view was, and remains, that the only isolation you can trust is the hypervisor. Kernel level isolation is not strong enough, and unprivileged user namespaces never actually mattered in cloud architectures. Your work on that feature was just security theater and ultimately useless, so spare me the lecture.
I do think Docker embraced user namespaces after my time but I couldn't care less.
What I remember hearing is that exercises and practice are needed to transform words on the page to something you know and master.
What I remember being questioned is does it make sense to do those exercises as homework or would they be better in school.
Or on the flip side should school get out early like 11 or noon, like I think the german gymnasium does and have all the exercises as homework.
The US system where children get out of school at 15:30 and still have a bunch of homework seems a little lopsided someplace.
The 3 month break in-between school years is definitely questionable.
I think the answer is a complex one because it intersects with personality and neurodivergence.
Depending on who you are and your family situation any form of homework can be a real challenge. Not because of what you are studying but because of how difficult it is to sit down and do anything you aren't passionate about. Certainly anyone with an executive function disability will have that challenge.
Part of the problem is AI datacenters make bad neighbors.
Because they are in such a rush to become operational they cut corners.
Instead of AC they use swamp coolers draining aquifers and thus wells of the neighbors.
Instead of using new power plants (AKA using renewables as most new plants do, and all old datacenters did). They either hook up to the grid and jack up everyones electric prices or use generators because they can't be bothered to wait for a grid connection.
All of which is to say while on the grand scale they may be fine. Locally they can be unpleasant to have in your back yard.
If the LLM datacenter builders and operators weren't cutting corners and rushing and doing everything they can to be good neighbors. There would be much less push back.
I say this as someone with 2 huge pre-AI datacenters in my town that have been fine.
> They either hook up to the grid and jack up everyones electric prices or use generators because they can't be bothered to wait for a grid connection.
Got source for that? Because in 90%+ of cases the power prices dropped because they are baseload.
I started before the guide was published. I am 40 years in on challenging myself and learning and improving and there remains so much more I have the opportunity to master.
I myself am spending a lot of time leveling up, I recently realized there are so many things about programming and CS that I don't know about or only have a superficial knowledge. There's so much to learn but it's very rewarding.
Not everything is encrypted though, session data (even from the sub-agent) remains unencrypted, only select things like the prompt the (main) agent sends the sub-agent is encrypted, rest of communication between the two seems still to be plain-text.
Regardless, I've updated the title from "Codex starts encrypting prompts, uses ciphertext for inference instead" to "Codex starts encrypting sub-agent prompts", hope this makes it clearer for everyone :)
From what little I read in the literature I seem to recall that there were enough programs with quite a bit more memory usage that they decided this approach was a dead end.
Does anyone know anymore details?
reply