TImaniac a écrit 6420 commentaires

En comparaison, Microsoft gagne plus de 75 dollars par console XBox 360 vendue avec un disque dur de 20 Go.
Si, réduction des coûts toussa :
"Aujourd'hui une Xbox 360 coûte déjà bien moins cher à produire : environ 323 dollars pour le modèle Premium. Microsoft rentre donc dans ses frais, et gagne même 76 dollars par

Etant donné que Novell à passé un contrat concernant l'autorisation d'utiliser ses brevets avec Microsoft
Novell n'a passé aucun contrat l'autorisant à utiliser les brevets de MS. A la demande de MS, Novell a accepté de payer MS pour que ce dernier n'attaque pas ses clients pour des problèmes liés à des brevets.
Un truc classique américain : "file moi de la thune ou je t'envoi devant un tribunal". Bref, tu paie pour ne pas être poursuivi, c'est pas pour autant que tu passe un accord de licence t'aurisant à faire quelque chose. Là c'est juste une variante sur le même thème, MS ayant cibler les clients plutôt que Novell directement (ce dernier ayant les moyens de se défendre juridiquement) : "tu paies ou j'attaques tes clients".
Bref, il n'y a aucune licence d'utilisation de quoique ce soit, et la GPLv2 n'est pas "violée".

MS a également fait un communiqué dans la foulé, en précisant qu'ils sont d'accord sur le fait qu'ils ne soient pas d'accord :)
http://www.microsoft.com/presspass/press/2006/nov06/11-20Sta(...)

Les JVM stables et éprouvées (je suppose que celle du "constructeur", à savoir Sun est la première la catégorie), sont elles facilement portables sur un nouveau processeur si le constructeur met à disposition un compilateur C?
Il existe différentes JVM, dans différentes éditions, notamment pour l'embarqué (plus légères, etc.). Evidemment, si la JVM est portable, c'est avant tout parcqu'il y a dessous un compilateur C pour la compiler :)
Enfin si tu veux mon avis, l'intérêt de la JVM c'est d'être portable pour Java, pas d'être portable pour du C. Donc soit t'utilise la JVM, et t'en profite pour utiliser un langage de plus "haut niveau", soit tu garde ton appli en C qui est portable, sans cibler de JVM.

je m'intéresse maintenant à cette plateforme jusque là relativement inconnue.
C'est une plateforme très très connue en milieu professionnel.

Sont-elles stables? Ou sont-elles aussi sujettes à bugs, comme certains processeurs bien physiques?
Aucun soft n'est parfait, mais la VM de Sun est bien entendu stable (depuis le temps qu'elle existe elle peut bien :) ) et puis c'est plus facile à patcher qu'un processeur physique ;)

mais peut-être que quelque part il y aurait moyen de prouver la qualité de la machine/l'exactitude de la machine?
En théorie, oui, en pratique non.

le C semble être absent. Impossible à compiler et faire tourner sur ce genre de machine?
La VM de Sun a été conçue pour être utilisée avec le langage Java, orienté objet, c'est donc beaucoup plus naturel d'y intégrer des langages objets. Après on peut très bien s'amuser à faire tourner du C dessus, mais il ne faut pas espérer un niveau d'intégration profond. (exposer des API pour Java toussa). Exemple de compilo C vers JVM : http://www.axiomsol.com/

Je suis prêt à parier que mono va disparaître de gnome assez rapidement, si rien ne change ...
Bof. C'est quand même très frenchie cette réaction anti-mono suite à l'accord de Novell. Je sais pas si c'est très représentatif, mais en lisant les planet de gnome et ubuntu j'ai vu personne crier au boycot de mono comme certains le font ici. Pourtant certains n'ont pas hésités à gueuler sur l'accord de Novell, mais rien de particulier concernant Mono.
Bref, à mon avis concernant Gnome, ca ne va strictement rien changer, les risques ont déjà été évalués avant l'inclusion de tomboy, et, à par ici, j'ai pas lu grand monde disant que ca ai changé avec cet accord.
Et puis si on suit ton raisonnement, Gnome devrait virer tout le code écrit par Novell, pas seulement celui lié à Mono.

