Hacker News Reader

Comment by makecheck | Hacker News Reader

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?

View on HN

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.

I was about to post this, but less eloquently, and without the obvious metaphor.

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.

>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.

Sadly, most people have forgotten about Usenet... or never knew it existed. The typical web forum is vastly inferior to most news clients.

Well, Usenet had basically no way of doing moderation, right? That's a pretty big missing feature from the perspective of forum administrators.

There are moderated groups. The NetNews Moderator's Handbook[1] has technical details (and more) but basically:

    'Moderated' means that all postings to the newsgroup go to a mail
    address (e.g. comp.std.unix@uunet.uu.net) instead of appearing
    in the newsgroup directly. The postings are then forwarded via
    email to a moderator, or group of moderators, or even an automated
    program, who decides whether to actually inject the article into
    the newsgroup or to reject it as not meeting guidelines spelled
    out in the group's charter.

1: https://www.eyrie.org/~eagle/usefor/other/moderators-handboo...

And there was one group, alt.hackers, that was moderated, but had no moderator, by design. It kept the signal-to-noise ratio pretty high.

Notably, though, USENET moderation was managed entirely by the addition of a single, unverified, header to the message ("Approved: cuzisayso"). This allowed for simple distribution, but equally simple circumvention.

Proper moderation for anything important would require cryptographic signatures and a solid federated PKI. Maybe the world is ready, this time. :)

I think the world is ready for someone to make an actual implementation and start using it for some actual conversation!

As long as you have an actual living conversation, then an open model of development can work... which means it doesn't have to be perfect from the start, and you don't need a beautiful landing page, because you want to attract the hackers and crazy people.

You also want to encourage lots of forks and independent implementations, because if it turns into some big mega-repository with some big bloated thing that includes Scala, Erlang, Babel, Bootstrap, and who knows what other ungodly monsters, then it's just going to become a boring monstrosity.

So you'd start with inviting a few people and then encourage them to use their own servers and clients. Make sure everyone understands that the protocols are in flux because you're trying to figure out together what will work.

The conceptual simplicity of Git would be an inspiration. There are different implementations of Git... but we could be even more obviously amenable to that, by using standardized messaging formats for example.

I think plain text messages, as on Usenet and mailing lists, are the best. You don't have to agree on a Markdown/whatever complex thing. Attachments if you want to send other documents. Hacker News developed consensus formatting for links and footnotes, and we seem to get on fine without inline images and tables and all the other fancy nonsense.

(Just some random thoughts...)

I agree. It'd be great fun to build something incorporating everything we knew about distributed and federated systems in the days before their incompatibility with business models became an issue.

There's a lot of good stuff in XMPP, too. As well as some pre-discovered dead ends.

Yeah. From a hacker's perspective, a business model is just some way to keep a thing up and running. If it doesn't create a bunch of jobs at some office somewhere or lead to an IPO, well, that's just worldly affairs, right?

The distributed/federated stuff is still alive, maybe more than ever. Git is a fantastic example. I push and pull repositories between computers all the time. Often over ad-hoc WiFi, even.

Usenet and all that stuff is beautiful to reminisce about, but we should keep in mind also that it was largely sponsored by universities, corporations, militaries, and internet service providers...

IRC is a great inspiration too. Nowadays people look at it and think "ew, no Unicode" or "duh, it's not even JSON," but considering its resilience, its simplicity, its adoption, it's an enormous, staggering success.

These beautiful projects that started as tiny little seeds by clever obscure Scandinavian hackers...

It's just all about starting a little thing, getting your friends in on it, and keepin' it hella real.

True, although keep in mind that while USENET's bandwidth was definitely sponsored, the technology (above the TCP layer) was built by hackers as a side project. At some point Larry Wall (e.g.) got a job just being himself, but for a long time he had unrelated professional responsibilities.

Since the bandwidth funding model has now bubbled down to the consumer marketplace, it seems like the conditions are right for a huge variety of services. Actually that was starting to happen before the web swallowed all other services. Don't get me wrong, the web was/is a great thing, but it severely dumbs down the range of protocol expression. The state of websockets in 2016 is a weak imitation of IRC or MUD capabilities more than 20 years ago (never mind adoption problems).

I guess that's a curse of being "good enough". The better has an uphill battle.

You could "kill file" a user, which meant you wouldn't see any of their posts, but other people still could.

