freem a écrit 4934 commentaires

Ils ont fait les choses bien :)

Je vois ça.

A noter que ce que fait Wine, a déjà été fait dans l'autre sens, via le projet Cygwin !

Oui, je connais cygwin.
Par contre, tu te trompes, ça n'à rien à voir avec un «wine inversé». Je cite:

Cygwin is not:
a way to run native Linux apps on Windows. You must rebuild your application from source if you want it to run on Windows.

Et personnellement, la fois ou j'ai essayé de l'installer, je l'ai trouvé trop pénible. Ça remonte, mais, de mémoire, le "gestionnaire de paquet" (enfin, l'outil qui indique ce qu'on essaie d'installer) n'était pas spécialement agréable à utiliser et pullait beaucoup de chose, histoire de bien pourrir la bande passante.
Là, quelqu'un l'a installé sur une VM au boulot, et ça fait plus comme si on faisait tourner "linux" sur windows, que comme si on avait accès aux outils "linux" sous windows (ok, pas linux, les coreutils en fait).

Perso mon kit de survie sous Windows ne l'inclue pas, j'avais trouvé les coreutils portés sous windows, et maintenant il suffit d'installer git pour se retrouver avec bash, ssh, grep, find & co. Pour l'émulateur de terminal j'ai trouvé il y à quelques temps conemu, et pour la compilation mingw fonctionne très bien.

Loin de moi, très très loin de moi même, de considérer que l'écriture d'un kernel est facile.
J'ai beaucoup d'admiration pour le projet, mais ça ne m'empêche pas d'être réaliste, et en tant que développeur, même si j'en reconnais l'intérêt pédagogique ou pour debug une appli windows sans avoir à payer une licence (je prie pour que le jour ou je referais du dev spécifique windows soit le plus loin possible, ceci dit), voire pour permettre de détecter les bugs et comportements indéfinis plus facilement (plus on peut tester sur de nombreux environnements, plus on à de chances de trouver, et corriger les UB avant que ça n'explose), il n'empêche qu'il ne me viendrait pas, en l'état, l'idée de baser du travail sur ReactOS. Sauf si j'en venais à avoir le niveau + la motivation + le temps de travailler sur ReactOS lui-même, bien sûr.

Quant au fait que wine et ReactOS soient complémentaires, ça me semble évident. On discutait juste du niveau de profondeur de la complémentarité (en tout cas, en ce qui me concerne).

les API : ben c'est Wine :p

Je ne pense pas. Notes: je ne pense pas ;)
Et ce, parce que même si je suis sûr qu'une bonne partie de l'implémentation de wine est en commun, il y à un moment où il faut cogner dans le kernel: lister les processus, ouvrir un lire un fichier de façon non-bloquante, ce genre de choses. Et là, je ne vois que 2 solutions:
1) ReactOS est POSIX (ou essaie de l'être sans en être sûr, comme Linux donc). Dans ce cas, on passe du kernel vers une DLL vers le kernel à nouveau… niveau perf, ça me semble mauvais, et dans ce cas autant utiliser directement un kernel plus classique.
2) Reactos n'est pas POSIX, et dans ce cas, il faut implémenter les APIs les plus basses soi-même, ok, tout en pouvant profiter d'une partie de wine.
À mon avis, l'option qu'ils ont prise est la 2nde.

Dans un sens, le travail de Wine est beaucoup plus compliqué,

Dans les 2 cas, il y à un travail énorme de reverse engineering, mais dans le cas de ReactOS tu as, en plus, besoin d'être assez pointu pour être capable d'écrire les outils de gestion de la RAM, et de mémoire, ce n'est pas trivial du tout. Je ne parlerais pas des techniques d'adressage "sécurisées" parce que je ne pense pas qu'ils s'embêtent avec ça au stade alpha…

pour moi, c'est la condition de base pour qu'il soit auditable.

Il y à plusieurs façons de trouver les problèmes d'un système:
1) le regarder de l'intérieur, lire le code, qui permets de trouver certains problèmes mais sûrement pas tous, parce que la programmation, c'est compliqué, surtout quand ce n'est pas toi qui à écrit le source (ou que ça date un peu).
2)le fuzzing, qui lui me paraît nettement plus efficace en terme de rentabilité (temps passé / problèmes trouvés). Pas besoin de connaître la programmation ici: suffit de trouver, aléatoirement ou par brute force, un moyen de faire tomber la cible.

