liberforce a écrit 4744 commentaires

Hum, ça ressemble beaucoup à qisrc…

Dans une boîte, j'ai eu droit à la grille selon l'école alors que j'avais 13 ans d'expérience à ce moment là…

Tu te dévoues pour « Flash, le coup de grâce » ?

C'était pour dire que les deux approches se valent, parce qu'il y a des besoins pour les deux ;).

Perso, je suis sous Gnome et c'est juste utilisable, sans les lenteurs (lourdeurs) que je constate avec Ubuntu.

Testé sur un Athlon XP 3000+ avec 1,5Go de RAM. C'est utilisable mais de temps en temps gnome-shell bouffe énormément de CPU, puis se calme. J'ai aussi eu quelques soucis avec le fait que mon processeur ne gère pas SSE2 et que certains paquets sont compilés avec SSE2 activé (libflac)… J'ai trouvé personne pour me dire ce qu'était vraiment la configuration minimale supportée pour Mageia 6 :-/

Mais bon, une fois que j'ai rebuildé la libflac sans SSE2, j'ai enfin pu ripper ma CD-thèque en FLAC et depuis ça roule ;)

J'aimerais que le monde linux aille dans le sens de la seconde solution plutôt que de voir les devs KDE et GNOME se croire chacun de leur côté les seuls qui comptent vraiment.

Il y a un besoin aussi pourtant. Tu veux de l'homogénéité par environnement de bureau sur une même distrib. Ok, mais moi je veux de l'homogénéité par environnement de bureau sur des distribs différentes. Au boulot je suis sur Ubuntu, à la maison sous Mageia, et j'utilise GNOME sur les deux. Du coup utiliser les outils GNOME est plus pratique pour moi (et c'est souvent mieux intégré visuellement, parce que GNOME fait des trucs beaux).

Ce test n'a donc aucun intérêt. J'attends de voir des comparaisons sur de vrais projets qui mettent 30 minutes au moins à compiler.

Genre GStreamer ?

Intrigued, he tried it out and found that it finished suspiciously quickly. His first instinct was that it was broken and hadn’t actually built everything! Turns out this build system written in Python 3 with Ninja as the backend actually was that fast. About 2.5x faster on Linux and 10x faster on Windows for building the core GStreamer repository.

La comparaison est faite par rapport à l'ancien build en autotools.

Source:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.html

J'aimerais bien savoir en quoi il sur-vend son projet…
Les retours de plein de projets (tracker, gstreamer, gnome) sont très positifs sur le produit comme sur l'écoute des devs, et Mesa et X envisagent aussi une migration…

Bah jette un coup d'oeil à Meson.

http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.html
https://samthursfield.wordpress.com/2017/05/22/tracker-%F0%9F%92%99-meson/
http://mesonbuild.com/Simple-comparison.html

Pour la news des 20 ans, c'est le moment de faire un peu d'archéologie:

Voici les débuts de GNOME vus par Miguel De Icaza (co-fondateur de GNOME)
https://web.archive.org/web/20131106035732/http://primates.ximian.com/~miguel/gnome-history.html

et des slides en vrac de Federico Mena Quintero (co-fondateur de GNOME, toujours impliqué dans le projet), datant de sa présentation au GUADEC 2012 à Á Coruña en Espagne (fouillez bien, il y a une présentation .odp dans le lot):
https://github.com/federicomenaquintero/guadec-2012-keynote

Et dans sa bio et d'autres ressources (malheureusement uniquement en espagnol):
https://people.gnome.org/~federico/bio-es.html
http://www.calcifer.org/documentos/librognome/introduccion-libro.html

Le lien pour la traduction automatique Google de sa bio:
https://translate.google.com/translate?hl=en&sl=es&tl=fr&u=https%3A%2F%2Fpeople.gnome.org%2F~federico%2Fbio-es.html

Idem pour moi, GNOME 3 sans extensions au boulot (dev/intégration) et à la maison.
GNOMiste convaincu depuis GNOME 2.6 :)

Le lien du bug Fedora dans la phrase "Ubuntu GNOME et Fedora" est cassé, le bon lien est https://bugzilla.redhat.com/show_bug.cgi?id=1415287

