Journal réflexion du soir, bonsoir

Posté par Ramso le 20 juin 2003 à 22:42.

Étiquettes : aucune

juin

2003

Je commence à me poser une grave question...

Je manipule des systèmes Linux depuis moults temps et donc je suis habitué aux commandes GNU, notamment ce qu'on peut faire avec ls, tar, gcc, ...

Quand je reviens sur un système BSD, je me sens un peu perdu parce que toutes les joyeuses options que j'avais avec les commandes GNU n'existent plus.

On pourrait étendre ce raisonnement à d'autres commandes du sytème GNU comme bash ou gawk qui apportent leur lot d'extension qui risquent de rendre les scripts non-portables sur BSD ou un autre Unix.

Je commence à avoir le sentiment que les commandes GNU apportent des extensions qui interdisent la compabilité avec l'Unix original.

Alors bien sûr, il s'agit de GNU et j'ai bien conscience que GNU's Not Unix mais je vais finir par penser qu'il s'agit d'extensions « propriétaires » qui ne sont compatibles qu'avec elles-mêmes.

Je met bien sûr propriétaire entre guillements parce que GNU reste un système libre et personne ne vous oblige à les utiliser.

Reste qu'elles apportent souvent un confort et il est parfois difficile de s'en passer quand on veut faire simple ou efficace. Au final on tombe dans le piège du script ou des habitudes à la GNU qui ne marchent plus sur BSD.

Regardez aussi toutes les options de gcc ou les subtilités qu'il fait utiliser au programmeur. Quid de la portabilté quand on passe à un autre compilateur ? il faut installer les outils GNU ? Quand je regarde tous les readme qui disent de les utiliser pour pouvoir compiler sur BSD ou Unix proprétaires, j'en ai bien l'impression...

Bon, je reviens sur le fond du problème : quelle est la limite entre le « embrace & extend » que l'on reproche à Microsoft et les extensions GNU qui peuvent rendre mon travail difficile à utiliser sur un autre Unix ? Pourquoi devrais-je installer à moitié un sytème GNU sur ma FreeBSD pour retrouver mes marques ? Est-ce qu'ils n'ont pas réussi à se rendre indispensables en faisant en sorte de les imposer dès qu'on veut utiliser un logiciel conçu avec eux ?

Où est la portabilité du C, d'Unix si tout le monde se cache derrière les extensions des commandes GNU et impose aux autres de les installer ?

Est-ce que ce qui distingue les extensions de Microsoft des extensions GNU ne tient qu'à la licence ? Un système libre n'est-il pas censé encourager les standards ?

On tombe rapidement dans le piège du troll à propos de Windows et MSOffice que certains considèrent comme des « standards » parce qu'il y a une masse de gens qui les utilisent mais j'espère que vous allez élever le débat.

J'espère aussi que vous n'allez pas vous débarrasser de la question en scandant au troll ou en sortant une vanne à la mode. Réfléchissez à la question, quitte à répondre dans plusieurs jours (d'ailleurs ça vaudrait mieux que de répondre une connerie tout de suite).

# Re: réflexion du soir, bonsoir

Posté par Thomas (site web personnel) le 20 juin 2003 à 22:48. Évalué à -4.

MS-Dos rulaize :)
# Re: réflexion du soir, bonsoir

Posté par ours Ours (site web personnel) le 20 juin 2003 à 23:01. Évalué à 3.

Réflexion très intéressante

Il est vrai que GNU impose sa vision tant au niveau de l'évolution de l'utilisation ainsi que des fonctionnalités (Attention, je ne juge pas la qualité de ces dites évolutions).

Ces évolutions posent la question du passage sous divers environnements, rien qu'aujourd'hui, un ami m'a dit qu'il n'aimait pas FreeBSD parce que les arguments aux commandes étaient différents.

Ce journal pose par extension le problème de la liberté, peut on considérer la license GPL comme libre alors qu'elle impose sa vision de la liberté aux gens qui utilisent ses sources dans leurs programmes.

Je m'explique, les améliorations que l'on apporte à un programme sous GPL ne pourront pas être appliquées à des programmes sous d'autres licenses pourtant plus libres comme la license BSD (sauf si l'auteur est prêt à modifier la license), c'est l'aspect viral de la GPL.

Après, vous pourrez évidemment me répondre que l'auteur a choisi la license, et que je n'ai pas le droit de regard là dessus, et je serai d'accord. On accepte ou non la license (comme avec windows).
De même, vous pourrez dire que c'est pour se protéger des grands groupes qui peuvent piller le BSD comme windows avec son client FTP.exe (strings ftp.exe vous en dira plus). C'est vrai aussi.

Certains diraient même - comme mr Bugnon - que ce type de license est un frein à l'innovation. :)
- [^] # Re: réflexion du soir, bonsoir
  
  Posté par ptit_tux le 20 juin 2003 à 23:42. Évalué à -2.
  
  > Ce journal pose par extension le problème de la liberté, peut on considérer la license GPL comme libre alors qu'elle impose sa vision de la liberté aux gens qui utilisent ses sources dans leurs programmes.
  
  Bravo.
  
  C'est librement implémenté et c'est librement utilisé. C'est donc librement que l'utilisation des extensions c'est généralisé.
  
  On parle d'extensions ! Les logiciels qui n'utilisent pas les extensions marchent toujours. Et au nom de la liberté, je dis que tout le monde est libre d'utiliser ces extensions. gcc, etc n'introduit pas des incompatibilités !
  
  Vos "remarques" à part demander le nivellement par le bas, ou figer l'évolution du logiciel libre, est "néfaste".
  - [^] # Re: réflexion du soir, bonsoir
    
    Posté par ours Ours (site web personnel) le 20 juin 2003 à 23:56. Évalué à 3.
    
    Il ne remet pas en cause le fait que GNU soit compatible mais qu'au contraire, ce qui est spécifique GNU est très souvent utilisé et devient inutilisable ailleurs. donc on ne sait toujours pas où se situe la limite et la définition de l'extension propriétaire, d'autant que comme dit plus bas, certaines extensions de microsft sont tout à fait implémentables (et le sont d'ailleurs).
    
    Ca me fait penser à la machine virtuelle java intégrée par défaut sur certaines versions d'IE. Certains développeurs utilisent ces fonctionnalités puis comme par hasard, leurs programmes ne marchent pas sur la jvm 1.4.1.
    
    Après le libre aurait pu évoluer autrement niveau license, l'histoire est faite par certains hommes qui ont eu un jour une idée folle ... C'est la vie ! :o)
    - [^] # Re: réflexion du soir, bonsoir
      
      Posté par ptit_tux le 21 juin 2003 à 00:35. Évalué à 1.
      
      > ce qui est spécifique GNU est très souvent utilisé et devient inutilisable ailleurs
      
      Par définition, on ne peut pas dire non.
      
      SVP gcc faites des extensions que personne veut utiliser. C'est vrai quoi, si c'est utilisé, ya toujours une minorité qui est pas contente ! Et la minorité c'est plus important que la majorité.
      
      Vous voulez que gcc voit limité au plus petit dénomiteur commun des OS. Bref, avec vous gcc n'est plus libre dans ces développements. "Gcc n'est pas libre", la phrase me fait froid dans le dos... Selon "certains" ici, Gcc doit faire ce que les autres font et rien de plus (sauf des extensions que les utilisateurs ne veulent pas utiliser)
      
      > ailleurs. donc on ne sait toujours pas où se situe la limite et la définition de l'extension propriétaire
      
      Libre, c'est libre. Les extensions Gcc sont libres.
      Le fait que les autres ne fasse pas comme gcc ne rend pas gcc proprio ! Sinon je peut dire :
      - J'ai un programme pour BSD, mais le programme il utilise des extensions de BSD qu'on trouve pas dans Linux. Fait chié BSD avec ces extensions proprios.
      - [^] # Re: réflexion du soir, bonsoir
        
        Posté par ours Ours (site web personnel) le 21 juin 2003 à 09:44. Évalué à 1.
        
        - J'ai un programme pour BSD, mais le programme il utilise des extensions de BSD qu'on trouve pas dans Linux. Fait chié BSD avec ces extensions proprios.
        
        Et ben non, tu as fait un programme en GPL dans un environnement relativement standardisé, les programmes en BSD ne pourront pas en profiter (sauf si tu leur envoies le patch en BSD mais bon).
        
        Le patch BSD pourra être intégré partout.
