Batchyx a écrit 1261 commentaires

Encore une fois, parce que tu n'as toujours pas l'air d'avoir saisi le sens de ma remarque, ce n'est pas parce que c'est un très bon développeur que ça fait de lui un expert réseau, ce qui est un domaine assez différent.

Justement.

Toi tu pourra certainement lui faire des cours sur comment faire un réseau des grands pères, filaire 100 mbit avec 0.00000001%⁻de pertes entre des machines qui sont toujours branchées, allumées, joignables (en unicast et multicast) et présentes, qui ne bougent jamais et qui forment un réseau bien géré, bien préparé à l'avance, ou la norme est respectée scrupuleusement par les équipements et des administrateurs.

Sauf que lui il pourra t'apprendre ce qu'est un OS généraliste et pourquoi ce n'est pas la même chose qu'un OS pour desktop et serveurs. Et que c'est largement mieux quand Linux possède les fonctionnalités pour faire ou recréer ce que tu demande, plutôt que d'avoir une partie non-négligeable de tes utilisateurs qui appliquent des ribambelles de patch écrits par des gorets qui plantent dans tout les sens pour faire la même chose. Surtout quand ces utilisateurs font parti de ceux qui sont obligés de savoir coder pour faire ce qu'ils font.

D'ailleurs il dit que c'est orienté "host internal", mais l'exemple qu'il donne, c'est de router un morceau de 127. vers eth0, et que ça ne le dérange pas que les gens utilisent ça pour leur adressage interne dans leur réseau…

Dans le cas ou tu est dans une machine virtuelle, eth0 pourrai être ta seule interface vers l'hôte. Nulle par il dit qu'il veut router 127/8 à travers un vrai lien…

Après, tu connais rien sur sa configuration. Si ça se trouve, son load balancer marche déjà en IPv6, mais il veut qu'il puisse aussi marcher indépendamment en v4 sans avoir à réserver des adresses sur le vrai réseau.

S'il se sent concerné par un manque d'adresses IP, qu'il travaille au déploiement d'IPv6, ça sera certainement plus utile.

Et qu'est ce que tu veux qu'un développeur noyau fasse de plus pour déployer IPv6 quand tu à déjà une stack qui marche ?! Ça serait plutôt aux experts réseaux de ton genre de se bouger le cul. Ça et les développeurs d'applis en espace utilisateur.

C'est pas mieux que d'en faire publier dans de véritables (ou pas) journaux scientifiques.

Vu comment le noyau fonctionne, je trouve que c'est une bonne chose. Ça permet de rendre 127/8 moins spécial, et il manquerai pas grand chose pour que ce comportement soit activé de base et qu'on puisse simplifier un peu le code, sans qu'il y ai de changement visibles par l'utilisateur qui verra toujours ses 127/8 droppés en entrée s'il n'a rien fait de spécial.

