Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
a few questions.. do you think they will show more with lion on tuesday? or will it be a mainly ipad event? also possibility of an updated iwork?
 
to be honest, I see my self never using launch pad, as we already sorta have that through stacks, and I don't even use the freaking stacks I've got setup, I spotlight everything, I know exactly what I'm looking for and just type it in. I don't par-ooze my applications folder looking for something to use...

Also why'd they choose to make quick look white??

Can't wait to see all the new auto-correct fails that come about with Lion...
 
Now what I really like to hear is versions... would be very nice,as I sometimes make changes, have to revert back to the original, and then back to the new (for the time when people can't make up their minds). Sounds a lot better than having multiple copies save in your system; under different names. My only concern would be how many versions are kept and for how long. May not need to save old documents, but then again - may be an issue with disk space

Now that is asking the right questions!
I also would like to know on what intervals will the file be saved?
how much of all this is configurable?
 
But they aren't running.

I'm talking about this, more specifically (from the front-page story):

"Application persistance. Apps and their states are saved when you logout and back in. Background apps may be terminated by Mac OS X and will restore if the user picks them again. Basically the concept of open and closed apps is gone."
Emphasis mine.

That sounds well and good in theory, but...

1. If the saved-state behavior is as inconsistent as it (still) is on iOS (i.e. devs have to write it into apps), things may be messy for quite a while.
2. What criteria will the system use to kill apps? What if I want some apps to continue to update in the background (like an IM app)? Will Apple allow some processes to run in the background?
3. The saved-state approach was designed for mobile systems with limited resources (compared to a desktop or laptop). It's a compromise between full-fledged multitasking and the previous iOS versions that only allowed you to run one app at a time. It makes sense on a mobile device, but on a PC? I'm not sold yet.
4. Keep in mind that the PC (and I use that term to include all laptops/desktops) will become, in Steve Jobs's eyes, like trucks. They'll become power user tools. They'll continue to exist in a smartphone/tablet world because some of us will still want the flexibility and power that a desktop OS gives us, compared to the mobile OSes out there. The ability to manually control the state of what apps are and aren't running is part of this.

Now, obviously, those of us who aren't developers don't yet know for sure how it's all going to work. But as of right now, I have lots of concerns about Lion from a user-interaction perspective.

EDIT:
For the very small number people who should care whether an App is suspended or not, you'll either be able to truly quit it via Activity Monitor, or perhaps we'll see some sort of pseudo-taskbar ala the iPhone, although I doubt it.
Right, but my point is a little different. I'm not worried about killing suspended apps; I'm worried about the fact that they're being suspended in the first place.
 
You say that as if XML is a good thing... The backend to store the "registry" in doesn't matter. The concept of a registry (central corruptible, deletable) in itself is flawed.

Well, if you go from .config to just a bunch of .*rc files, that won't save you. Your home directory then becomes such a registry. Or /etc. Or /Library/Preferences. Or C:\Users\KnightWRX\Local Settings, you name it. You are just shifting the scope.

As I've pointed earlier, being careful and making (and verifying!) backups is the only thing to prevent corruption and deletion in the first case. If you suspect you might be fat-fingered when typing rm . * (oh noes!), simple hardlinks in a safe place with a cron or launchd jobs is what's going to save you.

Besides, the "registry" Unix-wise is multiple files and not just one, which means you are not going to run into locking issues, file size creep and index corruption (filesystems are still better at hierarchical content than any single file). Think .somesoftwarerc files, but in unified format.

For things included in Gnome. libgtk/libgnome apps are all over the place UI wise (not that QT/kdelibs apps are any better). The stuff included in the KDE main packages is pretty decent as far as interface goes.
Well, as of GNOME 2.30, the only ugly thing out there is Firefox. Oh, it's not exactly GNOME application.

If I were ranking apps by their UI "unifiedness", I would place them like that:

Mac (Cocoa apps only)
GNOME and HIG-compliant applications
Command-line Unix
KDE
Windows applications (with their tendency to bring their own eyecandy and interface concepts with them, MS Office being the most prominent example at all times).

You're forgetting K3B (the best burning software. Period) and Amarok (iTunes can go cry in a corner).

Well, I haven't used an optical drive in the last two years, no surprise I forget things. ;) As for Amarok, I guess you are the bells-and-whistles appreciating person, but would you mind if my opinion is slightly different. The only thing apart from iTunes which I'd like ever to use is MOC (http://moc.daper.net/), now in Macports BTW.

As for other notable players out there, my opinion is:
iTunes is what Amarok should be in the first place (MySQL? Are you kidding me? SQLite or BerkeleyDB FTW!);
iTunes is what Banshee and Rhythmbox want to be but fail miserably at.
(Your mileage may vary :)) But still I hope...
 
But they aren't running. They're either suspended, or open.

For the very small number people who should care whether an App is suspended or not, you'll either be able to truly quit it via Activity Monitor, or perhaps we'll see some sort of pseudo-taskbar ala the iPhone, although I doubt it.

There was nothing wrong with Command-Q.
 
Airdrop=Dropbox=cool. Will it support iOS devices too?

Little concerned about "instantly wiping" my mac...mistakes do happen, including w/ Apple.

Not sure I get what Lion server is - different than Mac OS server?

Says the server will support iOS devices so guess Airdrop should work with your i-pads, pods, phones.

BUT... Airdrop is NOT equal to Dropbox. My dropbox lets me share files with my crummy PC's at work and vice-versa. Doesn't sound like Airdrop will.
 
2. What criteria will the system use to kill apps? What if I want some apps to continue to update in the background (like an IM app)? Will Apple allow some processes to run in the background?

My easy guess is: an app in idle event loop with no open files, no open network/Unix domain sockets (neither listening nor connecting), and with no windows open and not minimized, is a perfect candidate.

Concerning that last one about listening sockets. It's already implemented since Tiger: on-demand server startup. launchd happens to know what port an application is going to listen to, from the .plist file, and listens on behalf of the application. When a connection is made on that port, launchd starts the application and hands the socket over to it.

The thing is, launchd then won't stop the server when there are no more connections. Maybe this issue will be addressed, too, and launchd will be able to count idle and restartable server processes, too as candidates for termination.
 
I'm talking about this, more specifically (from the front-page story):


Emphasis mine.

That sounds well and good in theory, but...

1. If the saved-state behavior is as inconsistent as it (still) is on iOS (i.e. devs have to write it into apps), things may be messy for quite a while.

This is true, apps will require an update.

2. What criteria will the system use to kill apps? What if I want some apps to continue to update in the background (like an IM app)? Will Apple allow some processes to run in the background?

Of course processes will be able to run in the background. Full-fledged multitasking isn't going anywhere. I imagine it will suspend apps if there are no tasks or network activity going on (so if you set your IM status to "offline)," and move to a different app, it will suspend) and kill them as it does in OS, depending on memory available.

3. The saved-state approach was designed for mobile systems with limited resources (compared to a desktop or laptop). It's a compromise between full-fledged multitasking and the previous iOS versions that only allowed you to run one app at a time. It makes sense on a mobile device, but on a PC? I'm not sold yet.

The benefit, beyond the fact it is one less thing the user has to worry about, is that frequently used apps (ones that the OS keeps suspended) will load faster and will resume where you left off.

The ability to manually control the state of what apps are and aren't running is part of this.

With what apple is doing here, manually controlling it becomes irrelevant because the OS handles it all. As I said before, the power users will be able to kill an app right away via Activity Monitor if they really need to(and perhaps a GUI). But for 99% of the population, it's unnecessary.
 
There was nothing wrong with Command-Q.

+1000000

Lion might be the last step before we slide down a slippery slope of dumbification of the platform.

I really hope cmd+q stays. The "you can just open Activity Monitor, find the process and quit it" argument is a load of ****.

Suspended apps in Lion, is fine. They save state and quit completely, then when reopened, pop back up as they were, like Firefox saving tabs, but I don't want resources being sapped all the time because "it's so user friendly to just leave everything running".
 
My easy guess is: an app in idle event loop with no open files, no open network/Unix domain sockets (neither listening nor connecting), and with no windows open and not minimized, is a perfect candidate.

Concerning that last one about listening sockets. It's already implemented since Tiger: on-demand server startup. launchd happens to know what port an application is going to listen to, from the .plist file, and listens on behalf of the application. When a connection is made on that port, launchd starts the application and hands the socket over to it.

The thing is, launchd then won't stop the server when there are no more connections. Maybe this issue will be addressed, too, and launchd will be able to count idle and restartable server processes, too as candidates for termination.

I would think it may be something much simpler. It will only kill apps that support suspend and resume. An IM would not support suspend, since it stays active in the background, so it would not be eligible to be killed. It's up to the developer.
 
I am not a fan of the "conversational" email style at all.

I really wonder if this is the first OS update I am going to ignore? :confused:
 
+1000000

Lion might be the last step before we slide down a slippery slope of dumbification of the platform.

I really hope cmd+q stays. The "you can just open Activity Monitor, find the process and quit it" argument is a load of ****.

Suspended apps in Lion, is fine. They save state and quit completely, then when reopened, pop back up as they were, like Firefox saving tabs, but I don't want resources being sapped all the time because "it's so user friendly to just leave everything running".

That's what a lot of people have been saying. It's the new users from the iDevice fad that are all excited about "Lion", when it appears much of it is "dumbed down" and based from iOS.
 
I would think it may be something much simpler. It will only kill apps that support suspend and resume. An IM would not support suspend, since it stays active in the background, so it would not be eligible to be killed. It's up to the developer.

Meanwhile, a word processor probably doesn't need to eat up CPU cycles? That makes sense; I hope that's how it'll play out.
 
That's what a lot of people have been saying. It's the new users from the iDevice fad that are all excited about "Lion", when it appears much of it is "dumbed down" and based from iOS.

I think a lot of it is trying to solve problems that never existed. Making the Mac more like the user-end of iOS will make the Mac very casual and very consumeristic.

Meanwhile, Versions is a good idea, especially when working on a document faster than Time Machine can keep up. Airdrop also looks good.
 
Suspended apps in Lion, is fine. They save state and quit completely, then when reopened, pop back up as they were, like Firefox saving tabs, but I don't want resources being sapped all the time because "it's so user friendly to just leave everything running".

Resources aren't being sapped, apps become suspended, which you say is fine. Not sure what you're complaining about.

Think of the Normal Users who never Command-Q apps (yes, these people exist) and only close windows, then wonder why their computer has slowed to a crawl.

For everybody else, we will enjoy much faster app loading times and saved states. Honestly, to me this is the most exciting thing about Lion.
 
TLDR: its retarded if you cannot arbitrarily close running apps.
its retarded if they turn a desktop OS into a mobile OS.

do you not think things as basic as controlling whats executing and whats not is important?

Thts exactly what I thought when they implemented it in to the portable iDevices, but if they can include a close app option to that, don't you think it'll come to the OS X too? :rolleyes:
 
I would think it may be something much simpler. It will only kill apps that support suspend and resume. An IM would not support suspend, since it stays active in the background, so it would not be eligible to be killed. It's up to the developer.

Yep. But given a bunch of suspendable apps, and a need to free up some memory, how would you judge which one to kill?

Of course, there will be a bunch of events an app will need to be able to handle. While from the user viewpoint everything is transparent, I think some apps will need to distinguish the call to save and quit from the OS recource manager and from the user.

Consider, for example, some word processor which has an unsaved document. When I quit it, I might want either save the document as it is, or scrap everything up to the point of my last explicit save. This is what I'm used to, and adding extra need to muck around with Versions just because they are there and the word processor saves all my <verbal excrements> without asking me first, is a plain bad move.

Then imagine this workflow:
1. User edits a document.
2. User saves the document at some point.
3. User continues to edit the document, adding some stuff and taking stuff out.
4. User gets distracted by, say, some pr0n pictures, or a video call from his girlfriend, or both.
5. Soon he opens more apps unrelated to his word processing and the OS decides to ditch the word processor, as it is idle with no benefit.
6. After a while, the user copies his document onto a removable media with no notion of versions (say, a flash disk formatted with FAT).

Question: in what state should the document be on is removable media? As if at the time of the last save, or after the (presumably unsaved) edits?

So, I see the right behavior along the lines: when I quit the word processor explicitly, I want to be asked if I want to save my current version or throw it away.

When OS quits the word processor for freeing resources, it obviously won't ask me anything, but I want my document file to be as of the last explicit save, and its current state saved somewhere else.

When I copy the file somewhere, or open it with another program, I want it to be in the last explicitly saved state. It will be the most consistent state.

When I open the word processor back, and I haven't edited the file with anything else, I want it to open in the last state I left it in that word processor (as if it was never closed in the first place).

By the way, all this is not rocket science, so anyone could make such an application even now. I just think OSX will provide APIs so that there will be no need to implement transactions on files and backing store for uncommitted transactions by hand.
 
The vitriol over closed/suspended apps is ludicrous, and teaming with ignorant paranoia.

The feature on OS X is an outgrowth of iOS. The system works perfectly on iOS. As I mentioned in a previous post, iOS does not support swapping. If an app requests memory that the system can't allocate, then the app crashes. iOS is not plagued by constant app crashes when many apps are suspended. That's because the system is seamlessly jettisoning suspended apps as needed.

There's confusion on what it means when apps are suspended. On iOS, there are different states. There's "not running" (not taking up memory, not using compute cycles). The you have "active" which are actually running in the manner everyone is used to. It's taking up memory, visible, and consuming and least some amount of CPU cycles. Then there is "backgrounded"; a backgrounded app is not visible, in the background, but still executing code. This state most often happens before transitioning to a suspended state, although the app can request additional system time. And last we have "suspended". Suspended apps are what Apple refers to as "freeze-dried". They occupy memory, but are completely inactive and consuming zero CPU cycles. (There is another state called "Inactive" that I don't believe is applicable to OS X).

