Batchyx a écrit 1261 commentaires

Sachant que pour 80% des softs y a un système d'include/whatever qui permet d'avoir les paramètres spécifiques dans un fichier dédié qui n'est pas écrasé par l'update…

Seulement pour les projets upstream pas chiants.

C'est pour ça que je supporte de moins en moins les distrib comme gentoo et arch: On se prend toutes les conneries des projets upstream en pleine face. Et quand ça marche pas, on peut même pas accuser la distribution, parce qu'elle n'y est généralement pour rien, elle fait parfaitement ce qu'on lui demande. Mais juste, on à envie d'égorger upstream.

Les autres distributions, au moins, ont des mainteneurs qui rajoutent des bugs^Wfonctionnalités qu'upstream veut pas, et retire des fonctionnalités^Wbugs que les utilisateurs veulent pas. Et quand ça marche, on peut utiliser des logiciels fait par des trous du culs en oubliant qu'ils le sont.

Ce n'est pas parce que c'est documenté que c'est forcement une bonne idée.

Tu veux dire la matière ou tout le monde dort ?

Quant à la rapidité d'ouverture, sur Android, le client tourne en tâche de fond et averti d'un nouveau mail par notification. Plus instantané que ça, je ne vois pas.

Donc tu utilise une application native parce que c'est plus rapide.

CQFD.

La différence entre les pilotes wifi et les pilotes graphiques, c'est que personne ne comprend rien à wifi.

Je comprends, mais si l'usage me paraît logique, la possibilité de configurer ça est à mon avis hors de porter de la majorité des utilisateurs. D'ailleurs ce qui te semble la fonctionnalité minimum est implémentée presque nulle part (ou alors avec de la bidouille).

Windows en implémente une version limitée (utiliser une IP statique seulement s'il n'y a pas de DHCP). Et inutile de compter le nombre de logiciels Windows pour changer la configuration réseau en un clic.

Je comprends, mais si l'usage me paraît logique, la possibilité de configurer ça est à mon avis hors de porter de la majorité des utilisateurs.

Et alors ? À l'époque, configurer un réseau WPA2 sous Linux était hors de portée de la majorité des utilisateurs. Ça l'est toujours, mais NetworkManager simplifie ça pour le mode station et maintenant AP.

Je pense que ça viens du fait que l'énorme majorité des réseaux filières sont de l’Ethernet avec du dhcp dessus en IPv4 et que pour les réseaux sans fils, le SSID suffit généralement pour discriminer les réseaux.

Oui, mais ils ne sont pas forcement tous bien configurés, ou alors ils sont configuré de manière intentionnellement mauvaise: DNS ou suffixes DNS menteurs, filtrage de ports, proxy HTTP ou serveur SMTP obligatoire, et autres joyeusetés de réseau néo-nazis qui obligent à ne surtout pas utiliser la configuration proposée par DHCP et à dérégler ses programmes pour qu'ils fonctionnent.

Et pour les réseaux sans fils, le SSID ne suffit pas toujours. Dans la ML de NetworkManager, il y a notamment le cas d'un universitaire qui utilise eduroam qui à besoin de choisir lequel de ses deux comptes radius utiliser en fonction de l'université dans lequel il est, parce que les filtrages de port ne sont pas les mêmes si tu fait partie de l'université ou si tu viens d'une université extérieure.

On peut aussi parler du verrouillage du BSS, qui, du temps ou NetworkManager ne le supportait pas, était la mort à bidouiller en parallèle de NetworkManager.

Je comprends que ça puisse être très utile mais il me semble qu'avec les fonctionnalités de nm, on a quelque chose qui marche bien,

