Oh man. I would immediately apply for jobs at all the major mainframe companies, as well as try and get into the Apollo Guidance Computer group at MIT. I’d also love to work on the early calculators.
The issue with the premise is that despite me not being the greatest programmer now, in 1960 I’d be so far ahead of the curve. Imaging bringing object-oriented stuff into ALGOL or FORTRAN? Or giving lectures on concepts taken from POSIX/UNIX etc.? Assuming people bought into it, you’d be able to move the field forward so quickly, and make so much money.
Couldn’t agree more. When GitHub was bought by Microsoft, I migrated all my personal repos to GitLab, and since then I’ve never really had any reason to switch back. Stuff like CoPilot just seems unethical to me, and GitLab being open-source is awesome. I do have a small self-hosted Gogs server; the only reason I chose Gogs over GitLab is just how resource-hungry GitLab can be for small collaborative groups. It scales well, I’m sure, but if you’ve just got 4 or 5 users it makes sense to use a lightweight server. Hell, for a few years I even just ran a git “server” with no front-end at all. Just pushing directly to repositories. If I wanted to create a new one I’d ssh in and make a –bare repo, and then push to it.
Addressing what others have said: I don’t get the Pull Requests thing either. It seems like a great way to manage contributions to public, open-source projects. Especially if you get many small contributions from a large number of people, with a small core group of developers, the amount of time it saves everyone really does add up. But, if you don’t want to support GitHub but want to contribute to projects on there, emailing git-formatted patches is a thing. I mean, that’s how the Linux team still does it, right? I don’t have much experience using git this way, but I have done some work manually emailing diff/patch stuff and if git integrates well, it’s probably not too painful.
I think trying to convince projects to move to a different platform is a great idea in principle, but when a stranger walks in and immediately starts complaining about the hosting service, the devs usually have bigger fish to fry. I think it’s better to encourage new projects to use alternative platforms. A huge number of people seem to have only heard of GitHub and maybe GitLab; but as I mentioned, there are Gogs and Gitea for self-hosting, SourceHut, LaunchPad, and BitBucket; plus there are lots of free tools like Gerrit that help manage git and code tracking.
Curious to know what platforms people use by default, especially when it comes to personal vs. professional projects.
Stuff like CoPilot just seems unethical to me, and GitLab being open-source is awesome.
Weellllllll … partially. Part of it is open source and free to self-host. Whereas Sourcehut (where I migrated to from GitLab, after having left GitHub) is fully open source.
This is a strange argument. No matter where you host your code there is counterparty risk. That’s why the industry converged on distributed version control. If you want to reduce your counterparty risk to almost 0, then use multiple mirrors, don’t use any proprietary features on these mirrors, and if you have a private repo, encrypt it. Problem solved.
This article reminds me of when people say you should host your own IMAP server because Google is evil or whatever.
I’ll give you that. Self hosting an IMAP server definitely sounds like a better use of my time than spending hundreds, perhaps thousands, of cumulative hours throughout my life writing comments in obscure internet forums, arguing with random people I’ve never met in upvote-ordered comment trees.
The main inability to escape is because so many projects use Github, so how do you contribute without supporting?
The only real way forward I can see is if one creates burner accounts that are deleted once the PR is merged. That or attempt to influence the project to a different platform. OR fork the project with something like Fossil and manage your own copy of it. You don’t have to give your bug fixes and code over to an OSS project, it’s just “nice”.
IMO the real issue is that there are too many devs who want there to only to be one easy way and not have to learn about other ways. Not sure how to fight that awful mindset.
IMO the real issue is that there are too many devs who want there to only to be one easy way and not have to learn about other ways. Not sure how to fight that awful mindset.
The less a developer has the fight and fiddle with infrastructure the better. Developer tooling should just work and get out of the way of the real task, which is building a product useful for others.
Yeah, as someone who’s worked on these sorts of systems (my first full time job was at Bitbucket), I definitely have the knowledge but not the time for self-hosting… and feature wise GitHub is still miles ahead of the rest, plus there’s still the whole network effect.
I want to focus on building things that are useful to people - Emacs themes, SSH libraries, emulator frontends, whatever I find interesting. I don’t want to spend any more time or energy figuring out where to host them than I need to.
Calling this an “awful mindset” seems like a very short-sighted way of thinking.
feature wise GitHub is still miles ahead of the rest
If you mean “count the number of features” I think you can make this argument, but once you start looking at the quality of said features, it looks rather different.
Github’s page load times are atrocious compared to Sourcehut or Gitea. They claim you can reply to comment notifications over email, but that stopped working a couple years ago. Their CI doesn’t even have the ability to SSH into a failing build to debug, so its popularity while missing such a critical feature is rather baffling to me. Sure they have a large number of features, but once you look a little closer, each one on its own doesn’t hold up very well compared to the competition. (Unless you’re comparing with Gitlab in which case it becomes damning with faint praise.)
If you mean “count the number of features” I think you can make this argument, but once you start looking at the quality of said features, it looks rather different.
We may have to agree to disagree on this one - admittedly, it has been a while since I tried to use Gitea or something similar as a public instance (though I do have a private instance for some of my homelab infrastructure), but last time I did, GitHub’s more popular features were way more polished - pull requests/reviews, CI, issues/project management. I know Gitea recently added CI which is mostly compatible with GH Actions, so I’ll definitely try that out at some point, I just doubt it will fully replace GitHub for me.
plus there’s still the whole network effect.
It’s this. This is the whole thing.
It’s a bit more than this though, or at least a bit more nuanced. There’s also the monetary cost to hosting a service and how easy it is for people to contribute (which usually involves them setting up yet another account).
Part of my goal as an open source maintainer is making it easy for everyone to contribute, and right now the easiest place to do that is GitHub. I could see that changing in the future if there was a solid, easy-to-use federated system, but I personally can’t imagine that being easier to use, and it definitely wouldn’t be cheaper to run. Maybe it would still be worth it for me if it was close, but it seems like it’s a ways off still.
This isn’t to say moving to another platform doesn’t make sense for other people, but it also doesn’t line up well with my personal goals as an open source developer. I’ll be watching to see how things develop and migrate when it makes sense for me.
Contributing to anything on GitHub is supporting Microsoft materially speaking. It doesn’t matter if you used a normal account, burner account, or submitted the change via email. You are the product.
If a GitHub project receives a lot of patches via email that reduces GitHub’s hold on the maintainers, which would hurt Microsoft. Of course it’s possible that not receiving those patches at all could induce them to leave GitHub sooner, but no reason to think that’s usually the case.
An incredible number of things happen in the open source world because somebody was annoying enough about it but also nothing happens unless a maintainer somewhere is willing to go along with it. It probably depends on the project, what resources they have invested in the platform, and most importantly the political stance of the maintainers. If they see no problem with Microsoft and Github’s dominance, they’re unlikely to care much about changing regardless of what you do.
I use GH only to submit issues and lately started sponsoring a software on one of my favorite software programs. Hope I am not much of a product due to this reduced engagement with GH as a platform.
You can usually find an IRC channel or email address to send a patch to, even if the project doesn’t officially support any workflow other than GitHub.
I accept patches this way, but it’s very rare to find a maintainer who is receptive to this unless it’s someone from the olden days of sourceforge or savannah.
If the workflow is the issue and people want to advocate for this, maybe developers could normalize responding via email and/or listing a few alternative methods of contributing in the README? All my public projects are on GitHub, and every once in a while people reach out via IRC, but it’s not a very common occurrence… and that’s for the projects which list IRC as a place to get support.
It depends on how you do it - generally it involves someone submitting a patch via email, you having a back-and-forth similar to a review, and then you merging a re-submitted patch manually. It’s not very smooth, but it just needs an email client which supports attachments. Some platforms like SourceHut advocate the use of git-send-email, but that’s very quirky to set up properly.
Maybe I’m too far gone but I honestly don’t mind it.
I was able to get set up after reading git-send-email.io. To review and apply patches, I started with Thunderbird using the Colored Diffs addon, but more recently have taken to using aerc.
I can’t speak to different email clients, since I only use one client myself (mu4e in Emacs). But for me it works great; much smoother than the code review flow in github.
That said, for my primary projects I have left a read-only mirror in github since I know a lot of people haven’t got a good email setup. We still get contributions sent to that but they tend to be more minor; most of the contributors who have been around a while and tried it prefer email.
Aha! So this is probably the issue I ran into about a week ago. Same symptoms, ended up issuing /proc/sys/vm/drop_caches and that seemed to “un-freeze” khugepaged.
I’ve just tried disabling transparent hugepages as the author suggested, we’ll see if the issue comes up again. I do have 48GB of RAM, which is a decent amount (at least for me), so I have a feeling I would be unlikely to see this issue often as large pages are probably often available.
Oh man. I would immediately apply for jobs at all the major mainframe companies, as well as try and get into the Apollo Guidance Computer group at MIT. I’d also love to work on the early calculators. The issue with the premise is that despite me not being the greatest programmer now, in 1960 I’d be so far ahead of the curve. Imaging bringing object-oriented stuff into ALGOL or FORTRAN? Or giving lectures on concepts taken from POSIX/UNIX etc.? Assuming people bought into it, you’d be able to move the field forward so quickly, and make so much money.
Couldn’t agree more. When GitHub was bought by Microsoft, I migrated all my personal repos to GitLab, and since then I’ve never really had any reason to switch back. Stuff like CoPilot just seems unethical to me, and GitLab being open-source is awesome. I do have a small self-hosted Gogs server; the only reason I chose Gogs over GitLab is just how resource-hungry GitLab can be for small collaborative groups. It scales well, I’m sure, but if you’ve just got 4 or 5 users it makes sense to use a lightweight server. Hell, for a few years I even just ran a git “server” with no front-end at all. Just pushing directly to repositories. If I wanted to create a new one I’d ssh in and make a –bare repo, and then push to it.
Addressing what others have said: I don’t get the Pull Requests thing either. It seems like a great way to manage contributions to public, open-source projects. Especially if you get many small contributions from a large number of people, with a small core group of developers, the amount of time it saves everyone really does add up. But, if you don’t want to support GitHub but want to contribute to projects on there, emailing git-formatted patches is a thing. I mean, that’s how the Linux team still does it, right? I don’t have much experience using git this way, but I have done some work manually emailing diff/patch stuff and if git integrates well, it’s probably not too painful.
I think trying to convince projects to move to a different platform is a great idea in principle, but when a stranger walks in and immediately starts complaining about the hosting service, the devs usually have bigger fish to fry. I think it’s better to encourage new projects to use alternative platforms. A huge number of people seem to have only heard of GitHub and maybe GitLab; but as I mentioned, there are Gogs and Gitea for self-hosting, SourceHut, LaunchPad, and BitBucket; plus there are lots of free tools like Gerrit that help manage git and code tracking.
Curious to know what platforms people use by default, especially when it comes to personal vs. professional projects.
Weellllllll … partially. Part of it is open source and free to self-host. Whereas Sourcehut (where I migrated to from GitLab, after having left GitHub) is fully open source.
This is a strange argument. No matter where you host your code there is counterparty risk. That’s why the industry converged on distributed version control. If you want to reduce your counterparty risk to almost 0, then use multiple mirrors, don’t use any proprietary features on these mirrors, and if you have a private repo, encrypt it. Problem solved.
This article reminds me of when people say you should host your own IMAP server because Google is evil or whatever.
To be fair, running your own IMAP server is fun! It definitely doesn’t prematurely age you.
I’ll give you that. Self hosting an IMAP server definitely sounds like a better use of my time than spending hundreds, perhaps thousands, of cumulative hours throughout my life writing comments in obscure internet forums, arguing with random people I’ve never met in upvote-ordered comment trees.
please imagine me making a skeptical thinking face here :D
I mean… I sincerely believe the thing you said. I’m not sure anyone else does :D
The main inability to escape is because so many projects use Github, so how do you contribute without supporting?
The only real way forward I can see is if one creates burner accounts that are deleted once the PR is merged. That or attempt to influence the project to a different platform. OR fork the project with something like Fossil and manage your own copy of it. You don’t have to give your bug fixes and code over to an OSS project, it’s just “nice”.
IMO the real issue is that there are too many devs who want there to only to be one easy way and not have to learn about other ways. Not sure how to fight that awful mindset.
The less a developer has the fight and fiddle with infrastructure the better. Developer tooling should just work and get out of the way of the real task, which is building a product useful for others.
Yeah, as someone who’s worked on these sorts of systems (my first full time job was at Bitbucket), I definitely have the knowledge but not the time for self-hosting… and feature wise GitHub is still miles ahead of the rest, plus there’s still the whole network effect.
I want to focus on building things that are useful to people - Emacs themes, SSH libraries, emulator frontends, whatever I find interesting. I don’t want to spend any more time or energy figuring out where to host them than I need to.
Calling this an “awful mindset” seems like a very short-sighted way of thinking.
If you mean “count the number of features” I think you can make this argument, but once you start looking at the quality of said features, it looks rather different.
Github’s page load times are atrocious compared to Sourcehut or Gitea. They claim you can reply to comment notifications over email, but that stopped working a couple years ago. Their CI doesn’t even have the ability to SSH into a failing build to debug, so its popularity while missing such a critical feature is rather baffling to me. Sure they have a large number of features, but once you look a little closer, each one on its own doesn’t hold up very well compared to the competition. (Unless you’re comparing with Gitlab in which case it becomes damning with faint praise.)
It’s this. This is the whole thing.
We may have to agree to disagree on this one - admittedly, it has been a while since I tried to use Gitea or something similar as a public instance (though I do have a private instance for some of my homelab infrastructure), but last time I did, GitHub’s more popular features were way more polished - pull requests/reviews, CI, issues/project management. I know Gitea recently added CI which is mostly compatible with GH Actions, so I’ll definitely try that out at some point, I just doubt it will fully replace GitHub for me.
It’s a bit more than this though, or at least a bit more nuanced. There’s also the monetary cost to hosting a service and how easy it is for people to contribute (which usually involves them setting up yet another account).
Part of my goal as an open source maintainer is making it easy for everyone to contribute, and right now the easiest place to do that is GitHub. I could see that changing in the future if there was a solid, easy-to-use federated system, but I personally can’t imagine that being easier to use, and it definitely wouldn’t be cheaper to run. Maybe it would still be worth it for me if it was close, but it seems like it’s a ways off still.
This isn’t to say moving to another platform doesn’t make sense for other people, but it also doesn’t line up well with my personal goals as an open source developer. I’ll be watching to see how things develop and migrate when it makes sense for me.
Contributing to anything on GitHub is supporting Microsoft materially speaking. It doesn’t matter if you used a normal account, burner account, or submitted the change via email. You are the product.
If a GitHub project receives a lot of patches via email that reduces GitHub’s hold on the maintainers, which would hurt Microsoft. Of course it’s possible that not receiving those patches at all could induce them to leave GitHub sooner, but no reason to think that’s usually the case.
An incredible number of things happen in the open source world because somebody was annoying enough about it but also nothing happens unless a maintainer somewhere is willing to go along with it. It probably depends on the project, what resources they have invested in the platform, and most importantly the political stance of the maintainers. If they see no problem with Microsoft and Github’s dominance, they’re unlikely to care much about changing regardless of what you do.
I use GH only to submit issues and lately started sponsoring a software on one of my favorite software programs. Hope I am not much of a product due to this reduced engagement with GH as a platform.
You can usually find an IRC channel or email address to send a patch to, even if the project doesn’t officially support any workflow other than GitHub.
I accept patches this way, but it’s very rare to find a maintainer who is receptive to this unless it’s someone from the olden days of sourceforge or savannah.
If the workflow is the issue and people want to advocate for this, maybe developers could normalize responding via email and/or listing a few alternative methods of contributing in the README? All my public projects are on GitHub, and every once in a while people reach out via IRC, but it’s not a very common occurrence… and that’s for the projects which list IRC as a place to get support.
Curious, how smooth/easy is the git->email->git workflow? Does it integrate well with different email clients?
It depends on how you do it - generally it involves someone submitting a patch via email, you having a back-and-forth similar to a review, and then you merging a re-submitted patch manually. It’s not very smooth, but it just needs an email client which supports attachments. Some platforms like SourceHut advocate the use of git-send-email, but that’s very quirky to set up properly.
Maybe I’m too far gone but I honestly don’t mind it.
I was able to get set up after reading git-send-email.io. To review and apply patches, I started with Thunderbird using the Colored Diffs addon, but more recently have taken to using aerc.
I can’t speak to different email clients, since I only use one client myself (mu4e in Emacs). But for me it works great; much smoother than the code review flow in github.
That said, for my primary projects I have left a read-only mirror in github since I know a lot of people haven’t got a good email setup. We still get contributions sent to that but they tend to be more minor; most of the contributors who have been around a while and tried it prefer email.
they are not receptive in the sense that they will ignore your patch?
Usually either ignore altogether or redirect you to the pull request flow, yeah.
I guess it’s more common than I thought, but I maintain that projects like that are a joke.
If I had the luxury of being able to not use projects run by people who made bad decisions I would be a much happier person than I am today.
at least you can withhold your patches
Aha! So this is probably the issue I ran into about a week ago. Same symptoms, ended up issuing /proc/sys/vm/drop_caches and that seemed to “un-freeze” khugepaged.
I’ve just tried disabling transparent hugepages as the author suggested, we’ll see if the issue comes up again. I do have 48GB of RAM, which is a decent amount (at least for me), so I have a feeling I would be unlikely to see this issue often as large pages are probably often available.