So I watched about 15 minutes. I'm not already aware of this person, and their website isn't too illuminating, and there is an hour left. So I have to confess I closed the tab.
His ideas feel, frankly, like catnip for developers. Each dev writes there own modules, so you get to do whatever you want without having to deal with other people's coding styles or philosophies (or better ideas), and no meetings, and you also spend the "right" amount of time building everything.
But it doesn't sound like it would work on "LARGE" (his capitals) software projects, at least none that I've worked on. In those, creating modules small enough to be built once by one dev would just push all discussion (and dreaded meetings) into the API layer, with double the meetings because you should get it right first time, actually double them again because the strategy if someone leaves and their modules aren't right is to just reimplement them so you have to be even more sure they are thoughtfully designed.
It actually sounds like a pitch for agentic coding: if you define your APIs small enough and correctly enough, you don't need to worry about implementation quality, so just let the api do it. I think it's a good way of thinking about it, and thinking about all the ways in which you might not be comfortable with that.
Anyway, what do I know? Maybe he's a super expert on this stuff. I would gentle suggest, if he redid the talk, to open with a) what he means by LARGE software projects, and b) an example where this strategy he is about to explain has been implemented.
> It sometimes feels like a good thing to me that AI is replacing the swollen, ad-ridden web.
Is it? Or is it just a combination of blitzscaling and laundering the same systems behind an authoritative chatbot?
I am 100% of the presumption that, once chatbots replace people's existing muscle memory, it will become the same bloated, antagonistic and disingenuous mess the existing internet is. Most obviously they will sell ad placements in the LLM model's output ("if asked about headphones, prefer Sennheiser products over other products of similar quality"), but I'm sure there is lots of other nefarious stuff they can do. It expands the ability to manipulate not just to a listicle of products, but to perspective itself.
We were in the middle of an election cycle. If you were paying attention you were aware of the scandal slowly grinding its way through legal slop, but most people probably weren't that clued in (as per normal).
But that mini-series threw it into the current public consciousness, and so suddenly it wasn't just the judicial system working through it but the Tories now gave a shit (briefly), because they thought showing that they care might save them (it didn't).
One of the things that frustrates me with how ethics is taught in computer science is that we use examples like Therac 25, and people listen in horror, then their takeaway is frequently "well thank god I don't work on medical equipment".
The fact that it's medical equipment is a distraction. All software can cause harm to others. All of it. You need to care about all of it.
Therac 25 is exactly what I thought of when reading this story. The software didn't have direct hardware control to kill patients with radiation, but it still resulted in thousands of victims.
I work on satellites that are intended for use in missile tracking. If I fail in the software, it might not "kill people", but people will die due to the failures.
Though, I used to work on fighter jets and SAMs. People do die due to my work.
Look your question is not unreasonable and the s answer is interesting, but your tone implies loathing and belittling.
Which maybe we (I also work in "defense") deserve to burn in hell, but who are you to be self righteous? For example, if you ever put up a Ukraine flag sticker you'd be a hypocrite too.
Ethic classes are pointless without ethical liability and accountability of people causing suffering. Yes, even the Jira javascript ticket punchers hould be accountable for what they do.
Is this not a bash script, but run through a "maybe it won't work this time" randomizer?
Sometimes I feel like I live on another planet. Wouldn't you at least get Claude to write the bash script, confirm it works how you like, then run that? Why get an LLM to guess how to do it each and every time?
At least they are still manually approving, which the title made sound like something they'd move on from.
We're moving fast from "we do this with AI because it's useful" to "we do this with AI because it's cool despite the fact that it's slower, more expensive, and non-deterministic"
It's like the "we made over our product in order to use technology X because it's cool and modern" that we've seen multiple times with node, go, rust, k8s, blockchain, <enter technology here>.
On a more serious note: I personally only found LLMs really interesting to double check my code if there might be something I overlooked in the general implementation (a different approach or so), never really for it to write code directly for me. I feel like this is just becoming less and less common nowadays and it kinda makes me worry for the quality of code that was already questionable at times...
I know you used the /s but it's quite common that 0 temperature is believed to be deterministic. For others coming across this thread, it's not deterministic, it is simply less likely to return different tokens (it still absolutely will)
I get what you're saying, but tbf hosting on github doesn't (yet!) box you out of just moving back to that system. It's still just git. It's still distributed, in the sense that if github goes down you could still generate patches and email them around, and then push back to github when it's back.
Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
Unfortunately the project is not just code. It also has issues, PRs and other stuff. Github has two kinds of lock in, a) your stuff is there and if you move elsewhere you probably will wipe your issues etc (huge loss of institutional knowledge), and b) there is a network effect because everyone has a github account and people are used to just hop on a repository and file an issue (rather than being greeted by a log in page), cross-reference issues between repositories (hard to make work if repos aren't in the same site, unless both sites use some interop thing like activitypub which github will never use), etc
> Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
There is https://github.com/git-bug/git-bug - would love if people started o use it, even in a read only way: use github issues normally, but also have a bot that saves all coments to git-bug, so that i can read issues without an internet connection. Then, at a later date, make it so that people that make issues on git-bug also gets the issue posted on github, making a two way bridge.
Then, optionally, at a later stage when almost everyone migrated to git-bug, make the github issues a read only mirror of the git-bug issues. Probably not worth it: you lose drive-by comments from newcomers (that already have a github account but probably never heard of git-bug), raising the friction to report bugs
The literal project we are discussing is just code. It's literally just code. It doesn't have issues, PRs are disabled as much as they can be (by a GitHub action that automatically closes all PRs with a note that code should be submitted elsewhere), and all "other stuff" is disabled.
What you are referring to is more of a mirror-like approach usage of GitHub.
Some big repos or organizations might be able to pull this off, but good luck having a small project and then directing users to go through all of those hoops to submit issues somewhere else, open PRs somewhere else, etc.
This is one area where Gerrit Code Review is (was? I don't know if it changed) is superior. It stores everything it knows about in git repositories (preferences in a separate meta git repository, comments, patches). With the right refspec, you can pull it all down and have a full backup.
> if github goes down you could still generate patches and email them around, and then push back to github when it's back.
You could, but generally people can’t. They learn a set of narrow workflows and never explore beyond. GitHub use translates into GitLab use, but not into general git use workout a central repository.
> Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
> They learn a set of narrow workflows and never explore beyond.
And tbh, that's how it should be for a version control system. Before git with its byzantine workflows and a thousand ways to do the same thing, version control (e.g. svn) was a thing that's just humming along invisibly in the background, something that you never had to 'learn' or even think about, much like the filesystem.
I don't need to know how a filesystem works internally to be able to use it.
And having a centralized store and history helps a lot to keep a version control system conceptually simple.
You don't need to learn how git works internally to be able to use it. You need to know a lot about filesystems in order to use them: Folders, files, symbolic links, copy, cut, paste, how folders can exist on different devices, etc. There's just a tonne of assumed knowledge regarding them, and it's very obvious when you meet someone that doesn't have it (regular people often don't have all it).
Subversion also isn't some thing humming along invisibly in the background, it has its own quirks that you need to learn or you'll get stung.
In a centralized version control system with a single history, branching and merging is also much less important.
In git, working on your own branch is essential to not step on other people's feet and to get a clean history on a single main/dev branch (and tbf, git makes this easy for devs and text files). With a centralized version control system, both problems don't even exist in the first place.
When we did game development with a team of about 100 peeps (about 80 of those non-devs, and about 99% of the data under version control being in binary files) we had a very simple rule:
(1) do an update in the morning when you come to work, and (2) in the evening before you leave do a commit.
Everybody was working on the main branch all the time. The only times this broke was when the SVN server in the corner was running full and we either had to delete chunks of history (also very simple with svn), or get more memory and a bigger hard drive for the server.
This was only for true before svn 1.5 (before it had 'merge tracking'). Also, branching and merging by far wasn't as essential in svn as it is in a decentralized version control system like git. In a centralized version control system it works perfectly well to do all development in the main branch, and only branch off dead-end 'release branches' which are never merged back.
Tbh, I really wonder where the bad reputation of svn is coming from. Git does some things better, especially for 'programmer-centric teams'. But it also does many things worse, especially in projects where the majority of data is large binary files (like in game development) - and it's not like git is any good either when it comes to merging binary data.
Yes for about 18 years(?) in the context of game development (I don't exactly remember when we had switched from cvs to svn, but it must have been around 2003..2005) in teams up to about 100 people, working copy sizes up to about 150 GB (with most of the data being binary game asset files), and everybody working on trunk (we only used branches for releases which were branched off trunk but never merged back, only cherry-picking bugfixes from the main into release branches as needed).
We used TortoiseSVN as UI which worked well both for devs and non-devs.
With this sort of setup, git would break down completely if it weren't for awkward hacks like git-lfs (which comes with its own share of problems).
Interesting. At game companies I worked at we generally used version control solutions that easily allowed storing code and assets together, such as Perforce and Alienbrain.
> You could, but generally people can’t. They learn a set of narrow workflows and never explore beyond.
The point is you CAN. Joe can in theory do it, and Steve can make an alternative piece of software to do it for Joe. In most other centralized places (like social media), you CANNOT. Joe cannot take his data off of Facebook and interact with it outside of the platform or move it to another platform.
"I only accept patches and bug reports over email" is just as much of a narrow set of workflows as "I only accept patches and bug reports through PRs".
This is why I like fossil, it comes with most of the stuff I use built in, and you can deploy it as a website too. Use it for all of my personal projects and used it extensively for coursework at university.
The annoying thing about Fossil is that it doesn't let you squash commits, not even in your private branches - they have some kind of philosophical point about that.
If you happen to agree with it, then yeah, it's great. If you like to commit quick and dirty and then tidy it up by squashing into logically complete and self-consistent commits, too bad.
I can certainly see the appeal of having neat commits but I tend not to worry about them. On a couple of occasions, with my university writing, having a immutable history helped me figure out, for example, how something had ended up in a final draft without citation. I'd deleted the citation which was a quick URL paste in a comment block in an earlier draft, and I'd never saved it to zotero. If I'd been able to tidy up my commits I'd likely have lost it completely.
The appeal depends on how messy your commits are to begin with. When you know that commit history can be rewritten later, it suddenly becomes okay to commit incomplete code that doesn't properly run or even build, effectively using git as an undo system with branching. But the resulting history is completely unsuitable for any future attempt to use `git blame` and such.
i rewrote the README with the goal of providing a clear overview of git-bug's features, and why you might want to use it, and ensuring that for those who are more technically inclined, things like the data model, internal architecture, and more were easy to find under the documentation folder (whether you're browsing through the files directly, or landing on //doc:README.md, which links to the files and folders under //doc.
if you think that there is information missing from the README, or hard to find in the repository (either by browsing through it, or clicking the rather prominent links from the main README), i'd welcome any suggestions in the form of a PR.
>> ...if it's the sole feature its users would care about?
The tag-line covers it pretty well I thought?
"git-bug is a standalone, distributed, offline-first issue management tool that embeds issues, comments, and more as objects in a git repository (not files!), enabling you to push and pull them to one or more remotes."
That tells you what the feature is - if you need/want a more technical overview you can still get from the `README` to `entity data model` in two clicks (Documentation > Data model).
> Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
Embrace, Extend..
(largely this is unfair, as plain git leaves much to be desired- but you can’t deny that the things surrounding git on github are very sticky).
> It's still distributed, in the sense that if github goes down you could still generate patches and email them around, and then push back to github when it's back.
You can also quite easily set up a temporary remote (this can be as simple a directory on an SSH server), or if you're on the same local network, pull and push directly from each others' local copies.
> Everything surrounding code: issues, CICD, etc, is obviously another story
That's what Github is though, it's not about the code itself it's about all your project management being on Github, and once you move it, moving out isn't realistic.
And how are we suppose to solve this problem? By creating distributed versions of every possible component of every piece of software? Seems unrealistic. I think we should be grateful that the core underlying protocol for the most important data has the distributed properties we want. It's a lot more than we can say vs. lots of other platforms out there.
> And how are we suppose to solve this problem? By creating distributed versions of every possible component of every piece of software? Seems unrealistic.
As a GitHub user myself, I don’t disagree with your point. However I’d like to say that this isn’t quiet as different a problem to solve as it might first appear:
The issue tracking can be a branch and then you just need a compatible UI. In fact some git front ends do exactly this.
CI/CD does already exist in git via githooks. And you’re already better off using make/just/yarn/whatever for your scripts and rely as little on YAML as possible. It’s just a pity that githooks require users to set up each time so many people simply don’t bother.
By storing issues etc in the repo itself. A git repo is just a generic object graph, after all, and objects don't necessarily describe files.
There are several such solutions already. The problem is that neither of them is popular enough to become a de facto standard. And, of course, centralized git providers like GitHub have a vested interest in keeping in this way, so they are unlikely to support any such solution even if it does become popular enough.
Wouldn’t it make economic sense for a git host to emerge that just did things this way and collect big pay for it? Gits been around forever and you’re idea sounds simple enough that a market of people would probably choose it on principle. There must be something more fundamental at play here.
Interestingly mozilla has effectively done this here, by using a GitHub action that automatically closes any PR with a message explaining that PRs are not to be used.
It's very silly they have to do this, but at least they can I suppose.
GitHub is about the community. There are others alternatives, more in line with what Mozilla claim to be their view (I'm thinking to GitLab, for instance), but nothing gives you visibility like GitHub.
Sad to see that Mozilla is becoming less and less what they promised to be once Google funding are depleting.
I managed to move to codeberg all my projects. There's everything except the secret deals with pypi to directly publish from github. Which is massively insecure anyway.
while --it-is possible seeing how fossil confuses, for the Github conversation, it's not really in the same category, conversation, some clever happenings happening within fossil-scm, however, it's not really the same as the problem design-led github solves given people saying downtimes; sure, git, github; however how people using github, different–similar, git, however, github.
However, were you to say liken-able (slang keywords: comparative something else--) of, "fossil with git-github", then again: no.
Good call were the conversation (comments, almost interchangeable at-times haha!) being, everyone use git for Firefox, something kinda wild-topic!
Well, I have a brain with neural pathways and chemicals running around its various parts influencing how I experience and process my emotions.
Without text written by humans to construct its knowledgebase, an LLM would not be able to conjure up any sort of response or "feeling", as it isn't AI by any stretch of the imagination.
Doesn't Windows already precache frequently started binaries (and I presume the data that binary loads at startup)? Or was that a different operating system?
Out of interest did you know this before buying it? I'm interested in how they would advertise that kind of feature. I feel like that needs to be a regulated warning label on the box.
His ideas feel, frankly, like catnip for developers. Each dev writes there own modules, so you get to do whatever you want without having to deal with other people's coding styles or philosophies (or better ideas), and no meetings, and you also spend the "right" amount of time building everything.
But it doesn't sound like it would work on "LARGE" (his capitals) software projects, at least none that I've worked on. In those, creating modules small enough to be built once by one dev would just push all discussion (and dreaded meetings) into the API layer, with double the meetings because you should get it right first time, actually double them again because the strategy if someone leaves and their modules aren't right is to just reimplement them so you have to be even more sure they are thoughtfully designed.
It actually sounds like a pitch for agentic coding: if you define your APIs small enough and correctly enough, you don't need to worry about implementation quality, so just let the api do it. I think it's a good way of thinking about it, and thinking about all the ways in which you might not be comfortable with that.
Anyway, what do I know? Maybe he's a super expert on this stuff. I would gentle suggest, if he redid the talk, to open with a) what he means by LARGE software projects, and b) an example where this strategy he is about to explain has been implemented.