"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.
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.
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.
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.
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!
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/).
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!
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.
> 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.
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.
>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.
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.
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.
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.
>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.
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.
> 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.
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.
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."
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.
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.
> 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.
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...
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.
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.
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.
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.)
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.
> 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.
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.
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.
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.
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.
> 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.
> 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.
> 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.
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.
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.
That's much too simplistic. For instance Linus also denounces C++ and programmers don't fall into line behind him on that front. He is influential, but could not have caused the monumental shift in version control without producing a phenomenal tool to do the job. Git largely won on its overall merit, despite having some obvious UI warts.
Eh, that's a bit reductionist. Git was developed by Tovalds because BitKeeper had shortcomings he kept grating against, and it really needed to be a DVCS for kernel development. So he created something that fit the kernel development needs well, and it happened to also fit the needs of other companies as well. That it was free and open source was icing on the cake. That Torvalds created it just meant that there was already a wide audience of people willing to consider it and give it a fair shake initially.
I'm sure it didn't hurt that Torvalds had many years of experience dealing with lots of the shortcomings of different version control systems and their shortcomings in what is probably one of the more extreme version control situations, and is also known for optimizing the hard parts of things.
It was really the perfect storm for good open source software. A highly skilled developer with massive amounts of domain experience that is highly motivated to solve the problem. What you often get in those situations is something that is an obvious step up from the status quo, at least of free offerings, and often matching the paid offerings if they are more advanced. If it wasn't Torvalds, it just would have taken longer to take over.
As you say, it can't be understated just how much of a conceptual leap git was.
It wasn't developed in a vacuum. And there were several interesting distributed open source version control systems around at the time. After moving on from CVS and Subversion, I tried using Arch (tla) for a project. It was interesting, but still tied to the old way of thinking of version control as a series of deltas, both in its conceptual model and in its storage implementation. In fact, its storage was a tarball of a "base revision" plus a series of patches. Checking out a branch meant unpacking the tarball and applying patches in sequence. It was distributed, and elegant in its own way, but it didn't make the conceptual leap which Linus took with git.
In contrast, the hash-based blob/tree/commit model of git was groundbreaking. The storage doesn't use deltas (except as an implementation detail--as an optimisation in pack files). Deltas are computed on demand. Operations on and synchronising between blob stores is simple and fast. That one change is what made git revolutionary. It opened the door for doing so much more with the version control system.
Still, others took that step around the same time, and the git interface is not what one would call intuitive. But for various reasons it had the momentum and took the crown. It's not perfect, but it's still an absolutely superb tool.
I feel like GitHub made a lot of hacking around and software development a lot more seamless too. Before GitHub, the average state of software development seemed a bit more clunky to me.
Github made _Github style_ development seamless--i.e. centralized source control, slick web UI instead of CLI focus, pull requests instead of e-mailed patches. It's one of many different ways to build software though and it's a fallacy to say the entire field of software development didn't move forward until it existed. For someone who has only known Github style development it's true, but for many projects (including some of the largest in the world like the Linux kernel, all of Google's internal code, etc.) Github style development isn't necessary.
> it's a fallacy to say the entire field of software development didn't move forward until it existed
I mean, like, it kinda did in some ways? I feel like GitHub's semi-centralized web UI and pull requests empowered a lot of people to engage in software development online that wouldn't otherwise. I think if it didn't, we wouldn't see value in GitLab and Gittea providing GitHub's accessibility in a more decentralized way.
One thing I prefer about Mercurial is that it doesn't have a separate staging area. To create a new commit in git you need to run `git add` followed by `git commit`. In Mercurial it's just `hg commit`. Furthermore, if you want to look at the diff in git sometimes it's `git diff` and sometimes you need to run `git diff --cached`.
Now, I'm sure there are antsy git users in this forum ready to reply about how great the staging area is because of `git add -p`. I would note that you can also do those things in Hg if you want. For example, the `shelve` command in Hg is analogous to `git stash -p`. If you want to commit only part of the changes you can shelve away the things that you don't want to commit for now. One thing I like about this workflow compared to the staging area is that if you run your test suite, the code that is being tested in your working directory is the same one that will be commited.
> Except that if you added a new file then "git commit -a" will miss it out.
Exactly like Mercurial, you mean? Try it if you haven't in a while: you have to call “hg add” to add a new file or you'll get “nothing changed” when you run "hg commit".
The reason why neither of them has a default “add everything in the current directory” mode is that this is how you end up with repositories containing temporary files, build artifacts, and secrets.
This is not a good example to base ”much better UI” claims on.
So everything that you modified since last commit will get committed regardless? I can't add logging to some file or manually override a config without it getting it committed as there is no staging? Doesn't sound like much of a selling point, unless I'm misunderstanding...
Tbh, I don't even know if it is true today. Circa 2008-2010, I think Mercurial was certainly better -- it was certainly better designed and easier for a newcomer to use.
I'm probably going to be wrong/off on some stuff, but this is what I remember from the old days:
* Mercurial had a better CLI by default -- it was closer to SVN, which made it easier to use, and it was designed so that you had one command that did one thing, whereas git was more flexible but you needed to remember a lot of option flags.
* Mercurial had better early GUI client support (this changed, but early on, I know this was a draw for me as a Mac user)
* I'm pretty sure Mercurial had better Windows support (I didn't use Windows so I can't speak to this, but I seem to remember this)
* Better documentation
But git has evolved a lot over the last decade plus. Not only did GitHub really change the game by creating a more social layer on how to contribute/use git (and yes, I realize GitHub != git, but it definitely helped introduce a lot more people to git), it had features that really honed in on some of the pain points git had compared to Mercurial.
Although BitBucket was sort of positioned as a GitHub for Mercurial solution, it never achieved the organic/viral adoption of GitHub. And when Atlassian dropped hg support last year, it was pretty much confirmation that git "won."
Other than Facebook, I can't think of any major companies that use Mercurial or major projects that use hg.
I used to be sad about this, because I felt hg was better designed, but I came to terms with the reality a long time ago. It is what it is, and version control is often something that network effects define. Use whatever you want for your projects, but git won.
Both were still very faster than the mainstream solution at the time that is Subversion. I don't think Git could achieve the domination comparable to today without Github for that reason.
Mercurial beats git in a fair bechmark on a large repository by now. As far as I know, no other DVCS received similar dedicated optimizations.
(Microsoft worked around git by shimming a fake file system driver below the local repository to make it scale enouth to cover the Windows codebase. It's all Windows exclusive and not part of git, so it doesn't really count).
I mean git is wildly popular because of GitHub, and probably that was something to do with it in the Rails community... a community that if anything is culturally the opposite of the kernel dev community (or at least very different). I don’t think any kernel dev influence had to do with it, even though it’s often stated as a fact.
No, even at the time of GitHub's founding Git was already the clear winner. Think about it, why did GitHub feel safe launching with only Git support, while its competitors (Google Code, Bitbucket, SourceForge) had support for multiple VCSs?
Disagree. Git wasn't the clear winner when GitHub launched - and in fact the entire category of distributed version control was still proving itself.
I remember the GitHub team investing huge amounts of effort into convincing people to use git and teaching them how to do it - one of the four co-founders (Scott) was dedicated to that effort full-time.
Not really, lots of folks were using mercurial with BitBucket which didn't support Git at the time. Bazaar and Launchpad were also pretty common. I remember at one point around 2009-2010 I was semi-regularly using CVS, Subversion, Mercurial, Bazaar and Git.
Its competitors didn't have support for multiple VCSes. Sourceforge was CVS only, Google Code did SVN (and maybe CVS?), Bitbucket was hg only _and_ later. Many of these were later forced to add git support (and google code added hg iirc), but tying your source code host to a single version system was the norm when github launched.
Um.. no it wasn’t. Git was a complete trash fire on Windows when GitHub was founded for one.
I started using git when I was working on embedded Linux professionally in 2005, witnessing the whole bitkeeper saga. I am keenly aware of the history of DVCS 15 years ago.
Meanwhile outside the bubble of academia and startup web devs in 2008, Windows was still by far the most widely used dev platform. I typically deployed Mercurial when I wanted to convince a wider technical audience others of the beauty of DVCS.
GitHub felt safe the same way Instagram (among many) felt safe deploying for iOS only, even when then Android had a larger user base. There are other factors at play, and it was not that git had some kind of major advantage in 2008. If anything mercurial had a slight edge.
But if anything in 2008, the wider DVCS market was still in its infancy.
It did. Torvalds had (has?) a lot of pull in dev circles, he's a sort of archetypal Dev Evangelist. Though I agree Github was the main reason. They polished the git experience and then promoted their platform a ton, which brought git with it.
Kind of — I started using Mercurial before using Git and found a number of things which were easier or only possible using Git. Using some of the plugins for things like rebase were the only time I've ever lost data in a version control system.
By the time they had addressed some of those gaps, almost all of the projects I used had moved to GitHub, which seemed to be far more of a driver than Linux.
If I remember correctly Mercurial also made some dubious decisions early on (which they later reversed) that hurt adoption, like no in-repo branches and no ability to change history.
This is a version control misfeature/bad practice.
It's almost the single version control system that has it as part of its regular commands (though others allow it, generally as part of an admin set of permissions and usually with super clear warnings not to do it).
And it's far from a reason why git won. Git won because it was written by Torvalds and every script kiddie dreams to be a Linux kernel hacker and because the Facebook for Code, Github, took off and it was based on git.
Heck, I'd "accuse" you of rewriting history right now :-))
Mercurial also made the really good decision to support Windows long before git was even functional there. I've got clients who have been using Mercurial on Windows for more than 10 years now. They email bundles to each other and have no problems, whatsoever, and don't even notice git. One quote: "Why would I want to go back to a central repository that I have to be connected to? That's stupid."
Most Windows users, sadly, are simply too backward to use anything that isn't tightly integrated into the Microsoft ecosystem. So, it never really helped Mercurial that much.
GitHub, however, was what drove git.
Unfortunately, Github is to source control as PowerPoint is to presentations. It works--but it's a dumbed-down default and nobody thinks about the fact that there are sometimes much better alternatives for your use case.
An actual textual report? Whiteboards? Overheads? Actual slides? Flip charts? Livecoding?
Powerpoint is optimized for marketing and not much else. It exists because of two reasons:
1) Most people actively suck at presenting something. Forcing them to put their presentation in Powerpoint-standard forces some level of organization on them.
2) A lot of business presentation IS marketing--and Powerpoint is fine for that.
The problem is that a lot of technical communication really doesn't fit into Powerpoint-standard (see: space-shuttle disasters for example). The problem is that now nobody knows how to do anything else and never even thinks about doing anything else.
Got it. I thought you were comparing to other software tools.
I'm a big fan of chalk talks for anything mathematical. I find it hard to stay engaged with slides, even if the presenter uses tricks like revealing one step at a time, annotations, etc.
Github wasn't created until 2008, and in those early days there were big limits on hosting (very limited number of repos per user, even public ones). The everything free, everything easy all you can eat buffet that you see on Github today is a much more recent change. Back in '05 almost everything OSS was on source forge and Google Code, both of which offered super easy hosting, discussions, etc.
Sourceforge was already in demise, it was slow etc. when was it that they started adding malware? Don't remember ... i however remember Chris Wnastrath travelling to europe even for relatively small developer events and sponsoring the beer events. Quite a good marketing
...
One advantage of mercurial is that it is less tied to a specific file format like git is. It is much easier to make a mercurial backend for a system which actually stores the code in a different way (for example a distributed data store).
There are multiple implementations, but the contents of the .git directory are essentially the API, which tightly constrains how it can be implemented.
Git didn't exist until Linus Torvalds sat down and hacked it out in a few weeks during 2005. I remember using SDL back in '99 to play with game development on Windows 98. So the short answer is, git wasn't even an idea in its creators head when SDL was around and thriving.
IMHO when you see a design decision that seems odd to you, it's a good opportunity to investigate the entire context around that design, rather than pepper the devs/issues/comment threads/etc. with pointed questions, "Why did you do X when Y is now clearly better??".
i would guess you are right, though, that at the point SDL chose Mercurial (I don't know when), git hadn't achieved the market domination over mercurial it now has.
Where I work Mercurial has been an option for some time now (no Git unfortunately) and coming from Git I must say I really love how it does some of its things:
- hg split: split a commit into as many different commits as you like using an interactive patch editor (you can fold/collapse hunks, can edit them textually, can select which lines of the hunk should be applied). It will automatically rebase all the commits on top of the commit being split, ofc
- hg histedit: a sort of "git rebase -i" where you get a list of commits that you can manipulate by reordering them, merging, dropping
- hg amend -i/commit -i: interactive commit or amending of a commit, it's using that awesome interactive patch editor I mentioned earlier to select what exactly gets committed/amended
- same for "hg shelve -i" (a sort of "git stash")
The closest thing in Git to that interactive patch editor was doing "git add -p" which is not as good.
Mercurial is used at Facebook, but it is heavily customized and goes through Phabricator. Just like Google uses Piper, which is “like Perforce” and goes through Critique.
I heavily use Magit on Emacs to edit my patches interactively. It is my favorite way to interact with Git.
I think Visual Studio Code has something of its own. Would be great to have that part of the Git command line, but I guess shouldn't be hard to make one, considering its already out there on so many IDEs.
I do this using magit. I’ve never split a commit directly (I’m sure its possible) but manipulate commits at the file/hunk/line granularity which I did not think was possible with git.
Of course, you could do these same things with git if you just recite this or that obscure sequence of ~~shell commands~~ demonic rituals. These are common and reasonable things for vcs users to want to do, and gits ux for them is a steaming pile.
I've been using lazygit [0] for a lot of use cases like this and it's been great. It's a terminal UI with a bunch of shortcuts. In particular, the partial commit is awesome, as is the ease of amending.
A couple others mentioned Magit which I think is similar.
FWIW I learned Mercurial before I learned Git, and SVN before that. Mercurial was great. I still think its commands made more sense than the Git ones, especially coming from SVN.
I'm sure they use a custom version of mercurial and still probably use git as well. But that's really interesting, never knew about this. Like another other commenter mentioned I also use magit in interactive mode but I'm going to give mercurial a try now.
I've briefly used Mercurial and found it to be slower than Git in large repos. Mercurial has the concept of changeset (similar to Perforce) where the changeset is actually stored, while Git's "changeset" is computed as needed from two commits. Branch in Git is clear and straight forward, and is easily malleable, while Mercurial's branch is part of the version storage and cannot be changed or removed.
My VC history includes RCS, CVS, Visual Source Safe, then several years with Subversion. Moving from svn, the hg CLI was more intuitive. I still don't understand git at all, beyond the basic "clone, pull, add, commit, push" commands.
Git branches and tags were independent features from the very start. It's true that branches were not stored in a separate directory, but that really wouldn't add much. There were tools to check out a branch into a separate working directory on the filesystem. And it was always straightforward to store branches in separate full repos too.
That is fine, but what git does not have is branches baked into the history of the repo like HG or svn does.
With git you can see this if you merge things back and forth then remove the branch names. There is no way to tell which commit was on was which branch. You just have the graph of commits.
This is not true of HG, it is always there baked into the history.
Yes, you're right. Although there are easy ways to mitigate this if it's actually important. Simply including the branch name in each commit message is simple enough, or disabling fast-forward merges so that each merge has its own separate commit and meta-data. Or even just not merging like that in the first place and using "feature branches" that are only ever merged back into the master branch, never the other way.
Mozilla uses Mercurial for Firefox code because Mercurial had much better Windows support that git (at the time Mozilla was moving off CVS back in ~2007). Some Mozilla developers prefer git and use git plugins (cinnabar) to talk Mozilla's Mercurial servers.
Because I can explain Mercurial's mental model to anybody. And I have--from the CEO to the secretary--pretty much anybody can understand Mercurial.
Git, not so much. The whole "staging" area is something that the vast majority of developers simply do not need and would be better off without. The UX of the commands is abysmal--commands that change what they do based upon whether the argument is a file or a directory? Are you insane?
I could go on and on and on ...
However, git has won. I keep my repos in Mercurial and transfer them out to Git for public consumption. :(
What’s wrong with the staging area? It’s probably my number one most used feature. I tend to have a lot of changes in my working directory. Some are actual code, some are temporary fixes or comments. Maybe even another unrelated fix I threw in. Staging area allows me to pick the parts/files/lines I want for a particular commit.
That is far more state than most people are comfortable keeping track of. Most people have "working" and "committed" and that's almost more than they can deal with.
Ever dealt with someone who has a specific breadcrumb trail for making changes to WordPress, for example? "Staging" is an extra set of steps to his breadcrumbs that can go wrong.
The staging area is useful to a small number of people like you in return for complicating the life of everybody else.
Is it really that much state? For example, the thing I am working on right this moment have the following changes:
1. I changed my environment URL because I need to test on a specific one.
2. My actual feature changes, couple of files and a hundred lines changed.
3. A bunch of debug print messages, some are intertwined within the changes in 2, and some are in other places.
I will stage most of things in 2, probably in multiple commits to group logically. Most of 1,3 will simply be discarded once I comment and test final version. 1, might stick around for the next features I work on.
I can not believe this is too much state, nor can I believe this is not a fairly common workflow for developers?
How would you do this without staging? Would you discard the temporary changes and commit, then possibly write them back manually?
—-
I appreciate the Wordpress example but I’m not familiar with it so it flies right over my head to be honest.
Changeset Evolution [1], which allows me to amend and rebase shared commits without co-workers hating me, even when they are building on top of the mutated commits.
combined with a large set of tools to tweak commits (i mostly use absorb, amend, split, fold, uncommit, pick), it is very nice to work with if you value a clean history.
there is also the very powerful revset DSL for finding revisions and/or files.
I've worked on SDL although I haven't contributed any code. Partly because it isn't convenient to contribute and partly because I felt that the work I did wasn't significant enough to merit jumping thru the hoops to contribute. The move to Github is a very welcomed change.
> One reason we hadn’t considered a move to GitHub before now is that this project has had a policy of owning all its infrastructure.
This is still a good policy to have. They've already done the work to migrate from mercurial to git so, the potential for moving to a forked gitlab or something like that is there. Personally I think that, especially if your doing open source, github is really the way to go here. Github has been great for open source.
I think GitHub is generally safe as long as you have an exit plan for when it's no longer the place you want to be. Know where you're moving your issues and actions if you decide you need to leave.
Why engage with a company that have proven themselves to be an enemy of Free Software? I'm not buying their "how do you do, fellow Linux users" facade.
Look, I don't know. Speculating seems like a pointless exercise, and I'm already being downvoted for not liking Microsoft enough. I think I'm just about done with this website.
SDL is a project with a long history, so let's pretend they move a backlog of 5,000 issues over to Github. Everything is great--now users can search, discuss, open, manage, etc. all these issues on a slick web UI. People are happy and things just work.
Now some years later there's a blog post from Github, "An update to our free tier" that outlines dramatic changes. It turns out Microsoft needs to make some changes to keep their shareholders happy with their returns. Now Github only allows 2,500 issues per repo on the free tier--you'll be wowed with slick graphs that show for 99.999% of users they'll never even know or notice this new limitation. People will post long comments on the Hackernews thread about how 2,500 issues ought to be enough for anybody and that Github/Microsoft actually love developers _more_ because they're willing to reduce the features than shut down the business.
And now SDL is in a bind.. a free project that generates no revenue now is facing a dilemma. Should they pony up real dollars to keep the history of their 25+ year old project? The cost of moving source control isn't trivial and is a huge ops burden that keeps the devs from doing real work... and cha-ching out comes the credit card, out goes a $100/mo then $200/mo etc, etc. charge.
This isn't some wild speculation, look at Microsoft products like Onedrive that clawed back huge free tiers of storage in the past. It's just an inevitability with commercial software that costs will rise and someone will be squeezed for money.
So the threat is some number of years down the line they may have to go back to paying to host and maintain the infrastructure themselves again? I'd take that deal.
It's probable that in that instance they could just pay for GitHub datacenter or whatever Microsoft chooses to name the new evil plan. But Microsoft has little reason to turn evil again (open-source projects generally have little money and won't spend it on source control/issues when there's a free competitor), as we're at a crossroads where nobody needs Microsoft software anymore (iOS/Android/Mac/Chrome OS for personal computing, Google/Amazon for cloud), so they need the advertising for their cloud. Therefore, $500K per year or thereabouts to host all of the open-source code on GitHub and provide some amount of CI minutes is worth it to get people to ask for GitHub/Azure at work.
It genuinely surprises the shit out of me that people haven't created a "middleware" layer that treats GitHub as its backend / source of truth, but everything gets routed through a custom domain. E.g., spin up this glorified reverse proxy on Heroku, and now example.com/bugs is really just example.github.io/bugs, which is a page with all its form actions pointing to the Heroku service acting as a go-between for managing github.com/example/whatever/issues with full backups, etc.
Microsoft is a completely different company than it was even just 5 or 10 years ago. Saying that MS is an enemy of open source is uninformed at best and idiotic at worse.
Do me a favor, look at Facebook [1], Apple [2], Amazon [3], Netflix [4] and Google [5]. Now tell me which one has more Open Source repos than MS [6]. I'll give you a hint... none of them. Sure, volume of open source repos may not be the best metric, but to say in 2021 they are enemies of open source with almost 4k open source repos is just dumb.
Hell, even the new MS terminal [7] is open source. They realized that FOSS isn't the enemy and is actually good for the tech industry at large.
And this, btw, is the KEY to show that if MS decides to be evil there's a LOT of motivated players that would happily step in with a new platform and take over.
The fact that Apple is trusting MS with their source code really should tell you that your open source project will be fine. What you'll want to watch out for is when these other competitors decide to abandon ship.
You're factually correct, but you've probably forgotten the "3 Es": "Embrace, Extend, Extinguish" [0]. Microsoft is a business and is therefore about maximizing profits. I'd rather not assume anything, especially not that they are somehow friendly to the OSS movement. Lets give it a few more years before we assume that OSS is something they are gonna do long term. Otherwise, it's like "free" google products; here today, gone tomorrow.
EEE is from a meeting in 1996 by someone who left the company in 2000. It's really hard for anyone to claim it represents the company today or even a decade ago.
You act as though Open Source is somehow mutually exclusive with profits and a sustainable business.
> Otherwise, it's like "free" google products; here today, gone tomorrow.
Respectfully, I disagree... google products are introduced as services, not open source and they shut them down often. If an OSS project is useful and has community support, you can always fork it.
>Microsoft is a completely different company than it was even just 5 or 10 years ago.
Counterpoint: No they aren't. Counting Git repos is totally nonsensical, and open sourcing their terminal is a meaningless gesture, but I guess that's enough to fool some people.
Microsoft has a very, very long history of being a shitty company. Fucking over DR DOS, fucking over Stac, war profiteering, patent trolling, up to the privacy dumpster fire that is Windows 10. That's just off the top of my head. And I've been around for all of it, so excuse me if I just don't fawn over Microsoft suddenly claiming to be the good guys now. Trust is hard to earn and easy to lose.
> Microsoft is a completely different company than it was even just 5 or 10 years ago. Saying that MS is an enemy of open source is uninformed at best and idiotic at worse.
Rather than fighting the target directly, they are embracing it at first; and this time, the target is open-source and the developers. They are doing it again and are targeting where the developers are: Hence their involvement with GitHub, Xamarin, Linux Foundation, Chromium (MS Edge), WSL 2, VS Code, TypeScript and Azure and it is working for them.
The company has not changed. Only the target has, and they are already embracing them and slightly started to extend.
Sounds like no amount of evidence will convince you, even with evidence that contradicts your opinion. The stuff you are talking about was the strategy for most big software vendors in the 90's/early 2000's. They sold software licenses and support.
If you look at current MS, it is all about services. Services do better when you have a larger addressable market and not embracing OSS will reduce who they can sell to, which is why they are going to.
VS Code is a perfect example, MIT License... OSS, wide support and well regarded.
I've tried to contribute to SDL a few times over the last couple of years as well. Never got a reply on any attempt whatsoever. Even getting a simple "rejected" label would've been nice.
After Wayland support was added, I was trying to add support for running SDL apps inside the "fullscreen shell" style compositors (compositors meant to nest other compositors or run one application fullscreen).
Found two bugs, reported them, sent patches. It was as easy as it gets. The idea that forking a repo, pushing changes to your own copy, then posting a PR is simpler than posting a diff on a bug tracker is bizarre.
When I moved my open source project to GitHub, contributions skyrocketed by roughly 10x. I attribute that to three things:
- contributors need to learn a single workflow to submit patches to any open-source project:fork and submit PR
- contributors already have a github account, so a significant barrier is removed for flyby contributions (no need to register a new user account to a mailing list / bugtracker / or both for each trivial or non-trivial fix.)
- network effects and improved visibility
Each of those may appear small by itself, but they combine into a significantly better experience for contributors.
Just be aware that "boomer rant" creator made one of the most highly successful and used game development libraries in history. I would wager 75% of the games in your steam library use or depend on SDL in some way. Almost certainly most of the games from your childhood that you cherish and love have used SDL too. You should probably be thanking them for creating something that gave you joy at one time, and giving it away for free...
I see where the SDL author is coming from, but is it really that hard to get local GitLab instance running? Or even just using GitLab? I saw other replies about how GitHub has a network of open source developers, but that didn't bother the SDL author before, and I don't see why it is bothering him now.
If open-source organisations like RedoxOS, GNOME, GTK (Who use their own self-hosted instances of GitLab), etc are able to self-host, surely SDL can too, thanks to the new technologies out there that automates this.
When your entire project is sitting on GitHub like nearly everyone else out there and something goes wrong, don't be surprised when one has to tweet at the CEO of GitHub if the repository is falsely flagged for 'some reason' or if your GitHub actions, pull requests and packages are experiencing a degraded service.
You missed a key point that the SDL author raised--they're tired of maintaining all the ancillary software around a project. Every minute they waste troubleshooting a CI/CD failure, bugzilla limitation, etc. is a minute taken away from working on their actual project. And as this is an OSS project of love and not their full-time job it's even more infuriating for them to waste their free time janitoring services.
Gitlab self hosted is fantastic, but it's far from 'set it and forget it' maintenance. There's significant technical overhead to keeping it updated, secure, migrating its database with major releases, scaling out the underlying hardware as project demands increase, etc. Moving to a hosted platform like Github solves those problems and gets them back to being productive on their project.
The authors are really lamenting that they have to give up control of their project's source code and tie themselves to a new commercial offering (something that history has shown us over and over will inevitably lead to more technical debt in the future as platforms fade--just ask any former sourceforge, google code, etc. user).
I don't blame them--it's sad to see that the state the art in self-managed OSS source code never progressed much beyond "become a domain expert in server operations and kludge together a suite of tools with wildly different UI, management and operations; also, documentation is non-existent or wildly out of date".
This is sad. It is as if we are going backwards, from an open source solution they decided to move to a closed ecosystem. They could at least use gitlab instead...
Exactly. You have new solutions like GitLab, Gitea and Docker which can automate this stuff for you and it is yours and you own everything. Didn't stop RedoxOS, wireguard and GNOME from self-hosting.
The point is that they didn't want to deal with self-hosting anymore. I think he makes some valid points in the article re: owning all of your own infrastructure - there is something to be said for that.
But it is so much more than just Git hosting.
> "It’s not just Bugzilla. It’s the wiki, the mailing lists, the quaint little Mercurial web interface. The little open source thing that we rely on but no one is working on and probably has security holes in it. It’s all janky, and it causes developer friction. It causes it for Sam and I, and we’re old Unix command line cowboys, so for those that expect computers to treat them like computers do in 2021–with slick UIs and without cronjobs that occasionally fail until Ryan rolls along to restart a service over ssh–it was becoming untenable."
I don't see GNOME (GitLab), FreeBSD, Blender (Phabricator) or even wireguard complaining about their issue tracking management here. I have seen many examples of FOSS/FLOSS devs choosing a self-hosted solution over GitHub.
For example, ReactOS's source is hosted on both GitHub and they have a self-hosted backup which they control in case GitHub goes down. If this was SDL being GitHub, so far they don't have a backup plan. Pull requests, issues and their GitHub actions will not work and they would need to wait for GitHub to restore their services or do 'anything'.
I prefer 'Owning all of your own infrastructure' or even being on GitHub and having a self-hosted backup of your own infrastructure just in case GitHub goes down. But moving everything and being 'all in on GitHub' is the ridiculous quest to centralize everything on a platform you don't own because everyone else is doing it.
This is poignant for me, for reasons that have nothing to do with the technical merits of git vs mercurial, or github/Microsoft specifically as a company.
> It’s not just Bugzilla. It’s the wiki, the mailing lists, the quaint little Mercurial web interface. The little open source thing that we rely on but no one is working on and probably has security holes in it. It’s all janky, and it causes developer friction. It causes it for Sam and I, and we’re old Unix command line cowboys, so for those that expect computers to treat them like computers do in 2021–with slick UIs and without cronjobs that occasionally fail until Ryan rolls along to restart a service over ssh–it was becoming untenable.
The bar has been raised for developer tools in 2021. The OP recognizes it, it's true.
The bar has been raised by hosted products, usually corporate/proprietary products, that companies often give out for free at least for some and at least initially.
It is very hard to compete with this with "DIY" systems. It's just a fact. You have to spend a whole bunch of time on your tooling infrastructure, and you still don't really get close. As an open source developer you'd rather be spending it on the product, not the tooling infrastructure.
(It's way easier to get people to volunteer to contribute to the product, often because they are scratching their own itch, then it is to get people to volunteer to do "ops" stuff for you. The ops has diverged into somewhat of a different skillset. Who wants to do ops for free for open source products? Some people, sure, but not nearly as much as there is demand, or as there would be demand if they were all "self-hosting" everything instead of using the oh-so-easy commercial hosted offerings...)
And then a lot of those open source products themselves are just janky and poorly maintained, there isn't enough labor being put in.
We could have imagined a different world. This is not the world the open source afficianados of 20 years imagined or wanted.
But... this is where we are. Nobody wants to spend all that time trying to keep the janky self-hosted system running, when it's so much clunkier and you are probably making it harder for new contributors at the same time, and you'd rather it just were done for you so you can focus on the code. Even when you know what you are giving up in terms of control or the free software world we'd like to be contributing to.
The author is writing knowing all of this, knowing exactly what is being given up, but seeing it as the best option to get the open source product (SDL) developed as high-quality as possible, and regretting that this is where we find ourselves.
You don't have to compete with hosted systems that have dedicated teams of developers and operations shipping features though. Linus Torvalds manages the development of the entire Linux kernel (millions of lines of code, thousands of contributors) with just an email client, text editor, and git CLI.
I will say too don't expect these hosted services to free you of operations burden. On the contrary you're even less connected and more at risk of operations burdens when these hosted services are facing issues. When Github actions CI/CD is acting up, or the hubot issue manager isn't working, or the release artifact store doesn't have the bits you expect, etc. your entire project grinds to a halt and it's not easy (by design) to eject out and work around them. Projects that depend heavily on all these hosted services are going to find over time that they need to buffer and insulate themselves from these centralized, single points of failure. It's just a different kind of operations burden.
Why would someone want to contribute to a bullshit boot camp homework exersize? That seems literally the least likely thing to get any collaborators on.
But, sure, if you don't care about making the development tools something that anyone other than you find convenient, than you can of course just pick whatever you find convenient, nobody is going to stop you.
That's still not a mailing list with patches for most people, but if it is for you, that's great, nobody's going to tell you you can't do that.
The OP said he was switching because he thought their current systems were taking too much of his time to maintain, and were still too hard to use for other collaborators.
You seem to be trying to tell him he's wrong and those systems didn't really take too much of his time, and he actually didn't have any other potential collaborators anyway.... it's a weird argument.
I was saying that the few contributions I've ever gotten on any of my projects are basically people completing bullshit codecamp exercises. The contribution is low impact and the contributor never returns. The actual act of submitting the contribution was a larger percentage of the effort than the actual change itself.
> Why would someone want to contribute to a bullshit boot camp homework exersize? That seems literally the least likely thing to get any collaborators on.
You've misunderstood, the coding boot camp assigns homework, and sometimes that homework is: "Contribute to an open source project!" This usually takes the form of something like a pull request to "Fix typos in README" or something otherwise insignificant. GP is just saying that however you release your FOSS project, you're unlikely to get even that tiny level of outside contribution, so using "no one will contribute" as an argument against a mailing list isn't very persuasive. The argument that mailing lists suck, perhaps more so, but GP didn't opine on that.
That works out well for you that you and Linus and others find that system to have just as good user experience as the sort of hosted systems far more projects are using, but the majority of current actual and potential developers do not.
I think you are unlikely to persuade them to change their minds with an argument in an HN comment, but you can keep trying!
You can self host Gitlabs. I did that a few years back and it's quite nice. It has a similar feature set to Github. Gitlab these days is a perfectly good alternative and it's popular as well though not nearly as popular as Github.
Self hosted gitlab is nice, until you realize that you can get the same functionality for free from Github and any second of devops spent on your self hosted thing is technically just money down the drain. In our case, I got a little worried about our flaky backups and the fact we were using a single node vm in AWS to host this. The fix would have been increasing cost by spending on more vms and devops. Instead, we switched to Github. And that was before they had free plans with unlimited repositories and developers. We actually paid for it and saved money (not to mention stress). These days it's a no-brainer because at 0$ per month you get source hosting, CI via github actions, and all the rest. I'd actually gladly pay for it before considering other options. But it seems MS has decided that's not worth the effort.
The thing with OSS is that it's not the world you want but the world we all build together. Plenty of people that want stuff but rarely enough that go out there and actually build it, persist with building it, find the right people to collaborate with to get things done, and then collectively deliver results. That takes a platform to collaborate on and for better or worse that platform is Github and git.
Mercurial just never got of the ground as a mainstream solution and fell behind as Git got more popular. It had a shot as long as it was the third option (along with subversion and git) on Sourceforge before Github was a thing. But then Github happened and offered a nice UI for pull requests and that turned out to have been the killer feature developers wanted and needed.
It seems to me people don't give enough thought to the possibility of hosting themselves elsewhere, and only "mirroring" onto GitHub for the presence effect.
GCC does this (edit: LLVM half-does-it, in that issues are handled elsewhere). So does MonetDB and I'm sure there are a million more examples.
This doesn’t solve the issues of stuff like Bugzilla, plus these mirror only offer a fraction of what GitHub truly offers (issues, CI, pull requests with nice interface).
Basically, if you think your home grown infra sucks, a GitHub mirror doesn’t address that.
Neither does hosting your code on GitHub. Its issues mechanism is very limited compared to Bugzilla (or JIRA or whatnot). As for CI - GitHub itself doesn't give you CI. Travis does and they've gone mostly/wholly commercial. etc.
I'm just saying you don't need to be fully on GitHub to be visible on GitHub.
Actually LLVM has their official repository there, not a mirror as GCC[0]. But they still do reviews and merges outside of github. linux kernel project does a similar thing.
The "linux kernel project" does not have its official tree on github, Linus just has a read-only mirror there.
You can confirm this by reading one of the bot replies to a PR [0]:
Linux kernel development happens on mailing lists, rather than on GitHub - this GitHub repository is a read-only mirror that isn't used for accepting contributions. So that your change can become part of Linux, please email it to us as a patch.
I know that the discussions and reviews happen on mailing lists and believed that this github repo is the official one there all these patches go, but apparently it's not.
This sounds like an indictment of git. It was supposed to make it easier for OSS developers to collaborate, but it turns out that you become bound to a monopoly like Microsoft. Why can't git users develop an easy to maintain server, like svn and fossil did, for example?
Not sure this is an indictment of git. It still works great without central servers (unlike svn) but GitHub just makes it nicer for most people. And with GitHub the wiki is just a git repo so I’m guessing it would be easy to take with you. Not sure how the GitHub issues work so that would be a pain to move away from.
This is not about git. Git is probably easier to set up and maintain than svn. This is about everything else github offers like issues, pull requests, discussions, wiki, ....
Read-up on the history of git. It was not designed to be a new panacea of OSS development. It was designed to keep the Linux kernel development running smoothly after their commercial source code host dropped them--that's it.
Running a git server is actually very easy, just run the git-daemon command: https://git-scm.com/book/en/v2/Git-on-the-Server-Git-Daemon This is actually easier than running something like Gitlab that requires setting up a database, a reverse proxy, or even an entire runtime environment like Kubernetes, etc.
You're falling into a trap of conflating git with Github. Github took the mechanics of git and built a slick, centralized, commercial source code host on top of it. They made a social network that engaged users and gamified writing code. Lots of folks are working on similar commercial and open source variations of the same. But in all those cases git is just a part of the tech and not tightly coupled to the success (or failure) of them.
There are great "easy to maintain" servers like Gitea. I run it myself to mirror some things that I would not want to lose.
But self hosted Gitea and other alternatives won't scale easily (and would not be cheap). The biggest attraction to Github for me is the user base and scale, not the UI/UX.
> 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.
I don't like this, everything is moving to GitHub which has already done some questionable things. I don't care for Microsoft and I don't believe them when they claim they "heart" Linux.
Yeah, libsdl2 is built around more modern rendering devices and drawing APIs, and supports far fewer (but more popularly used) platforms. And is vastly faster on those platforms than SDL1.2 used to be, since it’s playing to the strengths of those modern devices, instead of fighting against them the way that SDL1.2 did.
Do note that libsdl2 can emulate framebuffer-style “I just want to splat pixels to the screen”-style program architectures just fine using “streaming” textures [0], but that’s not going to help you if it doesn’t support your platform.
If you need broader platform support and/or are running on low-power devices, then libsdl1.2 is still around and supported, and is probably a more appropriate choice for such projects.
A bit sad that they gave up on Mercurial, if they really think is better for their needs; although having used Subversion, Mercurial, Bazaar, git, ...; I kind of like when it is just git. Not because is better or I like it better, but switching between tools in this case was PITA because of the subtle differences of almost the same commands.
> And the way that most people personally like using git is via GitHub.
I don't get it. In which way? I use GH for pull requests, may be issues? There's a lot more of my git day to day than that. I don't think you really use git via GH.
What will be SDL's official GitHub repo? The article had no link. Seems like an important item to include. https://github.com/libsdl is an unofficial mirror and github.com/sdl/ is something unrelated.
Good, I remember wanting to submit a tiny patch but then giving up because I couldn't be bothered to make sense of the system they were using(and I use mercurial for my personal stuff).
269 comments
[ 4.6 ms ] story [ 235 ms ] threadThis 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.
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.
https://gitlab.kitware.com/users/sign_in
or
https://gitlab.xiph.org/users/sign_in
You can sign up with your GitHub account.
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.
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.
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!
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)
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.
> 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.
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.
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
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.
I gitlab significantly harder to use and more error-prone than Github
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.
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.
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.
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.
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.
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.
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.
* Jewish Zionists
* Mentally ill (trans)
* Feminists (anti male brainwashed commie cunts)
* Censor people
and exlude White straight males that are skilled/qualied/experenced over non white people
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.
Bad UX is subjective. Money doesn't change that.
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.
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.
http://contemporary-home-computing.org/RUE/
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.
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.
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.
Except that's exactly what human behavior does.
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 use mkcert[2] for this but it's still fiddly.
[1] https://letsencrypt.org/docs/certificates-for-localhost/
[2] https://github.com/FiloSottile/mkcert
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."
Why bother installing k3s and whatever deployment-tool-du_jour it is these days, when dropping some files on a host is good enough?
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.
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
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
For sure, many of us don't use OS where POSIX has any relevant meaning.
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.
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?
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.
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...
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.
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.
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.
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.
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.
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.
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.
IoT is even more of a niche than desktop.
And, I think you underestimate the amount of software written in c, directly against posix.
Since then, language runtimes have spared me the effort, and I am not alone.
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 will outlive us all.
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.
Good luck emulating! That emulator's probably based on FOSS. :)
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.
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.
But if you wanted to, you _can_ update dead Foss. Can't update that copy of Simcity, can you. Nopers.
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?
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 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.
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.
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.
Check Android and maker distributions for how much gets merged upstream.
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.
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.
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.
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.
To those who use mercurial over git, why?
I'm sure it didn't hurt that Torvalds had many years of experience dealing with lots of the shortcomings of different version control systems and their shortcomings in what is probably one of the more extreme version control situations, and is also known for optimizing the hard parts of things.
It was really the perfect storm for good open source software. A highly skilled developer with massive amounts of domain experience that is highly motivated to solve the problem. What you often get in those situations is something that is an obvious step up from the status quo, at least of free offerings, and often matching the paid offerings if they are more advanced. If it wasn't Torvalds, it just would have taken longer to take over.
It wasn't developed in a vacuum. And there were several interesting distributed open source version control systems around at the time. After moving on from CVS and Subversion, I tried using Arch (tla) for a project. It was interesting, but still tied to the old way of thinking of version control as a series of deltas, both in its conceptual model and in its storage implementation. In fact, its storage was a tarball of a "base revision" plus a series of patches. Checking out a branch meant unpacking the tarball and applying patches in sequence. It was distributed, and elegant in its own way, but it didn't make the conceptual leap which Linus took with git.
In contrast, the hash-based blob/tree/commit model of git was groundbreaking. The storage doesn't use deltas (except as an implementation detail--as an optimisation in pack files). Deltas are computed on demand. Operations on and synchronising between blob stores is simple and fast. That one change is what made git revolutionary. It opened the door for doing so much more with the version control system.
Still, others took that step around the same time, and the git interface is not what one would call intuitive. But for various reasons it had the momentum and took the crown. It's not perfect, but it's still an absolutely superb tool.
I mean, like, it kinda did in some ways? I feel like GitHub's semi-centralized web UI and pull requests empowered a lot of people to engage in software development online that wouldn't otherwise. I think if it didn't, we wouldn't see value in GitLab and Gittea providing GitHub's accessibility in a more decentralized way.
A lot of software development got a lot better. Yes, software development was possible before GitHub, but it lowered the barrier to entry a lot.
Curious as how it's "better". I have in all honestly only ever used git.
Now, I'm sure there are antsy git users in this forum ready to reply about how great the staging area is because of `git add -p`. I would note that you can also do those things in Hg if you want. For example, the `shelve` command in Hg is analogous to `git stash -p`. If you want to commit only part of the changes you can shelve away the things that you don't want to commit for now. One thing I like about this workflow compared to the staging area is that if you run your test suite, the code that is being tested in your working directory is the same one that will be commited.
Or `git commit -a` — and if you're making commits that frequently it'll be in your shell history anyway.
Git's UI is full of little sharp edges like that. You get used to them, but it's just needlessly fiddly to start with.
Exactly like Mercurial, you mean? Try it if you haven't in a while: you have to call “hg add” to add a new file or you'll get “nothing changed” when you run "hg commit".
The reason why neither of them has a default “add everything in the current directory” mode is that this is how you end up with repositories containing temporary files, build artifacts, and secrets.
This is not a good example to base ”much better UI” claims on.
I'm probably going to be wrong/off on some stuff, but this is what I remember from the old days:
* Mercurial had a better CLI by default -- it was closer to SVN, which made it easier to use, and it was designed so that you had one command that did one thing, whereas git was more flexible but you needed to remember a lot of option flags. * Mercurial had better early GUI client support (this changed, but early on, I know this was a draw for me as a Mac user) * I'm pretty sure Mercurial had better Windows support (I didn't use Windows so I can't speak to this, but I seem to remember this) * Better documentation
But git has evolved a lot over the last decade plus. Not only did GitHub really change the game by creating a more social layer on how to contribute/use git (and yes, I realize GitHub != git, but it definitely helped introduce a lot more people to git), it had features that really honed in on some of the pain points git had compared to Mercurial.
Although BitBucket was sort of positioned as a GitHub for Mercurial solution, it never achieved the organic/viral adoption of GitHub. And when Atlassian dropped hg support last year, it was pretty much confirmation that git "won."
Other than Facebook, I can't think of any major companies that use Mercurial or major projects that use hg.
I used to be sad about this, because I felt hg was better designed, but I came to terms with the reality a long time ago. It is what it is, and version control is often something that network effects define. Use whatever you want for your projects, but git won.
(Microsoft worked around git by shimming a fake file system driver below the local repository to make it scale enouth to cover the Windows codebase. It's all Windows exclusive and not part of git, so it doesn't really count).
I remember the GitHub team investing huge amounts of effort into convincing people to use git and teaching them how to do it - one of the four co-founders (Scott) was dedicated to that effort full-time.
I started using git when I was working on embedded Linux professionally in 2005, witnessing the whole bitkeeper saga. I am keenly aware of the history of DVCS 15 years ago.
Meanwhile outside the bubble of academia and startup web devs in 2008, Windows was still by far the most widely used dev platform. I typically deployed Mercurial when I wanted to convince a wider technical audience others of the beauty of DVCS.
GitHub felt safe the same way Instagram (among many) felt safe deploying for iOS only, even when then Android had a larger user base. There are other factors at play, and it was not that git had some kind of major advantage in 2008. If anything mercurial had a slight edge. But if anything in 2008, the wider DVCS market was still in its infancy.
By the time they had addressed some of those gaps, almost all of the projects I used had moved to GitHub, which seemed to be far more of a driver than Linux.
This is a version control misfeature/bad practice.
It's almost the single version control system that has it as part of its regular commands (though others allow it, generally as part of an admin set of permissions and usually with super clear warnings not to do it).
And it's far from a reason why git won. Git won because it was written by Torvalds and every script kiddie dreams to be a Linux kernel hacker and because the Facebook for Code, Github, took off and it was based on git.
Heck, I'd "accuse" you of rewriting history right now :-))
Most Windows users, sadly, are simply too backward to use anything that isn't tightly integrated into the Microsoft ecosystem. So, it never really helped Mercurial that much.
GitHub, however, was what drove git.
Unfortunately, Github is to source control as PowerPoint is to presentations. It works--but it's a dumbed-down default and nobody thinks about the fact that there are sometimes much better alternatives for your use case.
Powerpoint is optimized for marketing and not much else. It exists because of two reasons:
1) Most people actively suck at presenting something. Forcing them to put their presentation in Powerpoint-standard forces some level of organization on them.
2) A lot of business presentation IS marketing--and Powerpoint is fine for that.
The problem is that a lot of technical communication really doesn't fit into Powerpoint-standard (see: space-shuttle disasters for example). The problem is that now nobody knows how to do anything else and never even thinks about doing anything else.
I'm a big fan of chalk talks for anything mathematical. I find it hard to stay engaged with slides, even if the presenter uses tricks like revealing one step at a time, annotations, etc.
Took a bit to dig up with Google their 2011 announcement that they're now also supporting Git. https://bitbucket.org/blog/bitbucket-now-rocks-git
hg added stuff to match git's workflow but it isn't hg's default. The tutorials for hg all teach a decidedly inferior workflow to git.
ps: did a 20 person year long project in hg first, next project was git. Not going back if I can help it.
[1] https://www.mercurial-scm.org/wiki/GitExtension
IMHO when you see a design decision that seems odd to you, it's a good opportunity to investigate the entire context around that design, rather than pepper the devs/issues/comment threads/etc. with pointed questions, "Why did you do X when Y is now clearly better??".
https://en.wikipedia.org/wiki/Mercurial#History
i would guess you are right, though, that at the point SDL chose Mercurial (I don't know when), git hadn't achieved the market domination over mercurial it now has.
[1]: http://forums.libsdl.org/viewtopic.php?t=6047 [2]: https://discourse.libsdl.org/t/sdl-in-subversion/13289
edit: I can’t remember where, it was when I was researching fossil, but there are some good reads on why Linus created git and the history of VCSs.
Where I work Mercurial has been an option for some time now (no Git unfortunately) and coming from Git I must say I really love how it does some of its things:
- hg split: split a commit into as many different commits as you like using an interactive patch editor (you can fold/collapse hunks, can edit them textually, can select which lines of the hunk should be applied). It will automatically rebase all the commits on top of the commit being split, ofc
- hg histedit: a sort of "git rebase -i" where you get a list of commits that you can manipulate by reordering them, merging, dropping
- hg amend -i/commit -i: interactive commit or amending of a commit, it's using that awesome interactive patch editor I mentioned earlier to select what exactly gets committed/amended
- same for "hg shelve -i" (a sort of "git stash")
The closest thing in Git to that interactive patch editor was doing "git add -p" which is not as good.
[1] https://engineering.fb.com/2014/01/07/core-data/scaling-merc...
Ubuntu might still use Bazaar.
Pijul is very promising: https://pijul.org/ and https://pijul.org/manual/why_pijul.html
Merging A in B should yield the same result as the opposite with Pijul, etc.
I think Visual Studio Code has something of its own. Would be great to have that part of the Git command line, but I guess shouldn't be hard to make one, considering its already out there on so many IDEs.
Same with histedit, that’s in magit as well.
A couple others mentioned Magit which I think is similar.
FWIW I learned Mercurial before I learned Git, and SVN before that. Mercurial was great. I still think its commands made more sense than the Git ones, especially coming from SVN.
0: https://github.com/jesseduffield/lazygit
One thing I liked, that most do not is they had both git style branches in the form of tags, but mercurial had "real" branches.
With git you can see this if you merge things back and forth then remove the branch names. There is no way to tell which commit was on was which branch. You just have the graph of commits.
This is not true of HG, it is always there baked into the history.
https://hg.mozilla.org/
Git, not so much. The whole "staging" area is something that the vast majority of developers simply do not need and would be better off without. The UX of the commands is abysmal--commands that change what they do based upon whether the argument is a file or a directory? Are you insane?
I could go on and on and on ...
However, git has won. I keep my repos in Mercurial and transfer them out to Git for public consumption. :(
Ever dealt with someone who has a specific breadcrumb trail for making changes to WordPress, for example? "Staging" is an extra set of steps to his breadcrumbs that can go wrong.
The staging area is useful to a small number of people like you in return for complicating the life of everybody else.
1. I changed my environment URL because I need to test on a specific one.
2. My actual feature changes, couple of files and a hundred lines changed.
3. A bunch of debug print messages, some are intertwined within the changes in 2, and some are in other places.
I will stage most of things in 2, probably in multiple commits to group logically. Most of 1,3 will simply be discarded once I comment and test final version. 1, might stick around for the next features I work on.
I can not believe this is too much state, nor can I believe this is not a fairly common workflow for developers?
How would you do this without staging? Would you discard the temporary changes and commit, then possibly write them back manually?
—-
I appreciate the Wordpress example but I’m not familiar with it so it flies right over my head to be honest.
[1]: https://www.mercurial-scm.org/wiki/ChangesetEvolution
combined with a large set of tools to tweak commits (i mostly use absorb, amend, split, fold, uncommit, pick), it is very nice to work with if you value a clean history.
there is also the very powerful revset DSL for finding revisions and/or files.
> One reason we hadn’t considered a move to GitHub before now is that this project has had a policy of owning all its infrastructure.
This is still a good policy to have. They've already done the work to migrate from mercurial to git so, the potential for moving to a forked gitlab or something like that is there. Personally I think that, especially if your doing open source, github is really the way to go here. Github has been great for open source.
I'm not asking in bad faith here. If there are such dangerous I would very much like to know them.
Now some years later there's a blog post from Github, "An update to our free tier" that outlines dramatic changes. It turns out Microsoft needs to make some changes to keep their shareholders happy with their returns. Now Github only allows 2,500 issues per repo on the free tier--you'll be wowed with slick graphs that show for 99.999% of users they'll never even know or notice this new limitation. People will post long comments on the Hackernews thread about how 2,500 issues ought to be enough for anybody and that Github/Microsoft actually love developers _more_ because they're willing to reduce the features than shut down the business.
And now SDL is in a bind.. a free project that generates no revenue now is facing a dilemma. Should they pony up real dollars to keep the history of their 25+ year old project? The cost of moving source control isn't trivial and is a huge ops burden that keeps the devs from doing real work... and cha-ching out comes the credit card, out goes a $100/mo then $200/mo etc, etc. charge.
This isn't some wild speculation, look at Microsoft products like Onedrive that clawed back huge free tiers of storage in the past. It's just an inevitability with commercial software that costs will rise and someone will be squeezed for money.
Do me a favor, look at Facebook [1], Apple [2], Amazon [3], Netflix [4] and Google [5]. Now tell me which one has more Open Source repos than MS [6]. I'll give you a hint... none of them. Sure, volume of open source repos may not be the best metric, but to say in 2021 they are enemies of open source with almost 4k open source repos is just dumb.
Hell, even the new MS terminal [7] is open source. They realized that FOSS isn't the enemy and is actually good for the tech industry at large.
[1] https://github.com/facebook [2] https://github.com/apple [3] https://github.com/amzn [4] https://github.com/Netflix [5] https://github.com/google [6] https://github.com/microsoft [7] https://github.com/microsoft/terminal
The fact that Apple is trusting MS with their source code really should tell you that your open source project will be fine. What you'll want to watch out for is when these other competitors decide to abandon ship.
[0]: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
> Otherwise, it's like "free" google products; here today, gone tomorrow.
Respectfully, I disagree... google products are introduced as services, not open source and they shut them down often. If an OSS project is useful and has community support, you can always fork it.
Counterpoint: No they aren't. Counting Git repos is totally nonsensical, and open sourcing their terminal is a meaningless gesture, but I guess that's enough to fool some people.
Microsoft has a very, very long history of being a shitty company. Fucking over DR DOS, fucking over Stac, war profiteering, patent trolling, up to the privacy dumpster fire that is Windows 10. That's just off the top of my head. And I've been around for all of it, so excuse me if I just don't fawn over Microsoft suddenly claiming to be the good guys now. Trust is hard to earn and easy to lose.
Rather than fighting the target directly, they are embracing it at first; and this time, the target is open-source and the developers. They are doing it again and are targeting where the developers are: Hence their involvement with GitHub, Xamarin, Linux Foundation, Chromium (MS Edge), WSL 2, VS Code, TypeScript and Azure and it is working for them.
The company has not changed. Only the target has, and they are already embracing them and slightly started to extend.
If you look at current MS, it is all about services. Services do better when you have a larger addressable market and not embracing OSS will reduce who they can sell to, which is why they are going to.
VS Code is a perfect example, MIT License... OSS, wide support and well regarded.
After Wayland support was added, I was trying to add support for running SDL apps inside the "fullscreen shell" style compositors (compositors meant to nest other compositors or run one application fullscreen).
Each of those may appear small by itself, but they combine into a significantly better experience for contributors.
When your entire project is sitting on GitHub like nearly everyone else out there and something goes wrong, don't be surprised when one has to tweet at the CEO of GitHub if the repository is falsely flagged for 'some reason' or if your GitHub actions, pull requests and packages are experiencing a degraded service.
[0] https://news.ycombinator.com/item?id=22663627
[1] https://news.ycombinator.com/item?id=26066365
Gitlab self hosted is fantastic, but it's far from 'set it and forget it' maintenance. There's significant technical overhead to keeping it updated, secure, migrating its database with major releases, scaling out the underlying hardware as project demands increase, etc. Moving to a hosted platform like Github solves those problems and gets them back to being productive on their project.
The authors are really lamenting that they have to give up control of their project's source code and tie themselves to a new commercial offering (something that history has shown us over and over will inevitably lead to more technical debt in the future as platforms fade--just ask any former sourceforge, google code, etc. user).
I don't blame them--it's sad to see that the state the art in self-managed OSS source code never progressed much beyond "become a domain expert in server operations and kludge together a suite of tools with wildly different UI, management and operations; also, documentation is non-existent or wildly out of date".
But it is so much more than just Git hosting.
> "It’s not just Bugzilla. It’s the wiki, the mailing lists, the quaint little Mercurial web interface. The little open source thing that we rely on but no one is working on and probably has security holes in it. It’s all janky, and it causes developer friction. It causes it for Sam and I, and we’re old Unix command line cowboys, so for those that expect computers to treat them like computers do in 2021–with slick UIs and without cronjobs that occasionally fail until Ryan rolls along to restart a service over ssh–it was becoming untenable."
For example, ReactOS's source is hosted on both GitHub and they have a self-hosted backup which they control in case GitHub goes down. If this was SDL being GitHub, so far they don't have a backup plan. Pull requests, issues and their GitHub actions will not work and they would need to wait for GitHub to restore their services or do 'anything'.
I prefer 'Owning all of your own infrastructure' or even being on GitHub and having a self-hosted backup of your own infrastructure just in case GitHub goes down. But moving everything and being 'all in on GitHub' is the ridiculous quest to centralize everything on a platform you don't own because everyone else is doing it.
> It’s not just Bugzilla. It’s the wiki, the mailing lists, the quaint little Mercurial web interface. The little open source thing that we rely on but no one is working on and probably has security holes in it. It’s all janky, and it causes developer friction. It causes it for Sam and I, and we’re old Unix command line cowboys, so for those that expect computers to treat them like computers do in 2021–with slick UIs and without cronjobs that occasionally fail until Ryan rolls along to restart a service over ssh–it was becoming untenable.
The bar has been raised for developer tools in 2021. The OP recognizes it, it's true.
The bar has been raised by hosted products, usually corporate/proprietary products, that companies often give out for free at least for some and at least initially.
It is very hard to compete with this with "DIY" systems. It's just a fact. You have to spend a whole bunch of time on your tooling infrastructure, and you still don't really get close. As an open source developer you'd rather be spending it on the product, not the tooling infrastructure.
(It's way easier to get people to volunteer to contribute to the product, often because they are scratching their own itch, then it is to get people to volunteer to do "ops" stuff for you. The ops has diverged into somewhat of a different skillset. Who wants to do ops for free for open source products? Some people, sure, but not nearly as much as there is demand, or as there would be demand if they were all "self-hosting" everything instead of using the oh-so-easy commercial hosted offerings...)
And then a lot of those open source products themselves are just janky and poorly maintained, there isn't enough labor being put in.
We could have imagined a different world. This is not the world the open source afficianados of 20 years imagined or wanted.
But... this is where we are. Nobody wants to spend all that time trying to keep the janky self-hosted system running, when it's so much clunkier and you are probably making it harder for new contributors at the same time, and you'd rather it just were done for you so you can focus on the code. Even when you know what you are giving up in terms of control or the free software world we'd like to be contributing to.
The author is writing knowing all of this, knowing exactly what is being given up, but seeing it as the best option to get the open source product (SDL) developed as high-quality as possible, and regretting that this is where we find ourselves.
I will say too don't expect these hosted services to free you of operations burden. On the contrary you're even less connected and more at risk of operations burdens when these hosted services are facing issues. When Github actions CI/CD is acting up, or the hubot issue manager isn't working, or the release artifact store doesn't have the bits you expect, etc. your entire project grinds to a halt and it's not easy (by design) to eject out and work around them. Projects that depend heavily on all these hosted services are going to find over time that they need to buffer and insulate themselves from these centralized, single points of failure. It's just a different kind of operations burden.
If you started a FOSS project today with a mailing list wherein contributors mail you git patches, you would get exactly 0 contributors.
And maybe that's ok, maybe this is your baby, and if someone wants to push code to it they can learn how to email a patch to you.
But for many developers, they do want to have some of the load taken off of them by other developers. They want to reap that benefit of OSS.
Oh, you'll get complaints, that much is very achievable. But actual contributions? Even simple, bullshit code boot camp homework exercises? Good luck.
But, sure, if you don't care about making the development tools something that anyone other than you find convenient, than you can of course just pick whatever you find convenient, nobody is going to stop you.
That's still not a mailing list with patches for most people, but if it is for you, that's great, nobody's going to tell you you can't do that.
The OP said he was switching because he thought their current systems were taking too much of his time to maintain, and were still too hard to use for other collaborators.
You seem to be trying to tell him he's wrong and those systems didn't really take too much of his time, and he actually didn't have any other potential collaborators anyway.... it's a weird argument.
You've misunderstood, the coding boot camp assigns homework, and sometimes that homework is: "Contribute to an open source project!" This usually takes the form of something like a pull request to "Fix typos in README" or something otherwise insignificant. GP is just saying that however you release your FOSS project, you're unlikely to get even that tiny level of outside contribution, so using "no one will contribute" as an argument against a mailing list isn't very persuasive. The argument that mailing lists suck, perhaps more so, but GP didn't opine on that.
I think you are unlikely to persuade them to change their minds with an argument in an HN comment, but you can keep trying!
Self hosted gitlab is nice, until you realize that you can get the same functionality for free from Github and any second of devops spent on your self hosted thing is technically just money down the drain. In our case, I got a little worried about our flaky backups and the fact we were using a single node vm in AWS to host this. The fix would have been increasing cost by spending on more vms and devops. Instead, we switched to Github. And that was before they had free plans with unlimited repositories and developers. We actually paid for it and saved money (not to mention stress). These days it's a no-brainer because at 0$ per month you get source hosting, CI via github actions, and all the rest. I'd actually gladly pay for it before considering other options. But it seems MS has decided that's not worth the effort.
The thing with OSS is that it's not the world you want but the world we all build together. Plenty of people that want stuff but rarely enough that go out there and actually build it, persist with building it, find the right people to collaborate with to get things done, and then collectively deliver results. That takes a platform to collaborate on and for better or worse that platform is Github and git.
Mercurial just never got of the ground as a mainstream solution and fell behind as Git got more popular. It had a shot as long as it was the third option (along with subversion and git) on Sourceforge before Github was a thing. But then Github happened and offered a nice UI for pull requests and that turned out to have been the killer feature developers wanted and needed.
GCC does this (edit: LLVM half-does-it, in that issues are handled elsewhere). So does MonetDB and I'm sure there are a million more examples.
Basically, if you think your home grown infra sucks, a GitHub mirror doesn’t address that.
I'm just saying you don't need to be fully on GitHub to be visible on GitHub.
[0] https://github.com/llvm/llvm-project
You can confirm this by reading one of the bot replies to a PR [0]:
Linux kernel development happens on mailing lists, rather than on GitHub - this GitHub repository is a read-only mirror that isn't used for accepting contributions. So that your change can become part of Linux, please email it to us as a patch.
[0] https://github.com/torvalds/linux/pull/805#issuecomment-5933...
Thanks for the correction.
Running a git server is actually very easy, just run the git-daemon command: https://git-scm.com/book/en/v2/Git-on-the-Server-Git-Daemon This is actually easier than running something like Gitlab that requires setting up a database, a reverse proxy, or even an entire runtime environment like Kubernetes, etc.
You're falling into a trap of conflating git with Github. Github took the mechanics of git and built a slick, centralized, commercial source code host on top of it. They made a social network that engaged users and gamified writing code. Lots of folks are working on similar commercial and open source variations of the same. But in all those cases git is just a part of the tech and not tightly coupled to the success (or failure) of them.
But self hosted Gitea and other alternatives won't scale easily (and would not be cheap). The biggest attraction to Github for me is the user base and scale, not the UI/UX.
OMG I feel heard. I feel like this is me.
A hosted version is also available: https://foss.heptapod.net/public
Works like gitlab, but on top of Mercurial. Use it myself and it works perfectly.
* pull the project on a whim
* Is Anti merit
* Anti free speech
* Is anti white
What could go wrong
Do note that libsdl2 can emulate framebuffer-style “I just want to splat pixels to the screen”-style program architectures just fine using “streaming” textures [0], but that’s not going to help you if it doesn’t support your platform.
If you need broader platform support and/or are running on low-power devices, then libsdl1.2 is still around and supported, and is probably a more appropriate choice for such projects.
[0]: http://wiki.libsdl.org/MigrationGuide#If_your_game_just_want...
> And the way that most people personally like using git is via GitHub.
I don't get it. In which way? I use GH for pull requests, may be issues? There's a lot more of my git day to day than that. I don't think you really use git via GH.
Presumably you'll know then.