Misc a écrit 6286 commentaires

Il y le script mklivecd :

http://www.linuxminicd.org/mklivecd/(...)

Il y a pas trop de docs sur le web je croit.

Amusant, il manque une partie de la phrase, je vias donc en rajouter.

Peut être que certains pensent que pour bien choisir un serveur, il faut le faire vite histoire de dire que nous sommes les premiers à l'avoir fait.
Réaction quasiment marketing, et digne d'un gamin.
Mais pour un truc aussi central et important que le serveur X, il vaut mieux réflechir.

Surtout vu à quel point ça peut devenir important de ne repartir ou pas sur le code et les fondations toujours critiqués de XFRee86 ou de prendre une base de code plus récente mais sans doute moins compatible.
Une fois de plus, les plus pressés, par effet d'annonce, vont essayer de forcer les autres et d'imposer leur décisions , pour se dire en cas d'erreur qu'ils ne sont pas les seuls à l'avoir fait.

J'ai rien vu.

Pour le moment, rien n'a encore été décidé pour cause de manque de temps.

Tu as surement plus d'info ?

> > pas de mplayer pour fedora ?

> NON ! C'EST UN PUTAIN DE PROBLÈME DE BREVET !
> C'EST ENCORE ET ENCORE LA MÊME RAISON RÉPÉTÉ 2 MILLES FOIS !

Ça ne la rends pas plus vrai. Si il y avait des brevets, pourquoi est ce que d'autres se permettent de le distribuer ?
Fedora/RH pourrait tout simplement ne pas compiler certaines parties, comme d'autres le font. Il y a plein de --with qui vont avec mplayer.

Tu as surement plus d'info sur les brevets ? ( atention, je rappelle que libdvdcss ne viole pas un brevet )


> btw, il n'y a pas de mp3 pour la même raison. Je dis ça, c'est pour t'épargner
> un autre journal.

Au passage, il n'y a pas de gif pour la même raison.
Ah oups, il y a gif. RH aurait plus peur de thompson que de unisys ?
Pourtant le format gif est aussi sous le coup d'un brevet, et comme le mp3, il y a des décodeurs libres et le détenteur du brevet n'a pas indiqué vouloir attaquer les lecteurs.

Et pourtant, RH n'a pas retiré toute trace du gif de ses distributions. Contrairement au mp3, completement anhilé, même depuis les tarball sources.

Une bien étrange conception de la constance en matiére de choix....

Parfait, dois je comprendre que tu proposes du code, ou tu te contente d'être paranoiaque et alarmiste sur le sujet ?

Courir et crier partout ne sert à rien. faut exposer calmement la situatuion. Le libre a toujours absorbé rapidement les technos de windows. L'installeurs de apache win32 utilisait msi dés sa sortie. Je voit pas pourquoi mozilla serait forcement moins intégré que ie.

Et je voit pas non plus ce que ça change par rapport à maintenant, ou ie est déja bien intégré, niveau graphique et tout

Un lien sur :"Release criteria for the Linux kernel", qui peut t'interesser.

http://www.firstmonday.org/issues/issue9_4/glance/index.html(...)


Gloabalement, il y a pas de test de non regression.
La majorité des projets n'en font pas.

Je sais que les modules CPAN ont ça, que svn et des projets dérivés doivent avoir ça, et postgresql aussi , mais la plupart n'ont rien. C'est pourtant fun et ça permet de vraiment éviter les bugs.

"On en veut pas d'XFree86 mais on reste avec..."

Relit :
"FB: Yes. We disagree with the new license with regards to the GPL."

Donc, ils gardent l'ancien pour le moment, n'ayant pas encore choisi comment remplacer. Peut etre que certains

SI tu veut tester d'autres serveurs, il y a quelque part des paquets non officiels qui traine, mais j'ai oublié l'url :/

Je me permet d'ajouter le lien vers rpm.lyvna.org, un dépot de rpm pour rh, qui contient le support mp3.

http://rpm.livna.org/(...)


