rewind a écrit 3416 commentaires

À côté de ça, je savoure l'idée d'allumer la lumière une heure plus tard dès ce soir.

Une heure plus tôt tu veux dire… Oui, en hiver, tu vas allumer ta lumière une heure plus tôt (la nuit se couche plus tôt). Et en été, tu ne vas pas allumer ta lumière parce qu'il fera encore jour de toute façon.

Il est perturbé par le changement d'heure…

Pareil. Me lever alors qu'il fait encore nuit, ça ne me dérange pas, je vois le soleil se lever petit à petit, c'est plutôt agréable. En revanche, rentrer chez moi après le boulot alors qu'il fait déjà nuit, ça me déprime, surtout quand il faut ressortir pour faire des courses ou ce genre de choses. J'aimerais mieux aller me coucher à ce moment là.

Il y a des admins qui ont des problèmes très concrets qu'ils ont exposés ici et dans d'autres article précédemment et qui n'ont jamais eu de réponse. Et j'ai vraiment la flemme de me replonger dans cet océan de trolls pour les retrouver.

Personnellement (j'insiste sur ce mot, c'est mon avis et je le partage, je ne sais pas si c'est exact), je pense que la cause principale est RedHat. Redhat a une telle emprise sur une quantité non-négligeable de projets libres, dont GNOME, qu'elle peut «imposer» les technos qu'elle veut. Je met imposer entre guillemets parce que c'est plutôt proposer mais comme en face, il n'y a personne avec la même puissance (notamment le même nombre de développeurs), il n'y a pas d'autres propositions.

Si on prend l'exemple de NM, au départ, ça part d'une bonne idée et d'un besoin réel du desktop. Puis ça grandit, ça s'intègre à GNOME, et du coup, les distribs sont obligés de suivre, ainsi que les autres DE. Y a-t-il des alternatives ? Oui, il y a wicd, et il me semble qu'à une époque, on pouvait utiliser wicd sur KDE à la place de NM, mais maintenant, je crois qu'on ne peut plus, tout le monde s'aligne parce qu'un des DE (par défaut sur de nombreuses distribs) a fait un choix unique et donc, pour simplifier la maintenance des autres, on abandonne les alternatives.

Et pour systemd, ça a l'air de se diriger vers la même chose : RH participe à GNOME, utilise des fonctionnalités propres à systemd (oui, c'est qu'une interface DBus qui peut être implémentée par d'autres, n'empêche que systemd est pour l'instant la seule implémentation), et du coup, les distribs se retrouvent obligées de suivre.

On pourrait aussi reparler de FreeDesktop qui n'est qu'une grosse blague sachant que toutes les technos venant de KDE sont rejetés (ou pas implémentées par GNOME) et toutes les technos venant de GNOME sont imposés (et implémentées dans KDE, même s'il y avait un existant mieux).

Bref, personne n'est menacé à coup de fusil, c'est beaucoup plus subtil que ça. À mon sens, c'est juste de la stratégie industrielle (toujours être le premier sur les technos pour avoir une longueur d'avance sur les concurrents), rien de plus.

Donc oui, ceux qui utilisent sans contribuer, ils sont dépendant des autres. Mais c'est uniquement leur faute, car la seule chose qui les retient, c'est eux mêmes.

C'est vrai ça, pourquoi tout le monde ne contribue pas ? Vraiment les gens, je me demande bien ce qu'ils peuvent faire d'autre dans leur vie ? C'est un scandale !

Déjà, c'est pas bien de caricaturer ceux qui ne veulent pas de systemd et toutes ses extensions comme de vilains réactionnaires qui veulent vivre dans le passé. C'est une généralisation abusive. Rien ne dit qu'ils ne sont pas passés à Gnome Shell (pour reprendre un autre troll poilu).

Ensuite, je pense que le point important, c'est pas le changement ou pas, c'est surtout que Lennart nous a habitué à nous fournir des trucs pas finis qui gère certains cas particuliers mais pas des cas généraux (PulseAudio toussa). Et que son entreprise est une spécialiste des «révolutions» de technologies qui finalement finissent à la poubelle quelques années après (*Kit toussa), ou qui restent bugguées ou incomplètes pendant des années (NetworkManager toussa).

Il y a sans doute un juste milieu entre vouloir «révolutionner», surtout quand la révolution a lieu tous les 3-4 ans et vouloir une évolution soutenable (notamment par des admins qui gèrent des systèmes critiques dans certaines entreprises).

