those pining away over the loss of labels, mourn no more. for a measly $7 you can buy a copy of Labels X, the latest haxie from unsanity and get all your lost functionality back.
<strong>those pining away over the loss of labels, mourn no more. for a measly $7 you can buy a copy of Labels X, the latest haxie from unsanity and get all your lost functionality back.</strong><hr></blockquote>
What's all the fuzz about here. It's an added feature and a *very* important one for people with crusial data on their computers, it's turned off by default, you have to activate it yourself and it does NOT slow down the UI except you're extreemly low in phisical memory
I haven't upgraded to 10.2 yet. I have G3 700 iMac and have switched to OS X. I haven't really had GUI issues or OS issues. It's been other people's software (Graphic Converter vanishes after a few minutes and Photoshop 7's Image Browser is slooow as a dog...even with their recent update).
Just seems to be business as usual with Apple... <img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" /> </strong><hr></blockquote>
Yeah, damn them for providing new useful features and using a kick-butt chip. We demand less!
To repeat the obvious again: journaling hits the *drive access* with a 10-15% slowdown, *NOT* the entire system. The performance hit to the average user is going to be about nil. Under certain circumstances, yes, you'll likely notice, but those should be fairly rare. And, you can turn it off. And, it is off by default.
And, *do you people have any idea how freakin' amazing it is for them to offer a journaling **plug-in** for an *existing* filesystem?!?* Good LORD that is cool. I fully expected them to come out with UberFS that required a full reformat and reinstall. THIS is nothing short of a technical coup, and shows off the raw power of the VFS in Darwin.
Kickaha, well said. Now that I know Apple hasn't been ignoring user requests (Spring Loaded Folders today, JFS tomorrow, Labels on the horizon) I'm fairly impressed with how OS X is coming together. It's a mirror of the current hardware situation: short-term we and Apple have to suck in, but long-term is looking better than ever. The future's bright, so be :cool:
<strong>So since filenames and filetypes were both in BeFS, that means *those* are related? Cool, I think we just found the justification for filename extensions. [No]
Proximity does not imply conceptual relationship.</strong><hr></blockquote>
Proximity is also a relationship, especially when you hire a BeFS guy. It's likely that he knows the advantages that advanced metadata can bring (and has some experience with it).
[quote]<strong>I wonder why this assumption keeps getting made in the face of a lack of evidence to support it.
Just because you're not privy to Apple's inner circle doesn't mean that it isn't a high priority. Read the signs and portents in various UI elements (particularly in the dev tools) to see nascent forays into *rich* metadata handling.</strong><hr></blockquote>
The lack of evidence is exactly what's worrying me. Could you expand on the signs and portents that you see?
<strong>The lack of evidence is exactly what's worrying me. Could you expand on the signs and portents that you see?</strong><hr></blockquote>
Project Builder 2.0 has an interface exposing MIME-like file typing functionality. Remember Be and MIME? I believe Kickaha's showed us a screenshot at least once before.. very cool.
Don't forget iTunes 3 "live playlists". With that you're getting very close to data soup--just dump everything into a folder and let the OS sort things anyway that you want depending on parameter and context.
well just to comment on the performance hit critics...
I don't care that OS X runs a bit slow on the UI, I'm just incredibly grateful that crashing word doesn't ruin a whole days work in photoshop and that I can a lot of things at once without having to wait every time i print, open something or set a filter running.
I find this more than makes up for the time spent waiting for folders to open etc...
It's a trade off and I like the result, if anything I'm more productive as a power user in X, even when I'm Xing on my Wallstreet...totally off topic sorry but i'm in a rantin' mood
well just to comment on the performance hit critics...
I don't care that OS X runs a bit slow on the UI, I just incredibly grateful that crashing word doesn't ruin a whole days work in photoshop and that I can a lot of things at once without having to wait every time i print, open something or set a filter running.
I find this more than ,akes up for the time spent waiting for folders to open etc...
It's a trade off and I like the result, if anything I'm more productive as a power user in X, even when I'm Xing on my Wallstreet...totally off topic sorry but i'm in a rantin' mood
<strong>Don't forget iTunes 3 "live playlists". With that you're getting very close to data soup--just dump everything into a folder and let the OS sort things anyway that you want depending on parameter and context.</strong><hr></blockquote>
And iPhoto's keywords.
Heck, think about Address Book's group tags for a moment, and you'll realize it's the same thing as well.
The iApps are moving to keyword/tag based lookup in a serious way. The dev tools are moving towards handling files based on hierarchical datatypes... that are *not* currently part of the file extension mechanism.
These are the beachheads.
One thing Apple seems to have learned, the hard way, is that you can't just plop a neat new technology down in front of your userbase and expect them to get it, learn it, or use it. Remember OpenDoc? Confused the *heck* out of most people -> they didn't like it -> they didn't use it or want it -> market dried up -> OpenDoc faded. Technologically, OD was pretty amazing... but there was no *need* for it to fill.
Think of iPhoto, iTunes and the rest as a user training ground. These are the baby steps that get users used to the idea of metadata as a useful working tool (way beyond labels). Once they find out how bloody useful and easy they are, and are used to them, rejiggering the Finder in a major way to provide the same sort of functionality becomes easier from a support viewpoint. I've actually had family members, once they grok keywords and tags, say "Wow, that'd be cool if I could do that with all my files..." Voila. A need to fill.
These are the signs and portents, among others. Add to these various speculations, rumors and whisperings from within Apple, and the direction they're headed is, if not clear, at least well hinted at.
wfzelle, I'd suggest reading up on the Virtual File System's guts to find out exactly why metadata and journaling are not tied together (in MacOS X) on a technical or implementation level any more than they are a conceptual one. It's a different beast, and one that allows independent implementation of such functionality, unlike most systems you may be used to and basing your assumptions on.
I can't believe you whiny people who get some new functionality and then bitch about how it slows file I/O by 10 to 15%. Users like you make programmers like me sick. We work to give you great functionality and all you do is complain about how it will marginally slow down your performance (even though you are obviously too dumb to remember that it is disabled by default). Heck, you probably don't know what a JFS is or why you would need it. People who complain that it runs 10-15% slower are idiots because for people who NEED a JFS, the penalty is well worth the functionality gained.
Users like you make programmers like me want to code up a lousy GUI's so that you have something legitimate to complain about.
OSX gets a real enterprise level feature and as a result, the discussion forum is filled with clueless people who can do nothing but complain about it. How completely sad! <img src="graemlins/oyvey.gif" border="0" alt="[No]" />
Users are easily confused. The eWeek article is a little misleading -- it describes 10-15% decrease in system performance, when it should probably say file I/O.
I have no idea why people are complaining about something is turned off by default and requires a CL to turn on, though. I imagine that OS X's UI performance is something of a sensitive area right now, and emotions get excited before brain cells kick in.
<strong>wfzelle, I'd suggest reading up on the Virtual File System's guts to find out exactly why metadata and journaling are not tied together (in MacOS X) on a technical or implementation level any more than they are a conceptual one. It's a different beast, and one that allows independent implementation of such functionality, unlike most systems you may be used to and basing your assumptions on.</strong><hr></blockquote>
They are both file system issues. And the BeFS guy has worked on a FS that has both. That sure is a relation, although not a technical one.
In any case, I don't think we have enough information yet to speculate on what the performance impact will be.
Oh, rumor site. Right. Sorry .
Without knowing anything about the implementation, let me throw a few random notes into the mix:
1. Writes in Darwin are, IIRC, essentially asynchronous operations; the data is copied into the kernel space, control is returned to the user, and writes are scheduled separately. If this is indeed how it works (and assuming I can tell my semaphores from my shmsegs these days), then writes are for all intents and purposes nonblocking operations, and user programs won't notice any slowdown. Can anyone here confirm or deny?
2. Although slow writes in journaled filesystems aren't uncommon, most also have tuning options that let you define how often writes are flushed to disk, how much caching is done, etc. Even if those options aren't public in the first version, I'd be surprised if they didn't eventually come to light.
3. Most journaling implementations exhibit poor behavior in pathological cases involving lots of small writes being constantly sent to disk; in such a case, it is possible that a system could exhibit a 10-15% reduction in interactivity, because it'll be thrashing the disk trying to schedule writes while otherwise fully occupied. However, I want to stress that the likelihood of this affecting a Mac user is very small, since that's a rare performance profile for a desktop user.
Just $0.02. Hopefully we'll find out more soon.
[ 10-17-2002: Message edited by: The Watchful Babbler ]</p>
To try and make this point as crystal clear as possible...
Some of the current research I'm doing involves real-time tracking of objects in live video.
Two parts of this problem are an algorithmic plugin system for tracking disparate objects (I have no idea what types of objects might be tracked later), and a video conferencing infrastructure. These are two separate, orthogonal problems, and are handled in separate orthogonal systems within the project. Either one can be used with or without the other.
Does this mean that every video conferencing system I work on from now on out *HAS* to have the object tracking?
Of course not.
Does the fact that the video conferencing structure can be used without the video tracking, and has been used as such by folks, mean that I've never implemented the video tracking?
Of course not.
Proximity does not imply a conceptual, causal, or even casual relationship between programmatic entities. This is one of the prime benefits of orthogonal systems design, which in turn is a foundation of OO programming. Apple has accomplished the design of a system that allows for orthogonal implementation of orthogonal concerns. This is the *right* way to do it.
Just because the guy who worked on BeFS implemented the journaling filter for VFS doesn't mean that either he IS or IS NOT working on a metadata system. It has absolutely, utterly nothing to do with it, other than as a use of his finite time. Given this one fact, regardless of all others, you cannot draw any meaningful conclusions regarding what else he may or may not be working on... and you certainly can't draw any rational conclusions as to what *other* people may be working on. It's a logical fallacy to assume otherwise.
Given the other areas where Apple has shown a strong interest in metadata (the iApps, arguably a cornerstone of their strategy, and the development tools, definitely something to shape future applications from *all* parties), there appears to be much more support for the hypothesis that they *are* working on metadata in some format or another, but that it just isn't in a consumer ready form.
Comments
<strong>those pining away over the loss of labels, mourn no more. for a measly $7 you can buy a copy of Labels X, the latest haxie from unsanity and get all your lost functionality back.</strong><hr></blockquote>
I guess you missed <a href="http://forums.appleinsider.com/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=5&t=001571"; target="_blank">this thread</a>.
<strong>There you go!</strong><hr></blockquote>
It should be more like:
Elvis Lives!! (in my OS)
<strong><a href="http://www.eweek.com/article2/0,3959,634711,00.asp"; target="_blank">This</a> + <a href="http://maccentral.macworld.com/news/0210/16.ibm.php"; target="_blank">this</a> = Having to buy a newer, faster Mac. Seems to be the way Apple has done things for the past few years...so why change?
I haven't upgraded to 10.2 yet. I have G3 700 iMac and have switched to OS X. I haven't really had GUI issues or OS issues. It's been other people's software (Graphic Converter vanishes after a few minutes and Photoshop 7's Image Browser is slooow as a dog...even with their recent update).
Just seems to be business as usual with Apple... <img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" /> </strong><hr></blockquote>
Yeah, damn them for providing new useful features and using a kick-butt chip. We demand less!
<img src="graemlins/bugeye.gif" border="0" alt="[Skeptical]" />
To repeat the obvious again: journaling hits the *drive access* with a 10-15% slowdown, *NOT* the entire system. The performance hit to the average user is going to be about nil. Under certain circumstances, yes, you'll likely notice, but those should be fairly rare. And, you can turn it off. And, it is off by default.
And, *do you people have any idea how freakin' amazing it is for them to offer a journaling **plug-in** for an *existing* filesystem?!?* Good LORD that is cool. I fully expected them to come out with UberFS that required a full reformat and reinstall. THIS is nothing short of a technical coup, and shows off the raw power of the VFS in Darwin.
Frankly, I'm extremely impressed.
<strong>So since filenames and filetypes were both in BeFS, that means *those* are related? Cool, I think we just found the justification for filename extensions. [No]
Proximity does not imply conceptual relationship.</strong><hr></blockquote>
Proximity is also a relationship, especially when you hire a BeFS guy. It's likely that he knows the advantages that advanced metadata can bring (and has some experience with it).
[quote]<strong>I wonder why this assumption keeps getting made in the face of a lack of evidence to support it.
Just because you're not privy to Apple's inner circle doesn't mean that it isn't a high priority. Read the signs and portents in various UI elements (particularly in the dev tools) to see nascent forays into *rich* metadata handling.</strong><hr></blockquote>
The lack of evidence is exactly what's worrying me. Could you expand on the signs and portents that you see?
<strong>The lack of evidence is exactly what's worrying me. Could you expand on the signs and portents that you see?</strong><hr></blockquote>
Project Builder 2.0 has an interface exposing MIME-like file typing functionality. Remember Be and MIME? I believe Kickaha's showed us a screenshot at least once before.. very cool.
I don't care that OS X runs a bit slow on the UI, I'm just incredibly grateful that crashing word doesn't ruin a whole days work in photoshop and that I can a lot of things at once without having to wait every time i print, open something or set a filter running.
I find this more than makes up for the time spent waiting for folders to open etc...
It's a trade off and I like the result, if anything I'm more productive as a power user in X, even when I'm Xing on my Wallstreet...totally off topic sorry but i'm in a rantin' mood
[ 10-17-2002: Message edited by: robster ]</p>
I don't care that OS X runs a bit slow on the UI, I just incredibly grateful that crashing word doesn't ruin a whole days work in photoshop and that I can a lot of things at once without having to wait every time i print, open something or set a filter running.
I find this more than ,akes up for the time spent waiting for folders to open etc...
It's a trade off and I like the result, if anything I'm more productive as a power user in X, even when I'm Xing on my Wallstreet...totally off topic sorry but i'm in a rantin' mood
<strong>Don't forget iTunes 3 "live playlists". With that you're getting very close to data soup--just dump everything into a folder and let the OS sort things anyway that you want depending on parameter and context.</strong><hr></blockquote>
And iPhoto's keywords.
Heck, think about Address Book's group tags for a moment, and you'll realize it's the same thing as well.
The iApps are moving to keyword/tag based lookup in a serious way. The dev tools are moving towards handling files based on hierarchical datatypes... that are *not* currently part of the file extension mechanism.
These are the beachheads.
One thing Apple seems to have learned, the hard way, is that you can't just plop a neat new technology down in front of your userbase and expect them to get it, learn it, or use it. Remember OpenDoc? Confused the *heck* out of most people -> they didn't like it -> they didn't use it or want it -> market dried up -> OpenDoc faded. Technologically, OD was pretty amazing... but there was no *need* for it to fill.
Think of iPhoto, iTunes and the rest as a user training ground. These are the baby steps that get users used to the idea of metadata as a useful working tool (way beyond labels). Once they find out how bloody useful and easy they are, and are used to them, rejiggering the Finder in a major way to provide the same sort of functionality becomes easier from a support viewpoint. I've actually had family members, once they grok keywords and tags, say "Wow, that'd be cool if I could do that with all my files..." Voila. A need to fill.
These are the signs and portents, among others. Add to these various speculations, rumors and whisperings from within Apple, and the direction they're headed is, if not clear, at least well hinted at.
wfzelle, I'd suggest reading up on the Virtual File System's guts to find out exactly why metadata and journaling are not tied together (in MacOS X) on a technical or implementation level any more than they are a conceptual one. It's a different beast, and one that allows independent implementation of such functionality, unlike most systems you may be used to and basing your assumptions on.
I can't believe you whiny people who get some new functionality and then bitch about how it slows file I/O by 10 to 15%. Users like you make programmers like me sick. We work to give you great functionality and all you do is complain about how it will marginally slow down your performance (even though you are obviously too dumb to remember that it is disabled by default). Heck, you probably don't know what a JFS is or why you would need it. People who complain that it runs 10-15% slower are idiots because for people who NEED a JFS, the penalty is well worth the functionality gained.
Users like you make programmers like me want to code up a lousy GUI's so that you have something legitimate to complain about.
OSX gets a real enterprise level feature and as a result, the discussion forum is filled with clueless people who can do nothing but complain about it. How completely sad! <img src="graemlins/oyvey.gif" border="0" alt="[No]" />
I have no idea why people are complaining about something is turned off by default and requires a CL to turn on, though. I imagine that OS X's UI performance is something of a sensitive area right now, and emotions get excited before brain cells kick in.
[ 10-17-2002: Message edited by: Hobbes ]</p>
<strong>wfzelle, I'd suggest reading up on the Virtual File System's guts to find out exactly why metadata and journaling are not tied together (in MacOS X) on a technical or implementation level any more than they are a conceptual one. It's a different beast, and one that allows independent implementation of such functionality, unlike most systems you may be used to and basing your assumptions on.</strong><hr></blockquote>
They are both file system issues. And the BeFS guy has worked on a FS that has both. That sure is a relation, although not a technical one.
Oh, rumor site. Right. Sorry .
Without knowing anything about the implementation, let me throw a few random notes into the mix:
1. Writes in Darwin are, IIRC, essentially asynchronous operations; the data is copied into the kernel space, control is returned to the user, and writes are scheduled separately. If this is indeed how it works (and assuming I can tell my semaphores from my shmsegs these days), then writes are for all intents and purposes nonblocking operations, and user programs won't notice any slowdown. Can anyone here confirm or deny?
2. Although slow writes in journaled filesystems aren't uncommon, most also have tuning options that let you define how often writes are flushed to disk, how much caching is done, etc. Even if those options aren't public in the first version, I'd be surprised if they didn't eventually come to light.
3. Most journaling implementations exhibit poor behavior in pathological cases involving lots of small writes being constantly sent to disk; in such a case, it is possible that a system could exhibit a 10-15% reduction in interactivity, because it'll be thrashing the disk trying to schedule writes while otherwise fully occupied. However, I want to stress that the likelihood of this affecting a Mac user is very small, since that's a rare performance profile for a desktop user.
Just $0.02. Hopefully we'll find out more soon.
[ 10-17-2002: Message edited by: The Watchful Babbler ]</p>
Some of the current research I'm doing involves real-time tracking of objects in live video.
Two parts of this problem are an algorithmic plugin system for tracking disparate objects (I have no idea what types of objects might be tracked later), and a video conferencing infrastructure. These are two separate, orthogonal problems, and are handled in separate orthogonal systems within the project. Either one can be used with or without the other.
Does this mean that every video conferencing system I work on from now on out *HAS* to have the object tracking?
Of course not.
Does the fact that the video conferencing structure can be used without the video tracking, and has been used as such by folks, mean that I've never implemented the video tracking?
Of course not.
Proximity does not imply a conceptual, causal, or even casual relationship between programmatic entities. This is one of the prime benefits of orthogonal systems design, which in turn is a foundation of OO programming. Apple has accomplished the design of a system that allows for orthogonal implementation of orthogonal concerns. This is the *right* way to do it.
Just because the guy who worked on BeFS implemented the journaling filter for VFS doesn't mean that either he IS or IS NOT working on a metadata system. It has absolutely, utterly nothing to do with it, other than as a use of his finite time. Given this one fact, regardless of all others, you cannot draw any meaningful conclusions regarding what else he may or may not be working on... and you certainly can't draw any rational conclusions as to what *other* people may be working on. It's a logical fallacy to assume otherwise.
Given the other areas where Apple has shown a strong interest in metadata (the iApps, arguably a cornerstone of their strategy, and the development tools, definitely something to shape future applications from *all* parties), there appears to be much more support for the hypothesis that they *are* working on metadata in some format or another, but that it just isn't in a consumer ready form.