nlgranger a écrit 255 commentaires

Merci pour ton commentaire, je vais jeter un œil au forkserver et aussi à ipyparallel qui pourrait me servir au boulot.
Je n'ai pas voulu trop rentrer dans les détails pour le journal, mais ton premier point est aussi une des raisons pour lesquelles j'ai retiré le timeout sur les processus inactifs. Pour un de mes scripts, j'avais désactivé l'overcommit car je ne voulais pas me retrouver bloqué à l'extérieur de mon serveur en cas de fuites mémoire. Comme les forks pour redémarrer des workers avaient lieu pendant que je travaillais sur un gros tableau, j'avais des OutOfMemory rapidement.
Au sujet de ton deuxième point, c'est vrai mais ce n'est pas aussi terrible que je le craignais initialement. cPickle est pas mal optimisé donc la latence est négligeable dans beaucoup de mes cas d'utilisation. En revanche, j'ai fait quelques essais avec l'interpréteur PyPy qui implémente pickle en pur python et c'est souvent trop lent. Je ré-essaierai PyPy avec la mémoire partagée quand ils auront corrigé un bug dans le support des extensions.

J'ai oublié de mentionner d'autres projets similaires qui existent:

• dask est orienté pour le fouille de données, l’exécution à la demande n'est pas le comportement par défaut mais peut être explicitement demandée.
• joblib propose une version plus élaborée de ma fonction seqtools.prefetch avec une API fonctionnelle. Si c'est la seule fonction qui vous intéresse dans seqtools, pensez à y jeter un œil.
• Appache arrow est plus puissant mais franchement plus lourd et compliqué de mon point de vue.
• pytorch.data a moins de fonctionnalités.
• tensorflow.data est très lié au reste de l'écosystème tensorflow.

Dans l'ensemble, je pense que seqtools se distingue par le fait que ce soit très simple, léger et transparent: une dépendance, peu de code, son API qui prend et retourne de simples objets semblables à des listes et une gestion des erreurs pour aider l'utilisateur au maximum.

Je crois que la formule est justement destinée à faire référence à d'autres républiques peu démocratiques.

Oui c'est très bien mais c'est au bon vouloir du site, aucune banque française ne semble intéressée par ce standard. Pour l'instant je ne connais que paypal qui le supporte.

[EDIT: je me suis fais doubler :-)] Il y a un .deb disponible sur la page release du dépôt, c'est ce qui est aussi utilisé pour le paquet sous archlinux et ça ne demande pas de dépendances exotiques à côté, je ne comprend pas ce qui ne te conviens pas?

NVidia ne prend pas trop de risque si il ne libèrent pas la partie liée à CUDA. Le jeu sous linux est quasi inexistant donc pas de marché de ce côté. Par contre pour faire du calcul, la licence du driver proprio interdit actuellement l'utilisation de cartes G/RTX dans des serveurs (hors minage bitcoin?!) et force donc les entreprises à acheter des cartes pro au rapport qualité prix bien inférieur. Si le driver devient libre pour cuda aussi, ça changerait des choses.

Je présume qu'il y a un risque pour les hébergements de serveurs mutualisés à base de conteneurs type docker/kubernetes/lxc vu qu'il y a des changements des contexte entre différents clients sur un même coeur CPU. Et ça inclurait aussi les fournisseurs de services PaaS. Quelqu'un peut confirmer?

Pas sûr, il y a des bandes de fréquences en commun: https://www.everythingrf.com/community/galileo-frequency-bands

Tout à fait d'accord, à l'époque où j'ai fait un peu de C++, c'était vraiment super au niveau autocomplétion ou refactoring. L'interface est efficace, on la trouve un peu rigide au début et on se rend compte que c'est bien pensé après.
En ressources CPU c'était aussi très bien, et plus réactif que VIM avec youcompleteme.
Par contre c'était très dépendant de cmake, je ne sais pas si ça s'est amélioré depuis?

Blague à part, les opérateurs cherchent à s'accaparer quelques plages de fréquences en plus pour la 5G dont certaines vont dégrader le signal GPS et de radars météo.

