Live data from Hacker News

GitHub had connectivity problems

status.github.com

171–175 of 175 posts

Re: GitHub had connectivity problems

#171
post #166

Earlier quoted context omitted.

I'd imagine that for legal/security reasons, you'd get about the same response as any other company: "We use better than industry standard encryption on private repo data, encrypted with AES-1024 and encrypted in transit via TLS-3 etc etc..." But, I don't know. What was that quote? "Don't put anything on the internet that you wouldn't want to see on your grandma's coffee table."

I don't think most people would mind having their source code on their Grandma's table. Free off site backups :)

Touche. You'll be the first invited to my new BGCTaaS business then—Backup to Grandma's Coffee Table as a Service.

Re: GitHub had connectivity problems

#172
post #169
post #168

Earlier quoted context omitted.

You called me :) Anyway, installing GitLab should take under 5 minutes on a fresh Ubuntu 14.04 server with https://about.gitlab.com/downloads/ And then you can set a daily nightly cron for: sudo apt-get update sudo apt-get install gitlab-ce Don't forget to take snapshots of your server for backups.

> And then you can set a daily nightly cron for: sudo apt-get update sudo apt-get install gitlab-ce AHHHH!!!! Don't recommend doing that. Only those who are crazy do that. Imagine waking up in the morning and your SCM system is broken due to an update that was automatically applied - I wouldn't want a sysadmin (or developer) to see that before their first cup of coffee. When you update - does it automatically apply m…

For the reason mentioned it is better to set the timing during the day (that is what we do). But if you upgrade automatically during the day you'll have a bit of downtime during the day.

By default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. The behaviour can be changed by adding a /etc/gitlab/skip-auto-migrations file.

Obviously if you installation grows you can review the needed upgrades in advance and prevent downtime in most cases.

Re: GitHub had connectivity problems

#173

Does anyone else find the Github status "messages" page [0] a bit jarring in how it's organised? The way that, when read from top to bottom, time goes forwards within a day but backwards across days? I guess I normally wouldn't notice, but there are currently some messages on there from today and yesterday and I found it hard to read as a story (either forwards or backwards) - I had to jump around a bit to figure it…

It's fixed now ^_^

Re: GitHub had connectivity problems

#174
post #134
post #95

Earlier quoted context omitted.

Design looks very, very confusing regarding timestamps. https://i.imgur.com/wminZWg.png

It probably uses the local time zone name (for me it shows CEST) and was written by someone who assumed all time zone names are always abbreviated.

I also live in CEST.

Re: GitHub had connectivity problems

#175
post #61

Earlier quoted context omitted.

What makes you think Github is "large and well connected"? Don't get me wrong, I love GitHub, but due to their architecture decisions, they aren't anywhere near a great example of best practices in the industry for preventing DDoS attacks.

I'm intrigued. What architectural decisions?

One that would really help with DDoS attacks is if they didn't do everything on github.com. Layer 3 DDoS mitigation will always be cheaper and more effective than Layer 7. If it's not obvious what I mean, here's an example:

Current: http://github.com/jsjohnst/project

One (of many) better approaches: http://jsjohnst.github.com/project

Post reply on HN