freem a écrit 5019 commentaires

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.

Je suis désolé de t'annoncer qu'en fait, c'est pas mon trip, j'ai juste partagé parce que ça peut intéresser les gens ici.

Sinon, j'aurais fait un bookmark… qui aurait commencé en 2 lignes, et finit en 50.

Ça répond a la question?

Citation nécessaire la, parce que j'ai assuré au moins 2 fois mon poids sur la même forme! Et je suis un parano sur la sécu, pas envie de me retrouver avec un handicapé sur le dos, ni même dans le club!

Ceci dis, moi, je préfère avoir une visse, et quand je suis responsable, je titille le doigt de tout le monde, vis ou auto, je m'en fout, c'est automatique. Et quand je suis pas responsable, je check quand meme avant chaque grimpe mon assurreur.

J'ai pas eu le "plaisir" de voir ma méfiance être utile, mais une fois que j'étais pas la, justement, un accident s'est produit. Par des "pros".

Ou, simplement, que les gens aient conscience des limitations de leurs outils… tu utiliserais une tapette (comme on dit chez moi, ça désigne le marteau pour enfoncer les petits clous de moins de 2 cm de longeur avec une tête de moins de 2 mm de diamètre) pour enfoncer une vis?

Ptain mais ouai, un outil qui enfonce (ou visse, c'est pareil) est adapté à tout… et puis, l'info, c'est facile… ah, pardon, me suis trompé de site on dirait..

Ce qui,du coup, casse mon point de rire, méheu… Bah, au moins, quelqu'un aura explicité le truc donc même si moi j'y perds par fierté (lol) ceux qui liront ta réponse apprendront.

En vrai, j'ai appris peu après que sqlite est endian-agnostique, donc que je me suis planté sur toute la ligne! J'assume, j'ai,une fois de plus, écris de la merde.

https://jointwt.org/

Voila. J'ai pensé que ça intéresserais des gens ici.

Moi qui croyais que c'est pas un problème, l'API changeante XD

Es-tu certain, ou persuadé?

Pour un outil critique a son activité?
Je suis débile de chercher a maîtriser ce que je fais et comment je le fais?

Et de toute façon, si on utilise le mauvais outil pour une tâche, est-ce normal d'accuser l'outil de ne pas être fait pour, ou d'avoir des limitations dans un usage non prévu?

Y'a une GUI a sqlite? Un truc officiel je veux dire… non parce que pour moi, l'intérêt de sqlite, c'est d'être un SGBDR sur un seul fichier, donc léger et relativement «simple» à bouger, point barre.

Tu aurais parlé d'access, j'aurais compris… mais ça reste un outil de prototypage a mes yeux.

J'en doute, une système de fichier, ça bosse avec des blocks me semble, qui ont uen taille minimale, je dirais d'environ 4Kio pour ceux que je «connais». Imagines le gâchis sur disque et en mémoire quand tu as un peu trop d'enregistrements…

Perso, quand je lis "unicode" je comprend "codepoint unicode". Mais tu as raison c'est un raccourcis mental que je me suis fait.

Chiche? Mais faut d'abord spécifier une syntaxe, que les autres puissent jouer…

Ajoutes juste "tout glyphe ASCII 30 ou 29 devant être utilisé dans un champ doit être encodé sous la forme \30 ou \29, et le glyphe \ doit être encodé sous la forme \134" et ça me paraît bon. Tu utilisais bien le décimal pour 29 et 30?

Parce que le problème, il vient clairement pas des gens qui utilisent excel ou un tableur pour stocker des millions d'enregistrements? Qui utilisent des outils sans en comprendre le rôle et les limitations?

SQLite peut s'utiliser sans problème sous Windaube

Est-tu sûr qu'un fichier sqlite généré sous Windaube sera lisible sur n'importe quel Lisux peu importe le hardware en dessous? Pas de risque de confondre un Sioux avec un Cherokee?

(je sens que je vais me marrer)

j'ai toujours eu des soucis pour ouvrir des fichiers csv (ou texte, c'est kla même chose pour le coup) de plus de 1 GiO.

Peut-être une question d'outil? Ton outil, il ouvre le fichier et lit caractère par caractère, avec un fread (ou du même genre) à chaque fois? Ou il utilise mmap, ce qui permets de jouer avec les données comme si elles étaient en mémoire et donc réduit le nombre de syscalls nécessaire pour accéder à une donnée, en laissant le noyal fair boulot de gestion des accès aux ressources?

S'il utilise mmap, dans ce cas c'est probablement la même merde pout n'importe quel format texte: il faut toujours parser, on peut pas pas paralléliser pépère. Sauf si le format indique la taille en octets ou en caractères des champs, à la rigueur, mais ni xml ni json ne font ça. C'est plutôt les formats binaires qui font ça, mais je crois que c'est passé de mode… (enfin perso, si je dois bricoler un truc réseau, je préfère utiliser un format binaire, je trouve ça bien plus simple a implémenter)