raphj a écrit 1627 commentaires

En l'occurrence l'antenne était branchée dans les cas que je mentionne (justement). Mais ça peut marcher aussi sans, mes cousines qui aimaient regarder la télé n'avaient pas l'antenne et ça marchait pour elles.

Ma plus grande peur je pense avec les chaînes serait l'exposition aux pubs, mais comme pour le contenu lui-même, un peu de prévention, d'explication, de clefs de lecture et de pédagogie font probablement l'affaire. Au final ça peut même probablement être "retourné dans le bon sens" en mode : "voilà ce qui existe dans la société, voilà ce qui est un peu moisi et ce à quoi il faut faire attention et d'ailleurs ça ce voit dans telle et telle pub, voilà ce qui est pas mal"…

Je ne trouve pas cette diabolisation des écrans justifiée finalement.

Mes parents limitaient un peu à ma sœur le temps passé devant la télé mais elle y passait quand même un peu de temps parce qu'elle aimait bien ça et aujourd'hui, tout va bien pour elle. Pour ma part, ils limitaient le temps passé à jouer aux jeux vidéos, mais ils ont rapidement compris que devant l'ordi je programmais surtout (d'ailleurs c'est eux qui m'ont lancé) et ça ils ne limitaient pas et heureusement, je pense. Je crois que ça va pour moi aussi.

Au lycée, je connaissais des gens dont les parents restreignaient vachement les choses, y compris pas de télé. Ils étaient souvent très bons et très studieux mais pas toujours très heureux et épanouis.

Une de mes meilleures amies a passé beaucoup, beaucoup de temps devant la télé petite. Tout va très bien aussi pour elle. Sa culture télévisée l'a construite en partie. Heureusement que ses parents ne la limitait pas trop, elle n'aurait probablement pas été la même personne sinon. Bien sûr, ça ne marcherait peut-être pas comme ça pour tout le monde.

Perso, j'avais ce biais de "regarder trop la télé = le mal", mais j'en reviens. La vérité est ailleurs. Il y a tout un contexte et il faut certainement adapter au cas par cas en fonction des goûts et du caractère de chaque enfant et probablement pas de règle évidente applicable partout.

Bref, trop d'écran peut probablement faire des dégâts, mais trop de diabolisation des écrans ou de restrictions plus généralement en fait clairement.

(tant mieux que les choses aient fonctionné pour tes enfants bien entendu !)

Un peu. Je programmais plutôt sur l'ordi, mais je suis particulièrement content d'avoir introduit un camarade du lycée à la programmation grâce à cette calculatrice, en math quand on avait fini les exercices avant les autres. Il avait fini par faire des trucs chiadés vu les limitations du ti-basic.

Faudrait presque faire comme certains systèmes de rapport de bogues, afficher les contenus potentiellement similaires / doublons en fonction du titre et du lien saisis :-P

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.

OpenSuse ne s'appuie sur aucune distribution "communautaire"

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.

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).

J'ai bien sûr pensé à ma Ti 83+ pour ma part.

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.

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]…

1. https://pine64.com/product/rockpro64-4gb-single-board-computer/
2. https://pine64.com/product-category/rock64/

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.

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.

Ç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. 🙃

Ç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/

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.

Ça risc.

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)

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.

• La doc : https://tour.dlang.org/tour/en/gems/scope-guards
• La page du livre Programmer en D : http://ddili.org/ders/d.en/scope.html

La doc vend cette fonctionnalité comme un remplacement de RAII en C++ :

The D scope feature effectively replaces the RAII idiom used in C++ which often leads to special scope guard objects for special resources.

Scope guards are called in the reverse order they are defined.

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.

Le README de JVB semble dire l'inverse :

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.

nous sommes conscients que de nombreuses entreprises ont besoin de la publicité pour exister

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!)

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).

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.

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.