Ben t'as qu'à coder une alternative qui réponde à leur besoin de faire des trucs qui clignottes dans tous les sens et qui stream de la video en même temps, le tout en multi plateformes (sans oublier l'embarqué), bien sûr un truc performant, et t'oublies pas le principal : des outils pour créer le contenu, des bouquins pour expliquer le bouzin, tu oublies pas les serveurs de streaming, t'intègre tout ca bien comme il faut, tu met le tout sous une licence libre, tu proposes des services associés (formation, support, hébergement) et après tu reviens pour râler parcque les gens utilisent une techno proprio.
Ce dont 99% du code ecris se moque royalement.
Y'a pas que pour le programmeur qu'il y a un intérêt, mais aussi pour l'utilisateur : la couche d'abstraction vis à vis de matos est le meilleur moyen d'avoir une compatibilité binaire. On le voit facilement par exemple avec le passage au 64bits : le matos et l'OS est obligé de se coltiner un mode "legacy" 32 bits juste pour faire marcher de vieilles applis. Les appli .NET/Java tournent out of the box sur une machine 64 bits.
De toute facon c'est au systeme d'exploitation de fournir le confinement/sandboxing; le faire dans le langage c'est un palliatif, pas une solution.
Et ben c'est pareil que pour le problème de matos : les instructions machines du proc sont limitées et le code associé y est fortement lié : le modèle de sécu de .NET par exemple est bien plus avancé en terme de gestion de droits que ce que propose l'OS. Les 2 sont complémentaires, l'OS gère tout ce qui concerne les droits au niveau processus, le framework .NET travaille plutôt au niveau des assemblies.
Et puis y'a des choses que l'OS ne peut pas faire : un débordement de tampon qui se fini par une appli avec du code injecté, ben l'OS aura beau limiter ses droits, si l'appli avait ne serais-ce que les droits utilisateurs, paf, accès à des données sensibles, toussa. Et ca l'OS ne peut pas le faire car un débordement de tampon, ce n'est que finalement une fonctionnalité offerte par le langage C qui t'autorise à taper n'importe où dans l'espace mémoire du processus.
De plus la granularité est beaucoup plus fine : je peux faire du sandboxing interne : pleins d'applis sont développées avec un mécanisme de plugin, tu trouverais ca normal qu'un plugin "tiers" fasse planter une appli critique ? Non, ben tu l'isoles, dans le doute, c'est pas ton code, il peut être une sour ce de bug supplémentaire, je sandbox, et l'OS ne peut rien y faire.
il te suffit de coller un tag dans toutes tes structures; tu peux meme faire ca en C si tu veux.
Sauf que là c'est proposé out of the box, ca marche avec tous les types, c'est un modèle complètement objet this.GetType().GetBaseClass().FindMethod("trucmuch"), tu vas t'arracher en C.
Aller petit exercice : je te files une classe C++, et tu me génères dynamiquement un proxy sur une instance de cet objet, et bien sûr tu rajoutes au milieu une connection TCP.
Donc la machine virtuelle ne sert toujours a rien
T'as pas bien compris ce qu'est une machine virtuelle. La machine est "virtuelle". Dans le cas de .NET/Java, une partie de la vue virtuelle c'est la représentation de ces données, et en l'occurence des objets.
Poussons le raisonnement que tu proposes, à savoir :
1 - je rajoutes systématiquement une info de type à la structure pour pouvoir l'identifier.
2 - je veux maintenant que ca soit fait automatiquement sur mes objets, je fais donc en sorte que ca soit fait par le compilo et qu'un support à l'exécution soit présent : c'est le runtime RTTI que propose C++. Déjà, le langage C++ propose dans ce contexte un semblant de vue qui n'est pas uniquement des "bits" en mémoire comme en C, on a un début de machine virtuelle.
3 - je veux des infos sur tous les membres objet par introspection
4 - allez je veux même le code de tous les membres objet par introspection
5 - j'ajoutes donc un tas d'infos sur le code lui même : au final j'ai construit une couche d'abstration complète de mon code, j'ai créé un nouveau modèle de machine virtuelle.
Tiens d'ailleur au passage je me dis que le code natif ne sert plus à rien dans l'histoire, on peut le regénérer à partir du code virtuel puisqu'il contient toutes les infos. hop je le vire, il sera traduit en code natif au dernier moment : JIT.
Ah oui, et le C dans l'histoire, ne fera que rendre ta solution bancale, non standard : rien n'empêche un couillon (ou bêtement un bug si fréquent) d'aller écraser l'info de type dans ta structure. Pouf, tout ton code après s'écroule comme un con. D'où l'intérêt d'avoir un modèle beaucoup plus contrôlé.
Bon ca je sais pas ce que c'est. Enfin le nom me dit rien. Si c'est un truc
Des trucs du genre : j'instancie à distance un objet dans un autre processus sur une autre machine par exemple, et je la manipule comme si elle était en local (bref cas typique d'une application répartie avec des composants objets).
L'avantage de la machine virtuelle, c'est pour les applications embarquees,
quand le temps de compilation doit etre vraiment minimise, parce que c'est facile a traduire en code natif; sur un serveur/desktop/PC moderne ca ne sert a rien.
Alors pourquoi D ne propose pas les mêmes fonctionnalités en terme de sécu, d'introspection et tout le tralala ?
Pourquoi personne n'a encore fait de super langage sans machine virtuelle et qui concurrence Java & Co ?
Pourquoi on doit encore se taper ce con de C dans l'embarqué (malgré ce que tu dis, car souvent dans l'embarqué, les perfs sont primordiales)
Si on regarde un language comme Common Lisp, qui compile en code natif
Gni ? Et ? .NET compile en natif. Java compile en natif. Tu crois que Common Lisp ne propose pas par hasard un modèle de représentation des données virtuelles qui lui est propre ? Tu crois qu'il n'y a aucun service dynamique à l'exécution pour pallier les impossibilités d'introspection du langage natif ? Tu crois que common lisp te permet de faire de memcpy et autre bidouille en partant du principe que tu attaques physiquement une zone mémoire ou bien Common Lisp te propose une abstraction totale de la machine physique ? Tu crois que tout ca c'est pas caché dans ce qu'on appel généralement une machine virtuelle ?
Ca veut rien dire du tout. Le vrai programmeur moderne, il sait pertinamment que ce genre d'optimisation est laissé à la discretion du compilateur; à part rendre le code illisible, le décalage de bit pour effectuer une division par une puissance de 2 n'a plus grand intérêt de nos jours.
Le programmeur ferait mieux de penser à optimiser son algo plutôt que de faire son malin avec des décalages de bits.
Non aux technologies propriétaires, même dans leur implémentation libre, dans une distribution linux.
C'est vrai. Alors faisons vraiment le ménage, et virons Linux, cette implémentation libre d'Unix.
J'ai rien compris (et je crois que t'es pas loin derrière moi ;). Qu'est-ce qui n'est pas possible avec les templates en C++ ?
Ben je partais du principe que qu'un type template avait une signature "générique", et donc que les infos RTTI à l'exécution auraient autoriser un dynamic_cast. En fait non c'est l'inverse, y'a bien une signature de type différente pour 2 instanciations d'un même template avec 2 types différents, et le dynamic_cast foire.
En fait j'ai rien dis, je viens de vérifier, tu peux faire la vérification avec dynamic_cast, ce qui est assez logique en fin de compte, le compilateur ayant figé une fois pour toute le type "instancier" à la compilation par le template. dynamic_cast fait alors la vérif standard pour savoir si le type paramétré peut être transtypé.
Donc effectivement, les templates ne sont pas un problème particulier pour la sécu, c'est bien le cast qui est effectivement dangereux.
Oui mais ce que tu as évoqué est applicable aussi bien pour les templates que pour les non templates.
Comme précisé plus bas, il y a une vérification de type possible avec les trucmachin_cast. (le runtime RTII de C++ s'occupe de ca). Ben avec les templates c'est pas possible. le design des templates empêche donc bien toute vérification à l'exécution.
. Donc ça n'a rien avoir. Je pense que tu n'as pas compris ce qu'est un template.
Si ca a à voir. Parcque tel qu'est implémenté les types génériques par exemple en C# (désolé, je parle de ce que je connais), tu pourras pas faire ce genre de connerie : le runtime a connaissance du type générique et des types en paramètres.
Voilà le rapport. Les templates C++, une fois l'étape de compilation passée, plus aucun contrôle possible.
Bien sûr. Mais du point de vue du programmeur (la vision machine virtuelle qui lui est proposée), ce n'est pas le cas :)
Et bon, globalement, il peut rarement inliner, si l'objet cible est défini dans un .class séparé et que celui-ci est amené à évoluer, c'est la merde quand même... Cela dis ca n'empêche pas un inlining au moment de la compilation JIT.
. Maintenant appeler ça du sucre syntaxique je trouve que tu pousses le bouchon un peu trop loin
Parcque tu prends ca au sens négatif :) Ca a certains avantages, c'est très puissant (turing compliant toussa), mais concrêtement ca reste du sucre syntaxique : dans le code exécutable produit, ca n'a aucun d'impact.
La preuve la plus flagrante, c'est que ca s'exporte pas. Tu peux pas faire une lib binaire qui "exporte" une classe template. Tout se passe comme tu le précise à la compilation.
mais de là à mélanger buffer overflow et templates...
Je prenais juste un exemple plus parlant et très répandu de faille de sécu.
Tu peux très bien imaginer un template qui prend un type en paramètre. A l'exécution, tu passe autre chose avec un bon gros cast bourrin. Hop le code généré par le template travaille avec une donnée non prévu dans le code source. On peut imaginer tout et n'importe quoi comme problème : débordement de tampon, accès à une adresse illégale, etc. Et certaines erreurs de ce type sont réputés pour conduire potentiellement à des failles de sécu.
Quel est le rapport entre les templates et la sécurité?
Effectivement, y'a pas de rapport. Je voulais parler de fiabilité.
En fait je me corrige, ca a quand même un rapport avec la secu : comme beaucoup de problèmes de fiabilité dans un programme écrit en C/C++, cela engendre un problème de sécurité potentielle dont il est difficile d'évaluer les conséquences. Exemple typique de problème de sécu lié à un problème de fiabilité du code écrit : un débordement de tampon.
Les plateformes modernes de type Java/.NET propose des barrières pour éviter qu'un problème de fiabilité (nullpointerexception, indexoutofrange) ne devienne un problème de sécu.
Evidemment, quand je dis problème de sécu, c'est qui pourrait compromettre une autre partie du système que ce que le programme est autorisé à faire lui même. Ca n'enlève pas les problèmes de sécu interne au programme :) (bien que Java/.NET propose d'autres mécanisme pour se prémunir contre ce genre de chose, genre les chaînes de caractères immutables, pas de débordement de tampon, etc.) sans qu'il y est bien sûr une quelconque garantie.
L'introspection et les services de remoting en Java se font sans support spécial du language
Ah bon ?
Et la syntaxe pour écrire des méta-données intégrée au langage Java ca sert à quoi ?
A quoi sert les mots clés instanceof ou typeof ?
Si le langage autorisait comme l'autorise le C/C++ l'exécution de code binaire (asm) comment tu ferais de l'introspection sur le code ?
Si le langage autorisait des optimisations du style 'inlining" pour des méthodes, comment tu la retrouverais par introspection ? (genre le compilo s'amuse à inliner les méthodes get* et set*, ca serait rigolo pour les bean...)
A quoi ressemblerait un template àla C/C++ dans l'exécutable par introspection ?
On est d'accord, le service d'introspection n'est pas fourni par le langage, mais ill faut que le langage se plie à un certain nombre de contraintes et propose quelques fonctionnalités (genre méta-données).
Si.
Non. Y'a les types génériques, mais pour moi ca n'a pas grand chose à voir d'un point de vue technique, même s'il y a des points communs au niveau utilisation/syntaxe.
C'est pas pour rien que ca s'appelle pas template dans le monde Java/.NET.
Quel est le rapport entre les templates et la sécurité?
Effectivement, y'a pas de rapport. Je voulais parler de fiabilité.
Pourquoi donc beagle se met il a indexe les fichiers ainsi ?! il ne marche pas avec inotify ?!
Il marche avec inotify quand ce dernier est installé et beagle configuré pour, autrement il s'en passe. Sinon beagle est censé "bosser" lors des périodes d'inactivités de la machine, je soupçonne leur algorithme de détection d'inactivité d'être foireux dans ce contexte :)
- c'est effarant le nombre de programme qui terminent avec une stack-trace dy type 'Null Pointer Exception' et consorts
Ben la sécurité justement, c'est que le framework Java ne va pas planter lamentablement et compromettre le système :) De plus cette exception est un cas "normal" qui peut être traiter sans problème. Bref c'est pas un segfault ;)
Tu confonds fiabilité et sécurité.
Les templates, ça n'existe que depuis très peu de temps.
Les templates en Java n'existe pas. Les templates en C/C++ sont une vraie daube au niveau sécurité comparé à la généricité de .NET : les templates n'ont aucune "vie" à l'exécution, c'est du sucre syntaxique proposé par le compilateur. Et ca ne t'empêche pas de faire n'importe quoi.
tc donc le niveau de programmation est similaire a celui de Java/C# mais avec des perf voisine de C/C++.
Java/C# te garantisse une certaine sécurité. C/C++/D non. Même si D te propose d'avoir une meilleure sécurité, il n'y a aucune garantie, tu peux toujours manipuler des pointeurs qui font n'importe quoi, et rien ne t'empêche de le faire. Y'a une énorme différence entre : "t'es pas obligé" et "tu peux pas". Genre en tant qu'utilisateur, je peux obtenir un certain nombre de garantie de la part d'un exécutable .NET, alors qu'un exécutable écrit en D, si le concepteur a voulu faire un truc malveillant...
Je ne parle même pas du framework de sécurité sous-jacent présent dans .NET par exemple, qui permet d'attribuer des droits différents à chaque composant de la plateforme pour toutes les applis.
en Java/C#, le démarrage des VM a un coup de démarrage assez élevé et au départ les performance sont assez faibles (le temps que le JIT génère le code
Faux problème : .NET a été conçu dès la base pour être utilisé en mode AOT (Ahead of Time) : la compilation JIT est faite une fois pour toute, l'exécutable natif est conservé en cache jusqu'à mise à jour.
franchement c'est un avantage très théorique: pour C#, il ne doit pas y avoir beaucoup de programme non-lié aux librairies spécifique a Windows,
Windows ca tourne sur x86 mais aussi x64 et pleins de plateformes embarquées où est présent le framework .NET sous différentes formes.
De plus dans des scénario de remoting (Java RMI, .NET remoting), une compatibilité binaire reste indispensable.
Ce n'est pas un oubli, c'est juste des fonctionnalités qui ne sont pas du ressort du language, mais du compilateur et des API.
Ces fonctionnalités sont fortement dépendantes du type de machine cible. Pour celà les plateformes de type .NET/Java propose une "vue" différente de la machine physique : une machine virtuelle, et c'est elle qui propose la plupart de ces services. Le langage par ses possibilités offertes suppose/exploite les fonctionnalités proposées par la machine cible. Le compilateur étant là pour faire la traduction dans le langage de la machine cible (réelle ou virtuelle).
Bref, c'est tout un éco-système, du langage à la machine cible en passant par le compilateur qui offre ces fonctionnalités. Et c'est pourquoi les plateformes comme .NET/Java ont une machine virtuelle, pour proposer tous ces services. Et c'est pour la même raison que D ne peut avoir ces services, parcqu'ils ont fait le choix de ne pas avoir de machine virtuelle.
Rien n'empêche la création d'une version de D qui s'exécute dans une machine virtuelle avec les services que tu décris.
Avoir D qui tourne sur une machine virtuelle, pourquoi pas, mais sans modification/support du langage, la plupart des services seront inaccessibles.
Certes, mais doit-on réellement emmerder toute la communauté des utilisateurs de logiciels libres simplement pour faciliter l'introduction de logiciels propriétaires dans les distributions majoritaires ?
Certes, c'est demandé par les distributeurs de logiciels propriétaires, mais ca serait aussi un grand confort pour tous les utilisateurs de logiciels libres : l'utlisateur lambda de mandrake, ubuntu ou fedora il a une distribution à base de binaire, et qu'ils soient proprio ou pas, le problème est le même.
Et puis bon franchement, voir autant de distributions qui font toutes le même boulot de packaging en parrallèle, je trouve ca une perte de temps considérable.
"vec un confort de développement pour le programmeur voisin de celui fourni par Ruby ou Python"
J'avoue que j'ai du mal à comprendre le rapport avec ces 2 langages au niveau confort de programmation...
Pour ceux qui viennent du C#/Java, la liste est plus courte, mais un gros avantage: pas de machine virtuelle ou d'interpréteur.
Non, ca c'est le gros désavantage : on perd la couche d'abstraction avec le matos, on perd tous les services de sécurité, les services d'introspection, la portabilité binaire, les services de remoting, et j'en oublie sûrement (au passage ils "oublient" toutes ces fonctionnalités dans leur tableau de comparaison, ils font juste mention du typeof).
Le gros avantage par rapport à C# ou Java, c'est surtout les perfs. C'est en partie lié à l'absence de machine virtuelle, certes, mais surtout au côté "programmation bas-niveau" (tout est relatif, mais bon : pointeurs, pas de vérif, toussa).
Bref, D est plus un remplacant du C/C++ qu'une alternative à C#/Java : pas les mêmes objectifs et donc pas forcement les mêmes utilisations apropriées.
Bon j'espère maintenant que D va être normalisé, ca serait vraiment cool d'avoir un vrai remplacant à ce batard de C++.
Si je fais dépendre le daemon trackerd à une bibliothèque GNOME, je vais me faire incendier par tous ceux qui ne veulent pas du bureau du même nom...
Rassure moi, y'a quand même un système de plugins, qui permette d'ajouter des modules sans se préocuper de ce genre de problème de dépendance non ? Si je veux ajouter un filtre dépendant de Qt ou GTK je peux j'espère ?
le daemon local gère toutes les données d'evolution... sauf les mails. Sans doute les types d'evolution ont estimés que ces données (les mails) n'avaient pas besoin d'être partagées. Ca reste discutable mais c'est comme ca :)
J'ai dit que ce système ne me semble pas augmenter la qualité des commentaires de façon générale et a des effets de bords, entre autre de muselé les opinions minoritaires.
Je fais parti de ces gens avec très souvent une opinion minoritaire. Pourtant je peux encore poster tranquillement sans aucun problème : il suffit d'argumenter et d'ettayer ses propos. Non, les opinions minoritaires ne sont pas muselées. Pareil pour pBpG, il peut toujours poster.
Tu parts du postulat que c'est le système de modération qui a résolu ce problème et qu'il n'a pas d'effet de bord.
C'est quoi l'effet de bord ? Certaines personnes ne peuvent plus poster ? c'est l'objectif. Les gens s'auto-censure dans un espèce de brouhaha consensuel ? Perso je suis loin d'être consensuel et j'ai de nombreux XP.
Avant de proposer quelque chose, il faut déjà s'entendre que l'avantage ou l'inconvénient d'avoir la mini-censure. Si une grosse majorité trouve la mini-censure super, sans défaut, sans effet de bord, il est inutile de proposer quoi que ce soit.
Comment t'évites les questions toi c'est pas possible :) T'es pas d'accord sur le système actuel, propose une alternative qui va tenter de répondre aux mêmes objectifs : limiter la pollution des posts. Tout le monde s'accorde à dire que le système actuel est loin d'être parfait, mais pour l'instant, c'est "faute de mieux".
Et supprimer le système actuel ne va pas arranger les choses.
Ainsi on n'aura les commentaires filtrés sur :
- le score (le système actuel)
- une liste de compte dont les commentaires doivent être masqué. Liste associée par compte.
C'est le système de PCInpact, et ben franchement, les commentaires sont globalement d'un nullissime incroyable. Et leur base doit être polluée au possible. Cela dis, eux sont une entreprise commerciale, ils peuvent se permettre d'avoir des milliers de conneries en base.
Et pour les lecteurs occasionnel comme moi qui n'ont pas de compte, j'ai pas que ca à foutre que de m'amuser à "trier" les cons : je lis plus les commentaires.
Par exemple, pour ton compte, ta liste de compte dont les commentaires sont à masquer pourrait être :
- PasBill PasGate : tu dis la chose même que lui :-)
- IsNotGood : anti-MS primaire
C'est idiot, les gens peuvent évoluer. Si tu caches ses commentaires, tu ne les voies plus. Moi je lis les posts sans à priori sur leur auteur.
Certe firefox fait un joli score mais combien utilise firefox sous Windows ?
A mon avis y'a un bon paquet de moules au boulot qui ne peuvent choisir que leur navigateur web ;)
J'ai des doutes sur l'application de la loi concernant le simple fait de regarder chez soi un DVD du commerce.
La loi est pourtant clair : CSS est un système de protection de contenu, DeCSS le fait sauter, il n'est donc pas légal de l'utiliser, à moins que ce ne soit à des fins de recherche en sécurité ou crypto. Et je penses pas que matter un DVD rentre dans ce dernier cadre ;)
[^] # Re: C'est pas la première fois
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft, le controle absolu de votre PC ?. Évalué à -1.
[^] # Re: et le mien
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 1.
Y'a pas que pour le programmeur qu'il y a un intérêt, mais aussi pour l'utilisateur : la couche d'abstraction vis à vis de matos est le meilleur moyen d'avoir une compatibilité binaire. On le voit facilement par exemple avec le passage au 64bits : le matos et l'OS est obligé de se coltiner un mode "legacy" 32 bits juste pour faire marcher de vieilles applis. Les appli .NET/Java tournent out of the box sur une machine 64 bits.
De toute facon c'est au systeme d'exploitation de fournir le confinement/sandboxing; le faire dans le langage c'est un palliatif, pas une solution.
Et ben c'est pareil que pour le problème de matos : les instructions machines du proc sont limitées et le code associé y est fortement lié : le modèle de sécu de .NET par exemple est bien plus avancé en terme de gestion de droits que ce que propose l'OS. Les 2 sont complémentaires, l'OS gère tout ce qui concerne les droits au niveau processus, le framework .NET travaille plutôt au niveau des assemblies.
Et puis y'a des choses que l'OS ne peut pas faire : un débordement de tampon qui se fini par une appli avec du code injecté, ben l'OS aura beau limiter ses droits, si l'appli avait ne serais-ce que les droits utilisateurs, paf, accès à des données sensibles, toussa. Et ca l'OS ne peut pas le faire car un débordement de tampon, ce n'est que finalement une fonctionnalité offerte par le langage C qui t'autorise à taper n'importe où dans l'espace mémoire du processus.
De plus la granularité est beaucoup plus fine : je peux faire du sandboxing interne : pleins d'applis sont développées avec un mécanisme de plugin, tu trouverais ca normal qu'un plugin "tiers" fasse planter une appli critique ? Non, ben tu l'isoles, dans le doute, c'est pas ton code, il peut être une sour ce de bug supplémentaire, je sandbox, et l'OS ne peut rien y faire.
il te suffit de coller un tag dans toutes tes structures; tu peux meme faire ca en C si tu veux.
Sauf que là c'est proposé out of the box, ca marche avec tous les types, c'est un modèle complètement objet this.GetType().GetBaseClass().FindMethod("trucmuch"), tu vas t'arracher en C.
Aller petit exercice : je te files une classe C++, et tu me génères dynamiquement un proxy sur une instance de cet objet, et bien sûr tu rajoutes au milieu une connection TCP.
Donc la machine virtuelle ne sert toujours a rien
T'as pas bien compris ce qu'est une machine virtuelle. La machine est "virtuelle". Dans le cas de .NET/Java, une partie de la vue virtuelle c'est la représentation de ces données, et en l'occurence des objets.
Poussons le raisonnement que tu proposes, à savoir :
1 - je rajoutes systématiquement une info de type à la structure pour pouvoir l'identifier.
2 - je veux maintenant que ca soit fait automatiquement sur mes objets, je fais donc en sorte que ca soit fait par le compilo et qu'un support à l'exécution soit présent : c'est le runtime RTTI que propose C++. Déjà, le langage C++ propose dans ce contexte un semblant de vue qui n'est pas uniquement des "bits" en mémoire comme en C, on a un début de machine virtuelle.
3 - je veux des infos sur tous les membres objet par introspection
4 - allez je veux même le code de tous les membres objet par introspection
5 - j'ajoutes donc un tas d'infos sur le code lui même : au final j'ai construit une couche d'abstration complète de mon code, j'ai créé un nouveau modèle de machine virtuelle.
Tiens d'ailleur au passage je me dis que le code natif ne sert plus à rien dans l'histoire, on peut le regénérer à partir du code virtuel puisqu'il contient toutes les infos. hop je le vire, il sera traduit en code natif au dernier moment : JIT.
Ah oui, et le C dans l'histoire, ne fera que rendre ta solution bancale, non standard : rien n'empêche un couillon (ou bêtement un bug si fréquent) d'aller écraser l'info de type dans ta structure. Pouf, tout ton code après s'écroule comme un con. D'où l'intérêt d'avoir un modèle beaucoup plus contrôlé.
Bon ca je sais pas ce que c'est. Enfin le nom me dit rien. Si c'est un truc
Des trucs du genre : j'instancie à distance un objet dans un autre processus sur une autre machine par exemple, et je la manipule comme si elle était en local (bref cas typique d'une application répartie avec des composants objets).
L'avantage de la machine virtuelle, c'est pour les applications embarquees,
quand le temps de compilation doit etre vraiment minimise, parce que c'est facile a traduire en code natif; sur un serveur/desktop/PC moderne ca ne sert a rien.
Alors pourquoi D ne propose pas les mêmes fonctionnalités en terme de sécu, d'introspection et tout le tralala ?
Pourquoi personne n'a encore fait de super langage sans machine virtuelle et qui concurrence Java & Co ?
Pourquoi on doit encore se taper ce con de C dans l'embarqué (malgré ce que tu dis, car souvent dans l'embarqué, les perfs sont primordiales)
Si on regarde un language comme Common Lisp, qui compile en code natif
Gni ? Et ? .NET compile en natif. Java compile en natif. Tu crois que Common Lisp ne propose pas par hasard un modèle de représentation des données virtuelles qui lui est propre ? Tu crois qu'il n'y a aucun service dynamique à l'exécution pour pallier les impossibilités d'introspection du langage natif ? Tu crois que common lisp te permet de faire de memcpy et autre bidouille en partant du principe que tu attaques physiquement une zone mémoire ou bien Common Lisp te propose une abstraction totale de la machine physique ? Tu crois que tout ca c'est pas caché dans ce qu'on appel généralement une machine virtuelle ?
[^] # Re: Java oui, c'est lent
Posté par TImaniac (site web personnel) . En réponse au message Lenteur de Java ?. Évalué à 6.
Le programmeur ferait mieux de penser à optimiser son algo plutôt que de faire son malin avec des décalages de bits.
[^] # Re: Fin de semaine
Posté par TImaniac (site web personnel) . En réponse au journal Tomboy 0.5 est sorti !. Évalué à 9.
C'est vrai. Alors faisons vraiment le ménage, et virons Linux, cette implémentation libre d'Unix.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 2.
Ben je partais du principe que qu'un type template avait une signature "générique", et donc que les infos RTTI à l'exécution auraient autoriser un dynamic_cast. En fait non c'est l'inverse, y'a bien une signature de type différente pour 2 instanciations d'un même template avec 2 types différents, et le dynamic_cast foire.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 2.
Donc effectivement, les templates ne sont pas un problème particulier pour la sécu, c'est bien le cast qui est effectivement dangereux.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 2.
Comme précisé plus bas, il y a une vérification de type possible avec les trucmachin_cast. (le runtime RTII de C++ s'occupe de ca). Ben avec les templates c'est pas possible. le design des templates empêche donc bien toute vérification à l'exécution.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 2.
Si ca a à voir. Parcque tel qu'est implémenté les types génériques par exemple en C# (désolé, je parle de ce que je connais), tu pourras pas faire ce genre de connerie : le runtime a connaissance du type générique et des types en paramètres.
Voilà le rapport. Les templates C++, une fois l'étape de compilation passée, plus aucun contrôle possible.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 2.
Et bon, globalement, il peut rarement inliner, si l'objet cible est défini dans un .class séparé et que celui-ci est amené à évoluer, c'est la merde quand même... Cela dis ca n'empêche pas un inlining au moment de la compilation JIT.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 2.
Parcque tu prends ca au sens négatif :) Ca a certains avantages, c'est très puissant (turing compliant toussa), mais concrêtement ca reste du sucre syntaxique : dans le code exécutable produit, ca n'a aucun d'impact.
La preuve la plus flagrante, c'est que ca s'exporte pas. Tu peux pas faire une lib binaire qui "exporte" une classe template. Tout se passe comme tu le précise à la compilation.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 1.
Je prenais juste un exemple plus parlant et très répandu de faille de sécu.
Tu peux très bien imaginer un template qui prend un type en paramètre. A l'exécution, tu passe autre chose avec un bon gros cast bourrin. Hop le code généré par le template travaille avec une donnée non prévu dans le code source. On peut imaginer tout et n'importe quoi comme problème : débordement de tampon, accès à une adresse illégale, etc. Et certaines erreurs de ce type sont réputés pour conduire potentiellement à des failles de sécu.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 0.
Effectivement, y'a pas de rapport. Je voulais parler de fiabilité.
En fait je me corrige, ca a quand même un rapport avec la secu : comme beaucoup de problèmes de fiabilité dans un programme écrit en C/C++, cela engendre un problème de sécurité potentielle dont il est difficile d'évaluer les conséquences. Exemple typique de problème de sécu lié à un problème de fiabilité du code écrit : un débordement de tampon.
Les plateformes modernes de type Java/.NET propose des barrières pour éviter qu'un problème de fiabilité (nullpointerexception, indexoutofrange) ne devienne un problème de sécu.
Evidemment, quand je dis problème de sécu, c'est qui pourrait compromettre une autre partie du système que ce que le programme est autorisé à faire lui même. Ca n'enlève pas les problèmes de sécu interne au programme :) (bien que Java/.NET propose d'autres mécanisme pour se prémunir contre ce genre de chose, genre les chaînes de caractères immutables, pas de débordement de tampon, etc.) sans qu'il y est bien sûr une quelconque garantie.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 2.
Ah bon ?
Et la syntaxe pour écrire des méta-données intégrée au langage Java ca sert à quoi ?
A quoi sert les mots clés instanceof ou typeof ?
Si le langage autorisait comme l'autorise le C/C++ l'exécution de code binaire (asm) comment tu ferais de l'introspection sur le code ?
Si le langage autorisait des optimisations du style 'inlining" pour des méthodes, comment tu la retrouverais par introspection ? (genre le compilo s'amuse à inliner les méthodes get* et set*, ca serait rigolo pour les bean...)
A quoi ressemblerait un template àla C/C++ dans l'exécutable par introspection ?
On est d'accord, le service d'introspection n'est pas fourni par le langage, mais ill faut que le langage se plie à un certain nombre de contraintes et propose quelques fonctionnalités (genre méta-données).
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 2.
Non. Y'a les types génériques, mais pour moi ca n'a pas grand chose à voir d'un point de vue technique, même s'il y a des points communs au niveau utilisation/syntaxe.
C'est pas pour rien que ca s'appelle pas template dans le monde Java/.NET.
Quel est le rapport entre les templates et la sécurité?
Effectivement, y'a pas de rapport. Je voulais parler de fiabilité.
[^] # Re: enfin !
Posté par TImaniac (site web personnel) . En réponse au journal meta-tracker, le tueur de beagle .... Évalué à 2.
Il marche avec inotify quand ce dernier est installé et beagle configuré pour, autrement il s'en passe. Sinon beagle est censé "bosser" lors des périodes d'inactivités de la machine, je soupçonne leur algorithme de détection d'inactivité d'être foireux dans ce contexte :)
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 1.
Ben la sécurité justement, c'est que le framework Java ne va pas planter lamentablement et compromettre le système :) De plus cette exception est un cas "normal" qui peut être traiter sans problème. Bref c'est pas un segfault ;)
Tu confonds fiabilité et sécurité.
Les templates, ça n'existe que depuis très peu de temps.
Les templates en Java n'existe pas. Les templates en C/C++ sont une vraie daube au niveau sécurité comparé à la généricité de .NET : les templates n'ont aucune "vie" à l'exécution, c'est du sucre syntaxique proposé par le compilateur. Et ca ne t'empêche pas de faire n'importe quoi.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 1.
Java/C# te garantisse une certaine sécurité. C/C++/D non. Même si D te propose d'avoir une meilleure sécurité, il n'y a aucune garantie, tu peux toujours manipuler des pointeurs qui font n'importe quoi, et rien ne t'empêche de le faire. Y'a une énorme différence entre : "t'es pas obligé" et "tu peux pas". Genre en tant qu'utilisateur, je peux obtenir un certain nombre de garantie de la part d'un exécutable .NET, alors qu'un exécutable écrit en D, si le concepteur a voulu faire un truc malveillant...
Je ne parle même pas du framework de sécurité sous-jacent présent dans .NET par exemple, qui permet d'attribuer des droits différents à chaque composant de la plateforme pour toutes les applis.
en Java/C#, le démarrage des VM a un coup de démarrage assez élevé et au départ les performance sont assez faibles (le temps que le JIT génère le code
Faux problème : .NET a été conçu dès la base pour être utilisé en mode AOT (Ahead of Time) : la compilation JIT est faite une fois pour toute, l'exécutable natif est conservé en cache jusqu'à mise à jour.
franchement c'est un avantage très théorique: pour C#, il ne doit pas y avoir beaucoup de programme non-lié aux librairies spécifique a Windows,
Windows ca tourne sur x86 mais aussi x64 et pleins de plateformes embarquées où est présent le framework .NET sous différentes formes.
De plus dans des scénario de remoting (Java RMI, .NET remoting), une compatibilité binaire reste indispensable.
[^] # Re: mon avis
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 1.
Ces fonctionnalités sont fortement dépendantes du type de machine cible. Pour celà les plateformes de type .NET/Java propose une "vue" différente de la machine physique : une machine virtuelle, et c'est elle qui propose la plupart de ces services. Le langage par ses possibilités offertes suppose/exploite les fonctionnalités proposées par la machine cible. Le compilateur étant là pour faire la traduction dans le langage de la machine cible (réelle ou virtuelle).
Bref, c'est tout un éco-système, du langage à la machine cible en passant par le compilateur qui offre ces fonctionnalités. Et c'est pourquoi les plateformes comme .NET/Java ont une machine virtuelle, pour proposer tous ces services. Et c'est pour la même raison que D ne peut avoir ces services, parcqu'ils ont fait le choix de ne pas avoir de machine virtuelle.
Rien n'empêche la création d'une version de D qui s'exécute dans une machine virtuelle avec les services que tu décris.
Avoir D qui tourne sur une machine virtuelle, pourquoi pas, mais sans modification/support du langage, la plupart des services seront inaccessibles.
[^] # Re: Beurk
Posté par TImaniac (site web personnel) . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 6.
Certes, c'est demandé par les distributeurs de logiciels propriétaires, mais ca serait aussi un grand confort pour tous les utilisateurs de logiciels libres : l'utlisateur lambda de mandrake, ubuntu ou fedora il a une distribution à base de binaire, et qu'ils soient proprio ou pas, le problème est le même.
Et puis bon franchement, voir autant de distributions qui font toutes le même boulot de packaging en parrallèle, je trouve ca une perte de temps considérable.
# mon avis
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 6.
J'avoue que j'ai du mal à comprendre le rapport avec ces 2 langages au niveau confort de programmation...
Pour ceux qui viennent du C#/Java, la liste est plus courte, mais un gros avantage: pas de machine virtuelle ou d'interpréteur.
Non, ca c'est le gros désavantage : on perd la couche d'abstraction avec le matos, on perd tous les services de sécurité, les services d'introspection, la portabilité binaire, les services de remoting, et j'en oublie sûrement (au passage ils "oublient" toutes ces fonctionnalités dans leur tableau de comparaison, ils font juste mention du typeof).
Le gros avantage par rapport à C# ou Java, c'est surtout les perfs. C'est en partie lié à l'absence de machine virtuelle, certes, mais surtout au côté "programmation bas-niveau" (tout est relatif, mais bon : pointeurs, pas de vérif, toussa).
Bref, D est plus un remplacant du C/C++ qu'une alternative à C#/Java : pas les mêmes objectifs et donc pas forcement les mêmes utilisations apropriées.
Bon j'espère maintenant que D va être normalisé, ca serait vraiment cool d'avoir un vrai remplacant à ce batard de C++.
[^] # Re: pas forcement comparable
Posté par TImaniac (site web personnel) . En réponse au journal meta-tracker, le tueur de beagle .... Évalué à 1.
[^] # Re: pas forcement comparable
Posté par TImaniac (site web personnel) . En réponse au journal meta-tracker, le tueur de beagle .... Évalué à 2.
Rassure moi, y'a quand même un système de plugins, qui permette d'ajouter des modules sans se préocuper de ce genre de problème de dépendance non ? Si je veux ajouter un filtre dépendant de Qt ou GTK je peux j'espère ?
[^] # Re: pas forcement comparable
Posté par TImaniac (site web personnel) . En réponse au journal meta-tracker, le tueur de beagle .... Évalué à 2.
[^] # Re: le karma moyen des utilisateurs est en baisse
Posté par TImaniac (site web personnel) . En réponse à la dépêche Nouvelle année et statistiques du site. Évalué à 2.
Je fais parti de ces gens avec très souvent une opinion minoritaire. Pourtant je peux encore poster tranquillement sans aucun problème : il suffit d'argumenter et d'ettayer ses propos. Non, les opinions minoritaires ne sont pas muselées. Pareil pour pBpG, il peut toujours poster.
Tu parts du postulat que c'est le système de modération qui a résolu ce problème et qu'il n'a pas d'effet de bord.
C'est quoi l'effet de bord ? Certaines personnes ne peuvent plus poster ? c'est l'objectif. Les gens s'auto-censure dans un espèce de brouhaha consensuel ? Perso je suis loin d'être consensuel et j'ai de nombreux XP.
Avant de proposer quelque chose, il faut déjà s'entendre que l'avantage ou l'inconvénient d'avoir la mini-censure. Si une grosse majorité trouve la mini-censure super, sans défaut, sans effet de bord, il est inutile de proposer quoi que ce soit.
Comment t'évites les questions toi c'est pas possible :) T'es pas d'accord sur le système actuel, propose une alternative qui va tenter de répondre aux mêmes objectifs : limiter la pollution des posts. Tout le monde s'accorde à dire que le système actuel est loin d'être parfait, mais pour l'instant, c'est "faute de mieux".
Et supprimer le système actuel ne va pas arranger les choses.
Ainsi on n'aura les commentaires filtrés sur :
- le score (le système actuel)
- une liste de compte dont les commentaires doivent être masqué. Liste associée par compte.
C'est le système de PCInpact, et ben franchement, les commentaires sont globalement d'un nullissime incroyable. Et leur base doit être polluée au possible. Cela dis, eux sont une entreprise commerciale, ils peuvent se permettre d'avoir des milliers de conneries en base.
Et pour les lecteurs occasionnel comme moi qui n'ont pas de compte, j'ai pas que ca à foutre que de m'amuser à "trier" les cons : je lis plus les commentaires.
Par exemple, pour ton compte, ta liste de compte dont les commentaires sont à masquer pourrait être :
- PasBill PasGate : tu dis la chose même que lui :-)
- IsNotGood : anti-MS primaire
C'est idiot, les gens peuvent évoluer. Si tu caches ses commentaires, tu ne les voies plus. Moi je lis les posts sans à priori sur leur auteur.
Certe firefox fait un joli score mais combien utilise firefox sous Windows ?
A mon avis y'a un bon paquet de moules au boulot qui ne peuvent choisir que leur navigateur web ;)
[^] # Re: PLF indispensable avec une Mandriva
Posté par TImaniac (site web personnel) . En réponse à la dépêche Appel à donations pour zarb.org. Évalué à 2.
La loi est pourtant clair : CSS est un système de protection de contenu, DeCSS le fait sauter, il n'est donc pas légal de l'utiliser, à moins que ce ne soit à des fins de recherche en sécurité ou crypto. Et je penses pas que matter un DVD rentre dans ce dernier cadre ;)