En admettant que l'ascii ne soit pas du binaire (même si mon disque dure me dit qu'il ne sait stocker que du binaire … mais admettons ce n'est qu'un disque dur)

Je vais juste répondre sur ce point, je laisse le reste aux trolls genre Zenitram que je trouve très très en forme sur cet article :D

Historiquement, il existait une différence entre texte et binaire. On en trouve des traces dans deux endroits (au moins) :

• dans le protocole FTP où il y a un mode binaire (le fichier est transmis tel quel) et un mode ASCII (où les fins de ligne sont transformés en s'adaptant au système).
• dans les arguments à fopen où il existe un flag "b" pour désigner un fichier binaire. Il n'est plus utilisé sous Unix mais il me semble qu'il a encore un sens sous Windows.

Avant le fichier texte était la norme et le fichier binaire l'exception. D'ailleurs, les formats binaires n'avait pas trop la cote (GConf toussa). Et puis il y a eu XML et on s'est aperçu qu'un format texte pouvait être aussi dégueulasse qu'un format binaire. Du coup, maintenant, les (nouveaux) tenants des fichiers binaires conchient les défenseurs du vénérable fichier texte à coup d'argument moraux du genre «vous ne voulez pas évoluer». Ces derniers se défendant à coup d'arguments moraux du genre «vous ne comprenez rien à Unix». Mais à mon avis, toute cette histoire texte/binaire, c'est juste pour renouveler les sujets à troll.

Du coup, j'ai parcouru la norme SVG 1.1.

Oui, on peut déclarer un objet en lui donnant un nom, et l'invoquer plus bas. Y compris plusieurs fois pour afficher plusieurs fois une même forme. Et à chaque fois on peut faire subir diverses homothétie et autres translations.

Je ne savais pas que SVG pouvait faire ça. D'un autre côté, ça ne doit pas être très utilisé par les éditeurs graphiques.

Et puis, il manque quand même des choses assez utiles, comme définir des variables avec des réels, pour éviter d'avoir à répéter des nombres qui ont la même sémantique. Et il n'y a pas d'expression (ou alors, je n'en ai pas vu) permettant de définir un point ou un réel ou un vecteur ou une couleur.

Les fonctions et les structures de contrôles je vois pas bien ce que tu veux dire par là.

Si je veux afficher 50 carrés disposé en rond, j'aimerais pouvoir le faire dans une boucle for plutôt que de définir 50 carrés. C'est impossible de le faire en SVG nativement. Si je veux une fonction qui renvoie une couleur suivant certains paramètres, je ne peux pas. Etc.

Bref, ça montre au moins que tu n'as pas fait une analyse de l'existant très poussée avant de te lancer dans ton propre projet.
XML étant fait pour être facilement étendu, tu devrais peut-être regarder si ça t'aide pas d'étendre SVG plutôt que de partir de 0.

Désolé, je préfère partir de 0. Parce que SVG n'est pas très adapté pour une édition manuelle, comme la plupart des dialectes XML. Et puis je considère que je ne réinvente pas la roue, je pars des mêmes modèles de dessin que SVG, à savoir PostScript (il suffit de voir comment SVG est né pour le comprendre). Toutes les libs vectorielles 2D font pareil et on ne leur dit pas de se baser sur SVG.

Sur ce que j'ai présenté, OK. Mais je ne compte pas m'arrêter là sinon ça n'aurait aucun intérêt ! Est-ce que SVG permet de définir et réutiliser des variables qui contiennent des objets, des propriétés, des transformations ? Je ne pense pas. Est-ce que SVG permet de créer des fonctions, d'avoir des structures de contrôles ? Avec JS, peut-être, mais ce n'est plus SVG. Est-ce que SVG permet de faire du placement relatif ? Non. Et tout ça, je compte bien l'inclure dans mon langage.

Je pense que c'est "envie de faire plaisir aux copains", de deux manières différentes. En taxant les moteurs de recherche, on ne risque aucun conflit avec un industriel français, vu qu'on n'en a pas sur ce créneau. En revanche, on a plein de copains qui sont à fond pour cette solution parce qu'ils n'ont rien compris.

Je partage l'avis de Fabrice Epelboin sur Reflets.info, tout ceci n'est qu'une question industrielle : comment protéger (ou en tout cas croire qu'on protège) l'industrie française ? Toute l'action de Fleur Pellerin depuis qu'elle est à ce poste (et celle de ses prédécesseurs) va dans ce sens. Toutes les décisions et propositions rocambolesques peuvent être comprises à travers ce prisme. Et pour moi, l'explication est tout à fait crédible.