J'ai entendu aussi le contraire ce week-end un gars d'origine asiatique dont le nom (ou prénom, j'ai oublié) était "I". Du coup, certains systèmes informatiques demandent minimum 2 lettres, et il se fait refuser.

On lit du code plus qu'on ne l'écrit. Détourner l'API ne me semble pas une très bonne idée, surtout si un jour toi ou ton successeur devez faire une mise à jour vers une autre bibliothèque: tu rends plus difficile de faire un grep pour retrouver les symboles en question.

Je te conseille donc soit de faire un wrapper, avec des fonctions qui appelleront ces fonctions là, ou bien utilise de manière plus efficace le complètement automatique de ton éditeur de texte.

être consistant au sein d'un projet

Cohérent, uniforme, homogène… Pas "consistant".

En plus de CMake, je pense qu'évoquer Meson ne ferait pas de mal. Il utilise par défaut un backend Ninja, optionnel sous CMake. Ça gère pkg-config, ça fait les bons choix par défaut (-Wall par exemple), et grâce à Ninja, c'est rapide et ça ne reconstruit que le nécessaire.

Meson

project('glib-test', 'c')

deps = dependency ('glib-2.0')
sources = ['glib-test.c']
executable('glib-test', sources, dependencies: deps)

CMake

project (glib-test)
cmake_minimum_required (VERSION 2.4)

find_package (PkgConfig REQUIRED)
pkg_check_modules (GLIB2 REQUIRED glib-2.0)

include_directories (${GLIB2_INCLUDE_DIRS})
link_directories (${GLIB2_LIBRARY_DIRS})
add_executable (glib-test glib-test.c)
target_link_libraries (glib-test ${GLIB2_LIBRARIES})

Je suis originellement un programmeur C, et si à une époque, j'ai pu louer les mérites d'une lib comme GTK (car elle permet par exemple de façon assez élégante de faire un peu polymorphisme), je pense que j'aurais maintenant pas mal de difficultés à "rentrer" dans une IHM écrite en C depuis que je connais autre chose.

Bin on peut faire du GTK+ dans plein de langages. C'est pas parce que la bibliothèque est en C que le code applicatif doit l'être: on fait du GTK en C++ (gtkmm), python (pygobject), Rust, etc.

Ensuite, sur la question de la réécriture à partir de rien d'un projet en C évoqué par Jehan: le langage Rust permet de faire de la réécriture par morceau. C'est ce que fait Federico Mena Quintero (co-fondateur de GNOME, mainteneur de librsvg) avec la librsvg qu'il migre petit bout par petit bout du C vers le Rust depuis octobre dernier. C'est un langage particulièrement adapté au parsing de fichiers, parce qu'il t'assure à la compilation une bonne gestion de la mémoire (pas de double free, pas de fuite mémoire), favorise le parallélisme… Alors oui, c'est un peu la "mode" mais si Firefox et librsvg s'y mettent, il y a peut être de (bonnes) raisons, et pas juste de l'effet de mode…

Et Meson ? Emanuelle Bassi, un des mainteneurs de GTK+ a commencé à sérieusement se pencher dessus en portant graphene à Meson. GStreamer builde 10× plus vite sous Windows et 2,5× plus vite sous Linux depuis sa migration de autotools à Meson. Avec son backend Ninja (utilisable aussi dans CMake) pour remplacer make la gestion des dépendance a l'air plus simple, et il n'a pas les trucs sales et confus de CMake pour la gestion des listes et des séparateurs. Sa logique est d'utiliser les options pertinentes par défaut aussi (gcc -Wall par exemple est actif de base). Mais il est vrai que meson utilise aussi un fichier externe pour la cross-compilation.

Bref, tout ça pour dire que les autotools ne sont plus une fatalité. Meson n'est pas forcément encore 100% mature, mais s'il l'est assez pour un projet comme GStreamer, c'est tout de même quelque chose à regarder pour le jour où vous en aurez mare de CMake et des autotools. En attendant, tu peux utiliser CMake avec le backend Ninja.

Après presque 15 ans sur ce site je découvre seulement maintenant l'origine de ton pseudo ! D'oh !

J'ai pas mal de rapports de bugs (et même plusieurs patchs) qui attendent dans le bugtracker. Peut-être mes patchs vont-ils enfin avoir une revue de code et une intégration? :-)

Demande à Federico au prochain GUADEC ;)

Bonjour,

Il semble que tu veuilles remplacer un Windows 32 bits par un Windows 64 bits. Du coup je ne vois pas trop le rapport ni avec Linux, ni avec le Libre. Sur un autre forum spécialisé dans Windows, tu sera auras sans doute plus de chances de trouver quelqu'un qui pourra répondre à ta question.

(le tout 4G permettrait sans doute un gros gain énergétique, de coûts et de performances car purement numérique).

Oui mais non: Postulat de Khazzoom-Brookes

Snif, j'étais en vacances à ce moment là, depuis j'ai une message "la page n'existe plus". Serait-il possible d'avoir un nouveau lien ? Merci !

Tu dis avoir regardé git et svn, ceux là ne sont pas adaptés au stockage de fichiers binaires. Tu as regardé du côté de git-annex ?

Je ne sais pas si c'est déjà implémenté, mais moi ce que j'attends c'est un filtre pour vectorizer des bitmaps de jeux vidéos pour pouvoir rejouer à des jeux d'anthologie sans gros pixels baveux :)

Le papier de recherche en question:
http://johanneskopf.de/publications/pixelart/paper/pixel.pdf