Miod in the middle a écrit 400 commentaires

> Bof, c'est joli ce que tu dis mais ça reste ton opinion.
Bien sûr ! Comme chacun des commentaires ici...

> écrire facilement du code non fiable sans s'en rendre compte
> j'adore qu'on me prenne pour un imbécile, oh tu ne l'as pas écrit bien sur...
Le mot clef était «permet». Je ne dis, ni ne sous-entend, que ceux qui codent en C sont des idiots. Cependant je maintiens que coder plus de 20000 lignes de C sans la moindre erreur est une tâche difficile.

> C permet d'écrire facilement du code non fiable
> linux par exemple, l'est pas fiable du tout...
Il suffit de constater que, version après version, une part non négligeable des changements sont des corrections de bugs, pour estimer que oui, Linux n'est pas fiable. Aucun logiciel n'est fiable d'ailleurs... Linux est suffisamment fiable pour répondre à la plupart des besoins, mais il n'y a pas de magie, dans plusieurs centaines de milliers de lignes de C, il y a toujours des erreurs, et pas uniquement parce qu'un driver a été écrit à partir d'un document constructeur lui-même erroné.

> le monde du logiciel libre est particulièrement conservateur
> C'est du FUD ? parce que le kernel est en C ? Moi j'ai vu
> plein de gens à la pointe sur XML, Ruby, Phython, Patterns Design,
> FreeNet, etc et qui faisaient bouger les choses...
> Et GNU en lui même n'est pas révolutionnaire ?
Non, ce n'est pas du FUD, c'est une simple constatation au fil du temps. Et le fait de coder un noyau en C n'est pas spécialement conservateur, mais plutôt un bon choix d'outil. On parlait des applications plus haut, ou les raisons d'utiliser le C plutôt qu'un autre langage sont moins importantes.
Quant à GNU, j'avoue ne pas trouver en quoi il serait révolutionnaire.

> mais bon, je viens du hardware alors quand je vois des
> propos si utopiques, ça me laisse reveur...
Et puis ? Moi aussi je viens du hardware. Et quand je code bas niveau, bien évidemment le C est l'un des outils les mieux adaptés.

> Cela dit, tu serais terrorisé si tu savais le nombre de
> machines et d'automates que tu croises toute la journée et
> qui sont codés en C... et qui pourtant ne plantent pas
> pour autant (sauf les trucs MS bien sur).
Pas plus que ça, vu que je suis responsable d'une partie de ces lignes de C (-:

Tsk, tsk, tsk. Interprétation hâtive des propos de Nicolas.

Oui, des langages de type C (ou C++, guère meilleur sur ce point de vue) permettent d'écrire facilement (et surtout sans s'en rendre compte) du code non fiable. Cela oblige les programmeurs à se montrer rigoureux, mais quand mien même ils le sont, l'erreur est humaine et tôt ou tard leur code finit par être erroné.

Non, recoder Apache en un autre langage n'est pas réaliste. Ne serait-ce parce que c'est un logiciel complexe, et que l'on ne transpose pas l'expérience et la connaissance de son fonctionnement qu'en ont ses développeurs vers un autre langage en peu de temps.

L'avenir est probablement d'écrire un énième logiciel de serveur web, mais cette fois-ci dans un langage moderne et adapté à ce genre d'application, permettant aux développeurs de se concentrer sur les vrais problèmes à résoudre (performance, scalabilité, mise à disposition du contenu d'un site) plutôt que sur les problèmes liés au système (gestion de la mémoire, des ressources système, des divers processus et/ou thread lancés, etc).

Simplement, une telle chose n'est pas près d'arriver, principalement parce que le monde informatique, et plus particulièrement le monde du logiciel libre, est particulièrement conservateur quant aux méthodes («on a toujours codé en C», «malloc() c'est plus rapide qu'autre chose», «de toute façon pour coder sous un système POSIX seul le C est adapté», etc).

C'est pourquoi ceci ne se produira pas sans un changement des mentalités des programmeurs... et tant que de tels propos seront considérés comme troll, il restera un long chemin à parcourir.

- $sig_on_top. Include the signature before any quoted or forwarded
text. WARNING: use of this option may provoke flames.

Je sens qu'une nouvelle version du .mutt-troll-rc s'impose...

Sans le «mal documenté», il avait une chance de passer, mais là, trop gros, passera pas...

Comme si ceux qui découvrent les failles le faisaient non pas pour obliger l'éditeur à vite sortir un correctif, mais pour leur gloire personnelle...

Malheureusement, une (trop) grande partie des gens qui découvrent les failles les publient pour leur gloire personnelle, une fois qu'ils en ont marre de jouer avec.

Certaines des fonctionnalités sont prévues sur le long terme.

TPE : pas spécialement envisagé
acl : en cours (et des vrais acl, pas les pseudo-semblant-simili acl de Stephanie)
Vérification md5 : non
Restriction des affichages de ps etc : il faudrait qu'on commence par y trouver une utilité
Restriction sur les liens symboliques : non
Journal des appels execve() : on a mieux avec systrace en -current...
paranoia ld.so : pas spécialement envisagé (cela a autant d'utilité que la restriction d'affichage de ps etc)

Pour Solaris 9, je ferai comme avec toutes les versions majeures des produits qui sortent :
attendre un peu, car comme chacun le sait, le béta-testeur c'est l'utilisateur.

Allons, allons, ce n'est tout de même pas la même chose que s'il s'agissait de la Mandrake 9 !

(-1 et je sors...)