J'hésites encore, entre lui demander ce qui est le plus dangereux, entre se prendre un brevet sur la tête, un ruby dans le cul ou se faire bouffer par un python. Bash franchement je sais pas ce que java lui dire.
PS : la phrase précédente contient quelques perl, je trouve que c'est plus plus mieux. Quoi j'ai t'ai cassé ? Mon cul t'es pas plus drôle que moi. Ok j'arrête.

Cof cof. Hum. (Vocalises)
Faites chiez merde, c'est vendredi j'ai autre chose à foutre :)
Bon allez, petite tentative de discours enflammé aussi argumenté que le discours ci-dessus :

En même temps si vous avez suivez le long débat qu'il y a eu sur l'accord Novell/MS, on en déduit que globalement Mono n'est pas protégé par cet accord, à part au sein de SuSE comme tous les autres softs de SuSE.
Vous préférez utiliser une autre distri que SuSE pour ne pas cautionner les brevets logiciels, et préférez être dans l'insécurité juridique. Et bien assumez jusqu'au bout, puisque pour vous Mono ca viole des centaines de milliers de brevets, utilisez le ! C'est la meilleure façon de montrer que vous avez des couilles face aux brevets ! Combattez le FUD des brevets logiciels, combattez Microsoft, Mettez du Mono partout !

Quoi comment ca je fais de la récupération ?

Pour répondre au type au dessus : C'est sûr qu'il n'y a aucune communauté Mono. Si Novell lâche l'affaire (et tous les contributeurs de MainSoft, et tous les contributeurs libres-mais-pas-de-la-communauté), ca va devenir le nouveau Hurd du Logiciel libre. Belle consécration !

, windows met en avant la portabilité PARCE QUE des benevoles se sont crever le cul pour le porter, je trouve ca fort en café.
MS a surtout eu l'idée intelligente de concevoir son framework pour être portable : c'est une couche d'abstraction vis-à-vis du matos et de l'OS. Ils ont pondus des implémentations "shared-source" (pas libre, non-commercial uniquement toussa) pour montrer que c'est techniquement faisable. Donc .NET est portable parcque MS a décidé de le concevoir de la sorte. Commercialement ils ont préférés le garder pour leurs produits et ainsi y mettre une valeure ajoutée.
Mono apporte surtout le côté logiciel libre que MS ne veut évidemment pas faire.
Mais bon, revenons à nos moutons, et évitons de partir dans les trolls stériles.

Trés pertinnent quand le type de lgg que l'on veut utiliser s'en fout royalement de l'objet (par exemple lisp , ou prolog ou encore le C ...).
Evidemment, .NET n'est pas non plus adapté à tous les langages : c'est une plateforme multi-langages... objets.

Ah bon tu es sur ?
Tu sais la limites est flou, si tu considères qu'un navigateur web doit faire tout ce que propose le web, t'es pas rendu : tu peux faire des web-services, faire du WebDav, faire du protocole de chat, etc. Après ton navigateur peut vite devenir une usine à gaz. La limite, tu la fixes où tu veux, et c'est bien pour ca que la philosophie Unix est foireuse : si tu considère la brique élémentaire de base, tu fixes l'instruction assembleur. Ou alors tu fixes la limite là où ca t'arrange, suivant les besoins, le contexte, auquel cas la philosophie ne tient plus debout.

que cet attribut possede une fonction 'DownloadString' (pourquoi pas DownStr ou GetUrl ou ...)
D'où l'intérêt de l'autocomplétion : t'as pas à réfléchir à la syntaxe comme sous Unix ou si t'as le malheur de mettre une option "A" en minuscule "a" tu changes entièrement le comportement de la commande.

Et ton script tu le tape ou ? directement dans le shell, ou dans un éditeur de texte ou ... ?
Bah comme d'hab : dans le shell ou dans un fichier de script...

Globalement tu dis de belle connerie sans meme t'en rendre compte.
T'es gentil, mais argumente un minimum. C'était quoi pour toi la philosophie des pipes Unix à la base ?

Alors il est peut etre génial, mais c'est pas un shell.
Le powershell c'est un shell associé à un langage de script. Comme tous les shells Unix. Vois pas ce que tu cherches à démontrer. Appelle le powershell comme tu veux, le fait est que son intérêt est le même : administrer en ligne de commande, faire des petits scripts simples.

