freem a écrit 5019 commentaires

et pour autant je promeus la démarche devops, docker n'étant pas dans mes solutions préférées pour diverses raisons

Du coup, c'est quoi tes solutions préférées? Par pure curiosité.

Bref, ce n'est pas le sujet qui est de réduire l'empreinte des logiciels demandés pour un fablab :-)

Allons allons, ce n'est pas comme si c'était la première fois que des digressions arrivent sur linuxfr, et en plus, il a posté un jeudi soir, le moment idéal pour avoir un journal exposé au trolldi dès le matin à la 1ère heure :p

Je suppose que je t'ai mal compris dans ce cas, ou que je me suis mal exprimé. Je vais développer un peu plus, en citant de manière plus ciblée:

difficulté de mise à jour

c'est justement un de ces points forts

Comparé aux gestionnaires de paquets traditionnels, dont apt, non? Ou alors, comparé à quoi?

lancer un nouveau container […] est bien plus rapide

Pour moi, relancer juste un service après une MàJ, c'est plus rapide que relancer un service ET ses dépendances… du coup, en quoi, par exemple, apt serait-il plus lent que docker?

lancer un nouveau container […] est bien plus reproductible et facilite le retour arrière

Ici, je veux bien t'accorder le bénéfice du doute, dans le cas que je connais le mieux (apt), un paquet foireux pourrait effectivement n'être pas reproductible et donc ne pas faciliter le retour en arrière.

Sauf que, en pratique, j'ai fait suffisamment de va-et-viens entre les diverses versions de Debian (avec un peu d'apt-pinning et quelques repos externes, dont 1 non-free, au passage, pour bien essayer de foutre la merde) pour savoir que les paquets Debian sont solides, très solides.

Hum… en quoi les paquets apt seraient-ils lents, non-reproductibles ou empêcheraient le retour en arrière?

Je suis curieux de voir tes références, parce que j'ai personnellement fait pas mal joujou avec l'apt-pinning et le yoyo entre une stable et une unstable/sid, en passant par testing, et sans problèmes particuliers.

Ok, finalement j'ai réussi. Pour info, si l'on n'utilise pas logind, ce qui est mon cas, ou que l'on n'a pas la possibilité d'utiliser des pilotes compatibles DRM/KMS, il est possible de contourner le problème en:

