Misc a écrit 6286 commentaires

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.

C'est pas plus "équitable", ça arrange plus debian.

C'est pas les années qui font les incompatiblités, mais les versions.

Si jamais tu releases tout les 10 ans, et que tu prévoit que tu va changer de tel version à tel version, oui ça marcheras.

Si tu as 20 cas particuliers à traiter dans les scripts d'upgrades, forcément, ça passe moins bien.

J'ai entendu dire que le code source de sarge serait diponible publiquement sur des servuers ftp partout dans le monde, comme hl2....


======>[]

Installe une debian 1.1 et mets à jour en sarge.
7.2 a 10, ça fait ...
7 versions.
Donc prends une buzz, et fait l'upgrade.
Si il y a apt dessus, bien sur...

> En effet, Debian précise bien que la sortie de la Debian suivante se fait
> quand elle est prête, et non à date fixée.

Alors, pourquoi est ce que j'entends depuis un an des "sarge va sortir bientot", pourquoi est ce que je vit des pubs dans linuxmag, des pubs certes dépouillés, mais des pubs pour rappeler que sarge sort bientot.

et surtout, ou est ce que l'on décide de prêt ou pas ?

SI prêt veut dire plus de RC bugs, on peut reporter le problème à qui décide de freezer les versions pour se consacrer uniquement à la chasse au bug.

Le problème c'est que "debian sort quand c'est prêt", mais personne défini ce que prêt veut dire, et tout le monde trouve ça normal.
La plupart des devs vivent au jour le jour, fixant leur bugs, votant sur les listes ( parfois ), sans que personne ne puisse dire ce qui est prévu.

C'est le rêve de tout développeur professionnel de pouvoir se déconnecter de la réalité, d'envoyer sur les roses les users et le patron, qui demandent des trucs, avec des deadlines et tout ça.
Et bien, chez debian, ils ont réalisés ce rêve.
Quelque part, ç'est beau. 1000 personnes qui rêvent....

> Que reproches-tu au système de partitionnement de Debian ? Il est très
> bien !

cfdisk et fdisk redimensionne la fat ? le ntfs ? non.
Mais ça sert jamais, on va prendre un autre. Le support du lvm ?
Non plus.
Donc techniquement, ça pue.

Et oui, bien sur, il y a d'autres installeurs. Ce qui prouve bien que techniquement, celui de debian est pas assez bon.

Il y a pas que le graphique, tu saute trop vite au conclusion. Comme tout les debianneux qui n'ont plus vu ce qui se passe en face depuis des années, omnibulés par le seul truc visible de l'installation, le coté graphique.


> Et de toute facon, une Debian, ca s'installe une fois, et ca s'utilise des
> années ... Alors chipoter pour 2 heures d'installation !

J'ai jamais reinstallé ma mdk depuis la 8.2, date de la premiére install, d'un pc neuf. J'ai du faire plus de cycles d'upgrade que tu as du en faire depuis que tu utilise debian, sauf si tu utilise ça depuis la 2.0.

Toi, tu as pas eu besoin de recompiler le kernel pendant l'install debian sur un serveur pour la prise en charge du raid, comme j'ai pu voir chez certains que je connait.
L'installation 2H et on oublie, tu compte pas les 3 semaines de backports/config que tu te tapes aprés.

Ben tu peut rire, mais les debianneux s'en vantent

Tellement de gens qui forkent, qui refusent de suivre le projet mére, et de suivre les autres. Ensuite, on s'étonne que le projet arrivent pas à fermer tout les bugs RC...

Tellement d'installeurs alternatifs, mais beaucoup moins de remontés au niveau du vrai installeur...

Tellement de dépot alternatifs, au lieu d'aider backports.org.

Le fork a déja eu lieu.

Ou sont définis formellement les notions de meilleur ou moins bon, chez debian ?

Meilleur techniquement ?

Surement pas, car sinon jamais le systême de partionnement actuel n'aurais pu passer, même avec les standards de meilleur d'il y a deux ans. Peut être avec ceux d'il y 5 ans, oui.

