bubar🦥 a écrit 6906 commentaires

Peux essayer de résumer cela par quelque chose de simple comme ceci :

--

Il y a un danger, réel : si Ubuntu est réellement massivement adoptée, alors elle devra massivement contribué. Ce n'est pas un problématique ni de licence ni de morale mais de stratégie de développement d'une entreprise. Pour le moment, le danger est là, mais Canonical avance à petit pas tout à fait cohérents. Donc ne pas anticiper le futur de Ubuntu parcequ'on en voit les inconvénients.

Son insistance sur le fait qu'Ubuntu permet à mr michu d'avoir gnu/linux facilement : c'est du troll de compétition d'un point de vue objectif, mais après tout c'est bien le rôle d'un patron/commercial de boite, non ? Il serait un peu décevant de lire que ubuntu c'est moins bien par le patron de ubuntu.

--

addon :
Peut être, par contre, que le danger qu'il n'a peut être pas encore vu venir c'est la gratuité de Ubuntu. Vampirisation de clients d'autres, affaiblissement éventuel des développements lorsque ceux ci sont fait par d'autres... Enfin, si je veux une distribution de calibre professionnel, et gratuite, ben que m'apporte ubuntu sur Debian ? trois trucs proprios ? kénena-afoutr ?
Bref certainement un délicat équilibre à trouver entre guerre commerciale et assurance de pérénité des développements.

Passer du status d'éditeur, intégrateur, de distribution, au status de centre majeur de développement ne se fait en deux ans. Et je ne crois pas que la politique actuelle de ubuntu à ce sujet aide vraiment canonical à se développer ...

En plus Debian est vraiment plus sexy :)

Ubuntu c'est une offre d'appel :) T'installes c'est beau ça marche bien. Puis ça te plait et tu veux la version au dessus :) Z'auraient peut être mieux de faire une branche 'corpo' à Debian dès le départ. M'enfin j'dit ça, j'dit rien...en plus c'est même pas vendredi.

Arretez d'utiliser un mauvais navigateur ?

Konqueror a toujours sû faire cela, placer l'écrit dans un tampon. Un retour arrière et hop tu retrouves ta prose sans être obligé de chercher dans les méandres des fichiers temporaires.

Firefox le fait aussi depuis pas mal de versions je crois.

Bien sûr cela m'est arrivé également, et de nombreuses fois :p Depuis, pas mesure de sécurité je fais simplement un ctrl+a avant de cliquer sur "poster", juste au cas où...

Bonus : Quant fifi beta 245 merde, l'utilisateur pourra pas dire "debian merde" : il saura bien que c'est son fif beta 245, là. Ca ne vient pas de la distro.

Merci aussi à tous de vos réponses.

Je tenterai de mettre tout ça au clair pour moi, dans un nourjal prochain, avec ces nouvelles lumières.

Là où je veux en venir, en essayant de résumé une idée non-finie :

Le système ne devrait pas contraindre l'utilisateur. (ne pas être obliger d'avoir tout son système en instable juste parcequ'il souhaite utiliser une version beta d'un soft mineur pour le système mais majeur pour lui)
Le système devrait savoir se protéger. (ne pas laisser un rpm de chrome faire ce qu'il veut en %pre %post et autre... seul le binaire et un menu sont intéressants...)
L'utilisateur devrait pouvoir installer firefox 4 beta sur son système stable, de manière simple (ne pas se contenter de coller le binaire, et ses libs, dans son ~/bin : c'est sale)
La distribution ne devrait pas avoir 'la responsabilité' de l'usage de ce binaire (pas de rapports de bugs à la distro valide pour ça, renvoyant ainsi la balle au projet quant il refuse des rapports parceque le binaire vient pas de chez eux.)

L'utilisateur il est tout jouasse : il a un système stable avec son fifi beta 245, même si ce fifi consomme plus de ram et est moins propre que celui livré de base.
L'adminisatreur, il est rassuré : le système n'est pas impacté. Si bronx il y a ça sera chez l'utilisateur, dans son home, sous sa responsabilité.
Le projet, il est content : il a des remontées directes de ses utilisateurs pour ses versions beta.
J'imagine la distribution rassurée : finie les requêtes incessantes "bouh firefox openoffice vlc sont antédiluvients", fini les rapports merdiques du gars ne disant pas que son truc il a installé depuis un dépôt obscur.

