Très peu de détails sont connus pour le moment, mais de très nombreuses questions émergent petit à petit et il semble de plus en plus probable que cette annonce soit un des pires scénarios catastrophes que l'on puisse imaginer.
Voici une liste non exhaustive des questions que l'on peut se poser :
- "Qui récupère la propriété de Unix ?". En effet, comme cela a été démontré lors du procès SCO, cette dernière appartient à Novell ;
- Quels sont les brevets récupérés par le consortium dirigé par Microsoft ? Sont-ils utilisés dans le noyau Linux (les mauvaises langues diront que si oui Microsoft Corp aurait enfin ses centaines de violations de brevets...) ? ;
- Quel est l'impact sur OIN ? Ne connaissant pas le fonctionnement de cette organisation est-ce que la participation consistait juste en une promesse très généraliste ou dans une liste de brevets bien définis ?
- Que vont devenir les développeurs de Linux et de logiciels libres dans la nouvelle entreprise ? Rappelons que le numéro 2 du noyau, Greg Kroah Hartman, est employé par Novell. Un fonds d'investissement n'ayant pour unique raison d'être que de faire de l'argent, il est assez peu probable qu'une politique à long terme soit menée.
Naturellement les scénarios les plus pessimistes font aussi leur apparition comme on peut le lire sur [ITwire]. Une analyse plus poussée mais en anglais peut être lue sur le site Groklaw.
Il est probablement aussi important de signaler que pour le moment le rachat n'a été que soumis à la SEC et qu'il y a déjà deux groupes d'actionnaires qui entament une procédure contre cette vente (voir la fin de l'article sur le site Groklaw). Un journal succinct avait parlé de cela mais vu l'importance de Novell dans le monde de Linux et plus généralement du logiciel libre, le sujet méritait une dépêche.
Aller plus loin
- Annonce de Novell (11 clics)
- OIN (4 clics)
- ITwire (2 clics)
- Journal LinuxFr.org (9 clics)
- Groklaw (3 clics)
# google est ton ami
Posté par TImaniac (site web personnel) . Évalué à 5.
Y'a une liste bien définie :
http://www.openinventionnetwork.com/pat_owned.php
# Les droits sur Unix ne font pas partie du lot racheté à Novell par M$
Posté par Yarma22 . Évalué à 4.
[^] # Re: Les droits sur Unix ne font pas partie du lot racheté à Novell par
Posté par benoar . Évalué à 4.
C'est court, mais bon…
[^] # Re: Les droits sur Unix ne font pas partie du lot racheté à Novell par
Posté par Albert_ . Évalué à 4.
[^] # Re: Les droits sur Unix ne font pas partie du lot racheté à Novell par
Posté par Albert_ . Évalué à 0.
Dommage aussi que tu ne saches pas clicquer sur les liens en bas de la news qui sont les sources que j'ai utilise.
En ce qui concerne la source des questions desole si tu n'aimes pas le fait que je n'ai pas fait un plagiat d'un article quelconque sur le net.
[^] # Re: Les droits sur Unix ne font pas partie du lot racheté à Novell par
Posté par boq . Évalué à 5.
C'est la neige qui te stresse a ce point? Détend-toi, relis ce qu'il a écrit. Il n'y a pas d'ambiguïté qu'il parle de l'auteur de la news de clubic.
[^] # Re: Les droits sur Unix ne font pas partie du lot racheté à Novell par
Posté par Albert_ . Évalué à 3.
s'il vous plait moinsser le message au dessus. Cacher donc ceci :)
[^] # Re: Les droits sur Unix ne font pas partie du lot racheté à Novell par
Posté par antistress (site web personnel) . Évalué à 4.
# Contribution au noyau Linux
Posté par Thomas J. (site web personnel) . Évalué à 10.
Ah... on me dit que non...
# Bonne nouvelle
Posté par j_kerviel . Évalué à 10.
Novell, en fait de caméléon vert était plutôt un mouton noir dans le libre.
Entre les accords fudesques avec MS pour faire croire que MS peut attaquer tout le monde sauf Novell, le chevalier blanc qui met en sécurité les utilisateurs de leur distribution et mono qui crée une autre insécurité juridique, Novell était plus l'ami qui vous dispense de la nécessité d'avoir des ennemis.
Alors certes, c'est triste pour reg Kroah Hartman, qui est certainement la partie émergée de l'iceberg. Je pense qu'il ne sera pas difficile pour le numéro deux du noyau pour trouver un autre financement pour continuer ses activités. Les boites (google ? Red Hat ? Oracle ? ...) ne manquent pas. Ou peut être que la Linux Foudation pourrait l'embaucher, comme elle l'a fait pour Linus Torvalds suite à la baisse de forme de transmetta ? Encore ce serait un mainteneur d'un sous-sytème obscur ou un contributeur de base, je ne dis pas. Mais là, j'ai peu de craintes pour lui.
Je me fais plus de soucis pour tout ce qu'on ne voit pas. Mais au bout du compte, même si ça risque de pénaliser certains projets on risque de se retrouver avec une situation plus claire et plus saine et ce n'est pas une mauvaise chose.
Si Novell pouvait mourir, je n'en serais pas malheureux. Surtout si ça emporte mono et Suse dans la tombe au passage.
[^] # Re: Bonne nouvelle
Posté par patrick_g (site web personnel) . Évalué à 8.
Le numéro deux du noyau c'est plutôt Andrew Morton que Greg Kroah Hartman.
Sinon sur le fond tu as raison, je ne me fait aucun souci pour lui si il décide de changer d'employeur.
[^] # Re: Bonne nouvelle
Posté par j_kerviel . Évalué à 3.
Le numéro deux du noyau c'est plutôt Andrew Morton que Greg Kroah Hartman.C'est ce que j'ai pensé en lisant la dépêche.« Tiens, ça a changé ? ».
Ca me semblait bizarre, mais vu que la dépêche a été rédigé par quelqu'un qui s'y connais (je suppose) et relue par une demie-douzaine de relectmodos, je me suis dit que ça devait être une information fiable.
Mais bon, indépendamment du numéro, non seulement il a un rôle important, mais en plus il est extrêmement médiatisé (relativement à un développeur Linux s'entend).
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 4.
Moi m'y connaitre? Non je suis un vulgaire trolleur :)
Et oui j'ai tout a fait pu me tromper sur le sujet. De tout de facon GKH qu'il soit numero 2, 3 ou 4 c'est un detail, le plus important c'est que ce soit un contributeur majeur du kernel et il me semble celui qui fait les backports du kernel de dev vers ceux utilise par les distribs.
[^] # Re: Bonne nouvelle
Posté par Raoul Volfoni (site web personnel) . Évalué à 4.
Hé ho, Yast a été libéré non ? Là on tombe vraiment dans l'ultralibéralisme Mr Kerviel...
[^] # Re: Bonne nouvelle
Posté par j_kerviel . Évalué à 6.
Hé ho, Yast a été libéré non ?Je ne vois pas le rapport.J'ai toujours considéré que faire de la pub à Suse, c'était implicitement soutenir Novell. Moins il y a d'utilisateurs de Suse (communautaire ou pas), moins il y a de contributions, moins la distribution peut se différencier des autres, moins Novell a de l'influence, moins Novell peut être néfaste au logiciel libre.
Là on tombe vraiment dans l'ultralibéralisme Mr Kerviel...J'ai bien peur de ne pas comprendre la relation de cause à effet entre ma phrase et le libéralisme. Est ce qu'il serait possible d'avoir plus de précisions, M. letoff ?[^] # Re: Bonne nouvelle
Posté par djano . Évalué à 1.
J'ai bien peur de ne pas comprendre la relation de cause à effet entre ma phrase et le libéralisme. Est ce qu'il serait possible d'avoir plus de précisions, M. letoff ?
Regarde plus attentivement ton pseudo j_kerviel, tu y verras peut-être une relation de cause a effet.
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 3.
[^] # Re: Bonne nouvelle
Posté par daimrod . Évalué à 3.
Puis c'est aussi la mort de nombreux trolls.
Enfin pour mono, j'ai des doutes sur sa chute, surtout maintenant que F# a été libéré.
[^] # Re: Bonne nouvelle
Posté par Florian.J . Évalué à 9.
Personnellement après des débuts difficiles sur Mandrake 9.1, c'est Suse 9.1 qui a fait de moi un Linuxien peu de temps après, c'était vraiment une excellente distribution.
(ça a été un peu plus difficile par contre avec le passage au x86_64).
Et pas extension je suis devenu plus tard libriste.
Même si à l'époque Yast n'était pas libre (ça a changé depuis), le système fournissait principalement des logiciels libres.
Donc je pense qu'il fait pas être sectaire, je sais pas trop ou ça en est maintenant (j'ai connu entre temps Debian et Archlinux), mais il y a toutes les chances pour qu'OpenSuse soit un très bon SE et qu'il pousse des gens à decouvrir Linux et le libre.
Concernant Mono c'est un peu plus délicat.
D'un côté c'est un langage et une plateforme venant de Microsoft donc forcément au début on est un peu réticent.
Mais il se trouve que pour le boulot j'ai dû me mettre au C# (au passage c'est vraiment de la riguolade quand on a des bases de C++) et je dois dire que c'est assez bien penser.
De plus le fait qu'il y ait quelqu'un pour se dévouer à développer Mono on y gagne beaucoup en intéropérabilité.
Je rappelle que Mono est libre, faut pas dénigrer le truc uniquement par ce que c'est une implémentation de .NET qui vient de Microsoft.
Dans ce cas on pourrait dire également que le mec qui s'occupe de maintenir gcc sur Windows est un traître, qu'il vole le boulot de GNU pour le mettre à disposition d'utilisateurs d'une plateforme propriétaire. Et que dire de MinGW ou Cygwin !!!
Et il sont bien entendu indispensables, à commencer pour moi. (programmer sur Windows avec kate/kwrite avec gcc dans une console bash, tout ça grace à MinGW, moi je dis merci, sinon ça serait avec Visual Studio).
Ben Mono c'est pareil, ça peut déranger pour les sectaires, mais heuresement qu'il existe, sinon il faudrait se contenter de l'implémentation de Microsoft, avec les outils qui vont avec !
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
Même libre, il reste le problème de ces ****** de brevets. Tant qu'on aura pas brûlé le dernier consultant en propriété intellectuelle avec les derniers brevets, on n'aura pas la paix.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par zebra3 . Évalué à 1.
Seule la couche de compatibilité Microsoft peut poser des problèmes, mais pour développer des applications purement Linux, il n'y a aucun risque. Cette couche n'est d'ailleurs pas nécessairement installée.
Pour tout le reste, Mono implémente soit des technologies standardisées par l'ECMA et dont l'implémentation est libre, soit des technologies propres qui ne violent aucun brevet (GTK#, Gstreamer, etc).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 6.
Au passage la promesse ne concerne qu'une seule implementation de .Net, celle normalise a l'ECMA il y a bien longtemps, et uniquement si elle est complete.
Donc dire que mono est sans risque c'est etre un "bisounours".
Je vous laisse trouver les liens vous memes cela n'est pas difficile.
[^] # Re: Bonne nouvelle
Posté par zebra3 . Évalué à 4.
* libmono-microsoft-visualbasic8.0-cil - Visual Basic 2005 runtime libraries for Mono
* libmono-microsoft-build2.0-cil - Mono Microsoft.Build libraries
* libmono-microsoft7.0-cil - Mono Microsoft libraries (for CLI 1.0)
* libmono-microsoft8.0-cil - Mono Microsoft libraries (for CLI 2.0)
Donc si, c'est bien séparé.
Et quand on voit l'histoire de FAT32, le noyau lui-même n'est pas à l'abri de ce genre de troll, et Mono ne pose pas plus de risque.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 7.
http://nocturn.vsbnet.be/content/get-facts-mono
* Mono implements a lot more than the ECMA parts, De Icaza’s promise to seperate mono into safe and non-safe parts was never fulfilled
http://www.the-source.com/2010/11/mono-criticism-uninformed-(...)
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 1.
Mais il est particulièrement malhonnête de ne pas mentionner également que :
- Jusqu'à preuve du contraire, on ne parle d'aucune infraction concrête mais uniquement de "possibles" litiges sans que l'on sache vraiment de quel code on parle ni de quel brevet.
- Utiliser Linux, c'est risquer d'enfreindre un brevet logiciel.
- Utiliser [cequevousvoulez], c'est risquer d'enfreindre un brevet logiciel.
- Debian semble penser qu'il est plus avantageux de proposer Mono à leurs utilisateur que de céder au troll des brevets.
- Fedora semble penser qu'il est plus avantageux de proposer Mono à leurs utilisateur que de céder au troll des brevets.
- Ubuntu semble penser qu'il est plus avantageux de proposer Mono à leurs utilisateur que de céder au troll des brevets.
Le plus drôle dans l'histoire, c'est que tu trouveras toujours un anti-MS/anti-DeIcaza pour diffuser le troll de Microsoft & co. Ironique non ?
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 5.
Linux ca fait deux ans que les VRP Microsoft pretendent cela mais bon meme Linus dit que c'etait des conneries.
Tu as oublie un petit detail dans ta liste:
Mono est une des applications les plus desinstalle apres l'installation du systeme d'ou le retour en arriere sur f-spot par exemple. Enfin on sait que tu ADORES ce truc moi ce que je vois c'est que cela devait arriver partout et en fait cela disparait de partout, qui parle encore de beagle par exemple, le bureau gnome devait utiliser silverlight mais bon comme il se doit moonlight la version linux n'a jamais reussi a rattraper son retard, maintenant vu que silverlight est en train d'etre abandonne par Microsoft c'est possible qu'ils y arrivent voir carrement qu'ils se retrouvent en charge du code comme pour ironpython, ironruby et F#.
[^] # Re: Bonne nouvelle
Posté par zebra3 . Évalué à 4.
Quand je vois des brevets aussi cons que ceux sur FAT32, je me dis qu'on est à l'abri de rien. Je ne m'oserai pas à prétendre que Linux ne viole aucun brevet.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 1.
Vas-y, prouve-le : donne nous un lien vers un brevet et le code de Mono associé qui utiliserait le dit brevet.
On va voir si tu te fou simplement de la gueule du monde ou si t'es un minimum honnête.
PS : je te tire mon chapeau à l'avance, tu viens de faire passer les juristes de RedHat et Novell pour des guignoles simultanément.
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 2.
Ah oui tiens c'est amusant va donc voir pourquoi Moonlight n'est pas inclu dans Fedora et apres on reparle.
Pour le reste si il y a des discussions sur separation du code dangereux et celui moins dangereux c'est jsute pour perdre du temps non? Prouve moi par un lien provenant de Microsoft que aucun brevet n'est viole par aucune version de Mono et des softs associe. Je te souhaite bon courage et je decline l'invitation a comparerer les 42 millions de brevets microsoft avec la norme ECMA, la version .Net actuelle (2 ou 3 v ersions depuis non? et cela m'etonnerait bien que Microsoft n'ait depose aucun brevet sur les nouveautes introduite) et Mono.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
Moonlight reste un projet à part dans Mono, ça serait bon de ne pas généraliser.
Prouve moi par un lien provenant de Microsoft que aucun brevet n'est viole par aucune version de Mono et des softs associe.
Tu sais très bien que c'est impossible à prouver gros malin. Et tu sais très bien que j'ai jamais dit que Mono ne violait aucun brevet : j'ai dit que Mono avait un risque, comme tous les autres logiciels libres.
Mais en tout cas tu confirmes mon intuition : tu te fou bien de la gueule du monde. Tu affirmes quelque chose (Mono utilise forcement des brevets MS) sans aucune preuve. Ton argumentation est detestable et totalement irrespectueuses des développeurs et utilisateurs de ce logiciel libre.
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 0.
http://linuxfr.org/~HAROBED/15586.html
si tu fais l'effort de lire et non pas de forcement vouloir utiliser la tactique microsoft de denigrement des interlocuteurs, tu verras qu'il est bien question de BREVET MICROSOFT dans mono.
Je vais pas me fatiguer a repondre plus a tes attaques et a rentrer dans les tactiques lobbyste/microsoftienne de on tourne autour du pot pour tenter de noyer le poisson et faire croire que le plafond est en bas et le plancher en haut. Amuses toi bien.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
J'ai lu, et ?
La politique de Mono est clair : si y'a un brevet qui peut géner, on l'utiliser pas en trouvant un algo alternatif. Si c'est pas possible, on supprime le code en question.
Je réitère donc ma demande : montre moi un brevet et un morceau de code de Mono qui violerait le dit brevet.
Je vais pas me fatiguer a repondre plus a tes attaques
Ou comment avouer que tu n'as strictement aucune preuve de ce que tu prétends. Mais t'as raison, arrête de répondre, c'est tellement ridicule.
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 2.
Ok, ca resoud le pb legal (enfin ca montre une bonne volonte tout du moins), par contre si le code en question est supprime, elles font quoi les applis qui en dependent?
Note que je suis plutot du cote des "la probabilite d'un proces est tres faible, pas plus eleve qu'avec le kernel en tout cas", mais ca a tendance a me faire peur ce genre d'approche, disons qu'avec le brevet, tu peux payer si t'en as les moyens. La meme si t'as les moyen, tu te retrouves gros jean comme devant.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 5.
Oué bah oué, c'est la base même de l'épée de Damoclès des brevets logiciels. Mais Mono est plus concerné qu'un autre, quoiqu'en dise certains.
Donc il faut combattre les brevets logiciels dans leur ensemble et arrêter de taper gratuitement sur un logiciel plus qu'un autre.
[^] # Re: Bonne nouvelle
Posté par Spyhawk . Évalué à -1.
[^] # Re: Bonne nouvelle
Posté par zebra3 . Évalué à 2.
Et la présomption d'innocence ? Mono n'a rien transgressé, jusqu'à preuve du contraire.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
[^] # Re: Bonne nouvelle
Posté par zebra3 . Évalué à 3.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Bonne nouvelle
Posté par Mathieu Segaud . Évalué à -3.
pour preuve: ironique ou pas, écrire "Tant qu'on aura pas brûlé le dernier consultant en propriété intellectuelle" c'est s'exposer à se faire traiter d'à peu près tout ce qu'il est possible d'imaginer.
et ce, même un vendredi.
[^] # Re: Bonne nouvelle
Posté par Tonton Th (Mastodon) . Évalué à 5.
Euh...
http://en.wikipedia.org/wiki/Mono_%28software%29#Mono_and_Mi(...)
[^] # Re: Bonne nouvelle
Posté par zebra3 . Évalué à 1.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Bonne nouvelle
Posté par Tonton Th (Mastodon) . Évalué à 4.
Mais alors, où est l'intérèt de MONO si on ne peut plus faire du multi-plateforme ?
[^] # Re: Bonne nouvelle
Posté par yellowiscool . Évalué à 3.
Envoyé depuis mon lapin.
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 2.
[^] # Re: Bonne nouvelle
Posté par yellowiscool . Évalué à 2.
Mais il faut quand même constater qu'il en est de même avec Java, et que finalement c'est pareil pour la plupart des autres langages. Python, ruby, et compagnie ne sont pas conçus par des consortiums à ce que je sache (mais je peux me tromper).
Toujours est-t'il que je trouve en tant que modeste développeur encore débutant dans ces langages (je ne les ai jamais utilisés en milieu professionnel contrairement au python et au C++), je trouve le C# de très bonne facture, et avec de bonnes idées.
Envoyé depuis mon lapin.
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 5.
http://www.python.org/psf/
je trouve le C# de très bonne facture, et avec de bonnes idées.
Peut etre mais bon ce n'est pas une raison pour faire entrer le loup dans la bergerie.
[^] # Re: Bonne nouvelle
Posté par Antoine . Évalué à 3.
Même pas, c'est juste une communauté de développeurs.
La PSF sert à financer PyCon et d'autres trucs (ainsi qu'à protéger la « propriété intellectuelle » (sic)), mais elle n'a aucune voix au développement.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à -3.
Mais quelle connerie...
Quel loup ? C'est un LANGAGE. Il va se passer quoi plus tard ? Le code va se transformer tout seul et effacer ton OS ? Il va subitement emprisonner tes donnees ?
Le langage est propre niveau brevets, ainsi que la couche standardisee, utiliser celles-ci ne comporte AUCUN risque, point a la ligne.
Utiliser d'autres librairies, ca encourt le meme risque qu'utiliser d'autres librairies dans un autre langage.
[^] # Re: Bonne nouvelle
Posté par Benoît Donnette . Évalué à 2.
Pour rappel, le langage C# a bénéficié d'une mise en œuvre libre avant le langage Java... Second rappel, les brevets logiciels purs ne sont pas applicables en Europe, merci Michel Rocard. C'est gentil de se préoccuper des USA mais je vous promets qu'ils savent le faire tous seuls :)
Retour à l'humeur : Que penser du rachat de Novell ? Quelques mois après les déboires de Mandriva, on peut juste se dire que le ciel n'est pas dégagé au-dessus des distributions Linux industrielles, et qu'à ce niveau-là on peut commencer à se poser des questions quand à leur pluralité dans un avenir pas si éloigné...
Je pense que Linux ne sera pas mieux vu s'il est représenté par 1 seul éditeur, fût-il RedHat ou Canonical. L'esprit du libre (et ses financements) n'en sortiront pas grandis.
[^] # Re: Bonne nouvelle
Posté par houra . Évalué à 2.
Canonical fait très fort, si Suze ( sic ) correspond réellement à une attente non comblée par RedHat, elle sera remplacée ( je propose Ambassadeur pour rester dans la même veine ) .
Mais moi, ce que j'aimerai voir débouler, c'est des gens qui ont envie de bousculer des montagnes, de proposer du GGI+KGI ou autre DirectFB à la Android, ou du Wayland sur des fenêtres virtuelles au dessus d'un plan de travail qui couvrirait tout l'écran, sur un noyau interdisant le freeze système, et de proposer aussi d'autres architectures . Pas de refaire 1000 fois la même gestion de pacquage compatible dans l'esprit avec ce qui a été l'origine: l'arbre des ports FreeBSD .
Bon ceci dit, si vous connaissez de bonnes adresses en la matière, j'aimerai tester. :)
Ce qui pourrait " pousser " aussi des distributions, c'est d'y intégrer un gros projet type GRC, CAD ou/et compta.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Bonne nouvelle
Posté par Tonton Th (Mastodon) . Évalué à 2.
Voilà, c'est aussi mon avis. Parce qu'après on va se retrouver avec un Gimp en interface MDI. Et
peut être bien pire...
[^] # Re: Bonne nouvelle
Posté par dufour olivier . Évalué à 2.
Les appli linux peuvent être développé en utilisant uniquement la partie sans patent.
ADO.NET ==> couche donnée par utilisé
ASP.NET ==> couche graphique web ==> pas utilisé sur les applis linux qui utilise GTK#
windows.forms ==> couche graphique windows ==> pas utilisé sur les applis linux qui utilise GTK#
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 1.
Cela doit pas etre tres courrant voir quasiment marginal et ils est certains qu'aucune grosse applis .Net ne fonctionne de cette facon la.
En tout cas pour en citer deux: Paint.Net ca marche pas et Silverlight ca marche pas.
Donc ca c'est de la com mais la realite est tout autre. Par contre c'est amusant mais une applis python voir C++ avec Qt c'est quasi sans probleme le passage sur une autre plateforme (si cela a ete code correctement et sans se servir des trucs specifics a l'OS naturellement). De meme pour java ou le nombre d'applis multiplateforme qui tournent sans probleme est legion.
[^] # Re: Bonne nouvelle
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 2.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à 4.
http://www.medsphere.com/solutions/system-architecture
http://www.sourcegear.com/vault/index.html
etc...
De rien
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 3.
Ben pour .Net, c’est exactement pareil.
Fait un truc en Gtk#, il tournera sous Linux et Windows sans modification
Fait un truc avec les MFC en Python, tu le feras pas tourner sous Linux sans modification
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 2.
Autant se servir de framework dont la communite dirigent le devenir et non pas cours derriere l'implementation de ref.
Python, Qt sont de bons exemple de framework totalement controle par la communite opensource de facon ouverte. Un peu comme ODF, la norme et le travail dessus se fait au vu de tout le monde sans que personne soit avantage par rapport au voisin.
[^] # Re: Bonne nouvelle
Posté par zebra3 . Évalué à 2.
Il y a des développeurs dont le langage de référence est C#, on ne va pas les forcer à choisir un autre langage, si ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 3.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 4.
Je te conseille donc de faire une campagne de boycott de GCC, Linux, OpenOffice, Gnome, KDE, Apache, etc.
Heureusement, il te reste un système d’exploitation complet avec une pléthore d’applications que le libre contrôle entièrement, Emacs. Il te faudra juste une Lisp machine.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à -3.
Vu l'importance de GCC, c'est tout comme.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 6.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 3.
Ça ne veut pas dire que cette influence est notable.
Je rappelle que la question n’est pas « qui a la plus grosse » (influence), mais : est-il acceptable pour le libre d’utiliser des technos sur lesquelles il n’a aucune influence notable ?
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Je ne pense pas que le comité qui s'occupe du C++ puisse s'assoir facilement sur GCC alors que Microsoft peut à tout moment sortir une .NET complètement fermée et faire un gros doigt à Mono.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 3.
Ben non. Albert_ a dit : on peut pas utiliser C#, parce que le libre le contrôle pas.
Implication fausse, puisque le libre ne contrôle pas non plus C/C++, mais que ça ne semble pas déranger Albert_.
Point.
Arguer pendant des heures sur oui mais le libre contrôle 0.000001% de l’évolution de C++ mais 0% de Mono, excuse moi, mais c’est de l’entubage de drosophiles. Le résultat est le même : si demain Iguaza veut mettre Gtk# dans le standard .Net, il peut pas. Si demain Stallman veut mettre un interpréteur Lisp dans la lib standard du C, ben il peut pas. 0—0, fin de match, rentrez chez vous, ya rien à voir.
> Microsoft peut à tout moment sortir une .NET complètement fermée et faire un gros doigt à Mono.
Version qui devra toujours être compatible avec les versions précédentes.
La vache de gros doigt, j’ai trop peur.
Le fait est là : l’existant .Net/Mono d’aujourd’hui, il est pas fermé, il est pas près de disparaître, et il est suffisamment différent de ce qui existe ailleurs pour intéresser des projets.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
- c'est Microsoft qui définit l'avenir de .NET et Mono restera éternellement un sous produit à moins d'abandonner la compatibilité et de suivra sa propre voie.
- le C++ est stable depuis des années et GCC est à l'avant garde pour ses évolutions (support de C++1x, Concept GCC...).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 devnewton 🍺 (site web personnel) . Évalué à 2.
http://www.mono-project.com/Guidelines:Application_Portabili(...)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 4.
On parle d'une des boites les plus riches du monde, avec le plus d'employe dans le developpement de logiciel et ils ont pas reussi a trouver 2 ou 3 personnes pour faire le port eux meme de quoique ce soit? Et apres il existe des bisounours qui veulent croire que cette boite joue "fair-play"?
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 3.
Un des objectifs de la plateforme .Net (CLR & co) est d’être portable, et en pratique, ça marche.
Par contre, les APIs Microsoft de .Net (Windows Forms) n’ont jamais prétendu avoir cet objectif.
De plus, tu t’obstines à voir Mono comme « un effort de Microsoft pour se rapprocher du LL » (et vice-versa) avec des objectifs stratégiques des deux côtés alors qu’on se tue à te dire qu’on peut aussi tout simplement voir Mono comme une plate-forme de développement comme une autre, avec ses atouts (facile à déployer sous Windows & Linux, pas mal de langages différents, C# assez agréable à utiliser relativement au C++ ou à Java) et ses inconvénients (chiant à déployer sous MacOS X, pas d’API GUI standardisée, pas encore installé de base dans toutes les distributions).
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
T'es toujours aussi stupide dans tes affirmations. Après le coup des brevets-que-c-sur-que-mono-violent-mais-que-je-peux-pas-pointer, voici les logiciels qui n'existent pas, strictement, en particulier avec Mono.
C'est tellement comique que Mono diffuse pourtant des logiciels Microsoft, sûrement une preuve qu'ils ne marchent sûrement pas avec Mono :
- ASP.NET MVC
- DLR
- Managed Extensibility Framework (MEF)
- System.Data.Services.Client
D'autres tournent sans problème avec Mono :
- Le compilateur F#
- Le compilateur IronPython
- Le compilateur IronRuby
Voir sont packagés spécifiquement pour Mono :
- Les codecs Windows Media pour Moonlight
Après oui, ce sont essentiellement des logiciels à destination des développeurs et non des produits "grand public", mais c'est assez logique : ces briques n'ont pas de pertinence à être fortement liées à Windows.
D'autres softs sont fournis par MS pour Linux, sans rapport avec Mono :
- Linux Integration Services v2.1 for Windows Server 2008 Hyper-V R2
Et apres il existe des bisounours qui veulent croire que cette boite joue "fair-play"?
Si tu savais le nombre d'entreprise qui ne portent pas leurs logiciels grand public sous Linux, avec leurs 1% de parts de marché sur le desktop, c'est tellement étonnant... MS n'a rien contre les autres OS quand y'a un marché, regarde Mac OS X...
[^] # Re: Bonne nouvelle
Posté par cdeblesson . Évalué à 0.
Ben voyons...
.Net vise le desktop ? Linux a 1% de part de marché sur les serveurs ?
Il est impossible d'utiliser un produit MS sans passer à la caisse, même les applications distribuées gratuitement ont besoin au minimum d'un windows pour fonctionner.
Une version *nix de .Net permettrait de gérer tout le cycle de vie d'un logiciel sans utiliser un seul de leur produit.
Les éditeurs l'utiliserait de plus en plus, en une décennie il n'y aurait plus aucun intérêt à payer des licences windows, les softs windows only se compteraient sur les doigts de la main, les éditeurs de bloatware installés sur les PCs neufs permettraient aux constructeurs de continuer à se faire payer les installations en économisant les licences windows, fin de la dépendance, fin de leur monopole, que le meilleur gagne.
Trop cher payé pour tuer java...
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 3.
Je crois que tu n’as pas compris mon argument.
Aujourd’hui, pour le choix d’une technologie, tu t’intéresses à l’existant hic et nunc. Tu te fous de savoir si les fonctionnalités de la version dans deux ans seront implémentées dans ton implémentation. Ce qui t’intéresse, ce sont les fonctionnalités d’aujourd’hui. Hors, le fait est :
- l’implémentation de Microsoft dans deux ans pourra toujours lancer les applications d’aujourd’hui, parce que c’est dans l’intérêt de Microsoft (je rappelle que Windows 7 est toujours capable de faire tourner les applications Windows 3.11 voire MS-DOS 6). C’est en ce sens que je dis : on se fout de qui contrôle le futur du langage. Donc, si tu ne prends que les fonctionnalités d’aujourd’hui, Mono/.Net est une solution de développement multiplateforme totalement acceptable.
- l’implémentation d’aujourd’hui est aujourd’hui techniquement assez différente de la concurrence, même « totalement libre » (selon le sens assez… particulier des contempteurs de Mono), pour que ces différences techniques surpassent largement les questions d’ordre « politique ».
[^] # Re: Bonne nouvelle
Posté par nicolas . Évalué à 4.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 nicolas . Évalué à -1.
Car je suis désolé, mais sur tes deux arguments c’est rien comparé au C, et au passage ton premier devient faux, ça va les chevilles ? Car on parle de langage, pas d’OS, et ça en devient un mensonge étant donné les ténors du secteur.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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: Bonne nouvelle
Posté par nicolas . Évalué à 3.
Quand je parle de garantie je parle bien sûr des processus qui mène à la standardisation du langage. 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 !
Je résume ici très grossièrement ce que j’ai compris des lectures Wikipediennes, en comparant avec le C, qui fait l’unanimité, je pense, comme langage de référence. Le C a été développé par 3 gus, des implémentations ont fusé partout toutes plus incompatibles les unes que les autres, quand je parlais d’implémentation de référence je parlais de ça : c’est bien beau d’avoir un langage bien défini, mais si chaque implémentation part dans son sens et devient incompatible avec les autres les spécifications du langage deviennent caduques. 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. L’ISO décide de créer un comité pour mettre au propre une norme, note bien que l’acteur ici est l’ISO. Je n’ai malheureusement pas retrouver qui a participé au comité, ni qui participe à l’heure actuelle aux évolutions (je pense au C99 et au C en préparation). Le C subit une évolution majeure tous les 10 ans, il existe depuis 30 ans. En C il n’existe pas d’implémentation de référence, mais il est populaire et un bon nombre de compilateurs existent sur le marché, ce qui garantit une certaine indépendance vis à vis des spécifications propres et vis à vis d’un compilateur qui commencerait à faire n’importe quoi avec le langage.
À côté de ça tu as le C♯, la version normalisée est la 2.0, Microsoft utilise la 4.0. Je ne sais pas à quel point les deux versions diffèrent mais ça ne présage rien de bon. Le langage est très lié au framework .NET (développé en parallèle, annoncé en même temps), technologie exclusivement Microsoft. Le langage normalisé ISO a 7 ans. Je serai vicieux je te rappellerai un commentaire assez récent que j’ai fait à propos d’ACPI, à ce moment j’avais trouvé comme exemple les documents bureautiques. 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. 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. D’un autre côté j’entends bien que cracher sur Mono pour cette raison c’est aussi participer à diffuser ce FUD. 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. Il existe donc une seule implémentation, qui sera a fortiori une implémentation de référence : celle de Microsoft. 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é. La position d’Albert, que je comprends parfaitement, est de ne pas prendre, en quelque sorte, de risque en faisant un pari inconsidéré, surtout avec l’historique qu’a l’entreprise, alors qu’il existe de très bonnes solutions libres pour le développement. Cela fait partie d’une stratégie sur le long terme, on dit souvent que le libre manque de direction claire… Mais au final ce seront les utilisateurs qui décideront, souvent pour des raisons bien plus pragmatiques : lancer une machine virtuelle au démarrage de Gnome, c’est lourd, dans tous les sens du terme.
PS : dans le monde du libre l’historique d’une société compte, si elle fait des coups bas les gens le retiennent.
PPS : à 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…
Et désolé pour les fautes, après un commentaire aussi long je n’ai pas envie de me relire…
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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: Bonne nouvelle
Posté par nicolas . Évalué à 4.
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. Je soupçonne que tu mélanges avec la portabilité des données, binaires, produites et enregistrées sur disque, ce qui n’a rien à voir avec la portabilité du code. Mais ce problème explose au développeur inattentif très précisément parce que le code C a abstrait cette représentation.
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.
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.
Bien sûr qu’il y a un FUD à propos des brevets, demande à Albert, à propos de Linux, à propos de l’attaque contre Tomtom sur le Fat32, tout ceci y participe, utiliser des technologies de chez Microsoft est susceptible de l’alimenter. Pas sur le langage en lui-même : mais ça je l’ai dit, tu n’as juste pas lu, la partie standardisée ou couverte par des accords unilatéraux (ie. Microsoft envers quiconque, quiconque étant égal à all et différent des non-profit ou autre OSS) n’a pas à craindre de brevets. 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 il y en a au moins 2 vu que Mono implemente C# 4 en toute legalite. » 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.
Enfin je n’ai jamais dit que Mono devrait suivre à fortiori le standard « comme un petit chien ». 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.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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: Bonne nouvelle
Posté par nicolas . Évalué à 4.
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.
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.
Il reste la question de différencier de ce qui est couvert ou pas, si c’est clair pour toi, tant mieux. 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.
ACPI était un exemple pour mon autre argument : on a d’une part le problème du FUD sur les brevets, d’autre part le problème de la main-mise sur le langage, que ce soit au niveau institutionnel (standard, qui sont plus une solution qu’un problème pour apporter quelques garanties), ou que ce soit au niveau pratique. Et 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.
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.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 TImaniac (site web personnel) . Évalué à 1.
Ca c'est la théorie. Pourtant, moi aussi je vais citer Wikipedia, à la rubrique inconvénients :
"il est difficile d'écrire des programmes portables car le comportement exact des exécutables dépend de l'ordinateur cible ;"
Ca c'est la vraie vie.
Un langage qui laisse le choix à l'implémentation de la taille d'un "int", c'est clairement une lacune qui fait qu'un code, bien que respectant la norme ANSI C, ne sera pas portable. Et c'est ce qui se passe en pratique : suivant l'architecture cible, la taille d'un int diffère.
Cet exemple suffit à montrer, que bien qu'étant "relativement" portable, la norme ANSI C est loin d'être la panacée niveau portabilité.
Si je reprends toujours ta même source, Wikipedia, il y a même une rubrique dédiée aux trucs mal définis qui font qu'un code écrit en ANSI C n'est pas forcement portable, le résultat dépendant des choix d'implémentation :
http://fr.wikipedia.org/wiki/C_(langage)#Comportements_mal_d(...)
Bref, ne pas confondre la théorie, les objectifs affichés, les blablas de chercheurs et la vraie vie.
[^] # Re: Bonne nouvelle
Posté par nicolas . Évalué à 3.
Je crois qu’il y a un problème de définition : coder en ANSI veut dire respecter la norme et ne pas faire de suppositions sur les comportements indéfinis de la norme.
Taille des int ⇒ tout un tas de constante à chercher dans un include (dont j’ai oublié le nom), dans le cas où on sait que ce sera problématique.
/ d’entiers négatifs ⇒ Répètes après moi : « La division d’entiers en C est une division euclidienne. » Un fois que tu as compris ça tu n’as plus jamais de problème avec les divisions d’entiers, quelque soit le langage. C’est tout simplement magique…¹
Taille des pointeurs ⇒ sizeof est ton ami.
Va donc sur l’article anglais, la phrase est assez éloquente :
« The reason some behavior has been left undefined is to allow compilers for a wide variety of instruction set architectures to generate more efficient executable code for well-defined behavior, which was deemed important for C's primary role as a systems implementation language; thus C makes it the programmer's responsibility to avoid undefined behavior, possibly using tools to find parts of a program whose behavior is undefined. Examples of undefined behavior are:
* accessing outside the bounds of an array
* overflowing a signed integer
* reaching the end of a non-void function without finding a return statement, when the return value is used
* reading the value of a variable before initializing it »
Les comportement indéfinis sont précisément là pour laisser champ libre à l’implémentation en fonction de l’architecture cible. Et pour enfoncer le clou :
« These operations are all programming errors that could occur using many programming languages; C draws criticism because its standard explicitly identifies numerous cases of undefined behavior, including some where the behavior could have been made well defined, and does not specify any run-time error handling mechanism. » C’est-il pas beau ?
Pour la route : « man gcc », [/], « -ansi », « -pedantic », et surtout retourner sur les bancs de l’école. On ne peut pas dire que je pisse du C à longueur de journée, mais je connais quand même les bases.
Et, je crois que ça vient de C99, s’il y a quelqu’un pour confirmer…, on a accès à des types à la taille prédéfinie.
¹ D’une part, la division euclidienne n’est bien définie que pour les entiers naturels (c.-à-d. positifs), d’autre part, la blague avec l’arrondi à l’entier inférieur n’en est plus une.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 3.
Si tu veux utiliser des int, va pourtant bien falloir que tu fasses une supposition sur le comportement du compilateur... Si tu ne veux pas faire de supposition, la seule alternative qu'il te reste, c'est de ne pas utiliser le type int.
Tu peux aussi t'amuser à faire des tests à coup de #ifdef : pour que ton code deviennt "portable" : c'est jamais qu'un aveu de non portabilité : tu écris du code spécifiques dans chaque branche de ton if.
Les comportement indéfinis sont précisément là pour laisser champ libre à l’implémentation en fonction de l’architecture cible.
On est d'accord, y'a une bonne raison : c'est pour des questions de perf/optimisation. Mais il n'en reste pas moins que le code devient non portable puisqu'avec un comportement potentiellement différent d'une architecture à l'autre.
D'ailleur la phrase que tu cites est effectivement éloquente : grosso modo il est de la responsabilité du programmeur de s'assurer que son code est portable. Ce qui montre bien que la norme ne l'assure pas.
CQFD.
On ne peut pas dire que je pisse du C à longueur de journée, mais je connais quand même les bases.
Le problème, c'est que t'as visiblement jamais bosser sur un vrai projet en C : la vraie vie, c'est que t'as intérêt de faire gaffe quand tu codes en C si tu veux qu'il soit portable, et t'as sacrément besoin de vérifier. T'appelles ça des "erreurs" de programmation si tu veux, le fait est que le compilateur ne t'offre aucune garantie que le code que tu pondes soit portable, et pour cause, la norme l'oblige à faire un choix qui ne sera pas le même que celui du voisin.
D'ailleurs, quelque chose qui montre bien que la norme ANSI C n'est pas un garant de portabilité (même si son respect met le code sur la bonne voie), c'est le nombre de "guide" pour le programmeur afin qu'il fasse attention à la portabilité du code qu'il écrit :
"Guide pour la portabilité" : http://docs.hp.com/en/B3901-90005/ch05s02.html
http://serghei.net/docs/programming/autobook-1.1/writing20po(...) (citation rigolote : "The C language makes it easy to write non-portable code")
Le mythe de la portabilité du C : http://spinning-yarns.org/blog/?p=451
http://www.psgd.org/paul/docs/cstyle/cstyle16.htm (avec ma préférée : "C combines the power of assembler with the portability of assembler. " )
http://unixwiz.net/about/porting.html ( "Ultimately, most software porters created portability macros that allowed the use of many of these features in code that could be straight K&R or ANSI.")
Voilà la vraie vie de nombreuses personnes. Rien à voir visiblement avec ton expérience personnelle.
Quand tu codes en Java ou en C#, t'es pas en train de poser des questions sur le fait que ton code soit portable ou non en fonction de l'architecture matérielle, tu te demandes juste si les libs que tu utilises sont portables (cad s'appui sur du code natif portable ou non) : ce sont des beaucoup plus portables que le ANSI C.
[^] # Re: Bonne nouvelle
Posté par nicolas . Évalué à 2.
int a une taille minimal : 16 bits, quand tu risques de dépasser, comme je l’ai dit, les constantes sont définies, par exemple si tu additionnes deux int il faut faire attention que les deux soit < INT_MAX / 2 par exemple (je ne me rappelle plus le nom exacte de la constante). Pareil pour la multiplication : il faut vérifier que tu es inférieur à la racine. Au passage je crois que c’est pareil pour le java, en C# j’en sais rien et je m’en tape. Et, mis à part si le langage peut manipuler des entiers de taille arbitraire, il faut faire attention à la taille des int, toujours, sinon ton code va t’exploser à la gueule tôt ou tard.
Ne pas accepter d’utiliser une variable nommée INT_MAX (ou que sais-je) en lieu et place d’un nombre codé en dur dans ton code est au mieux du foutage de gueule, au pire de l’incompétence.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 nicolas . Évalué à 3.
en:C_standard_library
en:limits.h
Et tu as le même problème en Java ! Faut vérifier que tu ne dépasses pas la limite. La seule différence est qu’en Java le code gruik avec le chiffre en dur est accepté.
95 % ? T’es optimiste ! :p
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 nicolas . Évalué à 3.
⇒ Fortune !
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à 0.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 8.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 nicolas . É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. »
Ça pête juste pareil : 16 bits = 64 ko addressables, 32 bits = 4 Go addressables. malloc (INT_MAX) t’alloueras en fait toujours la moitié de la mémoire.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Bonne nouvelle
Posté par nicolas . Évalué à 2.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 nicolas . Évalué à 2.
Alors effectivement un code qui alloue 2 Go n’est pas non plus portable sur une machine qui n’a que 1 Go. Ok, tu as gagné : le C n’est pas « portable ».
Sinon sur un vrai système (c’est du quick&dirty) :
#include <stdlib.h>
#include <stdio.h>
#define N 250000000
int main (int argc, char **argv) {
int *a;
int i;
a = (int*)malloc (N * sizeof (int));
printf ("%u\n", a);
for (i = 0; i < N; i++)
a[i] = 0;
printf ("zeros\n");
for (i = 0; i == 0;);
return 0;
}
J’alloue donc ~1 Go, j’ai 1 Go de RAM :
nicolas:~% ./a.out
2078031880
mon clavier s’est blo… nan je rigole ^^ par contre ça swappe
zeros
Résultat du TOP :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23784 nicolas 20 0 955m 666m 172 R 100 66.6 0:19.75 a.out
Ça marche parce que mon système n’est pas en carton ^^, tant que j’alloue une quantité inférieure à la mémoire de RAM c’est bon…
D’ailleurs un spécialiste dans la salle pour me dire comment c’est possible ? Un malloc doit retourner une zone continue.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 Littleboy . Évalué à 2.
Prenons un probleme un tout petit peu plus realiste (mais tout de meme relativement simple):
Je veux lire un fichier dans une structure en memoire et ensuite acceder a une valeur val de taille t dans cette structure situee a offset du debut.
Le tout doit etre portable [*].
Tu trouves que le C c'est portable facilement, ca doit donc etre trivial pour toi a realiser en quelques minutes. Vas-y, prouves-nous que tu sais ce dont tu parles...
[*] c'est volontairement vague pour voir si t'y connais un minimum et que tu prevois plus que juste le cas general.
[^] # Re: Bonne nouvelle
Posté par nicolas . Évalué à 3.
Par « le tout » je suppose que tu parles du code et du fichier de donnée. D’une remarque que j’ai précisé dès le début (pfiou ça remonte assez loin maintenant dans le fil) que je parle du code et pas des fichiers de données qui sortent.
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 volontairement vague » À tel point que je n’ai pas compris.
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 1.
Change fichier de donnees par discussion reseau avec un autre client alors.
Fait la meme chose avec du Java, ou autre langage reellement multiplateforme, ton int envoye sera 32 bits dans une certaine endianness, quelque soit la machine faisant tourner le code.
C'est sur qu'avec comme une definition de portable telle que "ca compile", forcement, on va aller loin...
Bon, les deux compilations feront pas la meme chose, mais c'est pas grave ca, le code a compile donc il est portable.
Si tu vas par la un File file = new File("C:/Program Files"); c'est portable, ca compile!
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 Littleboy . Évalué à 2.
Le fichier de donnees est fixe (disons LE si tu veux). Le code doit etre capable de lire les donnees, quelque soit l'architecture et l'alignement. Comme plein de gens le disent depuis le debut sur le thread, c'est faisable, mais non trivial (et le langage ne te donne pas les briques pour le faire automatiquement, il faut tout gerer toi meme).
Pour le code, comme je le dis et le répète : c’est portable
je n’ai personnellement jamais fait donc je ne saurais te pondre le code là comme ça en 10 minutes, mais c’est possible
Ben le code il s'ecrit pas tout seul. Et apres tu viens dire aux autres de retourner sur les bancs de l’école. Faut etre gonfle quand meme!
Lorsque tu auras eu a ecrire du code portable qui manipule autre chose que des fichiers textes a coup de printf, tu pourras peut-etre la ramener...
[^] # Re: Bonne nouvelle
Posté par DLFP est mort . Évalué à 1.
- temps de compilation interminable.
Et Java c'est rapide ? On a pas utilisé le même. Vu qu'on recompile en général que ce qui a été modifié (y compris pour Java je suppose), ce n'est pas très significatif sauf à être utilisateur de Gentoo.
- lib standard anoréxique.
- comportements non définis ( initialisation statique, accès concurrents...)
- compatibilité binaire très difficile à maintenir.
Mais il y a plein d'autres langages, pourquoi Java ?
IDE et outils peu puissants
Il est effectivement plus facile d'analyser un langage simpliste qu'un langage complexe.
Quant à Java, c'est bien le premier langage qui est à peu près inutilisable sans IDE monstrueux, je n'appelle pas ça un progrès.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Bonne nouvelle
Posté par DLFP est mort . Évalué à 2.
Justement il y en a plein, qui permettent de détecter quelques erreurs basiques par exemple. Ça ne t'évite pas de faire des architectures avec 40 Factory évidemment, bref c'est bien pour les boîtes qui emploient des développeurs incompétents et qui veulent limiter la casse. Bref, c'est le côté simpliste de Java qui permet ça, là où dans d'autres langages certaines fonctionnalités rendent l'analyse difficile.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 1.
Et ce code ecrit a l'epoque est potentiellement encore utilise de nos jours. Plus sous cette forme, certes, mais le jour ou le dev a recu son pentium flambant neuf, ca a du lui faire bizarre quand il a compile son appli.
Et mon petit doigt me dit qu'il a du mettre du temps a trouver la source du pb.
Je suis loin d'etre un expert en code natif, mais je serais pas surpris que d'autres problemes du meme tonneau sont apparus le jour ou des mecs ont passe leur appli en 64 bits.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 0.
Ces ptis cons qui se croient meilleurs que tout le monde parce qu'ils ont implemente une liste chainee suite a leur 3ieme tp de C...
C'est sur que toi, t'as prevu toutes les evolutiosn de l'informatique pour les 30 prochaines annees.
Tu pourrais meme les inventer, la maintenant, mais tu preferes draguer la belette a la cafet' de la fac.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par lasher . Évalué à 2.
Quelque soit le langage, si celui-ci autorise des accès concurrents non-protégés, le résultat est nécessairement aléatoire. Ce n'est pas obligatoirement un « mauvais » résultat (certains algorithmes en tirent même parti), mais généralement ce n'est pas ce qu'on recherche.
Ceci étant dit:
Le modèle mémoire de Java (JMM) spécifie que si tu codes sans passer par des outils de synchro (locks, utilisation de volatile, etc), alors le comportement à l'exécution est indéfini. Si tu utilises les mécanismes de synchro, alors tu auras une exception à l'exécution (ou peut-être même une tape sur la main à la compil si tu as des outils intelligents).
Dans le cas d'une utilisation correcte des méthodes de synchronisation, alors le JMM garantit une exécution suivant une politique appelée « sequential consistency » (SC). En gros, Du point de vue du thread qui s'exécute, l'ordre des instructions (au sens instruction load ou store dans la jvm) doit être celui spécifié dans le programme original, et toute écriture sur un des objets mémoire que le thread manipule (lecture ou écriture) doit lui apparaître selon l'ordre total de tous les threads qui s'exécutent en même temps.
Je parle ici de programmes dits « data race free » i.e. qui ont des accès synchronisés aux variables partagées.
Java a toujours eu un modèle mémoire concernant les accès concurrents, mais celui-ci est cassé/buggé. En 2004 une refonte du JMM a été commencée (et appliquée à partir de Java 1.5 si je me souviens bien).
Le cas de C++ diffère, dans le sens où les threads ne faisaient pas partie du langage initialement. La prochaine norme va les intégrer au langage, ce qui signifie que C++ doit prendre position sur la façon dont les opérations en mémoire doivent être perçues par le programmeur et à l'exécution.
C++MM suit plus ou moins le même modèle (SC pour les programmes sans accès concurrents aux données), avec quelques subtilités où ils précisent explicitement certains comportements indéfinis ou dépendants de l'implémentation (pour autoriser certaines optimisations impossibles dans le cas SC pur).
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
Eh sinon fait du C#, t'as des structures nommées Int16, Int32, Int64 ;)
C'est d'ailleur assez rigolo de voir comment les approches divergent :
en C#, int n'est qu'un alias de Int32, long un alias de Int64, short un alias de Int16.
En C, c'est l'inverse, int32_t est un typedef de int ou autre en fonction de la plateforme.
[^] # Re: Bonne nouvelle
Posté par lasher . Évalué à 2.
malloc(INT_MAX) n'alloue pas toute la mémoire, juste un nombre maximal de cases qui peuvent stocker de l'information dans un tableau.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Bien au contraire, parce qu’à l’époque des processeurs 16 bits, beaucoup étaient également à adressage 16 bits, et donc malloc(INT_MAX) c’était allouer la moitié de l’espace d’adressage.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Dans les faits, c’est le C qui a réussi à prouver qu’il pouvait tenir des décennies (presque 40 ans !) et toutes les évolutions qui se sont déroulées pendant ces décennies.
Moi, je suis impatient de voir les développeurs Java dans 30 ans quand le programmeur lambda pourra se permettre des tableaux contenants des milliards d’éléments, avec la spec de leur langage où il est écrit en dur « l’index des tableaux, c’est 32 bits ».
Si Java existe encore dans 30 ans, bien entendu.
C’est sûr, le C aurait été plus « portable » (au sens assez restreint de mes contradicteurs où seule un langage garantissant à 100% la portabilité peut être qualifié de portable) si on avait mis en dur dans la spec « un entier, c’est 16 bits, un long 32, et un pointeur doit pouvoir tenir dans un long ». Pas sûr que le C aurait fêté ses 40 ans s’ils avaient fait ce choix (mais j’aurais été amusé de voir la tête de pBpG et des autres développeurs de Windows (Linux aussi du reste) si ce choix avait été fait. Comment ça on doit changer de langage de programmation et tout réécrire de A à Z pour faire du 64 bits ? Mais je croyais que le langage était plus portable quand on définissait explicitement tout !)
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Tu n’as _rien_ compris au message de pBpG.
Quand tu indexes toute la mémoire, par définition, tu utilises toute la mémoire pour l’indexation (dit autrement : si tu essaies de faire une table de hashage dans laquelle la clef est l’adresse mémoire linéaire, alors rien que le stockage de tes clefs te prend la mémoire entière).
Ce que pBpG dit, c’est que sur une machine où l’entier est à 16 bits mais où l’adressage est sur 20 bits — à l’aide de mécanismes comme la segmentation —, malloc(INT_MAX), c’est 16 fois moins (en fait 32, il a oublié que INT_MAX était signé) que l’espace adressable, donc que ça plantera pas — au contraire de nos machines où taille de l’entier = capacités d’adressage.
C’est tout.
Le seul exemple qu’il a donné, c’est « sur 16 bits on peut utiliser malloc(INT_MAX) pour allouer 64ko, et ça plante sur 32 bits », ce que j’appelle difficilement un exemple probant.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 0.
Dieu vivant du code?
T'etais ou ces 10 dernieres annees, quand google et facebook ont mene la scalabilite la ou elle n'a jamais ete?
Non, parce que tu viens de nous dire substance "le java c'est bon pour les boites qui embauchent des incompetents" je te demande donc d'annoncer a google qu'ils sont incompetents, ca devrait les faire rigoler vu le niveau de tes competences.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Pardon je n'ai pas été clair : en Java, les opérations concurrentes suivent la norme qui dit dans quels cas elles donnent des résultats imprévisibles ou prévisibles.
En C++, la réponse est presque toujours "ça dépend".
Sauf que la complétion, les opérations de refactoring, de génération de code et de modélisation ne sont souvent bien implémentées que pour Java. C'est bien dommage d'ailleurs!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Essaye avec de gros projets, tu verras la différence.
Il était là au bon moment, avec la bonne com?
Oui, mais les gens aiment les gros IDE. Tu peux toujours essayer de les convaincre qu'avec ton VIM et ton GDB, on peut être plus productif, ça ne marchera pas.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par DLFP est mort . Évalué à 3.
Quant à Facebook, oui c'est clairement une boîte d'incompétents mais ils font surtout… du PHP.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 3.
Allez, encore un petit effort et tu pourras être encore plus insultant.
Bon, comme tu as l’air d’être un peu dur à la compréhension, je répète. Tu me dis :
- Java a de bons IDE => Java est un bon langage (plus exactement, tu as dit : la qualité de ses IDE est une mesure de la qualité d’un langage)
Je te dis: c’est faux, parce que la bonne relation de causalité est:
- Java nécessite un IDE pour être utilisé => Java a de bons IDE
Avec, pour argument : de très bons langages, qui ne nécessitent pas d’IDE, ne donnent pas une telle « culture de l’IDE » : Ruby et Python par exemple. L’immense majorité des devs de RoR sont soit sous vim, soit sous TextMate. Ce se sont incompétents ? Des narcissiques qui préfèrent « se mesurer la quequette » plutôt que d’être productifs ?
C++, qui, au niveau « nécessité de l’utilisation d’un IDE », se situe entre Python et Java, ben se situe également entre les deux sur « qualité des IDE » (refactoring moins bon voire inexistant par exemple) et sur « nombre de programmeurs préférant travailler avec un IDE en C++ »
> mais le but du jeu c'est de produire des applis
Putain, j’aurais jamais deviné tout seul. Merci beaucoup de m’avoir prévenu, heureusement que tu es là.
Maintenant, est-ce qu’il ne te serait pas venu à l’esprit que :
- l’utilisation des IDEs a des avantages mais aussi des inconvénients (naoon, pas possible !)
- le poids de ces avantages et de ces inconvénients diffère selon le langage et même la personne (fou hein !)
- et que donc, au niveau productivité, l’utilisation ou non d’un IDE dépend du langage, du projet, et de la personne (bon, je commence à avoir mal à l’épaule à force d’enfoncer des portes ouvertes)
[^] # Re: Bonne nouvelle
Posté par nicolas . Évalué à 2.
« Comme plein de gens le disent depuis le debut sur le thread, c'est faisable, mais non trivial »
Et ben je crois qu’on est « tombé » d’accord. Enfin… mis à part qu’on a dévié, dès mon second commentaire j’ai bien fait la distinction entre le code et les fichiers de données. Il faut faire la distinction. Le code est portable, les fichiers binaires ne l’ont jamais été.
Ce sera mon dernier commentaire.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 1.
Ce sera mon dernier commentaire.
C'est con c'est exactement l'inverse :) Le problème n'est pas le fichier binaire en soit : lui est parfaitement portable et à peu prêt tous les systèmes sont capables de stocker un fichier en conservant sa structure intacte.
Par contre, le code qui lit/écrit le fichier, s'il est écrit en C, a un comportement différent suivant la machine sur laquel il s'exécute : il va intepréter différemment le fichier suivant l'architecture.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 1.
Tu vas rire, mais tu les utilises indépendament de ton architecture : que ce soit du 16, 32, 64 bits, ou pourquoi pas demain 128 ou je ne sais quoi.
Et là tu vas te bidonner : même que Java, si le besoin s'en fait ressentir, peut évoluer, tout comme le C évolue...
Comment ça on doit changer de langage de programmation et tout réécrire de A à Z pour faire du 64 bits ?
C'est quoi cet argument ridicule ? Le C s'est vu ajouté des types à taille fixe en 99, et personne ne trouve que c'est un boulet, bien au contraire. Si demain il y a besoin de types plus large encore, il suffira de rajouter de nouveaux keywords, waouuh va falloir tout réécrire ?
Non clairement en C il faut utiliser ces types à taille fixe si on veut du code portable, et il n'y a aucun inconvénient lié à l'évolutivité des plateformes.
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 2.
Calme toi et laisse tomber. Il n'y aura plus de discussion si tant est qu'il en est eu une. C'est un des tactiques preferes des personnes paye par microsoft pour pourrir leurs opposants.
[^] # Commentaire supprimé
Posté par Littleboy . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 1.
D'autre part, les devs java updateront leur code bien tranquillement, pendant que les devs C seront en train d'en chier a updater leur implem de tout ce qui touche au binaire, parce que les int sont passe de 32 a 64b un beau matin, que ca fout la grouille partout et qu'en plus on s'en rend pas forcement compte sauf dans des cas speciaux.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Commentaire supprimé
Posté par Albert_ . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 3.
[^] # Re: Bonne nouvelle
Posté par DLFP est mort . Évalué à 3.
C'est pas toi qui raille sur la mesure de taille de quéquette dans un autre commentaire ?
Je ne vois pas le rapport entre le nombre de visiteurs et la compétence. Et c'est quoi cette mode de balancer des noms de grosses boîtes comme si c'était des dieux vivants du code ?
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à 0.
C’est tout.
Le seul exemple qu’il a donné, c’est « sur 16 bits on peut utiliser malloc(INT_MAX) pour allouer 64ko, et ça plante sur 32 bits », ce que j’appelle difficilement un exemple probant.
Vraiment ? Pourtant c'est un exemple reel, qui demontre que non, C n'est pas un langage multi-plateforme du fait de la non definition de ses types de base parmis d'autres faiblesses au niveau support multiplateformes.
Tu iras des lors expliquer a ce code qu'il n'a jamais existe, et qu'il n'avait pas non plus lieu d'exister.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à 1.
Merci de confirmer ce que je dis depuis le debut.
La prochaine fois, reflechis avant d'ecrire.
[^] # Re: Bonne nouvelle
Posté par daimrod . Évalué à 4.
C'est un peu comme le Lisp, la grammaire de base est extrêmement simple, pourtant c'est un langage très puissant.
Bah KISS c'est pareil, c'est simple et efficace sans être simpliste.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 devnewton 🍺 (site web personnel) . Évalué à 2.
Est-ce que ce n'est pas plutôt la culture du "mon langage n'a pas la feature X, du coup je clame qu'il est tellement bien qu'on n'en a pas besoin"?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
> Pourtant c'est un exemple reel,
Comme ce qu’on trouve sur http://thedailywtf.com/
Encore une fois, c’est quoi la sémantique derrière malloc(INT_MAX) dans un exemple de code correct ? Si c’est "allouer 64K", permets-moi de crier bullshit : c’est un code qui aurait sa place sur DailyWTF, tout comme new int[(int)math.PI] le serait pour créer un tableau de 3 entiers.
Et si c’est pour dire que C est moins neuneu-proof, encore une fois (ça fera combien de fois dans ce fil ?) : je sais.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 3.
Je suppose donc que je ne peux pas savoir :
- sur quel OS je tourne, et agir en conséquence
- l’endianness de la machine hôte, et agir en conséquence (par exemple IPC avec un programme écrit en C++ qui partage ses données dans le sens de la machine hôte)
- la JVM sur laquelle je tourne, et agir en conséquence
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 1.
> Sauf que la complétion, les opérations de refactoring, de génération de code et de modélisation ne sont souvent bien implémentées que pour Java. C'est bien dommage d'ailleurs!
Refactoring, peut-être (jamais essayé les outils de refactoring d’eclipse dont on me rebat tant les oreilles), pour le reste, tu as totalement craqué, n’importe quel IDE un tant soit peu complet est capable de faire ça pour le C ou le C++
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 1.
Ça, ça dépend complètement du langage. Effectivement, l’immense majorité des devs Java aiment les gros IDE, mais c’est exactement parce que le langage est inutilisable sans (forcément, étant donné que les 3/4 du code sont tellement trivial qu’un IDE peut le générer et qu’un être humain se fait chier à en crever à l’écrire…)
Les développeurs Python, Ruby et PHP n’aiment en général pas les IDE parce que ces derniers sont incapables d’utiliser toute la puissance de leur langage (et pourtant, la puissance de PHP…)
Pour les développeurs C et C++, ça dépend franchement des milieux.
[^] # Re: Bonne nouvelle
Posté par nicolas . Évalué à 2.
J’ai un système de 1 Go de RAM, et 1 Go de SWAP. Environ 250 Mo de la RAM et 180 Mo du SWAP sont occupés. Je fais un malloc de environ 1 Go, il doit me trouver une mémoire continue. Il ne peut physiquement exister 1 Go de mémoire continue, pourtant, le système me la donne lors du malloc. Ma question est : comment le kernel gère ça ?
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 4.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
> Eh tu vas rire, mais en Java, y'a un type "long" et un type "double".
Aucun, mais alors vraiment aucun rapport avec ce que j’ai écrit.
Ou alors on peut utiliser les double pour indexer des tableaux en Java. Dans ce cas, c’est une killer feature que vous devriez mettre en avant.
> Et là tu vas te bidonner : même que Java, si le besoin s'en fait ressentir, peut évoluer,
Ben nan, et c’est très précisément ce que je voulais dire.
En C, on a pas défini en dur « taille d’un pointeur », de même qu’on a pas défini en dur « type de l’indice d’un tableau » dans la spec. Alors ça pose quelques soucis de portabilité à certains gruiks qui voyant que sur leur machine sizeof(int) = sizeof(void*) pensent qu’ils peuvent caster des int en void* et vice-versa, certes, mais ça laisse le champ libre à l’évolution du C.
Donc quand on est passé de 16 bits à 32 bits puis 32 bits à 64 bits, pas de souci pour passer de tableaux contenant des dizaines de milliers d’éléments à des millions, et on aura ensuite aucun souci pour passer de tableaux contenant des centaines de millions d’éléments à des tableaux de plusieurs milliards d’éléments.
Au contraire, Java a dit :
- int = 32 bits
- indice des tableaux = int. long doit balancer une exception [http://java.sun.com/docs/books/jls/second_edition/html/array(...)]
Ergo, avec Java, tu ne pourras tout simplement pas faire de tableaux de quelques milliards d’éléments même quand ce sera monnaie « courante » chez d’autres langages.
Le but est juste de montrer les inconvénients de définir une taille d’entiers fixes, pourquoi le C a choisi de ne pas le faire, et pourquoi ce choix a été un facteur de réussite sur le long terme.
Tu veux un autre exemple ? Prenons le cas où j’ai codé un algorithme sur ma machine 32 bits, que je veux utiliser sur un processeur 16 bits sans addl (je pense qu’on peut plus en trouver aujourd’hui, mais ça a existé).
En Java :
- soit la JVM n’existe pas pour cette machine : on a rien pour faire de l’int
- soit la JVM force artificiellement le 32 bits à l’aide d’une fonction addl, et bonjour les performances où toute opération sur un int c’est un appel de fonction
- donc, en pratique, je fais un sed s/int/short/g MonAlgo.java > MonAlgo-16.java
En C:
- je recompile et ça juste marche (tm). Sauf si bien sûr j’ai codé comme un porc.
- différence entre les plateformes : les limites de mon algorithme sont plus basses sur la machine 16 bits. Rien qui ne me choque là-dedans.
Pour moi, sur cet exemple, le C est plus portable.
Encore une fois, ce que je dis, c’est ça :
- le fait de ne pas fixer les tailles en C a été un choix
- ce choix, en pratique, revient à privilégier une forme de portabilité (algorithme qui s’adapte « automagiquement » aux capacités de la machine) sur une autre (certaines opérations peuvent « tomber en marche » sur une machine et planter 2 ans plus tard quand tu changes de machine)
- ce choix a été un des facteurs de succès du C sur le long terme
> Non clairement en C il faut utiliser ces types à taille fixe si on veut du code portable
Que dalle. Il faut utiliser des entiers de taille et d’endianness fixe pour la communication avec l’extérieur et vérifier les tailles lors de la sérialisation/déserialisation, c’est tout.
Si je veux un "entier sur 32 bits", parce que ça a un sens sémantiquement dans le contexte (pour coder une couleur RGBA par exemple), oui, je prend un entier de taille fixe.
Si je veux juste "un nombre sur lequel ma machine peut faire des opérations arithmétiques" (l’immense majorité des algos), je prend un int.
Bon sang, c’est juste une règle de bonne conduite dans tout projet et dans tout langage : un choix d’ordre sémantique doit être explicité ! int et int32_t, ce n’est pas _du tout_ la même chose sémantiquement, et si tu les mélanges au petit bonheur la chance, c’est pas la faute du langage, c’est parce que tu ne sais pas ce que tu fais, et dans ce cas, comme le disait mon prof d’ingénierie logicielle : tu enlèves les mains de ton clavier et tu réfléchis. unsigned int rgbaColor = 0xdeadbeef, c’est une hérésie, que ce soit en C ou en Java, parce que pour du RGBA-32, la taille a un sens important. Même si ça marche et c’est portable en Java, c’est du même ordre que mon exemple new int[(int)PI] : c’est pas parce que _par hasard_ la constante ((int)PI ou sizeof(int)) marche pour mon problème qu’il est correct de l’utiliser !
> C'est quoi cet argument ridicule ?
Relis mon exemple. Tu ne l’as pas compris.
tl;dr : sur la question de la taille des entiers, il n’y a pas un langage plus ou mois portable qu’un autre entre Java et C : il y a portabilité formelle (si ma fonction multiplyByTwo fonctionne sur une architecture avec 2**30 en entrée, alors elle doit fonctionner partout avec cette entrée, même si ça signifie que toute opération sur un int doit être ralentie (à la louche) d’un facteur 10 ou plus si la machine ne sait pas faire nativement) pour Java contre portabilité sémantique (la sémantique générale de l’algorithme multiplyByTwo est préservée, mais ses limites dépendent de la machine) pour le C
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 0.
Mouhahaha!
T'en as pas marre de te ridiculiser serieux?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
D'où as-tu sorti cette exemple débile? On attends toujours que tu nous sortes un cas concret et pas un vague "ça pouvait être utile il y a 20 ans je crois peut être".
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
C'est TON code qui est tout moisi :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par nicolas . Évalué à 2.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 3.
http://download.oracle.com/javase/1.4.2/docs/api/java/awt/Co(...)
;)
[^] # Re: Bonne nouvelle
Posté par DLFP est mort . Évalué à 2.
Pourquoi tu ne réponds pas au reste, plutôt que dire que je suis « ridiculisé » ?
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à 1.
Combien d'elements maximum peut-il gerer ? MAX_INT ...
Quel est le moyen le plus rapide d'acceder a ces elements ? Une table contenant ces elements, une table de taille ... MAX_INT
--> malloc(MAX_INT) ou MAX_INT*(ce que tu veux)
C'est peut-etre pas optimal, mais c'est pas stupide non plus hein quand la taille au final est bien plus petite que la RAM dispo sur les machines standards.
Ca a tout son sens quand ton soft gere 32768 (ou 65536 avec MAX_UINT) elements, le probleme etant quand tu 4 ans plus tard un nouveau systeme sort, et il a des int sur 32bits, et boum, tu te retrouves avec ta table qui fait 2 milliards d'entrees.
Et devines quoi, aujourd'hui tout le monde a un systeme avec CPU 64bits, et des int 32bits, d'ici quelque annees tout le monde aura 128Go de RAM en standard sur son iPad/desktop/frigo et on verra regulierement des tables de 2^32 elements, tu sais, MAX_UINT, ou si ce n'est l'allocation elle-meme, une reservation d'espace d'addressage continu de cette taille a remplir au fur et a mesure des besoins(ca se fait probablement deja aujourd'hui dans des bases de donnees).
Et dans quelque annees, un nouvel OS(ou ancien et modernise) bien joli va sortir tout 64bit et tout, avec des int de 64bit vu que tout le monde a 128Go de RAM et qu'un int 32bit c'est devenu ringard, et boum, la meme merde.
Quand t'as des types de taille statique, ce genre de merde n'arrive pas, si tu passes ton soft sur le nouvel OS, ton code il marche, point.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
byte[] gros = new byte[java.Integer.MAX_INT];
C'est pas portable! Sur les machines avec moins de 4Go de RAM ça ne marche pas!!! Bouh!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 3.
Ce qui n’est pas en soit surprenant.
> Ca a tout son sens quand ton soft gere 32768
Tu mélanges deux situations différentes. Ton soft gère 32768 éléments ou MAX_INT éléments ? Ce n’est pas la même chose.
Cas où ton soft gère 32768 éléments : ben tu fais pas MAX_INT, mais #define MAXELEMS
Cas où ton soft gère MAX_INT : tu aimerais bien que ton algo scale avec les capacités de ta machine, donc il me semble normal que MAX_INT change selon l’architecture, et tant pis si ça plante pour une machine pas assez puissante.
> et on verra regulierement des tables de 2^32 elements
Ha, mais c’est exactement mon argument plus bas, hein !
1. Là où Java est portable dans le sens où il garantit que l’algo aura les mêmes limites partout, là où C est portable dans le sens où l’algo « scale » avec les capacités de la machine.
2. Justement, je suis impatient de voir comment fera Java quand on verra régulièrement des tables de 2^32 éléments, alors qu’il est écrit dans sa spec que l’index d’un tableau, c’est 32 bits.
> Quand t'as des types de taille statique, ce genre de merde n'arrive pas, si tu passes ton soft sur le nouvel OS, ton code il marche, point.
Mais il est incapable de profiter de la puissance de ce nouvel OS flambant neuf, et au final, si tu veux en profiter, tu es obligé de recoder ton programme en changeant des int par des long.
C’est pas « plus » ou « moins » portable, c’est différent. Pour une FFT fenêtrée de taille fixe sur un stream, l’approche Java est plus adaptée. Pour de la manipulation d’images, l’approche C est plus adaptée (tu aimerais que la limite en taille d’image puisse s’adapter avec l’évolution du matos : images 170 par 170 au max sur du 16 bits, 65000 par 65000).
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 0.
Je sais pas, c'est un peu comme si tu disais que internet est ecrit en C parce que les serveurs web sont generalement du apache.
Ca veut rien dire en premier lieu, vu le nombre de composants implique dans un site pareil, le php n'est que la partie visible de l'iceberg.
Mon petit doigt me dit qu'ils ont qq palettes de Java pour les applis, avec du c/c++ pour les composants qui necessite une optimisation "native", pas mal de python et/ou de ruby pour tout ce qui est script interne et probablement d'autres trucs auquels j'ai pas pense..
Par dessus tout ca, tu rajoutes des camions entiers de mysql avec probablement pas mal de procedures stockees, qq containers de hadoop + hives pour tout ce qui est traitement des donnees.
Et au dessus tout ca, pour la partie que toi tu vois, ils ont des pages php (qu'ils compilent en c++ au final...).
A ton avis, le data mining dans le demi milliards d'utilisateurs, il tourne en php?
Tout le backend, il tourne en php?
La partie en php, c'est la partie "facile" (bon, facile, tout est relatif vu la charge, mais c'est pas le plus complique clairement), c'est juste du rendu html. Traiter les millions de photos qu'ils font par jour, mettre a jour les walls en temps reel, construire les graphes d'utilisateurs gigantesque et tout ce genre de connerie, tu crois *vraiment* que c'est fait en php?
Et google search, tu vas me dire qu'il font surtout du python?
Pourquoi tu ne réponds pas au reste, plutôt que dire que je suis « ridiculisé » ?
Parce que tu me fais rire quand tu te sent coince, tu sort ton parapluie geant et tu commence a nier ce que t'as dit 2 messages plus haut.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par DLFP est mort . Évalué à 2.
Parce que tu me fais rire quand tu te sent coince, tu sort ton parapluie geant et tu commence a nier ce que t'as dit 2 messages plus haut.
Ta tactique d'argumentation principale est de déformer les propos des autres et plus personne ici n'est dupe. Tu peux dire où je me suis contredit ?
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à 1.
Parce qu'un malloc(INT_MAX) sur certains systemes a tout son sens, et sur d'autres absolument aucun, alors qu'un byte[] gros = new byte[java.Integer.MAX_INT] lui a _toujours le meme sens_ ou que ce soit. Et c'est bien ca qui fout la merde avec le C, le meme code se comporte differement d'un systeme a l'autre.
Mais bon, c'est tellement plus simple de sortir des inepties plutot que regarder la verite en face ...
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à 1.
Cas où ton soft gère 32768 éléments : ben tu fais pas MAX_INT, mais #define MAXELEMS
Cas où ton soft gère MAX_INT : tu aimerais bien que ton algo scale avec les capacités de ta machine, donc il me semble normal que MAX_INT change selon l’architecture, et tant pis si ça plante pour une machine pas assez puissante.
Sans blague ? Merci je connais, mais moi je regardes pas la theorie de ce que t'es sense faire et que 1% des gens font, mais ce que l'enorme majorite des gens font, parce qu'au final si le langage est tellement alambique que personne ne sait, c'est comme si le langage ne le faisait pas.
La realite est que l'enorme majorite des developpeurs ne sait meme pas qu'un int peut avoir une taille differente d'un systeme a l'autre. Cette realite fait que tous ces softs qu'ils ont ecrits ne sont probablement pas multiplateforme.
La realite est qu'un soft ecrit par un neuneu en Java/Python/autre lui par contre il a toutes les chances de tourner sur plein de plateformes differentes.
Mais il est incapable de profiter de la puissance de ce nouvel OS flambant neuf, et au final, si tu veux en profiter, tu es obligé de recoder ton programme en changeant des int par des long.
Tout a fait, maintenant ce que Java fera c'est d'ajouter a sa spec de nouvelles methodes supportant une taille d'entier superieure pour les tableaux et autres, et ca resoudra le probleme, sans rien remettre en cause.
[^] # Re: Bonne nouvelle
Posté par nicolas . Évalué à 2.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Ben non, vu le nombre de programmeurs compétents, s’il y avait un besoin (d’IDE), t’inquiète que les IDE se mettraient à pousser comme des champignons et que un ou deux sortiraient vite du lot.
D’ailleurs, tu remarqueras que pour Python par exemple, des IDE de très bonne facture existent [http://eric-ide.python-projects.org/], mais sont peu utilisés.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Je ne sais pas non plus s'il existe des statistiques sérieuses au sujet de l'utilisation d'IDE chez les pythoneux.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Après, ça plantera si t’as pas assez de RAM oui (que tu sois sur un 16 bits avec 20ko de RAM et pas de swap ou un 32 bits avec moins de 4 Go de RAM + swap), mais c’est là une question de capacités de la machine.
C’est pas parce la taille d’un entier varie que la sémantique derrière change.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
La norme Java impose certaines choses (ordre des initialisations statiques, accès à la mémoire, synchronisation, intéractions entre thread) et il y a une bibliothèque standard pour le threading avec un comportement spécifié.
En C++, c'est le bordel, chaque combinaison compilateur/plateforme d'exécution/bibliothèque peut avoir un comportement différent.
Heureusement ça va changer : http://en.wikipedia.org/wiki/C%2B%2B0x#Multitasking_memory_m(...)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 1.
- sur quel OS je tourne, et agir en conséquence
- l’endianness de la machine hôte, et agir en conséquence (par exemple IPC avec un programme écrit en C++ qui partage ses données dans le sens de la machine hôte)
- la JVM sur laquelle je tourne, et agir en conséquence
D'après la norme Java ? non.
Avec des API dédiés, bien sûr que oui.
C'est toute la différence : le langage, la JVM, sont normalisés de telle sorte qu'ils sont totalement indépendant de la machine physique, ce qui garantie sa portabilité. Après tu peux utiliser des API qui font autre chose, c'est ton problème mais plus celui de la norme.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à 1.
Le probleme est quand ce meme code se met a allouer 2Go sur un systeme qui ne peut en allouer que 4 au grand maximum et qui en realite n'en a que 3 ou 2 de disponible en allocation pour un processus, sans compter ce que le systeme utilise et qui reduit et fragmente la quantite disponible.
--> Tu passes d'une allocation qui est 16 ou 256x plus petite que l'espace d'addressage, a une qui est 2x plus petite que l'espace d'addressage, et tu passes d'une tres tres grande chance d'avoir une allocation reussie, a quasiment aucune.
Tu le vois toujours pas le probleme ?
La difference avec les autres langages, c'est qu'avec eux, ta taille d'allocation ne change pas, elle est constante quel que soit le systeme, des surprises du genre tu n'en as pas, si ton code tourne sur un 80x286 avec 16Mo de RAM, tu sais qu'il tournera sur un P4 avec 2Go de RAM, avec le C ce n'est pas le cas.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
C'est totalement idiot comme affirmation. Le passé l'a montré : Java a déjà évolué de nombreuses fois, et si le besoin se fait sentir demain d'indexer un tableau avec un long, aucun doute qu'il évoluera dans ce sens, et ca va pas casser grand chose.
Si je veux juste "un nombre sur lequel ma machine peut faire des opérations arithmétiques" (l’immense majorité des algos),
L'immense majorité des algos ont besoins d'être bornés, tu connais beaucoup d'algo générique qui marche quelque soit la taille d'un int ?
int et int32_t, ce n’est pas _du tout_ la même chose sémantiquement,
On est d'accord, mais le int existe, est dans la norme, et est beaucoup trop dépendant de la machine pour qu'il soit considéré comme non portable pour la majorité des codes qui l'utilise.
unsigned int rgbaColor = 0xdeadbeef, c’est une hérésie, que ce soit en C ou en Java
C'est absolument pas une hérésie en Java, la taille des int est garantie, et tu peux compter dessus.
Relis mon exemple. Tu ne l’as pas compris.
Tu essaies de nous démontrer que ca a un intérêt pour un algo de voir ses possibilités décuplés parceque demain la taille de ses pointeurs ou de ses int va augmenter. C'est totalement ridicule.
Le seul intérêt qu'il y a à manipuler des int, c'est pour une question d'optimisation puisque celà correspond à la taille des données manipulées nativement par l'UC. Ce qui montre bien que celà n'a strictement rien de portable.
Le C, c'est un compromis entre portabilité et performance.
il n’y a pas un langage plus ou mois portable qu’un autre entre Java et C
Bah si : en Java, quelque soit l'architecture sur laquelle tu tournes, ton algorithme aura toujours les mêmes bornes, toujours le même comportement et toujours le même résultat.
la sémantique générale de l’algorithme multiplyByTwo est préservée
Si tu définies la sémantique comme étant celle exprimée par la construction syntaxique en C, effectivement elle sera préservée. Le risque, c'est que la sémantique qu'a voulu donner le programmeur avant de le traduire en C, elle peut en prendre un gros coup dans l'aile.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
int* fib = stackalloc int[Int32.MaxValue];
[^] # Re: Bonne nouvelle
Posté par daimrod . Évalué à 3.
C = lego
my 2 cents...
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Non. Même les gros noobs savent que int et size_t ne sont pas forcément le même type.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Alors il faut se demander pourquoi ce langage "inutilisable" est le plus utilisé?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à 0.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Tu es le seul zoulou à faire des malloc(INT_MAX).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 1.
Cool, t'iras expliquer a Google qu'ils sont incompetents.
Et t'iras expliquer a Facebook que leur gars qui ont deploye hadoop et leur permettent de gerer un demi millard d'utilisateurs sans broncher sont des incompetents.
Merci de me traiter d'incompetent aussi, pourtant ma boite sert 20 millions de visiteurs uniques par mois, a se demander comment des incompetents pareils peuvent faire un truc qui marche!
En somme, si je te suis:
- Si c'est simple, c'est forcement mal. Probablement que ca ne doit pas brosser ton besoin de te prouver qq chose dans le bon sens.
- Si c'est complique au point que le tooling devient impossible a implementer alors c'est bien. Forcement, ca doit te permettre de te faire mousser devant tes potes a la fac.
Et donc:
Il vaut mieux un truc complique que peu peuvent utiliser et que meme ces peu qui peuvent l'utiliser ont du mal avec parfois.
Plutot qu'un truc simple que les neuneus peuvent utiliser sans trop de problemes et que les mecs competents peuvent utiliser pour liberer leur temps de cerveau pour faire des applications massives
Ce qui me fait le plus marrer la dedans, c'est que tu vas probablement venir te gargariser dans un autre thread des concepts unix de base, genre "keep it simple, stupid".
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 1.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à 0.
Et ca en dit long sur toi et ton apport a ce fil de discussion et ce site en general.
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 3.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 0.
Je comprends que ca caresse ton ego de tout faire a la main, mais le but du jeu c'est de produire des applis, pas de se mesurer la quequette a base de ki k'est le plus hardcore.
Je sais pas c'est un peu comme si tu disais: "les chaines de productions modernes, c'est a chier, un ouvrier peu plus travailler avec simplement un marteau et un tournevis, il lui faut un paquet de machines".
On s'en fout que Java soit tres aride sans ide, vu que tout le monde d'a peu pres sain d'esprit en utilise un.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
L’API J2** a évoluée, le langage Java a vu des fonctionnalités ajoutées. Par contre, je n’ai pas vu des fonctionnalités du langage modifiées (ce que serait « bon en fait on s’est planté, les long comme indice d’un tableau, c’est valide… J’aimerais bien voir d’ailleurs comment ils feront pour faire cohabiter les programmes dont le bytecode contient des index de tableaux en int et des index de tableaux en long, mais en même temps je connais pas le bytecode Java). Si tu as des exemples…
> C'est absolument pas une hérésie en Java
Si, de la même manière que new int[(int)math.PI] est une hérésie. Pour la n-ième fois, c’est pas parce qu’une constante marche « par hasard » qu’il est correct de l’utiliser. Si le type de ta variable nécessite sémantiquement une taille définie, tu l’explicites, sinon celui qui reprendra le projet dans 5 ans risque de se casser la tête (il voulait juste un nombre ou il voulait un conteneur pour 32 bits ? Je peux utiliser short pour réduire l’emprunte mémoire étant donné que maintenant on stocke des centaines de millions d’éléments ?)
> tu connais beaucoup d'algo générique qui marche quelque soit la taille d'un int ?
Heu, tous les algos de base pour la manipulation des structures de données : tables de hashage, graphes & arbres, liste chainées, tableaux, qui en pratique scalent selon la taille du type de base (pointeur pour les liste chainées, entier pour le tableau,…)
> Tu essaies de nous démontrer que ca a un intérêt pour un algo de voir ses possibilités décuplés parceque demain la taille de ses pointeurs ou de ses int va augmenter. C'est totalement ridicule.
En quoi c’est ridicule ?
[^] # Re: Bonne nouvelle
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 3.
Si je veux créer un tableau de 64 Ko, je fais un malloc(64*1024), pas un malloc(INT_MAX) parce qu’il se trouve que par le plus grand des hasards la constante matche.
De même, si je devais créer un tableau de 3 éléments, il ne me viendrait pas l’idée un seul instant de faire un new byte[(int)java.math.PI], même si ça fait ce que je veux.
Parce que bon, tu peux aussi faire un new byte[GetJVMName().getSize()] si par le plus grand des hasards la longueur du nom de ta JVM est pareil que la taille de ton tableau désiré.
Tu peux.
Ce sera juste pas portable et totalement crétin.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
Bah ca serait un ajout, pas une modification : le compilateur accepterait, en plus de la signature tab[int] la signature tab[long].
Pour la n-ième fois, c’est pas parce qu’une constante marche « par hasard » qu’il est correct de l’utiliser.
Ben en Java c'est pas un hasard.
Si le type de ta variable nécessite sémantiquement une taille définie, tu l’explicites, sinon celui qui reprendra le projet dans 5 ans risque de se casser la tête
Euh, en même temps t'as une alternative ? La norme Java ne défini pas de type dont le nom comporte le nomber de bits associés.
C'est le concept même des types "primitifs" : ils sont là pour stocker de l'information, à toi de structurer son accès avec une classe qui encapsule ces données.
Si t'as peur, tu peux même mettre un commentaire pour le futur.
Si t'es pas d'accord, propose moi une alternative à cette hérésie en Java pour stocker ta couleur.
En quoi c’est ridicule ?
C'est ridicule parcqu'une bonne pratique consiste, quand tu souhaites que ton algo soit indépendant d'un type, à mettre un typedef (à défaut de template ou de généricité).
Il est sémantiquement idiot, si ton algo se veut indépendant de la taille des données manipulées, de mettre "int" plutôt que "long" ou "patate".
[^] # Re: Bonne nouvelle
Posté par lasher . Évalué à 2.
int i;
...
for (i = 0; i < n; i++)
...
J'ai enseigné le C système à des élèves de L3, et je crois bien que j'étais le premier à leur faire remarquer qu'il y avait d'autres types entiers (size_t, long, unsigned...) que le simple type int.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Si C++ interdit la surcharge sur la seule base de la taille d’un type numérique, c’est pas pour rien : c’est très casse-gueule.
Mais bon, je pense (sans ironie) que je ferai mieux de me taire, je connais pas assez le fonctionnement interne des JVM ni même à quoi ressemble le bytecode Java (en dehors que c’est du bytecode).
> Ben en Java c'est pas un hasard.
Dans le sens de coïncidence, pas d’aléatoire.
> La norme Java ne défini pas de type dont le nom comporte le nomber de bits associés.
J’avais oublié ce détail (une des nombreuses raisons que je fuis Java, pourtant… mais si je devais toutes les retenir… mais on s’éloigne du sujet).
Effectivement, je vois pas de meilleure solution que d’encapsuler ça dans une classe et de mettre un commentaire.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Il est clair que quelqu’un qui a deux ans de « programmation » (comprendre : un DUT informatique) derrière lui, je le met pas dans un projet en C direct, sauf à mettre quelqu’un qui relit chacune de ses lignes derrière.
[troll]
D’ailleurs, c’est pas ça le principe d’un noob fraîchement diplômé, de se charger du code des projets Java-bateau, pour que les personnes plus expérimentées puissent se concentrer sur de vrais projets ?
[/troll]
[^] # Re: Bonne nouvelle
Posté par lasher . Évalué à 2.
#define TWO_GIGS 2UL * (1UL << 30)
int *array = malloc(TWO_GIGS);
for (size_t i = 0; i < TWO_GIGS; ++i)
array[i] = i; /* to force memory to be allocated */
foo(array);
Définis ensuite foo() quelque part dans une autre unité de compilation, pour être sûr que gcc ne va pas simplifier le code (ou compile avec -O0). Bref. Sur mon super core i7 au boulot, effectivement je risque d'aller très vite. Sur mon Core 2 de l'ancien boulot, ça va prendre un moment. Je le sais d'expérience.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
- temps de compilation interminable.
- lib standard anoréxique.
- comportements non définis ( initialisation statique, accès concurrents...)
- compatibilité binaire très difficile à maintenir.
- IDE et outils peu puissants.
Aujourd'hui un langage qui ne propose pas au moins aussi bien dans chacun de ces domaines ne vaut rien.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par lasher . Évalué à 2.
Je ne dis pas ça non plus. Je répondais juste au monsieur en haut qui disait que même un noob sait qu'il existe size_t. Peut-être bien, mais il ne comprend pas forcément (en fait la plupart du temps c'est même certain) comment sont définis les types, sur quels intervalles, pourquoi size_t est utilisé, etc.
« [troll]
D’ailleurs, c’est pas ça le principe d’un noob fraîchement diplômé, de se charger du code des projets Java-bateau, pour que les personnes plus expérimentées puissent se concentrer sur de vrais projets ?
[/troll] »
Malheureusement si, et ça me désole. C'est pas comme si faire des trucs immondes en Java c'était si dur que ça (je le sais bien, j'ai pratiqué en tant que stagiaire). La seule différence c'est que Java c'est censé être « bloated » de toute manière, donc y'a qu'à rajouter de la RAM au serveur, alors que C c'est censé aller vite donc si ça va pas assez vite, c'est le programmeur qui est en cause.
... Alors qu'en pratique un bon dév Java (disons un « expert ») devrait finir par connaître plutôt bien la JVM qu'il utilise, et donc savoir comment son code se traduit en bytecode, etc... Et donc, avoir une connaissance pointue d'une machine virtuelle là où en C on a une machine « concrète ».
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
A part se ridiculiser dans un troll, je ne vois pas :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Le problème ici c'est le codeur qui fait une opération débile.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Relativement au C, l’écart n’est pas tellement évident sur une machine récente.
(par rapport à du vrai C++ avec des templates de partout, par contre, je suis à 100% d’accord)
> accès concurrents...
Toujours indéfinis en Java, et dans tous les langages que je connais d’ailleurs.
> IDE et outils peu puissants
La plupart des IDE « puissants » sont multi-langage. Quant à des outils puissants, liés au langage, qui auraient contribué au succès de Java, je vois pas.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Et en Java, tu fais comment ?
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
http://mindprod.com/jgloss/endian.html
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Java ne te permet pas de stocker des classes directement dans un fichier (l’équivalent de write(fd, (void*)&myStruct, sizeof(myStruct)). Tu dois passer par une API de sérialisation.
Ben en C, pareil : si tu veux pas te prendre la tête, tu passes par une API de sérialisation. Ce sera plus lourd en C à cause du manque d’introspection, je te l’accorde.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Si c’est pour dire que .Net/Java a une librairie standard plus fournie, j’étais au courant avant.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 Moonz . Évalué à 3.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à 1.
a) est disponible sur toutes les plateformes que tu veux
b) est utilisable du point de vue de la licence
Avec le framework du langage, c'est simple la question ne se pose pas.
Avec C, vu qu'il n'y a justement pas de framework, ben faut bien chercher et esperer avoir de la chance.
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 1.
Et ca marche!
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 3.
La difficulté est d’obtenir l’offset en fonction de l’alignement et tout. Tu fais comment en Java, sans les APIs de sérialisation ?
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 1.
La difference c'est qu'en C, faut penser au fait que ton int ne fait pas necessairement la meme taille partout, et donc au niveau du format standardise sur une certaine taille.
La ou en Java ou C#, tu dit write(int) et read(int).
Ton write(int) en C n'est plus un write(int), mais write4bytes(int).
C'est un exemple simple, mais comme il parait que C est portable, pourquoi est ce qu'on a besoin d'y penser?
Si tu contentes d'outputter ton int de 16 bits et que tu cherches a le lire ensuite sur une machine ou l'int fait 32 bits, tu vas avoir comme qui dirait des soucis.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par Alex . Évalué à 1.
[^] # Re: Bonne nouvelle
Posté par Littleboy . Évalué à 2.
- endianess
- taille des types int/word/double/etc.
- alignement memoire (si tu veux lire a un offset dans ta structure, selon le compilateur et l'architecture, tu peux avoir un padding different...)
Tout ca est evidemment gerable en C, mais ce qu'on repete depuis le debut, c'est que:
- c'est relativement complique
- cela necessite beaucoup plus de code (ou de se trimballer un framework expres pour comme le font beaucoup de projets portables)
- on doit garder en tete des details d'assez bas niveau si on veut pas se planter
- les gens qui viennent nous expliquer que c'est trivial et que portabilite == respecter la norme ANSI sont de petits rigolos qui n'ont justement jamais eu a ecrire et maintenir du code de ce genre.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Si ton but c’est de faire un write((void*)&myStruct) parce qu’on peut le faire et que ça a l’air funton compilateur t’engueulera pas si tu le fais, oui.
Si ton but c’est de faire un truc qui juste marche, non, même en ANSI C : tu spécifies ton format de fichier et tu mets noir sur blanc l’endianness et la taille. Pas de problème d’alignement si tu fais pas un read((void*)&myStruct) mais que tu fais champ par champ. Oui, on sait : Java l’a fait pour toi. Mais la question « battery included » ou pas est orthogonale à la question « portable ou pas »
Et je te signale que tu entres ici dans la question de la portabilité des API, question que tu avais admis toi-même qu’elle était peu pertinente, tellement il est simple de faire non portable dans la communication avec l’extérieur.
> cela necessite beaucoup plus de code
Pas beaucoup non
write32(int32): 2 lignes (1 ligne pour le write, 1 ligne pour le htonl).
int32 read32(): 3 lignes (1 ligne pour le read, 1 ligne pour le ntohl, 1 ligne pour le return).
Le truc vraiment chiant à gérer c’est la représentation des flottants par contre, là je t’accorde que ce sera un peu plus que 5 lignes. Mais ce sera pas 3000 lignes non plus.
Bon, pour faire propre, double le nombre de lignes pour la gestion des erreurs.
> ou de se trimballer un framework expres pour comme le font beaucoup de projets portables
Parce que J2SE, c’est pas un framework peut-être ?
[^] # Re: Bonne nouvelle
Posté par Littleboy . Évalué à 1.
Dans mon cas, je dois acceder aux donnees par offset (pour recuperer au choix int32, int16 et byte). Donc meme en lisant les donnees champ par champ lors du chargement depuis le disque, j'ai quand meme des problemes d'alignement lors d'un access ulterieur si je ne fais pas attention et que je ne rajoute pas des #pragma pack autour de ma structure (le padding depend de l'architecture et du compilateur...).
Mais la question « battery included » ou pas est orthogonale à la question « portable ou pas »
La question est depuis le debut portable facilement ou pas...
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
Ce n'est pas un problème d'API : on parle bien de la définition du langage. Le C te permet de par sa grammaire d'obtenir des résulats différents d'une machine à l'autre là où le Java ou C# ne te le permettent pas. Ce n'est pas un comportement différent de l'API : le problème vient bien de la trop forte liaison entre les types primitifs du C avec l'architecture hardware, les I/O fichiers binaires ne sont qu'un révélateur, les API spécialisés en C ne sont là que pour cacher les lacunes natives du langage. Java ou C# n'utilises pas des API pour régler le problème, mais définissent une machine virtuelle qui constitue une véritable abstraction de l'hardware, et ouvre donc la voie à une portabilité totale du code qui le cible. En fait le C# et Java ne sont pas du tout portables : ils ciblent avant tout une seule machine, avec une architecture bien précise. L'astuce consistant en fait à porter cette machine qui est une machine virtuelle pour obtenir la portabilité de tout ce qui tourne au dessus.
dans la communication avec l’extérieur.
Peut-on vraiment parler de communication avec l'extérieur ? Le fichier ne voit pas sa structure modifiée lorsque tu le changes de machine. Par contre le comportement de ton programme, si.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Ben si, la preuve : tu as des APIs en dehors de la librairie standard pour te faire de la serialisation. Toujours pas aussi simple à utiliser qu’en Java, certes, mais ça a plus à voir avec l’absence d’introspection.
> Ce n'est pas un comportement différent de l'API
Ben si.
Avec la librairie standard du C, tu peux écrire tout et n’importe quoi librement. Et si un programme essaie de lire au petit bonheur la chance un truc écrit au petit bonheur la chance par un autre programme, ça a effectivement de fortes chances de pas bien se passer. Pour que ça fonctionne, tu dois définir correctement le format d’échange (endianness, taille des entiers, format des string, format des flottants,…). C’est quelque chose que les ingénieurs de Sun ont fait quand ils ont défini l’API de sérialisation, c’est quelque chose que C s’est refusé à faire (parce que c’est pas son boulot de faire des trucs haut niveau, parce que C a besoin de communiquer avec du non-C, et surement d’autres raisons que j’ignore).
C’est pareil en Java : si tu essaies de faire un dump mémoire dans un fichier et de reloader brutalement ce dump mémoire sur une autre architecture, il y a de fortes chances que ça marche pas. La différence entre C et Java, c’est que le premier t’autorise à faire ça (en cohérence avec sa philosophie : le langage est pas là pour penser à la place du programmeur, et il y a des situations où faire une telle chose est tout à fait correct) et que le second ne t’y autorisera jamais.
Objective-C, en tant que langage, est exactement dans la même situation que le C à ce niveau (taille de l’entier qui varie, endianness, alignement, etc). Pourtant, OpenStep/Cococa a défini une API et un format d’échange, comme Java, et bizarrement, on ne voit personne pour pleurer sur la non-portabilité d’Objective-C et des plist.
Non, franchement, dire que le C n’est pas portable sous le prétexte que je peux pas charger brutalement le contenu brut de la mémoire d’une architecture vers l’autre (ce que tu fais quand tu fais un write+read direct de tes structures, hein), c’est un peu pareil que dire que Java n’est pas portable parce que je peux pas faire un core dump d’un programme tournant sur la JVM sun et charger ce core dump dans une autre JVM et que le programme puisse continuer sans rien remarquer.
tl;dr : quel que soit le langage, si tu veux être portable, tu dois définir un format d’échange, la seule différence entre Java et C étant qu’en Java tu as un format défini direct dans l’API standard.
> Peut-on vraiment parler de communication avec l'extérieur ?
Ben oui, quand tu communiques avec quelqu’un d’autre que toi (toi = fork(), en gros), tu dois faire gaffe : définir un format d’échange, et ne pas te contenter de lui balancer un dump mémoire à la gueule en le laissant se démerder. Si Java n’a pas ce problème, c’est parce qu’il n’autorise tout simplement pas à balancer un dump mémoire ([troll]c’est la résolution des problèmes selon Java : si une fonctionnalité peut potentiellement être mal utilisée, on la supprime[/troll])
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
On s'en fou, t'es pas obligé de les utiliser, tu peux faire ta propre sérialisation si ça t'excite.
Ce qui importe, c'est que les API de sérialisation peuvent faire confiance à la JVM qui te garantie l'endianess, la taille des types primitifs, l'alignement : ces API seront portables.
En C, les API sont obligés de faire du cas par cas en fonction de la plateforme cible.
Et si un programme essaie de lire au petit bonheur la chance un truc écrit au petit bonheur la chance par un autre programme,
On te parle d'un même programme, le même code source, mais sur 2 plateformes différentes : le programme ne pondra pas le même binaire et ne lira pas le binaire de la même façon. C'est bien un problème de portabilité du code qui a des comportements différents suivant la plateforme sur laquelle il est compilé/exécuté.
si tu essaies de faire un dump mémoire dans un fichier et de reloader brutalement ce dump mémoire sur une autre architecture, il y a de fortes chances que ça marche pas
Le langage/la JVM ne te permet pas de le faire, justement parcque ce n'est pas portable : Java ne t'autorise qu'à faire des trucs portables là où le C te permet de faire des trucs non portables.
c’est la résolution des problèmes selon Java : si une fonctionnalité peut potentiellement être mal utilisée, on la supprime
Bah oui, c'est ce qui permet d'obtenir des garanties en terme de portabilité, de sécurité. Au détriments d'autres aspects on est d'accord.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Ce qui ne revient pas au même que de dire que le C n’est pas portable, nom d’une pipe en bois !
Encore une fois, c’est pas parce que Java n’est pas un langage à preuve formelle qu’il ne permet pas de créer des programmes corrects… si tu fais gaffe.
Si c’est juste pour dire que le C est un langage beaucoup, beaucoup moins neuneu-proof que Java, je suis d’accord.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
Je crois qu'au fond on est d'accord, le problème c'est que le commentaire initiale qui a conduit à cette dicussion disait explicitement que tout code écrit en C était portable, ce qui est largement faux, bien au contraire. Il faut mieux se dire : le C n'est pas portable, j'ai intérêt de faire gaffe à éviter toutes les constructions du langage qui ne le sont pas si je veux un code indépendant de la machine ; que de croire, comme l'exposait nicolas, ce que lui ont dit ses professeurs : "le C est portable, il a été conçu pour, j'ai jamais eu de problème, donc c'est vrai".
Si c’est juste pour dire que le C est un langage beaucoup, beaucoup moins neuneu-proof que Java, je suis d’accord.
C'est plutôt pour dire : warning, si vous voulez faire du code portable, le C n'est pas forcement le plus adapté car il demande un certain nombre d'effort pour y arriver, sans aucune garantie au final, d'autres langages t'offre des garanties et ont vraiment été conçu dans ce sens.
Sans parler du fait qu'on parle d'une seule forme de portabilité, celle du source : le langage C implique pourtant la compilation dans un binaire qui n'est pas portable, qui ne garantie pas l'interopérabilité binaire entre compilateurs, etc. Autant de problématiques plus ou moins liées qui ont conduit à la création de langages comme Java ou C# : de vrais abstractions du matériel (avec d'autres inconvénients on est d'accord).
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 3.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
En même temps, si tu t’amuses à faire des malloc(-1), je suis pas sûr qu’on puisse dire que ce soit la faute du langage si ça te pète à la gueule.
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 1.
Et la, t'as beau utiliser sizeof, bonne chance pour t'en sortir.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
Imagine que tu codes un logiciel qui a une feature dont la capacité dépend d'un int : tu vas dire à ton client "oui bah euh cette fonctionnalité dépend de la machine sur laquelle vous exécuter le logiciel... J'ai un tableau à 6 colonnes et 8 lignes pour les différentes situations si vous voulez".
INT_MAX ne change rien au problème : sa valeur diffère elle aussi d'une plateforme à l'autre.
En Java ou en C#, Integer.MAX_VALUE ou Int32.MaxValue sont des constantes qui ont toujours les mêmes valeurs, sur toutes les plateformes : bref le code associé aura toujours le même comportement et le résultat sera prévisible : le code est bien portable.
Pour celà, ces langages définissent une véritable abstraction de la machine physique, une machine virtuelle. Le C, par définition, autorise les optimisations bas-niveau qui dépendent du hardware : le C n'offre pas, par définition, la garantie d'un code portable, c'est au codeur de s'en assurer.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Ha, parce que évidemment, dans le monde .Net/Java, on entend jamais « votre machine là, elle est pas assez puissante pour faire tourner cette fonctionnalité ».
> sa valeur diffère elle aussi d'une plateforme à l'autre.
Ben oui, évidemment, si tu fais un srand(INT_MAX) et que ton logiciel dépend des nombres sortis par ton peudo-RNG, sûr que le comportement diffèrera d’une plateforme à l’autre.
En dehors de ce cas, j’ai quelque difficultés à voir un code qui change ses fonctionnalités du tout au tout selon la valeur de INT_MAX (et sans erreur de programmation « mais non c’est du code tout à fait normal » à la malloc(INT_MAX)). Mais peut-être est-ce juste mon manque d’imagination ?
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
Vaguement drôle, mais y dit qu'il voit pas le rapport.
Mais peut-être est-ce juste mon manque d’imagination ?
Je me suis fait chier à pondre des liens plus haut sur les bonnes pratiques en matière de portabilité du code C, avec des exemples concrêts.
Si t'as pas d'imagination, google est ton ami, exemples :
http://webcache.googleusercontent.com/search?q=cache:liqP32f(...)
http://docs.hp.com/en/5921/portability.html
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Le rapport, c’est qu’à part la quantité de données que sera capable d’ingurgiter le programme, je vois pas ce que la taille des entiers change au niveau fonctionnel.
> Si t'as pas d'imagination, google est ton ami, exemples :
Ceci ne sont pas des exemples de fonctionnalités qui changent selon la taille d’un entier. Ce sont des listes de bonnes pratiques. Comme il y en a dans tous les langages — si tu les suis pas, vient pas pleurer si ton programme te pète dans les mains.
Encore une fois, ce que je te demande, c’est une fonctionnalité bien codée dont le comportement dépend de la taille d’un entier. Parce que si c’est juste pour dire qu’on peut faire du code pas portable en C en faisant n’importe quoi (genre caster un int en pointeur et vice versa), on était au courant, merci.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
Bah c'est déjà un gros changement... Et je vois toujours pas le rapport avec les limitations de ressource mémoire disponible.
Ce sont des listes de bonnes pratiques. Comme il y en a dans tous les langages — si tu les suis pas, vient pas pleurer si ton programme te pète dans les mains.
Trouves moi un guide qui parle de portabilité de code Java (qui parle du langage, pas d'API spécifiques style accès au système de fichier).
C'est quand même fort : "le code ANSI C est toujours portable" et après "évidemment faut suivre des bonnes pratiques sinon faut pas venir pleurer".
Encore une fois, ce que je te demande, c’est une fonctionnalité bien codée dont le comportement dépend de la taille d’un entier.
Evidemment ta question est tourné à ta façon : si je trouve un exemple, tu vas dire que la fonctionnalité est mal codée. Tu ne fais que justifier ce que je dis depuis le début : en C, la portabilité du code dépend de la compétence du développeur car la norme en soit ne garantie pas un code portable, au contraire d'un code Java par exemple.
Après tout, on peut aussi dire que le C est un langage à typage fort : après tout, si y'a des erreurs de typage, c'est parcque le programmeur il code comme les pieds.
Après tout, on peut aussi dire que le C est un langage totalement secure : si y'a des débordements de tampon ou des dereferencement de pointeurs null, c'est la faute au programmeur, il a qu'a bien coder.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
J’ai une mauvaise nouvelle à t’annoncer : depuis le début, tu te bats contre un homme de paille.
Qui ici a dit que le C était toujours portable ?
> si je trouve un exemple, tu vas dire que la fonctionnalité est mal codée.
Ben voyons. Dire que caster les void* en int et vice-versa c’est mal coder (c’est un des premiers exemple de ton lien), c’est être de mauvaise foi ?
J’en déduis donc que chez toi c’est une bonne pratique de caster les pointeurs en entier ?
> car la norme en soit ne garantie pas un code portable
Je crois que tu n’as pas compris un truc. C est un langage qui a comme principe d’être très laxiste, qui t’autorise à faire d’énorme conneries. Java est un langage au contraire beaucoup plus strict. Donc oui, tu peux faire d’énormes conneries qui t’empêcheront d’être portables en C et pas en Java. De là à dire qu’un programme écrit normalement en C n’est pas portable, il y a un gouffre que je ne peux voir franchi sans réagir.
Je vais te faire une image : Java ne peut pas te garantir formellement que ton programme est conforme à sa spécification (le C ne peut te garantir la portabilité), contrairement à certains langages issus de la recherche. Quelle est la bonne chose à en déduire ?
- Java ne permet pas de faire du code correct (le C n’est pas portable)
- Si tu veux réussir à remplir ton cahier des charges, il faut suivre des bonnes pratiques (si tu veux être portable, il faut suive des bonnes pratiques)
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
Toi je sais pas, mais nicolas:
"Quand j’écris un code ANSI C il doit tourner et rendre le même résultat quelque soit la machine le supportant"
Ou encore :
"Le C est portable, oui,"
"parce que précisément le C est portable"
- Java ne permet pas de faire du code correct (le C n’est pas portable)
J'ai jamais dit que le C ne permettait pas de faire du code portable.
si tu veux être portable, il faut suive des bonnes pratiques
En C oui, en Java, non. (je parle strictement du langage).
[^] # Re: Bonne nouvelle
Posté par lasher . Évalué à 2.
Tu es sûr de toi ? Si je regarde la norme, je ne vois qu'une relation d'ordre entre les types, et c'est tout:
char <= short <= int <= long
sizeof(char) == 1 (même quand un char tient sur 16 bits)
Si ensuite tu rajoutes la norme POSIX (toujours dans mes souvenirs), alors
sizeof(long) == sizeof(mot mémoire) == sizeof(void *)
sizeof(int) >= 32 bits
[^] # Re: Bonne nouvelle
Posté par nicolas . Évalué à 2.
« 2.2.4.2 Numerical limits
A conforming implementation shall document all the limits specified
in this section, which shall be specified in the headers <limits.h>
and <float.h> .
"Sizes of integral types <limits.h>"
The values given below shall be replaced by constant expressions
suitable for use in #if preprocessing directives. Their
implementation-defined values shall be equal or greater in magnitude
(absolute value) to those shown, with the same sign.
[...]
* maximum value for an object of type int
INT_MAX +32767 »
[^] # Re: Bonne nouvelle
Posté par Tonton Th (Mastodon) . Évalué à 3.
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à -1.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par nicolas . Évalué à 3.
Qui-qu’a la plus grosse ?
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 2.
Oui, et?
Si tu veux des urls sans rapport avec le sujet, ya un randomizer sur la home page de wikipedia.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 3.
Personnellement, en C, je peux faire du code qui tourne sans modification sur mon PC et le MSP430 (je l’utilise pour faire des routines que je peux tester sur mon PC, c’est plus simple de débugger sur un PC que sur un MSP430). Java, il tourne sur un MSP430 ?
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à -1.
Le code machine, ca tourne partout, par definition, donc le code machine est le langage le plus portable au monde?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 3.
On a trouvé une fortune plus grosse que le malloc(INT_MAX) de pBpG là !
Le code machine ne tourne pas partout, non (que ce soit l’assembleur ou le code binaire résultant), et c’est précisément pour cette raison que deux gus dans leur garage (Dennis Ritchie et Kenneth Thompson) ont inventé un langage portable qui puisse être traduit dans ces langages non-portables.
> Ca devient du grand n'importe quoi la...
Je confirme. Je ne sais pas d’où m’est venue cette idée saugrenue que la portabilité pouvait avoir un vague rapport lointain avec le fait de pouvoir faire fonctionner le même code source sans modification sur deux architectures aussi différentes que le x86-64 et le MSP430, vraiment.
Désolé de t’avoir faire perdre ton temps avec une idée aussi stupide.
Sur ce, excuse-moi, mais je dois aller modifier mon dictionnaire pour redéfinir « portable » comme « langage tournant sur une machine virtuelle, mais impossible à faire tourner sur une architecture sur laquelle ladite machine virtuelle n’existe pas ».
[^] # Re: Bonne nouvelle
Posté par Erwann . Évalué à 3.
Malheureusement c'est faux. Au boulot, j'utilise pas moins de 3 JVM différentes (Sun/Oracle, IBM et Microsoft) et les applis qui fonctionnent sur une des JVM ne fonctionnent pas sur les deux autres. C'est très commode.
[^] # Re: Bonne nouvelle
Posté par Tonton Th (Mastodon) . Évalué à 2.
Merci de votre soutien (cTMr)
[^] # Re: Bonne nouvelle
Posté par Tonton Th (Mastodon) . Évalué à 5.
Là, ce n'est clairement pas la faute du C, c'est juste que l'application a été écrite avec les pieds, et même peut-être en gardant les charentaises.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 Tonton Th (Mastodon) . Évalué à 8.
Ah ah ah !
Je juste lole et me rotf-myself-ise !
Figures-toi que le C a justement été conçu pour porter Unix sur des plateformes diverses et variées, alors bon, camembert !!!
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 nicolas . Évalué à 2.
⇒ Fortune ! :D
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Et s'ils mentent, ils vont enfer!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 2.
Mais cela ne couvre QUE les implementations de C#/.NET tel que decrit dans la norme ECMA c'est a dire 2 ou 3 generations derrieres les versions actuelles...
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ce n'est pas du tout évident. Existe-t-il seulement un texte de loi qui réglemente les promesses publiques?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 1.
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Non, ce n’est pas la même chose. Une licence est une contrat entre deux parties, une promesse publique n’implique pas d’autre partie au moment de son énoncé.
Après, je sais pas quelles sont les implications juridiques :)
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 1.
Ca depend potentiellement des etats, mais en californie un contrat oral a la meme valeur qu'un contrat ecrit.
Reste a prouver la parole, mais dans ce cas, ca va etre facile.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
Tiens on va prendre un exemple d'un langage qui s'écarte de la norme : Vala. Il est largement inspiré de la norme C#, et s'en écarte sensiblement sur certains points. Est-ce que celà gène ses utilisateurs ? Est-ce que les gens crient au FUD des brevets alors que justement Vala n'est pas protégé n'implémentant explicitement pas la norme ? Est-ce que ce langage perd de son intérêt ?
[^] # Re: Bonne nouvelle
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
C'est le seul lien, le reste est très différent, contrairement à Mono.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
Oui bah on parle de langage, c'est donc l'essentiel.
Et ma comparaison reste valable : si demain MS sort une version de C# qui sux, Mono peut "forker" et faire son bonhomme de chemin comme le fait Vala, ça lui enlèvera sans doute un intérêt mais la plateforme restera pertinente comme l'est Vala.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 3.
Mono est un logiciel libre, tu peux forker et faire ce que tu veux avec.
[^] # Re: Bonne nouvelle
Posté par daimrod . Évalué à 1.
> 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
C'est vrai que question compatibilité avec l'ancien Microsoft sait faire. Au hasard, MsWordX avec MsWordX+1 ou X+2 ?
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à -1.
Donc oui, même si c'est pas parfait, la compatibilité avec l'ancien est sans doute la préocupation majeure de MS, ce qui est d'ailleur un avantage et un inconvénient: maintient de vieilles API avec ce que celà implique en terme de sécurité, maintient de vieilles interfaces, avec ce que celà implique en terme de modernité, lourdeur dans les process de conception/développement (je suppose) pour tenter d'innover tout en gardant la compatibilité, etc.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 daimrod . Évalué à 3.
> Word 2010 t'ouvres toujours un fichier de Word d'il y a 15 ans avec une representation correcte si ce n'est parfaite.
Étonnant j'ai souvent entendu dire l'inverse.
> 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...
Un document latex écrit avec emacs a toujours le même rendu, merci bien.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 nicolas . Évalué à 2.
On s’en tape de la date de sortie du logiciel !
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 daimrod . Évalué à 3.
> 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)
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 ?
> Elle est bonne celle-la...
>
> Latex 2 est sorti en 1994, Latex 3 ? Toujours pas sorti...
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.
Et je serais vraiment supris de voir MsWord20XX ouvrir un document écrit avec le MsWord de 1983.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 daimrod . Évalué à 3.
Malheureusement non, mais je l'ai déjà vu.
> 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.
Si j'ai fait allusion aux packages c'est parce que tu sous-entendais que LaTeX était au point mort avec LaTeX 2, alors que bien qu'il n'y ai
pas de nouveau ajout au langage à proprement parler, les packages sont là pour apporter de nouvelles fonctionnalités.
[^] # Re: Bonne nouvelle
Posté par Tonton Th (Mastodon) . Évalué à 3.
Et alors ?
[^] # Re: Bonne nouvelle
Posté par daimrod . Évalué à 3.
Bah rien, c'est juste qu'il voulait parler de la compatibilité entre logiciels, dont certains sortis il y a plus de 15ans.
J'ai parlé de LaTeX, et il m'a fait remarquer que LaTeX 2 n'est sorti qu'en 1994 (donc pas 15ans) et que LaTeX 3 est toujours dans les cartons s'tout.
Par contre LaTeX date de 1985, quant au langage TeX lui est bien plus vieux, il date de 1977.
[^] # Re: Bonne nouvelle
Posté par ziliss . Évalué à 5.
> Et alors ?
Je crois qu'il ne critique pas le fait que Latex n'évolue pas. Mais plutôt qu'il veut dire que puisqu'on utilise la même version de Latex depuis 1994, c'est normal de ne pas avoir de problème de compatibilité. (C'est juste une façon un peu ironique de le présenter)
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 1.
Mais bon comme il doit parler de la perfection non pas au masculin mais a la microsoft cela ne veut pas dire grand chose.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 3.
> Word 2010 t'ouvres toujours un fichier de Word d'il y a 15 ans avec une representation correcte si ce n'est parfaite.
C'est faux et archi faux, comme je l'ai dit la situation est peut etre differente avec du microsoft ooxml mais avec le format doc c'est un pur mensonge car ce n'est pas possible.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 3.
Alors oui, la compatibilité ascendante n'est pas parfaite chez Microsoft, mais c'est clairement une volontée et un de leur atouts/inconvénients : ils traînent des boulets dans le code de leur logiciels, chose dont ne s'embarassent pas de nombreux logiciels libres.
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 0.
Deja qu'un document ODF est pas portable entre differentes suite implementant ODF, faut pas s'attendre a des miracles...
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par El Titi . Évalué à 3.
Le résultat est le même : si demain Iguaza veut mettre Gtk# dans le standard .Net, il peut pas.
Tu parles bien de Micel Iguaza, là ? :D
[^] # Re: Bonne nouvelle
Posté par lasher . Évalué à 4.
Tu veux rire j'espère ? Des compilateurs C++ y'en a tout un paquet (icc, les compilos de PGI, ceux de Sun, etc.). GCC a mis un sacré bout de temps de passer de « GNU C Compiler » à « GNU Compiler Collection ». Peut-être qu'il y a des dév de GCC dans le comité de standardisation de C++, mais qu'ils soient derrière GCC, ou un autre compilateur n'est absolument pas pertinent. Pas plus pertinent qu'être dev pour un autre compilateur en tout cas.
[^] # Re: Bonne nouvelle
Posté par zebra3 . Évalué à 3.
Ça permet d'avoir d'un côté un langage pas si mauvais (ce que je lis à droite et à gauche) et de l'autre de bonnes librairies et une bonne intégration.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 3.
Avantages sur Python : (au fait : PyGTK ? tkinter ? PyQt ? wxPython ? Chacun a ses spécificités, ses avantages, ses inconvénients)
- Typage statique, vérifié à la compilation
- Pas la peine de distribuer un interpréteur python avec toutes ses libs si tu veux distribuer ton soft sous Windows.
Avantages sur Qt :
- Plus haut niveau (garbage collector, pas autant de soucis de nature historique comme QString vs std::string vs char*/QList vs std::vector vs liste chaînée à la main,…)
Si je ne te liste que des avantages, c’est pas pour te faire croire que Mono n’a que des avantages, hein, mais qu’il y en a, et qu’on ne peut pas réduire Mono à « un Qt contrôlé par Microsoft ».
Je crois que tu réduis beaucoup trop le choix d’un framework à des critères politiques. Tu cites par exemple Python comme si techniquement Python ou .Net c’était kif-kif et que le choix était purement et uniquement politique, alors que c’est faux, rien que la différence typage statique/dynamique est d’une importance primordiale pour beaucoup de projets.
[^] # Re: Bonne nouvelle
Posté par lezardbreton . Évalué à 10.
Faut pas déconner, SUSE a apporté beaucoup au libre, notamment sur KDE. Tant que Mageia n'est pas au point, c'est la seule distribution qui y investit autant.
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 4.
[^] # Re: Bonne nouvelle
Posté par weonbin . Évalué à 7.
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 3.
[^] # Re: Bonne nouvelle
Posté par kowalsky . Évalué à 1.
[^] # Re: Bonne nouvelle
Posté par cerber . Évalué à 0.
Vu sous cet angle, ca ferait sense.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 6.
Donc MS va bientôt racheter HTC.
[^] # Re: Bonne nouvelle
Posté par Albert_ . Évalué à 2.
[^] # Re: Bonne nouvelle
Posté par lasher . Évalué à 5.
[^] # Re: Bonne nouvelle
Posté par oau . Évalué à 1.
[^] # Re: Bonne nouvelle
Posté par yellowiscool . Évalué à 1.
Un système avec des fonctionnalités orienté objet par exemple, ça pourrais à être pas mal.
Envoyé depuis mon lapin.
[^] # Re: Bonne nouvelle
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Bonne nouvelle
Posté par herve18 . Évalué à 2.
Un système avec des fonctionnalités orienté objet par exemple, ça pourrais à être pas mal.
Hurd ?
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: Bonne nouvelle
Posté par cerber . Évalué à -1.
Il y a un an, j'avais lu un article d'un ingé de Microsoft sur leur blog, qui parlait justement de cette possibilité.
Dommage que je n'ai pas conservé le lien...
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.
D'ailleurs, d'un point de vu professionnel, j'en serais vraiment enchanté, car pour l'instant, le support des platformes Windows est pour moi un enfer au quotidien.
Sans vouloir troller... ^^
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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: Bonne nouvelle
Posté par boq . Évalué à 2.
a) L'archicture Unix et Windows est deja quasiment la meme
A quel sujet plus précisément? Je suis dans le brouillard là.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 Alex . Évalué à 2.
On peut certainement faire les même choses sous windows et unix, ceci dit sous unix je trouve que tout est plus souple grace au contrôle DAC et au modèle tout fichier
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 3.
pipe() + fork() pour les IPC ? Les périphériques accessibles dans le système de fichier ? /proc et /sys ? Les liens durs ? Toute la configuration du système accessible dans le système de fichier et éditable par un éditeur de texte ?
[^] # Re: Bonne nouvelle
Posté par Littleboy . Évalué à 0.
Joli abstraction, sauf que dans la realite, ca fait longtemps que ca n'est plus le cas pour plein de peripheriques pour lesquels tu passes par une API differente (son, carte graphique). Du coup l'interet est tout relatif (voir contre-productif dans certains cas ou une API differente est necessaire pour que ca marche => son).
/proc et /sys ?
T'as la meme chose sous Windows, c'est juste que l'API est differente
Les liens durs ?
Euh???????
Toute la configuration du système accessible dans le système de fichier et éditable par un éditeur de texte ?
Idem, en theorie. En realite de nos jours, il faut aimer editer d'enormes blobs de XML (ou pire). Avec bien sur des emplacements differents suivant les distribs et des infos dispersees dans 2 ou 3 fichiers differents. Du coup tu passes soit par des utilitaires en ligne de commande ou par une UI et tu t'en tapes du systeme de stockage derriere.
[^] # Re: Bonne nouvelle
Posté par Alex . Évalué à 2.
T'as la meme chose sous Windows, c'est juste que l'API est differente
Mais là est bien tout la différence.
Toute la beauté d'unix vient de ce coté tout fichier, ce qui rend le système souple, facilement adaptable et simple à administrer
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: Bonne nouvelle
Posté par Littleboy . Évalué à 1.
Et a chaque fois on a droit a la meme chose!
Avec un compte ouvert en 99, tu dois pourtant savoir qu'il faut triturer un peu la verite pour arriver a dire que tout est fichier sous Unix...
Tiens, un peu de lecture:
http://lwn.net/Articles/411845/
Et la suite pour ceux que ca interesse:
http://lwn.net/Articles/412131/
http://lwn.net/Articles/414618/
http://lwn.net/Articles/416494/ (seulement pour les abonnes pour l'instant)
[^] # Re: Bonne nouvelle
Posté par Alex . Évalué à 2.
Dire que tout est fichier est évidemment un raccourci et une généralité, néanmoins cela représente bien l'utilisation que l'on a du système.
Avec un compte ouvert en 99
putain t'es salaud là, tu me files un coup de vieux.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 3.
ls /dev/snd
> T'as la meme chose sous Windows, c'est juste que l'API est differente
/proc et /sys ne sont pas une API mais des fichiers, c’est bien ça qui le rend unique.
Je peux y accéder avec les outils standard de mon système (find & grep pour trouver rapidement, tar pour envoyer ma config à quelqu’un qui me dépanne) sans avoir à aller chercher le 5ème agrument de GetDevicePropertyW sur MSDNAA.
> Idem, en theorie. En realite de nos jours, il faut aimer editer d'enormes blobs de XML (ou pire).
Dans ton petit monde Ubuntu/Gnome/KDE seulement. Sur mon PC et mon serveur, tout est configuré à coups de vim.
[^] # Re: Bonne nouvelle
Posté par nicolas . Évalué à 2.
Voilà c’était juste pour apporter une petite précision à ton commentaire (parce que de toute façon le commentaire parent est soit : un gros troll, soit quelqu’un qui n’a jamais réellement utilisé Linux car ce n’est pas possible d’en avoir une telle méconnaissance autrement).
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 . É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 daimrod . Évalué à 3.
> soft.
Avoir toutes les config dans des fichiers c'est quand même génial.
1/ Pour avoir la même configuration sur plusieurs postes il suffit simplement de recopier le ou les fichiers de config.
2/ Tu peux garder toutes tes config grâces à un CVS genre git, ce qui te permet de revenir à une config antérieur, faire
des tests, les partager très simplement, ...
3/ Automatiser la configuration, et activer/désactiver certaines options avec un simple script shell
(genre sed 's/machin=enable/machin=disable/' -i pwet.conf ou encore echo "machin=enable" >> pwet.conf)
L'avantage, c'est très clairement de se passer d'une API qui sera différente pour chaque soft et garder l'interface la plus
universelle qui soit: le fichier texte.
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 0.
et tu crois qu'ils la stockent ou la config windows et mac?
Partant de la, tes deux premiers points sont non pertinents. Bon, windows centralise tout, ca aide pas a assembler des bouts, c'est sur, mais c'est pas un probleme texte vs api dediee.
Ton 3 se fait trivialement sous macos avec defaults write/delete, et avec une semantique autrement plus forte que de manipuler aveuglement des bytes.
Genre ca permet de s'affranchir des 42 format de confs en cours dans le monde linux et des 25 paths possibles pour la conf.
Je connais pas windows, mais je doute qu'ils ne proposent pas une api systeme (donc identique pour chaque appli) pour manipuler la registry.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par daimrod . Évalué à 2.
> Partant de la, tes deux premiers points sont non pertinents. Bon, windows centralise tout, ca aide pas a assembler des bouts, c'est sur, mais c'est pas
> un probleme texte vs api dediee.
Je ne faisais pas une critique de la gestion de config de windows ou macos hein, je ne sais pas comment ils marchent. J'indiquais simplement les avantages
des fichiers textes, par rapport à un accès par un soft. Si tu peux y accéder avec n'importe quel éditeur tu peux facilement le sauvegarder/manipuler/...
Par exemple, je trouve gconf horrible, je préfère un fichier de conf par logiciel.
> Ton 3 se fait trivialement sous macos avec defaults write/delete, et avec une semantique autrement plus forte que de manipuler aveuglement des bytes.
> Genre ca permet de s'affranchir des 42 format de confs en cours dans le monde linux et des 25 paths possibles pour la conf.
Généralement les fichiers de conf sont dans /etc ou dans ton home (~/), après si on veut configurer un soft il vaut mieux la doc aussi...
Je ne sais pas quel est le format de confs de macos, mais tous les softs n'ont pas les mêmes besoins.
Entre configurer fetchmail ou procmail et apache ou postfix, bah c'est pas pareil.
Après il existe différents langage de script pour faire des choses un peu plus puissantes, comme lua.
J'aimerais aussi beaucoup que Guile, un dérivé de scheme, se développe d'avantage, et soit plus utilisé comme langage de configuration avancée.
> Je connais pas windows, mais je doute qu'ils ne proposent pas une api systeme (donc identique pour chaque appli) pour manipuler la registry.
Comme précédement. Le problème que je vois à l'API identique, c'est qu'elle n'est pas adaptée à chaque logiciel.
C'est chaque logiciel qui doit s'adapter à l'API. Il y a donc un manque de souplesse et de liberté.
[^] # Re: Bonne nouvelle
Posté par Frank-N-Furter . Évalué à 2.
En gros, c'est des fichiers XML (exempl: http://pastebin.com/RW8aMQut )
En ligne de commande tu as la commande defaults qui:
Defaults allows users to read, write, and delete Mac OS X user defaults from a command-line shell. Mac OS X applications and other programs use the defaults system to record user preferences and other information that must be maintained when the applications aren't running (such as default font for new documents, or the position of an Info panel).
http://www.manpagez.com/man/1/defaults/
Comme précédement. Le problème que je vois à l'API identique, c'est qu'elle n'est pas adaptée à chaque logiciel.
Pourquoi? Si le format de stockage est suffisamment souple (genre une paire clef/valeur) le logiciel a juste besoins de pouvoir lire/écrire/modifier ces pairs.
Depending on the time of day, the French go either way.
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 1.
D'ou l'avantage, une seule api pour acceder a la conf, et la serialization est laissee au systeme, dans le fond on s'en tampone, on veut juste recuperer une valeur.
Abstraction, separation of concerns, tout ca.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par pasScott pasForstall . Évalué à 0.
Comme tu dit generalement, a 2 endroits possibles. Potentiellement, ailleurs. Et ca change pour chaque distro, evidemment.
Le format du fichier passe son temps a changer aussi.
Ca peut etre du plain key/value, du [section] key/value, du xml, certains utilisent meme des csv (oui, ils sont tordus).
On sait pas trop quels encodage sont supportes, comment il faut echapper les chaines (ou s'il faut le faire tout court), ni quelles autres contraintes peuvent avoir les fichiers (taille de ligne, multiligne etc).
Et on a bien sur aucun typage, a savoir qu'une cle Date peut se faire affecter un booleen ou autre et tu le sauras qu'au runtime, potentiellement tard.
Apres, en pratique, ya une certaine tendance a bouger la conf vers du xml ce qui limite un peu ces problemes.
Face a l'avantage de pouvoir l'editeur de texte de mon choix, perso je prend le systeme robuste.
Comme précédement. Le problème que je vois à l'API identique, c'est qu'elle n'est pas adaptée à chaque logiciel.
C'est chaque logiciel qui doit s'adapter à l'API. Il y a donc un manque de souplesse et de liberté.
Ben une conf, c'est cle/valeur, j'aimerais bien avoir un seul exemple ou la registry windows ou les plist macos sont insuffisants.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 4.
Je peux faire dd if=/sda1 | gzip > /media/external-disk sous Windows ?
> La carte graphique ? Aucun Unix ne le fait
Plan9 (oui, je suis légèrement de mauvaise foi ;))
> 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
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.
> Vois pas trop en quoi cela fait partie de l'architecture
De l’architecture, philosophiquement en théorie, je sais pas, mais en pratique, je vois la différence entre /etc et la base de registres.
> et en quoi etre accessible par un editeur de texte est mieux qu'etre accessible par un autre soft.
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 vas me dire : « c’est simple, tu vas sur tel site de support de Microsoft, tu télécharges regedit-diff.exe, et ça marche, et en plus c’est graphique avec une interface kikoolol user-friendly à des années lumières de ce qui se fait sous Linux avec cette ligne de commande préhistorique. Seule ton incompétence sous Windows fait que tu sais pas faire ». Ben non, c’est justement mon argument : sous unix, je n’ai pas eu à découvrir et apprendre un nouvel outil. Je n’ai pas eu à faire un man etc-diff. L’outil standard marche sans me prendre la tête.
Et je peux faire pareil pour /proc et /sys. Pour windows, il me faudrait encore un n-ième outil, devices-diff.
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 Moonz . Évalué à 2.
J’avais essayé et ça m’avait explosé à la gueule, je sais plus pourquoi. L’ordre des clés qui différait entre deux exports peut-être, mais c’est vieux (Windows 2000 je crois), donc je me rappelle pas bien.
> Ben oui, et avec powershell aussi
Powershell ne fait pas partie du système chez moi.
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. Mais c’est pas grave, on est sur TrollFR. tl;dr: PowerShell est là pour prouver que :
- de base, on peut pas faire la même chose avec Unix et Windows
- l’approche Unix est suffisamment intéressante pour l’émuler au-dessus de l’approche Windows
Au fait, je peux faire vim sur une partie de la base de registre avec PowerShell ?
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 Moonz . Évalué à 1.
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).
> Ca veut dire quoi 'faire vim' ?
Éditer avec vim. Je peux faire "vim /etc/fstab". Je peux faire vim (manière d’accéder au registre en PowerShell) ?
[^] # Re: Bonne nouvelle
Posté par pasBill pasGates . É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 pasScott pasForstall . Évalué à -1.
Ca veut pas dire grand chose la.
Qu'il ya une couche d'abstraction ou pas, on s'en tamponne, tant qu'elle est fournie avec le systeme.
C'est le cas en l'occurence, ms fournit avec Windows les outils qu'il faut, Apple fait pareil avec MacOS.
A la limite, tant mieux qu'il ya ait une couche d'abstraction, ca evite de faire des conneries.
Le fait que tu puisses pas utiliser vi pour visualiser la registry est un non argument, sinon je vais te retorquer que je peux pas utiliser regedit pour visualiser la con' linux et que c'est un inconvenient.
Tu peux la scripter automagiquement, tu peux la bidouiller "en live" avec les outils fournis.
Par contre le fait que tu passes par une api dediee qui te garantit que tu vas pas foutre la chtouille dans ta conf, ca saybien.
Typiquement, probleme d'encodage de caracteres, fin de lignes, conversion type <-> texte ou toute autre contrainte de serialization.
Le fait que ca soit accessible via une api haut niveau evite par exemple de faire une boulette et de mettre un 0 la ou ca attends un false, ou inversement, plutot que de tout foutre en l'air a coup de sed.
Et tres honnetement, le fait de pas pouvoir utiliser sed et awk, je considere ca limite comme un avantage vu l'aride illisibilte de ces outils et leur cote casse gueule.
Cette approche etait probablement pleine de bon sens en 1978, mais l'eau a coule sous les ponts depuis.
Apres, on peut commencer a troller sur le cote centralise vs distribue, mais c'est un autre debat.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 1.
Euh, la mauvaise foi c'est plutôt ne pas vouloir considérer la réalité et se référer au passer quand ça nous arrange. Si PowerShell était sorti y'a 2 mois, tu aurais une excuse, mais PowerShell est sorti y'a 4 ans, il est maintenant intégré par défaut dans les déclinaisons serveur et desktop de Windows : ça montre juste ta méconnaissance du sujet sur lequel tu trolls.
Au fait, je peux faire vim sur une partie de la base de registre avec PowerShell ?
PowerShell, c'est par définition la même chose que la ligne de commande sous Linux mais en plus puissant : les programmes ne communiquent pas avec des pipes de données quelconque mais communiquent avec des données structurées : bref la même chose avec des métas.
[^] # Re: Bonne nouvelle
Posté par Moonz . Évalué à 2.
Ben non. PowerShell, c’est une couche d’abstraction, comme on l’a souligné.
vim, il travaille sur des fichiers, il utilise fopen & co.
Donc, je doute que taper "vim HKEY_CURRENT_USER\ma_clef" soit possible. D’ailleurs pBpG semble le confirmer puisque pour lui, « c’est complètement crétin de vouloir faire ça ».
Ergo : non, même avec PowerShell, tu ne peux pas faire tout ce que tu peux faire avec le shell Unix.
> ça montre juste ta méconnaissance du sujet sur lequel tu trolls.
Je ne nie pas. Juste que ce qui m’intéressait, c’était la comparaison entre le design « canonique » de Windows (tout est accessible par des handle avec les APIs qui vont bien) et de Unix (tout est accessible à l’aide de fichiers). Qu’on puisse faire des couches d’abstraction qui vont de l’un à l’autre, j’entends bien merci, j’avais pas besoin de troller pendant 3 jours pour le deviner. Que la couche d’abstraction « Unix-like » pour Windows soit maintenant fournie par défaut, je ne peux qu’applaudir des deux mains. Mais c’était pas ce qui m’intéressait.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . Évalué à 2.
Comme Bash est une couche d'abstraction au dessus de certains API Posix. Je te parle des fonctionnalités spécifiques aux lignes de commandes, bref de ses possibilités en ligne de commande.
Donc, je doute que taper "vim HKEY_CURRENT_USER\ma_clef" soit possible.
Le problème c'est que vim ne sait pas discuter avec l'environnement powershell et les objets qui y circulent. vim est trop lié aux API Posix.
Mais si tu as un éditeur qui sait le faire, c'est une ligne de commande qui est envisageable.
[^] # Re: Bonne nouvelle
Posté par Tonton Th (Mastodon) . Évalué à 2.
Loulz
[^] # Re: Bonne nouvelle
Posté par collinm (site web personnel) . Évalué à 5.
www.solutions-norenda.com
# Droits sur unix
Posté par vpinon . Évalué à 4.
Sinon, je vois pas comment un "mainmise sur unix" pas MS ne déclancherait pas tous les mécanismes antitrust...
Et puis il y a une telle économie qui repose sur unix (serveurs, embarqué de tout poil : google, nokia...) que c'est impossible que tout s'effondre comme ça ?
[^] # Re: Droits sur unix
Posté par Albert_ . Évalué à 4.
[^] # Re: Droits sur unix
Posté par pasBill pasGates . Évalué à 5.
[^] # Re: Droits sur unix
Posté par Albert_ . Évalué à 2.
De plus que l'on prenne dans le sens que tu suggeres les abus microsoft sont tellement legions que cette boite aurait du etre eclate depuis bien longtemps.
[^] # Re: Droits sur unix
Posté par pasBill pasGates . É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: monopole
Posté par franckd . Évalué à 2.
C'est sans doute l' ouverture des marchés , qui prévaut largement sur le marché intérieur, aux yeux des américains, qui a permis à Microsoft d'éviter une mise en accusation dans ce cadre, beaucoup plus que la loi elle même...
[^] # Re: Droits sur unix
Posté par Mathieu Segaud . Évalué à -2.
c'est plutôt pathétique en fait.
[^] # Re: Droits sur unix
Posté par claudex . Évalué à 3.
Le développement d'Unix ne s'est pas arrêter il y a 50 ans mais a continué bien plus longtemps (et continue encore pour certaines versions).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Droits sur unix
Posté par Jllc . Évalué à 2.
D'autant plus qu'il n'a commencé qu'il y a 41 ans (1969).
mais a continué bien plus longtemps (et continue encore pour certaines versions)
L'éclatement d'Unix en ses dérivés s'est fait essentiellement au début des années 1980 (moins de 30 ans).
# M'en fous
Posté par christophe vincent . Évalué à 9.
# Aidons nos enfants
Posté par trashit . Évalué à 3.
je voudrais ici livrer quelques remarques et commentaires, que ce soit pour le rachat (éventuel) de Novell ou autres.
Etant utilisateur de Linux depuis 16 ans, je peux vous dire que non seulement ce système ne m'a jamais déçu, mais, en plus, j'en trouve une quiétude dans son utilisation quotidienne a titre privé, comme au boulot.
Voici donc mes remarques :
- tous le monde sait que le but de Microsoft n'est pas de construire des logiciels fiables et performant mais qui
1) peuvent rapporter de l'argent à ces actionnaires et
2) musèlent bien l'utilisateur ce qui arrange certains gouvernement.
- dans les administrations par exemple, c'est une hérésie d'utiliser des logiciels Microsoft, tout d'abord pour le prix qu'ils coutent (je vous rappele que c'est notre pognon qui sert a cela), mais en plus du fait de la "non pérénité" de ces mêmes logiciels ils n'offrent qu'un panel limité de services possibles ... je vous le rappel : avec votre argent.
Etant informaticien depuis de nombreuses années et ayant fortement militer contre les brevets logiciels, je puis vous dire que notre génération (d'informaticien) est une génération de sacrifiés ! On nous vend au plus offrant, soi disant pour des raisons "d'européenisation", mais il ne faut pas se leurer, ceux qui produisent pas d'argent en gagnent beaucoup (et ils sont peu nombreux) alors que ceux qui produisent de l'argent n'en gagne pas en conséquence de leur mérite (et ils sont majoritaire).
- quand vous écouter les arguments de ventes des commerciaux, qui n'ont qu'un but , c'est vendre sans se soucier de la qualité de l'utilisateur, ils en arrivent très vite à des réponses du style "l'informatique linux c'est un monde d'anarchie", "60% des serveurs Linux et 100 % d'illètrés", ou le dernier en date, mon favoris (apès plusieur tentatives de sa part de faire passer les logiciels M$) "de toute façon, c'est le monopole qui compte".
Je n'ai jamais entendu un commercial me parler "réellement" de son soft.
Microsft rachete sans rien créer, renome sans rien inventer, musèle sans bruit. Nos gouvernement (encore une fois qui sont censé agir pour le bien du peuple et non des multinationales) ne se sont jamais opposé aux abus de position dominate (par Microsft entre autre). Demander comment se sont négocié les contracts logiciels pour la commission européenne il y a quelques années, ou pourquoi depuis 1995 les guichets des banques et autres vous répondent fréquement "désolé, nous ne pouvons vous répondre pour l'instant, notre réseau est en panne". Combien d'accord cadre ne sont pas signé entre les amdinistrations et Microsoft sans consultation ni même respect du cahier des charges et mise en concurence ? Ou plus simplement des "imposées" des administrateurs certifiés M$ dans des sociétés publiques en leurs faisant mirroiter des réductions sur le prix des licenses.
Tous ces exemples sont réels, et je suis sûre que si on crée une liste de tout cela ... Internet en devient saturé.
Soyons content d'utiliser Linux, c'est un beau système d'exploitation qui offre des possibilités quasi sans limite, mais avant tout : essayons de le faire pour nos enfants, c'est ceux ci qui auront la liberté (je veux dire "la vrai liberté") de travailler en informatique, nous avons été jeter comme des merdes par des politicards trop avide de se faire payer des vacances par ces grosses boites, sans comprendre où était le vrai bonheur des gens.
Tout le monde sait où est le problème (Aung San Suu Kyi ne pourra jamais rien faire dans son pays, elle ne pactise pas avec les multinationales) mais il faut une volonté pour y arriver, et là ...
[^] # Re: Aidons nos enfants
Posté par Florian.J . Évalué à 5.
Dans ma boite on utilise tous Windows, c'est pas un choix, c'est juste que les applications clients ne tournent que sur Windows (bientôt Mac OS X pour Autocad, mais ça vaut pas mieux à mes yeux).
Par contre on a un informaticien Linuxien, après des années d'un magnifique serveur Windows 2000, on est passé à un serveur Linux avec Zimbra pour le courriel et samba pour le partage de fichiers.
Ca a quasiment rien coûté à la boite, ça s'est fait de manière transparente (le renouvellement du matériel aidant également), les performances au rendez-vous.
Et que peut dire Microsoft ? Rien, ils ne sont pas compétitifs.
Par contre le plus triste est qu'on me demande souvent (en tant que geek/développeur de service) des choses genre "Comment je peux trier les messages par objet dans Zimbre, tu sais, comme Outlook... ?" ou encore "Tu sais comment je peux attacher un fichier excel/word/insérer autre format propriétaire monopolistique ?"
De même que malgré tous mes efforts la plupart des utilisateurs restent sur Internet Explorer, souvent la version 6 sur Windows XP...
C'est assez décourageant de se sentir obligé d'expliquer ce qui cloche, surtout qu'on peut/veut pas te comprendre, qu'est ce que ça peut bien f***tre, c'est qu'une application.
En plus les Linuxiens ne sont que des idéaliste illuminés, donc je parle souvent dans le vide.
Par contre, même si Linux est un système "discret" comparé à Windows et Mac OS X (qui lui fait beaucoup parler de lui pour la place qui est la sienne), il n'empêche que l'on peut être assuré que sont existance n'est pas menacée, loin de là.
Déjà le projet est plus actif que jamais, mais il a surtout un poid économique considérable, avec plein de grosses sociétés qui en dépendent à des niveaux variables et contribuent.
Donc même avec toute la volontée de Microsoft ou autre boites dans le même genre (Oracle, Hewlett packard ?), on aura toujours la libertée d'utiliser nos ordinateurs, j'en suis persuadé.
[^] # Re: Aidons nos enfants
Posté par trashit . Évalué à 3.
je n'ai pas dit que rien n'est fait, je dis que depuis le temps que les gens se plaignent du monopole Mircosoft et que si peu ne bouge ... on critique le prix, la lourdeur, les licenses ... mais quand on propose de jeter tout cela, j'ai une réponse assez classique "oui, mais on veut de la maintenance"
Etant administrateur systeme (Unix/linux) et développant mes applications sous Linux (avec une compatibilité complète entre les sytèmes), je sais que je n'ai aucun problème, ni de plantage ni d'interopérabilité et pour avoir fait des développemant pour des administrations (jusqu'en asie), le seul problème est que jen'ai pas de maintenance à faire ni de mise à jour à facturer. Je suis retourné dans une boîte après 7 ans pour des formations et des gestionnaires sont venus me trouver pour me dire que mes scripts datant de 2000 tournaient toujours.
De plus, ma remarque était aussi en regard du rachat d'une boite qui possède des technologies et des brevets par une boite qui ne pense qu'a se les appropriés pour l'entérer.
Quant a ta "liberté" de pouvoir utiliser un PC, souviens toi de TCPA.
Jettes un oeil sur http://kolab.org/
Bien à toi
[^] # Re: Aidons nos enfants
Posté par pasBill pasGates . É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: Aidons nos enfants
Posté par El_DreamMachine (site web personnel) . Évalué à -1.
Ça en fait du monde ! Un tas de gens clairvoyants autour de nous...
[^] # Re: Aidons nos enfants
Posté par trashit . Évalué à 1.
je te range donc dans ma catégorie favorite :
"de toute façon, c'est le monopole qui compte" (voir mon texte ci dessus)
# vmware
Posté par slamp . Évalué à 2.
Vmware a participe au rachat de Novell.
[^] # Re: vmware
Posté par Littleboy . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.