> EXEMPLE urpmi, smart permettent de connaitre le contenu d'un package non installé ainsi que de ses dépendances.
Yum ne se limite pas à la commande Yum. Il y a entre autre repoquery.
[admin@one rsync]$ rpm -q arj
le paquetage arj n'est pas installé
[admin@one rsync]$ repoquery -q -i arj
Name : arj
Version : 3.10.22
Release : 1.fc6
Architecture: i386
Size : 373102
Packager : Fedora Project <http://bugzilla.redhat.com/bugzilla>
Group : Applications/Archiving
URL : http://arj.sourceforge.net/
Repository : extras
Summary : Archiver for .arj files
Description :
This package is an open source version of the arj archiver. This
version has been created with the intent to preserve maximum
compatibility and retain the feature set of original ARJ archiver as
provided by ARJ Software, Inc.
[admin@one rsync]$
repoquery a plein d'option que je ne vais pas commenter ici mais seulement dire qu'il supporte aussi toutes les options de rpm.
> ajout facile de repository,
Yum n'a pas ça. Effectivement. Mais c'est un faux problème.
Yum a "/etc/yum.repos.d/" . Donc il suffit d'ajouter un paquet avec la configuration yum qui va bien. Tout le monde le fait. Si je veux freshrpms, je fais :
Et voilà, c'est fait. Tout le monde fait ça. La clée gpg qui va bien est aussi ajoutée. Après il te suffit de faire un "yum install paquet_freshrpms", ou lancer pirut, etc...
> création de ses propres repository,
Très facile avec yum. C'est createrepo.
[admin@one yum]$ createrepo --help
createrepo [options] directory-of-packages
Options:
-u, --baseurl = optional base url location for all files
-o, --outputdir = optional directory to output to
-x, --exclude = files globs to exclude, can be specified multiple times
-q, --quiet = run quietly
-g, --groupfile to point to for group information
( relative to directory-of-packages)
-v, --verbose = run verbosely
-c, --cachedir = specify which dir to use for the checksum cache
-U, --update-info-location = acquire package update metadata
-h, --help = show this help
-V, --version = output version
-p, --pretty = output xml files in pretty format.
[admin@one yum]$
Il y a aussi repoview. Il fait une version html d'un dépôt pour naviger dessus : [admin@one yum]$ repoview --help
usage: repoview [options] repodir
options:
--version show program's version number and exit
-h, --help show this help message and exit
-i IGNORE, --ignore-package=IGNORE
Optionally ignore this package -- can be a shell-style
glob. This is useful for excluding debuginfo packages,
e.g.: "-i *debuginfo* -i *doc*". The globbing will be
done against name-epoch-version-release, e.g.:
"foo-0-1.0-1"
-x XARCH, --exclude-arch=XARCH
Optionally exclude this arch. E.g.: "-x src -x ia64"
-k TEMPLATEDIR, --template-dir=TEMPLATEDIR
Use an alternative directory with kid templates
instead of the default: /usr/share/repoview/templates.
The template directory must contain four required
template files: index.kid, group.kid, package.kid,
rss.kid and the "layout" dir which will be copied into
the repoview directory
-t TITLE, --title=TITLE
Describe the repository in a few words. By default,
"RepoView" is used. E.g.: -t "Extras for Fedora Core 4
x86"
-l DTITLE, --title-deprecated=DTITLE
This option is deprecated. Please use -t.
-u URL, --url=URL Repository URL to use when generating the RSS feed.
E.g.: -u "http://fedoraproject.org/extras/4/i386".
Leaving it off will skip the rss feed generation
-f, --force Regenerate the pages even if the repomd checksum has
not changed
-q, --quiet Do not output anything except fatal errors.
[admin@one yum]$
> mode ligne de commande,
Pas de problème pour ça...
> relocation des packages (installé là plutot qu'ici),
Ça dépend du paquet. Il doit supporter "--prefix" de rpm. Si c'est le cas, yum le fait aussi. Fedora n'est pas fan de cette fonctionnalité.
Celà va de soit, yum supporte aussi chroot pour installer un système complet sur une partition vide (très utilisé par les utilitaires Xen).
> sauver un package (en refaire un rpm) avant de l'effacer/upgrader...
Up2date le faisait, yum ne le fait pas. Mieux, up2date stockait les opérations faitent et on pouvait revenir en arrière. Mais OK, yum ne le fait pas.
> Secundo comment sais-tu que yum est plus utilisé
Pour info, yum a aussi plein de plugin.
C'est "que" pour Fedora (Core et Extras). Ça n'inclus freshrpms, atrpms, etc... [admin@one yum]$ repoquery --whatrequires --queryformat="%{NAME}\n" yum | sort | uniq
anaconda
kyum
mach
mock
pirut
plague-builder
pungi
repoview
system-config-kickstart
yum-allowdowngrade
yum-changelog
yum-downloadonly
yumex
yum-fastestmirror
yum-fedorakmod
yum-kernel-module
yum-priorities
yum-protectbase
yum-skip-broken
yum-tsflags
yum-updateonboot
yum-updatesd
yum-utils
yum-versionlock
Ajouter createrepo qui crée des dépôts mais n'est pas dépendant de yum (ce qui est normal).
Et il y a aussi yum-utils avec des utilitaires sympathique : [admin@one yum]$ rpm -q -l yum-utils | grep bin
/usr/bin/package-cleanup
/usr/bin/repo-graph
/usr/bin/repo-rss
/usr/bin/repoclosure
/usr/bin/repomanage
/usr/bin/repoquery
/usr/bin/reposync
/usr/bin/repotrack
/usr/bin/yum-builddep
/usr/bin/yumdownloader
[admin@one yum]$
Pour info, yum supporte les plugins.
> Donc ce que tu affirmes est parfaitement faux, yum a du succès façon MS: personne n'ose d'autre solution
Pour Fedora il y a : up2date, apt4rpm, yum, smart.
Que propose Mandriva ? urpmi.
Il y a peut-être smart maintenant.
Pour ton info, Yum n'a pas été développé par Red Hat. La page projet de yum : http://linux.duke.edu/projects/yum/
A l'origine Yum était fait pour Yellow Dog. Yum c'est imposé au près de Red Hat et Fedora car c'est le meilleur (ou le plus apprécié). Au début de Fedora, il y a eu des tonnes de discussion pour savoir s'il fallait abandonné up2date et par quoi le remplacer. Le débat était principalement autour de smart et Yum. Yum l'a emporté de peu.
Ton "yum a du succès façon MS", tu peux te le carrer dans le cul.
Quel alternative à urpmi a tenté Mandriva ? Rien.
> personne n'ose d'autre solution
Smart a été proposé et est dispo dans Fedora Extras depuis FC2 (peut-être FC1).
apt4rpm a été proposé et est dispo dans toutes les Fedora.
Yum a été proposé (au début il n'était que dans Fedora Extras).
Urpmi n'a jamais été proposé. Propose le si tu veux.
Tu fais bien de le souligner. Ext3 protège les données comme aucun FS le fait. C'est pour ça que c'est le "chouchou" des développeurs Linux (et de très loins). Donc les comparaisons entre ext3 et un autre système de fichier journalisé ne sont pas juste. Ext3 en fait plus et oui ça a un coût en performance (sauf sous forte charge et avec multi-cpu ou ext3 est au top).
Mais qu'es-ce qui compte le plus ? Vitesse ou fiabilité ? Pour moi c'est la fiabilité.
J'ai jamais compris pourquoi les gens veulent autre chose qu'ext3 alors que ce FS roxe. Certe d'autres FS font mieux dans tel ou tel domaine. Mais ext3 a un fabuleux compromis fiabilité/performance/fonctionnalité.
> Je suis d'accord. ext2/3 conviennent pour tous les usages courants
Comme tout les FS...
> Il n'y a que pour certains cas "extrêmes" que l'usage d'un autre FS peut devenir intéressant
> Je pense notamment aux serveurs très fortement chargés
Là tu te trompes un peu. Le point fort d'ext3 n'est pas un usage Desktop, c'est en usage serveur avec forte charge qu'il donne toute sa mesure (lecture et écriture simultannées). C'est pour ça que Red Hat l'utilise. Pour un serveur de fichier ou base de donnée sous forte charge et sur un système multi-cpu, les autres FS se prennent une branlée. Et c'est aussi pour ça que Novell a laissé tomber ReiserFS.
Autre point positif d'ext3, il supporte tout sans accro : ACL, SeLinux, NFS, Smb, etc...
Les gros problèmes actuels d'ext3 sont la limite en taille (8 ou 16 To) et la durée des fsck. Ces problèmes seront corrigés avec ext4. Notes bien que ces problèmes ne consernent pas un usage courant/desktop. Mais ils sont tout en haut de la TODO list.
> .... qu'elle distrib choisir pour la certification.... voila le genre de question qu'ils se posent
Un peu de sérieux. C'est une question à deux centimes. Les autres supportent Red Hat et Novell. Avec ça tu fais sans problème 80 % des entreprises.
Et si ça tourne sur Red Hat (ou Novell) c'est trois rien pour que ça tourne avec l'autre.
> J'espere que les gens de PSA comptent mettre la pression sur DS pour ce genre de possibilité CatiaV5 sous LINUX ( une sorte de reve LOL) ce serons les seuls qui y arriverons, mais ils sont deja tellement impliqué dedans qu'ilns n'ont eu aussi dejà presque plus le choix :(
Mais oui ils ont le choix. Je ne doute pas qu'il y aura Catia sous Linux. PSA le demandera, j'en suis convaincu. C'est une question de temps maintenant.
Linux va devenir le standard Unix. Il n'y a que Solaris qui peut le contester.
J'ai bossé chez PSA, et ils seront très heureux d'avoir un "vrai" standard Unix. Si de plus cet Unix est utilisé en Desktop, c'est que du bonheur pour eux. Par contre, et pour avoir bossé chez PSA, ça peut être long, très long (ce qui se comprend).
> Sinon urpmi est très bien, et je ne comprends toujours pas pourquoi ce n'est pas mis en standard dans les Redhat, Fedora et OpenSuse...
Si tu connaissais Yum, tu comprendrais très vite.
Le seul reproche sérieux qu'on peut faire à Yum, c'est de ne pas supporter les périphériques amovibles (CD, DVD). Mais c'est un choix qui a ses raisons et que je ne vais pas étaler.
Regardes du côté de urpmi. C'est compliqué, il y a des howto de 50 pages, il faut mettre à jour le cache avant de lancer la mise à jour, il y a 40 commandes, ça ne passe pas par librpm pour résoudre les dépendances, etc...
Tout ce qui y a connaitre avec yum c'est "yum update" et "yum install mon_programme".
En plus urpmi est écrit en Perl...
Yum, même récent à côté de urpmi, est déjà plus utilisé par les développeurs. On ne compte plus les utilitaires qui utilisent Yum. Yum est partout dans Fedora. Dans l'installeur, dans le serveur qui vérifie s'il y a des mises à jours, les download et l'indique sur le bureau, dans l'applet qui fait les mises à jours, dans system-config-package, etc...
Pour RHEL 5 (la distribution qui fait de l'argent chez Red Hat), RHEL va passer à Yum. Il n'y aura plus de trace de up2date.
Une erreur qu'a fait Mandriva (encore une...), c'est de ne pas utiliser smart alors qu'en plus Mandriva a racheté Conectiva (dont les développeurs de smart).
Fedora/Red Hat ose passer de up2date à yum. Mandrake reste accroché à urpmi qui est sans avenir.
Entre Yum et smart, il y a de quoi hésiter. Entre Yum et urpmi, il n'y a pas de quoi hésiter.
Il existe smart pour Fedora et apt pour Fedora car des gens les veulent. C'est dans Fedora Extras. Il n'y pas urpmi pour Fedora car personne en veut. Il n'y a que urpmi pour Mandriva.
> Que reproches tu finalement à Mandrake/riva : de ne pas voir assez de développeurs travaillant sur le bas-niveau.
Non. Le manque de développeur est une conséquence.
Mandriva n'a pas de business plan clair. Ils veulent tout faire (serveur, desktop, gadget, etc). En voulant tout faire, ils font tout mal. Je n'en déduit pas que les développeurs de Mandriva sont plus con qu'ailleurs. Mais simplement que ce n'est pas possible avec leur moyen. Même Red Hat qui a des moyens sans commune mesure avec Mandriva ne se disperse pas comme le fait Mandriva.
> de ne pas voir assez de développeurs travaillant sur le bas-niveau
Mais veulent-ils le faire ?
J'en doute et de doute manière ils ne sont pas en position pour le faire. Ils ont déjà trop à faire pour sortir une distribution régulièrement (la mandriva libre, la discover, la machine, la usb, la corporate server, etc...).
> Vue la politique de développement de Mandriva, (pas l' économique) il est très clair que si elle en avait les moyens, elle le ferait sans hésiter.
J'en doute toujours. Mandrake avait les moyens il y a quelques années. Mais qu'on-t-il fait ? Ben ils ont investit dans le e-learning. Une catastrophe.
> Un exemple parmi d' autres : le travail fait sur nepomuk
Un bon point pour Mandriva. Ils ont aussi bossé sur l'impression. Mais compare avec Red hat et Novell. Même en rapportant au nombre de salarié, c'est ridicule.
> Tu retombes sur la "mentalité française" dont tu disais partager mon agacement à son encontre au début du post.
Tu tombes dans la mentalité : Mandriva est génial et tout ce qui lui arrive est une puissante injustice.
Mandriva a largement eu sa chance, a eu un support de la part de la communauté énorme. On ne compte pas le nombre de personne qui ont acheté des boites ou se sont abonnés au club Mandrake uniquement pour supporter Mandrake car ils croyaient en Mandrake. Ils n'ont pas eu tord de tenter d'aider Mandrake.
Regardes les faits. Mandrake a eu une popularité et un soutient énorme en France. Je ne crois pas que Mandrake ait eu à souffrir d'une certaine "mentalité française" que tu décris. Loins de là.
> De plus, lorsque je vois les problèmes d'incompatibilité de nombreuses licences entre elles
Les incompatibilités c'est dans les deux sens. Dans les grandes ligne la gauche est incompatible avec la droite et vice versa. Le libre est incompatible avec le propriétaire et vice versa. Que la GPL soit incompatible avec les licences propriétaires (et vice versa) n'en est qu'une conséquence et non la cause.
Supprime l'incompatibilité de la GPL avec les licences propriétaires, et il n'y a plus de GPL, il n'y a pas de code qui reste libre, il y a du code qui peut être libre ou propriétaire. Mon code, je veux qu'il reste libre, toujours, pour que les utilisateurs soit toujours libres.
> je préfère laisser les gens libres
C'est très naïf.
Libre à tout le monde de déposer de brevets, d'avoir des EULA à la con, etc.
C'est ça laisser les gens libres ? Une toute petite minorité profite des brevets, etc de la "liberté" BSD, et une grande majorité est "enchainée".
Un dictateur a besoin de beaucoup de liberté, mais il ne défend pas la liberté. Microsoft veut un maximum de liberté (donc MS adore la BSD). Mais ce n'est pas pour la liberté des utilisatieurs.
Mais qui aurait dit il y a quelques années que java et solaris serait sous GPL ?
Peut-être que dans 5 ans les brevets vont perdre en importance.
> du fait de la provenance du code de multiples développeurs à qui il faudrait demander la permission pour changer la licence
Si un concensus sort pour passer Linux en GPL v3 (ce n'est pas le cas aujourd'hui) les quelques fichiers qui posent problème seront virés. Ça c'est déjà vu.
> Je ne glisse pas dans le FUD, mais des réactions celle de Herve_2 m'énerve car il n'y a pas l'once d'un renseignement avant de sortir des affirmations complètement fausses. Idem pour ton intervention d'ailleurs.
Merci. Mais herve_02 a raison. Relis le (lentement et tous les mots).
> Donc c'est bien ce que je dis la situation est la même que pour la fourniture de gcc
> Il y a écrit « en tant que module », donc il n'est pas question de compiler un binaire du noyau BSD avec des drivers Linux dedans, mais bien de continuer à livrer un noyau BSD classique, et à côté des modules extrait de Linux, sous GPL.
Ça, après avoir regardé dans le détail, ne doit pas poser de problème.
Mais herve_02, qui se fait moinser injustement, dit :
- "Si ils doivent modifier le makefile pour les compiler sous freeebsd, il n'ont pas le droit de les redistribuer (ensemble et compilés)"
herve_02 a raison. Le système de score dlfp a encore tord...
La BSD est compatible avec la GPL mais pas l'inverse.
Un source sous BSD dans un projet GPL a sa licence toujours respecté.
L'inverse est faut. Si un projet est sous BSD, alors on peut le distribuer sans les sources. Si est fichier de ce projet est source GPL, on viole la GPL.
Rien à voir. Gcc est sous GPL qu'il soit fournit pas FreeBSD ou Linux. Evites de glisser dans le FUD.
gcc n'est pas un travail dérivé de Linux. Les drivers de Linux le sont (en fait ça dépend, Linus n'a pas exactement la même interprétation que RMS).
Si un drivers est sous GPL, il ne peut être mis dans le noyau FreeBSD et redistribué. La licence GPL du driver est en contradiction avec la licence BSD et vice versa.
Par contre le driver peut être délivré séparément.
Mais beaucoup de driver Linux sont sous double licence BSD-GPL.
> Je pense que Mandriva souffre encore du désastreux passage de Harry Poole à sa direction.
Car avant c'était mieux ? Si c'était si merveilleux que ça, pourquoi Mandriva est allé le chercher ?
> Tout s"est passé comme si il avait été nommé (par les investissers US) pour couler la boite.
Ça frise l'anti-américanisme primaire.
Qui a demandé ces investisseurs ? Qui a accèpté ces capitaux ? C'est Mandrake et personne d'autre.
D'ailleurs sans ses investisseurs Mandrake serait peut-être déjà mort.
> Si tu proposes de bonnes rédactions la-dessus et que c'est refusé (parcequ'on déteste RedHat/Novell/Whatever, comme chacun sait) tu pourras poster ce genre de truc.
J'ai dit que pour aujourd'hui (actuellement, ces dernières semaines/mois), j'étais mauvaise langue.
Je crois qu'il est urgent de tuer le débât dans l'oeuf.
> Ceci étant : si Mandriva n'existait pas, la différence serait que la seule vraie distribution facile à installer, stable, avec bcp de matos reconnu, tournée vers l'utilisateur, et qui fonctionne out of the box n'existerait pas.
Ubuntu, Linspire, etc tu veux dire ?
Il y a quoi en code dans Ubuntu qui vient de Mandriva ? Pas grand chose. Ubuntu, comme Mandriva, utilise beaucoup de code de Red Hat et Novell. Pas seulement du code dédié serveur mais aussi du code pour que ça "fonctionne out of the box".
Quelle a été la premier distribution qui "fonctionne out of the box" ?
Red Hat ou SuSE et pas Mandr(ake|iva). Red Hat/SuSE ont eu une interface graphique simple d'installation bien avant Mandrake.
Au début de Mandrake, Mandrake n'était qu'une Red Hat avec KDE en plus. Rien d'autre. Red Hat ne distribuait pas KDE a cause de la licence de QT (qui n'était pas GPL à l'époque). Ce n'est pas un reproche, c'est pour remettre dans le contexte.
Qu'es-ce qui permet d'avoir des choses qui marche "out of the box" ? Un drakebidule en perl de plus ?
USB est formidable dans la facilité d'usage. Maintenant quand on branche une clée USB, elle est montée illico. Si c'est un appareil photo, gphoto est lancé, etc... C'est grace à un drakebidule qu'on lance depuis mcc ? Ben non, c'est en codant au niveau du noyau, c'est en faisant dbus, c'est en faisant Hal, c'est en faisant gnome-volume-manager, etc. C'est des technologies comme ça dont a besoin Linux, pas d'un drakebidule de plus. Ces technologies sont difficiles à développée, mais c'est le chemin qu'il faut prendre. Un drakebidule c'est facile à faire, ça impressionne la galerie, mais c'est sans avenir.
Vaut-il mieux développer au niveau noyau/xorg pour que l'OS reconnaisse automatiquement une souris qu'elle soit sur un port USB ou PS/2 et ainsi qu'a l'installation on ne te demande rien à propos de la souris, ou faire un drakesouris qui te demande si ta souris est sur un port USB ou PS/2 ou serial ?
Avec stateless du projet Fedora, on arrive à installer Fedora sur n'importe quelle bécane sans le moindre clique. Dans un contexte entreprise la configuration software (et non hardware) est récupérée sur un serveur. En entreprise, on vient de te livrer une nouvelle bécane, et tout ce que tu as à faire c'est de la brancher. Tous les périphériques seront configurés à la volée sans intervention et la configuration logiciel correspondra a ton entreprise. Ça c'est du progres. Ceci dit stateless n'est pas encore terminé et c'est un boulot sur le long terme. Il fera ces début commercial avec RHEL5.
Où est Mandriva dans ces technologies qui compte vraiment ? Pratiquement null part.
Puis la facilité de Mandriva est vraiment discutable. Leur installateur a des tonnes de paneaux de configuration. Oui, de configuration et non pour l'installation. Red Hat/Fedora a le minimum et ne fait que de l'installation. Il peut y avoir de la configuration qu'en on veut être sur que l'utilisateur passe par une étape. Typiquement pour que l'utilisateur active le pare-feu.
Compares une installation de Fedora avec Mandriva, et ça va te sauter aux yeux.
Le défaut est tellement criant qu'il a fallu que Ubuntu fasse une installation simple pour raffler la mise. Et non, Ubuntu n'est pas basée sur Mandriva, n'a pas besoin des technologies made by Mandriva, pour arriver à ça.
Au niveau applicatif, qu'es-ce que Mandriva a développé et qui est utilisé aujourd'hui ? Ben presque rien.
> La "popularité" d'Opensuse, est vraiment, pour moi, issue d'un matraquage mediatique sur le web.
Pas en France en tout cas. Puis c'est récent, c'est depuis OpenSuse.
On peut aussi parler du matraquage mediatique sur le web de Mandrake.
> mais ce que je disait n' est pas faux non plus, j' ai oublier de préciser "% de dev., de recherche en comparaison du CA." Là, Mandriva tiens la route clairement
Pas sûr. Au début de Mandrake j'aurais dit oui. Aujourd'hui Mandriva doit maintenir ces outils de configurations spécifiques, doit bosser pour faire plein de version boite (ce qu'a arrêté de faire depuis longtemps Red Hat... car c'était cher et sans plus-value significative pour l'utilisateur), doit s'occuper de son service club compliqué à plusieurs niveaux d'accès, modérer les forums club, etc... Vu la taille de Mandriva, il ne reste plus grand monde de disponible pour contribuer au libre. Aujourd'hui c'est la faute à personne. C'est l'accumulation de l'historique de Mandriva.
Un exemple. Alors que Red Hat poussait Fedora et un cycle de 6 mois plus synchronisé avec les développements upstreams, Mandriva "pissait" contre vent avec un cycle d'un an. Aujourd'hui Mandriva est revenu en arrière. Mais combien de contributeur ont quitté le navire ? Pas beaucoup je pense. Mais combien de temps ça va prendre pour les retrouver ? Beaucoup.
> Mandriva vient de commencer à participer à GCC, par le biais d' un projet européen. Et l' équipe historique de GCC voit cela d' un oeil pragmatique me semble t i
Encore une fois Mandriva "pisse" contre le vent. Regardes ce que fait Red Hat/Sun/Novell, etc...
Ils ne passent plus d'accord avec telle ou telle boite sur une projet de recherche.
Je prend l'exemple de Fedora car je le connais un peu. Red Hat met son équipe de développement sur la place public (c'est Fedora). Si quelqu'un veut participer, il se présente, il présente le projet, il montre du code, et si ça branche les développeurs de Fedora/Red Hat, ben ils suivent le wagon. Red Hat a dit que depuis Fedora (évidemment c'est arrivé petit à petit), il y a de plus en plus de développement "officieux" qui se font via Fedora. Dell/etc participent à Fedora. Avant Dell/etc ne participaient que pour le "produit" Red Hat (c'est-à-dire RHEL). Mais maintenant quand Dell veut bosser avec Red Hat, quand Dell veut qu'une évolution soit dans RHEL, il n'envoie pas un commercial pour négocié un contrat. Dell dit à ses devéloppeurs de bosser et de communiquer avec Fedora (ou d'autres distributions, ou les projets upstreams). Exemple, c'est Dell qui vérifie les dépendances "BuildRequires" pour Fedora ! Fedora n'a rien demandé, il n'y a pas eu d'accord entre Red Hat et Dell pour ça. Dell fait des choses, si c'est interessant Fedora participe, si ça aboutit c'est dans Fedora (et dans toutes autres distributions ou projet upstream évidemment). Et voilà :-)
Avec ce nouveau modèle, on ne sait plus qui a fait quoi. Et alors ? Dell a ce qu'il veut. Fedora a des contributions. Tout est ouvert et ceux les mieux à même de participer participent. Que du bonheur...
Cette initiative européen doit être saluée évidemment. Il faut encourager Mandriva pour ce projet. Mais bon, c'est comme souvent, Mandriva a un train de retard. Les communications de ce projet devraient avoir lui sur les mailing gcc, avec les spécialistes de gcc qu'ils viennent de Red Hat ou Novell ou Mandriva et pas dans un coin. Il est claire que ce projet aura peu d'aide de la part de gcc s'il reste dans son coin. C'est ce projet et gcc qui vont en patir.
> ce qui me fait chier personnellement c' est la différence d' attitude entre les anglo-saxons et les français. Et ça, ce n' est pas spécifique à mandrake.
C'est bien vrai.
> les français n' aiment pas les boites françaises,
Certe, je n'aime pas Mandrake, mais j'achete en général du français. Ma bagnole est française, etc... Pas tout évidemment, mais j'essaie d'acheter français même si ça me coute quelques ¤ de plus. Et en général je ne le regrette pas.
> et dès qu' il s' agit de les soutenir, y a pas grand monde de chez nous.
Mandrake est une mauvaise boite. Ce n'est que mon avis. Et contribuer/soutenir une mauvaise boite ne m'emballe pas.
> Je me demande comment Novell peut encore avoir des contributeurs externes tellement ils se moquent des LL
Il y a un accro avec Novell et c'est son accord avec MS. Un accro grave. Et d'ailleur ça lui a couté des développeurs qui sont partit (Novell l'a reconnu).
> Mandriva avec bien moins de moyens, travaille bien plus pour le LL de manière générale.
Les contributions au libre de Novell sont sans commune mesure avec Mandriva. Vérifies toi même.
> Nous avons en France parmi les meilleurs et les plus gros programmeurs. Et en europe, c' est le grand bonheur.
Heureusement RedHat/Novell paye beaucoup de développeurs européen. Pour en citer un, citons Alan Cox.
> Mandriva apporte aux LL
Franchement, regardes ce qu'a apporté Mandriva au libre. Il reste rien ou presque.
Novell c'est alsa (énorme comme contribution), c'est (voire c'était) KDE (énorme), la libc (énorme), etc, etc...
RedHat c'est NPTL, ext3, le plus gros contributeur à Linux/gcc/libc/binutils, etc, etc... Red Hat c'est aussi du pognon pour le "lobby" anti-brevet.
Red Hat et Novell ont fait des choses qui restent et sont utilisées dans la durée.
Mandriva il n'y a pratiquement rien.
Si Mandr(ake|iva) n'existait pas, il n'y aurait pratiquement aucune différence aujourd'hui. Si Red Hat ou Novell n'existait pas, la différence serait énorme. Pas d'alsa, pas de NPTL, pas de etc...
Je ne crois pas. De plus il n'y a pas de brevet en Europe.
Ce qui a me semble-t-il pesé, est que Novell et SuSE ont une longue tradition de proposer des solutions de cohabitation Windows/Linux. Ce n'est pas le cas de Red Hat qui est concentré sur Linux/Unix. Red Hat a beaucoup de succès dans les serveurs (principalement migration Unix vers Linux) et c'est peu intéressé au desktop. Bien qu'il ne l'ignore pas (ses contributions dans Gtk/Gnome/Mozilla le prouve), ce n'est pas *aujourd'hui* leur cible commerciale (ça devrait changer avec RHEL5 qui sort début mars). Peugeot migre principalement des Desktops et Novell/SuSE a probablement plus d'expertise dans ce domaine. J'imagine que c'est ça qui a fait que Novell a gagné le marché. Bravo.
> Elle ne figure maintenant qu'en seconde page sur Linuxfr...
Parceque ce n'est pas Mandr(ake|iva).
Mais aujourd'hui je suis mauvaise langue.
Red Hat (probablement idem pour Novell mais je n'ai pas vérifié) a des tonnes de "success story" : http://www.redhat.com/rhel/informationcenter/successstories/(...)
Mais comme c'est Red Hat (ou Novell), ça ne passe pas ici. Aujourd'hui c'est passé car c'est Peugeot (avec un volume de migration exceptionnel pour Linux, il faut bien le reconnaitre).
Red Hat a pour la troisième année consécutive (!) été considéré comme n°1 "most valuable software vendor" (comment traduire ça ?).
Ce qui montre que les entreprises lorsqu'elles choisissent Linux sont très satisfaites. Que le choix de Linux n'est pas intéressant "idéologiquement", mais aussi financièrement et en terme de service pour une entreprise. Et du service de qualité, Red Hat prouve qu'il existe, peu exister avec du logiciel libre. Contrairement à ce que veut nous faire croire certains FUD.
> La seule chose que je trouve dommage, c'est qu'une entreprise française ou même européenne n'ait pas été choisie.
La seule chose qui est dommage est que Mandr(ake|iva) est HYPRA mauvais et point barre. Ça fait depuis des années qu'ils n'ont pas été foutu d'avoir un "business plan" correct, qu'ils foutent de l'argent en l'aire, etc... alors que Linux est en pleine expansion. Depuis des années Red Hat a une croissance de plus de 30% par an ! Et les profits suivent et Red Hat ne manquent pas d'idée pour les réinvestir dans la durée. Par exemple en achetant Sistina, en faisant Red Hat Network, Fedora, OLPC, stateless et maintenant avec JBoss même si actuellement il ne font pas de profit avec ce dernier. Mais à moyen terme ça va changer.
Red Hat (mais aussi Novell) place ses pions sur la durée. Mandr(ake|iva) fait des coups d'esbrouffe.
Aujourd'hui je ne vois pas comment Mandriva ne pourra pas être étouffé par Red Hat et Novell.
Mandrake avait une place de choix au début de Linux et avait des opportunités formidables. Presque tout a été gaché. Je crois que Mandriva est condamné à être un acteur mineur du libre.
Je n'aime pas Mandr(ake|iva), mais ça fait chier de voir que l'Europe n'a pas une boite en mesure de concurrencer les deux gros Red Hat/Novell alors que l'Europe est peut-être le plus gros contributeur au libre et ne manque pas de têtes bien faites.
Ça me fait chié, mais je n'ai pas non plus envis de supporter une boite à la con.
Posté par IsNotGood .
En réponse au journal CQFD.
Évalué à 3.
> Et comme debian est la seule à respecter vraiment le libre
Par rapport à ma man page gcc dont tu n'as pas accès, il faut vraiment s'interroger.
C'est respecter le projet gcc que de ne pas fournir la doc ?
Et tout ça pour quoi ?
Car Debian ne veut pas respecter une petite clause qui concerne 0,01 % du la doc.
C'est ridicule.
Enfin, la FSF est mieux placé pour dire ce qui est ou non du logiciel libre ou dans "l'esprit" du logiciel libre. La GFDL est libre (ou au moins à 99,99 %) mais Debian veut la "diaboliser" et fait peu cas des gens qui écrivent de la doc bénévolement, une doc libre au sens de la FSF.
Franchement : honte à Debian.
La GFDL n'a jamais posée de problème à personne. Il y a que Debian qui casse les couilles en voulant se la péter.
Et où en est l'adoption de DCC (Debian Core Consorcium) ?
> Debian est une distribution bien en vie : contrairement à Ubuntu qui a une majorité d'utilisateurs où la contribution se limitera à des howto dans des wiki,
Pertinant.
> Des trucs comme ça ne se voient pas dans Fedora Extras où les packages sont bumpés en version quand celà est nécessaire
Étant un utilisateur de Fedora depuis ses débuts, je dois dire que tu aventures un peu. De plus, tout ensemble important de logiciel (ce qui est le cas d'une distribution) peut toujours avoir un bug (et en général en possède plusieurs).
Donc ton exemple avec F-spot est un peu léger. De même, je ne vais pas m'amuser à critiquer Ubuntu car une fois ils ont livré un Xorg inexploitable. Ce type de truc peut arriver à tout le monde d'autant plus lorsque c'est une distribution "communautaire".
[^] # Re: Autre temps, autre moeurs...
Posté par IsNotGood . En réponse à la dépêche Linux en entreprise : deux nouveaux exemples de migration. Évalué à 1.
Yum ne se limite pas à la commande Yum. Il y a entre autre repoquery.
[admin@one rsync]$ rpm -q arj
le paquetage arj n'est pas installé
[admin@one rsync]$ repoquery -q -i arj
Name : arj
Version : 3.10.22
Release : 1.fc6
Architecture: i386
Size : 373102
Packager : Fedora Project <http://bugzilla.redhat.com/bugzilla>
Group : Applications/Archiving
URL : http://arj.sourceforge.net/
Repository : extras
Summary : Archiver for .arj files
Description :
This package is an open source version of the arj archiver. This
version has been created with the intent to preserve maximum
compatibility and retain the feature set of original ARJ archiver as
provided by ARJ Software, Inc.
[admin@one rsync]$
repoquery a plein d'option que je ne vais pas commenter ici mais seulement dire qu'il supporte aussi toutes les options de rpm.
> ajout facile de repository,
Yum n'a pas ça. Effectivement. Mais c'est un faux problème.
Yum a "/etc/yum.repos.d/" . Donc il suffit d'ajouter un paquet avec la configuration yum qui va bien. Tout le monde le fait. Si je veux freshrpms, je fais :
$ (rpm -i | yum install) http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/6/freshr(...)
Et voilà, c'est fait. Tout le monde fait ça. La clée gpg qui va bien est aussi ajoutée. Après il te suffit de faire un "yum install paquet_freshrpms", ou lancer pirut, etc...
> création de ses propres repository,
Très facile avec yum. C'est createrepo.
[admin@one yum]$ createrepo --help
createrepo [options] directory-of-packages
Options:
-u, --baseurl = optional base url location for all files
-o, --outputdir = optional directory to output to
-x, --exclude = files globs to exclude, can be specified multiple times
-q, --quiet = run quietly
-g, --groupfile to point to for group information
( relative to directory-of-packages)
-v, --verbose = run verbosely
-c, --cachedir = specify which dir to use for the checksum cache
-U, --update-info-location = acquire package update metadata
-h, --help = show this help
-V, --version = output version
-p, --pretty = output xml files in pretty format.
[admin@one yum]$
Il y a aussi repoview. Il fait une version html d'un dépôt pour naviger dessus :
[admin@one yum]$ repoview --help
usage: repoview [options] repodir
options:
--version show program's version number and exit
-h, --help show this help message and exit
-i IGNORE, --ignore-package=IGNORE
Optionally ignore this package -- can be a shell-style
glob. This is useful for excluding debuginfo packages,
e.g.: "-i *debuginfo* -i *doc*". The globbing will be
done against name-epoch-version-release, e.g.:
"foo-0-1.0-1"
-x XARCH, --exclude-arch=XARCH
Optionally exclude this arch. E.g.: "-x src -x ia64"
-k TEMPLATEDIR, --template-dir=TEMPLATEDIR
Use an alternative directory with kid templates
instead of the default: /usr/share/repoview/templates.
The template directory must contain four required
template files: index.kid, group.kid, package.kid,
rss.kid and the "layout" dir which will be copied into
the repoview directory
-t TITLE, --title=TITLE
Describe the repository in a few words. By default,
"RepoView" is used. E.g.: -t "Extras for Fedora Core 4
x86"
-l DTITLE, --title-deprecated=DTITLE
This option is deprecated. Please use -t.
-u URL, --url=URL Repository URL to use when generating the RSS feed.
E.g.: -u "http://fedoraproject.org/extras/4/i386".
Leaving it off will skip the rss feed generation
-f, --force Regenerate the pages even if the repomd checksum has
not changed
-q, --quiet Do not output anything except fatal errors.
[admin@one yum]$
> mode ligne de commande,
Pas de problème pour ça...
> relocation des packages (installé là plutot qu'ici),
Ça dépend du paquet. Il doit supporter "--prefix" de rpm. Si c'est le cas, yum le fait aussi. Fedora n'est pas fan de cette fonctionnalité.
Celà va de soit, yum supporte aussi chroot pour installer un système complet sur une partition vide (très utilisé par les utilitaires Xen).
> sauver un package (en refaire un rpm) avant de l'effacer/upgrader...
Up2date le faisait, yum ne le fait pas. Mieux, up2date stockait les opérations faitent et on pouvait revenir en arrière. Mais OK, yum ne le fait pas.
> Secundo comment sais-tu que yum est plus utilisé
Pour info, yum a aussi plein de plugin.
C'est "que" pour Fedora (Core et Extras). Ça n'inclus freshrpms, atrpms, etc...
[admin@one yum]$ repoquery --whatrequires --queryformat="%{NAME}\n" yum | sort | uniq
anaconda
kyum
mach
mock
pirut
plague-builder
pungi
repoview
system-config-kickstart
yum-allowdowngrade
yum-changelog
yum-downloadonly
yumex
yum-fastestmirror
yum-fedorakmod
yum-kernel-module
yum-priorities
yum-protectbase
yum-skip-broken
yum-tsflags
yum-updateonboot
yum-updatesd
yum-utils
yum-versionlock
Ajouter createrepo qui crée des dépôts mais n'est pas dépendant de yum (ce qui est normal).
Et il y a aussi yum-utils avec des utilitaires sympathique :
[admin@one yum]$ rpm -q -l yum-utils | grep bin
/usr/bin/package-cleanup
/usr/bin/repo-graph
/usr/bin/repo-rss
/usr/bin/repoclosure
/usr/bin/repomanage
/usr/bin/repoquery
/usr/bin/reposync
/usr/bin/repotrack
/usr/bin/yum-builddep
/usr/bin/yumdownloader
[admin@one yum]$
Pour info, yum supporte les plugins.
> Donc ce que tu affirmes est parfaitement faux, yum a du succès façon MS: personne n'ose d'autre solution
Pour Fedora il y a : up2date, apt4rpm, yum, smart.
Que propose Mandriva ? urpmi.
Il y a peut-être smart maintenant.
Pour ton info, Yum n'a pas été développé par Red Hat. La page projet de yum :
http://linux.duke.edu/projects/yum/
A l'origine Yum était fait pour Yellow Dog. Yum c'est imposé au près de Red Hat et Fedora car c'est le meilleur (ou le plus apprécié). Au début de Fedora, il y a eu des tonnes de discussion pour savoir s'il fallait abandonné up2date et par quoi le remplacer. Le débat était principalement autour de smart et Yum. Yum l'a emporté de peu.
Ton "yum a du succès façon MS", tu peux te le carrer dans le cul.
Quel alternative à urpmi a tenté Mandriva ? Rien.
> personne n'ose d'autre solution
Smart a été proposé et est dispo dans Fedora Extras depuis FC2 (peut-être FC1).
apt4rpm a été proposé et est dispo dans toutes les Fedora.
Yum a été proposé (au début il n'était que dans Fedora Extras).
Urpmi n'a jamais été proposé. Propose le si tu veux.
> primo : je connais yum
J'en doute très très très fort.
[^] # Re: No comment...
Posté par IsNotGood . En réponse au journal Choix d'un système de fichiers. Évalué à 1.
[^] # Re: No comment...
Posté par IsNotGood . En réponse au journal Choix d'un système de fichiers. Évalué à 6.
Mais qu'es-ce qui compte le plus ? Vitesse ou fiabilité ? Pour moi c'est la fiabilité.
J'ai jamais compris pourquoi les gens veulent autre chose qu'ext3 alors que ce FS roxe. Certe d'autres FS font mieux dans tel ou tel domaine. Mais ext3 a un fabuleux compromis fiabilité/performance/fonctionnalité.
[^] # Re: Ne pas se prendre la tête
Posté par IsNotGood . En réponse au journal Choix d'un système de fichiers. Évalué à 7.
Comme tout les FS...
> Il n'y a que pour certains cas "extrêmes" que l'usage d'un autre FS peut devenir intéressant
> Je pense notamment aux serveurs très fortement chargés
Là tu te trompes un peu. Le point fort d'ext3 n'est pas un usage Desktop, c'est en usage serveur avec forte charge qu'il donne toute sa mesure (lecture et écriture simultannées). C'est pour ça que Red Hat l'utilise. Pour un serveur de fichier ou base de donnée sous forte charge et sur un système multi-cpu, les autres FS se prennent une branlée. Et c'est aussi pour ça que Novell a laissé tomber ReiserFS.
Autre point positif d'ext3, il supporte tout sans accro : ACL, SeLinux, NFS, Smb, etc...
Les gros problèmes actuels d'ext3 sont la limite en taille (8 ou 16 To) et la durée des fsck. Ces problèmes seront corrigés avec ext4. Notes bien que ces problèmes ne consernent pas un usage courant/desktop. Mais ils sont tout en haut de la TODO list.
[^] # Re: enfin les postes de travail
Posté par IsNotGood . En réponse à la dépêche Linux en entreprise : deux nouveaux exemples de migration. Évalué à 3.
Un peu de sérieux. C'est une question à deux centimes. Les autres supportent Red Hat et Novell. Avec ça tu fais sans problème 80 % des entreprises.
Et si ça tourne sur Red Hat (ou Novell) c'est trois rien pour que ça tourne avec l'autre.
> J'espere que les gens de PSA comptent mettre la pression sur DS pour ce genre de possibilité CatiaV5 sous LINUX ( une sorte de reve LOL) ce serons les seuls qui y arriverons, mais ils sont deja tellement impliqué dedans qu'ilns n'ont eu aussi dejà presque plus le choix :(
Mais oui ils ont le choix. Je ne doute pas qu'il y aura Catia sous Linux. PSA le demandera, j'en suis convaincu. C'est une question de temps maintenant.
Linux va devenir le standard Unix. Il n'y a que Solaris qui peut le contester.
J'ai bossé chez PSA, et ils seront très heureux d'avoir un "vrai" standard Unix. Si de plus cet Unix est utilisé en Desktop, c'est que du bonheur pour eux. Par contre, et pour avoir bossé chez PSA, ça peut être long, très long (ce qui se comprend).
[^] # Re: Autre temps, autre moeurs...
Posté par IsNotGood . En réponse à la dépêche Linux en entreprise : deux nouveaux exemples de migration. Évalué à 2.
C'est Yast je crois. Du moins un module de Yast.
[^] # Re: Autre temps, autre moeurs...
Posté par IsNotGood . En réponse à la dépêche Linux en entreprise : deux nouveaux exemples de migration. Évalué à 0.
Si tu connaissais Yum, tu comprendrais très vite.
Le seul reproche sérieux qu'on peut faire à Yum, c'est de ne pas supporter les périphériques amovibles (CD, DVD). Mais c'est un choix qui a ses raisons et que je ne vais pas étaler.
Regardes du côté de urpmi. C'est compliqué, il y a des howto de 50 pages, il faut mettre à jour le cache avant de lancer la mise à jour, il y a 40 commandes, ça ne passe pas par librpm pour résoudre les dépendances, etc...
Tout ce qui y a connaitre avec yum c'est "yum update" et "yum install mon_programme".
En plus urpmi est écrit en Perl...
Yum, même récent à côté de urpmi, est déjà plus utilisé par les développeurs. On ne compte plus les utilitaires qui utilisent Yum. Yum est partout dans Fedora. Dans l'installeur, dans le serveur qui vérifie s'il y a des mises à jours, les download et l'indique sur le bureau, dans l'applet qui fait les mises à jours, dans system-config-package, etc...
Pour RHEL 5 (la distribution qui fait de l'argent chez Red Hat), RHEL va passer à Yum. Il n'y aura plus de trace de up2date.
Une erreur qu'a fait Mandriva (encore une...), c'est de ne pas utiliser smart alors qu'en plus Mandriva a racheté Conectiva (dont les développeurs de smart).
Fedora/Red Hat ose passer de up2date à yum. Mandrake reste accroché à urpmi qui est sans avenir.
Entre Yum et smart, il y a de quoi hésiter. Entre Yum et urpmi, il n'y a pas de quoi hésiter.
Il existe smart pour Fedora et apt pour Fedora car des gens les veulent. C'est dans Fedora Extras. Il n'y pas urpmi pour Fedora car personne en veut. Il n'y a que urpmi pour Mandriva.
[^] # Re: Autre temps, autre moeurs...
Posté par IsNotGood . En réponse à la dépêche Linux en entreprise : deux nouveaux exemples de migration. Évalué à 3.
Non. Le manque de développeur est une conséquence.
Mandriva n'a pas de business plan clair. Ils veulent tout faire (serveur, desktop, gadget, etc). En voulant tout faire, ils font tout mal. Je n'en déduit pas que les développeurs de Mandriva sont plus con qu'ailleurs. Mais simplement que ce n'est pas possible avec leur moyen. Même Red Hat qui a des moyens sans commune mesure avec Mandriva ne se disperse pas comme le fait Mandriva.
> de ne pas voir assez de développeurs travaillant sur le bas-niveau
Mais veulent-ils le faire ?
J'en doute et de doute manière ils ne sont pas en position pour le faire. Ils ont déjà trop à faire pour sortir une distribution régulièrement (la mandriva libre, la discover, la machine, la usb, la corporate server, etc...).
> Vue la politique de développement de Mandriva, (pas l' économique) il est très clair que si elle en avait les moyens, elle le ferait sans hésiter.
J'en doute toujours. Mandrake avait les moyens il y a quelques années. Mais qu'on-t-il fait ? Ben ils ont investit dans le e-learning. Une catastrophe.
> Un exemple parmi d' autres : le travail fait sur nepomuk
Un bon point pour Mandriva. Ils ont aussi bossé sur l'impression. Mais compare avec Red hat et Novell. Même en rapportant au nombre de salarié, c'est ridicule.
> Tu retombes sur la "mentalité française" dont tu disais partager mon agacement à son encontre au début du post.
Tu tombes dans la mentalité : Mandriva est génial et tout ce qui lui arrive est une puissante injustice.
Mandriva a largement eu sa chance, a eu un support de la part de la communauté énorme. On ne compte pas le nombre de personne qui ont acheté des boites ou se sont abonnés au club Mandrake uniquement pour supporter Mandrake car ils croyaient en Mandrake. Ils n'ont pas eu tord de tenter d'aider Mandrake.
Regardes les faits. Mandrake a eu une popularité et un soutient énorme en France. Je ne crois pas que Mandrake ait eu à souffrir d'une certaine "mentalité française" que tu décris. Loins de là.
[^] # Re: MIT
Posté par IsNotGood . En réponse au sondage La licence que je préfère utiliser pour mes logiciels est. Évalué à 6.
Les incompatibilités c'est dans les deux sens. Dans les grandes ligne la gauche est incompatible avec la droite et vice versa. Le libre est incompatible avec le propriétaire et vice versa. Que la GPL soit incompatible avec les licences propriétaires (et vice versa) n'en est qu'une conséquence et non la cause.
Supprime l'incompatibilité de la GPL avec les licences propriétaires, et il n'y a plus de GPL, il n'y a pas de code qui reste libre, il y a du code qui peut être libre ou propriétaire. Mon code, je veux qu'il reste libre, toujours, pour que les utilisateurs soit toujours libres.
> je préfère laisser les gens libres
C'est très naïf.
Libre à tout le monde de déposer de brevets, d'avoir des EULA à la con, etc.
C'est ça laisser les gens libres ? Une toute petite minorité profite des brevets, etc de la "liberté" BSD, et une grande majorité est "enchainée".
Un dictateur a besoin de beaucoup de liberté, mais il ne défend pas la liberté. Microsoft veut un maximum de liberté (donc MS adore la BSD). Mais ce n'est pas pour la liberté des utilisatieurs.
[^] # Re: 3e raison
Posté par IsNotGood . En réponse au journal Solaris et java sous GPL3, ça se confirme.... Évalué à 4.
Mais qui aurait dit il y a quelques années que java et solaris serait sous GPL ?
Peut-être que dans 5 ans les brevets vont perdre en importance.
> du fait de la provenance du code de multiples développeurs à qui il faudrait demander la permission pour changer la licence
Si un concensus sort pour passer Linux en GPL v3 (ce n'est pas le cas aujourd'hui) les quelques fichiers qui posent problème seront virés. Ça c'est déjà vu.
[^] # Re: 3e raison
Posté par IsNotGood . En réponse au journal Solaris et java sous GPL3, ça se confirme.... Évalué à 3.
Linux n'a qu'une licence. La GPL v2 satisfait Linux *aujourd'hui*.
Peut-être que demain Linux passera en GPL v3.
> À part cela, c'est une excellente nouvelle \o/
Clairement.
[^] # Re: licenses
Posté par IsNotGood . En réponse à la dépêche FreeBSD utilise les pilotes Linux. Évalué à 1.
Merci. Mais herve_02 a raison. Relis le (lentement et tous les mots).
> Donc c'est bien ce que je dis la situation est la même que pour la fourniture de gcc
Non.
[^] # Re: licenses
Posté par IsNotGood . En réponse à la dépêche FreeBSD utilise les pilotes Linux. Évalué à -2.
Ça, après avoir regardé dans le détail, ne doit pas poser de problème.
Mais herve_02, qui se fait moinser injustement, dit :
- "Si ils doivent modifier le makefile pour les compiler sous freeebsd, il n'ont pas le droit de les redistribuer (ensemble et compilés)"
herve_02 a raison. Le système de score dlfp a encore tord...
[^] # Re: licenses
Posté par IsNotGood . En réponse à la dépêche FreeBSD utilise les pilotes Linux. Évalué à 3.
Un source sous BSD dans un projet GPL a sa licence toujours respecté.
L'inverse est faut. Si un projet est sous BSD, alors on peut le distribuer sans les sources. Si est fichier de ce projet est source GPL, on viole la GPL.
[^] # Re: licenses
Posté par IsNotGood . En réponse à la dépêche FreeBSD utilise les pilotes Linux. Évalué à 3.
Rien à voir. Gcc est sous GPL qu'il soit fournit pas FreeBSD ou Linux. Evites de glisser dans le FUD.
gcc n'est pas un travail dérivé de Linux. Les drivers de Linux le sont (en fait ça dépend, Linus n'a pas exactement la même interprétation que RMS).
Si un drivers est sous GPL, il ne peut être mis dans le noyau FreeBSD et redistribué. La licence GPL du driver est en contradiction avec la licence BSD et vice versa.
Par contre le driver peut être délivré séparément.
Mais beaucoup de driver Linux sont sous double licence BSD-GPL.
[^] # Re: Autre temps, autre moeurs...
Posté par IsNotGood . En réponse à la dépêche Linux en entreprise : deux nouveaux exemples de migration. Évalué à -4.
Car avant c'était mieux ? Si c'était si merveilleux que ça, pourquoi Mandriva est allé le chercher ?
> Tout s"est passé comme si il avait été nommé (par les investissers US) pour couler la boite.
Ça frise l'anti-américanisme primaire.
Qui a demandé ces investisseurs ? Qui a accèpté ces capitaux ? C'est Mandrake et personne d'autre.
D'ailleurs sans ses investisseurs Mandrake serait peut-être déjà mort.
[^] # Re: Autre temps, autre moeurs...
Posté par IsNotGood . En réponse à la dépêche Linux en entreprise : deux nouveaux exemples de migration. Évalué à 2.
J'ai dit que pour aujourd'hui (actuellement, ces dernières semaines/mois), j'étais mauvaise langue.
Je crois qu'il est urgent de tuer le débât dans l'oeuf.
[^] # Re: Autre temps, autre moeurs...
Posté par IsNotGood . En réponse à la dépêche Linux en entreprise : deux nouveaux exemples de migration. Évalué à 4.
Ubuntu, Linspire, etc tu veux dire ?
Il y a quoi en code dans Ubuntu qui vient de Mandriva ? Pas grand chose. Ubuntu, comme Mandriva, utilise beaucoup de code de Red Hat et Novell. Pas seulement du code dédié serveur mais aussi du code pour que ça "fonctionne out of the box".
Quelle a été la premier distribution qui "fonctionne out of the box" ?
Red Hat ou SuSE et pas Mandr(ake|iva). Red Hat/SuSE ont eu une interface graphique simple d'installation bien avant Mandrake.
Au début de Mandrake, Mandrake n'était qu'une Red Hat avec KDE en plus. Rien d'autre. Red Hat ne distribuait pas KDE a cause de la licence de QT (qui n'était pas GPL à l'époque). Ce n'est pas un reproche, c'est pour remettre dans le contexte.
Qu'es-ce qui permet d'avoir des choses qui marche "out of the box" ? Un drakebidule en perl de plus ?
USB est formidable dans la facilité d'usage. Maintenant quand on branche une clée USB, elle est montée illico. Si c'est un appareil photo, gphoto est lancé, etc... C'est grace à un drakebidule qu'on lance depuis mcc ? Ben non, c'est en codant au niveau du noyau, c'est en faisant dbus, c'est en faisant Hal, c'est en faisant gnome-volume-manager, etc. C'est des technologies comme ça dont a besoin Linux, pas d'un drakebidule de plus. Ces technologies sont difficiles à développée, mais c'est le chemin qu'il faut prendre. Un drakebidule c'est facile à faire, ça impressionne la galerie, mais c'est sans avenir.
Vaut-il mieux développer au niveau noyau/xorg pour que l'OS reconnaisse automatiquement une souris qu'elle soit sur un port USB ou PS/2 et ainsi qu'a l'installation on ne te demande rien à propos de la souris, ou faire un drakesouris qui te demande si ta souris est sur un port USB ou PS/2 ou serial ?
Avec stateless du projet Fedora, on arrive à installer Fedora sur n'importe quelle bécane sans le moindre clique. Dans un contexte entreprise la configuration software (et non hardware) est récupérée sur un serveur. En entreprise, on vient de te livrer une nouvelle bécane, et tout ce que tu as à faire c'est de la brancher. Tous les périphériques seront configurés à la volée sans intervention et la configuration logiciel correspondra a ton entreprise. Ça c'est du progres. Ceci dit stateless n'est pas encore terminé et c'est un boulot sur le long terme. Il fera ces début commercial avec RHEL5.
Où est Mandriva dans ces technologies qui compte vraiment ? Pratiquement null part.
Puis la facilité de Mandriva est vraiment discutable. Leur installateur a des tonnes de paneaux de configuration. Oui, de configuration et non pour l'installation. Red Hat/Fedora a le minimum et ne fait que de l'installation. Il peut y avoir de la configuration qu'en on veut être sur que l'utilisateur passe par une étape. Typiquement pour que l'utilisateur active le pare-feu.
Compares une installation de Fedora avec Mandriva, et ça va te sauter aux yeux.
Le défaut est tellement criant qu'il a fallu que Ubuntu fasse une installation simple pour raffler la mise. Et non, Ubuntu n'est pas basée sur Mandriva, n'a pas besoin des technologies made by Mandriva, pour arriver à ça.
Au niveau applicatif, qu'es-ce que Mandriva a développé et qui est utilisé aujourd'hui ? Ben presque rien.
> La "popularité" d'Opensuse, est vraiment, pour moi, issue d'un matraquage mediatique sur le web.
Pas en France en tout cas. Puis c'est récent, c'est depuis OpenSuse.
On peut aussi parler du matraquage mediatique sur le web de Mandrake.
> Et là, j'écris depuis Kubuntu Edgy ;-)
C'est presque un CQFD.
[^] # Re: Autre temps, autre moeurs...
Posté par IsNotGood . En réponse à la dépêche Linux en entreprise : deux nouveaux exemples de migration. Évalué à 7.
Pas sûr. Au début de Mandrake j'aurais dit oui. Aujourd'hui Mandriva doit maintenir ces outils de configurations spécifiques, doit bosser pour faire plein de version boite (ce qu'a arrêté de faire depuis longtemps Red Hat... car c'était cher et sans plus-value significative pour l'utilisateur), doit s'occuper de son service club compliqué à plusieurs niveaux d'accès, modérer les forums club, etc... Vu la taille de Mandriva, il ne reste plus grand monde de disponible pour contribuer au libre. Aujourd'hui c'est la faute à personne. C'est l'accumulation de l'historique de Mandriva.
Un exemple. Alors que Red Hat poussait Fedora et un cycle de 6 mois plus synchronisé avec les développements upstreams, Mandriva "pissait" contre vent avec un cycle d'un an. Aujourd'hui Mandriva est revenu en arrière. Mais combien de contributeur ont quitté le navire ? Pas beaucoup je pense. Mais combien de temps ça va prendre pour les retrouver ? Beaucoup.
> Mandriva vient de commencer à participer à GCC, par le biais d' un projet européen. Et l' équipe historique de GCC voit cela d' un oeil pragmatique me semble t i
Encore une fois Mandriva "pisse" contre le vent. Regardes ce que fait Red Hat/Sun/Novell, etc...
Ils ne passent plus d'accord avec telle ou telle boite sur une projet de recherche.
Je prend l'exemple de Fedora car je le connais un peu. Red Hat met son équipe de développement sur la place public (c'est Fedora). Si quelqu'un veut participer, il se présente, il présente le projet, il montre du code, et si ça branche les développeurs de Fedora/Red Hat, ben ils suivent le wagon. Red Hat a dit que depuis Fedora (évidemment c'est arrivé petit à petit), il y a de plus en plus de développement "officieux" qui se font via Fedora. Dell/etc participent à Fedora. Avant Dell/etc ne participaient que pour le "produit" Red Hat (c'est-à-dire RHEL). Mais maintenant quand Dell veut bosser avec Red Hat, quand Dell veut qu'une évolution soit dans RHEL, il n'envoie pas un commercial pour négocié un contrat. Dell dit à ses devéloppeurs de bosser et de communiquer avec Fedora (ou d'autres distributions, ou les projets upstreams). Exemple, c'est Dell qui vérifie les dépendances "BuildRequires" pour Fedora ! Fedora n'a rien demandé, il n'y a pas eu d'accord entre Red Hat et Dell pour ça. Dell fait des choses, si c'est interessant Fedora participe, si ça aboutit c'est dans Fedora (et dans toutes autres distributions ou projet upstream évidemment). Et voilà :-)
Avec ce nouveau modèle, on ne sait plus qui a fait quoi. Et alors ? Dell a ce qu'il veut. Fedora a des contributions. Tout est ouvert et ceux les mieux à même de participer participent. Que du bonheur...
Cette initiative européen doit être saluée évidemment. Il faut encourager Mandriva pour ce projet. Mais bon, c'est comme souvent, Mandriva a un train de retard. Les communications de ce projet devraient avoir lui sur les mailing gcc, avec les spécialistes de gcc qu'ils viennent de Red Hat ou Novell ou Mandriva et pas dans un coin. Il est claire que ce projet aura peu d'aide de la part de gcc s'il reste dans son coin. C'est ce projet et gcc qui vont en patir.
[^] # Re: Autre temps, autre moeurs...
Posté par IsNotGood . En réponse à la dépêche Linux en entreprise : deux nouveaux exemples de migration. Évalué à 3.
C'est bien vrai.
> les français n' aiment pas les boites françaises,
Certe, je n'aime pas Mandrake, mais j'achete en général du français. Ma bagnole est française, etc... Pas tout évidemment, mais j'essaie d'acheter français même si ça me coute quelques ¤ de plus. Et en général je ne le regrette pas.
> et dès qu' il s' agit de les soutenir, y a pas grand monde de chez nous.
Mandrake est une mauvaise boite. Ce n'est que mon avis. Et contribuer/soutenir une mauvaise boite ne m'emballe pas.
> Je me demande comment Novell peut encore avoir des contributeurs externes tellement ils se moquent des LL
Il y a un accro avec Novell et c'est son accord avec MS. Un accro grave. Et d'ailleur ça lui a couté des développeurs qui sont partit (Novell l'a reconnu).
> Mandriva avec bien moins de moyens, travaille bien plus pour le LL de manière générale.
Les contributions au libre de Novell sont sans commune mesure avec Mandriva. Vérifies toi même.
> Nous avons en France parmi les meilleurs et les plus gros programmeurs. Et en europe, c' est le grand bonheur.
Heureusement RedHat/Novell paye beaucoup de développeurs européen. Pour en citer un, citons Alan Cox.
> Mandriva apporte aux LL
Franchement, regardes ce qu'a apporté Mandriva au libre. Il reste rien ou presque.
Novell c'est alsa (énorme comme contribution), c'est (voire c'était) KDE (énorme), la libc (énorme), etc, etc...
RedHat c'est NPTL, ext3, le plus gros contributeur à Linux/gcc/libc/binutils, etc, etc... Red Hat c'est aussi du pognon pour le "lobby" anti-brevet.
Red Hat et Novell ont fait des choses qui restent et sont utilisées dans la durée.
Mandriva il n'y a pratiquement rien.
Si Mandr(ake|iva) n'existait pas, il n'y aurait pratiquement aucune différence aujourd'hui. Si Red Hat ou Novell n'existait pas, la différence serait énorme. Pas d'alsa, pas de NPTL, pas de etc...
[^] # Re: Accord
Posté par IsNotGood . En réponse à la dépêche Linux en entreprise : deux nouveaux exemples de migration. Évalué à 3.
Ce qui a me semble-t-il pesé, est que Novell et SuSE ont une longue tradition de proposer des solutions de cohabitation Windows/Linux. Ce n'est pas le cas de Red Hat qui est concentré sur Linux/Unix. Red Hat a beaucoup de succès dans les serveurs (principalement migration Unix vers Linux) et c'est peu intéressé au desktop. Bien qu'il ne l'ignore pas (ses contributions dans Gtk/Gnome/Mozilla le prouve), ce n'est pas *aujourd'hui* leur cible commerciale (ça devrait changer avec RHEL5 qui sort début mars). Peugeot migre principalement des Desktops et Novell/SuSE a probablement plus d'expertise dans ce domaine. J'imagine que c'est ça qui a fait que Novell a gagné le marché. Bravo.
[^] # Re: Autre temps, autre moeurs...
Posté par IsNotGood . En réponse à la dépêche Linux en entreprise : deux nouveaux exemples de migration. Évalué à 6.
Parceque ce n'est pas Mandr(ake|iva).
Mais aujourd'hui je suis mauvaise langue.
Red Hat (probablement idem pour Novell mais je n'ai pas vérifié) a des tonnes de "success story" :
http://www.redhat.com/rhel/informationcenter/successstories/(...)
Mais comme c'est Red Hat (ou Novell), ça ne passe pas ici. Aujourd'hui c'est passé car c'est Peugeot (avec un volume de migration exceptionnel pour Linux, il faut bien le reconnaitre).
Un truc qui pourrait faire une news en première page :
http://www.redhat.com/promo/vendor/?sc_cid=bcm_bnrhpciovalue(...)
Red Hat a pour la troisième année consécutive (!) été considéré comme n°1 "most valuable software vendor" (comment traduire ça ?).
Ce qui montre que les entreprises lorsqu'elles choisissent Linux sont très satisfaites. Que le choix de Linux n'est pas intéressant "idéologiquement", mais aussi financièrement et en terme de service pour une entreprise. Et du service de qualité, Red Hat prouve qu'il existe, peu exister avec du logiciel libre. Contrairement à ce que veut nous faire croire certains FUD.
> La seule chose que je trouve dommage, c'est qu'une entreprise française ou même européenne n'ait pas été choisie.
La seule chose qui est dommage est que Mandr(ake|iva) est HYPRA mauvais et point barre. Ça fait depuis des années qu'ils n'ont pas été foutu d'avoir un "business plan" correct, qu'ils foutent de l'argent en l'aire, etc... alors que Linux est en pleine expansion. Depuis des années Red Hat a une croissance de plus de 30% par an ! Et les profits suivent et Red Hat ne manquent pas d'idée pour les réinvestir dans la durée. Par exemple en achetant Sistina, en faisant Red Hat Network, Fedora, OLPC, stateless et maintenant avec JBoss même si actuellement il ne font pas de profit avec ce dernier. Mais à moyen terme ça va changer.
Red Hat (mais aussi Novell) place ses pions sur la durée. Mandr(ake|iva) fait des coups d'esbrouffe.
Aujourd'hui je ne vois pas comment Mandriva ne pourra pas être étouffé par Red Hat et Novell.
Mandrake avait une place de choix au début de Linux et avait des opportunités formidables. Presque tout a été gaché. Je crois que Mandriva est condamné à être un acteur mineur du libre.
Je n'aime pas Mandr(ake|iva), mais ça fait chier de voir que l'Europe n'a pas une boite en mesure de concurrencer les deux gros Red Hat/Novell alors que l'Europe est peut-être le plus gros contributeur au libre et ne manque pas de têtes bien faites.
Ça me fait chié, mais je n'ai pas non plus envis de supporter une boite à la con.
[^] # Re: Ubuntu / Debian, une question de philosophie
Posté par IsNotGood . En réponse au journal CQFD. Évalué à 3.
Par rapport à ma man page gcc dont tu n'as pas accès, il faut vraiment s'interroger.
C'est respecter le projet gcc que de ne pas fournir la doc ?
Et tout ça pour quoi ?
Car Debian ne veut pas respecter une petite clause qui concerne 0,01 % du la doc.
C'est ridicule.
Enfin, la FSF est mieux placé pour dire ce qui est ou non du logiciel libre ou dans "l'esprit" du logiciel libre. La GFDL est libre (ou au moins à 99,99 %) mais Debian veut la "diaboliser" et fait peu cas des gens qui écrivent de la doc bénévolement, une doc libre au sens de la FSF.
Franchement : honte à Debian.
La GFDL n'a jamais posée de problème à personne. Il y a que Debian qui casse les couilles en voulant se la péter.
[^] # Re: Ubuntu / Debian, une question de philosophie
Posté par IsNotGood . En réponse au journal CQFD. Évalué à 4.
T'es venu faire du buzz autour de BSD, Slack ou Gentoo ?
[^] # Re: Ubuntu / Debian, une question de philosophie
Posté par IsNotGood . En réponse au journal CQFD. Évalué à 2.
Certes, c'est seulement mon impression et ça peut changer.
Mais exemple : http://desktoplinux.com/news/NS7103672739.html
Et où en est l'adoption de DCC (Debian Core Consorcium) ?
> Debian est une distribution bien en vie : contrairement à Ubuntu qui a une majorité d'utilisateurs où la contribution se limitera à des howto dans des wiki,
Pertinant.
> Des trucs comme ça ne se voient pas dans Fedora Extras où les packages sont bumpés en version quand celà est nécessaire
Étant un utilisateur de Fedora depuis ses débuts, je dois dire que tu aventures un peu. De plus, tout ensemble important de logiciel (ce qui est le cas d'une distribution) peut toujours avoir un bug (et en général en possède plusieurs).
Donc ton exemple avec F-spot est un peu léger. De même, je ne vais pas m'amuser à critiquer Ubuntu car une fois ils ont livré un Xorg inexploitable. Ce type de truc peut arriver à tout le monde d'autant plus lorsque c'est une distribution "communautaire".