Miod in the middle a écrit 400 commentaires

N'importe quel lecteur de cd-rom scsi capable de fonctionner avec des secteurs logiques de 512 octets (soit par commande, soit par jumper), devrait fonctionner.

i.e. n'importe quel lecteur fonctionnant sur une parc (pas ultrasparc !) fera l'affaire.

Pour plus de détails, voir la «SUN cd-rom FAQ» en
http://www.ebsinc.com/solaris/suncdrom.html(...)

On dit un vieil «HP» ou une vieille «HP» selon ses goûts, mais certainement pas «Apollo».

Afin de ne pas effaroucher les clients d'Apollo, HP a utilisé le nom sur ses propres machines pendant quelques années, bien que le système et le matériel soient totalement différents.

Les seules machines HP pouvant légitimement porter l'étiquette Apollo sont la série des 9000/400 (400, 425, 433), et pour cause... il s'agit d'une conception Apollo reprise par HP afin de la rendre compatible avec la gamme 300, à l'époque...

Le 7011-250 est un PowerPC 603, il me semble qu'il est supporté par linuxppc.

A ce sujet, ne soyez pas timide, si vous etes doue en francais, vous pouvez egalement participer aux relectures (coordonnees aussi sur traduc.org). Les traducteurs de howto seront les premiers a reconnaitre que parfois leur francais laisse a desirer...

Ce que tu nommes «jolies choses» sont ce que l'on appelle plus cruement des «extensions gnu make». Le comportement de make, ainsi que la syntaxe des Makefile, est normalisé dans Single Unix Specification v2.

Le gnu make y ajoute un certain nombre d'extensions de son cru, dont certaines sont intéressantes, mais qui ne sont dès lors plus portable, puisque ne pouvant fonctionner que si l'on utilise gnu make...

Pas OpenBSD, mais FreeBSD, attention a ne pas confondre...

32V est la première version d'Unix fonctionnant sur systèmes vax (les anciennes ne fonctionnant que sur certains modèles de PDP-11, 16 ou 18 bits), d'où le 32 dans le nom.

C'est aussi la première version disposant d'un système de mémoire virtuelle, en utilisant les fonctionnalités de pagination propres au VAX, d'où le V (virtual) dans le nom.

Cette version est considéré comme un «milestone» majeur dans l'histoire d'Unix.

Depuis la fusion entre BSDi et Walnut Creek, l'an dernier, avant le rachat par Windriver, une fusion progressive entre BSDi et FreeBSD était en cours, les éléments non «libérables» de BSDi (pour cause de mauvaises licences, NDA, etc) mis à part. La branche 5.0 de FreeBSD en a déjà beaucoup bénéficié, en particulier pour le support SMP, qui était meilleur chez BSDi.

Il était initialement prévu que les parties propriétaires de BSDi soient toujours disponibles à la vente pour les clients intéressés. La débâcle provoquée par Windriver a probablement changé la donne, puisqu'on en entend plus parler...

Non, je veux simplement dire que Theo est le proprietaire du nom.
Il est normal d'attendre son retour avant de prendre une eventuelle decision qui le concerne au plus haut plan.

Pourquoi il n'y a pas encore de dispute à propos du nom ?

Quelques indices :

Primo, le produit de Darren Reed s'identifie comme «OpenBSD/IPF» ou «OpenBSD with IPF». Certes, pas le système lui-même, mais pour le télécharger il faut bien être passé sur le site de Darren Reed...

Secundo, Theo de Raadt est actuellement en vacances en Argentine, éloigné de tout ordinateur et connexion internet pour quelques jours encore, donc il est normal qu'il n'ait pas réagi pour le moment.

Tertio, nous avons briévement discuté de cette situation hier soir, et le consensus général était qu'il valait mieux en rire qu'en pleurer...

On verra bien, d'ici quelque temps, la popularité de cette variante du système, et la promotion qu'en fait Darren Reed qui, pour l'instant, n'a pas cherché à faire une publicité particulière à ce travail.

Une erreur s'est glissée dans le texte de la niouse.

Au lieu de lire
«Les nouvelles versions d'OpenBSD (>= 3.0) utilisent pf et nat, des outils développés au sein d'OpenBSD qui sont eux aussi stables et fonctionnels (quelques fonctions supplémentaires par rapport à IPFilter) mais encore jeunes.»

il faut lire :
«Les nouvelles versions d'OpenBSD (>= 3.0) utilisent pf, un filtre de paquet (disposant également de fonctionnalités NAT) développé au sein d'OpenBSD qui est aussi stable et fonctionnel (quelques fonctions supplémentaires par rapport à IPFilter) mais encore jeune.»

C'est une bonne nouvelle.

L'important n'est pas tant que FreeBSD dispose ou non d'une source de financement (après tout, d'autres projets vivent très bien par les dons des utilisateurs satisfaits et des subventions de recherche), mais que les développeurs de FreeBSD anciennement employés par WindRiver aient de nouveau l'assurance qu'on ne leur demandera de travailler que sur FreeBSD et non pas en main d'oeuvre de secours sur tel ou tel projet de WindRiver.

Le journaliste de silicon.fr n'a pas tout à fait compris les faits, semble-t-il.

Une version alpha de RedHat existe depuis très longtemps, en tout cas au moins les RH 4.x. La sortie de RedHat 7.2 pour alpha n'est que la continuation du support de cette plate-forme.

Ce qui est nouveau côté alpha, c'est que cette version sera désormais distribuée par Compaq.

Merci pour le conseil, mais l'histoire de Mygale, je la connais plutôt bien, ayant fait parti des premières centaines de sites hébergés, à l'automne 96. Avant l'interruption des créations de compte, le système de parrainage, etc...

