C'est à dire immensément mieux, mais moins connu et FUDé.
Open Sound System 4 est la crème de la crème de la technologie, et permet toutes les goodies de PulseAudio (volume par applications, mixage sans problèmes), sans les défauts d'ASLA (l'API de OSS est super simple, c'est super rapide fluide et léger, et ça ne consomme pas de ressources). Toutes les cartes que j'ai pu utiliser fonctionnent.
Pourquoi ce n'est pas utilisé alors ? Et bien, c'est simple : le FUD. C'est même comme un couteau dans le coeur que j'ai découvert que même notre chez patrick_g y participe, je crois dans sa news sur le noyau 2.6.31 : «Mais malheureusement il y a toujours les méchantes applications qui utilisent encore toujours le vieux OSS», ou quelque-chose du genre.
Pour beaucoup de gens, OSS est vieux (ils pensent au 3). Pour d'autres, il n'est pas libre (alors qu'il est dispo en GPL et BSD, oui, au choix !).
Comme Linux pour Windows, OSS s'efforce alors d'être compatible. Il a proposé une bibliothèque émulant ALSA (parallèle de Wine), mais il aura fallu attendre que ALSA propose une sortie OSS pour que les applis soient portés.
Étant utilisé en minorité, il est moins supporté. Les gros projets comme HAL, KDE, etc le délaissent, et préfèrent pousser le lourd machin qu'est PulseAudio, ou l'immonde Linux-only ALSA, au lieu d'aider les pauvres développeurs d'OSS qui n'en peuvent plus d'être seuls, depuis des années et des années.
Bref, vous tous qui me lisez, utilisez OSS ! Il s'installe en quelques minutes, même si (FUD oblige) les distribs ne sont pas nombreuses à l'empaqueter. Vos applis ALSA sauront l'utiliser sans problème, KDE aussi après quelques manipulations, et vous aurez un son parfait, qui juste-marche (plus de problèmes avec des applis qui s'accaparent la carte son, avec PulseAudio qui insère des délais énormes, ou qui se met à consommer 100% du CPU).
Mesdames et messieurs, des alternatives existent ! Beaucoup sont passés de Windows à Linux, maintenant passez de ALSA à OSS.
Merci.
(voilà, le post long et inutile du lundi soir :-° )
J'ai bien le code aéré, c'est par pure lisibilité :
if (machin && truc && brol != chose) {
c = (b == encore ? !truc : chose + 4);
}
Illisible, en tous cas peu clair, et pas si symétrique (t'as une accolade seule sur sa ligne, l'autre sur la ligne du if, donc c'est pas la même chose)
if (machin && truc && brol != chose)
{
c = (b == encore ? !truc : chose + 4);
}
Autre avantage utile pour le debug, vraiment utile :
/* if (un truc qui ne sert à rien, enfin je crois, donc je vire pour voir) */
{
le_code
}
Ça compile encore !
Et puis c'est comme pour mes commentaires et mes sauts de lignes. Plus c'est écarté et découpé, plus les gens comprennent (je préfère avoir 100 personnes qui comprennent et soumettent des patchs, même si 10 n'aiment pas, que de n'avoir que 10 personnes qui comprennent ce que je met)
S'il y a des fautes, c'est avec plaisir que je les corrigerai :) .
Pour la progression, c'est un affichage encore un peu expérimental, sachant que la bibliothèque qui gère les paquets envoie à certains intervalles des signaux permettant de savoir ce qui avance ou pas, et que c'est totalement asynchrone. De plus, une progression de type 2/2 permet de signaler que la progression est finie, donc, dans la GUI, d'effacer la barre de progression.
C'est tordu et pas spécialement joli, mais je n'ai pas encore trouvé mieux. C'est cependant sur la feuille de route pour la finale, pour que Setup soit joli (et ne flood pas trop la console quand on télécharge un fichier, aussi).
Les distributions n'ont pas une infinité de packageurs. Généralement, avec comme exemple Xmoto cette fois-ci, ce sont les développeurs du logiciel qui font des paquets pour les quelques distributions qu'ils utilisent, et ils maintiennent ce paquet.
Parce que sinon, ça ferait déjà longtemps qu'il y aurai un paquet Logram DE dans Debian, ou alors j'aurais la version 0.5.2 et non 0.5.1 de XMoto dans Fedora, etc.
Commentaire intéressante, merci. Je ne détaille jamais assez le fond de ma pensée, parce que je n'y pense pas, mais j'ai prévu la plupart de ces problèmes.
Gettext n'est pas lent à l'installation, pas du tout. C'est simplement peu élégant, et encourage la non-traduction. Imagine que tu crées ton paquet perso, par exemple que le dev de Wormux crée son paquet Wormux. Il sait peut-être parler français, anglais et espagnol, mais a-t-il envie de créer des templates Gettext, de les gérer, de les traduire, et de modifier trente six mille fichiers pour que dpkg-buildpackage marche comme il faut ?
Non. Lui, il veut un truc simple. Il ne sait d'ailleurs peut-être même pas qu'on sait faire les traductions de paquets. Setup, lui, fournit une architecture de type [langue]texte[/langue] dans son fichier de métadonnées. Ainsi, si le développeur suit le tuto et se rend compte qu'on lui demande de taper :
< fr >Description< /fr >
Il va se rendre compte qu'en replaçant fr par en, il peut traduire super rapidement en anglais. Oui, c'est moins "pro" que du Gettext, mais le résultat est que l'utilisateur aura un paquet dans sa langue, avec le changelog dans sa langue (super Super important ça, pour les mises à jour), une description dans sa langue, etc. C'est typiquement ce type de "finition" qu'il manque au Libre.
Prenez un Windows, et regardez. Tout, absolument tout est traduit. Les rares choses qui ne le sont pas sont des obscures programmes dans system32. Prenez votre distro préférée, même une Mandriva française. Vous trouverez sans problèmes des éléments non-traduits. Oui, le KDE est traduit. Mettez votre système à jour, recherchez un paquet, et *paf*, rien ou presque n'est traduit.
L'utilisateur anglophobe sera totalement perdu. C'est ce genre de problème auxquels il faut faire attention.
Pour le test de transaction, c'est intéressant. J'utilise Fedora et j'ai pu apprécier cet élément. Setup sera un peu plus hackish, mais fera la même chose. En effet, on peut définir l'Installation-Root d'un paquet. Il suffit, quand on installe les paquets, de les installer dans /tmp/teporarytree. Une fois que tout est installé et testé (les postinst() des paquets peuvent servir à vérifier, ainsi que les || exit 1 dans le packagebuild), on copie simplement ce dossier dans /, et c'est fait.
Ainsi, l'utilisateur répondra aux questions, ce sera rapide, et si un paquet échoue, le système est encore stable, laissé intouché. Mieux, ne pas nécessiter les droits root pour cette phase de test, mais seulement pour la copie finale.
> Si cette argument était étayé par des exemples, il en deviendrait plus persuasif.
J'ai donné l'exemple des kdelibs après. Grosso-modo, chaque paquet un peu lourd de Debian devient fort complexe. Prends par exemple Grub, un "simple" bootloader, mais qui nécessite un fichier rules kilométrique.
Ensuite, Logram n'a pas encore d'exigence sur les paquets, du fait qu'aucun paquet officiel n'existe. Dès que Setup sera suffisamment avancé, qu'on pourra créer de beaux paquets, les exigences seront mises en places.
Et elles seront draconiennes ! Il y a «les classiques», comme les informations de debug séparées (un petit helper Sepa le permet déjà, puis une petite modification des métadonnées et c'est fait), le strip des éxécutables, etc. Il y aura aussi des choses plus complexes à mettre en oeuvre, indépendemment de Setup, comme par exemple une intégration à KDE partout où c'est possible.
M'enfin, j'avoue que tout ceci n'est pas encore très clair. Setup se développe, je réfléchis de mon côté, plus qu'à voir ce que ça va donner. Je me concentre actuellement plus sur la gestion des Deltas, avec bsdiff, pour drastiquement réduire les téléchargements (et ainsi pouvoir, avec la légèreté de Setup et de Logram DE, viser les OLPC pas puissants du tout, avec petit écran, et mauvaise connexion s'ils en ont).
Deux commentaires se plaignent du manque d'arguments en faveur de la simplicité avec laquelle on peut créer un paquet Setup.
Tout d'abord, voici ce que je trouve complexe avec les paquets Deb et Rpm (pour les autres, ABS etc, j'ai dit que j'aimais bien et que je m'en étais inspiré). Pour ces deux types de paquets, créer un «paquet simple» est une affaire de minutes. J'ai eu l'occasion de tester, c'est rapide et facile.
Seulement, quand les paquets deviennent un peu complexes (plusieurs binaires, bibliothèques, etc), ça devient plus difficile. Il faut adapter le Control pour que ça marche, le fichier Rules se complexifie, etc.
Un paquet ne répondant pas strictement aux normes est également plus difficile à produire. Pour le constater, prenez le paquet sources des kdelibs, ou de tout programme KDE empaqueté par l'équipe KDE de Debian. Le rules est simple, oui, mais il commence par une ligne pour inclure une monstrueuse et complexe suite de scripts faisant en sorte que le rules marche.
Pour RPM, j'ai cru voir (mais je n'en suis pas certain) qu'il faut taper manuellement le nom de tous les fichiers qu'on veut inclure dans le paquet. Ok, c'est faisable pour Qtracker ou autre programme composé d'un petit nombre de fichiers, mais essayez un peu avec un truc un peu gros comme OpenOffice.org, FireFox, les kdelibs, etc. Vous allez en avoir vite marre.
Du côté de Setup, un paquet simple est un peu plus compliqué à faire (on a du code à taper), mais la complexité augmente bien moins quand le paquet change. Par exemple, le packagebuild contient les instructions nécessaires à la compilation, à la manière d'un pkgbuild (d'ailleurs, le nom packagebuild s'inspire bien de pkgbuild, comme quoi je sais voir ce qu'il y a de bien chez les autres :) ). Si vous suivez le LFS un de ces jours, vous verrez que toutes les lignes de commandes pour appliquer des patchs sont données. Avec Setup, il suffit de les copier/coller dans le pkgbuild. Avec un paquet Debian (je ne sais pas pour RPM), ça peut aussi se faire mais il faut une adaptation.
Pour le fichier XML, il est auto-documenté (petits commentaires, et balises XML explicites). Le principe du XML n'est pas compliqué à apprendre, même si c'est plus complexe qu'un simple fichier «Clef: Valeur» comme Debian utilise. Par contre, ça permet plein de choses, comme l'arbre DOM. C'est grâce à l'utilisation du XML que les traductions sont si faciles à faire, alors que Debian nécessite un puissant gettext (encore un exemple que Setup reste simple quand Debian se complexifie atrocement). Les règles de validation pour les questions sont également gérées par arbre DOM, ce qui permet de les regrouper, de les modifier, etc. Il y a plein d'autres exemples.
Néanmoins, j'admet que ce n'est pas si simple qu'un PKGBUILD, mais Setup s'oriente un peu plus vers l'user-friendlyness que Pacman. Avec Setup, l'utilisateur peut configurer son paquet graphiquement au moment de l'installation, toutes les chaînes de caractère traduites dans sa langue. Ça a un pris pour le développeur, oui.
J'ai utilisé Redmine pendant 10 mois, avant le site que j'ai codé. J'ai pu apprécier tout ce qu'il permet, ainsi que ses défauts, qui m'ont conduit à créer ce site :
* Le forum est vraiment inutilisable, même pas moyen de voir facilement les messages lus et non-lus
* Il est très difficile à intégrer à un autre site (j'utilisais Drupal pour les nouvelles et pour son forum)
* Le reste est bien pensé mais un peu trop "sérieux"
Néanmoins, c'est un outil d'une très grande qualité bourré de fonctionnalités très intéressantes, comme les Milestones, les Grantt, les statistiques sur le SVN, etc. Je tiens à féliciter son auteur.
Un joli troll de haut niveau a été lancé sur ce journal, pour fêter le vendredi comme il se doit (faut dire que c'est inévitable avec un journal posté le jeudi soir).
Tout d'abord, ne vous en prenez pas à mes connaissances, ce n'est pas "parce que je ne sais rien faire d'autre" que j'ai utilisé Qt. Simplement, je suis le seul codeur, et j'aime le code lisible. Prenez un gestionnaire de paquets pas trop complexe, genre la libalpm (utilisé par Pacman, le gestionnaire de paquets de Arch Linux), et regardez.
Il y a pas mal de code dedans, dont un qui gère le protocole HTTP, un le HTTP, un les différents types de compression, un un système de queue, etc. Au final, quand on veut résoudre un bug sans connaître le code, on prend plus de temps à trouver le fichier et la fonction incriminée qu'à corriger le code.
Qt permet de factoriser le code, et est un avantage technologique. Déjà il permet de ne pas tout recoder (on a la gestion du réseau dedans, la gestion des fichiers de configuration, la gestion du XML, etc). Ensuite, les signaux et les slots peuvent être utiles (par exemple dans la gestion des téléchargements en parallèle, un téléchargement fini déclanchant l'installation de son paquet), et certains modules, comme QtScript, sont un simple bonus.
Logram n'est absolument pas une distribution à vocation serveur. Sur un serveur, installez une Debian, une Red Hat, ou tout autre. Logram, c'est du bureau, du vrais (donc pas un truc comme Ubuntu qui se dit "desktop" parce que ça fait bien, mais qui fournit également une version serveur "parce que ça fait bien aussi").
D'ailleurs, dans le monde du desktop, nous avons Mandriva, qui utilise la suite URPM ... codé en Perl. Ça alors, un langage de script, qui nécessite tout Perl. Même pas une lib, non non, tout un langage. Il faut vraiment leur dire que ça pue, que c'est pas bien, que le C99 juste au dessus de la LibC c'est mieux, non ?
Et bien non. Si l'utilisation d'une bibliothèque de haut niveau permet de sortir un programme de qualité, ou du moins qui a la possibilité de devenir de qualité, on en profite. Rien ne dépend de X, Qt s'installe en quelques secondes, ça occupe 10Mio de disque dur, quelques Mio de RAM, donc c'est rien. Profitons que nous avons un OS correctement conçu qui permet d'installer des bibliothèques sans encrasser une base de registre et ralentir le tout (on est vendredi).
Sinon, je veux bien qu'on fork Setup. Vous allez simplement passer 6 mois à corriger les bugs dans votre implémentation de ce que Qt fournit, comme par exemple les tables de Hash, très utilisées, les listes, les threads, les signaux, la synchronisation, etc.
Ou alors, vous allez utiliser trente six mille bibliothèques, à la manière des applications C générales, pour avoir la même chose. Ce sera plein de dépendances, mais personne ne va s'en plaindre.
Elle était déjà sur la clef USB, mais fraîchement installé (avec quand-même tout ce que je dis dans le journal de fait).
Effectivement, j'écris mes journaux juste après avoir découvert la chose, et le but des journaux est justement ce genre de réactions. Ma dépêche sur LLVM était tout ce qu'il y a de plus correct, normalement.
Dans ce journal, je saluais le travail fait sur Chakra, et sur Arch Linux, qui fait que cette distribution m'a convenu tout de suite.
J'utilise encore Chakra, je l'ai bien personnalisée, et elle me plaît encore toujours tout autant, toujours aussi rapide (même avec un MySQL d'installé, etc).
Bref, ce journal était venu un peu tôt, mais je ne suis pas moins d'accord avec.
Et pour finir, comme je teste plein de choses différentes, c'est toujours le plus_mieux_qu_il_est_bien. Ce n'est pas parce que Chakra est une bonne distro que KOffice ou KDE ne seront plus bons, ou que OSSv4 ne cartonnera plus, ou que Mandriva ne sera plus une excellente distro, ou que GRUB 2 ne sera plus une tuerie, etc. Je ne passe pas ma vie à changer d'avis, je dis simplement quand un truc me plaît (avec exagération, sinon c'est pas marrant il n'y a pas moyen de troller)
Moi j'ai un Atom, le genre de bêbete à peine plus puissante qu'un téléphone mobile. Ce truc est certes cadencé à 1,6Ghz, mais ça a un cache de 512K, un bus de carte mère de 133Mhz, bref une architecture plutôt de Pentium 3 ou 2.
Donc oui, 20 secondes sur un P4, c'est 1 minute ou plus sur un Atom. Donc c'est bon :-) .
Moi j'ai fait le journal, subjectif, relatant mes impressions de quand j'ai testé. Maintenant, s'il est passé en dépêche, ça m'arrange aussi et j'en remercie les modérateurs. Par contre, hors de question de se plaindre de ce que j'ai dit.
Sinon, ce que je dis est effectivement vrai. Les drakxtools sont superbes, j'ai dis que j'aimais beaucoup Mandriva, mais franchement, rpmdrake est inacceptable :
* Lancer les drakxtools, ça va encore
* Cliquer sur «Installer et supprimer des paquets»
* Attendre 30 ou 40 secondes que ça charge, et encore, je suis certain que ça prend plus.
* Rechercher ses paquets, les sélectionner
* Attendre le temps d'installation (qui lui est correct, bien que largement plus lent que APT, mais c'est pas la faute de rpmdrake)
* à nouveau attendre 50 secondes, sans qu'on puisse rien faire, pour que la GUI se recharge
* Enfin pouvoir cliquer sur Quitter
Je trouve inacceptable de devoir prendre 5 minutes, des vraies minutes, pour installer une bêtise genre Django, Djapian, les libs -devel de Qt et autre. C'est bien trop lent. Heureusement, la ligne de commande est elle parfaitement utilisable.
Du côté de Chakra, et donc de Arch, c'est largement plus rapide. On a un petit splash screen au démarrage de Shaman, qui reste d'ailleurs quelques secondes, puis on sélectionne les paquets, on les installe (et là c'est plus rapide, ou plus lent, ça dépend un peu du temps qu'il fait dehors), et une fois installer, on ferme la fenêtre d'installation.
En dessous, la GUI qui affiche la liste des paquets est encore toujours utilisable, et on peut fermer Shaman ou installer d'autres paquets rapidement, alors que Mandriva efface la liste, ré-explore les paquets et reconstruit tout.
C'est peut-être une différence Perl/C++, le C++ autorisant des programmes procéduraux et Perl encourageant les programmes «en boucles» (même s'il gère les procédures). En tous cas, il y a un problème avec rpmdrake.
PS: Et en plus j'ai dit que c'est la même machine, le même DD, la même quantité de RAM, des partitions de la même taille, etc.
Je donne dans le premier paragraphe un lien vers le site de Chakra, c'est à peu près tout ce qu'il y a, mais suffisant.
En effet, ce site contient une très bonne introduction, plein de screenshots, des explications, un wiki, un forum, etc. C'est un très très bon site d'ailleurs.
J'avoue, oui, il m'arrive de dire des trucs idiots.
Néanmoins, si il y a 50 ans, quelqu'un t'avais montré un téléphone portable, un eeePC, ou même un ordinateur normal, ne l'aurais-tu pas pris pour un fous ?
Je n'ai pas la prétention de dire que je suis visionnaire, mais il ne faut pas tout de suite jeter des idées.
L'algo de compression est "plausible". Un hash, par exemple, est censé être différent pour chaque fichier qu'un hash, ce qui pourrait vouloir dire qu'un simple sha256 peut contenir des informations. Oui, elles sont dégradées, mais c'est juste possible. J'avais remarqué que les disques durs utilisent un certain codage pour transformer des suites de bits en ondes, et que ces ondes avaient une forme "binaire" (soit hautes, soit basses). On pouvait par exemple encoder 12 bits dans une onde ne présentant de 10 changements d'états, donc 10 bits. C'est une compression, indépendante des données. Il se pourrait donc qu'en appliquant une compression de ce type, on sache compresser le fichier encore plus. Maintenant, cela m'étonnerais que ce soit possible, mais je donne l'idée.
Pour les backdoors, voir visuellement les différences entre les fichiers est encore une fois "plausible". Je n'avance jamais rien en tant que vérité absolue, je dis juste quand j'ai trouvé quelque-chose, en espérant trouver quelqu'un pour dire si c'est possible ou pas. Alors évidemment, si tout ce qu'on me dit est «c'est pas possible, retourne jouer à la petite voiture», j'insiste.
De plus, ce que j'avais avancé (des différences minimes si on change un truc) est certes invérifiable en compilé, mais où se situe du bytecode llvm dedans ? Si le programme qui génère les cartes de différences détecte quand il y a un décalage, il est possible de trouver des différences ne jouant que sur quelques octets, mais décalant tout le reste. Encore une fois, c'est très probablement impossible, mais pas à 100%.
Et pour la gestion des dépendances, alors là non. Mon gestionnaire de dépendances marche, il fait ce qu'il doit, il m'installe mes paquets, supprime mes conflits (même un conflit de provide, donc si "machin" est en conflit avec "www-browser", FireFox et Konqueror seront supprimés). Bref, la théorie est un peu osée, mais les exemples en fin de journal étaient là pour montrer que ça marchait, du moins un peu. Depuis, cet algorithme a été amélioré pour gérer plus de choses et être plus intelligent. C'est une base simple mais solide sur laquelle on peut mettre ce qu'on veut.
Et pour le noyau, je n'ai pas parlé de 50 fois plus vite, simplement que c'est plus réactif. C'est un fait, il existe un réglage «Server», «Desktop», «High responsive desktop», et Debian le règle sur «Server», et moi sur «High responsive desktop». Je n'ai rien inventé, je n'ai fait qu'appliquer une option de configuration du noyau qui fait ce qu'elle est censé faire : améliorer la réponse du système et l'ordonnancement des threads. Ça s'applique particulièrement bien au démarrage car des dizaines de processus sont lancés en même temps, demandent le disque en même temps, demandent du processeur en même temps, etc.
Donc oui, il m'arrive d'un peu trop m'avancer, mais c'est pas parce que je dis une fois une bêtise que tout le reste est bêtise. Alors oui, si on part du principe que je ne racconte que des tissus d'ânerie, jamais on va me trouver pertinent, mais si on me laisse une chance, qui sait, on va peut-être trouver quelque-chose d'utile dans tout ce que je dis.
Je suis tout à fait conscient du problème, du fait que mon père est daltonien et que j'utilise souvent des programmes en distant avec SSH, sans couleurs (petite connexion).
Pour le moment, Setup utilise beaucoup de couleurs, car c'est assez agréable à utiliser pour ceux qui savent en profiter. Une des choses que j'ai le plus apprécié avec Gentoo est que Portage utilise quelques couleurs (surtout le vert). Ceux qui ont fait un "apt-cache showpkg un_paquet" savent qu'un gros pâté blanc est repoussant.
Pour les dépendances (et pour les légendes «va être installé», «supprimé», etc), oui, c'est particulièrement handicapant. Je commence tout doucement à corriger le problème, et les premiers résultats sont visibles dans la liste des versions d'un paquet : la version installée des précédée d'un "»" au lieu d'une "*".
Pour le reste, je compte en plus des couleurs mettre des signes, comme des flèches, ou des numéros (avec légende). Je dois encore voir comment faire ça sans rendre le code sâle (parce que les couleurs c'est joli, mais en plus ça simplifie le code et évite les qPrintable).
Alors oui, je suis ambitieu, mais moi au moins, je code et ça avance :-° .
Si vous remettez en cause ce que je dis, le premier réflexe devrait être d'aller sur le site de Logram vérifier mes dires dans les news, télécharger le code et tester ;-) .
Je suis bien d'accord que mes journaux peuvent ne pas intéresser tout le monde, et c'est pour cela que ce sont des journaux, de seconde page qui plus est.
Alors oui, je parle souvent très tôt de ce que je fais, ça a un aspect blog. Je le sais, et c'est pour cela que je poste mes journaux le week-end, le plus souvent, c'est à dire quand il y a peu d'activité. En effet, un journal qui intéressera une minorité des lecteurs n'a pas d'intérêt en pleine semaine quand on croule déjà sous les dépêches. Par contre, le week-end, quand on a une dépêche et deux journaux par jour, le mien n'est pas de trop. Ainsi, ceux qui s'ennuient, réactualisent la page frénétiquement pour voir s'il y a du nouveau seront servis.
Ensuite, ce n'est pas uniquement du vent que je fais. Oui, j'ai parlé d'un concept abstrait sur Setup, mais actuellement, Setup est capable d'installer des paquets, il résout les dépendances, il affiche tout un tas d'informations, il est même intégré à la future version 4 du site de Logram (http://v4dev.logram-project.org/packages-4-1.html , oui, c'est comme packages.debian.org, sauf qu'ici c'est encore en développement, et qu'au menu, on a des commentaires, une notation, des screenshots, etc).
Ici, ce journal n'est pas purement un «Venez tous sous KDE». Honnêtement, je l'ai écrit sur un coup de tête. Je venais d'avoir trouvé un truc très beau dans Krita, et me suis souvenu de tout ce que j'avais déjà découvert. Je me suis alors dit que tout ça pourrait intéresser du monde, et que ceux qui ne sont pas intéressés pourraient trouver des conseils pratiques (si je parle des styles et du plus, qui existent dans OpenOffice.org et partout ailleurs, c'est justement parce que j'ai passé deux jours à trouver ce plus).
Et pour finir, dans tous mes journaux, il y en aura bien un qui va intéresser du monde. Ça arrive assez souvent qu'on me traite d'incompétent, mais généralement, le fond est correct. Dans mon journal «Passage du noyau 2.6.30 Debian au 2.6.31 vanilla», j'ai malencontreusement laissé échapper une petite erreur sur la préemptabilité. S'en sont suivis une dizaine de messages disant que je parle trop vite, et tout et tout. C'est comme ça, on voit toujours plus le mal que font les autres que le bien qu'ils font, donc je n'en veux à personne.
C'est d'ailleurs ça que j'aime dans Linuxfr. Si je postais ces journaux sur mon blog, sur le site de Logram, ou n'importe où ailleurs, je n'aurais que des fanboys disant «Super, génial, vivement que ça sorte», sans même avoir lu. Ici, je sais que j'obtiendrai un retour de qualité, et c'est pour ça que je soumet mes idées ici. Il y en a même, comme «LLVM dans un gestionnaire de paquets», qui intéressent pas mal de monde et qui me font recevoir un livre (même si mes journaux n'ont pas ça comme but).
Désolé pour le message long avec de gros paragraphes.
> Puis pour une fois, il pourrait utiliser une techno Kde les devs de gnome, ca changerait ;)
Ils en utilisent déjà tellement !
* Les thèmes d'icônes, c'est de KDE à la base
* Les fichiers .desktop et le menu des applications, c'est du KDE à la base
* DBUS, c'est plus ou moins comme DCOP
* Il me semble que la norme qui définit comment un gestionnaire de fenêtres se comporte vient de KDE, mais là je suis pas sûr du tout
En tous cas, ça m'a bien fait marrer quand j'ai lu les documentations de Freedesktop.org, et de lire à plein d'endroit «Préférez utiliser [Desktop Entry] au lieu de [KDE Desktop Entry]. Préférez utiliser [Icon theme] au lieu de [KDE icon theme], etc».
Tout d'abord, toutes mes félicitations pour ce programme. Je ne l'ai pas encore utilisé, mais vu ce qu'il sait faire (le truc avec le sinus en 3D), je suis certain qu'il servira à vraiment plein de monde.
Krita, l'éditeur d'images bitmap de la suite KOffice de KDE, a également pour vocation d'être très avancé technologiquement (il gère les profils de couleurs à 8, 16 et 32-bit depuis des lustres, alors que GIMP a encore du mal). Vu que G'MIC a l'air facile à intégrer, je te propose de faire un petit tours sur le forum de Krita ( http://forum.kde.org/viewforum.php?f=136 ), pour proposer l'intégration de G'MIC dedans.
C'est justement ce genre de choses qu'ils aiment, et qui apporterait d'un coup une énorme suite de fonctionnalités au programme. Ils pourraient même s'en donner à coeur joie et nous coder un joli éditeur de script G'MIC avec aperçu :) !
Et pour finir, c'est justement la bonne période. KOffice vient de recevoir l'aide de Nokia et d'une autre entreprise (j'ai cru entendre parler de 32 développeurs en plus, mais franchement, je ne suis absolument pas certain de cette information), et KOffice 2.1 sortira bientôt. Ils sont donc en phase de stabilisation, en ont marre de corriger des bugs, et attendent de très bonnes idées pour Krita 2.2, surtout quand le travail est déjà fait comme ici.
J'espère franchement pouvoir utiliser une telle merveille dans Krita dans quelques mois. Chapeau bas.
Le neuneu moyen, il va télécharger les belles images LiveCD qui sont présentées sur la première page du wiki et sur le site officiel. Les images x86_64, il faut vraiment les vouloir (ici passer par un DVD -je n'ai pas de DVDs-, ou alors il paraît que les PowerPack contiennent une version 64-bit. On peut aussi prendre des images minimales, mais ce n'est pas l'idéal pour le débutant).
Pour la majorité des utilisateurs, seule la version i586 existe, donc ils la prennent, et comme ils sont nombreux, les développeurs vont bien déboguer les paquets i586 (de même que plus d'utilisateurs enverront leurs bugs).
C'est possible, mais rien n'est fait pour me mettre en confiance :
* Je vois que les paquets sont du genre "lib64qt4", ce qui me fait croire qu'on peut toujours avoir un système "à moitié" en 32-bit. Fedora avait ce problème, car tous les paquets qu'on installait l'étaient en 32-bit sauf si on demandait explicitement le contraire (Fedora 9, ça date)
* Vu que quasi tout le monde utilise la version 32-bit, il faudrait s'assurer que les paquets 64-bit soient de la même qualité.
Bref, ça me convient pour le moment, et me permet de tester GCC 4.4.
J'ai, première fois de ma vie, formatté ma partition en XFS, pour tester. Il faut dire que je n'en n'avais entendu que du bien, performant, sans checkdisk au démarrage, rapide à formatter, solide, etc. Je ne suis pas déçu ! Le démarrage est bien rapide, je l'ai dit dans le journal, mais je viens aussi d'importer ma collection de musiques dans Amarok. Sous Debian, ça prenait une dizaine de secondes. Ici, ça a pris 2 secondes, et encore !
Deuxième point, les thèmes. Quand la 3D est activée, on a des décorations de fenêtres genre Oxygen, mais avec quelques modifications (qui personnellement ne me plaisent pas trop). Le thème de widgets, unifié entre GNOME et KDE, est léger et épuré. Il est également gentil pour le processeur, ce qui fait que l'ensemble de l'interface semble bien fluide. Pour tout ce qui est fond d'écran et écran de démarrage, c'est très joli.
Par contre, énorme point noir, c'est du i586. J'ai donc un KDE SVN compilé et tous ses modules qui se trouve impossible à lancer, de même qu'un Qt snapshot Git (future 4.6). Je sens que ça va compiler sec ces prochains jours (toujours mon petit Atom qui compile 1 SBU* en près de 25 minutes).
Je ne sais pas si je pourrai recompiler une autre version de mon noyau. J'ai un simple Atom à 1,6Ghz, et plein de choses à faire. Une compilation prend vraiment beaucoup de temps, temps pendant lequel je ne sais que surfer sur internet ... et pas compiler les programmes que je développe.
Si quelqu'un a une meilleure machine, ce serait effectivement intéressant de voir si c'est le changement de noyau ou la recompilation qui change tout.
PS: Mise à jour des données : redémarrage en quelques secondes à peine, mais le KDE prend plus ou moins 50 secondes à démarrer maintenant. La différence est du au fait que lors de mon premier test, Kate n'était pas lancé.
Noon ! J'ai compilé la version .2 hier et je vois maintenant que la .3 est sortie. J'ai vraiment pas de chance (la dernière fois j'ai compilé un 2.6.28 quand le 2.6.29 était en rc, le temps de la compile, la version finale était sortie).
# OSS4 est aux autres ce que Linux est à Windows
Posté par steckdenis (site web personnel) . En réponse au journal Le son sous Linux : du pure n'importe quoi. Évalué à 10.
Open Sound System 4 est la crème de la crème de la technologie, et permet toutes les goodies de PulseAudio (volume par applications, mixage sans problèmes), sans les défauts d'ASLA (l'API de OSS est super simple, c'est super rapide fluide et léger, et ça ne consomme pas de ressources). Toutes les cartes que j'ai pu utiliser fonctionnent.
Pourquoi ce n'est pas utilisé alors ? Et bien, c'est simple : le FUD. C'est même comme un couteau dans le coeur que j'ai découvert que même notre chez patrick_g y participe, je crois dans sa news sur le noyau 2.6.31 : «Mais malheureusement il y a toujours les méchantes applications qui utilisent encore toujours le vieux OSS», ou quelque-chose du genre.
Pour beaucoup de gens, OSS est vieux (ils pensent au 3). Pour d'autres, il n'est pas libre (alors qu'il est dispo en GPL et BSD, oui, au choix !).
Comme Linux pour Windows, OSS s'efforce alors d'être compatible. Il a proposé une bibliothèque émulant ALSA (parallèle de Wine), mais il aura fallu attendre que ALSA propose une sortie OSS pour que les applis soient portés.
Étant utilisé en minorité, il est moins supporté. Les gros projets comme HAL, KDE, etc le délaissent, et préfèrent pousser le lourd machin qu'est PulseAudio, ou l'immonde Linux-only ALSA, au lieu d'aider les pauvres développeurs d'OSS qui n'en peuvent plus d'être seuls, depuis des années et des années.
Bref, vous tous qui me lisez, utilisez OSS ! Il s'installe en quelques minutes, même si (FUD oblige) les distribs ne sont pas nombreuses à l'empaqueter. Vos applis ALSA sauront l'utiliser sans problème, KDE aussi après quelques manipulations, et vous aurez un son parfait, qui juste-marche (plus de problèmes avec des applis qui s'accaparent la carte son, avec PulseAudio qui insère des délais énormes, ou qui se met à consommer 100% du CPU).
Mesdames et messieurs, des alternatives existent ! Beaucoup sont passés de Windows à Linux, maintenant passez de ALSA à OSS.
Merci.
(voilà, le post long et inutile du lundi soir :-° )
[^] # Re: très bon test.
Posté par steckdenis (site web personnel) . En réponse au journal Test de KDE 4.4 - Krita demande de l'aide - Setup et la mise à jour. Évalué à 8.
if (machin && truc && brol != chose) {
c = (b == encore ? !truc : chose + 4);
}
Illisible, en tous cas peu clair, et pas si symétrique (t'as une accolade seule sur sa ligne, l'autre sur la ligne du if, donc c'est pas la même chose)
if (machin && truc && brol != chose)
{
c = (b == encore ? !truc : chose + 4);
}
Autre avantage utile pour le debug, vraiment utile :
/* if (un truc qui ne sert à rien, enfin je crois, donc je vire pour voir) */
{
le_code
}
Ça compile encore !
Et puis c'est comme pour mes commentaires et mes sauts de lignes. Plus c'est écarté et découpé, plus les gens comprennent (je préfère avoir 100 personnes qui comprennent et soumettent des patchs, même si 10 n'aiment pas, que de n'avoir que 10 personnes qui comprennent ce que je met)
[^] # Re: Setup
Posté par steckdenis (site web personnel) . En réponse au journal Test de KDE 4.4 - Krita demande de l'aide - Setup et la mise à jour. Évalué à 1.
Pour la progression, c'est un affichage encore un peu expérimental, sachant que la bibliothèque qui gère les paquets envoie à certains intervalles des signaux permettant de savoir ce qui avance ou pas, et que c'est totalement asynchrone. De plus, une progression de type 2/2 permet de signaler que la progression est finie, donc, dans la GUI, d'effacer la barre de progression.
C'est tordu et pas spécialement joli, mais je n'ai pas encore trouvé mieux. C'est cependant sur la feuille de route pour la finale, pour que Setup soit joli (et ne flood pas trop la console quand on télécharge un fichier, aussi).
Merci pour les encouragements.
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par steckdenis (site web personnel) . En réponse au journal Sortie de Setup 0.1-alpha0. Évalué à -3.
Parce que sinon, ça ferait déjà longtemps qu'il y aurai un paquet Logram DE dans Debian, ou alors j'aurais la version 0.5.2 et non 0.5.1 de XMoto dans Fedora, etc.
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par steckdenis (site web personnel) . En réponse au journal Sortie de Setup 0.1-alpha0. Évalué à 3.
Gettext n'est pas lent à l'installation, pas du tout. C'est simplement peu élégant, et encourage la non-traduction. Imagine que tu crées ton paquet perso, par exemple que le dev de Wormux crée son paquet Wormux. Il sait peut-être parler français, anglais et espagnol, mais a-t-il envie de créer des templates Gettext, de les gérer, de les traduire, et de modifier trente six mille fichiers pour que dpkg-buildpackage marche comme il faut ?
Non. Lui, il veut un truc simple. Il ne sait d'ailleurs peut-être même pas qu'on sait faire les traductions de paquets. Setup, lui, fournit une architecture de type [langue]texte[/langue] dans son fichier de métadonnées. Ainsi, si le développeur suit le tuto et se rend compte qu'on lui demande de taper :
< fr >Description< /fr >Il va se rendre compte qu'en replaçant fr par en, il peut traduire super rapidement en anglais. Oui, c'est moins "pro" que du Gettext, mais le résultat est que l'utilisateur aura un paquet dans sa langue, avec le changelog dans sa langue (super Super important ça, pour les mises à jour), une description dans sa langue, etc. C'est typiquement ce type de "finition" qu'il manque au Libre.
Prenez un Windows, et regardez. Tout, absolument tout est traduit. Les rares choses qui ne le sont pas sont des obscures programmes dans system32. Prenez votre distro préférée, même une Mandriva française. Vous trouverez sans problèmes des éléments non-traduits. Oui, le KDE est traduit. Mettez votre système à jour, recherchez un paquet, et *paf*, rien ou presque n'est traduit.
L'utilisateur anglophobe sera totalement perdu. C'est ce genre de problème auxquels il faut faire attention.
Pour le test de transaction, c'est intéressant. J'utilise Fedora et j'ai pu apprécier cet élément. Setup sera un peu plus hackish, mais fera la même chose. En effet, on peut définir l'Installation-Root d'un paquet. Il suffit, quand on installe les paquets, de les installer dans /tmp/teporarytree. Une fois que tout est installé et testé (les postinst() des paquets peuvent servir à vérifier, ainsi que les || exit 1 dans le packagebuild), on copie simplement ce dossier dans /, et c'est fait.
Ainsi, l'utilisateur répondra aux questions, ce sera rapide, et si un paquet échoue, le système est encore stable, laissé intouché. Mieux, ne pas nécessiter les droits root pour cette phase de test, mais seulement pour la copie finale.
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par steckdenis (site web personnel) . En réponse au journal Sortie de Setup 0.1-alpha0. Évalué à 1.
J'ai donné l'exemple des kdelibs après. Grosso-modo, chaque paquet un peu lourd de Debian devient fort complexe. Prends par exemple Grub, un "simple" bootloader, mais qui nécessite un fichier rules kilométrique.
Ensuite, Logram n'a pas encore d'exigence sur les paquets, du fait qu'aucun paquet officiel n'existe. Dès que Setup sera suffisamment avancé, qu'on pourra créer de beaux paquets, les exigences seront mises en places.
Et elles seront draconiennes ! Il y a «les classiques», comme les informations de debug séparées (un petit helper Sepa le permet déjà, puis une petite modification des métadonnées et c'est fait), le strip des éxécutables, etc. Il y aura aussi des choses plus complexes à mettre en oeuvre, indépendemment de Setup, comme par exemple une intégration à KDE partout où c'est possible.
M'enfin, j'avoue que tout ceci n'est pas encore très clair. Setup se développe, je réfléchis de mon côté, plus qu'à voir ce que ça va donner. Je me concentre actuellement plus sur la gestion des Deltas, avec bsdiff, pour drastiquement réduire les téléchargements (et ainsi pouvoir, avec la légèreté de Setup et de Logram DE, viser les OLPC pas puissants du tout, avec petit écran, et mauvaise connexion s'ils en ont).
# De la facilité avec laquelle un paquet Setup est créé
Posté par steckdenis (site web personnel) . En réponse au journal Sortie de Setup 0.1-alpha0. Évalué à 2.
Deux commentaires se plaignent du manque d'arguments en faveur de la simplicité avec laquelle on peut créer un paquet Setup.
Tout d'abord, voici ce que je trouve complexe avec les paquets Deb et Rpm (pour les autres, ABS etc, j'ai dit que j'aimais bien et que je m'en étais inspiré). Pour ces deux types de paquets, créer un «paquet simple» est une affaire de minutes. J'ai eu l'occasion de tester, c'est rapide et facile.
Seulement, quand les paquets deviennent un peu complexes (plusieurs binaires, bibliothèques, etc), ça devient plus difficile. Il faut adapter le Control pour que ça marche, le fichier Rules se complexifie, etc.
Un paquet ne répondant pas strictement aux normes est également plus difficile à produire. Pour le constater, prenez le paquet sources des kdelibs, ou de tout programme KDE empaqueté par l'équipe KDE de Debian. Le rules est simple, oui, mais il commence par une ligne pour inclure une monstrueuse et complexe suite de scripts faisant en sorte que le rules marche.
Pour RPM, j'ai cru voir (mais je n'en suis pas certain) qu'il faut taper manuellement le nom de tous les fichiers qu'on veut inclure dans le paquet. Ok, c'est faisable pour Qtracker ou autre programme composé d'un petit nombre de fichiers, mais essayez un peu avec un truc un peu gros comme OpenOffice.org, FireFox, les kdelibs, etc. Vous allez en avoir vite marre.
Du côté de Setup, un paquet simple est un peu plus compliqué à faire (on a du code à taper), mais la complexité augmente bien moins quand le paquet change. Par exemple, le packagebuild contient les instructions nécessaires à la compilation, à la manière d'un pkgbuild (d'ailleurs, le nom packagebuild s'inspire bien de pkgbuild, comme quoi je sais voir ce qu'il y a de bien chez les autres :) ). Si vous suivez le LFS un de ces jours, vous verrez que toutes les lignes de commandes pour appliquer des patchs sont données. Avec Setup, il suffit de les copier/coller dans le pkgbuild. Avec un paquet Debian (je ne sais pas pour RPM), ça peut aussi se faire mais il faut une adaptation.
Pour le fichier XML, il est auto-documenté (petits commentaires, et balises XML explicites). Le principe du XML n'est pas compliqué à apprendre, même si c'est plus complexe qu'un simple fichier «Clef: Valeur» comme Debian utilise. Par contre, ça permet plein de choses, comme l'arbre DOM. C'est grâce à l'utilisation du XML que les traductions sont si faciles à faire, alors que Debian nécessite un puissant gettext (encore un exemple que Setup reste simple quand Debian se complexifie atrocement). Les règles de validation pour les questions sont également gérées par arbre DOM, ce qui permet de les regrouper, de les modifier, etc. Il y a plein d'autres exemples.
Néanmoins, j'admet que ce n'est pas si simple qu'un PKGBUILD, mais Setup s'oriente un peu plus vers l'user-friendlyness que Pacman. Avec Setup, l'utilisateur peut configurer son paquet graphiquement au moment de l'installation, toutes les chaînes de caractère traduites dans sa langue. Ça a un pris pour le développeur, oui.
[^] # Re: Outil de travail collaboratif
Posté par steckdenis (site web personnel) . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 2.
* Le forum est vraiment inutilisable, même pas moyen de voir facilement les messages lus et non-lus
* Il est très difficile à intégrer à un autre site (j'utilisais Drupal pour les nouvelles et pour son forum)
* Le reste est bien pensé mais un peu trop "sérieux"
Néanmoins, c'est un outil d'une très grande qualité bourré de fonctionnalités très intéressantes, comme les Milestones, les Grantt, les statistiques sur le SVN, etc. Je tiens à féliciter son auteur.
# Raison de l'utilisation de Qt
Posté par steckdenis (site web personnel) . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 10.
Un joli troll de haut niveau a été lancé sur ce journal, pour fêter le vendredi comme il se doit (faut dire que c'est inévitable avec un journal posté le jeudi soir).
Tout d'abord, ne vous en prenez pas à mes connaissances, ce n'est pas "parce que je ne sais rien faire d'autre" que j'ai utilisé Qt. Simplement, je suis le seul codeur, et j'aime le code lisible. Prenez un gestionnaire de paquets pas trop complexe, genre la libalpm (utilisé par Pacman, le gestionnaire de paquets de Arch Linux), et regardez.
Il y a pas mal de code dedans, dont un qui gère le protocole HTTP, un le HTTP, un les différents types de compression, un un système de queue, etc. Au final, quand on veut résoudre un bug sans connaître le code, on prend plus de temps à trouver le fichier et la fonction incriminée qu'à corriger le code.
Qt permet de factoriser le code, et est un avantage technologique. Déjà il permet de ne pas tout recoder (on a la gestion du réseau dedans, la gestion des fichiers de configuration, la gestion du XML, etc). Ensuite, les signaux et les slots peuvent être utiles (par exemple dans la gestion des téléchargements en parallèle, un téléchargement fini déclanchant l'installation de son paquet), et certains modules, comme QtScript, sont un simple bonus.
Logram n'est absolument pas une distribution à vocation serveur. Sur un serveur, installez une Debian, une Red Hat, ou tout autre. Logram, c'est du bureau, du vrais (donc pas un truc comme Ubuntu qui se dit "desktop" parce que ça fait bien, mais qui fournit également une version serveur "parce que ça fait bien aussi").
D'ailleurs, dans le monde du desktop, nous avons Mandriva, qui utilise la suite URPM ... codé en Perl. Ça alors, un langage de script, qui nécessite tout Perl. Même pas une lib, non non, tout un langage. Il faut vraiment leur dire que ça pue, que c'est pas bien, que le C99 juste au dessus de la LibC c'est mieux, non ?
Et bien non. Si l'utilisation d'une bibliothèque de haut niveau permet de sortir un programme de qualité, ou du moins qui a la possibilité de devenir de qualité, on en profite. Rien ne dépend de X, Qt s'installe en quelques secondes, ça occupe 10Mio de disque dur, quelques Mio de RAM, donc c'est rien. Profitons que nous avons un OS correctement conçu qui permet d'installer des bibliothèques sans encrasser une base de registre et ralentir le tout (on est vendredi).
Sinon, je veux bien qu'on fork Setup. Vous allez simplement passer 6 mois à corriger les bugs dans votre implémentation de ce que Qt fournit, comme par exemple les tables de Hash, très utilisées, les listes, les threads, les signaux, la synchronisation, etc.
Ou alors, vous allez utiliser trente six mille bibliothèques, à la manière des applications C générales, pour avoir la même chose. Ce sera plein de dépendances, mais personne ne va s'en plaindre.
Désolé pour le post un peu long, dure journée.
[^] # Re: FTP
Posté par steckdenis (site web personnel) . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 4.
[^] # Re: Quelle surprise dites donc ...
Posté par steckdenis (site web personnel) . En réponse à la dépêche Chakra, la distribution qu'elle est bien. Évalué à 5.
Effectivement, j'écris mes journaux juste après avoir découvert la chose, et le but des journaux est justement ce genre de réactions. Ma dépêche sur LLVM était tout ce qu'il y a de plus correct, normalement.
Dans ce journal, je saluais le travail fait sur Chakra, et sur Arch Linux, qui fait que cette distribution m'a convenu tout de suite.
J'utilise encore Chakra, je l'ai bien personnalisée, et elle me plaît encore toujours tout autant, toujours aussi rapide (même avec un MySQL d'installé, etc).
Bref, ce journal était venu un peu tôt, mais je ne suis pas moins d'accord avec.
Et pour finir, comme je teste plein de choses différentes, c'est toujours le plus_mieux_qu_il_est_bien. Ce n'est pas parce que Chakra est une bonne distro que KOffice ou KDE ne seront plus bons, ou que OSSv4 ne cartonnera plus, ou que Mandriva ne sera plus une excellente distro, ou que GRUB 2 ne sera plus une tuerie, etc. Je ne passe pas ma vie à changer d'avis, je dis simplement quand un truc me plaît (avec exagération, sinon c'est pas marrant il n'y a pas moyen de troller)
[^] # Re: marketing
Posté par steckdenis (site web personnel) . En réponse à la dépêche Chakra, la distribution qu'elle est bien. Évalué à 1.
Moi j'ai un Atom, le genre de bêbete à peine plus puissante qu'un téléphone mobile. Ce truc est certes cadencé à 1,6Ghz, mais ça a un cache de 512K, un bus de carte mère de 133Mhz, bref une architecture plutôt de Pentium 3 ou 2.
Donc oui, 20 secondes sur un P4, c'est 1 minute ou plus sur un Atom. Donc c'est bon :-) .
[^] # Re: marketing
Posté par steckdenis (site web personnel) . En réponse à la dépêche Chakra, la distribution qu'elle est bien. Évalué à 8.
Sinon, ce que je dis est effectivement vrai. Les drakxtools sont superbes, j'ai dis que j'aimais beaucoup Mandriva, mais franchement, rpmdrake est inacceptable :
* Lancer les drakxtools, ça va encore
* Cliquer sur «Installer et supprimer des paquets»
* Attendre 30 ou 40 secondes que ça charge, et encore, je suis certain que ça prend plus.
* Rechercher ses paquets, les sélectionner
* Attendre le temps d'installation (qui lui est correct, bien que largement plus lent que APT, mais c'est pas la faute de rpmdrake)
* à nouveau attendre 50 secondes, sans qu'on puisse rien faire, pour que la GUI se recharge
* Enfin pouvoir cliquer sur Quitter
Je trouve inacceptable de devoir prendre 5 minutes, des vraies minutes, pour installer une bêtise genre Django, Djapian, les libs -devel de Qt et autre. C'est bien trop lent. Heureusement, la ligne de commande est elle parfaitement utilisable.
Du côté de Chakra, et donc de Arch, c'est largement plus rapide. On a un petit splash screen au démarrage de Shaman, qui reste d'ailleurs quelques secondes, puis on sélectionne les paquets, on les installe (et là c'est plus rapide, ou plus lent, ça dépend un peu du temps qu'il fait dehors), et une fois installer, on ferme la fenêtre d'installation.
En dessous, la GUI qui affiche la liste des paquets est encore toujours utilisable, et on peut fermer Shaman ou installer d'autres paquets rapidement, alors que Mandriva efface la liste, ré-explore les paquets et reconstruit tout.
C'est peut-être une différence Perl/C++, le C++ autorisant des programmes procéduraux et Perl encourageant les programmes «en boucles» (même s'il gère les procédures). En tous cas, il y a un problème avec rpmdrake.
PS: Et en plus j'ai dit que c'est la même machine, le même DD, la même quantité de RAM, des partitions de la même taille, etc.
[^] # Re: screenshot , liens ...
Posté par steckdenis (site web personnel) . En réponse au journal Chakra, la distribution qu'elle est bien. Évalué à 6.
En effet, ce site contient une très bonne introduction, plein de screenshots, des explications, un wiki, un forum, etc. C'est un très très bon site d'ailleurs.
[^] # Re: Fais un blog.
Posté par steckdenis (site web personnel) . En réponse au journal Pourquoi j'utilise et utiliserai KDE et KOffice 2. Évalué à 3.
Néanmoins, si il y a 50 ans, quelqu'un t'avais montré un téléphone portable, un eeePC, ou même un ordinateur normal, ne l'aurais-tu pas pris pour un fous ?
Je n'ai pas la prétention de dire que je suis visionnaire, mais il ne faut pas tout de suite jeter des idées.
L'algo de compression est "plausible". Un hash, par exemple, est censé être différent pour chaque fichier qu'un hash, ce qui pourrait vouloir dire qu'un simple sha256 peut contenir des informations. Oui, elles sont dégradées, mais c'est juste possible. J'avais remarqué que les disques durs utilisent un certain codage pour transformer des suites de bits en ondes, et que ces ondes avaient une forme "binaire" (soit hautes, soit basses). On pouvait par exemple encoder 12 bits dans une onde ne présentant de 10 changements d'états, donc 10 bits. C'est une compression, indépendante des données. Il se pourrait donc qu'en appliquant une compression de ce type, on sache compresser le fichier encore plus. Maintenant, cela m'étonnerais que ce soit possible, mais je donne l'idée.
Pour les backdoors, voir visuellement les différences entre les fichiers est encore une fois "plausible". Je n'avance jamais rien en tant que vérité absolue, je dis juste quand j'ai trouvé quelque-chose, en espérant trouver quelqu'un pour dire si c'est possible ou pas. Alors évidemment, si tout ce qu'on me dit est «c'est pas possible, retourne jouer à la petite voiture», j'insiste.
De plus, ce que j'avais avancé (des différences minimes si on change un truc) est certes invérifiable en compilé, mais où se situe du bytecode llvm dedans ? Si le programme qui génère les cartes de différences détecte quand il y a un décalage, il est possible de trouver des différences ne jouant que sur quelques octets, mais décalant tout le reste. Encore une fois, c'est très probablement impossible, mais pas à 100%.
Et pour la gestion des dépendances, alors là non. Mon gestionnaire de dépendances marche, il fait ce qu'il doit, il m'installe mes paquets, supprime mes conflits (même un conflit de provide, donc si "machin" est en conflit avec "www-browser", FireFox et Konqueror seront supprimés). Bref, la théorie est un peu osée, mais les exemples en fin de journal étaient là pour montrer que ça marchait, du moins un peu. Depuis, cet algorithme a été amélioré pour gérer plus de choses et être plus intelligent. C'est une base simple mais solide sur laquelle on peut mettre ce qu'on veut.
Et pour le noyau, je n'ai pas parlé de 50 fois plus vite, simplement que c'est plus réactif. C'est un fait, il existe un réglage «Server», «Desktop», «High responsive desktop», et Debian le règle sur «Server», et moi sur «High responsive desktop». Je n'ai rien inventé, je n'ai fait qu'appliquer une option de configuration du noyau qui fait ce qu'elle est censé faire : améliorer la réponse du système et l'ordonnancement des threads. Ça s'applique particulièrement bien au démarrage car des dizaines de processus sont lancés en même temps, demandent le disque en même temps, demandent du processeur en même temps, etc.
Donc oui, il m'arrive d'un peu trop m'avancer, mais c'est pas parce que je dis une fois une bêtise que tout le reste est bêtise. Alors oui, si on part du principe que je ne racconte que des tissus d'ânerie, jamais on va me trouver pertinent, mais si on me laisse une chance, qui sait, on va peut-être trouver quelque-chose d'utile dans tout ce que je dis.
[^] # Re: Fais un blog.
Posté par steckdenis (site web personnel) . En réponse au journal Pourquoi j'utilise et utiliserai KDE et KOffice 2. Évalué à 2.
Je suis tout à fait conscient du problème, du fait que mon père est daltonien et que j'utilise souvent des programmes en distant avec SSH, sans couleurs (petite connexion).
Pour le moment, Setup utilise beaucoup de couleurs, car c'est assez agréable à utiliser pour ceux qui savent en profiter. Une des choses que j'ai le plus apprécié avec Gentoo est que Portage utilise quelques couleurs (surtout le vert). Ceux qui ont fait un "apt-cache showpkg un_paquet" savent qu'un gros pâté blanc est repoussant.
Pour les dépendances (et pour les légendes «va être installé», «supprimé», etc), oui, c'est particulièrement handicapant. Je commence tout doucement à corriger le problème, et les premiers résultats sont visibles dans la liste des versions d'un paquet : la version installée des précédée d'un "»" au lieu d'une "*".
Pour le reste, je compte en plus des couleurs mettre des signes, comme des flèches, ou des numéros (avec légende). Je dois encore voir comment faire ça sans rendre le code sâle (parce que les couleurs c'est joli, mais en plus ça simplifie le code et évite les qPrintable).
[^] # Re: Fais un blog.
Posté par steckdenis (site web personnel) . En réponse au journal Pourquoi j'utilise et utiliserai KDE et KOffice 2. Évalué à 10.
Ensuite, cd libs/libpackages && qmake && make && sudo make install && cd ../../base/setup && qmake && make && sudo make install.
Résultat en screenshots :
* http://www.logram-project.org/sites/default/files/98SetupVer(...) : affichage de plein d'informations, y compris quand le paquet a été installé, et, bientôt, par qui (http://www.logram-project.org/sites/default/files/99SetupIns(...) ).
* http://www.logram-project.org/sites/default/files/100SetupRe(...) : le solveur en action
* http://www.logram-project.org/sites/default/files/97V4InfosD(...) : intégration au site v4 (j'ai donné le lien plus haut)
* http://www.logram-project.org/fr/node/430 : Installation des paquets en parallèle (installation de plusieurs paquets en même temps, téléchargement sur plusieurs mirroirs, le tout asynchrone avec des files d'attente et tout et tout).
Alors oui, je suis ambitieu, mais moi au moins, je code et ça avance :-° .
Si vous remettez en cause ce que je dis, le premier réflexe devrait être d'aller sur le site de Logram vérifier mes dires dans les news, télécharger le code et tester ;-) .
[^] # Re: Fais un blog.
Posté par steckdenis (site web personnel) . En réponse au journal Pourquoi j'utilise et utiliserai KDE et KOffice 2. Évalué à 10.
Je suis bien d'accord que mes journaux peuvent ne pas intéresser tout le monde, et c'est pour cela que ce sont des journaux, de seconde page qui plus est.
Alors oui, je parle souvent très tôt de ce que je fais, ça a un aspect blog. Je le sais, et c'est pour cela que je poste mes journaux le week-end, le plus souvent, c'est à dire quand il y a peu d'activité. En effet, un journal qui intéressera une minorité des lecteurs n'a pas d'intérêt en pleine semaine quand on croule déjà sous les dépêches. Par contre, le week-end, quand on a une dépêche et deux journaux par jour, le mien n'est pas de trop. Ainsi, ceux qui s'ennuient, réactualisent la page frénétiquement pour voir s'il y a du nouveau seront servis.
Ensuite, ce n'est pas uniquement du vent que je fais. Oui, j'ai parlé d'un concept abstrait sur Setup, mais actuellement, Setup est capable d'installer des paquets, il résout les dépendances, il affiche tout un tas d'informations, il est même intégré à la future version 4 du site de Logram (http://v4dev.logram-project.org/packages-4-1.html , oui, c'est comme packages.debian.org, sauf qu'ici c'est encore en développement, et qu'au menu, on a des commentaires, une notation, des screenshots, etc).
Ici, ce journal n'est pas purement un «Venez tous sous KDE». Honnêtement, je l'ai écrit sur un coup de tête. Je venais d'avoir trouvé un truc très beau dans Krita, et me suis souvenu de tout ce que j'avais déjà découvert. Je me suis alors dit que tout ça pourrait intéresser du monde, et que ceux qui ne sont pas intéressés pourraient trouver des conseils pratiques (si je parle des styles et du plus, qui existent dans OpenOffice.org et partout ailleurs, c'est justement parce que j'ai passé deux jours à trouver ce plus).
Et pour finir, dans tous mes journaux, il y en aura bien un qui va intéresser du monde. Ça arrive assez souvent qu'on me traite d'incompétent, mais généralement, le fond est correct. Dans mon journal «Passage du noyau 2.6.30 Debian au 2.6.31 vanilla», j'ai malencontreusement laissé échapper une petite erreur sur la préemptabilité. S'en sont suivis une dizaine de messages disant que je parle trop vite, et tout et tout. C'est comme ça, on voit toujours plus le mal que font les autres que le bien qu'ils font, donc je n'en veux à personne.
C'est d'ailleurs ça que j'aime dans Linuxfr. Si je postais ces journaux sur mon blog, sur le site de Logram, ou n'importe où ailleurs, je n'aurais que des fanboys disant «Super, génial, vivement que ça sorte», sans même avoir lu. Ici, je sais que j'obtiendrai un retour de qualité, et c'est pour ça que je soumet mes idées ici. Il y en a même, comme «LLVM dans un gestionnaire de paquets», qui intéressent pas mal de monde et qui me font recevoir un livre (même si mes journaux n'ont pas ça comme but).
Désolé pour le message long avec de gros paragraphes.
[^] # Re: Alors
Posté par steckdenis (site web personnel) . En réponse au journal Pourquoi j'utilise et utiliserai KDE et KOffice 2. Évalué à 7.
Ils en utilisent déjà tellement !
* Les thèmes d'icônes, c'est de KDE à la base
* Les fichiers .desktop et le menu des applications, c'est du KDE à la base
* DBUS, c'est plus ou moins comme DCOP
* Il me semble que la norme qui définit comment un gestionnaire de fenêtres se comporte vient de KDE, mais là je suis pas sûr du tout
En tous cas, ça m'a bien fait marrer quand j'ai lu les documentations de Freedesktop.org, et de lire à plein d'endroit «Préférez utiliser [Desktop Entry] au lieu de [KDE Desktop Entry]. Préférez utiliser [Icon theme] au lieu de [KDE icon theme], etc».
[^] # Re: Intégration de G'MIC dans un logiciel tiers
Posté par steckdenis (site web personnel) . En réponse au journal [Imagerie] Avancement du projet G'MIC (version 1.3.2.8). Évalué à 9.
Tout d'abord, toutes mes félicitations pour ce programme. Je ne l'ai pas encore utilisé, mais vu ce qu'il sait faire (le truc avec le sinus en 3D), je suis certain qu'il servira à vraiment plein de monde.
Krita, l'éditeur d'images bitmap de la suite KOffice de KDE, a également pour vocation d'être très avancé technologiquement (il gère les profils de couleurs à 8, 16 et 32-bit depuis des lustres, alors que GIMP a encore du mal). Vu que G'MIC a l'air facile à intégrer, je te propose de faire un petit tours sur le forum de Krita ( http://forum.kde.org/viewforum.php?f=136 ), pour proposer l'intégration de G'MIC dedans.
C'est justement ce genre de choses qu'ils aiment, et qui apporterait d'un coup une énorme suite de fonctionnalités au programme. Ils pourraient même s'en donner à coeur joie et nous coder un joli éditeur de script G'MIC avec aperçu :) !
Et pour finir, c'est justement la bonne période. KOffice vient de recevoir l'aide de Nokia et d'une autre entreprise (j'ai cru entendre parler de 32 développeurs en plus, mais franchement, je ne suis absolument pas certain de cette information), et KOffice 2.1 sortira bientôt. Ils sont donc en phase de stabilisation, en ont marre de corriger des bugs, et attendent de très bonnes idées pour Krita 2.2, surtout quand le travail est déjà fait comme ici.
J'espère franchement pouvoir utiliser une telle merveille dans Krita dans quelques mois. Chapeau bas.
[^] # Re: Et parce qu'on poste toujours trop vite...
Posté par steckdenis (site web personnel) . En réponse au journal Test de la Mandriva Cooker, future 2010.0. Évalué à 2.
Le neuneu moyen, il va télécharger les belles images LiveCD qui sont présentées sur la première page du wiki et sur le site officiel. Les images x86_64, il faut vraiment les vouloir (ici passer par un DVD -je n'ai pas de DVDs-, ou alors il paraît que les PowerPack contiennent une version 64-bit. On peut aussi prendre des images minimales, mais ce n'est pas l'idéal pour le débutant).
Pour la majorité des utilisateurs, seule la version i586 existe, donc ils la prennent, et comme ils sont nombreux, les développeurs vont bien déboguer les paquets i586 (de même que plus d'utilisateurs enverront leurs bugs).
[^] # Re: Et parce qu'on poste toujours trop vite...
Posté par steckdenis (site web personnel) . En réponse au journal Test de la Mandriva Cooker, future 2010.0. Évalué à 1.
* Je vois que les paquets sont du genre "lib64qt4", ce qui me fait croire qu'on peut toujours avoir un système "à moitié" en 32-bit. Fedora avait ce problème, car tous les paquets qu'on installait l'étaient en 32-bit sauf si on demandait explicitement le contraire (Fedora 9, ça date)
* Vu que quasi tout le monde utilise la version 32-bit, il faudrait s'assurer que les paquets 64-bit soient de la même qualité.
Bref, ça me convient pour le moment, et me permet de tester GCC 4.4.
# Et parce qu'on poste toujours trop vite...
Posté par steckdenis (site web personnel) . En réponse au journal Test de la Mandriva Cooker, future 2010.0. Évalué à 3.
J'ai, première fois de ma vie, formatté ma partition en XFS, pour tester. Il faut dire que je n'en n'avais entendu que du bien, performant, sans checkdisk au démarrage, rapide à formatter, solide, etc. Je ne suis pas déçu ! Le démarrage est bien rapide, je l'ai dit dans le journal, mais je viens aussi d'importer ma collection de musiques dans Amarok. Sous Debian, ça prenait une dizaine de secondes. Ici, ça a pris 2 secondes, et encore !
Deuxième point, les thèmes. Quand la 3D est activée, on a des décorations de fenêtres genre Oxygen, mais avec quelques modifications (qui personnellement ne me plaisent pas trop). Le thème de widgets, unifié entre GNOME et KDE, est léger et épuré. Il est également gentil pour le processeur, ce qui fait que l'ensemble de l'interface semble bien fluide. Pour tout ce qui est fond d'écran et écran de démarrage, c'est très joli.
Par contre, énorme point noir, c'est du i586. J'ai donc un KDE SVN compilé et tous ses modules qui se trouve impossible à lancer, de même qu'un Qt snapshot Git (future 4.6). Je sens que ça va compiler sec ces prochains jours (toujours mon petit Atom qui compile 1 SBU* en près de 25 minutes).
* http://www.linuxfromscratch.org/lfs/view/development/chapter(...)
[^] # Re: Et aussi...
Posté par steckdenis (site web personnel) . En réponse au journal Passage du noyau Debian 2.6.30-2 au noyau Vanilla 2.6.31-2. Évalué à 2.
Je ne sais pas si je pourrai recompiler une autre version de mon noyau. J'ai un simple Atom à 1,6Ghz, et plein de choses à faire. Une compilation prend vraiment beaucoup de temps, temps pendant lequel je ne sais que surfer sur internet ... et pas compiler les programmes que je développe.
Si quelqu'un a une meilleure machine, ce serait effectivement intéressant de voir si c'est le changement de noyau ou la recompilation qui change tout.
PS: Mise à jour des données : redémarrage en quelques secondes à peine, mais le KDE prend plus ou moins 50 secondes à démarrer maintenant. La différence est du au fait que lors de mon premier test, Kate n'était pas lancé.
[^] # Re: Ubuntu
Posté par steckdenis (site web personnel) . En réponse au journal Passage du noyau Debian 2.6.30-2 au noyau Vanilla 2.6.31-2. Évalué à 1.
Noon ! J'ai compilé la version .2 hier et je vois maintenant que la .3 est sortie. J'ai vraiment pas de chance (la dernière fois j'ai compilé un 2.6.28 quand le 2.6.29 était en rc, le temps de la compile, la version finale était sortie).
/hs