``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».
Ç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 ?
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.
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.
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.
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.
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.
«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.
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».
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: adéquation
Posté par Miod in the middle . 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 Miod in the middle . 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 Miod in the middle . 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 Miod in the middle . 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 Miod in the middle . 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 Miod in the middle . 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 Miod in the middle . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 4.
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 Miod in the middle . 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 Miod in the middle . 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 Miod in the middle . 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 Miod in the middle . En réponse au journal Des nouvelles de LibreSSL. Évalué à 10.
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 Miod in the middle . 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 Miod in the middle . En réponse au journal Des nouvelles de LibreSSL. Évalué à 6.
Merde, grillé… (mais tu t'es trompé en ce qui concerne le pays)
[^] # Re: 64 ko, data comprises où non ?
Posté par Miod in the middle . 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 Miod in the middle . 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 Miod in the middle . En réponse au journal Sparc chez Debian, c'est fini. Évalué à 6.
Obélix.
[^] # Re: Donc utile?
Posté par Miod in the middle . 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 Miod in the middle . 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 Miod in the middle . 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 Miod in the middle . 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 Miod in the middle . 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 Miod in the middle . 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 Miod in the middle . En réponse à la dépêche RFC: Révision de la politique de sponsoring des RMLL. Évalué à 3.
Voyons, tout le monde sait bien que le canard est un légume !
[^] # Re: Est ce que la solution...
Posté par Miod in the middle . En réponse au journal Les BSD isolés. Évalué à 1.
En ce qui concerne les cgroups, remplace Linux par google.
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 Miod in the middle . En réponse au journal Les BSD isolés. Évalué à 8.
À quand une spécification définitive des cgroups ?