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.
Et cette solution à quelque chose d'autre de remarquable : ça répond à sa question.
Et depuis quand on est cense repondre aux questions techniques sur fcold ?
C'est quand meme un peu carrement hors sujet.
Manuel Leclerc
Stephane TOUGARD a écrit :
Tu connais un developpeur qui va plus vite qu'un compilo C++ quand le Makefile est bon ?
Moi je connais pas, desole.
Moi, des fois j'ai la femme de sauter sur l'erreur de compilation suivante, je lance un build après correction de la première, et je me retrouve sur la deuxième. Avec les headers précompilés, la compilation incrémentale, et l'édition de lien incrémentale aussi, c'est presque instantané, même pour de grosses DLLs.
Donc je ne suis pas un "développeur", je suppose :-)
--
Why did you replace `%ll' by `%L'?
Because it's one byte shorter. --Jan Beulich
Stephane TOUGARD a écrit :
Tu connais un developpeur qui va plus vite qu'un
compilo C++ quand le Makefile est bon ?
Moi je connais pas, desole.
Moi, des fois j'ai la femme de sauter sur l'erreur
de compilation suivante, je lance un build après
correction de la première, et je me retrouve sur la
deuxième. Avec les headers précompilés, la compilation
incrémentale, et l'édition de lien incrémentale aussi,
c'est presque instantané, même pour de grosses DLLs.
Donc je ne suis pas un "développeur", je suppose :-)
Tu connais un developpeur qui va plus vite qu'un compilo C++ quand le Makefile est bon ?
Moi je connais pas, desole.
Moi, des fois j'ai la femme de sauter sur l'erreur de compilation suivante, je lance un build après correction de la première, et je me retrouve sur la deuxième. Avec les headers précompilés, la compilation incrémentale, et l'édition de lien incrémentale aussi, c'est presque instantané, même pour de grosses DLLs.
Donc je ne suis pas un "développeur", je suppose :-)
--
Why did you replace `%ll' by `%L'?
Because it's one byte shorter. --Jan Beulich
Thierry B.
--{ Fabien LE LEZ a plopé ceci: }--
Un bon Makefile fait que seul les parties vraiment modifiees sont re-compilees.
Ce qui fait déjà beaucoup (avec un seul .cpp, g++ commence déjà à patiner).
C'est la faute à Gcc ou c'est la faute à c++ ?
Sans compter le temps passé à maintenir le Makefile.
Temps qui n'est jamais perdu. Avoir un bon système de "build" est une chose _vitale_ dès que l'on dépasse plus de trois fichiers source. Perdre plusieurs heures parce que le machin ne voit pas toutes les dépendances, c'est vraiment énervant.
-- { SIGAREDECUBA, "HAVANE" }, /* Instructs the process to share resources and to hate USA. Kill * remains the dictator, though */ --{ f.m.b.l revisite la command kill }--
--{ Fabien LE LEZ a plopé ceci: }--
Un bon Makefile fait que seul les parties vraiment modifiees sont
re-compilees.
Ce qui fait déjà beaucoup (avec un seul .cpp, g++ commence déjà à
patiner).
C'est la faute à Gcc ou c'est la faute à c++ ?
Sans compter le temps passé à maintenir le Makefile.
Temps qui n'est jamais perdu. Avoir un bon système de "build"
est une chose _vitale_ dès que l'on dépasse plus de trois
fichiers source. Perdre plusieurs heures parce que le machin
ne voit pas toutes les dépendances, c'est vraiment énervant.
--
{ SIGAREDECUBA, "HAVANE" },
/* Instructs the process to share resources and to hate USA. Kill
* remains the dictator, though */
--{ f.m.b.l revisite la command kill }--
Un bon Makefile fait que seul les parties vraiment modifiees sont re-compilees.
Ce qui fait déjà beaucoup (avec un seul .cpp, g++ commence déjà à patiner).
C'est la faute à Gcc ou c'est la faute à c++ ?
Sans compter le temps passé à maintenir le Makefile.
Temps qui n'est jamais perdu. Avoir un bon système de "build" est une chose _vitale_ dès que l'on dépasse plus de trois fichiers source. Perdre plusieurs heures parce que le machin ne voit pas toutes les dépendances, c'est vraiment énervant.
-- { SIGAREDECUBA, "HAVANE" }, /* Instructs the process to share resources and to hate USA. Kill * remains the dictator, though */ --{ f.m.b.l revisite la command kill }--
Thierry B.
--{ Jonathan ROTH a plopé ceci: }--
La chaise étant en contact avec le sol, tout comme les pieds du développeur, et la plupart programmant avec leurs pieds, ce serait en fait plutôt le sol qui serait responsable du code de mauvaise qualité et de la lenteur du développement.
Tout ça me rappelle un roman fantastique: "Il faut rester en contact avec la Chula".
-- Ni fmbl ni fcold ne sont l'endroit approprié pour quoi que ce soit. C'est une buvette ici, on parle de tout et de rien (ah merde, tout usenet est comme ça en fait). -- JYB --
--{ Jonathan ROTH a plopé ceci: }--
La chaise étant en contact avec le sol, tout comme les pieds du
développeur, et la plupart programmant avec leurs pieds, ce serait en
fait plutôt le sol qui serait responsable du code de mauvaise qualité et
de la lenteur du développement.
Tout ça me rappelle un roman fantastique:
"Il faut rester en contact avec la Chula".
--
Ni fmbl ni fcold ne sont l'endroit approprié pour quoi que ce
soit. C'est une buvette ici, on parle de tout et de rien (ah merde,
tout usenet est comme ça en fait). -- JYB --
La chaise étant en contact avec le sol, tout comme les pieds du développeur, et la plupart programmant avec leurs pieds, ce serait en fait plutôt le sol qui serait responsable du code de mauvaise qualité et de la lenteur du développement.
Tout ça me rappelle un roman fantastique: "Il faut rester en contact avec la Chula".
-- Ni fmbl ni fcold ne sont l'endroit approprié pour quoi que ce soit. C'est une buvette ici, on parle de tout et de rien (ah merde, tout usenet est comme ça en fait). -- JYB --
SL
Le 01-12-2008, Nicolas George <nicolas$ a écrit :
Michel Talon, dans le message <gh0f9s$128e$, a écrit :
Il est notoire que g++ est extrêmement mauvais quand au temps de compilation, et qu'il existe considérablement mieux, par exemple le compilateur Microsoft.
D'un autre côté, le compilo microsoft, d'après ce que j'ai entendu dire
Ça devait être sur un blog.
Le 01-12-2008, Nicolas George <nicolas$george@salle-s.org> a écrit :
Michel Talon, dans le message <gh0f9s$128e$3@asmodee.lpthe.jussieu.fr>,
a écrit :
Il est notoire que g++ est extrêmement mauvais
quand au temps de compilation, et qu'il existe considérablement mieux,
par exemple le compilateur Microsoft.
D'un autre côté, le compilo microsoft, d'après ce que j'ai entendu dire
Michel Talon, dans le message <gh0f9s$128e$, a écrit :
Il est notoire que g++ est extrêmement mauvais quand au temps de compilation, et qu'il existe considérablement mieux, par exemple le compilateur Microsoft.
D'un autre côté, le compilo microsoft, d'après ce que j'ai entendu dire
Ça devait être sur un blog.
SL
Le 01-12-2008, Manuel Leclerc a écrit :
Stephane TOUGARD a écrit :
Tu connais un developpeur qui va plus vite qu'un compilo C++ quand le Makefile est bon ?
Moi je connais pas, desole.
Moi, des fois j'ai la femme de sauter sur l'erreur
Faut que tu prennes des vacances.
Le 01-12-2008, Manuel Leclerc <manuel.leclerc@alussinan.org> a écrit :
Stephane TOUGARD a écrit :
Tu connais un developpeur qui va plus vite qu'un
compilo C++ quand le Makefile est bon ?
Moi je connais pas, desole.
Moi, des fois j'ai la femme de sauter sur l'erreur