Perso, si je devais faire tomber les logiciels dont j'ai le source au taf, je te promets que je n'essaierais pas de les lire: vue la gueule du source, j'y perdrai ma santé mentale. Non, une bonne séance avec ces bons vieux netcat/wireshark me semble bien plus efficace, et c'est encore mieux si je sais à quoi l'outil est censé servir… d'ailleurs, c'est là que nmap peut entrer dans la danse, si tu fais une attaque complètement à l'aveugle.

J'ai dû mal comprendre. COMPILIBRE, ce n'est pas le logiciel qui sert de gestionnaire de paquets? Je pensais que c'était les logiciels proposés qui allaient être testés sous ReactOS.

C'est vrai, mais la tâche de ReactOS est d'un tout autre niveau que celle de wine: la ou wine implémente de "simples" APIs, ReactOS c'est une distribution complète, kernel, pilotes, environnement graphique…. et APIs, bien sûr.

Au préalable, attention, méthode expérimentale et… bon, évites de faire ça si tu tiens aux données du disque cible. Comme d'hab avec les partoches & co: backup, blabla…

Si tu veux un truc plus graphique que debootstrap—au niveau de l'installation du moins—(j'ai vu l'argument dans le thread précédent) tu peux aussi utiliser virtualbox pour créer un disque virtuel bindé sur une partition ou un disque physique.
Je te conseille fortement de ne pas le faire sur le disque que tu utilises avec ton système: j'avais testé (boot sur debian d'un HD externe, lancement de vbox, tentative d'install de netbsd sur une partition préparée à l'avance sur le même disque externe. Ça à flingué ma table de partoches au point de faire un DoS par udev. Oui, je voulais jouer ;) ).

La commande pour créer un disque lié à un fichier dans /dev, c'est: vboxmanage internalcommands createrawvmdk -filename <path/to/vmdk> -rawdisk </path/to/physical/disk>. L'utilisateur qui fait l'opération doit faire partie du groupe disk, bien entendu.

Je suis intrigué, vraiment.

J'aime bien l'idée, tant de distribuer des outils qui marchent sous ReactOS que l'idée même de ReactOS, mais la dernière fois que je l'ai testé, il était d'une simplicité enfantine de générer un BSOD, juste en changeant les locales et en allant jouer avec les menus.

Ne serait-il pas plus pertinent, et plus économe en terme de temps pour ceux qui feront le travail, de se concentrer sur wine, qui au moins ne fait pas segfault le kernel, et ça permettrait de faciliter les transitions de windows vers linux (avoir des outils dont il est «garantit» qu'ils marchent aussi bien sous win que sous wine aide. Je dirais même que je doute qu'il soit possible de faire autrement sans une sacrée dose de volonté).

PS: je pense que si j'avais voulu faire de la pub autour d'un tel projet, j'aurai au moins cité certains logiciels phares. Le secret du contenu ne fera pas grand chose: il suffit probablement d'aller sur framasoft pour deviner les noms.

Me suis mal exprimé.

C'est vrai, certains vont aller jusqu'a dédoubler le réponses de quelqu'un d'autre (dans le genre productif, on à vu mieux). Pour autant, je ne pense pas que ce soit la majorité. Il m'est déjà arrivé d'avoir des scores très négatifs, et pourtant seules 2 ou 3 personnes répondent (dont, en général, 1 qui… "s'inspire" des commentaires précédents pour dire la même chose).

J'aime beaucoup ta citation en tout cas.

Ouais mais tu est quand même beaucoup plus calé que moi, déjà tu a semble-t-il étudier l'informatique a l'école, moi je suis autodidacte

C'est vrai… mais j'ai appris avant de toucher au code en cours, résultat je n'ai pas appris grand chose à l'école. C'est le temps qui fait que je suis un peu meilleur, rien d'autre amha.
Enfin… pour être exact, je dois aussi préciser que mon seul diplôme obtenu, c'est un bac STI électronique, ça aide aussi j'imagine.

Le compilateur construit une table de symboles d'après l'analyse du code source:

