freem a écrit 5019 commentaires

ls -l c'est juste une commande au hasard pour vérifier la faisabilité.

Bon… j'ai voulu mitiger ma pensée en lisant le sudo su, notamment parce que je reconnais l'avoir commis. Mais le ls dans un script, c'est le pire exemple de hasard… S'il vous plaît les gens, gardez à l'esprit que des enfants peuvent lire ces obscénités et les reproduire, ce qui peut faire subir à des gens bien éduqués la maintenance de ce genre de trucs!
Plutôt que ls, dans un script, utilisez donc find ou (inclusif) stat, il me semble qu'ils sont moins sujets à changement et plus aisés à parser! Sans parler, pour find de la possibilité de changer aisément la profondeur de recherche.

Adl?

Pour ma part, je ne dis pas qu'il faut garder le système d'init sysV

Attention, on confond souvent sysVinit et rc.d. La vraie calamité, dans l'histoire, c'est rc.d, pas sysVinit, même si je trouve quand même que sysVinit en fait trop, notamment les runlevels, qui ne servent en pratique pas à grand chose à mon avis.

Cela dit, vu que sysVinit dispose de fonctionnalités inutiles, je suis également en faveur de le virer.
De mon côté, je cherche des solutions entre-deux.
J'ai adopté runit, mais je tombe au boulot dans certaines de ses limites (quand le fichier run est en exécution, le service est considéré up, alors que si ça se trouve, on essaie juste de vérifier les préconditions… ça se règlerait avec un bête signal à runsv, mais non. De plus, il faut parser la sortie de sv pour savoir si un service devrait tourner… c'est dommage) et je suis tombé récemment sur un outil nommé nosh, qui prétend résoudre certains de ces problèmes.
Accessoirement, nosh prétend être capable de convertir les units de systemd, et implémenter un DSL. Ce sont à la fois les points qui m'intéressent, et qui me font peur: j'ai été énormément déçu par systemd (oui, j'ai cru un jour que ce projet serait capable de faire juste ce qu'on lui demande: gérer les services, mais il continue de grossir et entraîne occasionnellement des failles de sécurité, je ne peux accepter ça d'un PID1) et uselessd à abandonné le suivi justement à cause de ce chaos.
D'un autre côté, pouvoir récupérer les config du PID1 à la mode, proposer un DSL qui évite les forks inutiles (bon, ok, il reste à prouver que les autres imposent l'usage de /bin/sh…) liés au shell scripting, et qui ne lance un service que si les préconditions sont remplies, c'est séduisant…

Je suis désolé, mais je n'ai pas compris l'usage de ce logiciel et, malgré tout, j'ai l'impression qu'il pourrait me permettre de résoudre un de mes problèmes au taf: gérer facilement les comptes utilisateurs.
Bon, je sais que c'est plus ou moins l'utilité de LDAP (je n'ai eu il y a quelques années qu'une formation sur AD, qui semble être une surcouche de LDAP, et je n'ai jamais eu l'occasion de manipuler du vrai LDAP) et justement, c'est là ou je ne comprend pas.

Ce logiciel ajoute quoi à LDAP? Une interface facile à utiliser (facile restant à définir, la ligne de commande ne me fais que rarement peur)? Une possibilité de versionner facilement la config (j'ai cru lire qu'il est maintenant plus facile de faire un diff… pourquoi maintenant, et pas avant?)?

Pourquoi utiliser "sudo su"? Ça me semble moyennement pertinent, non? Juste un sudo devrait faire le taf?

Sinon, compte tenu des contraintes de l'OP, à savoir pas d'installation possible sur les machines distantes, je conseillerais l'usage d'un outil de déploiement sans agent (agentless).
J'ai déjà utilisé un peu Rex, mais pas Ansible qui est plus connu:
* Rex, nécessite perl et un serveur ssh sur la cible;
* ansible, nécessite python et un serveur ssh sur la cible;

