steckdenis a écrit 327 commentaires

Debian configure son noyau pour un serveur, c'est à dire en retirant la préemptabilité (donc les applications ne passent la main que quand elles le veulent, ou si vraiment trop de temps passe). Ça permet d'avoir des performances magnifiques sur un serveur, mais sur un desktop, dès qu'une appli utilise un peu de processeur (au démarrage par exemple), toutes les autres attendent. Ca produit l'effet du «démarrage en parallèle qui n'est pas parallèle» que je décris, les services s'attendant mutuellement.

L'horloge est réglée sur 100hz avec Debian, alors que la mienne est réglée sur 300hz. Cela permet également une meilleure réactivité. Ce sont à peu près les seuls changements que j'ai fait (j'ai fait un make xconfig, puis j'ai lu les petits messages de chaque option du premier groupe, puis j'ai sauté le reste parce que j'en avais marre).

Quand le noyau rentrera dans Debian, il sera normalement plus rapide que le 2.6.30, mais toujours orienté serveur. Il faudrait voir si Debian ne propose pas des variantes (il me semble que Ubuntu le fait avec ses noyaux -server, -rt et -desktop).

La recompilation est franchement rapide et simple (make bzImage && make modules && make modules_install && cp arch/x86/boot/bzImage /boot/linux-image-2.6.31.2), c'est juste la configuration qui nécessite d'être un peu attentif.

Quand j'aurai un peu de temps, je compte voir s'il est possible de créer une belle GUI de compilation du noyau pour KDE (gnark !) : cocher les grosses options (serveur/desktop, rapidité/robustesse par exemple), puis la GUI détecte les modules chargés (parse de lsmod), ainsi qu'éventuellement ceux qui sont compilés en dur (on fait comment ?), puis un kernel est téléchargé, configurer avec tout en N, puis en O tout ce qui est utilisé sur le système. Démarrage foudroyant, kernel léger et optimisé, etc :-) .

Bonjour,

Je n'ai malheureusement pas la chance d'avoir deux écrans, mais j'ai entendu tellement de bien de la gestion multi-écran de KDE (un bureau sur chaque écran, un dock différent, des plasmoides différents, plein de modes différents, etc) que j'aimerais bien que quelqu'un teste pour moi.

La gestion des écrans de KDE se trouve dans K»Configuration du système»Affichage. Les écrans apparaissent normalement dans un arbre. Dans la barre de gauche, il y a une icône «Moniteurs multiples», qui devrait permettre de facilement tout régler.

Merci à celui qui pourra tester :-) .

Normalement, le flush n'est pas nécessaire, car Btrfs gère également le cache des fichiers, donc s'il est correctement codé, il met dans le snapshot le contenu du cache (donc il faut un flush global, comme si la commande sync était appelée juste avant toute opération sur les snapshots)

Pas mal du tout.

Mais ce dont moi je parle, c'est aussi une intégration avec KDE. Mais sinon, vraiment pas mal. J'aime bien l'interface (qui occupe un peu trop de place à l'écran à mon gout).

Je sens que ça va finir par une libatomicalfilesystem dans Logram, pour pouvoir utiliser ce genre de fonctionnalités avec Btrfs, ZFS et autres systèmes de fichiers le supportant.

Merci beaucoup pour le lien, et mes félicitations aux développeurs.

Ben justement. C'est pourtant simple :

D'un côté Qt est générique et bien portable. Les devs de KDE avaient besoin de leur propre boîte de dialogue, donc ils la mettent dans les kdelibs (ils n'ont pas accès à Qt). Qt est donc propre et intégrable dans GNOME.

Du côté de GNOME, imaginons qu'ils aient également besoin d'une boîte de dialogue. Pourquoi la mettre dans libgnome alors qu'ils ont GTK à leur disposition ? Ben allons-y, mettons le tout dans GTK.

On a donc Qt qui est bien indépendant de KDE, et GTK qui contient, comme je l'avais dit, de petit bouts de GNOME qu'ils ajoutent quand ils en ont besoin. Le bug de la boîte d'ouverture vient sans doutes d'un de ces morceaux de GNOME, le fait que les applis GTK genre GIMP ne s'intègrent pas dans Windows aussi, etc.

Oui, c'est vrai, mais ça fait fuir les développeurs :

«Je veux coder pour KDE. Très bien, j'apprends/approfondis le C++, installe KDevelop, et j'y vais»

«Je veux coder pour GNOME. Le C en objet, j'aime pas, donc faut que je trouve autre chose [déjà ici 1/2 des devs sont partis]. Alors, nous avons Vala qui a l'air bien, mais c'est apprendre un autre langage. Nous avons le C++ qui semble pas mal non-plus, mais faut voir si ce binding n'est pas trop lent/pas à jour. Y'a aussi la solution Mono, mais je vais me faire flamer par les barbus. Y'a aussi le python, mais c'est lent et lourd si je compte développer une grosse appli. Y'a aussi le ruby, mais je connais pas. Dites docteur, je prend quoi ?»

