Batchyx a écrit 1261 commentaires

Et si tu reposes sur le comportement de ifconfig Linux tout le monde va gueuler par ce que c'est pas portable. C'est sans fin.

Te reposer sur le comportement de ifconfig Linux pour faire quoi ?
Si c'est pour que l'administrateur configure son interface, pas besoin que ça soit portable. Si c'est pour qu'un programme configure une interface, il n'a qu'avoir un comportement par défaut indiquée par la distribution et changeable par l'administrateur.

J'ai pas regarder le côté réseau, qui à l'air bien léger, et je pense même pas que systemd implémente cette partie.

Si tu as bien suivi, le seul cas ou on peut mettre une configuration réseau cablée qui soit utile (permette d'accéder à un internet IPv4), c'est le cas ou on utilise DHCP, c'est à dire précisément le cas ou (dans 95% des cas) il n'y a pas besoin de configuration !

Mais faut bien commencer par quelque chose non ? Si ça marche pour 90% des gens automatiquement, et que ceux qui ont besoin de plus peuvent garder l'ancienne méthode c'est un problème ? Maintenant qu'on a eu la démonstration que c'était débile on propose quoi ?

La proposition à faire est bateau, c'est repenser le problème de base et vérifier que c'est bien à toi de le corriger. Parce que "je veux un moyen dans gnome pour configurer les paramètres réseau de toutes les distribution", ce n'est pas un problème, c'est une solution. Mauvaise.
Si le réseau est chiant à configurer dans une distribution, c'est le problème de la distribution. Les utilisateurs choisissent aussi leurs distributions en fonction de ça. Si je préfère configurer mon réseau avec ifupdown en manual avec des hooks customs, ce n'est pas pour qu'un programme décide à ma place (et potentiellement aussi à la place de ma distribution) comment est configuré mon réseau.

Si tu trouve qu'un bidule de configuration qui ne supporte ni IPv6 ni les configuration statiques c'est trop génial, intègre le dans ta distribution. Et non, Gnome n'est pas une distribution.

Oui c'est du poulet :

The backends are a single executable application containing the following DBus Objects

Objets qui doivent gérer les utilisateurs et groupes, la résolution de nom, la configuration des interfaces réseaux, les montages NFS, la synchronisation NTP, la configuration du démarrage des services, la configuration de samba, la gestion du temps…

Enfin bref, n'importe quel programmeur sérieux ne mettrai JAMAIS toutes ces fonctionnalités là dans UN SEUL programme. Et quand même, on touche à la configuration du système là, on peut facilement péter le boot avec ces choses là. Ce n'est vraiment pas quelque chose à prendre à la légère.

Il y a pas si longtemps, j'expliquai déjà pourquoi on voudrai pas refaire des utilitaires ifconfig/route qui utiliserai les nouvelles API du noyau, puisque ces nouvelles API ont des fonctionnalités supplémentaires qui n'ont pas d'équivalents en ioctl, et que la question de savoir si il faut écraser, ignorer ou bidouiller les fonctionnalités supplémentaires était loin d'être évidente.

Mais là, quand je vois les paramètres réseaux qui doivent pouvoir être changés pour une carte ethernet via cette interface D-Bus, c'est à se tirer une balle :

Integer32 Whether the interface is enabled
Integer32 Whether the interface is enabled automatically at boot time
Integer32 Method to obtain the IP address (Static IP, DHCP)
String IP address
String Network mask
String Network base address
String Broadcast address

Même ifconfig à plus de fonctionnalités que ça. Parce que là, IPv6, on oublie, ça n'existe pas. Ajouter une gateway par défaut en statique ? C'est quoi une gateway ? Passer des paramètres à DHCP ? Mais pourquoi faire ?!?.
Et je vous parle pas des autres types d'interfaces (genre Wi-Fi) ni du comportement du code pour modifier la configuration (dans les distribs que je connais en tout cas), parce que là, c'est tout simplement dangereux. Parce que par exemple, sous Debian, s'il voit des options qu'il ne connaît pas, il les écrases et remet des options par défaut, et cela, dans un fichier ou c'est explicitement indiqué qu'aucune application n'a le droit de modifier automatiquement. Et ce n'est que la partie "configuration des interfaces réseaux". (parce que, juste comme ça, il y a aussi un autre logiciel pour gérer la configuration réseau. Il manque un peu de fonctionnalités, mais il en supporte nettement plus et il couvre plus de cas d'utilisation. C'est un petit logiciel peu connu qui s'appelle NetworkManager. Ça couvre pas la moitié des fonctionnalités dont j'ai besoin chez moi, mais c'est largement suffisant pour bien d'autres utilisateurs. D'ailleurs je crois même que c'est intégré dans Gnome).

Et si on veut revenir à la gestion des fuseaux horaires, je ne vois pas pourquoi un utilisateur devrai forcement utiliser le fuseau horaire du système. Surtout en 2012.

Franchement, Une abstraction dans ce cas la, c'est non. Surtout dans un cas pareil, ou on est typiquement dans le cas ou chaque pourcentage d'utilisateurs à besoin d'une fonctionnalité particulière de sa distribution. Soit cette abstraction supporte toutes les fonctionnalités des distributions supportées et les programmes qui utilisent ces abstractions sont des monstres quasiment spécifiques à là distribution (ce qui est un peu le contraire du principe d'une abstraction), Soit elle sera inutile pour une partie des utilisateurs, et écrasera ou ignorera des options de configuration, alors que ces options étaient peut-être là pour une raison.

