pasBill pasGates a écrit 16062 commentaires

Merci de ce post extremement utile et productif qui va faire avancer le schmilblick.

ooops desole d'avoir casse le troll ....

Bon hop je le relances : OOXML est un vrai standard et est meilleur qu'ODF (qui sux autant q'OO compare a Office et KDE compare a Gnome).

Je suis infiltre et passe incognito : je mets le 1er t-shirt trouve dans ma valise et des shorts (faut etre fou pour mettre autre chose a Las Vegas au mois d'aout), par contre un moyen facile de me reconnaitre : j'ai des baskets, pas des sandales.

Blackhat est assez calme de ce cote la en fait, et c'est normal vu le nombre de professionnels de la branche qui y vont, Defcon est bcp plus drole niveau habillement (l'entree est bien moins chere et les wannabe-hackers et autres fans de Matrix s'y donnent a coeur joie).

http://www.microsoft2.net/2008/04/27/windows-live-wave-3-pla(...)

This theme will involve close collaboration with the Windows 7 and Office 14 teams. Examples of features we could build to support this theme include:

* Make it easy to get set up with Windows Live by typing your Windows Live ID, and automatically download the information and applications required
* Enhance the Windows desktop with Windows Live services and a new theme so customers feel their Windows PC has “come alive” after Windows Live is installed
* Support Windows 7 platform enhancements so Windows Live feels like a natural extension of the Windows system, including gestures, ribbon, and other elements
* Enable a “one-click” way to take my settings, get a Live ID, and “move them” to the service so that POP/IMAP import happens in the cloud.
* What’s our next level of investment in family safety? What is the experience of parental controls and account management (with Windows 7)?

Les softs sont a telecharger, et une fois installes seront bien integres avec le reste du systeme. Nulle part il est dit que l'OS va etre livre avec les softs de Windows Live.

Au final, je sais comment faire un journal de seconde page, je ne sais simplement pas comment faire un journal de premiere page...

Bah c'est comme au foot quoi, tu renouvelles ta confiance a l'entraineur publiquement, ce qui donne le signal a tous les entraineurs interesses par le poste qu'il est disponible, et tu le vires une semaine apres une fois que t'as trouve le bon remplacant.

Si l'argent est le nerf de la guerre, pourquoi est-ce que RedHat a persisté toutes ces années en investissements avant de faire enfin des bénéfices ?

Ben c'est comme toute societe hein, tu investis, en pariant que ton investissement va payer.

Si Oracle ne croyait pas en Linux ni en les logiciels libres comme marché potentiel, je ne pense pas qu'ils auraient envisagé d'éditer leur propre version de RHEL, Oracle Entreprise Linux (OEL). Oracle est un éditeur d'applications, son moteur de bases de données lui sert avant tout à mettre un pied dans le SI des clients. Peu lui importe le système d'exploitation qui permet à ces applications de tourner, finalement.

Tant que la plateforme est stable oui tout a fait. Ce que je dis, c'est que si demain les devs de Linux se mettent a casser la compatibilite tous les 6 du mois, Oracle va serieusement reviser sa strategie, car ses couts de support/maintenance vont fortement monter.

Quand a creer sa propre distribution, jusqu'a un point, ils ne peuvent pas se permettre un vrai fork, car ils n'ont pas les ressources et l'experience pour maintenir un OS entier, c'est un boulot enorme, et j'en sais qqe chose.

Certaines societes font cela (certains demandent encore un support NT4 apres tout...), mais la grande majorite des societes migre plus tot que cela. Quand tu regardes le passage NT4 --> 2000 par exemple, la grande majorite des gens a migre avant la fin du support total NT4, il y a des annees de cela. De ce que j'ai vu, il y a plutot un cycle dans bcp de societes, renouvellement du parc, on en profite pour updater le systeme.

Tu sais trés bien que les clients qui utilise ce genre de base de données, ne s'amuse pas à changer de système d'exploitation juste histoire d'être à la mode.

Oh non, ils le font quand ils se rendent compte que la nouvelle version leur permet de faire des choses que l'ancienne version ne permettait pas (au hasard : hot-add RAM, meilleures perfs sur plusieurs CPU / cores , ...) ou quand le support de l'ancien OS se termine.

Quand a changer le tout, certainement pas, valider l'OS est une chose, valider la nouvelle version du soft de base de donnees en est une autre. Oracle fait le 1er, mais c'est l'enterprise qui va devoir se taper le second, et c'est un sacre boulot. Savoir que Oracle X qui tourne sur RHEL 4 tourne sur RHEL 5 c'est bien mieux pour l'entreprise qu'apprendre qu'ils doivent passer de Oracle X sur RHEL 4 a Oracle X+1 sur RHEL 5

Quand a Oracle, ils font certainement la certification eux-meme, mais si tu t'appelles Torvalds et que tu t'amuses a casser la compat avec Oracle tous les 6 mois, ils vont vite en avoir marre et sentir que cela leur coute plus en support / tests / dev de maintenir la compatibilite d'Oracle sur Linux que cela leur rapporte.

Les kernels hacker tiennent a conserver une certaine stabilité de l'ABI. Je n'ai jamais dit le contraire, La modification apporté ici était trop mineure pour justifier le désagrément de casser l'ABI.
En aucun cas la décision a été motivé par l'existence de logiciel propriétaire utilisant l'ioctl.

Ben reflechis un peu: qui c'est qui souffre lors d'un changement d'ABI ? Le code proprio, pas vraiment le code libre...
Chaque fois qu'ils font bien attention a ne pas casser la compatibilite, c'est en bonne partie pour ca, alors oui de temps en temps ca arrive, mais il leur faut une tres bonne raison pour le faire comme tu dis, car ils savent qu'emmerder leurs utilisateurs de maniere reguliere va les aliener.

Microsoft ne communique pas sur les détails de ses bugs. Je te cite "Quand aux details, je doutes que j'aie l'autorisation de les donner..."
En tout cas, ça a bien a voir avec les fichiers...

Ca a a voir avec des fichiers et leur contenu oui, pas avec la structure du systeme de fichier.

Bon ok, ca m'apprendra a pas faire assez attention, en voila un autre : http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.22

commit c74e83a8632fd88560a533980a0d4c3922325326
Author: Hans Verkuil <hverkuil@xs4all.nl>
Date: Thu May 17 06:41:44 2007 -0300

V4L/DVB (5670): Adding new fields to v4l2_pix_format broke the ABI, reverted that change

Reverted the change to struct v4l2_pix_format. I completely missed that
this struct was used by existing ioctls so that changing it broke the ABI.
I will have to think of another way of setting the top/left coordinates
but for now this change is reverted to preserve compatibility.

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>

MS devrait prendre exemple sur ces méthodes de développement, ça lui éviterait de perdre les données sur ses produits Home *Server* ou Retail Management System.

Moi je crois que tu devrais plutot t'informer sur un sujet avant d'en parler, ca te rendrait bien plus credible. Aucun de ces 2 problemes n'avait quoi que ce soit a voir avec le systeme de fichier.

Oracle ne tournera pas sur la prochaine RHEL. La société Oracle mettra les mains dans le code pour porter et certifier sa base de données sur la nouvelle RHEL.

Permets moi d'en douter enormement, tu crois que les clients vont s'amuser a faire une transition Oracle pour pouvoir tourner sur la prochaine RHEL ? Tu crois qu'Oracle va s'amuser a se coltiner ces changements du code constamment ? Tu reves mon cher, ce genre de boulot ca coute cher, et l'argent c'est le nerf de la guerre pour Novell, Redhat, ...

Montre moi une modification du kernel, de la libc au autre qui n'a pas eu lieu uniquement pour satisfaire le fonctionnement d'une appli propriétaire ?

Que je te montres ce qui n'a PAS ete fait ? Ca ca va etre dur, je suis pas dans la tete des devs.

Un truc que tu peux facilement faire par contre c'est aller sur Google et chercher :

site:kernel.org "backward compatibility"

Et tu verras plein de diffs / mails ou ils se preoccupent serieusement de la compatibilite descendante, avec differents bouts de code dont la seule utilite est de faire tourner du code ancien.

Petit exemple tire au hasard : http://209.85.173.104/search?q=cache:rCWUt7318jgJ:www.kernel(...)

/* This structure is 256 bytes large, depending on the name, only part */
/* of it is written to disk */
/* nice though it would be, I can't change this and preserve backward compatibility */

Si la communauté Linux prenait ces décisions dans le respect des logiciels propriétaires, il n'y aurait tout simplement pas de Linux 64 bits !!!
Alors franchement la compatibilités avec Flash, Acrobat Reader, nVidia, ou Oracle... on s'en tape.

Vous vous en tapez ? Je veux bien croire que tu t'en tapes, mais je doutes que les utilisateurs moyens de Linux eux s'en tapent.

Tu peux etre sur que si Oracle ne tourne plus sur la prochaine version de Redhat Entreprise Server, Redhat va avoir les oreilles qui sifflent...

La realite, c'est qu'une fois que Linux est repandu, que les utilisateurs se basent dessus pour leurs differents besoins, qu'ils utilisent des logiciels proprio dessus, cela a un effet sur le developpement, la communaute ne va pas s'aliener sa base d'utilisateurs sans une tres tres tres bonne raison, et Redhat ne va surement pas accepter une decision qui lui retombera au visage a travers ses clients.

Ce qui n'a rien a voir avec l'espace disque utilise par l'OS mon cher...

Il faut dans les 8-9Go pour installer l'OS, cela contient plein de trucs dont en realite tu n'as pas besoin pour faire tourner l'OS, au hasard il y a 300Mo de fichiers de donnees pour la reconaissance vocale dans plusieurs langues, je doutes que tu aies besoin de toutes les langues, etc...

Les forcer ?

C'est marrant, parce que Exchange n'est pas en monopole, et n'est pas en situation de lock-in, il est remplaceable, bref, ils n'ont pas veritablement de pouvoir sur leurs clients dans ce cas la.

La realite, c'est que les besoins d'Exchange (espace d'addressage pour mappings, etc...) font que Windows 64bits etait la meilleure solution pour le long terme et qu'il n'y avait pas vraiment de raisons de garder la version x86.

Quand a forcer les editeurs a developpeur, tu ne convaincras personne en insinuant qu'avoir Exchange 64bit uniquement va forcer le monde du logiciel a passer a Windows 64bit.

Pas besoin de preuve certes, mais la seule maniere c'est d'avoir une suite de tests complete, et lorsque ton code est un tant soi peu complexe, avec des cas genre code multithread, ... bonne chance...

Ben oui. Une regression se définit si quelqu'un la subit. Et comme l'ensemble de développement est ouvert au grand public de manière transparente, une régréssion est immédiatement détecté, rapporté, et corrigé !

Marrant quand meme, comment se fait-il qu'il y ait des regressions dans les releases stables si c'est tellement facile de les trouver ?
La realite c'est qu'elles sont detectees par l'utilisateur qui la subit comme tu dis, et souvent, c'est l'utilisateur final, pas le beta-testeur, nos service packs sont downloades par des dizaines de milliers de beta-testeurs, aucun d'entre eux n'a vu le bug. Ensuite, le debuggage/correction, c'est meme topo chez eux et chez nous, on sort un patch, ils sortent un nouveau .deb

L'ensemble des logiciels étant libres, la communauté peut alors décider si c'est l'application ou la base qui doit être corrigé. La mise à jour étant gratuite, il n'y a rien de pénalisant a casser ou étendre une API en upstream. Les distributions prenant en charge la stabilité de l'API et du comportement durant le cycle de vie d'une version de distributions.

L'ensemble des logiciels est libre ? Oracle est libre ? Acrobat est libre ? ...
Desole, mais c'est loin d'etre le cas.

Install clean de vista (+ calculatrice et bloc-notes) == 20 Go d'espace disque occupé
Install complète (GNOME, OpenOffice, GIMP, Inkscape, Blender+ 56 langues supportées...) de Linux == 4 Go d'espace disque occupé !

20Go ? J'etais pas au courant... mais il est vrai qu'il prend trop de place, la version serveur elle prend bcp moins.

Forcément, aujourd'hui Windows n'est qu'un gigantesque chateau de carte qu'une moindre perturbation peut écrouler ! Impossible pour Microsoft de faire table rase du passé et de repartir à zéro sur des bases saines, il signerait sa mort. Il n'y a qua voir Windows 64 bits... Il n'y a quasiment aucune différence avec la version 32 bits, et pourtant, aucune appli, aucun driver disponible pour ce système !!

Windows 64bits va tres bien merci pour lui, la derniere version d'Exchange n'existe qu'en 64bits d'ailleurs, c'est tout dire...

Je suis sur que Debian au total est plus gros que XP.

Maintenant, tu as connaissance de toutes les regressions qui sont introduites dans Debian ? J'en doutes fortement...

Avec Windows ca fait du bruit parce que meme quand tu as 1% des gens affectes ca fait plusieurs millions, avec Debian une regression dans le package

Cherches un peu le mot "regression" avec Debian, filtre uniquement sur les releases stables, tu trouveras plein d'occurences, et c'est normal, ils n'ont pas de formule magique, personne ne l'a.

Quand on modifie des interfaces on en paie les conséquences, tous les programmeurs savent que c'est très dangereux et qu'il vaut mieux marquer la fonction comme dépréciée et en créer une autre à coté.

Le truc c'est que la modification n'etait pas voulue...

Enfin là ça n'a rien à voir avec la correction du code, on demande juste à ce qu'il fasse la même chose que la version précédente. Et là, la compléxité ne me semble pas insurmontable.

Ben si, parce que pour comparer le comportement du code avec ce qu'il faisait avant tu fais quoi ?

Tu ecris des tests qui verifient le comportement, et imagine simplement un API qui prend plusieurs parametres, certains sont des structures, un est un contexte cree par une fonction precedente, contexte qui peut etre dans plusieurs etats differents selon le flux du code, ... tu te rends vite compte que c'est impossible de gerer tous les cas possibles.

Oh si, plus que tu ne peux l'imaginer, ca ne veut pas dire qu'ils couvrent tous les cas possibles et imaginables par contre, verifier qu'un bout de code non-trivial est correct est un probleme d'une complexite enorme et qu'il est impossible de resoudre aujourd'hui.

Pas des patchs prives, si tu recois un patch pour le binaire X, tu recevras ton patch + toutes les modifs qui ont ete faites a ce binaire precedemment, tout comme avec Debian ou autre.

Simplement peu de gens on demande un patch pour ce binaire, resultat personne n'a decouvert le probleme jusqu'a ce que les gens se mettent a tester/installer le service pack, car la la quantite de gens recevant le binaire a cru exponentiellement.

Mais c'est l'ensemble des patchs appliques au systeme. Cette librairie a ete modifiee par une requete d'une societe, on leur a fait un patch, ils ne s'en sont jamais plaint (car ils l'utilisent de maniere differente), on l'a integre dans le service pack, et la il ressort que dans un contexte different, il y a probleme.

XP SP2 etait un cas a part, on y a ajoute des fonctionnalites d'un point de vue securite, mais un service pack c'est les patchs existant mis ensemble et rien d'autre.

Non, ils parlent des gens qui font les patchs quand un probleme dans l'OS nous est remonte, 400-500 employees a plein temps dans ce cas.
Quand au support technique, il est payant dans la plupart des cas, et il est tres loin d'etre inexistant.

Donc non, le support c'est bien plus qu'une feuille A4

Il reste ~400-500 personnes pour patchs, service packs, ... mais on bosse sur plusieurs OS a la fois.

Comment un changement dans le code de l'OS peut affecter directement et aussi profondément le comportement d'un logiciel ?

J'avoue, j'ai peu programmé sous dodows, mais le logiciel en question doit quand même faire appel à des bibliothèques qui fournissent des fonctions de plus ou moins haut niveau ...

Ben oui, et le service pack il contient tout cela, le probleme se situe dans une de ces libs de haut niveau.

Quand au changement de comportement, qu'on soit clair, c'est un bug. Pas de manque de documentation en cause, ca n'aurais simplement pas du arriver. Il se trouve que RMS est le seul soft sur lequel (pour l'instant) le bug est expose, raison pour laquelle on ne s'en est rendu compte que maintenant. Le probleme n'est visible que si l'API est utilise d'une certaine maniere.

Quand aux details, je doutes que j'aie l'autorisation de les donner...