I would think creative ways of packing information into less bandwidth would count as "innovation" as much as anything else.
Re:Mortgage points and auto loan 'doc prep fees'
on
Add-Ons Add Up
·
· Score: 3, Informative
I think he means that if you did not pay that point, and instead put the money in a bank, and used the interest to pay off some of your loan, the remaining payment would be like the interest rate was 1/8 of a percent less.
This sounds like the assumption is that the saved money will be invested at a 12.5% return, which sounds a little high, but I may be wrong with how the math works.
That explains why all the customer service lines want you to punch in your account ID, but for some reason once you finally reach a person they have no idea who you are (you would think this info should come up on a screen in front of them to save expensive customer-support time). This explains why they collect and then seemingly ignore the infomation. Scary indeed.
1. If you want to draw in a particular color you have to know the exact pixel layout of the display. And if it is not TrueColor you have to do a number of calls to allocate colors in a colormap and you cannot do this efficiently without making a copy of the colormap in your own memory that you continuously update to match the system. Any request for a new color in a colormapped system requires a round-trip to the server.
2. If you have an rgb image in memory it requires several pages of code to display it on an arbitrary X display. You need to encode it into the display format, and you have to do error diffusion for reasonable display on an 8-bit screen. If you want to use shared memory to speed it up you have to write 2 copies of your code with subtle differences so you can work when the shm extension is missing (any intelligent design would have made the shm work right away for the old calls).
3. It is impossible to locate a font that the user wants without enumerating every single one of them and doing your own comparison to find the closest match. Despite the fact that the font engines can now do arbitrary scaling, the interface makes it nearly impossible to access it.
4. Xft, like shm, requires you to use entirely new calls to draw text. Sure the new calls might be better, but they should have made the old calls work as well. Embarrasingly enough, MicroSoft made *their* old non-antialiased calls work. This is a good sign that the internals are a mess.
5. All calls require odd combinations of display, screen, root window, colormap, visual, visualid, and gc structures to work. An intelligent design would only take a "gc" and everything else would be set in it. An even better design would be like OpenGL where you get rid of the "context" argument entirely, this is why OpenGL code ports between toolkits and even to Windows, while no toolkit allows a programmer to draw using raw Xlib.
6. There are many many other things but I am tired of typing now.
I think you will find a lot more people complaining about the X protocol than about XFree86.
I do think what is needed is a new complete rewrite of the Xlib/Xprotocol layer to be modern. I do not like the fact that they keep adding calls or user-level libraries to make up for X's lame graphics capabilities. A clean lower level would be much easier to understand and debug.
The existing X interface can be emulated atop it. Most people would be happy with just an emulation Xlib that talks to the server by translating the old calls to the new ones. It does not have to be accurate (for instance it could tell the program 32-bit TrueColor no matter what the hardware does, and I'm sure the fonts will be named all different and be UTF-8 only, and it will not run any existing window managers. But this would allow you to run your old programs on the new system.
It may also be necessary to make an "XServer" for remote programs to talk to in X-protocol. This could be an independent program that translates the protocol to the new system. Without this you could not run programs from other machines that think they are running old X. This is not so important however.
I do not think a replacement for X will be successful without an Xlib emulator. This does not really preclude any design ideas. Even people who want widgets in the server (an idea I don't like, but there are arguments for it) will certainly provide the ability to create a blank window-sized "widget" and for a program to detect where the mouse is clicked and draw arbitrary graphics. X programs can use this for emulation. Yea, it won't look like the spiffy new widgets but at least the old programs work, which is really all that is needed.
All these systems have to realize how important Xlib emulation is needed and must work on it immidiately so that it is available the first day their system is available for use. Otherwise they will fail.
Also it is quite possible that X can suck in it's own ways even though a low-level protocol is a good idea. The fact that X is bad does not prove that every single part of it's design is bad.
First, plenty of toolits are on Windows. I recieve about 10 times more interest from Windows programmers who do not even know how to run a file from a command line for fltk than I get from Linux users. Also you can easily tell that virtually all large graphics systems and some of MicroSoft's own work (Word, for instance) do not use their "toolkit".
Also if X had been a "toolkit" like you seem to want, it would have been the Athena toolkit that existed in 1984. I'm sure the fact that everything is drawn in two colors (black & white, which a "configuration" that reversed them) would have been deeply engrained into it. There would also be those lovely scrollbars where only the middle mouse button did what you expected.
Fortunately this did not happen. All of X's mistakes are because the graphics were designed in 1984 (or earlier, really). But oddly enough bad graphics *can* emulate stuff that was not imagined 20 years later, so X is still working. Bad toolkits cannot do anything.
Someday there may be a replacement for "buttons" and "menus" and "icons" that is far more user friendly (no, I don't know what, if I did I would be writing it!) and when that happens the people who wrote toolkits into the system are going to look as stupid and backward as the people who wrote record-management into the disk file systems.
What is needed is for the people who can to stop doing the easy and "fun" part of writing "toolkits" (I know, as I am also a toolkit author) and start doing the HARD stuff, like drawing an arbitrary transformation of an image with error diffusion, something we have known how to do since about 1987 but for some reason is not in any of the graphics systems even today. Drawing every single character in UTF-8 with a single call that takes a string would also be nice.
If the problem was PhotoShop and fonts, then people would all be using Macs, or have no trouble going from Windows to Macs.
Also the "WM" is completely different than what does the fonts. Part of the problem with Linux is that too many things do the fonts, but the Window Manager is one of the things that does NOT do fonts. You probably mean the X server, though a plausable solution to fonts is to make most of the work (and all of the potential problems) in a user-level library and not in the server.
Actually the preview could be a short segment from the middle, with low quality. Mostly to be able to recognize the piece of music so you are sure it is the one you want, but otherwise not of any use. They could even grant the right to send the short segment to anybody else for free, so if you are talking with email to somebody about music, you could say "you mean this one [segment]? I found it on the EMI site, here is the URL" and maybe your friend would go and pay a buck to get the song.
Such preview samples would probably greatly increase their sales.
The watermarks are there to make a reliable way for a computer program to search for copyrighted data on the internet. There is no need for them them be different.
Most likely they would not go after Joe Sixpack. They would instead go after the services that are distributing the copies. They could provide a free service that tells if a piece of information is copyrighted (after a significant delay so it is not a good way to detect if a watermark was removed) and thus claim that they have provided an easy and reliable way for services to detect and reject copyrighted material.
You can't use watermarks to prevent playback. The problem is that it gives the cracker a simple test to see if they removed the watermark. They *will* be stripped then, there is absolutly no way to prevent it.
Watermarks would be useful if they identified the original source of the data but could not be detected by anything the consumer has access to. If copyrighted data appears in wide distribution, they can identify the original source. Prosecuting that person is probably not a good idea, but it will identify the type of hardware or software that leaked the data. And the threat of prosecution may reduce the incentive to pirate.
Although they don't have to, a reasonable business model would allow the usage to work a lot like CD's. Anybody who has a your copy can do something with the site and get a key to play it on their own player. No questions asked, except a given copy can only have a new key made every few days. This would pretty much allow you to play it on your friend's CD (and also to give them a copy, but so what) but would make mass distribution of copies impossible.
I think a lot of the ideas sound like they would work. However I strongly believe this will fail and be cracked unless they imbed it in closed hardware and reveal enough of the interface that Linux drivers can be written. This removes a lot of the cracking incentive (anger that something works on Windows and not on Linux is a far bigger motivation for development than anything else) and also helps to prove that their system is really secure and not just relying on obscurity.
Yes, this is something that the hardware/software manufacturers need to realize. But actually such self-contained cards could be put into PC's as well and they would really make DRM work.
If the DVD card in the PC acted much more like a DVD player and simply put the image on the screen (perhaps with an analog signal between the card and the graphics card), and the interface to the card was much more like the interface between a DVD player's remote control and the player, there would be no DVD cracks. First of all, complete documentation required for a Linux driver would not make the data any more vulnerable. Leaked source for the Windows driver would not make the data any more vulnerable. Reverse engineering the Windows driver would not make the data any more vulnerable. The ability to write a Linux driver that matched the capabilities of the Windows driver would have removed about 90% of the incentive that actual good engineers have to crack the encryption.
The problem is that hardware manufacturers are cheap and will put stuff in software if they can. Also MicroSoft strongly encourages this to force lockin to their systems. Also unscrupulous hardware manufactures insist on getting the secret information for writing this software, they could sell it at considerable profit to real pirates who make money duplicating disks.
The way around it is for the DRM consortium to get together and manufacture a closed decoding and playback chip. Do not reveal enough information that it is possible for anybody to play a disk without using the chip. Make the chip so it cannot be instructed to do anything you don't want it to do. Because of mass-production for all consumer devices as well as PC cards, there will be no incentive to try to make a software solution. And absolulely totally document the entire interface to the chip so that Linux drivers are allowed, if you fear to do this then you have made a mistake in your design and it *WILL* be cracked.
It is not impossible. Add watermarks that do not stop playback (and thus remove any incentive to remove them, and more importantly removes the ability for anybody to test if they removed them). These watermarks can then be used to locate and identify copyrighted data on the internet and then use the already-existing laws to go after the people who are distributing this copyrighted content. Also make free and easy-to-use data-sharing networks that refuse watermarked data (with a long delay before accepting or refusing data so it cannot be used as a practical test for whether the watermark has been removed).
Re:When will they learn?
on
Film Gimp
·
· Score: 2
No such restrictions are what make many licenses not "free" according to the FSF, so in no way would RMS ever consider this.
Re:Open source gives studios a headache
on
Film Gimp
·
· Score: 2
the last thing you want is legal liablity because some Joe stuck some patented or copywritten code into the module you use on the movie
I don't see what you are talking about. At worse "Joe" would be in trouble, and it sure does not matter whether he was writing open source or working for a proprietary company. The movie company can escape blame in either case by being unaware that any copyright was being violated, at worst they will be unable to use that module in any future movies.
If Hollywood is using Open Source, that means that the MPAA can't push for content restrictions that affect Open Source without compromising the tools (and money flow) of the Hollywood folks that the MPAA is supposed to represent.
No, they can easily push for content restrictions that affect open source but *don't* compromise the tools they use (which are a *subset* of all the open source projects). For instance, if the new Harry Potter DVD could only be played with WMP on WinXP, it would not harm them if a special effects company could not use that DVD as a source for images for compositing on their Linux systems (or on their Windows systems, for that matter). In fact they may like this, since that keeps the images from being used in another film. However if they hire a company working on the next Harry Potter film, they will certainly provide the source images in a format that the company can use.
Another way of looking at it is that the fanciest and most powerful video processing hardware and software is incapable of decoding DirectTV. Yet that does not make it useless for editing stuff that will appear on DirectTV.
Re:You don't suppose the "viral" GPL plays here
on
Film Gimp
·
· Score: 2
In case you are not just making a joke, the use of a GPL tool in no way requires the product to be GPL. Even if it did, only the "source code" is required, so I guess the script would be available for anybody who wants to "compile" into a movie by filming their own version.
I can see lots of reasons for there to be a spelling corrector in user level programs, but I still fail to see any logical argument for putting a small subset of it into the kernel, especially when it complicates or makes impossible many hashing algorithims that a filesystem would like to use, and can allow more security bugs.
A filesystem should assign no more meaning to the bytes used to name a file than it should assign to the bytes stored in the file. Therefore case-insensitivity, or encoding matches, or anything other than strict equality of the bits for identifying a file is wrong.
I do not consider "avoiding confusion" a legitimate argument. If "avoiding confusion" was a requirement for file systems then they would not allow files with different numbers of spaces in them, or substitue '1' for 'l' or 'O' for '0', or spell words incorrectly. In fact the filesystem would have to have a full AI to weigh new filenames against existing ones and decide if they are sufficiently close, and also decide whether the old or new name is correct. Now this may be a good idea, but anybody who proposes that that be in the disk driver rather than a user-level library would be laughed out of geek school. For that reason I also think that case-insensitivity is much better as a user-level library.
If Linux is to succeed on the desktop, they have to show some initiative and design some NEW things, not copy stupid cheap "solutions" that Windows or Mac have done. How about a "save as" dialog box that includes the nice error-correction and matching that the newer shells have? That would completely eliminate any need for "case insensitive" and be much more useful for avoiding confusing filenames.
I agree that filename extensions are evil. They are a kludgey version of a "type attribute" that is designed to be stored on systems without such attributes, but I also think an attribute like that is evil as well, unless it is just a cached result. The real solution is to use things like the Unix "file" command to find out what the data is (you then cache this in a file attribute if the command is too slow). This is the only solution that is really user friendly, the result survives any transmission of the data through the net or email or any other system, and allows the user to rename the files.
1. Well I challenge you to tell grandma to differentiate "readme", "read me", "readme" or "read me " (note extra spaces), or to differentiate "one" and "1", or any of a million other things that Windows/Mac file systems will happily store as different files. This is not an argument whatsoever and anybody who thinks this is an argument for case-insensitivity is an idiot.
It makes spelling correction more difficult mostly by discouraging it's use and making it impossible to write powerful algorithims that can weigh case-sensitivity against other possible corrections. Try it some day if you don't believe me.
"Case insensitivity" is a user interface issue that should not be in the innards of the operating system. If a file system can treat a filename as a sequence of bytes that have no other meaning, then it can be written to be far more reliable, secure, and dependable, and easier to prove that there are no bugs.
For the "average user" case means nothing. Grandma picks files by clicking on the little pictures and would never notice if many files had the same name. The *ONLY* use for "case insensitive" is for CLI interfaces, and it is amazing that the same people who say "Unix sucks because of case sensitive filenames" are the same ones that say "it sucks because you have to use the CLI". Hey, if you don't need a CLI, you have eliminated the only reason for case insensitive filenames! Not only that, case insensitivity actually interferes with user-friendliness in a CLI as it makes it more difficult to do really advanced things in the user program, such as spelling correction of filenames.
GUI libs should completely remove the ability for an application to request that one of its windows be raised and brought to the foreground since, anyhow, window mangement is the responsibility of... window managers.
I disagree with this. First, it won't work. What actually is being delayed is not the "raise" of the window, but the creation of the window. I suppose you could have an "active app" and only raise that, but even then there is a problem in that the creation of the app could be delayed. Unless you say that all new windows appear below the focus window always there is no way to solve it.
Also, I actually am a big proponent of ONLY allowing programs to raise themselves, and focus should only change by a program doing a "set the focus to this window" call. This would get rid of the "click raises" behavior that makes overlapping windows useless (a program could instead raise only if the user clicks on an area that does nothing else). It would also get rid of the need for child windows, hieraarchies, window type flags, and all the other complexities that have come up because programs have the need to instruct the window manager what windows they want to not be buried and where the input focus could go. So therefore I certainly don't want the apps to be unable to raise themselves.
What I meant was that newer CD drives would be available that read all the bits off the disk, including the error correction bits, and return them to the computer. This would allow a program to analyze them. There may be drives that do this but I have never seen that mentioned here so it would seem not.
As I understand it, all the TOC schemes can be defeated with current hardware, which I believe the programs you are talking about are now doing. But the errors in the music are not fixable unless they are all read. Of course a program can analyze the data and remove what it thinks are the errors, but this is not as nice as being able to reproduce what an analog CD does.
Slashdot Mirror
I would think creative ways of packing information into less bandwidth would count as "innovation" as much as anything else.
This sounds like the assumption is that the saved money will be invested at a 12.5% return, which sounds a little high, but I may be wrong with how the math works.
That explains why all the customer service lines want you to punch in your account ID, but for some reason once you finally reach a person they have no idea who you are (you would think this info should come up on a screen in front of them to save expensive customer-support time). This explains why they collect and then seemingly ignore the infomation. Scary indeed.
1. If you want to draw in a particular color you have to know the exact pixel layout of the display. And if it is not TrueColor you have to do a number of calls to allocate colors in a colormap and you cannot do this efficiently without making a copy of the colormap in your own memory that you continuously update to match the system. Any request for a new color in a colormapped system requires a round-trip to the server.
2. If you have an rgb image in memory it requires several pages of code to display it on an arbitrary X display. You need to encode it into the display format, and you have to do error diffusion for reasonable display on an 8-bit screen. If you want to use shared memory to speed it up you have to write 2 copies of your code with subtle differences so you can work when the shm extension is missing (any intelligent design would have made the shm work right away for the old calls).
3. It is impossible to locate a font that the user wants without enumerating every single one of them and doing your own comparison to find the closest match. Despite the fact that the font engines can now do arbitrary scaling, the interface makes it nearly impossible to access it.
4. Xft, like shm, requires you to use entirely new calls to draw text. Sure the new calls might be better, but they should have made the old calls work as well. Embarrasingly enough, MicroSoft made *their* old non-antialiased calls work. This is a good sign that the internals are a mess.
5. All calls require odd combinations of display, screen, root window, colormap, visual, visualid, and gc structures to work. An intelligent design would only take a "gc" and everything else would be set in it. An even better design would be like OpenGL where you get rid of the "context" argument entirely, this is why OpenGL code ports between toolkits and even to Windows, while no toolkit allows a programmer to draw using raw Xlib.
6. There are many many other things but I am tired of typing now.
I agree. One of the few posters here who seems to know what is going on and what needs to be done.
I do think what is needed is a new complete rewrite of the Xlib/Xprotocol layer to be modern. I do not like the fact that they keep adding calls or user-level libraries to make up for X's lame graphics capabilities. A clean lower level would be much easier to understand and debug.
The existing X interface can be emulated atop it. Most people would be happy with just an emulation Xlib that talks to the server by translating the old calls to the new ones. It does not have to be accurate (for instance it could tell the program 32-bit TrueColor no matter what the hardware does, and I'm sure the fonts will be named all different and be UTF-8 only, and it will not run any existing window managers. But this would allow you to run your old programs on the new system.
It may also be necessary to make an "XServer" for remote programs to talk to in X-protocol. This could be an independent program that translates the protocol to the new system. Without this you could not run programs from other machines that think they are running old X. This is not so important however.
I do not think a replacement for X will be successful without an Xlib emulator. This does not really preclude any design ideas. Even people who want widgets in the server (an idea I don't like, but there are arguments for it) will certainly provide the ability to create a blank window-sized "widget" and for a program to detect where the mouse is clicked and draw arbitrary graphics. X programs can use this for emulation. Yea, it won't look like the spiffy new widgets but at least the old programs work, which is really all that is needed.
All these systems have to realize how important Xlib emulation is needed and must work on it immidiately so that it is available the first day their system is available for use. Otherwise they will fail.
Also it is quite possible that X can suck in it's own ways even though a low-level protocol is a good idea. The fact that X is bad does not prove that every single part of it's design is bad.
First, plenty of toolits are on Windows. I recieve about 10 times more interest from Windows programmers who do not even know how to run a file from a command line for fltk than I get from Linux users. Also you can easily tell that virtually all large graphics systems and some of MicroSoft's own work (Word, for instance) do not use their "toolkit".
Also if X had been a "toolkit" like you seem to want, it would have been the Athena toolkit that existed in 1984. I'm sure the fact that everything is drawn in two colors (black & white, which a "configuration" that reversed them) would have been deeply engrained into it. There would also be those lovely scrollbars where only the middle mouse button did what you expected.
Fortunately this did not happen. All of X's mistakes are because the graphics were designed in 1984 (or earlier, really). But oddly enough bad graphics *can* emulate stuff that was not imagined 20 years later, so X is still working. Bad toolkits cannot do anything.
Someday there may be a replacement for "buttons" and "menus" and "icons" that is far more user friendly (no, I don't know what, if I did I would be writing it!) and when that happens the people who wrote toolkits into the system are going to look as stupid and backward as the people who wrote record-management into the disk file systems.
What is needed is for the people who can to stop doing the easy and "fun" part of writing "toolkits" (I know, as I am also a toolkit author) and start doing the HARD stuff, like drawing an arbitrary transformation of an image with error diffusion, something we have known how to do since about 1987 but for some reason is not in any of the graphics systems even today. Drawing every single character in UTF-8 with a single call that takes a string would also be nice.
Also the "WM" is completely different than what does the fonts. Part of the problem with Linux is that too many things do the fonts, but the Window Manager is one of the things that does NOT do fonts. You probably mean the X server, though a plausable solution to fonts is to make most of the work (and all of the potential problems) in a user-level library and not in the server.
First he looks both ways to check if any cars are coming.
How does a computer programmer cross a road?
First he looks to check if there is a road.
Such preview samples would probably greatly increase their sales.
Most likely they would not go after Joe Sixpack. They would instead go after the services that are distributing the copies. They could provide a free service that tells if a piece of information is copyrighted (after a significant delay so it is not a good way to detect if a watermark was removed) and thus claim that they have provided an easy and reliable way for services to detect and reject copyrighted material.
Watermarks would be useful if they identified the original source of the data but could not be detected by anything the consumer has access to. If copyrighted data appears in wide distribution, they can identify the original source. Prosecuting that person is probably not a good idea, but it will identify the type of hardware or software that leaked the data. And the threat of prosecution may reduce the incentive to pirate.
I think a lot of the ideas sound like they would work. However I strongly believe this will fail and be cracked unless they imbed it in closed hardware and reveal enough of the interface that Linux drivers can be written. This removes a lot of the cracking incentive (anger that something works on Windows and not on Linux is a far bigger motivation for development than anything else) and also helps to prove that their system is really secure and not just relying on obscurity.
If the DVD card in the PC acted much more like a DVD player and simply put the image on the screen (perhaps with an analog signal between the card and the graphics card), and the interface to the card was much more like the interface between a DVD player's remote control and the player, there would be no DVD cracks. First of all, complete documentation required for a Linux driver would not make the data any more vulnerable. Leaked source for the Windows driver would not make the data any more vulnerable. Reverse engineering the Windows driver would not make the data any more vulnerable. The ability to write a Linux driver that matched the capabilities of the Windows driver would have removed about 90% of the incentive that actual good engineers have to crack the encryption.
The problem is that hardware manufacturers are cheap and will put stuff in software if they can. Also MicroSoft strongly encourages this to force lockin to their systems. Also unscrupulous hardware manufactures insist on getting the secret information for writing this software, they could sell it at considerable profit to real pirates who make money duplicating disks.
The way around it is for the DRM consortium to get together and manufacture a closed decoding and playback chip. Do not reveal enough information that it is possible for anybody to play a disk without using the chip. Make the chip so it cannot be instructed to do anything you don't want it to do. Because of mass-production for all consumer devices as well as PC cards, there will be no incentive to try to make a software solution. And absolulely totally document the entire interface to the chip so that Linux drivers are allowed, if you fear to do this then you have made a mistake in your design and it *WILL* be cracked.
It is not impossible. Add watermarks that do not stop playback (and thus remove any incentive to remove them, and more importantly removes the ability for anybody to test if they removed them). These watermarks can then be used to locate and identify copyrighted data on the internet and then use the already-existing laws to go after the people who are distributing this copyrighted content. Also make free and easy-to-use data-sharing networks that refuse watermarked data (with a long delay before accepting or refusing data so it cannot be used as a practical test for whether the watermark has been removed).
No such restrictions are what make many licenses not "free" according to the FSF, so in no way would RMS ever consider this.
I don't see what you are talking about. At worse "Joe" would be in trouble, and it sure does not matter whether he was writing open source or working for a proprietary company. The movie company can escape blame in either case by being unaware that any copyright was being violated, at worst they will be unable to use that module in any future movies.
No, they can easily push for content restrictions that affect open source but *don't* compromise the tools they use (which are a *subset* of all the open source projects). For instance, if the new Harry Potter DVD could only be played with WMP on WinXP, it would not harm them if a special effects company could not use that DVD as a source for images for compositing on their Linux systems (or on their Windows systems, for that matter). In fact they may like this, since that keeps the images from being used in another film. However if they hire a company working on the next Harry Potter film, they will certainly provide the source images in a format that the company can use.
Another way of looking at it is that the fanciest and most powerful video processing hardware and software is incapable of decoding DirectTV. Yet that does not make it useless for editing stuff that will appear on DirectTV.
In case you are not just making a joke, the use of a GPL tool in no way requires the product to be GPL. Even if it did, only the "source code" is required, so I guess the script would be available for anybody who wants to "compile" into a movie by filming their own version.
I can see lots of reasons for there to be a spelling corrector in user level programs, but I still fail to see any logical argument for putting a small subset of it into the kernel, especially when it complicates or makes impossible many hashing algorithims that a filesystem would like to use, and can allow more security bugs.
A filesystem should assign no more meaning to the bytes used to name a file than it should assign to the bytes stored in the file. Therefore case-insensitivity, or encoding matches, or anything other than strict equality of the bits for identifying a file is wrong.
If Linux is to succeed on the desktop, they have to show some initiative and design some NEW things, not copy stupid cheap "solutions" that Windows or Mac have done. How about a "save as" dialog box that includes the nice error-correction and matching that the newer shells have? That would completely eliminate any need for "case insensitive" and be much more useful for avoiding confusing filenames.
I agree that filename extensions are evil. They are a kludgey version of a "type attribute" that is designed to be stored on systems without such attributes, but I also think an attribute like that is evil as well, unless it is just a cached result. The real solution is to use things like the Unix "file" command to find out what the data is (you then cache this in a file attribute if the command is too slow). This is the only solution that is really user friendly, the result survives any transmission of the data through the net or email or any other system, and allows the user to rename the files.
It makes spelling correction more difficult mostly by discouraging it's use and making it impossible to write powerful algorithims that can weigh case-sensitivity against other possible corrections. Try it some day if you don't believe me.
For the "average user" case means nothing. Grandma picks files by clicking on the little pictures and would never notice if many files had the same name. The *ONLY* use for "case insensitive" is for CLI interfaces, and it is amazing that the same people who say "Unix sucks because of case sensitive filenames" are the same ones that say "it sucks because you have to use the CLI". Hey, if you don't need a CLI, you have eliminated the only reason for case insensitive filenames! Not only that, case insensitivity actually interferes with user-friendliness in a CLI as it makes it more difficult to do really advanced things in the user program, such as spelling correction of filenames.
I disagree with this. First, it won't work. What actually is being delayed is not the "raise" of the window, but the creation of the window. I suppose you could have an "active app" and only raise that, but even then there is a problem in that the creation of the app could be delayed. Unless you say that all new windows appear below the focus window always there is no way to solve it.
Also, I actually am a big proponent of ONLY allowing programs to raise themselves, and focus should only change by a program doing a "set the focus to this window" call. This would get rid of the "click raises" behavior that makes overlapping windows useless (a program could instead raise only if the user clicks on an area that does nothing else). It would also get rid of the need for child windows, hieraarchies, window type flags, and all the other complexities that have come up because programs have the need to instruct the window manager what windows they want to not be buried and where the input focus could go. So therefore I certainly don't want the apps to be unable to raise themselves.
As I understand it, all the TOC schemes can be defeated with current hardware, which I believe the programs you are talking about are now doing. But the errors in the music are not fixable unless they are all read. Of course a program can analyze the data and remove what it thinks are the errors, but this is not as nice as being able to reproduce what an analog CD does.