sobek a écrit 351 commentaires

* Liberté 0 : La liberté d'exécuter le programme, pour tous les usages.
* Liberté 1 : La liberté d'étudier le fonctionnement du programme.
* Liberté 2 : La liberté de redistribuer des copies.
* Liberté 3 : La liberté d'améliorer le programme et de publier ses améliorations.

Faut-il le rappeler, ces libertés définissent le LOGICIEL libre SELON la FSF.

Heureusement, le libre ce n'est pas QUE cela.

Pour rappel, le NC ne gène pas le libre, il ne gène que les boites qui veulent faire de l'argent avec le libre (je sais, certains extrémistes me parleront des CDs accompagnant un magazine... mais souvant il suffit dans ce cas de demander).

Le ND est beaucoup plus problématique par contre, je suis d'accord.

Oui, c'est une BSD-like.

euh si, tu as tout à fait les droits de faire les deux, simplement faut assumer : passer ton programme binaire en GPL
C'est bien ce que je voulais dire : tu ne peux faire l'intégration de code GPL dans un programme libre sans devoir passer tout ou partie de ce programme en GPL (au moins le binaire dans ce cas précis). C'est ce que certains appèlent le coté "viral" de la GPL, même vis-à-vis du libre.

ce n'est qu'au moment où tu distribues un programme que les contraintes
En général, si je fait du libre et que je me pose des questions de licenses c'est que je ne compte pas garder ces modifications pour moi, même si la version modifiée n'est pas forcement à diffusion très large.

tu as choisi de reprendre du code GPL, c'est la GPL qui s'applique
On est d'accord : à partir du moment ou une ligne de code GPL est intégré, il est automatiquement "contaminé" et devient à son tour loup-garoup^W^W GPL, quelque soit le choix de license de l'auteur initial.

Ainsi, si on a deux programmes proches, l'un sous license GPL et l'autre sous license BSD.
Si un dév du premier prend un bout de code du second pour améliorer son programme, il est libre de le faire sans problème (et c'est très bien).
En revanche si un dév du second veut s'inspirer du premier pour améliorer son programme alors il n'a qu'une solution : mettre son programme sous GPL.
C'est ce partage à sens unique dans la vision du libre suivant la FSF qui me gène parfois un peu...

d'être plus pragmatique et de distribuer en GPL (de toute façon tu souhaitais le distribuer aussi ton source non ?).
Oui, je voulais le distribuer, mais en lui concervant sa license d'origine.
Pour moi, le monde du logiciel libre ne se limite pas à linux et à la GPL, fort heureusement.

Ben elle est compatible au sens GNU : tu as le droit de linker une librairie ISC dans un programme GPL, mais pas l'inverse.
De même, tu peux inclure du code ISC dans du code GPL, mais pas l'inverse. C'est illustré dans le document que tu indiques.

En gros, la licence GPL permet de piocher dans nombre de projets libres sans avoir à redonner en échange si l'autre à une vision du libre qui n'est pas GPL (c'est uniquement suivant le bon vouloir de l'auter, s'il publie sa modification en licence multiple ou non...).

Personnellement, la GPL est une license que j'évite au maximum (et encore plus des "version n ou ultérieur" sans savoir ce que l'avenir réserve) pour ce que je produis, parce que pour moi si la liberté des utilisateurs est importante, la liberté du point de vu programmeur l'est elle aussi.

il semble être qqcun de raisonnable et voulant innover

Tout dépend raisonnable par rapport à quoi.
Disons que pour quelqu'un d'ultra-libéral [*], il est cohérent.

[*] j'entend par là ceux qui oublient volontairement la fin de "concurrence libre et non faussée", pronant la dérégulation (ce qui va bien au dela d'une ouverture à la concurrence) et la levée de tous les garde-fous...

Ça dépend, c'est une bonne heure pour l'apéro du soir...

C'est la même chose techniquement. RHEL 5 est une FC6 avec quelques bricoles de plus.

Il y a quelques différences tout de même, comme yum.
Mais nous sommes d'accord, d'ou le rapprochement dans mon premier message.

Donc ne voit pas pourquoi tu critiques le principe de Fedora et pas celui de FreeBSD.

