> Je regrette d'autant plus l'ancienne politique Suse " SAPUCEPALIBRE " qui a fait que les communautés Mandrake, Debian ou Redhat se sont bien plus développé...
Tu devrais ausi dire que cette campagne "SAPUCEPALIBRE" n'était pas apprécié d'une partie ne négligeable de non-utilisateur de SuSE.
J'utilise RedHat/Fedora et j'ai jamais participé à ce linchage et l'ai même combattu.
> Il n'y a que des RPM-istes pour croire qu'on peut prendre un paquet au pif et passer ça à coup de --no-deps et vas-y que ça rentre.
Il n'y a que des DEB-istes pour croire que les RPM-istes sont comme ça.
> Quand on utilise Debian on s'en fout : Tout est déjà dispo sous forme de paquets alors pourquoi aller voir ailleurs?
Pour avoir une bécane à jour stable avec suivit des trous de sécurté et pas un truc bancal fait de stable/testing/unstable/backport qui explose toutes les semaines, pour ne pas se tromper d'au moins d'un an quand on fait une prédiction sur la date de sortie de la prochaine version stable, pour avoir des outils de configuration centralisés et ne pas passer 3 plombes à chercher quel est le nom du paquet qu'il faut installer pour configurer ce @~?#@£! de machin, pour ne pas avoir à lire 300 pages de doc pour faire un truc simple, pour pas tester 50 programmes pourris pour trouver le bon mais avoir déjà un bon programme par défaut, pour ne pas répondre aux questions idiotes de debconf, pour installer une bécane avec la partition root en raid/lvm sans s'arracher les cheveux, pour avoir une distribution stable sur amd64, pour ne pas être obligé d'être abonné à une mailing d'aide avec 200 messages par jours sinon tu n'arrive pas à utiliser le bousin, pour ne pas fréquenter la communauté Debian qui pête plus haut que son cul, etc...
Il y a plein de bonnes raisons.
PS : pour la pertinence de la balise troll, c'est à chaqu'un d'en juger.
tout est dans /dev/md0. /dev/hdc1 /dev/hda1 c'est pour backup (/dev/hdc1 c'est j-2 et /dev/hda1 c'est j-1). C'est identique à /dev/md0 mais sans les gros trucs sans importances (videos (légales, des enregistrements tv), trucs que je peux downloader, etc). Si /dev/md0 s'"écroule", je peux continuer à bosser avec /dev/hdc1 ou /dev/hda1. /dev/hde1 est a usage temporaire, typiquement pour des tests.
> Excuse-moi, mais vu comment tu le disais: "ridicule et suranné", je t'ai trouvé assez généraliste.
J'ai fait une faute de communication :-)
ridicule :
- car dans 97 % des cas c'est inutiles et une source d'emmerdemment
suranné :
- c'est vieux et lié à des problèmes techniques. Limite du fs, limite en nombre de inode, limite des disques, pas de lvm, pas de quota, etc.
Ceci dit, je trouve très bien que l'arborescence Unix soit bien foutue et permette d'utiliser intelligement "plein de partitions" lorsque c'est utile.
> Ils doivent etre assis en face de ceux qui predisent depuis le debut de KDE que le projet va se planter:
C'est vrai.
> Oui et non. Il est possible de faire tourner les composants bonobo a l'interieur du meme processus, et dans ce cas, c'est bien un dlopen qui est utilise.
C'est vrai aussi :-)
> Le choix de corba dans bonobo rend la technologie plus complexe et limite par consequent son adoption.
J'ai jamais codé de bonobo. Mais là c'est un peu léger comme argument. J'image que lorsqu'on utilise bonobo on ne parle pas le "corba" en native. On utilise une interface qui doit cacher ces détails et simplifier la vie des développeurs d'appli.
C'est le role du noyau d'être au plus près du hardware pour être le plus rapide possible.
Ce qu'il faut c'est que les drivers, applis soient portables. C'est le cas.
Dans un noyau il y a toujours des parties qui sont spécifiques au hardware.
> Je pense au fait qu'aujourd'hui, sur certaine machines, le cache est trop gros pour avoir une complete couverture par la TLB (lire dans le document de mon second lien).
Au niveau hardware/cpu, je n'y connais pas grand chose :-)
Je crois que c'est ça. En guise d'excuse je t'ai plussé tes deux commentaires ici.
> c'est toi qui emploie le terme de discrimination, c'est abusif ici : les vendeurs font ce qu'ils veulent et sont libres de ne pas fournir de contrat de support pour des distributions anecdotiques ou inconnues
Certe. Et on ne peut blamer les vendeurs de la disparité dans GNU/Linux.
Comme l'indique un commentaire plus bas, il y a 12 (!) distributions qui clonent RHEL
et l'argument premier de ces distributions est d'être des clones. Cet aspect est nouveau.
> le nombre de clients qu'elles "piquent" véritablement à RHEL doit être infime
Actuellement ça doit être le cas. Plus particuliairement je ne pense pas que ça influence les finances de Red Hat actuellement car les clones ne doivent pas être beaucoup utilisé en entreprise (clients qui payent).
> plusieurs retours d'expérience m'ont indiqué que la simple perte de temps impliquée par le choix d'un clone de Red Hat par rapport à une "vraie" RHEL (recherches d'infos éparpillées, support, mises à jour) fait que l'opération n'est pas forcément aussi rentable qu'on le croit.
Tout à fait. Tu mets en lumière que le prix d'une RHEL n'est pas énorme.
> Dans nos conditions de travail, il est hors de question de ne pas partitionner /var /usr et /tmp - le /home est distant.
Je ne dis pas que ce n'est jamais intéressant mais j'ai vu *énormement* de personnes qui ont regretté avoir fait plein de partitions et qui se mordaient les doigts après coup. Si tu fréquentes des forums, tu ne pourra qu'être d'accord avec moi : http://ww.google.fr/search?hl=fr&q=partition+%2Fvar+%2Ftmp+full(...)
Les gens qui ont regretté de ne pas avoir plein de partitions partout sont très rares. Ce qui est le plus populaire c'est d'avoir un "/home" séparé. Perso, je préfère un backup.
Je ne suis pas convaincu que toutes les applis marchent après avoir changé PAGE_SIZE (qui est une macro définie dans /usr/include/asm/page.h).
> En gros, certaines applications fonctionnent mieux avec des pages plus grandes, d'autres fonctionnent mieux avec des pages plus petite.
Je dis pas non mais t'aurais un exemple concret ou un bench je te plusserais :-)
Puis c'est peut-être plus pertinent de faire ça côté libc si tu penses à l'optimisation de malloc/free. Un malloc n'aboutis pas systématique a un appel système "malloc" et beaucoup d'appels systèmes peuvent marcher sur une page mémoire (read, write, brk, etc).
Au feeling, je n'ai pas l'impression que ça peut apporter un gain important.
C'est nouveau chez Mandrake ou j'ai raté un épisode ?
Ça a l'air nouveau selon le changelog du .spec.
Il y a une "vrai" politique pour utiliser rsbac ou c'est seulement pour dire qu'ils l'ont. Car il y a aussi selinux mais il n'est pas utilisé (pas de règles).
Où tu vois ça ?
J'ai un doute. Tu peux donner l'extrait.
La licence utilisée est ici : http://opensource.adobe.com/licenses.html(...) (c'est la licence MIT)
A première vu (heureusement elle est courte), c'est compatible GPL et c'est positif.
Posté par fabb .
En réponse au journal Pango.
Évalué à -1.
> Si tu lui avais expliqué dès le début l'évolution des choses
"Dès le début", je ne connaissais pas l'évolution des choses. Simplement il est à mon sens évident qu'un élément aussi utilisé que vte ne peut pas rester non maintenu très longtemps. Au pire (ou au mieux) il y a rapidement un nouveau projet pour le remplacer.
Dans des projets gros comme Gnome il y a toujours des moments où une partie parait non maintenu ou n'est pas maintenu. Ce n'est pas un fait significatif qui permet de tirer des "conclusions". Ce sont des choses qui arrivent.
De mémoire, c'est déjà arrivé à gconf, bonobo et nautilus (après la "mort" de eazel).
> Ecoute, de manière générale je trouve que tu pourris les discussions avec ta façon agressive et condescendante de communiquer avec les autres membres de la communauté.
Toi aussi tu pourris le thread ici. Mais là c'est gentil :-)
A propos de condescendance j'ai rarement des avis péremptoires. Je ne dis pas "machin puxor ou est lent comme un vaux" ou "un tel roxe des ours" ou "Gnome est définitivement supérieur techniquement à KDE" ou "tel distribution atomise toutes les autres" ou "ext3 c'est has been il est temps de passer à un FS plus moderne" ou "Gnome à deux ans de retard sur KDE et ne pourra plus ratraper KDE" (cette dernière phrase ou équivalent c'est beaucoup vu ici).
Si j'étais vraiment condescendant je serai plus péremptoire.
[^] # Re: semi conclusion
Posté par fabb . En réponse au journal #kubuntu ou le coté le plus hideux de linux. Évalué à 1.
Si ça sucks ici, vas par là. Il n'y a pas que [k]ubuntu et Mandrake. T'as Fedora, SuSE, Xandros, etc.
[^] # Re: Ça me souale.
Posté par fabb . En réponse au journal Distros basées sur RHEL. Évalué à 2.
[^] # Re: en effet
Posté par fabb . En réponse au journal Kunbuntu en test !. Évalué à 2.
Tu devrais ausi dire que cette campagne "SAPUCEPALIBRE" n'était pas apprécié d'une partie ne négligeable de non-utilisateur de SuSE.
J'utilise RedHat/Fedora et j'ai jamais participé à ce linchage et l'ai même combattu.
[^] # Re: Ça me souale.
Posté par fabb . En réponse au journal Distros basées sur RHEL. Évalué à 1.
Tout est libre sauf le CD "extra" et comme dit plus haut, pour installer du proprio avec RHEL il faut le demander explicitement.
Tiens, la beta2 de RHEL 4 :
http://ftp.redhat.com/pub/redhat/linux/beta/nahant-beta2/(...)
Il y a iso, binaire et tout sauf le proprio qui est un "extra". Je répète, le proprio est dans une iso "annexe".
# Re: Kunbuntu en test !
Posté par fabb . En réponse au journal Kunbuntu en test !. Évalué à 2.
C'est Kubuntu (Qbuntu ?) et Ubuntu.
[^] # Re: Debian a le vent en poupe...
Posté par fabb . En réponse à la dépêche Une nouvelle version de la MEPIS : SimplyMEPIS 3.3. Évalué à 2.
Il n'y a que des DEB-istes pour croire que les RPM-istes sont comme ça.
> Quand on utilise Debian on s'en fout : Tout est déjà dispo sous forme de paquets alors pourquoi aller voir ailleurs?
Pour avoir une bécane à jour stable avec suivit des trous de sécurté et pas un truc bancal fait de stable/testing/unstable/backport qui explose toutes les semaines, pour ne pas se tromper d'au moins d'un an quand on fait une prédiction sur la date de sortie de la prochaine version stable, pour avoir des outils de configuration centralisés et ne pas passer 3 plombes à chercher quel est le nom du paquet qu'il faut installer pour configurer ce @~?#@£! de machin, pour ne pas avoir à lire 300 pages de doc pour faire un truc simple, pour pas tester 50 programmes pourris pour trouver le bon mais avoir déjà un bon programme par défaut, pour ne pas répondre aux questions idiotes de debconf, pour installer une bécane avec la partition root en raid/lvm sans s'arracher les cheveux, pour avoir une distribution stable sur amd64, pour ne pas être obligé d'être abonné à une mailing d'aide avec 200 messages par jours sinon tu n'arrive pas à utiliser le bousin, pour ne pas fréquenter la communauté Debian qui pête plus haut que son cul, etc...
Il y a plein de bonnes raisons.
PS : pour la pertinence de la balise troll, c'est à chaqu'un d'en juger.
[^] # Re: 2.6.12
Posté par fabb . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 1.
[^] # Re: 2.6.12
Posté par fabb . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 2.
la partie vfs tourne en kernel space, le reste en user space.
> le hurd propose quelque chose de mieux ;)
c-à-d ?
la partie vfs est en user space ?
[^] # Re: gconf (était:Re: Bonobo?)
Posté par fabb . En réponse à la dépêche GNOME 2.10 RC2. Évalué à 1.
/dev/md0 120269524 47962012 66288864 42% /
/dev/hdc1 19467148 13004872 6462276 67% /mnt/big_a1
/dev/hda1 19467148 13005104 6462044 67% /mnt/big_b1
/dev/hde1 18658996 7932568 10726428 43% /mnt/small1
$ cat /proc/mdstat
Personalities : [raid0]
md0 : active raid0 hdc2[0] hda2[1]
120372992 blocks 128k chunks
tout est dans /dev/md0. /dev/hdc1 /dev/hda1 c'est pour backup (/dev/hdc1 c'est j-2 et /dev/hda1 c'est j-1). C'est identique à /dev/md0 mais sans les gros trucs sans importances (videos (légales, des enregistrements tv), trucs que je peux downloader, etc). Si /dev/md0 s'"écroule", je peux continuer à bosser avec /dev/hdc1 ou /dev/hda1. /dev/hde1 est a usage temporaire, typiquement pour des tests.
[^] # Re: Ça me souale.
Posté par fabb . En réponse au journal Distros basées sur RHEL. Évalué à 2.
Toujours la même obsession de vouloir faire croire que le libre ne coûte rien...
> RedHat n'en a rien à foutre qu'on les repompes
Explique pourquoi ils ne mettent pas tous les binaires à disposition alors.
> ...sauf un énergumène comme toi.
Petit con.[1]
[1] tu l'as cherché.
[^] # Re: KDE 3.4
Posté par fabb . En réponse à la dépêche KDE 3.4 RC1. Évalué à 1.
Star supporte acl.
Dar ( http://dar.linux.free.fr/(...) ) support les acl et les attributs étendus.
[^] # Re: gconf (était:Re: Bonobo?)
Posté par fabb . En réponse à la dépêche GNOME 2.10 RC2. Évalué à 1.
J'ai fait une faute de communication :-)
ridicule :
- car dans 97 % des cas c'est inutiles et une source d'emmerdemment
suranné :
- c'est vieux et lié à des problèmes techniques. Limite du fs, limite en nombre de inode, limite des disques, pas de lvm, pas de quota, etc.
Ceci dit, je trouve très bien que l'arborescence Unix soit bien foutue et permette d'utiliser intelligement "plein de partitions" lorsque c'est utile.
[^] # Re: Bonobo?
Posté par fabb . En réponse à la dépêche GNOME 2.10 RC2. Évalué à 1.
C'est vrai.
> Oui et non. Il est possible de faire tourner les composants bonobo a l'interieur du meme processus, et dans ce cas, c'est bien un dlopen qui est utilise.
C'est vrai aussi :-)
> Le choix de corba dans bonobo rend la technologie plus complexe et limite par consequent son adoption.
J'ai jamais codé de bonobo. Mais là c'est un peu léger comme argument. J'image que lorsqu'on utilise bonobo on ne parle pas le "corba" en native. On utilise une interface qui doit cacher ces détails et simplifier la vie des développeurs d'appli.
[^] # Re: Il manque
Posté par fabb . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 1.
C'est le role du noyau d'être au plus près du hardware pour être le plus rapide possible.
Ce qu'il faut c'est que les drivers, applis soient portables. C'est le cas.
Dans un noyau il y a toujours des parties qui sont spécifiques au hardware.
[^] # Re: Il manque
Posté par fabb . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 1.
Au niveau hardware/cpu, je n'y connais pas grand chose :-)
Merci pour tes précisions.
[^] # Re: Ça me souale.
Posté par fabb . En réponse au journal Distros basées sur RHEL. Évalué à 2.
Je crois que c'est ça. En guise d'excuse je t'ai plussé tes deux commentaires ici.
> c'est toi qui emploie le terme de discrimination, c'est abusif ici : les vendeurs font ce qu'ils veulent et sont libres de ne pas fournir de contrat de support pour des distributions anecdotiques ou inconnues
Certe. Et on ne peut blamer les vendeurs de la disparité dans GNU/Linux.
> mais ce phénomène date d'avant les RHEL.
On peut le dire. Mais avec RHEL ça décolle. On a maintenant des news rien que pour ça :
http://linux.slashdot.org/linux/05/03/02/1739228.shtml?tid=190&(...)
http://lwn.net/Articles/125202/(...)
Comme l'indique un commentaire plus bas, il y a 12 (!) distributions qui clonent RHEL
et l'argument premier de ces distributions est d'être des clones. Cet aspect est nouveau.
> le nombre de clients qu'elles "piquent" véritablement à RHEL doit être infime
Actuellement ça doit être le cas. Plus particuliairement je ne pense pas que ça influence les finances de Red Hat actuellement car les clones ne doivent pas être beaucoup utilisé en entreprise (clients qui payent).
> plusieurs retours d'expérience m'ont indiqué que la simple perte de temps impliquée par le choix d'un clone de Red Hat par rapport à une "vraie" RHEL (recherches d'infos éparpillées, support, mises à jour) fait que l'opération n'est pas forcément aussi rentable qu'on le croit.
Tout à fait. Tu mets en lumière que le prix d'une RHEL n'est pas énorme.
[^] # Re: gconf (était:Re: Bonobo?)
Posté par fabb . En réponse à la dépêche GNOME 2.10 RC2. Évalué à 1.
Je ne dis pas que ce n'est jamais intéressant mais j'ai vu *énormement* de personnes qui ont regretté avoir fait plein de partitions et qui se mordaient les doigts après coup. Si tu fréquentes des forums, tu ne pourra qu'être d'accord avec moi :
http://ww.google.fr/search?hl=fr&q=partition+%2Fvar+%2Ftmp+full(...)
Les gens qui ont regretté de ne pas avoir plein de partitions partout sont très rares. Ce qui est le plus populaire c'est d'avoir un "/home" séparé. Perso, je préfère un backup.
[^] # Re: Ça me souale.
Posté par fabb . En réponse au journal Distros basées sur RHEL. Évalué à 0.
Compares rpm à dpkg et pas à apt.
[^] # Re: Ça me souale.
Posté par fabb . En réponse au journal Distros basées sur RHEL. Évalué à 1.
yum est plus lent sinon c'est grosso-modo la même chose.
[^] # Re: Il manque
Posté par fabb . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 2.
Je ne suis pas convaincu que toutes les applis marchent après avoir changé PAGE_SIZE (qui est une macro définie dans /usr/include/asm/page.h).
> En gros, certaines applications fonctionnent mieux avec des pages plus grandes, d'autres fonctionnent mieux avec des pages plus petite.
Je dis pas non mais t'aurais un exemple concret ou un bench je te plusserais :-)
Puis c'est peut-être plus pertinent de faire ça côté libc si tu penses à l'optimisation de malloc/free. Un malloc n'aboutis pas systématique a un appel système "malloc" et beaucoup d'appels systèmes peuvent marcher sur une page mémoire (read, write, brk, etc).
Au feeling, je n'ai pas l'impression que ça peut apporter un gain important.
# -fvisibility=hidden
Posté par fabb . En réponse au journal Mandrakelinux 10.2 Beta 1 pour x86-64. Évalué à 1.
J'ai vérifié, Mandrake a patché gcc-3.4.3.
Un truc que j'ignorais complètement, le noyau de Mandrake intègre rsbac :
http://www.rsbac.org/(...)
C'est nouveau chez Mandrake ou j'ai raté un épisode ?
Ça a l'air nouveau selon le changelog du .spec.
Il y a une "vrai" politique pour utiliser rsbac ou c'est seulement pour dire qu'ils l'ont. Car il y a aussi selinux mais il n'est pas utilisé (pas de règles).
[^] # Re: Il manque
Posté par fabb . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 0.
Les autres cpu 64bit suivront.
> Je serais beaucoup plus heureux lorsque cela integrera le support de taille de page variable.
???
à chaud ou via une recompilation du noyau ?
Pourquoi faire ?
[^] # Re: Compatibilité de la licence
Posté par fabb . En réponse à la dépêche Adobe se lance dans l'Open Source !. Évalué à 4.
Laisse tomber, j'ai trouvé :
- "the revised BSD license and the MIT license are GPL-compatible"
Bizarre, c'est dans le texte pour la "Academic Free License, version 1.1".
[^] # Re: Compatibilité de la licence
Posté par fabb . En réponse à la dépêche Adobe se lance dans l'Open Source !. Évalué à 0.
J'ai un doute. Tu peux donner l'extrait.
La licence utilisée est ici :
http://opensource.adobe.com/licenses.html(...) (c'est la licence MIT)
A première vu (heureusement elle est courte), c'est compatible GPL et c'est positif.
[^] # Re: pango
Posté par fabb . En réponse au journal Pango. Évalué à -1.
"Dès le début", je ne connaissais pas l'évolution des choses. Simplement il est à mon sens évident qu'un élément aussi utilisé que vte ne peut pas rester non maintenu très longtemps. Au pire (ou au mieux) il y a rapidement un nouveau projet pour le remplacer.
Dans des projets gros comme Gnome il y a toujours des moments où une partie parait non maintenu ou n'est pas maintenu. Ce n'est pas un fait significatif qui permet de tirer des "conclusions". Ce sont des choses qui arrivent.
De mémoire, c'est déjà arrivé à gconf, bonobo et nautilus (après la "mort" de eazel).
> Ecoute, de manière générale je trouve que tu pourris les discussions avec ta façon agressive et condescendante de communiquer avec les autres membres de la communauté.
Toi aussi tu pourris le thread ici. Mais là c'est gentil :-)
A propos de condescendance j'ai rarement des avis péremptoires. Je ne dis pas "machin puxor ou est lent comme un vaux" ou "un tel roxe des ours" ou "Gnome est définitivement supérieur techniquement à KDE" ou "tel distribution atomise toutes les autres" ou "ext3 c'est has been il est temps de passer à un FS plus moderne" ou "Gnome à deux ans de retard sur KDE et ne pourra plus ratraper KDE" (cette dernière phrase ou équivalent c'est beaucoup vu ici).
Si j'étais vraiment condescendant je serai plus péremptoire.
Mais effectivement il m'arrive d'être agressif.