Ça fait depuis combien de temps que tu n'as plus essayé KDE 4. Ce n'est pas pour dire, mais alors que GNOME se développe lentement (migration gnome-vfs vers gvfs qui dure depuis plus d'un an, et qui n'est toujours pas finie), KDE évolue superbement vite. Entre KDE 4.0 et KDE 4.1, c'était le jour et la nuit.
Quand j'ai testé KDE 4.0, j'ai voulu ne plus jamais toucher à KDE. Quand KDE 4.1 est venu, je lui ait laissé une chance, et en 6 petits mois, ils avaient corrigé une bonne partie des problèmes ! Quand KDE 4.2 est arrivé, voilà, en 1 an, KDE est utilisable, et pleinement utilisable. Je suis entièrement satisfait de KDE 4.2.
Maintenant, j'ai la version SVN de KDE 4.3 sur mon disque dur, et quand j'étais sous Gentoo, je l'utilisais toute seule (sans prendre le ebuild 4.2). Là, c'est carrément le rêve. Hyper stable (alors que c'était encore avant le bêta 1), hyper développé, tous les bugs corrigés (Konqueror stable comme un rock, Plasma hyper bien fini, thème Oxygen épuré, etc).
Franchement, KDE n'est pas le genre de chose sur lesquels il faut avoir des préjugés. Il évolue vite.
De même pour GNOME, je ne critique pas sans tester. J'ai eu Ununtu Jaunty en GNOME pendant bien 1 mois, avant de remettre KDE. J'utilise donc "en parallèle" les deux DE, et je parle en connaissance de cause.
Purée, on peut dire ce qu'on veut, mais KDE est des années lumières devant GNOME quand on voit ça !
Quand je pense que la majorité des normes FreeDesktop viennent de KDE (DBus~DCop, Desktop Entry~KDE Desktop Entry, Icon Theme~KDE Icon Theme, etc), je me demande à quoi sert GNOME :-° .
Et quand je pense que les distros choisissent GNOME (Ubuntu par exemple, distro la plus utilisée, est largement orientée GNOME), alors que KDE est bien mieux intégré, et montre une très belle facette de Linux.
Utilisateur Vista : «Ouais, moi mon système est bien intégré, je peux aller sur du FTP dans l'explorateur Windows, il m'affiche plein d'infos sur mes images, les fenêtres sont décorées avec transparence, j'ai plein d'applis intégrée, donc toutes les applis MS».
Face à GNOME : «Bof, on peut même pas mettre de widgets Vista sur le bureau, et Nautilus n'affiche pas plein d'infos sur mes photos dans un panel à côté. Oui, c'est joli, mais c'est bien moins développé que mon cher Vista»
Face à KDE : «J'adore : on peut mettre des widgets sur tout le bureau, je peux aller sur le web ou dans mes dossiers (locaux et distants) depuis Konqueror, Dolphin est vraiment super, et m'affiche mes infos sur mes images, le tout est beau, bien léché, les applis super intégrées (le peux avoir Okular dans Konqueror, et afficher un PDF donné en lien rien qu'en cliquant dessus !), j'adore, je recommende Linux, Vista c'est nul à côté».
Mes comparaisons sont volontairement biaisées sur le côté graphique (on parle bien d'un utilisateur de Vista non :-° ).
Bref, si Linux ne veut pas se prendre une sale claque à la sortie de Windows 7, il faut jeter GNOME et se rendre compte que KDE est le meilleur, qu'il a toujours été le meilleur. Mon père teste Windows 7, et GNOME est bien en dessous.
De plus, contrairement au troll répendu, KDE n'est pas plus lourd. Au démarrage, un GNOME occupe 250Mio (et encore, optimisé). KDE en occpue 200Mio, avec tout de même Plasma qui propose bien plus de fonctionnalités, etc.
Désolé pour le troll, ça devait sortir (surtout que je n'ai pas argumenté en plus :-° . Je me base uniquement sur mon expérience de Windowsien pendant 6 ans, GNOMEiste pendant 8 mois, et KDEiste pendant 6 mois)
PS: Encore une couche : vous aimez Anjuta, l'environnement de développement de GNOME ? Et bien, vous allez être séduit par KDevelop ! On peut faire ça pour beaucoup de parties de GNOME. Je ne sais pas si les codeurs de GNOME s'y sont pris avec les pieds, si Qt prémâche vraiment le travail, si le C++ convient mieux (réutilisabilité du code, etc), ou si les devs de KDE sont géniaux, mais GNOME fait 20 millions de lignes de code [1], et propose bien moins de choses que KDE qui en fait 8 millions [2].
Setup crée son paquet pour le moment, mais ne l'envoie pas. Je ne vais surtout pas supprimer ceci, mais plutôt le garder pour les fameux serveurs de compilation, et les personnes de confiance (quoiqu'à un moment, je comptais me baser sur un processus 100% communautaire pour assez rapidement avoir en beaucoup d'architectures les paquets de beaucoup de programmes dans les versions les plus récentes).
Je cherche, c'est tout. Celui qui ne cherche pas ne trouve pas. C'est peut-être impossible, auquel cas je ne trouverai jamais, mais comme je tiens un tant soit peu à mes idées, j'essaie de les rendre réalisable.
Généralement, on ne se moque pas des gens qui cherchent à arriver à leurs fins.
En clair, je dois arriver à sécuriser cet envoi, d'une manière ou d'une autre. Tout ce que je trouve, tout ce que je dis est suceptible d'aider des gens qui cherchent la même chose ou quelque chose de proche. Par exemple, détecter les infimes modifications d'un fichier permettrais de créer de très bons antivirus ou autres programmes.
Oh j'ai trouvé, comment ais-je pu ne pas y penser.
La GPL et la LGPL demandent qu'on distribue les sources avec les binaires, du moins quand on modifie. Tous les paquets ne sont pas GPL, mais on peut s'aider de cette demande.
Quand un paquet est créé par Setup, les binaires sont placés dans /tmp/lgrpackages/paquet_src. Les sources qui ont construit ce paquet se trouvent dans /tmp/lgrpackages/paquetversion_src.
Il "suffit" de réempaqueter les sources et de les joindre aux paquets binaires. Elles seront aussi envoyées au serveur, et comparées avec les sources "officielles". Si elles ne sont pas les mêmes, on fait un diff, et si le patch est intéressant, on l'applique aux sources officielles.
Pour que ce soit un minimum secure, il faut éxécuter les actions dans cet ordre (le but est d'empêcher l'éventuel cracker de modifier les sources avant, pendant ou après la compilation/création du paquet) :
- l'archive source est téléchargée, puis décompressée. On calcul un md5 de l'archive tar obtenue
- les fichiers de l'archive sont décompressés dans /tmp/lgrpackages/paquetversion_src (le cracker a déjà perdu ses modifs ici ^^ )
- un md5 de toutes ces sources est calculé (avec un re-tarage), et comparé au premier.
- Si les hash ne correspondent pas, on quitte tout
- On stocke le timestamp actuel
- On compile le paquet
- On supprime tous les fichiers plus récents que le timestamp actuel (la compilation ne modifie normalement pas de fichiers source, mais c'est à vérifier).
- On recalcul le md5 des sources, et on recompare
- Si ce n'est pas bon, on quitte tout
- le recalcul aura créé une archive tar. On la compresse en lzma, et on l'envoie avec le paquet, ainsi que le hash du tar non-compressé.
- sur le serveur, le hash envoyé est comparé avec le hash des sources officielles décompressées.
- si le hash ne correspond pas, on refuse le paquet.
Normalement, pas moyen de passer outre :) . Quelques questions maintenant.
> Pourquoi calculer les hash sur des archives tar non-compressées ?
On doit calculer pas mal de hash ici, et un md5sum (ou sha256sum) est bien plus rapide qu'un passage par lzma ou bzip2. De plus, les sources officielles sont normalement en lzma, mais peuvent aussi être en bzip2, z, etc.
> Comment faire pour SVN ?
La séquence est assez simple (et s'applique aussi à git et autres) :
o svn checkout
o calcul du md5
o svn log doit être vide
o calcul du md5
Les deux md5 doivent être les mêmes, sinon ça veut dire que l'utilisateur a modifié des fichiers. De plus, l'emplacement des dépots SVN récupérés est placé dans /var/setup/cache/hash_sha_du_nom_du_dépot. Ainsi, un script malicieux a plus de mal à détecter et à modifier le dépot.
Malheureusement, tout cela ralentit vraiment fortement la création de paquets, et ne devrait donc être activé que quand l'utilisateur veut envoyer son paquet.
De plus, étant open-source, le pirate pourra très facilement modifier Setup pour faire sauter la protection. Malheureusement, la GPL v3 interdit de placer un code de vérification dans Setup qui l'empêche de démarrer s'il a été modifié.
Effectivement, ça ne marche pas. Les images sont tout à fait brouillées dès que je change une option de compilation, et le changement d'une ligne est imperceptible.
Il va malheureusement falloir tester tous les paquets, ou encore trouver une autre solution (ou alors ne pas proposer l'envoi de paquets, mais ce serait perdre quelque-chose de très pratique (autant d'architectures que d'utilisateurs de supportées)).
Soit une image de 256x256, donc de 65536 pixels. On peut donc s'en servir pour représenter des fichiers de minimum 196k (trois octets par pixels). pour les fichiers plus petits, on réduit l'image, pour les plus grands, on place plusieurs octets par pixels (on ne fait que les additionner bêtement, pas besoin de plus).
Les composantes R, G et B de chaque pixel sont les valeurs des octets qu'ils représentent. On sauve l'image. On a donc une image gribouillie par fichier, et on ne sait rien en faire.
Maintenant, pour chaque image, on prend les images des autres fichiers, et on fait leur moyenne, puis la différence avec l'image du fichier. On obtiens donc ... une image toute noire pour un fichier concordant !
Si le moindre octet, ou groupe d'octets ne correspond pas, de jolis et brillants pixels de couleurs vont apparaître sur l'image.
Avec les optimisations du compilateur, on peut avoir un léger bruit sur les images, bruit qu'on peut laisser passer. Si jamais une ligne de code, comme montrée dans le commentaire plus haut, est modifiée, ce ne sera pas quelques octets de changés, mais une quarantaine.
Au lieu d'avoir quelques (ou plus) pixels différents éparpillés sur l'image, on aura une "tache" plus claire. La quantité de pixels ne fera donc pas la différence (une image peut être bruitée), mais plutôt leur disposition. Si une zone de pixels contigus sont clairs, c'est qu'il y a un problème.
On applique donc un petit flou, puis quelques autres opérations, et enfin un ajustement du constraste, et on peut obtenir de belles images avec des taches quand ça ne va pas, ou toutes noires quand ça va.
Je m'en vais tester tout ça, pour vérifier mes dires. (et ça, ce sera un bon petit logiciel libre qui va pouvoir servir à tout le monde, j'aurai au moins créé un comparateur rapide de fichiers binaires :P ).
Non non, je but de ce "hash" n'est pas de signer les paquets, ou de les vérifier pour l'utilisateur, c'est pour vérifier que deux paquets (soit-disant les mêmes) envoyés par deux personnes ne sont pas trop différents.
Dans le journal, je donne l'exemple d'un trojan inséré dans un paquet. On a trois paquets : deux quasi-semblables, et un différent. Avec des images, on peut voir lequel est différent, et l'éliminer.
Bien sûr, une signature GPG et un hash (un vrai hash) sont utilisés une fois le paquet validé et placé dans les dépôts, bien entendu.
Setup n'a que quelques semaines, et sa gestion des dépendances est encore toute simple. Seulement, quand je donne une durée, c'est pour dire que je n'ai pas codé ça vite fait, j'ai un minimum réfléchit.
Pour le moment, j'utilise l'algorithme le plus simple qu'il puisse exister :
Quand on installe un paquet :
on obtiens sa liste de dépendances directes (format "paquet" ou "paquet=version" ou "paquet>=version", etc)
Si l'utilisateur le veut, on ajoute aux dépendances la liste des recommendations.
On a donc une simple liste de chaînes, qu'on explore.
Pour chaque chaîne :
--Si le paquet n'est pas installé:
----Parser sa chaîne, pour obtenir le nom du paquet, sa version à installer, et sa méthode d'installation (données, binaire ou source)
----Ajouter le paquet à la liste (ce qui appelle cette fonction, qui est donc récursive)
Quand l'ajout des paquets est fini, on ajoute ce paquet à la liste des paquets à installer. Ainsi, les dépendances sont installées avant ce paquet, ce qui est logique
C'est tout simple, et ça marche pour la majorité des paquets. Je n'ai pas cité la dedans l'élimination des dépendances.
Une fois la liste des paquets à installer/supprimer construite, elle est affichée à l'utilisateur, qui peut la valider ou pas (dans la version graphique, il pourra peut-être la modifier).
Ensuite, la liste est procédée : les paquets sont installés dans l'ordre, donc d'abord les dépendances, puis les paquets sélectionnés.
Il faut donc trouver un moyen de détecter les grosses différences entre deux fichiers, ou alors en se basant sur la taille (un trojan a toujours un certain poids).
Ce que vous n'avez pas relevé mais que je n'ai pas dit est la gestion des USEs, qui influence encore le paquet. Bien évidemment, on ne compare que des paquets qui ont les mêmes USE.
C'est en effet bien plus complexe, mais le journal était déjà conséquent. De plus, ce système est prévu pour dans très longtemps, donc j'ai encore le temps d'y réfléchir. Je suis ouvert à toutes suggestions.
Une méthode qui peut être utilisée est la génération d'une image. Par exemple, chaque pixel a comme valeur le checksum d'un bloc de donnée. Ainsi, un cerveau humain peut très facilement voir si une image est proche d'une autre, ou pas, alors que comparer deux longs hash, c'est bien plus complexe.
Pour le réseau de confiance, on aurait à nouveau le problème relevé plus haut dans les commentaires : il faudrait énormément de monde pour maintenir les paquets. Avec ce système «Les utilisateurs envoient leur paquets», il ne faut plus trop de monde pour créer les paquets, juste des personnes qui s'occupent de créer les lbuilds sources (et de les tester, mais ils ne doivent le faire que sur une architecture), et les utilisateurs pourront créer leurs lbuilds sources eux-même (avec pkgAssistant, comme dit dans la news).
Les dépendances sont gérées, à plusieurs niveaux (obligatoires, recommandées, conflits). Les dépendances peuvent dépendre d'une "USE string" (donc une chaîne qui indique les conditions de USE, comme par exemple "machin,-chose", pour quand machin est activé ou que chose ne l'est pas).
Les dépendances sont installées dans l'ordre données dans le lbuild. Les dépendances binaires sont installées avant les sources (pour éviter qu'une compilation plante), etc.
J'ai pris près d'une semaine entière pour coder le système de gestion des dépendances, donc il doit être correct (peut-être pas le meilleur, mais il est viable). Je ne le montre pas dans mes exemples car je n'ai pas un deuxième paquet (j'ai juste llibs pour le moment, et pas Qt par exemple).
Pour la compatibilité binaire, un paquet peut dépendre d'une version exacte d'un paquet, ou d'une version supérieure/inférieure. Pour les grosses bibliothèque, il y a un système de scripts et de patchs de disponible. Je dois avouer que je n'ai pas encore beaucoup pensé à ça.
Je sais, je ne respecte pas les conventions de codage, mais c'est parce qu'elle ne me conviennent pas.
Je suis plutôt pour un code très aéré, donc avec des tabulations de 8 caractères, des accolades à la ligne, etc. Ce n'est pas parce qu'on utilise Qt qu'on doit suivre ses conventions de nommage, qui sont jolies, mais parfois difficiles à lire.
Pour le code que tu montres, avec QHttp, ben justement, c'est le seul morceau de copier/coller de la doc de Qt, dans un des exemples qu'ils donnaient, donc ce morceau n'est pas de moi.
Pour les commentaires, oui, il y en a énormément, mais ils ont l'avantage de vraiment montrer mon raisonnement, car à la base, je les écrits pour me fixer les idées. Ainsi, quand les gens viennent, ils comprennent le code rapidement. J'ai eu l'occasion de me plonger dans le code de Plasma, et je peux te dire que j'aurais vraiment, mais vraiment aimé avoir plus de commentaires. La doc de cette partie de l'API est très succinte, et les commentaires secs. Bref, avec tous ces DesktopCorona et autres, j'ai du tatoner pendant près d'une semaine pour arriver à un truc qui marche de mon côté.
Pour le design des classes, j'avoue. La classe Package contient tout ce qui touche au fichier XML des paquets, sa sous-classe Private tout ce qui ne doit pas être exposé à l'extérieur (et tu remarqueras que je suis la convention du pointeur d ici, comme quoi j'en suis capable). Effectivement, la classe PackageSystem est boiteuse, avec des fonctions statiques et d'autres non. J'ai essayé d'en mettre quelques-unes en statique, pour permettre de facilement faire un "PackageSystem::package(nom, version, méthode)" sans avoir besoin d'une instance (et donc d'un pointeur d en mémoire, ainsi quele classe private, et tout un QObject).
La classe Util est vraiment tordue, je l'avoue. Son but premier est de fournir des méthodes qui ne sortent pas de libpackages, comme download() (méthode qu'on retrouve, statique, dans PackageSystem).
Si tu trouves encore du code que je peux améliorer, dis-le, et je me ferai un plaisir de le corriger. En attendant, je vais regarder de bien plus près le code de KDE, pour apprendre.
Et comme les balises "a" ne sont pas prises dans les commentaires, je mets ici l'exemple de lbuild que j'ai voulu donner plus haut : http://logram.pastebin.com/f2350f66e
Bonne idée, mais il y a un problème : qu'est-ce qu'on fait des applications non-Logram ?
Par exemple, FireFox gère les onglets, et n'exposera pas à Logram une méthode pour savoir ce qu'on peut faire avec un document ouvert dedans. Ça obligerait Logram à recoder toutes les applications pour les intégrer, et c'est une tâche monstrueuse.
Je retiens tout de même, au cas où quelqu'un trouve une solution.
C'est prévu. Le README est en anglais, mais je vous déconseille franchement de le lire tellement l'anglais y est horrible.
D'ailleurs, si quelqu'un se sent le courage de traduire, je veux bien qu'il essaie. Malheureusement, je ne suis pas dans la possibilité de coder en anglais (foutue éducation en Belgique, ça fait près de 10 ans qu'on nous apprend le flamand, et seulement deux ans on on a un peu d'anglais).
Sinon, normalement, la version 4 du site sera en anglais, de même pour le code, etc.
- ceux qui veulent intégrer tout ce qu'on trouve de bon. Pas mal de distribs le font (basées sur Deb ou sur Rpm)
- ceux qui veulent quelque-chose qui convient à leur besoin, comme Gentoo et son Portage, et surtout ArchLinux qui a l'air si plébiscité ici. Si ArchLinux avait repris Deb, est-ce que son gestionnaire de paquets si aimé serait né ?
Bref, reprendre l'existant est bien, mais si on croit pouvoir faire mieux, autant essayer non ? Si on n'y arrive pas, tant pis. Si on y arrive, alors tout le monde est gagnant :) .
Pas par coeur, mais je sais où tout se trouve, et je sais ce que les fichiers contiennent. En ayant développé Logram, je me suis de temps en temps inspiré de KDE.
Donc oui, je sais me retrouver dans trunk/KDE/kdelibs/kdecore, et aussi dans kdeui. J'ai déjà jeté un oeil dans kio, mais pas encore dans kjs et khtml (je ne vois pas ce que je ferais de ça). J'ai quelques fois exploré kdevelop et kdesdk (pour voir comment parchait Kate). J'ai aussi assisté à la migration de Konversation depuis branches/work à trunk/extragear. Grand moment :) .
Enfin bon, j'avoue que mon terme était un peu fort. Je m'y retrouve on va dire.
svn co svn://logram-project.org/logram/branches/work
pour obtenir le code de la version de développement de Setup (le trunk contient encore uniquement le DE, en attendant que Setup soit fonctionnel, et qu'il rejoigne le trunk).
Télécharge depuis le dépôt SVN le code des bibliothèques Logram, les compile avec les USE flags sélectionnés, et installe le tout. Dans /tmp/lgrpackages/llibs_pkg, il y a un fragment de lbuild ainsi que les archives binaires compressées en LZMA qui sont prêts à l'envoi :) !
À venir, mais construira le paquet d'un répertoire contenant les sources (ma version de dev réussi à compiler X-Moto !). Il suffit de retirer "--console" pour avoir une magnifique GUI. J'ai une vidéo de 40 Mio à envoyer, si quelqu'un la veut.
[^] # Re: Troll, ou pas
Posté par steckdenis (site web personnel) . En réponse au journal Kde 4.3 beta2. Évalué à 8.
Quand j'ai testé KDE 4.0, j'ai voulu ne plus jamais toucher à KDE. Quand KDE 4.1 est venu, je lui ait laissé une chance, et en 6 petits mois, ils avaient corrigé une bonne partie des problèmes ! Quand KDE 4.2 est arrivé, voilà, en 1 an, KDE est utilisable, et pleinement utilisable. Je suis entièrement satisfait de KDE 4.2.
Maintenant, j'ai la version SVN de KDE 4.3 sur mon disque dur, et quand j'étais sous Gentoo, je l'utilisais toute seule (sans prendre le ebuild 4.2). Là, c'est carrément le rêve. Hyper stable (alors que c'était encore avant le bêta 1), hyper développé, tous les bugs corrigés (Konqueror stable comme un rock, Plasma hyper bien fini, thème Oxygen épuré, etc).
Franchement, KDE n'est pas le genre de chose sur lesquels il faut avoir des préjugés. Il évolue vite.
De même pour GNOME, je ne critique pas sans tester. J'ai eu Ununtu Jaunty en GNOME pendant bien 1 mois, avant de remettre KDE. J'utilise donc "en parallèle" les deux DE, et je parle en connaissance de cause.
[^] # Re: Troll, ou pas
Posté par steckdenis (site web personnel) . En réponse au journal Kde 4.3 beta2. Évalué à 2.
Pour les widgets de bureau, avec tout le show qu'à fait MS («La bourse et vos photos toujours affichées !»), les utilisateurs en ont pris l'habitude.
# Troll, ou pas
Posté par steckdenis (site web personnel) . En réponse au journal Kde 4.3 beta2. Évalué à 10.
Quand je pense que la majorité des normes FreeDesktop viennent de KDE (DBus~DCop, Desktop Entry~KDE Desktop Entry, Icon Theme~KDE Icon Theme, etc), je me demande à quoi sert GNOME :-° .
Et quand je pense que les distros choisissent GNOME (Ubuntu par exemple, distro la plus utilisée, est largement orientée GNOME), alors que KDE est bien mieux intégré, et montre une très belle facette de Linux.
Utilisateur Vista : «Ouais, moi mon système est bien intégré, je peux aller sur du FTP dans l'explorateur Windows, il m'affiche plein d'infos sur mes images, les fenêtres sont décorées avec transparence, j'ai plein d'applis intégrée, donc toutes les applis MS».
Face à GNOME : «Bof, on peut même pas mettre de widgets Vista sur le bureau, et Nautilus n'affiche pas plein d'infos sur mes photos dans un panel à côté. Oui, c'est joli, mais c'est bien moins développé que mon cher Vista»
Face à KDE : «J'adore : on peut mettre des widgets sur tout le bureau, je peux aller sur le web ou dans mes dossiers (locaux et distants) depuis Konqueror, Dolphin est vraiment super, et m'affiche mes infos sur mes images, le tout est beau, bien léché, les applis super intégrées (le peux avoir Okular dans Konqueror, et afficher un PDF donné en lien rien qu'en cliquant dessus !), j'adore, je recommende Linux, Vista c'est nul à côté».
Mes comparaisons sont volontairement biaisées sur le côté graphique (on parle bien d'un utilisateur de Vista non :-° ).
Bref, si Linux ne veut pas se prendre une sale claque à la sortie de Windows 7, il faut jeter GNOME et se rendre compte que KDE est le meilleur, qu'il a toujours été le meilleur. Mon père teste Windows 7, et GNOME est bien en dessous.
De plus, contrairement au troll répendu, KDE n'est pas plus lourd. Au démarrage, un GNOME occupe 250Mio (et encore, optimisé). KDE en occpue 200Mio, avec tout de même Plasma qui propose bien plus de fonctionnalités, etc.
Désolé pour le troll, ça devait sortir (surtout que je n'ai pas argumenté en plus :-° . Je me base uniquement sur mon expérience de Windowsien pendant 6 ans, GNOMEiste pendant 8 mois, et KDEiste pendant 6 mois)
PS: Encore une couche : vous aimez Anjuta, l'environnement de développement de GNOME ? Et bien, vous allez être séduit par KDevelop ! On peut faire ça pour beaucoup de parties de GNOME. Je ne sais pas si les codeurs de GNOME s'y sont pris avec les pieds, si Qt prémâche vraiment le travail, si le C++ convient mieux (réutilisabilité du code, etc), ou si les devs de KDE sont géniaux, mais GNOME fait 20 millions de lignes de code [1], et propose bien moins de choses que KDE qui en fait 8 millions [2].
[1] : http://www.ohloh.net/p/gnome/analyses/latest
[2] : http://www.ohloh.net/p/kde/analyses/latest
je prédis -10 (et si on pouvait aller plus bas : -42)
[^] # Re: Nombre de lignes de code du noyau
Posté par steckdenis (site web personnel) . En réponse à la dépêche Le noyau Linux 2.6.30 est disponible. Évalué à 5.
Ohloh nous propose un joli petit graphique ici : http://www.ohloh.net/p/linux/analyses/latest .
C'est impressionnant un tel nombre de lignes ! (et ce qui m'étonne aussi est la régularité de l'augmentation du nombre de lignes).
[^] # Re: Tu peux donner un vrai lien, c'est aussi simple
Posté par steckdenis (site web personnel) . En réponse au journal Google connaît bien Linuxfr. Évalué à 7.
Je n'avais pas vu.
[^] # Re: Magie !
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 2.
Setup crée son paquet pour le moment, mais ne l'envoie pas. Je ne vais surtout pas supprimer ceci, mais plutôt le garder pour les fameux serveurs de compilation, et les personnes de confiance (quoiqu'à un moment, je comptais me baser sur un processus 100% communautaire pour assez rapidement avoir en beaucoup d'architectures les paquets de beaucoup de programmes dans les versions les plus récentes).
[^] # Re: Magie !
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 1.
Généralement, on ne se moque pas des gens qui cherchent à arriver à leurs fins.
En clair, je dois arriver à sécuriser cet envoi, d'une manière ou d'une autre. Tout ce que je trouve, tout ce que je dis est suceptible d'aider des gens qui cherchent la même chose ou quelque chose de proche. Par exemple, détecter les infimes modifications d'un fichier permettrais de créer de très bons antivirus ou autres programmes.
[^] # Re: Magie !
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 2.
La GPL et la LGPL demandent qu'on distribue les sources avec les binaires, du moins quand on modifie. Tous les paquets ne sont pas GPL, mais on peut s'aider de cette demande.
Quand un paquet est créé par Setup, les binaires sont placés dans /tmp/lgrpackages/paquet_src. Les sources qui ont construit ce paquet se trouvent dans /tmp/lgrpackages/paquetversion_src.
Il "suffit" de réempaqueter les sources et de les joindre aux paquets binaires. Elles seront aussi envoyées au serveur, et comparées avec les sources "officielles". Si elles ne sont pas les mêmes, on fait un diff, et si le patch est intéressant, on l'applique aux sources officielles.
Pour que ce soit un minimum secure, il faut éxécuter les actions dans cet ordre (le but est d'empêcher l'éventuel cracker de modifier les sources avant, pendant ou après la compilation/création du paquet) :
- l'archive source est téléchargée, puis décompressée. On calcul un md5 de l'archive tar obtenue
- les fichiers de l'archive sont décompressés dans /tmp/lgrpackages/paquetversion_src (le cracker a déjà perdu ses modifs ici ^^ )
- un md5 de toutes ces sources est calculé (avec un re-tarage), et comparé au premier.
- Si les hash ne correspondent pas, on quitte tout
- On stocke le timestamp actuel
- On compile le paquet
- On supprime tous les fichiers plus récents que le timestamp actuel (la compilation ne modifie normalement pas de fichiers source, mais c'est à vérifier).
- On recalcul le md5 des sources, et on recompare
- Si ce n'est pas bon, on quitte tout
- le recalcul aura créé une archive tar. On la compresse en lzma, et on l'envoie avec le paquet, ainsi que le hash du tar non-compressé.
- sur le serveur, le hash envoyé est comparé avec le hash des sources officielles décompressées.
- si le hash ne correspond pas, on refuse le paquet.
Normalement, pas moyen de passer outre :) . Quelques questions maintenant.
> Pourquoi calculer les hash sur des archives tar non-compressées ?
On doit calculer pas mal de hash ici, et un md5sum (ou sha256sum) est bien plus rapide qu'un passage par lzma ou bzip2. De plus, les sources officielles sont normalement en lzma, mais peuvent aussi être en bzip2, z, etc.
> Comment faire pour SVN ?
La séquence est assez simple (et s'applique aussi à git et autres) :
o svn checkout
o calcul du md5
o svn log doit être vide
o calcul du md5
Les deux md5 doivent être les mêmes, sinon ça veut dire que l'utilisateur a modifié des fichiers. De plus, l'emplacement des dépots SVN récupérés est placé dans /var/setup/cache/hash_sha_du_nom_du_dépot. Ainsi, un script malicieux a plus de mal à détecter et à modifier le dépot.
Malheureusement, tout cela ralentit vraiment fortement la création de paquets, et ne devrait donc être activé que quand l'utilisateur veut envoyer son paquet.
De plus, étant open-source, le pirate pourra très facilement modifier Setup pour faire sauter la protection. Malheureusement, la GPL v3 interdit de placer un code de vérification dans Setup qui l'empêche de démarrer s'il a été modifié.
Problème hyper épineux.
[^] # Re: Magie !
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 2.
Il va malheureusement falloir tester tous les paquets, ou encore trouver une autre solution (ou alors ne pas proposer l'envoi de paquets, mais ce serait perdre quelque-chose de très pratique (autant d'architectures que d'utilisateurs de supportées)).
[^] # Re: Magie !
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 2.
Soit une image de 256x256, donc de 65536 pixels. On peut donc s'en servir pour représenter des fichiers de minimum 196k (trois octets par pixels). pour les fichiers plus petits, on réduit l'image, pour les plus grands, on place plusieurs octets par pixels (on ne fait que les additionner bêtement, pas besoin de plus).
Les composantes R, G et B de chaque pixel sont les valeurs des octets qu'ils représentent. On sauve l'image. On a donc une image gribouillie par fichier, et on ne sait rien en faire.
Maintenant, pour chaque image, on prend les images des autres fichiers, et on fait leur moyenne, puis la différence avec l'image du fichier. On obtiens donc ... une image toute noire pour un fichier concordant !
Si le moindre octet, ou groupe d'octets ne correspond pas, de jolis et brillants pixels de couleurs vont apparaître sur l'image.
Avec les optimisations du compilateur, on peut avoir un léger bruit sur les images, bruit qu'on peut laisser passer. Si jamais une ligne de code, comme montrée dans le commentaire plus haut, est modifiée, ce ne sera pas quelques octets de changés, mais une quarantaine.
Au lieu d'avoir quelques (ou plus) pixels différents éparpillés sur l'image, on aura une "tache" plus claire. La quantité de pixels ne fera donc pas la différence (une image peut être bruitée), mais plutôt leur disposition. Si une zone de pixels contigus sont clairs, c'est qu'il y a un problème.
On applique donc un petit flou, puis quelques autres opérations, et enfin un ajustement du constraste, et on peut obtenir de belles images avec des taches quand ça ne va pas, ou toutes noires quand ça va.
Je m'en vais tester tout ça, pour vérifier mes dires. (et ça, ce sera un bon petit logiciel libre qui va pouvoir servir à tout le monde, j'aurai au moins créé un comparateur rapide de fichiers binaires :P ).
[^] # Re: dépendance
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 2.
Là, ça change tout. Je vais m'empresser de lire ce document.
[^] # Re: Magie !
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 2.
Dans le journal, je donne l'exemple d'un trojan inséré dans un paquet. On a trois paquets : deux quasi-semblables, et un différent. Avec des images, on peut voir lequel est différent, et l'éliminer.
Bien sûr, une signature GPG et un hash (un vrai hash) sont utilisés une fois le paquet validé et placé dans les dépôts, bien entendu.
[^] # Re: dépendance
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 2.
Pour le moment, j'utilise l'algorithme le plus simple qu'il puisse exister :
Quand on installe un paquet :
on obtiens sa liste de dépendances directes (format "paquet" ou "paquet=version" ou "paquet>=version", etc)
Si l'utilisateur le veut, on ajoute aux dépendances la liste des recommendations.
On a donc une simple liste de chaînes, qu'on explore.
Pour chaque chaîne :
--Si le paquet n'est pas installé:
----Parser sa chaîne, pour obtenir le nom du paquet, sa version à installer, et sa méthode d'installation (données, binaire ou source)
----Ajouter le paquet à la liste (ce qui appelle cette fonction, qui est donc récursive)
Quand l'ajout des paquets est fini, on ajoute ce paquet à la liste des paquets à installer. Ainsi, les dépendances sont installées avant ce paquet, ce qui est logique
C'est tout simple, et ça marche pour la majorité des paquets. Je n'ai pas cité la dedans l'élimination des dépendances.
Une fois la liste des paquets à installer/supprimer construite, elle est affichée à l'utilisateur, qui peut la valider ou pas (dans la version graphique, il pourra peut-être la modifier).
Ensuite, la liste est procédée : les paquets sont installés dans l'ordre, donc d'abord les dépendances, puis les paquets sélectionnés.
Si vous avez des conseils, ne vous privez pas.
[^] # Re: Magie !
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 2.
Il faut donc trouver un moyen de détecter les grosses différences entre deux fichiers, ou alors en se basant sur la taille (un trojan a toujours un certain poids).
Ce que vous n'avez pas relevé mais que je n'ai pas dit est la gestion des USEs, qui influence encore le paquet. Bien évidemment, on ne compare que des paquets qui ont les mêmes USE.
[^] # Re: Magie !
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 2.
Une méthode qui peut être utilisée est la génération d'une image. Par exemple, chaque pixel a comme valeur le checksum d'un bloc de donnée. Ainsi, un cerveau humain peut très facilement voir si une image est proche d'une autre, ou pas, alors que comparer deux longs hash, c'est bien plus complexe.
Pour le réseau de confiance, on aurait à nouveau le problème relevé plus haut dans les commentaires : il faudrait énormément de monde pour maintenir les paquets. Avec ce système «Les utilisateurs envoient leur paquets», il ne faut plus trop de monde pour créer les paquets, juste des personnes qui s'occupent de créer les lbuilds sources (et de les tester, mais ils ne doivent le faire que sur une architecture), et les utilisateurs pourront créer leurs lbuilds sources eux-même (avec pkgAssistant, comme dit dans la news).
[^] # Re: dépendance
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 2.
Les dépendances sont installées dans l'ordre données dans le lbuild. Les dépendances binaires sont installées avant les sources (pour éviter qu'une compilation plante), etc.
J'ai pris près d'une semaine entière pour coder le système de gestion des dépendances, donc il doit être correct (peut-être pas le meilleur, mais il est viable). Je ne le montre pas dans mes exemples car je n'ai pas un deuxième paquet (j'ai juste llibs pour le moment, et pas Qt par exemple).
Pour la compatibilité binaire, un paquet peut dépendre d'une version exacte d'un paquet, ou d'une version supérieure/inférieure. Pour les grosses bibliothèque, il y a un système de scripts et de patchs de disponible. Je dois avouer que je n'ai pas encore beaucoup pensé à ça.
[^] # Re: Le Francais te tuera...
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 2.
Je suis plutôt pour un code très aéré, donc avec des tabulations de 8 caractères, des accolades à la ligne, etc. Ce n'est pas parce qu'on utilise Qt qu'on doit suivre ses conventions de nommage, qui sont jolies, mais parfois difficiles à lire.
Pour le code que tu montres, avec QHttp, ben justement, c'est le seul morceau de copier/coller de la doc de Qt, dans un des exemples qu'ils donnaient, donc ce morceau n'est pas de moi.
Pour les commentaires, oui, il y en a énormément, mais ils ont l'avantage de vraiment montrer mon raisonnement, car à la base, je les écrits pour me fixer les idées. Ainsi, quand les gens viennent, ils comprennent le code rapidement. J'ai eu l'occasion de me plonger dans le code de Plasma, et je peux te dire que j'aurais vraiment, mais vraiment aimé avoir plus de commentaires. La doc de cette partie de l'API est très succinte, et les commentaires secs. Bref, avec tous ces DesktopCorona et autres, j'ai du tatoner pendant près d'une semaine pour arriver à un truc qui marche de mon côté.
Pour le design des classes, j'avoue. La classe Package contient tout ce qui touche au fichier XML des paquets, sa sous-classe Private tout ce qui ne doit pas être exposé à l'extérieur (et tu remarqueras que je suis la convention du pointeur d ici, comme quoi j'en suis capable). Effectivement, la classe PackageSystem est boiteuse, avec des fonctions statiques et d'autres non. J'ai essayé d'en mettre quelques-unes en statique, pour permettre de facilement faire un "PackageSystem::package(nom, version, méthode)" sans avoir besoin d'une instance (et donc d'un pointeur d en mémoire, ainsi quele classe private, et tout un QObject).
La classe Util est vraiment tordue, je l'avoue. Son but premier est de fournir des méthodes qui ne sortent pas de libpackages, comme download() (méthode qu'on retrouve, statique, dans PackageSystem).
Si tu trouves encore du code que je peux améliorer, dis-le, et je me ferai un plaisir de le corriger. En attendant, je vais regarder de bien plus près le code de KDE, pour apprendre.
[^] # Re: Liens
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 2.
[^] # Re: Des idées pour logram
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 2.
Par exemple, FireFox gère les onglets, et n'exposera pas à Logram une méthode pour savoir ce qu'on peut faire avec un document ouvert dedans. Ça obligerait Logram à recoder toutes les applications pour les intégrer, et c'est une tâche monstrueuse.
Je retiens tout de même, au cas où quelqu'un trouve une solution.
[^] # Re: Le Francais te tuera...
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 2.
D'ailleurs, si quelqu'un se sent le courage de traduire, je veux bien qu'il essaie. Malheureusement, je ne suis pas dans la possibilité de coder en anglais (foutue éducation en Belgique, ça fait près de 10 ans qu'on nous apprend le flamand, et seulement deux ans on on a un peu d'anglais).
Sinon, normalement, la version 4 du site sera en anglais, de même pour le code, etc.
[^] # Re: Pacman ?
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 9.
- ceux qui veulent intégrer tout ce qu'on trouve de bon. Pas mal de distribs le font (basées sur Deb ou sur Rpm)
- ceux qui veulent quelque-chose qui convient à leur besoin, comme Gentoo et son Portage, et surtout ArchLinux qui a l'air si plébiscité ici. Si ArchLinux avait repris Deb, est-ce que son gestionnaire de paquets si aimé serait né ?
Bref, reprendre l'existant est bien, mais si on croit pouvoir faire mieux, autant essayer non ? Si on n'y arrive pas, tant pis. Si on y arrive, alors tout le monde est gagnant :) .
[^] # Re: Hum,
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 2.
Maintenant, je vais changer de signature, c'est vrai qu'elle fait beaucoup trop mégalo (merci de me le faire remarquer).
[^] # Re: Contributeur régulier?
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 6.
Donc oui, je sais me retrouver dans trunk/KDE/kdelibs/kdecore, et aussi dans kdeui. J'ai déjà jeté un oeil dans kio, mais pas encore dans kjs et khtml (je ne vois pas ce que je ferais de ça). J'ai quelques fois exploré kdevelop et kdesdk (pour voir comment parchait Kate). J'ai aussi assisté à la migration de Konversation depuis branches/work à trunk/extragear. Grand moment :) .
Enfin bon, j'avoue que mon terme était un peu fort. Je m'y retrouve on va dire.
# Liens
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 1.
- http://www.logram-project.org, pour le site de Logram, qui permet d'avoir un aperçu de Setup
svn co svn://logram-project.org/logram/branches/work
pour obtenir le code de la version de développement de Setup (le trunk contient encore uniquement le DE, en attendant que Setup soit fonctionnel, et qu'il rejoigne le trunk).
[^] # Re: Mon rêve...
Posté par steckdenis (site web personnel) . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 1.
setup --install llibs:binary --uses -panache-plugins,+tests
n'installe pas les plugins Panache contenus dans le paquet binaire llibs (et ne les télécharge même pas).
setup --install llibs=devel:source --uses -kde,+tests
Télécharge depuis le dépôt SVN le code des bibliothèques Logram, les compile avec les USE flags sélectionnés, et installe le tout. Dans /tmp/lgrpackages/llibs_pkg, il y a un fragment de lbuild ainsi que les archives binaires compressées en LZMA qui sont prêts à l'envoi :) !
pkgassistant --console /le/chemin/d'un/Makefile/CMakeLists.txt/autre
À venir, mais construira le paquet d'un répertoire contenant les sources (ma version de dev réussi à compiler X-Moto !). Il suffit de retirer "--console" pour avoir une magnifique GUI. J'ai une vidéo de 40 Mio à envoyer, si quelqu'un la veut.