Sommaire
- Principe de base numéro 1: rendre facile pour les tiers de supporter notre OS
- Principe de base numéro 2: offrir aux tiers un environnement stable à long terme
- Concrètement ce qu'il faut changer par rapport aux OS libres actuels
- Grand public, mais quel grand public?
- Noyau: Linux ou pas Linux?
Non, non, ça n'est pas une annonce de nouveau projet. Juste une réflexion à voix haute sur les choix techniques qu'on pourrait faire.
Depuis bientôt vingt ans, la façon standard de lancer un nouvel OS de bureau libre, c'est de faire une distribution GNU/Linux. Les avantages en sont connus; les inconvénients aussi, et après 20 ans de tentatives infructueuses de conquérir plus de 1% du marché, il est temps de remettre en cause cette approche.
D'ailleurs il y a déjà d'autres approches. Il y a d'autres UNIX libres, notamment les BSDs. Ceux-ci partagent quand même beaucoup des caractéristiques des GNU/Linux. Puis il y a d'autres variantes plus différentes, comme Haiku. Mais aucune n'a conquis de parts de marché importantes sur le bureau. Et pour un vieux cynique comme moi, les parts de marché, c'est important. Après tout, on ne peut pas apporter de progrès sur le marché avec un produit que presque personne n'utilise.
Voici donc un tour d'horizon des différents paramètres qu'on peut choisir le jour où on se décide à lancer un nouvel OS de bureau libre.
Principe de base numéro 1: rendre facile pour les tiers de supporter notre OS
Si on veut avoir une chance de réussir là où des gens très intelligents échouent depuis 20 ans, il faut avoir une approche radicalement différente. Ça ne peut pas faire de mal non plus d'apprendre les leçons de l'histoire de ces 20 dernières années.
Période bien entendu dominée par Windows. Qu'est-ce qui fait que ce système d'exploitation, par bien des aspects techniquement inférieur à la concurrence, domine le marché depuis si longtemps?
Dans la plupart des domaines, en excluant quelques domaines bien spécifiques comme le jeu vidéo où Microsoft a eu une vraie volonté de mener la danse (DirectX), Windows n'offre qu'une base, qui ne fait pas grand-chose de très intéressant ni de très moderne. Aux tiers d'offrir des fonctionnalités pointues. Les tiers, ce sont les éditeurs de logiciels tiers, et les fabricants de matériel et donc de pilotes de périphériques.
Microsoft a compris qu'en offrant un OS a minima ils permettaient au reste de l'industrie d'offrir le reste, et qu'ainsi la plateforme Microsoft deviendrait la base d'un immense écosystème.
Quelles leçons concrètes en tirer pour un futur OS libre? J'y viens juste après le point suivant.
Principe de base numéro 2: offrir aux tiers un environnement stable à long terme
Ici, à nouveau, par tiers je veux dire les fabricants de matériels et de logiciels tiers.
Les distributions GNU/Linux offrent typiquement une nouvelle version tous les 6 mois. Dans le cas d'Ubuntu, l'édition Long Term Support a un rythme plus lent, tous les 2 ans. À chaque fois, les paquets binaires sont à refaire.
Windows offre un nouvelle version théoriquement tous les 3 à 5 ans, et préserve la compatibilité binaire d'une version à une autre. Les applications binaires continuent de tourner sans broncher, et les fabricants de périphériques n'ont que rarement à écrire de nouveaux pilotes binaires.
C'est ça qui fait que les utilisateurs Windows peuvent aller dans un magasin d'informatique et acheter un périphérique et le faire marcher simplement en insérant un CD. Alors que l'utilisateur de Linux va dans le meilleur des cas devoir mettre à jour tout son OS car le pilote pour ce nouveau périphérique ne sera disponible que dans une nouvelle version de son noyau. Remplacer manuellement un noyau n'est pas à la portée de l'utilisateur moyen, sans compter qu'en le faisant on perd le bénéfice du travail d'assurance qualité fait par sa distribution.
Concrètement ce qu'il faut changer par rapport aux OS libres actuels
Abandonner les systèmes de dépendances profondes inter-paquets
L'idée que les applications se reposent sur de nombreuses dépendances, plutôt que d'avoir leurs propres copies de diverses bibliothèques (et pas seulement de quelques bibliothèques de base, comme sous les OS propeiétaires), est un des principes les plus fondamentaux de la plupart des OS libres. C'est une idée élégante: on gagne énormément d'espace disque, un peu en utilisation de la mémoire, et il devient plus facile de distribuer des correctifs pour les bibliothèques partagées. Pourtant cette idée n'est utilisée dans aucun OS qui ait jamais eu un réel succès auprès du grand public. C'est parce que cette approche est très hostile aux développeurs tiers. Dans cette approche, ils doivent soit accepter l'approche des dépendances, et donc devoir refaire leur paques très souvent et pour chaque distribution, soit faire une grosse liasse (ma traduction de bundle) qui va forcément mal s'intégrer dans un OS qui s'attend à une intégration plus profonde de la part des applications.
Voici donc ma première proposition concrète: pour avoir du succès il faut renoncer à la façon «libriste» de distribuer des logiciels avec des dépendances profondes, ce qui veut dire qu'en dehors de quelques bibliothèques système, chaque application va avoir sa propre copie des bibliothèques qu'elle utilise.
En guise de consolation, on peut se dire que c'est un changement qui permet d'améliorer immensément les temps de démarrage des applications. Charger un seul gros binaire est bien, bien plus rapide que de charger récursivement toute une panoplie de bibliothèques séparées. Comparer le temps de démarrage de Firefox version binaires officiels de Mozilla, à une application de taille comparable utilisant le système des dépendences (charger une grosse application KDE sans être déjà dans KDE).
Garantir la comparibilité binaire à long terme
Dans la section précédente on a vu que les applications ne devraient se reposer que sur quelques bibliothèques système et distribuer le reste elles-mêmes. Ces bibliothèques système doivent offrir une compatibilité binaire à long terme. Par long terme, on veut dire à vraiment très long terme. Si jamais une nouvelle version doit casser la compatibilité binaire, alors il faut continuer de distribuer l'ancienne version avec la nouvelle. Les applications doivent alors être en mesure d'utiliser les 2 en même temps pour pouvoir se porter tout doucement. Ne pas retirer l'ancienne version tant qu'elle a encore des utilisateurs. Ça peut prendre 15 ans s'il le faut. Penser à OpenGL qui permet toujours aux applications OpenGL 1 de tourner. Sous Windows, les SDKs incluent toujours une copie de chaque version antérieure. C'est pour ça que la taille sur disque de Windows est si énorme, mais ça vaut le coup.
Compatibilité binaire aussi pour les pilotes de périphériques
Il devrait aller sans dire que cette compatibilité binaire est aussi vitale pour les pilotes de périphériques que pour les autres logiciels. Sauf que dans la communauté du noyau Linux, on méprise généralement les demandes allant dans cette direction. Je pense que ce qui se passe est que Linux a du succès dans des domaines (serveurs, HPC, embarqué) où la compatibilité binaire pour les pilotes n'est pas trop importante, ce qui pousse les développeurs du noyau à croire, à tort, qu'il en va de même sur le marché du PC grand public.
Or, encore une fois, le grand public veut pouvoir n'installer un OS qu'une fois tous les 5 à 10 ans, et pouvoir à tout moment aller dans un magasin, acheter un périphérique et le faire marcher facilement, aussi facilement que pour l'installation de n'importe quel logiciel: en quelques clics. Ça n'est pas envisageable sans compatibilité binaire des pilotes.
Grand public, mais quel grand public?
Une question importante à se poser est quel «grand public» exactement on vise, avec un OS libre.
La grande tendance de ces dernières années dans les OS libres a été la simplification, visant un public véritablement non-spécialiste, au risque d'aliéner les utilisateurs existants: Unity, GNOME 3, KDE 4. Cette approche n'a pas suffi à gagner beaucoup de parts de marché, mais elle a déplu à de nombreux utilisateurs expérimentés qui se servaient d'OS libres sur leurs stations de travail.
Le segment des stations de travail est très mal servi. Ni Apple ni Microsoft n'offrent un produit vraiment adapté. C'est aussi probablement le seul segment du marché des OS de bureau où les OS libres ont déjà un certain succès.
Vous voyez où je veux en venir: la bonne stratégie pour gagner des parts de marché pour un OS libre, c'est de commencer par le segment des stations de travail et de progressivement s'étendre vers des utilisateurs de moins en moins techniques, sans compromis sur le secteur de la station de travail.
D'ailleurs, la station de travail va peut-être faire un grand retour en grâce dans les prochaines années, alors que l'informatique gagne en importance dans beaucoup de domaines professionnels.
Noyau: Linux ou pas Linux?
Se pose aussi la question du choix du noyau. Si on est d'accord sur l'idée de se concentrer d'abord sur les stations de travail, alors le choix du noyau devient particulièrement important. Par exemple, je compile Firefox 10 fois par jour et j'apprécie le fait que ça va nettement plus vite sous Linux que sous les OS propriétaires, et il ne fait pas de doute que c'est dû aux fonctionnalités du noyau (par exemple: système de fichiers rapide, fork() rapide, ordonnanceurs adaptés à cette charge, etc).
Techniquement Linux est le choix par défaut, puisqu'il est déjà le plus populaire des noyaux libres, et probablement de loin le plus avancé. D'un autre côté, on a vu ci-dessus qu'un impératif est la présence d'une interface binaire stable pour les pilotes de périphériques, ce qui est un tabou parmi les développeurs de Linux. Donc si Linux est retenu comme le noyau d'un OS libre de bureau, et que cet OS veut avoir du succès, il va falloir surmonter des désaccords importants avec la communauté des développeurs de Linux.
Je ne veux pas conclure ce paragraphe dans un sens ni dans l'autre, parce que je ne sais vraiment pas qu'en penser.
D'ailleurs je vais m'arrêter ici, je suis un peu à court d'idées. À vos commentaires!
# "Si on commençait un nouvel OS libre de bureau aujourd'hui..."
Posté par damien . Évalué à -4.
Google à déjà commencé avec Chrome OS :)
# Je n'en veux pas d'un tel système
Posté par Renault (site web personnel) . Évalué à 10.
Ta critique est typiquement une volonté de transformer les systèmes libres en une copie gratuite de Windows.
Oui la copie des bibliothèques par les applications facilite la tâche, mais elle prend beaucoup de place sur le disque (et réduit les performances), et pire, ça aggrave considérablement la sécurité globale du système. Et comme sous Windows tu dois faire les mises à jour manuellement pour la plupart des logiciels tiers et qu'une bonne partie des utilisateurs ne le font pas, tu as du coup un terrain favorable à l'exploitation de failles…
Je n'ai rien contre le fait que GNU/Linux ou autre système libre ait 100% du marché informatique, mais ce n'est pas mon but premier. Mieux, j'aimerais que si cela arrive, c'est grâce à son élégance et ses qualités intrinsèques, pas en puisant dans les astuces de mauvaises conceptions de Windows (qui a ses avantages mais ses défauts).
[^] # Re: Je n'en veux pas d'un tel système
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 10.
Je suis complètement d'accord, d'autant plus que tous les os ont tendance à copier les linux/bsd, le système de market qu'on retrouve partout c'est quand même juste une mauvaise copie du système de paquets
[^] # Re: Je n'en veux pas d'un tel système
Posté par reno . Évalué à 1.
Je ne suis pas d'accord: vouloir reproduire les avantages de Windows ne veut pas forcément dire copier Windows a l'identique.
Par exemple on peut envisager de "sandboxer" les applications pour réduire le problème de sécurité que tu mentionnes.
Ensuite pour ta critique sur la mise à jour des logiciels, note bien qu'avec les AppStore la mise à jour des systèmes devient "globale".
J'ai mis globale entre guillemets car avoir un point unique de mise à jour de l'OS et des applications n'implique pas que les applications soient mis à jour, donc dans ce modèle là il faut quand même pouvoir isoler les applications non-fiable.
[^] # Re: Je n'en veux pas d'un tel système
Posté par Philippe M (site web personnel) . Évalué à 2.
chroot n'est pas dans le principe des sandboxs ? Comment ça il existe depuis longtemps… Bon certe c'est pas ce qu'il y a de plus simple à mettre en place mais le principe est là.
Born to Kill EndUser !
[^] # Re: Je n'en veux pas d'un tel système
Posté par reno . Évalué à 3.
Non, chroot n'est pas une sandbox, ça ne fournit pas de sécurité.
[^] # Re: Je n'en veux pas d'un tel système
Posté par madhatter (site web personnel) . Évalué à 3.
Et c'est très simple à mettre en place.
LXC se rapproche plus des sandboxes, mais c'est un peu plus complexe à mettre en place qu'un chroot.
There is no spoon...
[^] # Re: Je n'en veux pas d'un tel système
Posté par Maclag . Évalué à 7.
Bof! Pour les copies gratuites de Windows, y'a déjà ReactOS.
Pour le reste, j'ai l'impression de ne voir que des voeux pieux:
-facile pour les tiers:
Parce que dans les systèmes actuels, tous les 2 ou 3ans, des gens se réunissent en disant "bon les gars, comment on pourrait rendre la doc encore plus obscure?"
-compatibilité binaire à long terme
Tous les mois, Torvalds pète un câble et demande si on peut pas casser toutes les API, juste pour le fun.
Sinon, vous croyez qu'on aurait tous dû adopter la solution en vigueur sous Win 3.11? Parce que ça, ça aurait eu de la gueule en terme de stabilité dans le temps (pas dans l'uptime, par contre…).
Il y a des raisons pour lesquelles ça casse parfois, et c'est jamais pour faire chier les gens!
Sinon, pour "l'environnement" stable à long terme genre Ubuntu LTS c'est 2 ans contre 3 à 5 pour Windows, c'est un peu bidon comme argument:
Avant de parler de support dans le temps, il faut résoudre le problème du support sur N distros. Pour ça, on peut toujours opter pour le LSB ou faire des gros binaires liés en statiques. D'ailleurs ça se fait déjà et je ne vois pas ce qu'il faudrait changer là-dedans.
[^] # Re: Je n'en veux pas d'un tel système
Posté par claudex . Évalué à 10.
Tu parles des API internes du noyau, pour les API externe, la compatibilité à long terme est assurée. D'ailleurs Linus pète un câble quand on veut péter la compatibilité externe.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Je n'en veux pas d'un tel système
Posté par Marotte ⛧ . Évalué à 7.
Ubuntu LTS c'est cinq ans et deux ans pour toutes les autres versions. Je concède que Windows XP l'explose sur ce plan avec plus de dix ans mais faut pas raconter n'importe quoi non plus ;)
[^] # Re: Je n'en veux pas d'un tel système
Posté par barmic . Évalué à 6.
Ça n'a rien avoir. Tu peut très bien avoir des logiciels compilés en statique dans les dépôt des distributions et donc mis à jour comme ça l'est actuellement sous Linux et BSD.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Je n'en veux pas d'un tel système
Posté par Firwen (site web personnel) . Évalué à 1.
Et comme ça, à chaque mise à jour de sécu d'openSSL, tu as 300 mise à jour triggered car tous les paquets compilés en statiques doivent être mise à jour. J'aime la compilation statique ( ou pas )
[^] # Re: Je n'en veux pas d'un tel système
Posté par barmic . Évalué à 3.
Je n'ai pas dis que c'était bien ou mal, j'ai juste dis que dire que la compilation statique empêche d'avoir des mises à jour globales est faux. Tu pourrait très bien maintenir les sources des paquets et faire des mises à jours des paquets par mise à jour des sources et compilation statique de l'ensemble ce qui diminue la taille de ton téléchargement mais tu prend 300 créations de paquets dans les gencives.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Je n'en veux pas d'un tel système
Posté par pasBill pasGates . Évalué à -1.
En fait tu te contredis la.
Parce que bien que techniquement faisable, cette solution est en fait en realite infaisable pour les raisons que tu cites (nombre de paquets modifies a telecharger/recompiler)
[^] # Re: Je n'en veux pas d'un tel système
Posté par reno . Évalué à 3.
C'est pour ça qu'en général on propose qu'il y ait un ensemble de librairie "socle" fournie avec l'OS à utiliser dynamiquement, les autres librairies étant elle compilées statiquement avec le logiciel.
# Liaison statique
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Pour l'idée d'éviter les grandes dépendances, c'est gentil mais il est déjà possible de compiler ses logiciels en liant tout en statique, et de distribuer ainsi un gros blob incluant tout. C'est ce qui se fait pour par mal a logiciels distribués hors distribution, par exemple les logiciels de Mozilla, et pas mal de jeux vidéos propriétaires.
[^] # Re: Liaison statique
Posté par Bob Volant . Évalué à 3.
On comprend facilement l'intérêt d'une liaison statique des exécutables mais à ce que je sache
1. cela a un impact sur l'occupation mémoire
2. cela pose des soucis en cas de faille découverte dans une librairie (par exemple, glibc)
En cherchant un peu :
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Developer_Guide/lib.compatibility.static.html
[^] # Re: Liaison statique
Posté par pasBill pasGates . Évalué à 4.
C'est une solution absolument horrible, bien pire que livrer des copies supplementaires de librairies (qui deja en soit n'est pas top)
[^] # Re: Liaison statique / Android
Posté par ®om (site web personnel) . Évalué à 3. Dernière modification le 11 novembre 2012 à 08:53.
Pour info, c'est un peu ce qui se fait pour Android en Java.
Alors bien sûr, ce n'est pas de la liaison statique, mais si deux applications utilisent la même bibliothèque Java (un .jar placé dans /libs dans les sources du projet, ou un "project library"), alors chacun des APK généré contiendra le contenu de la bibliothèque. Il n'y a pas, comme en Java pur, un classpath qui permettrait naturellement d'utiliser des bibliothèques partagées à l'exécution.
Si je développe plusieurs applications et que je souhaite avoir du code ou des ressources (icônes par exemple) en commun, tout ce qui est commun sera dupliqué dans chacun des APK.
En bidouillant bien (sans doute en écrivant son propre ClassLoader), ça ne doit pas être impossible, mais ce n'est pas fait pour.
blog.rom1v.com
[^] # Re: Liaison statique / Android
Posté par Firwen (site web personnel) . Évalué à 2.
C'est que fait Windows, c'est ce que font la majorité des installs .dmg sous OS X, etc… C'est pas pour autant que c'est propre….
[^] # Re: Liaison statique
Posté par pepp . Évalué à 0.
Mise à part les problèmes de licences, effectivement c'est possible.
Pour l'exemple des "jeux vidéos propriétaires", s'ils utilisent la SDL (licence LGPG) je vois mal comment ils pourraient faire un gros binaire statique…
Par contre, une solution à base de bibliothèques dynamiques + rpath fonctionne.
C'est ce que fait LGP : http://blog.linuxgamepublishing.com/2009/02/08/our-new-way-to-meet-the-lgpl/
# Succès
Posté par JGO . Évalué à 10. Dernière modification le 10 novembre 2012 à 23:13.
Je comprends l'intérêt technique éventuel, mais je ne vois pas en quoi les développeurs tiers se trouvent lésés par la situation actuelle. C'est déjà possible de dupliquer le code des bibliothèques libres et certains projets le font. C'est juste considéré comme inélégant, mais si c'est juste ça le problème, le développeur peut l'ignorer.
Ensuite, je ne pense pas que le succès soit lié à un problème technique de cette nature. Si le succès était basé sur les mérites techniques, Windows n'aurait pas survécu à l'an 2000.
Si tu parles de « succès », c'est du marketing de masse qu'il est question. Et là le « problème » marketing de linux c'est surtout sa diversité. Le problème est résolu lorsqu'une distribution arrive nettement devant les autres pour les produits grand public, et c'est ce que Canonical cherche à faire. Étant donné le cycle de vie des appareils mobiles actuels (pas de mise à jour majeure de l'OS dans les 2 ans de vie utile) ainsi que le circuit actuel de distribution des logiciels (via le dépôt du fournisseur), le problème des dépendances qui changent après 2 ans n'est plus un frein.
Le problème n'est pas que pour les dépendances. Bruce Schneider (je crois) a une illustration dans un livre avec le compte des appels systèmes, le noyau de Windows maintient des milliers d'appels obsolètes, et autant de surface d'attaque. Si tu ajoutes cela aux bugs non corrigés dans les bibliothèques dupliquées (les patchs sont pas forcément backportés), tu auras un OS aussi peu sûr que certains concurrents payants de linux.
Cela dit je suis d'accord sur le diagnostic, linux a clairement un problème de compatibilité binaire à long terme. Pour les vieux projets non maintenus, c'est plus facile de télécharger la version .exe et de la lancer dans wine, que d'essayer d'utiliser le code qui ne compile plus, à cause de dépendances ou d'autre chose.
[^] # Re: Succès
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
C'est aussi ce que font les logiciels propriétaires, par exemple avec Matlab, Ansys… tu installes une version de java, une version de tcl… qui vient avec le logiciel.
Il suffit de mettre tout cela sous /opt et de régler quelques variables d'environnement avant de lancer les exécutables.
Bref, des choses simples, robustes et qui marchent bien depuis des années !
Tu pourrait créer un format pour formaliser cette modification LOCALE des variables d'environnement. Un standard est déjà un peu en place avec module qui n'est pas parfait car basé sur tcl qui a, à mon sens une syntaxe mauvaise (comme csh) mais aussi est uniquement dédiée à la ligne de commande (et les jeunes veulent du clic ! Les interfaces graphiques de nos jours sont bien trop basées sur la notion de variable globale à mon sens, il faudrait créer une interface graphique ergonomique qui gère correctement la notion de processus père fils)…
# Le retour...
Posté par MTux . Évalué à 3.
Cela me rappelle beaucoup les idées de Phoenix OS. Bon OK ça n'a jamais été un projet officiel ou sérieux, mais c'est tellement drôle.
[^] # Re: Le retour...
Posté par ymorin . Évalué à 7.
Ou bien de multidesk OS ? ;-)
Hop,
Moi.
[^] # Re: Le retour...
Posté par Obsidian . Évalué à 3.
Décidément, les backronyms, ça peut devenir redoutable, parfois…
# Déçu
Posté par jbbourgoin (site web personnel) . Évalué à 10.
Je suis sincèrement déçu. Le titre, la taille de l'article, et même l'entête laissait espérer un article passionnant portant sur des idées de conceptions nouvelles, et en fait … rien.
Rien d'autre que la très classique critique du modèle de distribution des applications dans le monde libre : les sources.
Car au fond c'est de cela qu'il s'agit. Des gros binaires ? Ca a toujours été possible.
Au fond, la seule critique qui vaille c'est celle de l'absence d'une garantie de compatibilité binaire sur le très long terme dans le noyau Linux.
C'est une vraie "critique", mais au fond le but de l'open-source est-il d'encourager les binaires fermés ou plutôt la disponibilité des sources ? Se poser cette question c'est comprendre les choix de conception du noyau Linux.
Quelle est la priorité ? Les applis proprio ou les applis libres ? Si ce sont les proprios alors il faut sacrifier certains choix de conceptions du noyau (et des distros), si ce sont les applis libres, alors il faut sacrifier les exigences des proprio.
Linux est un noyau libre avant tout conçu pour des OS libres, la réponse est donc donnée.
[^] # Re: Déçu
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 11 novembre 2012 à 00:17.
au contraire, la réponse est donné… mais inverse.
corrigez moi si je me trompe mais l'API externe de linux n'est-elle pas justement stable?
le libre, c'est le bordel que l'intérieur (donc ca emmerde les pilotes proprio, pas les applis)
Le reproche à "Linux" est que cette API est pas l'API de l'OS complet, juste le noyau. Linux est sympa pour les applis car stable.
Reste à avoir plus que le noyau stable… Il y a bien LSB, mais ça a du mal (faut dire que même vu de loin, ça a l'air pas mal critiqué). Par rapport au journal, je dirai que LSB répond à 100% aux critiques (mais comme toute tentative a des "bugs"), pas besoin de refaire une n-ième norme (avec encore plus de critiques et de bugs), on l'a déjà, juste que tout le monde n'adhère pas.
Pourquoi faudrait-il qu'il y ai une priorité? Tu penses trop fort que le libre est pourri au point de devoir le prioriser pour qu'il gagne. Ne peut-on pas le laisse gagner par ses capacités intrinsèques plutôt que de forcer les gens à faire du libre?
La stabilité d'une API n’empêche pas d'avancer ailleurs, bref on peut travailler avec les deux sans problème, si on veut (LSB ;-) ).
[^] # Re: Déçu
Posté par rewind (Mastodon) . Évalué à 5.
Ce n'est pas un choix, c'est une contrainte. À partir du moment où libre et proprio ont des exigences contradictoires, il faudra à un moment donné en privilégier un au détriment de l'autre. Historiquement, c'est le libre qui a toujours été privilégié sur Linux.
[^] # Re: Déçu
Posté par Zenitram (site web personnel) . Évalué à 2.
Quelles sont ces exigences contradictoires? Perso, je n'en vois pas. Je vois juste des bâtons dans les roues "pour le plaisir" d'un côté ou de l'autre, rien de contradictoire (genre "une API stable", ce n'est pas contradictoire avec le libre, ça n'a rien à voir en fait vu qu'on n'a pas forcément envie de se retaper toute la compilation quand on y connais rien, on veut juste que le projet libre qu'on a marche, y compris avec le dernier code compilé il y a un moment)
J'attend donc des précisions sur le contradictoire, et en attendant côté OS proprio le libre et le proprio cohabite très bien.
[^] # Re: Déçu
Posté par Misc (site web personnel) . Évalué à 6.
j'aurais tendance à dire qu'il faut surtout opposé développement bénévole avec développement commercial/payant.
Pour du dev bénévole, tu as 1) pas envie de faire des trucs chiants ( garantir la compatibilité, garder du vieux code, te limiter à une paire d'API parce que c'est le standard d'il y a 3 ans, )
2) les utilisateurs sont peanuts par rapport aux contributeurs.
Pour du dev commercial ( lire "payant", en simplifiant grandement et sans rentrer dans les multiples modèles possibles ), les gens comptent plus, car si ils partent, selon ton modèle, tu perds des moyens de manière bien plus quantifiable et immédiate. De plus, les moyens permettent d'avoir des gens pour faire les trucs chiants, ce qui permet d'avoir le niveau de qualité qu'on est censé avoir ( je précise bien "censé" car faut psa déconner, y a des softs payants et tout pourri et ou personne ne remets en cause le fait de payer une blinde pour divers raisons psychologiques )
Je résume un peu vite, mais c'est la vraie opposition selon moi. Et la question est de savoir si tu peux faire une plateforme qui permet de faire de l'argent sans que toi tu en fasses pour faire tenir la dite plateforme, ie les limites du don pour un produit pour utilisateur final.
RH et Suse arrivent à être durable, mais leur distros sont payantes, et j'ai jamais vu personne dire à un particulier : "prends ça, ça te couteras de l'argent mais tu va contribuer à faire tenir ça dans la durée". À contrario, Canonical n'arrive pas à avoir un modéle à l'équilibre mais ne fait pas payer sa plateforme. D'autres ont tentés et ont échoués aussi.
Donc bien que ça soit pas une démonstration formelle, loin de la, ça montre quand même que c'est dur d'assumer tout seul la stabilité ( qui compte des moyens ) quand tu n'arrives pas à monétiser directement les clients.
[^] # Re: Déçu
Posté par moi1392 . Évalué à 6.
Je suis d'accord sur la forme, mais fondamentalement, sur le fond, ce sont les rentrées d'argent qui comptent, et si pour cela, il faut effectivement que tu fasses le maximum pour tes clients, tu le feras. Mais qui sont tes clients ?
Regarde le nombre de pourritures installées sur une machine achetée en grande surface, tu penses que c'est l'acheter de la machine le client dans ce cas là ?
Regarde les systèmes de "protections anti copie" dans l'os pour tout ce qui est film et musiques, tu penses que c'est l'acheteur du logiciel le client dans ce cas là ?
Regarde tous les moyens mis en place pour emprisonner les utilisateurs dans une suite de logiciels et de services. Tu penses que c'est l'utilisateur le client dans ce cas là ?
Dans les développement libre, la partie qui marche mal, et qu'il est très dur de faire faire ce qui est vraiment chiant et qui améliorerait beaucoup son utilisation.
Par contre, un truc bien, c'est que le développeur est, dans 99% des cas, l'utilisateur le plus important du logiciel qu'il développe, et il ne va jamais rien faire qui lui fasse vraiment chier à l'usage pour satisfaire n'importe quel intérêt qui n'est pas le sien en tant qu'utilisateur de son logiciel.
Et mine de rien, ça donne souvent des résultats plutôt cool ("eat your own dogfood" comme ils disent)
[^] # Re: Déçu
Posté par Misc (site web personnel) . Évalué à 3.
Je pense qu'il y a plusieurs clients. Dans le cas du PC, le client, c'est toi, tu achètes, mais aussi les ISV, qui achètent la visibilité sur le desktop.
Et le truc tout pourri que tu as sur le pc ( version demo d'un antivirus, etc ), c'est aussi pour faire baisser ta facture d'utilisateur final ( car symantec, etc, paye les éditeurs pour la place ).
Et dans le cas des applications mal finis de l'éditeur, bah, c'est juste ça, des applis mal finis.
[^] # Re: Déçu
Posté par fravashyo . Évalué à 4.
justement ce n'est pas ça le problème, comme le souligne le journal :
j'ai pu déplorer cela à nombreuses reprises.
D'ailleurs le fait d'avoir un gestionnaire de paquets classique n'empêche pas d'utiliser par dessus un système plus axé "bundle" :
http://www.pcbsd.org/fr/
Le problème aussi c'est que des systèmes de paquets alternatifs pour faire ça, il en existe des tas : autopackage, klik, zeroinstall. Ce dernier semble encore exister mais je ne sais pas si c'est encore très populaire ni très fonctionnel (est-ce qu'une distribution installée il y a 4 ans permet de faire tourner un paquet compilé aujourd'hui ?
Enfin, même si je suis 100% d'accord avec le journal, on voit que ce n'est pas forcément le fait d'avoir un environnement stable sur le long terme qui rend la plateforme populaire, j'en veux pour preuve Android qui ne cesse de monter en part de marché, alors qu'ils n'arrêtent pas de casser la compatibilité avec leurs nouvelles versions.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
# casser les paquets et imposer la compatibilité binaire des drivers
Posté par Guillaume Knispel . Évalué à 10.
Je suis en désaccord quasi complet avec ton analyse énonçant qu'il serait souhaitable de casser le système de paquet au prétexte qu'il ne permettrait pas d'avoir une intégration correcte des bundles. Il n'y a aucune raison intrinsèque à ce que ça soit requis, et il serait bon de profiter du meilleurs des deux mondes : permettre une "intégration" acceptable des bundles, sans pour autant jeter le bébé avec l'eau du bain.
Concernant la compatibilité binaire à assez long terme des pilotes de périphérique, l'idée n'est potentiellement réaliste que si l'on utilise un micro noyau (du moins beaucoup plus que Linux et celui de Windows) et d'une manière générale un système beaucoup moins couplé que Windows et la tendance actuelle d'ultra-couplage du monde GNU/Linux (alors que MS fait justement des efforts de découplage depuis moultes années, hm certains concepteurs bien en vue feraient bien d'étudier l'histoire de l'autre côté de la barrière). Windows permet une sorte de compatibilité à ce niveau, mais elle est en fait bien plus mauvaise que la compatibilité dans le reste du système : le passage en 64 bits s'est assez mal passé (incompatibilité des matériels existants (quasi?) générale) et seule la puissance attractive de MS l'a rendue possible, il va probablement se passer exactement la même chose pour l'ARM si MS réussit sur cette archi. L'état des "pilotes" d'imprimantes est pour certaines (beaucoup!) marques calamiteux (justement parce que le système est si tolérant vis-à-vis des logiciels tiers et si prompt à attirer les entreprises de merde en les autorisant à bourrer tout de bloatware sous la dénomination absurde de "valeur ajoutée") et le non fonctionnement des drivers d'un Windows à l'autre est une méthode archi-classique d'obsolescence "programmée" (du moins entérinée). Les drivers d'une génération de sous-système précédent sont parfois tolérés sous Windows, mais modulo l'impossibilité d'utiliser certains logiciels applicatifs ou même certaines fonctions de l'OS (ce qui est parfois assez logique). Linux en forçant l'intégration des drivers les supporte alors parfois bien plus longtemps. De toute façon Apple a montré que le succès commercial pouvait être assez fortement décoléré de l'ouverture de la plateforme et de sa pérennité, initiant au passage une mode malheureuse.
Les besoins principaux en drivers permettant l'extensibilité ou l'évolution des PC de bureau aujourd'hui ne couvrent de toutes manières pas trop de catégories pour couvrir le besoin essentiel technique : imprimante et carte/chip graphique. Les imprimantes sont justement un point ou l'intégration de logiciel libre centralisé a permis un support à très long terme d'un très grand nombre de modèles, donc peu importe si certaines ne sont pas supportée, ce n'est pas plus un drame que les imprimantes de certaines marques qui sont systématiquement dépréciées toutes les deux version de Windows, ni d'ailleurs du device quelconque qui ne fonctionne pas sous OS X ou IOS ou je sais pas quoi. Pour ne pas empêcher le décollage le besoin est marketing et non technique. Concernant les cartes graphiques on est sur un marché ultra hi-tech et très concurrentiel avec encore principalement un cercle vertueux techniquement entre MS et les fabriquant de CG mais excluant fortement toute tentative des tiers de reprendre une partie du leadership pour (co)driver l'évolution. Donc il va falloir dans un premier temps suivre, avec tous les problèmes archi connus qui seront les même que sous Linux. Le besoin principal est un interlocuteur commercial assez puissant, et justement Valve est en train de foutre un peu le bordel dans ce milieu, donc l'idée la plus plausible serait de se greffer à ce mouvement et de réutiliser le plus possible des drivers Linux et stacks graphiques de base Linux. Je ne crois pas une seule seconde à l'arrivée d'un petit nouveau dans ce contexte.
Enfin je ne vois pas pourquoi "stations de travail est très mal servi". OS X est très utilisé pour certaines niches. Les grands éditeurs d'énorme suites logicielles typées "stations de travail" ont tendance à se concentrer sur Windows parce que l'OS suffit largement aujourd'hui (voire, dans certains domaines, est supérieur du fait de l'écosystème), et que cette standardisation de fait procure bien plus d'avantages qu'il ne pourrait y avoir d'inconvénients technique. Par contre pour les logiciels associés à du matériel (embarqué) on voit quelques retour ou passage au multiplateforme notamment dans le domaine des IDE, justement grâce aux plateformes constituée de logiciel libre qui s'imposent par leur qualité, couverture fonctionnelle, et parce que sur des thèmes considérées comme des commodités, puis une fois l'étincelle allumé par le cercle vertueux autour de ses softs se renforce des apports collaboratif de toutes les boites qui s'en servent (bref qui s'imposent par un faisceau de raisons qui ratisse très large). Par contre j'ai l'impression que ce phénomène est confiné au domaine qui intéresse historiquement les informaticiens unixien et/ou libristes vu qu'ils ont les plateformes de dev logiciel traditionnel qui excellent particulièrement et qu’ils drivent ce domaine avec du libre (bref conjonction d’énormément de facteurs, ça risque d’être difficile à reproduire).
[^] # Re: casser les paquets et imposer la compatibilité binaire des drivers
Posté par Guillaume Knispel . Évalué à 5.
Pour rebondir sur les crapwares sous Windows que tant de boites kiffent, probablement parce que le sadisme de leur dirigeants n'a pas de limite, je viens de tomber sur : http://dendory.net/blog.php?id=509ec629
[^] # Re: casser les paquets et imposer la compatibilité binaire des drivers
Posté par BAud (site web personnel) . Évalué à 2.
je te rejoins sur la situation déplorable des imprimantes : lors du passage à Citrix, beaucoup d'entreprises ont pâti de l'UNIDRV.SYS qui ne gérait qu'une portion des imprimantes du marché, là où celles qui avaient mis en œuvre CUPS en ont moins souffert (un serveur intermédiaire supplémentaire). Cela s'est amélioré, mais par le bas : les constructeurs sont devenus compatibles avec UNIDRV.sys, avec des régressions sur les fonctionnalités proposées (qualité d'impression, gestion du recto-verso…) là où ils auraient dû améliorer les standards d'impression pour le bien de leurs clients (surtout avec les imprimantes réseau). Le nivellement s'est fait par le bas : passage au PDF plutôt que Postscript et PCL avec des fonctions standards et diminution des transferts réseau (sérieux, un .doc de 300 ko doit-il générer 3 Mo sur le réseau ? sans parler des .doc de 50 Mo qui pourrissent le réseau, local il est vrai, à coup de 800 Mo, qui échoue lamentablement en erreur dans l'imprimante qui n'a que 64 ou 256 Mo de nos jours, certaines sont passées à 4 Go voire 16 Go pour gérer ce genre de "besoin" ?).
Je te rejoins sur le contexte unixien, aka "ceux qui ont compris ce dont ils ont besoin, plutôt que de chouiner".
Pour steam, j'attends des retombées effectives.
bref, oui, il y a des sujets concrets à traiter. Qui le fait, qui s'en charge ?
# plop
Posté par M . Évalué à 3.
Le noyau linux le garanti, apres c'est des questions de gestionnaire de package : rien ne t'interdit d'installer toutes les version de libc(/…) qui ont existé. Avec le versionning des bibliothèques, ca doit marcher.
C'est vrai que c'est chiant de devoir mettre a jour tout son noyau linux, pour pouvoir supporter un nouveau peripherique ou corriger des bugs, mais :
- linux est gpl et les drivers kernel sont aussi gpl (sauf exception)
- maintenir une compatibilité au niveau API interne serait assez compliqué (elles evoluent en permanence au gres du refactoring, nouveau besoin)
- en théorie on peut mettre a jour son noyau sans impacter les binaires user
[^] # Re: plop
Posté par gouttegd . Évalué à 3.
Heu, pas seulement en théorie. Ça fait des années que je mets à jour mon noyau régulièrement (une release mineure sur deux en moyenne), ça n’a jamais impacté les programmes utilisateurs compilés sur une version précédente. Jamais je n’ai eu à recompiler un programme suite à un changement de noyau.
[^] # Re: plop
Posté par M . Évalué à 3.
Je pensais au soft fortement couplé au noyau : modutils, udev, …
[^] # Re: plop
Posté par gouttegd . Évalué à 2.
Ben, même les programmes de ce genre supportent généralement très bien le passage d’une version du noyau à une autre. J’utilise actuellement une Slackware 14.0 dont tous les programmes ont été compilés contre un noyau 3.2.29 (le noyau fourni avec la distribution), et tous ces programmes fonctionnent sans problèmes une fois le noyau mis à jour en 3.6.6.
Et précédemment, sous Slackware 13.37, les programmes compilés contre un noyau 2.6.37 (fourni avec la distribution) fonctionnaient sans problèmes avec un noyau 3.4.2.
Même le passage d’un noyau 2.4 à un noyau 2.6, sous Slackware 11, n’avait pas nécessité de recompilation des programmes en userland, y compris les programmes « fortement couplés » au noyau comme udev, modprobe & co.
[^] # Re: plop
Posté par BAud (site web personnel) . Évalué à 3.
en même temps, le user est surtout lié à la glib/glibc et xorg et le ssl, donc bon.
après, c'est la roulette russe si un de ces éléments change :-) (ça marche parfois).
# Des serveurs
Posté par lordblackfox . Évalué à 1.
Sinon, j'aime bien le principe des serveurs comme sous gnu/hurd ou Minix. D'ailleurs la version trois de celle-ci met ses pilotes en user mode.
# Lance toi
Posté par Adrien . Évalué à 9.
Tu as des idées sur un OS, qui serait soit disant mieux que tout le reste. ok pourquoi pas, et bien lance-toi, et on verra si ton idée est si géniale… et un OS révolutionnaire de plus !
À mon avis ton problème de part de marché est mal posé : il n'y a pas un marché mais des marchés. Sur certains marchés (calculateurs, serveurs par ex.), les OS Linux s'en tirent de façon très honorable. Je suppose que tu voulais parler du marché « grand public ».
Sur ce marché, tu te concentrent sur des éléments techniques, hors les éléments commerciaux, marketing sont il me semble totalement prépondérants : Une grande partie des gens sont sensibles à ce qu'ils voient en magasin, et aux conseils des vendeurs. Que ça soit du Ubuntu, Debian ou Windows on s'en fiche, du moment que ça marche pour ce que je veux en faire.
Que proposes-tu donc pour éclairer le grand public et le faire acheter ton OS ? Tu as quelle force de frappe économique ? Quelle puissance publicitaire derrière toi ?
Je comprends l'intérêt des parts de marché, seulement il me semble que c'est un tort de se focaliser là-dessus : le « grand public » n'existe pas, c'est un personnage fictif. Plutôt que de satisfaire un personnage inexistant, dont peu de gens se reconnaissent dedans, il vaux mieux à mon avis satisfaire les besoins des utilisateurs actuels des systèmes libres. Et si notre système est réellement bon, alors les autres systèmes reprendront les bonnes idées sous peine de disparaître.
[^] # Re: Lance toi
Posté par myou (site web personnel) . Évalué à 5.
Et il faut avoir en tête que pour une majorité d'utilisateur, le mot "système" n'est pas précisément connu. Il utilise le système qui est installé sur l'ordinateur qu'il achète, c'est dans leur tête indissociable. C'est une réussite marketing.
Alors oui, les utilisateurs de système libres ont tendance à oublier cela, car en principe pour la plupart, il ont déjà fait la démarche d'installer autre chose. Mais pour cela il faut avoir un gout pour la technique que bcp d'utilisateur lambda non pas.L'utilisateur lambda veut allumer sa machine et que ca marche.
Le jour ou "OS_libre_revolutionaire 1.0" sera installé par défaut sur une majorité d'ordinateur neuf vendu dans le commerce alors il sera adopté par une majorité.
# l'OS dont tu rêves existe
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
https://www.haiku-os.org/
https://www.haiku-os.org/blog/zooey/2011-02-01_package_management_present_and_hopefully_near_future
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: l'OS dont tu rêves existe
Posté par reno . Évalué à 1.
Bof "existe" est un bien grand mot.
Certes ils gardent la compatibilité binaire avec BeOS, mais comme ils ont fait le choix de réutiliser un noyau très peu connu (une erreur à mon avis) au lieu d'utiliser Linux ou le noyau de FreeBSD comme base, ils n'ont quasiment pas de matériel supporté :-( :-(.
[^] # Re: l'OS dont tu rêves existe
Posté par navaati . Évalué à 3.
Et en plus, il le faisait déjà il ya
1015 ans.# Le grain de sel d'un simple utilisateur
Posté par Vincent Gay (site web personnel) . Évalué à 10.
Cher monsieur Benoît Jacob, chers Linufriens,
au milieu de ce concert de spécialistes et de techniciens, souffrez je vous prie qu'un simple citoyen exprime modestement son point de vue. Pas sur la compatibilité binaire, il y a bien des chances que je raconte des bêtises. Mais puisque l'auteur du journal évoque des "parts de marché" et que je suis moi-même utilisateur d'une distribution Linux, je me sens un peu impliqué.
Tout d'abord je me révolte contre cette pensée unique qui voudrait ne satisfaire qu'une majorité relative de clients. Que veut dire cette phrase ?
Outre l’exagération du "presque personne" (même 0,5% de la population ça représente quand-même un monde non négligeable), cela signifie-t-il :
Si l'heure se prêtait à l'humour (à l'ironie) je dirais que d'un strict point de vue commercial il existe en effet deux types de client à satisfaire :
Ce que n’entrevoit sans doute pas Mr Benoît Jacob c'est que dans ce modèle économique, une fois qu'un leadership a été établi, il est rarement possible de le remettre en cause. La seule exception notable que je connaisse est le marché automobile où les constructeur américains ont été victime, entre autres choses, de l’ineptie de la politique énergétique de leur pays qui les ont conduit progressivement à avoir des modèles inadaptés au reste de la planète.
Quoiqu'il en soit, quand on regarde l'histoire des empires économiques, on note qu'ils reposent tous sur l'émergence (la création) d'un nouveau marché, pas sur la prise d'un marché existant. Si vous souhaitez des parts d'un marché, Mr Jacob, créez-le vous-même. Pour les postes de travail, les ordinateurs de maison, les tablettes et les smartphones c'est vraisemblablement trop tard.
By the way ! Sans-doute suivez vous l’actualité de ces nano-ordinateurs arm genre Raspberry-pi, Mele A1000, Cubox, etc. Voilà un marché à créer ! Malheureusement (ou heureusement selon mon point de vue) les créateurs de ces engin se sont davantage évertués, me semble-t-il, à faire des systèmes ouverts qu'à vendre un rêve tout fait. Arf… C'est pas comme ça qu'on gagne de l'argent.
Bon, je m'égare, revenons à nos moutons. Enfin, je veux dire à nos clients…
L'une des dimensions quelquefois évoquée de Linux est son coté éducatif. Ça c'est différent, et ça me plaît. Quand je n'atteint pas le résultat escompté je sais que, neuf fois sur dix, je trouverai dans la communauté une documentation ou un forum qui me permettra de comprendre ce qui se passe et d'apporter les corrections nécessaires. Bon, comme je ne suis pas trop finaud ça prend souvent du temps, mais je finis généralement par trouver. Mais ça non plus n'est pas dans l'air du temps, il paraît que c'est rébarbatif d'apprendre.
Last but not least je suis persuadé que la société dans laquelle nous vivons est un tout dans laquelle il n'est pas possible de ne corriger qu'une partie en laissant les bases inchangées. C'est pourtant, j'en conviens, le rêve de beaucoup. Les écolos qui voudraient une économie de marché respectueuse de l'environnement, les sociaux-démocrates qui aimeraient un capitalisme plus humain. Il y a aussi des défenseurs des logiciels libres qui imaginent que leur liberté est indépendante de celles des paysans face aux semenciers, des thérapeutes face à l'industrie pharmaceutique, des journalistes face au empires des média… Mais ce n'est pas ainsi que je comprend les choses.
Selon moi les logiciels libres ne doivent pas conquérir de parts de marché mais s'inscrire dans un monde plus humain, plus solidaire, plus sûr, en un mot plus vivable. Donc je vous en supplie, Mr Jacob, le modèle économique mondialisé offre suffisamment de potentiel à votre soif de conquête, toute légitime qu'elle puisse vous paraître : laissez-moi mon Linux. Je tiens au moindre de ses défauts comme à la prunelle de mes yeux.
[^] # Re: Le grain de sel d'un simple utilisateur
Posté par reno . Évalué à 6.
Bah, pour un post qui dis "moi les PdM j'en ai rien à faire", il y en a dix qui disent "j'aimerai bien avoir l'appli/le jeu/tel matériel compatible"..
Et ça c'est lié aux PdM!
# Plan9
Posté par MCMic (site web personnel) . Évalué à 5.
Il me semble que plan9 ne supporte pas les bibliothèques partagées et que tout est compilé en statique justement.
[^] # Re: Plan9
Posté par Physche . Évalué à 1.
Tout à fait, et en plus les binaires sont bien plus petites sous Plan 9.
Par exemple :
Ce sont tous les deux exactement le même programme. Le premier est lié dynamiquement sous Linux et le second est lié statiquement sous Plan 9.
L'exemple est applicable à n'importe quel programme.
[^] # Re: Plan9
Posté par reno . Évalué à 1.
Euh, il y a des gros programme genre Firefox, LibreOffice sur Plan9?
Parce que là, la comparaison serait intéressante autrement bof.
[^] # Re: Plan9
Posté par Physche . Évalué à 1.
Non, mais mon but était de montrer que le gain de place n'est pas une justification suffisante pour s'encombrer de la complexité de la gestion des bibliothèques dynamiques. Au contraire, il n'est pas rare de constater que l'utilisation de ces dernières conduit à un espace occupé plus important.
[^] # Re: Plan9
Posté par reno . Évalué à 3.
Et mon post était pour te dire que dans l'absence de gros programme, ta justification n'est pas vraiment crédible.
[^] # Re: Plan9
Posté par liberforce (site web personnel) . Évalué à 3. Dernière modification le 12 novembre 2012 à 11:39.
Le gain de place, c'est aussi du gain en cache. Si c'est plus petit, ça tient mieux dans niveau de cache inférieur, et ça devient du gain en performance.
# Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Et les OS de cuisine ?
Posté par reno . Évalué à 1.
Bah, ce n'est pas parce que SGI s'est planté(trop cher) qu'il n'y a pas moyen de reprendre le marché des stations de travail..
[^] # Re: Et les OS de cuisine ?
Posté par Antoine . Évalué à 7.
De nos jours, le marché des stations de travail est à peu près confondu avec celui des machines de bureau « normales », je crois. D'ailleurs plus personne n'utilise le terme « station de travail » à part quelques nostalgiques.
Ce qui justifiait un marché distinct dans les années 90, c'était le manque de performance et de robustesse des PC.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Et les OS de cuisine ?
Posté par mornik . Évalué à 2.
Je suis pas sur que l'interface tactile du futur soit adaptée au poste de travail.
Pas sur non plus que l'intégration du web dans le desktop soit aussi adaptée à la sécurité du poste de travail en entreprise.
Pas sur non plus que mon poste de travail actuel avec toute ses abérations soit adapté à mon travail.
Bref, moi je trouve que "station de travail" ça à perdu un sens et qu'il serait temps de retrouver !
# Carrément une autre idée
Posté par Bertrand Sennegon (site web personnel) . Évalué à 1.
A mon avis, si on voulait rendre accessible linux à tout un chacun, ce qui fait sa grande force c'est sa diversité.
On pourrais donc imaginer soit un méta-installateur de distribution: Tu télécharge un cd d'installation, qui sonde ta machine, et te propose ensuite après un qcm bien ficelé la distribution qui te conviendrais le mieux avec options pour les experts pour obtenir rapidement ce que tu veut en quelques clics aussi.
Soit ce même méta-installateur pour une unique distribution (pourquoi pas debian, désolé du troll), qui te propose des sélections de paquets en fonction de ta bécane, de tes goûts, tes besoins de liberté, ton besoin de stabilité ou de rolling-release, etc.
Ça je pense que ça pourrais fonctionner autant pour les débutant que pour les habitués qui pourrait ainsi installer le système de leur choix en quelques clics.
Mais il faut un qcm rudement bien ficelé pour que l'installateur s'adapte à couvrir ce que tout un chacun peut attendre d'un GNU/Linux.
# Échec
Posté par zebra3 . Évalué à 7.
Je ne vois pas où est l'échec. Linux est largement répandu, bien plus qu'on ne croit.
Il est majoritaire ou important dans les téléphones, tablettes, les téléviseurs, les lecteurs enregistreur DVD/Bluray, les *box, les serveurs et même les supercalculateurs, sans compter toutes les appliances matérielles (pare-feu, routeurs, etc).
Il n'y a que le secteur du PC où il est négligeable, et tu extrapoles en affirmant que c'est un échec. En plus, la raison de cet échec est surtout que le choix n'est pas possible à l'achat, vu que 99% des PC sont vendus avec une licence qu'on ne peut refuser qu'après l'avoir payée et sans possibilité de remboursement sans passer par des démarches décourageantes même pour la majorité des libristes (non, je ne renvoie pas mon PC au fabricant pour désinstaller Windows).
Non, à mon avis Linux est au contraire une grande réussite, surtout compte tenu du fait qu'il soit né par hasard dans une chambre d'étudiant.
Et il n'a pas fini d'évoluer.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Échec
Posté par reno . Évalué à 5.
Le sujet du post est "Si on commençait un nouvel OS libre de bureau aujourd'hui" et toi tu parles de téléphones, téléviseurs, etc..
Ça c'est typique: ne pas accepter un échec dans un domaine en parlant des succès dans d'autre domaines.
Donc respire, personne ne cherche a agresser quelqu'un ou à diminuer les autre succès de Linux en reconnaissant que Linux est un échec sur le bureau (du particulier ou de l'entreprise).
[^] # Re: Échec
Posté par capslock . Évalué à 4.
Décidément, je ne comprends pas : Vous êtes plusieurs à parler d'échec, mais pourtant, sur mes bureaux, ça fonctionne très bien. J'ai raté quelque-chose ?
[^] # Re: Échec
Posté par saltimbanque (site web personnel) . Évalué à 2.
On peut critiquer ce billet pour son aspect technique, et par exemple parler de vente liée est pertinent, mais son succès sur le secteur PC est précisément le sujet et même mister Linus en parle
[^] # Re: Échec
Posté par barmic . Évalué à 2.
Qu'entends-tu par là ? C'est la démocratisation des ordinateurs personnels qui a poussé tout les autres domaines. Bien sûr c'est les jeux vidéos, mais même pour tout le reste à quoi sert d'avoir un réseau s'il n'y a personne pour se connecter dessus ? Pourquoi les téléphones devraient faire plus que le Nokia 3110 ?
Sans ce marché l'informatique existerait mais elle serait bien moins développée.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Et un coup dans l'eau, un !
Posté par Yth (Mastodon) . Évalué à 10.
Globalement ce que tu veux c'est que par exemple on puisse fournir un jeu sous Linux avec un installeur clicqouillable qui t'installe ton jeu et que ce jeu fonctionne sans que tes mises à jour système n'y changent grand chose ? Un système qui pourrait aussi être utilisé pour des logiciels etc ?
Bah un jour une boîte, Loki Games, a créé SDL et un installeur de ce goût là.
Aucun des deux projet n'est mort, libres ils ont poursuivi leur vie, alors que Loki Games a sombré corps et âme…
L'installeur Linux il existe, les jeux déployé statiquement avec leurs propres versions des libs, ils existent déjà, et ça compatibilise pas si mal que ça depuis toutes ces années.
Tiens, allez, j'avais acheté rune il y a bien longtemps chez Loki !
Pifpafpouf, je ressors mon installeur, diantre, il fonctionne !
Oh, ben allez, je vais lancer le jeu pour voir ?
A mais que se passe-t-il !
M'aurait-on menti ?
Bah il tourne…
Bon, bon, second essai, même jeu toujours installé sur une vieille machine, mais qui a été fortement mise à jour au fil du temps : le système a dû changer plusieurs fois sous les pieds du jeu, toujours bien rangé dans son /usr/local/games/.
Allez, on teste… Bigre, ça fonctionne aussi !
Bon, retour case départ, Linux fait déjà ce que tu demandes, ou en tout cas c'est déjà possible depuis des années… Parce que je sais plus quand je l'ai acheté Rune, mais Loki Games existait encore, je l'ai pas acheté chez LGP ! Et Loki Games a disparut officiellement le 31 janvier 2002, soit bientôt 11 ans…
Eh, c'pas si mal dans le genre compatibilité binaire à long terme tu ne trouves pas ?
Yth, au passage…
# Linux en étant libre souffre surtout de ne pas avoir de budget marketing sur un produit phare
Posté par FragBis . Évalué à 0.
Je suis plutôt d'accord avec l'un des commentaires qui disait que le problème de popularité de Linux tient plus dans son aspect marketing que dans son aspect technique.
C'est justement l'aspect technique qui fait que Linux existe comme noyau Unix le plus populaire. Donc, on ne devrait pas avoir trop de reproches structurels à lui faire. J'ai été formé à la base au Dotnet (avec Windows Server 2003, Visual Studio et SQL Server), mais les serveurs Linux m'ont tout de suite accroché. J'ai donc changé de camp.
Du point de vue d'un développeur, la force de MS est de proposer un IDE (Visual Studio) aussi riche et complet (même en version express). Comme je développe désormais en PHP, mon poste de travail reste désormais sous Linux (Mageia 2 avec KDE) et Eclipse comme IDE. C'est parfait. Par contre, pour du développement Java (par exemple), je me contente de faire du code qui se cantonne à faire des Inputs/Outputs en console car éditer des formulaires aussi simplement que sous Visual Studio, ce n'est pas la joie.
Même pour le développeur que je suis, j'aime bien que ça "claque" un peu visuellement et trouver un certain confort d'action pour faire des choses récurrentes (insérer un bouton dans un formulaire par exemple). Bon, comme je développe désormais en PHP, la question ne se pose plus et il n'y a pas mieux qu'Eclipse (ou Netbeans, mais je préfère Eclipse).
Bref, les gens veulent avoir de beaux effets visuels lorsque l'OS boote, que les "fonts" (caractères) ne bavent pas et soient nettes et précises (je trouve qu'Ubuntu pêche un peu à ce niveau-là) et ensuite, jouer, écouter de la musique, voir des films, aller sur Internet. L'arrivée de Steam (Valve), cela veut dire un budget venant d'une grosse société qui va investir en faveur de cette plateforme et ça change beaucoup de choses.
[^] # Re: Linux en étant libre souffre surtout de ne pas avoir de budget marketing sur un produit phare
Posté par FragBis . Évalué à 0.
Si Steam se met à proposer des "Steam Box", c'est-à-dire des PC (tours, portables, barebones etc.) avec l'OS Linux de Steam, cela veut dire qu'**on ne vous proposera plus Windows par défaut systématiquement**. Moi, j'achète. Surtout si ça évite de payer une licence Windows pour rien.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.