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
@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 :-)
@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.
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
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 #software 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! 
@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.
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
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
- replies
- 1
- announces
- 2
- likes
- 0