ff9097 a écrit 637 commentaires

ça sera probablement stable lorsque l'application grossira et ça deviendra du coup intéressant

C'est par défaut sur Fedora depuis 6 ans

Et python serait la seule cause ?

Sur quoi te base tu pour dire que Prince serait nettement plus rapide ?

Normalement seules les apps ont un fichier avec les versions des dépendances fixées. Je crois que pour les bibliothèques ce n'est pas conseillé. Je ne sais pas quel est ton cas.

En fait, le code fonctionne très bien avec PyParsing-3.0.9 (j’ai essayé).

Tu as testé tous les cas possibles ? Ou juste ceux que tu utilises et en fait : "ça a l'air d'aller" ?

Les virtualenv dépendent quand même de la version de python du système, il n'est pas possible d'avoir deux environnements avec deux versions de python différentes.

Le lien DKMS pointe vers une mauvaise page, voici la bonne : https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support

Le framework Flutter (langage Dart donc compilé) fonctionne de la même façon

Oui bien sûr mais ça rends l'utilisation très simple et on n'a pas à faire de l'impératif

Dans les toolkit graphique, tout redessiner est très couteux, on gère donc des modifications qui deviennent un enfer à tenir cohérent.

Il me semble justement que React notamment est declaratif et donc que "tout" est redessiné et ça ne pose pas de soucis

Ça a l'air très séduisant mais 230€… Je n'ose pas imaginer le prix de l'ordinateur portable modulaire à venir. Si c'est le prix qu'on doit payer pour relocaliser et faire durer nos équipements, je crains que seule une petite partie de la population ne puisse se vanter de contribuer à l'avenir de notre planète. J'imagine que des esprits éclairés leur demanderont de renoncer au superflu.

C'est un cercle vertueux : c'est cher mais ça fait vivre des gens en France qui peuvent consommer et faire vivre d'autres, … Du coup au début oui c'est surtout pour ceux qui ont les moyens (et ils existent)

En même temps ça ne peut fonctionner que si c'est massivement utilisé. Compte tenu du fait que c'est assez peu contraignant ça me paraissait une bonne idée mais ça n'a pas accroché

J'utilise Plasma et ça fonctionne plutôt bien au quotidien mais bon déjà j'ai quasiment rien configuré et j'ai quand même des bugs de temps en temps de restauration sur mon double écran ou de bascule vers l'écran du portable quand je débranche. Et depuis quelques jours le raccourci pour ouvrir le menu principal ne fonctionne plus…
J'ai quand même le sentiment que si je configurais beaucoup j'aurais encore plus de problèmes…
GNOME me semble moins problématique parce qu'il y a eu des choix forts en terme d'ergonomie contrairement à KDE

Visiblement le second degré a du mal à passer ici aussi.

1) et aussi, un peu, car le machin-d’init-qui-fait-tout-et-presque-le-café m’agace, pas très Unix dans le sens : « je fais une seule chose, mais je la fais bien » tout cela !

Il ne fait pourtant qu'une chose : il gère ta machine

Qu'est ce qui explique la tendance de ces trucs ? Comment tout cela est née ?

Quand je reçois une contribution à un de mes projets, je l'oublie pas

C'est pas bête, je me demande si quelqu'un y a pensé avant.

Si je comprends bien, pour restaurer l'image il faudra toujours brancher 2 clés : la bootable avec redorescue et celle contenant l'image sauvegardé pour restorer. Il y a un moyen simple pour avoir les deux sur la même clé ?

Noto est relativement récent

Si je ne me trompe pas, actuellement c'est DejaVu + Noto car DejaVu ne couvre pas toutes les langues. En basculant sur Noto pour toutes les langues, on enlève DejaVu de l'installeur

Avoir la configuration des logs centralisés dans LDAP via une syntaxe standard de Java, c'etait pas non plus déconnant.

Je vois pas le rapport entre LDAP et les logs

CI c'est le minimum en effet. Après le delivery a chaque push je dirais que ça dépends.

Tu crois que ça n'est pas utilisé sur GitHub ni SO mais que ça serait très utilisé ailleurs ? Non c'est (quasiment) pas utilisé parce que c'est (quasiment) inutile.

Il n'y a aucun rapport entre des API taggés obsolètes et une soit-disant envie de pousser Kotlin puisque c'est la même API Android et que Kotlin est 100% compatible avec Java.
Franchement AsyncTask plus personne n'utilise cette horreur depuis des années