• installant xserver-xorg-legacy
• mettant ou ajoutant la clé de configuration needs_root_rights=yes dans /etc/X11/Xwrapper.config`.

Trouvé via ces 2 liens.

C'est un peu hors-sujet, mais du coup, un des problèmes qui me bloquaient est enfin résolu :)

si c'est un disque qui sera deplacable (usb) il n'est pas recommandé d'utiliser ext4 car il ne sera alors pas lisible sur windows/osx

Pour être exact, il ne sera pas utilisable sous windows tant que le pilote correspondant n'est pas installé. Mais il existe des outils qui permettent d'accéder à des partitions ext4 depuis windows. Pour OS X, je ne sais pas.

Enfin, c'est un détail, de toute façon je suis d'accord qu'il vaut mieux utiliser ntfs pour faire transiter des données d'un os à l'autre, ça simplifie les choses pour les non linuxiens, qui sont bien plus nombreux.

Intéressant, merci, il faudra que je l'essaie. Ca peut toujours servir ce genre de trucs.

Le truc, c'est que sous Debian, pour installer KDevelop, il faut installer KDE, no way pour moi, j'ai autre chose à faire de ma bande passante et de mon espace disque.

Et pour ce qui est de QtCreator… comment dire… la dernière fois que j'ai utilisé ce machin, il ne me restait plus que l'équivalent d'une feuille A6 pour coder.
Comparé à mon i3 combiné avec mes urxvt, le gain d'espace est juste évident. La seule chose qui me fait parfois envie dans les IDEs, c'est bien leurs debuggers, et encore.

Les debuggers les plus puissants et les mieux foutus que j'aie vu, c'était sous windows, et aucun n'incluait, à ma connaissance, de fonctionnalités d'édition de code:

• softice un débugger en ring 0,
• IDA qui même dans sa version démo est capable de rendre la lecture de code assembleur relativement aisée,
• w32dasm lui était un peu léger en fonctionnalités il faut le reconnaître, mais ollyDbg en revanche était très bien.

Si un seul IDE sous linux dispose d'un interface à gdb (ou llvm, pourquoi pas) aussi efficace que n'importe lequel de ces outils, je suis curieux de savoir duquel il s'agit (cgdb en est, lui aussi, extrêmement loin, nous somme d'accord, mais au moins il se lance dans la seconde même avec des machines pas sur-puissantes).
Bon, dans le cas de softIce, il y avais bien rr0d mais j'avoue ne jamais avoir joué avec, et le projet semble mort depuis bien des années.

Enfin, je serai aussi preneur du sondage github, je ne savais même pas que github en faisait…

D'accord. Bon ben j'aurais appris un truc aujourd'hui :)

C'est ici. Bon, il n'y a pas des masses de projets dessus, certes (6 dont c'est le forum officiel, 9 «invités») mais bon, ça lui éviteras de parcourir la toile et je pense qu'une telle proposition sera acceptée avec joie.

La variable Do est initialisé à 0 par défaut.

À quel endroit? Je ne vois aucune affectation à Do autre que dans EraseAll moi. Le standard spécifie qu'une variable est toujours initialisée à 0? Je n'en suis pas si sûr… d'ailleurs, je surpris qu'il n'y ait pas le classique warning "value not initialised" ou un truc dans ce goût la.

Ah tiens? Étrange, quand j'avais essayé, à config utilisateur égale avec la jessie, il me renvoyais connexion refusée? Tu as mis des droits particuliers à ton utilisateur?

Tu dois bien savoir ce que tu fais de ta machine quand même? Si tu utilises un DE et lequel, si c'est un serveur de quelque chose tu dois bien connaître les logiciels nécessaires pour fournir ce service?

Oui oui, dans ce dernier paragraphe j'accuse (sans preuves formelles) carrément Google de saboter ses services pour qu'ils ne marchent "à tous les coups" qu'exclusivement avec ses outils.

Tiens, un peu d'eau pour alimenter ton moulin…

D'autres pistes pour ce genre de problèmes de lien: man ldd et les manpages associées. Parfois c'est un «simple» problème de symbole qui n'est pas à la bonne version et du coup, il faut recompiler ou installer la bonne version de la lib.

Tu utilises quoi comme paquets?

Perso, je n'ai pas fait la migration (et je ne la ferai pas, je changerai de distro, du coup) à cause de modifications qu'ils ont faites et qui empêchent de lancer un serveur Xorg sans être root. Mais ça ne te concernera probablement pas: c'est lié à l'utilisation de xinit.

Malgré le shebang?

j’écris ça surtout pour d’autres débutants…

Je t'avoue que je n'avais pas noté le coup du www-data, en fait.

Que tu le nettoies ou que tu le refasses entièrement, profites-en pour le documenter.

Même sans refactoring, je suis en train de documenter cette chose… pas le choix si je veux y voir ne serait-ce qu'un peu et éviter de tout péter au moindre commit… parce que la, c'est du boulot sans procédure d'install, sans description de quels ports sont ouverts et dans quels protocoles (tcp? udp?), sans API décente, avec du zombie de tous les côtés, et j'en oublie. J'ai même trouvé cet aprem une classe qui encapsule les sockets BSD et… euh… y'a un peu un membre qui n'est jamais écrit (sauf init, c'est déjà ça) mais donc la valeur est utilisée par listen, bind, accept et close. Youpi. Y'a un bug, c'est sûr, mais comment ça se fait que ça semble marcher en prod?
Et tu l'auras deviné: debug en prod: essayer de reproduire l'environnement de prod à base de VM risque de me prendre encore quelques heures, au bas mot.
Bref: je pleure.

C'est une bonne occasion de le faire parce que tu ne seras pas poussé aux fesses pour sortir en temps et en heure un produit qui n'existe pas encore. Et tant qu'à faire, essaie de faire quelque chose qui soit auto-généré, donc soit du Doxygen, soit une page de référence interactive à la manière de celle d'Apache.

C'est bien mon intention.
Généralement, j'utilise doxygen, mais contrairement à pas mal de choses que je vois, je me contente d'expliciter les pré-requis et post-conditions, avec quand nécessaire (je sais que tout le monde n'est pas d'accord, mais régulièrement les noms d'une fonction et de ses arguments se suffisent à eux-même) une description du rôle du code. Les "doc doxygen" dans lesquelles on peut lire "GetSize(): retourne le nombre d'éléments" me filent des boutons et sont malheureusement les plus répandues de mon expérience.
Après, l'auto-génération ne fait pas tout, surtout quand on a affaire à des usines à gaz dont l'architecture, n'en déplaise potentiellement aux auteurs, n'a jamais été pensée.
Faire du multi-thread parce que c'est la mode, c'est pas ce que j'appelle réfléchir à une archi pérenne et maintenable (dans un truc ou la performance n'est pas critique et ou donc utiliser des processus ou même simplement des IO bloquantes avec du polling aurait suffit tout en étant 1000 fois plus lisible)

Désolé pour la râlerie, mais là, j'avais besoin :/

Je ne commente généralement presque pas mon code, mais j'essaie au maximum d'en expliciter les contrats: le jour ou j'ai lu pour la 1ère fois ce dont il s'agit à changé à tout jamais ma façon de programmer, et honnêtement, je pense que ces quelques heures de lecture m'ont fait gagner bien des jours de debug :)

Le manuel indique:

-s, --shell=SHELL
run SHELL if /etc/shells allows it

et

-c, --command=COMMAND
pass a single COMMAND to the shell with -c

Vue la longueur de la manpage, certains pourraient se poser des questions sur temps de recherche de solution…

Malheureusement, il n'existe pas de solution ultime. Pour que l'on t'aiguille, il nous faut plus d'informations, certaines techniques, d'autres humaines.

Le 1er côté qui viens à l'esprit, c'est, quelles sont les caractéristiques techniques de ta machine?
Les informations qu'il nous faut sont, en particulier et à peu près du plus important au moins important:

• mémoire vive, aka RAM, disponible,
• architecture du processeur (dans ton cas, on sait déjà que tu utilises une archi de type "intel", mais il nous reste à savoir si c'est une machine 32 bits ou 64 bits pour que ce soit complet) ainsi que le nombre de coeurs et la fréquence maximale,
• présence ou non d'une carte graphique, et ses caractéristiques (surtout le nom du GPU, en fait),
• espace disque.

Ces informations permettront de savoir quelles distributions fonctionneront ou non de manière fluide sur ta machine.

Ensuite, côté humain:

• ton niveau en informatique,
• connais-tu d'autres utilisateurs de linux ou d'un autre système libre?
• que fais-tu avec ta machine?
• pourquoi en avoir ras-le-bol de windows? Les raisons potentielles sont nombreuses…

Avec au moins une partie de ces éléments, on pourra te donner des indications concernant quelle distribution sera le plus adaptée à tes besoins et capacités. Plus il y aura d'informations, plus nos opinions pourront être pertinentes.

Mais bon, en utilisant ma boule de cristal, je peux supposer que tu ne connais personne qui n'utilise pas windows, que tu n'as que peu de connaissances en informatique, que ton activité principale est d'aller sur internet, de consulter et répondre aux mails.
De ces quelques informations, je te conseille déjà d'éviter Debian, Fedora, ou archlinux qui sont plutôt réservées à des publics avertis.
Grosso merdo, on t'orienteras probablement plutôt vers Ubuntu, l'une de ses variantes, ou linux Mint.

Si j'ajoute à la boule de cristal le tarot de Marseilles, je gage que la machine en question date de plus de 5 ans, mais peut-être pas beaucoup plus, éventuellement livrée avec windows 7 premium, du coup il est très possible qu'il s'agisse d'un CPU 64bits, avec un GPU et plus de 2Gio de RAM.
Suffisant mais pas énorme, donc je t'orienterais plutôt vers Linux Mint LMDE ou Xubuntu.

Ceci dit, c'est de la pure supposition, très probablement à côté de la plaque: je suis programmeur, pas devin.

Après j'ai rien contre lui, c'est sûrement un gentil garçon :)

Probablement pas, vu le genre employé dans l'écrit :D

Pour le moment, j'utilise virtualbox, mais je t'avoue qu'a terme j'aimerai finir par en utiliser un autre, d'une part pour ne pas être enfermé dans une seule techno, et d'autre part parce que je trouve son interface en ligne de commande mal foutue.

Par ailleurs, il me semblait que le réglage NAT de virtualbox ne permets pas à la machine hôte d'accéder aux machines virtuelles?

tu dois aussi pouvoir faire ce que tu envisages avec ton schema

À vue nez, c'est ce que je voudrais faire. Je vais essayer de chercher par moi-même maintenant que tu m'as passé quelques mots-clés (bond, notamment).

Il faudrait vraiment que j'arrive à prendre le temps d'étudier le fonctionnement des réseaux moi…

Ça reste une bonne idée en soi. C'est juste que ces modules ne seraient pas forcément des pilotes.

En effet. Je n'ai pensé aux pilotes qu'en second, ma première idée à été de refondre vers une architecture type client-serveur, qui permettrait d'isoler de manière claire les sections bas-niveau d'une part entre elles, et d'autre part du code de plus haut niveau.
Mais l'envie de jouer avec des pilotes est malgré tout assez forte :p

Pour ce qui est des écrans, à l'heure actuelle on est sur une interface type texte, oui, mais il est prévu de passer à un truc plus user-friendly.

M'enfin cela ne reste que des pistes de réflexion. Il n'y a rien de pire qu'un standard écrit à l'arrache au départ et qu'il faut ensuite maintenir par compatibilité pendant des décennies (sans exagérer).

Je le sais bien, c'est pour ça que j'ai posé cette question justement: je voulais avoir des éléments pour guider ma pensée avant d'agir bêtement et de risquer de finir avec un truc pire que l'existant (quoique, pour ça, il faudrait probablement que j'en fasse exprès…). Quant à la maintenance, le code à déjà au moins 2 ans, mais cumule à la fois les défauts de jeunesse et une dette technique impressionnante. Enfin, on m'a un peu expliquer les antécédents donc je peux comprendre, mais je n'ai pas trop envie de travailler avec un code aussi inutilement complexe, sachant qu'en plus je vais être le seul à intervenir dessus, théoriquement.

Je vais essayer d'être plus clair:

                  +--- eth0 ---+
LAN domestique ---+            +--- PC --- VLAN --- VM_1
                  +--- wlan0 --+

Ce que je voudrai, c'est configurer PC pour que VM_1 puisse accéder au LAN domestique dès lors que soit eth0 soit wlan0 y est connecté.

Je ne connais pas trop le réseau (ça s'est vu, j'imagine :)) du coup je me suis peut-être trompé sur les noms, voire, très probable, je me mélange totalement les pinceaux.

D'habitude, avec juste une seule interface (sur eth0 qui est configurée en client dhcp, le routeur domestique étant en 192.168.1.1), je procède ainsi:
J'ajoute dans /etc/network/interfaces:

auto eth0.0
iface eth0.0 inet static
  address 10.0.0.1
  network 255.0.0.0
  gateway 192.168.1.1

Puis au démarrage de la machine iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE et ensuite pour chaque machine avec un service que je veux rendre accessible sur le LAN domestique iptables -t nat -A PREROUTING -i eth0 -d <ip externe> -p tcp --dport <port externe> -j DNAT --to <IP:port interne>. Bon, forcément, ça dépend de l'ip d'eth0, c'est loin d'être parfait, mais ça fonctionne.

Je doute fortement que dupliquer ça avec wlan0 fonctionnerait…

Faut bien trouver une excuse pour utiliser les 100 avis quotidiens :)

C'est ce que j'aimerai faire, oui. Le problème c'est qu'entre une carte qui active/désactive des relais et lis des valeurs de capteurs, une autre qui permets la communication avec avec des voitures électriques (pour la charge, protocole ZE ready IIRC), et les autres qui vont arriver pour d'autres projets, j'ai un peu de mal à voir un tronc commun, d'autant qu'a l'heure actuelle on ne peux même pas savoir la version ou le rôle des cartes en les interrogeant (ce qui devrait changer prochainement vu que j'en ai émis l'idée et qu'il y avait de toute façons d'autres corrections à appliquer).

Du coup, il est très difficile de savoir (proprement) quelle cartes sont à quelles adresses sur le bus (dans le cas du 485) voire même sur quel bus (pour les divers 232 et 485).
Accessoirement, toutes les fonctionnalités sont dans un seul binaire, très difficile à maintenir, raison pour laquelle je me suis dit que déplacer le code lié au hard dans des pilotes serait une piste intéressante, pour débloater un peu le bouzin (qui n'est, bien sûr, absolument pas documenté).