Le choix, c'est bien (KDE propose aussi plein de bindings), mais trop de choix tue le choix, malheureusement. J'ai un jour voulu développer en graphique «pour Linux» (au tout début de ma découverte d'Ubuntu, donc ce que je dis en haut est basé sur des faits réels). J'ai donc tout naturellement installé «l'IDE de Linux», c'est à dire Anjuta. Et bien, comparé à Visual Studio, comment dire, c'est de la merde, désolé. Déjà on me propose à l'installation de choisir quel widget j'utilise pour la coloration syntaxique, j'ai gardé le choix par défaut. Ensuite, merci Ubuntu, pas moyen de compiler le programme de test (ben oui, il manque les bibliothèques -dev, que Ubuntu a omis de mettre en dépendances d'Anjuta).

Il y a quelques mois, j'ai voulu développer pour KDE, pour voir. J'installe «l'IDE de KDE», c'est à dire KDevelop, en version 4 parce que j'aime le bleeding edge. Faut savoir qu'il n'était même pas encore en bêta, mais déjà largement robuste ! Et là, pur bonheur. Nouveau projet, CMake, configuration (nom, parties de KDE qu'on utilise, etc). Un fichier d'exemple est créé, je clique sur la flèche pour lancer, ça se lance. J'ai une auto-complétion super efficace, qui m'affiche même la documentation Doxygen.

Je met le tout sur mon SVN, et v'là t-y pas qu'on peut même faire des SVN commit en graphique dans KDevelop ! Franchement, chapeau, j'en ai même fait une entrée de blog : http://www.logram-project.org/fr/node/297 .

Pour résumer, GNOME est plutôt une machine à attirer les utilisateurs (ça se voit à son site, un onglet rien que pour les releases notes bourrées de screenshots). KDE est plus pour les développeurs (dans le menu, on a des liens vers les mailing-lists, le wiki des développeurs, et seulement récemment un forum d'utilisateurs et un wiki d'utilisateurs).

C'est là que KDE a été plus intelligent.

Du côté de KDE, on a une base Qt, développé par des salariés (beaucoup) de Nokia, et donc au développement super rapide (y'a qu'à voir la 4.6 qui est vraiment superbe).

Du côté de GNOME, ils ont été intégrer GTK dans GNOME lui-même, donc ce sont les mêmes développeurs qui développent pour GNOME et GTK. Ça divise vraiment très fortement leur main d'oeuvre.

Si GNOME, au tout début, avait laissé GTK chez GIMP (là où il devrait être), on n'aurait pas de problèmes :

* Pas de morceaux de GNOME dans GTK, donc les applis GTK seraient comme les applis Qt : intégrables partout sans trop de problèmes
* Les devs de GNOME auraient le temps de tout bien développeur leur DE, au lieu de se concentrer sur leur toolkit
* GTK aurait été un projet bien à part, attirant plus de devs (par exemples ceux qui n'aiment pas un point du travail chez GNOME, etc)

Et puis, revient toujours la question du langage. Sur KDE, il ne doit pas y avoir plus de 30 développeurs "actifs" au sens «plusieurs commits par jour, tous les jours». Chez GNOME, je ne sais pas combien ils sont, mais un fait est là : développer une appli GTK prend vraiment plus de temps qu'une appli Qt. Il n'y à qu'à voir les "petites" applis GTK qu'on peut trouver, comme Cream, le navigateur web d'une connaissance. Ca fait des mois et des mois que son développeur travaille dessus, et fait RC sur RC pour peaufiner le tout. En Qt, ça aurait été bien plus rapide : http://www.siteduzero.com/tutoriel-3-11372-tp-znavigo-le-nav(...) .

Par contre, ce qui m'étonne, c'est que les distribs choisissent d'intégrer un DE certes très agréable à utiliser (et même moi je le dis, je préfère utiliser GNOME que KDE, et c'est dommage que GNOME soit si limité quand on pousse dans l'utilisation avancée), mais qui manque de développeurs, plutôt que KDE qui est vraiment un étendard du Libre, intégrant tout plein de bonnes choses, et qui est une machine à attirer les développeurs (voyez son site : http://www.kde.org , dès la page d'accueil on a un chemin pour participer, et la techbase[1] est vraiment bien faite. Il existe même des tutoriels pour développer pour KDE[2] !)

[1] : http://techbase.kde.org/Welcome_to_KDE_TechBase
[2] : http://techbase.kde.org/Development/Tutorials (d'ailleurs, je vous invite à suivre au moins les 4 premiers, qui vous permettent en, allez, 150 lignes, de faire un lecteur de tout type de document en utilisant les Kio)

Il me semble que ça a été trollé et re-trollé.

Le programme de gravure sous Linux, c'est cdrdao et mkisofs. Oui, K3B n'est qu'un frontend. Maintenant, KDE oblige, il est de très bonne qualité, ce qui permet presque d'oublier qu'il ne fait que lancer des commandes en arrière-plan quand on l'utilise.

Sous GNOME, je crois que c'est Brasero, qui utilise aussi cdrdao et mkisofs (et encore plein d'autres).

