Yup. Biggest problems I tend to have with CSS involve its not being designed to determine the size of a block (either height or width) by the size of its content; most stuff involves specifying fixed sizes. Try determining the width of that div using the width of the smallest contained image.
Actually the problems I've had so far with CSS are documented here (1, 2 and 3.htm).
Hmm. It does rather sound like you're too lazy to specify a protocol to the browser. Just typing a bareword in there is like saying "I want orange." to the browser. Do you want a list of orange stuff, a drink of orange, the colour orange...? Doing a search doesn't seem any less intuative than going to a certain port on the host so-named...
I've been using that pronouncement for at least 15 - 20 years...
Why? Do you Americans have a secret admiration for the French and want to start speaking their language? And what's with your pronunciation of the word 'fillet', and usage of the word 'resumé' (I even had to use a very non-English accent there!) ?
Voting for Michael Howard, who would've been much more lenient and sensible, and who really did stand a chance in hell of getting elected under Britain's non-PR electoral system.
Please replace 'the sheep' with 'the MPs of the Labour party, having been called to vote on a three-line whip, despite their law being criticised by just about every other corner of society'.
Face it, democracy that allows a simple majority to implement a law sucks; it's the tyranny of the majority - and it's not even a majority of the country, it's a majority of MPs who aren't exactly representative in the first place.
Yes, but just HOW hard must they be pushed before they rise up? If it's harder than government spying illegally on citizens, kidnapping citizens for extraordinary rendition to 'extract' confessions from them, placing hundreds of people in an offshore prison where law "doesn't apply", slowly but surely removing freedom of speech (if a website promoted eg. terrorism), and promoting the rights of copyright holders to the extent that their breach is considered by law more serious than rape... then i'd say the point of rebellion is somewhat defeated.
AMD lost me here.. They need to convince me they will continue to lower prices and maintain a competitive product. At this point I'm not convince they can catch up to Intel again.. Intel has greater market share, lower costs and wider margins. AMD had opportunity, but I think they won't have it for long..
So you'll soon have the problem of there being one, uno, major PC CPU manufacturer in the market, with a barrier to entry so high it makes the Great Wall of China look like a garden fence. Much better.
I'm more interested in how they dealt with offline messaging. Yahoo (like most other IM networks) supports the nice feature of sending a message to an offline contact, having it stored on Yahoo's server and delivered to that contact when they come online. Apparently, MSN could never be bothered to do that. How do they merge those two policies?
Ah, but many people frequently swap capitalization for convenience, me included. I may want to call my file ReadThis, but on the commandline I'd like type re, then TAB. I want it to ignore capitalization when searching, and I don't want to worry about capitalization when searching, which i can't do when the FS is case-sensitive.
I disagree. Linux is DOING as well. It's imposing on me the policy that I can have two same-named files, save capitalization, in the same dir, even when I dont want it to. You can actively force something on your users by allowing stuff, too; the ability to have silly behaviour. Case-sensitive filesystems are one example. I would like Windows NOT TO OFFER the option of hiding file extensions, I'd like it NOT TO OFFER the option of using file extension to make a file executable, and NOT TO OFFER the ability to have a scripted page as a desktop too. There are some things it's sensible for an OS not to do.
Those who approve of top-down policy making will support the MS/Apple approach; those who prefer versatility and experimentation will support the unix approach. There's no logical resolution to this, as it's not a logical issue.
No, I support the latter, but I still think the underlying filesystem is far more sensibly designed if it's case-insensitive.
And OSes do impose policy decisions on you, no matter what, and it's unavoidable. It's necessary to get a sane system. They impose memory management algorithms on you, device driver framework on you, and (to some degree) licencing requirements on you; and I'm sure those are just the tip of the iceberg. The only way to avoid these 'imposed restrictions' would be to code your own operating system.
What is more, what I'm suggesting isn't forcing stuff on you, because you can change the FS that Linux uses. I am definitely saying, however, that major Linux filesystems should, by default, be case-insensitive, and all major distroes should have this setup by default, and all programmers should program with the assumption that this is the case in mind. Although it can (in very rare circumstances, two of which you specified above) be useful to have files in the same directory distinguished only by case, it's far more likely that the ability to do this will cause confusion and problems, especially for users who're new to, say, Linux.
There are *indeed* ways to get around the desire to distinguish only by case, caused by the not-silly barrier in the way of Getting The Job Done In A Rather Silly Way, that don't add to anyone sane's frustration level. Please don't ever say that there aren't again, because you'd be lying.
How about: Sonata in D major Sonata in d minor
AppleCo.htm apple.htm
Notice how you can still have case-RETENTIVENESS, so can still search on case if that would be helpful (searching for Apple to get files on the company, etc.) but you avoid the problems of case-sensitivity by the most trivial of workarounds. Well, I don't even think they're workarounds, I think they're just sensible, unambiguous, naming.
If I tried to create Apple.htm and then later apple.htm, Windows would popup a message telling me I couldn't do this, and I'd think "thanks for reminding me that I just tried to do something stupid, I'll rename this second file". You should too.:-)
One is a server that needs to store files from other computer systems. A case-sensitive filesystem can simply use the same names that were on the originating systems. A case-insensitive filesystem will occasionally map two files to the same name, losing one of the files (and 50% of the time using the wrong name for the file that's there). But if the filesystem preserves the correct byte values in the file names, you can just copy files to your server, and they maintain the correct name. You don't need to redesign anything.
The only circumstance I can see this happening is if you have two files in the same directory, only distinguished by case, or two directories in the same dir, only distinguished by case. Can you give me another situation in which that would happen? At this point, I have to say, get your source filesystem sorted out. This should never happen, it's confusing and stupid. Rename any files/directories that are distinguished only by case.
This is a special case of a more general observation: If system X allows some particular thing and system Y doesn't, then system X is generally more usable. It may be more complex, of course. Case insensitivity is easy enough to implement at the "library" level in a system that is case sensitive. I've done it in several projects. But you can't easily fake case sensitivity if the file system ignores case. So if you want a general-purpose system, you're better going with the one that doesn't enforce such policy decisions inside the OS kernel.
Although this may apply to system elements that the user does not have to use (on a default install) such as having a million-and-one text editors installed, it doesn't apply to ones that they do have to. There are definitely times when allowing something is seen as worse than not allowing something, as evidenced by many complaints I've heard against Windows (allowing file extension to control execution permission, allowing hiding of file extensions, allowing a scripted page for a desktop, etc.). No, in this case, allowing that extra thing is far worse than not allowing it, IMHO. Just because you can make up for it in the shell doesn't rectify the underlying problem. Besides, most Linux shells certainly DON'T make up for it.
I've also had the fun of trying to deal with projects that use code from several different sources. It's pretty easy on a conventional unix file system. When I've moved the result to OSX, the result was a nightmare due to the case insensitivity. This is because search paths inherit the case insensitivity. So if package X has a "foo" command and package Y has a "Foo" command, which you get depends on which directory is first in the search path. You find that scripts in X sometimes get "Foo" when they called "foo", and scripts in Y sometimes get "foo" when they called "Foo". Debugging this can take an inordinate amount of time, as there are no "not found" warnings. The software just quietly goes berserk.
Right, so those projects *happen* to play nicely together if case-sensitivity is enabled. I'm not sure exactly what ones you're talking about, but are you saying that you never get the problem of two filenames being EXACTLY the same (many projects just put every file in lowercase to avoid case-sensitivity confusion); every two files that conflict happen not to conflict on case? This just sounds like a lazy answer. 'Software package commands are badly named and rely on case-sensitivity to distinguish them'. Fix the software, name it properly. This is just apologising for piss-poor, lazy naming conventions.
But if you're using code from more than one source, you're just inviting a lot of long debugging sessions due to the case insensitivity. It's easier to go with a system that doesn't do that to you.
Or... 'This is a good idea, because what I'm using is broken and I don't mind it staying broken as long as I can make use of an obscure feature that lets it keep working'. No; fix the file naming conventions.
First of all, as far as I know except for Mac OS all UNIX systems are case-sensitive. That in itself is a reason to use a case-sensitive filesystem even if it wasn't better: because UNIX makes up for it.
Rubbish! If it's not better, that's a great reason to change it. Mere momentum is the worst reason to keep something going. Whatsmore, I could make the opposite argument. Because Windows, used by a large majority of the computing world, and Mac OS, have case-insensitive file systems by default, other OSes should fall into line because it may cause problems if trying to convert from one file system to another.
Second, I'd rather have the flexibility of using any character I want, just in case. I mean, uppercase and lowercase letters are different UNICODE values, so why should the filesystem treat them any differently from every other character by merging them together?
Because the difference between capitalization is far less relevant than the difference between other unicode characters (such as accented characters) in most Latin-based languages? Because it's very likely to lead to confusion if you only use capitalization to distinguish between two files? Tell me honestly, when was the last time you actually saw 2 files in the same directory distinguished only by capitalization?
Oh yeah and Anna-Kournikova.jpg.exe causes trouble even if extensions are made visible because much (not all) DOS/Windows software only displays the first extension.
Ahem? Once hiding file extensions is disabled in the Explorer shell, I have never come across ONE Windows app that 'only displays the first extension'. Examples?
If it starts with CAFEBABE, the JVM can semi-safely assume that this is a valid bytecode file. But... what if some other file "collides" with that signature?
So you've immediately rendered the first sentence utterly false.
If every file in the file system had a minimum "simple set" of metadata tags in the header information, this would work beautifully.
If I understand you correctly, you mean having the same fields of metadata for all files? For a sourcecode file, you might want language, author, maybe even editor used to write it. For an image, you'll want a description, location, etc. How would that work?
Extensions are part of the filename. I, as a user, can meddle with them in the same manner as the rest of a filename.
You, as a user (assuming you have control of your system), can meddle with ANY PART of a file. Including the header and contents. Filenames are *slightly* more readily available and changeable, and IMHO that's a good thing because it makes it that little bit easier to check what type of file you've got IF the extension is being used correctly. It can be abused, but so can anything. So what?
And if you post a brick through someone's letterbox it'll fall through, despite the fact it isn't a letter. Why don't you just name the file correctly and use the tool as it's meant to be used?
Slashdot Mirror
Yup. Biggest problems I tend to have with CSS involve its not being designed to determine the size of a block (either height or width) by the size of its content; most stuff involves specifying fixed sizes. Try determining the width of that div using the width of the smallest contained image.
Actually the problems I've had so far with CSS are documented here (1, 2 and 3.htm).
Hmm. It does rather sound like you're too lazy to specify a protocol to the browser. Just typing a bareword in there is like saying "I want orange." to the browser. Do you want a list of orange stuff, a drink of orange, the colour orange...? Doing a search doesn't seem any less intuative than going to a certain port on the host so-named...
Woah, don't decry the 'new tab' button just because you don't use it. I'm sur you realise such behaviour is stupid.
I often use it when I'm in 'reading' mode and am not using the keyboard, but am copy/pasting a URL using the mouse.
I've been using that pronouncement for at least 15 - 20 years...
Why? Do you Americans have a secret admiration for the French and want to start speaking their language? And what's with your pronunciation of the word 'fillet', and usage of the word 'resumé' (I even had to use a very non-English accent there!) ?
Voting for Michael Howard, who would've been much more lenient and sensible, and who really did stand a chance in hell of getting elected under Britain's non-PR electoral system.
Please replace 'the sheep' with 'the MPs of the Labour party, having been called to vote on a three-line whip, despite their law being criticised by just about every other corner of society'.
Face it, democracy that allows a simple majority to implement a law sucks; it's the tyranny of the majority - and it's not even a majority of the country, it's a majority of MPs who aren't exactly representative in the first place.
What, and you think you folks could rise up?
Push them enough, and they will.
Yes, but just HOW hard must they be pushed before they rise up? If it's harder than government spying illegally on citizens, kidnapping citizens for extraordinary rendition to 'extract' confessions from them, placing hundreds of people in an offshore prison where law "doesn't apply", slowly but surely removing freedom of speech (if a website promoted eg. terrorism), and promoting the rights of copyright holders to the extent that their breach is considered by law more serious than rape... then i'd say the point of rebellion is somewhat defeated.
This almost make you long for the days when the monarchy and the House of Lords were stronger. At least they knew their boundaries for the most part.
Heh. Henry VIII (hint: search for 'executed').
the UK's equivalent of the RIAA
The British Pornographic Industry.
I might well be being naive here, but isn't this almost repeating what copyright/trademark laws say? What's new?
Kudos - Why Live A Real Life When You Can Simulate One?
Oh yeah, actually living one would probably be a better idea. Sorry, don't like it.
The democracy one looks boring too. Sorry.
Yes it does. It's a great example of how you can help excercise your right not to vote by passing away your idle time viewing link farms.
AMD lost me here.. They need to convince me they will continue to lower prices and maintain a competitive product. At this point I'm not convince they can catch up to Intel again.. Intel has greater market share, lower costs and wider margins. AMD had opportunity, but I think they won't have it for long..
So you'll soon have the problem of there being one, uno, major PC CPU manufacturer in the market, with a barrier to entry so high it makes the Great Wall of China look like a garden fence. Much better.
So on, so fourth.
What happens fifth?
Bad guys figure out how to rewrite BIOSes so that they can run their code even when the boot drive is a Knoppix disk.
Ahem.
I'm more interested in how they dealt with offline messaging. Yahoo (like most other IM networks) supports the nice feature of sending a message to an offline contact, having it stored on Yahoo's server and delivered to that contact when they come online. Apparently, MSN could never be bothered to do that. How do they merge those two policies?
Ah, but many people frequently swap capitalization for convenience, me included. I may want to call my file ReadThis, but on the commandline I'd like type re, then TAB. I want it to ignore capitalization when searching, and I don't want to worry about capitalization when searching, which i can't do when the FS is case-sensitive.
I disagree. Linux is DOING as well. It's imposing on me the policy that I can have two same-named files, save capitalization, in the same dir, even when I dont want it to. You can actively force something on your users by allowing stuff, too; the ability to have silly behaviour. Case-sensitive filesystems are one example. I would like Windows NOT TO OFFER the option of hiding file extensions, I'd like it NOT TO OFFER the option of using file extension to make a file executable, and NOT TO OFFER the ability to have a scripted page as a desktop too. There are some things it's sensible for an OS not to do.
Those who approve of top-down policy making will support the MS/Apple approach; those who prefer versatility and experimentation will support the unix approach. There's no logical resolution to this, as it's not a logical issue.
:-)
No, I support the latter, but I still think the underlying filesystem is far more sensibly designed if it's case-insensitive.
And OSes do impose policy decisions on you, no matter what, and it's unavoidable. It's necessary to get a sane system. They impose memory management algorithms on you, device driver framework on you, and (to some degree) licencing requirements on you; and I'm sure those are just the tip of the iceberg. The only way to avoid these 'imposed restrictions' would be to code your own operating system.
What is more, what I'm suggesting isn't forcing stuff on you, because you can change the FS that Linux uses. I am definitely saying, however, that major Linux filesystems should, by default, be case-insensitive, and all major distroes should have this setup by default, and all programmers should program with the assumption that this is the case in mind. Although it can (in very rare circumstances, two of which you specified above) be useful to have files in the same directory distinguished only by case, it's far more likely that the ability to do this will cause confusion and problems, especially for users who're new to, say, Linux.
There are *indeed* ways to get around the desire to distinguish only by case, caused by the not-silly barrier in the way of Getting The Job Done In A Rather Silly Way, that don't add to anyone sane's frustration level. Please don't ever say that there aren't again, because you'd be lying.
How about:
Sonata in D major
Sonata in d minor
AppleCo.htm
apple.htm
Notice how you can still have case-RETENTIVENESS, so can still search on case if that would be helpful (searching for Apple to get files on the company, etc.) but you avoid the problems of case-sensitivity by the most trivial of workarounds. Well, I don't even think they're workarounds, I think they're just sensible, unambiguous, naming.
If I tried to create Apple.htm and then later apple.htm, Windows would popup a message telling me I couldn't do this, and I'd think "thanks for reminding me that I just tried to do something stupid, I'll rename this second file". You should too.
One is a server that needs to store files from other computer systems. A case-sensitive filesystem can simply use the same names that were on the originating systems. A case-insensitive filesystem will occasionally map two files to the same name, losing one of the files (and 50% of the time using the wrong name for the file that's there). But if the filesystem preserves the correct byte values in the file names, you can just copy files to your server, and they maintain the correct name. You don't need to redesign anything.
The only circumstance I can see this happening is if you have two files in the same directory, only distinguished by case, or two directories in the same dir, only distinguished by case. Can you give me another situation in which that would happen? At this point, I have to say, get your source filesystem sorted out. This should never happen, it's confusing and stupid. Rename any files/directories that are distinguished only by case.
This is a special case of a more general observation: If system X allows some particular thing and system Y doesn't, then system X is generally more usable. It may be more complex, of course. Case insensitivity is easy enough to implement at the "library" level in a system that is case sensitive. I've done it in several projects. But you can't easily fake case sensitivity if the file system ignores case. So if you want a general-purpose system, you're better going with the one that doesn't enforce such policy decisions inside the OS kernel.
Although this may apply to system elements that the user does not have to use (on a default install) such as having a million-and-one text editors installed, it doesn't apply to ones that they do have to. There are definitely times when allowing something is seen as worse than not allowing something, as evidenced by many complaints I've heard against Windows (allowing file extension to control execution permission, allowing hiding of file extensions, allowing a scripted page for a desktop, etc.). No, in this case, allowing that extra thing is far worse than not allowing it, IMHO. Just because you can make up for it in the shell doesn't rectify the underlying problem. Besides, most Linux shells certainly DON'T make up for it.
I've also had the fun of trying to deal with projects that use code from several different sources. It's pretty easy on a conventional unix file system. When I've moved the result to OSX, the result was a nightmare due to the case insensitivity. This is because search paths inherit the case insensitivity. So if package X has a "foo" command and package Y has a "Foo" command, which you get depends on which directory is first in the search path. You find that scripts in X sometimes get "Foo" when they called "foo", and scripts in Y sometimes get "foo" when they called "Foo". Debugging this can take an inordinate amount of time, as there are no "not found" warnings. The software just quietly goes berserk.
Right, so those projects *happen* to play nicely together if case-sensitivity is enabled. I'm not sure exactly what ones you're talking about, but are you saying that you never get the problem of two filenames being EXACTLY the same (many projects just put every file in lowercase to avoid case-sensitivity confusion); every two files that conflict happen not to conflict on case? This just sounds like a lazy answer. 'Software package commands are badly named and rely on case-sensitivity to distinguish them'. Fix the software, name it properly. This is just apologising for piss-poor, lazy naming conventions.
But if you're using code from more than one source, you're just inviting a lot of long debugging sessions due to the case insensitivity. It's easier to go with a system that doesn't do that to you.
Or... 'This is a good idea, because what I'm using is broken and I don't mind it staying broken as long as I can make use of an obscure feature that lets it keep working'. No; fix the file naming conventions.
If you're build
First of all, as far as I know except for Mac OS all UNIX systems are case-sensitive. That in itself is a reason to use a case-sensitive filesystem even if it wasn't better: because UNIX makes up for it.
Rubbish! If it's not better, that's a great reason to change it. Mere momentum is the worst reason to keep something going. Whatsmore, I could make the opposite argument. Because Windows, used by a large majority of the computing world, and Mac OS, have case-insensitive file systems by default, other OSes should fall into line because it may cause problems if trying to convert from one file system to another.
Second, I'd rather have the flexibility of using any character I want, just in case. I mean, uppercase and lowercase letters are different UNICODE values, so why should the filesystem treat them any differently from every other character by merging them together?
Because the difference between capitalization is far less relevant than the difference between other unicode characters (such as accented characters) in most Latin-based languages? Because it's very likely to lead to confusion if you only use capitalization to distinguish between two files? Tell me honestly, when was the last time you actually saw 2 files in the same directory distinguished only by capitalization?
I'm more used to/more comfortable with/prefer case-sensitive filenames
- Do you mean case-retentive?
- If you mean case-sensitive... Why?
Remember, you're arguing that you should be able to have 'Data2' and 'data2' in the same directory.
Why?
Oh yeah and Anna-Kournikova.jpg.exe causes trouble even if extensions are made visible because much (not all) DOS/Windows software only displays the first extension.
Ahem? Once hiding file extensions is disabled in the Explorer shell, I have never come across ONE Windows app that 'only displays the first extension'. Examples?
If it starts with CAFEBABE, the JVM can semi-safely assume that this is a valid bytecode file. But... what if some other file "collides" with that signature?
So you've immediately rendered the first sentence utterly false.
If every file in the file system had a minimum "simple set" of metadata tags in the header information, this would work beautifully.
If I understand you correctly, you mean having the same fields of metadata for all files? For a sourcecode file, you might want language, author, maybe even editor used to write it. For an image, you'll want a description, location, etc. How would that work?
Extensions are part of the filename. I, as a user, can meddle with them in the same manner as the rest of a filename.
You, as a user (assuming you have control of your system), can meddle with ANY PART of a file. Including the header and contents. Filenames are *slightly* more readily available and changeable, and IMHO that's a good thing because it makes it that little bit easier to check what type of file you've got IF the extension is being used correctly. It can be abused, but so can anything. So what?
And if you post a brick through someone's letterbox it'll fall through, despite the fact it isn't a letter. Why don't you just name the file correctly and use the tool as it's meant to be used?