liberforce a écrit 4730 commentaires

Avec CMake tu va écrire un CMakeLists.txt qui va te permettre de générer des fichiers pour différents systèmes de build, dont autotool si je ne me trompe pas.

Effectivement, comme dit au dessus, tu te trompes, CMake produit bien des Makefile, pas des fichiers consommés par les autotools. Du coup, je ne comprenais pas tes critiques.

Pardonne ma naïveté, mais a priori sa sortie, c'est un makefile, comme les autotools. Tu aurais un lien à me filer qui parlerait des défauts que tu trouves à CMake ? J'ai toujours vu SCons, CMake et les autotools comparés comme étant le même type de solutions.

C'est à dire ? KDE est passé à CMake il y a un bon moment, donc CMake n'est pas non plus un jouet…

Je dois être un peu con sur les bords, mais j'ai toujours pas compris. Ces projets te semblent positifs ou négatifs ? Issus de la Cathédrale ou du bazar ? Parce que sans être dans ta tête, j'ai du mal à voir ce que tu veux transmettre comme information derrière ta remarque…

Une petite question: c'est compatible avec tous les shells ?

Le fait que autotools soit une usine à gaz avec des horreurs comme libtool tient à son architecture et à ses choix de design… qu'est-ce que son modèle de développement vient faire là dedans ?

Le point de vue est pourtant expliqué dans le journal… Il pense que c'est le fait de s'adapter à de multiples cas différents par manque de normalisation qui a obligé libtool à devenir une usine à gaz pour gérer toutes les exceptions à la règle.

Tu pourrais en profiter pour éclaircir ta remarque ?

Avec les récents développements de Gnome3, Unity, systemd, etc. À se demander si le modèle du bazar amène autre chose que du bazar…

Je sais que c'est vendredi, mais j'ai pas trop compris ce que tu voulais dire.

Autant la question du 1 et 2 du numéro de sécu. m'indiffère

Vas dire ça aux personnes qui doivent changer de sexe…

Totem est passé à Clutter si je me souviens bien, et nécessite donc l'accélération 3D… qui est désactivée dans le mode fallback. D'ailleurs, le mode fallback risque de disparaître prochainement.

Je dirais même plus: http://linuxfr.org/tags/top500/public

Un point que je trouve important, c'est aussi que c'est un autre moyen de faire connaître et promouvoir le libre, à ceux qui évoluent plutôt dans un univers propriétaire. C'est pour ça que la même chose pour Linux a à mon avis moins d'intérêt… Bref, continuez ;-)

Ah, non, pas convainquant, mais convaincant !

C'est idiot, c'est le workflow vers lequel tend gnome-shell, c'est donc un bug si ça ne fonctionne pas. Et les patchs pour corriger des bugs, ils l'intègreront. Si c'est pour une fonctionnalité sortie du chapeau, c'est sûr, c'est plus compliqué vu qu'il faut convaincre les développeurs.

Pas plus tard qu'hier, j'ai encore tenté un énième fois Gnome shell.
C'est inconcevable de l'utiliser en desktop.

Bref, la seule alternative crédible reste KDE qui peut être configuré exactement aux desiderata de l'utilisateur.

Ça c'est du commentaire objectif…

Vouloir utiliser sa machine simplement sans être informaticien n'est pas un délit que je sache… J'imagine qu'il y a 10 ans des gars ont dû dire "quoi, les gens veulent utiliser Linux sans recompiler leur kernel ? Au bûcher !"

Tu as donc dans ce cas l'inconvénient de la taille de la compression du FLAC, avec l'inconvénient de la compression destructive de ta copie originale, le tout pour un morceau que tu as acheté. Un vrai bonheur…

2007: Virgin Digital ferme sa plateforme de vente de musique en ligne, empêchant ses clients de lire de la musique légalement achetée. La méthode de contournement indiquée (graver les morceaux sur un CD, puis les re-numériser) réduit la qualité d'origine des morceaux. Et DADVSI interdit de fournir un outil de cassage des DRM même dans ce cas.

Bordel, j'ai tellement retouché ma phrase qu'elle est illisible maintenant !

Merci de me faire parvenir votre cv sous format Word

La plupart des gens qui on lu jusque là qui n'iront pas plus loin…

Pour le moment, c'est la gestion de l’énergie dans gnome.

Ce qui gêne les gens c'est le "pour le moment". On ne va pas se voiler la face: si le mainteneur d'un module central décide de passer à systemd et d'abandonner les anciennes méthodes, c'est la porte ouverte à une utilisation massive. Ce n'est techniquement pas un mal, mais cela envoie un signal négatif à ceux qui veulent GNOME sur autre chose que du Linux, ou aux Linux qui n'ont pas le temps ou l'envie de passer à systemd. Rajouter une charge de boulot à d'autres personnes, ce n'est jamais fun pour elles.

En fait le probleme c'est qu'on a d'un cote des gens qui critiquent l'aspect politique (et une petit partie qui pointent les faiblesses techniques mais non redhibitoires, mais c'est perdu dans le flot de critiques) et de l'autre des supporters qui repondent uniquement sur l'aspect technique. Forcement, ca ne mene a rien.

Il suffit de poser la question.

Pour le côté technique :
Est-ce que je pense que SystemD fait bien son job ? Oui. Est-ce que je pense que c'est surtout les habitudes et la peur du changemement qui font que certaines personnes ne veulent pas l'adopter ? Oui.

Pour le côté politique:
Est-ce que l'influence croissante de Red Hat sur le projet GNOME me gêne ? Oui. Forcément quand un certain nombre de systèmes sont maintenus par des gens embauchés par Red Hat, ça rend plus sensible aux décisions desdits mainteneurs. Encore que je ne pense pas que leur choix soit déterminé par leurs employeurs sur ce point.

Tu peux m'expliquer en quoi la Free Software Foundation ou l'Open Source Initiative peuvent édicter des règles indiquant en quoi une œuvre artistique est libre ou pas ? C'est comme si tu me disais, « le seul vrai Dieu, c'est le mien » !

Donc il me semble qu'il faut arrêter tout le modèle de développement moderne. Parce qu'une branche d'un logiciel dans git, c'est aussi un fork. En gros il demande aux gens de maintenir une branche spécifique à chaque OS pour que le code soit plus simple. Ça te convient mieux ?

J'ai lu l'article sur SystemD dans Linux Magazine n°153, et franchement, il n'y a pas de quoi fouetter un chat ! De plus, il semble que certaines syntaxes ont été conservées (genre: appel à chkconfig, à service), histoire de conserver une certaine rétro-compatibilité. Pas de quoi s'arracher les cheveux !

2/ Parce que la volonté affichée du développeur de Systemd est de faire du Linux Only

Combien de fois il va falloir le dire. Il ne veut juste pas avoir à maintenir les autres OS, au risque de rendre le code incompréhensible. Il ne veut pas de #ifdef pour ne pas le rendre illisible. La manière de gérer systemd pour un autre kernel est donc de forker, et se synchroniser pour récupérer ce qui est indépendant de l'OS. Cela permet à chaque implémentation d'être spécifique, sans rendre le code abscons. De plus, s'il y a des choses à abstraire un minimum pour que la gestion de différents kernels se fasse plus simplement au niveau code, cela m'étonnerait que Lennart refuse les patchs.

Lennart a fait du code multi-plateforme pour Avahi, et en a tellement souffert qu'il ne veut plus revivre la même chose. Ça peut se comprendre, non ?