This platform and devices based on it still require you to have service from a wireless service provider. See the press releases, this is a *completely seperate* effort from Google's 700 MHz spectrum efforts. (Although that effort can only be good for their platform.)
T-Mobile isn't even remotely an option in many areas of the U.S. (including where I live - I would pay through the nose in roaming charges).
Similarly, Sprint isn't an option in a lot of areas too.
That said - the moment an unlocked GSM phone based on this platform is released (Which is basically guaranteed), plenty of people will probably be putting their AT&T SIMs in them.
Yeah, except there's no standard for I2C controllers (making software a nightmare - how many I2C controllers does lm-sensors need to support? How many are not supported?), likewise no standard for certain sensor types with I2C interfaces. (How many different temperature sensor drivers does lm-sensors have?)
I haven't been following the war too much recently, but the impression I get is that BoB/MC are finally losing ground to Everyone Else, despite developer assistance and at least 2.2B ISK/day in zero-risk trade route bug exploitation income.
Latest news is that Orange Species figured out how to run a particular trade route without triggering the automatic price readjustments that are supposed to occur for all NPC buy/sell orders. The end result is that for many months the sell price for a trade good at one station has not changed, and same for the buy price at another station. OS is jump bridging a bunch of freighters with his titan to run this route on a daily basis.
A few years ago the original "Slim PS2" was released.
I believe a few months ago the "Slim and Light PS2" was released (with little fanfare, marketed the same as the original slim) - Same form factor as the old one, but apparently lighter. (I heard 600g instead of 900 for the unit itself, and 250 vs. 350 for the power supply).
Now they are set to release the "Super Slim PS2" which may retain the same form factor for the unit itself, but instead of having the external brick it'll have 120VAC input to an internal power supply.
For me, what I (and I think a lot of people) liked was the fact that except on special servers, there was a clear delineation between PvE (cooperative) areas and RvR (competitive teamplay) areas.
Also, while PvP in many games can be to varying degrees a free-for-all with large teams (guilds/alliances) usually forming and becoming successfull, DAoC was definately "large team" based by design. Also, the frontiers had a pretty well designed capture-and-hold objective system, although over time the rewards for killing other people by roaming with a small group became significantly more than cooperating with your realmmates to capture and hold an objective. The balance of the game shifted away from epic battles with large amounts of cooperation to splintered groups of 8 running all over competing for kills.
Except that in this case, the app returns pure HTML/JS that is "embedded" in the container. Thus it can easily override whatever styling guidelines that container uses.
"With the Facebook platform, app developers build to Facebook-proprietary languages and APIs such as FBML (Facebook Markup Language) and FQL (Facebook Query Language) -- those languages and APIs don't work anywhere other than Facebook -- and then the apps can only run within Facebook. In contrast, with Open Social, app developers can build to standard HTML and Javascript, and their apps can then run in any Open Social container."
One of the biggest reasons "MySpace haters" like myself prefer facebook is that Facebook enforces a relatively "clean" user interface for profiles.
While the Facebook platform has reduced that "cleanness" a bit (too much flexibility was given to app developers, and hence some apps look just plain FUGLY.), the thought of app developers being given full-blown HTML and JS as opposed to a restricted markup language that prevents them from going too far in terms of altering Facebook's UI scares me. If you don't believe me, look at the cesspool of ugliness known as MySpace - it's a perfect example of why there is such a thing as too much flexibility.
For document formats, that's an unholy nightmare, and is the biggest problem with typical third-party application support for existing MS formats. Basic documents transfer fine, but documents using certain features will break horribly.
IPSec is primarily intended for creating a point-to-point tunnel.
Establishing arbitrary IPSec connections on demand to each endpoint you want to contact would be extremely difficult.
You could, of course, tunnel to a host that was not connected to a braindead provider, but that would be extremely bandwidth inefficient - every packet you sent or received to host C when you were tunneled through host B would have to be both sent AND received by host B.
I fully agree. There are plenty of workaround approaches to Comcast's brain-deadedness, many of which will result in increased pain for Comcast in the long run.
For example, the easiest workaround would be to use a custom transport mechanism layered over UDP which includes authentication for connection management (i.e. there's no way to spoof the equivalent of a TCP RST.) The problem is that a LOT of research has gone into TCP congestion control algorithms in the past two decades, and the initial implementation of any custom congestion control scheme will likely be FAR less "fair" than TCP is.
Unfortunately, most current secure transport schemes were only designed to protect data from eavesdropping, not to protect against denial of service attacks against the connection. For example, SSL and TLS both need to be layered above a reliable transport layer (usually TCP), and it is TCP itself that Comcast is attacking.
Actually, they're not blocking an entire protocol.
They're actively resetting ANY TCP connection that involves uploading significant amounts of data for more than a few seconds.
There have been numerous reports of this killing Lotus Domino connections too, and I wouldn't be surprised if I found lots of complaints on the SmugMug forums about people being unable to upload pictures if they were on Comcast. (Same traffic patterns - lots of upload for a while.)
Still, anything that involves resetting/blocking connections is not QoS. I don't think people would care if BT were the "bottom of the barrel" and was superseded by any other traffic type - it would still be wicked fast at 3 AM. The problem here is that Comcast is actively killing connections regardless of what the actual status of the rest of the network is, instead of taking advantage of TCP's built in congestion control mechanisms to slow things down.
I worry that if done wrong, legislation will be passed that even forbids QoS, which will make things really bad for both users and ISPs. The legislation would have to have wording that QoS is OK as long as the "bottom of the barrel" protocols are able to use full bandwidth when no one else is using the network.
With the exception of that Samsung phone, many (if not most) of the phones listed will work fine in the U.S.
I'm fairly certain that all of the HTC devices (Touch Dual, S630, S730) have full or nearly-full functionality on either U.S. GSM carrier.
Touch Dual - Probably the least functional. It's only tri-band GSM, and only does UMTS2100, so no UMTS (3G) in the U.S. and might have issues with normal GSM service in the U.S.
S630 and S730 - Both are quad-band GSM (Works on T-Mobile or AT&T) and support UMTS850 and UMTS1900 (3G with AT&T). In addition, the S630 apparently supports UMTS1700 for when T-Mobile USA starts rolling out 3G.
I don't know about PULSTAR, but the now decommissioned Ward Reactor at Cornell had a thermal output of something like 200-250 kW. (On the order of an average car engine's power output.)
I believe that even at full tilt, it was not able to boil the water of the pool it was sitting in - I'm fairly certain that it was using passive convective cooling.
Unlike power reactors, many of these reactors exist solely for the purpose of studying nuclear reactions and generating radiation (For example, one of the main uses of the Ward reactor was to generate a neutron flux that could be used for imaging purposes.) Because of this lack of a need to generate power, they are not pressurized and don't have any component in the system where water is at boiling temperatures. They sit in a pool of water that is room temperature and do not even have a pressure vessel. You could stand at the top of the Ward reactor's pool and look down into the core, which glowed a pretty blue thanks to Cerenkov radiation. (Similar to that picture of PULSTAR, which was probably taken with a normal camera by someone standing above the pool.)
Sort of recall that it took 30 minutes or so to transfer a CD over a 10BaseT (10 Mb) network back in college. So MAYBE 20-25 minutes for a gig if you could saturate your connection, which you probably won't be able to do because of bandwidth overselling.
I think his point is that without a service level guarantee, there's a good chance you'll frequently see your "20M up" perform worse than your cable modem's 512k because Verizon oversold their backbone connectivity.
If Comcast thinks it has to resort to connection reset shenaningans for users making full use of their 512k up (might be higher for Comcrap - I think OptimumOffline is 1.5M up), how much of that 20M up do you think Verizon will let you use?
What the Comcast rep is describing in the article sounds like QoS - Any time there's a queue in a router somewhere, BT traffic goes to the back of the line. The end result is that if the network is being heavily used for other more latency/bandwidth critical uses, BT slows down, but if you use BT at 4 AM when no one else is using the network it'll be nice and fast.
What Comcast is actually doing is forcing connections to close if they have certain traffic patterns, regardless of whether or not the network is busy at that time. i.e. BT (and other functions, such as Lotus Domino apparently) is adversely affected regardless of what time of day it is or whether it is even necessary to throttle BT.
Unfortunately, since it's based on traffic analysis (and not content analysis) and their system conducts a MITM attack against the transport layer (TCP) instead of the application layer, application layer encryption such as SSL won't help. You need an encrypted transport, either a custom one layered over UDP, or TCP through a VPN tunnel to defeat Comcast's system. Also, the traffic-based analysis scheme significantly increases the chance of false positives, which is why Lotus Domino users are apparently getting shafted in certain situations.
This is correct. EVE's forum logins are tightly tied to your account and characters.
It has always been that only players with active accounts could post on the forums, and in addition on some forums players are forbidden from posting unless they have chosen to make certain information (such as their corporation and alliance affiliation) public.
Slashdot Mirror
Not in the U.S.
Perhaps you're thinking of AT&T? They managed to secure some UMTS spectrum in the preexisting PCS bands and are slowly rolling it out.
T-Mobile was not - they're waiting for the 1700 MHz band to free up to roll out UMTS.
Unfortunately, very little hardware supports/will support UMTS1700.
How is it a serious competitor to AT&T?
This platform and devices based on it still require you to have service from a wireless service provider. See the press releases, this is a *completely seperate* effort from Google's 700 MHz spectrum efforts. (Although that effort can only be good for their platform.)
T-Mobile isn't even remotely an option in many areas of the U.S. (including where I live - I would pay through the nose in roaming charges).
Similarly, Sprint isn't an option in a lot of areas too.
That said - the moment an unlocked GSM phone based on this platform is released (Which is basically guaranteed), plenty of people will probably be putting their AT&T SIMs in them.
Yeah, except there's no standard for I2C controllers (making software a nightmare - how many I2C controllers does lm-sensors need to support? How many are not supported?), likewise no standard for certain sensor types with I2C interfaces. (How many different temperature sensor drivers does lm-sensors have?)
What they probably meant is that they forged a return address from a modified variant of the company's domain.
e.g. sending an email from FIRSTUNI0N.COM to employees of FIRSTUNION.COM
I haven't been following the war too much recently, but the impression I get is that BoB/MC are finally losing ground to Everyone Else, despite developer assistance and at least 2.2B ISK/day in zero-risk trade route bug exploitation income.
Latest news is that Orange Species figured out how to run a particular trade route without triggering the automatic price readjustments that are supposed to occur for all NPC buy/sell orders. The end result is that for many months the sell price for a trade good at one station has not changed, and same for the buy price at another station. OS is jump bridging a bunch of freighters with his titan to run this route on a daily basis.
The PS2 has been slimmed down multiple times.
A few years ago the original "Slim PS2" was released.
I believe a few months ago the "Slim and Light PS2" was released (with little fanfare, marketed the same as the original slim) - Same form factor as the old one, but apparently lighter. (I heard 600g instead of 900 for the unit itself, and 250 vs. 350 for the power supply).
Now they are set to release the "Super Slim PS2" which may retain the same form factor for the unit itself, but instead of having the external brick it'll have 120VAC input to an internal power supply.
For me, what I (and I think a lot of people) liked was the fact that except on special servers, there was a clear delineation between PvE (cooperative) areas and RvR (competitive teamplay) areas.
Also, while PvP in many games can be to varying degrees a free-for-all with large teams (guilds/alliances) usually forming and becoming successfull, DAoC was definately "large team" based by design. Also, the frontiers had a pretty well designed capture-and-hold objective system, although over time the rewards for killing other people by roaming with a small group became significantly more than cooperating with your realmmates to capture and hold an objective. The balance of the game shifted away from epic battles with large amounts of cooperation to splintered groups of 8 running all over competing for kills.
Except that in this case, the app returns pure HTML/JS that is "embedded" in the container. Thus it can easily override whatever styling guidelines that container uses.
From the second link:
"With the Facebook platform, app developers build to Facebook-proprietary languages and APIs such as FBML (Facebook Markup Language) and FQL (Facebook Query Language) -- those languages and APIs don't work anywhere other than Facebook -- and then the apps can only run within Facebook. In contrast, with Open Social, app developers can build to standard HTML and Javascript, and their apps can then run in any Open Social container."
One of the biggest reasons "MySpace haters" like myself prefer facebook is that Facebook enforces a relatively "clean" user interface for profiles.
While the Facebook platform has reduced that "cleanness" a bit (too much flexibility was given to app developers, and hence some apps look just plain FUGLY.), the thought of app developers being given full-blown HTML and JS as opposed to a restricted markup language that prevents them from going too far in terms of altering Facebook's UI scares me. If you don't believe me, look at the cesspool of ugliness known as MySpace - it's a perfect example of why there is such a thing as too much flexibility.
For document formats, that's an unholy nightmare, and is the biggest problem with typical third-party application support for existing MS formats. Basic documents transfer fine, but documents using certain features will break horribly.
The article makes no sense.
How can a document format be "compatible with" OOXML without BEING OOXML???
It's like somehow saying that PNG is more "compatible with" JPEG than GIF is - it makes ZERO sense!
I am using English (US) settings, and no sweet IMAP for me yet. I do currently have POP turned on, I wonder if that is holding me back?
IPSec is primarily intended for creating a point-to-point tunnel.
Establishing arbitrary IPSec connections on demand to each endpoint you want to contact would be extremely difficult.
You could, of course, tunnel to a host that was not connected to a braindead provider, but that would be extremely bandwidth inefficient - every packet you sent or received to host C when you were tunneled through host B would have to be both sent AND received by host B.
I fully agree. There are plenty of workaround approaches to Comcast's brain-deadedness, many of which will result in increased pain for Comcast in the long run.
For example, the easiest workaround would be to use a custom transport mechanism layered over UDP which includes authentication for connection management (i.e. there's no way to spoof the equivalent of a TCP RST.) The problem is that a LOT of research has gone into TCP congestion control algorithms in the past two decades, and the initial implementation of any custom congestion control scheme will likely be FAR less "fair" than TCP is.
Unfortunately, most current secure transport schemes were only designed to protect data from eavesdropping, not to protect against denial of service attacks against the connection. For example, SSL and TLS both need to be layered above a reliable transport layer (usually TCP), and it is TCP itself that Comcast is attacking.
Actually, they're not blocking an entire protocol.
They're actively resetting ANY TCP connection that involves uploading significant amounts of data for more than a few seconds.
There have been numerous reports of this killing Lotus Domino connections too, and I wouldn't be surprised if I found lots of complaints on the SmugMug forums about people being unable to upload pictures if they were on Comcast. (Same traffic patterns - lots of upload for a while.)
Still, anything that involves resetting/blocking connections is not QoS. I don't think people would care if BT were the "bottom of the barrel" and was superseded by any other traffic type - it would still be wicked fast at 3 AM. The problem here is that Comcast is actively killing connections regardless of what the actual status of the rest of the network is, instead of taking advantage of TCP's built in congestion control mechanisms to slow things down.
I worry that if done wrong, legislation will be passed that even forbids QoS, which will make things really bad for both users and ISPs. The legislation would have to have wording that QoS is OK as long as the "bottom of the barrel" protocols are able to use full bandwidth when no one else is using the network.
With the exception of that Samsung phone, many (if not most) of the phones listed will work fine in the U.S.
I'm fairly certain that all of the HTC devices (Touch Dual, S630, S730) have full or nearly-full functionality on either U.S. GSM carrier.
Touch Dual - Probably the least functional. It's only tri-band GSM, and only does UMTS2100, so no UMTS (3G) in the U.S. and might have issues with normal GSM service in the U.S.
S630 and S730 - Both are quad-band GSM (Works on T-Mobile or AT&T) and support UMTS850 and UMTS1900 (3G with AT&T). In addition, the S630 apparently supports UMTS1700 for when T-Mobile USA starts rolling out 3G.
That 150 Kb stealth cap (which similar to Comcast, I don't think OptOffline ever admitted to) is why I call them OptOffline.
I got stealthcapped too for accidentally running BT uncapped for only a day or so.
RoadRunner only has a 512k per-user upstream cap and 5M downstream cap, but doesn't seem to care if you saturate it.
I don't know about PULSTAR, but the now decommissioned Ward Reactor at Cornell had a thermal output of something like 200-250 kW. (On the order of an average car engine's power output.)
I believe that even at full tilt, it was not able to boil the water of the pool it was sitting in - I'm fairly certain that it was using passive convective cooling.
Unlike power reactors, many of these reactors exist solely for the purpose of studying nuclear reactions and generating radiation (For example, one of the main uses of the Ward reactor was to generate a neutron flux that could be used for imaging purposes.) Because of this lack of a need to generate power, they are not pressurized and don't have any component in the system where water is at boiling temperatures. They sit in a pool of water that is room temperature and do not even have a pressure vessel. You could stand at the top of the Ward reactor's pool and look down into the core, which glowed a pretty blue thanks to Cerenkov radiation. (Similar to that picture of PULSTAR, which was probably taken with a normal camera by someone standing above the pool.)
About the only advantage Hotmail has (had) at this point is free push email for Windows Mobile clients.
The question is - does Gmails IMAP implementation support IDLE? If so, then effectively Gmail can provide push email to mobile IMAP clients now.
They could have done this as part of the rumored "gPhone" push, in order to provide a push email service for the new phone.
Megabits, not megabytes.
Sort of recall that it took 30 minutes or so to transfer a CD over a 10BaseT (10 Mb) network back in college. So MAYBE 20-25 minutes for a gig if you could saturate your connection, which you probably won't be able to do because of bandwidth overselling.
I think his point is that without a service level guarantee, there's a good chance you'll frequently see your "20M up" perform worse than your cable modem's 512k because Verizon oversold their backbone connectivity.
If Comcast thinks it has to resort to connection reset shenaningans for users making full use of their 512k up (might be higher for Comcrap - I think OptimumOffline is 1.5M up), how much of that 20M up do you think Verizon will let you use?
Yup. It appears that OpenVPN tunnels everything over an SSL connection (which at its low end uses TCP).
Comcast is doing traffic analysis on TCP connections and sending forged resets to the endpoints.
You need to switch to a VPN that does not tunnel over a TCP connection, but has a fully encrypted transport instead.
IPSec will definately do the trick, not sure about PPTP.
I agree.
What the Comcast rep is describing in the article sounds like QoS - Any time there's a queue in a router somewhere, BT traffic goes to the back of the line. The end result is that if the network is being heavily used for other more latency/bandwidth critical uses, BT slows down, but if you use BT at 4 AM when no one else is using the network it'll be nice and fast.
What Comcast is actually doing is forcing connections to close if they have certain traffic patterns, regardless of whether or not the network is busy at that time. i.e. BT (and other functions, such as Lotus Domino apparently) is adversely affected regardless of what time of day it is or whether it is even necessary to throttle BT.
Unfortunately, since it's based on traffic analysis (and not content analysis) and their system conducts a MITM attack against the transport layer (TCP) instead of the application layer, application layer encryption such as SSL won't help. You need an encrypted transport, either a custom one layered over UDP, or TCP through a VPN tunnel to defeat Comcast's system. Also, the traffic-based analysis scheme significantly increases the chance of false positives, which is why Lotus Domino users are apparently getting shafted in certain situations.
This is correct. EVE's forum logins are tightly tied to your account and characters.
It has always been that only players with active accounts could post on the forums, and in addition on some forums players are forbidden from posting unless they have chosen to make certain information (such as their corporation and alliance affiliation) public.
Helicopters are, by design, constantly trying to shake themselves into their constituent components with some rather extreme forces.
The ability to autorotate won't help you if the Jesus Nut lets loose... ( http://en.wikipedia.org/wiki/Jesus_nut )