Ah oui : (For the ptrace bug, a root-shell exploit was available on 17 March 2003, and a working fix was not available on linux-kernel until the following week. Evidence found on the machine indicates that gnuftp was cracked during that week.)
C'est le moment de vérifier ce que vous avez downloadé.
Pensez à utiliser gnupg pour vérifier la signature du md5sum. La conception de pgp/gnupg est une petite merveille d'intelligence. Malheureusement, c'est un peu lourd a utiliser dans le cadre du site ftp.gnu.org car les fichiers doit être signés manuellement un par un par une personne de confiance.
Je ne peux que très chaudement vous recommender de vous familliariser avec gnupg : http://www.gnupg.org/(...)
C'est pas trivial au début mais ça finit par rentrer.
N'oubliez pas que les rpm (les .deb aussi ?) sont souvent signés.
Faite un "rpm --checksig toto.rpm" pour être sûre de la provenance d'un paquet.
Les signatures des distributions sont généralement dans /usr/share/doc/rpm-...
Il faut importer la signature dans rpm avec "rpm --import" avant de pourvoir vérifier la signature d'un paquet. Attention, c'est de votre responsabilité de vérifier que la signature est digne de confiance. C'est pour celà qu'elle n'est pas importée d'origine.
Globalement je suis de ton avis. Mais c'est une qualité du logiciel libre que d'avoir des projets dont la viabilité ou l'interêt n'est pas évidant pour la majorité.
Si les développeurs et les utilisateurs prennent leur pied et ne font de mal à personne, où est le problème ?
Szulik: The desktop is certainly an important area, but when we're inside now speaking to corporations the areas they are trying to solve are around configuration management, patch updates, scheduling, other hard problems that are causing their systems not to perform the way they want. Those are the areas we see as more strategic at this moment in time and of course ultimately, [our strategy] will find its way toward the Red Hat Desktop implementation.
J'ai l'impression que t'as pas essayé une RedHat depuis un moment.
> est ce que les services proposés par RH ne sont valables que si la distribution est pure, c'est à dire avec rien d'autre que ce qui a sur les CD fournis ?
Tu peux ajouter des programmes, il n'y a pas de problème avec ça. Par contre si tu changes de noyau ou de libc par exemple, il n'y a plus de support. Et c'est pas tout a fait ça. Si tu changes la libc, le support via rhn est toujours disponible. Par contre la hotline refusera de t'aider si tu ne prends pas un support très couteux.
Le seul truc proprio chez RedHat, c'est toute la partie serveur de rhn. De plus si tu achetes un serveur rhn ou un proxy rhn tu peux ajouter des canaux supplémentaires (par exemple le canal gnustep).
Pour finir avec rhn, le nouveau client rhn, up2date, qui est utilisé pour mettre à jour les bécanes supporte depuis peu des dépôts yum, apt et même de simple répertoire remplit de rpm ( http://listman.redhat.com/archives/rhl-beta-list/2003-August/msg005(...) ) et c'est RedHat qui a développé ces extensions. Le programme redhat-config-packages aura aussi ces extensions. Celà sera dispo dans la prochaine RHL et la RHLE post 3.0. Et la prochaine RHL aura aussi yum. Et pour info, up2date et redhat-config-packages sont sous GPL et il existe des implémentation libre du serveur rhn : http://current.tigris.org/(...) http://www.nrh-up2date.org/(...)
Si RedHat voulais appliquer un "vrai" modèle économique proprio, le protocole rhn serait breveté, les clients uniquement en binaire, et redhat n'utiliserait pas isolinux pour créer les cd bootables, etc... Tu peux acheter une RHEL, downloader toutes mise à jours sous forme de paquet, faire des images iso et mettre le tout sur internet. C'est le boulot d'une journée. Si tu veux vendre il faut virer ce qui est relatif à la marque RedHat. C'est un boulot qui prend 3 jours maxi et c'est parfaitement légal.
Puis via rhn, redhat vend principalement le service de mettre à jours ou administrer plusieurs bécanes à la fois (pour une bécance c'est gratuit). Ici on fait l'apologie du service alors que RedHat fournie un service basé sur un produit proprio pour un produit libre...
Je peux admettre que rhn a un modèle économique proprio mais pour tout le reste ça ne tient pas la route. D'ailleur RedHat ne support jamais de produit proprio. Sauf le jre sous RHEL mais c'est parce qu'il n'y a pas d'équivalent en libre.
Essaies d'avoir du support de Mandrake pour la cooker :-) Reproche à Mandrake de fournir des produits proprio via leur club...
Pour moi Mandrake n'a pas un modèle économique propriétaire.
Que le "domination" de RedHat et SuSE pose problème, je suis d'accord et je l'ai dit. Mais faut pas chercher les problèmes là où il n'y en a pas.
Plus que ça ! Tu as répondu concrêtement à mon intérogation. Mais là, ce n'est pas forcément la faute des distributeurs. Mais plutôt la faute d'oracle. Ça rejoint le fait que RedHat et SuSE ont maintenant une place prépondérante dans les serveurs. Mais il ne crée pas de standard propriétaire.
Et si tu étais à la place d'Oracle, tu supporterais Gentoo, par exemple, qui peut être compilé de 50 façons différentes ?
Le fsck de reiserfs ne gère pas les blocks défectueux contrairement à e2fsck (dont l'excellence n'est plus à démontrer).
Les quotas ne sont pas journalisés par reiserfs 3.
Reiserfs 3 ne journalise pas les donnés. Par contre reiserfs 4 le fait.
Alan Cox un peu énervé avec les demandes répétés d'avoir reiserfs dans RedHat (c'est fourni mais pas officiellement (faire "linux reiserfs" au boot lilo), et non fourni dans la version Enterprise) a indiqué que reiserfs ne passe pas les tests/critères RedHat.
Il faut bien reconnaitre que reiserfs c'est fait une mauvaise réputation en sortant trop tôt à cause de la pression de Hans sur Linus. Et Hans fait de nouveau la même erreur en demandant d'intégration de reiserfs 4 dans 2.6.0. Ext3 était dispo pour 2.2 (patch) mais n'a été officiellement intégré à Linux que dans la version 2.4.9 .
A chaque fois que j'ai eu des problèmes avec ext3, c'était lié à un problème hard. S'il n'y a pas de problème hard, ça roule. Mais moins vite que reiserfs...
> on doit considérer un logiciel comme un service plutôt que comme un produit.
Ta voiture te rend service mais c'est aussi un produit avec des caractéristiques. Le plus important c'est le service rendu. Mais si le produit n'est pas en mesure de rendre le service demandé...
> Tu devrais plutôt parler d'utilisateurs, ça serait plus proche de la réalité.
Comme les société commerciales ont des utilisateurs. On tourne en rond le fond ne change pas.
> SuSE et Yast
J'ai répondu plus haut.
> Lindows, Xandros
Je connais pas.
> RedHat et gcc
RedHat a fait ça une fois. C'était pour avoir le support Itanium et avec un compilo compatible source avec 2.95 et 3.0 pour préparer le passage à 3.0. De plus Debian utilise ce compilo pour la plate-forme Itanium.
> RedHat et KDE
RedHat a introduit une incompatibilité dans RH8.0 : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74071(...)
Notes que le bug est renseigné par un employé RedHat. Tu peux aussi t'amuser à rechercher les bugs reportés par le team KDE dans le bugzilla de redhat :-)
Un produit fournit des services. Si c'est un mauvais produit il fournira un mauvais service. Une pile tcp/ip fournit un service. L'implémentation Linux de cette pile est un produit et non un service. Un logiciel de dessin, est un service. Gimp est un produit. Gimp ce n'est pas le service de faire du dessin avec un ordinateur. Et un produit informatique n'est forcément quelque chose qui doit se vendre. D'où le licence GPL. La licence GPL s'applique au produit Gimp mais pas au service rendu par Gimp. Et heureusement.
Pourquoi vouloir obsolument nier l'aspect produit ? On tourne en rond.
> il faut plutôt parler de services
"Linux me fourni le service de fournir des systèmes de fichier journalisé, j'ai aussi le service de s'excécuteur en mode 64 bits, et d'accéder à des périphériques USB."
Heureusement en général on ne parle pas comme ça.
> > Y a SuSE avec YaST.
> C'est l'une des trois distributions commerciales majeures. Pour moi, ça compte beaucoup.
Yast ce n'est pas un protocol. Yast n'impose pas de format de fichier de configuration pour apache par exemple.
Un utilisateur de SuSE n'a pas plus de difficulté de passer à Debian qu'un utilisateur de Debian à passer à SuSE. Il n'y a pas de dépendance créé ici.
> Tout dépent de ce qu'on appelle fantaisie, en fait.
Ben si tu limites les "fantaisies" tu fais comme les autres.
> Ta réponse est une bonne illustration de ce que Ian Murdock critique.
Tu peux expliquer ?
> En fait, il propose de considérer Linux comme une infrastructure et non pas comme un produit.
Je pense qu'il faut considérer Linux comme les deux. On développe un bon produit dans une bonne infrastructure. Une belle infrastructure qui n'accouche pas d'une bon produit est sans réel intérêt.
> Dans la mesure où Murdock est lui-même administrateur de Progeny, un distributeur commercial de Linux, ses remarques méritent vraiment qu'on y réfléchisse.
Mais j'y ai réfléchis (dans la mesure de mes moyens :-)).
Je ne pense pas que sa "vision" est fausse. Mais actuellement je ne la vois pas concrêtement et certaines critiques me paraissent excéssives.
Par exemple :
> puis controler les standard en "capturant" les client aux moyens de technologies propriétaires
Y a SuSE avec YaST. C'est tout pour le propriétaire (j'oublie volontairement les Linux/Xandros etc).
> de contrats de support englobant les standards existants et s'étendant jusqes aux bonnes pratiques"
Qui peut fournir du support qui couvre toutes les fantaisies de l'utilisateur ? Ce serait un support extrèmement cher.
On peut retrouver dans cette critique le fait, par exemple, que RedHat ne supporte que ext3. Mais c'est un ext3 standard. Ce qui compte, c'est qu'il y ait d'autres distributeurs pour supporter reiserfs, xfs, jfs. J'ai un peu dit dans mon précédent post.
> Les incompatibilités introduites par certaines sociétés [de distributions Linux] conduisent, à nouveau, à un verrouillage par ces sociétés au moyen des services et du support.
Il y a épisodiquement des incompatibilités qui apparaissent. Mais c'est pas le bout du monde. Prends RedHat avec gcc 2.96. C'est incompatible binaire mais compatible source. Donc pour tous les projets LL, ça roule. De plus c'est pas une volonté de faire incompatible mais plutôt l'adaptation de gcc pour répondre à un besoin. D'ailleur maintenant RedHat à un compilo tout ce qu'il y a de standard. Puis RedHat et un gros contributeur de gcc...
Il y a aussi la LSB que les distributions majeurs respectent.
Les paquets sont lisibles partout. Je peux voir un .deb et un utilisateur de debian peut voir un .rpm.
RedHat a aussi introduit nptl. Es-ce un problème ? C'était plannifier pour Linux 2.6 et ça suis les standards.
Une évènement interessant est le projet rhl. En gros redhat est plus ouvert au contributions extérieurs et veut être plus synchronisé avec l'upstream des projets.
Tant que les contributions extérieurs (boîtes commerciales comme Sun/IBM ou les bénévoles) ont un apport significatif pour un distributeur, les distributeurs n'auront pas envis de s'éloigner de ce qui est réalisé par les projets. Par exemple RedHat a dit qu'il intègrerait reiserfs, si c'est supporté (dans le cadre de la distribution, je ne parle pas du noyau). C'est à dire qu'ils ne veulent pas s'occuper de reiserfs, mais accèpte toute initiative extérieur qui permet de supporter reiserfs.
Bref, ce que je veux dire, sans nier la pertinance du raisonnement de l'article, c'est qu'actuellement je ne vois pas de dérives significatives et il me semble que la possibilité de """monopole""" de certains distributeurs est plus préoccupante.
Je donne une réflexion pas forcément lié à ton post.
Je trouve en général qu'un soft qui, dans la mesure du possible, ne demande pas de consulter une doc est un plus. Ça ne veut pas dire que je demande aux utilisateurs de ne pas savoir ce qu'il font.
Des exemples tout bête. Au début de linux il fallait connaitre ifconfig et route pour avoir le réseau. Maintenant j'ai une interface graphique et ça roule. J'ai toujours besoin de connaitre TCP/IP mais pas ifconfig/route.
Avant pour avoir un noyau qui marche pour ta bécane il fallait recompiler le noyau puis configurer lilo et lancer lilo. Maintenant je n'ai plus besoin de connaitre les subtilités de la compilation d'un noyau ou de lilo/grub. Je fais un "rpm -i kernel..." et tout est ok.
Avant pour écouter un cd, il fallait faire un hideux chown ou chmod 666 pour pouvoir écouter un CD. Maintenant avec pam il n'y a rien a faire.
Avant a chaque fois que tu ajoutais un programme sur ta bécane il fallait éditer ton .fvwm pour avoir un menu. Maintenant c'est toujours fait.
Avant pour avoir une image en fond d'écran il faillait utiliser son .xsession. Idem pour qu'un programme soit systématiquement lancé. Maintenant il y a des interfaces graphique pour configurer le fond d'écran (un bête drag&drop) et tu demandes tout simplement de sauvegarder la session lorsque tu quittes le bureau.
Avant lorsque tu fesais un ssh ou telnet sur une autre bécane il fallait défini DISPLAY sur avoir l'affichage de programme X11 sur ton écran. Mais c'est fait automatique.
Bref, depuis plusieurs années, Linux me simplie la vie.
Maintenant pour utiliser efficacement Linux, c-à-d faire ce que j'ai envis, c'est beaucoup plus rapide, ça demande moins de compétance et c'est tant mieux.
Ce qui compte, c'est de savoir ce que l'on fait. C-à-d activer une interface réseau, installer un noyau, etc. Pour un utilisateur, savoir que l'installation d'un noyau passe par la detection du disque dure de boot, la recherche des drivers nécessaires pour accéder à la particition racine, la création d'un inird avec les modules nécessaires pour accéder à la particition racine, la reconfiguration de lilo ou grub est pour l'utilisateur final sans grand intérêt.
Une fois que l'utilisation a installé son système rapidement (c-à-d sans passer plusieurs heures à fouiller les docs et poser des questions sur les forums) il peut s'attaquer à ce qu'il intéresse. Surfer, dessiner avec gimp, et pourquoi pas décrypter la séquence de boot du noyau, ou coder un nouveau système de fichier,
ou lire la doc rpm pour découvrir que "rpm -e <nom du paquet>" désinstalle un paquet :-)
Plus spécifiquement l'ajout a été demandé par Richard Stallman et Eben Moglen (voir le patch du changelog) . Bref on peut pratiquement affirmer que c'est la FSF.
J'ai pas vu ça : The Free Software Foundation's overriding goal is to protect the freedom of the free software community, including developers and users, but we also want to serve users.
De plus : We will have a further announcement concerning continuing support of SCO Unix
by GCC before our next release.
Linux n'est pas un produit... Tout un programme.
Je préfèrerait "Linux n'est pas qu'un produit". Un produit c'est utile (ou ça sert à rien mais ça fait plaisir). Puis il faut bien avoir une vision produit de Linux pour en faire quelque chose d'utile.
Un bon exemple c'est Gnome ou Kde, où les développeurs ont compris qu'ils devaient faire un produit pour tout le monde (qui marche et accessible). Faire un bon produit, c'est répondre aux attentes du clients. Si les développeurs n'ont pas une vision produit (c-à-d ignore les clients) en vas retomber sur les travers de programme fait par des développeurs pour des développeurs qui n'intéressent presque personne. Le but du logiciel libre c'est d'être largement utilisé et non uniquement par les développeurs.
C'est bien la vision produit de Linux qui permet aux distributeurs de faire du pognon qui est après réinjecté dans le logiciel libre. S'il n'y a pas de vision produit, tu vends quoi ?
Un distributeur vend un produit. Il garantit le support, le niveau de performance, la compatibilité, etc... Et plus que tout il fait attention à la satisfaction du client. C'est un bon produit qui va satisfaire le client/utilisateur et l'éloigner des solutions proprios. Si Linux devient de plus en plus populaire, c'est parce que ça devient un bon produit.
Et puis ça conclusion je la comprend pas.
> En poursuivant les stratégies de verouillage des plate-formes traditionnelles
?
Les distributeurs sont généralement très impliqués dans les développements des projets libres. J'ai pas connaissance de distribution majeur qui ne suit pas les évolutions des projets et reste sur une version.
> l'industrie des distributions Linux tente de détourner une infrastructure technologique en une infrastructure propriétaire.
Que les distributeurs tentent d'orienter des projets vers leur besoin (donc pour leur produit) je comprends. Mais généralement, cette orientation est obtenu en contribuant au projet. Ceux qui ne contribue pas ne font rien bouger. Doit-on se plaindre que les distributeurs contribuent ?
Puis "détourner une infrastructure technologique en une infrastructure propriétaire"... Perso, j'ai rien remarqué. Si quelqu'un a des exemples a donner pour que je comprenne mieux, je suis preneur.
> Le code source peut être disponible, mais qu'en tirer de bon si je suis scotché à la compagnie qui me l'a donné ?
C'est pareil, je comprends pas. Le gros problème avec les distributeurs actuellement, c'est qu'on commence à découvrir des concentrations de compétences. Pour les serveurs il y a principalement plus que deux acteurs et les choses ne semblent que s'accentuer. Ainsi, alors qu'on disait il était facile de concurrencer n'importe quelle distribution, on se rend compte que pour les serveurs c'est pratiquement plus le cas. Car pour les serveurs il ne faut pas uniquement fournir une bonne distribution, il faut l'infrastructure pour le support, il faut de grosses compétences en interne pour répondre aux problèmes des gros clients et il faut aussi s'être forgé une grosse réputation.
On commence a approcher une situation ou un monopole de "compétences", de service est envisagable sous Linux. D'ailleur j'ai été surpris, et je m'en félicite, que Sun ne cherche plus a faire ça propre distribution pour les serveurs. Comme s'il rendait les armes...
Si c'est par curiosité (juste pour voir), c'est pas très intéressant :-(. C'est-à-dire que la futur RHE est principalement une RedHat normale, entre la RH9 et la prochaine RH10. A l'oeil nu les différences ne sont pas énormes. Ceci est normal car RedHat indique que la différence entre la RHE et RHL est principalement le support. De plus le noyau actuel à des options de debug activés ce qui le ralentit. Par contre il y a des fonctionnalités qu'on ne trouvent pas sur la RH Linux "normal". Principalement le support PXE, le support pour station diskless et ACL (samba 3.0 est livré).
Depuis la beta1 il y a beaucoup d'erratas. Pour les récupérer tu peux créer un compte demo sur http://rhn.redhat.com/(...) . Les erratas sont uniquement fournit par rhn car RedHat veut en profiter pour tester le service. Des informations de ta becane (hard et paquets) seront remontées sur le site. T'es libre de refuser cette remontée d'info (et biensur tu peux toujours créer ton compte démo sans ces infos).
Pour créer le compte, c'est pas compriqué, tu fais un rhn_register. Pour mettre à jour tu fais up2date. La partie "desktop" n'est pas dans la AS de la beta1. RedHat l'a ajouté après quelques plaintes sur mailing-list. Mais tu peux l'ajouter en fesant "up2date --install openoffice mrproject etc". Pour voir la liste des paquets dispos non installés fais "up2date --show-available".
[^] # Re: ftp.gnu.org piraté
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à 3.
(For the ptrace bug, a root-shell exploit was available on 17 March 2003, and a working fix was not available on linux-kernel until the following week. Evidence found on the machine indicates that gnuftp was cracked during that week.)
# Re: ftp.gnu.org piraté
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à 6.
http://lwn.net/Articles/44402/(...)
C'est le moment de vérifier ce que vous avez downloadé.
Pensez à utiliser gnupg pour vérifier la signature du md5sum. La conception de pgp/gnupg est une petite merveille d'intelligence. Malheureusement, c'est un peu lourd a utiliser dans le cadre du site ftp.gnu.org car les fichiers doit être signés manuellement un par un par une personne de confiance.
Je ne peux que très chaudement vous recommender de vous familliariser avec gnupg :
http://www.gnupg.org/(...)
C'est pas trivial au début mais ça finit par rentrer.
N'oubliez pas que les rpm (les .deb aussi ?) sont souvent signés.
Faite un "rpm --checksig toto.rpm" pour être sûre de la provenance d'un paquet.
Les signatures des distributions sont généralement dans /usr/share/doc/rpm-...
Il faut importer la signature dans rpm avec "rpm --import" avant de pourvoir vérifier la signature d'un paquet. Attention, c'est de votre responsabilité de vérifier que la signature est digne de confiance. C'est pour celà qu'elle n'est pas importée d'origine.
# Re: ftp.gnu.org piraté
Posté par ptit_tux . En réponse à la dépêche ftp.gnu.org compromis. Évalué à -10.
C'est une bonne piqûre de rappel à peut de frais.
[^] # Re: Afterstep n'est pas mort
Posté par ptit_tux . En réponse à la dépêche Afterstep n'est pas mort. Évalué à 6.
Si les développeurs et les utilisateurs prennent leur pied et ne font de mal à personne, où est le problème ?
[^] # Re: Debian a 10 ans !
Posté par ptit_tux . En réponse à la dépêche Debian a 10 ans !. Évalué à 1.
Je crois pas :
http://www.crn.com/sections/BreakingNews/dailyarchives.asp?ArticleI(...)
Szulik: The desktop is certainly an important area, but when we're inside now speaking to corporations the areas they are trying to solve are around configuration management, patch updates, scheduling, other hard problems that are causing their systems not to perform the way they want. Those are the areas we see as more strategic at this moment in time and of course ultimately, [our strategy] will find its way toward the Red Hat Desktop implementation.
J'ai l'impression que t'as pas essayé une RedHat depuis un moment.
[^] # Re: Linux n'est pas un produit
Posté par ptit_tux . En réponse à la dépêche Linux n'est pas un produit. Évalué à 2.
Tu peux ajouter des programmes, il n'y a pas de problème avec ça. Par contre si tu changes de noyau ou de libc par exemple, il n'y a plus de support. Et c'est pas tout a fait ça. Si tu changes la libc, le support via rhn est toujours disponible. Par contre la hotline refusera de t'aider si tu ne prends pas un support très couteux.
Le seul truc proprio chez RedHat, c'est toute la partie serveur de rhn. De plus si tu achetes un serveur rhn ou un proxy rhn tu peux ajouter des canaux supplémentaires (par exemple le canal gnustep).
Pour finir avec rhn, le nouveau client rhn, up2date, qui est utilisé pour mettre à jour les bécanes supporte depuis peu des dépôts yum, apt et même de simple répertoire remplit de rpm ( http://listman.redhat.com/archives/rhl-beta-list/2003-August/msg005(...) ) et c'est RedHat qui a développé ces extensions. Le programme redhat-config-packages aura aussi ces extensions. Celà sera dispo dans la prochaine RHL et la RHLE post 3.0. Et la prochaine RHL aura aussi yum. Et pour info, up2date et redhat-config-packages sont sous GPL et il existe des implémentation libre du serveur rhn :
http://current.tigris.org/(...)
http://www.nrh-up2date.org/(...)
Si RedHat voulais appliquer un "vrai" modèle économique proprio, le protocole rhn serait breveté, les clients uniquement en binaire, et redhat n'utiliserait pas isolinux pour créer les cd bootables, etc... Tu peux acheter une RHEL, downloader toutes mise à jours sous forme de paquet, faire des images iso et mettre le tout sur internet. C'est le boulot d'une journée. Si tu veux vendre il faut virer ce qui est relatif à la marque RedHat. C'est un boulot qui prend 3 jours maxi et c'est parfaitement légal.
Puis via rhn, redhat vend principalement le service de mettre à jours ou administrer plusieurs bécanes à la fois (pour une bécance c'est gratuit). Ici on fait l'apologie du service alors que RedHat fournie un service basé sur un produit proprio pour un produit libre...
Je peux admettre que rhn a un modèle économique proprio mais pour tout le reste ça ne tient pas la route. D'ailleur RedHat ne support jamais de produit proprio. Sauf le jre sous RHEL mais c'est parce qu'il n'y a pas d'équivalent en libre.
Essaies d'avoir du support de Mandrake pour la cooker :-) Reproche à Mandrake de fournir des produits proprio via leur club...
Pour moi Mandrake n'a pas un modèle économique propriétaire.
Que le "domination" de RedHat et SuSE pose problème, je suis d'accord et je l'ai dit. Mais faut pas chercher les problèmes là où il n'y en a pas.
[^] # Re: Validation d'une hypothèse...
Posté par ptit_tux . En réponse à la dépêche À nouveau noyau, nouveaux benchs de systèmes de fichiers. Évalué à 2.
SCO ?
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par ptit_tux . En réponse à la dépêche À nouveau noyau, nouveaux benchs de systèmes de fichiers. Évalué à 2.
Non, j'ai pas de problème actuellement.
> Il peut le faire
Non. Mais reiserfs 4 le fait. Enfin je le garantis pas mais j'ai lu ça.
[^] # Re: Linux n'est pas un produit
Posté par ptit_tux . En réponse à la dépêche Linux n'est pas un produit. Évalué à 1.
Je sais que tu fais de la poésie http://linuxfr.org/comments/253365.html(...) post-moderne :
- "Et par retroaction, elle fait senti le caca pourri a toute la distribution."
[^] # Re: Linux n'est pas un produit
Posté par ptit_tux . En réponse à la dépêche Linux n'est pas un produit. Évalué à 2.
Plus que ça ! Tu as répondu concrêtement à mon intérogation. Mais là, ce n'est pas forcément la faute des distributeurs. Mais plutôt la faute d'oracle. Ça rejoint le fait que RedHat et SuSE ont maintenant une place prépondérante dans les serveurs. Mais il ne crée pas de standard propriétaire.
Et si tu étais à la place d'Oracle, tu supporterais Gentoo, par exemple, qui peut être compilé de 50 façons différentes ?
[^] # Re: Un logiciel n'est jamais un produit
Posté par ptit_tux . En réponse à la dépêche Linux n'est pas un produit. Évalué à 1.
Donc la version Qt sous windows est un produit et Qt sous Unix est un service ?
Faut pas déformer les mots. Si je veux comparer openoffice à ms-office je doit dire :
- le service openoffice
- le produit ms-office
J'ai pas envie que le logiciel libre crée un vocabulaire qui lui est spécifique.
> non une session de propriété
La licence gpl n'est pas une session de propriété !
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par ptit_tux . En réponse à la dépêche À nouveau noyau, nouveaux benchs de systèmes de fichiers. Évalué à 4.
Le fsck de reiserfs ne gère pas les blocks défectueux contrairement à e2fsck (dont l'excellence n'est plus à démontrer).
Les quotas ne sont pas journalisés par reiserfs 3.
Reiserfs 3 ne journalise pas les donnés. Par contre reiserfs 4 le fait.
Alan Cox un peu énervé avec les demandes répétés d'avoir reiserfs dans RedHat (c'est fourni mais pas officiellement (faire "linux reiserfs" au boot lilo), et non fourni dans la version Enterprise) a indiqué que reiserfs ne passe pas les tests/critères RedHat.
Il faut bien reconnaitre que reiserfs c'est fait une mauvaise réputation en sortant trop tôt à cause de la pression de Hans sur Linus. Et Hans fait de nouveau la même erreur en demandant d'intégration de reiserfs 4 dans 2.6.0. Ext3 était dispo pour 2.2 (patch) mais n'a été officiellement intégré à Linux que dans la version 2.4.9 .
A chaque fois que j'ai eu des problèmes avec ext3, c'était lié à un problème hard. S'il n'y a pas de problème hard, ça roule. Mais moins vite que reiserfs...
[^] # Re: Linux n'est pas un produit
Posté par ptit_tux . En réponse à la dépêche Linux n'est pas un produit. Évalué à -1.
Ta voiture te rend service mais c'est aussi un produit avec des caractéristiques. Le plus important c'est le service rendu. Mais si le produit n'est pas en mesure de rendre le service demandé...
> Tu devrais plutôt parler d'utilisateurs, ça serait plus proche de la réalité.
Comme les société commerciales ont des utilisateurs. On tourne en rond le fond ne change pas.
> SuSE et Yast
J'ai répondu plus haut.
> Lindows, Xandros
Je connais pas.
> RedHat et gcc
RedHat a fait ça une fois. C'était pour avoir le support Itanium et avec un compilo compatible source avec 2.95 et 3.0 pour préparer le passage à 3.0. De plus Debian utilise ce compilo pour la plate-forme Itanium.
> RedHat et KDE
RedHat a introduit une incompatibilité dans RH8.0 :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74071(...)
Notes que le bug est renseigné par un employé RedHat. Tu peux aussi t'amuser à rechercher les bugs reportés par le team KDE dans le bugzilla de redhat :-)
Le correctif est ici :
https://rhn.redhat.com/errata/RHSA-2002-220.html(...)
Pour ton info, lit cette article d'un utilisateur/développeur sous KDE à propos de KDE de RH8.0 :
http://www.cyber.com.au/users/mikem/redhat8kde.html(...)
Tu verras que la majorité des patchs ne sont pas de RedHat.
> Considères-tu Internet comme un produit ?
Un produit fournit des services. Si c'est un mauvais produit il fournira un mauvais service. Une pile tcp/ip fournit un service. L'implémentation Linux de cette pile est un produit et non un service. Un logiciel de dessin, est un service. Gimp est un produit. Gimp ce n'est pas le service de faire du dessin avec un ordinateur. Et un produit informatique n'est forcément quelque chose qui doit se vendre. D'où le licence GPL. La licence GPL s'applique au produit Gimp mais pas au service rendu par Gimp. Et heureusement.
> Pour Linux, il faut que ça soit pareil.
Tu veux payer pour utiliser Linux ?
[^] # Re: Linux n'est pas un produit
Posté par ptit_tux . En réponse à la dépêche Linux n'est pas un produit. Évalué à 1.
Pourquoi vouloir obsolument nier l'aspect produit ? On tourne en rond.
> il faut plutôt parler de services
"Linux me fourni le service de fournir des systèmes de fichier journalisé, j'ai aussi le service de s'excécuteur en mode 64 bits, et d'accéder à des périphériques USB."
Heureusement en général on ne parle pas comme ça.
> > Y a SuSE avec YaST.
> C'est l'une des trois distributions commerciales majeures. Pour moi, ça compte beaucoup.
Yast ce n'est pas un protocol. Yast n'impose pas de format de fichier de configuration pour apache par exemple.
Un utilisateur de SuSE n'a pas plus de difficulté de passer à Debian qu'un utilisateur de Debian à passer à SuSE. Il n'y a pas de dépendance créé ici.
> Tout dépent de ce qu'on appelle fantaisie, en fait.
Ben si tu limites les "fantaisies" tu fais comme les autres.
[^] # Re: Linux n'est pas un produit
Posté par ptit_tux . En réponse à la dépêche Linux n'est pas un produit. Évalué à 1.
Tu peux expliquer ?
> En fait, il propose de considérer Linux comme une infrastructure et non pas comme un produit.
Je pense qu'il faut considérer Linux comme les deux. On développe un bon produit dans une bonne infrastructure. Une belle infrastructure qui n'accouche pas d'une bon produit est sans réel intérêt.
> Dans la mesure où Murdock est lui-même administrateur de Progeny, un distributeur commercial de Linux, ses remarques méritent vraiment qu'on y réfléchisse.
Mais j'y ai réfléchis (dans la mesure de mes moyens :-)).
Je ne pense pas que sa "vision" est fausse. Mais actuellement je ne la vois pas concrêtement et certaines critiques me paraissent excéssives.
Par exemple :
> puis controler les standard en "capturant" les client aux moyens de technologies propriétaires
Y a SuSE avec YaST. C'est tout pour le propriétaire (j'oublie volontairement les Linux/Xandros etc).
> de contrats de support englobant les standards existants et s'étendant jusqes aux bonnes pratiques"
Qui peut fournir du support qui couvre toutes les fantaisies de l'utilisateur ? Ce serait un support extrèmement cher.
On peut retrouver dans cette critique le fait, par exemple, que RedHat ne supporte que ext3. Mais c'est un ext3 standard. Ce qui compte, c'est qu'il y ait d'autres distributeurs pour supporter reiserfs, xfs, jfs. J'ai un peu dit dans mon précédent post.
> Les incompatibilités introduites par certaines sociétés [de distributions Linux] conduisent, à nouveau, à un verrouillage par ces sociétés au moyen des services et du support.
Il y a épisodiquement des incompatibilités qui apparaissent. Mais c'est pas le bout du monde. Prends RedHat avec gcc 2.96. C'est incompatible binaire mais compatible source. Donc pour tous les projets LL, ça roule. De plus c'est pas une volonté de faire incompatible mais plutôt l'adaptation de gcc pour répondre à un besoin. D'ailleur maintenant RedHat à un compilo tout ce qu'il y a de standard. Puis RedHat et un gros contributeur de gcc...
Il y a aussi la LSB que les distributions majeurs respectent.
Les paquets sont lisibles partout. Je peux voir un .deb et un utilisateur de debian peut voir un .rpm.
RedHat a aussi introduit nptl. Es-ce un problème ? C'était plannifier pour Linux 2.6 et ça suis les standards.
Une évènement interessant est le projet rhl. En gros redhat est plus ouvert au contributions extérieurs et veut être plus synchronisé avec l'upstream des projets.
Tant que les contributions extérieurs (boîtes commerciales comme Sun/IBM ou les bénévoles) ont un apport significatif pour un distributeur, les distributeurs n'auront pas envis de s'éloigner de ce qui est réalisé par les projets. Par exemple RedHat a dit qu'il intègrerait reiserfs, si c'est supporté (dans le cadre de la distribution, je ne parle pas du noyau). C'est à dire qu'ils ne veulent pas s'occuper de reiserfs, mais accèpte toute initiative extérieur qui permet de supporter reiserfs.
Bref, ce que je veux dire, sans nier la pertinance du raisonnement de l'article, c'est qu'actuellement je ne vois pas de dérives significatives et il me semble que la possibilité de """monopole""" de certains distributeurs est plus préoccupante.
PS : Bravo pour la traduction.
[^] # Re: Debian a 10 ans !
Posté par ptit_tux . En réponse à la dépêche Debian a 10 ans !. Évalué à 2.
Je trouve en général qu'un soft qui, dans la mesure du possible, ne demande pas de consulter une doc est un plus. Ça ne veut pas dire que je demande aux utilisateurs de ne pas savoir ce qu'il font.
Des exemples tout bête. Au début de linux il fallait connaitre ifconfig et route pour avoir le réseau. Maintenant j'ai une interface graphique et ça roule. J'ai toujours besoin de connaitre TCP/IP mais pas ifconfig/route.
Avant pour avoir un noyau qui marche pour ta bécane il fallait recompiler le noyau puis configurer lilo et lancer lilo. Maintenant je n'ai plus besoin de connaitre les subtilités de la compilation d'un noyau ou de lilo/grub. Je fais un "rpm -i kernel..." et tout est ok.
Avant pour écouter un cd, il fallait faire un hideux chown ou chmod 666 pour pouvoir écouter un CD. Maintenant avec pam il n'y a rien a faire.
Avant a chaque fois que tu ajoutais un programme sur ta bécane il fallait éditer ton .fvwm pour avoir un menu. Maintenant c'est toujours fait.
Avant pour avoir une image en fond d'écran il faillait utiliser son .xsession. Idem pour qu'un programme soit systématiquement lancé. Maintenant il y a des interfaces graphique pour configurer le fond d'écran (un bête drag&drop) et tu demandes tout simplement de sauvegarder la session lorsque tu quittes le bureau.
Avant lorsque tu fesais un ssh ou telnet sur une autre bécane il fallait défini DISPLAY sur avoir l'affichage de programme X11 sur ton écran. Mais c'est fait automatique.
Bref, depuis plusieurs années, Linux me simplie la vie.
Maintenant pour utiliser efficacement Linux, c-à-d faire ce que j'ai envis, c'est beaucoup plus rapide, ça demande moins de compétance et c'est tant mieux.
Ce qui compte, c'est de savoir ce que l'on fait. C-à-d activer une interface réseau, installer un noyau, etc. Pour un utilisateur, savoir que l'installation d'un noyau passe par la detection du disque dure de boot, la recherche des drivers nécessaires pour accéder à la particition racine, la création d'un inird avec les modules nécessaires pour accéder à la particition racine, la reconfiguration de lilo ou grub est pour l'utilisateur final sans grand intérêt.
Une fois que l'utilisation a installé son système rapidement (c-à-d sans passer plusieurs heures à fouiller les docs et poser des questions sur les forums) il peut s'attaquer à ce qu'il intéresse. Surfer, dessiner avec gimp, et pourquoi pas décrypter la séquence de boot du noyau, ou coder un nouveau système de fichier,
ou lire la doc rpm pour découvrir que "rpm -e <nom du paquet>" désinstalle un paquet :-)
[^] # Re: Sortie de GCC 3.3.1
Posté par ptit_tux . En réponse à la dépêche Sortie de GCC 3.3.1. Évalué à 2.
[^] # Re: Sortie de GCC 3.3.1
Posté par ptit_tux . En réponse à la dépêche Sortie de GCC 3.3.1. Évalué à 1.
[^] # Re: Sortie de GCC 3.3.1
Posté par ptit_tux . En réponse à la dépêche Sortie de GCC 3.3.1. Évalué à 1.
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00214.html(...)
Désolé pour le post plus bas.
[^] # Re: Sortie de GCC 3.3.1
Posté par ptit_tux . En réponse à la dépêche Sortie de GCC 3.3.1. Évalué à -1.
J'ai pas vu ça :
The Free Software Foundation's overriding goal is to protect the freedom of the free software community, including developers and users, but we also want to serve users.
De plus :
We will have a further announcement concerning continuing support of SCO Unix
by GCC before our next release.
C'est "We" et non "The Free Software Foundation".
J'ai vu sur la mailing-list gcc, que certains développeurs de gcc étaient assez chaud par rapport à SCO (le début du thread) :
http://gcc.gnu.org/ml/gcc/2003-07/msg01564.html(...)
# Re: Lesquels me racontent des bobards ?
Posté par ptit_tux . En réponse au journal Lesquels me racontent des bobards ?. Évalué à -3.
Il faut bien que ceux qui achetent une Nvidia pour jouer sous Windows se justifient.
[^] # Re: Quelques nouvelles relatives à RedHat
Posté par ptit_tux . En réponse à la dépêche Quelques nouvelles relatives à RedHat. Évalué à 0.
Ça existe déjà.
# Re: Linux n'est pas un produit
Posté par ptit_tux . En réponse à la dépêche Linux n'est pas un produit. Évalué à 10.
Linux n'est pas un produit... Tout un programme.
Je préfèrerait "Linux n'est pas qu'un produit". Un produit c'est utile (ou ça sert à rien mais ça fait plaisir). Puis il faut bien avoir une vision produit de Linux pour en faire quelque chose d'utile.
Un bon exemple c'est Gnome ou Kde, où les développeurs ont compris qu'ils devaient faire un produit pour tout le monde (qui marche et accessible). Faire un bon produit, c'est répondre aux attentes du clients. Si les développeurs n'ont pas une vision produit (c-à-d ignore les clients) en vas retomber sur les travers de programme fait par des développeurs pour des développeurs qui n'intéressent presque personne. Le but du logiciel libre c'est d'être largement utilisé et non uniquement par les développeurs.
C'est bien la vision produit de Linux qui permet aux distributeurs de faire du pognon qui est après réinjecté dans le logiciel libre. S'il n'y a pas de vision produit, tu vends quoi ?
Un distributeur vend un produit. Il garantit le support, le niveau de performance, la compatibilité, etc... Et plus que tout il fait attention à la satisfaction du client. C'est un bon produit qui va satisfaire le client/utilisateur et l'éloigner des solutions proprios. Si Linux devient de plus en plus populaire, c'est parce que ça devient un bon produit.
Et puis ça conclusion je la comprend pas.
> En poursuivant les stratégies de verouillage des plate-formes traditionnelles
?
Les distributeurs sont généralement très impliqués dans les développements des projets libres. J'ai pas connaissance de distribution majeur qui ne suit pas les évolutions des projets et reste sur une version.
> l'industrie des distributions Linux tente de détourner une infrastructure technologique en une infrastructure propriétaire.
Que les distributeurs tentent d'orienter des projets vers leur besoin (donc pour leur produit) je comprends. Mais généralement, cette orientation est obtenu en contribuant au projet. Ceux qui ne contribue pas ne font rien bouger. Doit-on se plaindre que les distributeurs contribuent ?
Puis "détourner une infrastructure technologique en une infrastructure propriétaire"... Perso, j'ai rien remarqué. Si quelqu'un a des exemples a donner pour que je comprenne mieux, je suis preneur.
> Le code source peut être disponible, mais qu'en tirer de bon si je suis scotché à la compagnie qui me l'a donné ?
C'est pareil, je comprends pas. Le gros problème avec les distributeurs actuellement, c'est qu'on commence à découvrir des concentrations de compétences. Pour les serveurs il y a principalement plus que deux acteurs et les choses ne semblent que s'accentuer. Ainsi, alors qu'on disait il était facile de concurrencer n'importe quelle distribution, on se rend compte que pour les serveurs c'est pratiquement plus le cas. Car pour les serveurs il ne faut pas uniquement fournir une bonne distribution, il faut l'infrastructure pour le support, il faut de grosses compétences en interne pour répondre aux problèmes des gros clients et il faut aussi s'être forgé une grosse réputation.
On commence a approcher une situation ou un monopole de "compétences", de service est envisagable sous Linux. D'ailleur j'ai été surpris, et je m'en félicite, que Sun ne cherche plus a faire ça propre distribution pour les serveurs. Comme s'il rendait les armes...
# Re: Nouvelle version du noyau Linux
Posté par ptit_tux . En réponse au journal Nouvelle version du noyau Linux. Évalué à 0.
http://linuxfr.org/~yodaz/4551.html(...)
J'en profite pour rappeler cette news qui donne quelques url importantes pour quelqu'un qui veut tester/utiliser le 2.6 :
http://linuxfr.org/2003/07/11/13229.html(...)
[^] # Re: Quelques nouvelles relatives à RedHat
Posté par ptit_tux . En réponse à la dépêche Quelques nouvelles relatives à RedHat. Évalué à 2.
Pour les pages de man, c'est les même que les autres distributions. Comprends pas.
> Bon bah je vais essayer une EAS en toute légalité just for fun :o)
Regardes la beta1 de la futur RHE 3.0 :
http://lwn.net/Articles/41631/(...)
Voir aussi la release note :
http://wftp.tu-chemnitz.de/pub/linux/redhat-ftp/redhat/linux/beta/t(...)
Si c'est par curiosité (juste pour voir), c'est pas très intéressant :-(. C'est-à-dire que la futur RHE est principalement une RedHat normale, entre la RH9 et la prochaine RH10. A l'oeil nu les différences ne sont pas énormes. Ceci est normal car RedHat indique que la différence entre la RHE et RHL est principalement le support. De plus le noyau actuel à des options de debug activés ce qui le ralentit. Par contre il y a des fonctionnalités qu'on ne trouvent pas sur la RH Linux "normal". Principalement le support PXE, le support pour station diskless et ACL (samba 3.0 est livré).
Depuis la beta1 il y a beaucoup d'erratas. Pour les récupérer tu peux créer un compte demo sur http://rhn.redhat.com/(...) . Les erratas sont uniquement fournit par rhn car RedHat veut en profiter pour tester le service. Des informations de ta becane (hard et paquets) seront remontées sur le site. T'es libre de refuser cette remontée d'info (et biensur tu peux toujours créer ton compte démo sans ces infos).
Pour créer le compte, c'est pas compriqué, tu fais un rhn_register. Pour mettre à jour tu fais up2date. La partie "desktop" n'est pas dans la AS de la beta1. RedHat l'a ajouté après quelques plaintes sur mailing-list. Mais tu peux l'ajouter en fesant "up2date --install openoffice mrproject etc". Pour voir la liste des paquets dispos non installés fais "up2date --show-available".
Notes qu'il n'y a pas reiserfs.