> Et la concurrence pure et parfaite que promeut le TCE ?
Non. C'est "concurrence libre et non-faussée".
> Elle s'accomode des aides aux entreprises en situation de concurrence ?
Non (sauf cas particulier, région défavorisée, etc).
Mais en quoi c'est un problème ?
Imagines, tu bosses dans la boîte toto.
La boîte titi est un des concurrents de la boîte toto. Elle est par exemple basée en Angleterre.
L'Angleterre finance la boîte titi et les produits de la boîte toto ne sont plus compétitifs. La boîte toto coule et tu es viré.
Tu trouves ça normal ?
Le problème est les charges sur les entreprises. Mais comme il y impopulaire d'augmenter la TVA ou les impôts sur le revenu....
Que veux-tu... Mandr(iva|ake) n'annonce pas la date de disponibilité en download. Donc ça peut-être entre 3 jours et 3 ans. Personne ne sait.
Eux même ne doivent pas le savoir. Il y aura la version download lorsque les ventes chuteront.
> C'est là que je les ai trouvés. Je suppose donc qu'ils sont au courant.
Si l'api n'est pas cassée, il y aura peut-être une mise à jours vers cette nouvelle version qui supporte le bi-écran. Mais Red Hat est très conservateur dans le cycle de vie d'une RHEL. Donc c'est peu probable (je tiens à te prévenir).
> À l'époque, tu étais obligé d'installer les 2 en même temps
Non. Tu installes l'un ou l'autre ou les deux en même temps.
Tu n'es pas obligé.
> avec la même version et même release exactement.
Ça dépend. Mais en pratique oui.
> Sous Mandrake Linux tu pouvais déjà faire vivre les 2 séparemment, indifféremment.
Idem.
> Lis par exemple les commentaires de Mike Harris dans ses packages. Ils sont en train de limiter les libs à uniquement des packages -libs pour limiter les conflits pour ce qui est en dehors de */lib ou */lib64.
C'est comme ça depuis longtemps. Ce n'est pas nouveau. Toi tu dis que c'est nouveau. C'est sur ce point que je ne suis pas d'accord.
> Non, lis bien le code de rpm. Il y a du code spécifique qui te permet de préférer un binaire marqué ELF64 quand tu installes 2 packages 32-bit et 64-bit en même temps. Autrement, ça conflicte.
Par défaut il installe ELF64. En quoi ça te dérange ? Tu veux que sur un système AMD64 par défaut il installes du i386 ?
Ça n'a pas de sens.
De plus j'aimerai que tu me trouves ce code rpm. Tu dois parler de yum ou up2date.
Avec yum ou up2date peut peut installer un paquet i386 sur un système amd64 avec :
yum install toto....i386
Avec rpm s'est tout bêtement :
rpm -i toto...i386.rpm
Si tu fais "rpm -i toto...i386.rpm toto...x86_64.rpm", il les installera s'il ne sont pas en comflit.
> Autrement, ça conflict
Ça dépend. Pour les lib, ça ne "conflict" pas.
> Lis bien, il voulait glib-config 32- et 64-bit, c'est donc glib-devel, pas glib. Et glib-devel conflicte.
Comme Mandriva. C'est toi même qui l'a dit :
- "sans conflit lors de l'installation (non simultanée) desdits packages."
Où veux tu en venir ?
> Essaie par exemple d'installer en même temps un glib-devel 32-bit et 64-bit sous FC4 ou RHEL.
Essais avec Mandriva :
[admin@one mandriva]$ ll
total 2732
drwxrwxr-x 3 admin admin 4096 avr 14 15:22 amd64
drwxrwxr-x 3 admin admin 4096 avr 14 15:21 i386
-rw-rw-r-- 1 admin admin 1418458 mar 10 20:32 lib64glib2.0_0-devel-2.6.3-1mdk.x86_64.rpm
-rw-rw-r-- 1 admin admin 1358933 fév 28 19:19 libglib2.0_0-devel-2.6.3-1mdk.i586.rpm
[admin@one mandriva]$ diff -r */usr/bin/
Les fichiers binaires amd64/usr/bin/glib-genmarshal et i386/usr/bin/glib-genmarshal sont différents.
Les fichiers binaires amd64/usr/bin/gobject-query et i386/usr/bin/gobject-query sont différents.
[admin@one mandriva]$ file */usr/bin/*
amd64/usr/bin/glib-genmarshal: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped
amd64/usr/bin/glib-mkenums: perl script text executable
amd64/usr/bin/gobject-query: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped
i386/usr/bin/glib-genmarshal: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped
i386/usr/bin/glib-mkenums: perl script text executable
i386/usr/bin/gobject-query: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped
Par quel miracle il est possible d'installer lib64glib2.0._0-devel avec libglib2.0_0-devel alors qu'il y a des fichiers en conflit ?
Faudrait peut-être arrêter de pipeauter.
> - parce que le club n'est pas non plus un truc sur invit' uniquement, et que donc ça peut intéresser des gens pas encore membre
Il me semble que tu ne m'as pas bien compris. J'ai demandé que la première news d'une distribution "majeure" soit en première page et les suivantes en seconde.
Donc, j'ai demandé le passage de cette news en première page et non de l'envoyer à la poubelle.
> Le problème ici c'est vraiment juste d'éviter de passer 3 fois de suite la même distrib en PP, c'est tout.
Ben dans ce cas, que la première news passe en première page (ce que je "conseille").
> j'ai de toute façon pas d'opinion hyper tranchée sur le choix de la version à passer en PP...
OK. Mais l'établissement quelques règles ne peut pas faire de mal pour ce cas précis et à répétition.
Si la seconde ou troisième news sur Mandriva LE 2005 passe en première page, ça sera un peu ridicule car il n'y aura rien de significativement nouveau. Or c'est ce qui va se passer uniquement pour avoir au moin une news en première page et donner l'impression de traiter équitablement les distributions majeurs.
Franchement avoir dans 3 mois l'annonce de la disponibilité en grauit de Mandrake LE 2005 fera "toutgratuit.com". Tu ne penses pas ?
> je me demande pourquoi c'est pas fait par defaut dans toutes les distribs
Parce que ça sucks. Alsa (j'ignore dans quelle version, la 1.0.7 ?) a corrigé les problèmes restant dans dmix.
Je pense que tout le monde va faire comme Mandriva puisque ça "just works". Fedora en a discuté. Je ne me rappèle pas qu'une décision ait été prise.
> La NPTL (Native POSIX Thread Library) remplace de plus en plus l'ancienne bibliothèque Linux-Threads
On peut même dire que linuxthread est très peu utilisé maintenant.
Pour FC4, les entêtes par défaut seront NTPL et GLIBC_2.0 sera marqué comme obsolète.
Sans oublié que la grande majorité des applis qui compilent avec les entêtes linuxthread tournent avec l'implémentation NTPL.
___________________________________________________
See %changelog:
- move LinuxThreads libraries to /%{_lib}/obsolete/linuxthreads/
and NPTL libraries to /%{_lib}. To run a program against LinuxThreads,
LD_ASSUME_KERNEL=2.4.xx LD_LIBRARY_PATH=/%{_lib}/obsolete/linuxthreads/
is now needed
The move was necessary because of the change to make NPTL the default
library programs are linked against and are using its headers.
glibc 2.0 compiled programs are implicitly using LD_ASSUME_KERNEL=2.2.5.
I'll probably change the hack to also add implicitly
/%{_lib}/obsolete/linuxthreads/ to library search path, but be aware that
when linuxthreads is finally dumped into the trash bin, which will happen
in ~ a year or less, glibc 2.0 programs will finally stop working.
BTW, it must have been early 1999, RHL 6.0 already shipped with glibc 2.1.x.
J'oubliais, ton url parle de RHEL 3 qui est sortie il y a 2 ans...
De plus, l'utilisateur reconnais son erreur "Download the right package and it installs fine.". Manifestement son système n'est pas maintenu à jour (argh).
Par contre RHEL ne permet pas de développer du i386 et AMD64 en même temps. C'est comme Mandriva.
Red Hat "mixe" 32 bits et 64 bits depuis RHEL 3 (basé sur RH9). De plus il y a eu une "technologie preview" (gingin64) basée sur RH9 bien avant la sortie de RHEL 3.
C'est Red Hat qui a ajouté le support multi-arch dans rpm et dans la libc. Red Hat maintient pratiquement à 100 % rpm et à 70 % la libc.
> Red Hat commence à peine à séparer davantage les libs au niveau package
Rien n'a changé sur ce point (du moins récemment) et tu fais des mélanges. rpm supporte d'avoir deux fois le même fichier dans deux paquets différents.
Donc lib...i386.rpm et lib...x86_64.rpm qui fournit tous les deux le même fichier peut-être installé en parallèle (c'est nécessaire pour les librairies qui dépendent de données dans /usr/share/... ou d'un fichier de config dans /etc/...). Sous Red Hat/Fedora, toutes les lib x86_64 sont installées dans ../lib64 .
> Sous Mandriva Linux c'était déjà possible depuis longtemps sans repackager les libs et grâce à une politique de libification des packages (à la Debian)
Tu mélanges avec la possibilité d'avoir des versions différentes de la même librairie sans "troubler" rpm.
Red Hat le fait quand c'est nécessaire mais ne le fait pas systématiquement.
> Red Hat commence à peine à séparer davantage les libs au niveau package (cf. packages de la forme -libs)
Ce qui est du pipeau car Red Hat fait ça pour les besoins de mixer i386/x86_64 depuis RHEL 3 (et avant évidemment ; phase beta et preview gingin64).
Pour Fedora il y a FC1 pour AMD64 qui est sorti depuis un bon moment : http://fr2.rpmfind.net/linux/fedora/core/1/x86_64/os/Fedora/RPMS/(...)
Plus de 60 paquets en i386.
Donc rien de nouveau.
> SuSE repackagent les libs 32-bit.
Red Hat ne fait pas ça. Le même paquet est fait pour i386 (--target=i386) et x86_64 (--target=x86_64). C'est tout. Il n'y a pas de paquet spécifique pour x86_64.
> La nouveauté de la 2005 étant la possibilité de mixer des packages de -devel pour développer à la fois des applications 32-bit et 64-bit, sans chroot, sans conflit lors de l'installation (non simultanée) desdits packages.
Avec le "non simultanée", c'est pareil pour Red Hat.
> Inutile de dire que c'est la meme chose pour une nouvelle version d'une distrib.
Tu n'as pas tord mais avec les distributions Linux c'est différent.
Considéront des distributions "entreprises".
Comme pour Unix, elles sont extrèment stables (ici stable != fiable, bien qu'elles le sont aussi).
L'équivalent d'un service pack chez MS c'est par exemple le passage de RHEL 3 à RHEL 4. Or cette montée en version n'est pas nécéssaire car RHEL 3 est supporté 7 ans. Une RHEL version 'n', ne change pas d'API (binaire et source) et il n'y a pas de "révolution" durant la vie.
Je pense que c'est plus le border de passer de RHEL 'n' à RHEL 'n+1' que d'ajouter un service pack à Windows. Mais avec RHEL, tu es moins obligé de faire cette montée en version.
Ainsi en entreprise les mises à jours de RHEL 'n' (ou une autre distribution "entreprise") pausent rarement des problèmes. Ça a le défaut de ses qualités : la distribution à une version 'n' n'évolue pas.
Qu'on soit bien d'accord, je ne critique pas MS ici. Je dis que les approches sont différentes.
> reproduit les mêmes bugs (cf autres messages ci-dessus)...
Et comme au dessus, je pense que ce n'est pas un bug Gamin (ou famd) mais un autre bug.
Arrêtons ce thread, il fait doublon. Désolé de l'avoir créé, je n'avais pas lu tous les commentaires avant de créer ce thread.
Je ne sais pas ce qu'il en est en upstream. Gamin est développé par Red Hat donc je ne pense pas qu'il y ait des différences entre la version Fedora et la version upstream.
Enfin, je me demande si on ne confond pas un bug Gamin ou HAL ou Nautilus ou kernel (qui ne remonte pas certains évènements).
Si un répertoire doit être suveillé, il doit être suveillé. C'est claire. C'est le boulot de gamin.
Si un répertoire ne doit plus être suveillé, c'est à d'autres programmes d'en informer Gamin.
> Il y a d'ailleurs un rapport de bug d'ouvert sur le sujet.
> Mais en fait ça sert à quoi d'avoir une version "stable" tous les 6 mois?
Réponse bête : à rien.
Tu as un raisonnement simplifié. Le but d'avoir des versions stables pour Mandriva ou Fedora, est d'avoir des périodes (de 3 à 4 mois) de développement intensif où les développeurs peuvent tout casser en profondeur pour faire évoluer les choses et avoir des périodes (de 2 à 3 mois) ou les développeurs ne font que du bugfix et travaillent avec les retours des utilisateurs/testeurs (durant la phase beta et pas après que la distribution soit sortie).
Debian se prive des périodes de développement intensif qu'ont Fedora ou Mandriva. D'où les lourdeur dans Debian pour passer de Linux 2.4 à Linux 2.6, etc alors que les autres distributions font ça d'un coup car elles ne cherchent pas à avoir une distribution qui supporte Linux 2.4 et 2.6 en même temps. Si tu fais le passage de Linux 2.4 à 2.6 (ou python 2.3 à 2.4) en douceur, tu dois durant une période transitoire supporter la vieille version et la nouvelle. Les autres distributions ne se font pas "chier" avec ça car les mises à jours se fond par bond et non en continu.
> Je pense que pas mal de gens n'ont pas compris le concept de la Debian!
SID est stable ?
Le concept de Debian est de proposer plusieurs branches et une seule est stable. C'est la branche "stable". Hors, et pour faire court, la branche "stable" est vielle comme l'enfer et beaucoup moins utilisable que les branches "stables" des autres distributions.
Si tu veux de "unstable", pratiquement toutes les distributions le propose.
Mandrake => Cooker.
Red Hat/Fedora => RawHide.
...
> La nécessité d'une distrib officielle regulière n'est plus de mise (je parle bien de distrib, pas de pub, la pub est importante), c'est du vieux marketing, laissons cela aux Fedoras.
Tu mélanges un peu tout. Fedora n'a pas besoin de faire de pub ou du vieu marketing. Fedora est gratuit, Red Hat ne gagne pas d'argent avec Fedora, Red Hat ne vend pas Fedora (ni abonnement, ni CD, ni support). Red Hat investit dans Fedora pour que le libre progrès et finalement pour que l'offre commerciale de Red Hat progresse.
C'est une démarche pragmatique pour faire évoluer le logiciel libre. Ça n'a rien à voir avec la pub ou le marketing.
Compares avec Debian, Fedora réussi dans ce domaine et Debian est à la traine.
> - RH : oui mais c'est pas supporté
> - moi : et comment je peux savoir si ce que j'ai installé depuis vos CD est supporté ou pas ?
Le problème de demande à Red Hat de tout supporter, est que déjà aucune distribution ne supporte tout et que ça pousse Red Hat a virer des fonctionnalités qui peuvent rendre service. Exemple : Red Hat n'a gardé que ext3 dans RHEL 4, car ils en avaient marre de tomber sur des grincheux qui avaient des problèmes avec autre_que_ext3 alors qu'ils ne supportent que ext3.
Enfin, le support est plus une aide utilisateur qu'un moyen pour obtenir des développements spécifiques.
Si OpenMotif ne supporte pas le bi-écran, ce n'est pas de la faute à Red Hat mais des développeurs d'OpenMotif.
> Du coup, j'ai cherché et trouvé les patches openmotif pour corriger mon problème, puis j'ai mis à jour le bugzilla avec ces fameux patches, qui n'ont toujours pas été intégrés depuis environ 1 an.
Java oui. gcj n'est pas un terrain miné.
Je t'invite à lire un article de lwn très intéressant : http://lwn.net/Articles/129914/(...) (rechercher gcj).
Comme dit lwn : "But like GNU is Not Unix, GCJ is not Java."
Même RMS dit qu'il n'y a pas de problème avec gcj.
N'oublions pas que gcj, qui fait parti de gcc, fait parti du projet GNU.
> et proche des besoins entreprise là où RedHat est clairement leader.
Et ?
Debian récupère plein plein plein de choses développées par Red Hat. C'est du logiciel libre.
> L'avantage de RedHat est de jouer le balancier sur les priorités entreprise là où debian joue le contre-balancier libre
Je trouve stupide cette opposition.
Debian ne fait-il pas une distribution aussi utilisable en entreprise ?
> Simplement le coût marginal d'ajouter une source dans debian est très mineur (donc très facilement rattrappable) là où pour RedHat comme Mandr*Linux ça a un coût non négligeable.
Je ne comprend rien.
> A chacun de faire ses choix : les uns le lapin, les autres la tortue mais il faut des deux pour donner la cadence par rapport à la réalité.
Vite c'est mieu que lentement. Je préfère avoir Linux 2.6 maintenant que dans 3 ans.
> un installeur graphique "user friendly" à la Mandrake/Suse/Fedora
Pour info, anaconda (l'installeur de Fedora) est graphique *et* texte. Suffit de passer le paramètre "text" lors de l'installation.
anaconda utilise Xorg pour le graphique. Comme Xorg tourne partout (ou presque) il n'y a pas de raison de ne pas avoir d'installeur graphique partout (ou presque).
> parceque j'imagine que les Clubers à qui s'adressent les sorties en exclu reçoivent de toute façon l'info par mail
C'est pertinent. Mais si on suit ton raisonnement, alors pourquoi avoir publié la news ? Uniquement pour faire de la pub à MandrakeClub ?
J'aimerai qu'on instaure un principe simple. Pour les sorties de distribution suscèptible de passer en première page, on ne passe que la première annonce en première page. Les autres annonces pour la même distribution doivent passer en seconde page.
Puis linuxfr.org ce n'est pas "toutgratuit.com".
Au fait, il y a aussi les précommandes : Limited Edition 2005 est en précommande sur Mandriva Store pour tous les autres utilisateurs sous forme de DVD (59 euros) : http://www.mandrivastore.com(...)
[^] # Re: mouais...
Posté par fabb . En réponse au journal Meeting militant pour le oui. Évalué à 3.
Non. C'est "concurrence libre et non-faussée".
> Elle s'accomode des aides aux entreprises en situation de concurrence ?
Non (sauf cas particulier, région défavorisée, etc).
Mais en quoi c'est un problème ?
Imagines, tu bosses dans la boîte toto.
La boîte titi est un des concurrents de la boîte toto. Elle est par exemple basée en Angleterre.
L'Angleterre finance la boîte titi et les produits de la boîte toto ne sont plus compétitifs. La boîte toto coule et tu es viré.
Tu trouves ça normal ?
Le problème est les charges sur les entreprises. Mais comme il y impopulaire d'augmenter la TVA ou les impôts sur le revenu....
[^] # Re: Première page
Posté par fabb . En réponse à la dépêche Sortie de Mandriva Limited Edition 2005. Évalué à -4.
Eux même ne doivent pas le savoir. Il y aura la version download lorsque les ventes chuteront.
[^] # Re: Un si joli troll....
Posté par fabb . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à -1.
https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Red+Hat+Ent(...)
[^] # Re: Un si joli troll....
Posté par fabb . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 1.
Tu ne demande pas la correction d'un bug mais tu demandes un "feature". OK ?
Ton applis tournait-elle en bi-écran avant ?
Non.
> et je dirais même qu'ils devraient le dire avant qu'on achète leur distrib.
Notes que tu n'as pas demandé un bugfix mais un ajout de fonctionnalité (support bi-écran qui n'existait pas au moment de la vente du produit). C'est différent.
Le support de bugfix est pris en compte :
https://rhn.redhat.com/errata/RHBA-2004-243.html(...)
https://rhn.redhat.com/errata/RHSA-2004-537.html(...)
> C'est là que je les ai trouvés. Je suppose donc qu'ils sont au courant.
Si l'api n'est pas cassée, il y aura peut-être une mise à jours vers cette nouvelle version qui supporte le bi-écran. Mais Red Hat est très conservateur dans le cycle de vie d'une RHEL. Donc c'est peu probable (je tiens à te prévenir).
[^] # Re: Et le plus important...
Posté par fabb . En réponse au journal Mandriva Linux Limited Edition 2005 released. Évalué à 1.
Non. Tu installes l'un ou l'autre ou les deux en même temps.
Tu n'es pas obligé.
> avec la même version et même release exactement.
Ça dépend. Mais en pratique oui.
> Sous Mandrake Linux tu pouvais déjà faire vivre les 2 séparemment, indifféremment.
Idem.
> Lis par exemple les commentaires de Mike Harris dans ses packages. Ils sont en train de limiter les libs à uniquement des packages -libs pour limiter les conflits pour ce qui est en dehors de */lib ou */lib64.
C'est comme ça depuis longtemps. Ce n'est pas nouveau. Toi tu dis que c'est nouveau. C'est sur ce point que je ne suis pas d'accord.
> Non, lis bien le code de rpm. Il y a du code spécifique qui te permet de préférer un binaire marqué ELF64 quand tu installes 2 packages 32-bit et 64-bit en même temps. Autrement, ça conflicte.
Par défaut il installe ELF64. En quoi ça te dérange ? Tu veux que sur un système AMD64 par défaut il installes du i386 ?
Ça n'a pas de sens.
De plus j'aimerai que tu me trouves ce code rpm. Tu dois parler de yum ou up2date.
Avec yum ou up2date peut peut installer un paquet i386 sur un système amd64 avec :
yum install toto....i386
Avec rpm s'est tout bêtement :
rpm -i toto...i386.rpm
Si tu fais "rpm -i toto...i386.rpm toto...x86_64.rpm", il les installera s'il ne sont pas en comflit.
> Autrement, ça conflict
Ça dépend. Pour les lib, ça ne "conflict" pas.
> Lis bien, il voulait glib-config 32- et 64-bit, c'est donc glib-devel, pas glib. Et glib-devel conflicte.
Comme Mandriva. C'est toi même qui l'a dit :
- "sans conflit lors de l'installation (non simultanée) desdits packages."
Où veux tu en venir ?
> Essaie par exemple d'installer en même temps un glib-devel 32-bit et 64-bit sous FC4 ou RHEL.
Essais avec Mandriva :
Par quel miracle il est possible d'installer lib64glib2.0._0-devel avec libglib2.0_0-devel alors qu'il y a des fichiers en conflit ?
Faudrait peut-être arrêter de pipeauter.
[^] # Re: Première page
Posté par fabb . En réponse à la dépêche Sortie de Mandriva Limited Edition 2005. Évalué à 0.
Il me semble que tu ne m'as pas bien compris. J'ai demandé que la première news d'une distribution "majeure" soit en première page et les suivantes en seconde.
Donc, j'ai demandé le passage de cette news en première page et non de l'envoyer à la poubelle.
Enfin, tu oublies encore que cette distribution n'est pas uniquement réservée aux clubers.
http://store.mandriva.com/product_info.php?products_id=217(...)
> Le problème ici c'est vraiment juste d'éviter de passer 3 fois de suite la même distrib en PP, c'est tout.
Ben dans ce cas, que la première news passe en première page (ce que je "conseille").
> j'ai de toute façon pas d'opinion hyper tranchée sur le choix de la version à passer en PP...
OK. Mais l'établissement quelques règles ne peut pas faire de mal pour ce cas précis et à répétition.
Si la seconde ou troisième news sur Mandriva LE 2005 passe en première page, ça sera un peu ridicule car il n'y aura rien de significativement nouveau. Or c'est ce qui va se passer uniquement pour avoir au moin une news en première page et donner l'impression de traiter équitablement les distributions majeurs.
Franchement avoir dans 3 mois l'annonce de la disponibilité en grauit de Mandrake LE 2005 fera "toutgratuit.com". Tu ne penses pas ?
[^] # Re: \o/
Posté par fabb . En réponse à la dépêche Sortie de Mandriva Limited Edition 2005. Évalué à 1.
Parce que ça sucks. Alsa (j'ignore dans quelle version, la 1.0.7 ?) a corrigé les problèmes restant dans dmix.
Je pense que tout le monde va faire comme Mandriva puisque ça "just works". Fedora en a discuté. Je ne me rappèle pas qu'une décision ait été prise.
# NPTL
Posté par fabb . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 5.
On peut même dire que linuxthread est très peu utilisé maintenant.
Pour FC4, les entêtes par défaut seront NTPL et GLIBC_2.0 sera marqué comme obsolète.
Sans oublié que la grande majorité des applis qui compilent avec les entêtes linuxthread tournent avec l'implémentation NTPL.
http://www.redhat.com/archives/fedora-devel-list/2005-April/msg0047(...)
[^] # Re: Première page
Posté par fabb . En réponse à la dépêche Sortie de Mandriva Limited Edition 2005. Évalué à 0.
Vous voulez quoi ?
Que les news ne soient jamais corrigées et qu'on laisse des conneries se propager ?
[^] # Re: Et le plus important...
Posté par fabb . En réponse au journal Mandriva Linux Limited Edition 2005 released. Évalué à 1.
De plus, l'utilisateur reconnais son erreur "Download the right package and it installs fine.". Manifestement son système n'est pas maintenu à jour (argh).
Par contre RHEL ne permet pas de développer du i386 et AMD64 en même temps. C'est comme Mandriva.
[^] # Re: Et le plus important...
Posté par fabb . En réponse au journal Mandriva Linux Limited Edition 2005 released. Évalué à 1.
Red Hat "mixe" 32 bits et 64 bits depuis RHEL 3 (basé sur RH9). De plus il y a eu une "technologie preview" (gingin64) basée sur RH9 bien avant la sortie de RHEL 3.
C'est Red Hat qui a ajouté le support multi-arch dans rpm et dans la libc. Red Hat maintient pratiquement à 100 % rpm et à 70 % la libc.
> Red Hat commence à peine à séparer davantage les libs au niveau package
Rien n'a changé sur ce point (du moins récemment) et tu fais des mélanges. rpm supporte d'avoir deux fois le même fichier dans deux paquets différents.
Donc lib...i386.rpm et lib...x86_64.rpm qui fournit tous les deux le même fichier peut-être installé en parallèle (c'est nécessaire pour les librairies qui dépendent de données dans /usr/share/... ou d'un fichier de config dans /etc/...). Sous Red Hat/Fedora, toutes les lib x86_64 sont installées dans ../lib64 .
> Sous Mandriva Linux c'était déjà possible depuis longtemps sans repackager les libs et grâce à une politique de libification des packages (à la Debian)
Tu mélanges avec la possibilité d'avoir des versions différentes de la même librairie sans "troubler" rpm.
Red Hat le fait quand c'est nécessaire mais ne le fait pas systématiquement.
> Red Hat commence à peine à séparer davantage les libs au niveau package (cf. packages de la forme -libs)
Ce qui est du pipeau car Red Hat fait ça pour les besoins de mixer i386/x86_64 depuis RHEL 3 (et avant évidemment ; phase beta et preview gingin64).
Pour Fedora il y a FC1 pour AMD64 qui est sorti depuis un bon moment :
http://fr2.rpmfind.net/linux/fedora/core/1/x86_64/os/Fedora/RPMS/(...)
Plus de 60 paquets en i386.
Donc rien de nouveau.
> SuSE repackagent les libs 32-bit.
Red Hat ne fait pas ça. Le même paquet est fait pour i386 (--target=i386) et x86_64 (--target=x86_64). C'est tout. Il n'y a pas de paquet spécifique pour x86_64.
> La nouveauté de la 2005 étant la possibilité de mixer des packages de -devel pour développer à la fois des applications 32-bit et 64-bit, sans chroot, sans conflit lors de l'installation (non simultanée) desdits packages.
Avec le "non simultanée", c'est pareil pour Red Hat.
> http://www.redhat.com/archives/amd64-list/2005-February/msg00008.ht(...)
C'était un bug (tu sais, le truc que tout le monde rencontre), il a été corrigé :
http://www.redhat.com/archives/amd64-list/2005-February/msg00004.ht(...)
> par exemple, qui n'a pas eu de réponse.
Voir l'url que j'ai donné.
[^] # Re: Puisque chacun passe son coup de gueule....
Posté par fabb . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 1.
Tu n'as pas tord mais avec les distributions Linux c'est différent.
Considéront des distributions "entreprises".
Comme pour Unix, elles sont extrèment stables (ici stable != fiable, bien qu'elles le sont aussi).
L'équivalent d'un service pack chez MS c'est par exemple le passage de RHEL 3 à RHEL 4. Or cette montée en version n'est pas nécéssaire car RHEL 3 est supporté 7 ans. Une RHEL version 'n', ne change pas d'API (binaire et source) et il n'y a pas de "révolution" durant la vie.
Je pense que c'est plus le border de passer de RHEL 'n' à RHEL 'n+1' que d'ajouter un service pack à Windows. Mais avec RHEL, tu es moins obligé de faire cette montée en version.
Ainsi en entreprise les mises à jours de RHEL 'n' (ou une autre distribution "entreprise") pausent rarement des problèmes. Ça a le défaut de ses qualités : la distribution à une version 'n' n'évolue pas.
Qu'on soit bien d'accord, je ne critique pas MS ici. Je dis que les approches sont différentes.
[^] # Re: Puisque chacun passe son coup de gueule....
Posté par fabb . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 1.
Et comme au dessus, je pense que ce n'est pas un bug Gamin (ou famd) mais un autre bug.
Arrêtons ce thread, il fait doublon. Désolé de l'avoir créé, je n'avais pas lu tous les commentaires avant de créer ce thread.
[^] # Re: Puisque chacun passe son coup de gueule....
Posté par fabb . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 1.
Enfin, je me demande si on ne confond pas un bug Gamin ou HAL ou Nautilus ou kernel (qui ne remonte pas certains évènements).
Si un répertoire doit être suveillé, il doit être suveillé. C'est claire. C'est le boulot de gamin.
Si un répertoire ne doit plus être suveillé, c'est à d'autres programmes d'en informer Gamin.
> Il y a d'ailleurs un rapport de bug d'ouvert sur le sujet.
Donnes le. STP.
[^] # Re: Pour une fondation Debian
Posté par fabb . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 2.
Réponse bête : à rien.
Tu as un raisonnement simplifié. Le but d'avoir des versions stables pour Mandriva ou Fedora, est d'avoir des périodes (de 3 à 4 mois) de développement intensif où les développeurs peuvent tout casser en profondeur pour faire évoluer les choses et avoir des périodes (de 2 à 3 mois) ou les développeurs ne font que du bugfix et travaillent avec les retours des utilisateurs/testeurs (durant la phase beta et pas après que la distribution soit sortie).
Debian se prive des périodes de développement intensif qu'ont Fedora ou Mandriva. D'où les lourdeur dans Debian pour passer de Linux 2.4 à Linux 2.6, etc alors que les autres distributions font ça d'un coup car elles ne cherchent pas à avoir une distribution qui supporte Linux 2.4 et 2.6 en même temps. Si tu fais le passage de Linux 2.4 à 2.6 (ou python 2.3 à 2.4) en douceur, tu dois durant une période transitoire supporter la vieille version et la nouvelle. Les autres distributions ne se font pas "chier" avec ça car les mises à jours se fond par bond et non en continu.
[^] # Re: Pour une fondation Debian
Posté par fabb . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 1.
La comparaison n'est pas très juste. Cooker donne Mandriva est équivalent à Rawhide donne Fedora.
[^] # Re: Félicitation
Posté par fabb . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 1.
SID est stable ?
Le concept de Debian est de proposer plusieurs branches et une seule est stable. C'est la branche "stable". Hors, et pour faire court, la branche "stable" est vielle comme l'enfer et beaucoup moins utilisable que les branches "stables" des autres distributions.
Si tu veux de "unstable", pratiquement toutes les distributions le propose.
Mandrake => Cooker.
Red Hat/Fedora => RawHide.
...
[^] # Re: Plutôt une aubaine, mais est-ce le bon débat ?
Posté par fabb . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 2.
Tu mélanges un peu tout. Fedora n'a pas besoin de faire de pub ou du vieu marketing. Fedora est gratuit, Red Hat ne gagne pas d'argent avec Fedora, Red Hat ne vend pas Fedora (ni abonnement, ni CD, ni support). Red Hat investit dans Fedora pour que le libre progrès et finalement pour que l'offre commerciale de Red Hat progresse.
C'est une démarche pragmatique pour faire évoluer le logiciel libre. Ça n'a rien à voir avec la pub ou le marketing.
Compares avec Debian, Fedora réussi dans ce domaine et Debian est à la traine.
[^] # Re: Un si joli troll....
Posté par fabb . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 1.
> - moi : et comment je peux savoir si ce que j'ai installé depuis vos CD est supporté ou pas ?
Le problème de demande à Red Hat de tout supporter, est que déjà aucune distribution ne supporte tout et que ça pousse Red Hat a virer des fonctionnalités qui peuvent rendre service. Exemple : Red Hat n'a gardé que ext3 dans RHEL 4, car ils en avaient marre de tomber sur des grincheux qui avaient des problèmes avec autre_que_ext3 alors qu'ils ne supportent que ext3.
Enfin, le support est plus une aide utilisateur qu'un moyen pour obtenir des développements spécifiques.
Si OpenMotif ne supporte pas le bi-écran, ce n'est pas de la faute à Red Hat mais des développeurs d'OpenMotif.
> Du coup, j'ai cherché et trouvé les patches openmotif pour corriger mon problème, puis j'ai mis à jour le bugzilla avec ces fameux patches, qui n'ont toujours pas été intégrés depuis environ 1 an.
Il faut les envoyer en upstream.
[^] # Re: N'importe quoi
Posté par fabb . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 2.
Oui et non. Ubuntu pourrait être basé sur Fedora par exemple.
[^] # Re: le process qualité de debian est un exemple du genre
Posté par fabb . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 1.
Java oui. gcj n'est pas un terrain miné.
Je t'invite à lire un article de lwn très intéressant :
http://lwn.net/Articles/129914/(...) (rechercher gcj).
Comme dit lwn : "But like GNU is Not Unix, GCJ is not Java."
Même RMS dit qu'il n'y a pas de problème avec gcj.
N'oublions pas que gcj, qui fait parti de gcc, fait parti du projet GNU.
> et proche des besoins entreprise là où RedHat est clairement leader.
Et ?
Debian récupère plein plein plein de choses développées par Red Hat. C'est du logiciel libre.
> L'avantage de RedHat est de jouer le balancier sur les priorités entreprise là où debian joue le contre-balancier libre
Je trouve stupide cette opposition.
Debian ne fait-il pas une distribution aussi utilisable en entreprise ?
> Simplement le coût marginal d'ajouter une source dans debian est très mineur (donc très facilement rattrappable) là où pour RedHat comme Mandr*Linux ça a un coût non négligeable.
Je ne comprend rien.
> A chacun de faire ses choix : les uns le lapin, les autres la tortue mais il faut des deux pour donner la cadence par rapport à la réalité.
Vite c'est mieu que lentement. Je préfère avoir Linux 2.6 maintenant que dans 3 ans.
[^] # Re: Puisque chacun passe son coup de gueule....
Posté par fabb . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 1.
[^] # Re: Puisque chacun passe son coup de gueule....
Posté par fabb . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 1.
Qui t'oblige ?
Elle est gratuite ta critique.
> Par contre ça fait très très longtemps qu'il y a des problèmes avec famd...
Et ça fait depuis longtemps que Gnome n'utilise plus famd...
[^] # Re: Un bon coup de pieds dans le cul !
Posté par fabb . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 2.
Pour info, anaconda (l'installeur de Fedora) est graphique *et* texte. Suffit de passer le paramètre "text" lors de l'installation.
anaconda utilise Xorg pour le graphique. Comme Xorg tourne partout (ou presque) il n'y a pas de raison de ne pas avoir d'installeur graphique partout (ou presque).
[^] # Re: Première page
Posté par fabb . En réponse à la dépêche Sortie de Mandriva Limited Edition 2005. Évalué à 1.
C'est pertinent. Mais si on suit ton raisonnement, alors pourquoi avoir publié la news ? Uniquement pour faire de la pub à MandrakeClub ?
J'aimerai qu'on instaure un principe simple. Pour les sorties de distribution suscèptible de passer en première page, on ne passe que la première annonce en première page. Les autres annonces pour la même distribution doivent passer en seconde page.
Puis linuxfr.org ce n'est pas "toutgratuit.com".
Au fait, il y a aussi les précommandes :
Limited Edition 2005 est en précommande sur Mandriva Store pour tous les autres utilisateurs sous forme de DVD (59 euros) : http://www.mandrivastore.com(...)