Un chiwawa est un animal, ça peut être une arme avec cette définition! :)
Etre sous la menace d'un chiwawa c'est loin d'être risible. C'est assez terrifiant comme bestiole.
(Voix enrouée et légèrement trainante d'un fond d'accent italien) : Ecoute petit, on a un problème toi et moi. Et j'aime pas les problèmes. Tu te couches sur le dossier Lenflure & Co, sinon je serais ammené à faire des chose que je regretterai.
(Voix pleine d'arrogance d'un jeune premier) : Jamais, le dossier Lenflure c'est ma vie, je les défendrais jusqu'au bout vous m'entendez ! Jusqu'au bout !
(Voix enrouée) : Dommage petit, je pensais que tu serais plus intelligent que çà… Bon ben on va être obligé d'offrir un chiwawa à ta femme. On lui mettra même un noeud rose autour du cou.
(Voix nettement moins pleine d'arrogance d'un coup.) : Quoi ? Mais vous pouvez pas faire çà ! Mes beaux-parents ont déjà un yorkshire, pas un chiwawa à la maison en plus.
(Voix enroué) : C'est toi qui choisit la solution difficile petit. On prendra un chiwawa femelle, avec un peu de chance comme ça elle aura une portée avec le yorkshire.
(Voix plus arrogante du tout, parce que c'est dur d'être arrogant quand on vient de vomir) : Bon dieu… Vous êtes ignobles… C'est bon je téléphone à M Lenflure demain pour lui dire que je lâche l'affaire.
Il me semble, corrige-moi si je me trompe, que la personne a attaqué non pas sans objet (à main nues), mais avec un objet (la chantilly en l’occurrence)
Le problème de la définition du Larousse (qui est juste au sens commun, l'est elle au sens légal ?) c'est qu'elle décale le paradygme de l'agression sur un autre mot : attaquer.
C'est à dire que tout objet,appareil ou engin qui sert à attaquer est une arme.
Apparament il y a le sens familier d'attaquer qui est synonyme de commencer un plat. Donc on peut attaquer de la chantilly, mais pour autant on est pas beaucoup plus avancé…
Hein ? C'est possible pour un virus logiciel de péter des composants matériels ? Ou alors y'a un truc qui m’échappe.
Il y a pleins de sécurités qui ont été ajoutés, mais dans un monde ou les processeurs et divers composants chargent leur firmware et/ou microcodes depuis des zones modifiables, il y a encore (ou plutôt de nouveau) moyen de faire des trucs sympas.
J'ai encore du mal à comprendre comment il est possible de comparer ces deux finalistes, ces domaines étant si différents.
C'est vrai il y en a un qui a trouvé un noyau avec lequel on peut faire ce que l'on veut, le distribuer comme on veut et l'installer ou on veut pour remplacer de l'existant vieillissant ou déficient, et l'autre c'est Linus Torvalds…
a) Les asiatiques n'utiliseront pas UTF-X, et ils ne sont clairement pas fan d'unicode. L'unification des Han leur a filé des boutons. Les asiatiques veulent pouvoir faire la différence entre un signe avec une graphie chinoise et le même signe (au sens point unicode) avec uen graphie japonaise. Unicode ne permet pas cette distinction. Pour l'instant ils bricolent avec des polices différentes en fonction de l'encoding.
b) Si un jour les asiatiques venaient à utiliser un UTF-X de façon globale, (ce qui n'est clairement pas gagné) ca serait probablement plutôt UTF-16 pour des raisons de place gagné et de mapping 1-1 des anciens encodings.
c) Je me fous complètement que l'Asie utilise UTF-8/16 GB18030 ou tout autre encoding du moment que c'est à peu prêt cohérent. Quand je reçoit un document chinois de Chine, je sais qu'il va être en GB18030 et ca me va très bien.
d) Dans le cadre d'un shell ou du nommage des fichiers d'un FS, UCS-2 est un choix nettement plus intelligent que UTF-X. Certes certains caractères ne sont pas accessibles, mais au moins on a pas de caractères interdits dont on ne sait plus quoi foutre en cas de corruption de données. La plupart des programmes traitent d'ailleurs les chaines de caractères en UCS-2 en interne, parceque que c'est quand même nettement plus pratique.
e) Si mon opinion est que d'avoir un shell bloqué en UTF-8 ou UTF-16 est complètement con aujourd'hui (et probablement demain aussi, vu que la corruption de noms de fichiers peut toujours arriver même si la planête entière passe en UTF) Je n'ai rien contre UTF à l'intérieur d'un fichier. En fait du moment qu'un gentil meta m'indique l'encoding à utiliser je suis content.
En DECIMAL , J'ai un nombre identique quelques soit la date 999999999.
Oui c'est vrai, j'oublie toujours à quel point c'est ch… de transformer les timestamp en decimal sous MySQL.
En fait tu peux faire un select microseconds(expr) pour récupérer la partie décimale.
Mais bon vu que tu as déjà déterminer que le problème venait d'une comparaison de strings…
C'est un peu long à expliquer, et en plus je ne suis pas forcément au top sur les dernières versions de mysql.
Grosso-modo :
a) Mysql affiche et stoque des données à la seconde près, mais bosse en interne sur des microsecondes.
b) Sauf indications contraires la première colonne d'une table au format timestamp est forcément auto-initialisée/auto-updatée. Si vous empéchez ceci, la colonne suivante au format timestamp récolte de l'auto initialisation/auto-update par la suite etc.
CF https://linuxfr.org/nodes/89781/comments/1327695 (oui c'est pas beau de s'auter citer, mais là c'est vraiment pile poil le truc qui explique et on gagne du temps)
c) La valeur 0 dans un timestamp est très particulière, par défaut elle est interdite (donc renvoit un résultat faux quoi qu'il arrive) sauf si on autorise les dates à 0.
d) Par défaut toujours un timestamp ne peut pas être null.
A partir de là il peut se passer pleins de choses suivant le connecteur que tu utilises :
1- Quand il n'y a pas d'index, la comparaison se fait sur des entiers longs (normalement). Mais quand il y a un index pour une raison x,y ou z la comparaison se fait sur des strings. Et là tout peut se produire. En fait le problème peut même venir de ton .0 qui n'existera pas dans ton format de base. Et en chaine on a bien '2012-05-03 08:00:00.0'
Essaye de gicler le .0 et regarde ce qu'il se passe. C'est l'hypothèse la plus probable.
2- Autre possibilité, OVH a modifié le format de stockage des timestamp (comme il est possible de le faire depuis la 5.6.4 et peut être sur les versions précédentes avec les backports), et comme tu demandes explicitement les dizièmes de secondes il te stocke en décimal (ou pire en flotant). A l'affichage ca ne se voit pas car MySQL continue a ne prendre en compte que l'arrondi à la décimale supérieure, mais à la comparaison ca fache. Il manque quelques dizièmes de secondes pour que ca passe.
Pour valider il suffit de faire un select de la date avec un cast sur un décimal et de regarder sil y a bien que des 0 dans la partie décimale. Moins probable mais possible.
3- Ton connecteur interprête la requète différamment suivant qu'il s'agisse d'une colonne avec index ou non, et quand il y a un index il décide de forcer la comparaison directement sur le type timestamp - et là c'est le drame, la comparaison renvoit un timestamp à 0, qui est interdit => comparaison forcément fausse. Très improbable, csi c'est le cas il y a un gros bug dans le connecteur.
Dans ce cas tu es d'accord qu'un shell UTF-8 pur n'a de sens que si tout le monde utilise un shell UTF-8 pur depuis des années. Parceque sinon les problèmes évoqués sont pour le moins génant.
T'es contre l'utilisation d'UTF-8 partout et pour tout, donc t'es contre UTF-8. ;-)
Même avec le smiley, ca ne me fait pas trop rire. Comme tous les trucs qui deviennent des dogmes plutôt que des solutions techniques.
Ben UCS-2 (ou UTF-16, parce que c'est pas loin d'être la même chose) apporte rien à un occidental par rapport à UTF-8 à part que ça prend plus de place en mémoire et sur les disques durs. (oui j'ai conscience d'alimenter un dialogue de sourds)
UTF-16 et UCS-2 sont proches au niveau character map, mais au niveau du concept ca n'a rien à voir. En UCS-2 tout est sur deux octets et puis c'est tout. Alors que vache UTF-16 pour décoder une chaine il faut sortir la tronconneuse (et encore de gros efforts on été fait pour simplifier les boulot des devs par rapport aux premières versions, on est plus obligé de parser toute la chaine pour connaitre la valeur d'un caractère). Les high et les low surrogate c'est d'une lourdeur. Je veux extraire le 27ème caractère d'une chaine UCS-2, je fais un bon de 54 octets depuis le début la chaine. En UTF-8 ou 16….
Pas mal de programme utilisent UCS-2 en interne et n'utilisent UTF que pour le stockage et la lecture.
Et il y a des caractères interdits en UCS-2 (enfin des caractères réservés, qui justement rendent UTF-16 possible).
Non juste non utilisés pour faciliter le mapping. Mais tout à fait légaux, il ne correspondent juste pas à un glyphe.
Et c'est à Pékin qu'on écrit les normes. ;-)
Autant le Tibet d'accord, autant Taiwan les normes de Pekin….
Il y a un tableau bien fait pour combattre tes préjugés ici (si ça t'intéresse vraiment):
C'est à dire que le seul "préjugé" que tu combats c'est de m'expliquer que les caractères asiatiques en UTF-8 sont codés sur 3 caractères et non 4.
Après tout le reste (non correspondance des mappings, problèmes de caractères interdits, problème du shift lock, soucis pour travailler avec le reste du monde etc.) tu ne l'évoques même pas.
De plus tu as l'air de penser que je suis anti UTF-8, alors que je suis anti UTF-8 dans un shell quand c'est la seule solution.
Pour finir (et juste pour info) le GB18030-2005 est utilisé par
- La Chine
- Le Tibet
- La Mongolie
- Partiellement la Thailande
Taiwan ne s'en sert pas à ma connaissance, mais c'est principalement pour bien montrer à la Chine qu'ils sont idépendants.
Après effectivement pour le Japon, la Corée, le Vietnam et partiellement la Thailande c'est de l'UTF-16 majoritairement pour les points unicode.
Les asiatiques survivrons à +50% (et j'ose la plaisanterie: en plus c'est eux qui fabriquent les disques durs et la RAM!).
Oui, si ca leur apporte quelque chose. UCS-2 apporte quelquechose à un occidental (et en plus il n'y a pas de caractères interdits en UCS-2) par rapport à ASCII ou ISO. Mais qu'apporte UTF-8 à un oriental par rapport à UTF-16 ?
Oui c'est pour ça qu'il ne faut en utiliser qu'un seul pour tous les fichiers d'un filesystem donné. Et tant qu'à en utiliser qu'un seul, UTF-8 n'est pas pire qu'ASCII-7.
ASCII-7 (ou même ANSI complet sur toute la plage 32-255) va créer des erreurs d'affichage, UTF-8 va créer des erreurs d'execution. C'est largement pire.
Un bien bel exemple de ce qui se passe quand deux programmes écrivent des noms de fichiers dans le même filesystems avec des encodages différents.
Tu ne travailles qu'avec des gens en qui sont en pur UTF-8 ? Et eux-même ne travaillent qu'avec des gens qui sont en pur UTF-8 ? Parceque sinon tu prends le risque de mélanger les encodings à un moment ou à un autre. Rien que les sources du kernel linux ne passent pas un "make menuconfig" proprement. (Bon c'est juste moche, pas de dégats collatéraux - mais justement parceque les devs utilisent exclusivement ANSI dans le nommage des fichiers)
Les asiatiques sont censés faire la gueule d'avoir enfin un encodage qui permette de représenter tous les caractères dont ils peuvent avoir besoin et qui est interopérable et supporté par le monde occidental (celui qui considérait que 7 bits c'était assez) ?
Plutôt oui. Déjà si ils prennent un encoding ce sera UTF-16, pas UTF-8 sinon une grosse partie des caractères va se retrouver à occuper 4 octects au lieu de 2. Sur un ordinateur normal on s'en fout un peu (et encore, bonjour la gueule des bases de données) mais sur une solution embarquée ca ne passe juste pas.
Et comme seule la Chine utilise GB18030, on ne peut même pas parler de norme asiatique… (va faire du GB18030 au Japon…)
GB18030-2005 est justement la réponse de la Chine à UTF-8/UTF-16 qui reste compatible avec ASCII et l'ancien système GBK. Ils ont créé ce système à cause des nombreux problèmes que l'on peut rencontrer avec UTF-8 et UTF-16. Il couvre tout unicode (et largement même) donc rien n'empêche d'écrire en japonais avec GB18030-2005, mais il est peut rentable pour les caractères japonais ou corééns qui vont systématiquement se retrouver sur 4 octets.
De façon générale tout pays va chercher à faire un encoding qui
a) fait un mapping direct des caractères ASCII
b) dans la mesure du possible fait un mapping direct de l'ancienne norme en vigueur.
c) economise un maximum de place pour les caractères les plus utilisés dans le pays.
GB18030 est juste cela, un enconding qui respecte ASCII, GBK et qui essaye de mettre d'autres caractères dans les trous disponibles.
Tu veux dire utiliser exclusivement les caractères ASCII-7 ? ….. Mais le problème existait avant UTF-8.
Non le problème n'éxistait pas avant UTF-X. Certes il y avait déjà des caractères illégaux dans les noms de fichier, mais un caractère illégal n'a rien à voir avec un caractère interdit. En ASCII je vais juste me dire "mais quel est le con qui a foutu un CR dans un nom de fichier", en UTF-8 ca va donner un truc du genre "le nom de fichier n'est pas décodable, on fait quoi ?".
La norme UTF-8 (qui fort heureusement n'est pas respectée dans ce cas) dit qu'il faut dropper la séquence - donc pour un filesystem je me retrouve avec un fichier invisible et innacessible complètement, du moins jusqu'à ce que je change ma locale.
C'est vraiment dur les noms de fichiers. Donc soit tu n'utilises que des lettres ASCII-7 des chiffres et des underscores, soit tu as un et un seul encodage pour tout ton filesystem et à chaque fois que tu as une interface (ftp, sftp, webdav, git clone, unzip) tu t'assures de ne pas injecter de la merde.
Et tu t'en assures comment ? Un collègue sous windows t'envoies un .rar, un vieux logiciel métier sur une babasse de dix ans d'age a son code prisonnier dans un tar.gz. Tu fais quoi ? Perso je repasse en locale C, tout autre aproche étant casse gueule.
Et si t'as déjà plein de merde sur ton filesystem, tu peux aussi essayer convmv (yum/apt-get install convmv) pour qu'il te nettoie les choses sans que tu aies à gesticuler avec des "LANG=C mv toto*foo toto_foo" fais à la main.
Oui, et là tu te rends compte que pour lancer la compilation/faire fonctionner l'ETL/linker/ecrire dans le log etc. tu dois te frapper 8500 à la mano et en éditer le contenu (prie pour qu'il n'y ait pas trop de binaires dans le lot). En plus convmv ca me sert principalement à réparer les anneries faites par une personne qui pensait gagner du temps en l'utilisant. convmv est en perl, ce qui veut dire qu'il faut régler les locales et autres charmap de ton interpreteur perl avant de lancer la moindre conversion. Et si tu as des fichiers de plusieurs origines dans plusieurs encodings il vaut mieux reconfigurer entre chaque lot.
Là si je peux me permettre, tu confonds les effets de LANG sur le shell et sur les processus que tu lances. Si tu fixes LANG=C avant un git clone, tout va fonctionner car git clone ne t'enverra que de l'étatsunien en ascii7 qui ne donnera pas de bouton au shell (ni à ton émulateur de terminal) et git lui-même étant configuré en C et pas en C.UTF-8 créera les fichiers en conséquences
Déjà c'est pas juste LANG, mais toute la locale que je repasse en C et ensuite même si j'en ai rien à fiche des commentaires de commit (alors que bon en vrai ca m'interresse un peu) GIT ne dispose pas de moyen de modifier le code source à l'intérieur du contenu. Donc les fichiers auront des noms propres, mais je vais devoir me rééditer tout le contenu à la mano pour reprendre les includes, les chemins, les libs etc. Et quand le dev original voudra synchroniser il va se retrouver avec une tonne de modifs complètement con et les deux lignes de correction de bugs vont passer à la trappe, noyées sous un flot de destruction de fichiers et de création de nouveau fichiers. Bref GIT ne servira à rien et sera même contre productif. Seule solution => ASCII/ANSI.
(et que ça a déjà avec ton SSH à la place de Mosh)
Si ton SSH est en pur UTF-8 oui. Mais le truc c'est que justement le pur UTF-8 en shell ca ne marche pas. Maintenant moyennant deux ou trois essai j'arriverai à caler ma locale sur celle du dev et quand je travaillerais sur ce repo je passerais dans cette locale. C'est ce que mosh ne permet pas.
(bon j’arrête là parce qu'on est légèrement off topic quand même…)
On est pas off-topic du tout. La question est "un shell pur UTF-8, bonne ou mauvaise idée". Pour moi c'est une très mauvaise idée, pour toutes les raisons exposées.
Je ne comprends absolument pas cette obsession que tu as de vouloir mélanger dans le même filesystem des fichiers dont les noms son encodés différemment (je ne parle pas du contenu des fichiers bien sûr).
Le contenu des fichiers, on s'en fout. Si le programme qui est supposé ouvrir un fichier ne gère pas UTF-8, ben soit on ouvre avec un autre programme, soit on prend sur soi et on code un pacth. Sinon recode marche du feu de dieu dans la plupart des cas.
Par contre le shell lui c'est une autre paire de manche. Si le shell est en UTF-8, ca veut dire que tout un tas d'autres trucs doivent être en UTF-8, la locale le LANG moult parmètres pour less, perl, python, ruby etc. Sinon il va se passer de drôles de trucs à l'execution de certains scripts.
Mais bon ca c'est encore gérable.
Il n'y a pas de moyen de connaitre l'encoding d'un nom de fichier - Aucun meta ne permet de le savoir, du moins pas sur les filesystems classiques. A partir de là pour pouvoir utiliser des programmes aussi courants que tar, git-clone, unzip, perl, python etc. il faut :
- soit se mettre d'accord avec le monde entier pour que tout le monde utilise exclusivement un encoding. Par exemple UTF-8, mais les asiatiques vont faire la gueule.
- Soit utiliser exclusivement les caractères ANSI dans tous les scripts/archives/backups/repo/sources etc.
Sinon tu prends le risques réel que ton programme fasse n'importe quoi. Supposons que ton make clean fasse un rm -r sur /home/toi/┌/obj et que ton parseur bute sur le ┌ qu'il interprete comme une terminaison (Je sais ca ne peux pas être le cas avec ce caractère là, c'est même pour ça que je l'ai choisi). Il va se passer quoi à ton avis ? Déjà ton make clean ne finira pas, et ensuite tu vas avoir plein de place libre sur ton ~….
Pour éviter ce genre de conneries, la seule bonne méthode pour l'instant, en attendant que UTF-8 conquiert le monde entier ou que de meta apparaissent dans les filesystems c'est
a) D'utiliser exclusivement les caractères ANSI dans le noms de fichier qui peuvent être exportés
b) De passer en locale C avant tout git-clone, unzip, ./script.sh etc. Et seulement si ca ne marche pas de repasser dans la locale présumée du truc mais en faisant très gaffe à ce qu'on fait.
Ah au fait, repasser en locale C est la bonne solution pour shooter un fichier dont le nom en UTF-16 qui contient des caractères UTF-8 invalides. Des fois que ca interresse quelqu'un…
Sauf que dans un shell UTF-8 pur, ben on peut pas repasser en locale C.
Autre problème, mosh utilise SSH pour se connecter à la machine distante. Sauf que en SSH il faut déclarer le type de terminal et également remaper un certain nombre de combinaisons de touches. A partir de là soit toute la chaine (emulateur terminal, serveur ssh, shell) est en UTF-8, soit je suis curieux de savoir ce qui va se passer quand je vais faire ctrl+H.
mais de là à t'en servir d'argument pour justifier ton point initial, à savoir qu'UTF-8 utilisé pour la communication en shell ne fonctionne pas à cause de bugs noyau (je te cite)
Ce n'est pas très grave pour la discussion en cours, mais ce n'est pas moi que tu vas citer.
parce que la led num lock ne s'allume pas dans certains cas en console,
Il ne s'agit pas de la led numlock, mais de la led capslock. Ou pour être exact à cause du local echo les caractères vont s'afficher en local comme si il s'agissait d'un caps lock mais être interpretés par mosh en bout de chaine comme si il s'agissait d'un shiftlock.
Par exemple si je tape 88 via le pavée numérique en capslock chez moi, je verais s'afficher 88 sur mon emulateur terminal, mais le shell recevra deux fois l'instruction "commande précédente". Ca peut faire des trucs très drôle. Par exemple tu penses avoir lancé un worker tomcat sur le port 8088 ? Perdu tu as réexecuté la commande 3 slots plus haut et tu es passé en mode insertion.
t'as pas l'impression de tout mélanger façon quand on veut tuer UTF-8 on dit qu'il a la rage?
Non, quand on veut tuer UTF-8 on le présente comme la solution absolue à tous les problèmes dans tous les cas et sur toutes les machines. Alors bien sur il y a des gens qui vont y croire, mais au bout du 15ème incident incompréhensible ils vont gentillement repasser leur machine en ISO/ANSI/C parceque ca marche. Et là miracle, même si ça affiche parfois n'importe quoi, ca ne casse pas tout de façon hyper chiante à debugguer.
UTF-8 est un bon format pour les documents avec des métas qui sont capables de signaler "je suis en UTF-8". mais pour les shells et les noms de fichiers, j'évite.
Toi quand une ampoule grille chez toi, tu ne la changes pas, tu décrètes qu'il n'y a pas besoin de gérer l'obscurité…
Excellente analogie. Félicitation.
Si tu veux faire une analogie aussi terre à terre on va plutôt dire :
Quand tu as du 220v chez toi, comment tu fais pour brancher un appareil 110v ?
a) Tu branches pas
b) Tu mets un gros transfo (conversion à la volée de la tension, avec probablement une limitation en puissance), mais sous Linux il n'existe pas de modules qui permette de convertir à la volée les noms de fichiers d'un encodage à l'autre.
c) Tu branches quand même et pis tant pis si ca claque.
Maintenant avec tous les moinssages que j'ai reçu, personne n'a répondu à la question : comment faire en UTF-8 pour ouvrir un fichier dont le nom est en UTF-16 et contient un caractère interdit en UTF-8.
A noter qu'en bête ANSI, les noms de fichiers UTF-8/UTF-16 et même CP1252 ou ISO sont accessibles aussi bien programatiquement que via le shell, moyennant des échapements et ou des jokers.
Ben en ce qui me concerne tu fais ce que tu veux chez toi, mais perso je vais quand même continuer à changer les ampoules qui claquent et à utiliser UTF-8 partout.
Ce que tu utilises chez toi fonctionnera toujours, si tu décides d'utiliser exclusivement IBM-1364 ca marchera. Le problème c'est ce que tu utilises chez les autres et ce que les autres utilisent chez toi. Si je t'envoie un fichier en ISO-8859-15, vu que tu utilses UTF-8 partout j'en déduis que tu ne l'ouvriras pas. Donc tu ne changeras pas non plus l'ampoule…
Il est important de laisser les gens compétents là ou ils sont et de promouvoir les incompétents à des postes décisionnels et de management pour limiter leur impact sur les gens compétents.
et au milieu un fichier qui porte un nom en ISO-8859-15. Ha ben merde, comment je fais ?
Le symbole € ne s'affichera pas correctement. C'est tout. A la place tu verras le symbole monétaire international ¤, rien de bien méchant. Avec un clavier français, en faisant Alr Gr+e tu pourras éditer et modifier ce fichier sans même recourir aux jokers.
A exécuter dans un navigateur qui comprend le js. Et hop, je viens d'écrire de l'unicode en ISO-8859-1. Alors, il est où le problème finalement ?
Essaye de faire ca dans un shell, comme Mosh par exemple. Et regarde la gueule que fait ton interpreteur. Surtout que afficher des caractères c'est une chose, mais les interpreter s'en est une autre. De mémoire c'est quoi le code unicode de 국 par exemple ? Tu vas en avoir besoin pour accéder au fichier…
Ton problème de rennomage c'est la même chose entre ISO-8859-1 et CP-1252 par exemple.
Non, les caractères posant problème en CP-1252 (i.e les caractères de 128 à 159) qui ne transcrivent pas en ISO-8859 peuvent être échappés facilement avec des antislash en code ou avec des caractères joker (? et * principalement) en shell. Le problème est nettement plus simple à traiter.
Ha oui, et comment tu gères le € sur un ISO-8859-1 ?
Tu ne le gères pas. Si tu as besoin du symbole € tu prends un autre charmap.
Et comment, dans ton approche traditionnelle, tu gères un fichier coréen ?
Le nom du fichier va être explosé en une suite de caractères (imprimables ou non) que je peux récupérer de la même façon que je récupères les noms de fichiers incorrects. En échappant ou en utilisant des jokers. C'est moche, mais ça marche.
UTF-8 c'est bien pour l'affichage d'un texte non corrompu. Mais bon sur un texte avec des erreurs qui ont générées des caractères interdits ou pour une saisie interactive, c'est déjà nettement plus discutable. Ne serait-ce que d'avoir un système qui tolère les noms de fichiers en UTF-X c'est un bordel sans nom. Tiens question : sous un système comme mosh, qui est pur UTF-8 comment on fait pour effacer un fichier dont le nom est codé en UTF-16 (par exemple un fichier nommé en Coréen) ? Point bonus si tu sais dire comment éditer un fichier dont le nom en UTF-16 contient un caractère interdit en UTF-8.
Unicode c'est comme IPv6, sur le papier c'est génial, dans la pratique on s'en sort souvent mieux avec une approche plus traditionnelle.
Qu'est-ce que tu leur avais choisi comme distribution inadaptée, qui ne dure même pas un an et demi sans mise à jour majeure ?
Qui te dis qu'il n'y a pas eu de mises à jour majeures. C'est juste que les mises à jour (majeures ou non) cassent les installs, les réglages persos, la compatibilité hardware etc.
Comme indiqué j'ai fait Fedora (ca a pas marché - mais je me suis dit que c'était à cause du modèle assez expérimental de la distrib) puis je suis passé sous Suse d'un coté et Ubuntu de l'autre. Ca n'a pas marché non plus.
Et sera vendu pendant combien de temps ? Si les gens ne peuvent plus acheter 7, il seront obligé de passer à 8 au changement de matériel
Alors c'est typiquement l'argument qui ne tient plus.
D'une part l'équipement qui n'est plus fonctionnel sous Windows Vista et consort (à savoir une poignée de scanners, d'imprimantes multifonctions, de cartes réseaux wifi ou non et de cartes d'aquisitions video) n'est plus fonctionnel sous Linux non plus. V4L a giclé, une bonne partie des pilotes madwifi anciens (notamment au niveau des variantes atheros 5k) se sont barrés en fumée etc.
Alors certes il existe des pilotes qui fonctionnent encore sous Linux et qui ne marchent plus sous windows 7, mais la réciproque est vraie.
D'autre part sur une machine portable vieille de trois ou quatre ans il y a plus de chance qu'elle soit compatible complètement avec windows 7 qu'avec Linux. Même si elle au moment de l'achat elle était complètement compatible Linux. Les hacks ACPI s'en vont gentillement du kernel après un ou deux ans, la prise en charge de certaines touches (notamment les touches d'activation/désactivation du wifi) part en vrille et j'en passe.
En plus Linux devient furieusement gourmand, les nouvelles versions de tout un tas de logiciels phares de l'eccosystème Linux font de plus en plus appel à des dépendances à la con. Et vas-y que je remonte tout le projet Gnome en bleeding edge tout ça parceque je veux pouvoir écrire des formules mathématiques dans Abiword, et vas-y que j'installe la moité de tous les packages connus de freedesktop pour pouvoir faire un copier/coller. Et on ne va pas parler du son sous Linux parceque sinon je vais encore m'ennerver.
Bref début 2009 j'ai acheté des portables ASUS full compatible Linux (fonctionnement impécable sous Suse, Fedora et Ubuntu) pour mes deux grand mères et ma mère, et mi 2010 je passais tout le monde sous Vista parceque j'en avais marre de maintenir un repo complet de patchs à la con pour que le wifi et les touches spéciales fonctionnent, pour que la luminosité de l'écran soit un temps soit peu cohérente, pour que verrou numérique reste dans la position voulue même en cas de changement d'appli, pour que le volume de lecture de CD audio soit enregistré proprement, pour que le montage de clefs USB se fassent là ou les utilisateurs s'atendent à la voir et avec un nom qu'ils connaissent, pour que network manager ne casse pas mon paramétrage WPA-Supplicant etc. Et là on parle d'utilisateurs très très basiques qui ne font ni 3D ni audio poussé et qui lisent leurs mails sur des webmails la plupart du temps (dieu merci parceque l'option de recherche indexée sous thunderbird j'en ai soupé sur mes machines persos).
Donc l'argument "Ah ben oui mais sous Windows tu n'es pas sur que tu pourras mettre à jour ton système dans 5 ans" il me fait doucement rigoler. Sous Linux tu n'es pas sur que tu pourras mettre à jour dans 8 mois, en tout cas pas sans un admin sys qui t'assiste pas à pas.
En fait, il faudrait une toolchain avec une libc, libm et libgcc compilée avec toutes les cibles ARM pour que ce soit efficace
Oui en plus il faut rajouter toutes les variations d'ARM et le fait que les différents bus varient d'une plateforme à l'autre.
En fait sous ARM c'est plutôt une plateforme = un toolchain. Dejà tu as de la chance si la même toolchain fonctionne entre la v1 et la v2 d'un même device.
- Ils "oublient" que 1800 en loyer c'est charges comprises, en emprunt c'est sans les charges. Ca rajoute…
Pour la majeure partie, le prix de la location dans un marché saturé (comprendre à peu près toutes les grandes villes un peu dynamique : Paris, Lyon, Lille, Toulouse etc.) le prix du loyer est sensiblement égal à la mensualité d'achat sur un prêt de durée conventionnel avec un apport de 15%. En 1996 la durée conventionnelle était de 12 ans, avec des prêts pouavnt aller jusqu'à 17 ans. Aujourd'hui la durée conventionelle est de 20 ans avec des prêts pouvant aller jusqu'à 25 ans (qui deviennent la norme à Paris…).
8
En fait le propriétaire "perd" les 15% d'apport mais derrière il les récupère aux alentours de la 7ème/8ème année (avant aux alentours de la 5ème/6ème année).
Par contre ce qu'il faut bien voir c'est que dès la troisième année les mensualités de remboursement seront sensiblement égales au loyer pour un bien donné (toujours dans une région dense avec un marché saturé). Sauf accident de parcours (licenciement, faillite, chommage) le propriétaire d'un bien a tout intéret à garder celui-ci et à le louer plutôt qu'à le revendre. Sa dette et ses revenus s'annuleront sur ce point. Maintenant il y a effectivement prise de risque, mais il n'y a pas 30% de différence entre le proprio et le locataire, 10 ou 12% maximum et en début de prêt.
Ouais OK on le dira à tous les petits propriétaires
Merci de lire l'ensemble du texte avant de régair, il s'agit ici du propriétaire du bien qu'il habite par opposition au locataire d'un même bien. Mon texte contient en plus de nombreux exemples qui ne laissent aucun doute sur ce que j'ai voulu dire.
Ah… L'Achat vs la location… C'est très latin comme idée de vouloir à tous prix être proprio.
Le problème est que l'achat fournit une grosse sécurité par rapport à la location. Bien sur il n'est pas forcément intelligent d'acheter coute que coute, et la technique qui ocnsiste à acheter de petites surfaces et de les mettre en location tout en louant soi-même sa résidence principale est assez interressante dans bon nombre de cas.
Seulement malgré les nombreuses protections dont dispose le locataire, le propriétaire est systèmatiquement très avantagé en terme d'assurance.
Quelques exemples :
Assurance decès : si je meurs sans avoir finit de payer mon crédit, le bien peut revenir de plein droit à ma famille - libéré de tout emprunt. Mieux, si je suis marié avec des enfants, ma femme possède l'usufruit du bien jusqu'à sa mort. Vous connaissez une assurance qui va payer le loyer d'un appart jusqu'à la mort de ma femme en cas de décès ? Moi pas.
Assurance chomage/faillite financière : si je suis dans l'incapacité financière de finir de payer mon crédit, l'assurance prend en charge les paiements sur une durée variable, ou au moins reporte les échéances. Bonus : je peux prendre en plus une hypothèque sur le captial déjà remboursé pour rebondir. Rien de tout celà en locatif.
Divorce : En supposant que madame ait la garde des enfants, elle n'a pas à se casser la tête pour trouver un logement, elle n'a pas à notifier qui que ce soit d'un changement de statuts. De pus les versements pour rembourser le crédit et l'usage de l'appartement sont déduits de la pension alimentaire. Et en cas de nouveau changement de statut, l'appart est toujours disponible.
Eviction forcée : Même quand on paye régulièrement son loyer, on peut se faire jeter facilement. Soit pour cause de vente du bien, soit pour mise à disposition gratuite du bien à des membres de la famille du propriétaire. Quand on est dans une situation nécessitant une forte mobilité, se retrouver à devoir changer d'appart alors qu'il y a possibilité de déménagement dans les 6 mois, c'est complexe. Avec un bien à l'achat, la location du bien ou même le crédit relais sont des options qui permettent de respirer.
Et il y a des dizaines de cas ou la location, bien qu'economiquement avantageuse sur le papier, devient un problème très complexe à gérer.
intérêt du scrutin majoritaire à 2 tours est que tout le monde le comprend
Pour être exact croit le comprendre. Et puis ca fait des surprises des fois, comme d'avoir une gauche majoritaire et un second tour droite vs extreme droite. Et donc un candidat de droite élu avec plus de 70% des voix dans un pays ou 52% des votants sont à gauche.
Comprendre un système de vote veut principalement dire comprendre ce que le résultat donné par ce système veut dire. Et il y a très peu de gens qui savent ce que veut dire "M. X a été élu au second tour avec 54% des suffrages".
La mécanique est simple certes, mais tout un tas d'arnaques et d'escroqueries ont elle aussi des mécaniques simples (montages pyramidaux par exemple). Que le fonctionnement soit simple est une chose, que le résultat soit compréhensible en est une autre.
[^] # Re: Juridiquement...
Posté par Kaane . En réponse au journal C'est une arme redoutable.. Évalué à 5.
Un chiwawa est un animal, ça peut être une arme avec cette définition! :)
Etre sous la menace d'un chiwawa c'est loin d'être risible. C'est assez terrifiant comme bestiole.
[^] # Re: Juridiquement...
Posté par Kaane . En réponse au journal C'est une arme redoutable.. Évalué à 0.
Il me semble, corrige-moi si je me trompe, que la personne a attaqué non pas sans objet (à main nues), mais avec un objet (la chantilly en l’occurrence)
Le problème de la définition du Larousse (qui est juste au sens commun, l'est elle au sens légal ?) c'est qu'elle décale le paradygme de l'agression sur un autre mot : attaquer.
C'est à dire que tout objet,appareil ou engin qui sert à attaquer est une arme.
Pour autant peut-on qualifier un entartage d'attaque ?
Voyons la définition du mot attaquer dans le même dictionnaire :
http://www.larousse.com/en/dictionaries/french/attaquer
Apparament il y a le sens familier d'attaquer qui est synonyme de commencer un plat. Donc on peut attaquer de la chantilly, mais pour autant on est pas beaucoup plus avancé…
[^] # Re: Hein ?
Posté par Kaane . En réponse au journal Après Stuxnet, le virus Viper force l'Iran à arrêter les installations pétrolières de l’île de Kharg. Évalué à 1.
Hein ? C'est possible pour un virus logiciel de péter des composants matériels ? Ou alors y'a un truc qui m’échappe.
Il y a pleins de sécurités qui ont été ajoutés, mais dans un monde ou les processeurs et divers composants chargent leur firmware et/ou microcodes depuis des zones modifiables, il y a encore (ou plutôt de nouveau) moyen de faire des trucs sympas.
[^] # Re: Comparaison impossible ?
Posté par Kaane . En réponse à la dépêche Linus Torvalds sélectionné pour le Millennium Technology Prize édition 2012 . Évalué à 8.
J'ai encore du mal à comprendre comment il est possible de comparer ces deux finalistes, ces domaines étant si différents.
C'est vrai il y en a un qui a trouvé un noyau avec lequel on peut faire ce que l'on veut, le distribuer comme on veut et l'installer ou on veut pour remplacer de l'existant vieillissant ou déficient, et l'autre c'est Linus Torvalds…
[^] # Re: Bof
Posté par Kaane . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 0.
Bon c'est sans espoir apparament mais au cas ou :
a) Les asiatiques n'utiliseront pas UTF-X, et ils ne sont clairement pas fan d'unicode. L'unification des Han leur a filé des boutons. Les asiatiques veulent pouvoir faire la différence entre un signe avec une graphie chinoise et le même signe (au sens point unicode) avec uen graphie japonaise. Unicode ne permet pas cette distinction. Pour l'instant ils bricolent avec des polices différentes en fonction de l'encoding.
b) Si un jour les asiatiques venaient à utiliser un UTF-X de façon globale, (ce qui n'est clairement pas gagné) ca serait probablement plutôt UTF-16 pour des raisons de place gagné et de mapping 1-1 des anciens encodings.
c) Je me fous complètement que l'Asie utilise UTF-8/16 GB18030 ou tout autre encoding du moment que c'est à peu prêt cohérent. Quand je reçoit un document chinois de Chine, je sais qu'il va être en GB18030 et ca me va très bien.
d) Dans le cadre d'un shell ou du nommage des fichiers d'un FS, UCS-2 est un choix nettement plus intelligent que UTF-X. Certes certains caractères ne sont pas accessibles, mais au moins on a pas de caractères interdits dont on ne sait plus quoi foutre en cas de corruption de données. La plupart des programmes traitent d'ailleurs les chaines de caractères en UCS-2 en interne, parceque que c'est quand même nettement plus pratique.
e) Si mon opinion est que d'avoir un shell bloqué en UTF-8 ou UTF-16 est complètement con aujourd'hui (et probablement demain aussi, vu que la corruption de noms de fichiers peut toujours arriver même si la planête entière passe en UTF) Je n'ai rien contre UTF à l'intérieur d'un fichier. En fait du moment qu'un gentil meta m'indique l'encoding à utiliser je suis content.
[^] # Re: Le bug c'est la requete
Posté par Kaane . En réponse au journal Aujourd'hui, petit bug d'un serveur MySql d'OVH. Évalué à 0.
En DECIMAL , J'ai un nombre identique quelques soit la date 999999999.
Oui c'est vrai, j'oublie toujours à quel point c'est ch… de transformer les timestamp en decimal sous MySQL.
En fait tu peux faire un select microseconds(expr) pour récupérer la partie décimale.
Mais bon vu que tu as déjà déterminer que le problème venait d'une comparaison de strings…
[^] # Re: Le bug c'est la requete
Posté par Kaane . En réponse au journal Aujourd'hui, petit bug d'un serveur MySql d'OVH. Évalué à 2.
C'est un peu long à expliquer, et en plus je ne suis pas forcément au top sur les dernières versions de mysql.
Grosso-modo :
a) Mysql affiche et stoque des données à la seconde près, mais bosse en interne sur des microsecondes.
b) Sauf indications contraires la première colonne d'une table au format timestamp est forcément auto-initialisée/auto-updatée. Si vous empéchez ceci, la colonne suivante au format timestamp récolte de l'auto initialisation/auto-update par la suite etc.
CF https://linuxfr.org/nodes/89781/comments/1327695 (oui c'est pas beau de s'auter citer, mais là c'est vraiment pile poil le truc qui explique et on gagne du temps)
c) La valeur 0 dans un timestamp est très particulière, par défaut elle est interdite (donc renvoit un résultat faux quoi qu'il arrive) sauf si on autorise les dates à 0.
d) Par défaut toujours un timestamp ne peut pas être null.
Il est bon de lire aussi le mode de comparaison de timestamp chez mysql, qui vaut le détour : http://dev.mysql.com/doc/refman/5.0/en/using-date.html
A partir de là il peut se passer pleins de choses suivant le connecteur que tu utilises :
1- Quand il n'y a pas d'index, la comparaison se fait sur des entiers longs (normalement). Mais quand il y a un index pour une raison x,y ou z la comparaison se fait sur des strings. Et là tout peut se produire. En fait le problème peut même venir de ton .0 qui n'existera pas dans ton format de base. Et en chaine on a bien '2012-05-03 08:00:00.0' Essaye de gicler le .0 et regarde ce qu'il se passe. C'est l'hypothèse la plus probable.
2- Autre possibilité, OVH a modifié le format de stockage des timestamp (comme il est possible de le faire depuis la 5.6.4 et peut être sur les versions précédentes avec les backports), et comme tu demandes explicitement les dizièmes de secondes il te stocke en décimal (ou pire en flotant). A l'affichage ca ne se voit pas car MySQL continue a ne prendre en compte que l'arrondi à la décimale supérieure, mais à la comparaison ca fache. Il manque quelques dizièmes de secondes pour que ca passe.
Pour valider il suffit de faire un select de la date avec un cast sur un décimal et de regarder sil y a bien que des 0 dans la partie décimale. Moins probable mais possible.
3- Ton connecteur interprête la requète différamment suivant qu'il s'agisse d'une colonne avec index ou non, et quand il y a un index il décide de forcer la comparaison directement sur le type timestamp - et là c'est le drame, la comparaison renvoit un timestamp à 0, qui est interdit => comparaison forcément fausse. Très improbable, csi c'est le cas il y a un gros bug dans le connecteur.
[^] # Re: Le bug c'est la requete
Posté par Kaane . En réponse au journal Aujourd'hui, petit bug d'un serveur MySql d'OVH. Évalué à 0. Dernière modification le 21 avril 2012 à 13:26.
expliquant comment le système est capable d'effectuer & d'optimiser plus rapidement deux comparaisons plutôt qu'une seule !
Ca va quasiment aussi vite que
Surtout sur des formats ou le signe est porté par un bit de poids fort. dasn ce cas le abs() c'est juste un xor.
[^] # Re: Bof
Posté par Kaane . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 0.
Parce que j'ai rien à dire dessus.
Dans ce cas tu es d'accord qu'un shell UTF-8 pur n'a de sens que si tout le monde utilise un shell UTF-8 pur depuis des années. Parceque sinon les problèmes évoqués sont pour le moins génant.
T'es contre l'utilisation d'UTF-8 partout et pour tout, donc t'es contre UTF-8. ;-)
Même avec le smiley, ca ne me fait pas trop rire. Comme tous les trucs qui deviennent des dogmes plutôt que des solutions techniques.
Ben UCS-2 (ou UTF-16, parce que c'est pas loin d'être la même chose) apporte rien à un occidental par rapport à UTF-8 à part que ça prend plus de place en mémoire et sur les disques durs. (oui j'ai conscience d'alimenter un dialogue de sourds)
UTF-16 et UCS-2 sont proches au niveau character map, mais au niveau du concept ca n'a rien à voir. En UCS-2 tout est sur deux octets et puis c'est tout. Alors que vache UTF-16 pour décoder une chaine il faut sortir la tronconneuse (et encore de gros efforts on été fait pour simplifier les boulot des devs par rapport aux premières versions, on est plus obligé de parser toute la chaine pour connaitre la valeur d'un caractère). Les high et les low surrogate c'est d'une lourdeur. Je veux extraire le 27ème caractère d'une chaine UCS-2, je fais un bon de 54 octets depuis le début la chaine. En UTF-8 ou 16….
Pas mal de programme utilisent UCS-2 en interne et n'utilisent UTF que pour le stockage et la lecture.
Et il y a des caractères interdits en UCS-2 (enfin des caractères réservés, qui justement rendent UTF-16 possible).
Non juste non utilisés pour faciliter le mapping. Mais tout à fait légaux, il ne correspondent juste pas à un glyphe.
Et c'est à Pékin qu'on écrit les normes. ;-)
Autant le Tibet d'accord, autant Taiwan les normes de Pekin….
[^] # Re: Bof
Posté par Kaane . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 1.
Il y a un tableau bien fait pour combattre tes préjugés ici (si ça t'intéresse vraiment):
C'est à dire que le seul "préjugé" que tu combats c'est de m'expliquer que les caractères asiatiques en UTF-8 sont codés sur 3 caractères et non 4.
Après tout le reste (non correspondance des mappings, problèmes de caractères interdits, problème du shift lock, soucis pour travailler avec le reste du monde etc.) tu ne l'évoques même pas.
De plus tu as l'air de penser que je suis anti UTF-8, alors que je suis anti UTF-8 dans un shell quand c'est la seule solution.
Pour finir (et juste pour info) le GB18030-2005 est utilisé par
- La Chine
- Le Tibet
- La Mongolie
- Partiellement la Thailande
Taiwan ne s'en sert pas à ma connaissance, mais c'est principalement pour bien montrer à la Chine qu'ils sont idépendants.
Après effectivement pour le Japon, la Corée, le Vietnam et partiellement la Thailande c'est de l'UTF-16 majoritairement pour les points unicode.
Les asiatiques survivrons à +50% (et j'ose la plaisanterie: en plus c'est eux qui fabriquent les disques durs et la RAM!).
Oui, si ca leur apporte quelque chose. UCS-2 apporte quelquechose à un occidental (et en plus il n'y a pas de caractères interdits en UCS-2) par rapport à ASCII ou ISO. Mais qu'apporte UTF-8 à un oriental par rapport à UTF-16 ?
[^] # Re: Bof
Posté par Kaane . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 1.
Oui c'est pour ça qu'il ne faut en utiliser qu'un seul pour tous les fichiers d'un filesystem donné. Et tant qu'à en utiliser qu'un seul, UTF-8 n'est pas pire qu'ASCII-7.
ASCII-7 (ou même ANSI complet sur toute la plage 32-255) va créer des erreurs d'affichage, UTF-8 va créer des erreurs d'execution. C'est largement pire.
Un bien bel exemple de ce qui se passe quand deux programmes écrivent des noms de fichiers dans le même filesystems avec des encodages différents.
Tu ne travailles qu'avec des gens en qui sont en pur UTF-8 ? Et eux-même ne travaillent qu'avec des gens qui sont en pur UTF-8 ? Parceque sinon tu prends le risque de mélanger les encodings à un moment ou à un autre. Rien que les sources du kernel linux ne passent pas un "make menuconfig" proprement. (Bon c'est juste moche, pas de dégats collatéraux - mais justement parceque les devs utilisent exclusivement ANSI dans le nommage des fichiers)
Les asiatiques sont censés faire la gueule d'avoir enfin un encodage qui permette de représenter tous les caractères dont ils peuvent avoir besoin et qui est interopérable et supporté par le monde occidental (celui qui considérait que 7 bits c'était assez) ?
Plutôt oui. Déjà si ils prennent un encoding ce sera UTF-16, pas UTF-8 sinon une grosse partie des caractères va se retrouver à occuper 4 octects au lieu de 2. Sur un ordinateur normal on s'en fout un peu (et encore, bonjour la gueule des bases de données) mais sur une solution embarquée ca ne passe juste pas.
Et comme seule la Chine utilise GB18030, on ne peut même pas parler de norme asiatique… (va faire du GB18030 au Japon…)
GB18030-2005 est justement la réponse de la Chine à UTF-8/UTF-16 qui reste compatible avec ASCII et l'ancien système GBK. Ils ont créé ce système à cause des nombreux problèmes que l'on peut rencontrer avec UTF-8 et UTF-16. Il couvre tout unicode (et largement même) donc rien n'empêche d'écrire en japonais avec GB18030-2005, mais il est peut rentable pour les caractères japonais ou corééns qui vont systématiquement se retrouver sur 4 octets.
De façon générale tout pays va chercher à faire un encoding qui
a) fait un mapping direct des caractères ASCII
b) dans la mesure du possible fait un mapping direct de l'ancienne norme en vigueur.
c) economise un maximum de place pour les caractères les plus utilisés dans le pays.
GB18030 est juste cela, un enconding qui respecte ASCII, GBK et qui essaye de mettre d'autres caractères dans les trous disponibles.
Tu veux dire utiliser exclusivement les caractères ASCII-7 ? ….. Mais le problème existait avant UTF-8.
Non le problème n'éxistait pas avant UTF-X. Certes il y avait déjà des caractères illégaux dans les noms de fichier, mais un caractère illégal n'a rien à voir avec un caractère interdit. En ASCII je vais juste me dire "mais quel est le con qui a foutu un CR dans un nom de fichier", en UTF-8 ca va donner un truc du genre "le nom de fichier n'est pas décodable, on fait quoi ?".
La norme UTF-8 (qui fort heureusement n'est pas respectée dans ce cas) dit qu'il faut dropper la séquence - donc pour un filesystem je me retrouve avec un fichier invisible et innacessible complètement, du moins jusqu'à ce que je change ma locale.
C'est vraiment dur les noms de fichiers. Donc soit tu n'utilises que des lettres ASCII-7 des chiffres et des underscores, soit tu as un et un seul encodage pour tout ton filesystem et à chaque fois que tu as une interface (ftp, sftp, webdav, git clone, unzip) tu t'assures de ne pas injecter de la merde.
Et tu t'en assures comment ? Un collègue sous windows t'envoies un .rar, un vieux logiciel métier sur une babasse de dix ans d'age a son code prisonnier dans un tar.gz. Tu fais quoi ? Perso je repasse en locale C, tout autre aproche étant casse gueule.
Et si t'as déjà plein de merde sur ton filesystem, tu peux aussi essayer convmv (yum/apt-get install convmv) pour qu'il te nettoie les choses sans que tu aies à gesticuler avec des "LANG=C mv toto*foo toto_foo" fais à la main.
Oui, et là tu te rends compte que pour lancer la compilation/faire fonctionner l'ETL/linker/ecrire dans le log etc. tu dois te frapper 8500 à la mano et en éditer le contenu (prie pour qu'il n'y ait pas trop de binaires dans le lot). En plus convmv ca me sert principalement à réparer les anneries faites par une personne qui pensait gagner du temps en l'utilisant. convmv est en perl, ce qui veut dire qu'il faut régler les locales et autres charmap de ton interpreteur perl avant de lancer la moindre conversion. Et si tu as des fichiers de plusieurs origines dans plusieurs encodings il vaut mieux reconfigurer entre chaque lot.
Là si je peux me permettre, tu confonds les effets de LANG sur le shell et sur les processus que tu lances. Si tu fixes LANG=C avant un git clone, tout va fonctionner car git clone ne t'enverra que de l'étatsunien en ascii7 qui ne donnera pas de bouton au shell (ni à ton émulateur de terminal) et git lui-même étant configuré en C et pas en C.UTF-8 créera les fichiers en conséquences
Déjà c'est pas juste LANG, mais toute la locale que je repasse en C et ensuite même si j'en ai rien à fiche des commentaires de commit (alors que bon en vrai ca m'interresse un peu) GIT ne dispose pas de moyen de modifier le code source à l'intérieur du contenu. Donc les fichiers auront des noms propres, mais je vais devoir me rééditer tout le contenu à la mano pour reprendre les includes, les chemins, les libs etc. Et quand le dev original voudra synchroniser il va se retrouver avec une tonne de modifs complètement con et les deux lignes de correction de bugs vont passer à la trappe, noyées sous un flot de destruction de fichiers et de création de nouveau fichiers. Bref GIT ne servira à rien et sera même contre productif. Seule solution => ASCII/ANSI.
(et que ça a déjà avec ton SSH à la place de Mosh)
Si ton SSH est en pur UTF-8 oui. Mais le truc c'est que justement le pur UTF-8 en shell ca ne marche pas. Maintenant moyennant deux ou trois essai j'arriverai à caler ma locale sur celle du dev et quand je travaillerais sur ce repo je passerais dans cette locale. C'est ce que mosh ne permet pas.
(bon j’arrête là parce qu'on est légèrement off topic quand même…)
On est pas off-topic du tout. La question est "un shell pur UTF-8, bonne ou mauvaise idée". Pour moi c'est une très mauvaise idée, pour toutes les raisons exposées.
[^] # Re: Bof
Posté par Kaane . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 5.
Je ne comprends absolument pas cette obsession que tu as de vouloir mélanger dans le même filesystem des fichiers dont les noms son encodés différemment (je ne parle pas du contenu des fichiers bien sûr).
Le contenu des fichiers, on s'en fout. Si le programme qui est supposé ouvrir un fichier ne gère pas UTF-8, ben soit on ouvre avec un autre programme, soit on prend sur soi et on code un pacth. Sinon recode marche du feu de dieu dans la plupart des cas.
Par contre le shell lui c'est une autre paire de manche. Si le shell est en UTF-8, ca veut dire que tout un tas d'autres trucs doivent être en UTF-8, la locale le LANG moult parmètres pour less, perl, python, ruby etc. Sinon il va se passer de drôles de trucs à l'execution de certains scripts.
Mais bon ca c'est encore gérable.
Maintenant la bonne question est "mais pourquoi je parle tout le temps de koréen ?" et bien (un élément de réponse) est là :
http://code.google.com/p/msysgit/issues/detail?id=376
Il n'y a pas de moyen de connaitre l'encoding d'un nom de fichier - Aucun meta ne permet de le savoir, du moins pas sur les filesystems classiques. A partir de là pour pouvoir utiliser des programmes aussi courants que tar, git-clone, unzip, perl, python etc. il faut :
- soit se mettre d'accord avec le monde entier pour que tout le monde utilise exclusivement un encoding. Par exemple UTF-8, mais les asiatiques vont faire la gueule.
- Soit utiliser exclusivement les caractères ANSI dans tous les scripts/archives/backups/repo/sources etc.
Sinon tu prends le risques réel que ton programme fasse n'importe quoi. Supposons que ton make clean fasse un rm -r sur /home/toi/┌/obj et que ton parseur bute sur le ┌ qu'il interprete comme une terminaison (Je sais ca ne peux pas être le cas avec ce caractère là, c'est même pour ça que je l'ai choisi). Il va se passer quoi à ton avis ? Déjà ton make clean ne finira pas, et ensuite tu vas avoir plein de place libre sur ton ~….
Pour éviter ce genre de conneries, la seule bonne méthode pour l'instant, en attendant que UTF-8 conquiert le monde entier ou que de meta apparaissent dans les filesystems c'est
a) D'utiliser exclusivement les caractères ANSI dans le noms de fichier qui peuvent être exportés
b) De passer en locale C avant tout git-clone, unzip, ./script.sh etc. Et seulement si ca ne marche pas de repasser dans la locale présumée du truc mais en faisant très gaffe à ce qu'on fait.
Ah au fait, repasser en locale C est la bonne solution pour shooter un fichier dont le nom en UTF-16 qui contient des caractères UTF-8 invalides. Des fois que ca interresse quelqu'un…
Sauf que dans un shell UTF-8 pur, ben on peut pas repasser en locale C.
Autre problème, mosh utilise SSH pour se connecter à la machine distante. Sauf que en SSH il faut déclarer le type de terminal et également remaper un certain nombre de combinaisons de touches. A partir de là soit toute la chaine (emulateur terminal, serveur ssh, shell) est en UTF-8, soit je suis curieux de savoir ce qui va se passer quand je vais faire ctrl+H.
mais de là à t'en servir d'argument pour justifier ton point initial, à savoir qu'UTF-8 utilisé pour la communication en shell ne fonctionne pas à cause de bugs noyau (je te cite)
Ce n'est pas très grave pour la discussion en cours, mais ce n'est pas moi que tu vas citer.
parce que la led num lock ne s'allume pas dans certains cas en console,
Il ne s'agit pas de la led numlock, mais de la led capslock. Ou pour être exact à cause du local echo les caractères vont s'afficher en local comme si il s'agissait d'un caps lock mais être interpretés par mosh en bout de chaine comme si il s'agissait d'un shiftlock.
Par exemple si je tape 88 via le pavée numérique en capslock chez moi, je verais s'afficher 88 sur mon emulateur terminal, mais le shell recevra deux fois l'instruction "commande précédente". Ca peut faire des trucs très drôle. Par exemple tu penses avoir lancé un worker tomcat sur le port 8088 ? Perdu tu as réexecuté la commande 3 slots plus haut et tu es passé en mode insertion.
t'as pas l'impression de tout mélanger façon quand on veut tuer UTF-8 on dit qu'il a la rage?
Non, quand on veut tuer UTF-8 on le présente comme la solution absolue à tous les problèmes dans tous les cas et sur toutes les machines. Alors bien sur il y a des gens qui vont y croire, mais au bout du 15ème incident incompréhensible ils vont gentillement repasser leur machine en ISO/ANSI/C parceque ca marche. Et là miracle, même si ça affiche parfois n'importe quoi, ca ne casse pas tout de façon hyper chiante à debugguer.
UTF-8 est un bon format pour les documents avec des métas qui sont capables de signaler "je suis en UTF-8". mais pour les shells et les noms de fichiers, j'évite.
[^] # Re: Bof
Posté par Kaane . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 3.
Toi quand une ampoule grille chez toi, tu ne la changes pas, tu décrètes qu'il n'y a pas besoin de gérer l'obscurité…
Excellente analogie. Félicitation.
Si tu veux faire une analogie aussi terre à terre on va plutôt dire :
Quand tu as du 220v chez toi, comment tu fais pour brancher un appareil 110v ?
a) Tu branches pas
b) Tu mets un gros transfo (conversion à la volée de la tension, avec probablement une limitation en puissance), mais sous Linux il n'existe pas de modules qui permette de convertir à la volée les noms de fichiers d'un encodage à l'autre.
c) Tu branches quand même et pis tant pis si ca claque.
Maintenant avec tous les moinssages que j'ai reçu, personne n'a répondu à la question : comment faire en UTF-8 pour ouvrir un fichier dont le nom est en UTF-16 et contient un caractère interdit en UTF-8.
A noter qu'en bête ANSI, les noms de fichiers UTF-8/UTF-16 et même CP1252 ou ISO sont accessibles aussi bien programatiquement que via le shell, moyennant des échapements et ou des jokers.
Ben en ce qui me concerne tu fais ce que tu veux chez toi, mais perso je vais quand même continuer à changer les ampoules qui claquent et à utiliser UTF-8 partout.
Ce que tu utilises chez toi fonctionnera toujours, si tu décides d'utiliser exclusivement IBM-1364 ca marchera. Le problème c'est ce que tu utilises chez les autres et ce que les autres utilisent chez toi. Si je t'envoie un fichier en ISO-8859-15, vu que tu utilses UTF-8 partout j'en déduis que tu ne l'ouvriras pas. Donc tu ne changeras pas non plus l'ampoule…
# Ca s'appelle le principe de Dilbert
Posté par Kaane . En réponse au journal De l'incompétence comme moteur de l'économie…. Évalué à 9.
Il est important de laisser les gens compétents là ou ils sont et de promouvoir les incompétents à des postes décisionnels et de management pour limiter leur impact sur les gens compétents.
http://en.wikipedia.org/wiki/The_Dilbert_principle
La direction est le moyen qu'a trouvé la nature pour sortir les andouilles des flux de production.
[^] # Re: Bof
Posté par Kaane . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à -3.
et au milieu un fichier qui porte un nom en ISO-8859-15. Ha ben merde, comment je fais ?
Le symbole € ne s'affichera pas correctement. C'est tout. A la place tu verras le symbole monétaire international ¤, rien de bien méchant. Avec un clavier français, en faisant Alr Gr+e tu pourras éditer et modifier ce fichier sans même recourir aux jokers.
A exécuter dans un navigateur qui comprend le js. Et hop, je viens d'écrire de l'unicode en ISO-8859-1. Alors, il est où le problème finalement ?
Essaye de faire ca dans un shell, comme Mosh par exemple. Et regarde la gueule que fait ton interpreteur. Surtout que afficher des caractères c'est une chose, mais les interpreter s'en est une autre. De mémoire c'est quoi le code unicode de 국 par exemple ? Tu vas en avoir besoin pour accéder au fichier…
[^] # Re: Bof
Posté par Kaane . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 1.
Ton problème de rennomage c'est la même chose entre ISO-8859-1 et CP-1252 par exemple.
Non, les caractères posant problème en CP-1252 (i.e les caractères de 128 à 159) qui ne transcrivent pas en ISO-8859 peuvent être échappés facilement avec des antislash en code ou avec des caractères joker (? et * principalement) en shell. Le problème est nettement plus simple à traiter.
Ha oui, et comment tu gères le € sur un ISO-8859-1 ?
Tu ne le gères pas. Si tu as besoin du symbole € tu prends un autre charmap.
Et comment, dans ton approche traditionnelle, tu gères un fichier coréen ?
Le nom du fichier va être explosé en une suite de caractères (imprimables ou non) que je peux récupérer de la même façon que je récupères les noms de fichiers incorrects. En échappant ou en utilisant des jokers. C'est moche, mais ça marche.
[^] # Re: Bof
Posté par Kaane . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à -7.
UTF-8 c'est bien pour l'affichage d'un texte non corrompu. Mais bon sur un texte avec des erreurs qui ont générées des caractères interdits ou pour une saisie interactive, c'est déjà nettement plus discutable. Ne serait-ce que d'avoir un système qui tolère les noms de fichiers en UTF-X c'est un bordel sans nom. Tiens question : sous un système comme mosh, qui est pur UTF-8 comment on fait pour effacer un fichier dont le nom est codé en UTF-16 (par exemple un fichier nommé en Coréen) ? Point bonus si tu sais dire comment éditer un fichier dont le nom en UTF-16 contient un caractère interdit en UTF-8.
Unicode c'est comme IPv6, sur le papier c'est génial, dans la pratique on s'en sort souvent mieux avec une approche plus traditionnelle.
[^] # Re: Pas de problèmes avec Gnome Shell | La situation sur le Desktop est meilleur que par le passé
Posté par Kaane . En réponse au journal Pourquoi le monde libre me gave de plus en plus.. Évalué à -1.
Qu'est-ce que tu leur avais choisi comme distribution inadaptée, qui ne dure même pas un an et demi sans mise à jour majeure ?
Qui te dis qu'il n'y a pas eu de mises à jour majeures. C'est juste que les mises à jour (majeures ou non) cassent les installs, les réglages persos, la compatibilité hardware etc.
Comme indiqué j'ai fait Fedora (ca a pas marché - mais je me suis dit que c'était à cause du modèle assez expérimental de la distrib) puis je suis passé sous Suse d'un coté et Ubuntu de l'autre. Ca n'a pas marché non plus.
[^] # Re: Pas de problèmes avec Gnome Shell | La situation sur le Desktop est meilleur que par le passé
Posté par Kaane . En réponse au journal Pourquoi le monde libre me gave de plus en plus.. Évalué à 6.
Et sera vendu pendant combien de temps ? Si les gens ne peuvent plus acheter 7, il seront obligé de passer à 8 au changement de matériel
Alors c'est typiquement l'argument qui ne tient plus.
D'une part l'équipement qui n'est plus fonctionnel sous Windows Vista et consort (à savoir une poignée de scanners, d'imprimantes multifonctions, de cartes réseaux wifi ou non et de cartes d'aquisitions video) n'est plus fonctionnel sous Linux non plus. V4L a giclé, une bonne partie des pilotes madwifi anciens (notamment au niveau des variantes atheros 5k) se sont barrés en fumée etc.
Alors certes il existe des pilotes qui fonctionnent encore sous Linux et qui ne marchent plus sous windows 7, mais la réciproque est vraie.
D'autre part sur une machine portable vieille de trois ou quatre ans il y a plus de chance qu'elle soit compatible complètement avec windows 7 qu'avec Linux. Même si elle au moment de l'achat elle était complètement compatible Linux. Les hacks ACPI s'en vont gentillement du kernel après un ou deux ans, la prise en charge de certaines touches (notamment les touches d'activation/désactivation du wifi) part en vrille et j'en passe.
En plus Linux devient furieusement gourmand, les nouvelles versions de tout un tas de logiciels phares de l'eccosystème Linux font de plus en plus appel à des dépendances à la con. Et vas-y que je remonte tout le projet Gnome en bleeding edge tout ça parceque je veux pouvoir écrire des formules mathématiques dans Abiword, et vas-y que j'installe la moité de tous les packages connus de freedesktop pour pouvoir faire un copier/coller. Et on ne va pas parler du son sous Linux parceque sinon je vais encore m'ennerver.
Bref début 2009 j'ai acheté des portables ASUS full compatible Linux (fonctionnement impécable sous Suse, Fedora et Ubuntu) pour mes deux grand mères et ma mère, et mi 2010 je passais tout le monde sous Vista parceque j'en avais marre de maintenir un repo complet de patchs à la con pour que le wifi et les touches spéciales fonctionnent, pour que la luminosité de l'écran soit un temps soit peu cohérente, pour que verrou numérique reste dans la position voulue même en cas de changement d'appli, pour que le volume de lecture de CD audio soit enregistré proprement, pour que le montage de clefs USB se fassent là ou les utilisateurs s'atendent à la voir et avec un nom qu'ils connaissent, pour que network manager ne casse pas mon paramétrage WPA-Supplicant etc. Et là on parle d'utilisateurs très très basiques qui ne font ni 3D ni audio poussé et qui lisent leurs mails sur des webmails la plupart du temps (dieu merci parceque l'option de recherche indexée sous thunderbird j'en ai soupé sur mes machines persos).
Donc l'argument "Ah ben oui mais sous Windows tu n'es pas sur que tu pourras mettre à jour ton système dans 5 ans" il me fait doucement rigoler. Sous Linux tu n'es pas sur que tu pourras mettre à jour dans 8 mois, en tout cas pas sans un admin sys qui t'assiste pas à pas.
[^] # Re: Libc
Posté par Kaane . En réponse au journal Chaine(s) de compilation ARM. Évalué à 0.
En fait, il faudrait une toolchain avec une libc, libm et libgcc compilée avec toutes les cibles ARM pour que ce soit efficace
Oui en plus il faut rajouter toutes les variations d'ARM et le fait que les différents bus varient d'une plateforme à l'autre.
En fait sous ARM c'est plutôt une plateforme = un toolchain. Dejà tu as de la chance si la même toolchain fonctionne entre la v1 et la v2 d'un même device.
[^] # Re: Peut mieux faire !
Posté par Kaane . En réponse au sondage Quel est le meilleur indicateur pour mesurer la taille de sa geekitude ?. Évalué à 0.
J'espère être battu , écrasé et ridiculisé par nombre de lecteurs de Linuxfr ;-)
Tu synchronises tes CVS dans le home ? Drôle d'idée…
En plus il manque un -type f pour être propre.
Mais bon je ne pense pas que la geekitude se résume à un concours de bits…
Perso je suis assez content de mon
$ netstat -r | wc -l
117
Mais bon avec les machines virtuelles, les jail et autres alias ca va vite, et puis un vlan par poste ca pique aussi.
Machine de la maison je précise.
Sinon ifconfig|grep -C ether qui renvoit 14 aussi. (Il vaut mieux greper ether que UP en ces temps d'IPv6 fou)
[^] # Re: Pas sûr...
Posté par Kaane . En réponse au journal [HS] Hacker le problème du logement. Évalué à 5.
- Ils "oublient" que 1800 en loyer c'est charges comprises, en emprunt c'est sans les charges. Ca rajoute…
Pour la majeure partie, le prix de la location dans un marché saturé (comprendre à peu près toutes les grandes villes un peu dynamique : Paris, Lyon, Lille, Toulouse etc.) le prix du loyer est sensiblement égal à la mensualité d'achat sur un prêt de durée conventionnel avec un apport de 15%. En 1996 la durée conventionnelle était de 12 ans, avec des prêts pouavnt aller jusqu'à 17 ans. Aujourd'hui la durée conventionelle est de 20 ans avec des prêts pouvant aller jusqu'à 25 ans (qui deviennent la norme à Paris…).
8
En fait le propriétaire "perd" les 15% d'apport mais derrière il les récupère aux alentours de la 7ème/8ème année (avant aux alentours de la 5ème/6ème année).
Par contre ce qu'il faut bien voir c'est que dès la troisième année les mensualités de remboursement seront sensiblement égales au loyer pour un bien donné (toujours dans une région dense avec un marché saturé). Sauf accident de parcours (licenciement, faillite, chommage) le propriétaire d'un bien a tout intéret à garder celui-ci et à le louer plutôt qu'à le revendre. Sa dette et ses revenus s'annuleront sur ce point. Maintenant il y a effectivement prise de risque, mais il n'y a pas 30% de différence entre le proprio et le locataire, 10 ou 12% maximum et en début de prêt.
[^] # Re: Pas sûr...
Posté par Kaane . En réponse au journal [HS] Hacker le problème du logement. Évalué à 2.
Ouais OK on le dira à tous les petits propriétaires
Merci de lire l'ensemble du texte avant de régair, il s'agit ici du propriétaire du bien qu'il habite par opposition au locataire d'un même bien. Mon texte contient en plus de nombreux exemples qui ne laissent aucun doute sur ce que j'ai voulu dire.
[^] # Re: Pas sûr...
Posté par Kaane . En réponse au journal [HS] Hacker le problème du logement. Évalué à 3.
Ah… L'Achat vs la location… C'est très latin comme idée de vouloir à tous prix être proprio.
Le problème est que l'achat fournit une grosse sécurité par rapport à la location. Bien sur il n'est pas forcément intelligent d'acheter coute que coute, et la technique qui ocnsiste à acheter de petites surfaces et de les mettre en location tout en louant soi-même sa résidence principale est assez interressante dans bon nombre de cas.
Seulement malgré les nombreuses protections dont dispose le locataire, le propriétaire est systèmatiquement très avantagé en terme d'assurance.
Quelques exemples :
Assurance decès : si je meurs sans avoir finit de payer mon crédit, le bien peut revenir de plein droit à ma famille - libéré de tout emprunt. Mieux, si je suis marié avec des enfants, ma femme possède l'usufruit du bien jusqu'à sa mort. Vous connaissez une assurance qui va payer le loyer d'un appart jusqu'à la mort de ma femme en cas de décès ? Moi pas.
Assurance chomage/faillite financière : si je suis dans l'incapacité financière de finir de payer mon crédit, l'assurance prend en charge les paiements sur une durée variable, ou au moins reporte les échéances. Bonus : je peux prendre en plus une hypothèque sur le captial déjà remboursé pour rebondir. Rien de tout celà en locatif.
Divorce : En supposant que madame ait la garde des enfants, elle n'a pas à se casser la tête pour trouver un logement, elle n'a pas à notifier qui que ce soit d'un changement de statuts. De pus les versements pour rembourser le crédit et l'usage de l'appartement sont déduits de la pension alimentaire. Et en cas de nouveau changement de statut, l'appart est toujours disponible.
Eviction forcée : Même quand on paye régulièrement son loyer, on peut se faire jeter facilement. Soit pour cause de vente du bien, soit pour mise à disposition gratuite du bien à des membres de la famille du propriétaire. Quand on est dans une situation nécessitant une forte mobilité, se retrouver à devoir changer d'appart alors qu'il y a possibilité de déménagement dans les 6 mois, c'est complexe. Avec un bien à l'achat, la location du bien ou même le crédit relais sont des options qui permettent de respirer.
Et il y a des dizaines de cas ou la location, bien qu'economiquement avantageuse sur le papier, devient un problème très complexe à gérer.
[^] # Re: Pour la science
Posté par Kaane . En réponse au journal Voter autrement. Évalué à 9.
intérêt du scrutin majoritaire à 2 tours est que tout le monde le comprend
Pour être exact croit le comprendre. Et puis ca fait des surprises des fois, comme d'avoir une gauche majoritaire et un second tour droite vs extreme droite. Et donc un candidat de droite élu avec plus de 70% des voix dans un pays ou 52% des votants sont à gauche.
Comprendre un système de vote veut principalement dire comprendre ce que le résultat donné par ce système veut dire. Et il y a très peu de gens qui savent ce que veut dire "M. X a été élu au second tour avec 54% des suffrages".
La mécanique est simple certes, mais tout un tas d'arnaques et d'escroqueries ont elle aussi des mécaniques simples (montages pyramidaux par exemple). Que le fonctionnement soit simple est une chose, que le résultat soit compréhensible en est une autre.