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.
Ah ouais, donc le même prix que la version Linux, donc Lenovo se fait une marge plus grande sur la version Linux ? Ça aurait été logique de déduire le coût de la licence Windows quand-même…
Le langage commun c'est open source selon l'OSI. C'est l'usage majoritaire et toute autre utilisation est confuse. Tu prends une page au pif sur internet, open source veut dire open source selon l'OSI, statistiquement. Les seuls contre exemples sur lesquels je tombe sont exclusivement ces discussions de plus en plus nombreuses et interminables où des gens défendent des définitions plus troubles.
Si tu veux dire que les sources sont disponibles, le dire comme ça c'est mieux qu'open source, non ? Pourquoi utiliser un anglicisme complètement ambigu pour ça ? Même en anglais, source available c'est ce qu'il y a de plus clair.
Je ne veux pas restreindre l'usage commun, je veux le défendre. Si "open source" est dans l'usage commun, c'est justement parce qu'il vient de l'open source initiative. Sinon, c'est clairement pas une expression naturelle en français. Utiliser le terme open source autrement, c'est oublier tout le contexte culturel et historique du monde du logiciel.
Ma motivation est simple : nous avons besoin de convaincre les gens que le logiciel libre est une bonne chose. C'est un enjeu politique important. En tant que personnes versées dans ce monde, nous sommes les mieux placées pour ça. Pour faire ce travail de communication, nous avons besoin d'un discours clair. Pour avoir un discours clair, il faut des termes clairs. Logiciel libre est tout trouvé en français. Le hic, c'est que les gens ont pas mal entendu parler d'open source, avec tous le tapage de ces boites que le logiciel libre gêne et qui préfèrent parler d'open source pour éviter de faire de la politique, mais qui, de ce fait, en font beaucoup quand même parce qu'on ne peut pas éviter de faire de la politique. Et aussi, on n'a pas cette chance en anglais d'avoir un truc aussi clair que logiciel libre, free software c'est bof, libre software ça ne fait pas très naturel pour le moment, et on a aussi besoin d'être clair en anglais. Donc on doit composer avec. Si en plus on doit rajouter du trouble dans les termes, on est mort. On galère déjà pour dire "ouais, l'open source, c'est ce que tu connais, mais vraiment, historiquement, le trucs qui cherche à défendre tes droits, c'est le logiciel libre". Si en plus il faut clarifier les trucs qui étaient clairs mais rendus troubles, on est bonnes et bons pour trois kilomètres de mise en contexte et de clarifications à chaque fois, ça n'aide pas.
Alors je propose qu'on garde le sens commun et répandu d'open source, celui qui est omniprésent, qu'on arrête d'affaiblir et de troubler ces mots qui sont des outils indispensables, et qu'on utilise sources disponibles quand on veut dire sources disponibles.
Cette page et ce dessin te contredisent et confirment ce qu’écrivent les autres : logiciel libre et logiciel open source, c’est quasi la même chose au niveau technique.
Avec une subtilité qui n’avait pas été explicité, par simplicité (mais qui avait sous entendue) : il y a, de manière assez anecdotique, des licences reconnues par l’open source initiative comme open source mais comme non libre par la FSF / GNU. C’est pour ça qu’il y a une petite case « open source non libre ».
Le terme « open source » (littéralement, à code source ouvert) est utilisé par certains pour qualifier plus ou moins la même catégorie que le logiciel libre. Il ne s’agit pas exactement de la même classe de logiciel : ils acceptent certaines licences que nous considérons comme trop restrictives et il y a des licences de logiciel libre qu’ils n’ont pas acceptées. Toutefois, les différences entre les deux catégories sont minimes : nous ne connaissons que très peu de cas de code source open source mais non libre. En théorie, il pourrait arriver que certains programmes libres ne répondent pas aux critères de l’open source, mais nous ne savons pas si cela s’est déjà produit.
Il y a par exemple la Sybase Open Watcom Public License, sous laquelle est le compilateur qui compile le bios de VirtualBox, reconnue comme open source mais pas libre.
Mais essentiellement, en pratique c’est les mêmes licences. Open source ne veut pas dire « les sources sont disponibles », c’est bien plus fort que ça, ça doit respecter la OSD (open source définition). Qui est pratiquement équivalente aux 4 points de la définition du logiciel libre. « mais il se peut que tu n’aies aucun droit dessus à part les lire », c’est complètement faux.
Il est important de comprendre que la différence intéressante / importante entre open source et logiciel libre n’est pas technique, mais politique et philosophique.
L’OSD est un copier coller des DSFG (Debian Free Software Guidelines). C’est le même texte, mais comme le projet GNU, Debian ne considère pas Open Watcom comme libre et ne l’intègre pas dans ses dépôts main, et donc VirtualBox non plus. À partir de la même définition, on a eu deux décisions différentes. Donc c’est même peut-être pas un problème de définition, mais un problème d’interprétation (de la définition ou de la licence).
no vendor lock-in : les achats de logiciels libres doivent éviter les situations où une seule entité contrôle un logiciel, notamment par la propriété intellectuelle lui permettant de changer unilatéralement de licence (coucou Hashicorp).
Ça parait un peu contraignant. Si ton logiciel est libre et que la boite qui le développe le rend propriétaire, tu peux continuer avec ta version actuelle et organiser une transition ou un fork.
Peut-être que tu peux plutôt imposer des contrats qui interdisent la boite de changer la licence tant que le contrat court.
Partager le wifi est donné en example, mais ça, un bon vieux QR Code fait probablement encore mieux l'affaire parce que ça peut fonctionner à plus grande distance, et c'est beaucoup moins coûteux, y compris écologiquement.
[^] # Re: wl-clipboard
Posté par raphj (site web personnel) . En réponse au journal Enfin une utilité au presse-papier synchrone de X11. Évalué à 4. 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 (site web personnel) . En réponse au journal Enfin une utilité au presse-papier synchrone de X11. Évalué à 4. 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 (site web personnel) . En réponse à la dépêche Photos et traces gps dans un blog statique. Évalué à 4. 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 (site web personnel) . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 3. 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 (site web personnel) . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 3.
Ç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 (site web personnel) . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 5.
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 (site web personnel) . En réponse au journal Enfin une utilité au presse-papier synchrone de X11. Évalué à 8.
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 (site web personnel) . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 4. 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 (site web personnel) . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 2. 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 (site web personnel) . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 3. 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 (site web personnel) . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 3.
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 (site web personnel) . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 5.
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 (site web personnel) . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 2.
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 (site web personnel) . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 4.
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 (site web personnel) . En réponse à la dépêche Un serveur musical pour mon salon. Évalué à 2.
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 (site web personnel) . En réponse au lien La console portable de Lenovo est meilleure sous Linux que W11. Évalué à 2. 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 (site web personnel) . En réponse au lien La console portable de Lenovo est meilleure sous Linux que W11. Évalué à 4. 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.
[^] # Re: La conclusion qui fait mal
Posté par raphj (site web personnel) . En réponse au lien La console portable de Lenovo est meilleure sous Linux que W11. Évalué à 6.
Ah ouais, donc le même prix que la version Linux, donc Lenovo se fait une marge plus grande sur la version Linux ? Ça aurait été logique de déduire le coût de la licence Windows quand-même…
[^] # Re: Dépôt github associé
Posté par raphj (site web personnel) . En réponse au lien The Windows Subsystem for Linux is now open source . Évalué à 3. Dernière modification le 23 mai 2025 à 17:52.
Le langage commun c'est open source selon l'OSI. C'est l'usage majoritaire et toute autre utilisation est confuse. Tu prends une page au pif sur internet, open source veut dire open source selon l'OSI, statistiquement. Les seuls contre exemples sur lesquels je tombe sont exclusivement ces discussions de plus en plus nombreuses et interminables où des gens défendent des définitions plus troubles.
Si tu veux dire que les sources sont disponibles, le dire comme ça c'est mieux qu'open source, non ? Pourquoi utiliser un anglicisme complètement ambigu pour ça ? Même en anglais, source available c'est ce qu'il y a de plus clair.
Je ne veux pas restreindre l'usage commun, je veux le défendre. Si "open source" est dans l'usage commun, c'est justement parce qu'il vient de l'open source initiative. Sinon, c'est clairement pas une expression naturelle en français. Utiliser le terme open source autrement, c'est oublier tout le contexte culturel et historique du monde du logiciel.
Ma motivation est simple : nous avons besoin de convaincre les gens que le logiciel libre est une bonne chose. C'est un enjeu politique important. En tant que personnes versées dans ce monde, nous sommes les mieux placées pour ça. Pour faire ce travail de communication, nous avons besoin d'un discours clair. Pour avoir un discours clair, il faut des termes clairs. Logiciel libre est tout trouvé en français. Le hic, c'est que les gens ont pas mal entendu parler d'open source, avec tous le tapage de ces boites que le logiciel libre gêne et qui préfèrent parler d'open source pour éviter de faire de la politique, mais qui, de ce fait, en font beaucoup quand même parce qu'on ne peut pas éviter de faire de la politique. Et aussi, on n'a pas cette chance en anglais d'avoir un truc aussi clair que logiciel libre, free software c'est bof, libre software ça ne fait pas très naturel pour le moment, et on a aussi besoin d'être clair en anglais. Donc on doit composer avec. Si en plus on doit rajouter du trouble dans les termes, on est mort. On galère déjà pour dire "ouais, l'open source, c'est ce que tu connais, mais vraiment, historiquement, le trucs qui cherche à défendre tes droits, c'est le logiciel libre". Si en plus il faut clarifier les trucs qui étaient clairs mais rendus troubles, on est bonnes et bons pour trois kilomètres de mise en contexte et de clarifications à chaque fois, ça n'aide pas.
Alors je propose qu'on garde le sens commun et répandu d'open source, celui qui est omniprésent, qu'on arrête d'affaiblir et de troubler ces mots qui sont des outils indispensables, et qu'on utilise sources disponibles quand on veut dire sources disponibles.
[^] # Re: Dépôt github associé
Posté par raphj (site web personnel) . En réponse au lien The Windows Subsystem for Linux is now open source . Évalué à 3. Dernière modification le 23 mai 2025 à 08:37.
Cette page et ce dessin te contredisent et confirment ce qu’écrivent les autres : logiciel libre et logiciel open source, c’est quasi la même chose au niveau technique.
Avec une subtilité qui n’avait pas été explicité, par simplicité (mais qui avait sous entendue) : il y a, de manière assez anecdotique, des licences reconnues par l’open source initiative comme open source mais comme non libre par la FSF / GNU. C’est pour ça qu’il y a une petite case « open source non libre ».
C’est ce que dit en substance cette section : https://www.gnu.org/philosophy/categories.html#OpenSource
Il y a par exemple la Sybase Open Watcom Public License, sous laquelle est le compilateur qui compile le bios de VirtualBox, reconnue comme open source mais pas libre.
Mais essentiellement, en pratique c’est les mêmes licences. Open source ne veut pas dire « les sources sont disponibles », c’est bien plus fort que ça, ça doit respecter la OSD (open source définition). Qui est pratiquement équivalente aux 4 points de la définition du logiciel libre. « mais il se peut que tu n’aies aucun droit dessus à part les lire », c’est complètement faux.
Il est important de comprendre que la différence intéressante / importante entre open source et logiciel libre n’est pas technique, mais politique et philosophique.
L’OSD est un copier coller des DSFG (Debian Free Software Guidelines). C’est le même texte, mais comme le projet GNU, Debian ne considère pas Open Watcom comme libre et ne l’intègre pas dans ses dépôts main, et donc VirtualBox non plus. À partir de la même définition, on a eu deux décisions différentes. Donc c’est même peut-être pas un problème de définition, mais un problème d’interprétation (de la définition ou de la licence).
[^] # Re: Le premier principe : des principes non contraignants
Posté par raphj (site web personnel) . En réponse au lien La France devient le 1er pays à adopter les "principes de l'open source" de l'ONU. Évalué à 2. Dernière modification le 19 mai 2025 à 21:12.
Ça parait un peu contraignant. Si ton logiciel est libre et que la boite qui le développe le rend propriétaire, tu peux continuer avec ta version actuelle et organiser une transition ou un fork.
Peut-être que tu peux plutôt imposer des contrats qui interdisent la boite de changer la licence tant que le contrat court.
Sinon, tout à fait d'accord :-)
[^] # Re: Pourquoi pas root ?
Posté par raphj (site web personnel) . En réponse au lien The audio stack is a crime scene. Évalué à 3.
Ça n'a pas encore l'air super facile à avoir en pratique, cf ce rapport auprès de Debian lié depuis le dernier commentaire de ton lien : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103237
J'espère que ça va s'améliorer :-)
[^] # Re: Exemples d'utilisation
Posté par raphj (site web personnel) . En réponse au lien Comment fabriquer vos propres étiquettes NFC. Évalué à 2.
Ah oui, je pensais à une utilisation domestique, je vois clairement comment les étiquettes NFC peuvent être utilisés plus généralement.
[^] # Re: Exemples d'utilisation
Posté par raphj (site web personnel) . En réponse au lien Comment fabriquer vos propres étiquettes NFC. Évalué à 2.
Excellent !
# Exemples d'utilisation
Posté par raphj (site web personnel) . En réponse au lien Comment fabriquer vos propres étiquettes NFC. Évalué à 8.
Partager le wifi est donné en example, mais ça, un bon vieux QR Code fait probablement encore mieux l'affaire parce que ça peut fonctionner à plus grande distance, et c'est beaucoup moins coûteux, y compris écologiquement.
Des exemples concrets ?