Robert VISEUR a écrit 765 commentaires

Ce n'est pas de faire le fork qui est le plus compliqué, c'est de le faire réussir (= faire basculer le marché ou une partie significatice). Ce que je veux dire avec XFree, c'est que l'on est toujours pas sûr que le marché va se tourner vers des alternatives, alors que cela fait un an que la communauté se plaint du team XFree et appelle des alternatives ou un autre management.

> un des 6 grands languages
Ca depend aussi de l'activité, de la motivation de la communauté. Il faut mieux 20 développeurs CAML motivés que 40 développeurs C++ pas intéressés :-) ! Tu as des programmes en Delphi qui progressent bien (ex. : Filezilla) ; la communauté Python (Zope, etc) n'était sans pas si grande que ça quand Zope a été libéré mais elle était apparemment très active (idem pour toutes sortes d'applications écrites en PHP, PHP n'étant pas si vieux que ça => ta logique aurait voulu que tous les CMS PHP auraient dû être écrits en Perl, car plus ancien & plus connu au départ, par exemple), etc.

> libérer MS-Office n'aurait que peu d'intérets
Exact.
Par contre, l'ouvrir peut avoir de l'intérêt, s'il y a des organisations prêtes à coopérer (déboguage / ajout de fonctions / feedback développeurs test /...). C'est ce qu'ils font d'ailleurs avec des programmes comme le Shared Source (code ouvert d'où coopération / pas libre d'où maintient du modèle économique basé sur les licences).

C'est aussi l'idée du produit-solution. Un exemple : "Je" n'achète pas un ordinateur, puis un système d'exploitation, j'achète une solution de communication et traitement de l'information => stratégie de Macintosh (solidarité du matériel et du logiciel).

Je ne comprends pas bien ta question, donc je vais peut-être répondre à côté.

- Une société commerciale doit toujours être rentable (jusqu'à quel point, c'est aux actionnaires d'en juger).
- Une société commerciale peut se lancer en faisant du soft libre et en se faisant un nom par sa diffusion, qui résulte notamment de sa qualité : les exemples ne manquent pas (JBoss). De là, elle fait son chiffre d'affaires.
- Une boîte peut faire du libre une fois lancée (elle fait déjà du chiffre) pour faire de l'argent (Zope a été libéré bien après la création de l'entreprise) ou pour en économiser (cas d'Objectweb, de l'édition mutualiste, etc).

C'est la stratégie de feu Cobalt.

Mais il y a plein d'autres modèles (voir post plus haut)

Il ne faut pas oublier que le logiciel libre fait tomber les barrières technologiques, mais pas les autres : notoriété de la marquen, accès aux canaux de distribution, proximité avec le client, personnel formé / certifié plus crédible (en gros les barrières commerciales).

Il y a aussi le classique mélange libre / pas libre qui permet de mieux contrôler la diffusion : voir IBM en la matière avec Tivoli ou DB2 (rajout de barrières juridiques et technologiques).

- frok trop puissant : c'est pour ça que la boîte doit libérer un truc suffisamment avancé pour que l'organisation d'un fork soit trop lourde (lenteur pour s'organiser). Il suffit de prendre XFree et de voir le temps qu'il faut pour que le marché se tourne vers des alternatives (et on est même pas sûr que le revirement va se faire).
- multitude de fork : il faut voir si les forks s'organisent. Si l'on prend l'exemple de PHP Nuke, PHP Nuke est resté le plus populaire auprès du public (rôle de la marque à nouveau) et seuls quelques concurrents se sont réellement faits un nom auprès de certaines communautés (PostNuke par exemple). Mais pour PHPNuke, l'impact n'a pas été mortel vu que les forks n'ont pas su, en terle de diffusion, prendre le dessus.
- code source crade : ça fera surtout fuir les contributeurs :-) !

Les modèles d'affaires sont présentés dans un de mes diaporamas présenté ici : http://www.logiciellibre.net/2003/news20031017.php(...) .

