Again by my personal example....I would have to copy over the contents of at least 60 full 700 MB backup CDs, reinstall XP Pro, run Windows Update, reinstall all my other programs from source CDs, hunt Kaaza and websites for stuff that I don't have discs for anymore, hunt down registration codes for installations I could re-download, and restore+update an 8 gig Linux partition with at least a year's worth of tweaks.
(my emphasis)
That will get your system wiped again, most likely before you even finished installing.:-)
At mach 3, won't the doppler effect change the frequency of the radio signal so such a degree that the receiever won't be able to communicate with the rocket?
Not 100% accurate. In Java, you can get the valus of private members, and call private methods. However, it is possible to install a security manager that prevents this (which is what the applet sandbox does, for example).
I think you got your currency conversion wrong somewhere... Either that or the US prices for GPRS are absurd. You're telling me that you're paying 1000 USD per MB? I'm sorry, not even the US could have those kinds of prices.
I have a very expensive GPRS subscription, and my price is approximately 0.01 USD (that's one cent) per KB.
I mostly agree with the original poster, but I do not think the filenames need to be forced to be UTF-8 by the kernel. The kernel/filesystem should enforce that they be strings of bytes where no byte is equal to zero or '/' and that the same string of bytes is not used more than once in a directory. This is easy enough to get right.
So what you're saying is that you like it the way it is?:-)
You are disagreeing with the Unicode consortium on this. And I have to agree that I'm leaning toward joining your stance on this.
All I did was to point out that there is a thought behind this, good or not.
I'd suggest that you get involved and lobby to get different runic styles included. I'm not so sure that they have a lot of people using runic with unicode. Perhaps they just made an uniformed descision?
Actually, set your locale to de_DE.UTF-8 (or just de_DE if you like legacy:-) ) and "ls" will print the files using natural language ordering (i.e. case-insignificant, according to german sorting rules).
Similar complaints has been raised with regards to the Chinese, Japanese and Korean characters which are unified in Unicode.
The idea is that Unicde encodes characters and not glyphs. The same character may have different glyphs, for example the difference between traditional and simplified chinese. It has spawned a lot of controvercy, and personally I can understand both sides of the argument. But this is the way it works in Unicode, and I don't see anyone else coming up with a better suggestion on a standard character encoding scheme.
I'd say that probably exactly the same reasoning lies behind the codification of the runic characters.
It already sort of works this way. All my file names are already UTF-8. But yeah, it would be nice if the kernel enforced it (or used (wchar_t *) for path names).
The point of my post was that the file system runs in the kernel, and you don't want to encumber the kernel with all of this.
Also, since differentiating wether two files are the same or not would be locale-dependent, I fail to see how the kernel could handle this in a consistent manner. The black-magic performed by windows to handle it is insane, and very non-intuitive to a speaker of any language except english.
No they shouldn't. Plain and simple. Case-insensitivity has no business in a file system.
Allow me to expand a little on why this is the case:
Case-insensitivity is a complicated business as soon as you leave the simple domain of the english language, and this is the reason you usually only head english-speaking people wanting case-insensitive file systems.
An example: German has a letter ß, which in upper case becomes SS. tchüß -> TCHÜSS. Now, when lowercasing, you can't just map SS to ß, instead it becomes ss. I.e. TCHÜSS -> tschüss.
Do you start to realise the implications this has on a case-insensitive file system? (the question to answer is: is "tchüß" and "tschüss" considered to be the same file?)
It gets worse. In french, as spoken in france, the letter ë is converted to uppercase E. I.e. citroën -> CITROEN. But in Canadian french, it becomes Ë. I.e. citroën -> CITROËN.
When you start to bring in other languages, for example the Japanese full-with and half-width latin characters it starts to get really messy.
In order to handle all of this in a case-insensitive file system the file system itself needs not only to be aware of the intricate details of character encodings and casing for different languages, every single file system operation would also have to look at the currently selected locale in order to determine wether two names are equivalent or not. If you believe this is simple, read the FAQ's at the Unicode site and you will never again suggest that the file system should be case-insignificant.
However, making a user application work independently of case in file names is a reasonable idea. However, it would have to be specified by the UI framework, for example Gnome. I'm not sure exactly if that idea would work at all since I haven't given it much thought.
I'm so happy the Unix file system is case-significant.
If it's price that gets you so upset, I recommend you take a look at SAP DB. It's a proper database, strong enough to run SAP R/3 (which should, to anyone that knows about R/3, be enough proof it's enterprise capable) and it's GPL'ed.
It does take a little bit more time to learn than PostgreSQL, which would be the other GPL'ed alternative, but it's easier than Oracle and needs much less (if any) maintenance.
Deutche Post runs their R/3 system on it, and it's a huge system.
We have this already. And have had for quite some time. It was invented with Multics, and Linux makes it available using the system call mmap(). Look it up, you might like it.:-)
Keeping two systems consistent (esp at different locations with slow (i.e. slower than disc busses) is probably more expensive than biting the bullet and spend the cash you need to get reasonable performance with discs.
Slashdot Mirror
It hasn't stopped them so far. :-)
That will get your system wiped again, most likely before you even finished installing. :-)
What on earth made you believe that "benefits for the customer" is of any onterest to the producers?
Isn't this what we always wanted?
It will happen! Remember the Star Trek phasers? One again Star Trek proves that it's more than a tv show. It's a time machine!
It's still enough to change the frequency. Quite possibly enought to prevent a receiever from locking on to the signal.
At mach 3, won't the doppler effect change the frequency of the radio signal so such a degree that the receiever won't be able to communicate with the rocket?
Not 100% accurate. In Java, you can get the valus of private members, and call private methods. However, it is possible to install a security manager that prevents this (which is what the applet sandbox does, for example).
[1] Nowhere near 1 USD/KB though.
I think you got your currency conversion wrong somewhere... Either that or the US prices for GPRS are absurd. You're telling me that you're paying 1000 USD per MB? I'm sorry, not even the US could have those kinds of prices. I have a very expensive GPRS subscription, and my price is approximately 0.01 USD (that's one cent) per KB.
Nope, the period still sorts before the letters. Try it, you might like it. :-)
All I did was to point out that there is a thought behind this, good or not.
I'd suggest that you get involved and lobby to get different runic styles included. I'm not so sure that they have a lot of people using runic with unicode. Perhaps they just made an uniformed descision?
Actually, set your locale to de_DE.UTF-8 (or just de_DE if you like legacy :-) ) and "ls" will print the files using natural language ordering (i.e. case-insignificant, according to german sorting rules).
The idea is that Unicde encodes characters and not glyphs. The same character may have different glyphs, for example the difference between traditional and simplified chinese. It has spawned a lot of controvercy, and personally I can understand both sides of the argument. But this is the way it works in Unicode, and I don't see anyone else coming up with a better suggestion on a standard character encoding scheme.
I'd say that probably exactly the same reasoning lies behind the codification of the runic characters.
It already sort of works this way. All my file names are already UTF-8. But yeah, it would be nice if the kernel enforced it (or used (wchar_t *) for path names).
Maybe you ought to study another language? You seem to lack the frame of reference needed to actually understand what the issues are.
Also, since differentiating wether two files are the same or not would be locale-dependent, I fail to see how the kernel could handle this in a consistent manner. The black-magic performed by windows to handle it is insane, and very non-intuitive to a speaker of any language except english.
Allow me to expand a little on why this is the case:
Case-insensitivity is a complicated business as soon as you leave the simple domain of the english language, and this is the reason you usually only head english-speaking people wanting case-insensitive file systems.
An example: German has a letter ß, which in upper case becomes SS. tchüß -> TCHÜSS. Now, when lowercasing, you can't just map SS to ß, instead it becomes ss. I.e. TCHÜSS -> tschüss.
Do you start to realise the implications this has on a case-insensitive file system? (the question to answer is: is "tchüß" and "tschüss" considered to be the same file?)
It gets worse. In french, as spoken in france, the letter ë is converted to uppercase E. I.e. citroën -> CITROEN. But in Canadian french, it becomes Ë. I.e. citroën -> CITROËN.
When you start to bring in other languages, for example the Japanese full-with and half-width latin characters it starts to get really messy.
In order to handle all of this in a case-insensitive file system the file system itself needs not only to be aware of the intricate details of character encodings and casing for different languages, every single file system operation would also have to look at the currently selected locale in order to determine wether two names are equivalent or not. If you believe this is simple, read the FAQ's at the Unicode site and you will never again suggest that the file system should be case-insignificant.
However, making a user application work independently of case in file names is a reasonable idea. However, it would have to be specified by the UI framework, for example Gnome. I'm not sure exactly if that idea would work at all since I haven't given it much thought.
I'm so happy the Unix file system is case-significant.
Thanks for the clarification. I'll try to double-check better in the future.
It does take a little bit more time to learn than PostgreSQL, which would be the other GPL'ed alternative, but it's easier than Oracle and needs much less (if any) maintenance.
Deutche Post runs their R/3 system on it, and it's a huge system.
We have this already. And have had for quite some time. It was invented with Multics, and Linux makes it available using the system call mmap(). Look it up, you might like it. :-)
In fact, you can get your beloved RAM database by putting the data partition on a RAM disc, and only have the transaction log on a (mirrored) disc.
Then again, read some basic textbook on databases and see what they say about the idea. You'd be suprised.
Keeping two systems consistent (esp at different locations with slow (i.e. slower than disc busses) is probably more expensive than biting the bullet and spend the cash you need to get reasonable performance with discs.
This doesn't matter for MySQL though, since they never cared about data integrity anyway.