Ce qui me gène dans sysconfig n'est pas dans le contenu, qui est proche comme le montre ma citation, mais dans l'aspect "fouilli" : rien que pour le réseau, l'information est parfois répartie sur une dizaine de fichiers, ce qui en complique la maintenance je trouve.

Ça c'est les goûts et les couleurs.

Sans aucun doute.

Mais ta critique de /etc/sysconfig de Fedora est gratuite et ça m'énerve.

Elle n'est pas completement gratuite : Rien que cette année j'ai du installer une trentaine de serveurs sous CentOS, et mon portable est longtemps resté sous FC6, puis FC7.
Le "problème" est que ce que qui me gène est plus de l'ordre du ressenti : difficile a exprimé et pouvant parfaitement ne pas être partagé.

En passant, tu as fait ses tests sur quoi ?
Parce que NFS ça existe depuis longtemps et c'est très utilisé.

Tests faits sur une CentOS 4, avec discution avec l'une des personnes en charge de cette distrib.
Pour les problèmes NFS, la plupart sont référencés sur le bugzilla de RedHat ou autre et sont restés ouverts un certain temps malgré ce que tu dis sur l'utilisation de NFS...

> /bin/sh qui est en fait un bash, avec toutes les gnuteries associées pour le shell root...

C'est connu, BSD est parfait est GNU ça pue, c'est le mal et ça veut la mort de BSD.

Alors je m'excuse pour le mot "gnuteries", ce n'est pas le point le plus important que je voulais soulever. Ce qui me gène surtout c'est d'avoir fait de /bin/sh un simple lien vers /bin/bash sur nombre de distribs alors que pour moi le shell de root par défaut devrait être minimaliste de chez minimaliste, question de sécurité, quitte à lancer un bash à la main après. Cela éviterait de se retrouver coincé par un truc dans /etc/bashrc lorsque l'on essaye de se connecter root sur une machine ayant un problème...

Déjà, j'avoue, je connais bien moins Fedora que CentOS ou RHEL.

Ensuite, je ne considère pas qu'apache fasse parti du système de base.
Mais pour comparaison, voici ce que l'on peut mettre dans le rc.conf concernant apache, sachant qu'il suffit de mettre le premier et le dernier à yes pour activer un serveur web :

# Add the following lines to /etc/rc.conf to enable apache22:
# apache22_enable (bool): Set to "NO" by default.
# Set it to "YES" to enable apache22
# apache22_profiles (str): Set to "" by default.
# Define your profiles here.
# apache22limits_enable (bool):Set to "NO" by default.
# Set it to yes to run `limits $limits_args`
# just before apache starts.
# apache22_flags (str): Set to "" by default.
# Extra flags passed to start command.
# apache22limits_args (str): Default to "-e -C daemon"
# Arguments of pre-start limits run.
# apache22_http_accept_enable (bool): Set to "NO" by default.
# Set to yes to check for accf_http kernel
# module on start up and load if not loaded.

Maintenant, je parlais bien de sysconfig, qui même s'il ne représente qu'un pourcent en taille est assez pénible en comparaison lorsque l'on a des configurations un peu pénibles (certains serveurs ont plusieurs cartes réseaux et une diszaines d'alias IP, par exemple).

Le gros intéret de rc.conf est qu'il permet d'avoir une vision synthétique de toute la configuration non par défaut du système, des services démarrés, etc.

Mais au-lieu de faire un truc de porc en bidouillant les /etc/rc.*, tu fais la configuration en un lieu précis dans un cadre qui l'a prévu (plus ou moins car prévoir tout les cas est impossible).

