lasher a écrit 2738 commentaires

« [Parlant de Buffy saison 1] Les épisodes sont pour la plupart fasconnés sur le même schéma: on prend un des petits malheurs de la vie lycéenne, on le rend concret sous une forme paranormale, et on saupoudre d'humour pour faire passer la sauce. »

De l'aveu de Whedon, ils ont repris pour chacun des épisodes de la première saison des thèmes de films d'horreur des années 50 (genre Hammer, etc). Ce sont clairement des remakes d'une manière ou d'une autre. :)

Alors qu'en utilisant « passage à l'échelle », on ne précise pas de quelle échelle on parle, ce qui est bien pratique. ;-)

Par exemple, si l'échelle considérée est la charge, alors « passer à l'échelle » signifie bien « correctement monter en charge ». Dans le cas de programmes composé de calculs parallèles, passer à l'échelle peut se faire de deux façons :
1/ On augmente la taille du problème à résoudre, et l'algorithme fait que plus il y a de détails (pour une simulation par exemple), plus on peut ajouter des unités de calcul.
2/ On rajoute des unités de calcul, et l'algorithme étant intrinsèquement parallèle, alors le temps de calcul est bel et bien réduit (quasi-)proportionnellement au nombre d'unités de calcul disponibles.

Bref,  « passage à l'échelle », c'est bon, mangez-en.

« [À propos d'un code qui ne linkait pas] question qui me turlupine, ils faisaient comment avant ? »
Il (le collègue) faisait pas. :)

Ça s'est passé un peu comme ça :
Collègue: Rah, ça compile mais à l'édition de lien ça me plante !
Moi: T'as essayé GOLD ?
Collègue: Gné ?
[s'en suit une courte explication, et une tentative du collègue avec GOLD]
Collègue: Ça marche !

Sauf que le passage à l'échelle est une bonne traduction, alors que montée en charge est incomplet. Dans le cas de ce programme précis, ça suffit, mais (au hasard) si je parle de calcul intensif et que je demande quelle est la « scalabilité » d'un programme donnée, je demande en fait à quel point il est parallélisable (i.e. à quel point il peut passer d'une échelle de x processeurs à 10x processeurs).

« GOLD est encore jeune et pas tout à fait au même niveau que le bon vieux GNU ld. »
Parfois plus lent peut-être, mais en pratique, je connais des collègues autour qui n'ont pu effectuer l'édition de lien de leur que grâce à GOLD (ld finissait en out-of-memory).

C'est toujours vrai. Un goto est un saut inconditionnel. Suivant la façon dont il est placé, le compilateur peut parfaitement remplacer le goto par un if/while/etc si c'est « évident », mais la plupart du temps tu vas surtout le perdre.

Ben c'est utilisé en prog système, où les ressources au final sont plutôt limitées. :)

Non, il a eu affaire à des pédagogues. Mes profs d'IUT m'expliquaient qu'ils préféraient des étudiants « vierges » (au sens informatique hein, bande de dégueulasses). Tout simplement parce que comme ça, il n'y avait aucune mauvaise habitude à redresser. Et justement, des élèves qui arrivent en cours et qui croient savoir ce qu'ils font (au hasard, en utilisant scanf sans en connaître tous les dangers), c'est relativement fréquent. Interdire certaines constructions dans le cadre d'un cours me semble plutôt intelligent. On forme des gens à structurer leurs programmes, et le goto casse la structure (parfois, c'est ce qui fait que ledit programme est plus clair à lire, mais c'est très très rare).

Maintenant, d'un point de vue compilation, le goto est extrêmement dangereux dans 90% des cas:

1/ Un goto qui revient en arrière, ça revient à faire une boucle, sans que le compilateur puisse facilement le deviner (enfin, si, mais non).
2/ Un goto qui sort d'une structure de contrôle, c'est mal -- surtout si c'est une boucle. Ça empêche le compilateur de générer un code optimisé. Évidemment, s'il s'agit d'un truc du genre if (catastrope_détectée) goto CATASTROPHE; c'est différent, vu que ça revient à implémenter des exceptions... Mais dans tous les cas, c'est à réserver pour des utilisations « uniques ».
3/ Un goto qui arrive en plein milieu d'une boucle, c'est criminel. Il faut pendre haut et court le mec qui fait ça.

« C'est marrant, parce que ce type de profs trouvera normal d'abuser de trucs genre break, continue, switch/case »

Tu généralises, mais cette généralisation est fausse. J'avais des profs anti-goto, qui tout simplement ne nous ont jamais dit que ça existait, sauf une fois en cours, en nous expliquant que dans 90% des projets, ce serait inutile (et que dans les projets qu'ils nous donneraient, ça vaudrait des points en moins). Oui, ils disaient en gros « le goto, c'est mal ». Et ils ont raison. Il y a des cas particuliers où c'est justifié, mais presque jamais. Pour le break, c'était autorisé à condition d'avoir une utilité réelle (i.e. : qu'on ne puisse pas changer la structure de l'algo d'abord, et si c'est réellement le mieux auquel on puisse penser, alors bon, pourquoi pas).

De plus, je ne vois pas ce que switch vient faire là-dedans. Un switch-case n'a rien à voir avec goto/break, sauf à vouloir faire des trucs moches genre duff's device.

« Ca fait des années que je n'ai pas programmé en java, mais je ne sais plus quelle version de compilateur mettait comme message, en cas d'utilisation de goto : "goto not allowed" »

Ce n'est pas une erreur de syntaxe à mon sens. Le mot-clef "goto" est bien réservé en Java, pour en interdire l'utilisation. :)

