> Tout cela pour dire que avant de faire migrer quelqu'un, renseigner vous ...
Je ne fais JAMAIS migrer quelqu'un. Je peux l'aider si c'est SON choix.
Je trouve détestable (je pèse mes mots) les "libristes" qui imposent leur vision. On ne compte pas les "j'ai migré machin vers KDE ou autre".
Ce n'est pas comme ça que le libre va se faire une place. C'est par son excellence. Firefox est excellent, inutile de forcer les gens à l'utiliser (ce qui n'apporterait rien à moyen/long terme).
OOo n'est pas encore excellent. Il progresse joliment, mais ne peut encore remplacer MS-Office dans certains cas. Pour mon travail, j'utilise souvant MS-Office. Pour les trucs persos, je n'utilise que OOo. Je fais attention de ne jamais diffuser du .doc only.
> au bout de 2 ans de boulot sur OoO, je vais avoir du mal à lui dire que c'était peut être une mauvaise idée ...
Fais lui un joli cadeau. Au moins pour te faire pardonner :-)
> Déjà, j'avoue, je connais bien moins Fedora que CentOS ou RHEL.
C'est la même chose techniquement. RHEL 5 est une FC6 avec quelques bricoles de plus. Faut être un expert pointu pour voir la différence. C'est le support qui change entre Fedora et RHEL. Techniquement c'est la même chose. RHEL est toujours basé sur Fedora.
> Mais pour comparaison, voici ce que l'on peut mettre dans le rc.conf concernant apache
Dans l'idée c'est la même chose. Donc ne voit pas pourquoi tu critiques le principe de Fedora et pas celui de FreeBSD. C'est le chemin /etc/sysconfig qui te pose problème ?
> Le gros intéret de rc.conf est qu'il permet d'avoir une vision synthétique de toute la configuration
Ça c'est les goûts et les couleurs. Certains développeurs veulent tout dans le même répertoire et d'autres veulent une arborescence.
> Tu as déjà regardé comment sont organisés les rc.* sur un BSD ?
Non, et je n'ai jamais dit que rc.* sur BSD était naze.
Mais ta critique de /etc/sysconfig de Fedora est gratuite et ça m'énerve.
> (tip: C'est à l'image du reste lorsque l'on compare Linux vs. BSD)
Faisons dans le troll. C'est limité et d'une autre époque ?
> Entre autre, les problèmes sur certains montage nfs (montages ro qui est en fait rw),
Puisque tu le dis.
> client nfs qui ne remonte pas forcement suite à un problème sur sa connexion avec le serveur,
Puisque tu le dis.
> nscd qui se gaufre sous forte charge,
Puisque tu le dis.
> nfs4 qui ne tient pas non plus avec en message d'erreur des problèmes VFS non traités qui n'auraient pas du remonter en userland (ces 2 derniers datent de nos tests d'il y a un an, on est revenu en arrière depuis),
Puisque tu le dis.
En passant, tu as fait ses tests sur quoi ?
Parce que NFS ça existe depuis longtemps et c'est très utilisé.
C'est bien gentil de mettre une liste de bug/limitation/manquement/etc.
Si on veut faire la liste de FreeBSD ça serait pire.
> /bin/sh qui est en fait un bash, avec toutes les gnuteries associées pour le shell root...
C'est connu, BSD est parfait est GNU ça pue, c'est le mal et ça veut la mort de BSD. Mais le monde est injuste, BSD c'est qu'une niche (même dans les serveurs).
> Oui enfin, entre maintenir un fichier rc.conf sous FreeBSD et l'arborescence /etc/sysconfig sur une RHEL ou une Fedora, le plus compliqué n'est pas le premier, loin de là.
Tu connais hypra mal Fedora.
Ce qui concerne apache dans Fedora :
/etc/systemconfig/httpd
# Configuration file for the httpd service.
#
# The default processing model (MPM) is the process-based
# 'prefork' model. A thread-based model, 'worker', is also
# available, but does not work with some modules (such as PHP).
# The service must be stopped before changing this variable.
#
#HTTPD=/usr/sbin/httpd.worker
#
# To pass additional options (for instance, -D definitions) to the
# httpd binary at startup, set OPTIONS here.
#
#OPTIONS=
#
# By default, the httpd process is started in the C locale; to
# change the locale in which the server runs, the HTTPD_LANG
# variable can be set.
#
#HTTPD_LANG=C
Tout est dans ce registre. Il n'y a dans /etc/sysconfig que des options que tu ne peux pas changer avec /etc/httpd/conf*.
Mais au-lieu de faire un truc de porc en bidouillant les /etc/rc.*, tu fais la configuration en un lieu précis dans un cadre qui l'a prévu (plus ou moins car prévoir tout les cas est impossible).
[root@one ~]# du -s /etc
111596 /etc
[root@one ~]# du -s /etc/sysconfig/
864 /etc/sysconfig/
/etc/sysconfig est moins d'1 % de la configuration du système.
> Ayant plusieurs dizaines de serveurs à maintenir, j'aurai tendance à dire que statistiquemen les linux nous posent plus de problèmes que les BSD... et pas qu'un peu.
C'est f8 en passant.
Et f8 c'est faire une installation via réseau (je l'ai fait).
Fedora fait ça depuis le FC1 !
Mieux, tu peux aussi faire une installation réseau via vnc.
Il y en a qui installe Fedora, graphiquement, sur dédibox.
Tu peux le faire avec Debian ?
> Et sait pas installer une fc8 avec juste le premier cd de tête en plus /o\
Admettons.
Tu peux installer via bootp (noyau et initrd récupéré sur le réseau).
Je veux bien admettre que ça manque de polish.
Mais ça marche puis des années ! Depuis RH 6.2 au moins (j'ai fait des netinstall avec RH 6.2).
> Il me demande aussi si je veux mettre à jour quand je fais une install "standard"
Tu peux faire l'installation et la mise à jour en même temps sous Fedora. Dans ce cas Fedora ne va pas installer toto v1 (de la release) puis mettre à jour vers toto v2 (des mises à jours). Il installe directement toto v2.
Je peux d'affirmer de façon définitive que ça le fait car je le fais et les dépôts utilisés sont sur une de mes bécanes (donc j'ai le log apache pour confirmer).
Il suffit à l'installation d'ajout un dépôt avec les mises à jours.
Alors pas d'accord pour dire que Fedora ne fait pas de netinstall. Fedora (et Red Hat) le fait depuis des lustres. Par contre, je suis tout à fait d'accord pour dire que ça manque de polish et qu'il faut lire un peu de doc (donc ce n'est pas accessible pour un newbi qui ne veut pas se prendre la tête).
> Sans vouloir te vexer, si un rpm Mandriva ne s'installe pas sous Fedora c'est que la réalité est un peu plus complexe que ta vision des choses.
Je ne vois où tu veux en venir a part conclure que le gestionnaire de paquet n'es tpas le coeur d'une distribution.
> Avec ton niveau d'argumentaire vache == cheval
Tu changes bien le coeur des OS seulement avec un gestionnaire de paquet.
Une vache à quatre pattes, comme un cheval.
Ça bouffe comme un cheval, ça a un regard attendrissant, et désolé, ça peut aussi se manger. Bref, plein de point en commun. Et au niveau ADN on doit avoir dans les 95 % d'ADN commun.
Mais tu veux faire de l'oreille de la vache son coeur (dans le sens "centre", "essence" et pas organe). Partant de la et constatant que l'oreille de la vache est différente de l'oreille du cheval, tu conclus qu'une vache et un cheval ça n'a rien à voir. Les anes et les chevaux n'ont pas les même oreilles.
Je te laisse à ton fétichime du gestionnaire de paquet.
> On peut se demander pourquoi Debian ne s'inspire pas de l'exemple d'Ubuntu pour proposer aux newbies les mêmes facilités de configuration.
Et pourquoi Debian ne s'inspirerait pas de Mandriva ou Fedora ?
Et pourquoi Debian ne réfléchirait pas de lui-même ?
C'est dingue cette manie d'associer systématiquement linux-simple à Ubuntu.
Avant Ubuntu il y avait MEPIS, Linspire, Xandros, etc.
De plus, toutes les distributions "modernes" et généralistes sont simples. C'est trivial d'installer une RHEL/CentOS, ou Mandriva ou OpenSuSE, etc...
Installe une Red Hat 8.0 ou 9 (sorti bien avant Ubuntu), c'est simple. Pour info, l'installation est graphique sous Red Hat depuis RH 6.0 !
Des années avant Ubuntu.
Installe une F8, c'est trivial (même pas de question sur X11 ou la carte son (s'il n'y en a qu'une)).
Ubuntu a peut-être un peu plus le soucis de la simplicité. Mais ce n'est pas ici que se joue son succès par rapport aux autres. C'est dans son compromis (pour ne pas dire compromission) avec le logiciel proprio. C'est aussi car Ubuntu a capté un publique que pouvait enfin attirer GNU/Linux. Ce n'est pas Ubuntu qui a amené GNU/Linux a ce niveau. Mais Ubuntu, et donnont lui crédit, a su en profiter au bon moment, avec de la bonne communication, avec une bonne infrastruture (wiki), avec une bonne compréhension de ce nouveau publique.
Je suis admiratif de voir comme Ubuntu a su intelligemment et opportunément bien gérer tout ça. Mais Ubuntu n'a pas inventé l'eau chaude. Faut arrêter le délire.
Donnez des technologies ou réflexions qu'a apporté Ubuntu. Bonne chance.
J'entend bien que l'utilisateur Ubuntu classique en a rien à foutre de la technologie et je n'irais pas lui reprocher d'avoir choisi Ubuntu au-lieu de Mandriva ou autre.
Mais aujourd'hui on frize le délire Windowsien de la "belle époque" ou Microsoft avait inventé Internet seulement car les gens connaissaient Internet que via Windows.
La simplicité n'est pas l'exclusivité d'Ubuntu. Loins loins de là.
Juste un petit exemple en fouillant rapidement le web : http://ometer.com/free-software-ui.html (avril 2002 !)
Un papier d'Havoc qui a fait beaucoup polémique à l'époque. Mais un papier visionnaire. Owen Taylor a aussi eu d'excellentes réflexions.
Et ne parlons même de Gnome 2.0 qui a fait couler d'encre :
- réduction des options
- obligation de respecter un HIG (Human Interface Guidelines)
- important travail de Sun sur l'ergonomie
- etc.
En fouillant les archives dlfp, on devrait encore trouver des débats très animés.
Même après huit pages, cet article ne concerne que la pointe de l'iceberg que renferme la distribution Xandros 3.0. En somme, vous en finirez avec les spams, des fenêtres publicitaires imposantes et gênantes, des redémarrages coûteux en temps... Avec Xandros, finis les longues recherches trop souvent frustrantes lorsqu'il s'agit de trouver un logiciel pour Linux... Finis de passer des nuits entières à faire fonctionner un nouveau périphérique!
Bref, finis les cauchemars du débutant sous Linux!
> Il est indéniable qu'Ubuntu attire des milliers d'utilisateurs de Windows.
Ceci est de la connerie.
Les gens ne sont pas attirés par Ubuntu, mais par GNU/Linux, par un système solide et bien conçu, etc.
Ubuntu ce n'est que le packaging et deux ou trois bricoles de plus.
Ubuntu serait sorti à l'époque de Linux 2.0 ou 2.2, sans usb, sans AIGLX, sans udev/hal, etc ça attirerait beaucoup moins de personne.
En passant, Ubuntu est massivement basé sur Debian.
> Peut-être un objectif que les autres distributions ne s'étaient pas fixé.
Qui a fait le système usb de Linux qui roxe ?
C'est Ubuntu ? Non.
Qui a fait udev/hal/gnome-volume-manager/etc ?
C'est Ubuntu ? non.
Qui a fait AIGLX/compiz/etc ?
C'est Ubuntu ? non.
Qui a fait Gnome 2 avec toute la réflexion sur le "just works" ?
C'est Ubuntu ? non.
etc.
> En tout cas, un objectif que les autres distributions n'ont pas atteint.
Un objectif que n'a pas atteind Ubuntu. Ce n'est pas avec 0,5 % d'utilisateur qu'on peut pavoiser.
> Une fois habitués au monde GNU/Linux grâce à Ubuntu, ces utilisateurs n'auront pas un gros effort d'adaptation à faire pour essayer un autre bureau, une autre distro.
Et vice versa.
Il ne faut pas prendre les gens pour con ici et notamment à propos de Linux.
Une Mandriva ou une OpenSuse ou un Fedora, etc sont aussi simple qu'Ubuntu.
> Alors où est le vrai problème derrière ça ? Une bande d'irréductibles barbus associaux
Ton attitude est particulièrement associal et surtout méprisante pour tout ceux qui ont participé à faire de GNU/Linux ce qu'il est aujourd'hui. Dans ce travail IMMENSE, Ubuntu n'est qu'une goute d'eau.
> abandonnez Linux pour Hurd.
Beaucoup des personnes que tu "insultes", on fait udev/hal, AIGLX, apt, Gnome, KDE, etc.
Fais un truc : prends la premier Ubuntu et une Mandriva ou Fedora ou OpenSuse de la même époque. Tu verras que Ubuntu a tout pompé (ce qui est normal, tout le monde le fait dans le libre).
Et aujourd'hui, qu'a de si formidable Ubuntu ?
Un bon packaging et deux ou trois bricole. Ce n'est qu'une distribution parmis d'autres. Aujourd'hui elle est "hype" mais ça pourrait ne pas durer.
D'autres distribution ont été "hype".
anaconda is the only thing keeping kudzu around, for the most part. Everything that it uses it for can be handled by the 'normal' mechanisms that the OS uses for probing, module loading, and device discovery these days.
Bref, pour Fedora il n'y a plus à avoir de kudzu ou autre.
La présence de kudzu est aujourd'hui un bug (qui doit être corrigé).
> Il a quand même besoin de détecter du matériel pour proposer de le configurer
Faudrait s'entendre sur le vocabulaire.
Kudzu ne détecte pas le matériel, il le liste. Le matériel a déjà été détecté via les mécanisme classique (et upstream) de Linux.
Si je fais "ls /tmp", je ne détecte pas le contenu de "/tmp", je le liste.
> Il a quand même besoin de détecter du matériel pour proposer de le configurer
Configurer comme on configure X11, comme on configure la fréquence d'un carte tv ou radio, etc.... On n'est plus dans la configuration bas niveau, mais dans l'utilisation du hardware déjà détecté et configuré (pour le bas niveau (irq, ioport, paramètre des modules (puisqu'ils sont déjà chargé), etc)).
> et c'est ce qu'il fait avec pas mal de workarounds :-)
D'accord, mais c'est erreur. Le matériel (et pas le logiciel type X11, etc) doit être configuré sans kudzu. Je te paris qu'il le sera à moyen terme (F9 voire F10).
> Dans Mandriva, la reconfiguration de matériel est faite avec le service harddrake, écrit en Perl et se basant sur ldetect, c'est difficile d'envisager une fusion des 2 deux outils ...
Si Fedora peut virer kudzu, vous pouvez virer ldetect. Peut-être que ldetect ou kudzu resteront mais sous une autre forme. Par exemple uniquement pour voir s'il y a un ajout de matériel entre deux boot (typiquement l'ajout d'une carte PCI) et prendre les actions nécessaires. Si la carte graphique a été changée, il est clair qu'il ne faut pas lancer X11 sans le reconfigurer. Quoique Fedora utilise massivement l'autoconfiguration de X11 et peut-être qu'un jour par défaut il n'y aura plus de /etc/X11/xorg.conf. Et en réalité, c'est déjà fait pour linuxstateless.
> Et chaque distribution a ses besoins particuliers
Besoins ou caractéristiques ou exigences ou cibles ?
Les exigences et la cible de Fedora et RHEL ne sont pas les mêmes. Mais pour les besoins au niveau de l'OS c'est la même chose.
Pour la détection/configuration, c'est le même besoin pour tout le monde. Une même solution peut marcher pour tout le monde.
En partant avec ton raison, il faut des noyaux linux différent, des X11 différents, etc. Ça sucks.
Autre aspect, comme tu fais pour concilier ton avis avec l'annonce de ce journal ?
L'annonce dit que TurboLinux et Mandriva vont utiliser le même mkinitrd par exemple...
Tu es contre ?
> , et surtout une vision différente de la manière dont il faut détecter et configurer le matériel.
Plus le temps passe, et plus c'est faux.
Je suis sûr qu'à moyen terme tout le monde va faire comme Fedora (c-à-d ne pas avoir de truc spécifique).
Et joubliais un "petit truc".
Tu peux installer des rpm sur Debian/Slack/etc. Et les programmes marcheront.
Pour l'utilisateur que ça soit "apt install" ou "yum install" ne change pratiquement rien. On trouve des programmes qui interfacent deb et rpm. Si PackageKit devient populaire, sûr que beaucoup d'utilisateurs ne sauront plus quel gestionnaire ils utilisent.
Les gestionnaires de paquet sont une "commodité". Certes importante pour des développeurs/admins, mais c'est tout. Ce n'est pas le coeur de l'OS. Loins loins de la.
Que dirais-tu si Windows passe à Deb ? Que Windows a changé de coeur ? Que Windows == Debian ?
Quand quelqu'un veut changer d'OS, le ne dit pas "je cherche un OS avec un coeur rpm". Il va dire qu'il veut un OS pour le desktop, pour faire un serveur, qu'il veut du "blengind edge", qu'il veut KDE ou Gnome, du sans proprio, etc.
Beaucoup de gens veulent conserver une barrière (artificielle) entre les distributions selon le gestionnaire de paquet. D'autant plus quand c'est pour surfer sur le "rpm puxor" et "donc" que l'autre distribution est nulle.
Tout ça c'est de la merde.
Le cas où ça commence à devenir vaguement pertinant, c'est pour les distributions orientés sources vs distribution "normal".
> Je ne sais pas trop de quel autre coté tu parles
Il serait un peu bête de cherche un bon et mauvais côté.
Il y a eu désaccord entre Johnson et Red Hat.
Johnson n'a pas tenu de propos "orduriers" envers Red Hat et vice versa. Il n'y a pas eu de "sabotage", etc.
Red Hat a laissé le cvs de rpm.org à disposition de Johnson, ainsi que les mailings. Ceci afin qu'il continu son boulot avec ceux qui partage ses objectifs. Notons que même si Red Hat en avait le droit aux yeux de la lois, il ne pouvait pas décemment se le permettre.
Johnson n'a pas réclamé de "propriété" pour le nom RPM. Johnson ne prétent pas être LE rpm. En passant, rpm n'est pas une marque protégé, et on voit la confusion que ça crée. Pas de quoi en faire un formage dans ce cas.
C'est ConsoleKit qui le fait (via hal/dbus ?).
Donc l'utilisateur test peut utiliser la carte son. Il n'a pas besoin d'appartenir à un groupe. Les acl sont utilisés aussi pour fast-user-switch.
NB : c'est le début de l'utilisation de ConsoleKit.
> ils ne changent pas le groupe
Ici (F8) il ne change pas le groupe (du moins lorsque quelqu'un prend la console). Les groupes pour les périphérique, ce n'est pas la tasse de thée de Fedora. Il n'y a pas de groupe audio, video, etc chez Fedora.
> Et il n'y a pas vraiment d'équivalent qui permet de détecter le module à utiliser pour chaque périphérique.
Tu parles de problèmes qui devrait être réglé en upstream. Fedora n'utilise pas ldetect ou autre. S'il y a un problème, il est corrigé en upstream (comme ça tout le monde en profite :-)).
Fedora utilise kudzu, mais pour des raisons historiques. kudzu va être viré.
A vrai dire, je ne sais même plus exactement ce que fait kudzu :-)
Kudzu ne fait pas de détection de matériel, il permet principalement de détecter un changement de matériel. Si par exemple un carte réseau a été ajoutée entre deux boots, il propose de la configurer (ce qu'on peut faire sans kudzu).
Depuis longtemps je le vire de ma bécane (sans --force ou --nodeps !) et ça ne dérange rien.
Il n'y a pas de problème, c'est bien. C'est même carrément génial lorsqu'il y a une petit mise à jour d'OOo.
Par contre, il ne faut pas croire que ça va tout accelérer.
> Il a droit de commit et donc corrige directement upstream c'est sur que c'est plus facile.
Il a fait la démarche de le demander et prouvé sa valeur. Ce qui est bien normal.
Faites de même avec Fedora. Il y a plein plein de cvs Red Hat qui ne sont pas en rw uniquement pour les employés de Red Hat.
En passant, le nouveau "patron" Fedora, n'est pas un employé Red Hat.
Red Hat est passé de up2date à yum et yum n'a pas été développé par Red Hat. Toute l'infrastructure de Fedora a vu la participation massive de développeurs non Red Hat (communauté, Dell, IBM, etc). Le site fedoraproject.org n'est pas géré par Red Hat.
Etc.
Red Hat/Fedora est beaucoup plus ouvert que tu ne le crois. Mais pas ouvert à n'importe quoi.
> Ca justifie d'avoir forké pour avoir un truc qui marche.
Oui. Mais il ne faut pas généraliser.
> Au hasard, des noms de groupe auxquels donner certains devices qui ne sont pas les mêmes que chez d'autres ?
Ce n'est pas udev, ça doit être MAKEDEV ou pam_console (qui va être remplacé par ConsoleKit). C'est seulement un fichier de configuration.
> C'est faux, on a depuis de nombreuses années la ldetect.
Ben ça doit être fabuleux par rapport à ce que fait le noyau et hal...
Vous allez aussi forcker hal ?
> De plus tout n'est pas dans le noyau, et il faut être capable de detecter quels rpm supplementaires installer en fonction du materiel, ou savoir si on est sur un portable par exemple.
Ce qui n'est plus de la détection de matériel. C'est du paramétrage en fonction du matériel qui a déjà été détecté (les modules ont été chargés et donc le matériel a été détecté). C'est seulement listé le matériel détecté.
> C'est tout simplement faux. Certains le font plus continuellement que d'autres (je pense par exemple à Fred Crozat pour tout ce qui est GNOME/hal/...) mais globalement tout le monde essaye d'être le plus proche d'upstream, ca fait moins de boulot et travailler à plusieurs permet que ca marche mieux pour tout le monde...
OK. Mais je disais par rapport à des choses qui sont upstream chez Fedora (et plus généralement Red Hat) pour Mandriva.
Un petit exemple mkinitrd.
mkinitrd de Mandriva : rpm -q --changelog -p mkinitrd-4.2.17-55mdv2008.1.src.rpm | grep -i merge
It probably should be just merged in label patch.
- merge rh 4.2.12
- merge bits from rh 4.1.12
- merge p1 into p0
- big merge from redhat's 4.1.9
- merge bits from redhat 3.5.24
- merge patch 5 into patch 0 (simplify patch)
- drop patch 4 (merged into simplified patch 0)
Dans la version upstream (6.0.19), on ne trouve que ça : find . -type f -print0 | xargs -0 grep -i mandr
./mkinitrd:# Guillaume Cottenceau <gc@mandrakesoft.com>
./mkinitrd.spec.in:- mkinitrd: add patch from gc@mandrakesoft.com to determine module
./mkinitrd.spec:- mkinitrd: add patch from gc@mandrakesoft.com to determine module
M'enfin, apparament tout est prétexte pour ne pas bosser avec Red Hat.
J'espère que vous aurez de meilleurs disposition d'esprit avec TurboLinux.
> - faire évoluer le format RPM pour qu'il soit plus portable d'une distribution à une autre
Comprend pas.
Rpm est largement utilisé par les distributions. Si tu dis ça en t'appuyant sur le constat que seul les distributions utilisant rpm utilise rpm, ben seul les distributions utilisant deb utilise deb.
Je ne crois que deb soit plus portable (rpm est aussi utilisé sur Unix et pas seulement Linux).
> et qu'il soit plus simple pour les développeurs d'empaqueter leurs logiciels dans un fichier RPM.
C'est plus simple avec deb ?
Faire un paquet rpm n'est pas compliqué. Mais c'est comme tout, il faut apprendre.
> - faire évoluer le système d'installation afin de ne pas à avoir à retélécharger tout le fichier RPM, mais seulement les différences d'une version à une autre.
Su le fait depuis longtemps.
> mais seulement les différences d'une version à une autre.
C'est fait depuis une version de "référence". S'il y a toto-1, puis toto-2, puis toto-3, lorsque tu va downloadé toto-3, ça va être le diff entre toto-1 et toto-3. Sinon ça fait trop de boulot coté serveur, trop de version à gérer, etc.
> Cette dernière évolution permettrait de rendre Yum, Aptitude et autres beaucoup plus rapide
Pas forcément, il faut reconstruire le paquet. Il y a un gain lorsqu'il faut downloader, mais après c'est plus lent. Si t'as une excellent connexion internet, ça ne sera peut-être pas toujours un gain.
[^] # Re: Ca fait un moment...
Posté par IsNotGood . En réponse au journal qui l'aurait cru.... Évalué à 2.
Je ne fais JAMAIS migrer quelqu'un. Je peux l'aider si c'est SON choix.
Je trouve détestable (je pèse mes mots) les "libristes" qui imposent leur vision. On ne compte pas les "j'ai migré machin vers KDE ou autre".
Ce n'est pas comme ça que le libre va se faire une place. C'est par son excellence. Firefox est excellent, inutile de forcer les gens à l'utiliser (ce qui n'apporterait rien à moyen/long terme).
OOo n'est pas encore excellent. Il progresse joliment, mais ne peut encore remplacer MS-Office dans certains cas. Pour mon travail, j'utilise souvant MS-Office. Pour les trucs persos, je n'utilise que OOo. Je fais attention de ne jamais diffuser du .doc only.
> au bout de 2 ans de boulot sur OoO, je vais avoir du mal à lui dire que c'était peut être une mauvaise idée ...
Fais lui un joli cadeau. Au moins pour te faire pardonner :-)
[^] # Re: Aux utilisateurs d'Abiword
Posté par IsNotGood . En réponse au journal Foresight Linux 2.0 Alpha 3 est de sortie. Évalué à 2.
OOo a fait beaucoup de progrès.
J'ai moins de 10 seconde au premier lancement et 1 seconde le suivant.
[^] # Re: Plaf
Posté par IsNotGood . En réponse au journal Vous savez quoi ?. Évalué à -1.
C'est la même chose techniquement. RHEL 5 est une FC6 avec quelques bricoles de plus. Faut être un expert pointu pour voir la différence. C'est le support qui change entre Fedora et RHEL. Techniquement c'est la même chose. RHEL est toujours basé sur Fedora.
> Mais pour comparaison, voici ce que l'on peut mettre dans le rc.conf concernant apache
Dans l'idée c'est la même chose. Donc ne voit pas pourquoi tu critiques le principe de Fedora et pas celui de FreeBSD. C'est le chemin /etc/sysconfig qui te pose problème ?
> Le gros intéret de rc.conf est qu'il permet d'avoir une vision synthétique de toute la configuration
Ça c'est les goûts et les couleurs. Certains développeurs veulent tout dans le même répertoire et d'autres veulent une arborescence.
> Tu as déjà regardé comment sont organisés les rc.* sur un BSD ?
Non, et je n'ai jamais dit que rc.* sur BSD était naze.
Mais ta critique de /etc/sysconfig de Fedora est gratuite et ça m'énerve.
> (tip: C'est à l'image du reste lorsque l'on compare Linux vs. BSD)
Faisons dans le troll. C'est limité et d'une autre époque ?
> Entre autre, les problèmes sur certains montage nfs (montages ro qui est en fait rw),
Puisque tu le dis.
> client nfs qui ne remonte pas forcement suite à un problème sur sa connexion avec le serveur,
Puisque tu le dis.
> nscd qui se gaufre sous forte charge,
Puisque tu le dis.
> nfs4 qui ne tient pas non plus avec en message d'erreur des problèmes VFS non traités qui n'auraient pas du remonter en userland (ces 2 derniers datent de nos tests d'il y a un an, on est revenu en arrière depuis),
Puisque tu le dis.
En passant, tu as fait ses tests sur quoi ?
Parce que NFS ça existe depuis longtemps et c'est très utilisé.
C'est bien gentil de mettre une liste de bug/limitation/manquement/etc.
Si on veut faire la liste de FreeBSD ça serait pire.
> /bin/sh qui est en fait un bash, avec toutes les gnuteries associées pour le shell root...
C'est connu, BSD est parfait est GNU ça pue, c'est le mal et ça veut la mort de BSD. Mais le monde est injuste, BSD c'est qu'une niche (même dans les serveurs).
[^] # Re: Plaf
Posté par IsNotGood . En réponse au journal Vous savez quoi ?. Évalué à -5.
Tu connais hypra mal Fedora.
Ce qui concerne apache dans Fedora :
/etc/systemconfig/httpd
Tout est dans ce registre. Il n'y a dans /etc/sysconfig que des options que tu ne peux pas changer avec /etc/httpd/conf*.
Mais au-lieu de faire un truc de porc en bidouillant les /etc/rc.*, tu fais la configuration en un lieu précis dans un cadre qui l'a prévu (plus ou moins car prévoir tout les cas est impossible).
[root@one ~]# du -s /etc
111596 /etc
[root@one ~]# du -s /etc/sysconfig/
864 /etc/sysconfig/
/etc/sysconfig est moins d'1 % de la configuration du système.
> Ayant plusieurs dizaines de serveurs à maintenir, j'aurai tendance à dire que statistiquemen les linux nous posent plus de problèmes que les BSD... et pas qu'un peu.
Je ne vois pas pourquoi.
[^] # Re: bsdiff...
Posté par IsNotGood . En réponse à la dépêche Sortie de rpm 5.0.0. Évalué à 1.
C'est la honte pour moi, mais merci :-)
[^] # Re: Non évènement
Posté par IsNotGood . En réponse à la dépêche Sortie de rpm 5.0.0. Évalué à 2.
C'est f8 en passant.
Et f8 c'est faire une installation via réseau (je l'ai fait).
Fedora fait ça depuis le FC1 !
Mieux, tu peux aussi faire une installation réseau via vnc.
Il y en a qui installe Fedora, graphiquement, sur dédibox.
Tu peux le faire avec Debian ?
> Et sait pas installer une fc8 avec juste le premier cd de tête en plus /o\
Admettons.
Tu peux installer via bootp (noyau et initrd récupéré sur le réseau).
Je veux bien admettre que ça manque de polish.
Mais ça marche puis des années ! Depuis RH 6.2 au moins (j'ai fait des netinstall avec RH 6.2).
> Il me demande aussi si je veux mettre à jour quand je fais une install "standard"
Tu peux faire l'installation et la mise à jour en même temps sous Fedora. Dans ce cas Fedora ne va pas installer toto v1 (de la release) puis mettre à jour vers toto v2 (des mises à jours). Il installe directement toto v2.
Je peux d'affirmer de façon définitive que ça le fait car je le fais et les dépôts utilisés sont sur une de mes bécanes (donc j'ai le log apache pour confirmer).
Il suffit à l'installation d'ajout un dépôt avec les mises à jours.
Alors pas d'accord pour dire que Fedora ne fait pas de netinstall. Fedora (et Red Hat) le fait depuis des lustres. Par contre, je suis tout à fait d'accord pour dire que ça manque de polish et qu'il faut lire un peu de doc (donc ce n'est pas accessible pour un newbi qui ne veut pas se prendre la tête).
[^] # Re: Non évènement
Posté par IsNotGood . En réponse à la dépêche Sortie de rpm 5.0.0. Évalué à 2.
Je ne vois où tu veux en venir a part conclure que le gestionnaire de paquet n'es tpas le coeur d'une distribution.
> Avec ton niveau d'argumentaire vache == cheval
Tu changes bien le coeur des OS seulement avec un gestionnaire de paquet.
Une vache à quatre pattes, comme un cheval.
Ça bouffe comme un cheval, ça a un regard attendrissant, et désolé, ça peut aussi se manger. Bref, plein de point en commun. Et au niveau ADN on doit avoir dans les 95 % d'ADN commun.
Mais tu veux faire de l'oreille de la vache son coeur (dans le sens "centre", "essence" et pas organe). Partant de la et constatant que l'oreille de la vache est différente de l'oreille du cheval, tu conclus qu'une vache et un cheval ça n'a rien à voir. Les anes et les chevaux n'ont pas les même oreilles.
Je te laisse à ton fétichime du gestionnaire de paquet.
[^] # Re: Navrant...
Posté par IsNotGood . En réponse à la dépêche Ubuntu 8.04 alpha 3, prête à déboguer !. Évalué à 4.
Et pourquoi Debian ne s'inspirerait pas de Mandriva ou Fedora ?
Et pourquoi Debian ne réfléchirait pas de lui-même ?
C'est dingue cette manie d'associer systématiquement linux-simple à Ubuntu.
Avant Ubuntu il y avait MEPIS, Linspire, Xandros, etc.
De plus, toutes les distributions "modernes" et généralistes sont simples. C'est trivial d'installer une RHEL/CentOS, ou Mandriva ou OpenSuSE, etc...
Installe une Red Hat 8.0 ou 9 (sorti bien avant Ubuntu), c'est simple. Pour info, l'installation est graphique sous Red Hat depuis RH 6.0 !
Des années avant Ubuntu.
Installe une F8, c'est trivial (même pas de question sur X11 ou la carte son (s'il n'y en a qu'une)).
Ubuntu a peut-être un peu plus le soucis de la simplicité. Mais ce n'est pas ici que se joue son succès par rapport aux autres. C'est dans son compromis (pour ne pas dire compromission) avec le logiciel proprio. C'est aussi car Ubuntu a capté un publique que pouvait enfin attirer GNU/Linux. Ce n'est pas Ubuntu qui a amené GNU/Linux a ce niveau. Mais Ubuntu, et donnont lui crédit, a su en profiter au bon moment, avec de la bonne communication, avec une bonne infrastruture (wiki), avec une bonne compréhension de ce nouveau publique.
Je suis admiratif de voir comme Ubuntu a su intelligemment et opportunément bien gérer tout ça. Mais Ubuntu n'a pas inventé l'eau chaude. Faut arrêter le délire.
Donnez des technologies ou réflexions qu'a apporté Ubuntu. Bonne chance.
J'entend bien que l'utilisateur Ubuntu classique en a rien à foutre de la technologie et je n'irais pas lui reprocher d'avoir choisi Ubuntu au-lieu de Mandriva ou autre.
Mais aujourd'hui on frize le délire Windowsien de la "belle époque" ou Microsoft avait inventé Internet seulement car les gens connaissaient Internet que via Windows.
La simplicité n'est pas l'exclusivité d'Ubuntu. Loins loins de là.
Juste un petit exemple en fouillant rapidement le web :
http://ometer.com/free-software-ui.html (avril 2002 !)
Un papier d'Havoc qui a fait beaucoup polémique à l'époque. Mais un papier visionnaire. Owen Taylor a aussi eu d'excellentes réflexions.
Et ne parlons même de Gnome 2.0 qui a fait couler d'encre :
- réduction des options
- obligation de respecter un HIG (Human Interface Guidelines)
- important travail de Sun sur l'ergonomie
- etc.
En fouillant les archives dlfp, on devrait encore trouver des débats très animés.
Pour le fun, un test de Xandros 3.0 (avant l'existance d'Ubuntu) :
http://www.quebecos.com/documents/xandros3/xandros3_page7.ht(...)
[^] # Re: Sisi
Posté par IsNotGood . En réponse au journal Qt sous GPLv3. Évalué à 4.
http://trolltech.com/company/newsroom/announcements/press.20(...)
C'est GPLv2 + v3.
[^] # Re: Navrant...
Posté par IsNotGood . En réponse à la dépêche Ubuntu 8.04 alpha 3, prête à déboguer !. Évalué à -1.
Ceci est de la connerie.
Les gens ne sont pas attirés par Ubuntu, mais par GNU/Linux, par un système solide et bien conçu, etc.
Ubuntu ce n'est que le packaging et deux ou trois bricoles de plus.
Ubuntu serait sorti à l'époque de Linux 2.0 ou 2.2, sans usb, sans AIGLX, sans udev/hal, etc ça attirerait beaucoup moins de personne.
En passant, Ubuntu est massivement basé sur Debian.
> Peut-être un objectif que les autres distributions ne s'étaient pas fixé.
Qui a fait le système usb de Linux qui roxe ?
C'est Ubuntu ? Non.
Qui a fait udev/hal/gnome-volume-manager/etc ?
C'est Ubuntu ? non.
Qui a fait AIGLX/compiz/etc ?
C'est Ubuntu ? non.
Qui a fait Gnome 2 avec toute la réflexion sur le "just works" ?
C'est Ubuntu ? non.
etc.
> En tout cas, un objectif que les autres distributions n'ont pas atteint.
Un objectif que n'a pas atteind Ubuntu. Ce n'est pas avec 0,5 % d'utilisateur qu'on peut pavoiser.
> Une fois habitués au monde GNU/Linux grâce à Ubuntu, ces utilisateurs n'auront pas un gros effort d'adaptation à faire pour essayer un autre bureau, une autre distro.
Et vice versa.
Il ne faut pas prendre les gens pour con ici et notamment à propos de Linux.
Une Mandriva ou une OpenSuse ou un Fedora, etc sont aussi simple qu'Ubuntu.
> Alors où est le vrai problème derrière ça ? Une bande d'irréductibles barbus associaux
Ton attitude est particulièrement associal et surtout méprisante pour tout ceux qui ont participé à faire de GNU/Linux ce qu'il est aujourd'hui. Dans ce travail IMMENSE, Ubuntu n'est qu'une goute d'eau.
> abandonnez Linux pour Hurd.
Beaucoup des personnes que tu "insultes", on fait udev/hal, AIGLX, apt, Gnome, KDE, etc.
Fais un truc : prends la premier Ubuntu et une Mandriva ou Fedora ou OpenSuse de la même époque. Tu verras que Ubuntu a tout pompé (ce qui est normal, tout le monde le fait dans le libre).
Et aujourd'hui, qu'a de si formidable Ubuntu ?
Un bon packaging et deux ou trois bricole. Ce n'est qu'une distribution parmis d'autres. Aujourd'hui elle est "hype" mais ça pourrait ne pas durer.
D'autres distribution ont été "hype".
[^] # Re: mini-forks
Posté par IsNotGood . En réponse au journal Manbo-Labs. Évalué à 0.
Non. Du moins pas en même temps.
> C'est un peu comme mkinitrd, il n'y a pas vraiment d'"upstream".
Désolé, mais quand on regarde l'historique de "votre" mkinitrd, l'upstream est le mkinitrd de Fedora.
> Rien n'empêche les autres distributions de reprendre nos outils.
Très juste. C'est par exemple ce qui a été fait avec rpmlint. Pas sous la forme d'un "mini-fork", mais participation upstream.
> Apparement, les 2 implémentations qui ressortent dans ce domaine sont ldetect et kudzu.
Comme je l'ai dit, je ne suis pas un spécialiste kudzu. Mais kudzu ne fait plus grand chose.
http://fedoraproject.org/wiki/Anaconda/Features/NoMoreKudzu
Bref, pour Fedora il n'y a plus à avoir de kudzu ou autre.
La présence de kudzu est aujourd'hui un bug (qui doit être corrigé).
> Il a quand même besoin de détecter du matériel pour proposer de le configurer
Faudrait s'entendre sur le vocabulaire.
Kudzu ne détecte pas le matériel, il le liste. Le matériel a déjà été détecté via les mécanisme classique (et upstream) de Linux.
Si je fais "ls /tmp", je ne détecte pas le contenu de "/tmp", je le liste.
> Il a quand même besoin de détecter du matériel pour proposer de le configurer
Configurer comme on configure X11, comme on configure la fréquence d'un carte tv ou radio, etc.... On n'est plus dans la configuration bas niveau, mais dans l'utilisation du hardware déjà détecté et configuré (pour le bas niveau (irq, ioport, paramètre des modules (puisqu'ils sont déjà chargé), etc)).
> et c'est ce qu'il fait avec pas mal de workarounds :-)
D'accord, mais c'est erreur. Le matériel (et pas le logiciel type X11, etc) doit être configuré sans kudzu. Je te paris qu'il le sera à moyen terme (F9 voire F10).
> Dans Mandriva, la reconfiguration de matériel est faite avec le service harddrake, écrit en Perl et se basant sur ldetect, c'est difficile d'envisager une fusion des 2 deux outils ...
Si Fedora peut virer kudzu, vous pouvez virer ldetect. Peut-être que ldetect ou kudzu resteront mais sous une autre forme. Par exemple uniquement pour voir s'il y a un ajout de matériel entre deux boot (typiquement l'ajout d'une carte PCI) et prendre les actions nécessaires. Si la carte graphique a été changée, il est clair qu'il ne faut pas lancer X11 sans le reconfigurer. Quoique Fedora utilise massivement l'autoconfiguration de X11 et peut-être qu'un jour par défaut il n'y aura plus de /etc/X11/xorg.conf. Et en réalité, c'est déjà fait pour linuxstateless.
> Et chaque distribution a ses besoins particuliers
Besoins ou caractéristiques ou exigences ou cibles ?
Les exigences et la cible de Fedora et RHEL ne sont pas les mêmes. Mais pour les besoins au niveau de l'OS c'est la même chose.
Pour la détection/configuration, c'est le même besoin pour tout le monde. Une même solution peut marcher pour tout le monde.
En partant avec ton raison, il faut des noyaux linux différent, des X11 différents, etc. Ça sucks.
Autre aspect, comme tu fais pour concilier ton avis avec l'annonce de ce journal ?
L'annonce dit que TurboLinux et Mandriva vont utiliser le même mkinitrd par exemple...
Tu es contre ?
> , et surtout une vision différente de la manière dont il faut détecter et configurer le matériel.
Plus le temps passe, et plus c'est faux.
Je suis sûr qu'à moyen terme tout le monde va faire comme Fedora (c-à-d ne pas avoir de truc spécifique).
[^] # Re: Non évènement
Posté par IsNotGood . En réponse à la dépêche Sortie de rpm 5.0.0. Évalué à 1.
Tu peux installer des rpm sur Debian/Slack/etc. Et les programmes marcheront.
Pour l'utilisateur que ça soit "apt install" ou "yum install" ne change pratiquement rien. On trouve des programmes qui interfacent deb et rpm. Si PackageKit devient populaire, sûr que beaucoup d'utilisateurs ne sauront plus quel gestionnaire ils utilisent.
Les gestionnaires de paquet sont une "commodité". Certes importante pour des développeurs/admins, mais c'est tout. Ce n'est pas le coeur de l'OS. Loins loins de la.
Que dirais-tu si Windows passe à Deb ? Que Windows a changé de coeur ? Que Windows == Debian ?
Quand quelqu'un veut changer d'OS, le ne dit pas "je cherche un OS avec un coeur rpm". Il va dire qu'il veut un OS pour le desktop, pour faire un serveur, qu'il veut du "blengind edge", qu'il veut KDE ou Gnome, du sans proprio, etc.
Beaucoup de gens veulent conserver une barrière (artificielle) entre les distributions selon le gestionnaire de paquet. D'autant plus quand c'est pour surfer sur le "rpm puxor" et "donc" que l'autre distribution est nulle.
Tout ça c'est de la merde.
Le cas où ça commence à devenir vaguement pertinant, c'est pour les distributions orientés sources vs distribution "normal".
[^] # Re: Non évènement
Posté par IsNotGood . En réponse à la dépêche Sortie de rpm 5.0.0. Évalué à 1.
Ou changer de compilateur, etc...
> C'est trop impactant.
Comme le changement du compilateur. Le compilateur serait le "coeur" de l'OS ?
On ne devrait plus dire GNU/Linux mais GCC/Linux ?
> Une distribution se définit par sa ligne éditoriale et le gestionnaire de paquets est l'outil privilégié pour l'appliquer.
Ça dépend des distributions.
Donc selon toi Xandros == Debian ?
CentOS == Mandriva ?
> Sans le gestionnaire de paquet et ses fichiers connexes, tu n'as plus de distribution mais la masse de code source qui lui sert de matière première.
Pareil pour gcc.
[^] # Re: Ca fait un moment...
Posté par IsNotGood . En réponse au journal qui l'aurait cru.... Évalué à 2.
Mieux vaut bosser sur ODF et pour la compatibilité sur OOXML (pour ceux qui y ont le goût).
[^] # Re: Non évènement
Posté par IsNotGood . En réponse à la dépêche Sortie de rpm 5.0.0. Évalué à 1.
Il serait un peu bête de cherche un bon et mauvais côté.
Il y a eu désaccord entre Johnson et Red Hat.
Johnson n'a pas tenu de propos "orduriers" envers Red Hat et vice versa. Il n'y a pas eu de "sabotage", etc.
Red Hat a laissé le cvs de rpm.org à disposition de Johnson, ainsi que les mailings. Ceci afin qu'il continu son boulot avec ceux qui partage ses objectifs. Notons que même si Red Hat en avait le droit aux yeux de la lois, il ne pouvait pas décemment se le permettre.
Johnson n'a pas réclamé de "propriété" pour le nom RPM. Johnson ne prétent pas être LE rpm. En passant, rpm n'est pas une marque protégé, et on voit la confusion que ça crée. Pas de quoi en faire un formage dans ce cas.
[^] # Re: R ?
Posté par IsNotGood . En réponse à la dépêche Sortie de rpm 5.0.0. Évalué à -2.
[^] # Re: mini-forks
Posté par IsNotGood . En réponse au journal Manbo-Labs. Évalué à 1.
Juste. Désolé. D'ailleur ça fait doublons avec /etc/makedev.d.
Je me suis mélangé les crayons.
> ConsoleKit/PolicyKit ne permettent que d'appliquer des ACLs aux devices
Très très bizarre.
[test@one /]$ ll dev/snd/pcmC0D1p
crw-rw----+ 1 root root 116, 4 jan 14 19:03 dev/snd/pcmC0D1p
[test@one /]$ id
uid=502(test) gid=502(test) groupes=502(test) context=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023
[test@one /]$ ll dev/snd/pcmC0D1p
crw-rw----+ 1 root root 116, 4 jan 14 19:03 dev/snd/pcmC0D1p
[test@one /]$ getfacl dev/snd/pcmC0D1p
# file: dev/snd/pcmC0D1p
# owner: root
# group: root
user::rw-
user:gdm:rw-
user:test:rw-
group::rw-
mask::rw-
other::---
C'est ConsoleKit qui le fait (via hal/dbus ?).
Donc l'utilisateur test peut utiliser la carte son. Il n'a pas besoin d'appartenir à un groupe. Les acl sont utilisés aussi pour fast-user-switch.
NB : c'est le début de l'utilisation de ConsoleKit.
> ils ne changent pas le groupe
Ici (F8) il ne change pas le groupe (du moins lorsque quelqu'un prend la console). Les groupes pour les périphérique, ce n'est pas la tasse de thée de Fedora. Il n'y a pas de groupe audio, video, etc chez Fedora.
> Et il n'y a pas vraiment d'équivalent qui permet de détecter le module à utiliser pour chaque périphérique.
Tu parles de problèmes qui devrait être réglé en upstream. Fedora n'utilise pas ldetect ou autre. S'il y a un problème, il est corrigé en upstream (comme ça tout le monde en profite :-)).
Fedora utilise kudzu, mais pour des raisons historiques. kudzu va être viré.
A vrai dire, je ne sais même plus exactement ce que fait kudzu :-)
Kudzu ne fait pas de détection de matériel, il permet principalement de détecter un changement de matériel. Si par exemple un carte réseau a été ajoutée entre deux boots, il propose de la configurer (ce qu'on peut faire sans kudzu).
Depuis longtemps je le vire de ma bécane (sans --force ou --nodeps !) et ça ne dérange rien.
[^] # Re: bsdiff...
Posté par IsNotGood . En réponse à la dépêche Sortie de rpm 5.0.0. Évalué à 1.
[^] # Re: Non évènement
Posté par IsNotGood . En réponse à la dépêche Sortie de rpm 5.0.0. Évalué à 1.
Par contre, il ne faut pas croire que ça va tout accelérer.
[^] # Re: Non évènement
Posté par IsNotGood . En réponse à la dépêche Sortie de rpm 5.0.0. Évalué à 4.
Fait "yum install yum-utils".
il y a repoquery dedans :
[test@one ~]$ repoquery --all | wc -l
11531
[test@one ~]$ repoquery --all | grep mutt
mutt-5:1.5.17-2.fc8.x86_64
[test@one ~]$ time repoquery --all --queryformat="%{NAME} %{ARCH} %{LICENSE}\n" | grep -i mutt
mutt x86_64 GPLv2+ and Public Domain
real 0m3.999s
user 0m3.766s
sys 0m0.247s
[test@one ~]$ repoquery --querytags | wc
28
4 secondes pour 11500 paquets, ça va.
On peut faire des choses plus exotiques :
repoquery --provides java-1.7.0-icedtea | xargs repoquery --whatrequires --queryformat="%{NAME}\n" | sort | uniq
avalon-logkit
axis
azureus
bolzplatz2006
castor
checkstyle
classpathx-mail
dtdparser
freecol
graphviz-java
...
Pour confort tu peux te faire des alias.
[^] # Re: mini-forks
Posté par IsNotGood . En réponse au journal Manbo-Labs. Évalué à 1.
Il a fait la démarche de le demander et prouvé sa valeur. Ce qui est bien normal.
Faites de même avec Fedora. Il y a plein plein de cvs Red Hat qui ne sont pas en rw uniquement pour les employés de Red Hat.
En passant, le nouveau "patron" Fedora, n'est pas un employé Red Hat.
Red Hat est passé de up2date à yum et yum n'a pas été développé par Red Hat. Toute l'infrastructure de Fedora a vu la participation massive de développeurs non Red Hat (communauté, Dell, IBM, etc). Le site fedoraproject.org n'est pas géré par Red Hat.
Etc.
Red Hat/Fedora est beaucoup plus ouvert que tu ne le crois. Mais pas ouvert à n'importe quoi.
[^] # Re: mini-forks
Posté par IsNotGood . En réponse au journal Manbo-Labs. Évalué à -1.
Es-ce que tu peux donner des preuves de ça ?
Un rapport de bug, etc...
Parceque Red Hat a une participation quasi massive en upstream. Si c'était des porcs, ça se saurait. Tu ne crois pas.
Parce ton commentaire frize le FUD et rien d'autre.
Moi j'argumente. Insufisament, très probablement. Mais je ne sors pas des trucs de mon chapeau.
[^] # Re: mini-forks
Posté par IsNotGood . En réponse au journal Manbo-Labs. Évalué à -1.
Oui. Mais il ne faut pas généraliser.
> Au hasard, des noms de groupe auxquels donner certains devices qui ne sont pas les mêmes que chez d'autres ?
Ce n'est pas udev, ça doit être MAKEDEV ou pam_console (qui va être remplacé par ConsoleKit). C'est seulement un fichier de configuration.
> C'est faux, on a depuis de nombreuses années la ldetect.
Ben ça doit être fabuleux par rapport à ce que fait le noyau et hal...
Vous allez aussi forcker hal ?
> De plus tout n'est pas dans le noyau, et il faut être capable de detecter quels rpm supplementaires installer en fonction du materiel, ou savoir si on est sur un portable par exemple.
Ce qui n'est plus de la détection de matériel. C'est du paramétrage en fonction du matériel qui a déjà été détecté (les modules ont été chargés et donc le matériel a été détecté). C'est seulement listé le matériel détecté.
> C'est tout simplement faux. Certains le font plus continuellement que d'autres (je pense par exemple à Fred Crozat pour tout ce qui est GNOME/hal/...) mais globalement tout le monde essaye d'être le plus proche d'upstream, ca fait moins de boulot et travailler à plusieurs permet que ca marche mieux pour tout le monde...
OK. Mais je disais par rapport à des choses qui sont upstream chez Fedora (et plus généralement Red Hat) pour Mandriva.
Un petit exemple mkinitrd.
mkinitrd de Mandriva :
rpm -q --changelog -p mkinitrd-4.2.17-55mdv2008.1.src.rpm | grep -i merge
It probably should be just merged in label patch.
- merge rh 4.2.12
- merge bits from rh 4.1.12
- merge p1 into p0
- big merge from redhat's 4.1.9
- merge bits from redhat 3.5.24
- merge patch 5 into patch 0 (simplify patch)
- drop patch 4 (merged into simplified patch 0)
Les patchs Mandriva :
cat *.patch | diffstat | tail -1
10 files changed, 1944 insertions(+), 803 deletions(-)
Dans la version upstream (6.0.19), on ne trouve que ça :
find . -type f -print0 | xargs -0 grep -i mandr
./mkinitrd:# Guillaume Cottenceau <gc@mandrakesoft.com>
./mkinitrd.spec.in:- mkinitrd: add patch from gc@mandrakesoft.com to determine module
./mkinitrd.spec:- mkinitrd: add patch from gc@mandrakesoft.com to determine module
M'enfin, apparament tout est prétexte pour ne pas bosser avec Red Hat.
J'espère que vous aurez de meilleurs disposition d'esprit avec TurboLinux.
[^] # Re: Non évènement
Posté par IsNotGood . En réponse à la dépêche Sortie de rpm 5.0.0. Évalué à 1.
Comprend pas.
Rpm est largement utilisé par les distributions. Si tu dis ça en t'appuyant sur le constat que seul les distributions utilisant rpm utilise rpm, ben seul les distributions utilisant deb utilise deb.
Je ne crois que deb soit plus portable (rpm est aussi utilisé sur Unix et pas seulement Linux).
> et qu'il soit plus simple pour les développeurs d'empaqueter leurs logiciels dans un fichier RPM.
C'est plus simple avec deb ?
Faire un paquet rpm n'est pas compliqué. Mais c'est comme tout, il faut apprendre.
> - faire évoluer le système d'installation afin de ne pas à avoir à retélécharger tout le fichier RPM, mais seulement les différences d'une version à une autre.
Su le fait depuis longtemps.
> mais seulement les différences d'une version à une autre.
C'est fait depuis une version de "référence". S'il y a toto-1, puis toto-2, puis toto-3, lorsque tu va downloadé toto-3, ça va être le diff entre toto-1 et toto-3. Sinon ça fait trop de boulot coté serveur, trop de version à gérer, etc.
> Cette dernière évolution permettrait de rendre Yum, Aptitude et autres beaucoup plus rapide
Pas forcément, il faut reconstruire le paquet. Il y a un gain lorsqu'il faut downloader, mais après c'est plus lent. Si t'as une excellent connexion internet, ça ne sera peut-être pas toujours un gain.
[^] # Re: Non évènement
Posté par IsNotGood . En réponse à la dépêche Sortie de rpm 5.0.0. Évalué à 1.
df avant/après :
Plus de 500 Mo installé, soit plus de 4,3 Mo/s.
Plus de 20 000 fichiers/répertoires, soit 170 fichiers/s.
En passant, les paquets sont downloadés depuis un réseau local et non depuis internet.