> Tu as oublie la partie sur GNUstep
Non, la première version publique de GNOME est sortie avant que la partie graphique de GNUStep soit utilisable. Certes OpenStep était probablement une meilleure base de travail, mais les gens voulaient quelque chose d'utilisable le plus rapidement possible. GNOME n'a pas été démarré par la FSF (ni GNUStep d'ailleurs) mais avec la bénédiction de la FSF.
Il est arrivé la même chose avec Linux et le Hurd, à l'origine Linux comme GNOME c'était un bricolage qui a finalement pris le dessus sur le projet plus "carré" Hurd ou GNUStep.
Au moins GNUStep n'a pas connu le destin du Hurd ou presque.
> Et Qt est libre.
Aujourd'hui oui, ça ne l'était pas à l'époque des débuts de GNOME. Qt/X11 a été disponible sous une licence libre à la même période ou GNOME présentait une version fonctionnelle donc voilà.
> Et par rapport a Qt pas libre c'etait juste un pretexte
prétexte à quoi ? Qt n'était pas libre point barre, à l'époque, les gens avaient tenté de convaincre Trolltech de modifier la licence et/ou convaincre KDE d'utiliser autre chose.
> comme l'a prouve mono de plus a l'epoque
Prouver quoi ? Mono est libre, et ses fesses sont assurés par OIN.
> Alors certes cela criera parceque le bug avait ete decouvert sur Ubuntu et non passe aux autres
Justement, il faut attendre plus d'un mois pour que ce bogue soit rapporté upstream, et en plus le mainteneur ubuntu lâche le merdier sur le bugzilla fedora dans l'espoir que le mainteneur fedora fasse son boulot (c'est à dire aider les développeurs upstream à corriger le bogue voire le corriger lui-même si il a les compétences).
> c'est un pauvre gars qui fait son boulot
Ce serait un incident isolé, certes mais c'est un problème structurel dans Canonical. Ok, ils n'ont pas les compétences pour corriger le bogue, mais de là à se défausser de leurs responsabilités d'intégrateurs ça devient grave. Entre le mainteneur X qui est débordé par les rapports de bogues, Kees Cook qui n'a pas le temps de suivre convenablement un bogue critique dans une version LTS (et qui aurait dû probablement être un release blocker), il est urgent d'agir.
Il faut soit recruter plus de monde, soit restreindre les paquets couverts par le support et laisser plus de place à la communauté dans la gestion technique (un peu comme Fedora avant FC6 Core/Extras).
En l'occurrence, ce n'est pas sur le seul Kees Cook qu'il faut taper, mais sur l'employeur qui ne lui permet pas de faire son boulot dans de bonnes conditions.
> à l'origine, GNOME choisit Gtk parce qu'il ne veut pas de C++ et que le C est suffisant pour faire de l'objet
À l'origine, c'est surtout que Qt était pas libre d'où la recherche d'une alternative libre (Gtk+).
Quant au choix de C, c'est surtout dû à la facilité d'écrire des bindings et de permettre d'écrire des applications GNOME dans une variété de langages. Là où KDE estimait que C++ se suffit à lui-même, GNOME a préféré laisser le choix du langage.
GNOME n'est pas écrit entièrement en C, seul le coeur l'est, les applications GNOME sont écrites dans une variété de langage: C++, Python, Javascript, C# etc ...
Pour Vala, l'intérêt c'est d'avoir un langage de haut niveau simple (pas comme C++), performant (pas comme C#, Java) et qui soit 100% interopérable avec le C.
Avec l'arrivée de GI (GObject Introspection), l'écriture de bindings sera encore plus facile (voire s'en passer).
C/GObject était et reste encore un choix pertinent, si tu veux des plantages de GNOME, c'est du côté de Bonobo et des libgnome* qu'il faut voir.
De son côté, KDE pousse un peu plus les bindings (grâce à smoke entre autre), pour autant, je vais pas dire non plus que le choix de C++ est un échec de KDE. Faut replacer chaque chose dans son contexte.
LiMo présente quelques mobiles sur son site http://www.limofoundation.org/solutions/index.php
Note que motorola a quitté LiMo fin 2009 et que Samsung investit de plus en plus dans Android, les derniers mobiles LiMo sont des Necs principalement vendus au Japon.
Ce n'est pas surprenant vu qu'ils n'ont pas su vendre leur plateforme auprès du grand public (malgré le succès commercial de certains mobiles), des développeurs, l'arrivée tardive des smartphones.
Peut-être pas sur ce paquet, mais le groupe kernel-maintainers comporte quelques membres de la communauté, et tous ne sont pas des kernels hackers et encore moins sont des spécialistes de ext4. Rien ne garantit que tu tireras le bon numéro quand à savoir qui s'occupera du ticket.
> certains à l'origine de ext4 sont chez RedHat
Red Hat != Fedora, ce n'est pas parce qu'un mec travaille chez RH, que forcément il bosse également sur Fedora (plus de 80% des contributeurs sont issus de la communauté).
Et même si c'est le cas, il est quasi certain que tu tomberas sur les mêmes personnes sur le tracker upstream, donc quel est l'intérêt ? ext4, ce n'est pas un projet Fedora, t'as une belle brochette d'experts en dehors de Fedora (Google en emploie quelqu'un).
Par contre, le bug concerne une LTS (donc une version avec du support commercial), Canonical semble pas fichu de le corriger et n'a pas l'envie/le temps de suivre la résolution du problème avec upstream. Donc la théorie, je refile le bébé au mainteneur Fedora et les laisse se démerder avec upstream pour corriger le bogue, c'est pas déconnant du tout non plus.
Un bon mainteneur n'est pas forcément un bon développeur, être capable de remonter les bogues, les informations pertinentes, être à l'écoute des utilisateurs et des mainteneurs, c'est déjà pas mal.
Theodore T'so ne s'est pas trompé, ça demande de libérer du temps à l'équipe technique (donc embaucher du personnel), ça demande d'avoir des experts (soit en les embauchant, soit en les formant) et de savoir les retenir (cadre de travail agréable, paie conséquente).
LiMo, c'est environ 50 modèles de téléphones, 10.8 millions de mobiles vendus en 2009 (bien plus qu'Android). Harry Potter aime bien se faire mousser mais il dit pas n'importe quoi.
Jusqu'à présent, LiMo se concentre sur les mobiles en milieu de gamme donc ça chiffre pas mal en volumes. La plateforme est mature, les composants sont standardisés (notamment téléphonie), mais ils ont manqués d'ambition (ils ont loupés le coche des smartphones) et le côté consortium industriel fermé n'a pas aidé à constituer une communauté autour.
À ma connaissance, PA est disponible sur les plateformes mobiles: LiMo, Maemo.
Lors du dernier Linux Plumbers Conferences, deux conférences portaient sur PA et l'embarqué (dont l'une plus particulièrement avec le N900)
Ça fait longtemps que j'ai pas écrit un journal, j'aurais du relire l'aide plutôt que de supposer que c'est le même paragraphe que les commentaires.
Je m'en souviendrais pour le prochain journal "xxxxx FAIL" (qui portera sur une autre distribution)
* comme précisé dans l'aide, la balise html a n'est pas autorisée.
taiste
* syntaxe recommandée dans l'aide mais moche en plein milieu d'un texte.
[https://linuxfr.org/~GeneralZod/29685.html]
C'est pas satisfaisant, mais faute de mieux (si vous avez des suggestions, je suis preneur).
Quant au désordre, comme j'ai l'habitude de déconstruire/reconstruire la structure de mes textes, ça m'arrive souvent.
> Peut-être qu'il n'a que ces deux distros d'installés sur sa machine ?
Pour moi, il était plus logique qu'il commence par rapporter le problème chez Debian, d'une part parce qu'Ubuntu se synchronise régulièrement dessus, d'autre part parce que c'est un DD.
Je ne leur reproche pas de ne pas savoir corriger tout les bogues mais que la collaboration se fasse un peu trop à sens unique.
Rapporter le bogue upstream: OK (upstream comprenant bien évidemment Debian dans leur cas)
Rapporter le bogue chez les autres distributions: pourquoi pas, si derrière il y a un échange constructif (j'aurais applaudi des nageoires si c'était le cas). Mais de là à refiler le boulot à une autre distribution et rester peinard à attendre la solution, c'est plutôt moyen comme habitude.
Surtout quand le grand patron fait des belles phrases sur la collaboration entre les distros.
> Que les distributions doivent participer aux développements en finançant des développeurs, d'accord, mais leur rôle c'est l'intégration au départ
Le problème c'est que la société vends du support sur la distribution, tu ne peux pas vendre un support que tu n'es pas capable d'assumer. Si demain, le développeur upstream décède ou refuse de corriger le bogue (genre tu tombes sur un disciple d'Ulrich Drepper), tu réponds quoi à ton client ? Même si tu n'as pas vocation à participer à tout les développements, faut avoir la capacité de répondre au problème si besoin est.
On peut le voir ainsi, ouvrir un bug en upstream aurait suffi, puis pourquoi ne pas l'avoir fait pour Debian (plus logique), SuSE ou Mandriva ?
> mais dire qu'ils sous-traitent vers Fedora c'est pas vrai.
Je force le trait (histoire de pimenter la discussion), mais ce genre de scénario commence à être un peu trop fréquent pour ne pas être suspect. Surtout que derrière, il y a rarement des remontées vers Fedora.
Qu'on le veuille ou non, Canonical fait partie du paysage et le problème des ressources humaines et des relations avec upstream ne voit toujours pas un début de solution depuis environ 6 ans. Ça nuit à Canonical, et ça n'est pas dans l'intérêt du logiciel libre (un Canonical à la traine techniquement, ça veut dire moins de bras pour corriger les bogues et écrire du code).
Récemment, c'est Upstart (qui est plus ou moins l'init standard des distros modernes) qui traine parce que son mainteneur n'arrive plus à dégager du temps pour bosser dessus ===> Lennart Poettering & cie qui démarre systemd.
C'est d'autant plus regrettable que Canonical a mené une réflexion intéressante sur les outils et la collaboration (j'ai lu un billet très intéressant sur le processus de traduction à ce sujet sur planet ubuntu cette semaine) à travers bazaar, Launchpad mais ne semble jamais aller jusqu'au bout de la démarche.
Par exemple, la faculté qu'à Launchpad de suivre un ticket sur un tracker distant (excellent!) ne semble pas avoir sa contrepartie naturelle: pouvoir signaler sur celui-ci les changements intéressants.
La synchronisation que souhaite tant Shuttleworth est finalement à portée de main mais ça demande plus de mains (et des mains expérimentées) et d'achever le travail sur les outils. Une fois ce pallier franchi, Canonical aura toutes les cartes en main pour devenir un géant.
> D'ailleurs ceux qui font la formation en école, ça se voit : 17h30 départ, même si le serveur est en feu, l'admin mort dans l'incendie et que le patron a besoin du fichier qui est sur le serveur en feu.
je préfère démissionner que de me brûler au 5ème degré et de me retrouver handicapé à vie dans le meilleur des cas pour un fichier à la con.
L'article en question parle du système de démarrage sous GNU/Linux et il y a une partie sur Upstart puis une bafouille sur launchd (très bon article au passage).
Launchd est sous licence Apache 2.0, ça se configure à l'aide de fichiers plist (un format xml somme toute classique), avec des outils amicaux. OS X démarre très rapidement et c'est très agréable d'utilisation mais mon expérience s'arrête là. :o) http://developer.apple.com/macosx/launchd.html
Il avait été un temps évoqué d'utiliser launchd dans Fedora mais le choix s'est porté sur Upstart qui semblait prometteur et très actif à l'époque (c'était déjà Harald Hoyer qui s'en occupait côté Fedora)
Juste Ubuntu, alors.
Pour Fedora, c'est l'audio terrorist himself qui s'est occupé de l'intégration, les mainteneurs Debian, et Mandriva ont eu l'idée saugrenue de lui demander conseil et chose surprenante, il les a aidé. En revanche, Ubuntu a intégré PA à la va-vite sans même prendre le temps de lire le wiki ou les listes de diffusions alors que de l'aveu même de son auteur, ça demande quelques efforts d'adaptation (des patchs pour le kernel, alsa, applications, etc ..). OpenSuSE eux avaient eu le bon goût de fournir des paquets défraichis avec des bogues corrigés dans des versions publiés quelques mois avant.
La première étape pour devenir un bon mainteneur de distribution, c'est de communiquer avec upstream, avec PA c'est même indispensable sinon on coure droit à la catastrophe.
Gwibber n'est pas une application mono mais python + desktopcouch (responsable d'une bonne partie du bloat des dernières versions)
> Fedora 13 qui inclura tous ces logiciels par défaut pour éviter d'avoir des applications Mono.
Ce choix est principalement motivé par le fait que la place est de plus en plus limité dans les médias et qu'inclure Mono juste pour Tomboy (F-Spot n'a jamais été fourni par défaut, il me semble) c'était de l'espace gâché. Surtout que Gtkmm était déjà présent pour d'autres trucs.
Derrière, on offre Mono et bon nombre de logiciels basés sur cette plateforme dans les dépôts, la seule exception étant Moonlight qui pose des problèmes légaux spécifiques. https://fedoraproject.org/wiki/ForbiddenItems#Moonlight
Officiellement, Fedora n'évite pas Mono, tout au plus, on veille à ne pas multiplier les VM (y a déjà python, perl par défaut, voire Java)
> Justement l'intégration de Nouveau dans Fedora alors qu'il n'était pas présent Upstream dans le noyau a fait polémique sur la LKML
Pas tout à fait, Nouveau est par défaut depuis Fedora 11 (présent dans les dépôts depuis Fedora 7) et Linus se demandait pourquoi 9 mois après, ça n'était pas intégré dans la branche master.
Linus a eu raison de taper une gueulante, certes les mainteneurs de Nouveau estimaient que ce n'était pas prêt à être intégré mais fallait bien un jour se décider à le faire.
Fedora a un rôle d'expérimentation, ça permet d'évaluer et améliorer de nouvelle technologies, au niveau du noyau, ça a été la nouvelle stack WiFi tiré de la branche Linville, puis JuJu la stack firewire, mais l'objectif final c'est d'être intégré au tronc sinon à la poubelle. C'est le rôle de Linus de donner des claques quand c'est nécessaire.
En proposant Nouveau puis en le mettant par défaut (sans oublier les tests days), ça a permis de booster un peu le développement de celui-ci. Il y a 3 ans, Nouveau supportait juste la 2D (et c'était très poussif) et aujourd'hui, Nouveau offre un support décent de la 3D, certes ce n'est pas parfait, mais c'est mieux que NV, et c'est un premier pas pour se débarrasser du pilote propriomerdique.
Et c'est grâce à toutes les distributions (pas seulement Fedora, mais également mandriva, opensuse, gentoo etc ...) que c'est possible, et ce sans esbrouffe.
> Je vais faire un paragraphe là dessus dans la prochaine news noyau.
C'est très bien !
> Mais bien sur... "il" est fatalement le seul dans le monde à apprécier d'utiliser les réseaux sociaux...
Je soulignais l'absence d'une fonctionnalité importante dans la dépếche, d'autant plus surprenante que celle-ci est poussée par le dictateur en chef de la distribution.
Mais visiblement certains ont des problèmes de compréhensions profonds puisqu'ils arrivent à voir une critique de la dite fonctionnalité là où il n'y en a pas.
La grande nouveauté de cette version, c'est justement l'ouverture aux réseaux sociaux, avec Gwibber, MeMenu, le music store, etc ... est-ce que j'ai dis que c'est de la merde ? non, ça a son public et c'est très bien, je les encourage même à développer leur propre vision du desktop. C'est en expérimentant qu'on fait évoluer les choses, on peut même tirer des enseignements des ratages (Cf Online Desktop, Luminocity qui ont respectivement influencé GNOME-shell, Compiz puis Mutter)
> "il"
$ sudo apt-get install humour second-degré
T'as pas fait le rapprochement avec IronMan où bien tu vis dans une cave. Comme IronMan a son joujou en métal, "il" (pour respecter ta terminologie) a son joujou ubuntu, mais bon j'allais pas l'appeler CacaMan, j'ai préféré faire référence au matériau des CD dont il arrose ses fidèles.
> En d'autres temps tu aurais râlé sur l'intégration d'outils de lecture de musique numérique sous prétexte que "il" a décidé d'en intégrer dans la distribution ?
Puisque tu veux parler des sujets qui fâchent, fâchons-nous joyeusement !
Je râle quand on prétends soutenir nouveau et qu'il faut attendre 3 ans pour le voir dans les dépôts (et que rien ne s'est fait entre temps), je râle quand on prétends synchroniser les distros quand on ne fait pas l'effort de collaborer en upstream, je râle quand on pousse les pilotes propriétaires, les services propriétaires et qu'on joue au guru du libre, je râle quand on entretient la confusion entre logiciel libre/pas libre (Cf Ubuntu One, conditions d'utilisations de la marque)
Tu peux pas vendre Ubuntu en tant que distribution libre et communautaire (Cf l'excellent livre de Jono Bacon sur la construction des communautés) quand on intègre de plus en plus de services propriétaires et quand toutes les décisions sont prises par une société et que les membres du conseil communautaire sont tous nommés par le dictateur.
Ce sont des faits, t'auras beau les triturer dans tout les sens, ils restent là.
> Il est clair que tu fais une allergie et que ça t'empêche de prendre du recul par rapport à la personne tout comme pour la distribution.
Merci du conseil, mais question recul et aigritude, je ne crois pas que tu ais quelque chose à m'apprendre. Dès qu'on touche au guru on a la horde des zélotes au cul ! On m'aurait pendu si je l'avais appelé par des noms d'oiseaux ?
Le principal de problème de PA c'est que derrière t'as ALSA et tout les pilotes pourris qui vont avec. T'as deux stratégies, soit tu fais avec et tu bidouilles ton daemon pour contourner les bogues (arts et ESD ont montré que cette solution avait des limites), soit tu retrousses les manches et tu aides à corriger les bogues dans ALSA.
Le mec a sévi sur d'autres projets (il est également le dictateur d'Avahi entre autre)
Ce qui est intéressant dans la conception de systemd, c'est qu'il a mis en parrallèle son expérience d'écriture de daemon (Cf libdaemon). Au final, le système est plus simple, plus léger et point important simplifie l'écriture de daemon (donc potentiellement moins de bogues).
Si les développeurs de systemd arrive à créer une réelle dynamique autour du projet, ça pourrait d'ici un an, se retrouver sur bon nombre de machines.
[^] # Re: API ?
Posté par GeneralZod . En réponse au journal Pulseaudio vs JACK. Évalué à 2.
Non, la première version publique de GNOME est sortie avant que la partie graphique de GNUStep soit utilisable. Certes OpenStep était probablement une meilleure base de travail, mais les gens voulaient quelque chose d'utilisable le plus rapidement possible. GNOME n'a pas été démarré par la FSF (ni GNUStep d'ailleurs) mais avec la bénédiction de la FSF.
Il est arrivé la même chose avec Linux et le Hurd, à l'origine Linux comme GNOME c'était un bricolage qui a finalement pris le dessus sur le projet plus "carré" Hurd ou GNUStep.
Au moins GNUStep n'a pas connu le destin du Hurd ou presque.
> Et Qt est libre.
Aujourd'hui oui, ça ne l'était pas à l'époque des débuts de GNOME. Qt/X11 a été disponible sous une licence libre à la même période ou GNOME présentait une version fonctionnelle donc voilà.
[^] # Re: API ?
Posté par GeneralZod . En réponse au journal Pulseaudio vs JACK. Évalué à 0.
prétexte à quoi ? Qt n'était pas libre point barre, à l'époque, les gens avaient tenté de convaincre Trolltech de modifier la licence et/ou convaincre KDE d'utiliser autre chose.
> comme l'a prouve mono de plus a l'epoque
Prouver quoi ? Mono est libre, et ses fesses sont assurés par OIN.
[^] # Re: Et la timeline ?
Posté par GeneralZod . En réponse au journal Canonical FAIL. Évalué à 3.
Justement, il faut attendre plus d'un mois pour que ce bogue soit rapporté upstream, et en plus le mainteneur ubuntu lâche le merdier sur le bugzilla fedora dans l'espoir que le mainteneur fedora fasse son boulot (c'est à dire aider les développeurs upstream à corriger le bogue voire le corriger lui-même si il a les compétences).
> c'est un pauvre gars qui fait son boulot
Ce serait un incident isolé, certes mais c'est un problème structurel dans Canonical. Ok, ils n'ont pas les compétences pour corriger le bogue, mais de là à se défausser de leurs responsabilités d'intégrateurs ça devient grave. Entre le mainteneur X qui est débordé par les rapports de bogues, Kees Cook qui n'a pas le temps de suivre convenablement un bogue critique dans une version LTS (et qui aurait dû probablement être un release blocker), il est urgent d'agir.
Il faut soit recruter plus de monde, soit restreindre les paquets couverts par le support et laisser plus de place à la communauté dans la gestion technique (un peu comme Fedora avant FC6 Core/Extras).
En l'occurrence, ce n'est pas sur le seul Kees Cook qu'il faut taper, mais sur l'employeur qui ne lui permet pas de faire son boulot dans de bonnes conditions.
[^] # Re: API ?
Posté par GeneralZod . En réponse au journal Pulseaudio vs JACK. Évalué à 10.
À l'origine, c'est surtout que Qt était pas libre d'où la recherche d'une alternative libre (Gtk+).
Quant au choix de C, c'est surtout dû à la facilité d'écrire des bindings et de permettre d'écrire des applications GNOME dans une variété de langages. Là où KDE estimait que C++ se suffit à lui-même, GNOME a préféré laisser le choix du langage.
GNOME n'est pas écrit entièrement en C, seul le coeur l'est, les applications GNOME sont écrites dans une variété de langage: C++, Python, Javascript, C# etc ...
Pour Vala, l'intérêt c'est d'avoir un langage de haut niveau simple (pas comme C++), performant (pas comme C#, Java) et qui soit 100% interopérable avec le C.
Avec l'arrivée de GI (GObject Introspection), l'écriture de bindings sera encore plus facile (voire s'en passer).
C/GObject était et reste encore un choix pertinent, si tu veux des plantages de GNOME, c'est du côté de Bonobo et des libgnome* qu'il faut voir.
De son côté, KDE pousse un peu plus les bindings (grâce à smoke entre autre), pour autant, je vais pas dire non plus que le choix de C++ est un échec de KDE. Faut replacer chaque chose dans son contexte.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par GeneralZod . En réponse au journal Pulseaudio vs JACK. Évalué à 3.
Note que motorola a quitté LiMo fin 2009 et que Samsung investit de plus en plus dans Android, les derniers mobiles LiMo sont des Necs principalement vendus au Japon.
Ce n'est pas surprenant vu qu'ils n'ont pas su vendre leur plateforme auprès du grand public (malgré le succès commercial de certains mobiles), des développeurs, l'arrivée tardive des smartphones.
[^] # Re: Bof
Posté par GeneralZod . En réponse au journal Canonical FAIL. Évalué à 2.
[^] # Re: Bof
Posté par GeneralZod . En réponse au journal Canonical FAIL. Évalué à 2.
Red Hat != Fedora, ce n'est pas parce qu'un mec travaille chez RH, que forcément il bosse également sur Fedora (plus de 80% des contributeurs sont issus de la communauté).
Et même si c'est le cas, il est quasi certain que tu tomberas sur les mêmes personnes sur le tracker upstream, donc quel est l'intérêt ? ext4, ce n'est pas un projet Fedora, t'as une belle brochette d'experts en dehors de Fedora (Google en emploie quelqu'un).
Par contre, le bug concerne une LTS (donc une version avec du support commercial), Canonical semble pas fichu de le corriger et n'a pas l'envie/le temps de suivre la résolution du problème avec upstream. Donc la théorie, je refile le bébé au mainteneur Fedora et les laisse se démerder avec upstream pour corriger le bogue, c'est pas déconnant du tout non plus.
Un bon mainteneur n'est pas forcément un bon développeur, être capable de remonter les bogues, les informations pertinentes, être à l'écoute des utilisateurs et des mainteneurs, c'est déjà pas mal.
Theodore T'so ne s'est pas trompé, ça demande de libérer du temps à l'équipe technique (donc embaucher du personnel), ça demande d'avoir des experts (soit en les embauchant, soit en les formant) et de savoir les retenir (cadre de travail agréable, paie conséquente).
[^] # Re: Pulseaudio sur des téléphones ?
Posté par GeneralZod . En réponse au journal Pulseaudio vs JACK. Évalué à 3.
Jusqu'à présent, LiMo se concentre sur les mobiles en milieu de gamme donc ça chiffre pas mal en volumes. La plateforme est mature, les composants sont standardisés (notamment téléphonie), mais ils ont manqués d'ambition (ils ont loupés le coche des smartphones) et le côté consortium industriel fermé n'a pas aidé à constituer une communauté autour.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par GeneralZod . En réponse au journal Pulseaudio vs JACK. Évalué à 2.
Lors du dernier Linux Plumbers Conferences, deux conférences portaient sur PA et l'embarqué (dont l'une plus particulièrement avec le N900)
[^] # Re: Web 0.1
Posté par GeneralZod . En réponse au journal Canonical FAIL. Évalué à 3.
[^] # Re: Web 0.1
Posté par GeneralZod . En réponse au journal Canonical FAIL. Évalué à 2.
Je m'en souviendrais pour le prochain journal "xxxxx FAIL" (qui portera sur une autre distribution)
[^] # Re: Web 0.1
Posté par GeneralZod . En réponse au journal Canonical FAIL. Évalué à 1.
taiste
* syntaxe recommandée dans l'aide mais moche en plein milieu d'un texte.
[https://linuxfr.org/~GeneralZod/29685.html]
C'est pas satisfaisant, mais faute de mieux (si vous avez des suggestions, je suis preneur).
Quant au désordre, comme j'ai l'habitude de déconstruire/reconstruire la structure de mes textes, ça m'arrive souvent.
[^] # Re: Exagéré
Posté par GeneralZod . En réponse au journal Canonical FAIL. Évalué à 9.
Pour moi, il était plus logique qu'il commence par rapporter le problème chez Debian, d'une part parce qu'Ubuntu se synchronise régulièrement dessus, d'autre part parce que c'est un DD.
[^] # Re: Bof
Posté par GeneralZod . En réponse au journal Canonical FAIL. Évalué à 6.
Rapporter le bogue upstream: OK (upstream comprenant bien évidemment Debian dans leur cas)
Rapporter le bogue chez les autres distributions: pourquoi pas, si derrière il y a un échange constructif (j'aurais applaudi des nageoires si c'était le cas). Mais de là à refiler le boulot à une autre distribution et rester peinard à attendre la solution, c'est plutôt moyen comme habitude.
Surtout quand le grand patron fait des belles phrases sur la collaboration entre les distros.
> Que les distributions doivent participer aux développements en finançant des développeurs, d'accord, mais leur rôle c'est l'intégration au départ
Le problème c'est que la société vends du support sur la distribution, tu ne peux pas vendre un support que tu n'es pas capable d'assumer. Si demain, le développeur upstream décède ou refuse de corriger le bogue (genre tu tombes sur un disciple d'Ulrich Drepper), tu réponds quoi à ton client ? Même si tu n'as pas vocation à participer à tout les développements, faut avoir la capacité de répondre au problème si besoin est.
[^] # Re: XLusive
Posté par GeneralZod . En réponse au journal Canonical FAIL. Évalué à 2.
Je ne relèverais pas les autres imbécilités.
[^] # Re: Exagéré
Posté par GeneralZod . En réponse au journal Canonical FAIL. Évalué à 9.
On peut le voir ainsi, ouvrir un bug en upstream aurait suffi, puis pourquoi ne pas l'avoir fait pour Debian (plus logique), SuSE ou Mandriva ?
> mais dire qu'ils sous-traitent vers Fedora c'est pas vrai.
Je force le trait (histoire de pimenter la discussion), mais ce genre de scénario commence à être un peu trop fréquent pour ne pas être suspect. Surtout que derrière, il y a rarement des remontées vers Fedora.
Qu'on le veuille ou non, Canonical fait partie du paysage et le problème des ressources humaines et des relations avec upstream ne voit toujours pas un début de solution depuis environ 6 ans. Ça nuit à Canonical, et ça n'est pas dans l'intérêt du logiciel libre (un Canonical à la traine techniquement, ça veut dire moins de bras pour corriger les bogues et écrire du code).
Récemment, c'est Upstart (qui est plus ou moins l'init standard des distros modernes) qui traine parce que son mainteneur n'arrive plus à dégager du temps pour bosser dessus ===> Lennart Poettering & cie qui démarre systemd.
C'est d'autant plus regrettable que Canonical a mené une réflexion intéressante sur les outils et la collaboration (j'ai lu un billet très intéressant sur le processus de traduction à ce sujet sur planet ubuntu cette semaine) à travers bazaar, Launchpad mais ne semble jamais aller jusqu'au bout de la démarche.
Par exemple, la faculté qu'à Launchpad de suivre un ticket sur un tracker distant (excellent!) ne semble pas avoir sa contrepartie naturelle: pouvoir signaler sur celui-ci les changements intéressants.
La synchronisation que souhaite tant Shuttleworth est finalement à portée de main mais ça demande plus de mains (et des mains expérimentées) et d'achever le travail sur les outils. Une fois ce pallier franchi, Canonical aura toutes les cartes en main pour devenir un géant.
[^] # Re: Rien de nouveau sous le soleil ...
Posté par GeneralZod . En réponse au journal [HS] Favi, l'entreprise sans chef.. Évalué à 10.
je préfère démissionner que de me brûler au 5ème degré et de me retrouver handicapé à vie dans le meilleur des cas pour un fichier à la con.
[^] # Re: launchd?
Posté par GeneralZod . En réponse au journal Rethinking PID 1. Évalué à 2.
Launchd est sous licence Apache 2.0, ça se configure à l'aide de fichiers plist (un format xml somme toute classique), avec des outils amicaux. OS X démarre très rapidement et c'est très agréable d'utilisation mais mon expérience s'arrête là. :o)
http://developer.apple.com/macosx/launchd.html
Il avait été un temps évoqué d'utiliser launchd dans Fedora mais le choix s'est porté sur Upstart qui semblait prometteur et très actif à l'époque (c'était déjà Harald Hoyer qui s'en occupait côté Fedora)
[^] # Re: [:Mouaifff]
Posté par GeneralZod . En réponse au journal Rethinking PID 1. Évalué à 7.
Pour Fedora, c'est l'audio terrorist himself qui s'est occupé de l'intégration, les mainteneurs Debian, et Mandriva ont eu l'idée saugrenue de lui demander conseil et chose surprenante, il les a aidé. En revanche, Ubuntu a intégré PA à la va-vite sans même prendre le temps de lire le wiki ou les listes de diffusions alors que de l'aveu même de son auteur, ça demande quelques efforts d'adaptation (des patchs pour le kernel, alsa, applications, etc ..). OpenSuSE eux avaient eu le bon goût de fournir des paquets défraichis avec des bogues corrigés dans des versions publiés quelques mois avant.
La première étape pour devenir un bon mainteneur de distribution, c'est de communiquer avec upstream, avec PA c'est même indispensable sinon on coure droit à la catastrophe.
LP s'était expliqué à ce sujet après une série d'articles négatifs (limite violents) sur PA:
http://0pointer.de/blog/projects/jeffrey-stedfast.html
[^] # Re: MeMenu & les kikoololeries
Posté par GeneralZod . En réponse à la dépêche Ubuntu 10.04 est sortie. Évalué à 2.
> Pour le 2.6.34 il y a eu une nouvelle flame war car l'API de Nouveau a changé et donc Linus a gueulé comme un putois.
Ça devait être bien fendard, mais il peut pas dire qu'on ne l'avais pas prévenu. J'ai encore plus hâte de lire la prochaine dépêche. :o)
[^] # Re: Mono
Posté par GeneralZod . En réponse à la dépêche Ubuntu 10.04 est sortie. Évalué à 3.
> Fedora 13 qui inclura tous ces logiciels par défaut pour éviter d'avoir des applications Mono.
Ce choix est principalement motivé par le fait que la place est de plus en plus limité dans les médias et qu'inclure Mono juste pour Tomboy (F-Spot n'a jamais été fourni par défaut, il me semble) c'était de l'espace gâché. Surtout que Gtkmm était déjà présent pour d'autres trucs.
Derrière, on offre Mono et bon nombre de logiciels basés sur cette plateforme dans les dépôts, la seule exception étant Moonlight qui pose des problèmes légaux spécifiques.
https://fedoraproject.org/wiki/ForbiddenItems#Moonlight
Officiellement, Fedora n'évite pas Mono, tout au plus, on veille à ne pas multiplier les VM (y a déjà python, perl par défaut, voire Java)
[^] # Re: MeMenu & les kikoololeries
Posté par GeneralZod . En réponse à la dépêche Ubuntu 10.04 est sortie. Évalué à 2.
Pas tout à fait, Nouveau est par défaut depuis Fedora 11 (présent dans les dépôts depuis Fedora 7) et Linus se demandait pourquoi 9 mois après, ça n'était pas intégré dans la branche master.
Linus a eu raison de taper une gueulante, certes les mainteneurs de Nouveau estimaient que ce n'était pas prêt à être intégré mais fallait bien un jour se décider à le faire.
Fedora a un rôle d'expérimentation, ça permet d'évaluer et améliorer de nouvelle technologies, au niveau du noyau, ça a été la nouvelle stack WiFi tiré de la branche Linville, puis JuJu la stack firewire, mais l'objectif final c'est d'être intégré au tronc sinon à la poubelle. C'est le rôle de Linus de donner des claques quand c'est nécessaire.
En proposant Nouveau puis en le mettant par défaut (sans oublier les tests days), ça a permis de booster un peu le développement de celui-ci. Il y a 3 ans, Nouveau supportait juste la 2D (et c'était très poussif) et aujourd'hui, Nouveau offre un support décent de la 3D, certes ce n'est pas parfait, mais c'est mieux que NV, et c'est un premier pas pour se débarrasser du pilote propriomerdique.
Et c'est grâce à toutes les distributions (pas seulement Fedora, mais également mandriva, opensuse, gentoo etc ...) que c'est possible, et ce sans esbrouffe.
> Je vais faire un paragraphe là dessus dans la prochaine news noyau.
C'est très bien !
[^] # Re: [:Mouaifff]
Posté par GeneralZod . En réponse au journal Rethinking PID 1. Évalué à 5.
[^] # Re: MeMenu & les kikoololeries
Posté par GeneralZod . En réponse à la dépêche Ubuntu 10.04 est sortie. Évalué à 5.
Je soulignais l'absence d'une fonctionnalité importante dans la dépếche, d'autant plus surprenante que celle-ci est poussée par le dictateur en chef de la distribution.
Mais visiblement certains ont des problèmes de compréhensions profonds puisqu'ils arrivent à voir une critique de la dite fonctionnalité là où il n'y en a pas.
La grande nouveauté de cette version, c'est justement l'ouverture aux réseaux sociaux, avec Gwibber, MeMenu, le music store, etc ... est-ce que j'ai dis que c'est de la merde ? non, ça a son public et c'est très bien, je les encourage même à développer leur propre vision du desktop. C'est en expérimentant qu'on fait évoluer les choses, on peut même tirer des enseignements des ratages (Cf Online Desktop, Luminocity qui ont respectivement influencé GNOME-shell, Compiz puis Mutter)
> "il"
$ sudo apt-get install humour second-degré
T'as pas fait le rapprochement avec IronMan où bien tu vis dans une cave. Comme IronMan a son joujou en métal, "il" (pour respecter ta terminologie) a son joujou ubuntu, mais bon j'allais pas l'appeler CacaMan, j'ai préféré faire référence au matériau des CD dont il arrose ses fidèles.
> En d'autres temps tu aurais râlé sur l'intégration d'outils de lecture de musique numérique sous prétexte que "il" a décidé d'en intégrer dans la distribution ?
Puisque tu veux parler des sujets qui fâchent, fâchons-nous joyeusement !
Je râle quand on prétends soutenir nouveau et qu'il faut attendre 3 ans pour le voir dans les dépôts (et que rien ne s'est fait entre temps), je râle quand on prétends synchroniser les distros quand on ne fait pas l'effort de collaborer en upstream, je râle quand on pousse les pilotes propriétaires, les services propriétaires et qu'on joue au guru du libre, je râle quand on entretient la confusion entre logiciel libre/pas libre (Cf Ubuntu One, conditions d'utilisations de la marque)
Tu peux pas vendre Ubuntu en tant que distribution libre et communautaire (Cf l'excellent livre de Jono Bacon sur la construction des communautés) quand on intègre de plus en plus de services propriétaires et quand toutes les décisions sont prises par une société et que les membres du conseil communautaire sont tous nommés par le dictateur.
Ce sont des faits, t'auras beau les triturer dans tout les sens, ils restent là.
> Il est clair que tu fais une allergie et que ça t'empêche de prendre du recul par rapport à la personne tout comme pour la distribution.
Merci du conseil, mais question recul et aigritude, je ne crois pas que tu ais quelque chose à m'apprendre. Dès qu'on touche au guru on a la horde des zélotes au cul ! On m'aurait pendu si je l'avais appelé par des noms d'oiseaux ?
[^] # Re: [:Mouaifff]
Posté par GeneralZod . En réponse au journal Rethinking PID 1. Évalué à 8.
Le mec a sévi sur d'autres projets (il est également le dictateur d'Avahi entre autre)
Ce qui est intéressant dans la conception de systemd, c'est qu'il a mis en parrallèle son expérience d'écriture de daemon (Cf libdaemon). Au final, le système est plus simple, plus léger et point important simplifie l'écriture de daemon (donc potentiellement moins de bogues).
Si les développeurs de systemd arrive à créer une réelle dynamique autour du projet, ça pourrait d'ici un an, se retrouver sur bon nombre de machines.