701–710 of 740 posts
Earlier quoted context omitted.
Wonder what the story is behind these two... User-Agent: bender Disallow: /my_shiny_metal_ass User-Agent: Gort Disallow: /earth
I reod some people use false slugs in the robots.txt as a honey pot of sorts. IPs that actually read the robots.txt, ignore the disallow, and still access the uri are outright banned.
Earlier quoted context omitted.
Call me old fashioned but the latest trend of showing "empathy" for a serious incident, then proceeding to dance around the aftermath of it, whilst people give themselves a pat on back in a retro/post-mortem, isn't the way to do it. People need to be blamed, and responsibility for actions taken (without covering asses)
the attitude that "people need to be blamed" will never improve reliability in the long run. people come and go; systems and processes endure. blaming people is the best way to avoid making durable improvements to systems and processes.
We do not have a system that adjusts to "oops"
Earlier quoted context omitted.
Is their anything these big sites could do in this situation, or must they choose between running and maintaining all of their own infra or relying on a single CDN?
If you have absolutely vanilla CDN requirements, you can run multiple CDNs and fail-over or load balance between them using DNS. Quite a few Fastly customers have more than vanilla requirements though, and may have a lot of business logic performed within the CDN itself. That Fastly is "just Varnish" and you can perform powerful traffic manipulation is one of it's main selling points.
Earlier quoted context omitted.
This is market cap, but if you look at amount of traffic you have Akamai estimated at 15-30%, CF at 10%. So if it would go down, it would cripple vast amount of internet.
Akamai is balls deep in video streaming, which is probably the most bandwidth/traffic intense thing for a CDN to dabble with. My guess is that CF has much more diverse traffic. Hence the fallout from an interruption would be quite different.
Earlier quoted context omitted.
Well, while engineers are getting paid $100K/yr to post #HugOps, I know someone in HFT and their dashboard uses the Fastly service, so this has had a huge impact on them for sure. Flag and downvote all you want, you know this is true.
I suspect you'll have trouble convincing a forum of primarily engineers that a high frequency trader is more worthy of sympathy than an engineer. They're both pretty privileged jobs and HFT is not known for having tons of benefits to society
Engineers are paid because their companies have customers. The it is pure madness that #hugops is the thing. I sincerely hope that Fastly's customers wack it $$ wise so hard that it actually affects #hugops engineering culture.
Earlier quoted context omitted.
True. But the vast majority of use goes via "WWW". For example email - the other big "internet-user" is technically not part of the WWW, but most (? I don't have any stats, just a guess) of our mailclients run on the WWW, nonetheless.
BitTorrent was half of all Internet traffic for a while, though it has decreased with the rise of legal and convenient streaming services.
I'm not sure what the native clients for Netflix and Spotify actually run, but I use their WWW clients mostly. Making most of my internet bits&bytes go over the WWW.
This seems to be impacting a number of huge sites, including the UK government website[0]. [0] https://www.gov.uk/ https://m.media-amazon.com/ https://pages.github.com/ https://www.paypal.com/ https://stackoverflow.com/ https://nytimes.com/ Edit: Fastly's incident report status page: https://status.fastly.com/incidents/vpk0ssybt3bj
> potential impact to performance So it is a "performance" issue when all pages give a 503.
Earlier quoted context omitted.
v1. "It's Bob's fault and so we fired Bob." v2. "The issue was caused by a previously unidentified pathway that caused a feedback loop and overloaded our servers in a cascading fashion (or whatever). We have implemented a fix for this and updated our testing and deployment processes to stop similar cascades." Which solves the problem long term? As an architect making product choices, v2 wins every time. (With the cav…
If an employee does something actively malicious, you should absolute remove them. This is very rare though - incompetence /broken systems is much more likely. Otherwise you develop internal process that's entirely scar tissue, and only stops your teams doing their jobs.
The scar tissue: this is where good choices come in because it's certainly not a rule that a change as a result of an incident review is an impediment to work. These definitely occur, and sometimes linger after the root cause is phased out. But best practices often reduce cognitive & process overheads.
A rough example is that there are still people out there FTPing code to servers, having to manually select which files from a directory to upload. Replacing this error prone process with a deployment pipeline leads to a massive reduction in the likelihood of errors and will actually speed up the deployment process. It's all about making the right choices, not knee-jerk protections, and sometimes the choice is to leave things as they are.
Earlier quoted context omitted.
Lets hope you don't ever go into management. You clearly have no idea how to motivate and retain people or have any insight on how hard it is to hire good people to begin with. And no, I'm pretty certain this is not how Netflix's culture is.
> pretty certain this is not how Netflix's culture is. > pReTtY CeRtAiN This, the wording in of itself shows you have absolutely no clue whatsoever at all of Netflix's culture.
Earlier quoted context omitted.
How would you make the button send a request without js and without navigating to another page? Maybe css to load an image on :active or is there some better way?
Here are two robust techniques that I haven’t seen actually employed in production for maybe fifteen years: ① A submit button or link targeting an iframe which is visually hidden. (Or even don’t hide it. If only seamless iframes had happened, or any other way of auto-resizing an iframe: relevant spec issues are https://github.com/whatwg/html/issues/555 and https://github.com/w3c/csswg-drafts/issues/1771 .) ② A submit…