Les backports sont une réponse à cela, mais est ce bien le plus propre pour le système ? Si j'installe des backports, je reprends l'exemple de firefox, je vais me retrouver quant même avec certaines bibliothèques importantes (pour gnome) qui seront backportées également. Elles ne seront pas isolées sur le système, mais en seront partie intégrante. Bien que depuis quelques temps, xul-runner est il me semble en version spécifique pour firefox, non ? justement pour éviter cela, on a déjà un doublon ...
Ce n'est pas "pour ou contre" je me demande juste si les backports ce n'est pas une réponse qui finalement ne convient pas à FireFox et OpenOffice ? Alors qu'elle est gage de qualité pour d'autres logiciels 'endusers' ?

(ce n'est qu'une question)

Tout à fait, c'est cela aussi que je ne comprends pas.

Le système a tout ce qu'il faut, intrinsèquement, pour permettre cet accueil (/opt, mais aussi /usr/games et le compte associé, hein). Le système propose des outils franchement géniaux aussi pour ce type de cas (de la configuration par défaut des autotools, qui font attention par défaut au système, jusqu'aux possibilités de restrictions diverses). Les projets se décarcassent souvent pour finir un .spec dans leurs sources, voir même parfois passent des heures à construire plein de paquets, ou propose des binaires statiques [pas mal pour les versions beta]

Le seul point bloquant, c'est le packaging, ou plutot cette politique forcenée de packaging. N'est il pas possible de se dire simplement que le système ne devrait pas être en danger si l'utilisateur choisi firefox 4 beta ? Ne peux t on donc faire aucune concession sur la propreté théorique du système afin d'éviter des conneries pires, et de permettre (bis) aux utilisateurs d'avoir firefox 4 beta et de faire leur remontées avec l'outil prévu par la MoFo ?

Pil Poil !!!!

Seule la réponse "non" est inadaptée car elle ne concerne que le cas où un soft beta viendrai foutre le bronx dans mon système. Plus un. Mais inadaptée car elle n'entre pas en contradiction avec cette légitime volonté d'un utilisateur de vouloir firefox beta 4 sur son système stable, mais sans installer un paquet venu de n'importe où, sans foutre le bronx dans son système.

Tu viens d'illustrer à merveille l'enfermement de l'utilisateur.
S'il ne sait pas compiler correctement Firefox, alors qu'il creuve ou change de distro. C'est dommage, visiblement l'utilisateur lui il veux à la fois avoir un système stable, en suivant la doc, en écoutant, bref... et à la fois, pour quelques softs pouvoir les avoir en version beta sans remettre en cause le premier point.

J'ai volontairement laisser de côté l'aspect technique (n'ayant pas la prétention de dire "c'est ça qu'il faut faire", perso je compile et je chroot, tu vois c'est pas la panacée non plus) pour ne m'interessé qu'à l'aspect théorique. L'utilisateur il écoute Debian, il comprends pourquoi Chromium se sera pas intégrer par exemple. Actuellement, la seule solution facile qui lui possible c'est ... de foutre le bronx dans son système :( :( :(
Or il comprends que saymal, et aimerai bien avoir à la fois, comme tu le fais, un système stable et un firefox beta dans un coin. Pour le projet c'est bien aussi : un même binaire chez tout le monde, des remontées directes. Sans heurter les politiques des distros.

Une petite concession permettant :
1. éviter de foutre le bronx sur un système stable
2. au projet un rapport direct avec leurs utilisateurs quant il le demande
3. à l'utilisateur de pouvoir avoir firefox 4 beta

C'est il me semble une bien petite concession au regard de ce que cela apporte.
Techniquement, doit on se contenter d'un howto ? En sachant que peu le suivront et finiront par mettre le bronx sur leur système ? Ou est ce possible d'avoir une solution correcte pour tous ?

En tout cas, maintenant nous en sommes sûr : les méchants utilisent bash et ne connaissent pas les limits

/tout les jours aussi, je lave mon cerveau avec la télévision

C'était plus une question sur la pertinence d'appliquer des recettes de serveur et de système d'entrerprise pour un système orienté grand public. (je comprends que le sysadmin devienne un peu dictateur avec ses usagers, je le comprends moins lorsque le sysadmin et l'usager sont une seule personne : utilisateur unique ou familial d'une machine personnelle, et que c'est la distro qui endosse ce rôle)
Dans ce petit cadre d'utilisation personnelle et familale, n'y a t il possibilité de laisser l'usager pouvoir suivre facilement directement les projets eux-mêmes, pour quelques grands softs "vitrines" ? Est ce qu'une politique de packaging unique ne devient pas contradictoire, au final, parfois, avec le but de l'utilisation personnelle facilité ? Qu'est ce que le système, la distro, craint il vraiment, de voir ses utilisateurs pouvoir facilement utiliser firefox 4 beta, sans déstabilisé tout leur système, ni encombrer son bugzilla avec un problème uniquement à firefox 4 beta ? Est ce que le système de packaging n'atteinds pas là ses limites ?

