iSCSI operation against a writable snapshot of a lun. Or various nfsroot solutions for linux. Or probably a number of other things...
This patent was filed in 2006, back when Apple was taking enterprise semi-seriously. Expect the validity of this one to be a moot point as Apple ignores it.
I would be interested in knowing how that works for XMB content. Namely what are their prospects for revoking keys used to sign existing apps/games without completely screwing over published apps/games. I would imagine disc-based would be a problem, but maybe they could somehow revoke a key for things that could have only come via PSN and require updates with new sigs.
Obviously, not a particularly savvy guy on this front, I just dream of a MythTV frontend on my XMB without screwing up the rest of it. The UPnP stuff does a respectable, generic job but I just want more.
Google isn't getting in the way there. The handset maker has what amounts to a significant fork. They require time to modify it. Google can't do anything about that. Maybe they could 'improve' the default UI, however it's a highly subjective thing and the handset manufacturers will continue to impose their own distinct vision of how it should be, so that is probably a dead end.
Discussion on Android is falling into the same pitfall that linux does. People bitch and moan about how enterprise distributions are 'behind', or how one distro has patched something another hasn't, or how one has picked KDE or Gnome as the default. If you have a phone with an OS that *happens* to be 'Android based', but provided by your handset manufacturer rather than straight from google, then you should treat it as completely distinct and Android 2.2 has no meaning for you.
I wonder if the handset makers should start branding Android in a way to mitigate this, relegating Android base as something like 'Android compliant' or something like that.
It was an awesome game, but The Wizard was less 'inspired' by the game and more a commercial funded by Nintendo for all things Nintendo. It's a testament more for Nintendo's commitment to advertising than how 'big' it was. Otherwise, the Powerglove was an awesome, era defining device (unless you take the "it's so bad" line ironically...).
While not excusing the pretty atrocious iPhone alarm quality, an alarm clock with battery backup is about 5 dollars, is always exactly in the same place, has big, simple physical buttons dedicated for alarm clock function, and is so damn simple that no one really screws them up (at least the ones that have no clue what day it is and don't do auto-adjust for DST and the like).
For the application of alarm for waking you up for bed, I would highly recommend that anyone who uses their phone instead of any alternative stop doing so. The complexity causes stupid risks like this and the interface is hostile to operation when you were unconscious seconds before.
There remains the case of daytime alarms that is problematic, but I don't know about the iPhone and how/if calendar notifications in their platform are affecting/make moot daytime alarms.
One of the more interesting things about it is that you develop on it using Adobe Air, instead of the traditional Blackberry SDK.
I suppose that could be interesting for them. I wonder if Adobe has their game together on mobile devices yet, the time from initial promise of flash first appearing on devices to first time it actually appeared was a long time. The company can't even consistently deliver a 64-bit build alongside their 32-bit build. It gives me some doubts about their ability to maintain a lot of architectures and OSes (QNX, Linux w/ X, Android, WebOS Windows, OSX, x86, arm)
But that's not what it's about. It's about a curated set of software that is all updated more automatically than current software. What's wrong with that?
If it were like apt or yum where any organization could set up their own repository and augment/replace Apple's source, then I would be less worried. My understanding is they do not, however Cydia is going to set up another one. I consider that to be aggravating as it means it isn't extensible. WebOS has a similar situation, the App Catalog and the Preware repository. The Preware view does endeavor to present the app catalog as a subset, but the app catalog will not. I find this a bit sloppy.
I don't mind it as a strictly additional feature, but I'm wary of Apple having a taste of control over the iPhone/iPod (where users are *forbidden* from sideloading) and seeking to pursue that end game in OSX or alternatively giving up on OSX altogether in favor of iOS. I suppose I have little 'right' to worry or complain since I never buy apple stuff and I find plenty of competent alternatives that do what I want.
I think Touchstone is a fantastic thing to have baked into your platform strategy, *particularly* with the exposition feature opened up to third-party stuff.
It's the only platform I see that is feasible to build a blind-dock automotive application. Bluetooth pairs with stereo system, and GPS/Internet radio app auto-start when user just slaps the phone in the vicinity of a car-mounted touchstone. iPhone comes closest, but their docking is generally clumsy in cars (most of the time a cable coming out clumsily somewhere, best case a headunit that still requires relatively precise guidance to get in right.
Blackberry Playbook, most interesting aspect is blackberry ripped off WebOS gestures/display for multitasking. However, I am generally skeptical that Blackberry can get out of their niche of mostly business only, they spent way too long with a behind-the-curve platform.
Honeycomb, will see, but I don't see how people get excited over a "we'll get it right *this* time" promise.
If they were going to say 'tablets', they could've skipped Blackberry and Honeycomb. I personally still don't get the tablet fuss and wonder if it is destined to be a dead fad. I would be more excited over phones with glasses display and 'Kinect' like controls, though I really like tactile feedback. Done right that gives 'bigger' personal experience with increased convenience and privacy.
ChromeOS, I view as a dead-end. They should have focused more on enriched Android as a common platform. I don't think Google's name will salvage a concept even more limited than the Linux-only netbook attempts that did not do so well in the market.
Dual-core phones, I wouldn't mind *but* I don't know the power draw difference expected. Memory has hurt my experience more than processor.
Mac app store, please don't be *eager* for that. Why seek more and more ongoing draconian control over the product you purchase?
Google TV falls under the Honeycomb category, "this time it will be better" with no substantive evidence is not the makings of interesting news. Generically saying improved internet enabled TV, maybe. I personally treat my display as a dumb display and prefer the 'smarts' to be small, relatively inexpensive changeable parts.
Hulu for magazines. I think a magazine company might dream of a day where the magazine model dominates, but I just don't see that happening. A web presence in which articles are published as they are ready (not waiting for the next publish date) and adaptive formatting is well-established means e-magazines don't make a whole lot of sense.
Sure, Intel and AMD tech refreshes belong there.
I suspect the playstation phone will be more n-gage than DS. Nintendo 3DS is probably a more 'sure thing' for this sort of slot.
Will see if the net neutrality stuff has any impact. Most commentary I saw was that it was enough to give some annoyance to carriers, but not enough teeth to actually do anything.
I would be willing to be wowed by a second-chance WebOS set of devices. I loved so much about the Pre (WebOS, plug-free 'dock' that can be detected by software, remarkably malleable to consumer manipulation with blessing of vendor). If they did have a portrait slider & keyboardless phone to flesh out their portfolio, that could be exciting. Too bad I don't have hopes of more than just Android and iPhone long term in the mobile market.
I will say that the Mac Pro is a workstation (dual Xeon sockets don't come cheap from anyone) and not a 'consumer desktop' and all dual socket workstations are way expensive regardless of vendor (only a niche market really 'needs' them). Frankly I wonder if those and the 'server' branding of those machines will go the way of the Xserve sooner rather than later.
They simply have nothing in the expandable desktop market. They simply are not interested in serviceable products. I wouldn't be surprised if in the next year they drop support for anything not installed via an app store even in their desktops. They are that sort of company, and most people who would be interested in that flexibility justifiably avoid anything with Apple's name on it like the plague.
NAT is evil. Skype needs to build an overly complex networking protocol because too many people are behind NAT gateways. Skype *could* probably get away with their basic available hardware if only they got to design for a NAT free world.
One could also say they were trying to cheap out and not invest as much hosting required to assure reliability of their chosen networking architecture.
Of course, on the flip side, Skype as a service would be nearly useless in a NAT-free world. No need for a coordinating entity other than DNS if all peers can directly ring up the address of their recipient. Even in multi-user desktop/migration scenarios one could have a DNS record that points to the 'active' user and deregisters on logout. Some may argue that skype would still be cleaner, and of course they still have the bridge to phone feature.
Geohot's claim was specifically that he had a way to exploit Other OS. None of the actual attacks in the wild had anything to do with Other OS.
The first couple of moves were buffer overflows in the PS3 USB stack.
This supposed move is deriving Sony's signing key.
None of the hacks had anything to do with OtherOS. All signs point to Geohot being full of it.
However, I was never satisfied with Other OS, since it locked out the GPU, relegating a whole lot of easy things in most of the world as huge endeavors as people tried desperately to use the PPUs to compensate for a dumb framebuffer. I wonder how many people were explicitly disinterested before thanks to Other OS, or would have not cared if Other OS had never been allowed, but took the Other OS removal as a challenge to break them.
This sounds like it's a way to have signed applications, no modifications in hardware or software required. Of course, we won't know until proof of concept rolls out.
Game servers are supposed to be coloed in datacenters the way CCP, Blizzard, Zynga, etc. do it,
And yet in many PC games, if I host a game, I am indeed the server. It's obvious by how shaping affects everyones gameplay and how my friend on the same network segment gets incredible connectivity compared to everyone else. Game hosting in datacenters for decentralized games (i.e. not MMO) is more an artifact of NAT mess than the ideal, cheap solution.
So why would carriers make effort to allow peer-to-peer file sharing applications?
I like to live in a dream world where carriers are swayed by what their customers want. File-sharing isn't the only peer-to-peer app (though there are non-infringing uses of that). Conferencing is another example. SIP last I checked was something that required some cooperation from the NAT gateway and IIRC, only one PBX per IP would be possible, so if the carrier even in theory gave port forwarding access, they couldn't serve two on the same IP.
All sorts of arguments and counter-examples of protocol designs that have contorted themselves and used a third-party broker to unbreak the NAT is there, but networking was never *supposed* to be that hard. A whole lot of conferencing, voip, and gaming network protocols would be *greatly* simplified without NAT, and NAT64 would be the compromise to get to the right place eventually. If you are going to give a mobile phone a useless IPv4 address anyway, might as well give it an 'almost' useless IPv6 address.
A smartphone may have rich applications or be used for tethering, opening it up to all sorts of awkwardness. If game servers and peer 2 peer applications try to run and fail, it will look bad.
Also, as others note, carrier level NAT is a demanding proposition that will degrade performance. With NAT64, the same thing is incurred, but there is the likelihood that over time, a smaller proportion of traffic will hit the NAT alleviating the degradation. That possibility does not exist with v4 only NAT using private addresses.
Thanks to finally embracing NAT64, this becomes easy.
If you are providing 'server' access, you pretty much *have* to get an IPv4 address, and preferably an IPv6, but not absolutely required for now. Short term, don't sweat it, medium term go dual stack at first opportunity that presents itself, long term you may take down the IPv4 network one day, but don't explicitly plan when that day will come. The common strategy may continue to be ignore v6 entirely, however moving dual stack at your pace ensures that in the slim, but real possibility that your next-hop provider stops IPv4 routing or starts penalizing IPv4 use via unreasonable fees won't put you in a tight spot. The scenario of next-hop penalizing/dropping v4 is the only scenario I see as sufficient motivation to get servers to bother with v6 at all. I think even brand new servers will do what it takes to secure IPv4 space, which may free up some given the next point...
If you are setting up a network as 'clients', you can get by with either IPv6 or IPv4 for a while. Giving dual stack when available is nice, but whatever you have would be sufficient. ISPs without IPv4 addresses available for new clients should rapidly pursue IPv6 for residential customers and give them most internet via NAT64 on their end. Doing IPv4 private addresses would doom them to crappy service indefinitely, whilst IPv6 would only be semi-crappy for a more temporary interval. If you *really* want v6 to catch on, then start allowing v4 addresses to be carved up more free-market style. All technical experts agree that this would completely fubar the v4 network performance in aggregate, but you would entice adoption of v6+NAT64 with the profitable opportunity to reclaim addresses and sell them to places that *really* need them. The v6 network would be nice and cleanly routed, and getting on the v6 network just becomes that much more important.
Some would argue that any sort of NAT at the carrier plays right into the hands of those who hate P2P networks, including NAT64 as those behind NAT64 are unreachable by peers who are v4 only. However, the reality is there are two possible outcomes, residences getting 10/8, 172.16/12, or 192.168/16 which *completely* breaks P2P (and probably many wireless routers presuming those prefixes won't come from the WAN), or NAT64 where the P2P graph may not be as connected, but all v6 peers can reach each other. Since P2P designs are inherently tolerant of unreliable ability to reach peers, this should suffice for a while.
Major architects in v6 world advocated the dual-stack method as the way to theoretically move on with no thought to the practical motivations to move forward. They hated NAT in every way as it breaks the peering model they hold dear. They hated accepting the practical view that most of the internet are clients and few are servers. If they had embraced it from the beginning, then I suspect most residences would be v6 by now.
It is interesting that the private companies killed off the walled garden without intervention. It's an example where companies didn't think long term and went for short term advantage that *happened* to luck out for the consumers. If they had thought long term business, they would've emphasized exclusive content and explicitly not granted internet connectivity (maybe allowed email, but no routable IP address to the home), making it hard to move from one service to another. We are very fortunate things didn't go that way.
In terms of the article, I don't see FCC mandating full stack to the point of mandating a portal UI (absolutely no precedent of that). If they would have hypothetically stood in the way of service providers offering internet on top of their other services, it would not have been due to instability, but obscenity. Even then they would probably have just required parental controls to access the internet at all. I do see them not moving to shift the open/closed status quo one way or another (if the general market is open, they do endeavor to preserve openness, but if the market is closed, they don't seem too eager to open it up excessively much, e.g. cable television).
The only entities that would have stopped the internet are private companies.
Except, you know, to make my software run better...
But, for a non-trivial and increasing share of their market, the hardware is 'good enough' until it physically breaks. Sure, some people are always going to want the newest software to run with as any features possible enabled and they will feed demand for hardware churn, but a lot of the market won't care except when the next software features enhanced integration with the latest and greatest social networking fad. If those guys can get that without a new phone for free, that's a problem for manufacturers. One would hope an open manufacturer would have this advantaged recognized, but most of the market is too short sighted to think beyond their immediate needs.
To be derisive of hunt and peck is nonsense in this context. I know a fair share of respectable speed typists not doing proper technique. Will they ever hit the 90+ WPM, perhaps not, but it really doesn't matter to that degree.
Speed only matters insofar as it gives an indirect indication of experience. If they are painfully slow, it means they haven't gotten much experience on a keyboard one way or another, which is a bad sign for a programmer. It's sort of a subjective measure, I'd guess 50 WPM ballpark would be what an experienced programmer would pull off if hunt and peck (I haven't measured lately, but I was 60 WPM when I did hunt and peck, probably no faster now even though I am using home row, but with dvorak).
I would say gadget freaks are more likely to be all about all the bells and whistles, hardware or software, but your point is valid at this second.
However, look forward to the near future, and I think you'll find only the enthusiasts lacking for new hardware bells and whistles. I think the desktop/laptop market is there, I know many cases of 5-7 year old desktops of family members because they simply don't need anything new. Their hard drive still has more free space than used space, the applications they run now aren't particularly more demanding than they were then. However, their biggest problem over time was software. Pre-installed crapware by the ton expired trial periods go into full nag mode, years of being on the internet has cause them to accumulate more crapware/toolbars, and also they managed to get snagged by some trojans. This was enough to make them think they needed a whole new system, but I went in and made it 'like new' and suddenly it's acceptable again.
Carriers probably care about lockdown less and less, their restricting of features to try to push their 'special' services just isn't working, but manufacturers. One exception, carriers also have to be tech support for devices, which is a PITA while the handsets are evolving quickly if people hold on to old devices and are in the practice of changing them around a lot.
If you can put latest and greatest Android on an end-of-lifed handset they haven't gotten money for in two years, they get nothing.
If they successfully lock things down so that you need to buy a *new* handset to get the snazzy new features. If most of the reason people get new things is for software, then the hardware vendor has their own interests in making sure their stuff comes along for the ride.
My experience has been largely: -if working on existing progress, continue in language it is already in -if working on new project, what's the language most comfortable for the most developers available
Frequently, the answer continues to be perl, sometimes python, sometimes ruby. Usually, I can't be bothered to care. If it comes down to my call, currently I prefer: -If planning to use across many OS updates, perl5. Nice and stagnant, not screwing around with how it does things, perl6 threatens this. -If not expecting a lot of churn on the runtime but active development across random developers coming and going as available, python as it forces readability. -If expected to work in a barebones as possible generic windows, vbscript, but please no. -If wanting to work with as few prereqs as possible on Windows server 2008r2/7, then powershell. -Have gone along with ruby, but have not personally found the magic situation I personally prefer it for above all other possibilities.
Slashdot Mirror
iSCSI operation against a writable snapshot of a lun. Or various nfsroot solutions for linux. Or probably a number of other things...
This patent was filed in 2006, back when Apple was taking enterprise semi-seriously. Expect the validity of this one to be a moot point as Apple ignores it.
I would be interested in knowing how that works for XMB content. Namely what are their prospects for revoking keys used to sign existing apps/games without completely screwing over published apps/games. I would imagine disc-based would be a problem, but maybe they could somehow revoke a key for things that could have only come via PSN and require updates with new sigs.
Obviously, not a particularly savvy guy on this front, I just dream of a MythTV frontend on my XMB without screwing up the rest of it. The UPnP stuff does a respectable, generic job but I just want more.
We could've obtained appldr, (the loader used to load games and apps), but chose not to, since we are not interested in app-level stuff
Would that be the required bit for homebrew apps to be able to appear on the XMB of stock GameOS without Sony intervention?
Google isn't getting in the way there. The handset maker has what amounts to a significant fork. They require time to modify it. Google can't do anything about that. Maybe they could 'improve' the default UI, however it's a highly subjective thing and the handset manufacturers will continue to impose their own distinct vision of how it should be, so that is probably a dead end.
Discussion on Android is falling into the same pitfall that linux does. People bitch and moan about how enterprise distributions are 'behind', or how one distro has patched something another hasn't, or how one has picked KDE or Gnome as the default. If you have a phone with an OS that *happens* to be 'Android based', but provided by your handset manufacturer rather than straight from google, then you should treat it as completely distinct and Android 2.2 has no meaning for you.
I wonder if the handset makers should start branding Android in a way to mitigate this, relegating Android base as something like 'Android compliant' or something like that.
Do you want something that "just works" out of the box
Well, except frequently the alarm...
Do you like to be able to modify every little facet of your phone
Once someone figures out how to circumvent the protection put in place by the handset manufacturer.
It was an awesome game, but The Wizard was less 'inspired' by the game and more a commercial funded by Nintendo for all things Nintendo. It's a testament more for Nintendo's commitment to advertising than how 'big' it was. Otherwise, the Powerglove was an awesome, era defining device (unless you take the "it's so bad" line ironically...).
While not excusing the pretty atrocious iPhone alarm quality, an alarm clock with battery backup is about 5 dollars, is always exactly in the same place, has big, simple physical buttons dedicated for alarm clock function, and is so damn simple that no one really screws them up (at least the ones that have no clue what day it is and don't do auto-adjust for DST and the like).
For the application of alarm for waking you up for bed, I would highly recommend that anyone who uses their phone instead of any alternative stop doing so. The complexity causes stupid risks like this and the interface is hostile to operation when you were unconscious seconds before.
There remains the case of daytime alarms that is problematic, but I don't know about the iPhone and how/if calendar notifications in their platform are affecting/make moot daytime alarms.
One of the more interesting things about it is that you develop on it using Adobe Air, instead of the traditional Blackberry SDK.
I suppose that could be interesting for them. I wonder if Adobe has their game together on mobile devices yet, the time from initial promise of flash first appearing on devices to first time it actually appeared was a long time. The company can't even consistently deliver a 64-bit build alongside their 32-bit build. It gives me some doubts about their ability to maintain a lot of architectures and OSes (QNX, Linux w/ X, Android, WebOS Windows, OSX, x86, arm)
But that's not what it's about. It's about a curated set of software that is all updated more automatically than current software. What's wrong with that?
If it were like apt or yum where any organization could set up their own repository and augment/replace Apple's source, then I would be less worried. My understanding is they do not, however Cydia is going to set up another one. I consider that to be aggravating as it means it isn't extensible. WebOS has a similar situation, the App Catalog and the Preware repository. The Preware view does endeavor to present the app catalog as a subset, but the app catalog will not. I find this a bit sloppy.
I don't mind it as a strictly additional feature, but I'm wary of Apple having a taste of control over the iPhone/iPod (where users are *forbidden* from sideloading) and seeking to pursue that end game in OSX or alternatively giving up on OSX altogether in favor of iOS. I suppose I have little 'right' to worry or complain since I never buy apple stuff and I find plenty of competent alternatives that do what I want.
I think Touchstone is a fantastic thing to have baked into your platform strategy, *particularly* with the exposition feature opened up to third-party stuff.
It's the only platform I see that is feasible to build a blind-dock automotive application. Bluetooth pairs with stereo system, and GPS/Internet radio app auto-start when user just slaps the phone in the vicinity of a car-mounted touchstone. iPhone comes closest, but their docking is generally clumsy in cars (most of the time a cable coming out clumsily somewhere, best case a headunit that still requires relatively precise guidance to get in right.
Verizon iPhone, not my thing, but I get it.
Blackberry Playbook, most interesting aspect is blackberry ripped off WebOS gestures/display for multitasking. However, I am generally skeptical that Blackberry can get out of their niche of mostly business only, they spent way too long with a behind-the-curve platform.
Honeycomb, will see, but I don't see how people get excited over a "we'll get it right *this* time" promise.
If they were going to say 'tablets', they could've skipped Blackberry and Honeycomb. I personally still don't get the tablet fuss and wonder if it is destined to be a dead fad. I would be more excited over phones with glasses display and 'Kinect' like controls, though I really like tactile feedback. Done right that gives 'bigger' personal experience with increased convenience and privacy.
ChromeOS, I view as a dead-end. They should have focused more on enriched Android as a common platform. I don't think Google's name will salvage a concept even more limited than the Linux-only netbook attempts that did not do so well in the market.
Dual-core phones, I wouldn't mind *but* I don't know the power draw difference expected. Memory has hurt my experience more than processor.
Mac app store, please don't be *eager* for that. Why seek more and more ongoing draconian control over the product you purchase?
Google TV falls under the Honeycomb category, "this time it will be better" with no substantive evidence is not the makings of interesting news. Generically saying improved internet enabled TV, maybe. I personally treat my display as a dumb display and prefer the 'smarts' to be small, relatively inexpensive changeable parts.
Hulu for magazines. I think a magazine company might dream of a day where the magazine model dominates, but I just don't see that happening. A web presence in which articles are published as they are ready (not waiting for the next publish date) and adaptive formatting is well-established means e-magazines don't make a whole lot of sense.
Sure, Intel and AMD tech refreshes belong there.
I suspect the playstation phone will be more n-gage than DS. Nintendo 3DS is probably a more 'sure thing' for this sort of slot.
Will see if the net neutrality stuff has any impact. Most commentary I saw was that it was enough to give some annoyance to carriers, but not enough teeth to actually do anything.
I would be willing to be wowed by a second-chance WebOS set of devices. I loved so much about the Pre (WebOS, plug-free 'dock' that can be detected by software, remarkably malleable to consumer manipulation with blessing of vendor). If they did have a portrait slider & keyboardless phone to flesh out their portfolio, that could be exciting. Too bad I don't have hopes of more than just Android and iPhone long term in the mobile market.
I will say that the Mac Pro is a workstation (dual Xeon sockets don't come cheap from anyone) and not a 'consumer desktop' and all dual socket workstations are way expensive regardless of vendor (only a niche market really 'needs' them). Frankly I wonder if those and the 'server' branding of those machines will go the way of the Xserve sooner rather than later.
They simply have nothing in the expandable desktop market. They simply are not interested in serviceable products. I wouldn't be surprised if in the next year they drop support for anything not installed via an app store even in their desktops. They are that sort of company, and most people who would be interested in that flexibility justifiably avoid anything with Apple's name on it like the plague.
NAT is evil. Skype needs to build an overly complex networking protocol because too many people are behind NAT gateways. Skype *could* probably get away with their basic available hardware if only they got to design for a NAT free world.
One could also say they were trying to cheap out and not invest as much hosting required to assure reliability of their chosen networking architecture.
Of course, on the flip side, Skype as a service would be nearly useless in a NAT-free world. No need for a coordinating entity other than DNS if all peers can directly ring up the address of their recipient. Even in multi-user desktop/migration scenarios one could have a DNS record that points to the 'active' user and deregisters on logout. Some may argue that skype would still be cleaner, and of course they still have the bridge to phone feature.
Geohot's claim was specifically that he had a way to exploit Other OS. None of the actual attacks in the wild had anything to do with Other OS.
The first couple of moves were buffer overflows in the PS3 USB stack.
This supposed move is deriving Sony's signing key.
None of the hacks had anything to do with OtherOS. All signs point to Geohot being full of it.
However, I was never satisfied with Other OS, since it locked out the GPU, relegating a whole lot of easy things in most of the world as huge endeavors as people tried desperately to use the PPUs to compensate for a dumb framebuffer. I wonder how many people were explicitly disinterested before thanks to Other OS, or would have not cared if Other OS had never been allowed, but took the Other OS removal as a challenge to break them.
This sounds like it's a way to have signed applications, no modifications in hardware or software required. Of course, we won't know until proof of concept rolls out.
Game servers are supposed to be coloed in datacenters the way CCP, Blizzard, Zynga, etc. do it,
And yet in many PC games, if I host a game, I am indeed the server. It's obvious by how shaping affects everyones gameplay and how my friend on the same network segment gets incredible connectivity compared to everyone else. Game hosting in datacenters for decentralized games (i.e. not MMO) is more an artifact of NAT mess than the ideal, cheap solution.
So why would carriers make effort to allow peer-to-peer file sharing applications?
I like to live in a dream world where carriers are swayed by what their customers want. File-sharing isn't the only peer-to-peer app (though there are non-infringing uses of that). Conferencing is another example. SIP last I checked was something that required some cooperation from the NAT gateway and IIRC, only one PBX per IP would be possible, so if the carrier even in theory gave port forwarding access, they couldn't serve two on the same IP.
All sorts of arguments and counter-examples of protocol designs that have contorted themselves and used a third-party broker to unbreak the NAT is there, but networking was never *supposed* to be that hard. A whole lot of conferencing, voip, and gaming network protocols would be *greatly* simplified without NAT, and NAT64 would be the compromise to get to the right place eventually. If you are going to give a mobile phone a useless IPv4 address anyway, might as well give it an 'almost' useless IPv6 address.
A smartphone may have rich applications or be used for tethering, opening it up to all sorts of awkwardness. If game servers and peer 2 peer applications try to run and fail, it will look bad.
Also, as others note, carrier level NAT is a demanding proposition that will degrade performance. With NAT64, the same thing is incurred, but there is the likelihood that over time, a smaller proportion of traffic will hit the NAT alleviating the degradation. That possibility does not exist with v4 only NAT using private addresses.
Thanks to finally embracing NAT64, this becomes easy.
If you are providing 'server' access, you pretty much *have* to get an IPv4 address, and preferably an IPv6, but not absolutely required for now. Short term, don't sweat it, medium term go dual stack at first opportunity that presents itself, long term you may take down the IPv4 network one day, but don't explicitly plan when that day will come. The common strategy may continue to be ignore v6 entirely, however moving dual stack at your pace ensures that in the slim, but real possibility that your next-hop provider stops IPv4 routing or starts penalizing IPv4 use via unreasonable fees won't put you in a tight spot. The scenario of next-hop penalizing/dropping v4 is the only scenario I see as sufficient motivation to get servers to bother with v6 at all. I think even brand new servers will do what it takes to secure IPv4 space, which may free up some given the next point...
If you are setting up a network as 'clients', you can get by with either IPv6 or IPv4 for a while. Giving dual stack when available is nice, but whatever you have would be sufficient. ISPs without IPv4 addresses available for new clients should rapidly pursue IPv6 for residential customers and give them most internet via NAT64 on their end. Doing IPv4 private addresses would doom them to crappy service indefinitely, whilst IPv6 would only be semi-crappy for a more temporary interval. If you *really* want v6 to catch on, then start allowing v4 addresses to be carved up more free-market style. All technical experts agree that this would completely fubar the v4 network performance in aggregate, but you would entice adoption of v6+NAT64 with the profitable opportunity to reclaim addresses and sell them to places that *really* need them. The v6 network would be nice and cleanly routed, and getting on the v6 network just becomes that much more important.
Some would argue that any sort of NAT at the carrier plays right into the hands of those who hate P2P networks, including NAT64 as those behind NAT64 are unreachable by peers who are v4 only. However, the reality is there are two possible outcomes, residences getting 10/8, 172.16/12, or 192.168/16 which *completely* breaks P2P (and probably many wireless routers presuming those prefixes won't come from the WAN), or NAT64 where the P2P graph may not be as connected, but all v6 peers can reach each other. Since P2P designs are inherently tolerant of unreliable ability to reach peers, this should suffice for a while.
Major architects in v6 world advocated the dual-stack method as the way to theoretically move on with no thought to the practical motivations to move forward. They hated NAT in every way as it breaks the peering model they hold dear. They hated accepting the practical view that most of the internet are clients and few are servers. If they had embraced it from the beginning, then I suspect most residences would be v6 by now.
It is interesting that the private companies killed off the walled garden without intervention. It's an example where companies didn't think long term and went for short term advantage that *happened* to luck out for the consumers. If they had thought long term business, they would've emphasized exclusive content and explicitly not granted internet connectivity (maybe allowed email, but no routable IP address to the home), making it hard to move from one service to another. We are very fortunate things didn't go that way.
In terms of the article, I don't see FCC mandating full stack to the point of mandating a portal UI (absolutely no precedent of that). If they would have hypothetically stood in the way of service providers offering internet on top of their other services, it would not have been due to instability, but obscenity. Even then they would probably have just required parental controls to access the internet at all. I do see them not moving to shift the open/closed status quo one way or another (if the general market is open, they do endeavor to preserve openness, but if the market is closed, they don't seem too eager to open it up excessively much, e.g. cable television).
The only entities that would have stopped the internet are private companies.
Except, you know, to make my software run better...
But, for a non-trivial and increasing share of their market, the hardware is 'good enough' until it physically breaks. Sure, some people are always going to want the newest software to run with as any features possible enabled and they will feed demand for hardware churn, but a lot of the market won't care except when the next software features enhanced integration with the latest and greatest social networking fad. If those guys can get that without a new phone for free, that's a problem for manufacturers. One would hope an open manufacturer would have this advantaged recognized, but most of the market is too short sighted to think beyond their immediate needs.
To be derisive of hunt and peck is nonsense in this context. I know a fair share of respectable speed typists not doing proper technique. Will they ever hit the 90+ WPM, perhaps not, but it really doesn't matter to that degree.
Speed only matters insofar as it gives an indirect indication of experience. If they are painfully slow, it means they haven't gotten much experience on a keyboard one way or another, which is a bad sign for a programmer. It's sort of a subjective measure, I'd guess 50 WPM ballpark would be what an experienced programmer would pull off if hunt and peck (I haven't measured lately, but I was 60 WPM when I did hunt and peck, probably no faster now even though I am using home row, but with dvorak).
They don't manufacturers do want them to do that.
I would say gadget freaks are more likely to be all about all the bells and whistles, hardware or software, but your point is valid at this second.
However, look forward to the near future, and I think you'll find only the enthusiasts lacking for new hardware bells and whistles. I think the desktop/laptop market is there, I know many cases of 5-7 year old desktops of family members because they simply don't need anything new. Their hard drive still has more free space than used space, the applications they run now aren't particularly more demanding than they were then. However, their biggest problem over time was software. Pre-installed crapware by the ton expired trial periods go into full nag mode, years of being on the internet has cause them to accumulate more crapware/toolbars, and also they managed to get snagged by some trojans. This was enough to make them think they needed a whole new system, but I went in and made it 'like new' and suddenly it's acceptable again.
I was talking about *manufacturers* not carriers.
Carriers probably care about lockdown less and less, their restricting of features to try to push their 'special' services just isn't working, but manufacturers. One exception, carriers also have to be tech support for devices, which is a PITA while the handsets are evolving quickly if people hold on to old devices and are in the practice of changing them around a lot.
If you can put latest and greatest Android on an end-of-lifed handset they haven't gotten money for in two years, they get nothing.
If they successfully lock things down so that you need to buy a *new* handset to get the snazzy new features. If most of the reason people get new things is for software, then the hardware vendor has their own interests in making sure their stuff comes along for the ride.
My experience has been largely:
-if working on existing progress, continue in language it is already in
-if working on new project, what's the language most comfortable for the most developers available
Frequently, the answer continues to be perl, sometimes python, sometimes ruby. Usually, I can't be bothered to care. If it comes down to my call, currently I prefer:
-If planning to use across many OS updates, perl5. Nice and stagnant, not screwing around with how it does things, perl6 threatens this.
-If not expecting a lot of churn on the runtime but active development across random developers coming and going as available, python as it forces readability.
-If expected to work in a barebones as possible generic windows, vbscript, but please no.
-If wanting to work with as few prereqs as possible on Windows server 2008r2/7, then powershell.
-Have gone along with ruby, but have not personally found the magic situation I personally prefer it for above all other possibilities.