Apple's gone further than that -- Apple provides almost everything between the microphone and your speakers. most music is produced on Mac's, much of it mixed and mastered using Apple software Logic. And with iTMS it's sold and distributed using Mac's, for playback on Mac's and iPod's. That's how the entire process can work so smoothly -- Apple's integrated the entire process. It's somewhat breathtaking when you realize how long Apple's been putting the pieces together for this one.
Now think about what's next.:-)
"AAC the format may have DRM but AAC the songs available from the iTMS have ZERO DRM turned on. Basically it's MP3 with a different compression scheme enabled. You can freely trade the AAC files from iTMS if you want. Whether this will still be true after the larger PC rollout I do not know, maybe Apple trusts their loyal fans more than the great unwashed."
This is incorrect. When you buy music from iTMS, it's encoded using AAC, and DRM protected using a technology Apple calls FairPlay. Admittedly it's a pretty simple/easy to live with DRM system, but one of the few things it does prevent is freely trading the Protected AAC files downloaded from iTMS.
I remember attending one of Apple's World Wide Developer Conferences and getting in a bit of a fight (many years ago) about the need for a 'headless' consumer Macintosh. Their argument then was that Apple could provide an all-in-one system for a lower cost than buying a CPU and monitor separately, because there would only be one power supply, simplified cabling, etc. I'm not sure that this is still the case...
Worked just fine on the Apollo workstations, back in the 80's. Really, it's just the same as keeping database records consistent when multiple applications are accessing the database at once.
Be careful about what you're saying here. It's true that the subpoena process bypasses the courts in giving the RIAA accused people's real names and contact information. But that does not mean that they've been convicted -- it just means that RIAA knows who to sue. The accused person still gets to defend themselves in court.
I'm not sure how I feel about digital media, p2p file sharing, etc., but this sort of goofy thinking doesn't do anyone any good. Or perhaps I've been had by a troll...
"The RIAA is now sending subpoenas and notice of lawsuits to citizens throughout the United States, and these citizens will have to defend their innocence in a court of law, rather than the plaintiff backing up their accusations with incontrovertible evidence.
The RIAA is making an accusation that would lead to a trial that would determine guilt or innocence (or a settlement). This is pretty much the same as anyone who files a lawsuit; they argue that the defendent is guilty, and the defendent argues that they're innocent, and a judge and/or jury decide who's right.
"2. John has a slow computer, but an MP3 player and wants to listen to his music under Fair Use Rights, upheld through case law in the courts. "Ripping" said music takes longer than downloading it off his high-speed internet. He downloads the music he has a legal license for."
It has never been upheld in court that fair use allows you to download music. The one relevant case I can think of specifically stated that a music download service that claimed only to be allowing people to download music that they own wasn't legal...
"3. John gets picked up on some type of scanner that the RIAA has on the Internet."
They're only scanning for sharing. It's pretty well established that actively sharing your music collection out to the internet is illegal. It's not accidental -- no computer comes with file sharing software magically running -- anyone running KaZaA, etc., installed and ran it on purpose and is broadcasting the contents of their hard drives to the whole internet. Hopefully only a 'shared' folder, but sometimes people share their entire hard drive, which can be kinda entertaining...
"4. John gets served with a copyright infringement lawsuit, ending up paying countless dollars in legal fees to prove that he had the CD, and the fair use rights to the intellectual property contained on the media."
It doesn't matter that much whether John owns the music or not; I don't think that any amount of money would prove that "fair use" allows John to actively advertise and serve their music to the internet. Even if he had the "right" to download music because he owned the CD (which hasn't been established, and is pretty unlikely) it's pretty clear that he doesn't have the right to broadcast that music to everyone else.
'If I leave my car unlocked in a bad neighborhood, does that make me a felon if my car gets stolen?'
Running file sharing software isn't equivalent to leaving a car unlocked. Perhaps your analogy should be "If I left my car unlocked in a bad neighborhood, and put thousands of posters all over town advertising that, who can I blame when it gets stolen?"
"If I own a store, and someone shoplifts from me, does that make me the shoplifter?" You mean "If I I put someone else's property out onto the street and encourage people to take it, does that make me a shoplifter?" Of course not, but it does make you a thief.
Of course, drawing analogies between physical goods and bits is a bit strained, so I wouldn't take these analogies too far.
"Are the cable and satellite TV companies getting sued when someone commits Theft of Service?"
Nope, the people who steal the service get sued. So do people advertising devices specifically designed to allow you to steal encrypted TV signals, and people re-selling cable TV service illegally. Your point?
"Then why are the people hosting files on the Internet getting sued for having files available for download?" Because they're advertising and serving those files to anyone on the planet, giving away other people's property to anyone who asks.
Actually, we're better off ignoring the car analogies, and going to something closer, like books. How about "If I buy a book and start publishing copies and give them away, does that make me a criminal?" The answer is yes.
While I agree with your pragmatic point that you should keep info that you need in the contents of files rather than just in metadata, because metadata-oblivious operating systems could lose it, it would be a shame if that issue kept operating systems from implementing richer metadata. Luckily, given that MS is adding 'rich metadata' to their next OS, perhaps we'll evolve past the limtations of the 70's...:-)
Well, HFS has nice metadata (and it's still in Extended HFS in MacOS X!) but it's not dynamic -- you find files by looking in directories, rather than by asking the OS for things that match criteria.
To illustrate, in BFS you can see new email by asking the OS for things that are of type email that have the attribute unread=true, and get back files containing email messages, with each email message having metadata for sender, receiver, subject, date, etc. The dynamic part is that there's no 'email folder' -- it's all just a database query, and if any other application created new email files, they'd immediately appear in the window with your other new email.
In HFS, you could have a file for each email message, and store the metadata in the resource fork. But you couldn't use the metadata to find the file. NTFS has a vaguely similar metadata capability, but nobody uses it.
First, I deal with objects as objects, not as text strings. That is. I don't write code to parse a text file, or re-write the text file if data has changed. That eliminates tons of persistence code that I usually have to write. So not only do I write way less code to do the same work, but the application runs faster (no wasted time serializing/deserializing all of the data).
Second, I deal with the information as a structured database (object database, not relational), rather than as a bitstream. So, for example, I can say 'given me all appointments for next wednesday' and get back objects. And I can update one object and since it's persistent it's automatically stored. I don't need to write code to manage 'dirty bits', or append to files, or whatever. Again, my app is simpler, and runs faster.
Thirdly, in a PDA it makes more sense. If I were using files, I'd have to have two copies of my data (one in the 'filesystem' and one loaded into the 'application'). In the NewtonOS, all data was stored in persistent memory (SRAM, Flash RAM) so I could work with it directly without having to 'load' any files into 'memory'.
Fourth, there's a consistency of access. All address book entries are objects of a particular type, so any application can manipulate the address book. Since everything is an object, there are no proprietary file formats to parse, etc. (though of course you could implement your own private classes if you want to). The result is that applications largely manipulate shared data stores.
Yes, you could implement all of this over 'files' but at that point you aren't using files any more, you're using a high level object-oriented API (which is how things should be) that happens to use files for persistence . That's a good thing, but shouldn't that sort of capability be provided by the operating system so that everything can interoperate, rather than having a custom, incompatible persistent layer for every application on your computer?
"And how does that meta data gets to the db? Oh, right, it will rely on file extensions and other hacks:)"
Like it has in MacOS for 20 years -- when applications write files, they tell the OS the filetype. The only time MacOS looks at extensions is if it's dealing with files transferred from operating systems that don't have relevant metadata. Unfortunately, that would be nearly every other OS.:-) But if Linux started transferring filetype metadata that would be a nice step in the right direction.
The idea isn't that you'd manually put in metadata for files, but that applications would use filesystem metadata instead of internal data stores. So your photo organizer would store title, date/timestamp, etc., as filesystem metadata so that it could be used outside the photo organizer. (Note: there's tons of metadata captured automatically by digital cameras; it's just not accessible outside of a photo organizer app) Or, an example that the Be folks used, your email program could store each mail message as a file with metadata for date, sender, subject, etc. So to see all email sent to you by "bob" by opening a window in your file browser and telling it to show you things of type "email" with sender "bob". And as more email came in (an asynchronous process that just writes files to the filesystem) it's immediately appear in the window. Amazingly cool.
I disagree, strongly. Files are an artifact of a bunch of bad implementation decisions when stripping Multics down to produce UNIX. What programmers want to be able to do is manipulate data structures and store them persistently. What files force you to do is waste tons of time writing code to take your data structures and write them out as sequences of bytes and read them back in.
One OS that solved this nicely was NewtonOS. If you wanted to manipulate persistently stored data you opened a "soup" that contained objects. So if you wanted to, say, set up an appointment with someone for lunch, you could find the person in the address book "soup" and then create an entry in the databook "soup" recording the appointment, which would immediately appear in all other apps that dealt with appointments (because app's accessed the same data structures, and were notified of changes so that they could update). So your data was not trapped in a particular application's proprietary format, and users weren't forced to learn the artificial concept of a "file" but instead could think about "my appointments" or "my address book".
If you haven't tried it, don't knock it. As a developer, and as a user, it was wonderful -- much more straightforward than "files" and "directories".
Actually, Be had two flavors of "filesystem as database" in widespread deployment. OK, not as widespread as Windows, but certainly thousands of users. The first version of Be's filesystem, by Benoit Schillings, was very database like, but performance was so-so. The second version of BeFS, by Dominic Giampaolo, was less general in implementation, but had the same metadata-driven capabilities. There's an interesting article on this at http://www.theregus.com/content/4/24485.html. Basically, Be did everything that this project is talking about, years ago. That's not to take anything away from the project -- it's cool if more mainstream operating systems catch up to the innovations of niche players, because more people benefit. Dominic is working at Apple, so there's hope that MacOS X's filesystem will start incorporating the rich-metadata, dynamic view model of the world. And while MS has (I think) pushed the "filesystem as database" out of the next version of Windows NT/XP/whatever, it's still planned for the next version after that, so perhaps in a deade or so we'll all be able to do what Be did back in '91. And of course, Palm owns the Be code, so perhaps PalmOS will lead the way?
It's not good enough to have the computerized voting machines print out a receipt, because there's no guarantee that the vote that is printed out is the same as the vote that is recorded digitally.
The only way to guarantee that the vote is to have the votes counted by actually reading them from the physical vote.
Rather than touchscreens, etc., the best solution I've seen is to use the (much less expensive, and widely used) optical mark readers. People vote using well understood technology (a pencil making marks on paper), the votes are immediately tallied or rejected, and rejected votes can easily be corrected (correct and rescan the ballot). And it's trivial to store the ballots, and pull them out and re-scan for a recount, or to do a manual audit of the system.
I have no idea why anyone is purchasing systems that are far more expensive, impossible to audit (or trust), and completely unproven in the field.
Actually, this has been done before. Back when I worked at Thinking Machines, the CM-5 had an entire network devoted to detecting hardware failures and remapping the CPU's. It was way cool -- every chip had a self-test and an a connection to the test network, and if there was a failure the OS would swap the task on that CPU to another CPU and the router would map all communications so that the new CPU looked just like the old one. Some of the compute jobs that people run on supercomputers are _huge_ (some run for months) making it very important that errors are handled properly. The machine could also swap all RAM to disk absurdly quickly, so you could checkpoint your calculations so that if there was a complete system failure (e.g. power) you could pick up from the last checkpoint instead of starting from the beginning.
Perhaps it's true that 'And only an idiot would put "Ripped by laird" in the ID3 tag' but fairly often people do sign their RIP's with a handle of some sort. I'm not sure why, since it's not like RIPping a CD is an amazing technical feat...
I don't disagree that it's *possible* for different people to RIP the same track and get exactly the same MP3 file. My point is that because of the issues people have pointed out here, you can't assume that all RIP's of the same track, even with the same settings and pulling the ID3 tags from CDDN, will generate identical files. Other posters in this thread have even documented that they've ripped a track twice in a row with the same software, same drive, same CD and the same computer have generated different MP3's. Because of this, if you see two collections of music with many files that are bit-for-bit identical, it's a good indicator that the files were copied, not all generated independently.
Actually, because of variations been CD's (error that the drive automatically recovers from) and between CD drives (sensitivity to errors, recovery algorithms, etc.), even ripping the sale CD with the exact same settings will usually result in slightly (inaudibly) different files. Even ripping the same CD with the same drive two times in a row can result in different files. Thus, different MD5 checksums. So a matching MD5 hash is a pretty good indicator of a file being a copy. Hundreds of matching MD5's between two file collections is a very good indicator of file copying.
There are already quite extensive infrastructures in place to allow game companies to spend effort only on the the 'content' instead of the engine. The result hasn't been 'cookie cutter games' -- if you look at all of the games using the Quake engine, for example, they have different stories, graphics, characters, AI, etc., even though they use the same graphics and AI engine.
I don't see the raw software development being the issue with the costs going up. It's going to be the sheer cost of producing larger worlds with more characters, more graphics, more motion capture, more behavioral interaction,... all stuff that you can't buy anywhere, because it's all by definition unique to your game.
But nobody says that the point of a PS3 is to have larger worlds with more stuff (though I am sure that Final Fantasy whatever-the-next-number-is will be cool). It could also be used to create very interesting little worlds, where you put your energy into great gameplay and AI rather than sheer volume of content.
Look at amplitude. It's a great online multiplayer music game with cool graphics, lots of fun to play, and certainly didn't cost $10M to develop.
Personally, I'd love to see an accurate swordfighting simulator. I fenced (foil, sabre, epee) for years, and I've never seen any videogame even remotely close to a simulation of the subtlety of what you do when you're using a real sword (extend, wait for the opponent to parry, disengage, replace and lunge!).
The ten commandments are clearly not the basis for the US legal system, which is why referring to the Bible in court won't get you anywhere. US law is based on the Constitution, which doesn't mention religion at all except to make sure that the government doesn't have any. The judge in Alabama is just trying to score points with Christians who don't know US history, or who think that promoting christianity is more important than upholding the Constitution. I'd hoped that people had outgrown that sort of primitive tribal thinking, but I guess it takes some people a little longer to catch on...
The point isn't that the file was originally traded on Napster in particular, but that the file didn't originate on the defendent's computer but was copied there (illegally).
It's true that two different people could generate RIP's of the same track with the same MD5 hash, but the odds are low: they'd have to use exactly the same encoding settings, and enter exactly the same ID3 tags with exactly the same values. (Counterpoints: they could be default settings, and CDDB/Gracenote metadata, which would improve the odds a bit) And since we're talking about large music collections, the exact matching would have to have to happen across hundreds of tracks. And if the ID3 tags had notes like "ripped by so-and-so" that'd kinda blow the case. So while it's certainly true that MD5 hashes don't completely uniquely identify a particular RIP of a track, I think that when compared for large numbers of files, it'd be a pretty good indicator of file copying.
While we're wandering off-topic, I should point out that most of the "founding fathers" were in fact not Christians, but were mainly Deists or Unitarians, who believe in an impersonal "Providence" but not the divinity of Jesus or the literal interpretation of the Bible.
It was during John Adam's administration that the Senate ratified the Treaty of Peace and Friendship, which states in Article XI that "the government of the United States of America is not in any sense founded on the Christian Religion."
These founding fathers were a reflection of the American population. Having escaped from the state-established religions of Europe, only 7% of the people in the 13 colonies belonged to a church when the Declaration of Independence was signed.
For more such fun, check out http://www.dimensional.com/~randl/founders.htm and http://www.postfun.com/worbois.html.
Anyway, the point is that the judge in Alabama has no idea what he's talking about. Since the country wasn't founded by Christians, it's pretty hard to argue that Christianity (and the ten commandments) formed the basis for our legal system.
While it's a good idea to run the same hardware/OS in staging and production to minimize risks, there are many situations where mixed platforms make sense. For example, when deploying J2EE applications, most of the best IDE's are typically available for NT (let's not start a religious war, please), but you'd never want to run a production environment on NT. One of the nice things about J2EE is that in practice Java server applications really are quite portable between operating systems.
And for non-Java applications, developing on Linux and deploying on Solaris works quite well, too (and saves a ton of money). Of course, you need a Sun to to some staging testing, but that's cheap compared to putting Sun's on every engineer's desktop.
It depends on the kind of engineering you're doing. There's a shortage of CAD packages for the Mac, for example, but with MacOS X, most of the major UNIX engineering packages have been ported to MacOS X -- the vendors see it as a dramatically easier way to get to the non-UNIX desktop market than doing an NT port. Some examples:
You can find a good catalog of Mac app's at http://guide.apple.com/. A quick search turned up ArchiCAD, CADintosh, DesignWorks (circuit design/schematics), MacSchema, PowerCADD, VectorWorks, B2Spice (circuit emulator),... you get the idea. Probably not as wide a range as for Wintel, but they've certainly got their fans (i.e. people using them to make a living).
Slashdot Mirror
Apple's gone further than that -- Apple provides almost everything between the microphone and your speakers. most music is produced on Mac's, much of it mixed and mastered using Apple software Logic. And with iTMS it's sold and distributed using Mac's, for playback on Mac's and iPod's. That's how the entire process can work so smoothly -- Apple's integrated the entire process. It's somewhat breathtaking when you realize how long Apple's been putting the pieces together for this one. Now think about what's next. :-)
"AAC the format may have DRM but AAC the songs available from the iTMS have ZERO DRM turned on. Basically it's MP3 with a different compression scheme enabled. You can freely trade the AAC files from iTMS if you want. Whether this will still be true after the larger PC rollout I do not know, maybe Apple trusts their loyal fans more than the great unwashed."
This is incorrect. When you buy music from iTMS, it's encoded using AAC, and DRM protected using a technology Apple calls FairPlay. Admittedly it's a pretty simple/easy to live with DRM system, but one of the few things it does prevent is freely trading the Protected AAC files downloaded from iTMS.
I remember attending one of Apple's World Wide Developer Conferences and getting in a bit of a fight (many years ago) about the need for a 'headless' consumer Macintosh. Their argument then was that Apple could provide an all-in-one system for a lower cost than buying a CPU and monitor separately, because there would only be one power supply, simplified cabling, etc. I'm not sure that this is still the case...
Worked just fine on the Apollo workstations, back in the 80's. Really, it's just the same as keeping database records consistent when multiple applications are accessing the database at once.
Be careful about what you're saying here. It's true that the subpoena process bypasses the courts in giving the RIAA accused people's real names and contact information. But that does not mean that they've been convicted -- it just means that RIAA knows who to sue. The accused person still gets to defend themselves in court.
I'm not sure how I feel about digital media, p2p file sharing, etc., but this sort of goofy thinking doesn't do anyone any good. Or perhaps I've been had by a troll...
"The RIAA is now sending subpoenas and notice of lawsuits to citizens throughout the United States, and these citizens will have to defend their innocence in a court of law, rather than the plaintiff backing up their accusations with incontrovertible evidence.
The RIAA is making an accusation that would lead to a trial that would determine guilt or innocence (or a settlement). This is pretty much the same as anyone who files a lawsuit; they argue that the defendent is guilty, and the defendent argues that they're innocent, and a judge and/or jury decide who's right.
"2. John has a slow computer, but an MP3 player and wants to listen to his music under Fair Use Rights, upheld through case law in the courts. "Ripping" said music takes longer than downloading it off his high-speed internet. He downloads the music he has a legal license for."
It has never been upheld in court that fair use allows you to download music. The one relevant case I can think of specifically stated that a music download service that claimed only to be allowing people to download music that they own wasn't legal...
"3. John gets picked up on some type of scanner that the RIAA has on the Internet."
They're only scanning for sharing. It's pretty well established that actively sharing your music collection out to the internet is illegal. It's not accidental -- no computer comes with file sharing software magically running -- anyone running KaZaA, etc., installed and ran it on purpose and is broadcasting the contents of their hard drives to the whole internet. Hopefully only a 'shared' folder, but sometimes people share their entire hard drive, which can be kinda entertaining...
"4. John gets served with a copyright infringement lawsuit, ending up paying countless dollars in legal fees to prove that he had the CD, and the fair use rights to the intellectual property contained on the media."
It doesn't matter that much whether John owns the music or not; I don't think that any amount of money would prove that "fair use" allows John to actively advertise and serve their music to the internet. Even if he had the "right" to download music because he owned the CD (which hasn't been established, and is pretty unlikely) it's pretty clear that he doesn't have the right to broadcast that music to everyone else.
'If I leave my car unlocked in a bad neighborhood, does that make me a felon if my car gets stolen?'
Running file sharing software isn't equivalent to leaving a car unlocked. Perhaps your analogy should be "If I left my car unlocked in a bad neighborhood, and put thousands of posters all over town advertising that, who can I blame when it gets stolen?"
"If I own a store, and someone shoplifts from me, does that make me the shoplifter?" You mean "If I I put someone else's property out onto the street and encourage people to take it, does that make me a shoplifter?" Of course not, but it does make you a thief.
Of course, drawing analogies between physical goods and bits is a bit strained, so I wouldn't take these analogies too far.
"Are the cable and satellite TV companies getting sued when someone commits Theft of Service?"
Nope, the people who steal the service get sued. So do people advertising devices specifically designed to allow you to steal encrypted TV signals, and people re-selling cable TV service illegally. Your point?
"Then why are the people hosting files on the Internet getting sued for having files available for download?" Because they're advertising and serving those files to anyone on the planet, giving away other people's property to anyone who asks.
Actually, we're better off ignoring the car analogies, and going to something closer, like books. How about "If I buy a book and start publishing copies and give them away, does that make me a criminal?" The answer is yes.
While I agree with your pragmatic point that you should keep info that you need in the contents of files rather than just in metadata, because metadata-oblivious operating systems could lose it, it would be a shame if that issue kept operating systems from implementing richer metadata. Luckily, given that MS is adding 'rich metadata' to their next OS, perhaps we'll evolve past the limtations of the 70's... :-)
Well, HFS has nice metadata (and it's still in Extended HFS in MacOS X!) but it's not dynamic -- you find files by looking in directories, rather than by asking the OS for things that match criteria.
To illustrate, in BFS you can see new email by asking the OS for things that are of type email that have the attribute unread=true, and get back files containing email messages, with each email message having metadata for sender, receiver, subject, date, etc. The dynamic part is that there's no 'email folder' -- it's all just a database query, and if any other application created new email files, they'd immediately appear in the window with your other new email.
In HFS, you could have a file for each email message, and store the metadata in the resource fork. But you couldn't use the metadata to find the file. NTFS has a vaguely similar metadata capability, but nobody uses it.
Several big differences:
First, I deal with objects as objects, not as text strings. That is. I don't write code to parse a text file, or re-write the text file if data has changed. That eliminates tons of persistence code that I usually have to write. So not only do I write way less code to do the same work, but the application runs faster (no wasted time serializing/deserializing all of the data).
Second, I deal with the information as a structured database (object database, not relational), rather than as a bitstream. So, for example, I can say 'given me all appointments for next wednesday' and get back objects. And I can update one object and since it's persistent it's automatically stored. I don't need to write code to manage 'dirty bits', or append to files, or whatever. Again, my app is simpler, and runs faster.
Thirdly, in a PDA it makes more sense. If I were using files, I'd have to have two copies of my data (one in the 'filesystem' and one loaded into the 'application'). In the NewtonOS, all data was stored in persistent memory (SRAM, Flash RAM) so I could work with it directly without having to 'load' any files into 'memory'.
Fourth, there's a consistency of access. All address book entries are objects of a particular type, so any application can manipulate the address book. Since everything is an object, there are no proprietary file formats to parse, etc. (though of course you could implement your own private classes if you want to). The result is that applications largely manipulate shared data stores.
Yes, you could implement all of this over 'files' but at that point you aren't using files any more, you're using a high level object-oriented API (which is how things should be) that happens to use files for persistence . That's a good thing, but shouldn't that sort of capability be provided by the operating system so that everything can interoperate, rather than having a custom, incompatible persistent layer for every application on your computer?
"And how does that meta data gets to the db? Oh, right, it will rely on file extensions and other hacks :)"
:-) But if Linux started transferring filetype metadata that would be a nice step in the right direction.
Like it has in MacOS for 20 years -- when applications write files, they tell the OS the filetype. The only time MacOS looks at extensions is if it's dealing with files transferred from operating systems that don't have relevant metadata. Unfortunately, that would be nearly every other OS.
The idea isn't that you'd manually put in metadata for files, but that applications would use filesystem metadata instead of internal data stores. So your photo organizer would store title, date/timestamp, etc., as filesystem metadata so that it could be used outside the photo organizer. (Note: there's tons of metadata captured automatically by digital cameras; it's just not accessible outside of a photo organizer app) Or, an example that the Be folks used, your email program could store each mail message as a file with metadata for date, sender, subject, etc. So to see all email sent to you by "bob" by opening a window in your file browser and telling it to show you things of type "email" with sender "bob". And as more email came in (an asynchronous process that just writes files to the filesystem) it's immediately appear in the window. Amazingly cool.
I disagree, strongly. Files are an artifact of a bunch of bad implementation decisions when stripping Multics down to produce UNIX. What programmers want to be able to do is manipulate data structures and store them persistently. What files force you to do is waste tons of time writing code to take your data structures and write them out as sequences of bytes and read them back in.
One OS that solved this nicely was NewtonOS. If you wanted to manipulate persistently stored data you opened a "soup" that contained objects. So if you wanted to, say, set up an appointment with someone for lunch, you could find the person in the address book "soup" and then create an entry in the databook "soup" recording the appointment, which would immediately appear in all other apps that dealt with appointments (because app's accessed the same data structures, and were notified of changes so that they could update). So your data was not trapped in a particular application's proprietary format, and users weren't forced to learn the artificial concept of a "file" but instead could think about "my appointments" or "my address book".
If you haven't tried it, don't knock it. As a developer, and as a user, it was wonderful -- much more straightforward than "files" and "directories".
Actually, Be had two flavors of "filesystem as database" in widespread deployment. OK, not as widespread as Windows, but certainly thousands of users. The first version of Be's filesystem, by Benoit Schillings, was very database like, but performance was so-so. The second version of BeFS, by Dominic Giampaolo, was less general in implementation, but had the same metadata-driven capabilities. There's an interesting article on this at http://www.theregus.com/content/4/24485.html. Basically, Be did everything that this project is talking about, years ago. That's not to take anything away from the project -- it's cool if more mainstream operating systems catch up to the innovations of niche players, because more people benefit. Dominic is working at Apple, so there's hope that MacOS X's filesystem will start incorporating the rich-metadata, dynamic view model of the world. And while MS has (I think) pushed the "filesystem as database" out of the next version of Windows NT/XP/whatever, it's still planned for the next version after that, so perhaps in a deade or so we'll all be able to do what Be did back in '91. And of course, Palm owns the Be code, so perhaps PalmOS will lead the way?
It's not good enough to have the computerized voting machines print out a receipt, because there's no guarantee that the vote that is printed out is the same as the vote that is recorded digitally.
The only way to guarantee that the vote is to have the votes counted by actually reading them from the physical vote.
Rather than touchscreens, etc., the best solution I've seen is to use the (much less expensive, and widely used) optical mark readers. People vote using well understood technology (a pencil making marks on paper), the votes are immediately tallied or rejected, and rejected votes can easily be corrected (correct and rescan the ballot). And it's trivial to store the ballots, and pull them out and re-scan for a recount, or to do a manual audit of the system.
I have no idea why anyone is purchasing systems that are far more expensive, impossible to audit (or trust), and completely unproven in the field.
Actually, this has been done before. Back when I worked at Thinking Machines, the CM-5 had an entire network devoted to detecting hardware failures and remapping the CPU's. It was way cool -- every chip had a self-test and an a connection to the test network, and if there was a failure the OS would swap the task on that CPU to another CPU and the router would map all communications so that the new CPU looked just like the old one. Some of the compute jobs that people run on supercomputers are _huge_ (some run for months) making it very important that errors are handled properly. The machine could also swap all RAM to disk absurdly quickly, so you could checkpoint your calculations so that if there was a complete system failure (e.g. power) you could pick up from the last checkpoint instead of starting from the beginning.
Perhaps it's true that 'And only an idiot would put "Ripped by laird" in the ID3 tag' but fairly often people do sign their RIP's with a handle of some sort. I'm not sure why, since it's not like RIPping a CD is an amazing technical feat...
I don't disagree that it's *possible* for different people to RIP the same track and get exactly the same MP3 file. My point is that because of the issues people have pointed out here, you can't assume that all RIP's of the same track, even with the same settings and pulling the ID3 tags from CDDN, will generate identical files. Other posters in this thread have even documented that they've ripped a track twice in a row with the same software, same drive, same CD and the same computer have generated different MP3's. Because of this, if you see two collections of music with many files that are bit-for-bit identical, it's a good indicator that the files were copied, not all generated independently.
Actually, because of variations been CD's (error that the drive automatically recovers from) and between CD drives (sensitivity to errors, recovery algorithms, etc.), even ripping the sale CD with the exact same settings will usually result in slightly (inaudibly) different files. Even ripping the same CD with the same drive two times in a row can result in different files. Thus, different MD5 checksums. So a matching MD5 hash is a pretty good indicator of a file being a copy. Hundreds of matching MD5's between two file collections is a very good indicator of file copying.
There are already quite extensive infrastructures in place to allow game companies to spend effort only on the the 'content' instead of the engine. The result hasn't been 'cookie cutter games' -- if you look at all of the games using the Quake engine, for example, they have different stories, graphics, characters, AI, etc., even though they use the same graphics and AI engine.
... all stuff that you can't buy anywhere, because it's all by definition unique to your game.
I don't see the raw software development being the issue with the costs going up. It's going to be the sheer cost of producing larger worlds with more characters, more graphics, more motion capture, more behavioral interaction,
But nobody says that the point of a PS3 is to have larger worlds with more stuff (though I am sure that Final Fantasy whatever-the-next-number-is will be cool). It could also be used to create very interesting little worlds, where you put your energy into great gameplay and AI rather than sheer volume of content.
Look at amplitude. It's a great online multiplayer music game with cool graphics, lots of fun to play, and certainly didn't cost $10M to develop.
Personally, I'd love to see an accurate swordfighting simulator. I fenced (foil, sabre, epee) for years, and I've never seen any videogame even remotely close to a simulation of the subtlety of what you do when you're using a real sword (extend, wait for the opponent to parry, disengage, replace and lunge!).
The ten commandments are clearly not the basis for the US legal system, which is why referring to the Bible in court won't get you anywhere. US law is based on the Constitution, which doesn't mention religion at all except to make sure that the government doesn't have any. The judge in Alabama is just trying to score points with Christians who don't know US history, or who think that promoting christianity is more important than upholding the Constitution. I'd hoped that people had outgrown that sort of primitive tribal thinking, but I guess it takes some people a little longer to catch on...
The point isn't that the file was originally traded on Napster in particular, but that the file didn't originate on the defendent's computer but was copied there (illegally).
It's true that two different people could generate RIP's of the same track with the same MD5 hash, but the odds are low: they'd have to use exactly the same encoding settings, and enter exactly the same ID3 tags with exactly the same values. (Counterpoints: they could be default settings, and CDDB/Gracenote metadata, which would improve the odds a bit) And since we're talking about large music collections, the exact matching would have to have to happen across hundreds of tracks. And if the ID3 tags had notes like "ripped by so-and-so" that'd kinda blow the case. So while it's certainly true that MD5 hashes don't completely uniquely identify a particular RIP of a track, I think that when compared for large numbers of files, it'd be a pretty good indicator of file copying.
While we're wandering off-topic, I should point out that most of the "founding fathers" were in fact not Christians, but were mainly Deists or Unitarians, who believe in an impersonal "Providence" but not the divinity of Jesus or the literal interpretation of the Bible.
It was during John Adam's administration that the Senate ratified the Treaty of Peace and Friendship, which states in Article XI that "the government of the United States of America is not in any sense founded on the Christian Religion."
These founding fathers were a reflection of the American population. Having escaped from the state-established religions of Europe, only 7% of the people in the 13 colonies belonged to a church when the Declaration of Independence was signed.
For more such fun, check out http://www.dimensional.com/~randl/founders.htm and http://www.postfun.com/worbois.html.
Anyway, the point is that the judge in Alabama has no idea what he's talking about. Since the country wasn't founded by Christians, it's pretty hard to argue that Christianity (and the ten commandments) formed the basis for our legal system.
While it's a good idea to run the same hardware/OS in staging and production to minimize risks, there are many situations where mixed platforms make sense. For example, when deploying J2EE applications, most of the best IDE's are typically available for NT (let's not start a religious war, please), but you'd never want to run a production environment on NT. One of the nice things about J2EE is that in practice Java server applications really are quite portable between operating systems.
And for non-Java applications, developing on Linux and deploying on Solaris works quite well, too (and saves a ton of money). Of course, you need a Sun to to some staging testing, but that's cheap compared to putting Sun's on every engineer's desktop.
It depends on the kind of engineering you're doing. There's a shortage of CAD packages for the Mac, for example, but with MacOS X, most of the major UNIX engineering packages have been ported to MacOS X -- the vendors see it as a dramatically easier way to get to the non-UNIX desktop market than doing an NT port. Some examples:
... you get the idea. Probably not as wide a range as for Wintel, but they've certainly got their fans (i.e. people using them to make a living).
You can find a good catalog of Mac app's at http://guide.apple.com/. A quick search turned up ArchiCAD, CADintosh, DesignWorks (circuit design/schematics), MacSchema, PowerCADD, VectorWorks, B2Spice (circuit emulator),