barmic a écrit 10455 commentaires

  • [^] # Re: Comment développe-t-on un nouveau gros logiciel ?

    Posté par  . En réponse à la dépêche Movim, sortie de la version 0.2. Évalué à 4.

    Je pense pas que PHP soit un frein, c'est pour pouvoir être utilisé sur une offre LAMP clef en main ce qui représente encore l'énorme majorité des offres grand publique.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: actualité récente

    Posté par  . En réponse à la dépêche Actualité Meego. Évalué à 1.

    Merci pour ta lumineuse intervention

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Vive MeeGo!

    Posté par  . En réponse à la dépêche Actualité Meego. Évalué à 4.

    Réinventer la roue ? Tu veut dire que réutiliser ce que Nokia et Intel ont développés depuis 5 ans c'est réinventer la roue ?

    L'interface moblin (qui est à la base de l'interface de Meego) a fait énormément parler d'elle est a était disponible pendant un temps au moins dans d'autres distributions (fedora notamment).

    Ce coté "mutter et Qt" viens justement de cette volonté de réutiliser ce qui a déjà était fait (au passage maintenant le développement est uniquement orienté Qt).

    Je ne sais pas où en était OpenEmbedded en 2006, mais je ne suis pas sûr que le contexte de l'époque aurait mené à son utilisation. Pour Debian, c'était la base de Maemo et Fedora était la base de Moblin, je présume qu'il y a eu de beaucoup de discussions pour choisir la quel des deux aller être utilisée.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Un netbook sous MeeGo

    Posté par  . En réponse à la dépêche Actualité Meego. Évalué à 3.

    ASUS c'est le vendeur qui dis que « c'est meilleur avec Windows » ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Numérotation

    Posté par  . En réponse au journal Linux 3.0 en approche. Évalué à 7.

    Je ne comprends pas très bien, pour moi :

    il a opté pour un passage en version 3.x (et les versions -stables seront donc en 3.x.x)

    ça signifie que la liste des versions stable seras :

    • 3.0.0
    • 3.1.1
    • 3.2.2
    • etc

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Du choix

    Posté par  . En réponse à la dépêche Cfengine : un outil de gestion de configuration libre. Évalué à 5.

    Les deux sites officiels :

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: De l'intérêt de ces paradigmes ?

    Posté par  . En réponse au journal Des paradigmes alternatifs. Évalué à 1.

    Tu pouvais simplement répondre que ça n'était pas la peine d'être si pointilleux et qu'on comprenait très bien ce que tu voulais dire, mais non, tu vas nous raconter que ta phrase ne souffrait d'aucune ambiguïté et qu'elle était correcte en nous la décortiquant. Sauf que ton explication ne change rien. C'est tout, le reste je m'en fiche.

    C'est toi qui à commencé l'orgie avec les mouches, je n'ai fais que continuer...

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: De l'intérêt de ces paradigmes ?

    Posté par  . En réponse au journal Des paradigmes alternatifs. Évalué à 2.

    Donc faire de l'objet en C…

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: De l'intérêt de ces paradigmes ?

    Posté par  . En réponse au journal Des paradigmes alternatifs. Évalué à 1.

    Et ?

    Tu remarqueras que pour ma part j'avais argumenté.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: De l'intérêt de ces paradigmes ?

    Posté par  . En réponse au journal Des paradigmes alternatifs. Évalué à 2.

    Vive la mauvaise foie, la prochaine fois il faudra écrire :

    Selon moi, mais ça n'engage que moi car il faut rappeler que je n'ai pas la science infuse, il se pourrait que, peut être, le langage C++ ne serait pas le pire des langages que j'ai testé pour faire des structures de données, enfin si mon opinion ne gêne personne, je rappelle que ça ne reste que mon humble avis donc lié à mes connaissances limitées et à ma minuscule expérience (parce que je le rappel je ne connais pas tout les langages, tout les paradigmes, toutes les bibliothèques, tout les interpréteurs, tout les compilateurs et tout les frameworks existants donc il se pourrait que je soit complètement à coté de la plaque). Je voudrait bien argumenter mais comme je ne suis pas certain qu'ils soient valide face à des langages que je ne connaîtrais pas.

    Comme ça peut peut être que je ne choquerais personne…

    Il y a vraiment que sur DLFP qu'on peut se faire reprocher de ne pas avoir précisé que l'on ne connais pas tout les langages.

    Pour parler plus sérieusement, ma phrase voulais dire d'une part que c'est mon opinion (donc évidement avec mes connaissances) et le coté affirmatif c'est parce que je ne vois pas d'inconvénients à celui-ci.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: De l'intérêt de ces paradigmes ?

    Posté par  . En réponse au journal Des paradigmes alternatifs. Évalué à 0.

    Si je veux dire que j'adore les croissants et que c'est ma viennoiserie préférée et que je la trouve formidable, je m'autorise à le dire malgré le fait que je ne les ai pas toutes goûtées (je ne les connais même pas toutes).

    Y a une grande différence entre dire j'adore les croissants et les croissants, c'est ce qu'il y a de mieux. Le premier annonce clairement la subjectivité, le second donne un fait... Mais bon, je chipote.

    Lis avant de répondre ça seras plus simple. Pour rappel voici ce que j'avais écris (tu peut le vérifier plus haut :

    Pour moi le meilleur langage pour faire des structures de données c'est le C++ :

    Alors oui j'ai pas mis en gras les deux premiers mots, mais il me semble que la subjectivité était assez claire, non ? En plus c'est en début de phrase, il y a même pas besoin de lire jusqu'au bout.

    Sinon, pour les Os cités, j'ai touché aux quatre... ;-)

    J'aurais put en citer d'autres : AIX, HPUX, ReactOS, Minix,… Je doute qu'il soit possible d'avoir touché à tout les OS, ni tout les langages (ça serait intéressant mais il y en a bien trop et il faut approfondir un minimum pour connaître).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: De l'intérêt de ces paradigmes ?

    Posté par  . En réponse au journal Des paradigmes alternatifs. Évalué à 1.

    j'ai juste ajouté que je trouve que le C++ est ce qu'il y a de mieux pour ça.

    C'est pas un peu gonflé de dire ça alors que tu connais pas tous les langages du monde notamment les Pascal et Algol-like ?

    Et puis quoi encore ? Si je veux dire que j'adore les croissants et que c'est ma viennoiserie préférée et que je la trouve formidable, je m'autorise à le dire malgré le fait que je ne les ai pas toutes goûtées (je ne les connais même pas toutes).

    C'est nouveau ça de ne plus pouvoir donner son avis par le simple fait que l'on est pas une connaissance de l'ensemble des possibilités. C'est comme si je disais qu'il était gonflé de dire que Linux c'est bien sans avoir touché à un BSD ni à QNX ou Haiku.

    Sinon les prés et post condition c'est des commentaires où c'est formellement vérifié à la compilation ou à l'exécution ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: De l'intérêt de ces paradigmes ?

    Posté par  . En réponse au journal Des paradigmes alternatifs. Évalué à 4.

    N'empêche que le gars qui explique que Boost n'est pas portable et qui de son coté fait du code avec des extension GNU de partout et ne passe que sur gcc et les compilateurs qui tentent d'implémenter les extensions GNU (comme icc), je trouve ça ridicule.

    L'unique abstraction dont il parle c'est la modélisation objet des programmes. C'est ce qui ne lui plaît pas. Il fait parti de ces programmeurs qui ont peur de perdre en performance parce qu'ils utilisent des objets. C'est plus ou moins du même niveau que croire que l'on perd en performance parce qu'on utilise trop de fonctions et qu'il vaut mieux coder de grosses fonctions pour qu'elles soient bien performantes.

    Pour ce qui est des mérites de Linus, on sait tous ce qu'il a fait et fait toujours. Mais il n'est pas le développeur ultime. Par exemple affirmer :

    Il a prouvé qu'il était capable d'enfoncer bien profond tous les gestionnaires de source avec git (et les choix qu'il a fait en sont la cause)

    Ça c'est juste un troll bien velux. Mercurial est un vrai concurrent. C'est ce voiler la face d'affirmer que git est le seul CVS bon qui existe et que tout le reste c'est de la merde. Par exemple Mercurial a fait un effort de modularité qui n'existe tout simplement pas dans git. Moi je vais essayer monotone d'ici peu, je ne le connaissais pas et c'est toujours intéressant de découvrir de nouvelles choses (j'utilise git actuellement).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: De l'intérêt de ces paradigmes ?

    Posté par  . En réponse au journal Des paradigmes alternatifs. Évalué à 2.

    Parce que tu as dis que quand on veut faire de la structure de données en python, il faut le faire en C.

    Je n'ai jamais dit « il faut ». J'ai juste constaté qu'en python comme en ruby et d'autres langages dès qu'il y a besoin de structures de données un peu efficace, on le fait en C.

    La manière de le présentais le sous-entendais.

    Peux-tu donc m'expliquer pourquoi 99% des algo dans la littérature scientifique sont en impératif (le reste en fonctionnel) ? C'est quand même triste d’utiliser un paradigme si dépassé.

    Tu avais prévenus, tu confond structure de données et algorithme. C'est pas grave. Mais tout de même dans la littérature, comme tu dis, on défini les structure de données par un ensemble de fonctions qui leur sont applicable et par le comportement de ces fonctions. Dans quasiment tout les cas ces présentés avec des notations mathématiques.

    assurer la consistance de ta structure (que les invariants qui sont liées à ta structure soient toujours valides)

    Je ne vois pas le rapport. Mais il n'y pas vraiment de grandes différences entre python ou ruby dans ce domaine. Rien ne t'empêche de corrompre la structure ou de mettre un None/nil/null.

    Si tu implémente une liste chaînée en C par exemple. Comment est ce que tu empêche que l'utilisateur prenne un élément de ta chaîne et modifie le pointeur vers l'élément suivant à la main ? Comment tu fais pour qu'il passe d'une implémentation à une autre d'une même structure sans avoir à modifié chaque déclaration + chaque endroit où il les passe en paramètre ?

    Puisque tu veux que je te donne des exemples précis pour python c'est grâce au __slot__. Quand Tu déclare tes classes ainsi :

    class Voiture(object):  
      __slots__=["marque","model"]
    

    L'accès aux attributs des objets se fait de manière statique (v.marquene fait alors plus appelle à un index) et il n'est donc plus possible d'ajouter dynamiquement des attributs dynamiquement.
    Pour le masquage de l'information, il faut utiliser la méthode property (mais c'est quelque chose qui semble moins t’intéresser).

    Pour ce qui est du model checking, c'est un peut comme si tu expliquait que pour être sûr qu'un programme est correcte il faut le prouver quelque soit le langage. Il y a des langages qui aident plus que d'autres. Il reste moins lourd d'utiliser les fonctionnalités du langage pour assurer la cohérence que d'utiliser des outils externes, lourd et à la charge de l'utilisateur.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: btrfs

    Posté par  . En réponse à la dépêche Sortie de Fedora  15 « Lovelock ». Évalué à 1.

    Oui c'est vrai qu'il est dommageable que les distributions ne soient pas restées à ext2 par défaut.

    Les développeurs du noyau disent qu'il deviendras le système de fichier privilégié au même titre qu'ext2 , 3 et 4 l'ont était. Il est normale qu'ils le proposent. On peut critiquer leur choix de le faire si tôt, mais c'est la politique de cette distribution (il vaut mieux en choisir une autre si ça ne plaît pas).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Du choix

    Posté par  . En réponse à la dépêche Cfengine : un outil de gestion de configuration libre. Évalué à 2.

    Il me semble que les administrateurs ont maintenant une quantité impressionnante d'outils à leur disposition pour gérer les configuration de leur parc de machine :

    • Cfengin
    • Puppet
    • MCollective
    • Fabric

    Et il doit y en avoir des tas d'autres.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: De l'intérêt de ces paradigmes ?

    Posté par  . En réponse au journal Des paradigmes alternatifs. Évalué à 2.

    Parce que tu as dis que quand on veut faire de la structure de données en python, il faut le faire en C. Je ne parle pas des « Ada, pascal, haskell, ocaml », parce que je ne les connais pas (bien qu'ocaml ayant un paradigme objet il a la même au minimum les même avantages que le C++ (sauf la gestion de la mémoire)).

    Parce que tu cite Linus qui démoli le C++ et fait tout en C.

    Mais si tu veut que je généralise tout ce que j'ai dis au sujet du s'applique tel quel à tout les langages impératifs (je ne m'exprime pas sur les langages fonctionnels).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: btrfs

    Posté par  . En réponse à la dépêche Sortie de Fedora  15 « Lovelock ». Évalué à 4.

    Ben c'est cool t'a pas besoin de btrfs, en quoi ça te gêne que d'autres puissent vouloir autre chose ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: De l'intérêt de ces paradigmes ?

    Posté par  . En réponse au journal Des paradigmes alternatifs. Évalué à 1.

    Tout faut

    C'est rare que je fasse la remarque mais celle-la est un peu dure.

    • L'objet inutile: présente qqcchose infaisable en Pascal non objet: je demande à voir !

    Je connais pas Pascal mais je ne connais d'autres mécanisme que l'objet pour masquer vraiment l'implémentation de ta structure à son utilisateur.

    • la gestion des pointeurs en 'C' est merdique (en C++ je sais pas!)

    Déçu de l'arithmétique des pointeurs ? :)

    • la gestion des pointeurs en Pascal est plus facile que 1+1=10 !

    Peut être

    • on a les records, qui permettent de faire des structures complexes.

    Ce sont des sortes de structures C en plus évoluées ?

    • on peut faire des arbres / listes ou autre avec les pointeurs

    Tu n'a sans doute pas compris ce que j'ai voulu dire (faut dire que je m'exprime pas super bien). J'ai juste dis que tout les langages qui ont la notion de pointeur ou de références sont capable de faire de la structure de données, j'ai juste ajouté que je trouve que le C++ est ce qu'il y a de mieux pour ça.

    • on peut faire 2 listes enlacées ( tu la connait celle-là???? )

    Non mais je présume qu'on peut la faire en C++

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: De l'intérêt de ces paradigmes ?

    Posté par  . En réponse au journal Des paradigmes alternatifs. Évalué à 0.

    Python, ruby (et d'autre) par contre imposent des abstractions qui se révèlent souvent être un désastre au niveau prédictabilité et même évaluation de la complexité. En python, par exemple, toutes les variables sont des références et sont liées via leur nom. Cela a pour conséquence directe qu'à l'insu de ton plein grè, il est possible qu'un anodin a.c soit en réalité un accès à une hash table (table des symboles). Par conséquent, un algo que tu crois en O(n) est tout à coup en O(n * t), t étant la complexité d'accès à la table de hash.

    Sous Linux tu te retrouve avec un mécanisme de pagination de mémoire qui fait que l'accès à la mémoire peut être beaucoup plus complexe que ce que ton algo le laisse penser (chargement d'une nouvelle page mémoire par exemple).

    Oui même en C tu as des mécanisme sous jacent. L'idée c'est qu'il faut les connaître et savoir s'en servir (c'est ce que l'on appel communément savoir programmer dans ce langage). En python (je connais pas ruby), tu as des mécanismes qui permettent de ne pas avoir les problèmes dont tu parle (notamment avec ce qu'ils appellent je crois les "nouveaux objets").

    Donc nous sommes d'accord un langage que l'on maîtrise pas ou mal est une plaie pour faire de la structure de données, mais c'est aussi une plaît pour tout le reste.

    Pour ce qui est du C, explique moi comment tu fait pour dans ta structure de donnée :

    • assurer la consistance de ta structure (que les invariants qui sont liées à ta structure soient toujours valides)
    • pouvoir contenir n'importe quel type de données sans passer par l'ignoble void* (parce qu'avec ça tu n'a plus aucune aide fournis par ton compilateur et c'est à l'utilisateur de se débrouiller pour savoir à tout moment ce qu'il traite et il se retrouveras à faire du transtypage de partout)

    paradigme objet : masquage de l'implémentation, polymorphisme, vrai découplage entre le code et la structure de données

    L'encapsulation me semble être exactement l'inverse de ce que tu dis.

    Je comprends pas ce que tu veux dire.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Parfeu

    Posté par  . En réponse à la dépêche Sortie de Fedora  15 « Lovelock ». Évalué à 6.

    Le fonctionnement du pare‐feu actuel requiert un redémarrage à chaque changement.

    Je ne comprends pas très bien. Actuellement il n'est pas nécessaire de redémarrer pour que les règles netfilter soient prises en compte. Il y a longtemps nous avions parlé ici même d'un remplaçant à netfilter parce que celui-ci devait recharger l'ensemble des règles à chaque fois que l'on en ajoutait une. On en a plus entendu parler depuis est ce de cela qu'il s' agit ? Est-ce que ça s'appuie toujours sur netfilter ? C'était iptables qui était en cause ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: De l'intérêt de ces paradigmes ?

    Posté par  . En réponse au journal Des paradigmes alternatifs. Évalué à -1.

    Tu connais beaucoup de langages qui n'ont pas la notion de référence ou de pointeur ?

    Dans la liste que tu cite, python et ruby en ont pour les deux autres je sais pas. La seule chose que tu perd c'est la gestion de la mémoire (devoir "nullifier" des références au lieux de simplement libérer).

    Je dirais même que le C est juste une abomination sans nom pour faire de la structure de données, simplement parce qu'il n'a pas de paradigme objet. Faire des structures structures de données sans polymorphisme (on peut aussi l'obtenir par duck typing) et sans masquage de l'implémentation, je trouve ça juste ridicule (c'est toi qui a commencé à troller sévère).

    Pour moi le meilleur langage pour faire des structures de données c'est le C++ :

    • paradigme objet : masquage de l'implémentation, polymorphisme, vrai découplage entre le code et la structure de données
    • gestion manuelle de la mémoire : quand on fait notre structure on sait quand libérer la mémoire
    • surcharge des opérateurs : ça permet de rendre agréable l'utilisation de nos structures de données pour les utilisateurs

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Intéressant

    Posté par  . En réponse au journal Des paradigmes alternatifs. Évalué à 4.

    Je connais pas les decorators pythons, c'est une implem du pattern eponyme?

    En quelque sorte sauf que ça s'applique à des méthode et pas à des objets et que ce n'est pas dynamique (c'est à la déclaration de la méthode que tu la décore).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Dépendances

    Posté par  . En réponse au journal Nouvelle machine, ubuntu live, debian.. Évalué à 3.

    C'est si complexe à comprendre ?

    Debian package gnome de la manière la plus respectueuse de la philosophie du projet possible, c'est à dire comme un tout, c'est le fameux GnomeOS. Si tu veut pas de l'un des éléments qui le constitue , tu n'a plus gnome et il te faut indiquer qu'est ce que tu veut garder. On t'a trouvé une méthode graphique (avec synaptic), une méthode semi graphique (avec aptitude en curse) et une en ligne de commande et toi tu viens me dire qu'on est obligé d'utiliser awk ? D'une part comme déjà dis tu as d'autre méthode, d'autre part juste pour le plaisir je peux te montrer une version avec sed et une avec perl.

    Si ça gène tellement rapporte un bug ou envoie un mail à l'une des liste de diffusion.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • [^] # Re: Intéressant

    Posté par  . En réponse au journal Des paradigmes alternatifs. Évalué à 3.

    Ce que tu dis c'est simplement qu'il faudrait pouvoir voir dans le code initial qu'un greffon a était placé (un peu comme python avec les décorations).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)