Puisque tu as demandé des arguments de ceux qui ne sont pas d'accord, voici les miens:

• Tu prétends que la procédure pour voter est plus simple, mais mon expérience (confirmée par plusieurs autres commentaires) est que la procédure en ligne est plutôt compliquée pour des non-informaticiens. En comparaison, pour avoir une action il suffit d'en toucher un mot à ton banquier quand tu passes le voir et il fera le nécessaire sur ton PEA.
• Pour les personnes sans internet, donc notamment un grand nombre de retraités, c'est très compliqué: il faut récupérer un formulaire (disponible sur … internet, sauf que le lien sur le site du RIC est mort donc il faut chercher ailleurs avec le numéro de cerfa), ensuite aller dans le chef lieu du canton qui est facilement à 30 bornes en province (pour savoir lequel, il faut aussi chercher sur internet) et trouver un fonctionnaire qui saura quoi faire du papier.
• Sur les 500 000 investisseurs particuliers, je me demande si une partie n'est pas due aux placements pilotés gérés par la banque?
• Ça a déjà été évoqué, la couverture médiatique quasi-nulle a limité la participation. Je comprends ceux qui rejettent la possibilité de payer des spot publicitaire pour l'annoncer, mais les médias du service publique auraient du assurer l'annonce. La plupart des personnes avec qui j'ai parlé du RIC n'étaient pas du tout au courant, ou bien avaient eu si peu de détails qu'ils n'y ont pas prêté attention, pensant qu'il s'agissait d'une simple pétition.

Il y a aussi une base qui semble assez fournie ici: http://www.radio-browser.info/webservice
En plus il y a une api publique pour faire des requêtes.

En fait je viens de regarder https://linuxfr.org/forums/general-petites-annonces/posts/emploi-embauche-developpeurs-linux-kernel-pourvu#comment-1622396 mais ce n'est pas super clair, il faudrait préciser que le salaire doit faire partie des annonces (dans le wiki?).

En quoi est-ce mal? Le OOM killer n'est pas particulièrement prédictible et je me suis déjà retrouvé avec une machine qui freeze à cause d'une fuite mémoire dans un de mes scripts.
Pour une machine distante j'ai décidé de désactiver l'overcommit, au moins le script incriminé plante tout de suite. Mais si tu as une meilleure idée je suis preneur.

Merci d'avoir pris le temps de répondre. J'avais bien sûr forcé le trait car c'était vendredi.
Les crashs sont au moins présents sur les versions des dépôts archlinux, peut-être qu'on essuie les plâtres avant les autres?
L'interface est franchement un point faible, il faut beaucoup de clics pour accéder aux fonctions et les retours de novices ne sont pas positifs. Avec de l'expérience on n'y pense plus, mais pour un usage ponctuel c'est inférieur à office ou onlyoffice. Tu me répondra sans doute que je me suis juste adapté à la concurrence, mais je me souviens du passage à l'interface d'office 2007 qui était toute nouvelle à l'époque et pourtant tout tombait sous la main.
Pour la différence de positionnement, il faudra voir si elle ne réduit pas avec l'ajout de fonctionnalités dans OnlyOffice.

Et chaque mois, le même commentaire qui revient. Je comprends que tu sois déçu d'avoir investi du temps sur LO, mais je trouve que ta critique est de mauvaise foi.

Il y a un autre point de vue possible sur le sujet: ça fait des dizaines d'années que libreoffice est incapable d'ouvrir et d'éditer correctement les fichiers du standard de facto, l'interface est bancale et contre-productive, les bugs/crashs omniprésents (heureusement que le module de récupération fonctionne bien au moins) et les performances s'effondrent quand un document gagne en complexité.

