Journal Sortie de Pardus Linux 2009.1

Posté par  .
Étiquettes :
8
18
jan.
2010
Pardus Linux est une distribution basée sur KDE4, Python et Qt, incluant tous les codecs multimédia, Flash, Java, DVD de manière à être immédiatement opérationnelle pour l'utilisateur de base, qui représente sa cible privilégiée.

UNIQUE

Développée sur fonds publics (turcs) par l’Institut de Recherche en Électronique et Cryptologie du Conseil de Recherche Scientifique et Technologique (TUBITAK/UEKAE) dans un but d'indépendance technologique nationale.
Les développeurs sont partis d'une feuille blanche et ont créé une distribution moderne et novatrice. Ils ont écrit un gestionnaire d'initialisation (Mùdur), un gestionnaire de paquets (PiSi), un gestionnaire de configuration (ÇOMAR), de nombreux assistants graphiques destinés à faciliter la vie de l'utilisateur.
La plupart de ces outils sont écrits en python afin de rendre l’ensemble du système cohérent et élégant.
Tous les développements sont placés sous licence GPL.

ORIGINALE

ZORG

Zorg représente un ensemble de scripts python et de modules permettant la configuration automatique du serveur graphique X.org.

COMAR

ÇOMAR, qui signifie "Configuration MAnageR", est, comme son nom l’indique, le gestionnaire de configuration de Pardus. Il est écrit en C et propose une API en python. Il fournit, sous forme de scripts Python intégrés aux paquets, l’ensemble des services de configuration du système (réseau, utilisateurs, affichage, etc.).
Ces services sont connectés, grâce à D-Bus, à des clients graphiques écrits en langage Qt. Ces clients graphiques sont les gestionnaires graphiques de l'ancien centre de contrôle Tasma de Pardus 2008 qui sont intégrés au centre de contrôle de KDE 4 dans Pardus 2009.
ÇOMAR n’est donc pas directement visible par l’utilisateur. Il travaille dans l’ombre pour l’utilisateur, et propose au développeur une interface de configuration du système de bas-niveau, unifiée et cohérente, pour créer de nouveaux assistants graphiques en Python et Qt.

PolicyKit est également intégré à ÇOMAR ce qui permet une gestion des droits utilisateurs simplifiée dans les clients graphiques. Lancer et arrêter des services ou bien mettre à jour son système en deux clics sont enfin possible sans avoir à taper à chaque fois son mot de passe utilisateur.

MUDUR

Mùdur, qui signifie "directeur" en turc, est la réécriture en langage Python du système Init d’initialisation au démarrage de Linux. Mùdur fait partie du système ÇOMAR.
Mùdur gère le montage des systèmes de fichier, le chargement des pilotes de périphériques, le démarrage des services système et d’autres tâches pendant les séquences de démarrage et d’arrêt de Pardus.
Le script /sbin/mudur.py est lancé par /sbin/init (cf. /etc/inittab) pendant les changements de niveau de fonctionnement (les runlevels 1, puis 2, 3, 4, 5), et prend en charge le démarrage et l’arrêt des tâches.
Au démarrage, mudur.py appelle un autre script, /sbin/muavin.py, qui détecte le matériel présent au démarrage et charge les éventuels pilotes nécessaires dans le noyau (coldplug). Lors des branchements "à chaud" de périphériques, Muavin4 est appelé par udev. Il s’occupe de charger modules et firmwares.

PISI

PiSi, qui signifie " Packages Installed Successfully, as Intended" est le gestionnaire de paquets. Il est implémenté en python et conçu comme un framework afin qu’il soit facile de l’utiliser pour en réaliser des clients. Deux clients existent actuellement, pisi, en ligne de commande, simple, pratique et puissant et Package Manager, le client graphique.
Les paquets sources PiSi sont décrits en XML et la partie compilation utilise une API en python qui simplifie grandement la création et la maintenance des paquets PiSi.
PiSi gère les paquets de type .delta. Ainsi, lorsqu’une nouvelle version d’un logiciel / bibliothèque est disponible, les paquets delta ne contiennent que ce qui a changé depuis la dernière version installée, réduisant ainsi la taille des mises à jour de l’ordre 40 à 98%.
L’architecture de PiSi se différencie nettement de celles des systèmes de gestion de paquets de Debian (.deb) et Redhat (.rpm) et de leurs distributions dérivées (Ubuntu, Mandriva, etc.). Ces distributions font en effet appel à de multiples outils annexes pour la résolution des dépendances entre paquets, la construction, le téléchargement, la validation, l’installation, la gestion des dépôts, alors que toutes ces fonctionnalités sont codées de manière intégrée dans PiSi et que les scripts shell sont remplacés par l’appel à des fonctions python disponibles dans une API cohérente, maintenable et évolutive.
Une autre différence vient du profit qui est tiré de l’existence du système ÇOMAR : la configuration des paquets logiciels est strictement séparée du système de gestion des paquets. Ainsi, le système de configuration des paquets ne se limite pas à des scripts de pré-suppression ou de de post-installation ; c’est un système plus perfectionné qui permet un mode de configuration intégré de l’ensemble des paquets installés par le recours à l’unique API de ÇOMAR. Dans ce système, un paquet peut fournir un script de configuration de service et s’en servir d’interface de configuration pour lui-même. Un autre bénéfice est que la configuration des paquets peut se faire aussi bien à distance que localement.

