> When I think of using virtual consoles I think of using something akin > to MS's terminal server, might be a misunderstanding on my part.
Oh, that's remote display serving, completely different. Also good, but unrelated. > Being able to log in twice as the same user does not shout any obvious > advantages at me, but that might just be that they are advantages but > not obvious in my use. The point is that if you were working from scratch starting with Mac OS X and its unix base, the FreeBSD virtual consoles would be an obvious thing to implement, it'd even be a Macish thing... remember the original Multifinder? I'd never run any restriction to "one session per user" except in the Microsoft world. That's why I see that as copying Microsoft. Which is the point I'm getting at... not that it's a big problem or a little problem, but that it's a very Microsoft style approach to the thing. > > PDF will sometime have its faults too, as we agree nothing is > invulnerable, so its best to plan well. We also both hope Apple is > doing so but its unclear until its implemented longer. The FTP with the > Finder thing, eh, the Finder sucks for FTP and FTP is not a secure > protocol. Also FTP use of the Finder is very limited. I think we will > see this change a lot in the future. I sure as hell hope so. That stuff should STAY in the browser. > The whole point of services and core resources is to share the ability > of one application with others so that you do not have to double up on > functionality everywhere you want it, you can just tap what already > exists. Right, but you do that by implementing components that do one thing, so you have a "html display" component and a "web access" component, and applications that use both... and you get a system that is inherently safe: if there's a bridge between the two it's because an application put it there... putting them both in one component is inherently dangerous, applications have to choose to be safe. > Most users do not download a file that comes in compressed in an > archive to store it, they do so to use it immediately. That's true, and then when they need to reinstall it they don't have it. What Apple really needs is a "zipfile manager". That could be handled with folder actions as well, and it'd just work for ALL your zipfiles... not just the ones you download, but the ones you get on your MacWorld CD as well. > Folder actions is an excellent example of depth of a product. However, > most users do not get to the point where they know what a folder action > is let alone how to use it. Most aren't even familiar with the name. They don't need to be. Safari would set it up for them if they clicked "yes" on that first prompt. > I disagree with the problem not having some grounding in the OS knowing > between a file and an application. What is the difference? I'm not really sure myself. :)/2. > Blanket solutions generally suck. Indeed, that's why I'm arguing for safe design that *allows* a careful user to remain safe, rather than one that forces you to depend on the OS vendor not leaving any holes. -- Unsupported OS X is sponsored by <http://lowendmac.com/> Support Low End Mac <http://lowendmac.com/lists/support.html> Unsupported OS X list info <http://lowendmac.com/lists/unsupported.html> --> AOL users, remove "mailto:"; Send list messages to: <mailto:[EMAIL PROTECTED]> To unsubscribe, email: <mailto:[EMAIL PROTECTED]> For digest mode, email: <mailto:[EMAIL PROTECTED]> Subscription questions: <mailto:[EMAIL PROTECTED]> Archive <http://www.mail-archive.com/unsupportedosx%40mail.maclaunch.com/> Using a Mac? Free email & more at Applelinks! http://www.applelinks.com
