121–130 of 147 posts
It seems like it's only a matter of time before something will have to give. Either they'll have to start throttling web serving or cover the site in ads like sourceforge or something
I guess I'd better sign up and start paying ASAP to help be part of the solution
Earlier quoted context omitted.
Your company runs its source revisions through Github without a backup solution? Do you really put all your eggs in a basket you have no control over? I know that in theory a cloud solution should have a higher uptime than an amateuristic set up private server, but cloud solutions have a certain complexity and coherence that make them very vulnerable to these kinds of 'full failures' where nothing is in your control.…
Add up your downtime over a three year period by relying on Git (or gmail, or AWS) versus the cost of trying to engineer some local-backup system, and the downtime associated with that going awry. Outages happens - as long as we're talking hours a year, pretty much everyone but life-safety systems, critical infrastructure, and payment/high-traffic commerce sites are probably better off just letting third-party cloud…
Earlier quoted context omitted.
Github is definitely in 2-digits this year.
I doubt it. (Assuming by 2 digits you mean 1% downtime is over three days. They've had some big outages, but I think this may be their longest of the year and it was a < 6 hours. They could have one of those every month and still only have 72 hours of downtime, which is 99.18%.
Earlier quoted context omitted.
Exactly. I'm sitting here thinking "poor GitHub engineers" rather than "oh crap, how am I going to work?" (Though I do wish GitHub Issues weren't as centralized...)
One of the neat things about repos in Fossil (the DVCS by drh of SQLite fame) is that they have a built-in wiki and issue tracker whose contents are version controlled along with everything else in a project's repo. The Fossil executable also has a built-in web server that presents a web interface for working with the repo, including the issue tracker and wiki. In short, if you have a project's Fossil repo, you can w…
That's a really nice status dashboard, tracking and publicly displaying your 98th% is really cool. On the other hand stuff like this: "13:17 UTC We are seeing unicorns ..." Comes off as un-professional at exactly the wrong moment.
Github switched to the Unicorn server ( http://unicorn.bogomips.org ) some time ago. Sorry if you don't like the name but, uhm well, it's the name of the server they use. Anyways. Error pages featured an "angry unicorn" since then, so when they are saying "we are seeing unicorns", most users know that this translates to errors..
Earlier quoted context omitted.
Other posters have noted where the terminology comes from. But you should really learn to take the meaning of an unknown term from context if you don't know what it means. As for the accusations of unprofessionalism -- I'll take vivid metaphor [1] like "seeing unicorns" over a dull monotone description like "our site is experiencing server errors." [1] As other replies have pointed out, in this case it's not a metaph…
May be just a matter of preference but for me "our site is experiencing server errors" is much clearer communication than "seeing unicorns." The latter requires me to learn a new terminology in a high pressure environment for no good reason . And if "seeing unicorns" was a code word for a specific kind of errors, then again I would rather have a more descriptive terminology and not one that I may confuse for an insid…
Status messages should be communicated with no unnecessary ambiguity both internally (where unicorns may be the clearest term) and externally (where it is not).
Lack of clarity during periods of heavy human workload is a common cause of e.g. plane crashes. Operations people of the internet would do well to learn from mistakes made before the cloud was a thing.
Earlier quoted context omitted.
Yup. I wanted to do some coding before heading off, but I guess that's off the table now.
What? That's the complete opposite of what OP was saying. You don't need github to be online to work with your code or even your repositories so long as you haven't gone and thrown all your digital eggs in the same basket (i.e. as long as you have other remotes or at least local copies of your repositories).
Earlier quoted context omitted.
I think kmfrk is implying his place of employment doesn't use git.
I don't think so, because it's GitHub that's down and I think kmfrk would have mentioned it if his other service was coincidentally down at the same time. I think what kmfrk meant is that he can't operate without GitHub's issues. It isn't ideal but it's understandable.
I'm really curious how much longer github can offer so much free service. It's not just git but effectively free web hosting as well, at least for statically served pages. It seems like it's only a matter of time before something will have to give. Either they'll have to start throttling web serving or cover the site in ads like sourceforge or something I guess I'd better sign up and start paying ASAP to help be part…
I'm really curious how much longer github can offer so much free service. It's not just git but effectively free web hosting as well, at least for statically served pages. It seems like it's only a matter of time before something will have to give. Either they'll have to start throttling web serving or cover the site in ads like sourceforge or something I guess I'd better sign up and start paying ASAP to help be part…
Think of it less as a free service and think of it more as marketing. I have a few free repos which I used to open source some of my personal modules; however when it came time to select a source revisioning service for work, I remembered how easy GitHub was and went with their payed service. I am fairly sure us now paying for our repositories offset itself and my and quite a few other free repositories.