# À propos du C.

Posté par Schwarzy le 20 juin 2003 à 23:01. Évalué à 3.

Tu parles de la portabilité du C. Je suis surpris par cette remarque. Je travailles avec différents compilo C et gcc est loin, très loin, d'être un problème. C'est le plus agréable des compilo C car sur le C Ansi/ISO il n'y a pratiquement pas de de bug. Les bugs des compilo sont le problème de la portabilité du C, pas les extensions.

Quant aux extensions du C ajoutées sur gcc, c'est assez courant de les retrouver sur d'autres compilo. Elle sont nécessaire pour faire de la programmation système. Avec quelques macros, on peut s'en sortir pour masquer les extensions. C'est vraiment pas la mer à boire.
- [^] # Re: À propos du C.
  
  Posté par Ramso le 20 juin 2003 à 23:17. Évalué à 3.
  
  donc gcc ne semble pas poser trop de problèmes, j'aurais pensé le contraire.
  
  de toute façon, difficile de se faire une idée sur BSD, c'est déjà gcc qu'il faut utiliser.
  
  si d'ailleurs quelqu'un sait quelque chose sur les compilateurs qu'utilisait *BSD avant gcc... ils avaient les leurs ?
  - [^] # Re: À propos du C.
    
    Posté par Schwarzy le 20 juin 2003 à 23:35. Évalué à 3.
    
    Pour être précis. Tous les compilo qu'on trouve aujourd'hui arrivent à suivre ua moins la norme ANSI (1989). Les extensions que l'on trouve existent pour tenir compte des contraintes de la programmation système. Ils s'agit de mots clés ajoutés au language et facilement masquable dans des macros.
    
    Je parle bien de la portabilité du language. Les problèmes liés aux architectures et au matériel existent toujours et sont à imputer au language C et non aux compilo.
    
    A propos de gcc et de BSD, gcc est l'un des premiers programmes qui ait existé dans le projet GNU. Il a rapidement atteint une qualité certaine qui a séduit beaucoup de développeurs dans les années 90 et peut-être même avant.
    *BSD, à ses origines, embarquait (je crois) son propre compilo C. Par la suite gcc a pris le dessus.
    - [^] # Re: À propos du C.
      
      Posté par Ramso le 20 juin 2003 à 23:40. Évalué à 0.
      
      merci pour toutes tes réponses
# Re: réflexion du soir, bonsoir

Posté par Edouard Gomez (site web personnel) le 20 juin 2003 à 23:08. Évalué à 7.

C'est la technique du "Embrace and extend", mais bon ca a au moins le mérite d'apporter un plus. Puis tout ç a est fait dans la transparence, tes outils GNU (pour la plupart) peuvent tourner en mode POSIX.

Pour moi, les outils GNU respectent souvent un standard du mieux possible puis ensuite sont étendus pour répondre à des lacunes ou introduire des facilités. Dans le logiciel propriétaire, le respet du standard est souvent bien secondaire... l'apparition des extensions/facilités se fait souvent au détriment du standard qui lui restera peu implémenté.

Petit exemple illustrant ce fait: GNU CC (GNU) et Visual C++ (MS). GNU CC n'a de cesse d'implémenter le standard ISO C99, tandis que VC++ depuis sa version 5 stagne dans une sorte de coma entre ISO C89 (ANSI C) et ISO C99 très partiellement supporté. Par contre dans le même temps, VC++ a intégré beaucoup plus d'extensions que gcc qui tente de limiter les __attribute__() (j'avoue c'est pas gagné, gcc 3.x en apporte beaucoup). Dans un cas y'a la volonté affiché de pourrir le langage C (qui est plutot pas mal en ISO C99) pour favoriser C# et de l'autre y a juste la volonté de faire mieux, _et_ encore plus compatible.