Et sinon, http://freshrpms.net/,(...) toujours pour rh.

De toute façon, en utilisant les outils ( urpmf/apt-file ou le /usr/share/doc ), on peut recreer la base rpm/dpkg en cas de probléme.
J'ai déja effacé mon /var ( maudite partitionneur BSD ), et j'ai réussi à reprendre la base rpm sans aucun probléme, donc le coup des corruptions, ouais, mais ç'est vraiment mineur.

Via getent, tu voit le contenu des fichiers :

getent groups

getent passwd

Trés rapidement, bof, j'ai eu deja un bug assez chiant sur subversion, 1 semaine a etre fixé ( pb sur une autre lib ).

Donc, ç'est pas cassé souvent, mais c'est pas toujours rapidement fixé.

> Gniiiii ? Au lieu de parler comme un windozien, si tu nous donnais le nom du
> soft qui fait ça (en plus ça te permettra de trouver par toi même).

Sous mandrake et fedora, tu as un script appelé service, qui active les ... services.

Le sous systéme son n'est pas un daemon, vu que ça charge des modules.
Donc on ne peut pas dire que tout dans /etc/init.d est un soft ou un daemon.

Donc, non, c'est pas une terminologie de "windowsien".

Deja vu :

http://archives.mandrakelinux.com/cooker/2003-01/msg06043.php(...)

1) msn c'est mal (tm) :)

2) gaim, jabber, ça marche ?
Il y a pas moyen de décocher une option genre "envoyer des messages en format enrichi", un truc dans ce gout la ?

> Comme les gens de Cooker vont faire leur première rencontre aux RMLL, j'ai
> envie de leur proposer de rencontrer des vrais utilisateurs de la vraie vie,

Je pense que le probléme n'est pas de rencontrer plus d'utilisateurs dans la vraie vie.
Le problème est toujours le même, des moyens limités, et une complexité grandissante. On a beau avoir toujours plus de testeurs, et plus de rapports de bugs, ils faut encore réussir à les fixer à temps, et pouvoir les fixer.
Par exemple, le probléme de Flash :
1) Soit mdk le distribue, et viole la license de macromedia, et se fait critiquer pour avoir mis du non libre, et augmente les problémes de maintenance

2) soit mdk garde ça pour le club, et on critique à tout bout de champ la dérive commercial de mdk, qui est contre le concept de libre, etc etc.

Quelque soit la solution, des gens la trouveront jamais bonnes.
Donc, faire plus de test, ça va pas régler ce probléme. Faut pas croire qu'un developpeur est complétement détaché de la vie réelle, ou est complétement asocial.

Tout le monde aura bien sur compléter par :

</Location>

( et je me fait encore avoir.... )

Sauf erreur de ma part, il y a déja eu des demandes pour utiliser Postgresql, et c'est en cours de developpement.

Sinon, je pense qu'on peut se débrouiller pour gerer plusieurs projets à coup de configurations et de liens hard, je voit pas vraiment ce qui l'empeche.

Dans la mesure ou configurer trac, c'est juste mettre ça dans la conf apache ( trac dans le repertoire qui va bien ) :

Alias /trac/ "/usr/share/trac/htdocs/"
<Location "/cgi-bin/trac.cgi">
SetEnv TRAC_DB "/tmp/plop.db"


On peut facilement imaginer un fichier par projet, le tout placer dans un dossier inclut par apache.

> Problème de brevet. C'est récurrent.

Sans vouloir être pointilleux, c'est pas un probléme de brevet pour le decss car un brevet doit être publié, hors, John Johnansen a du faire du reverse enginnering.
C'est donc un problème différent ( secret industriel, et John a été accusé sous le coup du dmca, pour avoir contourné un systéme de protection, si je me souvient bien )

Je pensais que testing avait comme principe de ne pas avoir de dépendances cassés :

http://www.debian.org/devel/testing(...)

"Toutes ces dépendances doivent soit être satisfaites par les paquets d'ores et déjà présents dans testing, ou bien être satisfaites par un ensemble de paquets qui sont installés au même instant ;"

