lasher a écrit 2754 commentaires

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.

Au pire tu n'es pas embauché, ok. Mais honnêtement dans le cadre des métiers de l'info, du boulot, tu en trouves (parfois merdique je te l'accorde) relativement facilement.

Dans le cas de métiers un peu différents (édition, etc), là les stagiaires sont réellement des employés au rabais surexploités (et comme le monde de l'édition est réellement minuscule, si on se fait mal voir, on est grillé pour un bon bout de temps de pas mal de maisons d'éditions par exemple).

Je me souviens que globalement, je me mettais tout seul la pression, et pas vraiment besoin d'un chef de projet pour en rajouter, merci. :) Avec le temps (et au bout du 3è stage, le dernier, celui qui dit que normalement t'es presqu'ingé), j'ai fini par comprendre que même en faisant miroiter un CDI derrière, quand l'ambiance n'y est pas, franchement, bien bosser, tout ça, rien à foutre. Je faisais mes heures (et j'essayais de bosser bien quand même hein, conscience professionnelle, tout ça), mais il était hors de question de rester jusqu'à pas d'heure [1].

Concernant les stages de pré-embauche, oui, je comprends qu'on veuille bosser bien pour être gardé ensuite, mais à la seule condition que ce soit sans repasser par une période d'essai juste derrière (ce qui transforme effectivement le stage en CDD d'un an à pas cher ...).

[1] Chose que j'avais faite dans les deux stages précédents, tout bêtement parce que le contenu était intéressant, et que l'ambiance des deux boites donnait l'impression de faire partie de l'équipe... Comme quoi ça tient à peu de chose, d'avoir un employ^Wstagiaire qui s'investit.

Hum. En 2005 j'étais payé le SMIC pour bosser en tant que stagiaire de fin d'études. Donc je pense que les stages de dernière année d'école d'ingé qui ne sont pas payés au moins le 1/3 du SMIC, c'est plus l'exception que la règle.

Pire que ça : mon école à l'époque pouvait refuser de valider un stage s'il n'y avait pas un minimum de rémunération correcte -- ben oui, ça joue aussi sur l'image de l'école, si ses élèves doivent se contenter de quémander n'importe quel stage fut-il non rémunéré...

Je suis d'accord, avec tout de même un petit bémol : en tant que stagiaire, tu n'as pas d'obligation de résultat. L'employeur n'est donc pas censé te soumettre au même rythme de travail qu'un employé lambda. Si tu mets deux fois plus de temps qu'un mec qui bosse dans la boite depuis plus d'un an, ce n'est pas censé poser de problème, car on n'est pas censé te donner de travail dont l'avenir de la boite dépend. :) (je dis bien « pas censé », je sais bien qu'en pratique, ça se fait parfaitement ...).

T'es pas le premier que je lis/j'entends dire ça, tiens.

C'est marrant, les gens de l'ENS Lyon j'en connais un certain nombre aussi, et ils ne sont pas aussi élitistes que ceux que tu connais ... Comme quoi, ça dépend peut-être un peu des gens, non ? :)

(Après, il y a effectivement un certain nombre de personnes qui sont/sortent d'une ENS et qui ont une suffisance assez insupportable, je te l'accorde).

Tu as tout à fait raison, à une petite différence près: « Nature » avait écrit une sorte d'avertissement qui précédait l'article pour dire que c'était une recherche très controversée, et que tout le monde dans la rédaction n'était pas convaincue de la véracité de celle-ci.

« Effectivement, sur le web pas de ségrégation couleur de peau / sexe / gabarit de la personne. »
Bof. Y'a d'autres critères : un mec qui d'habitude a des « notes » positives va avoir le bénéfice du doute beaucoup plus longtemps que quelqu'un qui vient d'arriver. Je ne dis pas que ce n'est pas normal, mais du coup certaines opinions qui parfois pourraient être considérées comme « limite » seront plus facilement tolérées à cause de ça.

Et si le coup du « 1m90 90kg » IRL n'a pas de poids sur le net (et ne devrait pas en avoir en règle générale hein), je suis assez d'accord avec "kiki" sur le fait que certains se lâchent parce qu'ils ne se rendent plus compte qu'ils ont une personne « en face » d'eux.

Dans certaines applications intensives en calcul aussi, ça peut faire la différence. Du point de vue performances, s'il est possible de modifier les algos de calcul (analyse numérique en général, traitement d'image ou de signal, etc.) de façon à ce que des blocs de données soient utilisés le plus longtemps possible dans les caches, on va gagner en perf (vu que la mémoire cache est plus rapide que la RAM). Mais si à cause d'une trop grande fragmentation mémoire je me retrouve avec de la mémoire non-contiguë, ça finit par faire désordre [1].

Théoriquement, l'utilisation des « superpages » (ou « huge pages ») permet justement d'éviter des défauts de TLB, d'améliorer la façon dont les données sont mappées dans les sets des caches, etc., mais sous Linux, et particulièrement avec du x86 en tout cas, leur utilisation est plutôt difficile : sous x86 et x86-64 par exemple, les huge pages font 2 ou 4 Mio, ce qui est trop pour beaucoup d'applications. Mais si ce n'était que ça encore, ça irait. Le problème vient aussi du fait que pour utiliser ces grosses pages, il faut en gros les allouer au boot de la machine, juste au moment de l'init de Linux, qui va réserver ces pages au démarrage. La mémoire ainsi réservée est perdue pour les autres programmes. Et si j'avais besoin d'une grosse page de plus, ben tant pis (si je me souviens bien, la HugePageTLB des archis x86 est de 4 entrées, de toute manière ...).

Pour le coup, il y a un problème inhérent à l'archi actuelle des x86/x86_64, car une page physique fait obligatoirement 4kio. Sur d'autres architectures (Alpha, Itanium par ex), il existe plusieurs tailles possibles pour les pages mémoire, ce qui permet de limiter la fragmentation de la mémoire en fonction de l'utilisation faite de la machine [2].


[1] Ne pas me demander pourquoi, je suis encore en train d'essayer de piger. Pour simplifier, si je lance une appli de calcul intensif au boot d'une machine je vais avoir un certain temps d'exécution. Si je la relance après plusieurs heures, où entre temps j'ai joué avec Eclipse, Firefox, que sais-je (n'importe quoi qui fragmente bien la mémoire), si ensuite je lance mon appli de calcul qui fait un bon gros malloc/mmap au début, la mémoire réellement allouée va être fragmentée tout partout, et il y a un impact direct sur la performance.

[2] Bon OK, en pratique ça veut juste dire qu'on a des blocs de mémoire contiguë plus gros (par exemple sur Itanium 2, je crois que les distribs Red Hat ont mis 64kio par défaut pour une page normale, et 256 Mio pour une huge page). En même temps, quand on a dans les 1 à 4Gio de RAM comme c'est de plus en plus fréquent, on peut se permettre d'avoir des tailles de pages plus grosses ! Surtout si une grande partie de celle-ci sert de cache disque : ça n'enlèvera a priori rien aux perfs. Au contraire.

Quelques précisions:

« Il [le programmeur C] utilise pour gérer tout cela des pointeurs vers la mémoire virtuelle de la machine, la RAM. »

La RAM, c'est la mémoire physique, pas la mémoire virtuelle. En fait le C ne sait pas ce qu'est que la RAM en elle-même, il a juste une notion de « mémoire ».

Ah et juste parce qu'il est encore vendredi quelque part dans le monde: le C est un langage de haut-niveau. O:-)