CrEv a écrit 4577 commentaires

Ok, donc en quoi utiliser clang restreint les liberté de qui que ce soit ?

clang/llvm participe justement à ça, pas avec les mêmes outils (tech vs politique en gros) mais je vois pas bien le problème là et surtout ça n'enferme personne. C'est peut-être moins militant, certes, mais répond aux questions de libertés.

Comme XP ?

Nan mais tout ça c'est pas une histoire de favoriser un OS ou un autre. En vrai tout ça c'est utiliser un backend spécifique à une plateforme :

Depuis la version 24.4, les utilisateurs d'Emacs sur MacOS pouvaient profiter d'un tout nouveau moteur de rendu pour le texte, basé sur une API plus moderne d'Apple (Core Text), ce qui améliorait le rendu des polices et permettait (entre autres) d'utiliser des polices colorées, dont celles représentant les emojis.

Tous les softs multiplateforme à un niveau ou un autre s'appuient sur les couches de l'OS. Une nouvelle API est dispo sur un système, ça semble pas anormal de l'utiliser.

il vaut mieux dire "on fait pareil sur tout les OS, point"

Mais ça n'existe pas ça :-)
Ou alors Emacs ne doit tourner qu'exclusivement en mode console et avec serveur X par exemple. Là ok. Mais du moment où on permet des ports natifs alors en vrai ce n'est de toute façon pas pareil sur tous les OS.
Donc refuser de mettre à jour une API de rendu de texte qui est plus moderne et améliore le rendu des polices pour un éditeur de texte c'est franchement surprenant. D'autant plus si la raison invoquée est que les autres systèmes n'ont pas eu droit eux à une mise à jour de leurs API.

Mais je ne comprends pas ce que tu veux dire.

Si on suit ta règle, il y aura toujours des gens pour dire que la fonctionnalité en question n'est pas suffisantes

Si c'est le cas alors ça montrera juste que le logiciel ne correspond pas/plus aux attentes de ses (potentiels) utilisateurs.

Tu dis que certains seront là pour dire que la fonctionnalité n'est pas suffisante. Ok. Ce que je rajoute c'est que s'ils ne sont pas écoutés et que la fonctionnalité est en effet insuffisante alors ça montre que le logiciel ne répond pas aux besoins (au moins perçu) de ces utilisateurs. Qu'est-ce qui n'est pas clair ?

Si elle ne pose pas de problème de maintenance (à priori ce n'est en tout cas pas la raison avancée) supprimer une fonctionnalité améliorant un logiciel pour ses utilisateurs est un signe plus négatif quant au fait de répondre aux besoins des utilisateurs. Ou alors il faut juste supprimer le port MacOS si le problème c'est que MacOS est en avance sur Linux…

De ma vision, la GPL est plus que jamais d'actualité. Le GPL-only est un moyen sacrément efficace pour assurer les 4 libertés. C'est probablement pour cela que peu de grosses boites l'utilisent.

Ben je sais pas, en quoi utiliser clang restreint mes 4 libertées ?
En quoi utiliser un projet open source les restreint ?

On peut aussi voir dans l'autre sens : la GPL par son côté exclusif a eu un rôle chiant mais qui a permis de ne pas avoir de demi mesure (enfin presque). Et maintenant toutes les grosses boites font du libre, de l'open source. Le code libre est devenu quelque chose de beaucoup plus normal et courant, il devient alors moins nécessaire d'avoir une licence qui segmente et on peut remercier la GPL d'avoir permis d'en arriver là.

Après, que l'écosystème GPL soit constitué aussi de vieux barbus ronchons et de vielles technos, c'est probablement un peu vrai :)

tu veux dire comme sur dlfp ?

Prenons l'exemple de Linux si tout ce qui se fait pour le support de wayland ne fonctionnait que avec les cartes Nvidia vous (ie Zenitram and co) trouverez cela normal?

Faut voir, si c'est parce que nvidia implémente des choses que intel par exemple n'a pas ça peut aussi être une façon de forcer l'autre à se mettre à niveau.
Et en fait ça marche même souvent comme ça ;-)

Si on suit ta règle, il y aura toujours des gens pour dire que la fonctionnalité en question n'est pas suffisantes

Si c'est le cas alors ça montrera juste que le logiciel ne correspond pas/plus aux attentes de ses (potentiels) utilisateurs.

utilisent clang parce que GCC a refusé certaines fonctionalités qui permettraient éventuellement de contourner l'esprit de la licence GPL (notament, ils ont refusé d'avoir un système de plugins)

