Hacker News Reader

Comment by rockooooo | Hacker News Reader

"So in moving it to GitHub, we’re finding that a lot of things are just nicer because a large paid staff of engineers is working on it every day. And I grew up during the heydey of the Free Software Foundation, so I know this is a trap, but I’m tired and don’t have the energy to be a server admin for something that’s held together with scotch tape and prayers when I’m really supposed to be writing OpenGL code."

This seems to sum up the biggest pain point that drives people away from OSS. Not knowledge, not skill, not price, but the total experience of a nice piece of software that lets you get the work you actually want to get done... done.

View on HN

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.

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.

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

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

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.

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

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.

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?

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

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.

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.

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

Can you give some examples of the fantastic failures?

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.

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

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.

> 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

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[

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?

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.

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

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.

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

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.

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

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.

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

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.

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.

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.

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

Depends on the specific software. Plenty of Free and Open Source software 'just works' just about perfectly. Firefox and Notepad++ for instance.

In the specific instance of GitHub, I have to agree it's nicer and better polished than the alternatives, but I'd also say the Free Software alternatives (GitLab, SourceHut, etc) are catching up, and are already usable. Hosting your own GitLab instance gives you a far nicer solution than an old school solution like SourceForge.

> we’re finding that a lot of things are just nicer because a large paid staff of engineers is working on it every day

People are paid to work on various Free and Open Source software projects, including Firefox and Notepad++, and most famously, the Linux kernel.

I wouldn't say GitHub is nicer or more polished than GitLab. Both have similar feature set ( GitHub did well to catch up after years of stagnating, with Actions, docker/package repositories, etc) even if GitLab still has an advantage there, good ecosystems ( GitHub has more tools integrating with it than GitLab), and both work and are fully polished.

I've been running Gitea myself, and honestly I've found it more polished than Github in general. Never really causes me issues either.

>This seems to sum up the biggest pain point that drives people away from OSS. Not knowledge, not skill, not price, but the total experience of a nice piece of software that lets you get the work you actually want to get done... done.

This is why I continue to be fascinated by FreeBSD, I don't use it for much but when I do, what I'm trying to do almost always works right out of the box.

My point is that is all comes down to packaging, which is done everywhere. Docker is so popular because debian-style/rpm-style/etc packaging systems and the maintainers of said packages do a pretty uneven job of making things work without luck or fiddling (or having to have package specific knowledge about how to do something obvious). Docker doesn't really do a great job either, but it has a different set of problems and having the old ones gone is nice.

What are you using FreeBSD for? I imagine it's quite good at some things, but isn't that range kind of limited? You need to have the precise set of hardware that's well supported and then use it for precisely the thing it supports well.

In my experience of using FreeBSD for twenty or so years, for the most part, if it's a major vendor and a few years old then it's supported.

It is true that FreeBSD is slower to get new hardware support but I actually like that, it's one of the major reasons why things just work in FreeBSD. You put the work in upfront, select the right hardware and FreeBSD will serve you well for years with very little effort.

They aren't chasing some imaginary/political/technological dream they are delivering high quality software using tried and tested methods.

> What are you using FreeBSD for? I imagine it's quite good at some things, but isn't that range kind of limited? You need to have the precise set of hardware that's well supported and then use it for precisely the thing it supports well.

No you don't? You can throw it on a random commodity desktop and expect it to work. I imagine laptops are harder if you want suspend etc. - it feels pretty similar to how Linux was a few years ago. (If anything support for old hardware tends to be better than Linux because they don't keep changing the kernel interfaces, so a barely-maintained driver from 5 years ago is probably still usable). You don't need to use it in some particular way, it's fine for a daily-driver desktop or home server. I used mine for a little bit of everything until recently - ordinary KDE desktop, fairly normal web hosting environment running some stuff I wrote in Python with WSGI, database server, home VPN server... all the usual stuff.

I have come to the conclusion that the only reason why things like flatpak and snap exist is because the ergonomics for creating and maintaining .deb packages is so awful.

Pacman FTW

Not just that. Application sandboxing is important too. The traditional unix approach of any process run by your user can access all your files is at odds with modern security concerns.

Sandboxing is an issue, though I would argue that sandboxing and packaging are orthogonal concerns, so a new format should not have been needed just for the sandboxing use case. That said, if you are developing sandboxing from scratch pretty much no sane person would choose to use the .deb workflow as their UI for packaging.

