freem a écrit 5059 commentaires

mpd est un daemon qui peut soit prendre ses commandes sur un «socket UNIX» (man 7 unix) soit sur des sockets plus classiques, c'est à dire TCP/IP.

Dans le 2nd cas, si tu fais écouter mpd sur une interface réseau réelle (autre que "lo") ou sur une IP réelle (autre que localhost, 127.0.0.1, etc) il te sera possible de le piloter de n'importe quelle machine de ton réseau local.
À noter que l'IP "0.0.0.0" indique "toutes les IP".

Bref, si LXDE ne sert qu'a piloter mpd, tu serais gagnant a simplement piloter mpd de l'extérieur, que ce soit via ario, ncmpc, ncmpcpp, mpc ou autre.
Ça ne réduirait probablement pas le temps de boot de mpd, cela dis, temps de boot qui me surprend, d'ailleurs, j'ai toujours vu mpd démarrer très vite, avant même que les instances d'agetty ne soient lancées, et ce, y compris sur ma vieille machine que je voulais pendant un temps utiliser comme jukebox: vieux pentium mono-coeur cadencé à 700MHz, disques pATA entre 80 et 40 gig, récupéré avec 64Mo de ram, boosté depuis a la quantité faramineuse de 196Mo, bref, moins performant qu'un beaglebone black, et pas qu'un peu. Ne parlons même pas des raspberry pi :)

