Peut être parcequ'elle n'est déjà pas capable de livrer un système qui reste cohérent entre leurs mises à jour ? Moi ça me laisse dubitatif de voir que la version de suse "for sap" pête la timezone sur une mise à jour : le boot.clock est celui d'origine, le /etc/sysc*/clock est celui avec les paramètres d'installation, le tout installé par un expert certifié, avec un suse-manager en version boite noire par novell... Mais SuSE arrive quant même à te changer la timezone en UTC, comme ça, paf la timezone [on passe sur l'abomination de l'utilitaire chargé de ça, et de sa manière de traiter ses tpl] Et ça se voit aussi lorsque tu regardes le fichier idoine dans l'initrd généré : TZ2\nTZ2\nUTC0 paf, alors que ça devrait être du TZ2\nCESTblabla. Forcément en changeant de timezone, le sap n'est pas très content.
Alors avec du *BSD, tu rêves mon ami :-)
[^] # Re: On est presque vendredi
Posté par bubar🦥 . En réponse au journal SUSE SolidDriver de nouveau sur les rails pour développer des drivers Linux en toute sécurité !. Évalué à 3. Dernière modification le 16 novembre 2013 à 10:45.
Peut être parcequ'elle n'est déjà pas capable de livrer un système qui reste cohérent entre leurs mises à jour ? Moi ça me laisse dubitatif de voir que la version de suse "for sap" pête la timezone sur une mise à jour : le boot.clock est celui d'origine, le /etc/sysc*/clock est celui avec les paramètres d'installation, le tout installé par un expert certifié, avec un suse-manager en version boite noire par novell... Mais SuSE arrive quant même à te changer la timezone en UTC, comme ça, paf la timezone [on passe sur l'abomination de l'utilitaire chargé de ça, et de sa manière de traiter ses tpl] Et ça se voit aussi lorsque tu regardes le fichier idoine dans l'initrd généré : TZ2\nTZ2\nUTC0 paf, alors que ça devrait être du TZ2\nCESTblabla. Forcément en changeant de timezone, le sap n'est pas très content.
Alors avec du *BSD, tu rêves mon ami :-)