jihele a écrit 961 commentaires

  • [^] # Re: Chrome is the new IE?

    Posté par . En réponse au journal Microsoft serait en train de développer un navigateur web basé sur Chromium. Évalué à 4 (+2/-0). Dernière modification le 04/12/18 à 10:08.

    Les critiques de Chrome concernant le respect de la vie privée s'appliquent-elles à Chromium?

  • [^] # Re: Décorer ses ennemis ?

    Posté par . En réponse au lien Un développeur du logiciel VLC et un hacker français nommés chevaliers de l'Ordre du Mérite. Évalué à 5 (+3/-0).

    Détrompe-toi, le logiciel libre est un sanctuaire où l'on voit manifestants et police s'entraider en laissant de côté leurs différents.

    VLC

    Sur le fond, je suis assez d'accord avec toi qu'il y a parfois une belle hypocrisie. Les décorés n'en ont que plus de mérite.

  • [^] # Re: Retour d'expérience sauvegarde rsync

    Posté par . En réponse au journal Timeshift, l'outil de sauvegarde de Linux Mint 19 : oui mais attention. Évalué à 2 (+0/-0).

    J'ai aussi un disque dur externe USB sur lequel je fais une sauvegarde manuelle hebdomadaire. Je le conserve au bureau.

    Il faut pas que la maison brûle le soir où je le ramène pour la sauvegarde…

  • [^] # Re: Retour d'expérience sauvegarde rsync

    Posté par . En réponse au journal Timeshift, l'outil de sauvegarde de Linux Mint 19 : oui mais attention. Évalué à 2 (+0/-0).

    SpaceFox parle de sauvegarde incrémentale, donc oui, je pense que c'est pour l'historique.

    Pour l'historique des installations/désinstallations, j'utilise etckeeper qui versionne /etc avec git. Et apt-clone pour conserver la liste des paquets installés. J'ai jamais utilisé apt-clone pour réparer, mais la sauvegarde de /etc c'est vraiment pas mal. En tout cas pour du serveur et pour un utilisateur technique.

  • [^] # Re: ionice

    Posté par . En réponse au journal Timeshift, l'outil de sauvegarde de Linux Mint 19 : oui mais attention. Évalué à 3 (+1/-0).

    Je voulais dire que les devs pourraient le faire, pas Mme Michu.

  • # ionice

    Posté par . En réponse au journal Timeshift, l'outil de sauvegarde de Linux Mint 19 : oui mais attention. Évalué à 3 (+1/-0). Dernière modification le 15/11/18 à 11:00.

    Il y aurait pas moyen dans Mint d'utiliser ionice pour minimiser la priorité de la sauvegarde et pas plomber les autres tâches ?

  • # Retour d'expérience sauvegarde rsync

    Posté par . En réponse au journal Timeshift, l'outil de sauvegarde de Linux Mint 19 : oui mais attention. Évalué à 2 (+0/-0).

    Je fais tous les jours à 21h une sauvegarde rsync depuis mon disque principal (2 disques en RAID miroir) vers un autre disque interne. Ce ne sont pas des SSD. Et ma machine date pas d'hier.

    Ce n'est pas une sauvegarde incrémentale, juste une synchro.

    J'ai jamais constaté d'impact. Mais peut-être que je fais jamais de choses coûteuses à ce moment-là (à part la MAO, je fais rien qui coûte, et je dois faire ça plus tard, probablement…).

  • [^] # Re: Comment ça marche ?

    Posté par . En réponse au journal SSPL: All your service are belong to us. Évalué à 5 (+3/-0).

    Je vois des interprétations contradictoires

    https://devclass.com/2018/10/17/mongodb-new-license-cloud-service-providers/

    Under the GPL, anyone offering the software as a service would have to make the source code available for download. The new terms expand that, requiring them to make the ‘Service Source Code’ available. This means not just the source code for the software, but also the source code for any other software used to serve it from the cloud. This includes “management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available,” the SSPL says.

    Ça n'impacterait que les logiciels liés à l'exploitation de la DB…

    The license won’t apply […] to SaaS companies using it as the basis for their services, the company added.

    mais pas le code métier.

    https://techcrunch.com/2018/10/16/mongodb-switches-up-its-open-source-license/

    For virtually all regular users who are currently using the community server, nothing changes because the changes to the license don’t apply to them. Instead, this is about what MongoDB sees as the misuse of the AGPLv3 license. “MongoDB was previously licensed under the GNU AGPLv3, which meant companies who wanted to run MongoDB as a publicly available service had to open source their software or obtain a commercial license from MongoDB,” the company explains. “However, MongoDB’s popularity has led some organizations to test the boundaries of the GNU AGPLv3.”

    Ici aussi, je comprends que c'est destiné aux boîtes qui fournissent du Mongo DB en cloud, pas des applis basées sur Mongo DB.

  • [^] # Re: Comment ça marche ?

    Posté par . En réponse au journal SSPL: All your service are belong to us. Évalué à 6 (+4/-0).

    The only substantive change is an explicit condition that any organization attempting to exploit MongoDB as a service must open source the software that it uses to offer such service.

    Ce que je comprends de cette phrase c'est que si je développe une appli web à base de MongoDB, je dois la publier sous licence SSPL.

    Ça me parait assez gros. On développe une appli web propriétaire pour laquelle on a investi beaucoup de temps dans le développement de couches libres, notamment ODM Mongo Python, et je trouvais le deal assez correct.

    Ce modèle me paraît pas mal. On est nombreux à codévelopper des libs Python pour faire de l'API REST et je pense que la plupart des contributeurs développent une appli proprio, mais on essaye de partager le plus possible les bases pour ne conserver que le métier dans le code spécifique à l'appli.

    Je ne pense pas qu'on puisse revenir sur le caractère proprio d'une appli comme ça, c'est tout son modèle économique qui est impacté, donc de trois choses l'une

    • soit j'interprète mal l'annonce
    • soit un fork fiable va sortir (mais c'est pas moi qui vais le porter)
    • soit tout ♬ le monde doit changer de base ♬ (<- désolé, pas pu résister)
  • [^] # Re: Lien vers le CVE

    Posté par . En réponse au journal demain soir on finit tard. Évalué à 8 (+6/-0). Dernière modification le 17/10/18 à 10:05.

    >=1.9.0 and <2.3, c'est les versions de python-cryptography, pas celles de libssh.

    https://tracker.debian.org/pkg/libssh

    stable: 0.7.3-2
    stable-bpo: 0.8.1-1~bpo9+1
    testing: 0.8.1-1
    unstable: 0.8.4-2

    Pour le reste, j'ai les mêmes interrogations.

    Quant à python-cryptography, on dirait bien que Debian est passée entre les gouttes :

    https://tracker.debian.org/pkg/python-cryptography

    stable: 1.7.1-3
    testing: 2.3-1
    unstable: 2.3-1

  • # Pas de version patchée dans Debian Security?

    Posté par . En réponse au journal demain soir on finit tard. Évalué à 2 (+0/-0).

    0.8.4 & 0.7.6 sont disponibles dans toutes les bonnes crèmeries.

    Dans Debian, pas de 0.7.6 et 0.8.4 attendra 5 jours comme tout le monde.

    https://tracker.debian.org/pkg/libssh
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911149

    Ça devrait pas passer dans stable-security, ça ?

  • [^] # Re: NextCloud

    Posté par . En réponse au message Envoyer/recevoir des messages Facebook par courriel. Évalué à 2 (+0/-0).

    J'en parle au-dessus. Je l'aurais peut-être déjà installé si c'était dans les dépôts Debian officiels. J'en aurais pas une grosse utilisation, donc je veux pas m'embêter avec la maintenance, sinon ça vaut pas la coup.

    Et d'après ce que j'ai lu, c'est pas demain la veille. Même le client n'est pas dans les dépôts, contrairement au client owncloud.

  • [^] # Re: Les avantages du groupe de discussion sans les inconvénients FB

    Posté par . En réponse au message Envoyer/recevoir des messages Facebook par courriel. Évalué à 2 (+0/-0).

    Oui, SSH irait bien pour mon cas. C'est intégré à mon gestionnaire de fichiers (avec gvfs, je pense).

    Mais je pense pas que les autres OS fournissent cette facilité.

    Et puis pour certaines utilisations, c'est mieux avec des utilisateurs virtuels. Ça serait peut-être faisable avec un système à la gitolite (un utilisateur système, plein de clés SSH), mais là, il faut une bonne couche d'enrobage pour que Mme Michu n'y voit que du feu.

  • [^] # Re: Les avantages du groupe de discussion sans les inconvénients FB

    Posté par . En réponse au message Envoyer/recevoir des messages Facebook par courriel. Évalué à 2 (+0/-0).

    Mouarf, ça serait pas un cadeau pour FB, mais bon, je suis d'accord avec toi. Je crois pas qu'on le fasse, ça a été juste évoqué.

    Avec son ancien groupe, le batteur utilisait Dropbox…

    J'héberge mes morceaux sur mon serveur, mais j'ai pas d'interface pratique à proposer. FTP, c'est sans doute un gros mot, pour eux.

    Je serais bien tenté de mettre un Nextcloud si c'était packagé Debian, quitte à acheter qqs Go de stockage en plus, mais j'ai pas envie de gérer install et surtout maintenance hors APT. Peut-être que je pourrais mettre un truc plus simple avec gestion de droits ultra-simpliste, juste une interface web mono-compte pour exposer un répertoire partagé. Mais bon, il y a pas le confort du client intégré au gestionnaire de fichiers…

    Bref, c'est un autre sujet. Mais merci pour ta vigilance.

  • [^] # Re: Les avantages du groupe de discussion sans les inconvénients FB

    Posté par . En réponse au message Envoyer/recevoir des messages Facebook par courriel. Évalué à 2 (+0/-0).

    Merci pour ces infos.

    Il s'agit d'un groupe de musique qu'on est en train de monter.

    Je crois qu'ils ont évoqué l'idée de se servir de l'espace de stockage qui va avec le groupe FB pour mettre les compos, mais c'est une autre histoire. Sorti de ça, l'idée n'est pas d'avoir une page, publique ou pas, et un historique, mais juste d'échanger des messages d'orga: on se voit tel jour, tiens écoutez, j'ai mis un nouvel enregistrement.

    Ils utilisent ça sur leur téléphone, et il y a peut-être une confusion avec le FB Messenger, c'est pas clair. Je vais clarifier ça avec eux.

    Si je comprends bien ton message, je pourrais recevoir des notifications. Si en plus les notifications incluent le contenu du message, c'est pas si pire, sinon il faut se connecter, c'est pénible. Et si en plus je peux répondre en écrivant à une adresse, ça va. Ça va juste bousiller le threading, mais bon… je plaiderai non coupable. Fallait choisir un autre outil.

    En fait je cherche à la fois une solution technique pour m'adapter et des arguments techniques (autres que de principe) pour refuser FB. Si c'est inutilisable pour moi parce que pas de mobile et pas pratique du tout parce que pas d'autre utilisation de FB, c'est un bon argument technique, déjà.

  • [^] # Re: Les avantages du groupe de discussion sans les inconvénients FB

    Posté par . En réponse au message Envoyer/recevoir des messages Facebook par courriel. Évalué à 10 (+8/-0).

    Je suis d'accord sur le fond, confidentialité et tout. Mais j'ai affaire à des gens qui s'en branlent et je peux faire avec, dans la mesure où c'est cloisonné (discussion limitées au sujet lié à ce seul groupe).

    Techniquement, je trouve ça délirant qu'on se retrouve à imposer à quelqu'un (moi) de passer par une solution technique régressive (FB) là où le courriel fait bien le boulot. Eux ils trouvent ça pratique parce que j'imagine que l'appli FB sur leur téléphone est pratique et le client mail doit être un peu pourri, je sais pas. Je comprends même pas comment ils peuvent être branques au point de pas savoir écrire un courriel et devoir passer par FB pour se parler. Ça me dépasse. M'imposer de devoir ouvrir FB ou installer un client exprès, c'est n'importe quoi. Ne serait-ce que techniquement. Je vais pas passer ma journée à regarder une page FB pour voir si on m'a écrit.

    Si j'arrive en proposant une autre solution technique qui nécessite l'installation d'un client dédié (ou la consultation d'un site dédié), je me mets un peu dans la même posture qu'eux, question confidentialité / ouverture mise à part, je leur impose une nouvelle source. Et ça m'arrange pas non plus. Techniquement, faire du polling sur une page FB ou une page Mattermost ça m'emmerde dans les deux cas. Même si je pense que Mattermost fait au moins les notifications par mail et peut-être même possibilité d'utiliser que par courriel, je sais pas.

    Bref, la solution alternative à FB qui protège nos échanges on l'a déjà c'est le courriel (même si avec leurs adresses gmail et live, la confidentialité, bof… mais bon), c'est juste que pour décrocher les gens de FB, c'est la croix la bannière et comme je suis pas en position d'imposer autre chose je cherche une façon de m'interfacer avec eux sans passer pour le boulet.

    On est bien d'accord que c'est eux qui ont tort…

  • # Journal traitant de la même info

    Posté par . En réponse au lien L'état chinois suspecté d'avoir introduit des puces espionnes dans le design de matériel. Évalué à 3 (+1/-0).

  • [^] # Re: Tu aimes vivre dangereusement

    Posté par . En réponse au journal [Écriture] Inktober 2018 libre (mais pas en dessins). Évalué à 10 (+9/-1). Dernière modification le 03/10/18 à 10:06.

    Logiciel libre et art libre, c'est pas tout à fait pareil, quand-même. Vaste débat.

    En tout cas, dans les commentaires, Boulet et Pop affichent de la perplexité mais je ne les vois pas péter les plombs. La conversation est plutôt cordiale.

    Merci quand-même pour les liens.

  • [^] # Re: HS sur RGPD

    Posté par . En réponse à la dépêche Appel à propositions pour la conférence PyParis de novembre 2018. Évalué à 2 (+0/-0).

    Je pense qu'il se demandait comment ils avaient eu son adresse. L'infraction au RGPD serait dans l'obtention de l'adresse, pas dans son utilisation.

  • [^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?

    Posté par . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 6 (+4/-0).

    Je ne comprends pas trop.

    Dans git, quand tu intègre une branche dans ta branche principale, tu as un commit de merge (toujours s'il y a un merge, ou optionnellement si c'est du fast-forward) mais tu récupères aussi dans l'historique les commits de la branche de dev, donc tu as rien perdu et tu peux supprimer la branche de dev car elle ne comporte aucune info supplémentaire.

    Concrètement, le commit de merge est juste un commit qui a deux parents : le dernier commit de la branche master et celui de la branche de dev. Donc on peut remonter tous les commits de la branch de dev. Et si on veut pas se trimballer plein de commits temporaires dans master, on peut squasher les commits de la branch de dev avant intégration, mais on aura au moins un commit de dev avec une trace écrite.

    Du coup, vous avez juste :
    - le commit qui dit "merge de la fiche XXX-1234 dans le tronc principal"
    - votre bug tracker qui indique le nom de la personne assignée au bug, mais sans certitude que ce soit bien elle qui ait produit le code
    - perdu le détail des itérations du code

    Ben non, vous avez le commit de merge et au moins un commit de dev qui indique qui a codé et vous conservez les itérations que vous voulez (squash ou pas).

  • [^] # Re: Merci !

    Posté par . En réponse à la dépêche Sortie de Python 3.7. Évalué à 3.

    Je ne suis pas familier des annotations, donc je sais pas si la pratique consiste à écrire

        -> None

    ou juste ne rien écrire du tout. Mais en tout cas, ça ne renvoie pas un int.

    C'est un détail, hein…

    Mais ça m'a incité à aller regarder quelle était la syntaxe des annotations, donc c'est bien.

  • # Merci !

    Posté par . En réponse à la dépêche Sortie de Python 3.7. Évalué à 3.

    Merci pour la dépêche. J'utilise encore 3.5 (Debian stable inside) donc j'ai suivi de loin l'arrivée de 3.7 et je n'ai pas participé à la dépêche, mais j'ai pris plaisir à la lire.

    En plus les retours sur les versions antérieures me permettent de découvrir des choses qui me sont accessibles mais que je ne connaissais pas.

    Dans l'exemple des dataclasses, je pense que la valeur de retour indiquée par l'annotation est trompeuse (honte à moi, j'aurai du participer à la rédaction plutôt que le signaler après publication):

            def tax(self, val) -> int:
                self.value -= val
  • [^] # Re: Sauvegardes

    Posté par . En réponse au message Quelles précautions pour ne pas réinstaller tous le système linux en cas de panne. Évalué à 2.

    Ça répond à la première partie de la question

    que je dois faire pour ne pas perdre mes données en cas de panne

  • [^] # Re: NeoVim ?

    Posté par . En réponse au journal vim: Au revoir syntastic, bonjour ALE. Évalué à 3.

    Je connais pas NeoVim. Je crois comprendre que c'est "vim en mieux" mais j'ai jamais pris le temps d'essayer.

    Je suis pas sûr de comprendre. Tu veux dire que NeoVim exécute les plugins synchrones de façon asynchrone ? syntastic est synchrone, c'est pas la faute de vim. (voir. https://github.com/vim-syntastic/syntastic/issues/1370#issuecomment-372807959)

    A vrai dire, pour l'instant, ALE me va bien, je suis pas plus attaché que ça à syntastic.

  • # Merci

    Posté par . En réponse à la dépêche Présentation de The Log File Navigator. Évalué à 7.

    Merci pour l'info.

    Sur de gros fichiers, c'est assez long à charger, là où vi est instantané.