matiasf a écrit 1969 commentaires

Et si t'as pas besoin de log, tu peux meme faire un halt. Le noyau continu sa fonction pare-feu.

Et la t'es un pare-feu hyper protege (mais comme sur un pare-feu il y a rien d'interessant (doc confidentiel, etc...) ...).

Rien ne t'interdit de monter des partitions en Read-only.

De plus, il y a une commande hdparm qui permet de mettre un disque en read-only.

Question securite, le CD-ROM n'apporte rien ...

Ca fait du bien.

C'est hyper juste.

Hors querelle de cloche, je vois que linux evolu super vite et bien. Surtout compare aux Unix commerciaux.
Certain vont dire qu'il n'est pas normal d'attendre pres d'un an pour un 2.4 stable. Moi ca me choque pas compte tenu des fonctionnalites et du nombre de drivers.
Les boites qui utilisent des Unix commerciaux et veulent un systeme fiable ne prennent pas la version sortie l'annee precedante !

C'est pareille pour Linux (c'est meme mieux).

Certain pense que si Linux etait sous CVS avec droit d'ecriture ca irait plus vite.
Plus vite peut-etre mais avec plus de bordel c'est sure.
La lourdeur (relative) du developpement de Linux est lie a toutes les phases de controle/concertation (que les meme qui veulent un developpement plus rapide trouve insuffisant).

Bref, plein cul des gens qui gueulent alors que Linux est recent et est presque la rolls des noyaux Unix :
- plein de drivers et de tres loin.
- multi-plateforme.
- 32 et 64 bits.
- modulable.
- version temps reel.
- le top en reseau (ipv6, firewall, etc...).
- etc...

Je trouve les linuxiens limite cassent couilles. Ils gueulent car un petit patch n'est pas applique alors qu'un windowien se felicite que Microsoft est corrige un trou de securite vieux de 3 mois.

Le plus choquant est le manque de respect pour les developpeurs (souvent benevoles) et qui merite notre consideration.

Il me semble que Linus delegue certaines parties. Par exemple Alsa qui est enorme a ete rapidement integre.

Si quelqu'un se promene dans les mailing-list kernel, peut-il confirmer qu'il y a de reels problemes (et non des plaintes isolees) ?

Quel est l'avis de Linus ?

Je crois que c'est Eric qui pique une petite crise comme le sous-entend lwn.net :
"Eric, of course, is increasingly frustrated that HIS patches have not yet gone in... "

