"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.
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.
For better or for worse, this is nothing new. It is a symptom of the fact that the FSF and other FOSS organizations have displayed a fantastic failure of technical leadership for over 3 decades. The political leadership has not been bad, but if you go back and dig through the history of open source you will see that there have been multiple repeated failures by the supposed thought leaders to provide the equivalent level of technical excellence that is required to compete.
Making the lives of developers of free software easier has rarely if ever been on the list of priorities for many of the core projects.
> It is a symptom of the fact that the FSF and other FOSS organizations have displayed a fantastic failure of technical leadership for over 3 decades.
I agree that many FSF/GNU projects have made horrible technical choices, but I don’t think that’s really the root cause here. The reality is that good software requires an enormous amount of skilled labor to create and maintain, and the FSF and other OSS orgs can only muster a small fraction of the engineering hours that a mid-sized for-profit software company could.
In addition, good user-facing software requires more than just good engineering - you need good UX, product direction, etc. Sometimes the creator or maintainer of an OSS program will have the good fortune to be reasonably good at all of these, but it’s very rare, and there aren’t nearly as many UX designers or product managers looking to contribute to open source as there are developers. Even if someone did want to help in this role, the developers on most projects would probably ignore them.
>Even if someone did want to help in this role, the developers on most projects would probably ignore them.
This is the lion's share of the problem, I suspect. OSS projects are driven by the people who write the code, and they don't take orders, and they don't massively value making things easy to use - or even necessarily have much connection with what that means. Current computing is such a pain in the ass that we've basically selected for inhuman levels of persistence and patience, and placed a large cultural value on those traits to boot. "Read the docs", we say. "Use the source", we say.
We don't have any idea how many human factors experts are out there, willing to help, because there's no process for them to contribute beyond "submit a pull request" - and even then, a purely UI tweak will meet with huge resistance. The UI expert is going to have to be a diplomat as well.
It's particularly interesting, because the rise of GNU is because it was an overall better set of tools than what Unix vendors shipped (HP-UX, IBM AIX, Sun OS, SGi Irix...).
The age of web changed all of that. Instead of being stuck on your computer with whatever tools you could obtain for it, you could now access centrally-maintained, quality webservices.
The FSF realized the freedom risk that centrally-maintained services posed, and created stuff like the AGPL to address it, but there just isn't as much leverage for that to take off like the GPL did.
Stallman's (and the FSF's) view on services is that it's like paying a plumber. The plumber isn't violating any of your freedoms by using non-free tools in their repair work, but it is unfortunate. This is a pragmatic view, because Stallman needed to grapple with continuing riding public transportation, even as they relied on non-free software, so an arbitrary line was drawn in the sand, one that barely made sense in the 80s and only continued to become more bizarre as computers became more and more networked.
This line has very bizarre consequences: FSF-supported hardware prefers closed-source firmware to be fused into ROM rather than upgradeble, the theory being that manufacturers shouldn't have more freedoms than the user. My favorite story was a laptop recommended by the FSF went from being "free" to "non-free" because an engineer found an undocumented protocol to upload new firmware to memory that the FSF thought was fused shut. These are the weird results that emerge when extrapolating extreme fundamentalist social policies far beyond their breaking point.
The FSF and Stallman do not care about the AGPL that much, they are far more worried about non-free software running on your own machine, like non-free JavaScript. Otherwise, Stallman couldn't ethically ride the T.
FWIW Stallman's stance was always that freedom is more important than technical excellence and that he'd rather use and promote a technically inferior product that respected users' freedoms than one that was technically superior but came with shackles.
Which is one of the reason's Stallman's ideas are fundamentally flawed as if there's a better product available even if it's only free as in beer, people will use it over the worse one, from the end user's perspective.
In the worldview of Stallman, your argument is analogous to saying that advocating for democracy is flawed because if an authoritarian regime or slave society provides a better product, people will choose it over worse democratic ones.
To Stallman, your counter-argument is a non-sequitur. His goal is maximizing user freedom. UX may be one dimension of user freedom, but at best it's secondary to certain prerequisite freedoms, such as the freedom to modify code so you can independently improve it, perhaps by improving UX for yourself and your community.
Many people sympathetic to Stallman, but more utilitarian, might argue that in the long term, user freedom is necessary for achieving optimal utility (e.g. UX, etc). And getting there might require short-term sacrifices in superficial aspects like UX.
> 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 fully agree about the skills gap, but I think the reason behind it is more that server administration has come to feel unapproachable, with an air of "better leave that to the experts", along the same lines as "don't roll your own crypto" (but less extreme) or how some people wouldn't dare run electrical wires in their homes.
Why run your own server, and keep it patched, and keep it secure, and configure the firewall, and all that stuff which spells doom if you get it wrong... when you can use some cheap or free service that does all the hard stuff for you?
I'm curious how much of this shift is purely because these tools really are better, or how much is due to an intentional marketing effort to make the DIY approach seem bad/unsafe/difficult/fraught with peril. I guess at some point it's a self-reinforcing flywheel. People think DIY is hard, so they actively avoid it, and tell their friends "running servers is hard, don't do that."
> My experiences, especially more recently, have been shocking in how little the average software developer knows about /very basic/ server administration.
I used to know quite a bit of that stuff, had a series of jobs doing it. I gradually moved from C89 to modern c++ over the course of about 25 years. Easy stuff, when you use it daily. But when it's not my job to do server admin, that stuff evolves too fast to stay on top of. For me it's not a high horse, rather, a wagon that I fell off a long time ago
Sure, and I'm not advocating to build a Rube Goldberg device, unless it's purely for learning purposes. But why go to great lengths (and expense) to avoid having to SSH into a server for your personal projects when you could run them on a Raspberry Pi or a $5/mo droplet?
The issue isn't that people need more than a LAMP stack, it's that for some reason software developers in the 2020s are scared to or think it's beneath them to install a LAMP stack of their own.
When you're a kid, tinkering is exciting. When you turn 30, you just want your software and tools to work. Janitoring your computer is not fun when it's in the way of your actual day job.
My worry is that this has bad long term implications.
Modern computing environments aren't very good, and most of the core abstractions haven't changed / improved since the 80s. Those core abstractions have so much stuff built on top of them now that they're very difficult to change. You used to be able to make a usable operating system in a month or two if you knew what you were doing. Now a simple web browser takes 20m+ lines of code to make. Its out of the hands of anyone with less than $1bn or so to spend - and at that scale the only real contributors are big tech companies. Except for some small features like io_uring and device drivers, linux is developed as if its already feature complete.
So I worry - will we ever replace the crufty parts of POSIX[1]? Will we ever have operating systems and software that can properly take advantage of NVMe and Optane memory[2]? Will we ever have desktop computers which sandbox software by default like my phone does, so I don't have to trust every program, npm library and rust crate on my computer with my data? Will there ever be a desktop class UI library which works across all my devices, or are we doomed to waste 90% of our computer hardware keeping electron + javascript fast-ish?
I'm worried these ships have sailed, and our grandchildren are destined to inherit a computing experience of electron, + more CSS.
In the 90s people would iterate on this stuff by just hacking linux and submitting patches. Now thats really hard because of how tall we've made our mountains of code. By the time you've climbed one mountain, you're halfway through your career. I mean, how many kernel hackers out there are also good at making user interfaces? How many people with frontend experience are even capable of hacking on linux? Its impossible to improve the interfaces between our systems without a holistic understanding. And thats becoming an increasingly rare commodity.
[1] Eg fsync(), and in my opinion the filesystem abstraction as a whole.
> 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.
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.
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.
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.
> 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.
> 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.
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.
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.
>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.
> 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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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!
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)
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.
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'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).
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.
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.
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.
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.
>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.
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.
> 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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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 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'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.
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'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 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.
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.
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.
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 :-))
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.
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.
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
...
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 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.
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.
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.
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...
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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).
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.
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?
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.
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, ....
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 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.
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 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.