Je vous invite à donner votre avis, surtout si vous êtes pour !

Ha ben elle est belle la discussion, et si on est contre, tu vas nous moinsser ?

Plus sérieusement, ça ne changera strictement rien du tout. Je moinsse parfois parce que je ne suis pas d'accord, et ça ne me posera aucun problème que mon pseudo soit affiché. Donc, je continuerai à le faire. Ça fait partie du jeu, linuxfr est ainsi fait qu'on plussoie et qu'on moinsse, tout le monde participe et je n'ai pas l'impression que ça freine les gens d'avoir des positions à contre-courant.

Du coup, j'ai cliqué sur inutile dans l'entrée de suivi. J'ai bon ?

La différence art/outils est primordial.

Quand on écoute certains produits des industries du bruit musicales, on se dit que c'est un très bon outil pour faire passer le temps à la caisse du supermarché.

Ceci dit, tu parles de choses qui n'ont aucun rapport avec le sujet. On parle de licence (libre ou pas) et donc, de droit d'auteur. Le droit d'auteur ne définit pas ce qui est de l'art ou pas, ou ce qui est un outil ou pas, il définit ce qui est une œuvre de l'esprit. Et dans le droit d'auteur, il y a les photos, la musique, la littérature et les logiciels. Et quand on définit «libre», c'est par rapport aux droits d'auteur, parce que bon, une licence, c'est un truc juridique, c'est pas une position philosophique. Donc «libre» a déjà un sens dans ce contexte juridique et ça, les tenants du «je fais du libre mais pas vraiment mais je veux appeler ça libre» n'y peuvent rien. Tant pis pour eux !

Mon problème, c'est que j'aime bien les deux visions et que j'aimerais que les deux soient bien intégrés l'une par rapport à l'autre, et que je ne suis encore convaincu par aucune solution. Avoir deux syntaxes pour les mêmes objets me paraît bizarre. Avoir une seule syntaxe ne permet pas de distinguer les deux cas facilement.

Nombre de logiciels libres écrits en C ou C++ ont en fait vérouillé leur plate-forme indirectement par l'utilisation de constructions supportées uniquement par gcc (au hasard, les macros avec nombre d'arguments variables).

Les macros avec nombre d'arguments variables font partie de la norme C99 et de C++11. Seulement, elles ont un problème de conception, le nombre variable est obligatoirement supérieur ou égal à 1 plutôt que 0. D'où une syntaxe GNU qui permet d'éliminer ce problème.

Mais d'une manière générale, oui, il existe un nombre certains d'extensions, qui parfois rejoignent la norme suivante (comme les commentaires C++ qui étaient une extension puis qui ont rejoint la norme C99).

Il n'y a actuellement aucun problème de rendu avec les jointures. Je te conseille de lancer par exemple la démo Qt4 pathstroke (package qt4-demos dans Debian) pour te rendre compte des possibilités. Tout est déjà implémenté et de bien belle manière, donc inutile de refaire ce travail à mon sens.

Non, ce n'est pas exactement la même chose. Parce que dans un trait, il y a deux éléments qui sont pris en compte dans le modèle de dessin actuel : la manière dont la jointure entre deux traits consécutifs dans un chemin est dessinée et la manière dont le bout du trait est dessiné. Sans compter le fait qu'on puisse faire des pointillés facilement. Si on considère qu'un trait est un rectangle, on doit réimplémenter ces éléments d'une manière ou d'une autre. Et je n'aborde même pas le cas des traits courbes.

Encore heureux. #ifdef c'est sale. Un programme bien conçu n'utilise pas #ifdef pour assurer la portabilité, mais il sépare le code portable et le code dépendant d'une plateforme dans des fichiers différents, et laisse le système de build choisir quels fichiers compiler.

Tu devrais en parler à Lennart, il n'est pas au courant.

Tu es en train de me dire qu'un utilisateur qui n'a pas les capacités de contribuer n'a d'autre choix que de fermer sa gueule.

Non, ça c'est toi qui le dit. Moi, j'ai posé la question.

Des devs bénévoles

C'est tout à fait ça, Lennart c'est un brave bénévole, il vit d'amour et d'eau fraîche.

Susceptible, hein ?
Remarque pourtant que je n’ai pas dit « ça ne sert à rien » ou « ça existe déjà ». J’ai demandé « pourquoi ? ».

