Bon, je crois qu'un rappel sur la licence BSD s'impose...
Les deux clauses systématiquement rencontrées sont celles-ci :
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
Supposons que Microsoft ait réutilisé du code sous licence BSD au sein de Windows, comme l'y invite la licence.
Il suffit alors que la mention de copyright adéquat figure quelque part dans la documentation, par exemple dans un obscur fichier d'aide, ou un readme.txt dans un coin du disque dur, où dans la documentation imprimée, etc.
Il n'est pas nécessaire que cette mention soit particulièrement mise en avant.
Les premières versions d'Unix (jusqu'à la V7) avaient moins de 100 commandes, tous répertoires *bin confondus, ce qui est autrement plus facile à gérer que 2000 fichiers dans /usr/bin...
La plupart des shells modernent conservent une liste des exécutables disponibles dans les répertoires du PATH ; celle-ci est généralement créée au premier appel d'un binaire sans en donner le chemin absolu, et peux-être mise à jour(par exemple lorsque l'utilisateur change son PATH), par des commandes ad hoc (hash -r, rehash, etc).
Seule cette opération de mise en cache est relativement longue; ensuite, il n'y a pas de pénalité à avoir un PATH de grande longueur.
Pour les bibliothèques, c'est un peu la même chose.
Sur un système correctement administré, la quasi totalité des bibliothèques dynamiques dont auront besoin les programmes sont dans les chemins du système (/etc/ld.so.conf), et une recherche prémachée à l'intention de ld.so, effectuée par les soins de ldconfig au démarrage du système, est disponible (/var/run/ld.so.cache ou approchant, selon le système).
Si l'utilisateur a besoin d'utiliser la variable LD_LIBRARY_PATH, ce ne sera que pour un ou deux répertoires et de manière occasionnelle.
La encore, on ne peut pas considérer qu'il y a une perte de performance.
La licence du noyau Linux autorise explicitement, en clause additionnelle a la licence GPL, l'utilisation de modules non-GPL (par exemple, proprietaire des familles), a la condition expresse qu'ils ne necessitent aucun changement des API du noyau pour fonctionner.
Il n'a peut-être rien répondu de technique tout simplement parce qu'il n'a pas les compétences ni le recul pour être capable de répondre objectivement à cette critique.
Il y a tellement de choses à développer dans Hurd, chaque développeur ne peut pas être un expert technique sur tous les sujets possibles et imaginables...
L'article a été écrit par Brett Glass, un prosélyte BSD qui est connu pour en faire un peu trop.
Comme Brett hait viscéralement la GPL, il n'a pas pu s'empêcher de placer un paragraphe anti-GPL à partir de phrases particulièrement ambigües (par exemple ici, il dit que si l'on utilise du code GPL on doit diffuser le programme, ce qui empêche de le vendre; or ce sont les sources qui doivent être rendues disponibles, et il reste possible de vendre le logiciel).
C'est dommage, parce que ça nuit à la qualité de son article.
En fait, j'ai ecrit ce commentaire quand cette nouvelle etait encore en section "autres" et incorrect. Lors de son passage en premiere page, elle a ete corrige, rendant mon commentaire caduc.
... ne pourrais-tu pas faire l'effort de donner des informations correctes ? Ça arrangerait tout le monde...
Rectificatifions donc : les 3 cd ne sont bootables que sur 6 architectures, deux par disque (alpha, hp300, i386, macppc, sparc et sparc64)
Enfin, je pense que mentionner http://www.openbsd.org/fr/30.html(...) (traduction française de l'avant dernier lien) aurait été approprié, sinon à quoi ça sert, que les traducteurs, ils se décarcassent ?
Pourquoi utiliser Solaris plutôt que Linux sur UltraSPARC ?
Une très bonne raison : pour profiter d'un système 64 bits. Seul le noyau tourne en 64 bits pour Linux, le reste est du 32 bits, principalement à cause de problèmes dans le support sparc64 de gcc.
Linux est particulièrement lent sur les machines de type sun4c (SparcStation 1, 1+, 2, ELC, IPC, IPX et SLC) parce qu'il gère de façon très peu efficace le MMU de cette architecture. Sur d'autres types de machines Sparc, il a des performances tout à fait convenables.
M'sieu Anonyme, si tu visites le site de OpenBeOS, tu pourra constater que le sieur mmu est listé parmi les développeurs du système, et depuis plusieurs semaines...
Il existe un port de Linux pour Atari, au moins les modèles Falcon030 et clones.
Plus de détails sur http://www.linux-m68k.org(...)
Entre autres, tu y trouvera des liens vers une distribution Debian pour Atari.
Un portage de NetBSD existe également, supportant le Falcon030, le TT, le Hades, et le support du Milan est en cours de développement.
Plus de détails sur http://www.netbsd.org/Ports/atari(...)
Je me souviens du bon moment qu'on avait passé à la Place To Be, à chercher le bug dans la routine d'affichage de .FLC à la fin, en faisant attention de ne pas faire tomber les canettes de bière de l'écran de Patrice dont les couleurs étaient un peu trop verdatres...
Souvenirs, souvenirs (et une larme d'émotion, tiens).
Pourquoi pas ? Mais c'est loin d'être une tâche facile...
En ce qui concerne OpenSSH, le travail était somme toute relativement simple : il s'agissait d'adapter petit à petit le code aux subtilités de chaque système, au besoint en fournissant des fonctions de remplacement (très peu de systèmes ne dérivant pas de 4.4BSD fournissent les fonctions err(), errx(), warn() et warnx() dans libc, pour prendre un exemple simple).
Ce travail a été réalisé par un groupe de personnes indépendantes d'OpenBSD. Il a été reconnu et officialisé car il s'agit d'un travail de qualité.
Refaire la même chose avec PF est bien entendu théoriquement possible, mais, outre le fait que PF évolue plutôt vite pour l'instant, il est volontairement très lié aux particularités d'OpenBSD. Il ne devrait pas être trop difficile d'en effectuer un portage sur un autre système BSD, car les piles tcp/ip sont proches (et même identiques pour la pile ipv6 qui est KAME). Par contre, pour un autre système, ce sera beaucoup plus délicat...
[^] # Re: Ce n'est que le début ...
Posté par Miod in the middle . En réponse à la dépêche Lecteur de divx: la GPL violée par des développeurs Russes. Évalué à 1.
Les deux clauses systématiquement rencontrées sont celles-ci :
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
Supposons que Microsoft ait réutilisé du code sous licence BSD au sein de Windows, comme l'y invite la licence.
Il suffit alors que la mention de copyright adéquat figure quelque part dans la documentation, par exemple dans un obscur fichier d'aide, ou un readme.txt dans un coin du disque dur, où dans la documentation imprimée, etc.
Il n'est pas nécessaire que cette mention soit particulièrement mise en avant.
[^] # Re: Faudra qu'il explique ça à Ken Thompson
Posté par Miod in the middle . En réponse à la dépêche Mosfet : Rage against the File System Standard. Évalué à 10.
[^] # Re: Y'a pas 50 solutions
Posté par Miod in the middle . En réponse à la dépêche Mosfet : Rage against the File System Standard. Évalué à 10.
Seule cette opération de mise en cache est relativement longue; ensuite, il n'y a pas de pénalité à avoir un PATH de grande longueur.
Pour les bibliothèques, c'est un peu la même chose.
Sur un système correctement administré, la quasi totalité des bibliothèques dynamiques dont auront besoin les programmes sont dans les chemins du système (/etc/ld.so.conf), et une recherche prémachée à l'intention de ld.so, effectuée par les soins de ldconfig au démarrage du système, est disponible (/var/run/ld.so.cache ou approchant, selon le système).
Si l'utilisateur a besoin d'utiliser la variable LD_LIBRARY_PATH, ce ne sera que pour un ou deux répertoires et de manière occasionnelle.
La encore, on ne peut pas considérer qu'il y a une perte de performance.
[^] # Re: BSD ça pue !
Posté par Miod in the middle . En réponse à la dépêche L'alternative BSD. Évalué à 4.
La licence du noyau Linux autorise explicitement, en clause additionnelle a la licence GPL, l'utilisation de modules non-GPL (par exemple, proprietaire des familles), a la condition expresse qu'ils ne necessitent aucun changement des API du noyau pour fonctionner.
[^] # Re: Pas toujours convaincant
Posté par Miod in the middle . En réponse à la dépêche Interview de Neal Walfield (GNU/Hurd). Évalué à 10.
Il y a tellement de choses à développer dans Hurd, chaque développeur ne peut pas être un expert technique sur tous les sujets possibles et imaginables...
[^] # Re: Commentaire de l'auteur sur la license GPL
Posté par Miod in the middle . En réponse à la dépêche L'alternative BSD. Évalué à 9.
Comme Brett hait viscéralement la GPL, il n'a pas pu s'empêcher de placer un paragraphe anti-GPL à partir de phrases particulièrement ambigües (par exemple ici, il dit que si l'on utilise du code GPL on doit diffuser le programme, ce qui empêche de le vendre; or ce sont les sources qui doivent être rendues disponibles, et il reste possible de vendre le logiciel).
C'est dommage, parce que ça nuit à la qualité de son article.
[^] # Re: l'action de la gauche - HS -1
Posté par Miod in the middle . En réponse à la dépêche décision de justice à propos de front14.org. Évalué à 2.
[^] # Re: Saad, par pitié...
Posté par Miod in the middle . En réponse à la dépêche OpenBSD 3.0 bientôt dans les bacs. Évalué à -1.
[^] # Re: Un track audio sur le CD...
Posté par Miod in the middle . En réponse à la dépêche OpenBSD 3.0 bientôt dans les bacs. Évalué à 10.
Et puis comme il nous restait un peu de place, autant en profiter. Et ca cadre tres bien avec le theme des illustrations pour cette version.
# Saad, par pitié...
Posté par Miod in the middle . En réponse à la dépêche OpenBSD 3.0 bientôt dans les bacs. Évalué à 10.
Rectificatifions donc : les 3 cd ne sont bootables que sur 6 architectures, deux par disque (alpha, hp300, i386, macppc, sparc et sparc64)
Enfin, je pense que mentionner
http://www.openbsd.org/fr/30.html(...) (traduction française de l'avant dernier lien) aurait été approprié, sinon à quoi ça sert, que les traducteurs, ils se décarcassent ?
# Ah, la fougue de la jeunessse...
Posté par Miod in the middle . En réponse à la dépêche logo OpenBSD 3.0. Évalué à 1.
Le pilote pour cartes sons basees sur emu10k (SB Live!, SB PCI512, etc) est posterieur a la version 3.0.
[^] # Re: N'oublions pas ...
Posté par Miod in the middle . En réponse à la dépêche Bientôt d'autres plateformes. Évalué à 4.
Une très bonne raison : pour profiter d'un système 64 bits. Seul le noyau tourne en 64 bits pour Linux, le reste est du 32 bits, principalement à cause de problèmes dans le support sparc64 de gcc.
[^] # Re: N'oublions pas ...
Posté par Miod in the middle . En réponse à la dépêche Bientôt d'autres plateformes. Évalué à 8.
Linux est particulièrement lent sur les machines de type sun4c (SparcStation 1, 1+, 2, ELC, IPC, IPX et SLC) parce qu'il gère de façon très peu efficace le MMU de cette architecture. Sur d'autres types de machines Sparc, il a des performances tout à fait convenables.
[^] # Re: Plutot repartir sur ce qui existe deja !
Posté par Miod in the middle . En réponse à la dépêche BeOS n'est pas mort. Évalué à 4.
L'utilisation de Linux n'était de toute façon pas possible compte tenu de leur choix de licence.
[^] # Re: Youpi
Posté par Miod in the middle . En réponse à la dépêche BeOS n'est pas mort. Évalué à 5.
[^] # Re: D'après Coluche ...
Posté par Miod in the middle . En réponse à la dépêche Retranscription du chat avec le PDG de MandrakeSoft. Évalué à 1.
[^] # Re: Linux Entre Amis
Posté par Miod in the middle . En réponse à la dépêche Léa Espére un Acronyme. Concours. Évalué à 5.
[^] # Re: Faut pas faire des grosses annonces comme ça :)
Posté par Miod in the middle . En réponse à la dépêche First Jeudi. Évalué à 1.
[^] # Re: le retour de l'errata ....
Posté par Miod in the middle . En réponse à la dépêche Faille dans OpenSSH 2.5.x et 2.9.x. Évalué à -1.
En guise d'excuse, je dirai que ma langue maternelle ne derive pas du latin (-,
[^] # Re: 4 years...
Posté par Miod in the middle . En réponse à la dépêche Faille dans OpenSSH 2.5.x et 2.9.x. Évalué à 2.
Donc, toujours 4 ans sans vulnerabilite exploitable a distance dans l'installation par defaut...
[^] # Re: léger, léger...
Posté par Miod in the middle . En réponse à la dépêche LOGIN: #88 : OpenBSD 2.9. Évalué à 2.
[^] # Re: arg!
Posté par Miod in the middle . En réponse à la dépêche Faille dans OpenSSH 2.5.x et 2.9.x. Évalué à 2.
http://www.openssh.com/ftp.html(...)
ou
http://www.openssh.com/portable.html(...)
[^] # Re: Atari forever
Posté par Miod in the middle . En réponse à la dépêche Et une autre demo, une !. Évalué à 8.
Plus de détails sur http://www.linux-m68k.org(...)
Entre autres, tu y trouvera des liens vers une distribution Debian pour Atari.
Un portage de NetBSD existe également, supportant le Falcon030, le TT, le Hades, et le support du Milan est en cours de développement.
Plus de détails sur http://www.netbsd.org/Ports/atari(...)
# Purée, ça va me faire tout drôle...
Posté par Miod in the middle . En réponse à la dépêche Et une autre demo, une !. Évalué à 5.
Je me souviens du bon moment qu'on avait passé à la Place To Be, à chercher le bug dans la routine d'affichage de .FLC à la fin, en faisant attention de ne pas faire tomber les canettes de bière de l'écran de Patrice dont les couleurs étaient un peu trop verdatres...
Souvenirs, souvenirs (et une larme d'émotion, tiens).
[^] # Re: Portage Linux?
Posté par Miod in the middle . En réponse à la dépêche Le OpenBSD Packet Filter HOWTO est sorti. Évalué à 4.
En ce qui concerne OpenSSH, le travail était somme toute relativement simple : il s'agissait d'adapter petit à petit le code aux subtilités de chaque système, au besoint en fournissant des fonctions de remplacement (très peu de systèmes ne dérivant pas de 4.4BSD fournissent les fonctions err(), errx(), warn() et warnx() dans libc, pour prendre un exemple simple).
Ce travail a été réalisé par un groupe de personnes indépendantes d'OpenBSD. Il a été reconnu et officialisé car il s'agit d'un travail de qualité.
Refaire la même chose avec PF est bien entendu théoriquement possible, mais, outre le fait que PF évolue plutôt vite pour l'instant, il est volontairement très lié aux particularités d'OpenBSD. Il ne devrait pas être trop difficile d'en effectuer un portage sur un autre système BSD, car les piles tcp/ip sont proches (et même identiques pour la pile ipv6 qui est KAME). Par contre, pour un autre système, ce sera beaucoup plus délicat...