Ouhaip, c'est complètement déplacé de questionner sur ça sur un post de Debian. Désolé.
En plus, effectivement, j'ai oublié plein de points d'interrogations partout.

http://www.thinq.co.uk/2010/7/1/tv-business-kisses-hdmi-good(...)
(l'article sur lequel pointe celui de /.)

je suis bien incapable de t'en dire plus ! j'ai vu passer la news, comme beaucoup d'autres je pense, sur /. il me semble, il y a une quinzaine de jours.
et hop, le lien est fait, c'est tout :)

C'est drole que ce soi-disant "cassage" ai lieu pile au moment où certains constructeurs commencent à parler sérieusement de déjà remplacer hdmi. Avec ça comme argument, nul doute qu'ils vont pouvoir convaincre leurs partenaires.

Y a des disclosers comme ça, vachement bien opportuns.

Je ne comprends pas cette opposition stabilité et nouveauté.

Lorsque le but est d'avoir un serveur stable, y a pas photos. Cette politique met une énorme claque à tout autre système. En même temps celui qui lance chrome sur un serveur stable (ou qui se sert d'un serveur web/mail/whatever mais pas d'appli, pour lancer openoffice), ben heu comment dire, faut aller voir s'il reste du goudron et des plumes...

Lorsque le but est d'avoir un bureau grand public, y a pas photos. Cette politique est celle, lorsqu'elle est appliquée de a à z, qui met une énorme claque à l'utilisateur lambda. Et l'utilisateur lambda, il se casse. Bon pour Debian, probable qu'ils s'en fichent. (l'important étant ici l'aspect pédagogique ainsi que le cheminement pour une personne afin qu'elle se fasse la main sur un truc secondaire dans ce système, avant de devenir 'productive' : ceci a une importance sans commune mesure avec un mr michu)

Lorsque le but est d'avoir un bureau grand public, secondo :p il va être difficile de tenir le même discours. Aller expliquer au projet libre x "qu'il pue du cul" d'une part, et de l'autre aller expliquer à l'utilisateur qui souhaiterait faire des rapports de bugs sur la version beta de x, ben que c'est pas possible parcequ'il a pas le niveau et que dans le système c'est la version stable, sinon tout est cassé !

Un système visant le bureau grand public doit s'ouvrir plus tout d'abord aux projets eux mêmes, en permettant des relations plus étroites avec leurs utilisateurs, si ces projets le demandent. Et s'ouvrir aussi aux demandes utilisateurs, qui ne réclament souvent que de pouvoir suivre les gros projets comme eux ils le souhaitent. En plus, nos systèmes permettent des configurations assez velues assez facilement, rien n'empêche de prévoir une sécurité, une prison, un environnement restreint, pour ces binaires venus d'ailleurs mais libres...

Un exemple un peu bancal, la politique de Fedora vis à vis de Kde : de super packages, une super intégration, mais c'est bien le bugzilla de Kde qui est sollicité s'il y a problème, pas celui de Fedora. Parfait. Pour oter l'adjectif 'bancal' il pourrait y avoir la même chose mais pour FireFox, OpenOffice, VLC, bref les projets libres indépendants. Moins de travail de packaging, plus d'utilisateurs satisfaits parcequ'ils ont la dernière version de logiciel 'vitrine' important, et plus de retours directement fait aux projets.

Je ne dis pas qu'il faille vider les bugzilla des distributions de tout rapport de bugs qui ne concerne pas les fichiers spec, bien spur, je ne tombe dans l'autre extrème. Je dis juste que ça me semblerait intéressant de lacher du lest aux projets indépendants, qu'ils puissent avoir des retours directs de leurs utilisateurs plus facilement. Donc préparer un système stable à être en capacit" d'accueillir une version beta de firefox, si l'utilisateur, et le projet!, le désirent. Protéger le système pour plus de liberté à l'utilisateur et aux projets indépendant.

mes deux cents.

oupss j'aurai dû attendre vendredi pour celui là ! et puis surtout c'est juste rigolo.

mode évidence : moi c'est bien Debian qui me fait de plus en plus de l'oeil ! :) reste à gentoĩsé un stade 1 de Debian... ensuite à utiliser les binaires des projets directement (pour firefox, ooo, tb, VLC...) dans un beau tit env bien préparé :)

Tant qu'on touche pas aux overlays :)
les binaires c'est bien de les faire pour comprendre, pas pour les distribuer
(...)

merci encore

