Because the Google dev decided that they absolutely needed sms and telephony, and the app shouldn't work if those two items weren't there. At least they specified such in the proper way, so it'll at least tell you at install-time that you're SOL instead of bombing out randomly.
Checking the app's plist, it's iPhone only because Google's developer on it decided that it would require the following: - gps (includes GSM/CDMA iPads) - location-services (all devices since wifi can give you some form of a fix) - sms (iPhone) - telephony (iPhone) - wifi (all devices)
As the only items which match all of it are iPhones, that's all it'll install on. Now why they decided it required telephone and sms, and didn't just gracefully downgrade when they're lacking, I have no idea. It's kind of sloppy.
Yes on the first, be aware on the second. It's been deprecated, as noted at http://php.net/manual/en/features.safe-mode.php Safe mode is really a band-aid on an open wound. mod_security, suhosin, proper file ACLs, etc. are all likely better options for dealing with the sorts of things safe_mode buys you, and all but suhosin are applicable to anything that isn't PHP.
Aside from that, a good list. The one thing that can't be said enough: NEVER TRUST CLIENT INPUT. VERIFY, VERIFY, VERIFY.
The problem that had been noted with VLC was that you had to go to a 'third party' site for the source, and you couldn't build the actual app and install it without additional hurdles. In this case the Xcode application itself isn't GPLd, LLVM (the default C/C++/Obj-C compiler) is similar to the BSD license, and any GPL source elements are available from Apple (http://opensource.apple.com/).
Xcode4 is kind of an odd duck in that it doesn't conform specifically to OSX AppStore guidelines (installs outside of/Applications, isn't a single.app file, etc)
You do realize those development tools you're talking about are FOSS-derived, right? Xcode sits on gcc/llvm. Apple is a huge backer of LLVM (BSD licensed). Aside from the IDE UI bits and codesign, the dev tools are the same as you'll find on your own *nix system.
And have to push new TCP/IP stacks for most operating systems to get them to understand that that is now viable space. This would be effort better spent on just going IPv6.
Aside from the app signing aspect, it's either GCC or LLVM for the compiler and toolchain. All those OSS things you love.
The astronauts wouldn't be touching station control software development while they're on-board. The developers on the ground would be the ones who need an OSX system, and I'd be kind of surprised if they don't have some knocking around. I mean, there is a NASA iOS application, so they've got some will to do iOS development in at least one part of the organization.
iOS 4 also lets you deploy an app on authorized devices wirelessly, and it's stupidly simple to do. No AppStore required.
Apple is clearly abusing its users: If you buy one of my outrageously overpriced devices, you will only be able to login as an unprivileged user, we reserve the right to login as administrators.
I hope you're not trying to compare to Android, since the above could easily apply there too under most carriers.
You will be able to install applications, but only if we approve them first. We decide what apps you get and what apps you don't arbitrarily, and you have no part in that process.
App store policies are now published, and they've been following them pretty well it seems, based on the types of apps which had been in limbo, and have since been approved post-policy posting. Google Voice was also pulled by Google post-publishing of those guidelines, since they wanted to update it, which they did, and it was approved.
If you want to install an app, first you need to sign up in our store, give us all of your personal information, and you will have to give us your credit card. We are the only providers, we are a monopoly, you can't buy apps from anywhere else.
Aside from the "no other store" it's not much different than any other purchase you make online.
Also, we'll keep 30% of what you pay for any app. We will restrict what apps you can use based on where you are, who you are, or other parameters we can arbitrarily choose later. We will actively discriminate our users. Also, your device has a kill switch, and we disable it any time we want.
30% is light for distribution costs compared to anything you find in the brick & mortar world. It's also something that is more of a developer concern than an end-user. Once you have an app installed, you can use it. Any regional restrictions on app store visibility would be up to the developer. There may be rules in place that the app developer had to abide with to get the app approved, such as the earlier VoIP over Wifi only restriction, which has since been lifted. The Kill Switch exists on most of the other smartphones as well. Apple has yet to use theirs. The only known use of any kill switch on an iOS device so far has been the remote bricking of the prototype iPhone 4. They've never killed an app, even ones which got approved and were in violation of app store rules.
We also control what songs, music or other content you download, and deliberately add restrictions to those files, so they are ours, not yours.
You can download and put whatever you want in media on your phone/iPod/iPad. If you want to buy it from online, you have the option of using iTunes... which has no DRM on the music files. You can also get your music from anywhere else, and copy it onto your iOS device as mp3, aac, etc. Video files still have DRM, but you'll get that with pretty much any paid video download (Hulu, Netflix, etc.)
Certainly. There's nothing that mandates a/64 allocation for routing. That's convention to keep from blowing up routing tables, same as not taking BGP announcements for longer than/24s. You can subnet down to the/128 if you really want in v6 and routing will continue to work. You just will have a larger table, and won't be able to use RA/SLAAC for host assignments where statics don't matter.
It is opt-out by default. In order for anyone to see your real 'meatspace' identity, they have to request to be your RealID friend, and you then have to approve them. And in order for them to do that, they have to know one of the following: - Your battle.net account name - Be a friend of a friend of yours (who you would have approved by means of the above or below) - Be a friend of yours on facebook, and you would have had to login via SC2 to your facebook account.
All of those require you to have done some deliberate action to get into the RealID pool. These new options let you disable #2 and 3, and let you completely disable RealID. You could already block requests.
As this is still a fairly new development, who knows if the Flash->iOS native inherits the same faults of the original runtime. I would tend to think it's likely that it will, for the following reason. It would be far easier and less prone for porting weirdness for Adobe to build a Flash as static link library and stub launcher that can bind against the data chunk from a source.fla than to completely transcode the.fla into native code.
No, it's a function Flash isn't using: usleep().;-)
Basically Flash has a tendency to spin its wheels while waiting a lot more than a normal application. Continually polling for stuff to do is heavy on the processor and consequently is detrimental to battery life.
At least on OSX, this might not be entirely true for Cataclysm. The launcher actually registers itself with Bonjour with a service of _bzdn._tcp, and the usual downloader identifier you'd see in the p2p stats for the pre-Cata downloader. The only reason I can think of to do that, would be to announce on your local LAN that you are a valid source for download data. Might not need to copy a thing between systems if this is true. I'll have to test this on the next patch.
You have two ISPs. You get a/64 or/48 from each of them. Each router announces that prefix into your network and each of your systems get their own v6 addresses off of each prefix based off of that RA information your routers spit out.
But wait, a link drops! Prefix is withdrawn, systems down their IPs on the down interface, systems will use the other gateway and addresses from that prefix. Crisis averted.
I had two external floppy drives for my A500. Great for games that were smart enough to check all drives for the next disk.
I think the whole concept of how disks were addressed was the underlying reason for this. Having the disk name be one of the accessors was key. ATLANTIS10: was ATLANTIS10: whichever drive it was in, or whereever it was Assigned to. The HD installer for FoA was simply a series of: Copy FD0:* HD0:Indy/ Assign Atlantis#: HD0:Indy/
That was also a key thing for people to remember when implementing the early days of copy protection: your disk name is not a unique butterfly, it can be moved.
Correlate this, then: if so, why do they still use DRM?
Let's see: - SC: No CD, just a key. Digital download. - D2: No CD, just a key. Digital download. - War3: No CD, just a key. Digital download. - WoW: No CD, just an account. Digital download.
None of those have copy restrictions, aside from having to buy a copy originally to get your key or account. I'm not seeing the DRM here.
As he noted, they have free basic as part of their franchise agreement with Comcast, so there's no out-of-pocket from the city budget for this service.
As to why they need TV: on-duty firefighters between calls, idling in the station, waiting rooms in city offices, conference rooms with local/national news, TVs displaying city meetings over the city channel, etc.
Because SC2/WoW have access to your facebook password to pull your friends list? Oh wait, they don't. It will be available, but it's not automatic. Much like giving up your email address book to facebook to scan them.
As to RealID itself, I don't mind the in-game functionality of it. The people on my RealID list are people who already know me. Everyone else is just via character name. The change to the forum, however, I do expect there to be problems.
In this case, I have to disagree with you. While enhancing the commercial services sounds good on paper, we've seen how good they are at managing themselves under normal use, in urban areas: read AT&T service. Imagine how that would be in rural environments where they have no financial gains to be in. Look at coverage maps of the US of all the major carriers, especially on the 3G/4G protocols: they exist in the population centers. There are still places you won't get EDGE or GPRS, and barely get voice. They also require a fair amount of infrastructure to operate properly; they don't run in a vacuum. As to things like FRS... yeah, doesn't even compare.
Now, Amateur Radio... Joe with his HT is stuck on a back trail, but has signal to a repeater, 20 miles away, which is on-grid, but with batteries and generator for days. What infrastructure exists in the HAM world is primarily all run by volunteer or local emergency auxiliaries, for the cases when the primary infrastructure goes kablooie. HAMs can setup and tear-down their comms in short order for whatever job needs done. It's too bad you didn't have this kind of commentary last week, as you should have stopped by Field Day and seen what is involved, and why it is. http://www.arrl.org/field-day
What happens when 5000 people download an iPhone application, and then that application gets removed from the app store? Do those 5000 copies stay on the phones they were originally downloaded on?
Sure do. And the computers they've been synced on, and any future phones they're synced onto. Pulled from the store doesn't remove them from the wild.
Slashdot Mirror
Because the Google dev decided that they absolutely needed sms and telephony, and the app shouldn't work if those two items weren't there. At least they specified such in the proper way, so it'll at least tell you at install-time that you're SOL instead of bombing out randomly.
Checking the app's plist, it's iPhone only because Google's developer on it decided that it would require the following:
- gps (includes GSM/CDMA iPads)
- location-services (all devices since wifi can give you some form of a fix)
- sms (iPhone)
- telephony (iPhone)
- wifi (all devices)
As the only items which match all of it are iPhones, that's all it'll install on. Now why they decided it required telephone and sms, and didn't just gracefully downgrade when they're lacking, I have no idea. It's kind of sloppy.
Turn register globals off in PHP. Use safe mode.
Yes on the first, be aware on the second. It's been deprecated, as noted at http://php.net/manual/en/features.safe-mode.php Safe mode is really a band-aid on an open wound. mod_security, suhosin, proper file ACLs, etc. are all likely better options for dealing with the sorts of things safe_mode buys you, and all but suhosin are applicable to anything that isn't PHP.
Aside from that, a good list. The one thing that can't be said enough: NEVER TRUST CLIENT INPUT. VERIFY, VERIFY, VERIFY.
The problem that had been noted with VLC was that you had to go to a 'third party' site for the source, and you couldn't build the actual app and install it without additional hurdles. In this case the Xcode application itself isn't GPLd, LLVM (the default C/C++/Obj-C compiler) is similar to the BSD license, and any GPL source elements are available from Apple (http://opensource.apple.com/).
Xcode4 is kind of an odd duck in that it doesn't conform specifically to OSX AppStore guidelines (installs outside of /Applications, isn't a single .app file, etc)
Because it pays attention to the Parental policies.
You do realize those development tools you're talking about are FOSS-derived, right? Xcode sits on gcc/llvm. Apple is a huge backer of LLVM (BSD licensed). Aside from the IDE UI bits and codesign, the dev tools are the same as you'll find on your own *nix system.
And have to push new TCP/IP stacks for most operating systems to get them to understand that that is now viable space. This would be effort better spent on just going IPv6.
Aside from the app signing aspect, it's either GCC or LLVM for the compiler and toolchain. All those OSS things you love.
The astronauts wouldn't be touching station control software development while they're on-board. The developers on the ground would be the ones who need an OSX system, and I'd be kind of surprised if they don't have some knocking around. I mean, there is a NASA iOS application, so they've got some will to do iOS development in at least one part of the organization.
iOS 4 also lets you deploy an app on authorized devices wirelessly, and it's stupidly simple to do. No AppStore required.
Apple is clearly abusing its users: If you buy one of my outrageously overpriced devices, you will only be able to login as an unprivileged user, we reserve the right to login as administrators.
I hope you're not trying to compare to Android, since the above could easily apply there too under most carriers.
You will be able to install applications, but only if we approve them first. We decide what apps you get and what apps you don't arbitrarily, and you have no part in that process.
App store policies are now published, and they've been following them pretty well it seems, based on the types of apps which had been in limbo, and have since been approved post-policy posting. Google Voice was also pulled by Google post-publishing of those guidelines, since they wanted to update it, which they did, and it was approved.
If you want to install an app, first you need to sign up in our store, give us all of your personal information, and you will have to give us your credit card. We are the only providers, we are a monopoly, you can't buy apps from anywhere else.
Aside from the "no other store" it's not much different than any other purchase you make online.
Also, we'll keep 30% of what you pay for any app. We will restrict what apps you can use based on where you are, who you are, or other parameters we can arbitrarily choose later. We will actively discriminate our users. Also, your device has a kill switch, and we disable it any time we want.
30% is light for distribution costs compared to anything you find in the brick & mortar world. It's also something that is more of a developer concern than an end-user. Once you have an app installed, you can use it. Any regional restrictions on app store visibility would be up to the developer. There may be rules in place that the app developer had to abide with to get the app approved, such as the earlier VoIP over Wifi only restriction, which has since been lifted. The Kill Switch exists on most of the other smartphones as well. Apple has yet to use theirs. The only known use of any kill switch on an iOS device so far has been the remote bricking of the prototype iPhone 4. They've never killed an app, even ones which got approved and were in violation of app store rules.
We also control what songs, music or other content you download, and deliberately add restrictions to those files, so they are ours, not yours.
You can download and put whatever you want in media on your phone/iPod/iPad. If you want to buy it from online, you have the option of using iTunes... which has no DRM on the music files. You can also get your music from anywhere else, and copy it onto your iOS device as mp3, aac, etc. Video files still have DRM, but you'll get that with pretty much any paid video download (Hulu, Netflix, etc.)
RFC3021
Certainly. There's nothing that mandates a /64 allocation for routing. That's convention to keep from blowing up routing tables, same as not taking BGP announcements for longer than /24s. You can subnet down to the /128 if you really want in v6 and routing will continue to work. You just will have a larger table, and won't be able to use RA/SLAAC for host assignments where statics don't matter.
It is opt-out by default. In order for anyone to see your real 'meatspace' identity, they have to request to be your RealID friend, and you then have to approve them. And in order for them to do that, they have to know one of the following:
- Your battle.net account name
- Be a friend of a friend of yours (who you would have approved by means of the above or below)
- Be a friend of yours on facebook, and you would have had to login via SC2 to your facebook account.
All of those require you to have done some deliberate action to get into the RealID pool. These new options let you disable #2 and 3, and let you completely disable RealID. You could already block requests.
Not yet a suit, just an investigation. And now, not likely to become one.
As this is still a fairly new development, who knows if the Flash->iOS native inherits the same faults of the original runtime. I would tend to think it's likely that it will, for the following reason. It would be far easier and less prone for porting weirdness for Adobe to build a Flash as static link library and stub launcher that can bind against the data chunk from a source .fla than to completely transcode the .fla into native code.
No, it's a function Flash isn't using: usleep(). ;-)
Basically Flash has a tendency to spin its wheels while waiting a lot more than a normal application. Continually polling for stuff to do is heavy on the processor and consequently is detrimental to battery life.
They're still verboten by the new rules:
2.5 Apps that use non-public APIs will be rejected
The wireless framework is a non-public API under iOS.
At least on OSX, this might not be entirely true for Cataclysm. The launcher actually registers itself with Bonjour with a service of _bzdn._tcp, and the usual downloader identifier you'd see in the p2p stats for the pre-Cata downloader. The only reason I can think of to do that, would be to announce on your local LAN that you are a valid source for download data. Might not need to copy a thing between systems if this is true. I'll have to test this on the next patch.
Already works fine in v6, no SNAT required.
You have two ISPs. You get a /64 or /48 from each of them. Each router announces that prefix into your network and each of your systems get their own v6 addresses off of each prefix based off of that RA information your routers spit out.
But wait, a link drops! Prefix is withdrawn, systems down their IPs on the down interface, systems will use the other gateway and addresses from that prefix. Crisis averted.
I had two external floppy drives for my A500. Great for games that were smart enough to check all drives for the next disk.
I think the whole concept of how disks were addressed was the underlying reason for this. Having the disk name be one of the accessors was key. ATLANTIS10: was ATLANTIS10: whichever drive it was in, or whereever it was Assigned to. The HD installer for FoA was simply a series of:
Copy FD0:* HD0:Indy/
Assign Atlantis#: HD0:Indy/
That was also a key thing for people to remember when implementing the early days of copy protection: your disk name is not a unique butterfly, it can be moved.
Correlate this, then: if so, why do they still use DRM?
Let's see:
- SC: No CD, just a key. Digital download.
- D2: No CD, just a key. Digital download.
- War3: No CD, just a key. Digital download.
- WoW: No CD, just an account. Digital download.
None of those have copy restrictions, aside from having to buy a copy originally to get your key or account. I'm not seeing the DRM here.
As he noted, they have free basic as part of their franchise agreement with Comcast, so there's no out-of-pocket from the city budget for this service.
As to why they need TV: on-duty firefighters between calls, idling in the station, waiting rooms in city offices, conference rooms with local/national news, TVs displaying city meetings over the city channel, etc.
automatic Facebook integration
Because SC2/WoW have access to your facebook password to pull your friends list? Oh wait, they don't. It will be available, but it's not automatic. Much like giving up your email address book to facebook to scan them.
As to RealID itself, I don't mind the in-game functionality of it. The people on my RealID list are people who already know me. Everyone else is just via character name. The change to the forum, however, I do expect there to be problems.
In this case, I have to disagree with you. While enhancing the commercial services sounds good on paper, we've seen how good they are at managing themselves under normal use, in urban areas: read AT&T service. Imagine how that would be in rural environments where they have no financial gains to be in. Look at coverage maps of the US of all the major carriers, especially on the 3G/4G protocols: they exist in the population centers. There are still places you won't get EDGE or GPRS, and barely get voice. They also require a fair amount of infrastructure to operate properly; they don't run in a vacuum. As to things like FRS... yeah, doesn't even compare.
Now, Amateur Radio... Joe with his HT is stuck on a back trail, but has signal to a repeater, 20 miles away, which is on-grid, but with batteries and generator for days. What infrastructure exists in the HAM world is primarily all run by volunteer or local emergency auxiliaries, for the cases when the primary infrastructure goes kablooie. HAMs can setup and tear-down their comms in short order for whatever job needs done. It's too bad you didn't have this kind of commentary last week, as you should have stopped by Field Day and seen what is involved, and why it is. http://www.arrl.org/field-day
Because the Market submission process is as follows:
- Pay $25 fee to be able to publish to Market
- Upload application
- It's live!
There is no review or approval process whatsoever.
What happens when 5000 people download an iPhone application, and then that application gets removed from the app store? Do those 5000 copies stay on the phones they were originally downloaded on?
Sure do. And the computers they've been synced on, and any future phones they're synced onto. Pulled from the store doesn't remove them from the wild.