J'attendais mieux d'un premier commentaire que trois lignes qu'on retrouve systématiquement, quel que soit la proposition qui est faite.

La problématique d’un langage descriptif de dessin vectoriel a déjà été traitée plusieurs fois. Et les questions que tu exposes ont aussi été traitées par ces formats.

Et les réponses apportées diffèrent parfois, donc ça montre que rien n'est figé.

Et ne méprends pas ce que je dis, comme tu l’as déjà si facilement fait avec ta gueulante.

Ben c'est tombé sur toi, mais ça ne t'étais pas destiné spécialement.

Je dis qu’il y a eu des réponses, que ces réponses peuvent avoir des défauts mais que jeter tout ce qui existe sans critique, c’est-à-dire sans étudier les forces et les faiblesses, est une attitude puérile et non constructive.

Qui te dit que je ne l'ai pas fait ? Simplement, je n'ai pas fait d'état de l'art dans ce journal parce que ça ne me semblait pas nécessaire. Mais je pourrais, il suffit de lire une partie de mes réponses et tu auras ta réponse.

Et, moi aussi, je peux pousser une gueulante, envers tout ceux qui, quand on leur pose une question pour qu’ils approfondissent leur questionnement, pensent immédiatement et sans aucun doute que l’on n’est rien que des méchants vilains qui veulent tuer leur merveilleuse idée dans l’œuf, empêcher toute forme d’innovation et dénier leur fabuleuse créativité.

Dans ces cas là, écris un peu plus de trois lignes et ta critique sera plus crédible.

Cette réponse serait pertinente si tout utilisateur avait les capacités pour contribuer, ce qui est très loin d'être le cas. Ensuite, il y a ceux qui ont les capacités mais qui font autre chose, qui contribuent autre part. Enfin, il y a ceux qui peuvent contribuer et qu'on envoie chier (genre «non, non, on ne mettra pas de #ifdef dans mon code pour assurer une meilleure portabilité»).

Pour moi, un utilisateur n'a aucun droit, et encore moins le droit de faire chier le monde en râlant sans cesse.

En gros, il a le droit de fermer sa gueule, c'est ça ?

Plus que le choix, c'est avant tout l'entremêlement de couches qui n'ont a priori rien à voir les unes avec les autres qui m'inquiètent. Quand on lit que GNOME pourra dépendre d'un init particulier, on croit rêver… Oser prononcer ce genre de phrases quelques années en arrière relevait de la folie pure.

Moi j'attends la première alerte de sécurité dans systemd pour refroidir un peu tout le monde.

On doit pouvoir afficher n'importe quoi à partir du PS, donc en créant un language qui exportera en PS, ça t'évitera l'étape fastidueuse de la gestion de l'affichage, sauf si le challenge de ce type de développement te motive, ce qui peut être également une bonne raison.

Heu, pour l'export, je vais tranquillement me reposer sur cairo (je pense) qui a un backend PS, un backend PDF, et aussi des backend pour les principaux systèmes d'affichage (Xlib et XCB pour Linux and co par exemple) ce qui permettra d'avoir une sorte de preview de l'image. De cette manière, je ne m'occupe que du «frontend» et je laisse le «backend» (ce qui correspond à la génération de code pour un compilateur) à cairo qui va me générer les bons formats.

Pour en revenir à graphviz, désolé d'insister, mais il est possible d'y intégrer des formes personnalisées.

Avec les liens que je vois, on est obligé de passer par un fichier externe. Ou alors, on est limité à la boîte rectangulaire. Du coup, on n'est pas très avancé. Je ne dénigre pas Graphviz hein, je le trouve merveilleux dans son domaine de prédilection et je l'utilise assez souvent pour ça. Je l'ai aussi utilisé pour faire des diagrammes de classes UML, ça marchait à merveille. Mais là, je ne vois pas bien comment être flexible avec Graphviz.

Pour moi, l'idéal (je sais pas si tu compte le faire) serait d'ajouter la possibilité de définir des animations de ces formes

En fait, ça fait partie des questions que je me pose : est-ce qu'un fichier correspond à une seule figure ou alors, est-ce qu'un fichier peut produire plusieurs figures ? Je vois des avantages et inconvénients dans les deux approches.

d'ajouter aussi des boites textes (si ce n'est pas déjà présent)

C'est prévu, mais je préfère prendre mon temps sur ce point parce que dès qu'on parle de texte, c'est très vite la galère (les caractères non latins, les fontes, toussa).