Hmm, I think we understood 'local' as two different things. I understood it as a self hosted git server, like on premises in parent's company that he and his colleagues would use. Now that you mentioned it, I'm starting to think I understood it wrong.
You can merge from anywhere, not just Github master. It's a little more work, but a coworker could share their repository without much difficulty. You can even apply patches sent over email, if you're so inclined.
All legitimate solutions, I agree. The thing is, it really sucks when this happens over the weekend. Alerting a colleague in their off-hours to be able to continue with your work is not ideal. Of course, it happens rarely, so you're making a good point. If it happened weekly, that would be another story. :)
Can't they at least fix their status page? https://www.githubstatus.com/ It returns `All Systems Operational`. I mean what's the point of having a status page if it returns wrong info?
These things don't/can't get updated instantly. I was doing some work as of ~5 minutes ago and it was working fine, and is unavailable now. If it is a major outage it will likely be updated shortly.
Large orgs (like Github) don't want or use automated status updates. There is usually always some service having issues in complex systems and immediately updating a public status page does more harm than good, including false alarms which may not affect anything public facing.
More harm than good to the company's own long-term reputation.
A status page is a kind of PR. Think of it like a policy for a flight attendant to come out into the cabin to tell everyone what's going on when the plane encounters turbulence. That policy is Public Relations -driven. You only do it if you expect that it's positive PR, compared to not doing it — i.e. if telling people what's going on is boosting your reputation compared to saying nothing at all.
If a status page just makes your stakeholders think your service is crappy, such that you'd be better off with no status page at all... then why have a status page? It's not doing its job as a PR tool.
I read the line specifically as "The employees can do better; they just don't want to try."
But that's not true. The company could do better. But the individual employees cannot. The individual employees are constrained by the profit motive of the company. They are not allowed by corporate policy to set up automatic status updates, for about the same reason they're not allowed to post their corporate log-in credentials: that the result would very likely be disastrous to the company's bottom line.
(Though, really, the corporations in most verticals are in a race-to-the-bottom in most respects. Even if you treat GitHub as a single entity capable of coherent desires, it probably doesn't desire to avoid automatic status updates. It needs to avoid them, to survive in a competitive market where everyone else is also avoiding them. People — and corporations — do lots of things they don't want to do, to survive.)
No, I don't think they can. An MMO is a very simple system, in that there's only one Service Level Indicator (SLI) that devs, shareholders, and players all agree on. That SLI is "can a player connect to the server, and perform regular gameplay actions, without a ridiculous amount of per-action latency."
GitHub, meanwhile, is a million different things to a hundred million different people. Users of e.g. Homebrew, with its big monolithic ports system hosted as a github repo, have a very different SLI for Github than do users of some language-ecosystem package manager that allows you to pull deps directly from Github; than do people who depend on GitHub Actions to CI their builds on push; than do people doing code-review to others' PRs; than do people using Github mostly for its Wiki, or Issues, or downloading Releases, or Github Pages, or even just reading single-page-with-a-README repos, ala the various $FOO-awesome projects.
For many of these use-cases, Github isn't degraded right now. For others, it is.
If you ask for Github (or any service with this many different use-cases and stakeholders) to measure by the union of all these SLIs, then the service would literally never be not-degraded. In systems of sufficient scale, there's likely no point where every single component and feature and endpoint of the system is all working and robust and fast, all at once. Never has been, never will be.
And anything less than just going for the union of all those SLIs, is asking Github to exercise human judgement over which kinds of service degradation qualify as part of their own SLOs. Which is exactly what they're doing.
Certainly, internal to services like this, there are all sorts of alerting systems constantly going off to tell SREs what things need fixing. But not all of those things immediately, or even quickly, or even ever, translate to SLO violations. There are some outlier users whose use-cases just break the system's semantics, where those use-cases just aren't "in scope" for the SLO. As long as those users are only breaking the system for themselves, the degradation they experience won't ever translate to an SLO breakage.
You seem to be applying different rules to MMOs and Github, and I don't understand why. I'd say that there are many ways of looking at this; there exist complex MMOs; and one could look at Github from the point of view of an average user.
E.g., a bit tongue in cheek:
> An MMO is a very simple system, in that there's only one Service Level Indicator (SLI) that devs, shareholders, and players all agree on. That SLI is "can a player connect to the server, and perform regular gameplay actions, without a ridiculous amount of per-action latency."
Wouldn't you say that in an MMO of sufficient scale there's likely no point where every single component and feature and endpoint of the system is all working and robust and fast, all at once?
> In systems of sufficient scale, there's likely no point where every single component and feature and endpoint of the system is all working and robust and fast, all at once. Never has been, never will be.
Couldn't we redefine SLIs as "can the user connect to the server and perform regular user actions without a ridiculous amount of per-action latency"?
> and one could look at Github from the point of view of an average user.
My point was that Github has no "average user." Github is like Microsoft Word: each user only uses 10% of the features, but it's a different 10% for every user. Yes, there are some features that are in the critical path for all users (loading the toplevel repo view in the website might be one); but for any given particular user, there will be plenty of other features that are also in their critical path.
An MMO, meanwhile, does have an "average user"; in fact, MMOs have ideal users. An MMO's goal is to induce every user (player) to play the game a certain way, so that the company can concentrate their resources on making that particular play experience as polished as possible. There is, per se, an idiomatic "rut" in the road that players can "click into", ending up doing exactly the same short-term game loops that every other player before and after them has also done when playing the game.
MMOs can be reduced to a single SLO: can the ideal player have fun playing the game at the moment?
GitHub cannot be reduced to a single SLO, because there is no ideal user of GitHub. There are probably two or three thousand separate "ideal users" (= critical, non-universal user stories) for GitHub.
> Wouldn't you say that in an MMO of sufficient scale there's likely no point where every single component and feature and endpoint of the system is all working and robust and fast, all at once?
No, not really; MMOs have a complexity ceiling by operational necessity. They aren't composed of a ridiculous sprawling array of components. They might use Service-Oriented Architecture, but in the end, you don't scale an MMO vertically by making more and more complex clustered systems with master-to-master replication and so forth. You scale MMOs by either pure-vertical hardware scaling, or by horizontal shared-nothing sharding.
(The key thing to realize about MMO servers is that they're OLTP servers — they need to track a whole bunch of users doing a whole bunch of simple actions at once; and therefore they can't really be doing overly-much computation on those actions, lest they lose shared-realtime verisimilitude.)
I think you underestimate the complexity of MMOs. They can host truly massive events, e.g. https://en.m.wikipedia.org/wiki/Battle_of_B-R5RB . With so many different play styles and optional components (guilds, pvp, official forums, paid content, user made content, etc), I’d say defining an ideal MMO gamer is just as easy as defining an ideal SaaS user.
Not sure if any MMO reaches Github level, most likely not. But I don’t think there is a ceiling or any sort of hard distinction; i.e. I think 5 years from now we could have a MMO with complexity of today’s Github. Maybe it will be called a metaverse though.
I should mention that I've worked as an infrastructure engineer on both MMOs and GitHub-like enterprise-y services.
EVE is literally the only exception to "MMOs scale by horizontal shared-nothing sharding"; and that's why I mentioned the option EVE uses instead — namely, "vertical scaling of hardware" (i.e. having a really honking powerful single-master multi-read-replica DB cluster.)
In neither case is anything "clever" (i.e. inefficient for the sake of developer productivity / enterprise integration / etc.) happening. There's no CQRS message queues, no async batch writes, no third-party services halfway around the world being called into, no external regulatory systems doing per-action authorization, no separate "normalized data warehouse for OLAP, denormalized data for runtime" forking writes, no low-level cross-replicated integration between a central multitenant cloud system and individual enterprise-hosted tenant silos, etc etc.
> With so many different play styles and optional components (guilds, pvp, official forums, paid content, user made content, etc)
I think you misunderstood me when I said that there's a rut that users are guided into. The thing about MMOs is that the ideal user uses all the features (because the game incentivizes doing so, and because the more deeply and broadly users engage with the game's systems, the higher their retention / lower their churn will predictably be.) The ideal player is in both a party (or constantly switching parties) and a guild; has paid for all the DLC and regularly buys cash-shop items; plays every piece of PVE content you build; engages in PVP content and co-op UGC content all the time; etc.
Which is to say, for the ideal user, "the game" either works or it doesn't, because "the game" is the whole thing. Every feature needs to work, in order for the game to work. Because the ideal user engages with every feature. The SLO is, essentially, "can you do a completionist run through every bit of content we have." (If you're clever, and can make your server deterministic, you can create a completionist run as a backend-event demo file and run it in CI!)
And this is, in part, why MMOs are kept architecturally simple. Everything needs to work!
(And I don't just mean "simple" in terms of the backend not being a sprawling enterprise-y mess, but rather usually a single monolithic binary that can keep a lot of state in memory. I also mean "simple" in terms of as much of the game as possible being pushed to local, mostly-ephemeral-state client-side logic. MMOs are, often, a lot less "online" than one might think. It's very hard to "break" an MMO with a content update, because most content updates are to zonal scripts whose state doesn't persist past the lifetime of the in-memory load of that zone in a particular interacting device.)
With GitHub, their ideal users — of which there are many — can be individually satisfied by very small subsets of the system, such that they're still satisfying almost all their users even if one system is horribly breaking. That's what an SLO is "for", in the end: to tell you whether different subpopulations of users with different needs are happy or not. If you only have one "core" subpopulation, one ideal user, then you only need one SLO, to track that one ideal user's satisfaction. If you have more, you need more.
I understand and I had a similar understanding with your earlier comment. I still disagree with: "The thing about MMOs is that the ideal user uses all the features". This seems not a property of MMOs, this seems just a way of working with MMOs.
They have a banner "Investigating - We are investigating reports of degraded performance for GitHub Actions. -- Nov 27, 20:43 UTC" which should suffice for a start.
1. It clearly indicates that automatic systems are failing to detect the outage.
2. It also indicates that no one is aware about the incident to manually signal the outage (or that there is no manual override).
Basically, it makes a difference between "yeah, shit happened, we know (and maybe working on it)" and "hah, they don't even know themselves".
Partially because these large systems have some kind of ongoing issue at any given time, so it's challenging to provide a meaningful live status that isn't a bit misleading and could cause misdirected panic.
Partially because you don't want to give potential attackers (eg ddos) any insight if/how their methods are affecting your systems.
Partially because there are SLAs and reputation at risk, and you don't want to admit to any more downtime than you absolutely have to.
If you had a really robust system, it'd be fun to just slap a read-only mirror of your internal metrics dashboard onto the public Internet for anyone to browse and slice as they please. It'd be a brag, kinda.
Of course, in the real world, I don't think there's a single IT admin who didn't just start nervously sweating and pulling at their collar after reading the above, imagining it as something their CEO said and encouraging them to target it. Nobody can really do this — and that in turn says something important about how those metrics really look in most systems.
FWIW, I've worked on systems that have internal SLAs orders of magnitude higher than what they promise to the public. I think it's more just that there's no advantage to doing something like this as long as none of your competitors are. The status quo is that people's systems are really opaque and vastly underpromise what they should be capable of, and in exchange you get to absorb some unplanned downtime due to issues with underlying systems that you have little control over.
Yeah it seems company status page lost its infancy stage where companies were actually honest about their outages. Bit similar what happened to online reviews.
I don’t work for github, so on a personal note I was about to create an issue in a repo, and it wasn’t loading. My go to “is my router messed up?” check is to load HN because it’s so reliable and fast. And lo, the top post was about github being down!
Ha. I checked HN for the same reason, I was not able to reach Github via university network and I thought that was the time my university messed up with DNS.
HN seems to be going down for the massive amount of requests!
Status pages are almost never automated these days, they cause more problems than they solve.
To be fair, redditstatus.com is quite nice with their sparkline headline metrics. It at least lets you know _something_ is happening even if they haven't yet declared an incident.
In my last job our main “is everything okay?” monitoring dashboard had RPS, latency, 500 rate etc and a line for the number of user issues reported per N requests served. We didn’t alert on this but it was a useful way to detect issues that were subtle enough not to trip up our main alerts.
A telco I used to work for did this like two decades ago but even better, they mapped incoming support calls (customers) to stations, and if more than N came in during a certain period for the same DSLAM it triggered some kind of alert.
Same thing happens (should happen) when you visit your ISPs website and look for registered downtime — many requests from one zip code from multiple ips should trigger an alarm if the isp is competent.
That might be a good idea as a last-resort measure, but if you're only finding out problems because customers are telling you about them (even indirectly through a signal like this), your monitoring and alerting is woefully inadequate.
Generally I agree. Humans are much better at recognizing patterns than machines.
But as a counterpoint I was once working in a project where our monitoring dashboard showed an anomaly in incoming traffic. It turned out that it was an ISP problem and that we were the first ones to notice according to them.
So maybe part of the answer as to why customers are faster is that different monitoring systems are monitoring each other :)
They should also monitor HN's submission with GitHub mentioned. Judging from historical pattern it is probably faster than monitoring traffic on status page or even twitter.
Github.com does not work properly (borderline on "at all") in a browser, and I cannot download a release of one project via curl. This sucks. And is definitely not just "degraded performance for GitHub Actions".
In any other situation I'd recommend it since it really was the tool of choice for decentralized git repos with lots of cool features. (Despite the "Empowering developers with DeFi building blocks like NFTs, token streams, and more" mentioned on the home page which throws me off)
Edit: It seems like the download page is up and working now.
That would be great. But Github is a massive coordination point with network effects and free tiers so it's not so easy to compete. Some other challenges:
- despite being decentralized, you still need moderation and access control
- open source projects typically aren't great at frontend UI/UX
It would be neat if I could publish git repos on IPFS and receive patches from people. It's just hard to compete with a centralized, CDN'd service where you can click and get a result in 100ms.
Hmm, great idea. We could build on Git as a storage medium, and we'd need a durable and reliable way to exchange patches. Something like ...email?
$ man -k patches
git-am(1) - Apply a series of patches from a mailbox
git-format-patch(1) - Prepare patches for e-mail submission
git-imap-send(1) - Send a collection of patches from stdin to an IMAP folder
git-send-email(1) - Send a collection of patches as emails
Ironic that you're pondering Git as a solution to Github's self-created centralization problem.
Even if you were to find the data somewhere, GitHub grew a lot after MS and added a lot of features, including the now most popular CI, so it's not a great comparison.
I have a status page that is automatically and manually updated and it costs 10 bucks a month to run, updates within 2 minutes of a downtime.
Github has no excuse.
We can and will hold them accountable for their decision to hide information from their paying customers and any other case they prioritize their ego over their users.
it SHOULD be manual. you're foolish if you automate your red/yellow/green status indicators, or even host any of that kind of thing on your own infrastructure in any way.
the status page needs to be updated by a human that knows what the issues are, and not automation that will flag everything red the instant anything trivial in the automation fails.
you want static pages and images served up, nothing automated or scripted.
It's technically correct, but, at least for me, it has the connotation of it being a common enough thing, such as something that happens every week. For something with over 99.9% (99.99?) uptime, it's just another fluke occurrence.
I vividly remember the last time they really went down, I was in the middle of an important deploy and since "we" (it predates me) didn't consider "github been on fire" a critical dependency it all went a bit sideways.
I would wager that your self-hosted GitLab has less uptime than GitHub (or the quality of the deployment). We typically underestimate the downtime of the software we deploy ourselves, probably because we're attached to it, or because we're busy fixing it, instead of having to wait.
I'd take the occasional downtimes of cloud solutions, if it means not having to use some of the self-hosted software I had to to use at work.
I'm managing a Gitlab instance for 10k users since 3 years, we had zero unplanned downtime in the last 3 years, I just had to apply the upgrade every 3 months and it's running smoothly ever since
If Github had planned downtime every 3 months people would scream bloody murder, so the point stands that github's uptime is almost surely better than someone who selfhosts.
Not really, it’s far better to have downtime at a time of your choosing than in the middle of a key time.
It’s why we run certain services in my department ourselves rather than central IT, because central IT thinks that the best time for planned downtime is 6pm, which is hilarious as for our department 5pm-11pm is the most critical time, and the best time to make changes is between 9 and 12 when the services are least important (not that we have a full outage, but we can have a degraded outage - our internet service for half of our equipment can take upto 20 seconds to fail over, and not every end device is dual connected)
FYI the planned downtime for upgrade is 5mn every 3 months done on Saturday night, I believe our instance uptime is much better than GitHub uptime
Of course we are using it only for 10k users not for millions like GitHub
I ended up here because automated cluster deployments failed trying to download releases from GitHub... I wonder if that software is served there and I can update the URLs before GitHub fixes their issues :)
Thanks for the suggestion, but for now I can only bookmark it for later. My priority right now is to reach basic competency ASAP, so I'm running Spacemacs. I love the "batteries included" thing, but just installing it took like an hour of fiddling before I just gave up and ingored the error message. I don't think it'd be wise to fiddle around with the settings if even the defaults are going haywire.
Ah sure, it's good to stick with the default packages in your distribution then... I started from scracth and found that Ivy was more than sufficient for everything I need (and it's quite a lot lighter than Helm).
288 comments
[ 3.3 ms ] story [ 289 ms ] threadGot one after you posted at least
And I need it right now.
Guess I'll be setting up a local git instance very soon...
edit: by local I meant in the intranet. not on my local machine.
The incorrectness of this highlights how useful DVCS can be — a git server going down doesn't affect working locally at all.
Yep, can't even push
They can do better, they just don't want to.
Besides that, how are you going to cause "more harm than good"?
A status page is a kind of PR. Think of it like a policy for a flight attendant to come out into the cabin to tell everyone what's going on when the plane encounters turbulence. That policy is Public Relations -driven. You only do it if you expect that it's positive PR, compared to not doing it — i.e. if telling people what's going on is boosting your reputation compared to saying nothing at all.
If a status page just makes your stakeholders think your service is crappy, such that you'd be better off with no status page at all... then why have a status page? It's not doing its job as a PR tool.
But that's not true. The company could do better. But the individual employees cannot. The individual employees are constrained by the profit motive of the company. They are not allowed by corporate policy to set up automatic status updates, for about the same reason they're not allowed to post their corporate log-in credentials: that the result would very likely be disastrous to the company's bottom line.
(Though, really, the corporations in most verticals are in a race-to-the-bottom in most respects. Even if you treat GitHub as a single entity capable of coherent desires, it probably doesn't desire to avoid automatic status updates. It needs to avoid them, to survive in a competitive market where everyone else is also avoiding them. People — and corporations — do lots of things they don't want to do, to survive.)
GitHub, meanwhile, is a million different things to a hundred million different people. Users of e.g. Homebrew, with its big monolithic ports system hosted as a github repo, have a very different SLI for Github than do users of some language-ecosystem package manager that allows you to pull deps directly from Github; than do people who depend on GitHub Actions to CI their builds on push; than do people doing code-review to others' PRs; than do people using Github mostly for its Wiki, or Issues, or downloading Releases, or Github Pages, or even just reading single-page-with-a-README repos, ala the various $FOO-awesome projects.
For many of these use-cases, Github isn't degraded right now. For others, it is.
If you ask for Github (or any service with this many different use-cases and stakeholders) to measure by the union of all these SLIs, then the service would literally never be not-degraded. In systems of sufficient scale, there's likely no point where every single component and feature and endpoint of the system is all working and robust and fast, all at once. Never has been, never will be.
And anything less than just going for the union of all those SLIs, is asking Github to exercise human judgement over which kinds of service degradation qualify as part of their own SLOs. Which is exactly what they're doing.
Certainly, internal to services like this, there are all sorts of alerting systems constantly going off to tell SREs what things need fixing. But not all of those things immediately, or even quickly, or even ever, translate to SLO violations. There are some outlier users whose use-cases just break the system's semantics, where those use-cases just aren't "in scope" for the SLO. As long as those users are only breaking the system for themselves, the degradation they experience won't ever translate to an SLO breakage.
E.g., a bit tongue in cheek:
> An MMO is a very simple system, in that there's only one Service Level Indicator (SLI) that devs, shareholders, and players all agree on. That SLI is "can a player connect to the server, and perform regular gameplay actions, without a ridiculous amount of per-action latency."
Wouldn't you say that in an MMO of sufficient scale there's likely no point where every single component and feature and endpoint of the system is all working and robust and fast, all at once?
> In systems of sufficient scale, there's likely no point where every single component and feature and endpoint of the system is all working and robust and fast, all at once. Never has been, never will be.
Couldn't we redefine SLIs as "can the user connect to the server and perform regular user actions without a ridiculous amount of per-action latency"?
My point was that Github has no "average user." Github is like Microsoft Word: each user only uses 10% of the features, but it's a different 10% for every user. Yes, there are some features that are in the critical path for all users (loading the toplevel repo view in the website might be one); but for any given particular user, there will be plenty of other features that are also in their critical path.
An MMO, meanwhile, does have an "average user"; in fact, MMOs have ideal users. An MMO's goal is to induce every user (player) to play the game a certain way, so that the company can concentrate their resources on making that particular play experience as polished as possible. There is, per se, an idiomatic "rut" in the road that players can "click into", ending up doing exactly the same short-term game loops that every other player before and after them has also done when playing the game.
MMOs can be reduced to a single SLO: can the ideal player have fun playing the game at the moment?
GitHub cannot be reduced to a single SLO, because there is no ideal user of GitHub. There are probably two or three thousand separate "ideal users" (= critical, non-universal user stories) for GitHub.
> Wouldn't you say that in an MMO of sufficient scale there's likely no point where every single component and feature and endpoint of the system is all working and robust and fast, all at once?
No, not really; MMOs have a complexity ceiling by operational necessity. They aren't composed of a ridiculous sprawling array of components. They might use Service-Oriented Architecture, but in the end, you don't scale an MMO vertically by making more and more complex clustered systems with master-to-master replication and so forth. You scale MMOs by either pure-vertical hardware scaling, or by horizontal shared-nothing sharding.
(The key thing to realize about MMO servers is that they're OLTP servers — they need to track a whole bunch of users doing a whole bunch of simple actions at once; and therefore they can't really be doing overly-much computation on those actions, lest they lose shared-realtime verisimilitude.)
Not sure if any MMO reaches Github level, most likely not. But I don’t think there is a ceiling or any sort of hard distinction; i.e. I think 5 years from now we could have a MMO with complexity of today’s Github. Maybe it will be called a metaverse though.
EVE is literally the only exception to "MMOs scale by horizontal shared-nothing sharding"; and that's why I mentioned the option EVE uses instead — namely, "vertical scaling of hardware" (i.e. having a really honking powerful single-master multi-read-replica DB cluster.)
In neither case is anything "clever" (i.e. inefficient for the sake of developer productivity / enterprise integration / etc.) happening. There's no CQRS message queues, no async batch writes, no third-party services halfway around the world being called into, no external regulatory systems doing per-action authorization, no separate "normalized data warehouse for OLAP, denormalized data for runtime" forking writes, no low-level cross-replicated integration between a central multitenant cloud system and individual enterprise-hosted tenant silos, etc etc.
> With so many different play styles and optional components (guilds, pvp, official forums, paid content, user made content, etc)
I think you misunderstood me when I said that there's a rut that users are guided into. The thing about MMOs is that the ideal user uses all the features (because the game incentivizes doing so, and because the more deeply and broadly users engage with the game's systems, the higher their retention / lower their churn will predictably be.) The ideal player is in both a party (or constantly switching parties) and a guild; has paid for all the DLC and regularly buys cash-shop items; plays every piece of PVE content you build; engages in PVP content and co-op UGC content all the time; etc.
Which is to say, for the ideal user, "the game" either works or it doesn't, because "the game" is the whole thing. Every feature needs to work, in order for the game to work. Because the ideal user engages with every feature. The SLO is, essentially, "can you do a completionist run through every bit of content we have." (If you're clever, and can make your server deterministic, you can create a completionist run as a backend-event demo file and run it in CI!)
And this is, in part, why MMOs are kept architecturally simple. Everything needs to work!
(And I don't just mean "simple" in terms of the backend not being a sprawling enterprise-y mess, but rather usually a single monolithic binary that can keep a lot of state in memory. I also mean "simple" in terms of as much of the game as possible being pushed to local, mostly-ephemeral-state client-side logic. MMOs are, often, a lot less "online" than one might think. It's very hard to "break" an MMO with a content update, because most content updates are to zonal scripts whose state doesn't persist past the lifetime of the in-memory load of that zone in a particular interacting device.)
With GitHub, their ideal users — of which there are many — can be individually satisfied by very small subsets of the system, such that they're still satisfying almost all their users even if one system is horribly breaking. That's what an SLO is "for", in the end: to tell you whether different subpopulations of users with different needs are happy or not. If you only have one "core" subpopulation, one ideal user, then you only need one SLO, to track that one ideal user's satisfaction. If you have more, you need more.
1. It clearly indicates that automatic systems are failing to detect the outage. 2. It also indicates that no one is aware about the incident to manually signal the outage (or that there is no manual override).
Basically, it makes a difference between "yeah, shit happened, we know (and maybe working on it)" and "hah, they don't even know themselves".
Partially because these large systems have some kind of ongoing issue at any given time, so it's challenging to provide a meaningful live status that isn't a bit misleading and could cause misdirected panic.
Partially because you don't want to give potential attackers (eg ddos) any insight if/how their methods are affecting your systems.
Partially because there are SLAs and reputation at risk, and you don't want to admit to any more downtime than you absolutely have to.
Of course, in the real world, I don't think there's a single IT admin who didn't just start nervously sweating and pulling at their collar after reading the above, imagining it as something their CEO said and encouraging them to target it. Nobody can really do this — and that in turn says something important about how those metrics really look in most systems.
https://metrics.sr.ht/graph?g0.expr=&g0.tab=1&g0.stacked=0&g...
HN seems to be going down for the massive amount of requests!
To be fair, redditstatus.com is quite nice with their sparkline headline metrics. It at least lets you know _something_ is happening even if they haven't yet declared an incident.
Same thing happens (should happen) when you visit your ISPs website and look for registered downtime — many requests from one zip code from multiple ips should trigger an alarm if the isp is competent.
Can't tell you how many times I've had a customer write to me, only to be receiving some automated alerts 30-40 seconds later.
But as a counterpoint I was once working in a project where our monitoring dashboard showed an anomaly in incoming traffic. It turned out that it was an ISP problem and that we were the first ones to notice according to them.
So maybe part of the answer as to why customers are faster is that different monitoring systems are monitoring each other :)
It's weasel words in their purest form.
Right up there with "We apologise for any inconveniences you may have experienced".
If you are apologising it's because you know you inconvenienced someone.
I'd genuinely have more respect if instead they just said "We fucked up, we'll do better".
It's at least honest.
Guess I'll work on my stuff.
I imagine the ability to resist $billion offers when you're successful would be one.
My first thought was https://radicle.xyz/.
What a cruel twist of fate. Their downloads page is hosted on Github Pages, which is down right now! https://radicle.xyz/downloads.html
In any other situation I'd recommend it since it really was the tool of choice for decentralized git repos with lots of cool features. (Despite the "Empowering developers with DeFi building blocks like NFTs, token streams, and more" mentioned on the home page which throws me off)
Edit: It seems like the download page is up and working now.
- despite being decentralized, you still need moderation and access control
- open source projects typically aren't great at frontend UI/UX
It would be neat if I could publish git repos on IPFS and receive patches from people. It's just hard to compete with a centralized, CDN'd service where you can click and get a result in 100ms.
edit: cribbing from sibling comment, it looks like Radicle has thought hard about decentralized git: https://radicle.xyz/blog/radicle-link.html
You mean Git? The Linux Kernel for e.g. does this just fine.
- A single startup file that starts up gitserver, a p2p node to enable repo discovery and submission of PRs.
- A web/electrum client that provides PR merge interface, and links to forks.
- user ids are their public keys, with non-unique nicks. There will only usually be one "jungly" on a repo.
We DO NOT need a blockchain for this. All those ethereum projects are messing things up by introducing an unnecessary coin that we really don't need.
You totally could develop in the kernel workflow, everything done over email, but are you willing to?
EDIT: nope, command line is down, too.
I mean, the moment it went down I'm sure Github's SREs were paged. Give them a minute to process it first, jeez.
Github has no excuse.
We can and will hold them accountable for their decision to hide information from their paying customers and any other case they prioritize their ego over their users.
the status page needs to be updated by a human that knows what the issues are, and not automation that will flag everything red the instant anything trivial in the automation fails.
you want static pages and images served up, nothing automated or scripted.
> you want static pages and images served up
Totally separate issue. You can update static pages with any method.
(My self hosted gitlab is working fine)
I'd take the occasional downtimes of cloud solutions, if it means not having to use some of the self-hosted software I had to to use at work.
It’s why we run certain services in my department ourselves rather than central IT, because central IT thinks that the best time for planned downtime is 6pm, which is hilarious as for our department 5pm-11pm is the most critical time, and the best time to make changes is between 9 and 12 when the services are least important (not that we have a full outage, but we can have a degraded outage - our internet service for half of our equipment can take upto 20 seconds to fail over, and not every end device is dual connected)
We only do security upgrades or wait for x.1 upgrades. Never x.0
The hosted .com however I wouldn't recommend.
[1] https://writequit.org/denver-emacs/presentations/2017-04-11-...
[2] https://oremacs.com/swiper/
BTW what was the error mesage?
Good luck!
Try `M-x info-apropos` and type "helm".
Info docs form a tree: press '^' to go up a node, 'n' and 'p' to go forward and back on same level, '[' and ']' to go forward/back a page like a book.