Ah oui, ce que je mets en place dans cette dépêche c'est l'inverse : j'ai des enceintes qui ne font pas bluetooth, et la tablette se comporte comme une enceinte bluetooth.
Mais je suppose que le montage que je fais est le même.
Toi avec tes enceintes bluetooth tu n'as pas besoin de faire ça finalement :-)
L'onglet actualités de Duck Duck Go est quasi inutilisable à cause de MSN. Souvent, le résultat cite le journal source, mais quand on clique, en fait c'est un lien MSN. La page n'affiche pas le résultat, pour une raison ou une autre. Je n'accepte pas les cookies, je n'active pas JavaScript par défaut (et MSN est typiquement le genre de site pour lesquels je bloqué JavaScript). C'est peut-être pour ça, mais tout fonctionne sur les sites orignaux. Et puis bon, si on trouve l'info sur un site, il n'y a aucune raison pour que le moteur de recherche nous amène ailleurs.
C'est probablement une des causes les plus communes de mes abandons de recherches.
Pour le GPS, n'y a-t-il pas beidu, galileo, glonass qui devraient rendre une coupure du GPS plus ou moins invisible ?
Pour les DNS, ne pourrions nous pas repartir des services non américains existants ? Je veux bien croire que ça mettrait le bazar mais deux ans ça me parait une éternité.
J'ai l'impression qu'on pourrait même réussir à réadresser 1.1.1.1, 8.8.8.8 et leurs copains localement pour les appareils qui hardcodent ces DNS.
Pour 3, je suppose que partir de linux mobile serait la solution la plus pragmatique pour le coup.
C'est ma lecture : systemd apporte des fonctionnalités dont Gnome a besoin. Alors, au lieu de les réimplémenter en mal, le projet réutilise direct ce qui existe et est maintenu. De plus, sur les OS utilisant systemd, ça évite d'avoir plusieurs implémentations d'un même truc qui ont des comportements différents / incohérents.
À charge des OS n'utilisant pas systemd d'importer juste les briques systemd nécessaires quand c'est possible / modulaire, ou de réimplémenter les fonctionnalités pour les fournir à Gnome.
Ce qui est embêtant c'est que du point de vue de quelqu'un qui maintient un OS sans systemd, des choses fournies par GNOME ne le sont plus, et c'est donc des choses que l'OS doit maintenant fournir.
Mais je ne crois pas qu'il y ait de reproche à faire au projet systemd : il fournit des fonctionnalités liées au cœur du système, que les projets en espace utilisateur choisissent d'utiliser. systemd est un standard de facto, et aussi de plus en plus gros. C'est clair que c'est frustrant pour les gens qui développent des systèmes alternatifs, mais en même temps faut bien que ces fonctionnalités vivent quelque part aussi.
Il y a des fonctionnalités qui doivent vivre quelque part entre le noyau / le système de base et l'environnement de bureau, parce que ces fonctionnalités sont indépendantes de l'environnement de bureau mais trop haut niveau pour être dans le noyau ou dans le système de base. Et cet endroit, aujourd'hui, c'est systemd.
Je ne vois pas trop d'alternative à ça. On pourrait imaginer des briques indépendantes, mais fatalement on voudra certainement faire un paquet plus ou moins standard de ces briques indépendantes, et pourquoi pas unifier un peu les pratiques, mais ça, c'est tout comme systemd.
En réalité, derrière "Gnome dépend de plus en plus de systemd", faudrait lire "Gnome dépend des modules X, Y et Z de systemd, et ces modules sont de plus en plus nombreux". Les alternatives n'ont pas besoin d'être systemd, elles ont besoin de fournir X, Y et Z. Après c'est sûr qu'à force, on se retrouve à réimplémenter systemd au complet et à être piégé dans sa conception, mais j'ai du mal à voir une alternative à ça. Faut bien que les trucs dont dépendent les environnements de bureau vivent quelque part. Ou sinon, chaque environnement doit réimplémenter ces trucs, ça ne me semble pas très malin non plus.
Évidemment ma vision est biaisée, j'utilise (et j'aime bien) systemd, bon je n'utilise pas Gnome par contre. J'utilise KDE et je ne sais pas à quel point KDE dépend de systemd.
Je serais intéressé par lire quelqu'un qui aurait des idées pour éviter les problèmes que tout ça soulève.
J'ai été agréablement surpris de voir qu'ils ont bien la fonctionnalité lecture bluetooth, mais il semblerait que la fonctionnalité lecture Bluetooth est dans la version premium qui est payante (7,49€/mois). Cette version contient des intégrations à des service proprio et je suppose que ces intégrations sont proprio. Je préfère me concentrer sur les solutions complètement libres.
Par ailleurs, je ne suis pas un grand fan du modèle opencore. Cela dit, c'est peut-être payant mais libre, je n'ai pas pu trouver l'info en quelque clics. Par contre, je salue l'utilisation des termes "free software" plutôt qu'open source dans leur comm'.
Plus généralement le prêt à l'emploi est une bonne chose, c'est bien que ça existe pour qui n'a pas envie de bidouiller.
Il y a pas mal de solutions prêtes à l'emploi proposées dans les commentaires, et je pense que ça pourrait valoir le coup d'organiser une dépêche dans laquelle ces solutions sont présentées et comparées plus en détails :-)
Note pour la personne lisant ton commentaire qui voudrait peut-être démarrer ce chantier : ça pourrait commencer par les paquets d'une installation minimale de Debian.
Mais je crois que le plus dur c'est plutôt de trouver des gens pour sponsoriser ces temps pleins.
Le premier c’est x2x : j’ai de la continuité de clavier/pointeur entre deux machines, et c’est grâce à la transparence de X11, et qui pour le coup n’a pas besoin de beaucoup de débit ! Ça marche du tonnerre (et en IPv6-only aussi pour mon cas, pour un « vieux » soft je trouve ça génial : il a été codé à l’époque où on se souciait réellement du réseau). J’imagine qu’un équivalent pourrait exister avec de l’USB over IP ou un autre truc complexe, mais là ça roule simplement.
Il semblerait que ça soit possible avec https://github.com/input-leap/input-leap (retrouvé via https://github.com/dottedmag/x2x/issues/18, pas testé). Le partage du clipboard ne fonctionne pas encore d'après le README par contre (mais j'imagine que c'est implémentable, on peut partager le clipboard avec KDE connect entre un appareil Android et un appareil Linux donc il n'y a pas de raison).
Le deuxième, c’est l’export de display entre une VM et un hôte, où le débit et la latence sont tellement bons qu’on ne se rend pas compte de la « lourdeur » de X11 : j’ai déjà fait des vidéos Youtube au moins en FHD sans problème comme ça ! Toujours en 100% IPv6 aussi.
J'imagine que waypipe permettrait cela, et sinon, il y a toujours XWayland qui devrait permettre ça sous Wayland aujourd'hui (et du coup oui, on se retrouve à utiliser la transparence réseau de X sous Wayland, avec une partie des problèmes que dépendre de X cause). En fait, j'ai
Un autre cas que j’ai très peu expérimenté, mais qui m’a impressionné un jour : avec xpra, qui offre une vue Web, où je peux passer mes fenêtres de ma machine locale (avec xpra en proxy) pour les déplacer « sur le Web » pour les partager avec quelqu’un. Même si le truc n’est pas complètement léché, c’est vraiment super bien travaillé côté xpra.
Mais bon pour le coup, tu vas me dire qu’on fait des choses similaire avec du VNC ou autre protocole du genre. Mais pas de manière aussi « seamless » pour moi.
Ouais, non, ce serait plus malin de suggérer des choses équivalentes. Si ce n'est pas aussi « seamless », c'est qu'on a perdu quelque chose. En l'occurrence, j'ai l'impression qu'on peut retrouver ces fonctionnalités, mais je reconnais que ça demande du travail qui n'a pas encore été fourni. Et que dans l'état actuel, il y a bien des choses possibles sous X qui ne sont pas possibles sous Wayland.
une autre tare rhédibitoire de Wayland, que de ne pas être construit autour du réseau et de régresser sur des cas d'usage dont j'aurais du mal à me passer
Pour moi, c'est bien que les choses soient optimisées pour le cas d'usage commun et actuel : local, applications qui balancent de toute façon du raster à gogo.
Même sous X, l'architecture réseau, avec dessin à l'aide de primitives vectorielles, elle est très souvent bypassée : les toolkits font des gros rendus raster et balancent ça à X, voire directement au GPU. La conception Wayland part de ce constat.
La bonne exigence n'est pas l'architecture réseau ou la transparence réseau, mais le fait que ça puisse fonctionner en réseau (peu importe comment).
Et là, à priori, il y a des manières de faire fonctionner ça sous Wayland :
avec un truc style Waypipe (que j'ai jamais essayé)
ssh -X (que j'utilise toujours par habitude et parce que ça fonctionne suffisamment bien pour mes usages). Sous X11 comme sous Wayland, ça fonctionne toujours !
Ça fait plus de dix ans maintenant que le GUI par réseau avec X, c'est comme RDP/VNC en moins efficace mais en fenêtré et avec un peu d'intégration. Il n'y a absolument pas besoin d'une transparence réseau pour ça, en fait tu auras plus vite fait d'avoir une solution qui propose un streaming efficace.
Et force est de constater qu'au contraire, l'architecture réseau de X, c'est elle la tare vu les usages actuels. Elle est overkill pour la majorité des usages (en local), et inefficace pour la plupart des usages où elle a du sens (quand elle est utilisée effectivement en réseau). Autrement dit : elle est inefficace pour tous les usages, à un epsilon près.
On afficherait en réseau des applications Motif ou écrites directement en X11, je ne dirais pas, mais plus personne ne fait ça.
Aussi, il y a un côté "séparation des problèmes" : affichage à l'écran d'un côté, transmission réseau de l'autre. Si tu as besoin d'un affichage en réseau, tu peux assembler les deux briques qui font chacune une chose et bien, au lieu de dépendre d'un truc trop complexe qui fait tout mal.
tl;dr: le cas d'usage est répondu sous Wayland, on s'est débarrassé d'une architecture qui n'est plus adaptée, je ne vois pas ce qui est rédhibitoire et de quoi on devrait se plaindre de ce côté.
et également merci à Christophe pour la mention de PiGallery2.
Je vais probablement me servir de tout ça comme source d'inspiration.
Ça tombe à pic : je suis justement en train de me préparer pour un petit voyage où je compte partager mes photos depuis un blog avec une carte interactive. Et je suis en train de programmer un truc pour ça, avec un peu de chance j'aurai fini à temps. Ça tombe tellement à pic que je me suis un instant demandé si je n'allais pas jeter une semaine de travail pour reprendre l'idée de ce journal telle quelle. Mais je vais persister.
Je n'ai pas nécessairement besoin de traces GPX (mais ce serait chouette de l'avoir), par contre l'idée serait d'avoir des articles de blog (des "étapes") dans lesquelles il y a des photos.
Sans Javascript, le site statique généré ressemblerait à un blog classique, mais avec Javascript, le visiteur pourra se balader sur une carte et dans une visionneuse, dans l'esprit « progressive enhancement » le plus fidèle. La visionneuse devrait permettre de se balader dans les descriptions et d'afficher les photos, avec une option pour rester dans la même étape ou pour traverser la visite entière. Les photos seront affichées avec un petit descriptif s'il est fournit.
Un flux RSS serait généré pour que les deux seules personnes au monde avec un lecteur RSS puissent être notifiées des mises à jour.
Le site serait généré à partir d'un dossier Nextcloud partagé publiquement (c'est du WebDAV très standard derrière, mais Nextcloud génère aussi des miniatures et je compte réutiliser ça au moins dans un premier temps). Un bouton importer irait interroger le dossier et stocker les infos dans une petite base SQLite à partir de laquelle le blog serait généré. Seuls les fichiers changés seraient réévalués, c'est aussi là que la base SQLite est justement utile, mais restant "sobre" comme le dit l'article.
Le dossier partagé contiendrait des fichiers Markdown avec front matter qui décrivent ces fameuses étapes, très compatible avec ce qu'attendrait un générateur de sites statiques tel qu'Hugo. Ces fichiers Markdown afficheraient des photos et ces photos peuvent contenir des données GPS. Dans le front matter des étapes, on pourrait définir une date, une localisation gps, voire un noeud OSM. Les localisations GPS des images seraient récupérées mais pourraient aussi être spécifiés dans les fichiers d'étape : ça permettra d'ajouter les localisation à la main directement dans le fichier d'étape sans devoir utiliser des outils complexes ou en ligne de commande, quitte à ajouter les localisations aux fichiers eux-mêmes dans un second temps.
Et par défaut, si la localisation manque pour une photo, c'est la localisation de l'étape qui sera utilisée, donc ça pourra ne pas être trop fastidieux au pire.
Nextcloud ayant un éditeur Markdown WYSIWYG, ou le dossier pouvant être synchronisé sur un appareil doté de l'éditeur markdown de son choix, le tout serait utilisable par quelqu'un qui n'est pas technique. Je le sais déjà, j'ai déjà un site de recettes reposant sur un système comme ça, mis à jour avec succès par quelqu'un d'autre que moi. Et si l'outil venait à disparaitre, le blog ne disparaîtrait pas avec puisqu'il serait entièrement consultable avec n'importe quel éditeur Markdown standard.
J'étais resté sur MPD en me disant qu'il serait bien plus léger, étant écrit en C, et ne nécessiterait pas de configurer un serveur web, et qu'il serait toujours temps de passer à Mopidy avec sa compatibilité MPD quand le besoin s'en ferait sentir, mais si avec Mopidy c'est simple de lancer une lecture depuis YouTube (par exemple, pour lire à la suite un truc demandé ou mentionné par un·e invité·e), ça permettrait quelque chose que je n'ai pas actuellement. L'interface web accessible sans rien installer, ça serait un gros plus aussi. Ça permettrait de confier les commandes « DJ » aux invités le plus simplement possible, ça peut être très cool.
Un comparatif entre mpd et ce couple squeezelite / lms serait intéressant, je vois que vous êtes pas mal dans les commentaires à utiliser ça.
Je ne suis pas campé sur MPD, mais il me faudrait une motivation claire pour aller essayer squeezelite / lms. MPD est hyper léger et il n'y a besoin que d'un démon, là il faudrait que je le remplace par deux solutions (mais je comprends bien l'architecture, c'est propre de séparer les problèmes, ça me va). La convivialité peut être un point fort qui pourrait me convaincre. Avec MPD on peut imaginer des clients très agréables et simples d'utilisation, bien sûr il faut qu'ils existent et peut-être que lms l'a déjà.
Le multiroom est clairement un bon point, à priori c'est possible pour MPD avec Snapcast aussi.
3,69€ c'est pas la ruine
Plus que le coût monétaire, mon frein c'est plus que je mets un point d'honneur à n'utiliser que des logiciels libres (mais lire l'audio sur un téléphone n'est pas un besoin actuel, ça pourrait le venir si je récupère un vieux téléphone et que j'ai soudainement l'utilité d'une installation multiroom et le matos qui le permet).
Je ne comprends pas bien, aujourd'hui le copier coller par sélection / clic du milieu sous Wayland semble fonctionner partout à la perfection. Ce n'était pas le cas au début et c'était un gros frein pour moi. Et c'est tellement ancré en moi que c'est pénible quand je suis amené à utiliser OS alternatif qui n'a pas la fonctionnalité.
(sous KDE en tout cas, y compris entre les différents toolkits)
Si encore le clic droit donnait accès à des fonctions avancées comme supprimer le formatage, transposer une liste, remplacer les tab à la volée par des espaces… mais, non, rien de tout ça :/
C'est une piste intéressante mais qui ne vient pas sans son lots d'inconvénients.
en plus ce serait beaucoup plus rapide.
Pas clair :
le système est déjà suffisamment rapide à l'exécution, et le temps de lire le système entier depuis le SSD pour le mettre dans la ram puis le booter risque d'allonger le temps de démarrage (le SSD de cette tablette est assez lent à la lecture et le CPU pour la décompression d'une image compressée éventuelle est potentiellement un peu long). Ici, le temps de démarrage est plus important que la vitesse d'exécution après démarrage vu qu'elle est suffisante, donc "contre intuitivement", on peut y perdre en praticité, parce qu'on risque de devoir attendre plus longtemps avant de pouvoir utiliser l'ensemble
avec le fait que le noyau met en cache les trucs souvent accédés, les accès lectures sont déjà potentiellement limités
Bon, faudrait mesurer tout ça et il y a peut-être moyen d'être malin pour quand-même y gagner.
Par ailleurs, on veut garder l'état de mpd à tout moment donc cette partie doit rester hors de la ram, donc ça complexifie l'installation.
Avec noatime, je crois que la source d'écritures la plus conséquente qu'on pourrait vouloir éviter (avec une petite étoile et note de bas de page quand-même) est probablement les journaux.
Ça doit pouvoir se faire avec https://unifiedpush.org/ pour celles et ceux qui seraient intéressés par cette solution et qui voudraient une solution libre pour ça.
Pour ma part, je préférerais que le système ne dépende pas de ma présence ou de celle de mon téléphone.
J'ai juste un bouton power sur cette tablette. Il y a aussi un capteur qui permet de faire touche du bas sur appui court et entrée sur appui long qui fonctionne dans le bios et dans Grub mais plus après. Il y a peut-être moyen de l'utiliser. Ou le capteur de lumière :-) D'ailleurs c'est peut-être le même capteur.
On pourrait avoir le bluetooth allumé en permanence mais n'accepter que les nouvelles connexions pendant quelques secondes après l'appui de ce capteur. Un son pourrait être joué à ce moment. En fait, on obtiendrait un comportement très similaire aux enceintes Bluetooth du marché et c'est ce qui me parait le plus simple à mettre en place et aussi le plus pratique à utiliser.
Je ne connaissais pas. Ça a l'air de se baser sur Squeezebox server.
Pourquoi pas en effet ! Les pré-requis matériels seraient remplis ; architecture x86 32 bits, au moins 512M de ram, on est bons.
J'aime bien avoir un système standard et adaptable, et je suppose que la solution clé en main m'aurait freiné (notamment la partie bluetooth, j'imagine que daphile ne propose pas ça par défaut, et tout ce qui est extinction d'écran, etc), mais je suis prêt à me laisser surprendre et c'est chouette que des solutions clé en main existent. Toutes les bidouilles que je décris, ça pourrait être cool que ça soit clé en main et qu'il n'y ait pas besoin de suivre toutes ces étapes d'admin sys pour y arriver, et je suppose qu'un truc comme daphile est une bonne réponse à ça.
Je ne vais pas mettre ces choses en place, je le sais déjà. Ça ne me dérange pas de me connecter en ssh et de lancer une mise à jour. Et la sécurité ne m'inquiète pas trop. De toute façon si elle travaille trop elle va souffler et ça va me gêner, et je vais aller voir ce qu'il se passe.
Par contre, cette histoire d'affichage de chiffres pour l'appairage, je n'ai pas le temps mais ça m'intéresse bien. Je pensais aussi que je pouvais faire lire les chiffres en audio (la tablette est un peu planquée, devoir aller la sortir c'est moyen commode. Avec une lecture sonore, si on est installés au salon, ça pourrait se faire à distance.
ok pigé ! Merci pour les pistes, en effet ce serait bien d'avoir cet affichage des chiffres ! Je ne savais pas qu'on pouvait faire ça.
Si ça tente quelqu'un, n'hésitez pas à lancer quelque chose, et sinon j'y viendrai peut-être dans quelques mois.
Merci pour les pistes !
Sinon oui, un petit ufw sur la tablette ça ne mange pas de pain. Tout bloquer sauf les ports d'avahi, de samba, de mpd et de ssh. Mais j'espère que mon wifi n'est pas compromis xD
1) pourquoi utiliser Samba pluto que NFS vu que tu as a priori tout en Linux
Nope, ce n'est pas le cas !
Et quand bien même, il me semble que mettre en place un point de montage NFS n'est pas aussi simple qu'accéder à un dossier réseau SMB. Tu peux te connecter en SMB avec une simple adresse depuis la plupart des gestionnaires de fichiers répandus. Pour nfs, il faut aller lancer un mount, ou ajouter une ligne à /etc/fstab ou utiliser l'équivalent systemd en espérant que ça ne mette pas la pagaille au démarrage si le dossier n'est pas accessible (parce que je ne suis pas chez moi, parce que la tablette est éteinte, etc. Ou aller chercher des solutions style automount.
Là, avec Samba, pas de configuration : le dossier est découvrable grâce à Avahi, il n'y a plus qu'à double cliquer.
Donc même pour quelqu'un qui est uniquement sous linux, pour cet usage, Samba est probablement la meilleure solution.
Pour un dossier réseau permanent et stable et un peu indispensable sur un poste de travail qui ne bouge pas, NFS est probablement la meilleure solution.
La question alternative serait : qu'apporte NFS par rapport à Samba dans ce cas d'utilisation ? Note que je ne veux pas de gestion de droits, l'absence d'ACL est une fonctionnalité.
2) pourquoi MPD ?
Je connaissais et ça répondait au besoin :-)
Un ordi central qui joue de la musique, contrôlable par des clients quand il y a besoin mais qui se débrouille tout seul sinon (fonctionne sans client connecté). Une installation légère.
a la maison j utilise lyrion media center (vu que j ai des squeezebox c est obligatoire pour moi)
Je ne connaissais pas, ça a l'air pas mal !
J'ai l'impression que c'est un peu différent de ce que fait mpd : tu héberges une médiathèque sur ton serveur, et l'audio est joué sur le client.
Ce qui m'intéresse c'est que ça soit le serveur qui joue l'audio. L'audio ne traverse pas le réseau. Autrement dit, je n'ai pas besoin d'une médiathèque en réseau, mais d'un lecteur de musique contrôlable par le réseau.
mais je suggérerais d'allumer l'écran pour afficher le code pin à rentrer, ça serait mieux
Oui, et un moyen de dire oui sur la tablette. Présenter un bouton sur lequel on peut taper (vu que l'écran est tactile). Pour le coup sur un vieux netbook doté d'un clavier, ce serait plus simple.
Donc il faut démarrer un serveur d'affichage
Par contre, ça suppose que la machine n'est pas en veille…
C'est exact.
Faudrait sans doute faire un truc à base de rtcwake pour le reveil et de /etc/pm/sleep.d pour l'appeler avant la mise en veille
Utiliser RTC pour ça, c'est une bonne idée !
Effectivement, si tu laisses du bluetooth ouvert à tous, du samba ouvert à tous aussi, et du wifi pour couronner le tout, t'as intérêt à bien garder les logs ;-)
Yes. Après, le Bluetooth n'est ouvert qu'en audio, et côté wifi, c'est quand même derrière un firewall qui garde le réseau local isolé. Hors de question d'ouvrir tout ça plus largement :-)
On pourrait ajouter des alertes (débit / connexions réseau (on ne s'attend pas à avoir beaucoup de connexion entrantes, très peux sortantes, pas de gros débits), utilisation CPU (pas supposé tourner fort pendant très longtemps).
il doit y avoir des coûts d'intégration de l'OS à la machine. Là, je m'attends à ce qu'il y ait le même genre de coûts pour Windows ;
l'appareil est noté comme officiellement supporté sur cette page, donc il doit y avoir un partenariat entre Valve et Lenovo pour ça. Il y a certainement des gens payés côté Valve, Lenovo ou les deux pour s'assurer que l'OS marche bien sur la machine. Je ne sais pas à quel point c'est plus ou moins coûteux que s'assurer que Windows tourne sur la machine.
Et peut-être qu'il y a en effet des accords pour utiliser les marques de Valve.
Ouais, j'ai l'impression que la différence matérielle justifie entièrement cette différence de prix.
Ça aurait été pas mal de comparer ce qui est comparable. Je suis content de lire que Linux a plus d'autonomie et est plus fluide que Windows, mais pour l'autonomie c'est peut-être juste que le matériel consomme moins. Pour la fluidité, par contre, si Linux est meilleur sur du matériel moins puissant, ça doit dépoter sur la version plus costaud.
[^] # Re: Bon anniversaire
Posté par raphj . En réponse à la dépêche Vingt-sept ans de LinuxFr.org. Évalué à 3 (+1/-0).
La galanterie est une forme de sexisme, alors bon débarras :-)
[^] # Re: Ou, accessoirement, tu peux utiliser Owntone
Posté par raphj . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 3 (+1/-0).
Ah oui, ce que je mets en place dans cette dépêche c'est l'inverse : j'ai des enceintes qui ne font pas bluetooth, et la tablette se comporte comme une enceinte bluetooth.
Mais je suppose que le montage que je fais est le même.
Toi avec tes enceintes bluetooth tu n'as pas besoin de faire ça finalement :-)
[^] # Re: Ou, accessoirement, tu peux utiliser Owntone
Posté par raphj . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 2 (+0/-0).
Ça a l'air vraiment bien ! Merci pour le partage.
Tu confirmses pour le bluetooth ? Je ne vois rien dans leur doc là dessus.
# L'onglet actualité de DDG
Posté par raphj . En réponse au lien MSN de Microsoft est la poubelle du Web. Évalué à 3 (+1/-0). Dernière modification le 23 juin 2025 à 14:16.
L'onglet actualités de Duck Duck Go est quasi inutilisable à cause de MSN. Souvent, le résultat cite le journal source, mais quand on clique, en fait c'est un lien MSN. La page n'affiche pas le résultat, pour une raison ou une autre. Je n'accepte pas les cookies, je n'active pas JavaScript par défaut (et MSN est typiquement le genre de site pour lesquels je bloqué JavaScript). C'est peut-être pour ça, mais tout fonctionne sur les sites orignaux. Et puis bon, si on trouve l'info sur un site, il n'y a aucune raison pour que le moteur de recherche nous amène ailleurs.
C'est probablement une des causes les plus communes de mes abandons de recherches.
[^] # Re: Mauvais article
Posté par raphj . En réponse au lien Trump can pull the plug on the internet, and Europe can't do anything about it. Évalué à 3 (+1/-0). Dernière modification le 23 juin 2025 à 14:04.
Pour le GPS, n'y a-t-il pas beidu, galileo, glonass qui devraient rendre une coupure du GPS plus ou moins invisible ?
Pour les DNS, ne pourrions nous pas repartir des services non américains existants ? Je veux bien croire que ça mettrait le bazar mais deux ans ça me parait une éternité.
J'ai l'impression qu'on pourrait même réussir à réadresser 1.1.1.1, 8.8.8.8 et leurs copains localement pour les appareils qui hardcodent ces DNS.
Pour 3, je suppose que partir de linux mobile serait la solution la plus pragmatique pour le coup.
# Raisonnable
Posté par raphj . En réponse au lien GNOME va dépendre de plus en plus de systemd. Évalué à 10 (+11/-2). Dernière modification le 11 juin 2025 à 17:08.
C'est ma lecture : systemd apporte des fonctionnalités dont Gnome a besoin. Alors, au lieu de les réimplémenter en mal, le projet réutilise direct ce qui existe et est maintenu. De plus, sur les OS utilisant systemd, ça évite d'avoir plusieurs implémentations d'un même truc qui ont des comportements différents / incohérents.
À charge des OS n'utilisant pas systemd d'importer juste les briques systemd nécessaires quand c'est possible / modulaire, ou de réimplémenter les fonctionnalités pour les fournir à Gnome.
Ce qui est embêtant c'est que du point de vue de quelqu'un qui maintient un OS sans systemd, des choses fournies par GNOME ne le sont plus, et c'est donc des choses que l'OS doit maintenant fournir.
Mais je ne crois pas qu'il y ait de reproche à faire au projet systemd : il fournit des fonctionnalités liées au cœur du système, que les projets en espace utilisateur choisissent d'utiliser. systemd est un standard de facto, et aussi de plus en plus gros. C'est clair que c'est frustrant pour les gens qui développent des systèmes alternatifs, mais en même temps faut bien que ces fonctionnalités vivent quelque part aussi.
Il y a des fonctionnalités qui doivent vivre quelque part entre le noyau / le système de base et l'environnement de bureau, parce que ces fonctionnalités sont indépendantes de l'environnement de bureau mais trop haut niveau pour être dans le noyau ou dans le système de base. Et cet endroit, aujourd'hui, c'est systemd.
Je ne vois pas trop d'alternative à ça. On pourrait imaginer des briques indépendantes, mais fatalement on voudra certainement faire un paquet plus ou moins standard de ces briques indépendantes, et pourquoi pas unifier un peu les pratiques, mais ça, c'est tout comme systemd.
En réalité, derrière "Gnome dépend de plus en plus de systemd", faudrait lire "Gnome dépend des modules X, Y et Z de systemd, et ces modules sont de plus en plus nombreux". Les alternatives n'ont pas besoin d'être systemd, elles ont besoin de fournir X, Y et Z. Après c'est sûr qu'à force, on se retrouve à réimplémenter systemd au complet et à être piégé dans sa conception, mais j'ai du mal à voir une alternative à ça. Faut bien que les trucs dont dépendent les environnements de bureau vivent quelque part. Ou sinon, chaque environnement doit réimplémenter ces trucs, ça ne me semble pas très malin non plus.
Évidemment ma vision est biaisée, j'utilise (et j'aime bien) systemd, bon je n'utilise pas Gnome par contre. J'utilise KDE et je ne sais pas à quel point KDE dépend de systemd.
Je serais intéressé par lire quelqu'un qui aurait des idées pour éviter les problèmes que tout ça soulève.
[^] # Re: Et les trucs tout prêt ?
Posté par raphj . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 4 (+2/-0).
Je ne connaissais pas, merci pour le partage !
J'ai été agréablement surpris de voir qu'ils ont bien la fonctionnalité lecture bluetooth, mais il semblerait que la fonctionnalité lecture Bluetooth est dans la version premium qui est payante (7,49€/mois). Cette version contient des intégrations à des service proprio et je suppose que ces intégrations sont proprio. Je préfère me concentrer sur les solutions complètement libres.
Par ailleurs, je ne suis pas un grand fan du modèle opencore. Cela dit, c'est peut-être payant mais libre, je n'ai pas pu trouver l'info en quelque clics. Par contre, je salue l'utilisation des termes "free software" plutôt qu'open source dans leur comm'.
Plus généralement le prêt à l'emploi est une bonne chose, c'est bien que ça existe pour qui n'a pas envie de bidouiller.
Il y a pas mal de solutions prêtes à l'emploi proposées dans les commentaires, et je pense que ça pourrait valoir le coup d'organiser une dépêche dans laquelle ces solutions sont présentées et comparées plus en détails :-)
[^] # Re: Vulnérabilité de projets cruciaux
Posté par raphj . En réponse au journal Sécurité de linux. Évalué à 2 (+0/-0).
Note pour la personne lisant ton commentaire qui voudrait peut-être démarrer ce chantier : ça pourrait commencer par les paquets d'une installation minimale de Debian.
Mais je crois que le plus dur c'est plutôt de trouver des gens pour sponsoriser ces temps pleins.
[^] # Re: wl-clipboard
Posté par raphj . En réponse au journal Enfin une utilité au presse-papier synchrone de X11. Évalué à 4 (+2/-0). Dernière modification le 04 juin 2025 à 09:20.
Il semblerait que ça soit possible avec https://github.com/input-leap/input-leap (retrouvé via https://github.com/dottedmag/x2x/issues/18, pas testé). Le partage du clipboard ne fonctionne pas encore d'après le README par contre (mais j'imagine que c'est implémentable, on peut partager le clipboard avec KDE connect entre un appareil Android et un appareil Linux donc il n'y a pas de raison).
J'imagine que waypipe permettrait cela, et sinon, il y a toujours XWayland qui devrait permettre ça sous Wayland aujourd'hui (et du coup oui, on se retrouve à utiliser la transparence réseau de X sous Wayland, avec une partie des problèmes que dépendre de X cause). En fait, j'ai
J'avais aussi été impressionné par xpra en jouant un peu avec et j'ai aucune idée si un truc comme ça existe sous Wayland actuellement. Je suppose que c'est implémentable ("We should be able to plug into wayland and provide remote access for it. Reading this freerdp implementation, it doesn't look too hard. The main difficulty may be in glueing the C api with our (mostly) python server code., donc ça n'a pas l'air d'être une impossibilité technique, mais je reconnais qu'il y a probablement pas mal de choses qui n'existent pas encore (l'écosystème n'est pas complet, même après 10 ans).
Ouais, non, ce serait plus malin de suggérer des choses équivalentes. Si ce n'est pas aussi « seamless », c'est qu'on a perdu quelque chose. En l'occurrence, j'ai l'impression qu'on peut retrouver ces fonctionnalités, mais je reconnais que ça demande du travail qui n'a pas encore été fourni. Et que dans l'état actuel, il y a bien des choses possibles sous X qui ne sont pas possibles sous Wayland.
[^] # Re: wl-clipboard
Posté par raphj . En réponse au journal Enfin une utilité au presse-papier synchrone de X11. Évalué à 4 (+2/-0). Dernière modification le 03 juin 2025 à 11:54.
Pour moi, c'est bien que les choses soient optimisées pour le cas d'usage commun et actuel : local, applications qui balancent de toute façon du raster à gogo.
Même sous X, l'architecture réseau, avec dessin à l'aide de primitives vectorielles, elle est très souvent bypassée : les toolkits font des gros rendus raster et balancent ça à X, voire directement au GPU. La conception Wayland part de ce constat.
La bonne exigence n'est pas l'architecture réseau ou la transparence réseau, mais le fait que ça puisse fonctionner en réseau (peu importe comment).
Et là, à priori, il y a des manières de faire fonctionner ça sous Wayland :
Ça fait plus de dix ans maintenant que le GUI par réseau avec X, c'est comme RDP/VNC en moins efficace mais en fenêtré et avec un peu d'intégration. Il n'y a absolument pas besoin d'une transparence réseau pour ça, en fait tu auras plus vite fait d'avoir une solution qui propose un streaming efficace.
Et force est de constater qu'au contraire, l'architecture réseau de X, c'est elle la tare vu les usages actuels. Elle est overkill pour la majorité des usages (en local), et inefficace pour la plupart des usages où elle a du sens (quand elle est utilisée effectivement en réseau). Autrement dit : elle est inefficace pour tous les usages, à un epsilon près.
On afficherait en réseau des applications Motif ou écrites directement en X11, je ne dirais pas, mais plus personne ne fait ça.
Aussi, il y a un côté "séparation des problèmes" : affichage à l'écran d'un côté, transmission réseau de l'autre. Si tu as besoin d'un affichage en réseau, tu peux assembler les deux briques qui font chacune une chose et bien, au lieu de dépendre d'un truc trop complexe qui fait tout mal.
tl;dr: le cas d'usage est répondu sous Wayland, on s'est débarrassé d'une architecture qui n'est plus adaptée, je ne vois pas ce qui est rédhibitoire et de quoi on devrait se plaindre de ce côté.
# Merci pour le partage
Posté par raphj . En réponse à la dépêche Photos et traces gps dans un blog statique. Évalué à 4 (+2/-0). Dernière modification le 02 juin 2025 à 16:55.
et également merci à Christophe pour la mention de PiGallery2.
Je vais probablement me servir de tout ça comme source d'inspiration.
Ça tombe à pic : je suis justement en train de me préparer pour un petit voyage où je compte partager mes photos depuis un blog avec une carte interactive. Et je suis en train de programmer un truc pour ça, avec un peu de chance j'aurai fini à temps. Ça tombe tellement à pic que je me suis un instant demandé si je n'allais pas jeter une semaine de travail pour reprendre l'idée de ce journal telle quelle. Mais je vais persister.
Je n'ai pas nécessairement besoin de traces GPX (mais ce serait chouette de l'avoir), par contre l'idée serait d'avoir des articles de blog (des "étapes") dans lesquelles il y a des photos.
Sans Javascript, le site statique généré ressemblerait à un blog classique, mais avec Javascript, le visiteur pourra se balader sur une carte et dans une visionneuse, dans l'esprit « progressive enhancement » le plus fidèle. La visionneuse devrait permettre de se balader dans les descriptions et d'afficher les photos, avec une option pour rester dans la même étape ou pour traverser la visite entière. Les photos seront affichées avec un petit descriptif s'il est fournit.
Un flux RSS serait généré pour que les deux seules personnes au monde avec un lecteur RSS puissent être notifiées des mises à jour.
Le site serait généré à partir d'un dossier Nextcloud partagé publiquement (c'est du WebDAV très standard derrière, mais Nextcloud génère aussi des miniatures et je compte réutiliser ça au moins dans un premier temps). Un bouton importer irait interroger le dossier et stocker les infos dans une petite base SQLite à partir de laquelle le blog serait généré. Seuls les fichiers changés seraient réévalués, c'est aussi là que la base SQLite est justement utile, mais restant "sobre" comme le dit l'article.
Le dossier partagé contiendrait des fichiers Markdown avec front matter qui décrivent ces fameuses étapes, très compatible avec ce qu'attendrait un générateur de sites statiques tel qu'Hugo. Ces fichiers Markdown afficheraient des photos et ces photos peuvent contenir des données GPS. Dans le front matter des étapes, on pourrait définir une date, une localisation gps, voire un noeud OSM. Les localisations GPS des images seraient récupérées mais pourraient aussi être spécifiés dans les fichiers d'étape : ça permettra d'ajouter les localisation à la main directement dans le fichier d'étape sans devoir utiliser des outils complexes ou en ligne de commande, quitte à ajouter les localisations aux fichiers eux-mêmes dans un second temps.
Et par défaut, si la localisation manque pour une photo, c'est la localisation de l'étape qui sera utilisée, donc ça pourra ne pas être trop fastidieux au pire.
Nextcloud ayant un éditeur Markdown WYSIWYG, ou le dossier pouvant être synchronisé sur un appareil doté de l'éditeur markdown de son choix, le tout serait utilisable par quelqu'un qui n'est pas technique. Je le sais déjà, j'ai déjà un site de recettes reposant sur un système comme ça, mis à jour avec succès par quelqu'un d'autre que moi. Et si l'outil venait à disparaitre, le blog ne disparaîtrait pas avec puisqu'il serait entièrement consultable avec n'importe quel éditeur Markdown standard.
Bref, à suivre.
[^] # Re: Bravo
Posté par raphj . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 3 (+1/-0). Dernière modification le 02 juin 2025 à 16:28.
J'ai vu Mopidy, faut que j'essaie ça.
J'étais resté sur MPD en me disant qu'il serait bien plus léger, étant écrit en C, et ne nécessiterait pas de configurer un serveur web, et qu'il serait toujours temps de passer à Mopidy avec sa compatibilité MPD quand le besoin s'en ferait sentir, mais si avec Mopidy c'est simple de lancer une lecture depuis YouTube (par exemple, pour lire à la suite un truc demandé ou mentionné par un·e invité·e), ça permettrait quelque chose que je n'ai pas actuellement. L'interface web accessible sans rien installer, ça serait un gros plus aussi. Ça permettrait de confier les commandes « DJ » aux invités le plus simplement possible, ça peut être très cool.
[^] # Re: Autre alternative pour Raspberry Pi
Posté par raphj . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 3 (+1/-0).
Ça a l'air pas mal, si je comprends bien c'est une distribution basée sur Debian avec MPD et une UI web sympa.
[^] # Re: bravo
Posté par raphj . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 5 (+3/-0).
ok, merci pour les infos !
Un comparatif entre mpd et ce couple squeezelite / lms serait intéressant, je vois que vous êtes pas mal dans les commentaires à utiliser ça.
Je ne suis pas campé sur MPD, mais il me faudrait une motivation claire pour aller essayer squeezelite / lms. MPD est hyper léger et il n'y a besoin que d'un démon, là il faudrait que je le remplace par deux solutions (mais je comprends bien l'architecture, c'est propre de séparer les problèmes, ça me va). La convivialité peut être un point fort qui pourrait me convaincre. Avec MPD on peut imaginer des clients très agréables et simples d'utilisation, bien sûr il faut qu'ils existent et peut-être que lms l'a déjà.
Le multiroom est clairement un bon point, à priori c'est possible pour MPD avec Snapcast aussi.
Plus que le coût monétaire, mon frein c'est plus que je mets un point d'honneur à n'utiliser que des logiciels libres (mais lire l'audio sur un téléphone n'est pas un besoin actuel, ça pourrait le venir si je récupère un vieux téléphone et que j'ai soudainement l'utilité d'une installation multiroom et le matos qui le permet).
[^] # Re: wl-clipboard
Posté par raphj . En réponse au journal Enfin une utilité au presse-papier synchrone de X11. Évalué à 8 (+6/-0).
Je ne comprends pas bien, aujourd'hui le copier coller par sélection / clic du milieu sous Wayland semble fonctionner partout à la perfection. Ce n'était pas le cas au début et c'était un gros frein pour moi. Et c'est tellement ancré en moi que c'est pénible quand je suis amené à utiliser OS alternatif qui n'a pas la fonctionnalité.
(sous KDE en tout cas, y compris entre les différents toolkits)
Ça serait badasse.
bien essayé, par contre xD
[^] # Re: Mettre ton système en Ram
Posté par raphj . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 4 (+2/-0). Dernière modification le 29 mai 2025 à 11:18.
C'est une piste intéressante mais qui ne vient pas sans son lots d'inconvénients.
Pas clair :
Bon, faudrait mesurer tout ça et il y a peut-être moyen d'être malin pour quand-même y gagner.
Par ailleurs, on veut garder l'état de mpd à tout moment donc cette partie doit rester hors de la ram, donc ça complexifie l'installation.
Avec noatime, je crois que la source d'écritures la plus conséquente qu'on pourrait vouloir éviter (avec une petite étoile et note de bas de page quand-même) est probablement les journaux.
[^] # Re: Fort intéressant !
Posté par raphj . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 2 (+0/-0). Dernière modification le 29 mai 2025 à 11:05.
Ça doit pouvoir se faire avec https://unifiedpush.org/ pour celles et ceux qui seraient intéressés par cette solution et qui voudraient une solution libre pour ça.
Pour ma part, je préférerais que le système ne dépende pas de ma présence ou de celle de mon téléphone.
[^] # Re: Fort intéressant !
Posté par raphj . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 3 (+1/-0). Dernière modification le 29 mai 2025 à 11:03.
Oui, c'est une bonne idée !
J'ai juste un bouton power sur cette tablette. Il y a aussi un capteur qui permet de faire touche du bas sur appui court et entrée sur appui long qui fonctionne dans le bios et dans Grub mais plus après. Il y a peut-être moyen de l'utiliser. Ou le capteur de lumière :-) D'ailleurs c'est peut-être le même capteur.
On pourrait avoir le bluetooth allumé en permanence mais n'accepter que les nouvelles connexions pendant quelques secondes après l'appui de ce capteur. Un son pourrait être joué à ce moment. En fait, on obtiendrait un comportement très similaire aux enceintes Bluetooth du marché et c'est ce qui me parait le plus simple à mettre en place et aussi le plus pratique à utiliser.
[^] # Re: Daphile?
Posté par raphj . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 3 (+1/-0).
Je ne connaissais pas. Ça a l'air de se baser sur Squeezebox server.
Pourquoi pas en effet ! Les pré-requis matériels seraient remplis ; architecture x86 32 bits, au moins 512M de ram, on est bons.
J'aime bien avoir un système standard et adaptable, et je suppose que la solution clé en main m'aurait freiné (notamment la partie bluetooth, j'imagine que daphile ne propose pas ça par défaut, et tout ce qui est extinction d'écran, etc), mais je suis prêt à me laisser surprendre et c'est chouette que des solutions clé en main existent. Toutes les bidouilles que je décris, ça pourrait être cool que ça soit clé en main et qu'il n'y ait pas besoin de suivre toutes ces étapes d'admin sys pour y arriver, et je suppose qu'un truc comme daphile est une bonne réponse à ça.
[^] # Re: Fort intéressant !
Posté par raphj . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 5 (+3/-0).
Eh eh.
Je ne vais pas mettre ces choses en place, je le sais déjà. Ça ne me dérange pas de me connecter en ssh et de lancer une mise à jour. Et la sécurité ne m'inquiète pas trop. De toute façon si elle travaille trop elle va souffler et ça va me gêner, et je vais aller voir ce qu'il se passe.
Par contre, cette histoire d'affichage de chiffres pour l'appairage, je n'ai pas le temps mais ça m'intéresse bien. Je pensais aussi que je pouvais faire lire les chiffres en audio (la tablette est un peu planquée, devoir aller la sortir c'est moyen commode. Avec une lecture sonore, si on est installés au salon, ça pourrait se faire à distance.
[^] # Re: Fort intéressant !
Posté par raphj . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 2 (+0/-0).
ok pigé ! Merci pour les pistes, en effet ce serait bien d'avoir cet affichage des chiffres ! Je ne savais pas qu'on pouvait faire ça.
Si ça tente quelqu'un, n'hésitez pas à lancer quelque chose, et sinon j'y viendrai peut-être dans quelques mois.
Merci pour les pistes !
Sinon oui, un petit ufw sur la tablette ça ne mange pas de pain. Tout bloquer sauf les ports d'avahi, de samba, de mpd et de ssh. Mais j'espère que mon wifi n'est pas compromis xD
[^] # Re: bravo
Posté par raphj . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 4 (+2/-0).
Top !
Nope, ce n'est pas le cas !
Et quand bien même, il me semble que mettre en place un point de montage NFS n'est pas aussi simple qu'accéder à un dossier réseau SMB. Tu peux te connecter en SMB avec une simple adresse depuis la plupart des gestionnaires de fichiers répandus. Pour nfs, il faut aller lancer un mount, ou ajouter une ligne à /etc/fstab ou utiliser l'équivalent systemd en espérant que ça ne mette pas la pagaille au démarrage si le dossier n'est pas accessible (parce que je ne suis pas chez moi, parce que la tablette est éteinte, etc. Ou aller chercher des solutions style automount.
Là, avec Samba, pas de configuration : le dossier est découvrable grâce à Avahi, il n'y a plus qu'à double cliquer.
Donc même pour quelqu'un qui est uniquement sous linux, pour cet usage, Samba est probablement la meilleure solution.
Pour un dossier réseau permanent et stable et un peu indispensable sur un poste de travail qui ne bouge pas, NFS est probablement la meilleure solution.
La question alternative serait : qu'apporte NFS par rapport à Samba dans ce cas d'utilisation ? Note que je ne veux pas de gestion de droits, l'absence d'ACL est une fonctionnalité.
Je connaissais et ça répondait au besoin :-)
Un ordi central qui joue de la musique, contrôlable par des clients quand il y a besoin mais qui se débrouille tout seul sinon (fonctionne sans client connecté). Une installation légère.
Je ne connaissais pas, ça a l'air pas mal !
J'ai l'impression que c'est un peu différent de ce que fait mpd : tu héberges une médiathèque sur ton serveur, et l'audio est joué sur le client.
Ce qui m'intéresse c'est que ça soit le serveur qui joue l'audio. L'audio ne traverse pas le réseau. Autrement dit, je n'ai pas besoin d'une médiathèque en réseau, mais d'un lecteur de musique contrôlable par le réseau.
[^] # Re: Fort intéressant !
Posté par raphj . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 2 (+0/-0).
Merci pour le message sympa !
Oui, et un moyen de dire oui sur la tablette. Présenter un bouton sur lequel on peut taper (vu que l'écran est tactile). Pour le coup sur un vieux netbook doté d'un clavier, ce serait plus simple.
Donc il faut démarrer un serveur d'affichage
C'est exact.
Utiliser RTC pour ça, c'est une bonne idée !
Yes. Après, le Bluetooth n'est ouvert qu'en audio, et côté wifi, c'est quand même derrière un firewall qui garde le réseau local isolé. Hors de question d'ouvrir tout ça plus largement :-)
On pourrait ajouter des alertes (débit / connexions réseau (on ne s'attend pas à avoir beaucoup de connexion entrantes, très peux sortantes, pas de gros débits), utilisation CPU (pas supposé tourner fort pendant très longtemps).
[^] # Re: La conclusion qui fait mal
Posté par raphj . En réponse au lien La console portable de Lenovo est meilleure sous Linux que W11. Évalué à 2 (+0/-0). Dernière modification le 28 mai 2025 à 11:52.
À priori l'OS lui-même est gratuit : https://help.steampowered.com/en/faqs/view/1B71-EDF2-EB6D-2BB3
Par contre :
Et peut-être qu'il y a en effet des accords pour utiliser les marques de Valve.
[^] # Re: La conclusion qui fait mal
Posté par raphj . En réponse au lien La console portable de Lenovo est meilleure sous Linux que W11. Évalué à 4 (+2/-0). Dernière modification le 27 mai 2025 à 15:54.
Ouais, j'ai l'impression que la différence matérielle justifie entièrement cette différence de prix.
Ça aurait été pas mal de comparer ce qui est comparable. Je suis content de lire que Linux a plus d'autonomie et est plus fluide que Windows, mais pour l'autonomie c'est peut-être juste que le matériel consomme moins. Pour la fluidité, par contre, si Linux est meilleur sur du matériel moins puissant, ça doit dépoter sur la version plus costaud.