6 ms·

One of the most ironic things about GitHub is how it seems to have spawned centrist systems despite being named after a distributed system. Much like key serve

One of the most ironic things about GitHub is how it seems to have spawned centrist systems despite being named after a distributed system. Much like key servers allow people to determine authenticity in a somewhat-decentralized way, there ought to be a similar way of determining the “authentic” sites for various projects/people or the official places to log issues, etc. Then, the whole network can figure out where to find things, whether or not GitHub or something like it exists, and we can stop asking or expecting GitHub to provide every feature that we need. As one commenter on the page put it, GitHub is a place for posting a sort of software résumé and is an “expected” way to determine what people have contributed to. Why? Git itself is decentralized; the whole point was supposed to be that somebody's code might be almost anywhere...and yet, an ecosystem of centralization emerged. Similarly, when GitHub went down awhile back, all these things were affected. Why? Why did people set up systems that depended on the ability to download from GitHub, for instance?

dozzie 11y ago
Quite simple. People in IT (and hobbyst programmers) tend to not learn the tooling, its features and properties, and reasons behind the tooling itself. It's all rage about writing things, never mind that somebody had it already implemented and way, way better. Look for instance at how programmers deploy their applications (which are mostly web applications). Are those applications tied to operating system version somehow? Mostly. Are those programmers using this operating system's tools for software installation? Hardly. And why? Because it's not sexy enough, npm or gem are way sexier (despite apt-get or yum being much more mature and robust). It really takes a long time to feel how and why the OS works and to work with the system instead of against it. Don't expect programmers with vast three years experience to understand their surroundings.
- oldmanjay 11y ago
  "It takes a long time to understand" is synonymous with "can be improved."
  - pklausler 11y ago
    Counterexample: the universe.
    - astrange 11y ago
      I think the universe has a long list of outstanding feature requests.
      - davidhowlett 11y ago
        I wanted to add a few feature requests so I went looking for god on github. I found god but unfortunately most of the universe has not been open sourced yet :-( The physicists are trying hard to reverse engineer it though.
  - gkya 11y ago
    I add this to my list of epic non-sequiturs. While it is not necessarily wrong completely, it is not correct for all the cases. It takes a long time to understand how it's ok to do without the latest version of the software. It takes long time to understand that old is not a synonyme for obsolete. And to have this understandings one needs experience, and for experience you need time, which cannot be substituted. There are some things that one only learns by rediscovering them, and this is one of them: who settles is happy.
- oldmanjay 11y ago
  "It takes a long time to understand" is synonymous with "can be improved."
- qwertyuiop924 11y ago
  there are legitimate technical reasons for using NPM (disk is cheap, project local packages ftw, etc.). gem, less so. I can, however, tell you the primary reasons for using npm or gem: I need a dependency, my os hasn't packaged it, and it's the path of least resistance. Also, I am a hobbyist programmer. I also know that git was created by Linus Torvalds, it's a DVCS (although Torvalds calls it an SCM), and it's based on a DAG (directed acrylic graph), which is a directed graph with no directed cycles, and excellent for modelling causal relations. I can explain to you the difference between a rebase and a merge. I know that git uses SHA-1 hashes to identify check-ins internally, as a data security feature. I know that checkins and other objects are stored in the .git folder at the repository's root directory. I know that these objects are garbage collected, although the frequency at which they are escapes me. I know that, despite common belief, git commits are immutable, but also that the git history is not. I know that git was inspired by BitKeeper, after the incident that caused the linux source to be moved away from that system, because Linux got fed up with tarballs and patches, and hates CVS with a fanatical passion. I know that git had three design goals: distributed, fast, and guarantees that you get the same bits out that you put in. And I've have several years of causal experience with git, using probably one tenth of its functionality. I may not be able to recite git's internals at you, but I know it's features (to an extent), I know the tools, and I know the reasoning. And the functionality sure as heck isn't magic.
  - dozzie 11y ago
    > I need a dependency, my os hasn't packaged it, and it's the path of least resistance. What I tell you back: you probably don't need it, you're just being very, very lazy, which will cost later in bugs in those dependencies, and it's not that easy to fix a bug in a dependency. Additionally, it's not that difficult to make a package with that dependency. I routinely do so, both for things other people wrote and for my code. Sure, it's not as easy as adding a line in package.json, but there should be some friction in adding a library to a project, so the library would justify itself. Keeping many dependencies is very expensive in the long run, but short-term is somewhat beneficial. Look at how it works for Node.js and gems and Python packages: every library needs its own `map()' function implementation (or anything else similarly trivial), so typcial application requires few dozens of other libraries.
- efes 11y ago
  > Are those programmers using this operating system's tools for software installation? Hardly. And why? Because this is a bizarre argument. I accidentally make dependencies on specific variants of libraries because I don't immediately need to support other variants and lack examples and/or time to worry about theoretical portability. I don't use OS specific packaging because it was intentionally written to be non-portable. My learning it is an irrational commitment to keep using an OS at the neglect of all others and even if its distributor changes (or can no longer honor) the conditions of our deal.
  - dozzie 11y ago
    Your dynamic website (often called a webapplication) is very probably OS-specific anyway. I've seen websited that can run only on Ubuntu. Most often you could as well settle with what OS provides to deploy it, especially that you won't need another instance on the same server. Even more so if it's not a hobbyst project, but a professional one. > I don't use OS specific packaging because it was intentionally written to be non-portable. Only if you use it mindlessly. It's not really different to build a package for Debian, Red Hat, Slackware, or Gentoo (been there, done all of these). All it takes is to properly separate downloading sources and building things, which is a good engineering on its own. And guess what you get in exchange? Easy dependency installation, both for development and for deployment.
- mitm2mitm 11y ago
  So you can link your Github profile to recruiters and add "Creator of project X" in your CV. I hate the amount of garbage and noise created by this. But how many of the good tools we have today wouldn't have existed if people didn't just started coding? It's full circle to your first phrase since if nobody was using nobody would write redundant/worse tools. Man I miss the time programming was only my hobby.
dominotw 11y ago
If there is no central server like github. What do you map origin to?
- ossreality 11y ago
  You can't be serious...
- cyphar 11y ago
  That's not how git works... Yes, you can have remotes where you pull your initial state. You can have many remotes -- any git repo you've cloned can be used to host the repo publicly. But after that, you can merge patches that people send you over email (or heck, even via carrier pigeon), do everything you need without a host. In fact some people have made a github-like hosting solution that is decentralised called GitTorrent.
  - dominotw 11y ago
    But which one does the team deploy if everyone is sending patches to each other.
mbrock 11y ago
Why do we all rely on communicating through news.ycombinator.com? Because it's useful to have a central hub. It's a very easy system to understand and use. There's no obvious alternative right now. Someone should build one. It's not super easy. There are big and interesting political and technical questions... which GitHub conveniently sidesteps by just being a central server.
- qwertyuiop924 11y ago
  I was about to post this, but less eloquently, and without the obvious metaphor.
- makecheck 11y ago
  A central-hub choice of implementation shouldn't be confused with a centralization requirement however. It is possible for distributed systems to still converge on things (indeed, entire papers have been written on the problem of distributed “agreement”), it's just that they must work in a very different way. Indeed, we had this, in the form of NNTP and older news servers; those servers essentially exchanged copies of whatever was posted from around the Internet. If there were no news.ycombinator.com, there could still be a wide variety of servers that constitute “hacker news” around the world, that come to a general agreement on what the collection of posts should be. At any instant in time, not all servers will be 100% identical but for all practical purposes they would be.
  - jasode 11y ago
    >A central-hub choice of implementation shouldn't be confused with a centralization requirement however. >Indeed, we had this, in the form of NNTP and older news servers; You're focusing on the technical aspects. The other forces are social and economics. Both of those lead to centralization. Take your example of Usenet news groups. Yes, in a technical sense, it's decentralized but once you get economics/money involved, what happens? My ISP like Verizon doesn't carry all newsgroups (e.g. exclude newsgroups with large binaries.) Or another ISP may carry more newsgroups but the retention is 1 month instead of 1 year. So the economics converges to an central entity like Deja News that emphasizes the archival of usenet posts. Then Google buys them (Google Groups). Google Groups is now "centralized" for finding very old usenet posts. Conceivably, any of us besides DejaNews could have archived the posts but we didn't spend the money on harddrives to store it whereas DejaNews did. Hence, we end up with a centralized archive. When I had Verizon, their newsgroups feed was very poor. I therefore paid $10 extra to GigaNews because they had everything with multi-year retention. That's another "centralized" hub driven by economics. Looking only at the usenet RFC technical specs for distributing news posts doesn't reveal how the economics makes centralization emerge. As for github's centralization... A lot of us want to host a public git repository. Hmmmm... if github didn't exist, what do we do? Pay for a VPS for $9/month plan and host git on that? What about extra bandwidth costs if it's a popular repo and lots of people are cloning it? That's a lot of ugly financial bookkeeping that we don't want to do since we'd rather just concentrate on programming. Wait -- there's an ABC company out there that lets me conveniently host a git repo there? For free? Sign me up! That "ABC company" by way of economics and social dynamics has turned out to be Github and BitBucket. And since Github has been winning the mindshare, you get centralization. There is no irony in git-the-tool being distributed and github-the-focal-point being centralized.
volaski 11y ago
It's nothing new or ironic because that's exactly the definition of centralization. Here's the definition: "concentrate (control of an activity or organization) under a single authority." There has been and will always be systems that try to centralize already existing distributed entities.
exolymph 11y ago
Centralization happens naturally. There's a reason why we see it again and again. https://medium.com/@Exolymph/i-swear-i-m-not-a-statist-df99079f0086#.ib4qa0nyw https://medium.com/@Exolymph/i-swear-i-m-not-a-statist-df990...
jotux 11y ago
I really don't understand your argument. Git is for decentralized development but there has always been a need for a central server to host the repo and github made a business out of providing that along with additional services (pages, wiki, issues). The dear-github complaints are overwhelmingly about the secondary services github provides for project management. >Why did people set up systems that depended on the ability to download from GitHub, for instance? Because if they didn't rely on github they'd have to rely on some other server subject to similar downtime?
emmelaich 11y ago
You could use a distributed bug tracker like http://www.bugseverywhere.org/ http://www.bugseverywhere.org/ "Bugs Everywhere is a “distributed bugtracker”, designed to complement distributed revision control systems. By using distributed revision control as a backend for bug state, we gain several convenient features: ..."

dozzie 11y ago

Quite simple. People in IT (and hobbyst programmers) tend to not learn the tooling, its features and properties, and reasons behind the tooling itself. It's all rage about writing things, never mind that somebody had it already implemented and way, way better. Look for instance at how programmers deploy their applications (which are mostly web applications). Are those applications tied to operating system version somehow? Mostly. Are those programmers using this operating system's tools for software installation? Hardly. And why? Because it's not sexy enough, npm or gem are way sexier (despite apt-get or yum being much more mature and robust). It really takes a long time to feel how and why the OS works and to work with the system instead of against it. Don't expect programmers with vast three years experience to understand their surroundings.

oldmanjay 11y ago
"It takes a long time to understand" is synonymous with "can be improved."
- pklausler 11y ago
  Counterexample: the universe.
  - astrange 11y ago
    I think the universe has a long list of outstanding feature requests.
    - davidhowlett 11y ago
      I wanted to add a few feature requests so I went looking for god on github. I found god but unfortunately most of the universe has not been open sourced yet :-( The physicists are trying hard to reverse engineer it though.
- gkya 11y ago
  I add this to my list of epic non-sequiturs. While it is not necessarily wrong completely, it is not correct for all the cases. It takes a long time to understand how it's ok to do without the latest version of the software. It takes long time to understand that old is not a synonyme for obsolete. And to have this understandings one needs experience, and for experience you need time, which cannot be substituted. There are some things that one only learns by rediscovering them, and this is one of them: who settles is happy.
oldmanjay 11y ago
"It takes a long time to understand" is synonymous with "can be improved."
qwertyuiop924 11y ago
there are legitimate technical reasons for using NPM (disk is cheap, project local packages ftw, etc.). gem, less so. I can, however, tell you the primary reasons for using npm or gem: I need a dependency, my os hasn't packaged it, and it's the path of least resistance. Also, I am a hobbyist programmer. I also know that git was created by Linus Torvalds, it's a DVCS (although Torvalds calls it an SCM), and it's based on a DAG (directed acrylic graph), which is a directed graph with no directed cycles, and excellent for modelling causal relations. I can explain to you the difference between a rebase and a merge. I know that git uses SHA-1 hashes to identify check-ins internally, as a data security feature. I know that checkins and other objects are stored in the .git folder at the repository's root directory. I know that these objects are garbage collected, although the frequency at which they are escapes me. I know that, despite common belief, git commits are immutable, but also that the git history is not. I know that git was inspired by BitKeeper, after the incident that caused the linux source to be moved away from that system, because Linux got fed up with tarballs and patches, and hates CVS with a fanatical passion. I know that git had three design goals: distributed, fast, and guarantees that you get the same bits out that you put in. And I've have several years of causal experience with git, using probably one tenth of its functionality. I may not be able to recite git's internals at you, but I know it's features (to an extent), I know the tools, and I know the reasoning. And the functionality sure as heck isn't magic.
- dozzie 11y ago
  > I need a dependency, my os hasn't packaged it, and it's the path of least resistance. What I tell you back: you probably don't need it, you're just being very, very lazy, which will cost later in bugs in those dependencies, and it's not that easy to fix a bug in a dependency. Additionally, it's not that difficult to make a package with that dependency. I routinely do so, both for things other people wrote and for my code. Sure, it's not as easy as adding a line in package.json, but there should be some friction in adding a library to a project, so the library would justify itself. Keeping many dependencies is very expensive in the long run, but short-term is somewhat beneficial. Look at how it works for Node.js and gems and Python packages: every library needs its own `map()' function implementation (or anything else similarly trivial), so typcial application requires few dozens of other libraries.
efes 11y ago
> Are those programmers using this operating system's tools for software installation? Hardly. And why? Because this is a bizarre argument. I accidentally make dependencies on specific variants of libraries because I don't immediately need to support other variants and lack examples and/or time to worry about theoretical portability. I don't use OS specific packaging because it was intentionally written to be non-portable. My learning it is an irrational commitment to keep using an OS at the neglect of all others and even if its distributor changes (or can no longer honor) the conditions of our deal.
- dozzie 11y ago
  Your dynamic website (often called a webapplication) is very probably OS-specific anyway. I've seen websited that can run only on Ubuntu. Most often you could as well settle with what OS provides to deploy it, especially that you won't need another instance on the same server. Even more so if it's not a hobbyst project, but a professional one. > I don't use OS specific packaging because it was intentionally written to be non-portable. Only if you use it mindlessly. It's not really different to build a package for Debian, Red Hat, Slackware, or Gentoo (been there, done all of these). All it takes is to properly separate downloading sources and building things, which is a good engineering on its own. And guess what you get in exchange? Easy dependency installation, both for development and for deployment.
mitm2mitm 11y ago
So you can link your Github profile to recruiters and add "Creator of project X" in your CV. I hate the amount of garbage and noise created by this. But how many of the good tools we have today wouldn't have existed if people didn't just started coding? It's full circle to your first phrase since if nobody was using nobody would write redundant/worse tools. Man I miss the time programming was only my hobby.

dominotw 11y ago

If there is no central server like github. What do you map origin to?

ossreality 11y ago
You can't be serious...
cyphar 11y ago
That's not how git works... Yes, you can have remotes where you pull your initial state. You can have many remotes -- any git repo you've cloned can be used to host the repo publicly. But after that, you can merge patches that people send you over email (or heck, even via carrier pigeon), do everything you need without a host. In fact some people have made a github-like hosting solution that is decentralised called GitTorrent.
- dominotw 11y ago
  But which one does the team deploy if everyone is sending patches to each other.

mbrock 11y ago

Why do we all rely on communicating through news.ycombinator.com? Because it's useful to have a central hub. It's a very easy system to understand and use. There's no obvious alternative right now. Someone should build one. It's not super easy. There are big and interesting political and technical questions... which GitHub conveniently sidesteps by just being a central server.

qwertyuiop924 11y ago
I was about to post this, but less eloquently, and without the obvious metaphor.
makecheck 11y ago
A central-hub choice of implementation shouldn't be confused with a centralization requirement however. It is possible for distributed systems to still converge on things (indeed, entire papers have been written on the problem of distributed “agreement”), it's just that they must work in a very different way. Indeed, we had this, in the form of NNTP and older news servers; those servers essentially exchanged copies of whatever was posted from around the Internet. If there were no news.ycombinator.com, there could still be a wide variety of servers that constitute “hacker news” around the world, that come to a general agreement on what the collection of posts should be. At any instant in time, not all servers will be 100% identical but for all practical purposes they would be.
- jasode 11y ago
  >A central-hub choice of implementation shouldn't be confused with a centralization requirement however. >Indeed, we had this, in the form of NNTP and older news servers; You're focusing on the technical aspects. The other forces are social and economics. Both of those lead to centralization. Take your example of Usenet news groups. Yes, in a technical sense, it's decentralized but once you get economics/money involved, what happens? My ISP like Verizon doesn't carry all newsgroups (e.g. exclude newsgroups with large binaries.) Or another ISP may carry more newsgroups but the retention is 1 month instead of 1 year. So the economics converges to an central entity like Deja News that emphasizes the archival of usenet posts. Then Google buys them (Google Groups). Google Groups is now "centralized" for finding very old usenet posts. Conceivably, any of us besides DejaNews could have archived the posts but we didn't spend the money on harddrives to store it whereas DejaNews did. Hence, we end up with a centralized archive. When I had Verizon, their newsgroups feed was very poor. I therefore paid $10 extra to GigaNews because they had everything with multi-year retention. That's another "centralized" hub driven by economics. Looking only at the usenet RFC technical specs for distributing news posts doesn't reveal how the economics makes centralization emerge. As for github's centralization... A lot of us want to host a public git repository. Hmmmm... if github didn't exist, what do we do? Pay for a VPS for $9/month plan and host git on that? What about extra bandwidth costs if it's a popular repo and lots of people are cloning it? That's a lot of ugly financial bookkeeping that we don't want to do since we'd rather just concentrate on programming. Wait -- there's an ABC company out there that lets me conveniently host a git repo there? For free? Sign me up! That "ABC company" by way of economics and social dynamics has turned out to be Github and BitBucket. And since Github has been winning the mindshare, you get centralization. There is no irony in git-the-tool being distributed and github-the-focal-point being centralized.

volaski 11y ago

It's nothing new or ironic because that's exactly the definition of centralization. Here's the definition: "concentrate (control of an activity or organization) under a single authority." There has been and will always be systems that try to centralize already existing distributed entities.

exolymph 11y ago

Centralization happens naturally. There's a reason why we see it again and again. https://medium.com/@Exolymph/i-swear-i-m-not-a-statist-df99079f0086#.ib4qa0nyw https://medium.com/@Exolymph/i-swear-i-m-not-a-statist-df990...

jotux 11y ago

I really don't understand your argument. Git is for decentralized development but there has always been a need for a central server to host the repo and github made a business out of providing that along with additional services (pages, wiki, issues). The dear-github complaints are overwhelmingly about the secondary services github provides for project management. >Why did people set up systems that depended on the ability to download from GitHub, for instance? Because if they didn't rely on github they'd have to rely on some other server subject to similar downtime?

emmelaich 11y ago

You could use a distributed bug tracker like http://www.bugseverywhere.org/ http://www.bugseverywhere.org/ "Bugs Everywhere is a “distributed bugtracker”, designed to complement distributed revision control systems. By using distributed revision control as a backend for bug state, we gain several convenient features: ..."