- pénétrataion rapide : généralement combiné à une stratégie de marque forte style Zope ou JBoss. La diffusion du logiciel conduit à la diffusion de la marque et développe la notoriété, permet de développer les activités de consultance. Pour MySQL, c'est un peut différent, puisqu'ils vivent à 50% de la vente de licences propriétaires de MySQL (même genre de modèle que TrollTech).
- pas métier : ce sont les stratégie type Objectweb ou SPIP. Bull vend du service, Le monde diplomatique, de l'info, pas des CMS.
- dynamitage de la concurrence : pratique de la terre brulée pour affaiblir un concurrent et l'attaquer sur autre marché (ex. : Star / Open Office attaque MS Office et Sun peut attaquer sur .Net avec J2EE).
- autres arguments : voir mon diapo

- cas néfastes (point de vue de l'entreprise) : oui.
. si pas de modèle économique viable (par exemple, si faible composante service).
. si problème de mise en oeuvre : code libre mais bordélique d'où peu de contributions (ex. : Mozilla en 1998), transition édition vers services mal gérée (effondrement des revenus), etc.

Globalement, si le produit en tant que tel fournit un avantage concurrentiel important à la société, elle a rarement un intérêt économique à libérer le code source.

Haute disponibilité : http://linux-ha.org/(...)
Mail : Postfix, Qmail ou Sedmain
Webmail : Squiredmail (pas sur de l'orthographe)
Virus : Amavis sur serveur mail
Gestion (partielle) : Webmin

Aïe aïe aïe /o\, tu as raisons, j'avais loupé la parenthèse, avec les : juste avant...

le support USB), est tout à fait fonctionnelle => fonctionnel.

Il s'agit d'un double fork. PHPNuke a forké en Xoops et Xoops a forké en e-Xoops. Je n'ai jamais pu vraiment comprendre quel était la distinction (technique, philosophique, etc) entre e-Xoops et Xoops (réécriture quasi complète de PHPNuke en orienté objet), qui semble plus répandu. Donc, je te conseillerais de jeter un oeuil sur Xoops (plus répandu, donc logiquement meilleure pérennité, plus de support, plus de modules supplémentaires, etc : à vérifier cependant) avant de passer à e-Xoops.

Je n'ai pas fait de comparaison, donc je ne sais pas te répondre avec précision. Maintenant, comment je vois ça :
- Dans une distribution style Mandrake, tu as une installation "à la Windows" où tu choisis les ensembles de logiciels que tu veux ou ne veux pas installer.
- Dans le système de Progeny, tu as une granularité beaucoup plus petite ( http://www.progeny.com/products/components.html(...) ). Tu peux donc, de manière semble-t-il conviviale, paramétrer par exemple ce que tu veux ou ne veux pas dans le noyau Linux pour la distribution que tu te construit. Par rapport à LFS, je dirais (de nouveau, je me base sur la présentation que Progeny en fait, je n'ai trouvé aucune comparaison technique) que LFS est une démarche beaucoup plus "brute", moins conviviale, où l'on peut si l'on s'y connaît tout maîtriser, mais sans une vision granulaire fine (dans le système de Progeny, il y a semble-t-il une découpe préalable qui existe) permettant une certaine abstraction par rapport aux fondations du système.

Je vais tenter une interprétation.

Ian Murdoch, patron de Progeny, estime que GNU/Linux est avant tout un processus et pas un produit. Conséquence de cette opinion, il est idiot de vouloir en faire une distribution monolithique comme le font Red Hat, SuSE ou tout autre distributeur. Surtout, ces distributions monolithiques ne tirent pas pleinement avantage de GNU/Linux.

L'idée est donc, pour chaque client, de donner la possibilité de se construire une solution à la carte. Cette possibilité d'adaptation sur mesure est ici facilitée par ce qu'il appelle le 'componentized linux'.

C'est pour ça que je demandais plus haut s'il y avait eu des mesures de performances, pour pouvoir évaluer le comportement des nouveaux BeOS libres, les comparer, et les comparer au BeOS d'origine. C'est d'autant plus interpelant que le coeur du système n'est plus celui du BeOS d'origine. A ce niveau, ça vaudrait la peine de comparer les versions basées sur Linux et celle basée sur NewOS, qui selon un autre post a été développé par un ingénieur de Be Inc. (donc, peut-être plus proche techniquement du Be d'origine).

Gnome est un environnement utilisateur ; BlueEyedOS est un système d'exploitation. Comparer BlueEyedOS à Gnome, c'est comme comparer GNU/Linux à KDE ou à Gnome.

J'aurais dit pour des raisons de performances, mais une rapide recherche semble montrer que ça se discute : 2300 applications ont été portées sur FreeBSD et sont utilisables gracieusement. Il faut y ajouter toutes les applications SCO Unix, BSDI et Linux qui tournent sous FreeBSD en émulation. Ajoutons que les applications Linux sont quelquefois plus performantes dans l'environnement FreeBSD.
Source (assez enthousiaste :-) : http://www.netline.be/presse/inside_internet/freebsd/Freebsd.htm(...)

Et il y a un argumentaire plus général ici : http://www.chez.com/bthery/beos.html(...) et ici : http://www.multios.com/compos/beos.php3(...) .

Initialement, il était optimisé pour le multimédia et avait un multi-tâche très efficace.

BlueEyedOS is a BeOS-inspired operating system powered by a Linux kernel.
The BlueEyedOS APIs are BeOS APIs rewritten with some improvements. The main goal is to create a new platform for BeOS developers. All you need is to recompile your BeOS apps. Linux developers will be able to find here a complete set of functionalities developed for consistency.

Donc, en dessous, c'est le noyau Linux ; au dessus, c'est une API BeOS-like. Bref, ça s'interface comme BeOS, mais ce n'est plus vraiment BeOS.

Je me posais une question technique à propos des multiples nouvelles versions libres de BeOS. Le choix du noyau est à chaque fois différent : BeFree (basé sur le noyau Linux), BlueEyedOS (basé sur le noyau Linux), Cosmoe (basé sur le noyau Linux) et OpenBeOS (basé sur le noyau NewOS), etc. J'avais lu qu'un des intérêts de BeOS était sa capacité à faire du multimédia et son implémentation du multitâche. La réutilisation d'un noyau tout fait comme Linux (très bon, là n'est pas la question) ou NewOS ne diminue-t-il pas fortement l'intérêt technique de ces nouvelles implementations de BeOS (puisque, à la base, la techno utilisée est la même que GNU/Linux par exemple) ? Et a-t-on une idée des performances comparées des différentes implémentations ?

