The end result is clear: a much more user-friendly Linux experience for end-users and a much better platform to run beloved Windows games with Steam on Linux.
Ah d'accord. Valve veut élargir sa clientèle.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
Sa clientèle je ne pense pas, le coût d'assurer le support linux est certainement très supérieur à ce que peut rapporter la petite communauté de gamers sous linux.
On dirait qu'ils préparent plutôt le terrain pour sortir une console qui supporterait leur large catalogue.
Certainement. Et du coup, baisser les coûts en employant des windowsiens personnes non qualifiées pour écrire (habituées au point-n-click) va sûrement aider aussi un peu.
Comment ? Les coups bas seraient interdits même le vendredi ?
Sérieusement, je pensais que le système de fichier "case insensitive" était un bug de Windows de l'époque W95/W98 qui avait été corrigé lorsqu'ils étaient sortis du FAT pour le NTFS. C'est encore d'actualité pour les Windows actuels (je n'ai pas testé depuis W98)?
J'ai du mal à comprendre l'intérêt d'implémenter le foutoir qu'il y avait à avoir plusieurs manières différentes de nommer un même fichier.
J'ai du mal à comprendre l'intérêt d'implémenter le foutoir qu'il y avait à avoir plusieurs manières différentes de nommer un même fichier.
Un humain dit-il que "THE ALF" et "the alf" et "The Alf" sont différents?
Certains pensent que l'humain doit s'adapter à la machine, d'autres pensent que la machine doit s'adapter à l'humain.
Un humain Français fait la différence entre « la Renaissance » et « la renaissance ».
Blague à part, ton fichier que tu as crée il y a 5 ans, il avait une majuscule ou non ? Tu t'en souviens vraiment sur le long terme ? Cette fonctionnalité te permet de ne pas avoir à t'en soucier, ça enlève une difficulté pour les utilisateurs.
Comme c'est optionnel, je trouve que ça serait une bonne idée de l'activer par exemple pour /home au moins. Ça aidera les utilisateurs tout en gardant la rigueur dans le reste du système.
En plus, il y a des langues où un même mot peu s'écrire de plusieurs manières tout à fait équivalentes. Par exemple, si je me souviens bien, en allemand, tu peux écrire Fussball ou Fußball pour parler du football.
Pour implémenter cette fonctionnalité, les développeurs n'ont apparemment pas juste fait la différence entre majuscule et minuscule, mais ils prennent en compte aussi ces équivalents directement dans le système de fichier. D'ailleurs, avec ce commentaire et la réponse dans LWN, j'ai appris qu'il y a déjà une norme pour "normaliser" les mots définie par unicode.
Blague à part, ton fichier que tu as crée il y a 5 ans, il avait une majuscule ou non ? Tu t'en souviens vraiment sur le long terme ? Cette fonctionnalité te permet de ne pas avoir à t'en soucier, ça enlève une difficulté pour les utilisateurs.
Je ne vois pas bien ce que ça peut faire.
Pour que ce soit mis dans le /home, il faut que ce dernier soit sur une partition dédiée. Je trouverai mieux que ce soit fait en espace utilisateur plutôt que dans le fs. Comme ça tu as bien plus de souplesse. Tu peux accepter tout ce que tu sa souhaite de liberté.
Ça fait très longtemps qu'on peut chercher des fichiers en ignorant la casse (find -iname). Ici il est question d'empêcher la création de plusieurs fichiers dont le nom ne diffère que par la casse.
Cela étant dit, d'après l'article (et j'ai l'impression que les gens dans ce fil de discussion ne l'ont pas lu), c'est une fonctionnalité qui doit être activée explicitement pour chaque répertoire individuel où on le veut, et ce n'est faisable que sur un répertoire vide.
Pour find -iname, le manuel dit que ça ne fait qu'ignorer la casse. Il ne dit pas qu'il gère la normalisation des noms (comme le cas du "ss" en allemand que j'ai donné plus haut, ou le "ç" qui est un "c").
Même si on admet que nous avons tous un outil en espace utilisateur pour faire de la recherche sur des noms normalisés (comme Tracker, baloo…), ça ne résout que le cas de la recherche.
Ce qui est bien, c'est que, comme c'est au niveau du noyau, cp, mv et tous les autres outils en profitent directement sans avoir besoin d'implémenter la norme unicode de normalisation eux-mêmes.
Maintenant, j'aimerai bien que tu m'expliques l'avantage pour un utilisateur moyen (celui qui fait surtout de la navigation web, du mail et quelques documents de bureautique) de la sensibilité à la casse ?
Pour moi, la sensibilité a toujours été un désavantage face à Windows, car les noms de fichiers n'ont pas de contexte (pour distinguer Renaissance de renaissance ou Français de français, il faut avoir un contexte).
Pour moi, le système de fichier doit juste permettre à l'utilisateur d'organiser un peu ses fichiers, il ne doit pas lui mettre des battons dans les roues.
Car pour moi, "images" ou "Images" c'est exactement la même chose ça ne change rien sans contexte (début de phrase, titre dans un document). D'ailleurs, je n'ai jamais vu un logiciel ou une distribution utiliser cette "fonctionnalité" pour organiser les dossiers/fichiers de /etc, /usr…
La non-sensibilité à la casse (via la normalisation des mots) permet aussi de simplifier l'apprentissage du terminal aux nouveaux-venus: ils ne connaissent en général pas l'astuce de la touche "tabulation" et écrivent leurs premiers cp ou mv à la main de tête. Ça leur permettra de réussir leur commande dans le terminal sans avoir directement un message d'erreur :)
Par contre, je ne suis pas pour que cette fonctionnalité se retrouve ailleurs que dans le système de fichier. Par exemple, en C#, si je me souviens bien, le programmeur ne peut pas choisir les noms de variables comme bon lui semble car le langage est insensible à la casse. Dans le développement, je pense que l'on doit exiger de la rigueur de la part des développeurs car c'est un point essentiel du métier.
Maintenant, j'aimerai bien que tu m'expliques l'avantage pour un utilisateur moyen (celui qui fait surtout de la navigation web, du mail et quelques documents de bureautique) de la sensibilité à la casse ?
Ce qui est bien, c'est que, comme c'est au niveau du noyau, cp, mv et tous les autres outils en profitent directement sans avoir besoin d'implémenter la norme unicode de normalisation eux-mêmes.
Tu peux très bien avoir ça en espace utilisateur. Au mieux de l'ajouter à ext4 ce qui complexifie ce dernier et empêche de l'avoir dans xfs et btrfs par exemple, ça peut se faire par fuse et c'est indépendant du système de fichier en dessous.
Par contre je pense que ça pose un vrai problème pour le shell. Si pour le fichier azerty, tu tente Aze<tab> (de la même manière si tu utilise Azer*). Il ne trouvera pas on fichier car c'est le shell qui fais la comparaison et pas le système de fichier.
Tant que l'humain est plus intelligent que la machine, il me semble raisonnable d'attendre à ce que ce soit à l'humain d'apprendre à utiliser une machine, et non l'inverse. Sinon, on en est réduit au plus petit dénominateur commun.
Ce mode de pensée qui voudrait qu'il ne faut surtout pas que l'on attende d'une personne qu'elle ne réfléchisse pour utiliser un ordinateur (ou tout autre objet courant, d'ailleurs) me semble pour le moins perturbante et réductrice… mais malheureusement très présente dans notre mode actuel.
Tant que l'humain est plus intelligent que la machine, il me semble raisonnable d'attendre à ce que ce soit à l'humain d'apprendre à utiliser une machine, et non l'inverse. Sinon, on en est réduit au plus petit dénominateur commun.
Cette assertion n'a aucun sens. Il n'est pas question de l'intelligence de la machine, uniquement que celui ou ceux qui la conçoivent adaptent leur création à l'utilisateur. Il n'y a pas de concours à celui qui est le plus intelligent t ou non, c'est juste que généralement un logiciel est plus utilisé que programmé donc il paraît plus logique de corriger le problème une fois en amont que de laisser cette tâche à chaque utilisation par chaque utilisateur.
Ça ne dit pas s'il faut être sensible ou non aux majuscules, juste que ton accroche toute faite n'a aucun sens. Elle s'appuie sur des phrases au premier degré, plutôt que sur leur sens.
il me semble raisonnable d'attendre à ce que ce soit à l'humain d'apprendre à utiliser une machine, et non l'inverse.
Après il ne faut pas s'étonner que les gens n'utilisent pas les logiciels préférés (inutilisables) des "geeks", qu'ils préfèrent la "prison" Google ou Apple face à une offre "tu dois souffrir pour nous mériter". La tour d'ivoire.
Sinon, on en est réduit au plus petit dénominateur commun.
Rien à voir, juste que tout le monde n'a pas la capacité et surtout l'envie d'apprendre quand ils peuvent faire plus simple. Je vais te révéler un secret : c'est ce qui nous permet de ne plus passer 90% de notre temps à chercher à manger, on sait faire mais si on automatise ben on a plus de temps pour autre chose. Ta logique ferait que tu n'aurais pas de machine pour répondre aussi vite sur LinuxFr, tu utiliserais un système de lettre par la poste parce que les ordis te mâchent trop le travail et tu refuses le principe (même le télégramme avec le Morse, c'est te mâcher le travail, à refuser). La vie humaine moderne (pas juste se nourrir) est surtout basée sur l'automatisation "pas intelligente mais qu'on sait automatiser".
Ce n'est pas une question d'intelligence, juste que tout le monde n'est pas masochiste.
(dans le même registre les classiques gens qui vivent pour travailler qui n'arrivent pas à comprendre ceux qui travaillent pour vivre).
PS : toujours aussi amusant les grandes phrases théoriques dont les gens ne se l'appliquent pas à eux-mêmes pour de vrai, à croire qu'ils savent que c'est juste de l'affichage pour se croire supérieur au autres alors qu'en pratique ils sont juste comme les autres.
# Tout ça pour jouer.
Posté par ZeroHeure . Évalué à 0.
Ah d'accord. Valve veut élargir sa clientèle.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Tout ça pour jouer.
Posté par nlgranger . Évalué à 2.
Sa clientèle je ne pense pas, le coût d'assurer le support linux est certainement très supérieur à ce que peut rapporter la petite communauté de gamers sous linux.
On dirait qu'ils préparent plutôt le terrain pour sortir une console qui supporterait leur large catalogue.
[^] # Re: Tout ça pour jouer.
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 1. Dernière modification le 28 août 2020 à 22:58.
Certainement. Et du coup, baisser les coûts en employant des
windowsienspersonnes non qualifiées pour écrire (habituées au point-n-click) va sûrement aider aussi un peu.Comment ? Les coups bas seraient interdits même le vendredi ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Tout ça pour jouer.
Posté par deuzene (site web personnel) . Évalué à 3.
Ben non, la baisse des coûts c'est bien ce que recherche Valve ;)
« Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »
# Ou "Comment implémenter un bug de Windows dans Linux"...
Posté par THE_ALF_ . Évalué à 4.
Sérieusement, je pensais que le système de fichier "case insensitive" était un bug de Windows de l'époque W95/W98 qui avait été corrigé lorsqu'ils étaient sortis du FAT pour le NTFS. C'est encore d'actualité pour les Windows actuels (je n'ai pas testé depuis W98)?
J'ai du mal à comprendre l'intérêt d'implémenter le foutoir qu'il y avait à avoir plusieurs manières différentes de nommer un même fichier.
[^] # Re: Ou "Comment implémenter un bug de Windows dans Linux"...
Posté par barmic 🦦 . Évalué à 2.
Tu sais que c'est une fonctionnalité de base d'unix reprise dans linux et les BSD ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ou "Comment implémenter un bug de Windows dans Linux"...
Posté par Zenitram (site web personnel) . Évalué à 0.
Un humain dit-il que "THE ALF" et "the alf" et "The Alf" sont différents?
Certains pensent que l'humain doit s'adapter à la machine, d'autres pensent que la machine doit s'adapter à l'humain.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ou "Comment implémenter un bug de Windows dans Linux"...
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2.
Blague à part, ton fichier que tu as crée il y a 5 ans, il avait une majuscule ou non ? Tu t'en souviens vraiment sur le long terme ? Cette fonctionnalité te permet de ne pas avoir à t'en soucier, ça enlève une difficulté pour les utilisateurs.
Comme c'est optionnel, je trouve que ça serait une bonne idée de l'activer par exemple pour /home au moins. Ça aidera les utilisateurs tout en gardant la rigueur dans le reste du système.
En plus, il y a des langues où un même mot peu s'écrire de plusieurs manières tout à fait équivalentes. Par exemple, si je me souviens bien, en allemand, tu peux écrire Fussball ou Fußball pour parler du football.
Pour implémenter cette fonctionnalité, les développeurs n'ont apparemment pas juste fait la différence entre majuscule et minuscule, mais ils prennent en compte aussi ces équivalents directement dans le système de fichier. D'ailleurs, avec ce commentaire et la réponse dans LWN, j'ai appris qu'il y a déjà une norme pour "normaliser" les mots définie par unicode.
[^] # Re: Ou "Comment implémenter un bug de Windows dans Linux"...
Posté par barmic 🦦 . Évalué à 4.
Je ne vois pas bien ce que ça peut faire.
Pour que ce soit mis dans le /home, il faut que ce dernier soit sur une partition dédiée. Je trouverai mieux que ce soit fait en espace utilisateur plutôt que dans le fs. Comme ça tu as bien plus de souplesse. Tu peux accepter tout ce que tu sa souhaite de liberté.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ou "Comment implémenter un bug de Windows dans Linux"...
Posté par wismerhill . Évalué à 8.
Ça fait très longtemps qu'on peut chercher des fichiers en ignorant la casse (find -iname). Ici il est question d'empêcher la création de plusieurs fichiers dont le nom ne diffère que par la casse.
Cela étant dit, d'après l'article (et j'ai l'impression que les gens dans ce fil de discussion ne l'ont pas lu), c'est une fonctionnalité qui doit être activée explicitement pour chaque répertoire individuel où on le veut, et ce n'est faisable que sur un répertoire vide.
[^] # Re: Ou "Comment implémenter un bug de Windows dans Linux"...
Posté par barmic 🦦 . Évalué à 2.
J'avais vu qu'il fallait que ce soit vide, mais je n'avais pas compris que c'était par dossier.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ou "Comment implémenter un bug de Windows dans Linux"...
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 30 août 2020 à 09:05.
Pour
find -iname, le manuel dit que ça ne fait qu'ignorer la casse. Il ne dit pas qu'il gère la normalisation des noms (comme le cas du "ss" en allemand que j'ai donné plus haut, ou le "ç" qui est un "c").Même si on admet que nous avons tous un outil en espace utilisateur pour faire de la recherche sur des noms normalisés (comme Tracker, baloo…), ça ne résout que le cas de la recherche.
Ce qui est bien, c'est que, comme c'est au niveau du noyau,
cp,mvet tous les autres outils en profitent directement sans avoir besoin d'implémenter la norme unicode de normalisation eux-mêmes.Maintenant, j'aimerai bien que tu m'expliques l'avantage pour un utilisateur moyen (celui qui fait surtout de la navigation web, du mail et quelques documents de bureautique) de la sensibilité à la casse ?
Pour moi, la sensibilité a toujours été un désavantage face à Windows, car les noms de fichiers n'ont pas de contexte (pour distinguer
RenaissancederenaissanceouFrançaisdefrançais, il faut avoir un contexte).Pour moi, le système de fichier doit juste permettre à l'utilisateur d'organiser un peu ses fichiers, il ne doit pas lui mettre des battons dans les roues.
Je ne vois aucun avantage à pouvoir faire ça:
Car pour moi, "images" ou "Images" c'est exactement la même chose ça ne change rien sans contexte (début de phrase, titre dans un document). D'ailleurs, je n'ai jamais vu un logiciel ou une distribution utiliser cette "fonctionnalité" pour organiser les dossiers/fichiers de
/etc,/usr…La non-sensibilité à la casse (via la normalisation des mots) permet aussi de simplifier l'apprentissage du terminal aux nouveaux-venus: ils ne connaissent en général pas l'astuce de la touche "tabulation" et écrivent leurs premiers
cpoumvà la main de tête. Ça leur permettra de réussir leur commande dans le terminal sans avoir directement un message d'erreur :)Par contre, je ne suis pas pour que cette fonctionnalité se retrouve ailleurs que dans le système de fichier. Par exemple, en C#, si je me souviens bien, le programmeur ne peut pas choisir les noms de variables comme bon lui semble car le langage est insensible à la casse. Dans le développement, je pense que l'on doit exiger de la rigueur de la part des développeurs car c'est un point essentiel du métier.
[^] # Re: Ou "Comment implémenter un bug de Windows dans Linux"...
Posté par wismerhill . Évalué à 2.
Je ne prétend pas le savoir.
[^] # Re: Ou "Comment implémenter un bug de Windows dans Linux"...
Posté par barmic 🦦 . Évalué à 4.
Tu peux très bien avoir ça en espace utilisateur. Au mieux de l'ajouter à ext4 ce qui complexifie ce dernier et empêche de l'avoir dans xfs et btrfs par exemple, ça peut se faire par fuse et c'est indépendant du système de fichier en dessous.
Par contre je pense que ça pose un vrai problème pour le shell. Si pour le fichier
azerty, tu tenteAze<tab>(de la même manière si tu utiliseAzer*). Il ne trouvera pas on fichier car c'est le shell qui fais la comparaison et pas le système de fichier.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ou "Comment implémenter un bug de Windows dans Linux"...
Posté par THE_ALF_ . Évalué à 2.
Tant que l'humain est plus intelligent que la machine, il me semble raisonnable d'attendre à ce que ce soit à l'humain d'apprendre à utiliser une machine, et non l'inverse. Sinon, on en est réduit au plus petit dénominateur commun.
Ce mode de pensée qui voudrait qu'il ne faut surtout pas que l'on attende d'une personne qu'elle ne réfléchisse pour utiliser un ordinateur (ou tout autre objet courant, d'ailleurs) me semble pour le moins perturbante et réductrice… mais malheureusement très présente dans notre mode actuel.
[^] # Re: Ou "Comment implémenter un bug de Windows dans Linux"...
Posté par barmic 🦦 . Évalué à 4.
Cette assertion n'a aucun sens. Il n'est pas question de l'intelligence de la machine, uniquement que celui ou ceux qui la conçoivent adaptent leur création à l'utilisateur. Il n'y a pas de concours à celui qui est le plus intelligent t ou non, c'est juste que généralement un logiciel est plus utilisé que programmé donc il paraît plus logique de corriger le problème une fois en amont que de laisser cette tâche à chaque utilisation par chaque utilisateur.
Ça ne dit pas s'il faut être sensible ou non aux majuscules, juste que ton accroche toute faite n'a aucun sens. Elle s'appuie sur des phrases au premier degré, plutôt que sur leur sens.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ou "Comment implémenter un bug de Windows dans Linux"...
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 29 août 2020 à 20:56.
Après il ne faut pas s'étonner que les gens n'utilisent pas les logiciels préférés (inutilisables) des "geeks", qu'ils préfèrent la "prison" Google ou Apple face à une offre "tu dois souffrir pour nous mériter". La tour d'ivoire.
Rien à voir, juste que tout le monde n'a pas la capacité et surtout l'envie d'apprendre quand ils peuvent faire plus simple. Je vais te révéler un secret : c'est ce qui nous permet de ne plus passer 90% de notre temps à chercher à manger, on sait faire mais si on automatise ben on a plus de temps pour autre chose. Ta logique ferait que tu n'aurais pas de machine pour répondre aussi vite sur LinuxFr, tu utiliserais un système de lettre par la poste parce que les ordis te mâchent trop le travail et tu refuses le principe (même le télégramme avec le Morse, c'est te mâcher le travail, à refuser). La vie humaine moderne (pas juste se nourrir) est surtout basée sur l'automatisation "pas intelligente mais qu'on sait automatiser".
Ce n'est pas une question d'intelligence, juste que tout le monde n'est pas masochiste.
(dans le même registre les classiques gens qui vivent pour travailler qui n'arrivent pas à comprendre ceux qui travaillent pour vivre).
PS : toujours aussi amusant les grandes phrases théoriques dont les gens ne se l'appliquent pas à eux-mêmes pour de vrai, à croire qu'ils savent que c'est juste de l'affichage pour se croire supérieur au autres alors qu'en pratique ils sont juste comme les autres.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.