S'il y a une entitié qui serait hypra contente que OSP soit compatible GPL c'est assurément la FSF.
Si c'est compatible GPL, c'est une super assurance pour le libre. Plusieurs procès ont été gagnés pour faire respecter le caractère libre d'un programme. Tous ce qui est compatible GPL est bon pour le libre.
Mais OSP ce n'est pas compatible GPL. Et soit convaincu que la FSF le regrette mille fois plus que MS... MS doit être bien content que ça ne soit pas compatible GPL.
> Bon les gars, faut oublier ODF, il est incompatible avec la GPL.
Mais la SFLC (Software Freedom Law Center) suit ça comme d'autres. Et ce n'est pas un traitement de faveur envers Sun. Sun a sorti la CDDL, ben elle n'est pas compatible GPL (au moins Sun, contrairement à MS, n'est pas faux cul au point de dire le contraire). La FSF a aussi longtemps critiqué la "java trap" (qui aujourd'hui n'existe plus).
> Bon les gars, faut oublier ODF, il est incompatible avec la GPL.
Tu oublies (exprès) que OOo est sous GPL. T'es prêt à tout pour tailler des pipes à MS et FUDer sur les autres.
Mieux, OOo pour la version 3 (à partir de la première beta) sera GPLv3. Donc il n'y aura pas d'accord de trou du cul de minable à la MS/Novell.
Les brevets que met Sun dans OOo sont (vraiment) irrévocablement disponibles aux programmes GPL (et contrairement à OSP, pas seulement aux programmes qui implémentent la spec ODF).
Donc pour, par exemple ODF 2.0 et si Sun se désengage d'ODF (pûr délire ceci dit), tout ce qu'il faut c'est ne pas _ajouter_ des brevets de Sun qui ne sont pas dans les versions précédentes des spècs d'ODF.
Donc arrête ton FUD de merde.
Tu n'es ici que pour propager le FUD de MS et ça devient vraiment puant.
Tu bosses pour MS, tu le sais que MS est le roi des faux cul lorsqu'il sagit du logiciel libre. Tu deviens de plus en plus minable.
Open Friendly Baromètre :
- Sun : 9,8 / 10
- MS : 0,1 / 10
FUD Baromètre :
- Sun : 2 / 10
- MS : 10 / 10 (bravo MS)
Zut, il semble qu'il y a eu une rupture dans le continuum espace-temps et qu'un vendredi se soit glissé dans un jeudi.
Espérons que ça n'annonce pas la destruction totale de l'univers.
Grief, faut pas pousser.
De toute manière, il y aura toujours plein de monde pour gueuler que ça bouffe trop de mémoire, que ce n'est pas assez rapide, que X boote plus vite que Y et que ça change tout. Pourquoi ? Pas que la consommation mémoire soit telle qu'elle est insupportable, mais simplement pour dire "j'en ai une plus grosse que la tienne", "j'en un programme techniquement bien foutu et réalisé par des pointures", "je sais apprécier ces exploits technique et pas toi", etc.
Les optimisations c'est très bien. Mais que le "grief principale" soit réglé en le réduisant de 15 % ça laisse songeur. Ça prête à réflexion.
http://blogs.the451group.com/opensource/2008/03/06/red-hat-b(...)
Dont la source est : http://www.redhatmagazine.com/2008/02/04/tips-and-tricks-rhe(...)
Red Hat’s customer service and support teams receive technical support questions from users all over the world. Red Hat technicians add the questions and answers to Red Hat Knowledgebase on a daily basis. Access to Red Hat Knowledgebase is free. Every month, Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries. The information provided in this article is for your information only. The origin of this information may be internal or external to Red Hat. While Red Hat attempts to verify the validity of this information before it is posted, Red Hat makes no express or implied claims to its validity.
Bref, c'est d'une base de connaissance de Red Hat et il y a un webmaster qui a pioché au hazard. Sûr que cette entrée dans la base de connaissance de Red Hat est pour ceux qui écrivent la doc, s'occupe des sites web, etc...
Diable, il y a d'autres distributions !
J'ai utilisé Slack, j'ai utilise SuSE, j'ai beaucoup testé Debian (c'était il y a longtemps), j'ai beaucoup testé Gentoo, j'ai un peu testé Mandr(ake|iva) et j'ai aussi testé Ubuntu. Notons qu'il y a la distribution et le projet. Linspire est peut-être une formidable distribution, mais je n'aime pas le projet. Je fous d'office tout ce qui a un accord avec MS (Xandros, Novell/Suse, TurboLinux, Linspire) à la poubelle.
Bref, il faut faire un choix avec son cerveau, pas à cause de la mode.
En passant, j'utilse Fedora/CentOS/RHEL. Ça me convient le mieux.
J'ai une bonne F8 avec virt-manager et les installations sont triviales.
D'ailleurs j'ai installé une Ubuntu 7.10 et une 8.04 (alpha ?) pour tester vite fait.
Bilan : Ubuntu boote vite.
Mais comme je ne passe pas ma journée à booter...
Je vais te dire un truc insultant (et méprisant de l'histoire) et si tu le prends mal je vais t'expliquer que tu manques d'humour. Espèce de fils de tout le monde.
Et en plus Fedora fait l'importation de clée (il demande confirmation avant qu'on donne confiance à une clée). C'est indispensable dans le cas de dépôt qui sont disponibles sur plusieurs mirroirs.
> Je suis sous Fedora 8 et quand je clic sur un simple lien RPM sur internet, il est telechargé, on me demande le mot de passe et une interface graphique
C'est un truc qui existe depuis Red Hat 7.2 !
À l'époque c'était redhat-config-package (pas terrible ceci dit) qui était utilisé.
> Tu présentes le One-clic-Install comme une super nouveauté.
Ben ceux qui n'ont jamais utilisé Red Hat/Fedora le pensent.
> car elle sera le compilateur utilisé par Fedora 9
Je ne peux parler pour les autres distributions, mais c'est déjà le compilateur de (la future) F9.
Tout (noyau compris) a été compilé avec gcc 4.3 (et deux fois car au premier essai il y avais un bug :-)), depuis plusieurs semaines gcc 4.3 est intensivement testé.
L'aide des distributions pour les tests est plus que précieuse. Ça fait aussi plein plein de remontés upstream.
> Et aussi bête que de dire: ceux qui ne connaissent pas ADA, ce fabuleux langage, sont des idots. Ou encore: ceux qui n'utilisent pas Ruby, cette merveille, sont vraiment nuls. Etc.
Je ne connais pas ADA ni Ruby, je ne les critique pas. Tu vois la nuance ?
> Excuse-moi, mais je crois qu'on ne s'est pas compris du tout, mais alors là pas du tout, du tout.
C'est la seconde fois que du nomme explicitement Jeremy Katz dans des propos relatifs à PackageKit.
Le faire intervenir aujourd'hui (encore) parait pour le moins "saugrenu".
Et pourquoi que lui ? Es-ce que Fedora dans son ensemble est convaincu que PackageKit va tout remplacer à moyen terme ?
Je ne crois pas.
Ni aura-t-il pas quelques rétissances à ajouter PackageKit à Anaconda alors qu'Anaconda bouffe déjà un peu trop de mémoire ? Et ceci (ainsi que d'autres aspects) va au-delà de seulement l'avis de Jeremy Katz.
Et qu'on se comprenne bien, je n'ai rien contre PackageKit. Je me suis peu documenté, mais il parait pour le moins bien conçu et ergonique. Il a les qualités pour ralier d'autres développeurs de diverses distributions et c'est vraiment excellent.
Mais programmer l'enterrement de pirut/etc aujourd'hui est saugrenu.
Yum (avec yum-updatesd, les applets qui vont bien, pirut, etc) a mis des années (yum est dans Fedora par défaut depuis FC1 !).
Il ne faut pas enterrer pirut/etc à priori. Mais à posteriori. C-à-d après que PackageKit (ou un autre) ait prouvé sa valeur. D'autant plus que pour l'instant Fedora (et/ou Red Hat) n'a pas donné de signe qui indique que Fedora a une vision pour PackageKit (contrairement à Xen vs KVM par exemple). Pour l'instant Fedora va donner sa chance à PackageKit pour F9 (et suivant évidemment). PackageKit le mérite largement et c'est totalement dans l'esprit Fedora.
Si tu fais une news sur F9, n'hésite pas à mettre un projecteur (et un gros) sur PackageKit.
Mais ne sous-entend pas que les ambitions de PackageKit sont contrariées par Jeremy Katz :-)
Mais arrêtez avec cette connerie.
Es-ce que Gnome brule les livres sur les interfaces ?
Es-ce que Gnome prétend faire une race supérieure de bureau et exterminer tout le reste ?
Es-ce que Gnome fait sa propagande dans les écoles pour tout petit ?
Es-ce qu'on ne peut pas circuler librement si on n'a pas une carte Gnome ?
Merde alors, arrêtez de reprendre des propos stupides de Linus. Tout Torvalds qu'il est, il dit aussi des conneries (qu'il n'a pas répété).
> Je ne sais pas ce qui explique cette universalité de la critique
Simple, la majorités des gens ne comprend pas C++ et est trop fainéante pour l'apprendre. Au-lieu de reconnaitre sa paresse, ben elle critique (sans savoir tout le géni qu'il y a dans C++).
Moi cette réthorique que la "dictature" des standards me ... fatigue.
Cette réthorique remet en cause l'intérêt des standards (des vrais, pas des bouses comme MS-OOXML).
Ça donne une vision simpliste du monde puis ça tire des conclusions.
MS est un excellent porte-parole des anti-standards...
> Donc un code qui serait « parfaitement propre » (d'après cette définition) et qui utiliserait toutes les fonctionnalités du standard ne marcherait nulle part. Trop cool !
N'importe quoi.
Enfin le standard donne des possibilités pour faire des choses non proposées par le standard. Le standard C/C++ ne dit rien sur l'assembleur. N'empêche qu'on peut ajouter de l'assembleur dans du C/C++. N'empêche que le standard C/C++ n'interdit pas les pragma. Etc.
Mais quand le standard dit que pour faire un truc bien précis, il faut le faire "comme ci", ben il faut le faire "comme ci" et pas "comme ça".
Le standard dit que pour ajouter deux variables, il faut utilisé l'opérateur "+". Inventer l'opérateur "⊕" pour concurrencer le standard est sans intérêt.
> Côté développement logiciel, c'est d'ailleurs plutôt le non-respect des standards qui assure une certaine portabilité.
N'importe quoi encore...
Ben le code Windows est super portable selon toi...
Ce qui fait la portabilité, c'est le respect des standards. Ce n'est pas en inventant des solutions dans son coin qu'on assure la portabilité. Linux s'appuit sur le standard Posix, les applis conçues pour Posix (applis Unix en général) se portent sans problème sur Linux (ou *BSD).
N'assassinez pas bêtement les standards alors que leur intérêt n'est plus à démontrer. Mais c'est comme tout, rien est parfait. Un standard doit continuellement être amélioré (d'où les implémentations qui sont toujours en retard sur le dernier standard).
Pour Fedora, ça utilise les caractéristiques de rpm. wesnoth-1.2.8-2.fc8.i386.rpm, wesnoth-1.2.8-2.fc8.x86_64.rpm, etc.
Spécifiquement pour wesnoth il n'y a pas de wesnoth-data (le paquet n'a pas été fait ainsi, faut pas chercher midi à 14 h dans cet exemple).
Ici encore Fedora utilise les caractéristique de rpm (le champ ARCH).
Par exemple pour le noyau : source : (généralement le même pour tout le monde)
kernel-2.6.24.3-12.fc8.src.rpm <= le même pour tout le monde
sur dépôt i386 :
kernel-2.6.24.3-12.fc8.i586.rpm
kernel-2.6.24.3-12.fc8.i686.rpm
...
kernel-doc-2.6.24.3-12.fc8.noarch.rpm <= le même pour tout le monde (hardlink)
sur dépôt x86_64 :
kernel-2.6.24.3-12.fc8.x86_64.rpm
...
kernel-doc-2.6.24.3-12.fc8.noarch.rpm <= le même pour tout le monde (hardlink)
Il n'y a pas de distinct "data" ou "programme", mais la distinction architecture indépendant (noarch).
Ainsi yum est le même pour tout le monde (aussi bien source que programme) : source :
yum-3.2.8-2.fc8.src.rpm
sur dépôt i386 :
yum-3.2.8-2.fc8.noarch.rpm
sur dépôt x86_64 :
yum-3.2.8-2.fc8.noarch.rpm
Ce sont bien les mêmes, le md5sum peut le confirmer.
Mais on peut avoir des trucs surprenants. Par exemple toutes les traductions OOo sont architectures dépendants... Faut voir ça comme un bug upstream.
Un parquet n'est pas construit d'un coup. Par exemple pour kernel (Linux) il est contruit avec --target noarch (ce qui va être généré sera le même pour tout le monde), puis --target i586, puis --target i686, puis --target x86_68, etc...
> Fedora contient egalement les iso, et il semblerait que les 663 Go soient en comptant toutes les releases, vu qu'ils annoncent une augmentation de 100Go par release.
Non, ce n'est pas en comptant toutes les releases. Sur fr2.rpmfind.net, Fedora (rawhide + F7 + F8 + mise à jour) c'est 480 Go. Par contre fr2.rpmfind.net n'a les debuginfo que pour Rawhide. D'où probablement le fait que fr2.rpmfind.net ne fait pas 660 Go.
La GPL impose la disponibilité sur 3 ans des sources. Red Hat archive toutes les release sur un serveur (je ne sais plus où).
Serveur principale Fedora : http://download.fedora.redhat.com/pub/fedora/linux/releases/
Il n'y a que F7 et F8 (qui sont les distributions actuellement maintenues).
CPU ou core ?
Si c'est core et pour des quadri-cores on tombe à 40 machines (ce qui reste impressionnant).
> Je sais, de source sûre, que cet utilisateur a compilé ces paquets dans le mois d'octobre 2007 et n'y a pas touché depuis.
Mouaif... $ $ rpm -q --changelog -p kbde-1.1.6-9.36.src.rpm
attention: kbde-1.1.6-9.36.src.rpm: Entête V3 DSA signature: NOKEY, key ID 76edc1ff
* lun mai 14 2007 <valery_reznic@users.sourceforge.net> 1.1.5-1
- no real change - just to match kbde-driver version
Le dernier log n'est pas à jour (1.1.5-1 alors que le paquet est 1.1.6-9.36).
Le src.rpm a été reconstruit le 8 mars. $ rpm -q -i -p kbde-1.1.6-9.36.src.rpm | grep "Build Date"
attention: kbde-1.1.6-9.36.src.rpm: Entête V3 DSA signature: NOKEY, key ID 76edc1ff
Release : 9.36 Build Date: sam 08 mar 2008 07:54:34 CET
> Factory sont datés de deux jours (samedi 8 mars 2008 vers 07h55 - mes sources indiques que l'utilisateur lambda cité dormait encore), soit grosso modo la date de la dernière recompilation de la Factory. Et c'est comme ça pour tous les builds Factory.
Ce qui ne montre rien. Pour koji et probablement comme pour OpenSuSE, les requêtes de construction de paquet sont empilés dans une file. Ce n'est pas excécuté de suite.
> Aussi, la Factory est recompilée (quasi) entièrement une à deux fois par semaine
J'y crois pas. Mais si je me trompe, tant mieux.
> Enfin, il me semble qu'entre la ligne du "c'est une nécessité" et la suivante "Foutaise" qui parle du même sujet, il y a une subtilité qui m'échappe..
C'est une nécessité que le système de build gère les dépendances _lors_ de la construction.
Exemple pour mock (compilation de galeon). Mock est utilisé par koji (Fedora) :
$ mock --rebuild --root=fedora-8-x86_64 .../SRPMS/galeon-2.0.4-1.fc8.2.src.rpm : Installing:
gcc-c++ x86_64 4.1.2-33 fedora 3.7 M
make x86_64 1:3.81-10.fc8 fedora 482 k
redhat-rpm-config noarch 9.0.1-1.fc8 fedora 52 k
rpm-build x86_64 4.4.2.2-7.fc8 updates-released 303 k
tar x86_64 2:1.17-7.fc8 updates-released 911 k
unzip x86_64 5.52-6.fc8 updates-released 152 k
Installing for dependencies:
ConsoleKit-libs x86_64 0.2.3-3.fc8.1 updates-released 14 k
MAKEDEV x86_64 3.23-1.2 fedora 135 k
...
Transaction Summary
=============================================================================
Install 98 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 95 M
Ceci est l'installation du minimum.
Puis mock installe ce qui est spécifique pour la construction de galeon : =============================================================================
DEBUG util.py:250: Package Arch Version Repository Size
=============================================================================
Installing:
ccache x86_64 2.4-11.fc8 fedora 53 k
firefox-devel x86_64 2.0.0.12-1.fc8 updates-released 3.5 M
gettext x86_64 0.16.1-12.fc8 fedora 1.5 M
gnome-desktop-devel x86_64 2.20.3-1.fc8 updates-released 38 k
intltool x86_64 0.36.2-1.fc8 fedora 89 k
Installing for dependencies:
ConsoleKit x86_64 0.2.3-3.fc8.1 updates-released 56 k
GConf2 x86_64 2.20.1-1.fc8 fedora 1.6 M
...
Transaction Summary
=============================================================================
Install 202 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 115 M
Rien que pour construire Galeon, il y a 300 (!) dépendances !!! Soyons gentil et disons qu'on trouve ses 300 dépendances dans 100 paquets src.rpm.
Tu nous expliques que Galeon va être recompiler dès qu'un de ses 100 paquets est recompilé. Ceci est pour moi de la "foutaise".
Enfin, il y a les problèmes de dépendance cyclique et j'aimerai bien savoir comment fait OpenSuSE pour gérer ça...
Et que ce passe-t-il si une mauvaise version de libc est introduite ?
Tout est recompilé, tout échoue, et tout est cassé.
> qu'il se passe. Heureusement, la libc et gcc ne changent pas trop pour une version stable, mais il en est autrement pour les builds Factory
Et non Fedora ne recompile pas tout dans ce cas.
*Parfois* Fedora fait des recompilations de tous les paquets (typiquement lors d'un changement majeur de version de compilo, etc). Quand ça arrive, ça devient un projet à lui seul tellement c'est lourd à gérer (beaucoup de paquet plante à la compilation, etc).
En passant, la compilation d'OOo chez Fedora (i386/x86_64/ppc/ppc64) prend 8 heures ! Nombre de dépendance 387 !
Si à chaque changement d'une dépendance il faut recompiler OOo, ben tu le recompiles tous les 2 jours au minimum
Mais il y a "pire", c'est la bande passante. Les utilisateurs (mirroirs compris) ne vont absolument pas aprécier d'avoir à downloader des centaines de Mo car un paquet a été mis à jour.
Fedora ne recompile pas systématiquement et c'est déjà vraiment, vraiment limite (pas seulement pour Fedora, mais pour les mirroirs et les utilisateurs). Donc je ne crois pas qu'OpenSuSE recompile tout si une dépendance change. Ou alors OpenSuse est sur une autre planète et ce n'est pas la mienne.
Je ne sais pas ce qu'il t'a fait...
Et pourquoi tu tiens tant à voir PackageKit dans Anaconda ?
L'installeur c'est "one shot". Ça doit marcher en mode non intéractif et en mode texte.
Où est l'absolue nécessité d'avoir PackageKit dans Anaconda ?
> (voire même de le remplacer jusque dans Anaconda l'installeur)
Faut pas s'emballer. Si ça arrive ça ne sera probablement pas avant F11.
L'intérêt dans le cas de l'installeur est très limité. PackageKit ne remplace pas yum, c'est plus de complexité pour l'installeur (dbus, des tas de librairie, ConsoleKit, etc).
> Ce système est dérivé du Click'N'Run, que Linspire (anciennement Lindows) a développé et utilisé depuis bien 5 ans.
Faudrait pas s'extasier sur ce type de truc.
Il y a une tripotée d'année (à l'époque Fedora n'existe pas) lorsqu'on cliquait sur un rpm dans mozilla, le paquet s'installait (demande de mot de passe, résolution des dépendances, etc).
C'était simplement mozilla qui était configuré pour lancer "redhat-config-package url" lorqu'une url type rpm était demandée.
Voilà, c'était rien de plus.
> Les bénéfices, pour une distribution grand public sont conséquent et je pense que cette pratique sera étendue à la plupart des distributions.
Je ne crois pas. Ça va surtout intéresser les kékés.
> Toute l'infrastructure du Build Service tourne sur plus d'une centaine de machines généreusement données par AMD au projet openSUSE
Et pourquoi pas des milliers !
Pour Fedora (compilation i386, x86_64, ppc et ppc64), il n'y a "que" dix machines (certaines virtuelles) : http://koji.fedoraproject.org/koji/hosts
Et tout y est compilé, ce n'est pas que dédié "extras". La distribution y est compilé, les mises à jours, les contributions externes, rawhide, etc.
> Le Build Service a de multiples avantages :
> - Il resoud automatiquement les dépendances des paquets compilés.
Ce n'est pas un avantage, c'est une nécessité.
> Ainsi, si un paquet B dépend d'un autre paquet A, le paquet B va être automatiquement recompilé si la dépendance A est modifiée et recompilée.
"Foutaise".
Presque tous les paquets dépendent de libc ou gcc. Si libc ou gcc est changé, tu nous expliques que le build système va recompiler tous les paquets !
Et comment tu fais pour gérer les versions ? Ben oui, il va y avoir des toto-1.0-1 avec différent libc et gcc. Ça sucks.
Bref, ce truc je n'y crois pas.
> En comparaison, un mirroir ubuntu entier (incluant ISO) pèse ~ 260Go, debian (sans ISO) pèse ~320Go
Pour info :
Le mirror Fedora sur fr2.rpmfind.net (rawhide, et "seulement" F7 et F8) : 480 Go.
> PackageKit n'est pas sponsorisé, mais le projet semble intéresser Red Hat, openSUSE
Le mainteneur est un développeur Red Hat il me semble.
Pour l'instant il n'est pas prévu que PackageKit remplace Pirut, etc. PackageKit sera fournit avec F9.
> te donne rendez vous pour le prochain, qui traitera de façon pas trop superficielle les algorithmes de résolution des dépendances, les limites actuelles et peut être quelques solutions prometteuses.
Merci pour le temps que tu consacres à faire ces bons articles.
Mais il me semble qu'un aspect est "négligé". C'est la qualité, une vue d'ensemble. Fedora ne permet pas à tout le monde de compiler sur koji pour des raisons de qualité. Un paquet est accèpté qu'après un audit sérieux du paquet (licence, état de l'art, es-ce une technologie obsolète ou pas, etc).
Ça s'inscrit dans un projet qui a des objectifs. Ça fédère dans gens autour de ces objectifs. Ce n'est pas une libre service. C'est un mal et c'est un bien. Limiter les fonctionnalités (par exemple ne pas permettre à tout le monde de compiler) n'est pas forcément un mal.
Pour les algorithmes de résolution, il y a des "astuces" qui semblent moins sucker. Mais au niveau rigueur, c'est plus douteux (par exemple smart qui downgrade un paquet pour en installer un autre).
Qui peut le plus plus peut le moins. Mais ce n'est pas forcément pour le meilleur.
[^] # Re: T'as raison
Posté par IsNotGood . En réponse au journal Comme soupconne OSP est une arnaque!. Évalué à 7.
Si c'est compatible GPL, c'est une super assurance pour le libre. Plusieurs procès ont été gagnés pour faire respecter le caractère libre d'un programme. Tous ce qui est compatible GPL est bon pour le libre.
Mais OSP ce n'est pas compatible GPL. Et soit convaincu que la FSF le regrette mille fois plus que MS... MS doit être bien content que ça ne soit pas compatible GPL.
> Bon les gars, faut oublier ODF, il est incompatible avec la GPL.
Mais la SFLC (Software Freedom Law Center) suit ça comme d'autres. Et ce n'est pas un traitement de faveur envers Sun. Sun a sorti la CDDL, ben elle n'est pas compatible GPL (au moins Sun, contrairement à MS, n'est pas faux cul au point de dire le contraire). La FSF a aussi longtemps critiqué la "java trap" (qui aujourd'hui n'existe plus).
> Bon les gars, faut oublier ODF, il est incompatible avec la GPL.
Tu oublies (exprès) que OOo est sous GPL. T'es prêt à tout pour tailler des pipes à MS et FUDer sur les autres.
Mieux, OOo pour la version 3 (à partir de la première beta) sera GPLv3. Donc il n'y aura pas d'accord de trou du cul de minable à la MS/Novell.
Les brevets que met Sun dans OOo sont (vraiment) irrévocablement disponibles aux programmes GPL (et contrairement à OSP, pas seulement aux programmes qui implémentent la spec ODF).
Donc pour, par exemple ODF 2.0 et si Sun se désengage d'ODF (pûr délire ceci dit), tout ce qu'il faut c'est ne pas _ajouter_ des brevets de Sun qui ne sont pas dans les versions précédentes des spècs d'ODF.
Donc arrête ton FUD de merde.
Tu n'es ici que pour propager le FUD de MS et ça devient vraiment puant.
Tu bosses pour MS, tu le sais que MS est le roi des faux cul lorsqu'il sagit du logiciel libre. Tu deviens de plus en plus minable.
Open Friendly Baromètre :
- Sun : 9,8 / 10
- MS : 0,1 / 10
FUD Baromètre :
- Sun : 2 / 10
- MS : 10 / 10 (bravo MS)
# Re:
Posté par IsNotGood . En réponse au journal Réponse à des gens qui n'ont pas assez réfléchi. Évalué à 10.
Espérons que ça n'annonce pas la destruction totale de l'univers.
[^] # Re: Consommation
Posté par IsNotGood . En réponse au journal Firefox et consommation de mémoire. Évalué à 0.
Grief, faut pas pousser.
De toute manière, il y aura toujours plein de monde pour gueuler que ça bouffe trop de mémoire, que ce n'est pas assez rapide, que X boote plus vite que Y et que ça change tout. Pourquoi ? Pas que la consommation mémoire soit telle qu'elle est insupportable, mais simplement pour dire "j'en ai une plus grosse que la tienne", "j'en un programme techniquement bien foutu et réalisé par des pointures", "je sais apprécier ces exploits technique et pas toi", etc.
Les optimisations c'est très bien. Mais que le "grief principale" soit réglé en le réduisant de 15 % ça laisse songeur. Ça prête à réflexion.
# Re:
Posté par IsNotGood . En réponse au message Ca existe un GIMP light?. Évalué à 5.
Non.
Par contre un autre truc qui n'est pas Gimp, qui ne fait pas ce que fait Gimp, etc et qui est plus léger et plus simple ça existe peut-être.
[^] # Re: Ciol _o/
Posté par IsNotGood . En réponse au journal Le manifeste du parti linuxien, résumé pour ceux du fond qui n'écoutent pas. Évalué à 1.
[^] # Re: Ciol _o/
Posté par IsNotGood . En réponse au journal Le manifeste du parti linuxien, résumé pour ceux du fond qui n'écoutent pas. Évalué à 2.
Dont la source est :
http://www.redhatmagazine.com/2008/02/04/tips-and-tricks-rhe(...)
Red Hat’s customer service and support teams receive technical support questions from users all over the world. Red Hat technicians add the questions and answers to Red Hat Knowledgebase on a daily basis. Access to Red Hat Knowledgebase is free. Every month, Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries. The information provided in this article is for your information only. The origin of this information may be internal or external to Red Hat. While Red Hat attempts to verify the validity of this information before it is posted, Red Hat makes no express or implied claims to its validity.
Bref, c'est d'une base de connaissance de Red Hat et il y a un webmaster qui a pioché au hazard. Sûr que cette entrée dans la base de connaissance de Red Hat est pour ceux qui écrivent la doc, s'occupe des sites web, etc...
http://blogs.the451group.com/opensource/2008/03/06/red-hat-b(...)
Red Hat branding police outlaws RHEL
N'importe quoi.
C'est dingue cette manie qu'on les gens pour sauter sur toutes les boulettes de Red Hat et en faire l'affaire du siècle.
[^] # Re: Ciol _o/
Posté par IsNotGood . En réponse au journal Le manifeste du parti linuxien, résumé pour ceux du fond qui n'écoutent pas. Évalué à 5.
J'ai utilisé Slack, j'ai utilise SuSE, j'ai beaucoup testé Debian (c'était il y a longtemps), j'ai beaucoup testé Gentoo, j'ai un peu testé Mandr(ake|iva) et j'ai aussi testé Ubuntu. Notons qu'il y a la distribution et le projet. Linspire est peut-être une formidable distribution, mais je n'aime pas le projet. Je fous d'office tout ce qui a un accord avec MS (Xandros, Novell/Suse, TurboLinux, Linspire) à la poubelle.
Bref, il faut faire un choix avec son cerveau, pas à cause de la mode.
En passant, j'utilse Fedora/CentOS/RHEL. Ça me convient le mieux.
# Impressionnant
Posté par IsNotGood . En réponse au journal Unbuntu sous Virtual Box. Évalué à 3.
D'ailleurs j'ai installé une Ubuntu 7.10 et une 8.04 (alpha ?) pour tester vite fait.
Bilan : Ubuntu boote vite.
Mais comme je ne passe pas ma journée à booter...
[^] # Re: Un peu trop guerrier
Posté par IsNotGood . En réponse à la dépêche GNOME 2.22 : évolution perpétuelle. Évalué à -5.
[^] # Re: Fedora
Posté par IsNotGood . En réponse au journal Diverses choses sur les packages managers. Évalué à 3.
> Je suis sous Fedora 8 et quand je clic sur un simple lien RPM sur internet, il est telechargé, on me demande le mot de passe et une interface graphique
C'est un truc qui existe depuis Red Hat 7.2 !
À l'époque c'était redhat-config-package (pas terrible ceci dit) qui était utilisé.
> Tu présentes le One-clic-Install comme une super nouveauté.
Ben ceux qui n'ont jamais utilisé Red Hat/Fedora le pensent.
# Re:
Posté par IsNotGood . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 4.
Je ne peux parler pour les autres distributions, mais c'est déjà le compilateur de (la future) F9.
Tout (noyau compris) a été compilé avec gcc 4.3 (et deux fois car au premier essai il y avais un bug :-)), depuis plusieurs semaines gcc 4.3 est intensivement testé.
L'aide des distributions pour les tests est plus que précieuse. Ça fait aussi plein plein de remontés upstream.
[^] # Re: Je suis paresseux
Posté par IsNotGood . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 0.
Je ne connais pas ADA ni Ruby, je ne les critique pas. Tu vois la nuance ?
[^] # Re: PackageKit: le début de la collaboration inter-distribution ?
Posté par IsNotGood . En réponse au journal Diverses choses sur les packages managers. Évalué à 2.
C'est la seconde fois que du nomme explicitement Jeremy Katz dans des propos relatifs à PackageKit.
Le faire intervenir aujourd'hui (encore) parait pour le moins "saugrenu".
Et pourquoi que lui ? Es-ce que Fedora dans son ensemble est convaincu que PackageKit va tout remplacer à moyen terme ?
Je ne crois pas.
Ni aura-t-il pas quelques rétissances à ajouter PackageKit à Anaconda alors qu'Anaconda bouffe déjà un peu trop de mémoire ? Et ceci (ainsi que d'autres aspects) va au-delà de seulement l'avis de Jeremy Katz.
Et qu'on se comprenne bien, je n'ai rien contre PackageKit. Je me suis peu documenté, mais il parait pour le moins bien conçu et ergonique. Il a les qualités pour ralier d'autres développeurs de diverses distributions et c'est vraiment excellent.
Mais programmer l'enterrement de pirut/etc aujourd'hui est saugrenu.
Yum (avec yum-updatesd, les applets qui vont bien, pirut, etc) a mis des années (yum est dans Fedora par défaut depuis FC1 !).
Il ne faut pas enterrer pirut/etc à priori. Mais à posteriori. C-à-d après que PackageKit (ou un autre) ait prouvé sa valeur. D'autant plus que pour l'instant Fedora (et/ou Red Hat) n'a pas donné de signe qui indique que Fedora a une vision pour PackageKit (contrairement à Xen vs KVM par exemple). Pour l'instant Fedora va donner sa chance à PackageKit pour F9 (et suivant évidemment). PackageKit le mérite largement et c'est totalement dans l'esprit Fedora.
Si tu fais une news sur F9, n'hésite pas à mettre un projecteur (et un gros) sur PackageKit.
Mais ne sous-entend pas que les ambitions de PackageKit sont contrariées par Jeremy Katz :-)
[^] # Re: Un peu trop guerrier
Posté par IsNotGood . En réponse à la dépêche GNOME 2.22 : évolution perpétuelle. Évalué à -10.
Es-ce que Gnome brule les livres sur les interfaces ?
Es-ce que Gnome prétend faire une race supérieure de bureau et exterminer tout le reste ?
Es-ce que Gnome fait sa propagande dans les écoles pour tout petit ?
Es-ce qu'on ne peut pas circuler librement si on n'a pas une carte Gnome ?
Merde alors, arrêtez de reprendre des propos stupides de Linus. Tout Torvalds qu'il est, il dit aussi des conneries (qu'il n'a pas répété).
[^] # Re: gcc lave plus blanc ?
Posté par IsNotGood . En réponse à la dépêche Sortie de GCC 4.3. Évalué à -1.
Simple, la majorités des gens ne comprend pas C++ et est trop fainéante pour l'apprendre. Au-lieu de reconnaitre sa paresse, ben elle critique (sans savoir tout le géni qu'il y a dans C++).
[^] # Re: gcc lave plus blanc ?
Posté par IsNotGood . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 4.
Cette réthorique remet en cause l'intérêt des standards (des vrais, pas des bouses comme MS-OOXML).
Ça donne une vision simpliste du monde puis ça tire des conclusions.
MS est un excellent porte-parole des anti-standards...
> Donc un code qui serait « parfaitement propre » (d'après cette définition) et qui utiliserait toutes les fonctionnalités du standard ne marcherait nulle part. Trop cool !
N'importe quoi.
Enfin le standard donne des possibilités pour faire des choses non proposées par le standard. Le standard C/C++ ne dit rien sur l'assembleur. N'empêche qu'on peut ajouter de l'assembleur dans du C/C++. N'empêche que le standard C/C++ n'interdit pas les pragma. Etc.
Mais quand le standard dit que pour faire un truc bien précis, il faut le faire "comme ci", ben il faut le faire "comme ci" et pas "comme ça".
Le standard dit que pour ajouter deux variables, il faut utilisé l'opérateur "+". Inventer l'opérateur "⊕" pour concurrencer le standard est sans intérêt.
> Côté développement logiciel, c'est d'ailleurs plutôt le non-respect des standards qui assure une certaine portabilité.
N'importe quoi encore...
Ben le code Windows est super portable selon toi...
Ce qui fait la portabilité, c'est le respect des standards. Ce n'est pas en inventant des solutions dans son coin qu'on assure la portabilité. Linux s'appuit sur le standard Posix, les applis conçues pour Posix (applis Unix en général) se portent sans problème sur Linux (ou *BSD).
N'assassinez pas bêtement les standards alors que leur intérêt n'est plus à démontrer. Mais c'est comme tout, rien est parfait. Un standard doit continuellement être amélioré (d'où les implémentations qui sont toujours en retard sur le dernier standard).
[^] # Re: C'est pas Troll
Posté par IsNotGood . En réponse à la dépêche GNOME 2.22 : évolution perpétuelle. Évalué à 1.
[^] # Re: openSuse vs debian
Posté par IsNotGood . En réponse au journal Diverses choses sur les packages managers. Évalué à 2.
Pour Fedora, ça utilise les caractéristiques de rpm. wesnoth-1.2.8-2.fc8.i386.rpm, wesnoth-1.2.8-2.fc8.x86_64.rpm, etc.
Spécifiquement pour wesnoth il n'y a pas de wesnoth-data (le paquet n'a pas été fait ainsi, faut pas chercher midi à 14 h dans cet exemple).
Ici encore Fedora utilise les caractéristique de rpm (le champ ARCH).
Par exemple pour le noyau :
source : (généralement le même pour tout le monde)
kernel-2.6.24.3-12.fc8.src.rpm <= le même pour tout le monde
sur dépôt i386 :
kernel-2.6.24.3-12.fc8.i586.rpm
kernel-2.6.24.3-12.fc8.i686.rpm
...
kernel-doc-2.6.24.3-12.fc8.noarch.rpm <= le même pour tout le monde (hardlink)
sur dépôt x86_64 :
kernel-2.6.24.3-12.fc8.x86_64.rpm
...
kernel-doc-2.6.24.3-12.fc8.noarch.rpm <= le même pour tout le monde (hardlink)
Il n'y a pas de distinct "data" ou "programme", mais la distinction architecture indépendant (noarch).
Ainsi yum est le même pour tout le monde (aussi bien source que programme) :
source :
yum-3.2.8-2.fc8.src.rpm
sur dépôt i386 :
yum-3.2.8-2.fc8.noarch.rpm
sur dépôt x86_64 :
yum-3.2.8-2.fc8.noarch.rpm
Ce sont bien les mêmes, le md5sum peut le confirmer.
Mais on peut avoir des trucs surprenants. Par exemple toutes les traductions OOo sont architectures dépendants... Faut voir ça comme un bug upstream.
Un parquet n'est pas construit d'un coup. Par exemple pour kernel (Linux) il est contruit avec --target noarch (ce qui va être généré sera le même pour tout le monde), puis --target i586, puis --target i686, puis --target x86_68, etc...
[^] # Re: openSuse vs debian
Posté par IsNotGood . En réponse au journal Diverses choses sur les packages managers. Évalué à 3.
Non, ce n'est pas en comptant toutes les releases. Sur fr2.rpmfind.net, Fedora (rawhide + F7 + F8 + mise à jour) c'est 480 Go. Par contre fr2.rpmfind.net n'a les debuginfo que pour Rawhide. D'où probablement le fait que fr2.rpmfind.net ne fait pas 660 Go.
La GPL impose la disponibilité sur 3 ans des sources. Red Hat archive toutes les release sur un serveur (je ne sais plus où).
Serveur principale Fedora :
http://download.fedora.redhat.com/pub/fedora/linux/releases/
Il n'y a que F7 et F8 (qui sont les distributions actuellement maintenues).
[^] # Re: openSuse vs debian
Posté par IsNotGood . En réponse au journal Diverses choses sur les packages managers. Évalué à 3.
C'est le cas pour la grande grande grande majorité des paquets de Fedora. Les exceptions sont rarissimes (genre IcedTea qui ne tournait pas sur ppc).
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Diverses choses sur les packages managers. Évalué à 2.
CPU ou core ?
Si c'est core et pour des quadri-cores on tombe à 40 machines (ce qui reste impressionnant).
> Je sais, de source sûre, que cet utilisateur a compilé ces paquets dans le mois d'octobre 2007 et n'y a pas touché depuis.
Mouaif...
$ $ rpm -q --changelog -p kbde-1.1.6-9.36.src.rpm
attention: kbde-1.1.6-9.36.src.rpm: Entête V3 DSA signature: NOKEY, key ID 76edc1ff
* lun mai 14 2007 <valery_reznic@users.sourceforge.net> 1.1.5-1
- no real change - just to match kbde-driver version
Le dernier log n'est pas à jour (1.1.5-1 alors que le paquet est 1.1.6-9.36).
Le src.rpm a été reconstruit le 8 mars.
$ rpm -q -i -p kbde-1.1.6-9.36.src.rpm | grep "Build Date"
attention: kbde-1.1.6-9.36.src.rpm: Entête V3 DSA signature: NOKEY, key ID 76edc1ff
Release : 9.36 Build Date: sam 08 mar 2008 07:54:34 CET
> Factory sont datés de deux jours (samedi 8 mars 2008 vers 07h55 - mes sources indiques que l'utilisateur lambda cité dormait encore), soit grosso modo la date de la dernière recompilation de la Factory. Et c'est comme ça pour tous les builds Factory.
Ce qui ne montre rien. Pour koji et probablement comme pour OpenSuSE, les requêtes de construction de paquet sont empilés dans une file. Ce n'est pas excécuté de suite.
> Aussi, la Factory est recompilée (quasi) entièrement une à deux fois par semaine
J'y crois pas. Mais si je me trompe, tant mieux.
> Enfin, il me semble qu'entre la ligne du "c'est une nécessité" et la suivante "Foutaise" qui parle du même sujet, il y a une subtilité qui m'échappe..
C'est une nécessité que le système de build gère les dépendances _lors_ de la construction.
Exemple pour mock (compilation de galeon). Mock est utilisé par koji (Fedora) :
$ mock --rebuild --root=fedora-8-x86_64 .../SRPMS/galeon-2.0.4-1.fc8.2.src.rpm
: Installing:
gcc-c++ x86_64 4.1.2-33 fedora 3.7 M
make x86_64 1:3.81-10.fc8 fedora 482 k
redhat-rpm-config noarch 9.0.1-1.fc8 fedora 52 k
rpm-build x86_64 4.4.2.2-7.fc8 updates-released 303 k
tar x86_64 2:1.17-7.fc8 updates-released 911 k
unzip x86_64 5.52-6.fc8 updates-released 152 k
Installing for dependencies:
ConsoleKit-libs x86_64 0.2.3-3.fc8.1 updates-released 14 k
MAKEDEV x86_64 3.23-1.2 fedora 135 k
...
Transaction Summary
=============================================================================
Install 98 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 95 M
Ceci est l'installation du minimum.
Puis mock installe ce qui est spécifique pour la construction de galeon :
=============================================================================
DEBUG util.py:250: Package Arch Version Repository Size
=============================================================================
Installing:
ccache x86_64 2.4-11.fc8 fedora 53 k
firefox-devel x86_64 2.0.0.12-1.fc8 updates-released 3.5 M
gettext x86_64 0.16.1-12.fc8 fedora 1.5 M
gnome-desktop-devel x86_64 2.20.3-1.fc8 updates-released 38 k
intltool x86_64 0.36.2-1.fc8 fedora 89 k
Installing for dependencies:
ConsoleKit x86_64 0.2.3-3.fc8.1 updates-released 56 k
GConf2 x86_64 2.20.1-1.fc8 fedora 1.6 M
...
Transaction Summary
=============================================================================
Install 202 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 115 M
Rien que pour construire Galeon, il y a 300 (!) dépendances !!! Soyons gentil et disons qu'on trouve ses 300 dépendances dans 100 paquets src.rpm.
Tu nous expliques que Galeon va être recompiler dès qu'un de ses 100 paquets est recompilé. Ceci est pour moi de la "foutaise".
Enfin, il y a les problèmes de dépendance cyclique et j'aimerai bien savoir comment fait OpenSuSE pour gérer ça...
Et que ce passe-t-il si une mauvaise version de libc est introduite ?
Tout est recompilé, tout échoue, et tout est cassé.
> qu'il se passe. Heureusement, la libc et gcc ne changent pas trop pour une version stable, mais il en est autrement pour les builds Factory
Changement gcc (une fois par semaine) :
http://koji.fedoraproject.org/koji/packageinfo?packageID=40
Changement glibc (une fois toutes les deux semaines) :
http://koji.fedoraproject.org/koji/packageinfo?packageID=57
Et non Fedora ne recompile pas tout dans ce cas.
*Parfois* Fedora fait des recompilations de tous les paquets (typiquement lors d'un changement majeur de version de compilo, etc). Quand ça arrive, ça devient un projet à lui seul tellement c'est lourd à gérer (beaucoup de paquet plante à la compilation, etc).
En passant, la compilation d'OOo chez Fedora (i386/x86_64/ppc/ppc64) prend 8 heures ! Nombre de dépendance 387 !
Si à chaque changement d'une dépendance il faut recompiler OOo, ben tu le recompiles tous les 2 jours au minimum
Mais il y a "pire", c'est la bande passante. Les utilisateurs (mirroirs compris) ne vont absolument pas aprécier d'avoir à downloader des centaines de Mo car un paquet a été mis à jour.
Fedora ne recompile pas systématiquement et c'est déjà vraiment, vraiment limite (pas seulement pour Fedora, mais pour les mirroirs et les utilisateurs). Donc je ne crois pas qu'OpenSuSE recompile tout si une dépendance change. Ou alors OpenSuse est sur une autre planète et ce n'est pas la mienne.
[^] # Re: PackageKit: le début de la collaboration inter-distribution ?
Posté par IsNotGood . En réponse au journal Diverses choses sur les packages managers. Évalué à 2.
Je ne sais pas ce qu'il t'a fait...
Et pourquoi tu tiens tant à voir PackageKit dans Anaconda ?
L'installeur c'est "one shot". Ça doit marcher en mode non intéractif et en mode texte.
Où est l'absolue nécessité d'avoir PackageKit dans Anaconda ?
[^] # Re: PackageKit: le début de la collaboration inter-distribution ?
Posté par IsNotGood . En réponse au journal Diverses choses sur les packages managers. Évalué à 2.
Faut pas s'emballer. Si ça arrive ça ne sera probablement pas avant F11.
L'intérêt dans le cas de l'installeur est très limité. PackageKit ne remplace pas yum, c'est plus de complexité pour l'installeur (dbus, des tas de librairie, ConsoleKit, etc).
[^] # Re: Installation en un clic
Posté par IsNotGood . En réponse au journal Diverses choses sur les packages managers. Évalué à 4.
Faudrait pas s'extasier sur ce type de truc.
Il y a une tripotée d'année (à l'époque Fedora n'existe pas) lorsqu'on cliquait sur un rpm dans mozilla, le paquet s'installait (demande de mot de passe, résolution des dépendances, etc).
C'était simplement mozilla qui était configuré pour lancer "redhat-config-package url" lorqu'une url type rpm était demandée.
Voilà, c'était rien de plus.
# Re:
Posté par IsNotGood . En réponse au journal Diverses choses sur les packages managers. Évalué à 3.
Je ne crois pas. Ça va surtout intéresser les kékés.
> Toute l'infrastructure du Build Service tourne sur plus d'une centaine de machines généreusement données par AMD au projet openSUSE
Et pourquoi pas des milliers !
Pour Fedora (compilation i386, x86_64, ppc et ppc64), il n'y a "que" dix machines (certaines virtuelles) :
http://koji.fedoraproject.org/koji/hosts
Et tout y est compilé, ce n'est pas que dédié "extras". La distribution y est compilé, les mises à jours, les contributions externes, rawhide, etc.
> Le Build Service a de multiples avantages :
> - Il resoud automatiquement les dépendances des paquets compilés.
Ce n'est pas un avantage, c'est une nécessité.
> Ainsi, si un paquet B dépend d'un autre paquet A, le paquet B va être automatiquement recompilé si la dépendance A est modifiée et recompilée.
"Foutaise".
Presque tous les paquets dépendent de libc ou gcc. Si libc ou gcc est changé, tu nous expliques que le build système va recompiler tous les paquets !
Et comment tu fais pour gérer les versions ? Ben oui, il va y avoir des toto-1.0-1 avec différent libc et gcc. Ça sucks.
Bref, ce truc je n'y crois pas.
> En comparaison, un mirroir ubuntu entier (incluant ISO) pèse ~ 260Go, debian (sans ISO) pèse ~320Go
Pour info :
Le mirror Fedora sur fr2.rpmfind.net (rawhide, et "seulement" F7 et F8) : 480 Go.
> PackageKit n'est pas sponsorisé, mais le projet semble intéresser Red Hat, openSUSE
Le mainteneur est un développeur Red Hat il me semble.
Pour l'instant il n'est pas prévu que PackageKit remplace Pirut, etc. PackageKit sera fournit avec F9.
> te donne rendez vous pour le prochain, qui traitera de façon pas trop superficielle les algorithmes de résolution des dépendances, les limites actuelles et peut être quelques solutions prometteuses.
Merci pour le temps que tu consacres à faire ces bons articles.
Mais il me semble qu'un aspect est "négligé". C'est la qualité, une vue d'ensemble. Fedora ne permet pas à tout le monde de compiler sur koji pour des raisons de qualité. Un paquet est accèpté qu'après un audit sérieux du paquet (licence, état de l'art, es-ce une technologie obsolète ou pas, etc).
Ça s'inscrit dans un projet qui a des objectifs. Ça fédère dans gens autour de ces objectifs. Ce n'est pas une libre service. C'est un mal et c'est un bien. Limiter les fonctionnalités (par exemple ne pas permettre à tout le monde de compiler) n'est pas forcément un mal.
Pour les algorithmes de résolution, il y a des "astuces" qui semblent moins sucker. Mais au niveau rigueur, c'est plus douteux (par exemple smart qui downgrade un paquet pour en installer un autre).
Qui peut le plus plus peut le moins. Mais ce n'est pas forcément pour le meilleur.