Ce que je soupçonne, c'est que ton système d'initialisation ne démarre pas mpd avant que les interfaces réseau, et donc l'acquisition d'IP via DHCP (alors que mpd n'a pas besoin du réseau pour fonctionner, surtout dans ton cas). Il y a fort a parier que tu utilises systemd, sur lequel je ne peux pas t'aider, mais tu devrais jeter un oeil. Pour moi, dès lors que le kernel est chargé, mpd devrais être capable de démarrer en moins de 30s, même sur du vieux matos.
Autre piste, si le problème est la performance de la machine: passer les daemons moins importants en démarrage après mpd. Hum… j'y pense, tu as peut-être aussi pulse audio. Ça n'est pas grand chose, mais vu la machine, il peut être intéressant de ne pas l'installer, si tu t'en sers juste de jukebox et de serveur de fichiers. Il est possible après tout que mpd attende après PA si ce dernier est présent…

Par contre ils se sont trompé de terme, je pense, parce que pour moi, c'est pas des pijul qu'on entre par l'anu.

Je suis déçu, mon troll a fait long feu, pas beaucoup de réponses. Ça marchera mieux un autre jour :D
Même la note est encore positive. Décidément, j'ai tout raté!

Plus sérieusement, je pense que LaTeX nécessite un apprentissage initial plus long pour faire des trucs simples, c'est clairement moins ergonome, moins intuitif, et en ce sens, je pense que les logiciels de traitement de texte sont nécessaires.

Cela dis, je préfère personnellement utiliser LaTeX non pas pour faire mon élite (je suis loin d'en être) ni parce que je suis un scientifique (j'en suis pas un), mais du fait que je peux utiliser mes outils habituels pour gérer le source du document: git, vim, grep, etc.

Autre chose que j'apprécie avec LaTeX, c'est qu'il me débarrasse presque complètement de la tentation de bricoler la forme, du coup, je me concentre sur le contenu, je vais plus vite, et même si c'est plus spartiate (j'ai pas de couleurs à la fin, par exemple) moi ça me conviens bien plus.

Le point bonus, c'est la taille finale (en octets) du source et le fait de pouvoir en générer même sur de très petites machines peu performantes.

Par contre, je n'irai pas recommander LaTeX à un utilisateur qui a juste besoin d'un document pas trop moche rapidement.

ça me semble problématique, mais je ne suis pas un expert

Le TOFU à ses inconvénients: si le site est frauduleux dès le début, on peut pas protéger. Si le site est un squat de domaine, idem.
Ceci dit, une faille dans la chaîne des CA, et c'est tous les maillons descendants qui sont cassés, on a déjà vu le cas, et pas qu'une fois.

En plus de ça, que risque-t-on?
Avec gemini, pas de cookies, pour commencer.
Et l'idée, c'est d'avoir des sites gemini simples, pas de cross-domain, pas de contenu qui s'exécute au hasard (dans l'esprit, hein, parce que je doute que ça soit impossible de le faire, me souviens plus)… contrairement au web.

Je pense personnellement que les chaînes de sécurités des CA sont d'une utilité plus que douteuse dans le cas d'un site type blog, ou le but est juste de communiquer sur un sujet qui intéresse l'auteur, ou qui permets le téléchargement d'un fichier.
Il n'y a pas de login, pas (besoin) de cookie, pas de langage turing-complet embarqué dans le document…

Pour ce qui est du typo-squatting… au final, le système de CA ne l'empêche pas non plus, il suffit de voir tous ces gestionnaires de paquets pour language de programmation qui se font exploiter.

Bref, sauf pour des sites sensibles, qui servent a interagir (type linuxfr), je ne vois pas trop l'intérêt des chaînes de certificats. Et même dans ce cas précis, je ne suis pas entièrement convaincu.
Bon, certes, dans le cas de ma banque, avoir un certificat qui soit validé par une autorité supérieure en laquelle j'ai confiance est un plus.
Mais justement… puis-je avoir confiance dans l'autorité certificatrice de ma banque? Ça serait mon gouvernement, peut-être (et encore, on pourrait arguer que certains gouvernements de certaines nations ne sont pas nécessairement dignes de confiance).
En l'occurrence, il s'agit de «Sectigo Limited». Tout semble indiquer une entreprise des USA, alors, la confiance, comment dire…

Fusion c est vers le liquide… de solide à gazeux, c'est la sublimation.

Autres points, sur les disques mecanique, l'accès aux données est légèrement plus rapide en début de plateau. Donc, mettre les données fréquemment accedees dés sur une partition proche du début de disque peut aider.
Il faut aussi penser à la fragmentation, si il y a beaucoup de fichier de grosse taille, les mettre sur un ds ayant une taille de cluster plus importante peut aider.

Côté logiciels, ne pas installer automatiquement les paquets recommandés par debian va aider, et, pour les utilisateurs plus avancés, jouer avec le démarrage auto des démons(écrire avec une tablette est vraiment horrible, désolé pour les mauvais termes et autres).
Il est aussi possible d'exposer le socket de mpd de sorte à le piloter d'une autre machine.

Tout ça ne sera pas forcemment perceptible, mais cummule cadevrais gagner un peu.

Parce que LaTeX, étant du texte pur et dur, se prête au versionning (CVS, SVN, SCCS, mercurial, bazaar, git, fossil…), ne casse pas son interface entre les versions, et se prête donc merveilleusement à l'amélioration continue, contrairement aux usines à gaz logiciels de traitement de texte WYSIWYG.

Du coup, oui, je dirais que c'est bien le logiciel qui est en cause.

Bon vendredi :)

Que des sites issues de vox.com ou facebook ne marchent pas parfaitement avec netsurf, ben, on s'en fout un peu non?

Perso, je constate déjà que même linuxfr.org ou lwn.net ne marchent pas avec dillo, et de mémoire pas non plus avec netsurf-gtk (de mémoire, parce que je le trouve pas dans aptitude, je creuserai plus tard).
Ce ne sont pas des sites qui sont a franchement parler bourrés de JS et autres cochonneries, pourtant. Non, c'est juste cet horrible CSS.

Et il y a tout de même QtWebEngine et WebkitGTK en libre donc on n'est pas obligé non plus de revenir au TeleType.

En même temps, tous les moteurs de rendu actuels sont libres. C'est pas le souci.

Autre mécanisme que j'appréciais beaucoup, mais plus récent je suppose: les rings. Par contre j'imagine qu'il fallait embarquer une page d'un autre site, ça pourrais en faire tiquer certains de nos jours.

Encore un autre mécanisme, plus récent encore: les flux RSS/Atom, je m'en sers personnellement surtout pour les BDs, via un pluging claws-mail, mais il faut reconnaître que claws n'est pas adapté à ça, du coup je pense que j'utiliserais plus avec un outil plus structuré.

C'est un réseau a part.

Gemini n'est pas un réseau mais un protocole réseau doublé d'un format de fichier.
Le web n'est pas non plus un réseau, mais un ensemble de protocoles doublé d'un ensemble de formats de fichiers.

Facebook n'est pas non plus un réseau, mais un site web, sur lequel peuvent éventuellement se construire ce que l'on appelle des réseaux sociaux, c'est à dire entre personnes.

Je pourrais très bien décider d'héberger un serveur HTTP et héberger uniquement des fichiers de texte brut. Ça ne serait pas le web, les navigateurs standards seraient à chier dessus parce qu'ils considèrent que l'interface graphique est le boulot du site web. Pour moi, ces logiciels que sont firefox, chromium et safari ne sont même pas dignes du titre de "navigateur", ce sont au mieux de (mauvais, très mauvais même) outils de téléchargement et de rendu de "documents HTML5", ce qui est la seule chose qu'ils arrivent à peu près à faire correctement.

Certains sites web bâtissent des réseaux, c'est vrai. Au travers notamment des «rings», mais c'est un peu un truc du passé, ça.

on peut toujours faire des choses très bien avec du HTML, HTTP, CSS voire JavaScript,

On peut pas faire un client correct supportant ces techno, de nos jours.
C'est ça que ces projets (enfin, surtout gemini) essaient de résoudre: avoir des specs claire, implémentables aisément, et pas réservées à google, apple et mozilla.

Enfin, si tu dis qu'on peut, vas-y, je suis curieux de voir le résultat (les gens de netsurf essaient depuis des années, ils avancent, mais ils en bavent, et sont très loin de supporter correctement les "specs" de html5).

Hormis utiliser du PXE mais c'est une autre histoire pour un débutant !

Et même du PXE c'est pas forcément possible, le firmware est un BIOS, ça supporte pas forcément le PXE… ça dépend de la carte réseau, et si elle supporte pas, il faut jouer avec des disquettes, de ce que j'ai lu… mais j'admets ne jamais avoir fiat de PXE avec du matos aussi vieux: j'ai essayé (avec du plus pourri, en fait: CPU mono-coeur 700MHz, ~192Mo de ram, MAIS 200Gio (ou 240?) de disque dur :p (ben oui, j'y ai collé mes 3 vieux PATA qui marchent encore: 2 de 80, et l'autre peut-être 40 je sais plus).

Pour en revenir au sujet, moi je collerai une Debian avec le bureau LXDE, mais par contre le web on oublie (pas internet, hein, juste le web: les mails avec claws ne poserons pas de souci, les webradios via vlc ou mpd non plus, irc j'en parle pas, etc etc). 512Mio de ram, c'est bien trop peu pour le web bourré de cochonneries.
Enfin, certains sites sont p'tet utilisables, via des trucs rustiques comme linx ou, un peu mieux, netsurf ou dillo, mais faut pas rêver, ça sera juste les sites qui restent utilisables sans JS, et ça sera pas joli (les CSS sont pas forcément super bien supportées: plus le site utilise des merdes «modernes», plus tu peux oublier…).

[edit]
Bon, ok, solid, en fait, ça a juste l'air d'un gros bloatware aussi. Ce qui a l'air du site officiel mets 3 plombes a charger avec la co pourrie que je me tape depuis quelques temps (déménagement à la cambrousse, initié pile avant le 2nd confinement…), à savoir 130Ko/s le vent dans le dos.
Pour comparaison, les pages gopher sont quasi instantannées, et pèse moins de 1meg.
Sans lien plus pertinent, je dirais donc: Solid? Dans la poubelle grise.

Et j'ai lu les specs d'ailleurs. L'un des trucs qui m'ont marqué, c'est le fait que ça spécifie explicitement une dépendance a un protocole de chiffrement.
Ce qui est triste, parce qu'il n'y a aucune raison de faire ça, et je pense même que ça risque de bloquer l'évolutivité à plus ou moins court terme, la ou les gens qui fournissent des fichiers via http, s ou pas s, peuvent juste exposer un serveur http sur un port, et un proxy pour le chiffrement sur un autre port qui appelle le 1er (c'est ce que j'ai sur mon serveur: darkhttpd sur lo::8080, hitch sur lo::8443 qui redirige sur lo::8080, et des règles iptables qui redirigent comme il faut les ports par défaut).
Bref, pour du minimalisme, c'est raté de mon point de vue.

Je suis aussi sur un IRC ou ça aime causer de ce genre de trucs, et je suis pas le seul a avoir relevé ce point, même si ça veut rien dire.
Il y avait d'autres points que j'ai relevé, mais je me souviens plus.
Au final, je ne vois pas l'intérêt. De mon point de vue, c'est bien moins chiant d'exposer un serveur http qui laisse le client explorer l'arborescence et faire sa propre interface.
En aucun cas, un client http ne se doit d'être un client web, et tous les clients web que je connais sont loin d'avoir les fonctionnalités que j'attendrai d'un navigateur: je suis obligé d'utiliser les liens fournis par un document pour pouvoir trouver les autres ressources, je ne peux donc pas naviguer, et encore moins explorer, mais soyons honnêtes: c'est pas la faute de http si les gens ne s'en servent (quasi) que pour exposer des fichiers html (qui sont le vrai problème pour moi) et des scripts cgi.

Pour rappel: HTTP veut dire «HyperText Transfer Protocol». Et non «Hyper bloaTed Transfer Protocol». Au final, c'est le même problème qu'il y a eu (qui se calme, il me semble) avec XML: utilisé pour tout et surtout pour n'importe quoi, sans exploiter les vraies fonctionnalités. Encore que, XML au moins a encore un standard et des specs claires, qui ne changent pas selon le vent, lui.

Cela dis, je m'en vais creuser autour de ton autre machin, on sait jamais.

PS: pour gopher, il existe dooble qui est un navigateur web tout en supportant gopher. C'est un peu moins inconfortable que les clients de type cgo (par exemple) ou les proxy web, mais on y voit, justement, les limitations d'un protocole couplé à un format de fichier (ce qu'est en réalité gopher, tout comme gemini) «minimaliste».

Moui… de la ou je suis, je suis a ~8Km de la 1ère ville de taille acceptable. Comptes un aller-retour: 16km. Pour faire les courses "quotidiennes".
À cette distance, si t'as une pause repas assez longue (1H ou plus) et que tu bosses dans cette ville, ben tu rentres chez toi pour manger (pas écolo et plus cher que la gamelle, mais bien plus agréable). Hop, 32km.
En pratique, les gens vont souvent faire 20 minutes de route pour bosser, au moins. On estime dans mon coin les moyennes de vitesse à 50Km/h sur un trajet, donc a peu près 17km minimum pour aller bosser. Et le retour… 34km.
C'est du pifomètre, certes, basé sur mon expérience et celle des mes proches.

Aller voir un frangin ou un pote, tu ajoutes encore vite fait 10 bornes. Et bien d'autres usages, en admettant faire tout dans un cercle inférieur à 8Km de rayon, ce qui est loin d'être gagné.

Maintenant, il faudrait aussi définir ce que tu appelles rare: une fois par semaine, c'est rare ou pas, pour toi?

surtout quand on n'est pas dans une grande ville qui donne accès à transports en commun

Même certaines grandes villes ne donnent accès a des transports en commun à intervalles assez rapprochés (moins d'une heure) qu'a certaines zones. Tout en ayant un tarif également assez élevé du ticket, avec en prime ce gros foutage de gueule qu'est le télé-paiement (quand ça marche, ça coûte plus cher que le ticket unitaire!).
Rouen, c'est de toi que je parle (j'ai connu d'autre villes ou ces problèmes étaient moins vrai voire absent, la région parisienne notamment, mais aussi Caen, et peut-être d'autres, je sais plus).

Juste pour ma culture: si tu as testé les 2, c'est quoi la différence avec tiled

Et la, c'est à l'OS de savoir exposer les diverses horloges, et au logiciel client de savoir laquelle utiliser. Si l'OS sait pas faire… dommage, mais je doute que ça existe en dehors d'un kernel embarqué ultra compact (avec moins de 20 megs pour l'os complet, je dirais qu'un système basé sur linux peut tenir, mais ça sera probablement pas une distro GNU/Linux par contre, mieux vaut se baser sur busybox ici (je pense à certains routeurs que j'ai vu, mais me souviens plus des tailles de rom/ram).

Par exemple pour faire la 1ère installation d'une machine, qui par définition n'aura pas encore d'heure système (cas du journal, en fait).

Bref, ce comportement de isc-dhcp-client implique que PXE ne peut pas fonctionner selon le firmware, ou pire, si la mémoire stockant l'heure est corrompue.
DHCP n'est pas un protocole qui devrais nécessiter une synchronisation, donc pour moi c'est clairement un bug. Je pense que je vais faire un test "pour le fun" sur mes VMs, je suis curieux de savoir si le client que j'utilise le plus (udhcpc, l'applet busybox) est affecté par ce bug (car s'en est un)…

où les RJ45 murales sont raccordées avec du câble téléphonique…

C'est exactement ce que j'ai câblé il y a plus de 10 ans chez mes parents… à la campagne, sur moins de 10m, sans machine plus imposante dans les environs que l'habituel électro-ménager. Ça tiens largement tous les besoins, et c'est pas cher. J'ai d'ailleurs toujours une grande quantité de câble téléphonique non-utilisé, je m'en sers de temps en temps pour faire des câbles réseau, et ça n'a jamais été le goulot d'étranglement.

Je ne dis pas que le blindage ne sers à rien, hein, loin de la, juste que ça dépend de la distance, de l'environnement et des performances que l'on attends. Sur mes réseaux de particulier, je m'amuse rarement a transférer de grosses quantités de données, et encore plus rarement en en ayant besoin en temps réel.

Pour l'accès internet, le goulot à toujours été le lien internet, justement. Pas le Wi-Fi, pas mes câbles de barbare, pas le switch tout pourri acheté y a 15 ans… le dernier goulot d'étranglement que j'ai eu, c'était quand j'ai récup des données de vieux disques PATA, et c'était… le CPU de la machine qui a encore ce type de connectiques, le goulot!

Maintenant, je suis d'accord que pour du réseau professionnel avec de vraies exigences de vitesse, un minimum de qualité est nécessaire, et encore pire si c'est proche de machines outils bien sûr.
Mais chez le particulier? Bof.
Bon, il faut aussi mettre dans le contexte, la différence de prix aujourd'hui justifie-t-elle du non-blindé? Parce que si j'avais pris ça, c'est que j'étais étudiant ou chômeur ou peut-être que je creusais des trous, je sais plus. À l'époque, il y a avais une différence de prix, et de facilité a trouver, aussi, et puis, comme je l'ai dis: campagne, avec tout ce que ça implique en terme de calme électromagnétique.

Non, le rouge ça va plus vite.

Vu que le CPL utilise une fréquence porteuse plus haute (plus que 50Hz donc, pas difficile) il suffit de faire un filtre passe-bas passif qui bloque à partir du 1er composant (le porteur, mes souvenirs de décomposition de Fourrier sont loin derrière moi) voire bien avant, c'est une technologie plutôt ancienne.

Je n'ai pas ce type de filtre sous le coude, et encore moins d'oscillo, mais j'ai assez pratiqué ce genre de trucs au lycées (STI génie électronique, on en a bouffé du filtre) pour douter que "ça filtre pas en vrai", à moins que le complot international pour cacher que la terre est plate au peuple, quitte a imposer windows et répandre une pandémie de corona ne soit avérée, bien sûr :)

Plus sérieusement, un filtre passe bas passif, c'est littéralement un montage avec 3 des composants les plus simples: résistance, inductance (pour l'instant ça peut se faire avec juste des fils de métal) et condensateur.
Bon, évidemment, un filtre, ça atténue, ça ne "bloque" pas, donc tu peux toujours retrouver des traces en aval du filtre (mélangées à celles de tes voisins et au bruit ambiant, hein), et si quelqu'un arrive a amplifier suffisamment le signal, il pourrait effectivement le récupérer (avec un taux de pertes non négligeable je pense). Suite a quoi, il lui suffira d'aller installer sur ton PC de faux certificats racines pour faire une attaque de MitM et déchiffrer ton super mot de passe unique de DLFP.

Zut, je voulais être sérieux… donc, pour le sérieux: tu ne peux pas bloquer totalement un signal, juste l'atténuer drastiquement. Les filtres passe-bas sont une technologie très peu chère, tout sauf secrète, et il n'y a donc aucun intérêt a faire de la merde. Le signal atténué peut être récupéré en théorie, mais en pratique, au delà de ton compteur, il se retrouve mêlé aux signaux des autres et au bruit, donc je doute très fort de la faisabilité de la chose. À noter que selon la même logique, le compteur doit déjà en avoir un (sinon le niveau de bruit sur le réseau interne serait probablement trop elévé), mais avoir un filtre séparé me semble pertinent, ça fait un SPOF de moins.

En même temps, le jeunot, il utilise un éditeur de texte castré… Un vrai vieux comme moi, ou un ancêtre pire que moi, aurait utilisé edit.com à l'époque. Qui avait d'indéniables qualités, notamment la capacité de formater (un peu) un fichier selon un format d'enregistrement me semble?
Ce que je sais, c'est que j'ai reverse 2 des 3 formats de fichiers utilisés par dungeon keeper en quelques heures a l'époque! Je ne savais pas encore coder… enfin, si, je connaissais mon C et mon asm, mais bon, je savais pas créer un logiciel.

À condition de ne pas viser son intégration dans Debian, j'entends, parce que sinon il faut faire un .deb source, et ça, c'est une autre paire de manches.

Ce que je faisais au taf, en gros, c'était dans ce goût là:

Créer un fichier monprojet/DEBIAN/control, les champs que l'on utilisait étaient: Package, Version, Description, Architecture, Depends et c'est tout.

Bon, en vrai, j'avais bricolé un script de 100-150 lignes qui générait la structure du paquet, à savoir quelque chose qui ressemblait à ça:

./DEBIAN/control
./DEBIAN/md5sums (ou shasums? Je sais plus, suis pas chez moi, je re-répondrai ce soir au pire?)
./DEBIAN/conf (qui n'étais au final pas nécessaire)
./usr/bin/monbinaire (ou l'équivalent pour les libs bien sûr)
./etc/maconfig

Puis le script lançais la commande pour générer le binaire: dpkg -b mondossier. À noter qu'il gérait aussi d'autres bricoles comme les fichiers de dictionnaires et autres, et que, je pense que niveau légal c'était pourri, vu que pas de fichiers de licences. Ça avait été fait (comme toujours) dans l'urgence, mea culpa (et j'en avais marre du tar -xf foo qui me donnais des sueurs froides quand j'avais pas inspecté les tarballs des collègues!).

La config était stockée par moi et au moins un collègue dans un repo séparé (un autre ne le faisait pas, ça lui a rajouté quelques heures de boulot pour réparer ses oubli, surtout avec les connexions radio qui sont pas toujours géniales… mais c'était plus mon problème a ce stade), de sorte qu'au final on avait un paquet pour le binaire/la lib, et un autre pour la config. Elle contenait aussi souvent les scripts d'init (runit en fait).

Ceci dit, encore une fois, le but n'étais pas d'intégrer dans Debian (close source t'façon, et code de merde en plus).
Je pense que cette façon de faire est parfaitement acceptable (modulo l'aspect licence) pour un projet libre qui veut juste filer un binaire qui marche à ses utilisateurs, n'en déplaise aux perfectionnistes (et n'en déplaise aux râleurs: le format des paquets binaires de Debian est simple, robuste et très puissant).

Le gros problème est que la doc pour ces infos n'est pas super simple à trouver, j'avais en fait reverse un binaire (avec dpkg-deb -R) avant de trouver une référence.

En espérant que ça aide.

L'autre solution serait de faire des exécutable statique mais c'est peu recommandable.

Pourquoi?
Si c'est pour l'ASLR, il me semble bien que c'est possible aussi avec des binaires statiques. De plus, il y a plus d'optimisations possibles grâce au LTO. Si le problème est la mise à jour des dépendances, alors aucune solution ne sera jamais parfaite, même si dans l'idéal reposer sur les versions de l'hôte me semble le moins idiot.

Là ou ça va être chiant, c'est la compilation. C'est pénible à faire le link statique, avec des erreurs bien chiantes et très peu d'aide du linker pour les gérer.

Cela dis, pour linux, les libs qu'il utilise semble vraiment classiques. Il serait surprenant qu'une distro ne les ait pas déjà empaquetées.