I'm wondering if there had been negotiations that had previously fallen apart over the price. After the DDoS caused Dyn's customers to flee in droves (my own employer included), suddenly Oracle's last best offer became much more appealing. Something very similar happened at a company I used to work for - we had been talking to a potential acquisition but we were still far apart on price. That company's largest customer files Chapter 11, and *bam* they called back and agreed to our last offer within days. Deal announced within a week of that filing.
I know Dana Lewis, so I can probably tell you (the AC, not the reply) more about this system than the article does. There are safeguards around "use all its insulin at once" in the pump controller itself, that the OpenAPS system *cannot* override. The OpenAPS system effectively automates the "pushing the button" actions on the pump that are normally done manually by the patient who is reading his/her glucose meter and doing some fairly complicated math in his/her head to figure out the proper dose. It's an API client, nothing more.
The pump itself has safeguards against overdosing, either via manual control or APS control. And if there's a failure of the OpenAPS system, it simply reverts to manual control, which patients have been doing for years.
I'd be in support for wholesale pricing on generation, or an infrastructure fee to cover the costs of transmission. The problem here is that the Nevada PUC is allowing both.
I *highly* doubt it was a single line of code. To toggle the car's "EPA Cheat" mode, maybe, but by all accounts, the system used a variety of inputs to detect artificial driving conditions (including, apparently, barometer data), as well as needing code to define what engine parameters to change once the mode was entered.
While in practice most admins configure/64s as subnets, there's nothing preventing netblocks that are smaller than/64. I have/127 point-to-point subnets on my network, and/96s going to server racks. You need a/64 in order to do RA, however, but you can use DHCPv6 instead on smaller subnets.
What's more likely - I've run into exactly this scenario before, in fact - is that the configuration generation system regenerates configs on a regular schedule, and at one point encountered a failure or spurious bug that caused it to push an invalid config. On the next run - right as the SREs started poking around - the generator ran again, the bug wasn't encountered, and it generated and pushed a correct config, clearing the error and allowing apps to recover.
In python, that's correct. There's some method name mangling to ensure that devs writing code calling private methods know what they're doing, but otherwise it's allowed. In other languages (Java for example) private methods are completely hidden from outside classes.
Disclaimer: Another Twitter engineer here. What my apparently former colleague said, plus X.
Also: Don't be afraid to add caching layers when you see your web server or DBs start to run hot. Putting a memcached instance in place in "front of" your database layer is much easier than sharding the database layers to relieve load - eventually you'll have to do both, but you'll definitely want the memcache layer first. Same with web caches/proxies - putting varnish or squid in front will take some pressure off before you need to implement load balancers.
Re:"will it be enough to revive HP's server fleet?
on
HP Launches Moonshot
·
· Score: 3, Funny
Could you imaging the CEO of Northrop Grumman or Lockheed being able to talk about the engineering issues at this level of detail? Or even the head of NASA? This is why I bought TSLA stock.
In fact, if SPDY support was ubiquitous tommorrow, I would be surprised to see SPDY+TLS used for third party ad serving for this very reason.
Good news here: Google's DoubleClick and AdSense ads are served over SPDY today. In fact, I'm not aware of any Google properties that don't use SPDY, since they're all routed through the same GFE (Google FrontEnd) proxy farms.
SPDY as implemented requires SSL, since the protocol capability is negotiated by a TLS extension on port 443. There's no spec for negotiating SPDY on a standard HTTP port - it would only work if the capability was assumed on both sides before the connection (for example, URLs that start with spdy:// instead of http:/// which connects to a different TCP port on the server).
That only works if all of those hostnames resolve to the same IP addresses. The main optimization in SPDY is the elimination of the need to make multiple TCP connections simultaneously, but all of those resources must live on the same server. If the resources have different hostnames, you might be able to detect hostnames that point to the same IP and then interleave those, but I don't know if the current implementations do that yet.
Most CDNs, however, return different IPs for nearly every query, and web developers use multiple hostnames pointing to the same resources to get non-SPDY multiplexing today. This sounds like an optimization that's easy to accomplish dynamically, though (if request is SPDY, don't spread the resources across different hostnames).
1. HTTP Pipeline support proved very difficult to implement reliably; so much so that Opera was the only major browser to turn it on. It can be enabled in Chrome and Firefox but expect glitches. By all accounts SPDY's framing structure is far easier to reliably implement.
2. WIth SPDY, it's not just the content that's compressed but the HTTP headers themselves. When you look at the size of a lot of URLs and cookies that get passed back and forth, that's not a insignificant amount of data. And since it's text, it compresses quite well.
3. SSL is required for SPDY because the capability is negotiated in a TLS extension. Many people would argue that if this gets more sites to use SSL by default, that's a Good Thing.
4. If you're running SPDY, the practice of "spreading" site content across multiple hostnames, which improves performance with normal HTTP sites, actually works against you, since the browser still has to open a new TCP connection for each hostname. This is an implementation issue more than an issue with the protocol itself; I expect web developers to adjust their sites accordingly once client adoption rates increase.
5. The biggest gains you can get from SPDY, which few have implemented, is the server push and hint capability; this allows the server to send an inline resource to a browser before the client knows it needs it (i.e. before HTML or CSS is processed by the browser).
But as someone else as pointed out, the author's test isn't really valid, as he didn't test directly to sites that support SPDY natively, he went through a proxy.
The website I work for is supporting SPDY, and the gains we've seen are pretty close to the ~20-25% benchmarks reported by others. As many have pointed out, this author's methodology is way broken. I'd recommend testing to sites that are known to support SPDY (the best-known are Google and Twitter), with the capability enabled and then disabled (You can set this in Firefox's about:config, Chrome requires a command line lauch with --use-spdy=false in order to do this, though).
Slashdot Mirror
Great idea, except that the current that gets pulled from a Supercharger would melt a standard extension cord to slag in seconds.
I'm wondering if there had been negotiations that had previously fallen apart over the price. After the DDoS caused Dyn's customers to flee in droves (my own employer included), suddenly Oracle's last best offer became much more appealing. Something very similar happened at a company I used to work for - we had been talking to a potential acquisition but we were still far apart on price. That company's largest customer files Chapter 11, and *bam* they called back and agreed to our last offer within days. Deal announced within a week of that filing.
I know Dana Lewis, so I can probably tell you (the AC, not the reply) more about this system than the article does. There are safeguards around "use all its insulin at once" in the pump controller itself, that the OpenAPS system *cannot* override. The OpenAPS system effectively automates the "pushing the button" actions on the pump that are normally done manually by the patient who is reading his/her glucose meter and doing some fairly complicated math in his/her head to figure out the proper dose. It's an API client, nothing more.
The pump itself has safeguards against overdosing, either via manual control or APS control. And if there's a failure of the OpenAPS system, it simply reverts to manual control, which patients have been doing for years.
In python2.7 interactive mode:
>>> from __future__ import braces
File "", line 1
SyntaxError: not a chance
Enforcing such a clause is illegal if your company is subject to the NRLA (hint: most US companies are): http://www.npr.org/2014/04/13/...
I'd be in support for wholesale pricing on generation, or an infrastructure fee to cover the costs of transmission. The problem here is that the Nevada PUC is allowing both.
Yep, I took a LittleBits Synth Kit with me on a flight earlier this year, got pulled off for extra screening and had to explain the thing to them.
I *highly* doubt it was a single line of code. To toggle the car's "EPA Cheat" mode, maybe, but by all accounts, the system used a variety of inputs to detect artificial driving conditions (including, apparently, barometer data), as well as needing code to define what engine parameters to change once the mode was entered.
RS-232 serial consoles to network gear. Running at 9600 baud.
That feeds into best practice for configuring NTP clients - configure one upstream source, or at least three. Never two.
While in practice most admins configure /64s as subnets, there's nothing preventing netblocks that are smaller than /64. I have /127 point-to-point subnets on my network, and /96s going to server racks. You need a /64 in order to do RA, however, but you can use DHCPv6 instead on smaller subnets.
What's more likely - I've run into exactly this scenario before, in fact - is that the configuration generation system regenerates configs on a regular schedule, and at one point encountered a failure or spurious bug that caused it to push an invalid config. On the next run - right as the SREs started poking around - the generator ran again, the bug wasn't encountered, and it generated and pushed a correct config, clearing the error and allowing apps to recover.
In python, that's correct. There's some method name mangling to ensure that devs writing code calling private methods know what they're doing, but otherwise it's allowed. In other languages (Java for example) private methods are completely hidden from outside classes.
Disclaimer: Another Twitter engineer here. What my apparently former colleague said, plus X.
Also: Don't be afraid to add caching layers when you see your web server or DBs start to run hot. Putting a memcached instance in place in "front of" your database layer is much easier than sharding the database layers to relieve load - eventually you'll have to do both, but you'll definitely want the memcache layer first. Same with web caches/proxies - putting varnish or squid in front will take some pressure off before you need to implement load balancers.
So...former HP customer, or former employee?
That's true, and everyone who knew how to use it did, because Cisco's VPN client software is crap.
Could you imaging the CEO of Northrop Grumman or Lockheed being able to talk about the engineering issues at this level of detail? Or even the head of NASA? This is why I bought TSLA stock.
His severance package is $378.36. not $378 thousand or $378 million, Three Hundred and Seventy Eight dollars and Thirty Six cents.
The FSF has been knocking Apple over iOS since its release. http://www.fsf.org/blogs/community/why-free-software-and-apples-iphone-dont-mix
In fact, if SPDY support was ubiquitous tommorrow, I would be surprised to see SPDY+TLS used for third party ad serving for this very reason.
Good news here: Google's DoubleClick and AdSense ads are served over SPDY today. In fact, I'm not aware of any Google properties that don't use SPDY, since they're all routed through the same GFE (Google FrontEnd) proxy farms.
The good news there is that connections to Google's ad networks DO run over SPDY now, assuming a compatible browser.
Because no one's bothered to ship a BEEP implementation in a major browser release?
SPDY as implemented requires SSL, since the protocol capability is negotiated by a TLS extension on port 443. There's no spec for negotiating SPDY on a standard HTTP port - it would only work if the capability was assumed on both sides before the connection (for example, URLs that start with spdy:// instead of http:/// which connects to a different TCP port on the server).
That only works if all of those hostnames resolve to the same IP addresses. The main optimization in SPDY is the elimination of the need to make multiple TCP connections simultaneously, but all of those resources must live on the same server. If the resources have different hostnames, you might be able to detect hostnames that point to the same IP and then interleave those, but I don't know if the current implementations do that yet.
Most CDNs, however, return different IPs for nearly every query, and web developers use multiple hostnames pointing to the same resources to get non-SPDY multiplexing today. This sounds like an optimization that's easy to accomplish dynamically, though (if request is SPDY, don't spread the resources across different hostnames).
1. HTTP Pipeline support proved very difficult to implement reliably; so much so that Opera was the only major browser to turn it on. It can be enabled in Chrome and Firefox but expect glitches. By all accounts SPDY's framing structure is far easier to reliably implement.
2. WIth SPDY, it's not just the content that's compressed but the HTTP headers themselves. When you look at the size of a lot of URLs and cookies that get passed back and forth, that's not a insignificant amount of data. And since it's text, it compresses quite well.
3. SSL is required for SPDY because the capability is negotiated in a TLS extension. Many people would argue that if this gets more sites to use SSL by default, that's a Good Thing.
4. If you're running SPDY, the practice of "spreading" site content across multiple hostnames, which improves performance with normal HTTP sites, actually works against you, since the browser still has to open a new TCP connection for each hostname. This is an implementation issue more than an issue with the protocol itself; I expect web developers to adjust their sites accordingly once client adoption rates increase.
5. The biggest gains you can get from SPDY, which few have implemented, is the server push and hint capability; this allows the server to send an inline resource to a browser before the client knows it needs it (i.e. before HTML or CSS is processed by the browser).
But as someone else as pointed out, the author's test isn't really valid, as he didn't test directly to sites that support SPDY natively, he went through a proxy.
The website I work for is supporting SPDY, and the gains we've seen are pretty close to the ~20-25% benchmarks reported by others. As many have pointed out, this author's methodology is way broken. I'd recommend testing to sites that are known to support SPDY (the best-known are Google and Twitter), with the capability enabled and then disabled (You can set this in Firefox's about:config, Chrome requires a command line lauch with --use-spdy=false in order to do this, though).