moi1392 a écrit 730 commentaires

  • [^] # Re: Cochon-chien

    Posté par  . En réponse au journal La revanche du cochon/chien. Évalué à 2.

    comme Richard Cochien ?

  • # Cochon-chien

    Posté par  . En réponse au journal La revanche du cochon/chien. Évalué à 4.

    En français, le "/" signifie le choix exclusif entre plusieurs alternatives.

    Dans le cas présent, si j'ai bien compris, il s'agit d'un animal qui serait à la fois un cochon et un chien, et pas soit un cochon, soit un chien, donc cochon-chien et pas cochon/chien.

  • [^] # Re: HS

    Posté par  . En réponse au journal yet another journal about systemd. Évalué à 8.

    Ça ne m'a pas fait peur ;) d'ailleurs je l'ai fait.

    Mais j'ai trouvé ça compliqué et lourdingue !
    De mon point de vu de développeur, c'est vraiment mal fichu !!
    Mettre du code (script bash) dans de la config (ce qui doit être démarré, où et comment), je trouve ça très pourri comme design.
    Après, peut-être que pour les adim de machine, c'est indispensable, mais j'aurais plutôt tendance à penser que c'est parce que le système d'init est très très incomplet, mal fichu et mal pensé, donc il délègue la complexité sur les fichier de config en les laissant gérer eux même la façon dont ils veulent faire les choses.

    En tous cas, quand je code, la config, c'est de la config, il n'y a aucune logique dedans. Ensuite, l'appli lit et interprète la config, c'est elle qui sait comment bien faire les choses ! Séparer la logique des données est un concept de base dans le design d'un logiciel chez moi, et à chaque fois que j'ai prototypé un truc à la va vite et que je ne l'ai pas fait correctement, j'ai du revenir dessus par la suite.

  • [^] # Re: Ben alors ?

    Posté par  . En réponse au journal Marre de systemd? Un peu d'humour :). Évalué à 8.

    McCann, c'est ceux qui en parlent le plus qui en codent le moins ???

  • [^] # Re: Trop d'honneurs...

    Posté par  . En réponse au journal yet another journal about systemd. Évalué à 3.

    Je la maintiens à jour, de la à me considérer comme un administrateur…

  • [^] # Re: HS

    Posté par  . En réponse au journal yet another journal about systemd. Évalué à 3.

    ça j'aurais pu le faire avec le démarrage de ma session.
    les 2 soucis que j'ai c'est que :

    1) je veux que ça tourne même quand je ne suis pas logué

    2) mon jouet lance certaines commandes depuis des requêtes sur le réseau, et pour lancer ces commandes il faut être root. (c'est pas sécurisé, plein de buffer overflow et autres joyeusetés…) donc à lancer en root.

    Donc je n'ai pas trouvé d'autres moyens que de la lancer avec un script de démarrage.

  • [^] # Re: La conclusion

    Posté par  . En réponse à la dépêche Le point sur udev et systemd. Évalué à 5.

    Mais si tu veux changer ton pot… tu vas chez le garagiste.

    Si je n'ai pas d'autre choix que d'aller chez mon garagiste pour changer mon pot de voiture, c'est qu'il y a un problème de conception de ma voiture.

    Par contre, je peux décider d'aller chez mon garagiste changer mon pot car c'est plus pratique, simple, je trouve préfère payer le prix que de m'embêter à le faire moi même, …

    Mais quand je transpose ça au problème systemd, ce que j'en pense c'est qu'il doit être possible de faire ce que l'on veut (c'est une des choses que j'aime le moins dans les logiciels et systèmes non libres), et que c'est mieux si c'est simple à faire, et c'est ce dernier point qu'il est important de discuter.

  • [^] # Re: Trop d'honneurs...

    Posté par  . En réponse au journal yet another journal about systemd. Évalué à 5.

    Donc j'oubliais, faire un case $1, et faire 3 lignes de commentaire à la bonne syntaxe (en s'inspirant d'un autre script par ex) , si tu trouves que c'est vraiment trop dur arrête l'admin système.

    Et bien quand je l'ai écrit, ça c'était pas le cas. Car oui, je me suis bien inspiré des autres scripts.

    Et je me considère toujours comme un utilisateur et pas un administrateur. Il se trouve que je suis aussi un développeur et j'ai j'ai codé un petit jouet que j'ai envie de démarrer sur ma machine.
    Ça n'est pas un service ultra perfectionné de luxe (même si dans le principe, ça reste un service qui attends des requêtes depuis mon réseau interne)
    Et je continue à trouver ça trop compliqué.
    Un simple "lance cet exécutable avant le prompt de login" est suffisant pour moi, et ça devrait être une des fonctionnalité simple à utiliser d'un système de démarrage.

    oui, 3 lignes de commentaires en plus.

    C'est vrai que je n'ai jamais pris le temps de voir ce qui lui manquait, donc quelque part, c'est de ma faute, mais j'ai mis ce point pour souligner que ça n'est pas "3 lignes de script" mais plus que ça ! Et aussi que ça n'est pas si trivial que ça, avec des parties non cohérentes (entête non interprété par le shell dans un script shell)

    Si tu étais utilisateur, tu n'aurais pas le droit de modifier ces scripts.

    Si j'avais pu faire démarrer mon utilitaire sans avoir à ajouter un script, je l'aurais fait avec plaisir. C'est le système qui me force à cela.
    Moi j'aurais aimé un outil avec une syntaxe du genre :

    "#>execute_ce_binaire_au_démarrage_de_la_machine --c_est_un_demon_alors_inutile_d_attendre_qu_il_termine --si_tu_peux_le_relancer_quand_il_plante_ça_m_arrangerait /chemin/vers/mon/binaire"

    Et il se serait chargé de créer la config qui va bien pour ça.

    avec des commandes qui me disent ce que est déjà dans la liste de lancement (pas tous les services, mais juste ceux que j'ai ajouté via cette commande), ceux qui tournent, me permettre de les arrêter, les relancer, de les virer.
    J'ai l'impression qu'il y a presque tout déjà, mais qu'il faut un enrobage énorme de shell autour et que le binaire en question ait quelques bons goûts dans sa façon de fonctionner pour que ça se passe comme on veut.

    Au fait, ma machine (principale) n'est pas pétée au bout de 6 mois ! je ne l'ai réinstallée qu'une seule fois récemment pour passer en arch amd64.

    parce qu'un script qui est distribué dans une distrib a certaines règles a respecter pour s'intégrer correctement (par exemple que tous les scripts aient les mêmes jolis "ok" vert, et pas l'un entre crochet à la fin de la ligne, l'autre après un saut de ligne, un autre sans ok vert etc…)

    La complexité pour ces choses ne devrait pas être dans les script, mais dans l'init.
    En tant que développeur, si je veux que tous les utilisateurs de ma lib se comportent bien, je ne leur laisse pas la possibilité de mal se comporter.
    C'est un peu comme les histoires de mutlitâche préemptif et coopératif, on est bien d'accord que le coopératif est une vaste fumisterie…

  • [^] # Re: Trop d'honneurs...

    Posté par  . En réponse au journal yet another journal about systemd. Évalué à -1.

    Tes infos datent un peu, aujourdh'hui on a les en-têtes de méta-infos LSB pour indiquer les dépendances et les niveaux d'exécutions où il doit être démarré et arrêté. Les liens sont créés par update-rc.d

    Ha oui, je viens de voir ça.
    Mais pourquoi des liens sont toujours crées si les niveaux d'exécution sont spécifiés dans l'entête ?

    Non. On ne relance pas tout.

    Alors si je ne dis pas de bêtises. Quand je suis en runlevel 2, si je fais init 3, j'appelle tous les scripts qui sont dans rc2.d avec le paramètre "stop" puis ceux de rc3.d avec le paramètre start.

    En sachant que si je fais ça, c'est que généralement, j'ai un ou deux services qui changent, donc 95% des services sont identiques.
    C'est pas super génial comme idée je trouve. Le mieux aurait été de n'arrêter que ceux qui sont dans 2 et pas dans 3 et de ne démarrer que ceux qui sont dans 3 et pas dans 2.
    C'est possible de faire ça ?

  • [^] # Re: Trop d'honneurs...

    Posté par  . En réponse au journal yet another journal about systemd. Évalué à 5.

    ah c'est compliqué un script qui fait un case sur $1 et qui gère "start" et "stop" ?

    Figure toi que j'en ai un qui fait "juste" ça.
    Et qu'à chaque mise à jour de init-je-sais-plus-quoi sur ma debian, j'ai des warnings m'indiquant que le script de démarrage n'est pas LSB compliant, que c'est mal (tm) et qu'à cause de ça, il ne peut pas passer à un système d'init basé sur des dépendances qui est trop bien.

    Donc même si c'est pas compliqué, ça reste pas suffisant pour avoir un truc propre dans ton démarrage.

    Ensuite, change l'administrateur… Ça aurait pu être là solution, s'il y en avait un. Moi, je suis utilisateur de ma machine.

    Dernier point, si c'est si simple et si facile, pourquoi les scripts de démarrage sur ma machine font-ils tous en moyenne 100 lignes (ça va de 33 à 408 !!) Et en plus avec des paramètres dans des fichiers extérieurs (ce que je comprends très bien, mais ça fait des lignes en plus et c'est pas toujours évident à trouver)

  • [^] # Re: Trop d'honneurs...

    Posté par  . En réponse au journal yet another journal about systemd. Évalué à 9.

    On te répondra certainement que c'est parce que le système actuel est parfait

    Perso, je l'ai toujours trouvé ultra pourri le système d'init actuel…

    Il a quoi de si génial ?
    Pourquoi, si je veux juste démarrer un truc avec ma machine, il faut que je fasse un scripte qui gère 5 (ou 6 ?) paramètres différents (start, stop, restart, …) et en faire des liens complètement abscons dans d'autres dossiers avec comme seul ordre pour déterminer à quel moment il sera exécuté….. l'ordre alphabétique du système de fichier ??????

    Ensuite, c'est quoi ces histoires de runlevel à la con ??? géré par des chiffres qui n'ont aucun sens ? (différents entre les distrib au passage) et limité à 9 en plus (d'ailleurs c'est vraiment limité à 9 ou c'est juste mon impression ?) ???
    Et pour le passage de l'un a l'autre, on coupe tout et on relance tout ?? ça serait pas possible de juste gérer le delta ??

    Et un point marquant que je lui trouve, c'est qu'il y a des différence notables entre chaque distributions sur comment il fonctionne. C'est bien qu'il y avait des problèmes à la base, et que chaqun ait ses propres solutions, c'est bien que la solution n'est pas simple.

    Et j'effleure juste la surface en tant qu'utilisateur de ma machine là.

    Je sais pas si systemd est bien ou pas, mais l'init actuel, pour moi, il est juste vraiment moisi…

  • [^] # Re: x86 32bits [:aloy]

    Posté par  . En réponse au journal Pierre Tramo 2.0. Évalué à 3.

    Merci :)

  • [^] # Re: x86 32bits [:aloy]

    Posté par  . En réponse au journal Pierre Tramo 2.0. Évalué à 1. Dernière modification le 24 août 2012 à 15:37.

    oui, x86-32 serait plus correcte.

    Et dans l'exitation du message, j'ai même oublié de parler de la référence à windows 9, et j'ai laissé une coquille…
    à un fils -> a un fils caché (a sans accent)

  • [^] # Re: Très hors sujet, mais il faut que je me confie

    Posté par  . En réponse au journal Comme quoi, il faut penser à tout.. Évalué à 3.

    Puisqu'on parle de téléphone, moi sur mon téléphone précédent j'ai aussi une "fonctionnalité" d'ingénieur qui n'a sûrement jamais utilisé son téléphone.
    Le système permet d'enlever le jingle d'allumage, mais pas celui d'arrêt.

    Super pratique quand t'es en meeting, que t'as oublié de la sortir de ta poche et que tu veux le couper discrètement… Alors que généralement, quand tu l'allumes, c'est que tu acceptes d'être dérangé, donc ça devrait être moins gênant de ne pas pouvoir enlever celui là.

  • [^] # Re: bon anniversaire

    Posté par  . En réponse à la dépêche 19 ans : Bon anniversaire Debian !. Évalué à 1.

    sarge en testing pour moi, c'était en 2003 si ma mémoire est bonne.

    Depuis, je ne l'ai réinstallé qu'une seule fois (sur ma machine fixe perso), pour mon passage de x86 à amd64

    Au passage, c'est à cause de la fin de la version d'essais d'un logiciel propriétaire sous windows que j'ai complètement basculé :)
    Le parefeu que j'utilisais ne faisait plus partage de connexion internet au bout de trois mois, et la freebox v1 que j'avais, ne le faisait pas non plus.
    Qui a dit que c'était pourri les shareware :D

  • # ça marche !

    Posté par  . En réponse au journal Et Dieu inventa le soutien gorge !. Évalué à 10.

    Ça me parait un peu compliqué, mais ça marche !
    Moi, je me serait contenté d'une liste chainée simple de pointeur de fonctions dans le genre :

    struct layer {
        void (*next_func)(struct layer*, ...);
        struct layer* next_layer;
    };
    
    

    et derrière, tes fonctions deviennent :

    void l1(struct layer* lay, ...) {
        ...
        lay->next_func(lay->next_layer, ...);
    }
    
    

    Tu peux facilement ajouter un truc au milieu de ta couche en ajoutant une fonction au milieu de liste layer.

    Et sinon, juste pour le fun :

    struct x {
        int a;
        int b;
    };
    
    struct x X;
    
    

    Et admettons :

    X est à l'adresse 0x14C4
    X.a est à l'adresse 0x14C8
    X.b est à l'adresse 0x14CC
    
    

    chez moi, l'adresse de X.a est la même que X ;)

  • [^] # Re: "connoisseurs"

    Posté par  . En réponse au journal GCC++ (gcc in cxx). Évalué à 1.

    J'ai appris cette semaine que Debian était entrain (tout doucement seul experimental le fait pour le moment) de remplacer libstdc++ par libc++

    j'ai vu passer aussi la news, je me suis mis un marque page dessus, mais je n'ai pas encore eu le temps d'aller voir ça tranquilement (Et à priori, c'est pas pour ce week end non plus…)

    D'ailleurs j'ai été assez surpris, et je suis curieux de savoir quel est l'objectif de ce remplacement.
    Dans tous les cas, si c'est une lib c++ standard qu'ils veulent, cela va être compliqué de faire sensiblement moins gros, à part peut-être en la splittant en plusieurs biliothèques un peu à la boost ?
    Ça pourrait être une idée intéressante pour les projects c++ embarqués qui veulent le minimum de dépendances.

    Si j'arrive quand même à trouver le temps d'y jeter un œil ce week end, je posterai sur ce fil de discussion ce que j'en ai compris.

  • # "connoisseurs"

    Posté par  . En réponse au journal GCC++ (gcc in cxx). Évalué à 10.

    Dans le contexte, j'aurais plutôt dit les "coinnaisseurs".

    Sinon pour ce qui est du portage vers c++, il y a des bons et des mauvais argument contre que je vois beaucoup.

    Pour les bons, je dirais l'emprunte mémoire de la libstdc++ qui est plutôt gênante pour les systèmes embarqués. En même temps je pense que la cross-compilation marche pas trop mal et que cet argument est plus valable pour gdb que pour gcc.
    Le second est l'abi c++ qui n'est pas terrible et qui a du changer à plusieurs reprises.
    Mais on peut raisonnablement supposer qu'un compilateur c++ soit livré avec le runtime c++ qui va bien.

    Ensuite, pour les mauvais arguments, j'ai toujours du mal avec les critiques sur c++.
    Oui oui, on peut faire des tas de choses horribles avec, mais il est quand même fourni avec une librairie standard pas trop mal, surtout si on prends boost avec (pas standard ok, mais vraiment pratique pour pas mal de choses)
    Et puis je suis désolé, mais travailler avec des structures de données et des concepts définis dans un langage, ça reste toujours mieux que de refaire sois même (dans le même langage, à peu de choses près) une implémentation objet (des tableaux de pointeurs de fonctions, héritage par inclusion ou copie, beurk), des conteneurs pour chaque type (pas de généricité du code, beurk)

    À un moment il faut arrêter les conneries, en 1995, les compilos et librairies standard n'étaient peut-être pas au point, mais ça n'est plus le cas depuis bien longtemps.
    D'autant plus que l'effort pour passer de C avec une implémentation moisie d'un concept objet (d'un point de vue utilisabilité et maintenabilité du code) à du c++, c'est pas la mort.

    PS: c'est mon premier flamewar c/c++ et c'est moi qui le lance en plus, c'est pas beau la vie le vendredi ?

  • [^] # Re: Pourquoi?

    Posté par  . En réponse au journal Asile équatorien accordé à Julian Assange. Évalué à 2.

    je me réponds à moi même, je viens juste de lire cet article du monde : http://www.lemonde.fr/technologies/article/2012/08/16/la-grande-bretagne-determinee-a-extrader-julian-assange_1746459_651865.html

    Où il y a ce détail intéressant : "la Suède et la Grande-Bretagne ne peuvent pas, en raison des lois locales et européennes, extrader un individu "vers un pays où le prévenu risque la peine de mort"."

    C'est vrai que c'est une loi européene, et je ne sais pas s'il est possible de tricher avec une astuce du genre "garanti qu'il n'y aura pas de peine de mort appliquée, donc vous pouvez l'extrader"

    Ou alors on peut imaginer que la personne étant australienne, la suède ne veut plus d'elle sur son territoire, donc elle l'extrade dans son pays d'origine, où il ne risquer pas la peine de mort, puis de là, plus de soucis pour l'envoyer aux états unis.

  • [^] # Re: Pourquoi?

    Posté par  . En réponse au journal Asile équatorien accordé à Julian Assange. Évalué à 6.

    Pourquoi? Quel motif? Pourquoi la Suède et pas la GB?

    Sur ce point, mes sources sont assez faibles. De ce que j'en ai lu, les accords d'extradition sont plus facile depuis la suède que depuis l'angleterre.
    Maintenant, l'effort extraordiaire qui a été mis en place pour cette affaire laisse quand même peu de doute sur le fait qu'il ne s'agit pas que d'une affaire de viol.
    C'est un peu comme si on faisait faire des test ADN pour un vol de scouter, personne ne ferait ça…

    Non, je ne comprend pas pourquoi on dit qu'il sera extradé si il se retrouve en Suède. Pourquoi la Suède spécialement? et si c'était la France?

    Il n'est accusé d'aucun crime en france, donc pas possible de demander son extradition vers la france pour pouvoir l'extrader ailleurs ensuite.

    Bizarrement, aucun journaliste ne l'explique, j'attends des journalistes qu'ils expliquent,

    Je n'ai pas fait de recherche approfondies sur le sujet, donc ce que je dit reste des suppositions basées sur ce que j'ai pu lire et mes suspicions entretenues par le caractère plutôt exceptionnel de l'affaire.
    Je pense que tu peux quand même admettre qu'annoncer aller chercher une personne dans une ambassade pour l'extrader parce qu'il à fait des galipettes sans capote, c'est plutôt surprenant ! Et ça laisse quand même planer un doute sur la légitimité réelle de l'affaire.

  • [^] # Re: Pourquoi?

    Posté par  . En réponse au journal Asile équatorien accordé à Julian Assange. Évalué à 10.

    ce qui est sous entendu, c'est que le procès en suède n'est qu'une excuse et que peu importe le résultat, il sera extradé vers les étas unis.

    Perso, je suis assez surpris de l'effort mis en place pour cette histoire, même si dans le cas où j'aurais été une jeune demoiselle violée, j'aurais certainement grandement apprécié la procédure, je doute TRÈS fortement qu'elle aurait été mise en place dans un autre contexte.

    Le second point est qu'au états unis, il n'aura pas de procès équitable du tout (voir pas de procès du tout…), et pour ce point, il y a pas mal de signes (voir d'exemples) qui tendent à le confirmer, à commencer par le sort du soldat qui est accusé d'avoir fourni ces informations.

    Tu comprends mieux ou tu as besoin de plus d'éclaircissements ?

  • [^] # Re: OpenGL ES

    Posté par  . En réponse à la dépêche Quoi de neuf du côté d'OpenGL et Linux ?. Évalué à 9.

    Le problème d'OpenGL est que les très vielles fonctions sont toujours supportées, ça fait beaucoup de code dans les pilotes, car plus rien de tout ça n'est cablé directement dans les puces graphiques, et du coup ça augmente de beaucoup l'emprunte mémoire de la libGL (de plusieurs Mo, y'a qu'à voir la libGL de nvidia ou amd), pour de l'embarqué, c'est complètement redhibitoire.

    En plus, y'a régulièrement des bugs et des soucis de performances liés aux anciennes fonctionnalités (je m'en tape de temps en temps au boulot)

    À vérifier tout de même, mais il me semble que du code OpenGL ES est 100% compatible OpenGL, sauf la partie connexion avec le système de fenêtres.
    Dans le cas de X11, c'est glX qui fait ça. Pour OpenGL ES, c'est EGL, et c'est sensé être une couche d'abstraction unique pour toutes les plateformes.

    Pour faire la même chose avec OpenGL, il y a OpenGL 3 core (à partir d'OGL 3.1) qui déprécie toutes les vielles fonctionnalités des entêtes avec le défine qui va bien.

    Donc le mieux je dirais c'est soit de coder en OpenGL ES si on vise aussi l'embarqué, soit en OGL3 Core si on est exclusif au desktop.

  • [^] # Re: OpenGL ES

    Posté par  . En réponse à la dépêche Quoi de neuf du côté d'OpenGL et Linux ?. Évalué à 10.

    Castré n'est pas vraiment le mot, OpenGL ES est sensé contenir une unique version des fonctionnalités de base pour avoir un rendu 3D, en gros les plus performantes et les plus proches de la carte graphique.

    L'intérêt pour l'embarqué et qu'on supprime énormément de code utilisé pour maintenir la compatibilité avec les fonctionnalités "habituelles" d'OpenGL (en gros, OpenGL < 3)

    Donc ça fait moins de code, mois d'espace disque et d'espace mémoire utilisé, et en bonus, on force les utilisateurs à utiliser une API plus proche du matériel qui, à priori, est plus performante.

    En simplifiant, OpenGL = OpenGL ES + fonctionnalités supplémentaires dépréciées (fixed pipe, direct mode, display lists, …) + des fonctions utilitaires en plus.

  • [^] # Re: Morale de l'histoire

    Posté par  . En réponse au journal Hack : Un journaliste de Wired se fait piquer sa vie en ligne.. Évalué à 2.

    Ou alors tu utilises ton cerveau, c'est bien aussi.
    J'ai plusieurs adresses de courriel chez google, aucune adresse de récupération ni numéro de téléphone.
    Si j'oublie mon mot de passe, c'est fichu.

  • [^] # Re: Souvenir souvenir ...

    Posté par  . En réponse à la dépêche SCO : Game Over. Évalué à 6.

    tu veux dire : sed s/logiteque/logitheque/g

    (éléphants, frigo, toussa…)