Sortie de Mandriva Linux 2009 Spring RC 1 : La transformation...

Posté par  . Modéré par Nÿco.
Étiquettes :
24
11
mar.
2009
Mandriva
Le 10 mars dernier a été publiée la version Release Candidate 1 de Mandriva Linux 2009 Spring. Cette version est très attendue par de nombreux utilisateurs déçus de la cuvée 2009.0 qui rappelons-le, a fait couler beaucoup d'encre au début. La 2009 Spring va apporter non seulement une stabilité radicalement différente par rapport à la version précédente, mais aussi des innovations intéressantes. Quelques détails, explications et retour de quelques mois en arrière sont présentés en seconde partie de dépêche.

NdM : comme son nom l'indique, release candidate 1, cette version n'est pas encore la version finale mais présage des ajouts effectués jusqu'à maintenant afin que ceux intéressés puissent tester et remonter les différents résultats de leurs tests pour corriger ce qui est bloquant pour la sortie de la version finale. Voir le calendrier prévisionnel des sorties, le cycle des alpha avait démarré en décembre 2008. Mandriva Linux 2009 Spring est livré avec KDE 4.2, une version considérée comme "enfin utilisable pour un usage quotidien" alors que ses prédécesseurs étaient relativement impopulaires. Sont aussi de la partie Gnome en version 2.25.92 actuellement (RC de Gnome 2.26, prévu pour être intégré en version stable) et Xfce en sa dernière version très attendue 4.6, apportant son très grand lot de nouveautés et d'améliorations. À ce propos, c'est désormais LXDE qui assume la charge de bureau minimal léger à la place de IceWM. On remarquera aussi la présence de Qt Creator en version 1.0 (Qt étant en version 4.5), du noyau Linux en version 2.6.29 RC6 contenant bon nombre de nouvelles fonctionnalités et prend en charge plus de matériel, et de X.org en version 1.6 qui permet le support du branchement à chaud de périphériques et corrige de nombreux problèmes graphiques avec les cartes nVidia et puces Intel. Dommage que AMD ne fournisse pas de pilotes fonctionnant correctement avec cette dernière version cependant.

Du côté des nouveautés dans cette Release Candidate, on voit se profiler l'aspect final de cette cuvée de printemps 2009. Les développeurs, coincés chez eux à cause du froid et de cet hiver grisâtre et morose, ont eu le temps non seulement de stabiliser leurs pré-versions ou Cooker tout simplement (version en perpétuelle évolution, Rolling release) à tel point que la version Alpha 2 était déjà plus stable que Mandriva Linux 2009.0, qui avait pourtant déjà bien été consolidée à l'aide de mises à jour et correctifs en masse. C'est bien ce qui a été remarqué par la plupart des testeurs dans la communauté de Mandriva.

En plus de la stabilisation, Mandriva 2009 Spring apporte une nouvelle technologie baptisée Speedboot, développée par Frédéric Crozat, qui consiste à démarrer d'abord les services essentiels au système, puis lorsque cela est possible, de démarrer immédiatement le serveur d'affichage X.org et l'écran de connexion. Le chargement du système continue en arrière-plan, démarrant des processus secondaires très utiles, puis les moins importants. Speedboot permet ainsi à Mandriva de réaliser des temps de démarrage apparent bien plus rapides pour un système qui n'est pourtant pas allégé à l'origine (comme les distributions pour les netbooks).

L'outil de gestion de sécurité système Msec, inclus depuis Mandrake Linux 8.0, a été entièrement refait et repensé, offrant à présent deux niveaux de sécurité au lieu de cinq précédemment, permet de configurer ses paramètres encore plus finement et précisément, et propose encore plus d'améliorations.

Diskdrake a été amélioré afin de permettre d'explorer le contenu de ses partitions dans le programme d'installation de Mandriva.

Le pare-feu interactif a reçu de multiples correctifs.

Le système de fichiers ext4 est maintenant stable mais toujours pas choisi par défaut.

Draksnapshot est enfin doté d'un système de restauration (!). Une entrée placée sur l'écran gfxboot du média d'installation permet de restaurer son ordinateur à une date antérieure, à l'aide de clichés instantanés pris de façon périodiques. Cette fonction est très utile en cas de plantage du système dû à une erreur ou à une mise à jour problématique.

La version finale de Mandriva Linux 2009 Spring est très attendue car bon nombre d'utilisateurs ont été déçus à la sortie de Mandriva Linux 2009.0, souvent à cause de problèmes matériels, problèmes de conception, mais aussi à cause de sérieux problèmes lors de la mise à jour d'une version 2008.1 à 2009.0, problèmes aujourd'hui réparés depuis longtemps. Beaucoup d'utilisateurs ont choisi de conserver soit Mandriva 2008.1 Spring, soit KDE 3.5, ou encore de passer à Gnome, du fait que KDE 4.1 était encore assez instable et parfois très impopulaire.

Autant dire que beaucoup attendent au tournant la cuvée de printemps 2009. Si sa stabilité semble ne plus faire de doute, elle doit cependant convaincre à nouveau son public. Mais la communauté est très confiante et participe plus que jamais aux tests et aux rapports de bogues pour cette version, encouragée par l'association MandrivaFR.org. Il faut dire que en 6 mois, énormément de choses ont évolué chez Mandriva et ce très rapidement : si le licenciement de plusieurs employés externes (dont Adam Williamson) a été un choc violent pour toutes les communautés de Mandriva dans le monde, l'association des utilisateurs francophones de Mandriva Linux tient aujourd'hui une relation privilégiée avec la direction de la société. Mandriva a également créé une assemblée ("Assembly") rassemblant équipes de développement, traducteurs, testeurs et utilisateurs du monde entier, démontrant la volonté ferme de la société, dirigée depuis quelques mois par Hervé Yahi, de se rapprocher de sa communauté. Et tout cela sans compter les projets actuellement en cours dans les communautés. Mandriva Linux 2009 Spring sera donc assurément le résultat de six mois de transformation et de changement, fruit des leçons de la 2009.0, des efforts des développeurs et des communautés, avec pour objectif de ramener à nouveau la confiance des utilisateurs.

