pasBill pasGates a écrit 16309 commentaires

Il faut que tu prouves que le style du code de bash soit une cause de la faille. Parce que c'est vraiment une critique gratuite : « Bouh, ils n'utilisent pas le dernier style à la mode, quels incapables ! »

Que le style soit responsable, c'est dur a prouver de maniere certaine (si ca se trouve c'est pas le cas…)

Ce qui est sur par contre, c'est que le style de programmation utilise (si on peut appeler ca un style…) est connu pour tres frequemment causer des problemes. Le meilleur exemple etant les variables globales, il devient tres dur d'arriver a savoir comment ces variables se comportent lorsque tu as des variables accessible de partout, que tu ne sais pas qui les change et qui ne les change pas (et non, un 'simple' grep ne suffit pas, vive les pointeurs).

Un certain minimum de variables globale peut avoir un sens, mais un nombre pareil rend le code impossible a maintenir et relire proprement.

Idem avec les fonctions considerees dangereuses. Leur presence n'indique evidemment pas automatiquement une faille, mais quand tu as fais assez de code reviews securite pour voir des patterns, tu sais que statistiquement, le risque est bcp plus eleve.

On est tous un peu artiste quelque part…

Tu remarqueras que j'ai liste un probleme tres precis : l'impossibilite du debugger utilise a afficher des conteneurs STL.

Quand ton soft est totalement base sur STL, vecteurs, maps, string, smart pointers, … on va dire que c'est un probleme sacrement dur a vivre avec.

Chacun ses gouts. Je me contentes de constater qu'il m'est bcp, bcp, plus rapide de developper un soft sous Windows avec VStudio, eliminer un max de bugs grace a un debugger qui fonctionne proprement, et faire alors le portage sous Linux que faire le codage principalement sous Linux avec Eclipse/Emacs/KDevelop et gdb.

C'est quand meme con de devoir utiliser un Windows pour accelerer le developpement d'un soft Linux…

Moi oui je peux.

Au hasard :

Tu peux mettre un breakpoint et voir les variables du systeme, incluant la stack, incluant la valeur des variables dans chaque frame, incluant les valeurs sur lesquelles les pointeurs pointent … n'importe ou a chaud.

Tu peux changer de breakpoint, l'enlever, … a chaud, n'importe quand. En 3 secondes.

Tu peux modifier le code a la volee, continuer l'execution

Tu peux bouger le registre d'instruction et le remettre au debut d'un bout de code pour revoir son execution sans devoir tout relancer

Tu peux voir ton buffer en memoire a chaud, pas a pas, y inclus les qqe bytes suivant / precedant le buffer, et t'assurer que le probleme n'est pas du a un ecrasement d'une autre variable par exemple.

etc…

Un debugger et printf, c'est aussi different qu'une BMW et une Trabant. Les 2 permettent de rouler, mais un des deux est bcp plus rapide, plus agreable et plus fiable.

Moi si, mais tous les IDEs Linux se basent sur gdb, et aucun n'est foutu d'afficher correctement le contenu d'objets en C++ donc bon, ca ne resoud rien…

Je parles de debuggage

Ni KDevelop, ni Emacs, ni Eclipse (que j'ai tous essaye) ne sont foutus de permettre de proprement debugger un programme sans y passer des heures. Car ils se basent tous sur gdb qui est un homme des cavernes de ce cote la (et je n'oses meme pas en parler quand tu ajoutes openmp dans le mix…), et leur capacite a interpreter proprement les containers STL par exemple est proche de zero.

Mais perso, je suis passé à cmake+vim+cgdb, ça marche très bien, c'est léger, réactif, stable et ça n'a pas besoin de serveur graphique (sisi, parfois c'est utile).

Et c'est totalement imbitable pour voir des structures imbriquees, genre STL.

Pour avoir passe l'annee derniere a developper sur Linux apres des siecles dans Visual Studio, j'ai vraiment l'impression d'etre passe du 21eme siecle a la prehistoire niveau debuggage, c'est incroyable a quel point c'est douloureux et non-productif. J'ai du mal a comprendre qu'une communaute tellement portee sur le developpement n'ait pas resolu ce point la.

Cela dit, j’espère que depuis 2009 il n’y a pas eu de faille majeure dans ces deux projets. :-)

