Anonyme a écrit 62265 commentaires

c'est le premier article que j'ai trouvé où le bonhomme s'est exprimé sur le sujet.

ca me fait néanmoins un peu bizarre d'être sommé de mentionner le biais idéologique d'une source d'information qui traite pertinemment du sujet en question.

encore aurait-il fallu que je le sachiasse :(

Voici un article avec la réponse du dev principal [en anglais] qui explicite la chose.

Techniquement je ne saurai le dire.

Mais, l'un deux accepte les contributions externes et pas l'autre.
Et si jamais quelqu'un souhaite participer à sqlite, ce qui signifie, si j'ai bien tout compris, être embauché par la société qui le développe, alors cette personne doit s'engager à respecter un code d'éthique qui exclut une majorité de la population mondiale.

10. Deny oneself in order to follow Christ. 

l'alternative restant bien évidemment le fork.

bref avec sqlite tu as le choix entre la croix et la fourchette :)

tout pareil, que ce soit sur serveur ou desktop, j'utilise une debian sans systemd avec sysvinit-core.
J'ai juste ajouté ceci à /etc/apt/preferences/systemd:

Package: systemd-sysv
Pin: origin *
Pin-Priority: -100

Package: systemd
Pin: origin *
Pin-Priority:-100

pour éviter une réinstallation de systemd lorsque, par hasard et très rarement, certains paquets l'ont en dépendance obligatoire. Dans ce cas, je me débrouille pour faire trouver une alternative à ces paquets.

pour suspendre le processus en cours et revenir à bash: Ctrl-z
pour réactiver le processus suspendu et le passer en arrière plan: bg au prompt bash
pour réactiver le processus suspendu et reprendre la main dessus: fg au prompt bash

dans about:config, browser.tabs.firefox-view = false

On a un projet sous licence libre et des appellations non protégées qui donnent lieu à une utilisation des libertés proclamées par la licence. Donc personne ne peut se plaindre.
Par contre, si Steam a mis en place des processus qui auraient pu empêcher cette possibilité, ils n'ont pas été efficaces.

et moi j'ai oublié de mettre le bon drapeau pour le lien ! Merci à l'équipe de modération pour la correction à venir

Il y a quelqu'un chez google qui a oublié de renouveler le virement annuel vers le Texas…

c'est tellement bien résumé, c'est vrmt devenu ça la répartition par tranche d'age de ces réseaux (as)sociaux.

Et pour les gamins faits des shorts snapchat.

Il me semble que le fait d'intégrer une passerelle à un serveur XMPP ne va pas dans le sens d'une philosophie KISS. Quel est l'intérêt de cette intégration par rapport à la mise en place d'une passerelle externe ?

ca confirme le problème d'intégration dans debian testing

donc ca semble être un problème d'intégration chez debian

Comme indiqué dans mon message, j'ai déjà parcouru tous ces liens qui ne permettent pas de réaliser une signature numérique d'un document libreoffice via une clé gérée par gnupg.

Il s'agit bien de signer, et non de chiffrer, et je n'utilise pas snap mais la version distribuée par debian testing.

Seahorse est un front end à gnupg, mais ce qui semble me manquer c'est un gestionnaire de certificat qui puisse interagir avec libreoffice.
J'ai installé seahorse et sa dépendence gnome-keyring qui me semble être le gestionnaire de certificat manquant.
Seahorse est alors ouvert par le bouton "start certificate manager" mais il est incapable d'importer les clés de gnupg:

• si je sélectionne le fichier .gnupg/secring.gpg pour l'importation, il génère une erreur en tentant de créer /home/user/~/.gnupg
• si je sélectionne le fichier .gnupg/migrate-from-classic-backup/pubring.gpg qui est l'ancien format géré par gnupg v1, seahorse se bloque et doit être killé

Manifestement je me suis trompé, toutes mes excuses pour cet accueil.
J'espère que cela ne te refroidira pas pour écrire journaux et dépêches sur les CMS puisque c'est un sujet que tu maîtrises.

https://be.linkedin.com/in/eric-moreau-webstanz

Nouveau compte, placement de lien pour référencement, mais bon ca parle de logiciels libres.
Personnellement, je n'aime pas la manière, mais laissons l'équipe de modération trancher.

J'utilise l'extension Stylus avec le style Global Dark Mode.

Je n'ai réussi à trouver la raison du problème, mais il se trouve qu'après avoir limité la configuration de /etc/asound.conf à l'utilisation de la sortie HDMI, tout est rentré dans l'ordre.
Il semble qu'alsa prenne désormais en charge automatiquement dmix, ce qui n'était pas le cas lors de la configuration initiale de ma machine et m'avait donc amené à modifier /etc/asound.conf.

Et il se passe quoi quand connman est installé en même temps que netwok-manager ?
Et beh ils se battent pour savoir qui aura droit de gérer la connexion, du coup ça se déconnecte tout le temps !
Rien à voir avec le firmware, une fois de plus le problème se situait entre la chaise et le clavier…

c'est mieux: avec la version du firmware fournie par ubuntu 20.04 j'ai des déconnexions toujours aussi régulières, mais qui sont reconnectées automatiquement deux secondes après.
Par contre, comme avec le firmware fournit par debian, si j'ai un stream en cours de lecture ou une connexion tor en cours d'utilisation, celles-ci doivent être réinitialisées.
Attention, Ubuntu 22.04 fournit le même fichier que debian testing.

ce qui m'étonne c'est que le même firmware que debian sous fedora ne pose pas de problème.
Je continue mes investigations, mais j'ai déjà amélioré mon confort d'utilisation grâce à toi :)

Et pile au moment de valider ce commentaire, une déconnexion qui a nécessité un coup de disconnect/connect via connmanctl… soyons positif, c'est tout de même mieux !

merci !
la seule différence que j'ai par rapport à toi c'est la version de firmware:
firmware=36.ca7b901d.0

je ne sais pas à quoi correspond la deuxième partie après le 36, peut être un id de commit, auquel cas je vais récupérer celui de ubuntu et voir si cela change quelque chose.

non j'avais déjà regardé, il s'agit également de la version 36 du firmware iwlwifi-8000C

bon et bien il n'aura pas fallu longtemps: le kernel 5.17.3 installé, redémarrage, connexion, 5min après déconnexion !
J'imagine donc qu'il y a un problème chez debian que je vais remonter via un rapport de bug

merci à tous pour vos idées

Après plus d'une demi-heure sous Fedora Workstation Live 36 1.5, sans aucune déconnexion, je dois donc en conclure que le problème vient soit d'une mauvaise configuration dans debian testing soit d'une régression dans la version 5.18.
la première différence est le noyau: 5.17 pour fedora contre 5.18 chez debian
Je vais donc trouver un paquet 5.17 sur snapshot.debian.org et tester cela.

La suite au prochain numéro