It is not likely that Apple's iOS is even in the running for security. It's obscurity that keeps it out of the minds of most. A billion PCs is a much bigger target, by far.
200 million iOS devices. 100 million Android devices.
But what's the reason to change? Like you said, people want Macs. What will Apple gain by gimping the Mac like is being suggested?
Apple will only stop selling proper PCs when people stop wanting them (or, as Apple sometimes does, just right before people stop wanting them). We are still far from that day. You can tell because people are crying "the sky is falling!" over the idea. When the time is right, these Chicken Little stories won't be looked at with fear, but welcomed, with a chorus of "yes, we *want* the sky to fall!"
Apple's Mac is highly profitable, highly successful, and in greater demand then ever. They've only ever once axed a product like that, and all they did was replace the hard drive with a flash drive. If they "iPod nano" the Mac, it will be in dropping hard drives and optical drives for SSDs. We are still a *long* way away from the day Apple will ax or neuter the Mac.
He got modded insightful because he's one of those "Windows cultists" that you haven't come across. They are legion, which is why it can be hard to recognize them. But they basically make sweeping claims about non-PC users which make no sense.
- Apple will kill the Mac - Mac users are stupid cultists who will buy anything Apple/Steve Jobs sells - Apple is EVIL - One button mouse - Steve Jobs is a control freak - Macs will have loads of viruses real soon, better get AV software now - ur playing this game on a MAC? buy a real computer, n00b
Are a few of the Apple-related phrases by which you can recognize them. Also, when they call someone like me a 'fanboy' for not holding the above opinions, it's a dead giveaway.
Neither can I. So the 0.1% that need it could go buy a "professional" Mac that comes with OS X and Xcode (and probably costs $1500+), and the rest would get an iOS laptop.
Why do nerds always seem to think people only buy what they "need"? People buy what they *want*.
Who "needs" an iPad? So far, 25 million people have bought them. Most, I suspect, *wanted* them, but didn't *need* them. Apple sells things that people want, not things that people need.
Right now, people *want* Macs. They want them more than ever. Why would Apple decide, "well, you don't *need* a Mac, so we'll just sell you this iOS device, since that's all you need. And for the few that specifically need a Mac, we'll keep a few around for them"?
Exactly. PC people observing Apple say the darndest things.
For Apple to lock down Mac OS X like iOS, they would have to have come to one conclusion first: that it would make the Mac a better product.
No one has yet been able to explain how that's the case. In fact, these stories and posts tend to be based on the exact opposite conclusion. They are based on the fear that it would destroy the Mac!
With a Mac-only XCode Apple locked in their developers into its ecosystem and is getting a nice fee from every single one (the margin on the sale of a Mac).
Oh, come on. Xcode has *always* been Mac OS X only. And since iOS is an OS X variant, it makes perfect sense for it to use Xcode. While I'm sure Apple isn't unhappy about being able to sell a Mac to some iOS programmers, it's not like this is a deliberate "lock in" of some sort.
Actually removing that lock in would be a wise move to expand further the developers base but IMHO it would be a very un-Applish one.
To what extent? Do you really think there is some untapped pool of developers of any notable size out there that won't/can't develop for iOS simply because it requires Xcode, and that requires a Mac?
Apple is having no trouble attracting developers. It's not like buying a Mac is some strange thing for a person to do. Apple has no reason to put in the effort to port Xcode to Windows (or provide some alternate form of SDK on Windows).
Sure, so can Java and.NET, and there are plenty of serialization options for C++.
However, not every random object can be serialized (how do you serialize an open socket, for example?). And, of course, just because an application uses Cocoa, it doesn't mean that its own state is completely stored in Objective-C objects. Even if it's written in Objective-C entirely, it can also have arrays and other data structures (esp. if it uses some third-party libraries written in plain C) that the runtime will not be aware unless told.
So this still doesn't enable automatic serialization of any random app.
I did mention that you can opt out, and also that if your app does certain things, it can't be suspended/resumed.
As for things that can't be automatically serialized, this can be often be solved by sending a message to the app that it's about to suspend, and having it prepare for or self-manage serialization. There usually aren't too many rough edges you have to address to get something like this to work.
So then, not really that much different. With Windows facility that I had referenced earlier, the only difference is that you'll have to create your own backing store for serialization (a file in AppData\Local would do nicely), and to indicate that resume is required by means of command line. That all is fairly trivial boilerplate. It's good that the OS can take care of that for you, but it's certainly not critical.
I'm going to suggest that it is. We will see, however. But if third party apps take up this feature, that speaks a lot to whether it matters if the OS provides much better support for this or not.
This illustrates one of the notable differences between Apple and the rest of the industry. To make a quick analogy, most of the industry runs a bunch a cable along the roads, then tells homeowners that they can run their own line out to the curb if they want to connect to the network. Apple runs those wires, then offers to send someone out to run it into your house.
I like how you present this as though it's a perfectly acceptable way to implement a feature like this.
What's not acceptable about it? It's a fairly common way of exposing a virtual FS on Windows.
It might be a fairly common way for Windows to work, but I doubt it's fairly common for users to actually use that feature. Imagine, for example, that Time Machine worked exactly like it does now, but files were only exposed by paths and filenames like that? That would instantly make Time Machine 90% less useful, even though it would still have the exact same functionality.
The end user doesn't really observe those paths (if you browse them in Explorer, they do show up like "C:\ (June 6, 2011 16:00)". They are there to enable back-compat with applications which were written long before this feature was even thought of - in my opinion, a good thing to have.
Whereas Time Machine was able to maintain backwards compatibility without exposing such an arcane interface to the user.
I actually suspect OS X does something similar with Time Machine, since wouldn't it require some kind of a file path to hand over to the app handling this document type to open it from. It being Unix, I'd expect to some system directory serving as a mount point for "Time Machine FS".
Or is there rather some different API involved which directly transmits the raw document data to the app? If so, then I think I still prefer the paths, since, aside from back-compat, they also let you work with file versions directly from command line, treating them as readonly files with funky names.
However it's implemented, the user will never see those paths and filenames. It's *sort of* like how IE deals with downloads that you "Open" instead of "Save". The file is some random file in %TEMP%, but the user just sees t
So long as the app can serialize its state and deserialize it, it would seem to me that some form of notification from the OS when it needs to do either is all that is needed. If it can't, then I don't see how the OS can do this short of effectively doing suspend-to-disk - but everyone is emphatically saying that this feature is totally different from suspend...
Cocoa can serialize/deserialize objects. It's been built into it since before it was even called Cocoa.
I didn't look deep into Lion's implementation of this, so perhaps I'm missing something. If you can provide some links describing the technical implementation of this feature from app developer perspective, it would be quite helpful.
I suspect it's all under NDA, but it's just an implementation of the generic way iOS "multitasks" apps (in the background, they are frozen, then killed if the OS needs the memory. When you re-enter the program it either unfreezes (if it's still frozen) or reloads its frozen state so that the end effect is identical, except for the difference in load time caused by having to re-read the saved state from storage instead of RAM. Lion does the same/similar thing, including not necessarily closing an app when you quit it.).
If you have a free developer account, you should be able to look up how that works. I don't have a link handy though. On iOS, at least, there are some things you have to keep in mind about your app, specifically that if it does certain things, suspend/resume won't work and it will instead just quit and reopen like normal, and you can explicitly opt-out of suspend/resume.
You can open old versions directly without restoring using Vista/7 file versioning as well - the dialog has an "Open" button. On low level, they are actually exposed as SMB-shared from localhost with a special path under \C$ (the usual system-wide share) - e.g. a versioned view of C:\ on my PC right now would be "\\localhost\C$\@GMT-2011.06.04-04.54.00\". So any app that can work with SMB paths (which is any app that uses stock API functions to manage them - most do, even some very old apps) will automatically work with versions.
I like how you present this as though it's a perfectly acceptable way to implement a feature like this. But, point taken.
It doesn't let you display content side-by-side though, if I understand your description of this feature in Lion correctly. Though surely it would also require app support for the particular document type, to permit such embedding?
I don't quite follow. This requires an app to be able to open a file the app just autosaved? Yes, that's true, but also implied by the app having just autosaved it (and prior to that, created or opened it).
That sounds like diff/merge functionality. Again, surely this would require an app registered for a given filetype supporting such a thing? E.g. if I have Office:Mac, then it wouldn't let me "restore a single paragraph" in a DOCX file, would it?
I suspect I'm missing something here. The app only needs to know how to open the file and *possibly* tell the system it wants to use autosave. Mac OS X takes care of the rest. It's a part of the system that also makes Time Machine happen, so I expect it just happens without the developer doing anything except *maybe* having to recompile against the 10.7 SDK.
When you enter Versions, it shows you your currently open document window, and next to it, another fully active document window with the version you are presently looking at (and you can scroll around backwards and forwards in time, and it will change which version is in the second windows).
It's exactly as though you had a second, temporary document window open in which you could flip through older versions of a document and interact with them, and choose to replace your current document with an older one, or just grab things from it and when you're done, close it.
Umm... You bought a Mac there buddy, not a computer. You have issues you are supposed to pay Apple their tithe to get it fixed, not fix it yourself.
What, exactly, are you talking about?
I am not trying to be trollish,
Well, that convinced me...
but iPhones, iPads, iPods are not supposed to be user serviceable items. Maybe this is just another step Apple is taking to movetheir computer business to a similar revenue stream model?
*WHAT* revenue stream model? Apple sells you hardware. That's their revenue stream. It's already the same for iPods and Mac Pros.
Look at the MacBook Airs for example, i don't believe anything about them is supposed to be user serviceable. I am not sure about the standard MacBooks, I don't own one..
Memory and hard drives are user-servicable. They aren't on the MacBook Air because that's how they were able to make it into a MacBook Air. Hatches and latches take up space, and you can't replace the hard drive or memory because it doesn't have a hard drive (nor even a regular SSD), and the memory is soldered on so that it will take up less space.
Like how they were the last company to make a PC, then the last company to make a GUI/WIMP PC, then the last company to make an MP3 player (well, that's one), then they were the last to make a touchscreen smartphone, then they were the last to make a tablet that isn't just a gimped PC...
They certainly aren't "always last". They are often first to do something in a major way, and often not. The only thing you can really say about this is that no matter when they do it, they are almost always the first to get it "right" (from the point of view of the consumer). Where that actually happens in the timeline of everything else is variable, although Apple does try to be earlier rather than later.
But I think what you say about Lion is incorrect. "Mac OS X Lion's new Resume feature lets users get back to where they left off after a shutdown or restart"
And based on how Apple's previous features have played out, I suspect they'll probably push all the hard work of actually implementing this onto the application developers...
Examples?
Apple tends to make these things so easy to use that the developer either has to do nothing except recompile to get these features, or at the very least just access/implement a few methods to tell the system how the app wants to work.
What you are describing is more generally true of Windows and Linux, etc.
So far as I know, both Gnome and KDE on Linux also have something similar - again, subject to app support.
This isn't simply "restarting an app with some arguments". It's actually reloading the exact same objects in the exact same states as you had running when you quit the app.
journaling function?
I'm not sure what, precisely, you mean by this; but in Windows 7 you can right-click on a file and choose "Restore previous versions" from the context menu. This is configurable in Control Panel -> System -> System Protection, and is turned on by default for the system drive. I can't say for sure where this feature has appeared first; if I remember correctly, there was something like that even in XP, but buried very deep in advanced settings.
The big problem with those is that people who are supposed to know about them in order to use them (in the first case, developers; in the second, users) usually don't. The tech is there, but it was never properly marketed.
Yeah, I'm pretty sure he was referring to Versions. But the way Lion implements them is *way* beyond anything else out there. You don't just restore to a previous version of a file (although you can), but when you enter the interface, the app you are in actually opens the previous versions live, right there, and you can interact directly with them. So you can search through for some specific version (instead of just going by a timestamp) and can even interact with an older version, allowing you to just restore a single paragraph, if that's all you want.
Application resuming/restarting has been around since Vista and the OS has several hooks for registering for these events and messages. The fact that no-one implements it isn't relevant.
Actually, it's very relevant. A feature that no one uses is inferior to a feature that gains wide usage. Resume will be quickly supported by just about every Cocoa app for which it makes sense.
After all, if this is all based on "I've had that for years", you'd assume that means actually having it implemented, and not just *potentially* implemented, but actually not.
It will be the same in Lion. Unless the apps are rewritten to support these features they won't work. It doesn't just happen magically.
These aren't "hooks" like you are thinking. There will be APIs to modify how it works on your app if it does something where Resume wouldn't be a good fit, but any standard Cocoa app compiled against Lion will get Resume for free.
Resume isn't what many here seem to think it is. It serializes all the objects of an app and saves them to disk. When you "restart" the app, it doesn't actually reinitialize the app like normal, it just reloads all the objects (and, I'd assume, provide optional methods for the app to do something on resume if it wants to).
My guess is that a large amount of music is fingerprinted either by the labels or identifiable because there are probably not that many unique rips of music out there, so most copies can be identified as downloaded. I would definitely read a EULA before letting apple scan your music.
Apple is *NOT* going to tattle on you for pirated music. Almost everyone has at least one "pirated" song. If this system did tattle, it would instantly become a pariah.
Apple will never do *anything* that would make people afraid that if they use iTunes, they might get sued.
The way I've interpreted that at least so far is "give us $25, and for the next year, everything you rip we'll give you an iTunes copy of too"... You may be right though, it may be "give us $25 a year to keep the music you've ripped synced up on the cloud"
It's the latter, but since your computer acts just like any other device, you can sync back down the 256k AAC file, making it possible to use it as the former as well.
And iTunes Match? Does anyone else find it baffling how they are getting away with this? I mean, for $25 I get legal versions of every single—ahem, questionably procured, shall we say— tracks in my gigantic iTunes library? Did the record companies read the fine print on this?
This means they get and additional $24.99/year (well, presumably minus 30%) from past "piracy", and possibly future piracy going forward.
So, basically they are getting *some* money from an activity that until now nets them no money. This also brings more non-customers going through the iTunes Music Store, which increases the odds of them simply becoming proper customers.
Or looked differently, all else remaining equal, this brings more money to the music industry than not doing it would have. This is especially notable to them given how Amazon and Google decided to just go ahead and implement a system that generates *no* money for that industry.
iCloud lets you upload the songs that aren't iTunes purchases. And the ones you get for $24.99 are the exact same DRM-free, 256k AAC files you get when you buy them in iTunes. They do not expire. The only thing that expires is your ability to download them again without first uploading them. You also don't have to transcode them or anything.
You are the most dishonest person I have ever encountered on Slashdot, and that's saying a *LOT*. You constantly deny ever saying the things you say, you deny the context of the threads you are in. You act as though you have one of those short-term memory diseases where you can't remember what happened just 5 seconds ago.
I truly can't believe anyone is as stupid as your posts portray you as, so I can only conclude you are a deliberate troll.
Sorry, just have to chime in here. Uhhh...you DO know that Apple is bringing the app store to OSX via lion, yes?
Wow, really? I never heard of such a thing!
I've been using it in Snow Leopard. I think it's fairly safe to assume I'm well aware of many of the new features in Lion.
So frankly any arguments of iOS VS OSX are about to be made moot anyway. Apple WILL lock down OSX, just as they have iOS, Apple WILL control the whole smash, again just as with iOS, and Apple fanboys WILL declare that locking them into a walled garden is the greatest thing since sliced bread and we're all haters who just "don't get Steve's vision".
You are full of shit.
So frankly you can make all the flaming logic hoops you want friend, OSX in 2 years will be nothing but iOS in a different package.
So any discussions today are limited to the lunatic ravings about the way it *might* be in the future?
If that day ever comes (and it won't), only THEN will it be relevant.
The only thing that worries me is seeing screencaps of Win 8 it looks like if someone doesn't fire Ballmer but quick Windows will be nothing but a WinPhone in a different case.
I will give you credit for at least being consistent in your lunacy.
In BOTH cases the future goal is pretty clear, a machine which you have about as much control over as your average ATM. You push the button, that's it. Frankly I'd say the only ones who'd benefit would be the Linux guys, but my guess is the way congress whores itself out for garbage like the PROTECT IP laws in all likelihood by 2015 all the devices will have Fritz chips in them and Linux won't run on anything but highly expensive dev boards and little ARM crap chips.
There will *NEVER* come a day where you won't be able to run Linux on off the shelf hardware. NEVER, NEVER, NEVER.
You have gone quite mad over the course of the past year.
the "locked down, walled garden" that it is, is SIGNIFICANTLY more free for most people than something like Android or Linux in general. What good is the small bit of additional "freedom" to people who can't benefit from it?
What you are talking about isn't freedom but possibilities and a completely different matter. For beginners an idiot-proof user interface is the most important thing, for advanced users it is freedom. This is nicely reflected in iOS/Android sales.
Freedom *is* possibilities. They are certainly not completely different matters. And you're mistaken about the difference being between beginners and advanced. The difference is in how the user *can* (beginner vs advanced) or *wants* (which makes no differentiation between beginner or advanced) to interact with the device.
The idea that iPhones are for beginners, and Android is for advanced users is silly. And it's unclear what you mean by this being reflected in sales. In fact, it's not just unclear, but makes no sense. Do you think most Android users are "advanced"?
Not wanting to fuck around with your device doesn't make you a "beginner". Wanting simplicity, reliability, and quality does not make you a "beginner".
I wonder what the opening line to your post that I was replying to was. I bet it was about Mac OS X.
Your right, OSX not running on open hardware (as in non-Apple hardware). Nothing about software (like I pointed out to you.)
Mac OS X *IS* software! Mac hardware can run any OS you want! The reverse isn't true. It's not that Macs can ONLY run Mac OS X (they can run Windows and Linux just fine), it's that Mac OS X *WON'T* run on non-Macs!
The limitation you were referencing was a limitation with Mac OS X, not Apple hardware!
What makes you think that saying you can't run Mac OS X on non-Apple hardware is not saying anything about software?
But its not a red herring. I've been talking about open hardware, and you've turned it into open software which had nothing to do with anything I had been talking about. I was showing you how your comments would have been valid with that example.
You mentioned software *MULTIPLE* times before I ever replied to you!
Like I asked in another reply to you, do you even READ the threads you participate in? The post of yours I was replying to mentioned Mac OS X, Darwin, and WebKit (and I even let your *huge* incorrect statement that "Apple merely bought them out" slide--see what I mean about you being wrong enough as it is?).
Aww.... again you read only what you want. I pointed out that Darwin and Webkit were bought buy Apple,
Apple didn't buy WebKit. They forked it from KHTML. And you also left out Bonjour (in the post you were replying to) where Apple started that in house as 100% open source. They also made QuickTime Streaming Server open source, as well as many other Apple-initiated open source projects.
I didn't say anything about open source, you did.
That wasn't me, you asshat. One of your replies to someone else was about open source projects. That is saying something about open source software. I have to ask again, do you even read what you write?
Here, let me quote my exact words from my post "As for Darwin and Webkit, those were made by other people, Apple just bought them out." Hmmm.... no, no, nope. Nothing about open source there...
Except for Darwin and WebKit, that is!
just pointing out that its not made by Apple (being its hard to offer them as your own when in reality you bought someone elses work out).
There are two huge flaws in your argument:
1. Apple didn't have to buy the projects that they did buy (or fork those that they forked). If they wanted to be proprietary, they could have just used in house solutions, or bought proprietary solutions. 2. Apple has created open source projects that they didn't have to make open source, and they have kept projects as open source that they didn't have to.
*sits down* This fun, I'm starting to enjoy pointing out your faults in every message and how you've twisted what I say. Please, do some more.
How would you ever know if someone is "twisting what [you] say" when you don't even seem to know what you've said in the first place?!
Slashdot Mirror
It is not likely that Apple's iOS is even in the running for security. It's obscurity that keeps it out of the minds of most. A billion PCs is a much bigger target, by far.
200 million iOS devices.
100 million Android devices.
One of these has malware, the other does not.
But what's the reason to change? Like you said, people want Macs. What will Apple gain by gimping the Mac like is being suggested?
Apple will only stop selling proper PCs when people stop wanting them (or, as Apple sometimes does, just right before people stop wanting them). We are still far from that day. You can tell because people are crying "the sky is falling!" over the idea. When the time is right, these Chicken Little stories won't be looked at with fear, but welcomed, with a chorus of "yes, we *want* the sky to fall!"
Apple's Mac is highly profitable, highly successful, and in greater demand then ever. They've only ever once axed a product like that, and all they did was replace the hard drive with a flash drive. If they "iPod nano" the Mac, it will be in dropping hard drives and optical drives for SSDs. We are still a *long* way away from the day Apple will ax or neuter the Mac.
He got modded insightful because he's one of those "Windows cultists" that you haven't come across. They are legion, which is why it can be hard to recognize them. But they basically make sweeping claims about non-PC users which make no sense.
- Apple will kill the Mac
- Mac users are stupid cultists who will buy anything Apple/Steve Jobs sells
- Apple is EVIL
- One button mouse
- Steve Jobs is a control freak
- Macs will have loads of viruses real soon, better get AV software now
- ur playing this game on a MAC? buy a real computer, n00b
Are a few of the Apple-related phrases by which you can recognize them. Also, when they call someone like me a 'fanboy' for not holding the above opinions, it's a dead giveaway.
Neither can I. So the 0.1% that need it could go buy a "professional" Mac that comes with OS X and Xcode (and probably costs $1500+), and the rest would get an iOS laptop.
Why do nerds always seem to think people only buy what they "need"? People buy what they *want*.
Who "needs" an iPad? So far, 25 million people have bought them. Most, I suspect, *wanted* them, but didn't *need* them. Apple sells things that people want, not things that people need.
Right now, people *want* Macs. They want them more than ever. Why would Apple decide, "well, you don't *need* a Mac, so we'll just sell you this iOS device, since that's all you need. And for the few that specifically need a Mac, we'll keep a few around for them"?
Exactly. PC people observing Apple say the darndest things.
For Apple to lock down Mac OS X like iOS, they would have to have come to one conclusion first: that it would make the Mac a better product.
No one has yet been able to explain how that's the case. In fact, these stories and posts tend to be based on the exact opposite conclusion. They are based on the fear that it would destroy the Mac!
With a Mac-only XCode Apple locked in their developers into its ecosystem and is getting a nice fee from every single one (the margin on the sale of a Mac).
Oh, come on. Xcode has *always* been Mac OS X only. And since iOS is an OS X variant, it makes perfect sense for it to use Xcode. While I'm sure Apple isn't unhappy about being able to sell a Mac to some iOS programmers, it's not like this is a deliberate "lock in" of some sort.
Actually removing that lock in would be a wise move to expand further the developers base but IMHO it would be a very un-Applish one.
To what extent? Do you really think there is some untapped pool of developers of any notable size out there that won't/can't develop for iOS simply because it requires Xcode, and that requires a Mac?
Apple is having no trouble attracting developers. It's not like buying a Mac is some strange thing for a person to do. Apple has no reason to put in the effort to port Xcode to Windows (or provide some alternate form of SDK on Windows).
Sure, so can Java and .NET, and there are plenty of serialization options for C++.
However, not every random object can be serialized (how do you serialize an open socket, for example?). And, of course, just because an application uses Cocoa, it doesn't mean that its own state is completely stored in Objective-C objects. Even if it's written in Objective-C entirely, it can also have arrays and other data structures (esp. if it uses some third-party libraries written in plain C) that the runtime will not be aware unless told.
So this still doesn't enable automatic serialization of any random app.
I did mention that you can opt out, and also that if your app does certain things, it can't be suspended/resumed.
As for things that can't be automatically serialized, this can be often be solved by sending a message to the app that it's about to suspend, and having it prepare for or self-manage serialization. There usually aren't too many rough edges you have to address to get something like this to work.
So then, not really that much different. With Windows facility that I had referenced earlier, the only difference is that you'll have to create your own backing store for serialization (a file in AppData\Local would do nicely), and to indicate that resume is required by means of command line. That all is fairly trivial boilerplate. It's good that the OS can take care of that for you, but it's certainly not critical.
I'm going to suggest that it is. We will see, however. But if third party apps take up this feature, that speaks a lot to whether it matters if the OS provides much better support for this or not.
This illustrates one of the notable differences between Apple and the rest of the industry. To make a quick analogy, most of the industry runs a bunch a cable along the roads, then tells homeowners that they can run their own line out to the curb if they want to connect to the network. Apple runs those wires, then offers to send someone out to run it into your house.
I like how you present this as though it's a perfectly acceptable way to implement a feature like this.
What's not acceptable about it? It's a fairly common way of exposing a virtual FS on Windows.
It might be a fairly common way for Windows to work, but I doubt it's fairly common for users to actually use that feature. Imagine, for example, that Time Machine worked exactly like it does now, but files were only exposed by paths and filenames like that? That would instantly make Time Machine 90% less useful, even though it would still have the exact same functionality.
The end user doesn't really observe those paths (if you browse them in Explorer, they do show up like "C:\ (June 6, 2011 16:00)". They are there to enable back-compat with applications which were written long before this feature was even thought of - in my opinion, a good thing to have.
Whereas Time Machine was able to maintain backwards compatibility without exposing such an arcane interface to the user.
I actually suspect OS X does something similar with Time Machine, since wouldn't it require some kind of a file path to hand over to the app handling this document type to open it from. It being Unix, I'd expect to some system directory serving as a mount point for "Time Machine FS".
Or is there rather some different API involved which directly transmits the raw document data to the app? If so, then I think I still prefer the paths, since, aside from back-compat, they also let you work with file versions directly from command line, treating them as readonly files with funky names.
However it's implemented, the user will never see those paths and filenames. It's *sort of* like how IE deals with downloads that you "Open" instead of "Save". The file is some random file in %TEMP%, but the user just sees t
So long as the app can serialize its state and deserialize it, it would seem to me that some form of notification from the OS when it needs to do either is all that is needed. If it can't, then I don't see how the OS can do this short of effectively doing suspend-to-disk - but everyone is emphatically saying that this feature is totally different from suspend...
Cocoa can serialize/deserialize objects. It's been built into it since before it was even called Cocoa.
I didn't look deep into Lion's implementation of this, so perhaps I'm missing something. If you can provide some links describing the technical implementation of this feature from app developer perspective, it would be quite helpful.
I suspect it's all under NDA, but it's just an implementation of the generic way iOS "multitasks" apps (in the background, they are frozen, then killed if the OS needs the memory. When you re-enter the program it either unfreezes (if it's still frozen) or reloads its frozen state so that the end effect is identical, except for the difference in load time caused by having to re-read the saved state from storage instead of RAM. Lion does the same/similar thing, including not necessarily closing an app when you quit it.).
If you have a free developer account, you should be able to look up how that works. I don't have a link handy though. On iOS, at least, there are some things you have to keep in mind about your app, specifically that if it does certain things, suspend/resume won't work and it will instead just quit and reopen like normal, and you can explicitly opt-out of suspend/resume.
You can open old versions directly without restoring using Vista/7 file versioning as well - the dialog has an "Open" button. On low level, they are actually exposed as SMB-shared from localhost with a special path under \C$ (the usual system-wide share) - e.g. a versioned view of C:\ on my PC right now would be "\\localhost\C$\@GMT-2011.06.04-04.54.00\". So any app that can work with SMB paths (which is any app that uses stock API functions to manage them - most do, even some very old apps) will automatically work with versions.
I like how you present this as though it's a perfectly acceptable way to implement a feature like this. But, point taken.
It doesn't let you display content side-by-side though, if I understand your description of this feature in Lion correctly. Though surely it would also require app support for the particular document type, to permit such embedding?
I don't quite follow. This requires an app to be able to open a file the app just autosaved? Yes, that's true, but also implied by the app having just autosaved it (and prior to that, created or opened it).
That sounds like diff/merge functionality. Again, surely this would require an app registered for a given filetype supporting such a thing? E.g. if I have Office:Mac, then it wouldn't let me "restore a single paragraph" in a DOCX file, would it?
I suspect I'm missing something here. The app only needs to know how to open the file and *possibly* tell the system it wants to use autosave. Mac OS X takes care of the rest. It's a part of the system that also makes Time Machine happen, so I expect it just happens without the developer doing anything except *maybe* having to recompile against the 10.7 SDK.
When you enter Versions, it shows you your currently open document window, and next to it, another fully active document window with the version you are presently looking at (and you can scroll around backwards and forwards in time, and it will change which version is in the second windows).
It's exactly as though you had a second, temporary document window open in which you could flip through older versions of a document and interact with them, and choose to replace your current document with an older one, or just grab things from it and when you're done, close it.
Umm... You bought a Mac there buddy, not a computer. You have issues you are supposed to pay Apple their tithe to get it fixed, not fix it yourself.
What, exactly, are you talking about?
I am not trying to be trollish,
Well, that convinced me...
but iPhones, iPads, iPods are not supposed to be user serviceable items. Maybe this is just another step Apple is taking to movetheir computer business to a similar revenue stream model?
*WHAT* revenue stream model? Apple sells you hardware. That's their revenue stream. It's already the same for iPods and Mac Pros.
Look at the MacBook Airs for example, i don't believe anything about them is supposed to be user serviceable. I am not sure about the standard MacBooks, I don't own one..
Memory and hard drives are user-servicable. They aren't on the MacBook Air because that's how they were able to make it into a MacBook Air. Hatches and latches take up space, and you can't replace the hard drive or memory because it doesn't have a hard drive (nor even a regular SSD), and the memory is soldered on so that it will take up less space.
Like how they were the last company to make a PC, then the last company to make a GUI/WIMP PC, then the last company to make an MP3 player (well, that's one), then they were the last to make a touchscreen smartphone, then they were the last to make a tablet that isn't just a gimped PC...
They certainly aren't "always last". They are often first to do something in a major way, and often not. The only thing you can really say about this is that no matter when they do it, they are almost always the first to get it "right" (from the point of view of the consumer). Where that actually happens in the timeline of everything else is variable, although Apple does try to be earlier rather than later.
It is VHS vs Betamax all over again.. where Apple is the latter.
Except in an alternate universe where Betamax actually wins.
But I think what you say about Lion is incorrect. "Mac OS X Lion's new Resume feature lets users get back to where they left off after a shutdown or restart"
And based on how Apple's previous features have played out, I suspect they'll probably push all the hard work of actually implementing this onto the application developers...
Examples?
Apple tends to make these things so easy to use that the developer either has to do nothing except recompile to get these features, or at the very least just access/implement a few methods to tell the system how the app wants to work.
What you are describing is more generally true of Windows and Linux, etc.
Which operating system out there now has a system-wide, OS-level resume
Windows since Vista. As with Lion, this boils down to apps supporting it.
So far as I know, both Gnome and KDE on Linux also have something similar - again, subject to app support.
This isn't simply "restarting an app with some arguments". It's actually reloading the exact same objects in the exact same states as you had running when you quit the app.
journaling function?
I'm not sure what, precisely, you mean by this; but in Windows 7 you can right-click on a file and choose "Restore previous versions" from the context menu. This is configurable in Control Panel -> System -> System Protection, and is turned on by default for the system drive. I can't say for sure where this feature has appeared first; if I remember correctly, there was something like that even in XP, but buried very deep in advanced settings.
The big problem with those is that people who are supposed to know about them in order to use them (in the first case, developers; in the second, users) usually don't. The tech is there, but it was never properly marketed.
Yeah, I'm pretty sure he was referring to Versions. But the way Lion implements them is *way* beyond anything else out there. You don't just restore to a previous version of a file (although you can), but when you enter the interface, the app you are in actually opens the previous versions live, right there, and you can interact directly with them. So you can search through for some specific version (instead of just going by a timestamp) and can even interact with an older version, allowing you to just restore a single paragraph, if that's all you want.
Application resuming/restarting has been around since Vista and the OS has several hooks for registering for these events and messages. The fact that no-one implements it isn't relevant.
Actually, it's very relevant. A feature that no one uses is inferior to a feature that gains wide usage. Resume will be quickly supported by just about every Cocoa app for which it makes sense.
After all, if this is all based on "I've had that for years", you'd assume that means actually having it implemented, and not just *potentially* implemented, but actually not.
It will be the same in Lion. Unless the apps are rewritten to support these features they won't work. It doesn't just happen magically.
These aren't "hooks" like you are thinking. There will be APIs to modify how it works on your app if it does something where Resume wouldn't be a good fit, but any standard Cocoa app compiled against Lion will get Resume for free.
Resume isn't what many here seem to think it is. It serializes all the objects of an app and saves them to disk. When you "restart" the app, it doesn't actually reinitialize the app like normal, it just reloads all the objects (and, I'd assume, provide optional methods for the app to do something on resume if it wants to).
Why would they use Linux? They've more traditionally used Sun, Oracle, and IBM systems.
Why would "most geeks" set this up themselves, when they can get it for $24.99 and not have to do anything?
Sure, many will (and really, already have), but there are *many* more who would rather have it just work. For $24.99/year, it's a bargain.
My guess is that a large amount of music is fingerprinted either by the labels or identifiable because there are probably not that many unique rips of music out there, so most copies can be identified as downloaded. I would definitely read a EULA before letting apple scan your music.
Apple is *NOT* going to tattle on you for pirated music. Almost everyone has at least one "pirated" song. If this system did tattle, it would instantly become a pariah.
Apple will never do *anything* that would make people afraid that if they use iTunes, they might get sued.
The way I've interpreted that at least so far is "give us $25, and for the next year, everything you rip we'll give you an iTunes copy of too"... You may be right though, it may be "give us $25 a year to keep the music you've ripped synced up on the cloud"
It's the latter, but since your computer acts just like any other device, you can sync back down the 256k AAC file, making it possible to use it as the former as well.
And iTunes Match? Does anyone else find it baffling how they are getting away with this? I mean, for $25 I get legal versions of every single—ahem, questionably procured, shall we say— tracks in my gigantic iTunes library? Did the record companies read the fine print on this?
This means they get and additional $24.99/year (well, presumably minus 30%) from past "piracy", and possibly future piracy going forward.
So, basically they are getting *some* money from an activity that until now nets them no money. This also brings more non-customers going through the iTunes Music Store, which increases the odds of them simply becoming proper customers.
Or looked differently, all else remaining equal, this brings more money to the music industry than not doing it would have. This is especially notable to them given how Amazon and Google decided to just go ahead and implement a system that generates *no* money for that industry.
iCloud lets you upload the songs that aren't iTunes purchases. And the ones you get for $24.99 are the exact same DRM-free, 256k AAC files you get when you buy them in iTunes. They do not expire. The only thing that expires is your ability to download them again without first uploading them. You also don't have to transcode them or anything.
You are the most dishonest person I have ever encountered on Slashdot, and that's saying a *LOT*. You constantly deny ever saying the things you say, you deny the context of the threads you are in. You act as though you have one of those short-term memory diseases where you can't remember what happened just 5 seconds ago.
I truly can't believe anyone is as stupid as your posts portray you as, so I can only conclude you are a deliberate troll.
We're done here.
Sorry, just have to chime in here. Uhhh...you DO know that Apple is bringing the app store to OSX via lion, yes?
Wow, really? I never heard of such a thing!
I've been using it in Snow Leopard. I think it's fairly safe to assume I'm well aware of many of the new features in Lion.
So frankly any arguments of iOS VS OSX are about to be made moot anyway. Apple WILL lock down OSX, just as they have iOS, Apple WILL control the whole smash, again just as with iOS, and Apple fanboys WILL declare that locking them into a walled garden is the greatest thing since sliced bread and we're all haters who just "don't get Steve's vision".
You are full of shit.
So frankly you can make all the flaming logic hoops you want friend, OSX in 2 years will be nothing but iOS in a different package.
So any discussions today are limited to the lunatic ravings about the way it *might* be in the future?
If that day ever comes (and it won't), only THEN will it be relevant.
The only thing that worries me is seeing screencaps of Win 8 it looks like if someone doesn't fire Ballmer but quick Windows will be nothing but a WinPhone in a different case.
I will give you credit for at least being consistent in your lunacy.
In BOTH cases the future goal is pretty clear, a machine which you have about as much control over as your average ATM. You push the button, that's it. Frankly I'd say the only ones who'd benefit would be the Linux guys, but my guess is the way congress whores itself out for garbage like the PROTECT IP laws in all likelihood by 2015 all the devices will have Fritz chips in them and Linux won't run on anything but highly expensive dev boards and little ARM crap chips.
There will *NEVER* come a day where you won't be able to run Linux on off the shelf hardware. NEVER, NEVER, NEVER.
You have gone quite mad over the course of the past year.
Possibility is freedom.
Unusuable options are not freedom. Freedom isn't some imaginary thing, it does you no good to have a freedom you can't use.
the "locked down, walled garden" that it is, is SIGNIFICANTLY more free for most people than something like Android or Linux in general. What good is the small bit of additional "freedom" to people who can't benefit from it?
What you are talking about isn't freedom but possibilities and a completely different matter. For beginners an idiot-proof user interface is the most important thing, for advanced users it is freedom. This is nicely reflected in iOS/Android sales.
Freedom *is* possibilities. They are certainly not completely different matters. And you're mistaken about the difference being between beginners and advanced. The difference is in how the user *can* (beginner vs advanced) or *wants* (which makes no differentiation between beginner or advanced) to interact with the device.
The idea that iPhones are for beginners, and Android is for advanced users is silly. And it's unclear what you mean by this being reflected in sales. In fact, it's not just unclear, but makes no sense. Do you think most Android users are "advanced"?
Not wanting to fuck around with your device doesn't make you a "beginner". Wanting simplicity, reliability, and quality does not make you a "beginner".
I wonder what the opening line to your post that I was replying to was. I bet it was about Mac OS X.
Your right, OSX not running on open hardware (as in non-Apple hardware). Nothing about software (like I pointed out to you.)
Mac OS X *IS* software! Mac hardware can run any OS you want! The reverse isn't true. It's not that Macs can ONLY run Mac OS X (they can run Windows and Linux just fine), it's that Mac OS X *WON'T* run on non-Macs!
The limitation you were referencing was a limitation with Mac OS X, not Apple hardware!
What makes you think that saying you can't run Mac OS X on non-Apple hardware is not saying anything about software?
But its not a red herring. I've been talking about open hardware, and you've turned it into open software which had nothing to do with anything I had been talking about. I was showing you how your comments would have been valid with that example.
You mentioned software *MULTIPLE* times before I ever replied to you!
Like I asked in another reply to you, do you even READ the threads you participate in? The post of yours I was replying to mentioned Mac OS X, Darwin, and WebKit (and I even let your *huge* incorrect statement that "Apple merely bought them out" slide--see what I mean about you being wrong enough as it is?).
Aww.... again you read only what you want. I pointed out that Darwin and Webkit were bought buy Apple,
Apple didn't buy WebKit. They forked it from KHTML. And you also left out Bonjour (in the post you were replying to) where Apple started that in house as 100% open source. They also made QuickTime Streaming Server open source, as well as many other Apple-initiated open source projects.
I didn't say anything about open source, you did.
That wasn't me, you asshat. One of your replies to someone else was about open source projects. That is saying something about open source software. I have to ask again, do you even read what you write?
Here, let me quote my exact words from my post "As for Darwin and Webkit, those were made by other people, Apple just bought them out." Hmmm.... no, no, nope. Nothing about open source there...
Except for Darwin and WebKit, that is!
just pointing out that its not made by Apple (being its hard to offer them as your own when in reality you bought someone elses work out).
There are two huge flaws in your argument:
1. Apple didn't have to buy the projects that they did buy (or fork those that they forked). If they wanted to be proprietary, they could have just used in house solutions, or bought proprietary solutions.
2. Apple has created open source projects that they didn't have to make open source, and they have kept projects as open source that they didn't have to.
*sits down* This fun, I'm starting to enjoy pointing out your faults in every message and how you've twisted what I say. Please, do some more.
How would you ever know if someone is "twisting what [you] say" when you don't even seem to know what you've said in the first place?!