pasBill pasGates a écrit 16169 commentaires

Pas tout le monde. Bien que ton argumentation se tienne, quelqu'un qui publierait ces sources enfreindrait un NDA et donc la loi. Peut-être que le Snowden du source code ne s'est pas encore manifesté !

Super !

a) Et tu crois que tout le monde lit les sources de Linux ?
b) Poster une maniere de trouver cette backdoor de maniere anonyme sur le net("regardez le binaire xyz, si vous passez les parametres a et b a la function p, ca declenche la backdoor" par exemple) est on ne peut plus simple et sur
c) "Pas encore" ? C'est quoi cette connerie ? On est coupable jusqu'a ce qu'on soit prouve innocent ?

1) Plein de gens ont acces aux source de Windows depuis des annees (oui, avec possibilite de recompiler, etc…) a travers toute la planete, pas une personne n'a encore senti le besoin de poster en ligne cette soi-disant backdoor(normal, elle n'existe pas), pas un gouvernement sur cette planete a decide d'eliminer l'usage de Windows.

Aucune idee de ce qu'est ce truc, faudrait regarder une trace reseau et voir ce qui merde. Ca pourrait etre l'authentification par exemple, ou autre, dur a dire comme ca.

Moi ce que je vois :

• Meme noyau
• Memes softs
• Binaire sur l'un peut tourner sur l'autre (memes syscalls, memes librairies, …)

Bref, c'est vraiment le meme OS a la base, juste configure differemment ou avec des binaires de versions differentes. Il n'y a aucunes differences architecturales ou incompatibilite binaire.

Ce sont des classes, qui se trouvent dans une "assembly" (l'equivalent d'une librairie en .NET en gros).

Il y a 2 manieres pour Powershell de les retrouver :
a) Registration, tu peux "enregistrer" l'assembly, ce qui fait que Powershell saura quels cmdlet sont dans quelle assembly
b) Tu utilises "Import-Module" qui charge dynamiquement une assembly contenant des cmdlet. Powershell v3 rend les choses encore plus simples car il importe automatiquement tous les modules qui se trouvent dans le path qu'il a

Pour le vase clos, tu peux toujours lancer des softs non-cmdlet, simplement ce qu'ils retournent ne sera pas structure.

Ben justement non…

Avec Powershell, tout cela est implemente avec un threadpool, dans un processus, t'as un nombre limite de threads cree, tout est propre.
La methode de lancer un ssh par machine, sur un reseau de 5000 machines par exemple (et 5000 c'est vraiment pas enorme, surtout avec la manie d'aujourd'hui de virtualiser tout et n'importe quoi), ca te cree … 5000 processus !
Ca te met la machine a genoux tout de suite, parce que ces 5000 processus il faut leur allouer de la RAM, rien que la stack prend 2mb par thread par defaut sur Linux x86(en tout cas Redhat). Et c'est sans compter le fait que tu n'as aucun moyen de savoir lequel des processus s'est rate sans faire une tambouille bien sale alors qu'avec Powershell t'as un systeme de retour d'erreur bien propre pour chaque tache cree.

Resultat, avec bash/tcsh, il faut te taper la gestion en batch a la main, faut te trouver un moyen de retourner les erreurs pour chaque processus plutot que le dernier comme wait le fait, … bref, c'est le bordel.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms714395(v=vs.85).aspx

Une "commande" powershell est un cmdlet, n'importe qui peut les ecrire, ils s'ecrivent en .net et derivent d'une classe parente nommee… cmdlet.

L'utilisateur ecrit tout ce dont il a besoin la dedans : il definit les parametres, fait ce qu'il faut pour arriver a resultat(il peut faire des connections reseau, lire la registry, faire des appels DCOM, interpreter un parameter en ligne de commande comme etant un script dans un langage donne, invoquer des poupees voodoo etc…), et retourne un objet qui contient le resultat.

Oh, et un truc bien sympa dans Powershell, il permet de tirer parti de toute l'infrastructure asynchrone presente dans .NET :
Tu veux la liste de tous les softs installes sur toutes les machines du reseau, ben pas besoin que le script fasse une machine après l'autre, il peut faire les requetes en asynchrones sur toutes les machines, les resultats arrivent quand ils arrivent et il suffit de faire un 'wait' a la fin sur tous les resultats pour avoir le resultat final. Ca amenera le resultat enormement plus vite qu'un script qui fait une machine après l'autre. Bonne chance pour faire un truc pareil en bash/tcsh…

Mais tu vas le voir comment ?

Si ils rajoutent une colonne qui contient un entier devant une autre colonne qui contient un entier, ton script il ne va pas planter, il va juste te filer le mauvais resultat, et selon ce que le script fait, tu pourrais:
- ne rien voir pendant des semaines alors que le script te fait perdre/endommager des donnees lentement mais surement
- t'en rendre compte tres vite sans dommages
- t'en rendre compte parce que la moitie de ton parc a disparu du reseau et tous tes utilisateurs hurlent.

