rrrrrhhhhaaaaaaaaaaaaa - Page 2

et il fonctionne ? parce que j'en ai trouvé un aussi (post ./1), mais on a beau lui donner les paths de ses dossiers en arguments, il dit qu'ils sont introuvables (mais le message d'erreur n'est pas le meme si on passe un chemin bidon ou un chemin reel, donc il se passe quand meme quelque chose...)

Et on est forcé de lui donner les paths en arguments parce ceux par defaut sont inscrits en dur au moment de la compilation. (donc c'est bien lourd)

=> j'ai voulu le recompiler moi meme


(pour info, j'ai essayé de recompiler avec --enable-runtime-pseudo-reloc, mais ça ne change rien.. en fait en virant la ligne qui pose problème, ça compile... mais le programme ne fonctionne pas (fallait s'y attendre en même temps ))

spectras
:

Pollux :
la solution propre ce serait, qd on veut toucher à /usr/machin, de demander une confirmation (avec éventuellement un mot de passe de root) et de logger toutes les modifications ultérieures quelque part... (voire mieux, de tout installer dans une sandbox et de fusionner le contenu de cette sandbox avec /usr/machin)
ça doit être le genre de truc faisable sous vista, mais sous linux je sais pas

C'est ce que font RPM et dpkg depuis une dizaine d'années ^^

Oui mais c'est un logiciel spécifique avec son format de données bien à lui : je parle de faire en sorte que le filesystem lui-même gère ça, pour que ça soit compatible aussi avec les compilations "à la main" ^^

Bah tout ce qui est réalisé par un programme est également faisable à la main, c'est juste plus long. Dans le cas présent, suffit de faire ton install dans un chroot et d'archiver la liste des fichiers à supprimer par la suite. De toutes façons c'est ça que font dpkg et rpm : c'est juste des outils qui automatisent ce processus.

Et je suis pas d'accord sur l'inclusion d'une telle chose dans le filesystem. Ca c'est le début du "feature creep". Un filesystem, comme son nom l'indique, ça sert à organiser un système de fichier. Et ça doit se limiter à ça. Y introduire des notions applicatives serait une grave erreur de conception (hormis filesystems dédiés tel que vmfs et ocfs).

Pen^2> ben oui il fonctionne .

Bah tout ce qui est réalisé par un programme est également faisable à la main, c'est juste plus long.

et tellement user-friendly ...

spectras > celle là ? http://gnuwin32.sourceforge.net/packages/src-highlite.htm
je vais telecharger à nouveau.

ah, tiens, ça fonctionne maintenant...
Curieux. Mais je suis pas certain que c'était bien cette même version que j'avais déjà essayée... Il me semble qu'il y avait un installeur...
Enfin bref, tant mieux si ça fonctionne.
Ceci dit, à l'occasion j'aimerais bien arriver à la compiler quand même.. (en plus ils ont l'air de dire que ça compile tout seul avec CygWin sur le site http://www.gnu.org/software/src-highlite/. C'est peut etre avec MinGW que ça pose problème )

spectras :
Et je suis pas d'accord sur l'inclusion d'une telle chose dans le filesystem. Ca c'est le début du "feature creep". Un filesystem, comme son nom l'indique, ça sert à organiser un système de fichier. Et ça doit se limiter à ça. Y introduire des notions applicatives serait une grave erreur de conception (hormis filesystems dédiés tel que vmfs et ocfs).

Je veux pas dire inclure ça dans le filesystem au sens "physique" (je parle pas de faire un driver fat32 modifié pour ça ), je veux dire inclure ça dans le filesystem au sens "virtuel" (i.e. comme les traducteurs de hurd). I.e. au lieu d'écrire physiquement dans /usr/machintruc il passe /usr/machintruc et ce qu'il veut écrire au démon d'installation, qui lui se chargera de l'écriture physique...

Flanker> troll à côté de la plaque. Là on parle d'un gars qui choisit de compiler les sources à la main au lieu d'utiliser une version packagée
Pollux> pour le coup je vois plus du tout ce que tu veux faire alors O_o