J'ai opté pour Rex, parce que mes cibles sont sous Debian (perl obligatoire) et je voulais réduire au maximum le nombre de dépendances. Ansible étant plus connu, il est probablement plus simple de trouver de l'aide.
Pour l'usage que j'ai eu, j'ai trouvé Rex assez facile à utiliser cela dit (même si je n'ai pas eu vraiment le temps de l'apprivoiser complètement).
C'est plutôt pratique: on peut configurer des tâches, des cibles, et des groupes de cibles. À partir de là, il est possible d'invoquer facilement une ou plusieurs tâches spécifiques sur un nombre variables de groupes ou de cibles, y compris en parallèle.

Pour régler le problème des machines accessibles uniquement par une «machine proxy», il est possible d'utiliser les rebonds ou les «proxycommand» ssh, par exemple avec une configuration ssh dans ce goût là:

Host mon_proxy
    User proxy_user
    Hostname proxy.example.com

Host ma_cible_1
    User cible_1_user
    Hostname cible_1
    ProxyCommand ssh -C mon_proxy /bin/nc -U %h

Juste un commentaire sur l'extrait plus haut: mes cibles à moi, elles sont derrière des liens GPRS, du coup pas d'accès direct.
Les cibles établissent donc un tunnel inversé, non pas vers un port de la machine distante, mais vers un fichier de socket UNIX dont le nom dépend de la cible: ça facilite l'allocation de l'identifiant, vu que ce fichier est généré en fonction de l'identifiant de la cible. Et puis, pas besoin de se souvenir si ma_cible_1 utilise le port 2222 ou 2223: il suffit de lister les fichiers.
Ça implique le netcat d'openBSD, mais s'il n'est pas disponible, on peut utiliser des trucs plus standard, c'est juste plus chiant. Pour le coup, j'ai l'avantage d'avoir les accès root sur tous mes systèmes :°

Sérieux, une disquette pour « enregistrer » ? Ceux qui ont moins de 20 ans n’en ont jamais utilisé de leur vie.

Cool.
Donc, on remplace par quoi? Les «d'jeuns» n'ont jamais vu de périphériques de mémoire morte, sauf les clés usb, qui ont la même forme que les dongles pour claviers sans fil, notamment.
Alors, on fait quoi, on mets une icône de périphérique USB pour tout, histoire que, tous, y compris les vieillards de 30 ans soient perdus?

Ça fait quoi, qu'un symbole soit utilisé pour des raisons historiques et que l'on n'en connaisse plus le sens? Moi, perso, le symbole du crâne humain, je n'en connais pas le sens originel, mais je l'associe sans problème à une idée. Même chose pour bien d'autres symboles.
L'intérêt des symboles qui restent les mêmes au court du temps, c'est bien justement de ne plus nécessiter l'adaptation aux modes et évolutions pour une fonctionnalités… remplacer un symbole, pourquoi pas, mais seulement si au moins la majorité de la population ne le connaît pas, et, ici, la disquette, c'est juste les moins de 20 ans (selon toi) qui ne connaissent pas.
Si on se base sur une espérance de vie moyenne de 60 ans, c'est 2/3 tiers de la population qui s'y sont habitués (je fais comme toi, je prend des chiffres sans source, notamment sur l'espérance de vie).

Bref en terme de design il faut toujours se remettre en cause, s’adapter au monde mais pas n’importe comment.

Se remettre en cause, ça n'implique pas de considérer que tout ce qui est, est mauvais et moins bien que ce que l'on imagine. Remettre en cause, c'est bien, casser les codes et les trucs qui s'implantent peu à peu, c'est pas si souvent bien.

Alors autant il a raison sur le point que je n'ai pas écouté, pour diverses raisons:

• j'étais au taf à ce moment la;
• mes machines perso m'ont lâché (physiquement, en série… oui, j'étais la cible de Murphy);
• j'ai déjà vu ce genre de sujets passer, j'ai plus répondu à ces sujets qu'à l'article lui-même, je l'admets;

