For better or for worse, this is nothing new. It is a symptom of the fact that the FSF and other FOSS organizations have displayed a fantastic failure of technical leadership for over 3 decades. The political leadership has not been bad, but if you go back and dig through the history of open source you will see that there have been multiple repeated failures by the supposed thought leaders to provide the equivalent level of technical excellence that is required to compete.

Making the lives of developers of free software easier has rarely if ever been on the list of priorities for many of the core projects.

> It is a symptom of the fact that the FSF and other FOSS organizations have displayed a fantastic failure of technical leadership for over 3 decades.

I agree that many FSF/GNU projects have made horrible technical choices, but I don’t think that’s really the root cause here. The reality is that good software requires an enormous amount of skilled labor to create and maintain, and the FSF and other OSS orgs can only muster a small fraction of the engineering hours that a mid-sized for-profit software company could.

In addition, good user-facing software requires more than just good engineering - you need good UX, product direction, etc. Sometimes the creator or maintainer of an OSS program will have the good fortune to be reasonably good at all of these, but it’s very rare, and there aren’t nearly as many UX designers or product managers looking to contribute to open source as there are developers. Even if someone did want to help in this role, the developers on most projects would probably ignore them.

>Even if someone did want to help in this role, the developers on most projects would probably ignore them.

This is the lion's share of the problem, I suspect. OSS projects are driven by the people who write the code, and they don't take orders, and they don't massively value making things easy to use - or even necessarily have much connection with what that means. Current computing is such a pain in the ass that we've basically selected for inhuman levels of persistence and patience, and placed a large cultural value on those traits to boot. "Read the docs", we say. "Use the source", we say.

We don't have any idea how many human factors experts are out there, willing to help, because there's no process for them to contribute beyond "submit a pull request" - and even then, a purely UI tweak will meet with huge resistance. The UI expert is going to have to be a diplomat as well.

Stallman and by extension the FSF are opposed to user experiences. He links to the following article on his website:

http://contemporary-home-computing.org/RUE/

And of course, no closed software has _ever_ had a poor UI/UX.

It has a money in the bank at the end of the month, regardless of the UI/UX.

It might? It might also not have money in the bank? Is that relevant?

Bad UX is subjective. Money doesn't change that.

Bad UX (for some definition of bad) may be subjective, but that doesn't mean money won't affect it.

Suppose we want to optimize user productivity. For any given UX, some users will feel they're more productive with it, and some less. Finding a UX that maximizes the number of users who feel productive is going to help attract users to the product, and money can buy the design expertise needed to find that UX.

It might be the case that users only feel more productive with a given UX and aren't actually more productive with it. Even then, if a majority of potential users think that the UX is making it easier to accomplish their goals, a project will have an easier time attracting users.

It changes where most people are willing to spend their skills.

I don't think anyone claimed that. Do you disagree that OSS tends to have a worse UI than commercially developed software? If not, what's your point?

It's particularly interesting, because the rise of GNU is because it was an overall better set of tools than what Unix vendors shipped (HP-UX, IBM AIX, Sun OS, SGi Irix...).

The age of web changed all of that. Instead of being stuck on your computer with whatever tools you could obtain for it, you could now access centrally-maintained, quality webservices.

The FSF realized the freedom risk that centrally-maintained services posed, and created stuff like the AGPL to address it, but there just isn't as much leverage for that to take off like the GPL did.

Stallman's (and the FSF's) view on services is that it's like paying a plumber. The plumber isn't violating any of your freedoms by using non-free tools in their repair work, but it is unfortunate. This is a pragmatic view, because Stallman needed to grapple with continuing riding public transportation, even as they relied on non-free software, so an arbitrary line was drawn in the sand, one that barely made sense in the 80s and only continued to become more bizarre as computers became more and more networked.

This line has very bizarre consequences: FSF-supported hardware prefers closed-source firmware to be fused into ROM rather than upgradeble, the theory being that manufacturers shouldn't have more freedoms than the user. My favorite story was a laptop recommended by the FSF went from being "free" to "non-free" because an engineer found an undocumented protocol to upload new firmware to memory that the FSF thought was fused shut. These are the weird results that emerge when extrapolating extreme fundamentalist social policies far beyond their breaking point.