Quand je vois que certains propose une vm pour un shell, je me dis qu'ils n'ont pas compris l'intéret d'un shell.
Mouarf. Et quand tu proposes un exemple de script... t'appelle un langage interprété avec un modèle de machine virtuelle dessous : Perl.

Mais c'est pas ce que je demande a mon shell.
Faut bien voir qu'on adapte aussi ses besoins aux possibilités offertes par l'outil. Faut pas croire que l'outil est juste là pour répondre à un besoin, c'est le jeu de l'émulation. Je suppose que les mecs qui codaient en binaire avec des switchs sur les premières machines de bureau, ils trouvaient que les claviers et écrans ca servait à rien, c'est pas ce qu'ils demandaient à leur engin.

Le concours du nombre de ligne ne rime a rien, ce qui importe, c'est le temps et la fiabilité que tu auras mis a developper ton script.
Ben justement, c'est ce que j'ai voulu montrer : sans y connaître grand chose, la completion automatique du powershell permet de découvrir facilement les services offerts.
Question temps, t'es gagnant. Question fiabilité, tu manipules des données typées, c'est toujours plus fiable que non typées. Question lisibilité, on laissera chacun se faire une idée.

Ici, mon truc est portable. Qu'en est-il de ton script ?
Mouarf, tellement portable, que t'as bien précisé que t'avais pas wget sur ta machine, imagine que sur ma mache j'ai pas... perl. Super portable dis donc. L'intérêt du powershell, c'est de se baser sur le framework .NET qui propose un nombre conséquent de fonctionnalités, en standard.

Jusqu'a ce que ca emmerde les gens, et que quelqu'un fasse un portage.
Oué bah comme quelqu'un a dû faire le portage de perl & co. C'est exactement pareil. On a déjà une infrastructure .NET sous linux, il ne manque que le powershell. Le gros inconvénient c'est que c'est pas un LL, va donc commencer par falloir en faire une implémentation libre. Mais la portabilité n'a strictement rien à voir là dedans : c'est pas un problème technique mais un problème politique.
Après tiens ca me fait penser que Novell a passé un accord avec MS, pas que sur des questions juridiques, mais aussi pour bosser sur des technos facilitant l'administration de serveurs hétérogènes... Sachant que les technos mises en avant dans leur truc sont Samba, .NET mais aussi Mono (.NET portable), s'ils ont la même idée que moi...

Ben le framework .NET a quand même été conçu pour couvrir le maximum de fonctionnalités. Après si ce qu'il y a dedans te suffit pas, tu peux aussi le faire avec des applis externes. Tiens par exemple tu récupères cygwin (version windows de la plupart des outils ligne de commande de Unix), et hop, tu les exécutes dans le powershell :)
Je vois pas trop ce qui peut te manquer après !

