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.
OK, but you see how you’re saying “there is no standard implementation, so the solution is not having the feature, as opposed to selecting a standard”.
That’s wrong. It’s just bad implementation. Or, rather, it’s bad prioritization of UX, which is then bad implementation by default.
Also, having case sensitivity be a user toggle is not the same as having no case insensitivity. We know case sensitivity works technically, you need to do additional work to make certain characters be read as equivalent. I don’t mind if grandma wants to set her documents folder to be case sensitive to hack the world. I mind that there is no feature to make it so she can’t be confused about what file she’s selecting because the engineers didn’t like having to deal with edge cases.
Alright, I’m getting trauma flashbacks now. I think we’ve established our positions. Happy to give you the last word.
You keep thinking you’re prioritizing UX, while ignoring and talking past the mountain of bugs and security problems this causes, as if those aren’t catastrophic UX problems.
Bugs and security problems aren’t bad UX, they’re a backlog.
You may not be able to afford the implementation, but that’s not the same as arguing the feature has no value. You want to argue that case insensitivity would be better but it’s too hard/problematic to implement? I can have that conversation.
Arguing that it’s the better option in general? Nah, lost me there.
Sorry, I said last word and then came back, but I feel we’re closer to meeting in the middle now, so maybe worth it. All yours again. This time I’m gone for reals.
Bugs and security problems aren’t bad UX, they’re a backlog.
No, they’re not. If you are building a platform for developers to build apps on and you design your API in a way that’s easy to introduce security vulnerabilities that’s not a backlog, that’s a badly designed platform that will be riddled with insecure apps creating a crappy, untrustworthy, ecosystem. And since those bugs are in third party apps you have no control over whether app developers are aware of them or if they’ll ever get to them in their backlog.
Again, this is literally the same thing as the JavaScript equality comparator.
It’s not a bad idea for a user facing UX in some cases, but it’s not good for all cases and thus shouldn’t be implemented at the low file system level.
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.
OK, but you see how you’re saying “there is no standard implementation, so the solution is not having the feature, as opposed to selecting a standard”.
That’s wrong. It’s just bad implementation. Or, rather, it’s bad prioritization of UX, which is then bad implementation by default.
Also, having case sensitivity be a user toggle is not the same as having no case insensitivity. We know case sensitivity works technically, you need to do additional work to make certain characters be read as equivalent. I don’t mind if grandma wants to set her documents folder to be case sensitive to hack the world. I mind that there is no feature to make it so she can’t be confused about what file she’s selecting because the engineers didn’t like having to deal with edge cases.
Alright, I’m getting trauma flashbacks now. I think we’ve established our positions. Happy to give you the last word.
You keep thinking you’re prioritizing UX, while ignoring and talking past the mountain of bugs and security problems this causes, as if those aren’t catastrophic UX problems.
You are right, I keep doing that.
Bugs and security problems aren’t bad UX, they’re a backlog.
You may not be able to afford the implementation, but that’s not the same as arguing the feature has no value. You want to argue that case insensitivity would be better but it’s too hard/problematic to implement? I can have that conversation.
Arguing that it’s the better option in general? Nah, lost me there.
Sorry, I said last word and then came back, but I feel we’re closer to meeting in the middle now, so maybe worth it. All yours again. This time I’m gone for reals.
No, they’re not. If you are building a platform for developers to build apps on and you design your API in a way that’s easy to introduce security vulnerabilities that’s not a backlog, that’s a badly designed platform that will be riddled with insecure apps creating a crappy, untrustworthy, ecosystem. And since those bugs are in third party apps you have no control over whether app developers are aware of them or if they’ll ever get to them in their backlog.
Again, this is literally the same thing as the JavaScript equality comparator.
It’s not a bad idea for a user facing UX in some cases, but it’s not good for all cases and thus shouldn’t be implemented at the low file system level.