Bruno Vernay wrote:
> malet jean-luc alias cityhunter wrote:
>
>> Bruno Vernay a écrit :
>>
>>> malet jean-luc alias cityhunter wrote:
>>
> ...
>
>> bon je vais arrêter là car ma rancoeur envers ces évolutions ne font
>> qu'envenimer cette liste..... ce qui n'était pas mon but....
>> @+
>> encore désolé ^_^
>>
> Si je comprend bien, c'est plus le marketing que les
> distrib/RPM/desktop en elle même qui t'énerve.
ben en fait ce qui m'énerve c'est que certains programeurs ne
connaissant que trop peu le background unix (je leur en veut pas de leur
non connaissance mais de ne pas avoir cherché) sautent sur le premier
argument marqueting d'une pub à deux balles pour réinventer la roue tout
en créant une rupture avec le monde unix.....
il m'a fallu 2 ans de bash au niveau "maintainer" de distrib basée sur
sources pour voir la rupture entre le monde unix et les desktops actuels....
> Dans ce cas pourquoi ne pas parler plus des avantages de Sourcemage,
> plutot que de donner envie à certains utilisateurs Linux de retourner
> sous des solutions propriétaires ?
je m'occupe de sorcerer, je ne parlerai pas pour les gas de
sourcemage..... sorcerer est une distrib orientée source comme gentoo,
sourcemage, lunar-linux. Le principe est de télécharger les sources sur
le net automatiquement, les configurer suivant vos souhaits, et les
compiler/installer.
parmis les choses que je trouve bien sous sorcerer c'est la
configuration des packages : lors de la création d'un "spell" (on
utilise l'alégorie de la magie donc les sorts sont dans des grimoires,
on "cast" [compile/install] un spell, on demande aux "augur" de nous
donner les informations sur le système, et on dispel les sort) on
essaie de trouver quels sont les paquage requits, optionels, ainsi que
les options de configuration. À partir de ces informations on va créer
le spell, avant la compilation proprement dite il y a une phase de
configuration qui ne s'éffectue qu'une fois (sauf si redemande) pendant
laquelle l'utilisateur va choisir ses options... il est ainsi possible
de compiler Vim avec support de X ou non, de choisir d'activer telle ou
telle fonction dans un soft etc.....
ensuite viens les fonctions "d'auto restoration de la box" ie sorcery
(la suite d'outils de sorcerer) va en fin de compilation ou à la demande
éffectuer un certain nombre de tests (configurable) sur le
filesystem.... si tous les test sont passés avec succés, les archives
des sorts upgradés/dispelé sont supprimées, sinon les sort qui ne
passent pas les tests sont recompilés...
ainsi imaginons qu'une upgrade de la libXXX vient d'être effectuée, le
package P est lié avec cette lib. lors d'une upgrade la libXXX est
d'abord saugegardée ce qui garantie que P fonctionnera toujours même si
la recompilation de P échoue.... P est recompilé et donc profite
automatiquement de la mise à jour de libXXX.... les upgrades sont donc
facilité et rapides! il n'est pas rare d'avoir la nouvelle version dispo
le lendemain de son anonce sur freshmeat.... vous voulez pas concerver
la nouvelle version car elle est pire que l'ancienne? demandez
l'ancienne! VOUS choisissez! pas le maintainer de votre distribution.....
les tests disponibles/effectués sont :
find : trouver le fichier
md5sum : vérifier que le fichier n'a pas été modifié (bien que n'étant
pas une prévention absolue contre les rootkits.... cela aide bien)
ldd : vérification des exécutables pour trouver d'éventuelles dépendance
manquantes
la vérification peux se limiter aux executables, aux executables plus
leurs données, aux éxécutables plus données plus headers, à l'ensemble
des fichiers installés (hors /etc)
ce que j'aime bien c'est aussi la facilité d'administration.... bon
d'accord, ici pas d'outil GUI.... (on a pas le temps d'en faire et ils
ne serviraient pas à grand chose dans notre cas) est-ce un mal? pas
forcément, car la configuration se fait super facilement... ceux de
cette liste qui connaissent les scripts /etc/init.d seront impréssionés
par ceux de sorcerer : nous essayons si possible d'avoir des scripts
simple, clairs, précis, qui ne font appel à aucun fichier de
configuration externe.... ce qui signifie que si vous avec un problème
avec par exemple le réseau il suffit d'aller dans /etc/init.d/networking
pour corriger le problème.... pas de jeu de cache cache à chercher tel
ou tel fichier..... si vous voulez rajouter une interface réseau copiez
le script modifez les lignes qui vous intéressent et c'est fait.... vous
n'avez qu'un seul endroit à chercher.... et cerise sur le gateau vous
allez apprendre à utiliser les bon outils.... par exemple vous
comprendrez en 2s que fixer une ip à une interface se fait avec
ifconfig, que changer la route se fait avec route.... vous savez dès
lors modifier une configuration réseau de manière temporaire.... sans
avoir à toucher aux fichier de configuration..... de même un script
défectuex est facilement fixé car comme je l'ai dit tout se trouve dans
le script.....
ensuite il n'y a dans /etc que les fichiers nécessaires pour les
packages installés.... ce qui facilite grandement la tache de trouver le
fichier à modifier...
ensuite y'a le dispell.... comme tout gestionaire de package, les
dépendances sont installée lors d'un cast.... mais qu'en est il lorsque
l'on désinstalle le package? sur la plupart des distrib binaires elles
sont laissées sur sorcerer on va desintaller récursivement, ie on va
demander à l'utilisateur s'il veut garder ou non.... jusqu'à ce que
l'utilisateur ne veuille que garder, bien sur on ne propose que les
package qui ne sont pas demandé par d'autres à concerver..... installez
gnome un jour revenez comme avant le lendemain.
nous essayons de garder une conformité stricte avec les standard unix et
en particulier avec le LinuxTree.... ce que ne fait pas mandrake....
ainsi les binaire nécessaires pour récupérer un système sont dans /bin
et /sbin les binaires pouvant se trouver sur un nfs sont dans /usr/sbin
et /usr/bin etc pas de fichier binaires installé par sorcerer dans
/usr/local/bin qui je le rappelle sert au SA pour tester un package
avant déploiement....
ensuite viennent des argument de développement, puisque nous nous basons
sur les sources, puisque nous avons une arborescence classique, le
dévelopement est simplifié... pas de surprises... de plus tous les
outils de compilation et headers sont installés.....
comparé aux scripts d'installation gentoo, notre API de script vient
d'atteindre un niveau de simplicité/qualité plus que facile.... un peu
de connaissance en bash pour les scripts les plus compliqués suffit....
ajouter un logiciel pour votre utilisation est facile et souvent se
limite à donner la version les urls et les dépendances.....
il y a quand mm des cons.... sorcerer est plus difficile à aborder que
Mdk/Knoppix/Kaella etc.... mais sorcerer vous donne les bonnes bases des
systèmes unix.... je peux passer sur n'importe quel linux sans avoir
aucun problème de configuration car je sais quels sont les outils qui
seront utilisés, un find /etc --exec grep -Hn XXXX {} \; me fournira
rapidement les infos voulues.....
sorcerer prends aussi plus de place disque à cause des headers/packages
de devel installés par défaut..... mais par exemple il y a possibilité
d'archiver automatiquement la doc des packages....
> Le marketing est là, il est plus efficace de l'utiliser que de lutter
> contre.
> Il ne faut pas se tromper de cible, les contributeurs de Mandriva ne
> sont pas ceux qui annoncent "Mdk=XPkiller". C'est plutot le fait des
> medias et de ceux qui veulent plein de connexions sur leurs forums !
> Malheureusement ta "rancoeur" fait du mal aux contributeurs et pas à
> ceux qui formulent ces annonces à l'emporte-piece.
peut-être mais regardons les choses en face : combien de packages ne
sont pas installés correctement sous les mdk? beaucoup trop.... combien
de distribs donnent les bonnes bases à un utilisateur, lui permettant
ensuite de résoudre ses problèmes rapidement? combien de distribs ne
piègent pas l'utilisateur dans leurs configuration propriétaires? sous
debian ou RH ou mandrake pour ne citer que celles là, il me faut sortir
ma connaissance bash pour comprendre leurs choix et réparer le problème....
ce que je reproche aux contributeur (enfin pas tous car un grand nombre
fait un travail formidable) c'est de ne pas tenir compte de l'histoire
d'unix.... actuellement il existe un focé entre des projets comme
kde/gnome et le comportement d'unix.... mais ce qui est encore plus
terrible c'est que l'utilisateur en subit les conséquences.... car il va
devoir apprendre deux comportements différents car qu'on le veuille ou
non les outils unix resterons....
>
> Par exemple http://www.webstandards.org/, qui lutte pour le respect
> des standards du Web aurait facilement pu se contenter de fustiger
> MS-IE. Mais ils ont choisi une voie plus difficile qui est celle de la
> collaboration et le résultat est bien plus efficace.
^_^ javascript javascript.... combien de site ne fonctionnent que sous
ie? oui on peut "copier" ie mais en le faisant on s'expose à la
dictature de m$ on s'expose aux brevets on s'expose à toutes les
saloperies.... qu'en sera-t-il si un jour m$ décide que le comportement
"standard" d'un browser c'est d'accepter les uploads ftp sans connection
préalable? (faille de ie datant de 1995 qui fait que la méthode de
hacking la plus en vogue actuellement est de chercher un pc avec ie qui
tourne et lui envoyer un fichier en utilisant du ftp..... ie accepte ce
fichier sans broncher.... reste à trouver comment executer le vers....
ce qui est la partie la plus facile.....)
faire des "compromis" c'est bien.... as-tu déjà vu une conf de stallman?
j'en ai vu une vidéo.... avant j'étais comme toi.... je me disais
"OpenSource == logiciel libre" maintenant je ne peux plus.... car en
acceptant de perdre une des 4 libertés je détruit les 3 autres....
de mon point de vue la grosse erreur des distribs c'est d'avoir cherché
en premier à faire les GUI de configuration et en fonction de ces choix
technique d'avoir créé les scripts qui vont avec.... tant que cela
marche c'est bien.... quand il y a de problèmes.... c'est la cata......
les outils de configuration auraient dû être créé pour s'adapter aux
fichiers/comportement existant et pas l'inverse....
ainsi kde/gnome auraient du utiliser les .xinitrc / .xession pour le
lancement des applications utilisateur et stocker les sessions....
l'utilisateur y aurait été gagnant.... je me souviens qu'une fois kde ne
pouvaient pas se lancer car il s'été mal arrêté suite à un crash
système.... un éditeur de texte, modifcation de .xinitrc avec un ajout
--safe à la ligne Startkde voir commenter les lignes lançant les
applications à restaurer aurait été plus élégant.... mais au bout de
10min de recherche je me suis résigné à solutioner le problème par un rm
-rf .kde
un autre point me vient à l'esprit... le clavier de kde (je sais pas si
c'est toujours vrai....) au lieu d'améliorer le clavier de X (qui pour
ceux qui ne le savent pas permet d'avoir 70-75% de l'utf16 dispo à
partir d'un clavier de 104 touches [je ne souviens pas du chiffre exact
mais c'etait de l'odre de 12000 charactères]) ils ont recré le leur....
dispo sous kde uniquement! quid du partage? il y a dans kde et gnome de
bonnes idées de bons softs.... mais les utiliser c'est devoir utiliser
gnome ou kde obligatoirement.... on parle du propriétaire, des standarts
fermés.... quel chemin reste-t-il à parcourir entre une application qui
t'en impose d'autres sans relation (je n'ai que faire de kwrite, kate,
gedit....) et ces derniers? bien sûr on dira "c'est sous gpl, tu peux le
modifier...." oui mais à quel prix? une fois que le logiciel sera
tellement dépendant des "suite de gestionaire de fenêtres" comment
poura-t-on raisonablement les en sortir? si les programeurs de kde ou
gnome avaient décidé de choisir la carte des applications non liées avec
un WM non liées à un projet de fagocitation on aurait actuellement
beaucoup beacoup plus de choix de logiciels.... une bien meilleur
interopérabilité entre eux... (et pas une interopérabilité entre
application d'une même suite....) heureusement tout n'est pas noir....
certains créateurs de logiciels (une grosse majorité) refuse la
fagocitation.... des projets tels qu'ImageMagick, fluxbox.....
par exemple
MALET JL
