Bon ok, tu t'obstines dans ton raisonnement, tant pis, depuis le début je te dis que je parle pas de la meme chose que toi, mais c'est pas grave.
L'hôpital qui se fout de la charité ... Je dis que Unity ce n'est pas GNOME et n'a qu'une filiation extrêmement tenu avec le projet mais tu soutiens mordicus que Unity c'est GNOME envers et contre tout.
Voilà ce que ca donne si on suit ta logique, désormais, on dira nautilus du projet Unity, ca fera plaisir aux devs GNOME je pense...
Tu vas arrêter de dire n'importe quoi ? Réutiliser quelques applications/services GNOME ou partager des bibliothèques communes ne font pas de Unity GNOME ou un bureau basé sur GNOME.
Sinon, sur le fait que Canonical fasse bande à part, le projet GNOME n'a qu'à avoir un comportement plus ouvert vis à vis de l'écosystème qui l'entour et les choses iraient surement beaucoup mieux
C'est bizarre que seul Canonical ait des "soucis" à contribuer avec le projet GNOME, si on exclut la cabale RH (qui veut la mort de Canonical et tient otage tout le projet), parmi les gens qui n'ont aucun problème avec GNOME reste: SuSE, Openismus, Lanedo, Igalia, Collabora, Intel, Litl, Fluendo, Nokia, codethink, mozilla etc ...
À propos du fameux GNOME census sur le 1% de Canonical dans GNOME, Jono Bacon expliquait que Canonical avait fait le choix de développer sa vision du bureau non pas contre GNOME mais parce qu'ils ont des objectifs et une approche différente. Encore une fois, il n'y a pas de "méchants" dans l'histoire, juste des choix différents et quelques incompréhensions ponctuelles.
C'est marrant y'a pas ce genre de problèmes avec Ayatana et KDE, le dialogue de ce coté là est ouvert!
Canonical n'a pas (encore?) forké KDE, donc forcément, ça apaise les relations (ironie inside). Sinon, cherche les réactions des gens de Nokia et de KDE aux initiatives de Canonical vis à vis de Qt (comme par exemple, intégrer le support de dconf dans Qt voire dans KDE - ce qui a fait hurlé Aaron Seigo qui hait dconf -).
Les classes ou fonctions templates non utilisées ne sont pas compilés. Ça ne résout pas le problème, mais ça peut constituer une partie de la solution.
Mais ou j'ai dit que les devs de GNOME bossait sur Unity
Faut savoir ce que tu dis, Unity c'est GNOME ou pas GNOME ?
Toi tu dis "Unity n'est pas basé sur GNOME3" ce qui est un énorme mensonge
La version stable d'Unity repose toujours sur la plateforme GNOME2 (Unity-Gtk3 est encore en cours de développement). Unity c'est GNOME3 mais ça n'a pas besoin de la plateforme GNOME3, ok, c'est moi le menteur ...
Whaou, sous KDE aussi non de dieu, c'est trop fort!
Si on suit ton raisonnement précédent, KDE4 c'est GNOME3. Logique imparable !
Montres moi dans les libs des applis ou dans les applis ce que Canonical refait en double...
C'est vrai que proposer une interface utilisateur complétement différente ne justifie pas le fait que Unity soit un bureau différent de GNOME.
NotifyOSD ==> daemon de notification fd.o GNOME
appindicators ==> symbolic icons
MeMenu ==> le machin en haut à droite du shell
Lightdm ==> gdm (à l'origine, Canonical devait bosser sur un nouveau greeter - le simple greeter était juste un hack en attendant ce dernier -, mais ils ont fini par réécrire un nouveau DM qui a le bon goût d'être moins fonctionnel que "new" GDM -ce qui en soit est déjà un exploit- précision: une fonctionnalité inexistante dans lightdm: l'accessibilité)
bamf ==> le mécanisme d'application matching dans la glib
Unity nécessite des versions patchées de Gtk+ (certains patchs ont été déjà refusés). La tendance actuelle, c'est que le temps s'écoulera, plus Unity et GNOME divergeront et ça ne s'arrange pas.
Pour arranger le tout, Unity et GNOME Shell ont tout deux choisi une politique d'intégration très poussée des applications dans le shell (Unity propose même une libunity).
GNOME Shell et Unity ne reposent pas du tout sur les mêmes technos: Mutter/Compiz, GJS/Vala, lenses Unity etc ... mais Unity c'est quand même GNOME. Parce qu'un bureau développé par des gens indépendamment du projet GNOME, dans une infrastructure externe à GNOME, avec une architecture différente (qui je le reconnais est beaucoup plus réfléchi que celle de GNOME Shell actuellement), avec des divergences irréconciliables, c'est GNOME que les gens de GNOME le veuillent ou non !
Il faudrait peut être suivre un peu l'actualité d'un projet avant de le critiquer, non ?
Je suppose que tu parles pour Unity ? Je vais te décevoir, mais je m'intéresse de près à l'évolution du projet
Le projet parapluie qui héberge Unity: Ayatana est en train de redévelopper pas mal de briques existantes dans GNOME3: https://wiki.ubuntu.com/Ayatana https://launchpad.net/ayatana
Bien sur que si Unity c'est GNOME3!
Uniquement dans le discours marketing de Canonical, Unity a été conçu en dehors de GNOME, sans même aucune concertation avec le projet.
La réflexion autour de GNOME3 est presque aussi vieille que Canonical (aussi loin que je m'en rappelle Havoc Pennington en parlait déjà en 2005). Les fondations de GNOME Shell ont été jeté fin 2008 (le premier commit dans Unity date de fin 2009) et je te défie de démontrer qu'il y a eu un désaccord technique entre les ingénieurs de Canonical et le reste de la communauté GNOME.
Unity est un projet indépendant de GNOME, tu peux réécrire l'histoire autant de fois que tu voudras mais ça ne changera pas ce fait.
Y'a juste deux shells: Unity d'un coté et Gnome-shell de l'autre mais sinon la base est identique...
Non, le projet GNOME ne maintient qu'un seul Shell: GNOME-Shell.
XFCE partage également des fondations communes avec GNOME, tu peux utiliser aussi une partie des services fournis par GNOME mais ça n'est pas GNOME tout comme Unity n'est pas ou plus GNOME.
Le fait que Unity ne soit pas GNOME ou développé en dehors de GNOME n'a rien de péjoratif, c'est un projet tout aussi légitime que GNOME Shell (et tout aussi prometteur).
gnome 3 sans gnome-shell mais avec Unity, ça rentre pas dans cases...
Unity n'est GNOME3, ça n'utilise même pas la plateforme GNOME 3 à l'heure actuelle, et Canonical réécrit une bonne partie de la plateforme. Unity n'est pas GNOME, Unity n'est pas basé sur GNOME (sinon XFCE est aussi "basé" sur GNOME à ce compte-là), c'est un nouveau bureau avec ses avantages et ses inconvénients.
La plupart du temps, c'est dû au fait que la tarball a été généré avec une version plus ancienne de la chaine autotools (soit parce que c'est qu'utilise le mainteneur upstream, soit parce que cette dernière a été mise à jour depuis la dernière release du projet).
Ça arrive fréquemment lors des cycles de développement, où la chaine autotools est très récente (ça permet de tester celle-ci, et de détecter quelques gruikeries également que l'on remonte en upstream). Même avec des projets très réactifs et avec un très bon niveau d'expertise avec autotools (ie: GNOME), il m'arrive parfois de devoir regénérer la chaine temporairement en attendant la prochaine release.
Pour avoir rédigé cette partie, je ne suis pas d'accord sur ce que tu qualifies d'approximations.
il y a une commande fournie avec les autotools (autoreconf) qui remplace avantageusement les scripts autogen.sh fait maison
Pouvoir regénérer correctement le système de construction avec autoreconf est malheureusement l'exception et non pas la règle. Et c'est l'empaqueteur qui te parle. Et même quand ça passe, ça ne garantit absolument pas l'absence d'effets de bords au point que certains en déconseillent l'utilisation ou bien de s'en servir comme base pour patcher directement le système de construction. http://www.redhat.com/archives/rhl-devel-list/2008-October/msg00866.html
il y a eu effectivement des incompatibilités entre versions, particulièrement la version 1.4 qui date de l'an 2000, et celles qui ont suivi, mais rien d'exceptionnel par rapport à d'autres outils
Pourquoi la majorité des distributions GNU/Linux fournissent encore autoconf 2.13 (sorti en 1999) ? Pourquoi Debian maintient 4 version d'automake, Fedora 5 ? (non, ce n'est pas par plaisir) Même si le nombre décroit petit à petit, tu as encore des paquets qui ont encore besoin de ces versions (autoreconf et autogen.sh ne peuvent pas grand chose la plupart du temps, patcher reviendrait à remettre à plat le système de construction). Ok, ça s'améliore, mais on est encore loin des autres outils en ce domaine.
Certes, c'est symptomatique d'une mauvaise utilisation d'autotools, mais un développeur qui maitrise autotools (malgré qu'il soit le plus utilisé et le plus avancé parmi ceux discutés), ça ne court pas les rues.
Le vrai point noir, ca reste la documentation, et le manque d'homogénéité des composants.
La documentation d'autotools est certes fouillie, mais relativement complète, il y a d'excellents tutoriaux (celui d'Alexandre Duret-Lutz, l'autobook, les tutoriaux d'openismus qui présente les bases et l'utilisation non-récursive). Quant au manque d'homogénéité, c'est defective by design, à moins de réécrire en grande partie autotools, ou de se restreindre à un sous-ensemble, on ne peut faire mieux.
Le vrai problème c'est qu'autotools est trop complexe pour le développeur "moyen" (ou que le développeur "moyen" soit incapable d'appréhender celui-ci par manque de temps ou par incapacité mentale), une meilleure documentation ne changera pas significativement cet état de fait (avec les ressources sus-mentionnées, on doit pouvoir arriver à un niveau de compétences plus que suffisant pour utiliser quotidiennement autotools sans être Fabrice Bellard)
le développeur s'en moque un petit peu. Il consulte la documentation de son SGBD, celui avec lequel il travaille quotidiennement et qui lui importe le plus pour son projet et il adapte les exemples de la documentation pour son besoin de l'instant
Mon coeur de métier n'étant pas le web, j'ai plutôt une expérience différente, j'ai du travailler avec du SQLite, MySQL, postgres, firebird (heureusement, j'ai toujours pu éviter les machins propriétaires). Les ORM peuvent constituer une solution mais pas toujours, heureusement qu'il existe des couches d'abstractions comme PDO en PHP, après pour les requêtes SQL, chacun sa méthode (partir d'une implémentation générique puis on optimise pour chaque base, implémentation base par base etc ...)
Le soucis, c'est que cela signifie un chantier énorme, pour une finalité pas si énorme que ça
Pour l'utilisateur qui a déjà une instance de Postgres, c'est un gain appréciable. Après, personne ne vous oblige à maintenir un backend postgres si vous n'en avez pas l'envie/le temps/les compétences etc ..., c'est du logiciel libre, libre à chacun d'apporter sa pierre. Dans l'écosystème libriste, le consommateur "passif" n'a pas voix au chapitre, soit il met la main à la pate (pas forcément dans le code, ça peut être de la traduction, documentation, promotion, packaging etc ... un échange de bons procédés), soit il met la main au porte-monnaie.
En découplant cette partie, ça vous permettra d'être un peu plus souple à l'avenir (par exemple, supporter un autre fork de MySQL comme Drizzle ou MariaDB), faciliter les contributions externes (tout est prêt pour supporter votre base préférée, y a plus qu'à coder les requêtes SQL qui vont bien et tester -pour caricaturer), découpler les requêtes SQL du code, ça peut même faire l'objet d'un Google SoC.
Boost jam (bjam): utilisé principalement par Boost qui est en train de passer à CMake, il est à la base de Boost.Build (en gros une collection de règles pour le premier)
et une bonne dizaine de forks plus ou moins confidentiels.
La famille Jam se rapproche plutôt de make et de scons, il orchestre directement la phase de compilation. À partir de maintenant, je limiterais mes propos à Boost.jam (je n'ai jamais utilisé les autres): il est extensible (boost-build utilise python), il a une syntaxe simple inspiré de make, il gére nativement les variantes de compilation (avec CMake, c'est une horreur, autotools un peu moins), il a un support décent de la plupart des chaines de compilations, par contre, très peu de règles pour gérer les outils tiers/bibliothèques tierces (de mémoire: qt, zlib, gettext, doxygen, fop, xsltproc dans la distro, pour le reste, il y a une forte probabilité que tu doives écrire à la main les règles.)
Sinon, c'est plutôt rapide.
en Postgresql ça retourne des lignes sans doublons, mais en MySQL on a des doublons. Donc on rajoute un DISTINCT, mais alors ça ne marche plus avec PostgreSQL : un peu galère.
Soit tu tiens absolument à maintenir un seul jeu de requêtes pour chaque base de données et tu te limites au sous-ensemble fonctionnel, soit tu découples les requêtes SQL du reste du code (un peu comme la génération du HTML avec smarties), et tu adaptes celles-ci au dialecte supporté par la base. C'est typiquement le cas d'utilisation de PDO, je fournis un API commune pour manipuler divers SGBDR, et j'adapte mes requêtes SQL en fonction (une implémentation naïve serait de stocker mes requêtes SQL dans un fichier par base de données ou un poil plus malin, de cacher celles-ci en mémoire). Si tu me dis, que même çà à un coût signicatif niveau performances, j'aurais beaucoup de mal à le croire.
Même si qmake est une option de premier choix dans le développement d'une application Qt, il a quelques inconvénients majeurs:
pratiquement inutilisable pour un projet non-Qt
très limité (pas de phase de configuration, pas de support de la compilation distribuée, support limité de la cross-compilation, pas de phase d'installation sauf à hardcoder les chemins)
peu ou pas extensible
très très mal documenté.
n'évolue plus, Nokia songe depuis quelques années à le faire passer à la trappe
Pour des projets de taille moyenne ou ayant des dépendances non-Qt, il est préférable de passer un système de construction plus avancés comme CMake ou autotools qui offrent tout deux un excellent support du framework.
gnu make fait formellement parti de la suite de construction GNU (d'ailleurs, j'aurais pu rajouter gnulib) [1], même si autotools est capable de générer un Makefile compatible avec bsd make par exemple.
Autotools sait faire, sauf que peu de développeurs savent s'en servir correctement. Le résultat c'est que la compilation out-of-source est dysfonctionnelle sur la plupart des projets gérer par autotools.
Lorsque je dirige des projets sous autotools, j'interdis formellement aux développeurs (sauf ceux qui ont démontrés leurs compétences à le faire) de modifier le système de construction sinon c'est le bordel assuré (scripts mal branlés, artefacts de compilations oubliés, mal testé, etc ...). Avec CMake, je peux me permettre un peu plus de souplesse à condition de fixer quelques guidelines et quelques explications (principalement, parce que la doc cmake -bouquin compris- est à chier, certes moins que celle d'autotools)
Avec autotools, faut introduire plusieurs langages (perl, shell, m4), expliquer les différences entre chaque version, l'habituer à un environnement de développement parfois non familier (pour les terreux sous windows -l'horreur-). Bref, on perds du temps, le résultat est à chier, au final, soit j'interdis aux bras cassés de toucher au système de construction, soit j'impose un système de construction plus "simple" selon le vécu de l'équipe (CMake, make, scons, etc ...)
Pour ma part, j'estime que l'article est destiné à un public de développeurs, l'utilisateur s'en branle royalement du système de construction (la plupart du temps, il récupérera un paquet binaire soit fourni par le mainteneur, soit par sa distro). De mon point de vue, la plupart des outils présentés se valent plus ou moins côté utilisateur.
Je remarquerais que parmis les utilitaires non-java, cmake est le seul à proposer nativement la génération de paquets binaires sous différents formats. Et j'en profite pour saluer le fabuleux travail d'Eric Noulard sur CPack, sans qui CPack aurait été déprécié et inutilisable depuis longtemps.
aucun ne marche sous windows sans devoir installer des outils tiers
CMake est relativement self-contained: compilateur C++, puis selon les fonctionnalités souhaités: zlib, libarchive, curl, curses, xmlrpc-c. Ensuite, ça te génére un projet qui utilises les outils "natifs" (nmake, jom, borland, mingw, cygwin sous windows)
Pour scons, waf, t'as juste besoin d'un interpréteur python classique, ce qui n'a rien d'extravagant pour des builders écrit en ce langage.
Autotools, ça a besoin: un shell posix (voire bash à cause des bashisms), perl, m4, pkg-config, et pas mal d'emmerdes parce que autotools a été fait pour les vrais systèmes d'exploitations et pas les jouets de micromou.
faire une appli véloce qui ne consomme pas 130% du CPU sur le serveur
Trolldi c'est passé, des applications web performantes en Python ça existe. De plus, l'interpréteur python est nettement plus performant que l'interpréteur php, pour le web. La grosse différence se situe dans la qualité des connecteurs aux serveurs, la maturité de mod_php jouant en faveur de php, mais si tu utilises autre chose que PHP ou que tu utilises le mode worker, tu es obligé de passer à fastcgi, et php revient à égalité avec python. Sans compter WSGI qui permet de booster les perfs pour servir une application python.
réussir à distribuer une application qui a des prérequis assez peu disponibles (PHP est largement plus disponible que Python sur les serveurs mutualisés)
Oui et non, en mutualisé "gratuit", en général, tu as du php5 (avec des limitations à la con comme chez free) et une base, en mutualisé "payant", c'est assez courant d'avoir une stack python complète (et largement suffisante pour GNU MediaGoblin).
Je pertinente, je rajouterais que cloudstack est un concurrent direct à openstack et opennova, deux autres frameworks permettant de construire un cloud privée ou hybride de type IaaS
il me semblait que le but était justement de s'émanciper des langages de requête et d'une part de gagner en performance (pas d’interprétation) et d'autre part de simplifier les requêtes et le code.
Historiquement, le terme NoSQL désignait les bases relationnelles qui effectivement cherchaient à s'émanciper du langage SQL. Le terme a été réintroduit pour désigner des bases non-relationnelles (orienté documents, graphes, clés/valeurs etc ...) et pour lesquelles, le langage SQL était inadapté. Ce que le mouvement NoSQL met en avant, c'est la fin des schémas fixes (et des join coûteux), la mise à l'échelle horizontale (la plupart gére nativement la réplication et fonctionnent en mode distribué).
T'as même des bases "NoSQL" comme Berkeley DB qui offre une interface SQL. UnQL cherche à fournir une interface commune aux bases NoSQL (voire SQL) pour faciliter les migrations, se libérer de l'enfermement propriétaire et en offrant une interface certes familière mais adapté aux besoins actuels.
Arora, Rekonq, Midori et Chromium utilisent tous WebKit donc les différences se feront au niveau de la GUI
Sauf que chacun utilise sa version de WebKit (QtWebKit, KHTML -rekonq?-, WebKit/Chromium, WebKitGtk) qui sont pas au même niveau, que chacun utilise un moteur de dessin/réseau/multimédia/ etc ... en plus de la surcouche de gras venant du toolkit (et Chromium utilise un modèle par processus propre, différent de celui qui sera proposé par webKit2 -utilisé par aucun navigateur libre à ma connaissance-)
C'est intéressant, après GNOME Shell qui est une extension javascript au gestionnaire de fenêtres, maintenant, le gestionnaire de fenêtres est écrit directement en javascript.
Même si l'auteur le décrit comme un bout de code "sale", y a potentiellement de quoi faire des applications un peu fun (comme avec GNOME Shell d'ailleurs).
mais quand tu as besoin d'une application en plus tu est bien ennuyé
SElinux est configuré sous Fedora (et RHEL aussi il me semble) en mode targeted, seuls les services critiques sont confinés (httpd, ftpd, mysqld, postgres, etc...), le reste des applications ne sont pas affectés (en fait, y a quelques règles relativement saines comme interdire l'exécution de la stack par exemple). Ce que tu décris, c'est la politique stricte qui n'est plus utilisé par défaut depuis un bon bout de temps.
Parce que pour faire marcher SAP ou Oracle avec SELinux, j'ai peur que ça soit le parcours du combattant
Rien que de faire fonctionner ces bouzins relèvent du parcours du combattant.
Rien que faire marcher Apache différemment de ce qui a été prévu demande de modifier des règles SELinux (genre, l'autoriser à lire un répertoire différent de /var/www/html).
ça demande juste de filer le bon contexte au répertoire (httpd_sys_content_t ou httpd_user_content_t), ça reste dans la continuité de la gestion des droits unix, si je veux qu'un process ait le droit de taper dans un répertoire, faut lui permettre de le faire.
Et si la réputation de complexité est bien surfaite, c'est pas non plus si simple que ça.
Si c'était simple d'administrer correctement une machine, les admins pointeraient au chômage. SELinux n'est pas simple, mais la configuration par défaut a été suffisamment simplifié pour être utilisable par le plus grand nombre sans trop de difficultés.
Si tu as besoin d'aller au-delà des possibilités de customisations prévues, soit tu as des besoins très pointues et ça justifie peut-être d'approfondir tes connaissances, soit c'est une mauvaise idée, soit c'est un bogue (pour les politiques bien définies comme httpd, c'est ultra rare maintenant).
C'est normal, Systemd est plutôt agressif dans les montées de versions des dépendances , du coup, c'est plus facile de monter en version sous une distro rolling release que sous une distro binaire. Pour avoir recompilé systemd 34, c'est chiant de se taper les dépendances :)
Sinon, systemd est un bijou, ma machine de développement démarre en 22s (au lieu de 80s), et j'ai encore de la marche (j'ai encore quelques services qui sont en SysV). L'écriture de services est relativement simple, l'administration est consistante, mon seul souci vient du fait que systemd fout le boxon avec cgroups et il y a des effets de bord notamment avec lxc.
Un logiciel en Qt n'obtiendra jamais une aussi bonne intégration à GNOME qu'un logiciel en GTK+, c'est un fait
+1
Même si Qt a fait un excellent boulot, reste encore quelques points à travailler dans le look'n'feel des widgets même si c'est parfois subtil.
Ceux qui n'en sont pas convaincu peuvent s'amuser à comparer les frontends Gtk+2 et Qt4 de transmission qui essaient de fournir une UI similaire, même si c'est plutôt réussi, on arrive quand même distinguer les deux à l'oeil nu.
[^] # Re: Unity ?
Posté par GeneralZod . En réponse au sondage A propos de gnome 3. Évalué à 1.
L'hôpital qui se fout de la charité ... Je dis que Unity ce n'est pas GNOME et n'a qu'une filiation extrêmement tenu avec le projet mais tu soutiens mordicus que Unity c'est GNOME envers et contre tout.
Tu vas arrêter de dire n'importe quoi ? Réutiliser quelques applications/services GNOME ou partager des bibliothèques communes ne font pas de Unity GNOME ou un bureau basé sur GNOME.
C'est bizarre que seul Canonical ait des "soucis" à contribuer avec le projet GNOME, si on exclut la cabale RH (qui veut la mort de Canonical et tient otage tout le projet), parmi les gens qui n'ont aucun problème avec GNOME reste: SuSE, Openismus, Lanedo, Igalia, Collabora, Intel, Litl, Fluendo, Nokia, codethink, mozilla etc ...
À propos du fameux GNOME census sur le 1% de Canonical dans GNOME, Jono Bacon expliquait que Canonical avait fait le choix de développer sa vision du bureau non pas contre GNOME mais parce qu'ils ont des objectifs et une approche différente. Encore une fois, il n'y a pas de "méchants" dans l'histoire, juste des choix différents et quelques incompréhensions ponctuelles.
Canonical n'a pas (encore?) forké KDE, donc forcément, ça apaise les relations (ironie inside). Sinon, cherche les réactions des gens de Nokia et de KDE aux initiatives de Canonical vis à vis de Qt (comme par exemple, intégrer le support de dconf dans Qt voire dans KDE - ce qui a fait hurlé Aaron Seigo qui hait dconf -).
# Template programming
Posté par GeneralZod . En réponse au message Faire une réduction de code en supprimant les fonctions non utilisées. Évalué à 2.
Les classes ou fonctions templates non utilisées ne sont pas compilés. Ça ne résout pas le problème, mais ça peut constituer une partie de la solution.
[^] # Re: Unity ?
Posté par GeneralZod . En réponse au sondage A propos de gnome 3. Évalué à 1.
Faut savoir ce que tu dis, Unity c'est GNOME ou pas GNOME ?
La version stable d'Unity repose toujours sur la plateforme GNOME2 (Unity-Gtk3 est encore en cours de développement). Unity c'est GNOME3 mais ça n'a pas besoin de la plateforme GNOME3, ok, c'est moi le menteur ...
Si on suit ton raisonnement précédent, KDE4 c'est GNOME3. Logique imparable !
C'est vrai que proposer une interface utilisateur complétement différente ne justifie pas le fait que Unity soit un bureau différent de GNOME.
NotifyOSD ==> daemon de notification fd.o GNOME
appindicators ==> symbolic icons
MeMenu ==> le machin en haut à droite du shell
Lightdm ==> gdm (à l'origine, Canonical devait bosser sur un nouveau greeter - le simple greeter était juste un hack en attendant ce dernier -, mais ils ont fini par réécrire un nouveau DM qui a le bon goût d'être moins fonctionnel que "new" GDM -ce qui en soit est déjà un exploit- précision: une fonctionnalité inexistante dans lightdm: l'accessibilité)
bamf ==> le mécanisme d'application matching dans la glib
Unity nécessite des versions patchées de Gtk+ (certains patchs ont été déjà refusés). La tendance actuelle, c'est que le temps s'écoulera, plus Unity et GNOME divergeront et ça ne s'arrange pas.
Pour arranger le tout, Unity et GNOME Shell ont tout deux choisi une politique d'intégration très poussée des applications dans le shell (Unity propose même une libunity).
GNOME Shell et Unity ne reposent pas du tout sur les mêmes technos: Mutter/Compiz, GJS/Vala, lenses Unity etc ... mais Unity c'est quand même GNOME. Parce qu'un bureau développé par des gens indépendamment du projet GNOME, dans une infrastructure externe à GNOME, avec une architecture différente (qui je le reconnais est beaucoup plus réfléchi que celle de GNOME Shell actuellement), avec des divergences irréconciliables, c'est GNOME que les gens de GNOME le veuillent ou non !
[^] # Re: Unity ?
Posté par GeneralZod . En réponse au sondage A propos de gnome 3. Évalué à 2.
Je suppose que tu parles pour Unity ? Je vais te décevoir, mais je m'intéresse de près à l'évolution du projet
Le projet parapluie qui héberge Unity: Ayatana est en train de redévelopper pas mal de briques existantes dans GNOME3:
https://wiki.ubuntu.com/Ayatana
https://launchpad.net/ayatana
Uniquement dans le discours marketing de Canonical, Unity a été conçu en dehors de GNOME, sans même aucune concertation avec le projet.
La réflexion autour de GNOME3 est presque aussi vieille que Canonical (aussi loin que je m'en rappelle Havoc Pennington en parlait déjà en 2005). Les fondations de GNOME Shell ont été jeté fin 2008 (le premier commit dans Unity date de fin 2009) et je te défie de démontrer qu'il y a eu un désaccord technique entre les ingénieurs de Canonical et le reste de la communauté GNOME.
Unity est un projet indépendant de GNOME, tu peux réécrire l'histoire autant de fois que tu voudras mais ça ne changera pas ce fait.
Non, le projet GNOME ne maintient qu'un seul Shell: GNOME-Shell.
XFCE partage également des fondations communes avec GNOME, tu peux utiliser aussi une partie des services fournis par GNOME mais ça n'est pas GNOME tout comme Unity n'est pas ou plus GNOME.
Le fait que Unity ne soit pas GNOME ou développé en dehors de GNOME n'a rien de péjoratif, c'est un projet tout aussi légitime que GNOME Shell (et tout aussi prometteur).
[^] # Re: Unity ?
Posté par GeneralZod . En réponse au sondage A propos de gnome 3. Évalué à 4.
Unity n'est GNOME3, ça n'utilise même pas la plateforme GNOME 3 à l'heure actuelle, et Canonical réécrit une bonne partie de la plateforme. Unity n'est pas GNOME, Unity n'est pas basé sur GNOME (sinon XFCE est aussi "basé" sur GNOME à ce compte-là), c'est un nouveau bureau avec ses avantages et ses inconvénients.
[^] # Re: Inconvénient des autotools
Posté par GeneralZod . En réponse à la dépêche Petit éventail des outils de construction (« builder ») libres. Évalué à 3.
La plupart du temps, c'est dû au fait que la tarball a été généré avec une version plus ancienne de la chaine autotools (soit parce que c'est qu'utilise le mainteneur upstream, soit parce que cette dernière a été mise à jour depuis la dernière release du projet).
Ça arrive fréquemment lors des cycles de développement, où la chaine autotools est très récente (ça permet de tester celle-ci, et de détecter quelques gruikeries également que l'on remonte en upstream). Même avec des projets très réactifs et avec un très bon niveau d'expertise avec autotools (ie: GNOME), il m'arrive parfois de devoir regénérer la chaine temporairement en attendant la prochaine release.
[^] # Re: Inconvénient des autotools
Posté par GeneralZod . En réponse à la dépêche Petit éventail des outils de construction (« builder ») libres. Évalué à 4.
Pour avoir rédigé cette partie, je ne suis pas d'accord sur ce que tu qualifies d'approximations.
Pouvoir regénérer correctement le système de construction avec autoreconf est malheureusement l'exception et non pas la règle. Et c'est l'empaqueteur qui te parle. Et même quand ça passe, ça ne garantit absolument pas l'absence d'effets de bords au point que certains en déconseillent l'utilisation ou bien de s'en servir comme base pour patcher directement le système de construction.
http://www.redhat.com/archives/rhl-devel-list/2008-October/msg00866.html
Pourquoi la majorité des distributions GNU/Linux fournissent encore autoconf 2.13 (sorti en 1999) ? Pourquoi Debian maintient 4 version d'automake, Fedora 5 ? (non, ce n'est pas par plaisir) Même si le nombre décroit petit à petit, tu as encore des paquets qui ont encore besoin de ces versions (autoreconf et autogen.sh ne peuvent pas grand chose la plupart du temps, patcher reviendrait à remettre à plat le système de construction). Ok, ça s'améliore, mais on est encore loin des autres outils en ce domaine.
Certes, c'est symptomatique d'une mauvaise utilisation d'autotools, mais un développeur qui maitrise autotools (malgré qu'il soit le plus utilisé et le plus avancé parmi ceux discutés), ça ne court pas les rues.
La documentation d'autotools est certes fouillie, mais relativement complète, il y a d'excellents tutoriaux (celui d'Alexandre Duret-Lutz, l'autobook, les tutoriaux d'openismus qui présente les bases et l'utilisation non-récursive). Quant au manque d'homogénéité, c'est defective by design, à moins de réécrire en grande partie autotools, ou de se restreindre à un sous-ensemble, on ne peut faire mieux.
Le vrai problème c'est qu'autotools est trop complexe pour le développeur "moyen" (ou que le développeur "moyen" soit incapable d'appréhender celui-ci par manque de temps ou par incapacité mentale), une meilleure documentation ne changera pas significativement cet état de fait (avec les ressources sus-mentionnées, on doit pouvoir arriver à un niveau de compétences plus que suffisant pour utiliser quotidiennement autotools sans être Fabrice Bellard)
[^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop
Posté par GeneralZod . En réponse à la dépêche Petites brèves : MediaGoblin, CloudStack, Walt Disney et G'MIC. Évalué à 1.
Mon coeur de métier n'étant pas le web, j'ai plutôt une expérience différente, j'ai du travailler avec du SQLite, MySQL, postgres, firebird (heureusement, j'ai toujours pu éviter les machins propriétaires). Les ORM peuvent constituer une solution mais pas toujours, heureusement qu'il existe des couches d'abstractions comme PDO en PHP, après pour les requêtes SQL, chacun sa méthode (partir d'une implémentation générique puis on optimise pour chaque base, implémentation base par base etc ...)
Pour l'utilisateur qui a déjà une instance de Postgres, c'est un gain appréciable. Après, personne ne vous oblige à maintenir un backend postgres si vous n'en avez pas l'envie/le temps/les compétences etc ..., c'est du logiciel libre, libre à chacun d'apporter sa pierre. Dans l'écosystème libriste, le consommateur "passif" n'a pas voix au chapitre, soit il met la main à la pate (pas forcément dans le code, ça peut être de la traduction, documentation, promotion, packaging etc ... un échange de bons procédés), soit il met la main au porte-monnaie.
En découplant cette partie, ça vous permettra d'être un peu plus souple à l'avenir (par exemple, supporter un autre fork de MySQL comme Drizzle ou MariaDB), faciliter les contributions externes (tout est prêt pour supporter votre base préférée, y a plus qu'à coder les requêtes SQL qui vont bien et tester -pour caricaturer), découpler les requêtes SQL du code, ça peut même faire l'objet d'un Google SoC.
[^] # Re: templates avec make
Posté par GeneralZod . En réponse à la dépêche Petit éventail des outils de construction (« builder ») libres. Évalué à 3.
C'est ça le standard: http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html (ce qui n'est pas listé dedans, est une extension vendeur)
Le manuel GNU explique quelles sont les innovations propre à GNU Make: http://www.gnu.org/software/make/manual/make.html#Features
Pas trop de documentation à ce sujet pour bsd make (enfin, la famille dérivée de pmake, les utilitaires make ont pas mal divergés selon les *BSD)
Le guide de référence: http://www.freebsd.org/doc/en/books/pmake/index.html (plus lire la page man fourni par ta distro *BSD)
Le shell Posix s'inspire principalement de ksh88 (avec quelques bizarreries comme echo/print, la syntaxe des fonctions etc ...)
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
[^] # Re: Et jam ???
Posté par GeneralZod . En réponse à la dépêche Petit éventail des outils de construction (« builder ») libres. Évalué à 3.
Jam, oui mais lequel ?
Perforce Jam: l'original
Boost jam (bjam): utilisé principalement par Boost qui est en train de passer à CMake, il est à la base de Boost.Build (en gros une collection de règles pour le premier)
et une bonne dizaine de forks plus ou moins confidentiels.
La famille Jam se rapproche plutôt de make et de scons, il orchestre directement la phase de compilation. À partir de maintenant, je limiterais mes propos à Boost.jam (je n'ai jamais utilisé les autres): il est extensible (boost-build utilise python), il a une syntaxe simple inspiré de make, il gére nativement les variantes de compilation (avec CMake, c'est une horreur, autotools un peu moins), il a un support décent de la plupart des chaines de compilations, par contre, très peu de règles pour gérer les outils tiers/bibliothèques tierces (de mémoire: qt, zlib, gettext, doxygen, fop, xsltproc dans la distro, pour le reste, il y a une forte probabilité que tu doives écrire à la main les règles.)
Sinon, c'est plutôt rapide.
[^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop
Posté par GeneralZod . En réponse à la dépêche Petites brèves : MediaGoblin, CloudStack, Walt Disney et G'MIC. Évalué à 4.
Postgres: select distinct on (field2) fieldA from tableA; -- ça n'est pas du SQL standard, mais ta requête MySQL ne l'est pas non plus
Tout à fait logique, MySQL ne respecte pas le standard SQL donc c'est la faute à Postgresql !
C'est pas moi qui le dit, mais la doc de MySQL: http://dev.mysql.com/doc/refman/5.1/en/group-by-hidden-columns.html
Soit tu tiens absolument à maintenir un seul jeu de requêtes pour chaque base de données et tu te limites au sous-ensemble fonctionnel, soit tu découples les requêtes SQL du reste du code (un peu comme la génération du HTML avec smarties), et tu adaptes celles-ci au dialecte supporté par la base. C'est typiquement le cas d'utilisation de PDO, je fournis un API commune pour manipuler divers SGBDR, et j'adapte mes requêtes SQL en fonction (une implémentation naïve serait de stocker mes requêtes SQL dans un fichier par base de données ou un poil plus malin, de cacher celles-ci en mémoire). Si tu me dis, que même çà à un coût signicatif niveau performances, j'aurais beaucoup de mal à le croire.
[^] # Re: Le grand absent: qmake
Posté par GeneralZod . En réponse à la dépêche Petit éventail des outils de construction (« builder ») libres. Évalué à 2.
Même si qmake est une option de premier choix dans le développement d'une application Qt, il a quelques inconvénients majeurs:
pratiquement inutilisable pour un projet non-Qt
très limité (pas de phase de configuration, pas de support de la compilation distribuée, support limité de la cross-compilation, pas de phase d'installation sauf à hardcoder les chemins)
peu ou pas extensible
très très mal documenté.
n'évolue plus, Nokia songe depuis quelques années à le faire passer à la trappe
http://labs.qt.nokia.com/2009/10/12/to-make-or-not-to-make-qmake-and-beyond/
http://labs.qt.nokia.com/2009/10/14/to-make-or-not-to-make-qmake-and-beyond-redux/
Par ailleurs, QtCreator a un excellent support de CMake et Openismus finance le développement d'un greffon autotools (et a de bonnes chances d'intégrer prochainement la branche principale).
http://psconboard.blogspot.com/2011/09/autotools-project-manager-part-3-merge.html
http://gitorious.org/qtcreator-autotools-plugin
Pour des projets de taille moyenne ou ayant des dépendances non-Qt, il est préférable de passer un système de construction plus avancés comme CMake ou autotools qui offrent tout deux un excellent support du framework.
[^] # Re: Les autotools n’impliquent pas GNU make
Posté par GeneralZod . En réponse à la dépêche Petit éventail des outils de construction (« builder ») libres. Évalué à 1.
gnu make fait formellement parti de la suite de construction GNU (d'ailleurs, j'aurais pu rajouter gnulib) [1], même si autotools est capable de générer un Makefile compatible avec bsd make par exemple.
[1] dans certains cas très précis, il est conseillé de recommander l'utilisation de GNU Make
http://www.gnu.org/software/automake/manual/automake.html#Simple-Tests-using-parallel_002dtests
[^] # Re: Avantages CMake
Posté par GeneralZod . En réponse à la dépêche Petit éventail des outils de construction (« builder ») libres. Évalué à 4.
Autotools sait faire, sauf que peu de développeurs savent s'en servir correctement. Le résultat c'est que la compilation out-of-source est dysfonctionnelle sur la plupart des projets gérer par autotools.
Lorsque je dirige des projets sous autotools, j'interdis formellement aux développeurs (sauf ceux qui ont démontrés leurs compétences à le faire) de modifier le système de construction sinon c'est le bordel assuré (scripts mal branlés, artefacts de compilations oubliés, mal testé, etc ...). Avec CMake, je peux me permettre un peu plus de souplesse à condition de fixer quelques guidelines et quelques explications (principalement, parce que la doc cmake -bouquin compris- est à chier, certes moins que celle d'autotools)
Avec autotools, faut introduire plusieurs langages (perl, shell, m4), expliquer les différences entre chaque version, l'habituer à un environnement de développement parfois non familier (pour les terreux sous windows -l'horreur-). Bref, on perds du temps, le résultat est à chier, au final, soit j'interdis aux bras cassés de toucher au système de construction, soit j'impose un système de construction plus "simple" selon le vécu de l'équipe (CMake, make, scons, etc ...)
[^] # Re: Inconvénient des autotools
Posté par GeneralZod . En réponse à la dépêche Petit éventail des outils de construction (« builder ») libres. Évalué à 4.
Pour ma part, j'estime que l'article est destiné à un public de développeurs, l'utilisateur s'en branle royalement du système de construction (la plupart du temps, il récupérera un paquet binaire soit fourni par le mainteneur, soit par sa distro). De mon point de vue, la plupart des outils présentés se valent plus ou moins côté utilisateur.
Je remarquerais que parmis les utilitaires non-java, cmake est le seul à proposer nativement la génération de paquets binaires sous différents formats. Et j'en profite pour saluer le fabuleux travail d'Eric Noulard sur CPack, sans qui CPack aurait été déprécié et inutilisable depuis longtemps.
[^] # Re: robuste ?
Posté par GeneralZod . En réponse à la dépêche Petit éventail des outils de construction (« builder ») libres. Évalué à 4.
CMake est relativement self-contained: compilateur C++, puis selon les fonctionnalités souhaités: zlib, libarchive, curl, curses, xmlrpc-c. Ensuite, ça te génére un projet qui utilises les outils "natifs" (nmake, jom, borland, mingw, cygwin sous windows)
Pour scons, waf, t'as juste besoin d'un interpréteur python classique, ce qui n'a rien d'extravagant pour des builders écrit en ce langage.
Autotools, ça a besoin: un shell posix (voire bash à cause des bashisms), perl, m4, pkg-config, et pas mal d'emmerdes parce que autotools a été fait pour les vrais systèmes d'exploitations et pas les jouets de micromou.
[^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop
Posté par GeneralZod . En réponse à la dépêche Petites brèves : MediaGoblin, CloudStack, Walt Disney et G'MIC. Évalué à 6.
Trolldi c'est passé, des applications web performantes en Python ça existe. De plus, l'interpréteur python est nettement plus performant que l'interpréteur php, pour le web. La grosse différence se situe dans la qualité des connecteurs aux serveurs, la maturité de mod_php jouant en faveur de php, mais si tu utilises autre chose que PHP ou que tu utilises le mode worker, tu es obligé de passer à fastcgi, et php revient à égalité avec python. Sans compter WSGI qui permet de booster les perfs pour servir une application python.
Oui et non, en mutualisé "gratuit", en général, tu as du php5 (avec des limitations à la con comme chez free) et une base, en mutualisé "payant", c'est assez courant d'avoir une stack python complète (et largement suffisante pour GNU MediaGoblin).
[^] # Re: Cloudstack != libvirt
Posté par GeneralZod . En réponse à la dépêche Petites brèves : MediaGoblin, CloudStack, Walt Disney et G'MIC. Évalué à 4.
Je pertinente, je rajouterais que cloudstack est un concurrent direct à openstack et opennova, deux autres frameworks permettant de construire un cloud privée ou hybride de type IaaS
[^] # Re: Surprenant
Posté par GeneralZod . En réponse à la dépêche UnQL : all your bases are belong to us. Évalué à 2.
Historiquement, le terme NoSQL désignait les bases relationnelles qui effectivement cherchaient à s'émanciper du langage SQL. Le terme a été réintroduit pour désigner des bases non-relationnelles (orienté documents, graphes, clés/valeurs etc ...) et pour lesquelles, le langage SQL était inadapté. Ce que le mouvement NoSQL met en avant, c'est la fin des schémas fixes (et des join coûteux), la mise à l'échelle horizontale (la plupart gére nativement la réplication et fonctionnent en mode distribué).
T'as même des bases "NoSQL" comme Berkeley DB qui offre une interface SQL. UnQL cherche à fournir une interface commune aux bases NoSQL (voire SQL) pour faciliter les migrations, se libérer de l'enfermement propriétaire et en offrant une interface certes familière mais adapté aux besoins actuels.
[^] # Re: linuxFR: interdit aux -18 ans?
Posté par GeneralZod . En réponse à la dépêche UnQL : all your bases are belong to us. Évalué à 4.
Je ne moinsserais pas, mais je déplore amérement le manque de culture des dernières générations de la gente moulesque.
[^] # Re: Remarque format image
Posté par GeneralZod . En réponse au journal Consommation mémoire navigateurs web. Évalué à 2.
Sauf que chacun utilise sa version de WebKit (QtWebKit, KHTML -rekonq?-, WebKit/Chromium, WebKitGtk) qui sont pas au même niveau, que chacun utilise un moteur de dessin/réseau/multimédia/ etc ... en plus de la surcouche de gras venant du toolkit (et Chromium utilise un modèle par processus propre, différent de celui qui sera proposé par webKit2 -utilisé par aucun navigateur libre à ma connaissance-)
# nwm
Posté par GeneralZod . En réponse à la dépêche Petites brèves : ebooks, nwm et Cloud Foundry. Évalué à 2.
C'est intéressant, après GNOME Shell qui est une extension javascript au gestionnaire de fenêtres, maintenant, le gestionnaire de fenêtres est écrit directement en javascript.
Même si l'auteur le décrit comme un bout de code "sale", y a potentiellement de quoi faire des applications un peu fun (comme avec GNOME Shell d'ailleurs).
[^] # Re: Pas choqué.
Posté par GeneralZod . En réponse au journal Debian: meilleure distribution de l'année 2011. Évalué à 2.
SElinux est configuré sous Fedora (et RHEL aussi il me semble) en mode targeted, seuls les services critiques sont confinés (httpd, ftpd, mysqld, postgres, etc...), le reste des applications ne sont pas affectés (en fait, y a quelques règles relativement saines comme interdire l'exécution de la stack par exemple). Ce que tu décris, c'est la politique stricte qui n'est plus utilisé par défaut depuis un bon bout de temps.
Rien que de faire fonctionner ces bouzins relèvent du parcours du combattant.
ça demande juste de filer le bon contexte au répertoire (httpd_sys_content_t ou httpd_user_content_t), ça reste dans la continuité de la gestion des droits unix, si je veux qu'un process ait le droit de taper dans un répertoire, faut lui permettre de le faire.
Si c'était simple d'administrer correctement une machine, les admins pointeraient au chômage. SELinux n'est pas simple, mais la configuration par défaut a été suffisamment simplifié pour être utilisable par le plus grand nombre sans trop de difficultés.
Si tu as besoin d'aller au-delà des possibilités de customisations prévues, soit tu as des besoins très pointues et ça justifie peut-être d'approfondir tes connaissances, soit c'est une mauvaise idée, soit c'est un bogue (pour les politiques bien définies comme httpd, c'est ultra rare maintenant).
[^] # Re: Systemd ?
Posté par GeneralZod . En réponse à la dépêche Fedora devient une grande fille. Évalué à 3.
C'est normal, Systemd est plutôt agressif dans les montées de versions des dépendances , du coup, c'est plus facile de monter en version sous une distro rolling release que sous une distro binaire. Pour avoir recompilé systemd 34, c'est chiant de se taper les dépendances :)
Sinon, systemd est un bijou, ma machine de développement démarre en 22s (au lieu de 80s), et j'ai encore de la marche (j'ai encore quelques services qui sont en SysV). L'écriture de services est relativement simple, l'administration est consistante, mon seul souci vient du fait que systemd fout le boxon avec cgroups et il y a des effets de bord notamment avec lxc.
[^] # Re: Précisions
Posté par GeneralZod . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. Évalué à 5.
+1
Même si Qt a fait un excellent boulot, reste encore quelques points à travailler dans le look'n'feel des widgets même si c'est parfois subtil.
Ceux qui n'en sont pas convaincu peuvent s'amuser à comparer les frontends Gtk+2 et Qt4 de transmission qui essaient de fournir une UI similaire, même si c'est plutôt réussi, on arrive quand même distinguer les deux à l'oeil nu.