Meilleurs, au niveau de la liberté ?
Alors pourquoi encore supporté nonfree, si ce n'est pour satisfaire les utilisateurs ?

Meilleurs pour l'utilisateur ?
Cette mesure montre clairement que non. Enfin à part les utilisateurs qui sont contents de passer pour des gens plus intégristes que RMS et linus, et à qui on arrive à faire accepter un retard digne de microsoft, malgré un planning déja en retard, et qui sont vachement content d'apprendre que une fois de plus, l'installation debian sur certains serveurs va être reservé à une élite qui sais comment recompiler un kernel pendant l'install sur un serveur.
Ces mêmes utilisateurs qui vont s'étonner que RH vole le marché du serveur, alors que debian serait tellement mieux.


Meilleur au niveau des discussion sans fin que ça engendre ici, oui sans doute, mais je pense pas...

> Pourtant, il y a de plus en plus d'utilisateurs Debian ...

des chiffres, des proportions ?

Tu as surement accés à des archives secrétes du nombres d'utilisateurs du libres ?

Peut être des "je voit que" ?
Trés scientifique comme méthode.

Utilise autre chose que kate ?

genre, emacs, ou evim ou n'importe quoi d'autres ?

pour ceux qui veulent pas passer 15 minutes à chercher le mail, c'est ici :

http://lists.debian.org/debian-devel/2004/debian-devel-200404/msg03(...)

Moi aussi, je trouve que faire des changements si importants alors que sarge doit sortir, c'est abusé.
Si debian s'en tenait à ses objectifs, sarge serait sorti sous peu. Même en s'autorisant un peu ( ~ 6 mois ) de retard, on fout pas tout en l'air 1 mois avant.

Et moi aussi, je trouve aussi que woody pue le moisi, un certain serveur dont je m'occupe est bourré de backport, on est bien obligé dés qu'on veut des features aussi révolutionnaires et unstable que postfix+sasl, clamav et un spamassassin un peu plus à jour que ce que woody propose.

Si jamais il y a encore une discussion ou un changement à faire, debian va encore retardé la distribution, et tenir en otage tout les utilisateurs de la stable ?

On tient pas compte des gens qui veulent une version stable sur leur serveur, à qui on promet depuis 1 an des "sarge va sortir bientot", des personnes qui répète ça et qui au final se retrouve un peu ridicule, du travail en plus pour un admin à qui on demande de mettre des trucs plus récents ?

j'ai rien contre le fait que debian nettoie son kernel et la doc de sa glibc car elle contient des morceaux pas assez libre pour elle.

Mais repoussé indéfiniment la release, et au final ne pas vraiment régler le probléme ( car tout le monde va finalement ajouter non-free dans le sources.list, banalisant par la même son utilisation, et rendant son éviction encore plus difficile ), c'est stupide.
La solution adopté, c'est juste pour l'apparence, une masquerade.

Pour le clic sur un touch pad, il faut simplement installer un paquet, synaptics, et ajouter ça dans la conf. Le support plus automatisé est dans la liste des choses à faire ( http://qa.mandrakesoft.com/twiki/bin/view/Main/IdeasForMandrakelinu(...) )
et il y a même un bug d'ouvert :
http://qa.mandrakesoft.com/show_bug.cgi?id=9008(...)

maintenant, la solution de mettre l'usb directement dans le kernel est pas trés propre à mon sens...

> le projet ne te doit rien à se que je sache

Je me permet de te citer le contrat social :

"4) Nos priorités sont nos utilisateurs et les logiciels libres"

et même :

"Les besoins de nos utilisateurs et de la communauté des logiciels libres nous guideront. Nous placerons leurs intérêts en tête de nos priorités. "

Donc satisfaire l'utilisateur doit être la priorité, non ?

( allez, jeanmi boude pas :) )

Conectiva ( http://conectiva.br(...) ) utilise subversion en interne, d'aprés un poste sur la liste de subversion. Mais je ne croit pas que ça soit public.

Argh, mes tags en moulxml sont pas passés :/
Il fallait lire <ironie>