Misc a écrit 6331 commentaires

> Quel est l'intérêt de faire des tonnes de forks d'une distrib ?

Plus facile, plus rapide.

Quand tu fait ta distro dérivé, tu n'as pas à rendre de compte à d'autres, tu n'as pas à discuter les mérites techniques des patchs que tu appliques ou ce genre de choses, à subir les contraintes dont tu n'as sans doute rien à faire dans le cadre de ton projet, etc.

Bien sur, si j'était mauvaise langue, je dirait aussi que ça flattes l'ego mais bon, faut reconnaitre que ç'est une motivation comme une autre, et qu'il y a pas de mal à ça.

Et dans la mesure ou canonical pousse tout pour les forks ( http://www.zarb.org/~misc/ubuntu.txt ), afin de devenir une base semblable à la lsb ou au dcc, le nombre important de dérivé à sa place dans la stratégie.

Et en plus, ça permet d'éviter de maniére élégante les tensions et les frictions au sain de la communauté, tel que mark shuttleworth le décrit ( http://www.markshuttleworth.com/archives/56/ ), pour éviter d'aboutir à la situation actuelle qui semble plomber debian depuis l'extérieur.

> L'éducation c'est la manière de fideliser les plus jeunes.

C'est sans doute pour ça que les linuxiens poussent le libre dans les universités et vers les . Sauf que, quand c'est microsoft, c'est mal, quand c'est canonical/ubuntu, c'est bien ?

( ou j'ai loupé le dernier mémo du parti au sujet du stage de DoubleThink )

Faut pas se leurrer, Microsoft fait ça parce que de toute façon, les étudiants le pirateront ( je doute fort que la fac ai changé depuis que j'en suis sorti ).

Et si les étudiants utilisent windows et pas un système libre, c'est sans doute pour les mêmes dizaines de raisons que le reste du monde ( raisons valides ou pas valides, c'est pas la question ). Pas parce que Microsoft leur file l'os gratuitement.

Bien sur, quand le seul argument qu'on arrive à expliquer aux gens, c'est la gratuité, je comprends que ça foute un coup au discours.

> C'est pourquoi debian backporte les patchs de sécurité pour sa version stable si
> je ne m'abuse.

Oui, ç'est exactement ça ( ce que presque tout le monde fait, pas que debian d'ailleurs ).

Perso, en tant que packageur, je suis pas mécontent.
Je partage parfaitement les craintes de ce dev ubuntu ( http://robitaille.wordpress.com/2007/01/24/will-linspires-cn(...) )

Et ça, parce que c'est déja arrivé, parce que prendre des binaires à gauche et à droite, c'est pas propre, et que pour es backports, il y a déja une infrastructure en place, suffit juste de demander ( en tout cas, moi, j'ai fait les backports qu'on m'a demandé en bonne et du forme ).

Et aussi swfdec :
http://swfdec.freedesktop.org/wiki/

Le dev actuel de swfdec n'est pas vraiment tendre avec gnash : http://www.advogato.org/person/company/diary.html?start=30

Et ça marche sur ppc ( os X ), mais pas sur linux/ppc, ce qui est différent ( et à ce rythme la, ça ne marche pas non plus sur les autres archis, genre sparc, etc )

Ça marche aussi sur x86_64, via le plugin nspluginwrapper (
http://gwenole.beauchesne.info/projects/nspluginwrapper/ ).

Les paquets plf ( http://plf.zarb.org ) du paquet flash ( les rpms pour mandriva ) intégre ça directement, il suffit juste d'installer le paquet sur son x86_64 et voila.

Récement, j'ai testé swfdec et gnash, et je doit reconnaitre que c'est assez impressionnant de voir le chemin parcouru. Il semble que swfdec puisse bientot lire les videos ( style youtube et co ), vu que la version 0.4.1 supporte le flv, et gnash en version dev aussi.

$ svn log -r 106015 svn+ssh://svn.mandriva.com/svn
------------------------------------------------------------------------
r106015 | blino | 2007-01-08 16:47:27 +0100 (lun, 08 jan 2007) | 1 line

Create secondlife
------------------------------------------------------------------------

Et on remercie blino pour ça \o/

> surtout quand on connait les liens etroits entre ATI & Microsoft

Et quand on connait pas ?

ou bien, (parce qu'on cause d'université ), on bosse et on va pas glander à clavarder avec le reste du monde :)

Dans le but de contourner les filtres de types bayesian, les spammeurs se sont mis à inclure du texte venant des listes de diffusion publique.

Pour le fait que ça soit en rapport avec le libre, je pense que c'est un hasard. Forcément, sur 1000 spams de ce type, tu va finir par en trouver ayant un vague rapport avec le sujet, et tu va te dire "mais comment ils ont fait". Ben comme pour les 999 autres ou tu ne te dit rien, c'est un hasard.

> Il n'y a vraiment que dans la communauté du libre où on aime autant
> réinventer la roue

vraiment ?

j'ignorais que yahoo messenger + msn messenger + icq messenger + aol messenger, était soit du libre, soit exclus de la réinvention de la roue.

J'ignorais aussi que les 45 types de jeux différents de stratégie, de fps, de foot et autres mutualisent grandement le code. Que nombreuses bases de données proprios ( oracle, sybase, sqlserver ) faisaient de même, tout comme les nombreux constructeurs de hardware.

Non, c'est pas ironique.
j'ai pas dit que je suis pour cette solution, mais c'est ce qui résoud le probléme actuellement.

Soit tu as une seule plateforme ( windows, osX ) homogéne, soit tu en as plusieurs avec des différences significatives ( distribution linux ).

Prenons les différences entre les distributions :
- les outils d'administrations. Dans un souci de simplification de la doc, il faut que cette partie soit unifié. Pas question de dire "si vous avez XX, ç'est tel appli, sinon, c'est tel autre".
- les logiciels présent, aussi bien leur nom, que les versions.
Si on continue à laisser les différences entre les versions, il y a des risques d'incompatiblités => donc on uniformise, au moins pour les libs de base.
Ce qui, par le jeu magique des dépendances, fait que tout le monde à la même version de gnome et de kde, compatible de façon binaire.

Du coup, si 75% des paquets sont les mêmes, si les outils d'admins sont les mêmes, les seules choses qui changent, c'est les fonds d'écrans ( super ), l'installeur, et les configurations par défaut ( modulo la compatiblité avec la norme ).

Soit grosso modo, les trucs que l'user peut déja changer par lui même. Et il y a plus aucune différence dans les distributions, donc autant ne garder qu'une seule distro.

Tu veut dire "merci, ça confirme que j'aurais du vérifier avant de troller, et désolé d'avoir dit n'importe quoi, promis, ce coup ci, la prochaine fois, je reflechit avant de parler" ?

La différence entre une page web et un mail, c'est qu'une page web, pour être potable, ç'est fait par un professionnel du sujet, qui sait quand mettre en gras, quel couleur sont corrects, et qui passe du temps dessus.
La page web a un design, une charte graphique, et une raison fondamental de se distinguer des autres, ainsi que du vrai contenu à organiser via le design et la mise en forme.

Un mail n'a pas tout ça. Et si c'est pas le cas, c'est plus un rapport qu'un mail, et dans ce cas, il faut utiliser des outils prévus pour, genre un traitement de texte, un tableur.
Pousser tout les fonctionnalités d'une suite bureautique dans un client mail, c'est du bloatware.

Moi, je lit mes mails en format texte, parce que tout les mails que j'ai recu, à l'exception de 2/3 exceptions ( des mails envoyé par svn::notify ), n'ont pas du tout bénéficié des couleurs et de la mise en forme. Donc, ç'est grosso modo inutile dans 90% des cas.

Et encore, je ne parle pas du fait que ça prends 2 à 4 fois plus de places, que ça fait bosser le filtre à spam de maniére bien plus conséquente, qu'afficher une page web prends plus de ram que d'afficher du texte, et ce genre de choses.

Gaspiller des ressources pour un gain nul, je trouve ça dommage.

Bien sur, tu peut aussi continué à sortir le même argument infondé "ça sert pour le web, donc ça doit servir partout" ( car pour le moment, dans ce thread, c'est le seul argument que j'ai vu de ta part ). Je pense qu'on devrait mettre directement un éditeur complet comme dreamweaver dans kmail, aprés tout, ça sert sur le web, donc ça sert aussi pour le mail.

> Ebfin, bon, honnêtement, il y a un certain nombre de distributions l'inux
> qu'on peut négliger tellement leur diffusion est confidentielle

De la même façon qu'on peut négliger les os confidentielles comme les distributions linux, d'un point de vue général.

Ce que fait autopakage en installant dans /usr/, non ?

La solution est pourtant simple : 1 seule distro linux de base pour tous.

Ce que d'ailleurs canonical essaye de proposer, comme expliqué ici : http://www.zarb.org/~misc/ubuntu.txt .

Aprés tout, un paquet basé sur une kubuntu devrait tourner sur une edubuntu, et sur les autres dérivés, car le core est commun.

> Euh, t'a entendu parler de macosx ?

Oui, j'ai entendu parler de osx.

Mais par contre, je voit pas en quoi c'est comparable.
Il y a un seul macos X, fait par un et un seul éditeur. Si tu veut comparé osx à toutes les distros linux, tu fait une erreur. Compare plutot à un distribution, par exemple, rhel.

Comme apple, rh propose un systéme avec une api figé, et ou tu peut facilement installé des binaires, sans passer par la lsb. La preuve, les paquets de oracle et compagnie sont souvent prévus pour rhel.

Et si selon toi, osx est la panacée, tu peut me dire quel différence entre "le rpm s'installe que sur la distribution prévu pour" et "le .dmg s'installe que sur macosx"

Il n'y a pas de systéme qui s'installe sur XP et Os X, qui sont quand même les 2 plateformes couvertes par les offres commerciales actuelles de la fnac.

Et au passage, les .dmg d'osX ne gére pas les dépendances ( vu que c'est des trucs fournis tout prés) donc la gestion des mises à jours de sécu, c'est pas aussi simple que sur un linux, les composants sont peu liés entre eux donc de la redondance, ce qui entraine divers problémes, comme perte d'espace disque, perte de mémoire vive ( vu que les libs sont totalement séparés ).

gcc ne fournit pas des tarballs binaires de gcc à des fins de bootstrapping ?

En général, soit je fait le paquet, et je l'uploade pour les autres, soit je tire un trait dessus.

C'est comme les fonctionnalités dans les versions svn/cvs. le code est dispo, mais pas facilement utilisable par un utilisateur, et il faut attendre que le dev finalise le code pour l'utiliser, tout comme il faut attendre que les packageurs packagent le tarball pour l'utiliser.

C'est une simple question de compétence. Soit l'utilisateur sait faire, soit il dépend des gens qui le font pour lui, rien de nouveau depuis les débuts de l'info.

Toute les normes du monde ne vont pas changer cet état de fait, et je pense que le systéme de distribution n'a pas avancé vers les méthodes actuelles par une incompétence généralisé des gens impliqués ou le plaisir de ne pas correspondre aux utilisateurs de bases, mais plus qu'il s'agit de choix mûrement réfléchis, basé sur l'expérience des "systémes" précédents.

La priorité de Microsoft pour imposer windows, ce fut de permettre un developpement commercial riche décentralisé, afin de faire jouer la compétition.
Donc , le systéme a été fait en conséquence, car les dirigeants de microsoft savait pertinement qu'ils n'avaient pas les ressources pour tout offrir.

Pour les distributions linux, ce fut le contraire. Il y avait un énorme potentiel d'intégration, grâce au respect des 4 libertés, et donc le choix du systéme actuel est arrivé naturellement.

La distribution de binaire, c'est qu'une partie des problémes par rapport au reste ( les tests, l'intégration correct, la gestion des dépendances, la gestion des versions différentes, le choix de la plateforme de référence pour le dev, l'impact des patchs des distributions, les remontés de bugs et leur reproductibilité via un systéme centralisé )

Rien que ce dernier point me fait rire d'avance.
User A télécharge le binaire, le lance, et il y a une erreur , le dev teste, il ne la voit pas, il va dire que ça vient de la distribution. Possible, aprés tout.
Ok, l'user A va aller raler sur la distro, la distro va prendre le paquet qu'elle distribue, ne reproduit pas, et va dire "c'est le type qui a fait le binaire, on fait pas le support de ça".

Résultat des courses, le seul à l'avoir dans l'os, c'est l'utilisateur, car ni le dev, ni la distribution n'ont fondamentalement tort, même si, dans mon exemple, je pense que c'est au dev de s'occuper du probléme. Mais ils n'ont pas du temps à perdre pour faire des tests sur toutes les plateformes possibles.
Bien sur, on peut imaginer se limiter, mais ça serait comme avoir un systéme à 2 vitesses, se dire que que "90% des linuxiens, c'est suffisant", c'est comme dire "90% des os suffisent, je vais donc faire du wmv"

Et je pense aussi qu'une grande partie des devs se contentent trés bien d'avoir le code source, et de laisser les autres faire la distribution et le packaging.

Trés franchement, plus je voit ce genre de choses, plus je doute que ça arrive.

Pour le moment, la seule façon dont ce genre de choses est arrivé est
1) une intégration proche de zéro avec la plateforme ( tarball binaire )
2) un monopole sur le produit sous jacent ( windows )

Imaginer que toutes les distributions linux et tout les distributeurs vont se mettre d'accord et sacrifier leur indépendance technologique pour respecter une norme arbitraire, c'est surréaliste.

Les distributions innovent, changent des trucs. Soit elles vont renoncer à ça, et je pense que ça sera le début de la fin, soit elles vont continuer à le faire, et les distributeurs vont être moins intégrés.

Exemple tout con ? Les scripts d'init parrallléles de Mandriva, à mettre en concordance avec upstrart chez ubuntu. Les 2 distributions devraient ne pas utiliser ça parce que ç'est potentiellement incompatible avec la lsb ?
Et donc, dire non à leur utilisateurs qui réclament ça depuis longtemps ?

Ou le faire, et donc avoir des bugs subtiles causés par les softs qui ne sont pas adaptés, ni testés avec ça ?

Car il ne faut pas oublier une chose. Avoir une norme, ç'est bien. Mais ça implique aussi de faire des tests sur chaque plateforme, et chaque distribution. Sauf à vouloir proposer des softs non testés, en plus d'être moins intégré.

De plus, comme j'ai déja dit dans la discussion précédente sur le sujet, ça va aussi limiter séverement les developpeurs dans l'usage des nouvelles libs.

Et ça, je pense que ça va faire grincer des dents.
On va se retrouver avec le probléme sauf qu'au lieu d'avoir des utilisateurs frustrés, ça sera des developpeurs frustrés. Frustrés de devoir garder des vielles libs pour faire du code pour les utilisateurs, frustrés de ne pas pouvoir utilisé le dernier truc trop fort de gstreamer, de cairo, car non dispo dans la norme.

Et trés franchement, entre frustrer les gens qui codent et font avancer le libre, ou les gens qui se contente d'utiliser, mon choix est vite fait, surtout pour un truc aussi futile que l'utilisation du dernier soft à la mode.

Et je ne parle pas du fait que si personne n'utilise les libs, les bugs ne seront pas remontés, donc le logiciel libre ira moins vite, avec du soft de moins bonne qualité, mais... avec des softs installables directement. Toute ressemblance avec la situation actuelle sur un os propriétaire est fortuite.

Ce sujet a déja été ressassé moult fois.

J'aime pas me repeter, donc je te reporte à ce test d'autopackage : http://linuxfr.org/comments/787791,1.html

Pour faire short autopackage marche, mais il faut quand même utiliser le systéme de gestion de la distribution, il y a pas de vérification des signatures, pas de systémes de gestion des mises à jours, et ç'est relativement fragile et décentralisé.
Grosso modo, ç'est comme sur windows. Si les gens veulent avoir les mêmes problémes que sur windows, pas besoin de venir pousser ça sur les os qui font les choses différements.

Comme beaucoup de monde, je voit que la personne ayant posté ce journal confond le conseil de l'europe ( http://ww.coe.int ) et le conseil de l'union européenne ( http://www.consilium.europa.eu/cms3_fo/showPage.asp?id=348&a(...) ).

C'est d'ailleurs même marqué en haut de l'article de wikipedia francais : http://fr.wikipedia.org/wiki/Conseil_de_l'Europe