UBUNTU LINUX: J'ai reçu qq chose de vraiment gratuit
28 réponses
Marc
Pour tester une distribution LINUX sans l'installer sur le disque dur.
http://shipit.ubuntulinux.org/
propose des CD's gratuits:
J'ai commandé 10 CD's, comme ils le conseillent, et environ 1 mois plus
tard (je n'y pensais plus), je les ai reçus en provenance des Pays-Bas (?)
sans aucun frais.
En fait, il y a 20 CD's, car chaque pochette comprend 2 CD's: un "live"
bootable (genre Knoppix) et un CD de "clean" installation sur disque dur.
Essayé le "live" : fonctionne sans problème pour l'instant.
On Sat, 22 Jan 2005 13:33:43 +0000 (UTC) Nicolas George <nicolas$ wrote:
Sans doute. A mon avis ça apporte 20-30% de performance en plus. En outre on peut compiler avec le dernier gcc disponible (3.4.3 chez moi), qui est un peu plus performant que les versions plus anciennes. Non, très loin de là. Tout ça ne représente que quelques pourcents à
tout casser.
Oui, c'est plutôt de cet ordre. Alors passer plusieurs jours de compilation pour gagner l'équivalent de quelques secondes par jour, c'est pas un argument valable. Il faut quand même penser que pour une utilisation courante, les machines actuelles n'utilisent même pas un quart de leur capacité de calcul (et encore, je suis généreux!).
À la limite, en utilisant un compilateur adapté à sa plate-forme (compilateurs IBM, Intel, Sun...), on peut gagner jusqu'à 10% par rapport à GCC pour certaines applications spécifiques (applications de calcul pur, que tout utilisateur sensé compilera lui-même, même quand on lui propose des paquets binaires).
-- Jérémy JUST
On Sat, 22 Jan 2005 13:33:43 +0000 (UTC)
Nicolas George <nicolas$george@salle-s.org> wrote:
Sans doute. A mon avis ça apporte 20-30% de performance en plus. En
outre on peut compiler avec le dernier gcc disponible (3.4.3 chez
moi), qui est un peu plus performant que les versions plus anciennes.
Non, très loin de là. Tout ça ne représente que quelques pourcents à
tout casser.
Oui, c'est plutôt de cet ordre. Alors passer plusieurs jours de
compilation pour gagner l'équivalent de quelques secondes par jour,
c'est pas un argument valable.
Il faut quand même penser que pour une utilisation courante, les
machines actuelles n'utilisent même pas un quart de leur capacité de
calcul (et encore, je suis généreux!).
À la limite, en utilisant un compilateur adapté à sa plate-forme
(compilateurs IBM, Intel, Sun...), on peut gagner jusqu'à 10% par
rapport à GCC pour certaines applications spécifiques (applications de
calcul pur, que tout utilisateur sensé compilera lui-même, même quand on
lui propose des paquets binaires).
On Sat, 22 Jan 2005 13:33:43 +0000 (UTC) Nicolas George <nicolas$ wrote:
Sans doute. A mon avis ça apporte 20-30% de performance en plus. En outre on peut compiler avec le dernier gcc disponible (3.4.3 chez moi), qui est un peu plus performant que les versions plus anciennes. Non, très loin de là. Tout ça ne représente que quelques pourcents à
tout casser.
Oui, c'est plutôt de cet ordre. Alors passer plusieurs jours de compilation pour gagner l'équivalent de quelques secondes par jour, c'est pas un argument valable. Il faut quand même penser que pour une utilisation courante, les machines actuelles n'utilisent même pas un quart de leur capacité de calcul (et encore, je suis généreux!).
À la limite, en utilisant un compilateur adapté à sa plate-forme (compilateurs IBM, Intel, Sun...), on peut gagner jusqu'à 10% par rapport à GCC pour certaines applications spécifiques (applications de calcul pur, que tout utilisateur sensé compilera lui-même, même quand on lui propose des paquets binaires).
-- Jérémy JUST
Jérémy JUST
On Sat, 22 Jan 2005 13:24:50 +0000 (UTC) Nicolas George <nicolas$ wrote:
Zut, alors je n'aurais pas les machins clignotants dernier cri ?
Hot-babe? ;)
-- Jérémy JUST
On Sat, 22 Jan 2005 13:24:50 +0000 (UTC)
Nicolas George <nicolas$george@salle-s.org> wrote:
Zut, alors je n'aurais pas les machins clignotants dernier cri ?
On Sat, 22 Jan 2005 13:24:50 +0000 (UTC) Nicolas George <nicolas$ wrote:
Zut, alors je n'aurais pas les machins clignotants dernier cri ?
Hot-babe? ;)
-- Jérémy JUST
talon
Nicolas George <nicolas$ wrote:
Richard Delorme , dans le message <41f253fd$0$26211$, a écrit :
Sans doute. A mon avis ça apporte 20-30% de performance en plus. En outre on peut compiler avec le dernier gcc disponible (3.4.3 chez moi), qui est un peu plus performant que les versions plus anciennes.
Non, très loin de là. Tout ça ne représente que quelques pourcents à tout casser.
J'ai des exemples où une bonne optimisation fait gagner un facteur 2, d'autres où elle ne fait rien gagner, et mêmes d'autres, nombreux, où un programme compilé avec -O3 tourne plus lentement qu'un programme compilé avec -O. Donc il s'agit de faire une statistique sur l'ensemble des utilisations et bien malin est celui qui peut avancer un chiffre. J'aurais tendance à penser comme toi que le résultat moyen est quasi nul.
A ce sujet, j'ai eu la surprise de ma vie hier: j'ai compilé le tout nouveau, tout beau, Java1.5 pour FreeBSD et je l'ai essayé avec Jython sur le fameux benchmark qui avait circulé ici, et que en particulier Richard avait testé sur sa machine. Et bien, la surprise c'est que le Benchmark version python tourne beaucoup plus vite (plus de deux fois plus vite, l'un des tests 10 fois plus vite) sous Jython que sous le python natif!
Ce qui est plus pertinent, comme exemple, c'est des applications qui peuvent utiliser cinquante bibliothèques différentes. Exemple : XChat peut embarquer un interpréteur perl et/ou un interpréteur python. Si on ne se sert d'aucun des deux, on gagne pas mal en taille mémoire, et un peu en temps.
Vu le principe de la pagination à la demande j'ai un doute profond sur ce que tu racontes. Si tu ne te sers pas de l'interpète python, il n'aboutira jamais dans la mémoire. Donc il ne s'agit là que d'économies de bout de chandelle.
--
Michel TALON
Nicolas George <nicolas$george@salle-s.org> wrote:
Richard Delorme , dans le message
<41f253fd$0$26211$7a628cd7@news.club-internet.fr>, a écrit :
Sans doute. A mon avis ça apporte 20-30% de performance en plus. En
outre on peut compiler avec le dernier gcc disponible (3.4.3 chez moi),
qui est un peu plus performant que les versions plus anciennes.
Non, très loin de là. Tout ça ne représente que quelques pourcents à tout
casser.
J'ai des exemples où une bonne optimisation fait gagner un facteur 2,
d'autres où elle ne fait rien gagner, et mêmes d'autres, nombreux, où un
programme compilé avec -O3 tourne plus lentement qu'un programme compilé avec
-O. Donc il s'agit de faire une statistique sur l'ensemble des utilisations et
bien malin est celui qui peut avancer un chiffre. J'aurais tendance à penser
comme toi que le résultat moyen est quasi nul.
A ce sujet, j'ai eu la surprise de ma vie hier: j'ai compilé le tout nouveau,
tout beau, Java1.5 pour FreeBSD et je l'ai essayé avec Jython sur le fameux
benchmark qui avait circulé ici, et que en particulier Richard avait testé sur
sa machine. Et bien, la surprise c'est que le Benchmark version python tourne
beaucoup plus vite (plus de deux fois plus vite, l'un des tests 10 fois plus
vite) sous Jython que sous le python natif!
Ce qui est plus pertinent, comme exemple, c'est des applications qui peuvent
utiliser cinquante bibliothèques différentes. Exemple : XChat peut embarquer
un interpréteur perl et/ou un interpréteur python. Si on ne se sert d'aucun
des deux, on gagne pas mal en taille mémoire, et un peu en temps.
Vu le principe de la pagination à la demande j'ai un doute profond sur ce que
tu racontes. Si tu ne te sers pas de l'interpète python, il n'aboutira jamais
dans la mémoire. Donc il ne s'agit là que d'économies de bout de chandelle.
Richard Delorme , dans le message <41f253fd$0$26211$, a écrit :
Sans doute. A mon avis ça apporte 20-30% de performance en plus. En outre on peut compiler avec le dernier gcc disponible (3.4.3 chez moi), qui est un peu plus performant que les versions plus anciennes.
Non, très loin de là. Tout ça ne représente que quelques pourcents à tout casser.
J'ai des exemples où une bonne optimisation fait gagner un facteur 2, d'autres où elle ne fait rien gagner, et mêmes d'autres, nombreux, où un programme compilé avec -O3 tourne plus lentement qu'un programme compilé avec -O. Donc il s'agit de faire une statistique sur l'ensemble des utilisations et bien malin est celui qui peut avancer un chiffre. J'aurais tendance à penser comme toi que le résultat moyen est quasi nul.
A ce sujet, j'ai eu la surprise de ma vie hier: j'ai compilé le tout nouveau, tout beau, Java1.5 pour FreeBSD et je l'ai essayé avec Jython sur le fameux benchmark qui avait circulé ici, et que en particulier Richard avait testé sur sa machine. Et bien, la surprise c'est que le Benchmark version python tourne beaucoup plus vite (plus de deux fois plus vite, l'un des tests 10 fois plus vite) sous Jython que sous le python natif!
Ce qui est plus pertinent, comme exemple, c'est des applications qui peuvent utiliser cinquante bibliothèques différentes. Exemple : XChat peut embarquer un interpréteur perl et/ou un interpréteur python. Si on ne se sert d'aucun des deux, on gagne pas mal en taille mémoire, et un peu en temps.
Vu le principe de la pagination à la demande j'ai un doute profond sur ce que tu racontes. Si tu ne te sers pas de l'interpète python, il n'aboutira jamais dans la mémoire. Donc il ne s'agit là que d'économies de bout de chandelle.
--
Michel TALON
Nicolas George
Michel Talon, dans le message <cstoe0$20t3$, a écrit :
Vu le principe de la pagination à la demande j'ai un doute profond sur ce que tu racontes. Si tu ne te sers pas de l'interpète python, il n'aboutira jamais dans la mémoire. Donc il ne s'agit là que d'économies de bout de chandelle.
Ne pas s'en servir, c'est ne pas lui donner de scripts à bouffer. Ça n'empêche probablement pas le programme qui est lié avec de lancer son initialisation au début, et donc effectivement de charger une grande partie de la bibliothèque partagée.
Michel Talon, dans le message <cstoe0$20t3$1@asmodee.lpthe.jussieu.fr>,
a écrit :
Vu le principe de la pagination à la demande j'ai un doute profond sur ce que
tu racontes. Si tu ne te sers pas de l'interpète python, il n'aboutira jamais
dans la mémoire. Donc il ne s'agit là que d'économies de bout de chandelle.
Ne pas s'en servir, c'est ne pas lui donner de scripts à bouffer. Ça
n'empêche probablement pas le programme qui est lié avec de lancer son
initialisation au début, et donc effectivement de charger une grande partie
de la bibliothèque partagée.
Michel Talon, dans le message <cstoe0$20t3$, a écrit :
Vu le principe de la pagination à la demande j'ai un doute profond sur ce que tu racontes. Si tu ne te sers pas de l'interpète python, il n'aboutira jamais dans la mémoire. Donc il ne s'agit là que d'économies de bout de chandelle.
Ne pas s'en servir, c'est ne pas lui donner de scripts à bouffer. Ça n'empêche probablement pas le programme qui est lié avec de lancer son initialisation au début, et donc effectivement de charger une grande partie de la bibliothèque partagée.
Nicolas Le Scouarnec
Mais obsolete... Sérieusement, c'est surement une très bonne distrib, mais c'est dommage de ne pas avoir tous les logiciels clignotant dernier cri quand on l'installe sur un poste utilisateur ou finalement on attache un petit peu moins d'importance a la stabilité éprouvée. Zut, alors je n'aurais pas les machins clignotants dernier cri ? J'avais pas
remarqué.
Ca dépend, a tu choisis la voie de la raison en suivant unstable ou testing ? En meme temps, je dis ca et j'utilise Mutt, Slrn, Irssi, des trucs bien pas flashy du tout... Par contre, déja que sous FreeBSD, je les trouve lent quand j'ai besoin d'un truc flashy (Java, Eclipse, Firefox,...).
Par contre chose désagréable sous Gentoo et FreeBSD, parfois les incompatiblités sur les mises a jour ne sont pas connues, et tu mets a jour une librairie et un logiciel ne veut plus marcher... Faut attendre.
-- Nicolas Le Scouarnec
Mais obsolete... Sérieusement, c'est surement une très bonne distrib,
mais c'est dommage de ne pas avoir tous les logiciels clignotant
dernier cri quand on l'installe sur un poste utilisateur ou finalement
on attache un petit peu moins d'importance a la stabilité éprouvée.
Zut, alors je n'aurais pas les machins clignotants dernier cri ? J'avais pas
remarqué.
Ca dépend, a tu choisis la voie de la raison en suivant unstable ou
testing ? En meme temps, je dis ca et j'utilise Mutt, Slrn, Irssi, des
trucs bien pas flashy du tout... Par contre, déja que sous FreeBSD, je
les trouve lent quand j'ai besoin d'un truc flashy (Java, Eclipse,
Firefox,...).
Par contre chose désagréable sous Gentoo et FreeBSD, parfois les
incompatiblités sur les mises a jour ne sont pas connues, et tu mets a
jour une librairie et un logiciel ne veut plus marcher... Faut
attendre.
Mais obsolete... Sérieusement, c'est surement une très bonne distrib, mais c'est dommage de ne pas avoir tous les logiciels clignotant dernier cri quand on l'installe sur un poste utilisateur ou finalement on attache un petit peu moins d'importance a la stabilité éprouvée. Zut, alors je n'aurais pas les machins clignotants dernier cri ? J'avais pas
remarqué.
Ca dépend, a tu choisis la voie de la raison en suivant unstable ou testing ? En meme temps, je dis ca et j'utilise Mutt, Slrn, Irssi, des trucs bien pas flashy du tout... Par contre, déja que sous FreeBSD, je les trouve lent quand j'ai besoin d'un truc flashy (Java, Eclipse, Firefox,...).
Par contre chose désagréable sous Gentoo et FreeBSD, parfois les incompatiblités sur les mises a jour ne sont pas connues, et tu mets a jour une librairie et un logiciel ne veut plus marcher... Faut attendre.
-- Nicolas Le Scouarnec
Lionel GRUHN
Jérémy JUST wrote:
Oui, c'est plutôt de cet ordre. Alors passer plusieurs jours de compilation pour gagner l'équivalent de quelques secondes par jour, c'est pas un argument valable. Il faut quand même penser que pour une utilisation courante, les machines actuelles n'utilisent même pas un quart de leur capacité de calcul (et encore, je suis généreux!).
Et la partie non quantifiable que représente le fait de bâtir peu à peu une distrib avec ce que tu veux (et que ce que tu veux) et de saisir un peu mieux comment tout est architecturé?
Que ma gentoo tourne un peu plus vite que la mandrake que j'utilisais avant, dans l'absolu, je m'en fiche un peu: j'ai pris le temps de choisir et d'installer les programmes que je voulais, de les configurer tranquillement, un par un, sans avoir de surprise...
Et je me suis régalé.
J'avoue que je ne me serais jamais lancé si je n'avais pas eu à coté une distrib qui fonctionnait déjà ;-)
Lionel
Jérémy JUST wrote:
Oui, c'est plutôt de cet ordre. Alors passer plusieurs jours de
compilation pour gagner l'équivalent de quelques secondes par jour,
c'est pas un argument valable.
Il faut quand même penser que pour une utilisation courante, les
machines actuelles n'utilisent même pas un quart de leur capacité de
calcul (et encore, je suis généreux!).
Et la partie non quantifiable que représente le fait de bâtir peu à peu une
distrib avec ce que tu veux (et que ce que tu veux) et de saisir un peu
mieux comment tout est architecturé?
Que ma gentoo tourne un peu plus vite que la mandrake que j'utilisais avant,
dans l'absolu, je m'en fiche un peu: j'ai pris le temps de choisir et
d'installer les programmes que je voulais, de les configurer
tranquillement, un par un, sans avoir de surprise...
Et je me suis régalé.
J'avoue que je ne me serais jamais lancé si je n'avais pas eu à coté une
distrib qui fonctionnait déjà ;-)
Oui, c'est plutôt de cet ordre. Alors passer plusieurs jours de compilation pour gagner l'équivalent de quelques secondes par jour, c'est pas un argument valable. Il faut quand même penser que pour une utilisation courante, les machines actuelles n'utilisent même pas un quart de leur capacité de calcul (et encore, je suis généreux!).
Et la partie non quantifiable que représente le fait de bâtir peu à peu une distrib avec ce que tu veux (et que ce que tu veux) et de saisir un peu mieux comment tout est architecturé?
Que ma gentoo tourne un peu plus vite que la mandrake que j'utilisais avant, dans l'absolu, je m'en fiche un peu: j'ai pris le temps de choisir et d'installer les programmes que je voulais, de les configurer tranquillement, un par un, sans avoir de surprise...
Et je me suis régalé.
J'avoue que je ne me serais jamais lancé si je n'avais pas eu à coté une distrib qui fonctionnait déjà ;-)
Lionel
talon
Nicolas George <nicolas$ wrote:
Michel Talon, dans le message <cstoe0$20t3$, a écrit :
Vu le principe de la pagination à la demande j'ai un doute profond sur ce que tu racontes. Si tu ne te sers pas de l'interpète python, il n'aboutira jamais dans la mémoire. Donc il ne s'agit là que d'économies de bout de chandelle.
Ne pas s'en servir, c'est ne pas lui donner de scripts à bouffer. Ça n'empêche probablement pas le programme qui est lié avec de lancer son initialisation au début, et donc effectivement de charger une grande partie de la bibliothèque partagée.
Je ne vois pas pourquoi il chargerait plus que quelques pages de la bibliothèque partagée, qui seront probablement trés rapidement recyclées en pages libres au besoin si elles ne sont pas utilisées.
--
Michel TALON
Nicolas George <nicolas$george@salle-s.org> wrote:
Michel Talon, dans le message <cstoe0$20t3$1@asmodee.lpthe.jussieu.fr>,
a écrit :
Vu le principe de la pagination à la demande j'ai un doute profond sur ce que
tu racontes. Si tu ne te sers pas de l'interpète python, il n'aboutira jamais
dans la mémoire. Donc il ne s'agit là que d'économies de bout de chandelle.
Ne pas s'en servir, c'est ne pas lui donner de scripts à bouffer. Ça
n'empêche probablement pas le programme qui est lié avec de lancer son
initialisation au début, et donc effectivement de charger une grande partie
de la bibliothèque partagée.
Je ne vois pas pourquoi il chargerait plus que quelques pages de la
bibliothèque partagée, qui seront probablement trés rapidement recyclées
en pages libres au besoin si elles ne sont pas utilisées.
Michel Talon, dans le message <cstoe0$20t3$, a écrit :
Vu le principe de la pagination à la demande j'ai un doute profond sur ce que tu racontes. Si tu ne te sers pas de l'interpète python, il n'aboutira jamais dans la mémoire. Donc il ne s'agit là que d'économies de bout de chandelle.
Ne pas s'en servir, c'est ne pas lui donner de scripts à bouffer. Ça n'empêche probablement pas le programme qui est lié avec de lancer son initialisation au début, et donc effectivement de charger une grande partie de la bibliothèque partagée.
Je ne vois pas pourquoi il chargerait plus que quelques pages de la bibliothèque partagée, qui seront probablement trés rapidement recyclées en pages libres au besoin si elles ne sont pas utilisées.
--
Michel TALON
Nicolas George
Michel Talon, dans le message <csu8hf$250d$, a écrit :
Je ne vois pas pourquoi il chargerait plus que quelques pages de la bibliothèque partagée,
Une bibliothèque de la complexité d'un interpréteur, ça a tendance à avoir une initialisation lourde, qui va aller trifouiller un peu partout dans les fonctions de la bibliothèque : sous-système d'entrée-sortie, sous-système d'allocation mémoire, parseur, état des variables, etc.
qui seront probablement trés rapidement recyclées en pages libres au besoin si elles ne sont pas utilisées.
En attendant ça a pris du temps, et ça a dégagé des trucs du cache disque.
Michel Talon, dans le message <csu8hf$250d$3@asmodee.lpthe.jussieu.fr>,
a écrit :
Je ne vois pas pourquoi il chargerait plus que quelques pages de la
bibliothèque partagée,
Une bibliothèque de la complexité d'un interpréteur, ça a tendance à avoir
une initialisation lourde, qui va aller trifouiller un peu partout dans les
fonctions de la bibliothèque : sous-système d'entrée-sortie, sous-système
d'allocation mémoire, parseur, état des variables, etc.
qui seront probablement trés rapidement recyclées
en pages libres au besoin si elles ne sont pas utilisées.
En attendant ça a pris du temps, et ça a dégagé des trucs du cache disque.
Michel Talon, dans le message <csu8hf$250d$, a écrit :
Je ne vois pas pourquoi il chargerait plus que quelques pages de la bibliothèque partagée,
Une bibliothèque de la complexité d'un interpréteur, ça a tendance à avoir une initialisation lourde, qui va aller trifouiller un peu partout dans les fonctions de la bibliothèque : sous-système d'entrée-sortie, sous-système d'allocation mémoire, parseur, état des variables, etc.
qui seront probablement trés rapidement recyclées en pages libres au besoin si elles ne sont pas utilisées.
En attendant ça a pris du temps, et ça a dégagé des trucs du cache disque.
