LWN: Comments on "LWN's guide to 2024"

Linux Software Map

alx.manpages — Thu, 26 Dec 2024 12:26:24 +0000

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.

LWN's guide to 2024

sammythesnake — Mon, 15 Jan 2024 10:05:58 +0000

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

dvdeug — Mon, 15 Jan 2024 03:33:19 +0000

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

TheBicPen — Fri, 12 Jan 2024 13:39:20 +0000

> 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.

LWN's guide to 2024

johannbg — Mon, 08 Jan 2024 22:41:30 +0000

> GitHub's dominance is problematic

How is Github's dominance problematic?

LWN's guide to 2024

mathstuf — Sun, 07 Jan 2024 18:10:42 +0000

I believe that every "issuable" has its own email address (using `+unique-id`-style addresses) and the sender is associated with the user account that sent the email (probably based on `From`, so mailing list header-rewriting might need to change). I don't know what happens if you send something to such an address without an associated GitHub account with the sending email address.

LWN's guide to 2024

dvdeug — Fri, 05 Jan 2024 22:43:28 +0000

> 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

sramkrishna — Fri, 05 Jan 2024 22:17:54 +0000

Since nobody is doing app ecosystem type stuff - let me add some things from my perspective:

* I predict that the popularity of distros like Silverblue and blue-fin where the OS is immutable is going to go up especially as a cloud native developer tool. Container driven work flows is going to get interesting.

* flatpak/snaps are going to continue to become more popular - flathub.org is going to gain more popularity as especially as we add the ability to pay or donate to open and closed source projects. Flathub is showing the popularity of apps for Linux.

Hopefully, we'll have some position statements on how AI is going to shake out. But I will say that in the world of democratized AI - the Free desktops are the ones to trust where your data and behavior are not used to drive AI.

LWN's guide to 2024

Cyberax — Fri, 05 Jan 2024 21:11:04 +0000

> I know this is opening up old debates, but Mozilla never made Firefox attractive for embedding or customization in the way that Google has with Chrome

Mozilla went out of their way to make it _impossible_ to embed Firefox. I guess the management wanted to make sure that Firefox brand is not diluted.

LWN's guide to 2024

pizza — Fri, 05 Jan 2024 14:52:06 +0000

> I think I've come to a round about way of agreeing with this, they keep shooting for the moon and missing (according to their own definition of success) rather than defining a goal that is more achievable and sustainable

The thing is, a "free standalone browser" _is_ not sustainable in the long run. That was the impetus for several of those moonshot projects (most notably FirefoxOS targeting smartphones); to try and make it so they're not entirely dependent upon platforms controlled by other, often hostile, organizations... that use said platforms to push (if not outright embed) their own competing browsers.

LWN's guide to 2024

raven667 — Fri, 05 Jan 2024 14:43:14 +0000

I know this is opening up old debates, but Mozilla never made Firefox attractive for embedding or customization in the way that Google has with Chrome, there are some reasons why Vivaldi, Brave, Opera and MS Edge built on top of Chromium and not Firefox when both are available for licensing under reasonably similar terms. Or why Electron took off and XULRunner didn't when I think they were trying to do similar things, maybe Mozilla was just early with the tech but people really didn't seem to care for XUL.

How was that different from Rust, which was invented to improve Firefox security, but has taken on a life of its own and will probably outlive Firefox as a project, getting wide industry adoption and a vibrant community.

I used to love Opera as a professional browser for people who are professionally online (as a sysadmin or developer, journalist or researcher) and Vivaldi is trying to rekindle that niche as a small sustainable business, but it seems Firefox is still targeting the general consumer in competition with Chrome, rather than a niche they could more easily dominate (same kind of criticism often lobbed at GNOME, which seems primary used by sysadmins/developers/media professionals but who seems to focus on the general consumer as their target user).

> For two cents worth of cynical speculation, I would guess that maintaining a declining browser is not a big enough goal. It's not shiny. It's not gratifying.

I think I've come to a round about way of agreeing with this, they keep shooting for the moon and missing (according to their own definition of success) rather than defining a goal that is more achievable and sustainable, but not as exciting. Some of their moonshots are not bad ideas either (like Rust, or even KaiOS) but I think a lot of people would prefer if they could be relied on to keep the lights on in 10y and not take on risky bets that could sink the org, like they are going to re-create Netscape and the dotcom bubble days again.

My wish – no endless discussion about law on LWN

