Bonjour,
Question certainement naïve d'un néophyte complet, vous voudrez bien m'en
excuser.
Il y a quelques années, j'avais essayé quelques distributions de Linux, plus
par curiosité que par nécessité. Mais j'ai été rebuté par le côté
"bricolage". La philosophie de l'époque était qu'il fallait mettre les mains
dans le cambouis pour arriver a faire ce qu'on voulait et en particulier à
gérer ses périphériques.
Il semble que les choses ont bien évolué, c'est en tout cas ce qu'on entend
un peu partout. Peut-on aujourd'hui affirmer que Linux est aussi simple et
convivial que XP pour un profane? Si c'est le cas, je me lance de suite. Et
quelle distribution conseillez-vous à un débutant ?
Merci pour vos lumières.
Phil
On Fri, 25 Nov 2005 01:15:21 -0800, Laurent wrote:
GNU/Linux *deviens* une usine à gaz
Et? quelle est la limite entre usine à gaz et pas usine à gaz? Les processeurs sont aussi de plus en plus puissants, les barettes de RAM et les disques sont aussi de plus en plus "volumineux" et rapides d'acc ès.
La limite est franchie lorsque l'on voit les dizaines de dépendances nécessaires pour faire fonctionner certains outils ne faisant que quelques tâches bien précises. Tout ça parce que le dev c'est dit "Cool cette fonction existe déjà dans tel logiciel, je vais donc m'en servir au lieu de recoder 30 lignes de C". Ben moi entre la taille et la vitesse d'éxecution de 30 lignes de C dans l'outil lui-même et 15Mo de dépendances se chargeant en mémoire, ma préférence est vite réglée, quand bien même j'aie un Athlon64 et 1Go de RAM.
Enfin c'est comme ça que je le vois.
-- Laurent
On Fri, 25 Nov 2005 01:15:21 -0800, Laurent wrote:
GNU/Linux *deviens* une usine à gaz
Et? quelle est la limite entre usine à gaz et pas usine à gaz?
Les processeurs sont aussi de plus en plus puissants, les barettes de RAM
et les disques sont aussi de plus en plus "volumineux" et rapides d'acc ès.
La limite est franchie lorsque l'on voit les dizaines de dépendances
nécessaires pour faire fonctionner certains outils ne faisant que
quelques tâches bien précises. Tout ça parce que le dev c'est dit
"Cool cette fonction existe déjà dans tel logiciel, je vais donc m'en
servir au lieu de recoder 30 lignes de C". Ben moi entre la taille et
la vitesse d'éxecution de 30 lignes de C dans l'outil lui-même et
15Mo de dépendances se chargeant en mémoire, ma préférence est vite
réglée, quand bien même j'aie un Athlon64 et 1Go de RAM.
On Fri, 25 Nov 2005 01:15:21 -0800, Laurent wrote:
GNU/Linux *deviens* une usine à gaz
Et? quelle est la limite entre usine à gaz et pas usine à gaz? Les processeurs sont aussi de plus en plus puissants, les barettes de RAM et les disques sont aussi de plus en plus "volumineux" et rapides d'acc ès.
La limite est franchie lorsque l'on voit les dizaines de dépendances nécessaires pour faire fonctionner certains outils ne faisant que quelques tâches bien précises. Tout ça parce que le dev c'est dit "Cool cette fonction existe déjà dans tel logiciel, je vais donc m'en servir au lieu de recoder 30 lignes de C". Ben moi entre la taille et la vitesse d'éxecution de 30 lignes de C dans l'outil lui-même et 15Mo de dépendances se chargeant en mémoire, ma préférence est vite réglée, quand bien même j'aie un Athlon64 et 1Go de RAM.
Enfin c'est comme ça que je le vois.
-- Laurent
talon
R12y wrote:
Ok, je suis d'accord avec toi pour le vrai SMP physique: il faut un compilateur capable l'exploiter et produire des binaires en conséquence. Est-ce aussi valable pour les dual core? Ils sont quand même vus comme du
Oui c'est exactement pareil que du SMP.
SMP? Les fabricants de chipsets en tout genre n'ont pas trouvé le moyen de rendre le SMP transparent pour l'OS/appli et de répartir lui-même les tache entre les deux (ou plus) coeurs?
Tu ne veux quand même pas que l'OS intervienne toutes les 10 instructions assembleur de ton programme! Au lieu d'accélération c'est un sacré coup de frein que ça donnerait. Non c'est le compilateur (ou l'auteur du programme) qui doit paralléléliser. Un exemple le compilateur Intel le fait. Je crois que gcc4 le fait aussi. De plus en plus de programmes sont programmés en multithread, par exemple firefox, openOffice, etc. Donc ils bénéficient d'un dual core.
Ok, je suis d'accord avec toi pour le vrai SMP physique: il faut un
compilateur capable l'exploiter et produire des binaires en conséquence.
Est-ce aussi valable pour les dual core? Ils sont quand même vus comme du
Oui c'est exactement pareil que du SMP.
SMP? Les fabricants de chipsets en tout genre n'ont pas trouvé le moyen de
rendre le SMP transparent pour l'OS/appli et de répartir lui-même les
tache entre les deux (ou plus) coeurs?
Tu ne veux quand même pas que l'OS intervienne toutes les 10 instructions
assembleur de ton programme! Au lieu d'accélération c'est un sacré coup de
frein que ça donnerait. Non c'est le compilateur (ou l'auteur du programme) qui
doit paralléléliser. Un exemple le compilateur Intel le fait. Je crois que
gcc4 le fait aussi. De plus en plus de programmes sont programmés en
multithread, par exemple firefox, openOffice, etc. Donc ils bénéficient d'un
dual core.
Ok, je suis d'accord avec toi pour le vrai SMP physique: il faut un compilateur capable l'exploiter et produire des binaires en conséquence. Est-ce aussi valable pour les dual core? Ils sont quand même vus comme du
Oui c'est exactement pareil que du SMP.
SMP? Les fabricants de chipsets en tout genre n'ont pas trouvé le moyen de rendre le SMP transparent pour l'OS/appli et de répartir lui-même les tache entre les deux (ou plus) coeurs?
Tu ne veux quand même pas que l'OS intervienne toutes les 10 instructions assembleur de ton programme! Au lieu d'accélération c'est un sacré coup de frein que ça donnerait. Non c'est le compilateur (ou l'auteur du programme) qui doit paralléléliser. Un exemple le compilateur Intel le fait. Je crois que gcc4 le fait aussi. De plus en plus de programmes sont programmés en multithread, par exemple firefox, openOffice, etc. Donc ils bénéficient d'un dual core.
--
Michel TALON
talon
Laurent wrote:
On Fri, 25 Nov 2005 01:15:21 -0800, Laurent wrote:
GNU/Linux *deviens* une usine à gaz
Et? quelle est la limite entre usine à gaz et pas usine à gaz? Les processeurs sont aussi de plus en plus puissants, les barettes de RAM et les disques sont aussi de plus en plus "volumineux" et rapides d'accès.
La limite est franchie lorsque l'on voit les dizaines de dépendances nécessaires pour faire fonctionner certains outils ne faisant que quelques tâches bien précises. Tout ça parce que le dev c'est dit "Cool cette fonction existe déjà dans tel logiciel, je vais donc m'en servir au lieu de recoder 30 lignes de C". Ben moi entre la taille et
C'est ce qui s'appelle ne pas réinventer la roue et a pour bénéfice: -que la fonction peut être bien débugguée et optimisée -qu'elle peut figurer dans une librairie partagée qui est utilisée par plusieurs programmes, etc.
la vitesse d'éxecution de 30 lignes de C dans l'outil lui-même et 15Mo de dépendances se chargeant en mémoire, ma préférence est vite réglée, quand bien même j'aie un Athlon64 et 1Go de RAM.
Enfin c'est comme ça que je le vois.
-- Laurent
Laurent <laurent.bar@gmail.com> wrote:
On Fri, 25 Nov 2005 01:15:21 -0800, Laurent wrote:
GNU/Linux *deviens* une usine à gaz
Et? quelle est la limite entre usine à gaz et pas usine à gaz?
Les processeurs sont aussi de plus en plus puissants, les barettes de RAM
et les disques sont aussi de plus en plus "volumineux" et rapides d'accès.
La limite est franchie lorsque l'on voit les dizaines de dépendances
nécessaires pour faire fonctionner certains outils ne faisant que
quelques tâches bien précises. Tout ça parce que le dev c'est dit
"Cool cette fonction existe déjà dans tel logiciel, je vais donc m'en
servir au lieu de recoder 30 lignes de C". Ben moi entre la taille et
C'est ce qui s'appelle ne pas réinventer la roue et a pour bénéfice:
-que la fonction peut être bien débugguée et optimisée
-qu'elle peut figurer dans une librairie partagée qui est utilisée par
plusieurs programmes, etc.
la vitesse d'éxecution de 30 lignes de C dans l'outil lui-même et
15Mo de dépendances se chargeant en mémoire, ma préférence est vite
réglée, quand bien même j'aie un Athlon64 et 1Go de RAM.
On Fri, 25 Nov 2005 01:15:21 -0800, Laurent wrote:
GNU/Linux *deviens* une usine à gaz
Et? quelle est la limite entre usine à gaz et pas usine à gaz? Les processeurs sont aussi de plus en plus puissants, les barettes de RAM et les disques sont aussi de plus en plus "volumineux" et rapides d'accès.
La limite est franchie lorsque l'on voit les dizaines de dépendances nécessaires pour faire fonctionner certains outils ne faisant que quelques tâches bien précises. Tout ça parce que le dev c'est dit "Cool cette fonction existe déjà dans tel logiciel, je vais donc m'en servir au lieu de recoder 30 lignes de C". Ben moi entre la taille et
C'est ce qui s'appelle ne pas réinventer la roue et a pour bénéfice: -que la fonction peut être bien débugguée et optimisée -qu'elle peut figurer dans une librairie partagée qui est utilisée par plusieurs programmes, etc.
la vitesse d'éxecution de 30 lignes de C dans l'outil lui-même et 15Mo de dépendances se chargeant en mémoire, ma préférence est vite réglée, quand bien même j'aie un Athlon64 et 1Go de RAM.
Enfin c'est comme ça que je le vois.
-- Laurent
jvcharles
essais ubuntu, ubuntu, ubuntu
une fois installé t'apprend vite à faire des copie collé du moin au début.
ubuntu, ubuntu, ubuntu, c'est à plus 95% cliquodrome et libre 100%
xp simple et convivial, mdrrrrrrrrr, tu connait pas les 1001 programmes pour maintenir sa tête or de l'eau
pour tous ce qui commence par mandri et fini par dow$, pas pour moi
essais ubuntu, kubuntu, ubuntu
essais ubuntu, ubuntu, ubuntu
une fois installé t'apprend vite à faire des copie collé du moin au début.
ubuntu, ubuntu, ubuntu, c'est à plus 95% cliquodrome et libre 100%
xp simple et convivial, mdrrrrrrrrr, tu connait pas les 1001 programmes
pour maintenir sa tête or de l'eau
pour tous ce qui commence par mandri et fini par dow$, pas pour moi
une fois installé t'apprend vite à faire des copie collé du moin au début.
ubuntu, ubuntu, ubuntu, c'est à plus 95% cliquodrome et libre 100%
xp simple et convivial, mdrrrrrrrrr, tu connait pas les 1001 programmes pour maintenir sa tête or de l'eau
pour tous ce qui commence par mandri et fini par dow$, pas pour moi
essais ubuntu, kubuntu, ubuntu
Nicolas George
"Laurent" , dans le message , a écrit :
Tout ça parce que le dev c'est dit "Cool cette fonction existe déjà dans tel logiciel, je vais donc m'en servir au lieu de recoder 30 lignes de C". Ben moi entre la taille et la vitesse d'éxecution de 30 lignes de C dans l'outil lui-même et 15Mo de dépendances se chargeant en mémoire, ma préférence est vite réglée
Oui, évidemment, avec des chiffres aussi fantaisistes, c'est facile de conclure...
"Laurent" , dans le message
<1132923641.571899.144010@g43g2000cwa.googlegroups.com>, a écrit :
Tout ça parce que le dev c'est dit
"Cool cette fonction existe déjà dans tel logiciel, je vais donc m'en
servir au lieu de recoder 30 lignes de C". Ben moi entre la taille et
la vitesse d'éxecution de 30 lignes de C dans l'outil lui-même et
15Mo de dépendances se chargeant en mémoire, ma préférence est vite
réglée
Oui, évidemment, avec des chiffres aussi fantaisistes, c'est facile de
conclure...
Tout ça parce que le dev c'est dit "Cool cette fonction existe déjà dans tel logiciel, je vais donc m'en servir au lieu de recoder 30 lignes de C". Ben moi entre la taille et la vitesse d'éxecution de 30 lignes de C dans l'outil lui-même et 15Mo de dépendances se chargeant en mémoire, ma préférence est vite réglée
Oui, évidemment, avec des chiffres aussi fantaisistes, c'est facile de conclure...
Nicolas George
Michel Talon, dans le message <dm72ps$17lv$, a écrit :
Non c'est le compilateur (ou l'auteur du programme) qui doit paralléléliser.
Ou le processeur.
Michel Talon, dans le message <dm72ps$17lv$1@asmodee.lpthe.jussieu.fr>,
a écrit :
Non c'est le compilateur (ou l'auteur du
programme) qui doit paralléléliser.
Après tout, pourquoi s'emmerder à faire de la bureautique, alors qu'il y a des secrétaires dont c'est le métier,
c'est vrai ça... je vais demander à une secrétaire du lycée où je bosse de taper mes cours ;-)
Michel Billaud
"" writes:
Après tout, pourquoi s'emmerder à faire de la bureautique, alors qu'il y a des secrétaires dont c'est le métier,
c'est vrai ça... je vais demander à une secrétaire du lycée où je bosse de taper mes cours ;-)
C'est plus simple de les écrire à la main.
D'autres questions ?
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
"noone@nowhere.com" <noone@nowhere.com> writes:
Après tout, pourquoi s'emmerder à faire de la bureautique, alors qu'il
y a des secrétaires dont c'est le métier,
c'est vrai ça... je vais demander à une secrétaire du lycée où je bosse
de taper mes cours ;-)
C'est plus simple de les écrire à la main.
D'autres questions ?
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Après tout, pourquoi s'emmerder à faire de la bureautique, alors qu'il y a des secrétaires dont c'est le métier,
c'est vrai ça... je vais demander à une secrétaire du lycée où je bosse de taper mes cours ;-)
C'est plus simple de les écrire à la main.
D'autres questions ?
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
talon
Nicolas George <nicolas$ wrote:
Michel Talon, dans le message <dm72ps$17lv$, a écrit :
Non c'est le compilateur (ou l'auteur du programme) qui doit paralléléliser.
Ou le processeur.
En effet, j'avais oublié. C'est exactement ce que font les pentiums ou similaires.
--
Michel TALON
Nicolas George <nicolas$george@salle-s.org> wrote:
Michel Talon, dans le message <dm72ps$17lv$1@asmodee.lpthe.jussieu.fr>,
a écrit :
Non c'est le compilateur (ou l'auteur du
programme) qui doit paralléléliser.
Ou le processeur.
En effet, j'avais oublié. C'est exactement ce que font les pentiums ou
similaires.
Michel Talon, dans le message <dm72ps$17lv$, a écrit :
Non c'est le compilateur (ou l'auteur du programme) qui doit paralléléliser.
Ou le processeur.
En effet, j'avais oublié. C'est exactement ce que font les pentiums ou similaires.
--
Michel TALON
Laurent
Nicolas George wrote:
"Laurent" , dans le message
Tout ça parce que le dev c'est dit "Cool cette fonction existe déjà dans tel logiciel, je vais donc m'en servir au lieu de recoder 30 lignes de C". Ben moi entre la taille et la vitesse d'éxecution de 30 lignes de C dans l'outil lui-même et 15Mo de dépendances se chargeant en mémoire, ma préférence est vite réglée
Oui, évidemment, avec des chiffres aussi fantaisistes, c'est facile de conclure...
Je suis quelqu'un rempli de fantaisie -- Post powered by Pick and PickBasic
Nicolas George wrote:
"Laurent" , dans le message
Tout ça parce que le dev c'est dit
"Cool cette fonction existe déjà dans tel logiciel, je vais donc m'en
servir au lieu de recoder 30 lignes de C". Ben moi entre la taille et
la vitesse d'éxecution de 30 lignes de C dans l'outil lui-même et
15Mo de dépendances se chargeant en mémoire, ma préférence est vite
réglée
Oui, évidemment, avec des chiffres aussi fantaisistes, c'est facile de
conclure...
Je suis quelqu'un rempli de fantaisie
--
Post powered by Pick and PickBasic
Tout ça parce que le dev c'est dit "Cool cette fonction existe déjà dans tel logiciel, je vais donc m'en servir au lieu de recoder 30 lignes de C". Ben moi entre la taille et la vitesse d'éxecution de 30 lignes de C dans l'outil lui-même et 15Mo de dépendances se chargeant en mémoire, ma préférence est vite réglée
Oui, évidemment, avec des chiffres aussi fantaisistes, c'est facile de conclure...
Je suis quelqu'un rempli de fantaisie -- Post powered by Pick and PickBasic