Je ne suis pas certains que contourner la GPL soit la seule motivation au système de plugins.
Mais de ce que je vois c'est que beaucoup semblent apprécier les messages d'erreur et la rapidité de clang. Le truc c'est que malheureusement à force de tout verrouiller les utilisateurs partent juste là où les outils répondent à leurs besoins (si on était vendredi j'aurais dit qu'ils partaient pour plus libre mais je vais attendre un peu).

Du coup, est-ce que finalement ça n'aurait pas avancé plus vite avec la licence BSD et un peu de pédagogie pour expliquer aux gens et aux entreprises pourquoi ils devraient contribuer au libre? Plutôt que de les contraindre à le faire avec une licence du genre de la GPL?

C'est vraiment une très bonne question. On se rend compte aujourd'hui que l'open source est beaucoup plus présent qu'il y a ne serait-ce qu'une dizaine d'année. Même Microsoft publie de l'open source, ce que personne n'aurait vraiment cru au début des années 2000.
Toutes les plus grosses boites publient du code libre. Mais quasiment jamais sous GPL. C'est quand même super cool que tout le monde en face, mais ça pose en effet une réelle question sur l'utilité actuelle de la GPL qui parfois donne plutôt l'impression de s'enfermer dans un monde GPL-only, beaucoup moins ouvert que le reste, ce qui devient un comble.

on se retrouve avec du code à maintenir et à corriger

A priori ce n'est pas la raison du retrait, non ?

Donc je peux comprendre leur volonté de ne pas l'intégrer.

Volonté de supprimer vu que c'était déjà intégré.

Sinon les personnes "perdent" leur liberté de choisir le système qu'ils veulent (si c'est mieux chez l'un pourquoi aller chez l'autre ?).

Vraiment ? Quelqu'un va vraiment switcher de linux à mac juste pour pouvoir mettre des emoji dans emacs ?

Après je trouve que c'est surtout un nivellement par le bas. Faire du multiplateforme implique de toute façon d'avoir des différences. Sinon par exemple pourquoi les menus sont emacs sont-ils bien gérés comme des menu mac (et donc dans la barre en haut de l'écran) et pas dans la fenêtre comme sous linux ?

(bon c'est pas tout, mais après presque 15 ans sous emacs — sous linux, mac et même windows, y compris professionnellement pour les trois — je dois avouer que vim est pas si pire :-p )

Si, c'est ce que je devrais faire :-)
C'est plus une question de temps pour le moment, sur mes derniers devs j'ai repris un rails parce que beaucoup de choses marchent simplement directement. Et pour avancer très rapidement sur un domaine complexe c'est agréable comme première approche.

Mais en effet ça pourrait être une solution élégante pour faire du fonctionnel sans pour autant sortir du LFE ou du Clojure.

Mais les deux ne sont pas même pas forcément sur le même serveur.

Par serveur j'entendais juste côté serveur, sur le même, pas sur le même, dans un cluster ou autre ne change rien au principe ;-)

C’est clair qu’il y a un peu de latence supplémentaire, puisque tu ne peux pas charger le contenu côté serveur sans avoir chargé celui côté client.

C'est plus que de la latence, c'est aussi parfois juste le temps de démarrage de l'app côté client

souvent que quand ça rame, c’est parce que le serveur est lent à répondre

Ça me semble assez simpliste ;-)

c’est juste manipuler du dom avec du js

Oué enfin justement, ce dont on parle c'est bien d'avoir du js et du dom des deux côtés. On serait pas en train de boucler là ? Après le but c'est d'avoir ça de manière bien intégrée, et même code côté client et serveur.

phantomjs, c’est beaucoup plus bourrin, ça fait le rendu image.

Ça peut aussi juste être utilisé pour pouvoir exécuter du js, donc app client side mais server side

j’ai du mal à voir l’intérêt de faire un rendu serveur.

L'intérêt est dans la performance permettant à arriver au premier rendu utilisable côté utilisateur.
En général avec des app client side ça se passe en deux temps : chargement de l'app côté client avec tout le js qui va bien puis appel au serveur pour des datas qui ensuite sont rendues.
Mais c'est quand même un peu con car les datas étaient déjà connues lors de l'appel à la page côté serveur, pour l'utilisateur ça aurait été plus rapide d'avoir la page contenant déjà les bonnes infos.

la charge sur le serveur est celle qui coûte

Oui, c'est certains que ça coûte.

celle sur le client est gratuite (sauf exceptions)

Ha ben non, c'est pas gratuit du tout. Si par exemple tu fais un site de vente en ligne, tu verra que chaque seconde (ou dixième de) fait en réalité perdre des ventes. Un site qui rame est un site qui ne vent pas, mais aussi un site qui donne envie d'aller voir le concurrent plus rapide par exemple. Donc avoir une expérience utilisateur qui n'est pas bonne risque même de coûter plus cher que ton serveur.

la solution est peut-être plus à chercher dans un moteur de rendu html tournant au sein d’un reverse proxy que directement dans le code du site.

Pourquoi ? Ça me parait justement tordu voir super consommateur de ressources. Certains faisaient par exemple ça avec des phantomjs tournant côté serveur, je suis pas certains que ça ait laissé un super souvenir à beaucoup.

Pour ceux que ça intéresse il y a cette conférence de François Zaninotto sur "l'expérience utilisateur ultime" qui est vraiment sympa : https://www.youtube.com/watch?v=tIlQCIz9XF8

Pour faire simple, aujourd'hui pour avoir une "expérience utilisateur" correcte on fait des applications client-side. On navigue en ajax/fetch, on modifie que des morceaux de l'UI pour aller plus vite, avoir de la perf et que l'utilisateur ait une navigation confortable.
Mais en vrai dans ce cas les pages n'existent pas en statique. Donc pas de référencement par exemple (même s'il existe des gruges de ce côté ci).
Mais surtout, si on veut arriver directement sur une page précise, le serveur va rendre la base puis le client vas modifier ce qu'il faut pour afficher le contenu (car l'app n'est pas gérée côté serveur, en général côté serveur ce sont plutôt des api). Donc c'est lent.
Si on ne fait pas client-side, le serveur calcul tout à chaque fois, c'est sympa car en général la page demandée arrive très vite, mais la navigation est plus lente, le serveur re-rend chaque page et le client aussi.