Oui, mais ton noyau doit être capable de retrouver ces symboles dans d'autres binaires, et ça, ça à un coût au runtime, et si ta lib expose trop de symboles, tu perds en vitesses sans y gagner en espace mémoire (voire pire: en y perdant, comme c'est par exemple le cas avec /bin/yes, qui pèse 31Kio chez moi… juste pour flooder une string identique à l'écran, c'est énorme! Et si on veut être exact, on rajoute la taille de la libc.). Je préfère ne pas trop en parler, je dirai des conneries (il faut que je prenne le temps de lire ce fichu pdf…).

Oui, je sais. Ce n'est peut-être pas le gars le plus efficace, ni le plus prolifique.

Mais, je tiens à le dire, MERCI, pour tes articles qui:

• ne sont liés à aucuns langage en général
• sont liés à de l'algo en général
• sont proche de ce qui m'à, il y à 10 ans, lancé dans le dev
• me permettent d'en découvrir toujours tant

Je sais, c'est un post inutile, mais je tenais à remercier Rewind qui s'est, à mon avis, démarqué comme étant le… allez, faisons dans la mode, «contributeur de l'année»

Voila, juste, mes remerciements. Et bon courage pour la suite.

PS: faut vraiment que je cherche ton repo.

Ou juste de relancer un troll à demi mort? ;)

TL;DR: ce que j'aime ici, c'est le débat, le fait de discuter avec des gens qui sont en désaccord avec moi. Plus mon score est bas, plus je suis content, s'il y a des réponses qui me permettent de comprendre le désaccord. J'apprend souvent grâce à DLFP, et je maudirai le jour ou tout le monde sera d'accord avec moi!

Je comprend ton amertume, c'est dur dans les systèmes collaboratifs de se rendre compte que notre opinion n'est pas universellement reconnue

Tu voudrais quoi? Que la grande masse de ceux qui sont d'accord avec toi le disent à chaque fois via un commentaire inutile, parce que n'apportant rien?

Je suis crû (genre, mieux vaut cru que cuit…hum….mouai, peut mieux faire), je sais, mais, si j'aime linuxfr, c'est parce que je dois être un peu… hum…. «maso»… ou… trop franc, et apprécie qu'on me dise mes 4 vérités en face!
Au final, ici, contrairement à d'autres sites, la plupart des gens n'ont pas peur de dire ce qu'ils pensent, et ont la sagesse de ne pas réagir ( si on omets les +1/-1, bien sûr).
Je pense ne pas être le seul à être, ici, attiré par les débats entre les gens qui pensent différemment les uns les autres. Oui, je dis des conneries, régulièrement. Et je me fait casser pour ça, mais… linuxfr est une communauté que j'apprécie, pas juste parce que les gens disent généralement ce qu'ils pensent, mais parcequ'ils le font de manière réfléchie, et que, même quand ils ont tord j'apprend des choses d'eux. Je vous remercie tous pour ça, surtout quand j'ai moi-même tort (je doute être assez compétent pour enseigner) et ce, même si je n'arrive pas à l'admettre publiquement.

Dans ce cas, pourquoi ne pas passer à systemd via devuan?

Sincèrement, je n'ai pas testé devuan, mais j'y suis resté attentif. Nulle part il n'est écrit que systemd ne sera pas supporté, la seule chose qui y est dite est que, par défaut, il n'y aura aucune trace de systemd dans le système.

Ceci étant dit…. j'avoue, même si je n'aime pas l'idée d'utiliser systemd, leur site, qui se vante de forker une des distro les plus méritantes à mes yeux (mais qui, malgré ça, s'éloigne de plus en plus de mes besoins… mais ce n'est pas leur faute, si je veux avoir le plus de contrôle possible sur mon système, je suis juste un noob qui évolue) me donnerait honte d'y contribuer, même si dans l'esprit je comprend leur point de vue.

Au final, le problème n'est pas qu'ils forkent debian, mais uniquement qu'ils le fassent en crachant trop sur ceux qui ont accompli la debian actuelle…. qui ont accompli quelque chose, alors que les auteurs ont attendu que le mainstream ne leur plaise pas pour contribuer au libre!

