Miod in the middle a écrit 400 commentaires

  • [^] # Re: adéquation

    Posté par  . En réponse au journal François Hollande visite 42, non mais allô quoi.... Évalué à 4.

    ``finite state machine'' se traduit en français par «automate» ou «automate à états finis». Merci de ne pas utiliser les affreux «machine à états» ou, pire, «machine d'états».

  • [^] # Re: Autre meurs...

    Posté par  . En réponse au journal Et la politesse bordel !!!. Évalué à 8.

    C'est pourtant simple ! Avant le souper, c'est le jour, et après le souper, c'est le soir.

    Et pendant le souper, me demanderez-vous ? Cela n'a pas d'importance, car on ne parle pas la bouche pleine.

  • [^] # Re: Kheops linux

    Posté par  . En réponse au sondage En quelle année êtes-vous passé(e) à GNU/Linux (ou autre système libre) ?. Évalué à 10.

    Ça va faire très plaisir à Joël Bernier que tu amalgames les Logiciels du Soleil et SCO. Tu es sûr que ce n'est pas une Caldera OpenLinux que tu avais installée ?

  • [^] # Re: Le meilleur processeur de tous les temps…

    Posté par  . En réponse au sondage Mon processeur préféré ?. Évalué à 6.

    Ne te plains pas, l'auteur du sondage m'a imposé mon vote !

  • [^] # Re: Pas sûr qu'elle tienne devant un tribunal

    Posté par  . En réponse au journal Licence open source "Don't Be a Jerk". Évalué à 4.

    Malheureusement, cette licence ne donne nulle part le droit de modifier le logiciel, ni de le distribuer.

  • [^] # Re: Sournoiserie

    Posté par  . En réponse à la dépêche Bitrig, un récent fork d'OpenBSD. Évalué à 2.

    La société dont il est question est basée aux USA.

  • [^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..

    Posté par  . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 4.

    la libgcc de gcc doit faire quelques lignes d'assembleur pour initialiser la pile et sauter à main().

    Oh non, ce que tu décris c'est crt0 ; dans libgcc il y a beaucoup plus de code, quelques dizaines de routines pour fournir les primitives gcc qui ne sont pas nécessairement existantes en tant qu'instructions (ou courtes séquences d'instruction) du processeur cible : ffs(), multiplication et division 64 bits, conversion de float en double et vice-versa, etc.

    C'est dans le fichier libgcc2.c qui fait plusieurs milliers de lignes, tout de même.

  • [^] # Re: Deux poids, deux mesures

    Posté par  . En réponse au journal Notepad++ est Charlie. Évalué à 1.

    Quoi, tu n'as jamais visité http://www.azf-10h18.com/ ?

  • [^] # Re: Non merci

    Posté par  . En réponse au journal Coup de gueule : il devrait être obligatoire d'avoir une boîte aux lettres. Évalué à 10.

    Pourtant, des 31 février, il n'y en a pas eu beaucoup, ça facilite la recherche.

  • [^] # Re: Euh…

    Posté par  . En réponse au journal SGI cartonne dans le monde des supercomputers grâce à Linux !. Évalué à 4.

    De toute façons, ces machines n'ont de SGI que le nom. La grenouille Rackable a racheté les cendres du bœuf SGI et a changé son nom afin de paraître plus grosse, mais leurs systèmes n'ont rien d'exceptionnel.

  • [^] # Re: Gestionnaire de source

    Posté par  . En réponse au journal Des nouvelles de LibreSSL. Évalué à 10.

    Ouai m'enfin dire que cvs c'est pas trop mal parce qu'il n'empêche pas d'utiliser git, c'est pas vraiment un argument pour rester avec cvs.

    Il y a une raison toute simple : l'historique. On a un arbre cvs qui contient près de 20 ans d'historique et plusieurs centaines de millier de commits.

    Migrer vers un autre VCS, pour OpenBSD, n'est acceptable que s'il est possible de récupérer la totalité de cet historique. Ce n'est pas du luxe, il arrive fréquemment que l'on aie à effectuer des recherches dans le code sur plusieurs années en arrière, et obliger à utiliser deux outils et deux arbres source selon la période concernée n'est pas acceptable.

    On a essayé, par le passé, divers outils de migration de VCS afin d'étudier la possibilité de la chose. Par exemple, cvs2svn n'est pas capable de gérer un arbre aussi gros (aussi bien en consommation mémoire qu'en consommation CPU). Notre meilleur espoir est actuellement effectivement une migration vers git, et un des développeurs a écrit un script qui arrive à traiter tout l'arbre, et reconstruire de véritables commits (i.e. retrouver les fichiers qui font l'objet d'un commit cvs avec le même message et au même moment). Il y a encore quelques opérations cvs qui lui posent problème, cependant.

  • [^] # Re: Gestionnaire de source

    Posté par  . En réponse au journal Des nouvelles de LibreSSL. Évalué à 10.

    M'enfin t'as rien compris ! Puisqu'on te dit que cvs c'est mal !

    Comme le dit le proverbe : « quand le sage montre le code, le fou regarde l'outil de VCS utilisé. »

  • [^] # Re: l'open source

    Posté par  . En réponse au journal Des nouvelles de LibreSSL. Évalué à 6.

    Si cela se trouve, le fork a été initié par la mafia russe qui va y introduire des failles :-D

    Merde, grillé… (mais tu t'es trompé en ce qui concerne le pays)

  • [^] # Re: 64 ko, data comprises où non ?

    Posté par  . En réponse au journal The Timeless hacke ta machine et ton cerveau. Évalué à 1.

    Ah, la GUS, c'était le bon temps !

  • [^] # Re: Netgear ReadyNas

    Posté par  . En réponse au journal Sparc chez Debian, c'est fini. Évalué à 3.

    Il y a eu effectivement au moins un modèle de ReadyNAS basé sur un cœur ``Infrant Padre'' compatible SPARC (je ne me souviens plus lequel, je crois que c'est le «Duo»). Mais je n'ai pas l'impression que les modifications apportées au noyau Linux (qui ont été publiées, pas de lézard de ce point de vue) aient fini dans les sources de Linus.

    Par ailleurs, il s'agit d'un processeur 32 bits, et il me semble que seuls les processeurs sparc 64 bits étaient encore supportés par Debian.

  • [^] # Re: Nostalgie

    Posté par  . En réponse au journal Sparc chez Debian, c'est fini. Évalué à 6.

    Obélix.

  • [^] # Re: Donc utile?

    Posté par  . En réponse au journal OpenSSL est mort, vive (le futur) LibreSSL. Évalué à 10.

    Choisir un nom n'était pas important parce que cela avait été fait très tôt, ainsi que la réservation des noms de domaine. D'où un certain désintérêt pour la question.

    Après, quand on s'acharne à nettoyer ce code-(ifdef-)spaghetti plein de toiles d'araignées et de morceaux de code emmurés que personne n'ose enlever, et que la principale préoccupation de spectateurs est «mais quel nom allez-vous utiliser ?», au bout d'un moment, la seule réaction qui te vient, c'est «vos gueules, y'en a qui bossent ici». D'où mon coup de gueule, qui permettait au passage de faire passer un peu de la ligne officielle du parti.

    Miod, pour le compte du ``Buena Vista SSL club''

  • [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

    Posté par  . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 1.

    Ah, mince, je n'avais pas vu que cela avait déjà été mentionné plus bas.

  • [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

    Posté par  . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 5.

    Bah, le seul véritable problème me semble être

    r = get_ctty_devnr(0, &devnr);
    if (r < 0)
    return -r;

    Il est clair que cette fonction renvoie, soit un file descriptor valide (donc >= 0) en cas de succès, et un code d'erreur négatif en cas d'échec.

    Si get_ctty_devnr() échoue, il faut renvoyer une erreur négative, donc "r" et non pas "-r" qui sera interprété comme une valeur de fd…

  • [^] # Re: Youpi !

    Posté par  . En réponse à la dépêche DragonFly BSD 3.6. Évalué à 4.

    «Quand les divers BSD se sont séparés, ils ont hérité de ce système»

    Ben non. Les ports de FreeBSD ont été créés plusieurs années après la séparation Free/Net. Et dans le plus pur esprit BSD, pkgsrc tout comme les ports OpenBSD ont commencé comme des forks des ports FreeBSD, eux aussi ajoutés après coup, et ont vite divergé en fonction des objectifs respectifs de chacun des projets.

  • [^] # Re: déja sur OpenBSD ?

    Posté par  . En réponse à la dépêche Le Bépo en console inclus de base sous GNU/Linux. Évalué à 2.

    C'est surtout du bépo limité parce qu'au moment où le support bépo a été ajouté à OpenBSD, la disposition «complète» n'était pas encore finalisée ; il n'y a donc que la disposition «simplifiée».

    On s'occupera de mettre à jour un jour de pluie.

  • [^] # Re: Petite question

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

    Seuls FreeBSD et OpenBSD ont décidé de s'abstenir d'utiliser du code sous licence GPLv3. DragonflyBSD et NetBSD n'ont pas de tels scrupules.

  • [^] # Re: Il est méchant mais il m'adore !

    Posté par  . En réponse à la dépêche RFC: Révision de la politique de sponsoring des RMLL. Évalué à 3.

    Et le canard ? Tu refuses les t-shirts de canard aussi ?

    Voyons, tout le monde sait bien que le canard est un légume !

  • [^] # Re: Est ce que la solution...

    Posté par  . En réponse au journal Les BSD isolés. Évalué à 1.

    AMHA si tu explores de nouvelles possibilités et que tu tentes d'aller au delà de POSIX, alors une certaine période d'expérimentation est inévitable avant que les choses ne se stabilisent. C'est ce que font les devs Linux.

    En ce qui concerne les cgroups, remplace Linux par google.

    Mais ta question reflète aussi le fait que Linux est le pionnier et que les BSDs sont, au moins sur ce sujet, les suiveurs. Pourquoi attendre que le travail soit terminé côté Linux pour ensuite décider d'adopter, ou pas, cette nouvelle techno ?

    Non. Ma question reflète le fait que l'écosystème Linux explore beaucoup de directions différentes, pour le meilleur comme pour le pire. Je n'ai rien a priori contre les cgroups, mais je n'ai rien pour : leur intérêt pratique reste à démontrer, et lorsqu'il le sera, alors il faudra que l'interface soit raisonnablement figée. En attendant qu'elle le soit, j'ai mieux à faire de mon temps que de coder une interface vouée à être fortement remaniée. C'est le côté Darwiniste du libre : si une API survit et s'avère utilisée, elle mérite que l'on s'y intéresse. Si elle crève dans son coin, on aura bien fait de ne pas s'y intéresser.

  • [^] # Re: Est ce que la solution...

    Posté par  . En réponse au journal Les BSD isolés. Évalué à 8.

    A quand les cgroups dans *BSD ?

    À quand une spécification définitive des cgroups ?