Misc a écrit 6251 commentaires

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

Je me souvient d'une apge sur le sujet sur /., mais à part ça, je trouve pas :

http://ask.slashdot.org/article.pl?sid=02/12/04/1247210&mode=th(...)

Les commentaires ont pas l'air d'être les mêmes qu'avant.

> D'ailleur il y a un dépôt Utopia pour Fedora :
> http://people.redhat.com/johnp/hardware_discovery.html(...(...))
> Utopia sera prêt pour le "consumer market" quand ? Techniquement
> peut-être dans 1 an. Puis il faut aussi que les fournisseurs de hard suivent le
> mouvement.

Pour ceux que ça intéresse, c'est décrit ici :
http://freedesktop.org/~david/hal-0.2/spec/hal-spec.html(...)

En googlant un peu j'ai juste trouvé ça aussi :
http://primates.ximian.com/~rml/project_utopia/(...)

Et divers interview de Robert Love. Faut dire que prendre un nom commun, ça aide pas :/

En installant les paquets hal et dbus de Cooker, j'ai pas l'air d'avoir grand chose de plus, mais d'un autre coté, flemme de lire la doc.

Aprés lecture du README, je suis pas si sur que ça soit une si grande avancé, ou si révolutionnaire.

> Pour mandrake le probleme est le meme, et les durées de vie sont trop
> courtes.

Y a 5 ans sur les versions corporate.
C'est vrai que c'est plus court que windows 98, mais c'est pas mal.

Dans la mesure ou il choisit Redhat pour le support, il serait plus pertinent de lui donner des noms de ssii qui font du support officiels sur debian, plutot que de lui conseiller d'installer directment une sarge en production, sarge sans update officiel de sécurité, comme je le rappelle si souvent.

> 1/ C'est la solution que je préconise dans la mesure où, contrairement à ce
> que j'ai pu lire parmi les commentaires, le suivi de sécurité bien
> qu'officielement absent est facilement remplacé par les priorités accordées à
> de telles mises à jour pour les paquets entrant dans l'unstable. En effet, la
> durée d'incubation varie en fonction de ce paramètre: 10, 5 ou 2 jours.

Ce qui est la durée minimum.
Si maintenant le passage à gccX+1 ou glibcX+1 bloque tout les paquets compilés car elle même ne peut pas venir dans testing, tu es coincé.
SUffit de voir des paquets coincés dans unstable depuis plusieurs mois, car une dépendances est coincés en même temps.

> T'as déjà essayé une unstable ?

Oui j'ai déja tourné en unstable, et on s'en tire relativement bien dés qu'on s'y connait. Et suffisament longtemps pour voir ce que ça vaut. Ça ne m'a pas plus pour tout un tas de raisons, que j'ai renoncé depuis longtemps à expliquer.

Actuellement, la tendance est de rendre unstable vachement moins unstable, en uploadant dans experimental, car justement, tout le monde utilise.
La ou des distribs comme mdk et fedora n'hésite pas à tout péter en uploadant un nouveau python dans cooker ou rawhide, debian préfére maintenir 3 versions du langage, afin de ne pas trop casser unstable, car de plus en plus de gens l'utilise. Ce qui au final ralentit le travail, et ceux uniquement parce que les versions ne sortent pas assez vite. Le serpent se mord la queue, selon moi. Même si il n'y a pas que ça qui ralentit, j'en suis conscient.

> par contre une "testing" va très bien en utilisation de bureau.

Et comme dit 100 fois, la sécurité dans tout ça ?

Toujours de la patience.
Comme pour la sortie de sarge.

C'est surtout faire glisser le but de unstable de distribution de développement à distribution pour tous. Combien d'utilisateur de unstable font ça pour aider debian ? Combien pour juste avoir des softs à jours ?

On se retrouve alors avec des choses comme de plus en plus de softs dans experimental, et donc moins testés alors qu'ils en aurait plus besoin.
Des rapports de bugs aussi de moins en moins bon, car tout le monde utilise unstable et pas que les utilisateurs avertis, les gens sont moins rompus à cette pratique. Voir même certains qui mettent tout en RC, sans réalisés que ça nuit au passage en testing des softs et donc à la sortie.

Ce qui au final ne fait que ralentir la release, et donc pénalise ceux qui joue les "régles" du jeu, cad utilisé stable pour ce qu'elle est, et ne pas utilisé unstable car faut pas raler si c'est cassé.

Sauf que 1) testing bouge tout le temps 2) testing n'est pas mise à jour pour la sécurité, il suffit d'avoir gcc qui bloque des trucs, et pouf, tes machines deviennent un gruyére avec le temps.

Si c'est pour se retrouver avec un windows bis au niveau sécu, merci.

On sens que tu commence à me suivre à la trace, tout ça parce que j'ai eu la mauvaise idée de parler de features qui servent sur des *vrais* serveurs, utilisés par des *vrais* admins, que l'install woody ne supporte pas.

Moi, je peut le montrer que 1) les gens utilisent lvm 2) que ne pas l'utilisé, c'est pas top.

Toi, tu peut pas me prouver que de plus en plus de gens utilise debian.
Et deplus j'ai donné mon avis, alors que la personne a énoncé ça comme une vérité.
Il y a une différence subtile que tu devrait surement réussir à saisir.

> Tu fais bien de le dire. Les développeurs Debian ne s'en étaient pas
> rendus compte, ils te remercient. D'ailleurs aucun nouvel installeur n'est
> prévu pour sarge.

SI les developpeurs eux mêmes n'ont pas compris, ça explique aussi pourquoi les utilisateurs le trouve si parfait....

Quand je dit debianneux, je parle pas des dévelopeurs, qui ont en général les pieds sur terre, font du bon boulot, et ont mieux à faire que de mouler ici. Je parle de l'user de base qui zone parfois ici, et qui donne à debian cette réputation si particuliére.