The entire issue is that gradmas don’t type out filepaths.
When you’re tying filenames case is easy, because a) you have to press something different, and b) typically terminal monospace fonts look very different in caps and non caps.
But in a GUI where you aren’t typing the names out? For a human reading human text caps and non caps are interchangeable. So as the name of an icon case sensitivity is confusing and prone to human error.
I mean, it’s that in typing, too, because it’s a very easy typo to make and all sorts of mixed case choices can be hard to remember, but it’s MORE confusing if you end up with just an icon with a name and the exact same icon with the exact same name just one character is a different case.
OSs don’t do anything by themselves, but they come bundled with all sorts of standardize applications built on top of them. If case sensitivity is baked into the filesystem, it’s baked into the filesystem. And absolutely no, you can’t put it in at the application level. I mean, congratulations for finding the absolute worst of both worlds, but how would that even work? If I tell an app to use a file and there are two of them with different cases how would that play out? You can build it into indexing and search queries and so on when they will display more than one result (and that, by the way, is typically extra EXTRA confusing), but you can’t possibly override the case sensitive filesystem.
Now, character byte codes are a different thing, and it’s true that the gripe in this particular rant seems to be almost more focused into weird unicode quirks and the case sensitivity thing seems to be mostly a pet peeve he rolls into it, I suspect somewhat facetiously.
But still, that’s for the OS, the filesystem and the applications to sort out. It’s an edge case to handle and it can be sorted out via arbitrary convention regardless of whether you do case sensitivity for filenames. “Case insensitive means insensitive to other things, too” is not a given at all.
Now, character byte codes are a different thing, and it’s true that the gripe in this particular rant seems to be almost more focused into weird unicode quirks and the case sensitivity thing seems to be mostly a pet peeve he rolls into it, I suspect somewhat facetiously.
No, it has nothing to do with “weird Unicode quirks”.
It has everything to do with their being a universal standard for representing different characters, and the file system deciding to then apply its own random additional standard on top that arbitrarily decides some thing are probably the same as others.
This is just like Javascript’s early ==, fuzzy equality choice. It was done to be helpful, but was a fuzzy system that doesn’t cover enough edge cases to be implemented at that low of a level.
Arbitrary means you can implement it however you want. The limits to it are by convention. There is no need to go any further than case insensitive filenames. At all. Rolling case insensitive filenames into the same issue is entirely an attempt to make a case against a pet peeve for unrelated reasons.
You want it to handle the edge cases? Have it handle the edge cases. You want to restrict it to the minimum feature just for alphabet characters? Do that.
But you do NOT give up on the functionality or user experience because of the edge cases. You don’t design a user interface (and that’s what a OS with a GUI is, ultimately) for consistency or code elegance, you design it for usability. Everything else works around that.
I can feel this conversation slipping towards the black hole that is the argument about the mainstream readiness of Linux and I think we should make a suicide pact to not go there, but man, is it starting to form a narrative and am I finding it hard to avoid it.
There is no need to go any further than case insensitive filenames. At all. Rolling case insensitive filenames into the same issue is entirely an attempt to make a case against a pet peeve for unrelated reasons.
This is literally just the same issue. I cannot see what two issues you are separating this into.
All of this stems from case insensitive file names.
But you do NOT give up on the functionality or user experience because of the edge cases. You don’t design a user interface (and that’s what a OS with a GUI is, ultimately) for consistency or code elegance, you design it for usability. Everything else works around that.
The OS is not the GUI. Every GUI you see in the OS is an application running on top of the actual OS.
The OS should not arbitrarily decide that some characters are the same as others, it should respect the unified standards for what bytes represent what characters. Unless there is an internationally agreed upon standard for EXACTLY what case insensitive means for every character byte code, then you are building a flawed system that will ruin the user experience when massive bugs and stability issues come up because you didn’t actually plan out your system properly to cover edge cases.
You know, as Linus is pointing out given his multi decade history of running Linux.
This is about whether the filesystem in the OS supports case insensitive names.
That determines whether the GUI supports case insensitive names down the line, so the choices made by the filesystem and by the OS support of the filesystem must be done with the usability of the GUI in mind.
So absolutely yes, the OS should decide that some characters are the same as others, not arbitrarily but because the characters are hard to read distinctly by humans and that is the first consideration.
Or hey, we can go back to making all filenames all caps. That works, too and fully solves the problem.
This is about whether the filesystem in the OS supports case insensitive names.
K, now that we’re done being pedantic…
That determines whether the GUI supports case insensitive names down the line, so the choices made by the filesystem and by the OS support of the filesystem must be done with the usability of the GUI in mind.
Oh yes, let’s prioritize making sure that when grandmas are using the raw filesystem they’re not confused by case sensitivity, totally worth it over stable, bug-free, secure, software.
Definitely couldn’t have just built grandmas a case insensitive option on the user portion of the file system instead of introducing bugs and edges cases into literally every single piece of software they might use…
Yes, prioritize making sure that grandmas are not confused by case sensitivity over bug-free secure software. That’s correct.
Also do that robustly in the user layer. Why not? That’s cool as well.
I am a bit confused about how you suggest implementing a file system where two files can have the same user-facing name in document names, file manager paths, shortcuts/symlinks, file selectors and everywhere else exposed by the user without having the file system prevent two files with the same case-insensitive name existing next to each other. That seems literally worse in every way and not how filenames are implemented in any filesystem I’ve ever used or known about. I could be wrong, though.
Point is, I don’t care. If you figure out a good implementation go nuts.
But whatever it is, it NEEDS to make sure grandma will never see Office.exe and office.exe next to each other in the same directory. Deal?
I am a bit confused about how you suggest implementing a file system where two files can have the same user-facing name in document names, file manager paths, shortcuts/symlinks, file selectors and everywhere else exposed by the user without having the file system prevent two files with the same case-insensitive name existing next to each other. That seems literally worse in every way and not how filenames are implemented in any filesystem I’ve ever used or known about. I could be wrong, though.
You can literally toggle case sensitivity on a folder by folder basis in Windows, it just defaults to the wrong one.
But whatever it is, it NEEDS to make sure grandma will never see Office.exe and office.exe next to each other in the same directory. Deal?
Not until you establish an internationally agreed on standard for what that is. Just throwing at a glib easy example is not a standard.
You’re just flat out and completely wrong.
The entire issue is that gradmas don’t type out filepaths.
When you’re tying filenames case is easy, because a) you have to press something different, and b) typically terminal monospace fonts look very different in caps and non caps.
But in a GUI where you aren’t typing the names out? For a human reading human text caps and non caps are interchangeable. So as the name of an icon case sensitivity is confusing and prone to human error.
I mean, it’s that in typing, too, because it’s a very easy typo to make and all sorts of mixed case choices can be hard to remember, but it’s MORE confusing if you end up with just an icon with a name and the exact same icon with the exact same name just one character is a different case.
OSs don’t do anything by themselves, but they come bundled with all sorts of standardize applications built on top of them. If case sensitivity is baked into the filesystem, it’s baked into the filesystem. And absolutely no, you can’t put it in at the application level. I mean, congratulations for finding the absolute worst of both worlds, but how would that even work? If I tell an app to use a file and there are two of them with different cases how would that play out? You can build it into indexing and search queries and so on when they will display more than one result (and that, by the way, is typically extra EXTRA confusing), but you can’t possibly override the case sensitive filesystem.
Now, character byte codes are a different thing, and it’s true that the gripe in this particular rant seems to be almost more focused into weird unicode quirks and the case sensitivity thing seems to be mostly a pet peeve he rolls into it, I suspect somewhat facetiously.
But still, that’s for the OS, the filesystem and the applications to sort out. It’s an edge case to handle and it can be sorted out via arbitrary convention regardless of whether you do case sensitivity for filenames. “Case insensitive means insensitive to other things, too” is not a given at all.
No, it has nothing to do with “weird Unicode quirks”.
It has everything to do with their being a universal standard for representing different characters, and the file system deciding to then apply its own random additional standard on top that arbitrarily decides some thing are probably the same as others.
This is just like Javascript’s early ==, fuzzy equality choice. It was done to be helpful, but was a fuzzy system that doesn’t cover enough edge cases to be implemented at that low of a level.
Arbitrary is the word.
Arbitrary means you can implement it however you want. The limits to it are by convention. There is no need to go any further than case insensitive filenames. At all. Rolling case insensitive filenames into the same issue is entirely an attempt to make a case against a pet peeve for unrelated reasons.
You want it to handle the edge cases? Have it handle the edge cases. You want to restrict it to the minimum feature just for alphabet characters? Do that.
But you do NOT give up on the functionality or user experience because of the edge cases. You don’t design a user interface (and that’s what a OS with a GUI is, ultimately) for consistency or code elegance, you design it for usability. Everything else works around that.
I can feel this conversation slipping towards the black hole that is the argument about the mainstream readiness of Linux and I think we should make a suicide pact to not go there, but man, is it starting to form a narrative and am I finding it hard to avoid it.
This is literally just the same issue. I cannot see what two issues you are separating this into.
All of this stems from case insensitive file names.
The OS is not the GUI. Every GUI you see in the OS is an application running on top of the actual OS.
The OS should not arbitrarily decide that some characters are the same as others, it should respect the unified standards for what bytes represent what characters. Unless there is an internationally agreed upon standard for EXACTLY what case insensitive means for every character byte code, then you are building a flawed system that will ruin the user experience when massive bugs and stability issues come up because you didn’t actually plan out your system properly to cover edge cases.
You know, as Linus is pointing out given his multi decade history of running Linux.
No, hold on, this is not about the OS.
This is about whether the filesystem in the OS supports case insensitive names.
That determines whether the GUI supports case insensitive names down the line, so the choices made by the filesystem and by the OS support of the filesystem must be done with the usability of the GUI in mind.
So absolutely yes, the OS should decide that some characters are the same as others, not arbitrarily but because the characters are hard to read distinctly by humans and that is the first consideration.
Or hey, we can go back to making all filenames all caps. That works, too and fully solves the problem.
Holding on.
K, now that we’re done being pedantic…
Oh yes, let’s prioritize making sure that when grandmas are using the raw filesystem they’re not confused by case sensitivity, totally worth it over stable, bug-free, secure, software.
Definitely couldn’t have just built grandmas a case insensitive option on the user portion of the file system instead of introducing bugs and edges cases into literally every single piece of software they might use…
OK, no, but yes, do that.
Yes, prioritize making sure that grandmas are not confused by case sensitivity over bug-free secure software. That’s correct.
Also do that robustly in the user layer. Why not? That’s cool as well.
I am a bit confused about how you suggest implementing a file system where two files can have the same user-facing name in document names, file manager paths, shortcuts/symlinks, file selectors and everywhere else exposed by the user without having the file system prevent two files with the same case-insensitive name existing next to each other. That seems literally worse in every way and not how filenames are implemented in any filesystem I’ve ever used or known about. I could be wrong, though.
Point is, I don’t care. If you figure out a good implementation go nuts.
But whatever it is, it NEEDS to make sure grandma will never see Office.exe and office.exe next to each other in the same directory. Deal?
You can literally toggle case sensitivity on a folder by folder basis in Windows, it just defaults to the wrong one.
Not until you establish an internationally agreed on standard for what that is. Just throwing at a glib easy example is not a standard.
As this whole article is saying, there isn’t one.