> C'est libre, les gens qui portent NetBSD sur un grille-pain le font parce qu'ils sont content de le faire.
Comme Linux, comme tout ce qui est libre.
> Ensuite, j'ai un NetBSD 4 avec 8Go de RAM
Le problème de 2 Go doit être par processus.
> Pour info, voici le nombre de libre specifique à x86-64, c'est à dire qui ne sont pas l'arbre de source general, pour simplifier.
Et ?
Je ne dois pas comprendre. J'ai une F8 sous x86_64, c'est les même source que pour i386, ppc et ppc64. Évidemment, il doit y avoir des "ifdef ...". Pour ce qui est "spécifique" x86_64, c'est dans linux/arch/x86_64 (ou un truc dans ce goût). Branche qui a été fusionnée avec i386 dans Linux 2.6.24.
Bref, pour comptabiliser, c'est quasi impossible. Alors c'est peut-être "pire" que NetBSD, mais il y a plus de 4 Go de mémoire par processus (c'est l'intérêt principal de x86_64). Et toutes les applis ont des pointeurs en 64 bits (contre 32 bits pour i386). Notons bien que sous Fedora (mais ça doit être la même chose pour Debian, etc), une appli qui existe en i386, existe en x86_64.
> simplement installer des paquets RPM sur une RHEL non-enregistrée parce que le client n'en a rien à faire de RHN, c'est la croix et la bannière.
<mode désagréable>
J'ai quand même l'impression qu'il y a de sacrés blanleurs lorsqu'il faut utiliser rhel...
Installer un rpm est trivial.
Puis tu peux aussi installer yum. Faire un dépôt yum est trivial. RHEL 4 a up2date qui supporte yum. RHEL 5 utiliser yum par défaut ! Depuis RHEL 4, tu peux mixer rhn avec yum. Donc utiliser rhn et avoir ton propre dépôt en même temps. up2date et yum utiliseront les deux à la fois.
Pourquoi il y a de tels branleurs sur rhel ?
Peut-être car on leur a imposer d'utiliser rhel. Ils y vont en freinant de 4 fers, et à chaques fois qu'un truc ne va pas comme espéré, ça fait leur bonheur (surtout à la machine à café où il pourra dire comme rhel pue et debian roxor).
Merde quoi !
Rhel est l'une des distributions les plus utilisées en entreprise. C'est étroitement dérivé d'une distribution communautaire. Ça ne vient pas d'une entreprise qui a la culture du logiciel propriétaire, mais d'une entreprise qui est "massivement" impliqué dans le libre. Si Rhel était une catastrophe, alors CentOS serait une catastrophe et aurait beaucoup de modifications par rapport à Rhel. Ben CentOS a très très très peu de modification par rapport à Rhel.
Désolé, mais un mec qui n'est pas foutu d'installer les doigts dans le nez un rpm sur rhel (ou même un groupe de rpm (c'est "rpm -U *.rpm" si on a que rpm)), qui n'est pas foutu de regarder les forums pour voir que rhel supporte aussi yum (et même les dépôts apt !), ben c'est un branleur.
Et qu'on me fasse pas croire qu'avec Ubuntu ou Debian ou Mandriva ou autre tout se passe les doigts dans le nez, que les upgrades passent comme une cuieille de miel, etc... Il y a des tonnes de forum et mailing pour prouver que c'est faux.
> compiz fusion qu'on utilise _vraiment_, à savoir, avec des applications opengl, et avec l'affichage video XV
Super, les drivers proprio de NVidia sont à "conseiller" (entre guillemet car ce n'est pas libre) à 0,1 % des utilisateurs qui veulent _vraiment_ se la pêter avec compizzz.
Pas de quoi considérer qu'Intel est une "catastrophe".
Novell fait ça pour le pognon. C'est opportuniste. Je crois que MS a donné plus de 300 millions de $ en 2007 à Novell. M'enfin, c'est une goutte d'eau pour MS.
Le jeux de MS est bizarre. Un peu comme quand MS financait SCO. Le jeux de Novell très ambigü.
Pour ma part, MS fait une connerie, Novell aussi.
Même si Novell n'a toujours pas franchit la ligne rouge, je ne veux pas avoir à faire avec eux (ni OpenSuse).
> Red Hat au moin lui
D'autres ont fait comme Red Hat. Mandriva et Ubuntu notamment.
M'enfin, c'est vrai que c'est Red Hat qui est le plus menacé.
Notons que Red Hat devait sortir une solution desktop vers septembre 2007. Mais ce n'est toujours pas là. Il semble que Red Hat, ou un de ses partenaires (fluenco ?), n'arrive pas à avoir des conditions satisfaisantes pour les codecs MS. J'imagine que MS veut imposer un accord avec Red Hat du type MS/Novell. A voir si ça ne va pas finir en procès (au moins en Europe). NB: C'est de la spéculation de ma part, Red Hat reste très vague.
> Et pour toi, rebooter, c'est la honte, c'est le truc qui ne dois jamais arriver, mais pour madame michu, c'est un truc déséspérement simple, qui résous certains de ses problèmes.
C'est une réponse à un bug. C'est un conseil du SAV s'il y a un problème, etc.
Ça ne doit pas être une règle pour rendre sa bécane plus rapide. En tout cas pas sous Linux.
T'as raison.
Mais tu parles de bug. Oui, si un programme a un bug il faut top, lsof, et voire un reboot si tu ne trouves pas le problème. Bref, tu peux avoir à faire un nombre de chose infini.
Je n'ai jamais conseillé à un mec qui trouve sa linuxbox lente de rebooter. Et toi ?
J'essai de trouver les raisons (drivers graphique sans accélération, bug d'un programme, etc).
Je n'ai pas souvenir d'avoir rebooter ma bécane Linux pour la rendre plus rapide. Et ça fait depuis 10 ans que j'utilise Linux.
Tu vois enfin la différence avec Windows ?
Lorsqu'un Windows est lent, on le reboot. Je peux t'assurer que j'ai vu ça des tonnes de fois même pour des serveurs.
Sous Linux ce n'est pas le cas. Et quand c'est le cas, c'est à cause d'un bug, d'un admin qui n'est pas futé, etc. Mais ça reste exceptionnel.
J'ai parfois des uptimes de 100 jours et plus sur ma bécane (qui fait serveur de développement, backup, station de travail, plateforme multi-média, host virtualisation, etc). Quand je reboot, c'est pour changer de noyau. Ce n'est pas pour rendre ma bécane plus rapide. Et juste après un reboot, je n'ai jamais trouvé ma bécane plus rapide (sauf évolution importante du noyau).
> Bon, faut encore une andouille pour contre-balancer la mauvaise foi
C'est MS qui le dit.
> Même si on n'utilise pas un programme, il utilise des ressources :
> - espace disque
Oui. Mais avec des disques de l'ordre de 300 Go aujourd'hui, il n'y a rien a attendre ici.
> - processeur (certains programmes tournent en tâche de fond)
> - mémoire (certains programmes tournent en tâche de fond)
Dans ce cas ses programme sont mauvais.
On a déjà vu des benchs entre par exemple une installation de Fedora par défaut (beaucoup de service) et une Gentoo au petit oignon, et il n'y a pas de différence. La différence est dans le temps de boot.
Ceux qui ont fait les benchs sont de mauvaise foi ?
> Plus un disque est plein, plus les fichiers deviennent fragmentés sur le disque et limite les perfs du système en conséquence. Y 'a pas de miracle.
Si le disque est plein à 95 % c'est effectivement un problème.
J'ai déjà fait du nettoyage de mes disques. Mais pas pour gagner en performance, mais pour gagner de la place disque.
Lorsque mon disque se remplit, je ne me dis pas "zut, mon système va être lent", mais "zut, je risque de manquer de place". Sous Windows c'est "zut, mon système va être lent". Et je peut le confirmer. Lorsque le taux d'utilisation arrive autour de 80%, les performances chutes significativement. Sous Linux à 80 % on ne remarque rien (sauf à sortir un chrono).
> Le problème est identique sous tous les OS.
Si tu lances deux programmes en même temps, ça ne doit pas être plus lents. T'as bécane en fait plus.
Si j'ai le programme A tout seul qui fait son boulot en 1 minutes et le programme B tout seul qui fait son boulot en 2 minutes, si je lance ces deux programmes en même temps, ça ne doit pas me prendre plus de 3 minutes (sauf cas exceptionnel type énormemment d'accès disques).
Sous Linux lorsqu'on compile on utilise souvent "make -j 2" pour un mono-processeur. Ça compile plus plus que "make -j 1" même su un mono-processeur.
Apparament sous Windows ce n'est pas le cas. Permet moi de trouver ça étrange.
Enfin on est à une époque de bi-core voire quadri-core, et dire qu'il ne faut pas lancer plusieurs applis à la fois est définitivement ridicule.
> Encore une fois, ce problème est similaire sous Linux : tu peux très bien avoir des programmes avec une légère fuite mémoire par exemple qui vont poser dégrader les perfs globales au bout d'un certain temps.
Ce problème ne demande pas de rebooter la bécane sous Linux.
Au pire tu te déloggue et te reloggue. Enfin, tu parles de bug. Vista est conçu pour les bugs, avec des bugs de conception ?
> Certaines mises à jour nécessite un reboot.
Énormément sous Windows
> Sous linux aussi.
Uniquement un changement de noyau demande un reboot.
> Ne pas rebooter une fois de temps en temps sur un poste client c'est potentiellement s'exposer à des problèmes de sécurité.
Dans ce cas ton système est pourri. Si t'es sous Windows, ça ne me surprend pas.
> C'est la rançon du succès.
Rire.
T'as vu le succès de Firefox ?
Ben pratiquement aucun virus et en tout cas sans commune mesure avec IE.
Bref, cette excuse facile il faudrait éviter de la sortir à l'avenir. Elle est complètement naze. Et ça fait depuis des années que je dis qu'elle est complètement naze.
> Un service qui s'exécute bouffe de la RAM et parfois du CPU.
Le mieux dans ce cas est de virer le "service" vista.
Si le service n'est pas utilisé, il ne bouffe pas de CPU. Si t'es un peu juste en RAM, le service fini dans le swap.
Ou alors la règle que MS c'est que chaque service soit locké en RAM ?
> Et franchement quand je vois des réponses dans les forums à base de "tu sauvegarde, tu formate et tu copie sur le nouveau fs"... je me demande si windows 3.11 est si loin que ça.
Très juste. Défragmenter apporte un gain. Mais sous Linux et pour un usage courant ce n'est pas grand chose. J'ai défragmenté qu'un fois sous Linux (à l'époque d'ext2), ça n'a pas changé grand chose.
Par contre sur un serveur qui lit et écrit intensivement le système de fichier ça peut faire une différence significative.
M'enfin, c'est de la petite optimisation. Jamais je ne vais faire un tar et le restaurer pour ça (sauf cas très particulier).
Si ils "tournent", ils ne font pas rien, c'est que tu les utilises.
S'ils sont lancés et que tu ne les utilises pas, ils ne bouffent pas de cpu. Si c'est le cas, il faut faire un rapport de bug.
Si tu es juste en mémoire, ces services non utilisés finissent en swap. Donc globalement ça ne change rien (sauf le temps de boot).
ATI le fait.
Si j'ai bonne mémoire, il y a déjà plus de 800 pages de doc de fournit (sans clause de non divulgation).
C'est un travail en cours, la doc arrive petit à petit (mais à un joli rythme).
> Une méthode équivalente pour générer des paquets pour Fedora serait bienvenue, si quelqu'un connait...
Je n'ai pas de puce Intel...
Mais, si j'en avais une, dans les grandes lignes je ferai ça :
* Récuparation du paquet de développement de Fedora (le paquet xorg-x11-drv-i810 a aussi les sources xf86-video-intel)
- rpm -i http://fr2.rpmfind.net/linux/fedora/development/source/SRPMS(...)
* Récupération des sources
- git-clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel
* remplacement du xf86-video-intel-*.tar.bz2 du rpm par les sources récupérés avec git-clone
* réajustement du fichier .spec
* construction du paquet ("rpmbuild ... " ou "mock ...").
* Installation : "rpm -Uvh ..."
> Puisque je vous parle de tests urgents (si vous souhaitez que le pilote dans les prochaines versions de Fedora et Ubuntu soit de bonne qualité),
Tout le monde ne peut avoir les connaissances nécessaires pour faire un paquet deb ou rpm.
Une autre voie, et tout aussi excellente, est de tester l'Ubuntu ou Fedora en préparation. Il *faut* aussi s'inscrire sur les mailings pour les testeurs. C'est une mine d'information et d'aide.
Puis faire un rapport de bug. Au niveau distributeur ou en upstream. Mais en cas de doute, il faut le faire au niveau distribution. Un développeur de la distribution regardera si ça concerne un problème lié à la distribution ou un autre paquet (bref, il va trier les bugs). Si c'est une problème upstream, il va créer un rapport de bug au niveau upstream.
* Important : une fois qu'un rapport de bug a été fait, il faut le suivre ! Il faut tester si une nouvelle version corrige le bug et si c'est le cas renseigner le rapport de bug.
Il ne faut pas forcément tester toutes les versions, mais de temps à autre.
* Important : Avant de créer un rapport de bug, vérifiez si le bug n'a pas déjà été remonté.
Une participation au développement/mise au point d'une distribution profite au projet upstream et donc à toutes les distributions.
> Je me demande ce que signifie "c'est normal", dans ce contexte.
C'est voulu si tu préfères.
> je suppose que tu voulais juste ne lui concéder aucun point,
Faut pas pousser. Il soulève plein de points, certains je ne suis pas d'accord (c'est clairement dit) et beaucoup je ne comprend pas où il veut en venir.
> Même si c'est cohérent au sein de Gnome (je n'ai pas vérifié), ça introduit une incohérence dès que quelqu'un utilise un autre logiciel, Firefox par exemple, qui utilise pourtant GTK.
Et ?
Où tu veux en venir ?
Qu'il est vain de chercher la cohérence ?
Que faire la LSB est une connerie ?
Qu'un toolkit doit tout permettre ?
Que tu dois faire un rapport de bug sur https://bugzilla.mozilla.org/ ?
> Enfin, peut-être que tu veux dire que "c'est bien comme ça"
C'est ton interprétation.
Globalement sur ce point je m'en fous.
Mais techniquement ça se tient. Si tu clique (gauche: donc avec metacity c'est premier plan + focus) sur une fenêtre qui a déjà une sélection, ben tu perds la sélection. C'est un moyen pour désélectionner. Et je suis sûr que tu dois le faire...
Par exemple t'as fait une grosse sélection d'une xterm, tu changes de bureau et fait le copié. Tu reviens au bureau où il y a la xterm, tout est encore sélectionné, la xterm à le focus, elle est au premier plan, et bien tu vas cliquer pour désélectionner et ne plus avoir un affichage sur fond noir. Tu trouves ça con ? Ben c'est peut-être moins con que de sélectionner autre chose pour désélectionner.
Et si tu ne veux pas perdre la sélection lorsque tu redonnes le focus, ben il suffit de donner le focus sans cliquer à l'intérieur de la fenêtre. Par exemple en cliquant sur les bords de la fenêtre, en utilisant <ctrl><tab>, en utilisant l'applet de sélection de fenêtre, etc...
> à quoi on peut te répondre "non", et on est bien avancé.
On est bien avancé si tu argumentes.
> Des arguments expliquant pourquoi c'est bien seraient un minimum.
C'est fait. Argumentes pour expliquer pourquoi c'est mal maintenant.
> pour faire un Drag&Drop, il fallait absolument que la fenêtre réceptrice soit au premier plan:
Tu parles d'autre chose ?
Comprend pas.
T'as utilisé <ctrl> ?
Encore une fois, ici c'est cohérent. A chaque fois que tu cliques (clique gauche, sans touche de modification) ben tu passent la fenêtre au premier plan et lui donne le focus. Il n'y a pas de "si on clique et que durant 40 ms il n'y a pas de détection de drag alors la fenêtre passe au premier plan".
> c'est une contrainte artificielle
Contrainte ?
> dont l'apport en terme d'ergonomie est loin d'être évident
La simplicité. Un clique gauche = passage au premier plan et focus.
Ce n'est pas "un clique gauche = ceci sauf si celà".
> et qui ajoute une incohérence entre les diverses applications.
???
> On a standardisé le comportement du drag&drop, il ne serait pas mal que le comportement du copier-coller à la souris le soit aussi.
C'est un problème de window manager. Ne mélange pas tout.
Change de windows manager, avec les mêmes applis gtk ça changera.
Regarde du côté de Icewm, il y a plein de bonne chose dans ce domaine (au détriment de la simplicité !).
En passant, tu n'es pas obligé d'utiliser metacity avec Gnome. Tu peux utiliser un autre WM si tu veux.
> se débarrasser une bonne fois pour toute de cette monstruosité qu'est le double clic.
La monstruosité est de vouloir se limité au simple clique.
Un clique c'est sélectionner (donc après tu peux faire un copier/couper etc).
Un double clique c'est exécuter/lancer/activer/etc.
Il y a deux fonctions différentes.
> Surtout, ne pas admettre que le problème a été créé par Mozilla.
Il n'y a pas que Debian™ comme distribution, et il n'y a qu'à Debian™ que Mozilla pose un problème. Quelle conclusion tirer ?
> c'est surtout d'avoir voulu compiler soi même FF/Iceweasel
Les autres compilent eux même Firefox aussi. Mozilla tolère les patchs s'ils ne sont pas stupides et après les avoir audité.
Pour exemple, les patchs F8 : [admin@one firefox]$ cat *.patch | diffstat | tail -1
74 files changed, 6183 insertions(+), 1209 deletions(-)
S'il y a des problèmes avec le Firefox de Fedora, Mozilla engage sa crédibilité. Mozilla ne peut se défiler et dire "c'est Fedora, on s'en torche, on y est pour rien".
C'est une précieuse assurance pour Fedora et beaucoup d'autres. Et ça coûte 0 € (!) aux distributions et du temps à Mozilla.
Ça n'empêche pas Fedora de sortir des navigateurs mozilla non estampillé Firefox de temps à autre.
Du .spec de F8 (FF 2.0.0.10) : %define official_branding 1 <= estampillé Firefox
Du .spec de Rawhide (FF 3.0-0.beta2.15.nightly20080130) %define official_branding 0 <= non estampillé Firefox
Debian™ ne veut pas de la crédibilité/assurance de Firefox car Debian™ ne veut pas demander d'accord à Mozilla avant de sortir un "Firefox". OK, accèptons le choix de "principe" de Debian™. Mais il n'y a pas de quoi conclure que Mozilla est un "méchant" dans cette histoire.
Les autres s'arrangent avec Mozilla et ils y gagnent ! Audite par Mozilla, crédibilité de la marque Firefox. Crédibilité qui n'existe que si Mozilla défend la marque Firefox. Donc, et si c'est bien géré comme c'est le cas aujourd'hui, on a tout à gagner par la défense de la marque Firefox par Mozilla.
Et quand il n'y a pas d'arrangement possible (comme le Firefox en version beta dans Rawhide de Fedora), ben il suffit d'éditer une ligne. Pas de quoi en faire un fromage, la liberté est toujours là. Il n'y a pas obligation à Fedora ou d'autres de ne sortir que des versions estampillées Firefox. Il n'y a pas de "lock-in", il n'y a rien de "propriétaire".
> Plus de problèmes de marques
En passant, Debian™ est une marque déposée et défendue. Comme Firefox, Ubuntu, Mandriva, Fedora, Red Hat, Novell, Microsoft, Windows, Linux, etc.
Debian™ serait-il dans le camp des méchants ?
Si, par exemple, linspire ou Xandros sort sa prochaine version avec le nom "Debian NG", tu crois que Debian™ ne va pas gueuler et utiliser les instruments juridiques qui vont bien ?
Imagine si MS mettait un Firefox en download avec plein de trous de sécurité à la MS ?
Tu penses que Mozilla devrait dire "pas de problème, c'est Firefox" ?
MS peut faire de la merde avec les sources de Firefox (c'est libre). Mais MS n'aura pas forcément le droit d'appeller ça Firefox. C'est bien ou c'est mal ?
Debian™ peut faire des merveilles avec les sources de Firefox, mais si Debian™ ne veut pas d'un audite de Mozilla, ben ça ne s'appelle pas Firefox.
Pour l'anectode, Mozilla n'est pas une marque déposée. Ben il y a eu des navigateurs Mozilla mal foutus (trous de sécurité) qui ont circulé sur le web et Mozilla ne pouvait rien dire et devait laisser ceux qui diffusaient une version pourrie de Mozilla continuer.
> - OpenOffice.org : options > affichage > taille et style des icônes : choisir grande et tango ou industriel ou autre, mais pitié, comment espèrent-ils rendre attractif openoffice quand les icônes par défaut sont dignes de windows 3.0 (avec moins de relief et de couleurs...) ?
C'est ton avis personnel. L'upstream n'est pas de ton avis.
Pourquoi tu imposes tes goûts à tes "utilisateurs" ?
> - pour epiphany, page d'accueil par défaut : debian.org .
Vrai faux problème.
Fedora fournit le paquet fedora-bookmarks. Il suffit de le remplacer. Voilà ce qu'il faut faire.
> Pourquoi ne pas concevoir une sorte de portail personnalisé par la distribution qui permette d'une part d'avoir des info discrètes et de la documentations sur la distribution installée, mais également d'avoir des actualités, un moteur de recherche internet etc.
Mauvaise idée. C'est mon avis. Du moins pour la partie "la documentations sur la distribution installée". Apparament tes utilisateurs n'ont pas le compte root. Donc tout ce qui les intéressent c'est Firefox, OOo, etc. La doc de apt ou yum ils s'en trochent.
> Donc en général, première chose à faire c'est installer à la main firefox / thunderbird.
Le première chose à faire, est de bien chosir une distribution.
Parce qu'une distribution qui demande de faire des installations à la main pour des paquets aussi répendus que Firefox ou Thunderbird, ben c'est de la [censuré].
> C'est un peu lourd, ils n'ont qu'à faire comme pour java ou flash, ils mettent firefox dans la partie "non-free", et ils le redistribuent sans modification, et c'est réglé.
Pipo. Par défaut, lorsqu'on construit Firefox ou Thunderbird depuis les sources (c'est-à-dire sans le patcher ni activer une option spécifique (--enable-official-branding)), les marques Firefox et Thunderbird ne sont pas utilisées. Donc Debian n'a rien à faire. J'imagine que Debian a quelques patchs qui sucks.
Pour utiliser la marque Firefox il faut le faire exprès. Non l'inverse.
> - dans la plupart des distributions, pas de raccourci direct vers gnome-control-center, il faut passer par chaque option du menu pour configurer chaque point.
Et ?
Le but de Gnome est de marcher de suite. Pas d'imposer à l'utilisateur de visiter tous les panneaux de config. Donc c'est un vrai-faux problème.
> - pour le calendrier, si on clique dessus, certains ne comprennent pas que c'est comme un bouton poussoir et que l'on peut faire disparaître le calendrier en recliquant dessus. Une petit croix discrète et c'est résolu.
On peut voir ça comme un bug. Faudrait fouiller le bugzilla de Gnome, je ne serais pas étonné que ça soit déjà considéré comme un bug.
> En fait je pinaille et ce n'est pas très génant en soit, mais si on pose un classeur sur le clavier et que cela bloque sur cette touche, cela ouvre 500 copie d'écran !
C'est un peu de l'enculage de mouche :-)
> - le fameux drag n drop de la discussion citée plus haut : si on clique sans relacher le bouton sur un objet d'une fenêtre sous une autre en vue de déplacer ou activer l'objet sur la seconde fenêtre, la première passe au premier plan, empêchant d'aller sur la seconde. Idem sous KDE.
Bof...
> le texte en presse-papier disparaît (sans doute remplacé par la "selection" vide du clic).
Oui, et c'est normal. Même si pour les vieux c'est casse couille.
Pour le reste, j'ai décrocher. Je ne vois pas où tu veux en venir... Tu fais une critique des bureaux ? Oui, il y a des bugs. Des trucs mal pensé aujourd'hui et corrigé demain. etc.
Et pourquoi ?
Et tu ne confonds pas erreur de packaging avec insuffisances des outils de packaging ?
Parce que même avec Ubuntu ou Debian les upgrades sucks. Il me semble qu'Ubuntu ne supporte que l'upgrade de la version n à la n+1. Toutes les distributions le font, même les distributions rpm.
> (je parle des versions de 97/98)
10 ans...
> la gestion des dependances etaient, comment dire..., aleatoire.
La gestion des dépendances a toujours été bonne. Sinon avance des arguments techniques.
La différence est que par défaut rpm s'arrête s'il ne peut mettre à jour un paquet. Deb l'ignore. C'est un choix "politique". Pour rpm, ne pas pouvoir mettre à jour un paquet est un problème de sécurité potentiel (en effet, la mise à jour est peut-être une mise à jour de sécurité). Deb a une autre philosophie. Ça ne veut pas dire que rpm sucks.
En passant, il y a le plugin yum-skip-broken pour ceux qui veulent le même comportement que deb.
> C'etait super chouette de savoir qu'il te manquait la libXXX.so.13221 et pas savoir dans quel paquet elle se trouvait...
Ici tu parles d'autres choses. Tu compares rpm à apt et c'est une erreur. Compare rpm à dpkg. Ou compare yum/apt4rpm/smart/up2date/urpmi/etc à apt.
> Des annees apres apt-get et je parle bien de la periode AVANT urpmi ou apt4rpm.
Et ?
Tu disais que Mandriva aurait dû passer à deb. Ben Mandrake n'avait pas deb et marchait très bien. Puis Mandrake a ajouté urpmi et marchait très. Puis Mandrake a moins bien marché (et pourtant deb/apt n'a pratiquement pas changé).
> Enfin c'est mon opinion toute personnelle
Pourquoi pas. Mais si tu dis que rpm sucks, faut donner des arguments valides.
> le train que ubuntu a lui a reussi a prendre!
Quel train ?
Le train deb ?
Le train AIGLX ?
Ooops, ce n'est pas Ubuntu qui l'a fait.
Le train "just works" de Gnome ?
Ooops, ce n'est pas Ubuntu qui l'a fait.
Le train udev/hal/etc ?
Ooops, ce n'est pas Ubuntu qui l'a fait.
etc.
Et où va aller ce train ?
Parce qu'à la belle époque de Mandrake, tout le monde disait que Mandrake allait bouffer Microsoft et que Red Hat ou Suse pue.
Il faut "se calmer". Ubuntu a "arraché" les gendarmerie et deux ou trois bricoles, ça reste très très très loins de Red Hat ou Novell.
Le train Ubuntu, c'est le train Debian. Dans 2 ans la gendarmerie passerait à Debian que je ne serais pas étonné.
La "mode" (si ça en est une) Ubuntu, peut s'essouffler comme la "mode" Mandrake.
> Anaconda permet d'installer dans une machine virtualisée ?
Oui.
> tout en offrant un xnest si je ne me trompe pour voir ce qu'il se passe ?
Pour anaconda c'est un périphérique graphique (cas kvm/qemu). Sinon anaconda peut utiliser vnc (cas Xen) et l'affichage est renvoyé n'importe où.
C'est virt-viewer qui fait l'affichage final (virt-viewer est biensur appellé par virt-manager).
Pour le cas Xen, j'ai un doute car je ne l'utilise plus. Il se peut que Xen fournisse maintenant un périphique à la machine virtuelle.
Dans la pratique, on lance la machine virtuelle. Si on veut l'affichage (c-à-d accéder à une console (où tourne peut-être X11)) on double-clique sur la ligne qui représente la machine virtuelle et voilà.
> En tout cas, le fait d'installer dans un chroot est très pratique au delà des machines virtuelles, pratique par exemple pour se faire des chroots de build.
Des choses dans ce goût peuvent aussi être faite :
# yum groupinstall --installroot=/mnt/root Base "Web Server"
Plus globalement, Red Hat investit énormemment dans la virtualisation. Donc il y a des résultats.
Maintenant Red Hat veut amener KVM/paravirt_ops au niveau de Xen et "virer" Xen (ce qui ne va pas être fait du jour au lendemain).
Fedora 9 (qui n'aura peut-être plus Xen) aura de sympatiques avancées : http://fedoraproject.org/wiki/Features/VirtPolicyKit
By integrating with PolicyKit it will be possible to run virt-manager as a regular user.
> ils ont du mettre au point un clone de apt-get etc
Il y a depuis des années apt4rpm.
Si deb est la clée du succès, pourquoi Red Hat et Novell explose deb dans les offres pour entreprise ?
Pourquoi Mandrake a fait un carton à ses débuts alors que debian existait à l'époque ?
Pourquoi Xandros, etc qui font des distributions simple à la Ubuntu n'ont pas percées comme Ubuntu ?
Etc.
Une distribution ne se résume pas à son gestionnaire de paquet. Loins loins loins de là.
La gestion du projet distribution, le buziness plan, etc plus beaucoup plus important. Dans ces domaines Mandriva n'a jamais été remarquable comme l'a été Ubuntu ou Red Hat.
[^] # Re: 2 Go
Posté par IsNotGood . En réponse au journal Un article intéressant sur NetBSD. Évalué à 1.
Comme Linux, comme tout ce qui est libre.
> Ensuite, j'ai un NetBSD 4 avec 8Go de RAM
Le problème de 2 Go doit être par processus.
> Pour info, voici le nombre de libre specifique à x86-64, c'est à dire qui ne sont pas l'arbre de source general, pour simplifier.
Et ?
Je ne dois pas comprendre. J'ai une F8 sous x86_64, c'est les même source que pour i386, ppc et ppc64. Évidemment, il doit y avoir des "ifdef ...". Pour ce qui est "spécifique" x86_64, c'est dans linux/arch/x86_64 (ou un truc dans ce goût). Branche qui a été fusionnée avec i386 dans Linux 2.6.24.
Bref, pour comptabiliser, c'est quasi impossible. Alors c'est peut-être "pire" que NetBSD, mais il y a plus de 4 Go de mémoire par processus (c'est l'intérêt principal de x86_64). Et toutes les applis ont des pointeurs en 64 bits (contre 32 bits pour i386). Notons bien que sous Fedora (mais ça doit être la même chose pour Debian, etc), une appli qui existe en i386, existe en x86_64.
> libc : ------------------310----------2772----------
> C startup : ----------0--------------104------------
> libm : -----------------52------------0---------------
> dynamic linker : ---59-------------172-----------
Sachant que la libc, libm, crt.o, et ld.so en i386 tourne sous x86_64 pour Linux, l'écard peut être de 0 ici.
[^] # Re: Daube
Posté par IsNotGood . En réponse à la dépêche Le poste de travail du gendarme sous GNU/Linux Ubuntu. Évalué à 3.
<mode désagréable>
J'ai quand même l'impression qu'il y a de sacrés blanleurs lorsqu'il faut utiliser rhel...
Installer un rpm est trivial.
Puis tu peux aussi installer yum. Faire un dépôt yum est trivial. RHEL 4 a up2date qui supporte yum. RHEL 5 utiliser yum par défaut ! Depuis RHEL 4, tu peux mixer rhn avec yum. Donc utiliser rhn et avoir ton propre dépôt en même temps. up2date et yum utiliseront les deux à la fois.
Pourquoi il y a de tels branleurs sur rhel ?
Peut-être car on leur a imposer d'utiliser rhel. Ils y vont en freinant de 4 fers, et à chaques fois qu'un truc ne va pas comme espéré, ça fait leur bonheur (surtout à la machine à café où il pourra dire comme rhel pue et debian roxor).
Merde quoi !
Rhel est l'une des distributions les plus utilisées en entreprise. C'est étroitement dérivé d'une distribution communautaire. Ça ne vient pas d'une entreprise qui a la culture du logiciel propriétaire, mais d'une entreprise qui est "massivement" impliqué dans le libre. Si Rhel était une catastrophe, alors CentOS serait une catastrophe et aurait beaucoup de modifications par rapport à Rhel. Ben CentOS a très très très peu de modification par rapport à Rhel.
Désolé, mais un mec qui n'est pas foutu d'installer les doigts dans le nez un rpm sur rhel (ou même un groupe de rpm (c'est "rpm -U *.rpm" si on a que rpm)), qui n'est pas foutu de regarder les forums pour voir que rhel supporte aussi yum (et même les dépôts apt !), ben c'est un branleur.
Et qu'on me fasse pas croire qu'avec Ubuntu ou Debian ou Mandriva ou autre tout se passe les doigts dans le nez, que les upgrades passent comme une cuieille de miel, etc... Il y a des tonnes de forum et mailing pour prouver que c'est faux.
[^] # Re: Autre époque, autres moeurs...
Posté par IsNotGood . En réponse à la dépêche Intel livre les spécifications complètes et sans NDA des chipsets graphiques récents. Évalué à -3.
Super, les drivers proprio de NVidia sont à "conseiller" (entre guillemet car ce n'est pas libre) à 0,1 % des utilisateurs qui veulent _vraiment_ se la pêter avec compizzz.
Pas de quoi considérer qu'Intel est une "catastrophe".
[^] # Re: Moi je me demande de quelle façon ils y gagnent...
Posté par IsNotGood . En réponse au journal Microsoft et Novell s'associent pour faire rentrer SuSE chez Renault. Évalué à 4.
Le jeux de MS est bizarre. Un peu comme quand MS financait SCO. Le jeux de Novell très ambigü.
Pour ma part, MS fait une connerie, Novell aussi.
Même si Novell n'a toujours pas franchit la ligne rouge, je ne veux pas avoir à faire avec eux (ni OpenSuse).
> Red Hat au moin lui
D'autres ont fait comme Red Hat. Mandriva et Ubuntu notamment.
M'enfin, c'est vrai que c'est Red Hat qui est le plus menacé.
Notons que Red Hat devait sortir une solution desktop vers septembre 2007. Mais ce n'est toujours pas là. Il semble que Red Hat, ou un de ses partenaires (fluenco ?), n'arrive pas à avoir des conditions satisfaisantes pour les codecs MS. J'imagine que MS veut imposer un accord avec Red Hat du type MS/Novell. A voir si ça ne va pas finir en procès (au moins en Europe). NB: C'est de la spéculation de ma part, Red Hat reste très vague.
[^] # Re: Moi je me demande de quelle façon ils y gagnent...
Posté par IsNotGood . En réponse au journal Microsoft et Novell s'associent pour faire rentrer SuSE chez Renault. Évalué à 2.
Ben Novell paye MS pour avoir la garantit que MS ne va pas attaquer Novell.
Si Renault avec choisi Red Hat, ça ferait 0 entrée pour MS.
[^] # Re: mouaich
Posté par IsNotGood . En réponse au journal Rigolons : accélérer Vista. Évalué à 1.
C'est une réponse à un bug. C'est un conseil du SAV s'il y a un problème, etc.
Ça ne doit pas être une règle pour rendre sa bécane plus rapide. En tout cas pas sous Linux.
[^] # Re: mouaich
Posté par IsNotGood . En réponse au journal Rigolons : accélérer Vista. Évalué à 2.
Mais tu parles de bug. Oui, si un programme a un bug il faut top, lsof, et voire un reboot si tu ne trouves pas le problème. Bref, tu peux avoir à faire un nombre de chose infini.
Je n'ai jamais conseillé à un mec qui trouve sa linuxbox lente de rebooter. Et toi ?
J'essai de trouver les raisons (drivers graphique sans accélération, bug d'un programme, etc).
Je n'ai pas souvenir d'avoir rebooter ma bécane Linux pour la rendre plus rapide. Et ça fait depuis 10 ans que j'utilise Linux.
Tu vois enfin la différence avec Windows ?
Lorsqu'un Windows est lent, on le reboot. Je peux t'assurer que j'ai vu ça des tonnes de fois même pour des serveurs.
Sous Linux ce n'est pas le cas. Et quand c'est le cas, c'est à cause d'un bug, d'un admin qui n'est pas futé, etc. Mais ça reste exceptionnel.
J'ai parfois des uptimes de 100 jours et plus sur ma bécane (qui fait serveur de développement, backup, station de travail, plateforme multi-média, host virtualisation, etc). Quand je reboot, c'est pour changer de noyau. Ce n'est pas pour rendre ma bécane plus rapide. Et juste après un reboot, je n'ai jamais trouvé ma bécane plus rapide (sauf évolution importante du noyau).
[^] # Re: mouaich
Posté par IsNotGood . En réponse au journal Rigolons : accélérer Vista. Évalué à 3.
C'est MS qui le dit.
> Même si on n'utilise pas un programme, il utilise des ressources :
> - espace disque
Oui. Mais avec des disques de l'ordre de 300 Go aujourd'hui, il n'y a rien a attendre ici.
> - processeur (certains programmes tournent en tâche de fond)
> - mémoire (certains programmes tournent en tâche de fond)
Dans ce cas ses programme sont mauvais.
On a déjà vu des benchs entre par exemple une installation de Fedora par défaut (beaucoup de service) et une Gentoo au petit oignon, et il n'y a pas de différence. La différence est dans le temps de boot.
Ceux qui ont fait les benchs sont de mauvaise foi ?
> Plus un disque est plein, plus les fichiers deviennent fragmentés sur le disque et limite les perfs du système en conséquence. Y 'a pas de miracle.
Si le disque est plein à 95 % c'est effectivement un problème.
J'ai déjà fait du nettoyage de mes disques. Mais pas pour gagner en performance, mais pour gagner de la place disque.
Lorsque mon disque se remplit, je ne me dis pas "zut, mon système va être lent", mais "zut, je risque de manquer de place". Sous Windows c'est "zut, mon système va être lent". Et je peut le confirmer. Lorsque le taux d'utilisation arrive autour de 80%, les performances chutes significativement. Sous Linux à 80 % on ne remarque rien (sauf à sortir un chrono).
> Le problème est identique sous tous les OS.
Si tu lances deux programmes en même temps, ça ne doit pas être plus lents. T'as bécane en fait plus.
Si j'ai le programme A tout seul qui fait son boulot en 1 minutes et le programme B tout seul qui fait son boulot en 2 minutes, si je lance ces deux programmes en même temps, ça ne doit pas me prendre plus de 3 minutes (sauf cas exceptionnel type énormemment d'accès disques).
Sous Linux lorsqu'on compile on utilise souvent "make -j 2" pour un mono-processeur. Ça compile plus plus que "make -j 1" même su un mono-processeur.
Apparament sous Windows ce n'est pas le cas. Permet moi de trouver ça étrange.
Enfin on est à une époque de bi-core voire quadri-core, et dire qu'il ne faut pas lancer plusieurs applis à la fois est définitivement ridicule.
> Encore une fois, ce problème est similaire sous Linux : tu peux très bien avoir des programmes avec une légère fuite mémoire par exemple qui vont poser dégrader les perfs globales au bout d'un certain temps.
Ce problème ne demande pas de rebooter la bécane sous Linux.
Au pire tu te déloggue et te reloggue. Enfin, tu parles de bug. Vista est conçu pour les bugs, avec des bugs de conception ?
> Certaines mises à jour nécessite un reboot.
Énormément sous Windows
> Sous linux aussi.
Uniquement un changement de noyau demande un reboot.
> Ne pas rebooter une fois de temps en temps sur un poste client c'est potentiellement s'exposer à des problèmes de sécurité.
Dans ce cas ton système est pourri. Si t'es sous Windows, ça ne me surprend pas.
> C'est la rançon du succès.
Rire.
T'as vu le succès de Firefox ?
Ben pratiquement aucun virus et en tout cas sans commune mesure avec IE.
Bref, cette excuse facile il faudrait éviter de la sortir à l'avenir. Elle est complètement naze. Et ça fait depuis des années que je dis qu'elle est complètement naze.
> Un service qui s'exécute bouffe de la RAM et parfois du CPU.
Le mieux dans ce cas est de virer le "service" vista.
Si le service n'est pas utilisé, il ne bouffe pas de CPU. Si t'es un peu juste en RAM, le service fini dans le swap.
Ou alors la règle que MS c'est que chaque service soit locké en RAM ?
[^] # Re: Esprit chagrin
Posté par IsNotGood . En réponse au journal Rigolons : accélérer Vista. Évalué à 1.
Très juste. Défragmenter apporte un gain. Mais sous Linux et pour un usage courant ce n'est pas grand chose. J'ai défragmenté qu'un fois sous Linux (à l'époque d'ext2), ça n'a pas changé grand chose.
Par contre sur un serveur qui lit et écrit intensivement le système de fichier ça peut faire une différence significative.
M'enfin, c'est de la petite optimisation. Jamais je ne vais faire un tar et le restaurer pour ça (sauf cas très particulier).
[^] # Re: Disable services
Posté par IsNotGood . En réponse au journal Rigolons : accélérer Vista. Évalué à 5.
Si ils "tournent", ils ne font pas rien, c'est que tu les utilises.
S'ils sont lancés et que tu ne les utilises pas, ils ne bouffent pas de cpu. Si c'est le cas, il faut faire un rapport de bug.
Si tu es juste en mémoire, ces services non utilisés finissent en swap. Donc globalement ça ne change rien (sauf le temps de boot).
[^] # Re: Cré nom de diou !
Posté par IsNotGood . En réponse à la dépêche Intel livre les spécifications complètes et sans NDA des chipsets graphiques récents. Évalué à 10.
[^] # Re: Intel livre les spécifications complètes de ses chipsets graphique
Posté par IsNotGood . En réponse au journal Intel livre les spécifications complètes des chipsets graphiques récents, sans NDA. Évalué à 4.
ATI le fait.
Si j'ai bonne mémoire, il y a déjà plus de 800 pages de doc de fournit (sans clause de non divulgation).
C'est un travail en cours, la doc arrive petit à petit (mais à un joli rythme).
[^] # Re: Tester le dernier pilote sous Ubuntu ou Debian
Posté par IsNotGood . En réponse au journal Intel livre les spécifications complètes des chipsets graphiques récents, sans NDA. Évalué à 3.
Je n'ai pas de puce Intel...
Mais, si j'en avais une, dans les grandes lignes je ferai ça :
* Récuparation du paquet de développement de Fedora (le paquet xorg-x11-drv-i810 a aussi les sources xf86-video-intel)
- rpm -i http://fr2.rpmfind.net/linux/fedora/development/source/SRPMS(...)
* Récupération des sources
- git-clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel
* remplacement du xf86-video-intel-*.tar.bz2 du rpm par les sources récupérés avec git-clone
* réajustement du fichier .spec
* construction du paquet ("rpmbuild ... " ou "mock ...").
* Installation : "rpm -Uvh ..."
> Puisque je vous parle de tests urgents (si vous souhaitez que le pilote dans les prochaines versions de Fedora et Ubuntu soit de bonne qualité),
Tout le monde ne peut avoir les connaissances nécessaires pour faire un paquet deb ou rpm.
Une autre voie, et tout aussi excellente, est de tester l'Ubuntu ou Fedora en préparation. Il *faut* aussi s'inscrire sur les mailings pour les testeurs. C'est une mine d'information et d'aide.
Puis faire un rapport de bug. Au niveau distributeur ou en upstream. Mais en cas de doute, il faut le faire au niveau distribution. Un développeur de la distribution regardera si ça concerne un problème lié à la distribution ou un autre paquet (bref, il va trier les bugs). Si c'est une problème upstream, il va créer un rapport de bug au niveau upstream.
* Important : une fois qu'un rapport de bug a été fait, il faut le suivre ! Il faut tester si une nouvelle version corrige le bug et si c'est le cas renseigner le rapport de bug.
Il ne faut pas forcément tester toutes les versions, mais de temps à autre.
* Important : Avant de créer un rapport de bug, vérifiez si le bug n'a pas déjà été remonté.
Une participation au développement/mise au point d'une distribution profite au projet upstream et donc à toutes les distributions.
[^] # Re: My bad
Posté par IsNotGood . En réponse au journal Intel livre les spécifications complètes des chipsets graphiques récents, sans NDA. Évalué à 2.
L'annonce et la doc Intel mérite beaucoup mieux que mon (bref) journal :-)
C'est une excellente nouvelle.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Les config mal foutues dans les logiciels libres. Évalué à -4.
C'est voulu si tu préfères.
> je suppose que tu voulais juste ne lui concéder aucun point,
Faut pas pousser. Il soulève plein de points, certains je ne suis pas d'accord (c'est clairement dit) et beaucoup je ne comprend pas où il veut en venir.
> Même si c'est cohérent au sein de Gnome (je n'ai pas vérifié), ça introduit une incohérence dès que quelqu'un utilise un autre logiciel, Firefox par exemple, qui utilise pourtant GTK.
Et ?
Où tu veux en venir ?
Qu'il est vain de chercher la cohérence ?
Que faire la LSB est une connerie ?
Qu'un toolkit doit tout permettre ?
Que tu dois faire un rapport de bug sur https://bugzilla.mozilla.org/ ?
> Enfin, peut-être que tu veux dire que "c'est bien comme ça"
C'est ton interprétation.
Globalement sur ce point je m'en fous.
Mais techniquement ça se tient. Si tu clique (gauche: donc avec metacity c'est premier plan + focus) sur une fenêtre qui a déjà une sélection, ben tu perds la sélection. C'est un moyen pour désélectionner. Et je suis sûr que tu dois le faire...
Par exemple t'as fait une grosse sélection d'une xterm, tu changes de bureau et fait le copié. Tu reviens au bureau où il y a la xterm, tout est encore sélectionné, la xterm à le focus, elle est au premier plan, et bien tu vas cliquer pour désélectionner et ne plus avoir un affichage sur fond noir. Tu trouves ça con ? Ben c'est peut-être moins con que de sélectionner autre chose pour désélectionner.
Et si tu ne veux pas perdre la sélection lorsque tu redonnes le focus, ben il suffit de donner le focus sans cliquer à l'intérieur de la fenêtre. Par exemple en cliquant sur les bords de la fenêtre, en utilisant <ctrl><tab>, en utilisant l'applet de sélection de fenêtre, etc...
> à quoi on peut te répondre "non", et on est bien avancé.
On est bien avancé si tu argumentes.
> Des arguments expliquant pourquoi c'est bien seraient un minimum.
C'est fait. Argumentes pour expliquer pourquoi c'est mal maintenant.
> pour faire un Drag&Drop, il fallait absolument que la fenêtre réceptrice soit au premier plan:
Tu parles d'autre chose ?
Comprend pas.
T'as utilisé <ctrl> ?
Encore une fois, ici c'est cohérent. A chaque fois que tu cliques (clique gauche, sans touche de modification) ben tu passent la fenêtre au premier plan et lui donne le focus. Il n'y a pas de "si on clique et que durant 40 ms il n'y a pas de détection de drag alors la fenêtre passe au premier plan".
> c'est une contrainte artificielle
Contrainte ?
> dont l'apport en terme d'ergonomie est loin d'être évident
La simplicité. Un clique gauche = passage au premier plan et focus.
Ce n'est pas "un clique gauche = ceci sauf si celà".
> et qui ajoute une incohérence entre les diverses applications.
???
> On a standardisé le comportement du drag&drop, il ne serait pas mal que le comportement du copier-coller à la souris le soit aussi.
C'est un problème de window manager. Ne mélange pas tout.
Change de windows manager, avec les mêmes applis gtk ça changera.
Regarde du côté de Icewm, il y a plein de bonne chose dans ce domaine (au détriment de la simplicité !).
En passant, tu n'es pas obligé d'utiliser metacity avec Gnome. Tu peux utiliser un autre WM si tu veux.
[^] # Re: Nautilus
Posté par IsNotGood . En réponse au journal Les config mal foutues dans les logiciels libres. Évalué à 9.
La monstruosité est de vouloir se limité au simple clique.
Un clique c'est sélectionner (donc après tu peux faire un copier/couper etc).
Un double clique c'est exécuter/lancer/activer/etc.
Il y a deux fonctions différentes.
[^] # Re: Intelligence
Posté par IsNotGood . En réponse au journal Les config mal foutues dans les logiciels libres. Évalué à 5.
Il n'y a pas que Debian™ comme distribution, et il n'y a qu'à Debian™ que Mozilla pose un problème. Quelle conclusion tirer ?
> c'est surtout d'avoir voulu compiler soi même FF/Iceweasel
Les autres compilent eux même Firefox aussi. Mozilla tolère les patchs s'ils ne sont pas stupides et après les avoir audité.
Pour exemple, les patchs F8 :
[admin@one firefox]$ cat *.patch | diffstat | tail -1
74 files changed, 6183 insertions(+), 1209 deletions(-)
S'il y a des problèmes avec le Firefox de Fedora, Mozilla engage sa crédibilité. Mozilla ne peut se défiler et dire "c'est Fedora, on s'en torche, on y est pour rien".
C'est une précieuse assurance pour Fedora et beaucoup d'autres. Et ça coûte 0 € (!) aux distributions et du temps à Mozilla.
Ça n'empêche pas Fedora de sortir des navigateurs mozilla non estampillé Firefox de temps à autre.
Du .spec de F8 (FF 2.0.0.10) :
%define official_branding 1 <= estampillé Firefox
Du .spec de Rawhide (FF 3.0-0.beta2.15.nightly20080130)
%define official_branding 0 <= non estampillé Firefox
Debian™ ne veut pas de la crédibilité/assurance de Firefox car Debian™ ne veut pas demander d'accord à Mozilla avant de sortir un "Firefox". OK, accèptons le choix de "principe" de Debian™. Mais il n'y a pas de quoi conclure que Mozilla est un "méchant" dans cette histoire.
Les autres s'arrangent avec Mozilla et ils y gagnent ! Audite par Mozilla, crédibilité de la marque Firefox. Crédibilité qui n'existe que si Mozilla défend la marque Firefox. Donc, et si c'est bien géré comme c'est le cas aujourd'hui, on a tout à gagner par la défense de la marque Firefox par Mozilla.
Et quand il n'y a pas d'arrangement possible (comme le Firefox en version beta dans Rawhide de Fedora), ben il suffit d'éditer une ligne. Pas de quoi en faire un fromage, la liberté est toujours là. Il n'y a pas obligation à Fedora ou d'autres de ne sortir que des versions estampillées Firefox. Il n'y a pas de "lock-in", il n'y a rien de "propriétaire".
> Plus de problèmes de marques
En passant, Debian™ est une marque déposée et défendue. Comme Firefox, Ubuntu, Mandriva, Fedora, Red Hat, Novell, Microsoft, Windows, Linux, etc.
Debian™ serait-il dans le camp des méchants ?
Si, par exemple, linspire ou Xandros sort sa prochaine version avec le nom "Debian NG", tu crois que Debian™ ne va pas gueuler et utiliser les instruments juridiques qui vont bien ?
Imagine si MS mettait un Firefox en download avec plein de trous de sécurité à la MS ?
Tu penses que Mozilla devrait dire "pas de problème, c'est Firefox" ?
MS peut faire de la merde avec les sources de Firefox (c'est libre). Mais MS n'aura pas forcément le droit d'appeller ça Firefox. C'est bien ou c'est mal ?
Debian™ peut faire des merveilles avec les sources de Firefox, mais si Debian™ ne veut pas d'un audite de Mozilla, ben ça ne s'appelle pas Firefox.
Pour l'anectode, Mozilla n'est pas une marque déposée. Ben il y a eu des navigateurs Mozilla mal foutus (trous de sécurité) qui ont circulé sur le web et Mozilla ne pouvait rien dire et devait laisser ceux qui diffusaient une version pourrie de Mozilla continuer.
[^] # Re: Friday but not necessarily troll day !
Posté par IsNotGood . En réponse au journal Les config mal foutues dans les logiciels libres. Évalué à -2.
WebKit/emacs_touch embedded(*)
(*) : C'est très corporate/geek d'utiliser des termes anglais dans tous les sens.
[^] # Re: Friday but not necessarily troll day !
Posté par IsNotGood . En réponse au journal Les config mal foutues dans les logiciels libres. Évalué à -6.
Il leur suffit d'une boite de dialogue pour faire leur bonheur...
Tu devrais lancer le projet "file-picker-OS".
# Le meilleur conseil
Posté par IsNotGood . En réponse au journal Rigolons : accélérer Vista. Évalué à 10.
# Re:
Posté par IsNotGood . En réponse au journal Les config mal foutues dans les logiciels libres. Évalué à -10.
C'est ton avis personnel. L'upstream n'est pas de ton avis.
Pourquoi tu imposes tes goûts à tes "utilisateurs" ?
> - pour epiphany, page d'accueil par défaut : debian.org .
Vrai faux problème.
Fedora fournit le paquet fedora-bookmarks. Il suffit de le remplacer. Voilà ce qu'il faut faire.
> Pourquoi ne pas concevoir une sorte de portail personnalisé par la distribution qui permette d'une part d'avoir des info discrètes et de la documentations sur la distribution installée, mais également d'avoir des actualités, un moteur de recherche internet etc.
Mauvaise idée. C'est mon avis. Du moins pour la partie "la documentations sur la distribution installée". Apparament tes utilisateurs n'ont pas le compte root. Donc tout ce qui les intéressent c'est Firefox, OOo, etc. La doc de apt ou yum ils s'en trochent.
> Donc en général, première chose à faire c'est installer à la main firefox / thunderbird.
Le première chose à faire, est de bien chosir une distribution.
Parce qu'une distribution qui demande de faire des installations à la main pour des paquets aussi répendus que Firefox ou Thunderbird, ben c'est de la [censuré].
> C'est un peu lourd, ils n'ont qu'à faire comme pour java ou flash, ils mettent firefox dans la partie "non-free", et ils le redistribuent sans modification, et c'est réglé.
Pipo. Par défaut, lorsqu'on construit Firefox ou Thunderbird depuis les sources (c'est-à-dire sans le patcher ni activer une option spécifique (--enable-official-branding)), les marques Firefox et Thunderbird ne sont pas utilisées. Donc Debian n'a rien à faire. J'imagine que Debian a quelques patchs qui sucks.
Pour utiliser la marque Firefox il faut le faire exprès. Non l'inverse.
> - dans la plupart des distributions, pas de raccourci direct vers gnome-control-center, il faut passer par chaque option du menu pour configurer chaque point.
Et ?
Le but de Gnome est de marcher de suite. Pas d'imposer à l'utilisateur de visiter tous les panneaux de config. Donc c'est un vrai-faux problème.
> - pour le calendrier, si on clique dessus, certains ne comprennent pas que c'est comme un bouton poussoir et que l'on peut faire disparaître le calendrier en recliquant dessus. Une petit croix discrète et c'est résolu.
On peut voir ça comme un bug. Faudrait fouiller le bugzilla de Gnome, je ne serais pas étonné que ça soit déjà considéré comme un bug.
> En fait je pinaille et ce n'est pas très génant en soit, mais si on pose un classeur sur le clavier et que cela bloque sur cette touche, cela ouvre 500 copie d'écran !
C'est un peu de l'enculage de mouche :-)
> - le fameux drag n drop de la discussion citée plus haut : si on clique sans relacher le bouton sur un objet d'une fenêtre sous une autre en vue de déplacer ou activer l'objet sur la seconde fenêtre, la première passe au premier plan, empêchant d'aller sur la seconde. Idem sous KDE.
Bof...
> le texte en presse-papier disparaît (sans doute remplacé par la "selection" vide du clic).
Oui, et c'est normal. Même si pour les vieux c'est casse couille.
Pour le reste, j'ai décrocher. Je ne vois pas où tu veux en venir... Tu fais une critique des bureaux ? Oui, il y a des bugs. Des trucs mal pensé aujourd'hui et corrigé demain. etc.
[^] # Re: Daube
Posté par IsNotGood . En réponse à la dépêche Le poste de travail du gendarme sous GNU/Linux Ubuntu. Évalué à 8.
Et pourquoi ?
Et tu ne confonds pas erreur de packaging avec insuffisances des outils de packaging ?
Parce que même avec Ubuntu ou Debian les upgrades sucks. Il me semble qu'Ubuntu ne supporte que l'upgrade de la version n à la n+1. Toutes les distributions le font, même les distributions rpm.
> (je parle des versions de 97/98)
10 ans...
> la gestion des dependances etaient, comment dire..., aleatoire.
La gestion des dépendances a toujours été bonne. Sinon avance des arguments techniques.
La différence est que par défaut rpm s'arrête s'il ne peut mettre à jour un paquet. Deb l'ignore. C'est un choix "politique". Pour rpm, ne pas pouvoir mettre à jour un paquet est un problème de sécurité potentiel (en effet, la mise à jour est peut-être une mise à jour de sécurité). Deb a une autre philosophie. Ça ne veut pas dire que rpm sucks.
En passant, il y a le plugin yum-skip-broken pour ceux qui veulent le même comportement que deb.
> C'etait super chouette de savoir qu'il te manquait la libXXX.so.13221 et pas savoir dans quel paquet elle se trouvait...
Ici tu parles d'autres choses. Tu compares rpm à apt et c'est une erreur. Compare rpm à dpkg. Ou compare yum/apt4rpm/smart/up2date/urpmi/etc à apt.
> Des annees apres apt-get et je parle bien de la periode AVANT urpmi ou apt4rpm.
Et ?
Tu disais que Mandriva aurait dû passer à deb. Ben Mandrake n'avait pas deb et marchait très bien. Puis Mandrake a ajouté urpmi et marchait très. Puis Mandrake a moins bien marché (et pourtant deb/apt n'a pratiquement pas changé).
> Enfin c'est mon opinion toute personnelle
Pourquoi pas. Mais si tu dis que rpm sucks, faut donner des arguments valides.
> le train que ubuntu a lui a reussi a prendre!
Quel train ?
Le train deb ?
Le train AIGLX ?
Ooops, ce n'est pas Ubuntu qui l'a fait.
Le train "just works" de Gnome ?
Ooops, ce n'est pas Ubuntu qui l'a fait.
Le train udev/hal/etc ?
Ooops, ce n'est pas Ubuntu qui l'a fait.
etc.
Et où va aller ce train ?
Parce qu'à la belle époque de Mandrake, tout le monde disait que Mandrake allait bouffer Microsoft et que Red Hat ou Suse pue.
Il faut "se calmer". Ubuntu a "arraché" les gendarmerie et deux ou trois bricoles, ça reste très très très loins de Red Hat ou Novell.
Le train Ubuntu, c'est le train Debian. Dans 2 ans la gendarmerie passerait à Debian que je ne serais pas étonné.
La "mode" (si ça en est une) Ubuntu, peut s'essouffler comme la "mode" Mandrake.
[^] # Re: Pulseaudio
Posté par IsNotGood . En réponse au journal Fedora 9. Évalué à 1.
J'ai un peu de mal à comprendre ce que fait Zenworks Orchestrator.
> mince les gens faut arreter de me moinsser
Je t'ai plussé.
Je serais heureux de voir un journal qui explique Zenworks Orchestrator.
[^] # Re: Pulseaudio
Posté par IsNotGood . En réponse au journal Fedora 9. Évalué à 1.
Oui.
> tout en offrant un xnest si je ne me trompe pour voir ce qu'il se passe ?
Pour anaconda c'est un périphérique graphique (cas kvm/qemu). Sinon anaconda peut utiliser vnc (cas Xen) et l'affichage est renvoyé n'importe où.
C'est virt-viewer qui fait l'affichage final (virt-viewer est biensur appellé par virt-manager).
Pour le cas Xen, j'ai un doute car je ne l'utilise plus. Il se peut que Xen fournisse maintenant un périphique à la machine virtuelle.
Dans la pratique, on lance la machine virtuelle. Si on veut l'affichage (c-à-d accéder à une console (où tourne peut-être X11)) on double-clique sur la ligne qui représente la machine virtuelle et voilà.
> En tout cas, le fait d'installer dans un chroot est très pratique au delà des machines virtuelles, pratique par exemple pour se faire des chroots de build.
Mock est utilisé pour ça :
https://fedorahosted.org/mock/
Excellent pour les builds ou les tests.
Des choses dans ce goût peuvent aussi être faite :
# yum groupinstall --installroot=/mnt/root Base "Web Server"
Plus globalement, Red Hat investit énormemment dans la virtualisation. Donc il y a des résultats.
Maintenant Red Hat veut amener KVM/paravirt_ops au niveau de Xen et "virer" Xen (ce qui ne va pas être fait du jour au lendemain).
Fedora 9 (qui n'aura peut-être plus Xen) aura de sympatiques avancées :
http://fedoraproject.org/wiki/Features/VirtPolicyKit
http://fedoraproject.org/wiki/Features/VirtStorage
http://fedoraproject.org/wiki/Features/VirtAuthentication
[^] # Re: Daube
Posté par IsNotGood . En réponse à la dépêche Le poste de travail du gendarme sous GNU/Linux Ubuntu. Évalué à 4.
Qui sont ?
> ils ont du mettre au point un clone de apt-get etc
Il y a depuis des années apt4rpm.
Si deb est la clée du succès, pourquoi Red Hat et Novell explose deb dans les offres pour entreprise ?
Pourquoi Mandrake a fait un carton à ses débuts alors que debian existait à l'époque ?
Pourquoi Xandros, etc qui font des distributions simple à la Ubuntu n'ont pas percées comme Ubuntu ?
Etc.
Une distribution ne se résume pas à son gestionnaire de paquet. Loins loins loins de là.
La gestion du projet distribution, le buziness plan, etc plus beaucoup plus important. Dans ces domaines Mandriva n'a jamais été remarquable comme l'a été Ubuntu ou Red Hat.