spectras :
Flanker> troll à côté de la plaque. Là on parle d'un gars qui choisit de compiler les sources à la main au lieu d'utiliser une version packagée

1 c'est pas de ma faute si la version que j'avais DL ne fonctionnait pas
2 c'est pas parce que tu choisis de compiler que tu dois tout te taper à la main
3 de toutes façons, dans la mesure où j'ai déjà un environnemetn CyGWin, il serait préférable que tout soit intégré dedans, plutôt que d'avoir un man en .txt (par exemple)

spectras :
Flanker> troll à côté de la plaque. Là on parle d'un gars qui choisit de compiler les sources à la main au lieu d'utiliser une version packagée

ben je suppose qu'il parle d'une sorte de hook

1)
=> a) chez moi ça marche (c)
=> b) si ça marchait pas fallait utiliser autre chose, personne ne t'as obligé à télécharger les sources et essayer de les compiler hein
2)
=> tout te tapper à la main ? fais le une fois tout à la main et tu comprendras ta douleur.
3)
=> oué mais c'est cygwin hein au départ. Faut pas oublier que cygwin c'est juste un hack pour permettre de faire tourner certains programmes peu exigeants en matière de compatibilité posix.

spectras :
Pollux> pour le coup je vois plus du tout ce que tu veux faire alors O_o

Ben dans le script d'installation de "monprog" :
fopen("/usr/bin/hello","wb");
serait transformé en
daemon_fopen("/usr/bin/hello","wb");
qui appellera entre autres
fopen("/installed/monprog/usr/bin/hello","wb");

Et par rapport à un chroot y'a quoi comme différence au juste ?

spectras :
1)
=> a) chez moi ça marche (c)

chez moi aussi maintenant (enfin pas encore testé sur mon ordi, mais bon y'a pas de raisons ^^)

=> b) si ça marchait pas fallait utiliser autre chose,

c'est ce que j'ai fait : j'ai décidé de recompiler

personne ne t'as obligé à télécharger les sources et essayer de les compiler hein

non, mais c'est une possibilité parmi d'autres (cf point précédent)
Comme je n'ai pas Internet chez moi, ça me gonfle un peu de faire des allers et retours => je me suis dit qu'en compilant j'allais être tranquille

2)
=> tout te tapper à la main ? fais le une fois tout à la main et tu comprendras ta douleur.

je parlais de la désinstallation

3)
=> oué mais c'est cygwin hein au départ. Faut pas oublier que cygwin c'est juste un hack pour permettre de faire tourner certains programmes peu exigeants en matière de compatibilité posix.

sans doute.

spectras :
Et par rapport à un chroot y'a quoi comme différence au juste ?

