Batchyx a écrit 1261 commentaires

Ah c'est modulaire ? Comment on enlève D-Bus de ce machin ? Et comment on enlève sa gestion des cgroups si j'ai pas envie d'activer cette option dans mon noyau ?

Quand on compare ça à un inittab ou on peut remplacer /etc/init.d/rc par ce que je veux, y compris par un machin utilisé par trois pélerin, ou un machin custom qui utilise des cgroups, c'est plutôt systemd le binaire monolithique.

Ah, on peut ne pas utiliser le machin systemd qui monte les partoches ? Ah on pouvait pas le faire avant avec sysvinit ? C'est bizarre ça, je me souviens l'avoir fait pourtant…

Pareil sur l'argument sur les dépendances: d'une part il y a les entêtes LSB (et insserv, qui est tout sauf un hack), et l'argument sur les changements à maintenir est aussi valable pour un systemd custom.

Ou plutôt dans la mauvaise. Si ces scripts étaient spécifiques, c'est qu'il y avait peut-être une raison. Raison qui n'est peut-être valable que dans certains cas, mais c'est largement suffisent.

Moi je n'ai pas envie d'installer D-Bus sur un serveur à moitié embarqué juste pour pouvoir admirer la rapidité du boot.

Systemd est dans Debian, et alors ?
Upstart aussi l'est, tout comme file-rc (encore un truc zarbe utilisé par trois pélerins…)

Tu viens juste de prouver que Debian est une distribution qui laisse le choix du système d'init à utiliser. Ça tombe bien, c'est pour ça que je l'aime.

Ah, et tu fait ça comment ?

Tu compte le nombre de réseau au alentours, et tu considère que 5 réseau inutilisés est pire qu'un réseau qui bourrine toujours à fond ? Tu fait une mesure de la qualité du signal (Indice: il va souvent te dire que le canal 3,4,8,9 sont peu utilisés … si tout le monde bourrine sur le 1,6,11) et tu espère qu'elle sera éternelle ? Tu passe ton temps à changer de canal en perdant la plupart de tes clients qui ne supportent pas ça ? Il n'y a pas de méthode miracle, juste des méthodes qui ne marchent que souvent.

Oui, la réalité, c'est dur. Planifier le déploiement d'un réseau Wi-Fi, c'est presque un métier.

Ou sinon, comme solution générique à tout les problèmes Wi-Fi sous linux …

• Essayez sans network-manager
  • Si ça marche sans, alors priez pour que ça marche avec la prochaine version
  • Si vous adorez être ignorés, alors rapportez un bug.
• Si ça marche toujours pas sans network-manager, lancez wpasupplicant avec le verbose à fond.
  • Si il y a des grosses erreurs dans les logs, éplucher sa mailing list.
  • Si le problème est nouveau, envoyer le log.
• S'il n'y a rien dans les logs, installer le dernier compat-wireless.
  • Si le problème n'est pas résolu, éplucher la mailling-list linux-wireless.
  • Si le problème semble nouveau, envoyer un mail.
  • Si tu sais programmer, alors programme.
  • Si tu sais pas programmer, alors ne programme pas.
  • Si c'est une régression, alors bissecte ton noyau.
• Si ça marche toujours pas, branche un câble.

Sauf que dans ce cas là, c'est une vraie erreur de type.

Tu à un objet de type StrongId<DistanceDiscriminant, int> à comparer avec un StrongId<TempsDiscriminant, int>, or la substitution donne
bool StrongId<DistanceDiscriminant, int>::operator==(const StrongId<DistanceDiscriminant, int> & other) (ça manquerai d'un const d'ailleurs)

Tu à donc une méthode qui prend un const StrongId<DistanceDiscriminant, int> & auquel tu essaye de faire passer un StrongId<TempsDiscriminant, int>& et le compilateur ne trouve pas de conversion implicite possible. Ce n'est pas différent de faire passer un int pour un std::string.

Ça aurai pu être une erreur d'instanciation si c'était défini comme étant

template <typename TYPE2>
bool operator==(const StrongId<DISCRIMINANT, TYPE2> & other)
{
  return _type == other._type;
}

