Just a pedantic quibble here, but infinity is significantly more than 2 to the power of 6731988480. Just because my calculator can't handle it doesn't make it infinite.
I think you misunderstand my point. I'm saying that data can mean what you want it to mean, however many bits are involved. If I give you 01100101001010 (or any sequence of any length), you can't really say what it represents without context. I'm not talking about compression, but rather the combination of data and decoder needed to assign "meaning" to any bit stream.
ANYTHING that is digital will never be uncopyable.
While this statement makes sense, the reasoning
The reason is because you always know the parameters of how the digitizing is done. There are only so many ways that 1's and 0's can be put together (or taken apart) that make sense.
is very flawed. Copying isn't about the ability to "make sense" of data. A CD press doesn't need to figure out that one sequence of bits can represent music and other set can represent images. That is why most people make a distinction between copy protection and copy prevention.
Further, the "so many ways" that data can be [en|de]coded is actually infinite. I make a good deal of fun on this issue on my Data Fetish web site. The same data can easily make sense in more than one way based on different coding schemes, with my favorite example (to date) being the DeCSS prime.
You called nothing. Perhaps you'd like to try again?
Tell you what, cupcake. Since you're so sure of yourself, I invite you to start your own "music and movies for a buck" service right here in the USA. If there is no copyright protection as you say, you'll clean up big time. Until then, after you've gone through all the legal hassles involved, don't pretend you know jack about copyright law. Congratulations on being my first twit list entry.
Uh huh. Perhaps you need to read the Constitution of the United States of America to see what protection is afforded to parties for creation. The answer: NONE.
You say that as though that 200+ year old document was the last say on protection afforded by the United States government.
Similarly, the Berne Convention does not impose copyright law on any non-signatory; how could it? It's a treaty! Furthermore, it doesn't establish any international copyright law so much as it requires signatories to grant a copyright to works copyrighted elsewhere. Even then, within certain bounds.
Yeah, which is what I already said. Seems like you're just getting pissy because I called you on your statement that mere creation afforded no protection, whereas the Berne Convention states otherwise. No, Taiwan is not a signatory country but continued abuses of works created by signatory countries will likely lead to economic/trade sanctions against Taiwan.
It's hardly theft. And it's not a loophole. The MPAA et al are not entitled to any amount of copyright protection whatsoever merely as a consequence of having created some work. Not even in the US.
How the hell did this get moderated up? Perhaps you need to read up on the Berne Convention to figure out what protection is afforded to parties for creation. Taiwan, it should be noted, is not a member. This little stunt, though, could easily turn them from a developing country into a country that gets hammered not just by the US and the MPAA, but by 95 other countries that actually value the efforts of individuals that create content.
And in what way is what you're saying different than my original post?
Perhaps you should go back and re-read what you posted and compare it to the details of what I posted. If you can't figure out the differences, I don't think my telling you would help much.
Clearly the people modding you up don't know you're clueless yourself. The original OS was called both NeXTSTEP and NEXTSTEP by NeXT, and OPENSTEP was the follow-up OS. With it came a cross-platform API called OpenStep. Perhaps it's asking too much for people to actually go to the GNUstep site and click on the "GNU & OpenStep" link?
If you expected TiVo to adjust for the last-minute changes of the networks in real time, you are a fool.
Then at least I'm not a fool. What I expected for my $10/month is an accurate listing, one that is at least if not more accurate than what I can get off the paper or the net. That was not the case. No, I didn't expect it to know that some broadcast of some guys prancing around in some area trying to move some ball to some smaller area would take some amount of time more than the network said it would (I mean, how could you know that something scheduled to bore you to tears for 3 hours would actually bore you to tears for an extra 13 minutes? It's not like they're professional, organized sports with a long history behind them of being televised . ..). But, fuck, it seems every listing in the world knew that SNL was switched locally from 10:35 to 10:30, yet the TiVo listings I payed for remained clueless for at least the three months at the end of my service. It may still be wrong, too; I no longer care, though.
Nothing can do that until the networks and local stations get their act together; TiVo has no control over this. But for 99% of the shows, TiVo works. What more do you want?
A set schedule works 95+% of the time, too. I want something of value for $10/month. The TiVo service did not provide that. As it turned out, all I was really doing was paying for them to collect information on my viewing habits. I decided to pass on that. Feel free to make your own decisions.
I actually had the opposite attitude when I bought one. I really hoped that my $10 would end up resulting in something more amazing than just a TV listing. The problem is that it doesn't. There are a number of shows locally that decided it's a good idea to start at 5 minutes after, but heaven help you if they decide to at the hour/thirty, because the TiVo listing were never updated and I was always missing the first 5 minutes of those shows. This was before you could adjust the start time, but I could still argue that my paying $10 means I shouldn't have to adjust the time ever.
I was also really hoping that the TiVo listings system was smart enough to adjust for the fucking sporting events that stations seem to think is just fine to go over with and screw up the rest of the evening. Hell, ABC doesn't even have sporting events that I'm aware of and I still couldn't/can't rely on Politically Incorrect being in the time it's slotted for.
So I dropped the service. As a VCR, the TiVo is still an excellent buy. But until they improve their listings or figure out a way to make money on the data they collect, they won't be collecting any more of my money. It'll take more than a couple USB ports to get me to buy the new hardware, too. If they had a clue, they would have added a FireWire port so I could drop an extra drive on or a DVD/CD-RW for archival purposes.
is that they screw the vendor out of way too much money. They take at least $2.50 from every order, which is just something I will not tolerate either as a buyer or a seller. If I'm registering a $5 piece of shareware, I don't like the idea of Kagi sucking half that down their throats when my intent is to reward the author for a good program. At least PayPal is reasonable (or at least comparable to CC companies) when it comes to taking their cut. Sorry, but I will never again use Kagi (I did use it once, for GraphicConverter, before I looked into how high their fees were) to register software.
Ok, they're really annoying, but at least they're creatively made.
Yeah, and so were banner ads for the first year (tops). If the history of the web is any indication, it won't take long before the uncreative marketing types drown us all in absolute garbage.
People really should stop being so selfish. I'm starting to believe that the 'geek' title so many people here are proud to use is nothing more than a certificate of insensitiveness, egocentrism and selfishness...
Selfish is expecting to be rewarded in any way for putting up some crap site. Because most here are geeks, we do understand what it takes to put a site together and what it is "worth", either in subscription cost or ad annoyance. Far too many sites overvalue their content, and that is why you're never going to see them move to a subscription model, because then reality really comes crashing down on you when you discover that your site is so worthless that people won't pay a bloody buck a month for it.
How about... growing up?
How about getting back to the idea that the web was based on (sharing information) instead of trying to turn everything into a profit making venture?
It could conceivably be possible for a PowerPC Linux distro to hack up some kind of support based on Mac On Linux [maconlinux.org], but saying that it wouldn't be difficult shows a pretty thorough lack of appreciation for the complexity of QuickTime.
While I agree that it might not be as easy as the OP thinks, it clearly should be doable by the Linux community if they really cared, yet they prefer to bitch about it not being done for them. And while QuickTime itself might be fairly complex, what we're talking about here is one particular codec (Sorenson) that is troublesome. Isolate that portion and get to work. It may take some effort, but the process itself should be fairly straightforward.
And even if you did manage to build this monster, you'd still be limited to using it on PPC machine.
Because QuickTime is available for Windows, buried somewhere in that code is the (same) Sorenson codec. Again, it should be possible to isolate and execute that code. I know Linux is capable of running other x86 Unix binaries and some x86 Windows code with Wine, so the groundwork has already been done. Someone who really gives a damn has to bring it all together to give you a Linux Sorenson codec.
Interestingly (or not:-), jam is what Apple uses on Mac OS X for their Project Builder. It works very well, and it's especially nice for not choking like make does just because the path contains a space.
"Hey, if it doesn't work out don't worry about it, we'll take the loss; but if it does work out, before we pay you your cut we want to get our investment back"
But that's not what the labels are saying. The money they offer is not some sort of gift or venture capital, it is a loan. They're really saying:
"We'll give you this loan and jack every possible dime you might see in profit until it is paid back, but you have to use our people at our prices to record and market it, and if our people can't do their job very well, you get to try paying back a million dollars by being a nobody working a dead-end job at Hardee's."
This is also much the same way the game industry works, however you don't hear nearly as much public outcry on how the developers get screwed even though they never get a share of the profits, typically get laid off after a game ships and for the most part get paid sub pare in comparison to there skills.
I have no real sympathy for anyone that signs bad contracts in full knowledge of what's involved, but you don't get to reverse the situation and expect me to now muster up sympathy for the record labels who simply cannot change their business model fast enough to keep making a profit. The record labels could drop off the face of the earth tomorrow and I could still get a lot of new music, but if the artists vanish both me and the record labels are screwed. The artists are the ones with all the power, and once they realize that and stop signing bad contracts on the empty promise of fame and fortune we'll all be a lot better off.
I like the idea a lot, though there are some tricky parts. It seems that having no directories or symbolic links will make it difficult to refer to one file from another, because files wouldn't necessarily have unique names. (eg, there may be a hundred different files called index.html on the computer; how do you tell which one gets linked to?)
Actually, the file name (and extension) is really just considered another bit of metadata, too. Items are fundamentally uniqued by their content (usually with an md5 checksum generated off the data in the file, but even that is a just a derived metadata value). From the user perspective, files are usually identified by their attributes and values, and giving a specific enough focus results in a single file. If you want a file to appear in another focus (akin to appearing in another directory), you assign the appropriate metadata to it. So if you happen to like sunset images for your screen saver and one of your vacation snaps happens to be a sunset, you just give it that metadata value and there it is in your screen saver, too! I'm not seeing how it gets tricky; perhaps an example might clear things up?
Also, do you have Mary on an FTP site somewhere? I'm very interested in it.
I don't think it's quite ready for public consumption. Bits and pieces will be coming out over the next few months, as noted in another reply. It's also only going to be available for Mac OS X until the kinks are worked out and I can use GNUstep to get out a Linux version. Anybody who is interested in this should probably drop me an email and I can send out a note when an beta version is ready for testing. I'll be happy to hear your suggestions and potential uses to keep in mind as work progresses.
Sounds truly interesting. I suppose you don't have any links yet?
Sorry, no. The only thing that's close to release is a related framework component, STEnterprise (heh, let's see if we get sued for that name:-), which is intended to be a database independent object persistence layer (needed by some of the specialized managers in the MOM) intended to address the fact that Apple has mishandled EOF. That's due out at the end of the month, but it's not a major part of the STMOM framework, which is the core of Mary and MaryTool (the command line version).
Since there is growing interest in an updated user experience, I can provide a few links that I found inspirational in my work on Mary as a MOM.
The Anti-Mac Interface got it right in 1996, but we didn't have the vast datastore on the desktop to make it worth it, or the processing power to make it happen.
Liquid File System, insightful enough for me to say "screw it" to my own white paper and just implement the damn thing.:-)
Placeless Documents, an excellent paper, as you might expect from Xerox PARC.
SQLite, useful if you need to release software that would benefit from a database on a system that might not have one.
Shore, which interestingly can have the object store accessible using directory navigation, addressing some migration issues.
I think the fundamental problem here is related to yesterday's story about new user interfaces [slashdot.org]. It's a problem of how and where storing our files.
You could also trace it back to the hierarchical database article, which is when I started making a lot of posts on the subject. It seems there is finally a lot of interest being generated about this sort of thing.
I have no idea how to implement such a beast. I'm thinking about a RDBMS with indices on 'filetype' and 'application', but I would love to see something much more flexible. All pictures should be accessible under ~/pictures and subdirectories, all files relating to my vacation last year in ~/summer2000. Files relating to both should be in ~/pictures/summer2000 _and_ ~/summer2000/pictures.
This is exactly the sort of thing I'm doing with my Meta Object Manager (MOM) software called Mary. Metadata in the form of attributes and values is associated with each file/object and you can do a query (both textually and graphically) on that metadata. For simple paths like you describe, it is a value query irrespective of a particular attribute, but there is support for a more structured "path" (I actually call it a "focus" as it restricts your focus to a subset of the objects on the system) like/type=picture/location=Hawaii/year=2000. Because the focus items are metadata attributes, order is not significant. With such a system, there are no directories or symbolic links; it's all dynamically structured based on what your metadata focus is at any particular time.
Mary is just in the alpha stages at this point, but it already works well on the command line for the type of things you describe and I'm using it myself to manage nearly 350,000 objects that have been flowing through my system. I'm not exactly sure when it'll be ready for public consumption, and it'll require a GNUstep port to get working on Linux (I'm doing development on Mac OS X) systems. I was hoping year end, but I don't think I'll have the time. Summer 2002 has a nice ring to it, though.:-)
Yeah, that works, but you are essentially building meta data into the directory structure. Seems to me we have better ways of creating and using metadata. Many of your MP3s might already have the metadata you encoded in the directory structure, stored internally in the file. It seems a waste to duplicate that data.
I would go even farther and say that ID3 tags are themselves a waste, as they lock the metadata into the file in a proprietary format instead of making it available for wider adoption using some generalized mechanism. Of course, it's the poor metadata handling of the current crop of file managers that's really to blame.
Your method also can fail if you forget how you organize things, or perhaps slip up and misorganize, or work in a common directory structure you share with others who might think a little differently. 'Gee did my boss put that project plan in "IT\Projects\ERP\New" or "ERP\New Projects"?' Anyone who has worked on a shared lan drive knows what I am talking about.
Exactly why imposing a hierarchy on the metadata is a mistake, as I pointed out when this came up. The original poster probably has only one file on his entire system called "minefields.mp3", yet he has to dig down through the hierarchy to get to it. A system with proper metadata handling will essentially do that digging for you, and I look forward to the day users can take advantage of that. I'm doing it today, myself, because that's just the type of software I'm working on.
There is a definite need for creating a universally recognized way of storing file meta data that is not specific to a given file system or file format. It need not be complex or 3D, it just needs to allow me to easily enter and search on meta data and quickly create customized views of my files based on the meta data I have entered.
My software is being developed on Mac OS X and so far a modified browser/column view seems to work just fine for navigation. The major interface element that is needed is a text entry field (shades of the command line) for times when it's faster/easier to essentially search for an object instead of navigating to it.
Storing the data is another issue, and we've already gone through 3 different methods of persistence. The object layer hasn't changed, however, and the metadata is still easily represented as named and unnamed attribute values.
Examples: "All word documents sorted by name" "All documents created in the last week" "All excel spreadsheets for project "Jupiter" sorted by size" "All documents about dogs"
That's really just scratching the surface based on current metadata handling and indexing techniques. In a world where structured metadata isn't locked into the file itself, it would be possible to do even more advanced queries like "all invoices that are overdue" or "all movies shorter than 1 minute" or "songs where Sting is an artist". The limits become the limits you're willing to represent in metadata and not the limits of the system itself. Computers are just at the edge of where they need to be for this kind of advanced processing, but I predict that in 5 years the idea of a hierarchical file system will seem quaint.
I wish I knew more about filesystem programming, because I've long wished to write a simple file system that uses a structure which is independent of the presentation of files.
This doesn't require you write a fs, but rather it suggests an abstraction layer above any particular file/object store, be it data stored in a hierarchy on the file system or in an XML file or data stored in a database.
It would be simply wonderful to create a file system view, per user, which exists not only to restrict what they can see (almost like being chroot'd with lots of mounts in that directory), but also to make certain things more accessible or differently organized based on properties you feel are important. Doing so currently requires a shitload of symbolic links and manual maintenance when adding or removing files. Instead, you should be able to mount a file set under a name and put a query in that file set, so that it appears to be a directory with files that match some given attributes. Then you build a hierarchy of those, since that's a natural way to think about things.
Dead on. I wanted to give an example from my paper here, but the Slashdot lameness filters aren't allowing it.
The lack of categorization, or meta data, for files has been a thorn in users' collective side for decades, and with the death of Mac metadata in OS X, there's no real proponents out there for improvement.
Actually, Mac OS X metadata handling is richer than in previous versions, getting away from a file-centric model and closer to a user-centric one. It still isn't up to snuff, though, which is why I'm writing Mary, my Meta Object Manager, using Cocoa. So I guess you could say there is at least one proponent.:-)
While a hierarchy is often used by humans to organize and structure things, that should in no way impact how the data/information/objects are treated as individuals. Look at the common file system hierarchy and it's easy to see that burying files under a hierarchy of directories actually makes access to that information harder. It wasn't so noticeable when we were all just managing a few MB of files, but now people are beginning to store large picture, movie, and sound libraries. File managers have mistakenly stuck with the hierarchy instead of using information associated with the file itself (ID3 tags, etc.) to organize it all. What is really needed is a better approach to representing metadata so that information can be accessed directly based on those metadata attributes and not have it hidden in the hierarchy. I have a short essay on this from the work I've been doing on a Meta Object Manager (MOM), but it needs to be cleaned up before it could be published.
The desire to impose a hierarchy on the data itself instead of considering a hierarchy as simply one view on the data is a step backwards. Nobody who manages large amounts of data is looking to jam it into a static hierarchy, and so XML is not an answer, nor is any hierarchical representation.
Slashdot Mirror
Hell, if Sorority Sarah can burn the new N'SYNC album on her Compaq, she's not going to buy it.
The negative consequences being?
Just a pedantic quibble here, but infinity is significantly more than 2 to the power of 6731988480. Just because my calculator can't handle it doesn't make it infinite.
I think you misunderstand my point. I'm saying that data can mean what you want it to mean, however many bits are involved. If I give you 01100101001010 (or any sequence of any length), you can't really say what it represents without context. I'm not talking about compression, but rather the combination of data and decoder needed to assign "meaning" to any bit stream.
ANYTHING that is digital will never be uncopyable.
While this statement makes sense, the reasoning
The reason is because you always know the parameters of how the digitizing is done. There are only so many ways that 1's and 0's can be put together (or taken apart) that make sense.
is very flawed. Copying isn't about the ability to "make sense" of data. A CD press doesn't need to figure out that one sequence of bits can represent music and other set can represent images. That is why most people make a distinction between copy protection and copy prevention.
Further, the "so many ways" that data can be [en|de]coded is actually infinite. I make a good deal of fun on this issue on my Data Fetish web site. The same data can easily make sense in more than one way based on different coding schemes, with my favorite example (to date) being the DeCSS prime.
You called nothing. Perhaps you'd like to try again?
Tell you what, cupcake. Since you're so sure of yourself, I invite you to start your own "music and movies for a buck" service right here in the USA. If there is no copyright protection as you say, you'll clean up big time. Until then, after you've gone through all the legal hassles involved, don't pretend you know jack about copyright law. Congratulations on being my first twit list entry.
Uh huh. Perhaps you need to read the Constitution of the United States of America to see what protection is afforded to parties for creation. The answer: NONE.
You say that as though that 200+ year old document was the last say on protection afforded by the United States government.
Similarly, the Berne Convention does not impose copyright law on any non-signatory; how could it? It's a treaty! Furthermore, it doesn't establish any international copyright law so much as it requires signatories to grant a copyright to works copyrighted elsewhere. Even then, within certain bounds.
Yeah, which is what I already said. Seems like you're just getting pissy because I called you on your statement that mere creation afforded no protection, whereas the Berne Convention states otherwise. No, Taiwan is not a signatory country but continued abuses of works created by signatory countries will likely lead to economic/trade sanctions against Taiwan.
It's hardly theft. And it's not a loophole. The MPAA et al are not entitled to any amount of copyright protection whatsoever merely as a consequence of having created some work. Not even in the US.
How the hell did this get moderated up? Perhaps you need to read up on the Berne Convention to figure out what protection is afforded to parties for creation. Taiwan, it should be noted, is not a member. This little stunt, though, could easily turn them from a developing country into a country that gets hammered not just by the US and the MPAA, but by 95 other countries that actually value the efforts of individuals that create content.
And in what way is what you're saying different than my original post?
Perhaps you should go back and re-read what you posted and compare it to the details of what I posted. If you can't figure out the differences, I don't think my telling you would help much.
Clearly the people modding you up don't know you're clueless yourself. The original OS was called both NeXTSTEP and NEXTSTEP by NeXT, and OPENSTEP was the follow-up OS. With it came a cross-platform API called OpenStep. Perhaps it's asking too much for people to actually go to the GNUstep site and click on the "GNU & OpenStep" link?
If you expected TiVo to adjust for the last-minute changes of the networks in real time, you are a fool.
Then at least I'm not a fool. What I expected for my $10/month is an accurate listing, one that is at least if not more accurate than what I can get off the paper or the net. That was not the case. No, I didn't expect it to know that some broadcast of some guys prancing around in some area trying to move some ball to some smaller area would take some amount of time more than the network said it would (I mean, how could you know that something scheduled to bore you to tears for 3 hours would actually bore you to tears for an extra 13 minutes? It's not like they're professional, organized sports with a long history behind them of being televised . . .). But, fuck, it seems every listing in the world knew that SNL was switched locally from 10:35 to 10:30, yet the TiVo listings I payed for remained clueless for at least the three months at the end of my service. It may still be wrong, too; I no longer care, though.
Nothing can do that until the networks and local stations get their act together; TiVo has no control over this. But for 99% of the shows, TiVo works. What more do you want?
A set schedule works 95+% of the time, too. I want something of value for $10/month. The TiVo service did not provide that. As it turned out, all I was really doing was paying for them to collect information on my viewing habits. I decided to pass on that. Feel free to make your own decisions.
Etc. could be a USB CD burner, perhaps? That popping sound was the MPAA's aneurism.
No, it was the sound of my own as I die waiting for a USB burner to write even a 30 minute show.
Yeah I had the same attitude until I bought one.
I actually had the opposite attitude when I bought one. I really hoped that my $10 would end up resulting in something more amazing than just a TV listing. The problem is that it doesn't. There are a number of shows locally that decided it's a good idea to start at 5 minutes after, but heaven help you if they decide to at the hour/thirty, because the TiVo listing were never updated and I was always missing the first 5 minutes of those shows. This was before you could adjust the start time, but I could still argue that my paying $10 means I shouldn't have to adjust the time ever.
I was also really hoping that the TiVo listings system was smart enough to adjust for the fucking sporting events that stations seem to think is just fine to go over with and screw up the rest of the evening. Hell, ABC doesn't even have sporting events that I'm aware of and I still couldn't/can't rely on Politically Incorrect being in the time it's slotted for.
So I dropped the service. As a VCR, the TiVo is still an excellent buy. But until they improve their listings or figure out a way to make money on the data they collect, they won't be collecting any more of my money. It'll take more than a couple USB ports to get me to buy the new hardware, too. If they had a clue, they would have added a FireWire port so I could drop an extra drive on or a DVD/CD-RW for archival purposes.
is that they screw the vendor out of way too much money. They take at least $2.50 from every order, which is just something I will not tolerate either as a buyer or a seller. If I'm registering a $5 piece of shareware, I don't like the idea of Kagi sucking half that down their throats when my intent is to reward the author for a good program. At least PayPal is reasonable (or at least comparable to CC companies) when it comes to taking their cut. Sorry, but I will never again use Kagi (I did use it once, for GraphicConverter, before I looked into how high their fees were) to register software.
Ok, they're really annoying, but at least they're creatively made.
Yeah, and so were banner ads for the first year (tops). If the history of the web is any indication, it won't take long before the uncreative marketing types drown us all in absolute garbage.
People really should stop being so selfish. I'm starting to believe that the 'geek' title so many people here are proud to use is nothing more than a certificate of insensitiveness, egocentrism and selfishness...
Selfish is expecting to be rewarded in any way for putting up some crap site. Because most here are geeks, we do understand what it takes to put a site together and what it is "worth", either in subscription cost or ad annoyance. Far too many sites overvalue their content, and that is why you're never going to see them move to a subscription model, because then reality really comes crashing down on you when you discover that your site is so worthless that people won't pay a bloody buck a month for it.
How about... growing up?
How about getting back to the idea that the web was based on (sharing information) instead of trying to turn everything into a profit making venture?
For the grave implications:
s/buddy/sexy
It could conceivably be possible for a PowerPC Linux distro to hack up some kind of support based on Mac On Linux [maconlinux.org], but saying that it wouldn't be difficult shows a pretty thorough lack of appreciation for the complexity of QuickTime.
While I agree that it might not be as easy as the OP thinks, it clearly should be doable by the Linux community if they really cared, yet they prefer to bitch about it not being done for them. And while QuickTime itself might be fairly complex, what we're talking about here is one particular codec (Sorenson) that is troublesome. Isolate that portion and get to work. It may take some effort, but the process itself should be fairly straightforward.
And even if you did manage to build this monster, you'd still be limited to using it on PPC machine.
Because QuickTime is available for Windows, buried somewhere in that code is the (same) Sorenson codec. Again, it should be possible to isolate and execute that code. I know Linux is capable of running other x86 Unix binaries and some x86 Windows code with Wine, so the groundwork has already been done. Someone who really gives a damn has to bring it all together to give you a Linux Sorenson codec.
Interestingly (or not :-), jam is what Apple uses on Mac OS X for their Project Builder. It works very well, and it's especially nice for not choking like make does just because the path contains a space.
Can you do a parallel (multiprocess) build like gnu make?
Looks like the same switch:
-jx Run up to x shell commands concurrently.
LOL. Do I sense a new villain in the making? How cool would it be to have a character on the show based off of a "character" on Slashdot?
"Hey, if it doesn't work out don't worry about it, we'll take the loss; but if it does work out, before we pay you your cut we want to get our investment back"
But that's not what the labels are saying. The money they offer is not some sort of gift or venture capital, it is a loan. They're really saying:
"We'll give you this loan and jack every possible dime you might see in profit until it is paid back, but you have to use our people at our prices to record and market it, and if our people can't do their job very well, you get to try paying back a million dollars by being a nobody working a dead-end job at Hardee's."
This is also much the same way the game industry works, however you don't hear nearly as much public outcry on how the developers get screwed even though they never get a share of the profits, typically get laid off after a game ships and for the most part get paid sub pare in comparison to there skills.
I have no real sympathy for anyone that signs bad contracts in full knowledge of what's involved, but you don't get to reverse the situation and expect me to now muster up sympathy for the record labels who simply cannot change their business model fast enough to keep making a profit. The record labels could drop off the face of the earth tomorrow and I could still get a lot of new music, but if the artists vanish both me and the record labels are screwed. The artists are the ones with all the power, and once they realize that and stop signing bad contracts on the empty promise of fame and fortune we'll all be a lot better off.
I like the idea a lot, though there are some tricky parts. It seems that having no directories or symbolic links will make it difficult to refer to one file from another, because files wouldn't necessarily have unique names. (eg, there may be a hundred different files called index.html on the computer; how do you tell which one gets linked to?)
Actually, the file name (and extension) is really just considered another bit of metadata, too. Items are fundamentally uniqued by their content (usually with an md5 checksum generated off the data in the file, but even that is a just a derived metadata value). From the user perspective, files are usually identified by their attributes and values, and giving a specific enough focus results in a single file. If you want a file to appear in another focus (akin to appearing in another directory), you assign the appropriate metadata to it. So if you happen to like sunset images for your screen saver and one of your vacation snaps happens to be a sunset, you just give it that metadata value and there it is in your screen saver, too! I'm not seeing how it gets tricky; perhaps an example might clear things up?
Also, do you have Mary on an FTP site somewhere? I'm very interested in it.
I don't think it's quite ready for public consumption. Bits and pieces will be coming out over the next few months, as noted in another reply. It's also only going to be available for Mac OS X until the kinks are worked out and I can use GNUstep to get out a Linux version. Anybody who is interested in this should probably drop me an email and I can send out a note when an beta version is ready for testing. I'll be happy to hear your suggestions and potential uses to keep in mind as work progresses.
Sounds truly interesting. I suppose you don't have any links yet?
Sorry, no. The only thing that's close to release is a related framework component, STEnterprise (heh, let's see if we get sued for that name :-), which is intended to be a database independent object persistence layer (needed by some of the specialized managers in the MOM) intended to address the fact that Apple has mishandled EOF. That's due out at the end of the month, but it's not a major part of the STMOM framework, which is the core of Mary and MaryTool (the command line version).
Since there is growing interest in an updated user experience, I can provide a few links that I found inspirational in my work on Mary as a MOM.
I think the fundamental problem here is related to yesterday's story about new user interfaces [slashdot.org]. It's a problem of how and where storing our files.
You could also trace it back to the hierarchical database article, which is when I started making a lot of posts on the subject. It seems there is finally a lot of interest being generated about this sort of thing.
I have no idea how to implement such a beast. I'm thinking about a RDBMS with indices on 'filetype' and 'application', but I would love to see something much more flexible. All pictures should be accessible under ~/pictures and subdirectories, all files relating to my vacation last year in ~/summer2000. Files relating to both should be in ~/pictures/summer2000 _and_ ~/summer2000/pictures.
This is exactly the sort of thing I'm doing with my Meta Object Manager (MOM) software called Mary. Metadata in the form of attributes and values is associated with each file/object and you can do a query (both textually and graphically) on that metadata. For simple paths like you describe, it is a value query irrespective of a particular attribute, but there is support for a more structured "path" (I actually call it a "focus" as it restricts your focus to a subset of the objects on the system) like /type=picture/location=Hawaii/year=2000. Because the focus items are metadata attributes, order is not significant. With such a system, there are no directories or symbolic links; it's all dynamically structured based on what your metadata focus is at any particular time.
Mary is just in the alpha stages at this point, but it already works well on the command line for the type of things you describe and I'm using it myself to manage nearly 350,000 objects that have been flowing through my system. I'm not exactly sure when it'll be ready for public consumption, and it'll require a GNUstep port to get working on Linux (I'm doing development on Mac OS X) systems. I was hoping year end, but I don't think I'll have the time. Summer 2002 has a nice ring to it, though. :-)
Yeah, that works, but you are essentially building meta data into the directory structure. Seems to me we have better ways of creating and using metadata. Many of your MP3s might already have the metadata you encoded in the directory structure, stored internally in the file. It seems a waste to duplicate that data.
I would go even farther and say that ID3 tags are themselves a waste, as they lock the metadata into the file in a proprietary format instead of making it available for wider adoption using some generalized mechanism. Of course, it's the poor metadata handling of the current crop of file managers that's really to blame.
Your method also can fail if you forget how you organize things, or perhaps slip up and misorganize, or work in a common directory structure you share with others who might think a little differently. 'Gee did my boss put that project plan in "IT\Projects\ERP\New" or "ERP\New Projects"?' Anyone who has worked on a shared lan drive knows what I am talking about.
Exactly why imposing a hierarchy on the metadata is a mistake, as I pointed out when this came up. The original poster probably has only one file on his entire system called "minefields.mp3", yet he has to dig down through the hierarchy to get to it. A system with proper metadata handling will essentially do that digging for you, and I look forward to the day users can take advantage of that. I'm doing it today, myself, because that's just the type of software I'm working on.
There is a definite need for creating a universally recognized way of storing file meta data that is not specific to a given file system or file format. It need not be complex or 3D, it just needs to allow me to easily enter and search on meta data and quickly create customized views of my files based on the meta data I have entered.
My software is being developed on Mac OS X and so far a modified browser/column view seems to work just fine for navigation. The major interface element that is needed is a text entry field (shades of the command line) for times when it's faster/easier to essentially search for an object instead of navigating to it.
Storing the data is another issue, and we've already gone through 3 different methods of persistence. The object layer hasn't changed, however, and the metadata is still easily represented as named and unnamed attribute values.
Examples: "All word documents sorted by name" "All documents created in the last week" "All excel spreadsheets for project "Jupiter" sorted by size" "All documents about dogs"
That's really just scratching the surface based on current metadata handling and indexing techniques. In a world where structured metadata isn't locked into the file itself, it would be possible to do even more advanced queries like "all invoices that are overdue" or "all movies shorter than 1 minute" or "songs where Sting is an artist". The limits become the limits you're willing to represent in metadata and not the limits of the system itself. Computers are just at the edge of where they need to be for this kind of advanced processing, but I predict that in 5 years the idea of a hierarchical file system will seem quaint.
I wish I knew more about filesystem programming, because I've long wished to write a simple file system that uses a structure which is independent of the presentation of files.
This doesn't require you write a fs, but rather it suggests an abstraction layer above any particular file/object store, be it data stored in a hierarchy on the file system or in an XML file or data stored in a database.
It would be simply wonderful to create a file system view, per user, which exists not only to restrict what they can see (almost like being chroot'd with lots of mounts in that directory), but also to make certain things more accessible or differently organized based on properties you feel are important. Doing so currently requires a shitload of symbolic links and manual maintenance when adding or removing files. Instead, you should be able to mount a file set under a name and put a query in that file set, so that it appears to be a directory with files that match some given attributes. Then you build a hierarchy of those, since that's a natural way to think about things.
Dead on. I wanted to give an example from my paper here, but the Slashdot lameness filters aren't allowing it.
The lack of categorization, or meta data, for files has been a thorn in users' collective side for decades, and with the death of Mac metadata in OS X, there's no real proponents out there for improvement.
Actually, Mac OS X metadata handling is richer than in previous versions, getting away from a file-centric model and closer to a user-centric one. It still isn't up to snuff, though, which is why I'm writing Mary, my Meta Object Manager, using Cocoa. So I guess you could say there is at least one proponent. :-)
While a hierarchy is often used by humans to organize and structure things, that should in no way impact how the data/information/objects are treated as individuals. Look at the common file system hierarchy and it's easy to see that burying files under a hierarchy of directories actually makes access to that information harder. It wasn't so noticeable when we were all just managing a few MB of files, but now people are beginning to store large picture, movie, and sound libraries. File managers have mistakenly stuck with the hierarchy instead of using information associated with the file itself (ID3 tags, etc.) to organize it all. What is really needed is a better approach to representing metadata so that information can be accessed directly based on those metadata attributes and not have it hidden in the hierarchy. I have a short essay on this from the work I've been doing on a Meta Object Manager (MOM), but it needs to be cleaned up before it could be published.
The desire to impose a hierarchy on the data itself instead of considering a hierarchy as simply one view on the data is a step backwards. Nobody who manages large amounts of data is looking to jam it into a static hierarchy, and so XML is not an answer, nor is any hierarchical representation.