Get an application like 'Rhythmbox' or "Muine" that will do the management for you.
Sounds great, except, some apps don't like ID3v2.3 tags, some apps don't like ID3v1.1 tags, etc.
Some advanced music player apps (bpmDj comes to mind) also like to use more advanced metadata like BPM (which either cannot or is not usually stored in ID3vX.X tags) to make shuffling decisions.
That's why I prefer to (very simplistically, I know) just have everything stored in a hierarchy where the "Album", "Artist", "Title" and "Track #" are stored somewhere in the path name (and year is usually also stored as well, although I almost never use it for searches). All other metadata (like BPM) goes somewhere else.
What I really want is a universal system where you can associate arbitrary KEY:VALUE metadata with files (which could, of course, be done semi-automatically for music and such). This can then be organized and stored in the file system itself (that's its job!) and more integrated with the system, rather than having each app use its own (broken, inefficient) metadata parser/database. Oh, well. One can only dream.
Don't use the fileystem for this kind of thing. It's very slow.
Umm... it's the file system's job to do this kind of thing.
Checking the ID3 tags for 3000 songs is not going to be a quickly accomplished task no matter your system. The disk access time is just going to be too great.
Well, you can always index them periodically (and on 'creation') instead of re-reading metadata every time.:)
But I'm wondering why the 'music' folder should be special... why not just index metadata of everything in one place? (Of course there are some things which don't have meaningful metadata, but then you just don't index them...).
That would give the user an alternative way of finding organizing/finding things without actually limiting them to 'only' the file system hierarchy.
A filing cabinet is not the same as files on a disk. You can index/organize files in countless ways in a file system whereas you can only have one particular organization with filing cabinets. Next!
And the great thing about the spatial Nautilus mode is that it works both spatially *and* navigationally!
Oooooh, I does two things which are of no use to me. These 'features' are only great if you care about the metaphor instead of caring about the user (imagine such a thing!).
Here's a free hint: Computer interfaces are not constrained by the real world (well, beyond capacity and the physical constraints on input/output devices)
You can open a folder, scan through the list of folders and files in it, and make a choice based on a known path or set of directions.
Rather than me just knowing beforehand that I want to go into the "src/whatever/lib/" directory and using the alphebetical listing to find each of those quickly. This gives med O(log N) time for each directory selection as opposed to O(N) time for each directory selection w/spatial unless I magically just happen to remember where it is 'spatially' and nobody's decided to reorganize things because they like some other spatial layout better (this is a real problem with shared folders). Another issue is that only nautilus cares about the 'spatial' metadata, so if I (god forbid!) want to use the command line, I still have to remember the file system paths to my files 'non-spatially' (i.e. remember their names). Mixing two metaphors/paradigms is not a good idea.
Now, if you'd care to make some real arguments for spatial navigation, be my guest, but what you gave us was hardly very convincing. Hint: Argument from authority (ie. the 'GNOME developers know better than you') or straw men ('oh, but just look at how we do things in the real world') are not real arguments.
[...]and the names of my music files don't have all of the info on which I care to search.
Fair enough, but why not, then, have a unified meta-data search for all document/file types? The "OS" could just index everything and you could perform metadata searches on all your documents/files...
Ok, how many different file types should the finder open and index every time a new one is created?
Uhm... by "new one", do you mean "new file type" or "new file"? If you mean file type, then the Finder should ideally index everything which it understands metadata for. Better yet, make it a part of the OS X compatibility guidelines, that any new file types created/used by a program be accompanied by a program/library with a fixed, well-known interface (this could be as simple as just listing KEY:VALUE pairs on stdout) which can extract keywords/metadata from any file of the given type. That way, Finder doesn't have to understand any files 'foreign' to itself, it just calls up the metadata extractor program/library which is registered for the file type.
How much space should we give up for indexing?
Any reasonably new machine has gigabytes upon gigabytes of free space. If you don't have the space, then it shouldn't index. You know, this can be detected auotmatically. Duh.
Maybe what Finder does and doesn't do has something to do with prioritization and limited resources.
Oh please. There's no reason metadata indexing can't be done in the background. (In fact, a program called mairix is doing it for my mail right now and at nice +19 I hardly notice it.)
Stuff from mom. Ok, that goes right to dev/null. "HOT TEENAGED SLUTS!!!!". Ok, that goes right to the important-respond right away folder. And we can all easily agree on those catagorizations too so we can share filters.
Nope, you can't share filters because chances are that your mom and my mom use vastly different vocabularies. (And in my particular case a language spoken/written only by fewer than 100.000 people in the whole world).
The only reason spam-filter sharing works is that spam tends to:
Be in english (or engrish at least)
Use similar phrases (Stuff about lotteries, deposed dictators and the like).
Also, there are only two categories (which can therefore easily be set up beforehand), spam and non-spam. Anything which is not classified as spam just automatically goes into non-spam, it doesn't even need to be 'classified' by the algorithm as non-spam, so the filter needs no training to know what non-spam is.
But in answer to your question: Yes, you do have to create an initial hierarchy. Bayesian classification techniques don't actually understand your documents, they only filter them into predetermined categories based on similarities. But doing initial setup and categorizing a few documents is hardly an insurmountable task.:)
and most scripting tasks are text processing and process control, neither of which any functional language is particularly suited for
Actually, if you think about it, sh is actually a lazily evaluated somewhat functional language (esp. the pipe syntax). However, very few functional languages have process management and pipes as a built-in part of the syntax, although one could probably quite easily whip something up using the Shell module (from the Equeue package) and a small preprocessor extension to make the syntax more sh-like. I haven't done so because, frankly, the OCaml environment is rich enough, and development fast enough that I usually don't actually need to drive preexisting command-line tools from within OCaml.
In my opinion it's more powerful than the "everything's a pipe" approach.
If anything it's actually a subset of the "everything's a pipe" approach. One problem with COM is that the data representation is fixed, whereas the pipe model allows arbitrary data (i.e. is more flexible with respect to the data representation) -- you just have to be able to parse the output of a program to the extent that you actually need to be able to interface with it. Example: wc doesn't actually need to know what the output of a program means to be able to count words/lines. Contrast this with COM where you actually need a full interface declaration to the able to interface with a "program". And you need to have such a declaration for every single program even though you don't actually need to understand very much of its data representation.
What's your point? The program is shorter shorter when written in sh, more natural and more readable. (Not to mention that it uses lazy evaluation, so that the full input doesn't need to be in memory, just the full list of words).
Admittedly all of them are microcontrollers (PIC, AVR, HC11), but it really does force you to understand how the machine is working.
It may do so on microcontrollers, but on e.g. x86 (anything later than Pentium 2, IIRC?), the processor actually interprets the machine code into a different RISC-based language which it executes. This translation is hidden from the programmer and so you effectively only learn about the "machine language environment" of the processor, not how the processor actually works.
You would/could not have known that this translation occurs just from learning x86 assembly because it is hidden from you.
No, if you wan't to learn about processor architecture you study processor architecture, you don't study assembly language.
No, you don't. It notices that the embedded IMG link goes to a listed server (or more precisely: is caught by your filter list) and stops mozilla from loading the image.
is if they've found a cure for cancer? I mean, since the chances of getting cancer increase dramatically with age (presumbly because there's an increase in the probability of a faulty DNA copy over time), wouldn't people just die of cancer instead of "old age"?
Since evolution cannot get rid of conditions/diseases that afflict us after reproduction has occurred, I suspect that there will always be some disease/condition which will cause death with age. But maybe that's just me.
even if you were only allowed, say, 5 copies, you could create 5*5*5*5*5 = 3125 copies, simply by copying the 1 'master' cd to 5 new cd's, copying each of those to 5 new cd's, etc.
How many people out there are currently doing 3125 copies (with no limits on copying)...?
Java isn't a purely compiled language, nor is it purely interpreted. It's a hybrid, and Java's similarity to C/C++ doesn't go far beyond syntax.
Language differences are utterly irrelevant. What is relevant (and what the poster points out rather cleverly) is that C/C++ is hugely popular, as cross-platform as you want it to be, etc.
There are lots of implementations of C/C++ that all interoperate perfectly well as long as the programmer sticks to specifications and the compilers do. It will be exactly the same with Java if it's opened up.
I don't want to find out what happens when all of a sudden you can't rely on the guts of Java to be the same anywhere.
You shouldn't rely on the "guts of Java" (by which I assume you mean "implementation of Java") to be the same everywhere. You should rely on the Java specification (that's what it's for!).
Surely the whole point of using assembly is that you can optimize specifically for the platform (otherwise why not just use C?).
But if it has to be "High-Level", then that implies that you cannot get access to or exploit the particulars of the underlying platform. E.g.: Optimal instruction scheduling, pipeline depths are different from platform to platform, so how you accomodate that? If this is just about generating assembler specifically for each platform from a "template", then why not just use a generic macro language?
Smart and efficient way to make a new compiler produce extremly fast code and be crossplatform without an extra effort.
Except that the Eiffel->C translation effectively obliterates any chance of using the (presumably) much stronger semantics of Eiffel for optimizations which are not possible in C, due to the fact that a C compiler doesn't know about the semantics of Eiffel, and consequently cannot know of any "non-C" properties of the intermediate C program.
So there is a clear meaning to the sentence "{the set of points in square A} is 50% of the size of {the set of points in square B}."
Nope, that doesn't make sense either, because there are equally many points in both sets, so you can just as well say that "{the set of points in square A} is 100% of the size of {the set of points in square B}". (There is a 1:1 mapping between them).
swapping to increase the size of the file cache, a huge performance win.
Well, the trouble with this is that there are rapidly diminishing returns on the size of the disk cache. At some point it becomes pointless to swap to try to increase the size of the file cache.
(However, being able to allocate more than the physical amount of memory and avoiding thrashing as long as the working set is smaller than physical RAM still counts for something if you normally work on huge data sets).
Although it may sound counterintuitive, it can (and usually does, unless you have obscene amounts of RAM) actually improve performance. Here's why: If the computer can swap something out which hasn't been used in a long time, you can use the freed physical RAM for other things, e.g. more disk cache, thus speeding things up.
Slashdot Mirror
Sounds great, except, some apps don't like ID3v2.3 tags, some apps don't like ID3v1.1 tags, etc.
Some advanced music player apps (bpmDj comes to mind) also like to use more advanced metadata like BPM (which either cannot or is not usually stored in ID3vX.X tags) to make shuffling decisions.
That's why I prefer to (very simplistically, I know) just have everything stored in a hierarchy where the "Album", "Artist", "Title" and "Track #" are stored somewhere in the path name (and year is usually also stored as well, although I almost never use it for searches). All other metadata (like BPM) goes somewhere else.
What I really want is a universal system where you can associate arbitrary KEY:VALUE metadata with files (which could, of course, be done semi-automatically for music and such). This can then be organized and stored in the file system itself (that's its job!) and more integrated with the system, rather than having each app use its own (broken, inefficient) metadata parser/database. Oh, well. One can only dream.
Umm... it's the file system's job to do this kind of thing.
Well, you can always index them periodically (and on 'creation') instead of re-reading metadata every time.
But I'm wondering why the 'music' folder should be special... why not just index metadata of everything in one place? (Of course there are some things which don't have meaningful metadata, but then you just don't index them...).
That would give the user an alternative way of finding organizing/finding things without actually limiting them to 'only' the file system hierarchy.
Define 'works'.
Finding a file is not the same as driving. Next!
A filing cabinet is not the same as files on a disk. You can index/organize files in countless ways in a file system whereas you can only have one particular organization with filing cabinets. Next!
Oooooh, I does two things which are of no use to me. These 'features' are only great if you care about the metaphor instead of caring about the user (imagine such a thing!).
Here's a free hint: Computer interfaces are not constrained by the real world (well, beyond capacity and the physical constraints on input/output devices)
Rather than me just knowing beforehand that I want to go into the "src/whatever/lib/" directory and using the alphebetical listing to find each of those quickly. This gives med O(log N) time for each directory selection as opposed to O(N) time for each directory selection w/spatial unless I magically just happen to remember where it is 'spatially' and nobody's decided to reorganize things because they like some other spatial layout better (this is a real problem with shared folders). Another issue is that only nautilus cares about the 'spatial' metadata, so if I (god forbid!) want to use the command line, I still have to remember the file system paths to my files 'non-spatially' (i.e. remember their names). Mixing two metaphors/paradigms is not a good idea.
Now, if you'd care to make some real arguments for spatial navigation, be my guest, but what you gave us was hardly very convincing. Hint: Argument from authority (ie. the 'GNOME developers know better than you') or straw men ('oh, but just look at how we do things in the real world') are not real arguments.
Fair enough, but why not, then, have a unified meta-data search for all document/file types? The "OS" could just index everything and you could perform metadata searches on all your documents/files...
Uhm... by "new one", do you mean "new file type" or "new file"? If you mean file type, then the Finder should ideally index everything which it understands metadata for. Better yet, make it a part of the OS X compatibility guidelines, that any new file types created/used by a program be accompanied by a program/library with a fixed, well-known interface (this could be as simple as just listing KEY:VALUE pairs on stdout) which can extract keywords/metadata from any file of the given type. That way, Finder doesn't have to understand any files 'foreign' to itself, it just calls up the metadata extractor program/library which is registered for the file type.
Any reasonably new machine has gigabytes upon gigabytes of free space. If you don't have the space, then it shouldn't index. You know, this can be detected auotmatically. Duh.
Oh please. There's no reason metadata indexing can't be done in the background. (In fact, a program called mairix is doing it for my mail right now and at nice +19 I hardly notice it.)
Nope, you can't share filters because chances are that your mom and my mom use vastly different vocabularies. (And in my particular case a language spoken/written only by fewer than 100.000 people in the whole world).
The only reason spam-filter sharing works is that spam tends to:
Also, there are only two categories (which can therefore easily be set up beforehand), spam and non-spam. Anything which is not classified as spam just automatically goes into non-spam, it doesn't even need to be 'classified' by the algorithm as non-spam, so the filter needs no training to know what non-spam is.
But in answer to your question: Yes, you do have to create an initial hierarchy. Bayesian classification techniques don't actually understand your documents, they only filter them into predetermined categories based on similarities. But doing initial setup and categorizing a few documents is hardly an insurmountable task.
Actually, if you think about it, sh is actually a lazily evaluated somewhat functional language (esp. the pipe syntax). However, very few functional languages have process management and pipes as a built-in part of the syntax, although one could probably quite easily whip something up using the Shell module (from the Equeue package) and a small preprocessor extension to make the syntax more sh-like. I haven't done so because, frankly, the OCaml environment is rich enough, and development fast enough that I usually don't actually need to drive preexisting command-line tools from within OCaml.
If anything it's actually a subset of the "everything's a pipe" approach. One problem with COM is that the data representation is fixed, whereas the pipe model allows arbitrary data (i.e. is more flexible with respect to the data representation) -- you just have to be able to parse the output of a program to the extent that you actually need to be able to interface with it. Example: wc doesn't actually need to know what the output of a program means to be able to count words/lines. Contrast this with COM where you actually need a full interface declaration to the able to interface with a "program". And you need to have such a declaration for every single program even though you don't actually need to understand very much of its data representation.
What's your point? The program is shorter shorter when written in sh, more natural and more readable. (Not to mention that it uses lazy evaluation, so that the full input doesn't need to be in memory, just the full list of words).
It may do so on microcontrollers, but on e.g. x86 (anything later than Pentium 2, IIRC?), the processor actually interprets the machine code into a different RISC-based language which it executes. This translation is hidden from the programmer and so you effectively only learn about the "machine language environment" of the processor, not how the processor actually works.
You would/could not have known that this translation occurs just from learning x86 assembly because it is hidden from you.
No, if you wan't to learn about processor architecture you study processor architecture, you don't study assembly language.
No, you don't. It notices that the embedded IMG link goes to a listed server (or more precisely: is caught by your filter list) and stops mozilla from loading the image.
Where in the story text did Slashdot misrepresent information?
is if they've found a cure for cancer? I mean, since the chances of getting cancer increase dramatically with age (presumbly because there's an increase in the probability of a faulty DNA copy over time), wouldn't people just die of cancer instead of "old age"?
Since evolution cannot get rid of conditions/diseases that afflict us after reproduction has occurred, I suspect that there will always be some disease/condition which will cause death with age. But maybe that's just me.
nt = no text
even if you were only allowed, say, 5 copies, you could create 5*5*5*5*5 = 3125 copies, simply by copying the 1 'master' cd to 5 new cd's, copying each of those to 5 new cd's, etc.
How many people out there are currently doing 3125 copies (with no limits on copying)...?
Language differences are utterly irrelevant. What is relevant (and what the poster points out rather cleverly) is that C/C++ is hugely popular, as cross-platform as you want it to be, etc.
There are lots of implementations of C/C++ that all interoperate perfectly well as long as the programmer sticks to specifications and the compilers do. It will be exactly the same with Java if it's opened up.
You shouldn't rely on the "guts of Java" (by which I assume you mean "implementation of Java") to be the same everywhere. You should rely on the Java specification (that's what it's for!).
as you probably already know. There is no way to access/manipulate form values within HTML.
Surely the whole point of using assembly is that you can optimize specifically for the platform (otherwise why not just use C?).
But if it has to be "High-Level", then that implies that you cannot get access to or exploit the particulars of the underlying platform. E.g.: Optimal instruction scheduling, pipeline depths are different from platform to platform, so how you accomodate that? If this is just about generating assembler specifically for each platform from a "template", then why not just use a generic macro language?
HLA seems utterly pointless to me.
Except that the Eiffel->C translation effectively obliterates any chance of using the (presumably) much stronger semantics of Eiffel for optimizations which are not possible in C, due to the fact that a C compiler doesn't know about the semantics of Eiffel, and consequently cannot know of any "non-C" properties of the intermediate C program.
Welcome to the real world of marketing.
does that allow you to pass values to the next "iteration"?
Simply put: The notion of a percentage breaks down because the denominator in the fraction (by which a "percentage" is defined) is infinite.
Nope, that doesn't make sense either, because there are equally many points in both sets, so you can just as well say that "{the set of points in square A} is 100% of the size of {the set of points in square B}". (There is a 1:1 mapping between them).
Well, the trouble with this is that there are rapidly diminishing returns on the size of the disk cache. At some point it becomes pointless to swap to try to increase the size of the file cache.
(However, being able to allocate more than the physical amount of memory and avoiding thrashing as long as the working set is smaller than physical RAM still counts for something if you normally work on huge data sets).
Although it may sound counterintuitive, it can (and usually does, unless you have obscene amounts of RAM) actually improve performance. Here's why: If the computer can swap something out which hasn't been used in a long time, you can use the freed physical RAM for other things, e.g. more disk cache, thus speeding things up.
14) Real men use sed.