- tu doit être root pour faire un chroot...
- comment est-ce que tu comptes à la fois importer les programmes existants dans /usr/bin et autoriser les écritures vers /installed/monprog/usr/bin, de façon propre ? (i.e. pas question de construire une liste des programmes existants avant l'appel de chroot et faire des symlinks : il faut que si monprog appelle le programme d'installation de malib, les exécutables de malib apparaissent dans le /usr/bin du programme d'installation de monprog)

Attends je suis pas sûr d'avoir suivi. Une fois le programme installé dans le répertoire du chroot, tout est mergé à la racine.
Je vois pas où est le problème en fait. (d'autant plus que ça marche très bien en pratique)

Ximoon > Il existe un moyen d'installer des paquets sous linux sans outil, ça s'appelle la lsb, ça permet en théorie de dropper un binaire dans /opt et qu'il marche tout seul, et de le rm quand tu veux l'enlever. Le seul problème c'est que personne ne distribue de paquets compatibles parce que c'est pas si utile que ça finalement.

Oui donc ça rejoint ce que je disais, au final y'a toujours 250000 trucs différents, que ce soient les paquets, les protocoles, les normes, les dépendances, etc, et au final on s'en sort pas sans y passer des heures.
Enfin si y'en a à qui ça plait, pourquoi pas.

Non mais c'est *la* norme, celle là. Elle est suivie (plus ou moins bien) par la majorité des distributions Linux, et normalement des paquets distribués sous cette forme marchent à peu près partout.

Juste, c'est bien joli, mais en fait, les gens préfèrent utiliser leur système favori : apt, rpm, portage ... système qui est en général un des arguments majeurs dans le choix d'une distribution ; si tu as choisi ta distrib parce que tu préfères utiliser apt, tu ne vas pas te mettre à installer tout d'un coup des binaires lsb juste parce que "c'est compatible". D'autant que les systèmes de gestion des paquets qui existent actuellement sont tout autant, voire plus simple : en général il suffit d'une ligne de commande genre "install <truc>" et ça t'installe <truc>. Difficile de faire plus simple, quand même. Alors, oui, c'est pas compatible entre diverses distributions, mais en tant qu'utilisateur final, tu t'en fous : tant que ça marche avec ton système de paquets ...

Cependant la lsb reste une alternative pour les distributeurs closed source qui voudraient distribuer des binaires qui marcheraient sous toute version de Linux. Cependant, il y en a pas tellement pour l'instant, et en général, un particulier sous Linux n'utilise pas cet OS pour y mettre du closed source (sauf en cas de drivers). En entreprise, par contre, c'est peut être plus fréquent.

(ah, il existe un autre standard, quand même : à une époque, chaque paquet avait sa méthode de compilation ; aujourd'hui, à peu près tout le monde utilise "./configure && make && make install", ce qui est tout de même plus pratique)

Tu sous-entends que la majorité des utilisateurs de linux le font d'un point de vue idéaliste et non pratique, donc ?

à cause de "un particulier sous Linux n'utilise pas cet OS pour y mettre du closed source (sauf en cas de drivers)." ?

je dis ça juste parce que je connais pas beaucoup d'applications closed source très populaires auprès des particuliers sous linux. Il y a quelques drivers (nvidia notamment), wineX/cedega pour jouer à des jeux qui ne tourneraient pas encore sous wine, vmware pour faire tourner d'autres os, flash, realplayer et acrobat pour le multimedia sur internet (et encore, seul flash est vraiment utilisé, le reste est largement remplaçable par des équivalents open source) et c'est à peu près tout.

Je sais pas si c'est une question d'idéalisme des utilisateurs ou pas. A mon avis c'est surtout parce qu'il y a peu d'applications closed source sous linux qui valent vraiment le coup par rapport à ce qu'il y a en open source ... et que les développeurs qui développent en closed source visent plus souvent windows ... et que les distributions préfèrent inclure des logiciels open source dans leurs systemes de paquets que des systemes closed source. Il peut y avoir plein de raisons.

Ou c'est à cause d'autre chose que j'aurais dit ?

Mais enfin je pense en effet que les raisons de licence et autres (celles que tu appelles idéaliste) sont des raisons importantes dans le choix de linux. Mais après tout, choisir un OS pour sa licence, c'est aussi une raison pratique en fait. Le fait d'avoir envie de pouvoir corriger les sources d'un programme qui ne marche pas, c'est plus "pratique" qu'"idéaliste", comme raison

Je doute que tant de personnes que ça corrigent efficacement, voir corrigent tout court, les bugs qu'ils trouvent.
Ceci dit, à mon grand étonnement, tu as répondu à la (bonne) question

C'est quand même le principal intérêt des logiciels open source, c'est de pouvoir les modifier et corriger, hein Alors, oui, je pense qu'une grande partie des gens qui les utilisent le font pour cet avantage là

Et "corriger", ça veut pas forcément vouloir dire "rajouter du parrallelisme à une application single thread", hein, ça peut être simplement : changer un message ou une image dans la source pour personnaliser le programme, corriger un bug difficilement trouvable par les développeurs, mais trivial à réparer quand on le rencontre, etc ... je pense que pas mal de gens qui tournent sous linux régulièrement et depuis assez longtemps pour avoir un peu d'expérience ont déjà modifié au moins un caractère dans un fichier source pour que le programme convienne mieux à leurs besoins.

Je suis dubitatif sur les chiffres que tu sous-entends, mais il m'est avis qu'on aurait du mal à vérifier.

Enfin sinon, une autre raison "pratique" et non pas "idéaliste" de préférer une licence open source, c'est qu'on n'est pas lié à attendre la prochaine version d'un programme si il y a un problème : on peut profiter d'un patch fourni par un tiers. Or ça, la quasi totalité des utilisateurs de Linux en profitent : chaque distribution patche une grande partie des programmes (à commencer par le noyau) qu'elle inclue dans son système de paquets.

Tout ça pour dire que je pense qu'on ne peut pas dire "Tant d'utilisateurs de Linux l'utilisent pour soutenir le mouvement du logiciel libre" et "Tant d'utilisateurs de Linux l'utilisent parce qu'ils trouvent que c'est un système plus pratique à utiliser". En fait, ces raisons sont fortement imbriquées les unes dans les autres, et il n'y a pas lieu de les classifier. Chaque utilisateur a ses raisons bien à lui bien sûr, mais on ne peut pas dire "ah tiens, ça c'est une raison matérielle", "ah tiens, celle là c'est une raison philosophique", "ah, celle la c'est une raison politique", parce que tous ces domaines sont intimement liés.

[EDIT : omg ste faute d'orthographe >_<]

tout développeur travaillant sous linux a sûrement déjà rapporter un bug. Après y'a aussi les admin sys qui maitrisent, ils doivent sûrement aussi raporter des bugs, mais c'est plus sur la conf je pense.
Après, est-ce qu'il a bcp d'utilisateurs de linux non dévelopeur et non admin sys...?...

Y'a pas que les bugs dans la vie. Une faute d'orthographe, une image manquante, une traduction foireuse, ou inexistante (envie d'avoir ton appli en catalan ?), un lien en 404 dans une boîte d'aide c'est autant de choses qui pourissent l'utilisation d'une application et qui sont triviales à corriger même sans la moindre notion de programmation.

Remarque, de nombreux projets libres considèrent ce type de problèmes comme des bugs. La différence étant qu'ils sont "débuggés" par des graphistes, des traducteurs, ... au lieu de développeurs.


Sur un autre plan, t'as également les choses annexes, même si pas directement liées. Par exemple les fichiers de configuration. La plupart des logiciels propriétaires travaillent sur des fichiers de configuration inutilisables (non spécifiés voire totalement différents d'une version un autre, quand ce ne sont pas des fichiers binaires, voire des dumps mémoire de structures internes de l'appli). Sans toucher au code lui même, j'aime bien pouvoir jouer sur toutes les options des programmes que j'utilise.
(faut dire que contrairement à la plupart des utilisateurs qui cherchent juste à faire ce qu'ils ont à faire, mon premier réflexe quand j'utilise un nouveau logiciel c'est de fouiller tous les menus et tester de nombreuses options de configuration pour voir ce que le logiciel sait faire).

et puis bon une raison pratique d'utiliser des programmes open source c'est que quand tu te fais chier tu peux faire ça :

moomoo@moobook ~ $ cd /usr/src/linux
moomoo@moobook /usr/src/linux $ find ./ | xargs grep fuck
./Documentation/DocBook/kernel-locking.tmpl:       If you don't see why, please stay the fuck away from my code.
./arch/i386/kernel/cpu/cpufreq/powernow-k7.c: * Some Athlon laptops have really fucked PST tables.
./arch/i386/kernel/cpu/mtrr/generic.c:/*  Some BIOS's are fucked and don't set all MTRRs the same!  */
./arch/mips/kernel/irixelf.c:#if 0 /* XXX No fucking way dude... */
./arch/mips/kernel/irixioctl.c: * irixioctl.c: A fucking mess...
./arch/mips/pci/pci-ip27.c:      * IOC3 is fucked fucked beyond believe ...  Don't even give the
./arch/mips/pci/pci-ip27.c:      * IOC3 is fucked fucked beyond believe ...  Don't even give the
./arch/mips/pci/pci-ip27.c:      * IOC3 is fucked fucked beyond believe ...  Don't try to access
./arch/mips/pci/pci-ip27.c:      * IOC3 is fucked fucked beyond believe ...  Don't even give the
./arch/mips/pci/pci-ip27.c:      * IOC3 is fucked fucked beyond believe ...  Don't even give the
./arch/mips/pci/pci-ip27.c:      * IOC3 is fucked fucked beyond believe ...  Don't try to access
./arch/mips/pci/pci-ip27.c:      * IOC3 is fucked fucked beyond believe ...  Don't even give the
./arch/mips/pci/pci-ip27.c:      * IOC3 is fucked fucked beyond believe ...  Don't even give the
./arch/mips/pci/pci-ip27.c:      * IOC3 is fucked fucked beyond believe ...  Don't try to access
./arch/mips/pci/pci-ip27.c:      * IOC3 is fucked fucked beyond believe ...  Don't even give the
./arch/mips/pci/pci-ip27.c:      * IOC3 is fucked fucked beyond believe ...  Don't even give the
./arch/mips/pci/pci-ip27.c:      * IOC3 is fucked fucked beyond believe ...  Don't try to access
./arch/mips/sgi-ip22/ip22-setup.c:       * fucking with the memory controller because it needs to know the
./arch/ppc/syslib/ppc405_pci.c:  * the kernel try to remap our BAR #1 and fuck up bus
./arch/sparc/kernel/process.c:  /* fuck me plenty */
./arch/sparc/kernel/sunos_ioctl.c:      /* Binary compatibility is good American knowhow fuckin' up. */
./drivers/char/watchdog/shwdt.c:         * brain-damage, it's managed to fuck things up one step further..
./drivers/ide/pci/cmd640.c: *  These chips are basically fucked by design, and getting this driver
./drivers/media/video/bt819.c:                                     BUG? Why does turning the chroma comb on fuck up color?
./drivers/mtd/mtd_blkdevs.c:       registered, to prevent the link/init ordering from fucking
./drivers/net/b44.c:    /* ??? What the fuck is the purpose of the interrupt mask
./drivers/net/sunhme.c:/* Only Sun can take such nice parts and fuck up the programming interface
./drivers/net/sunhme.c:         /* This card is _fucking_ hot... */
./drivers/scsi/NCR53C9x.c: * how bad the target and/or ESP fucks things up.
./drivers/scsi/NCR53C9x.c:              /* Be careful, we could really get fucked during synchronous
./drivers/scsi/esp.c: * how bad the target and/or ESP fucks things up.
./drivers/scsi/esp.c:    * phase things.  We don't want to fuck directly with
./drivers/scsi/esp.c:           /* Be careful, we could really get fucked during synchronous
./drivers/scsi/qlogicpti.h:/* Am I fucking pedantic or what? */
./fs/jffs/intrep.c:                don't fuck up. This is why we have 
./include/asm-cris/arch-v32/spinlock.h: * writers) in interrupt handlers someone fucked up and we'd dead-lock
./include/asm-m68k/sun3ints.h:/* master list of VME vectors -- don't fuck with this */
./include/asm-parisc/spinlock.h: * writers) in interrupt handlers someone fucked up and we'd dead-lock
./include/asm-sparc64/system.h: /* If you fuck with this, update ret_from_syscall code too. */  \
./include/linux/netfilter/xt_limit.h:   /* Ugly, ugly fucker. */
./lib/vsprintf.c: * Wirzenius wrote this portably, Torvalds fucked it up :-)
./net/ipv4/netfilter/ip_nat_snmp_basic.c: * (And this is the fucking 'basic' method).
./net/netfilter/nf_queue.c:             /* James M doesn't say fuck enough. */
./net/netfilter/xt_limit.c: *                   Alexey is a fucking genius?
./sound/oss/aci.c:/* The four ACI command types are fucked up. [-:
./sound/oss/opl3.c:      * What the fuck is going on here?  We leave junk in the beginning

ma préférée c'est "/* fuck me plenty */"