À l'usage, désolé mais … non. Le fait qu'il mette trois heure à se connecter sans dire ce qu'il est en train de faire, alors que à la main ça met trois secondes, le fait que ses messages d'erreurs sont dignes de Windows ("La connexion réseau a été déconnecté", il manquerai plus qu'un "contactez votre administrateur système") et ne servent absolument à rien, ou le fait qu'il fasse n'importe quoi lorsqu'il voit deux réseaux connus, en roamant de l'un à l'autre comme si c'était la même chose.

NetworkManager ça marche bien dans les cas simples. Mais si il suffisait de respecter les RFC pour avoir un accès au réseau qui marche, la vie serai bien meilleure.

qui réponds de lui même à une grande quantité d'usage et qui est relativement hackable (contrairement à ce qui me semble être une pensée bien établie).

Ce n'est pas parce que tu à quelques hooks dans un coin que tu peux prétendre que NetworkManager est un logiciel extensible et bidouillable. Franchement, un gestionnaire réseau sur lequel tu à des hooks dans lequel tu ne peux même pas changer la configuration IP sous peine de bordel général, j'appelle ça une blague. Dans un vrai logiciel hackable, on peut aussi changer le comportement par défaut. Dans le cas de NetworkManager, c'est codé en dur en C, et pas vraiment désactivable.

Dans le cas d'ifupdown, c'est un metascript compilé en dur (mais bidouillable par celui qui compile) désactivable avec le fameux mode manual, et avec ifup -v, tu connais les commandes qu'il exécute.

De plus je ne suis pas un spécialiste, j'ai parlé du script que j'ai trouvé, je ne sais pas si c'est réellement ça le plugin ifupdown.

Le plugin ifupdown (qu'il faudrai plutôt appeler module, pour être honnête intellectuellement) est écrit en C. Il est capable de lire les cas de configuration basiques de /e/n/i et de les appliquer, ou alors d'ignorer les interfaces listées dans ce fichier et de laisser un vrai ifupdown les configurer. Les distributions mettent généralement la deuxième option par défaut.

interface combinations are not supported

Met à jour ton noyau.

Les dernières versions d'iwlwifi supportent les combinaisons d'interfaces (mais pas forcement celles que tu veux, même s'il y a des chances que si).

Ça n'a absolument rien à voir.

Je branche un câble réseau. À quel réseau suis-je connecté ? selon le réseau sur lequel je suis, j'ai besoin d'utiliser une IP statique, du DHCP avec plus ou moins de bidouilles (genre utiliser des DNS custom, ignorer les suffixes DNS, changer la métrique de l'interface, et autres), utiliser autoconf IPv6, ou bidouiller les paramètres de certains programmes, notamment des proxy apt et des services que je veux activer sur le réseau. Je fais comment pour automatiser ça ?

guessnet, comme son nom l'indique, fourni des outils pour détecter sur quel réseau je suis, souvent en utilisant de l'ARP, mais d'autres méthodes sont disponibles. À travers le mapping d'ifupdown, il auto-détecte la configuration à utiliser au moment ou l'interface est configurée.

Et tout ça, sans modification d'ifupdown. Même si les mapping d'ifupdown n'étaient pas disponibles, une fonctionnalité équivalente aurai pu être scriptée en changeant les paramètres à la main et en utilisant le mode manuel.

Avec NetworkManager, tu fait ça comment ? certains paramètres sont gérées automagiquement, et NetworkManager écoute les modifications faites à ses interfaces via netlink. Autrement dit, c'est un bordel complet si tu modifie ses paramètres en même temps.

Et on parle d'une fonctionnalité vielle de 10 ans. Remarque, le support des bridges n'est apparu que dans cette version…

Ce que ton lien dit (et qui est possible, mais pas encore sous linux) c'est d'avoir une station connecté à deux (voire plus) AP sur des canaux différents. Il suffit que les APs supporte le powersave buffering et que les balises des AP soit suffisamment désynchronisées entre elles. Suffit juste de changer régulièrement de canal, mais avant de changer, dire à l'ancien AP que tu met ton interface wifi en veille pendant ce temps là. C'est de la bidouille, mais ça marche.

Par contre faire AP sur un canal et station non-AP sur un autre, ce n'est pas possible avec une seule radio, ou du moins pour l'instant: il n'y a pas encore de mode d'économie d'énergie pour AP qui soit suffisamment supporté par les stations.

Faire un équivalent de guessnet pour NetworkManager, c'est un cas "très pointu" ?

Oui alors je me suis raté je voulais écrire un troisième point qui est : c'est géré de base par nm, tu peut simplement le configurer lui.

C'est exactement le cas d'utilisation de guessnet: selon le réseau détecté, tu change les paramètres dynamiquement. Tu ne peux pas le décider à l'avance. Et si tu modifie les paramètres de NetworkManager pendant ce temps là, c'est la merde.

Ça reste extrêmement limité. Qu'est ce que tu fait lorsque tu veux toucher au paramètres passés à wpasupplicant ? Que tu veux toucher aux paramètres d'une autre interface quand tu en uppe une autre ? Que tu veux choisir à ce moment si NetworkManager à le droit de toucher à cette interface ? Est ce que tu peux modifier les paramètres IP dynamiquement à ce moment la ? Et si tu regarde ton rapport de bug, faire ce que tu décris n'est pas recommandé.

Avec ifupdown, tu peux totalement débrayer tout les machins automatiques en utilisant le mode manual.

C'est surtout que NetworkManager est extrêmement limité comparé à ifupdown. ìfupdown ne fait pas grand chose de base mais peut-être étendu assez facilement par des scripts shells. Pour étendre NetworkManager, il faut, selon ce qu'on cherche à faire, soit coder des plugins en C, soit causer en D-Bus (directement (pouah) ou indirectement via nmcli), soit modifier directement NetworkManager, soumettre le patch, se faire ignorer royalement par l'upstream et voir son patch intégré par les mainteneurs de certaines distributions ;)

1) Savoir si tu peux le faire dépend de la carte wifi (et de la version de ton noyau). Si tu veux quand même savoir si ta carte peut le faire, regarde la sortie de iw phy | grep -A 5 "interface combination". Mais note que, si ta carte n'a qu'une seule radio, l'AP que tu crée devra utiliser la même fréquence que l'AP que tu utilise. D'autres restrictions sur les paramètres de ton AP peuvent s'appliquer.

Mais de toute façon, NetworkManager ne sait pas gérer ça nativement (le contraire m'aurai surpris). Au pire, si tu lui crée une autre interface à la main (iw dev wlanXX interface add ap0 type managed), il verra l'interface comme si c'était une interface différente, et ça risque de marcher.

2) Ça dépend de la carte. Les cartes FullMAC font plein de choses en matériel, donc il faut que le matériel/firmware soit prévu pour. Les cartes SoftMAC font pas grand chose, et elles supportent généralement mieux des fonctionnalités pour lequel elles n'ont pas été prévues, mais elles ont parfois certaines limitations qui empêche de faire tout ce qu'on veut avec. Dans tout les cas, pour qu'une fonctionnalité soit utilisable, il faut que quelqu'un le code ;)

Ça m'apprendra à m'y prendre quelques jours avant la sortie ;)

Pour les ACK bidons, il faut savoir quel but tu veut atteindre.

Si tu veux couper la connexion et que l'un des deux pair légitimes cherche à couper la connexion, je vois pas pourquoi tu aurai envie de balancer des ack bidons, rien faire est parfaitement suffisant. Les acks bidons risquent plus d'empêcher la fermeture de la connexion qu'autre chose ;)

l'ACK que tu envoie quand tu détecte le RST litigieux est un ACK TCP parfaitement classique, qui va juste servir à indiquer quel est ton numéro de séquence attendu pour que l'autre pair se synchronise. Si l'autre pair n'a pas l'intention de couper la connexion, il ne va pas renvoyer de RST quand il recevra un ACK (qu'il soit bidon ou pas). Mais s'il a effectivement l'intention de couper la connexion, alors le standard TCP classique dit qu'il doit renvoyer le RST, parce que le précédent à potentiellement été perdu.

