I swear, I’m always baffled by the whole “did we NEED” this piece of media.
I don’t even know what they mean. Was the world in 1982 going “Oh, thank God, I had been looking for an ET everywhere”.
You don’t know if you wanted to watch a thing until you watch it.
Well, they did five years of Lower Decks. I would watch more Lower Decks. I’d say there’s a need for that.
So do I need more Twny Newsome Star Trek workplace comedy? I need it in my cardiovascular system this very minute, yes.
Whaaaat? You’re telling me someone in the Linux community chooses to be deliberately obscure based on a technicality no end user cares about in a patronizing, elitist manner?
Naah. Impossible.
The issue with the special characters for accent marks and diacritics is their importance fluctuates per language, so you have to keep them separate unless you want to make different rules per locale instead of per character.
They do it the other way for number formatting and that’s already a mess. If you’ve ever tried to work with spreadsheets across locale formats it’s absolutely bonkers. Excel outright changes the separators in formulas.
On a NTFS drive on Windows with default settings the first two are the same, the third one is not.
Caps and non-caps are matched, accented/unaccented characters are not, which is probably what you’d expect.
So is “I runned to the shop and buyed a bottle of milk”.
“Layout” is a noun made from a verb. Just say “how the views can be laid out”. You can’t make a verb out of a noun made from a verb. It makes my brainies ouchie.
Man, that’s nice of you. I mean, you already were out of time to try to make your case like four posts ago and now you’re making time for empathy. I think we’re really turning this around now. This is real progress.
Don’t think I will.
Case insensitive is still the right choice, too.
Persuasive.
So anyway, this here, kids, is why you don’t ever let software engineers actually design functionality for end users.
(…), e.g. via a user-customizable toolbar and how views can be layouted.
I WILL find these people and hurt them. Nobody will blame me.
Ah. So this functional feature is not actually functioning, I just see it function because I’m too dumb to understand all the ways it’s not actually doing the thing it’s doing.
Gotcha.
OK, you’re going to have to be specific about your technical claims here. Which part of unicode support on filenames prevents case insensitive filenames?
I mean, I don’t know why you made me try, because I do use non-English characters day to day. But you made me try, and sure enough, you can absolutely mix and match alphabets and cases in NTFS and still have it behave case-insensitively. i.e. делоinsensitive.txt and делоINSENSITIVE.txt can’t be placed in the same folder and are parsed as the same name.
So if you have some bit of nuance about why you “cannot have” the feature that clearly works right now in front of me in my computer and has for ages I’m all ears. For a completely impossible implementation of a clearly useful feature it sure seems like it is actively supported in most of the FSs currently in use.
EDIT: Made me go check because now I’m curious about the edge cases you guys keep claiming are catastrophic. Putting those two files in a case sensitive Samba share an opening it in Windows keeps the mix of characters but a suffix gets unceremoniously appended to the filename of one of the files. That’s probably a bit of a mess in some circumstances if you don’t know it’s coming, but there you go.
What thing that I propose? Case insensitive FSs aren’t a new thing. They are, in fact, the norm.
Why are you talking about this as if it’s a weird thing some rando in the Internet came up with? Yes, you need to attach the locale to the filename. No, I have no idea off the top of my head of how different file systems encode or store that.
I do know that the information is available, that it is handled in many commonly used FSs already… AND that you need to handle that anyway for a whole bunch of other reasons as well, from special characters ato alternate alphabets. And yes, there are edge cases (hey, to this day Windows won’t parse Japanese filenames out of the box half the time). That’s no excuse.
Once again, this is not about implementation, this is about the user-facing feature working as expected. “Oh, you can’t do case insensitivity because now you have to store additional information” is not an excuse to not support the feature.
Or, if it is, then let’s go back to eight characters from the English alphabet in all caps. 8.3 filenames. Why not? If we don’t want to have to implement features into the FS and convenience doesn’t trump having to deal with additional requirements and edge cases we may as well keep going. Why are spaces, cyrillic, special characters and long names worth doing but case insensitivity isn’t?
Seriously, I will find that blog.
But to your question, case sensitivity is user-facing. That’s been my argument from the beginning.
You don’t need to care about the implementation side. You just need to care about how it’s used. If it makes more sense for the user to have File.txt and file.txt be the same, then that’s as much as you need to “understand” to have an opinion on this. A correct one, at that. The rest of it serves the user and the usability first.
Why would grandma need to specifiy the locale? The locale has been an environment variable set on install as far back as MS DOS and it is still that on Linux, Windows and Mac OS to this day, to my knowledge. You can tell grandma she can edit her config.sys if things aren’t working as expected, I suppose.
This is the second time someone spontaneously brings up non-latin alphabets as if they are equivalent to case sensitivity for no good reason. Who made a nerdy blog post about this and poisoned the well?
No, it’s not. You’re substituting a base use case for an edge case and pretending they are on the same order when it comes to UX. They are not. File localization and mixing and matching alphabets in filenames is NOT the same as case sensitivity and using cases (or spaces, if we want to roll this conversation back a couple decades and talk about an actual implementation mess) in filesystems. Security and stability care about edge cases, it’s weird that you try to flex by name dropping “principle of least surprise” and then pretend that a problem impacting every single user who types a filename is the same impact on that than a user mixing and matching alphabets on multiple cases. ESPECIALLY when your example requires making the conscious decision that equivalent characters across alphabets is equivalent to case sensitivity, which is not a given at all.
Oh, and it’s not my idea. Default Windows and Mac FSs are case insensitive, legacy FAT systems are case insensitive. If the issue is standardization across systems, case sensistivity is the odd one out. If you’re having issues mixing and matching drives in older supported case-insensitive FSs the blanket fix for that is not having a case sensitive system elsewhere for no particularly good reason. I mean, speaking of minimizing surprise…
I mean, cases in non-latin alphabets are cases as long as they function like cases, equivalences between alphabets are not cases, they’re equivalences between alphabets and a different issue altogether. At least that’d be my starting point for implementation.
But you’re misrepresenting my argument. I don’t give a crap if it’s simple and obvious to implement and it’s not my claim that it is. If it’s simple and obvious to the user it’s still the right call, even if the implementation is complicated and has to deal with edge cases.
My last caveat there would be that nobody claimed that a one-size-fits-all is necessary. Ultimately you’re not deciding the case sensitiveness of databases, just of one database, and that’s the filesystem’s naming rules. The rules are arbitrary and conventional. Short of raw “any character code will always be different from any other character code regardless of how visually similar or grammatically interchangeable the user-facing glyphs may be” any other solution is just as arbitrary as each other. You’re always making a decision about it.
My contention is the decision shouldn’t be based on what is comfortable or more straightforward to implement, debug or use for the OS developers, it should be what is more usable by the lowest common denominator GUI-only users. And that’s case insensitive (but otherwise long and flexible) filenames.
I found this post confusing because on the face of it, it sounds like you agree with me.
I mean, yeah, HEAD and head should overwrite each other.
As you say, only technical command-line users care about the case sensitivity. So no, it shouldn’t matter to the nontechnical user. And because the nontechnical user doesn’t care about the distinction if something is called “head” in any permutation it shares a name with anything else called “head”. And the rules are items within a directory have unique filenames. So “head” and “HEAD” aren’t unique.
The issue isn’t that the names are case insensitive, the issue is that two applications are using the same name in the same path.
If we’re not careful that’ll lead to a question about whether consolidating things in the Unix-style directory structure is a bad idea. I normally tend to be neutral on that choice, but you make a case for how the DOS/Windows structure that keeps all binaries, libraries and dependencies under the same directory at the cost of redundancy doesn’t have this problem to begin with.
But either way, if two pieces of software happen to choose the same name they will step over each other. The problem there is neither with case sensitivity or case insensitivity. The problem there is going back and forth between the two in a directory structure that doesn’t fence optional packages under per-application directories. As you say, this is only possible in a very particular scenario (and not what the post in question is about anyway).
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.
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.
For the record, I hated maybe the first five episodes of Lower Decks, while they were mostly just trying to do Rick and Morty in Trek. I do think they found their stride and now the concept of a stand-alone Trek comedy makes a lot more sense, especially from some of the same team.
Whcih I would much prefer over another season of SNW trying to make every episode the wacky, weird viral one instead of having a baseline of episodic sci-fi antology.
I get it, it’s harder to get that balance right with so few episodes, but SNW is WAY closer to jumping the shark than Lower Decks ever was. If you’re going to do a Trek comedy, do a separate show.