• vient de jouer a CS 1.6 sous linux*

c'est beaucoup plus fluide que sous windows O.o

C'est moi ou j'ai l'impression que certains essayent 15 distributions dans le mois ?
C'est fou parceque je n'en ai pas essayer 15 dans ma vie.

godrik : il y a deux (dix ) catégories de gens. Ceux qui essaient des distributions linux, et ceux qui ont compris que ça faisait perdre trop de temps.

Cela dit, je suis bien content en tant qu'individu de type 2 qu'il existe des individus de type 1.

History of sh by Steve Bourne on /.

http://tech.slashdot.org/article.pl?sid=09/03/05/1539226

En réponse à :
https://www.jeuxvideo.com/forums/1-38-7678116-1-0-1-0-les-jeux-et-linux-sont-ils-compatibles.htm#message_7678146

« L'argument qu'on a eu "contre" l'utilisation d'IDE, c'est la non compréhension du mécanisme qui se trouve derrière la compilation (entre autre) » Est-ce important de savoir comment marche le compilateur quand on doit juste coder une fonction qui calcule le max de deux entiers ?
java/javac et git/make/vim prennent tout leur sens quand il s'agit de faire un vrai projet. Mais avant de faire des projets, il faut déjà savoir coder...
Au passage, si je devais enseigner à des élèves en dernière année d'école d'ingé (et si j'étais libre de faire ce que je veux), je ne leur interdirais les IDE, histoire d'être sûr qu'au moins une fois dans leur vie, ils aient été confrontés à la compilation et aux Makefiles.

« Par contre, pour introduire Linux à un public "nouveau", je ne sais pas comment s'y prendre. » Ce n'est jamais facile. Néanmoins, je sais à peu près ce que je veux voir dans un TP d'introduction à linux :
1) le gestionnaire de paquet
2) les bienfaits d'unix (éditeur de texte avec coloration syntaxique, indentation et complétion, copier-coller à la souris, présentations de quelques applications phare style amarok, ...)
3) le système de droits sous unix (manipulation dans nautilus/konqueror)
Fin de la séance. Et surprise, nous n'avons jamais ouvert le moindre terminal ! Le mythe, jle plie...
En prime, j'aurais bien sûr délibérément choisi en 2) des applications qui tournent sous windows, histoire que même ceux qui n'ont pas le courage d'installer linux puissent profiter des bienfaits de la communauté.

Au niveau des IDEs, je suis relativement d'accord pour commencer, il faut quelquechose qui marche juste. On ne peut pas prendre toutes les informations d'un coup. "masquer" la compilation c'est du fait pas forcement plus mal.

dans ton TP linux type, je pense que tu as oublier trois choses importantes:
-comment faire le lien avec windows
-flash ca marche
-je peux jouer a world of warcraft
Ces elements font "fuire les gens". Ca peut raporter des cli... utilisateurs

« -comment faire le lien avec windows » j'avoue qu'il faudrait que je rédige vraiment le TP pour voir comment intégrer au mieux le "et windows dans tout ça ?". Dans tous les cas, c'est un TP, et donc l'élève doit y apprendre quelque chose par la pratique. Je pense qu'en les faisant jouer avec synaptic ou les droits, on arrive facilement à amener un petit bagage théorique. À partir de là, la question de savoir comment c'est fait sous windows devient assez naturelle.

« -flash ca marche » oui, il faut bien un paquet qui ne soit pas dans les dépôts standards à installer de toute façon. Sinon, on n'aborde pas le point.