I found out when experimenting with it that Snap inherited most of the .deb cruft. As someone less experienced in .deb packaging, I found it very confusing with all the Ubuntu-specific package separations and archaic requirements. If I don’t have a man page, for instance, I shouldn’t have to create one and learn format naggles to meet an aggressive linter’s specs.

Wonder why they did not pick GitLab since it is significantly better for FOSS ideals and has the same niceness of GitHub

My guess is the network-effect. If you want more contributions Github is the platform to pick for your project. Good or bad it is the de facto standard platform for OSS projects with a huge pool of potential developers.

That's it. Back in the day that's what was great about source forge. Now it's github. Many people already have an account there so you significantly lower the bar for people to get involved with patches, bug reports etc.

If a project has self hosted infra and wants me to sign up to their Bugzilla I think twice before doing so.

And if github really turns to shit because Microsoft shows their true evil face you can just move platforms again.

Check out

https://gitlab.kitware.com/users/sign_in

https://gitlab.xiph.org/users/sign_in

You can sign up with your GitHub account.

https://gitlab.gnome.org/users/sign_in even allows you to login with a GitLab account. Which ironically isn't possible on these other two.

I don't think this is it. I think it's more about (1) marketing and discoverability and (2) ease for current maintainers.

Getting new contributors is overrated for OSS unless they are an exceptional contributor (like if a big org were to contribute).

Main incentive is getting more consumers of the project (increase popularity) and making it more convenient for current team.

I agree but think it's a bit of both and depends on the project. I e.g. don't think SDL needs more exposure. Everyone in game dev knows SDL.. many game engines / frameworks are built on top of it.

> has the same niceness of GitHub

Debatable. As a previous paid customer, I have never been a fan of GitLab, I've always found it slow, buggy and of confusing design language. YMMV.

I think what was meant is that at least parts of GitLab are FOSS and can be installed locally which in not the case with github.

But installable locally kinda defeats the whole point of this move? And as someone who manages a small gitlab instance, it's not always set it and forget it unfortunately.

No, it doesn't because Gitlab.com exists. Installability is an insurance policy.

GitLab team member here. For anyone considering a similar move, I encourage you to check out our GitLab for Open Source program: https://about.gitlab.com/solutions/open-source/

For academics, it take a few minutes to get a github academic account. For gitlab you have to write justifications and wait and wait, to maybe get it...

Yep, our university has GH Enterprise and refuses to “procure” (as it requires the central body to agree to the ToS) free Gitlab for academia as “another” git solution. Our project team on Gitlab cannot get into that program for academics because they only let one application per institution. I understand each side but still don’t see how we can solve this problem. Would love to find a way!

Update: seems like Gitlab removed the requirement of having one application per institution from https://about.gitlab.com/solutions/education/join/, I just applied again.

I use GitLab at work. My experience is that it has more features that work less well. There are a bunch of comments pointing to a GitLab issue to explain stupid hacks in our CI/CD pipelines.

Thanks, @PurpleFoxy! I tend to agree with @Fileeditview about the network effect and how GitHub has done a great job of helping OSS projects with visibility.

Like john_cogs, I'm also a GitLab team member, and am part of the Community Relations team. I run the GitLab for Open Source program. I joined about a year ago and am really impressed by how fast GitLab moves forward. We have a lot of awesome stuff coming up to make the product, and our community, even better.

With a release each month, we use our momentum to make big strides in the DevSecOps space -- so people can rest assured that we'll keep improving quickly! We like to build along with our users, and believe everyone can contribute to our product roadmap, and all aspects of our company (e.g. see https://about.gitlab.com/direction/).

For OSS projects considering a move, check out this GitHub vs GitLab Decision Kit: https://about.gitlab.com/devops-tools/github-vs-gitlab/decis... It outlines some of the key points to consider when evaluating a move.

I'm also happy to answer any questions about the GitLab for Open Source program john_cogs mentioned below (https://about.gitlab.com/solutions/open-source/). It's a great deal in that OSS projects get 50,000 CI minutes for free along with our top tier in SaaS or self-managed. Feel free to reach out to opensource@gitlab.com with any questions!

Best two things GitLab needs to do:

