FWIW, Scott Aaronson has likened the question on factorization of concrete instances to what happened during the Manhattan Project:
> Joe #11: Then you’ll be waiting a long time, because that’s a stupid metric. (Or rather: anyone willing to use that metric today, is probably someone you shouldn’t trust.) It’s almost exactly analogous to judging the Manhattan Project in 1942, 1943, 1944 by the metric “how big an explosion can you make, today?” I.e., it’s something that’s going to be basically flat for a long time and then undergo a step change, under the assumption that everything is progressing as it should—because you need a critical mass in the one case and to exceed the fault-tolerance threshold in the other.
I agree and I was being facetious since I know the answer is nothing much. The point is that IBM write all this breathless marketing copy that seems detached from the actual utility of the device.
Although I believe there's a difference with the Manhattan project. The original atom bomb was "useful" even at its small scale. Whereas there's likely to be a lot of time between a quantum computer that can factor 69 and a quantum computer that can factor RSA 2048.
> IBM write all this breathless marketing copy that seems detached from the actual utility of the device
What are the actual utility according to IBM? Did they say you can order one today on their website? Or even "call us to get the pricing info"? Are there case studies of what their customers use it for? Or only potential uses?
> Although I believe there's a difference with the Manhattan project. The original atom bomb was "useful" even at its small scale.
No it was not useful, otherwise it'd have been paraded and hyped up on the media. The trinity test was in July 1945. Hiroshima happened in August. They were practically used as soon as they were deemed ready. Hundreds of thousands people died.
No thats not a strange decision. self-hosted git servers disappear all the time, it's better to have everything unavailable at once when github is down than suffer whenever either of the sources goes unreachable. Non-developers view git availability as a simple utility, they don't attach a value judgement to git being usable with any remote.
> Palomar does keep a public preservation fork of every registered source, solely as a backup for the registry in the event that the original repository disappears.
The decision to limit git sources to Github is likely in order to be able to use Github's fork mechanism. Palomar could still offer to take a copy of the relevant commit of non-Github repositories.
And since all they need is a particular folder structure, you don't really need anything Git at all. Any kind of blob would do, cf. e.g. how Zenodo works.
The main reason Github is in the news these days is due to its unreliability. If availability is your main concern, Github would be a very odd choice for your One Blessed Source.
Besides, it isn't "self-hosted basement Git server VS Github". There are plenty of other large and reliable forges out there, such as GitLab, Sourcehut, Bitbucket, or Codeberg. Considering how many people - from individual devs to major open-source projects - are abandoning Github, launching a new project in 2026 which only works with Github is a rather odd choice.
It doesn't even make sense from a technical perspective. Git has a standard protocol it uses for cloning repos. You have to go out of your way to make it not work with other forges. And if reliability is critical, surely you'd just mirror it locally? Heck, why not make use of Git's inherent distributed nature and allow defining multiple upstream sources? Integrity is already handled by the commit hash itself, so it doesn't matter if you fetch that commit from Github, GitLab, or some guy's basement server - just take whichever one happens to respond the fastest.
That is a terrible metric to look into. Github being down is news, but on a long enough time horizon Gitlab or other provider isn't significantly better. It's just they are in news less often.
> on a long enough time horizon Gitlab or other provider isn't significantly better
I suspect the same. But do you have any evidence for this? The status pages of Github and Gitlab (more precisely their history pages) don't seem to be a good starting point for comparisons. Anything I find online are people reporting their own experiences, and it's difficult to tell how accurate they are, how many users were truely affected etc. The only thing I can vouch for is that Github has got more unreliable - adding to the hearsay myself...
I don't know if I'd consider GitLab, Bitbucket or any of the other git repo hosting services to be much worse than github in terms of availability or reliability.
But wouldn't you have to know the exact context before this token in order to verify the watermark? I.e. a paragraph wouldn't be sufficient; you would need the system prompt, previous prompts, and even hidden thinking?
There seems to be something strange going on with how it plays with the GHCP harness: I've experimented on a variety of inputs (code, plain text, literature search), and more than half the time it falls into an infinite text/tool call loop a la GPT-2. Which is a bit spooky as you're still being billed for those infinite loops! But when it works it works, and responses do seem a good deal cheaper than OAI/Anthropic equivalents, so hopefully they'll get it ironed out.
But if you are going to self-host, then you can also self-host a Mastodon server and never have to migrate anywhere; wouldn't that achieve the same effect?
No it wouldn't, because each Mastodon server can choose who to federate with and many servers don't federate openly or don't federate with smaller hosts for technical, scaling, or even political reasons.
I've done it, self hosted Mastodon limited my ability to participate in the social network in a way that it does not on ATProto.
Also you can't port between instances. Whereas this is fundamental to the ATProto ecosystem.
The new terms [0] say “You must not share projects that mostly consist of code written by "generative AI"-tools […]. Such projects having an unclear copyright status […]”
So okay, if you're concerned about the risk of liability from unclear copyright status, I suppose that's fine, but then why the “mostly”? It's not like the copyright status becomes less unclear by you supplementing with 50% hand-written code.
Its not the real reason. Copyright law varies with jurisdiction, is not simply if its AI written its not covered" anywhere AFAIK, and the and the reasons given in the blog post do have anything to do with copyright.
There is a certain amount of fuzzy thinking, but I think what is significant about this is that Codeberg is not a neutral place for FOSS software. It is a place for FOSS that Codeberg considers good - so no LLM code, no crypto related code, and no doubt more to come. I think it feels odd to people because its a different set of values to FOSS licences which are designed to be apolitical and neutral - a software license that stated that the software could not be used for crypto or in LLM projects would not be a FOSS license.
The most coherent argument I have heard is that LLM output might not be copyrightable. This matches what most courts have said, and is the assumption the entire industry is working under. There are probably eventually going to be cases where the LLM copies something verbatim, and then the courts will have to come up with some refinement to their tests. The legal exposure for this for codeberg is basically zero in the US, thanks to the DMCA.
So, their "copyright status is unclear" stance seems to be saying "it is unclear if the contributor can copyright the code, or if it cannot be copyrighted", but that argument does not make any sense:
"Not copyrightable" means "no one has a right to enforce a copyright on this".
If that is their objection, they need to run scrubs for public domain works + delete those too. God help them if they want to host old UNIX software. Unless someone has renewed the copyrights on stuff written before 1979, the copyright has already lapse, making it "not copyrightable".
If, alternatively, they're worried about inadvertent plagiarism, then they already have to have mechanisms to deal with intentional plagiarism, so no action is required.
If they're trying to impose their values on users by micromanaging acceptable use of third parties' computers, well, I agree: That's explicitly in violation of the definition of Free and Open Source software, so they're basically just ignoring their non-profit mission statement.
That is a good point. You could not host public domain code there, and there are quite important FOSS projects that are public domain - as well as the the old code you mentioned there is current stuff such as SQLite.
> The legal exposure for this for codeberg is basically zero in the US, thanks to the DMCA.
They are in Germany and they distribute software globally (i.e. you can clone or download code from anywhere) so zero liability in the US is not enough.
I think you are being rather harsh on them, but I think your point is more evidence that the real reasons are the ones in the blog, and they should probably remove copyright as a justification in the ToS.
I don't really understand international copyright laws at this point (too many jurisdictions), but, given the number of global sites that can only exist because of the DMCA (like YouTube), I assume there are comparable carve outs allowing platforms to host user uploaded content without being sued out of existence, as long as they pull copyright violations down reasonably quickly.
Right; see Lakatos. In its roughest form, you study the structure of whatever counterexamples you find, add those as (negated) preconditions to your proposition, rinse and repeat until you have a true statement. If the proposition remains useful, you now have a new definition.
reply