The FSF and Stallman do not care about the AGPL that much, they are far more worried about non-free software running on your own machine, like non-free JavaScript. Otherwise, Stallman couldn't ethically ride the T.

FWIW Stallman's stance was always that freedom is more important than technical excellence and that he'd rather use and promote a technically inferior product that respected users' freedoms than one that was technically superior but came with shackles.

Which is one of the reason's Stallman's ideas are fundamentally flawed as if there's a better product available even if it's only free as in beer, people will use it over the worse one, from the end user's perspective.

In the worldview of Stallman, your argument is analogous to saying that advocating for democracy is flawed because if an authoritarian regime or slave society provides a better product, people will choose it over worse democratic ones.

To Stallman, your counter-argument is a non-sequitur. His goal is maximizing user freedom. UX may be one dimension of user freedom, but at best it's secondary to certain prerequisite freedoms, such as the freedom to modify code so you can independently improve it, perhaps by improving UX for yourself and your community.

Many people sympathetic to Stallman, but more utilitarian, might argue that in the long term, user freedom is necessary for achieving optimal utility (e.g. UX, etc). And getting there might require short-term sacrifices in superficial aspects like UX.

It's really simple. If you want me to use your software, it needs to not be like brushing my teeth with a Dremel. I have things to get done, and while the Open Source movement doesn't owe anyone anything, I'm going to pick the product that isn't going to halt my work to try to figure out what broke again.

With as many open and closed options that exist out there, competition is a thing and Open Source as a whole needs to compete on more than just being "the freedom option"

Stallman's valid points are entirely lost in the ocean-full of software like GNU Image Manipulation Tool that incite frustration from users.

> In the worldview of Stallman, your argument is analogous to saying that advocating for democracy is flawed because if an authoritarian regime or slave society provides a better product, people will choose it over worse democratic ones.

Except that's exactly what human behavior does.

Fundamentalists take hardline stances to problems. To Stallman, one of the most unethical, immoral things one can do is to willingly run a computer program that they do not have permissions to modify.

Very few people in the world, even most FOSS contributors and developers, share that belief that strongly. They might feel like FOSS programs give them certain advantages and rights, but morals? Stallman has mentioned that he would rather go homeless than run proprietary software. That level of devotion is exceedingly rare.

To approach someone, even a Linux user, and tell them that they need to give up their convenience for free software because what they are doing is immoral, that's a very hard sell. This is one reason GNU has mostly produced free software clones of better, commercial software, where practical concerns take a backseat to GPL.

Can you give some examples of the fantastic failures?

> Doing almost anything yourself feels impractical these days.

I would argue this is only the case because we've created an intentional social and skill gap in the industry between server administration and operations work and software development. My experiences, especially more recently, have been shocking in how little the average software developer knows about /very basic/ server administration. I don't have a full picture of why this is, but my gut is that part of the reason is that this type of work has become socially considered to be beneath software developers. They see it as the type of thing you're supposed to outsource, scut work for digital janitors, so they never bother learning it. There's definitely a growing sheen of disrespect in the industry towards those very valuable skills.

The outcome is, yes, it may feel impractical to do things yourself. The reality is, it's probably never been easier to do things yourself. Everything from the widespread availability of low cost enterprise-grade hardware to the plethora of virtualization technologies and associated low-cost hosting platforms means that doing things yourself has never been easier than it is today. Yet it feels so far away because software developers in our current time are no longer the tinkerers they once were, preferring to focus on abstractions over dig down into the dirt of reality.

I think the best way to resolve this challenge is for individual developers to come down from their horses and learn the basics of system administration and actually try this stuff out. You can learn nearly 80% of what there is to know about systems administration and operations with an Ubiquiti router, two Raspberry Pis, and Google given enough time. But so many devs would rather use dubious SaaS tools rather than learn how to host their own Gitlab instance or run their own CI pipeline in their closet.

I don't agree. I spent a significant amount of time playing around with servers and never developed "mastery". I think that server administration has gotten more complex and the tools haven't changed much to help. A simple example is setting up an HTTPS/TLS/SSL endpoint. In the past, you just ran the HTTP server and you were off. Now there's a whole load of extra ceremony to setup a CA and sign your own cert or download a cert and merge it into something else. I think one can easily find many tiny little paper cuts like that and each time you have to remember some special process for how you do it. Unless you're repeatedly doing it or taking good notes it's hard for that knowledge to stick. Not to mention things change over time and across distributions (initv, systemd, etc.)

