mothsART a écrit 180 commentaires

Comme dis plus bas, PHP respecte Semver et l'inverse m'aurait étonné donc y'a pas vraiment de débat.

Je sais bien que des projets qui ont une visibilité hors dev ce permettent d'incrémenter la version principal sans bc : Linux depuis pas si longtemps, Firefox, Gnome etc.
C'est des schémas assumés car dans leur cadre, ils déprécient peu de choses.

Gimp et Gcc sont Semver compliant.

Latex a fait le choix de ne pas s'appuyer sur Semver donc c'est délibéré.

Bien pour le coup, je reste obtus : Semver est volontairement simple, accessible et compréhensible. C'est une règle commune à tellement de projets que je trouve vraiment dangereux de s'y soustraire. Sois tu respectes, soit tu respectes pas mais tu fais pas à moitié. (personne ne viendrait à faire des mesures en mélangeant des mètres et des pieds)

Héhé, tout s'éclaire. Intéressant !

Il m'en faut plus pour être "froissé" et là n'est pas la question.
Je considère juste qu'il faut tendre vers l'impartialité.
Il faut toujours garder en tête que rien n'est "parfait".

A titre d'exemple, j'ai porté quelques softs sous Nix qui étaient déjà empaqueté sous debian.
En le faisant de manière brut (juste édition d'un fichier nix), le soft se lançait mais certaines choses ne fonctionnaient pas bien : mon applicatif appelait des fichiers avec des chemin absolu selon les conventions d'arborescence Unix au lieu de passer par des chemins relatifs.
J'ai donc adapté mon code.
Si le paquet avait été validé tel quel dans la distrib sans que je m'en aperçoive, est-ce que ça aurait été un soucis de Nix ou de l'applicatif ?
Je présume que le soucis aurait été identique sous Guix.

Après, il faut se rendre à l'évidence : même si la partie packaging est purement fonctionnel (pas de bash ni aucun truc avec effet de bord) si l'applicatif derrière est très permissive et pas réfléchit pour… ça pourra pas être parfait !
Mais d'un point de vue utilisateur, l'amalgame est vite fait : à tord ou a raison.

donc ceci n'est pas vrai :

n'introduit pas des incompatibilités avec les versions précédentes

Que sais-tu des besoins et envies des développeurs sur ces projets en PHP, surtout pour les projets internes ?

Pour avoir bossé dans plusieurs boites avec plusieurs technos et des devs avec des niveaux différents, je dirais qu'un dev qui va promouvoir PHP est un dev qui n'a eu que très peu d'autres expériences de langages (ou alors sur des trucs tellement plus archaïque qu'il n'est pas vraiment objectif).
Dire le contraire c'est ce voiler la face.

Si un langage satisfait les objectifs de l'application, aucune raison de changer.

Peu importe l'application, y'a des constantes : la fiabilité, la productivité et la performance sont présent pour n'importe quoi. C'est le pourcentage entre chaque qui change et le degré d'exigence.
Sur la fiabilité, je pense que les bugs critiques (erreur 500) ne plaisent à personne.
Sur des gros projets, tu dois pouvoir faire des modifs, du refactoring sans connaitre le code dans sa globalité, avoir toutes les connaissances métiers et sans avoir forcément une couverture de tests de malade et également travailler avec des personnes qui ont des niveaux variables (le mec qu'à 20 ans d'expériences en PHP va sans doute réussir à faire pas trop mal parce qu'il aura anticipé une bonne partie des faiblesses du langage)
PHP n'ai franchement pas taillé pour ça.

Totalement subjectif. Question de goût.

Le goût, ça s'affine.

Mouai, ça montre surtout que tu ne connais pas bien l'éco-système PHP

Non, je ne connais pas bien car comme dis et du peu que je regarde, c'est que du réchauffé. On fait des trucs déjà existant depuis longtemps dans la techno qu'on connait bien mais pas ou peu d'innovations.

Quand j'ai été en relation avec des devs PHP "expérimentés" à chaque fois qu'on évoquais certains points (genre l'asynchronisme) c'était "on peut" et une fois dans les faits : "ben, c'est compliqué, tu comprends, y'a du legacy…"
Soit ils étaient tous nulles soit y'a anguille sous roche.

On peut faire plein d'autres choses que du web.

Mais pourquoi s'infliger ça !
Quand je bricole, je fais pas tout au marteau même si c'est possible.
Pourquoi prolonger la vie d'un truc qui s’essouffle ?
Justement, avec les VM/containers, une archi orienté micro-services, on peut varier les plaisirs.

ReactPHP

Donc c'est pas natif et je sens la blague pour coupler ça avec des frameworks.

Ben, quand on utilise des notations du genre "7.4.0 beta 1", pour moi on fait du semver.

Après, si c'est à moitié respecté, j'aurais tendance à dire qu'ils font de l'amateurisme.

Concernant les paquets cassés, c'est très rare. Ca arrive mais beaucoup moins que pour Nix par exemple.

Oups, bavure ?
On peux rester courtois et ouvert d'esprit plutôt que de partir sur des facilités ?

Sinon, mes paquets Nix vont très bien, merci.

Le passage de PHP 5 à 7 a été très compliqué

Je parlais plus de l’émergence d'une version 7 : on a quand même eu une période très longue entre les 2 avec une version 6 avorté.

Je n'ai quasiment rien modifié dans les applis PHP que je maintiens.

Tout le monde n'a pas été aussi chanceux.

Les améliorations qu'il y a eu dans PHP 7 et PHP 8 au niveau syntaxe, n'introduit pas des incompatibilités avec les versions précédentes. Ce sont des ajouts. Tu n'es pas obligé d'utiliser toutes ces nouveautés syntaxiques.

Ça me fait toujours sourire cette entorse à Semver : Version majeur mais sans breaking changes.

Je pense que je ferais le pas Guix un de ses 4 un peu pour le fun au début et peut-être en complément de Debian/Nix.

En dehors du fait que je sois sceptique sur certains points, je trouve ce projet bien plus novateurs que pas mal d'autres. Sans doute un des seuls vrais candidats (avec Nix) pour remplacer "apt", "pacman" ou autre gestionnaires vieillissants mais également fournir de meilleurs solutions que Snap , Flatpack et cie.

Très orienté GNU : on fait tout nous même.
C'est un parti pris.
Dans l'absolu c'est une bonne idée, dans les faits : ça occasionne des projets qui avancent au ralenti et qui n'attire pas vraiment les jeunes générations de devs.

Excuse moi si je me trompe mais ce process d'archivage n'a rien à voir avec le langage Nix utilisé pour du packaging.
C'est effectivement ultra critique mais c'est touché (et revue) par très peu de personnes, à la diff d'un fichier Nix qui va décrire l'empaquetage (en somme, tout ce qui est dans https://github.com/NixOS/nixpkgs/tree/master/pkgs) d'un logiciel en particulier.

donc des Nix expressions qui génèrent des fichiers qui sont ensuite parsés par du Python et le tout recollé avec du Shell.

Le python/shell (voir même peut-être la partie Nix) pourrait très bien être remplacé par du OOCaml, du Rust ou autre langage un peu plus rigoureux et l'affaire serait close.
Justement, Nix ne fait pas le parsing car il ne sait pas faire et comme déjà dit : tant mieux, car c'est un DSL (même si cette notion est vague).

Que la partie core du projet soit un mélange de C, Rust, Python et de Bash ne me pose pas de soucis outre mesure du moment que pour l'empaqueteur final n'a qu'à gérer un fichier nix réduit à peau de chagrin.(du genre https://github.com/NixOS/nixpkgs/blob/13a3e5023192b62d6c5662c37549d8bb9e5e6a28/pkgs/applications/editors/geany/default.nix)

Alors, tout n'est pas parfait, j'en conçoit. Ce genre de choses devraient être évité/remplacé dans la mesure du possible : https://github.com/NixOS/nixpkgs/blob/e66ba6bd4619068541dd0446e2c69f2a7cba08a2/pkgs/applications/graphics/ImageMagick/default.nix#L83
mais ça reste suffisamment cloisonné pour rester "acceptable".

PHP comme tous les langages est compilé mais compilé au runtime, ce qui signifie que le moindre run vérifie toute la sémantique de type tant que tu ne t'appuis pas trop sur du typage dynamique.

Ben, voilà : t'as bien résumé ce que je reproche.
Vous voulez de la perf mais aussi vérifier des trucs au runtime et être interprété : on tente de résoudre la quadrature du cercle.

OwnCloud a clairement choisi PHP car on ouvre plus d'hébergement LAMP que python, perl ou ruby.

Oui, et c'est parce que certains softs sont fait en PHP que les hébergeurs ne font aucun effort : le serpent qui se mort la queue.

J'espère franchement que la mode des conteneurs va faire sauter ce verrou : ça permettra de mettre tout le monde sur un pied d'égalité.

Blague : Owncloud pouvait le faire en Haskell et transpiller en PHP

Si on rentre dans les détails, ça peu effectivement paraitre plus flou.
Néanmoins, pour obtenir ce bytecode, on doit exécuter une première fois Python ou le lancer dans un build.
Et puis bon, les vérifs faites sont clairement très superficiels.(ce qui n'est pas forcément un mal)
Mais comme dis, ça dépend de la typologie du projet : pour plein de choses, Python me convient très bien mais je désapprouve toute tentative de le rendre plus typé car on risque de perdre ses plus grand atouts : simplicité, rapidité, lisibilité.

lancer mypy en ligne de commande sans problème sans passer par un IDE pour vérifier le typage ?

De l'analyse statique c'est toujours réalisable, en effet mais je doute que beaucoup le face au final.
Dans un langage compilé, c'est juste imposé.

Je ne comprends pas cette haine contre PHP.

Pas de haine, un désintérêt abyssal.
De mon côté, je ne comprend pas pourquoi on ne laisse pas mourir une techno.
Le passage de PHP 5 à 7 a été très compliqué et je ne comprend pas cet acharnement de mobiliser des core dev à reproduire des choses qui existent depuis moultes dans d'autres technos et d'essayé d'être rétro-compatible.
(Python que tu cites à fait un choix plus sain à mon sens en dépréciant plein de choses avec Python 3)

Blague à part : vu que le PHP des début ne ressemble à presque plus rien de ce qu'il est actuellement… je serais au commande, je ferais évoluer PHP pour que ça soit 100% compatible Python3 à la version 10. Comme ça au moins, l'affaire serait bouclé.

Depuis que le web c'est orienté "framework", API, microservices et "app" plutôt que "site", je n'ai pas compris l'intérêt de poursuivre avec PHP : l'effort pour migrer un gros site/applicatif d'un PHP natif vers du Symphony/Laravel mobilise autant d'énergie que de changer de langage.

Les projets que tu mentionnes existent depuis longtemps et le choix de PHP a leur début était bien plus logique que maintenant. Une migration semble désormais délicate (mais pas impossible).
Wordpress et Facebook sont pour moi moribond (même si PHP est loin d'en être la cause) donc ils ont pas vraiment de poids dans la balance.

Autant pour du legacy je peux comprendre qu'on maintienne un langage, autant pour des nouveaux projets, je n'identifie pas l'engouement.

Rejeter ce langage d'un revers de manche parait un peu réducteur.

Ben, justement, il existe tant de langages avec des bases tellement plus en adéquation avec les problématiques de notre époque ou future.
C'est triste à dire mais rien autours de PHP ne m'évoque l'avenir.

Autre point qui me chiffonne : pas de gitlab/github/bitbucket mais savannah. Je sais que ça va encore un peu à l'encontre du "Libre" mais bon, derrière on se prive d'une tonne d'outils modernes (issues, git-flow, ci etc.) et de visibilité.

Déjà merci pour cette dépèche très rafraîchissante sur une distrib peu connu !

Connaissant un peu mieux Nix, je ne serais sans doute pas très objectif non plus.

Avec Nix, il est nécessaire d'apprendre un nouveau DSL …

Là ou tu vois une faiblesse, je vois une qualité.
De toute façon, tu trouveras peu de développeur Scheme (qui ne connaisse ou ne participe pas déjà à Guix) et du coup, ça demande de toute façon d'apprendre un langage pour l'occasion.

Le fait d'avoir un DSL plutôt qu'un langage complet me parait justement plus approprié : on ne s'étale pas, on va a l'essentiel et y'a pas 36 façon de faire la même chose donc sans doute plus simple en terme de review.

G-Expressions

En effet, dans l'absolu c'est mieux. Dans les faits ça reste minimes à mon sens.

Guix ne propose donc pas de logiciel non-libre

Ça, pour moi, c'est rédhibitoire. Qu'on cloisonne les choses comme dans Debian, ok mais ne rien supporter de non libre, c'est forcément se positionner sur un marché de niche.
Faut savoir être pragmatique ! Je préfère avoir un système à 95% libre mais "utilisable" parce que mon GPU est supporté, que je peux utiliser ponctuellement tel logiciel etc.

Ça avance vite

Oui et non car plein de concepts ont 10 à 20 ans dans d'autres langages.
Ces typages sur des langages interprétés ont tendance plus à m'agacer : ça encourage des boites à continuer à faire de l'interprété plutôt que du compilé alors que c'est de la poudre aux yeux : tout ce fait à l’exécution et non en amont et finalement si on veut vérifier du typage avant la mise en prod, on s'appuie sur l'IDE (c'est pas son rôle à mon sens) et des tests.

Perso, quand je m'oriente sur des petits projets, des POC ou des scripts en one shot, j'aime bien passé par de l’interprété car ça me permet de faire vite.
Rajouter des infos de typage, c'est justement contre-productif dans ce cadre.

Si en revanche, je pars sur des projets plus complexes, je choisi du compilé et du typage fort (PHP en est encore loin et Typescript est bien meilleur).

Je ne vois qu'un intérêt aux améliorations de PHP : améliorer la qualité de produits qui ne peuvent pas changer de techno rapidement.
J'épiloguerais pas sur les choix de rétro-compatibilité qui font plus de mal que de bien, la syntaxe juste imbuvable quand on a connu d'autres choses, l'incapacité de faire de l'asynchrone, de faire autre chose que du web etc.
PHP aurait du s'arrêter à la version 3 sans objets : ça restait un langage de template pour faire des petits sites amateurs sans prétention.
Bref, dans tous les autres cas, changez de langage.

J'ai tenté l'install de nixGL et voici le résultat :
…
Using ld found on system at:
/nix/store/ks84d039ps8k9qrqjg4pfh707jmm4san-binutils-wrapper-2.31.1/bin/ld.gold
No pkg-config found
Using runghc version 8.8.3 found on system at:
/nix/store/wmvm4961nj76zpwy8yp1xnq2zp6jazdm-ghc-8.8.3/bin/runghc
Using strip version 2.31 found on system at:
/nix/store/03qd31jk1xl6vp27sm4yd640p0lk37vp-binutils-2.31.1/bin/strip
Using tar found on system at:
/nix/store/mhvgq9lnx1gmbx859ilgvi1zvznh1c14-gnutar-1.32/bin/tar
No uhc found
building
Preprocessing test suite 'test-sha' for SHA-1.6.4.4..
Building test suite 'test-sha' for SHA-1.6.4.4..

<no location info>: warning: [-Wmissing-home-modules]
    These modules are needed for compilation but not listed in your .cabal file's other-modules: 
        Data.Digest.Pure.SHA
[1 of 2] Compiling Data.Digest.Pure.SHA ( src/Data/Digest/Pure/SHA.hs, dist/build/test-sha/test-sha-tmp/Data/Digest/Pure/SHA.o )
ghc: out of memory (requested 1048576 bytes)

Des idées ?

Allez, on se calme, cet espace est justement la pour échanger (troller) et on commence à avoir l'habitude que ça tourne au conflit d'intérêt. C'est une des grandes traditions sur linuxfr !

Perso, j'ai apprécié ton article (et d'ailleurs tout ceux que tu réalises autours de Nix) : c'est toujours enrichissant de voir des problématiques être traités différemment.
Au final, peut importe celle qui est la mieux, ce que je trouve toujours édifiant autours du libre c'est la grande richesse de possibilités et le fait que dans tout choix technique, il y ai des avantages et des inconvénients et donc un arbitrage à faire, soit individuel soit collectif.

Perso, les rollbacks Nix sont vraiment une des fonctionnalités qui m'intéresse le moins dans la techno. L'installation en user, le fait de pouvoir l'utiliser sur une distrib hors NixOS, le côté "fonctionnel" et la simplicité de créer ses propres paquets m’enthousiasme d'avantage mais c'est toujours bien d'avoir une vision plus large que celle de ses propres besoins.

Après, à l'avenir, si tu construisais ton article avec :
"Voici comment la plupart font et voici comment je fais" plutôt que "j'ai une meilleur solution" tuerais sans doute un vent de protestation dans l’œuf.

Merci pour le ticket !

Avez-vous des idées d'activités pour ces âges-là ? Nous avons une liste d'activités à faire (https://phabricator.kde.org/project/view/142/), mais elle peut être enrichie en fonction des besoins.

J'ai déjà créé un compte sur votre forum et je pense que je vais passer par cet outil pour vous faire des propositions.

Comme dit dessus, plusieurs professeurs sont déjà en contact avec nous pour donner leurs avis sur les activités, ce qu'il fallait améliorer pour que l'objectif pédagogique soit atteint. Un autre exemple, ce sont des professeurs breton qui proposé l'idée d'ajouter des sous-domaines et qui les ont définis afin de mieux trier les activités.

Tant mieux. En effet, j'ai déjà remarqué des vrais améliorations sur les dernières versions (pas encore testé la 1.0) ce qui discréditent certaines remarques que j'aurais pu vous faire. (et oblige la distribution Primtux a rapidement se mettre à jour)

Comme dis, si j'ai quoi que ce sois à redire, je pense que le forum sera plus approprié car ça concernera sans doute des activités en particulier.

En effet, merci de corriger mes inexactitudes… je parlais effectivement d'analphabétisme.

@mahikeulbody : Les 2 points, je parlais de l'install auto et de BTRFS bien sur.

@barmic : j'avais pas pensé aux hooks, bonne idée.

Suite incontournable apprécié par mes enfants : bravo et merci !
J'aide actuellement modestement à la distribution Primtux et je pense qu'établir des ponts en plusieurs projets (je parle de ma paroisse mais il y a sans doute d'autres projets) serait bénéfique !

Voici quelques suggestions et questions :

• orienter plus le dev vers le cycle 3 (CM1, CM2 voir 6ème) car c'est un peu plus riche pour les 2 premiers cycles.
• faire valider par les professeurs des écoles pour que les activités correspondent plus aux vrais besoins éducatifs : des fois, un peu approximatif. (je ne suis pas prof mais juste parent d'élève donc je ne fais que répéter)
• est-ce qu'il est possible de lancer gcompris directement sur une activité précise ? Du genre "gcompris --launch "nom de l'activité" ? Je m'explique : je développe actuellement un logiciel nommé "PrimtuxMenu" qui remplacera les handymenus actuelles : en somme une interface d'accueil qui permet aux enfants d'avoir sous les yeux l'ensemble des logiciels de leur niveau et classé par matière. Pour gcompris, le lancer repasse par un menu qui fait un peu office de doublon (dans notre contexte : il reste bien entendu tout à fait légitime pour d'autres distrib) et ne nous permet pas de classer ces activités dans notre soft. Si par exemple l'enfant souhaite accéder à une activité mathématique, nous allons ranger Gcompris dans un niveau bien précis et donner la marche à suivre pour accéder à cette activité. Ce n'est pas vraiment l'idéal, surtout pour les enfants encore illettrés.

je fais un instantané avant chaque mise à jour de paquets

ah, oui : c'est pas vraiment comme ça que j'envisage l'informatique. Si mon instantané peut être fait automatiquement, c'est mieux.
Bon j'imagine que c'est possible de faire un alias bash ou zsh qui lance ton instantané avant de mettre à jour mais bon on rentre dans la bidouille.

Manjaro créé automatiquement une entrée dans grub pour chaque snapshot du sous-volume BTRFS…

Quand tu me parles de Timeshift, je pensais plus à rsync (usage le plus courant) que à BTRFS.

J'avoue que si tu règles ces 2 points, on obtient un léger avantage pour ta technique vu que les snapshots de BTRFS doivent être bien moins gourmand.