Par contre, me reprocher de sortir des poncifs quand le point d'accroche lui-même en est un (pour info, je viens de vérifier sur un dico, le terme "poncif" inclue "idée reçue", le titre de l'article lui-même est donc un poncif) me semble mesquin, surtout sans argument.
Perso, j'ai réagit d'une part au texte du journal, sans pouvoir accéder au contenu vidéo (déjà, un contenu vidéo, c'est beaucoup de vide et de faux semblants, comparé à un contenu texte), mais aussi aux commentaires (à ce journal) qui disaient à ce moment que dans le libre tout est moche, sous entendu: c'est mieux dans le fermé. Et, oui, j'ai perdu mon calme. Mais au moins, j'ai essayé d'argumenter.
Toi, en revanche, tu te contentes d'enfoncer quelqu'un sans la moindre tentative de développement.

Si l'usage de partoches réseau en état et de partoches locales en vrac t'es habituel, ma foi, je pense que tu ferais bien mieux d'utiliser un PXE….

Mais c'est bien d'avoir des couches. Le but de ces couches est de mutualiser le travail, ne pas réinventer la roue, avoir des composants plus solides.

J'ai moinssé pour cette phrase précise, alors que je ne comptais pas intervenir dans un thread mort… mais la, non.
Dans le cas de systemd, ça reste discutable, honnêtement. Moi, je n'apprécie pas, avec probablement de mauvaises raisons, éventuellement de bonnes: par exemple, je pense qu'un PID 1 ne devrais que se contenter d'initialiser le système, et lancer un superviseur pour les logiciels qui ont besoin de l'être. J'ai l'impression, du haut de mon manque d'éducation, que systemd utilise le même processus, et donc le même fichier de code source, pour initialiser le système ET superviser les daemons.
Sur ce point, je trouve sysVinit mieux foutu dans le sens ou sysVinit ne supervise (sisi, il supervise un peu, prenez une distro avec lui, et mettez /bin/false à la place de /sbin/getty dans l'inittab…) que des outils peu intelligents: basiquement, il ne supervise que agetty sur une Debian. Il me semble donc plutôt capable de superviser un superviseur plus puissant, qui ne lance les services qu'à la demande et/ou que après que les pré-conditions soient remplies.
Le problème est qu'il n'offre aucun outil qui permette de le faire, et donc, chaque distro s'étant basé sur sysVinit, à bricolé son gestionnaire de daemons, à grand coups de bourne scripts plus ou moins bien ficelés… et le résultat est ingérable pour Debian (mon opinion).
Donc, dans le cas de systemd, je peux accepter cette phrase.

La raison pour laquelle j'ai moinssé, j'ai parce que, au taf, j'ai été confronté à npm. Hors, des… gens… probablement très intelligents… hum… oui, ça doit être ça… fournissent un module pour tester si un nombre est négatif. Ce module, s'appuie sur un module qui teste si un nombre est positif, et en inverse juste le résultat.
Penses-tu vraiment que c'est toujours bien d'avoir des couches? Ne penses-tu pas que le fait d'ajouter, et d'utiliser, une couche doit être réfléchi en fonction du cas d'usage?

L'exemple que j'ai pris est, franchement, extrêmement stupide (mais tristement réel), contrairement à systemd. Mais dans le cas de systemd, je pense que dans certains cas il ne se justifie pas, par exemple est-il utile d'avoir la complexité de systemd qui dépends de dbus et d'une implémentation maison de cron dans un système embarqué, ou la taille des binaires compte?
Dans cet exemple, je crois qu'il n'est pas bon d'avoir des couches, car ça complexifie le débogage (il faut déboguer toutes les couches alors que potentiellement juste attaquer le matos peut être plus simple) et à un coût non négligeable en bande passante réseau (corriger les failles de sécu sans trop impacter le forfait pas cher est parfois un voeu du chef).

Et bizarrement, il n'y a pas grand monde pour se bouger à maintenir les scripts init à l'ancienne, preuve que pas grande monde trouvait SysV si bien que cela à maintenir et à l'usage…

Je connais par l'usage au moins 2 distributions non basées sur systemd. L'une est voidlinux, basée sur runit, l'autre est devuan, et j'ai cru voir un article sur lwn disant que, justement, les tensions se calmeraient pour garder en vie le vieux sysV. Si ça se fait, compte tenu que devuan (que peu ici imaginaient faire le boulot nécessaire pour réussir à publier une version stable) compte passer à openrc (de ce que j'ai compris sur irc, hein), j'imagine qu'il n'est pas impossible qu'un jour, sysV soit lâché, mais d'avoir une alternative à systemd.

Je pense que la réalité est plus complexe que ce que ne veulent faire avaler les gens qui soutiennent absolument systemd. L'inverse est malheureusement vrai aussi.

Je sais que c'est tard, mais bon…

J'ai l'impression que ce dont je rêve n'existe pas : un CAD libre et simple pour déposer un permis ou une demande préalable.

La raison est simple: même en enlevant l'aspect libre, c'est impossible de faire un CAD simple à utiliser pour un permis de construire.

Déjà, les réglementations de permis de construire, ça change selon les pays, et rien que ça, ça rend les choses complexes.
Ensuite, même dans un pays unique, ton permis de construire sera ou non accordé en fonction de bien des paramètres, tels que les plans d'urbanismes: on n'a pas le droit de faire n'importe quoi en france si on habite à moins d'une certaine distance d'un bâtiment classé (je le sais, parce que mon père justement doit gérer de l'urbanisme, entres autres, il est naturel que le grand public ne l'imagine pas), il existe aussi le problème de la stabilité des sols (chez nous, y'a pleins de marnières non référencées, de falaises surmontées de bâtisses dont il ne reste que la moitié, ce genre de choses, mais on peut aussi parler ailleurs de lits de rivières, et sûrement bien d'autres sujets que je n'imagine pas, tout comme mon père n'imagine pas la complexité d'un logiciel qui se contente d'afficher l'heure exacte…).
Et quand à parler de matériaux, il faut comprendre que certains sont plus ou moins résistants, voire illégaux dans certains endroits (le plomb et l'amiante, en france, par exemple).

Pour conclure: un rêve, on n'en approche qu'en essayant de le réaliser, surtout quand ça implique une absence de propriété intellectuelle :)
Et qu'on vise ou non cette absence, on ne l'atteint probablement jamais.

Zut quoi, je faisais quelques recherches pour essayer d'avoir un protocole sécurisé ultra-léger (pour de l'embarqué) entre un client et plusieurs serveurs qui se connaissent à l'install, je tombe sur la mention qu'IPsec est implémenté dans le header d'IPv6 (qui est juste 2 fois plus gros qu'IPv4: on passe de 20 octets minimum à 40 octets minimum, quand c'est pour trimballer 10 pauvres octets à la minute, ça fait cher de l'overhead quand même).
Je me dis «tiens, ben si ça me vire l'épine de la sécurité du pied, je veux bien voir si ça vaut le coup d'envoyer chier la compat IPv4!», je lis la manpage et….

