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.
[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...
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:
hello ← file:hello-world.txt
hello ← https://example.com/hello-world.txt
hello ← env:GREETING
hello ← var:greeting // hello defaults to var:hello
And you can also introduce shortcuts
scheme:greeter ← ref:https://example.com/ asScheme.
hello ← greeter:hello-world.txt
scheme:greeter ← ref:file:./ asScheme
hello ← greeter:hello-world.txt
scheme:greeter ← ref:https://example.com/ asScheme.
scheme:greeter ← #MPWRelativeScheme{ base: 'https://example/com' } → #MPWURLSchemeResolver{}
scheme:img ← #MPWImageResolveStore{} → scheme:greeter
helloPic ← img:wave.png
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.
Putting toolchains in perforce is how it works for lots of C++ shops, the setup instructions are “sync and hit build”, whether there’s a toolchain upgrade required or not
It's not impossible, there just isn't that much demand for it.
In fact, the way I use Git is hardly any different, I have no interest in getting a black belt in git magic.
> GitHub has done too many great things over the years, so I hope it remains, but there is obviously an earthquake going on.
Is the 'earthquake' referring to the frequent outages over the last couple of years, and if so are those outages because Microsoft can't keep up with the demand?
It's closer to 'too relevant' than it is to 'no longer relevant'.
I use git+lfs for unity projects and it works out great. If I had a real studio I'd buy some perforce seats.
Reinventing the wheel like this is quite exhausting. There are options that are proven to work. AI authorship does not fundamentally violate the idea of some thing owning a specific commit. We don't need new schemas in our source control system. "Provenance" is a bullshit word used to make the AI sound like it's some kind of oracular source with superhuman capabilities.
Will admit it got exactly one thing right, which could absolutely justify everything else (including the price) for a long time: Software Bill of Materials, which is non negotiable in a lot of more serious/heavily regulated development contexts
That still didn't excuse the hacked together pile of ruby scripts our QA lead maintained, each one designed to unfuck a specific weird thing clearcase did. Once everything was on git, they just wrote another script that grabbed a bunch of tags from git and shoved them into clearcase to spit out the bom.
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.
While you're right about the disadvantages of git, pretending that it became ubiquitous because it "became a quasi-religion because Linus made it in a day" is selling short its advantages. If you think about it for even just a little bit, it should be obvious what a simplistic statement that it. Also, git was not the stagnation you make it out to be. Even with its warts, it was a breath of fresh air, not unlike jujutsu is now a breath of fresh air vs git.
I remember working with SVN, and all things considered, git was a vast net improvement. Git took a lot of pain away. It made working with a versioned code base faster and simpler, to the point of enabling much better collaborative software development. There's a reason we got GitHub and not SVNhub. And GitHub was what helped git become so dominant.
Would it have been better if Mercurial had beat out git in the propularity contest? Possibly? There's trade-offs between the two, but Mercurial's easier interface counts for a lot. But if it had won, I'm sure we'd be griping about its shortcomings by now.
So yeah, I'm also happy to see some movement around the ergonomics of version control, but I don't understand the need to disparage the tools that got us where we are. It just seems that you're more bitter than happy, and like you're letting that bitterness cloud your judgment.
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?
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?
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 ...).
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.
As a result you have to look at what they share about themselves to infer where they're going with things, because they never explicitly state it. All traits amplified for the worse when people use chat bots too much, in my experience.
Scrolling to the end, they write:
> In 2005 a dozen version control systems fought to replace Bitkeeper, and the winner ended up ruling software development for two decades. Nobody in that race predicted that the decisive factor would be a hosting site with a social network on top.
They had a VCM start-up around their own technology, then Git displaced all other technologies, and then Github ate everyone's lunch. So the first revolution not-so-coincidentally overlaps with the time they ran a SCM startup, and they ignore anything that happened before they entered the space. Funny that.
So the implicit context is the business case and programmer culture around VCM systems.
Meaning the second revolution is anything that challenges Git and Github.
They also keep bringing up gigantic mono-repos and how Git can't handle the scale at which AI increases the amount of code bloat or commits.
So what I read between the lines is that they believe that there are enough people who don't want to actually address the automated hyperscaled Wirth's Law in the room, and are willing to pay services and technology to adapt around it instead.
That's the new business case that will power the second "revolution".
Which sounds horrifying to me, and the worst part is that I can actually see it happening if this AI bubble doesn't pop fast enough.
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.)
For the next time, instead of scrolling, you can just press the little "-" next to a post which collapses it and its whole subtree. Out of sight.
Besides, I explicitly stated that I read 2/3 of the article. How is that "low attention span"? And I didn't just bash it, I formulated what I find missing in it. Do you have answers to those questions? And how does asking such questions indicate "reading difficulties"?
It's quite fascinating that if my comment is so appaling to you, why you'd take the time to respond. I thank you for that though.