1. Fix their bugs instead of new features (ex: rebase fails 9/10 time for us) 2. Fix their pricing (ex: $99 per user is way to expensive and that is the only plan that allows free users)

Github Actions is already a good reason to use Github over Gitlab. Also the pricing is much better with Github even for Github Enterprise. All kind of normal features are behind a $99/user/month fee.

I don't understand why things like vulnerability scanning needs to cost $80 per user more and then at the same not supporting multiple report files as artefacts in monorepo.

I think they implicitly addressed this:

> So we’re moving to servers we don’t control, which does make me nervous, but the argument goes like this: Microsoft owns GitHub, and it’s highly unlikely Microsoft is going to go bankrupt anytime soon. If Microsoft pulls the plug on GitHub, it’s not just SDL that would be in trouble, it would be the entire open source ecosystem, so interested parties would move fast to help you migrate to somewhere else…right?

Gitlab Inc. is dramatically more likely to go out of business that Microsoft, and Gitlab generally is dramatically more likely to have significant outages than Github.

Sorry but GitLab is utterly horrendous from a developer's perspective compared to GitHub. It's massive enterprise bloatware (like most Atlassian products for example) that is nigh unusable without an entire team of people to manage it. My company uses it and it causes me problems almost every other day. Things that should "just work" never do.

Further when something gets reported to GitLab they automatically close old issues and things never get fixed. One outstanding huge issue is that if you mark certain files as owned by a specific team for example, it won't notify the teams to come in and actually review the code. There's options that say they do it, but it never works. (The notification system in general is an utter mess.)

GitLab is an example where everything is chopped up into tiny pieces and nothing works across different parts of the codebase. I don't envy anyone that works for GitLab as just the look of the code shows what a mess the backend must be.

GitLab team member here. We have Code Owners [1] and recently introduced Merge Request Reviewers [2]. Our team is working on the author-review handoff [3] as part of their work to improve the overall merge request reviewer experience [4]. I'm sure they would appreciate any detailed feedback you could share on the epics linked below.

1 - https://docs.gitlab.com/ee/user/project/code_owners.html#int...

2 - https://about.gitlab.com/releases/2020/12/22/gitlab-13-7-rel...

3 - https://gitlab.com/groups/gitlab-org/-/epics/5074

4 - https://gitlab.com/groups/gitlab-org/-/epics/1823

Code Owners don't work. If you assign a team as the owner it doesn't do anything unless the team itself is also added to the project. Further it doesn't seem to properly notify people either. We've fallen back to emailing everyone manually whenever a pull request is submitted.

I have the exact opposite experience, and it just works in ~90% of the cases, ~5% being behind a feature gate, 4% behind a paid tier, and 4% bugs.

It's easy to manage either via Helm or omnibus packages, and does a ton of things well enough. It still has significantly more features than GitHub.

> has the same niceness of GitHub

I gitlab significantly harder to use and more error-prone than Github

I just wish they would invest in the code review aspect of their tools. It’s pretty trash compared to competitors like reviewboard or phabricator (haven’t used Jira or Gitlab recently so can’t comment on those). A big missing feature is the ability to easily upload a stacked diff. Also the whole pull request thing is confusing - why not just use the commit and automatically populate title/summary + figure out which branch I’m likely to merge in to so that there’s a 1 click button to create the review (or push to origin/pr/branch_name to create the review from git cli)

at least on Github, if your branch only has one commit, it will use the commit to automatically populate title and summary. And recently pushed commits show up on top of the repo page with a one-click button to open a PR :) (or you can go to the "branches" page to do this as well)

It does not prepopulate in my experience (or if it does, not reliably). And I literally said I want an easy hit command line way to just push to a special branch name to have the pull created.

You’re answer is the stereotypical answer of telling the user to adapt to the tools instead of improving the UX (not to mention completely ignoring my point that GitHub doesn’t support stacked diffs). GitHub has a lot of advantages and has maintained their community but they lack pretty badly in some ways on the usability of their UX flow/feature set for power users. This isn’t necessarily accidental or a wrong decision since they might be prioritizing the broader dev community that isn’t familiar with more opinionated dev workflows and they’re solving the Ux for 90% of PRs. I still think there’s a way to strike that balance better and I hope they do so so that I don’t hate my life whenever I’m forced to use GitHub.

Reply on news.ycombinator.com