Le projet suivant est de fignoler le tout et de rendre Logram viable. Pour le moment, j'ai mon dépôt Setup perso en local, sur une partition dédiée, et c'est assez difficile à gérer (exemple, j'ai passé OpenSSL en version 1, et sa SOVERSION a changé. J'ai du GREPer tous les metadata.xml en ma possession pour voir ceux qui en dépendant et qui doivent donc être recompilés).
J'ai réservé le reste des vacances à la réalisation d'un «OpenSuSE Build Service-like», mais plus simple, et n'utilisant pas Ruby (par souci de consommation de RAM, je ne laisse tourner qu'un langage sur le serveur de Logram, et c'est Python pour le moment).
Ça permettra d'automatiquement reconstruire les paquets dépendant d'un autre, ayant changé de version, et ça me permettra également de peaufiner l'intégration entre Setup, le site web, et le démon de construction (pas encore réalisé celui-là).
Ensuite, de nouveaux paquets, dont KDE. Finalement, on s'intéressera aux artworks. Le champs est encore libre (faut juste utiliser le logo Logram, du bleu clair crème comme sur le site, et un peu de vert), donc j'accepte l'aide de tout graphiste voulant mettre un peu de sa personnalité dans Logram. Utilisez le forum de Logram pour cela (aspect communautaire, on n'a pas de liste de diffusion et m'envoyer des mails en privé cache trop de choses aux membres, qui ne savent pas donner leur avis).
Pour Logram DE, je laisse carte blanche aux mainteneurs actuels. J'avais au mois d'avril précédant commencé une version 2, ne contenant alors que de nouvelles bibliothèques (mais des belles, comme une gestion des icônes magnifiques avec des effets, repris de KDE, et la gestion des chemins d'accès, utilisant un fichier de description pour trouver les fichiers). Ils portent actuellement Panache vers ces bibliothèques, ce qui va prendre un peu de temps (au passage, on se débarrasse des LIO qui n'était utile que jusqu'à Qt 4.4, sachant que Qt 4.5 puis 4.6 ont intégré l'excellent QNetworkAccessManager permettant de gérer tout ce qu'on veut, facilement).
Pacman a bien évolué. Je n'en sais rien pour la sécurité, mais le problèmes des multiples paquets binaires créés à partir d'un paquet source a été résolu d'une manière très élégante (un peu comme j'avais fait dans Setup 0.1-alpha0, donc avec un petit hack dans les scripts bash).
Avant de lancer Setup, je m'étais renseigner sur Pacman. Pas de dépendances inverses, des trucs qui manquent, etc. Finalement, j'utilise Chakra, basée sur Arch Linux, depuis 6 mois, et c'est un pur bonheur. L'installation des paquets est aussi rapide que celle de Setup, le tout marche toujours bien, est stable, et rapide.
Bref, si je n'avais pas lu des trucs faux sur Pacman, je n'aurais peut-être jamais lancé le projet Setup. Heureusement, Setup apporte des choses comme les Communications, et le fait que la bibliothèque fonctionne aussi bien avec un front-end graphique qu'avec une application console (libalpm a corrigé le tir pour ça aussi, quoique quand je vois Shaman 2, je me dis qu'il y a encore trop de boulot fait dans le client par rapport à ce qui est demandé).
1) Tu as raison, absolument raison. OpenSuSE, Chakra, Kubuntu, tout ce petit monde empaquette KDE, Xorg, etc, et on ne peut se différencier que par les options de compilation (Qt compilé avec le moteur raster, voir mon journal «En finir avec la lourdeur de KDE», tous les paquets sont compilés en -march=pentium3 au lieu de -march=i686, ce qui apporte le support SSE pour tout le monde (énorme gain de performance dans le multimédia))
2) La aussi, Arch le fait déjà.
3) Mais ces deux points sont justifiés par le 3ème, qu'on peut résumer en version très courte : «Un nouveau gestionnaire de paquets => refaire les paquets => définition même d'une distribution». En clair, Setup n'installe pas les paquets Debian (il lui faut son propre format, évolutif et au goût du jour, pour apporter ce qu'il apporte). Il faut donc refaire tous les paquets.
Alors là, soit on «porte» les paquets Debian, en essayant d'y apporter le plus possible en y enlevant le moins possible, soit on réempaquette tout.
La deuxième solution a été choisie, d'une part pour son côté éducatif, d'autre part pour avoir le contrôle (compilation Pentium 3, choix des options de compilation, choix des dépendances utilisées, plaisir de hacker de grand projets comme GRUB et de créer des patches d'intégration, mes premiers patchs de logiciel libre :D ). Il y a aussi le fait, et il faut l'avouer, que c'est toujours agréable un truc du genre :
«Tu fais quoi ?
- Je crée une distribution Linux. (suivi d'explications sur ce qu'est Linux, etc)
Je peux voir ?
- Ok, pas de problème, j'ai un flashdisk USB avec Logram dessus.
*** Le LiveUSB démarre en 7 secondes dans VirtualBox ou sur un netbook. L'autre personne découvre un thème ensoleillé, je tape le mdp root, un court écran de chargement arrive, puis je peux faire une démonstrations des languettes et du menu rond.»
Tout ça, on sait le faire en installant Logram DE sur une Ubuntu. Mais où est le plaisir de montrer l'interface de Setup ? Où est la joie de taper «mysql -u root -p» et d'arriver dans un MySQL qui marche ? Quelle est la saveur du navigateur web d'exemple venant avec Qt, seul navigateur pour Logram pour le moment ?
C'est donc par amour pour les choses bien faites que j'ai créé cette distribution, parce que j'aime, parce que les autres aiment aussi (j'espère). Peut-être que dans quelques temps, Logram sera connu comme Chakra (pas très connu, mais quand on dira «Chakra», on verra une belle distrib Linux qui donne envie d'être testée, voire utilisée).
PS: Et c'est un des commentaires les moins trollesques que j'ai pu voir sur Linuxfr.
Je n'ai pas de chiffres, mais la Belgique doit être bien placée aussi.
Il y a quelques jours, mon professeur de Néerlandais (une langue parlé par ~60% des belges) a amené un enregistrement d'une émission radio néerlandophone parlant justement de ces navigateurs.
Et bien, je n'en reviens toujours pas ! Pas de FUD, pas de pro-MS, pas d'approximations. Non ! Ce sont des professeurs d'informatique qui viennent parler de Google Chrome, Mozilla FireFox, Opera, Internet Explorer et Apple Safari.
Internet Explorer en a bien pris pour son grade (il commet des «erreurs d'affichage des pages web», il attire le spam (o_O), etc). FireFox a été mis en avant ... comme étant Libre ! Oui, le Libre arrive au grand-publique. Une charmante jeune femme a parlé pendant près de 10 minutes des avantages du libre (qualité supérieure, confiance qu'on peut avoir en les données, adaptation facilité, etc). Chrome a été élu navigateur le plus rapide.
S'en est suivi un débat en classe, durant lequel j'ai pu un peu informer les gens (non, Google ne fait pas partie du web, Internet Explorer n'est pas «Internet», et accessoirement le nom des différentes moteurs de rendu parce que l'interview avait parlé de «technologies d'affichage» que personne n'avait compris). Ils savent maintenant un peu mieux ce qui tournent sur leur ordinateur.
Le tout fait en une semaine de cours (4 heures par semaine, ce n'est pas beaucoup, mais on en parlait aussi hors du cours de néerlandais).
Voilà, 17 jeunes élèves ont maintenant les yeux un peu plus ouverts sur les technologies du web, et le libre.
PS: Par contre, si vous devez un peu parler comme ça aux gens, surveillez votre manière d'être pour ne pas paraître «anti-tout» (Google pue, MS pue, Windows pue, Apple pue, les fabriquants de matériels puent, nous on est gentil on est beau mais pas respectés), c'est la meilleure manière de perdre son auditoire. Heureusement, c'est une faute que je n'ai pas commis (j'avais eu l'occasion quelques jours plus tôt de traiter, toujours en néerlandais, d'un article «Apple accusé de censure», parlant d'un forum internet fermé par apple parce qu'on y apprenait à installer des applications non-autorisées sur son iPod. La majorité de la classe est équipée Apple, et en a profité pour bien s'en plaindre. Un élève a failli demander de sortir, parce qu'il aimait bien Apple, c'est dire ce qu'il s'est passé !)
Dans le journal « Performances comparées de Javascript sous divers environnements», il y avait le score d'un benchmark Javascript avec IE 8 dedans. Il a eu 6000 au minimum.
Dans ce benchmark, FireFox avait 1403. Mon FireFox, à ce test, a eu 1600, donc un peu plus. Mon Konqueror a eu 4500-5000, je ne sais plus, c'est à dire à peine plus lent qu'IE8 comparé au reste (donc largement plus lent que Chrome ou FireFox).
KJS est donc bien le moteur Javascript libre le plus lent, si j'en crois ces tests. Heureusement que le moteur HTML est lui relativement rapide.
Et puisqu'on parle de KHTML, je trouve dégoûtant ce qu'à fait Apple en le forkant si brutalement, en larguant KHTML. Car on peut dire ce qu'on veut, je troue KHTML bien meilleur (meilleur respect des standards, meilleure intégration à KDE, bien plus prévisible dans tout ce qui est sélections, dessins plus jolis (arrondis des cadres, intégration des KParts pour afficher les contenus embed et objects (vidéos, SVG, PDF, autres pages, etc) etc), rendu un peu plus "chaud", bref, je préfère :) ).
* Les plasmoides contiennent des applets tout simples, accomplissant une seule et unique petite tâche (notes, affichage d'une page web). Leur but est d'avoir rapidement plein d'informations disponibles quand aucune fenêtre ne recouvre le bureau, sans prendre trop de place
* Les applications fournissent un environnement complet, avec des menus, barres d'outils, etc.
De l'autre côté :
* Les onglets des applications contiennent un même type de documents, fondus dans la même application, le même processus généralement. Tout élément du menu peut s'appliquer à n'importe quel onglet (petite exception : Konqueror avec ses KPart, mais ça va encore).
* Les onglets de KWin rassemblent des applications différentes n'ayant pas conscience des autres avec lesquelles elles sont regroupées. On peut grouper des applications totalement différentes.
* La barre des tâches contient en un endroit centralisé les applications ouvertes, pouvant être sur d'autres bureaux virtuels (on peut choisir d'afficher ou pas les fenêtres des autres bureaux). Qu'elles soient groupées ou non, la barre des tâches ne changera et contiendra toujours les mêmes entrées.
De plus, la barre des tâches affiche les fenêtres réduites, ainsi que plein d'autres machins (aperçus, état).
Au final, je trouve justement que chaque élément a sa place et se complète. Fini les petites applis stupides qui occupent une fenêtre pour un rien (gestionnaire de téléchargements par exemple), elles vont dans un plasmoïde, soit sur le bureau, soit dans un panel pour l'afficher tout le temps, soit dans le dashboard pour ne l'afficher que de temps en temps.
Les grosses applis gardent leurs fenêtres, et sont bien organisées. Regroupées par thèmes dans les bureaux virtuels et par activité dans les onglets KWin (bureau : développement web. Onglets kwin : l'éditeur de texte et la prévisualisation dans un navigateur web léger), on les retrouve facilement.
Et puis, ces onglets sont encore assez jeunes et changeront peut-être, quoiqu'ils sont déjà très bien :) .
La naissance des trolls genre «KDE est trop compliqué, super geek, etc». Les devs l'avouent eux-même, ils ajoutaient fonctionnalités sur fonctionnalités et essayant de garder le tout propre, mais sans en faire une priorité. Avec KDE 4, ils ont essayé de mieux présenter les fonctionnalités et de travailler l'ergonomie.
Regarde un screenshot de KDE 3.5 et un de KDE 4.3, tu verras la différence. Compare avec un screen de GNOME, et tu verras d'où viennent les trolls. KDE 3.5 utilise des couleurs flashes, avec les boutons Keramic pas super jolis (ou alors Plastik un peu plus vieillot). D'un autre côté, on avait à cette époque GNOME 2.22 et 2.24, avec un thème simple, léché et épuré. KDE 4.0 est venu avec Oxygen, et une interface bien plus simple (mais c'est parce qu'il y avait moins de fonctionnalités). Maintenant, avec KDE 4.4, il y a plein de fonctionnalités, et une interface toujours claire à utiliser.
Enfin, c'est ce que je peux tirer de l'analyse de trolls qu'on peut trouver dans les dépêches des sorties de KDE 3.x et de GNOME, ça revient très souvent.
Je veux bien que les administrateurs passent ce journal en dépêche, s'ils le jugent utile (après tout, c'est une simple astuce que j'ai développée pour pouvoir la mettre en journal, pour que plus de monde la voient et arrêtent de troller sur la lourdeur de KDE).
Je ne suis absolument pas certain de ce que j'avance, mais il me semble que GTK étant un peu plus ancien et un peu plus sobre, il utilise la XLib directement pour le dessin, donc pas XRender, ni un raster.
Ça évite les problèmes de Raster, ça n'est pas trop lent quand XRender traîne, mais c'est relativement lent en général (même si c'est léger, les UI GTK étant relativement simple et les thèmes épurés, on ne le remarque pas trop. Certaines personnes se plaignent de ça en parlant d'Evolution qui traîne à se redessiner).
Il me semble que là où ça tourne bien, c'est soit quand XRender n'est pas supporté (pilote VESA, et où on utilise alors Raster en fallback), soit quand tu as un bon pilote qui gère bien XRender et un processeur rapide.
Mais c'est quasiment aléatoire, donc c'est mieux d'utiliser Raster en dur pour savoir que ça marchera chez tout le monde (pensée spéciale «créateur de distribution» ici :-) ).
Pour savoir quel est le backend utilisé, je ne sais pas si c'est possible. Ça m'a d'ailleurs embêté lorsque j'ai ajouté la NOTE sur le test de Kwin, car je voyais que ça réagissait bien (donc comme si XRender était utilisé), donc j'ai du lancer une application en OpenGL (parce que c'est moche et lent, et que je vois que -graphicssystem est bien passé), puis à nouveau en Raster explicite pour voir que Raster s'est bien amélioré.
Mais normalement, si c'est fluide tout le temps (sans saccades), alors c'est du raster.
Sans vouloir me faire de la pub, je signale que http://www.logram-project.org utilise Django, donc ça montre ce qu'on sait en faire (forum, wiki, pastebin, news, utilisateurs, téléchargements, etc). C'est à peu près tout ce qu'on peut trouver dans un gros site web.
De plus, ce site web est disponible sous GPLv3 (Affero GPLv3 à partir de ce week-end, donc faut se dépêcher pour faire des magouilles avec :P ), et je reste disponible pour de l'aide (mais faut avoir bien cherché avant de me demander, je suis très occupé. steckdenis chez logram tiret project point org).
La documentation officielle est très bien développée, le site django-snippets est excellent, on trouve une belle blogosphère autour, et c'est rapide, très rapide (j'ai eu l'occasion de tester RoR, c'est horrible ce machin, à peu près 3s pour générer une page toutes les ~100 pages, même si c'est 0,1 seconde par page ensuite).
Sur mon Kimusufi 2XL (Un P4 mono-core hyper threading 3,2Ghz, 2Gio de RAM), avec le serveur web Nginx (que je conseille : configuré en 20 minutes en comptant la lecture de la doc, ça marche, c'est simple, puissant et rapide), je peux obtenir facilement 40 pages par seconde aux endroits complexes, une petite centaine sur les pages simples avec des templates simples. Nginx sur les fichiers statiques monte facilement à 16 000 pages par seconde !
Bref, Django est la voie, et en une semaine, on maîtrise le bazar (expérience perso, et en plus, j'ai appris le Python en même temps que Django, comme quoi les deux sont simples et puissants).
Un peu avant la sortie de Setup 0.1-alpha1, il était prévu de rassembler Sepa et Repoma (outils de création de paquets et de gestion des dépôts) dans Setup. Ceci amenait plusieurs avantages :
* Pour Sepa, sachant que c'est dans la liblpackage, la création de paquet est facilité et un greffon KDevelop est envisageable. C'est typiquement un truc qui plaît au décideur pressé, un IDE qui permet de faire de l'élaboration à la distribution d'un projet
* Pour Repoma, le C++ est largement plus puissant que le bash, et permet par exemple de gérer une base de donnée SQL en utilisant QtSql
C'est ce dernier point qui est intéressant, car cette base de donnée peut servir à conserver plein d'informations, donc les deltas, leurs versions, etc.
Du côté de l'arbre du dépôt, les informations de deltas seront ajoutées au fichier packages.xz, sous la forme
Ainsi, quand on a la version source et la version cible, Setup peut calculer les deltas qu'il appliquera, s'il doit en appliquer plusieurs, et dans quel ordre. Par exemple, pour passer de la version 1.1 à la version 1.4 du paquet proposant ceci :
Deltas=1.1~1.2 1.1~1.3 1.2~1.3 1.2~1.4 1.3~1.4
Setup sait qu'il doit par exemple appliquer 1.1~1.3 puis 1.3~1.4. Voilà, le dépôt n'est pas pollué par trop de deltas, mais l'utilisateur sera toujours facilement à jour :) .
Une solution possible serait de tester d'autres suites office libres qui savent lire les fichiers MS. Bon, il n'y en a pas beaucoup, mais KOffice s'en sort bien (et j'ai vu un comparatif sur kdedevelopers qui montre qu'il s'en sort d'ailleurs mieux que OpenOffice.org).
Et si tu n'aimes pas KOffice, il te suffit de ré-enregistrer en .odt, d'ouvrir dans OOo, de modifier, et d'exporter dans le format MS qui va bien.
Une solution trouvée ici : http://www.simmoril.com/blog/?p=293 semble très intéressante. Elle semble avoir une complexité O(n²), et utilise la récursivité ainsi que plein de listes (mais celui ayant codé ça en Python, il ne l'a peut-être pas vu, ou il s'en fiche un peu). Néanmoins, c'est déjà mieux que rien si je ne trouve rien de mieux.
Je n'ai pas encore eu la possibilité de tester ce que j'ai trouvé, mais c'est bien plus complet que le petit morceau que je demande ici. La particularité de mon algorithme est qu'il a une petite chance de produire les patches les plus petits possibles, ou en tous cas de s'en approcher fortement.
En effet, les algos existants éliminent des données, comme la thèse que je donne plus haut qui contient un truc du genre «Si le bloc ne correspond pas à plus de 50%, faire comme s'il ne correspond pas, car il y a des chances qu'il ne corresponde pas».
Je me concentre sur la petitesse du patch, par sur la rapidité. J'ai déjà sorti des artilleries très lourdes pour préparer cette liste de blocs, mais pour le moment, ça va (moins d'une seconde pour les premières passes du delta d'un fichier de 300Kio).
L'application du patch est déjà codée (avec des patchs faits-mains), et est de complexité O(taille du patch), alors que bsdiff applique les patches en O(m+n), avec m et n les tailles des anciens nouveau fichiers.
Ce problème de blocs est vraiment le dernier truc que je dois résoudre. Je planche sur ce diff depuis un mois maintenant (il n'y à qu'à regarder de quand cesse le dernier gros commit de Setup, ici la sortie de l'alpha1), c'est bientôt fini.
Merci beaucoup, c'est effectivement très proche de ce que je cherche. Malheureusement, les gens qui résolvent ce puzzle ne devraient pas spécialement vouloir que le secret soit révélé, et le résoudre moi-même consisterait à résoudre mon problème, donc ça ne m'avance pas.
Merci beaucoup tout de même :-) . Ça m'apprend que ça doit pouvoir se résoudre en O(n).
Ça passe impeccablement sous GCC 4.4, en -Wall -Werror. Pour infos, voici un extrait des erreurs :
/usr/include/QtCore/qlist.h:113: undefined reference to `shared_null'
cache.o: In function `QList::at(int) const':
/usr/include/QtCore/qlist.h:439: undefined reference to `qt_assert_x'
cache.o: In function `QByteArray::~QByteArray()':
/usr/include/QtCore/qbytearray.h:382: undefined reference to `qFree'
cache.o: In function `QString::QString()':
/usr/include/QtCore/qstring.h:868: undefined reference to `shared_null'
cache.o: In function `QList<Logram::Depend*>::at(int) const':
/usr/include/QtCore/qlist.h:439: undefined reference to `qt_assert_x'
cache.o: In function `QList<Logram::ChangeLogEntry*>::detach_helper()':
/usr/include/QtCore/qlist.h:608: undefined reference to `qFree'
cache.o: In function `QList<Logram::ChangeLogEntry*>::free(QListData::Data*)':
/usr/include/QtCore/qlist.h:649: undefined reference to `qFree'
cache.o: In function `QList<Logram::Package*>::detach_helper()':
/usr/include/QtCore/qlist.h:608: undefined reference to `qFree'
cache.o: In function `QList<Logram::Package*>::free(QListData::Data*)':
/usr/include/QtCore/qlist.h:649: undefined reference to `qFree'
cache.o: In function `QList<Logram::Depend*>::free(QListData::Data*)':
/usr/include/QtCore/qlist.h:649: undefined reference to `qFree'
cache.o:/usr/include/QtCore/qlist.h:608: more undefined references to `qFree' follow
cache.o: In function `QString::QString(QString const&)':
/usr/include/QtCore/qstring.h:715: undefined reference to `qt_assert'
cache.o: In function `QList::free(QListData::Data*)':
/usr/include/QtCore/qlist.h:649: undefined reference to `qFree'
C'est donc LD qui génère ça, et ça ne se produit pas avec GCC. La liste est un peu plus longue mais ne contient pas tous les symboles de Qt, de plus, voici la ligne de commande :
À la vue des "+++" et "---" de ton journal, je ne peux que te conseiller de tester GoboLinux avec un joli KDE dessus :
* Les applications sont installées dans un arbre de fichiers "à la Windows", mais en encore mieux
* T'as une barre des tâches comme t'aimes bien, avec groupement des fenêtres, et surtout, tu sais en changer (STasks fonctionne comme celle de Windows 7, si tu aimes). Il existe même des thèmes Plasma et des packs d'icônes pour transformer KDE en Windows 7, si tu en as envie
* Je n'ai pas testé l'installation de GoboLinux, mais ça devrait ne pas être trop difficile
* C'est du Linux, donc le système n'est pas opaque.
Comme quoi, il y a toujours de nouveaux horizons à découvrir partout :) .
L'environnement de bureau est maintenant maintenu par trois lascars, pendant justement que j'essaie d'aider KDE comme je peux : patches, troll^W promotion (mes journaux avec les screenshots), nouvelles, et surtout ma distribution visant à le remettre là où il doit, c'est à dire en première place. Je compte d'ailleurs utiliser le meilleur dedans, donc il se pourrait que je sois amené à le coder ce foutu backend Solid, ou l'intégration Plymouth->KDM, ou le support d'OSSv4 dans Phonon, etc.
Ok, je n'ai pas encore beaucoup de choses à mon actif, mais j'ai déjà soufflé quelques mots au développeur de Shaman 2, un gestionnaire de paquets à la packagekit (il est d'ailleurs compatible avec ce dernier) pour KDE.
Je bêta-test KOffice aussi, parce que ce truc a largement plus d'avenir que le clone de MS Office qu'est OpenOffice.org. KOffice est largement plus révolutionnaire, et quand il ne plante pas, un plaisir à utiliser (amusez-vous à mettre plein de graphismes vectoriels et à faire de la POO dans KWord, tout est à sa place, même des frames qui créent des nouvelles pages quand elles sont remplies).
Effectivement, mais j'en ai profité pour dénoncer le GNOME-centrisme que le Libre commence à prendre.
J'utilise KDE, j'aime KDE, c'est quelque-chose de très bien fait, mais j'ai de plus en plus l'impression d'être mis à l'écart, car de plus en plus de choses sont développées pour GNOME, sans se soucier de KDE.
Certaines choses sont la faute des devs de KDE, comme DeviceKit qui n'est pas très bien supporté par Solid, mais on peut aussi mettre la faute sur les entreprises qui préfèrent payer des devs pour travailler sur GNOME plutôt que KDE.
KDE a peut-être fait des erreurs, en se liant trop à Trolltech puis à Nokia, mais on ne peut pas dire que ce soit difficile de développer pour eux. Un compte SVN s'obtient en 20 minutes, et on a quasi carte blanche sur tout le dépôt. Des outils super sont en place, comme la doc Doxygen, le lxr.kde.org, techbase, les forums, les mailing-lists, etc.
Mais néanmoins, malgré que KDE soit super ouvert sur les contributions, personne ne s'attaque à ce dont KDE a besoin.
Oui, on a Plasma, plein de petits jeux, KOffice, et tout un tas de super bonnes applications. La partie «haute» est on ne peut plus complète, ce qui manque est la partie basse. Comme je le dis plus haut, on a un support DeviceKit plus que douteux, qui a fait l'objet de deux commits (ok, des gros) il y a quelques mois, et qui se morfond maintenant dans branches/work. Ce n'est que récemment, très récemment que KMix supporte PulseAudio.
En fait, pour constater le déséquilibre, il n'y à qu'à voir ce qu'on trouve de chaque côté :
* Pour GNOME, il y a RedHat qui paie des gens, Canonical qui développe de petits machins et qui mettent GNOME à la mode (pour ceux que je connais, Linux = Ubuntu = GNOME = largement en arrière par rapport à Windows 7 :( ). Tous ceux qui développent une technologie l'intègrent à GNOME, les GUI de configuration de KVM, MySQL Workbench, des trucs comme FireFox justement, et des centaines de grosses applis
* Pour KDE, il y a juste Nokia et SuSE. Le reste est assuré purement par des bénévoles, et pas beaucoup (Okular est quasi abandonné, Ark aussi, une vague d'applis on du être mises dans le tag unmaintained). Côté distrib, il y a juste OpenSuSE, Mandriva et les petits genre Chakra, Pardus, etc.
Ça me donne l'impression que KDE est développé à l'ombre de GNOME. Oui, GNOME est excellent, et je n'en garde que de bons souvenirs : simple, élégant, efficace. Mais il faut absolument éviter de tuer la concurrence, car on est dans un cercle vicieux : plus les gens développent pour GNOME, mieux GNOME est, donc plus il attire de gens.
(si on avait été vendredi, j'aurais ajouté qu'en plus GNOME n'aurait pas du exister, du moins plus après la libération de Qt sous GPL, mais c'est un pas que je ne franchirai pas).
encore une preuve que le support des systèmes libre par la fondation Mozilla n'est pas une priorité.
Non, la mozilla essaie de faire pour le mieux. Seulement, comme je dis de temps en temps dans les quelques trolls velus que je lance les vendredis, pour beaucoup de gens, «intégration à Linux» veut dire «intégration à GNOME» :-( . (exemples : DeviceKit qui dépend de la glib, packagtkit qui maintient gnome-packagekit et pas kpackagekit, OSS qui vient avec un mixeur GTK, le kernel qui peut se configurer en GTK2 ou en Qt ... 3, cairo et autres technos GNOME dans Freedesktop, pendant que Akonadi se fait refuser alors qu'il est pleinement utilisable sous GNOME)
Donc, chez Mozilla, ils se sont peut-être dis qu'ils aimeraient une bonne intégration. Un dev proche des entreprises pro-GNOME genre RedHat ou Novell aurait alors dit «Pour une bonne intégration, il faut utiliser gnome-vfs». Surtout qu'appeler xdg-open est peut-être perçu comme un hack permettant d'utiliser gnome-vfs en console, ou que sais-je.
Freedesktop, c'est comme KDE et Debian : trop communautaire, pas assez entreprise pour certains.
Défoulez-vous sur ce post, je suis préparé au -10 :) .
K»Configuration du système, puis bouton «Apparence», partie «Polices», mettre «Forcer le PPP des polices» sur 120PPP, normalement c'est ça.
Sinon, tu changes manuellement la taille des polices (liste au dessus) pour que ce soit lisible.
Pas de prob avec de bonnes applis Qt qui utilisent des layouts, c'est fait pour ça. Je ne garantis rien pour GTK :-° .
Icônes
À nouveau, K»Configuration du système, cliquer sur «Apparence», ensuite sur «Icônes», puis sur l'onglet «Avancé». Ensuite, pour chaque entrée de la liste, choisir la taille que tu veux. Par exemple, prendre «Bureau» et mettre une taille de 64 au lieu de 48 te donnera un bureau lisible.
Bordures de fenêtres (KDE 4.4 seulement) ou décorations Nitrogen
Cliquer sur la partie «Fenêtres», puis s'assurer que le thème Oxygen est bien utilisé.
Ensuite, explorer les petits onglets à la recherche de «Taille des boutons de la fenêtre», et les mettre en «gros» ou «très gros». Les boutons (croix, agrandir, réduir, etc) seront plus gros, la barre de titre aussi.
Voilà ! Utilisez KDE, vous dis-je. Ça se configure bien et ça marche bien :) .
Il y a déjà tous les flux RSS qu'on peut vouloir sur le site (y compris les derniers paquets, c'est dire).
Ensuite, il n'y a pas énormément de journaux par jour sur Linuxfr, et je vise toujours dans une période creuse (donc pas juste après une dépêche de patrick_g, une grosse sortie, mais plutôt quand le week-end commence, quand on a parlé de cinéma, etc). Et je n'oblige personne à lire mes journaux, il existe même un script pour les cacher (maintenant que j'ai vu ça, je vais le ressortir tout le temps).
Et puis, moi j'aimerais bien avoir des nouvelles ici des sorties de Wormux, G'MIC, et autres. Ce sont des projets que j'aime beaucoup et qui sont très intéressants.
Et puis, Setup, c'est tout de même un gestionnaire de paquets. Si j'avais pu voir naître APT, ou autre, j'aurais été très heureux. Malheureusement, même en cherchant dans les archives de Linuxfr, il ne reste plus aucune trace de cette époque, et c'est bien dommage.
De plus, il ne faut pas trop se fier aux titre alpha/beta/etc. Certes, Setup n'est pas avancé, mais la quantité de changements depuis l'alpha0 est quasi aussi importante que ce qu'on trouve entre deux versions majeures d'autres projets, qui se développent doucement. La version 0.1 finale de Setup commence bien par un zéro, mais c'est un zéro "à la enlightenment", donc un zéro pour dire que le dev n'est pas satisfait du machin. Vous pouvez sans problèmes considérer Setup 0.1-alpha1 comme Setup 1.1, l'alpha 0 comme Setup 1.0. Dans ce cas, ce sont des versions largement plus intéressantes :) .
Merci en tous cas de m'explique pourquoi un journal sur Setup recoit d'abord 39, puis -5.
[^] # Re: La suite
Posté par steckdenis (site web personnel) . En réponse à la dépêche Le projet Logram fête ses deux ans. Évalué à 4.
Le projet suivant est de fignoler le tout et de rendre Logram viable. Pour le moment, j'ai mon dépôt Setup perso en local, sur une partition dédiée, et c'est assez difficile à gérer (exemple, j'ai passé OpenSSL en version 1, et sa SOVERSION a changé. J'ai du GREPer tous les metadata.xml en ma possession pour voir ceux qui en dépendant et qui doivent donc être recompilés).
J'ai réservé le reste des vacances à la réalisation d'un «OpenSuSE Build Service-like», mais plus simple, et n'utilisant pas Ruby (par souci de consommation de RAM, je ne laisse tourner qu'un langage sur le serveur de Logram, et c'est Python pour le moment).
Ça permettra d'automatiquement reconstruire les paquets dépendant d'un autre, ayant changé de version, et ça me permettra également de peaufiner l'intégration entre Setup, le site web, et le démon de construction (pas encore réalisé celui-là).
Ensuite, de nouveaux paquets, dont KDE. Finalement, on s'intéressera aux artworks. Le champs est encore libre (faut juste utiliser le logo Logram, du bleu clair crème comme sur le site, et un peu de vert), donc j'accepte l'aide de tout graphiste voulant mettre un peu de sa personnalité dans Logram. Utilisez le forum de Logram pour cela (aspect communautaire, on n'a pas de liste de diffusion et m'envoyer des mails en privé cache trop de choses aux membres, qui ne savent pas donner leur avis).
Pour Logram DE, je laisse carte blanche aux mainteneurs actuels. J'avais au mois d'avril précédant commencé une version 2, ne contenant alors que de nouvelles bibliothèques (mais des belles, comme une gestion des icônes magnifiques avec des effets, repris de KDE, et la gestion des chemins d'accès, utilisant un fichier de description pour trouver les fichiers). Ils portent actuellement Panache vers ces bibliothèques, ce qui va prendre un peu de temps (au passage, on se débarrasse des LIO qui n'était utile que jusqu'à Qt 4.4, sachant que Qt 4.5 puis 4.6 ont intégré l'excellent QNetworkAccessManager permettant de gérer tout ce qu'on veut, facilement).
J'espère avoir répondu à tout.
[^] # Re: pourquoi ? (troll inside)
Posté par steckdenis (site web personnel) . En réponse à la dépêche Le projet Logram fête ses deux ans. Évalué à 4.
Avant de lancer Setup, je m'étais renseigner sur Pacman. Pas de dépendances inverses, des trucs qui manquent, etc. Finalement, j'utilise Chakra, basée sur Arch Linux, depuis 6 mois, et c'est un pur bonheur. L'installation des paquets est aussi rapide que celle de Setup, le tout marche toujours bien, est stable, et rapide.
Bref, si je n'avais pas lu des trucs faux sur Pacman, je n'aurais peut-être jamais lancé le projet Setup. Heureusement, Setup apporte des choses comme les Communications, et le fait que la bibliothèque fonctionne aussi bien avec un front-end graphique qu'avec une application console (libalpm a corrigé le tir pour ça aussi, quoique quand je vois Shaman 2, je me dis qu'il y a encore trop de boulot fait dans le client par rapport à ce qui est demandé).
[^] # Re: pourquoi ? (troll inside)
Posté par steckdenis (site web personnel) . En réponse à la dépêche Le projet Logram fête ses deux ans. Évalué à 3.
1) Tu as raison, absolument raison. OpenSuSE, Chakra, Kubuntu, tout ce petit monde empaquette KDE, Xorg, etc, et on ne peut se différencier que par les options de compilation (Qt compilé avec le moteur raster, voir mon journal «En finir avec la lourdeur de KDE», tous les paquets sont compilés en -march=pentium3 au lieu de -march=i686, ce qui apporte le support SSE pour tout le monde (énorme gain de performance dans le multimédia))
2) La aussi, Arch le fait déjà.
3) Mais ces deux points sont justifiés par le 3ème, qu'on peut résumer en version très courte : «Un nouveau gestionnaire de paquets => refaire les paquets => définition même d'une distribution». En clair, Setup n'installe pas les paquets Debian (il lui faut son propre format, évolutif et au goût du jour, pour apporter ce qu'il apporte). Il faut donc refaire tous les paquets.
Alors là, soit on «porte» les paquets Debian, en essayant d'y apporter le plus possible en y enlevant le moins possible, soit on réempaquette tout.
La deuxième solution a été choisie, d'une part pour son côté éducatif, d'autre part pour avoir le contrôle (compilation Pentium 3, choix des options de compilation, choix des dépendances utilisées, plaisir de hacker de grand projets comme GRUB et de créer des patches d'intégration, mes premiers patchs de logiciel libre :D ). Il y a aussi le fait, et il faut l'avouer, que c'est toujours agréable un truc du genre :
«Tu fais quoi ?
- Je crée une distribution Linux. (suivi d'explications sur ce qu'est Linux, etc)
Je peux voir ?
- Ok, pas de problème, j'ai un flashdisk USB avec Logram dessus.
*** Le LiveUSB démarre en 7 secondes dans VirtualBox ou sur un netbook. L'autre personne découvre un thème ensoleillé, je tape le mdp root, un court écran de chargement arrive, puis je peux faire une démonstrations des languettes et du menu rond.»
Tout ça, on sait le faire en installant Logram DE sur une Ubuntu. Mais où est le plaisir de montrer l'interface de Setup ? Où est la joie de taper «mysql -u root -p» et d'arriver dans un MySQL qui marche ? Quelle est la saveur du navigateur web d'exemple venant avec Qt, seul navigateur pour Logram pour le moment ?
C'est donc par amour pour les choses bien faites que j'ai créé cette distribution, parce que j'aime, parce que les autres aiment aussi (j'espère). Peut-être que dans quelques temps, Logram sera connu comme Chakra (pas très connu, mais quand on dira «Chakra», on verra une belle distrib Linux qui donne envie d'être testée, voire utilisée).
PS: Et c'est un des commentaires les moins trollesques que j'ai pu voir sur Linuxfr.
# Succès belge
Posté par steckdenis (site web personnel) . En réponse au journal IE en dessous de 50% de parts de marché en France. Évalué à 10.
Il y a quelques jours, mon professeur de Néerlandais (une langue parlé par ~60% des belges) a amené un enregistrement d'une émission radio néerlandophone parlant justement de ces navigateurs.
Et bien, je n'en reviens toujours pas ! Pas de FUD, pas de pro-MS, pas d'approximations. Non ! Ce sont des professeurs d'informatique qui viennent parler de Google Chrome, Mozilla FireFox, Opera, Internet Explorer et Apple Safari.
Internet Explorer en a bien pris pour son grade (il commet des «erreurs d'affichage des pages web», il attire le spam (o_O), etc). FireFox a été mis en avant ... comme étant Libre ! Oui, le Libre arrive au grand-publique. Une charmante jeune femme a parlé pendant près de 10 minutes des avantages du libre (qualité supérieure, confiance qu'on peut avoir en les données, adaptation facilité, etc). Chrome a été élu navigateur le plus rapide.
S'en est suivi un débat en classe, durant lequel j'ai pu un peu informer les gens (non, Google ne fait pas partie du web, Internet Explorer n'est pas «Internet», et accessoirement le nom des différentes moteurs de rendu parce que l'interview avait parlé de «technologies d'affichage» que personne n'avait compris). Ils savent maintenant un peu mieux ce qui tournent sur leur ordinateur.
Le tout fait en une semaine de cours (4 heures par semaine, ce n'est pas beaucoup, mais on en parlait aussi hors du cours de néerlandais).
Voilà, 17 jeunes élèves ont maintenant les yeux un peu plus ouverts sur les technologies du web, et le libre.
PS: Par contre, si vous devez un peu parler comme ça aux gens, surveillez votre manière d'être pour ne pas paraître «anti-tout» (Google pue, MS pue, Windows pue, Apple pue, les fabriquants de matériels puent, nous on est gentil on est beau mais pas respectés), c'est la meilleure manière de perdre son auditoire. Heureusement, c'est une faute que je n'ai pas commis (j'avais eu l'occasion quelques jours plus tôt de traiter, toujours en néerlandais, d'un article «Apple accusé de censure», parlant d'un forum internet fermé par apple parce qu'on y apprenait à installer des applications non-autorisées sur son iPod. La majorité de la classe est équipée Apple, et en a profité pour bien s'en plaindre. Un élève a failli demander de sortir, parce qu'il aimait bien Apple, c'est dire ce qu'il s'est passé !)
[^] # Re: Ha bon?
Posté par steckdenis (site web personnel) . En réponse au journal Konqueror un peu plus rapide. Évalué à 8.
Dans ce benchmark, FireFox avait 1403. Mon FireFox, à ce test, a eu 1600, donc un peu plus. Mon Konqueror a eu 4500-5000, je ne sais plus, c'est à dire à peine plus lent qu'IE8 comparé au reste (donc largement plus lent que Chrome ou FireFox).
KJS est donc bien le moteur Javascript libre le plus lent, si j'en crois ces tests. Heureusement que le moteur HTML est lui relativement rapide.
Et puisqu'on parle de KHTML, je trouve dégoûtant ce qu'à fait Apple en le forkant si brutalement, en larguant KHTML. Car on peut dire ce qu'on veut, je troue KHTML bien meilleur (meilleur respect des standards, meilleure intégration à KDE, bien plus prévisible dans tout ce qui est sélections, dessins plus jolis (arrondis des cadres, intégration des KParts pour afficher les contenus embed et objects (vidéos, SVG, PDF, autres pages, etc) etc), rendu un peu plus "chaud", bref, je préfère :) ).
[^] # Re: Deux vidéos pour voir KDE en fonctionnememt
Posté par steckdenis (site web personnel) . En réponse au journal Nouveau KDE.org. Évalué à 5.
* Les plasmoides contiennent des applets tout simples, accomplissant une seule et unique petite tâche (notes, affichage d'une page web). Leur but est d'avoir rapidement plein d'informations disponibles quand aucune fenêtre ne recouvre le bureau, sans prendre trop de place
* Les applications fournissent un environnement complet, avec des menus, barres d'outils, etc.
De l'autre côté :
* Les onglets des applications contiennent un même type de documents, fondus dans la même application, le même processus généralement. Tout élément du menu peut s'appliquer à n'importe quel onglet (petite exception : Konqueror avec ses KPart, mais ça va encore).
* Les onglets de KWin rassemblent des applications différentes n'ayant pas conscience des autres avec lesquelles elles sont regroupées. On peut grouper des applications totalement différentes.
* La barre des tâches contient en un endroit centralisé les applications ouvertes, pouvant être sur d'autres bureaux virtuels (on peut choisir d'afficher ou pas les fenêtres des autres bureaux). Qu'elles soient groupées ou non, la barre des tâches ne changera et contiendra toujours les mêmes entrées.
De plus, la barre des tâches affiche les fenêtres réduites, ainsi que plein d'autres machins (aperçus, état).
Au final, je trouve justement que chaque élément a sa place et se complète. Fini les petites applis stupides qui occupent une fenêtre pour un rien (gestionnaire de téléchargements par exemple), elles vont dans un plasmoïde, soit sur le bureau, soit dans un panel pour l'afficher tout le temps, soit dans le dashboard pour ne l'afficher que de temps en temps.
Les grosses applis gardent leurs fenêtres, et sont bien organisées. Regroupées par thèmes dans les bureaux virtuels et par activité dans les onglets KWin (bureau : développement web. Onglets kwin : l'éditeur de texte et la prévisualisation dans un navigateur web léger), on les retrouve facilement.
Et puis, ces onglets sont encore assez jeunes et changeront peut-être, quoiqu'ils sont déjà très bien :) .
[^] # Re: Quel problème
Posté par steckdenis (site web personnel) . En réponse au journal Nouveau KDE.org. Évalué à 10.
Regarde un screenshot de KDE 3.5 et un de KDE 4.3, tu verras la différence. Compare avec un screen de GNOME, et tu verras d'où viennent les trolls. KDE 3.5 utilise des couleurs flashes, avec les boutons Keramic pas super jolis (ou alors Plastik un peu plus vieillot). D'un autre côté, on avait à cette époque GNOME 2.22 et 2.24, avec un thème simple, léché et épuré. KDE 4.0 est venu avec Oxygen, et une interface bien plus simple (mais c'est parce qu'il y avait moins de fonctionnalités). Maintenant, avec KDE 4.4, il y a plein de fonctionnalités, et une interface toujours claire à utiliser.
Enfin, c'est ce que je peux tirer de l'analyse de trolls qu'on peut trouver dans les dépêches des sorties de KDE 3.x et de GNOME, ça revient très souvent.
[^] # Re: merci pour ce journal
Posté par steckdenis (site web personnel) . En réponse au journal En finir avec la lourdeur de KDE. Évalué à 1.
[^] # Re: Et GNOME?
Posté par steckdenis (site web personnel) . En réponse au journal En finir avec la lourdeur de KDE. Évalué à 0.
Ça évite les problèmes de Raster, ça n'est pas trop lent quand XRender traîne, mais c'est relativement lent en général (même si c'est léger, les UI GTK étant relativement simple et les thèmes épurés, on ne le remarque pas trop. Certaines personnes se plaignent de ça en parlant d'Evolution qui traîne à se redessiner).
[^] # Re: Et quand ça marche bien
Posté par steckdenis (site web personnel) . En réponse au journal En finir avec la lourdeur de KDE. Évalué à 5.
Mais c'est quasiment aléatoire, donc c'est mieux d'utiliser Raster en dur pour savoir que ça marchera chez tout le monde (pensée spéciale «créateur de distribution» ici :-) ).
Pour savoir quel est le backend utilisé, je ne sais pas si c'est possible. Ça m'a d'ailleurs embêté lorsque j'ai ajouté la NOTE sur le test de Kwin, car je voyais que ça réagissait bien (donc comme si XRender était utilisé), donc j'ai du lancer une application en OpenGL (parce que c'est moche et lent, et que je vois que -graphicssystem est bien passé), puis à nouveau en Raster explicite pour voir que Raster s'est bien amélioré.
Mais normalement, si c'est fluide tout le temps (sans saccades), alors c'est du raster.
[^] # Re: Django
Posté par steckdenis (site web personnel) . En réponse au journal Choisir un framework web.... Évalué à 2.
De plus, ce site web est disponible sous GPLv3 (Affero GPLv3 à partir de ce week-end, donc faut se dépêcher pour faire des magouilles avec :P ), et je reste disponible pour de l'aide (mais faut avoir bien cherché avant de me demander, je suis très occupé. steckdenis chez logram tiret project point org).
La documentation officielle est très bien développée, le site django-snippets est excellent, on trouve une belle blogosphère autour, et c'est rapide, très rapide (j'ai eu l'occasion de tester RoR, c'est horrible ce machin, à peu près 3s pour générer une page toutes les ~100 pages, même si c'est 0,1 seconde par page ensuite).
Sur mon Kimusufi 2XL (Un P4 mono-core hyper threading 3,2Ghz, 2Gio de RAM), avec le serveur web Nginx (que je conseille : configuré en 20 minutes en comptant la lecture de la doc, ça marche, c'est simple, puissant et rapide), je peux obtenir facilement 40 pages par seconde aux endroits complexes, une petite centaine sur les pages simples avec des templates simples. Nginx sur les fichiers statiques monte facilement à 16 000 pages par seconde !
Bref, Django est la voie, et en une semaine, on maîtrise le bazar (expérience perso, et en plus, j'ai appris le Python en même temps que Django, comme quoi les deux sont simples et puissants).
[^] # Re: Live CD non installable
Posté par steckdenis (site web personnel) . En réponse à la dépêche Sortie de Pardus 2009.1 (Anthropoides virgo). Évalué à 3.
Le programme d'installation est en GTK aussi je crois. Mais sinon, Fedora s'en sort encore bien niveau intégration.
[^] # Re: Réinventer la roue ?
Posté par steckdenis (site web personnel) . En réponse au message [Algorithmie] Aire la plus grande de blocs se superposant. Évalué à 3.
Un peu avant la sortie de Setup 0.1-alpha1, il était prévu de rassembler Sepa et Repoma (outils de création de paquets et de gestion des dépôts) dans Setup. Ceci amenait plusieurs avantages :
* Pour Sepa, sachant que c'est dans la liblpackage, la création de paquet est facilité et un greffon KDevelop est envisageable. C'est typiquement un truc qui plaît au décideur pressé, un IDE qui permet de faire de l'élaboration à la distribution d'un projet
* Pour Repoma, le C++ est largement plus puissant que le bash, et permet par exemple de gérer une base de donnée SQL en utilisant QtSql
C'est ce dernier point qui est intéressant, car cette base de donnée peut servir à conserver plein d'informations, donc les deltas, leurs versions, etc.
Du côté de l'arbre du dépôt, les informations de deltas seront ajoutées au fichier packages.xz, sous la forme
Deltas=version_source~version_cible version_source~version_cible ...Ainsi, quand on a la version source et la version cible, Setup peut calculer les deltas qu'il appliquera, s'il doit en appliquer plusieurs, et dans quel ordre. Par exemple, pour passer de la version 1.1 à la version 1.4 du paquet proposant ceci :
Deltas=1.1~1.2 1.1~1.3 1.2~1.3 1.2~1.4 1.3~1.4Setup sait qu'il doit par exemple appliquer 1.1~1.3 puis 1.3~1.4. Voilà, le dépôt n'est pas pollué par trop de deltas, mais l'utilisateur sera toujours facilement à jour :) .
# KOffice, autres, etc
Posté par steckdenis (site web personnel) . En réponse au journal Déboires avec OpenOffice. Évalué à 1.
Une solution possible serait de tester d'autres suites office libres qui savent lire les fichiers MS. Bon, il n'y en a pas beaucoup, mais KOffice s'en sort bien (et j'ai vu un comparatif sur kdedevelopers qui montre qu'il s'en sort d'ailleurs mieux que OpenOffice.org).
Et si tu n'aimes pas KOffice, il te suffit de ré-enregistrer en .odt, d'ouvrir dans OOo, de modifier, et d'exporter dans le format MS qui va bien.
C'est tout ce que je peux proposer.
[^] # Re: 1D / 2D ?
Posté par steckdenis (site web personnel) . En réponse au message [Algorithmie] Aire la plus grande de blocs se superposant. Évalué à 3.
Une solution trouvée ici : http://www.simmoril.com/blog/?p=293 semble très intéressante. Elle semble avoir une complexité O(n²), et utilise la récursivité ainsi que plein de listes (mais celui ayant codé ça en Python, il ne l'a peut-être pas vu, ou il s'en fiche un peu). Néanmoins, c'est déjà mieux que rien si je ne trouve rien de mieux.
[^] # Re: Réinventer la roue ?
Posté par steckdenis (site web personnel) . En réponse au message [Algorithmie] Aire la plus grande de blocs se superposant. Évalué à 6.
Je n'ai pas encore eu la possibilité de tester ce que j'ai trouvé, mais c'est bien plus complet que le petit morceau que je demande ici. La particularité de mon algorithme est qu'il a une petite chance de produire les patches les plus petits possibles, ou en tous cas de s'en approcher fortement.
En effet, les algos existants éliminent des données, comme la thèse que je donne plus haut qui contient un truc du genre «Si le bloc ne correspond pas à plus de 50%, faire comme s'il ne correspond pas, car il y a des chances qu'il ne corresponde pas».
Je me concentre sur la petitesse du patch, par sur la rapidité. J'ai déjà sorti des artilleries très lourdes pour préparer cette liste de blocs, mais pour le moment, ça va (moins d'une seconde pour les premières passes du delta d'un fichier de 300Kio).
L'application du patch est déjà codée (avec des patchs faits-mains), et est de complexité O(taille du patch), alors que bsdiff applique les patches en O(m+n), avec m et n les tailles des anciens nouveau fichiers.
Ce problème de blocs est vraiment le dernier truc que je dois résoudre. Je planche sur ce diff depuis un mois maintenant (il n'y à qu'à regarder de quand cesse le dernier gros commit de Setup, ici la sortie de l'alpha1), c'est bientôt fini.
[^] # Re: 1D / 2D ?
Posté par steckdenis (site web personnel) . En réponse au message [Algorithmie] Aire la plus grande de blocs se superposant. Évalué à 1.
Merci beaucoup tout de même :-) . Ça m'apprend que ça doit pouvoir se résoudre en O(n).
[^] # Re: Super, un site de plus en dark
Posté par steckdenis (site web personnel) . En réponse au journal Feuille de style CSS pour LinuxFR. Évalué à 2.
Bien plus simple :-) .
[^] # Re: Pourquoi serait-ce un bug dans Qt ?
Posté par steckdenis (site web personnel) . En réponse au journal Clang arrive avec le C++, et ça va faire mal. Évalué à 1.
/usr/include/QtCore/qlist.h:113: undefined reference to `shared_null'
cache.o: In function `QList::at(int) const':
/usr/include/QtCore/qlist.h:439: undefined reference to `qt_assert_x'
cache.o: In function `QByteArray::~QByteArray()':
/usr/include/QtCore/qbytearray.h:382: undefined reference to `qFree'
cache.o: In function `QString::QString()':
/usr/include/QtCore/qstring.h:868: undefined reference to `shared_null'
cache.o: In function `QList<Logram::Depend*>::at(int) const':
/usr/include/QtCore/qlist.h:439: undefined reference to `qt_assert_x'
cache.o: In function `QList<Logram::ChangeLogEntry*>::detach_helper()':
/usr/include/QtCore/qlist.h:608: undefined reference to `qFree'
cache.o: In function `QList<Logram::ChangeLogEntry*>::free(QListData::Data*)':
/usr/include/QtCore/qlist.h:649: undefined reference to `qFree'
cache.o: In function `QList<Logram::Package*>::detach_helper()':
/usr/include/QtCore/qlist.h:608: undefined reference to `qFree'
cache.o: In function `QList<Logram::Package*>::free(QListData::Data*)':
/usr/include/QtCore/qlist.h:649: undefined reference to `qFree'
cache.o: In function `QList<Logram::Depend*>::free(QListData::Data*)':
/usr/include/QtCore/qlist.h:649: undefined reference to `qFree'
cache.o:/usr/include/QtCore/qlist.h:608: more undefined references to `qFree' follow
cache.o: In function `QString::QString(QString const&)':
/usr/include/QtCore/qstring.h:715: undefined reference to `qt_assert'
cache.o: In function `QList::free(QListData::Data*)':
/usr/include/QtCore/qlist.h:649: undefined reference to `qFree'
C'est donc LD qui génère ça, et ça ne se produit pas avec GCC. La liste est un peu plus longue mais ne contient pas tous les symboles de Qt, de plus, voici la ligne de commande :
clang++ -o setup cache.o main.o app.o package.o communication.o string.o source.o repoma.o moc_app.o -L/usr/lib -llgrpkg -lQtCore -L/usr/lib -lz -lm -pthread -lgthread-2.0 -lrt -lglib-2.0 -ldl -lpthread
C'est un bug de clang, ou alors QMake qui ne génère pas ce qu'il faut, ou alors la libQt qui est cassée quand elle n'est pas utilisée par GCC.
# GoboLinux + KDE = ton rêve
Posté par steckdenis (site web personnel) . En réponse au journal Windows 7. Évalué à 6.
À la vue des "+++" et "---" de ton journal, je ne peux que te conseiller de tester GoboLinux avec un joli KDE dessus :
* Les applications sont installées dans un arbre de fichiers "à la Windows", mais en encore mieux
* T'as une barre des tâches comme t'aimes bien, avec groupement des fenêtres, et surtout, tu sais en changer (STasks fonctionne comme celle de Windows 7, si tu aimes). Il existe même des thèmes Plasma et des packs d'icônes pour transformer KDE en Windows 7, si tu en as envie
* Je n'ai pas testé l'installation de GoboLinux, mais ça devrait ne pas être trop difficile
* C'est du Linux, donc le système n'est pas opaque.
Comme quoi, il y a toujours de nouveaux horizons à découvrir partout :) .
[^] # Re: Libre = GNOME ?
Posté par steckdenis (site web personnel) . En réponse au journal Intel: Ca commence à être pas mal, Firefox: Ca continue à faire chier. Évalué à 3.
L'environnement de bureau est maintenant maintenu par trois lascars, pendant justement que j'essaie d'aider KDE comme je peux : patches, troll^W promotion (mes journaux avec les screenshots), nouvelles, et surtout ma distribution visant à le remettre là où il doit, c'est à dire en première place. Je compte d'ailleurs utiliser le meilleur dedans, donc il se pourrait que je sois amené à le coder ce foutu backend Solid, ou l'intégration Plymouth->KDM, ou le support d'OSSv4 dans Phonon, etc.
Ok, je n'ai pas encore beaucoup de choses à mon actif, mais j'ai déjà soufflé quelques mots au développeur de Shaman 2, un gestionnaire de paquets à la packagekit (il est d'ailleurs compatible avec ce dernier) pour KDE.
Je bêta-test KOffice aussi, parce que ce truc a largement plus d'avenir que le clone de MS Office qu'est OpenOffice.org. KOffice est largement plus révolutionnaire, et quand il ne plante pas, un plaisir à utiliser (amusez-vous à mettre plein de graphismes vectoriels et à faire de la POO dans KWord, tout est à sa place, même des frames qui créent des nouvelles pages quand elles sont remplies).
[^] # Re: Libre = GNOME ?
Posté par steckdenis (site web personnel) . En réponse au journal Intel: Ca commence à être pas mal, Firefox: Ca continue à faire chier. Évalué à 9.
J'utilise KDE, j'aime KDE, c'est quelque-chose de très bien fait, mais j'ai de plus en plus l'impression d'être mis à l'écart, car de plus en plus de choses sont développées pour GNOME, sans se soucier de KDE.
Certaines choses sont la faute des devs de KDE, comme DeviceKit qui n'est pas très bien supporté par Solid, mais on peut aussi mettre la faute sur les entreprises qui préfèrent payer des devs pour travailler sur GNOME plutôt que KDE.
KDE a peut-être fait des erreurs, en se liant trop à Trolltech puis à Nokia, mais on ne peut pas dire que ce soit difficile de développer pour eux. Un compte SVN s'obtient en 20 minutes, et on a quasi carte blanche sur tout le dépôt. Des outils super sont en place, comme la doc Doxygen, le lxr.kde.org, techbase, les forums, les mailing-lists, etc.
Mais néanmoins, malgré que KDE soit super ouvert sur les contributions, personne ne s'attaque à ce dont KDE a besoin.
Oui, on a Plasma, plein de petits jeux, KOffice, et tout un tas de super bonnes applications. La partie «haute» est on ne peut plus complète, ce qui manque est la partie basse. Comme je le dis plus haut, on a un support DeviceKit plus que douteux, qui a fait l'objet de deux commits (ok, des gros) il y a quelques mois, et qui se morfond maintenant dans branches/work. Ce n'est que récemment, très récemment que KMix supporte PulseAudio.
En fait, pour constater le déséquilibre, il n'y à qu'à voir ce qu'on trouve de chaque côté :
* Pour GNOME, il y a RedHat qui paie des gens, Canonical qui développe de petits machins et qui mettent GNOME à la mode (pour ceux que je connais, Linux = Ubuntu = GNOME = largement en arrière par rapport à Windows 7 :( ). Tous ceux qui développent une technologie l'intègrent à GNOME, les GUI de configuration de KVM, MySQL Workbench, des trucs comme FireFox justement, et des centaines de grosses applis
* Pour KDE, il y a juste Nokia et SuSE. Le reste est assuré purement par des bénévoles, et pas beaucoup (Okular est quasi abandonné, Ark aussi, une vague d'applis on du être mises dans le tag unmaintained). Côté distrib, il y a juste OpenSuSE, Mandriva et les petits genre Chakra, Pardus, etc.
Ça me donne l'impression que KDE est développé à l'ombre de GNOME. Oui, GNOME est excellent, et je n'en garde que de bons souvenirs : simple, élégant, efficace. Mais il faut absolument éviter de tuer la concurrence, car on est dans un cercle vicieux : plus les gens développent pour GNOME, mieux GNOME est, donc plus il attire de gens.
(si on avait été vendredi, j'aurais ajouté qu'en plus GNOME n'aurait pas du exister, du moins plus après la libération de Qt sous GPL, mais c'est un pas que je ne franchirai pas).
# Libre = GNOME ?
Posté par steckdenis (site web personnel) . En réponse au journal Intel: Ca commence à être pas mal, Firefox: Ca continue à faire chier. Évalué à 9.
Non, la mozilla essaie de faire pour le mieux. Seulement, comme je dis de temps en temps dans les quelques trolls velus que je lance les vendredis, pour beaucoup de gens, «intégration à Linux» veut dire «intégration à GNOME» :-( . (exemples : DeviceKit qui dépend de la glib, packagtkit qui maintient gnome-packagekit et pas kpackagekit, OSS qui vient avec un mixeur GTK, le kernel qui peut se configurer en GTK2 ou en Qt ... 3, cairo et autres technos GNOME dans Freedesktop, pendant que Akonadi se fait refuser alors qu'il est pleinement utilisable sous GNOME)
Donc, chez Mozilla, ils se sont peut-être dis qu'ils aimeraient une bonne intégration. Un dev proche des entreprises pro-GNOME genre RedHat ou Novell aurait alors dit «Pour une bonne intégration, il faut utiliser gnome-vfs». Surtout qu'appeler xdg-open est peut-être perçu comme un hack permettant d'utiliser gnome-vfs en console, ou que sais-je.
Freedesktop, c'est comme KDE et Debian : trop communautaire, pas assez entreprise pour certains.
Défoulez-vous sur ce post, je suis préparé au -10 :) .
# Solution pour KDE
Posté par steckdenis (site web personnel) . En réponse au journal Resolution independance. Évalué à 3.
Polices
K»Configuration du système, puis bouton «Apparence», partie «Polices», mettre «Forcer le PPP des polices» sur 120PPP, normalement c'est ça.
Sinon, tu changes manuellement la taille des polices (liste au dessus) pour que ce soit lisible.
Pas de prob avec de bonnes applis Qt qui utilisent des layouts, c'est fait pour ça. Je ne garantis rien pour GTK :-° .
Icônes
À nouveau, K»Configuration du système, cliquer sur «Apparence», ensuite sur «Icônes», puis sur l'onglet «Avancé». Ensuite, pour chaque entrée de la liste, choisir la taille que tu veux. Par exemple, prendre «Bureau» et mettre une taille de 64 au lieu de 48 te donnera un bureau lisible.
Bordures de fenêtres (KDE 4.4 seulement) ou décorations Nitrogen
Cliquer sur la partie «Fenêtres», puis s'assurer que le thème Oxygen est bien utilisé.
Ensuite, explorer les petits onglets à la recherche de «Taille des boutons de la fenêtre», et les mettre en «gros» ou «très gros». Les boutons (croix, agrandir, réduir, etc) seront plus gros, la barre de titre aussi.
Voilà ! Utilisez KDE, vous dis-je. Ça se configure bien et ça marche bien :) .
[^] # Re: Nombre de journaux
Posté par steckdenis (site web personnel) . En réponse au journal Sortie de Setup 0.1-alpha1. Évalué à 10.
Il y a déjà tous les flux RSS qu'on peut vouloir sur le site (y compris les derniers paquets, c'est dire).
Ensuite, il n'y a pas énormément de journaux par jour sur Linuxfr, et je vise toujours dans une période creuse (donc pas juste après une dépêche de patrick_g, une grosse sortie, mais plutôt quand le week-end commence, quand on a parlé de cinéma, etc). Et je n'oblige personne à lire mes journaux, il existe même un script pour les cacher (maintenant que j'ai vu ça, je vais le ressortir tout le temps).
Et puis, moi j'aimerais bien avoir des nouvelles ici des sorties de Wormux, G'MIC, et autres. Ce sont des projets que j'aime beaucoup et qui sont très intéressants.
Et puis, Setup, c'est tout de même un gestionnaire de paquets. Si j'avais pu voir naître APT, ou autre, j'aurais été très heureux. Malheureusement, même en cherchant dans les archives de Linuxfr, il ne reste plus aucune trace de cette époque, et c'est bien dommage.
De plus, il ne faut pas trop se fier aux titre alpha/beta/etc. Certes, Setup n'est pas avancé, mais la quantité de changements depuis l'alpha0 est quasi aussi importante que ce qu'on trouve entre deux versions majeures d'autres projets, qui se développent doucement. La version 0.1 finale de Setup commence bien par un zéro, mais c'est un zéro "à la enlightenment", donc un zéro pour dire que le dev n'est pas satisfait du machin. Vous pouvez sans problèmes considérer Setup 0.1-alpha1 comme Setup 1.1, l'alpha 0 comme Setup 1.0. Dans ce cas, ce sont des versions largement plus intéressantes :) .
Merci en tous cas de m'explique pourquoi un journal sur Setup recoit d'abord 39, puis -5.