Wol — Fri, 05 Jan 2024 14:31:19 +0000

> Judges can and do read Hansard to see what Parliament thought they were enacting (if the law isn't clear on the point in question), but they can't strike down the law as fraudulent. They don't need to: if they have to look at Parliamentary intention to interpret the law, and they find that Parliament meant X, then the law means X.

I think in this case, the law was perfectly clear. One of the parties, however, argued that the law did not say what the MPs *were* *told* it said. The Judge(s) sided with the party, so a perfectly clear law was set aside on the basis that the MPs didn't vote for what the law actually said.

Obviously, it's probably more complicated than that, but it was a definite case of "The law clearly says X, the MPs were clearly told Y", and the law as passed did not survive the court case.

Cheers,
Wol

My wish – no endless discussion about law on LWN

james — Fri, 05 Jan 2024 11:28:00 +0000

I'm not sure it quite goes like that.

Judges can and do read Hansard to see what Parliament thought they were enacting (if the law isn't clear on the point in question), but they can't strike down the law as fraudulent. They don't need to: if they have to look at Parliamentary intention to interpret the law, and they find that Parliament meant X, then the law means X.

If the Court of Appeal or Supreme Court / House of Lords make that determination, then that's precedent, and now the law does mean X in all subsequent cases (unless overturned).

This recent UK Supreme Court judgment discusses the point at paragraph 28 onwards.

As usual, I am not a lawyer, and if you need to rely on this, you need a good one!

My wish – no endless discussion about law on LWN

kleptog — Thu, 04 Jan 2024 22:22:33 +0000

I'd like to thank you for those links to Bert Hubert's blog, he explains things very very well. And he also includes some fascinating links regarding the explosive use of recitals in EU legislation which was puzzling to me. The problem appears to be the overwhelming majority of people involved in the drafting of EU legislation, from EU institutions to policy experts, don't have any legal training. There is no part of the legislative process that is targeted at improving the legal quality of the texts. Basically, what EU legislation really needs is a good editor to cut out all the fluff, even if the consensus is that the current results are of fairly high quality, just overly wordy.

With regard to the legal discussions on LWN, I think that indicates how much Groklaw is missed.

(The Debian statement was mostly badly timed, the vote being after the trilogue, but before the new draft was published. If it had happened a month or two earlier it would have mattered more.)

My wish – no endless discussion about law on LWN

Wol — Thu, 04 Jan 2024 21:53:48 +0000

To throw something else into the mix that has happened in the UK, but I can't see happening in the US,

The Judges read Hansard (the official record of the proceedings of the House of Commons) and issued the following ruling:

"Hansard says the MPs were told X, the law says not-X, therefore the law is struck down as fraudulent".

I don't think it went down very well at all in some quarters, but as PJ said, "law is squishy", and it's hard to argue when the ruling basically says "the law's backers lied".

Cheers,
Wol

LWN's guide to 2024

Lionel_Debroux — Thu, 04 Jan 2024 19:53:22 +0000

Last time I checked, the main sponsors of gccrs were Open Source Security Inc. and Embecosm. They've been contributing resources where none of the large companies did it... and they could afford doing it thanks to some of their other operations which earn money.
Come to think of it, with their history of over 20 years consistently working on making operating system kernels (mainly Linux, but not only it) safer, Open Source Security Inc. is one of the most obvious candidates for helping with that work, through the usual defense in depth philosophy: Rust is not a silver bullet, but can be part of the technical solution.

My wish – no endless discussion about law on LWN

NYKevin — Thu, 04 Jan 2024 18:27:27 +0000

+1, but statutory interpretation is even more complicated than you make it out to be. There are a ton of different principles for how judges try to resolve ambiguity in laws, and this varies significantly between jurisdictions. Here are some (non-exhaustive) examples from the US:

* What does the dictionary say these words mean? If you can figure it out just from looking up terms in the dictionary, then it wasn't actually ambiguous in the first place, so no using any of the other rules to find a cleverer interpretation. You might think that two judges coming to different legal conclusions about the meaning of a statute would be enough to render it "ambiguous," but in fact it is quite common for judges to disagree about a statute that is ultimately ruled to be unambiguous.
* Is there a federal agency responsible for executing this law, and if so, how do they think it should be interpreted? Then side with them if it's a "permissible" reading ("Chevron deference"). Caveat: Their opinion only matters if the statute was ambiguous in the first place, and not if the issue in question seems really important (the "major questions doctrine"). Also, the conservative legal movement does not like this rule, so who knows whether SCOTUS will narrow or eliminate it in the future.
* Would one possible interpretation cause Constitutional issues, and the other would not? Then go with the reading that doesn't cause problems ("Constitutional avoidance").
* Does one possible interpretation have far-reaching consequences, well beyond the scope of the statute as it seems to be intended? Then that's probably the wrong interpretation ("Congress does not hide elephants in mouseholes").
* Would one possible interpretation cause part of the sentence/paragraph/whatever to have no legal effect? Then that's probably the wrong interpretation (it would create "surplusage").

The annoying part: As far as I'm aware, there is no established order of priority for most of these rules (except for the obvious one: you have to figure out whether the statute is ambiguous in the first place before you can try applying different rules to it). Judges just pick whichever rule makes the most sense in any given situation, in that judge's individual opinion (but they will probably talk about all potentially-relevant rules just to cover their bases).

My wish – no endless discussion about law on LWN

farnz — Thu, 04 Jan 2024 14:47:12 +0000

There's two challenges, though:

People come in and call long-established (as in decades-old) principles of another country's system "crazy" (or other pejorative terms) simply because it doesn't work the way they expect from their understanding of their local system.
LWN.net discussions aren't the place that's going to affect the final outcome of the system; Bert Hubert had far more impact on the current text of the CRA than any of the people complaining about possible side effects here, because he wrote to actual legislators involved in the CRA and had changes made to the language of the latest draft to reflect concerns he had.

And then on top of that, you have people forgetting that there's a huge difference between how laws are "executed" and how code is executed; a law is interpreted by judges who will read the preamble and other non-binding parts of a rule to help resolve ambiguity; this is akin to a compiler reading the comments and turning UB into the right behaviour because the comment clarifies the programmer's intentions.

LWN's guide to 2024

timon — Thu, 04 Jan 2024 14:40:39 +0000

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.

My wish – no endless discussion about law on LWN

pizza — Thu, 04 Jan 2024 14:18:55 +0000

> In 2024, I'd like to see less discussion about laws on LWN. Reporting is superb, but the comment sections become a junkyard very quick. Be it about CRA, or Red Hat and availability of source vs GPL, or any other "legal" topic.

I'm sorry, that is _highly_ naive and is the moral equivalent of sticking one's head in the sand.

We are _all_ stuck dealing the the consequences of the law and the legal system. Sometimes the "bad" effects are unintentional; other times those effects are explicitly the purpose -- and we are _well_ past the point where we can expect "someone else" to advocate for our interests.

What drives most F/OSS activity? A combinational of Idealism (create the world I want) and pragamatism (make the best of the world as it is). The law is no different, and there is a remarkable amount of overlap in their effects on each other.

There is an old book by Lawrence Lessig, _Code and the Laws of Cyberspace_, that touches on this, and is still worth reading.

> Most have zero understanding how legal systems in other countries work

Most have zero understating about the legal systems in _their own countries_ work -- in theory or in actual practice.

LWN's guide to 2024

spacefrogg — Thu, 04 Jan 2024 13:54:57 +0000

> 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.

My wish – no endless discussion about law on LWN

Wol — Thu, 04 Jan 2024 09:37:24 +0000

> Most people here are not lawyers. Most have zero understanding how legal systems in other countries work. No one has understanding of many nuances how law works. Discussions about law matters here reach hundreds of comment, most of them misguided or blatantly false :(

> If lawyers were to discuss how to implement interrupts handlers in real-time OS, we would not treat them seriously. But when tech people discuss licenses or law in general, everyone seem to think they're knowledgeable in the topic. We are not. Leave law to lawyers.

Well, lawyers have good reason to be interested in real-time computer systems if they drive a modern car ... and lawyers write laws that affect ordinary people (including programmers) so we have good reason to be interested in legal stuff. That's why Groklaw is so seriously missed.

But yes, a little more light and a lot less heat would be appreciated, especially when people are deluded into thinking they are speaking the same language. It's bad enough trying to translate between The King's English and Legal Europese, without a bunch of people thinking Street American is mutually comprehensible with the other two ... :-) (that's without throwing Hansard into it!)

Oh to have Groklaw back :-(

Cheers,
Wol

LWN's guide to 2024

joib — Thu, 04 Jan 2024 08:05:16 +0000

No prediction that 2024 will be the year when the real time tree is finally completely merged?

I vaguely remember this has been predicted previously, but it now seems like the end is really finally in sight?

My wish – no endless discussion about law on LWN

zdzichu — Thu, 04 Jan 2024 07:15:12 +0000

In 2024, I'd like to see less discussion about laws on LWN. Reporting is superb, but the comment sections become a junkyard very quick. Be it about CRA, or Red Hat and availability of source vs GPL, or any other "legal" topic.

Most people here are not lawyers. Most have zero understanding how legal systems in other countries work. No one has understanding of many nuances how law works. Discussions about law matters here reach hundreds of comment, most of them misguided or blatantly false :(

If lawyers were to discuss how to implement interrupts handlers in real-time OS, we would not treat them seriously. But when tech people discuss licenses or law in general, everyone seem to think they're knowledgeable in the topic. We are not. Leave law to lawyers.

LWN's guide to 2024

JoeBuck — Thu, 04 Jan 2024 01:22:03 +0000

Yes, Linux succeeded because GNU, BSD, and X had already done the work of building a free Unix-compatible userland and development tools. The kernel was the last piece (and an extremely important one). But without all of that work, it would not have been immediately useful.

LWN's guide to 2024

Wol — Wed, 03 Jan 2024 21:33:18 +0000

> I understand, that contributing to such software can be a substantial personal benefit, but I find it important to discuss the overall consequences to the ecosystem and to establish/adjust a moral compass.

Oddly enough, I come to the complete opposite conclusion, for the exact same reasons that led you to your conclusion.

ScarletDME started life as a commercial product. It was "donated" by the owner as a linux-only version under the GPL. (Then they had a bit of a falling out with the community - I don't think they properly understood the GPL :-(

So. I'm going in the near future to modify the copying file to say that I, personally, grant a licence that any changes I make to Scarlet can be incorporated into the original OpenQM code base. I'm *hoping* that will encourage the current owners to free their updates into the Scarlet code base, but I look at it as (a) they gave me Scarlet when they had no need to whatsoever, I'm happy to give back to OpenQM on the exact same basis. And (b), if anything happens to Scarlet, I want to make sure that MY customers/users can move to the commercial product (if they so wish) without losing any functionality. I hope the other Scarlet contributors will sign their name to it too, but that's up to them.

Cheers,
Wol

LWN's guide to 2024

iabervon — Wed, 03 Jan 2024 21:22:02 +0000

I think there's a federation issue, more than anything else: can kernel.org do anything that appropriately conveys that Al Viro reviewed the PR in a message kernel.org received from him? Or can kernel.org deliver Al Viro a useful email such that, if he replies in the usual way, the review arrives in the PR appropriately? (Al Viro being an example of someone whose normal email address is not at kernel.org.)

The forge and the email list probably have to be able to trust each other to have done the appropriate authentication of the attribution of review comments before transforming them in ways that preserve the meaning, which probably requires some sort of special agreement to be not too awkward.

I guess it might be okay to have the GitHub PR get a lot of review comments by kernel.org that say "according to (link to lore), (real person) says: (extracted comment about that part)", which kernel.org could add on its own behalf.

LWN's guide to 2024

Wol — Wed, 03 Jan 2024 21:20:25 +0000

> trying to do too many things at once usually results in not doing any of them particularly well.

(a) Who cares? and

(b) People who do this "Just for Fun" are usually clever enough to be "Jack of all trades, MASTER OF MOST".

If they weren't clever, they wouldn't *want* to do it.

Cheers,
Wol

LWN's guide to 2024

rincebrain — Wed, 03 Jan 2024 20:49:32 +0000

Github allows replying to PRs via email, so I don't think it _has_ to violate ToS...

LWN's guide to 2024

roc — Wed, 03 Jan 2024 20:01:06 +0000

Mozilla incubated Rust until it became so important that it could continue to flourish without Mozilla's financial help. That's certainly a form of success.

In one way, Mozilla cutting their Rust team actually *helped* Rust: people used to worry about the future of Rust if Mozilla cut that support (sometimes in public as a FUD tactic, sometimes in good faith), and now they don't.

LWN's guide to 2024

sramkrishna — Wed, 03 Jan 2024 16:47:19 +0000

I actually believe that the dangers of inequity caused by AI will make trust in Windows and MacOS go down and we might see more interest in Linux on desktops/laptops. I think as GNOME and KDE continue to focus on the app ecosystem this is going to turn more critical as time goes by.

LWN's guide to 2024

elenril — Wed, 03 Jan 2024 16:19:05 +0000

That is entirely orthogonal to my point, which is that trying to do too many things at once usually results in not doing any of them particularly well.

LWN's guide to 2024

pizza — Wed, 03 Jan 2024 16:08:00 +0000

> For two cents worth of cynical speculation, I would guess that maintaining a declining browser is not a big enough goal. It's not shiny. It's not gratifying.

Eh, it's a lot more mundane than that.

All of firefox's competition (ie Edge, Chrome, Safari; everyone else doesn't even count as a rounding error) has the _massive_ advantages of (1) being the installed-by-default browser on a proprietary platform and (2) being pushed by major, major web destinations ("works best on Chrome", "Use our Chrome app for best experience" etc).

Firefox got its initial market share because it was genuinely, objectively *better* than its competition (mainly IE6). Today, everyone is roughly equivalent feature/performance-wise, and the only real way Firefox has to distinguish itself is through superior privacy features. However, the general consumer market doesn't give a flying f- about that stuff. And there's simply not enough privacy geeks to amount to more than a rounding error.

I find this almost incomprehensible; Firefox plus a couple of ad-blocking plugins provides such a vastly better browsing experience to everything else out there, yet the masses have clearly spoken.

(Meanwhile, on a similar token, folks complaining about Firefox lacking in feature X, or Mozilla coprorate shenanigans, and using that as justification to use Chrome, which is objectively _worse_ in those same respects... really don't deserve to be listened to)

LWN's guide to 2024

dvdeug — Wed, 03 Jan 2024 15:57:56 +0000

> 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

Wol — Wed, 03 Jan 2024 14:47:34 +0000

To quote Linus (from memory, not verbatim)

THIS IS A TOY, NOT MEANT TO BE ANYTHING BIG.

Cheers,
Wol

LWN's guide to 2024

b7j0c — Wed, 03 Jan 2024 14:42:45 +0000

You should watch the Ladybird status demos on YouTube, they are well past the toy phase already

LWN's guide to 2024

b7j0c — Wed, 03 Jan 2024 14:37:34 +0000

But they seem to be succeeding (and having fun doing it)...so I'm not sure what the problem is

There are advantages with owning the roadmap of your dependencies

Chrome will shoot itself in the foot.

amck — Wed, 03 Jan 2024 13:54:25 +0000

> If Chrome becomes a malware delivery tool, then it's a perfect target for the CRA. If pretty much EVERY version is exploitable "out of the box" by a carefully crafted website, the regulator is likely to say "you can't issue a CE for Chrome". At which point, every product with it pre-installed becomes unsaleable in Europe.

Interesting. How might this work out: some form of safety checking would be required. No checking by Chrome on adverts and it becomes a malware tool. But Google implementing any form of blacklisting or vetting of advertisers becomes a slam-dunk anti-trust violation (Google getting to blacklist its competitors).

Amck

LWN's guide to 2024

elenril — Wed, 03 Jan 2024 13:22:23 +0000

>But isn't that exactly the attitude that produced Linux?
No, Linus set out to write an OS kernel. He did not also write his own compiler, text editor, or libc as a part of it.

LWN's guide to 2024

spacefrogg — Wed, 03 Jan 2024 13:14:40 +0000

I know my following opinion is heavily disputed, which is: The free software community could start by explicitly withdrawing from any so-called free software that is under any company ownership. In my opinion, contributing to these projects is short-sighted and detrimental to the free-software ecosystem as a whole. Each hour of work put into a company-owned project directly circumvents taxable action by said company (e.g. paying an employee or contracting another company), while maintaining (or even contributing to) all market and marketing benefits, that company has with this product. It is negligent, at best, to believe that this company-owned free software is not one of its products and not a market benefit. On the contrary, everyone who contributes to such software ruins the employee market for everyone else who would like to live from writing software (only by a bit, of course), right because they provide free services to a company that should pay for them.

Free software cannot be owned/governed by a for-profit organisation. This is a material conflict of interest due to how the free market works. Thus, I do not regard any of such software a valid target for free software developers.

I understand, that contributing to such software can be a substantial personal benefit, but I find it important to discuss the overall consequences to the ecosystem and to establish/adjust a moral compass.

The second most important point is that free software development infrastructure must be taken back from for-profit companies. It is exceptionally detrimental to project governance when (almost) the whole project infrastructure depends on the goodwill of a single company (usually Microsoft, of all places...). 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.