First of all, kudos for trying to find new ways to fund open source. Those are needed.
This approach might work well for issues which require a lot of thought, but produce a simple fix and can be easily merged
This might go horribly wrong if outside contributors try to implement a major feature to a project which they don't have a good mental model for, produce a large patch that may get rejected by maintainers, or end up being rewritten-by-code-review, which would cost such maintainers more time than if they implemented the feature in the first place.
Bloomberg maintains an excellent dashboard that tracks vaccination in the US and worldwide ([1]). It shows that California is one of the slowest states with only 37% of received vaccine administered. Top five states are North Dacota (77%), West Virginia (74%), Oregon (61%), South Dacota (61%) and Texas (60%).
I don't know that percentage of received vaccine administered is quite the right metric: I tend to think doses administered per capita is the key number.
But whatever number you look at, California is a disgrace. We've fucked this colossally. The only states that are worse than we are are poor, rural, and low education.
It's not really true that all of them are: Alaska and North Dakota are actually quite wealthy per capita due to petroleum. Connecticut is also one of the states handling the vaccination quite well, and it's quite urban. But a number of the states doing well with vaccinations are quite poor and rural, and that just makes it all the more damning that California is doing so terribly poorly.
As far as I can tell, it's not anything particularly to do with any demographic factor: other big states like New York and Texas are doing much better than California. States that are both deeply red and deeply blue are doing much better than California. California is just... failing. We're underperforming every state that might reasonably be a comparator.
While my account is relatively young (13 days), it's not one day old. You can also look into my comments over this time. So, the accusation is clearly off.
snaps are tied to the proprietary Ubuntu store and they are not available on all of the Linux flavors. For instance, I don't see snapd on Alpine Linux:
I don't believe it's a joke. It still might be a deliberate lie (a random twit is not a real source of knowledge), but so far this is consistent with what we already know. See https://news.ycombinator.com/item?id=25769730
I thought it was clearly a joke, implying they had electron running server-side, maybe even running their app through cypress in production for time travel debugging?
But I actually do want to know they language(s) and framework(s).
Debian policy is very sane (no network access during build), but it does seem like modern software just assumes that the Internet is always available, and all dependencies (including transitive) are out there.
The assumption is a bit fragile, as proven by the the left-pad incident ([1]). I hope that whatever the outcome of the discussion in Debian will be, it would keep the basic policy in place: not relying on things outside of the immediate control during package builds.
Debian is incredibly conservative about versioning/updates and faces a lot of pressure to move faster. I hope they keep the same pace or even slow down.
The whole "download during build" thing is a minor issue; k8s, for example, puts all their dependencies in the /vendor/ directory, and AFAIK many toolchains support this or something like it. And even if they don't, this is something that can be worked around in various ways.
The real issue is whether or not to use that vendor directory, or to always use generic Debian-provided versions of those dependencies, or some mix of both. This is less of a purely technical issue like the above, and more of a UX/"how should Debian behave"-kind of issue.
Key quote: "We have become extremely dependent on conda and conda-forge. We must think of their sustainability."
Then it talks through the steps being taken to reduce dependency on Anaconda Inc. While the company proved to have a lot of goodwill in the past, there's always future: it gets acquired, and the new owners might not be as well meaning as the current ones.
That sounds great, but it's a very fragile state of things.
While it certainly makes lives of Iranian developers easier, it does not make it a good idea to put their code there: laws change, and quickly sometimes.
Laws change and there are also a bunch of other ways to get banned from your code on GH. And once that happens, you have nowhere to go.
Much easier to migrate to a Gitlab instance. And they know this! Which is why it's so fun to see Github dancing around these issues lately. Finally some healthy competition.
I'd love to know how many times MS have tried to buy Gitlab. :D
Probably a naive question, but is there some way for all these elements to held in a git repo as well? Just move all your issues/trackers to another platform?
and users. GH, GL, BB are kind of dev social netwoks. Project assets can be archivised/mirrored easily with tools or API scripts, but there is no way to link them back to live users. Community needs to be rebuild at new place and thay is lot of effort.
On the other hand, hopefully the more contact Iranians have with the outside world, the more they will petition their government for peaceful relations with other countries. Obviously GitHub access isn't going to make the difference, but rather lots of these kinds of things in aggregate.
Unfortunately, github is 50% git, 50% proprietary code that you don't control and can't neatly export your data for other platforms. All these git hosts are walled Gardens. It's a sad state of affairs but not really limited to git (Gmail walled Garden despite email standard, messaging apps, etc).
Github has some great management tools for reviewing code and integrating with various integrations. But so does Gitlab, Bitbucket... and I'm sure there are more. They aren't 1 for 1 replacements, but they do exist. I'd personally recommend against using a ton of integrations that tightly bound you to any service.
Even more than that, as long as one person has the repo cloned you can bootstrap the entire project again, any single clone has the entire project history to the most recent point it was fetched. Git is neat that way.
That's not necessarily true. If your organization has tens of repositories with multiple important branches in each, all odds that at least some of those branches are lost.
Proper backups of all repos are an answer, of course.
The way we use git, master has everything that is production with short-lived feature branches for development work. Not needing to worry about git backups is perhaps the least of the benefits of this approach (and no real drawbacks as far as I can tell).
Yes, as answered in another branch, it's possible and reasonable to setup continuous / daily backups, if you're using a hosted Git service (Github or not). This will mitigate the risk of losing access to the code.
It's not advised for these Iranian developers to use any Github-specific features, such as issues, wiki, CI, because losing them will cause disruption / knowledge loss.
And then the reason to use Github specifically, instead of something else is quite low.
You don’t understand - there is no need to setup backups. Every user has a full “backup” of the repository (unless using sparse checkouts or other niche configs).
This is true for the source control aspects of Git, but not all of the project management aspects of GitHub. (wikis, gists, gh-pages: yes. issues, pull requests: no)
Does Iran not have it's own version of online git service after such a long time? I imagine it's not too difficult to set a barebone git hosting service up (without the hub functions, obviously).
I suspect to get the same level of availability and trust folks have in github 100% inside Iran using local hosting providers / infrastructure is actually a bit difficult.
I think it's kinda hard to compete with the big boys with limited resources / footprint even whit / perhaps because of sanctions.
1. https://en.wikipedia.org/wiki/Criticism_of_Linux#Criticism_b...