Il existe des versions "desktop" pour entreprise, alliant support à long terme et facilité d'utilisation pour le commun des mortels.
Certes pas chez RH qui ne s'aventure pas sur ce marché, mais chez d'autres, comme Novell par exemple (SUSE Linux Enterprise Desktop aka SLED, qui fonctionne comme un client pour une version server SLES).
Hormis les widget plasma qui foire un peu, j'ai globalement trouvé l'environnement 4.0.3 plus réactif et assez stable, sauf les effets à la compiz. Globalement : plus que satisfait, et même un peu étonné au vu des résultats obtenus sur les version pécédentes 4.0.1 et 4.0.2.
Par contre, utiliser ces même appli sous l'environement KDE 3 me donnait une sensation de lourdeur : On sent bien que l'appli n'utilise pas les librairies préchargées du système.
C'est peut être du à l'effort fait par les dev openSUSE : certaines review trouvent moins stable la version Kubuntu. Egalement, une "rumeur" sur les canaux IRC répandaient l'information que le packaging Kubuntu etait bien en deça de celui d'openSUSE.
Je n'ai pas vérifié, et j'en suis même un peu surpris : le packaging d'une distrib peut-il réellement donner un grosse différence ?
(ps: Un sondage datant d'il y a quelques mois montraient que les dev. KDE utilisaient en grande majorité Kubuntu, openSUSE et un peu debian si mes souvenirs sont bons).
Le 28 juin 2005, la version 4 est publiée et améliore notamment le moteur de rendu, la séparation entre données et présentation et sépare la bibliothèque en divers modules :
* QtCore : pour les fonctionnalités non graphiques utilisées par les autres modules ;
* QtGui : pour les composants graphiques ;
* QtNetwork : pour la programmation réseau ;
* QtOpenGL : pour l'utilisation d'OpenGL ;
* QtSql : pour l'utilisation de base de données SQL ;
* QtXml : pour la manipulation et la génération de fichiers XML ;
* QtDesigner : pour étendre les fonctionnalités de Qt Designer, l'assistant de création d'interfaces graphiques ;
* QtAssistant : pour l'utilisation de l'aide de Qt ;
* Qt3Support : pour assurer la compatibilité avec Qt 3 ;
À cela s'ajoute pour la version commerciale sous Windows deux autres modules liés à l'utilisation d'ActiveX : QAxContainer et QAxServer
Avec l'évolution de Qt 4, d'autres modules sont conçus :
* QtDBus : pour la communication inter-processus en utilisant D-Bus (uniquement sous UNIX à partir de Qt 4.2) ;
* QtScript : pour l'évalution de scripts utilisant Qt Script (à partir de Qt 4.3) ;
* QtSvg : pour l'affichage d'images aux formats SVG (à partir de Qt 4.1) ;
* QtUiTools : pour charger dynamiquement les interfaces graphiques créées avec Qt Designer (à partir de Qt 4.1) ;
* QtTest : pour effectuer des tests unitaires (à partir de Qt 4.1) ;
* QtWebKit, portage du moteur de rendu web WebKit (à partir de Qt 4.4) ;
* Phonon : intégration de Phonon, framework multimédia de KDE4, développé en collaboration avec la communauté KDE (à partir de Qt 4.4) ;
Effectivement, Fedora répond à son objectif :
Etre une distribution "expérimentale" avant gardiste (et elle le fait bien).
En revanche, openSUSE sortira quelques semaines après Fedora, elle aussi muni de la branche KDE 4.0.x. Ses objectifs étant différents (user friendly tout en restant innovative aussi) les critiques de Neiji pourraient très bien lui être appliquées.
Les différentes reviews qu'on peut lire par-ci par là sont plutôt positive. Les dev ont également fait un train gros travail en parallèle afin de stabiliser la branche "opensuse" de KDE 4 (qui se retrouveront dans la branche upstream) et cela semble porter ses fruits. Mais cette prochaine release reste une version "risquée", où l'utilisateur servira de "post-cobaye".
Et Fedora 9 sera suivie par openSUSE dans 6 semaines.
Outre la présence d'un KDE 4 natif à la sauce germanique, tous les outils de configuration (Sax, modules YaST, installateur) ont déjà été porté vers Qt4. Au passage, l''installateur a pris un sacré coup de jeune...
Je me rappelle aussi d'un poster du même type d'o'reilly, mais pour une distribution Linux et toutes ses "couches" au dessus du noyau (en allant du kernel aux appli finale, aux langages de prog et services web). Un espèce de siphon avec une grosse boule kernel au milieu.
Depuis le temps, je crois que je n'ai pas trouvé mieux pour avoir une vue d'ensemble d'une distrib Linux. Cette représentation graphique est son complément idéal.
Les outils que tu cites existant bien avant ubuntu, quels sont les grands progrès qui ont été fait ? Ces distributions sont très facile à installer depuis longtemps...
Oui, comme sous entendu :
(quoique qu'elles etaient déjà passablement simple à installer.. ).
Je pensais plutôt à l'installation par Live-CD, qui n'existait pas/n'était pas mis en avant chez les autres distrib "grand public". Je me rappelle de Mepis qui fonctionnait sur ce principe, Knoppix aussi mais le but premier pour cette dernière était bien de fonctionner en live.
D'autant plus qu'on installe Ubuntu avec les choix par défaut, Mandriva et openSUSE demandent de faire des choix (perso je préfère celà, mais pour un nouveau.. )
La majorité des distributions "grand public" ont fait beaucoup de progrès dans leur processus d'installation depuis l'arrivée d'Ubuntu sur le marché (quoique qu'elles etaient déjà passablement simple à installer.. ).
Côté facilité d'utilisation, un centre de contrôle centralisé est un gros plus. Je citerais les 3 premières qui me viennent à l'esprit :
- Mandriva, avec son drakeconf
- PCLinuxOS (basé sur Mandriva) et de plus en plus populaire
- openSUSE avec YaST
[...] la majorité des développements de red hat sont en open source, tous les dev de mandriva sont en gpl (pour novel, suse, je me prononcerai pas je ne sais pas)
Moi je sais, alors je réponds :)
Tous les developpements et toute l'infrastructure d'openSUSE est libre (GPL) et disponible, tout le developpement est ouvert et accessible (mailing lists des dev, svn, etc.). Pour le côté SUSE Entreprise, seuls les correctifs (rpms binaires et sources) des correctifs ne sont pas disponible publiquement (au contraire de RH qui fournit les sources rpm).
A noter, un exemple, qui ressemble _extrement_ au cas de Lauchpad de Canonical, est le Build Service d'openSUSE.
Le Build Service à pour vocation de créer, de façon centralisée et simplifiée, des paquets RPM/DEB pour plusieurs distribution à partir du même code source (un seul fichier .spec). Il permet de lier des projets entre eux et d'augmenter l'interaction et le dynamisme des projets, pas forcément lié à la distribution openSUSE.
Très récemment, une nouvelle fonction de distribution p2p est apparue (soit, exactement ce que Canonical veut/est en train d'implémenter) est disponible. On peut ainsi installer une version locale du Build Service et faire la synchronisation vers un autre Build Service.
Dès le départ, les sources (en rpm/tar.gz) du Build Service étaient disponibles.
Que Mark Shuttleworth prétende que Lauchpad est closed source pour le bien des projets est du foutage de gueule royal. Je pense que ce n'est que par la pression des "Libristes" (entre autres ceux de GoButuntu et GNewSense) que Shuttleworth va ouvrir les sources (bientôt? ça fait 2 ans qu'il nous sort la même salade), et que Launchpad a été pensé à la base comme pièce maitresse de la stratégie de Canonical pour se rendre indispensable.
ps : tu pouvais le dire que ta distribution c'est Mandriva...
Non, ça fait un moment qu'il n'utilise plus Mandriva (rappelle toi du journal "les cents jours"). Il utilise debian sid, si mes suppositions sont bonnes.
L'ordinateur est un instrument d'acquisition de culture et de connaissance. Refuser de savoir comment marche l'informatique, c'est comme refuser d'apprendre à lire, et c'est laisser à d'autre la connaissance.
L'ordinateur est un instrument d'acquisition de culture et de connaissance. Refuser d'apprendre comment utiliser l'informatique, c'est comme refuser d'apprendre à lire, et c'est laisser à d'autre la connaissance.
Si je me souviens bien, la licence windows XP stipule que tu ne peux installer l'os que sur une seule machine (une seule carte mère). Je pense donc que le vendeur a raison.
Aussi, il est possible d'acheter un pc sans vista (il a raison), mais pas chez casino. Le vendeur a (surement) raison.
Après, oui, c'est de la vente liée, pour la raison que Carrefour ne propose pas un autre choix /pas d'os du tout dans son offre. Mais tu ne peux pas demander à acheter un pc pour y mettre ta licence attribuée à ton portable.
Ah oui, petite précision qui a peut être tout son sens :
Outre par AMD, openSUSE est sponsorisé par IP Exchange Germany, qui procure toute l'infrastructure réseau (bande passante, gros débits). Je ne sais pas dans quelle proportion, mais c'est surement un facteur décisif pour la bonne marche de l'oBS.
Je te confirme bien que la Factory est recompilée à chaque mise à jour. Et quand la libc passe pas, et bien la Factory ne compile pas (les "build" de la factory ne sont pas fait régulièrement, ca dépend si ça passe.. ou si ca casse).
Et effectivement, ça pose le problème de la bande passante.
Je ne sais pas comment font les miroirs qui relaient la Factory (comme indiqués, tous les mirroirs openSUSE n'ont pas le même contenu), mais pour les utilisateurs/testeurs Factory, c'est 1 à 3 Go (ou plus) de mise à jour par ~semaine.
Pour ce qui est des dépendances cycliques, j'en sais fichtrement rien (moi et la compile de paquets... comme tu l'as vu ceux que je propose sont de mauvaises qualité, mais c'etait juste un test pour me faire la main :) )
@guitoo > Effectivement, si j'avais déjà vaguement entendu parler de gdebi (et que j'ai complètement oublié lors de l'écriture de ce paragraphe), j'ignorais totalement que RH/Fedora pouvait également installer les dépôts et les utiliser (il fait ça gdebi?). Je ne connaissais pas non plus le système de Linspire.
Par contre, et suite aux commentaire ci-dessus, je note qu'il y a quand même une petite différence.
L'OCI d'openSUSE est conçu plus comme une couche d'abstraction : les liens OCI ne pointent pas directment vers le fichier RPM/deb en question, mais sur un fichier XML. Ce fichier XML peut décrire, au choix :
- l'installation d'un dépôt
- l'installation d'un paquet (et résolution dépendance), indépendamment de sa version
- l'installation d'un groupe de paquets d'un dépot
- l'installation d'un groupe de paquets situés sur plusieurs dépôts (pratique pour installer en quelques clics tous les fichiers nécessaires au "débridage" d'openSUSE via les repo Packman et VideoLan, par exemple)
- etc, etc. On peut imaginer toute sorte de combinaison plus ou moins utile selon la situation.
Chaque lien fichier XML peut en outre être muni d'option, tel que de garder ou non le dépot après installation des fichiers, une section "avancée" qui permet de sélectionner individuellement certains paquets d'un groupe de paquets par défaut, ...
Mais c'est surtout sa mise en avant, son utilisation par défaut et toute l'adaptation de l'infrastructure autour (wiki / moteur de recherche officiels et communautaires) qui ajoute cette plue value à la distribution.
Et je pense que toute les distributions auraient a gagner en utilisant "plus" (ou de façon native pour .deb) ce système qui n'est "pas une nouveauté" (enfin, Fedora ne semble pas intéressé par ce système "à la kéké", malgré qu'il est fonctionnel depuis des lustres :) )
@GeneralZod > Je ne pense pas que cette méthode "à la windows" déclencherait un retour au "dependancy hell", tant que l'environnement autour de la distribution est adaptée : les moteurs de recherche de paquets par défaut indiquent clairement le dépôt utilisé. C'est aussi plus facile quand la majorité de l'infrastructure est centralisée (oBS) et qu'il n'y a pas x dépôts disparates (websphere openSUSE plutôt limitée comparée à d'autres distributions).
Par contre, il est clair que mélanger des dépôts 10.3 avec des dépôts Factory ça risque de faire mal...
>>Toute l'infrastructure du Build Service tourne sur plus d'une centaine de machines généreusement données par AMD au projet openSUSE
>Et pourquoi pas des milliers !
>Pour Fedora (compilation i386, x86_64, ppc et ppc64), il n'y a "que" dix machines (certaines virtuelles) :
>http://koji.fedoraproject.org/koji/hosts
>Et tout y est compilé, ce n'est pas que dédié "extras". La distribution y est compilé, les mises à jours, les contributions externes, rawhide, etc.
Tu as raison, je suis allé un peu vite. De mémoire, il me semblait avoir lu quelque part le nombre de 126 machines (irc ?). Je n'ai pas réussi à retrouver une source pour ce nombre.
Cependant, sur le blog d'un développeur KDE employé par SuSE/Novell [1], j'ai trouvé le nombre de "plus de 120 CPUs" qui me laisse penser que ma mémoire était bonne,
Alors effectivement, ce n'est pas plus de 120 machines (du moins je pense, je n'ai aucune idée du nombre de CPU par machine, et encore moins du nombre de core par CPU...).
Ma seconde erreurs est d'avoir écrit tacitement que ces machines ont toutes été données par AMD. C'est bien sûr l'ensemble des machines (don AMD + le parc existant) qui représente ces 120+ CPUs.
>> Le Build Service a de multiples avantages :
>> - Il resoud automatiquement les dépendances des paquets compilés.
>Ce n'est pas un avantage, c'est une nécessité.
>> Ainsi, si un paquet B dépend d'un autre paquet A, le paquet B va être automatiquement recompilé si la dépendance A est modifiée et recompilée.
>"Foutaise".
>Presque tous les paquets dépendent de libc ou gcc. Si libc ou gcc est changé, tu nous expliques que le build système va recompiler tous les paquets !
>Et comment tu fais pour gérer les versions ? Ben oui, il va y avoir des toto-1.0-1 avec différent libc et gcc. Ça sucks.
>Bref, ce truc je n'y crois pas.
C'est pourtant ce qu'il se passe. Heureusement, la libc et gcc ne changent pas trop pour une version stable, mais il en est autrement pour les builds Factory (la version de dev opensuse).
Cet utilisateur lambda a compilé quelques paquets pour une version stable (10.3) et la version Factory. Je sais, de source sûre, que cet utilisateur a compilé ces paquets dans le mois d'octobre 2007 et n'y a pas touché depuis.
Les paquets du répertoire 10.3 sont datés d'octobre 2007. En revanche, les paquets Factory sont datés de deux jours (samedi 8 mars 2008 vers 07h55 - mes sources indiques que l'utilisateur lambda cité dormait encore), soit grosso modo la date de la dernière recompilation de la Factory. Et c'est comme ça pour tous les builds Factory.
Aussi, la Factory est recompilée (quasi) entièrement une à deux fois par semaine (à chaque mise à jour, et pas seulement lors du changement de la libc ou gcc). Ca permet de s'assurer que tous les paquets fonctionneront (avec le désavantage e lancer une compile après l'autre.. ).
J'imagine que les paquets compilés pour une version stable sont recompilés lors d'une mise à jour de sécurité (un rapide coup d'oeil à la liste des maj de sécu me montre qu'il n'y a pas eu d'update de la libc / gcc de octobre à ce jour). Ou alors, peut être qu'une simple faille corrigée dans la libc/gcc ne fait pas perdre de son caractère compatible (?).
Enfin, il me semble qu'entre la ligne du "c'est une nécessité" et la suivante "Foutaise" qui parle du même sujet, il y a une subtilité qui m'échappe..
>Mais il me semble qu'un aspect est "négligé". >C'est la qualité, une vue d'ensemble. Fedora ne permet pas à tout le monde de compiler sur koji pour des raisons de qualité. >Un paquet est accèpté qu'après un audit sérieux du paquet (licence, état de l'art, es-ce une technologie obsolète ou pas, etc).
>Ça s'inscrit dans un projet qui a des objectifs. Ça fédère dans gens autour de ces objectifs. Ce n'est pas une libre service. >C'est un mal et c'est un bien. Limiter les fonctionnalités (par exemple ne pas permettre à tout le monde de compiler) n'est pas forcément un mal.
Effectivement, je n'ai pas trop parlé de cet aspect "qualité". Après un rapide aperçu du BS, je voulais surtout mettre le doigt sur la possibilité de compiler des paquets autres qu'openSUSE (ce qui est surement plus intéressants pour la majorité des leceturs linuxfr), et surtout que la démarche entreprise par Fedora est la même pour les toutes autres distributions j'imagine.
Pour openSUSE, la seule différence est que les paquets "grands publics" (/repositories/home:/user) sont déjà dispo. Mais ils doivent bien sûr être approuvés avant d'entrer dans les dépôts semi-officiels contenus dans /repositories/projet (ex:KDE:/Backport) ou communautaires (ex: KDE:/Community).
Pour ceux que ça intéresse, cette présentation[2] fournit un schéma montrant bien le processus (slide 17). Le reste du PDF aborde les principes généraux du BS et quelques limites du BS dont je n'ai pas parlés. Egalement, le wiki openSUSE est assez exhaustif.
Pour smart, c'est justement le comportement que tu décris que je citais comme "efficacité agressive", mais je reprendrais ça ce week end (si j'ai le temps..)
Je ne saurais répondre (le 320 Go est indiqué tel quel dans ma source), un debianniste sera mieux placé que moi.
Mais rien que l'arbre FTP d'une seule version openSUSE et pour une architecture doit tourner autour des 15 à 20 Go si mes souvenirs sont bons.
Le BuildService (/repositories) contient des mises à jours semi-officielles pour plein de composants (KDE3 et 4, GNOME, Xorg, drivers, etc.) mais surtout, la grosse partie du contenu est faite des builds personnels des utilisateurs (/repositories/home:). Des paquets peuvent donc y être sous différentes formes et versions (genre un blender 2.43, 2.44, avec tel ou tel patch, etc.)
En ce qui concerne le nombre de package, je sais qu'avant l'ère Novell la distribution entière tenait sur un DVD double (pour une arch). Depuis, le nombre de paquets a complètement explosé. Selon la mailing-list de septembre 07 [1], le nombre de paquets sources était de ~3500+ dans le Build service (sans compter le /repositories/home:), et ~2500+ dans le repo communautaire packman (pour ~14'000 binaires)
Sinon, je crois que Gentoo est passé devant debian depuis un moment en terme de nombre de paquets différents absolu.
Et non, il n'y a pas de patrick_g dans ma famille. La preuve est qu'il y a un gros gène de monstrueuses fautes d'ortho dans la mienne...
Cette petite exploration présente avant tout mon point de vue, avec un biais sur les techniques employés par la distribution que j'utilise. Je n'ai pas le recul nécessaire ou une connaissance suffisante des autres distributions, bref, pas vraiment d'objectivité. Et comme précisé dans l'entête, les lecteurs me corrigeront.
Par contre, je n'avais pas assez de XP pour le placer en journal de première page...
[^] # Re: Ayons une pensée pour les utilisateurs
Posté par Spyhawk . En réponse au journal Mark Shuttleworth : il remet ça. Évalué à 2.
Je pensais qu'ils avaient essayé puis arrêté. Mon cerveau a du mixer avec la news du "desktop" pour les masses.
[^] # Re: Ayons une pensée pour les utilisateurs
Posté par Spyhawk . En réponse au journal Mark Shuttleworth : il remet ça. Évalué à 5.
Certes pas chez RH qui ne s'aventure pas sur ce marché, mais chez d'autres, comme Novell par exemple (SUSE Linux Enterprise Desktop aka SLED, qui fonctionne comme un client pour une version server SLES).
[^] # Re: À quand les premières versions opérationnelles ?
Posté par Spyhawk . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 3.
Hormis les widget plasma qui foire un peu, j'ai globalement trouvé l'environnement 4.0.3 plus réactif et assez stable, sauf les effets à la compiz. Globalement : plus que satisfait, et même un peu étonné au vu des résultats obtenus sur les version pécédentes 4.0.1 et 4.0.2.
Par contre, utiliser ces même appli sous l'environement KDE 3 me donnait une sensation de lourdeur : On sent bien que l'appli n'utilise pas les librairies préchargées du système.
C'est peut être du à l'effort fait par les dev openSUSE : certaines review trouvent moins stable la version Kubuntu. Egalement, une "rumeur" sur les canaux IRC répandaient l'information que le packaging Kubuntu etait bien en deça de celui d'openSUSE.
Je n'ai pas vérifié, et j'en suis même un peu surpris : le packaging d'une distrib peut-il réellement donner un grosse différence ?
(ps: Un sondage datant d'il y a quelques mois montraient que les dev. KDE utilisaient en grande majorité Kubuntu, openSUSE et un peu debian si mes souvenirs sont bons).
[^] # Re: Tout en un ?
Posté par Spyhawk . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 5.
Le 28 juin 2005, la version 4 est publiée et améliore notamment le moteur de rendu, la séparation entre données et présentation et sépare la bibliothèque en divers modules :
* QtCore : pour les fonctionnalités non graphiques utilisées par les autres modules ;
* QtGui : pour les composants graphiques ;
* QtNetwork : pour la programmation réseau ;
* QtOpenGL : pour l'utilisation d'OpenGL ;
* QtSql : pour l'utilisation de base de données SQL ;
* QtXml : pour la manipulation et la génération de fichiers XML ;
* QtDesigner : pour étendre les fonctionnalités de Qt Designer, l'assistant de création d'interfaces graphiques ;
* QtAssistant : pour l'utilisation de l'aide de Qt ;
* Qt3Support : pour assurer la compatibilité avec Qt 3 ;
À cela s'ajoute pour la version commerciale sous Windows deux autres modules liés à l'utilisation d'ActiveX : QAxContainer et QAxServer
Avec l'évolution de Qt 4, d'autres modules sont conçus :
* QtDBus : pour la communication inter-processus en utilisant D-Bus (uniquement sous UNIX à partir de Qt 4.2) ;
* QtScript : pour l'évalution de scripts utilisant Qt Script (à partir de Qt 4.3) ;
* QtSvg : pour l'affichage d'images aux formats SVG (à partir de Qt 4.1) ;
* QtUiTools : pour charger dynamiquement les interfaces graphiques créées avec Qt Designer (à partir de Qt 4.1) ;
* QtTest : pour effectuer des tests unitaires (à partir de Qt 4.1) ;
* QtWebKit, portage du moteur de rendu web WebKit (à partir de Qt 4.4) ;
* Phonon : intégration de Phonon, framework multimédia de KDE4, développé en collaboration avec la communauté KDE (à partir de Qt 4.4) ;
[^] # Re: À quand les premières versions opérationnelles ?
Posté par Spyhawk . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 3.
Etre une distribution "expérimentale" avant gardiste (et elle le fait bien).
En revanche, openSUSE sortira quelques semaines après Fedora, elle aussi muni de la branche KDE 4.0.x. Ses objectifs étant différents (user friendly tout en restant innovative aussi) les critiques de Neiji pourraient très bien lui être appliquées.
Les différentes reviews qu'on peut lire par-ci par là sont plutôt positive. Les dev ont également fait un train gros travail en parallèle afin de stabiliser la branche "opensuse" de KDE 4 (qui se retrouveront dans la branche upstream) et cela semble porter ses fruits. Mais cette prochaine release reste une version "risquée", où l'utilisateur servira de "post-cobaye".
[^] # Re: À quand les premières versions opérationnelles ?
Posté par Spyhawk . En réponse à la dépêche Qt 4.4 prend son envol. Évalué à 1.
Outre la présence d'un KDE 4 natif à la sauce germanique, tous les outils de configuration (Sax, modules YaST, installateur) ont déjà été porté vers Qt4. Au passage, l''installateur a pris un sacré coup de jeune...
# Dans le même genre (ou pas)
Posté par Spyhawk . En réponse au journal Un plan pour le noyau Linux. Évalué à 7.
Depuis le temps, je crois que je n'ai pas trouvé mieux pour avoir une vue d'ensemble d'une distrib Linux. Cette représentation graphique est son complément idéal.
[^] # Re: Michu compatible?
Posté par Spyhawk . En réponse à la dépêche Ubuntu 8.04 LTS : GNU/Linux pour le grand public. Évalué à 2.
Oui, comme sous entendu :
(quoique qu'elles etaient déjà passablement simple à installer.. ).
Je pensais plutôt à l'installation par Live-CD, qui n'existait pas/n'était pas mis en avant chez les autres distrib "grand public". Je me rappelle de Mepis qui fonctionnait sur ce principe, Knoppix aussi mais le but premier pour cette dernière était bien de fonctionner en live.
D'autant plus qu'on installe Ubuntu avec les choix par défaut, Mandriva et openSUSE demandent de faire des choix (perso je préfère celà, mais pour un nouveau.. )
[^] # Re: Michu compatible?
Posté par Spyhawk . En réponse à la dépêche Ubuntu 8.04 LTS : GNU/Linux pour le grand public. Évalué à 2.
Côté facilité d'utilisation, un centre de contrôle centralisé est un gros plus. Je citerais les 3 premières qui me viennent à l'esprit :
- Mandriva, avec son drakeconf
- PCLinuxOS (basé sur Mandriva) et de plus en plus populaire
- openSUSE avec YaST
[^] # Re: Arg
Posté par Spyhawk . En réponse au journal Launchpad, enfin Libre ?. Évalué à 3.
Moi je sais, alors je réponds :)
Tous les developpements et toute l'infrastructure d'openSUSE est libre (GPL) et disponible, tout le developpement est ouvert et accessible (mailing lists des dev, svn, etc.). Pour le côté SUSE Entreprise, seuls les correctifs (rpms binaires et sources) des correctifs ne sont pas disponible publiquement (au contraire de RH qui fournit les sources rpm).
A noter, un exemple, qui ressemble _extrement_ au cas de Lauchpad de Canonical, est le Build Service d'openSUSE.
Le Build Service à pour vocation de créer, de façon centralisée et simplifiée, des paquets RPM/DEB pour plusieurs distribution à partir du même code source (un seul fichier .spec). Il permet de lier des projets entre eux et d'augmenter l'interaction et le dynamisme des projets, pas forcément lié à la distribution openSUSE.
Très récemment, une nouvelle fonction de distribution p2p est apparue (soit, exactement ce que Canonical veut/est en train d'implémenter) est disponible. On peut ainsi installer une version locale du Build Service et faire la synchronisation vers un autre Build Service.
Dès le départ, les sources (en rpm/tar.gz) du Build Service étaient disponibles.
Que Mark Shuttleworth prétende que Lauchpad est closed source pour le bien des projets est du foutage de gueule royal. Je pense que ce n'est que par la pression des "Libristes" (entre autres ceux de GoButuntu et GNewSense) que Shuttleworth va ouvrir les sources (bientôt? ça fait 2 ans qu'il nous sort la même salade), et que Launchpad a été pensé à la base comme pièce maitresse de la stratégie de Canonical pour se rendre indispensable.
[^] # Re: Le troll a bien bouffé...
Posté par Spyhawk . En réponse au journal Cher IzNotGood.... Évalué à 7.
[^] # Re: Un seul mot:
Posté par Spyhawk . En réponse au journal Die Hard : une journée en enfer. Évalué à 5.
Non, ça fait un moment qu'il n'utilise plus Mandriva (rappelle toi du journal "les cents jours"). Il utilise debian sid, si mes suppositions sont bonnes.
[^] # Re: et ?
Posté par Spyhawk . En réponse au journal Pas de desktop pour les masses chez Red Hat. Évalué à 3.
[^] # Re: Parce que...
Posté par Spyhawk . En réponse au journal ubuntu ?== linux ?== gnome. Évalué à 1.
L'ordinateur est un instrument d'acquisition de culture et de connaissance. Refuser d'apprendre comment utiliser l'informatique, c'est comme refuser d'apprendre à lire, et c'est laisser à d'autre la connaissance.
[^] # Re: :(
Posté par Spyhawk . En réponse à la dépêche Sortie de la Mandriva Linux 2008.1 Spring. Évalué à 2.
Ben si, justement :)
[^] # Re: Emacs et bzr
Posté par Spyhawk . En réponse à la dépêche Nouvelle version de Bazaar, le DVCS de Canonical. Évalué à 2.
[^] # Re: Et le contenu ?
Posté par Spyhawk . En réponse au journal Introduction [propriétaire] à l'open source et au logiciel libre. Évalué à 0.
# Il a raison..
Posté par Spyhawk . En réponse au journal vente liée: discussion. Évalué à -5.
Aussi, il est possible d'acheter un pc sans vista (il a raison), mais pas chez casino. Le vendeur a (surement) raison.
Après, oui, c'est de la vente liée, pour la raison que Carrefour ne propose pas un autre choix /pas d'os du tout dans son offre. Mais tu ne peux pas demander à acheter un pc pour y mettre ta licence attribuée à ton portable.
[^] # Re: Re:
Posté par Spyhawk . En réponse au journal Diverses choses sur les packages managers. Évalué à 1.
Outre par AMD, openSUSE est sponsorisé par IP Exchange Germany, qui procure toute l'infrastructure réseau (bande passante, gros débits). Je ne sais pas dans quelle proportion, mais c'est surement un facteur décisif pour la bonne marche de l'oBS.
[^] # Re: Re:
Posté par Spyhawk . En réponse au journal Diverses choses sur les packages managers. Évalué à 1.
Et effectivement, ça pose le problème de la bande passante.
Je ne sais pas comment font les miroirs qui relaient la Factory (comme indiqués, tous les mirroirs openSUSE n'ont pas le même contenu), mais pour les utilisateurs/testeurs Factory, c'est 1 à 3 Go (ou plus) de mise à jour par ~semaine.
Pour ce qui est des dépendances cycliques, j'en sais fichtrement rien (moi et la compile de paquets... comme tu l'as vu ceux que je propose sont de mauvaises qualité, mais c'etait juste un test pour me faire la main :) )
[^] # Re: Fedora
Posté par Spyhawk . En réponse au journal Diverses choses sur les packages managers. Évalué à 1.
Par contre, et suite aux commentaire ci-dessus, je note qu'il y a quand même une petite différence.
L'OCI d'openSUSE est conçu plus comme une couche d'abstraction : les liens OCI ne pointent pas directment vers le fichier RPM/deb en question, mais sur un fichier XML. Ce fichier XML peut décrire, au choix :
- l'installation d'un dépôt
- l'installation d'un paquet (et résolution dépendance), indépendamment de sa version
- l'installation d'un groupe de paquets d'un dépot
- l'installation d'un groupe de paquets situés sur plusieurs dépôts (pratique pour installer en quelques clics tous les fichiers nécessaires au "débridage" d'openSUSE via les repo Packman et VideoLan, par exemple)
- etc, etc. On peut imaginer toute sorte de combinaison plus ou moins utile selon la situation.
Chaque lien fichier XML peut en outre être muni d'option, tel que de garder ou non le dépot après installation des fichiers, une section "avancée" qui permet de sélectionner individuellement certains paquets d'un groupe de paquets par défaut, ...
Mais c'est surtout sa mise en avant, son utilisation par défaut et toute l'adaptation de l'infrastructure autour (wiki / moteur de recherche officiels et communautaires) qui ajoute cette plue value à la distribution.
Et je pense que toute les distributions auraient a gagner en utilisant "plus" (ou de façon native pour .deb) ce système qui n'est "pas une nouveauté" (enfin, Fedora ne semble pas intéressé par ce système "à la kéké", malgré qu'il est fonctionnel depuis des lustres :) )
@GeneralZod > Je ne pense pas que cette méthode "à la windows" déclencherait un retour au "dependancy hell", tant que l'environnement autour de la distribution est adaptée : les moteurs de recherche de paquets par défaut indiquent clairement le dépôt utilisé. C'est aussi plus facile quand la majorité de l'infrastructure est centralisée (oBS) et qu'il n'y a pas x dépôts disparates (websphere openSUSE plutôt limitée comparée à d'autres distributions).
Par contre, il est clair que mélanger des dépôts 10.3 avec des dépôts Factory ça risque de faire mal...
[^] # Re: Re:
Posté par Spyhawk . En réponse au journal Diverses choses sur les packages managers. Évalué à 3.
>Et pourquoi pas des milliers !
>Pour Fedora (compilation i386, x86_64, ppc et ppc64), il n'y a "que" dix machines (certaines virtuelles) :
>http://koji.fedoraproject.org/koji/hosts
>Et tout y est compilé, ce n'est pas que dédié "extras". La distribution y est compilé, les mises à jours, les contributions externes, rawhide, etc.
Tu as raison, je suis allé un peu vite. De mémoire, il me semblait avoir lu quelque part le nombre de 126 machines (irc ?). Je n'ai pas réussi à retrouver une source pour ce nombre.
Cependant, sur le blog d'un développeur KDE employé par SuSE/Novell [1], j'ai trouvé le nombre de "plus de 120 CPUs" qui me laisse penser que ma mémoire était bonne,
Alors effectivement, ce n'est pas plus de 120 machines (du moins je pense, je n'ai aucune idée du nombre de CPU par machine, et encore moins du nombre de core par CPU...).
Ma seconde erreurs est d'avoir écrit tacitement que ces machines ont toutes été données par AMD. C'est bien sûr l'ensemble des machines (don AMD + le parc existant) qui représente ces 120+ CPUs.
>> Le Build Service a de multiples avantages :
>> - Il resoud automatiquement les dépendances des paquets compilés.
>Ce n'est pas un avantage, c'est une nécessité.
>> Ainsi, si un paquet B dépend d'un autre paquet A, le paquet B va être automatiquement recompilé si la dépendance A est modifiée et recompilée.
>"Foutaise".
>Presque tous les paquets dépendent de libc ou gcc. Si libc ou gcc est changé, tu nous expliques que le build système va recompiler tous les paquets !
>Et comment tu fais pour gérer les versions ? Ben oui, il va y avoir des toto-1.0-1 avec différent libc et gcc. Ça sucks.
>Bref, ce truc je n'y crois pas.
C'est pourtant ce qu'il se passe. Heureusement, la libc et gcc ne changent pas trop pour une version stable, mais il en est autrement pour les builds Factory (la version de dev opensuse).
Prenons un exemple : Je choisis totalement arbitrairement le dépôt personnel d'un utilisateur lambda : http://download.opensuse.org/repositories/home:/Spyhawk/.
Cet utilisateur lambda a compilé quelques paquets pour une version stable (10.3) et la version Factory. Je sais, de source sûre, que cet utilisateur a compilé ces paquets dans le mois d'octobre 2007 et n'y a pas touché depuis.
Les paquets du répertoire 10.3 sont datés d'octobre 2007. En revanche, les paquets Factory sont datés de deux jours (samedi 8 mars 2008 vers 07h55 - mes sources indiques que l'utilisateur lambda cité dormait encore), soit grosso modo la date de la dernière recompilation de la Factory. Et c'est comme ça pour tous les builds Factory.
Aussi, la Factory est recompilée (quasi) entièrement une à deux fois par semaine (à chaque mise à jour, et pas seulement lors du changement de la libc ou gcc). Ca permet de s'assurer que tous les paquets fonctionneront (avec le désavantage e lancer une compile après l'autre.. ).
J'imagine que les paquets compilés pour une version stable sont recompilés lors d'une mise à jour de sécurité (un rapide coup d'oeil à la liste des maj de sécu me montre qu'il n'y a pas eu d'update de la libc / gcc de octobre à ce jour). Ou alors, peut être qu'une simple faille corrigée dans la libc/gcc ne fait pas perdre de son caractère compatible (?).
Enfin, il me semble qu'entre la ligne du "c'est une nécessité" et la suivante "Foutaise" qui parle du même sujet, il y a une subtilité qui m'échappe..
>Mais il me semble qu'un aspect est "négligé". >C'est la qualité, une vue d'ensemble. Fedora ne permet pas à tout le monde de compiler sur koji pour des raisons de qualité. >Un paquet est accèpté qu'après un audit sérieux du paquet (licence, état de l'art, es-ce une technologie obsolète ou pas, etc).
>Ça s'inscrit dans un projet qui a des objectifs. Ça fédère dans gens autour de ces objectifs. Ce n'est pas une libre service. >C'est un mal et c'est un bien. Limiter les fonctionnalités (par exemple ne pas permettre à tout le monde de compiler) n'est pas forcément un mal.
Effectivement, je n'ai pas trop parlé de cet aspect "qualité". Après un rapide aperçu du BS, je voulais surtout mettre le doigt sur la possibilité de compiler des paquets autres qu'openSUSE (ce qui est surement plus intéressants pour la majorité des leceturs linuxfr), et surtout que la démarche entreprise par Fedora est la même pour les toutes autres distributions j'imagine.
Pour openSUSE, la seule différence est que les paquets "grands publics" (/repositories/home:/user) sont déjà dispo. Mais ils doivent bien sûr être approuvés avant d'entrer dans les dépôts semi-officiels contenus dans /repositories/projet (ex:KDE:/Backport) ou communautaires (ex: KDE:/Community).
Pour ceux que ça intéresse, cette présentation[2] fournit un schéma montrant bien le processus (slide 17). Le reste du PDF aborde les principes généraux du BS et quelques limites du BS dont je n'ai pas parlés. Egalement, le wiki openSUSE est assez exhaustif.
Pour smart, c'est justement le comportement que tu décris que je citais comme "efficacité agressive", mais je reprendrais ça ce week end (si j'ai le temps..)
[1] http://www.kdedevelopers.org/node/2850
[2] http://bw.uwcs.co.uk/talks/OBSTalk_WUGLUG.pdf
[^] # Re: openSuse vs debian
Posté par Spyhawk . En réponse au journal Diverses choses sur les packages managers. Évalué à 6.
Mais rien que l'arbre FTP d'une seule version openSUSE et pour une architecture doit tourner autour des 15 à 20 Go si mes souvenirs sont bons.
Le BuildService (/repositories) contient des mises à jours semi-officielles pour plein de composants (KDE3 et 4, GNOME, Xorg, drivers, etc.) mais surtout, la grosse partie du contenu est faite des builds personnels des utilisateurs (/repositories/home:). Des paquets peuvent donc y être sous différentes formes et versions (genre un blender 2.43, 2.44, avec tel ou tel patch, etc.)
En ce qui concerne le nombre de package, je sais qu'avant l'ère Novell la distribution entière tenait sur un DVD double (pour une arch). Depuis, le nombre de paquets a complètement explosé. Selon la mailing-list de septembre 07 [1], le nombre de paquets sources était de ~3500+ dans le Build service (sans compter le /repositories/home:), et ~2500+ dans le repo communautaire packman (pour ~14'000 binaires)
Sinon, je crois que Gentoo est passé devant debian depuis un moment en terme de nombre de paquets différents absolu.
Et non, il n'y a pas de patrick_g dans ma famille. La preuve est qu'il y a un gros gène de monstrueuses fautes d'ortho dans la mienne...
[1] http://lists.opensuse.org/opensuse-project/2007-09/msg00074.(...)
[^] # Re: Ce journal...
Posté par Spyhawk . En réponse au journal Diverses choses sur les packages managers. Évalué à 10.
Cette petite exploration présente avant tout mon point de vue, avec un biais sur les techniques employés par la distribution que j'utilise. Je n'ai pas le recul nécessaire ou une connaissance suffisante des autres distributions, bref, pas vraiment d'objectivité. Et comme précisé dans l'entête, les lecteurs me corrigeront.
Par contre, je n'avais pas assez de XP pour le placer en journal de première page...
[^] # Re: Pas vraiment
Posté par Spyhawk . En réponse au journal novell commence a voir les effets de vendre son ame. Évalué à 3.