Justifiable? Sure—they're trying to sell a profitable product. Hard to imagine "price fairly compensates seller" as a major factor driving most consumer purchasing decisions, alas.
What seems off to me is the fact that they're now saying the Office applications bundled with the Surface RT "are not for use in commercial, nonprofit, or revenue generating activities," at least not without purchasing — wait for it — an additional "commercial-use" Office license.
In other words, the two featured benefits of the Surface RT over the iPad are (1) a keyboard/cover that costs $120 extra, and (2) a bundled version of Office that can't be used to do "work".
Except that Apple hasn't locked anything down in their desktop OS other than access to Apple's own online services, nor given any indication that they want to turn the Mac into a "content-consumption-only" device, nor suggested that the existing Mac UI should either be displaced or embrace "touch". To repeat: the only code on the Mac that requires "filtration, censorship, and taxation by the App Store gatekeepers" is applications that use Apple's iCloud servers for synchronization and storage, and applications that use Apple's push notification servers. Otherwise, you're free to sell your application outside the App Store, and therefore not submit to its rules. You're also free to sell the same applications on the App Store and elsewhere, and Apple has even made special provisions to ensure smooth interoperability between App Store and non-App Store versions of the same application. Microsoft's rules are very different: you can only sell Metro-style applications inside the Store, and you can only sell desktop applications outside the Store.
As "obvious" as this may initially seem, it's also wrong. I can't even reach my desktop display without getting out of my chair, it's uncomfortable to use at a distance where I can. Not to mention the discomfort of actually using a set-up like this for any extended period of time, even on a laptop. And current laptop designs, or anything resembling current laptop designs, wouldn't work well for anything but the lightest (literally and figuratively) touch input chores for a number of fairly
obvious additional reasons. But PC OEMs love "options" as much as they love low-value, low-cost "me-too" features, so why not?
Firewire was great if you were using it for high end equipment that needed high speed data transfers. It was great for things like digital video cameras and external hard drives. It fairly expensive though, and much less flexible than USB.
How so? The USB host/device distinction means that it's difficult to use for computer-to-computer connectionssuch as IP networking and "target disk" modes. Due to USB's current limitations, bus-powered I/O devices that work fine over FireWire often require either external power supplies or ridiculous "splitter cables" to connect to two USB ports simultaneously to draw sufficient power. FireWire also supports more flexible cabling arrangements, with UTP and optical cabling options that support runs up to 100m long without hubs or repeaters.
For the record, "fairly expensive" was $1 or so per device.
Should I have to bundle together an editor, source control, and an interpreter in order for those programs to use the same files inside the sandbox? Should I do this for every language I want to develop in using that editor?... Would Apple close that hole, or reject me from the app store for that reason?
No, no, and no. Sandboxed applications have free access, forever, to files and folders you explicitly select, where "forever" can even include subsequent versions of the same app. Many vendors are running away from sandboxing "to improve user experience" in ways that directly conflict with the whole notion of sandboxing: accessing the user's SSH private keys without confirmation, using Apple Events and/or the Accessibility API to control arbitrary third-party applications, and so on. Apple's goal seems to be to maximize the number of applications that can be reasonably sandboxed without undermining the whole idea of sandboxing, using the App Store and iCloud as "carrots", because they're trying to address a problem Microsoft never did: most developers don't give a damn about the mitigation of security vulnerabilities in their applications.
It's a hard problem, and discussions like Marco's will ultimately contribute to a better solution, but "give up sandbox requirements" isn't an endgame I'd like to see.
Do understand correctly that you are, in fact, dismissing the notion of calculating with inexact quantities derived from empirical observation as a masturbatory philosophical exercise?
While I agree that iOS should extend support for "opt-in" background downloading, for a mobile device, in practice I still prefer the iOS status quo to the desktop alternative of "arbitrary programs running in the background draining battery and bandwidth".
A consolidated, system-level "background download manager", while unlikely to address the torrent case, seems like a nice compromise.
In the present context at least, Objective-C seems like an even better counterexample, given that its syntax, however convenient, is notrequired to use the underlyingobject system provided by the lightweight runtime.
The final C++ program wound up having 50% more lines of code for the exact same functionality, and that was the point where I gave up on it. It was a pretty bad first impression.
I'm guessing this was because the authors were exhibiting uselessly "object-oriented" toy programs to illustrate language features. You'd probably have had a different first impression if you'd started with Cocoa and Objective-C. While it hadn't been updated in years and consequently seems to have disappeared down the memory hole, one of Apple's old Cocoa tutorials was something to the effect of "Build a Text Editor in 15 Minutes", where they showed how you could build a TextEdit-like rich text editor with Cocoa in a couple pages of code.
In fact, it's pretty easy figure out how to do this starting from the Xcode "document-based application" template, as there's not much more to it than replacing the label control in the document window with a Text View and implementing a couple methods in the document class to get and set its contents.
"Untrained in computers?" How many *nix admins do you know who either always run sudo from an absolute path, or who enforce "write xor execute" on all filesystems for any user accounts authorized to run with elevated privileges?
I won't generalize about IT departments, but many admins I've worked with certainly seem to be. For instance, I've frequently found Windows installations where Domain Admins is granted merely to allow a user to bounce a particular service, or to a service that needs write access to a few particular registry keys, because "that's the vendor-supported solution." Whether this vendor "support" extends to compensation for the cost of downtime caused by said overprivileged users accidentally installing untested "recommended" updates and rebooting a production server in the course of bouncing said service, or when a bug in the service causes it to recursively delete an unintentionally large portion of said registry, is left as an exercise.
More generally, I've found that admins seem overenthusiastic about learning about new features that vendors claim "increase security" or "reduce TCO", but are comparatively uninterested in creatively using existing features to the same ends, even when the former amounts to a monstrously complicated (i.e., because it must supportably generalize to thousands of diverse installations, not because vendors are stupid) configuration interface for the latter.
As for age, I'd say that, if anything, the problem is worse with younger admins who seem more inclined to take vendor claims at face value and assume that anything they might possibly need to know is a Google search or, at worst, a support request, away, otherwise the product is, as you say, "defective." Older admins seem to at least accept that any given component is but a part of a unique environment, and that they, not vendors, are responsible for ensuring the various parts interoperate correctly, even in an ostensibly "homogeneous" environment like a "Windows shop."
Not at all. From personal experience, it typically takes a non-backordered Apple product 2–3 business days from the origin in China to clear customs in Anchorage, then another day or so before it's ready to ship out of a FedEx Hub in, say, Indianapolis*. So you're realistically only adding about five days to the lead time, and surprisingly little cost (LOTS of iPhones to a pallet — Apple packaging isn't efficient for environmental reasons).
* As a bit of a special case, I live in Indianapolis, so I've actually had Apple products ordered on a Monday ship FedEx from China and deliver by Friday, with standard shipping (officially "5–7 day" shipping).
Sure, but even so, what if those who "excoriate execs and companies who move parts of their businesses offshore" are only a small minority? Also, so long as "components sourced abroad and assembled in a Saipan sweatshop" is "made in the USA," the mark isn't particularly informative (not that this is what Google is doing, but it does suggest some sort of additional marketing would actually be useful).
That actually sounds much better than the usual "puzzle-style" interview questions I hear. I'd personally begin by asking for high-level details. What applications do you have in mind? Alternatively, are you looking for a specific sort of boat? Without knowing the first thing about boats, there are obvious orders-of-magnitude design, process, and resource differences between building a kayak, say, and an oil tanker. Note here that I'd be careful to avoid detailed design or requirement questions: by my own admission, I don't know how to build boats, so the resulting "requirements discussion" would almost surely be "bike-shedding."
Next, given that there's (presumably) a well-established industry selling ____ boats, why are we assuming at the outset that we should build rather than buy? Suppose the answer is "we're not an end-user, our business plan involves breaking into boat manufacturing."
Fair enough. Then doing profitability requires both building and selling boats in a market with established players, and, by our (my) own admission, we (I) don't yet know how to build a boat, let alone do so well enough to make a manufacturable and marketable product (not to mention the highly nontrivial matters of actual marketing and manufacturing "at scale"). So unless we already have a crack boat-design team at our disposal (in which case, why are you asking me?) it might bewiser, at least for a few years, to get our feet wet by OEMing third-party boats, building something related but less ambitious like "boat accessories", etc., before committing to full-on "boat-building."
And so on. Presumably this is the sort of discussion they want to hear?
What could work, however, is an inexpensive "trusted media coprocessor" that takes DRM video and renders directly to the video hardware. Probably too wasteful of silicon on small mobile devices, but it could be reasonable on the desktop.
Ideally, this would be subsidized by the media companies themselves, complete with open source reference drivers. Fine with me if they want to "own"the playback hardware, so long as they're willing to pay for it...
Why would they choose this over a Metro-style app?
Re:It's not just specialization, there is also fea
on
Where's HAL 9000?
·
· Score: 1
AI is to real intelligence what margarine is to butter - it's artificial. It isn't real. You're never going to get a Turing computer to actually think, although some future chemical or something machine may.
Define "real" and "actual". Also, the Turing test isn't tied to Turing's particular theoretical model of computation, rather, it's intended to be as "cross-platform" as possible, for reasons including, but not limited to, the philosophical and linguistic quagmires involved in defining things like "intelligence" and "reality", by a simple "qualifying exam": phase one, in which we throw out all potential "artificial ducks" that can't even quack.
Apple developer tools must be installed from the App store, costs nothing but you still need a credit card. And command-line tools doesn't install by default, which is most of what I want.
And Xcode need not be installed from the App Store: installers for both Xcode and the standalone command-line tools packages are on developer.apple.com/downloads (registration required).
Here's my prediction: The version of OS X that comes after Mountain Lion will only let you install applications/software from the App Store. Again, Steve's plan; not Tim's.
So Xcode will only run on Windows and Linux?
I suppose this would shut up the "it's bullshit that iOS development requires a Mac" crowd, at least.
Slashdot Mirror
Justifiable? Sure—they're trying to sell a profitable product. Hard to imagine "price fairly compensates seller" as a major factor driving most consumer purchasing decisions, alas. What seems off to me is the fact that they're now saying the Office applications bundled with the Surface RT "are not for use in commercial, nonprofit, or revenue generating activities," at least not without purchasing — wait for it — an additional "commercial-use" Office license. In other words, the two featured benefits of the Surface RT over the iPad are (1) a keyboard/cover that costs $120 extra, and (2) a bundled version of Office that can't be used to do "work".
You mean like this and this? To say nothing of what they seem to be pushing hardest these days.
Except that Apple hasn't locked anything down in their desktop OS other than access to Apple's own online services, nor given any indication that they want to turn the Mac into a "content-consumption-only" device, nor suggested that the existing Mac UI should either be displaced or embrace "touch". To repeat: the only code on the Mac that requires "filtration, censorship, and taxation by the App Store gatekeepers" is applications that use Apple's iCloud servers for synchronization and storage, and applications that use Apple's push notification servers. Otherwise, you're free to sell your application outside the App Store, and therefore not submit to its rules. You're also free to sell the same applications on the App Store and elsewhere, and Apple has even made special provisions to ensure smooth interoperability between App Store and non-App Store versions of the same application. Microsoft's rules are very different: you can only sell Metro-style applications inside the Store, and you can only sell desktop applications outside the Store.
As "obvious" as this may initially seem, it's also wrong. I can't even reach my desktop display without getting out of my chair, it's uncomfortable to use at a distance where I can. Not to mention the discomfort of actually using a set-up like this for any extended period of time, even on a laptop. And current laptop designs, or anything resembling current laptop designs, wouldn't work well for anything but the lightest (literally and figuratively) touch input chores for a number of fairly obvious additional reasons. But PC OEMs love "options" as much as they love low-value, low-cost "me-too" features, so why not?
Presumably you mean NeXTSTEP rather than CDE?
How so? The USB host/device distinction means that it's difficult to use for computer-to-computer connectionssuch as IP networking and "target disk" modes. Due to USB's current limitations, bus-powered I/O devices that work fine over FireWire often require either external power supplies or ridiculous "splitter cables" to connect to two USB ports simultaneously to draw sufficient power. FireWire also supports more flexible cabling arrangements, with UTP and optical cabling options that support runs up to 100m long without hubs or repeaters.
For the record, "fairly expensive" was $1 or so per device.
No, no, and no. Sandboxed applications have free access, forever, to files and folders you explicitly select, where "forever" can even include subsequent versions of the same app. Many vendors are running away from sandboxing "to improve user experience" in ways that directly conflict with the whole notion of sandboxing: accessing the user's SSH private keys without confirmation, using Apple Events and/or the Accessibility API to control arbitrary third-party applications, and so on. Apple's goal seems to be to maximize the number of applications that can be reasonably sandboxed without undermining the whole idea of sandboxing, using the App Store and iCloud as "carrots", because they're trying to address a problem Microsoft never did: most developers don't give a damn about the mitigation of security vulnerabilities in their applications. It's a hard problem, and discussions like Marco's will ultimately contribute to a better solution, but "give up sandbox requirements" isn't an endgame I'd like to see.
Do understand correctly that you are, in fact, dismissing the notion of calculating with inexact quantities derived from empirical observation as a masturbatory philosophical exercise?
While I agree that iOS should extend support for "opt-in" background downloading, for a mobile device, in practice I still prefer the iOS status quo to the desktop alternative of "arbitrary programs running in the background draining battery and bandwidth". A consolidated, system-level "background download manager", while unlikely to address the torrent case, seems like a nice compromise.
In the present context at least, Objective-C seems like an even better counterexample, given that its syntax, however convenient, is not required to use the underlying object system provided by the lightweight runtime.
Except that if you read his code, he's not actually subclassing Button, he's instantiating it. He's certainly saying it wrong, though.
I'm guessing this was because the authors were exhibiting uselessly "object-oriented" toy programs to illustrate language features. You'd probably have had a different first impression if you'd started with Cocoa and Objective-C. While it hadn't been updated in years and consequently seems to have disappeared down the memory hole, one of Apple's old Cocoa tutorials was something to the effect of "Build a Text Editor in 15 Minutes", where they showed how you could build a TextEdit-like rich text editor with Cocoa in a couple pages of code.
In fact, it's pretty easy figure out how to do this starting from the Xcode "document-based application" template, as there's not much more to it than replacing the label control in the document window with a Text View and implementing a couple methods in the document class to get and set its contents.
"Untrained in computers?" How many *nix admins do you know who either always run sudo from an absolute path, or who enforce "write xor execute" on all filesystems for any user accounts authorized to run with elevated privileges?
I won't generalize about IT departments, but many admins I've worked with certainly seem to be. For instance, I've frequently found Windows installations where Domain Admins is granted merely to allow a user to bounce a particular service, or to a service that needs write access to a few particular registry keys, because "that's the vendor-supported solution." Whether this vendor "support" extends to compensation for the cost of downtime caused by said overprivileged users accidentally installing untested "recommended" updates and rebooting a production server in the course of bouncing said service, or when a bug in the service causes it to recursively delete an unintentionally large portion of said registry, is left as an exercise.
More generally, I've found that admins seem overenthusiastic about learning about new features that vendors claim "increase security" or "reduce TCO", but are comparatively uninterested in creatively using existing features to the same ends, even when the former amounts to a monstrously complicated (i.e., because it must supportably generalize to thousands of diverse installations, not because vendors are stupid) configuration interface for the latter.
As for age, I'd say that, if anything, the problem is worse with younger admins who seem more inclined to take vendor claims at face value and assume that anything they might possibly need to know is a Google search or, at worst, a support request, away, otherwise the product is, as you say, "defective." Older admins seem to at least accept that any given component is but a part of a unique environment, and that they, not vendors, are responsible for ensuring the various parts interoperate correctly, even in an ostensibly "homogeneous" environment like a "Windows shop."
Sure, but
according to Webster's dictionary...
Not at all. From personal experience, it typically takes a non-backordered Apple product 2–3 business days from the origin in China to clear customs in Anchorage, then another day or so before it's ready to ship out of a FedEx Hub in, say, Indianapolis*. So you're realistically only adding about five days to the lead time, and surprisingly little cost (LOTS of iPhones to a pallet — Apple packaging isn't efficient for environmental reasons).
* As a bit of a special case, I live in Indianapolis, so I've actually had Apple products ordered on a Monday ship FedEx from China and deliver by Friday, with standard shipping (officially "5–7 day" shipping).
Sure, but even so, what if those who "excoriate execs and companies who move parts of their businesses offshore" are only a small minority? Also, so long as "components sourced abroad and assembled in a Saipan sweatshop" is "made in the USA," the mark isn't particularly informative (not that this is what Google is doing, but it does suggest some sort of additional marketing would actually be useful).
That actually sounds much better than the usual "puzzle-style" interview questions I hear. I'd personally begin by asking for high-level details. What applications do you have in mind? Alternatively, are you looking for a specific sort of boat? Without knowing the first thing about boats, there are obvious orders-of-magnitude design, process, and resource differences between building a kayak, say, and an oil tanker. Note here that I'd be careful to avoid detailed design or requirement questions: by my own admission, I don't know how to build boats, so the resulting "requirements discussion" would almost surely be "bike-shedding."
Next, given that there's (presumably) a well-established industry selling ____ boats, why are we assuming at the outset that we should build rather than buy? Suppose the answer is "we're not an end-user, our business plan involves breaking into boat manufacturing."
Fair enough. Then doing profitability requires both building and selling boats in a market with established players, and, by our (my) own admission, we (I) don't yet know how to build a boat, let alone do so well enough to make a manufacturable and marketable product (not to mention the highly nontrivial matters of actual marketing and manufacturing "at scale"). So unless we already have a crack boat-design team at our disposal (in which case, why are you asking me?) it might bewiser, at least for a few years, to get our feet wet by OEMing third-party boats, building something related but less ambitious like "boat accessories", etc., before committing to full-on "boat-building."
And so on. Presumably this is the sort of discussion they want to hear?
Maybe so, but how could a valid utility patent on a .NET library routine not extend to a functionally equivalent routine on Java or any other platform?
What could work, however, is an inexpensive "trusted media coprocessor" that takes DRM video and renders directly to the video hardware. Probably too wasteful of silicon on small mobile devices, but it could be reasonable on the desktop. Ideally, this would be subsidized by the media companies themselves, complete with open source reference drivers. Fine with me if they want to "own"the playback hardware, so long as they're willing to pay for it...
Why would they choose this over a Metro-style app?
Define "real" and "actual". Also, the Turing test isn't tied to Turing's particular theoretical model of computation, rather, it's intended to be as "cross-platform" as possible, for reasons including, but not limited to, the philosophical and linguistic quagmires involved in defining things like "intelligence" and "reality", by a simple "qualifying exam": phase one, in which we throw out all potential "artificial ducks" that can't even quack.
You don't need a credit card to download free stuff from the App Store.
And Xcode need not be installed from the App Store: installers for both Xcode and the standalone command-line tools packages are on developer.apple.com/downloads (registration required).
So Xcode will only run on Windows and Linux?
I suppose this would shut up the "it's bullshit that iOS development requires a Mac" crowd, at least.
Actually, it is. To wit, FTA,