Oui il y a les sources de Linux et c'est très pratique.
Oui il faut profiter des sources pour se sortir de "la merde".
Oui à toussa.
Mais n'empêche que dans la grande majorité des cas, c'est plus un "workaround", un "pis-allé" que la solution définitive.
Je dis ça et des programmes j'en ai compilé des tonnes. Mais il faut être honnète. C'est actuellement une faiblesse de Linux (en grande parti du au manque de support des contructeurs de périphérique) d'être parfois obligé de compiler un noyau.
La compilation d'un noyau ne doit pas être considéré comme la procédure "normal". C'est aussi pour ça que Linux a les modules. Pour ne pas avoir a compiler systématiquement un noyau.
Posté par 007 .
En réponse au journal J'adore Linus.
Évalué à 7.
Certe pour le CPU et toussa.
Mais :
p = 0 ; p++
c'est pas la même chose si p est un int ou un int *.
Si c'est un int alors p = 1. Si c'est un (int *) alors p = 4 (si sizeof(int) = 4).
Puis si p n'est pas un int, on passe à côté de toute l'arthémitique des pointeurs.
p[3] n'a aucun sens si p est un int.
Que l'adresse 0 soit valide ne change rien.
i = 0 // initialisation avec un int
i= (void *)0 // initialisation avec un pointeur (pour faire un reset :-))
i = NULL // initialisation avec un pointeur invalide
La norme ne dit pas que NULL est l'adresse 0. Le norme indique uniquement que c'est une adresse invalide en C.
De même si tu lis la norme posix, on a souvent :
- return NULL if ....
Mais pas
- return 0 if ...
Donc il faut toujours faire les tests avec (p == NULL).
Dans les bonnes règles de programmation ont rappèle toujours qu'il ne faut pas considérer qu'un pointeur est un entier.
J'ai bossé sur Digital Unix et j'ai :
sizeof(int) = 4
sizeof(void *) = 8
De même il ne faut jamais utiliser de int pour la différence de pointeur. Il faut utiliser le type ptr_diff.
Ce sont des règles de basse. sinon c'est la galère pour porter une appli dans un environnement 64 bits.
Je suis absolument d'accord avec Linus, il faut banir le '0' pour les pointeurs. Peut-être qu'un jour les compilateurs mettrons un gros warning lorsqu'un pointeur est initialisé avec un int. Car c'est fondamentalement une erreur. Les int et les pointeurs n'ont rien à voir.
> Ils ne sont pas masos au point de maintenir un truc deprécié si une meilleure alternative existe.
Certe. Mais tu ne comprends.
Mdk pour maintenir la 10.0 devrait maintenir devfs. Pas le chois.
Je sais bien que les prochaines Mandrake ne font pas utiliser devfs.
Merci. Instructif.
Pour un usage desktop ça change rien (au pire 1 %).
> y'a eu d'autre discutions sur le sujet.
Pour ma part, Linux (upstream) n'a pas a intégrer ce patch. Ce patch est une optimisation temporaire car il y a encore beaucoup de système 32 bits.
Dans 3 ans tous les serveurs seront en 64 bits et ce patch ne sera plus nécessaire.
Le prix d'un système 64 bits a dramatiquement (dans le sens positif :-)) baissé.
> Cela dit, gtk#, je pense que c'est un bon concept.
C'est pour ça que gtk/gnome est écrit en C et aussi pour ça qu'il y a gobject.
Formidable.
Ne pas confondre les "briques" de base et les applis. Gnome c'est :
- des briques de base avec des bindings
- un bureau avec des applis
Si tu veux faire tes applis en C++ ou C# ou python ou java, tu peux. Tout a été prévu.
C'est peut-être possible avec des "briques" de base en C++ mais c'est plus dure.
Mais on peut aussi toujours faire de bonne applis graphique en C. Ça dépend du domaine.
> Gnome a choisi de cacher pour pas que les premiers tombent dessus. KDE a fait le choix de les considerer comme des utilisateurs legitimes et de leur donner aussi une belle interface graphique.
Globalement je suis d'accord mais évites les trolls comme "des utilisateurs legitimes". Je ne vais pas dire que KDE considère les développeurs C comme "illégitimes".
Il y a deux bureaux différents qui ciblent deux types d'utilisateurs différents et c'est très bien.
Donc ne prenons pas MDI comme référence pour parler du projet Gnome d'aujourd'hui ou d'un soit-disant mécontentement général des développeurs.
Il y a maintenant (en fait depuis plusieurs années) des personnes beaucoup plus influentes et écoutées que MDI dans le projet Gnome.
De toute manière, le plus influent reste la communauté des développeurs "silencieux".
Les "MDI c'est levé du pied gauche donc salle temps pour Gnome aujourd'hui" et "MDI a compilé 'hello world !' en C++ donc Gnome va abandonner le C pour le C++" je m'en fous complètement.
> Je ne sais pas pourquoi tu sors ton delire sur Red hat.
Pour montrer que si je délire avec Red Hat, les propos sur Ximian sont aussi du délire et sont fondés sur rien.
J'espère que tu as remarqué ?
> Ce probleme a ete corrige rapidement (en quelques jours si je me souviens bien)
Quelques jours et il y a plusieurs années. Ça valait vraiment la peine de le rappeler...
> C'est juste que dire que Ximian est completement independant de Gnome et vice versa, ce n'est pas tout a fait vrai.
Et tu veux en venir où ?
Tu veux que je dise :
- "KDE est dépendant de Trolltech".
Tous les projets libres sont dépendants et orientés par les contributeurs. Ça n'a rien de nouveau.
Mais certains, qui ne manquent pas d'imagination, y voient des plans machiavéliques et ce uniquement pour dénigrer un projet libre et je trouve ça lourdingue.
Je ne parle pas de ça. Considère que kcontrol est génialissime et hypersimple, ça ne change rien à ce que je dis/pense.
Les gens ne customisent presque pas leur bureau en général.
Que soit simple ou pas de customiser son bureau, n'entre pas en ligne de compte. Je crois (c'est subjectif) que globalement ils s'en foutent et que dans la grande majorité des cas ils se satisfont des réglages par défaut.
Posté par 007 .
En réponse au journal J'adore Linus.
Évalué à 5.
Juste aussi une petit précision.
Globalement ça rend le code plus lisible.
Mais dans certains cas on ne peut pas utiliser '0' à la place de 'NULL'.
Typiquement les fonctions avec un nombre variable de paramètres (traité avec varargs).
toto("coucou : %p, %s\n", 0, "tralala") ;
est différent de :
toto("coucou : %p, %s\n", NULL, "tralala") ; # NULL ou "(void *)0"
Avec '0', sur la pile il y a :
- char *
- int
- char *
alors que la fonction toto() fait comme s'il y avait :
- char *
- void *
- char *
Si sizeof(int) != sizeof(void *) (typiquement le cas sur machine 64 bits), des problèmes sont à prévoir.
J'ai ignoré la promotion faite en C mais pas en C++.
C'est Red Hat qui héberge tout Gnome (web, ftp, cvs, mailing, bugzilla, bande passante, tout quoi).
Si tu peux faire l'hébergement en ne demandant rien en retour (même pas un lien) contacte la fondation Gnome. Il appréciront ton geste.
Dans ton élan tu pourrais aussi t'occuper de : http://sources.redhat.com/projects.html(...)
Ça fait beaucoup de projets importants (binutils, gcc, gdb, automake, autoconf, libstdc++, lvm, device-mapper etc...) pour une boîte... J'espère que tu n'utilises aucun de ces projets pour ne pas être "corrompu".
Par la même occasion, si tu as du pognon en trop, finance gnome pour qu'il puisse se passer de la page sponsor (en gros c'est une page de pub) : http://foundation.gnome.org/(...)
Pis tu trouves pas ça bizarre comme les dates de sortie de Gnome coïncident bien avec les dates de sortie des distributions RedHat/Fedora ?
> la réalité contredit sans trop de problèmes les affirmations/generalisation
C'était une "généralité" et toi tu parles d'un cas particulier. Ma généralité ne va pas être contredite par un cas particulier.
J'ai dit :
- "les développeurs sont surtout utilisateur de GNU/Linux et très occasionnellement de Windows ou Mac."
Et pas :
- "tous les développeurs utilisent uniquement GNU/Linux et jamais Windows ou Mac."
Tu ne vois pas une légère différence entre ces phrases ?
Tu as vu le mots graphiste ? Je parle des développeurs.
Ben j'y peux rien.
Que ton cousin ou ton grand-père graphiste (et pas développeur) utilise aussi Windows ne change rien à ça. On ne contredit pas une généralité avec un cas particulité.
> gnome.org n'a pas eu comme page "download" un lien direct vers Ximian
Je ne réponds pas à tout le reste car ça me broute.
Vas sur http://www.gnome.org/(...) et regardes en bas de la page.
Il y a un lien vers http://redhat.com/(...) . Oui Oui, Red Hat le méchant qui te pourri le look de gnome avec le fadasse thème Bluecurve (tm) (C'est une marque déposé : Ahh! les méchants Red Hat). Red Hat qui te change toute la configuration par défaut (surtout le panel). Red Hat qui mets Mozilla par défaut et pas galeon ou epiphany. Red Hat qui a (attention, c'est du brutal) diffusé l'antialiasing pour Gnome bien avant le Gnome officiel . Pour Gdm, ils ont leur propre thème et n'utilise pas un thème fournis par gdm. Red Hat qui n'a jamais mis balsa par défaut et il y a même un thread récent sur la mailing devel de Fedora pour virer Balsa. Ces cochons ont aussi été parmis les premiers à mettre evolution par défaut (et aussi pour KDE !).
C'est aussi Red Hat qui noyaute Gtk+ (avec utf8, ce gouffre à cpu) et nautilus (c'est plus helix/eazel/MDI/etc).
Ne parlons pas d'havoc qui se répend en blob pour que java soit privilégié car il trouve python un peu "limité".
Tu te rend compte du scandale ? Pardon, des scandales ?
Tu te laisse avec ces infos pour que tu puisses faire tourner ta boite à fantasme pour les 4 ans à venir.
PS : c'est dingue comme à partir d'un simple lien sur gnome.org on peut en dire des conneries.
> Et qu'on ne me dise pas que soit un calvaire pour trouver ce que l'on cherche
Le problème n'est pas là. Sous Gnome c'est aussi simpliste et beaucoup de personnes (notament les développeurs) ne touchent pas aux valeurs par défaut.
Regardes les postes sous Windows (c'est pas plus compliqué que KDE ou Gnome) et en général la customisation va pas loin :
- fond d'écran
- économiseur d'écran
Avec ça, tu couvres 90 % des personnalisations sans problème. Je compte pas les icones sur le bureau. C'est lié à l'organisation de l'utilisateur, ce n'est pas vraiment de la personnalisation.
Moi, c'est :
- un thème légèrement différent (moins joli mais plus lisible)
- pas d'écran de veille (mode économie d'énergie directement)
C'est tout.
Et depuis que metacity permet de mettre les fenêtres au premier plan, j'ai la flemme d'installer IceWM comme je le faisais avant...
Red Hat fait une distribution gratos et en profite pour faire RHEL avec. Les utilisateurs de Fedora sont contents car c'est gratos et ça aide le logiciel libre et Red Hat est content car ça leur permet de développer RHEL qui rapporte du pognon et qui permet de développer le logiciel libre.
Comme d'habitude, les gens veulent tout de Red Hat et sans contre partie. Ben faut pas rèver.
http://fedora.redhat.com/(...) What is The Fedora Project?
The Fedora Project is a Red-Hat-sponsored and community-supported open source project. It is also a proving ground for new technology that may eventually make its way into Red Hat products.
C'est sur la homepage et au tout début. Tu es prévenu. Si ça te plait, tu passes ton chemin.
Merci au revoir.
> ce que je constate c'est qu'il y en a au moins un qui m'emmerde et qui fait se vautrer ma machine lors d'un bete cp (de quelque GO quand meme) ou mount.
Des fichiers de plusieurs Go, mon PC en bouffe. J'utilise mon PC pour enregistrer la TV et je te garanti que ça bouffe cette "saloperie" quand tu veux une bonne définition.
J'ai un uptime tout frais car j'ai mis à jours (trou de sécurité qui n'est pas en upstream...). Mais avant j'avais plus de 30 jours. A 10 Go par jours (minimum) ça fait dans les 300 Go de donnée de brassé (ext3 avec 4:4 :-)). Chaque fichier fait dans les 2 à 6 Go.
> Oui parmis la tonne de patch appliqués par mdk, rh ou SuSE y'en a qui merdent et d'autre merdes aussi dans le vanilla.
Oui. Mais ...
Si Mdk, etc ajoutent ces patchs, c'est pas pour rien. Globalement l'objectif est d'améliorer l'expérience de l'utilisateur. Si globalement ça ne fait qu'emmerder l'utilisateur, tu penses pas bien qu'ils ne vont pas se faire chier à maintenir ces patchs.
Puis il y a une différence entre Linux upstream (le développement) et les distributions. Les distributions peuvent fait une patch "moche" mais qui corrige un bug très génant pour l'utilisateur.
Linux (upstream) ajoutera ce patch lorsqu'il sera propre. Il ne faut pas qu'un hack "moche" soit la base des autres développements.
C'est un élément important et même très important.
Il faut bien différencier le développement (mettre en place une infrastructure solide) et la maintenance (corriger les petits bobo même si c'est fait de façon immonde).
> Le problème c'est que tu mélange tout. Faire une update de sécu ce n'est pas grave, c'est normal et il y a peu de risque de pourrir la chose avec.
Tu parles en "rebelle" (je suis un "rebelle", ne vous énervez pas). Tu trouves normal de demander à l'utilisateur final de suivre les failles de sécurité, de patcher un noyau, de recompiler ? Normal pour un "rebelle". Pas normal pour un utilisateur lambda.
Depuis longtemps (au moins le 2.4), le Linux vanilla n'est plus un noyau "out of the box". C'est un noyau qu'il faut utiliser en étant abonné à la lkml (faille de sécurité, gros bug (genre le dernier ext3)).
> non pas le temps d'investiguer je pars en vacance demain.
Bonne vacance (enfoiré :-)).
> Personellement j'en compile un paquet par ce que je m'interesse a certaines parties en devel ou fait de petites exprerimentations
Le "rebelle touch". C'est respectable. J'utilise Fedora, donc je vais pas critiquer l'attitude.
> Par contre quand tu vois des choix absurdent tel que 4:4 de base ca ne va pas inciter les gens a moins recompiler...
Pssss...
C'est pour Fedora ( relis http://fedora.redhat.com/about/(...) ).
Puis ce patch est limite "vieux" (devait "trainer" dans FC1 (peut-être RH9 ?), est dans RHEL 3 depuis longtemps).
Tu ne te sers pas de 4:4 et moi non plus. Mais ça interressent des gens. Pour les clients de Red Hat c'est important (sinon pourquoi Red Hat ce fait chié avec ça ?).
Il faut que Red Hat sorte un noyau avec 4:4, un sans 4:4, un avec usb, un sans usb, un autre avec SeLinux, un autre sans SeLinux, etc...
Non, c'est ingérable.
Il faut que le noyau "de base" supporte le maximum de configuration sinon c'est l'enfer à maintenir, tester (trouver des testeurs pour 50 configurations de noyau différente pour chaque correction de bug/sécurité, c'est dure...).
Tu fais une fixation sur le noyau mais je suis sûre que si tu regardais d'autres programmes tu verrais plein de truc que tu n'utilises pas non plus.
Installes une Gentoo.
btw, les patchs Red Hat se retrouvent très souvent dans le vanilla. Donc c'est débile pour toi quand c'est Red Hat "only" et c'est bien quand c'est dans vanilla.
4kstack dans FC2 c'est nul. Mais maintenant que c'est dans 2.6.7 c'est bien. Logique... (tu peux m'expliquer ?).
Pour que ça rentre en upstream (et fasse ton bonheur) et faut faire du travail en amont. Linus ne va pas accepter des patch intrusifs sans un minimum de test et de feedback des utilisateurs. Et Fedora est fait aussi pour ça.
J'insiste, relis ça : http://fedora.redhat.com/about/(...)
> C'est bizarre mais les vanillas ne m'ont jamais posés de problèmes...
ok ok ok.
Les vanillas sont nickels et ce sont que les méchants distributeurs qui ajoutent des bugs dedans. C'est connu... D'ailleur dès qu'il y a un bug dans Linux une nouvelle version sort. Mais oui...
Voir ça par exemple : http://linuxfr.org/2004/06/15/16537.html(...)
Mais redevenons sérieux.
Avant de vous énerver encore plus, je recompile aussi mon noyau car REGPARM ne marche pas avec un driver que j'utilise. Mais sinon je garderai celui par défaut.
Tu vois quoi sur les forum :
- Comment on recompile un noyau ?
- tu copies /boot/config-.... /usr/src/linux, puis "make install"
La majorité c'est ça. L'autre grande majorité ne recompile pas.
Il m'arrive aussi de me tromper dans la configuration de mon noyau "customiser" alors que je compile linux depuis 1.2 (et à l'époque c'était pratiquement obligatoire).
Cette "histoire" de recompiler le noyau, c'est comme pour apache. Avant il fallait recompiler apache, maintenant c'est plus nécessaire et ceux qui recompile apache sont rares. Avant il fallait recompile mplayer (obligatoire) et maintenant presque tout le monde fait "apt/yum install mplayer". C'est une tendance lourde et qui est absolument normale. Je me trompe ?
Ce qui est arrivé aux autres (apache, mplayer, mod_ssl, etc) va arriver à Linux.
> Des rebels utilisant fedora et qui aimerai bien que leur noyau n'Oops pas sur des cp massif sur de l'ext3 (2.6.6)
T'as un rapport de bug ? C'était sûrement un noyau de développement (rawhide). J'ai utilisé tous les noyau FC2 depuis la FC2T2 et j'ai pas vu ce problème.
Fedora est un peu particulier. Fedora est là pour "imposer" des nouvelles techno (dont 4kstack qui ne marche pas avec NVidia).
Pour l'"esprit" Fedora, relire : http://fedora.redhat.com/about/(...)
Si tu me trouves une distribution grand public ou entreprise qui dans le manuel d'installation ou d'administration indique "il faut recompiler le noyau", tu me fais signe.
Mais c'est bien, t'as raison.
Tu n'utilises pas Gnome et tu n'arrêtes pas de critiquer, tu passes tes nuits à analyser son historique, à analyser les influences de chaqu'un (mais surtout MDI), ces performances, l'évolution des rapports de bug, les engueulages entre développeurs, ceux qui quittent le projet, les erreurs de frappe, etc...
Maintenant t'arrives avec un cas particulier.
En 5 mots comme en 100 :
Tu me casses les couilles.
[^] # Re: Re:
Posté par 007 . En réponse au journal Le noyau linux change de mode de développement. Évalué à 1.
Oui il faut profiter des sources pour se sortir de "la merde".
Oui à toussa.
Mais n'empêche que dans la grande majorité des cas, c'est plus un "workaround", un "pis-allé" que la solution définitive.
Je dis ça et des programmes j'en ai compilé des tonnes. Mais il faut être honnète. C'est actuellement une faiblesse de Linux (en grande parti du au manque de support des contructeurs de périphérique) d'être parfois obligé de compiler un noyau.
La compilation d'un noyau ne doit pas être considéré comme la procédure "normal". C'est aussi pour ça que Linux a les modules. Pour ne pas avoir a compiler systématiquement un noyau.
[^] # Re: Petites precisions
Posté par 007 . En réponse au journal J'adore Linus. Évalué à 7.
Mais :
p = 0 ; p++
c'est pas la même chose si p est un int ou un int *.
Si c'est un int alors p = 1. Si c'est un (int *) alors p = 4 (si sizeof(int) = 4).
Puis si p n'est pas un int, on passe à côté de toute l'arthémitique des pointeurs.
p[3] n'a aucun sens si p est un int.
Que l'adresse 0 soit valide ne change rien.
i = 0 // initialisation avec un int
i= (void *)0 // initialisation avec un pointeur (pour faire un reset :-))
i = NULL // initialisation avec un pointeur invalide
La norme ne dit pas que NULL est l'adresse 0. Le norme indique uniquement que c'est une adresse invalide en C.
De même si tu lis la norme posix, on a souvent :
- return NULL if ....
Mais pas
- return 0 if ...
Donc il faut toujours faire les tests avec (p == NULL).
Dans les bonnes règles de programmation ont rappèle toujours qu'il ne faut pas considérer qu'un pointeur est un entier.
J'ai bossé sur Digital Unix et j'ai :
sizeof(int) = 4
sizeof(void *) = 8
De même il ne faut jamais utiliser de int pour la différence de pointeur. Il faut utiliser le type ptr_diff.
Ce sont des règles de basse. sinon c'est la galère pour porter une appli dans un environnement 64 bits.
Je suis absolument d'accord avec Linus, il faut banir le '0' pour les pointeurs. Peut-être qu'un jour les compilateurs mettrons un gros warning lorsqu'un pointeur est initialisé avec un int. Car c'est fondamentalement une erreur. Les int et les pointeurs n'ont rien à voir.
[^] # Re: Situation périlleuse....
Posté par 007 . En réponse au journal Le noyau linux change de mode de développement. Évalué à 2.
Certe. Mais tu ne comprends.
Mdk pour maintenir la 10.0 devrait maintenir devfs. Pas le chois.
Je sais bien que les prochaines Mandrake ne font pas utiliser devfs.
[^] # Re: Re: Re:
Posté par 007 . En réponse au journal Le noyau linux change de mode de développement. Évalué à 0.
Merci. Instructif.
Pour un usage desktop ça change rien (au pire 1 %).
> y'a eu d'autre discutions sur le sujet.
Pour ma part, Linux (upstream) n'a pas a intégrer ce patch. Ce patch est une optimisation temporaire car il y a encore beaucoup de système 32 bits.
Dans 3 ans tous les serveurs seront en 64 bits et ce patch ne sera plus nécessaire.
Le prix d'un système 64 bits a dramatiquement (dans le sens positif :-)) baissé.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
C'est pour ça que gtk/gnome est écrit en C et aussi pour ça qu'il y a gobject.
Formidable.
Ne pas confondre les "briques" de base et les applis. Gnome c'est :
- des briques de base avec des bindings
- un bureau avec des applis
Si tu veux faire tes applis en C++ ou C# ou python ou java, tu peux. Tout a été prévu.
C'est peut-être possible avec des "briques" de base en C++ mais c'est plus dure.
Mais on peut aussi toujours faire de bonne applis graphique en C. Ça dépend du domaine.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 1.
Moi qui pensais que la philosophie Gnome 2.0 venait principalement d'Havoc :
Free software and good user interfaces
http://ometer.com/free-software-ui.html(...)
Ben non, c'est encore MDI.
- "VIVE MDI (qui fait la pluis et le beau temps) !!!"
[^] # Re: Un fork pour un gnome d'expert
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
Globalement je suis d'accord mais évites les trolls comme "des utilisateurs legitimes". Je ne vais pas dire que KDE considère les développeurs C comme "illégitimes".
Il y a deux bureaux différents qui ciblent deux types d'utilisateurs différents et c'est très bien.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
ORBit est sorti pour Gnome 1.2 il me semble...
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 1.
Il y a maintenant (en fait depuis plusieurs années) des personnes beaucoup plus influentes et écoutées que MDI dans le projet Gnome.
De toute manière, le plus influent reste la communauté des développeurs "silencieux".
Les "MDI c'est levé du pied gauche donc salle temps pour Gnome aujourd'hui" et "MDI a compilé 'hello world !' en C++ donc Gnome va abandonner le C pour le C++" je m'en fous complètement.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à -1.
Pour montrer que si je délire avec Red Hat, les propos sur Ximian sont aussi du délire et sont fondés sur rien.
J'espère que tu as remarqué ?
> Ce probleme a ete corrige rapidement (en quelques jours si je me souviens bien)
Quelques jours et il y a plusieurs années. Ça valait vraiment la peine de le rappeler...
> C'est juste que dire que Ximian est completement independant de Gnome et vice versa, ce n'est pas tout a fait vrai.
Et tu veux en venir où ?
Tu veux que je dise :
- "KDE est dépendant de Trolltech".
Tous les projets libres sont dépendants et orientés par les contributeurs. Ça n'a rien de nouveau.
Mais certains, qui ne manquent pas d'imagination, y voient des plans machiavéliques et ce uniquement pour dénigrer un projet libre et je trouve ça lourdingue.
[^] # Re: Un fork pour un gnome d'expert
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
Je ne parle pas de ça. Considère que kcontrol est génialissime et hypersimple, ça ne change rien à ce que je dis/pense.
Les gens ne customisent presque pas leur bureau en général.
Que soit simple ou pas de customiser son bureau, n'entre pas en ligne de compte. Je crois (c'est subjectif) que globalement ils s'en foutent et que dans la grande majorité des cas ils se satisfont des réglages par défaut.
[^] # Re: La preuve de la supériorité absolue de Java
Posté par 007 . En réponse au journal J'adore Linus. Évalué à 0.
Et il serait plus rapide. Mais aussi il n'y aurait aucun problème de portage.
[^] # Re: Petites precisions
Posté par 007 . En réponse au journal J'adore Linus. Évalué à 5.
Globalement ça rend le code plus lisible.
Mais dans certains cas on ne peut pas utiliser '0' à la place de 'NULL'.
Typiquement les fonctions avec un nombre variable de paramètres (traité avec varargs).
toto("coucou : %p, %s\n", 0, "tralala") ;
est différent de :
toto("coucou : %p, %s\n", NULL, "tralala") ; # NULL ou "(void *)0"
Avec '0', sur la pile il y a :
- char *
- int
- char *
alors que la fonction toto() fait comme s'il y avait :
- char *
- void *
- char *
Si sizeof(int) != sizeof(void *) (typiquement le cas sur machine 64 bits), des problèmes sont à prévoir.
J'ai ignoré la promotion faite en C mais pas en C++.
[^] # Re: Situation périlleuse....
Posté par 007 . En réponse au journal Le noyau linux change de mode de développement. Évalué à 1.
Final stabilization is to be done by distributors (as happens now, really)
Ça va s'accélérer.
Je trouve ça assez bien. Par contre, le problème c'est pour les petits distributions. Il faudra plus de ressources maintenant.
Par exemple devfs va être viré et Mdk utilise devfs. C'est maintenant à Mdk de maintenir devfs pour ses produits qui l'utilisent.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
C'est Red Hat qui héberge tout Gnome (web, ftp, cvs, mailing, bugzilla, bande passante, tout quoi).
Si tu peux faire l'hébergement en ne demandant rien en retour (même pas un lien) contacte la fondation Gnome. Il appréciront ton geste.
Dans ton élan tu pourrais aussi t'occuper de :
http://sources.redhat.com/projects.html(...)
Ça fait beaucoup de projets importants (binutils, gcc, gdb, automake, autoconf, libstdc++, lvm, device-mapper etc...) pour une boîte... J'espère que tu n'utilises aucun de ces projets pour ne pas être "corrompu".
Par la même occasion, si tu as du pognon en trop, finance gnome pour qu'il puisse se passer de la page sponsor (en gros c'est une page de pub) :
http://foundation.gnome.org/(...)
Pis tu trouves pas ça bizarre comme les dates de sortie de Gnome coïncident bien avec les dates de sortie des distributions RedHat/Fedora ?
Y a manifestement anguile sous roche.
[^] # Re: ho sigh, windows...
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à -1.
C'était une "généralité" et toi tu parles d'un cas particulier. Ma généralité ne va pas être contredite par un cas particulier.
J'ai dit :
- "les développeurs sont surtout utilisateur de GNU/Linux et très occasionnellement de Windows ou Mac."
Et pas :
- "tous les développeurs utilisent uniquement GNU/Linux et jamais Windows ou Mac."
Tu ne vois pas une légère différence entre ces phrases ?
Tu as vu le mots graphiste ? Je parle des développeurs.
Ben j'y peux rien.
Que ton cousin ou ton grand-père graphiste (et pas développeur) utilise aussi Windows ne change rien à ça. On ne contredit pas une généralité avec un cas particulité.
[^] # Re: << Gtk only >>, le fork qui n'en n'était pas un.
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
Je ne réponds pas à tout le reste car ça me broute.
Vas sur http://www.gnome.org/(...) et regardes en bas de la page.
Il y a un lien vers http://redhat.com/(...) . Oui Oui, Red Hat le méchant qui te pourri le look de gnome avec le fadasse thème Bluecurve (tm) (C'est une marque déposé : Ahh! les méchants Red Hat). Red Hat qui te change toute la configuration par défaut (surtout le panel). Red Hat qui mets Mozilla par défaut et pas galeon ou epiphany. Red Hat qui a (attention, c'est du brutal) diffusé l'antialiasing pour Gnome bien avant le Gnome officiel . Pour Gdm, ils ont leur propre thème et n'utilise pas un thème fournis par gdm. Red Hat qui n'a jamais mis balsa par défaut et il y a même un thread récent sur la mailing devel de Fedora pour virer Balsa. Ces cochons ont aussi été parmis les premiers à mettre evolution par défaut (et aussi pour KDE !).
C'est aussi Red Hat qui noyaute Gtk+ (avec utf8, ce gouffre à cpu) et nautilus (c'est plus helix/eazel/MDI/etc).
Ne parlons pas d'havoc qui se répend en blob pour que java soit privilégié car il trouve python un peu "limité".
Tu te rend compte du scandale ? Pardon, des scandales ?
Tu te laisse avec ces infos pour que tu puisses faire tourner ta boite à fantasme pour les 4 ans à venir.
PS : c'est dingue comme à partir d'un simple lien sur gnome.org on peut en dire des conneries.
[^] # Re: Un fork pour un gnome d'expert
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
> Et qu'on ne me dise pas que soit un calvaire pour trouver ce que l'on cherche
Le problème n'est pas là. Sous Gnome c'est aussi simpliste et beaucoup de personnes (notament les développeurs) ne touchent pas aux valeurs par défaut.
Regardes les postes sous Windows (c'est pas plus compliqué que KDE ou Gnome) et en général la customisation va pas loin :
- fond d'écran
- économiseur d'écran
Avec ça, tu couvres 90 % des personnalisations sans problème. Je compte pas les icones sur le bureau. C'est lié à l'organisation de l'utilisateur, ce n'est pas vraiment de la personnalisation.
Moi, c'est :
- un thème légèrement différent (moins joli mais plus lisible)
- pas d'écran de veille (mode économie d'énergie directement)
C'est tout.
Et depuis que metacity permet de mettre les fenêtres au premier plan, j'ai la flemme d'installer IceWM comme je le faisais avant...
[^] # Re: Un fork pour un gnome d'expert
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 0.
Si le gestionnaire PIM plante ou s'il n'est pas installé, t'es mal parti pour faire un rapport de bug.
Mais surtout que ça ne te prive pas de développer ton troll.
[^] # Re: Re: Re:
Posté par 007 . En réponse au journal Le noyau linux change de mode de développement. Évalué à 0.
Ah bon. Si tu le dis...
N'empêche que des gens installent Fedora sur du 64 bits car 32 ça commence a être un peu limité.
> tu connais beaucoup de personnes assez debiles pour avoir 16..64Go de RAM sur un x86
Beaucoup non mais j'en connais. D'ailleur Windows a un équivalent de 4g/4g.
> et que ca plombe les perfs de tout le reste de facon non negligeable
Un bench ?
> Dans ce cas oui ca me parait plutot approprie de proposer un noyau special pour les 3 personnes qui vont utiliser la chose.
Rererererererererelire : http://fedora.redhat.com/about/(...)
Red Hat fait une distribution gratos et en profite pour faire RHEL avec. Les utilisateurs de Fedora sont contents car c'est gratos et ça aide le logiciel libre et Red Hat est content car ça leur permet de développer RHEL qui rapporte du pognon et qui permet de développer le logiciel libre.
Comme d'habitude, les gens veulent tout de Red Hat et sans contre partie. Ben faut pas rèver.
http://fedora.redhat.com/(...)
What is The Fedora Project?
The Fedora Project is a Red-Hat-sponsored and community-supported open source project. It is also a proving ground for new technology that may eventually make its way into Red Hat products.
C'est sur la homepage et au tout début. Tu es prévenu. Si ça te plait, tu passes ton chemin.
Merci au revoir.
[^] # Re: une discrimination intolérable !
Posté par 007 . En réponse à la dépêche Poudre Verte vs NaDa. Évalué à 0.
Ooops, j'ai les dragées FUSCHIA qui rentre en action. J'y cours....
Coooolll.... Je me sens bien... alors que ça sent pas ...
Ça relache vachement les neurones ce truc.
[^] # Re: Re: Re:
Posté par 007 . En réponse au journal Le noyau linux change de mode de développement. Évalué à 0.
Des fichiers de plusieurs Go, mon PC en bouffe. J'utilise mon PC pour enregistrer la TV et je te garanti que ça bouffe cette "saloperie" quand tu veux une bonne définition.
J'ai un uptime tout frais car j'ai mis à jours (trou de sécurité qui n'est pas en upstream...). Mais avant j'avais plus de 30 jours. A 10 Go par jours (minimum) ça fait dans les 300 Go de donnée de brassé (ext3 avec 4:4 :-)). Chaque fichier fait dans les 2 à 6 Go.
> Oui parmis la tonne de patch appliqués par mdk, rh ou SuSE y'en a qui merdent et d'autre merdes aussi dans le vanilla.
Oui. Mais ...
Si Mdk, etc ajoutent ces patchs, c'est pas pour rien. Globalement l'objectif est d'améliorer l'expérience de l'utilisateur. Si globalement ça ne fait qu'emmerder l'utilisateur, tu penses pas bien qu'ils ne vont pas se faire chier à maintenir ces patchs.
Puis il y a une différence entre Linux upstream (le développement) et les distributions. Les distributions peuvent fait une patch "moche" mais qui corrige un bug très génant pour l'utilisateur.
Linux (upstream) ajoutera ce patch lorsqu'il sera propre. Il ne faut pas qu'un hack "moche" soit la base des autres développements.
C'est un élément important et même très important.
Il faut bien différencier le développement (mettre en place une infrastructure solide) et la maintenance (corriger les petits bobo même si c'est fait de façon immonde).
> Le problème c'est que tu mélange tout. Faire une update de sécu ce n'est pas grave, c'est normal et il y a peu de risque de pourrir la chose avec.
Tu parles en "rebelle" (je suis un "rebelle", ne vous énervez pas). Tu trouves normal de demander à l'utilisateur final de suivre les failles de sécurité, de patcher un noyau, de recompiler ? Normal pour un "rebelle". Pas normal pour un utilisateur lambda.
Depuis longtemps (au moins le 2.4), le Linux vanilla n'est plus un noyau "out of the box". C'est un noyau qu'il faut utiliser en étant abonné à la lkml (faille de sécurité, gros bug (genre le dernier ext3)).
> non pas le temps d'investiguer je pars en vacance demain.
Bonne vacance (enfoiré :-)).
> Personellement j'en compile un paquet par ce que je m'interesse a certaines parties en devel ou fait de petites exprerimentations
Le "rebelle touch". C'est respectable. J'utilise Fedora, donc je vais pas critiquer l'attitude.
> Par contre quand tu vois des choix absurdent tel que 4:4 de base ca ne va pas inciter les gens a moins recompiler...
Pssss...
C'est pour Fedora ( relis http://fedora.redhat.com/about/(...) ).
Puis ce patch est limite "vieux" (devait "trainer" dans FC1 (peut-être RH9 ?), est dans RHEL 3 depuis longtemps).
Tu ne te sers pas de 4:4 et moi non plus. Mais ça interressent des gens. Pour les clients de Red Hat c'est important (sinon pourquoi Red Hat ce fait chié avec ça ?).
Il faut que Red Hat sorte un noyau avec 4:4, un sans 4:4, un avec usb, un sans usb, un autre avec SeLinux, un autre sans SeLinux, etc...
Non, c'est ingérable.
Il faut que le noyau "de base" supporte le maximum de configuration sinon c'est l'enfer à maintenir, tester (trouver des testeurs pour 50 configurations de noyau différente pour chaque correction de bug/sécurité, c'est dure...).
Tu fais une fixation sur le noyau mais je suis sûre que si tu regardais d'autres programmes tu verrais plein de truc que tu n'utilises pas non plus.
Installes une Gentoo.
btw, les patchs Red Hat se retrouvent très souvent dans le vanilla. Donc c'est débile pour toi quand c'est Red Hat "only" et c'est bien quand c'est dans vanilla.
4kstack dans FC2 c'est nul. Mais maintenant que c'est dans 2.6.7 c'est bien. Logique... (tu peux m'expliquer ?).
Pour que ça rentre en upstream (et fasse ton bonheur) et faut faire du travail en amont. Linus ne va pas accepter des patch intrusifs sans un minimum de test et de feedback des utilisateurs. Et Fedora est fait aussi pour ça.
J'insiste, relis ça :
http://fedora.redhat.com/about/(...)
[^] # Re: Gnome Leger?
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à 1.
http://bugzilla.gnome.org/show_bug.cgi?id=141797(...)
[^] # Re: Re: Re:
Posté par 007 . En réponse au journal Le noyau linux change de mode de développement. Évalué à 1.
ok ok ok.
Les vanillas sont nickels et ce sont que les méchants distributeurs qui ajoutent des bugs dedans. C'est connu... D'ailleur dès qu'il y a un bug dans Linux une nouvelle version sort. Mais oui...
Voir ça par exemple :
http://linuxfr.org/2004/06/15/16537.html(...)
Mais redevenons sérieux.
Avant de vous énerver encore plus, je recompile aussi mon noyau car REGPARM ne marche pas avec un driver que j'utilise. Mais sinon je garderai celui par défaut.
Tu vois quoi sur les forum :
- Comment on recompile un noyau ?
- tu copies /boot/config-.... /usr/src/linux, puis "make install"
La majorité c'est ça. L'autre grande majorité ne recompile pas.
Il m'arrive aussi de me tromper dans la configuration de mon noyau "customiser" alors que je compile linux depuis 1.2 (et à l'époque c'était pratiquement obligatoire).
Cette "histoire" de recompiler le noyau, c'est comme pour apache. Avant il fallait recompiler apache, maintenant c'est plus nécessaire et ceux qui recompile apache sont rares. Avant il fallait recompile mplayer (obligatoire) et maintenant presque tout le monde fait "apt/yum install mplayer". C'est une tendance lourde et qui est absolument normale. Je me trompe ?
Ce qui est arrivé aux autres (apache, mplayer, mod_ssl, etc) va arriver à Linux.
> Des rebels utilisant fedora et qui aimerai bien que leur noyau n'Oops pas sur des cp massif sur de l'ext3 (2.6.6)
T'as un rapport de bug ? C'était sûrement un noyau de développement (rawhide). J'ai utilisé tous les noyau FC2 depuis la FC2T2 et j'ai pas vu ce problème.
Fedora est un peu particulier. Fedora est là pour "imposer" des nouvelles techno (dont 4kstack qui ne marche pas avec NVidia).
Pour l'"esprit" Fedora, relire :
http://fedora.redhat.com/about/(...)
Si tu me trouves une distribution grand public ou entreprise qui dans le manuel d'installation ou d'administration indique "il faut recompiler le noyau", tu me fais signe.
[^] # Re: ho sigh, windows...
Posté par 007 . En réponse à la dépêche Un fork de GNOME sur les rails ?. Évalué à -1.
20 cm environ.
Mais c'est bien, t'as raison.
Tu n'utilises pas Gnome et tu n'arrêtes pas de critiquer, tu passes tes nuits à analyser son historique, à analyser les influences de chaqu'un (mais surtout MDI), ces performances, l'évolution des rapports de bug, les engueulages entre développeurs, ceux qui quittent le projet, les erreurs de frappe, etc...
Maintenant t'arrives avec un cas particulier.
En 5 mots comme en 100 :
Tu me casses les couilles.