Journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique

Posté par . Licence CC by-sa
61
10
août
2015

Cher Nal !

Ces derniers temps, disons ces 15 dernières année, on lit beaucoup de témoignages poignants, larmoyants, parfois même insultants de (ex- ?) linuxiens frustrés, découragés, éconduits car on leur aurait menti : Leur distribution Linux n'est pas le meilleur OS du monde !

Du coup cher Nal, je voulais te raconter pourquoi, linux (et ma distribution) est toujours le meilleur OS du monde. Ce n'est bien sûr que mon humble point de vue …

J'aborderai 3 points :
1) Généralités philosophiques
2) De la résistance au changement
3) De l'herbe verte

1) De la liberté !

Tout d'abord, et malgré tous les défauts / avantages ou autres partis pris que l'on pourrait lire ici et là, il faut tout de même noter, peut être souligner, voire même marteler que gnu/linux c'est un logiciel libre. Libre comme dans liberté (pas comme dans gratuit … rien n'est gratuit en ce bas monde - au mieux, ça coûte le temps du gentil dév). Ce concept, certes simples en apparence est compliqué dans la réalité. Car la liberté, ça se mérite. Ce n'est jamais acquis … c'est valable pour linux comme pour les droits citoyens …

Philosophiquement parlant, on peut choisir linux, et se battre pour une conviction, pour un droit, pour le droit de choisir. C'est pas toujours drôle, c'est parfois douloureux, mais ça en vaut la peine, car en lieu et place, on a d'autre choix que l'asservissement, et là, même si ce n'est pas immédiat, là, ça fait vraiment (toujours) mal.

Tout ça pour dire, que depuis mes débuts sur linux, et malgré quelques pérégrinations, quelques changements de distro (Mandrake, Fedora, Mandriva, Debian, Archlinux et qq tests ici et là), aujourd'hui plus que jamais, je sais que mon choix était le bon. J'ai toujours accès à ce que je veux, je maîtrise (plus ou moins on est d'accord) ce que j'installe ou ce dont je ne veux pas et je suis à même de faire le choix que j'estime être le meilleur pour moi en terme de logiciels.

Merci gnu, merci linux, non, vous ne m'avez pas déçu !

2) Neo-Darwinisme et survie

Malheureusement pour tout les nostalgiques, le monde n'est pas immobile ni figé. Il avance, avec ou sans nous … et c'est à nous de suivre sinon gare à la casse. Le hardware change et le software doit aussi changer. Bien sûr, le vieil adage "on ne change pas une équipe qui gagne" peut sembler rassurant mais en l'occurrence, je défie n'importe quel entraîneur d'aligner la même équipe aux mondiaux de football à 4 ans d'intervalles pendant 16 ans …

Bref, par confort (ou par conformisme ?) l'être humain n'aime pas être dérangé dans ses habitudes et quand on a appris un soft, un système, une méthode de config' et qui plus est, quand on avait tout ça bien en mains, et bien on aime pas changer …

Alors oui, systemd blabla, wayland blabla, sddm blabla … on s'en fout. le truc c'est qu'il y a des gentils dev qui se mettent en 4 pour suivre l'évolution de l'informatique. ET oui, je suis content de savoir que xorg va disparaître. Systemd, qu'à cela ne tienne, m'a apporté beaucoup de simplification dans la gestion de mon système. kde, gnome … bah ça change. Mieux ? Moins bien ? juste différent. KDE 3.5 ou Gnome 2 plantaient eux aussi, et avaient leurs lots de problèmes.

La principale différence entre linux (quelque soit la distrib' ou le bureau) et les autres systèmes c'est que sur votre PC d'aujourd'hui, vous pouvez toujours lancer / installer une vieille mandrake si vous le voulez (je vois pas pourquoi qq voudrait ça mais bon …) et qu'avec une distrib actuelle, on peut toujours récupérer / utiliser le travail réalisé sur un vieux système.

ET pour ça, merci Linux.

3) Tout nouveau tout beau !

Doucement, mais sûrement, on en arrive à la concurrence. Alors oui, sur certains points, la concurrence peut être plus aboutie. Plus perfide aussi. Si on est prêt à abandonner sa liberté et perdre qq euros, alors pourquoi tergiverser sur les forums ? allez-y ! le monde du libre est là pour ça. Il vous permet même de choisir de quitter la liberté !

Par curiosité, on a tendance à vouloir changer / adapter son système avec chaque nouvelle version. Et au final, ce sont plus les early adopters qui râlent …

Ma propre expérience est, et elle vaut ce qu'elle vaut, qu'en suivant les màj de Archlinux, je n'ai quasiment jamais cassé mon PC (et si c'est arrivé, c'est que j'avais oublié de suivre la reco de la page d'accueil, comme par ex, ne pas oublier de recompiler un driver graphique avant de rebooter !)

J'ai la même distribution depuis 8 ans (même installation) qui a connu 2 PCs (alim' cramée) en insérant simplement le disque dur de l'ancien pc dans le nouveau. Faites en autant avec Mi---soft ou A--le … et pourtant cette distribution n'a rien à voir avec elle même tellement elle a évolué.

Cependant, il est passé le temps où je testais chaque nouvelle distro pour voir ce qu'elle amenait (ou pas …), aujourd'hui, je prends ce qui arrive, et je fais avec. Je customise le standard (BMW série M) et je n'essaie pas de rendre le standard customisé (Pimp my Ride / MTV) … et cette façon de faire apporte beaucoup de tranquillité car sinon, on succombe vite à la tentation de toujours regarder plus loin là où ce n'était pas pensé pour ! C'est comme les poupées Russes (réf au film) …

Bref, un grand merci linux, un grand merci à tous les développeurs et volontaires du libre, un grand merci aux fondations et aux trublions du libre !!!

