Ca permet de comprendre certains concepts des langages de plus haut niveau: utilisation de la mémoire, pointeurs, pile, etc. Par exemple, comment expliquer les techniques de tail-call optimisation (je parle du cas général et pas de la transformation des appels récursifs en boucle), des trampolines et autres joyeusetés sans parler de la pile d'appel? Ou même, juste comprendre ce que sont les variables, la différence entre les locales et les globales (ou entre champs/méthodes, statiques et dynamiques). La différence entre une affectation et une copie pour de très très nombreuses structures de données.
La liste est longue. En quelques mots, les langages de plus haut niveau restent magiques tant qu'on a pas une vision claire ce qui se passe sous le tapis.
Premièrement car je ne connaissais pas MMIX. Je l'avoue, je n'ai pas (encore) lu The Art of Computer Programming. Donc merci pour l'info. Deuxièmement, après avoir lu sa spécification, il est nettement plus complexe que l'assembleur bêta, trop complexe pour ce cours. Bêta est extrêmement simple: uniquement 32 instructions, pas de cache ni flottants. Toute l'architecture peut facilement être expliquée en une ou deux heures, ce qui laisse le champs libre pour le reste. Cela dit, dans le but de former des professionnels de la programmation en assembleur moderne, introduire MMIX semble être judicieux.
Totalement d'accord. La formation ne fait pas tout. Pour que ca marche il faut que ceux qui la suivent soient dans un état d'esprit favorable. Je vois beaucoup trop d'étudiants ne penser qu'à la note au lieu de d'être curieux. A la fin ca donne des professionnels qui ont de vagues souvenir comme "ah oui le libre ca veut dire gratuit". Mis à part les mettre devant un gros projet de rétro-ingénierie parce que tel ou tel logiciel n'est pas open-source et recaler ceux qui ne développerait pas une sensibilité à ceux problèmes, je vois pas ce qu'on peut faire de plus.
Tout dépend de l'espace de nom que tu considères. Pour l'informaticien, tant que c'est du code qui tourne, c'est du pareil au même. En revanche pour le marketeux, alors là rien à voir: un logiciel c'est has been, ringard, lourd, j'oserais dire antique. Alors qu'une App c'est moderne, c'est hype et ca fait saliver le consommateur lambda qui sera prêt à dilapider ses deniers durement gagnés pour la dernière App de pets le faisant briller en société.
Euh … il faudrait peut être se renseigner quelque peu avant de poster. Linus Torvalds résumait très bien les choses. Linux n'a jamais eu pour but de révolutionner l'architecture des OS. Il à toujours reposé sur des concepts éprouvé (UNIX) avec le pragmatisme comme mot d'ordre. Linus voulait un OS qui marche et c'est ce qui fait à mon avis l'un des points capitaux de Linux.
L'approche d'Hurd est radicalement différente. Le Hurd est une véritable refonte des concepts fondateurs d'un OS. Le concept de transducteur est tout sauf simple, le tout-service l'est tout autant. Je me permet de faire un parallèle entre le couple UNIX/Linux et Plan9/Hurd. Or force est de constater que tout révolutionner (avec ce que cela implique de boulot pour tout refaire) n'intéresse encore que peu de monde (normal, l'existant est pour l'instant bien suffisant).
Bref ne confondons pas tout. La réalité c'est qu'on a besoin des deux et que les opposer est une bêtise. L'approche pragmatique sans idéaux iraient n'importe ou et se perdrait vite, et les idéaux sans pragmatisme n'iraient nulle part.
Pour approfondir, il y a également son rapport technique The ZINC experiment décrit avec moultes détails les choix d'implémentation de CAML (ca date quand même un peu). Tant qu'a ne pas bouder son plaisir, il y a le sublime The Implementation of Functional Programming Languages par Simon Peyton Jones. Bonne lecture.
Haskell est gambas sont trop différents pour qu'une comparaison soit quelque peu pertinente. Pour la faire courte, Haskell est un langage fonctionnel pure, non strict et lazy. Il n'a pas de couche objet (Go non plus me semble t'il) et est compilé (même s'il est possible d’écrire des scripts). Bref rien à voir avec Gambas.
A part ça, très beau boulot et excellente dépêche!
Posté par GTof .
En réponse au journal fasd.
Évalué à 1.
Mais d'ailleurs, quel intérêt de programmer avec autre chose que des scripts shell ?
Mais voyons, l'intérêt des autres langages est de servir de faire-valoir aux seuls vrais langages dignes de ce noms que sont Shell, TeX, brainfuck et consorts. Tel le Yin et le Yang, le bien et le mal, les langages de vrais geeks et ceux des kevins.
A part perdre 30% du prix, je ne vois pas l'intérêt d'utiliser une plateforme de vente.
A vérifier, mais il me semble qu'IndieVania prend pas ou peu de marge. Certes c'est pas du Desura avec auto-patching et compagnie mais personnellement j'aime bien avoir les fichiers d'installation. Histoire d'être sur que je puisse encore jouer à mes jeux même si la plateforme meurt (qui peut dire si le steam-like X ou Y sera éternel?).
On n'est pas sur DabranletteFrenchPage, tes désirs hétérosexuels masculins tu les gardes pour les soirées entre potes
Euh … le terme "branlette" désigne aussi bien masturbation masculine que féminine. Et tout le monde sait que toutes les femmes sont prudes, frigides, avec une avertion profonde pour tout allusion qui touche de près ou de loin le sexe. Et puis c'est quoi cette histoire de thé? Depuis quand les geekettes ne prennent plus de bière?
PS: Te rens tu compte que, bien que prétendant le dénoncer, ton commentaire est on ne peut plus sexiste?
Certes mais LuaTeX c'est tricher. Plus sérieusement, compiler vers du TeX a l'avantage de rester dans un monde homogène et tres stable. De plus, l'objectif a terme est d'intégrer un système de type à la ML, ce dont ne dispose pas Lua. En résumé, le but est de proposer des constructions évolués tout en restant 100% compatible avec l'existant. Et puis la programmation en TeX est certes difficile mais très intéressante et riche d'enseignement.
Ne confondons pas tout, les différents projets libres et les jeux indie proprio ont des différences importantes et ca à a des conséquences sur leur mode de rémunération/dons. Les jeux indie proprios sont conçus dans l'optique de produire sous 3 ans maximum un produit fini de qualité suffisante pour remporter un certain succès.
Alors que les jeux libres, dont bon nombre sont de très grande qualité bien supérieure à la majorité des jeux indie, n'ont pas cette logique de production d'un produit fini a court ou moyen terme. Mais une logique de projet ouvert sur la durée (Ca fait des années que Battle For Wesnoth ou XMoto et tant d'autres sont déjà impressionnant de qualités).
Acheter un jeux indie classique c'est acheter un produit fini, donner a un projet libre c'est participer a un projet. Si on regarde les campagnes se dons de Wikipedia, on voit bien que quand un projet fait suffisemment parler de lui et demande des fond pour continuer à une base suffisante d'utilisateur, ca marche.
Seulement voila, les jeux libres, malgrè leur très grande qualité ne sont pas du tout dans la logique de l'évènement, créant une attente, faisant parler d'eux massivement sur une courte durée (les jeux indie ne font pas le buzz pendant des années). Sauf peut être Wildfire Games qui le fait un peu.
le secret de la correspondance privée n'est pas acquis en milieu professionnel, il y a eu pas mal de jurisprudences un peu contradictoires
Même si tu n'es pas censé lire tes mails privés ou gérer tes comptes au boulot, il y a des boites où tu dois avancer les frais pour certaines missions que ta boites rembourse ensuite. Tu peut donc être amené dans le cadre de ton boulot a utiliser des données privées (banquaire, mail, ...) avec le proxy espion de la boite. La boite n'est pas forcément mal attentionné, mais des données privées qui fuites, ca arrive. Et la, la responsabilité de la boite peut sans doute être engagée.
Il faut noter que les HIB font réellement un efforts pour le support Linux. Contrairement à ce que je pensais naïvement, ce n'est pas toujours les développeurs d'un jeu qui le portent sous GNU/Linux mais dans le cas des HIB il semble que ce soit bien souvent Ryan_C._Gordon (béni soit il!). J'ai pas les stats mais de mémoire, pas mal de jeux ont débuté sous linux avec les HIB. Certains jeux (lugaru,...) sont même passé open source avec le HIB.
Les Indie Royale sont juste des bundle comme il en existe tant sur toutes les plateforme de distribution. Le précédent n'avait (encore de mémoire) aucun jeu sous Linux mais il se trouve que celui ci contient des jeux Charlie's Games qui sont semble il systématiquement sous Linux (en tout cas j'ai jamais eu de problème avec).
Pour ce qui est des ports Linux dans les HIB, les seuls problèmes que j'ai eu venaient, semble t-il des incompatibilités entre ma version de X.org et les bibliothèques fournies avec certains jeux (les libSDL_*.so, etc ...). Dans tous les cas, utiliser les libs de ma distribution a la place de celles fournies à réglé le problème (la dépôt multilib sous Arch fait des miracles!).
C'est comme si tu voulais comparer Nutella et noisettes.
Tu veux dire qu'a du Linux dans un MacBook? Ah ben oui biensur ... maintenant qu'on sait qu'Android a été volé à Apple ...
L'humilité est toute à son honneur mais Unix n'est pas qu'un système qui, par chance, a bien marché mais avant tout le fruit d'une philosophie (une collection d'outils combinables qui ne font qu'une seule tâche mais la font bien, le "tout fichier", ....) qui reste encore aujourd'hui très pertinente et devraient être plus suivie. Tout le monde ne peut pas en dire autant, alors certes il n'était pas seul, et était au bon endroit au bon moment, mais lui il a vraiment révolutionné l'informatique. Et ca c'est quand même pas rien.
PS: quel dommage que Plan9 n'est pas eu le même succès qu'Unix :(
Remplacer JavaScript, pourquoi pas. Même si Fabrice Bellard arrive a en faire des merveilles, JS est quand même pas l'option la plus adaptée pour les performances. Mais pourquoi diable un nouveau langage "haut"-niveau? Surtout que rien ne force à développer en JS pour tourner sur le navigateur, les langages qui se compilent en JS sont légion. J'aurais plutôt vu une approche à la Mono/.NET avec un langage très bas niveau qui s'exécute rapidement sur le navigateur et une flopée de langages intercompatibles qui se compilent dedans. Car non l'analyse lexicale et syntaxique n'a pas à être fait à la volé par le navigateur par le navigateur et encore moins la vérification de types!
Pourquoi pas le support du bytecode LLVM dans les navigateur? Ce serait possible?
Il faut aussi prendre en compte l'évolution du nombre de contraventions. Plus les gens respecteront les limitations, moins ce sera rentable.
Enfin pour ce qui concerne le sujet de de l'article, quelques chiffres justifient d'éviter de pouvoir localiser les radars. Rendre illégales les applis de localisation ne sera certes pas efficace à 100% mais au moins ca en ralentira pas mal.
Et contrairement au contournement des DRM, qui peut servir à plein de bonnes choses dont l'interopérabilité. J'ai du mal à voir les usages légitimes de la localisation des radars.
Justement, je ne critique pas Linus sur la technique mais justement sur son manque d'ouverture pour le reste. C'est le célèbre débat Torvalds/Stallman, open/free software. Si on pend comme principe de base que ces seules préoccupations sont la qualité du code et la propagation de Linux, sa position est totalement fondée. C'est pour cela que je disais qu'il est intélligent. Mais y a pas que la technique dans la vie, et son refus de le voir est justement ce que je trouve "con" chez lui.
[^] # Re: Étudiant qui lève le doigt
Posté par GTof . En réponse au journal Alpha: une machine bêta avec écran.. Évalué à 9.
Ca permet de comprendre certains concepts des langages de plus haut niveau: utilisation de la mémoire, pointeurs, pile, etc. Par exemple, comment expliquer les techniques de tail-call optimisation (je parle du cas général et pas de la transformation des appels récursifs en boucle), des trampolines et autres joyeusetés sans parler de la pile d'appel? Ou même, juste comprendre ce que sont les variables, la différence entre les locales et les globales (ou entre champs/méthodes, statiques et dynamiques). La différence entre une affectation et une copie pour de très très nombreuses structures de données.
La liste est longue. En quelques mots, les langages de plus haut niveau restent magiques tant qu'on a pas une vision claire ce qui se passe sous le tapis.
[^] # Re: MMIX ?
Posté par GTof . En réponse au journal Alpha: une machine bêta avec écran.. Évalué à 2.
Premièrement car je ne connaissais pas MMIX. Je l'avoue, je n'ai pas (encore) lu The Art of Computer Programming. Donc merci pour l'info. Deuxièmement, après avoir lu sa spécification, il est nettement plus complexe que l'assembleur bêta, trop complexe pour ce cours. Bêta est extrêmement simple: uniquement 32 instructions, pas de cache ni flottants. Toute l'architecture peut facilement être expliquée en une ou deux heures, ce qui laisse le champs libre pour le reste. Cela dit, dans le but de former des professionnels de la programmation en assembleur moderne, introduire MMIX semble être judicieux.
[^] # Re: Rien de nouveau
Posté par GTof . En réponse au journal Vendre de l'open source illégal??. Évalué à 2.
Totalement d'accord. La formation ne fait pas tout. Pour que ca marche il faut que ceux qui la suivent soient dans un état d'esprit favorable. Je vois beaucoup trop d'étudiants ne penser qu'à la note au lieu de d'être curieux. A la fin ca donne des professionnels qui ont de vagues souvenir comme "ah oui le libre ca veut dire gratuit". Mis à part les mettre devant un gros projet de rétro-ingénierie parce que tel ou tel logiciel n'est pas open-source et recaler ceux qui ne développerait pas une sensibilité à ceux problèmes, je vois pas ce qu'on peut faire de plus.
# Euh ...
Posté par GTof . En réponse à la dépêche Sortie de Scala 2.10. Évalué à 4.
Il ne manquerait pas "la version 2.10 de" avant ce bout de phrase? Mis à part ca, très belle dépêche.
# Du bon namespace
Posté par GTof . En réponse au journal Une "App's" n'est pas un logiciel.. Évalué à 10.
Tout dépend de l'espace de nom que tu considères. Pour l'informaticien, tant que c'est du code qui tourne, c'est du pareil au même. En revanche pour le marketeux, alors là rien à voir: un logiciel c'est has been, ringard, lourd, j'oserais dire antique. Alors qu'une App c'est moderne, c'est hype et ca fait saliver le consommateur lambda qui sera prêt à dilapider ses deniers durement gagnés pour la dernière App de pets le faisant briller en société.
[^] # Re: Idéologie et pragmatisme...
Posté par GTof . En réponse à la dépêche Grabuge à la FSF : GnuTLS quitte le projet GNU et sed et grep perdent leur mainteneur. Évalué à 10.
Euh … il faudrait peut être se renseigner quelque peu avant de poster. Linus Torvalds résumait très bien les choses. Linux n'a jamais eu pour but de révolutionner l'architecture des OS. Il à toujours reposé sur des concepts éprouvé (UNIX) avec le pragmatisme comme mot d'ordre. Linus voulait un OS qui marche et c'est ce qui fait à mon avis l'un des points capitaux de Linux.
L'approche d'Hurd est radicalement différente. Le Hurd est une véritable refonte des concepts fondateurs d'un OS. Le concept de transducteur est tout sauf simple, le tout-service l'est tout autant. Je me permet de faire un parallèle entre le couple UNIX/Linux et Plan9/Hurd. Or force est de constater que tout révolutionner (avec ce que cela implique de boulot pour tout refaire) n'intéresse encore que peu de monde (normal, l'existant est pour l'instant bien suffisant).
Bref ne confondons pas tout. La réalité c'est qu'on a besoin des deux et que les opposer est une bêtise. L'approche pragmatique sans idéaux iraient n'importe ou et se perdrait vite, et les idéaux sans pragmatisme n'iraient nulle part.
# Et aussi ...
Posté par GTof . En réponse au journal Un cours en français sur la compilation : ne boudons pas notre plaisir !. Évalué à 2.
Pour approfondir, il y a également son rapport technique The ZINC experiment décrit avec moultes détails les choix d'implémentation de CAML (ca date quand même un peu). Tant qu'a ne pas bouder son plaisir, il y a le sublime The Implementation of Functional Programming Languages par Simon Peyton Jones. Bonne lecture.
[^] # Re: des chiffres plus réalistes
Posté par GTof . En réponse à la dépêche Sortie de Gambas 3.3. Évalué à 2.
Haskell est gambas sont trop différents pour qu'une comparaison soit quelque peu pertinente. Pour la faire courte, Haskell est un langage fonctionnel pure, non strict et lazy. Il n'a pas de couche objet (Go non plus me semble t'il) et est compilé (même s'il est possible d’écrire des scripts). Bref rien à voir avec Gambas.
A part ça, très beau boulot et excellente dépêche!
[^] # Re: alias + locate
Posté par GTof . En réponse au journal fasd. Évalué à 1.
Mais voyons, l'intérêt des autres langages est de servir de faire-valoir aux seuls vrais langages dignes de ce noms que sont Shell, TeX, brainfuck et consorts. Tel le Yin et le Yang, le bien et le mal, les langages de vrais geeks et ceux des kevins.
[^] # Re: Fédérer les codeurs ne fera sans doute pas avancer grand chose
Posté par GTof . En réponse à la dépêche Regrouper les efforts pour les jeux vidéos libres. Évalué à 2.
A vérifier, mais il me semble qu'IndieVania prend pas ou peu de marge. Certes c'est pas du Desura avec auto-patching et compagnie mais personnellement j'aime bien avoir les fichiers d'installation. Histoire d'être sur que je puisse encore jouer à mes jeux même si la plateforme meurt (qui peut dire si le steam-like X ou Y sera éternel?).
[^] # Re: Nan mais franchement..
Posté par GTof . En réponse au journal Naissance du projet nanim. Évalué à 5.
Euh … le terme "branlette" désigne aussi bien masturbation masculine que féminine. Et tout le monde sait que toutes les femmes sont prudes, frigides, avec une avertion profonde pour tout allusion qui touche de près ou de loin le sexe. Et puis c'est quoi cette histoire de thé? Depuis quand les geekettes ne prennent plus de bière?
PS: Te rens tu compte que, bien que prétendant le dénoncer, ton commentaire est on ne peut plus sexiste?
[^] # Re: Limitations sérieuses
Posté par GTof . En réponse au journal Compilateur mini-ML vers TeX et shell. Évalué à 1.
Certes mais LuaTeX c'est tricher. Plus sérieusement, compiler vers du TeX a l'avantage de rester dans un monde homogène et tres stable. De plus, l'objectif a terme est d'intégrer un système de type à la ML, ce dont ne dispose pas Lua. En résumé, le but est de proposer des constructions évolués tout en restant 100% compatible avec l'existant. Et puis la programmation en TeX est certes difficile mais très intéressante et riche d'enseignement.
[^] # Re: Problème de make sous Mac et *BSD
Posté par GTof . En réponse au journal Compilateur mini-ML vers TeX et shell. Évalué à 1.
Merci! C'est corrigé sur le dépôt git et les archives.
[^] # Re: Been there, done that
Posté par GTof . En réponse au journal Compilateur mini-ML vers TeX et shell. Évalué à 1.
J'aimerais beaucoup y jeter un oeil!
[^] # Re: De la doc ? Des exemples ?
Posté par GTof . En réponse au journal Compilateur mini-ML vers TeX et shell. Évalué à 1.
Tout à fait. Y'a quelques exemples et une doc épurée dans les sources, je les mettrais sur le site demain.
[^] # Re: De la doc ? Des exemples ?
Posté par GTof . En réponse au journal Compilateur mini-ML vers TeX et shell. Évalué à 3.
Et pour le shell, super lent!
[^] # Re: Stats
Posté par GTof . En réponse au journal Humble Indie Bundle 4 !. Évalué à -1.
Ne confondons pas tout, les différents projets libres et les jeux indie proprio ont des différences importantes et ca à a des conséquences sur leur mode de rémunération/dons. Les jeux indie proprios sont conçus dans l'optique de produire sous 3 ans maximum un produit fini de qualité suffisante pour remporter un certain succès.
Alors que les jeux libres, dont bon nombre sont de très grande qualité bien supérieure à la majorité des jeux indie, n'ont pas cette logique de production d'un produit fini a court ou moyen terme. Mais une logique de projet ouvert sur la durée (Ca fait des années que Battle For Wesnoth ou XMoto et tant d'autres sont déjà impressionnant de qualités).
Acheter un jeux indie classique c'est acheter un produit fini, donner a un projet libre c'est participer a un projet. Si on regarde les campagnes se dons de Wikipedia, on voit bien que quand un projet fait suffisemment parler de lui et demande des fond pour continuer à une base suffisante d'utilisateur, ca marche.
Seulement voila, les jeux libres, malgrè leur très grande qualité ne sont pas du tout dans la logique de l'évènement, créant une attente, faisant parler d'eux massivement sur une courte durée (les jeux indie ne font pas le buzz pendant des années). Sauf peut être Wildfire Games qui le fait un peu.
[^] # Re: Support des proxy HTTP ?
Posté par GTof . En réponse à la dépêche sslh 1.10, la bête noire des censeurs. Évalué à 2.
Même si tu n'es pas censé lire tes mails privés ou gérer tes comptes au boulot, il y a des boites où tu dois avancer les frais pour certaines missions que ta boites rembourse ensuite. Tu peut donc être amené dans le cadre de ton boulot a utiliser des données privées (banquaire, mail, ...) avec le proxy espion de la boite. La boite n'est pas forcément mal attentionné, mais des données privées qui fuites, ca arrive. Et la, la responsabilité de la boite peut sans doute être engagée.
[^] # Re: accélérer quand on est doublé
Posté par GTof . En réponse au journal De la bonne conduite sur autoroute. Évalué à 3.
Tu voudrais une ambiance plus gaie ?
[^] # Re: Ne pas acheter
Posté par GTof . En réponse au journal Un autre bundle sous Linux, IndieRoyale.. Évalué à 5.
Il faut noter que les HIB font réellement un efforts pour le support Linux. Contrairement à ce que je pensais naïvement, ce n'est pas toujours les développeurs d'un jeu qui le portent sous GNU/Linux mais dans le cas des HIB il semble que ce soit bien souvent Ryan_C._Gordon (béni soit il!). J'ai pas les stats mais de mémoire, pas mal de jeux ont débuté sous linux avec les HIB. Certains jeux (lugaru,...) sont même passé open source avec le HIB.
Les Indie Royale sont juste des bundle comme il en existe tant sur toutes les plateforme de distribution. Le précédent n'avait (encore de mémoire) aucun jeu sous Linux mais il se trouve que celui ci contient des jeux Charlie's Games qui sont semble il systématiquement sous Linux (en tout cas j'ai jamais eu de problème avec).
Pour ce qui est des ports Linux dans les HIB, les seuls problèmes que j'ai eu venaient, semble t-il des incompatibilités entre ma version de X.org et les bibliothèques fournies avec certains jeux (les libSDL_*.so, etc ...). Dans tous les cas, utiliser les libs de ma distribution a la place de celles fournies à réglé le problème (la dépôt multilib sous Arch fait des miracles!).
[^] # Re: Le souci du détail...
Posté par GTof . En réponse au journal La différence entre le bling-bling et le design de Qualitay. Évalué à 1.
[^] # Re: Respect...
Posté par GTof . En réponse à la dépêche Dennis Ritchie, un père d’UNIX, nous a quittés. Évalué à 8.
L'humilité est toute à son honneur mais Unix n'est pas qu'un système qui, par chance, a bien marché mais avant tout le fruit d'une philosophie (une collection d'outils combinables qui ne font qu'une seule tâche mais la font bien, le "tout fichier", ....) qui reste encore aujourd'hui très pertinente et devraient être plus suivie. Tout le monde ne peut pas en dire autant, alors certes il n'était pas seul, et était au bon endroit au bon moment, mais lui il a vraiment révolutionné l'informatique. Et ca c'est quand même pas rien.
PS: quel dommage que Plan9 n'est pas eu le même succès qu'Unix :(
# Encore un langage de "haut"-niveau interprété par le navigateur?!
Posté par GTof . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 10.
Remplacer JavaScript, pourquoi pas. Même si Fabrice Bellard arrive a en faire des merveilles, JS est quand même pas l'option la plus adaptée pour les performances. Mais pourquoi diable un nouveau langage "haut"-niveau? Surtout que rien ne force à développer en JS pour tourner sur le navigateur, les langages qui se compilent en JS sont légion. J'aurais plutôt vu une approche à la Mono/.NET avec un langage très bas niveau qui s'exécute rapidement sur le navigateur et une flopée de langages intercompatibles qui se compilent dedans. Car non l'analyse lexicale et syntaxique n'a pas à être fait à la volé par le navigateur par le navigateur et encore moins la vérification de types!
Pourquoi pas le support du bytecode LLVM dans les navigateur? Ce serait possible?
[^] # Re: les avertisseurs de radars sont des logiciels très particuliers
Posté par GTof . En réponse à la dépêche De l'interdiction de publier certains logiciels. Évalué à -1.
Il faut aussi prendre en compte l'évolution du nombre de contraventions. Plus les gens respecteront les limitations, moins ce sera rentable.
Enfin pour ce qui concerne le sujet de de l'article, quelques chiffres justifient d'éviter de pouvoir localiser les radars. Rendre illégales les applis de localisation ne sera certes pas efficace à 100% mais au moins ca en ralentira pas mal.
Et contrairement au contournement des DRM, qui peut servir à plein de bonnes choses dont l'interopérabilité. J'ai du mal à voir les usages légitimes de la localisation des radars.
[^] # Re: Torvalds vs Stallman
Posté par GTof . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à -2.
Justement, je ne critique pas Linus sur la technique mais justement sur son manque d'ouverture pour le reste. C'est le célèbre débat Torvalds/Stallman, open/free software. Si on pend comme principe de base que ces seules préoccupations sont la qualité du code et la propagation de Linux, sa position est totalement fondée. C'est pour cela que je disais qu'il est intélligent. Mais y a pas que la technique dans la vie, et son refus de le voir est justement ce que je trouve "con" chez lui.