Live data from Hacker News

GitHub dropped Pygments

greghendershott.com

41–50 of 133 posts

Re: GitHub dropped Pygments

#41
post #34

Earlier quoted context omitted.

Dear downvoters, have you heard of the Streisand effect? This thread now has the most downvotes (-14) of the many comments I've posted on HN. There is nothing factually incorrect in my posts. Why does this question deserve five downvotes? > Why not give existing users the choice of migration and timing? Edit: -20 downvotes. Previous record was -3.

This situation is very different from the Streisand effect. In the Streisand effect a single party is trying silence everyone else. Here everyone is trying to silence you. They are nearly opposite situations. A minority trying to silence a majority vs a majority trying to silence a minority. In both situations the majority wins.

Downvoting is (afaik) for not meeting the norms of polite / intelligent discourse as opposed to "we disagree with your opinion". There are opinions which if expressed breach out taboos - the usual range if racism sexism etc - but this is certainly not the case here.

So no, I think downvotes for a comment that is polite, intelligent, on topic and part of a discussion was the wrong use of downvotes.

I still don't agree with it of course :-) User choice is a bugger on cloud services especially where they are shelling out to run the pygments lexer.

On top of which is probably the interesting issue that there is no longer a binary on/off for most features. AB testing, feature toggles, stayed rollouts all mean we never quite know which version of a service we are running.

Re: GitHub dropped Pygments

#42

This sort of thing feeds my paranoia about GitHub being a giant single point of failure in the open-source world. I know the argument: Someone, somewhere has a copy of each repo checked out, so we (the nebulous "we") could reconstruct everything from the diaspora of ".git" directories. It just bothers me to think how dependent OSS has become upon GitHub.

Why do you think that that is limited to open source? Plenty of businesses utterly rely on github in their workflow.

It's not limited to open source, but commercial enterprises pay for GitHub's services, so at least there's some sort of service agreement. OSS depends upon GitHub's largesse (which is extensive). However, if GitHub changes its mind (deciding, for example to focus on selling code-editing software), or if something goes wrong with the commercial side, then OSS is left high and dry.

Re: GitHub dropped Pygments

#43

This sort of thing feeds my paranoia about GitHub being a giant single point of failure in the open-source world. I know the argument: Someone, somewhere has a copy of each repo checked out, so we (the nebulous "we") could reconstruct everything from the diaspora of ".git" directories. It just bothers me to think how dependent OSS has become upon GitHub.

I don't think it's paranoia. I think it factually is a single point of failure, which is a bad thing(tm). And GMail is a single point of failure for my (and my companies) e-mail, and that bothers me too, despite the fact that I'm not doing anything about it :)

Google is a giant single point of failure. Others would rush to fill the vacuum, but it'd be a brutal few months (years) while we all relied upon Bing.

Is there any GitHub-esque outfit waiting in the wings that provides free OSS hosting?

Re: GitHub dropped Pygments

#44
F# highlighting is also now totally gone with this change. Code is highlighted with some random lexer than doesn't even understand // comments. Rather frustrating, given that a lot of F# development is centered around GH, and GH themselves use F# in a couple of places.

Browsing the issues list, this isn't just "fringe" languages, either. Perl, PHP, Go, and Clojure all appear to have regressed to some degree.

Re: GitHub dropped Pygments

#45

Earlier quoted context omitted.

There is value in the aggregation of repositories which is separate from individual repos.

True, but it's anything but the end of the world if GitHub vanished from the face of the Earth right now. Everything would be running full steam within a week.

I disagree. Many OSS projects rely upon GitHub, especially projects that package or distribute other projects. Sure, everyone would eventually work out their own hosting, but it'd be a nightmare of changing URLs and uneven servers in the interim. I think a week would be extraordinarily optimistic.

Re: GitHub dropped Pygments

#46
post #34

Earlier quoted context omitted.

This situation is very different from the Streisand effect. In the Streisand effect a single party is trying silence everyone else. Here everyone is trying to silence you. They are nearly opposite situations. A minority trying to silence a majority vs a majority trying to silence a minority. In both situations the majority wins.

That is true if all downvoters are independent. Keep in mind that HN has cultural norms for downvoting, it is explicitly not for "silencing" opinions.

> HN has cultural norms for downvoting

Those cultural norms are not written into any of the faqs or guidelines and they only exist within a subset of the users of the site.

I don't know why you were downvoted so heavily! I would have thought that a few downvotes would have been enough.

Re: GitHub dropped Pygments

#47

This sort of thing feeds my paranoia about GitHub being a giant single point of failure in the open-source world. I know the argument: Someone, somewhere has a copy of each repo checked out, so we (the nebulous "we") could reconstruct everything from the diaspora of ".git" directories. It just bothers me to think how dependent OSS has become upon GitHub.

I don't think it's paranoia. I think it factually is a single point of failure, which is a bad thing(tm). And GMail is a single point of failure for my (and my companies) e-mail, and that bothers me too, despite the fact that I'm not doing anything about it :)

This planet is also a single point of failure. If a meteor strikes, all our code will be lost.

Re: GitHub dropped Pygments

#48

This sort of thing feeds my paranoia about GitHub being a giant single point of failure in the open-source world. I know the argument: Someone, somewhere has a copy of each repo checked out, so we (the nebulous "we") could reconstruct everything from the diaspora of ".git" directories. It just bothers me to think how dependent OSS has become upon GitHub.

> GitHub being a giant single point of failure

What is our definition of a "point"?

If you have an external hard-drive backup of your laptop, that's 2 points of failure, right? If someone else has 10 external hard-drives that they keep in different places, that's 10 points, yes? But what stops you from calling all those hard-drives "a giant single point of failure"? If all of them are destroyed, the data is lost.

I just don't get these arguments... The chances of all GitHub data being lost is probably less likely than BitBucket and SourceForge combined.

Re: GitHub dropped Pygments

#50

This sort of thing feeds my paranoia about GitHub being a giant single point of failure in the open-source world. I know the argument: Someone, somewhere has a copy of each repo checked out, so we (the nebulous "we") could reconstruct everything from the diaspora of ".git" directories. It just bothers me to think how dependent OSS has become upon GitHub.

Would a P2P version of GitHub make sense? Each outward-facing local repo would provide a GitHub-like interface for browsing code, submitting PRs etc., and would in addition route repo search requests to neighboring repos using something like a Gnutella protocol.

I don't think that would work well...Github has too much momentum. But I think open protocols and folding more of the functionality that has been proven out at Github into the core SCM could have a very positive impact.

To start with, pull requests could be implemented in the main git tool. They're no longer experimental and many, if not most, git users rely in them in some form or another (Github, Gitlab and BitBucket all support them). Folding them into the core would just standardize all the implementations.

It would also be good to define protocols for collaboration. Off the top of my head, that could mean a fork:// browser protocol that would allow a BitBucket user to fork a Github repository and seamlessly submit pull requests back upstream. Some of that is possible today, but there would be some new requirements around federated authentication to enable this (i.e. how to allow a user who is registered with a different service to create a pull request).

If the mechanics of interoperability are standardized, people will develop competitors to Github and things will get more decentralized. But, as mentioned above, Github has a lot of momentum and no incentive to cooperate with other providers. The only way they're really forced to work with others is if these changes and standards are coming from the core Git project.

Post reply on HN