euh
un octet (fr) = an octet (en)
un byte = un groupe de bits, généralement un octet, mais c'est pas obligé.
En français, on ne parle pas de bouchée (c'est la première fois que je le vois écrit dans un contexte informatique). Eventuellement, on parle de "mot".
« Je n'ai jamais utilisé de BSD donc je suis sans aucun doute très mal placé pour critiquer.
Cependant, d'après la description qui en est faite, il me semble que son développement (je prends les BSD en général) repose plus sur une architecture "cathédrale" que "bazar". »
Pour reprendre grosso modo ce que disait un dév d'OpenBSD, on te donne le droit de faire un commit sur l'arbre CVS lorsque tu soumets tellement de corrections que ça en devient fatiguant de devoir faire l'intermédiaire pour toi.
Bref, le modèle "cathédrale", c'est pas vraiment ce que font les BSD. Les contributions extérieures sont les bienvenues, mais elles sont un minimum vérifiées avant intégration, comme avec Linux.
« Je demande une implication minimum de mes stagiaires. »
Bon jusque là, nous sommes d'accord, c'est la moindre des choses. :-)
« Donc si on a une urgence, il peut m'arriver de leur demander de se rester plus tard oui. Et je saurai m'en rappeler a la fin du stage [...] »
Et s'ils ne restent pas, tu sauras t'en rappeler aussi ? :-)
Ca m'est déjà arrivé de rester assez tard lors de certains stages, mais
1°) Personne ne m'a jamais rien demandé (et surtout, honnêtement, on ne demande pas à un stagiaire de rester plus tard -- sauf éventuellement si le stage est officiellement une préembauche). J'étais motivé, et comme le client testait le lendemain matin et que tout n'était pas totalement finalisé (et comme je me sentais concerné) ben je suis resté.
2°) J'habitais à 20 minutes du boulot en métro (et en plus on nous a payé le taxi pour rentrer).
Franchement, lorsqu'un de mes chefs de projet m'avait demandé à ce que la partie du soft sur laquelle je bossais soit terminée pour le lendemain, alors qu'il était déjà 19h, étant donné que je mettais déjà 1h30 en période de pointe, j'allais pas rester et risque de mettre 2h ou 2h30 à revenir chez moi.
« Pour ceux qui vivent leur stage comme un boulot de fonctionnaire, et bien je dirai qu'ils ne sont pas en phase encore avec les realites de l'entreprise. »
Si la boite pour laquelle tu fais ton stage ne te prendra pas à la fin du stage, je ne vois pas pourquoi tu ferais plus d'efforts que ça -- sauf évidemment si le sujet du stage est intéressant. ;-) (mes premiers stages me passionnaient dans l'ensemble, donc je ne comptais pas mes heures)
Les "réalités de l'entreprise", je veux bien les partager si jamais on me paie comme quelqu'un qui en fait partie. Honnêtement, dans mes précédents stages, la différence entre moi (stagiaire) et les autres salariés, ça s'est le plus souvent réduit à une différence de salaire. Je n'étais pas moins compétent que les autres techniquement [1], et même si mes responsabilités n'étaient pas aussi importantes que pour d'autres collègues, je ne pense pas qu'on m'en aurait donné beaucoup plus en tant que jeune diplômé.
« Un autre aspect, c'est que pour faire un boulot interessant et motivant, il faut souvent y mettre plus d'energie que la moyenne syndicale. »
Là par contre, je ne peux qu'acquiéser.
« De la meme facon, developper un logiciel libre ou monter une assoce, ca demande beaucoup de soirees et de week-ends. »
Oui, mais on ne peut pas comparer : avec du LL (et en supposant que ce soit un hobby et pas un emploi), on n'espère pas vivre de notre travail.
[1] : tout dépend des collègues bien entendu, et du domaine technique.
« En ce qui concerne la precarite de l'emploi, le stage correspond normalement a une partie de la formation pour obtenir ton diplome, donc n'a rien de precarisant a priori. »
Oui, le stage correspond à une partie de la formation, mais il ne faut pas oublier que le stagiaire n'a aucune obligation de résultat. C'est important à signaler : ça veut dire que lorsqu'un patron te dit "bon, c'est fini pour demain, hein ?" à 19h, et que tu mets un certain temps à rentrer chez toi, tu as tout à fait le droit de dire "oui oui" et de rentrer chez toi 10 minutes après qu'il est parti. Oui, c'est du vécu (genre une appli qui bugge, tu rames dessus depuis déjà une heure, tu vois pas les problèmes - mais tu as corrigé deux/trois bugs annexes en cherchant).
Tout ça pour dire que le stagiaire n'est pas un salarié au rabais. Je ne dis pas que tu agis ainsi avec tes stagiaires, mais par contre ça se fait très souvent (de plus en plus souvent devrais-je dire) en entreprise. :-/
« Je suis surpris d'ailleurs d'avoir entendu des gens enchainer 8 stages de suite a la tele, car il me semble qu'il faut une convention entre l'ecole et l'entreprise pour avoir un stage, et je n'ai pas vu d'ecoles donner des conventions apres le diplome. »
Dans le domaine de l'informatique c'est rare. Mais je peux te citer le cas d'une amie voulant travailler dans le domaine de l'édition, qui est en stage dans une maison d'édition (c'est pratique), payée le tiers du smic (évidemment), mais à qui on demande de réaliser un vrai boulot, et qui finalement n'est qu'un emploi déguisé. Apparemment ils sont contents d'elle puisqu'ils ont rallongé son stage de quelques mois (elle est en thèse de lettres). En six ou sept ans d'études, il ne me semble pas totalement abérant de faire six ou sept (ou huit !) stages.
Et non, elle ne peut pas tout envoyer bouler : tout le monde se connaît dans l'édition, et il est très difficile de pouvoir dire "merde" à un employeur sans que ça te grille dans toute la profession. Certains ont été stagiaires _des années_ avant de pouvoir être embauchés dans une boite d'édition quelconque. Ca donne une idée de la "précarité de l'emploi des stagiaires" dans certains domaines.
« Quels sont les automatismes a retrouver sous FreeBSD quand on est habituer a utiliser Linux (ce qui est mon cas). »
Bon, le plus gros piège quand on passe de Linux à un BSD, c'est le fait que les deux soient des UNICES (ou un dérivé), ce qui fait croire que tout va fonctionner pareil.
Avec FreeBSD, le plus simple, c'est encore de lire le handbook disponible sur leur site.
Pour la plupart de tes questions, lire le handbook devrait être suffisant.
Pour la partie sur freebsd qui serait plutôt orienté "sources"... Non, il n'y a absolument pas de "philosophie du source" dans les BSD. Chacun fait comme il veut. Forcément, si c'est ta machine perso, tu préfèrerais sans doute compiler un soft qui soit "optimisé". Maintenant, pour ne pas avoir fait gaffe, je te promets que lancer un make install pour openoffice, c'était vraiment pas malin. Bref, il n'y a pas de règle particulière concernant les logiciels. Pire : quand tu es en production, tu auras plutôt tendance à t'appuyer sur des binaires plutôt que des sources, pour des raisons de sécurité évidentes (si y'a un patch qui sort, tu dois tout recompiler. Si c'est un binaire, c'est quand même plus simple).
Il te semble mal. Windows sait très bien gérer les 4 partitions primaires autorisées sur un disque pour une archi PC. Et Partition Magic aussi (ou alors ils ont régressé depuis la version 3)
« Pendant que les VM ont fait des progrès non négligeable, les compilo classiques aussi »
Bouais. Beaucoup moins. Et le JIT de Java permet clairement bien plus d'optimisations que ce que tu sembles dire. Attention, je ne dis pas qu'on obtiendra au final quelque chose d'optimal, mais certainement pas aussi "mauvais" que ce que tu sembles croire (même si tu rappelles bien que les perfs obtenues sont déjà pas mal ;-) ).
Je ne suis pas un fan absolu de Java, mais les JVM avec JIT sont très bien pensées, et le langage permet vraiment beaucoup de choses au niveau optimisations... Ah, si seulement il était libre ...
Euh, tu sais qu'il existe des softs de calcul en Java hein ? :-) Je veux dire, de vrais softs. Avec des multiplications de matrices, tout ça. Et ils s'en sortent plutôt bien. Attends, je vais te retrouver ça...
Voilà :
« Java Signal Processing : FFTs with bytecodes » (John Glossner, Jesse Thilo, Stamatis Vassiliadis). Le papier date de 98, et depuis Java a fait pas mal de progrès dans le domaine de l'optimisation en temps (en espace - donc en mémoire - c'est autre chose). Pour te résumer l'article, faire des transformées de Fourier rapides avec Java, c'est faisable. L'expérience avait été faite sur des Ultra-Sparc II avec 128Mo de RAM, avec Java 1.1.4 (sur diverses JVM) et comparé avec gcc 2.7. Au final, Java est en moyenne 2 à 3 fois plus lent qu'un code C optimisé. Mais c'était en 98. Depuis, on a encore largement amélioré les optimisations concernant Java (et aussi celles concernant C avec GCC, mais moins -- les efforts à partir de GCC 3 sont bien plus concentrés sur C++).
« Developing numerical libraries in Java » (Ronald F. Boisvert, Jack J. Dongarra, Roldan Pozo, Karin A. Remington, G.W. Stewart). Résultats (là encore, il ne faut pas oublier qu'on est en 98) : oui ben, y'a plein de trucs bien en Java, mais bon, quand même, c'est pas la panacée, y'a plein d'autres trucs qui manquent, du coup il faut faire plus d'effort quand on est programmeur pour avoir de bons résultats. Mais les travaux sur le JIT ont l'air intéressants, ça devrait booster les résultats.
Tu y verras entre autres les différents résultats obtenus par des benches dans le domaine du calcul [1]. Et que Java se situe devant g++ et le compilo c++ d'intel.
Mais à part ça, Java, c'est lent.
[1] évidemment, il en faut pas oublier ce que dit l'auteur sur le site, à propos des biais qu'on trouve dans ce genre de tests.
Euh, non. J'ai développé des applis J2EE sur un duron 650 avec 512Mo de RAM, et je t'assure que ça ne se passe pas très bien. En gros, voilà comment se déroulaient les choses :
Eclipse + JBoss + plugins Eclipse : tourne bien au début. Après plusieurs heures de dév, de démarrage/arrêt du serveur, de chargement de diverses webapps de test, etc... La machine est inutilisable, et met parfois une bonne minute (voire plus) avant de prendre en compte un quelconque élément en entrée (clavier, souris).
Deux solutions pour ça : trifouiller la JVM (allocation de +/- de RAM, etc.), et ... rajouter 512Mo de RAM. Grâce à ça, on peut avoir plus de temps avant que la machine ne se mette à rammer. Et donc, je pouvais faire mes heures de bureau sans accroc. Evidemment, ce genre de "solution" n'est pas viable pour un serveur en production. Mais dans ce cas, il vaudrait mieux avoir un vrai admin, qui sache comment on configure correctement une JVM.
Bref. Java n'est pas lent, mais bouffe effectivement de la mémoire, et Windows semble mal gérer celle-ci, ce qui ralentit le système au final.
Sous linux, Eclipse est moins bien, mais au moins je n'ai jamais eu les problèmes constatés ci-dessus.
Je propose de casser la compatibilité ascendante des processeurs x86. Après tout, le CISC c'est pourri, et le RISC c'est mieux. Ah tiens, Intel pense comme moi, sauf que eux ont mis un décodeur pour faire du CISC => RISC sur leurs processeurs récents. Je me demande pourquoi. Certainement pas à cause de tous ces logiciels qui tournaient très bien jusque là et qu'il aurait fallu recompiler à chaque nouvelle génération de processeur si on se permettait de tout casser...
Bon, je suis de mauvais foi, et j'ai compris l'argument initial. C'est vrai qu'il vaut mieux tout recasser de temps en temps. Mais généralement, cela signifie que le modèle suivi n'est plus pertinent. Donc au contraire, je ne comprends pas trop pourquoi une bibliothèque changerait de façon drastique sa structure à ses balbutiements. Au pire, on y rajoute de plus en plus de fonctionnalités, mais les premiers symboles restent là.
D'ailleurs c'est tellement vrai que l'équipe de NetBSD en a profité pour corriger certains des défauts mis en valeur par le test, là où certains dév. d'OpenBSD ont grogné et prétexté la mauvaise foi de fefe.
Cela dit, ils n'avaient pas totalement tort, vu que dans le test, ce dernier disait qu'il n'avait eu que des problèmes à l'install (si ça arrive, on peut dire que c'est la faute de l'OS, mais on peut aussi se demander si ce n'était pas un problème situé entre la chaise et le clavier).
Ca dépend. Le travail d'un menuisier est-il une oeuvre d'art ? Le travail de tout artisan en est-il une ? Si tu me réponds oui, alors pourquoi pas. Mais dans mon esprit, je ne vois pas du tout en quoi du code serait une oeuvre d'art. Pour moi une oeuvre d'art doit pouvoir être accessible à tout le monde, mais si ce "tout le monde" ne comprend pas forcément la même chose que ce qu'a voulu dire l'auteur.
Dans le cadre de code informatique, tout le monde n'est pas capable de le comprendre même parmi les gens du métier. Je ne peux pas considérer ça comme de l'art.
Pour moi si le code est libre, le jeu l'est aussi. Les graphismes, les sons etc... relèvent pour moi du côté artistique, et n'ont pas à être nécessairement libres.
" Les chomeurs n'ont pas besoin qu'on leur fasse la morale,"
Oui enfin ça dépend lesquels. Je connais des gens qui ont quitté volontairement leur job parce qu'ils n'avaient pas pris de vacances en deux ans, et qu'ils n'en pouvaient plus - surtout que leur job commençait sérieusement à les emm...bêter. Jusque là, OK, je peux comprendre (même si honnêtement je trouve que se plaindre de n'avoir pas pris de vacances alors qu'il "suffisait" de les poser, je trouve ça limite).
Par contre, ces mêmes personnes ont profité du système d'indemnités chômage en y allant jusqu'au trognon, en prétextant que "puisque le système laisse faire, alors j'en profite". Ces mêmes personnes pensent qu'évidemment, on fait payer trop de charges aux patrons, que la flexibilité n'est pas assez importante, ...
Evidemment, il y a plein de chômeurs qui voudraient ne plus l'être. Mais au moins au début de leur chômage, j'en ai rencontré d'autres qui se sont permis des "vacances" (de plus ou moins longue durée).
Sinon je suis tout à fait d'accord avec toi. J'ai lu les six volumes, (je me suis pas précipité pour acheter le 6è, il se trouve que je faisais mes courses et que je suis tombé dessus), et je trouve que, même si ce n'est pas forcément ce que j'ai lu de mieux, c'est tout de même une très bonne série de bouquins, bien construite.
Je ne trouve vraiment pas le langage C 'simple' car il contient trop d'élément de syntaxe différent (boucle, affectation, pointeur, référence, tableau, fonction, macro ...).
Euh, boucles, affectations, tableaux, fonctions, tout ça tu le retrouves (heureusement) dans tous les langages. Quant aux références, c'est du Java et pas du C. Tiens d'ailleurs, un truc tout bête :
en C, tout est passé par valeur. TOUT. En Java, les types primitifs sont passés par valeur (donc par copie), mais tous les types "complexes" (les objets) sont passés par référence. Et note bien que j'ai parlé de la simplicité du langage/de sa syntaxe, pas de la facilité à programmer avec le langage C. Je trouve que ce dernier est plutôt rapide à mettre en oeuvre justement parce qu'il n'y a pas trop de concepts à connaître (mis à part la notion de pointeur, mais honnêtement, comme je l'ai dit, il n'y a pas besoin de manipuler les pointeurs pour commencer à programmer).
quand je parlais d'algo, je pensais plutôt à des trucs basiques comme un quick sort ou la création de listes chainées
Quand tu commences à programmer, un quicksort ou un algo de listes chaînées n'est pas simple, quel que soit le langage.
Prend le code Java (ou Ruby ou O'Caml) et compare avec un code en C
Je ne connais pas Ruby. En ce qui concerne Java, si tu n'as aucune notion de comment est allouée la mémoire, de comment fonctionne le garbage collector, etc., je ne vois pas comment tu peux comprendre la signification d'un NullPointerException. Java te fait croire qu'il n'y a pas de pointeurs, alors qu'il n'y a que ça, partout. Si tu ne comprends pas le principe d'une référence, je ne vois pas trop comment tu peux faire des choses un tant soit peu complexes en Java, ce qui revient à comprendre les pointeurs en C. Dans les deux cas, il faut parler d'adresse mémoire.
Donc le paradigme objet ne te servira à pas grand chose au début, la seule chose c'est que Java par exemple permet de se détacher un minimun de la machine
La méthode objet ne sert à rien au début. Si on te fait prendre l'habitude dès le départ (enfin, très vite, dirons-nous) de programmer sous forme de modules (fonctions/procédures), les concepts objets seront relativement simples à comprendre (il faut quand même une période d'adaptation, bien sûr). Et justement, prends Java : lorsque tu fais de la prog non objet, tu te retrouves avec le corps minimal suivant :
public class MaClasse {
public static void main(String[] args) {
// programme
}
}
Tu dois donc dire à l'étudiant en prog "oui bon, ben, oublie tout le squelette pour le moment, je t'expliquerai plus tard". En C, tu peux aisément expliquer les choses :
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
/* ... *
return EXIT_SUCCESS;
}
(et encore, les #include étant comparables aux import, je ne devrais pas les mettre dans le "source").
Pour ce qui est des macros, tu ne les utilises pas au début, et bizarrement ça ne manque pas.
Et alors quel est l'intêret de commencer à apprendre avec un langage aussi 'primitif' que C si on n'utilise même pas ses 'features' les plus intéressantes
Ben justement, le langage est simple. Pour apprendre à programmer, y'a rien de tel : tu codes ton truc, et dès que tu as besoin d'une fonctionnalité avancée, tu te la programmes. C'est comme ça qu'on apprend. C'est très très formateur d'apprendre à réécrire la libc par exemple (c'est d'ailleurs plus ou moins l'approche utilisée dans le Kernighan & Ritchie, mais le bouquin en lui-même n'est pas pour les débutants).
Cela dit, tu peux déjà programmer pas mal de choses en C rien qu'avec la notion de tableaux.
Et tu utilises une syntaxe "propre" pour masquer les pointeurs dans les cas où tu en as besoin, du genre
typedef char CHAINE20[21];
Plus le langage est simple, plus il est facile d'apprendre a s'en servir. Cela dit, faire de la programmation « sérieuse » proprement en C, c'est une autre paire de manches.
De plus, commencer par utiliser un langage totalement orienté objet (comme Java ou Ruby), même si on peut toujours détourner le langage pour en garder le côté procédural, est une mauvaise idée à mon avis. Les algos sont rarement orientés objet au départ; ils sont adaptés au paradigme objet, mais proviennent pour la plupart des travaux de recherche effectués dans les années 60/70...
c'est à se demander comment il se fait qu'un projet tel qu'OpenSSH survive depuis tant d'années... Sans parler de X (oui, ça fait redite avec un post précédent :-) ) ou Apache, les divers projets de Jakarta, Struts ...
[Dans le film de Moore] la seule vraie raison de la violence aux EU apparaît dans un fatras d'autres causes illusoires (ex: la télévision)
Absolument pas.
Il dit que ce qui est la cause de la violence aux USA est l'injection permanente de peur dans l'esprit des gens. Il prend la télévision comme exemple, mais il sous-entend surtout que les média les plus utilisés par la grande majorité des étatsuniens véhiculent une propagande de la peur. Pour avoir de la famille là-bas, je peux te dire que c'est exactement comme ça. Lorsqu'il y avait [1] la 2è guerre du golfe, on maintenant dans l'esprit des gens qu'ils étaient susceptibles d'être attaqués à tout moment, afin de les gardés convaincus du bien fondé de cette "guerre préventive". Le propos de Moore est de dire que la violence naît de la peur. Et franchement, c'est vrai. Regarde en France : un Sarkozy promet de nettoyer une cité (avec toute la démagogie qui va avec), et il apparaît en homme fort, qui va nous débarrasser de la racaille comm... euh, de la racaille. C'est entre autres grâce à la peur que ce genre de choses est possible.
[1] enfin, "avait", "a", ... Bref, je sais plus trop là. :-)
[^] # Re: Ce que j'en pense ? Aucun intérêt...
Posté par lasher . En réponse au journal La fin de l'internet ?. Évalué à 1.
un octet (fr) = an octet (en)
un byte = un groupe de bits, généralement un octet, mais c'est pas obligé.
En français, on ne parle pas de bouchée (c'est la première fois que je le vois écrit dans un contexte informatique). Eventuellement, on parle de "mot".
[^] # Re: FreeBSD sur le poste de travail
Posté par lasher . En réponse à la dépêche Sortie de FreeBSD 6.0. Évalué à 3.
Cependant, d'après la description qui en est faite, il me semble que son développement (je prends les BSD en général) repose plus sur une architecture "cathédrale" que "bazar". »
Pour reprendre grosso modo ce que disait un dév d'OpenBSD, on te donne le droit de faire un commit sur l'arbre CVS lorsque tu soumets tellement de corrections que ça en devient fatiguant de devoir faire l'intermédiaire pour toi.
Bref, le modèle "cathédrale", c'est pas vraiment ce que font les BSD. Les contributions extérieures sont les bienvenues, mais elles sont un minimum vérifiées avant intégration, comme avec Linux.
[^] # Re: La rémunératon ?
Posté par lasher . En réponse au journal Stage en python / Qt. Évalué à 1.
Bon jusque là, nous sommes d'accord, c'est la moindre des choses. :-)
« Donc si on a une urgence, il peut m'arriver de leur demander de se rester plus tard oui. Et je saurai m'en rappeler a la fin du stage [...] »
Et s'ils ne restent pas, tu sauras t'en rappeler aussi ? :-)
Ca m'est déjà arrivé de rester assez tard lors de certains stages, mais
1°) Personne ne m'a jamais rien demandé (et surtout, honnêtement, on ne demande pas à un stagiaire de rester plus tard -- sauf éventuellement si le stage est officiellement une préembauche). J'étais motivé, et comme le client testait le lendemain matin et que tout n'était pas totalement finalisé (et comme je me sentais concerné) ben je suis resté.
2°) J'habitais à 20 minutes du boulot en métro (et en plus on nous a payé le taxi pour rentrer).
Franchement, lorsqu'un de mes chefs de projet m'avait demandé à ce que la partie du soft sur laquelle je bossais soit terminée pour le lendemain, alors qu'il était déjà 19h, étant donné que je mettais déjà 1h30 en période de pointe, j'allais pas rester et risque de mettre 2h ou 2h30 à revenir chez moi.
« Pour ceux qui vivent leur stage comme un boulot de fonctionnaire, et bien je dirai qu'ils ne sont pas en phase encore avec les realites de l'entreprise. »
Si la boite pour laquelle tu fais ton stage ne te prendra pas à la fin du stage, je ne vois pas pourquoi tu ferais plus d'efforts que ça -- sauf évidemment si le sujet du stage est intéressant. ;-) (mes premiers stages me passionnaient dans l'ensemble, donc je ne comptais pas mes heures)
Les "réalités de l'entreprise", je veux bien les partager si jamais on me paie comme quelqu'un qui en fait partie. Honnêtement, dans mes précédents stages, la différence entre moi (stagiaire) et les autres salariés, ça s'est le plus souvent réduit à une différence de salaire. Je n'étais pas moins compétent que les autres techniquement [1], et même si mes responsabilités n'étaient pas aussi importantes que pour d'autres collègues, je ne pense pas qu'on m'en aurait donné beaucoup plus en tant que jeune diplômé.
« Un autre aspect, c'est que pour faire un boulot interessant et motivant, il faut souvent y mettre plus d'energie que la moyenne syndicale. »
Là par contre, je ne peux qu'acquiéser.
« De la meme facon, developper un logiciel libre ou monter une assoce, ca demande beaucoup de soirees et de week-ends. »
Oui, mais on ne peut pas comparer : avec du LL (et en supposant que ce soit un hobby et pas un emploi), on n'espère pas vivre de notre travail.
[1] : tout dépend des collègues bien entendu, et du domaine technique.
[^] # Re: La rémunératon ?
Posté par lasher . En réponse au journal Stage en python / Qt. Évalué à 2.
Oui, le stage correspond à une partie de la formation, mais il ne faut pas oublier que le stagiaire n'a aucune obligation de résultat. C'est important à signaler : ça veut dire que lorsqu'un patron te dit "bon, c'est fini pour demain, hein ?" à 19h, et que tu mets un certain temps à rentrer chez toi, tu as tout à fait le droit de dire "oui oui" et de rentrer chez toi 10 minutes après qu'il est parti. Oui, c'est du vécu (genre une appli qui bugge, tu rames dessus depuis déjà une heure, tu vois pas les problèmes - mais tu as corrigé deux/trois bugs annexes en cherchant).
Tout ça pour dire que le stagiaire n'est pas un salarié au rabais. Je ne dis pas que tu agis ainsi avec tes stagiaires, mais par contre ça se fait très souvent (de plus en plus souvent devrais-je dire) en entreprise. :-/
« Je suis surpris d'ailleurs d'avoir entendu des gens enchainer 8 stages de suite a la tele, car il me semble qu'il faut une convention entre l'ecole et l'entreprise pour avoir un stage, et je n'ai pas vu d'ecoles donner des conventions apres le diplome. »
Dans le domaine de l'informatique c'est rare. Mais je peux te citer le cas d'une amie voulant travailler dans le domaine de l'édition, qui est en stage dans une maison d'édition (c'est pratique), payée le tiers du smic (évidemment), mais à qui on demande de réaliser un vrai boulot, et qui finalement n'est qu'un emploi déguisé. Apparemment ils sont contents d'elle puisqu'ils ont rallongé son stage de quelques mois (elle est en thèse de lettres). En six ou sept ans d'études, il ne me semble pas totalement abérant de faire six ou sept (ou huit !) stages.
Et non, elle ne peut pas tout envoyer bouler : tout le monde se connaît dans l'édition, et il est très difficile de pouvoir dire "merde" à un employeur sans que ça te grille dans toute la profession. Certains ont été stagiaires _des années_ avant de pouvoir être embauchés dans une boite d'édition quelconque. Ca donne une idée de la "précarité de l'emploi des stagiaires" dans certains domaines.
[^] # Re: Linux vers FreeBSD
Posté par lasher . En réponse à la dépêche Sortie de FreeBSD 6.0. Évalué à 4.
Bon, le plus gros piège quand on passe de Linux à un BSD, c'est le fait que les deux soient des UNICES (ou un dérivé), ce qui fait croire que tout va fonctionner pareil.
Avec FreeBSD, le plus simple, c'est encore de lire le handbook disponible sur leur site.
Pour la plupart de tes questions, lire le handbook devrait être suffisant.
Pour la partie sur freebsd qui serait plutôt orienté "sources"... Non, il n'y a absolument pas de "philosophie du source" dans les BSD. Chacun fait comme il veut. Forcément, si c'est ta machine perso, tu préfèrerais sans doute compiler un soft qui soit "optimisé". Maintenant, pour ne pas avoir fait gaffe, je te promets que lancer un make install pour openoffice, c'était vraiment pas malin. Bref, il n'y a pas de règle particulière concernant les logiciels. Pire : quand tu es en production, tu auras plutôt tendance à t'appuyer sur des binaires plutôt que des sources, pour des raisons de sécurité évidentes (si y'a un patch qui sort, tu dois tout recompiler. Si c'est un binaire, c'est quand même plus simple).
[^] # Re: Gestion des partitions BSD
Posté par lasher . En réponse à la dépêche Sortie de FreeBSD 6.0. Évalué à 7.
[^] # Re: Critères éthiques
Posté par lasher . En réponse au journal Un nouveau logo pour FreeBSD. Évalué à 0.
[^] # Re: Sauf que ...
Posté par lasher . En réponse à la dépêche Wine débarque bientôt. Évalué à 1.
Bouais. Beaucoup moins. Et le JIT de Java permet clairement bien plus d'optimisations que ce que tu sembles dire. Attention, je ne dis pas qu'on obtiendra au final quelque chose d'optimal, mais certainement pas aussi "mauvais" que ce que tu sembles croire (même si tu rappelles bien que les perfs obtenues sont déjà pas mal ;-) ).
Je ne suis pas un fan absolu de Java, mais les JVM avec JIT sont très bien pensées, et le langage permet vraiment beaucoup de choses au niveau optimisations... Ah, si seulement il était libre ...
[^] # Re: Sauf que ...
Posté par lasher . En réponse à la dépêche Wine débarque bientôt. Évalué à 2.
Voilà :
« Java Signal Processing : FFTs with bytecodes » (John Glossner, Jesse Thilo, Stamatis Vassiliadis). Le papier date de 98, et depuis Java a fait pas mal de progrès dans le domaine de l'optimisation en temps (en espace - donc en mémoire - c'est autre chose). Pour te résumer l'article, faire des transformées de Fourier rapides avec Java, c'est faisable. L'expérience avait été faite sur des Ultra-Sparc II avec 128Mo de RAM, avec Java 1.1.4 (sur diverses JVM) et comparé avec gcc 2.7. Au final, Java est en moyenne 2 à 3 fois plus lent qu'un code C optimisé. Mais c'était en 98. Depuis, on a encore largement amélioré les optimisations concernant Java (et aussi celles concernant C avec GCC, mais moins -- les efforts à partir de GCC 3 sont bien plus concentrés sur C++).
« Developing numerical libraries in Java » (Ronald F. Boisvert, Jack J. Dongarra, Roldan Pozo, Karin A. Remington, G.W. Stewart). Résultats (là encore, il ne faut pas oublier qu'on est en 98) : oui ben, y'a plein de trucs bien en Java, mais bon, quand même, c'est pas la panacée, y'a plein d'autres trucs qui manquent, du coup il faut faire plus d'effort quand on est programmeur pour avoir de bons résultats. Mais les travaux sur le JIT ont l'air intéressants, ça devrait booster les résultats.
Et miracle, c'est le cas.
Dernière chose, je te conseille de mater à cette adresse : http://shootout.alioth.debian.org/benchmark.php?test=all&(...)
Tu y verras entre autres les différents résultats obtenus par des benches dans le domaine du calcul [1]. Et que Java se situe devant g++ et le compilo c++ d'intel.
Mais à part ça, Java, c'est lent.
[1] évidemment, il en faut pas oublier ce que dit l'auteur sur le site, à propos des biais qu'on trouve dans ce genre de tests.
[^] # Re: Sauf que ...
Posté par lasher . En réponse à la dépêche Wine débarque bientôt. Évalué à 0.
Eclipse + JBoss + plugins Eclipse : tourne bien au début. Après plusieurs heures de dév, de démarrage/arrêt du serveur, de chargement de diverses webapps de test, etc... La machine est inutilisable, et met parfois une bonne minute (voire plus) avant de prendre en compte un quelconque élément en entrée (clavier, souris).
Deux solutions pour ça : trifouiller la JVM (allocation de +/- de RAM, etc.), et ... rajouter 512Mo de RAM. Grâce à ça, on peut avoir plus de temps avant que la machine ne se mette à rammer. Et donc, je pouvais faire mes heures de bureau sans accroc. Evidemment, ce genre de "solution" n'est pas viable pour un serveur en production. Mais dans ce cas, il vaudrait mieux avoir un vrai admin, qui sache comment on configure correctement une JVM.
Bref. Java n'est pas lent, mais bouffe effectivement de la mémoire, et Windows semble mal gérer celle-ci, ce qui ralentit le système au final.
Sous linux, Eclipse est moins bien, mais au moins je n'ai jamais eu les problèmes constatés ci-dessus.
[^] # Re: Compatibilite binaire
Posté par lasher . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 0.
Bon, je suis de mauvais foi, et j'ai compris l'argument initial. C'est vrai qu'il vaut mieux tout recasser de temps en temps. Mais généralement, cela signifie que le modèle suivi n'est plus pertinent. Donc au contraire, je ne comprends pas trop pourquoi une bibliothèque changerait de façon drastique sa structure à ses balbutiements. Au pire, on y rajoute de plus en plus de fonctionnalités, mais les premiers symboles restent là.
[^] # Re: ...
Posté par lasher . En réponse à la dépêche OpenBSD fête ses 10 ans !. Évalué à 3.
Cela dit, ils n'avaient pas totalement tort, vu que dans le test, ce dernier disait qu'il n'avait eu que des problèmes à l'install (si ça arrive, on peut dire que c'est la faute de l'OS, mais on peut aussi se demander si ce n'était pas un problème situé entre la chaise et le clavier).
[^] # Re: Pas très surprenant...
Posté par lasher . En réponse à la dépêche Le Wikiquote francophone risque de fermer sans réaction de sa communauté. Évalué à 1.
[^] # Re: 1st post
Posté par lasher . En réponse à la dépêche Le moteur du jeu Quake 3 en GPL. Évalué à 2.
[^] # Re: Chouette, un troll
Posté par lasher . En réponse au journal Les jeux vidéo libres. Évalué à 2.
Ca dépend. Le travail d'un menuisier est-il une oeuvre d'art ? Le travail de tout artisan en est-il une ? Si tu me réponds oui, alors pourquoi pas. Mais dans mon esprit, je ne vois pas du tout en quoi du code serait une oeuvre d'art. Pour moi une oeuvre d'art doit pouvoir être accessible à tout le monde, mais si ce "tout le monde" ne comprend pas forcément la même chose que ce qu'a voulu dire l'auteur.
Dans le cadre de code informatique, tout le monde n'est pas capable de le comprendre même parmi les gens du métier. Je ne peux pas considérer ça comme de l'art.
[^] # Re: Chouette, un troll
Posté par lasher . En réponse au journal Les jeux vidéo libres. Évalué à 1.
[^] # Re: Enfin : le Sage de la Montagne a parlé !
Posté par lasher . En réponse au journal Plus le droit de travailler !. Évalué à 2.
Oui enfin ça dépend lesquels. Je connais des gens qui ont quitté volontairement leur job parce qu'ils n'avaient pas pris de vacances en deux ans, et qu'ils n'en pouvaient plus - surtout que leur job commençait sérieusement à les emm...bêter. Jusque là, OK, je peux comprendre (même si honnêtement je trouve que se plaindre de n'avoir pas pris de vacances alors qu'il "suffisait" de les poser, je trouve ça limite).
Par contre, ces mêmes personnes ont profité du système d'indemnités chômage en y allant jusqu'au trognon, en prétextant que "puisque le système laisse faire, alors j'en profite". Ces mêmes personnes pensent qu'évidemment, on fait payer trop de charges aux patrons, que la flexibilité n'est pas assez importante, ...
Evidemment, il y a plein de chômeurs qui voudraient ne plus l'être. Mais au moins au début de leur chômage, j'en ai rencontré d'autres qui se sont permis des "vacances" (de plus ou moins longue durée).
[^] # Re: en même temps..
Posté par lasher . En réponse au journal Quand Stallman nous demande de ne pas acheter Harry Potter. Évalué à 3.
Sinon je suis tout à fait d'accord avec toi. J'ai lu les six volumes, (je me suis pas précipité pour acheter le 6è, il se trouve que je faisais mes courses et que je suis tombé dessus), et je trouve que, même si ce n'est pas forcément ce que j'ai lu de mieux, c'est tout de même une très bonne série de bouquins, bien construite.
[^] # Re: euh...
Posté par lasher . En réponse à la dépêche Un jeu sous licence libre remporte le FLIP. Évalué à 1.
[^] # Re: Changement de titre
Posté par lasher . En réponse au journal Adeptes du P2P, prenez gardes !. Évalué à 2.
[^] # Re: une bouteille de champ' virtuelle
Posté par lasher . En réponse à la dépêche Les eurodéputés rejettent la directive sur le brevet des logiciels. Évalué à 1.
En fait, d'après mon dictionnaire, si.
[^] # Re: Que veux-tu faire ?
Posté par lasher . En réponse au journal Commencer à programmer ?. Évalué à 1.
Euh, boucles, affectations, tableaux, fonctions, tout ça tu le retrouves (heureusement) dans tous les langages. Quant aux références, c'est du Java et pas du C. Tiens d'ailleurs, un truc tout bête :
en C, tout est passé par valeur. TOUT. En Java, les types primitifs sont passés par valeur (donc par copie), mais tous les types "complexes" (les objets) sont passés par référence. Et note bien que j'ai parlé de la simplicité du langage/de sa syntaxe, pas de la facilité à programmer avec le langage C. Je trouve que ce dernier est plutôt rapide à mettre en oeuvre justement parce qu'il n'y a pas trop de concepts à connaître (mis à part la notion de pointeur, mais honnêtement, comme je l'ai dit, il n'y a pas besoin de manipuler les pointeurs pour commencer à programmer).
quand je parlais d'algo, je pensais plutôt à des trucs basiques comme un quick sort ou la création de listes chainées
Quand tu commences à programmer, un quicksort ou un algo de listes chaînées n'est pas simple, quel que soit le langage.
Prend le code Java (ou Ruby ou O'Caml) et compare avec un code en C
Je ne connais pas Ruby. En ce qui concerne Java, si tu n'as aucune notion de comment est allouée la mémoire, de comment fonctionne le garbage collector, etc., je ne vois pas comment tu peux comprendre la signification d'un NullPointerException. Java te fait croire qu'il n'y a pas de pointeurs, alors qu'il n'y a que ça, partout. Si tu ne comprends pas le principe d'une référence, je ne vois pas trop comment tu peux faire des choses un tant soit peu complexes en Java, ce qui revient à comprendre les pointeurs en C. Dans les deux cas, il faut parler d'adresse mémoire.
Donc le paradigme objet ne te servira à pas grand chose au début, la seule chose c'est que Java par exemple permet de se détacher un minimun de la machine
La méthode objet ne sert à rien au début. Si on te fait prendre l'habitude dès le départ (enfin, très vite, dirons-nous) de programmer sous forme de modules (fonctions/procédures), les concepts objets seront relativement simples à comprendre (il faut quand même une période d'adaptation, bien sûr). Et justement, prends Java : lorsque tu fais de la prog non objet, tu te retrouves avec le corps minimal suivant :
public class MaClasse {
public static void main(String[] args) {
// programme
}
}
Tu dois donc dire à l'étudiant en prog "oui bon, ben, oublie tout le squelette pour le moment, je t'expliquerai plus tard". En C, tu peux aisément expliquer les choses :
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
/* ... *
return EXIT_SUCCESS;
}
(et encore, les #include étant comparables aux import, je ne devrais pas les mettre dans le "source").
Pour ce qui est des macros, tu ne les utilises pas au début, et bizarrement ça ne manque pas.
[^] # Re: Que veux-tu faire ?
Posté par lasher . En réponse au journal Commencer à programmer ?. Évalué à 1.
Ben justement, le langage est simple. Pour apprendre à programmer, y'a rien de tel : tu codes ton truc, et dès que tu as besoin d'une fonctionnalité avancée, tu te la programmes. C'est comme ça qu'on apprend. C'est très très formateur d'apprendre à réécrire la libc par exemple (c'est d'ailleurs plus ou moins l'approche utilisée dans le Kernighan & Ritchie, mais le bouquin en lui-même n'est pas pour les débutants).
Cela dit, tu peux déjà programmer pas mal de choses en C rien qu'avec la notion de tableaux.
Et tu utilises une syntaxe "propre" pour masquer les pointeurs dans les cas où tu en as besoin, du genre
typedef char CHAINE20[21];
Plus le langage est simple, plus il est facile d'apprendre a s'en servir. Cela dit, faire de la programmation « sérieuse » proprement en C, c'est une autre paire de manches.
De plus, commencer par utiliser un langage totalement orienté objet (comme Java ou Ruby), même si on peut toujours détourner le langage pour en garder le côté procédural, est une mauvaise idée à mon avis. Les algos sont rarement orientés objet au départ; ils sont adaptés au paradigme objet, mais proviennent pour la plupart des travaux de recherche effectués dans les années 60/70...
[^] # Re: lire l'histoire des projets bsd
Posté par lasher . En réponse à la dépêche ESR : «Nous n'avons plus besoin de la GPL.». Évalué à 2.
[^] # Re: [HS]Vive les armes à feu ?!
Posté par lasher . En réponse à la dépêche ESR : «Nous n'avons plus besoin de la GPL.». Évalué à 8.
Absolument pas.
Il dit que ce qui est la cause de la violence aux USA est l'injection permanente de peur dans l'esprit des gens. Il prend la télévision comme exemple, mais il sous-entend surtout que les média les plus utilisés par la grande majorité des étatsuniens véhiculent une propagande de la peur. Pour avoir de la famille là-bas, je peux te dire que c'est exactement comme ça. Lorsqu'il y avait [1] la 2è guerre du golfe, on maintenant dans l'esprit des gens qu'ils étaient susceptibles d'être attaqués à tout moment, afin de les gardés convaincus du bien fondé de cette "guerre préventive". Le propos de Moore est de dire que la violence naît de la peur. Et franchement, c'est vrai. Regarde en France : un Sarkozy promet de nettoyer une cité (avec toute la démagogie qui va avec), et il apparaît en homme fort, qui va nous débarrasser de la racaille comm... euh, de la racaille. C'est entre autres grâce à la peur que ce genre de choses est possible.
[1] enfin, "avait", "a", ... Bref, je sais plus trop là. :-)