La communauté Debian qui se félicitait d'être un bon millier explique maintenant qu'ils ne sont pas assez nombreux !!
Pour info, maintenir une distribution est un boulot faisable par une seule personne pour autant qu'elle se limite à packager et intégrer les paquets upstream sans s'amuser à vouloir modifier le code.
Slackware le fait.
Moi même je l'ai fait pour ma pomme pendant 3/4 ans pour une distrib plutôt complète de 700 paquets sources sur mon temps libre en plus des traductions GNOME. http://ftp.redfoxcenter.org/pub/RedFox/MyRPMs/
Le problème de certains packagers et de maintenir dans les faits un fork du paquet upstream sans prendre la peine de faire valider ses patchs par qui que se soit. On comprend pourquoi certains développeurs refuse de voir distribuer leur soft patché avec le même nom, surtout quand ces patchs ne leur amènent que des plaintes d'utilisateurs.
Pour avoir un KDE 4.1 complet et pas un truc bancale mélange de KDE3 et KDE 4.0
Pour avoir un GNOME plus uniforme (suppression de libgnomeprint, gnome-vfs, ....)
Une meilleure intégration de pulseaudio.
Un portage de LTSP fonctionnel
Pour avoir un Xorg finalisé, les drivers et les utilitaires de configuration qui vont bien avec.
Pour proposer un ext4 utilisable
Pour avoir un JDK opensource officiel
Bref... Fedora 9 est une distrib de transition, pas utilisable sur le long terme...
> J' aurai envie de dire "ok le mainteneur à ch**** dans la colle mais pourquoi personne ne l' a vu et pourquoi pendant si longtemps ?"
Moi j'imagine que PLEIN de personnes ont vu ce patch. Mais comme aucune personne n'a les compétences en cryptographie pour dire que ce patch est bien ou non, personne n'a cru bon de palabrer sur la question publiquement tout simplement parce que si LE MAINTENEUR du paquet à appliqué ce patch, c'est que LUI, SAVAIT CE QU'IL FAISAIT.
En aucune façons les bugs d'OpenOffice sont aussi dangereux que cette faille d'OpenSSL. sur laquelle s'articule toute la sécurité et la confidentialité des échanges sur Internet et en entreprise.
De plus, ce que tu cites ce sont des bugs dans le développement upstream corrigé en upstream et pas des bugs rajoutés par la distributions.
> je n'ai pas lu ça du tout.
Va sur planet.debian.org ... !!!
En vrac.
* C'est pas nous, c'est la faute aux dev upstream...
sauf que les devs upstream n'ont jamais intégré ce patch !!
* Debian, on est les meilleurs, dés qu'on a vu le bug on a fait un paquet corrigé.
Réussir a dire ça sans mourrir de honte, faut franchement n'avoir aucune fierté :(
* Debian est plus secure que les autres distribs car on a une blacklist des clés pourraves.
Là encore oser pourrir nommément les autres distribs à cause de sa propre incurie, faut oser.
J'aimerais bien que tu me cites une ou deux failles parmi les "tonnes" non publiées qui inpactent aussi dangereusement la sécurité et la confidentialités des échanges sur Internet et dans les entreprises !
Même la dernière faille vmsplice du kernel est 100 fois moins dangereuse !!
Et ce qui est assez scandaleux ici, c'est que ce n'est pas une faille du développement upstream, mais une faille béante apportée par un développeur externe, visiblement pas expert en cryptographie, au projet pour "corriger" un problème cosmétique de développement logiciel et intégré dans une distribution généraliste.
Ce qui me gène énormément dans cette histoire, c'est l'attitude devs Debian qui cherche à discréditer tout le monde (upstream et autres distributions) au lieu d'assumer simplement leur responsabilité et faire profil bas.
Il n'y a rien d'excusable.
Un packageur décide de modifier un paquet de la plus haute importance sans comprendre ce qu'il fait ne mérite plus de maintenir de paquets. Dans le cas présent l'erreur a des répercussions inadmissibles.
Maintenant les debian user se cherche des excuses et au lieu d'assumer vont chercher les responsabilités ailleurs ou jetent des écrans de fumée et le discrédit sur les autres distribs. C'est inadmissible !
En vrac.
* C'est pas nous, c'est la faute aux dev upstream... sauf que les devs upstream n'ont jamais intégré ce patch !!
* Debian, on est les meilleurs, dés qu'on a vu le bug on a fait un paquet corrigé. Réussir a dire ça sans mourrir de honte, faut franchement n'avoir aucune fierté :(
* Debian est plus secure que les autres distribs car on a une blacklist des clés pourraves. Là encore oser pourrir nommément les autres distribs à cause de sa propre incurie, faut oser.
Ce genre de bug serait arrivé chez Microsoft, je raconte pas comment il se fairait incendier à raison. c'est arrivé à Debian et ses dérivés, il faut que les devs debian assument.
Si on dit que la SNCF fait des bénefs, c'est parce tous les milliards de dettes ont été mis dans une société créé exprés (RFF), quelque chose comme 45 milliards !!
Un joli artifice comptable à la charge du contribuable...
De toute façon, PulseAudio, à part rediriger le son sur le réseau, je ne voit pas à quoi ça sert actuellement sur un poste de travail standard.
C'est juste une couche intermédiaire supplémentaire avec son lot de tracas, de consommation mémoire, et de latence.
Pour un desktop de base, on devrait se contenter d'Alsa, Gstreamer et GNOME
Pour un poste MAO, Alsa, Jack, Appli MAO
Pour un client léger Alsa, PulseAudio
Pour un serveur de client léger, PulseAudio, Gstreamer GNOME
GNOME devrait se dévarasser définitivement d'esound et taper directement dans alsa ou gstreamer.
Cependant PulseAudio va subir sous peu une évolution majeure qui risque de le rendre bien plus atractif. http://0pointer.de/blog/projects/pulse-glitch-free.html
La lecture des commentaires indique ausi a quel point il est difficile de faire du son sur un ordinateur et que c'est beaucoup de compromis à faire.
1) tu n'es pas obligé de mettre à jour
2) la mise à jour est gratuite
3) si tu considères que windows dure plus longtemps qu'une Fedora, dis toi qu'une nouvelle version de la fedora n'est qu'un service pack à appliquer et tu t'en portera psychologiquement bien mieux !
> pour limiter la consomation de mémoire (mais ce n'est vraiment pas un gros problème pour l'utilisateur vu la taille des HDs et de la RAM sur les machines actuelles) ...
Je suis désolé, mais je ne m'achete pas un nouvelle ordinateur avec chaque nouvelle sortie de distribution Linux.
En entreprise c'est Idem, Le parc est énormément composé de machine n'ayant que 256 Mo de RAM (si en plus elle n'est pas partagé avec la mémoire vidéo).
Et 256 Mo de RAM c'est vraiment limite inutilisable avec une distribution Linux moderne.
Alors NON, je suis contre cette argument qui consiste à dire qu'on peut coder comme des porcs, ne faire attention a rien car on veut se convaincre que la puissance des machines compense !!
J'avais acheté il y a quelques années une carte WiFi PCI avec une puce RaLink, en me disant que suite a la publications du driver du constructeur en GPL, ce sera vite supporté dans le kernel officiellement....
Il aura fallu être patient :/
En ce qui concerne les puce ACX100 et ACX111, quelqu'un sait où ça en est ? Là aussi j'attends un support officiel dans le kernel...
De manière plus générale, il y a une feuille de route quelque part qui recense tous les drivers WiFi existant et leur état d'avancement ?
"Selon le Journal du Dimanche, l'offre payée en roupies émane d'une agence web fondée en 1997 en Charente-Maritime à Jonzac, développant des services internet, et délocalisée à Pondichéry depuis 2007 sous le nom de Hangar 17 ICT.
Son dirigeant Denis Delcroix, injoignable dimanche, a nié au JDD avoir sollicité l'ANPE mais reconnaît déposer des offres similaires sur d'autres sites de recrutement: "Je suis dans mon droit, je suis une entreprise indienne, j'embauche aux conditions locales", explique-t-il."
> 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))
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...
> 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?
/* 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.
> 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 ?
[^] # Re: Limite du développement bénévole
Posté par Christophe Merlet (site web personnel) . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 8.
La communauté Debian qui se félicitait d'être un bon millier explique maintenant qu'ils ne sont pas assez nombreux !!
Pour info, maintenir une distribution est un boulot faisable par une seule personne pour autant qu'elle se limite à packager et intégrer les paquets upstream sans s'amuser à vouloir modifier le code.
Slackware le fait.
Moi même je l'ai fait pour ma pomme pendant 3/4 ans pour une distrib plutôt complète de 700 paquets sources sur mon temps libre en plus des traductions GNOME.
http://ftp.redfoxcenter.org/pub/RedFox/MyRPMs/
Le problème de certains packagers et de maintenir dans les faits un fork du paquet upstream sans prendre la peine de faire valider ses patchs par qui que se soit. On comprend pourquoi certains développeurs refuse de voir distribuer leur soft patché avec le même nom, surtout quand ces patchs ne leur amènent que des plaintes d'utilisateurs.
[^] # Re: Idem à Lille
Posté par Christophe Merlet (site web personnel) . En réponse au journal aujourd'hui il a plu. Évalué à 2.
Mais en 4x4, si le conducteur garde un tuba pour respirer... c'est possible ;o)
http://www.youtube.com/watch?v=mysp9FeOfd8
[^] # Re: Une réaction sur Debian Planet en français
Posté par Christophe Merlet (site web personnel) . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 4.
Les graphiques sont bluffants !
http://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html
[^] # Re: Idem à Lille
Posté par Christophe Merlet (site web personnel) . En réponse au journal aujourd'hui il a plu. Évalué à 10.
[^] # Re: L'upstream
Posté par Christophe Merlet (site web personnel) . En réponse au journal Mark Shuttleworth : il remet ça. Évalué à 2.
Pour avoir un KDE 4.1 complet et pas un truc bancale mélange de KDE3 et KDE 4.0
Pour avoir un GNOME plus uniforme (suppression de libgnomeprint, gnome-vfs, ....)
Une meilleure intégration de pulseaudio.
Un portage de LTSP fonctionnel
Pour avoir un Xorg finalisé, les drivers et les utilitaires de configuration qui vont bien avec.
Pour proposer un ext4 utilisable
Pour avoir un JDK opensource officiel
Bref... Fedora 9 est une distrib de transition, pas utilisable sur le long terme...
[^] # Re: Limite du développement bénévole
Posté par Christophe Merlet (site web personnel) . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 2.
Moi j'imagine que PLEIN de personnes ont vu ce patch. Mais comme aucune personne n'a les compétences en cryptographie pour dire que ce patch est bien ou non, personne n'a cru bon de palabrer sur la question publiquement tout simplement parce que si LE MAINTENEUR du paquet à appliqué ce patch, c'est que LUI, SAVAIT CE QU'IL FAISAIT.
[^] # Re: Mise en perspéctive
Posté par Christophe Merlet (site web personnel) . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 4.
De plus, ce que tu cites ce sont des bugs dans le développement upstream corrigé en upstream et pas des bugs rajoutés par la distributions.
> je n'ai pas lu ça du tout.
Va sur planet.debian.org ... !!!
En vrac.
* C'est pas nous, c'est la faute aux dev upstream...
sauf que les devs upstream n'ont jamais intégré ce patch !!
* Debian, on est les meilleurs, dés qu'on a vu le bug on a fait un paquet corrigé.
Réussir a dire ça sans mourrir de honte, faut franchement n'avoir aucune fierté :(
* Debian est plus secure que les autres distribs car on a une blacklist des clés pourraves.
Là encore oser pourrir nommément les autres distribs à cause de sa propre incurie, faut oser.
Toi même, si tu te relis !
[^] # Re: Mise en perspéctive
Posté par Christophe Merlet (site web personnel) . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 4.
Même la dernière faille vmsplice du kernel est 100 fois moins dangereuse !!
Et ce qui est assez scandaleux ici, c'est que ce n'est pas une faille du développement upstream, mais une faille béante apportée par un développeur externe, visiblement pas expert en cryptographie, au projet pour "corriger" un problème cosmétique de développement logiciel et intégré dans une distribution généraliste.
Ce qui me gène énormément dans cette histoire, c'est l'attitude devs Debian qui cherche à discréditer tout le monde (upstream et autres distributions) au lieu d'assumer simplement leur responsabilité et faire profil bas.
[^] # Re: repos tiers
Posté par Christophe Merlet (site web personnel) . En réponse au journal Fedora 9. Évalué à 3.
Surement une bonne indication de la pénétration des différents OS sur le desktop...
[^] # Re: Debian est coupable mais pas responsable !
Posté par Christophe Merlet (site web personnel) . En réponse au journal Vulnérabilité Debian. Évalué à 0.
Un packageur décide de modifier un paquet de la plus haute importance sans comprendre ce qu'il fait ne mérite plus de maintenir de paquets. Dans le cas présent l'erreur a des répercussions inadmissibles.
Maintenant les debian user se cherche des excuses et au lieu d'assumer vont chercher les responsabilités ailleurs ou jetent des écrans de fumée et le discrédit sur les autres distribs. C'est inadmissible !
En vrac.
* C'est pas nous, c'est la faute aux dev upstream... sauf que les devs upstream n'ont jamais intégré ce patch !!
* Debian, on est les meilleurs, dés qu'on a vu le bug on a fait un paquet corrigé. Réussir a dire ça sans mourrir de honte, faut franchement n'avoir aucune fierté :(
* Debian est plus secure que les autres distribs car on a une blacklist des clés pourraves. Là encore oser pourrir nommément les autres distribs à cause de sa propre incurie, faut oser.
Ce genre de bug serait arrivé chez Microsoft, je raconte pas comment il se fairait incendier à raison. c'est arrivé à Debian et ses dérivés, il faut que les devs debian assument.
[^] # Re: Pas mal de préjugés dans le journal...
Posté par Christophe Merlet (site web personnel) . En réponse au journal La poste, les tarifs. Évalué à 6.
Un joli artifice comptable à la charge du contribuable...
[^] # Re: Et la famille
Posté par Christophe Merlet (site web personnel) . En réponse au journal Pascal sevran est bronsonisé. Évalué à 2.
http://fr.news.yahoo.com/morandini/20080509/tcu-dcs-de-pasca(...)
Décidement ce vendredi sape tout élan de productivité, même Sarkozy n'a rien de mieux à faire !!
# What you say?
Posté par Christophe Merlet (site web personnel) . En réponse au journal La communauté affirme la GPL face à Skype... mais.... Évalué à 10.
Je n'ai absolument rien compris !!!
[^] # Re: Wouah
Posté par Christophe Merlet (site web personnel) . En réponse au journal Augmentez les performances de votre ... Linux. Évalué à 8.
C'est possible ?
Tu nous fait une capture d'écran stp :)
[^] # Re: À quand les premières versions opérationnelles ?
Posté par Christophe Merlet (site web personnel) . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 4.
http://mail.gnome.org/archives/desktop-devel-list/2007-Octob(...)
[^] # Re: À quand les premières versions opérationnelles ?
Posté par Christophe Merlet (site web personnel) . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 3.
C'est juste une couche intermédiaire supplémentaire avec son lot de tracas, de consommation mémoire, et de latence.
Pour un desktop de base, on devrait se contenter d'Alsa, Gstreamer et GNOME
Pour un poste MAO, Alsa, Jack, Appli MAO
Pour un client léger Alsa, PulseAudio
Pour un serveur de client léger, PulseAudio, Gstreamer GNOME
GNOME devrait se dévarasser définitivement d'esound et taper directement dans alsa ou gstreamer.
Cependant PulseAudio va subir sous peu une évolution majeure qui risque de le rendre bien plus atractif.
http://0pointer.de/blog/projects/pulse-glitch-free.html
La lecture des commentaires indique ausi a quel point il est difficile de faire du son sur un ordinateur et que c'est beaucoup de compromis à faire.
[^] # Re: À quand les premières versions opérationnelles ?
Posté par Christophe Merlet (site web personnel) . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 8.
2) la mise à jour est gratuite
3) si tu considères que windows dure plus longtemps qu'une Fedora, dis toi qu'une nouvelle version de la fedora n'est qu'un service pack à appliquer et tu t'en portera psychologiquement bien mieux !
[^] # Re: Le retour du Troll (WebKit Vs KHTML)
Posté par Christophe Merlet (site web personnel) . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 10.
Je suis désolé, mais je ne m'achete pas un nouvelle ordinateur avec chaque nouvelle sortie de distribution Linux.
En entreprise c'est Idem, Le parc est énormément composé de machine n'ayant que 256 Mo de RAM (si en plus elle n'est pas partagé avec la mémoire vidéo).
Et 256 Mo de RAM c'est vraiment limite inutilisable avec une distribution Linux moderne.
Alors NON, je suis contre cette argument qui consiste à dire qu'on peut coder comme des porcs, ne faire attention a rien car on veut se convaincre que la puissance des machines compense !!
[^] # Re: Bonne nouvelle pour le Wifistes en ralink
Posté par Christophe Merlet (site web personnel) . En réponse au journal Information assez importante (en fait non). Évalué à 2.
Il aura fallu être patient :/
En ce qui concerne les puce ACX100 et ACX111, quelqu'un sait où ça en est ? Là aussi j'attends un support officiel dans le kernel...
De manière plus générale, il y a une feuille de route quelque part qui recense tous les drivers WiFi existant et leur état d'avancement ?
[^] # Re: Précisions
Posté par Christophe Merlet (site web personnel) . En réponse au journal [OFF]Annonce ANPE hallucinante. Évalué à 3.
http://fr.news.yahoo.com/afp/20080504/tfr-social-emploi-chom(...)
"Selon le Journal du Dimanche, l'offre payée en roupies émane d'une agence web fondée en 1997 en Charente-Maritime à Jonzac, développant des services internet, et délocalisée à Pondichéry depuis 2007 sous le nom de Hangar 17 ICT.
Son dirigeant Denis Delcroix, injoignable dimanche, a nié au JDD avoir sollicité l'ANPE mais reconnaît déposer des offres similaires sur d'autres sites de recrutement: "Je suis dans mon droit, je suis une entreprise indienne, j'embauche aux conditions locales", explique-t-il."
[^] # Re: Oups, j'ma gourré...
Posté par Christophe Merlet (site web personnel) . En réponse au journal Victoire de RMS sur Microsoft. É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 Christophe Merlet (site web personnel) . En réponse au journal Victoire de RMS sur Microsoft. É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 Christophe Merlet (site web personnel) . En réponse au journal Victoire de RMS sur Microsoft. É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 Christophe Merlet (site web personnel) . En réponse au journal Victoire de RMS sur Microsoft. É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 Christophe Merlet (site web personnel) . En réponse au journal Victoire de RMS sur Microsoft. É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 ?