Tu as déjà regardé comment sont organisés les rc.* sur un BSD ?
(tip: C'est à l'image du reste lorsque l'on compare Linux vs. BSD)

> Ayant plusieurs dizaines de serveurs à maintenir, j'aurai tendance à dire que statistiquement les linux nous posent plus de problèmes que les BSD... et pas qu'un peu.

Je ne vois pas pourquoi.

Entre autre, les problèmes sur certains montage nfs (montages ro qui est en fait rw), client nfs qui ne remonte pas forcement suite à un problème sur sa connexion avec le serveur, nscd qui se gaufre sous forte charge, nfs4 qui ne tient pas non plus avec en message d'erreur des problèmes VFS non traités qui n'auraient pas du remonter en userland (ces 2 derniers datent de nos tests d'il y a un an, on est revenu en arrière depuis), /bin/sh qui est en fait un bash, avec toutes les gnuteries associées pour le shell root...

(pour préciser : certains chez nous sont plutot orientés Linux, d'autres plutot BSD... donc ce n'est pas forcement qu'une question de connaitre mieux un systeme)

Oui enfin, entre maintenir un fichier rc.conf sous FreeBSD et l'arborescence /etc/sysconfig sur une RHEL ou une Fedora, le plus compliqué n'est pas le premier, loin de là.

Ayant plusieurs dizaines de serveurs à maintenir, j'aurai tendance à dire que statistiquemen les linux nous posent plus de problèmes que les BSD... et pas qu'un peu.

(désolé, on n'est plus vendredi ;)

Tu veux dire que tu ne sais pas que le site web du projet est http://www.freebsd.org ?

Alors je m'y colle : http://www.freebsd.org/news/newsflash.html#event20080118:01
;)

Mais honnètement, même si ce n'est pas "obligatoire" d'après la FAQ, j'aurai vraiment tendance à partir d'une machine propre pour tester ce genre de chose,plutot que d'une machine dont je ne connais pas vraiment l'état...

Après, savoir s'il n'a pas pris le temps de bien expliquer ou s'il a juste voulu jouer son BOFH, je ne sais pas ;)

Ca a l'air d'être une sacrée grosse faignasse ton admin, parce qu'installer Kerrighed, ça demande pas de tout réinstaller...

Mouais, sur le papier, ça a l'air simple, mais en pratique...

Étant admin et gérant des serveurs de calcul scientifiques, je dirais que pour le moment Kerrighed c'est bien pour les grappes expérimentales, mais de là à le mettre en prod (surtout avec des vrais utilisateurs (=pas informaticiens mais scientifiques) faisant des calculs scientifiques de la vrai vie)...

Perso, je ne l'installerai pas dans ce cadre (et pourtant je l'ai déjà testé), d'autant que ce n'est pas forcement adapté au besoin : il s'agit "juste" de répartir des jobs, pas de monter un super-calculateur SMP virtuel avec des dizaines de CPU et des centaines de Go de RAM.

En gros, ce que tu cherches, ce sont des "scheduler" pour grappes de calcul, non ?

Alors pourquoi ne pas utiliser les outils de type SunGridEngine ou OpenPBS/Torque ?

Nous utilisons le premier pour répartir de l'ordre de 2millions de jobs par mois en moyenne vers un certain nombre de machines. Et cela comprend aussi des programmes interactif/graphique via tunnel ssh (juste que la gestion des signaux est un poil pénible dans ce cas).

Il faut juste définir un noeud comme étant maitre SGE, et un (des) autre(s) comme noeuds de soumissions, mais ce ne sont pas forcement des machines distinctes.

En parcourrant rapidement le pdf, il y a un comparatif avec le noyau Fedora 8. Fedora 8 qui n'est pas sorti !

Ça tombe bien, FreeBSD 7.0 n'est pas sorti non plus ;)
Il compare donc deux systèmes en phase de finalisation.

Ce n'est pas un 2.6.23 final. Fedora a pour habitude d'avoir des options de debug dans les phases de test ! Ce qui est tout à fait normal.

Sauf que Fedora 8 n'est plus en phase de développement.
Pour ceux qui ne sont pas au courant, la release est prévue pour le 8 novembre (soit bien avant celle de FreeBSD 7.0 qui est prévu pour mi-décembre), et on est passé à ce qui devrait être le noyau dévinitif, sans les options de débug, durant les RC. Cela c'est d'ailleurs vu puisque le rpm kernel.x86_64 est passé pour l'occasion de 63 à 16 Mo....

Par contre, il faut bien regarder les conditions du test. Un développeur a un FreeBSD aux petits oignons et compare avec un Linux "stock" ou un Linux de debug de Fedora.

Je n'ai pas vérifié pour le bench en question, mais d'autres benchs que j'avais vu et qui arrivaient à la même conclusion comparaient des systèmes en cours de finalisation (donc sans debug) et sans optimisation spécifique de part et d'autre (justement parce que le le testeur ne voulait pas que sa meilleure maitrise de FreeBSD influe sur le résultat).

Ou alors le type est tout simplement un "fusible", du genre de ceux qu'on envoie au front et que l'on grille pour protéger ceux qui tire les ficelles du retour de baton.
C'est TRES courant en politique, par exemple...

Partant là, j'ai de mal à voir en quoi la BSD est plus synonime de partage que la GPL.

Au hazard, parce que la GPL ne partage QUE avec la GPL, là ou BSD partage indiférement de la license ?

C'est bien ce qui, pour moi, est un des principaux problèmes de la GPL : il n'hésite pas à prendre dans les licenses compatibles, mais il ne repartage derrière que en GPL, sauf à en être obligé par les autres licences.
C'est ce "partage à sens unique" qui pose problème et qui est de plus en plus critiqué dans le monde BSD.
Parce que comme repris dans plusieurs autres interventions, nombres de développeur de code proprio retournent du code en BSD en retour. Ce n'est que rarement le cas des développeurs GPL, sauf pour les codes volontairement sous double license BSD/GPL.

M'enfin, si tu t'en fous de la liberté, c'est normal que tu dis ça.

Je ne m'en fous pas de la liberté, justement : la license BSD apporte des libertées du point de vue programmateur que n'offre pas la GPL. Je veux donc être libre de choisir quelles libertés sont les plus importantes pour moi.

Le principal reproche que je ferai à GConf est que celui-ci n'est pas arrété à la fermeture de session.

Résultat, sur des machines communes genre salle de TP, il est fréquent de trouver une dizaine d'instance de gconfd tournant sous des identifiants différents, alors que les utilisateurs en question ne sont plus connectés.

C'était du moins le cas sur des machines installées en septembre dernier...

Non, non, ceci n'est pas aberrant...

Pas plus que ce qui est demandé par certaines licences pourtant dites libres, à commencer par celle de la MoFo.

Ils veulent que l'on puisse parfaitement faire la différence entre le travail de SMF et les diverses contributions non intégrées dans la version officielle en interdisant un fork de cette dernière. C'est en désaccord avec l'esprit de la GPL, mais c'est leur choix et ce n'est pas pire que ce que l'on voit dans d'autres licences. Là, on a au moins accès aux sources, certaines modifications sont commitées... symplement, ce qui nést pas commité doit ressté a l'état de patch.

Ensuite, je suis d'accord, tant qu'à choisir moi aussi j'aurai préféré que la license soit de type BSD...

J'attends de voir quelqu'un essayant de démontrer que la license BSD n'est pas libre, tient.

En comparaison c'est plutôt la GPL qui impose des contraintes supplémentaires du point de vu des libertés du programmeur sans rien apporter de plus quant aux libertés de l'utilisateur... (ensuite, le fait de penser que ces contraintes supplémentaires sont nécessaires et bienfaitrices ou pas est un autre problème)

Du coup, pour redistribuer le patch qui permettra à SMF de tenir compte du nouveau système d'authentification, ça va être coton...

Pourquoi ?

Rien n'empèche l'installeur d'appliquer le patch de manière automatique. C'est ce qui est fait dans un grand nombre de ports sous FreeBSD et cela ne pose aucun problème !

Pour ce que j'ai compris de la license n'est pas interdit de distribuer SMF et patch ensemble, à condition que le patch ne soit appliqué qu'une fois sur le poste client.

Ces derniers temps, il est régulièrement question que Bouygues Telecom se lance dans l'ADSL.Pour le moment, je n'ai pas vu de source fiable allant au dela de la rumeur récurante, mais peut-être que ceci explique cela...

Flash me saoule éga;ement, et je n'installerai pas gnash parce que cela me permet d'éviter de me faire flashouiller par de la pub dans tous les sens...

Pour les vidéos, j'utilise soit unplug soit VideoDownloader, 2 extentions de Firefox qui donnent accès au .flv dans la majorité des cas...

Si je te suis, ces blob de compatibilité sont dus a un problème dans la chaine .doc -> ooxml -> .doc.

Sachant que toujours d'après toi ooxml sans option est complet, et le filtre ooxml -> .doc ne pose pas problème.
Par dichotomie, on en conclut que le problème est dans le filtre .doc -> ooxml...

On est donc finalement d'accord sur le fait qu'il s'agit d'un problème de filtre, même si cela se passe au niveau du filtre d'export et non du filtre d'import.

Ce qui repose d'ailleur le problème : un logiciel issu d'un éditeur n'ayant pas implémenté les parties optionnelles pourra-t-il ou non afficher correctement et de manière déterministe un document issue de la conversion d'un document Word6/WordPerfect/... ?
Si ce n'est pas le cas, alors ooxml n'assure pas sa fonctionnalité d'interopérabilité.
Si c'est le cas, alors tous les éléments de la chaine sont bon, et j'ai logiquement un doute sur l'argumentaire pour ces blobs de compat.

D'ailleurs je ne suis pas le seul, c'est également le cas de plusieurs membres, bien plus compétents que toi et moi a priori, du V1 et du comité de normalisation du Portugal.

L'article d'hier sur Ars Technica http://arstechnica.com/news.ars/post/20070726-office-open-xm(...)
est assez intéressant sur le sujet puisqu'on y apprend que ces blobs ne sont pas là pour des raisons techniques mais à la demande de clients de MS (the infamous "AutoSpaceLikeWord95" tags [...] had been added only at the request of organizations such as the US Library of Congress and the British Library).

On pourra au passage constater la bonne foi de MS quant à sa volonté de dialogue : volonté d'exclure Sun du comité portugais "par manque de siège", ou sa déclaration d'avoir été exclu de l'OASIS parce que leur proposition de blob de compat "risquait d'introduire une compatibilité avec les anciens documents" (?), alors que c'est MS qui a décidé de quitter l'OASIS (peut-être suite au refus de ces blobs, mais ce n'était pas une exclusion et la justification me semble fumeuse...

Enfin, pas la peine de dire "Ouais mais ODF fait pareil" : un certain nombre de personne en charge des normes sur le sujet sont conscients des problèmes d'ODF et préfèreraient l'étendre pour donner ODEF que de normaliser OOXML qui contient les mêmes problèmes et plus encore...

Je te l'ai donnee l'explication.

Ou ça ?

A part un "l'information est nécessaire pour ouvrir le document mais n'a rien à faire dans la partie hors option du document", et un "ceux qui savent ont décidé de faire comme ça alors tais-toi", je ne vois pas.

Toi par contre tu te contentes de dire "c'est une idee conne et le filtre devrait le faire".

Je n'ai jamais dis que j'étais un dieu en filtre bureautique. Perso je fais plutot dans le calcul scientifique qui a parfois des problématiques similaires sans retenir cette solution.

Je me limite à avoir une question et espérer une réponse autre que marketing ou puerile. Tant que ce n'est pas le cas, ooxml me semblera avoir des défauts suffisant pour ne pas avoir le statut de norme iso.

comment-est ce que le filtre peut avoir cette information contenant le formattage du document si l'info n'est pas dans le document.

Et bien comme déjà dit dans plusieures réponses, ainsi que par d'autres contributeurs : ou l'information est nécessaire (ce qui semble le cas d'après ce que tu dis) et dans ce cas elle doit être pleinement documentée pour que tout le monde puisse travailler avec les documents avec compat si bon lui chante, ou le format ooxml est déterministe sans la partie optionnelle et dans ce cas l'information devrait pouvoir être regénéré par le filtre à partir des informations dans la partie non optionnelle.

C'est du moins comme cela que l'on raisonne dans d'autres domaines de l'informatique que je connais.

Si l'on n'est dans aucun de ces deux cas, alors j'aurai tendance à croire qu'il y a volonté de limiter l'interopérabilité ; mais je suis ouvert si tu as une vraie explication prouvant le contraire.

Ici Intel utilise uniquement la licence GPLV2, avec une petite restriction [1]

La vision du libre par les GPListes me surprendra toujours...

Personellement, j'aurai mis "modification" ou "exception" plus que "restriction" pour traduire ce qui est en note. A croire que le GPL sans son aspect contaminant, c'est le mal absolu...

mais le code doit rester ouvert.

Heu... non, justement : tu peux mettre la license que tu veux, pas besoin que le code soit en GPL ni même ouvert. C'est justement le sens de l'exception en [1], et ça en fait un peu un intermédiaire entre GPL et LGPL...

PS: en tant que BSDiste, j'assume le mot "contaminant" qui, contrairement à "virulant" n'a pas le coté actif (et même si virulant irait à certains GPListes intaigristes ;)