IPSec support for EH and AH headers is missing

hé merde…. ceci dit, avec la change, le

This man page is not complete

qui suit implique peut-être qu'en fait, si?

Bon, je vais quand même aller me renseigner sur le sujet, après tout, je ne sais même pas encore ce que sont ces machins, et puis, même si linux n'implémente pas ça, p'tet que d'autres systèmes le font, eux (ça serait l'occase de changer de noyal).

C'est quoi, être beau? Franchement?

Non, parce que moi, je trouve que i3+rxvt+ncmpcpp+aptitude+xosview, ben, c'est pas moche. C'est simpliste, oui, mais moche, non.

Par contre, l'interface de windows XP, je l'ai toujours trouvé plus laide que celle de ses prédécesseurs, vista à ajouté la transparence, histoire d'en voir moins… parce que c'était moche, j'imagine. Justement. Mais le résultat, je le trouve pire, c'est con.
Les dernières itérations des windows que j'ai vues, je n'ai pas trouvé ça joli, j'ai trouvé ça surchargé, inconstant. Et dès qu'on rajoute des softs propriétaires non microsoft dessus, ça deviens même bordélique. De l'art moderne, je suppose?

Sinon, ces dernières années, j'ai vu le "dessin plat". Moué. Ça dit bien ce que ça veut dire: c'est plat. C'est chiant. On en chie à distinguer un élément de l'autre. Y'a pas ou peu de contraste. C'est censé être beau?

Et puis d'abord, un logiciel devrait-il être une oeuvre d'art? Un tableau de je-ne-sais-qui?
Non.
Un logiciel, c'est un outil, il doit être efficace avant tout, et l'esthétique me semble plus souvent entraver l'efficacité qu'autre chose, en plus d'être subjective.
De jolies icônes ne seront pas forcément simples à distinguer l'une de l'autre quand elles se multiplient (sans parler du fait de jouer bien avec les niveaux de zoom).
La transparence et les dégradés qui font qu'on est jamais trop sûr de ce que l'on va faire, impliqueront peut-être, à force, de devoir acheter un système plus puissant, avec plus capacité de stockage, pour quoi? Pour un truc 100% subjectif.

