Mettre un antivirus pour Linux (je ne parle pas des antivirus sous Linux qui traitent les virus de Windows) est une abération. A moins que MS porte IE et MS-Office sous Linux et que Mandrake en fasse de la pub :-)
> Mais si de plus en plus d'utilisateurs de Debian passent chez Mdk c'est qu'il doit y avoir une raison j'imagine.
Où tu as vu ça ?
Selon le dernier bulletin financier de Mandrake, les ventes ont stagné entre 2001 et 2002 (même chiffre d'affaire). Sur counter.li.org , debian est passé devant Mandrake.
> les publicités seront pour des produits ou services qu'il y a un sens à associer à GNU/Linux.
De la pub pour SuSE dans Mandrake !
C'était pour rire.
Sachant que Mandrake ne va pas faire de la pub pour du support offert par d'autres sociétés (ça fait parti de leur gagne pain), à part faire de la pub pour les bouquins, les FAI ou les produits payants et généralement propriétaire ça va être limité.
Dans un sens c'est bien (moins de pub) et dans un autre sens c'est pas bien (moins de pognon).
Pour la partie "sentimental", je veux dire que beaucoup d'utilisateurs de Mandrake non-Français auront beaucoup moins de scrupule de passer de Mandrake à autre chose s'ils veulent une distribution gratuite.
Beaucoup ne vont pas se dire :
- "C'est pour la survie de Mandrake que j'aime bien donc j'accepte."
mais plutôt :
- "fait chié cette pub, je vais regarder ailleur."
Ceux qui installent pour la première foi une Mandrake vont être "calmé" avant même d'avoir gouté aux caractéristiques de la Mandrake.
Or l'un des problèmes de Mandrake actuellement c'est qu'il n'augmente pas la distribution de leur OS alors que le marché augmente. Il semble même que Debian soit passé devant eux. L'ajout de la pub ne va pas arranger ce point même si ça permet à Mandrake de survivre.
Si ce point ne s'améliore pas, à long terme ça va être dure. La valeur financière d'une pub dépendent énormément de la taille du public touché.
Je ne dis pas que plus personne va installer Mandrake mais que cette décision ne va pas dans le bon sens (selon moi).
> mais ils savent ce qu'ils font, chez MD; faisons leur confiance.
Comme pour le e-learning ?
> Toutefois, ça me rappelle une periode ou (si je me souviens bien ), le premier telechargement sur le site été payant, et les suivants gratuits. mais ça n'a pas duré. :-)
Tu disais "faisons leur confiance" juste au-dessus.
Mandrake fait une connerie.
A court terme ça peut faire rentrer du pognon mais à long terme je ne crois pas.
On est en France et MandrakeSoft est une boîte Française et donc la perception Française n'est pas partagée dans la reste du monde. Or Mandrake ne peut pas vivre quand s'appuyant sur le sentimentalisme du marché Français.
Dans les autres pays si Mandrake disparait ça ne va pas créer le même émois qu'ici.
Mandrake ne contribue principalement qu'à la distribution Mandrake et très peu à d'autres projets (kernel, gcc, gnome, kde, etc...). Les outils dédiés à la distribution (installeur et drake*) ne sont utilisés que dans la Mandrake.
Désolé d'être brutale mais la perte de Mandrake ne sera pas un grosse perte pour le logiciel libre.
Si Mandrake disparait ça indiquera uniquement que faire une distribution profidable est difficile.
Les gens (la grande majorité selon moi) ne sont pas motivés à installer une Mandrake pour subir de la pub s'il ne sont pas affectivement attachés à Mandrake alors qu'il existe d'autres distributions gratuites et sans pub qui rendent le même service.
De plus la communauté des développeurs/testeurs ne va pas apprécier. Installer une distribution ou une beta (même sans pub) pour faire des développements/tests gratuits pour une distribution qui fait de la pub à d'autres sociétés (qui ne seront pas forcément liées au logiciel libre), faut être motivé.
Dans ceux qui maintiennent un mirror de mandrake il y en a beaucoup qui vont arrêter. Investir de la bande passante et de la place disque pour diffuser gratuitement une distribution qui fait de la pub ... la pilule va être dure à avaler.
Ceux qui avaient une raison "morale" d'être dans MandrakeClub même s'ils n'utilisaient pas le service ne vont plus s'inscrire.
Beaucoup vont arrêter de promouvoir une distribution qui fait de la pub. Je pense notament aux écoles/universités et peut-être les LUG durant les install-party.
La confiance de la communauté Mandrake envers Mandrake va encore diminuer. Beaucoup on mis la main à la poche pour renflouer les caisses après leur "connerie" e-learning qui n'a rien à voir avec le LL et maintenant il faut encore payer ou subir de la pub.
Idem pour la communauté LL qui n'a pas toujours apprécié la double licences de la solution firewall ou la solution cluster qui fait la "promotion" du compilo d'intel.
Mandrake a raté le marché des entreprises et n'a plus "que" le marché de la communauté et des ordinateurs personnels. Or la communauté ne va pas faire de la pub ou s'investir pour une distribution qui fait de la pub pour coca-cola, les tampons always, ou MacDo.
Maintenant Mandrake doit assumer tout seul comme le fait SuSE (qui est dans les entreprise). Bonne chance.
> on n'en parle pas assez mais la nouvelle politique de Red Hat concernant l'utilisation de ses marques et logo mériterait qu'on s'y intéresse vraiment
Ça n'a rien de nouveau.
> tellement elle est restrictive
Tu ne peux pas vendre une redhat avec les logos. C'est ça la restriction. Tu ne peux que la distribuer gratuitement. Et ça ne conserne que deux paquets. On trouve facilement des distributions basées sur RedHat a prix cassé sans ces deux paquets.
Google n'a pas payé Mozilla/Galeon/Firebird pour avoir un lien vers leur site.
C'est un chois libre de Mozilla/Galeon/Firebird.
Plus de lien vers Google dans la Mandrake si Google ne paie pas ?
La "nouvelle" beta est sortie fin juillet.
La beta2 de la RH10 sortira probablement vers le 15 septembre en même temps que la mise en ligne du nouveau http://rhl.redhat.com/(...) .
> Les developeurs de la mailing liste disait attendait la sortie de Gnome 2.4 .
Ils n'ont pas attendu la sortie de gnome 2.4 . D'ailleur gnome 2.4 (à 98 %) avec epiphany 1.0 est déjà dans rawhide. Par contre je crois que la sortie finale est repoussée vers fin octobre à cause de l'intégration de gnome 2.4 qui n'était pas initialement prévu pour la RH10.
> Ce qui sous Gentoo correspond par définition à la notion de paquet virtuel (genre si on a besoin d'un driver alsa ("virtual/alsa"), on peut se satisfaire soit d'un kernel 2.5/6, soit du driver pour les 2.4).
Pour en revenir au librairies, si le binaire définit les librairies qu'il a besoin, il vaut mieux avoir un système automatique pour détecter les dépendances avec les librairies que de faire ça à la main. Mais puisque ça te plait, tu peux faire des paquets avec :
requires|provide : "virtual/alsa".
Mais "virtual/alsa" ne dit pas que le paquet ne peut marché d'avec un Linux > 2.4.17 ou < 2.4.21 car une api a changé ou qu'il faut que les fontionnalité real-time soient disponibles ou plus simplement que le module soundcore soit présent. Seulement "virtual/alsa" est de la gestion de dépendance à la petite semaine.
Puis pour les services rendus par plusieurs paquets il y a aussi des facilités virtuels.
exemple :
$ yum provides ftpserver
Available package: vsftpd proftpd wu-ftpd provides ftpserver
> Enfin si, je sais plus si rpm le fait, ou le faisais à une époque lointaine en tout cas, ou si c'est urpmi qui le rajoute
C'est rpm qui le fait et non urpmi/etc. Par rapport à urpmi/apt/yum , rpm est un outil bas niveau et ne fait pas de recherche de paquet pour respecter les dépendances (c'est le boulot d'apt/urpmi/...). Par contre si les dépendances ne sont pas respectées, l'installation/mise_à_jour est refusée par rpm. C'est à urpmi/apt/yum de rechercher les bons paquets suivant des critères retourné par rpm et de les proposer à rpm qui fait tous les contrôles et l'installation (ce que ne fait pas urpmi/apt/...). Ainsi un "yum remove gtk+" fera un "rpm -e --test gtk+" pour connaitre les paquets qu'il faut desinstaller pour supprimer gtk+. (question : il se passe quoi si tu demandes la suppression de gtk+ sur une gentoo ?)
Il faut noter qu'urpmi ou yum sont des petits projets par rapport à rpm. rpm est 20 à 30 fois plus gros que yum ou urpmi qui utilise rpm alors que les gens n'ont d'yeux que pour urpmi/yum/... C'est les facilités de rpm qui permettent ça. Yum ou urpmi, des équivants d'apt mais dédiés rpm, font dans les 5 000 lignes de code seulement.
> Je sais pas dans le monde .rpm, mais dans le monde .deb c'était plutôt ce qu'on appelait des meta-paquets.
Dans la pratique, c'est peu utilisé avec rpm :-). Mais c'est présent (voir plus haut).
Puis que "meta-paquet" ça te plais, il te suffis de faire un paquet vide avec uniquement des "require: ..." et t'as un "meta-paquet".
> Franchement, je préfère de loin l'abstraction des virtuals (tu fait comment avec un nom de fichier pour dire: un codec divx ?)
Si c'est un librairie, tu ne fais rien.
Si la detection automatique n'est pas satisfesante (par exemple plusieurs nom de librairie pour la même fonctionnalité) tu fais une dépendance "virtuel"
"require : codec_divx >= 4".
Un paquet qui fourni cette fonctionnalité a par exemple :
"provide : codec_divx = 4.1".
Tous les paquets rpm on la dépendance vituelle : "provide : %{name} = %{version}"
Tu peux en ajouter autant que tu veux.
Je vois pas pourquoi tu insiste sur le "virtuel".
rpm detecte automatiquement s'il faut libc.so.6(GLIBC_2.3) ou libc.so.6(GLIBC_2.1.3) . Ça n'a rien de virtuel et ça évite bien des conneries. Maintenir en "virtuel" les dépendances avec la librairie C est un véritable enfer. Ma librairie C fournit la comptabilité avec 15 (!) versions (2.0 à 2.3.3). Certains paquets ont besoin de la 2.1.3 d'autres de la 2.3 etc... rpm contrôle tout automatiquement. J'ai vraiment pas envis de renseigner ces informations à main.
> Bah manquerai plus que l'install d'un paquet t'écrase ta config existante? Sérieux, c'est encore vraiment la base.
Tu ne comprends pas. Si un fichier de configuration est déréférences dans la base rpm le fichier est renommé toto.rpmsave (s'il est modifié par rapport à la version de référence). Si un fichier de conf peut-être écrasé il est renommé toto.rpmsave et il y a des options pour ne pas toucher au fichier de config (les nouveaux sont nommés toto.newrpm). Il y a aucun problème avec ça.
Par contre, lorsque rpm ne supportait la gestion des configurations, passer de ppp à ppp_ng (c'est un paquet différent) alors que c'est le même format de fichiers de configuration, aurait créé des .rpmsave (ou .newrpm). Maintenant ce n'est plus le cas.
> C'est merveilleux tellement c'est aller loin contre le bon sens et la simplicité.
Recompilé c'est tellement plus "simple"...
> Cool, ça vous fait un USE flag. Aller, encore un petit effort, c'est presque ça.
Tu ne comprends pas. J'ai rien contre USE qui va "paramétrer" la compilation des paquets et c'est un dispositif très utile. Je parle de la gestion des dépendances. De ce que je comprends, USE n'a rien à voir avec la gestion des dépendances.
Pour rpm on pourrait définir un convention des facilités à utiliser pour compiler un paquet avec "--with qt" ou "--without qt". C'est courament fait.
Exemple :
$ rpm -i proftpd
[...]
Available rpmbuild rebuild options :
--with : ldap mysql postgres tls
$ rpm -i alsa
Available rpmbuild rebuild options :
--without : isapnp sequencer oss
You may also recompile for given cards only by calling rpmbuild with :
--define "cards card1,card2,card3"
(the default is "cards all")
You may also recompile for a given kernel version and arch with :
--define "kernel <uname -r output>"
(for example "kernel 2.4.20-9")
--target
Mais même avec un système pour "châpeauter" la contruction des rpm, ce n'est pas un système de gestion de dépendance. A moins que USE puisse te dire :
- "compilation/installation de KDE refusé car qt n'est pas disponible"
au-lieu de planter au milieu de la compilation.
> Ça va en faire des versions spécifiques à compiler pour RedHat
Je crois que tu n'as pas bien compris le système. D'une certain manière on peut dire que c'est pour avoir des espaces de paquet séparés et éviter les conflits. Imaginons que ximian utilisé un Epoch=12 par exemple, le paquet nommé toto chez redhat ne va pas interférer avec le paquet toto de de xiniam et quelque soit la version des paquets. Par exemple tu ne peux pas mettre à jour libtoto-1.0-1 de ximian par un libtoto-1.0-2 de redhat si le paquet toto réclame un 12:libtoto . Le "Epoch" est prioritaire. L'objectif n'est pas de compiler des 10 façons différentes le même paquet. Il y a d'autres mécanismes pour ça ("--define", "--with", "--without").
> > Rpm gère les paquets absolètes.
> Pur narcissisme.
Exemple concret. Apache fournit maintenant mod_dav alors qu'avant c'était un paquet séparé. Dans le paquet il y a :
Obsoletes: mod_dav
Le nouveau paquet apache est autorisé à supprimer mod_dav puisqu'il le fourni. Sinon rpm indique un conflit (il ne va pas desinstaller un paquet sans "authorisation") et il faut désinstaller mod_dav avant de mettre le nouveau apache.
C'est aussi utilisé pour changer de version de distribution. Si la distribution passe de wu-ftpd à proftpd, il y aura dans proftpd :
Obsoletes: wu-ftpd
wu-ftpd sera supprimé si proftpd est installé. Ce qui est normal si le distributeur ne veut plus supporter wu-ftpd.
C'est aussi grace à ça que les gens passent de Mandrake 9.0 à 9.1 ou redhat 8.0 à 9 sans tout réinstaller.
C'est toujours du "Pur narcissisme" pour toi ?
> Moi je suis sûr grâce à ton post que bientôt rpm aura rattrapé son retard sur apt.
C'est d'une "naïveté"... apt existe pour rpm. rpm n'est pas l'équivalent d'apt !
up2date ou urpmi ou yum sont des équivalents d'apt. L'équivalent de rpm dans le monde apt est dpkg.
> vrais paquets virtuels
Fait.
> héritage entre specs
???
> gestion explicite des masques de paquets
???
Tu parles peut-être encore de compilation alors que je parle de gestion de dépendance pour un système rpm qui n'est pas orienté source.
> mélange aisé de 3 niveaux de stabilité des paquets
Fait.
> système de merge des fichiers de conf
Fait, c'est les triggers du paquet qui le font. Du moins si le paquet est développé pour le faire.
> Mais il n'approche qu'à peine (et c'est bien normal, mauvais choix, mauvais résultats) la souplesse que peut offrir un système basé sur les sources ... blabla source compilation etc
rpm n'est pas fait pour faire une distribution orienté source. Comparer rpm à gentoo sur ce point n'a pas de sens.
Par contre il est possible de faire une surcouche à rpm pour faire une distribution orienté source. Les binaires stokent le nom du paquet src.rpm qui stockent ce qui est nécessaire pour la compilation qui est elle-même paramétrable via --define --with --without. Une sourcouche pour "piloter" tout ça est tout a fait envisagable.
Mais avec ça on reste loin de la possilité de faire ça depuis les sources :
$ yum install_build_from_source provides libgnomeui-2.so.0
ou
$ yum install_build_from_source provides /usr/X11R6/bin/xscreensaver-demo
Or ça marche avec les binaires et avec résolution des dépendances. A moins de tout mettre en dure (pas de detections automatiques) ça ne peut pas marcher avec les sources. Tout mettre en dure n'est pas une bonne solution si on ne veut pas système bordélique.
> Alors que franchement, sur une distrib à la redhat, c'est quoi la proportion d'utilisateurs qui ont un jour fait leur propre srpm ?
T'as prouvé ton ignorance complète sur rpm.
Si tu veux une distribution orienté source, reste sous Gentoo. Personne n'a dit que les distributions actuelles basées sur rpm étaient des distributions orientées source.
Si les .rpm et .deb sont sur la place depuis un moment, ce n'est pas un hazard et surement pas à cause de "mauvais choix" comme tu dis.
Mais quels "mauvais choix" ? Tu peux t'expliquer ?
Le "mauvais choix" de n'avoir pas mis la priorité sur les distribution orienté source ?
Réjouis toi alors. Ça garanti un succès fulgurant de gentoo. Mais pour quand ? Car la déferlante on ne la voit pas venir actuellement.
Le gain serait proche de 0, voire moins.
Le compilo d'intel a un avantage pour les calculs, en fait pour certain calcul.
Si tu projetes de transformer ta gentoo en noeud de calcul pour un cluster c'est peut-être intéressant.
> càd qu'il gère l'héritage des dépandances? Merveilleux.
> Ou alors il analyse le binaire pour déterminer quelles libs sont nécessaires... pas tellement utile non plus.
C'est utile. C'est la librairie avec son numéro de version qui définie la compatibilité et pas autre chose. Sinon c'est de la duplication d'info. En fesant ainsi, tu peux remmoner des paquets les fusionner, etc... Tout ce qui compte, c'est la facilité réellement fournie et non le nom du paquet. L'héritage est aussi utile car il permet de limiter les nombres de dépendances et ne pas tomber dans l'ingérable. Rpm peut aussi définir des dépendances virtuels (style require: kde) ou des dépendances sur des fichiers ou sur une configuration. Par exemple lors d'un passage de ppp à ppp_ng si ppp_ng utilise config(ppp > 2) qui est déjà fourni par ppp-2.5 et que tu mets à jours, tes fichiers de configuration seront conservés. En fait le système de génération des dépendances utilise des plugins et rien ne t'empêche de devopper de nouveaux plugins (par exemple sur les symboles fournis par le noyau pour vérifier si un module noyau peut-être installé et marchera). Il y a quelques mois un plugins pour gérer les dépendances perl a été ajouté. Il y a un plugin pour prelink, ainsi rpm peut vérifier un binaires même s'il a été modifié par prelink.
rpm gère aussi les branches de paquets. T'as un gnome-2.2.2 spécifique qui utilise un libgnome-2.2.2 spécifique incompatible avec la branche 2.2, si un gnome-2.2.3 "standard" sort, il n'écrasera pas ta version spécifique mais un gnome-2.2.3 avec tes spécificités (marqués par le tag Epoch) sera un candidat pour la mise à jours.
rpm gére aussi les mises à jours sur plusieurs paquets et non seulement sur un seul. C'est l'ensemble des paquets qui sera évalué pour une mise à jour ou une installation et ce n'est pas fait paquet par paquet. un "rpm -U ppp_ng" pourra remplacer ppp et pppoe. Un "rpm -U ppp_ng pppoe" peut être utilisé pour mettre à jour le paquet ppp alors qu'un "rpm -U ppp_ng" n'est pas suffisant. Rpm gère les paquets absolètes. Rpm offrira dans 1 ou 2 mois la possibilité d'annulé la dernière transaction d'installation/mise à jours (c'est un transaction car rpm fait l'opération sur plusieurs paquets qui forme un tout).
> Les SLOTs (aka possibilité de considérer plusieurs version d'un même soft comme étant des logiciels diffèrents à installer en paralèle (QT, GTK...)).
Comme rpm. S'installation en parallàle ne pause pas de problème. Du moins lorsqu'elle est prévus. C'est une pratique très courrante.
> Et pis, franchement, quand on "crois" juste; vaut mieux ne rien dire, surtout quand le sujet est trollogène.
Pour ma part, je ne vais pas installer une gentoo. Trop "prise de tête" sur certains aspects comme tu le sous-entends pour pas grand chose. Par contre si j'ai besoin d'un système qui prend peu de place j'y jeterai un coup d'oeil.
Je recompile beaucoup plus rarement les programmes qu'avant car ils sont maintenant livrés complets pour la majorité des usages. Et c'est tant mieux.
> et quand on compile un programme, il n'est pas pris en compte par le gestionnaire de package.
Les dépendances sont définies à la construction du paquet (à la compilation). De plus rpm fait la detection automatique des librairies utilisées (rpm -q --requires -p toto-1.0-1.i386.rpm => Requires glibc... automatiquement).
> A ce qu'on peut lire sur la Gentoo, elle semble plus intéressante à ce niveau là. Qu'en est-il ?
Pour la gestion des dépendances ? Non, je ne crois pas.
Les paquets ou iso sont signés avec gpg. Si tu modifies le fichier tu dois refaire la signature. Or comme tu ne peux pas refaire la signature car elle est faite avec une clée secrète + un mot de passe.
Si tu ne refait pas la signature, gpg te retourne :
gpg: MAUVAISE signature de ...
Lorsque tu utilises bittorrent pour récupérer une distribution, le fichier md5sum qui accompagne généralement les iso est signé par le distributeur et infalsifiable. A toi de vérifier.
> c'est un appel à réflexion pour savoir s'il est "normal" que la copie soit illégale
C'est plutôt se demander si c'est légal. Je parle à grande de "l'échange de fichier à large échelle".
> mais ça me choque assez de toujours voir des gens considérer comme admis qu'il ne doit pas être permis de copier de la musique.
Tu as trouvé quelqu'un ici qui remet en cause le "fair use" ?
> On est dans une situation ou la copie est possible sans coût, à très grande échelle. En pratique, la copie est possible, donc sans obstacle artificiel elle sera pratiquée. Si on doit décider qu'il faut l'interdire, de manière artificielle (donc avec une loi) comme c'est le cas actuellement, le minimum serait de dire pourquoi.
Pourquoi : pour le pognon.
Que la rentabilité de star-academy ne soit pas remise en cause par le piratage est pratiquement une évidence.
Par contre il y a d'autre domaine où c'est beaucoup moins évident. Par exemple l'industrie du cinéma ne roule pas toujours sur l'or. Dans l'industrie du jeux video il y a plein de boîte qui souffre, etc...
Si le fait que la copie soit d'un coût très faible, autorise à tout copier...
Le cinéma, la music, les jeux video, les logiciels ne vendent pas que le support mais aussi la réalisation, la pub, les déficites du dernier film, la promotion d'artistes qui finalement ne sont pas rentables, etc.
Si demain il est admis qu'il est normal d'avoir gratuitement ce qui a couté très chez (je pense notament au cinéma et aux jeux videos), beaucoup moins de gens vond acheter des DVD, jeux videos etc...
Si c'est parce que c'est trop cher, on peut accéder au cinéma ou aux jeux video à un faible coût :
- film -> télé ou location
- jeux video -> les jeux un peu vieux et toujours excellents
[^] # Re: Espaces publicitaires à vendre
Posté par Austin . En réponse à la dépêche Espaces publicitaires à vendre. Évalué à 1.
Exemple :
http://www.lindows.com/products_virussafe_whatis.php(...)
[^] # Re: Espaces publicitaires à vendre
Posté par Austin . En réponse à la dépêche Espaces publicitaires à vendre. Évalué à 2.
maston28 a raison.
Le lien http://www.linuxfrench.net/article.php?id_article=1297(...) est intéressant :
- "Cette publicité concernera un antivirus"
Mettre un antivirus pour Linux (je ne parle pas des antivirus sous Linux qui traitent les virus de Windows) est une abération. A moins que MS porte IE et MS-Office sous Linux et que Mandrake en fasse de la pub :-)
[^] # Re: Espaces publicitaires à vendre
Posté par Austin . En réponse à la dépêche Espaces publicitaires à vendre. Évalué à 1.
Où tu as vu ça ?
Selon le dernier bulletin financier de Mandrake, les ventes ont stagné entre 2001 et 2002 (même chiffre d'affaire). Sur counter.li.org , debian est passé devant Mandrake.
[^] # Re: Sortie de Kde 3.2 alpha 1
Posté par Austin . En réponse à la dépêche Sortie de Kde 3.2 alpha 1. Évalué à 4.
[^] # Re: Espaces publicitaires à vendre
Posté par Austin . En réponse à la dépêche Espaces publicitaires à vendre. Évalué à 1.
http://news.netcraft.com/archives/2003/08/16/debian_linux_distribut(...)
# Re: Espaces publicitaires à vendre
Posté par Austin . En réponse à la dépêche Espaces publicitaires à vendre. Évalué à 1.
De la pub pour SuSE dans Mandrake !
C'était pour rire.
Sachant que Mandrake ne va pas faire de la pub pour du support offert par d'autres sociétés (ça fait parti de leur gagne pain), à part faire de la pub pour les bouquins, les FAI ou les produits payants et généralement propriétaire ça va être limité.
Dans un sens c'est bien (moins de pub) et dans un autre sens c'est pas bien (moins de pognon).
[^] # Re: Espaces publicitaires à vendre
Posté par Austin . En réponse à la dépêche Espaces publicitaires à vendre. Évalué à 0.
Beaucoup ne vont pas se dire :
- "C'est pour la survie de Mandrake que j'aime bien donc j'accepte."
mais plutôt :
- "fait chié cette pub, je vais regarder ailleur."
Ceux qui installent pour la première foi une Mandrake vont être "calmé" avant même d'avoir gouté aux caractéristiques de la Mandrake.
Or l'un des problèmes de Mandrake actuellement c'est qu'il n'augmente pas la distribution de leur OS alors que le marché augmente. Il semble même que Debian soit passé devant eux. L'ajout de la pub ne va pas arranger ce point même si ça permet à Mandrake de survivre.
Si ce point ne s'améliore pas, à long terme ça va être dure. La valeur financière d'une pub dépendent énormément de la taille du public touché.
Je ne dis pas que plus personne va installer Mandrake mais que cette décision ne va pas dans le bon sens (selon moi).
[^] # Re: Espaces publicitaires à vendre
Posté par Austin . En réponse à la dépêche Espaces publicitaires à vendre. Évalué à 0.
Comme pour le e-learning ?
> Toutefois, ça me rappelle une periode ou (si je me souviens bien ), le premier telechargement sur le site été payant, et les suivants gratuits. mais ça n'a pas duré. :-)
Tu disais "faisons leur confiance" juste au-dessus.
[^] # Re: Espaces publicitaires à vendre
Posté par Austin . En réponse à la dépêche Espaces publicitaires à vendre. Évalué à 1.
Non. Il n'y a pas de développeurs bénévoles derrière freshmeat. freshmeat n'est qu'un site web.
# Re: Espaces publicitaires à vendre
Posté par Austin . En réponse à la dépêche Espaces publicitaires à vendre. Évalué à 2.
A court terme ça peut faire rentrer du pognon mais à long terme je ne crois pas.
On est en France et MandrakeSoft est une boîte Française et donc la perception Française n'est pas partagée dans la reste du monde. Or Mandrake ne peut pas vivre quand s'appuyant sur le sentimentalisme du marché Français.
Dans les autres pays si Mandrake disparait ça ne va pas créer le même émois qu'ici.
Mandrake ne contribue principalement qu'à la distribution Mandrake et très peu à d'autres projets (kernel, gcc, gnome, kde, etc...). Les outils dédiés à la distribution (installeur et drake*) ne sont utilisés que dans la Mandrake.
Désolé d'être brutale mais la perte de Mandrake ne sera pas un grosse perte pour le logiciel libre.
Si Mandrake disparait ça indiquera uniquement que faire une distribution profidable est difficile.
Les gens (la grande majorité selon moi) ne sont pas motivés à installer une Mandrake pour subir de la pub s'il ne sont pas affectivement attachés à Mandrake alors qu'il existe d'autres distributions gratuites et sans pub qui rendent le même service.
De plus la communauté des développeurs/testeurs ne va pas apprécier. Installer une distribution ou une beta (même sans pub) pour faire des développements/tests gratuits pour une distribution qui fait de la pub à d'autres sociétés (qui ne seront pas forcément liées au logiciel libre), faut être motivé.
Dans ceux qui maintiennent un mirror de mandrake il y en a beaucoup qui vont arrêter. Investir de la bande passante et de la place disque pour diffuser gratuitement une distribution qui fait de la pub ... la pilule va être dure à avaler.
Ceux qui avaient une raison "morale" d'être dans MandrakeClub même s'ils n'utilisaient pas le service ne vont plus s'inscrire.
Beaucoup vont arrêter de promouvoir une distribution qui fait de la pub. Je pense notament aux écoles/universités et peut-être les LUG durant les install-party.
La confiance de la communauté Mandrake envers Mandrake va encore diminuer. Beaucoup on mis la main à la poche pour renflouer les caisses après leur "connerie" e-learning qui n'a rien à voir avec le LL et maintenant il faut encore payer ou subir de la pub.
Idem pour la communauté LL qui n'a pas toujours apprécié la double licences de la solution firewall ou la solution cluster qui fait la "promotion" du compilo d'intel.
Mandrake a raté le marché des entreprises et n'a plus "que" le marché de la communauté et des ordinateurs personnels. Or la communauté ne va pas faire de la pub ou s'investir pour une distribution qui fait de la pub pour coca-cola, les tampons always, ou MacDo.
Maintenant Mandrake doit assumer tout seul comme le fait SuSE (qui est dans les entreprise). Bonne chance.
PS : c'est parfois caricatural.
[^] # Re: Espaces publicitaires à vendre
Posté par Austin . En réponse à la dépêche Espaces publicitaires à vendre. Évalué à 2.
Ça n'a rien de nouveau.
> tellement elle est restrictive
Tu ne peux pas vendre une redhat avec les logos. C'est ça la restriction. Tu ne peux que la distribuer gratuitement. Et ça ne conserne que deux paquets. On trouve facilement des distributions basées sur RedHat a prix cassé sans ces deux paquets.
[^] # Re: Espaces publicitaires à vendre
Posté par Austin . En réponse à la dépêche Espaces publicitaires à vendre. Évalué à 2.
C'est un chois libre de Mozilla/Galeon/Firebird.
Plus de lien vers Google dans la Mandrake si Google ne paie pas ?
[^] # Re: Test de la Gentoo 1.4
Posté par Austin . En réponse à la dépêche Test de la Gentoo 1.4. Évalué à 1.
Pour avoir testé, ça ne change pas grand chose. Du moins pour les programmes en C.
[^] # Re: Epiphany
Posté par Austin . En réponse à la dépêche GNOME 2.4 est disponible. Évalué à 10.
Ils n'ont pas le même objectif/public.
Bash et nautilus ça fait double emploi, non ? :-)
[^] # Re: Intégration dans Red Hat
Posté par Austin . En réponse à la dépêche GNOME 2.4 est disponible. Évalué à 3.
La beta2 de la RH10 sortira probablement vers le 15 septembre en même temps que la mise en ligne du nouveau http://rhl.redhat.com/(...) .
> Les developeurs de la mailing liste disait attendait la sortie de Gnome 2.4 .
Ils n'ont pas attendu la sortie de gnome 2.4 . D'ailleur gnome 2.4 (à 98 %) avec epiphany 1.0 est déjà dans rawhide. Par contre je crois que la sortie finale est repoussée vers fin octobre à cause de l'intégration de gnome 2.4 qui n'était pas initialement prévu pour la RH10.
# Re: GNOME 2.4 est disponible
Posté par Austin . En réponse à la dépêche GNOME 2.4 est disponible. Évalué à 10.
boklm a pointé dans un journal un test de la 2.4 (2.3 en réalité) :
http://arstechnica.com/reviews/003/software/gnome-2.4/gnome2.4-1.ht(...)
Ximian a annoncé la disponibilité de la version de développement (comprendre que Ximian est loin de la version finale) de XD3 :
http://lists.gnome.org/archives/desktop-devel-list/2003-September/m(...)
[^] # Re: La fin du projet mplayer ?
Posté par Austin . En réponse au journal La fin du projet mplayer ?. Évalué à 1.
[^] # Re: Test de la Gentoo 1.4
Posté par Austin . En réponse à la dépêche Test de la Gentoo 1.4. Évalué à 0.
Pour en revenir au librairies, si le binaire définit les librairies qu'il a besoin, il vaut mieux avoir un système automatique pour détecter les dépendances avec les librairies que de faire ça à la main. Mais puisque ça te plait, tu peux faire des paquets avec :
requires|provide : "virtual/alsa".
Mais "virtual/alsa" ne dit pas que le paquet ne peut marché d'avec un Linux > 2.4.17 ou < 2.4.21 car une api a changé ou qu'il faut que les fontionnalité real-time soient disponibles ou plus simplement que le module soundcore soit présent. Seulement "virtual/alsa" est de la gestion de dépendance à la petite semaine.
Puis pour les services rendus par plusieurs paquets il y a aussi des facilités virtuels.
exemple :
$ yum provides ftpserver
Available package: vsftpd proftpd wu-ftpd provides ftpserver
> Enfin si, je sais plus si rpm le fait, ou le faisais à une époque lointaine en tout cas, ou si c'est urpmi qui le rajoute
C'est rpm qui le fait et non urpmi/etc. Par rapport à urpmi/apt/yum , rpm est un outil bas niveau et ne fait pas de recherche de paquet pour respecter les dépendances (c'est le boulot d'apt/urpmi/...). Par contre si les dépendances ne sont pas respectées, l'installation/mise_à_jour est refusée par rpm. C'est à urpmi/apt/yum de rechercher les bons paquets suivant des critères retourné par rpm et de les proposer à rpm qui fait tous les contrôles et l'installation (ce que ne fait pas urpmi/apt/...). Ainsi un "yum remove gtk+" fera un "rpm -e --test gtk+" pour connaitre les paquets qu'il faut desinstaller pour supprimer gtk+. (question : il se passe quoi si tu demandes la suppression de gtk+ sur une gentoo ?)
Il faut noter qu'urpmi ou yum sont des petits projets par rapport à rpm. rpm est 20 à 30 fois plus gros que yum ou urpmi qui utilise rpm alors que les gens n'ont d'yeux que pour urpmi/yum/... C'est les facilités de rpm qui permettent ça. Yum ou urpmi, des équivants d'apt mais dédiés rpm, font dans les 5 000 lignes de code seulement.
> Je sais pas dans le monde .rpm, mais dans le monde .deb c'était plutôt ce qu'on appelait des meta-paquets.
Dans la pratique, c'est peu utilisé avec rpm :-). Mais c'est présent (voir plus haut).
Puis que "meta-paquet" ça te plais, il te suffis de faire un paquet vide avec uniquement des "require: ..." et t'as un "meta-paquet".
> Franchement, je préfère de loin l'abstraction des virtuals (tu fait comment avec un nom de fichier pour dire: un codec divx ?)
Si c'est un librairie, tu ne fais rien.
Si la detection automatique n'est pas satisfesante (par exemple plusieurs nom de librairie pour la même fonctionnalité) tu fais une dépendance "virtuel"
"require : codec_divx >= 4".
Un paquet qui fourni cette fonctionnalité a par exemple :
"provide : codec_divx = 4.1".
Tous les paquets rpm on la dépendance vituelle : "provide : %{name} = %{version}"
Tu peux en ajouter autant que tu veux.
Je vois pas pourquoi tu insiste sur le "virtuel".
rpm detecte automatiquement s'il faut libc.so.6(GLIBC_2.3) ou libc.so.6(GLIBC_2.1.3) . Ça n'a rien de virtuel et ça évite bien des conneries. Maintenir en "virtuel" les dépendances avec la librairie C est un véritable enfer. Ma librairie C fournit la comptabilité avec 15 (!) versions (2.0 à 2.3.3). Certains paquets ont besoin de la 2.1.3 d'autres de la 2.3 etc... rpm contrôle tout automatiquement. J'ai vraiment pas envis de renseigner ces informations à main.
> Bah manquerai plus que l'install d'un paquet t'écrase ta config existante? Sérieux, c'est encore vraiment la base.
Tu ne comprends pas. Si un fichier de configuration est déréférences dans la base rpm le fichier est renommé toto.rpmsave (s'il est modifié par rapport à la version de référence). Si un fichier de conf peut-être écrasé il est renommé toto.rpmsave et il y a des options pour ne pas toucher au fichier de config (les nouveaux sont nommés toto.newrpm). Il y a aucun problème avec ça.
Par contre, lorsque rpm ne supportait la gestion des configurations, passer de ppp à ppp_ng (c'est un paquet différent) alors que c'est le même format de fichiers de configuration, aurait créé des .rpmsave (ou .newrpm). Maintenant ce n'est plus le cas.
> C'est merveilleux tellement c'est aller loin contre le bon sens et la simplicité.
Recompilé c'est tellement plus "simple"...
> Cool, ça vous fait un USE flag. Aller, encore un petit effort, c'est presque ça.
Tu ne comprends pas. J'ai rien contre USE qui va "paramétrer" la compilation des paquets et c'est un dispositif très utile. Je parle de la gestion des dépendances. De ce que je comprends, USE n'a rien à voir avec la gestion des dépendances.
Pour rpm on pourrait définir un convention des facilités à utiliser pour compiler un paquet avec "--with qt" ou "--without qt". C'est courament fait.
Exemple :
$ rpm -i proftpd
[...]
Available rpmbuild rebuild options :
--with : ldap mysql postgres tls
$ rpm -i alsa
Available rpmbuild rebuild options :
--without : isapnp sequencer oss
You may also recompile for given cards only by calling rpmbuild with :
--define "cards card1,card2,card3"
(the default is "cards all")
You may also recompile for a given kernel version and arch with :
--define "kernel <uname -r output>"
(for example "kernel 2.4.20-9")
--target
Mais même avec un système pour "châpeauter" la contruction des rpm, ce n'est pas un système de gestion de dépendance. A moins que USE puisse te dire :
- "compilation/installation de KDE refusé car qt n'est pas disponible"
au-lieu de planter au milieu de la compilation.
> Ça va en faire des versions spécifiques à compiler pour RedHat
Je crois que tu n'as pas bien compris le système. D'une certain manière on peut dire que c'est pour avoir des espaces de paquet séparés et éviter les conflits. Imaginons que ximian utilisé un Epoch=12 par exemple, le paquet nommé toto chez redhat ne va pas interférer avec le paquet toto de de xiniam et quelque soit la version des paquets. Par exemple tu ne peux pas mettre à jour libtoto-1.0-1 de ximian par un libtoto-1.0-2 de redhat si le paquet toto réclame un 12:libtoto . Le "Epoch" est prioritaire. L'objectif n'est pas de compiler des 10 façons différentes le même paquet. Il y a d'autres mécanismes pour ça ("--define", "--with", "--without").
> > Rpm gère les paquets absolètes.
> Pur narcissisme.
Exemple concret. Apache fournit maintenant mod_dav alors qu'avant c'était un paquet séparé. Dans le paquet il y a :
Obsoletes: mod_dav
Le nouveau paquet apache est autorisé à supprimer mod_dav puisqu'il le fourni. Sinon rpm indique un conflit (il ne va pas desinstaller un paquet sans "authorisation") et il faut désinstaller mod_dav avant de mettre le nouveau apache.
C'est aussi utilisé pour changer de version de distribution. Si la distribution passe de wu-ftpd à proftpd, il y aura dans proftpd :
Obsoletes: wu-ftpd
wu-ftpd sera supprimé si proftpd est installé. Ce qui est normal si le distributeur ne veut plus supporter wu-ftpd.
C'est aussi grace à ça que les gens passent de Mandrake 9.0 à 9.1 ou redhat 8.0 à 9 sans tout réinstaller.
C'est toujours du "Pur narcissisme" pour toi ?
> Moi je suis sûr grâce à ton post que bientôt rpm aura rattrapé son retard sur apt.
C'est d'une "naïveté"... apt existe pour rpm.
rpm n'est pas l'équivalent d'apt !
up2date ou urpmi ou yum sont des équivalents d'apt. L'équivalent de rpm dans le monde apt est dpkg.
> vrais paquets virtuels
Fait.
> héritage entre specs
???
> gestion explicite des masques de paquets
???
Tu parles peut-être encore de compilation alors que je parle de gestion de dépendance pour un système rpm qui n'est pas orienté source.
> mélange aisé de 3 niveaux de stabilité des paquets
Fait.
> système de merge des fichiers de conf
Fait, c'est les triggers du paquet qui le font. Du moins si le paquet est développé pour le faire.
> Mais il n'approche qu'à peine (et c'est bien normal, mauvais choix, mauvais résultats) la souplesse que peut offrir un système basé sur les sources ... blabla source compilation etc
rpm n'est pas fait pour faire une distribution orienté source. Comparer rpm à gentoo sur ce point n'a pas de sens.
Par contre il est possible de faire une surcouche à rpm pour faire une distribution orienté source. Les binaires stokent le nom du paquet src.rpm qui stockent ce qui est nécessaire pour la compilation qui est elle-même paramétrable via --define --with --without. Une sourcouche pour "piloter" tout ça est tout a fait envisagable.
Mais avec ça on reste loin de la possilité de faire ça depuis les sources :
$ yum install_build_from_source provides libgnomeui-2.so.0
ou
$ yum install_build_from_source provides /usr/X11R6/bin/xscreensaver-demo
Or ça marche avec les binaires et avec résolution des dépendances. A moins de tout mettre en dure (pas de detections automatiques) ça ne peut pas marcher avec les sources. Tout mettre en dure n'est pas une bonne solution si on ne veut pas système bordélique.
> Alors que franchement, sur une distrib à la redhat, c'est quoi la proportion d'utilisateurs qui ont un jour fait leur propre srpm ?
Je fais mes rpm quand c'est nécessaire (ajout crypto, driver adsl, etc). Je préfère utiliser mon système que d'attendre la fin d'une compilation de 10 heures.
Renseigne toi un peu, les repository pour rpm ne manquent pas :
- http://plf.zarb.org/(...)
- http://dag.wieers.com/home-made/apt/(...)
- http://atrpms.physik.fu-berlin.de/(...)
- http://ftp.falsehope.com/pub/(...)
- http://www.fedora.us/index-main.html(...)
- http://home.teleport.ch/simix/(...)
- http://ccrma-www.stanford.edu/planetccrma/software/(...)
- http://freshrpms.net/(...)
- ...
T'as prouvé ton ignorance complète sur rpm.
Si tu veux une distribution orienté source, reste sous Gentoo. Personne n'a dit que les distributions actuelles basées sur rpm étaient des distributions orientées source.
Si les .rpm et .deb sont sur la place depuis un moment, ce n'est pas un hazard et surement pas à cause de "mauvais choix" comme tu dis.
Mais quels "mauvais choix" ? Tu peux t'expliquer ?
Le "mauvais choix" de n'avoir pas mis la priorité sur les distribution orienté source ?
Réjouis toi alors. Ça garanti un succès fulgurant de gentoo. Mais pour quand ? Car la déferlante on ne la voit pas venir actuellement.
[^] # Re: Le compilo?
Posté par Austin . En réponse à la dépêche Test de la Gentoo 1.4. Évalué à 2.
Le compilo d'intel a un avantage pour les calculs, en fait pour certain calcul.
Si tu projetes de transformer ta gentoo en noeud de calcul pour un cluster c'est peut-être intéressant.
[^] # Re: Test de la Gentoo 1.4
Posté par Austin . En réponse à la dépêche Test de la Gentoo 1.4. Évalué à 1.
> Ou alors il analyse le binaire pour déterminer quelles libs sont nécessaires... pas tellement utile non plus.
C'est utile. C'est la librairie avec son numéro de version qui définie la compatibilité et pas autre chose. Sinon c'est de la duplication d'info. En fesant ainsi, tu peux remmoner des paquets les fusionner, etc... Tout ce qui compte, c'est la facilité réellement fournie et non le nom du paquet. L'héritage est aussi utile car il permet de limiter les nombres de dépendances et ne pas tomber dans l'ingérable. Rpm peut aussi définir des dépendances virtuels (style require: kde) ou des dépendances sur des fichiers ou sur une configuration. Par exemple lors d'un passage de ppp à ppp_ng si ppp_ng utilise config(ppp > 2) qui est déjà fourni par ppp-2.5 et que tu mets à jours, tes fichiers de configuration seront conservés. En fait le système de génération des dépendances utilise des plugins et rien ne t'empêche de devopper de nouveaux plugins (par exemple sur les symboles fournis par le noyau pour vérifier si un module noyau peut-être installé et marchera). Il y a quelques mois un plugins pour gérer les dépendances perl a été ajouté. Il y a un plugin pour prelink, ainsi rpm peut vérifier un binaires même s'il a été modifié par prelink.
rpm gère aussi les branches de paquets. T'as un gnome-2.2.2 spécifique qui utilise un libgnome-2.2.2 spécifique incompatible avec la branche 2.2, si un gnome-2.2.3 "standard" sort, il n'écrasera pas ta version spécifique mais un gnome-2.2.3 avec tes spécificités (marqués par le tag Epoch) sera un candidat pour la mise à jours.
rpm gére aussi les mises à jours sur plusieurs paquets et non seulement sur un seul. C'est l'ensemble des paquets qui sera évalué pour une mise à jour ou une installation et ce n'est pas fait paquet par paquet. un "rpm -U ppp_ng" pourra remplacer ppp et pppoe. Un "rpm -U ppp_ng pppoe" peut être utilisé pour mettre à jour le paquet ppp alors qu'un "rpm -U ppp_ng" n'est pas suffisant. Rpm gère les paquets absolètes. Rpm offrira dans 1 ou 2 mois la possibilité d'annulé la dernière transaction d'installation/mise à jours (c'est un transaction car rpm fait l'opération sur plusieurs paquets qui forme un tout).
> Les SLOTs (aka possibilité de considérer plusieurs version d'un même soft comme étant des logiciels diffèrents à installer en paralèle (QT, GTK...)).
Comme rpm. S'installation en parallàle ne pause pas de problème. Du moins lorsqu'elle est prévus. C'est une pratique très courrante.
> Et pis, franchement, quand on "crois" juste; vaut mieux ne rien dire, surtout quand le sujet est trollogène.
J'en suis sûre.
[^] # Re: Nombrilisme sur le Web
Posté par Austin . En réponse au journal Pour la tribune (passé votre chemin si vous n'est pas conserné).. Évalué à 1.
> qui EST et DOIT rester libre de circulation....
> Maintenant tu m'emmerdes avec tes histoires.
Liberté toute relavite parfois, il ne peut pas t'en autant.
[^] # Re: Test de la Gentoo 1.4
Posté par Austin . En réponse à la dépêche Test de la Gentoo 1.4. Évalué à 1.
Je recompile beaucoup plus rarement les programmes qu'avant car ils sont maintenant livrés complets pour la majorité des usages. Et c'est tant mieux.
[^] # Re: Test de la Gentoo 1.4
Posté par Austin . En réponse à la dépêche Test de la Gentoo 1.4. Évalué à 0.
Les dépendances sont définies à la construction du paquet (à la compilation). De plus rpm fait la detection automatique des librairies utilisées (rpm -q --requires -p toto-1.0-1.i386.rpm => Requires glibc... automatiquement).
> A ce qu'on peut lire sur la Gentoo, elle semble plus intéressante à ce niveau là. Qu'en est-il ?
Pour la gestion des dépendances ? Non, je ne crois pas.
[^] # Re: La RIAA attaque 261 utilisateurs de réseaux P2P
Posté par Austin . En réponse à la dépêche La RIAA attaque 261 utilisateurs de réseaux P2P. Évalué à 2.
Si tu ne refait pas la signature, gpg te retourne :
gpg: MAUVAISE signature de ...
Lorsque tu utilises bittorrent pour récupérer une distribution, le fichier md5sum qui accompagne généralement les iso est signé par le distributeur et infalsifiable. A toi de vérifier.
[^] # Re: La RIAA attaque 261 utilisateurs de réseaux P2P
Posté par Austin . En réponse à la dépêche La RIAA attaque 261 utilisateurs de réseaux P2P. Évalué à 1.
C'est plutôt se demander si c'est légal. Je parle à grande de "l'échange de fichier à large échelle".
> mais ça me choque assez de toujours voir des gens considérer comme admis qu'il ne doit pas être permis de copier de la musique.
Tu as trouvé quelqu'un ici qui remet en cause le "fair use" ?
> On est dans une situation ou la copie est possible sans coût, à très grande échelle. En pratique, la copie est possible, donc sans obstacle artificiel elle sera pratiquée. Si on doit décider qu'il faut l'interdire, de manière artificielle (donc avec une loi) comme c'est le cas actuellement, le minimum serait de dire pourquoi.
Pourquoi : pour le pognon.
Que la rentabilité de star-academy ne soit pas remise en cause par le piratage est pratiquement une évidence.
Par contre il y a d'autre domaine où c'est beaucoup moins évident. Par exemple l'industrie du cinéma ne roule pas toujours sur l'or. Dans l'industrie du jeux video il y a plein de boîte qui souffre, etc...
Si le fait que la copie soit d'un coût très faible, autorise à tout copier...
Le cinéma, la music, les jeux video, les logiciels ne vendent pas que le support mais aussi la réalisation, la pub, les déficites du dernier film, la promotion d'artistes qui finalement ne sont pas rentables, etc.
Si demain il est admis qu'il est normal d'avoir gratuitement ce qui a couté très chez (je pense notament au cinéma et aux jeux videos), beaucoup moins de gens vond acheter des DVD, jeux videos etc...
Si c'est parce que c'est trop cher, on peut accéder au cinéma ou aux jeux video à un faible coût :
- film -> télé ou location
- jeux video -> les jeux un peu vieux et toujours excellents