Aller plus loin

  • # une RC avec un kernel non stable

    Posté par  . Évalué à 3.

    Je n'y arrive pas. Je ne comprends pas comment on peut sortir une RC avec un kernel non stable... Pour moi, une RC s'est censé être une une version aboutie ne nécessitant plus que quelques ajustements... et le kernel, ce n'est pas un détail...

    J'espère juste qu'ils vont pas nous refaire le coup de la version final avec un kernel en RC... je trouve ça vraiment hallucinant!

    Mis à part ça, ça reste tout de même une bonne distribution...
    • [^] # Re: une RC avec un kernel non stable

      Posté par  . Évalué à 3.

      la 2009.0 était sortie avec un kernel en RC (en fait c'était un final, 1 semaine avant le passage du RC9 à 2.6.27).
    • [^] # Re: une RC avec un kernel non stable

      Posté par  (site web personnel) . Évalué à 6.

      La logique est d'avoir le dernier kernel disponible pour prendre en charge le plus de matériel possible. Difficile d'avoir autre chose qu'une version rc vu ce qui est disponible sur http://kernel.org ;-)

      Pour la 2009.0, tu constateras que le kernel a été mis à jour depuis (et régulièrement) :
      http://sophie.zarb.org/rpm/2009.0,i586/kernel-desktop-latest
      C'est justement l'intérêt des paquets -latest de bénéficier de ces mises à jour, au besoin.

      Que tu trouves cela hallucinant me paraît bizarre ;-) la rc1 reste encore une version de développement, comme je l'ai précisé en NdM : tu peux regarder le planning prévisionnel de sortie, il reste encore un peu plus de 15 jours avant la rc2, qui aura sans doute encore un kernel 2.6.28 en rc7 (ou rc8 si ça avance vite). Entre avoir un kernel en rc et tout ce qu'il faut d'intégration ou le tout dernier kernel qui vient de sortir sans avoir eu le temps de tester sur assez de matériel, le choix est vite vu : dans un cas, ce qui coince est connu et peut être annoncé, dans l'autre tu es face à l'inconnu.

      Bienvenue à tous ceux qui ont envie de passer en Cooker pour un peu plus d'un mois ;-)
      • [^] # Re: une RC avec un kernel non stable

        Posté par  . Évalué à 3.

        Qu'un kernel en cours de développement soit utilisé dans une distribution en cours de conception, ne me choque pas en soit. Bien au contraire, je suis tout à fait d'accord avec tes arguments.

        Je pense juste qu'on ne doit pas percevoir de la même façon ce qu'est une version RC pour une distribution. Moi, je vois ça comme une version finie qui ne nécessite plus que quelques ajustements, où la version des paquets est figée... mais bon, ce n'est que mon point de vu...
        • [^] # Re: une RC avec un kernel non stable

          Posté par  . Évalué à 2.

          D'un autre côté une RC avec un noyau en RC quasi final, c'est assez logique aussi vu que la distribution se cale sur les développements upstreams.
          Après c'est vrai qu'à ce niveau là chaque distribution ou logiciel a sa propre politique.
          • [^] # Re: une RC avec un kernel non stable

            Posté par  . Évalué à -1.

            En fait, en toute logique, la RC d'une distribution devrait déjà être calée sur des sorties stables des paquets upstream. La raison, c'est que la RC d'une distribution sert à fignoler la qualité de l'intégration, pas à stabiliser les logiciels fournis. Si Mandriva profite du passage de la version RC à la version finale pour modifier la version des paquets upstream, alors on comprend que la qualité soit décevante...
            • [^] # Re: une RC avec un kernel non stable

              Posté par  . Évalué à 6.

              > alors on comprend que la qualité soit décevante...

              Oui, c'est sûr que la qualité est forcément inférieure. Par contre, cela permet de l'installer sur des machines très récentes, avec un support immédiat et sans bidouilles des cartes sons, réseau, etc.

              Pour pondérer, la différence entre un noyau RC7 en un noyau final est généralement ultra minime, et n'implique jamais un changement dans le reste du système.

              Bref, Mandriva a toujours été une distribution qui prend des risques, et ça lui a valu des réactions très opposées (super, tout marche - grrr, noyau trop récent, je suis tombé sur une régression).

              ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

              • [^] # Re: une RC avec un kernel non stable

                Posté par  . Évalué à 2.

                C'est peut-être pour ça que ça coince dans la percée:

                - d'un coté on se réclame grand public accessible pour tout le monde, mais on peut tomber sur un problème technique à l'installation, peut-être qu'il faudra 5min pour le résoudre pour un utilisateur expérimenté, mais ce n'est pas la cible

                - de l'autre on prend des risques pour fournir les toutes dernières versions de tout, mais l'utilisateur expérimenté est déjà ailleurs, parce que la distro est estampillée "orientée débutant", bidouilleurs, passez votre chemin.

                Pourquoi ne pas avoir une version "un peu plus conservatrice" pour les grands débutants, et une version un peu plus agressive pour les utilisateurs expérimentés? (J'ajoute qu'il y a encore un fossé avec la Cooker, parce que moi essuyer des plâtres sur quelques bugs, je veux bien, mais prendre le risque de tout casser mon système de temps en temps, j'aurai pas les compétences pour rattrapper le coup).

                Tiens, je propose ça:
                - La One et Power Pack ne sortent qu'une fois par an, au prinptemps.
                - Une nouvelle version, disons la "Geek" est en rolling-release du prinptemps à l'automne, puis freeze pour stabiliser la One, et reprend sa rolling-release au prinptemps!
                (Oui, je sais, c'est Debian/Testing + Debian/Stable en version très accélérée avec une contrainte sur le temps plutôt que sur l'état, mais après tout Debian n'est pas une si mauvaise distro, et elle a su convaincre un large public!)
                • [^] # Re: une RC avec un kernel non stable

                  Posté par  (site web personnel) . Évalué à 7.

                  hmmmm, ça me rappelle des discussions interminables...
                  Il n'y aura pas de retour à un cycle annuel pour Mandriva, cela semble une optique ferme (tout simplement parce qu'ensuite tous les utilisateurs râlent que les logiciels sont trop anciens, qu'on ne parle pas assez de la distro, qu'elle vivôte... 'fin l'histoire du chien qui a la rage en bref).

                  Un axe sympathique est ce qu'a fait MLO : après la sortie officielle, refaire une ISO prenant en compte les mises à jour (updates), ce qui permet d'enlever certains des problèmes majeurs.
                  https://linuxfr.org//2009/01/21/24902.html

                  Et sinon, le cycle que tu décris existe déjà : les utilisateurs peuvent d'eux mêmes passer de la 2008.1 à la 2009.1 en ne passant pas par la case 2009.0 (les versions automnales étant souvent plus agressives sur les nouveautés... même si cette fois-ci avec les modifs au niveau de X.org, c'est quelques cartes graphiques qui fonctionneront mal avec le pilote propriétaire, bizarrement ATI/AMD :/).
                  Je ne vois pas en quoi une distribution "orientée débutant", peut ne pas convenir à un "geek" comme tu le dis... Cela reste du GNU/Linux, avec tous les outils permettant de développer ou de faire ce que l'on veut (install' sur du ARM, install' sur du MIPS pour ceux qui veulent...).
                  • [^] # Re: une RC avec un kernel non stable

                    Posté par  (site web personnel) . Évalué à 5.

                    Je ne vois pas en quoi une distribution "orientée débutant", peut ne pas convenir à un "geek"

                    Je dirais même mieux, pour convenir à un débutant, Mandriva comporte beaucoup de perfectionnements qui permettent d'automatiser tout ce qui peut l'être. La conséquence est que pour mettre les mains dans le moteur sans faire de bêtises, il faut avoir acquis de solides compétences.

                    C'est pourquoi Mandriva convient parfaitement aux geeks les plus pointus !
                    • [^] # Re: une RC avec un kernel non stable

                      Posté par  (Mastodon) . Évalué à 5.

                      Et puis, être débutant c' est déjà se positionner sur un chemin (newbie -> wanabee -> be -> guru?)... Ce terme m' énerve un peu, pas vous ?
                      Il faudrait peut être arrêter de qualifier les gens de "débutants". Ce sont la plupart du temps des utilisateurs qui n' aspirent qu' à avoir un matériel informatique qui fonctionne, en libre de préférence.

                      Dire, ou se définir comme, "débutant" c' est déjà avoir une volonté d' apprendre le fonctionnement du système.
                      Et dire "débutant" à une personne qui souhaite simplement utilisé, c' est quelque part du dénigrement, et peux être mal vécu, mal vu, par les utilisateurs. ("moi je suis "débutant" ? ha bon ? ha ben c' est vrai alors : il faut être informaticien pour utiliser gnu/linux")

                      S' il vous plait, arretons ensemble de qualifier les utilisateurs de débutants.
                      Merci.
                      • [^] # Re: une RC avec un kernel non stable

                        Posté par  . Évalué à 3.

                        Hmm, je plussoie!

                        En fait je n'avais jamais vraiment pensé à cet aspect avant!
                        Et pourtant je fais partie de ceux qui disent qu'un utilisateur lambda se fout des excuses genre
                        - "y'a des bugs mais pas beaucoup et ça concerne pas grand monde": si ça lui tombe dessus, pour lui ça marche pas, point final
                        - "y'a des bugs mais on est une petite boite": ben alors il va préférer les produits d'une grande boîte qui juste marche
                        etc.

                        C'est décidé, à partir d'aujourd'hui j'arrête d'utiliser "débutant".

                        Par contre, si on pouvait tous se mettre d'accord sur un terme... "utilisateur lambda", c'est un peu dénigrant aussi quelque part, je propose "utilisateur normal" (par opposition à celui qui aime la bidouille, les geeks étant vus comme des anormaux par le reste du monde!! \o/)
                • [^] # Re: une RC avec un kernel non stable

                  Posté par  . Évalué à 4.

                  de l'autre on prend des risques pour fournir les toutes dernières versions de tout

                  Pour être honnête je ne pense pas que ce soit uniquement un problème de versions.
                  Je suis utilisateur Mandriva depuis des années et je rapporte de moins en moins de bugs car je suis lassé de la politique QA inexistante. Quand on rapporte un bug sur le tracker il est fréquent qu'il soit totalement ignoré, ou que le mainteneur réponde à côté de la plaque, ou qu'il soit fermé sous un prétexte foireux (il y a quelques jours un zozo m'a fermé un bug sous prétexte que j'avais sélectionné le mauvais paquet. Quand j'ai demandé sous quel paquet il fallait entrer le bug pour le réouvrir, je n'ai pas eu de réponse. Vive le respect de l'utilisateur, n'est-ce pas ?).

                  Mandriva aura beau utiliser des versions vieilles d'il y a deux ans, tant qu'il n'y a pas un effort concerté pour améliorer les procédures qualité et responsabiliser les développeurs, il y aura toujours autant de problèmes.

                  (il y a aussi des mainteneurs qui font un très bon boulot, le problème c'est que manifestement rien dans l'entreprise n'oblige les mainteneurs à avoir cette démarche qualité, donc chacun fait comme bon lui semble)
                  • [^] # Re: une RC avec un kernel non stable

                    Posté par  . Évalué à 2.

                    La plupart des mainteneurs ne travaillent pas chez Mandriva, elle n'a donc aucun pouvoir coercitif pour améliorer la qualité. A moins de refuser des contributeurs.

                    Par contre, il faut encore et toujours se faire entendre, en envoyant des courriels pour signaler ces gros problèmes de qualité.

                    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

                    • [^] # Re: une RC avec un kernel non stable

                      Posté par  . Évalué à 3.

                      La plupart des mainteneurs ne travaillent pas chez Mandriva, elle n'a donc aucun pouvoir coercitif pour améliorer la qualité.

                      Pour la plupart des paquets, oui. Mais je pense que pour ssh, le mainteneur est un gars payé par l'entreprise (en tout cas j'espère, sinon il n'y a plus qu'à fuir en courant).

                      Par contre, il faut encore et toujours se faire entendre, en envoyant des courriels pour signaler ces gros problèmes de qualité.

                      Envoyer des courriels à qui ?
        • [^] # Re: une RC avec un kernel non stable

          Posté par  (site web personnel) . Évalué à 7.

          Cela fait bien longtemps que les release candidates de Mandriva Linux (et même Mandrake Linux) ne correspondent pas à ta notion de : "la version des paquets est figée".

          Ou alors, tu veux dire que c'est la version cible des paquets qui est figée : il n'y a pas que le kernel qui est en rc, Gnome 2.26 sera de la partie, on n'en est qu'à Gnome 2.25.92 actuellement (le cycle de rc contribue à stabiliser upstream aussi...).
          Il faut aussi savoir faire avec les plannings de chacun des projets et les rc permettent tout de même d'élargir le nombre de testeurs pour avoir plus de retours. Après, avec Cooker, c'est un peu comme une Gentoo : de temps en temps tu compileras toi même des choses qui te manquent (sans oublier de proposer le paquet dans le bugzilla) même s'il y a principalement les packageurs qui le font, le plus souvent tu auras tes 200 Mo de mises à jour par semaine... (si tu ne mets pas à jour tous les soirs) et avant de valider la mise à jour par un urpmi --auto-update tu vas plutôt regarder à 2 fois avant de valider ;-) et il faut bien penser à regarder si les bugs rencontrés n'existent pas déjà sur http://bugzilla.mandriva.com et les soumettre au besoin ou rajouter un commentaire sur un existant ;-)
    • [^] # Re: une RC avec un kernel non stable

      Posté par  (site web personnel) . Évalué à 9.

      Ben le kernel est en RC aussi :-)

      C'est pas comme si c'était une rc1 ou rc2, c'est une rc6 et le final sera certainement sorti d'ici la version finale (dans un mois et demi), et probablement avant la rc2.

      Et sinon c'est quoi le problème d'avoir sorti la finale avec un kernel en RC8 git2 + un patch, ou il manquait 2 ou 3 patchs avant la version finale du kernel ?
      • [^] # Re: une RC avec un kernel non stable

        Posté par  (Mastodon) . Évalué à 6.

        Ca fait mal aux yeux \o/

        Si ça avait été un kernel non-rc, ça aurait raler parceque c' était pas le kernel le plus récent, et si c' est un rc, ça rale aussi :p

        A propos de raler, on pourra faire la mise à jour 2009.0 -> 2009.1 par le ternet, et sans trouble aucun ? :))

        Blagues à part, la cooker en ce moment c' est de la bombe. La 2009.1 pourrait bien être la meilleure distribution jamais sortie par mandrake/lycoris/connectiva/mandriva !! Je parie une tournée que les compteurs des serveurs explosent le précédent record (détenu par mandriva ! surprise !)
        • [^] # Re: une RC avec un kernel non stable

          Posté par  . Évalué à -1.

          > Blagues à part, la cooker en ce moment c' est de la bombe. La 2009.1 pourrait bien être la meilleure distribution jamais sortie par mandrake/lycoris/connectiva/mandriva !!

          Il me semble avoir déjà lu ça...

          > Si ça avait été un kernel non-rc, ça aurait raler parceque c' était pas le kernel le plus récent, et si c' est un rc, ça rale aussi :p

          La remarque de 6arts est pertinente surtout quand on nous met autant de baratin sur la stabilité. Ce qui me surprend, est que personne ne dit que Mandriva veut utiliser le même noyau que Fedora et Ubuntu au-lieu de bosser tout seul dans son coin. Mandriva profite des tests de Fedora et Ubuntu (et vice versa). Ce n'est pas con même sur l'aspect stabilité.
          Es-ce qu'OpenSuse utilise aussi un 2.6.29 ?
          • [^] # Re: une RC avec un kernel non stable

            Posté par  (site web personnel) . Évalué à 5.

            C'était la motivation pour le 2.6.27, surtout qu'il va etre utilisé pour la distro server. Pour le 2.6.29 je ne crois pas que Ubuntu l'utilise (ou alors j'ai raté l'annonce)
          • [^] # Re: une RC avec un kernel non stable

            Posté par  (Mastodon) . Évalué à 7.

            tu as peut être déjà lu ça, mais pas de moi sur la 2009.0 depuis ... aout 2008.0, cad avant le freeze cooker ...
            Concernant la stabilité : cooker m' a explosé mon bi-pro xeon ram ecc & full scsi... m' a explosé aussi mon netbook, ma clef Flash et mes 3 clefs bootable... :) donc bon, c' est bien une cooker quant même :p

            Quant au "Mandriva profite" c' est une tournure de phrase quelque peu dénigrante, non ? "Mandriva bénéficie de" et "Mandriva participe au maximum de ses moyens à" aurait été tout aussi juste, tu en conviendra certainement. Il y a de plus grosses distros en terme de moyens humains et financier que participe bien moins au projets directement, et ont même du mal à partager leurs patchs internes avant leur release ...
            Et m*** je suis tombé dedans :p

            J' espère que tu la testera en profondeur, car même s' il n' y a pas les saveurs d' une fedora, c' est quant même la plus "redhat grand public avec techno récentes"

            ça sent le moinssage ce post :(
            • [^] # Re: une RC avec un kernel non stable

              Posté par  . Évalué à 2.

              > Quant au "Mandriva profite"

              Il y a "et vice versa".

              > J' espère que tu la testera en profondeur

              Je viens de faire un minimini-test sur une machine virtuelle.
              J'ai utilisé la Free et non la one. J'ai bien le droit de ne pas vouloir de proprio !
              Bizarre, il n'y a pas d'image pour Gnome, il y a "dual". Pourquoi des "saveurs" différentes entre Free et One ?
              A l'installation j'ai demandé d'ajouter Gnome, il n'y était pas à l'arrivé.
              A l'installation la carte réseau a été correctement configurée (il me semble). Plus loin l'installeur dit que je dois configurer une carte réseau puisque j'ai demandé d'ajouter Gnome et qu'il n'est pas sur l'ISO... L'installeur échoue. Peut-être que la carte n'était pas configurée contrairement à ce que j'ai dit, mais quoiqu'il en soit au final je n'ai de réseau.
              Premier login (sous KDE, pas de Gnome malheureusement), le menu est vide !
              Je lance FF de la barre de tâche et ça part en couille. La fenêtre de FF s'affiche, mais elle ... descent doucement jusqu'à ne plus être visible.
              Bref, ça m'a pris 0,001 seconde pour décider de détruire la machine virtuelle où j'ai fait l'installation.

              NB: La dernier Ubuntu et Fedora (ainsi que leur version de développement) s'installent sans problème sur une machine virtuelle ici.

              Je n'en conclus pas grand chose, c'est en développement.
              • [^] # Re: une RC avec un kernel non stable

                Posté par  . Évalué à 1.

                Je le plussoie.

                Il teste, c'est bien ce qu'il fallait faire en réaction à cette annonce??

                Autant je me souviens de deux journaux incendiaires qui sentait bon le poil, autant ce coup-ci on a un utilisateur qui n'a pas mis de mauvaise foi, et qui relate ses problèmes, sans oublier de préciser à la fin qu'on ne peut rien en conclure à ce stade!
                Plutôt que de moinsser jusqu'à ce qu'il disparaisse des écrans, ce serait peut-être bien de copier ça et de l'envoyer aux dévs, non??
              • [^] # Re: une RC avec un kernel non stable

                Posté par  . Évalué à 6.

                Sans reproche parce que ce n'est pas forcément évident :

                Si tu as pris la free, tu as pris le DVD ? Gnome & KDE ne peuvent pas être présent sur un CD (la galette est trop petite).

                Dual, n'a rien à voir avec KDE ou Gnome, c'est pour les images sur clef USB ...

                Donc si tu pars d'un CD KDE, et que tu n'as pas de réseau (ou si la configuration échoue, ce qui est fort possible), tu te retrouveras avec KDE et il faudra installer gnome ensuite. ce qui est faisable assez facilement. Mais bon, c'est plus rapide de passer directement par une version Gnome, bien sûr.

                Le menu vide (ça me paraît être un beau bug) pourrait s'expliquer par le fait que tu as choisi Gnome, que l'installation a échoué et que KDE, version minimale, ait été installé ...

                Je vois pas trop ce que tu veux dire avec "la fenêtre descend".

                Enfin, Free & One ont des "saveurs" différentes parce qu'elles ne sont pas destinées aux mêmes personnes.

                Free = personne avancée, sachant ce qu'elle fait.

                Bref, c'est dommage de faire un test à l'aveuglette en choisissant la version la "moins" intuitive sans s'impliquer. Les conclusions ne peuvent pas être bonnes.

                NB : moi aussi je peux faire planter Ubuntu, en essayant d'installer Kubuntu dans une machine virtuelle, via netinstall car je lui ai demandé Gnome ...

                Ce n'est pas parce que les choses sont difficiles que nous n'osons pas. C'est parce que nous n'osons pas qu'elles sont difficiles. - Sénéque

                • [^] # Re: une RC avec un kernel non stable

                  Posté par  (site web personnel) . Évalué à 4.

                  Dual, c'est les dual arch, pour une installation sur les architectures i586 et x86_64 (selon la machine) avec la même iso...
                • [^] # Re: une RC avec un kernel non stable

                  Posté par  (Mastodon) . Évalué à 3.

                  Neije, IsNotGood n' avance pas à l' aveuglette ;)
                  Amicalement
                • [^] # Re: une RC avec un kernel non stable

                  Posté par  . Évalué à 3.

                  > Si tu as pris la free, tu as pris le DVD ?

                  Non, trop gros à télécharger.

                  > Gnome & KDE ne peuvent pas être présent sur un CD (la galette est trop petite).

                  Pas de problème avec ça. De plus l'installeur permet d'ajouter Gnome depuis le réseau.

                  > Dual, n'a rien à voir avec KDE ou Gnome, c'est pour les images sur clef USB ...

                  C'est la seul image CD pour Free...

                  > Donc si tu pars d'un CD KDE

                  Pas le choix si je ne veux pas de proprio et ne veut pas télécharger un DVD.

                  > Je vois pas trop ce que tu veux dire avec "la fenêtre descend".

                  Elle descend, elle va vers le bas de l'écran et tellement loins qu'elle disparait de l'écran.

                  > Free = personne avancée, sachant ce qu'elle fait.

                  La Free doit être pour ceux qui ne veulent pas de proprio ! C'est tout, il ne doit pas y avoir d'autres différences avec la One.

                  > Bref, c'est dommage de faire un test à l'aveuglette en choisissant la version la "moins" intuitive sans s'impliquer.

                  J'ai pris la version la plus libre et à l'avenir je le ferais encore.
                  En passant, ma distribution préférée n'a que du libre et ce n'est pas une "sous-distribution".

                  > Les conclusions ne peuvent pas être bonnes.

                  Oubliez mon test. Pas de problème. Ce que j'ai fait n'est pas représentatif.
          • [^] # Re: une RC avec un kernel non stable

            Posté par  . Évalué à 7.

            > Ce qui me surprend, est que personne ne dit que Mandriva veut utiliser le même noyau que Fedora et Ubuntu au-lieu de bosser tout seul dans son coin.

            c'est un peu idiot. c'est une distribution GNU/Linux. tu voulais qu'ils mettent un noyau Hurd ou BSD ?

            et tu vas également dire que toutes les distributions qui utiliseront un noyau entre le 2.6.28 et le 2.6.30 copieront Fedora et Ubuntu ? les salauds :(
            • [^] # Re: une RC avec un kernel non stable

              Posté par  (site web personnel) . Évalué à 6.

              Les kernel hackers de Mandriva et de TurboLinux travaillent ensemble et proposent le même noyau. C'est pour cela que les kernels ont le suffixe mnb (exemple : vmlinuz-2.6.29-desktop-0.rc6.1.1mnb) qui signifie manbo venant de Mandriva et de TurboLinux.

              C'est une coopération qui unit l'Asie, l'Amérique du sud et l'Europe.
  • # l' hiver breton

    Posté par  (Mastodon) . Évalué à 1.

    Les développeurs, coincés chez eux à cause du froid et de cet hiver grisâtre et morose

    Haaa .. c' est pour ça que Kde est si bon ! Parcequ' un des principaux mainteneurs est breton, et que l' hiver en bretagne c' est pas de la tarte...

    Quoi ? la porte ? tartagueuleauxrmll ?
  • # Speedboot

    Posté par  (site web personnel) . Évalué à 10.

    >>> le chargement du système continue en arrière-plan, démarrant des processus secondaires très utiles, puis les moins importants. Speedboot permet ainsi à Mandriva de réaliser des temps de démarrage bien plus rapides

    C'est moi ou cette phrase est fausse ?
    D'après la news Speedboot démarre le plus vite possible le serveur X afin de donner à l'utilisateur l'illusion que le démarrage est terminé alors qu'en fait il y a encore plein de processus qui se chargent. C'est peut-être une bonne chose (je n'en sais rien) mais amha cela n'influe en rien sur le "temps de démarrage" de la machine qui reste identique.
    D'autre part est-ce que ce n'est pas la stratégie suivie par Windows ? Si oui et si le résultat est identique alors je ne peux que m'élever contre cette technique. Quand j'allume mon laptop au boulot et que XP me rend (faussement) la main après le boot je ne peux m'empêcher de maudire le responsable de ce système: on croit que l'ordi est lancé et on clique sur des trucs pour commencer à travailler...mais rien ne se passe et la diode du disque dur continue de clignoter frénétiquement !
    C'est vraiment de la poudre aux yeux pour faire croire que le système boote vite mais on ne peut pas réellement commencer à travailler.
    J'espère que Speedboot est mieux pensé à ce niveau.
    • [^] # Re: Speedboot

      Posté par  (Mastodon) . Évalué à 2.

      +1
      +10 même !

      ce système n' est adapté qu' aux netbooks, où le nombre restreint de services n' amenuisent pas le confirt d' utilisation d' un X lancé prématurement.
      C' est il me semble un peu la même tambouille (pas technique, seul le résultat) que upstart : upstart c' est génial pour les workstations, et encore, ça se discute. Par contre pour les serveurs et les stations avec de nombreux softs ISV ça pu sévère. (tien d' ailleurs Redhat travaille au remplacement de upstart alors que fedora l' intègre, mais pas de page sur et.redhat, je louche peut être ?)
      • [^] # Re: Speedboot

        Posté par  (Mastodon) . Évalué à 5.

        speedboot me semble donc parfaitement adapté à l' usage d' une Mandriva pour une majorité d' utilisateurs : une machine avec peu de services, qui boot vite, sur netbook ou laptop. De plus, le remplacement certain de upstart par une techno redhat permet d' avoir une fenêtre de tir autorisant l' utilisation de techno tierces, comme ce speedboot.
        Donc oui sur le fond. Mais en mettant en perspective l' utilisation d' une mandriva et le futur de sysV, speedboot à toute sa place, non ?
        Cdlt.
      • [^] # Re: Speedboot

        Posté par  (site web personnel) . Évalué à 2.

        >>> Redhat travaille au remplacement de upstart

        Tu a un lien pour voir de quoi il s'agit ?
      • [^] # Re: Speedboot

        Posté par  . Évalué à 2.

        > tien d' ailleurs Redhat travaille au remplacement de upstart

        A ma connaissance non. Red Hat utilise upstart. Du moins Fedora actuellement et RHEL pour la version 6.
        Par contre, avant l'arrivée d'upstart, Red Hat réfléchissait à remplacer init. Les idées de Red Hat étaient très proches de upstart, upstart a été pris.

        > pstart c' est génial pour les workstations, et encore, ça se discute. Par contre pour les serveurs et les stations avec de nombreux softs ISV ça pu sévère.

        ???
        Je ne vois pas pourquoi ça pu sur serveur.
        C'est évidement moins utile puisque les serveurs ne sont pas booté tous les matins.

        > softs ISV

        Passer à upstart n'est pas grand chose. Les ISV devront certifier à nouveau leur programme pour RHEL6, ils en profiterons pour faire les adaptions nécessaires à upstart. J'ignore s'il faut faire des modifications...
      • [^] # Re: Speedboot

        Posté par  . Évalué à 2.

        > C' est il me semble un peu la même tambouille (pas technique, seul le résultat) que upstart

        Techniquement on peut y trouver des ressemblances. Le but d'upstart est plus générique, on peut lancer des services après gdm, on peut aussi ne pas le faire (je crois qu'actuellement personne ne le fait).
        Comme Mandriva va passer à upstart, il faudra refaire bootspeed pour utiliser upstart.
        Perso je préfère que mon système ait fini de booter une fois que GDM a fini de se charger.
        Ici le Windows touch ne me plait pas du tout.
        • [^] # Re: Speedboot

          Posté par  . Évalué à 2.

          "Comme Mandriva va passer à upstart" : tu as une source pour ça ? J'en ai jamais entendu parler...
          Sur speedboot, s'il permet de se loguer plus vite, c'est quand même globalement bénéfique au temps de boot "grub -> desktop 100% utilisable". D'ailleurs il me semble que les dev RedHat ont dit penser à ce genre de code quand Mandriva a sorti les détails sur bootspeed.
          • [^] # Re: Speedboot

            Posté par  . Évalué à 3.

            > tu as une source pour ça ? J'en ai jamais entendu parler...

            J'ai vu un truc passer. Ça disait que Fedora abandonnait les anciens scripts de boot et qu'il fallait autre chose à Mandriva. Upstart a été suggéré.
            Par exemple :
            http://lists.mandriva.com/maintainers/2007-09/msg00393.php
            http://wiki.mandriva.com/en/uploads/6/61/Specs_2009spring.pd(...)
            2.5.5.1. initscript improvements
            Fedora has replaced rc.sysinit by upstart, starting with Fedora 9. This mean initscripts will probably no longer be maintained by Redhat soon. We should check upstart and see if it fits our needs (and doesn’t duplicate with prcsys).

            It could also be useful to start some services / programs after one specific event (desktop started, etc..) to make sure CPU is not overloaded at startup.


            Ce n'est pas définitif.
            • [^] # Re: Speedboot

              Posté par  . Évalué à 1.

              Effectivement, c'est visiblement une de leurs options, j'étais passé à côté.
            • [^] # Re: Speedboot

              Posté par  . Évalué à 2.

              > http://wiki.mandriva.com/en/uploads/6/61/Specs_2009spring.pd(...)

              Je me demande si ce document est bien à jour...
              La 2009 spring fournit toujours Xen (je doute qu'il y ait un support Xen dans le noyau).
              Il est indiqué le passage à virt-manager, mais il n'y est pas dans la rc1. Il y a virtualbox. Notons qu'il y a libvirt. Mais libvirt "tout nu", c'est un peu dure d'utilisation. Par contre il y a virualbox...
              A ce demander si c'est une release candidat.
              Sûr qu'on doit trouver virt-manager dans contrib. Mais c'est virtualbox qu'il y a dans main. Il est moins suprenant que j'ai eu des problèmes lors de mon test puisqu'il a été fait avec kvm.
              • [^] # Re: Speedboot

                Posté par  . Évalué à 1.

                > La 2009 spring fournit toujours Xen (je doute qu'il y ait un support Xen dans le noyau).

                $ urpmq -af kernel-xen
                kernel-xen-2.6.18.8-xen-3.3.1-2mdv-1-2mdv2009.1.x86_64
                kernel-xen-devel-2.6.18.8-xen-3.3.1-2mdv-1-2mdv2009.1.x86_64

                > Il est indiqué le passage à virt-manager, mais il n'y est pas dans la rc1. Il y a virtualbox. >Notons qu'il y a libvirt. Mais libvirt "tout nu", c'est un peu dure d'utilisation. Par contre il y a >virualbox...
                >A ce demander si c'est une release candidat.
                >Sûr qu'on doit trouver virt-manager dans contrib. Mais c'est virtualbox qu'il y a dans main. >Il est moins suprenant que j'ai eu des problèmes lors de mon test puisqu'il a été fait avec >kvm.

                Effectivement virt-manager est dans contrib : et alors ? Les deux dépôts sont activés automatiquement.

                C'est vraiment critiquer pour critiquer, il aurait été dans main tu aurais trouvé autre chose...
                • [^] # Re: Speedboot

                  Posté par  . Évalué à 1.

                  > kernel-xen-2.6.18.8-xen-3.3.1-2mdv-1-2mdv2009.1.x86_64

                  Super, un 2.6.18 qui n'est pas dans main.
                  Dis que je n'y comprend rien à l'organisation de Mandriva. Pas de problème.
                  Mais je n'ai pas trouvé le moindre kernel-xen dans la branche cooker/devel. Alors qu'il y a Xen dans main. Mais je suis sûr que tu vas trouver ça très logique de fournir Xen et ne pas pouvoir l'utiliser.

                  > Effectivement virt-manager est dans contrib : et alors ?

                  Donc main et contrib c'est la même chose.
                  Dommage qu'ils ne les fusionnent pas alors...
                  Et plus con encore qu'ils aient fait deux foix la même chose.

                  > C'est vraiment critiquer pour critiquer

                  J'avais un moment oublié que les mandriviens n'accèptaient pas les critiques.
                  Sauf peut-être la récurrente "la version précédente était mauvaise, mais la nouvelle est très bonne". Sûr qu'on va encore y avoir droit dans 6 ou 12 mois.
                  • [^] # Re: Speedboot

                    Posté par  (site web personnel) . Évalué à 3.

                    c'est le ton qui ne le fait pas :-)

                    mais non, main et contrib n'ont pas vocation à être fusionnés, même encore maintenant, ce n'est pas à l'ordre du jour.
                    Tu trouveras une définition sur http://wiki.mandriva.com/fr/Source
                    (ce qui me permet d'affirmer que tu n'y comprend rien à l'organisation de Mandriva. Pas de problème. :p)

                    $ urpmq -a xen
                    xen

                    $ urpmq -a kernel-xen
                    kernel-xen-2.6.18.8-xen-3.3.1-2mdv
                    kernel-xen-devel-2.6.18.8-xen-3.3.1-2mdv
                    Il a peut-être été prévu d'être packagé dans une version plus récente, je n'ai pas l'info.
                    • [^] # Re: Speedboot

                      Posté par  . Évalué à 2.

                      > c'est le ton qui ne le fait pas :-)

                      D'accord.

                      > Tu trouveras une définition sur http://wiki.mandriva.com/fr/Source

                      Donc kernel-xen pour 2009 Spring et virt-manageur ne sont pas "garantis en ce qui concerne les problèmes de sécurité" (dixit Mandriva).
                      Par contre Xen oui...
                      Libvirt est "garantis..." mais virt-manager ne l'est pas.
                      Où la cohérence ?

                      > Il a peut-être été prévu d'être packagé dans une version plus récente, je n'ai pas l'info.

                      C'est une explication possible.
                      En passant, on parle d'une Realese Candidat, pas de la première Alpha.
                      • [^] # Re: Speedboot

                        Posté par  (Mastodon) . Évalué à 2.

                        Je vais peut être mettre les pieds dans le plat... désolé d' avance.

                        Il me semble qu' il y a belle lurette que la distinction main/contrib n' est plus vraiment de rigueur. Mandrake à toujours été me semble t il plus "cool" dans la mesure ou les contributeurs peuvent intervenir sur des paquets Main. Tu peux te faire ta propre idée en utilisant sophie par exemple ( http://sophie.zarb.org ). Les paquets main et contrib sont en autre passés aux mêmes moulinettes (machines de compil, rpmlint interne...) et les exigences en terme de qualité sont les mêmes pour main et contrib.
                        Dans les faits certainement que des paquets de contrib ont moins de tests finaux et correctifs cosmétiques peut être. La différence s' arretes là ...
                        Seul la gamme Corporate à un soin particulier, correspondant à ce que tu es habitué en terme de fonctionnement à l' ancien fonctionnement de Fedora (Fedora a changé sa poltique récemment et s' est plus ouvert aux contributeurs aussi, non?), quant la gamme Corpo correspond toujours à la rigueur de Redhat.

                        J' espère pas trop m' être gourré, et si c' est le cas, j' espère que quelqu' un corrigera pour éviter d' éventuelles méprises.

                        Cdlt.
                        • [^] # Re: Speedboot

                          Posté par  . Évalué à 2.

                          Petite précision.
                          J'ai cherché à savoir ce qui était utilisé pour la virtualisation chez Mandriva car j'ai eu des problèmes en testant cette RC sous KVM.
                          Si j'éssaie de faire une synthèse, j'ai un problème réseau et Xorg. On peut dire que c'est grave (surtout le réseau) et que ça ne l'est pas vraiment vu le nombre de semaines qui reste avant la sortie et car c'est une bête installation sous KVM pour faire un test à l'arrache. Tester pour les développeurs est facile dans ce cas. Enfin, il ne faut pas écarter un problème avec la configuration de Fedora que j'ai. Je refais un essai en utilisant "safe setting" (lors du boot de l'installation), ça a corrigé le problème de menu.
                          Pour Fedora Rawhide et Ubuntu Alpha, j'ai aussi des problèmes d'affichage mais pas très génant. Pas de problème pour F10. Donc peut-être un problème Xorg 1.6.
                          Le mieux est qu'un Mandrivien fasse un essai, ce n'est pas contraignant sous KVM
                      • [^] # Re: Speedboot

                        Posté par  (Mastodon) . Évalué à 2.

                        Xen ne semble pas être une priorité pour Mandriva (ce qui est logique tu en conviendra). Un bon ou mauvais choix, je ne sais pas. Un choix logique parcequ il y a certainement peu d' utlisateurs ayant besoin de Xen d' une part, d' autre part ceux l' utilisant (hein Nantes_geek :p ) ont les compétences en internes et se font leurs propres outils, et enfin parceque c' est plutôt sur la gamme Corpo sur laquelle il faudra regarder Xen avec tes critères.

                        Xen est une ensemble de paquets et d' outils particuliers, il ne suffit pas je pense pour se faire une idée de la politique de packaging. Même si tu pointes avec une certaine justesse ce qui semble être un joli bordel pour ce xen à première vue :p

                        Si tu souhaites apporter ton savoir faire sur Xen ça serait génial, et moi je pourrai avoir Mandriva Xeniphié facilement sur ma RedHat Desktop, plutot que simplement chrootée :))




                        ps : encore une fois, les réserves de rigueur sur ce post, hein...
                    • [^] # Re: Speedboot

                      Posté par  . Évalué à 3.

                      > Il a peut-être été prévu d'être packagé dans une version plus récente, je n'ai pas l'info.

                      Ou, plus intéressant, c'est l'utilisation de Xen userland avec KVM (sans noyau kernel-xen). Je crois que c'est un objectif de Fedora qui fournit toujours Xen mais pas kernel-xen.
          • [^] # Re: Speedboot

            Posté par  . Évalué à 2.

            > D'ailleurs il me semble que les dev RedHat ont dit penser à ce genre de code quand Mandriva a sorti les détails sur bootspeed.

            Adam Willamson a dit qu'il fallait y penser. En effet, il y a eu des benchs et la dernier cooker boote plus vite que rawhide (la futur F11). Mais ceci ne prend pas en compte le temps de login.
            Il n'est pas acquis que le principe de bootspeed soit adopté par Fedora.
            Au premier abord je suis contre. Néanmoins dans les cas d'éléments externes qui ralentissent le boot (par exemple dhcp), c'est à considérer sérieusement.
            • [^] # Re: Speedboot

              Posté par  . Évalué à 2.

              Tu as testé la cooker pour voir ce que ça donne en pratique ? C'est encore la meilleure façon de se faire vraiment un avis.
              • [^] # Re: Speedboot

                Posté par  . Évalué à 5.

                moi j'ai testé, et c'est très rapide. D'ailleurs, KDE 4.2.1 avec une dizaine de plasmoide ne prend que 260 mégas (avec 1 dolphin). J'utilise également firefox 3.1b2 avec, et c'est impressionnant le peu de mémoire que le tout peut utiliser.

                http://blog.karlt.net/2008/12/firefox-31-beta-2-on-linux-use(...)

                J'ai 2 Gigas sur ma machine, et KDE est connu pour avoir une gourmandise dépendante de la quantité de RAM. Je vous laisse imaginer la conso sur une petite machine...
                • [^] # Re: Speedboot

                  Posté par  (Mastodon) . Évalué à 2.

                  +1
                  Kde sur un acer one avec 512 de ram ne consomme que 300mo dans une configuration Mr Michu (kde + plein de plasmoïdes + composite sur kwin pour les effets + Konqueror avec 8 onglets et plein de flash dedans + OpenOffice sur Impress) Impressionnant ... Bon, j' ai remis LXdesktop pour avoir un boot rapide, et parceque ça me suffit pour le netbook!

                  /blague
                  quoi ? le debug n' est plus activé que sur les paquets debug, vraiment ? quoi les options de compil de kde ont changés ? ben je sais pas, mais ça a changé!
                  /blague

                  En tout cas il semble bien qu' on puisse de nouveau dire KDE (et pas KDE4) ...

                  Vivement un écran tactile pour profiter de Kde !!!!!
            • [^] # Re: Speedboot

              Posté par  . Évalué à 3.

              >Adam Willamson a dit qu'il fallait y penser.
              Non, Adam a parlé du travail de Frédéric à Harald Hoyer (the main developer working on improved boot speed for Fedora ) et c'est Harald Hoyer qui a dit qu'il pensait à faire quelque chose de cette manière pour fedora dans le futur:
              I pointed it out to Harald, and he said he’s been thinking along very similar lines, so something similar may come into Fedora in the future.
              http://www.happyassassin.net/2009/02/23/20-second-startup-te(...)
              http://www.happyassassin.net/2009/03/02/20-second-boot-test-(...)
              • [^] # Re: Speedboot

                Posté par  . Évalué à 2.

                OK.
                Mais ça ne change pas grand chose :-)
                Ce que tu pointes n'est pas ce à quoi je pense et j'ai la flemme de chercher.
                Qu'importe, Fedora y pense.
        • [^] # Re: Speedboot

          Posté par  . Évalué à 10.

          Sauf que continuer à charger le système pendant le chargement du display manager, c'est pas si stupide que ça.
          T'as toute l'étape d'initialisation du serveur X qui prend pas mal de temps, et pendant laquelle tu peux encore lancer des services. Et surtout, t'as la phase de saisie de login/mot de passe : plusieurs secondes où rien n'est nécessaire en CPU/IO, et pendant lesquelles l'utilisateur n'a besoin que d'un clavier opérationnel...
    • [^] # Re: Speedboot

      Posté par  . Évalué à 5.

      > C'est moi ou cette phrase est fausse ?

      C'est toi qui pinaille en ne considérant *ta* définition du temps de démarrage.

      > amha cela n'influe en rien sur le "temps de démarrage" de la machine qui reste identique.

      Tout dépend de la définition du temps de démarrage, la définition la durée entre l'appui sur le bouton et l'apparition d'un prompt de login (ou d'un bureau en mode auto-login) utilisable est une définition aussi valable qu'une autre.

      Toute définition est ambigue: si un script de démarrage lance un 'updatedb' en tache de fond et basse priorité, doit-on considerer qu'il faille attendre la fin du updatedb avant de considerer le démarrage fini?
    • [^] # Re: Speedboot

      Posté par  (site web personnel) . Évalué à 9.

      Voici le fonctionnement de speedboot expliqué par Fred Crozat :
      http://blog.crozat.net/2009/02/speedboot-explained.html
      http://wiki.mandriva.com/en/2009.1-speedboot

      Les premiers résultats:
      http://blog.crozat.net/2009/01/fosdem-reducing-boot-time.htm(...)

      Et l'origine de tout cela (perception du temps de boot, résumé de ce qu'à fait Mandriva à ce sujet, et réactions suite aux optimisations menées par Arjan Van de Ven pour booter en 5 secondes sur un eeepc...):
      http://blog.crozat.net/2008/09/improving-boot-time-on-genera(...)
  • # Qt Creator en version 4.5.0 ?

    Posté par  (site web personnel) . Évalué à 9.

    « On remarquera aussi la présence de QT Creator en version 4.5.0 »

    Pas du tout. La dernière version de Qt Creator est la version 1.0
    C'est Qt (tout court) qui est en version 4.5.0

    (Par ailleurs c'est Qt et non QT)
    • [^] # Re: Qt Creator en version 4.5.0 ?

      Posté par  . Évalué à 8.

      Oui en effet, quelques erreurs se sont glissées dans l'article par ma faute. Vraisemblablement, je n'étais pas en forme ce qui ne m'a pas réussi sur certains passage. Ici, je clarifie donc, à défaut de mode d'édition disponible apparemment, les erreurs pointées par les commentaires précédent, et vous fournis plus d'informations :

      SPEEDBOOT
      "Speedboot essaie de démarrer en premier tous les scripts nécessaires au système graphique (display manager) pour obtenir rapidement un environnement de bureau, pendant que les autres services nécessaires à un démarrage complet (full boot) sont chargés en arrière plan. ", telle est la définition écrite dans le Wiki Mandriva.

      Si Speedboot vous intéresse, vous trouverez plus de détails sur :
      - L'article sur Speedboot dans le Wiki Mandriva : http://wiki.mandriva.com/fr/2009.1-speedboot
      - L'entrée de Frederic Crozat dans son blog qui explique en détail comment fonctionne Speedboot : http://blog.crozat.net/2009/02/speedboot-explained.html (en anglais)

      Il y a également un article sur le temps de démarrage de Speedboot en comparaison avec d'autres systèmes sur silicon.fr : http://www.silicon.fr/fr/news/2009/02/23/mandriva_donne_un_c(...)


      QT CREATOR :
      Effectivement, QT Creator est fourni en version 1.0 tandis que QT est fourni en version 4.5 depuis la Beta 1 de Mandriva 2009 Spring.

      Je présente mes excuses pour ces erreurs et espère avoir clarifié les choses. Si vous voyez d'autres inexactitudes, faites moi signe. Merci.
  • # HDT

    Posté par  (Mastodon) . Évalué à 2.

    Ouaih!! HDT est intégré !!!
    http://wiki.mandriva.com/en/2009.1_RC_1#Syslinux_-_HDT

    Merci Erwan !!!!!!!!!!!!!
    Tu m' en avais parlé au printemps dernier. ça c' est clair que c' est génial. Reste à trouver comment correctement traiter les infos reçues à l' autre bout :p ;) Ca va le faire ce truc pour des installs massives de clones sur des machines différentes... ça va le faire grave !!! (bon c était peut être pas l' usage prévu au départ, désolé)

    Référence upstream :
    http://syslinux.zytor.com/wiki/index.php/Hdt_(Hardware_Detec(...)

    Je suppose que de nombreux systèmes d' install vont se mettre assez rapidement au diapason de HDT.
  • # ça aura pris du temps

    Posté par  . Évalué à 3.

    Je me souviens du temps où j'étais en stage chez mandrake (2003-2004) et nous avions demandé aux devs d'essayer de mettre en place ce qui est appelé ici comme Speedboot. Est-ce que ce n'était vraiment pas faisable à l'époque ? En tout cas je me souviens bien de la réponse "On fait déjà tout pour démarrer le plus vite possible". Mouais.

    En tout cas merci à Fred j'avoir développé cette fonctionnalité.
    • [^] # Re: ça aura pris du temps

      Posté par  . Évalué à 3.

      Disons que quand les netbooks qui bootent en 8 secondes sont arrivés, ça a replacé le sujet en première ligne.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.