[dale_glass]

Yeah, I think the FSF and GNU are resting on their laurels and barely relevant.

So one of the core things for the FSF has been the GNU tools. Recently it's become trendy to rewrite stuff in Rust, and overall it seems like an excellent idea to have the core tooling of an OS being much harder to exploit, and often much more performant.

For instance ripgrep is a nice improvement on the classical grep, nushell is a better shell, exa is a better ls, and none of those is under the GPL.

There's also a project to do a straightforward rewrite of coreutils in Rust, and that is MIT licensed.

Where's the FSF's effort to modernize things and remain relevant?

[mbakke]

I think the FSFE (Europe) is doing a lot better than its American sister foundation, with active involvement in EU politics, running campaigns, etc.

Individual GNU projects are doing fairly well on the technical side (toolchain, Emacs, Guix, Mes), but there is little to no coordination across GNU, much less with the FSFs.

FSF Asia seems to have fallen off the earth, even though India appears to have a fairly active free software movement.

I don't think rewrite in Rust is a solution to "modernize" GNU tools. Maybe another memory safe language, but Rust has severe bootstrapping issues which is a hard sell for distros that care about source to binary transparency.

[noirscape]

The FSFe's knock-on effects (getting involved in local politics) also tends to translate to software that serve end-users.

A big issue with the FSF is that the GNU project only really serves two groups of users: programmers and power-users/commandline junkies. I belong to both of those groups. You know who doesn't? Most people out there. 99.9% of people using a computer don't give a shit on if their stuff is compiled with GCC, musl or clang. That's a fight that only concerns programmers (and one the GNU project arguably lost). The FSF simply never adapted to the idea that there's gonna be a sizable portion of computer users that will not know how to program. Too much of their rethoric is still laden on the assumption that everyone who uses a computer knows how to program (arguably an RMS relic, given his advice on learning how to program is just... unsuited for a lot of users[0]).

If you want free software to matter, start by funding free software that your average Joe needs to use. The FSFe seems to have figured that one out to some extent - governments contract out their IT work, so if you can get in a FOSS clause on those contracts, then that's a big win for everyone.

Just look at Peertube and Matrix for successful examples (regardless of product quality -I think Matrix is fundamentally broken-, these are both tangible things a regular user can access that are a meaningful alternative to YouTube/IRC).

[0]: https://stallman.org/stallman-computing.html

[Arathorn]

what bits of Matrix make it appear fundamentally broken btw? (asking from the pov of ensuring they get fixed)

[noirscape]

On a broader protocol level, it's just a case of "unexpected moderation pitfalls". Matrix is far more decentralized than even something like the fediverse is, which comes with a couple of issues for public servers. They're not really technical issues but social ones.

If we get down to brass tacks: things like how it's technically impossible to forcibly disband a room unless all parties agree to it/are manually kicked beforehand jump to mind as an issue that's not fundamentally broken per-se but is an example of "wait, that is supposed to work like that?".

Other than that, multi-room moderation is a total crapshoot. I've tried it, it just was a mess. You end up trying to plug in a moderation bot like Mjolnir onto your server and need to do the moderation through it instead of native clients. With the most common model for chats nowadays being closer to the discord model (where a subject might have many channels as opposed to the 2 or 3 you get on IRC), this isn't really workable.

Generally speaking, matrix doesn't seem to like many channel setups very well - there's been two attempts so far from what I can tell to solve it, but both just result in attempting to bolt existing channels into a "discord guild"-esque system with optional joining like it's an IRC channel list, which isn't how most people expect that to work. This is mostly a UX thing though - I imagine someone could write a client that just assumes the solutions on this in a better way.

