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 benoar . Évalué à 0.
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.
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 jiyuu . Évalué à 0.
[^] # Re: Changement d'approche ?
Posté par benoar . Évalué à 3.
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 _PhiX_ . Évalué à 1.
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 benoar . Évalué à 1.
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 Albert_ . Évalué à 2.
# Merci
Posté par bubar🦥 (site web personnel) . Évalué à 3.
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 _PhiX_ . Évalué à 2.
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 _PhiX_ . Évalué à 2.
Oui tu as raison. Du coup, j'ai proposé une dépêche.
# Python et Init
Posté par monde_de_merde . Évalué à 3.
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 Earered . Évalué à 4.
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 monde_de_merde . Évalué à 3.
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 hvannentir . Évalué à 1.
Ç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.