Si il y en a eu et qu'elles affectent SFU, elles seront patchees. SFU n'est peut-etre plus developpe, mais il est toujours en mode maintenance.

« chez eux », ça signifie que tu as changé de service ou que tu n’es plus chez Microsoft ?

Ca va faire un an le mois prochain que j'ai quitte Microsoft.

Aucune idee je bosses plus chez eux. Mais t'es sur que SFU inclue bash ? Il me semblait que c'etait csh et ksh

C:\Users\nvidiatnt>bash
'bash' is not recognized as an internal or external command,
operable program or batch file.

C'est quoi exactement le danger ? ;)

http://powershelltutorial.net/

Tu peux controler n'importe quel objet COM a travers PowerShell, et a peu pres tous les softs d'entreprise MS ont des cmdlet PowerShell specifiques, ainsi que de plus en plus de softs d'entreprise d'autres boites.

Maintenant, changer les habitudes des sysadmins, on sait tous que c'est pas simple…

Il y a un port pour Mono en Alpha, toujours developpe : https://github.com/Pash-Project/Pash/

Et je suis globalement d'accord, sauf sur la punition, il serait plus judicieux de lui supprimer son PC sous linux et de lui passer une tablette surface sous Windows 8 :) (2 jours devraient suffir)

Bonne idee, comme ca il pourra decouvrir PowerShell et se demander pourquoi ces hommes des cavernes s'acharnent a utiliser un outil prehistorique qui n'a aucune structure et qui est si facilement sujet a erreur.

Par ex. j’ai en tête le rachat de SQL Server à Sybase : ça tournait sur différents Unix, et MS s’est empressé de le rendre non-portable.

Totalement faux.

MS a rachete les droits des versions pour OS Microsoft a Sybase. Sybase a continue a developper sa ligne pour les Unix seul, et MS a continue a developper les versions pour Windows.

Et c'etait au debut des annees 90 donc, il y a 20 ans. On va dire que meme si ca avait ete le cas, l'exemple ne vaudrait pas grand chose.

Pourquoi est-ce que vous utilisez RDP pour lancer vos calculs ? Vous pouvez le faire a distance avec Powershell / psexec par exemple, et la aucun probleme de deconnexion.

Le comportement est normal car c'est un desktop, pas un serveur.

Je crois que ton super RDP est un poil loin derrière.

Sur cette fonctionnalite oui certainement.

D'ailleurs, dans le meme creneau, j'ai a te vendre une super voiture qui peut rouler sur toutes les routes, gratuite, mais qui consomme du 40 l/100km et qui n'a ni serrure ni clef de contact .

L'inconvénient dont tu parles est son principal avantage : ça transmet bêtement tout ce qui est affiché.

Cet inconvenient est probablement son avantage sur ce point la, ca ne change rien au fait que cet inconvenient est redhibitoire sur un reseau un poil lent.

Et encore une fois, VNC fonctionne tout à faire rapidement sur un réseau local.

C'et super, et quand je suis en Europe et veut me connecter a ma machine aux US, ca marche comment ?
Quand je suis dans un coffee shop et veut me connecter a ma machine au boulot ca marche comment ?
etc…

Tous des cas reels et habituels d'utilisation.

Tu ne sembles pas l'utiliser alors évite de dire que c'est nul, tu n'en as pas l'expérience « en vrai ». Juste de la belle théorie qui prédit que ça ne peut pas fonctionner comme il faut.

Je l'eu utilise, et depuis justement j'evites, a cause des points cites. Notamment le 2eme (securite) qui a lui seul rend VNC inutilisable vu qu'il donne acces a quiconque est proche de la machine.

interdire le proprietaire au gouvernement

Mon dieu, il fallait vraiment te le preciser qu'on parlait de ton idee d'interdire le proprietaire au gouvernement ?