http://qa.mandrakesoft.com/show_bug.cgi?id=9692(...)

Voila, si tu suis les listes dédiés, ben tu sais ce qui se passer.

> Mais pour les créateurs de distros, c'est une excellente nouvelle !

Pourquoi ?
C'est pas parce que c'est libre que ça sera réutilisé, il faut encore avoir les compétences pour lire le code, et avoir envie de le faire. En l'occurence, yast est écrit en qt/C++, donc ça limite un peu, selon moi.

Dans le même genre, il y a eu des paquets de hardrake pour debian, et personne n'en a rien fait : http://torsion.org/witten/debian/.(...)

> Je ne comprend toujours pas pourquoi si il est si embêtant de faire du
> spécifique, pourquoi ils ont tout recompilé pour architecture pentium pour le
> x86 ?

Parce que c'est recompilé depuis le début en i586. Ensuite, c'est pas tant de developper en spécifique, que de faire plusieurs archis, car, automatiquement, il faut faire plus de test, et vérifié que les patchs et fixs ne cassent pas un truc sur une autre architecture. Tout ça pour un gain nuls.

Peut être que pour la plupart du monde, limiter les dépenses est néfaste, mais quand on a des gens à payer, pour les faire vivre, ça semble tout d'un coup moins idiot.

> Oui il est développé pour 386 par pour 586 :) comme la plupart des applis.

Il y a pourtant des parties du code qui prennent en compte le mmx, dispo à partir de pentium, si je me souvient bien. Et pareil pour la glibc, qui a des parties optimisés i686, chargé dynamiquement grace au loader (voir fichier dans /lib/i686/ )


> Manfrake embauche des spécialistes de l'intégration pas des développeurs
> j'espère.

Ben je sais pas, mais je suppose que les gens qui font les outils mandrake sont des développeurs, tout comme les gens qui travailles sur le noyau ou kde. Du moins, c'est l'impression que j'ai.

Mais on pourrait dire, si on voulait lancer un troll que si mdk embauche des devs, c'est surtout signe que c'est mal intégré, et que si mdk embauche des intégrateurs, c'est dans ce cas signe qu'elle n'aide pas assez le libre en ne developpant que des trucs pour elles ( car en général, l'intégration d'un paquet bénéficie à moins de monde qu'un patch )

Mais si j'ai bien suivi, debian ( et fedora aussi ) n'ont pas encore fini de mettre en place une architecture qui permet de mixer les applis 32 bits et 64 bits.
En effet, une appli 32 bits a besoin de libs 32 bits, comme la glibc. Donc, un fichier /usr/lib/libmachin.so

Si une appli 64 bits a besoin de la même lib, il faut une version /usr/lib/libmachin.so en 64 bits. Comme il y a un conflit de noms de fichiers, ça ne marche pas.

C'est pour ça que mdk depuis 2 ans travaille sur ça, en placant les libs 64 bits dans lib64.

> Je me demande même si des DivX "enregistrés à la télé" ne pourraient pas
> être proposés au téléchargement gratuitement et légalement (en
> mentionnant que le téléchargement est autorisé à ceux qui payent la
> redevance et interdit aux autres).

Je croit que ç'est plus compliqué, car la chaine de tele paye pour rediffuser. Donc, tu aurais le droit si toi aussi tu paye les ayants droits pour à ton tour rediffusés.
Curieusement, dés qu'on parle de payer pour distribuer gratuitement, ça calme beaucoup de gens.

Tout comme le libre a fait avec Microsoft :
D'abord, on a ignoré Microsoft.
Ensuite, on a rigolé de windows, systéme meme pas multitache
Maintenant, on le combat, ça veut donc dire qu'on est pas loin de la phase "Microsoft a gagné" ?.

C'est bien beau de citer Gandhi, mais ça s'applique pas vraiment dans notre cas, dans la mesure ou on fait plus que de la résistance passive et non violente....