GeneralZod a écrit 2316 commentaires

Pour les hackfests, j'ai bien précisé celles relative au Shell. ;-)

> Je ne comprends pas où est le problème avec quelqu'un décidant de faire un nouveau desktop
On est d'accord, je pense même que Unity EST une piste intéressante à explorer.
Tout ce que je dis, c'est que Canonical a élaboré Unity en parallèle au Shell (et dans leur coin), ça doit certainement aller dans leur sens mais ce n'est pas parce que RH leur mettrait des batons dans les roues ou d'éventuelles tares du Shell (de par son architecture, il est très facile à étendre, modifier etc ... et contrairement à ce que l'article laisserait croire, n'a rien à envier niveau perfs à Unity).

Supposons que RedHat ait fomenté une cabale contre Canonical au sein de GNOME, ça voudrait dire que Novell, Intel, Nokia, collabora, Lanedo, Sun, Openismus etc ... et sans oublier le plus gros contributeur aka la communauté serait dans le coup ? ça ressemble plus à une mauvaise excuse qu'autre chose.

Faut arrêter de colporter des conneries, si Canonical veut participer à GNOME, faudrait commencer par proposer les patchs en upstream (et non pas au fin fond d'un serveur web), participer aux hackfest (ils n'ont visiblement pas été très présents pour celles relatives au Shell) etc ...

> Faux, Unity, ca n'as pas grand chose de révolutionnaire, c'est un doc vertical et quelques truc de gestion des fichier hors nautilus...

Comme le Shell en somme,dans un avenir proche, la sidebar devrait visuellement ressembler à un dock, il y aura même des indicateurs-like.
Unity et le Shell sont deux poussins de la même couvée, dire que l'un est révolutionnaire et l'autre non est un non-sens.

> Ce qui fait peur à Ubuntu, c'est clairement gnome-shell qui il est sure va casser les habitudes des utilisateurs.

Ce serait l'hôpital qui se fout de la charité, parce que Unity est tout aussi "déroutant" que le Shell à ce niveau-là. Je suppose que les ingénieurs de Canonical sont au courant que GNOME 3 incluera un environnement "classic" (un portage du bureau GNOME2 sur les nouvelles fondations).

C'est symptomatique du peu d'implication de Canonical dans GNOME, ça fait 2/3 ans que la communauté travaille sur l'avenir du bureau GNOME (notamment lors des hackfests) alors que Canonical travaillait dans son coin sur d'autres alternatives: UNE, le lanceur basé sur les EFL, Unity etc ... On notera également l'intérêt renouvelé de Canonical pour Qt4 (le CTO de Canonial a écrit un billet récemment http://mdzlog.alcor.net/2010/10/20/ubuntu-and-qt/ ===> mots-clés: ARM, multitouch, multiplateforme) et les interfaces tactiles.