« -je peux jouer a world of warcraft » ça c'est assez difficilement justifiable auprès du responsable pédagogique. Cela dit, c'est le genre de réponse qu'un TPman peut donner si on pose la question des jeux, avec éventuellement preuve à l'appui (suffit d'amener son laptop ). J'avoue, je suis bien du genre à lancer diablo 2 sous linux devant mes élèves (à la fin du TP, sinon c'est du suicide). Une demo valant mieux qu'un long discours.

il y a un prof a grenoble qui pour eduquer (comprendre geekise) les etudiants de son cours (destine aux ingenieur d'ecole non info qui refont une annee d'info) utilise les outils les plus obscure sur son laptop qu'il trouve, en change toute les semaines et en parle pendant 2, 3 minutes.
un coup il leur montre qu'avec linux on peu faire des fenetre molles et du feu sur son bureau.
Un jour il leur montre la magie des tiled window manager.
Un jour il fait express de recompiler son beamer en directe apres avoir changer une faute d'orthographe.
Je crois qu'il a pousse le vice jusqu'a afficher son pdf avec kpdf dans cygwin dans windows dans qemu sous ubuntu.
Juste pour la culture, c'est rigolo comme idee.

Ça dépend également de l'environnement (d'enseignement). Si l'équipe pédagogique se met d'accord sur le fait d'utiliser majoritairement Linux, alors oui présenter Linux comme alternative viable à windows peut être intéressant.

Pour les IDE, le risque est de rendre les gens acros dès le début. Mais en même temps, en entreprise ils seront plus confrontés à un IDE qu'à emacs (sauf peut être pour les admins-sys, et encore).

Ensuite, je ne sais pas si un Cours est prévu avant le premier TP ? Mais je verrai bien un petit historique, ça m'a vraiment manqué pour la culture personnelle. (avec les différents forks qui ont aboutis à Unix d'un côté et Linux de l'autre)

Ensuite, si tu comptes présenter les outils phares de Linux, je pense qu'un TP sur emacs peut être intéressant (pas forcément 4h, mais 1 ou 2). Cet éditeur est quand même vachement puissant (et le présenter avec l'option -nw dans le cas d'une maintenance à distance ou que sais-je)

Personnellement j'ai jamais supporté les boites noires qui font cinquante choses dans mon dos sans savoir ce qui se cache derrière.
Je suis de ceux qui ont besoin de comprendre les fondements pour arriver à s'intéresser à quelque chose.
Aussi me plaquer la face dans un gros bousin d'IDE même pour compiler un programme qui calcule le maximum de deux nombres m'aurait dégouté de la discipline.

Le processus adapté aux personnes telles que moi aurait été :
1- Présentation de l'architecure d'un ordinateur (notamment le fonctionnement du processeur et de la mémoire)
2- Explication du processus de compilation et de linkage sur un exemple basique de chez basique (hello world sur deux fichiers C de quatre lignes)
3- Apprentissage du C

Ensuite l'introduction aux Unix coule de source avec présentation des outils atomiques qui permettent de bien comprendre ce qu'il se passe et de retrouver les billes soutenues par le professeur. Et éventuellement débordement en fin de séance pour présenter les qualités de l'os sur des machines de bureau.

Une fois ces bases établies, les étudiants ont tout ce qu'il faut pour apprécier ou pas les IDE.

Apprendre pendant des semaines à utiliser Eclipse sous Windows, étudier par cœur sans rien comprendre des dizaines de design patterns est le meilleur moyen (et c'est exactement ce qu'il se passe actuellement) de se retrouver avec des « experts » certifiés SUN qui ne savent pas comment fonctionne la machine virtuelle java ou ce qu'il y a dans le war d'une webapp j2ee.
Les étudiants auront tout loisir de ranger leur cerveau au placard lorsqu'ils intégreront une entreprise, autant qu'il y ait un peu de stimuli intellectuel pendant les années d'études.

Je n'ai pas fait d'école purement informatique mais je suis content d'y avoir reçu un enseignement « à l'ancienne » par des profs de la vieille école. :p

Je suis tout à fait d'accord avec Sankukai, mais c'est certainement du à une nature curieuse.
Les IDE font gagner du temps, c'est certain, mais on ne sait pas ce qu'il fait pour nous.
De plus, ctrl+espace à tendance à remplacer la javadoc, et c'est pas forcément un plus. Du moins pendant le cycle de formation.

Et le jour où on est confronté à un framework exotique (par exemple le JMF), on ne sait pas où chercher.

Je pense aussi qu'il faut insister sur les commentaires dans le code (façon javadoc voire doxygen pour le C), rien que pour les rapports de projet ça peut servir, et on a vu ça qu'en 3ème année... (je l'utilisais avant... avec eclipse "sans savoir" que la commande javadoc existait)

Une autre idée qui me vient, c'est un sujet de projet (de fin d'année ?). Ça m'aurait plu de participer à un projet open-source, soit un projet from scratch (si on a défini une convention de codage, etc.), soit un plug-in ou quelque chose du style. Ça permet plusieurs chose. Premièrement la motivation de faire quelque chose de "visible" au niveau de la communauté, deuxièmement de s'imposer une façon "propre" de coder, troisièmement de lire du code source dans le cas d'un projet déjà existant.

Enfin, un dernier point important selon moi, la documentation en anglais.
Les traductions des pages man sont pas forcément plus compréhensibles que les originales, la javadoc ou les documentations sur les librairies C sont en anglais, etc.

godrik : ah, j'ai trouvé mon maître là.

Sankukai : «Je suis de ceux qui ont besoin de comprendre les fondements pour arriver à s'intéresser à quelque chose. » +1.

«Le processus adapté aux personnes telles que moi aurait été : [...] »
Le soucis, c'est que pour survivre à un vrai cours de compil (point 2), il faut avoir une bonne idée des enjeux, et pour ça, il faut avoir programmer (point 3) ... Perso, ça ne me dérange pas de lancer directement les petits L1 sur un IDE. Le curieux finira fatalement par me demander comment ça marche, et c'est assez facile de rentrer dans les détails en partant d'un fichier exemple et en jouant avec les 3 boutons "compiler" / "lancer" / "tout faire". Après, s'il en veut plus, c'est qu'il a trouvé sa voie et du coup je "te" l'envoie.

Jackass059 : j'ai pas osé dire emacs (parce que je suis un ferme défenseur de vim) mais c'est l'éditeur auquel j'avais pensé.

«Ça m'aurait plu de participer à un projet open-source» c'est proposé (et "fait") chaque année à l'ENS Lyon depuis plus de 10 ans. Le résultat est qu'il n'y a eu qu'un survivant jusqu'ici : http://savonet.sourceforge.net/
En général, ce genre de projet conduit à un échec (mais pas forcément un échec pédagogique, car le but est justement de montrer la difficulté d'un travail en gros groupe et des outils pour faire ce travail).

Personnellement, je suis aussi plus pour vim, mais faut avouer qu'emacs a ses atouts.

Pour le projet OpenSource, c'est pas forcément gênant qu'il n'aboutisse pas. Mon projet n'attire pas les foules, mais j'en tire quand même une certaine satisfaction, ne serait-ce que par le fait que j'ai appris ÉNORMÉMENT grâce à ça (lecture de code source, lecture de documentations C, auto-tools, svn, etc...).
Et quand je reçois ne serait-ce qu'UN mail avec une demande de fonctionnalité, ça me fait très plaisir.

L'avantage de se baser sur un projet existant, c'est qu'on doit lire le code, chercher les docs, etc. et c'est ce qu'on aura à faire probablement un jour ou l'autre en entreprise.

Le probleme evoque par sankukai est complique.
Il ya des gens qui comprennent/s'interessent plus avec une approche top down et d'autre avec une approche bottom up.
Je suis aussi plutot bottom up, mais ce n'est pas le cas de la majorite. et c'est difficile de proposer les deux aspects en meme temps.

Je pense qu'il est interessant d'etudier emacs, vim et nedit (inserer ici n'importe quel editeur "classique"). Ca montre aux etudiants qu'il y a plusieurs facon de considerer/effectuer la meme tache avec des modeles differents.

Ce que je remarque aussi en étant encore étudiant, c'est que ceux qui s'en sortent le mieux sont ceux qui passent leur temps à lire des tutos, à bidouiller le système, etc.
Après dans les études informatiques en général on a des matières annexes (communication, gestion, économie, etc.) et de mon DUT, je pense qu'il en est ressorti 50% de "8 info" - "12 autre", 25% de "12 info" - "8 autre", et le reste "12 info" - "12 autre".

Ce qui fait qu'en entreprise on retrouve des développeurs qui ne savent pas ce qu'est le MVC. On retrouve ensuite des pisseurs de code qui par manque "d'aise" à l'oral se font "exploiter".

Pour ces derniers, c'est dommage. Pour les premiers, c'est tant mieux pour eux.
Mais je pense que le gros pari que doivent prendre les enseignants, c'est de développer la curiosité de chacun, et pour ça malheureusement je n'ai pas de conseil à donner sur la technique ^^°.

Mon experience (qui n'est pas en DUT) est que les gens interesse vont aller voir plus loin que le cours et ces gens la vont etre bon techniquement.
Les autres vont faire le minimum pour passer l'examen, de toute facon, ils se foutent de la matiere.

Les gens pas interesse, tu ne peux rien y faire au niveau de l'enseignement. Soit tu les forces a apprendre ce que les autres apprennent, mais ca te prends du temps de cours et souvent ce n'est dans pas ton programme. Soit tu fais des examens qui vont les virer mais ca pose des problemes politiques.

C'est ça le gros problème. On ne peut pas faire des formations UNIQUEMENT techniques. Personnellement, les cours de gestion, économie, communication, etc. m'ont vraiment intéressé, et grâce notamment aux cours de communication j'ai pu négocier un stage avec des conditions assez intéressantes.

En même temps, si ces matières valaient rien niveau coefficients, les "geeks" s'en taperaient ^^°.
Mais du coup, y'a des gens qui profitent de ça, et c'est tant mieux pour eux encore une fois, mais je trouve ça dommage.

Après, si on avait que des étudiants ultra curieux qui apprennent au prof à recompiler un kernel, ça serait pas non plus sérieux ^^. Déjà parce qu'il faudrait que des profs ultra balèzes, ensuite parce qu'avec la conjoncture actuelle les FAC auraient pas forcément les moyens de les garder et enfin, tout simplement parce que des gens comme ça ça court pas les rues et qu'ils ont pas forcément la pédagogie/envie nécessaire.

reussir une formation en informatique ne veut pas dire que l'on est un bon informaticien. Ca veut juste dire qu'on ta parler d'informatique pendant x annees.

Il ne faut pas oublier que ces aspects techniques ne sont pas le coeur de l'enseignement en informatique. C'est ce qui te rends debrouillard devant une machine.

Ne t'en fais pas pour les profs. Des profs super au courant des technos, il y en a. Pas tous, ils n'en ont pas tous besoin. Il en suffit de 10% qui soient bien au courant pour obtenir une formation efficace. Tu as besoin de ce type de connaissance en TP uniquement et les TPmen savent faire ce genre de choses en general.

«Les gens pas interesse, tu ne peux rien y faire au niveau de l'enseignement.» si, tu peux leur demander pourquoi ils ne sont pas intéressé. Les raisons sont diverses et variées, mais parfois, elles donnent de bonnes pistes sur ce que l'enseignant doit faire pour améliorer son cours/TD/TP. En plus, c'est très bien de montrer à l'étudiant qu'on s'intéresse vraiment à lui, spécialement quand il est en difficulté et qu'il recherche un peu de soutien.

Jackass059 :
« Déjà parce qu'il faudrait que des profs ultra balèzes » mais ils sont ultra-balèzes.

« avec la conjoncture actuelle les FAC auraient pas forcément les moyens de les garder » avec la conjecture actuelle, tous les chercheurs vont devoir enseigner, donc la situation serait pire que ce qu'elle n'est à l'heure actuelle (ou c'est déjà pas brillant par endroits).

« des gens comme ça ça court pas les rues » mon point de vue, des gens comme, il y en a trop pour que j'obtienne rapidement un poste de prof en classe prépa.

« Il en suffit de 10% qui soient bien au courant pour obtenir une formation efficace. Tu as besoin de ce type de connaissance en TP uniquement et les TPmen savent faire ce genre de choses en general. »
euh... 1 cours en amphi pour 300 personnes => 10 TDs pour 30 personnes en parallèle => 20 TPs pour 15 personnes en parallèles.

Même si souvent, les TPs ont lieu une fois toutes les deux semaines, ça concerne quand même directement environ 50% du groupe pédagogique.

Heureusement, les TPs sont souvent donnés aux thésards comme moi, qui sont suffisamment jeunes pour mieux maîtriser la "pointe" de la technologie.