Les forges gratuites sont généralement publiques, donc tout ton code fait avec les pieds sera public dès le départ. Mauvaise solution. Et non, ton dépôt public n'est pas accessible partout, il te faut une connexion à de la donnée qui ressemble à internet qui ne soit pas trop censurée (donc exit les téléphonistes et les points d'accès publics avec des contrôleurs neonazis). Alors qu'une clef USB ou une carte SD dans ton portefeuille et des sauvegardes sur toutes les machines sur lequel t'a branché ta clef et c'est réglé.

Pour le reste, le workflow git c'est que tu bosse avec les autres, et pas contre eux. Après tu peux toujours prendre des analogies du genre "push c'est comme envoyer un patch à un projet et pull c'est quand tu veux merger les patches que t'a reçu", ou expliquer les méthodes de développement du noyau linux et comment git en est la matérialisation.

Tout mon propos c'est que si cette fonctionalité t'intéresse ca te prend 3 minutes chrono de t'écrire l'alias pour le faire. Bordel on parle d'automatiser 3 foutues commandes pour un dev. Si tu veux planquer ton repo dans ta working copy pour la mettre sur une clé USB il suffit de la mettre là. Il te faut après effectivement un alias pour faire le relocate automatiquement.

Sauf qu'on est pas des masochistes non plus. Pourquoi se trimballer avec une solution centralisée bidouillée pour être en local lorsqu'on en a une qui est prévu pour ça depuis le début, qui marche mieux et qui est plus simple ?