Je me permets de rappeller rapidement que le patch Stéphanie n'est pas exempt de bugs (en particulier, il y a quelques deadlocks amusants), et qu'il est toujours particulièrement agréable de chercher en vain un problème signalé par l'utilisateur pendant quelques heures avant que celui-ci ne glisse ingénuement «au fait, j'ai le patch Stéphanie installé, est-ce que ça influe ?». On a testé pour vous...

Ce genre de patch a son utilité, mais ne l'appliquez pas sans réfléchir, en particulier sur un système en production ; et pensez qu'il n'a pas été vérifié et validé comme le reste du système, et que son utilisation n'est pas recommandée.

Je me demande bien d'où tu peux sortir «SSH1 + SSH2 gérés» comme «grande nouveauté» sachant que cela fait un an et demie qu'ils le sont.

Pareil, en fait de «1000 packages», c'est «bien plus de 1000» (mais pas encore 2000, toutefois)...

Il aurait été plus judicieux de simplement laisser un lien vers l'annonce, comme l'a fais Jean-Yves Burlett dans un commentaire.

N'est-ce pas toi qui avait dit, il y a quelques semaines, que compiler du Perl, c'était (je cite) «grouik» ?

Avec comme gros inconvénients que ce projet :
- n'est disponible que sur architecture x86 ;
- n'est maintenu ni en ce qui concerne ipf, ni en ce qui concerne les errata d'OpenBSD 3.0 ;
- n'est supporté ni par Darren Reed ni par les mailing list OpenBSD...

Actuellement, les deux dernières versions d'OpenBSD sont systématiquement supportées, ce qui laisse une période d'un an pour la mise à disposition de correctifs.

Compte tenu qu'il sort une nouvelle version tous les six mois, cela n'est pas une tâche trop compliquée que de préparer une mise à jour à la version N+1 au cours des six mois qui suivent sa sortie, et avant la sortie de la version N+2 qui marque l'arrêt de la maintenance de la version N.

Maintenant, il y a également trois grosses raisons qui font que nous ne supportons pas plus de deux versions stables :
- des problèmes affectant la version N peuvent ne pas affecter les versions N+1 et ultérieures, car résolues lors de changements non triviaux. Il n'est pas dans la vocation des branches -stable de contenir la moitié des changements ayant eu lieu entre les versions N et N+1...
- utilisation de ressources CVS. Chaque commit dans une branche fait grossir la taille du dépot CVS, sans que cela soit considéré comme une occupation «utile» car peu de personnes utilisent les branches stable, surtout les anciennes versions.
- utilisation de ressources matérielles. Pour maintenir une branche stable dans de bonnes conditions, il faut une machine dédiée, qui pourrait tous comptes faits servir à autre chose de plus «excitant»...

Les développeurs d'OpenSSH n'ont pas l'intention de changer de language de sitôt, malgré tous les efforts de persuasion que tu pourra déployer. Cependant, rien n'empêche qui que ce soit de développer une alternative écrite dans le language de son choix. Si tu veux une implémentation ssh libre, et non écrite en C, il te suffit de trouver une équipe de développeurs intéressés et de se mettre au travail, tout simplement...

C'est pour décourager les lecteurs de consulter le glossaire final, qui définit «Debian» comme «Entreprise commercialisant une version de Linux»...

Non, il ne veut certainement pas dire ça car la commande correcte serait

sh ./install.sh | /usr/bin/yes

[-1 on s'en contrefiche]

Si NT (et 2000) n'est pas vulnérable à ce problème, il continue à empêcher la création de fichier portant ces noms par un vague souci de compatibilité... ce qui peut s'avérer pénible !

[cf. MSKB Q216654]

Ca colle, alors. Les programmes GNU viennent sans page de manuel, mais la documentation O'Reilly complete ce manque...

Elle est dans la section "autres".

A part SSH, il n'y a rien de lancé comme deamon dans OpenBSD.

C'est drôle, on ne doit pas avoir la même version, alors. L'installation par défaut d'OpenBSD lance quatre daemons : sshd, sendmail (n'acceptant que les connections locales, cependant), portmap et inetd.

Ces deux commandes s'appliquent à ext2 (et, je suppose, également ext3), mais d'autres systèmes de fichiers disposent de commandes du même acabit permettant de placer cet attribut d'immuabilité.

Par exemple, dans le cas des systèmes de fichier ffs sous *BSD, il s'agit de chflags(1).

Pas même lynx ?

Mettre une boîte «version de Sylpheed» sans faire une boîte «version de Windowmaker», ce serait un crime de lèse majesté !

(-1, je sors, etc)

OpenSSH supporte l'authentification par SmartCard (plus de détails dans README.smartcard dans les sources) depuis l'été dernier.

Tu as mal compris ce document.
Ce que tu cites comme nouveautés sont trois exemple de changements devant donner lieu à la création de branches CVS. Cela ne veut en aucun cas dire que de tels changements auront lieu...

Les Indigo2 peuvent accueillir des cartes ethernet EISA, par exemple les cartes Phobos, qui sont des 3c597 rebadgées.

En plus, comme les 3c597 sont full duplex et que l'interface intégrée est half-duplex, cela permet de gagner en performances.

Les cartes Phobos sont chères, même d'occasion ; en revanche il est plutôt facile de trouver une 3c597 d'occasion à vil prix, et de patcher le driver Phobos afin qu'il accepte de reconnaître la carte 3Com.

J'ai d'ailleurs une 3c597 dans mon Indigo2 et j'en suis très satisfait.

Plus de détails sur cette magouille en
http://www.futuretech.vuurwerk.nl/fastether.html(...)