Je n'ai pas fini. Le noyau. Il faut le compiler, le noyau. Linux, c'est mieux avec un noyau adapté à son usage. Euh, y a encore quelqu'un qui le fait aujourd'hui? 1 pourcent des linuxiens?
À l'époque, on compilait son noyau au lieu d'utiliser celui de sa distribution pour quatre raisons :
- optimiser pour son processeur : cela fait quelques années que le kernel a une option d'autodétection des capacités du processeur au boot qui règle le problème contre quelques ko. MPlayer aussi possède cette autodétection.
- éviter les modules : entre ata ou scsi, il fallait choisir lequel mettre dans son noyau pour monter sa partition racine et trouver les autres modules, il fallait charger tout module "à la main" ...
Maintenant, la plupart des distributions utilisent un initrd en standard et ont une bonne autodétection du matériel. Les modules ne sont plus une plaie mais une souplesse de d'utilisation. Vous souvenez-vous de l'époque où on ne pouvait pas migrer un disque dur d'une machine HS à une autre parce que le noyau était prévu pour le mauvais processeur ou n'avait pas le driver de la carte réseau ?
- avoir la dernière version : sans internet, je récupérais les sources du tout nouveau noyau 2.4.12 dans Planète Linux et le compilais à la main, maintenant avec l'adsl et les rolling-releases, ce n'est plus nécessaire.
- faire joujou : ceux qui veulent tester les dernières RC ou la fameuse branche -mm continuent à compiler depuis les sources bien entendu. Pour ma part je préfère utiliser mon CPU pour compiler KDE 4.2beta2 :)
Pour moi le fait qu'on ne recompile plus son noyau soi même est le signe d'une maturation du kernel (autodétection, modularisation) et de son intégration dans les distributions (initrd, hotplug), c'est donc une bonne chose.
OpenSUSE est le champion du backport à l'arrache et fait bien plus de modification que ubuntu ; je ne le conseillerai absolument pas pour avoir une expérience du KDE "vanilla".
As-tu fait en réalité ce dont tu parles? On m'a toujours dit "la communauté", mais je tombes très souvent en faisant des recherches sur des gens qui ont la même question que moi, mais... qui n'ont jamais de réponse.
Je suis contributeur Debian et KDE, et en posant les bonnes questions aux bonnes personnes j'obtiens généralement l'information ou le coup de pouce dont j'ai besoin. Mais il ne faut pas oublier que le logiciel libre marche à la méritocratie et que les gens ne sont pas obligés de répondre (bénévoles, humains faillibles, ...), surtout si :
- la question est posée dans la mauvaise mailing list (c'est usant à force, donc on ignore, surtout quand des questions de support sont posées dans une ML de développement)
- les formes n'y sont pas (débarquer sur un chan et poser une question sans même dire bonjour, ou utiliser un ton dénigrant / agressif)
- la réponse est dans la FAQ / les tutoriels de base
C'est malheureux, mais le nombre énorme de lusers [http://en.wikipedia.org/wiki/Luser] qui nous sollicitent chaque jour que RMS fait rend les développeurs peu accueillants au premier abord (et ça n'ira malheureusement pas en s'arrangeant avec les boulets qui découvrent linux pour sa gratuité et ne cherchent pas à comprendre comment marche le LL avant de se plaindre que les développeurs ne font pas leurs quatre volontés).
Mais si la forme y est, les nouveaux contributeurs sont toujours bien accueillis (en tout cas chez KDE et Debian).
Pourquoi pas des normes communes pour un interfacage entre un programme et un WM par exemple? Ca enlèverait de la diversité? non. Ca simplifierai le portage? Oui.
J'ai vraiment l'impression que tu ne sais pas trop de quoi tu parles.
Un window manager est un programe chargé de la gestion des fenêtres et de leur affichage, c'est tout. kwin est un WM ; metacity est un WM ; xmonad est un WM. L'interaction application-WM (maximiser une fenêtre, dialogue modal, enlever les bordures, ...) est assez bien standardisée (dans X11 même).
KDE est un environnement de bureau, GNOME est un environnement de bureau, XFCE est un environnement de bureau. Ce terme regroupe un nombre énorme d'applications et de fonctionnalités (du WM au système de notifications en passant par l'application de gestion des emails et le jeu de mahjongg) interagissant pour fournir une expérience utilisateur homogène et une intégration des différentes parties. Quand tu parles du menu clic-droit, je pense que tu parles de konqueror/dolphin, nautilus et consors. Ce sont des gestionnaires de fichiers, pas des WM.
Oui, les normes freedesktop.org ne couvent pas tout, mais on ne peut pas en quelques années rattraper 10 ans de "guerre" entre les différents environnements de bureau, surtout quand pour définir une norme il faut que des développeurs des deux camps se motivent pour créer une spec commune et l'implémenter à la place de leur système déjà en place (et qui marche bien). Si tu veux voir l'ampleur de la tâche, une spécification est en cours d'élaboration pour le système de notification, et ce n'est pas la joie.
Quand à l'intégration dans les différents gestionnaires de fichiers, c'est souvent l'affaire d'un simple fichier texte, 15 minutes grand maximum pour une personne expérimentée. Demander gentiment et humblement dans les canaux IRC appropriés sera plus fructueux que geindre sur trollfr. Et oui, dans la "communauté" il faut accepter de dépendre d'autres personnes et travailler avec eux, tout ne se fait pas tout seul automatiquement.
Je le vois déjà pour Horde IMP par exemple, pas petit quand même (je dirai même gros), le délai entre une version sur le site web et une dispo sous le repo Debian officiel etc... long :
- Sur le site web officiel http://www.horde.org/imp/ : IMP 4.3 est sorti 26 septembre, soit plus d'un mois
- Sur Debian Testing http://packages.debian.org/testing/imp4 : toujorus IMP 4.2, toujours...
1 mois, c'est énorme comme délai, non acceptable. Et c'est pour une grosse appli PHP. Pour une petite?
L'exemple du paquet Debian est fallacieux car Debian Lenny est actuellement en période de freeze : aucune nouvelle version upstream n'est acceptée dans testing, seulement les corrections de bugs.
La nouvelle version n'est pas dans unstable non plus, certainement pour pouvoir y placer de nouveaux candidats à Lenny (comme c'est le cas pour OpenOffice 3.0 et KDE 4.1 qui attendent dans experimental que Lenny sorte).
Il n'y a pas de bijection entre RVB et CMJN. Quelques exemples :
- beaucoup de couleurs RVB ne sont pas imprimables car impossibles à créer en CMJN. Les logiciels approximent souvent à la couleur imprimable la plus proche, mais le rendu est souvent décevant ;
- on peut avoir envie de mélanger du noir avec une autre couleur, pour faire du noir soutenu (ajouter du bleu quand le noir est trop pâle), éviter les zones blanches en cas de décalage ou autre. Dans d'autres cas c'est à éviter. Il est impossible de représenter cette information en RVB (noir c'est noir, il n'y a plus d'espoir) ;
- on utilise souvent des encres Pantone, ou tons directs au lieu de mélanger des couleurs de base. Le CMJN + profil gère ces couleurs supplémentaires, pas le RVB ;
De plus, si le client ne connaît pas le CMJN, il est probable qu'il ne connaisse pas la notion de profil de couleurs et se plaigne que le rendu final ne soit pas le même que sur son écran non calibré. C'est une assurance pour l'imprimeur.
Quand tu signes un contrat, il est évident d'employer une langue connue des deux parties et de lever le maximum d'ambiguïtés ? Ici c'est pareil, le CMJN + profil permet à l'imprimeur de savoir que le client commande vraiment ce qui est dans le fichier et pas un rendu parmi la centaine possible selon l'algorithme employé.
L'imprimerie est assez complexe à la base, inutile de rajouter encore de l'aléatoire.
Etch utilise une version 0.8 de digikam. Le bug est corrigé depuis longtemps mais visiblement le mainteneur n'a pas envie de backporter la correction de 0.9 .....
Il est formellement déconseillé de backporter du code dans debian stable, car tout patch peut potentiellement introduire des bugs et compliquer le suivi par la security team. Le manuel de référence du développeur Debian [http://www.debian.org/doc/manuals/developers-reference/pkgs.(...)] cite trois grands cas où un patch dans stable est envisageable :
- problème critique de fonctionnement (application qui ne démarre pas du tout ou qui est dangereuse pour les données / le système)
- paquet impossible à installer (à cause de la mise à jour d'un autre paquet par exemple)
- ajout d'une architecture
La retouche d'image n'étant pas le "fond de commerce" de l'appli et pouvant être géré par un autre programme, je comprends que le mainteneur n'ait pas jugé bon de faire un patch.
Il est vrai que etch n'est vraiment pas la priorité de l'équipe kde/kde-extras, mais il est possible de backporter assez facilement un paquet de testing dans le dépôt backports.org. Encore faut-il que plusieurs utilisateurs le demandent cordialement au lieu de réclamer et de se plaindre.
Et pour finir, si quelqu'un connaît un logiciel boursier d'analyse technique sous linux permettant également l'analyse des valeurs intra-day, je prends !
Parce que la marque Linux a le vent en poupe ?
Parce que c'est un noyau éprouvé et pour lequel il est relativement simple de trouver des developpeurs ?
Parce que les ingés de google ont pris celui qu'ils connaissaient le mieux ?
Parce que le noyau Linux n'est pas indiscociable de GNU/Linux, et que le principe d'UNIX est de pouvoir échanger les briques de base ?
Même bug chez konqueror.
C'est très certainement un bug de la toolbar qui ne nettoie pas correctement l'ancien CSS, et le navigateur s'enmêle les pinceaux.
Dans tous les cas, un reload de la page corrige le problème.
Malgré l'attention générale focalisée sur les spywares, le bon vieux virus qui a juste pour but de flinguer ton matos existe encore. Ce bug du noyau expose une vulnérabilité du matériel qui peut potentiellement être exploité par un virus (bien que j'espère que seul le driver peut aller farfouiller le microcode, même sous windows).
La grosse faille de la comparaison est l'opposition bénévole / entreprise : KDE et GNOME sont portés en grande partie par des bénévoles qui codent pour le plaisir de coder et de façonner de leur main leur environnement de travail. Une société pense plus en retour sur investissement : pourquoi payer une équipe à faire un filtre d'image si on pourra le pomper chez le concurrent dans un mois ? Et inversement, pourquoi innover quand tout cet argent investi ne donnera finalement pas d'avantage stratégique (le concurrent ayant repompé).
Après, les API ouvertes pour le matos, je suis totalement pour, mais c'est vraiment un tout autre problème !
Pour Qt 4.4, le style Cleanlooks ressemblant beaucoup au style gtk du même nom est disponible.
Trolltech a développé un style Qt qui utilise gtk pour le rendu [http://linuxfr.org/~tanguy_k/26635.html], il est compilable avec Qt 4.4 et sera intégré dans Qt 4.5. Celui ci permettra une réelle intégration, comme gtk-qt le fait dans l'autre sens depuis quelque temps déjà.
En lisant le titre du journal, j'ai pensé en premier lieu aux appareils électroménagers "jetables" qui sont conçus exprès pour ne durer que 12 mois (machines à laver, matériel de bricolage d'entrée de gamme, ...) et pas un de plus, histoire de continuer à faire tourner les usines d'année en année.
Si seulement ce phénomène se limitait à l'entrée de gamme chinois, ça irai, mais désormais, tout le monde s'y met. Il est loin le temps où on gardait sa machine à laver 5 ans. Malheureusement, c'est trop difficile à évaluer pour faire un barème fiable et assez dissuasif pour les tricheurs.
Google Chrome sera à Firefox ce que Ubuntu est à Debian
Tu veux dire que Chrome :
- a repompé tout le code de firefox et juste changé le thème par défaut pour sa première release ?
- clamé sur tous les toits qu'il a inventé les onglets et les plugins ?
Non, je crois pas que l'analogie tienne vraiment en fait ;)
Ces clefs servent à signer les listes de paquets (/debian/dist/*/Release), qui sont bien sûr régénérées automatiquement quand un nouveau paquet est disponible. Ces clefs sont installées par le paquet debian-archive-keyring [cf http://packages.debian.org/sid/debian-archive-keyring].
Les paquets sont signés manuellement par la clef GPG d'un développeur Debian. Les clefs publiques sont disponibles dans le paquet debian-keyring [cf http://packages.debian.org/sid/debian-keyring]. Même si la clef automatique est corrompue, si quelqu'un l'utilise pour ajouter un paquet à l'archive, apt se plaindra que ledit paquet n'est pas signé et demandera confirmation.
Les paquets Debian sont signés par la clef GPG de la personne ayant uploadé le package. Un package contient les clefs publiques de tous les DD et est mis à jour quand un nouveau Debian Developper est désigné.
Il n'y a pas à ma connaissance de signature automatisée des paquets.
Il sera disponible à l'url http://kde4.debian.net/ , certainement au moment de la sortie officielle de lenny.
En attendant, tous les paquets sont disponibles dans experimental, pour les utilisateurs de unstable : http://pkg-kde.alioth.debian.org/experimental.html (utilisables sous testing pour les habitués de l'apt-pinning)
Puisque tu parles de Quanta, un gros boulot de factorisation du code entre Quanta et Kdevelop a donné naissance au module kdevplatform. Kdevelop4 et kdevplatform sont attendus pour janvier, en même temps que KDE 4.2. J'imagine (mais je ne peux pas l'assurer) que Quanta plus va rejoindre kdewebdev pour KDE 4.2 aussi.
Pour koffice, les versions alpha sont prometteuses, bien que la liste des fonctions à implémenter soit loin d'être vide [http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.(...)]. Une beta1 est prévue fin septembre, mais aucune promesse quand à la version finale.
Un petit tour des programmes extragear :
- on peut espérer Amarok 2 pour fin 2008 ;
- digikam vient de publier sa deuxième beta et se rapproche de la release ;
- k3b est encore en cours de portage ;
- ktorrent a bien bénéficié de son passage à KDE4, au point d'être inclus dans debian lenny (qui a gardé KDE 3.5.9. Au passage, un dépôt KDE 4.1 officiel pour lenny est en cours de création)
- kile (éditeur latex) se fait désirer, je n'ai pas pu trouver d'information quand à l'avancement du portage ;
- le méconnu, mais tellement pratique yakuake [http://yakuake.uv.ro/] est disponible depuis quelque temps ;
- konq-plugins, la compilation de plugins de konqueror (auparavant dans kdeaddons) a vu sa première release en même temps que KDE 4.1, il doit maintenant être dans toutes les bonnes distributions.
Parce que tous les projets n'ont pas la main d'œuvre nécessaire, surtout pour un travail assez ingrat ? Ce travail est assez bien réalisé à mon avis par les sites communautaires et les forums des distributions, il suffit de chercher un peu. D'expérience, 99% des problèmes utilisateurs de résolvent avec des articles référencés dans les deux premières pages de résultats google.
Quand au tri de bugs avant soumission aux developpeurs, c'est le rôle des bugzilla des différentes distributions !
# Moi pour noel ...
Posté par gemegik . En réponse à la dépêche iPod : sept ans de « progrès » dans l'emprisonnement numérique. Évalué à 10.
Et vous me l'avez cassé :(
# Noyau
Posté par gemegik . En réponse au journal Le meilleur du troll: c'était mieux avant!. Évalué à 8.
À l'époque, on compilait son noyau au lieu d'utiliser celui de sa distribution pour quatre raisons :
- optimiser pour son processeur : cela fait quelques années que le kernel a une option d'autodétection des capacités du processeur au boot qui règle le problème contre quelques ko. MPlayer aussi possède cette autodétection.
- éviter les modules : entre ata ou scsi, il fallait choisir lequel mettre dans son noyau pour monter sa partition racine et trouver les autres modules, il fallait charger tout module "à la main" ...
Maintenant, la plupart des distributions utilisent un initrd en standard et ont une bonne autodétection du matériel. Les modules ne sont plus une plaie mais une souplesse de d'utilisation. Vous souvenez-vous de l'époque où on ne pouvait pas migrer un disque dur d'une machine HS à une autre parce que le noyau était prévu pour le mauvais processeur ou n'avait pas le driver de la carte réseau ?
- avoir la dernière version : sans internet, je récupérais les sources du tout nouveau noyau 2.4.12 dans Planète Linux et le compilais à la main, maintenant avec l'adsl et les rolling-releases, ce n'est plus nécessaire.
- faire joujou : ceux qui veulent tester les dernières RC ou la fameuse branche -mm continuent à compiler depuis les sources bien entendu. Pour ma part je préfère utiliser mon CPU pour compiler KDE 4.2beta2 :)
Pour moi le fait qu'on ne recompile plus son noyau soi même est le signe d'une maturation du kernel (autodétection, modularisation) et de son intégration dans les distributions (initrd, hotplug), c'est donc une bonne chose.
[^] # Re: Avis perso
Posté par gemegik . En réponse au journal Béranger passe à Windows. Évalué à 1.
[^] # Re: Problème sous linux aussi
Posté par gemegik . En réponse au journal Maintenez votre Windows à jour.... Évalué à 3.
Je suis contributeur Debian et KDE, et en posant les bonnes questions aux bonnes personnes j'obtiens généralement l'information ou le coup de pouce dont j'ai besoin. Mais il ne faut pas oublier que le logiciel libre marche à la méritocratie et que les gens ne sont pas obligés de répondre (bénévoles, humains faillibles, ...), surtout si :
- la question est posée dans la mauvaise mailing list (c'est usant à force, donc on ignore, surtout quand des questions de support sont posées dans une ML de développement)
- les formes n'y sont pas (débarquer sur un chan et poser une question sans même dire bonjour, ou utiliser un ton dénigrant / agressif)
- la réponse est dans la FAQ / les tutoriels de base
C'est malheureux, mais le nombre énorme de lusers [http://en.wikipedia.org/wiki/Luser] qui nous sollicitent chaque jour que RMS fait rend les développeurs peu accueillants au premier abord (et ça n'ira malheureusement pas en s'arrangeant avec les boulets qui découvrent linux pour sa gratuité et ne cherchent pas à comprendre comment marche le LL avant de se plaindre que les développeurs ne font pas leurs quatre volontés).
Mais si la forme y est, les nouveaux contributeurs sont toujours bien accueillis (en tout cas chez KDE et Debian).
[^] # Re: Problème sous linux aussi
Posté par gemegik . En réponse au journal Maintenez votre Windows à jour.... Évalué à 4.
J'ai vraiment l'impression que tu ne sais pas trop de quoi tu parles.
Un window manager est un programe chargé de la gestion des fenêtres et de leur affichage, c'est tout. kwin est un WM ; metacity est un WM ; xmonad est un WM. L'interaction application-WM (maximiser une fenêtre, dialogue modal, enlever les bordures, ...) est assez bien standardisée (dans X11 même).
KDE est un environnement de bureau, GNOME est un environnement de bureau, XFCE est un environnement de bureau. Ce terme regroupe un nombre énorme d'applications et de fonctionnalités (du WM au système de notifications en passant par l'application de gestion des emails et le jeu de mahjongg) interagissant pour fournir une expérience utilisateur homogène et une intégration des différentes parties. Quand tu parles du menu clic-droit, je pense que tu parles de konqueror/dolphin, nautilus et consors. Ce sont des gestionnaires de fichiers, pas des WM.
Oui, les normes freedesktop.org ne couvent pas tout, mais on ne peut pas en quelques années rattraper 10 ans de "guerre" entre les différents environnements de bureau, surtout quand pour définir une norme il faut que des développeurs des deux camps se motivent pour créer une spec commune et l'implémenter à la place de leur système déjà en place (et qui marche bien). Si tu veux voir l'ampleur de la tâche, une spécification est en cours d'élaboration pour le système de notification, et ce n'est pas la joie.
Quand à l'intégration dans les différents gestionnaires de fichiers, c'est souvent l'affaire d'un simple fichier texte, 15 minutes grand maximum pour une personne expérimentée. Demander gentiment et humblement dans les canaux IRC appropriés sera plus fructueux que geindre sur trollfr. Et oui, dans la "communauté" il faut accepter de dépendre d'autres personnes et travailler avec eux, tout ne se fait pas tout seul automatiquement.
[^] # Re: Problème sous linux aussi
Posté par gemegik . En réponse au journal Maintenez votre Windows à jour.... Évalué à 7.
- Sur le site web officiel http://www.horde.org/imp/ : IMP 4.3 est sorti 26 septembre, soit plus d'un mois
- Sur Debian Testing http://packages.debian.org/testing/imp4 : toujorus IMP 4.2, toujours...
1 mois, c'est énorme comme délai, non acceptable. Et c'est pour une grosse appli PHP. Pour une petite?
L'exemple du paquet Debian est fallacieux car Debian Lenny est actuellement en période de freeze : aucune nouvelle version upstream n'est acceptée dans testing, seulement les corrections de bugs.
La nouvelle version n'est pas dans unstable non plus, certainement pour pouvoir y placer de nouveaux candidats à Lenny (comme c'est le cas pour OpenOffice 3.0 et KDE 4.1 qui attendent dans experimental que Lenny sorte).
[^] # Re: Trackpoint
Posté par gemegik . En réponse au journal Elle a 40 ans,.... Évalué à 10.
Apple l'a fait, il faut donc que tout le monde le fasse pour ne pas être has-been.
[^] # Re: Scribus
Posté par gemegik . En réponse à la dépêche Linux Planète répond à vos questions. Évalué à 4.
- beaucoup de couleurs RVB ne sont pas imprimables car impossibles à créer en CMJN. Les logiciels approximent souvent à la couleur imprimable la plus proche, mais le rendu est souvent décevant ;
- on peut avoir envie de mélanger du noir avec une autre couleur, pour faire du noir soutenu (ajouter du bleu quand le noir est trop pâle), éviter les zones blanches en cas de décalage ou autre. Dans d'autres cas c'est à éviter. Il est impossible de représenter cette information en RVB (noir c'est noir, il n'y a plus d'espoir) ;
- on utilise souvent des encres Pantone, ou tons directs au lieu de mélanger des couleurs de base. Le CMJN + profil gère ces couleurs supplémentaires, pas le RVB ;
De plus, si le client ne connaît pas le CMJN, il est probable qu'il ne connaisse pas la notion de profil de couleurs et se plaigne que le rendu final ne soit pas le même que sur son écran non calibré. C'est une assurance pour l'imprimeur.
Quand tu signes un contrat, il est évident d'employer une langue connue des deux parties et de lever le maximum d'ambiguïtés ? Ici c'est pareil, le CMJN + profil permet à l'imprimeur de savoir que le client commande vraiment ce qui est dans le fichier et pas un rendu parmi la centaine possible selon l'algorithme employé.
L'imprimerie est assez complexe à la base, inutile de rajouter encore de l'aléatoire.
[^] # Re: ubuntu
Posté par gemegik . En réponse au journal Performance de Linux, le troll de ce Vendredi vous est offert par Phoronix. Évalué à 2.
Il est formellement déconseillé de backporter du code dans debian stable, car tout patch peut potentiellement introduire des bugs et compliquer le suivi par la security team. Le manuel de référence du développeur Debian [http://www.debian.org/doc/manuals/developers-reference/pkgs.(...)] cite trois grands cas où un patch dans stable est envisageable :
- problème critique de fonctionnement (application qui ne démarre pas du tout ou qui est dangereuse pour les données / le système)
- paquet impossible à installer (à cause de la mise à jour d'un autre paquet par exemple)
- ajout d'une architecture
La retouche d'image n'étant pas le "fond de commerce" de l'appli et pouvant être géré par un autre programme, je comprends que le mainteneur n'ait pas jugé bon de faire un patch.
Il est vrai que etch n'est vraiment pas la priorité de l'équipe kde/kde-extras, mais il est possible de backporter assez facilement un paquet de testing dans le dépôt backports.org. Encore faut-il que plusieurs utilisateurs le demandent cordialement au lieu de réclamer et de se plaindre.
[^] # Re: Parce qu'aucune distribution...
Posté par gemegik . En réponse au journal Une petite réflexion .... Évalué à 2.
C'est quoi la bourse ?
[^] # Re: on nous aurait menti ?
Posté par gemegik . En réponse à la dépêche Pré-version de démonstration de QtCreator (dit Greenhouse). Évalué à 10.
Ça c'est le côté "héritier de emacs" :)
[^] # Re: En bref
Posté par gemegik . En réponse au journal Sources d'android disponibles.. Évalué à 6.
Parce que c'est un noyau éprouvé et pour lequel il est relativement simple de trouver des developpeurs ?
Parce que les ingés de google ont pris celui qu'ils connaissaient le mieux ?
Parce que le noyau Linux n'est pas indiscociable de GNU/Linux, et que le principe d'UNIX est de pouvoir échanger les briques de base ?
# Logo KDE4
Posté par gemegik . En réponse à la dépêche Concours Qt "Pimp My Widgets". Évalué à 1.
http://upload.wikimedia.org/wikipedia/commons/8/8d/KDE_logo.(...)
[^] # Re: 2ème édition
Posté par gemegik . En réponse au journal Nouveau style CSS. Évalué à 1.
C'est très certainement un bug de la toolbar qui ne nettoie pas correctement l'ancien CSS, et le navigateur s'enmêle les pinceaux.
Dans tous les cas, un reload de la page corrige le problème.
[^] # Re: La communauté Ubuntu Server enquête
Posté par gemegik . En réponse à la dépêche La communauté Ubuntu Server enquête. Évalué à 9.
[^] # Re: Ah? Bientôt un nouveau virus pour windaube?
Posté par gemegik . En réponse au journal Corruption hardware fatal sur les noyaux 2.6.27-rc. Évalué à 1.
[^] # Re: non a la licence globale !
Posté par gemegik . En réponse au journal Geeks encore un effort si nous voulons être libre. Évalué à 2.
Après, les API ouvertes pour le matos, je suis totalement pour, mais c'est vraiment un tout autre problème !
[^] # Re: wiki down .. troll survives
Posté par gemegik . En réponse à la dépêche Sortie de VLC Media Player 0.9.2. Évalué à 6.
Trolltech a développé un style Qt qui utilise gtk pour le rendu [http://linuxfr.org/~tanguy_k/26635.html], il est compilable avec Qt 4.4 et sera intégré dans Qt 4.5. Celui ci permettra une réelle intégration, comme gtk-qt le fait dans l'autre sens depuis quelque temps déjà.
# D'autres types de jetable
Posté par gemegik . En réponse au journal [HS] taxer les produits jetables ?. Évalué à 5.
Si seulement ce phénomène se limitait à l'entrée de gamme chinois, ça irai, mais désormais, tout le monde s'y met. Il est loin le temps où on gardait sa machine à laver 5 ans. Malheureusement, c'est trop difficile à évaluer pour faire un barème fiable et assez dissuasif pour les tricheurs.
[^] # Re: non mais y'a de la place pour tout le monde
Posté par gemegik . En réponse au journal Chrome, le futur navigateur de Google. Évalué à 8.
Tu veux dire que Chrome :
- a repompé tout le code de firefox et juste changé le thème par défaut pour sa première release ?
- clamé sur tous les toits qu'il a inventé les onglets et les plugins ?
Non, je crois pas que l'analogie tienne vraiment en fait ;)
--
Le troll est un art de vivre ©
[^] # Re: Les clefs ne sont pas au coffre
Posté par gemegik . En réponse au journal Intrusion sur les serveurs Fedora/Red Hat. Évalué à 0.
Les paquets sont signés manuellement par la clef GPG d'un développeur Debian. Les clefs publiques sont disponibles dans le paquet debian-keyring [cf http://packages.debian.org/sid/debian-keyring]. Même si la clef automatique est corrompue, si quelqu'un l'utilise pour ajouter un paquet à l'archive, apt se plaindra que ledit paquet n'est pas signé et demandera confirmation.
[^] # Re: Les clefs ne sont pas au coffre
Posté par gemegik . En réponse au journal Intrusion sur les serveurs Fedora/Red Hat. Évalué à 3.
Il n'y a pas à ma connaissance de signature automatisée des paquets.
[^] # Re: Et les autres gros projets KDE ?
Posté par gemegik . En réponse à la dépêche KDE 4.1 : Don't Look Back. Évalué à 1.
En attendant, tous les paquets sont disponibles dans experimental, pour les utilisateurs de unstable : http://pkg-kde.alioth.debian.org/experimental.html (utilisables sous testing pour les habitués de l'apt-pinning)
[^] # Re: Et les autres gros projets KDE ?
Posté par gemegik . En réponse à la dépêche KDE 4.1 : Don't Look Back. Évalué à 2.
Pour koffice, les versions alpha sont prometteuses, bien que la liste des fonctions à implémenter soit loin d'être vide [http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.(...)]. Une beta1 est prévue fin septembre, mais aucune promesse quand à la version finale.
Un petit tour des programmes extragear :
- on peut espérer Amarok 2 pour fin 2008 ;
- digikam vient de publier sa deuxième beta et se rapproche de la release ;
- k3b est encore en cours de portage ;
- ktorrent a bien bénéficié de son passage à KDE4, au point d'être inclus dans debian lenny (qui a gardé KDE 3.5.9. Au passage, un dépôt KDE 4.1 officiel pour lenny est en cours de création)
- kile (éditeur latex) se fait désirer, je n'ai pas pu trouver d'information quand à l'avancement du portage ;
- le méconnu, mais tellement pratique yakuake [http://yakuake.uv.ro/] est disponible depuis quelque temps ;
- konq-plugins, la compilation de plugins de konqueror (auparavant dans kdeaddons) a vu sa première release en même temps que KDE 4.1, il doit maintenant être dans toutes les bonnes distributions.
[^] # Re: Paille, poutre toussa
Posté par gemegik . En réponse au journal Ce qui manque à GNU/LINUX : le souci de l'utilisateur et le professionnalisme. Évalué à 0.
Quand au tri de bugs avant soumission aux developpeurs, c'est le rôle des bugzilla des différentes distributions !