A cause de RMS, microsoft est obligé de reporter sine die le SP3 de XP qui devait sortie aujourd'hui.
Dans la foulée, le SP1 de Vista est aussi interrompu !
Je me suis demande de quoi tu parlais mais la lecture du lien est assez rigolote en effet.
J'aime beaucoup la conclusion de l'article qui souligne bien que pour un OS ayant osit disant ete re-ecrit a 100% les bugs affectant XP affectent aussi Vista.
J'aime beaucoup la conclusion de l'article qui souligne bien que pour un OS ayant osit disant ete re-ecrit a 100% les bugs affectant XP affectent aussi Vista.
Vista n'a jamais ete une reecriture a 100% et MS ne l'a jamais insinue.
C'est de ta faute, avec un titre pareil tu m'as fait croire un instant que qq'un avait mis du code GPL dans le SP et que la distribution etait stoppee a cause de cela :+)
Sous MS Windows 2000 quand on indique "no sound" pour le changement de volume on a un beep speaker à chaque changement de volume. Sous XP c'est encore le cas. Est ce que c'est toujours pareil sous Vista? (je n'ai jamais utilisé de Vista)
il y a pas à chier u ncake, en os proprio, Apple, Sun HP ou IBM sont carrément plsu professionels que Microsoft
Jamais vu d'update de MacOS X de décalé, et les patchadd ne font jamais planté ma machine.
Microsoft , en restant proprio, devrait prendre exemple sur Microsoft.
The following non-security issues introduced by Security Update 2006-001 are also addressed by this update:
Download Validation: Security Update 2006-001 could cause the user to be warned when provided with certain safe file types, such as Word documents, and folders containing custom icons. These unneeded warnings are removed with this update.
apache_mod_php: A regression in PHP 4.4.1 that could prevent SquirrelMail from functioning is corrected with this update.
rsync: A regression in rsync that prevented the "--delete" command line option from functioning is corrected with this update.
Pour etre precis, ca arrive a tout le monde d'avoir des regressions, surtout quand le soft est gros, que plein de softs sont bases dessus, ... personne n'est parfait et peut tester tous les scenarios possibles, nous non plus.
Bien sûr que ca arrive à tout le monde d'avoir des bugs ...
Avoue tout de même que c'est balot de retarder au dernier moment un patchset trés attendu parce qu'un bug majeur est justement tout juste mis en valeur ;-)
Je ne pense pas que ce soit un bug majeur. Pour une fois que microsoft fait les choses bien, éviter la perte de données à quelques centaines d'entreprises, c'est une action acceptable.
Heu, il ne s'adresse pas forcément à toi, je trouve que c'est aussi paradoxal, mais on peut aussi arrêter l'hypocrisie une seconde et remarquer que c'est un fait, M$ prend ses responsabilités (tout est relatif) en retardant un patch (deux) parce qu'ils ne sont pas ok.
Parce que la situation étant ce qu'elle est pour M$, il n'ont le choix qu'entre deux choses : repousser le patch pour le retravailler, ou le mettre à dispo avec les erreurs qu'il entraine. La meilleure option, c'est laquelle d'après toi (sans nous dire que c'est de changer de licence ou de passer sous linux, merci) ?
RIen a voir avec des pertes irrémédiable de donnée.
Les exemples que tu donnes sont mauvais ! Apple mets a jour rsync par rsync, apache_mod_php par apache_mod_php.
Le bug des SP n'est pas une simple "regression" d'une appli tierce mais une perte irrémédiable des données primordiale d'un logiciel de gestion des ventes !! Explique donc aux entreprises qui ont perdu leurs données et une semaine pour tout reinstaller de zero, que c'est une simple "regression" !!
De toute façon MS est coutumier du fait, n'est-ce pas aussi Microsoft Home Server qui corromp les données des applis MS OneNote 2003/2007, Outlook 2007, Money 2007, Windows Vista Photo Gallery , Windows Live Photo Gallery... ?
Il y a clairement là une erreur de positionnement du produit, il aurait fallu le nommer Microsoft Home Trash !!
Les exemples que tu donnes sont mauvais ! Apple mets a jour rsync par rsync, apache_mod_php par apache_mod_php.
Le bug des SP n'est pas une simple "regression" d'une appli tierce mais une perte irrémédiable des données primordiale d'un logiciel de gestion des ventes !! Explique donc aux entreprises qui ont perdu leurs données et une semaine pour tout reinstaller de zero, que c'est une simple "regression" !!
C'est exactement le meme probleme que le cas IBM que j'ai donne : un changement de comportement dans une librairie fait que l'appli se comporte differement. Selon l'appli ca peut causer perte de donnees ou pas. Ici avec RMS c'eest le cas, si tu regardes IBM, les applis faisant appel a cet API pourraient elles aussi corrompre leurs donnees selon la maniere dont elles sont concues.
De toute façon MS est coutumier du fait, n'est-ce pas aussi Microsoft Home Server qui corromp les données des applis MS OneNote 2003/2007, Outlook 2007, Money 2007, Windows Vista Photo Gallery , Windows Live Photo Gallery... ?
Il y avait Home Server oui, les autres je n'en ai pas souvenir.
Un truc que je trouve hallucinant, c'est le niveau déplorable de l'informatique en entreprise.
Le rôle d'une informaticien d'entreprise devrait être avant tout de faire en sorte qu'en cas de gros problèmes, la situation puisse revenir à la situation initial dans les plus brefs délai.
Au prix des supports de stockage actuels, ce n'est pas en plus une grosse dépense.
Là, c'est un problème logiciel, mais si le disque dûr était tombé en panne ?
C'est malheureusement un cas super fréquent dans les boites.
Remettre un ordinateur en état suite a quoi que ce soit ne devrait jamais prendre plus de quelques heures, sinon, c'est que l'informaticien à mal fait son travail, et cela semble est trop souvent fréquent dans le monde de l'entreprise.
PS : ça m'est venu en tête là, j'avais envie de l'écrire mais ce n'est pas forcément une réponse à ton commentaire. Je ne critique ni ne défent ici Microsoft sur ce service pack, même si je trouve leurs produits de très mauvaises qualitée (et vu leur CA et surtout leur bénéfices, je trouve même que c'est prendre les clients pour des cons), mais là, c'est la faute de ceux qui s'occupe de l'informatique dans les entreprises.
Je te rassure tout de suite : dans les grandes structures, normalement, on teste les mises à jour avant de les appliquer sur les systèmes en production.
Normalement, on teste les mises à jour sur la plate-forme de test, puis celle de pré-production avant de passer à celle de production, une fois que tout s'est bien passé.
Normalement, la plate-forme de pré-production doit être exactement semblable à celle de production, point par point.
Sauf qu'on voit des fois des cas où ils mettent à jour celle de production directement, puis celle de pré-production afin qu'elles soient toujours pareil. Va expliquer à ces gens-là que la seconde plate-forme ne sert plus à rien...
C'est les 2 en fait, le soft est victime d'un changement de comportement du code de l'OS, a cause de ce changement de comportement, le soft se comporte d'une facon differente et corrompt les donnees qu'il ecrit.
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 ...
Les mauvaises langues diront que la documentation n'est pas le point fort de microsoft, mais un changement aussi important dans les fonctionnalités proposées par ces bibli ne devrait pas exister pour un os aussi utilisé dans le monde professionnel, et donc vu le nombre de logiciels utilisant (risquant d'utiliser) ces fonctionnalités, devraient rester figées.
Bref, soit j'ai mal compris (fort probable), soit je trouve que c'est abhérent.
Si d'ailleurs quelqu'un avait plus d'infos sur le dit problème... (pbpg ?)
* message analysé au détecteur de troll - risque > 50% *
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...
Moi ce qui me gêne en fait c'est le fait que les Service Pack ne soient pas juste l'ensemble des patchs appliqués au système. Pourquoi le Service Pack doit-il changer une librairie de haut niveau ? Pour un bug ou un problème de sécurité ? Si oui, alors pourquoi ça n'a pas été patché avant ?
Quand debian sort une rX pour stable, c'est juste les paquets de stable en incluant les corrections de bugs et de failles, rien de plus...
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.
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.
D'accord, donc vous avez des patchs privés qui se promènent en plus...
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.
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.
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.
Après, si l'interface est trop complexe, c'est un autre problème, mais c'est indépendant de la complexité d'une preuve de code.
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.
Ben si, si le code est correct, il fait la même chose que le code d'avant
(à condition que le code d'avant soit correct)
Je dirai même que tu donne comme spécification de ton code, truc nécessaire pour vérifier la correction du code, par "il doit faire exactement ce qu'il faisait avant".
Je voulais signifier qu'on est loin d'avoir besoin de prouver que le code est correct pour découvrir ce genre de bug et pour que le test soit efficace.
Bon après c'est sûr que ça ne marche qu'avec un programme déterministe...
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...
tu vois bien, chez Apple les mise à jour ne sont jamais décalé...
Sous linux, ça attend d'être prêt pour sortir...
Microsoft commence à faire pareil, c'est plutôt une bonne chose. Vous imaginez s'ils avaient attendu d'enlever les bugs avant de commercialiser leurs produits, on utiliserait tous un OS sans aucun bug : Windows 3.11
mouais... j'ai un cas assez récent en tête d'une distribution orientée vers le "Grand" public, qui est pourtant sortie avant que toutes les corrections de bugs trouvés sur la RC soient faites...
Sous Linux aussi, il y a des dates clefs plus ou moins faciles à contourner... Et desfois, certains problèmes (rarement graves) sont connus avant une sortie...
Cette presse à la botte de Microsoft me donne toujours envie de vomir.
SP3 était donc "attendu avec fébrilité". Ça, c'est l'événement, incontournable (quel con, je n'étais même pas au courant) .
Puis vient la fatalité, un bug "découvert". Et horrible, "perte irrémédiable de données".
Et là, magnifique :
"Les développeurs travaillent d'arrache-pied".
Tel des bénévoles face à une catastrophe naturelle (imprévisible bien sûr, et dont personne n'est responsable).
A travers un tel article, Microsoft ressort finalement superbe de cette cagade.
Bon, suite au titre (accrocheur) de ce journal, je me suis un peu renseigné pour ma culture personnelle, et j'ai essayé de lire et de comprendre les messages ci-dessus.
Il y'a plusieurs choses qui me choquent. D'une je n'étais pas au courant de la sortie de ce SP3, mais peut-être est-ce dû à mon désinterrêt pour ce système, tout comme frayd ci-dessus. Mais ce n'est pas le pire.
Si j'ai bien tout compris, RMS est un logiciel édité par la branche solutions commerciales de Microsoft. Et le SP3 est produit par la même société, dans une branche différente.
Alors bon. Sujet à troll : déjà, laisser son commerce géré par des applis de ce type, ça me ferait froid dans le dos, si j'étais chef d'entreprise. Mais qu'une société ne soit pas capable de tester ses propres produits entre eux, ça, ça me fait vraiment peur.
Je suis bien conscient que ce sont deux branches distinctes de la même société, et j'ose espérer que les codeurs de RMS ne sont pas les mêmes qui codent les SP et autres joyeusetés de cet OS, mais quand même.
D'ailleurs pBpG dit bien Cette librairie a ete modifiee par une requete d'une societe ? Ben oui, c'est la même... De ce fait, cette branche de Microsoft était probablement une des mieux placées, sinon la mieux placée pour tester le SP avec son produit avant sa sortie officielle, non ?
Ou alors gogole ne m'a pas expédié vers le bon site et ce n'est pas la même application... Eprès tout, RMS ça peut vouloir dire plein de choses.
D'ailleurs pBpG dit bien Cette librairie a ete modifiee par une requete d'une societe ? Ben oui, c'est la même...
D'après ce que j'ai compris, la société qui a demandé le patch n'est pas celle qui édite RMS.
Mais par contre c'est avec RMS que ce patch présente un bug.
Ouai enfin bon la base de code que gère MS est quand meme grande, et le fait est qu'ils _ont_ découvert le problème avant la sortie officielle. Donc sur ce coup la je crois qu'il faut dire bravo ! Je préfère les logiciels qui ont le moins de bug possible, et je crois que c'est le cas de beaucoup de monde...
Je n'arrive plus à retrouver la référence(sur wikipédia) mais je me souviens d'une comparaison du nombre de ligne de code (ok ça veux pas dire grand chose) entre Windows et le projet Debian. Debian était nettement plus gros que XP.
De plus Debian doit s'accommoder des modifications de nombreux acteurs tiers. Alors bon ta félicitation ....
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é.
Oui mais en entreprise c'est plus compliqué. Les programmeurs bossent sur des choses qu'ils n'aiment pas forcément, l'organisation est plus compliquée, le chef de projet vous impose des méthodes de génie logiciel et des trucs UML bizarres, les marqueteux rajoute une couche, bref, respect.
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...
> Maintenant, tu as connaissance de toutes les regressions qui sont introduites dans Debian ?
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é !
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.
Au final, un système stable, léger et performant au lieu d'une accumulation de patch, de correction et l'obligation de conserver un comportement buggé par conception afin de conserver une compatibilité et "stbilité" de l'écosystème propriétaire.
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é !
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 !!
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...
> Windows 64bits va tres bien merci pour lui, la derniere version d'Exchange n'existe qu'en 64bits d'ailleurs, c'est tout dire...
Bien joué :)
Fallait bien trouver une manière de forcer les entreprises captives à utiliser Win 64... et par levier à forcer les constructeurs et éditeurs à développer pour cette plate forme.
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.
> 20Go ? J'etais pas au courant... mais il est vrai qu'il prend trop de place, la version serveur elle prend bcp moins.
Par acquis de conscience, j'ai quand même vérifier sur le net... si mes constatations étaient partagées. En fait je suis en dessous des recommandations officielles de Microsoft !
Windows Vista Édition Familiale Premium, Windows Vista Professionnel, Windows Vista Entreprise et Windows Vista Édition Intégrale
Disque dur de 40 Go disposant de 15 Go d'espace libre (pour le stockage des fichiers temporaires lors de l'installation ou de la mise à niveau)
Windows Vista Édition Familiale Basique
Disque dur de 20 gigaoctets (Go) disposant de 15 Go d'espace libre
Le familiale basique semble plus légère... mais je ne l'ai jamais vu.
Le familiale basique semble plus légère... mais je ne l'ai jamais vu.
C'est celle qui sera sur le OLPC donc < 2Gigs... Ah non c'est vrai sur celui la meme un vieux systeme basique redmondien de 8 ans d'ages a du mal a rentrer!
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...
pourquoi les installer si l'utilisateur en a pas besoin ?
Parce que demander un cd pour rajouter tel ou tel truc (typiquement quand tu souhaite changer de langue la première fois sous un xp), ca windows sait faire, alors pourquoi mettre des trucs qui sont inutiles ?
> L'ensemble des logiciels est libre ? Oracle est libre ? Acrobat est libre ? ...
> Desole, mais c'est loin d'etre le cas.
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.
Aux éditeurs de logiciels propriétaires de suivre de rhythme de développement de Linux. Et pour les applis critiques comme Oracle, à Oracle de certifier les distributions Linux avec laquelle sa base de données fonctionne...
D'ailleurs Oracle, contribue upstream à Linux afin d'améliorer les performances du kernel, et supporte par ailleurs elle même sa propre distribution Linux pour une compatibilité totale avec sa base de données. Cela n'est possible que grace à l'ouverture du code source et la possibilité de modifier et distribuer ses améliorations...
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.
> 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...
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.
C'est le cas à chaque nouvelle version de RHEL.
Passage du kernel 2.4 à 2.6.
Mise à jour de la GLibC et des Threads
Mise à jour de GCC et de la libstdc++
J'ai eu a réinstaller une machine en RHEL 3 pour une appli propriétaire de Visualisation Geophysique certifié pour cette distrib. Je pensais que l'appli pouvait tourner sur une RHEL4... J'avais tord ! L'appli figeait aléatoirement dés que l'on forçait un peu sur la 3D...
J'ai une poignée d'autres expérience de ce type avec des compilos fortran propriétaires, des bibliothèques MPI.
J'ai même l'expérience d'une appli "userland" qui compile et tourne sur un 2.4 sans problème et qui compile mais ne tourne pas sur un 2.6 !
Dés fois il existe des contournements pour faire tourner une vielle appli sur une distrib plus récente, mais ce n'est franchement pas la priorité des dev du kernel ou de la glibc... Pour t'en convaincre, il suffit de listes les listes de diffusions.
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 ?
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.
/* 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 */
/* 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 */"
Ho quel mauvais exemple !!
Tu me sort un bout de code du kernel 2.4 concernant le *systeme de fichiers* UMSDOS... qui n'est plus maintenu depuis 7 ans et qui a DISPARU DANS LE 2.6 !!
A cette époque, UMSDOS était un système de fichier servant a installer Linux sur une partition FAT12. Modifier la structure "on disk" d'UMSDOS aurait tout simplement rendu les installations existantes de Linux sur une partitions DOS inexploitables.
RIen a voir avec la nécessité d'être compatible avec une appli proprio.
Aujourd'hui encore, les kernel hacker font leur possible pour que les modification apporté aux systèmes de fichiers soit compatible de manière ascendante. Lorsque les modifications deviennent trop importantes et trop risquées, ils prennent la décision de crée une nouvelle branche distincte.
Exemple ext4, ext3 et ext2. bien qu'ils assurent respectivement une compatibilité ascendante, l'importance de la comptatibilité est primordiale afin de ne pas prendre le risque de perdre des données.
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.
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.
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.
> 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.
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...
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.
> 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 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.
Par ailleurs ce genre de base de données a sa machine dédiée. L'OS et le logiciel ne font qu'un. Une mise à jour s'enviseage de manière globale, ( matériel + OS + Base de données)
Oracle has a large-scale testing infrastructure where we test new Linux releases using real-world -- sometimes very large-- customer workloads. I expect testing of RHEL5 to take another few weeks to ensure stability, robustness and interoperability. Once RHEL5 passes the tests, we will release Enterprise Linux 5, downloadable for free, and will begin offering support through the Unbreakable Linux Support program.
what versions of RAC databases supported on RHEL 5.0?
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.
Pas du tout : on ne change surtout pas un truc qui tourne en production.
La seule raison d'une migration, c'est la fin du support de la version actuellement utilisée, que ce soit via l'éditeur original ou un tiers.
On trouve encore beaucoup de RHEL3, des Debian 3.x, etc...
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.
> Certaines societes font cela (certains demandent encore un support NT4 apres tout...),
Oui, moi j'aimerai bien !
La semaine dernière j'ai passé un peu plus de 3 jours a réussir a réinstaller NT 4 (retour en enfer) sur un chromatographe d'exclusion stérique.
Curieusement, ce chromatographe acheté en 2002 était livré neuf sous NT4 !! (Perso si j'avais eu a effectuer l'achat, je n'aurais jamais accepté cette arnaque)
Aujourd'hui, le constructeur demande une petite fortune pour fournir le soft de pilotage compatible avec Win 2000 !!
Entre payer une fortune a des escrocs revendeurs de matériel spécialisé, ou passer 3 jours a faire tourner NT4 sur du matériel trop récent pour lui... J'ai choisis de me tuer à la tache et j'en ai bavé :/ Je me suis rappelé pourquoi j'ai basculé sous Linux en 95 :o))
Je n'ai pas non plus dit que les entreprises attendaient forcément la fin du support pour migrer, fort heureusement pour elles.
Les test de migration peuvent en effet prendre des mois.
Cela étant : le système reste moins important que les applications.
Si l'application ne le requiert pas, le système restera bien souvent tel qu'il est et ne bougera pas. Tout est une question de risques bien calculés.
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 ?
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.
Simplement, avec Linux, il peut créer sa propre distribution, son propre système, sans payer de licences à qui que ce soit. Évidemment, ça demandera un investissement pour le support par ses services mais cela est également valable avec chaque système d'exploitation avec lesquels il est possible d'installer Oracle et pour lesquels c'est officiellement supporté.
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.
Sauf que RedHat a été créée il y a plus de 12 ans...
Leurs premiers bénéfices sont arrivés 7 ans après.
Le pari était très loin d'être gagné, à l'époque.
Pas mieux, à la lecture du titre j'ai crue que Richard Stallman avais découvert un disfonctionnement atteignant je ne sais quel liberté, que personne ni même crosoft ne pouvais réfuter et que du coup le gouvernement obligé Crosoft à revoir ça copie...
# Excellent
Posté par abramov_MS . Évalué à 8.
J'aime beaucoup la conclusion de l'article qui souligne bien que pour un OS ayant osit disant ete re-ecrit a 100% les bugs affectant XP affectent aussi Vista.
[^] # Re: Excellent
Posté par pasBill pasGates . Évalué à 7.
Vista n'a jamais ete une reecriture a 100% et MS ne l'a jamais insinue.
[^] # Re: Excellent
Posté par Christophe Merlet (site web personnel) . Évalué à 10.
[^] # Re: Excellent
Posté par abramov_MS . Évalué à 8.
[^] # Re: Excellent
Posté par pasBill pasGates . Évalué à 9.
[^] # Re: Excellent
Posté par Christophe Merlet (site web personnel) . Évalué à 9.
[^] # Re: Excellent
Posté par modr123 . Évalué à 4.
[^] # Re: Excellent
Posté par brunus (site web personnel) . Évalué à 2.
[^] # Re: Excellent
Posté par arapaho . Évalué à 2.
Non effectivement. Mais le bureau est différent de celui Windows Millenium.
[^] # Re: Excellent
Posté par brunus (site web personnel) . Évalué à 6.
[^] # Re: Excellent
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
"La première sécurité est la liberté"
[^] # Re: Excellent
Posté par ashram4 . Évalué à 2.
Sous MS Windows 2000 quand on indique "no sound" pour le changement de volume on a un beep speaker à chaque changement de volume. Sous XP c'est encore le cas. Est ce que c'est toujours pareil sous Vista? (je n'ai jamais utilisé de Vista)
# Apple , HP ou Sun
Posté par libre Cuauhtémoc . Évalué à -3.
Jamais vu d'update de MacOS X de décalé, et les patchadd ne font jamais planté ma machine.
Microsoft , en restant proprio, devrait prendre exemple sur Microsoft.
[^] # Re: Apple , HP ou Sun
Posté par pasBill pasGates . Évalué à 10.
B) Ca arrive chez Apple aussi : http://docs.info.apple.com/article.html?artnum=303453
The following non-security issues introduced by Security Update 2006-001 are also addressed by this update:
Download Validation: Security Update 2006-001 could cause the user to be warned when provided with certain safe file types, such as Word documents, and folders containing custom icons. These unneeded warnings are removed with this update.
apache_mod_php: A regression in PHP 4.4.1 that could prevent SquirrelMail from functioning is corrected with this update.
rsync: A regression in rsync that prevented the "--delete" command line option from functioning is corrected with this update.
Tout comme IBM : http://blog.vinceschuurman.com/vince/home/ndt4.nsf/(LUBlogCo(...)
Ca arrive chez Mozilla aussi d'ailleurs : http://www.mozillazine.org/talkback.html?article=22741
Pour etre precis, ca arrive a tout le monde d'avoir des regressions, surtout quand le soft est gros, que plein de softs sont bases dessus, ... personne n'est parfait et peut tester tous les scenarios possibles, nous non plus.
[^] # Re: Apple , HP ou Sun
Posté par Guinns . Évalué à 2.
Avoue tout de même que c'est balot de retarder au dernier moment un patchset trés attendu parce qu'un bug majeur est justement tout juste mis en valeur ;-)
[^] # Re: Apple , HP ou Sun
Posté par yellowiscool . Évalué à 9.
Envoyé depuis mon lapin.
[^] # Re: Apple , HP ou Sun
Posté par Guinns . Évalué à 0.
C'est de l'ironie ???
Et je n'ai jamais reproché à M$ de retarder son patchset, faudrait un peu apprendre à lire avant de répondre !
[^] # Re: Apple , HP ou Sun
Posté par Quikeg . Évalué à 5.
Parce que la situation étant ce qu'elle est pour M$, il n'ont le choix qu'entre deux choses : repousser le patch pour le retravailler, ou le mettre à dispo avec les erreurs qu'il entraine. La meilleure option, c'est laquelle d'après toi (sans nous dire que c'est de changer de licence ou de passer sous linux, merci) ?
[^] # Re: Apple , HP ou Sun
Posté par Christophe Merlet (site web personnel) . Évalué à 10.
Les exemples que tu donnes sont mauvais ! Apple mets a jour rsync par rsync, apache_mod_php par apache_mod_php.
Le bug des SP n'est pas une simple "regression" d'une appli tierce mais une perte irrémédiable des données primordiale d'un logiciel de gestion des ventes !! Explique donc aux entreprises qui ont perdu leurs données et une semaine pour tout reinstaller de zero, que c'est une simple "regression" !!
De toute façon MS est coutumier du fait, n'est-ce pas aussi Microsoft Home Server qui corromp les données des applis MS OneNote 2003/2007, Outlook 2007, Money 2007, Windows Vista Photo Gallery , Windows Live Photo Gallery... ?
Il y a clairement là une erreur de positionnement du produit, il aurait fallu le nommer Microsoft Home Trash !!
[^] # Re: Apple , HP ou Sun
Posté par pasBill pasGates . Évalué à 2.
Le bug des SP n'est pas une simple "regression" d'une appli tierce mais une perte irrémédiable des données primordiale d'un logiciel de gestion des ventes !! Explique donc aux entreprises qui ont perdu leurs données et une semaine pour tout reinstaller de zero, que c'est une simple "regression" !!
C'est exactement le meme probleme que le cas IBM que j'ai donne : un changement de comportement dans une librairie fait que l'appli se comporte differement. Selon l'appli ca peut causer perte de donnees ou pas. Ici avec RMS c'eest le cas, si tu regardes IBM, les applis faisant appel a cet API pourraient elles aussi corrompre leurs donnees selon la maniere dont elles sont concues.
De toute façon MS est coutumier du fait, n'est-ce pas aussi Microsoft Home Server qui corromp les données des applis MS OneNote 2003/2007, Outlook 2007, Money 2007, Windows Vista Photo Gallery , Windows Live Photo Gallery... ?
Il y avait Home Server oui, les autres je n'en ai pas souvenir.
[^] # Re: Apple , HP ou Sun
Posté par Psychofox (Mastodon) . Évalué à 9.
[^] # Re: Apple , HP ou Sun
Posté par seginus . Évalué à 5.
Le rôle d'une informaticien d'entreprise devrait être avant tout de faire en sorte qu'en cas de gros problèmes, la situation puisse revenir à la situation initial dans les plus brefs délai.
Au prix des supports de stockage actuels, ce n'est pas en plus une grosse dépense.
Là, c'est un problème logiciel, mais si le disque dûr était tombé en panne ?
C'est malheureusement un cas super fréquent dans les boites.
Remettre un ordinateur en état suite a quoi que ce soit ne devrait jamais prendre plus de quelques heures, sinon, c'est que l'informaticien à mal fait son travail, et cela semble est trop souvent fréquent dans le monde de l'entreprise.
PS : ça m'est venu en tête là, j'avais envie de l'écrire mais ce n'est pas forcément une réponse à ton commentaire. Je ne critique ni ne défent ici Microsoft sur ce service pack, même si je trouve leurs produits de très mauvaises qualitée (et vu leur CA et surtout leur bénéfices, je trouve même que c'est prendre les clients pour des cons), mais là, c'est la faute de ceux qui s'occupe de l'informatique dans les entreprises.
[^] # Re: Apple , HP ou Sun
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Re: Apple , HP ou Sun
Posté par Batchyx . Évalué à 3.
[^] # Re: Apple , HP ou Sun
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Normalement, la plate-forme de pré-production doit être exactement semblable à celle de production, point par point.
Sauf qu'on voit des fois des cas où ils mettent à jour celle de production directement, puis celle de pré-production afin qu'elles soient toujours pareil. Va expliquer à ces gens-là que la seconde plate-forme ne sert plus à rien...
[^] # Re: Apple , HP ou Sun
Posté par vladislav askiparek . Évalué à 5.
01net.com: Son installation sur des PC faisant tourner Dynamics RMS se traduit par des pertes irrémédiables de données
C'est pas exactement la même chose. Qui a tord, qui a raison?
[^] # Re: Apple , HP ou Sun
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: Apple , HP ou Sun
Posté par Elfir3 . Évalué à 6.
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 ...
Les mauvaises langues diront que la documentation n'est pas le point fort de microsoft, mais un changement aussi important dans les fonctionnalités proposées par ces bibli ne devrait pas exister pour un os aussi utilisé dans le monde professionnel, et donc vu le nombre de logiciels utilisant (risquant d'utiliser) ces fonctionnalités, devraient rester figées.
Bref, soit j'ai mal compris (fort probable), soit je trouve que c'est abhérent.
Si d'ailleurs quelqu'un avait plus d'infos sur le dit problème... (pbpg ?)
* message analysé au détecteur de troll - risque > 50% *
[^] # Re: Apple , HP ou Sun
Posté par pasBill pasGates . Évalué à 5.
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...
[^] # Re: Apple , HP ou Sun
Posté par vladislav askiparek . Évalué à -10.
pasBill pasGates envoie RMS au panthéon des soft reconnus et adulés:
...RMS est le seul soft...
Reprends-toi, pbpg, c'est une icône du (extrêmement) libre, mais ce n'est pas encore un soft, et encore moins le Hurd personnalisé.
[^] # Re: Apple , HP ou Sun
Posté par Elfir3 . Évalué à 1.
[^] # Re: Apple , HP ou Sun
Posté par modr123 . Évalué à 5.
[^] # Re: Apple , HP ou Sun
Posté par Pinaraf . Évalué à 1.
Quand debian sort une rX pour stable, c'est juste les paquets de stable en incluant les corrections de bugs et de failles, rien de plus...
[^] # Re: Apple , HP ou Sun
Posté par pasBill pasGates . Évalué à 1.
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.
[^] # Re: Apple , HP ou Sun
Posté par Pinaraf . Évalué à 1.
D'accord, donc vous avez des patchs privés qui se promènent en plus...
Brrrr
[^] # Re: Apple , HP ou Sun
Posté par pasBill pasGates . Évalué à 3.
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.
[^] # Re: Apple , HP ou Sun
Posté par Cédric Chevalier (site web personnel) . Évalué à 2.
[^] # Re: Apple , HP ou Sun
Posté par pasBill pasGates . Évalué à 7.
[^] # Re: Apple , HP ou Sun
Posté par Cédric Chevalier (site web personnel) . Évalué à 1.
Après, si l'interface est trop complexe, c'est un autre problème, mais c'est indépendant de la complexité d'une preuve de code.
[^] # Re: Apple , HP ou Sun
Posté par pasBill pasGates . Évalué à 3.
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.
[^] # Re: Apple , HP ou Sun
Posté par Thomas Douillard . Évalué à 1.
(à condition que le code d'avant soit correct)
Je dirai même que tu donne comme spécification de ton code, truc nécessaire pour vérifier la correction du code, par "il doit faire exactement ce qu'il faisait avant".
[^] # Re: Apple , HP ou Sun
Posté par Cédric Chevalier (site web personnel) . Évalué à 2.
Bon après c'est sûr que ça ne marche qu'avec un programme déterministe...
[^] # Re: Apple , HP ou Sun
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Apple , HP ou Sun
Posté par Dr BG . Évalué à 3.
[^] # Re: Apple , HP ou Sun
Posté par Axel R. (site web personnel) . Évalué à 2.
Sous linux, ça attend d'être prêt pour sortir...
Microsoft commence à faire pareil, c'est plutôt une bonne chose. Vous imaginez s'ils avaient attendu d'enlever les bugs avant de commercialiser leurs produits, on utiliserait tous un OS sans aucun bug : Windows 3.11
Axel
[^] # Re: Apple , HP ou Sun
Posté par snt . Évalué à 3.
euh plus tout à fait : http://linuxfr.org/2008/04/26/23995.html
[^] # Re: Apple , HP ou Sun
Posté par pampryl . Évalué à 7.
mouais... j'ai un cas assez récent en tête d'une distribution orientée vers le "Grand" public, qui est pourtant sortie avant que toutes les corrections de bugs trouvés sur la RC soient faites...
Sous Linux aussi, il y a des dates clefs plus ou moins faciles à contourner... Et desfois, certains problèmes (rarement graves) sont connus avant une sortie...
# Fatalité
Posté par frayd . Évalué à 10.
Cette presse à la botte de Microsoft me donne toujours envie de vomir.
SP3 était donc "attendu avec fébrilité". Ça, c'est l'événement, incontournable (quel con, je n'étais même pas au courant) .
Puis vient la fatalité, un bug "découvert". Et horrible, "perte irrémédiable de données".
Et là, magnifique :
"Les développeurs travaillent d'arrache-pied".
Tel des bénévoles face à une catastrophe naturelle (imprévisible bien sûr, et dont personne n'est responsable).
A travers un tel article, Microsoft ressort finalement superbe de cette cagade.
[^] # Re: Fatalité
Posté par Obsidian . Évalué à 4.
Ça veut dire qu'en fait, ils jouent au démineur ?
# Oups, j'ma gourré...
Posté par Gyro Gearllose . Évalué à 2.
Il y'a plusieurs choses qui me choquent. D'une je n'étais pas au courant de la sortie de ce SP3, mais peut-être est-ce dû à mon désinterrêt pour ce système, tout comme frayd ci-dessus. Mais ce n'est pas le pire.
Si j'ai bien tout compris, RMS est un logiciel édité par la branche solutions commerciales de Microsoft. Et le SP3 est produit par la même société, dans une branche différente.
Alors bon. Sujet à troll : déjà, laisser son commerce géré par des applis de ce type, ça me ferait froid dans le dos, si j'étais chef d'entreprise. Mais qu'une société ne soit pas capable de tester ses propres produits entre eux, ça, ça me fait vraiment peur.
Je suis bien conscient que ce sont deux branches distinctes de la même société, et j'ose espérer que les codeurs de RMS ne sont pas les mêmes qui codent les SP et autres joyeusetés de cet OS, mais quand même.
D'ailleurs pBpG dit bien Cette librairie a ete modifiee par une requete d'une societe ? Ben oui, c'est la même... De ce fait, cette branche de Microsoft était probablement une des mieux placées, sinon la mieux placée pour tester le SP avec son produit avant sa sortie officielle, non ?
Ou alors gogole ne m'a pas expédié vers le bon site et ce n'est pas la même application... Eprès tout, RMS ça peut vouloir dire plein de choses.
[^] # Re: Oups, j'ma gourré...
Posté par ciol . Évalué à -10.
[^] # Re: Oups, j'ma gourré...
Posté par pampryl . Évalué à 9.
[^] # Re: Oups, j'ma gourré...
Posté par Dinofly (site web personnel) . Évalué à 3.
D'après ce que j'ai compris, la société qui a demandé le patch n'est pas celle qui édite RMS.
Mais par contre c'est avec RMS que ce patch présente un bug.
[^] # Re: Oups, j'ma gourré...
Posté par Guillaume Knispel . Évalué à 3.
[^] # Re: Oups, j'ma gourré...
Posté par Jean B . Évalué à 4.
De plus Debian doit s'accommoder des modifications de nombreux acteurs tiers. Alors bon ta félicitation ....
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é.
[^] # Re: Oups, j'ma gourré...
Posté par ciol . Évalué à -6.
[^] # Re: Oups, j'ma gourré...
Posté par pasBill pasGates . Évalué à 3.
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...
[^] # Re: Oups, j'ma gourré...
Posté par Christophe Merlet (site web personnel) . Évalué à 1.
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é !
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.
Au final, un système stable, léger et performant au lieu d'une accumulation de patch, de correction et l'obligation de conserver un comportement buggé par conception afin de conserver une compatibilité et "stbilité" de l'écosystème propriétaire.
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é !
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 !!
[^] # Re: Oups, j'ma gourré...
Posté par pasBill pasGates . Évalué à 2.
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...
[^] # Re: Oups, j'ma gourré...
Posté par Christophe Merlet (site web personnel) . Évalué à 3.
Bien joué :)
Fallait bien trouver une manière de forcer les entreprises captives à utiliser Win 64... et par levier à forcer les constructeurs et éditeurs à développer pour cette plate forme.
[^] # Re: Oups, j'ma gourré...
Posté par pasBill pasGates . Évalué à 2.
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.
[^] # Re: Oups, j'ma gourré...
Posté par Christophe Merlet (site web personnel) . Évalué à 1.
Par acquis de conscience, j'ai quand même vérifier sur le net... si mes constatations étaient partagées. En fait je suis en dessous des recommandations officielles de Microsoft !
Windows Vista Édition Familiale Premium, Windows Vista Professionnel, Windows Vista Entreprise et Windows Vista Édition Intégrale
Disque dur de 40 Go disposant de 15 Go d'espace libre (pour le stockage des fichiers temporaires lors de l'installation ou de la mise à niveau)
Windows Vista Édition Familiale Basique
Disque dur de 20 gigaoctets (Go) disposant de 15 Go d'espace libre
Le familiale basique semble plus légère... mais je ne l'ai jamais vu.
[^] # Re: Oups, j'ma gourré...
Posté par abramov_MS . Évalué à 2.
C'est celle qui sera sur le OLPC donc < 2Gigs... Ah non c'est vrai sur celui la meme un vieux systeme basique redmondien de 8 ans d'ages a du mal a rentrer!
[^] # Re: Oups, j'ma gourré...
Posté par pasBill pasGates . Évalué à 1.
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...
[^] # Re: Oups, j'ma gourré...
Posté par briaeros007 . Évalué à 4.
Parce que demander un cd pour rajouter tel ou tel truc (typiquement quand tu souhaite changer de langue la première fois sous un xp), ca windows sait faire, alors pourquoi mettre des trucs qui sont inutiles ?
[^] # Re: Oups, j'ma gourré...
Posté par Christophe Merlet (site web personnel) . Évalué à 4.
> Desole, mais c'est loin d'etre le cas.
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.
Aux éditeurs de logiciels propriétaires de suivre de rhythme de développement de Linux. Et pour les applis critiques comme Oracle, à Oracle de certifier les distributions Linux avec laquelle sa base de données fonctionne...
D'ailleurs Oracle, contribue upstream à Linux afin d'améliorer les performances du kernel, et supporte par ailleurs elle même sa propre distribution Linux pour une compatibilité totale avec sa base de données. Cela n'est possible que grace à l'ouverture du code source et la possibilité de modifier et distribuer ses améliorations...
[^] # Re: Oups, j'ma gourré...
Posté par pasBill pasGates . Évalué à 1.
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.
[^] # Re: Oups, j'ma gourré...
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
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.
C'est le cas à chaque nouvelle version de RHEL.
Passage du kernel 2.4 à 2.6.
Mise à jour de la GLibC et des Threads
Mise à jour de GCC et de la libstdc++
J'ai eu a réinstaller une machine en RHEL 3 pour une appli propriétaire de Visualisation Geophysique certifié pour cette distrib. Je pensais que l'appli pouvait tourner sur une RHEL4... J'avais tord ! L'appli figeait aléatoirement dés que l'on forçait un peu sur la 3D...
J'ai une poignée d'autres expérience de ce type avec des compilos fortran propriétaires, des bibliothèques MPI.
J'ai même l'expérience d'une appli "userland" qui compile et tourne sur un 2.4 sans problème et qui compile mais ne tourne pas sur un 2.6 !
Dés fois il existe des contournements pour faire tourner une vielle appli sur une distrib plus récente, mais ce n'est franchement pas la priorité des dev du kernel ou de la glibc... Pour t'en convaincre, il suffit de listes les listes de diffusions.
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 ?
[^] # Re: Oups, j'ma gourré...
Posté par pasBill pasGates . Évalué à 1.
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 */
[^] # Re: Oups, j'ma gourré...
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
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 */"
Ho quel mauvais exemple !!
Tu me sort un bout de code du kernel 2.4 concernant le *systeme de fichiers* UMSDOS... qui n'est plus maintenu depuis 7 ans et qui a DISPARU DANS LE 2.6 !!
A cette époque, UMSDOS était un système de fichier servant a installer Linux sur une partition FAT12. Modifier la structure "on disk" d'UMSDOS aurait tout simplement rendu les installations existantes de Linux sur une partitions DOS inexploitables.
RIen a voir avec la nécessité d'être compatible avec une appli proprio.
Aujourd'hui encore, les kernel hacker font leur possible pour que les modification apporté aux systèmes de fichiers soit compatible de manière ascendante. Lorsque les modifications deviennent trop importantes et trop risquées, ils prennent la décision de crée une nouvelle branche distincte.
Exemple ext4, ext3 et ext2. bien qu'ils assurent respectivement une compatibilité ascendante, l'importance de la comptatibilité est primordiale afin de ne pas prendre le risque de perdre des données.
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.
[^] # Re: Oups, j'ma gourré...
Posté par pasBill pasGates . Évalué à 1.
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.
[^] # Re: Oups, j'ma gourré...
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
En aucun cas la décision a été motivé par l'existence de logiciel propriétaire utilisant l'ioctl.
Cela ne les empechera pas non plus de casser l'ABI si ça en vaut le coup... comme ça http://thread.gmane.org/gmane.comp.video.video4linux/37581
J'ai volontairement choisi un exemple autour de V4L2 pour rester dans le sujet...
> 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.
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...
[^] # Re: Oups, j'ma gourré...
Posté par pasBill pasGates . Évalué à 1.
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.
[^] # Re: Oups, j'ma gourré...
Posté par Christophe Merlet (site web personnel) . Évalué à 3.
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.
Par ailleurs ce genre de base de données a sa machine dédiée. L'OS et le logiciel ne font qu'un. Une mise à jour s'enviseage de manière globale, ( matériel + OS + Base de données)
Allez, je ne te sens pas convaincu, alors voici ce que dit Oracle à ce sujet lors de la sortie de la RHEL5 en mars 2007.
http://forums.oracle.com/forums/thread.jspa?threadID=486222&(...)
Oracle has a large-scale testing infrastructure where we test new Linux releases using real-world -- sometimes very large-- customer workloads. I expect testing of RHEL5 to take another few weeks to ensure stability, robustness and interoperability. Once RHEL5 passes the tests, we will release Enterprise Linux 5, downloadable for free, and will begin offering support through the Unbreakable Linux Support program.
what versions of RAC databases supported on RHEL 5.0?
As far as I know, no Oracle software is supported on RHEL5 yet. Testing and certification work is ongoing. You may verify this yourself here:
https://metalink.oracle.com/metalink/certify/certify.welcome
C'est Oracle qui se tape la certification de ses produits sur RHEL, et pas l'inverse.
[^] # Re: Oups, j'ma gourré...
Posté par pasBill pasGates . Évalué à 0.
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.
[^] # Re: Oups, j'ma gourré...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 5.
La seule raison d'une migration, c'est la fin du support de la version actuellement utilisée, que ce soit via l'éditeur original ou un tiers.
On trouve encore beaucoup de RHEL3, des Debian 3.x, etc...
[^] # Re: Oups, j'ma gourré...
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Oups, j'ma gourré...
Posté par Christophe Merlet (site web personnel) . Évalué à 4.
Oui, moi j'aimerai bien !
La semaine dernière j'ai passé un peu plus de 3 jours a réussir a réinstaller NT 4 (retour en enfer) sur un chromatographe d'exclusion stérique.
Curieusement, ce chromatographe acheté en 2002 était livré neuf sous NT4 !! (Perso si j'avais eu a effectuer l'achat, je n'aurais jamais accepté cette arnaque)
Aujourd'hui, le constructeur demande une petite fortune pour fournir le soft de pilotage compatible avec Win 2000 !!
Entre payer une fortune a des escrocs revendeurs de matériel spécialisé, ou passer 3 jours a faire tourner NT4 sur du matériel trop récent pour lui... J'ai choisis de me tuer à la tache et j'en ai bavé :/ Je me suis rappelé pourquoi j'ai basculé sous Linux en 95 :o))
[^] # Re: Oups, j'ma gourré...
Posté par Guillaume Knispel . Évalué à 2.
S'ils doivent faire le portage pour l'occasion, la petite fortune qu'ils demandent est ptet justifiée ?
[^] # Re: Oups, j'ma gourré...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
Les test de migration peuvent en effet prendre des mois.
Cela étant : le système reste moins important que les applications.
Si l'application ne le requiert pas, le système restera bien souvent tel qu'il est et ne bougera pas. Tout est une question de risques bien calculés.
[^] # Re: Oups, j'ma gourré...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
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.
Simplement, avec Linux, il peut créer sa propre distribution, son propre système, sans payer de licences à qui que ce soit. Évidemment, ça demandera un investissement pour le support par ses services mais cela est également valable avec chaque système d'exploitation avec lesquels il est possible d'installer Oracle et pour lesquels c'est officiellement supporté.
[^] # Re: Oups, j'ma gourré...
Posté par pasBill pasGates . Évalué à 2.
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.
[^] # Re: Oups, j'ma gourré...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
Leurs premiers bénéfices sont arrivés 7 ans après.
Le pari était très loin d'être gagné, à l'époque.
# C'est con mais...
Posté par Tux_Beginner . Évalué à 7.
# Franchement...
Posté par ß ß . Évalué à 10.
Appeler à dessein un soft RMS pour ensuite jetter la faute sur lui et discréditer l'acronyme aux trois lettres...
C'est petit ;)
[^] # Re: Franchement...
Posté par nanard . Évalué à 3.
Bon temps pis, j'y aurais crue deux seconde (:
Allez tous vous faire spéculer.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.