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.
Tu veux comparer comment la compatibilite ascendante d'un soft sans comparer plusieurs versions ? T'as une technique magique ?
Resultat, si il n'y a pas plusieurs versions --> Impossible de comparer la compatibilite ascendante.
Sinon, une nouvelle version c'est pas simplement pour corriger des bugs hein, c'est aussi souvent pour rajouter des features et changer des trucs qui auraient pu etre fait de meilleure maniere.
Note que je trouves LaTeX super comme soft, il fait ce qu'il est sense faire tres tres bien, mais dans cette discussion(compatibilite ascendante) il n'entre tout simplement pas en compte.
Le standard peut lui-même apporter certaines garanties en fonction des entreprises qui y ont pris part, au passage dire que n’importe qui peut y prendre part est faux : pour l’ISO ce sont les organisations nationales, pour l’ECMA les règles sont un peu plus compliquées et les droits ne sont pas les mêmes pour tout le monde, mais de ce que j’en ai compris ce sont les (grosses) entreprises, et c’est normal, le but de ces organisations est d’émettre des standard industriels et commerciaux !
La popularité du C vient du fait qu’il a été conçu dès le départ pour une très grande abstraction du matériel sur lequel il tourne, c’est à dire son côté multi-plateforme.
Tu m'excuseras mais non pas du tout, le C n'a pas grand-chose de multi-plateforme, son avantage est justement d'etre tres proche du materiel. C'est aussi son desavantage d'ailleurs, il l'est trop, un simple pointeur par exemple change de taille selon le systeme, le cote big/little endian n'est pas du tout gere, etc...
À côté de ça tu as le C♯, la version normalisée est la 2.0, Microsoft utilise la 4.0.
Non, la version normalisee est la 3.0 , la 4.0 est sortie il y a quelque mois donc ca va venir.
Le langage est très lié au framework .NET (développé en parallèle, annoncé en même temps), technologie exclusivement Microsoft.
Il y est lie en quoi ? A part avec la base de la base du framework en rien du tout, et la base du framework est standardisee aussi.
Pour ceux qui ne voient pas de quoi je parle : il y avait un fil ou un des trolleur avait rapporté l’existence, dont personne ne semble avoir remis en doute la réalité, d’un mail où Microsoft proposait que la norme ACPI soit orientée de telle sorte à favoriser Windows ; on parle régulièrement de problèmes liés à des bugs ACPI, curieusement bien corrigé par Windows : difficile de ne pas faire un parallèle
Faudrait penser a comprendre le probleme : MS donne un compilo ACPI pour Windows, ce compilo ne gere que Windows, car MS ne s'interesse qu'a Windows. Evidemment que les constructeurs qui utilisent ce compilo risquent de se retrouver avec du code qui ne fait pas tourner Linux, a eux d'utiliser un compilo fait pour etre multi-OS.
Il y a aussi un paragraphe sur l’article C♯ de la wikipedia anglaise à propos des accords passés avec Novell, c’est loin d’être simple et forcément donne de quoi se méfier, car populariser des solutions comme Mono c’est aussi donner plus de poids au FUD à propos des brevets.
Il n'y a aucun FUD la dedans, Mono est couvert par une promesse de MS sur les brevets, il n'y a donc absolument _AUCUN_ risque, que ce soit demain ou dans 20 ans.
Mais si je devais décider je préférerais encore tout simplement éviter de tendre la joue et ne pas utiliser de solutions comme Mono, ou alors se limiter à la version normalisée car elle protège contre l’attaque par brevet si j’en crois Wikipedia, mais on perd l’aspect multi-plateforme et compatibilité avec Microsoft qui utilise la version 4.0
T'as toujours pas compris le probleme.
C#, que ce soit 1.0, 2.0, 3.0 ou 4.0 est propre niveau brevets et il n'y a aucun risque.
Le risque, c'est quand t'utilises une reimplementation d'une librairie MS qui ne fait pas partie du framework standardise, genre WindowsForms.
Tu peux tout a fait ecrire un tas de softs en C# 4.0 avec Mono qui sont garantis 100% sans aucun risque niveau brevets MS, faut simplement suivre le standard qui te dit ce qui est standardise et ce qui ne l'est pas (ADO.net, ASP.Net, Windows Forms,..)
Il existe donc une seule implémentation, qui sera a fortiori une implémentation de référence : celle de Microsoft.
Non il y en a au moins 2 vu que Mono implemente C# 4 en toute legalite.
Si Microsoft décide de s’écarter franchement de la norme ? Que fait la Mono ? Suivre la norme… bien… mais on perd, encore une fois, toute compatibilité avec la référence, et donc le risque de perdre la très grande majorité des programmes ou développeurs qui se soucient peu de la compatibilité.
Et pourquoi est-ce que Mono suivrait ? Il y a une loi qui dit que Mono doit suivre comme un petit chien ?
PS : dans le monde du libre l’historique d’une société compte, si elle fait des coups bas les gens le retiennent.
Pas vraiment non, ils ont tendance a retenir ce qui leur plait et oublier le reste(je parles des fans, les devs ont plus d'experience et mettent de l'eau dans leur vin)
à propos des chevilles, c’est caractéristique de ton discours hautain, et ça a le mérite de mettre en évidence la culture d’entreprise qui doit régner : « on est les meilleurs ». Forcément quand ça reste entre vous c’est gratifiant de se faire mousser, par contre ici (alias linuxfr) ça passe très mal, et quand je dis ça je pense pouvoir parler au nom de pas mal d’entre nous. Tu réclames que certains d’entre nous se fassent plus consensuels sur leur discours contre Microsoft, mais j’espère que tu te rends compte que dans le genre tu en imposes…
Je vais pas le cacher, je trouves que sur certains aspects MS est loin devant les autres, il y a aussi des aspects ou on est derriere c'est evident, mais je vais pas me forcer a cacher les bons cotes pour faire plaisir aux gens ici, c'est pas vraiment ma nature.
Moi je te suggeres de mettre un peu d'eau dans ton vin si tu veux etre pris au serieux.
Les conneries genre MS n'a rien invente, MS veut faire des softs qui muselent ses utilisateurs, etc... c'est bon pour les fanboys linuxiens a qui ca fera plaisir, mais pour tout le reste de la planete qui a les yeux ouverts, ca te fait passer pour un extremiste decale de la realite.
Il y a la realite (il le fait tres bien, avec quelques problemes de temps en temps quand meme, il y a des bugs chez tout le monde), et le mythe repandu chez nos amis linuxiens qui ont tendance a ne pas comprendre comment un soft fonctionne et tout mettre sur le dos de MS(hint: le rendu depend de l'imprimante notamment)
Un document latex écrit avec emacs a toujours le même rendu, merci bien.
Elle est bonne celle-la...
Latex 2 est sorti en 1994, Latex 3 ? Toujours pas sorti...
Word 2010 t'ouvres toujours un fichier de Word d'il y a 15 ans avec une representation correcte si ce n'est parfaite.
Va essayer d'en faire de meme avec les autres softs du secteur, bon il est vrai que la majorite d'entre eux n'existaient meme pas il y a 15 ans...
Garanties ? Mais aucune voyons, tu me donnes un langage qui t'apporte des garanties ? Ca n'existe pas. Avoir une fondation ou autre ne te garantit absolument rien du tout non plus.
Si tu veux un truc similaire au community process de Java, il ya ECMA et ISO, qui valide les specs de C#, ou plusieurs societes et individus participent, ou je le rappelle n'importe qui peut participer hein.
Quand aux implementations de reference, le langage est une spec, personne ne code d'implementation de reference(= qui ferait foi), tout le monde code une implementation, et comme tout langage certaines implementations auront des bugs differents, peut-etre quelques unes seront 100% compliant, etc...
Parce que faut arreter de croire que C a une implementation de reference, il n'en a pas.
Quand au premier, oui merci les chevilles vont bien.
On peut pas demander a une boite d'etre 100% sure qu'elle est bien celle qui a trouve cette idee la premiere, c'est le boulot de l'office des brevets, sinon il sert a rien cet office des brevets...
Type de kernel, systeme multi-utilisateur avec permissions, etc ...
Il y a bien evidemment de grosses differences en terme d'implementation (type de scheduling, structures internes, systeme de drivers, etc...) mais pas forcement plus qu'entre un Linux et un AIX ou HP-UX ou autre.
a) C'est un langage sorti tout droit d'une entreprise dont la reputation niveau compatibilite avec l'ancien n'est plus a faire, personne n'arrive a notre cheville sur ce sujet
b) Ca fait quand meme pas mal d'annees que C# existe maintenant, et il n'y a pas eu de problemes
- C# 4 est sorti en Avril 2010, Mono l'a supporte en Septembre soit a peine 5 mois plus tard.
- Que Mono soit un sous-produit de .NET ou pas tout le monde s'en fout, la question est : est-ce qu'il est utile ou pas aux developpeurs, et la la reponse est clairement oui
- C# aussi est stable depuis des annees, et Mono clairement n'est pas en retard
Moi je te paries une Ferrari qu'aucun ingenieur Microsoft sobre n'a jamais dit ca. Rien que pour une question de cout et compatibilite.
Mais sinon, comme il a été dit plus tôt sur le ton de la rigolade, ca pourrait effectivement permettre aux OS de Microsoft de repartir sur des bases Unix éprouvées et donc de bénéficier de toutes les qualités de ces systèmes. Et accessoirement d'avoir la possibilité de se débarrasser d'une partie des reproches qui leur sont fait sur le coté passoire de Windows.
a) L'archicture Unix et Windows est deja quasiment la meme
b) Windows n'est en rien une passoire. Si on se fie aux chiffres en bugs, a ce que la communaute securite pense plutot que ce que pensens les fanboys linuxiens c'est clair et net
c) Je vois toujours pas un seul truc qu'un Unix (= grace a l'architecture Unix, donc tout Unix) peut faire qu'un Windows ne peut pas faire
Non, la loi US punit les _abus_ de monopole, pas etre un monopole en soi.
Parce que des monopoles ici il y en a plein, notamment dans les telecoms, operateurs cable & internet, ...
Quand aux abus, MS a ete condamne pour certains abus, et a perdu d'autres proces contre d'autres societes, ce qui montre qu'ils ne controlent pas la justice quoi que tu en dises.
[^] # 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.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Resultat, si il n'y a pas plusieurs versions --> Impossible de comparer la compatibilite ascendante.
Sinon, une nouvelle version c'est pas simplement pour corriger des bugs hein, c'est aussi souvent pour rajouter des features et changer des trucs qui auraient pu etre fait de meilleure maniere.
Note que je trouves LaTeX super comme soft, il fait ce qu'il est sense faire tres tres bien, mais dans cette discussion(compatibilite ascendante) il n'entre tout simplement pas en compte.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
Non, ECMA accepte les petites et grandes entreprises, ainsi que les organisations a but non-lucratif, qui y ont les memes droits que les societes, cf. http://www.ecma-international.org/memento/Ecmabylaws.htm
La popularité du C vient du fait qu’il a été conçu dès le départ pour une très grande abstraction du matériel sur lequel il tourne, c’est à dire son côté multi-plateforme.
Tu m'excuseras mais non pas du tout, le C n'a pas grand-chose de multi-plateforme, son avantage est justement d'etre tres proche du materiel. C'est aussi son desavantage d'ailleurs, il l'est trop, un simple pointeur par exemple change de taille selon le systeme, le cote big/little endian n'est pas du tout gere, etc...
À côté de ça tu as le C♯, la version normalisée est la 2.0, Microsoft utilise la 4.0.
Non, la version normalisee est la 3.0 , la 4.0 est sortie il y a quelque mois donc ca va venir.
Le langage est très lié au framework .NET (développé en parallèle, annoncé en même temps), technologie exclusivement Microsoft.
Il y est lie en quoi ? A part avec la base de la base du framework en rien du tout, et la base du framework est standardisee aussi.
Pour ceux qui ne voient pas de quoi je parle : il y avait un fil ou un des trolleur avait rapporté l’existence, dont personne ne semble avoir remis en doute la réalité, d’un mail où Microsoft proposait que la norme ACPI soit orientée de telle sorte à favoriser Windows ; on parle régulièrement de problèmes liés à des bugs ACPI, curieusement bien corrigé par Windows : difficile de ne pas faire un parallèle
Faudrait penser a comprendre le probleme : MS donne un compilo ACPI pour Windows, ce compilo ne gere que Windows, car MS ne s'interesse qu'a Windows. Evidemment que les constructeurs qui utilisent ce compilo risquent de se retrouver avec du code qui ne fait pas tourner Linux, a eux d'utiliser un compilo fait pour etre multi-OS.
Il y a aussi un paragraphe sur l’article C♯ de la wikipedia anglaise à propos des accords passés avec Novell, c’est loin d’être simple et forcément donne de quoi se méfier, car populariser des solutions comme Mono c’est aussi donner plus de poids au FUD à propos des brevets.
Il n'y a aucun FUD la dedans, Mono est couvert par une promesse de MS sur les brevets, il n'y a donc absolument _AUCUN_ risque, que ce soit demain ou dans 20 ans.
Mais si je devais décider je préférerais encore tout simplement éviter de tendre la joue et ne pas utiliser de solutions comme Mono, ou alors se limiter à la version normalisée car elle protège contre l’attaque par brevet si j’en crois Wikipedia, mais on perd l’aspect multi-plateforme et compatibilité avec Microsoft qui utilise la version 4.0
T'as toujours pas compris le probleme.
C#, que ce soit 1.0, 2.0, 3.0 ou 4.0 est propre niveau brevets et il n'y a aucun risque.
Le risque, c'est quand t'utilises une reimplementation d'une librairie MS qui ne fait pas partie du framework standardise, genre WindowsForms.
Tu peux tout a fait ecrire un tas de softs en C# 4.0 avec Mono qui sont garantis 100% sans aucun risque niveau brevets MS, faut simplement suivre le standard qui te dit ce qui est standardise et ce qui ne l'est pas (ADO.net, ASP.Net, Windows Forms,..)
Il existe donc une seule implémentation, qui sera a fortiori une implémentation de référence : celle de Microsoft.
Non il y en a au moins 2 vu que Mono implemente C# 4 en toute legalite.
Si Microsoft décide de s’écarter franchement de la norme ? Que fait la Mono ? Suivre la norme… bien… mais on perd, encore une fois, toute compatibilité avec la référence, et donc le risque de perdre la très grande majorité des programmes ou développeurs qui se soucient peu de la compatibilité.
Et pourquoi est-ce que Mono suivrait ? Il y a une loi qui dit que Mono doit suivre comme un petit chien ?
PS : dans le monde du libre l’historique d’une société compte, si elle fait des coups bas les gens le retiennent.
Pas vraiment non, ils ont tendance a retenir ce qui leur plait et oublier le reste(je parles des fans, les devs ont plus d'experience et mettent de l'eau dans leur vin)
à propos des chevilles, c’est caractéristique de ton discours hautain, et ça a le mérite de mettre en évidence la culture d’entreprise qui doit régner : « on est les meilleurs ». Forcément quand ça reste entre vous c’est gratifiant de se faire mousser, par contre ici (alias linuxfr) ça passe très mal, et quand je dis ça je pense pouvoir parler au nom de pas mal d’entre nous. Tu réclames que certains d’entre nous se fassent plus consensuels sur leur discours contre Microsoft, mais j’espère que tu te rends compte que dans le genre tu en imposes…
Je vais pas le cacher, je trouves que sur certains aspects MS est loin devant les autres, il y a aussi des aspects ou on est derriere c'est evident, mais je vais pas me forcer a cacher les bons cotes pour faire plaisir aux gens ici, c'est pas vraiment ma nature.
[^] # Re: Aidons nos enfants
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à -3.
Les conneries genre MS n'a rien invente, MS veut faire des softs qui muselent ses utilisateurs, etc... c'est bon pour les fanboys linuxiens a qui ca fera plaisir, mais pour tout le reste de la planete qui a les yeux ouverts, ca te fait passer pour un extremiste decale de la realite.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Il y a la realite (il le fait tres bien, avec quelques problemes de temps en temps quand meme, il y a des bugs chez tout le monde), et le mythe repandu chez nos amis linuxiens qui ont tendance a ne pas comprendre comment un soft fonctionne et tout mettre sur le dos de MS(hint: le rendu depend de l'imprimante notamment)
Un document latex écrit avec emacs a toujours le même rendu, merci bien.
Elle est bonne celle-la...
Latex 2 est sorti en 1994, Latex 3 ? Toujours pas sorti...
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
Word 2010 t'ouvres toujours un fichier de Word d'il y a 15 ans avec une representation correcte si ce n'est parfaite.
Va essayer d'en faire de meme avec les autres softs du secteur, bon il est vrai que la majorite d'entre eux n'existaient meme pas il y a 15 ans...
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 4.
Si tu veux un truc similaire au community process de Java, il ya ECMA et ISO, qui valide les specs de C#, ou plusieurs societes et individus participent, ou je le rappelle n'importe qui peut participer hein.
Quand aux implementations de reference, le langage est une spec, personne ne code d'implementation de reference(= qui ferait foi), tout le monde code une implementation, et comme tout langage certaines implementations auront des bugs differents, peut-etre quelques unes seront 100% compliant, etc...
Parce que faut arreter de croire que C a une implementation de reference, il n'en a pas.
Quand au premier, oui merci les chevilles vont bien.
[^] # Re: EFF au secours !
Posté par pasBill pasGates . En réponse au journal De la déchéance des brevets. Évalué à 1.
On peut pas demander a une boite d'etre 100% sure qu'elle est bien celle qui a trouve cette idee la premiere, c'est le boulot de l'office des brevets, sinon il sert a rien cet office des brevets...
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Il y a bien evidemment de grosses differences en terme d'implementation (type de scheduling, structures internes, systeme de drivers, etc...) mais pas forcement plus qu'entre un Linux et un AIX ou HP-UX ou autre.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 4.
b) Ca fait quand meme pas mal d'annees que C# existe maintenant, et il n'y a pas eu de problemes
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
- C# 4 est sorti en Avril 2010, Mono l'a supporte en Septembre soit a peine 5 mois plus tard.
- Que Mono soit un sous-produit de .NET ou pas tout le monde s'en fout, la question est : est-ce qu'il est utile ou pas aux developpeurs, et la la reponse est clairement oui
- C# aussi est stable depuis des annees, et Mono clairement n'est pas en retard
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à -1.
Mais sinon, comme il a été dit plus tôt sur le ton de la rigolade, ca pourrait effectivement permettre aux OS de Microsoft de repartir sur des bases Unix éprouvées et donc de bénéficier de toutes les qualités de ces systèmes. Et accessoirement d'avoir la possibilité de se débarrasser d'une partie des reproches qui leur sont fait sur le coté passoire de Windows.
a) L'archicture Unix et Windows est deja quasiment la meme
b) Windows n'est en rien une passoire. Si on se fie aux chiffres en bugs, a ce que la communaute securite pense plutot que ce que pensens les fanboys linuxiens c'est clair et net
c) Je vois toujours pas un seul truc qu'un Unix (= grace a l'architecture Unix, donc tout Unix) peut faire qu'un Windows ne peut pas faire
[^] # Re: Droits sur unix
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Parce que des monopoles ici il y en a plein, notamment dans les telecoms, operateurs cable & internet, ...
Quand aux abus, MS a ete condamne pour certains abus, et a perdu d'autres proces contre d'autres societes, ce qui montre qu'ils ne controlent pas la justice quoi que tu en dises.
[^] # Re: Droits sur unix
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 5.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.