Comme dit plus haut, administrer ça me fait crissement chier, et si toi tu passe tellement ton temps à créer des dépôt SVN pour connaître la commande par cœur, moi je l'aurai oublié le lendemain, et il faudrai que je relise la doc mal foutue à chaque fois que veux créer un dépôt SVN, de la même manière que je passe mon temps à oublier comment s'appelle l'option --bare de git init et que je me souviens jamais de ce que je veux mettre à l'option --shared pour des dépôts publics.

À propos du besoin de relocate t'es au courant qu'un DCVS comme bazaar te force aussi à faire un fixup à chaque fois que tu bouges ton clone ? Oui oui !

Pour l'instant, personne n'a recommandé d'utiliser bazaar pour créer un dépôt local ;)

Tu parles soudainement d'utilisateur débile alors qu'on parle de dev. Un SCM c'est l'outil de base d'un dev.

Un dev n'est pas un admin. Moi en tant que dev, administrer ça me fait chier. Et je pense que je ne suis pas le seul.

Un SCM c'est l'outil de base d'un dev.

Non, c'est un éditeur de texte. Mais passons.

Si ton seul argument au fait que SVN soit chiant à mettre en place, c'est "un SCM c'est l'outil de base d'un dev", c'est comme dire que tu doit apprendre à utiliser ed parce que un éditeur de texte c'est l'outil de base d'un dev.

Tu donnes des avantages à git qui n'existent pas. Ton coup de *.pyc il existe aussi avec git. git init . && git add . te donne exactement la même chose qu'un svn import et les solutions sont exactement les mêmes.

À la différence que les gens qui utilisent git add . ont soit une grosse arborescence bien compliquée (pas notre cas), soit sont des utilisateurs de SVN, et que de toute façon, git add . ne commite pas, tu peux toujours enlever les fichiers que tu n'aime pas avant de commiter.

Il ne doit surtout pas lire la doc ni comprendre un bête svnadmin. Pourquoi il comprendrait git init et la structure de git ?

Ou j'ai dit qu'il ne doit pas lire la doc ? je dis que la doc de svnadmin est plus prévue pour des administrateurs que la doc de git init ou svn. Suffit de commencer à la lire pour le voir.

Et puis la structure de git, tu n'en a pas besoin pour git add && git commit. Tu en à besoin quand tu commence à brancher dans tout les sens, ou si tu travaille avec un dépôt distant qui branche dans tout les sens.

Il est tellment bête qu'il ne comprend que vaguement co/ci/log par contre il est capable de faire des rebase interactifs & co et d'en comprendre le conséquences. Comment dire ?

Faire un rebase interactif ça n'est pas aussi difficile à expliquer que ce que tu crois, même si la doc de git rebase est nulle. Et git te guide bien sur ce que tu peux/doit faire à chaque étape (oui, c'est les messages super-verbeux qui te font chier quand tu les connais par cœur). En comprendre les conséquences, ça ne s'applique pas tant que tu n'a pas publié, et c'est expliqué dans la doc mal foutue.

Tu as une commande à exécuter: svnadmin create. Et c'est de toute facon ce que tu fais sur le serveur quand tu instancies un repo.

Les utilisateurs n'ont pas à savoir créer un repo sur un serveur, ni même à savoir ce qu'est un protocole file://. Pour un utilisateur de base qui sait juste checkout/commit/update, comprendre un mot de la doc de svnadmin est bien plus compliqué que ce qu'il est habitué à faire.

Enfin bref, maintenant, tu à un répertoire dans un endroit rien à voir, et il faut penser à ne pas le paumer, en plus de ne pas devoir le déplacer et donc de ne pas pouvoir le stocker sur une clef USB.

Et ensuite:

svnimport myproject file:///path/to/myrepo/trunk -m "Initial import"

Voilà fini. Le reste c'est le workflow classique.

Non, ça n'est que le début.