Possible. Le fait reste qu'elles ont choisit d'installer un Windows.

C'est quand meme drole ces gens qui lancent des phrases en l'air, sans le moindre argument, simplement parce qu'ils aiment repeter ce qu'ils ont lu sur un forum.

Perso, je preferes me fier a l'opinion des gens dans l'industrie de la securite informatique, qui donnent MS comme l'exemple a suivre.

vnc sur un réseau local est très rapide.

Ben comment dire… oui. Et moi je sautes tres haut si je suis sur la lune.

Maintenant, en realite, le reseau a du traffic, il y a de la latence, etc…. et VNC non seulement bouffe un traffic fou a cause de la maniere stupide dont il fonctionne, mais cela impacte la vitesse d'affichage en cas de reseau charge (logique tu me diras)

Le pépin est sur les liaisons lentes par rapport au flux d'affichage. Là clairement c'est moyen. Mais RDP ne fait pas franchement mieux.

Non desole, RDP et NX font bcp bcp mieux que VNC, pour avoir du vivre avec pendant qqe jours il n'y a pas photo. Le fait que VNC ne fasse que du copier-coller de rectangles en gros est un vrai desavantage compare a qqe chose comme RDP qui transmet simplement les primitives.

Avec RDP on ne peut pas redimensionner la tailles des éléments du gestionnaire de fenêtre (au moins avec Windows XP et 7). Avec RDP on ne peut pas régler soi-même le verrouillage en cas d'inactivité. Toutes ces choses qui ne posent strictement aucun problème avec vnc.

RDP n'est pas le truc parfait et ideal, mais VNC desole, il faudrait etre fou pour utiliser ca plutot que NX. Rien que le fait qu'il unlocke la session en local quand tu te connectes a distance fait qu'utiliser ce truc est une folie d'un point de vue securite.

Cette mauvaise foi est choquante.

Non, ca s'appelle du realisme a l'inverse de tes vues totalement idealistes sans rapport avec la realite.

Personne ? Il y a moi, il y a tout le monde, des centaines de milliers de personnes probablement, toute personne ayant les compétences peut intervenir sur un logiciel libre. PAR DÉFINITION.

Oui oui on sait. C'est beau la theorie.

J'ai hate de te voir essayer de corriger un bug dans le noyau Linux, et surtout le tester. Tu l'as prise ou ta batterie de tests pour t'assurer que rien n'est casse ? Ton expertise noyau tu l'as eu en lisant 30s sur Wikipedia c'est ca ?

C'est surtout que tu n'as pas la moindre idee du travail et des ressources necessaire pour faire du support/maintenance d'un gros soft.
Supporter une distrib d'il y a 13 ans, c'est un boulot enorme. C'est bien pour ca que malgre le fait qu'en theorie c'est faisable, en pratique personne ne le fait et c'est donc exactement la meme situation qu'avec le modele proprietaire.

Avec un logiciel privateur, il n'y a que l'entreprise qui l'édite. C'est à dire potentiellement personne.

Tout a fait. Et en pratique, on se rend compte que pour les LL c'est idem.

Bon, tu m'a gonflé, je te perdrais plus mon temps à te répondre désormais. Pour la dernière fois : il n'y a que dans ton esprit malhonnête que des gens veulent interdire un modèle selon sa licence.

Tu as toi-meme que tu voulais que le gouvernement n'achete que du LL, et refuse le proprietaire : http://linuxfr.org/users/bortzmeyer/journaux/munich-ferait-marche-arriere#comment-1556602

ils devraient imposer des solutions libres et ouvertes, et commander leur développement s'il n'en existe pas. Car l'adoption d'une solution privatrice et fermée n’intéresse que celui qui la vend.

Assumes tes paroles.

Ah les suppositions… Windows sur les serveurs n'a pas Office, pourtant il se vend comme des petits pains.

Le probleme est pas AutoCAD, le probleme est VNC. C'est lent, surtout pour qqe chose d'intense graphiquement comme AutoCAD, et niveau securite c'est juste pas ca.