Very small corrections here; while Actions was publicly launched after the acquisition, the initial version of it was in development before the acquisition, and would have launched regardless of it. While it is true that the version of Actions that is currently available runs on Azure and shares a lot of DNA with Azure DevOps Pipelines, this was not true of the initial version; it was an independent project and more-or-less code complete before the deal closed, and ran on AWS.
Source: I’m a former employee of GitHub, who was around during the acquisition.
I was surprised (and horrified) by the deep dive into the github actions code. I know a lot of people who enjoy using github actions as semi-black-boxed functions that “do the thing”.
Making an upload CPU bound on VMs which are already somewhat notoriously slow for single core performance is a special kind of ugly.. but hey, I guess they’re charging per second, so maybe making it slow is good for business…
Anecdotally I have friends that work at one of the top-three cloud vendors that swear they have been reprimanded for implementing performance improvements in DBaaS products, because it reduces revenues.. not sure how true that is, but the financial incentives are problematic.
in their defence, I have also been reprimanded for improving performance.
But that was because their was a desire to keep pushing features instead of improving the performance of things that already exist. So I could imagine a situation like this.
However, it’s very bad optics if there is a financial incentive for bad performance.
Were you reprimanded for improving performance, or for working on stuff you wanted to work on, instead of sticking to priorities agreed upon with the rest of the company? Most of the time the problem is that developers don’t see the larger picture and it’s a matter of balance.
Almost definitely true story from a distant past: IBM’s VM/370 was very heavily used internally for developing new operating system releases but wasn’t actively marketed to customers because it would allow customers to buy fewer machines.
Would they be open source, if it was slow on purpose? For most users, Github Actions are free, and they’re hurting themselves by not being able to offer them to as many users as possible as often as possible, plus they open themselves to these kinds of attacks. I know it feels good to just take it down, because it’s an easy target, but a company of that size can easily afford world class programmers, so there must be a good reason for it and you’re not being very charitable with your interpretation.
I’m not sure there must be a good reason for it—large organizations make
mistakes and missteps constantly.
Furthermore, many people do shady and unethical things out in the open because they just don’t expect people to look closely.
Not to say in this case Github is doing anything nefarious in this case, but I’m not particularly convinced by “Github is fabulously wealthy so we should trust they have Reasons”
In my experience when you see code that seems to be missing something obvious, it’s more likely that there’s a good reason for it, than that you’re the first person to notice it. Especially if it’s a flagship product of one of the biggest companies in the world, inspectable by anyone. It sure is an ego boost to think that you’re just smarter than everyone working at company X, but it’s never true. With Github, you can use self-hosted runners, and most companies who use Actions commercially do, so the theory that this is because they want to inflate running times and charge more is also almost certainly wrong. Additionally, anyone examining CI for savings would see that this particular code was a major bottleneck. It’s easier to deliver a great product that makes clients happy to use it, than to artificially inflate running times here.
Github Actions epitomizes the “worse is better” mindset, and it’s a good example of how that path can really send you in a bad direction. There are so many things wrong, so many things that can’t be right, but at this point it exists and making major changes is hard.
So many choices appear to be iterative “make it work” decisions.
At Github’s scale “worse is better” just feels like the wrong choice, you need to transition to “sweat the details” and “get it right the first time”.
TBH I disagree with the “You can’t compete with them” stuff at the end. While people will want to use one tool as much as possible, Travis and other 3rd party tools were “it” for a long time despite being 3rd party. The other tools are so, so much better, and safer, I think it’s actually a very easy sell to use them.
That’s a great point. He stayed away from recommending a specific solution, which at least means the video won’t be outdated when that project goes under.
this vid feels years ahead of its time. it’s so specific to the industry with such deep understanding of subject matter, which normally takes the form of a lecture or a more “info-oriented” video. but this came off as casual and fun. overall just amazing work, when i found out it was fasterthanlime at the end, i thought “oh yea, that makes sense” - nobody else could do this better.the only creator in the same realm rn is krazam, but the quality here was just. honestly i’m kinda moved. thank you for your dedication to craft.
but also, ftl, if you’re reading this, respectfully, golang rules fukyou o7
TIL that there is a computing commentator named betterthanlime in addition to fasterthanlime. I had supposed that the latter’s name was an allusion to the phrase “faster than light”, but now I question that. I wonder whether they’re siblings. :-)
I’ve tried multiple ways of using GitHub for students where:
there is a public teacher repo
student repos inherit the code from the teacher’s repo, but student repos are private (teachers have access)
teachers can push to student repos
students can pull fixes from the teacher repo after they clone their personal repo
It’s been a nightmare. At every turn there’s some design decision that thwarts you.
First, if you have a public repo, all forks inherit the “public” attribute, and this can’t be changed without unlinking it from upstream. Every student can then see every other student’s code. We didn’t want this.
There are things called “template repositories” but they’re not forks. They share no history and can’t pull updates from the template, ever. It’s a one-shot deal. Hope you ironed out all the bugs from last semester (you didn’t).
We even tried maintaining two copies of the teacher repo, one public and one private, so student repos could be forks of the private one. This lets you fetch changes but only from the private teacher repo, which means every student needs elevated access to the teacher repo.
We finally ended up solving this by circumventing GitHub completely and just had students download patches from somewhere else. Then we poured one out for our lost sanity and contemplated ditching GitHub entirely.
Ironically, GitHub provides a dedicated action for cloning, because there’s no way to do this within GitHub unless you are GitHub. So I guess we just wait for them to solve our use case or stop using GitHub. Which is a shame, because teaching students to use git is great, and GitHub has some excellent features (like Discussions and pull request workflows) that we still like to use.
Shared history. If you don’t have shared history, git has no way of applying changes. So think of a template repository like a regular repo but after you clone it you delete your git history and do git init on your local copy. Now it’s a new repo as far as git is concerned, regardless of its content being identical to the remote.
The result is if the template changes after you clone it, you can’t apply those changes to your local copy. The best you can do is clone it again and add your changed files manually, at which point why bother using git?
Templates work fine in the (intended?) use case where you want to share a public, read-only, static repo.
Right, for templates, those copy the files. But you also said having private repos forked from public ones are an issue, and that one works just as fine? Either fork and then set to private, or make a private repo and push the contents of the public one?
When I TAed courses like that we’d automate repo setup anyways, so the extra step isn’t a problem and even without that it’d IMHO beat distributing patches out-of-band
We use an on-prem enterprise GitHub which lags behind github.com a bit, so I’ll have to go back and check. My memory is that at the time (pre enterprise version 3.9 I think), I attempted to automate the “fork and then make it private” but that particular sequence of actions was impossible. I know it’s always been possible to do a “bare clone” manually from the command line and basically stuff a blank repo with the contents of a private repo, but I couldn’t figure out how to do it via the API.
For a while we had students do the bare clone thing, but it ate a lot of TA time coaching students through the command line steps.
We’re on enterprise 3.10 now so I’ll have to see what’s new.
I watched this again and it’s really really great (who knew Booch would pop up randomly). It reminds me a bit about the Bret Victor talks about the history of computing but more in depth on programming.
Very small corrections here; while Actions was publicly launched after the acquisition, the initial version of it was in development before the acquisition, and would have launched regardless of it. While it is true that the version of Actions that is currently available runs on Azure and shares a lot of DNA with Azure DevOps Pipelines, this was not true of the initial version; it was an independent project and more-or-less code complete before the deal closed, and ran on AWS.
Source: I’m a former employee of GitHub, who was around during the acquisition.
I was surprised (and horrified) by the deep dive into the github actions code. I know a lot of people who enjoy using github actions as semi-black-boxed functions that “do the thing”.
Making an upload CPU bound on VMs which are already somewhat notoriously slow for single core performance is a special kind of ugly.. but hey, I guess they’re charging per second, so maybe making it slow is good for business…
Anecdotally I have friends that work at one of the top-three cloud vendors that swear they have been reprimanded for implementing performance improvements in DBaaS products, because it reduces revenues.. not sure how true that is, but the financial incentives are problematic.
in their defence, I have also been reprimanded for improving performance.
But that was because their was a desire to keep pushing features instead of improving the performance of things that already exist. So I could imagine a situation like this.
However, it’s very bad optics if there is a financial incentive for bad performance.
Were you reprimanded for improving performance, or for working on stuff you wanted to work on, instead of sticking to priorities agreed upon with the rest of the company? Most of the time the problem is that developers don’t see the larger picture and it’s a matter of balance.
Almost definitely true story from a distant past: IBM’s VM/370 was very heavily used internally for developing new operating system releases but wasn’t actively marketed to customers because it would allow customers to buy fewer machines.
Would they be open source, if it was slow on purpose? For most users, Github Actions are free, and they’re hurting themselves by not being able to offer them to as many users as possible as often as possible, plus they open themselves to these kinds of attacks. I know it feels good to just take it down, because it’s an easy target, but a company of that size can easily afford world class programmers, so there must be a good reason for it and you’re not being very charitable with your interpretation.
I’m not sure there must be a good reason for it—large organizations make mistakes and missteps constantly.
Furthermore, many people do shady and unethical things out in the open because they just don’t expect people to look closely.
Not to say in this case Github is doing anything nefarious in this case, but I’m not particularly convinced by “Github is fabulously wealthy so we should trust they have Reasons”
In my experience when you see code that seems to be missing something obvious, it’s more likely that there’s a good reason for it, than that you’re the first person to notice it. Especially if it’s a flagship product of one of the biggest companies in the world, inspectable by anyone. It sure is an ego boost to think that you’re just smarter than everyone working at company X, but it’s never true. With Github, you can use self-hosted runners, and most companies who use Actions commercially do, so the theory that this is because they want to inflate running times and charge more is also almost certainly wrong. Additionally, anyone examining CI for savings would see that this particular code was a major bottleneck. It’s easier to deliver a great product that makes clients happy to use it, than to artificially inflate running times here.
[Comment removed by author]
Github Actions epitomizes the “worse is better” mindset, and it’s a good example of how that path can really send you in a bad direction. There are so many things wrong, so many things that can’t be right, but at this point it exists and making major changes is hard.
So many choices appear to be iterative “make it work” decisions.
At Github’s scale “worse is better” just feels like the wrong choice, you need to transition to “sweat the details” and “get it right the first time”.
TBH I disagree with the “You can’t compete with them” stuff at the end. While people will want to use one tool as much as possible, Travis and other 3rd party tools were “it” for a long time despite being 3rd party. The other tools are so, so much better, and safer, I think it’s actually a very easy sell to use them.
There’s “worse is better”, which is trading off polish for simplicity, ease of understanding, and implementability.
This is just “worse is worse”
I liked this a lot, but I must say that I was hoping for a call to action (heh) at the end. The “polycule” slide was great.
There was! “Get paid, feed your family, and if you can contribute to the commons while doing so, that’s a privilege – use it wisely”.
That’s a great point. He stayed away from recommending a specific solution, which at least means the video won’t be outdated when that project goes under.
I thought the polycule slide was funny anyway…but I didn’t get the joke…? :P
timestamp?https://youtu.be/9qljpi5jiMQ?si=ggpvtT_8M079BxhE&t=1478
It’s probably a reference to https://iliana.fyi/blog/tailscale-auth-and-threat-modeling/
i run headscale for my polycule :3 we have a shared nas and stuff, and this way even the non-physically-present people get access!
Well, it’s not Circle CI, that’s for sure.
https://twitter.com/paulbiggar/status/1738371292271616220
Am confused. Relevance of the link?
Paul Biggar was punished for writing this https://blog.paulbiggar.com/i-cant-sleep/
I still don’t see the relevance.
this vid feels years ahead of its time. it’s so specific to the industry with such deep understanding of subject matter, which normally takes the form of a lecture or a more “info-oriented” video. but this came off as casual and fun. overall just amazing work, when i found out it was fasterthanlime at the end, i thought “oh yea, that makes sense” - nobody else could do this better.the only creator in the same realm rn is krazam, but the quality here was just. honestly i’m kinda moved. thank you for your dedication to craft.
but also, ftl, if you’re reading this, respectfully, golang rules fukyou o7
TIL that there is a computing commentator named betterthanlime in addition to fasterthanlime. I had supposed that the latter’s name was an allusion to the phrase “faster than light”, but now I question that. I wonder whether they’re siblings. :-)
Edit: Oh. Never mind then.
o gawd how embarrassing my bad. corrected
I’ve tried multiple ways of using GitHub for students where:
It’s been a nightmare. At every turn there’s some design decision that thwarts you.
First, if you have a public repo, all forks inherit the “public” attribute, and this can’t be changed without unlinking it from upstream. Every student can then see every other student’s code. We didn’t want this.
There are things called “template repositories” but they’re not forks. They share no history and can’t pull updates from the template, ever. It’s a one-shot deal. Hope you ironed out all the bugs from last semester (you didn’t).
We even tried maintaining two copies of the teacher repo, one public and one private, so student repos could be forks of the private one. This lets you fetch changes but only from the private teacher repo, which means every student needs elevated access to the teacher repo.
We finally ended up solving this by circumventing GitHub completely and just had students download patches from somewhere else. Then we poured one out for our lost sanity and contemplated ditching GitHub entirely.
Ironically, GitHub provides a dedicated action for cloning, because there’s no way to do this within GitHub unless you are GitHub. So I guess we just wait for them to solve our use case or stop using GitHub. Which is a shame, because teaching students to use git is great, and GitHub has some excellent features (like Discussions and pull request workflows) that we still like to use.
/rant
I think I’m missing something - what does “Github considers this a fork” have to do with “can/cannot fetch updates from teacher repo”?
Shared history. If you don’t have shared history, git has no way of applying changes. So think of a template repository like a regular repo but after you clone it you delete your git history and do
git initon your local copy. Now it’s a new repo as far as git is concerned, regardless of its content being identical to the remote.The result is if the template changes after you clone it, you can’t apply those changes to your local copy. The best you can do is clone it again and add your changed files manually, at which point why bother using git?
Templates work fine in the (intended?) use case where you want to share a public, read-only, static repo.
Right, for templates, those copy the files. But you also said having private repos forked from public ones are an issue, and that one works just as fine? Either fork and then set to private, or make a private repo and push the contents of the public one?
When I TAed courses like that we’d automate repo setup anyways, so the extra step isn’t a problem and even without that it’d IMHO beat distributing patches out-of-band
We use an on-prem enterprise GitHub which lags behind github.com a bit, so I’ll have to go back and check. My memory is that at the time (pre enterprise version 3.9 I think), I attempted to automate the “fork and then make it private” but that particular sequence of actions was impossible. I know it’s always been possible to do a “bare clone” manually from the command line and basically stuff a blank repo with the contents of a private repo, but I couldn’t figure out how to do it via the API.
For a while we had students do the bare clone thing, but it ate a lot of TA time coaching students through the command line steps.
We’re on enterprise 3.10 now so I’ll have to see what’s new.
I watched this again and it’s really really great (who knew Booch would pop up randomly). It reminds me a bit about the Bret Victor talks about the history of computing but more in depth on programming.