Voila ma vision des choses
- [^] # Re: réflexion du soir, bonsoir
  
  Posté par Schwarzy le 20 juin 2003 à 23:21. Évalué à 3.
  
  Juste pour compléter ton propos, on peut encore (sur)vivre avec le C de MS*. Par contre le C++, c'est une merde infame ! C'est simple, il y a deux C++ sur le marché. Celui de MS pour sa plateforme Windows et le "Standard" que tous les autres essayent de suivre.
  
  (*) Au passage, compiler avec GCC via Mingw32 si possible, il trouve plein de bug potentiel que MSVC ne trouvera jamais. http://www.bloodshed.net/dev/devcpp.html(...) est très bien. Dommage qu'au boulot on doit encore ce farcir MSVC :( .
  - [^] # Re: réflexion du soir, bonsoir
    
    Posté par Ramso le 20 juin 2003 à 23:29. Évalué à 2.
    
    lol, tout à fait dans mon propos, gcc est devenu le « standard » à suivre parce qu'il est le plus répandu. encore ces arguments à la microsoft mais dans un autre contexte.
    
    pour devcpp, je crois qu'il utilise gcc, peut-être avec mingw32 (si j'ai compris ce que c'est).
    - [^] # Re: réflexion du soir, bonsoir
      
      Posté par Schwarzy le 20 juin 2003 à 23:41. Évalué à 2.
      
      lol, tout à fait dans mon propos, gcc est devenu le « standard » à suivre parce qu'il est le plus répandu.
      
      euh .. tu frises l'insulte là ! Déja prouves-moi que gcc est le plus répandu (et dans quel domaine ?).
      De plus si gcc est aussi apprécié, et peut-être répandu, c'est pour sa fiabilité. Je me demande si tu as vraiment programmé en C en jour pour sortir de tels propos. J'ai déja environ 12 ans de C et gcc est une vrai rolls. Je rêve de le voir partout dans l'embarqué parce que j'en ai marre de debugger, et mon code, et le compilo !!!!
      - [^] # Re: réflexion du soir, bonsoir
        
        Posté par Ramso le 20 juin 2003 à 23:53. Évalué à 2.
        
        ok, je me suis emballé et comme t'as pu le remarquer, le petit monde de gcc m'est assez inconnu :)
        
        j'imaginais que gcc avait des subtilités de syntaxe ou des options de compilation qui faisaient qu'en les utilisant, le logiciel ne pouvait plus être compilé avec un autre compilateur.
        
        apparemment, C a déjà assez de problèmes à régler par ailleurs.
        
        la problématique ressortira peut-être plus avec bash et les scripts shell.
        
        il faudrait voir aussi du côté de posix.
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par Schwarzy le 21 juin 2003 à 00:21. Évalué à 2.
        
        Si tu démarres dans ce mode fou, fou, fou de la programmation, une petite remarque sur la notion de portabilité.
        
        Même si elle trouve ses racines sur un plan technique, c'est du marketing. Obtenir la portabilité, c'est mettre en place des outils automatiques de test (dit de régression dans un jargon plus technique). Mettre au point de tel outils, c'est long, très long, très très long même, difficile et le boulot le plus dévalorisant.
        En conséquence, il est rare de pouvoir avoir des tests de qualité. Les spécifications aident plus les programmeurs (les clients) que les programmeurs qui font l'implémentation. Ils existent toujours des zones de flous qui parasitent la portabilité. Enfin, tu peux intégrer les bugs dans les objectifs de la portabilité. Ce dernier aspect est celui qui casse le plus la portabilité.
        
        Mais, heureusement, avec le temps [genre 10/15 ans], il arrive que des technologies arrivent à approcher les 99 % de compatibilité entre les différentes implémentations. En exemple j'ai l'ANSI C, le Forth dans les languages informatiques. Java, POSIX sont pas trop loin (encore que ... Java 95%, POSIX 90% [au pifomètre :)] ). Win32 ça tient la route (90%) si on suit uniquement la version NT,2k et XP (les 9x,Me c'est de la merde en boîte).
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par Ramso le 21 juin 2003 à 00:36. Évalué à 0.
        
        et 100% pour Python ? ;)
        
        ok c'est sûrement plus simple avec un langage de haut niveau et relativement jeune.
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par Schwarzy le 21 juin 2003 à 00:51. Évalué à 3.
        
        non 100 % ca n'existe pas puisque qu'il dépend du système en-dessus (cf le mail de Christophe Grand sur le dilemme et la superposition des abstraction). Mais il peut prétendre au 99%. Surtout que c'est la même implémentation. Mais il est tout à fait faisable de faire une version liée à Windows en utilisant des bibliothèques Windows only. Je te renvoie à nouveau au mail de Christophe Grand.
        Il serait par contre intéressant de conparer Python et Jython.
    - [^] # Re: réflexion du soir, bonsoir
      
      Posté par ptit_tux le 21 juin 2003 à 00:01. Évalué à 0.
      
      > tout à fait dans mon propos, gcc est devenu le « standard » à suivre parce qu'il est le plus répandu.
      
      gcc respecte les standards et même beaucoup de standard pour être portable. Si les extensions de gcc te gonflent, limite toi à ANSI C ou a tout autres normes respectées par les cibles de ton programme. C'est à toi de faire des programmes portables (ou qui tourne uniquement sous BSD) ! C'est pas à GCC de dire :
      Bon, ben maintenant on fait que du BSD (ou n'importe quoi d'autre) et si vous avez des bonnes idées d'extensions, vous vous les taillées en pointe...
      
      GCC NE T'IMPOSE PAS T'UTILISER SES EXTENSIONS. SI TU FAIS UN PROGRAMME SPÉCIFIQUE À GCC, C'EST TON CHOIX.
      
      Et s'il y a plein de programmes qui utilisent les extensions de gcc, c'est le choix des l'utilisateurs et non de gcc ! C'est du logiciel libre. C'est-à-dire que les dev de gcc ajoute ce qu'ils veulent et les utilisateurs utilisent ce qu'ils veulent.
      
      Je vois pas pourquoi les specs de gcc devraient être dictées par une norme, ou BSD, ou MS, ou ...
      
      C'est vraiment n'importe quoi ce journal.
      - [^] # Re: réflexion du soir, bonsoir
        
        Posté par Ramso le 21 juin 2003 à 00:19. Évalué à 1.
        
        t'énerve pas !!!
        
        j'ai bien compris que gcc et mes programmes peuvent « coller » aux standards, c'est pas le problème.
        
        mais quand je veux utiliser un logiciel taillé pour gcc, je dois me farcir l'installation de gcc avec parce que mon compilateur ne passe pas. certes c'est un mauvais exemple car gcc est « par défaut » dans freebsd.
        
        Je vois pas pourquoi les specs de gcc devraient être dictées par une norme, ou BSD, ou MS, ou ...
        
        heu... C99, je dirais :)))
        
        je pense plutôt aux options de compilation au nom obscur, genre --fnolinemakecoffeifalignedon64bit que les compilateurs C sur les autres unix n'ont pas.
        
        le fond du problème reste là, microsoft fait des extensions et tout le monde trouve ça mal, même si ce sont de bonnes idées comme tu dis. pourtant, tu te sens obligé de les utiliser ? donc tu reste libre d'une certaine manière.
        
        GNU a aussi ses extensions mais il ne viendrait pas à l'esprit que de les utiliser c'est mal. ça tient à peu de choses :)
        
        les dev de gcc ajoute ce qu'ils veulent et les utilisateurs utilisent ce qu'ils veulent.
        
        s/gcc/microsoft/g
        
        où se situe la limite ?
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par ptit_tux le 21 juin 2003 à 02:02. Évalué à 0.
        
        > mais quand je veux utiliser un logiciel taillé pour gcc, je dois me farcir l'installation de gcc avec parce que mon compilateur ne passe pas. Ce n'est pas gcc ton problème. Ton problème, c'est les développeurs qui ont choisi d'utiliser les extensions spécifiques à Gcc. Je te souhaite du courage pour faire ce reproche aux développeurs qui utilisent les extensions de gcc : - "Et les branleurs ! Au boulot et ne comptez plus sur Gcc pour la portabilité, ni ses petites extensions qui rendent le développement si agréable. Il faut que tous les programmes soient portés pour tous les compilos. PS : Utiliser gcc qui tourne partout avec des extensions "superbes" : c'est trop facile". Puis si tu installes gimp sur freebsd et qu'il n'y a pas gtk+ sur ta bécane freebsd, demande un portage de gimp vers Xt. Les devs gimp : - "pourquoi ?" Toi : - "c'est vraiment trop chiant d'installer gtk+" Les devs gimp : - "C'est vraiment chiant de bosser pour des chieurs". > C99, je dirais :))) Change rien au problème. Si gcc est libre, et ne doit pas être limité à la norme C99 ou C2004 si elle existe déjà. > le fond du problème reste là, microsoft fait des extensions et tout le monde trouve ça mal, même si ce sont de bonnes idées comme tu dis. pourtant, tu te sens obligé de les utiliser ? Non. Qui oblige les developpeurs à utiliser les extensions gcc ? PERSONNE. MS a fait des trucs non proprio. Par exemple vfat. MS a aussi fait des trucs proprio. Par exemple NTFS. MS n'a pas fait que du proprio. Et la spec c# est aussi proprio que la norme Posix. Donc je ne vois aucun problème à mono (car tu as surement voulu lancer un troll sur mono). ok, ya des rumeurs comme quoi les api brevetés, ou chezpasquoi. Mais rien qui rend caduc la GPL. D'ailleur RMS a dit quelque chose de négatif sur mono ? T'as des liens ? > donc tu reste libre d'une certaine manière. Tout est libre sur ma bécane. Sauf que j'ai un lecteur mp3 et lecteur de dvd ce qui peut poser problème au état unis (brevets) et peut-être en europe quand la france appliquera EUCD (pour les DVD). Et si j'installe mono, XD2 que je choisi le thème Redmond, que j'utilise samba pour partager des imprimante ou des fichiers entre machine Linux, ça reste du libre ! > > les dev de gcc ajoute ce qu'ils veulent et les utilisateurs utilisent ce qu'ils veulent. > > s/gcc/microsoft/g > > où se situe la limite ? Donc si une expression est vraie pour microsoft et gcc, tu conclus que gcc est proprio. J'ai un conseille pour toi. Si tu ne vois pas la différence en gcc et MS : RETOURNE SOUS WINDOWS PS: Impossible que je ne m'énerve pas sur ce type de commentaire.
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par Christophe GRAND (site web personnel) le 21 juin 2003 à 07:58. Évalué à 2.
        
        mais quand je veux utiliser un logiciel taillé pour gcc, je dois me farcir l'installation de gcc avec parce que mon compilateur ne passe pas.
        
        mais quand je veux utiliser un logiciel écrit en XYZ, je dois me farcir l'installation du compilateur XYZ parce que je ne l'ai pas !!??
        
        Et oui, quand tu as les sources, tu es obligé de te farcir d'avoir les outils de développement pour les utiliser.
        
        Que t'apporte le respect des standards ? Le fait de pouvoir éviter de prendre les mêmes outils que les développeurs (parce que tu ne peux pas te les procurer : ils ne tournennt pas sur ton OS ou ils sont trop chers et tu as déjà acheté des outils kifonpareil). Tu dois cependant avoir tous les outils équivalents. Donc tu as gagné un peu de liberté puique tu as le choix.
        
        Que t'apporte l'utilisation de gcc ? Le fait de pouvoir prendre les mêmes outils que les développeurs partout sans les contraintes ci-dessus (plateforme et pognon).
        
        La réponse de Schwarzy sur Python est exemplaire :
        1/ Python n'a pas de norme
        2/ Python est portable à "99%"
        car Python repose sur une implémentation unique et libre et ça remplace le besoin d'un standard.
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par Barbapapa le 21 juin 2003 à 08:27. Évalué à 2.
        
        2/ Python est portable à "99%"
        
        Si certains modules utilisent des fonctionnalités liées à l'OS, c'est indiqué. Le développeur peut donc, en connaissance de cause, utiliser ces fonctions ou pas.
        
        En fait, le principal problème que j'ai avec Python, du point de vue de la portabilité, c'est qu'il n'est pas portable avec lui-même ! Le script que j'avais écrit avec Python 1.5.2 marchera-t-il avec Python 2.3 ? Peut-être, peut-être pas, il va falloir se farcir tout un tas de tests pour le savoir.
        
        Exemple: 5/2 donne 2 jusqu'à la 2.3. A partir de la 2.4 ça donnera 2,5 ! Chouette !!
        
        Encore un autre sur lequel je viens de tomber:
        
        a = None
        if a > 5:
        print "superieur"
        else:
        print "inferieur"
        
        avec une version antérieure à la 2.1 ça donne "superieur", à partir de la 2.1 ça donne "inferieur" ! Re chouette !!
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par Vivi (site web personnel) le 21 juin 2003 à 12:24. Évalué à 3.
        
        ça c'est pas de la protabilité, c'est de la compatibilité entre versions.
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par ours Ours (site web personnel) le 21 juin 2003 à 12:42. Évalué à 0.
        
        oui mais ca me ferait chier d'avoir à maintenir python 1.5, 2.1, 2.2, 2.3, 2.4 sur mon serveur puisque chaque client a sa propre version
        T'imagines si y a une faille de sécu à partir de la version 1.5, faut tout mettre à jour (si elles sont encore maintenues)
        
        Dans la pratique, on peut demander aux gens de mettre à jour leurs softs, mais comme on a vu, si il y a des tests, ca ne génère pas d'erreurs donc on peut avoir des failles très connes (style openssh il y a déjà qqes tps, deux signes qui changent).
        Bref du bonheur en perspective.
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par Ramso le 21 juin 2003 à 13:01. Évalué à 2.
        
        ça sent le FUD ça...
        
        Python 1.5 n'est plus maintenu
        Python 2.1 est vieillissant donc il serait quand même temps de passer au 2.2
        Python 2.2 est la version stable actuelle
        Python 2.3 est encore en bêta, alors la 2.4 j'en parle même pas...
        
        Les auteurs de la norme Python (cf. mon commentaire plus haut) ont choisi de ne pas se traîner des mauvais choix tout au long de leurs versions. La norme de Python 1.5 n'est pas la norme de Python 2.1 et c'est pas plus mal car ça veut dire qu'ils se remettent en cause et qu'ils corrigent leurs erreurs.
        
        Si vous n'avez pas envie de troller sur Python, regardez la situation avec GNU autoconf et automake. Les versions 1.4, 1.5, 1.6 et 1.7 sont incompatibles ou presque entre elles et les mainteneurs de Debian cherchent à se débarrasser des anciennes versions.
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par Ramso le 21 juin 2003 à 13:04. Évalué à 2.
        
        J'ai oublié de préciser que Python 2.1 a encore un sens parce que Zope dans ses versions 2.5 à 2.6 l'utilise.
        
        Zope 2.7 passe à Python 2.2 et ça nous débarassera des bugs et des ratés de la norme 2.1.
        
        Certes il faudra vérifier le code de ses produits mais si on s'est pas amusé à utiliser la magie de 2.1, le changement devrait être minime.
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par Barbapapa le 21 juin 2003 à 21:12. Évalué à 3.
        
        ça sent le FUD ça...
        
        L'argument ne te plaît pas donc c'est du FUD ? Mouais.
        
        Mon contexte, c'est un LL écrit en Python vers 1997 dont j'assure la maintenance depuis maintenant trois ans. A l'époque où il a été écrit la version de Python devait être la 1.4.
        
        A chaque nouvelle version de Python, je dois vérifier si par hasard Guido van Rossum n'aurait pas cassé la compatibilité ascendante.
        
        Des fois ça provoque une erreur franche et nette avec arrêt du programme (socket.connect qui prend deux arguments jusqu'à la 1.5.2 puis un tuple à partir de la 1.6), d'autres fois comme dans l'exemple avec None ça marche mais avec un comportement erronné.
        
        En clair un boulot chiant et sans intérêt à répéter à chaque nouvelle version.
        
        Les auteurs de la norme Python (cf. mon commentaire plus haut) ont choisi de ne pas se traîner des mauvais choix tout au long de leurs versions.
        
        C'est bien le problème, Python n'est pas un langage de programmation mais un projet de langage de programmation. Guido van Rossum modifie des éléménts du langage (je ne juge pas ici de la pertinence de la modification du point de vue du langage) apparemment sans se soucier des effets sur les gens qui utilisent son langage pour autre chose que des programme jouets.
        
        J'ai des programmes écrits en Fortran 77 qui fonctionnent exactement comme il y a 20 ans. Mes fichiers LaTeX d'il y a dix ans compilent parfaitement.
        
        Si tu choisis Python pour écrire un programme, tu es bon pour vérifier tous les ans si la nouvelle version n'a pas cassé quelque chose. Quand je vois des discussions sur fcp à propos de rendre Python insensible à la casse, j'ai peur (même si je ne sais pas si ces discussions ont abouti à quelque chose) !
        
        La devise de Python c'est "write once, debut at every release" !
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par Ramso le 21 juin 2003 à 13:09. Évalué à 0.
        
        Mais quelle idée de tester si None est supérieur à 5... franchement...
        
        Si a doit contenir un nombre et être testé numériquement, initialise-le à 0.
        
        Si tu veux que a puisse valoir None, vérifie ça avec
        
        if a is None:
        blabla
        
        Et puis évite d'utiliser Python 2.3 et 2.4, c'est des versions en développement. La version stable est la 2.1.
        
        C'est quand même bizarre de se plaindre d'une version obsolete mais de jouer avec des versions en développement, non ?
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par ours Ours (site web personnel) le 21 juin 2003 à 13:14. Évalué à 1.
        
        bah il teste, comme bcp testent php 5
        vérifier ce qui posera problème, c'est nécessaire si on ne veut pas rester le cul entre deux chaises et éviter de vérifier tt le code
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par Ramso le 21 juin 2003 à 13:18. Évalué à 0.
        
        ha bon ???
        
        tiens tout à coup tu réalise qu'il faut vérifier ce qui change d'une version à l'autre...
        
        Évidemment quand c'est du PHP c'est moins grave...
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par ours Ours (site web personnel) le 21 juin 2003 à 13:29. Évalué à 1.
        
        En fait, y a un truc à comprendre
        PHP ne modifie que son comportement qu'entre les versions majeures
        PHP 1 / 2 / 3 / 4 / 5
        Python modifie son comportement entre les versions mineures
        
        J'ajouterai que les modifs entre PHP 3 et 4, et entre 4 et 5 sont mineures
        
        (pour infos, l'architecture objet change un peu, d'ailleurs la majeure partie des scripts ne seront pas à modifier
        Tu peux en savoir plus sur http://www.phpbuilder.com/columns/argerich20030411.php3(...) )
        
        Donc, sachant que la majorité des personnes utilisant php n'utilisent pas l'architecture objet (pas de FUD là dessus SVP, j'ose espérer qu'on n'est pas obligé de connaître l'objet pour programmer, surtout quand la doc est très bien faite ce qui n'est pas toujours le cas), c'est vite réglé, on garde les deux versions PHP 4 et 5, et on regarde avec les clients si on peut effectuer la mise à jour (sachant qu'un hébergeur peut maintenir deux versions de PHP).
        
        Par contre, là où je ne suis pas d'accord, c'est de maintenir 4 versions de python, qui d'ailleurs ne sont peut être plus maintenus (possibles problèmes de bugs).
        
        Bref ce que je veux dire, c'est qu'un langage sérieux essaie de maintenir le maximum de compatibilité avec sa version précédente, et bien que ce ne soit pas possible avec tous, certains langages s'en sortent moins bien que d'autres.
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par Ramso le 21 juin 2003 à 13:16. Évalué à 2.
        
        La stable est la 2.2 !!
        
        et la 2.1 surtout si t'utilise les versions acutelles de Zope.
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par ours Ours (site web personnel) le 21 juin 2003 à 13:32. Évalué à 0.
        
        A ce que j'ai compris, la 2.1 est dépassée
        Tu veux dire que zope se base sur un produit dépassé et qu'il ne peut pas évoluer à cause de problèmes de compatibilités ?
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par Ramso le 21 juin 2003 à 12:54. Évalué à 2.
        
        1/ Python n'a pas de norme
        2/ Python est portable à "99%"
        car Python repose sur une implémentation unique et libre et ça remplace le besoin d'un standard.
        
        fauuuuuuuuux !!!
        
        Justement, Python est une norme, son implémentation de référence est CPython mais il en existe d'autres : Jython et Stackless Python à ma connaissance.
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par ours Ours (site web personnel) le 21 juin 2003 à 12:57. Évalué à 1.
        
        elle est normalisée par quel institut ?
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par Ramso le 21 juin 2003 à 13:13. Évalué à 2.
        
        Par la Python Software Foundation, tout ce qu'il y a d'ouverte au sens publique et open source.
        
        http://python.org/psf/(...)
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par ours Ours (site web personnel) le 21 juin 2003 à 13:30. Évalué à 1.
        
        Génial, donc je dis que je suis un institut de normalisation et je normalise mon propre langage.
        Bref je me demande pourquoi java a voulu normalisé son langage à jour puisqu'il est de facto normalisé par une entité indépendante à sun.
        
        [^] # Re: réflexion du soir, bonsoir
        
        Posté par ours Ours (site web personnel) le 21 juin 2003 à 13:44. Évalué à 0.
        
        si tu as d'autres implémentations, cela signifie que tu auras probablement des pb d'incompatibilités
        donc python est à priori encore moins portable que 99%
- [^] # Re: réflexion du soir, bonsoir
  
  Posté par Ramso le 20 juin 2003 à 23:24. Évalué à 2.
  
  C'est la technique du "Embrace and extend", mais bon ca a au moins le mérite d'apporter un plus.
  
  alors pourquoi quand microsoft le fait, c'est des méchants mais que GNU c'est des gentils ? ça me paraît plus que limité, voire « télétubbien » comme raisonnement.
  
  ce n'est pas en aucun cas contre toi, je pense que plein de gens auraient répondu ça mais je m'attendais à mieux.
  
  sinon pour gcc, je vois mieux l'aspect des choses mais j'aimerais avoir confirmation que d'utiliser gcc n'est pas un « choix sans retour » à moins de se farcir des milliers de lignes de code et de makefile pour enlever les spécificités.
  - [^] # Re: réflexion du soir, bonsoir
    
    Posté par Christophe GRAND (site web personnel) le 21 juin 2003 à 00:23. Évalué à 3.
    
    sinon pour gcc, je vois mieux l'aspect des choses mais j'aimerais avoir confirmation que d'utiliser gcc n'est pas un « choix sans retour » à moins de se farcir des milliers de lignes de code et de makefile pour enlever les spécificités.
    
    gcc compile mieux c'est tout :)
    
    Par "compile mieux" j'entends qu'il émettra plus de warnings et d'erreurs que bien d'autres compilos. Si tu pousses les options à fond et qu'il n'émet pas une seule ligne de warning en retour, ton code aura beaucoup plus de chances de se compiler ailleurs.
    
    J'en connais qui utilisent gcc comme outil de déboguage, juste pour les erreurs et les warnings.
  - [^] # Re: réflexion du soir, bonsoir
    
    Posté par Edouard Gomez (site web personnel) le 21 juin 2003 à 02:20. Évalué à 2.
    
    alors pourquoi quand microsoft le fait, c'est des méchants mais que GNU c'est des gentils ? Parce que en général MS "Embrace, does not extends so much but locks up the market", confère l'affaire Java où MS avait pensé que Java devait pouvoir taper dans les libraries système du système host... en gros ils ont pris Java "le langage", et ils avaient jeté aux orties les idées fondatrices de Java de dev Java -> "Program/compile once, runs everywhere" Mais y'a pas que MS dans ce cas, c'est juste que c'est un des seuls cas auxquels j'ai été confronté au début de ma vie de programmeur en C et en Java (ca fait 5ans, je suis pas encore un dino, ouf). Autre exemple, les appels d'objets clsid/COM/DCOM/ActiveX directement a partir de pages web... dans une moindre mesure, les aparitions sauvages de balises a l'epoque où netscape et IE se faisaient la guerre, c'etait à qui sortirait la balise la plus stupide (ze ouineur is <blink> ou <layer>) où les trucs les moins compatibles d'une version sur l'autre (MS DHTML) ça me paraît plus que limité, voire « télétubbien » comme raisonnement. C'était censé être un condensé de mon expérience, j'ai donc illustré ma phrase télétubienne car sortie de mon expérience ca pouvait être mal interprété. ce n'est pas en aucun cas contre toi Pas la peine de prévenir, on est là pour échanger des idées.
  - [^] # Re: réflexion du soir, bonsoir
    
    Posté par ptit_tux le 21 juin 2003 à 02:24. Évalué à 1.
    
    > j'aimerais avoir confirmation que d'utiliser gcc n'est pas un « choix sans retour » à moins de se farcir des milliers de lignes de code et de makefile pour enlever les spécificités. Tu peux suivre les normes et éviter ce qui est spécifique gcc pour ne pas être dépendant de gcc (même si c'est pas parfait). Problème du bac : 1- gcc tourne partout 2- gcc a des extensions spécifiques 3- gcc respecte les normes (faut utiliser les bonnes options. par ex : "-std=c89"). 4- gcc est fourni avec les sources sous GPL 5- MSCC tourne uniquement sous Windows 6- MSCC a des extensions spécifiques 7- MSCC ne respecte pas les normes 8- MSCC n'est pas fourni avec les sources. Question : A) Lequel des deux compilateurs n'est pas un « choix sans retour » B) Lequel des deux compilateurs donne le plus de garanti que le source développé est portable. Le candidat étudira les deux cas suivants 1) développer en respectant les normes 2) développer en utiliser les spécificités des compilateurs. C) Remplacez, dans l'énoncé, les points 5 à 8 par le compilateur de Solaris, ou de BSD, ... et répondez à A) et B) . Si tu fais tout le problème, normalement, tu dois savoir quel compilateur n'est pas un « choix sans retour » .
    - [^] # Re: réflexion du soir, bonsoir
      
      Posté par ours Ours (site web personnel) le 21 juin 2003 à 10:01. Évalué à 2.
      
      C) Remplacez, dans l'énoncé, les points 5 à 8 par le compilateur de Solaris, ou de BSD, ...
      et répondez à A) et B) .
      Actuellement (et depuis quelques temps déjà) le compilo de freebsd, j'imagine de tous les bsd en fait), est gcc.
      Donc en toute logique, gcc est ok sur les points 1 à 8.
      Il respecte et ne respecte pas les normes (un normand en quelque sorte)
      
      C'est fou ce que l'on peut faire avec de la logique :o)
      
      <mavie sans interet>
      En terminale, j'avais réussi à mettre logiquement au même niveau l'homme et le singe.
      Le singe a plein de chromosomes en commun avec l'homme.
      J'en a plein avec le voisin.
      Donc le singe est au même niveau qu'au voisin par rapport à moi.
      La prof l'a remarqué, a annoté "fausse logique" mais bon, j'ai quand même eu 13, j'étais content :o)
      </mavie sans interet>
      - [^] # Re: réflexion du soir, bonsoir
        
        Posté par Christophe GRAND (site web personnel) le 21 juin 2003 à 10:12. Évalué à 2.
        
        Ah, le cours du sophisme est en hausse !
        
        Remarque c'est toujours un produit demandé le sophisme : il n'y a qu'à regarder la politique internationale de ces derniers mois/ans/siècles.
        
        En parlant de sophisme, ça me fait penser à "Socrate est un chat" bien sûr.
        Pub : "Socrate le demi-chien" une bonne bédé de Sfar et Blain (Socrate est le nom du chien d'Hercule. Hercule est un demi-dieu. Donc Socrate est un demi-chien).
# Re: réflexion du soir, bonsoir

Posté par Anonyme le 20 juin 2003 à 23:13. Évalué à 1.

Franchement, je trouve la reflexion assez limitée. Une extension n'est pas propriétaire parce que quelqu'un l'a crée un jour (ce qui est à peu près ton soupçons concernant les programmes de GNU) mais parce qu'elle n'est pas documentée et que sa duplication est découragées.

Donc effectivement, ça tient à la licence.
- [^] # Re: réflexion du soir, bonsoir
  
  Posté par Ramso le 20 juin 2003 à 23:14. Évalué à 1.
  
  Pourtant rien ne t'empêche d'implémenter les extensions de Microsoft sur HTML et CSS, elles ne sont donc pas propriétaires ?
  - [^] # Re: réflexion du soir, bonsoir
    
    Posté par Anonyme le 21 juin 2003 à 01:34. Évalué à 2.
    
    Les extensions de Microsoft sont proprietaires par leur licence, le code n'est pas disponible librement. Mis à part ça, le fait que ces extensions n'est pas un problème sur un plan théorique : ils ont le droit, s'ils le veulent, d'ajouter des fonctionnalités à leur logiciel. Ce qui pose problème, c'est que leur créateur de page web comme FrontPage crée du HTML avec ces extensions en le présentant comme du HTML standard w3c. Alors que ce n'est pas le cas. Si tu écris un script utilisant des options de GNU qui n'existent pas dans les équivalents, c'est parce que ça te rend service. C'est à toi de préciser que ton script nécessite une version GNU des outils, où une version comprennant les options ajoutées par GNU. Les outils GNU étant libre, ces options peuvent être ajouté facilement dans n'importe quel outil libre - ou bien les outils GNU peuvent être installé. A chacun de faire son choix. Un script peut dépendre d'un logiciel précis, d'une version précise (un script bash n'est pas un script sh, alors qu'un script sh doit fonctionner avec bash). Ca ne choque pas. Par contre, une page HTML 4.0 devrait fonctionner avec n'importe quel navigateur supportant le HTML 4.0. En quelque sorte, une page HTML 4.0 dépend d'un logiciel supportant le HTML 4.0.
    - [^] # Re: réflexion du soir, bonsoir
      
      Posté par Barbapapa le 21 juin 2003 à 08:15. Évalué à 4.
      
      Si tu écris un script utilisant des options de GNU qui n'existent pas dans les équivalents, c'est parce que ça te rend service.
      
      A mon très humble avis, le problème est plutôt que tu utilises les outils dont tu disposes (make, bash, etc.) en pensant que si ça marche sur ta machine Linux, ça marchera sur n'importe quel Unix ce qui est malheureusement faux.
      
      Les différences ne portent pas seulement sur les options de tel ou tel utilitaire mais aussi sur le format de sortie de ces mêmes utilitaires (wc qui te sort le nom du fichier sous Linux mais pas sous HP-UX par exemple). Comment peux-tu le savoir si tu ne disposes pas d'une station HP sous la main ?
      
      Autant de petits détails bien chiants qui font que j'installe les outils GNU sur toutes les machines sur lesquelles je bosse. Comme ça je retrouve mes petits :)
      - [^] # Re: réflexion du soir, bonsoir
        
        Posté par ours Ours (site web personnel) le 21 juin 2003 à 09:55. Évalué à 2.
        
        A mon très humble avis, le problème est plutôt que tu utilises les outils dont tu disposes (make, bash, etc.) en pensant que si ça marche sur ta machine Linux, ça marchera sur n'importe quel Unix ce qui est malheureusement faux.
        Oui je pense que c'est ca le problème, quand tu travailles en connaissance de cause, tu ne peux que t'en vouloir à toi même si il y a des défauts de compatibilité (après cela dépend du contexte, si tu es dans une boite spécialisée ds la maintenance unix, il est de bon ton que tes programmes soient portables).
    - [^] # Re: réflexion du soir, bonsoir
      
      Posté par ours Ours (site web personnel) le 21 juin 2003 à 09:48. Évalué à 2.
      
      Par contre, une page HTML 4.0 devrait fonctionner avec n'importe quel navigateur supportant le HTML 4.0. En quelque sorte, une page HTML 4.0 dépend d'un logiciel supportant le HTML 4.0.
      HTML c'est une recommandation du w3c et non une norme.
      
      ok je -> []
# Re: réflexion du soir, bonsoir

Posté par ours Ours (site web personnel) le 20 juin 2003 à 23:39. Évalué à -1.

ls est un parfait exemple en ce qui concerne la différence entre bsd ls et gnu ls
# Le dilemme du plus petit dénominateur commun

Posté par Christophe GRAND (site web personnel) le 21 juin 2003 à 00:11. Évalué à 5.

Quand on commence à se poser ce type de questions, l'on finit par se rendre compte qu'il n'y a ni de Saint Graal ni de lingua franca en matière de portabilité.

En exagérant, je peux dire comme toi :
Je commence à avoir le sentiment que le code machine du 8008 apporte des extensions qui interdisent la compabilité avec les programmes concçu pour la machine de Turing originale.
(trop gros, passera pas...)

Je commence à avoir le sentiment que POSIX apporte des extensions qui interdisent la compabilité avec l'Unix primordial.
(trop gros, passera pas mieux...)

L'on travaille en permanence avec un empilement d'abstractions (des hypothèses sur comment focntionne ce sur quoi tu t'appuies). POSIX est l'abstraction d'un OS. Un langage est une abstraction. Une pile réseau est une pile d'abstractions. etc.

Ce qui nous pourrit la vie, c'est que ces abstractions (ou plutôt leurs "implémentations") ont leurs limites : chaque fois, que tu es obligé d'ouvrir le capot (ou de descendre dans la pile d'abstractions) pour comprendre pourquoi ça ne marche pas.
- Parce que le compilo est buggé ou incomplet
- Parce qu'Henri s'est pris les pieds dans le câble réseau
- Parce que non, finalement cette partie du standard était pas utile pour les développeurs de la bibliothèque alors personne ne l'a testée
- Parce qu'un moustique s'est logé dans une douille
- Parce que c'est la canicule ces jours-ci et que ta station est mal ventilée
etc.

Pour limiter ces risques et donc faire un développement portable, il faut choisir avec parcimonie les abstractions dont l'on a besoin.
C'est pénible comme choix car plus tu veux de confort et ne pas passer ton temps à réinventer la roue, plus tu veux utiliser des abstractions de haut niveau ; malheureusement comme elles sont de haut niveau elles reposent sur toute une théorie d'autres abstractions. Autant de facteurs libres pouvant te poser problèmes.

(Que faire Hans, que faire ? Mâchez finnois : GNU/Stimorol !)

Un moyen d'accéder au confort sans se prendre la tête, c'est de dire :
- ok, je ne fais plus du C++ mais du C++ pour tel compilo
- ok, je ne fais plus du POSIX mais du Solaris
- ok, je choisis telle et telle implémentations et je ne me soucie pas du reste.
En bref tu jettes aux orties ta portabilité. Sauf...

...sauf si les implémentations que tu as choisies existent presque partout (au moins là où tu espérais porter).

C'est pour ça que beaucoup de projets "Unix" nécessitent GNU. Car GNU est une implémentation qui tend à jouer le rôle de l'abstraction.

En fait le caractère libre estompe la différence entre implémentation et abstraction : à quo bon développer un standard dans les moindres détails quand il existe une implémentation de référence libre. Quasiment tout le monde prendre l'implém' de référence et presque personne n'essayera de réimplémenter le standard.

Voilà là où je voulais en venir :
Les implémentations libres ne sont pas tant à comparées aux implémentations propriétaires qu'aux les standards.

La question n'est pas GNU ou Solaris (ou HPUX, etc.) mais GNU ou Posix.

(J'ai sommeil si vous avez rien compris à ma prose, je réponds aux questions aux heures de consultation ;-))
- [^] # Re: Le dilemme du plus petit dénominateur commun
  
  Posté par Ramso le 21 juin 2003 à 00:33. Évalué à 0.
  
  merciiiiiiii ! je te plussois dès que j'ai à nouveau des votes.
  
  mais comme tu le souligne toi-même, GNU s'impose, donc si je ne veux pas rester bloqué dans le temps, je dois utiliser GNU/FreeBSD ;)
  
  GNU ne deviendrait-il pas un quasi-monopole en matière d'Unix et d'implémentation, surtout si plus personne ne cherche à implémenter le standard ?...
  
  bon j'arrête là sinon ça va partir en troll de petite vertu.
  
  je vais essayer de conclure en me disant que la licence libre de GNU nous protège contre les dérives de ses extensions et de son quasi-monopole, là où dans le cas de microsoft, la licence les rend dangereux.
  
  de toute façon, BSD roulaize, au moins c'est un vrai système ;)
  
  et je sors... pour mieux aller dormir !
  - [^] # Re: Le dilemme du plus petit dénominateur commun
    
    Posté par Christophe GRAND (site web personnel) le 21 juin 2003 à 00:50. Évalué à 4.
    
    GNU ne deviendrait-il pas un quasi-monopole en matière d'Unix et d'implémentation, surtout si plus personne ne cherche à implémenter le standard ?...
    
    Quand je dis qu'un projet libre peut remplacer un standard, celà va jusque dans l'élaboration : au lieu d'écrire un standard on écrit une implémentation libre de référence. Ce sont deux travaux coopératifs.
    
    Dans ce point de vue très pécis, les licences copyleft sont nécessaires car elles évitent le fork proprio. C'est donc un avantage sur le standard : il devient impossible d'ajouter des extensions proprios. Une extension est toujours publique, libre.
    
    (Cette fois j'y vais)
  - [^] # Re: Le dilemme du plus petit dénominateur commun
    
    Posté par ours Ours (site web personnel) le 21 juin 2003 à 11:45. Évalué à 3.
    
    mais comme tu le souligne toi-même, GNU s'impose, donc si je ne veux pas rester bloqué dans le temps, je dois utiliser GNU/FreeBSD ;)
    
    http://www.debian.org/ports/freebsd/(...)
    Il y a un projet Debian GNU/FreeBSD à ce propos.
  - [^] # Re: Le dilemme du plus petit dénominateur commun
    
    Posté par ckyl le 21 juin 2003 à 12:57. Évalué à 3.
    >mais comme tu le souligne toi-même, GNU s'impose, donc si je ne veux pas rester bloqué dans le temps, je dois utiliser GNU/FreeBSD ;)
    
    >GNU ne deviendrait-il pas un quasi-monopole en matière d'Unix et d'implémentation, surtout si plus personne ne cherche à implémenter le standard ?...
    
    Bon je pense que tu as un certain problème :-)
    Je vais te quoter une petite discution sur FreeBSD-hacker d'il y a quelques mois. Il s'agit d'une réponse à Brett Glass bien connu des lecteurs de -security et -hackers pour etre anti GNUsien primaire un peu évolué tout de meme.
    
    Brett, i'm going to thank you on behalf of the various BSD projects for
    volunteering your time and skills in creating a BSD licensed tar that is
    GNU-tar compatable. should i expect this before or after the BSD licensed
    C compiler?
    Johan Beisser
    
    L'attitude de la core team de FreeBSD et de la plupart des commiters est la suivante :
    - Pour le système de base (noyau et l'userland vital) avoir le moins de GNU, enfin GPL, possible et le mettre dans une branche a part. Tu peux retrouver la politique des licences dans le developpeurs handbook (y'a meme une version Francaise qui doit etre dispo sur freebsd-fr s'ils ont pas oublié de commiter mes fichiers :-). La licence BSD est très fortement majoritaire. La libc BSD est un petit peu moisie par rapport à la libc GNU par exemple, mais la partie concernant le réseau de linux est presque un copier coller de la libc BSD... :-)
    - Pour tout le reste il y a generalement le choix, et souvent la politique appliquée est de choisir le meilleur outil libre disponible. Tu veux recoder gcc, tar, openssh ? LIbre a toi et bon courage !!! Les outils actuels fonctionnent très bien. Cela est considere comme une perte de temps de réecrire des logiciels faisant leur boulot, la core team prefere se concentrer sur des choses défaillantes (voir KSE, les libs de threads dans -CURRENT) ou des choses n'existant pas dans les autres système (le système de Jail et de virtualisation qui est unique et qui commence a donner un gros avantage à FreeBSD pour du mass hosting)
    Ainsi après toutes ces critiques j'espère bien que tu vas envoyer tes patchs sur -hackers pour proposer Freecc, FreeSSH, FreeTar, FreeApache & co.
    A noter que je suis totalement pour FreeSSH
    
    Il y a quand meme des problemes avec la licence GPL. Comme dit plus haut du code GPL ne peut pas etre mis dans du code BSD alors que l'inverse est vrai. Il y a, comme nous le dit l'ami brett glass, la polution de l'esprit par du code GPL. Si tu lis du code GPL et qu'après tu écris un code équivalent, en terme de fonctionalités, en BSD il y a de forte chance pour que tu reproduises ce code : problème de licence.
    
    Mais rien ne t'empeche de coder les extensions GNU dans du code licence BSD. Tu penses pas que le choix des utilitaires comme tar a été fait en connaissance de cause ? Certains membres de la core team le sont depuis que les dinosaures ont céssés d'exister...
    
    Tu as d'autres questions ou d'autres patch à soumettre ???
    - [^] # Re: Le dilemme du plus petit dénominateur commun
      
      Posté par ckyl le 21 juin 2003 à 13:01. Évalué à 2.
      
      J'oubliais :
      " if it's not broken, don't fix it."
      - [^] # Re: Le dilemme du plus petit dénominateur commun
        
        Posté par Ramso le 21 juin 2003 à 13:23. Évalué à 2.
        
        Et la licence GPL n'est pas broken ?
        
        ok, ça c'est petit... tout petit :)
        
        [^] # Re: Le dilemme du plus petit dénominateur commun
        
        Posté par ckyl le 21 juin 2003 à 13:57. Évalué à 2.
        
        A part troller, tu aides beaucoup le projet FreeBSD à se debarasser de l'ennemi GPL ?
        Je te rappelles que FreeBSD n'est pas Linusque et il te suffit d'un mail et pas mal de boulot pour avoir accès en écriture au CVS de FreeBSD...Il n'y a de tiran tel que le torvalds pour dire que c'est mal ce que tu fais :-)
- [^] # Re: Le dilemme du plus petit dénominateur commun
  
  Posté par ptit_tux le 21 juin 2003 à 00:47. Évalué à 1.
  
  > C'est pour ça que beaucoup de projets "Unix" nécessitent GNU. Car GNU est une implémentation qui tend à jouer le rôle de l'abstraction.
  
  Donc on peut affirmer que gcc aide à rendre les programmes portables car il évite aux développeurs de se prendre la tête avec les spécificités des différents compilos. On peut dire la même chose pour glibc, make, sed, gawd, bison, etc...
  
  Le standard GNU, c'est vraiment du bonheur. Et c'est pratiquement le seul qui est disponible partout.
  
  Si tu fais un programme qui utilise les extensions BSD, ton programme marche que sous BSD. Si tu fais un programme qui utilise les extensions GNU, ton programme marche partout (dont BSD). C'est vraiment que du bonheur.
# Re: réflexion du soir, bonsoir

Posté par Pooly (site web personnel) le 21 juin 2003 à 11:26. Évalué à 0.

et POSIX ???
Normalement, il doit y avoir une POSIX pour que le comportement soit POSIX compliant, non ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.