et que tu voulais comparer un StrongId<DistanceDiscriminant, int> et un StrongId<DistanceDiscriminant, std::string> (même si ça n'a aucun sens).

Et si tu à 10 types de String différent, tu t'implémente 10 classes ? Parce que là on parle justement de pouvoir faire ça sans devoir écrire trop de code.

Ou bien le langage le supporte facilement, ou bien il faut pouvoir faire de la méta-programmation. Et j'aimerai bien voir comment s'en sort la méta-programmation de Java, donc certains se targuent qu'elle est supérieure à C++…

Et il manque aussi la couche de routage qu'il faut mettre au dessus.

C'est sûr, demander une nouvelle fonctionnalité dans Gnome …
 
 
 
(Si vous êtes un mainteneur Gnome, répondez à mes patches avant de moinsser)

Je ne compare pas son code avec du chained-policy, je dit juste que, vu qu'il est dans l'embarqué, faire des choses au runtime est bête lorsqu'on peut faire la même chose à la compilation, surtout si ça élimine du code. Le policy-based design en C++ est juste un exemple de comment faire ça avec un langage moderne.

L'équivalent en orienté objet ne serait pas vraiment Adapter (on adapte rien, c'est la même interface partout), mais plutôt une chaîne de pattern Strategy.

Mais on voit moins bien les liens entre les classes (c'est surtout pour ça que j'aime avoir un diagramme des classes), ce qui est toujours utile même en cours de développement.

Ça peut se générer à partir du code source, tout les bons outils de documentations te génèrent des diagrammes de classes.

Tu décris un détournement du diagramme de séquence qui ne se fait normalement qu'entre des objets.

J'ai du mal à voir en quoi c'est un détournement, surtout quand on considère qu'UML définit des messages asynchrones, des messages avec accusé de réception de durée limitée ou pouvant être mis dans une file d'attente … le genre de chose qu'on fait pas simplement entre des objets.

Et puis bon, il suffit juste de remplacer l'hôte par l'objet qui tourne sur l'hôte et on en parle plus.

C'est bête de faire ça au runtime, alors que tu pourrai donner à ton compilateur toutes les informations nécessaire sur ta pile de couche pour qu'il te merge tout ça et te l'optimise au petit oignons, plutôt que de devoir parcourir une liste chaînée qui contient toujours les même valeurs.

Parce que, ce que tu nous décris ressemble fortement à ce que l'on fait en C++ avec du Policy-based_design :

#include <cstdio>

template <class LowerLayer>
struct l1 : LowerLayer {
        unsigned char val1 = 'a';
        unsigned char val2 = 'b';
        unsigned char val3 = 'c';
        unsigned char state = 0x00;
        unsigned char send(unsigned char* lower_state_jcomprend_pas_trop) {
                unsigned char tmp = 0x00;
                unsigned char lower_state;
                // ... plein de code ...
                switch (state) {
                case 2:
                        // ici je considère que LowerLayer existe forcement,
                        // si ce n'est pas le cas, on pourrai passer une
                        // classe vide du genre NoLowerLayer avec des methodes
                        // vides qui seront éliminée par le compilo, on
                        // pourrai aussi tester avec
                        // if (std::is_same<LowerLayer,NoLowerLayer>::value)
                        // pour savoir s'il y a un niveau en dessous, ou faire
                        // du super SFINAE de ouf. mais bon, KISS.

                        tmp = this->LowerLayer::send(&lower_state);
                        if (lower_state == 0xFF)
                                state++;
                        *lower_state_jcomprend_pas_trop = state;
                        return tmp;
                }
                // ... encore plein de code ...

        }
};

// J'imagine que l2 ne peut être qu'utilisée en couche la plus basse.
// Sinon il faudra juste une autre classe 'terminale' du genre NoLowerLayer.
struct l2 {
        unsigned char val1 = 'Z';
        unsigned char val2 = 'F';
        unsigned char state = 0x00;
        unsigned char send(unsigned char* lower) {
                //...
        }

};

// Une couche intermédiaire, parce que je suis pas trop flemmard.
template <class LowerLayer>
struct l1_5 : LowerLayer {
        unsigned char send(unsigned char* lower) {
                unsigned char lower_state;
                *lower = 0x00;
                puts("coucou maman");
                return this->LowerLayer::send(&lower_state);
        }
};

template <class LayerStack>
char send(LayerStack& stack) {
        unsigned char res = 0x00;
        stack.send(&res);
        if (res == 0xFF)
                return 0;
        return 1;
}

int main() {
        // définition de mes couches : l1 puis l1,5 puis l2
        // et instanciation.
        l1<l1_5<l2>> ma_pile;

        while (send(ma_pile));
        return 0;
}

Ce que je reproche au diagramme de séquence (sauf cas particulier) , c'est qu'il est soit trop général et donc peu utile soit trop détaillé et il faudra diverger pendant l'implémentation ou il est bien fait et on aurait pu coder pendant ce temps et le programme serait déjà fini.

