Je souhaite migrer des postes de travail Windows 2000 & XP, utilisant
Office, Outlook, etc .. vers une solution libre.
J'avais pensé à Ubuntu, open office, thunderbird, firefox, etc ...
Que me conseillez-vous.
Quels sont les pièges et écueils à éviter pour ceux qui en ont déjà fait
l'expérience. (je crois que dans les administrations ils ont passé le cap)
Est-il envisageable ensuite de migrer les serveurs (un domaine NT et qq
serveurs) vers le libre ?
Là aussi des conseils seraient les bienvenus : Samba et openLDAP peuvent-ils
faire l'affaire ?
OpenOffice peut-il remplacer Exchange ?
y a t'il des sites expliquant cela ?
Pour le reste (firewall, web, etc....) tout est déjà en linux évidemment
donc pas de pb.
mette pas des *heures* à compiler son programme. Par exemple si tu compiles KDE il faut t'attendre à des *jours* de compilation, c'est
Et tu vois un interet quelconque a compiler KDE ?
Il a aussi parlé de compiler MySQL, ce qui est encore plus étrange.
-- CHIRAC CHAHUTE A L'ASSEMBLEE pas confondre avec CHIRAC CHAHUTÉ À L'ASSEMBLÉE
talon
Thierry B. wrote:
--{ Stephane TOUGARD a plopé ceci: }--
>> mette pas des *heures* à compiler son programme. Par exemple si tu >> compiles KDE il faut t'attendre à des *jours* de compilation, c'est > > Et tu vois un interet quelconque a compiler KDE ?
Il a aussi parlé de compiler MySQL, ce qui est encore plus étrange.
Dans mon souvenir il y a un gros fichier en C++ là dedans qui met des plombes à compiler, et prend uen tonne de mémoire, mais peut être je confonds avec autre chose.
--
Michel TALON
Thierry B. <tth@prout.stex.invalid> wrote:
--{ Stephane TOUGARD a plopé ceci: }--
>> mette pas des *heures* à compiler son programme. Par exemple si tu
>> compiles KDE il faut t'attendre à des *jours* de compilation, c'est
>
> Et tu vois un interet quelconque a compiler KDE ?
Il a aussi parlé de compiler MySQL, ce qui est encore plus étrange.
Dans mon souvenir il y a un gros fichier en C++ là dedans qui met des
plombes à compiler, et prend uen tonne de mémoire, mais peut être je
confonds avec autre chose.
>> mette pas des *heures* à compiler son programme. Par exemple si tu >> compiles KDE il faut t'attendre à des *jours* de compilation, c'est > > Et tu vois un interet quelconque a compiler KDE ?
Il a aussi parlé de compiler MySQL, ce qui est encore plus étrange.
Dans mon souvenir il y a un gros fichier en C++ là dedans qui met des plombes à compiler, et prend uen tonne de mémoire, mais peut être je confonds avec autre chose.
--
Michel TALON
talon
Thierry B. wrote:
--{ Stephane TOUGARD a plopé ceci: }--
>> mette pas des *heures* à compiler son programme. Par exemple si tu >> compiles KDE il faut t'attendre à des *jours* de compilation, c'est > > Et tu vois un interet quelconque a compiler KDE ?
Il a aussi parlé de compiler MySQL, ce qui est encore plus étrange.
Dans mon souvenir il y a un gros fichier en C++ là dedans qui met des plombes à compiler, et prend uen tonne de mémoire, mais peut être je confonds avec autre chose. Ca pourrait être: " Si vous avez des problèmes lors de la compilation de sql_yacc.cc, comme ceux qui sont décrits ci-dessous, vous avez probablement été à court de mémoire ou d'espace de swap :
Internal compiler error: program cc1plus got fatal signal 11 Out of virtual memory Virtual memory exhausted
Le problème est que gcc requiert de grandes quantité de mémoire pour compiler sql_yacc.cc avec les options inline. "
--
Michel TALON
Thierry B. <tth@prout.stex.invalid> wrote:
--{ Stephane TOUGARD a plopé ceci: }--
>> mette pas des *heures* à compiler son programme. Par exemple si tu
>> compiles KDE il faut t'attendre à des *jours* de compilation, c'est
>
> Et tu vois un interet quelconque a compiler KDE ?
Il a aussi parlé de compiler MySQL, ce qui est encore plus étrange.
Dans mon souvenir il y a un gros fichier en C++ là dedans qui met des
plombes à compiler, et prend uen tonne de mémoire, mais peut être je
confonds avec autre chose.
Ca pourrait être:
"
Si vous avez des problèmes lors de la compilation de sql_yacc.cc, comme
ceux qui sont décrits ci-dessous, vous avez probablement été à court de
mémoire ou d'espace de swap :
Internal compiler error: program cc1plus got fatal signal 11
Out of virtual memory
Virtual memory exhausted
Le problème est que gcc requiert de grandes quantité de mémoire pour
compiler sql_yacc.cc avec les options inline.
"
>> mette pas des *heures* à compiler son programme. Par exemple si tu >> compiles KDE il faut t'attendre à des *jours* de compilation, c'est > > Et tu vois un interet quelconque a compiler KDE ?
Il a aussi parlé de compiler MySQL, ce qui est encore plus étrange.
Dans mon souvenir il y a un gros fichier en C++ là dedans qui met des plombes à compiler, et prend uen tonne de mémoire, mais peut être je confonds avec autre chose. Ca pourrait être: " Si vous avez des problèmes lors de la compilation de sql_yacc.cc, comme ceux qui sont décrits ci-dessous, vous avez probablement été à court de mémoire ou d'espace de swap :
Internal compiler error: program cc1plus got fatal signal 11 Out of virtual memory Virtual memory exhausted
Le problème est que gcc requiert de grandes quantité de mémoire pour compiler sql_yacc.cc avec les options inline. "
--
Michel TALON
Francois G
Thierry B. a écrit :
--{ a plopé ceci: }--
On en revient alors à ma question d'origine : pourquoi proposerait-il des chiffres ?
Pour nous éviter de troller dans le vide.
Le troll est-il le vide où le vide est-il le troll ?
Une histoire de fleurs bleues, surement.
-- FG
Thierry B. a écrit :
--{ gl@unix4fun.net a plopé ceci: }--
On en revient alors à ma question d'origine : pourquoi proposerait-il
des chiffres ?
Pour nous éviter de troller dans le vide.
Le troll est-il le vide où le vide est-il le troll ?
On en revient alors à ma question d'origine : pourquoi proposerait-il des chiffres ?
Pour nous éviter de troller dans le vide.
Le troll est-il le vide où le vide est-il le troll ?
On se vide dans le troll.
Stéphane CARPENTIER
wrote:
Donc je résume : même s'il exhibe des benches montrant la lenteur relative de g++, tu ne seras pas satisfait, c'est bien ça ? Puisque de toute façon, la vitesse de compilation n'est pas primordiale.
On en revient alors à ma question d'origine : pourquoi proposerait-il des chiffres ?
Pour savoir de quoi il parle. Gagner 5% de temps de compilation n'a pas le même intérêt de de gagner 95% de temps de compilation.
-- Stéphane
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
gl@unix4fun.net wrote:
Donc je résume :
même s'il exhibe des benches montrant la lenteur relative de g++, tu ne
seras pas satisfait, c'est bien ça ? Puisque de toute façon, la vitesse
de compilation n'est pas primordiale.
On en revient alors à ma question d'origine : pourquoi proposerait-il
des chiffres ?
Pour savoir de quoi il parle. Gagner 5% de temps de compilation n'a pas le
même intérêt de de gagner 95% de temps de compilation.
--
Stéphane
Pour me répondre, traduire gratuit en anglais et virer le .invalid.
http://stef.carpentier.free.fr/
Donc je résume : même s'il exhibe des benches montrant la lenteur relative de g++, tu ne seras pas satisfait, c'est bien ça ? Puisque de toute façon, la vitesse de compilation n'est pas primordiale.
On en revient alors à ma question d'origine : pourquoi proposerait-il des chiffres ?
Pour savoir de quoi il parle. Gagner 5% de temps de compilation n'a pas le même intérêt de de gagner 95% de temps de compilation.
-- Stéphane
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
Jerome Lambert
Stéphane CARPENTIER a écrit :
wrote:
Donc je résume : même s'il exhibe des benches montrant la lenteur relative de g++, tu ne seras pas satisfait, c'est bien ça ? Puisque de toute façon, la vitesse de compilation n'est pas primordiale.
On en revient alors à ma question d'origine : pourquoi proposerait-il des chiffres ?
Pour savoir de quoi il parle. Gagner 5% de temps de compilation n'a pas le même intérêt de de gagner 95% de temps de compilation.
Ça dépend de ton unité de temps: si c'est la seconde, 5% est insignifiant, si c'est l'heure ou le jour, ça peut amplement valoir la peine.
Stéphane CARPENTIER a écrit :
gl@unix4fun.net wrote:
Donc je résume :
même s'il exhibe des benches montrant la lenteur relative de g++, tu ne
seras pas satisfait, c'est bien ça ? Puisque de toute façon, la vitesse
de compilation n'est pas primordiale.
On en revient alors à ma question d'origine : pourquoi proposerait-il
des chiffres ?
Pour savoir de quoi il parle. Gagner 5% de temps de compilation n'a pas le
même intérêt de de gagner 95% de temps de compilation.
Ça dépend de ton unité de temps: si c'est la seconde, 5% est
insignifiant, si c'est l'heure ou le jour, ça peut amplement valoir la
peine.
Donc je résume : même s'il exhibe des benches montrant la lenteur relative de g++, tu ne seras pas satisfait, c'est bien ça ? Puisque de toute façon, la vitesse de compilation n'est pas primordiale.
On en revient alors à ma question d'origine : pourquoi proposerait-il des chiffres ?
Pour savoir de quoi il parle. Gagner 5% de temps de compilation n'a pas le même intérêt de de gagner 95% de temps de compilation.
Ça dépend de ton unité de temps: si c'est la seconde, 5% est insignifiant, si c'est l'heure ou le jour, ça peut amplement valoir la peine.
gl
On 2008-12-02, Jerome Lambert wrote:
Stéphane CARPENTIER a écrit :
wrote:
Donc je résume : même s'il exhibe des benches montrant la lenteur relative de g++, tu ne seras pas satisfait, c'est bien ça ? Puisque de toute façon, la vitesse de compilation n'est pas primordiale.
On en revient alors à ma question d'origine : pourquoi proposerait-il des chiffres ?
Pour savoir de quoi il parle. Gagner 5% de temps de compilation n'a pas le même intérêt de de gagner 95% de temps de compilation.
Ça dépend de ton unité de temps: si c'est la seconde, 5% est insignifiant, si c'est l'heure ou le jour, ça peut amplement valoir la peine.
Tu ne saisis pas. Ici, on ne peut pas répondre à la question suivante : "je trouve le programme XXX lent, pouvez-vous m'indiquer un programme qui fasse la même chose, en plus rapide ?".
Plutôt que de répondre "Je connais YYY, qui est plus rapide, mais il a tel ou tel inconvénient", ou bien "Tous ces programmes sont sensiblement aussi rapides", etc, il faut y aller de sa question inutile, c'est comme ça. Il faut que le PO fournisse un bench détaillé de la lenteur qu'il attribue à XXX, et par rapport à un maximum d'alternatives. Il est idiot de faire part d'une impression quant à la rapidité d'un logiciel, franchement.
Et puis d'ailleurs, c'est crétin de poser une question pareille, puisque comme tu dois fournir des benches très précis pour étayer tes propos, tu as la réponse à ta question, puisque tu sais quels programmes sont plus rapides que XXX.
Pfff, vraiment, quels cons ces gens qui n'ont pas la science infuse et/ou qui posent une question sans s'être renseignés à fond au préalable.
-- "I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tanhauser gate. All those moments will be lost in time like tears in rain. Time to die."
On 2008-12-02, Jerome Lambert <jerome.lambert@swing.be> wrote:
Stéphane CARPENTIER a écrit :
gl@unix4fun.net wrote:
Donc je résume :
même s'il exhibe des benches montrant la lenteur relative de g++, tu ne
seras pas satisfait, c'est bien ça ? Puisque de toute façon, la vitesse
de compilation n'est pas primordiale.
On en revient alors à ma question d'origine : pourquoi proposerait-il
des chiffres ?
Pour savoir de quoi il parle. Gagner 5% de temps de compilation n'a pas le
même intérêt de de gagner 95% de temps de compilation.
Ça dépend de ton unité de temps: si c'est la seconde, 5% est
insignifiant, si c'est l'heure ou le jour, ça peut amplement valoir la
peine.
Tu ne saisis pas. Ici, on ne peut pas répondre à la question suivante :
"je trouve le programme XXX lent, pouvez-vous m'indiquer un programme qui
fasse la même chose, en plus rapide ?".
Plutôt que de répondre "Je connais YYY, qui est plus rapide, mais il a
tel ou tel inconvénient", ou bien "Tous ces programmes sont sensiblement
aussi rapides", etc, il faut y aller de sa question inutile, c'est comme
ça. Il faut que le PO fournisse un bench détaillé de la lenteur qu'il
attribue à XXX, et par rapport à un maximum d'alternatives. Il est idiot
de faire part d'une impression quant à la rapidité d'un logiciel,
franchement.
Et puis d'ailleurs, c'est crétin de poser une question pareille, puisque
comme tu dois fournir des benches très précis pour étayer tes propos, tu
as la réponse à ta question, puisque tu sais quels programmes sont plus
rapides que XXX.
Pfff, vraiment, quels cons ces gens qui n'ont pas la science infuse
et/ou qui posent une question sans s'être renseignés à fond au
préalable.
--
"I've seen things you people wouldn't believe. Attack ships on fire
off the shoulder of Orion. I watched C-beams glitter in the dark near
the Tanhauser gate. All those moments will be lost in time like tears
in rain. Time to die."
Donc je résume : même s'il exhibe des benches montrant la lenteur relative de g++, tu ne seras pas satisfait, c'est bien ça ? Puisque de toute façon, la vitesse de compilation n'est pas primordiale.
On en revient alors à ma question d'origine : pourquoi proposerait-il des chiffres ?
Pour savoir de quoi il parle. Gagner 5% de temps de compilation n'a pas le même intérêt de de gagner 95% de temps de compilation.
Ça dépend de ton unité de temps: si c'est la seconde, 5% est insignifiant, si c'est l'heure ou le jour, ça peut amplement valoir la peine.
Tu ne saisis pas. Ici, on ne peut pas répondre à la question suivante : "je trouve le programme XXX lent, pouvez-vous m'indiquer un programme qui fasse la même chose, en plus rapide ?".
Plutôt que de répondre "Je connais YYY, qui est plus rapide, mais il a tel ou tel inconvénient", ou bien "Tous ces programmes sont sensiblement aussi rapides", etc, il faut y aller de sa question inutile, c'est comme ça. Il faut que le PO fournisse un bench détaillé de la lenteur qu'il attribue à XXX, et par rapport à un maximum d'alternatives. Il est idiot de faire part d'une impression quant à la rapidité d'un logiciel, franchement.
Et puis d'ailleurs, c'est crétin de poser une question pareille, puisque comme tu dois fournir des benches très précis pour étayer tes propos, tu as la réponse à ta question, puisque tu sais quels programmes sont plus rapides que XXX.
Pfff, vraiment, quels cons ces gens qui n'ont pas la science infuse et/ou qui posent une question sans s'être renseignés à fond au préalable.
-- "I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tanhauser gate. All those moments will be lost in time like tears in rain. Time to die."
nicolas vigier
On 2008-12-02, wrote:
Tu ne saisis pas. Ici, on ne peut pas répondre à la question suivante : "je trouve le programme XXX lent, pouvez-vous m'indiquer un programme qui fasse la même chose, en plus rapide ?".
Plutôt que de répondre "Je connais YYY, qui est plus rapide, mais il a tel ou tel inconvénient", ou bien "Tous ces programmes sont sensiblement aussi rapides", etc, il faut y aller de sa question inutile, c'est comme ça. Il faut que le PO fournisse un bench détaillé de la lenteur qu'il attribue à XXX, et par rapport à un maximum d'alternatives. Il est idiot de faire part d'une impression quant à la rapidité d'un logiciel, franchement.
Et puis d'ailleurs, c'est crétin de poser une question pareille, puisque comme tu dois fournir des benches très précis pour étayer tes propos, tu as la réponse à ta question, puisque tu sais quels programmes sont plus rapides que XXX.
Pfff, vraiment, quels cons ces gens qui n'ont pas la science infuse et/ou qui posent une question sans s'être renseignés à fond au préalable.
Il lui a été conseillé d'essaier avec le compilateur d'Intel. Tu veux quoi de plus ? Après, lui demander ce qu'il veut dire par lent ca me semble normal aussi, et assez simple à répondre. Faut pas espérer avoir une réponse un peu détaillée en refusant de donner un minimum de details sur le problème.
On 2008-12-02, gl@unix4fun.net <gl@unix4fun.net> wrote:
Tu ne saisis pas. Ici, on ne peut pas répondre à la question suivante :
"je trouve le programme XXX lent, pouvez-vous m'indiquer un programme qui
fasse la même chose, en plus rapide ?".
Plutôt que de répondre "Je connais YYY, qui est plus rapide, mais il a
tel ou tel inconvénient", ou bien "Tous ces programmes sont sensiblement
aussi rapides", etc, il faut y aller de sa question inutile, c'est comme
ça. Il faut que le PO fournisse un bench détaillé de la lenteur qu'il
attribue à XXX, et par rapport à un maximum d'alternatives. Il est idiot
de faire part d'une impression quant à la rapidité d'un logiciel,
franchement.
Et puis d'ailleurs, c'est crétin de poser une question pareille, puisque
comme tu dois fournir des benches très précis pour étayer tes propos, tu
as la réponse à ta question, puisque tu sais quels programmes sont plus
rapides que XXX.
Pfff, vraiment, quels cons ces gens qui n'ont pas la science infuse
et/ou qui posent une question sans s'être renseignés à fond au
préalable.
Il lui a été conseillé d'essaier avec le compilateur d'Intel. Tu veux
quoi de plus ? Après, lui demander ce qu'il veut dire par lent ca me
semble normal aussi, et assez simple à répondre. Faut pas espérer avoir
une réponse un peu détaillée en refusant de donner un minimum de details
sur le problème.
Tu ne saisis pas. Ici, on ne peut pas répondre à la question suivante : "je trouve le programme XXX lent, pouvez-vous m'indiquer un programme qui fasse la même chose, en plus rapide ?".
Plutôt que de répondre "Je connais YYY, qui est plus rapide, mais il a tel ou tel inconvénient", ou bien "Tous ces programmes sont sensiblement aussi rapides", etc, il faut y aller de sa question inutile, c'est comme ça. Il faut que le PO fournisse un bench détaillé de la lenteur qu'il attribue à XXX, et par rapport à un maximum d'alternatives. Il est idiot de faire part d'une impression quant à la rapidité d'un logiciel, franchement.
Et puis d'ailleurs, c'est crétin de poser une question pareille, puisque comme tu dois fournir des benches très précis pour étayer tes propos, tu as la réponse à ta question, puisque tu sais quels programmes sont plus rapides que XXX.
Pfff, vraiment, quels cons ces gens qui n'ont pas la science infuse et/ou qui posent une question sans s'être renseignés à fond au préalable.
Il lui a été conseillé d'essaier avec le compilateur d'Intel. Tu veux quoi de plus ? Après, lui demander ce qu'il veut dire par lent ca me semble normal aussi, et assez simple à répondre. Faut pas espérer avoir une réponse un peu détaillée en refusant de donner un minimum de details sur le problème.
