Mais ce n’est pas possible de discuter avec vous, vous remettez en doute sans cesse mes compétences, mais n’hésite pas toi à me donner ton pedigree.
Personnellement, c'est pas que je remettes en cause tes competences, je te connais pas, mais ca fait plus de 15 ans que je fais du C, avec pas mal de multiplateforme justement (j'ai d'ailleurs fait que ca jusqu'a mon arrivee chez MS: un soft tournant sur MIPS, PPC, x86, Sparc avec NetBSD, Linux, IRIX, Windows & Solaris comme OS), alors quand j'entends dire que C c'est un langage multiplateforme, ca herisse les poils, et quand tu me montres plus haut que tu ne comprends pas pourquoi tu peux allouer 1Go sur un systeme avec 1Go de RAM physique, ca me conforte dans l'idee que tu ne maitrise pas forcement tout ce dont tu parles.
Parce que bon, au final tu peux ecrire une JVM C# ou Java en C, donc en theorie tout ce que tu peux faire en C# / Java tu peux le faire en C, mais faut etre un peu realiste et voir le langage pour ce qu'il est dans un contexte d'utilisation normale.
T'as un soft a ecrire de maniere portable, l'ecrire en Java, C# ou autre Python sera bcp plus facile que l'ecrire en C au niveau portabilite.
Parce qu t'avais un Go d'espace d'addressage libre, et qu'il est alle tape dans la swap pour l'espace utilise qu'il a mappe dans ce 1Go d'espace d'addressage.
C'est pour ca que quand tu veux allouer 2Go sur un systeme 32bit tu commences a avoir de tres tres gros problemes, meme si t'as 4Go de RAM, parce Linux reserve automatiquement 1Go de l'espace d'addressage pour le kernel, ca laisse 3Go, sur lesquels il faut enlever ce qui est utilise par le systeme, et esperer avec ca avoir 2Go continus quelque part.
Resultat, t'as beau avoir 4Go de RAM, les chances d'arriver a allouer 2Go sont plutot faibles, alors qu'avec un 80x86 allouer 64Ko c'est chose facile. Resultat, quand tu passes ton code d'un systeme a l'autre, ca compile joliment et tout, tu lances et 3 minutes plus tard quand il fait l'alloc, boum !
C'est ce genre de choses qui font qu'en pratique, quand tu ecris du code un minimum complexe, tu te retrouves avec des problemes de portage en C.
Pour le code, comme je le dis et le répète : c’est portable, rien à faire. Pour du fichier de donnée portable et facile, pas de secret : format texte, printf&co à donf. c’est ce que je fais. Si tu veux du binaires : c’est casse-couille, faut manipuler la mémoire bit-à-bit pour forcer l’endianess&co, c’est portable, juste casse-couille, je n’ai personnellement jamais fait donc je ne saurais te pondre le code là comme ça en 10 minutes, mais c’est possible : c’est ce que fait très certainement la JVM, y’a pas de miracle !
C'est bien, tu commences a comprendre que c'est casse-couille la ou d'autres langages font cela de maniere transparente.
Tu commences a comprendre pourquoi on considere C comme pas trop portable en comparaison de ces langages.
Ensuite, tu te rendras compte que dans enormement de cas un format texte n'est pas realiste, et tu comprendras que dans enormement de cas C est casse-couille.
Moi je regardes la realite, sur les processeurs x86 16bits, allouer 64Ko ca se faisait tres regulierement et passait sans probleme car les machines avaient frequemment jusqu'a 16Mo de RAM (80286) et quasi toujours au moins 512Ko.
Allouer 2Go sur un processeur x86 32bits, dans 95% des cas l'allocation ne fonctionne pas car le systeme n'a pas 2Go dispo lineairement dans son espace d'addressage
Sur un systeme avec entiers 16bits ca a son sens, tu veux allouer un tableau de la taille maximale (une entree pour chaque index possible), ca prend pas enormement de place.
Le probleme etant que des que tu passes sur un autre systeme, ca pete, parce que la taille du type de donnee a change.
Un truc pareil, avec des dizaine d'autres langages cela n'arriverais pas.
Un entier de 16bit, ca fait 65536 valeurs, un entier de 32bits plus de 4 milliards.
Alors, ton soft il passe de l'un a l'autre, tu crois que c'est sans effet de bord ?
Genre ton soft qui faisait des allocations de 64Ko, maintenant risque d'en faire de 4Go, ou autre difference, etc...
Faut se reveiller un peu, porter du code non-trivial en C, c'est pas tout simple.
Quand a la #define INT_MAX codee en dur, tu appelles ca de l'incompetence, moi j'appelles ca vivre dans la vraie vie ou 95% des etudiants sortis d'universite ne savent pas que INT_MAX existe.
Reprends tes cours d'histoire informatique mon cher. C a ete cree pour simplifier le portage d'Unix oui, mais pour remplacer assembleur, qui est vraiment le pire d'ou on puisse partir. C n'a jamais ete concu pour etre le langage multi-plateforme parfait. Le but etait de simplifier le portag(ce qui n'etait pas dur vu d'ou ils partaient) e tout en ayant un portage efficace.
C n'a jamais ete cree pour etre totalement multiplateforme comme nombre d'autres langages, et la preuve flagrante est justement ces differences d'implementation du langage d'un systeme a l'autre.
Typiqument un int de taille different d'une plateforme a l'autre, un pointeur d'une taille differente d'une plateforme a l'autre, ces problemes d'alignement d'une plateforme a l'autre, etc...
Oui il y a toujours un moyen de faire la chose de maniere multi-plateforme (#define, ne pas oublier d'utiliser sizeof, etc...) mais au final, c'est du boulot en plus pour le developpeur, il faut qu'il connaisse, la ou nombre d'autres langages n'ont absolument pas ce besoin d'attention.
C'est pas "la faute du C", simplement parce que le C n'a jamais ete concu pour proteger de cela, il n'a pas ete ecrit pour faire du code multiplateforme.
C'est la difference entre le C, ou le developpeur doit faire des pieds et des mains pour que le code tourne correctement sur plusieurs systemes differents, et des dizaines d'autres langages (Ada, C#, Java, Python, Pascal, ...) ou ce genre de probleme n'existe tout simplement pas.
Pour ECMA, les membres que tu cites ne font pas parti de l’assemblée générale, qui, seule, vote pour ou contre l’inclusion des nouveaux membres à la majorité des 2/3 et pour la publication des normes (dans le menu présentation il y a un pdf, je l’ai un peu parcouru). Les membres que tu cites ont des droits dans les comités techniques, c’est-à-dire l’élaboration des normes. Et en tout il n’y a que 60 entreprises regroupées sous ECMA, toutes ont nécessairement été acceptées par l’AG (c.-à-d. les 18 entreprises pré-citées).
Clairement il y a plus que les 18 grosses societes, y compris des petites societes, par contre il semble ne pas y avoir de fondations a but non lucratif.
Le C est portable, oui, il a été conçu pour ; Wikipedia le dit, mes professeurs me l’ont toujours dit, et je le constate tous les jours : je n’ai jamais eu à porter un code, oui, parce que précisément le C est portable, tous les jours j’utilise le même code sur des machines indifféremment 32 ou 64 bits. Que tu puisses faire des choses non-portables en C démontre juste que ce n’est pas un langage neuneu-proof, mais pas portable : non ; Malloc t’assure l’alignement des données, tu les dé-s-alignes : c’est ton problème.
Non desole, etre un langage portable signifie JUSTEMENT que tu n'es pas sense faire des pieds et des mains pour t'assurer que le code est portable.
Les problemes d'alignement dans les structures, de la definition de ce qu'est un int tout simplement (peut changer de taille d'une machine a l'autre, vive la gestion des overflows), etc... font que c'est un langage CHIANT pour le multiplateforme.
Pour revenir sur le cœur du sujet : je ne crois pas que le numéro du standard correspond à la version du langage, en tout cas les fonctionnalités qu’apportent la version du standard ECMA nº4, si j’en crois ton lien, correspondent aux fonctionnalités du langage en version 2 de chez Microsoft, si j’en crois Wikipedia. La liste des fonctionnalités dans les version 3 et 4 sont donc non normalisées, avec les conséquences que j’ai exposées.
En effet tu avais raison, c'est la 3eme edition, mais elle correspond a C# 2.0, tu noteras par contre que sur http://msdn.microsoft.com/en-us/netframework/aa569283.aspx ils donnent les working drafts pour la 5eme edition du standard, ils y travaillent donc.
Mais je le répète tout ceci est une guerre de communication (c’est le principe du FUD), pour aller vérifier que telle implémentation d’un langage est conforme à telle standard, et donc non soumis à attaque par brevets, il faut avoir des compétences au seins de l’entreprise, et pas des moindres : tout ça pour vérifier qu’on peut utiliser Tomboy (je force le trait) ? Bref s’il faut parcourir une spécification d’un langage et son implémentation pour vérifier les choses, ça signifie que c’est loin d’être simple.
Arf super, et c'est EXACTEMENT la meme choes pour 3533 autre standards, tu vas arreter d'utiliser les codecs video, audio, les fontes etc... alors ?
là ACPI montre que grâce à une implémentation de référence, qui n’est rien d’autre que le standard de facto (hors toute considération de l’existence d’un standard institutionnel), Microsoft a su tourner la situation à son avantage. Il est difficile de croire qu’ils n’en feront pas de même pour le langage dont il est question ici.
Tu m'expliques pourquoi tu rejettes sur MS le fait que certains constructeurs prennent son compilo, qui est clairement labele comme etant fait pour Windows, plutot qu'un compilo ACPI tel que celui d'Intel ?
Enfin vient l’utilisation de techno. Microsoft, oui, le risque « par hasard » n’est pas si petit que ça une fois que tu t’es donné l’objectif de : ré-implémenter avec une technologie Microsoft, avoir une API proche de la lib. Microsoft, etc. Tu offres mécaniquement plus de possibilité de tomber sur le coup d’un brevet. Sans compter que tu as toujours ce problème de communication et de FUD qui vient : cela donne plus de poids à ce dernier pour faire croire qu’il y a lieu de s’inquiéter.
Oui bien sur, par hasard tu vas reimplementer asp.net ou ado.net , sans t'en rendre compte ! Un peu de serieux stp...
Non, c’est juste qu’à force de répondre point par point, on a fini par ne plus parler de la même chose : tu parles de fonctionnalité possible, moi de fonctionnalités accessibles « out of the box » par le design du système (sans nécessiter de couche d’abstraction derrière).
Tu crois que le design du systeme dans Unix fait automatiquement que les devices et autres ont un file descriptor ? Non, ils ont tous une couche qui fait la translation.
Éditer avec vim. Je peux faire "vim /etc/fstab". Je peux faire vim (manière d’accéder au registre en PowerShell) ?
Tu m'expliques la logique ? Tu veux editer quoi dans la registry avec un editeur de texte ? Une entree qui est un chiffre ? Une entree qui est est une ligne de texte ?
Ta demande n'a aucun sens, un editeur de texte est absolument inutile pour la registry.
Mais oui, je reconnais qu’un Unix-like-over-Windows est appréciable. Ce qui prouve que l’approche Unix a fait des émules chez Microsoft aussi. Reste que c’est « récent » (relativement à l’histoire de Windows & Unix — 2005 il me semble), donc dire « je peux faire avec PowerShell ce que je peux faire avec Unix, donc l’architecture de Windows et d’Unix, c’est kif-kif »), c’est légèrement de mauvaise foi.
Je crois surtout que tu melanges absence de couche d'abstraction avec absence de fonctionalite.
Depuis des lustres la registry a les memes APIs, ils n'ont pas change.
Ce qui a change avec powershell c'est l'ajout d'une couche qui donne l'aspect "disque" a la registry.
Depuis au moins XP t'as des outils en ligne de commande qui te permettent d'acceder a la registry de base dans le systeme et tu peux utiliser ces outils dans tes scripts ou pour faire un diff.
Au fait, je peux faire vim sur une partie de la base de registre avec PowerShell ?
J’ai expliqué la différence : je peux l’utiliser avec perl, grep, awk, cut, tar, head/tail, paste, vim. La seule limite étant mon imagination.
Ben oui, et avec powershell aussi
Je suis obligé de me répéter ? Le choix du soft (regedit.exe n’est pas un modèle de clarté à mon goût). La capacité de combiner avec les outils standards.
Tu veux un exemple pratique ? J’ai dernièrement eu à regarder ce que faisait exactement l’installation d’un certain logiciel sur la configuration du système.
Sous unix, cp -r /etc /etc.old ; installation; diff -Nur /etc.old /etc
Avec regedit ? Je cherche toujours.
Tu exportes la branche "software" de la registry, tu laisses le soft tourner, tu exportes la branche "software" de nouveau, et tu fais un diff, en utilisant exactement le meme soft que tu ferais pour un diff texte vu que l'export est textuel.
Et je peux faire pareil pour /proc et /sys. Pour windows, il me faudrait encore un n-ième outil, devices-diff.
pipe() + fork() pour les IPC ?
Mais qui te dit qu'on ne peut pas rediriger les I/O sous Windows ?
Les périphériques accessibles dans le système de fichier ?
Lesquels ? Les disques ? Cela se fait sous Windows. La carte graphique ? Aucun Unix ne le fait
/proc et /sys ?
Oui ca s'appelle la registry, je vois pas trop la difference, t'utilises powershell et tu y accedes comme si c'etait un disque avec des repertoires
Les liens durs ?
Ils existent dans NTFS depuis sa naissance et ils ont toujours ete accessible.
Toute la configuration du système accessible dans le système de fichier et éditable par un éditeur de texte ?
Vois pas trop en quoi cela fait partie de l'architecture, et en quoi etre accessible par un editeur de texte est mieux qu'etre accessible par un autre soft.
Est-ce que tu as seulement lu le lien que tu donnes sur ECMA ? Je vais t’aider et citer le passage. « 4.2 Decisions on acceptance shall be made by the General Assembly with a two thirds majority of all the ordinary members. » Tu continues sur le site, et tu as la liste des membres de l’Assemblée générale : 18 noms, de grosses entreprises. Pour entrer il te faut le soutien de 12 des ces entreprises
Toutes ces entreprises/fondations ne sont pas des grosses entreprises, et ils sont membres de l'assemblee generale.
Le C est multi-plateforme, dire le contraire n’est que l’aboutissement d’années de propagande (je soupçonne Java). Quand tu codes en C tu n’as pas a savoir si t’es en little ou big endian, ni la taille de tes pointeurs, ce sont des représentations internes de la machine et le C permet justement de s’en affranchir ! Quand j’écris un int, et durant tout le code, je me fiche des détails techniques de représentation des nombres : endianness, taille des données à la précision numérique près, etc. Quand j’écris un code ANSI C il doit tourner et rendre le même résultat quelque soit la machine le supportant (à la précision numérique près), la force du C est très précisément d’abstraire ces problèmes de représentation interne.
Ben va t'amuser a prendre du code qui tourne sur une machine A et porte le sur une machine B, tu vas comprendre, si tu ne fais pas extremement attention, tu te feras bouffer.
Au hasard le fait que ta taille de pointeur est passee de 4 a 8 bytes, que ton alignement des allocations a change, que le systeme A lance une exception en cas d'acces non-aligne alors que le systeme B ne le fait pas, ...
Visiblement tu n'a jamais eu a faire un portage.
Tu dis « la version normalisée est la 3.0 », j’attends tes sources, parce que ce n’est pas ce que dit Wikipedia, du coup je suis allé voir la liste des standard ECMA : C# 4ème édition : juin 2006, selon Wikipedia la sortie de la version 3.0 du langage chez Microsoft date d’Août 2007.
Et ? Ca n'empeche pas de normaliser le langage avant la sortie de Visual Studio hein...
In June 2005, the General Assembly of the international standardization organization Ecma approved edition 3 of the C# Language and the Common Language Infrastructure (CLI) specifications, as updated Ecma-334 and Ecma-335, respectively (see press release).
Concernant ACPI, au contraire j’ai parfaitement compris le problème, je l’ai posé en terme d’implémentation de référence : si l’implémentation de référence ne respecte pas le standard, ce dernier ne sert plus à rien. Je fais le parallèle avec la situation de Mono vs. l’implémentation de Microsoft.
Mais qui te parle d'implementation de reference ? Qui a designe le compilo de MS comme implementation de reference ? Ils disent clairement que ce compilo est la pour le support de Windows, pas autre chose.
T'utilises le compilo Intel, Windows tourne et Linux tourne, c'est pas un probleme. Et va pas me dire qu'Intel est un nain hein, ils font partie des createurs d'ACPI au meme titre que MS.
Mais il est difficile de faire la part des choses et de relever ce qui est couvert par les brevets de ce qui ne l’est pas. C’est déjà assez difficile concernant le noyau… c’est une guerre de communication : utiliser des techno. de chez Microsoft c’est donner de la force au FUD.
C'est tres clair, tout ce qui est dans la spec ECMA est protege contre les brevets, point a la ligne.
Mono est développé par Novell qui a des accords spécifiques avec Microsoft. Qu’en est-il du reste de l’éco-système, libre, non-libre, commerciaux, etc., qui utiliserait Mono, implémenterait une lib. avec des fonctionnalités proches d’une lib. non couverte par les accords, tout ceci sur une techno. spécifiquement Microsoft, tu vas me dire qu’il n’existe aucun risque de tomber sur une solution proche de ce qu’à utiliser, et breveté, Microsoft ? Le risque est àmha plus grand que de partir from scratch.
Et dis-moi, quel est le risque si tu implementes DirectX ou autre lib MS sous Linux ? Identique a implementer une lib MS sous Mono.
Tu vas me faire croire que par hasard tu vas reimplementer une lib MS sans t'en rendre compte ? Tu te fiches de moi ?
Dans ce cas il suit l’implémentation de référence : retour à la case départ, ce sera du Microsoft, ça ne sera plus couvert par un standard, donc soumis à des attaques ou FUD sur les brevets. Ou alors Mono suit sa propre voie, redéfinit un langage à lui, etc., mais on perd toute compatibilité. Je ne sais pas pourquoi je me répète, tu ne vas pas plus lire que la première fois.
N'importe quoi, tu m'expliques pourquoi il ne peut pas suivre LA SPEC plutot que l'implementation MS ?
Parce que tu vois, c'est ce qu'il fait, il implemente des elements de la spec que meme MS n'implemente pas.
Ton avis sur les brevets on s'en fout un peu, c'est pas le sujet...
La realite est que si il y a un systeme de brevet, il faut le faire de maniere correcte et efficace. Avoir un systeme de brevets pourri ne va aider personne.
Hmm quand tu ouvres simplement un document et que *sur ton écran* tes titres partent en cacahuète c'est un problème d'imprimante ?
J'aimerais bien voir un cas de cela, t'as un document qui fait cela ?
LaTeX ce n'est pas que le langage, tu as aussi tous les packages kivonbiens tout autour, et ce n'est pas parce que le numéro de version n'augmente pas que
des nouveaux packages n'arrivent pas.
Un nouveau package par definition ne va pas affecter un document, vu que ce document ne l'utilise pas.
C'est un peu comme ajouter un plugin a Word, si le document n'utilises pas le plugin, aucune chance que ton document soit touche.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
Personnellement, c'est pas que je remettes en cause tes competences, je te connais pas, mais ca fait plus de 15 ans que je fais du C, avec pas mal de multiplateforme justement (j'ai d'ailleurs fait que ca jusqu'a mon arrivee chez MS: un soft tournant sur MIPS, PPC, x86, Sparc avec NetBSD, Linux, IRIX, Windows & Solaris comme OS), alors quand j'entends dire que C c'est un langage multiplateforme, ca herisse les poils, et quand tu me montres plus haut que tu ne comprends pas pourquoi tu peux allouer 1Go sur un systeme avec 1Go de RAM physique, ca me conforte dans l'idee que tu ne maitrise pas forcement tout ce dont tu parles.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
Parce que bon, au final tu peux ecrire une JVM C# ou Java en C, donc en theorie tout ce que tu peux faire en C# / Java tu peux le faire en C, mais faut etre un peu realiste et voir le langage pour ce qu'il est dans un contexte d'utilisation normale.
T'as un soft a ecrire de maniere portable, l'ecrire en Java, C# ou autre Python sera bcp plus facile que l'ecrire en C au niveau portabilite.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
C'est pour ca que quand tu veux allouer 2Go sur un systeme 32bit tu commences a avoir de tres tres gros problemes, meme si t'as 4Go de RAM, parce Linux reserve automatiquement 1Go de l'espace d'addressage pour le kernel, ca laisse 3Go, sur lesquels il faut enlever ce qui est utilise par le systeme, et esperer avec ca avoir 2Go continus quelque part.
Resultat, t'as beau avoir 4Go de RAM, les chances d'arriver a allouer 2Go sont plutot faibles, alors qu'avec un 80x86 allouer 64Ko c'est chose facile. Resultat, quand tu passes ton code d'un systeme a l'autre, ca compile joliment et tout, tu lances et 3 minutes plus tard quand il fait l'alloc, boum !
C'est ce genre de choses qui font qu'en pratique, quand tu ecris du code un minimum complexe, tu te retrouves avec des problemes de portage en C.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 0.
C'est bien, tu commences a comprendre que c'est casse-couille la ou d'autres langages font cela de maniere transparente.
Tu commences a comprendre pourquoi on considere C comme pas trop portable en comparaison de ces langages.
Ensuite, tu te rendras compte que dans enormement de cas un format texte n'est pas realiste, et tu comprendras que dans enormement de cas C est casse-couille.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
Allouer 2Go sur un processeur x86 32bits, dans 95% des cas l'allocation ne fonctionne pas car le systeme n'a pas 2Go dispo lineairement dans son espace d'addressage
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
Le probleme etant que des que tu passes sur un autre systeme, ca pete, parce que la taille du type de donnee a change.
Un truc pareil, avec des dizaine d'autres langages cela n'arriverais pas.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 0.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 0.
Amuses toi avec un truc du genre :
int* MyArray=malloc(INT_MAX); --> alloue 32Ko sur une machine avec entiers de 16bit, ce qui est tout a fait acceptable.
Maintenant va passer ca sur une machine avec entiers en 32bit et prend toi l'allocation de 2Go dans la tronche, ca va etre drole...
Quand a Java, si j'en crois http://download.oracle.com/javase/tutorial/java/nutsandbolts(...) c'est tres clair, un int est 32bit, quel que soit l'OS du dessous (normal vu que la JVM donne une plateforme abstraite identique partout).
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
Un entier de 16bit, ca fait 65536 valeurs, un entier de 32bits plus de 4 milliards.
Alors, ton soft il passe de l'un a l'autre, tu crois que c'est sans effet de bord ?
Genre ton soft qui faisait des allocations de 64Ko, maintenant risque d'en faire de 4Go, ou autre difference, etc...
Faut se reveiller un peu, porter du code non-trivial en C, c'est pas tout simple.
Quand a la #define INT_MAX codee en dur, tu appelles ca de l'incompetence, moi j'appelles ca vivre dans la vraie vie ou 95% des etudiants sortis d'universite ne savent pas que INT_MAX existe.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 4.
http://www.medsphere.com/solutions/system-architecture
http://www.sourcegear.com/vault/index.html
etc...
De rien
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
Ensuites quand tu veux changer une valeur, t'utilises reg.exe set <ce que tu veux>
etc...
Si tu veux envoyer ta config, t'as reg.exe export
Tu peux comparer avec reg.exe compare
etc...
Et bien evidemment tu peux scripter ca dans tous les sens, et c'est de base dans l'OS depuis des annees.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
C n'a jamais ete cree pour etre totalement multiplateforme comme nombre d'autres langages, et la preuve flagrante est justement ces differences d'implementation du langage d'un systeme a l'autre.
Typiqument un int de taille different d'une plateforme a l'autre, un pointeur d'une taille differente d'une plateforme a l'autre, ces problemes d'alignement d'une plateforme a l'autre, etc...
Oui il y a toujours un moyen de faire la chose de maniere multi-plateforme (#define, ne pas oublier d'utiliser sizeof, etc...) mais au final, c'est du boulot en plus pour le developpeur, il faut qu'il connaisse, la ou nombre d'autres langages n'ont absolument pas ce besoin d'attention.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à -1.
C'est la difference entre le C, ou le developpeur doit faire des pieds et des mains pour que le code tourne correctement sur plusieurs systemes differents, et des dizaines d'autres langages (Ada, C#, Java, Python, Pascal, ...) ou ce genre de probleme n'existe tout simplement pas.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
En fait on avait tous les 2 tort, voila les membres de l'AG : http://www.ecma-international.org/memento/GA.htm
Clairement il y a plus que les 18 grosses societes, y compris des petites societes, par contre il semble ne pas y avoir de fondations a but non lucratif.
Le C est portable, oui, il a été conçu pour ; Wikipedia le dit, mes professeurs me l’ont toujours dit, et je le constate tous les jours : je n’ai jamais eu à porter un code, oui, parce que précisément le C est portable, tous les jours j’utilise le même code sur des machines indifféremment 32 ou 64 bits. Que tu puisses faire des choses non-portables en C démontre juste que ce n’est pas un langage neuneu-proof, mais pas portable : non ; Malloc t’assure l’alignement des données, tu les dé-s-alignes : c’est ton problème.
Non desole, etre un langage portable signifie JUSTEMENT que tu n'es pas sense faire des pieds et des mains pour t'assurer que le code est portable.
Les problemes d'alignement dans les structures, de la definition de ce qu'est un int tout simplement (peut changer de taille d'une machine a l'autre, vive la gestion des overflows), etc... font que c'est un langage CHIANT pour le multiplateforme.
Pour revenir sur le cœur du sujet : je ne crois pas que le numéro du standard correspond à la version du langage, en tout cas les fonctionnalités qu’apportent la version du standard ECMA nº4, si j’en crois ton lien, correspondent aux fonctionnalités du langage en version 2 de chez Microsoft, si j’en crois Wikipedia. La liste des fonctionnalités dans les version 3 et 4 sont donc non normalisées, avec les conséquences que j’ai exposées.
En effet tu avais raison, c'est la 3eme edition, mais elle correspond a C# 2.0, tu noteras par contre que sur http://msdn.microsoft.com/en-us/netframework/aa569283.aspx ils donnent les working drafts pour la 5eme edition du standard, ils y travaillent donc.
Mais je le répète tout ceci est une guerre de communication (c’est le principe du FUD), pour aller vérifier que telle implémentation d’un langage est conforme à telle standard, et donc non soumis à attaque par brevets, il faut avoir des compétences au seins de l’entreprise, et pas des moindres : tout ça pour vérifier qu’on peut utiliser Tomboy (je force le trait) ? Bref s’il faut parcourir une spécification d’un langage et son implémentation pour vérifier les choses, ça signifie que c’est loin d’être simple.
Arf super, et c'est EXACTEMENT la meme choes pour 3533 autre standards, tu vas arreter d'utiliser les codecs video, audio, les fontes etc... alors ?
là ACPI montre que grâce à une implémentation de référence, qui n’est rien d’autre que le standard de facto (hors toute considération de l’existence d’un standard institutionnel), Microsoft a su tourner la situation à son avantage. Il est difficile de croire qu’ils n’en feront pas de même pour le langage dont il est question ici.
Tu m'expliques pourquoi tu rejettes sur MS le fait que certains constructeurs prennent son compilo, qui est clairement labele comme etant fait pour Windows, plutot qu'un compilo ACPI tel que celui d'Intel ?
Enfin vient l’utilisation de techno. Microsoft, oui, le risque « par hasard » n’est pas si petit que ça une fois que tu t’es donné l’objectif de : ré-implémenter avec une technologie Microsoft, avoir une API proche de la lib. Microsoft, etc. Tu offres mécaniquement plus de possibilité de tomber sur le coup d’un brevet. Sans compter que tu as toujours ce problème de communication et de FUD qui vient : cela donne plus de poids à ce dernier pour faire croire qu’il y a lieu de s’inquiéter.
Oui bien sur, par hasard tu vas reimplementer asp.net ou ado.net , sans t'en rendre compte ! Un peu de serieux stp...
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Tu crois que le design du systeme dans Unix fait automatiquement que les devices et autres ont un file descriptor ? Non, ils ont tous une couche qui fait la translation.
Éditer avec vim. Je peux faire "vim /etc/fstab". Je peux faire vim (manière d’accéder au registre en PowerShell) ?
Tu m'expliques la logique ? Tu veux editer quoi dans la registry avec un editeur de texte ? Une entree qui est un chiffre ? Une entree qui est est une ligne de texte ?
Ta demande n'a aucun sens, un editeur de texte est absolument inutile pour la registry.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Je crois surtout que tu melanges absence de couche d'abstraction avec absence de fonctionalite.
Depuis des lustres la registry a les memes APIs, ils n'ont pas change.
Ce qui a change avec powershell c'est l'ajout d'une couche qui donne l'aspect "disque" a la registry.
Depuis au moins XP t'as des outils en ligne de commande qui te permettent d'acceder a la registry de base dans le systeme et tu peux utiliser ces outils dans tes scripts ou pour faire un diff.
Au fait, je peux faire vim sur une partie de la base de registre avec PowerShell ?
Ca veut dire quoi 'faire vim' ?
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Eh oui : http://support.microsoft.com/kb/q100027
J’ai expliqué la différence : je peux l’utiliser avec perl, grep, awk, cut, tar, head/tail, paste, vim. La seule limite étant mon imagination.
Ben oui, et avec powershell aussi
Je suis obligé de me répéter ? Le choix du soft (regedit.exe n’est pas un modèle de clarté à mon goût). La capacité de combiner avec les outils standards.
Tu veux un exemple pratique ? J’ai dernièrement eu à regarder ce que faisait exactement l’installation d’un certain logiciel sur la configuration du système.
Sous unix, cp -r /etc /etc.old ; installation; diff -Nur /etc.old /etc
Avec regedit ? Je cherche toujours.
Tu exportes la branche "software" de la registry, tu laisses le soft tourner, tu exportes la branche "software" de nouveau, et tu fais un diff, en utilisant exactement le meme soft que tu ferais pour un diff texte vu que l'export est textuel.
Et je peux faire pareil pour /proc et /sys. Pour windows, il me faudrait encore un n-ième outil, devices-diff.
Ben non, idem
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
Mais qui te dit qu'on ne peut pas rediriger les I/O sous Windows ?
Les périphériques accessibles dans le système de fichier ?
Lesquels ? Les disques ? Cela se fait sous Windows. La carte graphique ? Aucun Unix ne le fait
/proc et /sys ?
Oui ca s'appelle la registry, je vois pas trop la difference, t'utilises powershell et tu y accedes comme si c'etait un disque avec des repertoires
Les liens durs ?
Ils existent dans NTFS depuis sa naissance et ils ont toujours ete accessible.
Toute la configuration du système accessible dans le système de fichier et éditable par un éditeur de texte ?
Vois pas trop en quoi cela fait partie de l'architecture, et en quoi etre accessible par un editeur de texte est mieux qu'etre accessible par un autre soft.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
N'importe quoi !
http://www.ecma-international.org/memento/NFP.htm
http://www.ecma-international.org/memento/SPC.htm
http://www.ecma-international.org/memento/SME.htm
Toutes ces entreprises/fondations ne sont pas des grosses entreprises, et ils sont membres de l'assemblee generale.
Le C est multi-plateforme, dire le contraire n’est que l’aboutissement d’années de propagande (je soupçonne Java). Quand tu codes en C tu n’as pas a savoir si t’es en little ou big endian, ni la taille de tes pointeurs, ce sont des représentations internes de la machine et le C permet justement de s’en affranchir ! Quand j’écris un int, et durant tout le code, je me fiche des détails techniques de représentation des nombres : endianness, taille des données à la précision numérique près, etc. Quand j’écris un code ANSI C il doit tourner et rendre le même résultat quelque soit la machine le supportant (à la précision numérique près), la force du C est très précisément d’abstraire ces problèmes de représentation interne.
Ben va t'amuser a prendre du code qui tourne sur une machine A et porte le sur une machine B, tu vas comprendre, si tu ne fais pas extremement attention, tu te feras bouffer.
Au hasard le fait que ta taille de pointeur est passee de 4 a 8 bytes, que ton alignement des allocations a change, que le systeme A lance une exception en cas d'acces non-aligne alors que le systeme B ne le fait pas, ...
Visiblement tu n'a jamais eu a faire un portage.
Tu dis « la version normalisée est la 3.0 », j’attends tes sources, parce que ce n’est pas ce que dit Wikipedia, du coup je suis allé voir la liste des standard ECMA : C# 4ème édition : juin 2006, selon Wikipedia la sortie de la version 3.0 du langage chez Microsoft date d’Août 2007.
Et ? Ca n'empeche pas de normaliser le langage avant la sortie de Visual Studio hein...
http://msdn.microsoft.com/en-us/netframework/aa569283.aspx
In June 2005, the General Assembly of the international standardization organization Ecma approved edition 3 of the C# Language and the Common Language Infrastructure (CLI) specifications, as updated Ecma-334 and Ecma-335, respectively (see press release).
Concernant ACPI, au contraire j’ai parfaitement compris le problème, je l’ai posé en terme d’implémentation de référence : si l’implémentation de référence ne respecte pas le standard, ce dernier ne sert plus à rien. Je fais le parallèle avec la situation de Mono vs. l’implémentation de Microsoft.
Mais qui te parle d'implementation de reference ? Qui a designe le compilo de MS comme implementation de reference ? Ils disent clairement que ce compilo est la pour le support de Windows, pas autre chose.
T'utilises le compilo Intel, Windows tourne et Linux tourne, c'est pas un probleme. Et va pas me dire qu'Intel est un nain hein, ils font partie des createurs d'ACPI au meme titre que MS.
Mais il est difficile de faire la part des choses et de relever ce qui est couvert par les brevets de ce qui ne l’est pas. C’est déjà assez difficile concernant le noyau… c’est une guerre de communication : utiliser des techno. de chez Microsoft c’est donner de la force au FUD.
Non, cela n'a ABSOLUMENT RIEN de difficile : http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-(...)
C'est tres clair, tout ce qui est dans la spec ECMA est protege contre les brevets, point a la ligne.
Mono est développé par Novell qui a des accords spécifiques avec Microsoft. Qu’en est-il du reste de l’éco-système, libre, non-libre, commerciaux, etc., qui utiliserait Mono, implémenterait une lib. avec des fonctionnalités proches d’une lib. non couverte par les accords, tout ceci sur une techno. spécifiquement Microsoft, tu vas me dire qu’il n’existe aucun risque de tomber sur une solution proche de ce qu’à utiliser, et breveté, Microsoft ? Le risque est àmha plus grand que de partir from scratch.
Et dis-moi, quel est le risque si tu implementes DirectX ou autre lib MS sous Linux ? Identique a implementer une lib MS sous Mono.
Tu vas me faire croire que par hasard tu vas reimplementer une lib MS sans t'en rendre compte ? Tu te fiches de moi ?
Dans ce cas il suit l’implémentation de référence : retour à la case départ, ce sera du Microsoft, ça ne sera plus couvert par un standard, donc soumis à des attaques ou FUD sur les brevets. Ou alors Mono suit sa propre voie, redéfinit un langage à lui, etc., mais on perd toute compatibilité. Je ne sais pas pourquoi je me répète, tu ne vas pas plus lire que la première fois.
N'importe quoi, tu m'expliques pourquoi il ne peut pas suivre LA SPEC plutot que l'implementation MS ?
Parce que tu vois, c'est ce qu'il fait, il implemente des elements de la spec que meme MS n'implemente pas.
[^] # Re: EFF au secours !
Posté par pasBill pasGates . En réponse au journal De la déchéance des brevets. Évalué à 1.
La realite est que si il y a un systeme de brevet, il faut le faire de maniere correcte et efficace. Avoir un systeme de brevets pourri ne va aider personne.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
J'aimerais bien voir un cas de cela, t'as un document qui fait cela ?
LaTeX ce n'est pas que le langage, tu as aussi tous les packages kivonbiens tout autour, et ce n'est pas parce que le numéro de version n'augmente pas que
des nouveaux packages n'arrivent pas.
Un nouveau package par definition ne va pas affecter un document, vu que ce document ne l'utilise pas.
C'est un peu comme ajouter un plugin a Word, si le document n'utilises pas le plugin, aucune chance que ton document soit touche.