If you have concrete ideas about how this could be improved, I might be inclined to agree with you.
Oh christ, there's all kinds of options. Here's two.
Get rid of the extra complexity (unneeded complexity is bad, OK) of multiple non-standardized metakeys that are not discoverable, and use contextual menus consistently and reliably, everywhere. The historical reasons for all the funky metakeys on Mac OS go back to the single-button mouse and the original antipathy towards contextual menus at Apple... with the resulting decision to use more and more special keys on the keyboard as "extra mouse buttons". We finally got contextual menus, but they're an afterthought in too many places. THEN if you want accelerators for contextual menus, add them, as an expert option.
That's one possibility. Another would be the one I already suggested, having the pouse pointer change (with, say, a little command or option ghosted next to it) when there's a metakey alternative available.
Again, not broken, just not your preference for what the desktop should represent.
And what it represented in pre Mac OS, and what the Dock represented in NeXTstep.
If you want to place aliases instead of actual files on your desktop, go ahead.
Huh?
If you want to use your desktop as an intermediate storage space for moving files, go ahead.
Huh?
I don't think you actually understand what I wrote. I didn't say anything about aliases and I've made the point EXPLICITLY that there IS NO INTERMEDIATE STORAGE involved.
The spatial Finder isn't coming back, applications aren't going to rely on creator codes in the resource fork, and the desktop is a folder.
I'm not expecting any of that to happen, but if they don't provide equivalent capabilities (and they haven't) that's a "bug", not a "preference".
The things you're complaining about aren't, quite frankly, issues, just preferences.
They're broken. You can't move a file from one folder to another without having both folders open. You used to be able to, by putting them on the desktop, but the desktop isn't the desktop any more, it's just a folder in your home directory, so putting stuff on the desktop makes an extra copy of it.
Automatically arranging desktop icons? You can do that, but that wrecks the spacial finder even more... and it's their AUTOMATIC placement of new icons that's broken in any case.
In the meantime, you can command-option-i
Ah, another magic secret option key sequence that you JUST HAVE TO KNOW.
Numerous actual performance and data problems have been fixed.
They've made it faster and less crashy, but they haven't done anything about the broken design, and they've broken the design in new ways.
No, I don't expect Apple to fix broken designs. I expect them to come up with some new passive-aggressive hack to let you do what you used to be able to do automatically.
I'm not talking about keyboard shortcuts that use an option key, I'm talking about keyboard shortcuts that do not appear in the menu, or where an option key changes their behavior in a way that doesn't correspond to any menu operation.
For example, in iTunes, the keyboard shortcut "delete" is not indicated in the menu as a shortcut for the delete operation key. It does, however, delete the currently selected item from a playlist, and option-delete deletes the currently selected item from your iTunes library.
There are other examples of these kinds of non-menu shortcut keys and modifiers, as well as buttons that change behavior when option- or command- clicked. One has to learn about these by googling. Which is why I thought that perhaps there might be some such magic combination in Finder for the capability I was missing.
99% of the really annoying stuff in Finder was indeed fixed in 10.5
What, in particular, are you thinking of?
The most annoying features of Finder for me, in Tiger, are:
* No plain file name search - search always goes through spotlight, which means it misses files that spotlight doesn't like and finds erroneous files when I'm looking for a file by name. Forgot that in my original list. Bummer. * Limited information about selected files and folders. "1 of 32 selected, 16 GB available" is nice, but I frequently want to know the total size of the selected files... more frequently than I want to know the free space on the drive. * No way to eliminate the sidebar without going to the silly pseudo-spacial view. * Icons pile up in the lower right corner of the desktop, even when there's plenty of room elsewhere.
Have they been fixed?
No?
What actually *has* been fixed in Finder in Leopard? Quick View is a new feature, not a fix, and the fact that it does an even worse job of tracking the current view of folders is definitely not a fix. So what am I missing?
Sometimes I am really amazed at how stupid and ignorant some Mac users can be.
I know what you mean. The ones who assume that every decision that Apple makes (even the ones they later back down on) are perfect, and call people who actually have experience with more than just Apple's software "dumbass" are the absolute worst.
Oh you mean like how you right click on a drive so you can eject it, and you have to wait for it to spin up before you can spin it down? "Wake up! Time for your sleeping pill!"
But unfortunately, the people developing Stacks apparently never heard of aliases and symbolic links. Yes, Stacks' list view doesn't resolve those, it just presents them as a clickable file.
Jesus, I use links in Tiger (and used them in Panther and Jaguar) for my "hot" applications dock item all the time.
Oh, great. "Stop complaining about Apple because Gnome's even worse"? Blow that for a joke... I don't expect Gnome to be worth using, but when I'm paying 40% more for a computer that's less capable than the cheaper one I would otherwise buy just to get an OS that doesn't suck... I think I have a reason to expect it to not suck.
I'll buy that. They should have maintained the Finder and NeXT File Manager as separate programs, instead of trying to merge two programs with such separate behaviors.
You could drag files onto the shelf, go to another folder, and drag them back off the shelf onto that folder, and it was just like you had dragged it from one folder directly to another. It's not a "temporary storage location" where files are moved to, it's a suspended file operation that is completed by taking the file back off the shelf and putting it somewhere. A suspended move of some kind is necessary, whether it's handled by the shelf or by cut-and-paste, and Finder doesn't have one.
As for rendering the space beside the dock useless... that depends on the application. Some applications simply refuse to let windows stay down there. Sometimes they pop right up, sometimes they pop up later on when you're not expecting it.
You mean break the entire application model that Mac OS has used since forever, which is that each window is not its own process?
That's an implementation detail. It's not something that users should see or care about. It's not even something that programmers should care about... there's nothing magical about processes. Many applications run multiple processes (not threads, processes) even for a *single* window... like Disk Utility. But, wot the hell, if Apple can magically fix multithreaded applications so a single thread can never hang the whole application (which is something that I've never seen done successfully, but maybe the reality distortion field can fix it) fine, but if they can't pull off a miracle they need to make Finder a special case. It's too central.
You could just not use FTP in the Finder.
That would be appropriate if it wasn't a security design flaw.
Have you ever actually used the Shelf from NeXTSTEP?
Yes, and I use XShelf in OS X to do its job on the Mac. It's not perfect, it's not super well integrated, but it does the job. Finder should really be doing it though.
Babbling about the purity of cut
I don't care if they come up with another mechanism (like, the shelf) to interrupt move operations, or violate Cut's precious bodily fluids, but they need to make it possible.
The shelf was there in previous versions of Mac OS X, but turned into the sidebar.
No, it wasn't. There was no place to drag a file to and then drag it back out of... you could drag things into the toolbar in Jaguar and earlier but you couldn't drag them back out to complete the move... you'd just remove it from the toolbar. Unless you mean it was there in Cheetah (the earliest version of OS X I used was Puma).
How, exactly, do you propose doing this?
I don't propose any mechanism, they have lots of smart people who are better at that kind of stuff, though things like changing the pointer come to mind.
Incidentally, most places where a right-click makes sense...
I'm not talking about right click. Right click is a (mostly) consistent operation that gets a context menu that you can safely ignore. I'm talking about all the special cases where you have to know that alt-click or command-click on a menu or button or object, or holding alt when using a keyboard shortcut, does something magically different, *and* that something is not always non-destructive so you can't really experiment.
Cut works perfectly well. It's only grayed out when it's not applicable.
You mean "it's only greyed out when APPLE thinks it's not applicable".
It should be possible to cut files and folders as well as text. If they're not going to allow cut, then they need to bring back the shelf so you can suspend a "move" operation that way instead.
* Restore the ability to have folders remember their views. * Run each Finder window in a separate process, so it doesn't lock everything up when one window gets busy. Particularly when hitting network shares. * Restore the pre OSX "staggered" icon layout option. * Give us an option to completely eliminate the sidebar without having to go back to "spacial" windows. * Move the "FTP" support from Finder to Safari, so we don't have the overhead and security issues of file-system-like operations when accessing remote high-latency servers. * Bring back the Shelf from NeXTSTeP. * Add "Cut" as well as "Copy". There's a "Cut" option in the edit menu but it's always greyed out. If there's some obscure option key that will enable this, well... * Make it OBVIOUS when there's an option/command click 'advanced' operation, instead of making us guess. And that goes for the rest of the software on the Mac.
False positives is one reason I haven't bought a copy of Windows since Windows 2000. I half expected that Microsoft would put their Vista-style disable code in XP, and the overhead and annoyance of the extra insecurity features in XP has made me glad I've stuck it out.
Just need to keep finding ways to bypass those unnecessary "we're not going to install on anything but XP" checks idiot hardware manufacturers put in their driver installers.
Theo has refused to implement other 'foreign' security changes in OpenBSD when they were first introduced, then turned around and implemented them after a while. He was contemptuous towards non-execute stacks when I spoke with him at Usenix many years ago, because he was convinced OpenBSD's code review policy made it irrelevant and because no-execute didn't stop all stack smashing attacks... but OpenBSD eventually picked it up.
Basically, he's very conservative, very resistant to change, and don't forget that's one of the things that made OpenBSD what it was to begin with... but if it really matters he'll come around.
Luke 3:13 - And he said unto them, extort no more than that which is appointed you.
Matthew 9:9-17 - As Jesus went on from there, he saw a man named Matthew sitting at the tax collector's booth. "Follow me," he told him, and Matthew got up and followed him.
While Jesus was having dinner at Matthew's house, many tax collectors and sinners came and ate with him and his disciples. When the Pharisees saw this, they asked his disciples, "Why does your teacher eat with tax collectors and sinners?"
On hearing this, Jesus said, "It is not the healthy who need a doctor, but the sick. But go and learn what this means: 'I desire mercy, not sacrifice.' For I have not come to call the righteous, but sinners."
The question is, what kind of data would you want to store in a file system where huge chunks of it are likely to be unavailable or just gone at any time?
I'm thinking, backups.
Let your desktops provide redundant backups of all your other desktops. Each night, the computers that are still up, would each make multiple copies of themselves on several of their neighbors... copies of everything but their backup directories and those system files that Microsoft makes it unreasonably hard to backup. A copy of the registry, a copy of the profiles, copies of installed programs, copies of all those files that make this system different from that one. Each would select systems that didn't have recent backup copies of themselves, and then at the end of the night they would prune the least useful backups... say, three redundant week-old backups of one of them, and a month-old backup of another... and report to the master control program what they had done.
Now if you lose your system, you bring up a standard install during the day, log in, and it will become your computer, find its most recent backup, copy itself back from its helpful neighbor and decrypt itself with your password, and by the time you get back from the morning staff meeting all will be well.
When I read "An OS should never have been something that people (in general) really care about: it should be completely invisible and nobody should give a flying [expletive] about it except the technical people" the message I get is "it's not what's under the hood that the user should have to care about". It doesn't matter whether OS X runs on top of Darwin or Linux or NT to most people. And really it doesn't. The net benefits to most people of all the things that NTFS does or that HFS does or that XFS does over and above "storing files" is just about zero. Spotlight doesn't need HFS, it doesn't need extended file attributes, it could have been implemented without any of that stuff. NTFS extended attributes are almost never used. ACLs, cylinder groups, superblocks, extents, catalogs, the user cares not about these things. They just want the file system to store their files and not lose them.
Same with everything else that the author is accusing Linus of focussing on at the expense of the stuff that the author things is important. It sounds to me like Linus is saying the same thing as he is, and he's just misunderstood it.
You seen to have missed the syntax of the DOCTYPE element.
What I may seem to have missed isn't the problem. The problem is that lots of other people, many of whom have written popular software programs or who have written XML document standards that *do* use URIs as identifiers, seem to have missed it.
Slashdot Mirror
If you have concrete ideas about how this could be improved, I might be inclined to agree with you.
Oh christ, there's all kinds of options. Here's two.
Get rid of the extra complexity (unneeded complexity is bad, OK) of multiple non-standardized metakeys that are not discoverable, and use contextual menus consistently and reliably, everywhere. The historical reasons for all the funky metakeys on Mac OS go back to the single-button mouse and the original antipathy towards contextual menus at Apple... with the resulting decision to use more and more special keys on the keyboard as "extra mouse buttons". We finally got contextual menus, but they're an afterthought in too many places. THEN if you want accelerators for contextual menus, add them, as an expert option.
That's one possibility. Another would be the one I already suggested, having the pouse pointer change (with, say, a little command or option ghosted next to it) when there's a metakey alternative available.
This isn't brain surgery.
Again, not broken, just not your preference for what the desktop should represent.
And what it represented in pre Mac OS, and what the Dock represented in NeXTstep.
If you want to place aliases instead of actual files on your desktop, go ahead.
Huh?
If you want to use your desktop as an intermediate storage space for moving files, go ahead.
Huh?
I don't think you actually understand what I wrote. I didn't say anything about aliases and I've made the point EXPLICITLY that there IS NO INTERMEDIATE STORAGE involved.
The spatial Finder isn't coming back, applications aren't going to rely on creator codes in the resource fork, and the desktop is a folder.
I'm not expecting any of that to happen, but if they don't provide equivalent capabilities (and they haven't) that's a "bug", not a "preference".
The information you're looking for, in iTunes, is under "Keyboard Shortcuts" in the "Help" menu.
If I wanted a computer that I have to go look up random shit in "help" all the time I can get that a lot cheaper from HP or Dell.
What the hell happened to Apple's "discoverable" user interface?
The things you're complaining about aren't, quite frankly, issues, just preferences.
They're broken. You can't move a file from one folder to another without having both folders open. You used to be able to, by putting them on the desktop, but the desktop isn't the desktop any more, it's just a folder in your home directory, so putting stuff on the desktop makes an extra copy of it.
Automatically arranging desktop icons? You can do that, but that wrecks the spacial finder even more... and it's their AUTOMATIC placement of new icons that's broken in any case.
In the meantime, you can command-option-i
Ah, another magic secret option key sequence that you JUST HAVE TO KNOW.
Numerous actual performance and data problems have been fixed.
They've made it faster and less crashy, but they haven't done anything about the broken design, and they've broken the design in new ways.
No, I don't expect Apple to fix broken designs. I expect them to come up with some new passive-aggressive hack to let you do what you used to be able to do automatically.
I'm not talking about keyboard shortcuts that use an option key, I'm talking about keyboard shortcuts that do not appear in the menu, or where an option key changes their behavior in a way that doesn't correspond to any menu operation.
For example, in iTunes, the keyboard shortcut "delete" is not indicated in the menu as a shortcut for the delete operation key. It does, however, delete the currently selected item from a playlist, and option-delete deletes the currently selected item from your iTunes library.
There are other examples of these kinds of non-menu shortcut keys and modifiers, as well as buttons that change behavior when option- or command- clicked. One has to learn about these by googling. Which is why I thought that perhaps there might be some such magic combination in Finder for the capability I was missing.
99% of the really annoying stuff in Finder was indeed fixed in 10.5
What, in particular, are you thinking of?
The most annoying features of Finder for me, in Tiger, are:
* No plain file name search - search always goes through spotlight, which means it misses files that spotlight doesn't like and finds erroneous files when I'm looking for a file by name. Forgot that in my original list. Bummer.
* Limited information about selected files and folders. "1 of 32 selected, 16 GB available" is nice, but I frequently want to know the total size of the selected files... more frequently than I want to know the free space on the drive.
* No way to eliminate the sidebar without going to the silly pseudo-spacial view.
* Icons pile up in the lower right corner of the desktop, even when there's plenty of room elsewhere.
Have they been fixed?
No?
What actually *has* been fixed in Finder in Leopard? Quick View is a new feature, not a fix, and the fact that it does an even worse job of tracking the current view of folders is definitely not a fix. So what am I missing?
That's how I use them, to point to directories containing the actual applications.
Brilliant.
Sometimes I am really amazed at how stupid and ignorant some Mac users can be.
I know what you mean. The ones who assume that every decision that Apple makes (even the ones they later back down on) are perfect, and call people who actually have experience with more than just Apple's software "dumbass" are the absolute worst.
(Your post was a parody, right? Right?)
Oh you mean like how you right click on a drive so you can eject it, and you have to wait for it to spin up before you can spin it down? "Wake up! Time for your sleeping pill!"
But unfortunately, the people developing Stacks apparently never heard of aliases and symbolic links. Yes, Stacks' list view doesn't resolve those, it just presents them as a clickable file.
Jesus, I use links in Tiger (and used them in Panther and Jaguar) for my "hot" applications dock item all the time.
Wunnerful.
Try using GNOME
Oh, great. "Stop complaining about Apple because Gnome's even worse"? Blow that for a joke... I don't expect Gnome to be worth using, but when I'm paying 40% more for a computer that's less capable than the cheaper one I would otherwise buy just to get an OS that doesn't suck... I think I have a reason to expect it to not suck.
I'll buy that. They should have maintained the Finder and NeXT File Manager as separate programs, instead of trying to merge two programs with such separate behaviors.
Either way the fake spatial windows are horrid.
I'm not sure what you mean by either of these.
You could drag files onto the shelf, go to another folder, and drag them back off the shelf onto that folder, and it was just like you had dragged it from one folder directly to another. It's not a "temporary storage location" where files are moved to, it's a suspended file operation that is completed by taking the file back off the shelf and putting it somewhere. A suspended move of some kind is necessary, whether it's handled by the shelf or by cut-and-paste, and Finder doesn't have one.
As for rendering the space beside the dock useless... that depends on the application. Some applications simply refuse to let windows stay down there. Sometimes they pop right up, sometimes they pop up later on when you're not expecting it.
You mean break the entire application model that Mac OS has used since forever, which is that each window is not its own process?
That's an implementation detail. It's not something that users should see or care about. It's not even something that programmers should care about... there's nothing magical about processes. Many applications run multiple processes (not threads, processes) even for a *single* window... like Disk Utility. But, wot the hell, if Apple can magically fix multithreaded applications so a single thread can never hang the whole application (which is something that I've never seen done successfully, but maybe the reality distortion field can fix it) fine, but if they can't pull off a miracle they need to make Finder a special case. It's too central.
You could just not use FTP in the Finder.
That would be appropriate if it wasn't a security design flaw.
Have you ever actually used the Shelf from NeXTSTEP?
Yes, and I use XShelf in OS X to do its job on the Mac. It's not perfect, it's not super well integrated, but it does the job. Finder should really be doing it though.
Babbling about the purity of cut
I don't care if they come up with another mechanism (like, the shelf) to interrupt move operations, or violate Cut's precious bodily fluids, but they need to make it possible.
ie: Steve's wrong. It happens. Get over it.
The shelf was there in previous versions of Mac OS X, but turned into the sidebar.
No, it wasn't. There was no place to drag a file to and then drag it back out of... you could drag things into the toolbar in Jaguar and earlier but you couldn't drag them back out to complete the move... you'd just remove it from the toolbar. Unless you mean it was there in Cheetah (the earliest version of OS X I used was Puma).
How, exactly, do you propose doing this?
I don't propose any mechanism, they have lots of smart people who are better at that kind of stuff, though things like changing the pointer come to mind.
Incidentally, most places where a right-click makes sense...
I'm not talking about right click. Right click is a (mostly) consistent operation that gets a context menu that you can safely ignore. I'm talking about all the special cases where you have to know that alt-click or command-click on a menu or button or object, or holding alt when using a keyboard shortcut, does something magically different, *and* that something is not always non-destructive so you can't really experiment.
Cut works perfectly well. It's only grayed out when it's not applicable.
You mean "it's only greyed out when APPLE thinks it's not applicable".
It should be possible to cut files and folders as well as text. If they're not going to allow cut, then they need to bring back the shelf so you can suspend a "move" operation that way instead.
* Restore the ability to have folders remember their views.
* Run each Finder window in a separate process, so it doesn't lock everything up when one window gets busy. Particularly when hitting network shares.
* Restore the pre OSX "staggered" icon layout option.
* Give us an option to completely eliminate the sidebar without having to go back to "spacial" windows.
* Move the "FTP" support from Finder to Safari, so we don't have the overhead and security issues of file-system-like operations when accessing remote high-latency servers.
* Bring back the Shelf from NeXTSTeP.
* Add "Cut" as well as "Copy". There's a "Cut" option in the edit menu but it's always greyed out. If there's some obscure option key that will enable this, well...
* Make it OBVIOUS when there's an option/command click 'advanced' operation, instead of making us guess. And that goes for the rest of the software on the Mac.
Yes, Microsoft really cares. If they didn't care, they'd stick with the honor-system security in Windows 2000 and earlier.
the customers would again be using forged copies, not even knowing that their local shop was screwing over people.
You say that like Microsoft isn't complicit in screwing people over by putting the drop-dead code in there in the first place.
False positives is one reason I haven't bought a copy of Windows since Windows 2000. I half expected that Microsoft would put their Vista-style disable code in XP, and the overhead and annoyance of the extra insecurity features in XP has made me glad I've stuck it out.
Just need to keep finding ways to bypass those unnecessary "we're not going to install on anything but XP" checks idiot hardware manufacturers put in their driver installers.
Theo has refused to implement other 'foreign' security changes in OpenBSD when they were first introduced, then turned around and implemented them after a while. He was contemptuous towards non-execute stacks when I spoke with him at Usenix many years ago, because he was convinced OpenBSD's code review policy made it irrelevant and because no-execute didn't stop all stack smashing attacks... but OpenBSD eventually picked it up.
Basically, he's very conservative, very resistant to change, and don't forget that's one of the things that made OpenBSD what it was to begin with... but if it really matters he'll come around.
Luke 3:13 - And he said unto them, extort no more than that which is appointed you.
Matthew 9:9-17 - As Jesus went on from there, he saw a man named Matthew sitting at the tax collector's booth. "Follow me," he told him, and Matthew got up and followed him.
While Jesus was having dinner at Matthew's house, many tax collectors and sinners came and ate with him and his disciples. When the Pharisees saw this, they asked his disciples, "Why does your teacher eat with tax collectors and sinners?"
On hearing this, Jesus said, "It is not the healthy who need a doctor, but the sick. But go and learn what this means: 'I desire mercy, not sacrifice.' For I have not come to call the righteous, but sinners."
The question is, what kind of data would you want to store in a file system where huge chunks of it are likely to be unavailable or just gone at any time?
I'm thinking, backups.
Let your desktops provide redundant backups of all your other desktops. Each night, the computers that are still up, would each make multiple copies of themselves on several of their neighbors... copies of everything but their backup directories and those system files that Microsoft makes it unreasonably hard to backup. A copy of the registry, a copy of the profiles, copies of installed programs, copies of all those files that make this system different from that one. Each would select systems that didn't have recent backup copies of themselves, and then at the end of the night they would prune the least useful backups... say, three redundant week-old backups of one of them, and a month-old backup of another... and report to the master control program what they had done.
Now if you lose your system, you bring up a standard install during the day, log in, and it will become your computer, find its most recent backup, copy itself back from its helpful neighbor and decrypt itself with your password, and by the time you get back from the morning staff meeting all will be well.
I donate this idea to the public domain.
Now, if only there was some filesystem whose performance didn't degrade over time due to fragmentation...
You mean, just about all of them?
When I read "An OS should never have been something that people (in general) really care about: it should be completely invisible and nobody should give a flying [expletive] about it except the technical people" the message I get is "it's not what's under the hood that the user should have to care about". It doesn't matter whether OS X runs on top of Darwin or Linux or NT to most people. And really it doesn't. The net benefits to most people of all the things that NTFS does or that HFS does or that XFS does over and above "storing files" is just about zero. Spotlight doesn't need HFS, it doesn't need extended file attributes, it could have been implemented without any of that stuff. NTFS extended attributes are almost never used. ACLs, cylinder groups, superblocks, extents, catalogs, the user cares not about these things. They just want the file system to store their files and not lose them.
Same with everything else that the author is accusing Linus of focussing on at the expense of the stuff that the author things is important. It sounds to me like Linus is saying the same thing as he is, and he's just misunderstood it.
You seen to have missed the syntax of the DOCTYPE element.
What I may seem to have missed isn't the problem. The problem is that lots of other people, many of whom have written popular software programs or who have written XML document standards that *do* use URIs as identifiers, seem to have missed it.