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.
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.
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)
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.
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.
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.
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à.
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.
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.
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).
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):
Je trouve aussi bizarre le menu en haut à gauche qui est décalé vers le bas.
J'ai rechargé la page en pensant que c'était un défaut de chargement.
C'est assez habituel (cf. MediaWiki, par exemple) le logo en haut à gauche qui est cliquable et renvoie à l'accueil.
Et esthétiquement, ça fait bizarre.
Si c'est juste pour rendre plus clair le fait que c'est une dépêche sélectionnée, alors autant l'écrire explicitement, ça devrait suffire, ou mettre un cadre spécial.
On l'utilise pour Marshmallow (https://opencollective.com/marshmallow). C'est pas moi qui ai choisi, j'ai pas cherché, j'ai pas benchmarké, donc je peux pas commenter.
J'utilisais Xfce et maintenant Mate pour les mêmes raisons et je comprends les limitations dont il parle. Devoir bricoler (et pas toujours avec succès) pour éviter le tearing sur les vidéos, ajouter des partages samba, rechercher des fichiers, modifier les sorties écran, etc., c'est pas top.
[^] # Re: Comment ça marche ?
Posté par jihele . En réponse au journal SSPL: All your service are belong to us. Évalué à 5.
Je vois des interprétations contradictoires
https://devclass.com/2018/10/17/mongodb-new-license-cloud-service-providers/
Ça n'impacterait que les logiciels liés à l'exploitation de la DB…
mais pas le code métier.
https://techcrunch.com/2018/10/16/mongodb-switches-up-its-open-source-license/
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 jihele . En réponse au journal SSPL: All your service are belong to us. Évalué à 6.
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
[^] # Re: Lien vers le CVE
Posté par jihele . En réponse au journal demain soir on finit tard. Évalué à 8. Dernière modification le 17 octobre 2018 à 10:05.
>=1.9.0and<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 jihele . En réponse au journal demain soir on finit tard. Évalué à 2.
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 jihele . En réponse au message Envoyer/recevoir des messages Facebook par courriel. Évalué à 2.
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 jihele . En réponse au message Envoyer/recevoir des messages Facebook par courriel. Évalué à 2.
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 jihele . En réponse au message Envoyer/recevoir des messages Facebook par courriel. Évalué à 2.
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 jihele . En réponse au message Envoyer/recevoir des messages Facebook par courriel. Évalué à 2.
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 jihele . En réponse au message Envoyer/recevoir des messages Facebook par courriel. Évalué à 10.
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 jihele . En réponse au lien L'état chinois suspecté d'avoir introduit des puces espionnes dans le design de matériel. Évalué à 3.
https://linuxfr.org/users/regis/journaux/des-puces-espionnes-installees-sur-des-cartes-meres-par-les-chinois
[^] # Re: Tu aimes vivre dangereusement
Posté par jihele . En réponse au journal [Écriture] Inktober 2018 libre (mais pas en dessins). Évalué à 10. Dernière modification le 03 octobre 2018 à 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 jihele . En réponse à la dépêche Appel à propositions pour la conférence PyParis de novembre 2018. Évalué à 2.
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 jihele . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 6.
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.
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 jihele . 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
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 jihele . 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):
[^] # Re: Sauvegardes
Posté par jihele . 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
[^] # Re: NeoVim ?
Posté par jihele . 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 jihele . 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é.
[^] # Re: Menu de gauche plus difficile d'accès sur la page d'accueil > icône du tableau de bord
Posté par jihele . En réponse à la dépêche Quelques petits changements sur le site. Évalué à 5.
Je trouve aussi bizarre le menu en haut à gauche qui est décalé vers le bas.
J'ai rechargé la page en pensant que c'était un défaut de chargement.
C'est assez habituel (cf. MediaWiki, par exemple) le logo en haut à gauche qui est cliquable et renvoie à l'accueil.
Et esthétiquement, ça fait bizarre.
Si c'est juste pour rendre plus clair le fait que c'est une dépêche sélectionnée, alors autant l'écrire explicitement, ça devrait suffire, ou mettre un cadre spécial.
[^] # Re: tiret du six
Posté par jihele . En réponse au sondage Prononciation des options. Évalué à 10.
(Histoire vraie.) Un jour, mon collègue brésilien qui était au téléphone à côté de moi me demande
…
# Open Source Collective
Posté par jihele . En réponse au journal Possible coupure de service sur Liberapay. Évalué à 3.
J'ai lu un peu en diagonale, pas sûr que ça remplisse exactement la même fonction, mais ça me fait penser à Open Source Collective.
https://opencollective.com/opensource
On l'utilise pour Marshmallow (https://opencollective.com/marshmallow). C'est pas moi qui ai choisi, j'ai pas cherché, j'ai pas benchmarké, donc je peux pas commenter.
[^] # Re: Plus disponible
Posté par jihele . En réponse au message Lien de téléchargement. Évalué à 3.
Attention, l'URL dit "stable" mais c'est Jessie.
[^] # Re: WM ?
Posté par jihele . En réponse au lien Lobotomizing GNOME. Évalué à 2.
J'utilisais Xfce et maintenant Mate pour les mêmes raisons et je comprends les limitations dont il parle. Devoir bricoler (et pas toujours avec succès) pour éviter le tearing sur les vidéos, ajouter des partages samba, rechercher des fichiers, modifier les sorties écran, etc., c'est pas top.
# C'est génial !
Posté par jihele . En réponse au lien Vendredi 25 mai : Jour de la serviette - prêt ? Don't panic !. Évalué à 2.
[^] # Re: python 2.7 pourquoi ne pas passer en 3.7 ?
Posté par jihele . En réponse à la dépêche Libravatar — fin du service ou début du renouveau. Évalué à 2.
3.7 est encore en beta. Mais la question reste pertinente pour 3.x.