me demande pourquoi Timaniac est sur linuxfr vu qu'il semble pas des masses utiliser un pingouin pour dire des trucs comme ca.
J'ai commencé à coder en C, et j'utilise Linux au quotidien chez moi. Je voulais juste faire remarquer la pseudo philosophie du "ca fait une seule chose et ca le fait bien" est globalement bidon. On pourrait lancer des trolls emacs par exemple, célèbre pour son "fait une seule chose et la fait bien". On pourrait lancer des trolls sur Konqueror qui pareil est réputé pour respecter à donf la philosophie Unix. Globalement dans le trip Unix, on auraît du tout coder à base de pipe pour construire des supers briques logiciels de la mort. Au final, ca sert juste à faire des scripts.
Si le système l'est, alors le shell l'est (peut l'être) aussi.
Et ben t'as tout compris : .NET c'est une couche d'abstraction objet pour offrir les services du système (et plus).

Moi je n'attend absolument pas les meme fonctionnalité du shell, du C, du C++, du lisp et du python.
Et ben t'as tout compris d'une 2ème idée de .NET : on fournit un socle objet commun, et on greffe des langages dessus, chacun ayant sa pertinence suivant le contexte. D'où le fait que MS est créé un langage de script spécialement pour son powershell.

j'utilise plutot ff vu qu'il me permet de cliquer directement sur le lien qui m'intéresse .
Tiens encore une appli qui fait autre chose que ce qu'on lui demande à la base... Elle peut pas laisser ce taf à un lecteur de flux RSS qui ne fait que ca et qui le fait bien ? Elle est où la philosophie Unix ?

rien que pour ca tu passe une heure dans les specifs pour savoir quels sont chacuns des attributs si tu n'as pas l'habitude
D'où l'intérêt du powershell : la completion grâce à l'introspection. Pas besoin de te taper les specifs et toutes les pages de man en permancence comme tu aurais dû le faire avec un shell classique.

et oui, ceux qui utilisent le shell script, c'est pas forcément qu'ils ont envie de faire 4000 lignes de code, mais simplement automatiser rapidement une tache simple
D'où mon exemple justement : en 3 lignes tu récupères les 8 premières entrées d'un blog. Fait le avec wget et un parseur xml en script bash, on va voir lequel est le plus simple pour l'admin.

Pour reprendre ton exemple un peu plus haut, tu n'as pas trés bien choisi ton exemple avec 'Get-Date', car le programme date (coreutils) peut faire tout ce que tu as dit:

Houlà, j'ai jamais dis que c'était pas faisable sous Unix...
Déjà le PowerShell apporte l'instrospection, et donc la completion automatique, le DayOfTheWeek m'a été proposé automatiquement après le ".", pas eu besoin de me taper le man de la commande date.
Ensuite je voulais montrer que celui qui a fait la commende Get-Date n'a rien eu à faire pour avoir la localisation : la classe System.DateTime est déjà localisée, son script doit ressembler à : System.DateTime.Now.
Tu vas me dire, la localisation, c'est pas forcement la "killer feature", certes, je voulais surtout montrer qu'il y a une différence entre la valeur "affichée" et la valeure manipulée : dans le powershell c'est différencié : la date est en français ou en allemand, si dessous ta commande powershell récupère ca, tu as toujours un objet DateTime. Dans nos shell classique, faut te taper la gestion de cette date à la main.

Pour moi, simple scripteur du dimanche, tout se passe comme si la variable $MYDATE avait conservé le 'type' date tout au long de ces transformations.
Oué bah regarde le boulot qu'à du faire le mec qui a fait date comment il a dû rigoler pour parser ses dates ;) Et puis comme je l'ai précisé dans un autre post, si toi tu dois choisir de faire un programme qui doit traiter des dates, ben, tu vas devoir tenter de trouver les conventions des autres programmes pour être sûr de gérer les mêmes types de date, modulo les bugs que tu vas ajouter, etc.

Allez, on va voir si ta variable $MYDATE contient vraiment le type pour toi scripteur...
Dans mon powershell si je fais :
$MYDATE = get-date
$JOUR = get-date.Today
maintenant je fais :
$HEUREDUJOUR = $MYDATE - $JOUR
T'optiens quoi en faisant une différence entre 2 chaînes de caractères en bash ? ;) Moi dans le powershell j'obtient un objet TimeSpan qui indique une durée.

.Net ... c'est vraiment tout et n'importe quoi de mon point de vue.
C'est aussi son objectif : couvrir un grand nombre de fonctionnalités, pour avoir un ensemble cohérent et unifié. C'est ce qui a fait tout le succès de Java par exemple.

Je rapelle un peu le principe sous jacent à unix : On fait un seul truc, mais on le fait bien.
Oué, et on commence par utiliser le langage Unix de référence : le C, on se tape un malloc et des void *, et hop, on fait tout et n'importe quoi avec, d'un interpréteur de script à un kernel en passant par un desktop complet :-p
Non plus sérieusement, le framework .NET c'est avant tout une VM et un modèle objet qui permet de voir autre chose que de simples adresses mémoires et des instructions pour les manipuler. Après .NET c'est aussi un ensemble conséquent de classes qui permettent à toutes les applis de partager des types en communs : un type string pour tous les programmes, un type DateTime pour tous les programmes, de l'appli graphique au pages web dynamique en passant par le shell : cohérence et interopérabilité. Tu vois, là moi je me vois déjà scripter mes classes développées dans un projet, juste parcque les 2 utilisent une infrastructure en commun et partagent les mêmes formats de données, bref toutes les applis parlent la même langues : .NET. C'est avec des exemples comme le power shell qu'on comprend mieux tout l'intérêt de proposer une infrastructure "générique" à tout faire : on peut "out-of-the-box" réutiliser tout le framework et les milliers de classes qu'elle contient, mais également les classes développées par tout le monde. Microsoft met également en valeur toutes ses technos basés sur l'introspection, depuis l'ancètre COM jusqu'aux ActiveX, toutes ces technos sont accessibles directement à travers le power shell. Comme quoi la réutilisation ventée par la technique objet n'est pas que théorique comme on l'entend souvent.
Allez pour la route, un exemple trouvé sur wikipedia montrant l'intérêt de donner accès à tout le framework .NET d'un coup :
PS> $rssUrl = "http://blogs.msdn.com/powershell/rss.aspx"
PS> $blog = [xml](new-object System.Net.WebClient).DownloadString($rssUrl)
PS> $blog.rss.channel.item | select title -first 8
Hop ca te retourne les 8 entrées les plus récentes du blog.

L'astuce, c'est que la plupart des objets de base du framework .NET sont "serializables" en fichier XML. Ca permet de faire des choses comme ca dans le powershell :
PS> $a=get-process ps
PS> $a

Handles PM(K) WS(K) VS(M) Id ProcessName
------- ----- ----- ----- -- -----------
270 18536 25188 127 804 ps
514 55288 56944 175 2356 ps

PS> get-process ps |export-clixml abc.xml
PS> import-clixml abc.xml

Handles PM(K) WS(K) VS(M) Id ProcessName
------- ----- ----- ----- -- -----------
270 18536 25188 127 804 ps
562 55300 56956 175 2356 ps

(désolé pour les tabulations)
Bref, tu ne perds pas le type de tes objets :)