En fait pour moi, devuan, c'est à la fois la beauté et la mocheté du libre.
C'est beau, parce qu'un fork, c'est comme un bébé, c'est un fils du projet père (ouai, père, pour pas être sexiste héhé… pourquoi ce serait toujours féminin le fait d'engendrer? ) mais c'est moche parce que je pense qu'il y à trop de conflit, et j'ai peur qu'au final les deux projets seront tellement braqués qu'ils ne pourront s'entr-aider, ce qui me semble être la force du libre en tant que particulier (en même temps, je connais aucune petite boîte qui recrute des dev pour du libre, à mon grand malheur).

Il faut dire que je suis loin d'être un Guru Linux

Moi non plus. Mais on ne parle pas de linux ici, uniquement de développement.

ne pas bien connaître make cmake

Je suis tombé amoureux de ce truc quand j'ai tenté pour la 1ère fois de compiler openMW. J'avais déjà tenté de compiler pleins de trucs à base d'autotools (genre wxWidgets) et quand ça merde, ça merde juste dur, le code est illisible, et… bref, une plaie.
À côté, j'avais compilé openMW, et j'ai voulu utiliser cpack pour faire un paquet debian, mais le code pour cpack n'était plus à jour. Il ne m'a fallu que 5 minutes à lire un code clair comme de l'eau de source pour corriger (un problème de version de dépendance) et générer le .deb pour ma machine.
C'est tellement simple que c'en est effrayant. Par contre, c'est un générateur de code qui pond un makefile, et comme tous les générateurs de code, ça génère un truc à peu près illisible et clairement pas maintenable.
Maintenant, il permets de compiler en dehors du chemin des sources, sans prise de tête, sous windows comme sous linux ou BSD, et ça, c'est vraiment génial.
J'ai lu que c'était pas terrible quand on essaie de bosser sur de l'embarqué, mais de toute façon je n'ai pas accès à ce type de matos (c'est en projet ceci dit).

Et disons que j'ai un peu déduit ce qu'était une bibliothèque partager de part mes expériences

Pour faire court, une DLL (enfin, .so sous nux, j'ai encore de vieux réflexes, mais il faut dire que j'ai codé et bricolé plus de 6 ans sous windows only…), c'est une liste de fonction qui est chargée en mémoire lorsqu'un programme à besoin d'elle, et qui est partagée quand plusieurs programmes s'en servent.
Donc, gain théorique de ressources…

Sauf qu'en fait, comme dans toutes les optimisations, on ne gagne jamais sur tous les tableaux, et pire: "early optimization is the root of evil".
Pour faire court (et probablement trop simplifié, mais je n'ai que commencé à lire le super doc que j'ai trouvé à ce sujet récemment) le programme indique à l'OS une liste de symboles dont il à besoin pour tourner (sous linux, qui utilise le format binaire ELF, ça s'appelle des DSO).
Ensuite, l'OS va regarder qui les fournit, s'ils sont déjà chargés en mémoire, et en fonction de la situation, charger la DLL. Une fois que cette DLL est chargée, il va effectuer encore du travail pour dire à l'application qui en à besoin où sont les symboles dont elle à besoin.
Ah, et bien sûr, si l'application n'a besoin que d'un nombre limité de symboles, l'OS charge toute la lib quand même…
Je ne parle même pas des risques d'emmerdes liées à l'utilisation des lib dynamiques (dll_hell, modification illégitime de ld_library_path qui détourne ton application, etc).

Alors que pour une lib statique, l'OS charge le binaire, et basta (par contre, quand on fait une maj il faut refaire l'édition des liens).

