= Résumé pour décideur =
On entend souvent dire que le GNU/Linux c'est over-top super trop méga-bien pour le desktop.
Moi je dis : mouais, bof.
= Résumé un peu moins résumé =
Je m'intéresse ici à voir qu'est ce qui pourrait faire adopter Linux sur le desktop (je ne m'intéresse pas au coté serveur, le problème n'est pas à ce niveau), voir quelle sont les faiblesses, et pourquoi sa progression n'est pas aussi importante qu'on pourrait l'espérer.
Aux dernières nouvelles les stats d'utilisations de Linux ne sont pas très encourageantes, écrasé par le règne quasi sans partage de Windows. Je me pose donc les questions qui pourrait expliquer cet état de fait, et essayer de voir delà de la rhétorique auquelle je n'adhère pas franchement : "les con-sommateurs sont des veaux", "big billou graisse la patte aux constructeurs", "les constructeurs sont des gros nazes", "La vente liée est le vrai problème", ...
C'est un peu long, je dois l'admettre, j'espère que vous lirez jusqu'au bout et saurez voir au delà du "vendredi, c'est permis" (qui après le preumsage, le lol, voire le ptdr, serait la nouvelle forme de commentaires parasites ?).
Je sais aussi que ce n'est pas très encourageant de répondre à ce genre de texte, sans doute que Linuxfr n'est pas vraiment le meilleur endroit pour poster ça, d'autant plus que mon capital délit de sale gueule^W^W^W^W^Wkarma ne me permet pas d'accèder au panthéon de la première page.
Je suis un peu déçu de n'avoir pas vu ces questions posées plus tôt sur ce genre de forum. C'est comme s'il y avait une sorte de tabou, un blasphème à vouloir critiquer ce que les autres ont fait bénévolement sur leur temps libre, avec à chaque fois le risque de clore le débat avec la réplique habituelle : si ça te plait pas, t'as qu'à contribuer. Si c'était si simple ...
= Argumentaire =
Bon, pour moi, l'élément central de tout système d'exploitation, ceux qui devraient être mis sur un piédestal, dont la présence est une bénédiction, engendrant un cercle vertueux de croissance et de progrès, et qui fera revenir femme et enfants et cas de divorce : ce sont les développeurs. Je ne vais pas jusqu'à refaire la monkey dance d'un certain Steve B., mais je pense que la quadrature du cercle est simple : pas (ou peu) de développeurs, pas (ou peu) d'applications ; pas d'applications, pas d'utilisateurs ; pas d'utilisateurs, pas de développeurs.
Une fois n'est pas coutume, je vais annoncer directement à quoi rime toute cette prose. Cette phrase je l'ai lue sur ce forum ici-même (deo gratias à son auteur, que j'ai oublié), et qui résume très bien la problématique : "Il n'y a pas que les électrons à choisir le chemin de la plus faible résistance".
Or qu'est ce qui est sensé favoriser la venue de nouveaux développeurs sous Linux ? Bah, perso, je ne sais pas trop, mais je peux déjà vous dire ce qui les fait fuir.
== Format de package, API, ABI ==
Oui, je me souviens encore du troll^W^W de la dépêche [1] sur le support du format binaire sous Linux. On va donc la faire courte (la problématique, hein) : quand on est nouveau venu dans le monde Linux, le ticket d'entrée dans ce domaine est beaucoup trop élevé.
Faut bien voir que dans le monde Windows et Mac OS, on a plus trop à se soucier de ce genre de problème depuis pas mal de temps. Ok, j'en vois déjà qui se pointe avec leur DLL-Hell. Bon, ce n'est pas parce qu'une bande de bras cassé, auto-proclamé informaticien s'y prennent comme des manches, que toute la profession supportant entre autre Windows fait pareil. Avec un minimum de rigueur, ce problème n'en est pas un, pour faire court [2].
Mais revenons à la source : le point commun de tous les formats, c'est bien-sûr le fu^Hameux autoconf. En supportant ça, on a de bonne chance de voir apparaître un paquet pour chacune des distribs. Sauf que je pense que les mots ne sont pas assez durs pour dire combien ce truc est pourri, assemblage improbable de scripts shell, macros m4, à la courbe d'apprentissage quasi verticale, ou il est préférable de faire une petite prière, brûler un cierge et faire l'imposition des mains, pour ne pas tomber sur un cas d'erreur, concrètement indéchiffrable par une personne autre qu'un développeur chevronné.
Certes, il faut reconnaître que c'est toujours mieux que rien. Mais là encore, sous Windows et Mac OS on trouve une tétrachié d'outils pour faire du déploiement d'applications convivial (pour le développeur et l'utilisateur). Pour n'en citer qu'un je dirais NSIS, qui malgré son langage anté-diluvien, est très bien documenté, efficace, exhaustif et avec une large communauté qui le supporte derrière (comprendre : qui ont essuyés les plâtres avant vous). Sous Mac OS X, c'est encore plus simple (dossier zippé avec un beau fond d'écran qui vous invite à copier votre_belle_appli™ où vous voulez).
Ok, sous Linux ce type de solution est difficilement viable : il y a une flopée d'architectures à prendre en compte, sans parler du rangement des fichiers complètement hétérogène d'une distrib à l'autre. Pour les architectures, on peut largement relativiser, en disant que le x86 représente la plus grosse partie, le PPC une grosse part ce qui reste, et le restant ne sont que des poussières parmi les miettes, qui se contenteront parfaitement des sources. Pour l'arborescence, on peut se contenter des recommandations, avec une possibilité de relocation : ce n'est pas parfait, mais cela suffit dans bien des cas.
En cherchant un peu, sur comment supporter convivialement cette plus grosse part, on tombe bien évidemment sur auto-package, qui apporte de vraies réponses à un vrai problème. Ces développeurs ont fait un très bon boulot dans la limite de ce qui est faisable en l'état des lieux : le système de soft declare devrait être en standard dans gcc depuis des lustres, pour éviter en partie les affres de cette glibc. Un système de relocation des fichiers de données aussi.
Mozilla aussi s'est toujours bien démerdé dans ce domaine. OpenOffice aussi. D'un autre coté ça laisse un peu une impression qu'il faut une armée de développeurs pour arriver à ce qu'il est trivial de faire ailleurs par soi même. Je ne pense pas qu'attendre que quelqu'un de la communauté de la distrib veuille bien packager chaque logiciels soit une solution. Primo, ce n'est pas viable, ça ne passe pas l'échelle. Deuxio, pour susciter l'engouement d'un logiciel, ces qualités techniques et des fonctionnalités qui déchirent ne suffisent pas (surtout quand il y en a 50 autres qui font à peu près la même chose, mais avec chacun sa petite fonctionnalité en plus). Passer des heures à triturer des fichiers de configs, recomposer des dépendances, pour finir sur un segfault ... application qui déchire ou pas, les premières impressions sont tenaces, geek ou utilisateur lambda, la persévérance à ses limites.
J'en entends aussi qui vont me dire, que sous Windows et Mac OS X, on triche : les dlls sont bien souvent inclues avec l'appli, alors que sous Linux on limite la redondance autant que possible. Réponse courte : sur Windows et Mac OS X, on peut se permettre, pas sous Linux, parce que :
== Diversité des frameworks ==
Bon, ce point c'est vraiment le plus douloureux, je dirais même que c'est le noeud du problème. Au risque de faire hérisser les poils de certains, je dirais même que trop de diversité dans les frameworks, cela nuit à la liberté de l'utilisateur.
Je vais expliquer ce qui semble en apparence un paradoxe, et qu'un autre journal a abordé timidement [3]. Autant le format de package, c'est un poil pénible, mais on peut encore s'en sortir. Là par contre, il n'y a rien à faire : il faut mettre les mains dans le cambouis, avoir une sacré dose de persévérance. Un système qui me parait beaucoup trop élitiste, et qui doit faire fuir beaucoup trop de développeurs.
Étudions un cas d'école : j'aimerai développer une appli pour Linux (peu importe quoi). Que dois-je faire (en laissant le problème de package de coté) ?
=== La partie émergée de l'iceberg ===
D'abord choisir un toolkit : ce qui dessinera les menus, boutons, listes, etc ... Là où quasiment tous les systèmes ayant une sortie graphique proposait un toolkit pour développer des applications (AmigaOS, Atari, Mac, Windows, BeOS, OS 2, ...), sous Unix (enfin X11), il n'y avait rien.
À la décharge de X11, il y avait quand même Xaw (X Athena Widgets) à sa sortie, mais ce truc était une bouse si immonde et a si mal évolué, que ce n'est pas plus mal qu'on soit en train de planter les derniers clous dans son cercueil. C'est d'autant plus décevant que les couches inférieures (Xt et Xlib) sont relativement bien faîtes, même à l'heure actuelle. Je pense que ça a été une des erreurs les plus monumentales dans l'histoire du desktop informatique. Erreur qui s'est déjà payée en années d'errements et qui va encore en faire perdre un bon paquet.
Cela a conduit à la situation qu'on connaît aujourd'hui : multiplication des frameworks, dont la seule base commune est la libX11, voire la libc. Un peu léger pour proposer une intégration poussée des applications se basant sur l'un ou l'autre.
Bon, j'entends déjà certains hurler que c'est pour la diversité de choix, que quand on voit l'orientation de Gnome, on est bien content que KDE existe (et inversement). Que sans cette diversité, on serait encore à faire du Xaw tout pourri, et Linux ne serait que l'ombre de l'ombre qu'il est actuellement. Et puis de toute façon les distributions sont là pour harmoniser tout ça.
Vision typique de l'informatique où le point de vue libre passe avant celui des développeurs / utilisateurs.
Je pense que l'inverse est tout aussi important, sinon plus. Si certains choix font chiés l'un ou l'autre des groupes (ou pire, les deux), c'est que quelque part on se marche sur la tête et qu'il serait bien de voir si on ne peut pas y remédier, tout en garantissant une liberté, pour éviter de tomber dans les affres du proprio.
Pour prendre un exemple plus terre à terre : il suffit de regarder le web. Quand Netscape et Microsoft rivalisaient pour pourrir les standards, on était dans une situation de stagnation, exacerbée une fois que Microsoft avait réussi à éradiquer Netscape. Ce n'est que lorsque les navigateurs se sont mit à suivre les standards, et non plus les standards qui suivaient les navigateurs, qu'on a enfin vu le vrai potentiel du web. En restreignant la frénésie de gadgétisation et d'implémentations incompatibles, on a pu faire en sorte que tout le monde puisse utiliser une base commune suffisamment flexible pour ne pas brider la créativité.
Ce qui a fonctionné avec le web, ne fonctionnera évidemment pas avec le libre. Le web est chapeauté par une seule et même entité (W3C) ayant une vision relativement claire de ce qu'ils veulent et surtout de ce qu'ils ne veulent pas. Ça fait grincer les dents de certains, mais tant pis, ils iront voir ailleurs. La grande force du libre, c'est justement de suivre à la lettre ces standards, mais quand il n'y en a pas, ça part dans tous les sens et pas forcément pour le bien de l'utilisateur.
C'est à mon sens vraiment ce qui manque dans le desktop libre : un dictateur bienveillant qui saurait trancher à la Linus sur des sujets où une décision arbitraire est à prendre, où le consensus mou n'aboutit à rien d'autre que la contre-productivité.
Je ne dis pas qu'on doit imposer le clickodrome à la Windows (voire KDE), ou le monde figé de Mac OS X (voire Gnome). Mais construire un framework suffisamment évolutif, efficace, stable pour éviter de réinventer la roue des années plus tard et permettre une diversité à un niveau qui soit productif : le niveau applicatif.
Qu'on vienne pas me faire croire que parmi tous les bureaux qui existent il n'est pas possible de partager des pans entier de code : tout le monde y gagnerait, à commencer par les développeurs qui éviteront de se palucher des centaines de pages de docs, tout cela pour prendre en compte des différences parfois anecdotiques.
=== La partie immergée de l'iceberg ===
Certains me diront que Gnome et KDE (voire XFCE, E17) ont des points de vue trop différents sur de trop nombreux détails pour espérer un jour un quelconque rapprochement. Le langage de programmation, la licence du framework de base, sa politique d'API, d'ABI, des technologies utilisées (je pense notamment à la lourdeur de CORBA, comparé au pragmatisme de DCOP), etc ...
Quand on est habitué au libre, on trouve cela normal. Un développeur venant d'ailleurs, trouvera que c'est un peu overkill en matière de travail à fournir pour intégrer une application. Pour l'utilisateur on notera pas mal d'inconvénients aussi : look'n feel hétérogène, empreinte mémoire, lourdeur (chargement), intégration bancale. Qui oserait dire qu'utiliser une application KDE sous Gnome se fait avec une merveille d'intégration ? S'il y avait un équivalent potable à K3B sous Gnome, je mets ma tête à couper que tous ceux sous Gnome l'utiliseraient. On pourrait s'étaler des heures comme cela, mais ça déjà été fait trop souvent sur ce forum, avec à chaque fois ce même sentiment de déception.
C'est d'autant plus rageant que ni Gnome, ni KDE n'ont fondamentalement révolutionné le desktop. Ils ont certaines applications qui sortent de l'ordinaire, mais la vision du desktop se résume toujours à un bureau, un explorateur, une barre des tâches, un menu à la "Démarrer Windows", des bureaux virtuels, une API ultra-banales (mais incompatibles) et quelques gadgets autour (ok, beaucoup de gadgets dans le cas de KDE, ...).
Genre pouvoir factoriser des composants ultra-classiques, comme le sélecteur de fichier/police/couleurs (combien de trolls à ce sujet ?), le gestionnaire de fichiers (par exemple permettre depuis une application d'ouvrir un certain dossier et sélectionner un fichier qu'elle vient de créer, en utilisant les préférences de l'utilisateur, soit via Konqueror, via Nautillus, Rox, E17, Thunar, permettre d'afficher les propriétés du fichier, rajouter des extensions pour afficher des attributs étendus, ...), le composant HTML (on pourrait par exemple switcher de gecko à khtml). Sans parler de la doc développeur (il avait fallu un paquet d'années avant que la doc de GTK soit à peu près au niveau de QT), des tutoriaux, meilleure stabilité (moins de code = moins de bugs), légèreté (moins de composant à charger), donc rapidité, etc ...
Cela permettrait d'avoir une granularité nettement plus fine en matière de liberté : pouvoir personnaliser jusque dans les moindres détails son environnement pour le faire correspondre à son besoin. À l'heure actuelle, on est plus proche du tout ou rien, du tout Gnome ou du tout KDE (ou du tout E17, XFCE ou alors de gros blocs de l'un mélangés à la truelle avec de gros blocs de l'autre).
Dans la série, c'était mieux à vent, le moulin qui animait les machines Amiga était exemplaire à ce niveau. Le système était 100% proprio, mais si bien documenté, avec une API et une ABI figées dans le marbre (et très loin d'être pourrie par la compatibilité ascendante), les bidouilleurs de tout poil s'en donnait à coeur joie : tout ou presque du système pouvait être remplacés par un autre composant. Vu le peu de ressource de la machine, il n'y avait de toute façon pas trop le choix.
Pour en revenir aux problèmes d'homogénéisation et d'intégration, certains seraient tentés de dire que c'est à la distribution en question de faire en sorte que le tout tourne le plus harmonieusement possible. Dans look'n feel, il y a "look", pour lequel il possible de faire quelque chose moyennant une bonne dose de bidouille bien gore, pour le "feel", il va falloir s'accrocher : les fameux composants standards dont j'ai énumérés, les widgets aux comportements légèrement différent, rien de vraiment dramatique, mais qui laisse un arrière goût de bidouille, de mauvaise finition et d'amateurisme, que seul un amateur plus qu'éclairé pourra en apprécier la juste valeur.
Je pense que c'est ce qui va arriver, mais pas avant plusieurs années. D'ici là Microsoft aura encore plus ancré son monopole, brossé encore plus dans le sens du poil des développeurs et de l'industrie (faut quand même pas trop marcher sur ses plates bandes, hein), qui à leur tour feront venir les utilisateurs.
Certains seraient aussi tentés de dire que le jugement lapidaire de certains utilisateurs ne les prédestinent pas vraiment à utiliser GNU/Linux Le Pur. Je pense que c'est une grave erreur, tous les utilisateurs doivent être les bienvenus, quand bien-même ils switcheront pour un oui ou un non (Si c'est le cas, c'est que le desktop Linux doit encore faire des progrès) ou ne contribueront sans doute pas à promouvoir l'esprit libriste.
C'est, je pense, un excellent exercice. Cela remet l'informatique là où ce domaine se trouve chez beaucoup de gens : un outil, rien de plus. Les querelles de clochers (KDE c'est plusse mieux, tout est configurable, Gnome c'est encore plus mieux, c'est pensé neuneu-friendly) passe au mieux pour de l'amateurisme quand on voit qu'une application d'un environnement s'intègre relativement mal avec l'autre environnement.
Il faut savoir aussi ce qu'on veut : apporter un maximum de personnes pour réellement favoriser la diversité et la créativité, ou alors prôner l'élitisme et se retrouver bien seul lorsqu'il s'agit de faire des demandes auprès de constructeurs, au risque de passer pour de simples râleurs.
Si un exemple illustre magistralement cette règle élémentaire, je pense qu'il viendrait non pas de l'informatique, mais de la musique. Certains doivent sans doute connaître l'excellent site Over Clocked Remix (OCRemix pour les intimes). Pour faire court, car il mériterait un journal à lui tout seul[4], c'est un site qui regroupe des passionnés de musique de jeux vidéos et qui ont entreprit de remasteriser les mélodies des jeux de la génération Playstation 1 et antérieure. A ce jour plus de 1500 titres sont disponibles au téléchargement (plus ou moins légal tant que les auteurs originaux ne font pas trop valoir leur droit d'auteur, ce qui en général se solde par le retrait du morceau. Ça arrive. Rarement, mais ça arrive).
Ce site en question regroupe de tout, pour tous les goûts, dans tous les genres. Mais faut pas se voiler la face : le pire côtoie le meilleur, quand bien même l'appréciation est souvent subjective. Il faut tout de même reconnaître que certains morceaux sont plus proches du bruit agaçant ou de la cacophonie inaudible et exaspérante, qu'un flot apaisant de notes, transcendant le travail bien fait, au point où ça force le respect. Est-ce un mal ? Non, si la barre de sélection était de plus en plus haute, au bout d'un temps, plus personne n'oserait soumettre de nouvelles créations, de peur de passer pour un gros nul. Là on encourage n'importe qui a apporter sa pierre, même si ça ne risque pas d'être supra-transcendantal, dans un premier temps.
D'un autre coté voir un afflux massif de développeurs de tout horizon et pas forcément sensible à la juste cause, pourrait faire craindre à certains que les affres du monde Windows viennent polluer celui de Linux. Spyware, Adware, Shareware à la con qui foutent la pagaille dans le système.
A mon avis, cela n'arrivera pas, parce que chaque distrib est fournie avec un système nettement plus complet que Windows, des sharewares à 30 pièces pour décompresser du .zip, ça n'existera jamais. Et quand bien même cela existerait, il n'y a pas un flingue sur votre tempe qui vous forcera à les utiliser. Ok, certains de vos proches, moins technophiles, sans doute, avec le risque d'un appel au secours quand une de ces choses aura foutu le bordel. D'un autre coté si on tenté de voir ailleurs, c'est que le libre ne réponds pas (ou mal) à un besoin, et qu'il serait bien de se remettre en question ...
Certains seraient tenté de me faire remarquer que j'ai un peu trop longuement critiqué cette hétérogénéité bancale des desktop libres, mais sous Windows ce n'est guère mieux, pour ne pas dire pire. Une profusion d'interfaces playskool-like et débile-ready, belle sur une plaquette marketing, une horreur à l'usage quotidien. Sans doute, mais il y a 2 détails fondamentaux qu'il est bien de garder à l'esprit :
1. Si le desktop Linux, dans une certaine mesure, refait les mêmes erreurs que Windows, à quoi bon switcher s'il n'y a pas de réelles plus values aptes à intéresser un utilisateur lambda (non, les sources, 90% des gens s'en foutent). D'autant plus que certaines applications phares du monde libre sont aussi dispo sous Windows, voire sont nettement meilleures que l'équivalent Linux (Firefox pour ne citer que lui, du il me semble à un manque de développeur motivé : on en revient à ce que je disais au début : pas de développeur, pas d'application; pas d'application, pas d'utilisateur; pas d'utilisateur, pas de développeur).
2. Si on veut faire une application bien intégrée (de Win95 à WinXP) sous Windows, on peut. Il suffit d'utiliser un framework se basant sur l'API Win32, soit la majeure partie d'entre eux. Compatibilité binaire assurée depuis 15 ans, documentations littéraire et électronique exhaustives, énorme communauté et base de connaissance, ... Mieux : on peut utiliser du C ANSI (ce que je fais), C++, C#, même XUL semble se baser sur les Win32, une tétrachié d'environnement proprios, ... la facilité d'intégration n'est même pas comparable avec ce qui se fait sous Linux.
Là encore j'en entends hurler, que Microsoft à des moyens considérables pour ce qui est documentation, que Windows n'est pas aussi configurable qu'un système Linux, donc l'intégration est forcément plus simple.
Que Microsoft à des moyens largement supérieurs à toute la communauté opensource réunie, je n'en doute pas (faut pas se leurrer : des développeurs payés 8 heures par jour feront en quelques heures des tâches over-chiantes, là où un bénévole prendra plusieurs jours, pour rester gentil. Je dirais même que sans les boîtes qui financent certains projets libres, l'écosystème autour de Linux serait au point où le Hurd se trouve à l'heure actuelle : mort). Il à mon avis primordial de prôner l'union, pour agir en force, que de se diviser, qui permet aux autres et en particulier à Microsoft de régner.
Pour ce qui est de la configurabilité, Linux permet effectivement de tourner sur des machines considérées comme obsolète par Windows. Mais d'un autre coté, il faut relativiser : on utilise en général un système adapté à l'époque de la machine. Un système de 2007 tournera effectivement difficilement sur une machine de 1995, que ce soit Windows, Mac OS X ou Linux. Ok, Linux s'en sortira un peu mieux avec quelques composants plus à jour, mais aura globalement un niveau fonctionnel de la même époque.
Au risque de me répéter, je ne pense pas qu'il faille sacrifier la diversité qui fait en partie la force des desktops libres. Je rêve d'un desktop où chacune des parties seraient interchangeables par des composants issus de groupes différents, et ce jusqu'à un niveau infinitésimal : widgets pour toolkit, plugin pour format de fichiers que toutes applications pourra profiter (ah, les datatypes de l'Amiga : il suffisait de rajouter un fichier et pouf toutes les applications utilisant ce mécanisme supportait un nouveau format d'import ET d'export : son, image, document texte, html, source), pareil pour les formats vidéos, compression (pour lire de manière transparente les archives tgz, bzip2, 7z, rar, lzh, zip ...), indexage, ...
Je n'ai malheureusement pas utilisé assez longtemps le système BeOS pour en parler en long et en large, mais il y a une chose qui m'avait frappé à l'époque de sa sortie : l'engouement qu'il a généré. Voilà un système sorti pratiquement de nulle part, qui débarque avec des fonctionnalités vraiment novatrices pour l'époque : toute une communauté a suivit et a développée pas mal de logiciels, surtout orienté multi-média. Comment c'est arrivé ? Je dirais une combinaison de système performant, allié à une API bien foutue, un peu plus haut niveau que l'assembleur et donc "productive" (oui, je sais, ce n'est pas marrant de taper toujours sur les mêmes, mais GTK à encore beaucoup à apprendre à ce niveau), le tout avec une apparence propre et homogène : cela faisait que c'était FUN à utiliser et à programmer. D'un autre coté, s'il est mort, c'est avant tout à cause de son caractère proprio, on ne va donc pas s'éterniser sur son sort, hélas tellement banal. La liberté et l'indépendance doit être primordiale.
Certains me diront que KDE se rapproche de l'idéal. Certes, mais quid de Gnome, E17, XFCE, aux dernières nouvelles, ils font et feront toujours bande à part. Pour certainement tout un tas de bonnes raisons, mais au moins une extrêmement mauvaise : les développeurs ne se feront jamais chié à supporter toutes les combinaisons de desktops.
Tiens, j'aimerais faire un petit aparté entièrement subjectif sur KDE. Je dois dire que je n'ai jamais vraiment aimé cet environnement, sans doute que mes premiers contacts avec ce système n'ont jamais été très encourageant : à l'époque de KDE 1, j'avais un P133 avec 32M de RAM (avec la Mandrake 6 que j'avais récupérer d'un numéro de feu-login). Tout était lent : le système mettait une éternité à se lancer, les applications étaient longue à démarrer, ça manquait désespérément de réactivité, là où Windows 95 s'en sortait pas trop mal (mais avec la stabilité qu'on lui connaît). Je suis passé à un Merdon 333 avec 64M de RAM (qui a tenu jusqu'à la Mandrake 9.2), je voulais donc essayer KDE2 à l'époque. Même topo : ça bouffait beaucoup trop de RAM, le swap était trop sollicité, tellement que ça devenait pénible au quotidien. Comble des emmerdes, ma carte son n'était pas reconnue et arts bouffait 100% de ce pauvre CPU si on avait le malheur de le lancer. Mauvaise machine, changer machine, c'est ce que j'ai fait quelques années plus tard (entre temps je tournais avec XFCE) : un P4 "brûle-couille"^WXeon 2.8GHz avec 512M de RAM. Bon, cette fois, c'était un peu près réactif, mais extrement décevant en comparaison de la puissance de la machine et surtout de ce qu'un BeOS arrivait à faire pratiquement 10 ans avant (avec 10x moins de ressources) : clignotement intempestif (absence de double-buffering ou routines de rafraîchissement vraiment mal foutues), toujours cette impression de lourdeur dans les interfaces avec une profusion de boutons ou de GUI codées à l'arrache. Quand on est passé par Mac OS X, où chaque quart de pixel a été étudié pour être à sa place, ça fait un peu mal aux yeux. En fait, je me suis amusé un jour de désoeuvrement à virer tout ce qui ne me plaisait pas dans KDE : je me suis retrouvé avec une barre des taches, sans applet (même pas d'horloge, en fait j'avais gkrellm), quelques raccourcis pour les applications, 3 bureaux virtuels et un terminal ouvert en permanence (même pas d'icône sur le bureau) : le pire, c'est que c'était toujours aussi lent à se charger. Pouf, retour XFCE.
Je racontais donc ces incompatibilités entre les différents bureaux. Certains serait encore tenté de me faire remarquer qu'on commence à tourner en boucle : tous ces environnements ont des visions trop différentes, des positions trop tranchées pour envisager un rapprochement. Le libre c'est pas définition l'autonomie absolue. La coopération entre équipes hétérogènes est pratiquement vouée à l'échec, puisque bien souvent issue d'un fork ayant eu des visions différentes de l'équipe d'origine (Gnome vs KDE et même, heureusement avorté maintenant, GonMe Vs Gnome, KDE vs SimpleKDE, etc ...). On fait ce qui nous plaît, rien à foutre que ça fout le bordel, chezmoicamarche.org, envoie_le_patch™ ou pour les goûts prémachés, il y a Windows.
Ce que à mon avis beaucoup de développeurs doivent choisir bien avant de se le faire dire. Ça parait sans doute normal pour quelqu'un qui suit l'évolution de tout cela au jour le jour depuis des années, mais quelqu'un de nouvellement parachuté, aura l'impression de se trouver au milieu d'une véritable guerre des tranchées, avec peu d'espoir de vouloir servir de chair à canon. Quitte à dépenser son énergie, autant le faire là où il y aura le moins de travail à fournir, une histoire d'électron, toussa ...
Cette diversité est dans un sens bien pour les plus pointilleux qui ne peuvent utiliser une application que si elle correspond à 100% de ce qu'ils espèrent. C'est une horreur pour les développeurs qui doivent batailler avec une tétrachiée de détails overkill et supra-contre-productif, et les oblige à faire des choix quasi arbitraires, qui ne satisfera au mieux qu'une partie d'un pool d'utilisateur, déjà minoritaire à la base.
Dans un sens, c'est amusant : lorsque Linux, le noyau, commença à avoir une certaine visibilité, les spécialistes pensaient qu'il allait y avoir le même phénomène de dispersion que les systèmes BSD : des forks incompatibles, divisant la communauté et éparpillant les efforts. Dieu merci, ce fork n'a jamais eu lieu au niveau du noyau (chaque distrib le patche, mais se synchronise toujours avec la branche officielle à un moment ou un autre), par contre il est bel et bien arrivé au niveau du desktop.
Cela dit, soyons réaliste, à la base le métier de ... euh, non, ce n'est pas ça. Imposer une API figée, avec une politique de rétrocompatibilité claire et documentée, c'est :
1. Un boulot d'une chiantitude absolue.
2. Imposer des méthodes de développement du monde proprio.
Autrement dit : de la science fiction. D'autant plus que des méthodes du monde proprio, apporteraient aussi des applications du monde proprio. Un blasphème pour beaucoup de libristes, qui pourraient craindre, à juste titre d'ailleurs, un noyautage d'éléments critiques du système par des composants proprios (je pense notamment aux drivers proprios, qui posent de gros problèmes même avec une API/ABI stable).
C'est là qu'un dictateur bienveillant serait salvateur : avoir une vision claire des couches critiques du système pour éviter à tout prix le moindre noyautage. La problématique est simple : si un logiciel proprio veut supporter (avec ses méthodes) Linux, on évite de lui mettre des bâtons dans les roues. Mais surtout : si jamais la boite qui le maintient se pète la gueule, quelle sera les conséquences pour la communauté : si d'une manière où d'une autre cela fait du tort, un équivalent libre est préférable.
Certains ont sans doute du mal à comprendre cet acharnement à vouloir supporter ces logiciels proprios, purs produits capitalistiques à but uniquement lucratifs, exploitant la misère prolétarienne pour engraisser de riches actionnaires et venant souiller le monde si pur de la communauté libre. Personnellement je travaille dans un milieu où les logiciels libres répondent extrêmement mal aux besoins : on veut des interfaces simples qui marchent immédiatement, avec des besoins qui sont les mêmes depuis quelques décennies, et surtout avec du support derrière (et pas uniquement technique). Pouvoir appeler quelqu'un à 2h du mat parce que la production s'est arrêtée à cause d'un logiciel de merde ou d'une défaillance matérielle, avoir des conseils sur telles ou telles machines, le moyen d'optimiser les workflows, même de l'administration système ... Croire que la communauté peut répondre à tous les besoins, même les SSLL, ce n'est même pas utopique, c'est complètement stupide. Il y a des domaines où cet écosystème est tout simplement hors course faute de compétences ou de ressources. Progiciels pilotant des machines coûteuses, specs qui ne s'obtiennent que sous NDA, etc ...
On serait aussi tenté de dire que si ces gros nazes de constructeurs filaient les specs de leur machine, il y aurait du support depuis belle lurette de leur matériel. C'est oublier deux détails : il est loin le temps où la spec de la machine tenait sur une feuille de papier toilette. Je ne pense pas particulièrement à nvidia et ATI, qui gagnerait sans doute à ouvrir leurs matos tant il y a de la demande, mais j'ai déjà vu des constructeurs de matériel qui n'avaient tout simplement pas de specs. Toutes les informations, je les ai obtenues par email, avec un amateurisme flagrant (je trouvait un truc bizarre, hop, nouvelle doc, nouveau firmware pour mettre à jour le tout). Et surtout ce qui pourri tout : les brevets logiciels.
J'ai l'impression qu'on se trouve au milieu d'une guerre des tranchées : le modèle de développement ne correspond pas à une large part de l'industrie et de développeurs passionnés, et d'un autre coté l'écosystème Linux ne veut rien entendre d'autre que le code source (GPL, BSD, DWTFYWPL). Je pense que c'est mettre la barre beaucoup trop haute, qui fait que beaucoup doivent aller voir ailleurs.
== Nos camarades tombés ==
Il y a aussi une autre catégorie de développeurs potentiels complètement largués sous Linux. Bon, vous me direz qu'il y a d'autres priorités en ce moment. Ce sont ceux qui ont des formations initiales dans d'autres domaines que l'informatique, mais dont une partie de leur travail peut-être automatisé via l'informatique. La communauté du libre est avant tout spécialisée dans l'informatique, il y a peu de chance de voir apparaître des applis métiers spécialisées dans des domaines qui sortent un peu de ce cadre, genre en médecine (où absolument tout coûte la peau du cul et où tout est ultra-proprio), ...
Pour ce genre de personne il faut des outils de développement simples et bien documenté, avec une courbe d'apprentissage un peu plus proche de l'horizontale que de la verticale. Coder en C avec GTK et manipuler du autoconf, déployer du J2EE avec du JBoss, Struts, EJB, Hibernate, voire générer de l'assembly .NET, on nage en pleine science fiction. En fait ce n'est pas tant le langage qui pose problème que le framework : ça doit non seulement être simple, un minimum fonctionnel, avec une communauté qui peuvent les aider, sans les envoyer chier à la première question stupide qu'ils pourraient poser. En ce moment, cette place est plutôt vide sous Linux.
En général ça commence sous Windows avec des trucs proprios bien crades, à faire hurler de rire un développeur utilisant des technos open source, mais qui permettent d'avoir un truc un peu près fonctionnel très vite, mais surtout avec une courbe d'apprentissage moins intimidante. Ça porte des noms comme 4D (mention spéciale pour cette bouse infâme, dont j'ai du reprendre le développement d'une base écrite avec cette usine à bugs), Visual basic, Windev pour les plus courageux ou RealBasic pour les plus avertis (qui est de très loin le moins pire de tous et qui supporte Linux x86/GTK2 en plus, je dis bien GTK, pas Gnome).
Quand l'appli en question commence à avoir une certaine envergure, de vrais informaticiens prennent en général le relais, et refont le tout avec des outils corrects. Mais bon, la base de clients sera sous Windows, voire Mac OS X, et Linux se retrouvera une fois encore comme la cinquième roue du carrosse.
== Les constructeurs ==
On entend souvent que les constructeurs ne veulent pas proposer Linux par peur des représailles de Microsoft, ou parce qu'ils sont en partenariat avec Microsoft. Sans doute mais quelle alternative face à Windows ? Il me semble que Dell voulait proposer du Linux pour les machines à destination des particuliers (bon Mac OS X aussi, mais c'est aux antipodes de la politique d'Apple[5], et tant que les souris Microsoft seront de meilleures qualité que celle d'Apple, rien ne changera), sa préférence allant pour Ubuntu, mais faute de consensus dans la communauté, il préférait se contenter de fournir Freedos (et encore juste pour le marché pro). Autrement dit, seuls ceux qui savent déjà se démerder, choisiront cette offre, soit quasiment personne.
Ajoutez à cela un support plus que timide de l'industrie du logiciel (en dehors du coté serveur, bien sûr), il ne faut pas s'étonner que les constructeurs choisissent ce qui posera le moins problème avec leur hotline (genre : je fais comment pour lancer Half-life 2 ? Avec wine.c ou wine.h ?). Surtout cela sera compatible avec ce qu'ils trouveront dans la plupart des boutiques, contre qui, même avec la meilleure volonté, la communauté libre pourra difficilement rivaliser.
Windows laisse souvent ses utilisateurs dans la merde, à un point où l'association entre informatique et problèmes est devenue quasi instinctive, mais quid de Linux ? Un geek saura se démerder avec, mais pour un geek satisfait, combien de clients qui ne connaissent moins que rien vont râler et faire exploser le coût de la hotline ? Croire que tous les geeks de la terre vont faire le service de support est au mieux d'une naïveté touchante, au pire d'une hypocrisie malhonnête. Linux n'a jamais été autant déployé que Windows auprès du grand public, il est donc difficile de savoir à l'heure actuelle si ça serait pire ou meilleur que Windows. À mon avis, on aurait un beau match nul.
Mais il est clair que tant que Linux ne sera pas proposé comme alternative à Windows sur les machines des constructeurs, Linux ne progressera jamais. L'installation d'un système est une tâche ardue, quand bien même les distributions font des efforts gigantesques pour simplifier cela. Passer une semaine à peaufiner une installation pour que le tout fonctionne à 99% : là encore pour un geek qui réussi, combien vont abandonner longtemps avant cela. C'est d'autant plus rageant que les constructeurs savent parfaitement quel matériel ils mettent dans leur machine, et pourraient sans doute faire une installation bien plus rapidement que le plus motivé des geeks.
== L'avenir ==
Contrairement à ce que ce journal laisse supposer, je ne suis pas un multi de pBpG ou TImaniac. Je n'apprécie que moyennement Microsoft (enfin surtout ses dirigeants), leur vision de l'informatique se résume trop souvent à comment rendre captif les utilisateurs, même s'il y a eu des progrès ces dernières années (la pression de l'open source doit y être pour quelque chose). Et comme disait l'autre Steve : "ils n'ont aucune classe", ils copient les autres avec 3 trains de retard et balance leur rouleau compresseur marketing pour faire croire qu'ils ont tout inventé. Un peu de diversité permettrait de leur botter le cul, quand ça devient vraiment flagrant qu'ils se foutent royalement des utilisateurs (au hasard Firefox vs IE).
Il y a donc quand même un espoir, même si ça va prendre à mon avis beaucoup de temps (5 à 10 ans encore à mon avis) pour le desktop Linux ait un début de visibilité :
- Le Web : c'est de loin ce qui est le plus prometteur pour s'affranchir de la plateforme pour le desktop, bien plus que .NET et Java. Même dans mon domaine il commence à y avoir de la demande. Ça ne m'étonne pas que Microsoft freinait des quatre fers avec IE, pour éviter que ça ne se répande. D'un autre coté, il faut être aussi réaliste : les possibilités d'intégration avec le bureau d'une appli web sont nulles et cela restera comme ça par choix de conception. Mais cela reste une excellente échappatoire à la dictature Windows.
Bon, certains seraient tentés de me faire remarquer qu'avec les bras cassés qui conçoivent actuellement les sites, c'est plutôt mal barré pour le respect des standards du W3C. Je pense que c'est une question de génération, celle qui vient est un peu plus sensibilisé à ce problème. Ce n'est à mon avis qu'une question de temps.
- Plus généralement en fait : Les formats ouverts. Ce qui a fait le beurre de MS Office, c'est son format à la con qui prenaient les données des utilisateurs en otage. Ses pratiques étant devenues un peu trop flagrante, Microsoft a du heureusement lâcher un peu leste et ouvrant dans une certaine mesure son format.
Que personne ne veuille utiliser un desktop Linux, pourquoi pas. Mais dans ce cas, il est préférable que ceux qui veulent l'utiliser ne soient pas emmerdés par des formats qui imposent la taxe d'un système dont on ne veut pas. Au moins, peu importe qu'on soit minoritaire du moment qu'on peut continuer à l'utiliser.
- Vista : bon, c'est plus du conditionnel pour l'instant, car c'est trop tôt, ce système n'a que quelques semaines d'existence, il est impossible de tirer la moindre conclusion (notamment au niveau des DRMs, j'attends de voir). Mais il sera très intéressant de voir comment il sera accueilli par les utilisateurs (bien qu'à mon avis ça ne changera pas grand chose par rapport à XP), et surtout comment il sera accueilli par les fouteurs de merde : script-kiddies, virus, trojan, spyware, ... Je suis vraiment impatient de voir si Microsoft à retenu la leçon avec XP.
- L'adoption de Linux coté entreprise : la résistance au changements y est un peu moins forte que dans le grand public. Par effet domino, les particuliers pourraient suivre. Mais Microsoft à encore une bonne longueur d'avance, quand on voit le nombre de ventes forcées annuelles et la rente que ça génère. L'écosystème qu'il y a autour, l'armée de développeurs qui supporte souvent très bien Windows, l'inertie risque d'être très longue, à moins d'innovations techniques très nettes, aptes à intéresser les développeurs (bon, je ne répète pas la quadrature ...).
S'il y a bien un domaine où Linux pourrait enfoncer Windows, c'est là où BeOS avait marqué beaucoup de points : un système simple, réutilisation d'un max de composants, intégration à tous les étages, framework évolutif, sécurité intégrée, concepts élégants, etc ... Windows est enfoncé jusqu'au cou dans la compatibilité ascendante, il suffit de voir combien de temps cela prends pour intégrer les innovations des concurrents : 5 à 10 ans (accélération 3D, Média player, indexage [la grosse blague qu'était cette fonction de recherche dans XP], browser [IE6, le vilain petit canard du web], widgets [dashboard, karambar], ...). Il y a clairement encore de la marge pour d'éventuels concurents.
Je pense que tout un chacun de la communauté libre devrait avoir en tête la conclusion du reportage "nom de code: Linux" : "il serait dommage que Linux ne libère rien d'autre que du code source".
[1] http://linuxfr.org/2007/01/04/21845.html (326 commentaires à date)
[2] Pour anecdote, il m'est arrivé un jour de décompresser un vieux programme qui moisissait sur mon disque. Quand je le lançais via ./mon_prog, bash me balançait un magnifique "No such file or directory". P...n, il m'a fallu du temps pour comprendre que c'était la version de l'éditeur de lien dynamique (ld.so) qui avait changé entre temps. Je me suis senti un peu las sur le coup ...
[3] http://linuxfr.org/~jchampavere/23613.html
[4] Ne mourrez pas sans avoir écouté au moins ces morceaux, ils sont vraiment des
moments d'anthologie, même si on un réfractaire de jeux vidéos :
- Phantasy Star 4 LastBreathFirs de djpretzel
À tout seigneur, tout honneur. Djpretzel, a.k.a. David Loyld,
fondateur d'OCRemix et contributeur talentueux de son propre
site. C'est en fait le premier morceau qui m'a fait découvrir
ce site (bon, je l'avoue en recherchant la ROM de Phantasy
Star 4 sur le réseau pire to pire), ce n'est pas son meilleur
titre, mais il se débrouille bien (bon, je sais, je ne lui
arrive pas à la cheville moi même, alors je pourrais me mettre
mes jugements péremptoire DMC). En général, je trouve ses
morceaux très bien retravaillé, un vrai boulot de pro, on dirait
presque qu'il a manqué son métier (il est développeur). On lui doit aussi :
Actraiser Lord PROTEKTOR (qu'il a réalisé en 1h30. Arf, même
en 6 mois je serais incapable de faire ça), Final Fantasy 9
dubnofantasyaloneman, Legend of the Mystical Ninja OedoPentatonic,
Sonic the Hedgehog Love Hurts, Zillion InsideTheRoadhouse,
Phantasy Star 4 Millennial (faites attention au volume), Phantasy Star
Alis Overture (ouais, j'ai beaucoup aimé Phatasy Star, sauf le 3
qui était une grosse daube), tient, puisqu'on parle de Phantasy
Star, rajoutons Phantasy Star Wanta Phanta d'analoq.
- Earthbound Dreaming on Distant Shores de Rellik
Bon, j'avoue que je ne sais pas trop pourquoi je n'arrête pas
d'écouter ce morceau en boucle. Sans doute que si vous avez
un bon système Hi-fi, qui rends bien les basses, il y a de
quoi faire trembler un peu les murs :-)
- Bust a Groove Bust This Groove '81 OC de AkumajoBelmont
Magnifique prestation vocale de la chanteuse, qui interprête
les paroles comme une pro. En fait, sa voix me fait
penser à http://en.wikipedia.org/wiki/Sandra_Cretu .
- Super Street Fighter 2 Turbo New Mexican Thunderbird de Vurez
Une musique tout droit sortie d'un Western, magnifiquement
retravaillée par Vurez. Du même auteur, il y a aussi Ninja
Gaiden Basilisk Run.
- Human Race Bando alle Seghe de DHS
Un mix entre Jarre, Vangelis, Enigma et Deep Forest (ne vous
fiez pas aux premières secondes). Parfait pour
atteindre la zen-attitude. Le jeu original tournait sur
commodore 64, ça permet d'apprécier d'autant plus
l'excellent travail pour redonner vie à cette mélodie.
- Oddworld: Abe's Oddysee The Monsaic de The Orichalcon
Un autre titre très zen. Excellent quand ton boss te crie
dessus pour retrouver ton calme.
- Rygar Trippin' on Snails de MazeDude
Un moment de pure anthologie dans le style funky-jazz. L'original
était sur Famicom (on peut la réécouter sur tasvideo.org), avec
des sons bien asthmatiques, un
excellent travail de MazeDude a qui on lui doit aussi
Doom 2 Blood Bath (un peu plus hardcore, qui mérite vraiment
son titre :-), Deadly Towers Quest for Conan (genre médiéval),
Doom 2 Gothic Sandy, Lemmings LoungeLemmings,
Wolfenstein 3D Nazi Requiem, Chrono Trigger Island of Zeal.
- Street Fighter 2 DeeJay's Caribbean Rave de McVaffe
Encore un remixer talentueux que ce McVaffe ! Auteur de ce
légendaire remix, un mix de musique salsa avec une trame
jouée à la flûte, qui déchire tellement qu'on aimerait apprendre à
en jouer. On lui doit aussi Panzer Dragoon Groove, comme
son nom l'indique avec un style un peu plus groovy,
Red Alarm Red Dimension, Street Fighter 2 ZangiefRetroRussian,
Super Street Fighter 2 Cammy's London Drizzle, ...
- Metal Gear Solid 2 BigShellWestBristol de BenCousins
Un remix qui sort de l'ordinaire, c'est le moins qu'on
puisse dire. La première minute ressemble beaucoup au
générique de fin (insipide) de MGS 2 sur PS2, ensuite
c'est là que ça déchire : une inspiration très forte de
Portishead, qui ne plagit en rien le groupe, bien au
contraire même, c'est un hommage magnifique.
ETC (ma playlist fait plus de 300 titres :-) Pour ceux qui recherchent
de la musique qui ne passera jamais à la radio (forcément),
ça vaut la peine d'y prêter une oreille. Un an que je carbure avec
ça, et je ne m'en lasse toujours pas ...
[5] Ha, ha, cette parodie d'interviou vaut son pesant de cacahuètes. À
lire au moins pour le dernier paragraphe, à mourrir de rire :
http://florian.innocente.free.fr/?p=393
Journal [TROP LONG] Réflexions sur le libre
18
fév.
2007
# Trop long
Posté par Bibinsa . Évalué à -1.
Et avec le bug Beryl : DLFP ça aide pas :D
M'enfin... je vais écouter les morceaux du [4]
[^] # Re: Trop long
Posté par tfeserver tfe (site web personnel) . Évalué à 4.
[^] # Re: Trop long
Posté par wahnby . Évalué à 3.
a propos de autotools : AJAX aussi c'est un assemblage indicible et apocaliptiquement mauvais de divers langages et pourtant...
AMHA Le problème des outils de compilation comme les autotools, scons et autres c'est qu'il faut les programmer et pas les configurer.
[^] # Re: Trop long
Posté par vat . Évalué à -2.
Ressemble à un robinet qui fuit.
Je ne vois pas l'intérêt de taper autant de mots.
C'est un record à battre ?
Ca me parait inutilement dilué.
Le message ne passe pas.
Désolé
# Frameworks & co
Posté par Jean-François Martin . Évalué à 9.
Certains projets permettent de faire évoluer tous les Unix libre, je pense par exemple à HAL qui permet de gérer le matérielle sans a avoir a ce demander si le système est Linux ou un BSD. Puis il y a aussi dbus...
Je pense qu'il y a moyen de créer encore beaucoup de standards pour le desktop. Les choses se font petit à petit. Mais le projet freedesktop fait avancé pas mal les choses. De plus, la majorité des bureaux libre tente de suivre les spécifications qui y sont publié.
Puis le reste, c'est des librairies. Soit tu choisis une lib performante, soit une facile a utiliser, soit une qui semble plus intéressante sur le long terme, ..., ou une qui rassemble plusieurs de ces caractéristique.
Je pense pas que la multiplication des composants soit une mauvaise chose. Mais ça dépend du domaine. Ce serais bien par exemple de ne plus avoir 5 logiciels/dictionnaires différents pour les 20 applications qui en ont besoins multiplié par le nombre de langues que tu veux que ton système supporte.
Si tu as des idées, fais les savoir, il y a pas que les patchs pour faire avancer les systèmes libre. Les bonnes idées, ça aide...
# ...
Posté par Anonyme . Évalué à 5.
Le gros avantage de Linux, c'est son hétérogénéité, et c'est aussi son gros point faible. On ne peut pas tout avoir, si on veut du tout figé dans le marbre, on va voir du BSD (sur un serveur, c'est top) ou du Solaris, et puis c'est tout.
Linux a un côté bidouille ? Oui, c'est vrai, mais on a jamais forcé personne à l'utiliser. Personnellement, je m'en tamponne qu'il n'y ai que 0.5% de linuxiens, tant que je peux tout faire sur mon ordi comme je veux.
Pour le coup des GUI, c'est vrai, c'est bordélique, sauf que pour réellement changer ça, il faudrait dégager xorg, et relier une bonne fois pour toute le monde console, et le monde graphique. Et pour faire ça, il va falloir revoir en profondeur la DRI, les drivers, le principe des terminaux, et ça, ça amuse peu de gens, ne serait-ce que parce que ça va casser plein de compatibilités.
Pour le build tools, les autotools sont lourdingues, mais super modulaires (comprendre, on fait ce qu'on veut avec). SCons, imake, qmake, etc. sont minables, mais cmake est plutôt bien, si ce n'est qu'il est lentissime (et que son langage de script est immonde).
Les packages, c'est un faux problèmes. Le principe tout binaire est à chier. Sous gentoo ou archlinux, aucuns probs avec les sources (du moins en stable). Les ports *BSD fonctionnent parfaitement. Quand les gens arrêteront de pleurer sur le fait que doh, faut passer 2 jours à compiler en installant son système (2 jours pour des années de tranquilité...), ça ira mieux.
Après, et c'est valable pour tout le monde, si les outils existants ne te plaisent pas, code les. Tu ne veux pas (ou ne peux pas) coder ? Paye quelqu'un (société, pourquoi pas amateurs) pour le faire.
La liberté se paie, faut savoir ce que l'on veut, et moi j'ai choisis.
[^] # Re: ...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
archi faux à mon avis : y a toujours des mises à jour à faire (sécurité ou autre). Bref, tu n'es jamais tranquille avec un OS. Alors si en plus il faut compiler...
[^] # Re: ...
Posté par Bruno Adele (site web personnel) . Évalué à 2.
>archi faux à mon avis : y a toujours des mises à jour à faire (sécurité ou autre). Bref, tu n'es jamais tranquille avec un OS. Alors si en plus il faut compiler...
Tu ne passe quand meme pas 24H/24 sur ton PC ?
Moi générallement avant de me coucher je lance une mise à jours, et le lendemain, j'ai mon OS tout frais
[^] # Re: ...
Posté par Drake . Évalué à 3.
Et le surlendemain tu as une nouvelle centrale au charbon devant chez toi :)
[^] # Re: ...
Posté par ola . Évalué à 5.
[^] # Re: ...
Posté par Zenitram (site web personnel) . Évalué à 2.
Sous windows, les MAJ sont téléchargées automatiquement en tache de fond, je ne le vois pas.
Si c'est des MAJ n'obligeant pas à rebooter, c'est installé en tache de fond.
Si c'est des MAJ obligeant à rebooter, c'est quand j'appuie sur le bouton "power" de ma machine (ca le fait s'éteindre...) qu'il installe ces MAJ et s'éteint.
Parce que la, tà solution avec manipulation active avant d'aller au lit, c'est un truc de geek, pas de gens normalement constitué!
[^] # Re: ...
Posté par IsNotGood . Évalué à 2.
Sous Fedora il y a une tache de fond qui regarde s'il y a des mises à jours. En fonction de la configuration il downloade les paquets voire les installe aussi. Il peut aussi en informer l'utilisateur via syslog, mail ou dbug. S'il n'y a pas d'installation automatique de démandé, l'utilisateur est informé qu'il y a des mises à jour via une applet sur le bureau (communication via dbus). Il clique dessus et lance la mise à jour (optionnellement en choisissant les paquets à mettre à jour).
A ma connaissance, il ne fait pas de reboote. Mais je ne serais pas étonné qu'il y ait une option dans un coin pour le faire.
[^] # Re: ...
Posté par Fabimaru (site web personnel) . Évalué à 1.
Avantage: on n'a pas de problème du style:
- rah, ce programme n'est pas packagé pour ma distrib (tu sais, le programme qui a la fonctionnalité dont tu as absolument besoin)
- rah, il dépend de machin 1.06 alors que je ne peux qu'avoir machin 1.05 dans mes packages
- (boucler plusieurs fois sur l'étape précédente jusqu'à avoir récupéré la moitié du web et recompilé le monde entier)
- super, maintenant j'ai des binaires qui vont aller pourrir mon arborescence
Quand t'as des binaires bien figés, bien statiques, tu peux les utiliser pendant des années.
Quand on ne peut pas utiliser un programme parce que le système de package est trop contraignant, y a quelque chose qui cloche
# mouais
Posté par kolter (site web personnel, Mastodon) . Évalué à -3.
> super trop méga-bien pour le desktop.
> Moi je dis : mouais, bof.
moi je dis pareil, à propos de ton argumentaire.
par contre je vais pas écrire 1000 lignes de n'importe quoi pour essayer d'argumenter (ce serait inutile).
M.
# Pub éhonté pour OverClocked Remix
Posté par Tiwaz . Évalué à -3.
J'ai tout lu (et je n'arrive pas à comprendre d'ailleur les personnes qui postent sans tout lire, et qui sont actuellement de plus en plus nombreuse, ce n'est pas le sujet). Je pense également que LinuxFR devrait adopter une règle pour les messages dans le but d'éviter les trolls ou les messages poubelles, en fixant un minimum de mots pour un post.
La publicité, linuxFR n'est pas un blog...
Sous le couvert d'un texte avec argumentaire percutant ou le juste cotois l'approximatif ou le discutable, je vois surtout dans ce texte une publicité pour un site, qui prend bien un cinquième du total du texte. Même si les titres proposés sont de bonne qualité, le niveau de légalité est sujet à contreverse. De plus, malgré le nom des remixeurs, je ne vois aucune mentien de licence avec ces musiques, ce qui est sujet à débat. De ce fait, c'est étrange de voir ceci sur Linuxfr, alors qu'à mon avis, un blog serait plus approprié (Tu veux faire partager ta playlist, ok, mais pourquoi sur LinuxFR?)
L'argumentaire
Que répondre... On dirait presque que tu découvres l'informatique. Oui, en effet, une grande partie de ce que tu racontes est vrai, mais qui ne le sais pas. Quand à faire bouger les choses, c'est très différent. Comme bien souvent, ce qui fait la force fait aussi souvent la faiblesse de la chose, en particulier dans les "utopies". Quand à savoir si c'est un bien ou un mal. Tu oublies également une chose fondamentale, c'est qu'une grande partie des développeurs qui contribuent au libre y prennent plaisir, et cela, rien ne l'enlevera. Plaisir de répondre à une demande, plaisir de se voir diffuser, plaisir de coder.
# coin
Posté par Troy McClure (site web personnel) . Évalué à 5.
Effectivement en matière de langage celui de NSIS est vraiment hors du commun. C'est tellement a chier qu'il vaut mieux faire generer ses scripts NSIS par un autre langage plutot qu'essayer de faire un IF avec cette bouse. Franchement il n'a rien à envier à un bon configure.in, c'est vraiment extraordinaire qu'il marche aussi bien (parce que c'est vrai que ça marche bien)
Quand à macos je dirais pas que c'est si simple que ça. Pour bien faire il faut fabrique un .pkg (ou plusieurs .pkg dans un .mpkg) et foutre tout ça dans une image disque (un .dmg). Et mine de rien c'est du boulot assez chiant parce que le packagemaker de macos est tout pourri, pas vraiment command-line friendly. Et que ses fichiers de description de package sont en xml tout chelou. Et l'outil en ligne de commande pour creer des .dmg (hdiutil) est particulièrement moisi (pourquoi doit il interagir avec le finder et le demon de montage en plantant un des deux une fois sur 10 ?)
# Une seule chose à dire...
Posté par Mathieu Pillard (site web personnel) . Évalué à 7.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Vive le développement libre !
Posté par moo2 . Évalué à 0.
Non la faut arreter. Les autotools sont surement pas superbe. Problèmes incéssant de rétro-compatibilité. Moi qui suit le premier à être pour le lachage des vieilles API je dois bien dire que avec ça je suis plutôt bien embetté. Dès qu'il y a une nouvelle release faut bricoler un truc qui tiens d'un hack en semi bash-script dans les configure.ac pour faire passer les compiles sur les 3 ou 4 dernière sous versions des autotools (soit des debianeux aux gentooistes).
C'est justement le but des autotools de faire quelque chose multi-plateformes ET multi-versionnages...
Alors oui ils sont puissant, tout le monde en a l'habitude et il n'y a pas un seul equivalent potable à l'horizon. Mais ça reste un réel problème.
Et en ce qui concerne les .deb il faut arreter de croire que Debian est la seule distrib binaire qui existe. Je ne sais pas comment sont fait les .rpm mais en tout cas les .deb sont très loin d'être un bon format, entre dpkg et sa db ridicule qui est lente et se brise pour un rien, les scripts bash et perl qui bricole un peu avant et apres l'installation des paquets histoire de faire du pseudo 0config, le tas de fichiers de config qui trainent sur quasiment toutes les sources libres (ce fameux dossier "debian" qui traine de partout... heureusement que les autres distrib ne font pas pareil) et la cerise dans tout ça c'est apt qui est d'une incapacité déconcertante (par exemple verifier l'espace disque nécessaire _total_ AVANT de lancer une install pour pas s'arreter au milieu comme un con). Et encore NON aptitude et smart ne valent pas mieux.
[pub]
Personnelement je suis passer d'un tout apt/dpkg à pacman par Arch et ben je suis jamais repartis. Un système à la FreeBSD port+binaire mais en propre et qui marche.
[/pub]
Encore une fois. Si on pouvait eviter de mettre du XML pour tout et surtout n'importe quoi ce serait bien. Franchement n'importe qu'elle appli en XUL est lente pour se lancer (et ça au moins c'est commun à toutes les plateformes supportées). Avoir un fichier XML commun pour tout les toolkits reviendrais à perdre du temps à parser un truc qui ne peut même pas exploiter les points fort de chacuns parce qu'il doit être interropérable. Gtk à ses Glade, Qt ses Kdevelop développer en Glade/PyGtk ou en Kdevelop/C++ c'est simple, extrement rapide et franchement accessible à n'importe qui.
A propos de FDO
Il y a du bon et du mauvais dedans. DBus et HAL font partis du bon. Côté mauvais FDO est quand même très gnomistes et certaines propositions de specs passe à la trappe sans raison (par exemple celles conernant le trayer).
Bien que ça commence à venir, il manque aussi un peu de volonté par les developeurs qui ne suivent pas forcément toutes les normes (exemple le path du dossier de config, histoire d'arreter de remplir les home avec des .machins)
Et en ce qui conerne l'idée du journal : il vaut mieux avoir des developeurs qui perdent du temps à forker et a travailler dans différentes directions. Même si c'est contre-productif. Imagine les tous sur un projet commun, ils passeraient leurs temps a se tirer dans les pattes et on aurait qu'un seul projet qui partirait dans tous les sens. Ca ferait des programmes avec des menu de 3km de long, un seul bouton dans la toolbar et le tout qui se gère entierement au clavier.
Il n'y a peut être qu'1% d'utilisateurs sous linux/bsd/etc.. mais au moins ce 1% est satisfait parce que son desktop fait ce qu'il veut. Les 99% autres eux si ils en sont content c'est uniquement parce qu'ils n'ont aucun élément de comparaison.
[^] # Re: Vive le développement libre !
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
C'est ce que fait Gecko : un seul langage d'interface, en XML (le XUL), et derrière, ça repose sur un toolkit selon la plateforme (win32, gtk etc..)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Vive le développement libre !
Posté par Narishma Jahar . Évalué à 6.
> Au final, Adobe utilise Qt pour avoir des applis portable d'un OS à l'autre !
Pas vrai. Leur seul produit qui utilise Qt c'est Photoshop Album qui n'est disponible que pour Windows.
> Par exemple, dans Gtk+, Container et Layout sont fusionné, ce qui simplifie énormément la conception d'un UI, alors que Qt, Win32, AWT/Swing utilise tous un canvas foutoir où les widgets se superpose et ou il faut multiplier les lignes de codes pour avoir un fenêtre qui se redimensionne normalement, s'intègre dans la langue de l'utilisateur (RTL/LTR), …
Soit je n'ai pas compris ce que tu voulais dire, soit tu n'as jamais utilisé Qt. Dans Qt tu crée un layout (QHBoxLayout, QVBoxLayout, QGridLayout ou QStackedLayout) auquel tu ajoute tes widgets et ils sont redimensionnés automatiquement pour prendre tout l'espace disponible, en prenant en charge la taille des polices, la langue et la plateforme.
> La doc GTK+ est même meilleure ! Devhelp est une merveille ! Java et Qt ont des documentation verbeuse (la listes des méthodes prends 3 écrans …).
Là encore tu n'as pas dù beaucoup utiliser Qt. Compare (au pif) http://developer.gnome.org/doc/API/2.0/gtk/GtkEntry.html et http://doc.trolltech.com/4.2/qlineedit.html
Qt offre une description courte et si tu veux en savoir plus il y a une description plus détaillée. Il y a des liens vers les méthodes et classes relatives. Et si ça ne suffit pas il existe plein de bouquins. Bref la documentation de GTK est meilleure qu'il y a quelque temps mais n'est pas encore au niveau de Qt.
Je suis d'accord sur le reste.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Vive le développement libre !
Posté par Narishma Jahar . Évalué à 1.
Avec designer c'est encore plus simple : tu place tes widgets approximativement dans ta fenêtre et tu clique sur le bouton en forme de grille et ils sont alignés automatiquement et prennent tout l'espace dispo. Je ne vois pas comment on peut faire plus simple que ça.
Pour les livres, j'ai regardé sur amazon il y a 5 ou 6 bouquins sur Qt et aucun sur GTK+... Même la librairie du coin a des livres sur Qt4, pour GTK+ le seul que j'ai trouvé c'est un vieux sur GTK+ 1.x
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Vive le développement libre !
Posté par Mark Havel . Évalué à 1.
Je ne suis pas d'accord du tout. On parle ici d'augmenter les parts de marché de Linux auprès du grand public. Et le grand public, il tourne avec des CPU x86 voire x64 voire peut-être dans des cas limite des PPC. Donc s'occuper et perdre du temps à supporter des architectures utilisées par une minorité d'utilisateurs à l'échelle du nombre actuels d'utilisateurs sous Linux par rapport à Windows, je pense que c'est de l'énergie dépensée pour un apport assez faible. D'autant plus que l'on parle de package poiur stocker l'application et l'installer je pense qu'effectivement, les rares personnes qui voudront l'utiliser auront les compétences pour compiler via les sources.
# Et bien
Posté par Tiberium . Évalué à -10.
+1
# ...
Posté par M . Évalué à 4.
# Et pourtant ...
Posté par Miguel Moquillon (site web personnel) . Évalué à 5.
- écrire un logiciel pour GNU/Linux implique aussi de choisir quelle(s) distribution(s) et quelle(s) version(s) de celle(s)-ci un paquet doit être construit ; ceci conduit donc à un surcoût. Avec des serveurs de builds et de packaging, la problématique est résolue ; toutefois celle-ci n'est pas ou peu possible avec des SSII
- l'ensemble des frameworks/toolkits disponibles est un véritable casse-tête : un choix et une étude est à réaliser. Et il est vrai que cela rebute un certain nombre d'équipes. Pourtant ces différentes possibilités permettent de répondre aux éxigences et besoins dans le développement du produit.
Pourtant, malgrès ces problèmes, GNU/Linux ou des frameworks libres prennent. Alors pourquoi ?
- L'utilisateur n'a que faire de ces problématiques et la seule chose qu'il attend ce sont des outils qui répondent à ses besoins. Or, ces outils existent sous GNU/Linux ; ce qui signifie qu'ils ont été développés par des programmeurs qui ont passé outre les problèmes énumérés. Et au vue des programmes disponibles et de ceux qui sont en cours de réalisation, ces problèmes ne semblent pas si insurmontables que ça.
- L'utilisateur-développeur qui souhaite s'investir sur GNU/Linux va le faire pour l'environnement graphique qui a su faire battre son coeur : il choisira alors soit GNOME, soit KDE, soit Enlightenment ou encore GNUstep. Le problème va plutôt être celui qui voudra rester libre de tout desktop : que choisir ? Un toolkit basé sur Gtk+ ? Sur Qt ? Ou autre ?
Bref, l'ensemble des frameworks qui permettent de développer des applications est une réponse des communautés du libre à celles-ci ; autrement dit ils ont été développé par les développeurs du libre pour les développeurs du libre. Ils n'ont pas été réalisés pour les sociétés de l'industrie du logiciel. Il faut bien comprendre ceci pour appréhender cette différence d'approche qu'il y a avec Windows ou MacOs X.
C'est pourquoi, destinées aux entreprises, des réponses ont commencé à se dessiner : GNUe (http://www.gnuenterprise.org/) en est un exemple.
# Re:
Posté par IsNotGood . Évalué à 8.
> On entend souvent dire que le GNU/Linux c'est over-top super trop méga-bien pour le desktop.
Qui dit ça ?
Linus Torvalds qui a dit à mainte fois que rendre Linux compétif dans le desktop est un énorme chalenge ?
Mandriva qui fait du desktop mais ne décolle pas financièrement ?
Red Hat qui fait du pognon mais ne fait pas de Desktop (ou marginalement) ?
Les 0,2 % de poste desktop sous Linux ?
L'absence de l'implication des constructeurs de périphérique "desktop" dans Linux ? (voir le difficulté qu'a Linux pour avoir un Wireless correct).
Dell qui investi dans Linux mais que pour les serveurs ?
Bob Young (créateur de Red Hat) qui a dit que Linux ne serait jamais pour le desktop ? (c'était il y a 7 ans je crois).
> pourquoi sa progression n'est pas aussi importante qu'on pourrait l'espérer.
Qui espérait une progression importante ?
Personne dont l'expertise en reconnue. On s'attend à une montée lente. Ça commence à se mettre en place. Le déploiement de 20 000 postes chez Peugeot est un signe significatif. Je pense que les assurances vont probablement suivre. Mais comme d'habitude, ça va prendre du temps.
> Je suis un peu déçu de n'avoir pas vu ces questions posées plus tôt sur ce genre de forum. C'est comme s'il y avait une sorte de tabou
Absolument pas. Les plus avisés savent que GNU/Linux n'est pas méga-génial pour le desktop. Mais il ne faut pas compter sur les supporter du logiciel libre (dont je fais parti) pour dire que GNU/Linux c'est de la merde.
> pas (ou peu) de développeurs, pas (ou peu) d'applications ; pas d'applications, pas d'utilisateurs ; pas d'utilisateurs, pas de développeurs.
Sauf que GNU/Linux a de plus en plus de développeurs, que le libre a de plus en plus d'adeptes, etc...
Mais ça tu oublies de le mettre dans ton équation.
Tu parles d'un déclin et tu te trompes. Linux grippe et depuis longtemps. Le plus gros fournisseur Linux fait au moins du +30% par an depuis de nombreuse année. Un résultat de progression bien supérieur à MS. Linux prend des parts de marché à MS dans les serveurs. Il avait été prédit que Windows NT et ses successeurs allaient tout bouffer dans le domaine serveur. Ben ce n'est pas le cas. Et ce n'est pas qu'une question de temps. D'un succès garantit de Windows NT (puis 2000, 2003), on est maintenant passé à une position fragile pour Windows dans le domaine des serveurs.
> [blabla autoconf] Sauf que je pense que les mots ne sont pas assez durs pour dire combien ce truc est pourri
Il est unique mais il est pourri...
C'est celà oui...
MS en chie comme un con pour fournir une version 64 bits de son OS, Linux fait ça les doigts dans le nez grace entre autre à autoconf (on a tout en 64 bits sous Linux et depuis longtemps : noyau, libc, base de donnée, bureau GNOME/KDE, etc), mais tu conclus que autoconf est pourri.
On a du GNU/Linux partout. Sur i386, sur AMD64, sur PPC32/64, sur ARM, sur Alpha, etc... alors que autoconf est pourri selon toi.
Pour Windows il n'y a pratiquement rien. Il y a une version Alpha (qui tournait principalement en 32 bits....) et un version Mips. J'ignore si cette dernière variante a vu vraiment le jour.
> Mais là encore, sous Windows et Mac OS on trouve une tétrachié d'outils pour faire du déploiement d'applications convivial (pour le développeur et l'utilisateur).
C'est un blague ?
Faire un paquet rpm ou apt est 10 fois plus simple que de se casser les couilles avec les salopries fournies par MS.
Si rpm ou apt était pourri, tu m'expliques pourquoi on voit tant et tant de paquet rpm ou apt ?
Bon, j'arrète là de lire ton journal. Il y a connerie sur connerie pour les aspects techniques et ça me souale. D'autant que tu parles de développement sous Windows, et moi qui développe aujourd'hui sous Windows (faut bien manger), ben c'est la galère. L'API est immonde (sauf DirectX ceci dit). Apprendre l'API de Windows est un chemin de croix.
C'est depuis que je développe sous Windows que je comprend pourquoi Linux dans une certaine mesure tient tête à Windows. Linux tient tête à Windows car l'OS et son API est beaucoup mieux foutu. L'écart est si énorme, que même s'il y a plus de 100 développeurs Windows pour 1 développeur Linux, ça permet à Linux d'avoir son mot à dire. Si on ne connait pas Windows et Linux, si Windows à 100 fois plus de développeur que Linux (ce qui doit être le cas) on peut se dire que Linux va être balayé.
Si Linux s'impose sur le long terme, ça sera grace à son innovation.
Prends rpm ou apt.Tu les critiques mais quand on y a goûté, ça casse les couilles de passer sous Windows. Et ça les casse gravement.
Pourquoi il n'y a pas l'enfer DLL de Windows sous Linux ? Car Linux a une bonne gestion de version des librairies. Windows n'a presque rien (il y a un truc récent avec les manifest) et c'est pour ça que Windows c'est l'enfer. Pas car Windows a obligation d'avoir une API stable. Linux l'a aussi dans certains domains (glibc, x11, gtk, gnome, kde etc). Red Hat propose des systèmes avec une API binaire et source qui ne bouge pas durant 7 ans et aussi au niveau noyau.
L'enfer DLL de Windows, c'est seulement car Windows sucks. Un exemple, tu sais comment on fait pour passer de Direct3D v8 à v9 ? Ben on change tous les noms des fonctions, des types, etc... Mais même après ça, il n'y a tout simplement pas compatibilité ascendante. C'est ça une politique de compatibilité ?
C'est gentil de parler de la stabilité API de Windows. Mais il faut y regarder à deux fois pour voir qu'il n'y a rien de particulier ou magique.
L'innovation est ce qui va apporter le succès à Linux. Innovation qui permet la modularité. Modularité qui permet entre autre à Linux d'être un succès dans l'embarqué même s'il y a Windows CE. Modularité/innovation qui permet de faire OLPC. OS bien conçu qui permet d'avoir un support pour les nouveaux CPU 64 bits très tôt. OS bien conçu qui permet à Linux d'être le premier à supporter les technologie VT d'Intel et AMD. OS bien conçu qui permet à Linux de faire un carton dans le domaine des cluster (Windows y est maintenant marginal). Modularité/innovation qui permet d'avoir des distributions bien distinctent pour répondre à des besoins spécifiques (voir Gentoo par exemple). Innovation qui permet à Linux d'avoir un système au top pour le réseau (Linux supporte IPV6 bien avant Windows). Innovation qui permet à Linux d'avoir un système au top pour tout ce qui est lié à lvm. Innovation qui a permis GFS, FUSE, etc... Innovation via la disponibilité des sources qui permet à Google d'exister. Sûr que ce que fait Google avec Linux, Google ne pourrait le faire avec Windows.
Il y a plein d'innovations dans Linux qu'on ne retrouve pas dans Windows. Depuis quelques temps le projet stateless suit son court. Il est en phase de développement. C'est une innovation significative qui a moyen terme va séduire beaucoup de décideur/administrateur comme ils ont été séduit par rpm/apt qui permet de gérer ce qui est installé sur les bécanes sans se prendre la tête.
Autre point fort de Linux, et ce car globalement Linux refuse d'être un adèpte de la compatibilité binaire, sa rapidité à déployer les innovations. Linux est passé de linuxthread à NPTL sans grosse difficulté. La gestion fine de librairie a permis de fournir linuxthread et NPTL en parallèle durant la transition.
Linux est passé à UTF. C'est UTF-8 (codage de 1 à 6 octets pour compacter le donnée, mais ça tout UTF-32 qui est dispo) et couvre tout unicode. Windows ne supporte que la version 16 d'unicode.
Mon sentiment, ce n'est qu'un sentiment mais il est fort, est que GNU/Linux va gagner grace à l'innovation et pas car OS n'est pas cher. Un OS gratuit mais avec un TCO élevé ou qui n'offre pas de service attractif, est sans intérêt.
Certe, pour le Desktop Linux sucks aujourd'hui. Il ne sucks pas gravement. L'architecture que propose GNU/Linux est aujourd'hui solide et sans virus (virus : ça mérite un journal complèt quand on parle de Windows, et une ligne quand on parle de Linux). Les fondations de GNU/Linux (via le noyau, udev, hal, dbus, freedesktop pour les standards) sont OK pour un succès dans le desktop. Elle sont plus qu'OK et dépassent même Windows pour tout ce qui est périphériques amovibles (merci Linux 2.6/udev/hal). Mais ce qu'il manque cruellement à Linux, c'est le support des fabricants de périphérique. Fabricants qui misent tout ou presque sur Windows et un peu Mac. Chose compréhensible puisque ces OS trustent le desktop.
Mais dès que Linux prendra une parte significative dans le desktop (5 % suffit), la tendance peut s'inverser rapidement. Et lorsque ça arrivera, ça se remarquera comme c'est arrivé pour Linux dans les serveurs.
> il m'a fallu du temps pour comprendre que c'était la version de l'éditeur de lien dynamique (ld.so) qui avait changé entre temps.
Il n'a changé qu'une fois depuis que j'utilise Linux (depuis 10 ans) !
Mieux, tu peux toujours installer l'ancien éditeur de lien (ce n'est qu'un fichier (ld-1*.so)). J'ai fait tourner des programmes pour Linux 1.0 (0.99 en fait) sur des bécanes avec Linux 2.6. Ça marche comme un charme.
[^] # Re: Re:
Posté par wahnby . Évalué à 1.
Je vois pas ce que autoconf a a voir avec le 64 bits, je dirais que c'est plutot grace a gcc.
Alors je suis d'accord avec toi Linux c'est bien mais bon les autotools beuark quoi, enfin c'est mon optinion mais je pense que je la partage avec un certain nombre de personnes. (faudrait faire un sondage sur linuxfr)
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
En un sens tu as raison. Mais les programmes (donc les sources) peuvent avoir besoin de savoir si on est en 32 bits ou 64 bits, s'il faut activer l'option LARGE_FILE (cas 32 bits) ou non, si on est en big ou little endian, etc...
Autoconf fournit ces informations.
Après, il faut aussi que les programmes soient conçu pour 32 bits et 64 bits.
M'enfin quand on voit comme les outils libres tourne sur plein de plateforme/OS, on se dit que c'est aussi grace à autoconf.
> je dirais que c'est plutot grace a gcc.
Pour compiler gcc, gcc utilise autoconf.
> les autotools beuark quoi,
Ben fais mieux. Certe autoconf c'est moche. Mais il faut pouvoir installer et faire tourner autoconf avec trois fois rien. On ne peut pas demander à autoconf d'être écrit en C ou C++ (puisque pour compiler le compilateur il faut autoconf). Actuellement autoconf demande sh, awk, m4 et optionnellement perl et imake (si j'ai bonne mémoire).
> c'est mon optinion mais je pense que je la partage avec un certain nombre de personnes.
Et tout ces gens n'ont pas proposé mieux...
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 1.
Ben si justement, si autoconf depend de awk et autres softs compiles en C, alors il peut lui meme etre compile en C sans aucun changement au niveau des dependences.
Qu'autoconf serve a compiler gcc n'y change rien, ils s'amusent pas a partir d'une machine nue et recompiler le systeme entier chaque fois qu'ils recompilent autoconf, le bootstrap du compilo c'est pour le compilo, pas tout ce qui tourne autour.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
On peut aussi rendre autoconf dépendant de gcc, de libstdc++, de libxml2, avoir une interface graphique en gtk+ ou qt, etc...
On peut. C'est blindé de dépendances circulaires s'il faut construire depuis les sources "from scratch", mais oui, on peut. Après je ne te dis pas l'enfer que c'est de maintenir une distribution...
> Qu'autoconf serve a compiler gcc n'y change rien, ils s'amusent pas a partir d'une machine nue
Ben avec Gentoo oui (pour donner un exemple).
Autre chose, si tu installes des outils GNU sur un unix commercial, et si autoconf exigerait gcc, etc, alors je ne te raconte pas l'enfer.
Normalement les unix commerciaux ont : shell, awk, sed, m4. Ce que demande autoconf.
> le bootstrap du compilo c'est pour le compilo
Pour le bootstraper gcc, gcc utilise le compilateur fournit par l'unix commercial ou Windows. Gcc n'utilise pas gcc (mais il peut, ce qui se fait avec Linux).
Si j'ai bonne mémoire gcc fait :
cc (compilateur fournit avec l'OS) => gcc stage1
gcc stage 1 => gcc stage 2 (final)
Autoconf fait partit des quelques programmes GNU qui doivent avoir le minimum de dépendance. Idem pour gmake par exemple qui est exigé par beaucoup de projet (NB : gmake n'existe pas gcc).
D'ailleurs sous GNU/Linux ont fait en sorte d'avoir le minimum de dépendance circulaire. Sinon ça pose de gros gros problèmes pour maintenir les distributions.
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 1.
Personne dont l'expertise en reconnue. On s'attend à une montée lente. Ça commence à se mettre en place.
A mon avis son journal ne s'addresse pas a Linus Torvalds, Andrew Morton ou autres mais plutot aux gens qui frequentent ce site.
Tu sais, ces memes gens qui trouvent 3342 excuses pour expliquer pourquoi Linux ne decolle pas et refusent d'imaginer que cela pourrait etre du a des problemes du cote de Linux aussi.
Mais il ne faut pas compter sur les supporter du logiciel libre (dont je fais parti) pour dire que GNU/Linux c'est de la merde.
Mais a mon avis personne ici ne dit que Linux c'est de la merde, il souleve qqe problemes, ca veut pas dire que tout est a jeter hein.
plus gros fournisseur Linux fait au moins du +30% par an depuis de nombreuse année. Un résultat de progression bien supérieur à MS. Linux prend des parts de marché à MS dans les serveurs. Il avait été prédit que Windows NT et ses successeurs allaient tout bouffer dans le domaine serveur. Ben ce n'est pas le cas. Et ce n'est pas qu'une question de temps. D'un succès garantit de Windows NT (puis 2000, 2003), on est maintenant passé à une position fragile pour Windows dans le domaine des serveurs.
Ca depend de tes sources... http://www.itjungle.com/tlb/tlb082906-story01.html
The Windows platform, which has been jockeying for dominance with Unix for the past several years in the server market, accounted for $4.2 billion in sales in the second quarter, according to IDC, and increase of 3.1 percent. Windows-based server shipments increased by 11 percent
Somewhat surprisingly, Linux seems to be running out of steam a little. After nearly four years of double-digit revenue growth, the Linux server sub-market accounted for only $1.5 billion in sales in the second quarter of 2006, an increase of only 6.1 percent
Selon ces statistiques, Windows croit plus rapidement que Linux(ce qui me surprend moi-meme)
MS en chie comme un con pour fournir une version 64 bits de son OS, Linux fait ça les doigts dans le nez grace entre autre à autoconf (on a tout en 64 bits sous Linux et depuis longtemps : noyau, libc, base de donnée, bureau GNOME/KDE, etc), mais tu conclus que autoconf est pourri.
C'est surtout toi qui ne sais pas du tout ce que MS fait, passer NT a 64bits etait tres simple, ce qui etait plus complique c'etait avoir un support de drivers decent vu qu'on ne les ecrit pas, generer tous les tests necessaires et avoir un support pret pour gerer pour ca.
OS bien conçu qui permet d'avoir un support pour les nouveaux CPU 64 bits très tôt. OS bien conçu qui permet à Linux d'être le premier à supporter les technologie VT d'Intel et AMD. OS bien conçu qui permet à Linux de faire un carton dans le domaine des cluster (Windows y est maintenant marginal). Modularité/innovation qui permet d'avoir des distributions bien distinctent pour répondre à des besoins spécifiques (voir Gentoo par exemple). Innovation qui permet à Linux d'avoir un système au top pour le réseau (Linux supporte IPV6 bien avant Windows)
De nouveau, rien a voir, tu sais depuis quand MS avait un NT 64bits en interne ? Depuis quand NT supporte les technos VT ? Non, tout ce que tu regardes c'est ce qu'on vend, et les releases elles dependent de bcp d'autres criteres en plus de "c'est pret techniquement".
Tu melanges qualites techniques de conception d'un OS avec methodologie de developpement(l'un release souvent, l'autre pas), ce qui n'a rien a voir.
Linux est passé à UTF. C'est UTF-8 (codage de 1 à 6 octets pour compacter le donnée, mais ça tout UTF-32 qui est dispo) et couvre tout unicode. Windows ne supporte que la version 16 d'unicode.
Linux ? Qui ca le kernel ? Parce que des softs Linux qui ne gerent pas UTF-8 j'en connais plein, et un OS c'est legerement plus qu'un kernel.
L'architecture que propose GNU/Linux est aujourd'hui solide et sans virus (virus : ça mérite un journal complèt quand on parle de Windows, et une ligne quand on parle de Linux).
L'architecture que propose Linux est quasi-identique a l'architecture de Windows, j'imagines donc mal la difference, mais t'es libre de m'eclairer...
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
Je fréquente ce site. Et comme beaucoup ici (même si on n'est peut-être pas la majorité mais on doit être un part significative) je ne dis pas que Linux est au top pour le desktop et va tout déchirer dans les semaines à venir. D'ailleurs des journaux avec "Linux est-il près pour le desktop ?", etc... on en voit des tonnes.
> Tu sais, ces memes gens qui trouvent 3342 excuses pour expliquer pourquoi Linux ne decolle pas
Là tu fais une erreur. Linux décolle. Mais il est parti à 0,01 %. S'il grippe à 33 % par ans (ce qui est fort respectable), il faut plus de 8 ans pour arriver à 0,1 %, et encore 8 ans pour arriver à 1 %, et encore 8 ans pour arriver à 10 %. Donc il faut 24 ans !
Il suffit de bases minimum en mathématique pour savoir ça.
> C'est surtout toi qui ne sais pas du tout ce que MS fait, passer NT a 64bits etait tres simple, ce qui etait plus complique c'etait avoir un support de drivers decent vu qu'on ne les ecrit pas, generer tous les tests necessaires et avoir un support pret pour gerer pour ca.
Ben c'est que je dis. Linux a 64 bits (avec drivers et des tonnes d'applications) depuis longtemps et pas Windows. Il y a une offre pour entreprise en Linux 64 bits. Windows c'est récent.
Pourquoi Windows peine à avoir des applis et des drivers 64 bit ?
Car les éditeurs de logiciel et de driver trainent la pate ? C'est seulement à cause de ça ? Probable que l'API windows sucks car si j'ai bonne mémoire, la version Alpha de Windows tourne en 32 bit pour les int... Alors que le int naturel d'Alpha (son mot machine) est en 64 bit sur les unix (idem pour Linux). C'est juste un exemple...
> De nouveau, rien a voir, tu sais depuis quand MS avait un NT 64bits en interne ? Depuis quand NT supporte les technos VT ? Non, tout ce que tu regardes c'est ce qu'on vend, et les releases elles dependent de bcp d'autres criteres en plus de "c'est pret techniquement".
L'argument est pertinant. Mais je parle d'offres aux entreprises (désolé, je ne l'ai pas signalé plus haut). Je ne parle pas d'un truc qui marche au fond d'une université. Je sais qu'il faut du temps entre l'innovation et son déployement.
Red Hat 7 (voire encore plus vieux) proposait au entreprise i386, Alpha, Mips (peut être plus encore). RHEL 4 propose i386, AMD/Intel 64, PPC32, PPC64 et peut-être encore d'autres.
> Linux ? Qui ca le kernel ? Parce que des softs Linux qui ne gerent pas UTF-8 j'en connais plein
Exemple ?
Xbill ?
Qu'es-ce qui ne supporte pas UTF-8 dans Linux et qui est utilisé ?
Pas grand chose.
> Linux ? Qui ca le kernel ? Parce que des softs Linux qui ne gerent pas UTF-8 j'en connais plein, et un OS c'est legerement plus qu'un kernel.
Et il y a presque rien d'UTF-8 dans le noyau (pour ne pas dire qu'il n'y a rien). À part certains trucs pour les noms de fichiers, les terminaux, et guère plus (et je crois que ça doit être moins ça...). UTF-8 on le trouve en premier dans la libc, pas dans le noyau. Et d'ailleur ça ne doit pas conserner le noyau (à quelques exceptions près).
Clairement quand je parle d'UTF-8, je ne parle pas du noyau. Un noyau sans UTF-8 (si un noyau avec existe) ne doit pas poser de problème pour faire tourner une applie UTF-8.
> L'architecture que propose Linux est quasi-identique a l'architecture de Windows
Diantre, Microsoft, ton maitre, dit que Linux est une technologie de 30 ans et que Windows c'est tout beau tout moderne.
MS c'est trompé, ou c'était encore un gros FUD, ou Linux a rattrapé ses 30 ans de retard en moins de 10 ans ?
Les OS (noyaux) sont proches du hardware donc les OS sont proches pour certaines parties. C'est un fait.
Mais sous Linux on n'a pas de C: D: etc...
Sous Linux il y a les pseudo-terminaux.
Sous Linux il y a select().
Sous Linux il y a les signaux.
Sous Linux il y a etc...
Sous Windows il y a etc... (à toi de remplir cette partie).
Entre un Unix commercial et Linux il n'y a pas beaucoup de différence. Par contre entre Windows et Linux (et les Unix en général) il y a de grosses différences.
Ceci dit, comme je me documente sur Windows, je dois reconnaitre que le noyau de Windows fournit ce qu'on attend d'un OS "moderne". Par contre pour l'API bas niveau (tout ce qui est équivalent à glibc) c'est beurk. Les noms de fonction sont bizarres, il y a des HANDLE (void*) partout, des fonctions qui attendent un HINSTANCE (void *) fournit pas main() (diable, pourquoi la libc de Windows ne gère pas ça !), il y a des structures et des fonctions avec des membres/paramètres réservés, ou il faut la renseigner avec sizeof(struct), etc... Quel est la différence entre un HANDLE un HINSTANCE et HMODULE ?
J'ai rarement (jamais ?) vu API aussi moche. Et c'est diablement difficile à retenir.
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 0.
C'est donc que ce journal ne s'addresse pas a toi !
Là tu fais une erreur. Linux décolle. Mais il est parti à 0,01 %. S'il grippe à 33 % par ans (ce qui est fort respectable), il faut plus de 8 ans pour arriver à 0,1 %, et encore 8 ans pour arriver à 1 %, et encore 8 ans pour arriver à 10 %. Donc il faut 24 ans !
Il suffit de bases minimum en mathématique pour savoir ça.
Si j'en crois les statistiques, il etait deja a 2-3% il y a 2-3 ans(ils parlaient de Linux passant le Mac), hors rien ne montre qu'il soit alle plus loin, d'ou le "manque de decollage" de mon point de vue.
Pourquoi Windows peine à avoir des applis et des drivers 64 bit ?
Car les éditeurs de logiciel et de driver trainent la pate ? C'est seulement à cause de ça ? Probable que l'API windows sucks car si j'ai bonne mémoire, la version Alpha de Windows tourne en 32 bit pour les int... Alors que le int naturel d'Alpha (son mot machine) est en 64 bit sur les unix (idem pour Linux). C'est juste un exemple...
L'API n'a rien a voir, il est identique en 32 et 64bits(sauf pour tout ce qui est relatif a la compatibilite des softs 32bit sur 64bit evidemment). Le probleme c'est que les editeurs n'en ont rien a battre du 64bit jusqu'a ce qu'il commence a se repandre, le meme probleme que Linux a avec les editeurs.
MS met son poids dans la balance pour changer ca(Exchange 2007 est 64bits uniquement par exemple) mais ca prend du temps.
Quand a la version Alpha de Windows, Win2000 beta etait 64bits sur Alpha, mais Compaq a decide d'arreter les frais, ce qui a coule l'Alpha en passant, et Win2000 pour Alpha n'est jamais sorti.
>L'argument est pertinant. Mais je parle d'offres aux entreprises (désolé, je ne l'ai pas signalé plus haut). Je ne parle pas d'un truc qui marche au fond d'une université. Je sais qu'il faut du temps entre l'innovation et son déployement.
Red Hat 7 (voire encore plus vieux) proposait au entreprise i386, Alpha, Mips (peut être plus encore). RHEL 4 propose i386, AMD/Intel 64, PPC32, PPC64 et peut-être encore d'autres.
Tout a fait, mais moi je parles techniquement, NT n'avait aucun probleme a passer a 64bits techniquement. Le probleme c'est le marche. Combien est-ce que Redhat fait de chiffre d'affaire sur PPC et autres ? Rien du tout, raison pour laquelle MS a abandonne NT pour Alpha, MIPS, PPC et Sparc(il y avait un port en cours), et raison pour laquelle NT pour Itanium existe uniquement en version serveur alors qu'il y avait un XP pour Itanium.
Exemple ?
Xbill ?
Qu'es-ce qui ne supporte pas UTF-8 dans Linux et qui est utilisé ?
Pas grand chose.
Ben je te propose d'aller visiter http://www.jw-stumpel.nl/input.html
In what follows I investigate the state of UTF-8 support under Linux (especially Debian, the newest version, called ‘unstable’ or ‘Sid’) from a user point of view. ‘Support’ has several aspects:
Applications must be able to accept UTF-8 strings and files, and must be able to display them.
You should be able to perform keyboard input, in a variety of languages, easily.
Printing UTF-8 documents, web pages, e-mail messages, or whatever, should work.
Copying (by selection from the screen) and pasting from one application to another should work.
In all these areas, MS Windows performs pretty well. If you install the correct fonts, and Microsoft’s ‘Global IME’ components for input, your computer becomes, in effect, multilingual.
For Linux, the picture is mixed, but improving rapidly. Display of UTF-8 largely works (if you have the correct fonts); but really complicated (‘Complex Text Layout’) scripts like Devanāgarī do not seem to have good support (supported in Openoffice, but not in Mozilla)¹.
Diantre, Microsoft, ton maitre, dit que Linux est une technologie de 30 ans et que Windows c'est tout beau tout moderne.
MS c'est trompé, ou c'était encore un gros FUD, ou Linux a rattrapé ses 30 ans de retard en moins de 10 ans ?
Rien a voir, car ils ne parlent pas de la meme chose, au niveau securite les 2 ont :
a) separation user / kernel
b) separation entre users
c) notion d'administrateur / user avec acces limite
Bref, architecturalement parlant, ils sont quasi-identiques la dessus. Les signaux, select et autres n'ont rien a voir la dedans, on parlait securite.
Par contre pour l'API bas niveau (tout ce qui est équivalent à glibc) c'est beurk. Les noms de fonction sont bizarres, il y a des HANDLE (void*) partout, des fonctions qui attendent un HINSTANCE (void *) fournit pas main() (diable, pourquoi la libc de Windows ne gère pas ça !), il y a des structures et des fonctions avec des membres/paramètres réservés, ou il faut la renseigner avec sizeof(struct), etc... Quel est la différence entre un HANDLE un HINSTANCE et HMODULE ?
J'ai rarement (jamais ?) vu API aussi moche. Et c'est diablement difficile à retenir.
Les MFCs sont moches, tout le reste par contre est tout a fait normal. HINSTANCE et HMODULE sont identiques(les 2 existent pour des raisons de compatibilite avec Windows 16bit), HANDLE par contre c'est generique pour tous types de handles(HINSTANCE/HMODULE c'est pour un handle de DLL), c'est l'utilite des typedefs: le compilo t'avertira si tu passes un HANDLE a une fonction qui veut un HINSTANCE.
L'API il t'es difficile a retenir parce que tu debutes, moi je m'y sens comme un poisson dans l'eau, tout comme je me trouvais quand je passais tout mon temps sous Linux
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
D'accord. M'enfin, les stats ça change du jours au lendemain.
Exemple, au-dessus tu dis (sur la base d'une étude) que Linux a crû de 6.1 %. Sur la même période, le plus gros vendeur Linux fait du +40 % (chiffre absolu) !
Qui croire ?
Autre aspect a remarquer. Linux a été vite adopté par les geeks en tant que desktop (d'où une croissance rapide). Pour les geek, la partie est "gagnée". Je veux dire que Linux n'est plus une alternative exotique. Un geek qui utilise Linux, ça n'étonne personne. Au pif et sans le moindre chiffre, je dirais que Linux à 20 % des geeks ou hackers. Par contre en poste desktop pour monsieur tout le monde (la très grande majorité), c'est une tout autre histoire. Pour Linux y a, au pif et sans le moindre chiffre, 0,1 %. Donc pour arriver à 10 % il faut ... 16 ans.
> Le probleme c'est que les editeurs n'en ont rien a battre du 64bit jusqu'a ce qu'il commence a se repandre, le meme probleme que Linux a avec les editeurs.
Mais pourquoi les éditeurs (oracle, ibm, etc) font des versions 64 bits pour Linux et pas pour Windows ?
> MS met son poids dans la balance pour changer ca(Exchange 2007 est 64bits uniquement par exemple) mais ca prend du temps.
Il y a MS-Office en 64 bits ? Je n'en sais rien mais je ne crois pas.
Mais il y a bien openoffice en 64 bits pour Linux et il n'y a pas de version 64 bits pour Windows d'Openoffice.
Le fait est là, Linux à tout (ou 99,9 %) en 64 bits et Windows pas grand chose.
> le meme probleme que Linux a avec les editeurs.
Les éditeurs Linux font du 64 bits. Tu nous dis que Linux a gagné la partie pour le 64 bits ?
> Tout a fait, mais moi je parles techniquement, NT n'avait aucun probleme a passer a 64bits techniquement.
Ce que j'ai surtout voulu dire est que l'API (ce qui est vu par les programmes) sucks et rend difficile le portage d'une appli 32 bits vers 64 bits ce qui n'est pas le cas de Linux.
S'il est facile d'avoir des applis 64 bits sous Windows, pourquoi il n'y a pas MS-Office (j'imagine qu'il n'y a pas MS-Office en 64 bits, car en fait je n'en sais rien) ?
Linux a des ressources ridicules par rapport à Windows et pourtant tout est dispo en 64 bits.
> Combien est-ce que Redhat fait de chiffre d'affaire sur PPC et autres ? Rien du tout,
On dit que tu as raison. Mais si ça ne coute "rien du tout" à Red Hat d'avoir une version 64 bits, ils auraient tord de ne pas proposer du 64 bits. Si ça coute "rien du tout" pour avoir du 64 bits sous Linux, alors Linux est vachement bien foutu. Si ça coutait cher, Red Hat auraient tord de faire du 64 bits (surtout que Red Hat est ridicule à côté de MS) et ça fait depuis longtemps qu'ils auraient arrêté de le faire. Si Red Hat le fait, c'est qu'il y voir un intérêt et en monnai sonnante et trébuchante. Mais clairement Red Hat ne doit pas perdre d'argent.
Red Hat vend beaucoup de 64 bits. D'ailleurs pour RHEL 5 il y aura encore le support pour IA64 (ce qui montre que Red Hat a beaucoup vendu de RHEL 3 et 4 pour IA64).
> In what follows I investigate the state of UTF-8 support under Linux (especially Debian
Debian est l'un des derniers distribution a être passé à UTF-8 !
Red Hat est passé à UTF-8 depuis la Red Hat 8.0 ! C'est configuré par défaut depuis RHL 8.0. Puis il y a eu RHL 9, FC1, FC2, FC3, FC4, FC5 et FC6. Il n'y a pas encore eu de Debian stable en UTF-8 ! (OK, ça ne devrait pas tarder).
Aussi, RHEL utilise UTF-8 par défaut depuis RHEL 3.
Autre chose, Linux support UTF-8 (donc 2^32 caractères, c'est-à-dire tout unicode). Windows (et si mes renseignement sont bons) que UCS-2 (2^16 caractères). UCS-2 est insuffisant pour certain language (c'est pour ça que Unicode est passé à 2^32).
Sous Linux en mode texte ça concerne la libc. En mode graphique ça concerne principalement gtk (pango). Malheureusement OpenOffice ne supporte pas pango et Mozilla que via un patch non officiel (qui marche bien mais impact significativement les performances). Le patch est dans Fedora depuis FC2 (pour Mozilla) et activé par défaut depuis FC3.
Notons que Firefox est principalement développé pour Windows (normal, il y a beaucoup plus d'utilisateur).
Ceci dit le support d'Unicode est une tâche énorme (avec les problèmes lorsqu'on mixe des écritures de gauche à droite et droite à gauche, par exemple, etc...), donc qu'il y ait des problèmes ne m'étonne pas.
> Les MFCs sont moches
Tu me fous la trouille. Je n'ai pas encore regardé MFC. Mais si MFC est pire que le reste, ça fous vraiment la trouille.
> HINSTANCE et HMODULE sont identiques(les 2 existent pour des raisons de compatibilite avec Windows 16bit)
Ben les deux sont dans le dernier SDK platform de Windows... (de 2006).
Je ne crois pas que quelqu'un va installer le dernier SDK de Windows pour faire une application 16 bit.
Ces trucs ne sont qu'un pointeur sur l'adresse du début du programme ou dll. Tout un poème.
> L'API il t'es difficile a retenir parce que tu debutes
Non. Par exemple DirectX, plus spécifiquement Direct3D, passe très bien. Et pourtant j'y connaissais rien dans le domaine des cartes graphiques.
Exemple : Dans Linux tout ce qui est thread débute par pthread. Sous Windows c'est une autre histoire.
Sous Linux il n'y a que le pid du thread. Sous Windows il y a l'HANDLE et le pid (parfois nécessaire pour quelques fonctions).
Regardes les fonctions liés à la mémoire sous Windows et compare avec Linux. T'as même un LOCALHANDLE... Des relant de Windows 16 bits dans le dernier SDK de Windows...
Pour le multi thread il y a les CRITICAL_SECTION/EnterCriticalSection/LeaveCriticalSection mais ça ne marche que pour un processus. En interprocessus, il faut autre chose (via les Event). Sous Linux, c'est la même chose pour intro-process et inter-process, tu dis seulement si tu veux que ça marche en inter-process (donc passage par le noyau systèmatique) ou non. C'est tout. La librairie C fait les appels système qui vont bien dernière. Si tu veux passer d'un processus à plusieurs, ça se passe comme une lettre à la poste.
> c'est l'utilite des typedefs: le compilo t'avertira si tu passes un HANDLE a une fonction qui veut un HINSTANCE.
C'est gentil ça. Un timer (event) et un process a le même type sous Windows. En fait tous les "objects systèmes", selon la terminologie MS, a le type HANDLE. Tu peux passer un timer ou un block mémoire à la place d'un process ou d'un fichier, le compilo ne voit aucun problème. Ce n'est en rien le cas sous Linux et fort heureusement.
Les typedefs Windows en utilise des tonnes et pour des conneries. Par exemple pour char il y en a plus d'une dizaine !
Linux utilise beaucoup de typedef (probablement plus que Windows) mais pas pour des conneries (comme DWORD qu'on trouve partout ce qui doit poser de gros problème de portabilité). Linux utilise des typedef là où c'est pertinant : quand le concèpt est différent. Un pid même si c'est stocké réellement dans un int (DWORD dans le language Windows) n'est pas un int, pour des raisons de portabilité, d'évolution système (lorsque le pid passe de 16 bits à 32), etc.
Autre chose rigolote, c'est DWORD. C'est un int ou un long ? Ben je crois que même MS n'en sait rien. Ce n'est pas un problème en soit. Surtout que sur du 32 bits int=long. Mais pour 64 bits on peu avoir par exemple sizeof(int) = 4 et sizeof(long) = 8. Donc le diff de deux pointeurs ou une taille mémoire n'est plus un int (DWORD) mais un long. Ben avec tous les DWORD dans l'API de Windows qui désigne des concepts différents (nombre, quantité de mémoire, etc), ça doit foutre un sacré bordel.
Linux (en fait POSIX) n'a pas ce problème. Si tu codes correctement, passer de 32 bits à 64 bits (que sizeof(int) soit 4 ou 8, qu'importe), passe comme une lettre à la poste.
Autre problème, Windows semble avoir des conventions de nommage mais elles sont peu respectée. Exemple : utiliser le préfix P pour le pointeur alors que c'est rarement utilisé. Les types qui sont parfois uniquement en majuscule et parfois un mix. Normalement ce qui commence par '_' est à usage interne d'une lib système (une appli ne doit pas l'utiliser !), ben sous Windows pas forcément, etc...
De ce que j'ai vu jusqu'à maintenant il n'y a que Direct3D qui est une bonne API (et pourtant Direct3D est particulièrement complexe ce qui ce comprend très bien).
Quand on sait que les constructeurs de hardware sont très impliqués dans le développement de Direct3D, on comprend que Direct3D n'a pas le "Windows touch".
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 0.
Qui croire ?
Je sais pas, tout comme toi, mais disons qu'une societe a des raisons d'augmenter ses chiffres, IDC un peu moins.
Par contre en poste desktop pour monsieur tout le monde (la très grande majorité), c'est une tout autre histoire. Pour Linux y a, au pif et sans le moindre chiffre, 0,1 %. Donc pour arriver à 10 % il faut ... 16 ans.
Les chiffres je sais pas, mais d'accord sur la tendance. Linux vabien pour les geeks, et a plus de problemes pour monsieur tout le monde.
Il y a MS-Office en 64 bits ? Je n'en sais rien mais je ne crois pas.
Mais il y a bien openoffice en 64 bits pour Linux et il n'y a pas de version 64 bits pour Windows d'Openoffice.
Office c'est en cours je crois.
Quand a OpenOffice 64 bit, si je vais sur http://download.openoffice.org/680/index.html je ne le vois pas, et en cherchant sur le net, je ne vois nulle part trace d'une version stable 64bit
Ce que j'ai surtout voulu dire est que l'API (ce qui est vu par les programmes) sucks et rend difficile le portage d'une appli 32 bits vers 64 bits ce qui n'est pas le cas de Linux.
S'il est facile d'avoir des applis 64 bits sous Windows, pourquoi il n'y a pas MS-Office (j'imagine qu'il n'y a pas MS-Office en 64 bits, car en fait je n'en sais rien) ?
Linux a des ressources ridicules par rapport à Windows et pourtant tout est dispo en 64 bits.
a) Tout n'est pas dispo en 64bit sur Linux, loin de la
b) Tu me montres la difference des APIs entre 32bit et 64bit sur Windows ? Je t'aides, t'auras du mal.
Quand a Office, ben pour la meme raison qu'OpenOffice faut croire...
On dit que tu as raison. Mais si ça ne coute "rien du tout" à Red Hat d'avoir une version 64 bits, ils auraient tord de ne pas proposer du 64 bits. Si ça coute "rien du tout" pour avoir du 64 bits sous Linux, alors Linux est vachement bien foutu
Ben moi je vais voir http://www.redhat.com/about/presscenter/2005/press_rhel4.htm(...) et je vois qu'ils supportent x86, Itanium, AMD64 et Power.
Voila, ca fait UN de plus que Windows, c'est a dire aucune difference a peu pres.
Autre chose, Linux support UTF-8 (donc 2^32 caractères, c'est-à-dire tout unicode). Windows (et si mes renseignement sont bons) que UCS-2 (2^16 caractères). UCS-2 est insuffisant pour certain language (c'est pour ça que Unicode est passé à 2^32).
Windows supporte UTF-16 depuis un moment deja(depuis XP en tout cas), ca fait 6 ans...
Je ne crois pas que quelqu'un va installer le dernier SDK de Windows pour faire une application 16 bit.
Ces trucs ne sont qu'un pointeur sur l'adresse du début du programme ou dll. Tout un poème.
Par contre plein de boites prennent leur ancien code 16bit et veulent le recompiler en 32bit, et la ca rend les choses bcp plus simples vu qu'ils n'auront quasiment pas a changer leur code.
Exemple : Dans Linux tout ce qui est thread débute par pthread. Sous Windows c'est une autre histoire.
Sous Linux il n'y a que le pid du thread. Sous Windows il y a l'HANDLE et le pid (parfois nécessaire pour quelques fonctions).
Il n'y a pas de PID pour les threads sous Windows, il y a un thread ID, Linux a un Process ID pour des threads, alors que ce sont des threads, pas des process, tu m'expliqueras la logique.
Pour les APIs multithread, de nouveau, c'est parece que tu ne comprends rien a l'architecture de Windows.
Tu fais comment pour attendre sur un event, un timer, la fin d'un thread, ... sous Linux ? Ah oui, des APIs differents, sous Windows, tous ces elements sont des objets, et tu utilises WaitForSingleObject.
Pour le multi thread il y a les CRITICAL_SECTION/EnterCriticalSection/LeaveCriticalSection mais ça ne marche que pour un processus. En interprocessus, il faut autre chose (via les Event). Sous Linux, c'est la même chose pour intro-process et inter-process, tu dis seulement si tu veux que ça marche en inter-process (donc passage par le noyau systèmatique) ou non. C'est tout. La librairie C fait les appels système qui vont bien dernière. Si tu veux passer d'un processus à plusieurs, ça se passe comme une lettre à la poste.
Sous Windows, personne n'utilises le modele "plusieurs processus", sous Unix c'est frequent car jusqu'a recemment le support des threads etait a chier, resultat, tout le monde utilise les CRITICAL_SECTION
C'est gentil ça. Un timer (event) et un process a le même type sous Windows. En fait tous les "objects systèmes", selon la terminologie MS, a le type HANDLE. Tu peux passer un timer ou un block mémoire à la place d'un process ou d'un fichier, le compilo ne voit aucun problème. Ce n'est en rien le cas sous Linux et fort heureusement.
Un block memoire ? Tu fais ca comment pour avoir un HANDLE sur un block memoire ?
Quand a timer/process/... sont des objets, et tu as un HANDLE sur ces objets, avec lequel tu passes a WaitForSingleObject, resultat, tu peux attendre sur tous ces objets avec le meme API. Bien plus simple que les 32 APIs differents pour faire la meme chose sous Linux.
Les typedefs Windows en utilise des tonnes et pour des conneries. Par exemple pour char il y en a plus d'une dizaine !
Linux utilise beaucoup de typedef (probablement plus que Windows) mais pas pour des conneries (comme DWORD qu'on trouve partout ce qui doit poser de gros problème de portabilité).
Plutot que dire que c'est pour des conneries, et si tu donnais des exemples ou c'est inutile ?
Autre chose rigolote, c'est DWORD. C'est un int ou un long ? Ben je crois que même MS n'en sait rien. Ce n'est pas un problème en soit. Surtout que sur du 32 bits int=long. Mais pour 64 bits on peu avoir par exemple sizeof(int) = 4 et sizeof(long) = 8.
Oh si on le sait, c'est meme documente, comme tous les autres types : http://msdn2.microsoft.com/en-gb/library/aa383751.aspx mais visiblement tu ne lis pas la doc, dans ce cas pas etonnant que tu n'y comprennes rien.
Un DWORD c'est 32bit, non signe. Un DWORD64 je te laisses deviner.
Si tu codes correctement, passer de 32 bits à 64 bits (que sizeof(int) soit 4 ou 8, qu'importe), passe comme une lettre à la poste.
Tout comme sous Windows, mais ton probleme c'est que tu n'y connais rien et en parles quand meme.
Autre problème, Windows semble avoir des conventions de nommage mais elles sont peu respectée. Exemple : utiliser le préfix P pour le pointeur alors que c'est rarement utilisé. Les types qui sont parfois uniquement en majuscule et parfois un mix. Normalement ce qui commence par '_' est à usage interne d'une lib système (une appli ne doit pas l'utiliser !), ben sous Windows pas forcément, etc...
Donnes des exemples plutot que donner des generalites, ca rendra ton discours plus credible.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
Les chiffres de Red Hat sont des chiffres comptables. De plus Red Hat étant en bourse ils sont vérifiables. Là tu dis que Red Hat magouille et tu pousses le bouchon un peu loin si tu n'as aucune preuve. Et si t'en as, lance des poursuites contre Red Hat. Tu es sûr de gagner et tu auras la bénédictions des actionnaires de Red Hat.
> IDC un peu moins.
Je n'ai pas remis en cause l'honnêteté d'IDC dans cette étude.
> Quand a OpenOffice 64 bit, si je vais sur http://download.openoffice.org/680/index.html je ne le vois pas
http://fr2.rpmfind.net/linux/fedora/core/6/x86_64/os/Fedora/(...)
Cherches openoffice, tu le trouveras en 64 bits. Ce n'est qu'un exemple.
Ceci dit, c'est récent. Mais Openoffice est aussi dispo sur Sparc depuis longtemps.
> a) Tout n'est pas dispo en 64bit sur Linux, loin de la
Ouais, il manque flash.
Tout n'est pas dispo en 64 bit sur Linux. Seulement 99,9 %.
> b) Tu me montres la difference des APIs entre 32bit et 64bit sur Windows ? Je t'aides, t'auras du mal.
Ben si tout nickel (au moins autant que Linux), MS-Office en 64 bits ne coûte rien à faire et devrait déjà être là !
Alors pourquoi il n'y a pas de MS-Office en 64 bits alors que depuis Windows NT il y a une version de Windows en 64 bits ?
Si Fedora/OOo (idem pour RHEL le produit commercial avec support et tout) le fait, j'ai énormément de difficulté à comprendre pourquoi Windows ne le fait pas si selon toi il n'y a aucune difficulté. Et notes bien que les moyens de Microsoft n'ont rien à voir avec les moyens ridicules de Red Hat à côté.
> Quand a Office, ben pour la meme raison qu'OpenOffice faut croire...
T'es un peu girouette...
> Ben moi je vais voir http://www.redhat.com/about/presscenter/2005/press_rhel4.htm(...) et je vois qu'ils supportent x86, Itanium, AMD64 et Power.
> Voila, ca fait UN de plus que Windows, c'est a dire aucune difference a peu pres.
Sauf qu'il y a tout dedans. Et pour PowerPPC, c'est 64 bits.
De plus, je n'ai pas souvenir que Windows a une version AMD64 ! J'ai seulement entendu parlé de versions béta et qu'il y a une version AMD64 pour Vista. C'est donc très récent. Quand on connait les moyens de Windows, si tu affirmes qu'il n'y a pas de problème pour MS de fournir du 64 bits, on a un sérieux problème de logique dans ce que tu dis.
Pour info, AMD64 (en vrai 64 bits) est dispo depuis RHEL 3 (avec support et tout et plein de programme). Et pour une version de Linux en 64 bits (avec 99,9% des logiciels) il faut remonter à la nuit des temps.
M'enfin, continu d'affirmer que windows est aussi portable que Linux.
> Windows supporte UTF-16 depuis un moment deja(depuis XP en tout cas), ca fait 6 ans...
Ben je n'ai vu que ucs-2.
> ca fait 6 ans...
Ce qui est du pipo. Windows est passé à ucs-2 avec Windows NT (ou 2000?). Et je dis bien ucs-2 (2^16 caractères) et non utf-8 (2^32 caractères). Windows 2000 utilise ucs-2 (j'en mettrais ma main au feu) et XP n'est qu'une évolution de Windows 2000.
> Par contre plein de boites prennent leur ancien code 16bit et veulent le recompiler en 32bit, et la ca rend les choses bcp plus simples vu qu'ils n'auront quasiment pas a changer leur code.
+1 pour toi. Même si je trouve que c'est de la connerie à moyen/long terme.
> Il n'y a pas de PID pour les threads sous Windows, il y a un thread ID
Oui. Désolé d'avoir dit PID.
> Linux a un Process ID pour des threads, alors que ce sont des threads, pas des process, tu m'expliqueras la logique.
Linux a :
- Process ID pour les thread : c'est le même pour tous les thread d'un processus (normal, tous thread appartient à un processus). Le thread n'a pas cette information directement attaché à lui.
- Thread ID pour chaque thread : Le type n'est pas pid_t mais pthread_t
J'espère que tu vois maintenant la logique évidente.
C'est comme ça pour LinuxThread et NPTL.
Par contre au niveau noyau (chose dont n'a pas à se préoccuper le développeur), les numéros de processus (pid_t) et de thread (pthread_t) sont partagés. Le premier thread d'un processus a pthread_t = pid_t. Pour les autres pthread_t != pid_t (quelque soit le thread et le processus). Mais ça le développeur s'en fout. Si un jour Linux change ça, il n'y aura pas de problème de portabilité (sauf pour les applis codé avec les pieds).
> Pour les APIs multithread, de nouveau, c'est parece que tu ne comprends rien a l'architecture de Windows.
Tu serais gentil d'arrêter de me prendre pour un con.
> Tu fais comment pour attendre sur un event, un timer, la fin d'un thread, ... sous Linux ? Ah oui, des APIs differents, sous Windows, tous ces elements sont des objets, et tu utilises WaitForSingleObject.
+0,1 pour toi. Mais Windows a encore mieux et ça on ne le trouve pas sous Linux :-)
C'est WaitForMultiObject et notamment avec l'option "auto-reset". Avec les mutex c'est intéressant, d'autant plus que c'est atomic. On peut le simuler sous Linux mais ce n'est pas trivial.
> Sous Windows, personne n'utilises le modele "plusieurs processus"
Ce qui est de la connerie. Le modèle "plusieurs processus" a ses avantages et idem pour le multi-threading.
Le gros problème du multi-threading est que le plantage d'un thread fait planter pour le processus. Et c'est la même chose sous Windows.
Alors que Windows fasse un gros processus. Les autres programmes (stockés dans des dll) seront dans des threads. C'est techniquement tout à fait réalisable. Mais dès qu'un truc plante, tout plante. Et il me semble bien que Windows fournit un truc style "job control" pour "mimer" Unix. Les "jobs" sont des processus et non des thread.
Donc ne dit pas que "Sous Windows, personne n'utilises le modele "plusieurs processus"" car c'est absolument faux.
> sous Unix c'est frequent car jusqu'a recemment le support des threads etait a chier
Rires. Tous les Unix commerciaux ont du multi-thread depuis longtemps. Il n'y a que Linux qui a mis du temps car Linux a débuté en 91 (il était embryonnaire). La version 2.0 de Linux avait le multi-thread. Linux 2.0 est sorti quasiment en même temps que Windows 95/NT (en fait Linux l'avait pour la version 1.2.13 mais pas pour 1.2.0). Donc Windows n'a pas le multi-threading depuis plus longtemps que Linux et assurément pas avant les Unix commerciaux. Le seul problème de Linux est que durant assez longtemps il n'avait pas de thread au niveau noyau. C'est-à-dire que ça ne permettait pas de tirer profit des systèmes multi-cpu. Mais sur la bécane de messieur tout le monde on a rarement du multi-cpu (et même sur la majorité des serveurs).
Notons que les gains de performance du multi-thread sur le multi-processus n'est pas énorme (et souvent nul). D'autant plus que créer un processus sous Linux n'est pas cher (fork() ou clone()).
On a vu plusieurs projet forker un projet pour le passer en multi-thread sans qu'il y ait de gain.
> le support des threads etait a chier
C'est-à-dire ? Depuis Linux 2.0 le multi-thread est Posix. Il n'était pas parfaitement Posix mais à 98 % Posix. NTPL l'a rendu 100% Posix (ou 99,9 %). C'est ce qui a permis aux applications Linux de passer rapidement de LinuxThread à NPTL.
Exemple : Il y avait LinuxThead et NPTL dans RHEL 3. Il n'y a que NPTL dans RHEL 4. Pourtant fournir LinuxThread en parallèle n'est pas un problème. Mais porter les applications vers NPTL n'est pas un problème non plus.
Donc si tu dis que le multithread était à chier, il doit l'être encore aujourd'hui selon toi.
L'intérêt de NPTL n'était pas de passer d'un multi-thread à chié à un truc formidable. Mais d'avoir le multi-threading en mode noyau et être plus conforme Posix. C'est tout, bien que la tâche n'a pas été évidente.
NPTL a des avantages significatif dans le cas où on a plus de 50 ou 100 thread. Ça ne conserne pas la majorité des applications, c'est le moins qu'on puisse dire.
> resultat, tout le monde utilise les CRITICAL_SECTION
Je ne vois pas le rapport. Je n'ai pas dit que CRITICAL_SECTION était mauvais. Je parlais de l'API. Relis.
> Un block memoire ? Tu fais ca comment pour avoir un HANDLE sur un block memoire ?
CreateFileMapping() par exemple.
Mais je suis mauvaise langue.
Je me suis trompé.
Il y a (si j'ai bonne mémoire) LocalAlloc qui retourne un HLOCAL et j'ai conclus rapidement qu'un GlobalAlloc retourne un HANDLE alors qu'il retourne un HGLOBAL (si j'ai bonne mémoire).
Retourner un (void *) comme tout le monde ça aurait été trop simple...
> tu peux attendre sur tous ces objets avec le meme API. Bien plus simple que les 32 APIs differents pour faire la meme chose sous Linux.
C'est une façon de voir la chose. Mais il n'y a aucun contrôle de type. Le seul intérêt des HANDLE est le WaitFor*Object(). C'est tout.
De plus WaitForSimgleObject ne marche pas pour tout. Il marche que pour attendre la fin d'un timer, la fin d'un thread, etc. Mais un WaitForSem() qui attend qu'un sémaphore passe à 10 ça n'existe pas.
Vu la contrepartie, je trouve ça sans intérêt. Par contre WaitForMultiObject (ou WaitForMultipleObject ?) c'est cool.
Sous Linux pour attendre la fin d'un thread on fait pthread_join(pthread_t, void **). Ce n'est pas la mer à boire, c'est lisible.
> Oh si on le sait, c'est meme documente, comme tous les autres types : http://msdn2.microsoft.com/en-gb/library/aa383751.aspx
Donc on a des api qui exige spécifiquement du uint32...
Sous Linux on n'a pas ça. On a pid_t qui on une taille qui colle au hardware ou au besoin de la fonction. Mais on ne dit pas qu'un pid_t doit être un uint32. Un jour c'est un int16, un autre c'est un int32, on s'en fout. Il y a toujours des exceptions. Mais tant qu'elles sont rares, ça se gère. Sous Windows l'exception est la règle.
> mais visiblement tu ne lis pas la doc, dans ce cas pas etonnant que tu n'y comprennes rien.
J'en ai lu beaucoup sur Windows ce dernier mois.
> Plutot que dire que c'est pour des conneries, et si tu donnais des exemples ou c'est inutile ?
WTypes.h
Le wchar_t je vois l'intérêt. Le WCHAR pourquoi pas. Mais les LPCWSTR, etc c'est stupide et ça n'améliore pas la lecture du code (il faut connaitre une tripoté de typedef).
Puis selon http://msdn2.microsoft.com/en-gb/library/aa383751.aspx WCHAR c'est :
Donc Windows ne support que ucs-2. Merci d'en faire la démonstration.
Tu me traites de con qui ne sait pas lire la doc. Je bosse sur Windows en tant que développeur depuis 1 mois seulement. Toi ça fait depuis des années et tu ne sais toujours pas que Windows ne supporte que ucs-2 et pas UTF-8. UTF-8 est une façon de coder usc-4 (unicode) et a 2^32 valeurs. Ça ne rentre pas dans du 16 bits. wchar_t sous Linux est dans son implémentation actuelle du 32 bits. wchar_t n'est pas défini comme étant un int32, mais comme étant un wide caractère. Qu'il occupe 8, 16, 24 ou 32 bits, n'est pas une propriété que le développeur doit utiliser ni savoir (sauf pour débuggeur).
Avec la définition qu'a Windows de wchar_t, ça ne va pas être facile de passer à usc-4...
> Tout comme sous Windows, mais ton probleme c'est que tu n'y connais rien et en parles quand meme.
Très bien, fais ce que tu dis et arrêtes de parler du logiciel libre.
Enfin, je tiens à te signalé que j'ai parlé de l'API de Windows après m'être informé. J'en parlais pour expliquer pourquoi "Linux tient tête à Windows" alors que Windows a facilement 100 fois plus de développeur que Linux.
M'enfin, tu as peut-être une autre explication. Les développeurs Linux seraient 100 plus doués que les développeurs Windows ?
Il y a moins d'un mois, je n'aurai rien dit de l'API de Windows et j'en ai rien dit jusqu'à ce que je lise la doc.
Si j'étais un anti-Windows primaire, je n'aurais pas dit que l'API de Direct3D est bien foutue ni que le noyau de Windows offre toutes les fonctionnalités qu'on attend d'un OS moderne.
De plus, j'ai passé sous silence DirectShow alors que ça va devenir mon "coeur de métier". En un mot : lourdingue. Tellement lourdingue que MS fournit une tripoté de classe pour simplifier le développement. Mais comme ces classes ne répondent pas à mon besoin... ça va être lourdingue.
Mais DirectShow est bien moins pire que l'API de Windows. Son historique l'a rendu lourdingue. M'enfin, il n'y a pas vraiment d'équivalent dans le libre. Sauf gstreamer mais ce n'est pas encore ça ; espérons que ça ne tarde pas.
NB : gstreamer est beaucoup plus récent que DirectShow. Je dis ça avec que tu te foutes de gstreamer.
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 1.
Ben non, moi je croyais que tu parlais de parts de marche, pas de chiffres comptables. Qui te dit que les 2 chiffres sont lies chez Redhat ? Ils vendent du JBoss aussi par exemple.
Cherches openoffice, tu le trouveras en 64 bits. Ce n'est qu'un exemple.
Ceci dit, c'est récent. Mais Openoffice est aussi dispo sur Sparc depuis longtemps.
Sparc je sais, mais on parle de Linux ici.
De ce que j'en ai lu, c'est pas tres utilisable, notamment vis a vis de problemes avec Java sur plateforme 64bit.
Ouais, il manque flash.
Tout n'est pas dispo en 64 bit sur Linux. Seulement 99,9 %.
Ah oui ? T'as Quake 64bits ? Flash 64bits ? Acrobat Reader 64bits ? ...
La plupart des softs "grand public" ne sont pas dispo en 64bit sur Linux, et les softs "serveurs" le sont, tout comme sous Windows. Car Oracle, Mathematica, DB2, ... sont dispo en 64bits pour Windows.
Ben si tout nickel (au moins autant que Linux), MS-Office en 64 bits ne coûte rien à faire et devrait déjà être là !
Alors pourquoi il n'y a pas de MS-Office en 64 bits alors que depuis Windows NT il y a une version de Windows en 64 bits ?
Parce qu'OpenOffice 64bit sur Linux n'est pas encore utilisable(cf. problemes Java plus haut), bref, ils en sont au meme point.
Sauf qu'il y a tout dedans. Et pour PowerPPC, c'est 64 bits.
De plus, je n'ai pas souvenir que Windows a une version AMD64 ! J'ai seulement entendu parlé de versions béta et qu'il y a une version AMD64 pour Vista. C'est donc très récent.
C'est dispo au public depuis 2005(XP x64 et WS03 x64), et ca tournait depuis bien plus longtemps en interne.
Ce qui est du pipo. Windows est passé à ucs-2 avec Windows NT (ou 2000?). Et je dis bien ucs-2 (2^16 caractères) et non utf-8 (2^32 caractères). Windows 2000 utilise ucs-2 (j'en mettrais ma main au feu) et XP n'est qu'une évolution de Windows 2000.
Moi je te proposes d'aller lire http://blogs.msdn.com/michkap/archive/2005/05/11/416552.aspx pour comprendre que tu as tort.
J'espère que tu vois maintenant la logique évidente.
C'est comme ça pour LinuxThread et NPTL.
Ca ne date en fait que depuis 2002-2003, j'en parles car j'avais eu le probleme a l'epoque, du code qui fonctionnait parfaitement sur Solaris devait etre trifouille pour tourner sur Linux a cause de cette anerie. C'est une bonne chose qu'ils l'aient corrige, mais ca a pris du temps.
Ce qui est de la connerie. Le modèle "plusieurs processus" a ses avantages et idem pour le multi-threading.
Le gros problème du multi-threading est que le plantage d'un thread fait planter pour le processus. Et c'est la même chose sous Windows.
Tout a fait, mais la ou sur Unix il est habituel d'utiliser des processus simplement pour faire du traitement en parralelle, sous Windows c'est fait avec des threads d'habitude. Il y a bien entendu des cas ou tu utilises des processus separes, mais c'est assez rare.
Et il me semble bien que Windows fournit un truc style "job control" pour "mimer" Unix. Les "jobs" sont des processus et non des thread.
Un job c'est en fait bien plus qu'un processus, c'est un ensemble de processus, sur lesquels tu peux mettre plein de contraintes.
Rires. Tous les Unix commerciaux ont du multi-thread depuis longtemps. Il n'y a que Linux qui a mis du temps car Linux a débuté en 91 (il était embryonnaire). La version 2.0 de Linux avait le multi-thread. Linux 2.0 est sorti quasiment en même temps que Windows 95/NT (en fait Linux l'avait pour la version 1.2.13 mais pas pour 1.2.0). Donc Windows n'a pas le multi-threading depuis plus longtemps que Linux et assurément pas avant les Unix commerciaux.
J'ai melange Unix et Linux, Solaris a toujours eu un tres bon support des threads, ma cible ici c'est Linux qui m'en a fait baver a l'epoque car l'implementation des pthreads jusqu'a recemment etait vraiment a chier(va t'amuser a passer des signaux a des threads avec un Linux de l'epoque, tu comprendras ma douleur)
Sous Linux pour attendre la fin d'un thread on fait pthread_join(pthread_t, void **). Ce n'est pas la mer à boire, c'est lisible.
Tout a fait c'est lisible, le probleme c'est que c'est uniquement pour un thread, il te faut 10 APIs pour faire la meme chose: attendre sur un objet.
Donc on a des api qui exige spécifiquement du uint32...
Sous Linux on n'a pas ça. On a pid_t qui on une taille qui colle au hardware ou au besoin de la fonction. Mais on ne dit pas qu'un pid_t doit être un uint32. Un jour c'est un int16, un autre c'est un int32, on s'en fout. Il y a toujours des exceptions.
Attends tu me fais bien rire, je parles de uint32, qui clairement a ete cree pour representer un entier 32bits et rien d'autres, tout comme il y a un equivalent sous Linux,et tu parles de pid_t, quel rapport ? Jettes un oeil sur les APIs, tu verras plein d'APIs qui utilisent un size_t par exemple(qui varie selon la machine, ...)
difference entre WCHAR/CHAR et LPWSTR/LPCSTR
La difference est pourtant simple, LPWSTR/LPCSTR sont la pour representer une chaine de texte(un pointer sur un array de char quoi), WCHAR/CHAR c'est un caractere, et un pointeur sur WCHAR/CHAR, c'est un pointeur sur un caractere.
Alors meme si au final c'est la meme chose, conceptuellement ca ne l'est pas, tu utilises LPWSTR quand tu veux une chaine de caracteres, et tu utilises WCHAR* quand tu veux un pointeur sur un caractere.
Donc Windows ne support que ucs-2. Merci d'en faire la démonstration.
Va lire la page du dessus et tu comprendras que tu as tort, c'est pas a moi que tu vas apprendre quel character set Windows supporte :+)
Très bien, fais ce que tu dis et arrêtes de parler du logiciel libre.
Le truc est que j'ai passe des annees sur Linux, a une periode meme exclusivement sur Linux, je connais le systeme.
Toi ça fait depuis des années et tu ne sais toujours pas que Windows ne supporte que ucs-2 et pas UTF-8. UTF-8 est une façon de coder usc-4 (unicode) et a 2^32 valeurs. Ça ne rentre pas dans du 16 bits. wchar_t sous Linux est dans son implémentation actuelle du 32 bits. wchar_t n'est pas défini comme étant un int32, mais comme étant un wide caractère. Qu'il occupe 8, 16, 24 ou 32 bits, n'est pas une propriété que le développeur doit utiliser ni savoir (sauf pour débuggeur).
Avec la définition qu'a Windows de wchar_t, ça ne va pas être facile de passer à usc-4...
Ben moi je te propose de relire la doc, et te rendre compte que le fait que WCHAR est 16bit n'y change rien(cf. l'article que je t'ai donne plus haut). De meme que sous Linux que wchar_t soit 16,32 ou autre, si plusieurs caracteres peuvent avoir des tailles differentes, t'es dans la mouise quand tu parses la chaine. Raison pour laquelle il est des APIs specifiques pour ca sur les 2 plateformes.
M'enfin, tu as peut-être une autre explication. Les développeurs Linux seraient 100 plus doués que les développeurs Windows ?
"Tiens tete" sur quoi ? l'OS lui-meme ? On a 100x plus de developpeurs que Linux+KDE+... reunis ? Permets moi d'en douter.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
Ça ne marche pas terrible en vente JBoss, de l'aveu même de Red Hat. M'enfin, je pense que ça va décoller.
> De ce que j'en ai lu, c'est pas tres utilisable, notamment vis a vis de problemes avec Java sur plateforme 64bit.
Ben sous Fedora, le java utilisé en gcj. Donc pas de problème.
> Ah oui ? T'as Quake 64bits ? Flash 64bits ? Acrobat Reader 64bits ? ...
Fichtre, gros problème. Il manque un jeu et deux trucs proprio dont un existe en version libre et marche en 64 bits (xpdf ou evince et probablement d'autres).
NB : je n'ai jamais installé Quake ou Acrobat Reader. Il m'arrive d'avoir Flash (et je ne le garde pas de façon permanente).
Bref, 99,9 % tourne en 64 bits sous Linux.
Tu peux me faire la liste de ce qui ne marche pas sous Windows en 64 bits ?
Ça doit être long...
> La plupart des softs "grand public" ne sont pas dispo en 64bit sur Linux
Et c'est quoi les softs "grand public" qui n'existe pas ?
Il y a Flash et Acrobat Reader. C'est tout. Deux trucs proprio.
> Parce qu'OpenOffice 64bit sur Linux n'est pas encore utilisable
Il est utilisable et utilisé. D'ailleurs RHEL 5 aura openoffice en 64 bits. Red Hat est devenu suicidaire selon toi ?
> bref, ils en sont au meme point.
Non. Un est dispo (pardon pour début mars avec support et tout) et l'autre non. Et n'oublies pas de prendre en compte les moyens de MS ainsi que son volume de vente qui sont sans commune mesure avec Red Hat...
> > > ca fait 6 ans...
> > Windows est passé à ucs-2 avec Windows NT (ou 2000?). Et je dis bien ucs-2 (2^16 caractères) et non utf-8 (2^32 caractères). Windows 2000 utilise ucs-2 (j'en mettrais ma main au feu) et XP n'est qu'une évolution de Windows 2000.
> Moi je te proposes d'aller lire
Ben "ça fait 6 ans..." c'est du pipo. Et ça j'en étais sûr au point d'en mettre ma main au feu.
> Ca ne date en fait que depuis 2002-2003
???
Alors ça m'étonnerai dans les grandes largeurs. Si tous les thread d'un même processus avait le même pthread_t, ça ne marcherait tout simplement pas. Comment tu fais marcher par exemple pthread_join(pthread_t, ...) si tu ne peux pas lui dire quel est le thread que tu attends ?
Ou alors tu parles d'un autre problème. Mais de tout temps chaque thread à son identifiant. C'est obligatoire.
Le plus gros problème de LinuxThread était les signaux. Mais ça avait aussi des avantages. Avec NPTL tu ne peux pas envoyer un signal à un thread spécifiquement (sauf débug et peut-être SIGUSR1 et SIGUSR2). Pour NPTL, la norme Posix a été suivie (ce qui n'a pas été du gout de tout le monde).
> tu utilises LPWSTR quand tu veux une chaine de caracteres, et tu utilises WCHAR* quand tu veux un pointeur sur un caractere.
Je dois reconnaitre que cette subtilité m'a échappé. Quand j'ai commencé à lire du code windows, j'ai pesté contre ces trucs...
> Ben moi je te propose de relire la doc
OK, j'ai lu. Windows XP support UTF-16. Linux c'est généralement UTF-8 pour le stockage dans les fichiers et ucs-4. UTF-8 et UTF-16 n'étant qu'une façon de coder Unicode. Notons qu'à une époque on disant Unicode même pour "seulement" usc-2. Et notes bien que le pointeur sur msdn que tu as donné dit : "Pointer to a null-terminated string of 16-bit Unicode characters".
Ça ne parle pas de UTF-16. UTF-16 n'est pas un "16-bit Unicode characters" (pour info, UTF-8 n'est pas un "8-bit Unicode characters"). UTF-16 peut-être codé de 2 à 6 octets. UTF-8 c'est de 1 à 6.
> Ben moi je te propose de relire la doc
Tu m'as donné un pointeur sur un blog...
Désolé mais je ne considère pas les blogs comme de la doc.
> et te rendre compte que le fait que WCHAR est 16bit n'y change rien
Car c'est du UTF-16 pour XP. Comme on peut utiliser un "char *" pour du UTF-8.
Mais la définition de wchar_t de Windows ne permet pas de passer à usc-4. Windows 2000 étant usc-2, j'ai pensé au vu son API qu'il aurait des problèmes pour passer à usc-4. Ce qui n'est pas faux, mais ce n'est pas un problème puisqu'il y a UTF-16. Désolé, je n'avais pas pensé à UTF-16.
> De meme que sous Linux que wchar_t soit 16,32 ou autre, si plusieurs caracteres peuvent avoir des tailles differentes, t'es dans la mouise quand tu parses la chaine.
Non. Sous Linux le développeur n'est pas sensé connaitre la taille d'un wchar_t. En interne, c'est effectivement codé sur 32 bits (usc-4) sur mon système. Mais ça serait du utf-8, du utf-16, du usc-2, du char, que ça ne changerait rien. La doc de la libc dit que wchar_t est un "wide character" sans préciser si c'est du 8, 16, 32 ou du 48 bits.
La doc de Windows dit qu'un wchar_t est un wide character codé sur 16 bits. Si c'est du UTF-16 alors c'est faux.
La définition de wchar_t dans Linux n'est pas dans /usr/include, mais au niveau du compilateur (par exemple : /usr/lib/gcc/i386-redhat-linux/4.1.1/include/ ).
Avec les définitions de la libc, on peut avoir un système embarqué qui utilise du ansi ou du usc-2 pour économiser de la mémoire sans changer les programmes ni la définition de wchar_t (celle que doit connaitre le développeur et non la définition au niveau du compilateur). Par contre, il faut recompiler.
Pour info, la définition de wchar_t de libc est celle de la ISO C90.
> De meme que sous Linux que wchar_t soit 16,32 ou autre, si plusieurs caracteres peuvent avoir des tailles differentes, t'es dans la mouise quand tu parses la chaine. Raison pour laquelle il est des APIs specifiques pour ca sur les 2 plateformes.
Pas vraiment. Ce n'est pas que la taille soit variable ou différente le problème. Le problème est que par définition sizeof(char) = 1. Alors que par définition sizeof(wchar_t) = inconnu (du moins avec ISO C90 c'est plateforme dépendant comme int par exemple).
De plus tu devrais savoir que Windows offre (ou offrait) des macros pour avoir le même source que l'application soit en ansi ou Unicode :-) (type TCHAR et TEXT et passe de ansi à ucs-2).
> On a 100x plus de developpeurs que Linux+KDE+... reunis ? Permets moi d'en douter.
Microsoft seul, ça prête effectivement à discution. Mais Windows et notamment son noyau n'est pas développé uniquement par MS. Les constructeurs de hardware y participe activement (ce n'est en rien un reproche). Par exemple on sent très bien l'influence des fabriquants de carte graphique dans Direct3D (et ce n'est en rien un reproche).
De plus, il faut s'entendre sur le terme développeur. Pour Linux, les derniers chiffres était de 100 développeurs à plein temps qui font 99 % du code et 1000 contributeurs (proposition, rapport de bug, bench, etc) qui ne sont pas à plein temps. Et c'est 100 développeurs à plein temps qui font aussi les drivers. Je ne pense pas que MS à 1000 développeurs sur le noyau de Windows. Par contre Windows a infiniment plus de développeur des constructeurs de hardware (qui font notamment les drivers) sur le noyau de Windows que sur le noyau Linux. C'est indiscutable. Notons aussi que le noyau Linux est le projet où il y a le plus de développeur à plein temps, et de loins. Linux (le noyau) est le projet le mieux loti.
> l'OS lui-meme ?
OS = noyau (bas niveau)
Ben si tu intégres des drivers, probablement que Windows a 100 fois plus de développeurs que Linux.
Mais compares avec Gnome ou KDE.
Quand je disais qu'il y avait 100 fois plus de développeurs sur Windows que sur Linux, j'entendais tous les développeurs (adobe, etc). Pas seulement ceux de MS.
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 0.
Bref, 99,9 % tourne en 64 bits sous Linux.
Tu peux me faire la liste de ce qui ne marche pas sous Windows en 64 bits ?
Ça doit être long...
D'un cote t'as une bibliotheque de softs plutot petite et principalement serveurs, de l'autre une bibliotheque de softs principalement desktop et enorme, pas tres normal comme comparaison hein.
Des softs non-64bits sous Linux il y en a plein d'autres, RealPlayer, ColdFusion, etc...
Tu remarqueras qu'une app qui existe a la fois sous Linux et Windows et existe en 64bit pour Linux d'habitude existe aussi en 64bit pour Windows
Ben "ça fait 6 ans..." c'est du pipo. Et ça j'en étais sûr au point d'en mettre ma main au feu.
Ben 2007-2001(XP)=6 hein
Alors ça m'étonnerai dans les grandes largeurs. Si tous les thread d'un même processus avait le même pthread_t, ça ne marcherait tout simplement pas. Comment tu fais marcher par exemple pthread_join(pthread_t, ...) si tu ne peux pas lui dire quel est le thread que tu attends ?
Je parlais du PID, pas du pthread_t
Tu m'as donné un pointeur sur un blog...
Désolé mais je ne considère pas les blogs comme de la doc.
Ok, va lire ca alors http://www.microsoft.com/globaldev/handson/dev/winxpintl.msp(...)
Non. Sous Linux le développeur n'est pas sensé connaitre la taille d'un wchar_t. En interne, c'est effectivement codé sur 32 bits (usc-4) sur mon système. Mais ça serait du utf-8, du utf-16, du usc-2, du char, que ça ne changerait rien. La doc de la libc dit que wchar_t est un "wide character" sans préciser si c'est du 8, 16, 32 ou du 48 bits.
La doc de Windows dit qu'un wchar_t est un wide character codé sur 16 bits. Si c'est du UTF-16 alors c'est faux.
Eh si c'est vrai, tout comme pour la libc c'est 32bit. Comme je te le dis, que wchar_t soit 16bit n'y change rien, une chaine de caracteres "internationale" sur les 2 plateformes, elle aura des caracteres qui n'entrent pas dans un wchar_t , resultat, peu importe qu'il soit trop petit de 2,3 ou 4 bytes.
Pas vraiment. Ce n'est pas que la taille soit variable ou différente le problème. Le problème est que par définition sizeof(char) = 1. Alors que par définition sizeof(wchar_t) = inconnu (du moins avec ISO C90 c'est plateforme dépendant comme int par exemple).
C'est jamais inconnu, suffit de faire sizeof(wchar_t) pour le savoir.
De plus tu devrais savoir que Windows offre (ou offrait) des macros pour avoir le même source que l'application soit en ansi ou Unicode :-) (type TCHAR et TEXT et passe de ansi à ucs-2).
Oui, mais ca ne resoud pas le probleme, si tu veux acceder a un caractere dans une chaine Unicode, tu peux pas simplement faire bob[3], ni sur Linux ni sur Windows. Parce que ta chaine, c'est un array de wchar_t(qu'il soit 16 ou 32bit n'y change rien), et que les caracteres de la chaines n'ont peut-etre pas tous la meme taille.
Quand je disais qu'il y avait 100 fois plus de développeurs sur Windows que sur Linux, j'entendais tous les développeurs (adobe, etc). Pas seulement ceux de MS.
Oui mais la tu compares l'incomparable. Linux n'a rien d'equivalent a Photoshop et Illustrator par exemple. Alors qu'on ait 100x plus de developpeurs de cette maniere peut-etre, mais on a aussi bcp plus de softs
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
Mais oui. Sous Fedora (ça doit être la même chose ailleurs mais je les connais moins) c'est plus de 6 Go de source et 8 Go de binaire (Fedora Core + Extras). Tous les logiciels desktop sont aussi en 64 bits (sauf flash, désolé).
Franchement, soit un peu sérieux.
> de l'autre une bibliotheque de softs principalement desktop et enorme
Oui windows à plus de soft. C'est indiscutable. Mais sous Linux c'est 99,9 % qui est dispo en 64 bits et sous Windows c'est ... 50 % (?) voire moins.
> Des softs non-64bits sous Linux il y en a plein d'autres, RealPlayer, ColdFusion, etc...
Tu cites encore du logiciel proprio.
> > Ben "ça fait 6 ans..." c'est du pipo. Et ça j'en étais sûr au point d'en mettre ma main au feu.
>
> Ben 2007-2001(XP)=6 hein
Ben autant pour moins, je ne croyait qu'XP était sortit en 2001 (je n'utilisais pas Windows depuis 97/98). Il me reste à me bruler une main...
> Je parlais du PID, pas du pthread_t
Finalement, je comprend ton problème.
> Ok, va lire ca alors http://www.microsoft.com/globaldev/handson/dev/winxpintl.msp(...)
Cette doc n'est pas dans le SDK.
> C'est jamais inconnu, suffit de faire sizeof(wchar_t) pour le savoir.
Comme sizeof(int) n'est pas inconnu. Mais tu es en train de noyer le poisson. Quand on code, on ne doit pas suposer quelle est la taille d'un int ou alors on est un mauvais codeur qui ne fait que des choses non portable. On ne sait que ça : short >= int >= long && short >= 2 && long >=4 .
Comme la norme C ne dit pas la taille d'un int, la libc ne dit pas la taille d'un wchar_t. Par contre Windows dit qu'elle est la taille d'un wchar_t. Le faisant Windows s'imposer de conserver cette taille.
Pour mon info, comment tu fais pour iswalpha() alors qu'il attend un wchar_t et que celui-ci est de 2 octets sous Windows (selon la définition de Windows) ? Comment tu fais pour passer du 32 bits ?
Sous Linux, c'est n'est pas un problème. Même si Linux stockait wchar_t sur 16 bits, passer iswalpha() en 32 bits (supporter usc-4) n'est pas un problème car la taille de wchar_t n'est pas dans la difinition de wchar_t (comme la taille d'un int n'est pas dans la diffinition d'un int) et donc l'API ne change pas. Pour Windows c'est une autre histoire.
> Oui mais la tu compares l'incomparable.
Ben quand on peut comparer Linux à Windows ? Jamais ?
> Alors qu'on ait 100x plus de developpeurs de cette maniere peut-etre, mais on a aussi bcp plus de softs
+ de softs, donc plus d'expert Windows, plus d'expert qui peuvent contribuer à Windows.
Je parle à un puit sans fond qui fait dans le simplisme quand ça l'arrange.
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 0.
Je te trouves 8Go de softs 64bits Windows sans probleme, c'est pas le probleme.
Oui windows à plus de soft. C'est indiscutable. Mais sous Linux c'est 99,9 % qui est dispo en 64 bits et sous Windows c'est ... 50 % (?) voire moins.
Quand t'as enormement plus de softs, atteindre 99.9%(ce qui n'est pas le cas de Linux qu'on s'entende bien) c'est legerement plus difficile
Tu cites encore du logiciel proprio.
Et ? C'est du soft non ?
Cette doc n'est pas dans le SDK.
Bon va lire ca alors : http://msdn.microsoft.com/library/default.asp?url=/library/e(...) c'est bien dans le sdk la.
Comme la norme C ne dit pas la taille d'un int, la libc ne dit pas la taille d'un wchar_t. Par contre Windows dit qu'elle est la taille d'un wchar_t. Le faisant Windows s'imposer de conserver cette taille.
Euh.... http://linuxpakistan.net/man.php?query=unicode&type=2&am(...) : Under GNU/Linux, the C type wchar_t is a signed 32-bit integer type.
T'appelles ca comment ? Moi j'appelle ca etre documente.
Pour mon info, comment tu fais pour iswalpha() alors qu'il attend un wchar_t et que celui-ci est de 2 octets sous Windows (selon la définition de Windows) ? Comment tu fais pour passer du 32 bits ?
Sous Linux, c'est n'est pas un problème. Même si Linux stockait wchar_t sur 16 bits, passer iswalpha() en 32 bits (supporter usc-4) n'est pas un problème car la taille de wchar_t n'est pas dans la difinition de wchar_t (comme la taille d'un int n'est pas dans la diffinition d'un int) et donc l'API ne change pas. Pour Windows c'est une autre histoire.
Sous windows ces fonctions acceptent un wint_t , pas un wchar_t, et un wint_t est defini la : http://msdn2.microsoft.com/en-us/library/323b6b3k(VS.80).asp(...) : Type of data object that can hold any wide character or wide end-of-file value.
+ de softs, donc plus d'expert Windows, plus d'expert qui peuvent contribuer à Windows.
Bien sur, et tu veux me faire croire que tous les gars qui ecrivent OpenOffice, Firefox, les 200 petits utilitaires d'une distrib contribuent a l'OS lui meme ?
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
> a) separation user / kernel
> b) separation entre users
> c) notion d'administrateur / user avec acces limite
>
> Bref, architecturalement parlant, ils sont quasi-identiques la dessus.
J'avais raté ce grand moment...
Ta description est simpliste. Tellement simpliste que tous les OS multi-utilisateur la respecte.
Mais sous Windows il n'y a qu'une partie du système qui est protégée. Tu peux faire un "rm -r -f /" sous un compte avec Linux, il n'y a que ton compte qui est bousillé. Sous Linux, et n'importe quel OS respectable, c'est l'ensemble du système qui est protégé. L'utilisateur n'a pas un navigateur qui tourne sous le compte administrator comme Windows le fait et te demande s'il peut faire tel ou tel truc dangereux pour le système.
Impact :
Sous Linux on ne demande pas à l'utilisateur :
- voulez-vous faire ce truc dangereux ?
Sous Linux il ne peut pas et point barre.
Sous Linux il n'y a pas qu'un compte admin mais plusieurs. Le compte bin, mail, dbus, ftp, lp, postgres, etc...
Puis ça ne s'arrête pas à l'OS. Firefox/Thunderbird ne supporte pas ActiveX car c'est dangereux. IE/Outlook supporte ActiveX. L'un veut être sûr et l'autre semble s'en foutre royalement. Opera et Firefox n'ont pas de problème de sécurité (mais des bugs qui sont vites corrigés), IE a des problèmes de sécurité au niveau conception. IE a besoin d'un antivirus, les autres non.
J'imagine que tu vas encore dire que Windows est beaucoup plus utilisé que Linux et donc a plus d'attaque, etc...
C'est marrant que l'OS le plus utilisé, qui a le plus de ressource, soit le moins bien foutu niveau sécurité et que les OS les moins utilisés soient les mieux foutu niveau sécurité.
Tu m'expliques ?
Linux propose plein de add-on au système de sécurité par défaut pourtant robuste. Le plus connu est SeLinux. Pour Windows c'est un anti-virus...
Oui, si on est simpliste, Linux et Windows c'est la même chose. Mais si on gratte ça n'a pas grand chose à voir aussi bien technologiquement que par leur approche de la sécurité. Par exemple ne pas avoir d'ActiveX dans un navigeur, ne pas avoir un onglet d'option pour dire à quel niveau de sécurité on navige, etc...
Linux (idem pour Firefox, etc) n'hésite pas à casser la compatibilité s'il y a un problème de sécurité. Windows le fait en dernier recours et s'appuis sur les anti-virus. Anti-virus tellement indispensable de part la conception de l'OS que MS en propose un maintenant... La boucle est bouclée.
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 0.
Tu n'as visiblement aucune idee de la maniere dont Windows fonctionne.
Cree un user normal sous Windows, amuses toi a faire l'equivalent de rm -r -f /, t'auras le meme resultat que sous Linux : rien de perdu a part les fichiers de l'utilisateur
De meme, IE ne demande absolument pas les droits d'admin pour tourner, il tourne tout a fait normalement en user.
Quand a demander si il peut faire tel ou tel truc dangereux pour le systeme, c'est un avertissement si t'es admin, et si t'es user, il te demandera un mot de passe admin
Sous Linux il n'y a pas qu'un compte admin mais plusieurs. Le compte bin, mail, dbus, ftp, lp, postgres, etc...
Et sous Windows t'as les comptes LocalSystem, NetworkService, ....
Puis ça ne s'arrête pas à l'OS. Firefox/Thunderbird ne supporte pas ActiveX car c'est dangereux. IE/Outlook supporte ActiveX.
Quel rapport avec l'OS et son architecture ? Si demain j'ecris un browser qui supporte ActiveX sous Linux, Linux devient mauvais architecturalement ?
C'est marrant que l'OS le plus utilisé, qui a le plus de ressource, soit le moins bien foutu niveau sécurité et que les OS les moins utilisés soient les mieux foutu niveau sécurité.
Tu m'expliques ?
Justement, c'est toi qui interprete mal, l'OS le plus utilise est le plus attaque, ca ne veut absolument pas dire qu'il est le moins fout niveau securite, et rien ne prouve que l'OS le moins utilise soit le mieux foutu.
Linux propose plein de add-on au système de sécurité par défaut pourtant robuste. Le plus connu est SeLinux. Pour Windows c'est un anti-virus...
De nouveau, manque de connaissance total de Windows, il y a plein d'add-ons dispo, que tu ne les connaisses pas ne signifie pas qu'ils n'existent pas.
Par exemple ne pas avoir d'ActiveX dans un navigeur, ne pas avoir un onglet d'option pour dire à quel niveau de sécurité on navige, etc...
ActiveX est inoffensif dans Vista vu qu'IE tourne avec quasi-aucun droits, quand au niveau de securite, IE te le donne, faut mieux regarder.
Linux (idem pour Firefox, etc) n'hésite pas à casser la compatibilité s'il y a un problème de sécurité. Windows le fait en dernier recours et s'appuis sur les anti-virus. Anti-virus tellement indispensable de part la conception de l'OS que MS en propose un maintenant... La boucle est bouclée.
J'attends une explication sur quels problemes de securite dans _WINDOWS_ demandent un anti-virus, et en passant, MS ne donne pas d'anti-virus avec l'OS, c'est un achat separe pour ceux qui en veulent, ce n'est nullement necessaire.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
Admettons mais j'en doute puissament.
> Quel rapport avec l'OS et son architecture ? Si demain j'ecris un browser qui supporte ActiveX sous Linux, Linux devient mauvais architecturalement ?
Essais de proposer un brower avec ActiveX. Aucune distribution le fournira (sauf si MS fait une distribution Linux...).
> Justement, c'est toi qui interprete mal, l'OS le plus utilise est le plus attaque, ca ne veut absolument pas dire qu'il est le moins fout niveau securite, et rien ne prouve que l'OS le moins utilise soit le mieux foutu.
Dans les OS "le moins utilisé" il y a Mac. Ben Mac a peu de soucis de sécurité. Puis de tout manière dans quelque années Linux sera très utilisé (10 %) et on verra que cette esplication avec la popularité de Windows est du flan. A 10 % tu va dire que ce n'est pas assez. Ben on attendra que Linux soit à 90 % et ça sera encore le cas. Linux ne sera pas la catastrophe Windows (à 0,1 % de popularité comme à 99,9 %).
Si Windows était un OS "super secure" comme le dit la propagande, pourquoi il supporte si mal sa "popularité" ?
Si Linux est si naze, pourquoi dans la pratique il est si "secure" ?
Tu ne pourrais pas faire un petit virus pour Linux ou cracker Linux histoire de démontrer que linux n'est pas "secure". Un truc qui fait du bruit. Et si ce n'est toi, pourquoi pas un autre fan de Windows ?
Il parait que beaucoup de cracker Windows tourne sous Linux. Pourquoi pas l'inverse ? Et pourquoi il n'y a pas l'inverse ?
Beaucoup de gens détestent Windows. Mais comme il y a beaucoup d'utilisateur de Windows, on peut penser qu'il y a beaucoup de fan de Windows. Je me trompe ?
> Et sous Windows t'as les comptes LocalSystem, NetworkService, ....
Et le compte Service. Je crois que tu as avoir du mal pour en trouver d'autres.
> De nouveau, manque de connaissance total de Windows, il y a plein d'add-ons dispo
Par exemple ?
Je ne parle pas d'outil d'audit. Je parle d'add-on actif (comme SeLinux).
> ActiveX est inoffensif dans Vista
Il aura fallu attentre VIsta... Des années.
M'enfin, méfiance, à la sortie d'XP, XP était "secure" selon MS et résolvait tous les problèmes de sécurité des versions précédentes de Windows. L'histoire a jugé, et XP était naze.
> vu qu'IE tourne avec quasi-aucun droits
Tiens maintenant il "tourne avec quasi-aucun droits" alors que plus haut c'était sans aucun droit...
> quand au niveau de securite, IE te le donne, faut mieux regarder.
Non seulement il te le donne, mais tu peux aussi le changer. Que du bonheur...
> J'attends une explication sur quels problemes de securite dans _WINDOWS_ demandent un anti-virus, et en passant, MS ne donne pas d'anti-virus avec l'OS, c'est un achat separe pour ceux qui en veulent, ce n'est nullement necessaire.
Si ce n'est pas nécessaire, c'est alors une arnaque. Rires^W heu non, ce n'est pas rigolo. Microsoft arnaque les gens en vendant un antivirus.
Au fait, ce n'est pas MS qui fait tout pour qu'on ne puisse pas retirer IE du système ? IE qui est installé avec _WINDOWS_. Ce n'est pas MS qui clame haut et fort que IE fait parti intégrante de l'OS de _WINDOWS_ ?
Oui et oui. J'y peux rien, c'est MS qui le dit.
Au fait, ce n'est pas Windows lui même qui te conseil d'installer un anti-virus ?
Oui, le "Security Center" de _WINDOWS_, même quand je n'ai installé que _WINDOWS_, me le conseil ! Idem s'il n'y a que du Microsoft certified Geniune, etc, _WINDOWS_ me conseille d'installer un antivirus (sinon je met en péril mon système (dexit Windows)).
C'est n'est pas MS-Office (ou Acroreader, etc...) qui me conseille d'installer un anti-virus, c'est _WINDOWS_.
Un truc rigolo (limité à microsoft.com):
http://www.google.fr/search?hl=fr&q=site%3Amicrosoft.com(...)
38 000 pages avec "antivirus" !
Un autre truc rigolo (limité à redhat.com) :
http://www.google.fr/search?hl=fr&q=site%3Aredhat.com+an(...)
5 430 pages avec "antivirus" ! Mais je te laisse regarder les pages. Ça parle quasi exclusivement d'antivirus pour Windows... et rien pour Linux.
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 1.
C'est pas complique, tu prends un windows, tu ajoutes un user limite, tu lances IE, ca prend 10 secondes a essayer. Maintenant, si tu ne sais meme pas ca, il est clair que tu ne connais rien a Windows et que t'as encore enormement a apprendre sur Windows mon cher.
C'est un peu comme si qq'un te disait "Linux a une interface graphique ? Admettons mais j'en doute puissament"
Essais de proposer un brower avec ActiveX. Aucune distribution le fournira (sauf si MS fait une distribution Linux...).
Je te demandes pas si les distrib l'acceptent, je te demandes si ca a un rapport avec l'architecture de l'OS. Si un probleme dans IE sur Windows rend Windows architecturalement mauvais, donc n'importe qui pourrait transformer Linux en merde architecturale simplement en ecrivant un browser qui supporte ActiveX non ? Ou alors ca veut dire qu'une appli n'influe pas sur l'architecture de l'OS....
Dans les OS "le moins utilisé" il y a Mac. Ben Mac a peu de soucis de sécurité.
Ben faut mieux regarder, ils ont tout un tas de failles de securite eux aussi.
Si Windows était un OS "super secure" comme le dit la propagande, pourquoi il supporte si mal sa "popularité" ?
Si Linux est si naze, pourquoi dans la pratique il est si "secure" ?
J'ai jamais dit que Windows etait "super secure",, quand a Linux en pratique il n'est pas si "secure" non plus, il evite simplement tous les malware et autres car les geeks sous Linux savent qu'il ne faut pas ouvrire tout et n'importe quoi.
Tu ne pourrais pas faire un petit virus pour Linux ou cracker Linux histoire de démontrer que linux n'est pas "secure". Un truc qui fait du bruit. Et si ce n'est toi, pourquoi pas un autre fan de Windows ?
Le jour ou tu m'expliqueras en quoi un virus qui :
- Utilises une faille du lecteur de mail pour executer du code sur le systeme
- Lit l'addresse book du lecteur de mail
- S'envoie lui meme a tous les contacts
- S'installe dans les scripts d'init / headers ELF des executables presents dans le compte de l'utilisateur
n'est pas realisable sous Linux j'y penserai, d'ici la ce sera du temps perdu vu que c'est clairement realisable.
Il parait que beaucoup de cracker Windows tourne sous Linux. Pourquoi pas l'inverse ? Et pourquoi il n'y a pas l'inverse ?
Beaucoup de gens détestent Windows. Mais comme il y a beaucoup d'utilisateur de Windows, on peut penser qu'il y a beaucoup de fan de Windows. Je me trompe ?
John Carmack tourne sous Windows, pourtant il ecrit aussi des softs sous Linux, mais il tourne sous Windows, il compte lui ?
Quand aux fans de Windows, sachant que la beta de Vista a ete downloadee par des _millions_ de gens, faut croire qu'il y a plein de gens qui sont interesses par Windows.
Et le compte Service. Je crois que tu as avoir du mal pour en trouver d'autres.
Et ? Il y a un minimum syndical a respecter pour etre considere secure ? Ces comptes sous Linux ont des privileges differents d'un user normal ? Non. Sous Windows ? Eh dingue, LocalService ne peut _pas_ acceder au reseau. Et la plupart des services s'enlevent automatiquement encore plus de privileges quand ils demarrent.
De nouveau, tu ne sais pas du tout ce que le systeme de privileges represente dans Windows
Par exemple ?
Je ne parle pas d'outil d'audit. Je parle d'add-on actif (comme SeLinux).
Au hasard tu peux donner ton propre systeme d'authentification(qui permet de faire authentification biometrique, smart card, ... ou n'importe quoi auquel tu pourrais penser)
Tiens maintenant il "tourne avec quasi-aucun droits" alors que plus haut c'était sans aucun droit...
Parce qu'encore une fois tu ne sais pas du tout comment IE7 fonctionne dans Vista, donc tu presumes, et tu presumes mal.
Sous Linux, si il y a une faille dans Firefox, l'exploit peut acceder a tout ce que le compte sous lequel Firefox tourne peut acceder.
Sous Windows, identique pour Firefox, IE7 par contre, il ne peut acceder a rien a part le repertoire cache, et un autre repertoire je crois.
Bref, IE7 quand il tourne sous les droits d'un user, a des droits encore plus limites que cet user.
Non seulement il te le donne, mais tu peux aussi le changer. Que du bonheur...
Tu m'expliqueras comment faire, je suis interesse
Si ce n'est pas nécessaire, c'est alors une arnaque. Rires^W heu non, ce n'est pas rigolo. Microsoft arnaque les gens en vendant un antivirus.
Donc tout ce qui n'est pas _necessaire_ est une arnaque ? Ta montre est une arnaque? Non c'est bien ce que je pensais.
Ta montre tu l'as achetee car _tu_ n'es pas capable de savoir l'heure qu'il est sans elle.
Un anti-virus tu l'achetes car tu n'es pas capable de savoir si il est sur de lancer cet executable inconnu qu'un site web te propose.
Au fait, ce n'est pas MS qui fait tout pour qu'on ne puisse pas retirer IE du système ? IE qui est installé avec _WINDOWS_. Ce n'est pas MS qui clame haut et fort que IE fait parti intégrante de l'OS de _WINDOWS_ ?
Oui et oui. J'y peux rien, c'est MS qui le dit.
Super, si il faut croire tout ce que MS dit, donc tu es d'accord que Linux c'est de la merde ? Ah non, on dirait que tu es selectif dans ce que tu crois.
Au fait, ce n'est pas Windows lui même qui te conseil d'installer un anti-virus ?
Vu que Windows est utilise par des gens ne connaissant rien a l'informatique et susceptible de lancer tout et n'importe quoi oui.
Maintenant je serais ravi que tu me prouves, car tu ne l'as toujours pas fait, la difference architecturale entre Windows et Linux qui fait qu'un anti-virus est _necessaire_ sur l'un et pas l'autre.
Je veux pas des "mais si xxx a tant de problemes et pas yyy, alors c'est que c'est vrai", je veux une reponse argumentee avec des elements techniques.
430 pages avec "antivirus" ! Mais je te laisse regarder les pages. Ça parle quasi exclusivement d'antivirus pour Windows... et rien pour Linux.
Normal vu qu'un anti-virus est utile pour proteger un neuneu contre lui-meme(lancement de softs pourris, ...), et vu que les neuneus sont a 99% sous Windows et 1% sous Linux...
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
>
> Ben faut mieux regarder, ils ont tout un tas de failles de securite eux aussi.
Des trous de sécurité qui ont coûté des milliards comme Windows ?
Me fais pas rire. Et rapporte aussi au nombre de poste (à la popularité), Mac n'est pas la catastrophe Windows.
> Au hasard tu peux donner ton propre systeme d'authentification(qui permet de faire authentification biometrique, smart card, ... ou n'importe quoi auquel tu pourrais penser)
Oui, ça existe sous Linux. Je n'en suis pas fan. RHEL le fournit.
Alors que je te demande un add-on équivalent de SeLinux, tu réponds répond par ce qui pourrait être un module PAM.
> IE7 par contre, il ne peut acceder a rien a part le repertoire cache, et un autre repertoire je crois.
Ben tant mieux si MS se met enfin à faire des trucs sûrs.
> > Non seulement il te le donne, mais tu peux aussi le changer. Que du bonheur...
>
> Tu m'expliqueras comment faire, je suis interesse
Menu : Tools | Internet Options...
Onglet : Sécurité.
> Donc tout ce qui n'est pas _necessaire_ est une arnaque ? Ta montre est une arnaque? Non c'est bien ce que je pensais.
Tu achètes un antivirus pour faire joli ? Pour écouter de la musique ?
Pourquoi pas, si c'est joli et que la musique est bonne.
Pourquoi tu achetes un antivirus au fait ?
Car c'est utile/nécessaire ou pour faire joli ?
> Un anti-virus tu l'achetes car tu n'es pas capable de savoir si il est sur de lancer cet executable inconnu qu'un site web te propose.
La bonne excuse...
Les virus qui ont coûté des milliards à l'industrie et ont foutu la panique jusqu'à passer au 20 h de tf1 et en boucle sur france info, c'est car les gens downloade explicitement un programme et le lance explicitement.
Mais oui...
> Vu que Windows est utilise par des gens ne connaissant rien a l'informatique et susceptible de lancer tout et n'importe quoi oui.
L'utilisateur de Windows a besoin d'un BigBrother. L'utilisateur de Windows est un con qui lance tout et n'importe quoi.
> Maintenant je serais ravi que tu me prouves, car tu ne l'as toujours pas fait, la difference architecturale entre Windows et Linux qui fait qu'un anti-virus est _necessaire_ sur l'un et pas l'autre.
En simpliant tout à l'extrème comme tu le fais, alors oui "la difference architecturale entre Windows et Linux" est nulle.
Mais à part la popularité de Windows, tu n'as pas avancé l'ombre d'un embroyon d'explication sur le FAIT que Windows a coûté des milliards en virus et attaques en tout genre, ni que Windows a besoin d'un antivirus (à part dire que les utilisateurs de Windows sont des cons contrairement aux utilisateurs de Linux (merci pour ces derniers)).
Quand Linux sera populaire (20 % des postes) et qu'il aura pas d'antivirus ni de problèmes qui coûtent des milliards, je serais très curieux de voir ton explication. Je sens qu'il va falloir se contenter d'un "Windows n'a eu de chance".
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
Dommage que l'antivirus n'ait rien vu...
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 0.
Bref, si tu sais ce que tu installes(comme n'importe quel geek on le sait nous, mais pas le grand public), pas besoin d'anti-virus.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
Ouaip, et comme par hazard, ça tombe sur un produit MS.
Tu me dis comme tu fais ça avec Linux/Firefox ?
Firefox n'exécute pas les programmes qu'il voit. Au mieux (ou au pire) on peut les downloader. C'est tout.
Firefox a fait ce choix de sécurité, MS se le refuse. Mais continu de dire que MS fait tout comme tout le monde au niveau sécurité.
Et tu m'expliques comment fait ce programme pour s'installer ? Je ne comprend pas. Firefox n'installe pas de programme (et il ne fait pas de exec() d'un programme qu'il vient de downloader).
Ce qui est possible avec les produits MS n'est pas possible, pardon, ne se voit pas avec les logiciels libres.
> bref, l'utilisateur installe sciemment ce soft, il ne passe pas par un faille du systeme, la faille ici est sur la chaise.
Pour ton info, le programme s'installe aussi si l'utilisateur clique sur "cancel" (relis l'article). Alors ton "l'utilisateur installe sciemment ce soft", il est de trop.
Mais comment tu fais ça avec Linux/Firefox par exemple ?
Au "mieu" tu downloades le programme.
Et après comment tu fais pour le lancer ?
Si c'est via nautilus, tu ne peux pas car le programme ne sera pas dans le $PATH (à moins de le déplacer dans $HOME/bin).
De plus il faut ajouter les droits d'exécutions (Firefox ne sauvegarde JAMAIS avec les droits d'exécution).
Donc il faut utiliser le shell (ce qui n'est pas pour un utilisateur neuneu).
Mais maintenant, comment tu fais pour installer le programme ?
Pour que le prompt demandant le mot de passe root s'affiche automatiquement il faut :
1- que le programme soit connu de console-helper (ce qui ici n'est forcément pas le cas).
2- que le programme soit en fait un rpm ou un deb (donc ça lance l'outil d'installation).
Dans le cas 2, le programme ne sera pas installé car il n'est pas une signature connue (par défaut l'installeur n'installe que des programmes signé).
Donc il faut passer par le compte root et la ligne de commande pour utiliser rpm ou dpkg.
Ce qui est facile avec les produits MS, est beaucoup plus compliqué avec Linux/Firefox. Et ce n'est pas un hazard. C'est intentionnel du côté de MS et c'est intentionnel du côté de Linux/Firefox.
Mais tu ne veux pas voir cette différence qui fait tout et saute aux yeux.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
Pour ton info, ce n'est pas l'OS, c'est le malware ici.
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 0.
Me fais pas rire. Et rapporte aussi au nombre de poste (à la popularité), Mac n'est pas la catastrophe Windows.
Voyons, Mac fait quoi, 3% du marche ? Ca fait ~32 fois moins que Windows.
http://secunia.com/product/96/ 99 vulnerabilites
http://secunia.com/product/1173/ 119 vulnerabilites
(les 2 sont sortis en 2003 si je ne me trompes)
Je te proposes aussi d'aller lire http://www.viruslist.com/en/analysis?pubid=191968025 pour te rendre compte que les worms, ca touche aussi les Unix.
Menu : Tools | Internet Options...
Onglet : Sécurité.
Genial, t'es en train de me dire que ca prend une action volontaire de l'utilisateur. Moi je te demandes comment un site web peut changer ca sans que l'utilisateur s'en rende compte.
Parce que changer ca par une action de l'utilisateur, je te fais ca avec n'importe quel browser.
Pourquoi tu achetes un antivirus au fait ?
Car c'est utile/nécessaire ou pour faire joli ?
Dans mon cas je n'en achetes pas, car ca ne m'est pas necessaire, donc je peux pas te repondre.
Les virus qui ont coûté des milliards à l'industrie et ont foutu la panique jusqu'à passer au 20 h de tf1 et en boucle sur france info, c'est car les gens downloade explicitement un programme et le lance explicitement.
Ca c'est l'autre utilite d'un anti-virus, detecter un process qui est connu comme etant "mauvais" qui tourne.
Tu crois que ca serait utile sous Unix de detecter un processus/script connu comme etant "mauvais" quand il se lance ? A mon avis tous les gens qui ne tiennent pas a jour leur machine(car ils ne savent pas qu'il faut le faire, comment, ...) en auraient une utilite pour esperer que l'anti-virus chope un exploit qui passerait par une faille non-patchee tu crois pas ?
L'utilisateur de Windows a besoin d'un BigBrother. L'utilisateur de Windows est un con qui lance tout et n'importe quoi.
J'ai dit nulle part qu'il etait con, je dis qu'en general il ne comprend pas forcement ce qui se passe sur sa machine, tout comme je ne comprends quasiment rien a ce que fait ma voiture. C'est une question de competence et interet.
Mais à part la popularité de Windows, tu n'as pas avancé l'ombre d'un embroyon d'explication sur le FAIT que Windows a coûté des milliards en virus et attaques en tout genre, ni que Windows a besoin d'un antivirus
A) T'as pas besoin d'anti-virus si tu sais ce tu fais, je n'ai pas d'anti-virus par exemple
B) C'est simple, l'explication est que la plateforme dominante est toujours la plus visee, et qu'evidemment infecter 3'000'000 de machines va faire plus de degats qu'en infecter 2'000.
Et je te rappelles que 3'000'000 de machines infectees, c'est genre 1-2% des machines Windows installees. C'est une part minuscule des machines qui a ete infecte, mais a cet echelle c'est enorme.
Toi par contre, tu n'as toujours pas donne d'argument technique expliquant pourquoi Linux serait insensible aux virus et Windows le serait.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
>
> http://secunia.com/product/1173/ 119 vulnerabilites
>
> (les 2 sont sortis en 2003 si je ne me trompes)
Mouaif...
Et sous Linux des trous de sécurité il y en a un paquet par semaine.
Pour la semaine dernière :
http://lwn.net/Articles/221244/
Ça ne veut pas dire que Linux est une daube. Red Hat avait fait une très bonne réponse quand MS a lancé un FUD à propos de ça. Malheureusement je n'ai plus le lien.
> Je te proposes aussi d'aller lire http://www.viruslist.com/en/analysis?pubid=191968025 pour te rendre compte que les worms, ca touche aussi les Unix.
Soyons claire, Unix peut avoir des virus "à la Windows" si la sécurité d'Unix est traité "à la Windows".
Si tu veux me faire dire ça, n'insiste pas, je le sais.
C'est pour ça que j'ai insister sur l'*approche* d'Unix (et du logiciel libre en particulier) sur la sécurité.
Tu peux avoir un super noyau avec SeLinux, etc mais si tu installes IE qui autorise ActiveX, c'est une catastrophe.
Au boulot j'utilise Windows avec Firefox et Thunderbird. Au niveau sécurité ça va. Windows avec Firefox/Thunderbird est meilleur au niveau sécurité que Linux avec IE/Outlook.
> Genial, t'es en train de me dire que ca prend une action volontaire de l'utilisateur.
Oui, et c'est important. Sous Firefox je n'ai pas l'option : fait de mon navigateur une niche à virus.
> Moi je te demandes comment un site web peut changer ca sans que l'utilisateur s'en rende compte.
Tu n'y es pas. Si j'ose, je dirais que tu n'y comprends rien.
Firefox ne propose pas ActiveX, ce n'est pas pour rien, ce n'est pas afin d'éviter de coder une option pour désactiver ActiveX. Et le fait de pouvoir désactiver ActiveX n'est pas une solution. Les gens activerons toujours ActiveX car ça permet d'avoir des bidules rigolos. Firefox fait fi de ces bidules au profit de la sécurité. IE ne fait pas ce choix. IE laisse une place aux bidules dangereux.
Tu dis que les utilisateurs sont neuneux mais tu trouves normal qu'on laisse les utilisateurs neuneux faire de leur navigateur une passoire.
Tu m'expliques ta logique ?
Moi, je ne l'a voit pas.
Tu dis que les utilisateurs sont irresponsables et c'est pour ça qu'il faut un anti-virus. Mais tu en appelles à la responsabilité de l'utilisateur en les laissant jouer avec le niveau de sécurité du navigateur.
Tu m'expliques ta logique ?
Windows => Plein de popup pour demander à l'utilisateur s'il veut activer tel ou tel truc dangereux.
Linux => Rien (sauf à l'installation pour le fireware et selinux).
Pour Linux, et le libre en général, l'OS n'a pas à proposer des trucs dangereux et surtout n'a pas à promouvoir des pratiques dangereuses. Sinon les développeurs les utilisent, beaucoup pour faire des trucs rigolos avec ActiveX et du coup tout le monde autorise ActiveX, et quelques un pour faire des virus (d'autant plus efficace qu'il y a beaucoup de développeurs qui font des trucs rigolos avec ActiveX).
Linux fait en sorte que l'utilisateur ne soit jamais sous le compte root (ou du moins n'en éprouve pas le besoin), sous Windows c'est une autre histoire et beaucoup sont sous le compte Administrator. Développeur sous XP avec un compte classique est une peine terrible.
Alors t'as beau dire en étant simpliste que l'architecture de Windows est proche de Linux, l'approche au niveau sécurité n'a rien à voir. C'est un fait.
L'approche sécurité de Windows est une catastrophe. Heureusement, mais avec une lenteur fabuleuse, Windows se rapproche de la philosophie d'Unix.
> Parce que changer ca par une action de l'utilisateur, je te fais ca avec n'importe quel browser.
Ben non. Sous Firefox il n'y a pas d'options liées à la sécurité (sauf pour indiquer quel sont les sites https de confiance, etc...). Mais sous Firefox il n'y a pas l'option : "ActiveX qui fait des ravages au niveau sécurité".
> Ca c'est l'autre utilite d'un anti-virus, detecter un process qui est connu comme etant "mauvais" qui tourne.
Ben le mieux c'est de faire en sorte qu'il ne soit pas là. C'est ce que s'efforce de faire Linux, c'est ce que fait plus ou moins maintenant Windows.
> A mon avis tous les gens qui ne tiennent pas a jour leur machine(car ils ne savent pas qu'il faut le faire, comment, ...)
Ben au-lieu de faire de la pub aux anti-virus, ne faisons que de la pub pour les mises à jours. La politique "j'ai un système pourri mais sous le contrôle d'un antivirus" sucks et quelque soit la qualité de l'antivirus. La longue tradition d'avoir des antivirus sous Windows le démontre très clairement.
Tous les systèmes Linux connectés à Internet font les mises à jours automatiquement (ou demande un ou deux cliques à l'utilisateur pour confirmer). Il n'y a rien de compliqué ici.
Tous ce qui est installé est signé/authentifié. Si l'utilisateur tombe sur un mirroir qui a été cracké, les paquets ne sont pas installés.
Par bêtise/erreur, une fois Red Hat a poussé des paquets non-signés et ça gueulé. Un peu trop fort à mon gout car ça n'a pas de conséquence (les paquets ne sont pas installés et des mises à jours signés ont été vite mise à disposition) mais ça a gueulé de façon tout à fait justifié.
> en auraient une utilite pour esperer que l'anti-virus chope un exploit qui passerait par une faille non-patchee tu crois pas ?
Ce principe sucks.
Sur le papier c'est mignon, c'est un plus, mais ça sucks.
Tu me fais penser à ça : http://linuxfr.org/2006/05/15/20813.html
En gros ça dit : Si le système est pourri, alors telle "faille" est exploitable.
Si le système est pourri, effectivement il faut un antivirus. Mais ça sucks. Un système pourri est un système pourri et un antivirus n'y changera rien. On ne compte pas le nombre de système avec un antivirus qui se sont fait "baisés".
> A) T'as pas besoin d'anti-virus si tu sais ce tu fais, je n'ai pas d'anti-virus par exemple
=> s'appuis sur la responsabilité de l'utilisateur qui est un neuneu selon toi
> B) C'est simple, l'explication est que la plateforme dominante est toujours la plus visee
OUI, mais ça c'est simpliste comme explication. Si un OS a par exemple 10 failles, que cet OS ait 10 utilisateurs ou 10 millions d'utilisateurs, il a toujours 10 failles et pas 10 millions de failles. Si t'as 10 millions d'utilisateurs, ça va vite pour identifier/exploiter les 10 failles et donc les corrigers. Si t'as une poignée d'utilisateurs, c'est beaucoup plus long.
Un contre exemple de ton explication est Linux. Linux demande des utilisateurs pour tester, demande des gens pour auditer l'OS, pour chercher des failles. Plus Linux a d'utilisateurs et plus Linux est sûr. L'inverse est tout simplement faux.
> et qu'evidemment infecter 3'000'000 de machines va faire plus de degats qu'en infecter 2'000.
La tu es sur le problème des virus. MS a fait de Windows une plateforme pour virus. OK avec le temps MS corrige ça. M'enfin, il reste encore du taff...
> Toi par contre, tu n'as toujours pas donne d'argument technique expliquant pourquoi Linux serait insensible aux virus et Windows le serait.
Je n'ai jamais dit que Linux était insensible au virus. Si Firefox se met a foutre des conneries type ActiveX, Linux sera dans la même merde que Windows.
Linux (et les logiciels qui l'acompagne) n'a pas de virus, n'est pas une plateforme pour les virus.
Notes comme Firefox est maintenant populaire (probablement autant utilisé que feu IE 4/5) et comme il a peu de problème de sécurité/virus.
Tu m'expliques ça ?
Si Firefox monte à 50 % d'utilisateur, comme tu vas expliquer que Firefox est sûr (globalement, il y aura toujours des épisodes avec un trou de sécurité, etc) et IE n'est/était pas sûr ?
Comment tu vas expliquer que IE a coûté des milliards avec ses virus et Firefox pratiquement rien ?
Qu'es-ce que tu vas trouver comme explication ?
Que IE n'a pas eu de chance... ?
Et quand MS fera des OS qui ne sont pas des plateformes à virus (et je pense qu'un jours ça arrivera), que ces OS ne couterons plus des milliards en trou de sécurité, comment tu vas expliquer ça ?
Tu vas dire qu'aujourd'hui on peut faire des OS qui ne sont pas des plateformes à virus mais qu'hier c'était impossible alors que Linux et le logiciel libre a toujours voulu et clamé être une plateforme qui ne favorise pas les virus.
Pourquoi tu m'"emmerdes" avec les améliorations au niveau sécurité d'IE pour Vista alors que tu n'arrêtes pas de dire que les risques que encours un utilisateur sont liés uniquement à la popularité de l'OS ?
Pourquoi MS se fait chier à améliorer son OS au niveau sécurité alors que tu n'arrêtes pas de dire que l'insécurité d'un OS est lié uniquement à sa popularité ?
Ton raisonnement ne tient pas debout deux secondes.
[^] # Re: Re:
Posté par pasBill pasGates . Évalué à 0.
Mais justement, j'ai jamais dit que Linux etait une daube personnellement, la difference c'est que je ne considere pas non plus Windows comme une daube.
C'est pour ça que j'ai insister sur l'*approche* d'Unix (et du logiciel libre en particulier) sur la sécurité.
Tu peux avoir un super noyau avec SeLinux, etc mais si tu installes IE qui autorise ActiveX, c'est une catastrophe.
Au boulot j'utilise Windows avec Firefox et Thunderbird. Au niveau sécurité ça va. Windows avec Firefox/Thunderbird est meilleur au niveau sécurité que Linux avec IE/Outlook.
Voila, sur le cote SeLinux+IE = Windows+IE on est d'accord.
Tu dis que les utilisateurs sont irresponsables et c'est pour ça qu'il faut un anti-virus. Mais tu en appelles à la responsabilité de l'utilisateur en les laissant jouer avec le niveau de sécurité du navigateur.
Tu m'expliques ta logique ?
Mais la logique est simple pourtant :
La plupart des utilisateurs n'y comprennent rien, ils ne vont donc rien changer a la config par defaut(qui elle est sure), car ils ne comprendront pas ce que sont ces options ,et si tu les changes, tu chopes un warning si je ne me trompes pas.
Le gars qui a vraiment envie de se tirer une balle dans le pied par contre et qui change les security settings, pourquoi on l'empecherait(surtout que dans certains cas c'est utile) ? Il me semblait que l'utilisateur etait sense etre maitre de sa machine pourtant.
Windows => Plein de popup pour demander à l'utilisateur s'il veut activer tel ou tel truc dangereux.
Linux => Rien (sauf à l'installation pour le fireware et selinux).
Plein ? Il y en a pour les ActiveX(et c'est pas un pop-up mais une barre en haut de la page) et softs que tu lances depuis le web, quoi d'autre ?
Linux fait en sorte que l'utilisateur ne soit jamais sous le compte root (ou du moins n'en éprouve pas le besoin), sous Windows c'est une autre histoire et beaucoup sont sous le compte Administrator. Développeur sous XP avec un compte classique est une peine terrible.
Plein de gens y arrivent pourtant.
L'approche sécurité de Windows est une catastrophe. Heureusement, mais avec une lenteur fabuleuse, Windows se rapproche de la philosophie d'Unix.
Windows lui-meme n'a aucune difference, tu contineus a melanger IE avec l'OS, si j'installes Firefox sur Windows, elle est ou la difference ?
Ben au-lieu de faire de la pub aux anti-virus, ne faisons que de la pub pour les mises à jours. La politique "j'ai un système pourri mais sous le contrôle d'un antivirus" sucks et quelque soit la qualité de l'antivirus. La longue tradition d'avoir des antivirus sous Windows le démontre très clairement.
Tous les systèmes Linux connectés à Internet font les mises à jours automatiquement (ou demande un ou deux cliques à l'utilisateur pour confirmer). Il n'y a rien de compliqué ici.
Ben tu vois, Windows aussi installe les updates automatiquement, le truc triste c'est que certains stoppent ca pour des raisons idiotes, et la pub pour les mises a jours, on le fait mais bonne chance pour convaincre tout le monde.
Ton probleme, c'est qu'en tant que geek tu ne te rends pas compte de la quantite de conneries qu'un newbie peut faire avec une machine, c'est assez effarant.
En gros ça dit : Si le système est pourri, alors telle "faille" est exploitable.
Si le système est pourri, effectivement il faut un antivirus. Mais ça sucks. Un système pourri est un système pourri et un antivirus n'y changera rien. On ne compte pas le nombre de système avec un antivirus qui se sont fait "baisés".
Si le systeme a une faille et l'anti-virus choppe l'exploit, c'est utile.
Un IDS c'est quoi ? Intrusion DETECTION system, bref, l'intrus est deja dedans, c'est utile ?
OUI, mais ça c'est simpliste comme explication. Si un OS a par exemple 10 failles, que cet OS ait 10 utilisateurs ou 10 millions d'utilisateurs, il a toujours 10 failles et pas 10 millions de failles. Si t'as 10 millions d'utilisateurs, ça va vite pour identifier/exploiter les 10 failles et donc les corrigers. Si t'as une poignée d'utilisateurs, c'est beaucoup plus long.
Tout a fait, et le truc est que Windows n'a pas specialement plus de failles que Linux.
Un contre exemple de ton explication est Linux. Linux demande des utilisateurs pour tester, demande des gens pour auditer l'OS, pour chercher des failles. Plus Linux a d'utilisateurs et plus Linux est sûr. L'inverse est tout simplement faux.
Ca c'est des grosses conneries, car meme si en theorie c'est vrai, en pratique quasiment personne ne le fait(manque de connaissances programmation et securite, de temps, manque de connaissance du code,...), raison aussi pour laquelle on trouve toujours des failles dans Linux.
Notes comme Firefox est maintenant populaire (probablement autant utilisé que feu IE 4/5) et comme il a peu de problème de sécurité/virus.
Tu m'expliques ça ?
Peu de problemes de securite ? Mais tu reves, va sur secunia, pour 2006, 16 rapports pour IE6, 13 pour Mozilla 1.x
quasiment la meme chose.
Comment tu vas expliquer que IE a coûté des milliards avec ses virus et Firefox pratiquement rien ?
Qu'es-ce que tu vas trouver comme explication ?
Faudrait encore que ca arrive, ce qui n'est pas le cas. Avec des conditionels on mettrait Paris en bouteille mon cher.
Et quand MS fera des OS qui ne sont pas des plateformes à virus (et je pense qu'un jours ça arrivera), que ces OS ne couterons plus des milliards en trou de sécurité, comment tu vas expliquer ça ?
Aucun OS MS n'est une plateforme a virus au jour d'aujourd'hui, et tu n'as toujours pas montre l'inverse.
Pourquoi tu m'"emmerdes" avec les améliorations au niveau sécurité d'IE pour Vista alors que tu n'arrêtes pas de dire que les risques que encours un utilisateur sont liés uniquement à la popularité de l'OS ?
Parce que tu n'es pas fichu de comprendre ce que "defense in depth" signifie.
Ce qui a ete fait pour IE dans Vista n'est rien d'autre que cela : MS sait parfaitement qu'il _peut_ y avoir des failles dans IE, comme dans tout autre soft, et comme IE est un soft qui communique avec l'exterieur, ils l'isolent afin que meme en cas de faille le resultat soit peu important.
Si tu vas lire les gars de Mozilla eux-meme : http://wiki.mozilla.org/Firefox3/Firefox_Requirements tu verras qu'ils trouvent ca utile et pensent a une approche similaire, dingue hein ?
# Des Frameworks et de leurs places dans la vie virtuelle
Posté par ThesmallgamerS . Évalué à 3.
La diversitée des libs graphiques n'est pas plus importante dans un système GNU/Linux que dans un windows classique (voir un commentaire précédent pour plus d'information). La différence essentielle entre les deux système, c'est que là où les second ont un devveloppement fort peu avancé (par rapport a la lib win normal), et ne sont finalement que rarement utilisé, les premiers forment une toile d'ossature autour de quelques projets importants : Gnome, KDE, E17 pour en prendre trois. Dire que cette profusion est un frein au devellopement d'application est une logique digne des Looney Tunes. Au contraire, plus il y a de Toolkit, plus le devellopeur a le choix et plus celui-ci a de possibilité ; de plus, s'il a peur de s'investir dans plusieurs toolkit, il peut fort bien n'en choisir qu'un seul comme il le ferait de manière classique avec windows, car ceux-ci sont tous extrêmement mature.
Maintenant, quittons le point de vue du programmeur pour prendre celui de l'utilisateur. Certes, l'hétérogénéité des applications que forment autant de frameworks peuvent le déconcerter. Mais n'est-ce pas la principale occupation des devellopeurs que de maintenant offrir des interconnexions stables entre ces frameworks ? Nous pouvons citer Freedesktop, qui constitue un pont majeur entre Gnome, KDE et les autre WM ; plus lointain, les certifications Posix, les système de paquets - dont aujourd'hui nous n'avons plus que deux importants, ainsi qu'une pléthore de moindre importances mais tout aussi mature -, le Dcop, X, etc. Malgré la profusion qu'ordonne le principe de develloppement même de GNU/Linux et dérivé, la préocupation de rassembler les éléments autour de quelque chose en commun s'est très vite imposé. Aujourd'hui, on lance des programmes Gnome dans KDE, et ceux-ci prennent automatiquement l'apparence du théme en place, et vice-versa. Ce n'est plus qu'une question de temps et de spécification avant que le reste ne communique simplement.
Enfin, une dernière chose : L'inexistence de "Killer lib" que suppose la fragmentation des devellopeurs est un arguments véritablement infondés dés qu'on recherche un peu plus loin que la croute. Beaucoup de toolkit et libs restent dans l'ombre alors qu'ils sont révolutionnaire, justement parce qu'ils sont révolutionnaire. Deux citations viennent appuyer : les EFL et la CImg library. La première forme l'ensemble des librairies révolutionnaire sur laquelle s'est formé E17. Elle prodiguent, avec beaucoup plus de simplicité et beaucoup moins de ressources que n'importe quels ensembles, des capacités avancés de retouche d'image, d'animation , d'interruption processus, de description graphique (X ans avant XUL). C'est des librairies qui, en leur temps, ont été révolutionnaire, et que seuls la superposition de plusieurs couches permettent aujourd'hui d'approcher l'équivalence.
L'autre exemple, la CImg, est un peu équivalent. Très bon, très simple, très rapide, rarement ou peu utilisé.
Hum... Voilà.
[^] # Re: Des Frameworks et de leurs places dans la vie virtuelle
Posté par pasBill pasGates . Évalué à 0.
Bien au contraire, quand il y a fragmentation il y a duplication et il y a un frein a la collaboration.
Developpeur X cree une librairie pour Qt, le gars qui bosse avec Gtk et qui ne connait pas Qt ne peut pas l'utiliser.
Developpeur X cree un soft utilisant DCOP, le gars qui a passe ses 3 dernieres annees dans Gnome ne saura pas quoi en faire.
Et meme pour ceux qui feraient l'effort d'apprendre la lib d'en face pour integrer ce qu'ils voient, cela finit avec une appli qui depend des libs des 2 frameworks, vive la lourdeur.
Faut pas rever, la variete ca a des avantages(t'as le choix), et ca a des inconvenients(cf ce que je decris).
[^] # Re: Des Frameworks et de leurs places dans la vie virtuelle
Posté par IsNotGood . Évalué à 3.
Je suis assez d'accord.
Mais il faut aller un peu plus loin. Deux implémentations pour le même service c'est sans intérêt, et pire ça peut nuir. Mais par exemple il y a plein de window manager sous Linux. Ça nuit ? Ils n'offrent pas la même chose. Ici c'est du choix pour l'utilisateur, c'est un plus.
Par contre entre gtkmm et qt, c'est limite doublon. M'enfin, qt est utilisé depuis longtemps, utilisé par KDE, et donc restera longtemps. gtk+ et qt n'est pas un doublon. L'un est pour les développeurs C et l'autre pour les développeurs C++. Il y a effectivement quelques doublons dans le logiciel dont l'un des plus populaire est dpkg et rpm.
Un des "problèmes" est qu'il ne faut pas interdire les initiatives même si elle semble faire doublon. Sinon on tu la concurrence.
Puis il faut aussi remarquer que les projets libre ont naturellement tendance à suivre les standards et non réinventer la roue. Les différences ne sont jamais introduites pour rendre les utilisateurs captifs.
# Phantasy Star, emu, etc
Posté par scullder . Évalué à 1.
Je plussoie violemment pour Phantasy Star. J'ai fini le 1, le 2 me saoule légèrement à cause de sa difficulté (oui je sais, sacrilège toussa, pardon aux familles), je suis pas emballé par le 3 (même si on choque les fans quand on dit ça), et pas eu le temps de finir le 4 (je l'avais gravé avec un emu pour dreamcast), mais je vais régler ça.
Merci pour les remix, je connais ocremix et pour ma part je conseille celui là sur le thème de StarFox :
http://ocremix.org/remix/OCR00996/#
Par contre j'ai un petit problème... est-ce que quelqu'un a un repository qui va bien pour debian amd64 pour :
- gens
- yabause
- epsxe
- raine
- gngeo
A la limite, j'essaierai de me faire ça si ça n'existe pas.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.