nlgranger a écrit 270 commentaires

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.

D'après https://askubuntu.com/a/768194 le pilote est à moitié supporté par linux au lieu de pas du tout auparavant :-).

Du coup tu dois lancer les commandes suivantes dans un terminal:

if [[ ! $(mount | grep /sys/firmware/efi/efivars) ]]; then sudo mount -t efivars efivars /sys/firmware/efi/efivars; fi
sudo cp /sys/firmware/efi/efivars/nvram-74b00bd9-805a-4d61-b51f-43268123d113 /lib/firmware/brcm/brcmfmac43340-sdio.txt
echo "blacklist btsdio" | sudo tee -a /etc/modprobe.d/blacklist-btsdio.conf

Mais je n'ai pas testé moi-même.

Durant mon court séjour là-bas, c'était assez aléatoire et les connections finissent souvent par être filtrées. De plus j'ai lu que les autorités ont décidé d'être beaucoup moins laxistes depuis quelques temps.

This is just a prototype right now

Cool, encore une fonctionnalité de Xorg qui a a été abandonnée/oubliée et qui a mis 10 ans à revenir dans Wayland sous la forme d'un projet expérimental pas officiellement supporté et non standard.

Je ne critique pas ce projet en particulier, qui rendra bien service si il parvient à maturité, mais je trouve aberrante la situation de Wayland qui est mal défini, mal organisé, et ne prend pas en compte une foultitude d'usages.

J'ai rien compris à tes explications, ni sur ce que tu cherches à faire, ni sur le problème.

Cependant, je me permets de te rappeler que python remplit les listes avec des références des objets qu'on lui donne. Du coup je trouve bizarre d'ajouter zbis à la liste, de le modifier et de le rajouter à nouveau à chaque itération. Tous les éléments de result pointent vers le même objet. Tu devrais pas créer un nouvel np.array à chaque fois?

Tu fais une veille régulière pour trouver ce genre de contenu?

Tu lances gnome avec GDM? Si il y a des soucis de permissions (polkit & co je crois), l'utilisateur n'a peut-être pas le droit d'éteindre l'ordinateur, auquel cas le bouton éteindre n’apparaît pas.

J'avais commencé par utiliser RawTherapee, ensuite lightroom dont l'interface/expérience utilisateur est franchement très chouette. En comparaison, le premier est assez pénible avec des curseurs difficiles à positionner et des intervalles de valeur bien trop large.
Darktable est ce qui s'en rapproche le plus, il y a même la possibilité de travailler par masques, de naviguer dans l'historique des opérations, et il y a des tutos assez poussés sur internet.

Ce n'est pas destiné pour des pré-prints. C'est un effort pour aider les chercheurs à valoriser le travail de développement logiciel jusqu'ici largement éclipsé dans un contexte où la qualité des chercheurs est mesurée par leurs publications. Le fait que les articles de joss soient revus par les pairs donne la possibilité de citer ces travaux dans des publications (certains conférences n'acceptent pas de citer des pré-publications/rapports techniques).

Il n'y a pas si longtemps, il y a eu un journal sur le Odroid-H2 avec un quad-core J4105 qui pourrait sans doute correspondre à tes attentes: https://www.hardkernel.com/shop/odroid-h2/
Je ne l'ai pas testé par contre.
Je ne recommande rien en ARM car les seuls SoCs avec des vrais contrôleurs sata (pas usb->sata) sont les vieillissants A20.

Si tu mets tes données en ligne, peut-être que l'on pourra jouer avec.

Autrement, en petite dimension tu peux essayer de visualiser tes données (ACP ou tsne) et tester des algorithmes plus simples pour commencer.
Peut-être des arbres de décisions seraient plus adaptés si il y a des effets de seuil dans la décote?