On parle de la beauté des icône, peut-être? Ok. Moi, je trouve que c'est n'importe quoi, de manière générale. Trop de couleurs, des dégradés, des traits grossiers…
Je préfère de loin les blasons: l'héraldique, c'est un tout petit ensemble de règles qui permets de bien identifier sur qui il faut taper dans la mêlée, même par mauvais temps. D'ailleurs, c'est p'tet moche et un truc de vieux, mais au final, les «icônes» du code de la route, elles respectent ces règles. Sont-elles open-source?

Pour conclure, avant de nous sortir ce genre de stupidité, il serait peut-être intéressant de comparer un ensemble de logiciels représentatif du logiciel libre, à un ensemble de logiciels représentatif du logiciel non-libre.
Je ne suis vraiment pas sûr que le logiciel libre ait à rougir, en admettant qu'il y ait une raison de chercher "la beauté" (et que celle-ci soit identique pour tout le monde, compte tenu du fait que, justement, le logiciel libre permets d'avoir des logiciels à ses goûts et ce, même si ces derniers diffèrent de la masse).

Quel est l'avantage concret ?

Le même que foutre une partition D: pour les données utilisateur? Autrement dit, permettre un réinstallation simple du système sans avoir à exporter les profils un par un?

Quant à l'expert qui y tient absolument, c'est toujours possible de le faire.

Je ne sais pas pour toi ni pour les nouvelles versions de windows, mais, j'ai essayé, lors de windows XP, de le faire.
Techniquement, oui, c'était possible. Il fallait pour cela installer 2 windows, un principal, et un autre qui ait pour seul objectif de manipuler le schéma de partitions du windows cible.
Ça à changé?

Je parle bien de coller juste le %HOMEDIR% sur une partition à lui. D'ailleurs, je n'ai pas poussé le vice à le mettre sur un disque dur séparé, pour voir si un profil peut se charger dynamiquement. Avec Linux, c'est facile, avec windows… hum.

Mais, oui, pour le particulier qui n'a jamais de soucis, ça ne sert à rien. Sauf que moi, j'ai connu plusieurs personnes qui ont perdu des disques juste parce que le système était flingué.

compliquer l'utilisation quotidienne

Faux. Tu peux juste définir un point de montage, ça marche comme sous *nix/nux en fait, mais c'est caché, reservé aux experts…

Quelque part, c'est drôle de voir que certaines choses ne changent pas.
Désolé d'avoir dérangé votre entre-soi en voulant partager mon retour d'expérience.

Ho, ça va hein, linuxfr est peuplé entre autres de gens normaux, qui votent par la forme, pas par le fond.
Et il est clair que ta forme est merdique, 3 lignes pour un article aussi intéressant en anglais… Tu aurais clairement pu faire un synopsis plus intéressant. D'un autre côté, je préfère 100 fois ça à un vulgaire lien, lierait-il à un article en français!

Si t'avais juste voulu de la pub, t'aurais posté un lien, et tu n'aurais que peu été exposé à la vindicte. Tu as eu le courage de faire un journal, et certes la forme manque, mais à lire en diagonale, j'ai eu la sensation que le journal (et le lien) était sincère, même s'il ne semble rien apporter de neuf.

Ce que tu tu aurais pu faire, pour te faire moins massacrer, c'est résumer, au lieu de juste sortir une phrase d'attaque traduite.

Tu cherches à dire quoi, par la? T'as déjà vu un travail pas en progrès dans le libre toi? Me semble que, dans le libre, un travail pas en progrès, on appelle ça…. UN PROJET MORT!!!!

Pourrais-tu, s'il te plaît, mettre un lien vers ces fameuses 5 photos? Parce que, en effet, je les ai vues, mais j'ose espérer que tu ne reproches pas à l'auteur d'avoir son avatar devant chacun de ses messages?

Je sais que je suis pas à l'heure, mais, systemd fait-il vraiment partie des meilleurs technologies du monde UNIX?