The system will automatically close suspended apps, should memory pressure pass a certain threshold. This happens with no performance impact and is completely transparent. The feature is a caching mechanism as well as a multitasking mechanism. Caching mechanisms are designed to free the cached memory automatically.

Concerns about breaking apps that wouldn't play nice in such a system are not applicable. The feature requires developers to specifically support it. They have to be compiled against the APIs with the feature. Applications that are not compiled against the new APIs with said features will function as they do now and will not be impacted. They will be closed as per usual, but remain in memory in a purely "cached" state, without any of the multitasking abilities. Should you relaunch the app, it will launch from a cold start, but from the cache for a quicker launch. Should the system need the memory, it will simply jettison the non-running, cached app to free up memory.

Since the feature will required a recompile and deliberate choice to participate in this form of app switch, such apps will not exhibit issues as they are DESIGNED to be suspended and resumed in the first place.

Lastly, you WILL be able to completely close apps if you wish. You can do it in iOS and it's completely asinine to suggest that the capability would be removed from OS X. The mechanism may or may not be different than what it currently is (i.e. CMD-Q may become a suspend feature for participating apps with a different shortcut to completely close the app). Haven't got my hands on it yet, so I can't say if the mechanism changed. It is equally asinine to state that you don't want the system managing memory for you. Hello? McFly? That's what it already does. You do understand the role of the kernel in respect to virtual memory, do you not?