Au final, c'est soit dangereux, soit inutile. Vouloir faire des abstraction pareilles sur des méthodes de configurations alors que ça fait partie des raisons pour laquelle il y a différentes distributions, c'est vraiment idiot, et l'échec est prévisible. C'est à la distribution de faire l'intégration, pas à upstream.

Il n'y a pas d'ioctl non dépréciés, seulement des socket netlink(7).

Et sinon, ifconfig sert principalement à deux choses: afficher des informations sur les interfaces, et modifier la configuration IP. Et faire l'un ou l'autre de manière tronquée n'est pas vraiment une bonne idée.

Par exemple, ifconfig ne supporte pas plusieurs addresse par interface réseau sans passer par des alias moches, n'affiche pas les flags sur ces addresses et n'affiche pas d'information sur les queues utilisées. Ça veut dire que si un autre programme (ou le noyau) rajoute ou se sert de ces fonctionnalités derrière ton dos, tu n'en saura rien. C'est criant en IPv6 : l'autoconfiguration est implémentée par le noyau, donc tu à peut être envie de savoir pendant combien de temps tes addresses IPv6 sont valides pour ton interface.

Ensuite, pour la modification de la configuration, ça pose aussi des problèmes, par exemple, est ce que ifconfig doit virer tout les flags si tu change une addresse IP? Certains de ces flags peuvent faire mal si on ne les voit pas.

Dans ifconfig, il y a aussi des options de configuration bas-niveau (du genre IRQ, addresse io de base et autres) qui n'avaient rien à faire là et dont aujourd'hui plus personne n'en à rien à faire.

Avec la commande route (remplacée aussi par ip), c'est encore pire, puisque il y a bien plus de fonctionnalités ajoutées qui peuvent faire la différence entre un réseau qui marche et un réseau qui marche pas.

Enfin bref, si on veut un ifconfig amélioré qui n'utilise plus d'ioctl, on utilise ip

C'est quoi ce FUD ? Il n'y a pas une personne qui décide, c'est un processus ouvert et tu es libre de contribuer. Pour le protocole syslog, ca a pris 6 ans pour arriver à la RFC finale. Rainer en a simplement été l'auteur. Je peux te dire qu'il est compétent, pro et ouvert, c'est un bon auteur de RFC. Comme dans tout groupe de travail de l'IETF tout ce dont tu as besoin pour contribuer c'est d'une adresse mail; et corrige moi si je me trompe, mais la tienne n'est pas apparue sur la liste du WG.

Sauf que je parle pas de RFC mais d'implémentations. Ça serait pas le premier à savoir faire des RFC géniales mais à ne pas savoir faire une implémentation qui tienne la route.

La seule chose qui pourrai m'intéresser (et sur lequel je peut contribuer), c'est du code. Parce que faire des bonnes implémentations de standards pourris qui se contredisent, je suis presque payé pour ça. Mais pour ça il me faut un standard.

Mais là, ce qui m'importe le plus, c'est comment ça va s'intégrer dans ma distrib. Si c'est encore du "il n'y a qu'une implémentation, pourquoi tu voudrai en changer ?" comme c'est trop souvent la mode en ce moment, alors là je vais commencer à râler, surtout si des patches intéressants (que ça soit les miens ou pas) sont refusés.

Tu déformerais pas un peu l'histoire à ta sauce ?