PS : je parle de linux, mais c'est valable pour tous les systèmes libres comme par ex. les BSDs

  • # Chezmoicamarche

    Posté par . Évalué à 10.

    Pour aller dans la même direction, pour contrer un peu la sur-représentation des commentaires négatifs dans les avis des utilisateurs, je ne crois pas me souvenir avoir jamais eu de problème de son depuis qu'Ubuntu est passé à pulseaudio. Ce passage a d'ailleurs permi chez moi de faire fonctionner le binaire Skype, qui ne détectait pas le micro avant.

    J'ai certainement eu de la chance de passer entre les bugs, mais je pense que c'est important de savoir que ça arrive.

    Le seul point négatif, c'est que je n'ai aucune idée de comment ça marche, puisque je n'ai jamais eu à le réparer…

    • [^] # Re: Chezmoicamarche

      Posté par (page perso) . Évalué à 1.

      Et maintenant, tu peux remplacer le mouchard logiciel propriétaire SKYPE par Hello, JITSI, Pidgin et bien d'autres.

      • [^] # Re: Chezmoicamarche

        Posté par . Évalué à 10.

        En plus il gagnera plein de temps car il n'aura plus à discuter avec tout un tas de gens.

      • [^] # Re: Chezmoicamarche

        Posté par . Évalué à 7.

        Bien sûr, mes contacts pro utilisent Pidgin et bien d'autres. En fait, je n'utilise Skype que parce que j'aime bien installer des trucs prorio Microsoft sur ma bécane, et que le logo est joli.

    • [^] # Re: Chezmoicamarche

      Posté par . Évalué à 4.

      je ne crois pas me souvenir avoir jamais eu de problème de son depuis qu'Ubuntu est passé à pulseaudio.

      Branchement à froid, retrait à chaud du casque audio USB et vice-versa, aucuns soucis - sous Debian 7 et Ubuntu 12->14, le son est directement routé là où il faut. Si vous avez envie de vous la jouer Jacquouille - branché, débranché, branché - faites vous plaisir! Soyons fous, alternons avec du bluetooth, ça marche!

      Faites de même sous Windows 7, qu'on rigole, branchement dans un autre et il se met à lancer la détection matériel/pilote et se stabilise après 30-40 secondes et peut-être que ça ira mais sans le routage automatique.

      Peut-être que Pulse Audio bouffe 1-4% CPU, peut-être… Mais ça "juste" marche comme on l'attend.

      • [^] # Re: Chezmoicamarche

        Posté par . Évalué à 1.

        w00t! On peut utiliser un casque audio sous linux sans avoir a rebooter. Truc de malade! Windows et macosx peuvent aller se rhabiller.

        Suis je le seul a me rendre compte du comique de ce genre d'arguments?

        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: Chezmoicamarche

          Posté par (page perso) . Évalué à 10.

          Ben ça te fait peut être rire mais sous Windows cela ne fonctionne pas aussi bien que sous Linux… Et je le dis parce que je suis sur un poste Windows là et que je peste à chaque fois que je branche le casque et que mon son reste coupé…

          • [^] # Re: Chezmoicamarche

            Posté par . Évalué à 1.

            Remarque ça marche sans pulseaudio ton truc (j’avais jamais fait gaffe), du moins entre les haut-parleurs internes et la sortie jack.

            • [^] # Re: Chezmoicamarche

              Posté par (page perso) . Évalué à 3.

              Non, ça ne fonctionne pas sans pulseaudio, tu n'a pas le volume mémorisé par périphérique.

              • [^] # Re: Chezmoicamarche

                Posté par . Évalué à 4.

                Si ça marche. Du coup j’ai vérifié :) ça doit bien faire deux ans que ce truc m’emmerde sans avoir pris 10s pour tester :/

                J’ai trois volumes sous alsamixer, un master, un headphone et un speaker. Après ça dépend peut-être du matos derrière, ce genre de truc…

          • [^] # Re: Chezmoicamarche

            Posté par (page perso) . Évalué à 5.

            Et avec moi ça fait au moins 3 à dire que ça marche pas bien sous windows.
            On parle bien de casque audio usb, pas avec la prise jack.

            • [^] # Re: Chezmoicamarche

              Posté par . Évalué à 3.

              Et avec prise jack, c'est kif: Windows est à la traine d'un point de vue ergonomie.
              Sous Ubuntu, je ne réveille pas les gens qui dorment autour de moi quand le jack se débranche par mégarde.
              Sous Windows, pas de mémorisation du volume même s'il détecte le (dé)branchement.

              • [^] # Re: Chezmoicamarche

                Posté par (page perso) . Évalué à 3.

                Et en même temps, sous windows quand on branche une bête souris microsoft à 3 boutons, il faut attendre 2 minutes pour pouvoir s'en servir.
                Et quand on a un clavier usb sur un laptop, dans le mode "y a eu un problème voulez-vous démarrer normalement" il n'est pas pris en compte.

        • [^] # Re: Chezmoicamarche

          Posté par . Évalué à 3.

          Suis je le seul a me rendre compte du comique de ce genre d'arguments?

          Non, mais je pense que tu as manqué le point. Il y a pas mal de chose qui juste marche sans qu'on s'en soucis et les conditions que j'ai cités sont loins d'être acquises sous Windows 7 qui est tout de même un assez bon produit, l'rrgonomie mise à part.

          Après, tout n'est pas rose sous linux, on est au courant (cf: nouveau matériels pointus, nvidia optimus, wifi à base de Broadcom, etc…), je ne fais pas le stupide fanboy mais en général, niveau support matériel ou gestion de celui-ci, l'OS du manchot est bien devant les autres.

    • [^] # Re: Chezmoicamarche

      Posté par . Évalué à 2.

      je ne crois pas me souvenir avoir jamais eu de problème de son depuis qu'Ubuntu est passé à pulseaudio.

      grand bien t'en fasse. Chez moi et à mon boulot (sur de multiples ordinateurs) c'est assez catastrophique, entre la charge CPU qui tourne parfois à 90 % sur pulseaudio ou les grésillements avec certains applications sous wine (disparaissent si on tue pulseaudio). Et comme de plus en plus d'applications nécessitent une dépendance à cette cochonnerie, c'est difficile de complètement le retirer.

      • [^] # Re: Chezmoicamarche

        Posté par (page perso) . Évalué à 2.

        entre la charge CPU qui tourne parfois à 90 % sur pulseaudio

        Super, tu ne l'as pas installé depuis 6 ans? C'est ça?

        • [^] # Re: Chezmoicamarche

          Posté par . Évalué à 2.

          Super, tu ne l'as pas installé depuis 6 ans? C'est ça?

          Si seulement…
          Si seulement ma dernière confrontation avec ce piètre logiciel datait de déjà 6 ans…

          Mais non, c'était l'année dernière seulement. Et j'ai exagéré (comme d'habitude), c'était 79% et non pas 90% :

          http://image.noelshack.com/fichiers/2015/33/1439303970-pulseaudio-79.png

          • [^] # Re: Chezmoicamarche

            Posté par (page perso) . Évalué à 5.

            Facile d'accuser pulseaudio parce que c'est lui qui prend le plus de CPU.

            Moi je vois surtout kded et kmix qui n'ont aucune raison de consommer autant de CPU, et qui sont surement en train de flooder pulseaudio… Bref, comme je l'ai dit, le stack audio de KDE est vraiment merdique…

            Ils devaient virer kded de KDE5 et ce n'est pas le cas, vraiment dommage tellement ce truc est une grosse merde monolithique capable de faire planter tout le bureau sans raison.

          • [^] # Re: Chezmoicamarche

            Posté par . Évalué à 3.

            Marrant, on te voit pas chier sur kded4, kmix ou firefox qui pompe visiblement plus de cpu qu'ils ne devraient, ni contre FF qui se goinfre 1.5Gb de ram a lui tout seul.

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

      • [^] # Re: Chezmoicamarche

        Posté par . Évalué à 10.

        de plus en plus d'applications nécessitent une dépendance à cette cochonnerie

        Pulseaudio, c'est comme systemd: on entend des critiques hyper-agressives (voire diffamatoires) de la part d'utilisateurs, alors que ces solutions ont été adoptées et intégrées à la plupart des distributions, y compris les distribs historiquement conservatrices. Or, personnellement, j'ai plus de considération pour les compétences techniques des gens qui sont responsables de la maintenance des grosses distribs (qui sont peut-être ceux qui ont la meilleure vision possible des tenants et des aboutissants des problèmes) que des remontées de bugs fantomes, du style "il y a trois ans j'ai eu un problème avec pulseaudio et c'est de la merde". La question, c'est pourquoi la grosse majorité des mainteneurs de distributions (qu'elles soient commerciales ou associatives) opteraient pour un choix technique totalement irrationnel ? Ils souhaiteraient tous, en même temps, casser leur distro ? Ils seraient payés en sous-main par des gens qui développement du logiciel libre ? L'hypothèse que les ronchons de l'autre bord ont tort me semble bien plus plausible.

        Bien sûr, tout changement de cette importance va occasionner des bugs. Mais pour bien faire, il faudrait comparer ces bugs attribuables au changement à tous les bugs évités par le nouveau système qu'on ne verra jamais.

        • [^] # Commentaire supprimé

          Posté par . Évalué à 10. Dernière modification le 11/08/15 à 14:29.

          Ce commentaire a été supprimé par l'équipe de modération.

          • [^] # Re: Chezmoicamarche

            Posté par (page perso) . Évalué à 3.

            https://wiki.archlinux.org/index.php/NFS/Troubleshooting

            Quand je vois que cette page ne contient aucun workaround en lien avec systemd, je peux partir du principe qu'il n'y a pas de problème entre NFS et systemd.

            Donc, oui j'ai une question, quelle est ta distribution? Il est peut être là le problème… Parce que bon, des machines sous Ubuntu, j'en ai vu passer ces 5 dernières années avec du matos différent, et j'ai jamais vu un utilisateur venir me dire que le son ne fonctionnait pas…

            Par contre, sous KDE, j'ai toujours eu des problèmes (sons systèmes avec une latence forte), j'ai toujours craché sur pulseaudio à l'époque, puis un jour je suis passé sous GNOME et j'ai vu que c'était KDE le problème.

            casque bluetooth qui fonctionnait avec alsa

            Pourtant j'ai lu que ça ne pouvait fonctionner tout seul avec ALSA. T'es sur que t'as pas oublié le support bluetooth dans ton pulseaudio?

            • [^] # Commentaire supprimé

              Posté par . Évalué à 6. Dernière modification le 11/08/15 à 15:10.

              Ce commentaire a été supprimé par l'équipe de modération.

              • [^] # Re: Chezmoicamarche

                Posté par (page perso) . Évalué à -1.

                Quand tu cherches sur google « systemd nfs share boot »

                Premier: comportement normal de NFS quand le serveur est lent, configurable.
                Second: Mise à jour Ubuntu foireuse (manque la dépendance au réseau).

                Je vais m’arrêter là…

                Il ne faut pas croire toute la « propagande ». Alsa fonctionne(ait) relativement bien.

                Je n'appelle pas cela fonctionner tout seul:
                https://wiki.debian.org/Bluetooth/Alsa

                J'ai tout installé, tout, tout, … Tout essayé ce que je trouvais sur le net. Rien n'y fait.

                Cela fonctionne très bien sur ArchLinux avec les outils en ligne de commande… Par contre, oui, sous Debian, à chaque fois, je passe 3 heures à trouver le paquet manquant… Et du coup, j'ai un trou de mémoire là… Installe ArchLinux, tu verras ça fonctionne tout seul… (normal vu que les paquets ne sont pas découpé comme sous Debian).

                • [^] # Re: Chezmoicamarche

                  Posté par . Évalué à 3.

                  Installe ArchLinux, tu verras ça fonctionne tout seul… (normal vu que les paquets ne sont pas découpé comme sous Debian).

                  Et surtout, Arch n'a pas tendance à patcher ses paquets comme un goret. Si ça marche sur Arch, c'est que le paquet upstream fonctionne comme attendu.

                  • [^] # Commentaire supprimé

                    Posté par . Évalué à 6.

                    Ce commentaire a été supprimé par l'équipe de modération.

                    • [^] # Re: Chezmoicamarche

                      Posté par (page perso) . Évalué à -1.

                      Je n'ai pas parlé de GNOME…

                      • [^] # Commentaire supprimé

                        Posté par . Évalué à 5.

                        Ce commentaire a été supprimé par l'équipe de modération.

                        • [^] # Re: Chezmoicamarche

                          Posté par . Évalué à -1.

                          Et tu as remonté tes bugs aux développeurs ?

                          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                          • [^] # Commentaire supprimé

                            Posté par . Évalué à 3.

                            Ce commentaire a été supprimé par l'équipe de modération.

                            • [^] # Re: Chezmoicamarche

                              Posté par . Évalué à 1.

                              Et tu as regardé si le problème était répandu ? S'il y avait des bug reports dont la description était proche de ton problème ?

                              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                              • [^] # Commentaire supprimé

                                Posté par . Évalué à 9.

                                Ce commentaire a été supprimé par l'équipe de modération.

                                • [^] # Re: Chezmoicamarche

                                  Posté par . Évalué à 1. Dernière modification le 11/08/15 à 17:24.

                                  Je ne te prends pas pour une Mme Michu, mais je vois pas comment résoudre le problème sans poser ce genre de questions.

                                  Mais bon, si tu te sens offensé, grand bien te fasse. ;-)

                                  Pourriez-vous me passer le support de second niveau parce que de toutes évidences, vous ne pourrez pas résoudre cela ;-)

                                  … Bah j'ai rien à résoudre, hein. Chez moi ça marche parfaitement. ;-)

                                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                                  • [^] # Re: Chezmoicamarche

                                    Posté par (page perso) . Évalué à -1.

                                    … Bah j'ai rien à résoudre, hein. Chez moi ça marche parfaitement. ;-)

                                    Ben, il installerait une Ubuntu, ça fonctionnerait aussi parfaitement… Ca se trouve, c'est juste sa conf utilisateur d'Alsa qui empêche pulseaudio de fonctionner…

                        • [^] # Re: Chezmoicamarche

                          Posté par (page perso) . Évalué à 2.

              • [^] # Re: Chezmoicamarche

                Posté par . Évalué à 2.

                Il ne faut pas croire toute la « propagande ». Alsa fonctionne(ait) relativement bien.

                Hum ! Rien que pour avoir un volume sonore par application, je suis obligé d'utiliser PA (car un "codec" HDA ne fait pas de hardware mixing. Le mixing revient au software, et ALSA avec ou sans dmix ça ne marche juste pas).

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: Chezmoicamarche

                Posté par . Évalué à -5.

                Quand tu cherches sur google « systemd nfs share boot », tu tombes sur pas mal de gens qui ont le problème depuis une mise à jour.

                NFS? Des utilisateurs avancés donc. J'en suis un et pourtant, j'utilise principalement SMB/CIFS parce que j'ai et j'interviens sur des environnements hétérogènes, c'este juste le dénominateur communs pour ce qui est du partage réseau et ça se monte ad-hoc sous Gnome.

                Après, je ne nie pas le problème que tu présentes mais je souligne juste qu'on est pas dans un scénario avec un utilisateur de base. Et vu qu'il utilise systemd, il doit être sur Fedora, Arch, ou autre truc non LTS du coups ben, assumez, essuyez les plâtres et faites avancer le schmilblik en rapportant des bugs, sinon, restez simples utilisateurs et utilisez du LTS.

                • [^] # Commentaire supprimé

                  Posté par . Évalué à 6.

                  Ce commentaire a été supprimé par l'équipe de modération.

                  • [^] # Re: Chezmoicamarche

                    Posté par (page perso) . Évalué à -1.

                    Non, sinon il n'y aurait pas debian LTS…

                  • [^] # Re: Chezmoicamarche

                    Posté par . Évalué à -1.

                    Debian stable c'est pas par excellence du LTS ?

                    Ben oui, c'est pour ça que je suggère Debian en non(testing/unstable) ou Ubuntu LTS.

                    NFS? Des utilisateurs avancés donc
                    

                    Je ne vois pas le rapport.

                    Je ne dis pas qu'il faille être un sysadmin aguerri mais CIFS/SMB est plus flexible, si tu as recours à NFS c'est que tu fais déjà quelque chose d'avancé ex: /home/$USER sur NFS, root NFS ou alors si c'est juste parce que tu n'as que des machines Unix/Linux et que tu favorises NFS, tu es donc probablement un utilisateur avancé.

                    Mais je réagissais à ton commentaire:

                    Bref, c'est de la faute de l'utilisateur qui est un bras cassé. Il n'a qu'à être développeur de tous les logiciels libres du monde.

                    Développeur ou sysadmin, c'est la même rengaine venant des victimes.

                • [^] # Re: Chezmoicamarche

                  Posté par (page perso) . Évalué à 2.

                  NFS? Des utilisateurs avancés donc.

                  Cause, conséquence, pas clair…

                  * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

          • [^] # Re: Chezmoicamarche

            Posté par . Évalué à 3. Dernière modification le 11/08/15 à 16:12.

            Je vois surtout une série de personne qui disent qu'elles ont eu des problèmes et ont toujours des problèmes avec pulse/systemd et autres, et un paquet de d'autres personnes qui disent :

            Y'en a aussi beaucoup chez qui ça fonctionne très bien, et qu'on entend jamais (moi - sauf qu'on m'entend dire que ça juste marche :p -, mes connaissances ayant PA / systemd, des millions d'utilisateurs d'Ubuntu et autres distribs utilisant systemd et/ou PA…)

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Chezmoicamarche

            Posté par . Évalué à 1.

            Bref, c'est de la faute de l'utilisateur qui est un bras cassé. Il n'a qu'à être développeur de tous les logiciels libres du monde.

            Je suis sysadmin mais depuis 5 ans au moins, je n'ai plus eu à me battre avec des imprimantes, le son et l'affichage (nvidia proprio ou ati/intel libre). Le wifi + Network Manager peut par contre être tatillon avec certains routeurs/AP wifi et certains types de profiles WPA, du coup, j'ai recours à la ligne de commande mais sincèrement, rien de plus.

            Mais quand je vois les réponses quand quelqu'un dit qu'il a problème, je n'ai pas envie de poser la moindre question. J'aimerais bien que ces deux produits fonctionnent directement, mais ce n'est pas mon expérience.

            Et bien oublie le rolling-release, les distro expérimentales où celles qui te vendent de la "légèrté" à base de WM austères.

            Dans mon exemple, j'ai cité Debian 7 et Ubuntu version LTS, chacunes avec leur install de base, quelques répo ou ppa pour certaines applications mais je ne me fais pas chier avec le système à proprement parler même si dés fois ça ne me dérange pas d'expérimenter.
            J'ai de la bouteille sous Linux, mais il ne me viendrait pas à l'esprit d'installer une Arch - bien que de qualité - ou une Fedora, si tu veux juste "utiliser" ton ordi, reste sur du LTS.

            Regarde les couroux qu'ont engendrés windows8 et maintenant windows10.

        • [^] # Re: Chezmoicamarche

          Posté par . Évalué à 6.

          Pulseaudio, c'est comme systemd: on entend des critiques hyper-agressives (voire diffamatoires) de la part d'utilisateurs, alors que ces solutions ont été adoptées et intégrées à la plupart des distributions, y compris les distribs historiquement conservatrices.

          Les distributeurs de sont pas l’upstream, ils ont une marge de manœuvre toute limitée. Quand les devs de udev disent vouloir mettre une dépendance sur kdbus, les devs de Gentoo qui n’en sont pas fan n’ont pas vraiment d’autre choix que plier (forker, mais ça signifie que leur pouvoir de manœuvre vient alors de leur position d’upstream, pas d’intégrateur)

  • # Merci au projet GNU !

    Posté par (page perso) . Évalué à 2.

    En effet, lorsque tu parles ici de linux, je comprends que tu parles en réalité du projet GNU, un système d'exploitation complet constitué exclusivement de logiciels libres pour utiliser nos ordinateurs.

    Face aux résultats obtenus par les sociétés privées et leurs moyens toujours plus grands, en termes de recherche et de développement, nous ne pouvons réellement compter que sur le principe de la souveraineté technologique pour défendre et promouvoir le projet GNU et l'intérêt spécifique des logiciels libres et dans une certaine mesure du copyleft.

    Je suis fière d'appartenir à ce mouvement populaire. Des entreprises privées puissent y trouver leur compte également. Mais si les logiciels sont réellement libres et non tenus par d'autres chaînes telles que les brevets logiciels (cf. v3 GPL), alors le peuple n'est pas particulièrement dominé par ces logiciels et les personnes qui les développent.

    Mais vis-à-vis des logiciels non-libres, privateurs… Nos logiciels libres donc, ne sont peut-être pas à la hauteur de leurs logiciels, ceux de Microsoft, ceux de Apple, de Google (ceux qui ne sont pas libres), de Facebook, etc. Mais nos logiciels libres sont bien à nous. Et cela nous rend libre, libre vis-à-vis de Microsoft, libre vis-à-vis de Apple, etc.

    Bien entendu, cette liberté peut paraître fort théorique à première vue et à l'utilisateur lambda, mais pourquoi ? Car elle repose sur le collectif, la communauté. Hors, l'individualisme nous éloigne tellement les uns des autres, que nous avons difficile à considérer le collectif, ou les collectifs au sein desquels nous pouvons être inscrit.

    Plus que jamais, les logiciels libres ont besoin d'un tissu social. Le goût du collectif et la confiance doivent être restauré.

    Parmi-nous, il y a des utilisateurs. Parmi-nous, il y a des connaisseurs. Parmi-nous, il y a des installateurs. Parmi-nous, il y a des programmeurs, des traducteurs, des ergonomistes, des chercheurs, des mathématiciens, des statisticiens, des philosophes, etc., etc.

    Avons-nous besoin d'autant de clans ? Avons-nous besoin d’enrichir les uns davantage que d'autres ? Avons-nous besoin que les uns aient un pouvoir sur les autres ? Avons-nous besoin de menaces, des pressions, de secrets, des monopoles, etc. ?

    Pour moi donc, le projet GNU, les logiciels libres, ce sont également ces questions :)

    • [^] # Re: Merci au projet GNU !

      Posté par . Évalué à 2.

      Salut,

      A titre personnel, j'ai bien du mal à comprendre ce qu'est le projet GNU. Je comprends la licence GPL mais est-ce que tout ceux qui utilisent cette licence font partie du projet GNU ? Pour moi le projet GNU était un projet global utilisant sa propre logithèque. Par exemple j'utilise parfois les autotools de GNU pour compiler et parfois cmake, qui n'est pas GNU mais libre. J'utilise kate et pas emacs pour coder … Soit je ne comprends pas l'ensemble que représente le projet GNU soit je le comprends et dans ce cas je trouve qu'il faut également remercier les gens qui utilisent d'autres licences libre que la GPL et ceux qui utilisent la GPL mais ne font pas partie du projet GNU. Personnellement j'ai pas du mal lorsqu'on fait croire qu'un projet contient tout ce qu'il existe alors que non. Je pense que GNU est très important historiquement mais également de part ses contributions actuelles au libre mais je ne pense pas qu'il soit ce qui fait que je peux utiliser des logiciels libres au quotidien. Il va de soit que je peux tout à fait ne pas bien saisir ce que représente ce projet !

      • [^] # Re: Merci au projet GNU !

        Posté par (page perso) . Évalué à 0.

        Je comprends bien.

        Selon mon approche, le projet GNU a été à l’origine du paradigme de logiciels libres pour l’aspect sociétal, et de manière concret défendre l’idée que tout logiciel devrait être libre. Avec la licence GPL, le projet GNU propose un domaine concret au sein duquel le projet GNU peut se concrétiser, au sein duquel les logiciels sont libres dans le sens originel du projet GNU. Sous licence GPL, tout logiciel peut donc être vu comme faisant partie du projet « de société » GNU mais peuvent également de manière concrète s’intégrer à un système GNU. Car le seul fait d’être un logiciel libre ne suffit pas forcément, ni d’un point de vue pratique, ni d’un point de vue philosophique vis-à-vis du projet GNU. Un logiciel libre doit être compatible avec la GPL, et le copyleft est un attribut supplémentaire pour l’aspect philosophique, sociétalement du projet GNU. C’est comme si la GPL proposait au-delà du concept de logiciel libre, un dôme protecteur sous lequel il est possible de vivre concrètement le projet GNU en toute sécurité juridique (c’est le but). Cela n’empêche pas les désaccords et les malentendus. Certaines licences seront considérées libres par la FSF-même, alors qu’elles seront incompatibles avec la GPL. Certaines de ces licences placent le logiciel en dehors du dôme originellement proposé par le projet GNU et la GPL, alors même qu’elles proposeront peut-être un autre dôme, mais distinct… (je trouve ça dommage)

        Par ailleurs, il y a bien un aspect dit engagé sociétallement, philosophiquement, politiquement, que certains fuiront comme la peste alors même qu’ils apprécieront d’autres avantages, dits parfois collatéraux, des logiciels libres et de la licence GPL.

        Nous n’arrêterons jamais de nous percevoir différent de la sorte, et les logiciels libres que certains nommerons Open Source, autant que les systèmes que certains appellerons GNU et d’autres Linux, sans parler des autres systèmes ou logiciels, BSD, Haiku, LibreOffice et autres, seront autant de lieux de "dispute" autour des approches et des valeurs véhiculées, mises en œuvre ou valorisées, volontairement ou pas…

        • [^] # Re: Merci au projet GNU !

          Posté par (page perso) . Évalué à 1.

          Par ailleurs, il y a bien un aspect dit engagé sociétallement, philosophiquement, politiquement, que certains fuiront comme la peste alors même qu’ils apprécieront d’autres avantages, dits parfois collatéraux, des logiciels libres et de la licence GPL.

          C'est ce qui fait bien souvent la différence entre le «Libre» et l'«Open Source».

          • [^] # Re: Merci au projet GNU !

            Posté par . Évalué à 3.

            Ha bon ?

            Les BSD sont OpenSource non GNU et tout ce qu'il y a de libre, non ?

            Donc pour moi GNU est un sous ensemble du libre et de l'OpenSource mais clairement pas l'alpha et l'omega du libre.

            En ce qui concerne les règles d'inclusion de logiciels GPL dans GNU cela ne m'a pas paru clair, ni dans la réponse précédente, ni dans la page wikipedia et encore moins sur le site de la FSF.

            Il n'y a pas 10% des softs que j'utilise qui sont dans ce projet et quand les noobs me demandent ce qu'est GNU, je ne sais pas trop quoi leur répondre à part c'est le projet logiciel qui a mis en place la GPL et qui donne accès à gcc et des outils bas niveau heu … ha oui ya gnome aussi et oui ya gimp ! Je crois qu'ils voulaient utiliser un micro noyau il y a vingt ans parce que c'est sensé être beaucoup mieux mais ça n'a jamais vraiment pris …

            Donc pas très clair et pas très carrés tout ça, en tout cas quand j'en parle.

            Sans compter que la base GCC a aujourd'hui un concurrent très sérieux qui gagne du terrain, les autotools sont souvent remplacé par d'autres outils.

            GNU octave peut être remplacé par python/numpy/scipy/matplotlib

            Tout ça fait que pour moi on peut tout à fait avoir une bonne expérience utilisateur avec très peu d'outils GNU. Quand ils sont bons je les utilise mais je ne ferais pas de génuflexion devant le gourou qui met un plateau de disque dur des années 80 sur sa tête et qui mange ses peaux de pieds en public. Je préfère avoir d'autres modèles, un certain Linus me semble plus représenter ce qui me plaît dans le libre.

            Vu qu'on était sur les remerciement, personnellement plutôt que d'essayer de financer un tueur à gage à son encontre, je préfère remercier chaleureusement Lennart Poettering pour pulseaudio qui rend vraiment de fiers services sur tous les PC modernes (en ce qui concerne systemd, je ne suis pas admin, donc pas vraiment concerné …).

            • [^] # Re: Merci au projet GNU !

              Posté par . Évalué à 8.

              GNU est un projet d'UNIX libre, qui impose la GPL comme licence pour les projets qu'il accepte, avec une cession des droits d'auteur pour que la FSF puisse prendre en charge les problèmes juridiques. C'est pas si compliqué :)

            • [^] # Re: Merci au projet GNU !

              Posté par . Évalué à 10.

              Quand ils sont bons je les utilise mais je ne ferais pas de génuflexion devant le gourou qui met un plateau de disque dur des années 80 sur sa tête et qui mange ses peaux de pieds en public.

              Une GNUflexion ! C’est par où la porte ? Par là ? Ah oui c’est par là…

  • # Tu peu même élargir ...

    Posté par . Évalué à 10. Dernière modification le 10/08/15 à 18:24.

    Permettez moi de vous parler comme un vieux c..

    Mais dans les des années 80 avant internet, il n'y avait que des modems 1200 bauds pour communiquer.
    Les ordinateurs coutaient cher, les logiciels coutaient cher bref … si t'avais pas de sous tu regardais les pubs de 'l'ordinateur individuel' à l'époque on apprenait plein de choses.

    Puis les ordinateurs ont commencé à être sympa : commodore 64 / Amiga 500 (atari aussi ;-) )
    mais le matériel coutaient cher, les logiciels coutaient cher ET quelques logiciels gratuits pouvaient se trouver sur les disquettes de Fred Fish.

    La diffusion se faisait de la main à la main quand par hasard vous rencontriez un autre passionné

    Mais problème certains fichiers d'entête binaire ne se diffusait pas c'était interdit et empêchait de développer même avec les langages gratuits.

    Pour apprendre c'était pas top … je ne parle même pas de documentation quasiment introuvable

    Puis Linux est arrivé un OS libre sans limite d'utilisateurs, ni limite du tout d'ailleurs
    Puis internet via ADSL avec un débit > 56K baud
    Et la des logiciels, des langages … de la doc … des bases de données … des logiciels graphiques en plus …

    Et maintenant, Linux est même reconnu par les Professionnels de la profession … et je m’aperçois que ces logiciels libres et gratuits valent BEAUCOUP plus que nombre de logiciels payants.

    Car ce que j'apprends avec eux, je ne le perds pas

    Certains de mes programmes arrivent à 10 ans et toujours en activité et en exploitation

    Bravo et merci à tous ces développeurs qui nous ont fournis ces outils, cette matière première formidable quand on veut bien prendre le temps d'apprendre à s'en servir.

    Merci a Mr STALLMAN qui nous montre un chemin (j'ai pas dit le ) et nous amène à réfléchir sur l'avenir

    il faut que ce droit de créer, de modifier d'échanger des programmes, des logiciels, des données perdure et ne soit pas accaparés par des monstres comme les GAFAs ou autre.

    Et pendant qu'on y est, Merci les moules, pour ce forum d'échanges enrichissants …

    L'informatique libre est un formidable espace de jeu et de création, en dehors de toute considération commerciale et marketing , il faut que nos enfants puisse en disposer.

    • [^] # Re: Tu peu même élargir ...

      Posté par (page perso) . Évalué à 0.

      Pour que l'informatique libre continue d'exister, à nous aussi de ne pas tomber dans la facilité des distributions GNU/Linux toute prêtes mais pleines de logiciels propriétaires : SKYPE…
      À nous de choisir des distributions 100% logiciels libres et de participer à leur amélioration (traductions, rapports de bugs, corrections, avis, tests…).
      https://www.gnu.org/distros/free-distros.fr.html

      • [^] # Re: Tu peu même élargir ...

        Posté par . Évalué à 7.

        Sophisme sans fondement, pourquoi quo-exister avec des logiciels propriétaires empêcherait le libre d'exister. Petite anecdote personnelle. Quand je suis arriver en poste j'ai fait basculer des profs sous linux. Ils étaient très contents mais sont passés sous MacOS quelques mois plus tard car ils avaient besoins d'échanger avec les administrations des documents words et passer sans arrêt sous Windows en dual-boot était éprouvant du coup hop là ! … tout le monde sous MAC. et bien s'il y avait eu MSWord sous linux fonctionnel sans hack alors ils y seraient resté.

        Tu peux donc arguer que l'inclusion de softs prorpio tue le libre, j'aimerais bien te voir faire un démonstration de cette hypothèse. L'autre exemple est celui des jeux. Combien disent que leur boot windows ne sert que pour les jeux ! C'est donc une bonne nouvelle que Steam avance sur Linux. D'une part ça fait progresser les drivers graphiques et de l'autre ça va attirer des gens sur le système en lui même. La liberté c'est aussi accepter les contraintes des autres et les laisser accéder à l'écosystème libre même s'ils ne peuvent en embrasser toute son entièreté. Je trouve que ce discours haineux "à la April" est fatiguant.

        Je me suis retrouvé une fois après un exposé de Jérémie Zimmermann à discuter avec des gens d'April qui voulaient presqu'en venir aux mains quand je leur expliqué que parfois il était compliqué de pouvoir tout faire avec des logiciels libres alors qu'ils ne connaissaient même pas mon spectre d'activité ni celui des gens dont je parlais. Il est fondamental d'avoir une idéologie qui guide ses choix techniques mais de là à en faire un tabou et à en manquer de civilité, franchement j'ai du mal.

        Pour ton exemple de Skype, trouves un logiciel qui sait passer les parefeux et autre restrictions et on en rediscute, il n'est pas là pour rien il me semble. Après si tu as la chance (ou la mal chance …) de pouvoir travailler et échanger qu'avec des gens qui partagent ta philosophie, grand bien te fasse mais évites de casser du sucre sur le dos de distributions qui permettent à des gens qui ne sont pas dans ton profil d'accéder à un sous ensemble du libre.

        • [^] # Re: Tu peu même élargir ...

          Posté par (page perso) . Évalué à 10.

          Le risque, et on le voit d'ores et déjà avec Ubuntu, dont la logithèque met en avant des logiciels non libres [1], dont les licences ne sont pas toujours correctement renseignées et qui ne fait pas vraiment d'éducation auprès de ses utilisateurs, de se retrouver avec une population qui ne sait pas vraiment ce qu'est le libre et ce que ça peut lui apporter. Population qui pourrait, à terme, cloner les comportements et la situation que l'on retrouve aujourd'hui sous Windows (récupérer des logiciels n'importe où, installer n'importe quoi, se retrouver avec des bloatwares, adwares, des barres de recherche qui s'accumulent…)

          L'autre souci, qu'on a connu avec Flash, c'est que de disposer d'une version Linux officielle a su contenter la communauté, qui n'a donc pas cherché à développer une implémentation libre, fiable, performante, sécurisée… Nous avons donc subi pendant des années les problèmes bien connus de ce greffon, suivi de l'abandon de notre plateforme par son développeur, nous poussant à devoir utiliser un autre logiciel non libre (Chrome) pour pouvoir bénéficier des améliorations nécessaires pour certains sites (ou de bidouiller une méthode bancale à base de binaire Windows).

          Même chose pour les drivers. Le fait qu'ils soient libres, inclus dans le kernel, permet (ou du moins, c'est l'idéal vers lequel on tend) de voir son matériel parfaitement supporté sans que l'utilisateur n'ai besoin de faire quoi que ce soit, de pouvoir maintenir le support dans le temps, de faire en sorte que tout soit parfaitement à jour avec une simple mise à jour du kernel, de pouvoir déplacer un disque système d'une machine à l'autre sans avoir besoin de réinstaller le système…

          Et pourtant, encore aujourd'hui, certains constructeurs n'ont rien compris au libre et au confort qu'il pouvait apporter, et continuent de proposer des binaires séparément, comme sous Windows [2].

          Je ne suis pas un intégriste du libre et ne suis donc pas opposé à l'utilisation, avec parcimonie, d'un nombre limités de logiciels propriétaires absolument nécessaires sur l'instant, mais à la condition que les utilisateurs soient conscients de ce que cela implique, et que l'on cherche à développer, améliorer, financer des alternatives libres le plus rapidement possible.

          [1] http://www.freesoftwaremagazine.com/articles/ubuntu_software_center_proprietary_and_free_software_mixed_confusing_ui
          [2] https://www.phoronix.com/scan.php?page=news_item&px=DisplayLink-USB-3.0-Driver

          • [^] # Re: Tu peu même élargir ...

            Posté par . Évalué à -10.

            Merci pour ce grand moment d'humour !

            Population qui pourrait, à terme, cloner les comportements et la situation que l'on retrouve aujourd'hui sous Windows (récupérer des logiciels n'importe où, installer n'importe quoi, se retrouver avec des bloatwares, adwares, des barres de recherche qui s'accumulent…)

            C'est faux. Le Windows store evite tous ces problèmes. Rien à voir avec le libre.

            Même chose pour les drivers. Le fait qu'ils soient libres, inclus dans le kernel, permet (ou du moins, c'est l'idéal vers lequel on tend) de voir son matériel parfaitement supporté sans que l'utilisateur n'ai besoin de faire quoi que ce soit, de pouvoir maintenir le support dans le temps, de faire en sorte que tout soit parfaitement à jour avec une simple mise à jour du kernel, de pouvoir déplacer un disque système d'une machine à l'autre sans avoir besoin de réinstaller le système…

            Ou comment parler de théorie sans jamais avoir fait l'expérience de la réalité…

            Allez, petit exemple pratique…

            La société X sort le 8 aout 2015 un nouveau matériel, ou un soft, qui a besoin d'un module kernel (bref, un driver).

            Elle fait comment pour que son matériel/soft tourne sur les Linux existants chez les utilisateurs qui sont du Ubuntu 12.04, 14.04, Redhat 6, OpenSuse 11, Debian x/y, etc… ? Ah oui tiens, c'est 3252 versions différentes de kernel, avec l'ABI qui casse quasiment à chaque update, qui sortent à des périodes différentes, à des fréquences différentes, avec des règles différentes pour l'inclusion de modules dans les dépots, etc…

            Tout ca pour supporter 1% du marché desktop.

            Sous Windows ? Ils peuvent dans la plupart des cas faire un driver qui tournera sur toutes les versions depuis Vista. Ca couvre 90% du marché desktop.

            Ca, c'est la réalite.

            L'inclure dans le kernel mainline ne résoud absolument rien du tout.

            • [^] # Re: Tu peu même élargir ...

              Posté par (page perso) . Évalué à 10.

              L'inclure dans le kernel mainline ne résoud absolument rien du tout.

              Si.

            • [^] # Re: Tu peu même élargir ...

              Posté par (page perso) . Évalué à 8.

              Pour ses versions LTS, Ubuntu met régulièrement à jour ses kernels, en backportant celui de la dernière version non LTS en date.

              Ensuite, au niveau des constructeurs, je pense que le mieux à faire, c'est de ne pas réagir le jour de la sortie commerciale du produit, mais commencer à contribuer au kernel bien en amont. C'est ce que fait d'ailleurs Intel, dont le support de ses processeurs, chipsets, IGP… était présent plusieurs mois avant la sortie du produit.

              • [^] # Re: Tu peu même élargir ...

                Posté par . Évalué à -10.

                Ah oui c'est bien marrant ca !

                Un constructeur / editeur doit attendre que Ubuntu fasse son update tous les X mois, et prier pour que tout le monde l'installe rapidement. Oh, et il attendra aussi pour Suse, pour Debian, etc… qui ont tous leur cadence, diffèrentes bien entendu.

                Ensuite, contribuer bien en amont, quand tu veux faire une sortie avec un effet de surprise sans que ta concurrence s'en rende compte et te suive pas à pas, super !

                Sérieusement, t'as déjà bossé dans une boite qui développe des produits ? Tu te rends compte à quel point ce que tu décris est horrible pour une société ?

                • [^] # Re: Tu peu même élargir ...

                  Posté par (page perso) . Évalué à 10.

                  Tu te rends compte à quel point ce que tu décris est horrible pour une société ?

                  Il parle d'Intel, pas de la boîte d'informatique du bled du coin…

            • [^] # Re: Tu peu même élargir ...

              Posté par . Évalué à 10.

              C'est faux. Le Windows store evite tous ces problèmes. Rien à voir avec le libre.

              Oui, c'est d'ailleurs parce que ça marche tellement bien que Microsoft essaie de tout nettoyer avant que les utilisateurs de Windows 10 ne bloatent leur système

              Soyons sincères (et ça vaut pour Android et iOS aussi) : de la manière dont ils fonctionnent (avec comme principe de base qu'il faut tout avoir, parce que sinon l'utilisateur ne sera pas content et ira ailleurs), aucun store ne peut prétendre à régler les problèmes de bloatwares, spywares, logiciels dangereux et autres scams.
              Je ne dis pas que c'est pire qu'avant, mais je ne vois sincèrement pas d'énorme amélioration…

              Pour les drivers, Linux n'est effectivement pas le paradis des indolents qu'est Windows (où tu peux littéralement faire n'importe quoi et t'attendre à ce que les devs de Microsoft se débrouillent pour que tes produits marchent encore, il suffit d'aller faire un tour sur le par ailleurs très instructif blog theoldnewthing pour en voir d'excellents exemples), mais, bien franchement, pour beaucoup de produits, ça n'a rien d'incroyablement complexe. Si tu produis un périphérique pour lequel des standards existent (ex. UVC pour les caméras, Postscript pour les imprimantes—même si dans ce dernier cas je simplifie un peu) alors ça marche direct. Si tu produis un périphérique simple (comme beaucoup de petites boîtes), pour lesquels une liaison série virtuelle ou un simple driver codé avec l'API USB du kernel suffit, alors ça va aussi.

              De plus, lorsqu'une compagnie accepte de libérer son driver et de l'inclure dans le kernel, alors les cassages d'ABI (voir d'API interne) ne sont plus un problème puisque tout peut être modifié d'un coup par les devs du kernel : ton driver fonctionne alors peu-importe la version du kernel.

              Bref, je ne prétends pas que Linux soit le meilleur des mondes pour le fabricant qui veut juste sortir son produit et faire du pognon avec pendant 15 ans sans toucher à une ligne de code, mais il ne faut pas exagérer dans l'autre sens non plus et faire croire que les devs s'amusent à changer l'ABI à tous les deux jours rien que pour énerver les gens…

              • [^] # Re: Tu peu même élargir ...

                Posté par . Évalué à -10.

                Un store ne sera effectivement jamais 100% sur, mais c'est tout à fait vrai pour les depots aussi. Ensuite, le système de sandbox dans ces OS limite de manière assez effective l'effet de ces malwares.

                Pour Linux et les drivers, le scenario que j'ai donné plus haut je ne l'ai pas sorti de mon chapeau hein, et il bloque à lui seul nombre de développements. Parce que l'insertion dans mainline, ça prend du temps, le produit il doit sortir hier, il doit supporter autant de systèmes que possible, et il faut que ce soit pas cher à maintenir.

                Et l'approche Linux avec cassage d'ABI rend ces développements horriblement complexe et couteux. Tu regardes Ubuntu 14.x, toutes les 2-3 semaines l'ABI est cassé dans une update. Un éditeur serait obligé de se taper une update chaque mois, avec la batterie de tests afférents, le packaging, etc… les utilisateurs se verraient avec un kernel teinté car le module n'est pas dans le noyau de base ce qui limite l'adoption, etc…

                • [^] # Re: Tu peu même élargir ...

                  Posté par . Évalué à 10.

                  Un store ne sera effectivement jamais 100% sur, mais c'est tout à fait vrai pour les depots aussi.

                  Oui, tout comme il est vrai que "une relation sexuelle non protégée ne sera jamais 100% sur, mais c'est tout à fait vrai pour les relations avec préservatif aussi"…

                  Par ailleurs, oui, les sandbox limitent les dégâts, mais ça n'a rien à voir avec le mode de distribution et je répondais à ta remarque :

                  Le Windows store evite tous ces problèmes.

                  Sinon :

                  Pour Linux et les drivers, le scenario que j'ai donné plus haut je ne l'ai pas sorti de mon chapeau hein, et il bloque à lui seul nombre de développements. Parce que l'insertion dans mainline, ça prend du temps, le produit il doit sortir hier, il doit supporter autant de systèmes que possible, et il faut que ce soit pas cher à maintenir.

                  À t'entendre, on jurerait que tu soutiens que le modèle de Windows encourage les développements à la va-vite, avec une avalanche de modifications à la dernière minute "parce qu'il faut sortir le produit hier", et qui ne vont surtout pas prendre du temps pour corriger les bugs et limitations du driver parce que sinon c'est trop cher à maintenir…
                  Un contre-argument serait de me répondre que si les boîtes veulent faire des drivers moisis et pas aboutis, ce n'est pas le problème de Microsoft, et ce n'est pas formellement faux, mais ça ne me ravit pas pour autant.

                  Cependant, il y a nombre d'initiatives pour faciliter l'inclusion de drivers dans Linux (à commencer par la branche staging), et, bien que je n'ai honnêtement pas de statistiques pour confirmer la chose, je doute qu'un driver bien conçu et relativement simple (comprendre : pas un nouveau driver de carte vidéo) requiert tant de temps pour entrer dans le kernel; une fois qu'il y est, la maintenance "de base" (e.g. suivre les changements d'API et d'ABI internes) est pour ainsi dire gratuite…

                  En bref, je pense qu'on peut résumer la chose par ces constatations. Le modèle de Microsoft, c'est "faites n'importe quoi tant que ça marche dans une configuration donnée de Windows, et on vous couvrira jusqu'à la mort", alors que celui de Linux, c'est "Linux doesn’t support external modules, if you use an external module, you are own your own."

                  Je peux voir l'avantage économique que peut avoir le modèle de Microsoft, mais je ne suis quand même pas certain que c'est ainsi que je veux voir développer des bouts de code capables potentiellement d'accéder à pas mal de choses dans mon ordinateur…

                  • [^] # Re: Tu peu même élargir ...

                    Posté par . Évalué à -10.

                    LOL merci pour ce grand moment d'humour.
                    Les tests WHQL que les drivers doivent passer pour etre signé par MS sont largement plus aboutis que ce qui se trouve sur Linux pour tester les modules kernel, et de très très loin.

                    Faudrait quand même penser à regarder objectivement ce dont tu parles avant de sortir des trucs pareils.

                    • [^] # Re: Tu peu même élargir ...

                      Posté par . Évalué à 1. Dernière modification le 11/08/15 à 10:23.

                      Mon cher PasBillPasGate…
                      C'est à se demander si un jour tu as utilisé des ordinateurs tournant sous Windows.
                      Moi oui !!
                      Si tu savais les problèmes que j'ai rencontré…..
                      Du coup j'ai changé de crémerie …
                      Tu pourras me sortir tous les arguments de la terre que tu veux, mais il n'y a plus rien à faire !!! La confiance a été rompue.

                      J'ai actuellement plus confiance dans ma distribution que dans n'importe quel système Microsoft, même si rien n'est parfait. Le jour où Microsoft sera en capacité de me dire : "vous pouvez avoir confiance" peut être que je changerais d'avis.Mais pour le moment, Microsoft a un gros travail à faire sur lui même et dans tous les domaines. En particulier sur ses méthodes de ventes et sur les méthodes de développement. Je pourrais dire d'ailleurs à peu près la même chose pour Apple.

                      J'ai cru comprendre que ce travail était plus ou moins en train de se faire. Mais on en est loin. Très loin. Et beaucoup trop loin pour moi.

                      • [^] # Re: Tu peu même élargir ...

                        Posté par (page perso) . Évalué à 8.

                        Si tu savais les problèmes que j'ai rencontré…

                        Si t'argumentes pas, tu vas te faire défoncer :p

                        Moi aussi je veux taper sur Windows, le plus gros reproche que je peux lui faire niveau driver, c'est que contrairement à Linux, tu ne peux pas déplacer ton disque dur d'une machine à une autre ou pire, d'un serveur sur un PC. Parfois ça fonctionne, mais souvent on a droit à un écran bleu, surement parce que le driver SATA du constructeur au lieu de dire: "c'est pas mon matos, utilise le driver générique", se tape un beau segfault.

                        C'est quand même vachement pratique dans une petite structure quand tu as un serveur qui a crashé et que tu attends le support de DELL…

                        • [^] # Re: Tu peu même élargir ...

                          Posté par . Évalué à 1.

                          Oui
                          Je suis Mr Michu. Je suis incapable de tripatouiller la moindre ligne de code.
                          Je suis un consommateur de base.

                          C'était il y a longtemps. C'était avec l'acquisition de mon premier photo numérique à la FNAC. Il était en solde parce que il ne faisait qu'un seul million de pixels alors que les nouveaux modèles qui commençaient à sortir en faisait 2. Le prix était intéressant. Un appareil d'une très grande marque et fabricant de pellicules qui depuis a fait faillite.

                          L'interface de Windows est devenue moitié anglaise moitié françaises.

                          Comme je suis justement un consommateur de "base" j'en ai ch..r pour comprendre ce qui m"arrivait. Une fois mon problème résolu, je me suis posé des questions. Devais je porter plainte ? Changer de crémerie ? J'ai changé de crémerie.

                          C'était l'époque où IE avait été intégré à l'OS. C'était l'époque ou les logiciels (du moins certains) avaient besoin d'IE pour fonctionner.

                          Ah !!!! pratiquement sans rien y connaitre, quel souvenir de ma toute première installation d'une distribution Linux. A l'époque, l'installation avait du prendre 40 mn et au bout de ces 40 mn j'avais un système totalement fonctionnel. Finger in the nose comme l'on dit.

                          • [^] # Re: Tu peu même élargir ...

                            Posté par . Évalué à 4.

                            C'était il y a longtemps. […] C'était l'époque où IE avait été intégré à l'OS.

                            T'as conscience que t'es en train de parler d'un truc qui t'es arrivé il y environ 15 ans (la polémique de l'intégration d'IE remonte à la fin des années 90) ?
                            Mon expérience de Linux à cette époque c'était X11 en 640x480 16 couleurs parce que j'avais pas la bonne release d'ATI Mach64. Je n'en tire pas des généralités.

                            Devais je porter plainte ?

                            Oui, bien sûr. Pour crime contre l'humanité au moins.

                            • [^] # Re: Tu peu même élargir ...

                              Posté par . Évalué à 1.

                              Non. Je n'ai pas porté plainte.
                              Pourquoi ? Parce que je savais dès le départ que cela n'avait aucune chance d'aboutir. Je vous laisse deviner pourquoi ;-)

                              Changer de crémerie m'a ainsi semblé une réponse bien plus appropriée. C'est aussi en changeant de crémerie que j'ai découvert ce nouvel univers, pour moi.

                              Ce n'est pas compliqué: ce fût juste une révélation. Tous les jours que Dieu fait, je dis merci à cet appareil photo qui, depuis a été transformé recyclé mais que je n'ai pas encore rencontré sur un banc public ou dans une bouilloire :-)

                              • [^] # Re: Tu peu même élargir ...

                                Posté par (page perso) . Évalué à 2.

                                Je vous laisse deviner pourquoi ;-)

                                je pense le savoir :D

                                Merci pour tes remontées factuelles sur MLO, c'est ce comportement qui aide souvent à identifier sur des cas concrets comment faire fonctionner quelques matériels récalcitrants (paquet non installé automatiquement, combinaison de touche pour l'activer, parfois bug résiduel ou évolution non encore intégrée…).

                              • [^] # Re: Tu peu même élargir ...

                                Posté par . Évalué à 2.

                                Pourquoi ? Parce que je savais dès le départ que cela n'avait aucune chance d'aboutir. Je vous laisse deviner pourquoi ;-)

                                Parce que tu n'aurais jamais été capable de prouver qui était en tort entre Microsoft caca et Canon pipi ? ;-)
                                Parce que les CLUFs et CGU/GVU prévoient des clauses de limitations de responsabilités, qui même si elles ne s'appliquent jamais à plein (CJUE toussa), t'auraient mis des méchants bâtons dans les roues ? ;-)
                                Parce que de toute façon, il n'y a pas de préjudice chiffrable ? ;-)
                                Parce que les juges sont des maichants à la solde de l'establishment ? ;-)

                                • [^] # Re: Tu peu même élargir ...

                                  Posté par . Évalué à 1. Dernière modification le 11/08/15 à 21:10.

                                  bah..;
                                  Finalement, et en effet: tu as complètement raison.

                                  La condamnation a fini par tomber toute seule. Une recherche dans Eur lex permet de trouver la décision (enfin plutôt les décisions)

                                  :-)

                                  Promis : j'y suis pour rien :-)

                          • [^] # Re: Tu peu même élargir ...

                            Posté par (page perso) . Évalué à 4.

                            L'interface de Windows est devenue moitié anglaise moitié françaises.

                            Wai, enfin si il fonctionnait sous Linux (Mass storage ou PTP), il fonctionnait aussi sous Windows sans le logiciel en question…

                            • [^] # Re: Tu peu même élargir ...

                              Posté par . Évalué à 7. Dernière modification le 11/08/15 à 14:42.

                              Très sûrement. Mais ce que je reproche à Windows, c'est aussi l'espèce de magma coutumier qu'il y a autour, c'est le driver d'imprimante qui fait 200Mo, ou l'appareil photo qui t'expliques qu'il faut d'abord installer un driver.
                              C'est pas la faute à Microsoft en soit, mais ça va tellement avec maintenant que je ne supporte plus.

                              Putain l'autre jour j'achète pour ma femme une imprimante photo (Epson pour pas citer la marque). Moderne, elle fait scanner, wifi etc. L'ordi de ma femme est resté sous Windows (vieux débat de couple, passons). Bon, je vais sur le site Epson, je télécharge mes centaines de Mo, j'installe le driver imprimante connectée en USB (obligatoire), puis je débranche en passant par le WiFi. Ça marche bien.

                              Je vais ensuite sur mon poste Linux (Debian unstable par défaut, rien d'exotique du tout), je lui demande d'installer une nouvelle imprimante, puis j'ai une boite de dialogue "elle est réseau ? usb ? ou alors est-ce que par hasard ce serait pas la Epson WXZ789 que je détecte ?". Je sélectionne cette dernière. Ça marche.

                              Résultat : les 2 marchent très bien depuis, mais pourquoi diable m'a-t-il fallut télécharger des kyrielles de conneries en étant sous Windows ?

                              • [^] # Re: Tu peu même élargir ...

                                Posté par (page perso) . Évalué à 5.

                                L'installation d'un driver sous Windows(même quand il fait 200Mo), c'est désarchivage avec 7zip -> Gestionnaire de périphérique -> Chercher le .inf

                                Toute autre méthode est vouée à pourrir ton Windows. Mais Microsoft ne peux pas empêcher les constructeur de faire tout pour neuneuiser l'utilisateur final. Ce qu'il manque à Windows, c'est de vraiment avoir une base de driver à jour sur le net, la fonctionnalité existe, je ne l'ai jamais vu fonctionner.

                                • [^] # Re: Tu peu même élargir ...

                                  Posté par . Évalué à 3.

                                  Exactement. Une bonne base de données de drivers (juste driver au sens OS du terme, pas gadgets de merde qui se foutent dans la barre des tâches) en ligne et c'est plié, ça rendra bcp, bcp plus de services pour Mme Michu que des clicotrons insupportables.

                                  Et qu'on me raconte pas que c'est pas possible par que chaque constructeur fait ce qu'il veut. Avec leur certification WHQL (je sais pas l'acronyme exact, mais ça doit ressembler à ça) c'est pas dur de rajouter une clause "et en plus vous nous fournirez le inf/dll strictement nécessaires".

                          • [^] # Re: Tu peu même élargir ...

                            Posté par (page perso) . Évalué à 2.

                            C'était l'époque où IE avait été intégré à l'OS. C'était l'époque ou les logiciels (du moins certains) avaient besoin d'IE pour fonctionner.

                            Ah !!!! pratiquement sans rien y connaitre, quel souvenir de ma toute première installation d'une distribution Linux. A l'époque, l'installation avait du prendre 40 mn et au bout de ces 40 mn j'avais un système totalement fonctionnel.

                            Ce n'est pas ma première expérience de GNU/Linux. Ce dont tu parles se situe approximativement il y a 15 ans. A cette époque, rien que pour lire une vidéo ou imprimer un texte sous Linux, ça pouvait prendre des heures de configuration…

                      • [^] # Re: Tu peu même élargir ...

                        Posté par . Évalué à -3.

                        Tu sais, essayer de faire changer d'avis quelqu'un qui se limite à ce qu'il a eu il y a 15 ans et parle des versions d'aujourd'hui sans jamais y avoir touché ben comment dire… on s'en fiche un peu ?

                        • [^] # Re: Tu peu même élargir ...

                          Posté par . Évalué à 1.

                          détrompes toi !!!
                          Au taff, mon employeur me colle un W7 ….

                        • [^] # Re: Tu peu même élargir ...

                          Posté par . Évalué à 2.

                          Tout le monde a du Windows au boulot… il me manque pas bcp de versions de Windows que j'ai jamais testé (style Windows2000 par exemple).

                    • [^] # Re: Tu peu même élargir ...

                      Posté par . Évalué à 8.

                      Les tests WHQL que les drivers doivent passer pour etre signé par MS sont largement plus aboutis que ce qui se trouve sur Linux pour tester les modules kernel, et de très très loin.

                      Ah non, mais ça ça ne va pas du tout! Parce que vois-tu, les tests WHQL bloquent clairement à lui seul nombre de développements. Parce que l'insertion dans mainline la certification WHQL, ça prend du temps, le produit il doit sortir hier, il doit supporter autant de systèmes que possible (ça inclut donc devoir faire signer le driver par Microsoft, sinon le noyau ne veut même pas le lancer sur les systèmes 64 bits), et il faut que ce soit pas cher à maintenir (ça inclut refaire les tests WHQL à chaque itération du driver, même une révision mineure), etc., etc.

                      En fait, c'est un peu la même chose que l'insertion dans mainline : et si je ne veux pas moi, faire certifier mon driver? C'est exactement la même problématique que : et si je ne veux pas moi, open-sourcer mon driver et l'inclure dans le kernel?
                      Bah si tu ne veux pas, tu te débrouilles…

                      Note que je n'ai aucun problème envers la certification WHQL en soi, je pense que c'est déjà un bon système qui a limité grandement le nombre de drivers pourrave, mais je veux juste te faire remarquer à quel point il est facile de descendre un système à grand coup de "les entreprises n'aiment pas ça"…

                      • [^] # Re: Tu peu même élargir ...

                        Posté par . Évalué à 1.

                        Note que je n'ai aucun problème envers la certification WHQL en soi, je pense que c'est déjà un bon système qui a limité grandement le nombre de drivers pourrave, mais je veux juste te faire remarquer à quel point il est facile de descendre un système à grand coup de "les entreprises n'aiment pas ça"…

                        Ben justement non.

                        WHQL permet à une entreprise de faire les drivers à son rythme, quand elle veut, sans dépendence. Tant que son driver passe les tests, il sera disponible pour tout le monde.

                        Linux ? Ben à moins de se mettre à parler a Ubuntu, Suse, etc… 6 mois-1 an avant la sortie, ce qui est absolument énorme, c'est impossible, et ils ne pourront pas non plus avoir une sortie synchronisée sur les diffèrentes distribs, leurs concurrents vont voir le module kernel apparaitre des mois avant la sortie finale du produit, avoir le temps de faire du reverse engineering dessus et réagir, etc…

                        Et le pire, c'est que vous croyez probablement tous que je dis ça pour descendre Linux au profit de Windows sans savoir de quoi je parles, la triste nouvelle est que je suis en train de passer à travers cette horreur en ce moment même pour un module noyau Linux, et que nombre de gens au boulot poussent pour l'abandon de ce module à cause justement de tous ces problèmes.

                        A un moment va falloir que vous ouvriez les yeux, arrétez de vous braquer à la moindre critique, et vous rendre compte que le système actuel à des limites sérieuses qui empêchent nombre de sociétés de développer des trucs sympa sur Linux car le modèle ne colle pas du tout à ce dont un éditeur a besoin.

                        La problématique est simple : Comment une société, qui veut faire du développement rapide, sortir des produits avec des itérations successives tous les quelques mois qui puissent être installées par la majorité du marché, peut faire sur Linux si elle a besoin d'un module noyau ?

                        Vraiment, posez ça sur une feuille de papier, les étapes les unes après les autres, avec le temps que cela demande à chaque étape, la dépendance sur des groupes externes, le risque de fuite sur un nouveau projet, etc… Arrétez de vous exciter à la moindre critique et faites l'exercice sérieusement, alors vous vous rendrez compte à quel point c'est douloureux.

                        • [^] # Re: Tu peu même élargir ...

                          Posté par (page perso) . Évalué à 5.

                          si tu veux t'en sortir avec un module externe de l'arbre Linux, dkms reste le plus simple àmha : http://mageia.madb.org/package/list/t_search/dkms/application/0 il y a tout de même pas mal de pilotes qui réussissent à s'y adapter…

                          sur eagle-usb, lorsque le fast 800 E3 est sorti, nous avions reçu un patch de ADI, lorsque le fast 800 E4 est sorti nous avons reçu le patch de Sagem iirc (bon, ils avaient du GPL depuis le début… ça aide :D même si c'est la réécriture complète et l'inclusion directement dans l'arbre Linux qui a réduit drastiquement la maintenance…).

                          pour du matériel basé sur des standards, l'ajout de vendor_id/product_id (voire subv et subp) peut suffire, il faudrait que je revoie l'histoire des DeviceTree : je crois que cela simplifie grandement.

                          Pour les pilotes hors matériel, skype y arrive ainsi que vbox (via dkms d'ailleurs), autant leur demander :D Sinon se baser sur des standards aide grandement.

                          • [^] # Re: Tu peu même élargir ...

                            Posté par . Évalué à 2.

                            dkms est bien, le problème c'est qu'il ne résoud pas tout (pas sur Fedora notamment) et qu'il force l'installation de compilateur et tout ce qui vient avec.

                            Tu prends le standard PCI pour les systemes ayant des données sensibles, il demande que seul le minimum soit installé sur ces systèmes. Quand on va expliquer à ces utilisateurs qu'ils doivent mettre un compilateur, make, etc… sur leurs machines, ils ont une crise cardiaque.

                            De nouveau, c'est pas de la théorie là, c'est du vécu.

                        • [^] # Re: Tu peu même élargir ...

                          Posté par . Évalué à 7.

                          Encore une fois, je ne prétends pas que le modèle de développement des drivers sous Linux soit la meilleure chose que la Terre ait connue après le scotch-tape double face, mais plutôt qu'il faut pondérer les avantages et inconvénients de chaque modèle.
                          C'est certain que si une entreprise développe des bidules pour Windows depuis 15 ans et qu'elle se met soudain au développement sous Linux, alors ses devs vont probablement râler. Cela veut-il dire que l'approche est fondamentalement mauvaise? Je ne crois pas.

                          Il y a en fait encore beaucoup d'idées reçues à propos du développement de drivers sous Linux, et, autant je ne suis clairement pas un expert de la certification WHQL et du développement sous Windows, autant je pense que tu ne l'es pas non plus sous Linux. Par exemple :

                          Linux ? Ben à moins de se mettre à parler a Ubuntu, Suse, etc… 6 mois-1 an avant la sortie, ce qui est absolument énorme, c'est impossible, et ils ne pourront pas non plus avoir une sortie synchronisée sur les diffèrentes distribs

                          Régler ce problème est exactement le but visé par le Driver Backport Workgroup de la Linux Foundation.

                          leurs concurrents vont voir le module kernel apparaitre des mois avant la sortie finale du produit, avoir le temps de faire du reverse engineering dessus et réagir

                          On revient à la bonne vieille critique du libre : "bouh mais mon concurrent va pouvoir copier sur moi…". Sinon, il est tout à fait possible de travailler de manière confidentielle un bon moment avec les développeurs du noyau, grâce au Linux Foundation NDA Program.

                          Et encore, je ne parle pas du Linux Driver Project, qui (je cite) :

                          [Permet aux fabricants de] get their driver written for free by volunteer kernel developers. The IHV provides a specification that describes how their device works, the email address of an engineer willing to answer questions, and (ideally) a few sample devices. An expert developer team of volunteers led by Greg Kroah-Hartman returns a complete and working Linux driver that is added to the mainline Linux kernel source tree.
                          The driver (like all Linux drivers) is automatically kept up to date and working through all Linux kernel API changes. The driver will work with all of the different CPU types supported by Linux, the largest number of CPU types supported by any operating system ever. At the IHV's option, the work can be done under LF NDA program.

                          Je ne parle pas non plus de l'appel explicite des développeurs centraux aux mainteneurs à merger le plus rapidement possible les drivers, tant que ces derniers n'affectent pas le reste du noyau.

                          Toutes les références sont sur cette page de la Linux Foundation, par ailleurs très facile à trouver soit dit en passant.

                          Je passe par ailleurs sur tous les aspects techniques favorisés par les changements d'ABI possible (simplicité du code, sécurité, augmentation des performances "gratuite" dans certains cas, etc.)

                          Bref, bien sûr qu'il y a matière à critique, mais il ne faut pas amplifier cette dernière sous prétexte que les éditeurs tiennent absolument à rester à un mode de développement qui avait cours à la sortie de Windows XP…

                          • [^] # Re: Tu peu même élargir ...

                            Posté par . Évalué à -2.

                            Régler ce problème est exactement le but visé par le Driver Backport Workgroup de la Linux Foundation.

                            Ah oui, ce workgroup qui n'a pas eu le moindre post sur sa ML depuis Mars 2013 et une main page pas updatée depuis Fevrier 2014 ? ( http://lists.linuxfoundation.org/pipermail/lf_driver_backport/ )

                            On revient à la bonne vieille critique du libre : "bouh mais mon concurrent va pouvoir copier sur moi…". Sinon, il est tout à fait possible de travailler de manière confidentielle un bon moment avec les développeurs du noyau, grâce au Linux Foundation NDA Program.

                            Ce qui ne résoud absolument rien à la problématique d'avoir les drivers sur les distribs déjà sorties. Le problème n'est pas d'écrire le driver, je l'ai fini le driver, le problème c'est le faire tourner sur les distribs existantes, s'assurer qu'il est updaté quand une update du kernel est installée sur ces distribs, etc…

                            Je ne parle pas non plus de l'appel explicite des développeurs centraux aux mainteneurs à merger le plus rapidement possible les drivers, tant que ces derniers n'affectent pas le reste du noyau.

                            Ce qui ne résoud absolument rien à la problématique d'avoir les drivers sur les distribs déjà sorties.

                            Non vraiment, c'est beau de sortir la théorie, je te suggères d'essayer en pratique, tu m'en diras des nouvelles.

                            • [^] # Re: Tu peu même élargir ...

                              Posté par . Évalué à 10.

                              Le Driver Backport Workgroup s'est concrétisé dans le projet Backports, qui, comme tu peux le constater, a une mailing list relativement conséquente et toujours bien active et supporte les kernels depuis le 2.6.26.

                              Non, ils ne supportent pas tous les types de drivers (pour le moment), c'est vrai. Mais c'est déjà un bon début.

                              Ce qui ne résoud absolument rien à la problématique d'avoir les drivers sur les distribs déjà sorties. Le problème n'est pas d'écrire le driver, je l'ai fini le driver, le problème c'est le faire tourner sur les distribs existantes, s'assurer qu'il est updaté quand une update du kernel est installée sur ces distribs, etc…

                              Et le driver, tu l'as fini 2 jours avant de devoir livrer le produit? Parce que fondamentalement, c'est ça le problème…

                              Pour ce qui est de le faire tourner sur les distribs existantes, si tu tiens absolument à rester hors de l'arbre principal du kernel, tu fais comme tous les fabricants de matériel : tu certifies le fonctionnement sur certaines distros commerciales (RedHat, Suse, Ubuntu, etc.) et si l'utilisateur veut l'installer sur son Damn Small Linux, ben c'est son problème (ou plutôt le tien, puisque cet utilisateur là, pour qui tout aurait bien fonctionné si tu avais empaqueté ton driver dans le kernel, n'achèteras probablement plus tes produits).

                              Par ailleurs, pour ta gouverne, les grosses boîtes (au moins RedHat et Suse) garantissent une ABI stable dans les révisions mineures (regarde par exemple le paquet kabi-whitelists dans RHEL), donc rendu là tu n'as pas à te soucier des updates.

                              Encore une fois, non ce système n'est pas parfait. Par exemple, une amélioration possible (il me semble que ça s'était discuté sur LWN, je ne retrouve plus le lien) serait d'empaqueter les drivers dans le main line, dès leur inclusion dans stagging, sous réserve qu'il soit démontré qu'ils n'affectent pas le reste du système, mais avec potentiellement un tag spécial pour indiquer que ce sont encore des drivers expérimentaux. Ça réduirait drastiquement le temps requis pour être inclus dans les principales distros (y compris celles déjà sorties, puique toutes les distros backportent les drivers dans leurs révisions mineures…)

                              Après, effectivement, si tu es une boîte qui compte distribuer planétairement un produit dont le driver a été terminé une semaine avant la sortie commerciale, le modèle de Windows convient mieux.
                              La question que je me pose, c'est surtout de savoir si je veux acheter ce genre de produits…

                              • [^] # Re: Tu peu même élargir ...

                                Posté par . Évalué à -1.

                                Et le driver, tu l'as fini 2 jours avant de devoir livrer le produit? Parce que fondamentalement, c'est ça le problème…

                                2 jours non, je suis sensé le finir 6 mois avant aussi ? A chaque update je dois attendre 6 mois ? Sur des projets dont le cycle est de moins de 6 mois, on va dire que c'est pas top.

                                Pour ce qui est de le faire tourner sur les distribs existantes, si tu tiens absolument à rester hors de l'arbre principal du kernel, tu fais comme tous les fabricants de matériel : tu certifies le fonctionnement sur certaines distros commerciales (RedHat, Suse, Ubuntu, etc.) et si l'utilisateur veut l'installer sur son Damn Small Linux, ben c'est son problème (ou plutôt le tien, puisque cet utilisateur là, pour qui tout aurait bien fonctionné si tu avais empaqueté ton driver dans le kernel, n'achèteras probablement plus tes produits).

                                Ça on est bien d'accord, c'est pas le problème.

                                Après, effectivement, si tu es une boîte qui compte distribuer planétairement un produit dont le driver a été terminé une semaine avant la sortie commerciale, le modèle de Windows convient mieux.

                                Le problème c'est d'être forcé à être en synchro complète avec ces 232 diffèrents kernels des distribs. Ca crée plusieurs dépendences externes sur lesquelles il y a très peu de contrôle, qui se chevauchent, … C'est juste le bordel, c'est compliqué et couteux.

                                La question que je me pose, c'est surtout de savoir si je veux acheter ce genre de produits…

                                Tous les produits que tu achètes ont été terminé 3 mois avant leur sortie ? Ils font quoi les développeurs entre temps ? Du ski ?

                                • [^] # Re: Tu peu même élargir ...

                                  Posté par . Évalué à 5.

                                  2 jours non, je suis sensé le finir 6 mois avant aussi ? A chaque update je dois attendre 6 mois ? Sur des projets dont le cycle est de moins de 6 mois, on va dire que c'est pas top.

                                  6 mois, c'est effectivement trop long dans la plupart des cas (même si il y en a certains à qui ça convient, comme par exemple Intel). Ceci étant, je n'ai aucune statistique sur le délai moyen entre un premier pull request dans stagging et une inclusion dans le mainline.

                                  Par contre, si tu es dans le kernel, non, tu n'as pas à attendre 6 mois pour chaque update; une fois le driver inclus, les itérations sont beaucoup plus rapides.

                                  Par ailleurs, je réitère : beaucoup de périphériques n'ont pas à avoir un driver en espace noyau. C'est particulièrement vrai pour la plupart des périphériques d'acquisition de données ou de contrôle. Dès que tu peux passer par l'USB et que tu n'as pas à contourner le contrôleur standard de Linux pour gérer les bugs de ton périphérique, alors ton driver peut tout à fait résider en espace utilisateur (privilégié) et utiliser l'API/ABI USB standard et stable pour communiquer avec le périphérique.

                                  Je donne un exemple, je ne dis pas que c'est le plus pertinent, mais c'est le premier qui me vient en tête vu mon occupation actuelle : Phidgets, qui est une boîte dont le coeur de métier est la commercialisation de senseurs et contrôleurs faciles à interfacer (autant au niveau hardware que software). Leur driver est une simple librairie qui supporte C/C++, C#, Python, Java, VB.NET, etc. et qui est binairement compatible avec pour ainsi dire toutes les distributions (en autant que libusb soit installé, ce qui est un prérequis acceptable je crois).
                                  Et ça tombe très bien pour eux : effectivement, lorsqu'ils sortent un nouveau produit (par exemple un nouveau thermocouple), ils n'ont pas envie d'attendre plusieurs mois pour qu'il soit pris en charge par les systèmes Linux, mais il leur suffit de mettre à jour leur librairie et ça marche automatiquement partout.

                                  Je ne dis pas que tout le monde peut faire ça, mais pour la plupart des boites dont l'écriture de drivers n'est pas le coeur de métier (par exemple des compagnies qui veulent commercialiser un nouveau produit dont le driver n'est qu'une interface, l'innovation étant vraiment dans le produit en soi), il n'y a aucun problème avec le modèle actuel.

                                  Pour les boites plus grosses, pour qui les drivers représentent en soi un atout important, oui, j'espère que ceux-ci sont terminés 3 mois avant la sortie du produit qu'ils accompagnent, et que les développeurs sont passés à l'écriture du driver de la génération suivante.

                                  • [^] # Re: Tu peu même élargir ...

                                    Posté par . Évalué à 2.

                                    6 mois, c'est effectivement trop long dans la plupart des cas (même si il y en a certains à qui ça convient, comme par exemple Intel). Ceci étant, je n'ai aucune statistique sur le délai moyen entre un premier pull request dans stagging et une inclusion dans le mainline.

                                    mainline on s'en fiche. Ce qui importe c'est le délai pour que le pekin moyen sur son Ubuntu/Suse/… le reçoive. C'est la seule date qui compte pour l'éditeur.

                                    Par ailleurs, je réitère : beaucoup de périphériques n'ont pas à avoir un driver en espace noyau.

                                    Bien évidemment que pour ceux-ci le problème ne se pose pas, mais on ne parle pas d'eux ici.

                                    Je ne dis pas que tout le monde peut faire ça, mais pour la plupart des boites dont l'écriture de drivers n'est pas le coeur de métier (par exemple des compagnies qui veulent commercialiser un nouveau produit dont le driver n'est qu'une interface, l'innovation étant vraiment dans le produit en soi), il n'y a aucun problème avec le modèle actuel.

                                    Là tu te fourvoies. Il y a nombre de choses ou un driver noyau est essentiel pour le bon fonctionnement de la chose, et cela n'inclut pas forcèment du matériel.

                                    Pour les boites plus grosses, pour qui les drivers représentent en soi un atout important, oui, j'espère que ceux-ci sont terminés 3 mois avant la sortie du produit qu'ils accompagnent, et que les développeurs sont passés à l'écriture du driver de la génération suivante.

                                    Et elle sort d'ou cette règle arbitraire ? En quoi faudrait-il attendre 3 mois pour sortir un truc plutôt que le sortir quand il est prêt ?

                                    • [^] # Re: Tu peu même élargir ...

                                      Posté par . Évalué à 3.

                                      Non il ne faut pas "attendre 3 mois pour sortir un truc plutôt que le sortir quand il est prêt".

                                      Ce que je dis, c'est que si tu ne peux pas envisager de pousser le driver dans le noyau 3 mois avant la sortie de ton bidule, c'est que c'est que ce driver est loin d'être terminé. S'il est loin d'être terminé, alors tu ne peux pas le tester (oh, j'imagine que tu peux rouler quelques tests unitaires ici et là, mais aucun test d'intégration ou quoi que ce soit de plus poussé), donc tu te laisses moins de 3 mois pour tester, déboguer et publier ton driver. Si c'est le cas, alors oui je pense qu'il y a un problème—encore une fois si c'est un truc tout con du genre un driver qui lit un device série virtuel dans un certain format, alors en effet tu n'as pas besoin de 3 mois pour tester ça, mais justement tu n'as pas non plus à passer par le noyau…

                                      Après, je me fiche effectivement que ce soit 3 mois ou 2½ ou 4, j'ai pris 3 mois en particulier parce que c'était ce que tu mentionnais dans ta précédente réponse.

                • [^] # Re: Tu peu même élargir ...

                  Posté par (page perso) . Évalué à 2.

                  Tu regardes Ubuntu 14.x, toutes les 2-3 semaines l'ABI est cassé dans une update.

                  dkms is the way to go… Après, effectivement, ce n'est pas le même outils sous Fedora… Mais bon, ça va bientôt être inclus dans systemd :) (ce qui serait logique vu que c'est une tache de boot)

                  • [^] # Re: Tu peu même élargir ...

                    Posté par . Évalué à 2.

                    (ce qui serait logique vu que c'est une tache de boot)

                    Pas que (au moins sous debian). Fort heureusement les modules sont reconstruits à l'installation d'un nouveau noyau et pas uniquement au boot d'après. Sinon ça poserait de vrais problèmes quand la compile explose parce que les headers kernel ont changé (Virtualbox guest additions et open-vm-tools, c'est vous que je regarde).

                  • [^] # Re: Tu peu même élargir ...

                    Posté par . Évalué à 0.

                    a) C'est pas le meme outil selon les distribs
                    b) Ca force les utilisateurs a avoir un compilateur et les headers du noyau sur chaque machine, sur les machines sensibles qui sont sensées avoir le strict minimum, ca fait moche.

                    DKMS aide, mais ne résoud pas tout malheureusement.

            • [^] # Re: Tu peu même élargir ...

              Posté par (page perso) . Évalué à 10.

              Sous Windows ? Ils peuvent dans la plupart des cas faire un driver qui tournera sur toutes les versions depuis Vista. Ca couvre 90% du marché desktop.

              Ca, c'est la réalite.

              Plus c'est gros plus ça passe ! J'ai plein de matériel photo/vidéo qui ne dispose plus de driver Windows depuis des lustres et qui fonctionne encore à merveille sous notre OS chéri. Et pour très très longtemps encore !

              La réalité (pas celle que ton boss t'as fait avaler au biberon et qui t'empêche de réfléchir avec tes propres neurones) c'est qu'en achetant du matériel sans un driver libre inclus en mainline on a toutes les chances de devoir le refourger quelques années plus tard quand tes boss auront décidé d'arrêter le support de la version en cours: obsolescence parfaitement programmée …

            • [^] # Re: Tu peu même élargir ...

              Posté par . Évalué à 8. Dernière modification le 11/08/15 à 13:12.

              Sous Windows ? Ils peuvent dans la plupart des cas faire un driver qui tournera sur toutes les versions depuis Vista. Ca couvre 90% du marché desktop.

              Ha ! 99 % du temps pour du matos pas-si-vieux j'ai un matériel dont le pilote n'est pas disponible sous Windows (genre, le driver n'existe qu'en version pour Windows 32 bits uniquement, ce qui te bloque à Windows 7 32 bits pour pouvoir l'utiliser), mais qui fonctionne très bien sous Linux sans rien faire.

              À bon entendeur, salut !

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: Tu peu même élargir ...

                Posté par . Évalué à 2.

                Ha ! 99 % du temps pour du matos pas-si-vieux j'ai un matériel dont le pilote n'est pas disponible sous Windows (genre, le driver n'existe qu'en version pour Windows 32 bits uniquement, ce qui te bloque à Windows 7 32 bits pour pouvoir l'utiliser), mais qui fonctionne très bien sous Linux sans rien faire.

                Tiens, c'est exactement mon cas, j'ai remonté un client Windows l'année dernière avec un vieux serveur dont je ne me servais plus depuis des années, qui comprenait une carte SCSI avec des disques SCSI. Ca a été une galère sans nom pour trouver un pilote qui fonctionne, et au final j'ai dû installer Windows 7 32 bits sur le disque IDE, puis basculer le système sur le disque SCSI.
                J'ai eu d'autres misères mais rien que celle-là m'a coûté des jours de travail ingrat.
                Ca m'a fait un choc de découvrir à quel point Windows était archaïque, plus encore que ce que j'imaginais : la version 32 bits ne supporte même pas 4 Go de RAM et trouve le moyen de ramer.
                Le pilote graphique NVidia à jour plante régulièrement en regardant des vidéos Youtube ou autre !

            • [^] # Re: Tu peu même élargir ...

              Posté par . Évalué à 5.

              Ou comment parler de théorie sans jamais avoir fait l'expérience de la réalité…

              En fait ton post est un bon exemple de cette phrase, et tu parles manifestement d'un sujet que tu ne maîtrises pas du tout.

              Allez, petit exemple pratique…
              La société X sort le 8 aout 2015 un nouveau matériel, ou un soft, qui a besoin d'un module kernel (bref, un driver).
              Elle fait comment pour que son matériel/soft tourne sur les Linux existants chez les utilisateurs qui sont du Ubuntu 12.04, 14.04, Redhat 6, OpenSuse 11, Debian x/y, etc… ? Ah oui tiens, c'est 3252 versions différentes de kernel, avec l'ABI qui casse quasiment à chaque update, qui sortent à des périodes différentes, à des fréquences différentes, avec des règles différentes pour l'inclusion de modules dans les dépots, etc…

              Elle ne développe pas son module le jour de la sortie, et il lui suffit de fournir le module en question via le moyen qu'elle veut : Web, paquet de la distribution, … C'est justement ce que font tous les constructeurs qui supportent Linux. Et l'ABI du noyau Linux ne casse pas à chaque update. Il faut éviter d'asséner des choses lorsque l'on ne maîtrise pas du tout le sujet.
              Ton exemple n'a rien de sorcier et est déjà géré.
              Le seul moment où cela pose problème, c'est lorsque le constructeur n'a développé aucun pilote libre.

              Tout ca pour supporter 1% du marché desktop.

              La donne change quand ces 1% de desktop correspondent à 90+ % de desktop utilisés dans un domaine à forte valeur ajoutée auquel ce constructeur vend 99% de son matériel.

              Sous Windows ? Ils peuvent dans la plupart des cas faire un driver qui tournera sur toutes les versions depuis Vista. Ca couvre 90% du marché desktop.

              90 % du desktop, dont au mieux le marché du constructeur n'est qu'un sous-ensemble, au final pas forcément plus grand que le 1 % de desktop ci-dessus.

              Ca, c'est la réalite.

              Non, c'est un exemple qui contredit la réalité, associé à des chiffres sans aucun rapport, plus élevés du côté qui te plaît pour appuyer ton argument par un sophisme de juxtaposition.
              Bref, ce que tu dis ne sert à rien, en plus d'être basé sur de l'ignorance.

              L'inclure dans le kernel mainline ne résoud absolument rien du tout.

              Et finir par une contre-vérité, ça résume bien le ridicule du post.

        • [^] # Re: Tu peu même élargir ...

          Posté par . Évalué à 0.

          Windows dans une machine virtuelle ça le fait tout autant, et c'est moins contraignant qu'un dual boot.

      • [^] # Re: Tu peu même élargir ...

        Posté par . Évalué à 6.

        Il existe deux grandes raisons objectives pour utiliser un logiciel proprio dans une distro libre: 1) il n'existe pas d'équivalent libre de qualité comparable (typiquement : drivers), ou 2) les équivalents libres ne sont pas compatibles avec le propriétaire, qui bénéficie d'un effet "réseau" (typiquement: Skype). Dans les deux cas, l'utilisation d'une brique proprio est le seul compromis raisonnable pour pouivoir encore utiliser un système à 99% libre.

        • [^] # Re: Tu peu même élargir ...

          Posté par . Évalué à 0.

          Il existe deux grandes raisons objectives pour utiliser un logiciel proprio dans une distro libre: 1) il n'existe pas d'équivalent libre de qualité comparable (typiquement : drivers), ou 2) les équivalents libres ne sont pas compatibles avec le propriétaire, qui bénéficie d'un effet "réseau" (typiquement: Skype). Dans les deux cas, l'utilisation d'une brique proprio est le seul compromis raisonnable pour pouivoir encore utiliser un système à 99% libre.

          Qu'est-ce qu'il ne faut pas lire, c'est le comportement gravissime dont parlait un posteur ci-dessus.
          Le compromis dont tu parles n'a absolument rien de raisonnable, c'est juste le plus facile, certainement pas le plus raisonnable. Je ne vois pas ce qu'il y a de raisonnable à abandonner sa liberté à la moindre contrainte, surtout quand on sait que la liberté est qqch qui n'est pas facile à obtenir ou à maintenir, c'est un combat de chaque instant.
          Et là, je lis qu'abandonner au premier coup reçu est raisonnable, c'est vraiment ridicule.

          Le Logiciel Libre a été la réponse raisonnable à précisément ce genre de problématique, mais c'est long et difficile. Le chemin parcouru en 25 ans et plus me paraît juste incroyable.

          Je n'ai rien contre lâchement accepter le compromis, je le fais aussi, en revanche je ne cautionne pas ceux qui, sachant qu'ils ont lâchement abandonné, se donnent bonne conscience en se disant que c'était ce qu'il y avait de mieux à faire, c'était le plus raisonnable, alors qu'ils sont sur un système qui prouve le contraire. Mais bon c'est humain…

          • [^] # Re: Tu peu même élargir ...

            Posté par (page perso) . Évalué à 2.

            C'est quoi ton téléphone? Attention, tu n'as que deux choix.

            Ensuite, tu faisais comment avant, tu n'avais pas de téléphone?

          • [^] # Re: Tu peu même élargir ...

            Posté par . Évalué à -1.

            c'est juste le plus facile, certainement pas le plus raisonnable

            Mise en pratique : on installe Linux sur l'ordinateur d'un ami. Il a deux écrans. Le driver disponible dans le kernel ne supporte qu'un écran.

            1) "Dis donc Gégé, qu'est-ce que tu as besoin de deux écrans? Allez hop, je n'en embarque un."
            2) "Ça y est, je n'ai installé Linux! Voici mon (faux) numéro de téléphone en cas de pépin! Adieu."
            3) "Ah bah je n'arrive pas à configurer la carte graphique. Je n'ai tout supprimé, comme ça tu restes sous Windows".
            4) "Je sais bien que tu as besoin de ton ordinateur, mais je l'embarque chez moi, il me le faut pour reverse-ingénierer le driver de la carte graphique. Je te code un truc libre dans les 12 mois et je te le rends, OK? Tu m'enverras tous les jours les fichiers de log, et d'ici ou 4 ans tu devrais n'avoir qu'un ou deux kernel panic par jour".

            Nan nan, y'a pas à dire, tout ceci est très raisonnable.

            Personnellement, j'aurais tendance à considérer que les solutions comme
            * changer de matériel
            * coder un patch soi-même
            * accepter une régression
            * passer plusieurs heures à copier-coller des commandes qui commencent par "sudo" à partir de sites internet en russe
            ne font pas partie de ce qu'on peut appeler des solutions "raisonnables" (en tout cas, pour des gens qui ont d'autres centres d'intérêt dans la vie).

Suivre le flux des commentaires

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