8 ms·

Starting directory names with capital letter is not a good idea. While that might look nice, it requires more keypresses when typing it in the terminal. So /app

Starting directory names with capital letter is not a good idea. While that might look nice, it requires more keypresses when typing it in the terminal. So /apps or /soft would be better than /Programs. It is convenient in case-insensitive filesystems like those used in Windows or Mac, but not in Linux. By the way it would be better if Linux also switched to case-insensitive filesystem, or even a filesystem where similar looking characters from different alphabets are considered the same. So that A is always A no matter what alphabet is used. Also I don't like the way they hide classic directories like /bin. Instead, they should just not create these directories; well-written programs should not require their presence.

tambourine_man 5y ago
I think bash autocomplete can be configured to be case insensitive
forty 5y ago
Case insensitivity is a mess as soon as you start looking outside of ASCII.
- codedokode 5y ago
  But I don't think that it is an unsolvable task. If you simply use Unicode-aware version of "to lowercase" function, it will be better than what we have today. But of course there is a place for improvement (dealing with accented letters in European languages, dealing with combining characters, different alphabets like Hiragana/Katakana etc).
  - forty 5y ago
    Hum... I think simpler is better, and having each letter be what they are only seems much simpler than having to guess if the file system is going to decide my new file name is equivalent to another existing file name and overide it rather than creating a new one (for example).
    - codedokode 5y ago
      It is "simple" for a programmer who doesn't want to learn Unicode and prefers working with bytes instead of letters, but inconvenient for a user. More keypresses, easier to make a mistake when typing. I cannot imagine a situation where you need two files whose names differ only in case.
      - forty 5y ago
        Since it's relevant and funny, I'll quote the famous rant of Linus Torvalds on the topic (it was because of issues it caused with Git, but I assume it still means it's unlikely Linux will ever follow this path ^^) "The true horrors of HFS+ are not in how it’s not a great filesystem, but in how it’s actively designed to be a bad filesystem by people who thought they had good ideas. The case insensitivity is just a horribly bad idea, and Apple could have pushed fixing it. They didn’t. Instead, they doubled down on a bad idea, and actively extended it – very very badly – to unicode. And it’s not even UTF-8, it’s UCS2 I think. Ok, so NTFS did some of the same. But apple really took it to the next level with HFS+. There’s some excuse for case insensitivity in a legacy model (“We didn’t know better”). But people who think unicode equivalency comparisons are a good idea in a filesystem shouldn’t be allowed to play in that space. Give them some paste, and let them sit in a corner eating it. They’ll be happy, and they won’t be messing up your system. And then picking NFD normalization – and making it visible, and actively converting correct unicode into that absolutely horrible format, that’s just inexcusable. Even the people who think normalization is a good thing admit that NFD is a bad format, and certainly not for data exchange. It’s not even “paste-eater” quality thinking. It’s actually actively corrupting user data. By design. Christ. And Apple let these monkeys work on their filesystem? Seriously?"
      - galaxyLogic 5y ago
        I can think of one. When we write (say "ES6") modules it makes sense that the name of the module-file without extension should be the same as the value exported by that module. Inside the module you'd prefer to follow conventions like name classes title-case and name functions camel-case. Thus you might have one module exporting a class named "Camel", and another module exporting a function named "camel". You could then have two files, Camel.js, and camel.js in the same directory, containing two separate programs.
  - kps 5y ago
    > If you simply use Unicode-aware version of "to lowercase" function […] There's no such thing. What's the lowercase of ‘I’ — ‘i’ or ‘ı’?
    - Dylan16807 5y ago
      That's the "place for improvement" you shoved into the "[...]". Pick something.
      - kps 5y ago
        Pick something? Whatever you pick is wrong for some users.
        Dylan16807 5y ago
        And busted unicode support is more wrong. Also you don't need to have an opinion on how to lowercase, you can just say that İIiı are equivalent and it shouldn't make people that upset.
- akho 5y ago
  Case-insensitive ASCII filenames are best filenames. Also, please, no whitespace in filenames. Allowing linebreaks is just insane.
  - forty 5y ago
    I wouldn't mind but there are a bunch of people in this world who have no idea what those ASCII symbols even mean, and who might prefer using symbols they understand ^^
    - akho 5y ago
      Those people do not use filesystems. Also, my native language does not use the Latin alphabet. Attempts by American companies to be more inclusive and internationalized are often misguided. MS is especially nasty with its translated formula functions in Excel, but having differently named filesystem paths in different alphabets depending on the phase of the Moon or something is also very inconvenient.
      - forty 5y ago
        Oh yeah Excel (or libreoffice) is really awful to use in another language, I often have to force it to English because of the formula mess. But I guess that's a developer-who-can-speak English point of view.
        akho 5y ago
        Nah, the names of Excel functions are nonsensical in any language, and you still need to know the English ones.
    - akho 5y ago
      Though I do have to admit that I do not know what, e.g., ASCII code 8 would mean in a filename. Or 27. I’d very much prefer using symbols I understand. Filenames with terminal control escape sequences are lots of fun. Limiting possibilities to just lowercase Latin, numbers, periods and dashes (in non-initial positions) decreases chances people see symbols they do not understand by a lot.
potatoalienof13 5y ago
The response by one of the devs to the first problem is "In fact, the concerns on typing-friendliness always comes up in discussions about the GoboLinux tree. To that, I can only respond that, in a properly configured shell like the one that comes by default with GoboLinux, typing /Programs takes the exact same number of keystrokes as typing /usr: slash, lowercase p, Tab." [0] The response to your second problem is that not all programs are well written, and they cannot afford to patch every poorly-written program. [0] https://gobolinux.org/doc/articles/clueless.html https://gobolinux.org/doc/articles/clueless.html
- klysm 5y ago
  I don’t want to have to reconfigure a shell when it could just be lowercase.
  - pxc 5y ago
    I hear you, but I also think tab completion is one of the basic amenities we should expect shell users to avail themselves of in 2021. And distro-makers can even pre-configure them for their users. I can understand why a distro maker might not be interested in accommodating users who don't want to use decent tab completion with smart casing.
    - klysm 5y ago
      Yes I agree, just playing devils advocate that you shouldn’t have to change off defaults for ergonomics when there isn’t a real _benefit_ to pascal case.
      - pxc 5y ago
        I agree that PascalCase makes more sense on systems like Windows, where everything is case-insensitive, or in shells like PowerShell, where virtually all commands are shell functions rather than separate binaries, and the shell itself is case-insensitive. Then, I suppose you get some legibility benefit, without any extra hassle. I'm personally still on the fence about the more verbose style. I think I like it for directory names but not really for executable names.
asperous 5y ago
From the faq it sounds like the purpose is to differentiate the gobolinux top level folders from the hidden compatibility folders, which makes sense to me.
nmz 5y ago
Case sensitivity is a good idea for sorting/identifying between files/directories.

tambourine_man 5y ago

I think bash autocomplete can be configured to be case insensitive

forty 5y ago

Case insensitivity is a mess as soon as you start looking outside of ASCII.

codedokode 5y ago
But I don't think that it is an unsolvable task. If you simply use Unicode-aware version of "to lowercase" function, it will be better than what we have today. But of course there is a place for improvement (dealing with accented letters in European languages, dealing with combining characters, different alphabets like Hiragana/Katakana etc).
- forty 5y ago
  Hum... I think simpler is better, and having each letter be what they are only seems much simpler than having to guess if the file system is going to decide my new file name is equivalent to another existing file name and overide it rather than creating a new one (for example).
  - codedokode 5y ago
    It is "simple" for a programmer who doesn't want to learn Unicode and prefers working with bytes instead of letters, but inconvenient for a user. More keypresses, easier to make a mistake when typing. I cannot imagine a situation where you need two files whose names differ only in case.
    - forty 5y ago
      Since it's relevant and funny, I'll quote the famous rant of Linus Torvalds on the topic (it was because of issues it caused with Git, but I assume it still means it's unlikely Linux will ever follow this path ^^) "The true horrors of HFS+ are not in how it’s not a great filesystem, but in how it’s actively designed to be a bad filesystem by people who thought they had good ideas. The case insensitivity is just a horribly bad idea, and Apple could have pushed fixing it. They didn’t. Instead, they doubled down on a bad idea, and actively extended it – very very badly – to unicode. And it’s not even UTF-8, it’s UCS2 I think. Ok, so NTFS did some of the same. But apple really took it to the next level with HFS+. There’s some excuse for case insensitivity in a legacy model (“We didn’t know better”). But people who think unicode equivalency comparisons are a good idea in a filesystem shouldn’t be allowed to play in that space. Give them some paste, and let them sit in a corner eating it. They’ll be happy, and they won’t be messing up your system. And then picking NFD normalization – and making it visible, and actively converting correct unicode into that absolutely horrible format, that’s just inexcusable. Even the people who think normalization is a good thing admit that NFD is a bad format, and certainly not for data exchange. It’s not even “paste-eater” quality thinking. It’s actually actively corrupting user data. By design. Christ. And Apple let these monkeys work on their filesystem? Seriously?"
    - galaxyLogic 5y ago
      I can think of one. When we write (say "ES6") modules it makes sense that the name of the module-file without extension should be the same as the value exported by that module. Inside the module you'd prefer to follow conventions like name classes title-case and name functions camel-case. Thus you might have one module exporting a class named "Camel", and another module exporting a function named "camel". You could then have two files, Camel.js, and camel.js in the same directory, containing two separate programs.
- kps 5y ago
  > If you simply use Unicode-aware version of "to lowercase" function […] There's no such thing. What's the lowercase of ‘I’ — ‘i’ or ‘ı’?
  - Dylan16807 5y ago
    That's the "place for improvement" you shoved into the "[...]". Pick something.
    - kps 5y ago
      Pick something? Whatever you pick is wrong for some users.
      - Dylan16807 5y ago
        And busted unicode support is more wrong. Also you don't need to have an opinion on how to lowercase, you can just say that İIiı are equivalent and it shouldn't make people that upset.
akho 5y ago
Case-insensitive ASCII filenames are best filenames. Also, please, no whitespace in filenames. Allowing linebreaks is just insane.
- forty 5y ago
  I wouldn't mind but there are a bunch of people in this world who have no idea what those ASCII symbols even mean, and who might prefer using symbols they understand ^^
  - akho 5y ago
    Those people do not use filesystems. Also, my native language does not use the Latin alphabet. Attempts by American companies to be more inclusive and internationalized are often misguided. MS is especially nasty with its translated formula functions in Excel, but having differently named filesystem paths in different alphabets depending on the phase of the Moon or something is also very inconvenient.
    - forty 5y ago
      Oh yeah Excel (or libreoffice) is really awful to use in another language, I often have to force it to English because of the formula mess. But I guess that's a developer-who-can-speak English point of view.
      - akho 5y ago
        Nah, the names of Excel functions are nonsensical in any language, and you still need to know the English ones.
  - akho 5y ago
    Though I do have to admit that I do not know what, e.g., ASCII code 8 would mean in a filename. Or 27. I’d very much prefer using symbols I understand. Filenames with terminal control escape sequences are lots of fun. Limiting possibilities to just lowercase Latin, numbers, periods and dashes (in non-initial positions) decreases chances people see symbols they do not understand by a lot.

potatoalienof13 5y ago

The response by one of the devs to the first problem is "In fact, the concerns on typing-friendliness always comes up in discussions about the GoboLinux tree. To that, I can only respond that, in a properly configured shell like the one that comes by default with GoboLinux, typing /Programs takes the exact same number of keystrokes as typing /usr: slash, lowercase p, Tab." [0] The response to your second problem is that not all programs are well written, and they cannot afford to patch every poorly-written program. [0] https://gobolinux.org/doc/articles/clueless.html https://gobolinux.org/doc/articles/clueless.html

klysm 5y ago
I don’t want to have to reconfigure a shell when it could just be lowercase.
- pxc 5y ago
  I hear you, but I also think tab completion is one of the basic amenities we should expect shell users to avail themselves of in 2021. And distro-makers can even pre-configure them for their users. I can understand why a distro maker might not be interested in accommodating users who don't want to use decent tab completion with smart casing.
  - klysm 5y ago
    Yes I agree, just playing devils advocate that you shouldn’t have to change off defaults for ergonomics when there isn’t a real _benefit_ to pascal case.
    - pxc 5y ago
      I agree that PascalCase makes more sense on systems like Windows, where everything is case-insensitive, or in shells like PowerShell, where virtually all commands are shell functions rather than separate binaries, and the shell itself is case-insensitive. Then, I suppose you get some legibility benefit, without any extra hassle. I'm personally still on the fence about the more verbose style. I think I like it for directory names but not really for executable names.

asperous 5y ago

From the faq it sounds like the purpose is to differentiate the gobolinux top level folders from the hidden compatibility folders, which makes sense to me.

nmz 5y ago

Case sensitivity is a good idea for sorting/identifying between files/directories.