Maintenant, tu à importé tout les fichiers du répertoire que tu voulais, y compris les log, sortie de débugs, fichiers *pyc précompilé, les *~ et swap files et autres fichiers que tu n'a pas envie de laisser dans le dépot. Il va falloir soit nettoyer ça dans un autre commit, soit récrire l'historique. Après te rendre compte que récrire l'historique, c'est trop compliqué pour toi, tu retourne à la case départ, rm -rf des répertoires concernés, nettoyage au préalable des sources, et recréation du dépot svn. Voilà, maintenant, tu à un dépôt SVN avec tes fichiers. On va pas trop regarder le fait que tout à été ajouté en un seul commit avec une description totalement inutile.

Alors qu'avec git, tu peux très bien choisir de ne versionner que les fichiers qui t'intéressent, et laisser les merdes en dehors de l'historique, sans à avoir à toucher un poil du fichier, et sans avoir à apprendre quelque chose de nouveau par rapport à ce que tu sais déjà : tu sais déjà faire git add puis git commit.

Et si tu te plante, git commit --amend. Mais si tu connaissais pas, tu peux toujours te recréer ton dépôt, il suffit juste de rm -fr .git && git init, ce qui restera toujours bien plus facile que de recréer un dépôt svn.

Et sinon, puisque le sujet de départ, c'était l'angoisse du programmeur qui n'a pas envie de publier les premiers commits crades, pouvoir récrire son historique, c'est pas mal aussi. Mon seul dépôt SVN local, je ne l'ai jamais publié, j'ai préféré ne laisser que les sources finales.

C'est bien plus chiant que git pour ça, et beaucoup moins documenté. Je l'ai fait une fois (j'étais pas root pour installer git), et j'en ai été guéri.

Avec git, il suffit juste de se décider à taper git init dans le répertoire ou il y a/aura les sources, et de commencer à commiter.

Non : en mathématique, 10 fois 100 millions est inférieur à 10 millions fois 200.

Donc il n'y a que 10 patrons voyous et 10 millions de fraudeurs à la sécu. C'est ça, on te crois.

Ça a peut-être un rapport avec ça:
http://lists.fedoraproject.org/pipermail/devel/2011-October/157671.html
http://lists.fedoraproject.org/pipermail/devel/2011-October/157760.html
http://people.gnome.org/~federico/news-2007-01.html

Résume simple: la notion de DPI n'a aucun sens pour les vidéoprojecteurs (elle dépend de la distance à l'écran, et même si elle est connue, ça ne sert à rien de l'utiliser: Elle est ridiculement faible, et si tu l'utilise, tes polices vont être illisibles de là ou tu est), et, à cause du problème de la fenêtre a cheval sur deux écrans, tu est obligé d'utiliser qu'une seule valeur de DPI.

Le problème du DPI est loin d'être simple. Et ne parlons pas des DPI bidons dans des EDID incorrects.

et comment tu spécifie une option qui a changé de nom/n'existe plus/.. dans la mise à jour ?

Tu demande à l'admin. Si ça se trouve, l'option était primordiale, et sans elle, le logiciel deviens inutile dans ce cas. Ce n'est pas le genre de chose que tu peut mettre à jour automatiquement.

Comme ils le disent si bien, ça ne supporte pas le rts/cts et la qos. Si on rajoute ça et toutes les combinaisons possibles en 802.11n du genre protection HT/green field et la plétore d'*ifs, la machine à état, même hiérarchique, va devenir un joyeux bordel.

Le problème des machines à états, c'est que tout rajout de fonctionnalité produit des patches très invasifs.

S'il y a de la sauvegarde d'états, ce n'est plus une machine à états finis.

Et ne parlons pas de la duplication de code engendrée lorsque une boite de dialogue/écran apparaît dans des hiérarchies différentes.

Là c'est un peu facile comme cas d'utilisation: il faut que tu recopie une machine à états déjà faite qui marche et qui ne peut pas changée. Dans la vraie vie, ils y a des normes qui ont des machines à état buggées, et c'est marrant de voir comment les implémenteur se vautrent une fois qu'ils ont découvert que la machine à état ne peut pas marcher. Le problème, c'est que généralement, ils ne changent pas la structure de la machine à état.

Et surtout, le problème des machines à états dans les réseaux, c'est que tu ne sais pas quoi faire d'événements qui ne sont pas censés arriver, et donc tu n'a pas deux implémentations qui font la même chose. Les protocoles qui sont spécifiés par du code asynchrones ne permettent pas d'ambiguïtés.