127/8 serait alors juste configuré par défaut comme une plage d'adresses de l'interface lo (donc réservée à l'hôte) et serait traité comme toutes les autres. Et si tu voulait router cette plage d'adresse quand même, il faudrait juste commencer par aller virer la route qui dit que ça appartient à l'interface lo (comme indiqué dans le patch).

Comprends pas là? Les pertes de paquets ça arrive, lors d'un changement de route ou autre, donc de toute manière il faut bien un mécanisme de reprise soit fourni par la couche réseau TCP/SCTP soit à faire soit même (le reste).

Dans le cas ou tu fait du téléchargement de grand mère ça ne pose aucun problème. Mais pour tout le reste, dans bien des cas c'est irrécupérable. Par exemple pour le multijoueur ou la voip (ou tout ce qui à une contrainte de délai) si tu perd un paquet, t'est foutu, et le temps que tu t'en rende compte, c'est déjà trop tard.

Dans les cas usuels, ça ne devrai pas être le cas. Moi quand je change mes routes, tout le cache est déjà flushé par le noyau. Le seul cas ou le cache à besoin d'être flushé manuellement, c'est lorsque la page de manuel de (par exemple) ip rule te dit de le faire.

Et le problème que j'ai quand je veux changer des routes, c'est plutôt que tout les paquets dans la file de la première interface partent dans /dev/null. TCP s'en fout, mais pas le reste …

Moi j'avais un autre bug chiant: Le cache dans 3.0 était mal foutu et lorsque tu recevait un ICMP redirect, il était appliqué jusqu'à la fin des temps, même si tu vidait ton cache et tes règles. Vu que maintenant ce bordel se trouve dans l'entrée de table de routage, si y a un problème, alors virer l'entrée de routage et la refaire est suffisant pour se débarrasser des redirections.

Après il faut voir si ça vaut vraiment la peine de vouloir utiliser ça avec les paramètres nommés de boost, et les constantes littérales de C++11 juste pour pouvoir écrire make_rect(_x=1cm. _width=1inch, _y=a.y, _height=a.height);

L'avantage d'utiliser ssh -X, c'est surtout pour éviter que tout le trafic X11 passe en clair sur le réseau.

J'imagine bien un problème avec les filtres de réception multicast… le mieux c'est de reporter ça sur la mailing list net-dev :

http://vger.kernel.org/vger-lists.html#netdev

Si mettre la carte en mode promiscuous résoud ton problème, c'est plus un bug de ta carte réseau/driver qu'autre chose.

Essaye de lancer tcpdump avec l'option -p (sans promiscuous) et regarde si ça continue à ne pas marcher. Puis stoppe la capture et lance ip link set eth0 promisc. Si ça se met à marcher, alors c'est très certainement un bug du driver de ta carte réseau.

Dans ce cas la, les diagnostics noyau habituels s'appliquent: Donne nous la version de ton noyau, et essaye un noyau plus récent si possible.

Donc tu vois qu'il y a des vérifications à faire (même si t'a pas du beaucoup utiliser C++ dans ta vie…)

On va faire simple :

