I've thought such DSU system for a while, and it came to me that using a simple fork/exec technique require you to save (or dump) you data somewhere, before the exec() call. If you do it with a file and your data is huge, your update is no longer "seamless". :-/
Some research (a while ago) showed me that exec() on Linux call may be parameterized in order to prevent it to cover data segment (while I am not 100% sure), but then I think it exist only for Linux and is not portable.
They probably targeting non-geek users I guess. People only needing email access, news/internet browsing. As stated above geek users use their connection more actively.
I am wondering whether Facebook ONLY connection is part of the business model. Do it allow Karma to share your internet usage data more easily with Facebook? And monetize those data (like the list of website you browse)?
I didn't find anything related in the "Terms of Service".
Anyway, a private vpn could do the trick I guess. But then such set-up would prohibits me from dropping my ISP at home and rely only on karma...
Exactly why I wouldn't feel comfortable with this. I haven't logged into Facebook from my primary browser in at least a year or two because of their Like beacons – there's no way I'm tying my FB account to my mobile ISP.
It seems fon requires you already have an isp connection. Fon allows you to share it with others. The balance is that on a trip you will be able to access fon hotspot for free (?). Here Karma embeds a 4G connection, AFAIU. Am I correct?
The author (Tom Paseka) wrote near the conclusion that himself addressed the Google's issue, by contacting a Moratel's engineer. Do you have the same feeling when reading the article? It sounds weird that Google did not triggered a recovery procedure on its own.
Maybe I see bad things everywhere and you may call paranoïd, but could it be some sort of ("false") advertising on the side of cloudfare?
I'm not a network engineer, but it seems like the kind of thing that might be very hard to detect when you're already inside or near to the google.com domain. Or maybe CloudFlare just got there first.
I don't think it's necessary to call BS on Cloudflare without any kind of evidence at all.
This is basically correct. BGP is weird. The addresses for one of Google's many datacenters were routed incorrectly for packets coming from some subset of IP space. Unless Google is running active ping tests to that subset of IP space, the way they would normally detect it is for someone to call and complain.
In this case, the author decided to take a shortcut and call the owner of the "problem peer" directly.
Although only a vanishingly small percentage of Google users can call and complain. Blog or tweet or post to HN and hope Matt Cutts sees it and notifies the right team, maybe.
A team of Googlers could have been working on this in parallel to Tom. I'm guessing that a sudden drop of queries like that would cause people at Google to start digging into what happened. I don't know either way, because network ops and BGP is pretty far from my area (search quality).
A common way to notice things like this is to subscribe to a service like Renesys or Cyclops (http://cyclops.cs.ucla.edu/) that will alert you if it sees your subnets being announced by a different AS.
I think it's good to qualify your opinion with your level of expertise. There's no rule that says HN should only be for discussion by experts (hopefully there never will be), and if you don't know something for sure it's best to say so that others don't take your word as gospel. That said, I'm no expert ;).
The key quote seems to be "Looking at peering maps, I'd estimate the outage impacted around 3–5% of the Internet's population." so if it didn't affect google directly it would have to go through customer server -> network technicians which would probably take more than the 26 min that Google was down for those customers for. I'm sure they would have been right on it if it hadn't have been fixed so fast.
It sounds weird that Google did not triggered a recovery procedure on its own.
It's possible they didn't have the personal contact details for the engineer capable of fixing the problem.
We all know how hard it can be to contact a competent person at a big corporation when you have a problem [1]. Would Google find it easier than every other human being?
It sounds like cloudflare simply got there first. Unless cloudflare is outright lying (highly unlikely) they saw a problem they could fix, and fixed it. What's the false advertising there?
They didn't fix anything. Multiple people noticed, all of them contacted the network in question, then they took credit publicly when another network fixed its mistake.
I don't the same point of view as the writer in the article. In essence mine is: you need an adapted device to your needs.
Since casual users buy a device for emails, browsing the web and watching movies, they must buy a deviced adated to those needs. And the iPad v1 for instance is well suited. If you look at the iPad v1's tech specs, it is not tremendous. I don't remember exactly, something like 256MB RAM ... 16Go SSD disk .. and so on. Apple made technical choices (or design choices) based on the user needs.
At the contrary if I need to compile big c++ projects with more that 1,000,000 lines of code. I need to set-up a something suiting my needs. Either a big machine with a big horsepower. Or a compiling grid? Whatever. Something that suit my needs.
I will talk about my own experience, and it only engage myself. I am not sure we can generalize my experience here with callbacks: But for me callback resulted in a big mess. :-)
I've worked in two investment banks, working on their "order passing servers" legacy code. It's c++ code for unix platform. And of course select() driven implementation leads to extensive use of callbacks. The kind of code structure was the same every where I worked: I receive something on a socket, I decode it, what is the event type? Huh ok, I call then the corresponding callback... Huh I need to load the associated context too. And usually the spaghetti appears just right here. When writing the callback for a processing deep into the "sequence diagram" people tend to be overflowed by information. They don't have a clear view of the invariants in their mind. Which leads to over-complicated code in order to deal with the myriad of possible states of your context. And it leads to a lot of bugs.
The context being global, a callback function is forced to behave with side effects. I guess (and only guess since I've never had the occasion to work in FRP style yet) that writing a callback in a synchronous style would would favor a more Functional-programming style, avoiding a lot of buggy side effects, while I guess also it would not be possible to avoid them all... :-/ It must be verified in a real world project that FRP does lead to a cleaner code. Does someone have examples please?
It would be great to have a c++ framework implementing FRP. Or implementing the async/await keywords as in c#. (just tell me if I am not clear enough cause I am not a natural English speaker... :-) )
Some research (a while ago) showed me that exec() on Linux call may be parameterized in order to prevent it to cover data segment (while I am not 100% sure), but then I think it exist only for Linux and is not portable.