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...
Miod Vallat , dans le message <407445dc$0$19470$, a écrit :
On ne peut pas, sans parcourir le contenu d'une chaîne, en connaître :
Mais s'agissant d'une représentation externe, c'est non-pertinent, puisqu'il est de toutes façons nécessaire de la parcourir.
- nécessité de réécrire la totalité de ses manipulations de chaînes,
Non, c'est faux. Une très grande partie des manipulations de chaînes n'ont rien à changer, puisque les seuls caractères significatifs sont presque toujours de l'ASCII, et qu'UTF-8, contrairement à UCS-[24], lui est compatible.
Prends head ou tail, par exemple : il n'y a strictement rien à changer dans le code pour les rendre compatibles avec l'UTF-8.
- 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-*
Les mauvais programmeurs trouveront _toujours_ le moyen de faire des buffer overflows. Avec un peu de chance, le fait que la représentation soit de taille variable leur fera peut-être au contraire prendre plus de précautions.
Miod Vallat , dans le message <407445dc$0$19470$636a15ce@news.free.fr>,
a écrit :
On ne peut pas, sans parcourir le contenu d'une chaîne, en
connaître :
Mais s'agissant d'une représentation externe, c'est non-pertinent,
puisqu'il est de toutes façons nécessaire de la parcourir.
- nécessité de réécrire la totalité de ses manipulations de chaînes,
Non, c'est faux. Une très grande partie des manipulations de chaînes
n'ont rien à changer, puisque les seuls caractères significatifs sont
presque toujours de l'ASCII, et qu'UTF-8, contrairement à UCS-[24], lui
est compatible.
Prends head ou tail, par exemple : il n'y a strictement rien à changer
dans le code pour les rendre compatibles avec l'UTF-8.
- 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-*
Les mauvais programmeurs trouveront _toujours_ le moyen de faire des
buffer overflows. Avec un peu de chance, le fait que la représentation
soit de taille variable leur fera peut-être au contraire prendre plus de
précautions.
Miod Vallat , dans le message <407445dc$0$19470$, a écrit :
On ne peut pas, sans parcourir le contenu d'une chaîne, en connaître :
Mais s'agissant d'une représentation externe, c'est non-pertinent, puisqu'il est de toutes façons nécessaire de la parcourir.
- nécessité de réécrire la totalité de ses manipulations de chaînes,
Non, c'est faux. Une très grande partie des manipulations de chaînes n'ont rien à changer, puisque les seuls caractères significatifs sont presque toujours de l'ASCII, et qu'UTF-8, contrairement à UCS-[24], lui est compatible.
Prends head ou tail, par exemple : il n'y a strictement rien à changer dans le code pour les rendre compatibles avec l'UTF-8.
- 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-*
Les mauvais programmeurs trouveront _toujours_ le moyen de faire des buffer overflows. Avec un peu de chance, le fait que la représentation soit de taille variable leur fera peut-être au contraire prendre plus de précautions.
george
Shmurtz , dans le message , a écrit :
Sketch qui s'apelle maintenant Skencil est scriptable en Python, de plus le portage de Tk vers Gtk est en cours.
Il était déjà en cours il y a quatre ans.
Shmurtz , dans le message <pan.2004.04.07.15.52.50.724458@Beurk.org>, a
écrit :
Sketch qui s'apelle maintenant Skencil est scriptable en Python, de plus
le portage de Tk vers Gtk est en cours.
Sketch qui s'apelle maintenant Skencil est scriptable en Python, de plus le portage de Tk vers Gtk est en cours.
Il était déjà en cours il y a quatre ans.
george
Michel Talon, dans le message <c512tm$1fpd$, a écrit :
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?
Rien du tout. En revanche, j'en ai ras-le-bol des trois versions de la libc qui se battent en duel dans l'espace mémoire d'un même processus, ras le bol qu'un code parfaitement standard ne compile pas sous BSD parce qu'ils ont une gestion des terminaux qui était déjà obsolète il y a cinq ans, et j'en oublie certainement.
Je n'essaie pas d'imposer mes vues, j'explique les raisons pour lesquelles, à mon avis, le découpage est stupide.
Eh bien le découpage, à mon avis, est utile. Et comme plusieurs packages découpés permettent de faire un unique paquet monolithique, alors que la réciproque est fausse, tu admettras bien que le choix se fasse dans le sens du découpage.
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
Si par « sensée » tu entends « qui a les moyens de s'acheter du matériel informatique tous les six mois », je te conseille de consulter un dictionnaire, ça ne veut pas dire ça.
Michel Talon, dans le message <c512tm$1fpd$1@asmodee.lpthe.jussieu.fr>,
a écrit :
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?
Rien du tout. En revanche, j'en ai ras-le-bol des trois versions de la
libc qui se battent en duel dans l'espace mémoire d'un même processus,
ras le bol qu'un code parfaitement standard ne compile pas sous BSD
parce qu'ils ont une gestion des terminaux qui était déjà obsolète il y
a cinq ans, et j'en oublie certainement.
Je n'essaie pas d'imposer mes vues, j'explique les raisons pour
lesquelles, à mon avis, le découpage est stupide.
Eh bien le découpage, à mon avis, est utile. Et comme plusieurs packages
découpés permettent de faire un unique paquet monolithique, alors que la
réciproque est fausse, tu admettras bien que le choix se fasse dans le
sens du découpage.
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
Si par « sensée » tu entends « qui a les moyens de s'acheter du matériel
informatique tous les six mois », je te conseille de consulter un
dictionnaire, ça ne veut pas dire ça.
Michel Talon, dans le message <c512tm$1fpd$, a écrit :
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?
Rien du tout. En revanche, j'en ai ras-le-bol des trois versions de la libc qui se battent en duel dans l'espace mémoire d'un même processus, ras le bol qu'un code parfaitement standard ne compile pas sous BSD parce qu'ils ont une gestion des terminaux qui était déjà obsolète il y a cinq ans, et j'en oublie certainement.
Je n'essaie pas d'imposer mes vues, j'explique les raisons pour lesquelles, à mon avis, le découpage est stupide.
Eh bien le découpage, à mon avis, est utile. Et comme plusieurs packages découpés permettent de faire un unique paquet monolithique, alors que la réciproque est fausse, tu admettras bien que le choix se fasse dans le sens du découpage.
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
Si par « sensée » tu entends « qui a les moyens de s'acheter du matériel informatique tous les six mois », je te conseille de consulter un dictionnaire, ça ne veut pas dire ça.
george
Jerome Lambert , dans le message , a écrit :
Qui a dit compliqué?
Et les dépendances ? Les fichiers de config ?
Jerome Lambert , dans le message
<pan.2004.04.07.16.11.43.658232@swing.aretirer.be>, a écrit :
In article <40743239$0$501$, 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.
Avec la taille des disques actuels (80 ou 120Go), l'OS ne prend qu'une toute petie partite de l'espace disponible, le reste est en general utilisé pour stocker des données. Et dans ce cas la on se fou completement que l'OS utilise quelques centaines de Mo supplementaires si ca peut permettre de simplifier les choses, et c'est pas ca qui va t'obliger à acheter un nouveau disque dur.
In article <40743239$0$501$636a15ce@news.free.fr>, 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.
Avec la taille des disques actuels (80 ou 120Go), l'OS ne prend qu'une
toute petie partite de l'espace disponible, le reste est en general
utilisé pour stocker des données.
Et dans ce cas la on se fou completement que l'OS utilise quelques
centaines de Mo supplementaires si ca peut permettre de simplifier
les choses, et c'est pas ca qui va t'obliger à acheter un nouveau
disque dur.
In article <40743239$0$501$, 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.
Avec la taille des disques actuels (80 ou 120Go), l'OS ne prend qu'une toute petie partite de l'espace disponible, le reste est en general utilisé pour stocker des données. Et dans ce cas la on se fou completement que l'OS utilise quelques centaines de Mo supplementaires si ca peut permettre de simplifier les choses, et c'est pas ca qui va t'obliger à acheter un nouveau disque dur.
george
Michel Talon, dans le message <c51h35$1jma$, a écrit :
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?
Le disque sur lequel je veux faire une installation prochainement n'a pas 20 Go. Tu as un 120 Go pour portable à m'offrir ? Je t'envoie mon adresse ?
Michel Talon, dans le message <c51h35$1jma$3@asmodee.lpthe.jussieu.fr>,
a écrit :
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?
Le disque sur lequel je veux faire une installation prochainement n'a
pas 20 Go. Tu as un 120 Go pour portable à m'offrir ? Je t'envoie mon
adresse ?
Mon adresse est sur ma page web, si tu veux m'envoyer un disque actuel.
Et dans ce cas la on se fou completement que l'OS utilise quelques centaines de Mo supplementaires
Et on se fout également des deux heures supplémentaires nécessaires pour télécharger le paquet à chaque mise à jour ?
Jerome Lambert
Le Wed, 07 Apr 2004 18:47:50 +0000, Nicolas George a écrit :
Jerome Lambert , dans le message , a écrit :
Qui a dit compliqué?
Et les dépendances ?
Il nécessite juste GTK2 et une glibc version ???
Sinon il vient avec les différentes bibliothèques nécessaires à son fonctionnement, qui sont dans des sous-reperoires de /usr/share/firefox, donc on n'a pas à se soucier des dépendances à ce niveau
exemple: [ jerome]$ locate libnspr4 /usr/share/firefox/libnspr4.so /usr/lib/libnspr4.so (celle du Mozilla installé)
Donc les conflits sont impossibles, puisque Firefox utilise SA bibliothèque dans SON repertoire et se fiche de celle des autres...
Les fichiers de config ? Idem, dans des sous-repertoires de /usr/share/firefox, les fichiers
propres aux utilisateurs étant bien entendu dans ~/.phoenix/
C'est clair que c'est on ne peut plus non-conforme à la hiérachie Unix standard, mais ça résout d'un seul coup tous les problèmes de conflits et de dépendances, vu que c'est "chacun chez soi"
Ca me rappelle d'ailleurs ce que l'on faisait sous DOS et OS/2: chaque programme s'installait dans son répertoire sans embeter les autres,et désinstaller un programme revenait à en supprimer le répertoire. D'après ce que j'en ai vu, les Macintosh (y compris OS X) fonctionnent aussi de cette manière.
Jerome.
Le Wed, 07 Apr 2004 18:47:50 +0000, Nicolas George a écrit :
Jerome Lambert , dans le message
<pan.2004.04.07.16.11.43.658232@swing.aretirer.be>, a écrit :
Qui a dit compliqué?
Et les dépendances ?
Il nécessite juste GTK2 et une glibc version ???
Sinon il vient avec les différentes bibliothèques nécessaires à son
fonctionnement, qui sont dans des sous-reperoires de /usr/share/firefox,
donc on n'a pas à se soucier des dépendances à ce niveau
exemple:
[jerome@torvalds jerome]$ locate libnspr4
/usr/share/firefox/libnspr4.so
/usr/lib/libnspr4.so (celle du Mozilla installé)
Donc les conflits sont impossibles, puisque Firefox utilise SA
bibliothèque dans SON repertoire et se fiche de celle des autres...
Les fichiers de config ?
Idem, dans des sous-repertoires de /usr/share/firefox, les fichiers
propres aux utilisateurs étant bien entendu dans ~/.phoenix/
C'est clair que c'est on ne peut plus non-conforme à la hiérachie Unix
standard, mais ça résout d'un seul coup tous les problèmes de conflits
et de dépendances, vu que c'est "chacun chez soi"
Ca me rappelle d'ailleurs ce que l'on faisait sous DOS et OS/2: chaque
programme s'installait dans son répertoire sans embeter les autres,et
désinstaller un programme revenait à en supprimer le répertoire. D'après
ce que j'en ai vu, les Macintosh (y compris OS X) fonctionnent aussi de
cette manière.
Le Wed, 07 Apr 2004 18:47:50 +0000, Nicolas George a écrit :
Jerome Lambert , dans le message , a écrit :
Qui a dit compliqué?
Et les dépendances ?
Il nécessite juste GTK2 et une glibc version ???
Sinon il vient avec les différentes bibliothèques nécessaires à son fonctionnement, qui sont dans des sous-reperoires de /usr/share/firefox, donc on n'a pas à se soucier des dépendances à ce niveau
exemple: [ jerome]$ locate libnspr4 /usr/share/firefox/libnspr4.so /usr/lib/libnspr4.so (celle du Mozilla installé)
Donc les conflits sont impossibles, puisque Firefox utilise SA bibliothèque dans SON repertoire et se fiche de celle des autres...
Les fichiers de config ? Idem, dans des sous-repertoires de /usr/share/firefox, les fichiers
propres aux utilisateurs étant bien entendu dans ~/.phoenix/
C'est clair que c'est on ne peut plus non-conforme à la hiérachie Unix standard, mais ça résout d'un seul coup tous les problèmes de conflits et de dépendances, vu que c'est "chacun chez soi"
Ca me rappelle d'ailleurs ce que l'on faisait sous DOS et OS/2: chaque programme s'installait dans son répertoire sans embeter les autres,et désinstaller un programme revenait à en supprimer le répertoire. D'après ce que j'en ai vu, les Macintosh (y compris OS X) fonctionnent aussi de cette manière.
Jerome.
george
Jerome Lambert , dans le message , a écrit :
Il nécessite juste GTK2 et une glibc version ???
Xft, fontconfig, X11, OpenSSL, stdc++...
Sinon il vient avec les différentes bibliothèques nécessaires à son fonctionnement, qui sont dans des sous-reperoires de /usr/share/firefox, donc on n'a pas à se soucier des dépendances à ce niveau
Bref, si tu as deux programmes qui utilisent la même bibliothèque, tu as deux exemplaires de la bibliothèque, aussi bien sur disque qu'en mémoire. Super... Tu n'aurais pas appris la... ahem, disons informatique... sous windows, par hasard ?
Idem, dans des sous-repertoires de /usr/share/firefox, les fichiers propres aux utilisateurs étant bien entendu dans ~/.phoenix/
Tu n'as pas compris où est le problème. Si je modifie un fichier de config (par exemple unix.js pour y indiquer des font.directory.truetype.*), j'ai envie que quand je mets à jour le package, le gestionnaire de package me prévienne des modifications qu'il y a à faire. Je ne veux ni qu'il écrase silencieusement mes modifications (ce que ferait ton tar), ni qu'il ne mette pas à jour un fichier de config que je n'ai pas modifié et qui a changé depuis la version précédente.
Jerome Lambert , dans le message
<pan.2004.04.07.20.36.08.26179@swing.aretirer.be>, a écrit :
Il nécessite juste GTK2 et une glibc version ???
Xft, fontconfig, X11, OpenSSL, stdc++...
Sinon il vient avec les différentes bibliothèques nécessaires à son
fonctionnement, qui sont dans des sous-reperoires de /usr/share/firefox,
donc on n'a pas à se soucier des dépendances à ce niveau
Bref, si tu as deux programmes qui utilisent la même bibliothèque, tu as
deux exemplaires de la bibliothèque, aussi bien sur disque qu'en
mémoire. Super... Tu n'aurais pas appris la... ahem, disons
informatique... sous windows, par hasard ?
Idem, dans des sous-repertoires de /usr/share/firefox, les fichiers
propres aux utilisateurs étant bien entendu dans ~/.phoenix/
Tu n'as pas compris où est le problème. Si je modifie un fichier de
config (par exemple unix.js pour y indiquer des
font.directory.truetype.*), j'ai envie que quand je mets à jour le
package, le gestionnaire de package me prévienne des modifications qu'il
y a à faire. Je ne veux ni qu'il écrase silencieusement mes
modifications (ce que ferait ton tar), ni qu'il ne mette pas à jour un
fichier de config que je n'ai pas modifié et qui a changé depuis la
version précédente.
Sinon il vient avec les différentes bibliothèques nécessaires à son fonctionnement, qui sont dans des sous-reperoires de /usr/share/firefox, donc on n'a pas à se soucier des dépendances à ce niveau
Bref, si tu as deux programmes qui utilisent la même bibliothèque, tu as deux exemplaires de la bibliothèque, aussi bien sur disque qu'en mémoire. Super... Tu n'aurais pas appris la... ahem, disons informatique... sous windows, par hasard ?
Idem, dans des sous-repertoires de /usr/share/firefox, les fichiers propres aux utilisateurs étant bien entendu dans ~/.phoenix/
Tu n'as pas compris où est le problème. Si je modifie un fichier de config (par exemple unix.js pour y indiquer des font.directory.truetype.*), j'ai envie que quand je mets à jour le package, le gestionnaire de package me prévienne des modifications qu'il y a à faire. Je ne veux ni qu'il écrase silencieusement mes modifications (ce que ferait ton tar), ni qu'il ne mette pas à jour un fichier de config que je n'ai pas modifié et qui a changé depuis la version précédente.
talon
Nicolas George wrote:
Michel Talon, dans le message <c512tm$1fpd$, a écrit :
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?
Rien du tout. En revanche, j'en ai ras-le-bol des trois versions de la libc qui se battent en duel dans l'espace mémoire d'un même processus, ras le bol qu'un code parfaitement standard ne compile pas sous BSD parce qu'ils ont une gestion des terminaux qui était déjà obsolète il y a cinq ans, et j'en oublie certainement.
Quelles 3 versions de la libc? S'il y a un système qui a des problèmes dramatiques de libc c'est bien Linux, et lui seul.
--
Michel TALON
Nicolas George <george@clipper.ens.fr> wrote:
Michel Talon, dans le message <c512tm$1fpd$1@asmodee.lpthe.jussieu.fr>,
a écrit :
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?
Rien du tout. En revanche, j'en ai ras-le-bol des trois versions de la
libc qui se battent en duel dans l'espace mémoire d'un même processus,
ras le bol qu'un code parfaitement standard ne compile pas sous BSD
parce qu'ils ont une gestion des terminaux qui était déjà obsolète il y
a cinq ans, et j'en oublie certainement.
Quelles 3 versions de la libc?
S'il y a un système qui a des problèmes dramatiques de libc c'est bien
Linux, et lui seul.
Michel Talon, dans le message <c512tm$1fpd$, a écrit :
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?
Rien du tout. En revanche, j'en ai ras-le-bol des trois versions de la libc qui se battent en duel dans l'espace mémoire d'un même processus, ras le bol qu'un code parfaitement standard ne compile pas sous BSD parce qu'ils ont une gestion des terminaux qui était déjà obsolète il y a cinq ans, et j'en oublie certainement.
Quelles 3 versions de la libc? S'il y a un système qui a des problèmes dramatiques de libc c'est bien Linux, et lui seul.