template<typename T>
void faire_quelquechose(T t) {
     t.

Montre moi comment tu autocomplête à cet endroit. Tu pourrais regarder les usages de faire_quelquechose(), même si là plupart du temps, ils ne sont même pas encore écrits. Tu pourrais me sortir l'intersection de tout les membres des T utilisés, ce qui n'est pas toujours pertinent, puisque tu ne sait peut-être pas que j'ai envie de spécialiser faire_quelquechose juste après. Et pourtant, ça n'est qu'une bête fonction template, alors imagine ce que c'est avec du vrai code qui fait de l'injection de dépendance (chouette, un buzzword) avec des templates

Oui, il faudrait pouvoir vérifier les usages. Quand on à du vrai code ou il y a des templates qui appellent d'autres templates, tu ne peux vérifier l'usage que lorsque du code non-template commencera à utiliser ta chaîne d'appel. Et si jamais il y a une erreur d'instantiation, tu ne sais jamais la faute de qui c'est. Autrement dit, ton IDE n'est pas plus avancé que ton compilateur, et un bête :make sous vim fait très bien la même chose que ton IDE.

Comment tu fais avec sed pour vérifier que tu n'es pas entrain de renommer une autre méthode d'une autre classe, mais qui a le même nom ?

La question ce n'est pas de savoir comment ne pas renommer une autre méthode d'une autre classe, mais de savoir si c'est pertinent.

class A {
    void faire_quelquechose();
};

class B {
    void faire_quelquechose();
    void faire_autre_chose();
}

// peut être utilisé avec A et B.
template <typename T>
class User1 {
    void f(T& t) {
        t.faire_quelquechose();
    }
};

// peut être utilisé avec A et B
template <typename T>
class User2 {
    void f(T& t) {
        for (unsigned i = 0; i < 5; ++i)
            t.faire_quelquechose();
    }
};

void usage_actuel() {
    User1<A> user1;
    User2<B> user2;
    A a;
    B b;
    user1.f(a);
    user2.f(b);
}

Je veut renommer A::faire_quelquechose() en A::do_something() avec un outil automatique. Est ce que je modifie que son usage dans C, ou est ce que je modifie tout, comme sed ? Dans les deux cas, le code compile quand même. Mais les commentaires donnent plutôt raison à sed.

Et encore, on est dans un cas simple, vu qu'on peut faire la même chose en C avec des macros. Si j'ajoute un petit utilisateur un peu plus compliqué (version C++11, je vous épargne la version C++03):

template <typename T>
auto faire_la_meilleure_chose(T* t, T* bidon) -> decltype(t->faire_quelquechose()) {
    t->faire_quelquechose();
}
template <typename T>
void faire_la_meilleure_chose(T* t, void* bidon) {
    t->faire_autre_chose();
}
// peut être utilisé avec A, B, et aussi C que j'ai la flemme de définir.
template <typename T>
void user3(T& t) {
    faire_la_meilleure_chose(&t, &t);
    // et autre chose au passage.
}
void usage_actuel() {
    B b;
    user3(b);
}

Pour ceux qui ne connaissent pas le C++ autant que nous deux (parce que tu le comprend ce code, hein ?), la version python est plus courte :

def user3(a):
   if hasattr(a, "faire_quelquechose") and callable(a.faire_quelquechose):
       a.faire_quelquechose()
   else:
       a.faire_autre_chose()
   # et autre chose au passage.

(et qu'on vienne pas me dire que C++ ne fait pas de duck-typing)

Sachant que B à aussi faire_autre_chose(), ne pas renommer l'usage par user3 va aussi produire un code qui compile. On est même pas dans un programme complet, mais on à déjà deux choix à faire, et donc 4 cas possibles. Seul le programmeur pourrai choisir ce qu'il faut faire pour ne pas se retrouver avec du code qui foire à l'exécution, et un simple sed amélioré qui demande si il faut remplacer ou pas est ce qu'il y a de mieux, un peu comme :%s/faire_quelquechose/faire_autrechose/gc dans un vim, quoi.

Et là ton programme il compilait et il connaissait les utilisateurs. Imagine si c'était une bibliothèque et que ce seront les utilisateurs de la bibliothèque qui écriront usage_actuel(). Tu ne peux pas vérifier tout les cas dans un vrai programme, parce qu'il y en a plusieurs milliers (si le nombre est fini), et avec tes tests, tu n'en couvrira qu'une toute petite partie.

Je n'es pas parlé de faire un calcul de tout les chemins (je vois pas pourquoi tu parle de ça). Je vois pas en quoi c'est non-pertinent (mais c'est bien reste avec tes aprioris et ton assurance que toi tu sais contrairement aux autres). grep va te ressortir un tas de faux-positif (si ça te conviens tant mieux, il m'arrive d'utiliser ack).

Simple : Parce que tout les chemins pertinents, tu ne les connais pas, pourtant tu en à besoin, rien que pour simplement renommer une méthode, et ce, même si ces chemins ne sont pas utilisés (ou alors pas encore). grep va sortir plein de faux positifs, tout comme Visual C++ 2010. Moi, personnellement, je préfère les faux positifs aux faux négatifs.

Ça n'a rien de compliqué de mettre en place ce genre de truc. En Python Tu dois pouvoir faire un truc qui marche pas superbien mais qui dépanne avec un grep sur le def (c'est plus technique en C, C++ et java qui n'ont pas de mot clef pour ça).

Ça n'a rien de très compliqué de rechercher les vrais usages dans un code qui compile, le compilo le fait très bien. Le problème, c'est que d'un point de vue du programmeur, du code peut être lié à d'autre code, même si le chemin n'est pas utilisé.

Aller, un exemple en C pour la route :

#ifdef ACTIVE_LE_DEBUG_STEPLAIT
void debug(int severity, const char* format, ...); // avec définition ailleurs.
#else
static inline void debug(int severity, const char* format, ...) { }
#endif

Si le debug est activé, la version sans debug n'est jamais utilisée. pourtant elle est importante, et doit suivre les évolutions de la fonction réellement utilisée. Cela peut rendre la fonction "sauter à la définition" non-pertinente, puisqu'il y a deux définitions.

Et ce cas là est facile, puisque si on ignore les macros, on peut voir deux déclarations.

Je présume que tu n'édite pas tout les modules de ton projet en même temps (si c'est le cas tu a peut être un problème d'architecture) de plus je présume que tu ne modifie pas les bibliothèques que tu utilise.

Une des bibliothèques que j'utilise, est boost. Je ne la modifie pas, mais je crée des chaînes de templates dedans qui peuvent potentiellement appeler mon code pas-fini (ou même pas écrit) en retour.

C'est une bonne pratique en C++ et en python. Quand tu renomme une classe ce qui prend le plus de temps c'est de le faire partout où elle est utilisée.

Lorsque ta classe est déjà utilisée, oui, c'est ce qui est le plus long, mais généralement, je modifie plus souvent les noms des classes que je n'ai pas fini de l'écrire qu'autre chose, surtout quand je me rend compte au dernier moment que la classe que j'écris devrai être coupée en deux.

Quand à faire du une classe = un fichier en C++, non merci, mes classes sont bien trop petites pour ça. Et j'ai trop de mauvaises expériences avec de gros projets java de 10000 fichiers de 100 lignes qui sont impossibles à naviguer, même avec un IDE.

C'est des langages où il est plus compliqué de créer des IDE aussi poussé que ce que l'on trouve ailleurs. Le C++ a une syntaxe très compliquée (y compris pour écrire un compilateur), python a le typage dynamique et le C est très laxiste.
C'est l'un des points qui fait le succès de Java d'avoir permis la création d'outil autour du langage. C'est quelque chose de recherché et non pas un effet de bord (ça simplifie la compilation, l'analyse statique (pour détecter d'éventuelle erreur et failles), etc).

Peut-être, mais tout le monde ne code pas en Java, et Java n'est pas la solution à tout. Les autres langages sont peut-être moins parsables, mais ils ne sont pas inintéressants pour autant. Certains font des choses que Java ne pourra jamais faire.

On trouve pourtant des IDE pour le C++ (qdevelop) qui font pas mal de choses déjà).

Si tu regarde qdevelop, c'est plutôt un IDE pour ceux qui font du C++ avec Qt, c'est à dire avec un framework orienté objet avec presque pas de templates. Mais pour le reste, il est rapidement perdu.

Par contre je ne comprends toujours pas t'a vraiment voulu dire que le C++ fais du duck-typing ???

On peut faire du mal aux mouches pour définir ce qu'est le duck-typing, mais de mon point de vue, c'est tout comme. Tu définit des fonctions qui prennent n'importe quoi en paramètre sur lequel tu peux utiliser n'importe quelle opérations du moment qu'elle éxiste. Tu peux aussi tester si une opération est possible et faire autre chose si elle ne l'est pas. Si ce n'est pas du "si ça cancane, ça nage et que ça marche comme un canard, alors c'est un canard", alors je ne vois pas ce que c'est.

Tes fonctionnalités ne sont rendues possible que par la pauvreté du langage, parce que dès que tu à un peu de duck-typing, pouf, tout tes avantages disparaissent, et on ne dépasse même pas le stade de trouver un bon compléteur de code pour des langages qui ont du duck-typing comme Python et C++. Alors vérifier le type des arguments tu oublie (c'est plutôt vérifier l'usage des arguments qui compte), refactorer le code se fait mieux avec sed qu'avec n'importe quoi d'autre de soit-disant intelligent, Voir les usages des méthodes est soit incalculable, soit non-pertinent ou soit aussi pertinent qu'un grep. Quand à sauter aux définitions …

Alors ça, oui je le remplace par mon cerveau, mais je suis ouvert à toute proposition qui soit réaliste. Parce que oui, compléter du code en utilisant un interpréteur/compilateur, c'est bien joli, mais généralement le code ne compile ni s'interprète correctement quand je suis en train de l'écrire.

Avoir un IDE pour Java est juste obligatoire (tu ne pourrai pas supporter de devoir renommer le nom de la classe + renommer le fichier à la main), mais si beaucoup de personnes s'accommodent très bien de ne pas avoir d'IDE pour coder du C, C++ et Python, c'est peut-être qu'il y a une raison.

Moi aussi j'ai un vieux dell pour particulier avec ce problème, et je suis content de ne pas être le seul a l'entendre, parce mes proches n'entendaient rien…

Je pense que c'est plus un problème de ligne d'interruption, parce si je laisse backspace enfoncé, le bruit est maximal, alors que le cpu doit presque se tourner les pouces…

Sur ton proxy, essaye l'option ForceCommand ssh ServeurB "$SSH_ORIGINAL_COMMAND".
Je ne garanti rien, mais ça peut peut-être fonctionner dans des cas simples avec un peu d'adaptation. Il faudra peut-être déléguer ça à un script si jamais il y a besoin de faire des trucs de bourrin comme détecter si un tty à été alloué…

Après, ça force tout le monde à se connecter à ServeurB… il va falloir trouver un moyen pour savoir sur quel serveur on veut se connecter…

-keyboard-layout azerty

Avec ta configuration actuelle, non.

Par contre, pour plus de sécurité, j'attacherai les routes explicitement à ton interface :
post-up ip route add 192.168.3.0/24 via 192.168.2.1 dev eth1

Existe aussi en version dev $IFACE pour les guru d'ifupdown.

Ok, il n'y avais juste rien de tout ça dans la version stable …

Mais bon je maintiens ce que je dit : utiliser malloc() nu en C++, c'est tendre le baton pour se faire battre.

Ah ? ou ça ? Parce chez moi :

• le configure ne vérifie pas la présence d'un compilo C++, et les makefiles ne bidouilles pas les flags pour.
• egrep -R "typename|template|using|namespace|::|std|new|delete|_cast|virtual" ne retourne rien de concluant
• grep -R "include" ne retourne pas de header C++

Donc j'aimerai bien savoir comment il pourrai y avoir des templates dans ce code… à croire qu'on ne parle pas du même logiciel.

C'est le bon vieux problème de l'invalidation des pointeurs ou des itérateurs: Si tu à plusieurs pointeurs/itérateurs qui sont éparpillés partout qui pointent vers des éléments de ton espace mémoire, alors si tu déplace ton espace mémoire, ces anciens pointeurs/itérateurs deviennent invalides et il faut soit les mettre à jour soit arrêter de les utiliser.

C'est un problème qui arrive quelque soit le langage. La seule solution, c'est soit de laisser le programmeur bien choisir ses structures de données pour qu'il sache qui pointe vers quoi, soit que le langage l'impose à sa place…

Une alternative à D-Bus ? Pourquoi pas … aucune ?

Ça ne me gène pas que D-Bus soit utilisé sur la session de madame michu. Un processus qui plante tout le bureau quand il merde, il y en a suffisamment, alors un de plus ou un de moins …

Mais sur un système de boot, non, quoi. Déjà la libdbus est extrêmement chiante à intégrer dans un programme, surtout si tu n'a pas une mainloop des années 90. Et encore faut t'il en avoir un, de programme qui tourne.

Ensuite, ne faire qu'une API qui parle à travers des sockets, c'est franchement lourdingue. Une socket, ça à plein de cas d'erreurs différents qui sont chiants à gérer pour faire des choses simples : une socket peut se fermer en plein millieu à n'importe quel moment, peut rester sans réponse indéfiniment, ou peut recevoir de la merde.

À coté, quand je fait un service monservice reload, Je demande rien à personne. Le fork peut merder, l'exec aussi et j'ai peut-être un sigchld à ignorer, et hop c'est fini. Un système de boot pourra choisir de lancer le service directement à partir de /sbin/service ou alors pourra charger son D-Bus lourdingue et planter lamentablement avec fallback sur la première solution en cas de problème). Si j'ai envie d'une information supplémentaire sur l'opération, je peux regarder le code de retour. C'est vrai que c'est très limité, et c'est sans doute la première chose que je changerai si on me demandait de faire une API systemd-like.

Et voilà comment une API qui existe presque déjà est plus simple, plus fiable, plus portable et plus facilement implémentable (et donc remplaçable) que n'importe quel machin avec du D-Bus dedans: Si tu veux causer au système de boot, tu lance un programme avec des arguments spécifiés. Va trouver un système de boot qui ne puisse pas implémenter ça !

Si tu utilise malloc en C++, c'est normal de te faire battre, puisque tu à tendu le bâton.

Pour information, en C++, new te force à spécifier le type, et ne retourne jamais NULL (ça lance une exception à la place).

Et sinon, conky est compilé avec un compilo C … donc aucune raison de caster le malloc.

Si tu veux remplacer systemd par un autre démon qui à la même API D-Bus, et bien désolé, mais tu dépendra toujours de D-Bus, et ça sera toujours une putain de mauvaise idée. Alors oui, tu peut te recoder la libdbus (comme ça tu pourra là faire un peu moins viellotte tant qu'à faire), mais bon, systemd est bloat de base, on pourra pas faire moins pire en étant compatible.

(Hé! j'ai cru comprendre que tu voulais une alternative à systemd, alors je t'ai recodé son interface D-Bus dans un recodage de l'interface libdbus pour que tu puisse t'interfacer avec libdbus pendant que tu t'interface avec D-Bus!)

Enfin bref, question remplacabilité et modularité on à fait mieux.

Est ce que c'est vraiment une histoire de place dans le binaire ou le fait que ça soit plus facile pour un analyseur statique de détecter des mauvais chemins ou on utilise une variable sans qu'elle soit initialisée à une valeur qui à du sens ?

Je dirais même plus: Il n'y a pas que le driver evdev qui utilise les interfaces evdev: le driver synaptics (et wacom?) supporte lui aussi (entre autres) evdev, mais offre d'autres fonctionnalités plus pertinentes pour le type de périphérique.

Bon après, j'ai cru lire que ces deux là vont se mettre à utiliser un "future udev backend" … sans doute pour l'autodetection. Mais le xf86-input-synaptics que tu utilise actuellement utilise bien evdev sans avoir besoin d'udev.

autant de goto, de dizaine de return par fonction et de pointeurs non-initialisés à NULL, je me dis que systemd n'est pas prêt pour être en production.

Ça ne veut pas dire grand chose sur la qualité du code. Il faudrai plutôt mesurer le bloat, la factorisation, la gestion des erreurs et le nombre d'erreurs que sort un analyseur de code statique ou dynamique.

À vrai dire, sur un serveur à moitié embarqué j'aurais tendance à utiliser un système largement utilisé afin d'éviter au maximum des problèmes.

Ça tombe bien, j'utilise Debian.
Plus sérieusement, ça dépend de ce qu'on appelle "à moitié embarqué". Mais bien souvent, il y a au moins une des contraintes de l'embarqué à tenir compte. Moi dans mon cas, c'est un manque de RAM, mais j'ai quand même un disque dur pour swapper. Donc je vire tout ce qui prend de la RAM et qui ne swappe pas bien, du genre ifplugd qui passe son temps à poller alors qu'on peut faire sans si on daigne utiliser netlink, ou… D-Bus.

Si je résume, systemd c'est au final plus de fonctionnalités, moins de bugs, plus rapide. C'est quoi l'intérêt de garder un sysv à l'ancienne qui est lent et moins testé?

[Référence nécessaire]. Sérieux, d'ou tu sort que systemd est plus tésté que sysv ? Et je veux bien des tests sur la rapidité de systemd sur des petites machines. Quand aux nouvelles fonctionnalités, c'est bien pour celui qui les attend, mais c'est pas mon cas.