Perso, je pense qu'avant ça, il serait intéressant qu'ils intègrent un mécanisme permettant de gérer les bibliothèques nécessaires par les versions des logiciels installés volontairement.

Ensuite, la séparation lors de l'installation des partions qui incluent les données utilisateurs des données système.

Et, pourquoi pas, un terminal à la taille dynamique… sans parler du chez nous fameux mais ignoré de tout windowsien qui se respecte, bureau multiple, voire, soyons fous, de ne pas avoir besoin de chercher ces putain de bordures pour déplacer ou redimensionner une fenêtre? (je n'ose mentionner mon vrai rêve, celui d'avoir un twm vraiment supporté, le jour ou je devrais y retourner)

Salut.

Désolé d'embêter, mais, cette liste n'est greppable que par nationalité puis par ville. Dans le cas de la France, il faut parfois faire 800 bornes pour atteindre une ville.
Je me disais qu'il serait peut-être intéressant de faire une liste greppable par nationalité, puis index, acronyme ou nom de département, puis ville?

[Edit] et pour pousser le bouchon, si c'était trié par ordre alpha, ça aiderait peut-être? [/edit]

Pas idiot le triple `

Bah, ça me permets de faire moins d'efforts pour comprendre, et tant mieux si ça aide les autres.

Commande système pour printf, ne sais pas les effets de bord possible

C'est simple: les mêmes que pour echo, le flou en moins, la flexibilité en plus. Globalement, printf semble être plus recommandé, bien que je n'aie pas de source à citer.
Ce qui est certain, c'est que juste le 1er paramètre détermine ce que tu afficheras réellement, et que les options de format sont nettement plus riches. Reste à savoir le poids du binaire en RAM et en ROM, qui peut impacter des usages embarqués. Mais dans l'embarqué, il est ridicule d'utiliser GNU, mieux vaut partir sur un *BSD ou busybox, le code est nettement plus concis, souvent en sacrifiant les locales, mais, c'est l'embarqué…

En tout cas, l'important, c'est que tu sois content :)

Sinon, je n'ai jamais utilisé (contrairement à fossil que j'ai utilisé de manière expérimentale et git que j'utilise à la fois au taf et pour mes projets persos, mais sans maîtriser), mais j'en ai lu énormément de bien, mercurial.
Je sais que c'est étrange, normalement on est censé défendre la technologie que l'on utilise, ne serait-ce que par résistance au changement… mais, pour moi, les 3 (D)VCS les plus intéressants sont (pas ordre d'intérêt personnel, pas par ordre d'usage réel personnel) fossil, git, et mercurial.

Fossil à l'avantage d'être une forge, et comme ma religion me dit d'utiliser surtout du code natif ça colle, mais, je ne sais pas encore l'utiliser, surtout dans le cas de projets liés entres eux…

Git permets de référencer d'autres projets, via les submodules, est intégré à toutes les forges qui ne veulent pas gérer le versionnage, et est codé en natif aussi. C'est aussi l'outil le plus célèbre, et le fait que j'ai du apprendre par moi-même d'abord SVN, puis git m'a déjà été dur, alors j'ai surement une forte résistance au changement de ce côté… d'autant que je reste un dev, quelqu'un qui vise à automatiser son propre taf pour être payé à ne rien faire d'emmerdant!

Mercurial est le l'outsider de git.
Il prétends apporter la facilité d'usage, mais rien de plus (pas de fonctionnalités supplémentaires).

Côté subjectif, mercurial… est codé en python, et d'une part le côté interprété du langage et d'autre part mon expérience des paquets pythons dans debian (oh, la jolie dépendance manquante! non, j'ai pas de source, juste vécu trop souvent, et non, c'est pas la faute du langage, juste des dev et empaqueteurs qui ne se basent pas sur un système strictement minimal pour définir leurs dépendances) font que j'ai deux arguments plus ou moins foireux en faveur de ma résistance au changement.

Ce que je retiens de ton message, c'est que, en théorie, c'est possible, mais en pratique ça n'a jamais été fait.

Cela dit, lire ton message me fait me demander si utiliser une forge type redmine (qui ne versionne pas, nous sommes d'accord) qui expose une API (REST, me semble) pour gérer les tickets ne permettrait pas justement de servir d'intermédiaire entre divers projets utilisant chacun divers (D)VCS et bugtrackers… en gros, s'il ne serait pas possible d'utiliser des forges classiques comme des agrégats de forges, ça permettrait vraiment de bosser sans être connecté, tout en permettant de lier des tickets à des tickets d'autres projets. La, fossil serait vraiment une putain de bonne solution!
Parce que bon, qui n'a jamais cherché à intégrer la gestion des tickets à son git, sérieusement? Le wiki, ok, c'est overkill, quoique, ça permets de documenter, ce qu'on a tant de mal à faire… bon, ok, je suis peut-être le seul, mais à voir l'état global des docs de libs, j'en doute…

Bref, tout ça pour dire qu'on peut comparer Fossil et Git sur la partie gestion de sources.

Mais pas sur la partie intégration avec d'autres logiciels, avec un éco-système.
Je pense très sincèrement que fossil est un projet intéressant, très adapté à certains cas, tout comme git l'est à d'autres, et seules la flemme et la dépendance à un langage interprété m'ont fait rejeter mercurial qui semble de réputation plus adapté à la majorité des projets (la flemme étant l'argument principal, qui n'est pas contrebalancé par la réputée meilleure facilité d'usage).

Et c'est quand même une sacrée preuve que les développeurs croient en leur produit, que de l'utiliser eux-même. D'autant que bon, sqlite est pas vraiment inconnu des développeurs, et j'ai jamais lu ni entendu de mal à son sujet.

Comment, dès lors, ne pas être intéressé par fossil, même sans jamais avoir eu la combinaison temps+motivation pour apprendre à s'en servir?

Je t'avoue que je ne vois pas, sur ce coup, et je suis curieux d'en apprendre plus (d'autant qu'on m'a déjà posé la question de pourquoi j'utilise pas rebase: parce ce que je ne sais pas ce que ça fait fut ma réponse honteuse).

Si je te suis, tu commit toutes tes sessions de code sale dans une branche séparée (je suppose, pour la branche) périodiquement, et à la fin, tu prends un morceau de ce commit-ci, un morceau de ce commit-la, pour faire un commit neuf et propre, et ce jusqu'à épuisement du pool de modifications?
Hum, je doute de t'avoir compris en vrai…

J'ai déjà vite fait essayé avec ce que savais utiliser un peu, blender en l'occurrence.
Une blague, c'est vraiment pas adapté, vraiment pas fait pour, et vraiment une idée débile. Utiliser un logiciel de dessin vectoriel 2D comme inkscape (comme dit plus haut) me paraît, désolé, mais vraiment être du masochisme.
Ceci dit, il faut dire que lors de mes années lycées, j'avais appris les bases de la CAD avec SolidWorks, donc j'avais un vague souvenir du confort.

Du coup, j'ai fait pas mal de recherches, demandé sur IRC… et en gros, je suis tombé sur 4 logiciels libres (ordre de citation alphabétique, quasi du moins utilisable au plus utilisable, pratiquement du plus facile à connaître le nom au moins facile):

• brlcad
• freecad
• openscad
• solvespace

BrlCAD c'est… un truc qui à l'air super complet, développé et utilisé à priori depuis plusieurs décennies notamment par l'armée des USA.
Le problème, c'est que c'est plein de tout petits programmes, qu'on sait pas trop à quoi ils servent chacun, et leur usage n'est pas instinctif.
Il existe un paquet Debian sur sourceforge, qui utilise des libs qui datent de Debian Jessie. Perso, quand je l'ai testé, je suis tombé sur des bugs de rendu que je suppose être liés au fait d'utiliser des binaires incompatibles.
Au moins, j'ai pu faire quelques bricoles et avoir un aperçu de quel outil utiliser pour faire quoi.

FreeCAD, c'est le 1er sur lequel on tombe. Et le pire.
En tout cas, de mon point de vue, j'ai eu l'impression d'un logiciel qui explose pleins de fonctionnalités non finies voire même non implémentées, une interface qui change tellement souvent qu'une doc de plus de 2 ans t'en montre une qui n'a rien à voir, une quantité d'atelier tellement riche que tu sais pas qui fait quoi…
Un bordel sans nom, dans lequel je n'ai pas réussi à dessiner un simple rectangle.
En somme, une expérience caractéristique de l'usage d'un logiciel au stade alpha, ce qu'il est en pratique, donc mon ressenti est normal, vu que je voulais un soft utilisable, pas un soft de CAD auquel contribuer.
En pratique, même si c'est le pire des 4 dont je parle, c'est le plus à même d'être utilisé pour faire les plans d'une maison, avec peu d'apprentissage.

OpenSCAD, c'est… l'OVNI. Il se qualifie lui-même de logiciel de CAD pour les programmeurs, du fait que l'on programme ses pièces.
En soit, je l'ai trouvé plutôt intéressant, mais in fine, il demande plus de compétences mathématiques qu'OpenGL pour une simple rotation d'un ensemble.
J'ai failli l'adopter, étant programmeur et vraiment séduit par l'idée, mais j'ai abandonné quand j'ai compris qu'il ne disposait d'aucun moyen natif de placer un élément en fonction de la position d'un autre. Faut vraiment tout faire à coup de trigonométrie…

Le dernier, mon préféré, est SolveSpace.
Il ne répond pas, en soit, à ton besoin et est probablement le plus moins évolué des 4: il n'intègre pas de bibliothèque de matériaux (à l'installation, hein. En gros, faut la faire soi-même ou la récupérer quelque part), il ne permets pas de faire joujou avec des textures ou des couleurs (ou alors je suis pas au courant…), pas de simulation de mouvements, pas de RDM…
Rien de tout ça.
En lieu et place, une interface graphique qui permets de placer des points, des lignes, des arcs, des ellipses, de définir des écarts, des angles… le tout en 2D. Puis, il permet d'appliquer diverses méthodes de combinaison entre 2 dessins 2D: extrusions, opérations logiques (or, xor, and, et les variantes inverses).
Il permets aussi de gérer simplement plusieurs pièces, d'en placer une par rapport à une autre, et d'indiquer les endroits ou il y a des collisions.

Mon projet à moi, c'était de dessiner le plan d'une sorte de bureau pour servir de labo électronique/prog/impression 3D. Bref, un truc sorti tout droit de mon imagination, en me mettant trop de contraintes parce que sinon c'est pas drôle. Je m'y remettrait, en regardant d'abord les trucs qui se vendent dans le commerce, ou juste faire un modèle de PoC, je sais juste pas comment m'y prendre: paraît que c'est un métier, et il est certain que c'est pas le mien :)
Mais ça reste un objectif relativement simple, à portée de bidouilleur.

Pour ce qui est de ton projet à toi, si c'est juste dessiner des murs et placer des meubles, je pense que ça peut le faire. Si il faut ajouter des chemins de câble puissance ou signal, avec un peu de plomberie, ça me paraît faisable aussi, mais nettement plus complexe (cela dit, si tu procède méthodiquement, c'est facile, mais le problème est bien là: être méthodique, c'est difficile). pour ça, il te faudra un soft du genre FreeCAD ou BRLCAD, ou un logiciel non libre.
Dans tout les cas, c'est du travail d'ingénierie, et ça demandera de l'apprentissage (du soft à minima), pas qu'un peu (et aussi du métier, de la méthode…). C'est logique en même temps, je m'attendrai jamais à ce qu'un maçon me file le call graph ou un diagramme de classes d'un logiciel qu'il veut que j'écrive (en plus, ça m'énerverait).

En tout cas, bon thread, j'ai lu pleins de noms de softs à tester ici :)

Ou mieux: utiliser printf, qui est plus puissante, dont le comportement est, il me semble, moins dépendant du shell utilisé, et surtout, on sait que seul ce qui est dans la chaîne de formatage sera affiché, il n'y a pas besoin de se demander si l'option "--truc" est connue ou non.

Sinon, si l'anglais n'est pas une barrière, il y a ce bon vieux grymoire.com/ qui peut aider à comprendre ton script initial (et aussi, pour marquer les blocs de code, utilises le ```bash en 1ère ligne précédée d'une ligne vide pour commencer et le ``` seul sur une ligne après la fin, le résultat est plus lisible).