If anything TLS has gotten easier since Lets Encrypt came along. You just install one of the clients for it, configure a domain and periodic renewal and you're done.

For a public facing computer, yes, for a private one, not so much[1].

I use mkcert[2] for this but it's still fiddly.

[1] https://letsencrypt.org/docs/certificates-for-localhost/

[2] https://github.com/FiloSottile/mkcert

I bought a domain to use for my home network instead. I have LE issue a cert for it via DNS challenge and use it liberally with hosts on my LAN, with the excellent benefit that I don’t need to give clients a new CA I invented.

It's not easier than HTTP sans TLS, which is the point that was being made.

I fully agree about the skills gap, but I think the reason behind it is more that server administration has come to feel unapproachable, with an air of "better leave that to the experts", along the same lines as "don't roll your own crypto" (but less extreme) or how some people wouldn't dare run electrical wires in their homes.

Why run your own server, and keep it patched, and keep it secure, and configure the firewall, and all that stuff which spells doom if you get it wrong... when you can use some cheap or free service that does all the hard stuff for you?

I'm curious how much of this shift is purely because these tools really are better, or how much is due to an intentional marketing effort to make the DIY approach seem bad/unsafe/difficult/fraught with peril. I guess at some point it's a self-reinforcing flywheel. People think DIY is hard, so they actively avoid it, and tell their friends "running servers is hard, don't do that."

> My experiences, especially more recently, have been shocking in how little the average software developer knows about /very basic/ server administration.

I used to know quite a bit of that stuff, had a series of jobs doing it. I gradually moved from C89 to modern c++ over the course of about 25 years. Easy stuff, when you use it daily. But when it's not my job to do server admin, that stuff evolves too fast to stay on top of. For me it's not a high horse, rather, a wagon that I fell off a long time ago

Most folks don't _need_ much more than a LAMP-equivalent running on a virtual host somewhere.

Why bother installing k3s and whatever deployment-tool-du_jour it is these days, when dropping some files on a host is good enough?

Sure, and I'm not advocating to build a Rube Goldberg device, unless it's purely for learning purposes. But why go to great lengths (and expense) to avoid having to SSH into a server for your personal projects when you could run them on a Raspberry Pi or a $5/mo droplet?

The issue isn't that people need more than a LAMP stack, it's that for some reason software developers in the 2020s are scared to or think it's beneath them to install a LAMP stack of their own.

When you're a kid, tinkering is exciting. When you turn 30, you just want your software and tools to work. Janitoring your computer is not fun when it's in the way of your actual day job.

My worry is that this has bad long term implications.

Modern computing environments aren't very good, and most of the core abstractions haven't changed / improved since the 80s. Those core abstractions have so much stuff built on top of them now that they're very difficult to change. You used to be able to make a usable operating system in a month or two if you knew what you were doing. Now a simple web browser takes 20m+ lines of code to make. Its out of the hands of anyone with less than $1bn or so to spend - and at that scale the only real contributors are big tech companies. Except for some small features like io_uring and device drivers, linux is developed as if its already feature complete.

So I worry - will we ever replace the crufty parts of POSIX[1]? Will we ever have operating systems and software that can properly take advantage of NVMe and Optane memory[2]? Will we ever have desktop computers which sandbox software by default like my phone does, so I don't have to trust every program, npm library and rust crate on my computer with my data? Will there ever be a desktop class UI library which works across all my devices, or are we doomed to waste 90% of our computer hardware keeping electron + javascript fast-ish?

I'm worried these ships have sailed, and our grandchildren are destined to inherit a computing experience of electron, + more CSS.

In the 90s people would iterate on this stuff by just hacking linux and submitting patches. Now thats really hard because of how tall we've made our mountains of code. By the time you've climbed one mountain, you're halfway through your career. I mean, how many kernel hackers out there are also good at making user interfaces? How many people with frontend experience are even capable of hacking on linux? Its impossible to improve the interfaces between our systems without a holistic understanding. And thats becoming an increasingly rare commodity.