Après… les deux ont leurs avantages, et il est probable qu'une DLL bien pensée aie plus d'avantages que d'inconvénients. Seulement voila, les gens (et moi le premier jusqu'à il y à peu) ont tendance à partir du principe que ça ne change rien, ou qu' «il suffit de» alors qu'en fait c'est plus compliqué qu'on ne le pense au premier abord.
Je ne suis pas du camp des auteurs de suckless tools, qui ont commencé une distro ou tout est lié en statique nommée stali, je les trouve trop extrêmes (et dans certains documents qu'ils citent il y à de sacrés biais) mais ils ont ma sympathie quand même, parce qu'ils osent penser différemment et agir contre la tendance actuelle de bloater les programmes sous prétexte que "le client rachètera du matos" (phrase entendue d'un de mes profs, ça ma choqué il y à 8 ans, et je suis content que toutes ses prédictions genre .NET vaincra, l'optim sertà rien & co se retrouvent dégommées par le mobile et l'embarqué, les machines les plus communes maintenant :p).

github
bitbucket
berlios
sourceforge
savannah

Et bien d'autres (à noter que j'ai écrites les URI de tête, sauf berlios et savannah, j'espère ne pas m'être planté sur les domaines…).
En fait, ça, ce sont de forges logicielles, des sites qui hébergent toute l'infra nécessaire pour bosser à plusieurs autour d'un même projet, ça ne fait pas forcément de la pub, mais ça permets diverses choses, qui facilitent le peer review (revue par les pairs).

Par exemple, on à généralement un outil qui permet de lire le code tel qui était à tel commit (sorte de version, idéalement chaque commit est l'équivalent d'un patch et donc très petit), des outils qui permettent de suivre des projets, voire des développeurs, ainsi que des outils permettant de faire des rapports de bugs et bien sûr, de permettre la soumission de patch d'une façon très très simple.

Après… pour faire connaître, ben, linuxfr, mais attention parce qu'à mon avis ici les gens sont plus dans la recherche du logiciel fini ou qui fait un truc sympa ou alors d'une façon différente. Une nième calculatrice faite juste pour le fun à peu de chances d'intéresser des gens.
Pour ça, j'irais plutôt voir du côté de developpez.com, dont la communauté est plus spécialisée développement (de tout niveau) avec quelques intéressés par le libre mais pas la majorité. Elle est aussi nettement plus importante.
Tu peux aussi utiliser le réseau codes-source, je n'ai jamais trop apprécié ni utilisé, mais ça me semble un peu dans ce que tu cherches.
Peut-être le site du zéro, mais vu ce qu'il est devenu, j'ai un gros doute. D'ailleurs, je crois qu'il à été forké…

Toujours est-il que tu mets le doigt sur un bon point: je ne connais aucune communauté qui soit vraiment orientée peer review, et c'est bien dommage, parce que lire le code des autres est un bon moyen de s'améliorer soi-même tout en aidant les autres pour moi.

Parce que tout le monde à le même compte utilisateur sur ta machine?

Bonjour.

Déjà, en général, on utilise les guillemets anglais ("…") pour tout ce qui à trait au projet en cours. Comment tu gères les noms te regarde, mais, encore une fois en général, on part du principe que la racine du projet (souvent un dossier src, qui lui-même peut contenir des sous-dossiers, mais ce n'est qu'une convention) est la racine du disque (autrement dit: /, ou c:\ sous windows).
On utilise toujours les <…> pour les libs externes.

Ensuite, utilise un outil pour gérer ton projet (ou au moins la phase de compilation).
Soit un IDE (code::blocks, Kdevelop, eclipse, qtcreator, peu importe. Perso j'ai bien aimé code::blocks, mais depuis je fais autrement, mais je comprend mieux qu'à mes débuts le processus de compilation aussi ;)) soit un moteur de compilation (makefile, scons, cmake… voire, pourquoi pas, l'ingérable autotools de gnu), mais ne t'embête pas à compiler le linker à la main des projets ou tu dépasses les 2 fichiers et ou tu utilises une lib externe.
D'une part, tu gagneras en facilité, d'autre part, tu gagneras en vitesse de compilation parce qu'un bon outil te permettra de ne pas re-compiler l'ensemble de tes fichiers quand tu n'en modifies qu'un, sans parler qu'il supporteras automatiquement des options debug ou release (qui sont optimisées différemment donc).

Bon courage.

[edit]
Ah, au fait, les listes d'outils que j'ai citées ne sont pas exhaustives, je ne parle que des outils dont j'ai entendu parler ou testé. Je ne connaît pas le nom de l'IDE de gnome, et je ne sait ni s'il existe, ni s'il est bien.

J'ai testé du coup, et la nouvelle IHM est vraiment, vraiment plus belle et mieux foutue.

Par contre, pas testé les Khâlifas encore, et j'ai fait la légende de wesmère avec mon frère (qui est vraiment mauvais avec les elfes ça m'a sauté aux yeux héhé), et elle est assez bugguée encore, sans compter que le nombre de joueurs nécessaires change tous les 3-4 scénarios. Vraiment dommage ça (parce que du coup, comment faire pour conserver les unités d'un chapitre à l'autre pour tous les camps? Va être le bordel amha)…
D'ailleurs, chose amusante, quand on à finit le 1er chapitre (on s'est arrêtés là), j'ai lancé le 2nd chapitre en continuant, et… le camp de mon frère avait 2 fois son leader (Kalenz), mais pas moi.
Donc, encore du travail à faire sur cette campagne.