D'ailleurs, sur Yahoo, on peut lire : on assure que les premiers essais seront possibles dès le prochain Salon de l'Automobile de Genève, en mars 2003. Etes-vous aussi impatients que nous de les découvrir ?
A ma connaissance (on est en mars 2004), on ne l'a toujours pas vu rouler pour un usage quotidien.

Je doute que comprimer de l'air à une pression suffisante à domicile soit économiquement rentable et respecte les normes minimales de sécurité (explosion de la bombone). Qu'on puisse les produire localement de manière mutualisée, ok, mais chacun chez soi, j'ai un doute.

> une cabale des pétroliers ?

Un peu mais pas uniquement. C'est un véhicule de niche, les gens ne se rueront pas dessus et ça ne menace pas les grandes marques. Par contre, Guy Nègre a visiblement multiplié les effets d'annonce et ça l'a un peu déforcé.

> centraliser la production

C'est un avantage. Mais il faut quand même calculer le bilan énergétique global. Je me souviens d'un calcul de Sciences et Vie qui attribuait au diesel un rendement de 28% et à un véhicule électrique, un rendement de 17%, à cause de la longueur de la chaîne de transport et des pertes successives (centrale à 33%, ligne électrique à 95%, batterie, moteur à 95%).

> totalement hors de prix

Toyota, qui est champion des véhicules écologiques (chez eux, ça marche, c'est déjà commercialisé et c'est déjà rentable : voir la Prius), a prévu de commercialiser un véhicule à hydrogène vers 2010. Ce sera sans doute cher mais pas hors de prix (voir la Prius, qui est chère mais pas hors de prix et qui, au niveau blocs moteur, a 10 ans d'avance sur les principaux concurrents).

> Avec le moteur a air on est davantage sur un moteur traditionnel

Ce n'est pas un avantage propre à l'air comprimé.

Tu as des BMW avec des moteurs à combustion interne dérivés des moteurs essences de série qui fonctionnent correctement à l'hydrogène (notamment des vieilles Série 7 à moteur V8, de mémoire).

L'hydrogène peut être utilisé de deux manières : dans des piles à combustible (et là c'est une technologie électrique) ou dans un moteur à combustion interne (et là tu retombes sur une technologie proche de l'actuelle.