En résumé :

- Écrit en Python de manière efficace et concise
- Paquets sources écrits en XML et Python, compressés par LZMA
- Accès rapide à la base de données des paquets grâce à Berkeley DB
- Intègre les opérations de gestion de paquets de bas et de haut niveau (résolution des dépendances)
- Approche orientée framework pour construire les applications et les outils
- Interface en ligne de commande simple et interface graphique intuitive en Qt (distribuées séparément)
- Construction de paquets extrêmement simple et rapide

ASPECT VISUEL

Un thème original soigné et plaisant, un jeu complet d'icônes (Milky), des fonds d'écrans.

DES ASSISTANTS ERGONOMIQUES INTÉGRÉS À KDE
  • YALI - installateur graphique simple à utiliser
  • Kaptan - assistant de configuratin du bureau et de la connexion à Internet en quelques clics.
  • Package Manager - gestionnaire de paquets
  • Network Manager - configuration des connexions réseaux
  • Firewall Manager - paramétrage du pare-feu
  • User Manager - configuration des utilisateurs
  • Display Settings - configuration de la carte graphique
  • Disk Manager - configuration des partitions
  • Service Manager - gestionnaire de service
  • History Manager - permet de défaire les opérations sur les paquets (installations, suppressions, mises à jour) et de revenir en arrière en cas de problème.
  • Boot Manager - configuration de GRUB
  • System Manager - configuration globale

Pardus 2009.1 est disponible en version installable ou live. Une même image ISO de Pardus a la faculté d'être gravée sur tout support (CD, DVD, clef USB).

