a: XO's spokesperson has publically stated (see the PCWorld article) that it was probably a reseller, not XO itself.
b: Most modifications, at least from the client viewpoint (and excluding the exploitable vulnerabilities which were discovered) are benign. 70% of the modifications were client-side proxies, such as personal firewalls, popup blockers, and add-removers.
Of the remaining, most other modifications where things like enterprise firewall services (which modify/insert Javascript checking code) and compression transformations (removing whitespace and/or routines for displaying downgraded images to save bandwidth).
But by signing the binary, they ARE modifying it...
So a copyright-holder of a GPLv2 app where someone else makes an iPhone derivitive COULD object, even if the derivitive author distributes the code (because Apple doesn't).
You CAN distribute code under the BSD liscence, just you can only distribute to other registered developers.
Since registering as a developer for the SDK is $0.00, and a registered devolper with a dev key is $100, AND is needed if you want to modify the code, Big Frakin Deal: you can only distribute the code to people who are able to use it, as the jailbreak dev-kits don't use the same APIs (and if they did, then you can distribute to your hearts content because its clearly no longer confidential information).
Actually, GPLv2 MAY BE incompatible, if the answer is "code which uses the iPhone APIs contains confidential information". In that case, you could only distribute the code to other registered developers, not everyone, which means Berkeley liscence is fine but GPL is not.
Also, apple's method of distribution MAY BE GPLv2 incompatible, because Apple might not want to also be responsible for distributing the source code and some GPLv2 authors may not like derivitive works where a different party distributes the source code compared to the binary (because the developer could always host the code if its not confidential), and the GPLv2 as written says it is the binary distributer's responsibility to distribute the source code.
We don't know yet, but if the distribution is not GPLv2 friendly: If you ask the Free Software Foundation, that would be a feature. If you ask Apple, that would be a feature.
The speculation that it was deliberate activity does strike me a little strange:
If you are going to get your malcode onto this, why do something old and crufty when you could do something new.
IIRC, this is used for BIOS updating as well as windows driver schlepping. So why use old-n-crufty known malcode when you could get a clean rootkit (no existing signature) and install it that way.
The problem is, without user fairness, the heavy users get MORE bandwidth. This is the multiflow problem.
Your neigbor and you share a common bottleneck. Your websurfing, he's got 6 torrents downloading. He is going to have at least 24 active flows, running full bore, and you will have 1 or 2 (which are bursty even). Thanks to how TCP works, without traffic shaping, you will receive 1 packet for every 24 he gets.
User fairness is necessary to be implemented in the network to keep his traffic from walking all over you.
ANy device sophisticated enough to do the flow fairness described can also do "user" fairness by averaging behavior across multiple flows from the same soure, and the behavior of the source over time.
This solves the P2P problem, and has a bunch of other advantages.
Note, also, you only need to do this at the edges, as the core is pretty overprovisioned currently.
Notice the fine print: They aren't saying they are ending interference with P2P, they are saying they will stop treating BitTorrent differently then other heavy transfers.
Which is a Good Thing, IMO, and I'm happy to have been proven wrong (I thought the P2P vs ISP war was going to heat up further.)
However, a guess: it may be a consequence of improved traffic shaping: they are already starting to prioritize short connections ("Speed boost", which is being very heavily advertised in this area).
You don't NEED to do RST injections if you can take the 1% heavy-users and traffic shape them down to a reasonable level when there's congestion. RST injection is very crude traffic management compared to the alternatives.
It also allows the ISP to deal with the cost externalities indirectly, because now the 90% don't complain as much about bad performance when they want to surf the net.
Finally, there is NOTHING in this that says they have to treat BitTorrent UPLOADS as special, just "not different from youtube".
Comcast has repeatedly claimed that they are only killing "leeches/seeds", flows which upload vastly more than they download. If Comcast instead just shapes all large uploads, this will have effectively the same effect, without the visible political repercussions.
Likewise, if ALL ISPs agressively shape uploads, this kills the P2P business model nearly as sure as anything else.
Also, the lack of topological awareness does hurt BitTorrent, as well as the lack of cacheability. If the ISP is able to say that a) BitTorrent-type protocols can stay in my local loop and b) These flows are ones I CAN cache without being sued
BitTorrent type flows become far less objectionable.
There have been plenty of lessons, Japan most recently, that upping the avaible capacity simply ups the amount of bulk-data P2P, without helping the other flows nearly as much.
TCP's fairness attempt (its not perfect, even so) is fairness among flows. But what people desire is fairness among users.
The problem, however, is that the fairness is an externality. You COULD build a BitTorrent-type client which monitors congestion and does AIMD style fairness common to all flows when it is clear that there is congestion in common on the streams rather than on the other side.
But there is no incentive to do so! Unless everyone else did, your "fair" P2P protocol gets stomped on like any other single-flow protocol. Fairness is an externality: you don't have a reason to be fair unless everyone else is, and the only reason the Internet IS even close is that TCP congestion control was done when there were a few thousand cooperating hosts, and any uncooperative entities could be squished.
Today, replacing the current congestion control with a user-weighted congestion control would be lovely, but its notgonnahappen.com, because even if you could get Microsoft on board to push a new TCP stack to 90% of the world, the P2P programs will STILL play games to increase their allocation: Vuse, in its FCC filing, actually calls it a feature how using multiple flows increases its performance.
We are going away from a world where we can trust the endpoints to "play nice" in the network. I'm afraid user-fairness traffic shaping is going to be a necessity and will be widely deployed.
Additionally, you want such traffic shaping to be protocol aware. Not just to degrade P2P, but to enhance VOIP, so even if the user is exceeding his allocation, you make sure the VoIP gets through first.
Now, I sympathize with Comcast. Many ISPs, not just Comcast, are disrupting P2P sessions, and these sessions are in clear violation of most ISP's Terms of Service. And P2P is horribly disruptive, a single user can easily transmit 20 GB of data in a day.
Yet Comcast seems intent on making people WANT to regulate them. Its like they are deliberately behaving stupid?
They aren't agressive at pointing out all the other ISPs, to get the heat off.
They do stupid things like pack FCC hearing, say that the results won't matter, etc.
Actually, the $250 pricing is for those who DON'T want to sell it, but instead do it as a corporate application, with limits on which iPhones can run it and a whole certificate infrastructure.
T-Mobile already does this effectively with their WiFi/cell phones: they route over WiFi when available (eg, home) and then over the cell network when away from the home. So you can have one phone, where you get GUARENTEED good reception at home, and can route transparently.
Hopefully AT&T will cross-liscence the patents, because THAT would be nice on the iPhone.
Skype is truely awful for data use on the cell network: Far more bandwidth per call and a lot more quiescent use. If the iPhone users had skype, the EDGE network would collape in 30 seconds.
I can see the No Skype on Cell-data restriction. VoIP is really very poorly suited for being carried over the wireless anyway, and the overhead is significantly more than just voice calls. Not to mention, voice on the cellphone network is pretty cheap already.
The "No Competing Browsers" I understand as well. You see, on the iPhone, the browser really isn't ordinary, but the keys to the kingdom of usability and utility. Apple wanting to protect that makes sense.
What is probably the MOST annoying is "No GPLv3": Apple won't distribute GPLv3 code because it means giving aways the signing key for that app (the anti-TiVoization clause), and since all distribution is through apple, GPLv3 is out.
However, for all the griping, this is actually an AMAZINGLY flexible and unrestricted platform, compared with say game consoles or other PDAs. And for $100 to get a developer key (which allows you to directly run on your own devices), who cares about the distribution restrictions if you are some l33t haxor type who just HAS to run firefox on his iPhone.
Rather than the broadcaster paying, because retail ISPs have significantly higher cost for bandwidth, this just shifted the cost from the broadcaster to the ISPs.
For a one-off experiment like this, it wasn't a problem. But if you are an ISP dealing with a company like Vuse, who's businsess model is shifting terabytes in this way, it will be a problems.
The classmate is a joke. The only thing the Classmate buys is a faster processor, a real keyboard, and 2x the Flash. For 50%-100% more cash.
In return, it is not as rugged (cooling fan and open interior, LiIon batteries, electrolytics, conventional hinge, clunky insecure closure, thick), nor as cheap, nor as useful (sunlight readable display), nor as appropriate for the 3rd world (a >50W power supply!?!).
Also, Windows doesn't understand how to use the Classmate's screen, either having it scroll up and down or squashing the display to fit.
I'd want Windows on the XO, with Windows understanding the screen resolution. THAT would be a nice combination, as Sugar is an abomination all to itself.
Slashdot Mirror
a: XO's spokesperson has publically stated (see the PCWorld article) that it was probably a reseller, not XO itself.
b: Most modifications, at least from the client viewpoint (and excluding the exploitable vulnerabilities which were discovered) are benign. 70% of the modifications were client-side proxies, such as personal firewalls, popup blockers, and add-removers.
Of the remaining, most other modifications where things like enterprise firewall services (which modify/insert Javascript checking code) and compression transformations (removing whitespace and/or routines for displaying downgraded images to save bandwidth).
It should be http://www.usenix.org/event/leet08/tech/
But by signing the binary, they ARE modifying it...
So a copyright-holder of a GPLv2 app where someone else makes an iPhone derivitive COULD object, even if the derivitive author distributes the code (because Apple doesn't).
You CAN distribute code under the BSD liscence, just you can only distribute to other registered developers.
Since registering as a developer for the SDK is $0.00, and a registered devolper with a dev key is $100, AND is needed if you want to modify the code, Big Frakin Deal: you can only distribute the code to people who are able to use it, as the jailbreak dev-kits don't use the same APIs (and if they did, then you can distribute to your hearts content because its clearly no longer confidential information).
Actually, GPLv2 MAY BE incompatible, if the answer is "code which uses the iPhone APIs contains confidential information". In that case, you could only distribute the code to other registered developers, not everyone, which means Berkeley liscence is fine but GPL is not.
Also, apple's method of distribution MAY BE GPLv2 incompatible, because Apple might not want to also be responsible for distributing the source code and some GPLv2 authors may not like derivitive works where a different party distributes the source code compared to the binary (because the developer could always host the code if its not confidential), and the GPLv2 as written says it is the binary distributer's responsibility to distribute the source code.
We don't know yet, but if the distribution is not GPLv2 friendly:
If you ask the Free Software Foundation, that would be a feature.
If you ask Apple, that would be a feature.
The Not FUD: The iPhone is incompatible with GPLv3.
If you ask Apple, thats a feature.
If you ask the Free Software Foundation, thats a feature.
The Maby FUD: Is code which uses the iPhone APIs confidential information under the NDA? No answer yet.
The Total FUD: It only affects SOME Free liscences. Even if the APIs are confidential, this does NOT stop BSD code, but only viral liscences like GPL.
The speculation that it was deliberate activity does strike me a little strange:
If you are going to get your malcode onto this, why do something old and crufty when you could do something new.
IIRC, this is used for BIOS updating as well as windows driver schlepping. So why use old-n-crufty known malcode when you could get a clean rootkit (no existing signature) and install it that way.
Oops, me bad. Missed that last bit.
The problem is, without user fairness, the heavy users get MORE bandwidth. This is the multiflow problem.
Your neigbor and you share a common bottleneck. Your websurfing, he's got 6 torrents downloading. He is going to have at least 24 active flows, running full bore, and you will have 1 or 2 (which are bursty even). Thanks to how TCP works, without traffic shaping, you will receive 1 packet for every 24 he gets.
User fairness is necessary to be implemented in the network to keep his traffic from walking all over you.
ANy device sophisticated enough to do the flow fairness described can also do "user" fairness by averaging behavior across multiple flows from the same soure, and the behavior of the source over time.
This solves the P2P problem, and has a bunch of other advantages.
Note, also, you only need to do this at the edges, as the core is pretty overprovisioned currently.
It is by fanboys alone that drool is set in motion.
It is by the news of cool that mobs begin to form, the slash begins to dot, the hype begins to build.
It is by fanboys alone that drool is set in motion.
Notice the fine print: They aren't saying they are ending interference with P2P, they are saying they will stop treating BitTorrent differently then other heavy transfers.
Which is a Good Thing, IMO, and I'm happy to have been proven wrong (I thought the P2P vs ISP war was going to heat up further.)
However, a guess: it may be a consequence of improved traffic shaping: they are already starting to prioritize short connections ("Speed boost", which is being very heavily advertised in this area).
You don't NEED to do RST injections if you can take the 1% heavy-users and traffic shape them down to a reasonable level when there's congestion. RST injection is very crude traffic management compared to the alternatives.
It also allows the ISP to deal with the cost externalities indirectly, because now the 90% don't complain as much about bad performance when they want to surf the net.
Finally, there is NOTHING in this that says they have to treat BitTorrent UPLOADS as special, just "not different from youtube".
Comcast has repeatedly claimed that they are only killing "leeches/seeds", flows which upload vastly more than they download. If Comcast instead just shapes all large uploads, this will have effectively the same effect, without the visible political repercussions.
Likewise, if ALL ISPs agressively shape uploads, this kills the P2P business model nearly as sure as anything else.
Also, the lack of topological awareness does hurt BitTorrent, as well as the lack of cacheability. If the ISP is able to say that
a) BitTorrent-type protocols can stay in my local loop and
b) These flows are ones I CAN cache without being sued
BitTorrent type flows become far less objectionable.
Thats acually in the FA, there seeing 75% utilization on fat pipes due to P2P.
Also, see the appendix in
http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-relax-fairness-00.txt
There have been plenty of lessons, Japan most recently, that upping the avaible capacity simply ups the amount of bulk-data P2P, without helping the other flows nearly as much.
TCP's fairness attempt (its not perfect, even so) is fairness among flows. But what people desire is fairness among users.
The problem, however, is that the fairness is an externality. You COULD build a BitTorrent-type client which monitors congestion and does AIMD style fairness common to all flows when it is clear that there is congestion in common on the streams rather than on the other side.
But there is no incentive to do so! Unless everyone else did, your "fair" P2P protocol gets stomped on like any other single-flow protocol. Fairness is an externality: you don't have a reason to be fair unless everyone else is, and the only reason the Internet IS even close is that TCP congestion control was done when there were a few thousand cooperating hosts, and any uncooperative entities could be squished.
Today, replacing the current congestion control with a user-weighted congestion control would be lovely, but its notgonnahappen.com, because even if you could get Microsoft on board to push a new TCP stack to 90% of the world, the P2P programs will STILL play games to increase their allocation: Vuse, in its FCC filing, actually calls it a feature how using multiple flows increases its performance.
We are going away from a world where we can trust the endpoints to "play nice" in the network. I'm afraid user-fairness traffic shaping is going to be a necessity and will be widely deployed.
Additionally, you want such traffic shaping to be protocol aware. Not just to degrade P2P, but to enhance VOIP, so even if the user is exceeding his allocation, you make sure the VoIP gets through first.
I got far more than 2.5 hours out of the air at a conference, running compiles and mysql database work enough that the fan was on 100%.
Now, I sympathize with Comcast. Many ISPs, not just Comcast, are disrupting P2P sessions, and these sessions are in clear violation of most ISP's Terms of Service. And P2P is horribly disruptive, a single user can easily transmit 20 GB of data in a day.
Yet Comcast seems intent on making people WANT to regulate them. Its like they are deliberately behaving stupid?
They aren't agressive at pointing out all the other ISPs, to get the heat off.
They do stupid things like pack FCC hearing, say that the results won't matter, etc.
Who's running that place?
Actually, the $250 pricing is for those who DON'T want to sell it, but instead do it as a corporate application, with limits on which iPhones can run it and a whole certificate infrastructure.
$100 is enough to sell all you want.
Symbian for publishing costs $250:
http://www.verisign.com/products-services/security-services/code-signing/symbian-content-signing/
Then get T-Mobile...
T-Mobile already does this effectively with their WiFi/cell phones: they route over WiFi when available (eg, home) and then over the cell network when away from the home. So you can have one phone, where you get GUARENTEED good reception at home, and can route transparently.
Hopefully AT&T will cross-liscence the patents, because THAT would be nice on the iPhone.
Skype is truely awful for data use on the cell network: Far more bandwidth per call and a lot more quiescent use. If the iPhone users had skype, the EDGE network would collape in 30 seconds.
I can see the No Skype on Cell-data restriction. VoIP is really very poorly suited for being carried over the wireless anyway, and the overhead is significantly more than just voice calls. Not to mention, voice on the cellphone network is pretty cheap already.
The "No Competing Browsers" I understand as well. You see, on the iPhone, the browser really isn't ordinary, but the keys to the kingdom of usability and utility. Apple wanting to protect that makes sense.
What is probably the MOST annoying is "No GPLv3": Apple won't distribute GPLv3 code because it means giving aways the signing key for that app (the anti-TiVoization clause), and since all distribution is through apple, GPLv3 is out.
However, for all the griping, this is actually an AMAZINGLY flexible and unrestricted platform, compared with say game consoles or other PDAs. And for $100 to get a developer key (which allows you to directly run on your own devices), who cares about the distribution restrictions if you are some l33t haxor type who just HAS to run firefox on his iPhone.
Rather than the broadcaster paying, because retail ISPs have significantly higher cost for bandwidth, this just shifted the cost from the broadcaster to the ISPs.
For a one-off experiment like this, it wasn't a problem. But if you are an ISP dealing with a company like Vuse, who's businsess model is shifting terabytes in this way, it will be a problems.
No, you register as a developer for $100, and you can run the code standalone on your devices.
Also, if you want to restrict use to within an enterprise, thats $300.
The classmate is a joke. The only thing the Classmate buys is a faster processor, a real keyboard, and 2x the Flash. For 50%-100% more cash.
In return, it is not as rugged (cooling fan and open interior, LiIon batteries, electrolytics, conventional hinge, clunky insecure closure, thick), nor as cheap, nor as useful (sunlight readable display), nor as appropriate for the 3rd world (a >50W power supply!?!).
Also, Windows doesn't understand how to use the Classmate's screen, either having it scroll up and down or squashing the display to fit.
I'd want Windows on the XO, with Windows understanding the screen resolution. THAT would be a nice combination, as Sugar is an abomination all to itself.
50lbs == 22.6 kg
.019 W
4 ft == 1.21 m
PE = mgh = 22.6 kg * 1.21 m * 9.8 m/s^2 ~= 270 J
Expended over 4 hours, thats
A GOOD white LED (the kind that really is equivelent to a good lightbulb), such as used in a Mag Lite flashlight, is 3W.
So either time, mass, or distance are off by a good order of magnitude.