Il y a une part d'ironie dans cette partie. Quoi que, parfois je me demande si ça n'est pas un peu vrai.

Sauf que dans le cas ou j'utilise les sous modules il faut en plus que je trouve un moyen de ma'assurer que ma journée de sauvegarde est bien cohérente (si pour une raison ou une autre un des sous modules n'a pas commité au 31, alors submodule update va remonter silencieusement la dernière bonne version connue, qui peut dater.)

git submodule update ne va pas "prendre la dernière version connue", elle va prendre la version associée au commit courant. Autrement dit, celui du 31 décembre.

Si un submodule n'à pas été changé par le commit du 31 décembre, tu peux t'en rendre compte en regardant le commit. Tu peux aussi mettre l'information dans le message de commit pour qu'elle soit plus visible…

Ça utilise des ioctl dépréciées, et c'est extrêmement pauvre en fonctionnalités lorsque l'on compare ça à ip qui utilise principalement des interfaces netlink.

Il n'y à rien de choquant à ne pas vouloir utiliser D-Bus. Il n'y à rien de choquant qu'une application ait besoin de RPC. Il n'y a rien de choquant que l'application se repose sur du code externe pour faire des RPC.

C'est lorsqu'on commence à mélanger "fonctionnalité" et "logiciel" que les problèmes commencent. Moi en tant que programmeur, j'ai envie de faire des RPC entre mes applis ou d'autres applis peu importe si ça passe par D-Bus, par du socket Unix/TCP ou par du morse sur SIGUSR1. J'ai envie de faire du RPC extensible ou l'utilisateur peut choisir d'utiliser du bidule lourdingue, du TCP vers l'autre bout de la planète, du pigeon voyageur ou de l'échange de disquettes, ou alors d'utiliser le super système révolutionnaire qui n'existe pas encore.

Sauf que D-Bus, c'est du genre "pourquoi tu voudrai utiliser autre chose ?", et donc c'est une interface bien compliqué pour ce que ça fait, et tu ne pourra jamais réimplementer une RPC se faisant passer pour D-Bus sans que ça soit aussi lourdingue que D-Bus.

Et oui, c'est choquant, parce que à un moment donné, on se rendra peut-être compte que D-Bus c'est de la merde en barre, de la même manière qu'on s'est rendu compte que ext2 est de la merde en barre. Sauf que pour ext2, Il n'y a pas eu besoin de recoder toutes les applis pour changer de système de fichier. Alors que pour D-Bus c'est juste très loin d'être le cas.

Et ben faut croire que c'est pas si clair que ça.
Si on prend par exemple le fait que le créateur de rsyslog bosse sur lumberjack, y'a quand même de quoi se poser des questions, non ?

Je compterai pas la dessus. Déjà, j'ai un peu du mal à considérer rsyslog comme une référence. En 2012, un logiciel qui perd des logs, qui change l'ordre des lignes ou qui les dupliques, moi ça me fait peur (surtout pour le peu que je voulait faire !). Parce que la différence entre un bon logiciel et un mauvais logiciel, on ne la voit que quand le logiciel marche pas.

Et franchement, laisser une personne décider ce que doit être un système de log, laisse moi rire. Un programmeur n'attend pas la même chose d'un système de log qu'un admin ou un utilisateur. Dire qu'on va résoudre "le problème" (et oui il n'y en à forcement qu'un) de tout le monde avec la magie des logs structurés, c'est comme dire qu'on va résoudre tout les problèmes de Linux avec une distribution unique.

C'est un peu facile comme raisonnement.

• Comment tu empêche un jeu en ligne d'envoyer toutes tes conversations dans le jeu à un tiers ?
• Comment tu empêche un client mail d'envoyer tout tes mails à tes ennemis ?
• Comment tu empêche une application bureautique de cacher des documents sensibles dans un autre document destiné à devenir public ? (les deux documents peuvent potentiellement être ouverts en même temps)

Zéro, c'est largement suffisant pour visiter une page publique contenant des informations publiques.

De là deux solutions. Soit tu sauvegardes tout ce qui a été fait depuis la cloture en bloc, tu restaures tout au 31 décembre en bloc et de là on avance pas à pas. Soit tu as 43 sauvegardes distinctes et là tu vas jouer à "komenkonfè" et "keskimanke" pendant deux mois

Et bien tu prend la première solution, qu'est ce qui t'en empêche ?

Ah, et pour revenir au 31 décembre en bloc, c'est cd $depot_parent && git checkout $le_commit_du_31_decembre && git submodule update (et peut-être un git submodule foreach git push, ça dépend comment tu organise tes dépots)

Je suis toujours pas sûr d'avoir compris (c'est quoi un "bloc" ?), mais pour moi, si tu à 43 choses différentes à sauvegarder, alors tu à 43 dépots.

