Je confirme de mon coté aussi cet état de fait.

Il est clair que les développeurs ont bien compris que bien souvent l’application Java/J2EE ou PHP qu’ils développent avec leur plateforme Eclipse est destinée à être mise en production vers un serveur Unix ou Linux.

Par ailleurs, j’ajouterai qu’il y a aussi (je pense) une certaine émulsion qui agit lorsqu’un développeur sous Windows, voit un développeur qui lui travaille avec Linux. Ce dernier même si il a des soucis de temps en temps avec son Linux + Eclipse, va tout simplement masquer ses problèmes et dire que son Linux est ‘carrément’ mieux que le Windows, et qu’il est super génial, chouette, etc. Éventuellement, il pourra tout de même dire qu’il y a parfois des problèmes, mais que les avantages restent supérieurs.

Dans tous les cas, le développeur qui se doit d’être curieux, va vouloir faire pareil que son collègue/copain. Et peut-être qu’il y aura ensuite un basculement durable sous Linux (ou un retour sous Windows).

On voit aussi parfois : l’installation en dual-boot, deux ou trois jours sous Linux, puis deux ou trois jours sous Windows en fonction de l’humeur, de la présence ou non du collègue, de la réussite ou non de l’installation de tel ou tel pilote de carte vidéo 3D, etc. Cela fait ‘presque’ penser à des gens qui essayent d’arrêter de fumer

Pour revenir à cette émulation qui apparaît lors qu’un développeur voit un autre développeur qui bosse sous Linux, on peut s’interroger sur le « comment a-t-il basculer sous Linux ? » ce premier développeur ?

Je n’ai pas une réponse, mais simplement quelques cas (qui ne sont pas forcément une généralisation) :

• l’étudiant en informatique qui a mis Linux sur sa machine dès la première année, qui a pu faire son stage de fin d’étude avec son portable toujours sous Linux, et dans la société qui l’a embauché, il n’y a pas de problème pour continuer à bosser sous Linux. Celui-là, finalement, il ne connait pas trop bien Windows, et va plus vite sous Linux.
• le développeur en régie qui vient d’une société où l’ensemble des développeurs est sous Linux (et oui cela existe). Donc là, on a un développeur qui d’abord est contraint, (et bien souvent ensuite – me semble-t-il – convaincu de Linux).
• l’expert / consultant (dont je pense faire parti) qui travaille sous Linux, et de part sa fonction dans le projet bénéficie d’une certaine reconnaissance de ses compétences, et donc du message « si il est expert et qu’il travaille sous Linux, c’est que Linux est le système pour les experts (les bons  »

Bien évidement ces cas s’adressent plutôt à des développeurs qui bossent sur du Java ou de PHP, le développeur .NET, lui n’a pas vraiment le choix, la meilleur plateforme de développement .NET est sous Windows, et son application va fonctionner sur Windows.

Pour conclure, c’est une bonne chose de mon point de vue de voir des développeurs travailler sur l’environnement Linux (ou le tester). Cela leur permet d’ouvrir un peu leur horizon informatique, de leur donner une meilleure compréhension de l’informatique, un peu comme si on voyage dans différents pays chacun ayant ses coutumes, traditions, plats culinaires, etc.

./

Et oui, 8 Go de mémoire (2 x 4 Go). Je l’ai ai reçu vendredi en fin de journée, comme une belle récompense après une semaine de travail compliquée.

Ainsi je passe de 4 Go de RAM à 8 Go. Mon ordinateur se sent bien mieux avec autant de mémoire, et de mon coté, je sens bien que les applications qui ont déjà été chargées une première fois, démarrent bien plus vite (le cache disque), et d’une manière générale que le temps de chargement, le temps de basculement des applications est devenu plus rapide.

Au niveau de Linux (64 bits évidemment), cela donne avec plusieurs applications lancées (Seamonkey, Thunderbird, Firefox, Eclipse, OpenOffice) :

$ free -m
                   total       used       free     shared    buffers     cached
Mem:          7991       4864       3127          0        326       2862
-/+ buffers/cache:       1674       6317
Swap:         9691          0       9691

J’ai donc 1674 Mo réellement utilisés, mais un cache de 2862 Mo soit 4864 Mo d’utilisés et il ne reste ‘plus’ que 3127 Mo.

Content

./

Pour mon cas, j’ai donc un portable Ubuntu Desktop (9.10), et j’ai un autre portable (cela marche aussi avec une machine virtuelle) qui est installé avec la distribution orientée tests de sécurité Backtrack (4 final). Je souhaite avoir l’environnement graphique XWindow de Backtrack (un KDE 3) sur mon poste (un Gnome), tout en gardant mon environnement XWindow/Gnome ouvert… c’est-à-dire conserver mon environnement de travail (thunderbird, firefox, etc..) et basculer sur le mode graphique du portable Backtrack pour lancer des tests de sécurité, et donc sans me déplacer physiquement vers le portable (un bon informaticien est un informaticien fainéant!).

Ouh là ! Je rêve ?! Et bien non, c’est possible :

Sur la machine backtrack, on va faire quelques ajustements / préparations après son installation :

En mode non graphique (en tant que root) :

Démarrage du SSH avec éventuellement, création des clés pour SSH si ce n’est pas déjà fait :

setup-sshd

puis, démarrage du serveur ssh :

/etc/init.d/ssh start

Démarrage en mode automatique du réseau (ce n’est pas le cas par défaut sur une backtrack) :

update-rc.d networking defaults

Démarrage en mode automatique du service SSH :

update-rc.d ssh defaults

Installation du paquetage kdm (et ses dépendances) pour pourvoir faire ce que je veux faire (le kdm est le gestionnaire d’affichage de KDE)

apt-get install kdm

On arrête le service kdm car sinon il va poser problème si jamais il est démarré que je veux l’avoir à distance.

/etc/init.d/kdm stop

On l’enlève du démarrage automatique (histoire qu’il ne nous embête plus jamais)

update-rc.d -f kdm remove

Sur la machine cliente (poste de travail), on change l’autorisation de lancer des environnements X de « console user » vers « Anybody », afin de (me) permettre de lancer le programme xinit sans être l’utilisateur root :

sudo dpkg-reconfigure x11-common

(choisir Anybody et valider)

Ensuite depuis une fenêtre Terminal (ligne de commande) sur la machine cliente,, on saisit la commande suivante :

xinit /usr/bin/ssh -i /home/milamber/.ssh/milamber -X root@10.0.0.2 "/opt/kde3/bin/startkde" -- :1

On notera que :

• 10.0.0.2 correspond à l’adresse de la machine backtrack
• l’on se connecte en root sur le backtrack (une particularité de la distribution)
• que j’utilise un certificat RSA pour ne pas saisir de mot de passe SSH
  

Et voilà, l’écran devient noir, puis le XWindow et le KDE démarrent… sur une nouvelle console virtuelle (vt).

Ensuite :

• Pour basculer (revenir) vers sa fenêtre XWindow locale, faire Ctrl+Alt+F7
• Pour revenir sur la fenêtre XWindow backtrack, faire Ctrl+Alt+F9

Un rêve devenu réalité…

./