pleroma.debian.social

pleroma.debian.social

really appreciated this post by Armin Ronacher about the importance of software archival and what might come after GitHub

personally i’m not very enthusiastic about self hosting and this post helped me see why

https://lucumr.pocoo.org/2026/4/28/before-github/

@b0rk Perhaps there's a continuum of alternatives between hosting everything yourself, and centralising everything in GitHub, e.g https://radicle.dev requires some local infrastructure but makes the software available through replication and distribution.

@b0rk Yeah, the effort/payoff ratio for *any* self-hosting, even a blog, is way too big for me.

@b0rk One thing I started doing a while back is cloning any repos I rely on to a private GitWeb instance on my Sandstorm server. It's not for everyone but I have an archive for me personally. For my own repos, I like to (ab)use free Actions and sync automatically, each repo has an action that pushes to my local copy.

@b0rk I self host my repositories not really by choice, but because I'âe seen Sourceforge, Berlios, Google Code and a few other rise and fall. The same will happen of any big, centralized forge. It doesn't solâe the archival problem. It just accumulates a lot of things for a while, and then loses it all at once.

I try to make sure my projects are backed up by software heritage. There also used to be "phonebooks" like freshmeat.net (no project hosting, just links to wherever projects are hosted)

@pulkomandy i'd never heard of the software heritage foundation, thanks!

@b0rk there is something to do for at least decentralizing the different functions: archival, discovery of new projects, code hosting, release distribution, ...

The all-in-one approach of Github to this is convenient, but when it inevitably fails, that breaks everything at once. Replacing just one of these things at a time in a project would be a little easier.

@b0rk @pulkomandy I'm always surprised when I see people not knowing something that I thought everyone knew :-)

https://www.softwareheritage.org/

@bortzmeyer @b0rk @pulkomandy Then just in case, you can easily snapshot releases on GitHub to Zenodo and get a DOI as well - https://docs.github.com/en/repositories/archiving-a-github-repository/referencing-and-citing-content

@pjacock @b0rk @pulkomandy I don't want a DOI. They are bad identifiers, maintained by a private organisation.

@b0rk

It is a good article.

But as a distro developer I am quite sad that such developer conversations neglect the role and the purpose of distribution projects.

Distributions do in fact represent a middle ground between going self-hosted and over-relying on a bit tech third-party.

They are made to solve the dependencies issues, to help with discovery, to serve as archives and as places to ask for help and collaboration.

Come to us, we have cookies :)

@bookwar I love that, I'm running an intro to linux workshop soon and I don't know if I'm going to have time to talk about Linux distros' function in the open source ecosystem but it could be a really interesting thing to bring in

@b0rk

RIght. Distributions have social, infra and coordination functions. They essentially allow FOSS developers to unionize and try to solve the shared problems together.

They also provide the supporting structure which turns the single XKCD-dependency guy into a part of a larger platform

https://floss.social/@bookwar/115082628376476848

We tend to over-emphasize the packaging (as in creating a specific package format) as the major function of a distribution, but it is not the goal rather the means.

RT: https://floss.social/users/bookwar/statuses/115082628376476848

@bookwar I'm so curious about this, I'd never thought of a distro as being related to a union

do you mean shared problems like the 32-bit to 64-bit transition?

@b0rk Thanks for sharing! It was a great read.

Still a bit sad that the author does not link it to any "political" ideas or forms of organizations. In some (plenty) of ways github (and previous forms he mentioned) was a product of a decade that is gone.

@b0rk Regarding archives, there is this vast project, @swheritage with precisely that ambitious objective.

@b0rk Was it because of the the whole archiving thing? I read the piece.

Maybe that will eventually not be a problem with self-hosting.

I could see a future where Forgejo or something similar is federated like mastodon and people can work together effectively and fork across instances and host backups of each other's repositories.

Where it would be easy to search for public repositories across the network.

And in the same way it's easy to back up Wikipedia, any entity with the resources could archive the whole thing.

There could be a collective who's purpose is to maintain such an archive.

@b0rk Software Heritage is the archive they described at the end as wanting - https://www.softwareheritage.org/

@b0rk OTOH, GH is still the worst dating platform ever! blobcat_not_like_googly

@b0rk I’ve been using https://www.pikapods.com/ (not sponsored!!!) for a few days and it’s a very interesting service halfway between self-hosting and SaaS. It feels almost like a homelab, just without the hardware.

This is not a suggestion or directly really on topic, sorry. I felt kinship with your comment about not liking self hosting.

@b0rk that's sad!! I wouldn't say "self-hosting" as much as "community-hosting".. I love it, and I think the future belongs to the people that are ready to seize this moment!

On a side-note, I honestly don't pay so much attention to what Amin says... I can see more clearly why from this blog post:

»I definitely cringed when Zig moved to Codeberg! But I now see people with real weight and signal talking about leaving GitHub«

@benjaoming i like the frame of community hosting!

i’m slowly rethinking my point of view but i spent a long time reading about tech startups and being excited about them, i worked for one of the biggest y combinator companies, the recurse centre had a huge impact on me, and I don’t know where i’d be today if I hadn’t been part of that world

anyway i like hearing about your point of view and about other ways to relate to technology.

@b0rk
That's one example.

In general, distributions are points where standardisation between various bits of the Linux ecosystem actually matters.

For instance, you can rely on your system following the FHS, not because upstream developers care, but because distributions do. Reproducible builds are another example of things that were pushed by distributions.
@bookwar

@b0rk
These improvements are usually pushed back upstream, because distributions don't want to have to maintain things like that in a branch long term. But these are shared interests, and for those, distributions are the ideal point to implement them.
@bookwar

@b0rk
To demonstrate how far this goes: Debian's policy document (https://www.debian.org/doc/debian-policy) explains the technical requirements of a Debian package. The first 5 chapters explain the technical details of the packaging system; the next 2 explain how the packaging-specific bits should act. The 5 remaining chapters explain how the packaged software should behave.
@bookwar

@b0rk
In other words, almost half the standard is about standards for upstream, rather than for the packaging-specific bits.

That comparison is a bit skewed though, because a lot of the last part of the document includes other standards, such as FHS or XDG, by reference.
@bookwar
replies
0
announces
0
likes
0