I can't imagine that crowd doing it anything but their preferred way.
Remember when a Debian maintainer quit due to the obsoleteness of the toolchain that the other maintainers flat out refused improve because "it worked" ( my google-fu is failing me, if someone finds it please post it)? I imagine things to be the same with the kernel ( not saying the toolchain is obsolete, just that if it were, they won't just change and jump to the latest X).
Despite technical brilliance, this is one of the most closed-minded and stubborn crowds arounds.
Just look at the reaction to adding case-insensitive functionality in filesystem in comments:
But why? Why are they a bad idea besides “Windows does it and ‘Windows bad’”? Why is DNS case insensitive (example.com and EXAMPLE.com are the same), but not files (.Xauthority and .xauthority are different)?
Case insensitivity lines up with the average user’s expectations. For example, if I’m searching for a file, I want a case insensitive match. Because if I named a file “Resume.txt” and searching “resume” didn’t bring it up, I’d be pretty confused. Now imagine the average Joe trying it. Explaining to them case sensitivity won’t convince them it’s a good idea because “Resume” and “resume” are the same thing.
Should that work different for different languages? Imagine the mess. Maybe the file names aren't even written in any human language. Should we use English rules for all languages? Why? What makes English so special that English characters would be normalized, but characters from the native language of the user won't? Wouldn't that trip people up?
Case-insensitive file systems are mostly advocated for by those who only or mainly speak English and aren't aware of how much variety there is in the languages across the globe.
And even in English "us" is a pronoun, whereas "US" is a country.
EDIT: another question: should the normalization rules be changed when the language changes? Break backwards-compatibility?
If you bothered reading the link, all of these questions have been addressed long ago by folks are are more knowledgeable than either one of us.
The rules are spesific to each language, and are especially neccesary for languages thay have several alphabets. Without this functionality, efficient search is impossible.
This silly, forcefull and uninformed critisism is exactly the kind of behaviour i was talking about.
The point of those questions wasn't to see if there are answers to them. The point of those questions was to show that all answers to them are flawed.
Yes, the link provides one set of answers. (Except for the backwards-compatibility and changing language question.) But it doesn't solve the problem.
When you want case-insensitive search, it's the search tool's job to provide it. E.g. whenever you want to do a case-insensitive search inside a file, you pass "-i" to grep or click a checkbox in a GUI. You don't change the file system to normalize characters inside files.
From the link, it also seems like the main motivation for the change is compatibility with Windows software. In particular, it mentions that it isn't something that should be enabled globally in the file system. It really isn't a convenience for the user.
The article makes a good case for providing compatibility with Windows software. But not for much else.
"The point of those questions was to show that all answers to them are flawed."
Whats flawed? Where is it flawed? You provide no arguments at all!
"When you want case-insensitive search, it's the search tool's job to provide it."
I dont know if you didnt read it, or missed it, but the article clearlerly explains that the tool above the FS cannot do such a search performantly, it has to happen at the FS layer
"You don't change the file system to normalize characters inside files."
Where does this certainty come from? Why do you offer no technical argument to support your position? Is this by Pope's decree?
Can you demonstrate a tool that can search efficiently in different alphabets, or when the same character is presentes by different unicode codepoints?
Reading replies here convinces me even more that you just picked 'something something windows' and react like a bull does to a red rag.
Not a single good technical counterargument has beed presented
Ok, maybe this you will judge as something constructive: when the underlying medium is case-insensitive, your application cannot behave in a case-sensitive way. But frequently I care about case-sensitivity in my searches. I gave an example in my top-most comment: "us" vs "US". On the other hand, when the underlying medium is case-sensitive, the application can implement case-insensitivity on its own. I do it all the time. Sometimes I want to run "find . -name", sometimes "find . -iname", and the first one not because I forgot about the second.
> Reading replies here convinces me even more that you just picked 'something something windows' and react like a bull does to a red rag.
Completely missed. I appreciate a lot of design choices behind Windows and use it with pleasure. However, I judge this one aspect of it negatively. It's also a source of recurring problems with Git on Windows.
Windows itself has case-insensitivity largely for backwards-compatibility reasons (from the times of MS-DOS). The underlying filesystem (NTFS) itself is case-sensitive, it is the OS API that normalizes filenames, and is itself case-preserving, rather than case-insensitive, when it comes to writing files.
UPDATE: another point: I may want to have a directory with an image for every character of my alphabet with files named accordingly. With a case-insensitive filesystem I can't have an "a.svg" and an "A.svg" in the same directory.
Isn’t that an implementation detail of whatever tool you’re using for searching for files? I seem to remember most search utilities doing that already?
I read it, even though you could be succintly making your points here instead of linking generic articles, and that's why I surfaced the only thing I considered valid.
The usecase you bring up, including the multiple scripts issue, is search. And it's not and should not be a filesystem concern which optimizes for a different kind of access from which you can build search on top of.
The article is not generic, it is spesific to the issue being discussed, and it explains the issue better than I can.
"And it's not and should not be a filesystem concern which optimizes for a different kind of access"
Why not? Is that by Pope's decree, or is there an actual reason for that?
The filesystem already has like 3 different APIs, with and without caches, sync and async, so clearly they do optimise for different kinds of access.
Can you demonstrate a tool that can search efficiently in different alphabets, or when the same character is presentes by different unicode codepoints?
> Why not? Is that by Pope's decree, or is there an actual reason for that?
By the decree of it vastly increasing complexity and drastically changing the very generic problem a filesystem tries to tackle, instead of just isolating it to its own solution for when it's actually needed and the trade-offs make sense.
> with and without caches, sync and async, so clearly they do optimise for different kinds of access.
That are compatible with the previously existing patterns. Case-insensitive/mapped codepoint full-text search is a very, very different problem and for which you should reach out to the right solution.
And if you want it in your file browser, well nobody's forcing your operating system's human-facing file browser to base its UX entirely on file system primitives.
As for existing tools, I don't know, I don't care for them since I can just organize my files and find them with fd or use a mapping tag-based file-system like tmsu. But I would assume this is the kind of usecase KDE's Baloo or GNOME Tracker intend to solve.
I imagine it’s convenient to them but being difficult for everyone else is a feature. They don’t want people sending in random garbage code so the barrier to entry is kept high.
Inconvenient to who? There a many things in Linux that anyone who doesn’t use Linux full time finds majorly inconvenient, a lot of the UX around Linux is only intuitive to the 45 year old graybeard. To us 30 year old win DevOps guys Linux isn’t actually that “convenient” out of the box.
They were talking about development of the Linux kernel, not using the OS. But I also take issue with your “graybeard” comment. Unix has won out for a reason, I and many other who aren’t old hats prefer the flow of development and deployment on Linux/Unix to that of Windows.
I’m sorry, I use that as a term of endearment. The GP appeared to me to be implying that those who work on Linux prefer convenience I was just remarking that convenience doesn’t always equal ease of use for most ppl.
Nop, it doesn’t. Linux, which is a Unix clone, has won on some category of computers (notably servers) but most unices derivativing from the original one have a marginal market share.
There's your problem right there. If you expect unix models to follow the particular broken-by-design failures of Windows on the server then that's the problem.
Unix models have their own broken-by-design crap, and it is different to the one you know :-)
Can I ask what’s intuitive about a UX that hides all functionality behind cryptic commands that require reading the mind of the person who made them to know which three letters correspond to the acronym of the command you’re trying to run?
Once you are familiar with it, it is easy to continue using, and much faster than fumbling around in a GUI trying to find the magic button.
For most commands it's also easy to find the necessary subcommand via man or -h or whatever. The other big thing is scriptability, there's a number of things I find myself doing a few times a day, I can throw that in a script (about a minute to do for most of them) and now they take .5 seconds to do, versus waiting for a GUI to load/run -- Plus, now it's my stupid 3 letter acronym I need to remember :P .