Canonical est en train de forker une partie de GNOME (on peut être en désaccord avec ça mais c'est leur droit), après, l'avenir nous dira si ils ont eu raison ou pas. Pour ma part, je trouve qu'ils explorent des pistes intéressantes même si Gnome Shell est loin de démériter.

Les six gouines n'aiment pas les serpents ...

<troll>Ou qu'il cherche encore desesperement quelques nouveautes permettant de combler les vides de sa depeche ! GNOME 2.32 et son ChangeLog negatif n'aide pas !</troll>

Réponse 2, si tu es intéressé le mainteneur a écrit une série d'articles sur la programmation en D (en anglais et en français):
http://blog.fedora-fr.org/bioinfornatics/

La très grande majorité des développements propres à Fedora se font en Python, les infrastructures web utilisent principalement le framework TurboGears (à l'exception notable de Transifex qui utilise aujourd'hui Django mais ce n'est plus à proprement parler un projet Fedora)

Par exemple, pour construire les paquets, OBS utilise un environnement générique pour le chroot, les mises à jours ne sont pas récupérés automatiquement, ça n'aide pas à détecter les dépendances de compilations explicites (ie: c'est une des raisons pour laquelle debian et fedora utilisent des chroots minimalistes).
Plus prosaïquement, les recettes sont rapidement remplie d'instructions conditionnelles pour gérer les différences entre les distros, les paquets sont le plus génériques possible donc pas parfaitement adapté à la distributions, ils ne sont pas forcément compilés avec les mêmes flags etc ...

Bien sûr, on peut utiliser OBS pour gérer une distro mais tu perds l'avantage principal du service: rendre accessible aux développeurs la construction de paquets pour diverses cibles.

Je suis d'accord avec toi pour dire qu'OBS est un excellent service mais c'est destiné principalement aux développeurs qui veulent fournir des paquets binaires pour différentes distros - ce qui est justement ton cas - sans devoir maintenir un gazillion de machines de builds (virtuelles ou non).
Néanmoins, ça n'est pas un outil adéquat pour gérer un dépôt ou même une distro, tu perds l'intégration (pour reprendre l'exemple des init vu plus loin, un mainteneur upstream fournira un script sysV générique mais pas le job upstart ou l'unit systemd), les recettes deviennent rapidement fouillies pour gérer les différents cas, etc ...


Je tiens à souligner que Koji permet de construire des paquets pour TOUTES les distributions RPM. La gestion des dépendances étant fournie par yum, pour supporter une nouvelle distro, il suffit de générer les méta-données yum (à la base, c'est un format commun avec apt/rpm et smart) et de fournir un fichier de configuration avec l'adresses des mirroirs.
Après, fp.o n'a pas les ressources pour ouvrir son propre build service multi-distro RPM mais les outils sont libres, l'installation est pas trop compliquée. J'ai ouï dire que koji est en cours de packaging dans Debian (celà-dit mock l'utilitaire de chroot l'est depuis quelques années et permet de construire des paquets fedora conformes depuis debian ;-) )

> n'importe qui peut mettre en place un de ces dépôts

Non, ça implique que tu sois un contributeur Fedora (donc avoir accepté le CLA) et avoir accès au système de build (donc faire partie du groupe des mainteneurs).

> c'est aussi surveillé que les paquets présents dans les dépôts officiels?

Les paquets sont sous la responsabilité des mainteneurs, la seule restriction est que les paquets doivent respecter les guidelines Fedora (gage de qualité et d'intégrité libriste). La plupart du temps, les dépôts fedorapeople sont maintenus par le mainteneur des paquets dans la distribution ou un mainteneur expérimenté (je citerais l'exemple de remi et spot qui maintiennent respectivement les dépôts remi - LAMP- et Chromium).
C'est exactement le même problème avec les PPA et l'OBS, mais certains réfléchissent déjà à l'intégration de la QA dans COPR qui permettra d'automatiser entièrement la gestion des dépôts fedorapeople. Entre parenthèses, Fedora travaille sur un framework de tests qualité automatisés aka autoqa qui permet de lancer des tests lorsqu'un paquet est construit, soumis en tant que mise à jour etc ... Si COPR est un jour incorporé dans Koji, les dépôts fedorapeople en bénéficieront automatiquement (yakafokon en somme :o) )

Systemd se rapproche beaucoup de launchd (l'init d'Apple sous licence Apache), pour définir un service, on n'écrit plus un script shell mais un simple fichier de configuration (un format .ini like), donc on se débarasse de l'overhead lié au lancement d'un shell pour exécuter le job (upstart)/unit (systemd).
De plus, systemd est beaucoup plus aggressif qu'upstart pour la parallélisation des tâches et le lancement de services à la demande. Sous Fedora qui utilise encore des scripts d'init sysV, le démarrage est beaucoup plus rapide qu'avec upstart. Pour être honnête, il faudrait pouvoir utiliser les deux inits en utilisant des scripts/fichiers de configuration au format natif pour les différencier à ce niveau.

Par exemple, l'intégration de D-Bus dans systemd permet de parallèliser le lancement de services: si un service A requiert que le service B soit actif, plus besoin d'attendre que B soit lancé pour démarrer A, systemd s'arrange pour que D-Bus place les requêtes de A dans une file d'attente le temps que B ait fini de se lancer.

Systemd est assez bien fourni en outils d'administration (ligne de commande ou graphique) qui permettent de suivre l'état des processus (grâce à l'api cgroups du noyau linux entre autre).

Tu trouveras pas mal d'informations sur ce billet de Lennart:
http://0pointer.de/blog/projects/systemd.html

L'image a été composée il y a deux semaines juste avant la release candidate, donc à l'installation tu te retrouveras avec plus ou moins la dernière béta. En revanche, la release candidate d'ors et déjà disponible dans les mises à jours.

La version finale de GNOME 2.32 est prévue pour demain par ailleurs.

C'est un poil plus rustique que les ppa ou l'Open Build Service, les contributeurs ont accès au service de build Koji pour construire les paquets (et éventuellement des machines de tests pour les architectures "exotiques") mais la création du dépôt sur leur espace fedorapeople reste en partie artisanale.
À terme, le projet COPR (Cool Other Packages Repositories) devrait permettre d'intégrer ce genre de fonctionnalités directement via le service de build Koji et d'avoir des utilitaires plus chiadés.

Un VCS c'est avant tout un outil de travail, son boulot c'est de conserver un historique des modifications, et de faciliter le travail collaboratif (détecter les conflits voire les résoudre pour les plus triviaux).

Un DVCS permet le travail hors-ligne (le développeur a toujours accès à l'historique, peut commiter les modifications ==> gros avantage pour le travail collaboratif), des opérations beaucoup plus rapides car moins d'accès réseau, pour un outil aussi utilisé qu'un VCS c'est très important. La gestion des branches permet aux développeurs d'expérimenter plus facilement sans perturber le développement de la branche principale, de gérer différentes versions d'un même logiciel plus facilement (avec le cherry-picking/transplant, porter un bugfix deviendrait presque trivial), l'outillage de merge plus puissant de git/hg & cie facilite encore la vie des développeurs.
Sans oublier la souplesse des DVCS qui facilitent leur intégration dans les workflows (et notamment les outils de revue, la possibilité d'importer/exporter des patchs via mail sans perdre l'historique etc ...).

===> Git ou mercurial sont de bien meilleurs VCS que ne le sont CVS ou svn (et comme j'aime le répéter le meilleur client subversion s'appelle git ;-) )

Rien n'est plus faux que d'affirmer qu'un DVCS encourage le travail isolé, je dirais que c'est même le contraire. Par rapport à CVS (et dans une moindre mesure svn), git/hg permettent de s'abstraire des défauts de ces outils (accès réseau obligatoire, lenteurs, merge pourri, gestion des branches complexes, outils fragiles).

> "problème" Qt

Troll mort et enterré depuis au moins 2004, il existe un accord qui lie KDE eV et Trolltech qui permet à la KDE Qt Free Foundation (gérer à parité par les deux parties) de passer unilatéralement la dernière version open source sous licence BSD. Et ce droit est applicable à partir du moment, où douze mois se sont écoulés depuis la dernière version majeure (je précise pour les amis malcomprenants)

http://www.kde.org/community/whatiskde/kdefreeqtfoundation.p(...)

> on fait quoi ? un fork ? C'est super facile pour un petit projet comme ça.

Depuis que Qt utilise git et que Nokia encourage les contributions externes, c'est beaucoup moins irréaliste que feu Harmony. :o)

> Est-ce que ça marche aujourd'hui ?

oui, ça fonctionne. Il est déjà disponible pour Fedora 14 (la béta sort en fin de semaine)

> Le support de Python avait l'air quand même assez ridicule, l'utilisation de boost allait bouffer des tonnes de mémoire, et j'en passe.

PySide n'utilise plus Boost.Python mais son propre générateur de bindings aka shiboken basé sur QtCore et l'api CPython.

> La dernière fois que j'ai regardé, ça avait l'air d'un projet de loser

Depuis le passage à shiboken, l'API est moins "bizarre", la documentation est très bien fournie (avec des exemples et tout), PySide supporte également QtMobility.
Même si PyQt4 a frôlé l'excellence (meilleur toolkit Python multiplateforme, premier toolkit à supporter Python3 -- Tkinter ne compte pas c'est une bouse), PySide est bien parti pour le taquiner d'ici quelque temps.

> Ce dernier est open source mais propriété d'oracle.
Tu noteras que c'est également le cas pour MyISAM.

> A l'origine ces softs fonctionnaient avec MySql mais depuis le rachat par Oracle cette option n'est plus supportée

Quelle boite et quels softs ? ça me semble curieux qu'Oracle retire le support d'un de ses produits dans un autre, à moins que le rachat de cette boite a eu lieu avant le rachat de Sun (et donc MySQL).

> Enfin Oracle est-il passé sur IIS ? ...

Le lien est cassé, mais la plupart des sites d'Oracle utilisent Oracle HTTP Server une variante propriétaire d'Apache (du moins ceux que BigIP ne masquent pas)

Actuellement, Novell c'est deux business units (depuis fin 2009): la première dédiée aux solutions collaborative (groupwise, stockage, netware etc ..) et la seconde axée sécurité, gestion d'utilisateurs et open source. À priori, je vois pas pourquoi Novell s'amuserait à se redécouper 9 mois plus tard (ça a un coût non négligeable et il est probable qu'ils envisageaient cette possibilité déjà à l'époque) même si on peut transférer quelques trucs peut-être les solutions de sécurité et gestion d'utilisateurs activités historiques de Novell, quant à l'ancienne business unit open source (en gros feu ximian et feu SuSE) c'est déjà bien imbriqué.

Si il est possible de se débarrasser de Mono, l'accord avec Microsoft lui engage toute la partie open source (SuSE, mono, OOo) donc à moins de négocier une porte de sortie avec Microsoft ce serait très risqué pour RH.

Oracle n'a toujours pas fini de digérer Sun, ils possédent déjà deux distributions *nix: Solaris et Unbreakable Linux, ils ont Java ===> aucun intérêt à récupérer Novell SuSE et Mono sauf à se lancer sur le desktop ce qui ne les intéressent pas.
RH pourrait être intéressé par la partie desktop de SuSE (en fait, ils ont embauchés quelques anciens de Novell récemment) mais à moins de se débarasser de l'encombrant accord avec Microsoft et de lever tout doute autour de Mono (qui pourrait céder à MDI & cie comme ils l'ont fait avec ecOS) c'est improbable.

Le candidat le plus sérieux au rachat de Novell est clairement VMware mais le portefeuille de propriétés intellectuelles de Novell attirera certainement les vautours.
Reste IBM (think go-ooo), SAP, et pourquoi pas Microsoft (enfin, avec monkey boy ballmer, faut pas rêver mais ça pourrait être une stratégie intéressante pour eux)

chromium ==> webkit/chromium
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)

