Hello, ça serait cool pour les gens qui ne sont pas sur Debian d'avoir un moyen pas trop dur de l'installer au moins pour tester.
Perso je suis sur Fedora, et en plus j'arrive pas à compiler à partir du dépôt git.
[freelan-all]$ cd libfreelan/
[libfreelan]$ scons
scons: Reading SConscript files …
ImportError: No module named freelan.build_tools:
File "/…/freelan-all/libfreelan/SConstruct", line 12:
from freelan.build_tools import LibraryProject, Environment
[libfreelan]$ cd ../freelan
[freelan]$ scons
scons: Reading SConscript files …
ImportError: No module named freelan.build_tools:
File "/…/freelan-all/freelan/SConstruct", line 13:
from freelan.build_tools import ProgramProject, Environment
Sinon ton soft fait très envie, je suis utilisateur d'OpenVPN en niveau 2 donc forcément FreeLAN m'intéresse aussi…
Merci.
J'aime beaucoup ton plaidoyer pour UCS-2 et contre UTF-16, sachant que ça fait bien 4 ou 5 commentaires que tu fais en demandant UTF-16 au lieu d'UTF-8 pour le salut de l'Asie et que l'un de tes arguments contre UTF-8 en Asie était la longueur d'encodage des idéogrammes rares, lesquels sont simplement absents d'UCS-2.
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.
Ben si j'ai réussi ça, j'ai pas complètement perdu mon temps alors.
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.
Parce que j'ai rien à dire dessus.
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.
T'es contre l'utilisation d'UTF-8 partout et pour tout, donc t'es contre UTF-8. ;-)
UTF-8 c'est bon mangez-en.
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 ?
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)
Et il y a des caractères interdits en UCS-2 (enfin des caractères réservés, qui justement rendent UTF-16 possible).
Sinon le fait de considérer que le Tibet et Taïwan ne font pas partie de la Chine n'est pas neutre politiquement, je suis sûr qu'à Pékin ce n'est pas ce qui se dit… ;-) Et c'est à Pékin qu'on écrit les normes. ;-)
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.
C'est faux car tous les caractères qui prennent 4 octets en UTF-8 en prennent aussi 4 en UTF-16 (je détaille plus bas).
Mais ton paragraphe devient diablement drôle quand on le rapproche du suivant:
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. (…) mais il est peut rentable pour les caractères japonais ou corééns qui vont systématiquement se retrouver sur 4 octets.
Ah oui, c'est une vraie différence. Au lieu d'avoir des caractères sur 4 octets on a… des caractères sur 4 octets.
Pour le comprendre il faut avoir à l'esprit que les langues asiatiques hors idéogrammes rares (rares = CJK extensions B et suivantes) sont toutes dans le BMP (
Il faut aussi noter une petite approximation, ce n'est pas "most Chinese characters" qui tient sur 2 octets mais bien sûr "most usual Chinese characters" (hors idéogrammes CJK extensions B et suivantes, qui sont rares mais très nombreux).
Pour te donner une idée du surcoût indu que représente +50% sur le texte non compressé, dis-toi que Microsoft a décidé avec Windows 2000 de passer tout stockage de chaîne caractères en UTF-16 (enfin historiquement en UCS-2 sous le nom pompeux d'Unicode) infligeant donc il y a plus de 10 ans un +100% à tout le monde occidental dès que tu passes par leurs bibliothèques (et comment te dire que c'est une pratique courante voire prudente sous Windows…).
Et j'ai un scoop: on n'est pas morts d'un +100%.
Les asiatiques survivrons à +50% (et j'ose la plaisanterie: en plus c'est eux qui fabriquent les disques durs et la RAM!).
Tu n'aimes pas Microsoft, tu n'utilises pas leurs bibliothèques? Et bien je ne connais pas les choix techniques internes de tous les autres environnements de programmation mais devine ce qu'utilisent une String Java et une QString Qt comme format interne depuis des années ? Et oui là aussi on a pris +100% sans broncher.
Te fatigues pas trop, si le port TCP 22 est filtré, il y a peu de chance que l'UDP passe, ou alors le type qui administre le firewall est vraiment trop lol.
Posté par DerekSagan .
En réponse à la dépêche Mosh, the Mobile Shell.
Évalué à 6.
Dernière modification le 18 avril 2012 à 09:22.
Il n'y a pas de moyen de connaitre l'encoding d'un nom de fichier
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.
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.
Cela dit si ce n'était pas une image et que tu écrivais vraiment coréen, tu ne serais pas en train de mener un combat d'arrière garde pro ISO-8859, justement.
tout le monde utilise exclusivement un encoding. Par exemple UTF-8, mais les asiatiques vont faire la gueule.
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) ?
Il y a sûrement quand même quelques asiatiques qui comme toi sont attachés à leurs anciens encodages qui leur font gagner quelques % d'espace disque sur le texte non compressé ou à pester (à juste titre) contre le fait que tous les logiciels qu'ils utilisent n'en sont pas au même stade de support d'UTF-8… mais globalement, UTF-8 c'est un progrès pour l'Asie…
Je reconnais qu'on pourrait utiliser GB18030 au lieu d'UTF-8, avec le même intérêt et les mêmes bonnes propriétés. Mais comme 80% des logiciels sont faits en Amérique du nord ou en Europe, ça n'a pas beaucoup de chance de se produire. Et comme seule la Chine utilise GB18030, on ne peut même pas parler de norme asiatique… (va faire du GB18030 au Japon…)
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
Tu veux dire utiliser exclusivement les caractères ASCII-7 ? Parce que c'est plus sûr si tu ne veux pas foute le bordel chez les gens qui utilisent UTF-8 avec des séquences interdites (ah oui… mais eux on s'en fiche c'est leur faute ils n'ont qu'à pas utiliser UTF-8).
En fait ce n'est même pas ASCII-7 mais ASCII-7 sans certains caractères parce que sinon ça créera d'autres problèmes sur certains OS (genre / sous Unix, \ : * ? sous Windows, : sous MacOS9, ; sous VMS, et j'en oublie). Voire sans espaces aussi. Bref t'as droit à une soixantaine de caractères si tu veux pas être emmerdé, ça passerait dans de l'ASCII-6 en fait ;-)
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.
Mais le problème existait avant UTF-8.
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.
Mais fais attention, installer convmv pourrait être la première étape à convertir tout ton filesystem en noms en UTF-8, le Mal pourrait t'atteindre…
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.
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. Avec toutes les limites que ça a (et que ça a déjà avec ton SSH à la place de Mosh), en particulier les commentaires de commit qui sont conventionnellement écris en UTF-8, mais tu t'en fous c'est pas le nom du fichier c'est son contenu.
Dit autrement ça marche indépendamment du shell.
Même raisonnement avec unzip (encore que de toute façon le format zip gère vraiment très mal l'encodage des noms de fichiers).
(bon j’arrête là parce qu'on est légèrement off topic quand même…)
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). Après tout, pourquoi pas, tu as peut-être tes raisons…
…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) parce que la led num lock ne s'allume pas dans certains cas en console, t'as pas l'impression de tout mélanger façon quand on veut tuer UTF-8 on dit qu'il a la rage?
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.
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é…
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.
J'ai pas dis que c'était nul, je relève juste une limite d'utilisation. Perso j'adore UDP, je déteste le tout-TCP voire le tout TCP:80,443 mais je constate que dans beaucoup de cas je ne pourrais pas me servir de mosh.
Posté par DerekSagan .
En réponse à la dépêche Mosh, the Mobile Shell.
Évalué à 6.
Dernière modification le 17 avril 2012 à 08:54.
J'aime beaucoup UDP, mais partout (entreprises, etc.) où on ne peut établir une connexion SSH que sur le port 443 à travers un proxy HTTP, Mosh ne fonctionnera pas…
Tu peux mettre n'importe quel caractère après un s, même si la convention est d'utiliser / quand il n'y a pas de bonne raison d'utiliser un autre caractère.
Par exemple s#/#z# remplacera tous les / par des z.
J'aime beaucoup. C'est la première fois qu'on fait une journée IPv6 ou un lancement d'IPv6 dans les 10 dernières années, c'est clair. Mais bon si l'ISOC dit que celui-ci est définitif, c'est sûrement vrai. ;-)
Aller, va, on finira bien par s'en servir quand même d'IPv6 (je veux dire à grande échelle).
Il pique les yeux ton graphique par pays effectivement.
Je ne sais par quel bout commencer: IPv6 l'exception française? La France championne du monde de l'IPv6 ? Le champion du monde a moins de 5% d'IPv6 14 ans après la validation de la norme ? Bref je ne sais pas s'il faut rire ou pleurer.
(14 ans c'est 9 périodes de Moore, des machines 512 fois plus puissantes pour le même prix)
Cela dit les chiffres concernent les recherche google si je comprends bien donc il y a un sérieux biais (genre la Chine doit pas trop s'en servir). Et on ne parle pas des serveurs, sur lesquels les hosteurs français ne doivent pas être trop mauvais non plus (OVH, Online et Gandi proposant tous de l'IPv6 natif sauf erreur de ma part).
Posté par DerekSagan .
En réponse à la dépêche mcercle - version 1.0.
Évalué à 0.
Dernière modification le 05 avril 2012 à 14:18.
Je crois que c'était une allusion à une phrase fort malheureuse d'un patron de pub célèbre (google s'en souvient) probablement destinée à créer une sorte d'analogie fondée sur: acheter un mac pour compiler = être un con de bourge de droite. Je n'ajoute pas sarkozyste parce qu'on approche le point Godwin.
À noter que je n'apprécie pas d'être obligé d'acheter un mac pour compiler sur mac (pas plus que d'être obligé d'acheter un windows pour compiler sur windows), je faisait juste part de la méthode la plus efficace que j'ai trouvée et jugeait juste que le prix n'était pas rédhibitoire face au marché que représente les utilisateurs de mac incapables de compiler à partir des sources.
Sous Windows (Seven, Pro, 64 bits, SP1, patches à jour).
Quand je fais un copier/coller de la boîte détail pour l'erreur, le coller donne ça (alors que je sélectionne les détails avant de faire le Ctrl C !)
---------------------------
Erreur
---------------------------
<b>La connexion avec la base de données n’a pas pu être établie!> </b>
---------------------------
OK Hide Details...
---------------------------
Les détails sont trop long à recopier à la main, et la capture d'écran serait d'une part honteuse d'autre part partielle à cause de l’ascenseur et de la boîte de dialogue non redimensionnable..
Je n'ai pas l'impression que l'installeur a installé Firebird, mais je n'en sais rien, et aucun message ne me dit quoi faire.
Pour toutes ces raisons, puisque c'est une version 1.0, je vais attendre la 2.1 pour tester. Désolé.
Posté par DerekSagan .
En réponse à la dépêche mcercle - version 1.0.
Évalué à -2.
Dernière modification le 03 avril 2012 à 18:01.
Quand on l'installe et le lance il commence par gueuler qu'il n'arrive pas à se connecter à la base et aucune explication de comment on créée/installe la base n'est fournie.
J'attends la 2.1 pour tester du coup
Mais c'est bien d'avoir choisi Qt et d'être cross-plateform :-)
Perso la méthode la plus simple que j'ai trouvé pour fournir une appli Qt aussi sur Mac a consisté à acheter un Mac Mini à 600 euros sans écran souris ni clavier, c'est simple et pas si cher que ça.
certaines images disques sont organisées de manière à indiquer ce qu'il faut faire
Oui et d'autres (VLC par exemple si ma mémoire est bonne) contiennent un README qui le dit avec des mots (c'est moins cool mais ça aide les mac-users qui n'ont pas "l'habitude" comme tu dis).
# paquet Fedora (ou tar.gz agnostique)
Posté par DerekSagan . En réponse à la dépêche Freelan : un nouveau venu dans le monde des VPN peer-to-peer. Évalué à 3.
Hello, ça serait cool pour les gens qui ne sont pas sur Debian d'avoir un moyen pas trop dur de l'installer au moins pour tester.
Perso je suis sur Fedora, et en plus j'arrive pas à compiler à partir du dépôt git.
Sinon ton soft fait très envie, je suis utilisateur d'OpenVPN en niveau 2 donc forcément FreeLAN m'intéresse aussi…
Merci.
[^] # Re: Bof
Posté par DerekSagan . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 1.
J'aime beaucoup ton plaidoyer pour UCS-2 et contre UTF-16, sachant que ça fait bien 4 ou 5 commentaires que tu fais en demandant UTF-16 au lieu d'UTF-8 pour le salut de l'Asie et que l'un de tes arguments contre UTF-8 en Asie était la longueur d'encodage des idéogrammes rares, lesquels sont simplement absents d'UCS-2.
Mélol!
[^] # Re: Bof
Posté par DerekSagan . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 1.
Ben si j'ai réussi ça, j'ai pas complètement perdu mon temps alors.
Parce que j'ai rien à dire dessus.
T'es contre l'utilisation d'UTF-8 partout et pour tout, donc t'es contre UTF-8. ;-)
UTF-8 c'est bon mangez-en.
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)
Et il y a des caractères interdits en UCS-2 (enfin des caractères réservés, qui justement rendent UTF-16 possible).
Sinon le fait de considérer que le Tibet et Taïwan ne font pas partie de la Chine n'est pas neutre politiquement, je suis sûr qu'à Pékin ce n'est pas ce qui se dit… ;-) Et c'est à Pékin qu'on écrit les normes. ;-)
[^] # Re: Bof
Posté par DerekSagan . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 3.
C'est faux car tous les caractères qui prennent 4 octets en UTF-8 en prennent aussi 4 en UTF-16 (je détaille plus bas).
Mais ton paragraphe devient diablement drôle quand on le rapproche du suivant:
Ah oui, c'est une vraie différence. Au lieu d'avoir des caractères sur 4 octets on a… des caractères sur 4 octets.
Bon soyons constructif:
Il y a un tableau bien fait pour combattre tes préjugés ici (si ça t'intéresse vraiment):
http://en.wikipedia.org/wiki/Comparison_of_Unicode_encodings
Pour le comprendre il faut avoir à l'esprit que les langues asiatiques hors idéogrammes rares (rares = CJK extensions B et suivantes) sont toutes dans le BMP ( Il faut aussi noter une petite approximation, ce n'est pas "most Chinese characters" qui tient sur 2 octets mais bien sûr "most usual Chinese characters" (hors idéogrammes CJK extensions B et suivantes, qui sont rares mais très nombreux).
L'affectation des plans est ici:
http://en.wikipedia.org/wiki/Unicode_plane
http://en.wikipedia.org/wiki/CJK_Unified_Ideographs
Pour te donner une idée du surcoût indu que représente +50% sur le texte non compressé, dis-toi que Microsoft a décidé avec Windows 2000 de passer tout stockage de chaîne caractères en UTF-16 (enfin historiquement en UCS-2 sous le nom pompeux d'Unicode) infligeant donc il y a plus de 10 ans un +100% à tout le monde occidental dès que tu passes par leurs bibliothèques (et comment te dire que c'est une pratique courante voire prudente sous Windows…).
Et j'ai un scoop: on n'est pas morts d'un +100%.
Les asiatiques survivrons à +50% (et j'ose la plaisanterie: en plus c'est eux qui fabriquent les disques durs et la RAM!).
Tu n'aimes pas Microsoft, tu n'utilises pas leurs bibliothèques? Et bien je ne connais pas les choix techniques internes de tous les autres environnements de programmation mais devine ce qu'utilisent une String Java et une QString Qt comme format interne depuis des années ? Et oui là aussi on a pris +100% sans broncher.
[^] # Re: incompatible avec un proxy http
Posté par DerekSagan . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 2.
Te fatigues pas trop, si le port TCP 22 est filtré, il y a peu de chance que l'UDP passe, ou alors le type qui administre le firewall est vraiment trop lol.
[^] # Re: Bof
Posté par DerekSagan . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 6. Dernière modification le 18 avril 2012 à 09:22.
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.
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.
Cela dit si ce n'était pas une image et que tu écrivais vraiment coréen, tu ne serais pas en train de mener un combat d'arrière garde pro ISO-8859, justement.
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) ?
Il y a sûrement quand même quelques asiatiques qui comme toi sont attachés à leurs anciens encodages qui leur font gagner quelques % d'espace disque sur le texte non compressé ou à pester (à juste titre) contre le fait que tous les logiciels qu'ils utilisent n'en sont pas au même stade de support d'UTF-8… mais globalement, UTF-8 c'est un progrès pour l'Asie…
Je reconnais qu'on pourrait utiliser GB18030 au lieu d'UTF-8, avec le même intérêt et les mêmes bonnes propriétés. Mais comme 80% des logiciels sont faits en Amérique du nord ou en Europe, ça n'a pas beaucoup de chance de se produire. Et comme seule la Chine utilise GB18030, on ne peut même pas parler de norme asiatique… (va faire du GB18030 au Japon…)
Tu veux dire utiliser exclusivement les caractères ASCII-7 ? Parce que c'est plus sûr si tu ne veux pas foute le bordel chez les gens qui utilisent UTF-8 avec des séquences interdites (ah oui… mais eux on s'en fiche c'est leur faute ils n'ont qu'à pas utiliser UTF-8).
En fait ce n'est même pas ASCII-7 mais ASCII-7 sans certains caractères parce que sinon ça créera d'autres problèmes sur certains OS (genre / sous Unix, \ : * ? sous Windows, : sous MacOS9, ; sous VMS, et j'en oublie). Voire sans espaces aussi. Bref t'as droit à une soixantaine de caractères si tu veux pas être emmerdé, ça passerait dans de l'ASCII-6 en fait ;-)
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.
Mais le problème existait avant UTF-8.
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.
Mais fais attention, installer convmv pourrait être la première étape à convertir tout ton filesystem en noms en UTF-8, le Mal pourrait t'atteindre…
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. Avec toutes les limites que ça a (et que ça a déjà avec ton SSH à la place de Mosh), en particulier les commentaires de commit qui sont conventionnellement écris en UTF-8, mais tu t'en fous c'est pas le nom du fichier c'est son contenu.
Dit autrement ça marche indépendamment du shell.
Même raisonnement avec unzip (encore que de toute façon le format zip gère vraiment très mal l'encodage des noms de fichiers).
(bon j’arrête là parce qu'on est légèrement off topic quand même…)
[^] # Re: Pas trop convaincu...
Posté par DerekSagan . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 2.
Un firewall peut-être…
# Je ne dis pas merci à Gabin ;-)
Posté par DerekSagan . En réponse au sondage Possédez-vous une tablette ?. Évalué à 2.
Cette phrase vient de me faire perdre 5h, à voir Matrix 2 et 3, je m'étais toujours arrêté au 1.
[^] # Re: Bof
Posté par DerekSagan . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 3.
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). Après tout, pourquoi pas, tu as peut-être tes raisons…
…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) parce que la led num lock ne s'allume pas dans certains cas en console, t'as pas l'impression de tout mélanger façon quand on veut tuer UTF-8 on dit qu'il a la rage?
[^] # Re: Trop bien !
Posté par DerekSagan . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 1.
Tu changes d'adresse IP quand tu passes en veille ?
[^] # Re: Bof
Posté par DerekSagan . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 1.
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é…
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.
[^] # Re: incompatible avec un proxy http
Posté par DerekSagan . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 5.
J'ai pas dis que c'était nul, je relève juste une limite d'utilisation. Perso j'adore UDP, je déteste le tout-TCP voire le tout TCP:80,443 mais je constate que dans beaucoup de cas je ne pourrais pas me servir de mosh.
# incompatible avec un proxy http
Posté par DerekSagan . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 6. Dernière modification le 17 avril 2012 à 08:54.
J'aime beaucoup UDP, mais partout (entreprises, etc.) où on ne peut établir une connexion SSH que sur le port 443 à travers un proxy HTTP, Mosh ne fonctionnera pas…
[^] # Re: Useless Use of wc -l
Posté par DerekSagan . En réponse au sondage Quel est le meilleur indicateur pour mesurer la taille de sa geekitude ?. Évalué à 1.
Tu peux mettre n'importe quel caractère après un s, même si la convention est d'utiliser / quand il n'y a pas de bonne raison d'utiliser un autre caractère.
Par exemple s#/#z# remplacera tous les / par des z.
# 114ème lancement officiel d'IPv6
Posté par DerekSagan . En réponse à la dépêche Événement G6 - IPv6 - 11 avril 2012 - Paris. Évalué à 3.
J'aime beaucoup. C'est la première fois qu'on fait une journée IPv6 ou un lancement d'IPv6 dans les 10 dernières années, c'est clair. Mais bon si l'ISOC dit que celui-ci est définitif, c'est sûrement vrai. ;-)
Aller, va, on finira bien par s'en servir quand même d'IPv6 (je veux dire à grande échelle).
[^] # Re: Free as a bird
Posté par DerekSagan . En réponse à la dépêche Événement G6 - IPv6 - 11 avril 2012 - Paris. Évalué à 1.
Il pique les yeux ton graphique par pays effectivement.
Je ne sais par quel bout commencer: IPv6 l'exception française? La France championne du monde de l'IPv6 ? Le champion du monde a moins de 5% d'IPv6 14 ans après la validation de la norme ? Bref je ne sais pas s'il faut rire ou pleurer.
(14 ans c'est 9 périodes de Moore, des machines 512 fois plus puissantes pour le même prix)
Cela dit les chiffres concernent les recherche google si je comprends bien donc il y a un sérieux biais (genre la Chine doit pas trop s'en servir). Et on ne parle pas des serveurs, sur lesquels les hosteurs français ne doivent pas être trop mauvais non plus (OVH, Online et Gandi proposant tous de l'IPv6 natif sauf erreur de ma part).
[^] # Re: Multi-vote
Posté par DerekSagan . En réponse au sondage Sur votre ordinateur personnel, quel(s) est/sont votre/vos système(s) d'exploitation ?. Évalué à 1.
Non c'est pas normal, c'est techniquement possible mais c'est pas éthique, donc je me demande pourquoi tu t'es permis de le faire. ;-)
[^] # Re: ça marche pas out of the box
Posté par DerekSagan . En réponse à la dépêche mcercle - version 1.0. Évalué à 0. Dernière modification le 05 avril 2012 à 14:18.
Je crois que c'était une allusion à une phrase fort malheureuse d'un patron de pub célèbre (google s'en souvient) probablement destinée à créer une sorte d'analogie fondée sur: acheter un mac pour compiler = être un con de bourge de droite. Je n'ajoute pas sarkozyste parce qu'on approche le point Godwin.
À noter que je n'apprécie pas d'être obligé d'acheter un mac pour compiler sur mac (pas plus que d'être obligé d'acheter un windows pour compiler sur windows), je faisait juste part de la méthode la plus efficace que j'ai trouvée et jugeait juste que le prix n'était pas rédhibitoire face au marché que représente les utilisateurs de mac incapables de compiler à partir des sources.
[^] # Re: ça marche pas out of the box
Posté par DerekSagan . En réponse à la dépêche mcercle - version 1.0. Évalué à 4.
Si je fais du développement sur Rolex, oui.
[^] # Re: ça marche pas out of the box
Posté par DerekSagan . En réponse à la dépêche mcercle - version 1.0. Évalué à 1.
C'est facile, mais il faut un Mac quand même. Et installer un Mac OS X plus ou moins pirate dans une VM c'est juste pénible.
[^] # Re: ça marche pas out of the box
Posté par DerekSagan . En réponse à la dépêche mcercle - version 1.0. Évalué à 2.
Alors:
Sous Windows (Seven, Pro, 64 bits, SP1, patches à jour).
Quand je fais un copier/coller de la boîte détail pour l'erreur, le coller donne ça (alors que je sélectionne les détails avant de faire le Ctrl C !)
Les détails sont trop long à recopier à la main, et la capture d'écran serait d'une part honteuse d'autre part partielle à cause de l’ascenseur et de la boîte de dialogue non redimensionnable..
Je n'ai pas l'impression que l'installeur a installé Firebird, mais je n'en sais rien, et aucun message ne me dit quoi faire.
Pour toutes ces raisons, puisque c'est une version 1.0, je vais attendre la 2.1 pour tester. Désolé.
[^] # dd_rescue
Posté par DerekSagan . En réponse au message Logiciel pour créer et récupérer des images disque. Évalué à 1.
EDIT: enfin surtout dd_rescue en fait
# ça marche pas out of the box
Posté par DerekSagan . En réponse à la dépêche mcercle - version 1.0. Évalué à -2. Dernière modification le 03 avril 2012 à 18:01.
Quand on l'installe et le lance il commence par gueuler qu'il n'arrive pas à se connecter à la base et aucune explication de comment on créée/installe la base n'est fournie.
J'attends la 2.1 pour tester du coup
Mais c'est bien d'avoir choisi Qt et d'être cross-plateform :-)
Perso la méthode la plus simple que j'ai trouvé pour fournir une appli Qt aussi sur Mac a consisté à acheter un Mac Mini à 600 euros sans écran souris ni clavier, c'est simple et pas si cher que ça.
# dd
Posté par DerekSagan . En réponse au message Logiciel pour créer et récupérer des images disque. Évalué à 1.
Ben moi j'utilise dd pour faire des images de disque (ce que je ne fais d'ailleurs qu'avec mon portable) et je suis très content.
[^] # Re: [X] MacOs
Posté par DerekSagan . En réponse au sondage Sur votre ordinateur personnel, quel(s) est/sont votre/vos système(s) d'exploitation ?. Évalué à 5.
Oui c'est ce que je dis: c'est pas intuitif.
Oui et d'autres (VLC par exemple si ma mémoire est bonne) contiennent un README qui le dit avec des mots (c'est moins cool mais ça aide les mac-users qui n'ont pas "l'habitude" comme tu dis).