[1] Eg fsync(), and in my opinion the filesystem abstraction as a whole.

[2] Eg https://www.usenix.org/conference/atc20/presentation/bittman

> So I worry - will we ever replace the crufty parts of POSIX[1]?

No, probably not, as much as I would love to, because there are still people who believe that POSIX's design ideals are to be aspired to, even as the world has aged heavily around them. The POSIX model and philosophies are very outdated, but as long as people see value in the nonsense that is "everything is a file" (except for all of the ones that you can only ioctl to) or "do one thing and do it well" (except text parsing, that famously secure and not at all haunted thing apparently belongs in every app), we won't see big shifts in production OS architecture. Maybe research kernels, but those don't run PostgreSQL installs.

I don't think that has anything to do with this complacency, however.

> So I worry - will we ever replace the crufty parts of POSIX[

For sure, many of us don't use OS where POSIX has any relevant meaning.

The majority of the world is on linux. A small remaining fraction is on windows, where there is no less cruft.

Yes, there are embedded OSes (l4); ibm i&z; etc. (L4 and ibm i are actually super cool.) But those are tiny drops in the bucket and aren't replacing linux any time soon.

What world?

ChromeOS and Android? POSIX APIs are not exposed to app developers.

Cloud? Language runtimes and serveless make POSIX irrelevant.

IoT? Linux is largely irrelevant in the world of real time OSes and bare metal language runtimes.

Desktop? How is that 1% going?

You are making the great-grandparent's point (with which I was agreeing). Their concern was not only the cruft built up in the POSIX API, but the many layers of abstraction and behemoths of code that depended on said cruft, making it a compatibility nightmare to ever remove. That comprises the web browser that drives chromeos's apps; the java runtime that drives android apps; the language runtimes that drive serverless apps.

IoT is even more of a niche than desktop.

And, I think you underestimate the amount of software written in c, directly against posix.

I don't underestimate the amount of C code written against POSIX, luckly the last time I did it was in 2001.

Since then, language runtimes have spared me the effort, and I am not alone.

> ChromeOS and Android? POSIX APIs are not exposed to app developers. Cloud? Language runtimes and serveless make POSIX irrelevant.

The underlying POSIX filesystem is still exposed to android developers via java's File. And via the C apis too, from the sounds of things. I think its the same on iOS.

But even if you're only using posix calls indirectly through complicated database abstractions and unix sockets, you're certainly still paying a cost. Plenty of benchmarks have been made over the years showing how better APIs can yield 20+% more filesystem & TCP socket performance on linux by bypassing write() and friends. If you spend $10k on a database or application server, think about it as $2k of that hardware wasted simply due to bad kernel APIs. And I'm sure there's plenty of features postgres and sqlite don't have because their devs instead needed to spend their days in a desperate struggling to make their software work correctly, at all.

Aside from performance, in my opinion a better API would also be transactional, at the filesystem level. Aside from dramatically simplifying every database, that could also would allow collaborative editing through simple network shares. I don't even think it would be that hard to do.

> Aside from performance, in my opinion a better API would also be transactional, at the filesystem level

A better API shouldn't be a filesystem. As a strictly hierarchical system, its only virtue is that it should be easy to create sandboxes and reason about the resultant guarantees. Emphasis on 'should'; in practice, chroots are easy but very ineffective. (I believe fuchsia[0] and plan9[1] do a slightly better job of this.)

Systems based (for example) on tags and tag categories are faster, more expressive, easier to reason about, and can be constructed into arbitrary trees on the fly should the need arise. (They are thus also capable of presenting a hierarchical interface to a legacy application, so compatibility isn't an issue.)

0. https://fuchsia.googlesource.com/docs/+/dart-docs/dotdot.md

1. Because plan9 does a better job than unix of making all resources files, inability to access some subset of files is a stronger guarantee.

I disagree with everything you said because your tone is just wrong. Old APIs don't remove the need for new ones. New APIs don't remove the need for old ones. The existence of one API does not prevent the existence of another API. Phrasing this as an us vs them problem will just waste your time and fail to convince everyone else. Instead of telling everyone how wrong they are you should convince them how great the new thing is.

Java File doesn't expose POSIX semantics directly.

In fact, there are special derived classes to handle file system specific semantics, if one feels inclined to do so, but that doesn't mean they work all the time, as JVM runs anywhere.

pjmlp, I don't know how you can keep claiming stuff like this. Android has fopen and pthread and you are allowed to use them in your app.

fopen is part of ISO C, supported by NDK, and pthread is a special case.

https://developer.android.com/ndk/guides/stable_apis

> Note that on Android, unlike Linux, there are no separate libpthread or librt libraries. That functionality is included directly in libc, which does not need to be explicitly linked against.

Better learn how much POSIX Android actually allows.

> pthread is a special case

How's that? It's a posix api among many others which is implemented on android.

How about fork[0], which is one of the more maligned posix apis (as far as I know, no one has any big problems with pthreads). Or errno[1]. Lots of ugly garbage in android...

0. https://android.googlesource.com/platform/bionic/+/refs/head...

1. https://android.googlesource.com/platform/bionic/+/refs/head...

So what?

APIs that aren't part of NDK stable API contract are not allowed, and since Android 7 Google has started to implement security measures to kill processes that try to use private APIs, one of the reasons why termux is no longer.

Good luck using your beloved POSIX APIs and not being killed in random Android devices.

Thats a distinction without a difference.

According to this google result[1] open() / write() are officially part of posix, while fopen() is part of C. Whatever - that distinction misses the forest for the trees. Its the semantics of those methods that hold computing back. Not their syntax.

[1] https://www.mkompf.com/cplus/posixlist.html - I'd have read the spec itself but you have to buy it from IEEE. Blergh.

No it does not, a platform with ISO compliant C compiler is not required to support POSIX in any form.

By the way, since C11, there is no need for POSIX threads any longer.

C11 threads might be implemented on top of POSIX threads, or anything else that the compiler vendor thinks of.

Sorry; the mistake was mine in my earlier comment. I pointed to "the crufty parts of POSIX" in an effort to point vaguely to the UNIX filesystem abstractions - fwrite/write, socket fds, fsync / fsyncdata, as well as fork() and whatnot. I don't actually care about the POSIX spec itself, or how POSIX differs from C11 (or how any of that is wrapped by the equivalent methods in Java).

This caused a distraction from the point I was making - which is that there are other ways we can do computing that don't use this model for files at all. For example we could make file operations transactional, or make files semantically rich - like database objects. So files themselves aren't "buckets of bytes" that need to be parsed by each application which interacts with them. There's lots of other ideas in this idea space - but the yoke of millions of lines of legacy code makes it difficult to explore this space outside of toy programming environments. And I worry as a result we might be stuck with the unix model forever.

specification https://pubs.opengroup.org/onlinepubs/9699919799/functions/o...

I think there's a certain "hacker cred" that comes from using really user-unfriendly software. And that's cool, but at some point OSS communities are starting to realize that "ease of use" is a hugely important quality. If they don't, they won't keep up with closed-source alternatives, end of sentence.

Or, some itches just require more work to scratch than you can reasonably do on the weekend.

These things go in cycles. Way back in the day, it felt like everyone used sourceforge.

Being a bit older this is no different than seeing the 70's hippies generation that helped fighting the dictatorship, working in capitalist right wing companies.

Eventually other things in life are more relevant and all that idealism fades away.

Even Linux will eventually be replaced by something else, when all the kernel engineers that helped its adoption are gone.

It won't be tomorrow, but it will come.

> Even Linux will eventually be replaced by something else, when all the kernel engineers that helped its adoption are gone.

I disagree. Linux has reached critical mass, the biggest tech giants depend on it heavily and are the main contributors. If some new fancy subsystem, interface or syscall would benefit Google's workload, they will implement it and it gets merged since even of Google will be the only one using it, that automatically means it has millions of users. You come along with a not completely polished and thoroughly tested Lego mind storms usb driver for Linux today, you'd get laughed of the mailing list, because security and who will maintain that? I mean security is good and stuff, but Linux is a commercial product today and nothing a curious 16 yo can get involved with like in the early 2000s.

> It won't be tomorrow, but it will come.

I mean if you're talking decades here you're probably right but then again that also will hold true for Windows, Chrome, HTTP/3 and basically everything.

> You come along with a not completely polished and thoroughly tested Lego mind storms usb driver for Linux today, you'd get laughed of the mailing list

This is simply not true. Even the new N64 port got merged even though it's not very practical.

> because security

As long as your module is not enabled by default, there is little security concern with it.

> who will maintain that?

Well you of course. Having someone who maintains it is the biggest factor in deciding whether code will stay or whether it will go.

Yes I am talking decades and specifically about Linux, naturally other OSes will eventually share similar fate.

Check Android and maker distributions for how much gets merged upstream.

The only guarantee of the future is that it is unpredictable.

> The only guarantee of the future is that it is unpredictable.

Yet here you are making predictions...

I doubt Linux will fade away until there is some major paradigm change away from Van Neumann architecture. It has survived and become dominant over 30 years by constantly adapting and innovating.

The plethora of IoT FOSS OSes with MIT/BSD licenses already show where the train is going.

Those do target an entirely different class of devices / applications.

FOSS has always been plagued by the 80/20 rule. Most of it is garbage, of the remaining quality software most are no longer maintained, of the remaining maintained most are slowing in development, and of the very few left that are healthy and active, most are shepherded by a private company or two.

The only software that actually dies is closed source. And with it, all the money you spent on it.

FOSS will outlive us all.

There's plenty of dead FOSS. Anything that relies on a library or build toolchain that's hard to find or configure comes to mind.

Go spend some time trying to get RHIDE working, for instance. You're going to have to bring it back to life to do so.

And yet, closed source seems to run just fine in emulation.

Luckily, I can bring it back to life.

Good luck emulating! That emulator's probably based on FOSS. :)

It generally takes less effort to emulate ancient software than to bring ancient FOSS back to life. Sure, the emulator is FOSS, but that's fitting in the 80/20 rule just fine. There's plenty of broken, abandoned and dead FOSS emulators, too.

But if you wanted to, you could bring them back to life. That's the value.

With the emulator, first you need to write that emulator, and then you only get precisely that version of the software. After that, you're toast.

Sure, but I'd have a tough time finding proprietary software that I'd want to use that isn't adequately emulated. As for updating, well, I'm not going to be updating most FOSS, either.

Right now I can double-click an icon on my desktop that launches SimCity for Windows 3.1 inside of dosbox, and it works great. It didn't take much effort to get working, either.

I can't say the same for most dead FOSS that I've tried to resurrect. Usually I'll have to manage the outdated dependencies somehow, perhaps by writing a SHIM or somesuch; and probably significantly fiddle with the build system because Linux systems have changed significantly since the mid-90s.

It's a difference of hours versus days of effort. I've done both, but guess which I simply _haven't the time for_ now? I've got family and friends that need my attention moreso than a dead piece of FOSS no one but myself seems to care about.

Sure, you're obviously a popular person and your friends/family are always more important than updating software.

But if you wanted to, you _can_ update dead Foss. Can't update that copy of Simcity, can you. Nopers.

Not quite, there are ways. The Diablo mod community is an excellent example: before the debug symbols were found on the psx release, the common method was to inject instructions directly into the binary. Similarly, Fallout and the Infinity engine games have mods that patch binaries and replace DLLs.

Yes, that's right, certainly easier than having the source. Your friends and family must appreciate the time you saved them by injecting DLLS. You'd better hope you efforts don't get DMCA'd.

Summarizing, closed source projects die. At best you can run them in an elaborate museum (emulator) and at worse, you can attempt to Frankenstein's monster them by injecting DLLs.

Open source will outlive us all.

How many places does Doom run?

Bin patching won't get you DMCA'd, and it's really not so different than writing a shim nowadays. Tooling has come a long way.

Doom is a closed source game that was finished, polished, and then open sourced. Strange to use that as a FOSS example.

The FOSS-from-the-start examples would be Tux Racer, 0ad, and so on.

And yet, here we are running Doom on our toasters, refrigerators and watches.

I really liked the old Presto-based Opera. How useful do you think running an 8 year old browser will be today, emulation or not? ;-)

And the emulation argument can also be made for old open source software, so I don't see how that supports the argument for closed source.

Maybe I just got lucky, but so far I've only ever "lost" CS software, example see above, but never OSS.