What I like about news readers is how they track new threads / messages. I could pick up where I left off. It encouraged longer term, more elaborate discussions, as opposed to posts that fall off the first couple pages like most web forums.

I agree that NNTP was a nicely federated system, and just a couple of days ago I was pondering the use of NNTP to publish Git pushes. Git's support for signed commits and content addressed objects is a great start for distributed, trustworthy collaboration. I still can't envision exactly how it would all function. There are lots of benefits to the GitHub model. They're a semi-trusted and well-funded entity who guarantee a highly available and fast synchronization. Sure, when it goes down everybody has a problem for a while... but with more distributed models you can get way more complicated failures, like "this object isn't seeded by a connected peer right now" or "this federated shard doesn't carry this repository" or whatever it may be.

I'm really interested in the future of distributed code collaboration. I just think it's not so trivial, and so it's very understandable that people have gravitated towards a semi-centralized model that already works.

> I agree that NNTP was a nicely federated system, and just a couple of days ago I was pondering the use of NNTP to publish Git pushes. Git's support for signed commits and content addressed objects is a great start for distributed, trustworthy collaboration. I still can't envision exactly how it would all function.

Perhaps having something akin to a private NNTP server that requires authentication to post for each open source project, but is publicly viewable. These news servers could be configured to send IHAVE <article> to other news servers to increase visibility. There could be a newserver like gmane to aggregate the feeds from each of those private news servers.

If you could get an authentication system that could work across those news servers, then you could have a decent system for keeping up with and contributing to open source projects.

The obvious alternative is using git through a mailing group like Linux has been doing for years. I say obvious because it's the workflow for which git was built in the first place. ;)

It's amazing to me that git's power to easily manage distributed software development been lost/forgotten with Github. You don't need a web interface to contribute code. Linux is doing just fine.

You just need git and some sort of communication tool to distribute patches, email being the most powerful, flexible, and ubiquitous I've seen.

Yeah, Git over email is really neat. But GitHub also has a role in hosting repositories for cloning and pulling...

Git can do that as well with a --bare repo on any $5 virtual server. The whole setup only takes a few minutes, and Github's doing that in the backend anyway. :)

Sure, but those servers will have much worse availability than GitHub, on average...

Then up it to $10 and host identical copies across EC2 and Linode or Digital Ocean. Set up a git hook to automatically push from your primary to your secondary server, keeping both up to date. You now have better uptime than Github (100%, more or less) for less money than Github charges and greater control.

Yeah, but GitHub does this for, like, a hundred thousand projects. That's a lot of repeated effort if every project is going to do this themselves. For private repositories, sure, but I'm thinking of GitHub as an infrastructure provider.

> You just need git and some sort of communication tool to distribute patches, email being the most powerful, flexible, and ubiquitous I've seen.

I would say that having a private NNTP server (one requiring an account to post) would also work in lieu of email. In fact, it would be better than email because it would allow new members to easily browse list archives. At least gmane already does something like that for some mailing lists.

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?

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.

"It takes a long time to understand" is synonymous with "can be improved."

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.

Counterexample: the universe.

I think the universe has a long list of outstanding feature requests.

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.

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.

> 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.

Writing yet another map implementation is not solving any problems.

People get so bizarrely bent out of shape over npm dependency quantity rather than ease of use.

Hey, I was just saying that that's the common idea, not that I think that way.

Personally, I use NPM because NPM does local versioning, so I will never end up in dll hell.

Also, NO, NEVER WRITE A PACKAGE THAT HAS EXPLICIT KNOWLEDGE OF A DISTRO PACKAGE MANAGER. If you do, you are being an asshole. If you want to depend on a distro specific package manager, document your dependencies, and just expect them to be there. Because not everybody uses your package manager.

If you have proper package building rules (not this currently popular fpm nonsense, which produces broken RPMs and DEBs unless one puts much effort in using it), tearing building procedure apart and adjusting it for other package managers will be really easy. No, you're not being an asshole. And if you want to be it even less, write a proper makefile and call that from package build rules (RPM spec, debian/rules, ebuild, or anything else).

You should be writing Makefiles, or Scons, or whatever your build system is.

> 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.

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.

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.

You could use a distributed bug tracker like 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: ..."

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-df990...

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.

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

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.

But which one does the team deploy if everyone is sending patches to each other.

Reply on news.ycombinator.com