Domage que linuxfr colporte ce type de news (c'est l'avis d'une personne et non ce qui resort de kernel-traffic par exemple).

Mon petit grain de sel.

Je connais pas Mandrake mais je pense que c'est en gros la meme chose que RedHat.

La RedHat est assez cohérente en dependance. Malheureusement elle a quelques points faibles.

Le système de paquetage de gère pas plusieurs versions de la meme librairie. C'est pas dramatique, on a seulement des truc du style : glib et glib0. C'est pour moi le plus gros problème.

Leur package kernel-header est réellement casse pied lorsqu'on installe un nouveau noyau depuis un tar.gz.
Il est égualement impossible d'installé deux noyaus via rpm (par exemple un noyau rawhide de test de un noyau RH7.2 de prod). ATTENTION, c'est possible mais en fesant des trucs imonde comme rpm --force.

Lorsqu'on construit une .rpm on ne peut spécifier un /usr/src/redhat alternatif pour compiler sous un compte non privilégié (fait changer le propriétaire de /usr/src/redhat).

Lorsqu'on désinstalle un package il reste souvent de fichier et il n'est pas possible de spécifier dans les fichier .spec les fichiers que génère l'appli et qui peuvent etre supprimé sans problème lors de la désinstallation.

Néanmoins; le tout est très cohérent et assez proche des standards. Par exemple, une foi (faut vraiment avoir que çà a faire) j'ai reconstruit une Rawhide depuis rien et uniquement en utilisant les src.rpm. Bien sur j'avais dejà une RedHat fonctionnelle.

j'ai refait les package filesystem, rpm, init, etc... en recréant la base de donnée rpm (/var/lib/rpm/ initialisé avec rpm --root --initdb). puis beaucoup de chroot.

C'est très long mais possible.

Enfin, je n'aime pas les choses cachées que fait kudzu et anaconda. Néanmoins ces packages se désinstalle sans perturber le système.

Mes distrib perso durent un bon moment et subissent beaucoup, beaucoup de mise à jour (je change de distrib pour changer de version majeur de noyau en général). Et je ne réinstalle JAMAIS ! Par contre je n'utilise qu'exceptionnellement le rpm --force ou --nodeps. Malheureusment, beaucoup, par facilité font des rpm --force et gueulent que çà marche pas après.

> mais que tu ne veux pas de X?
Avec RedHat tu peux virer X sans problème.

> Tu es obligé d'utiliser du --force partout pour déjouer les dépendances

Ben dans ce cas tu fais n'importe quoi mais t'es libre de le faire... Je sais qu'il faut taper beaucoup de commande rpm -e (sans --force ou --nodeps) pour supprimer correctement XFree mais c'est l'affaire de 10 minute maxi.

Et si tu as pas froid aux yeux des commande du type :
$ rpm -q -a | grep XFree86 | xargs rpm -q --provides | xargs rpm -q --whatrequires | sort | uniq

te donnera la liste des paquetages qui utilise XFree86*. Ceci peut grandement accélérer les suppression de paquage si tu ajoute ( | xargs rpm -e ).

> elle garde les lacunes liées au format de package qu'elle utilise...

C'est pas du .dep mais rpm est très correct. Surtout par rapport a ce qui existe sous les Unix commerciaux (ne parlons pas de Windows...).

Enfin, RedHat maintient les errata pour deux version majeur de RedHat . Actuellement c'est la 6.x et 7.x . Pour exemple, le dernier errata de la 6.0 date du 17/01/2002 pour une distrib de près de 3 ans.

> Reste Mandrake, plus forte base installee d'utilisateurs Linux au monde

A bon ...

> 100 % GPL

Ils ont pas XFree86, PostgreSQL, Apache, bind, etc... Pas facile d'être la meilleur distribe GNU/Linux sans serveur X11 (donc sans GNOME/KDE)...

> Mandrake disparaisse, car ce serait l'echec du 'modele commercial Open Source'

C'est les seuls dans ce domaine ? Donc RedHat, Suse, slack, Xiniam etc... ne sont pas des concurrents de Mandrake (commercialement parlant).

Question :
Il y a un service que propose Mandrake gratuitement contrairement à RedHat ?

Tu as des éléments pour dire que Mandrake fait plus de GPL que RedHat ?

Tu peux citer des produits développé et distribué par RedHat qui n'est pas GPL/LGPL ?


N'oublies pas que la distrib Mandrake etait au début une copie de la RedHat. Ils ont grandement profité du travail de redhat (phase d'installation/rpm entre autre).

être fan d'une distrib c'est bien, mais ne denigre pas les autres avec des arguments bidons.

> il est mignon.

Merci.

> 1) Tu as vu où que je donnais des ordres à Tosatti ? C'était une constatation

D'accord mais comment tu peux dire "il ferait mieux de ne s'occuper *que* de la branche 2.4".
- Tu connais son emploi du temps ?
- Tu as remarqué que dans les mailing-list kernel des gens se plaignent qu'il ne fesait pas son boulot correctement ?
- Tu croix qu'il a un salaire énorme pour s'occuper de la branche stable ?

Ben non, il fait çà gratuitement (ou presque) pour "la beauté du geste" et le bien de la "communauté". J'espère que tu comprends que je trouve le "il ferait mieux de ..." un peu hard.

> et une bête remarque.
Si c'est de l'humour/dérision alors je l'ai mal interprété.

> J'en déduis donc que si on est pas réalisateur de films on a pas le droit de trouver "Les visiteurs en Amérique" mauvais.

