Le dimanche 16 décembre 2012 à 20:07 +0100, Christophe HENRY a écrit : > Salut Michel, > > Merci de répondre de façon complète à ma demande :-) > > > Le Sat, 15 Dec 2012 14:53:19 +0100 > Michael Scherer <[email protected]> a écrit : > > > Coller à tes besoins, sans doute d'un point de vue de l'utilisation > > pur, vu qu'il s'agit juste d'une Ubuntu en retirant les trucs qui > > font râler certains. Mais la question est aussi de savoir : "est ce > > que c'est pérenne ?". > > Bon, il faut que j'avoue le fond du fond. J'utilise Debian depuis le > tout premier jour, et je n'ai jamais trouvé meilleur. C'est pour ma > moitié que je cherche un autre système.
> > > (...) > > Déjà, ils savent pas programmer proprement en python > > ( https://bugs.launchpad.net/linuxmint/+bug/1008501 ) > > (...) > > J'ai regardé, mais je suppose que le lien que tu as fourni pointe vers > la dernière version. Du coup, le code n'a plus rien à voir. Où alors > il faut moi aussi que je révise mon python. En effet, le code est la https://github.com/linuxmint/mintnanny/blob/master/usr/lib/linuxmint/mintNanny/mintNanny.py#L78 Si jamais un fichier /tmp/hosts.mintNanny existe déjà ( car il y a aucune vérif ), et au hasard, avec chattr +i ( donc non modifiable par root ), alors il va se retrouver à la place de /etc/hosts, vu qu'à aucun moment une vérification du code retour n'est fait ( ie, si le sed échoue, c'est pas grave ). Ce qui en pratique permettrais de détourner le trafic web, par exemple. ( www.mabanque.com va vers 1.2.3.4 qui est sous mon contrôle ). En pratique, vu le peu de monde sous mint, personne ne va jamais faire ce genre d'attaque mais bon, ça reste quand même à corriger. Plus vicieux, si jamais /tmp/hosts.mintNanny est un lien soft/hard vers un fichier, genre vers /home/misc/rapport_ultra_important_que_je_sauvegarde_pas.txt alors lancer l'outil mintnanny peut écraser le rapport ( vu qu'il est lancé en root ). Je dit "peut" car il y a un module kernel pour empêcher ça : https://wiki.ubuntu.com/Security/Features#hardlink , mais pas dans la version debian de linux mint, parce que le patch a mis du temps avant d'arriver upstream dans le noyau ( genre 3/4 ans, suffit de chercher "lwn yama" sur un moteur de recherche pour avoir les différents soucis ) ) Pareil, dans le même genre d'attaque à la con : https://github.com/linuxmint/mintupdate/blob/master/usr/lib/linuxmint/mintUpdate/mintUpdate.py#L1456 Si quelqu'un fait un lien vers un autre repertoire dans /tmp ( vu que tout le monde peut écrire ), bah tu file le droit d'écrire à tout le monde sur le repertoire pointé ( si le module yama n'est pas chargé ). Donc bon, c'est pas des failles graves, il faut avoir un accès à la machine mais c'est tout de même pas terrible. > > Donc je ne sais pas si il y a un vrai support sécurité sur le > > système. Les updates d'ubuntu sont remis dans Mint, du moins, je le > > suppose, mais quid des améliorations en dehors d'ubuntu ( exemple, > > mate, cinnamon, etc ) ? Et est ce que les paquets modifiés par mint > > sont maintenus ? Et comment ? > > Vu que je voulais quitter Ubuntu, il était de toutes façons entendu > que j'opterai pour la version Debian. Mais qu'ils maintiennent les > deux saveurs en même temps me fait douter. Laquelle est prioritaire ? J'ai pas le sentiment que la version Debian soit très suivi ( ie, il y a moins de releases et de buzz ). Ensuite, peut être qu'il y a pas besoin. C'est marqué comme étant basé sur testing, donc je suis dubitatif sur le fonctionnement sur le long terme. > > Ensuite, Linux mint a des positions simplistes sur les soucis de > > licenses. Si on regarde la FAQ ( http://www.linuxmint.com/faq.php ), > > on voit qu'ils sont contre les drivers proprios, mais s'en foutent > > pour le reste. On voit qu'ils confondent "brevet logiciel" et > > "support multimedia". > > Et dans la FAQ on voit : > """ > Why does Linux Mint include proprietary drivers? / Pourquoi Linux > Mint inclus des pilotes propriétaires ? > > It doesn't. If it did, it would be legally wrong (because it would > violate the GPL) (...) Ce n'est pas le cas. Sinon, ce serait > légalement mauvais (parce que ça enfreindrait la GPL). > """ > Ubuntu le fait pourtant. L'intégration du pilote de la carte graphique > Nvidia est très bon, grâce à DKMS. Rien à voir avec la GPL. Je suppose que Canonical a plus d'argent pour des avocats que Mint, et contrairement à Mint, a des accords commerciaux avec AMD/Nvidia ( je me souviens que Canonical avait accès à des préversions de pilote fireglx il y a quelques années ) > > > Et si on regarde le contenu des isos, on voit qu'ils distribuent > > faad2 et des morceaux de vlc sur le dvd "nocodecs", malgré le fait > > que la lib faad2 étant visiblement couvert par des brevets : > > http://en.wikipedia.org/wiki/Advanced_Audio_Coding#Licensing_and_patents > > ). Et le choix est entre "avoir une version oem" ou "une version > > qu'on prétends propre", donc un OEM qui voudrait faire du propre n'a > > pas de version. > > Je suis bien d'accord. Je suppose qu'il y a une raison de segmentation > clientelle et aussi pour la place sur les DVD, mais quand même... Ça > fait beaucoup d'éparpillement. C'est surtout idiot, y a pas besoin de faire 2 isos, c'est orthogonal au contenu : https://help.ubuntu.com/community/Ubuntu_OEM_Installer_Overview Donc soit ils ont une solution technique totalement différente. Soit l'iso est juste une iso avec une option de boot par défaut et 2/3 trucs en plus. > > Enfin, ce qui me gène, c'est le manque manifeste de collaboration > > qu'on retrouve souvent dans le projet. Plutôt que de rendre Ubuntu > > meilleure, un fork est mis en place. > > (...) > > Mint ( comme beaucoup de monde) a tout intérêt à ce que Canonical > > survive vu que la boite fait le gros du travail sur Ubuntu, mais en > > même temps, comme beaucoup de mon, ils font beaucoup pour les priver > > de revenus : > > (...) > > En effet, la collaboration avec la distro "upstream" me semble > houleuse. Et puis, c'est toujours Ubuntu. En poussant loin mon délire, > rien ne dit qu'il sera toujours possible de récupérer facilement leurs > développements. À Ubuntu/Canonical ? Je pense que si. On peut les accuser de faire des trucs pas super portables, mais je sais que c'est plus un manque de temps et de moyen humain ( les salariés ont pas mal la pression et ont du boulot en général plus urgent, de ce que j'ai discuté avec certains ) qu'une envie de pas distribuer. Ils essayent globalement de bien faire, mais s'y prenne pas forcément très bien. Historiquement, ce que Canonical ne distribue pas, c'est la partie serveur ou les choses qu'ils tentent de vendre aux OEMs ( android, etc ). Mais les serveurs divers et variés, ça reste bien souvent difficilement exploitable par des externes quand c'est prévu à la base comme un service plus que comme un soft à part. Par exemple, gitorious, => super compliqué à installer, transifex => le code sur mercurial diffère du code en prod et marche pas tout seul, etc. > > Donc pour terminer, perso, ça me parait pas terriblement pérenne et > > je recommanderais pas son usage, mais ça va sans doute coller à tes > > besoins ( comme la plupart des distros en fait, mais la grande > > réussite d'Ubuntu, c'est d'avoir fait rentrer dans l'esprit des gens > > que c'est "linux pour les êtres humains" sous entendu, les autres > > sont pour votre chien, ou des non humains ). > > Merci beaucoup pour ton analyse argumentée et profonde. Et du coup, je > reste quand même bloqué puisque Linux Mint reste foncièrement > dépendant de Ubuntu ; et pas d'une bonne manière, vu ce que tu m'as > appris. Mais pourquoi tu ne prends pas une Debian ? C'est pérenne, tu connais, ça va pas bouger ( ce qui à mon sens est super important pour les pcs des autres ), et je doute que ça coince à ce point dans les coins. -- Michael Scherer _______________________________________________ libre mailing list [email protected] http://brassens.heberge.info/cgi-bin/mailman/listinfo/libre
