4 ms·

They're different to a human, why would it be any more difficult to understand that they're different for computers too? Trying to make things easier to underst

by ornxka 6y ago

They're different to a human, why would it be any more difficult to understand that they're different for computers too? Trying to make things easier to understand by introducing complicated mechanisms just makes the whole thing harder to use.

klodolph 6y ago
The computer should be more complicated to make things easier for humans. The computer is fast and reliable at performing complicated operations. Humans are neither fast nor reliable at computing tasks. “Report (final).docx” vs “Report (Final).docx”
- toast0 6y ago
  The computer is fast and reliable at performing complicated well-defined operations. Case insensitive comparison is less well defined than you might think. You need to know what language, because the rules are different in different languages. You need to know what version of unicode, because the rules can change. You need to know what to do if the data on disk doesn't conform to the rules. You need to know what to do when copying data from one filesystem to another when the names can't be stored on the destination. I feel it's often better to train the user on how to use a simple system effectively, than to build a complex system. You have to put the complexity somewhere, and humans are easier to change than software and hardware.
  - klodolph 6y ago
    > You need to know what to do when copying data from one filesystem to another when the names can't be stored on the destination. You already need to know that, because filesystems are a jungle. This covers everything from special characters, to non-Unicode encodings, to different Unicode-like encodings, to special names, to file name length limits, and path length limits. Consider that on Linux a filename is just an arbitrary sequence of bytes with some limitations, and on Windows it's an arbitrary sequence of 16-bit integers. You can put unpaired surrogate characters in a Windows path, and you can put 0xff in a Linux path. > I feel it's often better to train the user on how to use a simple system effectively, than to build a complex system. You have to put the complexity somewhere, and humans are easier to change than software and hardware. Filenames are something that affects everyone who uses computers for more than just browsing the web. By and large, these people have been using case-insensitive filesystems for the past 40 years, except the people using Unix-derivatives other than macOS--a small slice of people with a high percentage of experts. So if you have an idea of how to train a billion people to deal with case sensitivity problems that they didn't have to do with before, I'm all ears. And yes... the case folding and locale problems exist. I think we're already on the way to the right solution there... hide the filesystem completely from most people who use computers. The filesystem is a terrible way to organize data, so we are building more complicated filesystems and more complicated stacks on top of filesystems to make it easier for humans to work with, and rightly so.
    - ChrisSD 6y ago
      > Consider that on Linux a filename is just an arbitrary sequence of bytes with some limitations, and on Windows it's an arbitrary sequence of 16-bit integers. You can put unpaired surrogate characters in a Windows path, and you can put 0xff in a Linux path. I don't think these are as equivalent as you imply. While it's technically possible for Windows paths to contain unpaired surrogates, in practice it never happens outside of malicious software (and even that's rare), Whereas on Linux, getting a "random" bag of bytes is relatively common because the convention of UTF-8 is new (and is a userspace convention). Of course it's usually not truly random but you have to play guess the encoding if you want to interpret it.
      - klodolph 6y ago
        Not implying anything about equivalence.
    - toast0 6y ago
      > So if you have an idea of how to train a billion people to deal with case sensitivity problems that they didn't have to do with before, I'm all ears. It's a bit harder for the people who had case insensitivity before, I'd imagine. But the basic way to train people for this is a) to work consistently and b) drop helpful examples in places. For a) When someone makes a new directory lowercse dotless i when they already have a folder named I, they might be surprised to have two directories with the same letter, but they'll figure it out. The same way that they figured out news.ycombinator.com/REPLY doesn't work, because the bytes aren't the same. For b) make some tools expect a file called Makefile and not work if makefile is present. Done!
      - klodolph 6y ago
        Solving a relatively simple technological problem with an immense human labor is a bad tradeoff. Computers are for end-users. OS and app developers are in the minority, and we should remember that when we write apps or filesystems.
        6y ago

by ornxka 6y ago

klodolph 6y ago

The computer should be more complicated to make things easier for humans. The computer is fast and reliable at performing complicated operations. Humans are neither fast nor reliable at computing tasks. “Report (final).docx” vs “Report (Final).docx”

toast0 6y ago
The computer is fast and reliable at performing complicated well-defined operations. Case insensitive comparison is less well defined than you might think. You need to know what language, because the rules are different in different languages. You need to know what version of unicode, because the rules can change. You need to know what to do if the data on disk doesn't conform to the rules. You need to know what to do when copying data from one filesystem to another when the names can't be stored on the destination. I feel it's often better to train the user on how to use a simple system effectively, than to build a complex system. You have to put the complexity somewhere, and humans are easier to change than software and hardware.
- klodolph 6y ago
  > You need to know what to do when copying data from one filesystem to another when the names can't be stored on the destination. You already need to know that, because filesystems are a jungle. This covers everything from special characters, to non-Unicode encodings, to different Unicode-like encodings, to special names, to file name length limits, and path length limits. Consider that on Linux a filename is just an arbitrary sequence of bytes with some limitations, and on Windows it's an arbitrary sequence of 16-bit integers. You can put unpaired surrogate characters in a Windows path, and you can put 0xff in a Linux path. > I feel it's often better to train the user on how to use a simple system effectively, than to build a complex system. You have to put the complexity somewhere, and humans are easier to change than software and hardware. Filenames are something that affects everyone who uses computers for more than just browsing the web. By and large, these people have been using case-insensitive filesystems for the past 40 years, except the people using Unix-derivatives other than macOS--a small slice of people with a high percentage of experts. So if you have an idea of how to train a billion people to deal with case sensitivity problems that they didn't have to do with before, I'm all ears. And yes... the case folding and locale problems exist. I think we're already on the way to the right solution there... hide the filesystem completely from most people who use computers. The filesystem is a terrible way to organize data, so we are building more complicated filesystems and more complicated stacks on top of filesystems to make it easier for humans to work with, and rightly so.
  - ChrisSD 6y ago
    > Consider that on Linux a filename is just an arbitrary sequence of bytes with some limitations, and on Windows it's an arbitrary sequence of 16-bit integers. You can put unpaired surrogate characters in a Windows path, and you can put 0xff in a Linux path. I don't think these are as equivalent as you imply. While it's technically possible for Windows paths to contain unpaired surrogates, in practice it never happens outside of malicious software (and even that's rare), Whereas on Linux, getting a "random" bag of bytes is relatively common because the convention of UTF-8 is new (and is a userspace convention). Of course it's usually not truly random but you have to play guess the encoding if you want to interpret it.
    - klodolph 6y ago
      Not implying anything about equivalence.
  - toast0 6y ago
    > So if you have an idea of how to train a billion people to deal with case sensitivity problems that they didn't have to do with before, I'm all ears. It's a bit harder for the people who had case insensitivity before, I'd imagine. But the basic way to train people for this is a) to work consistently and b) drop helpful examples in places. For a) When someone makes a new directory lowercse dotless i when they already have a folder named I, they might be surprised to have two directories with the same letter, but they'll figure it out. The same way that they figured out news.ycombinator.com/REPLY doesn't work, because the bytes aren't the same. For b) make some tools expect a file called Makefile and not work if makefile is present. Done!
    - klodolph 6y ago
      Solving a relatively simple technological problem with an immense human labor is a bad tradeoff. Computers are for end-users. OS and app developers are in the minority, and we should remember that when we write apps or filesystems.
      - 6y ago