En quelques mois, onlyoffice a énormément progressé (d'où les articles réguliers), à tel point que certains préfèrent déjà l'utiliser plutôt que LO. Le projet avance à grand pas, possède un fort potentiel et (c'est trolldi tout est permis) il serait peut-être plus productif de rediriger l'effort de contribution vers ce projet plutôt que vers Libreoffice qui traîne une lourde dette technologique.

Certes le format de stockage n'est pas un chef d’œuvre d’ingénierie, mais OnlyOffice prouve qu'on peut quand même se débrouiller avec. En informatique comme ailleurs, les standards ne suivent pas la raison.

J'ai eu la même expérience, j'ai essayé d'autres éditeurs mais aucun ne propose le même niveau de fonctionnalités ni la même qualité d'intégration ou des performances.

Pour des politiciens qui voient à court terme, une vente aux enchère c'est plus intéressant qu'une rente plus régulière comme de la location. Et une compagnie investira beaucoup moins si elle a un risque de guerre commerciale derrière.

Les chantres du libéralisme n'iront peut-être pas jusque là, enfin j'espère. Je pense que l'on risque d'abord d'avoir un système de concession par ligne comme pour les autoroutes ou les trains au Royaume-Uni. Et sans doute une interface unique pour les billets, comme c'est déjà le cas pour les compagnies de bus en région parisienne, qui sont privatisées.

J'aime le style de github. Certes, c'est un peu lent, mais toutes les fonctions utiles tombent sous la main. C'est simple, clair et direct. La plupart des variantes ne font que compliquer les choses.

Je ne comprend pas ce qui te déplaît dans les pull request (ou était-ce un troll bien déguisé?): ça s'intègre bien avec git, avec le processus de revue de code, avec les tests automatiques, et ça permet de travailler de manière incrémentale en suivant les évolutions de la branche principale si jamais l'intégration prend du temps.
En fait, c'est juste un coup de main à prendre: tu peux par exemple toujours suggérer un patch, mais dans un rapport de bug: c'est équivalent à un mail sur la mailing list sauf qu'il y a un suivi ouvert/clôturé en plus.

Et c'est plus facile de naviguer/rechercher/filter dans les pages de bugs, pull requests que dans une mailing list.

Le principal défaut amha, c'est le côté facebook avec la nécessité d'avoir un compte pour contribuer, gitlab ou atlassian sont plus flexibles de ce point de vue.

Merci beaucoup pour ces explications. Elle m'ont permis d'avancer.
L'authentification fonctionne et pour l'instant je passe simplement les identifiants et mots de passe via les arguments -D et -w des commandes ldap*.

Si j'ai bien compris, l'important est de donner l'accès en recherche à tout et l'accès en lecture à objectClass, entry et aux attributs souhaités

J'ai désormais la configuration suivante:

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: to attrs=userPassword,shadowLastChange
  by self write
  by anonymous auth
olcAccess: to attrs=entry,objectClass,uid
  by dn.base="cn=nslcd,ou=Services,dc=example,dc=org" read
  by dn.base="cn=postfix,ou=Services,dc=example,dc=org" read
  by dn.base="cn=dovecot,ou=Services,dc=example,dc=org" read
olcAccess: to attrs=uidNumber,cn,gecos,homeDirectory,gidNumber,loginShell
  by dn.base="cn=nslcd,ou=Services,dc=example,dc=fr" read
olcAccess: to *
  by self read
  by * search

Oui c'est très juste, je crois que ça date d'une version antérieure du code où des définitions multiples d'un même raccourci étaient possible et j'utilisais une liste de tuples pour les stocker.

Tu aurais du lire de quel démon il s'agit. Vu l'application, le mien passe 99,999% (au pifomètre) du temps bloqué sur l'appel système qui attend un retour de la part d'evdev.
J'aime le code optimisé, mais je n'optimise que les parties critiques pour lesquelles cette optimisation a une réelle utilité.

Très juste, le groupe input suffit et je pourrais donc modifier le service systemd pour lancer le démon avec des droits plus restreints. Si je n'ai pas trop la flemme je regarderai aussi du côté des capabilities, que l'on peut là aussi gérer via systemd il me semble.

Avec un brin de soudure, tu peux aussi utiliser des cartes d'extension. Par contre, si tu optes pour cette méthode, je ne recommande pas trop la hifiberry dac+, j'ai pas été impressionné par la qualité du son.
Pour la puissance, je rejoins ce qui est dit au dessus: le son consomme peu de ressources.