Tout à fait. Exemple:

if (pulseaudio.enabled()) goto CATASTROPHE;

Euh. Si je sors un logiciel libre qui s'amuse à écrire toujours au même endroit d'un disque SSD par exemple, et qui finit par bousiller des cellules (ou quelle que soit la terminologie à employer), ce logiciel est responsable de l'usure de mon matériel, et il n'est pas du tout impossible qu'en droit français je puisse me retourner contre l'auteur du soft (ou du patch, ou ...). La clause du « utilisez ce logiciel à vos risques et périls » n'est absolument pas valable, et si je publie un soft et que je suis identifiable comme en étant l'auteur, je dois répondre de certains dysfonctionnements graves que celui-ci peut amener.

En pratique, au moins en France, le coup du « si mon soft fait exploser ton PC c'est pas ma faute », ça n'a pas de valeur légale, et tu peux te retourner contre l'éditeur/le créateur du logiciel.

C et ASM je peux comprendre. Si tu fais du "vrai" C++ (pas du « C avec des classes »), ça devrait être relativement safe à condition d'utiliser le plus possible la bibliothèque standard.

Cela dit, vouloir faire du C absolument (ou de l'ASM à ce niveau), pour une application complète, je trouve ça dommage, car chronophage. Je le dis d'autant plus librement que mon activité fait que je fais du C et de l'ASM tous les jours. :) Pas besoin d'invoquer l'argument (pertinent) de la sécurité à mon sens. Utiliser n'importe quel langage de plus haut niveau est bien souvent un gain de temps de développement tellement grand que ça devrait être suffisant pour convaincre n'importe qui de changer de langage la plupart du temps. Après il reste l'embarqué et le calcul haute-performance où le C reste intéressant.

Au moment où ils ont été créés, les brevets (tout comme le droit d'auteur) n'avaient rien de théorique, ils étaient là pour au contraire contrer une réalité bien pratique (dans le cas du droit d'auteur, le fait que les éditeurs pillaient et revendaient sans vergogne les créations des musiciens/écrivains/etc, sans rien reverser à leur auteur -- le public n'était pas du tout visé). À l'époque ça avait du sens. Et encore, cf. « Du bon usage de la piraterie » (de F.Latrive), qui nous cite du Hugo par exemple, pour montrer que tout le monde n'était pas d'accord avec cet usage...

L'important selon moi est de se poser la question de l'intérêt de nos jours. Avec nos capacités de dupliquer le savoir, de diffuser l'information et la création, ce système de brevets est-il encore pertinent ? Si absolument tout le monde peut avoir accès à ces idées, et est éduqué pour savoir comment en tirer parti, les brevets sont-ils encore utiles ? Certains répondront que oui, car tout le monde n'a pas les capacités intellectuelles/industrielles/whatever de produire le résultat de ces idées, et donc certaines boites vont piller sans vergogne là encore dans les vraies bonnes et nouvelles idées. Pourquoi pas, mais je n'en suis pas certain.

Suffit de lubrifier.

Tu parles de défaillances, et moi je parlerais plutôt de limitations. Une console doit d'habitude durer 5 ans « telle quelle ». Comme Nintendo semble beaucoup jouer sur le matériel un peu particulier (DS et stylet, wiimotion/wiimotion plus pour Wii), lorsqu'une limitation survient il faut bien trouver un moyen de la contourner.
Après bien sûr, il y a certainement une histoire de coût initialement genre :
« 
- Hé chef, on pourrait p'tet avoir des capteurs plus sensibles, mais ça ferait monter le coût de la console de 50 €...
- Naaaaaaan, laisse la wiimote comme elle est, comme ça en plus, quand on aura besoin de plus de précision, on pourrait faire une grosse marge sur les accessoires. En plus comme ça, on fera de la marge dès le départ sur nos consoles, contrairement à Sony & Microsoft ».

Ah non. Il ne faut pas plus payer de MÀJ que pour Windows. Le seul OS X que j'aie jamais eu (10.3) a été supporté par Apple pendant très longtemps (5 ou 6 ans), au début avec mises à jour pour les softs en place (pour fonctionnalités et sécurité), puis avec mises à jour de sécurité tout court.
Ensuite, il se trouve qu'Apple sort une nouvelle gamme tous les 1 ou 2 ans, avec la nouvelle version de leur OS et de leurs suites logicielles. C'est totalement comparable à Microsoft qui sortirait une nouvelle version de Windows tous les ans.

« Finalement, il vaut mieux acheter du matériel ouvert et documenté que du matériel ultra fermé. »
Oui enfin, si tu veux jouer avec du Cell, la PS3 est peu ou prou la seule possibilité : le prix des blades faites à base de Cell est rédhibitoire, ce qui fait que même les labos qui voudraient essayer de faire de la prog sur matériel hybride (PPU+SPUs) se sont rabattues sur des PS3. L'opinion quasi-générale de la communauté du calcul scientifique c'est que le Cell est mort, à cause de deux choses :
1/ Son prix, mais surtout
2/ Sa difficulté à le programmer efficacement.

Si on veut jouer avec des archis un peu exotiques du coup, y'a pas 50 solutions. Soit on prend de l'ARM (mais finalement il ne s'agit « que » de processeurs RISC), soit ... soit ... Ben je sais pas.

Après, ce jeu de chat et de souris concernant les màj de firmware, ça existe aussi sur Wii et pas mal d'autres matériels. Je trouve ça plutôt rigolo.

Par contre, je pense qu'une des raisons pour lesquelles la PS3 n'était trop piratée (contrairement à la Wii par ex), c'est justement qu'elle proposait d'utiliser un autre OS si on le désirait. À partir du moment où ils ont retiré cette possibilité de la Slim, ils ont nécessairement déclenché le besoin chez certains de réparer cette étourderie (pour ne pas dire ce foutage de gueule total, étant donné que la possibilité d'installer Linux était clairement considérée comme une feature avant la sortie de la console).

Quels utilisateurs ? La cible de Sony, ce sont les joueurs-utilisateurs, pas les hackers. Du coup, de leur point de vue, ils ont fait la seule chose logique : fermer la menace potentielle qui permettrait de « pirater » des jeux, et s'assurer qu'ils gardent le contrôle sur leur console (parce qu'à ce niveau là, je considère qu'il s'agit plus d'une location de matériel à coût unique très très cher ...).

On ne peut plus vrai. cf. http://geohotps3.blogspot.com/
GeoHot a réussi à accéder à l'hyperviseur de la console => il a donc accès à tout. Il a cassé les protections de la PS3 fat, je ne sais donc pas du tout s'il est possible de faire de même sur une slim.

Intel ne propose pas encore de cartes avec accélération 3D comparable à ATI et Nvidia, si ?

« un bon développeur écrira toujours du code de meilleure qualité qu'un développeur débutant (mieux testé, et donc plus fiable). »

Petit aparté : un « bon développeur » peut parfaitement être débutant. Un « mauvais développeur » peut aussi être un « développeur senior ». Bien entendu, l'expérience joue pour devenir meilleur, mais honnêtement, un bon développeur, même avec des habitudes de développement à parfaire [1], est souvent clairement bon dès le départ.



[1] Je pense à des habitudes de présentation de code, d'utilisation d'outils et de tests unitaires pour tester ledit code, etc., bref de choses qu'on apprend soit en cours, soit (plutôt) avec l'expérience.

Oui enfin tu sais, une calculatrice programmable par exemple c'est un calculateur, donc un ordinateur. Et « computer » pourrait se traduire par « calculateur » , donc par .... Tu m'as compris. :)

Si un vrai gros problème survient pendant ton stage, tu es censé en parler à ton suiveur de stage (celui du côté de ta fac ou de ton école). Je sais que le réflexe n'est pas forcément présent, mais c'est le seul moyen de se défendre en cas d'injustice, et c'est fait pour ça.

« Tu as quand même une obligation de résultat quand c'est un stage de fin d'étude et que la note donnée par l'entreprise compte dans la note finale »

Même avec des stagiaires mauvais je n'ai jamais vu une boite mettre moins que l'équivalent de la moyenne au stagiaire. Alors c'est sûr, si la boite te met un 12, tu piges assez vite qu'elle n'était pas contente (quand la moyenne tourne généralement autour de 14 ou 16 sur 20). N'empêche, à moins de vraiment être contre-productif (ce qui est différent de peu productif, tu en conviendras), aucune boite ne te saquera.

« Je voudrais aussi ajouter que des entreprises (une bonne part, de ce que j'ai pu voir et entendre) jouent le jeu avec les stagiaires (encadrement (même si souvent léger), délais plus long qu'un employé,...) »

Toutes celles qui sont suffisamment grandes niveau structure oui (genre euh, plus de 5 employés ? ;)). Blague à part, autour de moi, les stages ont tous été très très variés, avec des encadrements plus ou moins heureux.