Merci de tes explications. (ça fait du bien de lire un texte qui cherche à avoir raison et non pas un texte qui cherche à prouver que l'autre à tord, donc merci, passons)

Pour être direct, toujours :
* si tout le monde se permet ça, tout les programmes vont prendre dix fois plus de mémoire
* globalement, ils feraient mieux de collaborer avec les auteurs des libs

Ok. Parfait.
Si des programmes font cela, et que ça deviant sale sur mon système, j'arrete d'utiliser ces programmes. Point.
Si je suis re-lecteur et que je me rends compte que tel navigateur s'amuse a implémenter une tinybd alors que le système l'as déjà, ben j'essaie de faire comprendre au projet, et de travailler avec eux, pour améliorer cela. Si le projet ne veux rien entendre et continue de faire ses saletés, je ne vois vraiment pas pourquoi je continuerai de m'enquiquiner à le packager en défaisant ce qu'ils ont choisi de faire. J'en informe les utilisateurs, et je pense qu'ils sauront écouter.

non ?

(je passe sur le troll des mises à jour et de la sécurité, hein, ça vaut mieux....)

problème est un terme déplacé.
le mode de fonctionnement du packaging de nombreuses distros, et uniquement pour les logiciels tiers, est à l'origine de problème pour passer à l'échelle supérieure.

sans y mettre les formes :
je ne vois pas pourquoi je ferai plus confiance a des re-lecteurs et packageurs qui ne veulent pas travailler upstream, préférant faire leur truc dans leur coin pour leur distro, plutot que de faire confiance au projet libre lui même.

La MoFo a un comportement proprio, aussi ? Les développeurs de l'installeur Debian également ? Ca ne tiens pas la route comme discours, on cherche juste à justifier du pouvoir et une position.

>Chromium a une approche propriétaire de la mise à jour
ouch ça c'est du beau gabarit !
un autre de beau gabarit : à moins que soit les distributions qui voudraient que la terre entière tourne autour d'elles ?
Chromium est libre.
Ils fournissent code et binaire.
Libre à chacun de s'en servir (moi je commence à m'en méfier, bien que je sois utilisateur de nombreux services google)

c'est quant même sacrément gros de justifier le fait que le packaging a un problème dans de nombeuses distros en disant que c'est le projet libre qui a un comportement proprio. Non ?

Quel rapport avec le packaging ?

>Plutôt que de travailler avec les libs qu'ils utilisent, ils font la modification dans leur coin et copient la lib entière dans leur source.
ça suffit comme raison, non ? En quoi le packaging impacte cela ? Il est impacté, oui, par contre.

Quant à la sécurité évoquée plus bas, j'ai autant de doutes sur chromium que sur chrome. Mais ce ne sont que des doutes. Quant je vois que Chrom{e;ium} semble ré-écrire une fonction autrefois dévolue à un service spécifique, puis plus récemment à la glibc, j'ai un peur sur ce que fait le bousin, en fait. En plus il est fourbe, il demande de jolies dépendances, mais ne s'appuye pas sur le système pour des trucs basiques.

Merci de ces éclairages.

1 0
pas anticipé celle là :) :) très très bonne ! le petit scarabée s'incline :)

Mais bon, j'vais attendre vendredi avant de pondre une telle connerie :)

Cesses d'être pendu au bon vouloir d'un empaqueteur ! Libères toi !

Et utilises le binaire de la Fondation Mozilla directement, si tu souhaites tester FireFox 4 beta. L'important c'est les Logiciels Libres, non la distribution. En plus tu fera plaisir à la MoFo, vu qu'ils "ralent" après le faible nombre de testeurs. Ils se décacarssent a fabriquer Firefox, et se décarcassent à nous filer un binaire fonctionnel (moyennant une règle en plus pour selinux chez ceux utilisant cette solution) et propre pour le systeme (tu peux le coller dans /opt par exemple, puis le lancer avec un simple " ./firefox -no-remote -ProfileManager " et hop :) :) :)

Tout comme pour Chrome, ou tu peux prendre le rpm de Google, il fonctionne sans problème sur ta mandriva (moyennant l'install des dépendances, bien sûr)

/mode trol off/ (tiens ça vaut bien un petit texte sur "l'utilisation des logiciels libres par les distributions, le pouvoir, l'utilisateur, le système" qui pourrait même compléter le fameux howto "comment détruire une communauté en 10 points", peut être, peut être... en fait juste une mise en valeur du point numéro 1 : "Rendez le projet dépendant d’outils complexes" ...

>l'augmentation des performances du hardware, c'est souvent utilisé comme prétexte pour gérer les ressources n'importe comment ...
c'est beau, ça fonctionne aussi dans l'autre sens !
gérer les ressources n'importe c'est souvent utilisé comme pretexte pour avoir une augmentation des performances du hardware