Avec le renforcement des conditions d'entrées de nouvelles versions ou de nouveaux paquets (le gel de Debian pour la publication de la nouvelle version stable se fait en plusieurs étapes), l'équipe de publication a décidé d'exclure le paquet de la prochaine version stable. En effet, l'équipe doit arbitrer entre le risque d'introduire de nouveaux problèmes en mettant à jour ou garder du code largement utilisé (et avoir une plus grande confiance dans ce dernier). Le choix est fait au cas par cas : ainsi une nouvelle version mineure de gnash a été acceptée (de 0.8.7 à 0.8.8). Chromium, probablement trop gros et trop risqué, en a fait les frais. On trouve une volonté de créer ce paquet dès mars 2009. Il semble que cette première intention ne soit pas celle ayant débouché sur le paquet actuel¹. Le paquet est rentré dans unstable en mars 2010.
Le paquet reste donc uniquement disponible dans Sid. Il reste toujours possible d'installer facilement Google Chrome en utilisant la version fournie par Google. Le .deb fonctionne sans difficulté mais est limité aux processeurs x86 et x86_64.
La licence du code source pour Chromium est de type BSD (en version sans clause de publicité) donc le paquet est intégrable à la branche principale de Debian (main) sans difficulté. En revanche, Google Chrome est soumise à une licence plus restrictive, basée sur celle des services Google, impliquant en particulier une divulgation des données personnelles.
¹ : Je ne sais pas ce qui s'est passé entre mars 2009 et mars 2010, date d'activation de la liste dédiée au paquet chromium-browser.
Aller plus loin
- Proposition de création du paquet (6 clics)
- Chromium-browser dans sid (25 clics)
- Paquet fourni par Google (81 clics)
- Message du mainteneur signalant la triste nouvelle (4 clics)
# Debian a raison
Posté par GeneralZod . Évalué à 5.
http://spot.livejournal.com/312320.html
[^] # Re: Debian a raison
Posté par DLFP est mort . Évalué à 7.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Debian a raison
Posté par bubar🦥 (Mastodon) . Évalué à 1.
>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.
[^] # Re: Debian a raison
Posté par DLFP est mort . Évalué à 10.
Le problème des libs bundlées, c'est que :
* si tout le monde se permet ça, tout les programmes vont prendre dix fois plus de mémoire
* quand une lib bundlée à une faille de sécurité, il faut mettre à jour tout ces paquets, c'est horrible
* c'est très lent à compiler (ça c'est l'utilisateur de Gentoo qui parle)
* globalement, ils feraient mieux de collaborer avec les auteurs des libs
Enfin, Firefox est aussi un habitué, en bundlant sqlite par exemple. (Ce qu'on peut éviter sous Gentoo.)
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Debian a raison
Posté par bubar🦥 (Mastodon) . Évalué à 5.
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....)
[^] # Re: Debian a raison
Posté par DLFP est mort . Évalué à 1.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Debian a raison
Posté par bubar🦥 (Mastodon) . Évalué à 2.
les binaires c'est bien de les faire pour comprendre, pas pour les distribuer
(...)
merci encore
[^] # Re: Debian a raison
Posté par bubar🦥 (Mastodon) . Évalué à 2.
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é :)
[^] # Re: Debian a raison
Posté par Bapt (site web personnel) . Évalué à 6.
1 fichiers c et 1 fichier h suffisent pour ça etc ainsi chacun projet embarque son sqlite et le compile avec les options adaptées à son utilisation (oui beaucoup d'options de sqlite sont des options compile-time).
Sinon dans la majeure partie des cas c'est pas bien de faire ça :)
[^] # Re: Debian a raison
Posté par Zenitram (site web personnel) . Évalué à 4.
Car le problème quand chacun embarque son sqlite (très pratique pour Windows/Mac, par forcément pour Linux) est que si il y a une faille de sécurité sur sqlite, ben si on loupe une appli qui l'embarque, on a mal si le développeur upstream n'y pense pas et ne sort pas de nouvelle version de sécurité.
Pas facile tout ça, car il n'y a pas de bonne et unique solution...
[^] # Re: Debian a raison
Posté par Gniarf . Évalué à 7.
qui êtes-vous et qu'avez-vous fait de Zenitram ?
[^] # Re: Debian a raison
Posté par houra . Évalué à 1.
- Si un groupe de développeurs ne suit pas les libs concernées, à un moment donné il va y avoir un problème de version dans le paquet. Inclure les libs permet de se passer de ce genre de problème, qui peut être bloquant, sans que rien d'autre que le numéro de version n'ait changé pour le groupe en question
- Pour la sécurité, j'ose imaginer que l'équipe qui fait le projet sait d'où vient ce qu'elle y a inclus , et est capable de s'abonner aux avis et en tenir compte.
- La mémoire, c'est uniquement la place du binaire sur le disque dur. Rien ne change à l'usage, quand tu fais un #include 'toto.h" ou un #include "/usr/lib/toto.h" si les deux libs sont identiques. Et même s'il faut y réfléchir, c'est quoi , 300ko de + , lorsque le To est à 70€ ? le soupçon de sérénité ?
Le grain de sel des mises à jour tranquilles ?
- La collaboration, c'est si possible, et si on modifie la lib de façon conforme aux objectifs. Quand je vois que le paquet Epiphany inclue Gecko , c'est à dire Firefox en entier sous FreeBSD, je me dis que quelque fois, les libs, ça pourrait être mieux géré. Si je devais faire un navigateur utilisant Gecko, crois moi, je prendrait tout ce qui concerne Gecko dans Firefox, mais ça serait du rm de tout le reste, et pas de remontées, peut -etre une énieme libGecko qui sera plus à jour à la prochaine update de firefox. ( à côté, webkit est dispo beaucoup plus facilement :s )
Quant à sqlite, en même temps, ce truc est fait pour être inclus dans les programmes . Sinon, faut travailler avec du lourd.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Debian a raison
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 5.
La mémoire, ce n'est pas la place du binaire sur le disque dur. Si tu embarque une bibliothèque dans le projet de ton logiciel, tu vas compiler cette bibliothèque. Cette version ne sera pas la même que celle fournit par la distribution. Le logiciel sera lié avec cette bibliothèque, le path de la bibliothèque étant décidé lors de la compilation. Donc oui, il y aura deux version de la bibliothèque dynamique chargées en mémoire. Au passage, ça n'a rien à voir avec les headers.
[^] # Re: Debian a raison
Posté par houra . Évalué à -1.
Moi je parle non pas de faire un boulot crado comme aller donner à l'EDI un chemin vers une bibliothèque externe et l'inclure dans le paquet ... Je parle de récupérer les sources et de compiler l'ensemble dans ton logiciel. :)
Évidemment, si les mecs font le boulot à moitié... ;S
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Debian a raison
Posté par tesiruna . Évalué à 2.
> donné il va y avoir un problème de version dans le paquet. Inclure les libs
> permet de se passer de ce genre de problème, qui peut être bloquant, sans que
> rien d'autre que le numéro de version n'ait changé pour le groupe en question
>
> - Pour la sécurité, j'ose imaginer que l'équipe qui fait le projet sait d'où
> vient ce qu'elle y a inclus , et est capable de s'abonner aux avis et en tenir
> compte.
En fait, tu dis que c'est chiant pour les développeurs de suivre les nouvelles
versions des libs qu'ils utilisent, mais que c'est moins chiant qu'ils
s'abonnent aux avis de sécurité sur les libs qu'ils utilisent ?
Ça n'a absolument aucun sens.
> - La mémoire, c'est uniquement la place du binaire sur le disque dur. Rien ne
> change à l'usage, quand tu fais un #include 'toto.h" ou un #include
> "/usr/lib/toto.h" si les deux libs sont identiques. Et même s'il faut y
> réfléchir, c'est quoi , 300ko de + , lorsque le To est à 70€ ? le soupçon de
> sérénité ?
Heu je pense que t'as pas compris. Un header contient juste en théorie les
prototypes des fonctions et les déclarations de types, en gros c'est utile qu'au
moment de la compilation et on s'en cogne.
En revanche, le linkage statique va inclure toute la lib dans l'executable, et
donc va l'alourdir, là où le linkage dynamique permet de charger la lib au
moment de l'exécution, et donc elle n'est présente sur le système qu'une seule
fois.
> - La collaboration, c'est si possible, et si on modifie la lib de façon
> conforme aux objectifs. Quand je vois que le paquet Epiphany inclue Gecko ,
> c'est à dire Firefox en entier sous FreeBSD, je me dis que quelque fois, les
> libs, ça pourrait être mieux géré. Si je devais faire un navigateur utilisant
> Gecko, crois moi, je prendrait tout ce qui concerne Gecko dans Firefox, mais
> ça serait du rm de tout le reste, et pas de remontées, peut -etre une énieme
> libGecko qui sera plus à jour à la prochaine update de firefox. ( à côté,
> webkit est dispo beaucoup plus facilement :s )
Bah dans ce cas là, la solution c'est qu'une libgecko développée upstream et
utilisée par Firefox soit bien faite, pas de pomper le code et de l'inclure dans
ton soft. Qu'est-ce que tu fais pour merger les modifs upstream de gecko après ?
> Quant à sqlite, en même temps, ce truc est fait pour être inclus dans les
> programmes . Sinon, faut travailler avec du lourd.
Heu j'ai peur de pas comprendre ce que tu veux dire.
[^] # Re: Debian a raison
Posté par houra . Évalué à -2.
versions des libs qu'ils utilisent, mais que c'est moins chiant qu'ils
s'abonnent aux avis de sécurité sur les libs qu'ils utilisent ?
Ça n'a absolument aucun sens.
Aucun, d'ailleurs, aucun paquet n'a jamais de problèmes de dépendances au moment des mises à jour.
Heu je pense que t'as pas compris. Un header contient juste en théorie les
prototypes des fonctions et les déclarations de types, en gros c'est utile qu'au
moment de la compilation et on s'en cogne.
En revanche, le linkage statique va inclure toute la lib dans l'executable, et
donc va l'alourdir, là où le linkage dynamique permet de charger la lib au
moment de l'exécution, et donc elle n'est présente sur le système qu'une seule
fois.
Ma réponse est deux posts plus haut.
Bah dans ce cas là, la solution c'est qu'une libgecko développée upstream et
utilisée par Firefox soit bien faite, pas de pomper le code et de l'inclure dans
ton soft. Qu'est-ce que tu fais pour merger les modifs upstream de gecko après ?
Demande-toi plutôt pourquoi Firefox ne donne pas de libGecko.
Heu j'ai peur de pas comprendre ce que tu veux dire.
KDE utilise quelles bases de données ( au pluriel ) ?
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Debian a raison
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Debian a raison
Posté par houra . Évalué à -1.
Bon sinon, je ne prêche pas , je ne dénonce pas, et je m'en fous Royal des bibliothèques.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Debian a raison
Posté par DLFP est mort . Évalué à 5.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Debian a raison
Posté par Zenitram (site web personnel) . Évalué à 3.
J'aime bien tes petits pics... Complètement HS.
A aucun moment je n'ai parlé que c'était bien de packager tout ce bordel avec des libs patchées sans avoir remonté upstream pour les libs. A aucun moment je n'ai parlé de changer ce comportement pour avoir un repo stable pour ceux qui le souhaitent. Bloquer Chronium dans le repo stable car l'upstream (Google) fait n'importe quoi ne me pose aucun problème.
Mais c'est un classique : tu n'as pas de bons arguments pour ce que je critique, donc tu m'accuses de tous les maux qui n'ont rien à voir pour essayer de me décrédibiliser. C'est une méthode très utilisée en politique.
[^] # Re: Debian a raison
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Debian a raison
Posté par Zenitram (site web personnel) . Évalué à 3.
# Raisons
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
[^] # Re: Raisons
Posté par Carl Chenet (site web personnel) . Évalué à 6.
En gros :
- Chrome 6 vient de sortir, Chrome 5 ne va plus recevoir de mises à jour de sécurité. C'est inacceptable pour un logiciel avec un si large public. Exit Chrome 5.
- Mais Chrome 6 vient de sortir (le 2 septembre) donc il ne peut pas être considéré comme stable, il n'a pas pu être intensivement testé sur une longue période et il serait donc incohérnet de l'inclure dans une version de Debian dite stable. Donc exit Chrome 6.
Heureusement les backports sont là et permettront aux utilisateurs d'avoir régulièrement des versions maintenues et sécurisées de Chromium.
[^] # Re: Raisons
Posté par Carl Chenet (site web personnel) . Évalué à 1.
Plus d'infos sur le rejet de Chromium : http://carlchenet.wordpress.com/2010/09/14/chromium-absent-d(...)
[^] # Re: Raisons
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 8.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Raisons
Posté par GeneralZod . Évalué à 3.
> Heureusement les backports sont là et permettront aux utilisateurs d'avoir régulièrement des versions maintenues et sécurisées de Chromium.
Rien n'est moins sûr, le code de Chromium a beau être développé sous une licence libre mais le projet ne fait aucun effort pour faciliter la tâche des intégrateurs. Chromium a une approche propriétaire de la mise à jour: je fournis un gros binaire compilé en statique et je gère tout seul les mises à jours. Les autres peuvent se démerder.
[^] # Re: Raisons
Posté par Carl Chenet (site web personnel) . Évalué à 2.
C'est sûr que le mieux serait une modification de leur modèle de développement, mais en l'état les backports permettront de mettre à disposition des utilisateur de Debian stable des versions pour lesquelles les plus récentes failles ont été corrigées.
[^] # Re: Raisons
Posté par Romeo . Évalué à 3.
Si en plus de l'upstream il faut attendre sur les packageurs pour ramener les nouvelles versions qui ne viendront peut-être pas à cause de la politique de la stabilité, le logiciel n'avance pas.
[^] # Re: Raisons
Posté par bubar🦥 (Mastodon) . Évalué à 2.
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)
[^] # Re: Raisons
Posté par bubar🦥 (Mastodon) . Évalué à 2.
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 ?
[^] # Re: Raisons
Posté par bubar🦥 (Mastodon) . Évalué à 2.
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.
[^] # Re: Raisons
Posté par Guillaume Knispel . Évalué à 3.
Le packageur est fort démuni si les conventions de dev de sa distro sont incompatibles avec celles de l'upstream du logiciel et qu'il n'a pas la force suffisante pour combler les deltas pendant la période de maintenance...
Après il y a d'autres distro de dispo qui apportent d'autres qualités, c'est pas comme si Debian était un espèce de monopole malsain qui tentait d'imposer sa manière de faire à toute l'humanité.
[^] # Re: Raisons
Posté par bubar🦥 (Mastodon) . Évalué à 2.
En plus, effectivement, j'ai oublié plein de points d'interrogations partout.
[^] # Re: Raisons
Posté par Gniarf . Évalué à 5.
ouais. tu te fais insulter si tu fournis un mozilla avec pas pile poil les mêmes libs qu'eux ou pas patchées pareil ou pas les mêmes options de compilation, ça se résume en un "seule notre version binaire est la bonne" "n'appelez pas la votre 'Firefox'" et ça a donné les gueguerres avec Debian qu'on a connu, avec des débordements de très grosses têtes de cons de part et d'autres.
vouloir interdire d'autres versions que les siennes est un comportement proprio. voir Ion3 par exemple. (et même problèmatique générale d'ailleurs)
> Ca ne tiens pas la route comme discours, on cherche juste à justifier du pouvoir
t'as oublié de faire comme ouin-ouin et crier à la censure.
[^] # Re: Raisons
Posté par ckyl . Évalué à 6.
Ils ne veulent pas interdire une autre version, ils ne veulent pas voir leur nom associé aux expérimentations des autres. C'est très différent.
Une base de code de la taille de firefox, avec des dépendences critiques (ils s'amusent pas à patcher par ce qu'ils s'emmerdent le dimanche) c'est juste un enfer niveau QA. Il faut avoir pas mal de connaissance du produit et de son historique pour pouvoir tripatouiller le tout en relative sérénité. Ils écrivent le code, ils te le donnent, ils t'assurent que ca fonctionne avec une configuration donnée. Et tout ce qu'ils demandent c'est que si tu veux faire joujou avec le build tu n'utilises pas leur nom.
Ca evite de se faire pourrir sa réputation par ce que des rigolos de packager ont foiré sur la QA.
[^] # Re: Raisons
Posté par GeneralZod . Évalué à 2.
Chromium pose un problème de packaging pour TOUTES les distros mais Chromium n'a évidemment rien à se reprocher ... Rien que la gestion fantaisiste des bibliothèques tierces dans Chromium est problématique (ça mériterait une tribune de J-P Troll), je vais pas répéter tout ce qui a déjà été dit. Oui, le code de chromium est libre mais la gestion du projet est tout ce qu'il y a de plus fermé.
Ce qui est gros, c'est de nier que Chromium n'a de libre que son code ...
> à moins que soit les distributions qui voudraient que la terre entière tourne autour d'elles ?
Entre faire la sourde oreille aux empaqueteurs/rapporteurs de bogues et ça, il y a un monde.
[^] # Re: Raisons
Posté par Zenitram (site web personnel) . Évalué à 2.
Ce qui serait pas mal c'est que tout le monde cherche à travailler ensemble, et la, je jette la pierre à Google qui me semble (je ne connais pas assez pour être sûr) fournit un gros truc énorme "démerdez-vous". Ce n'est certes pas obligatoire dans le libre, mais c'est dommage. Bon, pour leur défense, vu le monde que ça leur apporterait de consacrer du temps à faire les choses propres, je peux les comprendre. Bref pas tout le monde noir, mais pas blanc non plus.
[^] # Re: Raisons
Posté par tesiruna . Évalué à 2.
> et la, je jette la pierre à Google qui me semble (je ne connais pas assez pour
> être sûr) fournit un gros truc énorme "démerdez-vous". Ce n'est certes pas
> obligatoire dans le libre, mais c'est dommage. Bon, pour leur défense, vu le
> monde que ça leur apporterait de consacrer du temps à faire les choses
> propres, je peux les comprendre. Bref pas tout le monde noir, mais pas blanc
> non plus.
Que lise-je ?? Zenitram qui dit qu'il faudrait que les acteurs du libres
devraient collaborer entre eux ? Pourtant la GPL ne l'oblige pas.
Je pense que pendant ses quelques jours d'absence il a été enfermé dans une
pièce sans eau ni nourriture ni déodorant avec RMS.
[^] # Re: Raisons
Posté par Zenitram (site web personnel) . Évalué à 1.
Mais tu lis ce que tu veux lire et non pas ce que j'écris quand je réagis à une chose...
[^] # Re: Raisons
Posté par tesiruna . Évalué à 2.
[^] # Re: Raisons
Posté par djano . Évalué à 1.
https://linuxfr.org//comments/1162442.html#1162442
A cran Zenitram?
[^] # Re: Raisons
Posté par DLFP est mort . Évalué à 4.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Raisons
Posté par Zenitram (site web personnel) . Évalué à 2.
[^] # Re: Raisons
Posté par Gniarf . Évalué à 1.
[^] # Re: Raisons
Posté par hervé Couvelard . Évalué à 1.
[^] # Re: Raisons
Posté par zebra3 . Évalué à 8.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Données personnelles....
Posté par Olivier (site web personnel) . Évalué à 5.
La lecture de ceci me rend un peu perplexe http://linuxfr.org//comments/1161641.html#1161641 :
bref chromium c'est juste une recompilation de chrome (et moi qui croyais que certaines briques étaient virées, pas seulement celles pas libres éventuellement par rapport à chrome mais aussi celles qui concerne la vie privée)
N'étant ni un utilisateur de Chome ni de Chromium, j'aimerai savoir ce qu'en pense les utilisateurs de Chromium : Est-il vrai que ce dernier fait comme son "grand frère", et qu'il communique lui aussi avec Google ? Mise à part peut-être pour les mises à jour des bases de données anti-phishing ?
J'avoue que je ne suis que moyennent motivé par utiliser un navigateur qui communique avec son créateur, même si c'est de nature (parfaitement ?) anonyme (envoie des URL visitées par exemple).
[^] # Re: Données personnelles....
Posté par Sphax . Évalué à 1.
Mais ça ne veut pas dire que rien n'est jamais envoyé, je sais plus où j'avais vu que Chromium envoit un récapitulatif de tes recherches toutes les 24h ou un truc du genre.
Il faudrait analyser sur une période de 2/3 jours pour être sûr en fait.
[^] # Re: Données personnelles....
Posté par TImaniac (site web personnel) . Évalué à 7.
[^] # Re: Données personnelles....
Posté par daimrod . Évalué à 3.
Car si on ne fait pas confiance au programme, on n'a pas non plus confiance dans le programmeur, et donc rechercher une hypothétique fonction, certainement obfuscée qui envoie des trucs pas net ça doit pas être facile ...
[^] # Re: Données personnelles....
Posté par Olivier (site web personnel) . Évalué à 3.
Evidement, ce n'est qu'une première approche rapide du problème. Mais si il s'agit comme ici de savoir si oui ou non Chromium discute avec Google, cela s'avère suffisant.
Après, il est toujours possible (je n'ai pas dit "facile") de patcher/forker Chrominum pour éliminer les codes de discussion avec Google. Mais c'est du gros boulot.
Personnellement, je préfère utiliser un autre navigateur, même si celui-ci est plus lent (dixtit le journal de Patrick G : http://linuxfr.org/~patrick_g/30163.html )
# Ça ne mérite pas une dépêche.
Posté par IsNotGood . Évalué à -2.
[^] # Ça ne méritaitpas un commentaire
Posté par tesiruna . Évalué à 10.
[^] # Tu as oublié un espace
Posté par DLFP est mort . Évalué à 10.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Tu as oublié un espace
Posté par Romeo . Évalué à -1.
C'est bon on arrête de se chamailler ?
Vous le moinser et on arrête de perdre du temps.
[^] # Non c'est drôle
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 10.
[^] # On dit une espace
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Tout est dans le commentaire.
Posté par Anonyme . Évalué à 10.
[^] # Halte aux commentaires dans le titre avec le titre dans le commentaire!
Posté par Maclag . Évalué à 8.
[^] # Rien n'est dans le titre
Posté par zebra3 . Évalué à -1.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # ...
Posté par wismerhill . Évalué à 2.
Stack overflow!
[^] # Re: Ça ne mérite pas une dépêche.
Posté par grondilu . Évalué à 5.
Moi par exemple, je suis sous Sid et j'aurais très bien pu continuer à ignorer que chromium-browser ne serait pas dispo sous Squeeze. Or, il se trouve que j'utilise ce navigateur pour consulter certains sites mal gérés par mon navigateur préféré (uzbl en l'occurence). Donc cette dépêche m'a incité à rechercher un autre navigateur secondaire. J'ai cherché un peu, et j'ai trouvé 'arora'. Bizarrement ce browser fonctionne avec WebKit comme uzbl, mais il gêre mieux les sites problématiques sus-mentionnés.
Du coup, grâce à cette dépêche, j'ai pu faire un : "apt-get remove chromium-browser". Avec un certain ouf de soulagement, compte tenu de ma profonde méfiance envers Google.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par Romeo . Évalué à 2.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par GeneralZod . Évalué à 6.
uzbl ==> webkit/Gtk+
arora ==> webkit/Qt
Pour faire court, WebKit c'est un kit de construction de moteur de rendu, et chaque port doit brancher un moteur réseau, de dessin, javascript, multimédia, etc ... donc il y a quelques différences entre les "ports". Sans compter que chaque port embarque sa copie de WebKit (à des révisions différentes, avec des patchs spécifiques etc ...), pour le moment, il n'est pas possible d'avoir une seule installation de WebKit sur laquelle viendrait se brancher les ports (mais ça avance)
# Ça ne mérite pas une dépêche.
Posté par seb95 (site web personnel) . Évalué à 3.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par seb95 (site web personnel) . Évalué à 1.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par symoon . Évalué à 5.
...
sous ubuntu, c'est pareil
Mouaahh :-)
[^] # Re: Ça ne mérite pas une dépêche.
Posté par patrick_g (site web personnel) . Évalué à 4.
Il y a une différence entre ne pas avoir la dernière version et virer carrément le logiciel.
Mais bon tant que c'est dans backports les utilisateurs de Chromium-browser s'y retrouveront.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par bubar🦥 (Mastodon) . Évalué à 3.
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.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par Maclag . Évalué à 2.
Il n'y a pas si longtemps on débattait sur le trop grand nombre de distros suivant toutes les préférences techniques, politiques, idéologiques, etc.
Là tu vas presque nous dire que finalement il n'y en a pas assez?
Des distros qui ne patchent pas (ou très peu) et proposent des choses très à jour, y'en a!
Je pense à Archlinux en premier, mais ce n'est pas la seule.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par bubar🦥 (Mastodon) . Évalué à 2.
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 ?
[^] # Re: Ça ne mérite pas une dépêche.
Posté par Maclag . Évalué à 5.
Réponse longue:
Tu veux introduire un logiciel béta qui va potentiellement foutre un bronx pas possible dans le système.
Sous windows:
J'ai mes deux Firefox, 3.6 et 4béta installés par l'installeur.
Sous Debian (enfin une distro GNU/Linux, tu vas voir que ça revient au même!)
J'ai mon Firefox 3.6 installé par ma distro. (enfin, Iceweasel, mais on se comprend).
J'ai mon Firefox 4.0béta obtenu sur le site de Mozilla, compilé en statique, installé dans mon répertoire utilisateur, ce qui va éviter de foutre le bronx dans le système.
Le jour où est il est stable et mâture, je peux installer le paquet de ma distro et virer la béta de mon rép. utilisateur.
Comme ça, les bugs dans 3.6 passent d'abord par Debian au cas où ça viendrait de leurs patches.
Les bugs de 4.0béta, je peux les envoyer directement à Mozilla en disant que ça vient de leur binaire compilé en statique, sur leur site (on ne peut pas faire plus "pur" pour éviter qu'ils corrigent des trucs de chez Debian).
Elle est pas belle la vie?
[^] # Re: Ça ne mérite pas une dépêche.
Posté par bubar🦥 (Mastodon) . Évalué à 2.
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 ?
[^] # Re: Ça ne mérite pas une dépêche.
Posté par Psychofox (Mastodon) . Évalué à 4.
C'est à ça que sert /opt
http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICA(...)
[^] # Re: Ça ne mérite pas une dépêche.
Posté par bubar🦥 (Mastodon) . Évalué à 2.
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 ?
[^] # Re: Ça ne mérite pas une dépêche.
Posté par Gniarf . Évalué à 1.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par shbrol . Évalué à 2.
[http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html]
[^] # Re: Ça ne mérite pas une dépêche.
Posté par Gniarf . Évalué à 2.
c'est fourni par un tiers => /opt (ou /opt/games ou autre...)
[^] # Re: Ça ne mérite pas une dépêche.
Posté par shbrol . Évalué à 2.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ça ne mérite pas une dépêche.
Posté par hervé Couvelard . Évalué à 5.
Je travaille avec debian, donc naturellement c'est un système que je connais bien, et c'est un système à base de debian que j'installerais, cela fait gagner du temps à la maintenance.
Avant je mettais pas mal de buntu, gnome pour faire le "simple" et des kde pour faire plus complexe. Avec le recul, je me suis aperçu,à l'usage des utilisateurs que j'avais, c'est que le besoin de la dernière version du logiciel est très très surfait : tu compiles la version 2 en mettant 4 dans le à propos et ils sont contents. Les michus utilisent seulement le "socle" de base du soft, et les nouveautés sont très très à la marge de leurs besoins. Et de plus en plus pour les grands parents michu, je mets un fluxbox. ou c'est chiant de faire le menu à la main, mais ils sont très content de s'y retrouver facilement. et je scripte un maximum de choses.
De plus mon _ressenti_ sur buntu, c'est que c'est assez bien fini en gros mais avec plein de petit trucs qui merdent à la marge. Alors si tu ne tombes pas sur le truc à la marge c'est cool, sinon c'est la merde. Je me souviens d'un buntu ou l'applet network-manager ne fonctionnait pas et qu'il fallait changer le réseau "en console", j'avais fait un script avec un lien dans le menu, mais c'est très chiant tous ses petits trucs qui viennent à l'utilisation, en découvrant au fur et à mesure de l'utilisation. Si en plus tu laisses ton utilisateur pouvoir faire des mises à jour tout seul, c'est le drame.
Maintenant je mets des debian stable, en expliquant que ce ne sont pas les dernières versions, mais des versions "stabilisées" qui seront maintenues 3 ans. Pour ceux que cela ne peut pas aller, je mets un testing et ceux qui aiment le risque je un "unstable", mais le unstable est figé sauf si je suis dans un rayon très proche.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par Maclag . Évalué à 2.
La volonté légitime de l'utilisateur d'avoir un système stable avec des logiciels béta... c'est encore plus fort que les distros "grand public" (quoi? KDE4.6 est pas intégré alors qu'il est sorti au moins 2 jours avant la release??).
Le beurre, l'argent du beurre...
Si tu appelles ça une limite, OK, il y a une limite au système de paquet: on n'arrivera jamais à faire des paquets pour toutes les versions de dév, toutes les "nightly builds", etc.
Enfin, quand je dis "foutre le bronx dans le système", je parle bien des bugs restants dans la béta.
Si elle marche au poil, elle marchera tout aussi bien dans le répertoire de l'utilisateur, mais ne sera pas bien intégrée au système AVANT que le paquet soit validé.
Si elle est foireuse, système de paquet ou pas, elle foutra le bronx...
(Et merci au passage pour le rappel sur /opt dans l'autre commentaire, effectivement ce serait plus propre!!).
[^] # Re: Ça ne mérite pas une dépêche.
Posté par bubar🦥 (Mastodon) . Évalué à 2.
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.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par bubar🦥 (Mastodon) . Évalué à 2.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par Maclag . Évalué à 2.
Le système doit prendre en charge des trucs venus de l'extérieur, mais sans les toucher (sinon on pourra plus faire les rapports de bugs), et tout en les empêchant de faire des trucs sales, le tout sans les avoir fait préalablement vérifier par un responsable de paquet.
Ça me semble impossible...
Si je comprends bien, ce que tu veux, c'est que la distribution arrive à prendre en charge en tant que paquet n'importe quel binaire qu'on lui soumettra?
Quel intérêt? Le but des paquets est de gérer des logiciels, gérer les dépendances, etc.
Quel intérêt de gérer les dépendances d'un binaire statique?
Autant installer les binaires fournis avec l'alerte "hé! nouvelle version dispo! t'en veux?" dans /opt.
Je ne vois pas ce qu'il y manque en dehors d'une prise en charge par la distribution pour laquelle tu es d'accord pour dire que ça ne devrait pas être sa responsabilité.
Un tel système va réinstaurer le fameux "logiciel téléchargé n'importe où sur internet" qu'on reproche au monde Windows.
Comment vas-tu éviter ça?
[^] # Re: Ça ne mérite pas une dépêche.
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Je le fais, tu le fais, et ça m'étonnerai que quiconque plus proche du code s'enquiquine à utiliser les packages de sa distribution pour le code sur lequel il participe.
Impossible ? hum ... bizarre.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Comme ajout, je le répête, je ne sais ce qu'il faut, ce qui est bon ou pas. Peut être simplement ajouter un compte adm par défaut, intermédaire, qui ai droit sur un rep particulier ? Simplement un howto ? La seule chose dont je sois sûr c'est que la situation bloque : Les utilisateurs veulent firefox / openoffice / vlc en version beta, parfois, souvent. Le bon côté c'est qu'ils font les remontées directement aux projets, ça tombe bien, des projets le demande. Et actuellement comme solution on a un "demerdez toi" ou un "utilise tout un système instable". C'est pas super, ni pour les projets, ni pour les utilisateurs. On va pas nous demander de devenir expert en c/lisp/c++/whatever, et exiger tout un système instable, pour rapporter que y a un bug de la gestion du presse-papier dans firefox, quant même ?
>où s'arreter ?
Là où la distro le décide.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Y a très certainement des statistiques sur le nombre (voir mieux, un tri qa?) de rapports de bugs, afin de comparer entre : stable, testing et instable.
Y a que moi que ça choque autant de rapport de bugs sur la version stable ?
Et si on fait un tri plus fin, si c'est possible (?), je prends le parie que les rapports de bugs sur la version stable concernent en majorité... ce type de softs.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par bubar🦥 (Mastodon) . Évalué à 2.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par Ronan BARZIC . Évalué à 1.
[^] # Re:Ça ne mérite pas une dépêche.
Posté par tesiruna . Évalué à 2.
Mais bon ce sont des cas isolés, il faut que ce soit prévu par la distribution,
du coup c'est limité.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Je tenterai de mettre tout ça au clair pour moi, dans un nourjal prochain, avec ces nouvelles lumières.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par Jar Jar Binks (site web personnel) . Évalué à 7.
Comme beaucoup de gens dans le monde libre, tu as une vision totalement biaisée du grand public. Tu penses que le grand public, ce sont des geeks comme toi qui veulent la dernière nouveauté à la mode tous les 15 jours.
Le grand public, il utilise même Windows 2000 si on lui donne un Windows 2000 sur son PC. Le grand public, il ne change pas d’OS tous les 6 mois.
Il suffit de regarder la durée des cycles de release chez Microsoft : 3 ans, avec une maintenance qui s’étale sur presque 10 ans. Ne crois pas que cette durée soit calculée au hasard : c’est la durée de vie des produits informatiques en général, en particulier des matériels. Avec leurs 18-24 mois, Debian et RHEL ont déjà des cycles trop courts pour le grand public.
[^] # Re: Ça ne mérite pas une dépêche.
Posté par nicolas . Évalué à 7.
Autant en si peu de mots, j’en ai la larme à l’œil :'-)
# Mauvais conseil
Posté par vieux_barbu . Évalué à 7.
* Il est très facile d'obtenir un paquet debian de Chromium pour squeeze.
* Les conditions d'utilisation de Chrome sont parfaitement inacceptables.
Pour le premier point :
En tant que root :
aptitude install devscripts pbuilder
echo "deb-src ftp://ftp.fr.debian.org/debian/ sid main" >> /etc/apt/sources.list.d/src_sid.list
apt-get update
En tant qu'utilisateur:
apt-get source chromium-browser
cd chromium......
sudo /usr/lib/pbuilder/pbuilder-satisfydepends-aptitude
debuild -b
On risque de devoir compiler de la même manière 1 ou 2 dépendances, mais rien de bien compliqué.
Pour le second point :
6.2 Vous acceptez que vos données soient traitées conformément aux règles de confidentialité de Google.
Sachant que les règles de confidentialité sont susceptibles de changer sans préavis/
7.3 Google se réserve le droit, sans toutefois s'y engager, de pré-visualiser, réviser, marquer, filtrer, modifier, refuser ou retirer tout ou partie du Contenu issu de tout Service.
[^] # Re: Mauvais conseil
Posté par Zenitram (site web personnel) . Évalué à 3.
J'éclate de rire quand je lis ton mode d'emploi "facile".
Nous n'avons définitivement pas la même définition du mot "facile".
Peux-tu fournir une version facile de comment obtenir chronium pour argumenter sur la facilité?
On risque de devoir compiler de la même manière 1 ou 2 dépendances, mais rien de bien compliqué.
Pour toi peut-être, pas pour beaucoup de monde.
Pour le second point, entre télécharger un rpm et cliquer dessus avec un truc sur la vie privée qui dérange pas plus que ça et un mode d'emploi incompréhensible, le choix est rapide pour beaucoup de monde : pas celui que tu proposes.
[^] # Re: Mauvais conseil
Posté par vieux_barbu . Évalué à 7.
Cependant, l'une des beautés du logiciel libre est la notion de partage, et puisque je trouve facile de faire un paquet de chromium, je peux partager cela avec toi : http://jpinon.free.fr/make_chromium_for_zenitram.sh
Voilà, plus qu'à lancer le script sous squeeze et attendre un peu, et tu auras de beaux paquets de chromium.
De plus, dès qu'il aura fini de tourner chez moi, je pourrais proposer un joli dépot de paquets chromium pour squeeze.
Le logiciel libre c'est bien , ça permet d'aider les copains.
[^] # Re: Mauvais conseil
Posté par vieux_barbu . Évalué à 2.
deb http://jpinon.free.fr/chromium squeeze mainJe vais essayer de garder le dépot à jour, pour ceux que l'apt-pinning rebute, ca me permettra de me pencher sur bazaar et bzr-builddeb.
[^] # Re: Mauvais conseil
Posté par patrick_g (site web personnel) . Évalué à 2.
Nous n'avons définitivement pas la même définition du mot "facile".
Bah oui mais avec son pseudo tu t'attendais à quoi ?
[^] # Re: Mauvais conseil
Posté par Jeanuel (site web personnel) . Évalué à 2.
pas moi.
su -
CTR-C CTR-V
exit
CTR-C CTR-V
C'est pas la mer à boire.
[^] # Re: Mauvais conseil
Posté par hervé Couvelard . Évalué à 2.
:-)
[^] # Re: Mauvais conseil
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.