Site officiel
Site francophone
  • # Changement d'approche ?

    Posté par  . Évalué à 0.

    C'est bizarre, je n'avais pas vu avant que cette distribution était centrée sur le "incluant du proprio" et "immédiatement opérationnelle". Est-ce que ça a changé, ou ça a toujours été comme ça ? Ou alors c'est ton interprétation ? Moi je la voyais comme une distro originale avec du Python partout.

    Enfin bon, j'espère que tout ces trucs proprios ne sont pas inclus dans le CD/DVD de base ...
    • [^] # Re: Changement d'approche ?

      Posté par  . Évalué à 4.

      > "incluant du proprio"

      Tu penses à quoi? flash? c'est pas énorme, et de toute manière installé par tout utilisateur de Linux non-geek.

      Java, les codecs multimédia et DVD sont par contre des logiciels libres soumis à brevets aux USA. Leur inclusion veut juste dire qu'en Turquie les brevets ne s'appliquent apparemment pas.

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

      • [^] # Re: Changement d'approche ?

        Posté par  . Évalué à 0.

        Il se peut qu'il y est les pilotes nvidia / ati aussi.
      • [^] # Re: Changement d'approche ?

        Posté par  . Évalué à 3.

        Oui, à Flash, et à la base les codecs aussi, mais je me suis mélangé les pinceaux, c'est effectivement plutôt une histoire de brevets. Ce qui est plutôt bien pour une distribution faite dans un pays qui ne les reconnaît (apparemment) pas !

        Par contre, pour flash, je te ferais remarquer la "petite" contradiction entre "pas énorme" et "installé par tout utilisateur" : c'est effectivement petit en taille, mais en influence et pouvoir sur les gens, c'est tellement énorme que c'est aujourd'hui à peu près indispensable pour naviguer sur le net, et que toute personne le refusant passe pour un extra-terrestre. Donc, personnellement, je n'appellerait pas Flash un truc "tout petit" ; il a même été désigné par la FSF comme le plus gros "manque" du libre ...
    • [^] # Re: Changement d'approche ?

      Posté par  . Évalué à 1.

      C'est bizarre, je n'avais pas vu avant que cette distribution était centrée sur le "incluant du proprio" et "immédiatement opérationnelle". Est-ce que ça a changé, ou ça a toujours été comme ça ? Ou alors c'est ton interprétation ?

      C'est mon interprétation personnelle et ça a toujours été comme ça !

      J'ai oublié de mentionner les pilotes propriétaires ATI et NVidia. Tout est inclus de base dans le CD, il n'y a rien à rajouter pour couvrir les besoins courants de l'utilisateur lambda.
      • [^] # Re: Changement d'approche ?

        Posté par  . Évalué à 1.

        J'ai oublié de mentionner les pilotes propriétaires ATI et NVidia. Tout est inclus de base dans le CD

        Aïe. Si j'ai cité ça, c'est que ça viole la GPL. Et sûrement les conditions de distribution d'Adobe, NVidia et ATI (à moins qu'ils aient eu l'autorisation ...). Bref, légalement parlant c'est très bof.
        • [^] # Re: Changement d'approche ?

          Posté par  . Évalué à 2.

          ca va etre rigolo de voir Adobe et cie attaque en justice en turquie un projet turc dont l'armee se sert. Enfin j'aimerai bien voir ca...
  • # Merci

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

    Merci pour cette dépêche ce journal (pourquoi pas une dépêche ? c'est une version majeure!).

    Je ne suis pas sûr de comprendre l'interaction logique entre Mudur et Comar, ce qui a mené à avoir deux choses distinctes, alors que toutes deux s'occupent de configuration. Mudur se 'contente' d'exécuter, de lancer ; tandisque que Comar écrit et modifie. Est ce un bon résumé ? Si non qu'est ce que j'ai loupé qui a mené à la séparation des deux ? S'occuper de init justifie la présence séparé de Muder par exemple ? Merci.

    Autre question : Remarque importante : Les utilisateurs de la version 2009 de la distribution passeront automatiquement à Pardus 2009.1 lorsqu’ils mettront à jour leur système.
    comment cela se passe t il ? Le système pointe vers un nouveau dépôt ? Ou bien le système télécharge un 'live-comar+pisi' minimum, boot dessus, et effectue une installation plus classique, en préservant certains fichiers de configs et les $home
    ? Merci.
    • [^] # Re: Merci

      Posté par  . Évalué à 2.

      Mudur (petit script python) ne s'occupe que de l'initialisation du système. Il est lancé au démarrage et puis "s'arrête". Comar (en C) tourne en tâche de fond pendant toute la session de l'utilisateur. Les fonctions de MUDUR et COMAR sont différentes, les phases de travail sont différentes et les langages de programmation utilisés sont différents. Ça fait beaucoup de raisons pour en faire des programmes séparés. Pour avoir une réponse plus précise, il faudrait demander aux développeurs (ils répondent volontiers aux mails des curieux).

      En ce qui concerne la mise à jour de Pardus 2009 vers Pardus 2009.1, les dépôts restent ceux de 2009. La transition de millésime se fait donc insensiblement par simple mise à jour. Les fichiers de configuration et les répertoires personnels ne sont pas modifiés par l'opération.
    • [^] # Re: Merci

      Posté par  . Évalué à 2.

      Merci pour cette dépêche ce journal (pourquoi pas une dépêche ? c'est une version majeure!).

      Oui tu as raison. Du coup, j'ai proposé une dépêche.
  • # Python et Init

    Posté par  . Évalué à 3.

    Dans la mesure où c'est une distribution ton la cible est l'utilisateur non avertis (et donc la performance j'imagine), je trouve étrange le choix de python pour ré-écrire Init.

    Alors certes c'est juste le programme qui lance les différentes phases et démarre les processus, mais cela implique qu'il faille charger l'interpréteur python au démarrage (et avec des "import" un peu lourds ça peut ne pas être bien bien rapide).

    Quelqu'un a des infos la dessus ? Le site est bloqué au boulot (oui je sais c'est étrange mais j'ai cessé de comprendre la politique de filtrage local où les gens qui la mette au point).

    Disclaimer : ce n'est pas une critique de python, je travail avec et je suis convaincu de son intérêt mais le retrouvé à cet endroit m'interpelle.
    • [^] # Re: Python et Init

      Posté par  . Évalué à 4.

      Sur le site, ils expliquent que les goulots dans init ne concernent pas le proc, mais plutôt les I/O, et que donner des boulots d'écriture en parallèle, permet d'optimiser pas mal (éviter les aller-retour sur le disque).

      De plus, l'init dépend de pas mal outils externes (sed, awk, perl), juste python avec peu de module, ça n'est pas si mal

      Le gros problème, est que les script des services sont à ré-écrire (pas gênant pour eux, mais ça limite l'adoption)

      L'URL (peut être accessible malgré le filtre avec google/coral cache ou archive.org ?)

      http://www.pardus.org.tr/eng/projects/comar/SpeedingUpLinuxW(...)
      • [^] # Re: Python et Init

        Posté par  . Évalué à 3.

        En fait mon inquiétude provient surtout de la nécessité de charger l'interpréteur et les bibliothèques nécessaires.

        Bon d'après eux ça va vite :

        A simple boot test with init=/usr/bin/python showed that loading of Python core and built-in modules takes 1.5-2 seconds. From then on, only a few system tools (mount, udev, fsck, modprobe, etc), and actual services (kdm, ssh, apache, etc) are loaded. This is quite acceptable if you consider total time and disc IO saved. Having Python cached in the memory also helps speeding up our other programs.

        Mais il semblerai qu'ils aient fait, comme l'ont peut s'y attendre, des optimisations.

        Merci pour le lien :)
        • [^] # Re: Python et Init

          Posté par  . Évalué à 1.

          Fut une époque ou j'aurais installé cette distrib pour tester tout ça.
          Ça a l'air d'un projet vraiment propre et cohérent.

          Mais Arch est passée par là et maintenant j'ai un peu de mal avec les distrib "lambda friendly".

Suivre le flux des commentaires

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