C'est un vrai cauchemard ce genre de truc, surtout le 1, parce que bonne chance pour aller debugger tes scripts qui s'appellent les uns les autres, et arriver a comprendre ce qui se passe exactement.

C'est pas pour rien que les interfaces definies et solides sont importantes, que les donnees structurees sont importantes, c'est justement pour eviter ce genre de bordel. Si le format n'est pas bon ca plante, ca ne corrompt rien. Si l'interface est definitive, ca ne plante pas.

Un script qui plante un jour, suite à une montée de version. Mais facile à corriger.

Il plante ? Ou il te rend le mauvais resultat sans que tu t'en rende compte, ce qui est infiniment plus grave. Surtout selon ce que le script fait.

Euh… tu regardes la liste que tu donne sur la page, tu regardes la derniere colonne, c'est ecrit hein. 13/27 creent du MSI. Les autres font leur proper sauce, mais au final stockent ce qu'ils doivent au bon endroit. Ils ne remplissent probablement pas la base MSI par contre.

D'après toi, quels sont les logiciels d'empaquetage qui ont le vent en poupe actuellement sous Windows ?

MSI est le format de loin le plus utilise. Install Shield et WiX semblent etre les installers les plus souvent vus de mon experience.

df c'est posix, eh, ps aussi c'est posix, va donc lancer cette commande sur 3 Unix differents et dis moi si la sortie est identique…

Pour dpkg : https://launchpad.net/debian/+source/dpkg/+changelog

1.16.5

Superseded in sid-release on 2012-07-02

Add an Architecture column to «dpkg-query -l» before the Description column

Je te laisse imaginer ce que ce genre de changements aurait eu comme effet sur un script utilisant awk ou cut

T'as remarque que ma commande ne comportait pas la liste des attributs mais un '*' ? Pas besoin de tous les lister

Une entrée par ligne, ça revient exactement à un objet avec des membres.

Pas trop non, il y a les dates, tailles, etc… qui sont des attributs aussi. Ensuite sous tcsh/bash/… il faut arriver a les lier a l'element de depart quand tu les passes d'une commande a l'autre, etc… Compare a Powershell c'est totalement primitif

Cela n'arrivera pas car ce chemin fait partie de l'API documente : http://msdn.microsoft.com/en-us/library/ms954376.aspx C'est pas un truc cache qui n'est pas sense etre utilize, c'est un chemin officiel.

Alors que la sortie des outils ligne de commande, elle n'est en rien garantie.

On parle du meme OS. Debian & Redhat c'est le meme OS : GNU/Linux.

Windows XP/2003/Vista/Seven/8 c'est le meme OS : Windows.

Euh visiblement t'as pas tout compris a la page… Il y a plein de ces softs qui te permettent de creer des installers, mais beaucoup de ces softs creent un MSI a la fin.

Ensuite si tu veux une liste exhaustive(parce que ta liste, elle contient plein de formats que quasi personne utilise sous Windows) tu regardes Linux :

deb, rpm, tgz, ebuild, opkg,PiSi, Conary…

C'est pas forcement mieux hein, surtout va la difference enorme de taille des bases installees.

Tout a fait, maintenant fait une commande qui te sort Rpm+Deb, qui affiche ca de maniere uniforme, et qui est solide (genre ca ne pete pas parce que les gars de dpkg ont decide d'afficher une ligne supplementaire dans la version suivante), ca sera l'equivalent de ton powershell (ou du mien plus bas)

Oui, a part le fait que ma commande, elle marche sur un systeme remote et elle retourne une structure de donnees tres simple a reutilizer plutot que du texte qu'il faut formatter soi meme…

Tout a fait, faut prendre les 2 pour etre sur d'avoir les softs 64 ET 32bit. Wow6432 est pour les softs 32bit installes sur un systeme 64bit

Tout a fait, et tu peux les changer

J'ai pour habitude de ne pas toucher les pages se referrant a mon employeur, pour des raisons evidentes de partialite.

C'est toujours bancal, le jour ou tu as une machine qui n'est pas Debian/Ubuntu, tu rates cette machine.

Marrant, chez moi ca fait une ligne…

Invoke-Command -ComputerName this-ubook -ScriptBlock { gp HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* }

Ben non… (Powershell v3) :

Invoke-WebRequest http://www.google.com/

Ensuite… tu veux juste le contenu plutot que les headers ?

(Invoke-WebRequest 'http://www.google.com').Content

Le titre seulement peut-etre ?

(Invoke-WebRequest 'http://www.google.com').ParsedHtml.title

etc… Pour chaque exemple que tu me trouves plus complexe en powershell, je t'en trouves un plus complexe en shell unix…

Sinon, tu m'expliqueras l'usage de tes 2 dernieres lignes, si tu es dans la console powershell tu n'en as pas besoin.

Bref, tu n'as rien de serieux et tu supputes base sur tes fantasmes.

Tu me montreras ou est ce que MS a dit ca.