Des technos comme turbolinks dont il est question dans Rails font un mix, les pages sont crées côté serveur et on fusionne body/header des pages côté client, avec une gestion de cache. C'est un intermédiaire assez sympa.

La "vrai" solution est donc que l'app tourne aussi bien côté serveur que côté client.
Côté serveur car cela permet d'arriver rapidement n'importe où (et même de faire du sans js).
Côté client car cela permet de naviguer agréable et rapidement dans l'app.

Par contre Rail (comme django ou symphony) ne me donne pas du tout envie

Ni django ni symfony ne me font envie, par contre rails toujours. Ça juste marche dans un max de cas et c'est l'exemple même d'extension du langage. On ne fait en général pas la différence entre ce qui provient du framework ou du langage ce qui est super agréable.

Ce qui me manque est de pouvoir faire une app isomorphique à base de ruby…

Qu'entends-tu par là ?

Que l'application réponde aussi bien en front qu'en back. Si l'app est chargée dans mon browser c'est une app client-side, je navigue dans mon browser. Mais si j'arrive sur n'importe quelle url directement elle est rendue par mon back. Et je ne parle pas d'avoir une pseudo génération du front dans mon back, mais bien que l'app soit exécutée aussi bien côté front que back.
Pour le moment le plus agréable (mais pas simple) que j'ai trouvé est de faire ça en clojurescript. Parce que franchement je n'ai pas envie de faire ça en js.

cadriciel

Oué, enfin pour le coup ça fait des années que c'est employé dans moultes dépêches et journaux ici même ;-)

Ça fait 10 ans que je code en ruby… et ça reste toujours mon langage préféré (même si clojure et go ne sont pas bien loin).
Mes dernières apps sont en rails 5 (avec turbolinks, action cable, etc) et des services gravitant autour qui eux sont en Go. C'est un mix assez agréable.

le langage Ruby s'est focalisé sur la productivité et la joie procurée par la programmation

Je pense que c'est clairement le point qui me plait le plus. Certes ruby n'est pas du tout le plus performant, ni le plus pointu. Mais coder en ruby reste un grand plaisir, la richesse du langage et de la lib standard fait qu'on a un langage très expressif et relativement naturel (dur à définir). Mon code reste souvent très concis, simple et lisible. Sur ce point même Go fait moins bien je trouve, avec souvent des grands enchainements de if err != nil à la pelle.

J'y ai retrouvé un perl mais en mieux :-)

Le seul point qui me chagrine un peu avec ruby, c'est que faire de la programmation fonctionnelle avec n'est pas évident. Si ce point était plus avancé ce serait top.

Bref, à chaque fois que je dois écrire un nouveau programme je me pose la question de la plateforme, et en général je reviens vers ruby, avec rails si j'ai besoin, ou du Go si je veux juste faire un petit service. Ce qui me manque est de pouvoir faire une app isomorphique à base de ruby…

