Je confirme que c'est top (j'ai pu migrer un système d'un ordi à un autre en passant par des instantanés de sous-volumes Btrfs, pouvoir faire un instantané avant d'expérimenter et potentiellement foutre le bronx est un petit confort aussi ; j'adore Btrfs, en tout cas ses fonctionnalités, ça pourrait aussi être ZFS je suppose), par contre rien de spécifique à openSUSE il me semble, je le faisais aussi avec Ubuntu et Debian. D'ailleurs, je me demande si l'installateur d'Ubuntu ne fait pas ça aussi par défaut si on choisit Btrfs. Ils étaient peut-être pionniers. Ou Fedora ? Pour le coup je ne sais plus.
En tout cas je confirme que l'installateur d'openSUSE choisit Btrfs par défaut. Je l'ai vu tourner pour la première fois la semaine dernière, j'ai fait ma première (et précédente) installation via un chroot depuis Debian…
Je n'ai pas essayé Snapper dont tu m'apprends l'existence.
Je pense qu'ils sont installés par défaut, et le branding est léger. Perso j'utilise KDE, je n'ai jamais trop essayé Gnome sur openSUSE. Je regarde de temps en temps par curiosité, sans plus. Je crois qu'openSUSE a(vait) un focus KDE, et en effet on voit bien le branding openSUSE sur une nouvelle installation (faite la semaine dernière par PXE, tout à fait par hasard).
De spécifique openSUSE, tu dois déjà avoir zypper pour le gestionnaire de paquet et YaST quelque part pour configurer le système, je suppose que YaST est aussi installé par défaut quand on fait une installation Gnome.
Merci pour le lien vers ta dépêche sur Manjaro, je l'avais déjà lu mais je la lirai à nouveau dans la perspective d'en écrire une pour openSUSE.
Ça ne me choque pas qu'elle ne soit pas basée sur autre chose. Elle semble assez "grosse" pour se débrouiller et ses spécificités par rapport à Red Hat ou Debian justifient probablement cela. J'imagine que c'est en outre une bonne chose d'avoir une alternative commerciale (fournissant du support) à Red Hat et que cette alternative soit européenne.
Du coup, ne te sens tu pas parfois seul face à tes problèmes / questions ?
Non, pas particulièrement mais mon expérience existante en matière de GNU/Linux doit beaucoup aider. C'est vrai qu'on tombe de temps en temps sur des forums en allemand, mais en réalité :
j'ai tendance à faire toutes mes recherches en anglais depuis longtemps, avant même d'atterrir sur openSUSE. Je ne sais pas du tout comment ça se passe en français ;
l'écrasante majorité des problèmes ne sont pas spécifiques à openSUSE donc les solutions sur lesquelles on tombe pour les autres distributions fonctionnent en général sans adaptation. D'ailleurs, j'ai l'impression qu'openSUSE change très peu le fonctionnement des paquets. Parfois il y a un peu de branding mais il est léger, optionnel et clairement séparé dans un paquet -branding, avec un paquet alternatif -upstream si on veut le branding original. Par exemple pour Firefox, il y a un packet MozillaFirefox-branding-openSUSE et un paquet MozillaFirefox-branding-upstream en plus du paquet MozillaFirefox. C'est plutôt propre. Ça concerne 55 paquets à ce jour d'après zypper search, principalement les environnements de bureau, des trucs relatifs au démarrage, Firefox, LibreOffice, Yast, GTK et… NetworkManager ?!
en réalité, j'ai rencontré peu de problèmes. Les trucs sont plutôt logiques donc on s'en sort vite.
Ca te dit pas de nous faire un petit journal / dépêche pour parler du sujet ?
Dans le principe oui, pourquoi pas, faudrait que je m'y colle ! La demande est notée. Faut voir quoi présenter, dans quel but et pour qui. Les sources d'inspiration sont les bienvenues :-) Une écriture collaborative sur le sujet, et donc une dépêche, serait probablement plus adaptée. Je n'y connais pas grand chose en vrai. J'utilise assez passivement. Ça pourrait aussi valoir le coup de mentionner Open Build Service (en plus de Zypper et YaST).
Je n'ai jamais essayé les Raspberry, mais le rockpro64 est effectivement bien plus puissant à priori, et ça dépote pas mal. Je ne peux pas trop dire côté graphique, mais ça se passait bien pour naviguer sur le web avec Firefox la fois où j'ai été amené à l'utiliser comme ça.
« Les développeurs React forcés à réapprendre PHP et Vanilla JS »
"Nos applications et nos sites ne se lançaient plus sur les machines de nos clients. De toute façon, la compilation avec Webpack et Babel prenait une éternité, nous étions obligés de lancer la compilation le soir et on croisait les doigts pour que ça ait réussi à finir avant le lendemain matin. Nous n'en pouvions plus, nos sprints avaient fini par être étendus à 2 mois et pas 2 semaines comme avant. Les résultats des builds nous déconcentraient pendant nos standups. À l'exécution c'était l'enfer, je ne me doutais pas que tant de choses se passaient après la frappe d'un caractère… Alors, on s'est formés à Vim, et finalement HTML c'est pas si mal ! Et on met du JS vraiment quand c'est absolument nécessaire, lancer un compilateur ce n'est pas gratuit… et finalement, avec PHP, ça ne change pas grand chose, on avait déjà l'habitude de mélanger et d'entremêler aléatoirement le code pilotant la logique de l'interface avec du HTML, faut juste rajouter quelques $ à droite à gauche devant le noms des variables et voilà…"
Bon en tout cas, si les Raspberry Pi sont à 100-200€, ça vaut plus le coup de prendre une carte chez Pine64, la Rockpro64 est en stock à 80$ [1] et leurs cartes moins chères, probablement plus équivalentes aux Raspberry Pi, entre 25 et 45 $ [2]…
J'avais juste une appréhension sur YaST. Est-ce que ça te dérange pour configurer tes logiciels ? Son utilisation est-elle obligatoire pour configurer son système ?
YaST est un point fort. C'est un outil qui n'est pas obligatoire, mais ça aide bien quand tu as envie de faire des choses sans passer trop de temps à étudier le système sans encore connaitre les détails (justement, ceux qui changent par rapport à une distribution que tu connais bien par exemple). C'est bien foutu et ça marche bien. Quand il y a un doute sur un réglage système, YaST permet d'aller voir dans une interface bien présentée et claire. Pour moi, une des killer feature c'est l'installation en cliquant sur des liens depuis un navigateur, installation des dépôts compris avec un assistant qui guide et fait vérifier les trucs (ajout de la signature du dépôt, priorité du dépôt, avertissements qui vont bien, etc). En fait, je me surprends à parfois préférer utiliser YaST que les outils en ligne de commandes pour les trucs que je fais rarement ou la gestion des dépôts. J'irais jusqu'à dire que toutes les distributions grand public devraient fournir un outil comme YaST. Il y a vraiment des modules de configuration pour un tas de choses, y compris des choses qui ne sont pas forcément très agréables à configurer sur d'autres distributions, Grub par exemple.
Cela dit, toutes les fonctionnalités sont accessibles par les outils classiques et des fichiers de configuration classiques. YaST est un ajout plutôt qu'un outil qui se met en travers le chemin. Par exemple, il y a les équivalent de /etc/apt/sources.list et /etc/apt/preferences. Zypper est d'ailleurs très bien foutu et je trouve qu'il remplace avantageusement apt, et pourtant la barre est haute (et apt m'est plus familier). Sa sortie est concise, informative, en couleur, quand il y a des problèmes l'outil se met en mode interactif et propose des choix au lieu d'imposer une résolution arbitraire ou de botter en touche. Bloquer la version d'un paquet se fait en utilisant la commande zypper addlock, zypper install est aussi bien capable de prendre un nom de paquet dans les dépôts, un chemin vers un fichier rpm ou une URL sur internet. Il y a tout de base pour installer des nouveaux dépôts, ce n'est pas la galère comme sous Debian / Ubuntu avec les clés par encore importées, etc. Pour les opérations très bas niveau, il y a rpm, l'équivalent de dpkg, mais je ne m'en sert quasiment jamais, contrairement à dpkg sous Debian. Zypper mériterait probablement un journal à part entière en fait.
Quand on parle de distribution en rolling release, on évoque Manjaro, Arch or Debian sid.
Perso, j'aime bien Debian, et j'aime bien aussi avoir les dernières versions des logiciels et une bonne stabilité, mais Debian sid est là pour tester des correctifs et des nouvelles versions avant que tout ça soit livré dans Debian Stable. Il y a cette période de gel avant les sorties de Debian Stable, et finalement les logiciels ne sont pas toujours dans les nouvelles versions, pendant longtemps. En particulier KDE.
Arch, je l'ai utilisée un peu il y a longtemps, et ça a l'air de bien marcher mais le conseil de lire les notes de version avant de mettre à jour continue à être donné et je n'ai qu'une relative confiance sur la réussite des mises à jour à l'aveugle. Et pour beaucoup de logiciels, il faut passer par AUR, avec une qualité variable des recettes en laquelle je n'arrive pas à avoir confiance.
Et puis j'ai découvert l'existence openSUSE Tumbleweed : une rolling release qui promet d'être bien peaufinée et stable / robuste. Un peu réticent au départ parce que c'est une distribution RPM (habitué à APT depuis des années), je me suis malgré tout dit pourquoi pas essayer, et effectivement je l'utilise depuis 2018 et c'est jusqu'à maintenant promesse tenu : pas une seule merde qui plante tout le système. J'ai le sentiment de pouvoir mettre à jour en fermant les yeux. Il y a énormément de choses dans les dépôts, et pour certaines choses il y a des dépôts semi-officiels supplémentaires (par exemple pour KDE si on veut avoir des versions encore plus récentes), et on peut se rabattre sur des paquets expérimentaux / non officiels pour les quelques logiciels qui ne sont pas dans les dépôts principaux.
Très peu conseillée / discutée, et pourtant j'ai l'impression que c'est le meilleur des deux mondes : stable / peaufinée et rolling release. J'aime le confort des nouvelles versions des logiciels et des environnements de bureau sur distribution de bureau. Pas de problème de gestion comme chez Manjaro non plus. Je fais confiance. Ma préférence irait probablement vers une Debian réellement rolling release mais à défaut, je recommande cette distribution agréable au quotidien :-)
Pour le serveur, ma préférence va à Debian Stable avec les dépôts packages.sury.org pour des versions récentes de PHP et Apache, par le mainteneur qui s'occupe de ces paquets chez Debian.
Heureusement, aucun problème de ré-organisation de mon côté n'est possible. Je ne suis pas affecté. Parce que ça présupposerait d'avoir déjà une organisation en place. 🙃
Ça fait vachement penser à DBnary, qui est une base de données RDF (qu'on peut interroger avec Sparql) extraite du wiktionaire. Un effort de l'équipe GETALP au LIG (j'ai travaillé dessus en tant que stagiaire il y a quelques années).
Dbnary is an effort to provide multilingual lexical data extracted from wiktionary. The extracted data is made available as LLOD (Linguistic Linked Open Data). This data set has won the Monnet challenge in 2012.
Linguistic data currently includes Bulgarian, Dutch, English, Finnish, French, German, Greek, Italian, Japanese, Polish, Portuguese, Russian, Serbo-Croat, Spanish, Swedish and Turkish.
1) et aussi, un peu, car le machin-d’init-qui-fait-tout-et-presque-le-café m’agace, pas très Unix dans le sens : « je fais une seule chose, mais je la fais bien » tout cela !
Je suppose que tu parles de systemd. Je ne comprends pas cet avis. Ou plutôt, je comprends que c'est une rengaine souvent colportée sans trop réfléchir et une (mauvaise) manière de justifier de la haine contre systemd.
On encense les systèmes BSD pour leur bonne intégration. Justement, systemd c'est un ensemble bien intégré d'outils qui font chacun une chose bien. Ce n'est pas du tout un truc monolithique qui fait tout. Il apporte des qualités à l'écosystème GNU/Linux qu'on prêtait aux *BSD ! :-)
L'init n'est qu'un des nombreux petits outils qui font une seule chose et bien fourni par le projet systemd. Faut voir systemd comme GNU : un ensemble d'outils cohérents. Qui apporte une uniformisation, y compris à travers les différentes distributions, à un bazar pénible et spécifique qui régnait avant son arrivée.
Je trouve l'administration un poste sous Linux beaucoup plus simple et cohérente depuis l'introduction de systemd qui fait bien son job. Justement, tout est bien propre et découpé.
Si tu éprouves un sentiment aussi fort que l'agacement, c'est que tu as réfléchi sérieusement au problème et que tu vois une autre manière de faire meilleure. Quelle alternative vois-tu ? (en la décrivant précisément, et sans, du coup, tomber sur une description d'un équivalent à systemd).
En D (pour celles et ceux qui ne connaissent pas, c'est un langage à ramasse-miettes compilé nativement qui se veut un remplaçant de C++ avec 90% de sa puissance et 10% de sa complexité), cette fonctionnalité existe sous la forme de scope guards : il suffit de préfixer une instruction (ou un bloc d'instructions) par scope(exit) et elle sera exécutée à la fin du bloc de code actuel (pas de la fonction, sauf s'il s'agit du bloc principal de la fonction bien sûr).
Il y a aussi scope(success) : l'instruction ne sera exécutée que s'il n'y a pas eu d'exception levée, et scope(failure) que s'il y a eu une exception levée avant la fin de l'exécution du bloc courant.
Dans le Web, ce qui est triste, c'est que c'est plutôt bien accessible par défaut si on prend le temps de respecter les notions HTML de base (c'est un coup à prendre peut-être, mais ça ne prend pas tellement longtemps au quotidien au final).
Sauf que j'ai l'impression que souvent, dans le monde du développement frontend, on se bat en permanence contre CSS et HTML, à coup de CSS resets et de soupes de div. On ne comprend pas bien pourquoi on devrait utiliser des balises p pour faire des paragraphes quand ça marche avec des div et des br. Ces foutues balises p ajoutent des marges pénibles à gérer, autant partir d'un div qu'on contrôle totalement. Les table c'est mal donc on vire… et on remplace ça par des div imbriquées avec des classes bootstrap pour définir des lignes et des colonnes (non, je ne parle pas des tables pour faire de la présentation, mais bien pour afficher des données / entrées). les balises ul et li, pareil, ça ajoute des puces et des marges disgracieuses, avec des div c'est plus simple…
On ne pense pas en termes de sens et de structure HTML, mais en terme de comment ça doit s'afficher.
Mais en fait, quand on a une bonne structure HTML, c'est vite plus accessible sans effort (le navigateur sait faire automatiquement plein de chose avec ce qu'on lui donne), et on peut obtenir un affichage cohérent et logique probablement plus facilement Ensuite, c'est facile de rendre ça joli sans faire trop d'effort. Mais il faut le faire dans ce sens. Cependant, quand on écrit une application, on n'a pas forcément l'idée que c'est encore du HTML et tout ce qui va avec derrière, y compris sa sémantique… et c'est bien dommage. L'envie d'avoir son branding / une identité graphique bien particulière dans son UI n'aide pas toujours.
Il y a aussi le fait qu'on réinvente très vite les composants de base dans chaque projet, au lieu d'avoir une belle bibliothèque de composante toute faite et bien rodée comme on pourrait trouver dans les toolkits graphiques pour bureau comme Qt, GTK ou Cocoa, et où l'accessibilité vient par défaut. Ou on importe des bibliothèques React un peu random avec des qualité inégales et sans garanties.
Un jeu de composants tout prêt avec une accessibilité rôdée permettrait de régler un certain nombre de problèmes…
C'est comme les habitations, ce qui est plus accessible est souvent aussi plus facile ou agréable à utiliser pour tout le monde, mais ce n'est pas nécessairement facile de s'en rendre compte.
Mon message c'est : si on ne conçoit pas avec les outils qu'on utilise mais contre eux, oui, "ajouter" l'accessibilité c'est coûteux, mais si on embrasse les technos conçues pour ça, ça se passe déjà beaucoup mieux.
J'espère que je me trompe et que j'ai une vue trop réduite du monde du développement frontend.
Tout cela étant dit, bien sûr, tant que ce n'est pas testé (avec des lecteurs d'écrans, etc), on ne peut pas être sûr que ça fonctionne bien donc il y a des coûts dont on ne peut pas se passer si on veut être sûr d'être accessible.
Jitsi Videobridge does not mix the video channels into a composite video stream, but only relays the received video channels to all call participants. Therefore, while it does need to run on a server with good network bandwidth, CPU horsepower is not that critical for performance
À priori, un·e participant·e n'envoie qu'un flux vers le serveur, et le serveur dispatche le flux à chaque autre participant·e. C'est heureux que le flux ne soit envoyé qu'une fois, les connexions domestiques sont quand même souvent asymétriques et limitées en montant.
D'ailleurs, petite anecdote : à Algoo, pendant la mise en place de Visiocall (service basé sur Jitsi Meet, appelé Suricate TV à l'époque - on vient de faire le changement, il manque encore du branding sur cette instance), la veille du premier confinement, au cours des tests quand ce composant n'était pas encore en place, on observait ça :
conférence à deux fonctionnelle. La conférence continuait même si le serveur Jitsi était coupé
la conférence crashait dès qu'une troisième personne entrait dans le salon
Quand ce composant était en place :
idem à deux
la conférence continuait de fonctionner à 3 et prenait alors fin si on coupait le serveur. On pouvait observer un petit « switch » (petite coupure) en passant de 2 à 3 (qui ne s'observait plus au de-là) : c'était le passage d'une conf en P2P à une conf relayée par le serveur.
On suit et surveille actuellement les dernières versions de Jitsi : ça a beaucoup évolué depuis début 2020, où, il faut le reconnaître, ça pouvait déconner selon le navigateur utilisé (en particulier Firefox). Maintenant ça marche quand même bien indépendamment du navigateur et il y a plein de fonctionnalités bien cool, et notamment parce que des fonctionnalités nécessaires à la gestion des flux vidéos ont été implémentées dans Firefox et des bugs corrigés dans Jitsi Meet. On se tape quelques barres avec les réactions par émojis (la réaction « criquets » quand personne ne répond à une question en réunion a toujours son petit effet), et les fonds personnalisés… l'intégration avec Etherpad est top également.
Bref, Jitsi Meet est un outil formidable, je suis plutôt fan.
Avec la dernière version, on observe un petit soucis où parfois, un·e participant·e perd le son de quelqu'un d'autre. Un rafraîchissement de la page permet de remettre les choses dans l'ordre. Problème qui sera, espérons-le, bientôt corrigé. L'équipe derrière Jitsi est réactive et très sympathique.
Il y a un large recoupement entre les gens sensibles aux logiciels libres, ceux qui sont sensibles à la vie privée et ceux qui sont opposés au publicité, mais il n'y a qu'a faire un tour sur F-Droid pour se rendre compte qu'il y a des applications libres qui embarquent de base de la pub (et qui est retirée sur la version F-Droid, parce qu'en général c'est du code proprio qui s'en charge).
En tant qu'utilisateur de KDE, j'ai largement confiance dans le projet KDE pour ne pas mettre de la pub dans leur environnement de bureau ou leurs applications.
…et sinon, dans des distributions comme Debian pour retirer ces pubs.
D'ailleurs, je ne sais pas même pas si ce module permettant d'intégrer de la pub Qt est libre ?
J'ai mollement cherché et rien trouvé dans la page liée. Je ne compte pas utiliser ça, ni des applications qui l'utiliserait.
Ah… la tristesse. Au moins, ça décrasse les circuits empruntés par l'adrénaline.
C'est parfois vrai aussi sur les touches des claviers tactiles des téléphones dans les discussion instantanées.
Heureusement, la seule connerie qui me soit arrivée c'est d'envoyer ":-(" au lieu de ":-)" et je m'en suis rendu compte tout de suite (oui, parce que "(" et ")" sont aussi généralement à côté sur ces claviers).
[^] # Re: Une rolling release robuste : openSUSE Tumbleweed
Posté par raphj . En réponse au journal Comparaison entre Manjaro et Debian Sid. Évalué à 4. Dernière modification le 28 février 2022 à 20:48.
Je confirme que c'est top (j'ai pu migrer un système d'un ordi à un autre en passant par des instantanés de sous-volumes Btrfs, pouvoir faire un instantané avant d'expérimenter et potentiellement foutre le bronx est un petit confort aussi ; j'adore Btrfs, en tout cas ses fonctionnalités, ça pourrait aussi être ZFS je suppose), par contre rien de spécifique à openSUSE il me semble, je le faisais aussi avec Ubuntu et Debian. D'ailleurs, je me demande si l'installateur d'Ubuntu ne fait pas ça aussi par défaut si on choisit Btrfs. Ils étaient peut-être pionniers. Ou Fedora ? Pour le coup je ne sais plus.
En tout cas je confirme que l'installateur d'openSUSE choisit Btrfs par défaut. Je l'ai vu tourner pour la première fois la semaine dernière, j'ai fait ma première (et précédente) installation via un chroot depuis Debian…
Je n'ai pas essayé Snapper dont tu m'apprends l'existence.
[^] # Re: Une rolling release robuste : openSUSE Tumbleweed
Posté par raphj . En réponse au journal Comparaison entre Manjaro et Debian Sid. Évalué à 3. Dernière modification le 28 février 2022 à 15:41.
Je pense qu'ils sont installés par défaut, et le branding est léger. Perso j'utilise KDE, je n'ai jamais trop essayé Gnome sur openSUSE. Je regarde de temps en temps par curiosité, sans plus. Je crois qu'openSUSE a(vait) un focus KDE, et en effet on voit bien le branding openSUSE sur une nouvelle installation (faite la semaine dernière par PXE, tout à fait par hasard).
De spécifique openSUSE, tu dois déjà avoir zypper pour le gestionnaire de paquet et YaST quelque part pour configurer le système, je suppose que YaST est aussi installé par défaut quand on fait une installation Gnome.
Merci pour le lien vers ta dépêche sur Manjaro, je l'avais déjà lu mais je la lirai à nouveau dans la perspective d'en écrire une pour openSUSE.
[^] # Re: Une rolling release robuste : openSUSE Tumbleweed
Posté par raphj . En réponse au journal Comparaison entre Manjaro et Debian Sid. Évalué à 6. Dernière modification le 28 février 2022 à 12:07.
openSUSE semble elle-même être une distribution communautaire : https://fr.wikipedia.org/wiki/OpenSUSE#Communaut%C3%A9_openSUSE
Ça ne me choque pas qu'elle ne soit pas basée sur autre chose. Elle semble assez "grosse" pour se débrouiller et ses spécificités par rapport à Red Hat ou Debian justifient probablement cela. J'imagine que c'est en outre une bonne chose d'avoir une alternative commerciale (fournissant du support) à Red Hat et que cette alternative soit européenne.
Non, pas particulièrement mais mon expérience existante en matière de GNU/Linux doit beaucoup aider. C'est vrai qu'on tombe de temps en temps sur des forums en allemand, mais en réalité :
-branding, avec un paquet alternatif-upstreamsi on veut le branding original. Par exemple pour Firefox, il y a un packetMozillaFirefox-branding-openSUSEet un paquetMozillaFirefox-branding-upstreamen plus du paquetMozillaFirefox. C'est plutôt propre. Ça concerne 55 paquets à ce jour d'aprèszypper search, principalement les environnements de bureau, des trucs relatifs au démarrage, Firefox, LibreOffice, Yast, GTK et… NetworkManager ?!Dans le principe oui, pourquoi pas, faudrait que je m'y colle ! La demande est notée. Faut voir quoi présenter, dans quel but et pour qui. Les sources d'inspiration sont les bienvenues :-) Une écriture collaborative sur le sujet, et donc une dépêche, serait probablement plus adaptée. Je n'y connais pas grand chose en vrai. J'utilise assez passivement. Ça pourrait aussi valoir le coup de mentionner Open Build Service (en plus de Zypper et YaST).
[^] # Re: Z80 ou Z80 ?
Posté par raphj . En réponse au lien Le prix des Raspberry Pi flambe suite aux pénuries de composants. Évalué à 3.
J'ai bien sûr pensé à ma Ti 83+ pour ma part.
[^] # Re: un investissement
Posté par raphj . En réponse au lien Le prix des Raspberry Pi flambe suite aux pénuries de composants. Évalué à 3.
Je n'ai jamais essayé les Raspberry, mais le rockpro64 est effectivement bien plus puissant à priori, et ça dépote pas mal. Je ne peux pas trop dire côté graphique, mais ça se passait bien pour naviguer sur le web avec Firefox la fois où j'ai été amené à l'utiliser comme ça.
[^] # Re: un investissement
Posté par raphj . En réponse au lien Le prix des Raspberry Pi flambe suite aux pénuries de composants. Évalué à 5. Dernière modification le 27 février 2022 à 18:27.
Ah ah xD
« Les développeurs React forcés à réapprendre PHP et Vanilla JS »
"Nos applications et nos sites ne se lançaient plus sur les machines de nos clients. De toute façon, la compilation avec Webpack et Babel prenait une éternité, nous étions obligés de lancer la compilation le soir et on croisait les doigts pour que ça ait réussi à finir avant le lendemain matin. Nous n'en pouvions plus, nos sprints avaient fini par être étendus à 2 mois et pas 2 semaines comme avant. Les résultats des builds nous déconcentraient pendant nos standups. À l'exécution c'était l'enfer, je ne me doutais pas que tant de choses se passaient après la frappe d'un caractère… Alors, on s'est formés à Vim, et finalement HTML c'est pas si mal ! Et on met du JS vraiment quand c'est absolument nécessaire, lancer un compilateur ce n'est pas gratuit… et finalement, avec PHP, ça ne change pas grand chose, on avait déjà l'habitude de mélanger et d'entremêler aléatoirement le code pilotant la logique de l'interface avec du HTML, faut juste rajouter quelques $ à droite à gauche devant le noms des variables et voilà…"
Bon en tout cas, si les Raspberry Pi sont à 100-200€, ça vaut plus le coup de prendre une carte chez Pine64, la Rockpro64 est en stock à 80$ [1] et leurs cartes moins chères, probablement plus équivalentes aux Raspberry Pi, entre 25 et 45 $ [2]…
[^] # Re: Une rolling release robuste : openSUSE Tumbleweed
Posté par raphj . En réponse au journal Comparaison entre Manjaro et Debian Sid. Évalué à 6.
YaST est un point fort. C'est un outil qui n'est pas obligatoire, mais ça aide bien quand tu as envie de faire des choses sans passer trop de temps à étudier le système sans encore connaitre les détails (justement, ceux qui changent par rapport à une distribution que tu connais bien par exemple). C'est bien foutu et ça marche bien. Quand il y a un doute sur un réglage système, YaST permet d'aller voir dans une interface bien présentée et claire. Pour moi, une des killer feature c'est l'installation en cliquant sur des liens depuis un navigateur, installation des dépôts compris avec un assistant qui guide et fait vérifier les trucs (ajout de la signature du dépôt, priorité du dépôt, avertissements qui vont bien, etc). En fait, je me surprends à parfois préférer utiliser YaST que les outils en ligne de commandes pour les trucs que je fais rarement ou la gestion des dépôts. J'irais jusqu'à dire que toutes les distributions grand public devraient fournir un outil comme YaST. Il y a vraiment des modules de configuration pour un tas de choses, y compris des choses qui ne sont pas forcément très agréables à configurer sur d'autres distributions, Grub par exemple.
Cela dit, toutes les fonctionnalités sont accessibles par les outils classiques et des fichiers de configuration classiques. YaST est un ajout plutôt qu'un outil qui se met en travers le chemin. Par exemple, il y a les équivalent de
/etc/apt/sources.listet/etc/apt/preferences. Zypper est d'ailleurs très bien foutu et je trouve qu'il remplace avantageusement apt, et pourtant la barre est haute (et apt m'est plus familier). Sa sortie est concise, informative, en couleur, quand il y a des problèmes l'outil se met en mode interactif et propose des choix au lieu d'imposer une résolution arbitraire ou de botter en touche. Bloquer la version d'un paquet se fait en utilisant la commandezypper addlock,zypper installest aussi bien capable de prendre un nom de paquet dans les dépôts, un chemin vers un fichier rpm ou une URL sur internet. Il y a tout de base pour installer des nouveaux dépôts, ce n'est pas la galère comme sous Debian / Ubuntu avec les clés par encore importées, etc. Pour les opérations très bas niveau, il y arpm, l'équivalent dedpkg, mais je ne m'en sert quasiment jamais, contrairement àdpkgsous Debian. Zypper mériterait probablement un journal à part entière en fait.# Une rolling release robuste : openSUSE Tumbleweed
Posté par raphj . En réponse au journal Comparaison entre Manjaro et Debian Sid. Évalué à 10. Dernière modification le 26 février 2022 à 14:37.
Quand on parle de distribution en rolling release, on évoque Manjaro, Arch or Debian sid.
Perso, j'aime bien Debian, et j'aime bien aussi avoir les dernières versions des logiciels et une bonne stabilité, mais Debian sid est là pour tester des correctifs et des nouvelles versions avant que tout ça soit livré dans Debian Stable. Il y a cette période de gel avant les sorties de Debian Stable, et finalement les logiciels ne sont pas toujours dans les nouvelles versions, pendant longtemps. En particulier KDE.
Arch, je l'ai utilisée un peu il y a longtemps, et ça a l'air de bien marcher mais le conseil de lire les notes de version avant de mettre à jour continue à être donné et je n'ai qu'une relative confiance sur la réussite des mises à jour à l'aveugle. Et pour beaucoup de logiciels, il faut passer par AUR, avec une qualité variable des recettes en laquelle je n'arrive pas à avoir confiance.
Et puis j'ai découvert l'existence openSUSE Tumbleweed : une rolling release qui promet d'être bien peaufinée et stable / robuste. Un peu réticent au départ parce que c'est une distribution RPM (habitué à APT depuis des années), je me suis malgré tout dit pourquoi pas essayer, et effectivement je l'utilise depuis 2018 et c'est jusqu'à maintenant promesse tenu : pas une seule merde qui plante tout le système. J'ai le sentiment de pouvoir mettre à jour en fermant les yeux. Il y a énormément de choses dans les dépôts, et pour certaines choses il y a des dépôts semi-officiels supplémentaires (par exemple pour KDE si on veut avoir des versions encore plus récentes), et on peut se rabattre sur des paquets expérimentaux / non officiels pour les quelques logiciels qui ne sont pas dans les dépôts principaux.
Très peu conseillée / discutée, et pourtant j'ai l'impression que c'est le meilleur des deux mondes : stable / peaufinée et rolling release. J'aime le confort des nouvelles versions des logiciels et des environnements de bureau sur distribution de bureau. Pas de problème de gestion comme chez Manjaro non plus. Je fais confiance. Ma préférence irait probablement vers une Debian réellement rolling release mais à défaut, je recommande cette distribution agréable au quotidien :-)
Pour le serveur, ma préférence va à Debian Stable avec les dépôts packages.sury.org pour des versions récentes de PHP et Apache, par le mainteneur qui s'occupe de ces paquets chez Debian.
[^] # Re: Chapeau bas, David Louapre
Posté par raphj . En réponse au lien ScienceEtonnante : JE CRAQUE WORDLE ! 🟩⬛🟨⬛🟨 (grâce aux maths). Évalué à 2.
J'ai vécu ça pour le sudoku.
C'est assez fun d'écrire d'un solveur de sudoku. Résoudre un sudoku… ça, je ne sais pas faire.
[^] # Re: Tu n'imagines pas à quel point...
Posté par raphj . En réponse au lien Yet Another Hot Take on “Folders vs Tags”. Évalué à 2.
Ça a l'air long, chiant et compliqué.
Heureusement, aucun problème de ré-organisation de mon côté n'est possible. Je ne suis pas affecté. Parce que ça présupposerait d'avoir déjà une organisation en place. 🙃
# DBNary
Posté par raphj . En réponse au journal Le dictionnaire des francophones : un dictionnaire francophone structuré libre. Évalué à 7. Dernière modification le 13 février 2022 à 18:05.
Ça fait vachement penser à DBnary, qui est une base de données RDF (qu'on peut interroger avec Sparql) extraite du wiktionaire. Un effort de l'équipe GETALP au LIG (j'ai travaillé dessus en tant que stagiaire il y a quelques années).
http://kaiko.getalp.org/about-dbnary/
[^] # Re: arm ?
Posté par raphj . En réponse au lien Intel s'apprête à commercialiser des processeurs "Pay-As-You-Go" où vous payez pour débloquer.... Évalué à 10.
Ça risc.
# Understand the facts
Posté par raphj . En réponse au lien Intel mise sur RISC-V. Évalué à 5. Dernière modification le 10 février 2022 à 15:42.
J'attends avec impatience la participation ou le commentaire, ou l'inaction de ARM. Mes pop-corn sont prêts.
(ref : https://linuxfr.org/users/martoni/journaux/understand-the-fact-la-campagne-de-arm-contre-le-set-d-instructions-libre-risc-v)
[^] # Re: Slackware n’intègre pas de résolution de dépendances ?
Posté par raphj . En réponse à la dépêche Tout arrive, même Slackware 15.0. Évalué à 10. Dernière modification le 10 février 2022 à 12:49.
Je suppose que tu parles de systemd. Je ne comprends pas cet avis. Ou plutôt, je comprends que c'est une rengaine souvent colportée sans trop réfléchir et une (mauvaise) manière de justifier de la haine contre systemd.
On encense les systèmes BSD pour leur bonne intégration. Justement, systemd c'est un ensemble bien intégré d'outils qui font chacun une chose bien. Ce n'est pas du tout un truc monolithique qui fait tout. Il apporte des qualités à l'écosystème GNU/Linux qu'on prêtait aux *BSD ! :-)
L'init n'est qu'un des nombreux petits outils qui font une seule chose et bien fourni par le projet systemd. Faut voir systemd comme GNU : un ensemble d'outils cohérents. Qui apporte une uniformisation, y compris à travers les différentes distributions, à un bazar pénible et spécifique qui régnait avant son arrivée.
Je trouve l'administration un poste sous Linux beaucoup plus simple et cohérente depuis l'introduction de systemd qui fait bien son job. Justement, tout est bien propre et découpé.
Si tu éprouves un sentiment aussi fort que l'agacement, c'est que tu as réfléchi sérieusement au problème et que tu vois une autre manière de faire meilleure. Quelle alternative vois-tu ? (en la décrivant précisément, et sans, du coup, tomber sur une description d'un équivalent à systemd).
# Les scope guards en D
Posté par raphj . En réponse au journal Une 20-aine de lignes de code pour le defer de Go en C++. Évalué à 10. Dernière modification le 07 février 2022 à 19:58.
En D (pour celles et ceux qui ne connaissent pas, c'est un langage à ramasse-miettes compilé nativement qui se veut un remplaçant de C++ avec 90% de sa puissance et 10% de sa complexité), cette fonctionnalité existe sous la forme de
scopeguards : il suffit de préfixer une instruction (ou un bloc d'instructions) parscope(exit)et elle sera exécutée à la fin du bloc de code actuel (pas de la fonction, sauf s'il s'agit du bloc principal de la fonction bien sûr).Il y a aussi
scope(success): l'instruction ne sera exécutée que s'il n'y a pas eu d'exception levée, etscope(failure)que s'il y a eu une exception levée avant la fin de l'exécution du bloc courant.La doc vend cette fonctionnalité comme un remplacement de RAII en C++ :
[^] # Re: Manquer le sujet?
Posté par raphj . En réponse au lien Why Don’t Developers Take Accessibility Seriously?. Évalué à 10.
Entièrement d'accord. Et j'aimerais compléter.
Dans le Web, ce qui est triste, c'est que c'est plutôt bien accessible par défaut si on prend le temps de respecter les notions HTML de base (c'est un coup à prendre peut-être, mais ça ne prend pas tellement longtemps au quotidien au final).
Sauf que j'ai l'impression que souvent, dans le monde du développement frontend, on se bat en permanence contre CSS et HTML, à coup de CSS resets et de soupes de div. On ne comprend pas bien pourquoi on devrait utiliser des balises p pour faire des paragraphes quand ça marche avec des div et des br. Ces foutues balises p ajoutent des marges pénibles à gérer, autant partir d'un div qu'on contrôle totalement. Les table c'est mal donc on vire… et on remplace ça par des div imbriquées avec des classes bootstrap pour définir des lignes et des colonnes (non, je ne parle pas des tables pour faire de la présentation, mais bien pour afficher des données / entrées). les balises ul et li, pareil, ça ajoute des puces et des marges disgracieuses, avec des div c'est plus simple…
On ne pense pas en termes de sens et de structure HTML, mais en terme de comment ça doit s'afficher.
Mais en fait, quand on a une bonne structure HTML, c'est vite plus accessible sans effort (le navigateur sait faire automatiquement plein de chose avec ce qu'on lui donne), et on peut obtenir un affichage cohérent et logique probablement plus facilement Ensuite, c'est facile de rendre ça joli sans faire trop d'effort. Mais il faut le faire dans ce sens. Cependant, quand on écrit une application, on n'a pas forcément l'idée que c'est encore du HTML et tout ce qui va avec derrière, y compris sa sémantique… et c'est bien dommage. L'envie d'avoir son branding / une identité graphique bien particulière dans son UI n'aide pas toujours.
Il y a aussi le fait qu'on réinvente très vite les composants de base dans chaque projet, au lieu d'avoir une belle bibliothèque de composante toute faite et bien rodée comme on pourrait trouver dans les toolkits graphiques pour bureau comme Qt, GTK ou Cocoa, et où l'accessibilité vient par défaut. Ou on importe des bibliothèques React un peu random avec des qualité inégales et sans garanties.
Un jeu de composants tout prêt avec une accessibilité rôdée permettrait de régler un certain nombre de problèmes…
C'est comme les habitations, ce qui est plus accessible est souvent aussi plus facile ou agréable à utiliser pour tout le monde, mais ce n'est pas nécessairement facile de s'en rendre compte.
Mon message c'est : si on ne conçoit pas avec les outils qu'on utilise mais contre eux, oui, "ajouter" l'accessibilité c'est coûteux, mais si on embrasse les technos conçues pour ça, ça se passe déjà beaucoup mieux.
J'espère que je me trompe et que j'ai une vue trop réduite du monde du développement frontend.
Tout cela étant dit, bien sûr, tant que ce n'est pas testé (avec des lecteurs d'écrans, etc), on ne peut pas être sûr que ça fonctionne bien donc il y a des coûts dont on ne peut pas se passer si on veut être sûr d'être accessible.
[^] # Re: Nextcloud Talk + Coturn
Posté par raphj . En réponse au lien Quel logiciel de visioconférence utiliser ?. Évalué à 9. Dernière modification le 26 janvier 2022 à 23:18.
Le README de JVB semble dire l'inverse :
À priori, un·e participant·e n'envoie qu'un flux vers le serveur, et le serveur dispatche le flux à chaque autre participant·e. C'est heureux que le flux ne soit envoyé qu'une fois, les connexions domestiques sont quand même souvent asymétriques et limitées en montant.
D'ailleurs, petite anecdote : à Algoo, pendant la mise en place de Visiocall (service basé sur Jitsi Meet, appelé Suricate TV à l'époque - on vient de faire le changement, il manque encore du branding sur cette instance), la veille du premier confinement, au cours des tests quand ce composant n'était pas encore en place, on observait ça :
Quand ce composant était en place :
On suit et surveille actuellement les dernières versions de Jitsi : ça a beaucoup évolué depuis début 2020, où, il faut le reconnaître, ça pouvait déconner selon le navigateur utilisé (en particulier Firefox). Maintenant ça marche quand même bien indépendamment du navigateur et il y a plein de fonctionnalités bien cool, et notamment parce que des fonctionnalités nécessaires à la gestion des flux vidéos ont été implémentées dans Firefox et des bugs corrigés dans Jitsi Meet. On se tape quelques barres avec les réactions par émojis (la réaction « criquets » quand personne ne répond à une question en réunion a toujours son petit effet), et les fonds personnalisés… l'intégration avec Etherpad est top également.
Bref, Jitsi Meet est un outil formidable, je suis plutôt fan.
Avec la dernière version, on observe un petit soucis où parfois, un·e participant·e perd le son de quelqu'un d'autre. Un rafraîchissement de la page permet de remettre les choses dans l'ordre. Problème qui sera, espérons-le, bientôt corrigé. L'équipe derrière Jitsi est réactive et très sympathique.
# Google conscient des pauvres entreprises dans le besoin
Posté par raphj . En réponse au lien Google remplace le FLoC par Topics. Évalué à 3. Dernière modification le 26 janvier 2022 à 20:58.
Sens réel :
"Chez Google, la publicité est au centre de notre modèle économique et ne comptons pas changer ça maintenant"
Eeeeehhh, faut vraiment être attentif en lisant internet de nos jours.
(oh oh alerte au bullshit, alerte au bullshit les enfants!)
[^] # Re: Visuels curieux
Posté par raphj . En réponse au lien Qt propose d'intégrer de la publicité dans les applications. Évalué à 10.
Je ne comprends pas le moinsage sur ce message.
Il y a un large recoupement entre les gens sensibles aux logiciels libres, ceux qui sont sensibles à la vie privée et ceux qui sont opposés au publicité, mais il n'y a qu'a faire un tour sur F-Droid pour se rendre compte qu'il y a des applications libres qui embarquent de base de la pub (et qui est retirée sur la version F-Droid, parce qu'en général c'est du code proprio qui s'en charge).
[^] # Re: KDE
Posté par raphj . En réponse au lien Qt propose d'intégrer de la publicité dans les applications. Évalué à 5.
En tant qu'utilisateur de KDE, j'ai largement confiance dans le projet KDE pour ne pas mettre de la pub dans leur environnement de bureau ou leurs applications.
…et sinon, dans des distributions comme Debian pour retirer ces pubs.
D'ailleurs, je ne sais pas même pas si ce module permettant d'intégrer de la pub Qt est libre ?
J'ai mollement cherché et rien trouvé dans la page liée. Je ne compte pas utiliser ça, ni des applications qui l'utiliserait.
[^] # Re: Visuels curieux
Posté par raphj . En réponse au lien Qt propose d'intégrer de la publicité dans les applications. Évalué à 4.
Mais Qt est un intermédiaire, non ? Ils prennent une commission, ou un truc du genre ?
C'est ce que je comprends de cette illustration : https://www.qt.io/hubfs/qt-da-platform-2.png
Bien sûr les logiciels décident ou pas d'utiliser cette plateforme publicitaire, mais la bibliothèque Qt sera financée en partie par ça.
# Visuels curieux
Posté par raphj . En réponse au lien Qt propose d'intégrer de la publicité dans les applications. Évalué à 7.
C'est très fake. Ça ne donne pas une image souhaitable, ou réaliste des humains. Mais bon, je suppose que ça fait l'affaire.
Espérons que ça facilite le travail des bloqueurs de pub d'avoir un endroit central par lequel les pubs transitent.
Et donc Qt va être financé par / dépendre du monde publicitaire ? Je ne peux pas dire que ça m'enchante énormément.
[^] # Re: Un truc bien sur Hacker News
Posté par raphj . En réponse au journal La rubrique liens doit-elle être un copier/coller de Hacker News (de ycombinator). Évalué à 7. Dernière modification le 06 janvier 2022 à 00:29.
Ça fonctionne quand même plutôt bien en général. Ils sont parfois édités pour être rendus moins accrocheur.
Je trouve ça plutôt bien, je suis déjà tombé sur un lien LinuxFr dont le titre m'a beaucoup surpris.
On peut toujours laisser un commentaire pour le contexte.
Sur HN, il y a aussi une moulinette qui fait quelques petites éditions automatique, pour le coup je ne suis pas sûr de la pertinence de ce mécanisme.
J'aime bien aussi la règle qui demande de mettre l'année entre parenthèse quand le document n'est pas de l'année actuelle.
[^] # Re: Sci-Hub
Posté par raphj . En réponse à la dépêche Revue de presse de l'April pour la semaine 52 de l'année 2021. Évalué à 5.
« Salut salut, t'as deux minutes ? »
-- Une personne portant une casquette marquée « Elsevier », signant la fin du projet en 6 mots
[^] # Re: Y'a deux sortes de sysadmins...
Posté par raphj . En réponse au lien L'université de Kyoto perd 77 To de données de recherche à la suite d'une erreur de sauvegarde. Évalué à 3.
Ah… la tristesse. Au moins, ça décrasse les circuits empruntés par l'adrénaline.
C'est parfois vrai aussi sur les touches des claviers tactiles des téléphones dans les discussion instantanées.
Heureusement, la seule connerie qui me soit arrivée c'est d'envoyer ":-(" au lieu de ":-)" et je m'en suis rendu compte tout de suite (oui, parce que "(" et ")" sont aussi généralement à côté sur ces claviers).