freem a écrit 5059 commentaires

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é).

Merci pour ces retours.

Malgré que ça me tentait pas mal, je pense que ce ne serait pas le plus pertinent du coup, ou du moins, pas encore, les diverses cartes à piloter me semblent avoir une interface trop hétéroclite du coup.

Trêve de plaisanterie, mais je me dis quand même que 90% des utilisations des forums/listes de diffusion/réseaux sociaux sont possibles en NNTP et çà serait beaucoup plus efficient.

Je ne connais pas Usenet (trop jeune, je suppose) mais à lire rapidement l'article francophone de wikipedia (intéressant pour le coup), je me dis que c'est une sorte d'IRC permanent… je n'en vois du coup pas trop l'intérêt pour un site web, mais effectivement, j'imagine que la plupart des usages seraient réalisables.
Enfin, je ne vois pas trop comment supporter l'édition de contenu (correction de fautes, collaboration autour d'une dépêche, modération… qui sont des fonctionnalités très importantes à mon sens) du fait de la réplication qui expose à des désynchronisation?

Je sais que tu plaisantais, mais je trouve intéressant de chercher à connaître le fonctionnement global des protocoles, et le http(s) everywhere ne m'a jamais paru si pertinent que ça…

Certains citent la phrase à la quel ils répondent

Ce n'est pas toujours possible, ne serait-ce que parce que sur mon tel, il semble m'être impossible de sélectionner du texte hors d'une zone d'édition quand je répond… ça, et les accents qui sont lourds (du coup, à chaque fois, la prévisualisation ressemble à un sapin de Noël, mais j'ai trop la flemme de devoir faire 2s de manipulation pour chaque accent…) dessus.

L'autre cas est quand on répond à un commentaire court dans sa globalité, et non sur un ou deux points précis.

Du coup, la citation en elle-même, même si c'est un outil puissant, n'est ni forcément adaptée ni nécessairement exploitable. Pour le problème que j'ai avec le téléphone, je suppose qu'il «suffirait» d'ajouter un bouton «répondre en citant»?

Sinon, peut-être que l'on pourrait ajouter dans la ligne «Répondre» un indicateur type «message en réponse à […]»? Ça ne me semble toujours pas idéal, et je doute que ça éclaire tant que ça, ceci dit…

… et c'est les evenements qui sont loin, combines au mode fifo de la page d'accueil.
Que l'on soit un reclus ou simplement habitions (en 4D) trop loin d'un evenement, celui-ci ecrase du contenu plus pertinent, qui a plus d'interet general.

Je ne dis pas qu'il n'en faut pas, au contraire, mais ca serait pratique de pouvoir les filtrer, par exemple avec des points sur une mapemonde, et les gens pourraient ensuite cliquer sur les points (bon, ca, ca semble difficile) et que ca ne remplace pas les depeches/journaux intemporels (sortie de soft, debats, …). J'imagine que le plus simple serait une section pour les contenus localises (dans le temps et l'espace?)?

perso, je vois autour de moi plus de disques mecaniques que ssd: question de prix, sans doute.
Tout ceci etant dit, il y a un point qui fait que l'interet de separer le /boot de / n'est pas necessairement pertinent de toute facon: les distrib tendent a installer les modules dans /lib, donc le kernel en lui-meme, ou meme l'initramfs sont inutiles ou presque en stand-alone…
Perso, je pense que du coup le mieux est de juste avoir une partoche qui contiens un bootloader chaine, ce qui est au final ce qui est fait avec les uefi boot (en fat en plus) et laisser le /boot sur le /.
Apres, je ne pense pas avoir rencontre assez de situations pour avoir une idee vraiment precise du probleme.

Quel est l'intérêt d'avoir le /boot en début de disque, au juste?
Le début de disque (mécanique, j'entend), moi, je le réserve aux données qui sont souvent accédées, le /boot, j'ai plutôt tendance à le mettre en fin de disque du coup, parce que j'imagine que le kernel n'est lu qu'une seule fois… je préfère mettre le /usr en début, qui contient tous les programmes utilisés de façon aléatoire et bien souvent à multiple reprises lors de mes sessions.

Je me plante?

Pour avoir utilisé libyaml, le truc utilisé par le module de python, ben, je ne conseille pas d'utiliser ce truc, en tout cas pas si on veut de la performance et de la stabilité…
Je me suis tapé des segfaults que j'ai pu corriger en moins de 4H (patch envoyé à l'époque en même temps que le rapport de bug, je ne suis pas certain que le rapport ait été accepté, vu que le dépôt semblait mort. Du coup, itou pour le patch logiquement). Et non, ce n'était pas un cas d'utilisation à la con, c'était même un truc très simple.
Pour la performance, quand on commence a hijacker malloc pour qu'il alloue toujours au moins 1 octet, ça crains, et dans la pratique, quand mon code tournait, le CPU faisait du malloc de petites quantités de RAM en permanence, et prenait plusieurs minutes pour parser un fichier de quelques kibi octets.

Du coup, j'ai cherché d'autres lib qui correspondraient à mes standards et dont le code me semblait assez propre. Je n'ai rien trouvé de satisfaisant.
Conséquence, j'ai commencé à lire le standard de yaml, et j'ai compris l'état de l'existant: certes, le yaml, c'est joli et lisible… mais une horreur à traiter, les règles sont floues et multiples et de mémoire, le comportement quand on rencontre un token dépend du contexte…

En Python, les MemoryError en sont de bons exemples. Même si dans 99.9% des cas, cette erreur n'est lancée que si l'utilisateur fait quelque chose d'incorrect, elle peut techniquement se produire dans n'importe quelle opération.

Voir ne pas se produire du tout et avoir l'OOM killer qui entre dans la danse sur pas mal de distributions basées sur Linux, vu que par défaut sur Debian, le kernel est optimiste et considère que les applications n'ont pas besoin de toute la mémoire qu'ils réclament.

Je la trouve assez limitee, cette chanson, je prefere de loin open source de magic mushroom. Pas le meme style musical, certes, mais pourtant j'aime beaucoup le punk, donc ca viens pas de la. Ceci dit… tiens, une question, la chanson est-elle open source?

Je suppose que ca a ete verifie, mais, ton user sous mageia a-t-il acces aux fichiers contenant la bdd?