Et si tu à envie de versionner l'état de tes 43 dépots, alors tu crée un autre dépot parent qui possède les 43 dépots en sous-modules. le dépot parent ne va versionner que les hash des révisions de tes 43 sous-modules, mais va le faire avec toutes les fonctionnalités de git : messages de commit, branches, tags …

Bon après, les sous-modules, c'est pas la fonctionnalité la plus génialement faite de git, c'est un peu mal intégré avec le reste…

De ce que j'en comprend, t'a envie de tags, pas de branches. Mais en même temps je comprend toujours pas pourquoi tu veut créer une branche par jour, même s'il n'y a rien qui t'en empêche.

Et pour savoir qui à fait le con sur un fichier, c'est du coté de git blame (ou sa gui) qu'il faut regarder.

• IPv6 continuera de marcher.
• ARP aussi.
• Si c'était configuré, tu routera encore de l'IPv4.
• Selon ton noyau, tu pourra toujours recevoir du multicast IPv4.
• Tout ce qui joue avec des socket af_packet marchera encore. Par exemple, certains serveurs (et clients?) DHCP.
• Et surtout: ça coupe toutes les interfaces, même lo ou celle qui est censé servir de backup.

Ça ne suffit pas à couper la couche IP, si c'est ça que tu voulait.

Hacke ton noyau, de préférence dans le driver que tu utilise, et demande lui de dropper les frames selon un paramétrage dans debugfs. Peut être qu'il y a déjà des paramètres dans debugfs capable de faire bugger ta carte.

Bon sinon, en méthodes un peu plus soft, je ne sais pas si tes applis verront ça, mais au démarrage, tu peux renommer eth0 en real_eth0, créer un bridge "eth0" qui bridge real_eth0 et une interface dummy0 et continuer ton démarrage. Lorsque tu veux péter ton câble réseau, vire real_eth0 du bridge.

Mais si dans ta conf ton eth0 doit déjà faire partir d'un bridge, ça marchera moins bien … Dans ce cas la, regarde peut-être du coté de ebtables.

Pour les gros fichiers binaires, il y a git-annex. Ça ne garde pas l'historique du fichier (seulement celui de son hash) et ça utilise rsync en dessous quand il faut transférer les données.

Est ce que le projet accepte les contributions extérieures ? si ce n'est pas le cas, c'est niet, j'attendrai le fork.

Ce que je veux dire, c'est que mkdir() va déjà vérifier toutes les préconditions avant de créer le répertoire. S'amuser à les réimplementer dans le code qui l'appelle pour éviter des exceptions, c'est bien joli, sauf que comme toutes les réimplementations, elles seront buggées, et si jamais les préconditions de mkdir() évoluent plus rapidement que ta réimplementation de ces préconditions, ça risque d'être drôle. Au final, ça n'est rien d'autre que la duplication de code. Pour rien.

Et je ne parle pas du cas ou la fonction à appeler n'est pas mkdir(), mais une fonction passée en paramètre.

Mauvais exemple: Ce n'est pas parce que exists() te dit que le répertoire n'existe pas que ton mkdir ne va pas échouer avec une erreur du type "le répertoire existe déjà", et inversement.

Au final, ton code deviendrai lourdingue :

try {
    if(!exist(dir)) {
        mkdir(dir);
    }
}
catch (IOException e) {
    if (/* exception dut à préexistence de dossier */) { /* OSEF */ }
    else { /* Erreur */ }
}

Et c'est en supposant que les erreurs renvoyées par exists() aient la même sémantique que les erreurs renvoyées par mkdir. Si ce n'est pas le cas, il faudra les mettre dans des try séparés. Mais du coup, l'intérêt des exceptions de séparer le bon cas du mauvais cas est perdue.

Mais sinon, s'amuser à réimplémenter de façon buggée toutes les vérifications que peut faire le mkdir() actuel dans le code qui l'appelle, c'est pas vraiment une bonne idée, surtout si ton mkdir() change souvent (ici c'est pas le cas, mais avec d'autres fonctions …).