The rest of it just amounts to some variant on "Element sucks" (which since it's the "main" client, makes it the most used one). The easiest example I can think of is that you need to use a GitHub PWA or send manual curl commands to say, set a server ACL on a channel or take server moderation actions on one of your users is absurd/unacceptable if you want to run a public service.

The main reason I call it fundamentally broken is because a lot of these issues seem to have been there for several years and the priority doesn't quite seem there to make the experience of using Matrix easier. Element lacking good moderation components for example is something I've noticed for years on end and updates never seem focused on improving any of it.

Sorry if this is all a bit disparate in terms of complaints/haphazard complaining about Element - they mostly come from running Synapse since ~2019 (+Element, back when it was still Riot) and in my experience updates to it never seem to have addressed many of the pitfalls/unexpected behavior that Matrix runs into compared to other chat apps I've used over the years.

[dale_glass]

> I don't think rewrite in Rust is a solution to "modernize" GNU tools. Maybe another memory safe language, but Rust has severe bootstrapping issues which is a hard sell for distros that care about source to binary transparency.

That IMO is of lesser importance. It's a technical problem that's of little relevance to most end-users. It's still a problem, but one that I think can be solved.

The point though is that the world keeps on moving, and the FSF and GNU should be keeping up. If things are going to Rust, or Java, or Go, or whatever then the FSF should do its best to follow and to assert its influence there. Otherwise it'll be left in a sort of museum curator position -- taking care of old tools that few need anymore. That may be a valuable thing to do in many contexts, but is not what you want to be doing if you want to influence where the world is going.

[cxr]

I agree with your overall position, but where you say:

> Otherwise it'll be left in a sort of museum curator position

I think we actually need this; somebody should already be doing it. I wrote about this several years ago:

> Maybe in an alternate universe there exists an organization—or some sort of loosely connected movement—that focuses on software comprehensibility as a gift to the world and for future generations. The idea is that once software approaches doneness, the org would pour effort into fastidiously eliminating hacks around the codebase in lieu of rewrites that presents the affected logic in a way that's clearer. This work would extend to getting compiler changes upstream that allows the group to judiciously cull constructs of dubious readability so that they may be replaced with such passages, which may have previously been not as performant but that now work just as well as the sections being replaced, without any penalty at runtime.

> For example, one of the cornerstones of the FSF/GNU philosophy is that it focuses on maximizing benefit to the user. What could be more beneficial to a user of free software than ensuring that its codebase is clean and comprehensible for study and modification?

<https://www.colbyrussell.com/2019/05/15/may-integration.html...>

[dale_glass]

> Maybe in an alternate universe there exists an organization—or some sort of loosely connected movement—that focuses on software comprehensibility as a gift to the world and for future generations.

And like I said, I agree that this is a good and valuable thing to do, but not for the FSF. The FSF is trying to change the future, not to preserve the past.

GNU tools used to be the high end, full of features versions compared to what commercial Unix had, which is why they caught on. But you can't sit on your laurels, or others will catch up.

Eg, what do they offer as a shell? Bash. Okay, that was a great shell once upon a time, but honestly by modern standards it's painful. Even a couple decades back I was already reaching for Perl if I had to write more than about 10 lines. Since then the situation has only gotten much worse, and meanwhile we have things like PowerShell and nushell that suggest a new approach. The FSF seems nothing to offer in response.

[cxr]

There's nothing in this comment or your previous one that I disagree with.

[mbakke]

<this comment was removed because of general bitterness>

Apologies to anyone who had to endure my display of contempt.

I agree with the parent comment that FSF (and friends) needs to step up their game to have any influence on the tech scene of the future.

[kouteiheika]

> Maybe another memory safe language, but Rust has severe bootstrapping issues which is a hard sell for distros that care about source to binary transparency.

It is possible to bootstrap rustc from just GCC relatively easily, although it's a little bit time consuming.

You can use mrustc to bootstrap Rust 1.54: https://github.com/thepowersgang/mrustc

And from then you can go through each version all the way to the current 1.72. (Each new Rust version officially needs the previous one to compile.)

[mbakke]

Right, Guix solved that a while back:

https://guix.gnu.org/blog/2018/bootstrapping-rust/

I was thinking about the fact that building Rust requires cURL, Python, CMake, and more, which makes the "bootstrapping graph"[0] very complicated if coreutils is rewritten in Rust.

0: https://guix.gnu.org/en/manual/devel/en/guix.html#Full_002dS...

[phkahler]

Rewrite it in Rust has become "rewrite it without the GPL" and that is a big problem. While there are valid reasons for permissive licenses at times, there is no valid reason to do core utils under a non-free license other than co-opting freedom. One day a new OS and ecosystem will come along and it will all be closed. The hardware will also not allow you to run free software.

Please stop enabling this with thoughtless license choices.

[9659]

The 're-implement in rust' crowd is doing it for the evangelizing of rust. If they cared about free software, they would have improved the existing tools.

I long for the days when the basic unix system is unusable because everything has been "improved" and is "secure and written in rust".