> Nul part dans l'esprit du libre on ne parle de participer upstream.
Fraternité parce que chaque utilisateur a la possibilité de partager le programme avec le monde. RMS
Le libre met en avant la valeur de partage, la meilleure façon de partager c'est de mettre les connaissances et les compétences en commun. Ce n'est pas toujours possible (ie: travailler avec le dictateur Ulrich Drepper) mais c'est souhaitable. J'aimerais que tu nous expliques comment bosser dans son coin et balancer quelques patchs dans un obscur recoin d'un serveur respecte l'esprit du libre.
Si on lit le texte de la GPL, la GPL précise que tu dois fournir les outils nécessaires à la compilation et au packaging du binaire fourni. Si je fournis un paquet deb ou RPM d'un logiciel libre, je dois derrière fournir les outils pour arriver au même résultat (la recette du paquet, les outils de création de paquet etc ...)
L'esprit de la GPL est de supprimer tout entrave possible au partage et de faciliter celui-ci, or on peut pas dire que Canonical fait de gros efforts à ce niveau-là
> L'esprit du libre est respecté par Canonical
Non, seule la lettre est respectée, c'est ce qui est reproché à Android, et certains projets qualifiés de faux-pen source, le projet est plus fermé que le code. Avec son dictateur lunatique, Ubuntu est pas loin d'être un projet faux-pen source.
> Au fait c'est pas Red Hat qui a abandonné le desktop parce que pas assez rentable
Et qui continue de payer au moins une vingtaine d'ingénieurs pour bosser à temps plein dessus. Hein, si tu regardes le joli graphique du monsieur, tu verras beaucoup de rouge.
> s'appuie sur la communauté de manière désintéressée et pas du tout parce que ca leur permet de stabiliser leur belle distrib proprio.
Le projet Fedora repose sur un pacte entre la communauté et Red Hat, Red Hat paie des gens pour bosser sur Fedora, fournit une infrastructure etc, la communauté apporte des développeurs/testeurs/empaqueteurs/traducteurs/graphistes etc ... Red Hat gagne une base solide et innovante pour ses produits et la communauté une infrastructure et une distribution semi-communautaire.
Si au départ, Ubuntu/Fedora c'est le même combat, Ubuntu est devenu un despotat éclairé: une personne qui dirige tout et qui nomme même les membres du conseil "communautaire" (noter le choix pertinent du nom), Fedora est devenu une monarchie constitutionnelle britannique, un Fedora Project Leader nommé par Red Hat dont le rôle est principalement représentatif (et sert de trésorier) ==> le résident général, mais qui est dirigé par des différents comités élus par les contributeurs (le fesco ===> le premier ministre canadien qui détient le pouvoir réel).
Debian, c'est la démocratie athénienne, tout les contributeurs sont égaux (et c'est très bien !) et ils sont totalement indépendants.
Il y a communautaire comme debian, gento & cie, il y a semi-communautaire comme fedora, openSuSE et il y a pseudo-communautaire comme Ubuntu.
Je suis d'accord que se tourner vers le service était une bonne idée, mais je ne crois pas qu'il était nécessaire de racheter Edge-IT ou Linbox pour ça. Surtout quand la boite est elle-même fragile financièrement parlant.
Certes, Linbox a apporté dans sa corbeille les futurs MDS et Pulse2 (qui sont de beaux produits) mais Mandriva a été incapable de les faire fructifier au niveau commercial. C'est même le principal malheur de Mandriva, ils avaient une distribution pas trop mal foutu, de bons ingénieurs (malgré un encadrement de merde d'après ce qui se dit), une bonne réputation (en 2003, c'était comme ubuntu aujourd'hui) mais ils n'ont pas été foutu de commercialiser ça.
Mais Edge-IT c'est vraiment le truc qui sert strictement à rien, la boite était en cessation de paiement, endettée jusqu'au coup et sans intérêt (même pas un carnet clientèle bien rempli comme Conectiva). D'ailleurs, si tu regardes sur societe.com, Edge-It n'a fait qu'accumuler les pertes (et servira de veau expiatoire pour regrouper les dettes du "groupe"). Si je devais justifier le renvoi de Bancilhon en deux mots, ce serait "Edge-IT".
> Et toi tu as bien répété ton discours d'anti-Ubuntu...
Oui, quand on dit quelque qui ne va pas dans le sens des fanboys on est forcément un anti-xxx [:flu1]
> Tu peux le remonter upstream si ça te plait, eux n'en voient pas l'intérêt (le retour sur investissement), et alors? Ils mettent les sous où ils veulent, tant qu'ils respectent la licence (et ils la respectent)
Ai-je dit le contraire, je dis juste que la dichotomie entre le discours de Canonical ("on est des gentils pro-libre, c'est les autres qui veulent pas nous suivre") et les faits ("on fait tout pour partager les moins possible") ça rejaillit sur l'image de la boite sur son discours. Hein, j'ai pas entendu beaucoup de personnes ici féliciter Novell pour leur contribution pourtant énorme au libre: quand c'était SuSE: Yast sapusaipalibre, mono saiunetechonmicrosoft, novell sailemalilzonpaktiséaveksatan etc ...
Voilà, tu peux piocher dans le code libre, respecter la lettre de la licence mais si tu n'en respectes pas l'esprit (le partage des connaissances, des compétences etc ...) faut pas t'étonner si tu n'es pas vu d'un bon oeil par la communauté. Hein, Canonical c'est pas le caliméro du libre qui est le seul (l'unique) à s'en prendre plein la gueule.
Quand Canonical deviendra un acteur du libre digne de ce nom, je serais le premier à les applaudir. Je les ai applaudi quand ils ont libérés launchpad (auraient-ils libérer launchpad si on ne les avait pas fait chier ? je ne crois pas).
> Effectivement. C'est juste parce que c'est la plus utilisée, est les jaloux tapent sur ce qui marche mais qu'ils n'aiment pas.
Faudrait changer d'arguments, t'as un mec qui présente des stats qui contredisent le discours de canonical, donc c'est forcément des jaloux.
> Tu veux dire, genre Debian qui fait des .deb alors que tous les autres font des .rpm?
Non, genre on réinvente la roue tout les 6 mois pour au final reprendre ce que les autres ont fait.
Actuellement, tout le monde bosse sur gnome-shell pendant que Canonical bosse sur Unity ===> personne chez eux ne s'est demandé si ça n'était pas pertinent de collaborer avec les gars de gnome-shell (hint: ça repose sur les mêmes technos, et gnome-shell est extensible).
C'est toujours la même chose avec eux, le pire c'est que ça leur est plus nuisible qu'autre chose
> dernièrement on m'a traité d'employé Microsoft car j'ai défendu Microsoft
Plus haut, je suis à la fois employé par Novell et Red Hat ... (j'attends toujours ma double paie) Pourtant, j'en ai rien à branler de Red Hat comme il y a des gens d'ubuntu qui s'en branlent de Canonical.
Allez, je vais rajouter une calomnie à ta collection, cadeau de la maison ;)
<calomnie>Tu défendrais pas Canonical parce qu'ils ont acheté une licence H.264, hein on SAIT tous icitte que t'as vendu ton âme au dieu pognon (saimal l'argent !!!!) et au dieu MPEG (à ne pas confondre avec le dieu meuporgue)</calomnie>
J'utilise Debian à titre personnel et professionnel (et même ubuntu - à contre-coeur)
> Nombre de paquets Debian posent quelques questions à l'utilisateur pour configurer le paquet.
Je sais. Le problème c'est que t'as des paquets mal foutu (c-a-d qui ne respecte pas les guidelines définis par debian: utiliser debconf judicieusement) et qui empêche une installation silencieuse. L'utilisateur "normal", il pige que dalle aux questions, c'est au distributeur de lui proposer une configuration fonctionnelle (et pourquoi pas quelques variantes), PK permet justement de le faire en début ou fin de transaction.
> Et beaucoup de paquets ont des scripts à lancer après une installation, pour faire des ldconfigs ou mettre à jour des fichiers de confs genre grub.
Les scripts pre/post installation, ça existe dans quasiment tout gestionnaire de paquets.
> il va devoir installer/remplacer/supprimer tes fichiers systèmes par d'autres, et on ne peut pas considérer que nos systèmes de fichiers soient transactionnels
C'est même la principale difficulté pour préserver un état cohérent de ton gestionnaire de paquet
> Donc si il y a une coupure de courant, il y a forcement un état intermédiaire, et ton gestionnaire de paquet n'y peut rien
La seule que tu peux exiger de ton gestionnaire de paquets c'est de pouvoir réparer ce dysfonctionnement (soit en terminant la transaction, soit en l'annulant) mais ça n'est un état intermédiaire mais un état instable/corrompu/dégradé tout ce que tu veux.
Si ce genre de trucs s'accumulent sans réparer ta base de paquets, faut pas t'étonner que ça péte au bout d'un moment.
François Bancilhon est le premier responsable dans la chute de la société, le mec il arrive dans une société exsangue avec plus de commerciaux que de développeurs sans aucune stratégie commerciale (mais une bonne réputation). Il est parti, Mandriva a sombré dans l'oubli, Mandriva n'a toujours pas de stratégie commerciale, par contre, il a bien vidé les caisses en rachetant des boites douteuses (EdgeIT ? LinBox ? Lycoris muahahahahaha), la seule décision correcte qu'il ait jamais pris, c'est le rachat de conectiva qui avait une grosse expertise technique (enfin, il a paumé la moitié des ingénieurs au passage) et un carnet de commande rempli (c'est le seul investissement "rentable" dans la folie des fusions/rachat de Bancilhon).
Mandriva avait une stratégie brouillonne mais une base utilisateur solide, au lieu de s'appuyer dessus, il a appuyé l'initiative du club qui a complétement ruiné l'image de mandriva auprès du grand public sans pour autant constituer une source de revenu durable (limite de la mendicité auprès des adeptes de la distribution, le club n'avait quasiment aucun intérêt), au lieu de donner une ligne claire à la boite, il a préféré se lancer dans la gueguerre contre les fondateurs (sa campagne de fusion/rachat n'avait pour but que de diluer l'influence des premiers).
Certes Duval était un boulet, mais au moins, il a su gagner la sympathie de la communauté là ou Bancilhon était juste un boulet. Les quelques fois, où il a voulu communiquer avec la communauté, il a juste réussi à se ridiculiser.
T'as bien répété ton discours de fanboys ... On peut pas contredire les faits donc on sort les attaques bien perfides et qui reposent sur que dalle.
Contrairement à Kroah-Hartman, on ne peut pas accuser Dave Neary d'être employé par les méchants Novell et RH, il travaille en indépendant et on ne peut pas trouver plus neutre dans ce domaine.
J'aimerais qu'on m'explique comment Canonical a révolutionné le desktop (c'est ce qu'ils disent, je ne l'ai pas inventé) en contribuant moins que la pléthore de start-ups subventionnés par Nokia et la petite nouvelle litl. Si on veut taper là où ça fait mal, suffit de regarder du côté de X.
> Ca donne des devs libres qui se tirent dans les pattes et qui donnent vraiment une super image de l'aspect collaboratif du libre
Ce qui donne une image très classe, c'est le père Shuttleworth qui parle de collaboration et que les faits contredisent. Si Canonical s'en prends plein la gueule, ce n'est pas pour rien, les dirigeants encouragent une culture détestable de la duplication d'efforts et d'entretenir des rapports détestables avec upstream (Debian en premier) tout en ouvrant leur gueule sur "la synchronisation des distributions et blablabla".
> C'est juste un élément parmi d'autres.
Personne n'a dit le contraire, quand tu vois qu'une start-up comme litl arrive à faire plus de commits, tu te poses des questions ...
C'est comme une base de données, si la transaction va jusqu'au bout, elle est enregistrée sinon elle est annulée.
Si tu as une coupure d'électricité ou un truc du genre, ton gestionnaire de paquet comme ta base de données doit être capable de revenir à un état consistent. RPM comme dpkg te proposent un jeu d'outils pour "réparer" ta base mais ça n'est pas un état normal.
Si tu as un paquet à "moitié installé", c'est que ta base de paquet est corrompue. Quand ça arrive, yum te prévient qu'une transaction n'a pas été achevé correctement et te suggérera de la terminer/nettoyer avant de faire quoique ce soit avant
Si dpkg te présente des paquets à "moitié installé" (ce qui m'étonnerait beaucoup), c'est que t'as eu un souci et tu dois réparer ta base (hint: PackageKit tient compte de la batterie, de son niveau et du réseau utilisé pour te proposer les mises à jour)
On a vu les même diagrammes ? Parce que dans le lien de Marc, ça finit soit par "successful exit", soit par "exit with error message".
> problème de configuration
ça veut rien dire pour le gestionnaire de paquet, comment veux-tu que celui-ci sache que le logiciel est bien configuré ?
> à moitié installé
un gestionnaire de paquet doit s'assurer que l'installation se passe correctement et en cas d'échec que ton système soit dans un état stable donc si tu as un paquet a moitié installé tu as un GROS problème.
Si dpkg permet d'avoir des paquets à moitié installés (ce dont je doute fortement), faudra m'expliquer pour ça crache autant sur RPM ...
> L'uniformisation pas le bas c'est vraiment dommage tout de meme.
ça a surtout révélé des pratiques pas très nets dans le packaging debian. Il n'est pas normal qu'on ne puisse pas réaliser une installation silencieuse de paquets et que chaque paquet réinvente une façon d'interagir avec l'utilisateur. J'installe 100 paquets, est-ce que je dois intervenir à chaque fois ?
> Ce n'est pas dû au fait que personne ne s'est porté volontaire
C'est pourtant ce qu'il s'est passé. Il a fallu attendre près de deux ans avant que des gens de debian/ubuntu s'investissent dans le projet.
> mais parce que la vision de PackageKit ne correspond pas à APT/DPKG.
Pas tout à fait, les packaging guidelines de Debian exigent de passer par debconf or t'as plein de paquets qui passent par stdin ce qui n'est pas gérable.
Le problème, c'est que si le processus exige une interaction utilisateur, tu ne peux plus faire de mises à jours automatique, c'est plus chiant pour gérer l'installation de greffons à un programme.
PackageKit permet dans une certaine mesure les interactions utilisateurs mais seulement au début ou à la fin d'une transaction (ce qui est logique).
C'est facile de rejeter la faute sur le mainteneur mais quand il a ouvert la discussion sur le design de PK, on n'a pas beaucoup vu des gens de Debian. Et comme par hasard, PK gère environ 15 backends différents et le seul qui pose problème c'est apt ...
> Ah donc tu es en train de dire que pour utiliser packagekit il faut lire un bouquin voir passer un diplome specifique
Avant de critiquer, faudrait peut-être l'avoir utilisé et avant de poster un journal sur l'utilité de PackageKit, avoir visiter le site pour comprendre le pourquoi du comment.
Tu parles d'états "intermédiaires" de paquets qui n'existent que dans ton obscure cervelle, tu t'obstines à chier sur l'inexistant "résolveur de dépendance" de PK alors que c'est visiblement soit un bogue dans apt soit un bogue situé entre la chaise et le clavier, etc ...
Tu critiques PK sur des cas d'utilisations spécifiques (genre purger la configuration) alors que c'est principalement destiné au grand public qui en a rien à branler. L'utilisateur avancé, il utilisera directement l'outil sous-jacent (apt*/yum/conary/urpmi/portage etc ...)
> Tiens quand a parler d'un autre systeme bien mieux foutu je te nommerais pisi celui de pardus
Quel est le rapport entre pisi et PackageKit ? pisi c'est un gestionnaire de paquets comme RPM ou dpkg (et qui intégre des fonctionnalités des surcouches types yum/apt etc ...) Au passage, PackageKit possède un backend pisi.
> mais la encore c'est pas du Fedora donc ca doit etre le mal incarne
Tiens, m'attribuer des mots que je n'ai jamais prononcé voire jamais pensé, ça va très certainement t'éviter le ridicule. Tu t'enfonces, Charles !
> Le package manager étant l'une des clés de voutes de l'os et de son interaction homme-machine
PackageKit ne remplace pas ton gestionnaire de paquets, il offre une couche d'abstraction.
Par exemple, quand tu lances une vidéo avec totem, si le codec n'est pas installé Totem fait une requête à PK qui s'occupe de l'installer sans se soucier du gestionnaire de paquet utilisé.
Auparavant, t'avais autant de scripts helpers que de distribution (si ce n'est plus !) pour gérer ce genre de chose.
> La question est là , vue les circonstances du logciels , pourqoi se basé sur quelque chose de si récent pour tout changer , et qui plus est maintenue par une seule personne.
PK a un mainteneur et plusieurs développeurs, la difficulté c'est plutôt dans le support des backends qui demande de bien connaitre le gestionnaire de paquet en question.
Le truc, c'est que quand le mainteneur a demandé de l'aide pour écrire les backends, il a trouvé facilement des gens motivés pour le faire sauf pour debian/ubuntu pour qui PERSONNE ne s'était porté volontaire. il a fallu attendre genre deux ans pour que les mecs se réveillent.
> pourquoi au vue des conditions s'appuyer aussi fortement sur un logiciel qui me semble n'a pas encore fait ses preuves
PK a fait ses preuves, gpk-application est l'interface graphique par défaut de Fedora, Foresight Linux (avant même Fedora) et dans certains cas d'Ubuntu (la mise à jour entre autre) ... La quasi-totalité des distributions basés sur GNOME l'utilisent depuis plus d'un an.
> Cela va à l'encontre du bon sens , de la philosophie unix et de celle de debian
Si t'écoute les conneries d'albert_ qui n'a même pas visité le site ou même utilisé plus de 30s le bouzin, forcément oui.
> Ouhais ben moi j'ai l'habitude d'avoir des etats intermediaires
Tu dis n'importe quoi, ça n'est pas un état intermédiaire pour le gestionnaire de paquets ça, c'est juste la file d'attente. Hint: à gauche, tu as un onglet "Paquets sélectionnés" qui t'affichera les paquets en attente d'installation ou de désinstallation.
C'est pareil avec synaptic, si tu fermes synaptic avant d'avoir démarrer la transaction, tu perds la file d'attente si tu relances celui-ci ou que tu passes par une autre interface !
> Le truc de canonical c'est packagekit donc je vois pas trop ce que tu racontes a moins que tu parles du app-store
Je ne sais pas ce qu'utilise actuellement le machin-store de Canonical (ça n'utilisait pas PK la dernière fois que j'ai zyeuté le code) mais c'est le truc qu'utilise la majorité des ubuntistes et ils s'en plaignent pas plus que cela
> Ce n'est pas parceque packagekit vient de Fedora que je critique
PackageKit est un projet indépendant de Fedora, d'ailleurs le premier backend fonctionnel de PK était celui de conary.
> et je te suggere d'installer une debian (vu ton "amour" pour ubuntu je ne pense aps que ce soit le truc a essayer pour toi)
hint: déjà fait depuis quelques années, on ne critique que ce que l'on connait bien.
Ça décrit la machine à états interne à dpkg (hint: RPM fonctionne plus ou moins de la même façon [1]) mais au final, soit la transaction a réussie, soit elle a échouée. Dans la base de données du gestionnaire de paquets, à la fin d'une transaction, un paquet est soit installé, soit il ne l'est pas.
La différence, c'est que la couche d'abstraction offre une interface générique à différents moteurs là où le front-end ne supporte qu'un seul.
Imagine que ton gestionnaire de paquets soit une prise murale et que tu sois un appareil électrique. Le connecteur qui va bien, c'est le frontend mais il ne rentre que dans un seul type de prise murale, l'adaptateur de voyage c'est la couche d'abstraction avec différents embouts (ça c'est le code glue) pour rentrer dans la prise.
> lorsque tu veux savoir les etats intermediaire?
Les états intermédiaires n'existent pas, soit ton paquet est installé, soit il ne l'est pas, tu ne peux pas avoir de paquet à moitié installé ... La plupart des gestionnaires de paquets ont un fonctionnement transactionnel: pour lui un paquet ne peut avoir que deux états installé ou pas installé.
> Oui c'est d'ailleurs pour cela que j'aime bien avoir cette option pour les virer.
PackageKit est une couche d'abstraction, ce n'est pas un front-end à apt, si le comportement d'apt est stupide par défaut, PK n'y peut pas grand chose.
PK est destiné aux développeurs d'applications qui ont besoin d'une interface générique au système de paquets et aux utilisateurs normaux (qui pour la plupart ne connaissent pas le switch --purge).
D'ailleurs, je ne t'ai pas entendu critiquer le truc de Canonical qui a un comportement similaire à PK à ce niveau-là (pas d'affichage d'états "intermédiaire", pas d'option pour "purger" la configuration) pourtant ça ne gère qu'un seul format de paquet ...
> Je soupconne tout de meme que le backend utilise est apt du coup vu que cela fonctionne en ligne de commande
Le problème que tu décris, c'est lié au résolveur de dépendance or PK ne s'amuse pas à recoder ce genre de chose (qui est souvent lié au format de paquets).
> Euh oui mais il y a pas que le blanc et le noir dans la vie il y a aussi les paquets a installe
Le monsieur dit bien qu'on peut distinguer les paquets installés/non-installés dans l'interface
> ou les paquets mal desinstalle
Si t'as un paquet mal désinstallé, soit ton gestionnaire de paquets est sérieusement pété, soit c'est un bogue. Un paquet est installé ou il ne l'est pas, il n'existe pas d'état intermédiaire.
> ou encore les paquets avec des restes de configuration.
C'est une connerie de laisser trainer les fichiers de configuration après la désinstallation mais bon.
Rien ne t'empêche d'implémenter ça dans PK, le système de backends et de capacités est fait pour ça, les backends qui ne supporteront pas cette fonctionnalité ne l'afficheront pas.
> Sauf que la c'est pas la faute de apt vu que apt-get install a tres bien fonctionne
PackageKit ne gère pas les conflits de dépendances, c'est le backend utilisé qui s'en charge, donc ça n'est pas un bogue de PK.
Il n'a pas tort, on lui a demandé un "traitement de texte", il va pas te proposer un "système avancé de composition de documents de qualité professionnelle qui r0x0r des mamans ours".
C'est une couche d'abstraction pour la gestion de paquets:
* ça permet aux application de pouvoir récupérer des greffons (codecs, polices, paquets de langues, pilotes d'impressions, etc ...) sans se soucier du gestionnaire de paquets sous-jacent.
* d'avoir une interface standardisée: tu as des outils en ligne de commande (pkcon), graphiques (gnome-packagekit, kpackagekit, etc ...) pour gérer les paquets, les dépôts, les services packs, mises à jour etc ... Par exemple, PackageKit est capable d'inhiber les mises à jour si tu es sur batterie, de demander un redémarrage ...
* quelques trucs sympa comme avoir un mécanisme standard pour installer les paquets depuis le web, proposer l'installation automatique du paquet correspondant à une commande, etc ... tout ce que chaque distribution réinventait dans son coin.
PK ne se réduit pas au dénominateur commun, t'as un système de backends et chacun précise les actions supportés (gpk-backend-status). Ça n'a pas vocation à remplacer ton gestionnaire de paquets pour les cas d'utilisations avancées. C'est fait pour les utilisateurs "normaux" qui veulent un outil ergonomique pour faire les tâches classiques.
T'aurais pu attendre vendredi, parce que t'as visiblement pas fait l'effort de visiter le site qui a le mérite d'être clair et d'expliquer la démarche.
> Je considère que mon temps est suffisamment précieux pour minimiser autant que possible le temps que je passe à mettre à jour mon système.
Tu vas aimer presto, tu économises 80% de bande passante (donc autant de temps de téléchargement en moins). Par contre, sur le rafraichissement du cache, autant avec une debian stable, ça peut être superflu, autant avec une fedora, debian sid et dérivées, c'est pas une mauvaise idée.
Un truc que yum sait faire et pas apt c'est le rollback d'une transaction.
* autoremove ==> plugin remove-with-leaves
* deborphan ==> package-cleanup --orphan
* pinning ==> selon, ce que tu veux faire les plugins protectbase, versionlock ou priorities, tu peux également utiliser les clauses exclude/includepkgs par dépôts.
* purge ==> rpm renomme automatiquement les fichiers de configuration en xxx.rpmsave, tu peux utiliser la commande rpmconf pour gérer ça.
Yum plus pauvre que apt en fonctionnalités, c'était vrai il y a 4 ans, ça l'est beaucoup moins aujourd'hui. Yum a l'avantage d'être plus facilement extensible que apt (c'est du python et l'API est plutôt sympa et assez bien documenté).
[^] # Re: Étonnant
Posté par GeneralZod . En réponse au journal Contributions à Gnome. Évalué à 1.
Fraternité parce que chaque utilisateur a la possibilité de partager le programme avec le monde. RMS
Le libre met en avant la valeur de partage, la meilleure façon de partager c'est de mettre les connaissances et les compétences en commun. Ce n'est pas toujours possible (ie: travailler avec le dictateur Ulrich Drepper) mais c'est souhaitable. J'aimerais que tu nous expliques comment bosser dans son coin et balancer quelques patchs dans un obscur recoin d'un serveur respecte l'esprit du libre.
Si on lit le texte de la GPL, la GPL précise que tu dois fournir les outils nécessaires à la compilation et au packaging du binaire fourni. Si je fournis un paquet deb ou RPM d'un logiciel libre, je dois derrière fournir les outils pour arriver au même résultat (la recette du paquet, les outils de création de paquet etc ...)
L'esprit de la GPL est de supprimer tout entrave possible au partage et de faciliter celui-ci, or on peut pas dire que Canonical fait de gros efforts à ce niveau-là
> L'esprit du libre est respecté par Canonical
Non, seule la lettre est respectée, c'est ce qui est reproché à Android, et certains projets qualifiés de faux-pen source, le projet est plus fermé que le code. Avec son dictateur lunatique, Ubuntu est pas loin d'être un projet faux-pen source.
[^] # Re: Étonnant
Posté par GeneralZod . En réponse au journal Contributions à Gnome. Évalué à 5.
Et qui continue de payer au moins une vingtaine d'ingénieurs pour bosser à temps plein dessus. Hein, si tu regardes le joli graphique du monsieur, tu verras beaucoup de rouge.
> s'appuie sur la communauté de manière désintéressée et pas du tout parce que ca leur permet de stabiliser leur belle distrib proprio.
Le projet Fedora repose sur un pacte entre la communauté et Red Hat, Red Hat paie des gens pour bosser sur Fedora, fournit une infrastructure etc, la communauté apporte des développeurs/testeurs/empaqueteurs/traducteurs/graphistes etc ... Red Hat gagne une base solide et innovante pour ses produits et la communauté une infrastructure et une distribution semi-communautaire.
Si au départ, Ubuntu/Fedora c'est le même combat, Ubuntu est devenu un despotat éclairé: une personne qui dirige tout et qui nomme même les membres du conseil "communautaire" (noter le choix pertinent du nom), Fedora est devenu une monarchie constitutionnelle britannique, un Fedora Project Leader nommé par Red Hat dont le rôle est principalement représentatif (et sert de trésorier) ==> le résident général, mais qui est dirigé par des différents comités élus par les contributeurs (le fesco ===> le premier ministre canadien qui détient le pouvoir réel).
Debian, c'est la démocratie athénienne, tout les contributeurs sont égaux (et c'est très bien !) et ils sont totalement indépendants.
Il y a communautaire comme debian, gento & cie, il y a semi-communautaire comme fedora, openSuSE et il y a pseudo-communautaire comme Ubuntu.
[^] # Re: ennemi
Posté par GeneralZod . En réponse au journal Le pire ennemi de Mandriva, c’est François Bancilhon,. Évalué à 3.
Certes, Linbox a apporté dans sa corbeille les futurs MDS et Pulse2 (qui sont de beaux produits) mais Mandriva a été incapable de les faire fructifier au niveau commercial. C'est même le principal malheur de Mandriva, ils avaient une distribution pas trop mal foutu, de bons ingénieurs (malgré un encadrement de merde d'après ce qui se dit), une bonne réputation (en 2003, c'était comme ubuntu aujourd'hui) mais ils n'ont pas été foutu de commercialiser ça.
Mais Edge-IT c'est vraiment le truc qui sert strictement à rien, la boite était en cessation de paiement, endettée jusqu'au coup et sans intérêt (même pas un carnet clientèle bien rempli comme Conectiva). D'ailleurs, si tu regardes sur societe.com, Edge-It n'a fait qu'accumuler les pertes (et servira de veau expiatoire pour regrouper les dettes du "groupe"). Si je devais justifier le renvoi de Bancilhon en deux mots, ce serait "Edge-IT".
[^] # Re: Étonnant
Posté par GeneralZod . En réponse au journal Contributions à Gnome. Évalué à 2.
Oui, quand on dit quelque qui ne va pas dans le sens des fanboys on est forcément un anti-xxx [:flu1]
> Tu peux le remonter upstream si ça te plait, eux n'en voient pas l'intérêt (le retour sur investissement), et alors? Ils mettent les sous où ils veulent, tant qu'ils respectent la licence (et ils la respectent)
Ai-je dit le contraire, je dis juste que la dichotomie entre le discours de Canonical ("on est des gentils pro-libre, c'est les autres qui veulent pas nous suivre") et les faits ("on fait tout pour partager les moins possible") ça rejaillit sur l'image de la boite sur son discours. Hein, j'ai pas entendu beaucoup de personnes ici féliciter Novell pour leur contribution pourtant énorme au libre: quand c'était SuSE: Yast sapusaipalibre, mono saiunetechonmicrosoft, novell sailemalilzonpaktiséaveksatan etc ...
Voilà, tu peux piocher dans le code libre, respecter la lettre de la licence mais si tu n'en respectes pas l'esprit (le partage des connaissances, des compétences etc ...) faut pas t'étonner si tu n'es pas vu d'un bon oeil par la communauté. Hein, Canonical c'est pas le caliméro du libre qui est le seul (l'unique) à s'en prendre plein la gueule.
Quand Canonical deviendra un acteur du libre digne de ce nom, je serais le premier à les applaudir. Je les ai applaudi quand ils ont libérés launchpad (auraient-ils libérer launchpad si on ne les avait pas fait chier ? je ne crois pas).
> Effectivement. C'est juste parce que c'est la plus utilisée, est les jaloux tapent sur ce qui marche mais qu'ils n'aiment pas.
Faudrait changer d'arguments, t'as un mec qui présente des stats qui contredisent le discours de canonical, donc c'est forcément des jaloux.
> Tu veux dire, genre Debian qui fait des .deb alors que tous les autres font des .rpm?
Non, genre on réinvente la roue tout les 6 mois pour au final reprendre ce que les autres ont fait.
Actuellement, tout le monde bosse sur gnome-shell pendant que Canonical bosse sur Unity ===> personne chez eux ne s'est demandé si ça n'était pas pertinent de collaborer avec les gars de gnome-shell (hint: ça repose sur les mêmes technos, et gnome-shell est extensible).
C'est toujours la même chose avec eux, le pire c'est que ça leur est plus nuisible qu'autre chose
> dernièrement on m'a traité d'employé Microsoft car j'ai défendu Microsoft
Plus haut, je suis à la fois employé par Novell et Red Hat ... (j'attends toujours ma double paie) Pourtant, j'en ai rien à branler de Red Hat comme il y a des gens d'ubuntu qui s'en branlent de Canonical.
Allez, je vais rajouter une calomnie à ta collection, cadeau de la maison ;)
<calomnie>Tu défendrais pas Canonical parce qu'ils ont acheté une licence H.264, hein on SAIT tous icitte que t'as vendu ton âme au dieu pognon (saimal l'argent !!!!) et au dieu MPEG (à ne pas confondre avec le dieu meuporgue)</calomnie>
[^] # Re: Simplicité
Posté par GeneralZod . En réponse au journal packagekit c'est utilisable?. Évalué à 2.
J'utilise Debian à titre personnel et professionnel (et même ubuntu - à contre-coeur)
> Nombre de paquets Debian posent quelques questions à l'utilisateur pour configurer le paquet.
Je sais. Le problème c'est que t'as des paquets mal foutu (c-a-d qui ne respecte pas les guidelines définis par debian: utiliser debconf judicieusement) et qui empêche une installation silencieuse. L'utilisateur "normal", il pige que dalle aux questions, c'est au distributeur de lui proposer une configuration fonctionnelle (et pourquoi pas quelques variantes), PK permet justement de le faire en début ou fin de transaction.
> Et beaucoup de paquets ont des scripts à lancer après une installation, pour faire des ldconfigs ou mettre à jour des fichiers de confs genre grub.
Les scripts pre/post installation, ça existe dans quasiment tout gestionnaire de paquets.
> il va devoir installer/remplacer/supprimer tes fichiers systèmes par d'autres, et on ne peut pas considérer que nos systèmes de fichiers soient transactionnels
C'est même la principale difficulté pour préserver un état cohérent de ton gestionnaire de paquet
> Donc si il y a une coupure de courant, il y a forcement un état intermédiaire, et ton gestionnaire de paquet n'y peut rien
La seule que tu peux exiger de ton gestionnaire de paquets c'est de pouvoir réparer ce dysfonctionnement (soit en terminant la transaction, soit en l'annulant) mais ça n'est un état intermédiaire mais un état instable/corrompu/dégradé tout ce que tu veux.
Si ce genre de trucs s'accumulent sans réparer ta base de paquets, faut pas t'étonner que ça péte au bout d'un moment.
[^] # Re: ennemi
Posté par GeneralZod . En réponse au journal Le pire ennemi de Mandriva, c’est François Bancilhon,. Évalué à 7.
Mandriva avait une stratégie brouillonne mais une base utilisateur solide, au lieu de s'appuyer dessus, il a appuyé l'initiative du club qui a complétement ruiné l'image de mandriva auprès du grand public sans pour autant constituer une source de revenu durable (limite de la mendicité auprès des adeptes de la distribution, le club n'avait quasiment aucun intérêt), au lieu de donner une ligne claire à la boite, il a préféré se lancer dans la gueguerre contre les fondateurs (sa campagne de fusion/rachat n'avait pour but que de diluer l'influence des premiers).
Certes Duval était un boulet, mais au moins, il a su gagner la sympathie de la communauté là ou Bancilhon était juste un boulet. Les quelques fois, où il a voulu communiquer avec la communauté, il a juste réussi à se ridiculiser.
[^] # Re: Étonnant
Posté par GeneralZod . En réponse au journal Contributions à Gnome. Évalué à 7.
Contrairement à Kroah-Hartman, on ne peut pas accuser Dave Neary d'être employé par les méchants Novell et RH, il travaille en indépendant et on ne peut pas trouver plus neutre dans ce domaine.
J'aimerais qu'on m'explique comment Canonical a révolutionné le desktop (c'est ce qu'ils disent, je ne l'ai pas inventé) en contribuant moins que la pléthore de start-ups subventionnés par Nokia et la petite nouvelle litl. Si on veut taper là où ça fait mal, suffit de regarder du côté de X.
> Ca donne des devs libres qui se tirent dans les pattes et qui donnent vraiment une super image de l'aspect collaboratif du libre
Ce qui donne une image très classe, c'est le père Shuttleworth qui parle de collaboration et que les faits contredisent. Si Canonical s'en prends plein la gueule, ce n'est pas pour rien, les dirigeants encouragent une culture détestable de la duplication d'efforts et d'entretenir des rapports détestables avec upstream (Debian en premier) tout en ouvrant leur gueule sur "la synchronisation des distributions et blablabla".
[^] # Re: Ubuntu = Gnome ?
Posté par GeneralZod . En réponse au journal Contributions à Gnome. Évalué à 5.
[^] # Re: Étonnant
Posté par GeneralZod . En réponse au journal Contributions à Gnome. Évalué à 7.
http://www.neary-consulting.com/wp-content/uploads/2010/07/d(...)
ça c'est de la contribution ...
> C'est juste un élément parmi d'autres.
Personne n'a dit le contraire, quand tu vois qu'une start-up comme litl arrive à faire plus de commits, tu te poses des questions ...
[^] # Re: Simplicité
Posté par GeneralZod . En réponse au journal packagekit c'est utilisable?. Évalué à 2.
Si tu as une coupure d'électricité ou un truc du genre, ton gestionnaire de paquet comme ta base de données doit être capable de revenir à un état consistent. RPM comme dpkg te proposent un jeu d'outils pour "réparer" ta base mais ça n'est pas un état normal.
Si tu as un paquet à "moitié installé", c'est que ta base de paquet est corrompue. Quand ça arrive, yum te prévient qu'une transaction n'a pas été achevé correctement et te suggérera de la terminer/nettoyer avant de faire quoique ce soit avant
Si dpkg te présente des paquets à "moitié installé" (ce qui m'étonnerait beaucoup), c'est que t'as eu un souci et tu dois réparer ta base (hint: PackageKit tient compte de la batterie, de son niveau et du réseau utilisé pour te proposer les mises à jour)
[^] # Re: Simplicité
Posté par GeneralZod . En réponse au journal packagekit c'est utilisable?. Évalué à 0.
> problème de configuration
ça veut rien dire pour le gestionnaire de paquet, comment veux-tu que celui-ci sache que le logiciel est bien configuré ?
> à moitié installé
un gestionnaire de paquet doit s'assurer que l'installation se passe correctement et en cas d'échec que ton système soit dans un état stable donc si tu as un paquet a moitié installé tu as un GROS problème.
Si dpkg permet d'avoir des paquets à moitié installés (ce dont je doute fortement), faudra m'expliquer pour ça crache autant sur RPM ...
[^] # Re: PackageKit n'est pas un front-end
Posté par GeneralZod . En réponse au journal packagekit c'est utilisable?. Évalué à 4.
ça a surtout révélé des pratiques pas très nets dans le packaging debian. Il n'est pas normal qu'on ne puisse pas réaliser une installation silencieuse de paquets et que chaque paquet réinvente une façon d'interagir avec l'utilisateur. J'installe 100 paquets, est-ce que je dois intervenir à chaque fois ?
[^] # Re: PackageKit n'est pas un front-end
Posté par GeneralZod . En réponse au journal packagekit c'est utilisable?. Évalué à 4.
C'est pourtant ce qu'il s'est passé. Il a fallu attendre près de deux ans avant que des gens de debian/ubuntu s'investissent dans le projet.
> mais parce que la vision de PackageKit ne correspond pas à APT/DPKG.
Pas tout à fait, les packaging guidelines de Debian exigent de passer par debconf or t'as plein de paquets qui passent par stdin ce qui n'est pas gérable.
Le problème, c'est que si le processus exige une interaction utilisateur, tu ne peux plus faire de mises à jours automatique, c'est plus chiant pour gérer l'installation de greffons à un programme.
PackageKit permet dans une certaine mesure les interactions utilisateurs mais seulement au début ou à la fin d'une transaction (ce qui est logique).
C'est facile de rejeter la faute sur le mainteneur mais quand il a ouvert la discussion sur le design de PK, on n'a pas beaucoup vu des gens de Debian. Et comme par hasard, PK gère environ 15 backends différents et le seul qui pose problème c'est apt ...
[^] # Re: PackageKit n'est pas un front-end
Posté par GeneralZod . En réponse au journal packagekit c'est utilisable?. Évalué à 2.
http://www.packagekit.org/pk-authors.html ==> le mainteneur du backend pisi est aussi un des développeurs de pisi ....
[^] # Re: PackageKit n'est pas un front-end
Posté par GeneralZod . En réponse au journal packagekit c'est utilisable?. Évalué à 2.
Avant de critiquer, faudrait peut-être l'avoir utilisé et avant de poster un journal sur l'utilité de PackageKit, avoir visiter le site pour comprendre le pourquoi du comment.
Tu parles d'états "intermédiaires" de paquets qui n'existent que dans ton obscure cervelle, tu t'obstines à chier sur l'inexistant "résolveur de dépendance" de PK alors que c'est visiblement soit un bogue dans apt soit un bogue situé entre la chaise et le clavier, etc ...
Tu critiques PK sur des cas d'utilisations spécifiques (genre purger la configuration) alors que c'est principalement destiné au grand public qui en a rien à branler. L'utilisateur avancé, il utilisera directement l'outil sous-jacent (apt*/yum/conary/urpmi/portage etc ...)
> Tiens quand a parler d'un autre systeme bien mieux foutu je te nommerais pisi celui de pardus
Quel est le rapport entre pisi et PackageKit ? pisi c'est un gestionnaire de paquets comme RPM ou dpkg (et qui intégre des fonctionnalités des surcouches types yum/apt etc ...) Au passage, PackageKit possède un backend pisi.
> mais la encore c'est pas du Fedora donc ca doit etre le mal incarne
Tiens, m'attribuer des mots que je n'ai jamais prononcé voire jamais pensé, ça va très certainement t'éviter le ridicule. Tu t'enfonces, Charles !
[^] # Re: PackageKit n'est pas un front-end
Posté par GeneralZod . En réponse au journal packagekit c'est utilisable?. Évalué à 3.
PackageKit ne remplace pas ton gestionnaire de paquets, il offre une couche d'abstraction.
Par exemple, quand tu lances une vidéo avec totem, si le codec n'est pas installé Totem fait une requête à PK qui s'occupe de l'installer sans se soucier du gestionnaire de paquet utilisé.
Auparavant, t'avais autant de scripts helpers que de distribution (si ce n'est plus !) pour gérer ce genre de chose.
> La question est là , vue les circonstances du logciels , pourqoi se basé sur quelque chose de si récent pour tout changer , et qui plus est maintenue par une seule personne.
PK a un mainteneur et plusieurs développeurs, la difficulté c'est plutôt dans le support des backends qui demande de bien connaitre le gestionnaire de paquet en question.
Le truc, c'est que quand le mainteneur a demandé de l'aide pour écrire les backends, il a trouvé facilement des gens motivés pour le faire sauf pour debian/ubuntu pour qui PERSONNE ne s'était porté volontaire. il a fallu attendre genre deux ans pour que les mecs se réveillent.
> pourquoi au vue des conditions s'appuyer aussi fortement sur un logiciel qui me semble n'a pas encore fait ses preuves
PK a fait ses preuves, gpk-application est l'interface graphique par défaut de Fedora, Foresight Linux (avant même Fedora) et dans certains cas d'Ubuntu (la mise à jour entre autre) ... La quasi-totalité des distributions basés sur GNOME l'utilisent depuis plus d'un an.
> Cela va à l'encontre du bon sens , de la philosophie unix et de celle de debian
Si t'écoute les conneries d'albert_ qui n'a même pas visité le site ou même utilisé plus de 30s le bouzin, forcément oui.
[^] # Re: Simplicité
Posté par GeneralZod . En réponse au journal packagekit c'est utilisable?. Évalué à 2.
Tu dis n'importe quoi, ça n'est pas un état intermédiaire pour le gestionnaire de paquets ça, c'est juste la file d'attente. Hint: à gauche, tu as un onglet "Paquets sélectionnés" qui t'affichera les paquets en attente d'installation ou de désinstallation.
C'est pareil avec synaptic, si tu fermes synaptic avant d'avoir démarrer la transaction, tu perds la file d'attente si tu relances celui-ci ou que tu passes par une autre interface !
> Le truc de canonical c'est packagekit donc je vois pas trop ce que tu racontes a moins que tu parles du app-store
Je ne sais pas ce qu'utilise actuellement le machin-store de Canonical (ça n'utilisait pas PK la dernière fois que j'ai zyeuté le code) mais c'est le truc qu'utilise la majorité des ubuntistes et ils s'en plaignent pas plus que cela
> Ce n'est pas parceque packagekit vient de Fedora que je critique
PackageKit est un projet indépendant de Fedora, d'ailleurs le premier backend fonctionnel de PK était celui de conary.
> et je te suggere d'installer une debian (vu ton "amour" pour ubuntu je ne pense aps que ce soit le truc a essayer pour toi)
hint: déjà fait depuis quelques années, on ne critique que ce que l'on connait bien.
[^] # Re: Simplicité
Posté par GeneralZod . En réponse au journal packagekit c'est utilisable?. Évalué à 2.
Bref, c'est complétement hors sujet.
[1] http://www.rpm.org/wiki/DevelDocs/StateMachines
[^] # Re: Simplicité
Posté par GeneralZod . En réponse au journal packagekit c'est utilisable?. Évalué à 2.
Imagine que ton gestionnaire de paquets soit une prise murale et que tu sois un appareil électrique. Le connecteur qui va bien, c'est le frontend mais il ne rentre que dans un seul type de prise murale, l'adaptateur de voyage c'est la couche d'abstraction avec différents embouts (ça c'est le code glue) pour rentrer dans la prise.
[^] # Re: Simplicité
Posté par GeneralZod . En réponse au journal packagekit c'est utilisable?. Évalué à 1.
Les états intermédiaires n'existent pas, soit ton paquet est installé, soit il ne l'est pas, tu ne peux pas avoir de paquet à moitié installé ... La plupart des gestionnaires de paquets ont un fonctionnement transactionnel: pour lui un paquet ne peut avoir que deux états installé ou pas installé.
> Oui c'est d'ailleurs pour cela que j'aime bien avoir cette option pour les virer.
PackageKit est une couche d'abstraction, ce n'est pas un front-end à apt, si le comportement d'apt est stupide par défaut, PK n'y peut pas grand chose.
PK est destiné aux développeurs d'applications qui ont besoin d'une interface générique au système de paquets et aux utilisateurs normaux (qui pour la plupart ne connaissent pas le switch --purge).
D'ailleurs, je ne t'ai pas entendu critiquer le truc de Canonical qui a un comportement similaire à PK à ce niveau-là (pas d'affichage d'états "intermédiaire", pas d'option pour "purger" la configuration) pourtant ça ne gère qu'un seul format de paquet ...
> Je soupconne tout de meme que le backend utilise est apt du coup vu que cela fonctionne en ligne de commande
Le problème que tu décris, c'est lié au résolveur de dépendance or PK ne s'amuse pas à recoder ce genre de chose (qui est souvent lié au format de paquets).
[^] # Re: Simplicité
Posté par GeneralZod . En réponse au journal packagekit c'est utilisable?. Évalué à 4.
Le monsieur dit bien qu'on peut distinguer les paquets installés/non-installés dans l'interface
> ou les paquets mal desinstalle
Si t'as un paquet mal désinstallé, soit ton gestionnaire de paquets est sérieusement pété, soit c'est un bogue. Un paquet est installé ou il ne l'est pas, il n'existe pas d'état intermédiaire.
> ou encore les paquets avec des restes de configuration.
C'est une connerie de laisser trainer les fichiers de configuration après la désinstallation mais bon.
Rien ne t'empêche d'implémenter ça dans PK, le système de backends et de capacités est fait pour ça, les backends qui ne supporteront pas cette fonctionnalité ne l'afficheront pas.
> Sauf que la c'est pas la faute de apt vu que apt-get install a tres bien fonctionne
PackageKit ne gère pas les conflits de dépendances, c'est le backend utilisé qui s'en charge, donc ça n'est pas un bogue de PK.
[^] # Re: Simplicité
Posté par GeneralZod . En réponse au journal packagekit c'est utilisable?. Évalué à 7.
# PackageKit n'est pas un front-end
Posté par GeneralZod . En réponse au journal packagekit c'est utilisable?. Évalué à 10.
* ça permet aux application de pouvoir récupérer des greffons (codecs, polices, paquets de langues, pilotes d'impressions, etc ...) sans se soucier du gestionnaire de paquets sous-jacent.
* d'avoir une interface standardisée: tu as des outils en ligne de commande (pkcon), graphiques (gnome-packagekit, kpackagekit, etc ...) pour gérer les paquets, les dépôts, les services packs, mises à jour etc ... Par exemple, PackageKit est capable d'inhiber les mises à jour si tu es sur batterie, de demander un redémarrage ...
* quelques trucs sympa comme avoir un mécanisme standard pour installer les paquets depuis le web, proposer l'installation automatique du paquet correspondant à une commande, etc ... tout ce que chaque distribution réinventait dans son coin.
PK ne se réduit pas au dénominateur commun, t'as un système de backends et chacun précise les actions supportés (gpk-backend-status). Ça n'a pas vocation à remplacer ton gestionnaire de paquets pour les cas d'utilisations avancées. C'est fait pour les utilisateurs "normaux" qui veulent un outil ergonomique pour faire les tâches classiques.
T'aurais pu attendre vendredi, parce que t'as visiblement pas fait l'effort de visiter le site qui a le mérite d'être clair et d'expliquer la démarche.
[^] # Re: J'ai testé aussi
Posté par GeneralZod . En réponse à la dépêche Test de Fedora 13 : Goddard. Évalué à 2.
Tu vas aimer presto, tu économises 80% de bande passante (donc autant de temps de téléchargement en moins). Par contre, sur le rafraichissement du cache, autant avec une debian stable, ça peut être superflu, autant avec une fedora, debian sid et dérivées, c'est pas une mauvaise idée.
[^] # Re: J'ai testé aussi
Posté par GeneralZod . En réponse à la dépêche Test de Fedora 13 : Goddard. Évalué à 4.
* autoremove ==> plugin remove-with-leaves
* deborphan ==> package-cleanup --orphan
* pinning ==> selon, ce que tu veux faire les plugins protectbase, versionlock ou priorities, tu peux également utiliser les clauses exclude/includepkgs par dépôts.
* purge ==> rpm renomme automatiquement les fichiers de configuration en xxx.rpmsave, tu peux utiliser la commande rpmconf pour gérer ça.
Yum plus pauvre que apt en fonctionnalités, c'était vrai il y a 4 ans, ça l'est beaucoup moins aujourd'hui. Yum a l'avantage d'être plus facilement extensible que apt (c'est du python et l'API est plutôt sympa et assez bien documenté).