T'as raison et t'as tord car il y a une différence ENORME.
"Les visiteurs en Amérique" tu l'as vu et tu l'as pas aimé. Par contre, les patchs réalisés par Marcelo je ne les ai pas lu. Au mieux je peux apprécier les noms des variables, l'indentation, etc... Mais dire que j'aime ou que j'aime pas, je ne peut pas. Et à forciori sont travail et la pertinence de ces chois.

"Les visiteurs en Amérique" est pour un publique large (dont toi et moi) et ne demande pas de compétences particuliaires. Il est fait pour "divertir". Pour l'apprecier, il fait appèle à notre subjectif. J'aime ou je n'aime pas.

Et remarque qu'il y a certain film que je trouve très bien réalisé que je n'aime pas ...

Si on prend un documentaire scientifique sur la logique flou et bien je ne donnerai pas mon avis (surtout qu'il y a de forte chance que je m'endorme...).

La compilation n'est pas obligatoire. C'est uniquement pour controler que la partie "devel" est synchro avec ce que j'installe.

Si je suis amene a modifier un package je sais que mon installation est ok pour le recompiler.
Par exemple php sous RH n'est pas active avec --bcmath. Donc je refait un package avec une becane qui a tout (ou presque) pour recompiler. Idem pour le dernier trou de securite php (patch php*src.rpm -> compile -> nouveaux paquets). Et pour compiler php avec la conf RedHat, il en faut beaucoup des *-devel.
Mais ce n'est pas pour compiler avec "gcc -march=pentiumpro -DI686 -O8 -DRABBIT_MODE, etc.." pour gagne 0.2 % en perfo et 10 % de memoire en plus...

Tu te prends prend pour de la merde toi.

1- il donne des ordres a Marcello Tosatti.
2- il porte un jugement sur des developpeurs de haut niveau en estimant que Marcello n'est pas dans la meme categorie qu'Alan alors qu'il a ete designe par Linus (en consertation avec Cox, etc...).

Chapeau...

Tu devrais maintenir ta propre branche 2.4 si t'es si fort.

Juste.

J'ai teste slack (mouais) et debian (c'est vieux, c'etait la 1.3).

Avec la Debian c'etait un cauchemar. Mais c'est peut-etre mieux maintenant.

Puis un RH 4.2. Simple, coherent, facile la mettre a jour (si on a pas les doigts boudinnes). La je suis tombe amoureux de linux mais pas avec la slack ou la debian.

Perso, je trouve que certain se la pete avec la debian. Maintenant quand quelqu'un me dit utilise une debian je me mefie...
M'arrive meme de trouve les Mandrakiens pour sympatique malgres leur image de "windows touch".

Une defendeur de debian argumente :
- hyper facile a mettre a jour (RedHat 3 ligne de commande ; debian 1).

la belle affaire ...

RedHat (je connais moins les autres, desole) c'est :
- toutes les distribs disponibles sur leur site (de la version 1.0 a la rawhide).
- les distribs les plus recentes sur plein de mirror.
- tous les errata de toutes les distribs.
- la plupart de developpeurs utilise RedHat. La plupart des programmes recents sont package en rpm.
- une distrib particuliaire rawhide pour mettre a jour son systeme proprement (genre je veux evolution, il me faut gnome-core 1.4, etc...). ca demande beaucoup de ligne de commande et de compile, mais ca marche ...
- une base de donnee de bug.
- une base de donnee d'hardware compatible.
- la plupart des programmes commerciaux directement installable avec un rpm -i.

Voila, entre autre, ce qu'offre une distrib Redhat.
Attention, je ne parle que de distrib et non de ce que RedHat a apporte au free software de facon general.

Alors qu'un Debian m'evite de taper 4 lignes de commandes par jours en plus et me donne un air plus rebelle, je m'en fout.

