dans ce post, je vais vous dire pourquoi linux est mauvais, bien que
tout le monde le sache deja. or, si les defauts de linux sont si
evidents, pourquoi personne ne s'en rend compte ? c'est ce que je
developperai dans une seconde partie. ensuite, dans une troisieme
partie, je listerai les excuses les plus courantes pour ne pas
reconnaitre que linux est mauvais. enfin, dans une derniere partie, je
vous raconterai quelques anecdotes a propos de linux.
########################
# 1. linux est mauvais #
########################
a) mauvaise IHM
===============
pourquoi est-ce mauvais ? meme un cretin de windowsien est capable d'y
repondre : "parce que c'est trop dur a utiliser".
citons quelques exemples :
- les boites de dialogues qui ne se rafraichissent pas
- les boutons qui ne marchent pas
- les controles qui n'ont aucun effet
- l'installation de logiciel ne cree pas d'icone, ni de groupe, ni
d'entree de desinstallation visible
- c'est tellement laborieux qu'il faut toujours lire la doc
- ca ne marche pas bien que l'on ait fait exactement ce que dit la doc
- correction de code source, recompilation de noyau, ...
etc.
voila. je ne developpe pas trop ce point, car vous ne le connaissez
que trop bien.
b) mauvaise IHM = mauvais ?
===========================
la mauvaise IHM est-elle suffisante pour dire que linux est mauvais ?
reponse : oui. il faut garder en tete qu'un ordinateur est fait pour
etre UTILISE. le fait d'avoir du mal ou de ne pas arriver a l'utiliser
est donc un GRAVE DEFAUT.
de nos jours, la technologie est capable de permettre a n'importe qui
d'utiliser un ordinateur LES DOIGTS DANS LE NEZ ! linux en est encore
loin.
##############################################
# 2. pourquoi tout le monde est-il aveugle ? #
##############################################
a) fierte personnelle
=====================
linux est plus difficile a utiliser. il y a donc plus de fierte a
arriver a le faire fonctionner. c'est d'ailleurs pourquoi on a vite
fait de traiter les windowsiens de "cretins". on les sent tellement
inferieurs a nous...
bien evidemment, cette fierte est inconsciente. si on en etait
conscient, elle ne pourrait pas nous aveugler.
b) la joie
==========
outre le fait que cet OS laborieux satisfasse notre orgueil, il nous
procure aussi de la joie : en effet, lorsque l'on trouve la solution
pour installer sa carte son apres avoir galere pendant un mois, on est
CONTENT.
cette joie nous encourage et nous aveugle. apres une telle reussite,
peu sont encore capables de voir qu'ils ont perdu 1 mois. on va plutot
aller voir le copain et tout heureux, on lui dit :
"J'AI REUSSI A FAIRE MARCHER MA CARTE SON SOUS LINUX !!!!!!!!!!"
bref, aucun esprit critique sur le mois perdu.
c) le plaisir
=============
l'informatique, c'est INTERESSANT comme domaine. c'est INTERESSANT de
savoir comment ca marche, meme si on n'a pas besoin de savoir. cette
passion pour l'informatique nous fait elle-aussi prendre les galeres
linuxiennes pour des qualites. en effet, ces galeres nous font
explorer les bas fonds de l'informatique, ce qui est un plaisir.
d) la convoitise
================
avoir linux, c'est moins courant que d'avoir windows. ca fait
"nouveau" dans les yeux. en somme, ca rend jaloux le voisin, et ca
permet de faire le blaireau devant les copains. voila encore quelque
chose qui seduit inconsciemment les gens.
remarque : les points que je viens d'enumerer sont DEBILES, dans le
sens ou il faudrait etre DEBILE pour tomber dans des pieges pareils !
pourtant, c'est bien dans ceux-la que nous tombons.
e) aucun borgne au pays des aveugles
====================================
PERSONNE n'est la pour ouvrir les yeux aux linuxiens. plus d'un
windowsien est venu critiquer linux. ils se sont vite fait calmer : ne
connaissant pas suffisamment linux pour le critiquer, et ont vite ete
vaincus.
passons a la seconde categorie de windowsiens, ceux qui se sont
SERIEUSEMENT mis a linux. la difference de convivialite devrait leur
sauter aux yeux, et leurs critiques devraient permettre d'ouvrir les
yeux aux linuxiens... QUE NENNI ! les voila eux-aussi tombes amoureux
de linux. les windowsiens ne sont pas plus intelligents que les
linuxiens : ils sont eux-aussi tombes dans les memes pieges.
resultat : aucun borgne au pays des aveugles.
########################
# 3. defendons linux ! #
########################
maintenant que l'on est tombes sous le charme de linux, on perd
totalement notre objectivite. on n'est plus capable de reconnaitre la
verite. on defendra linux envers et contre tout ! cela nous amene a
dire beaucoup de betises...
a) attaque : "c'est trop laborieux a utiliser linux !"
======================================================
ce que l'on repond souvent dans ce cas-la, c'est :
"c'est parce que t'es pas assez intelligent pour l'utiliser !".
ainsi, on s'attaque aux sentiments personnels du windowsien. il va
repondre : "moi ? pas intelligent ?". il va commencer a nous sortir
les ecoles par lesquels il est passe, ses notes scolaires, sa position
dans le classement, ses resultats aux tests de QI qui circulent sur le
NET... etc.
c'est lamentable de voir des discussions derailler ainsi.
l'affirmation initiale etait pourtant vraie : c'est trop laborieux a
utiliser. si on a besoin d'etre INTELLIGENT pour pouvoir utiliser
linux, c'est mauvais. un bon OS devrait etre utilisable par n'importe
qui.
b) intelligence
===============
avant de passer a la prochaine replique, je vais dire un mot sur
l'intelligence. est-il vrai qu'il faille etre INTELLIGENT pour
utiliser linux ? reponse : oui sur un certain plan, et non sur un
autre.
un mot qui conviendrait peut-etre mieux, c'est le mot PERSEVERANT.
comme linux est plus difficile a utiliser, il faut etre plus
PERSEVERANT. l'intelligence a egalement a voir, puisque l'on doit
COMPRENDRE le fonctionnement pour pouvoir s'en sortir sous linux.
par contre, sur le plan du bon sens, il faut etre BETE pour ne pas se
rendre compte que c'est un defaut d'avoir besoin d'intelligence, ou de
perseverance pour utiliser un OS. l'homme a cree la machine pour que
la machine lui rende service. la machine est POTENTIELLEMENT capable
de nous eviter de galerer dans toutes ces configurations linuxiennes.
si on a besoin d'etre INTELLIGENT, c'est que la machine n'a pas fait
une partie de son travail, et qu'on doit le faire a sa place. si on
doit s'adapter a la machine, c'est que la machine est mauvaise. c'est
la machine qui doit s'adapter a l'homme.
c) un OS de developpeur
=======================
un linuxien plus calme repond autrement a cette attaque en a). il
n'essaye pas de mettre le feu. il dit :
"chacun ses gouts, chacun son avis, chacun ses besoins. cet OS ne te
satisfait pas, il n'est pas fait pour toi. c'est un OS de
developpeurs, et pour un developpeur, c'est de la rigolade de resoudre
toutes ces peripeties."
meme si le ton est plus calme, ce linuxien pense tout de meme : "1 OS
pour chacun, 1 pour les gens intelligents, 1 pour les cretins !".
c'est donc toujours le meme probleme d'intelligence !
comme j'ai deja suffisamment parle de l'intelligence, je ne recommence
pas, mais je vais parler du fait d'etre developpeur : meme pour un
developpeur (ou d'un expert linux), une galere reste une galere;
eux-aussi passent par des moyens classiques pour installer leur OS.
exemple : telechargement des drivers, compilation des drivers,
chargement des drivers. quand les drivers distribues ne marchent pas,
ils perdent egalement du temps.
donc, meme si on est developpeur, on a besoin d'un bon OS. je dirais
meme que pour pouvoir developper en paix, on a besoin que l'OS nous
fiche la paix avec ses problemes de fonctionnement.
je laisse de cote les autres erreurs de l'affirmation.
d) la reponse du paresseux
==========================
voici la reponse du linuxien paresseux. il n'a pas envie de discuter,
ni de defendre linux. il repond :
"retourne sous windows !"
en effet, si on prefere windows, pourquoi venir sous linux ?
je ne repondrai pas a cette derniere question afin de ne pas perdre le
sujet de vue : lors de cette replique, un defaut de linux a ete cite,
et n'a pas ete contredit. c'est ce qu'aucun linuxien ne voit jamais
lorsqu'il repond "retourne sous windows". apres le passage de ce
windowsien, ce linuxien n'aura toujours pas pris conscience du defaut
cite.
e) la reponse du developpeur
============================
"quelque chose ne te convient pas sous linux ? eh bien ameliore-le !
prend le code source, et modifie ce que tu veux dedans !"
la encore, c'est la meme erreur : le developpeur n'a pas contredit le
defaut. il suggere une "solution" en se gardant de reconnaitre que
defaut il y a. apres le passage de ce windowsien, ce developpeur
n'aura pas pris conscience d'un quelconque defaut, lui non plus. le
cerveau d'un humain n'est decidement qu'une PASSOIRE !
voila encore une reponse linuxienne typique. lire le manuel est
pourtant quelque chose de naturel a faire. seulement, ils sont souvent
tres mals ecrits. par exemple, lorsque le manuel donne une liste par
ordre alphabetique des directives possibles a mettre dans les fichiers
de configuration. d'autres donnent la grammaire (au sens de la theorie
des langages) du fichier de configuration... INUTILISABLE !
bien sur, le fait d'etre oblige de lire le manuel est deja un defaut
par rapport aux logiciels intuitifs que l'on peut prendre en main sans
avoir a apprendre le lexique et la syntaxe du fichier de
configuration par coeur...
cet etat de conscience par rapport a linux, je vis en permanence
la-dedans. si ces choses sont des revelations pour vous, ce sont de
grosses evidences pour moi. ca me fatigue quand je vais voir des
linuxiens, et qu'ils sont a l'image que je me fais d'eux : ils sont en
plein dans les defauts que je critique, et ne voient absolument pas ou
est leur erreur.
a) utiliser sans rien comprendre
================================
voici la premiere anecdote. c'est la plus recente qui m'est arrivee :
je suis alle sur un canal de linuxiens, et j'ai demande une IHM pour
me faciliter l'utilisation d'un logiciel trop laborieux a mon gout.
apres quelques etincelles "windows vs linux", l'un d'eux m'a dit qu'il
avait l'impression que je voulais faire des tas de trucs sans rien
comprendre a la technique.
je saisissais bien sur tout ce qu'il sous-entendait par cette
remarque. c'etait desolant de voir un linuxien autant dans l'erreur...
dans une erreur qui est tellement evidente pour moi, et completement
invisible aux yeux de l'individu... il m'a encore fait plus de peine
en insistant pour que je lui dise de quelle erreur il s'agissait... il
ne voyait vraiment pas.
pour lui, il faut absolument COMPRENDRE la technique pour pouvoir
utiliser, c'est-a-dire, comprendre comment ca marche. or, d'apres ce
que j'ai dit precedemment, on sait bien que ce n'est pas necessaire.
c'est meme un defaut d'etre oblige de comprendre. de plus, c'est tout
a fait naturel de vouloir utiliser sans comprendre. c'est le but des
machines, de l'informatique : on utilise une voiture sans comprendre
comment elle fonctionne, on utilise un logiciel sans savoir sous
quelle forme sont stockees les donnees, on utilise des fonctions de
librairies dont on n'a jamais regarde le code source, etc.
pour ce linuxien, le fait de se croire plus intelligent (parce que
l'on comprend tout) lui a completement fait perdre de vue l'objectif
de base de la creation de logiciels. voyez comme ces problemes
psychologiques peuvent mener loin.
b) le genie linuxien
====================
j'ai recemment entendu parler d'un genie linuxien-philosophe qui a
obtenu son doctorat a 20 ans. 4 ans plus tard, il sort un article ou
il parle du monde libre. je me suis dit : "on va enfin avoir l'avis
d'un etre superieur..."
resultat : c'etait LAMENTABLE ! il a sorti toutes les betises qu'un
linuxien ordinaire aurait dites ! il etait lui-aussi completement
tombe dans les pieges linuxiens ! et dire que c'est un genie,
c'est-a-dire, le meilleur d'entre vous !
l'une des expressions que j'ai retenues, c'etait : "un monde plus
humain" (les mots pour faire la grosse pub a linux...). ce qu'il
voulait dire par ces mots, c'est qu'il y avait un meilleur contact
entre humains : l'utilisateur peut plus facilement contacter le
developpeur, soumettre une modification au code, ameliorer le
logiciel, etc. je ne le contredirai pas la-dessus.
seulement, l'expression "un monde plus humain" ne me convient pas, car
cet environnement n'est pas adapte a un humain, puisqu'il n'est pas
intuitif. d'un autre point de vue, cette expression convient bien, si
on veut la comprendre dans le sens "un monde COMPOSE d'humains". en
effet, comme la machine ne fait pas son travail, ce sont les humains
qui doivent le faire a sa place.
c) discussion entre linuxiens
=============================
j'ai surpris une discussion entre linuxiens un jour. j'ai bien sur ete
navre : ils etaient toujours a l'image que je me faisais d'eux,
toujours dans la meme erreur, et tres loin d'en sortir. ils parlaient
du deploiement de linux, de faire connaitre linux aux gens, de les
former a cet OS... completement a cote de la plaque... ce n'est pas
les gens qu'il faut former ! c'est l'OS qui doit nous obeir, et pas le
contraire !
s'ils parlent de "former les gens a linux", c'est qu'ils savent
pourtant que linux est dur a prendre en main. pourquoi ne parlent-ils
pas plutot d'AMELIORER linux ?
ainsi, c'est a nous de nous adapter a la machine. nous devenons petit
a petit l'esclave de la machine. on pensait que la machine aurait
besoin d'IA pour pouvoir nous dominer, mais en fait, c'est inutile,
elle y arrive deja.
si on reconnaissait enfin les defauts de linux afin de pouvoir les
corriger, alors peut-etre qu'un jour, linux deviendrait reellement un
bon OS, et ne se contenterait plus de satisfaire les gens qui ont des
problemes affectifs.
---
remarque : en fait, ce n'est pas vraiment linux que j'ai critique,
mais tout le monde libre.
Q: How is security handled for testing and unstable?
A: The short answer is: it's not. Testing and unstable are rapidly moving targets and the security team does not have the resources needed to properly support those. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable. However, the security secretaries will try to fix problems in testing and unstable after they are fixed in the stable release.
http://www.debian.org/security/faq#testing
Il faut lire entre les lignes. La Debian stable est une distribution qui n'évolue plus. Quand un problème de sécurité dans un logiciel de la debian stable apparaît, ce logiciel n'est pas mis-à-jour vers une version plus récente sans le trou de sécurité, mais est simplement corrigé.
Oui, ça s'appelle appliquer des patches si je ne me trompe. Toutes les distros font ça, y compris Slackware. Mais il arrive parfois, quoi que rarement, je pense, qu'il n'y ait pas de patch et qu'il faille changer tout le paquet. La source la plus commune pour les patches semble être mitre.org. Rien de nouveau là, même entre les lignes.
Je me demande seulement pourquoi ça semble une tâche d'une telle envergure chez Debian alors que Volkerding arrive à faire ça seul.
Les Debian testing et unstable, elles, évoluent. Quand un problème de sécurité apparaît, le logiciel est généralement mis à jour rapidement et n'a pas besoin de correction per se.
Idem pour Slackware. S'il y a une patch pour un paquet existant et un nouveau paquet, il va évidemment choisir le nouveau paquet plutôt que de patcher l'ancien et d'installer le nouveau plus tard. Ça va de soi.
Seulement, selon ce que j'ai entendu dire... entre les branches des arbres, cette fois, c'est que dans le testing Debian, le paquet ne change pas. Parce que, quand on change le paquet, ça peut impliquer d'autres changements, de librairies, de dépendances etc., qui chambarderaient trop le test.
Alors, je ne sais pas trop, j'ai peut-être manqué un HOWTO sur la lecture entre les lignes? Mais, sur la ligne, ce n'est pas du tout ce que tu dis qui est écrit, et pas tout à fait ce que j'ai entendu dire, non plus. Permets que je traduise:
Q.: Comment la sécurité de testing et unstable est-elle prise en charge?
R.: En un mot elle ne l'est pas. (...) Les «secrétaires» de la sécurité tentent de régler les problèmes dans testing et unstable quand ils en ont fini avec stable.
----------------------
Pour des gens qui aiment tellement écrire, je pense qu'ils pourraient décrire la situation beaucoup plus précisément en n'étant pas plus longs.
Chez Slackware, les choses sont plus simples. Il y a deux versions -- stable et current -- et les deux sont à jour question sécurité. (Et même des précédentes, comme chez Debian, d'ailleurs, si je ne me trompe.)
Le problème chez Debian, c'est qu'ils chargent des comités de dessiner un dromadaire, qu'ils finissent avec un chameau et qu'ils ne savent pas à quoi sert l'autre bosse. Ensuite, ils demandent à quelqu'un d'écrire la doc et d'être très précis. Reste ensuite à lire entre les lignes.
Fatiguant! Je comprends Volkerding d'être crampé de rire... ou complètement outré lorsqu'il parle de Debian. Hé, même Murdock les manie avec des pincettes!
GP
Richard Delorme wrote:
GP wrote:
Q: How is security handled for testing and unstable?
A: The short answer is: it's not. Testing and unstable are rapidly
moving targets and the security team does not have the resources
needed to properly support those. If you want to have a secure (and
stable) server you are strongly encouraged to stay with stable.
However, the security secretaries will try to fix problems in testing
and unstable after they are fixed in the stable release.
http://www.debian.org/security/faq#testing
Il faut lire entre les lignes.
La Debian stable est une distribution qui n'évolue plus. Quand un
problème de sécurité dans un logiciel de la debian stable apparaît, ce
logiciel n'est pas mis-à-jour vers une version plus récente sans le trou
de sécurité, mais est simplement corrigé.
Oui, ça s'appelle appliquer des patches si je ne me trompe. Toutes les
distros font ça, y compris Slackware. Mais il arrive parfois, quoi que
rarement, je pense, qu'il n'y ait pas de patch et qu'il faille changer
tout le paquet. La source la plus commune pour les patches semble être
mitre.org. Rien de nouveau là, même entre les lignes.
Je me demande seulement pourquoi ça semble une tâche d'une telle
envergure chez Debian alors que Volkerding arrive à faire ça seul.
Les Debian testing et unstable, elles, évoluent. Quand un problème de
sécurité apparaît, le logiciel est généralement mis à jour rapidement et
n'a pas besoin de correction per se.
Idem pour Slackware. S'il y a une patch pour un paquet existant et un
nouveau paquet, il va évidemment choisir le nouveau paquet plutôt que
de patcher l'ancien et d'installer le nouveau plus tard. Ça va de soi.
Seulement, selon ce que j'ai entendu dire... entre les branches des
arbres, cette fois, c'est que dans le testing Debian, le paquet ne
change pas. Parce que, quand on change le paquet, ça peut impliquer
d'autres changements, de librairies, de dépendances etc., qui
chambarderaient trop le test.
Alors, je ne sais pas trop, j'ai peut-être manqué un HOWTO sur la
lecture entre les lignes? Mais, sur la ligne, ce n'est pas du tout ce
que tu dis qui est écrit, et pas tout à fait ce que j'ai entendu dire,
non plus. Permets que je traduise:
Q.: Comment la sécurité de testing et unstable est-elle prise en charge?
R.: En un mot elle ne l'est pas. (...) Les «secrétaires» de la
sécurité tentent de régler les problèmes dans testing et unstable
quand ils en ont fini avec stable.
----------------------
Pour des gens qui aiment tellement écrire, je pense qu'ils pourraient
décrire la situation beaucoup plus précisément en n'étant pas plus longs.
Chez Slackware, les choses sont plus simples. Il y a deux versions --
stable et current -- et les deux sont à jour question sécurité. (Et
même des précédentes, comme chez Debian, d'ailleurs, si je ne me trompe.)
Le problème chez Debian, c'est qu'ils chargent des comités de dessiner
un dromadaire, qu'ils finissent avec un chameau et qu'ils ne savent
pas à quoi sert l'autre bosse. Ensuite, ils demandent à quelqu'un
d'écrire la doc et d'être très précis. Reste ensuite à lire entre les
lignes.
Fatiguant! Je comprends Volkerding d'être crampé de rire... ou
complètement outré lorsqu'il parle de Debian. Hé, même Murdock les
manie avec des pincettes!
Q: How is security handled for testing and unstable?
A: The short answer is: it's not. Testing and unstable are rapidly moving targets and the security team does not have the resources needed to properly support those. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable. However, the security secretaries will try to fix problems in testing and unstable after they are fixed in the stable release.
http://www.debian.org/security/faq#testing
Il faut lire entre les lignes. La Debian stable est une distribution qui n'évolue plus. Quand un problème de sécurité dans un logiciel de la debian stable apparaît, ce logiciel n'est pas mis-à-jour vers une version plus récente sans le trou de sécurité, mais est simplement corrigé.
Oui, ça s'appelle appliquer des patches si je ne me trompe. Toutes les distros font ça, y compris Slackware. Mais il arrive parfois, quoi que rarement, je pense, qu'il n'y ait pas de patch et qu'il faille changer tout le paquet. La source la plus commune pour les patches semble être mitre.org. Rien de nouveau là, même entre les lignes.
Je me demande seulement pourquoi ça semble une tâche d'une telle envergure chez Debian alors que Volkerding arrive à faire ça seul.
Les Debian testing et unstable, elles, évoluent. Quand un problème de sécurité apparaît, le logiciel est généralement mis à jour rapidement et n'a pas besoin de correction per se.
Idem pour Slackware. S'il y a une patch pour un paquet existant et un nouveau paquet, il va évidemment choisir le nouveau paquet plutôt que de patcher l'ancien et d'installer le nouveau plus tard. Ça va de soi.
Seulement, selon ce que j'ai entendu dire... entre les branches des arbres, cette fois, c'est que dans le testing Debian, le paquet ne change pas. Parce que, quand on change le paquet, ça peut impliquer d'autres changements, de librairies, de dépendances etc., qui chambarderaient trop le test.
Alors, je ne sais pas trop, j'ai peut-être manqué un HOWTO sur la lecture entre les lignes? Mais, sur la ligne, ce n'est pas du tout ce que tu dis qui est écrit, et pas tout à fait ce que j'ai entendu dire, non plus. Permets que je traduise:
Q.: Comment la sécurité de testing et unstable est-elle prise en charge?
R.: En un mot elle ne l'est pas. (...) Les «secrétaires» de la sécurité tentent de régler les problèmes dans testing et unstable quand ils en ont fini avec stable.
----------------------
Pour des gens qui aiment tellement écrire, je pense qu'ils pourraient décrire la situation beaucoup plus précisément en n'étant pas plus longs.
Chez Slackware, les choses sont plus simples. Il y a deux versions -- stable et current -- et les deux sont à jour question sécurité. (Et même des précédentes, comme chez Debian, d'ailleurs, si je ne me trompe.)
Le problème chez Debian, c'est qu'ils chargent des comités de dessiner un dromadaire, qu'ils finissent avec un chameau et qu'ils ne savent pas à quoi sert l'autre bosse. Ensuite, ils demandent à quelqu'un d'écrire la doc et d'être très précis. Reste ensuite à lire entre les lignes.
Fatiguant! Je comprends Volkerding d'être crampé de rire... ou complètement outré lorsqu'il parle de Debian. Hé, même Murdock les manie avec des pincettes!
GP
Franck Yvonnet
Ainsi Parlait Philippe Lebon
luc2 wrote:
2% sur 15 tera-octets, c'est quand-meme pas mal. Tu l'a payé cher ton disque dur ?
Vu la capacité, c'est au moins une baie SAN. Et il me semble que c'est
pas donné du tout :-)
-- Franck Yvonnet "Reality is that which, when you stop believing in it, doesn't go away." - Philip K. Dick
Ainsi Parlait Philippe Lebon <dave.null@bidon.invalid>
luc2 wrote:
2% sur 15 tera-octets, c'est quand-meme pas mal.
Tu l'a payé cher ton disque dur ?
Vu la capacité, c'est au moins une baie SAN. Et il me semble que c'est
pas donné du tout :-)
--
Franck Yvonnet <franck@yvonnet.org>
"Reality is that which, when you stop believing in it, doesn't go away."
- Philip K. Dick
2% sur 15 tera-octets, c'est quand-meme pas mal. Tu l'a payé cher ton disque dur ?
Vu la capacité, c'est au moins une baie SAN. Et il me semble que c'est
pas donné du tout :-)
-- Franck Yvonnet "Reality is that which, when you stop believing in it, doesn't go away." - Philip K. Dick
Franck Yvonnet
Ainsi Parlait Jerome Lambert
En fait, le monsieur ici fonctionne comme ceci: soit on est d'accord avec lui, soit on est de mauvaise foi.
Remarquez aussi que lorsqu'on lui renvoie des arguments qui le mettent en défaut, il ne répond pas...
Ou alors il va te répondre d'arreter tes conneries, que ça n'a rien à voir avec le problème, et que tu ferais mieux de te rendre à l'évidence. D'ailleurs j'attend toujours qu'il m'explique pour les éditeurs vendent autant de bouquin sur Windows vu qu'on est censé savoir s'en servir instinctivement.
-- Franck Yvonnet "Reality is that which, when you stop believing in it, doesn't go away." - Philip K. Dick
Ainsi Parlait Jerome Lambert <jerome.lambert@swing.be>
En fait, le monsieur ici fonctionne comme ceci: soit on est d'accord avec
lui, soit on est de mauvaise foi.
Remarquez aussi que lorsqu'on lui renvoie des arguments qui le mettent en
défaut, il ne répond pas...
Ou alors il va te répondre d'arreter tes conneries, que ça n'a rien à
voir avec le problème, et que tu ferais mieux de te rendre à l'évidence.
D'ailleurs j'attend toujours qu'il m'explique pour les éditeurs vendent
autant de bouquin sur Windows vu qu'on est censé savoir s'en servir
instinctivement.
--
Franck Yvonnet <franck@yvonnet.org>
"Reality is that which, when you stop believing in it, doesn't go away."
- Philip K. Dick
En fait, le monsieur ici fonctionne comme ceci: soit on est d'accord avec lui, soit on est de mauvaise foi.
Remarquez aussi que lorsqu'on lui renvoie des arguments qui le mettent en défaut, il ne répond pas...
Ou alors il va te répondre d'arreter tes conneries, que ça n'a rien à voir avec le problème, et que tu ferais mieux de te rendre à l'évidence. D'ailleurs j'attend toujours qu'il m'explique pour les éditeurs vendent autant de bouquin sur Windows vu qu'on est censé savoir s'en servir instinctivement.
-- Franck Yvonnet "Reality is that which, when you stop believing in it, doesn't go away." - Philip K. Dick
Raphaël 'SurcouF' Bordet
On dim, 2004-08-01 at 22:50 -0400, GP wrote:
Richard Delorme wrote:
GP wrote:
Q: How is security handled for testing and unstable?
A: The short answer is: it's not. Testing and unstable are rapidly moving targets and the security team does not have the resources needed to properly support those. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable. However, the security secretaries will try to fix problems in testing and unstable after they are fixed in the stable release.
http://www.debian.org/security/faq#testing
Il faut lire entre les lignes. La Debian stable est une distribution qui n'évolue plus. Quand un problème de sécurité dans un logiciel de la debian stable appara ît, ce logiciel n'est pas mis-à-jour vers une version plus récente sans le trou de sécurité, mais est simplement corrigé.
Oui, ça s'appelle appliquer des patches si je ne me trompe. Toutes les distros font ça, y compris Slackware. Mais il arrive parfois, quoi que rarement, je pense, qu'il n'y ait pas de patch et qu'il faille changer tout le paquet. La source la plus commune pour les patches semble être mitre.org. Rien de nouveau là, même entre les lignes.
Je me demande seulement pourquoi ça semble une tâche d'une telle envergure chez Debian alors que Volkerding arrive à faire ça seul.
Tout "seul" ? Officiellement, ils sont au nombre de trois[1]... En outre: "Without Patrick, there would be no Slackware...". Un projet reposant sur un seul homme n'est pas un gage de qualité ni de pérennit é malgré l'âge avancé de Slackware: le jour où il jettera l'éponge, j'ai bien peur que ce soit également la fin de cette distribution...
Les Debian testing et unstable, elles, évoluent. Quand un problème de sécurité apparaît, le logiciel est généralement mis à jour rapidement et n'a pas besoin de correction per se.
Idem pour Slackware. S'il y a une patch pour un paquet existant et un nouveau paquet, il va évidemment choisir le nouveau paquet plutôt que de patcher l'ancien et d'installer le nouveau plus tard. Ça va de soi.
J'ai toujours cru entendre qu'il n'existait quasiment pas, à proprement parler, de notion de paquets chez Slackware...
Seulement, selon ce que j'ai entendu dire... entre les branches des arbres, cette fois, c'est que dans le testing Debian, le paquet ne change pas. Parce que, quand on change le paquet, ça peut impliquer d'autres changements, de librairies, de dépendances etc., qui chambarderaient trop le test.
Je ne vois pas en quoi ce serait tellement spécifique à la distribution Debian. Intégrer un nouveau paquet à l'arborescence peut amener d'autre s changements dûs aux nouvelles dépendances ou manquantes voire à cause de conflits. À tout cela s'ajoute, chez Debian, la gestion des 11 architectures actuellement supportées par le projet. Qui dit mieux ? Entre les 3 architectures supportées[2] par Slackware et les 11[2] de Debian, la comparaison s'arrêtera là.
Alors, je ne sais pas trop, j'ai peut-être manqué un HOWTO sur la lecture entre les lignes? Mais, sur la ligne, ce n'est pas du tout ce que tu dis qui est écrit, et pas tout à fait ce que j'ai entendu dire , non plus. Permets que je traduise:
Q.: Comment la sécurité de testing et unstable est-elle prise en char ge?
R.: En un mot elle ne l'est pas. (...) Les «secrétaires» de la sécurité tentent de régler les problèmes dans testing et unstable quand ils en ont fini avec stable.
Pas besoin de te donner tant de mal, il suffirait de régler ton navigateur correctement pour préférer la langue de Molière et on obti ent ceci[3]:
"Q. : Comment est gérée la sécurité pour testing et unstable ?"
"R. : La réponse courte est: elle ne l'est pas. Testing et unstable évoluent rapidement et l'équipe chargée de la sécurité n'a pas le s ressources nécessaires pour faire ce travail correctement. Si vous souhaitez un serveur sûr (et stable), vous être fortement encouragés à rester sur la distribution stable. Cependant, les membres de l'équipe en charge de la sécurité essayeront de corriger les problèmes dans testi ng et unstable une fois qu'ils auront été corrigés dans la version stabl e."
Pour des gens qui aiment tellement écrire, je pense qu'ils pourraient décrire la situation beaucoup plus précisément en n'étant pas plu s longs.
Chez Slackware, les choses sont plus simples. Il y a deux versions -- stable et current -- et les deux sont à jour question sécurité. (Et même des précédentes, comme chez Debian, d'ailleurs, si je ne me tr ompe.)
Quand on n'est que trois, qu'on ne gère que trois architectures, c'est fatalement plus facile de rédiger une documentation correcte.
Q: How is security handled for testing and unstable?
A: The short answer is: it's not. Testing and unstable are rapidly
moving targets and the security team does not have the resources
needed to properly support those. If you want to have a secure (and
stable) server you are strongly encouraged to stay with stable.
However, the security secretaries will try to fix problems in testing
and unstable after they are fixed in the stable release.
http://www.debian.org/security/faq#testing
Il faut lire entre les lignes.
La Debian stable est une distribution qui n'évolue plus. Quand un
problème de sécurité dans un logiciel de la debian stable appara ît, ce
logiciel n'est pas mis-à-jour vers une version plus récente sans le trou
de sécurité, mais est simplement corrigé.
Oui, ça s'appelle appliquer des patches si je ne me trompe. Toutes les
distros font ça, y compris Slackware. Mais il arrive parfois, quoi que
rarement, je pense, qu'il n'y ait pas de patch et qu'il faille changer
tout le paquet. La source la plus commune pour les patches semble être
mitre.org. Rien de nouveau là, même entre les lignes.
Je me demande seulement pourquoi ça semble une tâche d'une telle
envergure chez Debian alors que Volkerding arrive à faire ça seul.
Tout "seul" ? Officiellement, ils sont au nombre de trois[1]...
En outre: "Without Patrick, there would be no Slackware...". Un projet
reposant sur un seul homme n'est pas un gage de qualité ni de pérennit é
malgré l'âge avancé de Slackware: le jour où il jettera l'éponge, j'ai
bien peur que ce soit également la fin de cette distribution...
Les Debian testing et unstable, elles, évoluent. Quand un problème de
sécurité apparaît, le logiciel est généralement mis à jour rapidement et
n'a pas besoin de correction per se.
Idem pour Slackware. S'il y a une patch pour un paquet existant et un
nouveau paquet, il va évidemment choisir le nouveau paquet plutôt que
de patcher l'ancien et d'installer le nouveau plus tard. Ça va de soi.
J'ai toujours cru entendre qu'il n'existait quasiment pas, à proprement
parler, de notion de paquets chez Slackware...
Seulement, selon ce que j'ai entendu dire... entre les branches des
arbres, cette fois, c'est que dans le testing Debian, le paquet ne
change pas. Parce que, quand on change le paquet, ça peut impliquer
d'autres changements, de librairies, de dépendances etc., qui
chambarderaient trop le test.
Je ne vois pas en quoi ce serait tellement spécifique à la distribution
Debian. Intégrer un nouveau paquet à l'arborescence peut amener d'autre s
changements dûs aux nouvelles dépendances ou manquantes voire à cause de
conflits. À tout cela s'ajoute, chez Debian, la gestion des 11
architectures actuellement supportées par le projet. Qui dit mieux ?
Entre les 3 architectures supportées[2] par Slackware et les 11[2] de
Debian, la comparaison s'arrêtera là.
Alors, je ne sais pas trop, j'ai peut-être manqué un HOWTO sur la
lecture entre les lignes? Mais, sur la ligne, ce n'est pas du tout ce
que tu dis qui est écrit, et pas tout à fait ce que j'ai entendu dire ,
non plus. Permets que je traduise:
Q.: Comment la sécurité de testing et unstable est-elle prise en char ge?
R.: En un mot elle ne l'est pas. (...) Les «secrétaires» de la
sécurité tentent de régler les problèmes dans testing et unstable
quand ils en ont fini avec stable.
Pas besoin de te donner tant de mal, il suffirait de régler ton
navigateur correctement pour préférer la langue de Molière et on obti ent
ceci[3]:
"Q. : Comment est gérée la sécurité pour testing et unstable ?"
"R. : La réponse courte est: elle ne l'est pas. Testing et unstable
évoluent rapidement et l'équipe chargée de la sécurité n'a pas le s
ressources nécessaires pour faire ce travail correctement. Si vous
souhaitez un serveur sûr (et stable), vous être fortement encouragés à
rester sur la distribution stable. Cependant, les membres de l'équipe en
charge de la sécurité essayeront de corriger les problèmes dans testi ng
et unstable une fois qu'ils auront été corrigés dans la version stabl e."
Pour des gens qui aiment tellement écrire, je pense qu'ils pourraient
décrire la situation beaucoup plus précisément en n'étant pas plu s longs.
Chez Slackware, les choses sont plus simples. Il y a deux versions --
stable et current -- et les deux sont à jour question sécurité. (Et
même des précédentes, comme chez Debian, d'ailleurs, si je ne me tr ompe.)
Quand on n'est que trois, qu'on ne gère que trois architectures, c'est
fatalement plus facile de rédiger une documentation correcte.
Q: How is security handled for testing and unstable?
A: The short answer is: it's not. Testing and unstable are rapidly moving targets and the security team does not have the resources needed to properly support those. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable. However, the security secretaries will try to fix problems in testing and unstable after they are fixed in the stable release.
http://www.debian.org/security/faq#testing
Il faut lire entre les lignes. La Debian stable est une distribution qui n'évolue plus. Quand un problème de sécurité dans un logiciel de la debian stable appara ît, ce logiciel n'est pas mis-à-jour vers une version plus récente sans le trou de sécurité, mais est simplement corrigé.
Oui, ça s'appelle appliquer des patches si je ne me trompe. Toutes les distros font ça, y compris Slackware. Mais il arrive parfois, quoi que rarement, je pense, qu'il n'y ait pas de patch et qu'il faille changer tout le paquet. La source la plus commune pour les patches semble être mitre.org. Rien de nouveau là, même entre les lignes.
Je me demande seulement pourquoi ça semble une tâche d'une telle envergure chez Debian alors que Volkerding arrive à faire ça seul.
Tout "seul" ? Officiellement, ils sont au nombre de trois[1]... En outre: "Without Patrick, there would be no Slackware...". Un projet reposant sur un seul homme n'est pas un gage de qualité ni de pérennit é malgré l'âge avancé de Slackware: le jour où il jettera l'éponge, j'ai bien peur que ce soit également la fin de cette distribution...
Les Debian testing et unstable, elles, évoluent. Quand un problème de sécurité apparaît, le logiciel est généralement mis à jour rapidement et n'a pas besoin de correction per se.
Idem pour Slackware. S'il y a une patch pour un paquet existant et un nouveau paquet, il va évidemment choisir le nouveau paquet plutôt que de patcher l'ancien et d'installer le nouveau plus tard. Ça va de soi.
J'ai toujours cru entendre qu'il n'existait quasiment pas, à proprement parler, de notion de paquets chez Slackware...
Seulement, selon ce que j'ai entendu dire... entre les branches des arbres, cette fois, c'est que dans le testing Debian, le paquet ne change pas. Parce que, quand on change le paquet, ça peut impliquer d'autres changements, de librairies, de dépendances etc., qui chambarderaient trop le test.
Je ne vois pas en quoi ce serait tellement spécifique à la distribution Debian. Intégrer un nouveau paquet à l'arborescence peut amener d'autre s changements dûs aux nouvelles dépendances ou manquantes voire à cause de conflits. À tout cela s'ajoute, chez Debian, la gestion des 11 architectures actuellement supportées par le projet. Qui dit mieux ? Entre les 3 architectures supportées[2] par Slackware et les 11[2] de Debian, la comparaison s'arrêtera là.
Alors, je ne sais pas trop, j'ai peut-être manqué un HOWTO sur la lecture entre les lignes? Mais, sur la ligne, ce n'est pas du tout ce que tu dis qui est écrit, et pas tout à fait ce que j'ai entendu dire , non plus. Permets que je traduise:
Q.: Comment la sécurité de testing et unstable est-elle prise en char ge?
R.: En un mot elle ne l'est pas. (...) Les «secrétaires» de la sécurité tentent de régler les problèmes dans testing et unstable quand ils en ont fini avec stable.
Pas besoin de te donner tant de mal, il suffirait de régler ton navigateur correctement pour préférer la langue de Molière et on obti ent ceci[3]:
"Q. : Comment est gérée la sécurité pour testing et unstable ?"
"R. : La réponse courte est: elle ne l'est pas. Testing et unstable évoluent rapidement et l'équipe chargée de la sécurité n'a pas le s ressources nécessaires pour faire ce travail correctement. Si vous souhaitez un serveur sûr (et stable), vous être fortement encouragés à rester sur la distribution stable. Cependant, les membres de l'équipe en charge de la sécurité essayeront de corriger les problèmes dans testi ng et unstable une fois qu'ils auront été corrigés dans la version stabl e."
Pour des gens qui aiment tellement écrire, je pense qu'ils pourraient décrire la situation beaucoup plus précisément en n'étant pas plu s longs.
Chez Slackware, les choses sont plus simples. Il y a deux versions -- stable et current -- et les deux sont à jour question sécurité. (Et même des précédentes, comme chez Debian, d'ailleurs, si je ne me tr ompe.)
Quand on n'est que trois, qu'on ne gère que trois architectures, c'est fatalement plus facile de rédiger une documentation correcte.
Je ne veux pas spécialement garder la Woody, je ne veux simplement pa s passer une semaine à tout réinstaller pour mettre Unstable.
Eh bien choisis testing. Et tu perdras moins de temps qu'à râler ic i.
Testing ne reçoit pas de patches de sécurité, seulement stable et unstable.
Donc, testing aussi... puisqu'unstable est mise à jour presqu'aussitôt la rustine appliquée sur les paquets de stable. Ensuite, testing recevra le paquet envoyé pour unstable dans peu de temps, deux jours environ. En effet, la durée minimale de la quarantaine avec une si haute priorit é est de deux jours.
Note que c'est _précisément_ à ceux qui ne veulent pas passer de temps à mettre à jour que sert stable.
Oui... et ça leur sert longtemps! La dernière version de Woody date déjà de 8 mois et Dieu sait quand Sarge va sortir!
La phase de gel de la testing a débuté voici deux jours environ et doit durer un mois. La sortie ne saurait tarder et sera pour cette année. Debian n'a jamais cherché à gagner une quelconque course à la version , comme le faisait Mandrake avec RedHat. La nouvelle distribution Debian stable sortira une fois qu'elle sera prête.
Là, Slackware vient de passer à 10. Mais admettons que tu ne veuilles pas mettre à jour et que tu veuilles installer la dernière version de Firefox. Tu vas chez LinuxPackages et la dernière version est là.
Admettons que tu veuilles tenir ta version 10 à jour, tu vas ici: http://www.linuxpackages.net/search_view.php?ver.0&by=name&what_ca t=&subcat=&name=
installpkg, et l'affaire est vite dite, 10 reçoit les softs les plus récents.
Est-ce là une source officielle ou approuvée par Slackware ou est-ce équivalent aux paquets rétro-portés que l'on trouve ci-et-là pour l a woody ? De tels paquets ne sauraient être conseillés et être utilis és sans parcimonie...
Évidemment, PV n'a pas trop le temps de s'occuper de ça, lui. Ce que swaret te permet de récupérer pour la version stable, c'est surtout des patches de sécurité. Mais, c'est pas tellement sorcier de rouler current. (À remarquer que ça ne s'appelle pas testing ou unstable, mais /current/!)
Au début, current est identique à stable. On ajoute un petit soft, peut-être une librairie, un nouveau noyau, un nouvel ALSA, etc. Et ça évolue comme ça jusqu'à la prochaine distro. Si ç'a marché pour PV, ça devrait marcher pour toi. Sinon, tu écris.
Chez Debian, c'est le rôle de l'unstable. Testing sert uniquement de distribution intermédiaire: elle permet de tester (comme son nom l'indique) la future stable. La gestion des anomalies est telle qu'elle permet d'éviter d'y intégrer celles qui sont trop critiques.
Certains prétendent -- on ne /les/ nommera pas :) -- qu'il suffit de faire pointer swaret vers current pour être à la fine pointe du progrès. Certains ont peut-être été chançeux ou ils oublient qu elques replâtrages. Il vaut sans doute mieux lire le changelog. Je ne me rappelle pas qui a souligné ça ici, mais il y a effectivement parfois des recommandations précises et précieuses pour installer certains paquets auxquelles swaret ne saurait se plier.
Tout comme il est conseillé à ceux qui passent à l'unstable de savoir ce qu'ils font et de consulter non seulement les Changelog mais aussi le système de gestion d'anomalies (ou BTS, Bug Tracking System), que ce soit en consultant le site ou en utilisant des outils appropriés, comme l'incontournable apt-listbugs.
[...]
Debian a donné naissance à plusieurs distributions commerciales, ce que je n'apprécie pas particulièrement, mais aussi à Knoppix, que j'estime beaucoup. Et, tout ce qui a démarré à partir de Knoppix dépasse l'entendement. Ç'a été un coup de fouet pour Linux.
Leurs succès est tout relatif et Knoppix est l'un des rares dérivés à tirer son épingle du jeu.
Donc, Debian continue d'être un moteur dans le monde Linux mais, malgré ses... euh, 10 000 développeurs, c'est toujours quelqu'un d'autre qui fait que ça fonctionne, que le public l'adopte. Or, ce n'était clairement pas ça, le projet originel. Le modèle de développement ne fonctionne pas.
Pourrais-tu développer ?
Même Ian Murdock, celui qui a lancé Debian, semble opiner dans ce sens. Il y a deux ou trois ans, il lançait Progeny pour offrir une distro utilisable. Mais la distribution, dans un bel emballage carton avec un manuel, plutôt que dans un simple coffret CD avec un petit manuel de 50 page intégré, se vendait deux fois le prix de Mandrake e t ça ne s'est jamais vendu.
Que se passera-t-il lorsque PV n'aura plus envie de consacrer de temps ni d'énergie à son bébé ? Ian Murdock a simplement souhaité pours uivre sa route et a pris soin de confier le projet[1] en de bonnes mains, notamment celles de Bruce Perens.
Si on compare Debian à Slackware, le développement dans un immense groupe qui donne la frousse à quiconque possède encore un semblant de raison et le développement vraiment ouvert à la mode Slackware, le fossé est évident.
Pourquoi n'y a-t-il toujours que 3 personnes officiellement ?
C'est d'ailleurs ce type de développement que Klaus Knopper propose par ses refus de collaborer directement à Debian pour ne pas être pri s par toutes les chicanes de ménage, et pourtant de collaborer indirectement de façon exponentielle.
Tu veux parler des apports qu'aurait pu apporter son installateur ? D'une part, le projet Debian n'a jamais interdit la co-existence de projets tiers dérivés. D'autre part, le projet Debian a choisi de ne pa s intégré ni celui de Knoppix ni celui de Progeny pour des raisons essentiellement liées aux besoins des 11 architectures... En effet, la première contrainte était qu'il permette d'installer Debian sur toutes les architectures supportées, donc, qu'il soit portable. En outre, ils ont préféré disposer d'un outil modulable plutôt qu'u ne belle interface.
Est-ce que Debian saura se ressaisir? Je ne sais pas. L'entropie semble s'être installée en maître dans cette organisation.
Debian poursuit son bonhomme de chemin: que sa voie puisse paraître éloignée des routes poursuivies par Slackware, Gentoo ou les autres distributions de Linux n'est qu'un gage de diversité dont nous avons tous besoin.
Je ne veux pas spécialement garder la Woody, je ne veux simplement pa s
passer une semaine à tout réinstaller pour mettre Unstable.
Eh bien choisis testing. Et tu perdras moins de temps qu'à râler ic i.
Testing ne reçoit pas de patches de sécurité, seulement stable et
unstable.
Donc, testing aussi... puisqu'unstable est mise à jour presqu'aussitôt
la rustine appliquée sur les paquets de stable. Ensuite, testing recevra
le paquet envoyé pour unstable dans peu de temps, deux jours environ.
En effet, la durée minimale de la quarantaine avec une si haute priorit é
est de deux jours.
Note que c'est _précisément_ à ceux qui ne veulent pas passer de temps à
mettre à jour que sert stable.
Oui... et ça leur sert longtemps! La dernière version de Woody date
déjà de 8 mois et Dieu sait quand Sarge va sortir!
La phase de gel de la testing a débuté voici deux jours environ et doit
durer un mois. La sortie ne saurait tarder et sera pour cette année.
Debian n'a jamais cherché à gagner une quelconque course à la version ,
comme le faisait Mandrake avec RedHat. La nouvelle distribution Debian
stable sortira une fois qu'elle sera prête.
Là, Slackware vient de passer à 10. Mais admettons que tu ne veuilles
pas mettre à jour et que tu veuilles installer la dernière version de
Firefox. Tu vas chez LinuxPackages et la dernière version est là.
Admettons que tu veuilles tenir ta version 10 à jour, tu vas ici:
http://www.linuxpackages.net/search_view.php?ver=10.0&by=name&what_ca t=&subcat=&name=
installpkg, et l'affaire est vite dite, 10 reçoit les softs les plus
récents.
Est-ce là une source officielle ou approuvée par Slackware ou est-ce
équivalent aux paquets rétro-portés que l'on trouve ci-et-là pour l a
woody ? De tels paquets ne sauraient être conseillés et être utilis és
sans parcimonie...
Évidemment, PV n'a pas trop le temps de s'occuper de ça, lui. Ce que
swaret te permet de récupérer pour la version stable, c'est surtout
des patches de sécurité. Mais, c'est pas tellement sorcier de rouler
current. (À remarquer que ça ne s'appelle pas testing ou unstable,
mais /current/!)
Au début, current est identique à stable. On ajoute un petit soft,
peut-être une librairie, un nouveau noyau, un nouvel ALSA, etc. Et ça
évolue comme ça jusqu'à la prochaine distro. Si ç'a marché pour PV, ça
devrait marcher pour toi. Sinon, tu écris.
Chez Debian, c'est le rôle de l'unstable. Testing sert uniquement de
distribution intermédiaire: elle permet de tester (comme son nom
l'indique) la future stable. La gestion des anomalies est telle qu'elle
permet d'éviter d'y intégrer celles qui sont trop critiques.
Certains prétendent -- on ne /les/ nommera pas :) -- qu'il suffit de
faire pointer swaret vers current pour être à la fine pointe du
progrès. Certains ont peut-être été chançeux ou ils oublient qu elques
replâtrages. Il vaut sans doute mieux lire le changelog. Je ne me
rappelle pas qui a souligné ça ici, mais il y a effectivement parfois
des recommandations précises et précieuses pour installer certains
paquets auxquelles swaret ne saurait se plier.
Tout comme il est conseillé à ceux qui passent à l'unstable de savoir ce
qu'ils font et de consulter non seulement les Changelog mais aussi le
système de gestion d'anomalies (ou BTS, Bug Tracking System), que ce
soit en consultant le site ou en utilisant des outils appropriés, comme
l'incontournable apt-listbugs.
[...]
Debian a donné naissance à plusieurs distributions commerciales, ce
que je n'apprécie pas particulièrement, mais aussi à Knoppix, que
j'estime beaucoup. Et, tout ce qui a démarré à partir de Knoppix
dépasse l'entendement. Ç'a été un coup de fouet pour Linux.
Leurs succès est tout relatif et Knoppix est l'un des rares dérivés à
tirer son épingle du jeu.
Donc, Debian continue d'être un moteur dans le monde Linux mais,
malgré ses... euh, 10 000 développeurs, c'est toujours quelqu'un
d'autre qui fait que ça fonctionne, que le public l'adopte. Or, ce
n'était clairement pas ça, le projet originel. Le modèle de
développement ne fonctionne pas.
Pourrais-tu développer ?
Même Ian Murdock, celui qui a lancé Debian, semble opiner dans ce
sens. Il y a deux ou trois ans, il lançait Progeny pour offrir une
distro utilisable. Mais la distribution, dans un bel emballage carton
avec un manuel, plutôt que dans un simple coffret CD avec un petit
manuel de 50 page intégré, se vendait deux fois le prix de Mandrake e t
ça ne s'est jamais vendu.
Que se passera-t-il lorsque PV n'aura plus envie de consacrer de temps
ni d'énergie à son bébé ? Ian Murdock a simplement souhaité pours uivre
sa route et a pris soin de confier le projet[1] en de bonnes mains,
notamment celles de Bruce Perens.
Si on compare Debian à Slackware, le développement dans un immense
groupe qui donne la frousse à quiconque possède encore un semblant de
raison et le développement vraiment ouvert à la mode Slackware, le
fossé est évident.
Pourquoi n'y a-t-il toujours que 3 personnes officiellement ?
C'est d'ailleurs ce type de développement que Klaus Knopper propose
par ses refus de collaborer directement à Debian pour ne pas être pri s
par toutes les chicanes de ménage, et pourtant de collaborer
indirectement de façon exponentielle.
Tu veux parler des apports qu'aurait pu apporter son installateur ?
D'une part, le projet Debian n'a jamais interdit la co-existence de
projets tiers dérivés. D'autre part, le projet Debian a choisi de ne pa s
intégré ni celui de Knoppix ni celui de Progeny pour des raisons
essentiellement liées aux besoins des 11 architectures... En effet,
la première contrainte était qu'il permette d'installer Debian sur
toutes les architectures supportées, donc, qu'il soit portable.
En outre, ils ont préféré disposer d'un outil modulable plutôt qu'u ne
belle interface.
Est-ce que Debian saura se ressaisir? Je ne sais pas. L'entropie
semble s'être installée en maître dans cette organisation.
Debian poursuit son bonhomme de chemin: que sa voie puisse paraître
éloignée des routes poursuivies par Slackware, Gentoo ou les autres
distributions de Linux n'est qu'un gage de diversité dont nous avons
tous besoin.
Je ne veux pas spécialement garder la Woody, je ne veux simplement pa s passer une semaine à tout réinstaller pour mettre Unstable.
Eh bien choisis testing. Et tu perdras moins de temps qu'à râler ic i.
Testing ne reçoit pas de patches de sécurité, seulement stable et unstable.
Donc, testing aussi... puisqu'unstable est mise à jour presqu'aussitôt la rustine appliquée sur les paquets de stable. Ensuite, testing recevra le paquet envoyé pour unstable dans peu de temps, deux jours environ. En effet, la durée minimale de la quarantaine avec une si haute priorit é est de deux jours.
Note que c'est _précisément_ à ceux qui ne veulent pas passer de temps à mettre à jour que sert stable.
Oui... et ça leur sert longtemps! La dernière version de Woody date déjà de 8 mois et Dieu sait quand Sarge va sortir!
La phase de gel de la testing a débuté voici deux jours environ et doit durer un mois. La sortie ne saurait tarder et sera pour cette année. Debian n'a jamais cherché à gagner une quelconque course à la version , comme le faisait Mandrake avec RedHat. La nouvelle distribution Debian stable sortira une fois qu'elle sera prête.
Là, Slackware vient de passer à 10. Mais admettons que tu ne veuilles pas mettre à jour et que tu veuilles installer la dernière version de Firefox. Tu vas chez LinuxPackages et la dernière version est là.
Admettons que tu veuilles tenir ta version 10 à jour, tu vas ici: http://www.linuxpackages.net/search_view.php?ver.0&by=name&what_ca t=&subcat=&name=
installpkg, et l'affaire est vite dite, 10 reçoit les softs les plus récents.
Est-ce là une source officielle ou approuvée par Slackware ou est-ce équivalent aux paquets rétro-portés que l'on trouve ci-et-là pour l a woody ? De tels paquets ne sauraient être conseillés et être utilis és sans parcimonie...
Évidemment, PV n'a pas trop le temps de s'occuper de ça, lui. Ce que swaret te permet de récupérer pour la version stable, c'est surtout des patches de sécurité. Mais, c'est pas tellement sorcier de rouler current. (À remarquer que ça ne s'appelle pas testing ou unstable, mais /current/!)
Au début, current est identique à stable. On ajoute un petit soft, peut-être une librairie, un nouveau noyau, un nouvel ALSA, etc. Et ça évolue comme ça jusqu'à la prochaine distro. Si ç'a marché pour PV, ça devrait marcher pour toi. Sinon, tu écris.
Chez Debian, c'est le rôle de l'unstable. Testing sert uniquement de distribution intermédiaire: elle permet de tester (comme son nom l'indique) la future stable. La gestion des anomalies est telle qu'elle permet d'éviter d'y intégrer celles qui sont trop critiques.
Certains prétendent -- on ne /les/ nommera pas :) -- qu'il suffit de faire pointer swaret vers current pour être à la fine pointe du progrès. Certains ont peut-être été chançeux ou ils oublient qu elques replâtrages. Il vaut sans doute mieux lire le changelog. Je ne me rappelle pas qui a souligné ça ici, mais il y a effectivement parfois des recommandations précises et précieuses pour installer certains paquets auxquelles swaret ne saurait se plier.
Tout comme il est conseillé à ceux qui passent à l'unstable de savoir ce qu'ils font et de consulter non seulement les Changelog mais aussi le système de gestion d'anomalies (ou BTS, Bug Tracking System), que ce soit en consultant le site ou en utilisant des outils appropriés, comme l'incontournable apt-listbugs.
[...]
Debian a donné naissance à plusieurs distributions commerciales, ce que je n'apprécie pas particulièrement, mais aussi à Knoppix, que j'estime beaucoup. Et, tout ce qui a démarré à partir de Knoppix dépasse l'entendement. Ç'a été un coup de fouet pour Linux.
Leurs succès est tout relatif et Knoppix est l'un des rares dérivés à tirer son épingle du jeu.
Donc, Debian continue d'être un moteur dans le monde Linux mais, malgré ses... euh, 10 000 développeurs, c'est toujours quelqu'un d'autre qui fait que ça fonctionne, que le public l'adopte. Or, ce n'était clairement pas ça, le projet originel. Le modèle de développement ne fonctionne pas.
Pourrais-tu développer ?
Même Ian Murdock, celui qui a lancé Debian, semble opiner dans ce sens. Il y a deux ou trois ans, il lançait Progeny pour offrir une distro utilisable. Mais la distribution, dans un bel emballage carton avec un manuel, plutôt que dans un simple coffret CD avec un petit manuel de 50 page intégré, se vendait deux fois le prix de Mandrake e t ça ne s'est jamais vendu.
Que se passera-t-il lorsque PV n'aura plus envie de consacrer de temps ni d'énergie à son bébé ? Ian Murdock a simplement souhaité pours uivre sa route et a pris soin de confier le projet[1] en de bonnes mains, notamment celles de Bruce Perens.
Si on compare Debian à Slackware, le développement dans un immense groupe qui donne la frousse à quiconque possède encore un semblant de raison et le développement vraiment ouvert à la mode Slackware, le fossé est évident.
Pourquoi n'y a-t-il toujours que 3 personnes officiellement ?
C'est d'ailleurs ce type de développement que Klaus Knopper propose par ses refus de collaborer directement à Debian pour ne pas être pri s par toutes les chicanes de ménage, et pourtant de collaborer indirectement de façon exponentielle.
Tu veux parler des apports qu'aurait pu apporter son installateur ? D'une part, le projet Debian n'a jamais interdit la co-existence de projets tiers dérivés. D'autre part, le projet Debian a choisi de ne pa s intégré ni celui de Knoppix ni celui de Progeny pour des raisons essentiellement liées aux besoins des 11 architectures... En effet, la première contrainte était qu'il permette d'installer Debian sur toutes les architectures supportées, donc, qu'il soit portable. En outre, ils ont préféré disposer d'un outil modulable plutôt qu'u ne belle interface.
Est-ce que Debian saura se ressaisir? Je ne sais pas. L'entropie semble s'être installée en maître dans cette organisation.
Debian poursuit son bonhomme de chemin: que sa voie puisse paraître éloignée des routes poursuivies par Slackware, Gentoo ou les autres distributions de Linux n'est qu'un gage de diversité dont nous avons tous besoin.
~% less /usr/share/doc/apt/examples/configure-index.gz
et on a tout ce dont on a besoin pour configurer apt
Oui, sauf qu'on a vu ce que ça donne dans l'exemple donné par Surcouf... Je suis désolé. La doc de Debian sur dpkg, dselect, apt-get, synaptic, aptitude, longitude, latitude, whatnext, c'est vraiment un foutoir incroyable. Comme toute la doc de Debian, d'ailleurs. Quand on a 36 heures par jour à passer là-dessus, pas de problème. Autremetn, on préfère en arriver aux faits plus rapidemen t.
P.s.: Prière de ne pas répondre à ce message par un tas de bêtise s. Répondre à mon message précédent. Prière de me dire, ce que fon t dpkg, dselect, apt-get, synaptic, aptitude en quelques mots, ce qu'il faut utiliser et comment, pour faire quoi. Si vous m'écrivez 500 pages pour faire les quelques lignes de swaret, c'est trop long.
C'est pourtant très simple: apt est le seul véritable outil à utilise r. Tous les autres, à part dpkg, ne sont que sur-couches généralement graphiques ou apportant un confort non négligeable pour l'utilisateur. Et pour en revenir à dpkg: il s'agit de l'outil gérant directement les paquets debian, leurs installations, etc.. Apt est en fait lui-même une sur-couche de dpkg, permettant de gérer les mises à jour des paquets. En bref et en gros: swaret = apt et installpkg = dpkg.
-- Raphaël 'SurcouF' Bordet
# | http://www.debianfr.net
On dim, 2004-08-01 at 18:38 -0400, GP wrote:
ZeFredz wrote:
~% less /usr/share/doc/apt/examples/configure-index.gz
et on a tout ce dont on a besoin pour configurer apt
Oui, sauf qu'on a vu ce que ça donne dans l'exemple donné par
Surcouf... Je suis désolé. La doc de Debian sur dpkg, dselect,
apt-get, synaptic, aptitude, longitude, latitude, whatnext, c'est
vraiment un foutoir incroyable. Comme toute la doc de Debian,
d'ailleurs. Quand on a 36 heures par jour à passer là-dessus, pas de
problème. Autremetn, on préfère en arriver aux faits plus rapidemen t.
P.s.: Prière de ne pas répondre à ce message par un tas de bêtise s.
Répondre à mon message précédent. Prière de me dire, ce que fon t dpkg,
dselect, apt-get, synaptic, aptitude en quelques mots, ce qu'il faut
utiliser et comment, pour faire quoi. Si vous m'écrivez 500 pages pour
faire les quelques lignes de swaret, c'est trop long.
C'est pourtant très simple: apt est le seul véritable outil à utilise r.
Tous les autres, à part dpkg, ne sont que sur-couches généralement
graphiques ou apportant un confort non négligeable pour l'utilisateur.
Et pour en revenir à dpkg: il s'agit de l'outil gérant directement les
paquets debian, leurs installations, etc.. Apt est en fait lui-même une
sur-couche de dpkg, permettant de gérer les mises à jour des paquets.
En bref et en gros: swaret = apt et installpkg = dpkg.
~% less /usr/share/doc/apt/examples/configure-index.gz
et on a tout ce dont on a besoin pour configurer apt
Oui, sauf qu'on a vu ce que ça donne dans l'exemple donné par Surcouf... Je suis désolé. La doc de Debian sur dpkg, dselect, apt-get, synaptic, aptitude, longitude, latitude, whatnext, c'est vraiment un foutoir incroyable. Comme toute la doc de Debian, d'ailleurs. Quand on a 36 heures par jour à passer là-dessus, pas de problème. Autremetn, on préfère en arriver aux faits plus rapidemen t.
P.s.: Prière de ne pas répondre à ce message par un tas de bêtise s. Répondre à mon message précédent. Prière de me dire, ce que fon t dpkg, dselect, apt-get, synaptic, aptitude en quelques mots, ce qu'il faut utiliser et comment, pour faire quoi. Si vous m'écrivez 500 pages pour faire les quelques lignes de swaret, c'est trop long.
C'est pourtant très simple: apt est le seul véritable outil à utilise r. Tous les autres, à part dpkg, ne sont que sur-couches généralement graphiques ou apportant un confort non négligeable pour l'utilisateur. Et pour en revenir à dpkg: il s'agit de l'outil gérant directement les paquets debian, leurs installations, etc.. Apt est en fait lui-même une sur-couche de dpkg, permettant de gérer les mises à jour des paquets. En bref et en gros: swaret = apt et installpkg = dpkg.
-- Raphaël 'SurcouF' Bordet
# | http://www.debianfr.net
Laurent Fousse
Dans fr.comp.os.linux.debats, Richard Delorme nous disait:
Laurent Fousse wrote:
Dans fr.comp.os.linux.debats, luc2 nous disait:
ainsi, tu n'arrives toujours pas a differentier la convivialite de la securite.
On vous écoute. C'est quoi, la "convivialité" ?
D'après la vénérable académie française :
(1)*CONVIVIALITÉ n. f. XIXe siècle. Emprunté de l'anglais conviviality. 1. Vieilli. Goût des réunions joyeuses, des festins. 2. Caractère d'une société qui favorise les échanges, les relations franches et amicales entre les personnes, entre les groupes.
Maintenant, je ne sais pas si luc2 parlait de 1. ou de 2.
Il doit plutôt utiliser l'autre définition:
3. Jargon marketoïde. Attribut fumeux qu'un produit que l'on vend possède et dont un produit que l'on dénigre est complètement dépourvu. Voir aussi "multimedia".
Dans fr.comp.os.linux.debats, Richard Delorme nous disait:
Laurent Fousse wrote:
Dans fr.comp.os.linux.debats, luc2 nous disait:
ainsi, tu n'arrives toujours pas a differentier la convivialite de la
securite.
On vous écoute. C'est quoi, la "convivialité" ?
D'après la vénérable académie française :
(1)*CONVIVIALITÉ n. f. XIXe siècle. Emprunté de l'anglais conviviality.
1. Vieilli. Goût des réunions joyeuses, des festins. 2. Caractère d'une
société qui favorise les échanges, les relations franches et amicales
entre les personnes, entre les groupes.
Maintenant, je ne sais pas si luc2 parlait de 1. ou de 2.
Il doit plutôt utiliser l'autre définition:
3. Jargon marketoïde. Attribut fumeux qu'un produit que l'on vend
possède et dont un produit que l'on dénigre est complètement dépourvu.
Voir aussi "multimedia".
Dans fr.comp.os.linux.debats, Richard Delorme nous disait:
Laurent Fousse wrote:
Dans fr.comp.os.linux.debats, luc2 nous disait:
ainsi, tu n'arrives toujours pas a differentier la convivialite de la securite.
On vous écoute. C'est quoi, la "convivialité" ?
D'après la vénérable académie française :
(1)*CONVIVIALITÉ n. f. XIXe siècle. Emprunté de l'anglais conviviality. 1. Vieilli. Goût des réunions joyeuses, des festins. 2. Caractère d'une société qui favorise les échanges, les relations franches et amicales entre les personnes, entre les groupes.
Maintenant, je ne sais pas si luc2 parlait de 1. ou de 2.
Il doit plutôt utiliser l'autre définition:
3. Jargon marketoïde. Attribut fumeux qu'un produit que l'on vend possède et dont un produit que l'on dénigre est complètement dépourvu. Voir aussi "multimedia".
talon
Laurent Fousse wrote:
Il doit plutôt utiliser l'autre définition:
3. Jargon marketoïde. Attribut fumeux qu'un produit que l'on vend possède et dont un produit que l'on dénigre est complètement dépourvu. Voir aussi "multimedia".
La première étape pour produire quelque chose de convivial est de bien se convaincre que la définition ci-dessus est absolument fausse. De façon analogue certains prétendent que la beauté n'existe pas, que l'élégance d'une démonstration n'existe pas, etc. Pourtant chacun reconnaît immédiatement ces qualités dés qu'il les voit.
3. Jargon marketoïde. Attribut fumeux qu'un produit que l'on vend
possède et dont un produit que l'on dénigre est complètement dépourvu.
Voir aussi "multimedia".
La première étape pour produire quelque chose de convivial est de bien se
convaincre que la définition ci-dessus est absolument fausse. De façon
analogue certains prétendent que la beauté n'existe pas, que l'élégance d'une
démonstration n'existe pas, etc. Pourtant chacun reconnaît immédiatement
ces qualités dés qu'il les voit.
3. Jargon marketoïde. Attribut fumeux qu'un produit que l'on vend possède et dont un produit que l'on dénigre est complètement dépourvu. Voir aussi "multimedia".
La première étape pour produire quelque chose de convivial est de bien se convaincre que la définition ci-dessus est absolument fausse. De façon analogue certains prétendent que la beauté n'existe pas, que l'élégance d'une démonstration n'existe pas, etc. Pourtant chacun reconnaît immédiatement ces qualités dés qu'il les voit.
-- Michel Talon
Benjamin FRANCOIS
luc2 s'est exprimé en ces termes:
dans ce post, je vais vous dire pourquoi linux est mauvais, bien que tout le monde le sache deja.
Eh bé. En pleine forme, lucounet chéri. Tu as eu des vacances ?
-- <Zen> I wonder what flavor of Windows they're going to run on Xbox.. <Yohoma> hopefully AOL 7.0 is out by then, i wanna play gamez online
luc2 s'est exprimé en ces termes:
dans ce post, je vais vous dire pourquoi linux est mauvais, bien que
tout le monde le sache deja.
Eh bé. En pleine forme, lucounet chéri. Tu as eu des vacances ?
--
<Zen> I wonder what flavor of Windows they're going to run on Xbox..
<Yohoma> hopefully AOL 7.0 is out by then, i wanna play gamez online