«Maintenant, au tour de GNOME de nous présenter ce qui va changer dans la version 3»

C'est la seule chose que j'ai dit sur GNOME, et toutes les réponses à mon message m'accusent d'être anti-GNOME, alors que dans tous mes trolls^W posts, je m'efforce toujours de ne pas descendre GNOME.

Ici, je dit simplement que des gens vont passer à KDE (et dans ma liste tout en haut, GNOME est en dernier, donc c'est que le minimum de gens vont passer de GNOME à KDE, et quand j'écrivais ça, je pensais à Linus Torvalds qui est passé à GNOME en attendant que KDE aille mieux).

Ensuite, je demande simplement ce que GNOME réserver pour GNOME 3, parce que deux applications (ok, elles sont bien), c'est pas suffisant pour une version majeure d'un DE. Oui, ils nettoient les API, mais on a quand-même le droit de demander si on a loupé quelque-chose ? non ?

Bref, j'aimerais que les GNOMEistes ne se sentent pas tout de suite agressés quand on parle de GNOME, alors que j'essaie justement de ne froisser personne.

KPackageKit marche, oui, mais comparé à ce qu'on a sous GNOME, c'est le jour et la nuit. Il n'y à qu'à voir ces screenshots : http://www.packagekit.org/pk-screenshots.html .