PS : j'ai rien contre les utilisateurs de debian, mdk, etc...
Je parle beaucoup de RedHat car c'est la distrib que je connais le mieux (c'est pas forcement la meilleure :o) ).
Je m'en prends a CERTAINS utilisateurs de Debian qui se la petent...

Linuxfr fait dans le FUD et laisse passer des articles a la con !

Pour un boite commerciale, que faut-il faire pour satisfaire ces emmerdeurs de Linuxien :
- faire du code gratuite.
- le distribuer gratuitement (binaire i386, i686, etc, source ,iso)
- ouvrir son CVS aux autres (en ecriture surement) et interdiction de travailler dans la "discretion".
- ne faire payer aucun service.
- et toujours payer des employers.

n'importe quoi.

RedHat est dans le freeware depuis un moment et certainement l'une boite commercial les plus respecte pour son esprit freeware.

Les reproches minables de la news sont totalement naze.

He, les modulos, vous laisseriez passer une news de ce type contre Mandrake ?

PS :
La Redhat HA, PowerTools, DB (Postgresql) n'a jamais ete disponible en version ISO non plus et personne ne gueule. Ces distribs sont des versions specialise qui sont base sur RH x.x avec errata.

> PAQUET : c'est du français, ça désigne cela, et c'est court !

Juste.

> Concernant les rpm, il suffit de faire un rpm -ivh *.src.rpm...

Si ta procédure marche, il faut nous le dire !
Car pour ma part je serai, tres, tres surpris que ca marche et j'ai peur que tu envois des gens dans une impasse.