Les premières menaces de Renater de fermeture de Mygale datent de la fin du printemps 97, pour cause de trop grande consommation de bande passante. Souvenez-vous, de nombreuses pages sur mygale (et ailleurs) avaient été retirées pour protester, à l'époque, et Mygale avait eu un sursis.

Tout ceci est bien antérieure à la création de Multimania, à l'automne 99.

Il y avait des bandeaux de pub (sobre) sur Mygale, ainsi que le Mygalethon qui avait financé une partie du matériel à l'époque.

La migration vers multimania aurait certainement pu se faire avec moins de heurts si la nouvelle équipe de multimania n'avait pas immédiatement montré son mépris total des utilisateurs (comme la suppressions «temporaire» (plusieurs mois) des redirections de mail automatique et du serveur pop (plusieurs semaines), avec moins de 24 heures de préavis, pour commencer...)

Linux/sparc peut effectivement faire fonctionner les binaires SunOS 4 et Solaris sans trop de difficultes.

L'inverse n'est pas encore possible, personne a ma connaissance ne s'etant donne la peine de porter lxrun(http://www.ugcs.caltech.edu/~steven/lxrun(...(...)) ) - qui permet de faire tourner les binaires Linux/x86 sur SCO, Solaris/x86, et peut-etre d'autres - sur {ultra,}sparc.

Il faut que le binaire que l'on souhaite faire tourner soit compile pour l'architecture materielle utilise, bien entendu (sinon, il faut une emulation lourde, genre bochs ou spim).

Cependant, le concept est bien entendu applicable a toutes les architectures, ainsi les ports powerpc de NetBSD peuvent emuler les binaire Linux/ppc, etc.

Dans mes bras Irvin!

Plus sérieusement, un choix de licence passe par deux points très importants :

• L'auteur du logiciel, quand il décide de rendre son travail public, doit être conscient de ce qu'implique son geste ;


• L'auteur doit connaître l'existence de plusieurs licences afin de pouvoir choisir autant que possible une licence existante (afin de minimiser le bordel...) mais surtout une licence qui lui convienne.

Combien de personnes ayant diffusé du code ont rempli ces deux conditions ?

Une fois que l'auteur a pris sa décision, c'est à chacun de la respecter. On pourra taxer d'altruisme ceux qui diffuseront dans des licences non restrictives (type BSD), avec le spectre du danger de propriétarisation, comme on pourra taxer d'anarchisme ceux qui diffuseront dans des licences «verrouillantes» (type GPL), avec la garnatie de la pérennité des sources pour tout un chacun.

En ce qui me concerne, et ce n'est pas une surprise je pense, je suis biaisé envers la licence BSD, car je n'ai pas l'intention d'imposer des restrictions sur mon code dès lors qu'il est rendu public. Ce qui ne m'a pas empêché ça et là, de diffuser du code sous d'autres licences, dont la GPL.

Et je dois dire que j'ai maintes fois constaté que, pour qu'un standard émerge, le fait de disposer d'une implémentation de référence sous une licence non restrictive comme peut l'être la licence BSD, a joué un rôle important. Combien d'implémentation de TCP/IP se sont basées sur le code de 4BSD ? Combien d'implémentation de IPv6 réutilisent une partie du code de KAME ? Combien d'implémentations de Kerberos reprennent, aux bugs près, l'implémentation de référence du MIT ou l'une de ses dérivées ? Pourquoi le code d'Ogg Vorbis existe-t-il désormais en licence BSD ? Etc, etc.

Sans rien apporter au débat, OS/2 à l'époque n'était pas totalement 32 bits non plus, une partie du système fonctionnait en 16 bits pour des raisons de compatibilité (plus théorique que réelle, d'ailleurs) avec les drivers écrits pour les versions 1.x d'OS/2 (toute ma jeunesse).

Cette couche de compatibilité a été abandonnée à partir de la version 5 d'OS/2 («Aurora»), qui est sorti bien après.

Et cette version CD est disponible à l'achat depuis plus d'un mois, les précommandes ayant été honorées à partir du 23 novembre...

Sans vouloir tempérer ton optimisme, depuis la version 3.0, -CURRENT est un ton en dessous de la stabilité ordinaire, surtout sur certaines architectures (sparc, hp300, amiga par exemple). Cela dit, on y travaille, pas d'inquiétude...





[-1 hors sujet]

Je crois que tu as mis un zéro de trop, et que le prix d'achat de QDOS n'était que de $5000.

Quand aux deux qui se mordraient les c*uilles, voilà des années que Gary Kildall est décédé.

Gcc souffre de gros problèmes en ce qui concerne la production de code correct pour ultrasparc. Les développeurs de gcc le reconnaissent et y travaillent afin que la version 3.1 ait enfin une qualité convenable (i.e. pas de problèmes majeurs en compilant son code en -O2).

En ce qui concerne sizeof(int) == 4 (soit 32 bits), c'est la situation la plus fréquemment rencontrée sur les processeur 64 bits afin de faciliter la vie des programmeurs quand ils adaptent leurs logiciels. Si tu veux utiliser toute la largeur des registres, utilise non pas int, mais long. Ou, si ton système les propose, un type à taille explicite comme u_int64_t.

Sparc v7 (sun4, 4c, 4e) et v8 (4d, 4m) sont bien des systemes 32 bits (i.e. pas des UltraSPARC (sun4u)).

Cela dit, actuellement, le port sun4u de Linux n'est 64 bits qu'au niveau du noyau, le reste du systeme (userland) est en 32 bits.

Certes, mais l'intervalle 1,$ peut etre avantageusement remplace par %.

Donc :
:%s/2\.2/2.4/g