2/3 down the article I gave up. What are you trying to tell me? What is this revolution about? How are agent things fundamentally different and how are they being solved? What is this "second coming"?
Also, why "second"? Was git the first? But then what about all the other things before it? CVS was huge before, for better or worse.
Well, I like a good story, there is big potential in this long form stuff that's more than a tweet or two. There can be a great reward when the crux is revealed after building a foundation and then looking at it from different angles. But if that crux never comes then it's really just leaving a feeling of disappointment and waste of time that I invested into reading all this. And that does a disservice to everybody else writing blog posts.
I think that's part of why tiktok and yt shorts really took off. It's so short that if you realize it's bad and move on then your wasted investment in terms of time and energy was negligible. (Times 200 that's a different story but signal-to-noise is still high enough that people accept this.)
I can accept the authors bias, but all credibility was gone when I read “AccuRev was a fantastic system”. AccuRevs UX was akin to putting your face next to a farting anus and breathing deeply.
Honestly felt like I was missing some sort of satirical masterpiece as the author gleefully declared all the up and coming projects that are going to scatter open source projects to the four corners of the Earth.
Maybe they’ve been so locked into version control tooling as a career they’ve missed the bigger picture, but version control before git ubiquity sucked. Not saying Git is perfect but come on, are our memories so short?
Plan 9 had such a powerful model for networked systems using these virtual file systems, it sounds like a fairytale!
Oh, want to use that other machine as a gateway? Just mount its /net.
Oh, want to route audio through another machine? Just mount their soundcard into your /dev.
Oh, your machine is too puny to do the task at hand? Just run “cpu thebigmachine” which transplanted your entire environment over there (all the virtual file systems) so that you can continue doing what you were doing, but using that machine’s CPU and memory.
This solved the problem of having to transplant your setup to the remote machine, which you have with modern SSH. If you wanted a different environment you instead created it locally. Each process har its own virtual file tree with mounts.
There were cool things at the local level too: All the programs would expose virtual file systems to interact with. Text editor? Each window had a directory with files containing window content, current selection, even the UI “tagline” with commands. This meant you could write scripts for your programs in any language, because you just had to interact with files.
A modern take on plan 9 is definitely on my Christmas wishlist!
Have a look at Objective-Smalltalk[1][2], with polymorphic identifiers[3] (all identifiers are URIs), storage combinators[4] (virtual filesystems on steroids), and polymorphic write streams[5] (streams everywhere).
Objective-Smalltalk basically provides the sorts of things you write about locally at the language level. You could also move specific instances behind an operating system boundary.
I wonder if we're doing virtual filesystems wrong.
There is a good reason why traditionally filesystem access was mediated by the OS layer, but there are many use cases where you just want to give processes a different view of what they already can access and it could be done as a library in the same userspace process.
However, for that to work across all the processes in a session we'd need a standard way to install such a hook in all peocesses and that's achievable to some extent using LD preload but falls apart quite rapidly with statically built binaries or different libcs
Sending -asScheme to a reference is just a shorthand that actually constructs a composition[2] of a "path relative" scheme with the underlying scheme of the original reference. So
This composition mechanism can be carried further with post-processing, so an ing-scheme can be constructed by composing an image-decoder store with the another store
Git is incredibly mediocre. But it's all most people know. It's a version control tool that can't handle binary files; and no GitLFS does not count. The end result is a version control tool that is unable to actually version control all the things you need for a project.
This results in a Meta VCS layer where a ton of critical assets are stored in Docker files and other misery. If you want to re-compile a project for 2015 then good luck and god speed.
Personally I think full toolchains belong in source control. And that you should be able to clone / materialize a repro, yank your network cable, and build. This is how big tech monorepos work. It is TheWay imho.
IMO screw that. It's maybe a good way to build software in exactly one environment for exactly one environment, deployment to a corporate server fleet.
Consider a Linux desktop distro: if every little binary (out of order of magnitude 1000) acted like the center of the universe with gigabytes of build environment and "opinions" galore instead of portability, builds would take much more resources than they already do and parts wouldn't necessarily work together.
I half agree here. Now that the primary usage of Git is increasingly centered on providing auditable and revertible history for organizations that use a mix of AI (mostly) and people to do stuff with it, the requirements are going to shift away from being user friendly towards just being fit for purpose and efficient.
Git is so far good enough for this. It's not particularly user friendly. But that's not a problem for AI agents. What is a problem is that GitHub is a shared resource that is bottle necked on massively increased usage. That's nice if you are sharing code with other people but it becomes a bottleneck otherwise with a clear solution in the form of maybe using faster and compatible (or completely different) alternatives that do things faster/better.
If you sit back and watch what agents do with Git, it involves a lot of agents going through the moves of creating lots of pull requests, waiting for whatever CI systems to kick in, dealing with failures, etc. All that takes a lot of time and tokens and it's designed to compensate for human failures to properly follow processes. So, at least some of that is kind of becoming redundant. With AI we can compensate with more complicated processes instead.
There's definitely some optimization potential lurking there. If you have tens of thousands of agents working on a thing, it might be more efficient to share the burden of integration testing instead of each agent trying to do this independently and testing each micro change in isolation. Also you could question the logic of needing some centralized hub to dump and integrate code. Git is decentralized by design. GitHub is nice as a backup strategy but there are probably cheaper or different ways to do QA and integration with agents. As the development process changes and adapts to all this, the role of Git and Github also needs to be rethought.
As for the rest of the article, it seems a bit too people centric. Virtual file systems are cool. But do AI agents really need them?
Now that the revolution has apparently started, does anyone know of a version control system which uses encrypted storage? (I'm not concerned about performance, for I will use it for small projects only.)
> GitHub is still gigantic in both repos and minds, and its impact in the world of software development and collaboration in general has been enormous, and most likely it will continue to be.
Well - Microsoft worsened GitHub in the last few months with regards to reliability. The next corporate slayer move is to worsen it feature wise. GitHub will indeed most likely remain strong, but the outer shell has some cracks and that means people will be more eager to look for alternatives. It is also a problem that Microsoft has a say in open source projects via GitHub - I never liked that, and many others did not like that either, even more so with Trump acting in a political and ideological manner with his TechBros (who all have nothing to do with Epstein ... right? because what if some of them do ...).
It's great to see some moves to break up this great calcification around git. Gut greatest contribution to version control was stagnation. The space was evolving with great fresh ideas before git became a quasi-religion among the early adopters because Linus made it in a day and therefore it must be great or something. I'm exaggerating somewhat, but the zeal of some people back then was next level annoying.
Beyond that, git has a great deal of shortcomings, some obvious, some subtle. It was a regression against SVN in some ways and inferior to Mercurial in others. But the strengths of SCN and Mercurial are again vastly different. There is a reason SVN isn't dead.
My biggest gripe with the open source VCSes is that in the last 20 years, no meaningful evolution happened in the established tools, especially around any weaknesses. Commercial systems like Plastic and Perforce as well as proprietary solutions like piper/jujutsu and sapling show that the tools can still improve drastically. I'm excited for a future where we get better open tools for the masses.
Also, why "second"? Was git the first? But then what about all the other things before it? CVS was huge before, for better or worse.
Blog authors need a straight up TL;DR because I ain't reading all of that.
I think that's part of why tiktok and yt shorts really took off. It's so short that if you realize it's bad and move on then your wasted investment in terms of time and energy was negligible. (Times 200 that's a different story but signal-to-noise is still high enough that people accept this.)
Honestly felt like I was missing some sort of satirical masterpiece as the author gleefully declared all the up and coming projects that are going to scatter open source projects to the four corners of the Earth.
Maybe they’ve been so locked into version control tooling as a career they’ve missed the bigger picture, but version control before git ubiquity sucked. Not saying Git is perfect but come on, are our memories so short?
Great to have an inside view of wrangling technologies for these behemoth data sets.
Oh, want to use that other machine as a gateway? Just mount its /net.
Oh, want to route audio through another machine? Just mount their soundcard into your /dev.
Oh, your machine is too puny to do the task at hand? Just run “cpu thebigmachine” which transplanted your entire environment over there (all the virtual file systems) so that you can continue doing what you were doing, but using that machine’s CPU and memory.
This solved the problem of having to transplant your setup to the remote machine, which you have with modern SSH. If you wanted a different environment you instead created it locally. Each process har its own virtual file tree with mounts.
There were cool things at the local level too: All the programs would expose virtual file systems to interact with. Text editor? Each window had a directory with files containing window content, current selection, even the UI “tagline” with commands. This meant you could write scripts for your programs in any language, because you just had to interact with files.
A modern take on plan 9 is definitely on my Christmas wishlist!
Objective-Smalltalk basically provides the sorts of things you write about locally at the language level. You could also move specific instances behind an operating system boundary.
[1] https://objective.st
[2] https://dl.acm.org/doi/10.1145/3689492.3690052
[3] https://dl.acm.org/doi/10.1145/2508168.2508169
[4] https://2019.splashcon.org/details/splash-2019-Onward-papers...
[5] https://dl.acm.org/doi/10.1145/3359619.3359748
Especially the CPU functionality is really interesting. I'm pondering similar problems and the current solutions just aren't good enough.
There is a good reason why traditionally filesystem access was mediated by the OS layer, but there are many use cases where you just want to give processes a different view of what they already can access and it could be done as a library in the same userspace process.
However, for that to work across all the processes in a session we'd need a standard way to install such a hook in all peocesses and that's achievable to some extent using LD preload but falls apart quite rapidly with statically built binaries or different libcs
In Objective-Smalltalk[1], I can access a file as follows:
This is structurally the same way I would access a local variable, environment variable, database, remote http server etc. etc.And you can also introduce shortcuts
Or Sending -asScheme to a reference is just a shorthand that actually constructs a composition[2] of a "path relative" scheme with the underlying scheme of the original reference. So This composition mechanism can be carried further with post-processing, so an ing-scheme can be constructed by composing an image-decoder store with the another store And so on and so forth.[1] https://objective.st
[2] https://dl.acm.org/doi/10.1145/3359591.3359729
Please universe I beg you.
Git is incredibly mediocre. But it's all most people know. It's a version control tool that can't handle binary files; and no GitLFS does not count. The end result is a version control tool that is unable to actually version control all the things you need for a project.
This results in a Meta VCS layer where a ton of critical assets are stored in Docker files and other misery. If you want to re-compile a project for 2015 then good luck and god speed.
Personally I think full toolchains belong in source control. And that you should be able to clone / materialize a repro, yank your network cable, and build. This is how big tech monorepos work. It is TheWay imho.
Consider a Linux desktop distro: if every little binary (out of order of magnitude 1000) acted like the center of the universe with gigabytes of build environment and "opinions" galore instead of portability, builds would take much more resources than they already do and parts wouldn't necessarily work together.
Git is so far good enough for this. It's not particularly user friendly. But that's not a problem for AI agents. What is a problem is that GitHub is a shared resource that is bottle necked on massively increased usage. That's nice if you are sharing code with other people but it becomes a bottleneck otherwise with a clear solution in the form of maybe using faster and compatible (or completely different) alternatives that do things faster/better.
If you sit back and watch what agents do with Git, it involves a lot of agents going through the moves of creating lots of pull requests, waiting for whatever CI systems to kick in, dealing with failures, etc. All that takes a lot of time and tokens and it's designed to compensate for human failures to properly follow processes. So, at least some of that is kind of becoming redundant. With AI we can compensate with more complicated processes instead.
There's definitely some optimization potential lurking there. If you have tens of thousands of agents working on a thing, it might be more efficient to share the burden of integration testing instead of each agent trying to do this independently and testing each micro change in isolation. Also you could question the logic of needing some centralized hub to dump and integrate code. Git is decentralized by design. GitHub is nice as a backup strategy but there are probably cheaper or different ways to do QA and integration with agents. As the development process changes and adapts to all this, the role of Git and Github also needs to be rethought.
As for the rest of the article, it seems a bit too people centric. Virtual file systems are cool. But do AI agents really need them?
Come on at least say "many people". There are plenty of people still coding by hand.
Well - Microsoft worsened GitHub in the last few months with regards to reliability. The next corporate slayer move is to worsen it feature wise. GitHub will indeed most likely remain strong, but the outer shell has some cracks and that means people will be more eager to look for alternatives. It is also a problem that Microsoft has a say in open source projects via GitHub - I never liked that, and many others did not like that either, even more so with Trump acting in a political and ideological manner with his TechBros (who all have nothing to do with Epstein ... right? because what if some of them do ...).
Beyond that, git has a great deal of shortcomings, some obvious, some subtle. It was a regression against SVN in some ways and inferior to Mercurial in others. But the strengths of SCN and Mercurial are again vastly different. There is a reason SVN isn't dead.
My biggest gripe with the open source VCSes is that in the last 20 years, no meaningful evolution happened in the established tools, especially around any weaknesses. Commercial systems like Plastic and Perforce as well as proprietary solutions like piper/jujutsu and sapling show that the tools can still improve drastically. I'm excited for a future where we get better open tools for the masses.