Un débat intéressant et sans doute récurant que l'on voit apparaître
régulièrement sur les forums, et relatif quant au choix de la
distribution...
Linux pour quoi faire ? Tout d'abord clarifions la chose pour dire que
"linux" est le nom du kernel et non du system d'exploitation lui-même...
Petite précision pour les débutants linux. Il faut alors parler de
distribution GNU Linux...
Donc qu'attendez-vous d'un OS libre (par opposition à Windows) ?
Nous savons que Linux est une bonne solution s'il on veut faire un réseau ;
aussi peut-il est aussi une solution en terme de bureautique pure (Office) ?
La partie jeu reste une ombre pour ma part... peut-il concurrencer les
jeux sous Windows ?
Le choix de la distrib reste aussi, difficile dans la perspective des
mises à jour ? Je pense que c'est la que réside la difficulté. RPMS,
PKG, DEB, Yum, ou encore version type gentoo... , installation depuis les
sources, etc. Facilité, Rapidité ou encore prise de caféine, tels sont
les choix qui sont offerts. Un point important réside aussi dans la
sécurité...
Ayant tester une multitude de distrib (redhat, fedora, gentoo, mdk7.0 !,
archlinux, freebsd, solaris, etc), je ne sais sur quoi me baser afin de
trouver un bon compromis. L'on pourra consulter un site tel que
http://www.distrowatch.com afin d'y trouver un bref exposer des distribs
linux, avec les différents liens qui s'y rattachent.
Vos commentaires, et autres suggestions pour extrapoler ces propos seront
les bienvenus afin de clarifier certaines idées...
Michel Talon, dans le message <c50vau$1ech$, a écrit :
Tu sais ce que je pense du découpage qui est la plaie des distributions Linux, et particulièrement de Debian. C'est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer.
Moi je trouve ça utile. Donc je t'en prie, reste sous FreeBSD puisque tu préfères FreeBSD (que pour ma part je considère comme une sombre merde du point de vue technique)
Ca c'est la meilleure, et c'est bien la première fois que j'entends énoncer par quelqu'un (*) l'idée que Linux aurait des avantages techniques par rapport à FreeBSD. Tu as fumé quoi ce jour ci?
et n'essaie pas d'imposer tes vues à ceux qui n'en ont pas besoin.
Je n'essaie pas d'imposer mes vues, j'explique les raisons pour lesquelles, à mon avis, le découpage est stupide.
quand la taille des disques double tous les ans, c'est déjà ridicule.
Ça, c'est un des arguments les plus cons qu'on puisse sortir !
Non, c'est un argument absolument radical. Pour toute personne sensée la taille actuelle des disques peut dores et déjà être considérée comme infinie, et tous les ans ça sera encore plus vrai. Il en résulte qu'économiser de la place est une connerie.
(*) mis à part Linus T. bien sûr.
--
Michel TALON
Nicolas George <george@clipper.ens.fr> wrote:
Michel Talon, dans le message <c50vau$1ech$1@asmodee.lpthe.jussieu.fr>,
a écrit :
Tu sais ce que je pense du
découpage qui est la plaie des distributions Linux, et particulièrement
de Debian. C'est la plus grande stupidité que des esprits infiniment
médiocres aient pu imaginer.
Moi je trouve ça utile. Donc je t'en prie, reste sous FreeBSD puisque tu
préfères FreeBSD (que pour ma part je considère comme une sombre merde
du point de vue technique)
Ca c'est la meilleure, et c'est bien la première fois que j'entends énoncer
par quelqu'un (*) l'idée que Linux aurait des avantages techniques par
rapport à FreeBSD. Tu as fumé quoi ce jour ci?
et n'essaie pas d'imposer tes vues à ceux qui
n'en ont pas besoin.
Je n'essaie pas d'imposer mes vues, j'explique les raisons pour
lesquelles, à mon avis, le découpage est stupide.
quand la taille des disques double tous les ans, c'est déjà ridicule.
Ça, c'est un des arguments les plus cons qu'on puisse sortir !
Non, c'est un argument absolument radical. Pour toute personne sensée la
taille actuelle des disques peut dores et déjà être considérée comme
infinie, et tous les ans ça sera encore plus vrai. Il en résulte
qu'économiser de la place est une connerie.
Michel Talon, dans le message <c50vau$1ech$, a écrit :
Tu sais ce que je pense du découpage qui est la plaie des distributions Linux, et particulièrement de Debian. C'est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer.
Moi je trouve ça utile. Donc je t'en prie, reste sous FreeBSD puisque tu préfères FreeBSD (que pour ma part je considère comme une sombre merde du point de vue technique)
Ca c'est la meilleure, et c'est bien la première fois que j'entends énoncer par quelqu'un (*) l'idée que Linux aurait des avantages techniques par rapport à FreeBSD. Tu as fumé quoi ce jour ci?
et n'essaie pas d'imposer tes vues à ceux qui n'en ont pas besoin.
Je n'essaie pas d'imposer mes vues, j'explique les raisons pour lesquelles, à mon avis, le découpage est stupide.
quand la taille des disques double tous les ans, c'est déjà ridicule.
Ça, c'est un des arguments les plus cons qu'on puisse sortir !
Non, c'est un argument absolument radical. Pour toute personne sensée la taille actuelle des disques peut dores et déjà être considérée comme infinie, et tous les ans ça sera encore plus vrai. Il en résulte qu'économiser de la place est une connerie.
(*) mis à part Linus T. bien sûr.
--
Michel TALON
Jerome Lambert
Le Tue, 06 Apr 2004 11:03:00 +0200, Emmanuel Florac a écrit :
-rpm sucks badly. Avec yum ou apt-rpm c'est utilisable, mais les paquets sont généralement inadaptés et les cas de conflits de dépendances insolubles trop fréquents. Il convient d'éviter les distribs à base de rpm...
-Pour une station de travail, slackware rulez. A mon sens Slack a un grand avantage, inciter à installer depuis les sources (grace à checkinstall c'est une formalité) et utiliser des sources "princeps" pour tous les gros sous-ensembles (kernel, gnome, kde, etc). En plus avec swaret on peut quand même mettre à jour vite et facilement, même si ça reste plus sportif que sur la Debian.
J'ai l'impression que les systèmes de gestion de paquetages, qu'ils soient rpm ou deb, posent plus de problemes qu'ils n'en resolvent...
L'avenir est peut-etre au système utilisé par Firefox: les binaires et les bibliothèques nécessaires sont dans le même sous-repertoire. Yaka décompresser l'archive, la déplacer dans /usr/share et faire un lien dans /usr/bin et c'est parti.
Pour le désinstaller, on vire le répertoire et le lien, et c'est fini.
Qui a dit compliqué?
Jerome.
Le Tue, 06 Apr 2004 11:03:00 +0200, Emmanuel Florac a écrit :
-rpm sucks badly. Avec yum ou apt-rpm c'est utilisable, mais les paquets
sont généralement inadaptés et les cas de conflits de
dépendances insolubles trop fréquents. Il convient d'éviter les
distribs à base de rpm...
-Pour une station de travail, slackware rulez. A mon sens Slack a un grand
avantage, inciter à installer depuis les sources (grace à checkinstall
c'est une formalité) et utiliser des sources "princeps" pour tous les
gros sous-ensembles (kernel, gnome, kde, etc). En plus avec swaret on peut
quand même mettre à jour vite et facilement, même si ça reste plus
sportif que sur la Debian.
J'ai l'impression que les systèmes de gestion de paquetages, qu'ils
soient rpm ou deb, posent plus de problemes qu'ils n'en resolvent...
L'avenir est peut-etre au système utilisé par Firefox: les binaires et
les bibliothèques nécessaires sont dans le même sous-repertoire.
Yaka décompresser l'archive, la déplacer dans /usr/share et faire un
lien dans /usr/bin et c'est parti.
Pour le désinstaller, on vire le répertoire et le lien, et c'est fini.
Le Tue, 06 Apr 2004 11:03:00 +0200, Emmanuel Florac a écrit :
-rpm sucks badly. Avec yum ou apt-rpm c'est utilisable, mais les paquets sont généralement inadaptés et les cas de conflits de dépendances insolubles trop fréquents. Il convient d'éviter les distribs à base de rpm...
-Pour une station de travail, slackware rulez. A mon sens Slack a un grand avantage, inciter à installer depuis les sources (grace à checkinstall c'est une formalité) et utiliser des sources "princeps" pour tous les gros sous-ensembles (kernel, gnome, kde, etc). En plus avec swaret on peut quand même mettre à jour vite et facilement, même si ça reste plus sportif que sur la Debian.
J'ai l'impression que les systèmes de gestion de paquetages, qu'ils soient rpm ou deb, posent plus de problemes qu'ils n'en resolvent...
L'avenir est peut-etre au système utilisé par Firefox: les binaires et les bibliothèques nécessaires sont dans le même sous-repertoire. Yaka décompresser l'archive, la déplacer dans /usr/share et faire un lien dans /usr/bin et c'est parti.
Pour le désinstaller, on vire le répertoire et le lien, et c'est fini.
Qui a dit compliqué?
Jerome.
Irvin Probst
On 2004-04-07, Michel Talon wrote:
Je suis d'accord avec toi pour ce point là. Aprés vérification (il y a un changelog dans texmf) il apparaît que les versions de tetex dans Mandrake et FreeBSD sont exactement les mêmes, et qu'il s'agit donc uniquement d'un problème de découpage. Tu sais ce que je pense du découpage qui est la plaie des distributions Linux, et particulièrement de Debian. C'est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer. Perdre son temps à découper des paquets quand la taille des disques double tous les ans, c'est déjà ridicule. Le faire perdre aux utilisateurs car il manque toujours un bout de ci de là pour faire ce qu'on veut, c'est incurablement stupide.
Dis Michel, cette rengaine tu nous l'as déjà sortie sur gcc y'a un an, tu ne vas pas encore recommencer rassure moi ? Surtout qu'il suffit de faire s/tetex/gcc/ et s/dvipdfm/libc6-dev/ dans tes posts pour voir que tu n'as absolument pas évolué dans tes "critiques" ni dans tes méthodes de faire. Au passage j'en profite quand meme pour te signaler que pour beaucoup de monde "médiocrité" est plutot synonyme de "gros package fourre tout mal foutu" que de "découpage fin".
-- Irvin Probst There are 10 types of people in the world... those who understand binary and those who don't.
On 2004-04-07, Michel Talon <talon@lpthe.jussieu.fr> wrote:
Je suis d'accord avec toi pour ce point là. Aprés vérification (il y a
un changelog dans texmf) il apparaît que les versions de tetex dans
Mandrake et FreeBSD sont exactement les mêmes, et qu'il s'agit donc
uniquement d'un problème de découpage. Tu sais ce que je pense du
découpage qui est la plaie des distributions Linux, et particulièrement
de Debian. C'est la plus grande stupidité que des esprits infiniment
médiocres aient pu imaginer. Perdre son temps à découper des paquets
quand la taille des disques double tous les ans, c'est déjà ridicule.
Le faire perdre aux utilisateurs car il manque toujours un bout de ci de
là pour faire ce qu'on veut, c'est incurablement stupide.
Dis Michel, cette rengaine tu nous l'as déjà sortie sur gcc y'a un an,
tu ne vas pas encore recommencer rassure moi ? Surtout qu'il suffit de
faire s/tetex/gcc/ et s/dvipdfm/libc6-dev/ dans tes posts pour voir que
tu n'as absolument pas évolué dans tes "critiques" ni dans tes méthodes
de faire.
Au passage j'en profite quand meme pour te signaler que pour beaucoup
de monde "médiocrité" est plutot synonyme de "gros package fourre tout
mal foutu" que de "découpage fin".
--
Irvin Probst
There are 10 types of people in the world... those who understand binary
and those who don't.
Je suis d'accord avec toi pour ce point là. Aprés vérification (il y a un changelog dans texmf) il apparaît que les versions de tetex dans Mandrake et FreeBSD sont exactement les mêmes, et qu'il s'agit donc uniquement d'un problème de découpage. Tu sais ce que je pense du découpage qui est la plaie des distributions Linux, et particulièrement de Debian. C'est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer. Perdre son temps à découper des paquets quand la taille des disques double tous les ans, c'est déjà ridicule. Le faire perdre aux utilisateurs car il manque toujours un bout de ci de là pour faire ce qu'on veut, c'est incurablement stupide.
Dis Michel, cette rengaine tu nous l'as déjà sortie sur gcc y'a un an, tu ne vas pas encore recommencer rassure moi ? Surtout qu'il suffit de faire s/tetex/gcc/ et s/dvipdfm/libc6-dev/ dans tes posts pour voir que tu n'as absolument pas évolué dans tes "critiques" ni dans tes méthodes de faire. Au passage j'en profite quand meme pour te signaler que pour beaucoup de monde "médiocrité" est plutot synonyme de "gros package fourre tout mal foutu" que de "découpage fin".
-- Irvin Probst There are 10 types of people in the world... those who understand binary and those who don't.
Benjamin FRANCOIS
Michel Talon s'est exprimé en ces termes:
Non, c'est un argument absolument radical. Pour toute personne sensée la taille actuelle des disques peut dores et déjà être considérée comme infinie, et tous les ans ça sera encore plus vrai. Il en résulte qu'économiser de la place est une connerie.
Et tous les ans tu dilapides ton argent pour en racheter un et transfèrer le contenu de ton ancien disque dessus ? Excuse-moi, mais c'est ça que je considère être une connerie.
-- <vect> tout ce qui finit en ml c'est laid <Ol> ergo caml sux <vect> ergo caml ?
Michel Talon s'est exprimé en ces termes:
Non, c'est un argument absolument radical. Pour toute personne sensée la
taille actuelle des disques peut dores et déjà être considérée comme
infinie, et tous les ans ça sera encore plus vrai. Il en résulte
qu'économiser de la place est une connerie.
Et tous les ans tu dilapides ton argent pour en racheter un et
transfèrer le contenu de ton ancien disque dessus ? Excuse-moi, mais
c'est ça que je considère être une connerie.
--
<vect> tout ce qui finit en ml c'est laid
<Ol> ergo caml sux
<vect> ergo caml ?
Non, c'est un argument absolument radical. Pour toute personne sensée la taille actuelle des disques peut dores et déjà être considérée comme infinie, et tous les ans ça sera encore plus vrai. Il en résulte qu'économiser de la place est une connerie.
Et tous les ans tu dilapides ton argent pour en racheter un et transfèrer le contenu de ton ancien disque dessus ? Excuse-moi, mais c'est ça que je considère être une connerie.
-- <vect> tout ce qui finit en ml c'est laid <Ol> ergo caml sux <vect> ergo caml ?
Benjamin FRANCOIS
Michel Talon s'est exprimé en ces termes:
Tu sais ce que je pense du découpage qui est la plaie des distributions Linux, et particulièrement de Debian. C'est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer.
En fait ce qu'il te faudrait c'est un debian.tar.gz de 11 Go pour que tu nous foutes la paix, c'est ça ?
-- <vect> tout ce qui finit en ml c'est laid <Ol> ergo caml sux <vect> ergo caml ?
Michel Talon s'est exprimé en ces termes:
Tu sais ce que je pense du
découpage qui est la plaie des distributions Linux, et particulièrement
de Debian. C'est la plus grande stupidité que des esprits infiniment
médiocres aient pu imaginer.
En fait ce qu'il te faudrait c'est un debian.tar.gz de 11 Go pour que tu
nous foutes la paix, c'est ça ?
--
<vect> tout ce qui finit en ml c'est laid
<Ol> ergo caml sux
<vect> ergo caml ?
Tu sais ce que je pense du découpage qui est la plaie des distributions Linux, et particulièrement de Debian. C'est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer.
En fait ce qu'il te faudrait c'est un debian.tar.gz de 11 Go pour que tu nous foutes la paix, c'est ça ?
-- <vect> tout ce qui finit en ml c'est laid <Ol> ergo caml sux <vect> ergo caml ?
Irvin Probst
On 2004-04-07, Benjamin FRANCOIS wrote:
Michel Talon s'est exprimé en ces termes:
Tu sais ce que je pense du découpage qui est la plaie des distributions Linux, et particulièrement de Debian. C'est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer.
En fait ce qu'il te faudrait c'est un debian.tar.gz de 11 Go pour que tu nous foutes la paix, c'est ça ?
Compresser les archives alors que la capacité des media de stockage et la bande passante disponible pour les transférer double tous les ans est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer.
-- Irvin Probst There are 10 types of people in the world... those who understand binary and those who don't.
On 2004-04-07, Benjamin FRANCOIS <kwyxz@kwyxz.org> wrote:
Michel Talon s'est exprimé en ces termes:
Tu sais ce que je pense du
découpage qui est la plaie des distributions Linux, et particulièrement
de Debian. C'est la plus grande stupidité que des esprits infiniment
médiocres aient pu imaginer.
En fait ce qu'il te faudrait c'est un debian.tar.gz de 11 Go pour que tu
nous foutes la paix, c'est ça ?
Compresser les archives alors que la capacité des media de stockage et
la bande passante disponible pour les transférer double tous les ans est
la plus grande stupidité que des esprits infiniment médiocres aient pu
imaginer.
--
Irvin Probst
There are 10 types of people in the world... those who understand binary
and those who don't.
Tu sais ce que je pense du découpage qui est la plaie des distributions Linux, et particulièrement de Debian. C'est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer.
En fait ce qu'il te faudrait c'est un debian.tar.gz de 11 Go pour que tu nous foutes la paix, c'est ça ?
Compresser les archives alors que la capacité des media de stockage et la bande passante disponible pour les transférer double tous les ans est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer.
-- Irvin Probst There are 10 types of people in the world... those who understand binary and those who don't.
Miod Vallat
Je préfère de très loin un encodage comme Unicode
Unicode n'est pas une encodage, il ne décrit qu'une numérotation des caractères, pas leur représentation sous forme d'octets. Il y a plusieurs manières de représenter Unicode sous forme d'octets, les plus connues sont UCS-2 (deux octets par caractère, tout Unicode n'est donc pas représentable), UCS-4 (quatre octets par caractère), UTF-16 (deux octets par caractère en général, un hack pour représenter au delà, c'est une beurkerie pour contenter ceux qui avaient commencé à implémenter à base d'UCS-2), UTF-8 (de un à quatre octets par caractère).
Oui, je me suis fait mal comprendre, parce que j'ai tendance à faire l'amalgame Unicode / UCS-2 et UCS-4. UTF-* étant de la patée pour chats.
En revanche, pour la représentation externe des textes, UTF-8 a plein d'avantages sur tous les autres :
Et encore plus d'inconvénients... en voici une liste succinte :
- brise tous les principes de simplicité (KISS) dans le traitement des chaînes. On ne peut pas, sans parcourir le contenu d'une chaîne, en connaître : - la longueur (on peut la borner, c'est tout) - la position d'un caractère arbitraire dans la chaîne (et d'une bien sûr, la longueur d'une sous-chaîne)
- nécessité de réécrire la totalité de ses manipulations de chaînes, avec le succès que l'on a vu : entre les N implémentations différentes et toutes plus ou moins incorrectes, et plus ou moins complètes, on n' est pas sorti de l'auberge.
- sécurité zéro (qui découle directement du point précédent) : on n'a pas assez sensibilisé les programmeurs aux débordement de chaînes «standard», voilà que c'est pire avec UTF-*, comme l'attestent malheureusement les problèmes exploitables découverts petit à petit dans le traitement des chaînes en UTF-* de tel ou tel logiciel.
Une personne de mon entourage prétend que les coûts engendrés par le déploiement d'UTF-* dépassent celui de quadrupler la mémoire physique et la mémoire de masse de tous les ordinateurs de la planète. Je ne suis pas loin de partager son avis sur ce point.
Je préfère de très loin un encodage comme Unicode
Unicode n'est pas une encodage, il ne décrit qu'une numérotation des
caractères, pas leur représentation sous forme d'octets. Il y a
plusieurs manières de représenter Unicode sous forme d'octets, les plus
connues sont UCS-2 (deux octets par caractère, tout Unicode n'est donc
pas représentable), UCS-4 (quatre octets par caractère), UTF-16 (deux
octets par caractère en général, un hack pour représenter au delà, c'est
une beurkerie pour contenter ceux qui avaient commencé à implémenter à
base d'UCS-2), UTF-8 (de un à quatre octets par caractère).
Oui, je me suis fait mal comprendre, parce que j'ai tendance à faire
l'amalgame Unicode / UCS-2 et UCS-4. UTF-* étant de la patée pour chats.
En revanche, pour la représentation externe des textes, UTF-8 a plein
d'avantages sur tous les autres :
Et encore plus d'inconvénients... en voici une liste succinte :
- brise tous les principes de simplicité (KISS) dans le traitement des
chaînes. On ne peut pas, sans parcourir le contenu d'une chaîne, en
connaître :
- la longueur (on peut la borner, c'est tout)
- la position d'un caractère arbitraire dans la chaîne (et d'une
bien sûr, la longueur d'une sous-chaîne)
- nécessité de réécrire la totalité de ses manipulations de chaînes,
avec le succès que l'on a vu : entre les N implémentations différentes
et toutes plus ou moins incorrectes, et plus ou moins complètes, on n'
est pas sorti de l'auberge.
- sécurité zéro (qui découle directement du point précédent) : on n'a
pas assez sensibilisé les programmeurs aux débordement de chaînes
«standard», voilà que c'est pire avec UTF-*, comme l'attestent
malheureusement les problèmes exploitables découverts petit à petit
dans le traitement des chaînes en UTF-* de tel ou tel logiciel.
Une personne de mon entourage prétend que les coûts engendrés par le
déploiement d'UTF-* dépassent celui de quadrupler la mémoire physique et
la mémoire de masse de tous les ordinateurs de la planète. Je ne suis
pas loin de partager son avis sur ce point.
Unicode n'est pas une encodage, il ne décrit qu'une numérotation des caractères, pas leur représentation sous forme d'octets. Il y a plusieurs manières de représenter Unicode sous forme d'octets, les plus connues sont UCS-2 (deux octets par caractère, tout Unicode n'est donc pas représentable), UCS-4 (quatre octets par caractère), UTF-16 (deux octets par caractère en général, un hack pour représenter au delà, c'est une beurkerie pour contenter ceux qui avaient commencé à implémenter à base d'UCS-2), UTF-8 (de un à quatre octets par caractère).
Oui, je me suis fait mal comprendre, parce que j'ai tendance à faire l'amalgame Unicode / UCS-2 et UCS-4. UTF-* étant de la patée pour chats.
En revanche, pour la représentation externe des textes, UTF-8 a plein d'avantages sur tous les autres :
Et encore plus d'inconvénients... en voici une liste succinte :
- brise tous les principes de simplicité (KISS) dans le traitement des chaînes. On ne peut pas, sans parcourir le contenu d'une chaîne, en connaître : - la longueur (on peut la borner, c'est tout) - la position d'un caractère arbitraire dans la chaîne (et d'une bien sûr, la longueur d'une sous-chaîne)
- nécessité de réécrire la totalité de ses manipulations de chaînes, avec le succès que l'on a vu : entre les N implémentations différentes et toutes plus ou moins incorrectes, et plus ou moins complètes, on n' est pas sorti de l'auberge.
- sécurité zéro (qui découle directement du point précédent) : on n'a pas assez sensibilisé les programmeurs aux débordement de chaînes «standard», voilà que c'est pire avec UTF-*, comme l'attestent malheureusement les problèmes exploitables découverts petit à petit dans le traitement des chaînes en UTF-* de tel ou tel logiciel.
Une personne de mon entourage prétend que les coûts engendrés par le déploiement d'UTF-* dépassent celui de quadrupler la mémoire physique et la mémoire de masse de tous les ordinateurs de la planète. Je ne suis pas loin de partager son avis sur ce point.
talon
Benjamin FRANCOIS wrote:
Michel Talon s'est exprimé en ces termes:
Non, c'est un argument absolument radical. Pour toute personne sensée la taille actuelle des disques peut dores et déjà être considérée comme infinie, et tous les ans ça sera encore plus vrai. Il en résulte qu'économiser de la place est une connerie.
Et tous les ans tu dilapides ton argent pour en racheter un et transfèrer le contenu de ton ancien disque dessus ? Excuse-moi, mais c'est ça que je considère être une connerie.
Bien sûr que non, que je ne change pas mon disque tous les ans. Mais au bout de 4 ou 5 ans je le change, et sa capacité a beaucoup augmenté. Dans notre labo on a pendant longtemps été obligés à économiser sur l'espace disque. Maintenant c'est fini. On a déjà dix fois plus que ce qu'on utilise, et bientôt ce sera 100 fois plus. C'est pour ça que je dis qu'on peut considérer maintenant que l'espace disque est infini. Tu peux trouver des disques externes de 1 téraocted aujourdhui ( LACIE ) Bientôt ce sera tout à fait banal. Actuellement on n'a pas cet objet un peu dispendieux, mais on a deux maxtor externes de 300 Go pour faire des sauvegardes, et tout à l'avenant. Ceci est à comparer à l'espace que j'occupe sur mon installation FreeBSD, et pourtant j'ai plusieurs centaines de paquets: au total 5 Go, ce qui est totalement dérisoire. Aller pinailler pour économiser 1 Go c'est de la folie furieuse.
--
Michel TALON
Benjamin FRANCOIS <kwyxz@kwyxz.org> wrote:
Michel Talon s'est exprimé en ces termes:
Non, c'est un argument absolument radical. Pour toute personne sensée la
taille actuelle des disques peut dores et déjà être considérée comme
infinie, et tous les ans ça sera encore plus vrai. Il en résulte
qu'économiser de la place est une connerie.
Et tous les ans tu dilapides ton argent pour en racheter un et
transfèrer le contenu de ton ancien disque dessus ? Excuse-moi, mais
c'est ça que je considère être une connerie.
Bien sûr que non, que je ne change pas mon disque tous les ans. Mais au
bout de 4 ou 5 ans je le change, et sa capacité a beaucoup augmenté.
Dans notre labo on a pendant longtemps été obligés à économiser sur
l'espace disque. Maintenant c'est fini. On a déjà dix fois plus que ce
qu'on utilise, et bientôt ce sera 100 fois plus. C'est pour ça que je
dis qu'on peut considérer maintenant que l'espace disque est infini.
Tu peux trouver des disques externes de 1 téraocted aujourdhui ( LACIE )
Bientôt ce sera tout à fait banal. Actuellement on n'a pas cet objet un
peu dispendieux, mais on a deux maxtor externes de 300 Go pour faire des
sauvegardes, et tout à l'avenant. Ceci est à comparer à l'espace que
j'occupe sur mon installation FreeBSD, et pourtant j'ai plusieurs
centaines de paquets: au total 5 Go, ce qui est totalement dérisoire.
Aller pinailler pour économiser 1 Go c'est de la folie furieuse.
Non, c'est un argument absolument radical. Pour toute personne sensée la taille actuelle des disques peut dores et déjà être considérée comme infinie, et tous les ans ça sera encore plus vrai. Il en résulte qu'économiser de la place est une connerie.
Et tous les ans tu dilapides ton argent pour en racheter un et transfèrer le contenu de ton ancien disque dessus ? Excuse-moi, mais c'est ça que je considère être une connerie.
Bien sûr que non, que je ne change pas mon disque tous les ans. Mais au bout de 4 ou 5 ans je le change, et sa capacité a beaucoup augmenté. Dans notre labo on a pendant longtemps été obligés à économiser sur l'espace disque. Maintenant c'est fini. On a déjà dix fois plus que ce qu'on utilise, et bientôt ce sera 100 fois plus. C'est pour ça que je dis qu'on peut considérer maintenant que l'espace disque est infini. Tu peux trouver des disques externes de 1 téraocted aujourdhui ( LACIE ) Bientôt ce sera tout à fait banal. Actuellement on n'a pas cet objet un peu dispendieux, mais on a deux maxtor externes de 300 Go pour faire des sauvegardes, et tout à l'avenant. Ceci est à comparer à l'espace que j'occupe sur mon installation FreeBSD, et pourtant j'ai plusieurs centaines de paquets: au total 5 Go, ce qui est totalement dérisoire. Aller pinailler pour économiser 1 Go c'est de la folie furieuse.
--
Michel TALON
talon
Irvin Probst wrote:
On 2004-04-07, Michel Talon wrote:
Je suis d'accord avec toi pour ce point là. Aprés vérification (il y a un changelog dans texmf) il apparaît que les versions de tetex dans Mandrake et FreeBSD sont exactement les mêmes, et qu'il s'agit donc uniquement d'un problème de découpage. Tu sais ce que je pense du découpage qui est la plaie des distributions Linux, et particulièrement de Debian. C'est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer. Perdre son temps à découper des paquets quand la taille des disques double tous les ans, c'est déjà ridicule. Le faire perdre aux utilisateurs car il manque toujours un bout de ci de là pour faire ce qu'on veut, c'est incurablement stupide.
Dis Michel, cette rengaine tu nous l'as déjà sortie sur gcc y'a un an, tu ne vas pas encore recommencer rassure moi ? Surtout qu'il suffit de faire s/tetex/gcc/ et s/dvipdfm/libc6-dev/ dans tes posts pour voir que tu n'as absolument pas évolué dans tes "critiques" ni dans tes méthodes de faire. Au passage j'en profite quand meme pour te signaler que pour beaucoup de monde "médiocrité" est plutot synonyme de "gros package fourre tout mal foutu" que de "découpage fin".
Certes la répétition est inutile et je ne vais pas vous embêter plus avec ça, mais il s'agit bien comme tu le dis exactement de la même critique. Elle est encore mieux fondée cette année que la précédente, car les disques sont plus gros. Mais oui, pour moi la médiocrité c'est de penser qu'on a fait oeuvre utile, voire même qu'on a fait quelque chose, quand on a découpé en tronçons un logiciel que l'auteur n'a pas prévu de livrer découpé. La moindre des politesses envers l'auteur, c'est de laisser les headers qu'il a mis, et les docs qu'il a pondues (dans le cas heureux où il y en a), l'espace disque ça ne coute rien.
--
Michel TALON
Irvin Probst <irvin@trinity.irvinig.org> wrote:
On 2004-04-07, Michel Talon <talon@lpthe.jussieu.fr> wrote:
Je suis d'accord avec toi pour ce point là. Aprés vérification (il y a
un changelog dans texmf) il apparaît que les versions de tetex dans
Mandrake et FreeBSD sont exactement les mêmes, et qu'il s'agit donc
uniquement d'un problème de découpage. Tu sais ce que je pense du
découpage qui est la plaie des distributions Linux, et particulièrement
de Debian. C'est la plus grande stupidité que des esprits infiniment
médiocres aient pu imaginer. Perdre son temps à découper des paquets
quand la taille des disques double tous les ans, c'est déjà ridicule.
Le faire perdre aux utilisateurs car il manque toujours un bout de ci de
là pour faire ce qu'on veut, c'est incurablement stupide.
Dis Michel, cette rengaine tu nous l'as déjà sortie sur gcc y'a un an,
tu ne vas pas encore recommencer rassure moi ? Surtout qu'il suffit de
faire s/tetex/gcc/ et s/dvipdfm/libc6-dev/ dans tes posts pour voir que
tu n'as absolument pas évolué dans tes "critiques" ni dans tes méthodes
de faire.
Au passage j'en profite quand meme pour te signaler que pour beaucoup
de monde "médiocrité" est plutot synonyme de "gros package fourre tout
mal foutu" que de "découpage fin".
Certes la répétition est inutile et je ne vais pas vous embêter plus
avec ça, mais il s'agit bien comme tu le dis exactement de la même
critique. Elle est encore mieux fondée cette année que la précédente,
car les disques sont plus gros. Mais oui, pour moi la médiocrité c'est
de penser qu'on a fait oeuvre utile, voire même qu'on a fait quelque
chose, quand on a découpé en tronçons un logiciel que l'auteur n'a pas
prévu de livrer découpé. La moindre des politesses envers l'auteur,
c'est de laisser les headers qu'il a mis, et les docs qu'il a pondues
(dans le cas heureux où il y en a), l'espace disque ça ne coute rien.
Je suis d'accord avec toi pour ce point là. Aprés vérification (il y a un changelog dans texmf) il apparaît que les versions de tetex dans Mandrake et FreeBSD sont exactement les mêmes, et qu'il s'agit donc uniquement d'un problème de découpage. Tu sais ce que je pense du découpage qui est la plaie des distributions Linux, et particulièrement de Debian. C'est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer. Perdre son temps à découper des paquets quand la taille des disques double tous les ans, c'est déjà ridicule. Le faire perdre aux utilisateurs car il manque toujours un bout de ci de là pour faire ce qu'on veut, c'est incurablement stupide.
Dis Michel, cette rengaine tu nous l'as déjà sortie sur gcc y'a un an, tu ne vas pas encore recommencer rassure moi ? Surtout qu'il suffit de faire s/tetex/gcc/ et s/dvipdfm/libc6-dev/ dans tes posts pour voir que tu n'as absolument pas évolué dans tes "critiques" ni dans tes méthodes de faire. Au passage j'en profite quand meme pour te signaler que pour beaucoup de monde "médiocrité" est plutot synonyme de "gros package fourre tout mal foutu" que de "découpage fin".
Certes la répétition est inutile et je ne vais pas vous embêter plus avec ça, mais il s'agit bien comme tu le dis exactement de la même critique. Elle est encore mieux fondée cette année que la précédente, car les disques sont plus gros. Mais oui, pour moi la médiocrité c'est de penser qu'on a fait oeuvre utile, voire même qu'on a fait quelque chose, quand on a découpé en tronçons un logiciel que l'auteur n'a pas prévu de livrer découpé. La moindre des politesses envers l'auteur, c'est de laisser les headers qu'il a mis, et les docs qu'il a pondues (dans le cas heureux où il y en a), l'espace disque ça ne coute rien.
--
Michel TALON
talon
Benjamin FRANCOIS wrote:
Michel Talon s'est exprimé en ces termes:
Tu sais ce que je pense du découpage qui est la plaie des distributions Linux, et particulièrement de Debian. C'est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer.
En fait ce qu'il te faudrait c'est un debian.tar.gz de 11 Go pour que tu nous foutes la paix, c'est ça ?
Oui, pourquoi pas? Sur un disque de 120 gigs, qu'est ce que ça peut bien
me faire d'avoir 20 gigs de système?
--
Michel TALON
Benjamin FRANCOIS <kwyxz@kwyxz.org> wrote:
Michel Talon s'est exprimé en ces termes:
Tu sais ce que je pense du
découpage qui est la plaie des distributions Linux, et particulièrement
de Debian. C'est la plus grande stupidité que des esprits infiniment
médiocres aient pu imaginer.
En fait ce qu'il te faudrait c'est un debian.tar.gz de 11 Go pour que tu
nous foutes la paix, c'est ça ?
Oui, pourquoi pas? Sur un disque de 120 gigs, qu'est ce que ça peut bien
Tu sais ce que je pense du découpage qui est la plaie des distributions Linux, et particulièrement de Debian. C'est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer.
En fait ce qu'il te faudrait c'est un debian.tar.gz de 11 Go pour que tu nous foutes la paix, c'est ça ?
Oui, pourquoi pas? Sur un disque de 120 gigs, qu'est ce que ça peut bien
