J'ai vu passer cette vidéo, de quoi s'agit-il en bref ?
Le titre ne m'évoque pas grand chose, je suppose qu'on peut fouiller dans les commentaires mais si tu a posté ça ici, peut-être que tu peux nous en dire deux trois mots Milo ?
Je l'écouterai peut-être tout à l'heure, je risque d'avoir un peu de temps à tuer.
Je viens d'essayer de compiler et démarrer l'application. J'ai été surpris de voir que ça se lançait en local mais qu'il fallait y accéder à partir d'une URL externe.
Peux-tu en dire plus sur pourquoi et s'il y a moyen de le lancer sans connexion internet ? Je suppose que la page utilise des capacités présentes uniquement en HTTPS et que ça simplifie l'installation, mais ça serait cool de pouvoir utiliser sa propre infrastructure quand on a déjà un serveur web avec du HTTPS quelque part.
Plus généralement l'architecture de ton projet semble intéressante, avec les problèmes qu'elles résout, peut-être que tu peux répondre avec un journal ?
Les README des deux dépôts que tu nous fait cloner sont un peu avares en détails, voire inexistants.
Ayant saisi quelques partitions ces derniers temps avec MuseScore, parfois avec un clavier MIDI, ça me manque de pouvoir saisir toutes les notes, et ensuite déterminer leur durée. Je trouve ça ultra fastidieux de saisir des notes en devant sans cesse faire des aller-retours entre le clavier MIDI et le clavier et/ou la souris, d'autant qu'il y a des bugs liés à la disposition AZERTY et plus généralement à la saisie clavier [1,2] dans MuseScore qui empêchent certains raccourcis clavier de fonctionner (correctement).
Ton journal est un bon rappel que LilyPond existe, je pense que je vais essayer de m'y mettre, et je vais essayer ton outil. J'essaierai aussi Frescobaldi.
Comment ça se passe pour les silences ? Joues-tu une note puis tu la transforme en silence ? Ajoutes-tu les silences en saisissant les durées ? Autrement ?
Cependant, il ne faut pas que ça empêche de se poser la question de maîtriser son infrastructure et de ne pas dépendre de celle des autres pour pouvoir construire son logiciel, et le mettre en production si c'est un service web.
Si la construction échoue quand on retire les accès à internet à la CI / la machine qui construit le logiciel (ou au minimum les accès au monde extérieur qui n'est pas dans l'infrastructure qu'on gère soi-même), ce n'est pas encore bon. Ça veut dire que la disparition d'un seul acteur privé, potentiellement à l'autre bout de la terre, avec qui on n'a peut-être même pas une relation contractuelle, disparaisse ou change de politique pour se retrouver bloqué.
La question dépasse évidemment Docker, qui pourrait d'ailleurs revenir avec un plan un peu similaire plus tard : il va bien falloir qu'ils trouvent un manière de la financer, la leur, d'infrastructure, au lieu de remplacer celle des autres.
Si vous pensez, comme nous, qu’à un moment donné, l’IA — l’IA générale — sera extrêmement, incroyablement puissante, alors il n’est tout simplement pas logique d’ouvrir le code source. C’est une mauvaise idée… Je m’attends à ce que, dans quelques années, il devienne évident pour tout le monde qu’il n’est pas judicieux de mettre l’IA en libre accès
Traduction :
On ne veut pas négliger la quantité phénoménale d'investissement financiers de la part de Microsoft et ses demandes de restreindre l'accès à eux seuls pour des raisons évidentes de compétition.
…
il devienne évident pour tout le monde qu’
Non, pas pour moi. Si on veut que les gens puissent se défendre efficacement contre les nouvelles technologies, il est évident qu'on veut leur permettre d'accéder librement à nos technologies avancées et efficaces.
Voilà, c'est tellement simple à renverser. "C'est évident que" n'est pas un argument. L'appel à la peur n'est pas très subtile non plus. En sommes, un ramassis de sophismes qui cachent de vraies motivations, moins nobles.
C'est vrai et c'est pour ces raisons que libre est important pour moi. Et Docker est un outil libre et dispose d'écosystème sain de ce point de vue (apparemment, de loin, je n'utilise pas trop moi-même).
Après, leurs outils sont aussi orientés / configurés par défaut pour utiliser le service qu'ils proposent et tout est fait pour t'inviter à utiliser leurs services, sans même forcément le savoir / imaginer que la commande docker pourrait marcher avec d'autres services.
C'est un peu comme si un service mail fournissait un client mail configuré pour utiliser son service par défaut mais pouvait être utilisé avec d'autres services (vs. un client mails comme Thunderbird sans configuration par défaut sur un service - même si Thunderbird a des accords avec des services mails pour aller un peu dans ce sens aussi, par exemple Gandi (en France ?)).
Ils auraient pu faire en sorte que les gens aient à configurer les outils sur leurs services et faire une séparation nette entre les outils et les services. Ça pourrait rendre l'outil un poil moins pratique à utiliser aussi, ça peut aussi aider des services alternatifs qui d'un coup aurait bénéficié de la même barrière d'entrée que les services proposés par Docker.
Ce n'est pas un reproche, mais c'est un choix (stratégique) qu'ils ont fait.
je connais pas bien rsync.net mais tarsnap ne te permet pas de mettre à jour les données
Avec rsync.net tu peux y accéder en ftp, scp, sftp, et avec quelques outils unix classiques à travers ssh. Tu peux monter ton espace en sshfs et faire toutes les opérations classiques sur les fichiers. Ils font plusieurs snapshots (ZFS) de tes données par jour, donc c'est adapté à une utilisation style Nextcloud (en utilisation WebDAV et pas avec le client Nextcloud, mais il y a probablement des outils pour faire ce genre de chose aussi).
Effectivement ce n'est pas prévu pour être servi à des milliers d'utilisateurs comme un CDN (ou DockerHub) le ferait, donc oui, la mise en œuvre doit être très très différente.
Sans contredire tes remarques sur les coûts de stockages (et les comparaisons avec ce que proposent des GAFAM, les plus petits ne peuvent évidemment pas proposer les mêmes services pour les mêmes tarifs pour pleins de raisons) parce que je suis plutôt d'accord avec toi.
Je me suis intéressé récemment à un prix correct par quantité de données (que je pourrais proposer à quelqu'un à qui je fournirais un espace de stockage), je n'ai toujours pas ma réponse mais je suis tombé sur ces données intéressantes :
rsync.net : 1.5 centimes de dollar par GB, 1 centimes au dela d'un TB, 0.6 centimes au dela d'1 PT (redondé, avec des snapshots, support apparemment au top…). J'étais un peu sur le cul. Je suppose qu'il sont très gros et qu'ils peuvent faire des sacrés économies d'échelles. Quand on expose des prix pour des stockages de plus d'1 PT… Ça a l'air cool comme service d'ailleurs, dommage que la boite soit américaine (même s'ils ont un centre d'hébergement en suisse). En tout cas ça a l'air rentable, ils ont des gros clients et ils sont là depuis très longtemps (2001).
tarsnap.com : $0.25 par GB par mois. Ils sont probablement beaucoup plus petit que rsync.net.
Du coup peut-être qu'un quart de dollar par mois par GB c'est dans les prix. Encore moins quand tu peux faire des économies d'échelles. Mais ça doit dépendre énormément de l'uptime et des garanties que tu fournis, ainsi que du support et des services en plus que tu proposes, évidemment.
(pour référence si mes calculs sont bons : 20 € par an pour 100 GB, ça correspond à 0,017 € / GB / mois)
Par rapport à Docker, le fait qu'ils acceptent d'héberger et de servir autant de données gratuitement ça m'a toujours extrêmement étonné, c'est sûr que ça n'allait pas marcher éternellement. Le free lunch est fini mais il fallait s'y attendre. Et c'est vrai pour n'importe quel service : GitHub, les dépôts NPM, les dépôts Maven, PIP, un tas de ces choses sont gratuites mais dans une boite, je crois qu'il faut faire sa part et avoir des miroirs, des caches, des proxys des dépendances et ne pas se retrouver le bec dans l'eau quand il y a un changement de direction ou même une panne. Et aussi, c'est plus « poli » de ne pas tirer tout le temps sur les ressources des autres, même s'il y a des mécènes prêts à financer ces ressources :-).
Pour le coup, Unity était un environnement de bureau pas mal du tout. Il avait vraiment des fonctionnalités / une apparence distinctes et possiblement des besoins spécifiques (version netbook, adaptation mobile (Ubuntu Touch)…) donc je comprends le besoin d'avancer vite et de ne pas venir embêter les projets upstream avec des adaptations qui auraient peut-être été rejetées. Bon, aujourd'hui on comprends qu'adapter Gnome a l'air de bien marcher. Mais je comprends qu'on pourrait leur reprocher de ne pas avoir contribuer à Gnome ou KDE directement.
Pareil pour Upstart : ils ont fait un truc vraiment bien, finalement ça a été remplacé par systemd mais systemd n'existait pas encore mais c'était une alternative justifiée qui proposait une réelle avancée par rapport à l'existant. Upstart a certainement était une source d'inspiration de systemd (avec launchd).
Pour Mir, en effet on voyait le truc se casser la gueule à 2000 km. Tout le monde soutenait Wayland, je ne sais pas si Mir était supérieur techniquement (il y a des défauts de conceptions / décisions discutables dans Wayland, peut-être que Canonical avait vu ça et voulait faire autrement, je ne sais pas), mais ça allait difficilement marcher sans une adoption par l'écosystème complet.
Pour Snap, je vois l'intérêt business stratégique potentiel mais pas trop les avantages pour les utilisateurs / utilisatrices ou l'écosystème.
Le problème, c'est qu'on pourrait dire ça de presque n'importe quelle brique logicielle d'une distribution Linux. Mais si tout fonctionne comme ça, au final, on a pas mal perdu les avantages du libres.
Et la gestion des paquets / de l'installation des logiciels, c'est un peu central dans un système d'exploitation / une distribution Linux quand même. Surtout quand des trucs aussi importants que des navigateurs web sont distribués avec. (Il n'y a qu'à voir à quel point la possibilité d'ajouter des dépôts APT est utilisé, pouvoir ajouter ses sources alternatives n'est pas une utilité / liberté théorique).
Après, je suis d'accord avec toi, le client est libre, c'est déjà ça.
À noter aussi (pour répondre à une remarque d'un autre de tes commentaires) que le libre ne sert pas qu'à vérifier que le code est ok, il vient avec plein d'autres avantages dont un grand contrôle dans tes outils informatiques. Ok, dans tous les cas, tu ne vas pas pouvoir vérifier que le serveur fait tourner le code libre à ta disposition (si le code serveur était libre) (et c'est bien à ça que sert le chiffrement de bout en bout et plus généralement les protocoles qui permettent de ne pas faire confiance au serveur), mais par contre tu pourrais le réutiliser et l'adapter à tes besoins.
Je n'ai pas dit ça. j'ai dit "Dommage", c'est quand même beaucoup plus léger comme réaction, non ?
ça c'est bien.
ça je ne sais pas, ce n'est pas à moi d'en juger. Par contre ça pose des problèmes : la variété de distributions Linux ne facilite pas la distribution un logiciel qui va marcher partout.
On a eu une première tentative de résolution de ce problème avec AppImage (et ça ne marche pas trop mal !).
On a une deuxième tentative avec Flatpak, qui ajoute une gestion des dépendances sur des bases communes, une gestion des permissions et un système de conteneurisation qui va avec cette gestion des permissions. Perso je n'utilise pas, mais ça permet de distribuer des applications sur plein de distributions à la fois. Les distributions répandues l'on adopté, au moins dans leurs dépôts.
Et on a Canonical qui sort une techno équivalente avec pas d'avantage clair, et qui a surtout l'effet qu'on retourne à la case départ : au lieu de viser toutes les distributions sans devoir se payer la maintenance d'un paquet pour chaque distributions, si Ubuntu avait adopté Flatpak, on va avoir :
les gens qui vont s'arrêter à Ubuntu en produisant un Snap
les gens qui vont devoir se payer la production d'un Snap ET d'un flatpak, ou d'un deb ET d'un Flatpak.
À mon avis, ça limite l'intérêt du tout. "Dommage", parce que distribuer un logiciel pour Linux, c'est un réel problème, et perso je vois en Flatpak un truc qui aurait pu être (un début de) solution acceptable au problème, enterré par Snap vu la popularité d'Ubuntu.
Sinon, pourquoi tu attaques comme ça ? On peut échanger paisiblement ?
Même le simple fait d'utiliser des talkies walkies ou des pots de yaourt reliés par des ficelles permettent de se connecter, communiquer et partager des contenus.
Plutôt pas pour les pots de yaourt, puisque ça ne permet pas de découvrir d'autre gens, si ?
Et donc la question se pose pour des réseaux comme Signal : les contacts sont déjà dans le carnet d'adresse, donc ça ne s'appliquerait pas à Signal ou des applications de ce type qui n'ont pas de fonction de découverte ?
La conséquence, c'est que l'écosystème Snap est contrôlé par Canonical et personne d'autre. Ça fait de Snapcraft un "vulgaire" Play Store / Apple Store avec client libre.
Dommage, on avait déjà Flatpak pour cette fonctionnalité, sans ces problèmes.
Même si ça passe par imposer faute de pouvoir convaincre?
Oui et non. Concernant les citoyen·ne·s, idéalement il faudrait que les gens soient conscients de l'importance de la chose. Déjà pour qu'ils connaissant les bénéfices qu'ils peuvent en tirer, et aussi pour que ces droits ne se perdent pas. En même temps on ne peut pas demander à tout le monde d'être sensible à tous les aspects de tous les domaines. Peut-être qu'avec une présentation des enjeux autour de l'informatique tôt dans l'éducation ça pourrait le faire parce qu'il se trouve que l'informatique c'est assez omniprésent, mais bon. Concernant les boites qui font du logiciel, évidemment si on ne les pousse pas à faire du libre pour les utilisateurs finaux ça ne changera jamais. Mais ma perspective, elle est du point de vue du citoyen, pas de la boite qui produit du logiciel. Je m'intéresse aux droits du premier, pas de cette dernière. Il se trouve que je bosse moi-même pour une boite rentable qui vit du logiciel libre donc j'ai la chance d'être cohérent à ce point (mais je reconnais que c'est en partie de la chance - en partie parce que j'ai essayé fort aussi, faut pas déconner non plus :-P).
Je pense que ça devrait être dans la loi mais ça demande d'autres changements en profondeur. Peut-être déjà des subventions publiques comme celles que le gouvernement allemand attribue actuellement à différents projets libres pour constituer un socle numérique souverain et libre : https://www.dataport.de/about-phoenix/
Et du coup, savoir quel business model va gagner si on ne contraint rien, ça ne m'intéresse pas non plus. La question est : est-ce qu'on veut garantir que les citoyens aient ces libertés ? Si oui, et que c'est imposé par la loi, je suis sûr que des business seront possibles / vont s'adapter. Ça va suivre. Pas sans souffrance évidemment, ce serait une petite révolution.
À noter que la majorité des postes de dev, c'est en fait de la presta pour des boites il me semble, et qu'il n'y a pas de raison que ce genre activité soit touchée : ici les utilisateurs finaux ce sont les boites et elles payent pour obtenir du code dans les conditions qu'elles établissent. Éventuellement on peut "protéger" ces clients pour leurs garantir que le code qu'elle reçoive est libre, mais je ne crois pas que ça change grand chose.
Donc vraiment ça n'affecterait "que" les boites qui souhaitaient "enfermer" leurs utilisateurs pour une raison ou une autre. Et c'est "seulement" une partie du monde informatique.
un droit du citoyen
Je pense que ça devrait l'être justement, tout comme les chargeurs standards, ou comme la réparabilité. Avec les enjeux de vie privée, le code devrait être auditable publiquement, ou du moins l'utilisateur devrait pouvoir faire auditer son code, (faire) vérifier que les binaires correspondent aux sources et (faire) construire les binaires à partir des sources ; en principe ce point demande à la fois plus et moins que le libre (plus, parce que ça demande du reproducible build ou un autre mécanisme garantissant ces choses). Et aussi pouvoir (faire) modifier son logiciel selon ses besoin sans dépendre du fournisseur initial - en bref, d'être maitre·sse de ses outils comme cela l'a été pendant longtemps et comme ça l'est encore pour beaucoup de choses hors du monde de l'informatique.
je m'arrêterai de répondre même si c'est intéressant intellectuellement
Ça roule ! Je comprends.
les insultes "ces merdes", qui est bien dommage car casse un peu l'idée que ça serait objectif
Oui. En même temps j'assume (et je ne suis pas spécialement objectif même si j'essaie d'avancer des arguments rationnels, j'ai des opinions relativement tranchées). Ils vendent du matériel, ils n'auraient rien à perdre à libérer ce code. Sauf s'ils veulent ne pas risquer de se faire poursuivre en justice pour des questions de brevet, mais en fait tout le monde fait ça donc la source du problème c'est que le système des brevets est tout pété. Et je n'ai pas de trop de sympathie pour la protection de l'IP non plus. En tant que civilisation on devrait être capable de coopérer et de ne pas tout voir comme de la compétition. Mais là aussi on vie peut-être dans un monde à réformer de ce point de vue.
Et rappelons que le non libre n'enlève rien à personne, tu es toujours libre de refuser pour toi
Je pense comprendre ton point de vue (le code proprio est un truc qui existe simplement, tu n'es pas obligé d'utiliser si tu ne veux pas l'utiliser). Mais je ne suis pas d'accord avec toi là dessus.
Une personne qui vie dans un pays occidental aujourd'hui est quasi obligée d'utiliser du code non libre, à commencer par ces firmwares non libres. Et sinon, la tonne de JavaScript non libre qui traîne partout. Sinon, elle est exclue de la société au moins à un certain degré. Il y a une pelleté de démarches administratives ou de choses de la vie ou autres qui demandent maintenant d'avoir un ordinateur ou un smartphone, de plus en plus en tout cas. C'est de plus en plus difficile en tout cas d'y échapper. Et même si on peut s'en passer, on ne devrait forcer personne à un tel niveau d'inconfort. De fait, on est un peu forcé à exécuter du code non libre aujourd'hui. Il n'y a pas vraiment le choix. Personne qui n'est pas expert·e aujourd'hui peut éviter du code non libre même par conviction. On peut ne pas être versé·e dans l'informatique et utiliser GNU/Linux au quotidien, mais on ne peut pas éviter le code non libre. Ce choix n'existe pas.
Or, mon opinion est que les libertés garanties par le logiciel libre devraient être des droits fondamentaux (utiliser, étudier, modifier, redistribuer). Aujourd'hui, rien n'oblige les dev à fournir leur programmes à leurs utilisateurs et utilisatrices en libre. Y compris pour les services de l'état. On pourrait dire que les gens qui y tiennent devraient faire l'effort de trouver des solutions, mais pour l'instant ces solutions n'existent pas. Le compromis est quasi inévitable, et dans tous les cas demande énormément d'effort.
Tu as le droit de penser qu'on a pas besoin que ces libertés soient garanties, ou même que ce n'est pas souhaitable. Mais si on pense ça, c'est évident qu'on souhaite que ça aille dans ce sens, et qu'on considère l'obligation d'utiliser des firmwares non libres comme non souhaitable et qu'on veuille (militer pour, travailler pour) s'en débarrasser.
On pourra me demander "et le hardware alors ? Ça ne te dérange pas de l'utiliser quand il n'est pas open" ? Et là ma réponse est que mais oui, j'aimerais qu'on me fournisse les schémas du hardware que j'achète, en fait ! mais là, la situation est encore plus difficile que le logiciel libre, il n'y a plus ou moins aucun choix en open hardware.
De plus, si je peux raisonnablement modifier un logiciel avec du matériel que j'ai chez moi et du temps, je ne peux pas raisonnablement pas le faire pour une puce wifi / bluetooth ou un CPU. Je n'ai pas de salle blanche et tout le reste de l'infrastructure qui me permettrait d'adapter et produire un CPU chez moi. Et on peut y aller par étape. On peut déjà s'occuper du logiciel pour commencer. C'est la partie "facile".
Pour finir, j'aime bien vivre mes opinions pour moi (incarner le changement qu'on veut voir arriver), mais je souhaiterais que mes idéaux soient accessibles au reste du monde. Les solutions collectives, plus qu'individuelles, m'intéressent particulièrement.
Avec plaisir. C'est compliqué, je ne suis pas totalement fixé perso :-)
Dans tous les cas, indépendamment de Debian, je pense qu'il faut continuer à militer / agir contre les firmwares non libres, faire de la pédagogie, etc. En tout cas ne pas oublier le problème.
Je pense que déjà, le message de confirmation de l'installateur Debian permet de se souvenir du problème quand on l'installe…
En fait, c'est un recul et un progrès en même temps je pense. L'installateur contiendra effectivement les firmwares non-free (donc c'est pénible si tu voulais éviter de les télécharger) mais :
les firmwares seront désormais dans une section séparée des dépôts non-free-firmware, et plus non-free. Donc, quand tu veux les firmwares non-free mais pas le reste des paquets non-free, c'est gagnant.
l'installateur continuera à te demander si tu veux les installer ou non avant quoi que ce soit.
Je sympathise avec ce choix de 2011 de ne pas inclure les firmwares non-free par défaut pour forcer les constructeurs à libérer leurs firmwares (et j'aimais bien cette décision), mais force est de constater que 12 ans plus tard, la situation n'a fait que s'empirer : il y a des firmwares non-libres pour tout, le matériel qui fonctionne avec seulement des firmwares libres est vieillissant (pas de carte wiki AC ou plus récent, ça s'arrête à N), y compris les CPU avec leurs microcodes complètement obscures à mette à jour et il vaut probablement mieux le faire de toute façon. La liberté a régressé malgré Debian. Et donc en pratique, pour installer Debian, soit tu t'embêtais à télécharger l'image non officielle contenant les firmwares non-libre, soit tu t'embêtais à les télécharger et cette "barrière" n'a probablement pas plus convaincu les gens que ça, voire ça a été source de frustration. Si tu as du matériel qui ne fonctionne qu'avec des firmwares libres, tu es déjà convaincu.
De mon côté, ça pourrait m'encourager à plus facilement recommander Debian en ces jours où Ubuntu c'est pas mal chaotique avec Snap et autres trucs. Elle sera plus facile à installer, et elle reste une distribution qui sépare bien les choses, et elle devient aussi à ma connaissance la seule distribution qui permet d'opter pour les firmwares non-libres et pas pour tout l'ensemble complet non-free.
Au pire, il y a toujours PureOS qui est une Debian sans toutes ces merdes.
Du coup, aujourd'hui on a un bon choix pour recommander :
Debian aux gens qui ont du matériel avec firmwares non libres et qui ne s'en passeront pas (par exemple, ils ne rachèteront pas de matériel équivalent avec firmware libre)
PureOS ou Debian en refusant l'installation des firmwares non libres aux autres.
openSUSE Tumbleweed permet de tester un KDE à jour et bien intégré. Mais ce n'est pas Debian, et ça peut faire beaucoup de choses nouvelles à tester d'un coup. C'est chercher à avoir un nouveau KDE sur une Debian classique qui m'a mené à openSUSE Tumbleweed, à la base c'est plutôt Debian que je connais mieux. Je me suis dit que quitte à vouloir un KDE récent et à ne pas trouver de solution correcte sous Debian, une rolling release avec quand même des dépôts de bases bien fournis et relativement stable était une solution intuitive au problème. Clairement moins stable que Debian stable, mais c'est surtout parce que Debian stable, c'est Stable ®™.
KDE Neon ce n'était pas la panacée quand je l'avais essayée il y a des années, il y avait notamment des conflits de paquets, mais il y a de grandes chances que ça soit mieux maintenant, et que ça soit le choix tout naturel pour essayer un KDE récent pour quelqu'un venant de Debian. Il faut accepter d'être de retour sur Ubuntu (perso je ne veux plus y toucher, avec leur sale habitude de remplacer les paquets deb qui marchent bien par un snap tout cassé et tout lent), potentiellement pénible quand on est passé à Debian, mais bon, ça peut marcher.
Il est important de noter que, de par le manque de CI/CD permettant de déployer automatiquement une nouvelle version du code, chaque mise en production est, dans ce type d’entreprise, un processus majoritairement manuel avec les risques inhérents que cela implique, à savoir les erreurs humaines.
Je suis d'accord, il faut un peu de CI/CD pour les mises en production, ça permet d'automatiser les erreurs et les accélérer à toute vitesse, au lieu de les introduire manuellement, ce qui est assez épuisant surtout un vendredi.
D'ailleurs, n'oubliez pas de mettre en production manuellement votre système de CI/CD un autre jour que le vendredi.
# Vu passer, quid?
Posté par raphj (site web personnel) . En réponse au lien Magouilles et mensonges au pays du Starship (Stardust - La Chaîne Air & Espace - YouTube). Évalué à 4. Dernière modification le 13 avril 2023 à 11:23.
J'ai vu passer cette vidéo, de quoi s'agit-il en bref ?
Le titre ne m'évoque pas grand chose, je suppose qu'on peut fouiller dans les commentaires mais si tu a posté ça ici, peut-être que tu peux nous en dire deux trois mots Milo ?
Je l'écouterai peut-être tout à l'heure, je risque d'avoir un peu de temps à tuer.
# Utiliser localement ?
Posté par raphj (site web personnel) . En réponse au journal Lilypond + Frescobaldi + … (aka «En avant la musique !»). Évalué à 2. Dernière modification le 31 mars 2023 à 14:03.
Je viens d'essayer de compiler et démarrer l'application. J'ai été surpris de voir que ça se lançait en local mais qu'il fallait y accéder à partir d'une URL externe.
Peux-tu en dire plus sur pourquoi et s'il y a moyen de le lancer sans connexion internet ? Je suppose que la page utilise des capacités présentes uniquement en HTTPS et que ça simplifie l'installation, mais ça serait cool de pouvoir utiliser sa propre infrastructure quand on a déjà un serveur web avec du HTTPS quelque part.
Plus généralement l'architecture de ton projet semble intéressante, avec les problèmes qu'elles résout, peut-être que tu peux répondre avec un journal ?
Les README des deux dépôts que tu nous fait cloner sont un peu avares en détails, voire inexistants.
# Saisie des notes puis durée
Posté par raphj (site web personnel) . En réponse au journal Lilypond + Frescobaldi + … (aka «En avant la musique !»). Évalué à 5. Dernière modification le 25 mars 2023 à 12:22.
Ayant saisi quelques partitions ces derniers temps avec MuseScore, parfois avec un clavier MIDI, ça me manque de pouvoir saisir toutes les notes, et ensuite déterminer leur durée. Je trouve ça ultra fastidieux de saisir des notes en devant sans cesse faire des aller-retours entre le clavier MIDI et le clavier et/ou la souris, d'autant qu'il y a des bugs liés à la disposition AZERTY et plus généralement à la saisie clavier [1,2] dans MuseScore qui empêchent certains raccourcis clavier de fonctionner (correctement).
Ton journal est un bon rappel que LilyPond existe, je pense que je vais essayer de m'y mettre, et je vais essayer ton outil. J'essaierai aussi Frescobaldi.
Comment ça se passe pour les silences ? Joues-tu une note puis tu la transforme en silence ? Ajoutes-tu les silences en saisissant les durées ? Autrement ?
Merci !
[1] https://github.com/musescore/MuseScore/issues/17010
[2] https://github.com/musescore/MuseScore/issues/14195
# No free lunch
Posté par raphj (site web personnel) . En réponse au journal Docker aime finalement le libre. Évalué à 5. Dernière modification le 25 mars 2023 à 12:08.
C'est plutôt cool.
Cependant, il ne faut pas que ça empêche de se poser la question de maîtriser son infrastructure et de ne pas dépendre de celle des autres pour pouvoir construire son logiciel, et le mettre en production si c'est un service web.
Si la construction échoue quand on retire les accès à internet à la CI / la machine qui construit le logiciel (ou au minimum les accès au monde extérieur qui n'est pas dans l'infrastructure qu'on gère soi-même), ce n'est pas encore bon. Ça veut dire que la disparition d'un seul acteur privé, potentiellement à l'autre bout de la terre, avec qui on n'a peut-être même pas une relation contractuelle, disparaisse ou change de politique pour se retrouver bloqué.
La question dépasse évidemment Docker, qui pourrait d'ailleurs revenir avec un plan un peu similaire plus tard : il va bien falloir qu'ils trouvent un manière de la financer, la leur, d'infrastructure, au lieu de remplacer celle des autres.
# Bullshit
Posté par raphj (site web personnel) . En réponse au lien « Nous avions tort » : en dévoilant GPT-4, OpenAI dit rejeter l’open source désormais . Évalué à 10. Dernière modification le 17 mars 2023 à 09:23.
Traduction :
…
Non, pas pour moi. Si on veut que les gens puissent se défendre efficacement contre les nouvelles technologies, il est évident qu'on veut leur permettre d'accéder librement à nos technologies avancées et efficaces.
Voilà, c'est tellement simple à renverser. "C'est évident que" n'est pas un argument. L'appel à la peur n'est pas très subtile non plus. En sommes, un ramassis de sophismes qui cachent de vraies motivations, moins nobles.
Le libre n'est pas du tout le problème.
[^] # Re: Copieurs!
Posté par raphj (site web personnel) . En réponse au journal Docker supprime l'accès gratuit aux groupes et organisations. Évalué à 4. Dernière modification le 16 mars 2023 à 16:15.
C'est vrai et c'est pour ces raisons que libre est important pour moi. Et Docker est un outil libre et dispose d'écosystème sain de ce point de vue (apparemment, de loin, je n'utilise pas trop moi-même).
Après, leurs outils sont aussi orientés / configurés par défaut pour utiliser le service qu'ils proposent et tout est fait pour t'inviter à utiliser leurs services, sans même forcément le savoir / imaginer que la commande docker pourrait marcher avec d'autres services.
C'est un peu comme si un service mail fournissait un client mail configuré pour utiliser son service par défaut mais pouvait être utilisé avec d'autres services (vs. un client mails comme Thunderbird sans configuration par défaut sur un service - même si Thunderbird a des accords avec des services mails pour aller un peu dans ce sens aussi, par exemple Gandi (en France ?)).
Ils auraient pu faire en sorte que les gens aient à configurer les outils sur leurs services et faire une séparation nette entre les outils et les services. Ça pourrait rendre l'outil un poil moins pratique à utiliser aussi, ça peut aussi aider des services alternatifs qui d'un coup aurait bénéficié de la même barrière d'entrée que les services proposés par Docker.
Ce n'est pas un reproche, mais c'est un choix (stratégique) qu'ils ont fait.
[^] # Re: Copieurs!
Posté par raphj (site web personnel) . En réponse au journal Docker supprime l'accès gratuit aux groupes et organisations. Évalué à 3. Dernière modification le 16 mars 2023 à 16:03.
Exact.
Avec rsync.net tu peux y accéder en ftp, scp, sftp, et avec quelques outils unix classiques à travers ssh. Tu peux monter ton espace en sshfs et faire toutes les opérations classiques sur les fichiers. Ils font plusieurs snapshots (ZFS) de tes données par jour, donc c'est adapté à une utilisation style Nextcloud (en utilisation WebDAV et pas avec le client Nextcloud, mais il y a probablement des outils pour faire ce genre de chose aussi).
Ils n'ont pas l'air de proposer quoi que ce soit qui demande beaucoup de CPU, il ne semble pas y avoir d'utilitaire d'archivage comme gzip, xz ou bzip2 dispo (https://www.rsync.net/resources/howto/remote_commands.html).
Effectivement ce n'est pas prévu pour être servi à des milliers d'utilisateurs comme un CDN (ou DockerHub) le ferait, donc oui, la mise en œuvre doit être très très différente.
[^] # Re: Copieurs!
Posté par raphj (site web personnel) . En réponse au journal Docker supprime l'accès gratuit aux groupes et organisations. Évalué à 4. Dernière modification le 16 mars 2023 à 13:39.
Sans contredire tes remarques sur les coûts de stockages (et les comparaisons avec ce que proposent des GAFAM, les plus petits ne peuvent évidemment pas proposer les mêmes services pour les mêmes tarifs pour pleins de raisons) parce que je suis plutôt d'accord avec toi.
Je me suis intéressé récemment à un prix correct par quantité de données (que je pourrais proposer à quelqu'un à qui je fournirais un espace de stockage), je n'ai toujours pas ma réponse mais je suis tombé sur ces données intéressantes :
rsync.net : 1.5 centimes de dollar par GB, 1 centimes au dela d'un TB, 0.6 centimes au dela d'1 PT (redondé, avec des snapshots, support apparemment au top…). J'étais un peu sur le cul. Je suppose qu'il sont très gros et qu'ils peuvent faire des sacrés économies d'échelles. Quand on expose des prix pour des stockages de plus d'1 PT… Ça a l'air cool comme service d'ailleurs, dommage que la boite soit américaine (même s'ils ont un centre d'hébergement en suisse). En tout cas ça a l'air rentable, ils ont des gros clients et ils sont là depuis très longtemps (2001).
tarsnap.com : $0.25 par GB par mois. Ils sont probablement beaucoup plus petit que rsync.net.
Du coup peut-être qu'un quart de dollar par mois par GB c'est dans les prix. Encore moins quand tu peux faire des économies d'échelles. Mais ça doit dépendre énormément de l'uptime et des garanties que tu fournis, ainsi que du support et des services en plus que tu proposes, évidemment.
(pour référence si mes calculs sont bons : 20 € par an pour 100 GB, ça correspond à 0,017 € / GB / mois)
Par rapport à Docker, le fait qu'ils acceptent d'héberger et de servir autant de données gratuitement ça m'a toujours extrêmement étonné, c'est sûr que ça n'allait pas marcher éternellement. Le free lunch est fini mais il fallait s'y attendre. Et c'est vrai pour n'importe quel service : GitHub, les dépôts NPM, les dépôts Maven, PIP, un tas de ces choses sont gratuites mais dans une boite, je crois qu'il faut faire sa part et avoir des miroirs, des caches, des proxys des dépendances et ne pas se retrouver le bec dans l'eau quand il y a un changement de direction ou même une panne. Et aussi, c'est plus « poli » de ne pas tirer tout le temps sur les ressources des autres, même s'il y a des mécènes prêts à financer ces ressources :-).
(Coucou au fait, j'espère que ça va bien :-))
# « N’étant ni informaticienne, ni juriste, ni politicienne »
Posté par raphj (site web personnel) . En réponse à la dépêche Une page se tourne à l'April, une libraire est présidente depuis 100 jours. Évalué à 5.
Qu'est-ce qui t'a menée à l'APRIL / aux logiciels libres au point de t'engager dans une asso ?
Super en tout cas :-)
[^] # Re: Distribution
Posté par raphj (site web personnel) . En réponse au lien HP Dev One (sous Pop!_OS) : HP jette l’éponge mais assurera un support. Évalué à 1.
ah ah xD
Je n'avais pas la ref. Excellent.
[^] # Re: Distribution
Posté par raphj (site web personnel) . En réponse au lien HP Dev One (sous Pop!_OS) : HP jette l’éponge mais assurera un support. Évalué à 5. Dernière modification le 06 mars 2023 à 17:20.
Pour le coup, Unity était un environnement de bureau pas mal du tout. Il avait vraiment des fonctionnalités / une apparence distinctes et possiblement des besoins spécifiques (version netbook, adaptation mobile (Ubuntu Touch)…) donc je comprends le besoin d'avancer vite et de ne pas venir embêter les projets upstream avec des adaptations qui auraient peut-être été rejetées. Bon, aujourd'hui on comprends qu'adapter Gnome a l'air de bien marcher. Mais je comprends qu'on pourrait leur reprocher de ne pas avoir contribuer à Gnome ou KDE directement.
Pareil pour Upstart : ils ont fait un truc vraiment bien, finalement ça a été remplacé par systemd mais systemd n'existait pas encore mais c'était une alternative justifiée qui proposait une réelle avancée par rapport à l'existant. Upstart a certainement était une source d'inspiration de systemd (avec launchd).
Pour Mir, en effet on voyait le truc se casser la gueule à 2000 km. Tout le monde soutenait Wayland, je ne sais pas si Mir était supérieur techniquement (il y a des défauts de conceptions / décisions discutables dans Wayland, peut-être que Canonical avait vu ça et voulait faire autrement, je ne sais pas), mais ça allait difficilement marcher sans une adoption par l'écosystème complet.
Pour Snap, je vois l'intérêt business stratégique potentiel mais pas trop les avantages pour les utilisateurs / utilisatrices ou l'écosystème.
[^] # Re: Distribution
Posté par raphj (site web personnel) . En réponse au lien HP Dev One (sous Pop!_OS) : HP jette l’éponge mais assurera un support. Évalué à 3. Dernière modification le 06 mars 2023 à 16:42.
Le problème, c'est qu'on pourrait dire ça de presque n'importe quelle brique logicielle d'une distribution Linux. Mais si tout fonctionne comme ça, au final, on a pas mal perdu les avantages du libres.
Et la gestion des paquets / de l'installation des logiciels, c'est un peu central dans un système d'exploitation / une distribution Linux quand même. Surtout quand des trucs aussi importants que des navigateurs web sont distribués avec. (Il n'y a qu'à voir à quel point la possibilité d'ajouter des dépôts APT est utilisé, pouvoir ajouter ses sources alternatives n'est pas une utilité / liberté théorique).
Après, je suis d'accord avec toi, le client est libre, c'est déjà ça.
À noter aussi (pour répondre à une remarque d'un autre de tes commentaires) que le libre ne sert pas qu'à vérifier que le code est ok, il vient avec plein d'autres avantages dont un grand contrôle dans tes outils informatiques. Ok, dans tous les cas, tu ne vas pas pouvoir vérifier que le serveur fait tourner le code libre à ta disposition (si le code serveur était libre) (et c'est bien à ça que sert le chiffrement de bout en bout et plus généralement les protocoles qui permettent de ne pas faire confiance au serveur), mais par contre tu pourrais le réutiliser et l'adapter à tes besoins.
[^] # Re: Distribution
Posté par raphj (site web personnel) . En réponse au lien HP Dev One (sous Pop!_OS) : HP jette l’éponge mais assurera un support. Évalué à 4.
Je n'ai pas dit ça. j'ai dit "Dommage", c'est quand même beaucoup plus léger comme réaction, non ?
ça je ne sais pas, ce n'est pas à moi d'en juger. Par contre ça pose des problèmes : la variété de distributions Linux ne facilite pas la distribution un logiciel qui va marcher partout.
On a eu une première tentative de résolution de ce problème avec AppImage (et ça ne marche pas trop mal !).
On a une deuxième tentative avec Flatpak, qui ajoute une gestion des dépendances sur des bases communes, une gestion des permissions et un système de conteneurisation qui va avec cette gestion des permissions. Perso je n'utilise pas, mais ça permet de distribuer des applications sur plein de distributions à la fois. Les distributions répandues l'on adopté, au moins dans leurs dépôts.
Et on a Canonical qui sort une techno équivalente avec pas d'avantage clair, et qui a surtout l'effet qu'on retourne à la case départ : au lieu de viser toutes les distributions sans devoir se payer la maintenance d'un paquet pour chaque distributions, si Ubuntu avait adopté Flatpak, on va avoir :
À mon avis, ça limite l'intérêt du tout. "Dommage", parce que distribuer un logiciel pour Linux, c'est un réel problème, et perso je vois en Flatpak un truc qui aurait pu être (un début de) solution acceptable au problème, enterré par Snap vu la popularité d'Ubuntu.
Sinon, pourquoi tu attaques comme ça ? On peut échanger paisiblement ?
# Pas les pots de yaourt ?
Posté par raphj (site web personnel) . En réponse au journal Les mineurs bientôt privés de télécommunication (et les majeurs traqués). Évalué à 3. Dernière modification le 06 mars 2023 à 11:53.
Plutôt pas pour les pots de yaourt, puisque ça ne permet pas de découvrir d'autre gens, si ?
Et donc la question se pose pour des réseaux comme Signal : les contacts sont déjà dans le carnet d'adresse, donc ça ne s'appliquerait pas à Signal ou des applications de ce type qui n'ont pas de fonction de découverte ?
[^] # Re: Distribution
Posté par raphj (site web personnel) . En réponse au lien HP Dev One (sous Pop!_OS) : HP jette l’éponge mais assurera un support. Évalué à 3. Dernière modification le 06 mars 2023 à 09:03.
Très content de la gamme pro d'HP, en tout cas des Elitebook G640 (G3 et G6). Ça roule sans problème sous Linux :-)
[^] # Re: Distribution
Posté par raphj (site web personnel) . En réponse au lien HP Dev One (sous Pop!_OS) : HP jette l’éponge mais assurera un support. Évalué à 6.
La partie serveur de Snap, qui sert à faire tourner un "app store" (Snapcraft), n'est pas libre.
Il me semble que la partie cliente est, elle, libre.
Dans l'univers F-Droid, ça correspondrait à l'anti-fonctionalité "NonFreeNet" : https://f-droid.org/docs/Anti-Features/#NonFreeNet
La conséquence, c'est que l'écosystème Snap est contrôlé par Canonical et personne d'autre. Ça fait de Snapcraft un "vulgaire" Play Store / Apple Store avec client libre.
Dommage, on avait déjà Flatpak pour cette fonctionnalité, sans ces problèmes.
[^] # Re: Bi-genre
Posté par raphj (site web personnel) . En réponse au journal J’ai deux amours. Évalué à 4.
il y a gens, avec lequel les adjectifs sont féminins si avant, masculins si après.
Des gens heureux. De bonnes gens.
[^] # Re: C'est l'application de la décision prise comme indiqué précédemment :
Posté par raphj (site web personnel) . En réponse au lien Ça se précise, les microcodes privateurs bientôt de retour dans l'installateur Debian - phoronix. Évalué à 4. Dernière modification le 20 février 2023 à 19:15.
Oui et non. Concernant les citoyen·ne·s, idéalement il faudrait que les gens soient conscients de l'importance de la chose. Déjà pour qu'ils connaissant les bénéfices qu'ils peuvent en tirer, et aussi pour que ces droits ne se perdent pas. En même temps on ne peut pas demander à tout le monde d'être sensible à tous les aspects de tous les domaines. Peut-être qu'avec une présentation des enjeux autour de l'informatique tôt dans l'éducation ça pourrait le faire parce qu'il se trouve que l'informatique c'est assez omniprésent, mais bon. Concernant les boites qui font du logiciel, évidemment si on ne les pousse pas à faire du libre pour les utilisateurs finaux ça ne changera jamais. Mais ma perspective, elle est du point de vue du citoyen, pas de la boite qui produit du logiciel. Je m'intéresse aux droits du premier, pas de cette dernière. Il se trouve que je bosse moi-même pour une boite rentable qui vit du logiciel libre donc j'ai la chance d'être cohérent à ce point (mais je reconnais que c'est en partie de la chance - en partie parce que j'ai essayé fort aussi, faut pas déconner non plus :-P).
Je pense que ça devrait être dans la loi mais ça demande d'autres changements en profondeur. Peut-être déjà des subventions publiques comme celles que le gouvernement allemand attribue actuellement à différents projets libres pour constituer un socle numérique souverain et libre : https://www.dataport.de/about-phoenix/
Et du coup, savoir quel business model va gagner si on ne contraint rien, ça ne m'intéresse pas non plus. La question est : est-ce qu'on veut garantir que les citoyens aient ces libertés ? Si oui, et que c'est imposé par la loi, je suis sûr que des business seront possibles / vont s'adapter. Ça va suivre. Pas sans souffrance évidemment, ce serait une petite révolution.
À noter que la majorité des postes de dev, c'est en fait de la presta pour des boites il me semble, et qu'il n'y a pas de raison que ce genre activité soit touchée : ici les utilisateurs finaux ce sont les boites et elles payent pour obtenir du code dans les conditions qu'elles établissent. Éventuellement on peut "protéger" ces clients pour leurs garantir que le code qu'elle reçoive est libre, mais je ne crois pas que ça change grand chose.
Donc vraiment ça n'affecterait "que" les boites qui souhaitaient "enfermer" leurs utilisateurs pour une raison ou une autre. Et c'est "seulement" une partie du monde informatique.
Je pense que ça devrait l'être justement, tout comme les chargeurs standards, ou comme la réparabilité. Avec les enjeux de vie privée, le code devrait être auditable publiquement, ou du moins l'utilisateur devrait pouvoir faire auditer son code, (faire) vérifier que les binaires correspondent aux sources et (faire) construire les binaires à partir des sources ; en principe ce point demande à la fois plus et moins que le libre (plus, parce que ça demande du reproducible build ou un autre mécanisme garantissant ces choses). Et aussi pouvoir (faire) modifier son logiciel selon ses besoin sans dépendre du fournisseur initial - en bref, d'être maitre·sse de ses outils comme cela l'a été pendant longtemps et comme ça l'est encore pour beaucoup de choses hors du monde de l'informatique.
Ça roule ! Je comprends.
Oui. En même temps j'assume (et je ne suis pas spécialement objectif même si j'essaie d'avancer des arguments rationnels, j'ai des opinions relativement tranchées). Ils vendent du matériel, ils n'auraient rien à perdre à libérer ce code. Sauf s'ils veulent ne pas risquer de se faire poursuivre en justice pour des questions de brevet, mais en fait tout le monde fait ça donc la source du problème c'est que le système des brevets est tout pété. Et je n'ai pas de trop de sympathie pour la protection de l'IP non plus. En tant que civilisation on devrait être capable de coopérer et de ne pas tout voir comme de la compétition. Mais là aussi on vie peut-être dans un monde à réformer de ce point de vue.
[^] # Re: C'est l'application de la décision prise comme indiqué précédemment :
Posté par raphj (site web personnel) . En réponse au lien Ça se précise, les microcodes privateurs bientôt de retour dans l'installateur Debian - phoronix. Évalué à 10. Dernière modification le 20 février 2023 à 16:58.
Je pense comprendre ton point de vue (le code proprio est un truc qui existe simplement, tu n'es pas obligé d'utiliser si tu ne veux pas l'utiliser). Mais je ne suis pas d'accord avec toi là dessus.
Une personne qui vie dans un pays occidental aujourd'hui est quasi obligée d'utiliser du code non libre, à commencer par ces firmwares non libres. Et sinon, la tonne de JavaScript non libre qui traîne partout. Sinon, elle est exclue de la société au moins à un certain degré. Il y a une pelleté de démarches administratives ou de choses de la vie ou autres qui demandent maintenant d'avoir un ordinateur ou un smartphone, de plus en plus en tout cas. C'est de plus en plus difficile en tout cas d'y échapper. Et même si on peut s'en passer, on ne devrait forcer personne à un tel niveau d'inconfort. De fait, on est un peu forcé à exécuter du code non libre aujourd'hui. Il n'y a pas vraiment le choix. Personne qui n'est pas expert·e aujourd'hui peut éviter du code non libre même par conviction. On peut ne pas être versé·e dans l'informatique et utiliser GNU/Linux au quotidien, mais on ne peut pas éviter le code non libre. Ce choix n'existe pas.
Or, mon opinion est que les libertés garanties par le logiciel libre devraient être des droits fondamentaux (utiliser, étudier, modifier, redistribuer). Aujourd'hui, rien n'oblige les dev à fournir leur programmes à leurs utilisateurs et utilisatrices en libre. Y compris pour les services de l'état. On pourrait dire que les gens qui y tiennent devraient faire l'effort de trouver des solutions, mais pour l'instant ces solutions n'existent pas. Le compromis est quasi inévitable, et dans tous les cas demande énormément d'effort.
Tu as le droit de penser qu'on a pas besoin que ces libertés soient garanties, ou même que ce n'est pas souhaitable. Mais si on pense ça, c'est évident qu'on souhaite que ça aille dans ce sens, et qu'on considère l'obligation d'utiliser des firmwares non libres comme non souhaitable et qu'on veuille (militer pour, travailler pour) s'en débarrasser.
On pourra me demander "et le hardware alors ? Ça ne te dérange pas de l'utiliser quand il n'est pas open" ? Et là ma réponse est que mais oui, j'aimerais qu'on me fournisse les schémas du hardware que j'achète, en fait ! mais là, la situation est encore plus difficile que le logiciel libre, il n'y a plus ou moins aucun choix en open hardware.
De plus, si je peux raisonnablement modifier un logiciel avec du matériel que j'ai chez moi et du temps, je ne peux pas raisonnablement pas le faire pour une puce wifi / bluetooth ou un CPU. Je n'ai pas de salle blanche et tout le reste de l'infrastructure qui me permettrait d'adapter et produire un CPU chez moi. Et on peut y aller par étape. On peut déjà s'occuper du logiciel pour commencer. C'est la partie "facile".
Pour finir, j'aime bien vivre mes opinions pour moi (incarner le changement qu'on veut voir arriver), mais je souhaiterais que mes idéaux soient accessibles au reste du monde. Les solutions collectives, plus qu'individuelles, m'intéressent particulièrement.
[^] # Re: C'est l'application de la décision prise comme indiqué précédemment :
Posté par raphj (site web personnel) . En réponse au lien Ça se précise, les microcodes privateurs bientôt de retour dans l'installateur Debian - phoronix. Évalué à 3. Dernière modification le 20 février 2023 à 11:29.
Avec plaisir. C'est compliqué, je ne suis pas totalement fixé perso :-)
Dans tous les cas, indépendamment de Debian, je pense qu'il faut continuer à militer / agir contre les firmwares non libres, faire de la pédagogie, etc. En tout cas ne pas oublier le problème.
Je pense que déjà, le message de confirmation de l'installateur Debian permet de se souvenir du problème quand on l'installe…
[^] # Re: C'est l'application de la décision prise comme indiqué précédemment :
Posté par raphj (site web personnel) . En réponse au lien Ça se précise, les microcodes privateurs bientôt de retour dans l'installateur Debian - phoronix. Évalué à 10. Dernière modification le 20 février 2023 à 09:07.
En fait, c'est un recul et un progrès en même temps je pense. L'installateur contiendra effectivement les firmwares non-free (donc c'est pénible si tu voulais éviter de les télécharger) mais :
Je sympathise avec ce choix de 2011 de ne pas inclure les firmwares non-free par défaut pour forcer les constructeurs à libérer leurs firmwares (et j'aimais bien cette décision), mais force est de constater que 12 ans plus tard, la situation n'a fait que s'empirer : il y a des firmwares non-libres pour tout, le matériel qui fonctionne avec seulement des firmwares libres est vieillissant (pas de carte wiki AC ou plus récent, ça s'arrête à N), y compris les CPU avec leurs microcodes complètement obscures à mette à jour et il vaut probablement mieux le faire de toute façon. La liberté a régressé malgré Debian. Et donc en pratique, pour installer Debian, soit tu t'embêtais à télécharger l'image non officielle contenant les firmwares non-libre, soit tu t'embêtais à les télécharger et cette "barrière" n'a probablement pas plus convaincu les gens que ça, voire ça a été source de frustration. Si tu as du matériel qui ne fonctionne qu'avec des firmwares libres, tu es déjà convaincu.
De mon côté, ça pourrait m'encourager à plus facilement recommander Debian en ces jours où Ubuntu c'est pas mal chaotique avec Snap et autres trucs. Elle sera plus facile à installer, et elle reste une distribution qui sépare bien les choses, et elle devient aussi à ma connaissance la seule distribution qui permet d'opter pour les firmwares non-libres et pas pour tout l'ensemble complet non-free.
Au pire, il y a toujours PureOS qui est une Debian sans toutes ces merdes.
Du coup, aujourd'hui on a un bon choix pour recommander :
[^] # Re: Sympa!
Posté par raphj (site web personnel) . En réponse au lien KDE Plasma 5.27 est publié et apporte d'importantes améliorations au bureau et à ses outils. Évalué à 3. Dernière modification le 17 février 2023 à 13:05.
openSUSE Tumbleweed permet de tester un KDE à jour et bien intégré. Mais ce n'est pas Debian, et ça peut faire beaucoup de choses nouvelles à tester d'un coup. C'est chercher à avoir un nouveau KDE sur une Debian classique qui m'a mené à openSUSE Tumbleweed, à la base c'est plutôt Debian que je connais mieux. Je me suis dit que quitte à vouloir un KDE récent et à ne pas trouver de solution correcte sous Debian, une rolling release avec quand même des dépôts de bases bien fournis et relativement stable était une solution intuitive au problème. Clairement moins stable que Debian stable, mais c'est surtout parce que Debian stable, c'est Stable ®™.
KDE Neon ce n'était pas la panacée quand je l'avais essayée il y a des années, il y avait notamment des conflits de paquets, mais il y a de grandes chances que ça soit mieux maintenant, et que ça soit le choix tout naturel pour essayer un KDE récent pour quelqu'un venant de Debian. Il faut accepter d'être de retour sur Ubuntu (perso je ne veux plus y toucher, avec leur sale habitude de remplacer les paquets deb qui marchent bien par un snap tout cassé et tout lent), potentiellement pénible quand on est passé à Debian, mais bon, ça peut marcher.
# Les trolls le vendredi
Posté par raphj (site web personnel) . En réponse au lien Les mises en production le vendredi (1/3). Évalué à 10. Dernière modification le 17 février 2023 à 12:43.
Je suis d'accord, il faut un peu de CI/CD pour les mises en production, ça permet d'automatiser les erreurs et les accélérer à toute vitesse, au lieu de les introduire manuellement, ce qui est assez épuisant surtout un vendredi.
D'ailleurs, n'oubliez pas de mettre en production manuellement votre système de CI/CD un autre jour que le vendredi.
[^] # Re: Activer le débogage Android et essayer scrcpy au moins une fois
Posté par raphj (site web personnel) . En réponse au lien Astuce pour continuer à se servir d'un ordiphone avec un écran cassé. Évalué à 2. Dernière modification le 30 janvier 2023 à 22:38.
Oui, avec DAVx⁵.
Excellent aussi pour plein de choses, d'ailleurs je viens de le recommander à un pote qui m'a demandé d'installer Linux sur un vieil ordi.
# Activer le débogage Android et essayer scrcpy au moins une fois
Posté par raphj (site web personnel) . En réponse au lien Astuce pour continuer à se servir d'un ordiphone avec un écran cassé. Évalué à 5.
(pour qui a la flemme de cliquer)
… et je confirme, ça peut faciliter grandement les choses.
Et scrcpy est assez pratique aussi pour d'autres trucs, notamment pour taper des SMS avec son ordinateur, avec l'interface du téléphone.