Et sinon, on n'a pas d'équivalent à Synaptic Package Manager (Adept n'étant plus maintenant, et KPackage ne marche pas vraiment bien). On n'a pas d'équivalent à gnome-app-install d'ailleurs.

En gros, tout ce qui est intégration au système, on n'a pas dans KDE (du fait que les distribs genre Fedora, Ubuntu et Debian sont plus ou moins orientées GNOME, donc elles développent leurs outils pour GNOME, pas KDE).

Et ça ne peut que s'agraver, car l'utilisateur ayant un bureau GNOME plus consistant le préférera à KDE, ce qui va encore renforcer le déséquilibre. Amis de GNOME, ne faites pas à KDE ce que Windows fait à Linux.

De la haine ?

Je n'ai pas dit qu'il est nul (ce qu'il n'est pas). Je n'ai pas dit qu'il se développe trop doucement (seulement qu'il avance moins vite, «dans le respect des utilisateurs»). Je n'ai pas dit qu'il devrait disparaître.

Non, la seule chose que j'ai pu dire, c'est que KDE avance vite, très vite, et GNOME moins. Je ne m'en plaint pas, GNOME est très bien comme il est.

Ensuite, je dénonce un fait (et pas GNOME en particulier), c'est à dire le marketing, le fait que pour beaucoup de devs qui découvrent le Libre, «Linux = GNOME, programmer pour Linux = programmer pour GNOME», et ça fait qu'on arrive avec des trucs comme PackageKit qui est inutilisable sous KDE parce que totalement orienté GNOME.

Ça c'est une très très bonne chose. Quand on voit tout ce qu'ils ont ajouté, on peut se dire que beaucoup de monde va passer à KDE 4.4 (en provenance de Windows, KDE 3 et GNOME).

Rien que l'édition de filtres dans KMail a l'air super pratique !

Maintenant, au tour de GNOME de nous présenter ce qui va changer dans la version 3, mais ça m'étonnerais qu'ils en fassent autant (par contre ils feront peut-être plus de marketing, accompagnés d'Ubuntu :-( ).

PS: J'ai installé le trunk de KDE, et je peux vous dire que KWin déchire vraiment dans cette version. Surtout que le nouveau Oxygen est vraiment bien mieux que l'autre. Screenshot : http://omploader.org/vMmZpYw . Pour ceux qui n'aiment pas, l'engine Arorae permet de facilement créer des thèmes avec des images .png, avec support de la transparence par pixel s'il vous plaît (donc vous pouvez faire des trous dans votre décoration).

Vive KDE !

C'est ce qu'utilise KDE, ça marche correctement, donc ça peut être une piste à explorer.

Une note : ces deux projets ne sont pas liés à KDE, même s'ils s'intègrent bien dedans. Il devrait être possible de trouver un client pour ces outils qui marche sous GNOME :-) .

Ah oui, c'est Strigi qui fait la recherche et l'indexation. Nepomuk est juste un truc pratique pour avoir un bureau sémantique, donc avoir plein d'informations en plus sur les documents.

Bonne chance dans tes recherches.

Moi je ne peux qu'applaudir une phrase comme celle-ci :

(un calcul qu'on peut retrouver dans un fichier au format Excel ou OpenOffice).

Les mots «Excel» et «OpenOffice» pointant vers des documents contenant les données. Le document OpenOffice s'ouvre impeccablement avec KOffice (composant KOffice intégré directos dans Konqueror pour ne pas devoir DL et ouvrir une fenêtre < /troll>), et est bien formé.

Félicitations pour l'ouverture, si seulement pouvait en faire autant :-) .

Ce n'est pas vraiment un troll. Simplement, pour une fois qu'on a un journal prêt à être incendié, qui me permet de dire tout ce que j'ai à dire, j'en profite :-° .

En plus, on ne sait jamais. Et s'il était sérieux ?

J'ai détecté quelques conflits douteux dans ce journal :

ca fait 10 ans que j ai installe cette os par rapport à linux ubuntu.

Clairement, quand on a 10 ans d'ancienneté, c'est pas Ubuntu qu'on va utiliser.

De plus, quand on lit une interface deplorable moche orange terre, c'est que t'as pas du tester autre-chose qu'Ubuntu (qui n'existe pas depuis 10 ans), et surtout pas KDE : http://kde.org/announcements/4.3/images/kde430-desktop.png .

des dependances manquante

Je te soufflerais bien Debian à l'oreille, et normalement, un Ubuntu correctement utilisé n'a pas ce problème. Si vraiment t'aimes pas ce qui est basé sur Debian, t'as Mandriva qui contient plein de paquets (OpenSuSE un peu mois, Fedora ça dépend des dépôts qu'on active, perso j'aime pas trop).

des programmes nul

GNOME, Gnome, gnome.... Bon, désolé pour le troll, c'était trop gros :-° .

des recherches interminables pour installer un programme

Ahahahahah, non, ça c'est Windows :D ! C'est là que tu dois passer ta vie sur Telechergez.com pour installer le moindre machin. Franchement, avec ton Ubuntu, t'as Applications»Ajouter/Supprimer qui te permet de parcourir un catalogue très complet. Si tu veux encore plus d'applis, Système»Administration»Gestionnaire de paquets Synaptic.

Si tu suis mon conseil et passe sous Mandriva avec un KDE, t'as un petit raccourcis dans la barre de lancement rapide : Centre de contrôle. Clic dessus, puis sur Gestion des paquets, puis sur Ajouter/Supprimer des paquets. T'as une très jolie interface à base de catalogue qui s'affiche.

un site linuxfr avec des integristes

Personne ne t'oblige à rester sur ce site. Quand on dit qu'on est Libre, c'est pas pour rien. MS va t'obliger à utiliser leurs sites Live pour bénéficier de leurs services, toi tu peux aller où tu veux ;-) .

des sujets sur ce meme site toujours les memes qui interesse trois personnes pour un pic nic dans un village

J'avoue, c'est parfois lamentable :-( . Des fois je me réjouis de voir 10 nouvelles dépêches sur la page d'accueil, mais on a 3 pique-niques, 2 recontres à Paris (300 km de chez moi), une histoire de brevets aux USA, etc. Heureusement, on a les magnifiques dépêches de patrick_g sur le noyau pour ceux qui aiment le technique, et les dépêches du style «Sortie de Ubuntu/Mandriva/Slackware/SuSE/OpenOffice/FireFox/autre» pour du plus généraliste.

Enfin, je répète mon premier point, rien ne te retiens.

j ai installer windows sous virtualbox pour respirer un peu et ca fait plaisir

Ca c'est un beau conflit d'idées aussi. VBox ralentit quand-même pas mal l'OS qu'on met dedans, surtout un Windows, donc respirer n'est pas le mot qui convient.

Ou alors tu parles graphiquement, en te débarrassant du orange. Enfin, là tu le remplaces par du noir flashy brillant avec des ombres format pâté, et du floux partout. Teste KDE, tu verras la différence (là c'est bien blanc, juste ce qu'il faut pour ne pas se péter les yeux).

Ah oui, un thème graphique, ça se change. Système»Configuration»Apparence, t'as une liste de thèmes, prends-en un bleu, a pu de orange :D !

on gagne pas d argent avec linux

Ca tu t'en fous, sauf si t'es un dev. Justement, ton nunux chéri est gratuit pour toi, et si tu veux payer les devs, tu peux. T'as un joli bouton «Donate» sur les sites, et 5€ font vraiment très plaisir. Y'a aussi des devs payés par des entreprises, et bien payés, genre ceux de chez Nokia qui travaillent sur Qt, ceux de chez RedHat/Novell, ceux de chez IBM, etc.

ca n interesse personne

Non ? 1,2 % de la population mondiale utilisant un ordi, c'est peu ? On est combien sur Linuxfr ? Ils sont combien sur Slashdot ? Ils sont combien sur le SdZ ? Combien y a-t-il de devs sur KDE, GNOME, le Kernel, etc.

Oui, sur des sites kikoolol du style Telechagrez.com et des forums de bas niveau, ils seront sur Windows, mais les sites un tout petit peu plus intelligents (et je ne dis pas par là libristes), un tout petit peu plus en rapport avec l'informatique, t'auras minimum 10% des gens sous Linux (source : http://www.siteduzero.com/news-62-31965-p1-les-statistiques-(...) ). Tu prends un site avec 100 000 membres, tu prends 10%, t'as 10 000 membres sous Linux, et généralement ce sont les plus actifs.

pas un seul de mes amis ont linux d installer

Hum, vu ce journal, et ce que tu dis après, tes amis ne doivent pas voler bien haut (désolé, plus fort que moi).

tous developpeur merite salaire de quoi vit il

Exactement ! Le Libre ne vole pas les développeurs hein. C'est eux qui décident de libérer leurs applis. Ca, c'est un énooorme FUD de MS que tu nous montre.

Le dev, il peut très bien travailler comme tout le monde de 9h à 17h dans son entreprise développant du logiciel proprio ou libre (ou autre chose, comme un service d'administration serveur, un développeur de sites web, ou même un truc en dehors de l'informatique). Il peut passer 1h par jour à coder que son logiciel avancera, et s'il arrête, son logiciel sera repris par quelqu'un d'autre, et continuera.

Bref, c'est le dev qui choisit, on n'impose rien.

itunes ne marche pas sous linux

Houra ! Non, franchement, c'est une bonne chose. T'as tout un tas d'applications qui te permettent de mettre de la musique sur ton iPod pas trop récent sous Linux, faut juste un tout petit peu chercher. Au final, t'as une appli intégrée à ton environnement, et pas un lourd machin à la iTunes qui te ramène un bout de Mac sous Windows, et qui est une gigantesque pub dont le but est de te faire acheter un Mac, et payer ta musique sur le iTunes Store. Si tu veux de la musique gratuite et légale, en faisant plaisir aux musiciens, t'as Jamendo :) .

les jeux sont nuls

http://playonlinux.com/fr/ . Voilà, tous les jeux (ou presque) de Windows tournent sous Linux. Ca utilise une couche de compatibilité, mais ça marche.

Sache que Urban Terror, Tremulous et bien d'autres tournent en natif sous Linux. Simplement, il y en a un peu moins. Et puis, t'es pas obligé de tuer des gens. T'as Wormux et Hedgewars qui sont très bien réalisés, et qui te permettent de bien t'amuser. T'as XMoto qui est pas mal non-plus.

T'as donc des jeux 3D à la mode en émulation, mais qui marchent (et bien), d'autres jeux 3D en natif, un petit peu moins à la mode, mais avec plein de bonnes choses, puis des jeux en 2D, extrêmement bien réalisés (genre http://teeworlds.com/ ), mais bon, si t'as besoin de ta dose de 3D pour faire ramer ton ordi, c'est pas mon problème.

des programmes de composition musicale bancale
des programmes de montage video aussi bancale

C'est vrai que Rosegarden, Ardur et Audiocity, c'est de la gnognotte :-° . Non, franchement, c'est pas un point faible de Linux ça.

Pour les progs de montage vidéo, oui, t'as pas Edius ou Adobe Première. Mais normalement, t'as pas besoin de programmes professionnels à +2000€. Un truc comme Cinerrela ou Kdenlive devrait vraiment largement suffire.

Evidemment, comme dit au début, si t'as toujours utilisé ce ***** de GNOME, tu crois que seul Kino existe ? Et bien non, ahahah, y'a plein d'autres choses.

photoshop

GIMP. Bon, ok, il manque certains trucs, mais si t'es pas un retoucheur professionnel, t'as pas besoin de plus (surtout que ton photoshop, tu vas le payer ou le pirater ?)

sonar

Là je connais pas, j'avoue

live

Moteur de propagante de MS, FUIS ! Si t'as vraiment besoin de MSN, Kopete fait ça très bien, je l'utilise depuis plusieurs mois, ça roule (y compris la webcam, les échanges de fichiers, les groupes de contacts, les listes, etc).

T'as besoin d'un blog ? Wordpress t'en propose, Blogspot aussi, c'est facile et rapide. T'as même dans KDE une petite application pour gérer ton blog directement depuis ton bureau (je dois retrouver son nom, c'est passé sur le planet de KDE).

moche pas fonctionnel

GNOME, Gnome, gnome... (désolé, comique de répétition Linuxfrien, on m'a obligé, pas taper)

amis linuxien aurevoir

C'est bien ce que je dis. Si t'as utilisé Linux depuis 10 ans, tu verra très vite les limitations de Windows, très vite (la pub sur Hotmail, les petits plantages qu'on ne résoud pas simplement en cherchant sur un forum, mais qui nécessitent de tout réinstaller, etc).

Bon essais de Windows :) .

Loading repository data... -> 1 sec
Reading installed packages... -> 1 sec
Computing distribution upgrade... -> 0.5 sec

Justement. On n'a pas l'air de vraiment se comprendre, et la faute est peut-être de mon côté, mais tu viens de me montrer ce que je dénonce.

Sur les 2,5 secondes, seulement 0.5 secondes sont effectivement utilisées pour du calcul. Le reste est, comme le dit «Loading repository data», la lecture de tous les paquets et la construction du problème (avec «Reading installed packages» qui applique des contraintes supplémentaires, ou qui complète le problème).

On a donc 0,5 secondes réellement utiles, et 2 secondes de perdues parce que le SAT nécessite de lire la base de donnée de tous les paquets de la distribution (et c'est de ça que je parle, ça n'a rien à voir avec le SAT justement, le SAT est rapide et léger, mais il nécessite, avant lui, un traitement lourd de construction du problème).

Avec Setup, les deux secondes ne sont pas perdues, et comme le problème est nettement plus court, ce ne sera pas 0,5 secondes, mais peut-être moins (quoique, le solveur SAT simplifie très fortement le problème en première passe pour éliminer les «-wormux | wormux-data» totalement inutiles si t'installes OOo).

Je n'ai pas répondu à ce message plus tôt car je n'avais pas encore implémenté le système de "fournitures" (provides).

Pour le moment, si B fournit Plop, ça crée un "paquet virtuel" Plop. En fait, comme paquet virtuel, c'est une simple entrée dans la table des chaînes de caractères (mais bon, c'est un détail technique).

Bref, C install D, et D supprime B. Actuellement, ça supprimera A (car avec les provides, des dépendances inverses sont crées, etc). Seulement, comme c'est un simple système de dépendances inverses, ce n'est pas répété dans le code, et je peux faire un truc plus complexe.

Prenons A qui dépend de B, C ou D. Je veux supprimer D. Nous crées donc 3 branches : une où on supprime D et A, une où on supprime D et installe C, une où on supprime D et installe B. C'est simple à faire, le format de la BDD le permet (j'aime ce format, il permet plein de choses).

Reprenons donc notre exemple : D supprime B. B va donc créer deux branches : une où il supprime A ... et une où il installe E ! Voilà, c'est fait, le problème est résolu, et en quelques lignes seulement (enfin de crois, j'ai pas encore codé).

Tous les traitements sont récursifs. Si je dis qu'on supprime C, ça veut dire qu'on supprime C, ses dépendances inverses, leurs dépendances inverses, etc jusqu'en haut de l'arbre des dépendances.

Pour le moment, mon solveur doit être assez proche de la complétude, car il ne quitte ses boucles récursives que très difficilement (pour le moment, seulement si un paquet dépend d'un autre qui n'existe pas, ou si on veut supprimer A après avoir dit qu'il faut installer A).

Par contre, ça risque d'être très lent, donc je cherche pour le moment des conditions d'arrêt supplémentaires gardant au maximum cette complétude, pour vraiment éviter d'avoir un problème solvable qui échoue.

Je suis actuellement en train de tester les cas ou A dépend de B, et C fourni également B (exemple de chez Archlinux : fluxbox-svn fournit fluxbox, qui est aussi un paquet). Ca me crée bien deux branches, avec les paquets qu'on va installer, mais je dois voir si c'est bien robuste avec les conflits, les dépendances inverses, etc.

~2.5 secondes pour +16'000 paquets

Justement. Est-il normal, pour par exemple mettre à jour Wormux, d'avoir à gérer 16000 paquets. Là, ça prend 2,5 secondes, ce qui est correct. Maintenant, si t'as 160 000 paquets, ça va prendre 25 secondes, et là ça fait mal, très mal (et 160 000 paquets, c'est une affaire d'années).

Il me semble qu'un problème SAT est une suite de clauses, comme ceci (format utilisé par MiniSAT en entrée) :

-1 2 3
3 4 -5
...

Construire une telle liste nécessite de lire tous les paquets de la base de donnée, c'est à dire un minimum un for() sur les paquets.

Pour chaque paquet, il faut lister ses dépendances (ce qui est rapide en binaire), etc. Au final, la construction du problème prend presque autant de temps que sa résolution.

Maintenant, je me trompe peut-être.

Pour le moment, oui, C est supprimé. Je compte mettre en place un mécanisme qui crée les branches suivantes :

* Une pour supprimer C (et ce qui en dépend)
* Une pour chaque paquet du même nom que B, mais avec une version différente, et qui peut être pris comme dépendance de C

Ainsi, si C dépend de B>=0.1, et qu'on supprime B=0.5, on pourrait ne pas supprimer C, mais installer B=0.6, qui ira peut-être dans le problème :) .

> Sinon, j'aime bien tes journaux/concepts, y'a de bonne idées mais je pense qu'un peu plus de modestie serait un plus concernant ta crédibilité.

Merci :) . Pour la modestie, c'est toujours un effet de bord. Quand je viens de terminer quelque-chose, et que j'ai passé plusieurs jours pour y arriver, je suis toujours très (trop ?) content.

Pour le solveur SAT, rien que le fait qu'on doive lire tous les paquets est lourds. Il y a peut-être moyen de l'éviter, mais le but est de construire un problème à base de clauses, une ou plusieurs clauses par paquets. Oui, ce sont des clauses simples (comme dit dans la page Zypp, ça doit faire quelques mois que je lis presque tous les jours ce wiki et la doc Doxygen de libzypp), mais il y en a beaucoup.

On peut avoir une BDD aussi optimisée qu'on veut, si on doit lire 40Mio sur le disque dur pour résoudre un problème, le disque dur ne va pas aimer. Chez moi, comme seuls les paquets entrant directement dans le problème sont lus, la BDD peut faire plusieurs Gio qu'il n'y aura pas de problèmes.

J'ai conçu mon gestionnaire de paquets avec dans la tête l'informatique qu'on aura dans 10 ou 20 ans : plus de logiciels propriétaires (ou très peu), énormément de logiciels libres, et un bon million de paquets dans les distros. Le moindre algo en O(nombre de paquets) est immédiatement écarté, car même s'il est rapide, faire 40 millions de tours de boucle, c'est trop.

Mes algos sont généralement en O(1) (pour les simples) ou en O(nombre d'éléments en jeu). Par exemple, pour trouver tous les paquets qui ont un nom (donc par exemple pour voir quels paquets correspondent à "libfoo>=0.4.88"), je prend la structure _String de libfoo, et cette structure a un pointeur vers des _StrPackage. Je les explore, et j'obtiens la liste de tous les paquets et leurs versions qui ont ce nom.

Au passage, c'est effroyablement simple pour un autre problème de dépendances : les Provides. Quand un paquet en fournit d'autres (par exemple "machin" qui fourni "truc = 0.5"), il me suffit de rajouter dans les StrPackages de "truc" une entrée "0.5"->id_du_paquet_truc.

Le solveur de dépendance n'aura même pas à s'en occuper, c'est directement pré-résolu dans la BDD.

Pourquoi je cherche tant de rapidité ? Après tout, on n'installe pas un paquet tous les jours. Simplement, quand on installe un paquet, je compte faire un truc à la Synaptic, c'est à dire rajouter en temps réel les dépendances que notre action précédente entraîne. Il fait donc qu'il n'y ait pas de lag, et donc que la résolution soit foudroyante (attendre 0,1s, c'est déjà trop).

Effectivement, je ne vérifie pas qu'un paquet n'est plus nécessaire, mais un outil de type deborphan ne doit pas être trop compliqué à coder (explorer les paquets installés, prendre leurs reverse-dependencies, voir si il y en a au moins une d'installée, et s'il n'y en a pas, le supprimer si c'est une lib que l'utilisateur ne veut pas).

Pour les conflit, c'est assez simple (quoique j'avoue que ça peut être un peu idiot) : si je veux installer le paquet A, et qu'il est en conflit avec B, je supprime B. Je dois encore voir s'il est mieux de faire ça méchamment (on supprime B), ou intelligemment (on supprime B uniquement s'il est installés).

Pas mal de gens semblent s'intéresser à cette base de donnée, donc je vais détailler.

La base de donnée utilise deux concepts intéressants. D'une part, elle est binaire, et d'autre part, elle est lue grâce à des fichiers mappés.

L'immense avantage des fichiers mappés est que l'OS se charge de toutes les entrées sorties. Pour un solveur de type SAT, qui doit construire le problème, tous les paquets doivent être lus et mis dans le problème. On a donc beaucoup d'IO sur le disque.

Ici, mon système n'utilise que les dépendances d'un paquet (avec les conflits, les dépendances inverses, etc). Si le paquet A dépend de B et est en conflit avec C, je ne vois absolument pas pourquoi je dois mettre D, E et F dans le problème.

Pour illustrer par un cas réel, imaginez que vous souhaitiez installer OpenOffice.org. Vous avez vraiment besoin que votre solveur perde son temps à tester s'il doit installer Wormux ?

Donc, c'est un fichier mappé en mémoire, et ça accélère/simplifie grandement les choses. Il n'y à qu'à voir comment on récupère un paquet quand on connait son ID :

_Package *PackageSystemPrivate::package(int index)
{
// Trouver l'adresse du paquet
if (index >= *(int *)m_packages)
{
return 0;
}

// Début de la liste des paquets
uchar *pkg = m_packages;
pkg += 4;

// Paquet au bon index
pkg += (index * sizeof(_Package));

return (_Package *)pkg;
}

Seulement des pointeurs. Et ce qui est vraiment excellent, c'est que GCC sait très bien compiler et optimiser du code de ce genre. Ceci est compilé en ce code assembleur, uniquement :

movq 40(%rdi), %rdx
xorl %eax, %eax
cmpl %esi, (%rdx)
jle .L3
movslq %esi,%rax
leaq (%rax,%rax,4), %rax
leaq 4(%rdx,%rax,4), %rax
.L3:
rep
ret

9 instructions, en O(1), pour récupérer un paquet dans la BDD. Qui dit mieux ?

Même chose quand on a une chaîne :

const char *PackageSystemPrivate::string(uchar *map, int index)
{
// Si map == 0, on prend m_strings (c'est qu'on a été appelé d'ailleurs)
if (map == 0)
{
map = m_strings;
}

// Vérifier l'index
if (index >= *(int *)map)
{
return 0;
}

// Trouver la chaîne à l'index spécifié
uchar *str = map;
int count = *(int *)map; // count

str += 4; // Sauter count

// Index
str += (index * sizeof(_String));

// En fonction du pointeur, trouver l'adresse de la chaîne
const char *ptr = (const char *)map;
ptr += ((_String *)(str))->ptr; // Ajouter l'adresse du pointeur
ptr += 4; // Sauter le count
ptr += (count * sizeof(_String)); // Sauter la table des chaînes

return ptr;
}

Egalement en temps constant, très rapide. Ca s'utilise comme ça :

QString PackageSystemPrivate::packageName(int index)
{
_Package *pkg = package(index);

if (pkg == 0) return QString();

return QString(string(m_strings, pkg->name));
}

Pour la dépendance de Qt, c'est simplement qu'il est totalement idiot de ne pas l'utiliser alors qu'il marche si bien. Libpackage et Setup ne dépendent que de QtCore, mais bien. Par exemple, mon code utilise beaucoup de QHash, QList, QVector, QFile, QString, etc. Qt est vraiment très confortable, et permet de raccourcir le code.

Je n'ai pas de temps à perdre à coder mon propre Hash, ou ma propre liste. C'est une source de bugs potentielle. Je préfère me concentrer sur l'algo, pas sur le codage en dessous. Pour ça, Qt est excellent : il propose tous les trucs dont on a besoin, mais qui prennent pas mal de temps à coder. Utiliser QString::split() ou QString::section est un bonheur quand on a des trucs comme splitter "machin>=chose" pour récupérer le nom et la version.

La gestion des dépendances inverses est intéressante, surtout que en dehors du solveur.

Le packageur crée un fichier de la sorte :

[paquet]
Name=nom
Version=version
Distribution=section de la distrib
Depends=dépendances (>= version); ...

Ces fichiers sont envoyés sur le serveur, qui en fonction de Distribution crée les dists/distro/packages.lzma. Ce fichier compressé est la simple concaténation des fichiers écrits par les packageurs.

Du côté de Setup, ces fichiers sont récupérés, et inscrits dans la base de donnée (par un code monstrueux de 700 lignes d'ailleurs).

C'est là que tout est joué : dans la base de donnée, chaque paquet a une simple liste de dépendances, et chaque dépendant est une structure :

struct _Depend
{
int8_t type; // DEPEND_TYPE
int8_t op; // DEPEND_OP
int32_t pkgname; // Index de la chaîne du nom du paquet de la dépendance
int32_t pkgver; // Index de la chaîne de la version du paquet de la dépendance
};

Type permet de spécifier le type, c'est à dire une dépendance, une suggestion, un conflit, une fourniture, et une dépendance inverse. Les dépendances inverses ne sont pas données par le packageur, mais c'est databasewriter.cpp, qui connaissant tous les paquets de la BDD, s'occupe de faire les liens inverse (pour chaque dépendance, une dépendance inverse est crée de l'autre côté).

Ainsi, du côté du solveur, le code de gestion des dépendances inverses se limite à ... ceci :

else if (dep->type == DEPEND_TYPE_REVDEP && action == Solver::Remove)
{
act = Solver::Remove;
// TODO: Vérifier que la dépendance inverse est installée avant de surcharger l'arbre
}

Donc, si on retire un paquet, on retire également ses dépendances inverses (et le TODO est là pour me rappeler que quand j'aurai codé l'installation, je devrai voir si le paquet n'est pas déjà non-installé, pour ne pas le supprimer deux fois, et donc créer trop de branches).

C'est simple, ça marche :

$ ./setup add -libinitng
{
"libinitng" "0.6.99+gitAug302009~1"
"initng" "0.6.99+gitAug302009~1"
"initng-plugins" "0.6.99+gitAug302009~1"
"initng-plugins" "0.6.98"
"initng" "0.6.98"
}
{
"libinitng" "0.6.98"
}

Ici, on voit qu'on a deux solutions :

* Retirer libinitng-0.6.98 dont rien ne dépend
* Retirer tous les autres paquets (puisque je n'ai pas encore la gestion des paquets supprimés/installés, tout est supprimés). On voit qu'on a correctement remonté tout l'arbre : initng dépend de libinitng, et les initng-plugins dépendent de initng.

C'est ok :) .