Besides having door guards like the other poster mentioned, you could combat that kind of thing with scanners all around the store. It would look pretty suspicious if expensive items started dropping off the security scanners where ever you were walking.
Have you ever seen those non-cashier scanning stations and new grocery stores? You don't need a cashier to count change or swipe cards. And since scanning would be so much easier, you could probably have one person that oversees 15 or 20 scanning stations, instead of the 5 or 6 they do now. You don't need a person at each station just to change receipt rolls.
But then you suffer a performance hit going through some motions that work very well on filesystems but poorly on databases
I'm not sure whether you mean low-level operations like file space allocation or user-level operations like searching for and using files, but I don't think it's true in either case. A database filesystem could be optimized at the low-level as much as current filesystems. User-level operations could be seen as slower if you were trying to perform them in the same way, but the methodology of interacting with files would change. So we'd get a new set of operations that would be just as fast, or faster for many things.
Instead of declaring me pig-headed for not wanting to go to Oracle to store all my files, why not come over here and admit filesystems with metadata enhancemnets are just specialized databases that already do everything you want with just a little more effort.
Because I don't agree with that view. You're too stuck on this idea of location. Files don't need a location. That's a byproduct of the operational semantics that were chosen so long ago. A file hierarchy is just a kind of relation, something that a relational database filesystem could represent if you wanted it. But there are other kinds of relations that can't be represented by a hierarchical system. Relations that could by very useful, but that no one has thought of because we're stuck thinking that files need "locations".
I'm not trying to argue that this would be better or even as good as a database filesystem. I like the idea of well-designed database filesystem. I was merely pointing out a contradiction to your claim that "no collection of folders can duplicate this ease of use and flexibility no matter how crazy you make them." You could argue that it falls down on the "ease of use" criteria, but it would be pretty easy to make a tool that creates the directories and symlinks for you, according to your categorizations. On the other hand, searching the symlink maze wouldn't be quite as powerful as being able to write full SQL queries, so I can't really argue that it fulfills the flexibility criteria.
Don't be fooled, however, about the effort required. The amount of effort for adding the metadata is about the same under either system. Even if the database filesystem can handle the metadata automatically (I'm not sure what you meant by that), you still need to add it manually. The computer can't tell that the picture you just uploaded from your camera is of a bunch of wildflowers. So there would be tools to add metadata, and the tools could, to the user, behave identically for either system. The only difference would be that under one system, rows are added to a database, and under the other, directories and symlinks are created.
Aren't highways still around?:-) Must be an Americanism I've never heard before...
As on off-topic aside, the comment to which you responded has mixed two separate phrases. One is "going the way of the dodo," meaning extinct. The second is "hitting the highway," meaning getting on its way, out of your life.
You see, in my example the blob of data in your file system NEVER was in the proper backup set because you didn't tag it right.
This seems to be your main sticking point: that users will not want to tag files when they are created, so the whole system is worthless. However, you aren't seeing the similarity with the current system. "Everything has a location" is just another way of saying that, with the current system, users are forced to specify certain kinds of metadata on file creation: filename and directory path. It's easy to imagine that tools working in a DB filesystem might force the user to specify certain kinds of metadata on creation.
Starting a new project? In the current system, you'd navigate to a certain directory so that new files would be created there by default. In a DB system, you'd change the "Project Name" tag in your editor so that new files would get tagged in that project by default. And what if you forget to change the tag name? Well, what if you forget to create the file in the right place? The problems between the two domains are strikingly similar.
If you'd stop being so pig-headed, you might see that the current system is already metadata based, but basically only one kind of tag matters (directory location). It is easy to generalize to seeing how useful it would be when you could have as many tags as you wanted.
And no collection of folders can duplicate this ease of use and flexibility no matter how crazy you make them.
Actually you can in Linux (or any system with symlinks), if you want to put the effort in. Put all of the files in one directory. Then create seperate directories for major information categories like "decade," "genre," or "artist," with subdirectories for sections of the category like "1980s," "New Age," or "Kenny G." Inside those subdirectories, add symlinks to the files that match.
Pretty simply idea, but it would probably be a lot of tedious work to keep everything nice. On the plus side, though, you can add new categories whenever you want. You aren't limited to what ID3 tags make available.
It's pretty easy to find. Rub your finger along the upper side of the vaginal wall. A couple inches up, you should feel a rougher area, like very small corrugations. That's the spot you're looking for, although different women have different sensitivities to it, so finding it may or may not mean much to yours.
I admit, I didn't read your second post, nor did I notice it was made by the same user. I wasn't offended by your comments. Trolling is more than just trying to offend. The subtle trolls try to subvert the discussion by posting reasonable sounding comments that do not really add to the conversation. That's why I thought you were trolling. You could rightly label my comment as a troll since it was even further from the discussion, but I didn't mean it as a one. As yours wasn't meant so either, you have my apologies.
I would contend that it's much easier to move from functional to procedural than the other way. Witness the teeming masses of procedural programmers that end up saying, "Well I tried looking into some of that functional stuff because it sounded interesting, but it's just too weird. I can't get my head around it." I know some very bright programmers who have a lot of difficulty with the functional style because they're so used to procedural.
In contrast, I think anyone could pick up procedural programming if they had already learned a different type. It's basically just typing out instructions for the computer to perform. And I'm not a functional programmer trying to disparage the procedural method. I've been programming in C++ and Perl for years and only recently started feeling comfortable with Haskell.
I think the biggest disadvantage to teaching functional first is that functional languages usually have more features to offer than procedural languages, so it can be a bit frustrating sometimes moving in that direction.
I thought you might also be interested to know that even if you had originally licensed the code under the GPL, he wouldn't have had to give his modifications back to you. He only has to provide the source to those he distributes it to. So he could have taken your code, changed it a bit, and sold it for a tidey sum to some company. You'd never even hear about it unless that company decided to distribute it for some reason. The GPL's goal is to protect end-users, not whiney developers.
The BSD license only sucks if you care what others do with your code. If you just wrote it to be useful, it's actually better because it's more likely to be used.
I'm not trying to disparage you. If you want to force others to share, that's fine. But not everyone has that opinion.
The goal when using the GPL is to ensure that your code is never going to go proprietary and the basic freedoms taken away.
No, that isn't the goal of the GPL. Released code can never "go proprietary." If you write some code and release it, even if someone else uses it, your code is still available, regardless of what they do with it. Even if they release a proprietary product based on it, your code, the code you wrote and released, is still available. It is ready for anyone to use.
I just fucking dont want anyone to restrict people access to my own code.
No one can, once it is released, regardless of which license you use. They only way they could is if they hunted down every copy of the code that someone had made and deleted it. Do you think that is likely to happen? Because unless they do that, your own code is still available to anyone.
The GPL does restrict the freedoms of people who use your code. If you think it doesn't, you're wrong. Those people have less choices about what they can do with it than if it were under the BSD license. It's perfectly fine to want that. The whole reason licenses exist is to restrict freedoms. But you should know what the GPL is actually for, instead of just parrotting what you read on Slashdot.
You're thinking about the phrase "your code" differently than your parent intended. What he's saying is that even if some company comes and takes your code and "included it wholesale," that would not have any affect on the code that you wrote. Your code is still available, just as you wrote it, for anyone to use. The company would not be depriving anyone of using your code. They have not restricted its freedom because it is still available.
You just fire up your favorite bittorrent client and point it at the torrent you want to seed. That's it. Just leave the client running, and it will keep seeding forever.
Slashdot Mirror
One of my fears is that with the new handling speed the bananas will be too green to eat and I will have to buy them two days early.
Just put them in a brown paper bag overnight. That'll ripen them up real quick.
Besides having door guards like the other poster mentioned, you could combat that kind of thing with scanners all around the store. It would look pretty suspicious if expensive items started dropping off the security scanners where ever you were walking.
Have you ever seen those non-cashier scanning stations and new grocery stores? You don't need a cashier to count change or swipe cards. And since scanning would be so much easier, you could probably have one person that oversees 15 or 20 scanning stations, instead of the 5 or 6 they do now. You don't need a person at each station just to change receipt rolls.
Nine reasons to use aptitude instead of apt-get or dselect.
But then you suffer a performance hit going through some motions that work very well on filesystems but poorly on databases
I'm not sure whether you mean low-level operations like file space allocation or user-level operations like searching for and using files, but I don't think it's true in either case. A database filesystem could be optimized at the low-level as much as current filesystems. User-level operations could be seen as slower if you were trying to perform them in the same way, but the methodology of interacting with files would change. So we'd get a new set of operations that would be just as fast, or faster for many things.
Instead of declaring me pig-headed for not wanting to go to Oracle to store all my files, why not come over here and admit filesystems with metadata enhancemnets are just specialized databases that already do everything you want with just a little more effort.
Because I don't agree with that view. You're too stuck on this idea of location. Files don't need a location. That's a byproduct of the operational semantics that were chosen so long ago. A file hierarchy is just a kind of relation, something that a relational database filesystem could represent if you wanted it. But there are other kinds of relations that can't be represented by a hierarchical system. Relations that could by very useful, but that no one has thought of because we're stuck thinking that files need "locations".
I'm not trying to argue that this would be better or even as good as a database filesystem. I like the idea of well-designed database filesystem. I was merely pointing out a contradiction to your claim that "no collection of folders can duplicate this ease of use and flexibility no matter how crazy you make them." You could argue that it falls down on the "ease of use" criteria, but it would be pretty easy to make a tool that creates the directories and symlinks for you, according to your categorizations. On the other hand, searching the symlink maze wouldn't be quite as powerful as being able to write full SQL queries, so I can't really argue that it fulfills the flexibility criteria.
Don't be fooled, however, about the effort required. The amount of effort for adding the metadata is about the same under either system. Even if the database filesystem can handle the metadata automatically (I'm not sure what you meant by that), you still need to add it manually. The computer can't tell that the picture you just uploaded from your camera is of a bunch of wildflowers. So there would be tools to add metadata, and the tools could, to the user, behave identically for either system. The only difference would be that under one system, rows are added to a database, and under the other, directories and symlinks are created.
Aren't highways still around?
As on off-topic aside, the comment to which you responded has mixed two separate phrases. One is "going the way of the dodo," meaning extinct. The second is "hitting the highway," meaning getting on its way, out of your life.
You see, in my example the blob of data in your file system NEVER was in the proper backup set because you didn't tag it right.
This seems to be your main sticking point: that users will not want to tag files when they are created, so the whole system is worthless. However, you aren't seeing the similarity with the current system. "Everything has a location" is just another way of saying that, with the current system, users are forced to specify certain kinds of metadata on file creation: filename and directory path. It's easy to imagine that tools working in a DB filesystem might force the user to specify certain kinds of metadata on creation.
Starting a new project? In the current system, you'd navigate to a certain directory so that new files would be created there by default. In a DB system, you'd change the "Project Name" tag in your editor so that new files would get tagged in that project by default. And what if you forget to change the tag name? Well, what if you forget to create the file in the right place? The problems between the two domains are strikingly similar.
If you'd stop being so pig-headed, you might see that the current system is already metadata based, but basically only one kind of tag matters (directory location). It is easy to generalize to seeing how useful it would be when you could have as many tags as you wanted.
And no collection of folders can duplicate this ease of use and flexibility no matter how crazy you make them.
Actually you can in Linux (or any system with symlinks), if you want to put the effort in. Put all of the files in one directory. Then create seperate directories for major information categories like "decade," "genre," or "artist," with subdirectories for sections of the category like "1980s," "New Age," or "Kenny G." Inside those subdirectories, add symlinks to the files that match.
Pretty simply idea, but it would probably be a lot of tedious work to keep everything nice. On the plus side, though, you can add new categories whenever you want. You aren't limited to what ID3 tags make available.
Project Gutenberg has audio books for download in MP3 format. Currently only 31 are read by a human, but they do have over 350 that sound like they were read by a Speak & Spell.
It's pretty easy to find. Rub your finger along the upper side of the vaginal wall. A couple inches up, you should feel a rougher area, like very small corrugations. That's the spot you're looking for, although different women have different sensitivities to it, so finding it may or may not mean much to yours.
I admit, I didn't read your second post, nor did I notice it was made by the same user. I wasn't offended by your comments. Trolling is more than just trying to offend. The subtle trolls try to subvert the discussion by posting reasonable sounding comments that do not really add to the conversation. That's why I thought you were trolling. You could rightly label my comment as a troll since it was even further from the discussion, but I didn't mean it as a one. As yours wasn't meant so either, you have my apologies.
Again, well done. You truly live up to your username.
I would contend that it's much easier to move from functional to procedural than the other way. Witness the teeming masses of procedural programmers that end up saying, "Well I tried looking into some of that functional stuff because it sounded interesting, but it's just too weird. I can't get my head around it." I know some very bright programmers who have a lot of difficulty with the functional style because they're so used to procedural.
In contrast, I think anyone could pick up procedural programming if they had already learned a different type. It's basically just typing out instructions for the computer to perform. And I'm not a functional programmer trying to disparage the procedural method. I've been programming in C++ and Perl for years and only recently started feeling comfortable with Haskell.
I think the biggest disadvantage to teaching functional first is that functional languages usually have more features to offer than procedural languages, so it can be a bit frustrating sometimes moving in that direction.
Why isn't the portal not ready for prime time yet?
It already is not ready.
I'm not that new here.
Using this guy's data and interpolating, looks like your uid was created about about 8 days ago. I'd say that's pretty new.
I thought you might also be interested to know that even if you had originally licensed the code under the GPL, he wouldn't have had to give his modifications back to you. He only has to provide the source to those he distributes it to. So he could have taken your code, changed it a bit, and sold it for a tidey sum to some company. You'd never even hear about it unless that company decided to distribute it for some reason. The GPL's goal is to protect end-users, not whiney developers.
The BSD license only sucks if you care what others do with your code. If you just wrote it to be useful, it's actually better because it's more likely to be used.
I'm not trying to disparage you. If you want to force others to share, that's fine. But not everyone has that opinion.
The goal when using the GPL is to ensure that your code is never going to go proprietary and the basic freedoms taken away.
No, that isn't the goal of the GPL. Released code can never "go proprietary." If you write some code and release it, even if someone else uses it, your code is still available, regardless of what they do with it. Even if they release a proprietary product based on it, your code, the code you wrote and released, is still available. It is ready for anyone to use.
I just fucking dont want anyone to restrict people access to my own code.
No one can, once it is released, regardless of which license you use. They only way they could is if they hunted down every copy of the code that someone had made and deleted it. Do you think that is likely to happen? Because unless they do that, your own code is still available to anyone.
The GPL does restrict the freedoms of people who use your code. If you think it doesn't, you're wrong. Those people have less choices about what they can do with it than if it were under the BSD license. It's perfectly fine to want that. The whole reason licenses exist is to restrict freedoms. But you should know what the GPL is actually for, instead of just parrotting what you read on Slashdot.
... and the whole thing is then proprietary.
You're thinking about the phrase "your code" differently than your parent intended. What he's saying is that even if some company comes and takes your code and "included it wholesale," that would not have any affect on the code that you wrote. Your code is still available, just as you wrote it, for anyone to use. The company would not be depriving anyone of using your code. They have not restricted its freedom because it is still available.
Well, using this guy's data and extrapolating, uid 707389 was probably created around late August 2003. Your uid is only about a year older.
Anyway, two years is a pretty long time. And Slashdot has gotten markedly worse in those two years.
You just fire up your favorite bittorrent client and point it at the torrent you want to seed. That's it. Just leave the client running, and it will keep seeding forever.
By the way, the word is illogical.
In total points we ended up loosing.
You're certainly not getting any points for spelling.
Too bad ravens are wireless.