Le but de .NET c'est aussi de proposer le choix des langages : .NET a déjà de nombeux langages de script, que ce soit JScript (javascript en gros), IronPython, Boo ou encore RubyCLR. Pourquoi choisir tel ou tel langage ? Question de situation. Visiblement Microsoft a préférer faire un nouveau langage de script, fortement inspiré de la syntaxe C/C#, orienté script. Après on aime ou on aime pas, les goûts et les couleurs hein :) La syntaxe C a quand même l'avantage d'être la plus "traditionnelle" et donc la plus compréhensible par tous.

Est-ce que Mono propose cette API ?
Oui et non. Globalement ce qu'apporte le Power Shell, c'est l'ensemble des fonctions permettant de récupérer "rapidement" des infos du système. Bref, une tripoté de script et d'alias. Sinon pour les types sous-jacents, c'est les types du framework .NET dessous, largement implémentés par Mono.
Donc par exemple, la méthode get-process qui retourne tous les processus n'existe pas dans Mono. Par contre la méthode get-process retourne une liste d'objet de la classe System.Diagnostics.Process, implémentée par Mono. Ses propriétés et méthodes sont identiques à celles disponible dans le power shell : Id, Kill(), etc. (cf http://msdn2.microsoft.com/fr-fr/library/system.diagnostics.(...) )
Je me doute qu'étant donné la différence de conception entre les 2 os, il doit y avoir des incompatibilités
Globalement le framework .NET est bien indépendant de l'OS. La contre-partie, c'est que certaines infos ne sont pas disponible. MS propose donc des extensions spécifiques à Windows (gestion IIS, ActiveDirectory, etc.). Mono de son côté a un namespace Mono.Unix ( http://www.go-mono.com/docs/monodoc.ashx?tlink=0@N%3aMono.Un(...) ) qui offre une surcouche à des fonctionnalités spécifiques de nos OS.

Mono permet t'il réellement l'interopérabilité ?
On peut imaginer une bonne partie des scripts "compatibles", avec des spécificités pour chaque OS forcement.

Je doute que le shell de Microsoft arrive un jour à ce niveau de puissance parce que ca n'interessera personne, tout simplement.
Bof, ImageMagick et mencoder peuvent être lancés depuis le Power Shell de Microsoft, c'est des softs externes qui font des entrées/sorties standards, rien de bien spécifique au monde Unix :)

En gros, si on avait un shell python, ça serait plus ou moins pareil ?
Oui effectivement, tu peux appliquer le même modèle à n'importe quel environnement de programmation de "haut niveau" avec un modèle de machine virtuelle offrant des possibilité d'introspection. Python est un bon exemple. Reste plus qu'à faire le shell (gestion des pipes, completion, etc.) et l'ensemble des commandes pour accéder à tous l'OS :)

ais bon, soyont réaliste, le systeme unix avec ses milliers de commandes plus impressionnantes les unes que les autres et ses "tubes" restera toujours plus efficace que ca...
Pour les commandes, c'est vrai que pour l'instant, c'est pas pléthore. Mais le framework donne déjà accès à de très nombreux service, de la manipulation de service à la gestion de serveur web en passant par les regex ou la manipulation de fichiers XML. Bref c'est déjà un bon point de départ. Et gageont que les commandes vont vite s'enrichir.
Quand aux tubes, je vois pas trop ce qu'il y a de plus efficace, dans MS Power Shell y'a aussi les tubes, mais avec des vrais objets qui passe dedans :
exemple :
"get-process p* | stop-process"
Bref, ca marche comme les pipes Unix, mais en mieux.

Ca fait que tu manipules des objets typés et plus des chaînes de caractères toute bête. Prend par exemple des commandes qui manipules des dates. Dans le monde unix classique, tes commandes vont sortir sous forme de chaîne de caractère une date, d'autres vont se faire chier à les parser pour les interpréter. Y'a intérêt d'avoir des conventions. Mais j'imagine que certains vont utiliser la syntaxe ISO, d'autres vont plutôt mettre la valeur unix, enfin bref, c'est le bordel.
Dans un shell typé, ben les commandes ont des arguments en entrée et en sortie qui sont typés. En l'occurence ils peuvent utiliser le type DateTime. Ce ne sont plus des chaînes de caractères qui transite d'un program à l'autre dans les pipes mais des objets. Pas de problème de typage, le type DateTime est en standard dans le framework, tout le monde comprend cette structure.
Après on peut s'amuser avec tout le framework .NET, par exemple je veux le jour de la semaine d'aujourd'hui, je sais que Get-Date me retourne la date du jour de type DateTime, et je sais aussi qu'il y a la propriété DayOfWeek (qu'il m'a de toute façon proposé avec la completion possible grâce à l'introspection) :
>(Get-Date).DayOfWeek
Wednesday
Plus fort, la méthode ToString par défaut de DateTime retourne une chaîne de caractère qui est localisée suivant l'environnement :
>Get-Date
mercredi 15 novembre 2006 17:11:59
Hop c'est en français. Mais ca conserve le type sous-jacent, je peux mettre Get-Date dans une variable et la passer à une autre commande qui prend un DateTime en entrée.
Y'a pleins d'autres avantages, suffit d'essayer.

$process à pas de .memory
Là l'intérêt c'est que ta variable process est typée par une classe du framework, en l'occurence System.Diagnostics.Process ( http://msdn2.microsoft.com/fr-fr/library/system.diagnostics.(...) ). C'est compilé, en standard dans le framework. Bref, t'es sûr que ta propriété "memory" existe. C'est d'ailleur tout l'intérêt du truc.
Et le truc génial c'est surtout que tu peux faire :
foreach($proc in get-process){ $proc.
là tu appuis sur [TAB] et il te propose l'ensemble des propriétés de l'objet $proc, il a deviné tout seul qu'il était de type Process par introspection sur la méthode get-process qui renvoie une List < Process > .

Ici avec ce shell de MS on est limité aux fonctions intégrés.
Ah non pas du tout. C'est comme sous n'importe quel unix, tu peux utiliser n'importe quel soft qui lit ou écrit sur l'entrée/sortie standard. Là c'est juste qu'il y a une gestion "intelligente" des objets .NET et COM grâce à l'introspection, offrant une approche orientée objet aux scripts.
Alors non, ce n'est pas limité aux fonctions prédéfinis, c'est plutôt extensible à l'infini.