> SuSE est un logiciel ouvert mais pas libre.
yast
> si toutes les boites vivant du libre raisonnait comme SuSE et faisait du 98 % libre, quelle gueule aurait ta SuSE ?
Si ça marche et que gnu/linux prend des parts de marché...
C'est pas tout blanc ou tout noir. suse a un modèle, debian un autre, redhat un autre, etc...
> SuSE par exemple n'aurait pas le gestionnaire de paquet qu'elle utilise...
Si suse n'était pas là, mandrake, debian, redhat, etc n'aurait pas alsa, reiserfs, etc.
Balle au centre.
> Ca peut paraitre mineur mais SuSE ne joue pas le jeu comme le fond les autres. Et ça, ça pourrait être vu comme un crachat dans la soupe, pour reprendre tes mots.
Ça c'est un bon argument. Si tu ne prends pas une suse pour ça, c'est compréhensible.
Pour le crachat, suse amène plein de choses au libre et bosse beaucoup, beaucoup plus sur du bsd/gpl que sur yast.
> quelle gueule aurait ta SuSE ?
J'utilise pas suse. Et si je n'utilise pas suse, c'est à cause de yast. Mais ce n'est pas une raison pour dire "suse ça pue, c'est pas libre" et ignorer son énorme contribution au libre.
Mandrake n'est pas français ?
Qui a mit ces américains ?
Et c'est "croire au libre" que d'engloutir des sommes colossales (de l'argent qui vient que gens pensaient investir dans le LL) dans le e-learning ?
Si mandrake se casse la gueule, ce n'est pas que de la faute des autres.
> je suis sidéré par tant de commentaires agressifs envers une société qui essaye de faire progresser Linux vers le bon chemin.
Ne t'inquiètes pas il y en a qui ont les oeils grands ouverts. Les résultats de suse le prouve.
Puis suse fait parti des pionniers de gnu/linux. A l'époque, il fallait y croire.
Presque autant.
Yast, il y a les sources (vérifier qu'il n'y a pas une backdoor et trou de sécurité), tu peux les modifiers (adapder, corriger un trou de sécurité), et tu ne peux pas diffuser contre de l'argent et ça pose un réel problème de diffusion par d'autres distributeurs. Je suis d'accord pour dire que yast n'est pas libre. Mais ce n'est pas un logiciel propriétaire qui répend un format propriétaire, qui a des brevets etc...
De plus, et c'est un point très important, suse n'a jamais eu une politique d'expansion dans le développement de logiciel non 100 % libre. Depuis le début de suse, yast n'est pas 100 % libre et depuis le début il n'y a que yast.
Et que je sache, mandrake, comme d'autre, dans la version boîte fournis des "vrais" programmes propriétaires et mandrakeclub permet d'acheter des programmes propriétaires.
Si mandrake est un peu plus un "ange", c'est de peu. Les devs de mandrake font 100 % de "vrai" logiciel libre et suse 98 %.
Et si on regarde la contribution au libre, suse a pratiquement fait 10 fois plus de contribution au libre (alsa, kde, reiserfs, linux, portage, etc) que mandrake. Et tous ces développement, mandrake en a profité.
Donc le "pragmatisme" de suse est bon pour le logiciel libre. Je dis pas que suse est dans le vrai et tout le monde doit faire pareil. Mais j'aime pas quand on crache dans la soupe. Surtout s'il y a plus de 95 % de libre dedans.
Prend n'importe quoi comme distribe. Par contre vires ce qui te sert à rien dans les services => /etc/rc.d et aussi les modules apaches que tu n'utilises pas.
Mais GNU/Linux est devenu un système très complexe (je parle pas de l'utilisation) et il faut des gens à temps plein. Et pour travailler à plein temps sur le logiciel libre, il faut être payé. S'il y avait beaucoup de donation à la FSF, les boîtes commerciales ne seraient pas nécessaires. Mais voilà le "hic". Si on regarde les projets complexes telque linux, gcc, une partie plus que significative vient de développeurs à plein temps. De même les infrastructures (serveurs, bande passante) viennent souvant des boîtes commerciales (sourceforge, sources.redhat.com).
Mais le logiciel libre s'appuis encore et pour longtemps massivement sur le "bénévolat".
Et de toute manière, je vois pas où est le problème que des boîtes commerciales qui font du logiciel libre trouve un modèle économique pour faire du pognon. Du moment que le pognon est principalement utilisé pour le logiciel libre...
Mais a l'avenir amène un minimum de respect. Surtout pour une boîte qui fait principalement du logiciel libre. T'es idéaliste, ce n'est pas un défaut. Mais quand une boîte suit à 95 % tes idéaux de logiciel libre (et les miens), que les produits sont développés sont sous GPL et largement utilisés et aide à l'établissement du logiciel libre, évite les "conneries" de ce genre :
- "Ximian > /dev/null"
Je ne suis pas totalement d'accord avec toi mais je ne vais pas écrire :
- "Houba houba Hop ! > /dev/null"
et mettre ça sur un journal public.
> la prochaine fois , pense a installer une distro qui gere les dependances nativement
Faut problème. rpm a toute les infos pour gérer les dépendances mais ne les résoud pas automatiquement. Redhat gère automatiquement les dépendances avec up2date qui est une surcouche de rpm et non un remplaçant.
> est-ce que ce que fait Ximian fait du bien au libre ou pas
Ximian fait du libre oui ou non ? OK, il y a un plugin exchange qui est propriétaire et c'est tout.
Faut pas mettre la charrue avant les beoufs. C'est MS-office qui est le plus utilisé (97%). Lorsque OOo sera autour de 20 % il faudrat peut-être réviser le format par défaut.
> et dans quelle mesure cela se répercute sur GNOME
Va faire un tour sur les mailing-list Gnome et tu auras la réponse. Puis c'est du GPL oui ou non ?
C'est pénible cette façon systématique de s'attaquer au boîtes commerciales pour des bricoles comme si elles avaient toutes plein de tune. Laissez aux boites commerciales qui font du LOGICIEL LIBRE un peu de l'attitude. Eazel a coulé, côté distribution n'y a que 2 boites qui tiennent la route : redhat et suze (et pour suze c'est pas facile). Mandrake "qui fait tout tout bien" a maintenant moins de 50 employés et ne contribe presque plus.
Le logiciel libre a besoin de tune et ça passe principalement par les boîtes commerciales.
Désolé, mais la "communauté" qui n'en manque pas "une", n'est pas un modèle de générosité pour la tune et n'a donc pas de leçon à donner aux boîtes commerciales qui font du LOGICIEL LIBRE.
> > Quand Mandrake ajoute un éditeur de menu à Gnome 2 pour la 9.1 qui n'est toujours pas dans le cvs gnome, tu es scandalisé aussi ?
> Je trouve ça dommage, mais Mandrake ne contrôle pas le CVS de GNOME. Si c'était le cas, ça me surprendrais d'autant plus.
Ben Ximian ne "contrôle" pas le CVS de Gnome. C'est des phantasmes. Il me semble que c'est redhat le plus gros fournisseur de matos pour gnome.org . Et que redhat contrôle le CVS de Gnome est aussi un gros phantasme.
> Tu utilises des LL depuis combien de temps ?
Ouh j'ai peur.
> Moi, quand j'ai connu Balsa, il existait et était fonctionnel. Evolution n'existait pas.
Super ! Moi quand j'ai connu elm, il existait et était fonctionnel. Balsa n'existait pas et ... Gnome non plus ... etc KDE non plus.
Mais être plus vieux n'est pas une qualité, c'est une fatalité.
> Il aurait très bien pu être possible, en investissant dans Balsa, d'y ajouter toutes les fonctionnalités qui ont été depuis mises dans Evolution.
Oui peut-être. Mais les faits sont là. Des gens ont bossé sur evolution et evolution est devenu populaire. C'est la vie.
Puis ce type de débat, c'est la même chose que KDE/Gnome. Comme Gnome est arrivé après y en a toujours un pour ramener sa fraise et dire que les devs de Gnome aurait mieux fait de bosser sur KDE que de faire un nouveau bureau.
C'est du LL et les gens bossent sur ce qu'ils veulent.
> Mais ça, c'est une question de choix.Mais le Ximian bidule n'a jamais proposé de distribuer aussi Balsa, lecteur de courriel officiel de GNOME
Ximian choisi ce qu'il veut. Ximian c'est pas le site ftp de Gnome.
> Je crois que décidement il te manque un bout de l'histoire. C'est Ximian à l'époque ou Ximian s'appellait Helix qui a décidé que leurs amis d'Eazel feraient Nautilus
Eazel existait avant Helix.
> On choisit des projets qui n'existent pas, qui n'ont pas fait leurs preuves..
C'est-à-dire ? La première fois qu'evolution était distribué, c'était la version 1.0 et ça existait et ça marchait.
Enfin, et mets toi ça dans la tête, balsa et evolution n'ont JAMAIS fait parti de Gnome. Et evolution ne fait toujours pas parti de Gnome. C'est une appli Gnome comme galeon est une appli Gnome.
Et si tu as evolution dans ta distribution, c'est le chois du distributeur de non de MDI, Ximian, Gnome, ou autre. C'est uniquement le chois du distributeur. OK.
> > Non, Mono ne fera pas avancer gnome.
> Si tu veux défendre MDI, lis au moins ce qu'il écrit.
Je peux ne pas être d'accord avec MDI. C'est pas une raison pour l'allumer sur tout et rien. C'est un mec qui a beaucoup contribuer au LL et pour ça il mérite un minimum de respet.
Sinon, et MDI le reconnait, il n'est pas question d'écrire Gnome en Mono. Mono est un langage supplémentaire comme perl, ada, python, C++, etc. Et MDI le reconnait (bien qu'au début de Mono il parlait d'écrire certaines parties de Gnome en Mono). Si Mono est un plus pour Gnome, c'est parce qu'il y aura des applis développé en C# et non car Gnome va être écrit en C#.
> Je pense que c'est surtout pour ceux qui sont déjà équipés en serveur Linux.
Ou qui connaissent déjà C# et veulent passer sous Linux ou rester sous Windows mais avec un C# dont les sources sont disponibles. Idem Samba.
> Kde est clairement loin devant et ils ont encore pas mal de pain sur la planche.
C'est parce que MDI ne bosse plus sur Gnome ?
Mais j'arrête, je suis tombé sur un fana de Kde qui passait par là pour casser du gnome.
Globalement je suis d'accord. Ces procès de MDI à répétition sont pénibles.
> MDI/Ximian n'influent pas sur GNOME et les développeurs GNOME n'influent pas sur MDI/Ximian.
Pas d'accord. Ximian influent sur GNOME et les développeurs GNOME influent sur Ximian. Idem pour sun et redhat.
Et il est normal que ceux qui bossent le plus influent le plus. Sinon pourquoi bosser si c'est pour que rien ne changer ?
> Sur un plan comportemental, on peut constater qu'il reprochait aux gens de KDE un manque de fidélité au libre pour des actes qui sont très loin de ce qu'il fait aujourd'hui.
Le reproche c'était Qt quand il était pas sous GPL.
Et il fait quoi aujourd'hui à part un plugin exchange propriétaire pour accéder à un serveur propriétaire ?
> Maintenant, son produit s'appelle "Ximian Desktop"
Et alors ?
> Il a court-circuité les distributeurs - en créant sa méta-distribution
Quand Mandrake ajoute un éditeur de menu à Gnome 2 pour la 9.1 qui n'est toujours pas dans le cvs gnome, tu es scandalisé aussi ?
Faut bien vivre. Si tout son boulot il le donne en premier aux distributions, il fait comment pour gagner de l'argent qui paye des développeurs qui font du code GPL ?
> pour imposer son Evolution à une heure ou il n'existait pas face à un Balsa déjà fonctionnel
Si Evolution est plus utilisé que Balsa, c'est parce qu'il est adapté à un plus large public. Je préfère de loin Evolution à Balsa (agenda, carnet d'adresse, LDAP, etc...). Merci Ximian.
> en gérant le contenu réel de GNOME par ce biais
"out of range" sur mon trollomètre.
> il était dit dans la dernière depeche qu'on y trouve des éléments qui seront "peut-être" dans GNOME
Parce que le projet Gnome n'est pas obligé d'intégrer toutes les modifications Ximian. Ce qui prouve que ce n'est pas Ximian qui dirige Gnome. Pour la redhat 8.0 il s'est écoulé plusieurs mois pour que toute les modifs redhat soit intégrées. Et certaines modifs n'ont pas été intégrées.
> Tout ceci, est-ce que ça à fait avancer GNOME ou tout simplement à assis Ximian dans une position (controle unilateral de GNOME) de toute façon bancale mais acceptable pour ses actionnaires ?
A merde! Tu fais chié t'as pété mon trollomètre.
> Et je ne parle même pas de cette épave de Nautilus, proclamé gestionnaire de fichiers de GNOME à coup de capture d'écran.
C'est pas ximian qui a fait Nautilus...
Eazel ne maintient plus Nautilus et Ximian n'a jamais maintenu Nautilus.
> vous y croyez, que Mono va faire avancer GNOME ?
Non, Mono ne fera pas avancer gnome.
Mono utilise Gnome (surtout Gtk+) et non l'inverse. Par contre pour les développeurs d'application, ça peut être cool d'avoir un environnement libre (petit problème de brevet potentiel) qui tourne partout (comme java mais en mieu et avec les sources).
> le développement de Gnome est beaucoup plus efficace depuis qu'il n'y est plus pour forcer les autres développeurs à suivre à tout prix ses délires visionnaires.
C'est marrant car Gnome 2 n'a pas fait l'hunanimité au début. loin de là. Puis si tu crois que MDI a fait 90 % du développement de Gnome 1.x, tu te mets le doigt dans l'oeil.
> Appeler un système GNU/linux au lieu de Linux est une concession tellement infime par rapport à tout ce qu'il nous apporte.
Si c'était le seul, je comprendrais ta colère. A part Debian, il n'y a presque personne qui utilise GNU/Linux.
Ton courroux prouve que MDI est au moins un excellent communicant.
Si c'était un nul, il ne serait pas autant suivi. Ok pour reprocher ces chois mais pas ok pour dire que c'est un con et un "traitre".
C'est un article tout petit et sans grand intérêt.
L'article ne souligne pas sa cible (le gus (un peu neuneu) qui veut passer de Windows à Linux). Rien pour les entreprises par exemple, serveur, développeur, amateur, etc...
Pour les mises à jour "automatiques" 'up2date' de RedHat est gratuit pour une machine pour une adresse mail (ya un formulaire de 3 questions maxi tout les 2/3 mois à remplir). Et pour ceux qui ont plus d'une machine, il y a apt ou yum.
C'est la version serveur qui est payante (redhat linux enterprise). Les mises à jours peuvent être gratuites mais il n'y a que les src.rpm.
> Mandrake est l'une des trois distributions les plus utilisées.
> ce n'est pas qu'il faut banir la doc, loin de là, mais pourquoi ne trouve-t-on pas ou peu de doc sur ce que j'ai presque envie d'appeler les "bonnes façons de coder" ?
C'est comme le "bon parlé", ça n'existe pas :-)
Pour la doc, je te conseilles très vivement les pages info de la libc. C'est accessible en ligne de commande avec "info libc" ou "gnome-help info:libc" (et de 50 autres façons différentes). La libc te donne les éléments de base d'un système Unix et ça peut te resservir avec tout les autres languages.
Le timestamp, n'est pas nécessaire pour logrotate. Et logrotate peut même te gérer des fichiers binaires au format "stupide".
> Ainsi peu importe ce qu'il se passera note deamon n'auras _jamais_ le probleme du manque de plus de place sur le disque, ou de gerer un eventuel SIGHUP, ou de bien tout fermer en redamarrant completement.
J'ai rien contre les nouveaux systèmes, mais l'actuel est correct. S'il était "tout pourri" et devait être "bannit", il ne serait plus là depuis un moment.
> 'rotatelogs' au final complique la vie du programmeur.
Suffit de trouver un moyen pour ouvrir et fermer les fichiers logs pour les processus qui sont "résidants". Pas plus.
Je n'ai pas dit que logrotate était génial. J'ai seulement dit que j'aime bien.Le probleme ce n'est pas ca.
> Ce n'est pas non plus sa reentracy c'est que le random associe est completement pourri. Du man:
> BUGS
> Never use this function. Use mkstemp(3) instead.
C'est les pages infos qui font références. Je voulais dire que tmpnam() n'est pas un problème de sécurité si c'est bien utilisé (attention à l'umask entre autre). Je l'ai utilisé à une époque où il n'y avait pas le choi. mkstemp est meilleur, c'est claire.
Mais le mieux est d'utiliser tmpfile(). Avoir des noms de fichier, c'est pour le communiquer à d'autre processus.
> un const char * comme argument. Entre deux appels le fichier decrit par le parametre peut etre devenu un lien symbolique ou hard sur autrechose...
Il faut donc toujours travailler avec des fd.
Juste.
Plus globalement, je ne nie pas qu'il y a de meilleurs solutions. Mais tu critiques syslog, parles d'apache alors qu'apache n'utilise pas syslog etc... De plus apache utilise plusieurs fichiers de log (access, error, referer, ssl, etc...) (Et le format n'est pas dicté par syslog ou logrotate!). Tu critique l'utilisatation de /var/run/httpd.pid, alors que c'est aussi là pour avoir plusieurs serveurs web sur une même machine (dont un en chroot par exemple). Désolé mais tu fais dans le FUD (bannir syslog, tmpnam, etc...) pour caser des solutions plus innovantes et ça me gonfle.
Longue vie aux daemontools etc... qui font peut-être parti de l'avenir d'Unix/Linux. Mais c'est pour pour autant que l'existant est de la "merde" et n'a pas certains bénéfices. Je sais, je suis dure.
Bon, on va pas se facher. C'est beaucoup une histoire de "goûts et couleurs" et d'habitude.
> Les signaux sont asyncrhones, lorsqu'un SIGHUP est delivre le handler de ce signal est appele, le signal SIGHUP est bloque, par contre si ce handler mets du temps a s'executer, et qu'un autre signal arrive, l'autre handler va etre execute.
man sigaction :
"sa_mask gives a mask of signals which should be blocked during execution of the signal handler. In addition, the signal which triggered the handler will be blocked, unless the SA_NODEFER or SA_NOMASK flags are used."
> plutot que l'infame methode utilisee par rotatelogs...
C'est ton avis. J'aime bien logrotate.
> le programme htpasswd fait usage de tmpnam(). D'apres son man elle n'est pas vraiment recommandee ...
info libc :
"Temporary Files
===============
If you need to use a temporary file in your program, you can use the `tmpfile' function to open it. Or you can use the `tmpnam' (better: `tmpnam_r') function to provide a name for a temporary file and then you can open it in the usual way with `fopen'. "
man tmpnam :
"If the argument s is NULL this name is generated in an internal static buffer and may be overwritten by the next call to tmpnam(). If s is not NULL, the name is copied to the character array (of length at least L_tmpnam) pointed at by s and the value s is returned in case of success."
Le problème c'est d'utiliser tmpnam(NULL).
de /usr/include/stdio.h :
"/* This is the reentrant variant of `tmpnam'. The only difference is
that it does not allow S to be NULL. */
extern char *tmpnam_r (char *__s) __THROW;"
> Pourquoi donc ce n'est pas la panacee ?
Parce qu'il faut réécrire un système pour loguer. Car il faut mettre en place un système pour communiquer avec le nouveau système pour loguer. Car par rapport à un système qui écrit directement dans un descripteur de fichier, c'est moins performant.
> Ensuite les pipe sous linux c'est PIPE_BUF: 4096 atomiquement.
Si les processus sont frères et/ou que les processus clients peuvent "mourrir" tu ne peux pas utiliser de pipe (ou alors il faut utiliser des pipes nommés).
> Les ipc permettent le 'privilege separation' qui _doit_ etre utilise tout le temps que c'est possible.
?
> Quid de la rotation de logs ? (cf premier message)
Tu passe par syslog, puis tout les journaux de syslog sont "rotationné" par logrotate toute les nuits. Aucun problème.
> Quid du format du timestamp ? (cf premier message)
Oui. Mais c'est pas un drame. De plus il ne doit pas être difficile de corriger ça si c'est indispensable.
> Quid des personnes ne sachant pas utiliser les formats ? (cf premier message)
Si c'est pour des logs apache (/var/log/httpd/access_log par exemple), le format est sous le contrôle d'apache. Si tu passes par syslog, rien ne d'interdit d'ajouter la date dans le format qui te plais.
> Syslog est a bannir.
Je me marre. Fait un "man syslogd" et "man syslog.conf".
exemple :
"Named Pipes
This version of syslogd(8) has support for logging output to named pipes (fifos)."
"Terminal and Console"
"Remote Machine
This syslogd(8) provides full remote logging, i.e. is able to send messages to a remote host running syslogd(8) and to receive messages from remote hosts. The remote host wont forward the message again, it will just log them locally. To forward messages to another host, prepend the hostname with the at sign (@).
Using this feature youre able to control all syslog messages on one host, if all other machines will log remotely to that. This tears down administration needs."
Avec pipe, rien ne t'empêche de faire un programme qui écoute le pipe (sur une autre machine si tu veux) et de logguer les messages dans une base de donnée et jamais d'utilisation de logrotate et en même temps d'avoir les logs en directe pour les consoles sous toto. Le possibilités sont nombreuses. Mais si tu veux coder un autre syslog, te gène pas.
> par exemple funlink() utilisant un fd au lieu d'une chaine. Pour eviter les problemes de 'race condition' que l'on trouve avec toutes les fonctions basees sur le nom.
Quels sont les problèmes ?
Aucun. La chaine passée à unlink n'est pas interprété. C'est totalement différent de system() par exemple. Puis pourquoi pas virer toutes les fonctions qui attende un char * (open() ?). Utilise dmalloc si tu as "peur". Mais attention, les performances vont en prendre un sérieu coup...
> Un daemons est cense rester actif tout le temps.
C'est le cas pour apache. Lors d'un logrotate, le processus père (pid : /var/run/httpd.pid) reçoit un SIGHUP. Ce processus père tue "en douceur" les fils (il laisse les requêtes se terminer (sauf les longues requêtes)) mais le processus père n'est pas tué !. Lorsque tous les fils sont morts, le père relance des fils. Les requêtes arrivées durant cette phase reste en attentes mais aucun client ne perçoit un service arrêté.
Faire un process frère pour les logs n'est pas la panacée. Il faut mettre en place des moyens de communication entre le processus qui fait les logs et ces frères (ipc surement puisque ce sont des frères).
De plus ta demande d'avoir des deamons qui tourne 24h/24 peut être très facilement faite en utilisant syslog(3). Par contre c'est plus coûteux en temps.
> Reclamez l'implementation d'un syscall unlink() utilisant un fd et non plus un const char * (;p)
Ça n'a aucun sens.
exemple :
$ mon_prog toto &
$ ln toto titi # lien hard
$ mv toto tata
mon_prog crée et ouvre toto. 2 minutes après il faut un hypotétique unlink(fd). Que doit faire l'OS ? suprimer titi et tata ? Et si toto est un lien symbolique ? Et si fd est un pipe ?
> si les gens incompétents arrêtaient d'utiliser des languages de progs où chaque manipulation de chaines de caractères est un trou de sécurité potentiel
Faut se même dans la tête qu'il y a toujours un moment ou il faut "prendre des risques". Si tu fais un serveur web en C++, tu as surement une fonction "query_string_2_Qstring()" qui te retourne un objet string mais qui a forcément fait des manipulations avec malloc/strcpy etc.
De même, c'est pas parce que tu utilises du php qu'il n'y aura pas de problème.
[^] # Re: \o/ SuSE SAPULEPATE CAI PAS LIBRE \o/
Posté par Linux_GTI . En réponse à la dépêche Desktop, OEM : SuSE passe à l'offensive. Évalué à 3.
yast
> si toutes les boites vivant du libre raisonnait comme SuSE et faisait du 98 % libre, quelle gueule aurait ta SuSE ?
Si ça marche et que gnu/linux prend des parts de marché...
C'est pas tout blanc ou tout noir. suse a un modèle, debian un autre, redhat un autre, etc...
> SuSE par exemple n'aurait pas le gestionnaire de paquet qu'elle utilise...
Si suse n'était pas là, mandrake, debian, redhat, etc n'aurait pas alsa, reiserfs, etc.
Balle au centre.
> Ca peut paraitre mineur mais SuSE ne joue pas le jeu comme le fond les autres. Et ça, ça pourrait être vu comme un crachat dans la soupe, pour reprendre tes mots.
Ça c'est un bon argument. Si tu ne prends pas une suse pour ça, c'est compréhensible.
Pour le crachat, suse amène plein de choses au libre et bosse beaucoup, beaucoup plus sur du bsd/gpl que sur yast.
> quelle gueule aurait ta SuSE ?
J'utilise pas suse. Et si je n'utilise pas suse, c'est à cause de yast. Mais ce n'est pas une raison pour dire "suse ça pue, c'est pas libre" et ignorer son énorme contribution au libre.
[^] # Re: Voilà une nouvelle qui devrait ravir tous les partisans du libre.
Posté par Linux_GTI . En réponse à la dépêche Desktop, OEM : SuSE passe à l'offensive. Évalué à -1.
Mandrake n'est pas français ?
Qui a mit ces américains ?
Et c'est "croire au libre" que d'engloutir des sommes colossales (de l'argent qui vient que gens pensaient investir dans le LL) dans le e-learning ?
Si mandrake se casse la gueule, ce n'est pas que de la faute des autres.
[^] # Re: Desktop, OEM : SuSE passe à l'offensive
Posté par Linux_GTI . En réponse à la dépêche Desktop, OEM : SuSE passe à l'offensive. Évalué à 1.
Ne t'inquiètes pas il y en a qui ont les oeils grands ouverts. Les résultats de suse le prouve.
Puis suse fait parti des pionniers de gnu/linux. A l'époque, il fallait y croire.
[^] # Re: \o/ SuSE SAPULEPATE CAI PAS LIBRE \o/
Posté par Linux_GTI . En réponse à la dépêche Desktop, OEM : SuSE passe à l'offensive. Évalué à 5.
Yast, il y a les sources (vérifier qu'il n'y a pas une backdoor et trou de sécurité), tu peux les modifiers (adapder, corriger un trou de sécurité), et tu ne peux pas diffuser contre de l'argent et ça pose un réel problème de diffusion par d'autres distributeurs. Je suis d'accord pour dire que yast n'est pas libre. Mais ce n'est pas un logiciel propriétaire qui répend un format propriétaire, qui a des brevets etc...
De plus, et c'est un point très important, suse n'a jamais eu une politique d'expansion dans le développement de logiciel non 100 % libre. Depuis le début de suse, yast n'est pas 100 % libre et depuis le début il n'y a que yast.
Et que je sache, mandrake, comme d'autre, dans la version boîte fournis des "vrais" programmes propriétaires et mandrakeclub permet d'acheter des programmes propriétaires.
Si mandrake est un peu plus un "ange", c'est de peu. Les devs de mandrake font 100 % de "vrai" logiciel libre et suse 98 %.
Et si on regarde la contribution au libre, suse a pratiquement fait 10 fois plus de contribution au libre (alsa, kde, reiserfs, linux, portage, etc) que mandrake. Et tous ces développement, mandrake en a profité.
Donc le "pragmatisme" de suse est bon pour le logiciel libre. Je dis pas que suse est dans le vrai et tout le monde doit faire pareil. Mais j'aime pas quand on crache dans la soupe. Surtout s'il y a plus de 95 % de libre dedans.
# Re: Pentium 100 et Woody
Posté par Linux_GTI . En réponse au journal Pentium 100 et Woody. Évalué à 1.
[^] # Re: Ximian > /dev/null
Posté par Linux_GTI . En réponse au journal Ximian > /dev/null. Évalué à 2.
Mais GNU/Linux est devenu un système très complexe (je parle pas de l'utilisation) et il faut des gens à temps plein. Et pour travailler à plein temps sur le logiciel libre, il faut être payé. S'il y avait beaucoup de donation à la FSF, les boîtes commerciales ne seraient pas nécessaires. Mais voilà le "hic". Si on regarde les projets complexes telque linux, gcc, une partie plus que significative vient de développeurs à plein temps. De même les infrastructures (serveurs, bande passante) viennent souvant des boîtes commerciales (sourceforge, sources.redhat.com).
Mais le logiciel libre s'appuis encore et pour longtemps massivement sur le "bénévolat".
Et de toute manière, je vois pas où est le problème que des boîtes commerciales qui font du logiciel libre trouve un modèle économique pour faire du pognon. Du moment que le pognon est principalement utilisé pour le logiciel libre...
[^] # Re: Ximian > /dev/null
Posté par Linux_GTI . En réponse au journal Ximian > /dev/null. Évalué à 3.
Mais a l'avenir amène un minimum de respect. Surtout pour une boîte qui fait principalement du logiciel libre. T'es idéaliste, ce n'est pas un défaut. Mais quand une boîte suit à 95 % tes idéaux de logiciel libre (et les miens), que les produits sont développés sont sous GPL et largement utilisés et aide à l'établissement du logiciel libre, évite les "conneries" de ce genre :
- "Ximian > /dev/null"
Je ne suis pas totalement d'accord avec toi mais je ne vais pas écrire :
- "Houba houba Hop ! > /dev/null"
et mettre ça sur un journal public.
[^] # Re: HOWTO-remove-xd2 ?
Posté par Linux_GTI . En réponse à la dépêche Ximian Desktop 2 est disponible. Évalué à 1.
Faut problème. rpm a toute les infos pour gérer les dépendances mais ne les résoud pas automatiquement. Redhat gère automatiquement les dépendances avec up2date qui est une surcouche de rpm et non un remplaçant.
De plus, ça ne résoud pas son bug de "dead lock".
> ou au moins installe apt sur ta redhat
Y a aussi :
- http://linux.duke.edu/projects/yum/(...)
- http://current.tigris.org/(...)
- http://www.nrh-up2date.org/(...)
Mon préféré est yum même si ce programme est un peu "frai". Contrairement à apt, il n'utile pas --noorder de rpm.
freshrpms fournir un dépôt yum et les paquets quivontbien :
http://psyche.freshrpms.net/rpm.html?id=919(...) (pour 8.0)
http://shrike.freshrpms.net/rpm.html?id=508(...) (pour 9)
Le dépôt :
http://ayo.freshrpms.net/(...)
[^] # Re: Ximian > /dev/null
Posté par Linux_GTI . En réponse au journal Ximian > /dev/null. Évalué à 7.
Ximian fait du libre oui ou non ? OK, il y a un plugin exchange qui est propriétaire et c'est tout.
Faut pas mettre la charrue avant les beoufs. C'est MS-office qui est le plus utilisé (97%). Lorsque OOo sera autour de 20 % il faudrat peut-être réviser le format par défaut.
> et dans quelle mesure cela se répercute sur GNOME
Va faire un tour sur les mailing-list Gnome et tu auras la réponse. Puis c'est du GPL oui ou non ?
C'est pénible cette façon systématique de s'attaquer au boîtes commerciales pour des bricoles comme si elles avaient toutes plein de tune. Laissez aux boites commerciales qui font du LOGICIEL LIBRE un peu de l'attitude. Eazel a coulé, côté distribution n'y a que 2 boites qui tiennent la route : redhat et suze (et pour suze c'est pas facile). Mandrake "qui fait tout tout bien" a maintenant moins de 50 employés et ne contribe presque plus.
Le logiciel libre a besoin de tune et ça passe principalement par les boîtes commerciales.
Désolé, mais la "communauté" qui n'en manque pas "une", n'est pas un modèle de générosité pour la tune et n'a donc pas de leçon à donner aux boîtes commerciales qui font du LOGICIEL LIBRE.
[^] # Re: HOWTO-remove-xd2 ?
Posté par Linux_GTI . En réponse à la dépêche Ximian Desktop 2 est disponible. Évalué à 1.
Le problème : http://www.rpm.org/hintskinks/repairdb/(...)
La solution pour rh8.0 : ftp://people.redhat.com/jbj/test-4.1/(...)
[^] # Re: MDI l'opportuniste
Posté par Linux_GTI . En réponse à la dépêche Miguel de Icaza en Argentine - Conférence à l'Université de Buenos Aires. Évalué à 2.
http://distrowatch.planetmirror.com/images/screenshots/mandrake-men(...)
de
http://distrowatch.planetmirror.com/dwres.php?resource=review-mandr(...)
[^] # Re: MDI l'opportuniste
Posté par Linux_GTI . En réponse à la dépêche Miguel de Icaza en Argentine - Conférence à l'Université de Buenos Aires. Évalué à 0.
c'est ça.
> De totue facon, si ximian avait bossé sur balsa au lieu d'écrire un truc à partir de 0, je suppose que t'aurais crié au scandale
Pourquoi ?
> qu'une boite s'approprie un truc mega bien comme balsa pour en faire au final une bouse infame ?
C'est ton avis.
[^] # Re: MDI l'opportuniste
Posté par Linux_GTI . En réponse à la dépêche Miguel de Icaza en Argentine - Conférence à l'Université de Buenos Aires. Évalué à 2.
> Je trouve ça dommage, mais Mandrake ne contrôle pas le CVS de GNOME. Si c'était le cas, ça me surprendrais d'autant plus.
Ben Ximian ne "contrôle" pas le CVS de Gnome. C'est des phantasmes. Il me semble que c'est redhat le plus gros fournisseur de matos pour gnome.org . Et que redhat contrôle le CVS de Gnome est aussi un gros phantasme.
> Tu utilises des LL depuis combien de temps ?
Ouh j'ai peur.
> Moi, quand j'ai connu Balsa, il existait et était fonctionnel. Evolution n'existait pas.
Super ! Moi quand j'ai connu elm, il existait et était fonctionnel. Balsa n'existait pas et ... Gnome non plus ... etc KDE non plus.
Mais être plus vieux n'est pas une qualité, c'est une fatalité.
> Il aurait très bien pu être possible, en investissant dans Balsa, d'y ajouter toutes les fonctionnalités qui ont été depuis mises dans Evolution.
Oui peut-être. Mais les faits sont là. Des gens ont bossé sur evolution et evolution est devenu populaire. C'est la vie.
Puis ce type de débat, c'est la même chose que KDE/Gnome. Comme Gnome est arrivé après y en a toujours un pour ramener sa fraise et dire que les devs de Gnome aurait mieux fait de bosser sur KDE que de faire un nouveau bureau.
C'est du LL et les gens bossent sur ce qu'ils veulent.
> Mais ça, c'est une question de choix.Mais le Ximian bidule n'a jamais proposé de distribuer aussi Balsa, lecteur de courriel officiel de GNOME
Ximian choisi ce qu'il veut. Ximian c'est pas le site ftp de Gnome.
> Je crois que décidement il te manque un bout de l'histoire. C'est Ximian à l'époque ou Ximian s'appellait Helix qui a décidé que leurs amis d'Eazel feraient Nautilus
Eazel existait avant Helix.
> On choisit des projets qui n'existent pas, qui n'ont pas fait leurs preuves..
C'est-à-dire ? La première fois qu'evolution était distribué, c'était la version 1.0 et ça existait et ça marchait.
Enfin, et mets toi ça dans la tête, balsa et evolution n'ont JAMAIS fait parti de Gnome. Et evolution ne fait toujours pas parti de Gnome. C'est une appli Gnome comme galeon est une appli Gnome.
Et evolution ne sera pas dans Gnome 2.4 :
http://mail.gnome.org/archives/desktop-devel-list/2003-May/msg01074(...)
Et si tu as evolution dans ta distribution, c'est le chois du distributeur de non de MDI, Ximian, Gnome, ou autre. C'est uniquement le chois du distributeur. OK.
> > Non, Mono ne fera pas avancer gnome.
> Si tu veux défendre MDI, lis au moins ce qu'il écrit.
Je peux ne pas être d'accord avec MDI. C'est pas une raison pour l'allumer sur tout et rien. C'est un mec qui a beaucoup contribuer au LL et pour ça il mérite un minimum de respet.
Sinon, et MDI le reconnait, il n'est pas question d'écrire Gnome en Mono. Mono est un langage supplémentaire comme perl, ada, python, C++, etc. Et MDI le reconnait (bien qu'au début de Mono il parlait d'écrire certaines parties de Gnome en Mono). Si Mono est un plus pour Gnome, c'est parce qu'il y aura des applis développé en C# et non car Gnome va être écrit en C#.
[^] # Re: MDI l'opportuniste
Posté par Linux_GTI . En réponse à la dépêche Miguel de Icaza en Argentine - Conférence à l'Université de Buenos Aires. Évalué à 1.
[^] # Re: MDI l'opportuniste
Posté par Linux_GTI . En réponse à la dépêche Miguel de Icaza en Argentine - Conférence à l'Université de Buenos Aires. Évalué à 1.
[^] # Re: MDI l'opportuniste
Posté par Linux_GTI . En réponse à la dépêche Miguel de Icaza en Argentine - Conférence à l'Université de Buenos Aires. Évalué à 1.
[^] # Re: MDI l'opportuniste
Posté par Linux_GTI . En réponse à la dépêche Miguel de Icaza en Argentine - Conférence à l'Université de Buenos Aires. Évalué à 2.
[^] # Re: MDI l'opportuniste
Posté par Linux_GTI . En réponse à la dépêche Miguel de Icaza en Argentine - Conférence à l'Université de Buenos Aires. Évalué à 1.
[^] # Re: Au revoir !
Posté par Linux_GTI . En réponse au journal Au revoir !. Évalué à 2.
=> http://linuxfr.org/~gle/3154.html(...)
Je vais t'aider :
http://linuxfr.org/user_prefs.html#supp(...)
# C'est une blaque !
Posté par Linux_GTI . En réponse à la dépêche Pourquoi ne pas utiliser Linux. Évalué à 1.
L'article ne souligne pas sa cible (le gus (un peu neuneu) qui veut passer de Windows à Linux). Rien pour les entreprises par exemple, serveur, développeur, amateur, etc...
Et la fin avec un lien sur http://www.uselinuxathome.com/FRwhymdk.htm(...) ("Pourquoi choisir Mandrake") est du FUD de première classe.
> Par exemple, SuSe n'est disponible qu'en version payante.
C'est faux. Il y a une version gratuite mais qui ne s'installe que via ftp.
> De son côté, Red Hat est gratuit mais les mises à jour sont payantes...
C'est faux :
http://www.redhat.com/apps/support/errata/(...)
http://updates.redhat.com/(...)
Voir aussi les tonnes de mirrors :
http://www.redhat.com/download/mirror.html(...)
Pour les mises à jour "automatiques" 'up2date' de RedHat est gratuit pour une machine pour une adresse mail (ya un formulaire de 3 questions maxi tout les 2/3 mois à remplir). Et pour ceux qui ont plus d'une machine, il y a apt ou yum.
C'est la version serveur qui est payante (redhat linux enterprise). Les mises à jours peuvent être gratuites mais il n'y a que les src.rpm.
> Mandrake est l'une des trois distributions les plus utilisées.
Ça va peut-être pas durer. La distribe dégringole sur http://counter.li.org/reports/machines.php(...) (elle était à 20 % et debian monte fort).
red hat 28.83%
mandrake 16.59%
debian 14.90%
s.u.s.e 11.39%
slackware 11.35%
> Dernier point important pour nous: le support de la langue française.
J'ai une redhat (au boulot on utilise redhat) et elle cause autant le Français.
> les manuels sont disponibles en français.
Idem RedHat :
http://linuxwww.epfl.ch/Documentation.html(...)
La doc est de grande qualité (je conseille TRÈS fortement sa lecture) et en Français.
Mandrake c'est bien, mais il y a d'autres choix plus pertinents en fontion de l'utilisation.
[^] # Re: Et l'exemple qmail ?
Posté par Linux_GTI . En réponse à la dépêche Exec Shield: protection contre les débordements de tampons. Évalué à 1.
C'est comme le "bon parlé", ça n'existe pas :-)
Pour la doc, je te conseilles très vivement les pages info de la libc. C'est accessible en ligne de commande avec "info libc" ou "gnome-help info:libc" (et de 50 autres façons différentes). La libc te donne les éléments de base d'un système Unix et ça peut te resservir avec tout les autres languages.
Mais il n'y a pas que ça à lire...
[^] # Re: Et l'exemple qmail ?
Posté par Linux_GTI . En réponse à la dépêche Exec Shield: protection contre les débordements de tampons. Évalué à 2.
Le timestamp, n'est pas nécessaire pour logrotate. Et logrotate peut même te gérer des fichiers binaires au format "stupide".
> Ainsi peu importe ce qu'il se passera note deamon n'auras _jamais_ le probleme du manque de plus de place sur le disque, ou de gerer un eventuel SIGHUP, ou de bien tout fermer en redamarrant completement.
J'ai rien contre les nouveaux systèmes, mais l'actuel est correct. S'il était "tout pourri" et devait être "bannit", il ne serait plus là depuis un moment.
> 'rotatelogs' au final complique la vie du programmeur.
Suffit de trouver un moyen pour ouvrir et fermer les fichiers logs pour les processus qui sont "résidants". Pas plus.
Je n'ai pas dit que logrotate était génial. J'ai seulement dit que j'aime bien.Le probleme ce n'est pas ca.
> Ce n'est pas non plus sa reentracy c'est que le random associe est completement pourri. Du man:
> BUGS
> Never use this function. Use mkstemp(3) instead.
C'est les pages infos qui font références. Je voulais dire que tmpnam() n'est pas un problème de sécurité si c'est bien utilisé (attention à l'umask entre autre). Je l'ai utilisé à une époque où il n'y avait pas le choi. mkstemp est meilleur, c'est claire.
Mais le mieux est d'utiliser tmpfile(). Avoir des noms de fichier, c'est pour le communiquer à d'autre processus.
> un const char * comme argument. Entre deux appels le fichier decrit par le parametre peut etre devenu un lien symbolique ou hard sur autrechose...
Il faut donc toujours travailler avec des fd.
Juste.
Plus globalement, je ne nie pas qu'il y a de meilleurs solutions. Mais tu critiques syslog, parles d'apache alors qu'apache n'utilise pas syslog etc... De plus apache utilise plusieurs fichiers de log (access, error, referer, ssl, etc...) (Et le format n'est pas dicté par syslog ou logrotate!). Tu critique l'utilisatation de /var/run/httpd.pid, alors que c'est aussi là pour avoir plusieurs serveurs web sur une même machine (dont un en chroot par exemple). Désolé mais tu fais dans le FUD (bannir syslog, tmpnam, etc...) pour caser des solutions plus innovantes et ça me gonfle.
Longue vie aux daemontools etc... qui font peut-être parti de l'avenir d'Unix/Linux. Mais c'est pour pour autant que l'existant est de la "merde" et n'a pas certains bénéfices. Je sais, je suis dure.
Bon, on va pas se facher. C'est beaucoup une histoire de "goûts et couleurs" et d'habitude.
[^] # Re: Et l'exemple qmail ?
Posté par Linux_GTI . En réponse à la dépêche Exec Shield: protection contre les débordements de tampons. Évalué à 4.
man sigaction :
"sa_mask gives a mask of signals which should be blocked during execution of the signal handler. In addition, the signal which triggered the handler will be blocked, unless the SA_NODEFER or SA_NOMASK flags are used."
> plutot que l'infame methode utilisee par rotatelogs...
C'est ton avis. J'aime bien logrotate.
> le programme htpasswd fait usage de tmpnam(). D'apres son man elle n'est pas vraiment recommandee ...
info libc :
"Temporary Files
===============
If you need to use a temporary file in your program, you can use the `tmpfile' function to open it. Or you can use the `tmpnam' (better: `tmpnam_r') function to provide a name for a temporary file and then you can open it in the usual way with `fopen'. "
man tmpnam :
"If the argument s is NULL this name is generated in an internal static buffer and may be overwritten by the next call to tmpnam(). If s is not NULL, the name is copied to the character array (of length at least L_tmpnam) pointed at by s and the value s is returned in case of success."
Le problème c'est d'utiliser tmpnam(NULL).
de /usr/include/stdio.h :
"/* This is the reentrant variant of `tmpnam'. The only difference is
that it does not allow S to be NULL. */
extern char *tmpnam_r (char *__s) __THROW;"
> Pourquoi donc ce n'est pas la panacee ?
Parce qu'il faut réécrire un système pour loguer. Car il faut mettre en place un système pour communiquer avec le nouveau système pour loguer. Car par rapport à un système qui écrit directement dans un descripteur de fichier, c'est moins performant.
> Ensuite les pipe sous linux c'est PIPE_BUF: 4096 atomiquement.
Si les processus sont frères et/ou que les processus clients peuvent "mourrir" tu ne peux pas utiliser de pipe (ou alors il faut utiliser des pipes nommés).
> Les ipc permettent le 'privilege separation' qui _doit_ etre utilise tout le temps que c'est possible.
?
> Quid de la rotation de logs ? (cf premier message)
Tu passe par syslog, puis tout les journaux de syslog sont "rotationné" par logrotate toute les nuits. Aucun problème.
> Quid du format du timestamp ? (cf premier message)
Oui. Mais c'est pas un drame. De plus il ne doit pas être difficile de corriger ça si c'est indispensable.
> Quid des personnes ne sachant pas utiliser les formats ? (cf premier message)
Si c'est pour des logs apache (/var/log/httpd/access_log par exemple), le format est sous le contrôle d'apache. Si tu passes par syslog, rien ne d'interdit d'ajouter la date dans le format qui te plais.
> Syslog est a bannir.
Je me marre. Fait un "man syslogd" et "man syslog.conf".
exemple :
"Named Pipes
This version of syslogd(8) has support for logging output to named pipes (fifos)."
"Terminal and Console"
"Remote Machine
This syslogd(8) provides full remote logging, i.e. is able to send messages to a remote host running syslogd(8) and to receive messages from remote hosts. The remote host wont forward the message again, it will just log them locally. To forward messages to another host, prepend the hostname with the at sign (@).
Using this feature youre able to control all syslog messages on one host, if all other machines will log remotely to that. This tears down administration needs."
Avec pipe, rien ne t'empêche de faire un programme qui écoute le pipe (sur une autre machine si tu veux) et de logguer les messages dans une base de donnée et jamais d'utilisation de logrotate et en même temps d'avoir les logs en directe pour les consoles sous toto. Le possibilités sont nombreuses. Mais si tu veux coder un autre syslog, te gène pas.
> par exemple funlink() utilisant un fd au lieu d'une chaine. Pour eviter les problemes de 'race condition' que l'on trouve avec toutes les fonctions basees sur le nom.
Quels sont les problèmes ?
Aucun. La chaine passée à unlink n'est pas interprété. C'est totalement différent de system() par exemple. Puis pourquoi pas virer toutes les fonctions qui attende un char * (open() ?). Utilise dmalloc si tu as "peur". Mais attention, les performances vont en prendre un sérieu coup...
[^] # Re: Et l'exemple qmail ?
Posté par Linux_GTI . En réponse à la dépêche Exec Shield: protection contre les débordements de tampons. Évalué à 7.
C'est le cas pour apache. Lors d'un logrotate, le processus père (pid : /var/run/httpd.pid) reçoit un SIGHUP. Ce processus père tue "en douceur" les fils (il laisse les requêtes se terminer (sauf les longues requêtes)) mais le processus père n'est pas tué !. Lorsque tous les fils sont morts, le père relance des fils. Les requêtes arrivées durant cette phase reste en attentes mais aucun client ne perçoit un service arrêté.
Faire un process frère pour les logs n'est pas la panacée. Il faut mettre en place des moyens de communication entre le processus qui fait les logs et ces frères (ipc surement puisque ce sont des frères).
De plus ta demande d'avoir des deamons qui tourne 24h/24 peut être très facilement faite en utilisant syslog(3). Par contre c'est plus coûteux en temps.
> Reclamez l'implementation d'un syscall unlink() utilisant un fd et non plus un const char * (;p)
Ça n'a aucun sens.
exemple :
$ mon_prog toto &
$ ln toto titi # lien hard
$ mv toto tata
mon_prog crée et ouvre toto. 2 minutes après il faut un hypotétique unlink(fd). Que doit faire l'OS ? suprimer titi et tata ? Et si toto est un lien symbolique ? Et si fd est un pipe ?
[^] # Re: Et l'exemple qmail ?
Posté par Linux_GTI . En réponse à la dépêche Exec Shield: protection contre les débordements de tampons. Évalué à 3.
Faut se même dans la tête qu'il y a toujours un moment ou il faut "prendre des risques". Si tu fais un serveur web en C++, tu as surement une fonction "query_string_2_Qstring()" qui te retourne un objet string mais qui a forcément fait des manipulations avec malloc/strcpy etc.
De même, c'est pas parce que tu utilises du php qu'il n'y aura pas de problème.