Ça c'est un reproche que l'on peut faire à UML en général, ce n'est pas spécifique à un diagramme particulier. Surtout pour le diagramme de classe : on pourrai l'écrire en code avec des classes presque vides que l'on serait aussi rapide (sauf en Java, mais bien fait pour sa gueule).

Alors qu'un diagramme de séquence pour représenter des messages qui circulent sur un réseau entre des hôtes, cela va prendre bien plus de temps à implémenter qu'a dessiner des diagrammes détaillés complets, et ça va aider à déterminer à définir quels type de messages doivent être utilisés.

Au contraire, moi je trouve qu'un diagramme de séquence est bien plus utile qu'un diagramme de classe, puisque sur un diagramme de séquence, on ne préjuge pas forcement la manière dont les messages/événements sont échangés, ni quelle est la nature des acteurs. Ça peut être des classes, des nœuds sur un réseau, des services sur une même machine … donc on peut représenter plein de choses avec.

Alors qu'un diagramme de classe présuppose que l'on utilise principalement de l'orienté objet, du coup si tu en fait pas ou que ça y ressemble de loin (du genre C avec vtable à la main, policy based design ou collection de petit composants), cela fait un diagramme de classe peu-compréhensible ou peu représentatif… du coup l'utilité d'un diagramme de classe est plus restreinte.

Il y a certes d'autres diagrammes plus adaptés, mais ils sont beaucoup moins connus, et donc moins compris.

Pourquoi veut tu absolument mettre le PNG dans le commit ? Si c'est un fichier facile à générer, il ne devrai pas être dans le dépot, il faudrait juste filer le script à mettre dans le post-checkout pour régénérer l'image…

Au pire, tu pourrai versionner son hash et git-annexer l'image au dépot, mais c'est beaucoup de complexité pour pas grand chose. Et ça ne résout pas le problème de changer un commit coté serveur.

De plus, rajouter des commit coté serveur après un receive, c'est assez dangereux, puisqu'il faudra obliger les utilisateurs qui pushent à faire un pull juste après s'il veulent pas se retrouver avec des grosses divergences. Et il ne faudrait pas que des utilisateurs tentent de corriger ce que fait le pre-receive avec des commits à eux, parce que ça pourrai foutre un bordel monstre dans l'historique.

C'est un jeu, c'est ça ?

Pourquoi le procès ne serait pas équitable?

Parce la suède accepterai de l'extrader vers les états-unis ?

La suède est un état corrompu?

Oui, par les états unis ?

Pourquoi il serait extradé?

Parce que la suède est un état corrompu ?

Bizarre, je pensais plutôt que, quand tu monte, tu devais faire un choix entre :

• La porte.
• Le Bangladesh
• La Chine
• Le poste chiant.

et que lorsqu'on dit qu'un expert est irremplaçable, ça veut dire que la boite va se faire racheter par des financiers qui vont revendre la technologie au concurrent, en lourdant tout le monde au passage.

À coté de ça, moi je préfèrerait être le président de la république: Ça paye pas, mais pas mal de français rêverait de pouvoir rester en poste pendant 5 ans, peu importe tes résultats ou ta loyauté envers ton employeur.

-->[]

Pourquoi faudrai t'il que celui qui gagne le plus soit forcement le supérieur hierarchique ?

Non, cette solution est trop bloat dans ce cas la; Ce n'est pas le même problème, ici on cherche juste à trouver un service d'un type particulier.

Il n'y a qu'a simplement utiliser les enregistrements SRV pour ça, pas besoin d'indirection avec des PTR.

D'ailleurs, ça tombe bien, il y a même une RFC6186 pour le mail et plein de drafts qui seront certainement jamais publiés pour le reste.

Dans la vie, il y a deux types de personnes : ceux qui envoient des mails, et ceux qui y répondent.

Et la deuxième catégorie n'a absolument pas besoin d'un carnet d'adresse, juste d'un bouton "répondre".

Toi tu les utilise peut-être ensemble, moi pas.

Le principe UNIX s'applique donc.

Ce n'est pas toujours possible, et ça n'a pas plus de sens que "float:left", pour une interface graphique.

Attend, tu est en train de dire que tu va réimplémenter l'interprétation de CSS ?!?

Tu trouve pas qu'il y a suffisamment d'interpréteur de layout CSS ?

CSS va imposer de supporter des fonctionnalités comme des dégradés orientés et tout un framework d'animation ainsi que bien d'autres fonctionnalités plus ou moins utiles pour mettre en forme une interface.

En anglais, on appelle ça du bloat.

J'avais essayé uzbl/surf/l'exemple pywebkit et ça swappait aussi mal que Firefox.