[zokier]

Personally I find this far more worrisome signal of the health of foss ecosystem than the quibbles between elastic and amazon.

To me the idea of software "by hackers for hackers" and scratching your own itch has always been one of the key attractions in FOSS ecosystem, but somehow now our itches seem to have outgrown our ability to scratch then. Doing almost anything yourself feels impractical these days.

This is also why I like sourcehut, it represents to me sort of downshifting movement in the world that seems to be so very overspeeding. But I do feel that sr.ht does need certain almost monkish attitude to be satisfied with the austere facilities.

[hyperion2010]

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.

[alexhutcheson]

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

[dTal]

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

[matheusmoreira]

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/

[fartcannon]

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

[pjmlp]

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

[fartcannon]

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

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

[SummerlyMars]

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.

[pjmlp]

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

[dTal]

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?

[AceJohnny2]

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.

[Jasper_]

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.

[badsectoracula]

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.

[mlindner]

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.

[wahern]

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.

[Firehawke]

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.

[mlindner]

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

[Jasper_]

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.

[cdmckay]

Can you give some examples of the fantastic failures?

[tristor]

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

[lazypenguin]

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

[pabs3]

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.

[brigandish]

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

[rys]

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.

[pwdisswordfish6]

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

[dceddia]

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

[klyrs]

> 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

[dleslie]

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?

[tristor]

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.

[Jasper_]

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.

[josephg]

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

[Jasper_]

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

[pjmlp]

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

[moonchild]

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.

[pjmlp]

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?

[moonchild]

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.

[josephg]

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

[Jasper_]

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.

[ketzo]

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.

[madeofpalk]

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

[stock_toaster]

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

[pjmlp]

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.

[iforgotpassword]

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

[pantalaimon]

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

[pjmlp]

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.

[dingaling]

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

[pjmlp]

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

[pantalaimon]

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

[dleslie]

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.

[fartcannon]

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

FOSS will outlive us all.

[dleslie]

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.

[fartcannon]

Luckily, I can bring it back to life.

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

[dleslie]

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.

[fartcannon]

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.

[iforgotpassword]

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.