int bad = open("blah", O_RDONLY);
BOOST_SCOPE_EXIT ( (&bad) ) {
    if (bad != -1)
        close(bad);
} BOOST_SCOPE_EXIT_END
do_something(bad);

Et donc, quand l'anti-spam de l'utilisateur efface le mail, il faudrait aussi avertir l'autre… Bizarrement, personne ne le fait.

Hors sujet: L'utilisateur (ou son antispam) n'efface pas son mail avec SMTP.
Et si il efface le mail, c'est son problème. Du point de vue du protocole, il à reçu le message, et il ne peut affirmer le contraire.

Mais si tu répond que tu accepte d'assumer la responsabilité de transmettre le mail jusqu'à son destinataire mais que tu jette le mail, tu est juste malhonnête. Et tu casse la transaction, puisqu'il n'y à plus personne pour s'assurer que le mail soit transmis.

Idem. Ca dépend vraiment du point de vue…

la RFC ne prévoit pas que tu puisse choisir ton point de vue comme tu en a envie. Si tu n'est pas d'accord avec la RFC, alors utilise un autre protocole et vire ton MX et ton serveur SMTP.

Mais pour moi hors de question de perdre des ressources à informer un spammeur qu'on l'a détecté. Rappel : on parle de mails dont on est sûr que c'est du spam.

Tu n'a rien détecté du tout, tu ne fait que des suppositions vagues. SMTP ne standardise aucun moyen pour détecter le spam, et encore moins de valider la transaction tout en jetant le mail, même si ta méthode foireuse est soit disant sure à 100%. Tout ce que tu fait n'est autre qu'une violation du protocole.

En plus, ça te coûterai moins cher de répondre un 542 Zenitram hates you avant même que tu reçoivent le mail plutôt que de gaspiller la capacité de ton lien pour recevoir de la merde.

SMTP n'est pas un protocole de transport de contenu. Tu n'a pas besoin de protocole au dessus de TCP pour transporter du contenu, un netcat suffit largement (Si tu veut simplement transférer des octets, n'utilise pas TCP).

SMTP est un protocole transactionnel qui garanti le transfert de responsabilité de la livraison du message entre différents serveurs. Pour que ça marche, il faut bien entendu que à tout instant, les protagonistes aient la même vision de la transaction. Les codes de réponses SMTP ne servent pas à dire si le transfert est bon ou pas (TCP est largement suffisant. Si le serveur arrive au point ou il doit envoyer le code de réponse, c'est que le transfert est forcément bon), mais à indiquer l'état de la transaction.

Si tu peux/veux pas commiter et que tu dit que le commit est bon, t'est juste en train de casser la transaction et de rendre le système incohérent. Si ça te fait plaisir de faire ton byzantin, il faudra pas s'étonner que les autres arrêtent de te causer, et il faudra accepter que les autres fassent leur byzantin quand tu leur envoie des messages. Si tu trouve ça normal, alors rappelle moi de ne jamais te confier un réseau ou tout autre système distribué.

C'est bizarre, je croyait que c'était TCP qui était chargé du transport …

J'ai tendance a penser que cet argument est particulierement mauvais, sachant que de switcher entre fenetres se fait relativement peu souvent, a moins d'avoir la concentration d'un gamin de 3 ans gave de sucre.

Si tu est un fan des grosses applis lourdes qui font tout ce que tu à besoin, tu doit pas voir beaucoup l'intérêt des bureaux virtuels. Mais sache que ce genre d'applis n'existe pas dans tout les cas et que tout le monde n'en est pas fan.

C'est sûr que si tu utilise Emacs, je ne vois même pas l'intérêt de rajouter un gestionnaire de fenêtre de plus, sauf peut-être pour lancer un éditeur de texte.

Et je n'ai toujours pas d'exemples de dizaaaaaines de fenetres…

Au boulot, je ferme jamais ma session (j'ai pas dit que j'éteignais jamais ma machine), et je sépare chacune de mes taches en bureaux virtuels. Si on me demande de faire la tâche A, je vais sur le(s) bureau(x) virtuel(s) qui correspond(ent). Si on me demande de faire la tâche B, je vais dans un autre bureau virtuel, et si la tâche B est bloquée (du genre grosse compilation ou autre événement bloquant long et ennuyeux), je peux revenir rapidement vers la tâche A en attendant.

Avec facilement trois fenêtres par tâche, ça monte vite.