Live data from Hacker News

Before GitHub

lucumr.pocoo.org

131–140 of 255 posts

Re: Before GitHub

#131

Earlier quoted context omitted.

I wonder what tradeoffs make Git faster for large repository. Though for a long time that excluded large blobs.

Git has format dedicated for storing snapshots of trees and diffing them, fossil just uses SQLite and few tricks to keep size small

Of tree, or of sub-DAG?

"Just use SQLite" feels like missing the forest for the tree (the pun being coincidence here). That is, certainly any database out there already use all kinds of very efficient structures to walk graphs under the wood.

Maybe Git has a more bespoke approach to its specific goal of source code as main topic to deal with, and finner layer of abstractions. Which could also explain the clumsy leaky interface it presents.

Re: Before GitHub

#132
post #129

Earlier quoted context omitted.

Funny timing — I've been working on a hosted Fossil service to scratch this exact itch. The integrated wiki+forum+tickets+code is killer for small teams, but most people who'd pick Fossil don't actually want to babysit a server. So we host it. Two things I keep coming back to: (1) The "opinionated / small-teams only" critique others have raised in this thread is real, and I think Fossil should own it instead of fight…

You should continue with a name which is related to fossils, fossillab.io, boneyard.dev and so on…

fossilised.dev .. maybe british spelling.

palaeontology.dev ... too awkward.

museum.dev has a sort of "this is dead" ring to it.

Ironically what fossils are stored in within a museum is referred to as a "repository"..

Well, there's only 2 hard problems in computer science right?

Re: Before GitHub

#133
SF was exe + source code as zip file. And an admin that made all the decisions and had to for a project,

I do not agree with details, because it was for me before and after git.

So the hidden denominator here is and still is git, which sparked a tooling frenzy with reversing flow by being online server first (it wasn’t named cloud back then).

So even today, all splinters are doing something around git. That hasn’t changed.

What I really miss is the some sort of standardization that GitHub provided for a brief period of time. Projects would get no love aka stars when you couldn’t easily be used even for the experts. Some convenience as well as tooling evolved, devops became a thing.

I think of the future of a concept called cocooning. The JavaScript expert of today would be puzzled to write code on a notepad in a html file, because it has become so meta, being TypeScript essentially.

There is so much tooling going on that especially Python before AI already felt like I would miss something out if I would code more than 100 lines and that there must be libraries that abstract this all away and instead of coding I should google better.

AI is one thing, but the cluttered tech stacks aren’t really sparking any interest or joy in me, I think it is the not invented here syndrome or because I can story.

I miss the die hard coders, who stick to a tech stack which simply worked, not optimizing for weird use cases which are contrived at worst and rarely needed at best.

This became evident with the decline of data sheets, because Grunt, Gulp etc. as build tools were great but slow. We JavaScript devs couldn’t any longer joke about the compile times of the Backend dudes. And besides that, build times costs you focus, money, cpu time. But this was the main currency.

With AI I stopped trying out lots of tools because they feel like a weekend project by some dude who blasted his Claude budget.

Over are the fork and commit wars. Until AI battles itself this hard for quality source code I will stick to GitHub.

Re: Before GitHub

#134
> I definitely cringed when Zig moved to Codeberg!

If anything Codeberg’s legal structure (being a non-profit) and vision makes it a lot more aligned with the objectives of free and open source projects than GitHub in the long run (which has always been the case but it’s just abundantly clearer today).

I think “for-profit corporations providing high quality public services for free” was a zero interest-rate phenomenon and never sustainable.

Re: Before GitHub

#135
post #132
post #129

Earlier quoted context omitted.

You should continue with a name which is related to fossils, fossillab.io, boneyard.dev and so on…

fossilised.dev .. maybe british spelling. palaeontology.dev ... too awkward. museum.dev has a sort of "this is dead" ring to it. Ironically what fossils are stored in within a museum is referred to as a "repository".. Well, there's only 2 hard problems in computer science right?

> what fossils are stored in within a museum is referred to as a "repository"

I own a cute domain for that: repositoryum.com. I had the plans for it, but it's one of those that never came to a realization.

Re: Before GitHub

#136
post #21

I am still so salty that Git won out for the average project over Fossil. Sure Git has some performance advantages for massive codebases like the Linux Kernel, but the vast majority of projects will never run into performance limits from their VCS. Fossil’s internal tools (wiki, forum, tickets , etc) are just so useful to have versioned with your code in one file. I use Fossil for all my freelance work and it so easi…

Funny timing — I've been working on a hosted Fossil service to scratch this exact itch. The integrated wiki+forum+tickets+code is killer for small teams, but most people who'd pick Fossil don't actually want to babysit a server. So we host it. Two things I keep coming back to: (1) The "opinionated / small-teams only" critique others have raised in this thread is real, and I think Fossil should own it instead of fight…

Maybe something fossil-adjacent:

- amber.dev

- quarry.sh

You’ll probably need to play with gTLDs to find something that works.

Can also echo “scm” from fossil’s domain:

- amberscm.dev

Along with useX.com, Xhq.com, etc., patterns.

Of the two you have listed, I’d choose fossilforge, but would vote for an alternative TLD since .io has an expected meaning coming from GitHub.

Re: Before GitHub

#137
post #132
post #129

Earlier quoted context omitted.

You should continue with a name which is related to fossils, fossillab.io, boneyard.dev and so on…

fossilised.dev .. maybe british spelling. palaeontology.dev ... too awkward. museum.dev has a sort of "this is dead" ring to it. Ironically what fossils are stored in within a museum is referred to as a "repository".. Well, there's only 2 hard problems in computer science right?

Yeah, museum sounds like dead and rot… However on my small site [1] that’s the name of the fossil repos page

[1]: https://hdrz.cc/museum

Re: Before GitHub

#138
post #102

> Regardless of whether GitHub is here to stay or projects find new homes, what I would like to see is some public, boring, well-funded archive for Open Source software. Something with the power of an endowment or public funding to keep it afloat. Something whose job is not to win the developer productivity market but just to make sure that the most important things we create do not disappear. There is already such a…

Codeberg?

The problem is GitHub spends on the order of $100m/year on providing free CI. Nobody else can compete with that. It's possible they could make it shit enough that a large number of projects will say "screw this we'll just pay for CI", but people really like free (and easy!) things so I think we are a long way from that point.
Post reply on HN