Il n'y a pas encore d'annonce officielle mais les minutes de la dernière téléconférence laissent peu d'espoir de voir une réconciliation. David Dawes (président de XFree86, à l'origine de l'exclusion de KP) est particulièrement amer, cf. son dernier mail sur le forum.
Les objectifs de ce nouveau projet sont une plus grande modularité, l'ouverture et la transparence et un cycle de développement plus court 'release early, release often'.
Aller plus loin
- Le site d'Xwin (11 clics)
- Les minutes de la dernière téléconférence (0 clic)
- Dernier mail de David Dawes sur le Forum (4 clics)
# Re: Fork d'XFree86
Posté par Troy McClure (site web personnel) . Évalué à -10.
# Re: Fork d'XFree86
Posté par mammique . Évalué à 10.
[^] # Re: Fork d'XFree86
Posté par huhuhu . Évalué à -10.
# Re: Fork d'XFree86
Posté par tgl . Évalué à -10.
# Et la langue française, bordel !
Posté par Loic Jaquemet . Évalué à -10.
[^] # Re: Et la langue française, bordel !
Posté par Alexis B. . Évalué à -8.
[^] # Re: Et la langue française, bordel !
Posté par Vivi (site web personnel) . Évalué à 10.
[^] # Re: Et la langue française, bordel !
Posté par toub . Évalué à -9.
[^] # Re: Et la langue française, bordel !
Posté par LiNX_ . Évalué à -10.
[^] # Re: Et la langue française, bordel !
Posté par nigaiden . Évalué à 10.
[^] # Re: Et la langue française, bordel !
Posté par Guillaume Laurent (site web personnel) . Évalué à 10.
[^] # Re: Et la langue française, bordel !
Posté par Shld . Évalué à -10.
[^] # Re: Et la langue française, bordel !
Posté par doublehp (site web personnel) . Évalué à -10.
je vois vachement la comunauté du libre nous faire un :
" REGARDEZ TOUS : Voila la dernière version papier de la ml de X sous ce format livre de poche 24*32 de 13275 pages dans lequel vous pourrez retrouver les superbes aventures de XXX et YYY se debatant au sujet de la manière dont sera géré le deplacement d'une fenètre sous X pour GNU/Linux. Déjà disponible dans toutes les bonnes libraries ..."
-> @
[^] # Re: Et la langue française, bordel !
Posté par Shld . Évalué à -4.
Enfin cet usage impropre de minutes est assez répandu et malgré l'Académie c'est l'usage qui fait la langue.
[^] # Re: Et la langue française, bordel !
Posté par yugz . Évalué à 2.
On ne doit pas vivre au même endroit, je n'ai jamais entendu ça. Quant à dire que c'est l'usage qui fait la langue, c'est vraiment la pauvre excuse qui permet de faire passer n'importe quoi. Avec des "Si ils le font, elors je le fais aussi", on a fait les pires horreurs.
[^] # Re: Et la langue française, bordel !
Posté par Albert ARIBAUD . Évalué à 10.
De la part du suppôt de Bescherelle que je suis :
Tu ne me sortiras donc pas cette pauvre excuse pour justifier le fait que tu ne rendrais pas aujourd'hui ton propos par : "en tant qu'ils le faisaient, fallut-il qu'on le fît" ?
C'est pourtant du français fort correct... Si on parle comme parlait Rabelais (et encore, je t'épargne la graphie de l'époque).
Ceci pour dire que oui, c'est l'usage qui fait la langue. Je vomis certains usages courants, comme les styles SMS ou simplement fonétik, et je regrette continuellement les erreurs du genre confusion entre passé simple et infinitif ("je suis aller", "il faut mélangé") mais la langue que je défends aujourd'hui, elle est née d'un usage.
Tiens : je hurlais chaque fois que je voyais une pub avec le mot "dance" dedans, craignant pour la graphie correcte en français, à savoir "danse". Eh bien, en lisant une partition de chant choral, j'ai découvert qu'il y a quelques siècles, c'était bien "dance" la graphie correcte.
Au temps pour moi, donc. :-)
Amicalement,
Albert.
[^] # Re: Et la langue française, bordel !
Posté par patton . Évalué à 0.
"passé simple et infinitif " : Je pense que tu voulais dire participe passé et infinitif
[^] # Re: Et la langue française, bordel !
Posté par Albert ARIBAUD . Évalué à -1.
Oups ! Exact.
Merci d'avoir rectifié.
Amicalement,
Albert.
[^] # Re: Et la langue française, bordel !
Posté par doublehp (site web personnel) . Évalué à -2.
... sans oublier le "cédé" "cédéromme", qui est la francisation d un sigle anglicisé(CD) depuis le francais(DC) ... Disque Compacte ... terme d'un usage courant dans toutes les publicitées de grand magasin.
-- doublehp
apt-get remove ispell
[^] # Re: Et la langue française, bordel !
Posté par Schwarzy . Évalué à 4.
moi c'est tout le contraire. L'emploi du mot "minutes" est très répandu dans le contexte où j'ai étudié et même, maintenant, celui où je travaille (qui n'est plus étudiant). Toutes les conférences en français que j'ai pu suivre parle d'obtenir les "minutes" des conférences.
tout est relatif :)
[^] # Re: Et la langue française, bordel !
Posté par Erwan . Évalué à -3.
[^] # Re: Et la langue française, bordel !
Posté par boubou (site web personnel) . Évalué à -3.
[^] # Re: Et la langue française, bordel !
Posté par Moby-Dik . Évalué à -2.
Dans le cas présent, pas un compte-rendu, une transcription...
[^] # Re: Et la langue française, bordel !
Posté par Shld . Évalué à 2.
Je vis en France où j'ai déjà entendu cet usage en mileu professionel et j'ai aussi vécu en Australie où cet usage est il est vrai beaucoup plus répandu. J'ai dû être déformé mais je n'en suis pas encore au point de Van Damme.
[^] # Re: Et la langue française, bordel !
Posté par Laurent Simon . Évalué à 7.
En outre, ce sens (document original, destiné à être conservé) se retrouve par exemple dans le terme de "minutes de terrain" en cartographie, qui désigne les relevés cartographiques précis qui sont directement fait sur le terrain.
[^] # Re: Et la langue française, bordel !
Posté par Loic Jaquemet . Évalué à -4.
En l'occurrence je ne connaissais pas l'existence de l aversion de l'académie française. Mais amha, Shld a traduit violemment le "minutes"(en) en "minute"(fr), sans trop se poser de questions ..
Mais bien sur, ce n'est que mon avis, seul Shld peut statuer la dessus ...
[^] # Re: Et la langue française, bordel !
Posté par Shld . Évalué à 7.
Je l'ai déjà dit, j'ai utilisé minutes à défaut de mieux parce que je n'ai pas pris la peine d'ouvrir un dictionnaire qui m'aurait indiqué « transcription ».
[^] # Re: Et la langue française, bordel !
Posté par Korbinus (site web personnel) . Évalué à 0.
Mes deux centimes d'euro...
[^] # Re: Et la langue française, bordel !
Posté par dinomasque . Évalué à 4.
Il y a toute une réfrence culturelle derrière le terme fork.
Et puis 'dérivé' ne reprend pas le concept de deux branches qui se séparent tel un cheveu cassant aux pointes sèches.
La vraie question est donc : si les gurus/barbus se lavaient les cheveux avec du bon shampoing, les forks seraient-ils évités ?
Sur ce je crois que je vais aller reprendre un peu de café ... ;)
BeOS le faisait il y a 20 ans !
[^] # Re: Et la langue française, bordel !
Posté par Christophe Morvan (site web personnel) . Évalué à 3.
Je trouve qu'en dépit de la connotation religieuse, schisme est plus adapté !
On pourrait utiliser « schisme (fork) »
[^] # Re: Et la langue française, bordel !
Posté par Larry Cow . Évalué à 1.
Pour le premier cas, "schisme" me semble le terme le plus adapté, pour le second ça me paraît moins évident.
[^] # Re: Et la langue française, bordel !
Posté par Nap . Évalué à 0.
pendant mes études, j'appelais "binôme" l'étudiant en binôme avec moi, c'est le même genre d'usage - que je ne défendrais pas :)
[^] # Re: Et la langue française, bordel !
Posté par Larry Cow . Évalué à 2.
[^] # Re: Et la langue française, bordel !
Posté par Christophe Morvan (site web personnel) . Évalué à 1.
Je pense qu'on peut très bien dire : « Xwin (schisme de Xfree86) vient d'annoncer... »
Ça sonne même pas mal... dommage que ça n'ait que peu de chance de se répendre ! ;o)
Je propose un schisme sur l'emploi de fork. Tous avec moi !
[^] # Re: Et la langue française, bordel !
Posté par Dams Nadé (site web personnel) . Évalué à 7.
Y'a des jours comme ca... Y'a des jours tous les jours...
[^] # Re: Et la langue française, bordel !
Posté par Shld . Évalué à -1.
Oui, moi aussi ça m'a écorché les yeux quand je me suis relu ce matin. J'aurais mieux fait d'aller me coucher et de ne poster qu'après une bonne nuit de sommeil.
# Re: Fork d'XFree86
Posté par Ramso . Évalué à 10.
[^] # Re: Fork d'XFree86
Posté par XHTML/CSS inside (site web personnel) . Évalué à 10.
[^] # Re: Fork d'XFree86
Posté par Ramso . Évalué à 10.
[^] # Re: Fork d'XFree86
Posté par Emmanuel Blindauer (site web personnel) . Évalué à -10.
[^] # Re: Fork d'XFree86
Posté par doublehp (site web personnel) . Évalué à 9.
Bon ok, le GNU/HURD est VRAIMENT lent ... mais tant que ca fait naitre de bonnes idées ... on ne fait rien de bon dans la précipitation !
[^] # Re: Fork d'XFree86
Posté par Fabimaru (site web personnel) . Évalué à -7.
(je suis déja dehors)
[^] # Re: Fork d'XFree86
Posté par un_brice (site web personnel) . Évalué à 10.
[^] # Re: Fork d'XFree86
Posté par Erwan . Évalué à 10.
Dans ce cas les deux pourront bien marcher.
[^] # Re: Fork d'XFree86
Posté par Larry Cow . Évalué à 10.
Si l'équipe d'XWin est assez intelligente ne pas rendre les choses volontairement incompatibles, et qu'XFree en fait de même, au final on aura quelque chose de très positif. Même XFree risque d'en profiter, d'une part à travers le coup de pied au cul qu'ils viennent de se prendre, d'autre part à travers le "backport" de certaines modifications jugées stables.
En bref, avant de crier "au loup", messieurs, attendez au moins de voir ce qu'ils ont à proposer, et comment cela prend forme.
[^] # Re: Fork d'XFree86
Posté par Christophe BAEGERT . Évalué à -8.
[^] # Re: Fork d'XFree86
Posté par ashram4 . Évalué à -4.
[^] # Re: Fork d'XFree86
Posté par matiasf . Évalué à 10.
Il y a hurd, linux, openbsd, freebsd, etc... et tu n'utilises qu'un noyau. Il y a xfree86, un serveur x11 qui utise ggi, des versions X11 proprios et tu n'utilises qu'un serveur X11.
D'ailleur les unix proprios avec des serveurs x11 proprios ne fournissent pas xfree86 pour que tu puisses faire tourné des applis LL.
[^] # Re: Fork d'XFree86
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Mais si, comme c'est le cas actuellement pour Emacs/XEmacs, les deux branches survivent, et avec de plus en plus d'incompatibilités, alors, on risque d'être bien embetés. Il y a déjà pas mal d'extensions dans XFree qui ne sont pas dispo sur d'autres serveurs X. Par exemple, xawtv en mode "fullscreen", n'est à ma connaissance disponible que sous XFree. La transparence dans les menus aussi je crois, n'est dispo que sous XFree. Bon, c'est supportable tant qu'une application écrite pour XFree peut s'exporter sur un autre serveur X, mais j'espère que ça le restera.
[^] # Re: Fork d'XFree86
Posté par Raphael Junqueira . Évalué à 6.
Le probleme risquerait plutot que si "Xwin" devien l'implementation de reference du consortium X (ce qui parait bien parti) XFree aura vraiment du mal a suivre les evolutions de protocoles, extensions, ... meme si on peut supposer que l'on ne fasse que des "portages"
Par exemple, xawtv en mode "fullscreen", n'est à ma connaissance disponible que sous XFree.
Ca a rien a voir avec Xfree, c l'extension Xv qui gere ca (et que d'autres serveurs X implementent)
La transparence dans les menus
Ou tu as vu que XFree gerait ca ? Ca n'est pas pcque kde le "fait" que XFree le gere. En principe ca fonctionne en faisant un screenshot de la root window et apres on fait du blending software (donc technique bien horrible). La seule appli qui fait de la vrai transparence c'est enlightenment 0.17 qui fait du pur opengl :)
[^] # Re: Fork d'XFree86
Posté par Moby-Dik . Évalué à 0.
[^] # Re: Fork d'XFree86
Posté par Raphael Junqueira . Évalué à 0.
Sachant que wine utilise openGL mais que le support de l'alpha dans la couche D3D n'est que tres minime (partiellement code du moins pour la couche d3d < 7 tout simplement pcque les jeux utilisent peu de ses fonctionnalites)
[^] # Re: Fork d'XFree86
Posté par Larry Cow . Évalué à 1.
[^] # Re: Fork d'XFree86
Posté par the_freeman . Évalué à -10.
Mouais, enfin, dans ce cas je parlerai plutôt de bête co**erie humaine, faut pas aller chercher plus loin. Mais bon, le limogeage de Keith Packard laissait présager ce fork ...
C'est de mieux en mieux pour le newbi, on va avoir droit maintenant à des questions du style 'J'hésite, vaut il mieux que j'installe XWin ou XFree86 ?'
Non, vraiment les gars, pitoyable ...
[^] # Re: Fork d'XFree86
Posté par Yohann (site web personnel) . Évalué à -6.
Alors explique un peu l'histoire de ce bordel, moi j'ai pas suivi, mais j'aimerais bien comprendre... Surtout si leurs 'engeulades' sont basees sur des points techniques...
[^] # Re: Fork d'XFree86
Posté par bmc . Évalué à -4.
Arrêtez un peu de créer sans cesse de nouveaux projets, je me demande bien comment les newbies vont faire pour s'en sortir ! Paix à leurs âmes de newbies errants...
[^] # Re: Fork d'XFree86
Posté par Shld . Évalué à 10.
[^] # Re: Fork d'XFree86
Posté par achil . Évalué à 10.
Tous les produits ont des specificites et des avantages par rapport aux autres, elle permet d'avoir au final un produit plus proche de nos attentes.
Je ne pense aps que la diversite soit un mal.
[^] # Re: Fork d'XFree86
Posté par un_brice (site web personnel) . Évalué à -3.
La diversité (alternatives à Xwindow) non, mais le dispersement?
[^] # Re: Fork d'XFree86
Posté par Ramso . Évalué à 10.
Ensuite j'ai mes habitudes et de temps en temps je teste les nouveaux produits.
Ne dirais-tu pas que le monopole est un frein à l'innovation ? Et XFree n'a-t-il pas le (quasi) monopole des extensions graphiques pour Linux (Unix) ?
Ça me paraît toujours être une bonne idée d'avoir un projet parallèle à XFree où ils pourront expérimenter de nouvelles idées et changer de politique (ex: cycles de release plus courts).
A mon avis, le risque est surtout le dispersement en matière de développement de pilotes. C'est toujours un point critique (avoir les specs et les développeurs avec le niveau suffisant pour les comprendre et les implémenter) et ce serait effectivement très con que le travail fait pour XFree ne puisse pas servir pour XWin et inversement.
Je n'aimerai pas me voir imposer l'un des deux parce que le pilote de ma carte graphique ne fonctionne que sur celui-là; pas plus que je veux qu'on m'impose Windows parce que ma carte machin ne fonctionne que sur ce système.
[^] # Re: Fork d'XFree86
Posté par M . Évalué à 2.
surtout pour les pilotes fermé comme ceux de nvidia...
Esperons que les 2 projets restent plus ou moins synchrone au niveau des pilotes.
[^] # Re: Fork d'XFree86
Posté par doublehp (site web personnel) . Évalué à 4.
heu ... tiens, je compile toujours mes modules en statiques , suis pas très logique, enfin je trouverai bien une raison un jour ...
ok /me -> []
[^] # Re: Fork d'XFree86
Posté par doublehp (site web personnel) . Évalué à -4.
- deja le logo sur mappe monde -> volonté de dminer ?
- le nom : "XFree86" ... ca veut dire que ca marche que sur *86 ? -> port impossible sur autre chose que les intel ?
bref quand je vois le logo, c est a ca que ca me fait penser ... et que je pense depuis un bail d'ailleur. Loin de moi l'intention de dénigrer XFree qui m apporte tant de bons et loyeaux services, mais ca fait 3 ans que je me demande si XFree86 est fait pour ne tourner QUE sur intel *86 ... si la réponse est non, fodrait qu ils fassent une note de bas de page avec les raisons du choix de ce nom ambigue, et avec la mention "For happy few" ...
[^] # Re: Fork d'XFree86
Posté par Éric (site web personnel) . Évalué à 0.
[^] # Re: Fork d'XFree86
Posté par yugz . Évalué à 10.
http://www.graphics-muse.com/cgi/gmMusings.pl/musings/2001/20/gm.ht(...)
[^] # Re: Fork d'XFree86
Posté par Shld . Évalué à 10.
David Wexelblat a donné l'explication du nom XFree86 sur le Forum:
http://XFree86.Org/pipermail/forum/2003-March/000191.html(...)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Fork d'XFree86
Posté par Erwan . Évalué à 0.
[^] # Re: Fork d'XFree86
Posté par Ange Bara . Évalué à 10.
Par contre, j'attend avec impatience les reactions (ie prises de position) des differentes distributions et autres "acteurs industriels".
Apparemment, ce fork n'etait désiré par personne et c'est en desespoir de cause qu'il a eu lieu.
AMHA, il est encore bien tot pour percevoir toutes les implications que cela va avoir.
[^] # Re: Fork d'XFree86
Posté par Moby-Dik . Évalué à 0.
[^] # Re: Fork d'XFree86
Posté par anonyme512 . Évalué à 10.
Partant de là, XWin part avec un sérieux avantage, parce que tous ces gens qui étaient exclus du développement de XFree vont pouvoir contribuer. Ca revient à dire que, normalement, XWin va avoir un mode de développement proche de celui de Linux, enfin du moins c'est ce qu'on peut espérer.
Quand au BOD de XFree, David Dawes en tete, c'est une belle bande de faux-jetons, parce que crier à la "fausse transparence" et autre, ça me fait doucement rigoler: il était pratiquement impossible d'avoir la moindre info sur le fonctionnement du team XFree, l'état de l'intégration des patches, etc., et, il a fallu attendre la crise avec KP pour qu'ils se décident à mettre un bugzilla en place. Et on a toujours pas d'infos pour les patches, sans compter que, pour qu'ils soient intégrés à XFree dans des délais raisonnables, il aurait fallu qu'ils acceptent plus de gens dans le projet... Le BOD de XFree n'a jamais pu/su faire la différence entre "garder le controle du projet" (pour éviter que ça parte dans tous les sens), et "garder le controle du code", et le mail de Dawes le prouve encore. Le parallèle avec Linux est immédiat: une poignée de gens (Linus, Alan, Marcelo, ...) gardent le controle du projet, mais le nombre de contributeurs au code (= les gens qui ont un accès BitKeeper ou à un des CVS de gros patches régulièrement fusionnés dans le noyau) est bien plus grand.
Pour finir, pour l'utilisateur final, je crois que la question se posera probablement jamais, car les distros n'intégreront surement qu'un des deux projets, et il y a de fortes chances que ce soit XWin.
[^] # Re: Fork d'XFree86
Posté par matiasf . Évalué à 10.
[^] # Re: Fork d'XFree86
Posté par Larry Cow . Évalué à 5.
(ok, je sors)
[^] # Re: Fork d'XFree86
Posté par matiasf . Évalué à 2.
http://people.redhat.com/mharris/(...)
http://people.redhat.com/blizzard/(...)
Il y en a peut-être d'autre.
Et si on regarde la transcription, http://fontconfig.org/~keithp/teleconference/telecon-2003-04-10.txt(...) , il y a :
=================================
Regrets
-------
Owen Taylor
Havoc Pennington
Stuart Anderson
=================================
Et Owen Taylor et Havoc Pennington sont les plus connus des "représentants" redhat pour l'interface graphique.
[^] # Re: Fork d'XFree86
Posté par anonyme512 . Évalué à 10.
------------
Chris Blizzard (RedHat)
Egbert Eich (SuSE & XFree)
Jim Gettys (HP & W3C, ex-DEC, ex-Compaq)
Mike A. Harris (RedHat)
Keith Packard (hum... ;-))
Branden Robinson (Debian -était-il la peine de le préciser ?)
Chris Schlaeger (SuSE & KDE)
Carl Worth (universitaire américain, si qqun a des infos...)
Regrets
-------
Owen Taylor (GNOME & RedHat)
Havoc Pennington (GNOME & RedHat)
Stuart Anderson (?)
Si on regarde ici, on voit meme beaucoup plus de présence des SuSE/KDE:
http://fontconfig.org/~keithp/teleconference/minutes-2003-03-27.txt(...)
Il y a même un type de NVidia !
En d'autres termes à part Mandrake, toutes les distros majeures sont "représentées", KDE et GNOME sont tous les deux "représentés" (et par conséquent freedesktop), et il y a même des fabricants de matériel.
D'ailleurs, si quelqu'un de Mandrake me lit, qu'avez vous prévu de faire ?
[^] # Re: Fork d'XFree86
Posté par matiasf . Évalué à 10.
Il y a un news sur slashdot :
http://developers.slashdot.org/developers/03/04/13/0253224.shtml?ti(...)
Keith Packard y dit :
- "And, given that RH and Debian maintainers are both actively encouraging changes, it's hard to see how they wouldn't want to follow."
Je me disais bien que KP ne pouvait avoir une telle initiative sans un gros support. Il est claire qu'au minimum RedHat et Debian va prévilégier ce fork. Mais il va falloir attendre plusieurs semaines avant d'avoir quelque chose de concret (faire les status, la todo list, un cvs, créer des comptes, etc...). Les devs dri vont suivre ça de prêt comme les développeurs de drivers qui semblent agacés par certaines lenteurs de xfree86.
http://fontconfig.org/~keithp/teleconference/minutes-2003-03-27.txt(...)
Le FOD se fait clairement allumé. On a l'impression que les gens ne croient pas en des changements fondamentaux de la part de xfree86 et qu'avant même la réunion tout le monde avait à l'esprit un fork et que c'était la réunion de la dernière chance.
[^] # Re: Fork d'XFree86
Posté par oliv . Évalué à 3.
Sans vouloir troller, je pense qu'ils ont d'autres chats à fouetter en ce moment...
Il suffit de voir l'hémorragie de développeurs ces derniers mois chez eux (Garzick, ...)
[^] # Re: Fork d'XFree86
Posté par Pierre Tramo (site web personnel) . Évalué à 2.
[^] # Re: Fork d'XFree86
Posté par ashram4 . Évalué à -2.
choisissez votre serveur graphique
choisissez votre environnement de bureau
choisissez votre gestionnaire de fenêtre
déjà que moi qui n'utilise quasiment que Linux j'ai du mal avec la distinction des 2 derniers points alors pour le newbie : il se pose 3000 questions avant l'instalation.
[^] # Re: Fork d'XFree86
Posté par mammique . Évalué à 7.
Je suppose que Xwin sera plus rapide car son architecture sera repensée, on pourrat faire une surcouche à la xonx (sf.net) ou le X11 d'Apple, et du coup les apps XFree86 tourneront sous Xwin aussi vite qu'en natif, et les apps Xwin encore plus vite :-). Le beurre et l'argent du beurre ;-p
[^] # Re: Fork d'XFree86
Posté par Korbinus (site web personnel) . Évalué à 2.
Les distros "majeures" vont fournir en standard l'un ou l'autre, mais pas les deux.
La recherche de la vente de Linux au grand public conduit à une simplification de l'offre.
<troll poilu>
Par exemple, dans sa huitième mouture, RedHat à torpillé le gros KDE au profit de son jumeau, le patapouf Gnome. D'accord, les habitués de KDE peuvent toujours l'installer et s'en servir, mais à quel prix ?
</troll poilu>
[^] # Re: Fork d'XFree86
Posté par matiasf . Évalué à 2.
> Par exemple, dans sa huitième mouture, RedHat à torpillé le gros KDE ...
> </troll poilu>
<troll poilu mode="j'ai pas les couilles de dire que ce que je dis est ce que je pense">
Tiens, encore un utilisateur de RedHat. Je ne sais pas ce qu'ils ont à utiliser une distribe qu'ils n'aiment pas. Puis il faut bien que RedHat laisse aux autres un moyen de se distinguer et de ne pas uniquement copier RedHat avec 6 mois de retard.
<troll poilu>
[^] # Re: Fork d'XFree86
Posté par mammique . Évalué à 6.
[^] # Re: Fork d'XFree86
Posté par ludotux . Évalué à 10.
C'est déjà arrivé. Par exemple egcs/gcc.
Et ce n'est pas "douloureux". Ça rappèle un point fort du logiciel libre. S'il y a un truc qui coince et d'autres peuvent faire mieux, et bien ils peuvent faire mieux :-)
Mais idéalement c'est "regrettable".
Faire un fock de VB : tu peux toujours rèver. Et ça c'est un gros problème !
[^] # Re: Fork d'XFree86
Posté par dinomasque . Évalué à 5.
VB VB VB VB fork
Dans l'antarctique
T'es l'roi des fork
VB VB VB VB fork
....
oula ! mais qu'est-ce qui m'arrive ce matin ;)
BeOS le faisait il y a 20 ans !
# Re: Fork d'XFree86
Posté par Elihu . Évalué à 2.
J'aimerais bien aller vérifier par moi-même mais le site semble inaccessible.
[^] # Re: Fork d'XFree86
Posté par Shld . Évalué à 6.
[^] # Re: Fork d'XFree86
Posté par Jak . Évalué à 6.
Une autre remarque : Xwin, c'est vraiment pas génial, ça me fait penser à Xwin32, un serveur X pour Windows. D'ici à ce que la société éditrice vienne jouer à c'est-moi-qui-ai-la-plus-grosse (... horde d'avocats en droit des marques/propriété industrielle/etc.), 'faudrait penser à faire attention.
Tiens, une idée : Window XP
(oui, oui, [jesors])
[^] # Re: Fork d'XFree86
Posté par Ange Bara . Évalué à 5.
(seconf lien de la news)
le "brainstorming" version j'en ai rien a foutre, j'ai des questions plus importantes sur le gril.
pour ceux qui ont la flemme ou ne causent pas l'anglais : c'est temporaire. l'objectif etait d'avoir une existance et de permettre a d'autres de trouver un nom au projet en offrant des outils pour demarrer.
il ne faut pas aller plus vite que la musique.
[^] # Re: Fork d'XFree86
Posté par Jak . Évalué à 4.
Enfin bref, c'est vrai que c'est pas le plus important. Mais je me méfie de ces boîtes états-uniennes qui cherchent à faire profit de tout et n'importe quoi, et l'éditeur de Xwin32 pourrait facilement venir râler. D'où perte de temps ultérieure, etc.
Tiens, d'ailleurs, Phoenix a été renommé ? Je me rappelle d'un sondage qui demandait quels étaient les pires noms proposés pour le remplacer. C'est «Phallus» qui gagnait, il me semble.
[^] # Re: Fork d'XFree86
Posté par Temsa (site web personnel) . Évalué à 4.
une référence plus proche du vent que de la fenetre ainsi...
[^] # Re: Fork d'XFree86
Posté par Anonyme . Évalué à 10.
pourquoi pas XinX? (je ne sais si ça existe ;) : XinX is not XFree :)
[^] # Re: Fork d'XFree86
Posté par mammique . Évalué à 1.
[^] # renommage Phoenix
Posté par nobotag . Évalué à 6.
mis à part que c'est devenu, dans les prévisions, roadmap pour les intimes, le butineur principal de mozilla à partir de la version 1.5 . dont les principaux élements seront donc minotaur/thunderbird pour les mails
et phoenix/on_sait_pas_mais_firebird_est_un_grand_favori.
comme butineur
Une version 1.4 de mozilla all_in_one sortira au moins la version de ex_phoenix 0.6 aussi. minotaur/thunderbird a sorti ses 1ers binaires.
Pas d'inquiétude pour les developpeurs web - dom inspector et d'autres outils fondamentaux devront etre portés sous forme de phoenix extensions avant toute sortie de la nouvelle UI / philosophie.
gecko, Xul et compagnie sont evidement conservés. ce ne sera pas un grand changement d'architecture, plus pour la philosophie , et beaucoup en terme d'interface utilisateur.
Ouf voilà.
http://www.mozillazine.org(...) vous dira tout ça et le reste.
Pour ne pas poster 2 fois ce que je vais éviter ;)
Je trouve que c'est trés bien - Xfree86 me semble etre un des points de blocage des Unix libres - ce qu l'experience phoenix a montré au sein de mozilla (d'aprés les échos de l'équipe sur mozillazine) c'est que :
mieux vaut une petite équipe cohérente qu'une foule de gens.
Si on veut aller vers l'utilisateur, il vaut mieux faire le tri des "idées" qui ne sont jamais mauvaises (bien sur) mais peuvent se nuire les une aux autres.
J'ai encore 103 XP ça va aller ou vous voulez que je poste plus ?
[^] # Re: renommage Phoenix
Posté par fabien . Évalué à 8.
Pour phoenix, il me semble que lc'est des dev de mozilla, non pas un fork.
pour l'instant, les devellopements de mozilla arrivent chez phoenix quotidienement, c'est juste qu'ils ont supprimés des fonctionalités (et ajouté quelques autre aussi, c'est vrai)
donc ca n'a rien a voir avec la rupture XFree86 et XWin.
-
ce message à été posté avec Phoenix/0.5 Gecko/20030304.
[^] # Re: renommage Phoenix
Posté par nobotag . Évalué à 1.
Par contre pour l'aspect "projet" je serais un peu plus nuancé, et défendrais mon point de vue ainsi que la question posée .
Le projet mozilla et le programe est , trés ouvert chacun peut venir s'y greffer - notament parce qu'il comprend un volet outil/langage XUL je crois, il n'est besoin que d'aller sur mozdev pour s'en rendre.
Le projet phoenix s'est inscrit dans ce cadre.
Mais un de ses buts avoués a été de démontrer que l'ouverture du programme à tous développeurs/bout de code nuisait au programme lui mème ; c'est en tout cas ce que j'ai compris de ce que j'ai lu sur la page, mozdev de la version 0.3.
Aussi l'équipe, issue de mozilla, était restreinte à 4 ou 5 personnes.
Cette idée était originaire du projet mozilla lui mème, mais devait faire ses preuves pour emporter l'accord de la majorité.
Je crois que la nouvelle roadmap montre que ce but a été atteint.
Le fait que le "conflit", les divergences de vue ait été gérée en interne démontre l'intérêt de la variété, de l'ouverture.
[^] # Re: Fork d'XFree86
Posté par Mathieu Pillard (site web personnel) . Évalué à 5.
[^] # Re: Fork d'XFree86
Posté par Spermatozoide . Évalué à 6.
En fait, le nom est temporaire, c'est indiqué dans la news ;)
"le projet s'appelle pour l'instant 'Xwin', la communauté choisira elle-même le nom définitif"
Pour la licence, je n'ai pas trouvé non plus, ils doivent être certainement encore en train d'y réfléchir.
En ce qui concerne ton idée... non, rien :p
[^] # Re: Fork d'XFree86
Posté par doublehp (site web personnel) . Évalué à 4.
[^] # Re: Fork d'XFree86
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Il n'y a donc plus de problème pour le nom de domaine. Remarquez la date d'enregistrement !
[^] # Re: Fork d'XFree86
Posté par Linux_GTI . Évalué à 10.
[^] # Re: Fork d'XFree86
Posté par Rolland Dudemaine . Évalué à 9.
1) quel est l'interet d'un telmecanisme pour XFree86 ou un projet forké comparable ? Le projet est sous licence MIT, qui autorise toute exploitation, commerciale ou non. Rien a voir avec Linux qui est en GPL et pousse a le rester. La philosophie n'est pas la meme, et un mecanisme d'identification des licences serait totalement inutile pour un projet sous licence MIT/BSD.
2) Ca m'etonne qu'ils aient choisi XWin, meme temporairement. En regardant dans le cvs d'XFree86, j'ai vu qu'XWin existe deja : c'est le port officiel de Cygwin/XFree86 apparemment. (voir http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xwin/(...) pour la confirmation). Un tel choix va engendrer un poil de confusion ... ;o(
[^] # Re: Fork d'XFree86
Posté par Linux_GTI . Évalué à 10.
Le même que pour Linux. Ceux qui font des modifications du "coeur" de xwin doivent fournir les sources (Apple qui fournit les sources mais n'est pas obligé, etc...). Par contre, la licence doit être double pour cohabiter avec XFree86 (MIT/BSD et GPL). C'est actuellement pratiqué par Linux. Par exemple Le code sous linux d'un driver est GPL mais il est possible d'utilise ce même code ou un dérivé sous BSD (sans restriction quoi) hors de Linux (pour les composant sous BSD/GPL). Par exemple pour faire un version spécialisé pour solaris. Ce principe est utilisé pour acpi qui est en parti développé par Intel. Ça permet à Intel de fournir les sources à Linux et respecter la GPL. Ça permet aussi à Intel d'utiliser ce travail pour Windows sans que tout Windows soit sous GPL.
Les devs doivent se protéger explicitement d'un fork proprio le "coeur" (qui est un travail fourni par la communauté) avec l'utilisation de EXPORT_SYMBOL_GPL et authoriser les drivers proprios avec EXPORT_SYMBOL comme le fait Linux.
[^] # Re: Fork d'XFree86
Posté par Moby-Dik . Évalué à 2.
[^] # Re: Fork d'XFree86
Posté par Linux_GTI . Évalué à 2.
Pour que du code passe de xmin à xfree86 il faut qu'il soit sous BSD et GPL. GPL sous xwin et BSD sous xfree86. S'il n'est que GPL il ne peut pas passer sous xfree86.
[^] # double licence vs. licences différentes
Posté par Moby-Dik . Évalué à 6.
Quand on parle de double licence, c'est pour un bout de code donné, qui est distribué sous deux licences au choix (pour le même bout de code). Là pas besoin d'une telle construction : le coeur peut être sous GPL et les drivers sous BSD. Il n'y a pas double licence, mais une licence spécifique pour chaque portion du projet (la GPL l'"emportant" au final pour les conditions de distribution du package global).
Un autre exemple pour illustrer cette distinction de terminologie. Linux est sous GPL, la glibc est sous LGPL. Pourtant, on ne dit pas que les distribs Linux, qui incluent à la fois Linux et glibc, sont "sous double licence". Non, elles sont simplement distribuées sous les conditions résultant du plus grand commun dénominateur aux diverses licences utilisées, à savoir ici les conditions de la GPL (qui sont plus restrictives).
[^] # Re: double licence vs. licences différentes
Posté par Linux_GTI . Évalué à 7.
Un source GPL dans xwin GPL (ce qui tombe sous le sens :-)) ne pourra pas être mis dans xfree86. D'où l'intervention de ce que j'appelai abusivement la double licence/copyright.
Par contre, le système EXPORT_SYMBOL_GPL et EXPORT_SYMBOL est nécessaire pour qu'une société Toto diffuse des drivers propriétaires pour un xwin GPL. Car même si les sources sont BSD, c'est la GPL qui prévaut dans un projet GPL. Par contre, Toto ne peut difuser que le driver et non xwin avec le driver. Sinon Toto doit fournir tout les sources. Ce qui normalement empêche un distributeur de GNU/Linux/xwin de distributer ces drivers propriétaires. Mais on voit que certains ne s'en privent pas ...
[^] # Re: Fork d'XFree86
Posté par Rolland Dudemaine . Évalué à 5.
Je tiens a signaler aux integristes du libre que logiciel libre != licence GPL, quoi qu'en dise RMS. C'est juste la definition de liberte qui est differente. Et a qui la liberte s'applique, au code, au developpeur ou a l'utilisateur.
La GPL n'est pas la solution a tout, loin de la. Mais ca, c'est une question de point de vue ;o)
[^] # Re: Fork d'XFree86
Posté par Linux_GTI . Évalué à 10.
Imagine que tout ce qui constitue une distribe GNU/Linux soit sous BSD.
Alors IBM (par exemple) peut diffuser une distribe avec pleins d'extensions bien proprio, une pile tcpip non standard, une libc qui envoye des infos sur ton installation et ça sans fournir les sources, sans que tu puisses contrôler, adapter ton système. Si IBM fait bien son boulot, sa distribe devient un succès. Tout le monde l'utilisent mais on a pas les sources. Bref on se retrouve avec un système bien proprio. La GPL est là pour éviter ce type de dérive. On peut remarquer que les boîtes bien proprios n'aime pas la GPL mais n'hésite pas à piocher dans les produits BSD.
La GPL n'interdit pas un programme propriétaire d'utiliser des programmes GPL (mon programme propriétaire peut utiliser Linux, sed, etc...). La LGPL permet de linker un programme propriétaire. Globalement ce sont de bonnes licences qui défendent l'utilisateur (qui peut auditer les sources, les adapter, etc...) et n'ignorent pas le geste généreux de la part du développeur d'avoir "ouvert" les sources.
Par contre, la GPL est problématique pour les drivers, les extensions. C'est dans ces cas particulier qu'il faut utiliser des systèmes comme EXPORT_SYMBOL et EXPORT_SYMBOL_GPL.
Prends Apple. Il utilise xfree86. Actuellement Appel fournit les sources. Mais Apple n'est pas obligé. Par exemple, Appel pourrait faire une version de xfree86 qui empêche d'affichage des applis qui n'ont pas été développer avec leur version de xfree86 payante.
Avec BSD toute les dérives sont possibles.
[^] # Re: Fork d'XFree86
Posté par Rolland Dudemaine . Évalué à 4.
Mais le probleme n'est pas de connaitre la difference, mais de savoir si la GPL est adaptee a XWin. Les derives possibles que tu signales sont un risque a courir. Mais aller pour ces raisons vers la GPL, c'est reagir de la meme maniere que d'ajouter le DRM a la diffusion des musiques de facon electronique : ca essaye de pallier a une derive possible que des gens mal intentionnés adoptent, sans pour autant resoudre vraiment le probleme, puisque je ne connais pas (malheureusement) de jurisprudence qui ait fait qu'utiliser de facon illegale la GPL soit condamne. Resultat, il y aura surement un moyen de contourner le DRM, comme certaines boites utilisent surement des outils en GPL de facon commerciale.
Personnellement, je verrais d'un bon oeil la conservation de la licence BSD/MIT, pour deux raisons :
- si l'equipe de XWin a pour volonte de garder comme priorite une ouverture d'esprit, alors il faut l'etre au moins autant que XFree86, et permettre sans restriction le backportage de code de XWin vers XFree86, la ou cela est possible. Et ca ca ne peut se faire qu'en conservant une licence compatible, i.e. BSD ou MIT. De ce cote la je fais confiance a KP, il suffit de regarder TinyX/KDrive pour voir qu'il conserve une attitude exemplaire.
- comme precise dans des posts plus haut, si le code est en GPL, il est bloque en GPL. Si le code est BSD, alors il peut etre repris par d'autres. Ca a ses inconvenients, mais aussi ses avantages : Microsoft etant incapables de faire eux-memes leur pile TCP/IP, ils ont repris celle de FreeBSD (ou en tout cas d'un des *BSD). Ca ne fait pas de mal a FreeBSD, et ca ameliore le fonctionnement de Windows. Ca pourrait meme peut-etre avoir amene des gens a *BSD ?
La ou je veux en venir, c'est qu'il faut arreter de contraindre et commencer a eduquer.
<troll politique>c'est en contraignant de toutes parts qu'on arrive a l'integrisme qui nous entoure, cote americain qui craint de ne pas tout controler et de se faire depasser comme cote arabe qui ne controle les populations que par la terreur
[^] # Re: Fork d'XFree86
Posté par Linux_GTI . Évalué à 10.
Pour savoir si BSD ou GPL est plus adapté, il faut connaitre les différences.
> et permettre sans restriction le backportage de code de XWin vers XFree86
> Et ca ca ne peut se faire qu'en conservant une licence compatible, i.e. BSD ou MIT.
Aucun problème. Projet sous GPL source sous BSD. D'ailleur ils seront forcément sous BSD ou alors il faut l'accord de celui qui a le copyright pour changer la licence. Voir un peu plus haut où c'est discuté.
> comme precise dans des posts plus haut, si le code est en GPL, il est bloque en GPL.
Je parle de projet et non de code. Linux a plein de code sous BSD et les *BSD pioche du code de linux comme linux récupère du code *BSD.
> La ou je veux en venir, c'est qu'il faut arreter de contraindre et commencer a eduquer.
Certe. Mais pour que ça marche, on peut rêver. Si Linux était sous BSD, je ne suis vraiment, mais vraiment, pas convaincu qu'IBM, Sun, HP, etc... aurait fait autant de retour à la communauté.
De plus dire que BSD marche pour xfree et donc il ne faut rien changé est un peu léger comme argument. Tu n'as pas connu l'époque ou il y avait des serveurs x11 d'une somme rondelette, basé sur xfree86, et qui apportait rien à la communauté sinon de pouvoir utiliser une carte graphique. Informix est un dérivé de postgres et ça n'a pas aidé postgresql.
Pour moi, si la GPL/LGPL peut-être utilisé, il faut l'utiliser. J'espère que sur ce point on est d'accord. Je ne dis pas que la GPL est +forcément+ mieux que BSD pour xwin. Dans le domaine des noyaux, on a du GPL (linux) et du BSD (*BSD). Linux marche bien. Je ne vais pas conclure que c'est grace à la GPL. Mais il est meilleur pour le logiciel libre d'avoir du (L)GPL que du BSD. Je ne vais pas conclure qu'il faut du 100 % GPL et évité tout proprio. Les mécanismes comme EXPORT_SYMBOL sont là pour gérer avec souplesse un bon compromis ouverture aux proprios et conservation de la disponibilité du code.
Enfin, si xwin passe sous GPL, il y a un choix côté licence. Soit BSD avec xfree86, soit GPL avec xwin. Avoir le choix n'est pas un mal. Si xfree86 est plus utilisé à cause des contributions des sociétés commerciales ou parcequ'il y a des versions proprios basées sur xfree86 qui sont très utilisées, tant mieux pour xfree86. Si c'est xwin, tant mieux pour la communauté car la GPL défend mieux mon "intérêt" contrairement à la BSD ou tout est possible.
Il y a une opportunité pour avoir un serveur x11 sous GPL. Il serait dommage de ne pas la saisir. Surtout que ça ne va pas faire de "mal" à xfree86.
[^] # Re: Fork d'XFree86
Posté par Rolland Dudemaine . Évalué à 0.
Je ne comprends pas bien la difference entre la licence du projet et la licence du source. Je pose la question serieusement.
[^] # Re: Fork d'XFree86
Posté par Linux_GTI . Évalué à 8.
$ head -45 /usr/src/linux/drivers/net/bsd_comp.c
/*
* Update: The Berkeley copyright was changed, and the change
* is retroactive to all "true" BSD software (ie everything
* from UCB as opposed to other peoples code that just carried
* the same license). The new copyright doesn't clash with the
* GPL, so the module-only restriction has been removed..
*/
/* Because this code is derived from the 4.3BSD compress source:
*
* Copyright (c) 1985, 1986 The Regents of the University of California.
* All rights reserved.
*
* This code is derived from software contributed to Berkeley by
* James A. Woods, derived from original work by Spencer Thomas
* and Joseph Orost.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
$
C'est un source sous BSD dans Linux.
Puis regarde /usr/src/linux/COPYING qui est le copyright de Linux (c'est la GPL). Donc le fichier bsd_comp.c est considéré comme GPL sous Linux (car la BSD n'est pas incompatible avec la GPL et la GPL est une BSD avec des exigences supplémentaires) et est considéré BSD sous netBSD. Le licence de netBSD exige des sources sous BSD pour netBSD, mais un source GPL ne peut pas être mis dans un projet BSD (celà va à l'encontre d'exigences de la BSD).
Il y a un petit fil de discussion ici avec d'autres pointeurs qui parle de GPL/proprio EXPORT_SYMBOL_GPL, EXPORT_SYMBOL etc...:
http://linuxfr.org/comments/186264.html(...)
[^] # Re: Fork d'XFree86
Posté par Rolland Dudemaine . Évalué à 1.
Donc selon tes termes, le projet XFree86 est BSD. Et un projet sous GPL avec uniquement du code BSD, ca n'est pas possible d'apres ce que tu m'explique. Donc si KP et la troupe de XWin decide de sortir leurs sources sous licence BSD comme ca l'a ete jusqu'a maintenant, le projet restera sous licence BSD de facon automatique. J'ai bon ?
[^] # Re: Fork d'XFree86
Posté par Linux_GTI . Évalué à 10.
Pourquoi ?
(a) Le projet est GPL, ça veut dire, entre autre, qu'il faut pouvoir accéder aux sources si tu as le binaire.
(b) Le projet est BSD, ça veut dire, entre autre, que tu ne peut exiger d'avoir les sources si tu as le binaire.
Un source BSD dans un projet GPL, permet de respecter la licence du projet. Par exemple pour (a), je peut fournir le source à quelqu'un qui a le binaire.
Un source GPL dans un projet BSD, ne permet pas de respecter la licence du projet. Par exemple pour (b), je ne peut pas refuser de fournir les sources si quelqu'un a le binaire.
xfree86 est sous BSD, je ne suis pas obligé de fournir les sources.
xwin est sous GPL, je suis obligé de fournir les sources. Il faut que la/les licences des sources respectent la licence du projet. La BSD ne dit pas que, si quelqu'un a le binaire on n'a pas le droit de fournir les sources ! Si c'était le cas, la BSD ne serait pas compatible GPL. (ok c'est un exemple stupide).
Je ne vois pas en quoi un source BSD est en confit avec un projet sous GPL. Tous ce que demande un projet GPL peut être respecté avec du code BSD ou du code dans le domaine public par exemple. Par contre un source GPL ne peut être mis dans un projet BSD ou alors j'ai raté un truc. De plus, pour qu'un projet soit GPL, il n'y a pas un quota de code GPL à respecter. Le projet peut être GPL avec 100 % de code sous BSD. Dans ce cas tu peux faire un fork et lancer un projet sous BSD. Par contre un projet sous GPL avec du code sous GPL, tu ne peux faire un fork et passer la licence du projet sous BSD.
Le problème des programmes sous BSD est qu'ils ne peuvent avoir de code sous GPL (mais il peuvent utiliser des librairies sous LGPL). Ça ne veut pas dire que la réciproque est vraie ! Jètes un coup d'oeil au source postgresql et tu verras qu'il n'y a aucun code sous GPL.
Si tu écris un fichier .c, tu es le propriétaire et peut décider de la licence. Par exemple tu vas choisir BSD car tu veux que le source soit utilisé dans un projet proprio ou xfree86 ou xwin...
Tu peux aussi refuser une utilisation "proprio" (c'est très vague) de ton source et dans ce cas tu le met sous GPL. Dans ce cas, ton source ne peut être utilisé que dans un projet (L)GPL.
Lis la licence GPL.
[^] # Re: Fork d'XFree86
Posté par Rolland Dudemaine . Évalué à 0.
Donc si tu veux conserver un maximum d'ouverture a tous les niveaux, tu mets ton source en licence BSD. Si XWin est en GPL, il est ferme a XFree86 puisque le code de XWin ne pourrait etre integré a XFree86.
Donc, pour une compatibilité complète, il faut que le source soit et reste en licence BSD ou MIT. Et pas GPL.
[^] # Re: Fork d'XFree86
Posté par Linux_GTI . Évalué à 7.
Non.
> Si XWin est en GPL, il est ferme a XFree86 puisque le code de XWin ne pourrait etre integré a XFree86.
Non.
C'est le code sous GPL qui ne pourra aller vers xfree86. Or initialement, il n'y aura aucun code sous GPL (xwin ne pouvant modifier le copyright d'un source qu'avec l'accord de l'auteur). Et si ton argument c'est de dire que xwin se ferme à xfree86, pense que xfree86 se ferme à tout les codes GPL. Et il y a plus de code sous GPL que sous BSD dans un système GNU/Linux (avec l'utilisation de librairie, c'est pas très génant)..
> Donc, pour une compatibilité complète, il faut que le source soit et reste en licence BSD ou MIT. Et pas GPL.
Oui. Mais ce n'est pas incompatible avec un projet sous GPL. Et parmis les avantages d'un projet GPL, c'est qu'il peut accèpter du code GPL. Ce qui n'est pas le cas d'un code BSD où le GPL est interdit (cherches du gpl dans xfree86 :-), il n'y en a pas).
Sinon, tu peux m'expliquer comme fait Linux pour avoir du code sous BSD?
Si tu comprends ça, tu comprendras aussi que xwin, le projet, peut être GPL avec des sources sous BSD qu'ils peuvent donner à xfree86.
[^] # Re: Fork d'XFree86
Posté par Rolland Dudemaine . Évalué à -4.
Non.
C'est le code sous GPL qui ne pourra aller vers xfree86.
Relis un peu pour voir...
Mais comme le dit Simon Arnaud plus bas, cette discussion est sterile, puisque nous n'avons de toute facon aucun pouvoir de decision.
[^] # Re: Fork d'XFree86
Posté par ludotux . Évalué à 4.
PS : Passe une heure à lire et comprendre la GPL ça nous fera des thread moins long.
[^] # Re: Fork d'XFree86
Posté par Maz (site web personnel) . Évalué à 10.
De plus tes 2 raisons pour rester sous Mit/BSD me semble fumeuses.
D'abord, je ne vois pas le rapport entre ouverture d'esprit, et respect de l'existant. Ensuite dire que windows qui reprend le code d'un BSD pour sa pile TCP/IP ne leur a fait aucun mal, je trouve que c'est beaucoup s'avancer.
Et je ne comprends pas ta conclusion. Contraindre qui ? à faire quoi ? Eduquer sur quel sujet ?
[^] # Re: Fork d'XFree86
Posté par mammique . Évalué à 2.
[^] # Re: Fork d'XFree86
Posté par pasBill pasGates . Évalué à 0.
Si seulement c'etait vrai...
Le hic etant que notre stack TCP/IP est 100% made in MS
[^] # Re: Fork d'XFree86
Posté par ptit_tux . Évalué à 5.
> Le hic etant que notre stack TCP/IP est 100% made in MS
Quand tu dis "notre stack", tu parles des utilisateurs qui comme toi utilise Windows ?
Parce que tcp/ip, c'est pas ms qui l'a inventé ni codé en premier.
[^] # Re: Fork d'XFree86
Posté par pasBill pasGates . Évalué à 0.
Tu vois ou que je parles de invente ou code en premier ?
[^] # Re: Fork d'XFree86
Posté par ptit_tux . Évalué à 7.
Faut le savoir.
> Tu vois ou que je parles de invente ou code en premier ?
Tu dis : "notre stack TCP/IP est 100% made in MS" . Ça sous entend que la pile tcp/ip utilisée partout (et non seulement MS) a été faite par MS. Je voulais souligner que c'était faut.
Dire "notre stack" sur dlfp pour parlé de la stack MS, c'est pas évident à comprendre.
[^] # Re: Fork d'XFree86
Posté par daggett . Évalué à -1.
Mmmmh, tu es nouveau par ici toi, pour pas savoir que pbpg bosse chez MS ;)
[^] # Re: Fork d'XFree86
Posté par youri_b . Évalué à 0.
[^] # Re: Fork d'XFree86
Posté par ufoot (site web personnel) . Évalué à 10.
[^] # Re: Fork d'XFree86
Posté par Larry Cow . Évalué à 3.
(je déconne... enfin j'espère)
[^] # Re: Fork d'XFree86
Posté par pasBill pasGates . Évalué à 1.
http://support.microsoft.com/default.aspx?kbid=306819(...)
Relnotes.htm etant un des fichiers presents sur le CD.
Pour Win2k il me semble que c'est dans le manuel.
[^] # Re: Fork d'XFree86
Posté par ufoot (site web personnel) . Évalué à 2.
---------8<----------------------------------------------------
$ grep -r "Regents of the University of California" /mnt/windows | grep -v cygwin
Fichier binaire /mnt/windows/windows/ftp.exe concorde
$
---------8<----------------------------------------------------
Le fichier en ligne dont tu me parles ne semble donc pas présent sur ma machine. Et dans /mnt/windows/windows/license.txt on peut certes lire des passages rigolos comme:
---------8<----------------------------------------------------
LES DÉFAILLANCES DE LA TECHNOLOGIE JAVA PEUVENT DIRECTEMENT PROVOQUER LA MORT, DES PRÉJUDICES CORPORELS OU DE GRAVES DOMMAGES MATÉRIELS OU À L'ENVIRONNEMENT
---------8<----------------------------------------------------
mais pas de références à une quelconque licence BSD...
Alors peut-être que c'est marqué dans un coin du manuel - qu'on voit rarement quand comme moi on utilise des postes windows préinstallés à partir de masters concoctés par le service informatique d'une entreprise - mais quelque part je trouve que ça relève de la mauvaise foi la plus caractérisée de ne pas mettre cette information quelque part sur le disque, ou bien dans une aide, que ce soit visible quoi.
On ne devrait pas avoir à jouer au jeu de piste pour trouver ce genre d'infos. Sur mon poste Linux, je n'ai qu'à regarder dans /usr/share/doc/_nom_du_logiciel_/copyright pour connaître la licence d'un logiciel, ça me paraît beaucoup plus honnête et carré, et c'est pas ça qui sature mon disque dur.
Je pense pas que les quelques lignes de la licence BSD auraient fait exploser la taille de l'installeur de win98, qui fait déjà plusieurs (dizaines de) mégas...
[^] # Re: Fork d'XFree86
Posté par pasBill pasGates . Évalué à -2.
La licence BSD on la fout dans le manuel, on va pas la mettre a 434 endroits juste pour te faire plaisir, on l'aurait mise sur le CD que t'aurais rien vu non plus vu que tout ce qui est sur le CD n'est pas installe.
Hint: le relnotes.htm qui est sur le CD de XP n'est pas installe sur le disque.
Bref, tu gueules pour rien, juste pour montrer que t'es pas content. La licence on la respecte.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Fork d'XFree86
Posté par pasBill pasGates . Évalué à -1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Fork d'XFree86
Posté par pasBill pasGates . Évalué à 4.
Si qq'un a envie de mettre son soft sous licence BSD car il se tape eperdument de ce que les gens font de son code c'est une connerie ?
T'es qui pour te permettre de juger de ce qu'il est intelligent ou pas de faire avec son code ?
[^] # Re: Fork d'XFree86
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Fork d'XFree86
Posté par pasBill pasGates . Évalué à -2.
Il suffit de regarder l'architecture de la stack en lisant les ddk et autres pour se rendre compte que les 2 stacks n'ont rien a voir.
[^] # Re: Fork d'XFree86
Posté par Ludovic Gasc . Évalué à 4.
C'est pourquoi je pense qu'il faut utiliser dès que possible la licence GPL.
[^] # Re: Fork d'XFree86
Posté par cornofulgur . Évalué à 5.
Supposition : Parce que tu t'en moques que d'autres gagnent de l'argent ?
Tu contribues au Libre pour l'argent ?
Soyons logique.
S'il faut utiliser dès que possible la GPL, ce n'était pas la peine d'attendre ce fork pour le faire. On pouvait forker bien avant, dans ce but précis. Dans le même genre, forkons apache dès maintenant, avant qu'une société ne se fasse des sous avec.
Keith a donné quatre raisons pour forker, et aucune ne touche aux licences.
Je ne pige pas non plus la logique de Linux_GTI.
D'un coté, il veut la GPL pour écarter apple et ms. De l'autre il veut la GPL pour lui permettre d'intégrer facilement les drivers proprios de type nvidia grace aux SYMBOLS_*. Comprends pas...
[^] # Re: Fork d'XFree86
Posté par Linux_GTI . Évalué à 7.
Parce qu'un driver en proprio dans Linux ne permet pas une "récupération" de linux. C'est totalement différent avec xfree86. Le driver proprio dans linux est dans un cadre bien délimité avec EXPORT_SYMBOL et ne va pas faire passer la vm, etc sous proprio.
Les sources sous GPL/BSD de linux le resterons. Et celà quelque soit la volonté d'une boite commerciale et même si elle ajoute 20 drivers propriétaires.
Par contre avec xfree86, la situation est différente. Une sociétée commerciale peut ajouter un driver, modifier en profondeur le serveur, le rendre incompatible avec les serveur xfree86 existant et sans fournir le moindre code.
De plus, Linux étant sous GPL tu ne peux pas faire une distribution avec des drivers proprio (il n'y a que knoppixfr qui l'a fait et pour moi knoppixfr a fait une connerie). Si tu livres Linux il faut que tous les codes soient disponibles ! Le driver proprio ne peut être qu'un add-on que tu récupères sur le web, un cdrom... Mais le driver proprio ne peut pas être un noyau Linux complet en binaire sans les sources ! Tu ne peux fournir QUE le driver en proprio.
[^] # Re: Fork d'XFree86
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Fork d'XFree86
Posté par Rolland Dudemaine . Évalué à 3.
Je connais aussi une JVM temps-reel impressionnante publiee sous licence BSD (mais je ne me rappelle plus le nom, un truc qui ressemble a waimeaou quelque chose du genre).
[^] # Double licence :
Posté par Quzqo . Évalué à 3.
Imaginons les cas suivants et les conséquences envisageables :
(1) - Projet / code sous double licence, type GPL + BSD
Une société ne pouvant / souhaitant rendre public son code souhaite néanmoins "investir" dans les solutions libres et s'appuyer sur du code GPL/BSD.
D'après ce que j'ai compris plus haut : c'est possible.
(2) - Projet / code sous simple licence, type GPL
Même cas de figure sur du code uniquement GPL.
Dans ce cas, c'est impossible.
Par conséquent, le code libre ne sera pas utilisé mais redéveloppé (+/- bien là n'est pas la question) et le code additionnel spécifique ne sera pas plus rendu public.
Résultat : aucun bénéfice pour la communauté.
< parenthèse >
Rappelons au passage qu'il peut exister "mille" raisons pour qu'une société ne puisse rendre publique le code d'un projet : confidentialité exigée par le client, volonté commerciale, "culture", impératifs du projet ... Que l'on juge cela bien (tm) ou mal (tm), c'est néanmoins une réalité et ce n'est pas le cadre du débat...
< / parenthèse >
Dans le cas (1), certes les "améliorations/extensions" de la-dite société ne profiteront pas à la communauté mais au moins cette société aura intégré dans sa "culture" une certaine utilisation du libre qui pourra, à plus long terme, être étendue à une approche plus communautaire, du moins on peut l'espérer. Quoiqu'il en soit, cette possibilité n'est pas écartée.
Dans le cas (2), l'approche libre/communautaire est à jamais bannie dans la culture de cette société et ne croyons pas qu'une révolution ultérieure puisse y mener. A mon sens, la révolution du libre touche les individus; l'investissement des sociétés dans ce domaine se fait de manière réfléchie <=> calculatrice. La société est donc perdante mais la communauté aussi.
Réflexion faite, à tout choisir je préfère le cas n°1 qui présente l'avantage d'ouvrir cette société hypothétique à une alternative libre et, parrallèlement, d'accroître l'utilisation de logiciels libres donc leur implantation. Dommage que l'esprit critique laisse trop souvent place à la passion dans les débats...
[^] # Re: Double licence :
Posté par Erwan . Évalué à 1.
On deja laisse beaucoup plus de marge de manoeuvre pour la reutilisation du code que dans le cas proprietaire, ou c'est tout simplement impossible.
Une boite qui ne connait rien du libre n'a jamais reutilise un seul bout de code source proprietaire, et pour cause, le source n'est pas disponible et la reutilisation interdite. Ca n'empeche pas l'entreprise en question d'utiliser des softs proprietaires.
Donc une boite peut parfaitement utiliser des logiciels libres et developper des logiciels proprietaires ! Aucun problemes. Mais si elle veut reutiliser du code, la c'est autre chose.
Si quelqu'un veut fournir du code sous licence BSD, libre a lui ! Mais pour ma part, je n'accepterait pas que quelqu'un profite de mon travail (reutilisation de code source) sans reverser le sien a la communaute. Certaines entreprises n'ont pas le choix, et ne peuvent pas diffuser leur code source ? Aucun probleme ! Mais dans ces conditions elles ne doivent pas reutiliser de code libre.
Un cas tres simple:
1. Je sors un tres bon logiciel
2. Une boite sortie de nulle part prends mon soft, rajoute une fonctionalite et le vends sous forme proprietaire !
Je suis nique. Alors je bosse dur pour ajouter des fonctionalites, elle me les pique !
Dans le cas tout-libre, puisque moi aussi je peux piquer les fonctionalites du fork, la boite n'a plus d'avantage concurrentiel si flagrant. C'est donc au contraire moi, developpeur du soft d'origine, qui aie un avantage avec la connaissance du soft.
[^] # Re: Double licence :
Posté par Quzqo . Évalué à 1.
En es-tu si certain ?
Le libre n'a pas inventé la "réutilisation de code" que je sache... Même si cela se fait dans le cadre de logiciels "propriétaires" <=> "code non publique", des ensembles fonctionnels de code peuvent/sont utliser entre différents projets. Il me semble que c'est un lieu commun, je n'invente rien.
Et sans parler de code, dans un souci d'intégration plus vaste, des briques logicielles peuvent être réutilisées "en l'état" d'un projet à l'autre. Cela reste vrai que le projet soit libre ou pas; seul le cadre change...
Mais dans ces conditions elles ne doivent pas reutiliser de code libre.
Soit... mais j'estime que c'est agir comme le logiciel propriétaire sur l'aspect (et seulement sur ce point !) "je crée et je souhaite en conserver le bénéfice exclusif" : à la nuance près que le logiciel propriétaire restraint cette démarche à son petit périmètre alors que le logiciel libre en laisse le bénéfice à toute la communauté libre, le principe reste le même : * tu n'appartiens à ma "communauté", pas touche ! *.
En ce qui me concerne, je trouve cette approche trop réductrice. Si l'on souhaite créé dans un contexte libre :
1. c'est pour le bénéfice de tous (sans exception)
2. ne commettons pas les mêmes erreurs que ceux que nous critiquons.
Un cas tres simple ...
Trop simple ?!
On entend souvent ce type d'argumentaire mais n'est-ce pas un peu trop caricatural et relatif à des actualités déplorables comme les fascinantes prétentions de brevets sur des technos/formats standards (liens hypertextes, GIF...) ou les procès de vols de technologies (Intel/VIA, Microsoft...).
Je ne pense pas que ce soit en interdisant à une société de "culture propriétaire" l'utilisation de ressources "libres" que tu l'inciteras à changer son modèle économique pour devenir un défenseur/contributeur acharné du logiciel libre.
Ne rêvons pas (trop), impossibilité d'intégrer du libre
= on se tourne vers une offre propriétaire
<> on rend son code publique.
Au contraire, la rendre "dépendante" de nos logiciels/ressources me paraît plus souhaitable à long terme.
< Post Scriptum sans aucun rapport >
TROLL = langage de simulation économique inventé dans les années 1970
< / Post Scriptum sans aucun rapport >
[^] # Re: Double licence :
Posté par Rolland Dudemaine . Évalué à 0.
[^] # Re: Double licence :
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
C'est là ou tu te gourres totalement et que tu n'as pas compris grand chose à "l'esprit" de la GPL.
Le mouvement du logiciel libre veut que l'on donne les sources aux utilisateurs pour des raisons "philosophiques" de liberté, d'indépendance, de relations saines.
L'outils utilisé est la GPL car elle force le respect de cette liberté. La *BSD est une vision optimiste de l'humanité qui pense que les sociétés vont rendre la monaie, ce qu'elles font rarement.
Diffuser ses modifications est le prix à payer pour utiliser les miliers d'hommes.ans de travail que représentent certains logiciels libres. Je trouve que c'est un prix bien plus faible que celui des logiciels propriétaires. Pourquoi cela devrait être sans coûts pour ces sociétés ?
Le GPL a été créé pour initier le cercle virtueux : l'utilisation de code GPL entraine la création de code GPL ou son amélioration.
Tu trouves que la GPL n'est pas "assez" libre ? Certe. Limiter la liberté permet aussi de la garantir. Tu n'es pas libre de tuer ton voisin. Non, mais ainsi tu es libre de vivre sans le risque de te faire tuer par ton voisin.
Le code libre a d'autre qualité intrasec qui peut le rendre bien plus interrescant que du code proprio : un codeur aussi bon soit-il s'il n'a pas le temps de finir, fournira du code torché ! Or il n'y a pas de deadline dans le monde libre. Un codeur du libre sait que son code peut être relu par ses pères, il fait bien plus attention que son code soit propre. Par essence, le code se code en série mais peut se debugue en parrallèle. Or les phases de teste ou les revues de code ne se passent qu'avec qq personnes dans le monde du proprio... quand elles existent.
"La première sécurité est la liberté"
[^] # Re: Double licence :
Posté par Quzqo . Évalué à 1.
Merci de me rappeller mon idiotie.... J'espère que tu vas pouvoir éclairer ma lanterne.
pour des raisons "philosophiques" de liberté, d'indépendance, de relations saines.
Ce n'est pas ce point que je conteste, j'essaie juste d'expliquer qu'à mon avis "donner" d'une main ce n'est pas reprendre en partie de l'autre. J'explique, lorsque je donne, je donne et c'est tout. Il n'y a pas de conditions au delà ni de contre-parties. Ou alors je ne qualifie pas cela de don... En outre, la loi du "tout ou rien" n'est pas toujours souhaitable. Soit je donne soit... rien... bof.
N'est-il pas plus profitable de :
- laisser libre accès à condition de... (GPL)
- demander "rémunération" sinon... (non-GPL)
Pourquoi cela devrait être sans coûts pour ces sociétés ?... Tu trouves que la GPL n'est pas "assez" libre ?
Encore une fois ce n'est pas la teneur de mes propos. Je souligne juste que si rendre publique le code d'un projet est inacceptable (quelle qu'en soit la raison, cf http://linuxfr.org/comments/194677.html(...)), la licence GPL étant ce qu'elle est l'utilisation de code GPL entraine la création de code GPL ou son amélioration, à moins d'un système de double licence, je ne vois pas le bénéfice ni pour l'un ni pour l'autre ("éditeur" du code propriétaire comme communauté) : est-ce ce que nous voulons ?
Limiter la liberté permet aussi de la garantir. Tu n'es pas libre de tuer ton voisin. Non, mais ainsi tu es libre de vivre sans le risque de te faire tuer par ton voisin.
Si c'est en réaction à mes propos, désolé, mais là je pense que tu divagues...
Le code libre a d'autre qualité intrasèque...
Soit. En attendant, un projet en entreprise répond souvent à un besoin... limité dans le temps. Idéalement, je souhaiterais comme toi que la réponse à ce besoin puisse être améliorée au fil du temps mais en réalité on se satisfait du produit (dans la limite du raisonnable bien sûr) et on adapte ses méthodes de travail.
De plus, je trouve ta vision vraiment manichéenne :
- libre = code propre,& testé
- proprio = code torché sans test ni revue
Pour résumé, la vraie liberté selon moi c'est l'alternative, pas une et une seule liberté, certes séduisante, mais imposée.
Et le libre n'est pas l'ultime solution parfaite... il y a encore des points à améliorer.
PS: mes pères ne relisent jamais mon code, d'ailleurs je n'en ai qu'un, mes pairs en revanche, cela leur arrive parfois...
[^] # Re: Double licence :
Posté par Erwan . Évalué à 0.
En ce qui me concerne, je trouve cette approche trop réductrice. Si l'on souhaite créé dans un contexte libre :
1. c'est pour le bénéfice de tous (sans exception)
2. ne commettons pas les mêmes erreurs que ceux que nous critiquons.
Mais *tout le monde* peut faire du logiciel libre ! La notion de "communaute" du logiciel libre est un peu une vue de l'esprit.
Par exemple Microsoft a le droit de developper un logiciel libre, ce qui ne l'empecherait pas de continuer a faire du logiciel proprietaire a cote...
Donc le code libre est au benefice de tous, sans exception !
[^] # Re: Double licence :
Posté par Gruik Man . Évalué à -1.
[^] # Re: Fork d'XFree86
Posté par Jak . Évalué à 0.
# Re: Fork d'XFree86
Posté par _alex . Évalué à 10.
MAIS il faut que ca soit des briques interchangable : QT, GTK et tout le toutim doivent tournés indifféremement sur un projet comme sur l'autre (sans avoir de version spécifique de ces lib).
Sinon ca va être le bazarre.
Please : implémenter les fenêtres comme des textures, histoire que ca turbe un peu plus
[^] # Re: Fork d'XFree86
Posté par Larry Cow . Évalué à 6.
[^] # Re: Fork d'XFree86
Posté par Mathieu Pillard (site web personnel) . Évalué à 4.
[^] # Re: Fork d'XFree86
Posté par Jak . Évalué à 10.
On parle d'un fork d'une implémentation de X, pas du protocole.
[^] # Re: Fork d'XFree86
Posté par Fabimaru (site web personnel) . Évalué à 2.
[^] # Re: Fork d'XFree86
Posté par Larry Cow . Évalué à 9.
Mais comme le disait récemment quelqu'un sur un forum, il est plus que temps que certaines "extensions" modernes (comme Xft/fontconfig) remplacent le système "interne" actuel (la gestion des fonts basique de X, pour cet exemple). Quite à mettre en place une couche d'émulation de l'ancien système, ce qui est d'autant plus simple à mettre en place dans une architecture modulaire.
[^] # Re: Fork d'XFree86
Posté par Linux_GTI . Évalué à 10.
c'est un problème de standard. Il est évident que le fork va pas casser l'api existante. De plus, xfree n'est pas la seul implémentation x11 et Qt, Gtk marche sur les autres serveurs x11.
# Re: Fork d'XFree86
Posté par darkshun . Évalué à 10.
http://lwn.net/Articles/27673/(...)
# Et KGI dans tout ça?
Posté par Larry Cow . Évalué à 5.
Ca serait bien que les gens de KGI (framework graphique acceleré bas niveau) se mettent d'accord avec la toute nouvelle équipe de XWin, le résultat déchirerait tout :)
[^] # Re: Et KGI dans tout ça?
Posté par Larry Cow . Évalué à 0.
[^] # Re: Et KGI dans tout ça?
Posté par Moby-Dik . Évalué à 7.
# Re: Fork d'XFree86
Posté par ludotux . Évalué à 10.
Il y a quelques specs de freedesktop qui vont être déplacé vers xwin. Ainsi toutes applications (window manager compris) xwin marcheront "out of the box" sous n'importe quel bureau.
[^] # Re: Fork d'XFree86
Posté par ptit_tux . Évalué à 10.
Maintenant, il faut clairement dire que telle ou telle techno est obsolète. Il faut étendre le protocole X11 (qui date de plusieurs milliers d'année informatique) pour supporter des nouvelles technos sans que ce soit "ugly".
# Quid de Fresco???
Posté par okhin . Évalué à 3.
Paske je me pose la question, ca a l'air de roxoriser grave, mais je me demande si c'est compatible X11 (pas vu sur leur site), ou si on peut faire tourner KDE/Gnome/Wmaker par dessus....
Pour ceux que ca inétresse, ya la Milestone M2 de dispo.
Leur site web: <a href=http://www2.fresco.org/index.html(...)http://www2.fresco.org/index.html(...)
mais j'ai pas trouvé les infos qui me manque....
[^] # Re: Quid de Fresco???
Posté par Jak . Évalué à 2.
C'est écrit là, d'ailleurs : http://www2.fresco.org/introduction.html(...)
«* stand alone: Fresco does neither need X nor any other windowing environment to run. It can run in an X window, but it runs on the framebuffer as well. In fact we hope to be able to replace X some day.»
Après, si QT ou GTK étaient portés sur Freesco, il n'y aurait pas de raison pour qu'ils ne fonctionnent pas, 'faut juste faire le portage (comme il y a un port de GTK sous DirectFB, ou QT sur framebuffer).
[^] # Re: Quid de Fresco???
Posté par okhin . Évalué à 1.
ya des projets de portage en cours???
paske ca m"interesses pas mal en fait comme alternative à Xfree, mais je pense que je m'y connais as encore assez pour me lancer dans l'aventure tout seul...
[^] # Re: Quid de Fresco???
Posté par Jak . Évalué à 1.
[^] # Re: Quid de Fresco???
Posté par okhin . Évalué à 1.
[^] # Re: Quid de Fresco???
Posté par Erwan . Évalué à 1.
Il tourne sous X, sous Windows, sous MacOSX (Aqua). Si Berlin gagne en popularite, il sera porte. Comme wxWindows.
[^] # Re: Quid de Fresco???
Posté par Jak . Évalué à 1.
Mais comme aucun kit de développement n'est disponible pour Freesco, il faut tout écrire, et c'est bien le problème.
[^] # Re: Quid de Fresco???
Posté par okhin . Évalué à 1.
ya des gens (trés) motivés dans le coin????
[^] # Re: Quid de Fresco???
Posté par Raphael Junqueira . Évalué à 1.
En clair il c'est un gros moteur graphique avec un toolkit livrer de base a l'interieur, les APIs reelement utilisables ne fournissant que des primitives de haut nivo (dans ce cas l'API toolkit).
Autre chose, il est tres oriente effets "Eye candy" au niveau architecture (voir les possibilites de mult-channels/rotations en blending) donc tres eloigne du necessaire pour une utilsation desktop decente.
Pour moi la voie a suivre serait celle prise par les mini-serveurs compatible-X utilises dans l'embarque (comme celui de qnx).
[^] # Re: Quid de Fresco???
Posté par Erwan . Évalué à 1.
Gtk windows par contre se fout a cote du toolkit, ce qui le rend bien moins integre au systeme.
# Vous etes sur que c'est le bon moment ?
Posté par Jerome Herman . Évalué à 2.
Je n'ai rien contre un fork de XFree, en fait ca fait meme un moment que j'attendais ca (d'accord je suis carrement aigri par la liste de "gentilles" reponses que j'ai recu de la part de ce projet) mais pas maintenant. Sincerement, le moindre changement dans XFree entrainne des prises de tete pendant des heures (essayez de compiler les drivers Radeon du CVS au nouveau format de module pour voir). Et la on est en train de parler d'une reecriture complete. Donc soit il y a un grand pas en arriere, avec support minimaliste des fonctions 3D, et la c'est jouable mais qui va etre interresse par un nouveau projet qui ne propose que des fonctionnalites en moins (meme si l'architecture est belle). Soit il y a un grand pas en avant, a savoir on impose des normes nouvelles en profitant du fait que l'on ait pas de support a apporter aux anciennes versions, mais a ce moment la combien de projet vont devoir etre reecrit ou du moins etre adapte.
Bien que XFree soit stable d'un point de vue programme, il est plus qu'instable d'un point de vue projet. et je pense sincerement que c'est pas du tout le moment de faire un fork. Pas avant un an, histoire d'attendre que les choses se tassent, et que l'on sache un peu mieux ou l'on va en matiere de carte graphique, d'OpenGL, de noyeau et de threads.
kha
(mes deux cents)
[^] # Re: Vous etes sur que c'est le bon moment ?
Posté par Raphael Junqueira . Évalué à 2.
2. Pour le noyau, les besoins en APIs de Xfree/DRI/AGP* sont assez minimaux: du genre allocations de DMA, communications PCI, ... donc la aussi la question de l'evolution ne se pose meme pas.
3. Pour l'openGL, tout le probleme vient du fait que l'API a tres mal vieillit pas rapport, par exemple, aux evolutions de D3D. Pour gerer ce qu'entrevoit les premiers drafts de l'openGL2.0 il faudra pas mal de modifs mais ca ne sera pas en gardant l'ancien principe de developpement de Xfree86 que ca sera possible.
Il faudrait clairement integrer "le futur Mesa" au coeur de Xfree dans une sorte de "gros pipeline programmable" et coller par dessus des couches d'abstraction/compatibilite X.
Je pense que en pensant bien la chose on doit pouvoir faire ca en chamboulant pas mal l'architecture mais tout en gardant la grand majorite du code (et economiser tout idee utopique de reecriture complete meme partielle).
[^] # Re: Vous etes sur que c'est le bon moment ?
Posté par Jerome Herman . Évalué à 4.
Tout a fait vrai pour les applis (en theorie hein, on va pas parler des exceptions type wine), par contre completement faux pour le hardware, surtout dans si le noyau preemptif devient le standard. La gestion de thread dans une application OpenGL acceleree qui est par exemple multifenetres (donc plusieurs fenetres accelerees), risque de changer pas mal. En fait le probleme n'est pas XFree en lui meme mais plutot les differents drivers. Cote XFree c'est les drivers GLX et DRI qui m'inquietent un peu. Mais d'un autre cote c'est aussi les drivers qui font la force d'XFree. L'initialisation et la relache du mode DRI sont aussi loin d'etre evident, et une fois de plus comme on jongle avec du hardware d'un cote, c'est pas evident de changer.
Pour faire simple si une ancienne application demande a creer des threads ancien format le wrapper fait son office et tout va bien. Par contre si une nouvelle application demande a creer des threads nouveaux formats avec des fonctions qui font appel a un driver ancien format, la je ne sais pas trop ce qui se passe et comme c'est XFree qui fait tampon ...
2. Pour le noyau, les besoins en APIs de Xfree/DRI/AGP* sont assez minimaux: du genre allocations de DMA, communications PCI, ... donc la aussi la question de l'evolution ne se pose meme pas.
Oui si on part du principe que des fonctions de type transparences hard, T&L, shaders, couleur en flottant et j'en passe ne sont pas interressantes ou doivent etre integralement releguees a X. Perso j'aime bien l'idee de pouvoir me servir de la puissance de calcul de ma CG sans pour autant avoir une session XFree ouverte(il y a un paquet de clusters Maya qui partagent mon opinion).
3. Pour l'openGL, tout le probleme vient du fait que l'API a tres mal vieillit pas rapport, par exemple, aux evolutions de D3D. Pour gerer ce qu'entrevoit les premiers drafts de l'openGL2.0 il faudra pas mal de modifs mais ca ne sera pas en gardant l'ancien principe de developpement de Xfree86 que ca sera possible.
Ah non, OpenGL ca veillit super bien. Le seul truc est de savoir pourquoi ca a ete fait au depart. OpenGL a ete pense comme un generateur d'etats, et n'a pas du tout ete oriente temps reel a la base. Dire que OpenGL a du retard sur D3D c'est comme de dire qu'Acrobat writter est encore loin derriere Word. C'est vrai qu'Acrobat writter comme traitement de texte c'est assez leger. Mais c'est pas fait pour ca.
De plus l'architecture extremement souple d'OpenGL lui permet souvent d'etre au contraire plutot en avance sur D3D d'un point d evue global meme si l'ARB a plutot du retard, je suis bien d'accord.
Le seul probleme avec OpenGL 2.0 c'est surtout qu'on ne sait pas ce qui va etre utilise et/ou implemente. Avant la gueulante de Carmac il ne serait venu a l'idee d'aucun fabriquant de CG de faire des couleurs en flottant. De meme la fonction Render to Render (permet de refaire passer une image completement a travers le pipeline) n'a jamais ete utilisee, ou implementee, ca rend justement la mise en place de Mesa comme nerf de la guerre un peu delicate a l'heure actuelle.
C'est vrai que la meilleure facon d'avoir un systeme propre, rapide, modulaire et avec autant de "bonbon pour les yeux" que l'on veut est de passer par OpenGL. Mais en ce moment ca me parait un peu casse-gueule.
Kha
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.