LWN's guide to 2024

Posted Jan 3, 2024 15:57 UTC (Wed) by dvdeug (guest, #10998)
In reply to: LWN's guide to 2024 by spacefrogg
Parent article: LWN's guide to 2024

> This is in addition to that I think that single-source project hosting is a dead end development. We need much more effective ways to manage software development and developer interaction via P2P protocols.

I'm always skeptical of P2P protocols. They're rarely long-term sources; if you want software to be available 24-7, someone needs to set up a server. Not only that, there's questions of trustworthiness; you want a known source to download from. You can already directly download from any git server another developer has exposed to you, but that depends on that developer running a server and making it available and known. Why is that better than hitting git.software.org and checking out their branch? A master server is more trustworthy, easier to find, easier to use, and doesn't depend on every developer constantly hosting their branch on an always-available server.

I'm not entirely happy with github.com being the one stop shop for Free Software, but it simplifies hosting and discovery. If it's not in Debian, and it's not on github, odds are I won't see it or hear of it. Remembering good old Freshmeat.net, I found there's an actively updated Freshcode.club, which may help with some of the discovery, but doesn't make hosting any easier. We left SourceForge, and the Free Software community will leave GitHub if we have to.

LWN's guide to 2024

Posted Jan 4, 2024 13:54 UTC (Thu) by spacefrogg (subscriber, #119608) [Link] (7 responses)

> I'm always skeptical of P2P protocols.
> ...

I would counter this argument with e-mail and http. For everything that is bad about them. They are one of the few user-visible protocols that are not seized by a single corp. to lock you in. Github and all the other web-based git hosting services are an interoperability joke. They don't even strive for an interoperable development process. That is what I am aiming at. I don't really care for P2P as a technical implementation but for an interoperable one.

> A master server is more trustworthy, easier to find

There is absolutely no justification for your trust. To be blunt, I presume your trust to be disguised laziness.
Apart from that, even with P2P protocols there will be "official" and well-known entry-points to a particular software project. That has nothing to do with the protocol.

> ... but it simplifies hosting and discovery

That is exactly what people call "slave thinking". Slaves also don't have to worry about anything. On the other hand they are completely at the mercy of their masters. This thinking gives up control (which is the basis for effectively exercising freedom) for laziness. For me this is a material conflict of interest between central, for-profit company-owned hosting and free software. There is nothing free about software whose access is controlled by a single entity.

> If it's not in Debian, and it's not on github ...

People don't scrape github to find software that solves their needs. Visibility has nothing to do with hosting. Not even with the inevitable github. It has to do with people not being inclined to subscribe to another(!) service. A problem that the free software community has precisely because it does not care for interoperability which would make subscriptions obsolete.

LWN's guide to 2024

Posted Jan 4, 2024 14:40 UTC (Thu) by timon (subscriber, #152974) [Link]

Your usage of “P2P” seems unusual to me. HTTP is not usually considered a peer-to-peer protocol but a client-server protocol.

> There is absolutely no justification for your trust.

Going with your example of HTTP, of course there is with well-known entrypoints and TLS with root CAs (the last one is a bit problematic, but generally works).

Example:
I know that the home of Linux is at kernel.org, so if I want to get in touch with Linux kernel development, I’d visit https://kernel.org and from there I can find the mainline Linux repository hosted at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...

Anyway, everything of what I just said doesn’t mean that we need the quasi-monopoly on code hosting and open-source development that GitHub is.

LWN's guide to 2024

Posted Jan 5, 2024 22:43 UTC (Fri) by dvdeug (guest, #10998) [Link] (3 responses)

> I would counter this argument with e-mail and http.

Which aren't P2P protocols. It's hard to discuss something when not using standard language.

>That is what I am aiming at.

What is what you're aiming at?

>There is absolutely no justification for your trust.

Are you saying you'd trust a copy of the kernel from any source as much as you'd trust one from www.kernel.org or www.debian.org?

>This thinking gives up control (which is the basis for effectively exercising freedom) for laziness.

Sounds like a high-flying theory that has trouble with reality. Civilization is made possible by specialization. Do you grab a loaf of bread off the supermarket shelves, giving up control? Or do you bake your own bread, from commercial bread, trading a bunch of time for a little more control? Or do you grow your own wheat and sugar and process them yourself? That gives you control, but you don't have any time left.

I could spend all my time digging around the web for new, useful free software, but then I wouldn't have time to write it or use it.

>There is nothing free about software whose access is controlled by a single entity.

It's not. You can download most major free software projects from Debian or RedHat or Gentoo, even if they're hosted on GitHub. One feature of Git is that everyone who has downloaded the git repository has the whole history (at least in most cases.)

GitHub's dominance is problematic, but let's avoid exaggerating it.

>People don't scrape github to find software that solves their needs.

Except that I just told you I do.

>A problem that the free software community has precisely because it does not care for interoperability which would make subscriptions obsolete.

I don't even know what you want. To me, GitHub makes it trivial to throw up a quick hack and not worrying about paying for a website or jumping through hoops. It means it shows up in random searches on GitHub. It means if I can find a program, I can download it through a consistent interface and offer patches through a consistent interface, that doesn't require me to subscribe to another mailing list.

I don't know what magic you want. Apt, yum, pip, maven, snap, they all show that people want one source with consistent rules, and GitHub falls into that.

LWN's guide to 2024

Posted Jan 8, 2024 22:41 UTC (Mon) by johannbg (guest, #65743) [Link] (2 responses)

> GitHub's dominance is problematic

How is Github's dominance problematic?

LWN's guide to 2024

Posted Jan 15, 2024 3:33 UTC (Mon) by dvdeug (guest, #10998) [Link]

It's a large piece of infrastructure run by a commercial organization, a huge one that could turn it off and barely notice the backlash, and one that has a historically complicated relationship to open source. It's potentially like Geocities, which Yahoo unceremoniously shut down and left a hole in the Internet that's never really been replaced.

LWN's guide to 2024

Posted Jan 15, 2024 10:05 UTC (Mon) by sammythesnake (guest, #17693) [Link]

The simple answer is that it's a single point of failure - the possibility that it might become unavailable or unusable because of some future event (Microsoft remembers the "good old days" of hating open source, some awful security blunder...) It's a good idea for the process to be robust against such possibilities.

The "Network Effect" means that any potential improved alternative has a hard time getting traction, even if it's genuinely better.

Additionally, there are those for whom GitHub is already "unavailable" because of reluctance to sign up to an account, or because the interface is unpalatable to them. Various such objections (which I neither entirely agree with, nor have zero sympathy for) are frequently discussed here, on LKML, and elsewhere.

A key thing to remember is that the *reasons* some are reluctant to use GitHub (or whatever) aren't really the important thing. They exist and present an impedance requiring some kind of response, either technical (email bridges / mirrors / federation etc.) or social ("we value using GitHub more than we value your participation")

It would be great if all the process stuff hosted on GitHub (pull requests, bug tracking, discussion etc.) could be stored in a way similar to how code is stored in git. Anywhere capable of hosting a git repository (including each developer's computer) could be a complete source for all that information with whatever interface layered on top according to the needs of whoever wants access. Something like GitLab could even be taught to provide a forge-like interface on top of it to provide what people like about forges.

I'm not sure that git is really the ideal substrate for this, but could perhaps be adapted for the purpose...

LWN's guide to 2024

Posted Jan 12, 2024 13:39 UTC (Fri) by TheBicPen (guest, #169067) [Link]

> People don't scrape github to find software that solves their needs.

I do this regularly. If I can't find a piece of software through my distribution's package manager, the next place I look is GitHub, with Reddit being a close third.

Linux Software Map

Posted Dec 26, 2024 12:26 UTC (Thu) by alx.manpages (subscriber, #145117) [Link]

For software, there's the Linux Software Map.
<https://en.wikipedia.org/wiki/Linux_Software_Map>
<https://lsm.qqx.org/>
<https://xteddy.org/lsm/>

In the Linux man-pages project, we publish new entries for each release:
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.g...>

That map leads you to the master (and alternate) servers for the project. From there, you can consult the README of the project, which leads you to the other resources of the project (mailing list, maintainers, git repositories, ...). And of course, you can send email to the maintainers asking for other git repositories. For an entire year, I didn't have keys to the canonical server, and the project continued to be maintained in my home server. Since we only relied on mail and git, both of which are decentralized, we could continue working just fine. This, on a centralized platform, would have had a much worse impact in the maintenance of the project.