Honnêtement, j'ai passé des nuits à me servir du chat, à avoir des discussions super intéressantes avec des gens de divers pays.
En fait, ça dépend de la carte sur laquelle tu vas jouer.

Je dirais qu'il y à 6 types majeurs de parties:
_ les survival rapides (typiquement colosseum, qui est un add-on) => là, les gens sont peu patients
_ les combats rapides (souvent issar's cross, de mémoire) => idem
_ les RPGs => idem
_ les survival longs (type survie en équipe, ou un pays neuf) => ça arrive qu'il y ait des gens pressés, mais ce n'est pas trop fréquent (on sait qu'il faudra de toute façon plusieurs heures pour gagner après tout)
_ les combats longs (la plupart des cartes en fait) => je ne sais pas trop, je n'en ai pas trop faits au final
_ les campagnes multijoueurs (ça existe depuis des lustres, mais legend of wesmere est la seule que je connaisse qui ne soit pas générée aléatoirement. World conquest est très jouée… pour une campagne ;)) => rare.

Dans tous les cas, il arrive qu'une personne s'impatiente, quand on ne voit pas quelqu'un bouger, mais en général ce n'est pas au bout de 30s, faut pas pousser.
Et si on part sur une partie longue ou l'on à pas mal d'unités, les gens comprennent souvent que ça ne soit pas rapide, au final. Sur les parties longues, mention spéciale pour les risk-like (add-on, encore une fois, je n'ai pas cité mais j'ai envie de dire que ce n'est plus wesnoth, mais risk sur un thème wesnoth. Très bien foutu quand même.), dans le genre long, c'est long pour une seule map.

2 choses.

Premièrement, pour ton problème de MANPATH et LD_LIBRARY_PATH, peut-être que cpack (qui est fournit avec cmake) pourra t'aider. Pas sûr, perso je ne me suis encore jamais vraiment amusé à faire des archives pour diverses plate-formes…

Secundo, ceci n'est pas totalement vrai:

utilisent le fichier charger en mémoire de la glibc pour ses différentes fonctions, ce qui économise de la mémoire.

Les informations et calculs nécessaires à charger une bibliothèque liée dynamiquement (ou «partagée», les fameuses DLL de windows et .so sous linux) sont conséquentes.
Certains considèrent que la quantité d'informations et de calculs nécessaires au bon chargement d'un programme fait qu'au final, lier statiquement ferait en réalité gagner à la fois de l'espace mémoire (a minima mémoire persistante, je crois qu'ils parlaient aussi de RAM mais j'ai un doute) et calculs, du coup il y aurait une réelle perte de performances avec l'édition dynamique.

Il faudrait que j'arrive à retrouver la littérature sur laquelle j'étais tombé il y à quelques mois, les arguments étaient vraiment très intéressants, mais je me souviens que cette littérature m'a mené sur l'un des projets suckless: stali linux. Il y à une FAQ qui expose rapidement les idées de l'auteur sur ce sujet.

Personnellement, je ne suis pas totalement d'accord avec ces gens: lier dynamiquement du code utilisé par le système entier me semble plutôt pertinent, surtout pour les MaJ, bien qu'ils m'aient mis le doute (peut-être que je devrais tester sta.li, pour en avoir le cœur net?). Par contre, ce qui est quasi-certain, c'est que dans le cas de ta lib, qui ne sera pas utilisée par plus de 3-4 utilitaires, en faire une lib statique sera plus efficace.
Tu devrais tester: combien pèsent ta calculatrice liée dynamiquement + la lib, et combien pèse ta calculatrice liée statiquement? Pour ma part, j'avais fait quelques tests de mon côté: j'avais réimplémenté yes, pour être quasi égal au niveau des fonctionnalités avec la version GNU (le seul truc que je supportait pas, c'était les locales pour l'option --help…) et entre le statique sur la glibc et le dynamique, j'avais, de mémoire, 15% de gain. Ma version statique pesait aussi 10k de moins que le yes de gnu, sachant que GNU yes pèse… 31K. Ça donne à réfléchir, et pas qu'un peu.

Tout le monde ne parle que d'édition de liens dynamique, mais je crois que tout le monde fait juste le mouton de Panurge, sur ce point et sur bien d'autres. Peut-être que l'industrie logiciel s'encrasse dans ses idées reçues, au final…

Moui, mais je trouve les fichiers source (le .deb source, je parle) assez, disons, étranges à manipuler.
En même temps, Debian n'est pas faite pour être ultra customisée. Vais sûrement aller voir du côté d'une distro source quelconque un de ces 4…

Je ferai un nouveau poste car il reste quelques points a éclaircir:
-Le chemin ou sont situer les library partagées ne sont pas les mêmes sur les différentes distribution ? Sous Ubuntu elles sont situer dans /usr/lib.
- Et j'ai le même problème avec les manpages /usr/share/man/ sous Ubuntu.
Faire un script d'installation propre: ton conseil d'utilisé make me tente de plus en plus.

D'autant qu'en plus cmake… enfin, cpack, une sorte d'extension à cmake, intégrée par défaut, te permettras de générer des paquets/installateurs.

Je retiens les conseils données et je les appliquerai car la dernière fois que j'ai publier un programme C ont m'a conseiller d'inclure des fichiers d'extension *.c et non *.h ce que j'ai fait ce coup ci et j'ai compris la différence entre les deux.

Je serais curieux de voir l'argument employé. Ok, les .h peuvent servir pour les libs (que ce soit pour les dynamiques ou pour les statiques) mais personnellement, j'ai tendance à m'en servir pour savoir l'API du fichier d'implémentation correspondant. J'y mets aussi les trucs genre "commentaires doxygen", qui expliquent ce que la fonction prend en entrée et génère en sortie (en fait: préconditions, postconditions et invariants, même si le C++ permets déjà de bien l'expliquer via le langage).

Personnellement j'ai mis un an et demie avant d'envisager d'apprendre une GUI en C.

Bof, j'ai appris à utiliser Qt (v3 de mémoire), MFC, wxWidgets par le passé. M'adapter à une nouvelle API ne me prendrais pas longtemps, mais… j'avoue, me fader des IHM c'est ce qui m'emmerde le plus. Je trouve les toolkits assez mal conçus en général, et plus je peux éviter, mieux je me porte. Coup de bol: dans mon taf on me demande quasi pas d'IHM :p

Sinon j'utilise également un simple éditeur et le terminal comme toi. Pas de IDE comme code::block ou autres anjuta…

J'ai utilisé ce genre de trucs, par le passé. J'ai toujours trouvé ça stupide d'avoir, dans un même OS, une palanquée de logiciels implémentant la même fonctionnalité: la gestion de fenêtres. Un jour, j'ai découvert que des WM existaient qui permettent de faire du "docking" avec n'importe quelle application (TWM, dans mon cas i3). Ce jour la, j'ai pris la pente qui à aboutit à la suppression des IDE de ma trousse à outils ;)

A chaque modification de ligne de conf, il faudrait recréer un paquet. Si ça pourrait se faire, mais il faudrait décoreller la conf du paquet, et avoir un script permettant de récupérer celle-ci par une autre méthode.

C'est faisable sans refaire un paquet à chaque fois.

Il suffit de faire dépendre le méta-paquet d'un outil qui ira chercher les fichiers de conf, et d'appliquer un script dans post-inst, ou un truc du genre.
Je ne dis pas que c'est une bonne idée, parce qu'aller chercher un truc changeant automatiquement sur le réseau lors d'une intall, ça me paraît un peu… dangereux, mais ça me semble faisable.

Il n'y à rien de mal à ce bon vieux VCS cpold :p (à condition bien sûr d'aimer devoir trier des noms de dossier genre "copie de copie de copie de copie de copie de foobar" pour windows ou "foobar.bak.bak.bak.bak.bak.bak.bak"…)