This is one of the more ridiculous cases of Chicken Little-ism I've seen in a while. Although I think the great pentalobe screw conspiracy tops it.

EDIT: To clarify, the system will not jettison apps that are active or backgrounded (i.e. apps that are using CPU cycles). Only apps that not designed for the feature and are in a non running cached state, or apps that support the feature and are in a suspended (non-running, but resumable) state. It's not going to just go shutting down your apps willy-nilly. Only cases where it is safe to do so.
 
Last edited:
Resources aren't being sapped, apps become suspended, which you say is fine. Not sure what you're complaining about.

I mean if I can manually quit and have it reopen as I had it, that would be good. As long as there's a manual option there, I don't need to wait for a timeout, nor would I run into the problem of cmd+tabbing to Mail, then going back to Safari only to have to wait for it to resume (ie. I'd leave it completely running).

Basically, it would have to be pretty clever just to reach the same efficiency I use, let alone beat it.
 
Thts exactly what I thought when they implemented it in to the portable iDevices, but if they can include a close app option to that, don't you think it'll come to the OS X too? :rolleyes:

I am wondering this too. On the one hand, I can see them adding a "recent apps" taskbar that comes up and looks exactly like the iOS version, complete with the red X. On the other, I could see them rationalizing that memory management/battery life isn't as a problem on OS X, so it's not needed. And for the rare instances, there's activity monitor. It'll be interesting to see how it works.

I mean if I can manually quit and have it reopen as I had it, that would be good. As long as there's a manual option there, I don't need to wait for a timeout, nor would I run into the problem of cmd+tabbing to Mail, then going back to Safari only to have to wait for it to resume (ie. I'd leave it completely running).
.

If you're command-tabbing, then Safari would still be running. There would be no "waiting" for it to resume.
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.