1- meme si le patch est appliqué dans /usr/src/redhat/SOURCES/php-4.0.6/ il ne sera pas utilisé car le paquet est construit depuis /usr/src/redhat/BUILD/php-4.0.6/ qui est un désarchivage de /usr/src/redhat/SOURCES/php-4.0.6.tar.gz (l'une des premières chose realisé par "rpm -ba /usr/src/redhat/SPECS/php.spec").

2- le .spec généré apres un ./configure ignora le patch. c'est-à-dire qu'il n'y aura pas de ligne :

Patch3: php-4.0.6-upload.patch
[...]
%patch3 -p1 -b .upload

dans le fichier .spec par exemple.
A moins que le patch patche aussi le systeme qui contruit de le fichier .spec (tres peu probable). Et le fichier .spec généré est en general un fichier minium qui ne tient pas compte des specificité des distrib. Un diff devrait te convaincre.

Ceci dit, ta procedure peut marcher si tu recrés /usr/src/redhat/SOURCES/php-4.0.6.tar.gz avec le patch. Mais dans ce cas, tu ne "respectes" pas rpm qui assure la "traçabilité" (archive d'origine puis les patchs appliqués et non une archive patché de partout).

Que ceux qui ne "maitrise" par rpm/apt ne panique pas, il suffit d'attendre les mises à jour par les distributeurs. Et sous Linux c'est beaucoup plus rapide que chez MS. Par exemple...

Tu devrais poser la question a mdk ? non

Afin, si tu te documentes un peu sur rpm, il est assez facile a partir du paquage .src.rpm d'ajouter le patch et faire de nouveaux .i386.rpm. Si t'as change de numero de release pour le paquage, un rpm -U doit marcher. Attention, /etc/php.ini d'origine est peut-etre renome php.ini.rpmsave.

> Apparement il est incapable de gérer l'afflux de patchs...

Vu la vitesse de developpement il se debrouille bien le gaillard pour tout faire !

> Je trouve étrange qu'il ne délegue pas un minimum.

Il delegue. Pour les personnes de confiance, il applique les patchs les "yeux fermes" (c'est le but de son nouvel outil dont j'ai oublie le nom).

> Linux is the property of Linus Torvalds.

Le nom "Linux" seulement. Libre a toi de faire un fork et d'appliquer les patchs plus vite que lui ... et au moins de facon aussi pertinante et sans te faire allume par les autres developpeurs...

L'article n'est pas mechant.

Mais que conclure ?
- Que les mainteneurs font mal leur boulot ?
- Que les distribs font mal leur boulot ?
- Que la "communaute" n'"emmerde" pas asser les mainteneurs pour des petits patchs.

Regarde le nouveau 2.4.18 et son nombre de correction apportes (la 2.4 a presque 14 mois !).

Pourquoi un bug-fixe n'est pas applique :
- pas le temps et mineur.
- pas propre.
- travail d'evolution en court la ou est applique le bug-fix.
- perdu ! etc...

Bref il y a plein de raisons bonnes et moins bonnes.

Mais la perfection n'est pas de ce monde.
Une comparaison avec la concurrence commerciale montre de les corrections de bug se perdent moins souvent et sont tres prioritaire.

tout est dans le titre.

> mais pour faire prendre conscience aux mainteneurs du noyau qu'il y a peut-être des patches a intégre.

Mouais.

Je crois qu'un noyau RH officiel (2.4.9) a pres de 150 patchs (la pluspart ne sont pas specifiques RH) et RH (comme d'autre) se balade dans la mailing kernel et ne demande pas mieux que leur patch soit integre au noyau officiel : Un patch de moins a maintenir :-> .

Quand on sait le temps que peut mettre un bugfix pour arriver dans le noyau officiel...

Serieux, l'article c'est du vent.

Linus est toujours deborde, les patchs sont disponibles pour ceux que ca interressent ...

Enfin, le noyau Linus est surtout une "infrastructure" (propre, multi-plateforme, stable, sure, etc...). Apres les derniers perfectionnements/optimisation (meme dangereux), le petit patch qui va bien, etc... ce n'est pas le boulot des developpeurs de Linux (je pense Marcelo, Linux, Alan).
Si l'experience montre qu'un patch RH (par exemple) est stable et indispensable Alan va le proposer. Il va pas faire genre : pas vu, pas pri.

Ou est le probleme ?

gnucash peut utiliser postgresql. Donc plusieurs clients a la foi.

Malheureusement, il faut Le client gnucash qui ne tourne que sous Linux.

C'est le freewere. Chaqu'un tire la couverture de son cote.

Et chaqu'un est libre de "copier" la couverture, et l'adapter.

Pas de problemes.

Il faut souligne le role de la license GPL. Il n'y aura pas de modification non visible ou de "ca c'est mon code".

C'est un directive faite pour les Avocats ? Il est vrai que les Europeens sont tres en retard dans ce domaine par rapport aux americains.

y a aussi RC si tu preferes.

> Y'a également toujours des personnes pour donner le bon dieu sans confession à chaque entreprise... Pas pour moi. J'ai tres tres mal pris le changement de licence de mono par Xiniam. Et mono est un projet que j'apreci peu car il est manifestement mene pour plaire au boite commercial (vivement qu'on pique le boulot de benevole pour ce faire plein de pognon) et suivre les specs MS. Enfin, Gnome est sous GPL comme Linux et gcc. Si la/les directions prisent ne plaisent pas il y aura un fork...

> Le gros problème, c'est qu'on ne sait pas qui dirige/décide vraiment le projet GNOME !

Personne ne dirige Gnome (ou tout le monde).

Les travaux de Sun, Wipro etc... ne vont pas dirige Gnome.
Il s'occuper de :
- gnome-core ?
- gnome-lib ?
- bonobo ?
- gtk+
- etc ...
- etc ...

Ils vont bosser sur une partie de Gnome comme le fait RedHat (pour Gconf/ Gtk+/ gnome-lib principale il me semble).

Bref, c'est toujours pareil. Des d'une boite annonce ca participation a un free software il y en a toujour pour crier au vol...

> Le G de GNOME, c'est bien pour GNU non ?

Oui. Et RMS a pousse un coup de gueule durant l'episode Gnome/mono.
Mais je vois pas de probleme pour le travail de Sun/ximian/wipro.

Il est hyper important de rester sous licence GPL et de ne pas passer a du BSD like comme la fait Mono (c'est mon point de vue perso).