Je pense que c'était une démonstration par l'absurde en reprenant tes termes.
Je ne pense absolument pas que l'art ne serve à rien. J'imagine que CrEv non plus ne pense pas cela

C'est bien ça :-)

C'est précisément ce type de raisonnement qui nous met dedans

Ha mais c'est juste ce qui sort de ton raisonnement hein ;-) C'est toi qui parle d'utilitaire ou inutile.

Mais au final, et c'est le point le plus important, ça n'explique toujours pas vraiment pourquoi on mettrait des DRM pour de l'art et pas pour du code.
Ok tu dis que le code peut être fait à plusieurs, ben l'art aussi.

L'art est plus souvent fait en solo donc DRM parce qu'on peut identifier ? Ok donc si je fais du code de manière personnelle et sans collaboration externe il n'y a donc aucun problème à mettre un DRM dans mon code ? C'est bien ça la logique ?

Le lien sur le site de TED, avec entre autre transcription et sous-titre pour ceux qui préfèrent : https://www.ted.com/talks/rodney_mullen_pop_an_ollie_and_innovate

qu'il me propose une méthode pour remplir le frigo des artistes et financer leur matos. Et pas les dons volontaires

le développeur il est mignon il a un vrai taff et fait du libre à côté. Mais dans ce cas pourquoi l'artiste ne ferait-il pas pareil ?

Surprise, c'est déjà ce qu'il fait.

Donc dans ce cas il n'a pas de différences

Ensuite le code est utilitaire et répond à un besoin technique (exception faite des jeux), alors que l'art ne sert à rien

Vu que ça sert à rien pourquoi on payerait pour ça alors que le code est utile et a donc de la valeur lui ?

Que le libriste se batte pour de l'art libre, j'aimerais alors qu'il me propose une méthode pour remplir le frigo des artistes et financer leur matos. Et pas les dons volontaires, s'il vous plaît (soyons sérieux, l'internaute est un porc qui consomme et se casse dans 95 % des cas).

Quelle est la différence avec le développeur ? Le développeur lui a le droit de ne pas remplir son frigo ? Il n'a pas besoin de matos ?
Ou alors le développeur il est mignon il a un vrai taff et fait du libre à côté. Mais dans ce cas pourquoi l'artiste ne ferait-il pas pareil ?

Quand j'écris des scripts ou des plugins (pour mes besoins), je suis ravi des les publier sous GPL 3. Mais l'art, c'est différent : c'est personnel, il y a souvent de vraies personnes dedans, et je ne tiens pas à ce que ça soit utilisé n'importe où n'importe comment.

Ha oui, ok, compris. L'art c'est différent, c'est personnel.

soyons sérieux

Ouai, justement, soyons sérieux.

Il est alors très difficile de passer au multi process après coup, sans casser toutes les extensions.

Oui, c'est certains que c'est compliqué. Mais la question que je me pose au final c'est plutôt "n'est-ce pas trop tard ?"

Là où je suis surpris (pas vraiment dans le bon sens) c'est au niveau de la date. Si j'ai bien compris on parle d'une première version (voir de seulement certaines avancées mais pas le browser en entier) fin 2017. C'est tout autant de temps où tous les autres vont continuer à prendre de l'avance et j'espère que le résultat sera suffisamment différent/meilleur pour intéresser du monde.

Après c'est cool, ça ressemble aussi un peu à Microsoft qui a réécrit totalement leur browser.
C'est juste dommage de s'être accroché aussi longtemps à un moteur qui, de ce que je lis à droite et à gauche, est autant affreux à faire évoluer (voir le temps pour arriver à du multi process sans être au niveau d'un chrome par ex)

Maintenant, je dirai genre 4h en utilisation dév un peu intensive

Ok, donc avec un écran de plus haute résolution et 32Go de ram ça fait probablement un peu moins.

Le seul truc sur lequel je n'ai pas d'avis, c'est le touchpad/trackpoint. Je ne m'en sers jamais parce que je déteste ça. Visiblement avec quelques réglages de vitesse/sensibilité, des gens les trouvent utilisables :).

Ha mince, le touchpad est pour moi un truc auquel j'accord pas mal d'importance, j'adore par exemple le touchpad de mac (gros, multitouch).

Bon courage pour ton choix, ce n'est jamais évident de choisir sans pouvoir passer quelques semaines avec !

Merci pour toutes les infos :-)

Merci pour le lien :-)

J'ai bien lu "Debian bof"

C'était dans le sens où ça ne m'intéresse pas d'installer une debian, rien de plus ;-)

Cool, merci du retour.
Ça donne quoi côté autonomie ? En 16 ou 32 Go ?