> 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 ?

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.

Le problème de versions est limite mineur dans le cas de Chromium, d'une révision à une autre le code peut être totalement chamboulé (suffisamment pour rendre pénible le portage des patchs et casser des trucs au passage), celui-ci inclut beaucoup de bibliothèques tierces modifiés (parfois pour des raisons cosmétiques) dont libxml, libjingle, zlib, sqlite, icu etc ... Sans compter la taille monstrueuse du code qui ne facilite pas la tâche, une mise à jour de chromium ça prends beaucoup de temps.

> 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.

En l'état actuel des choses, Chromium n'est pas prêt pour être distribué dans les dépôts "stables" des distributions pour une simple et bonne raison: Google est apparemment incapable de travailler avec les projets upstreams et les empaqueteurs.
http://spot.livejournal.com/312320.html

Jusqu'à présent le média de prédilection d'Ubuntu est le CD vif or un CD c'est limité en espace ===> la voilà ton explication.
Néanmoins, rien n'empêche de développer un frontend Gtk+ pour la libVLC.

Premièrement, c'est un PowerMac old world ou new world (pour les distinguer, les new world ont au moins un port USB), parce que si c'est le premier cas, ton choix est beaucoup plus restreint (par ex. dans le cas de Fedora, ça requiert un bootloader spécial pour les old world et qui n'est pas fourni par la distribution).
Je privilégierais Debian, parce que même si Yellow Dog est bien optimisé sur PowerPC, il me semble que c'est plus vraiment supporté les G3