Le mieux ça reste de mettre un OS comme CyanogenMod. C'est ce que j'ai fait avec mon HTC Sensation et :
1) j'ai la dernière version d'Android à jour alors que la dernière version officielle date d'il y a genre 2 ans ;
2) j'ai énormément gagné en autonomie : ma batterie tient 24h quand elle tenait moins de 10h avec l'OS d'origine ;
3) c'est infiniment plus réactif : avant il fallait parfois plus d'une minute entre le moment où j'appuyais sur un contact et le moment où il appelait ce contact… Parfois je ne voyais même pas qui m'appelait car le temps que l'OS affiche le nom du contact, la personne était tombée sur le répondeur ! En ayant installé CyanogenMod, je bénéficie des optimisations faites pour CyanogenMod, je n'ai plus toute la surcouche HTC qui me ralentissait terriblement le téléphone et qui me pompait toute la batterie, et je n'ai plus la surcouche de mon opérateur téléphonique.
J'ai un peu galéré pour le mettre, c'est vrai, mais maintenant que c'est fait qu'est-ce que je suis content !! Ca valait vraiment la peine, je vous assure. Un ami a fait de même avec un Samsung Galaxy S4 et il est ravi.
Est-ce que tu as été confronté à des cas où en ayant un noyau + la pile graphique à jours (Mesa et compagnie), tu n'arrivais pas à lancer ces jeux en question ?
Car j'ai ce problème mais avec Debian Stable + backport pour le noyau, donc même si mon noyau est à peu près récent (v3.14), ma pile graphique remonte à il y a 2 ans et je sais qu'un certains nombre de bugs et de fonctionnalités ont été retirés et ajoutées entre temps dans les nouvelles versions de Mesa et consorts. Je n'ai plus ces problèmes en utilisant Debian Testing (= Jessie actuellement).
Ce qui me fait vraiment halluciner et marrer en même temps, c'est de me dire que des milliards de machines et de personnes (oui des milliards puisque les smartphones Android s'écoulent à hauteur de presque 1 milliard par an) doivent attendre que Monsieur Torvald ait terminé sa salle de bain pour avoir droit à la mise à jour de leurs systèmes.
"- Chef ! Le noyau est en retard d'un jour et notre milliard de clients s'impatiente, chef !
- Ah, encore un coup des chinois du FBI, saperlipopette !
- Chef ! On me dit que c'est parce que M. Torvald termine sa salle de bain, chef !
- Tu t'fous d'moi, mon p'tit Baleine ?"
Je ne suis pas sûr cependant qu'on compare des cartes tout à fait égales car l'auteur dit qu'il regrette de ne pas avoir de carte AMD R9 290X sous la main.
Ceci étant dit, tout dépend des besoins. Si on a absolument besoin de performances, alors effectivement Nvidia est sûrement mieux. Mais en l'occurrence Nvidia pèche très largement sur les pilotes libres. Donc ça dépend des priorités de chacun. A titre personnel, je préfère largement privilégier AMD car je n'ai pas besoin de performances fulgurantes, une Radeon 4870 X2 me suffit amplement.
Les pilotes graphiques propriétaires sont nécessaires car certains clients d'AMD ont besoin d'OpenGL 4.x, dont l'implémentation n'est pas libre. Dans cette vidéo, Alex Deucher dit que même si AMD mettait une armée de développeurs pour implémenter OpenGL 4.x sous forme libre (c'est le projet Mesa) le plus rapidement possible, ils seraient en retard et ne pourraient pas satisfaire leurs clients qui en ont besoin immédiatement. Donc AMD continue d'utiliser les Catalyst pour satisfaire certains clients, mais fondamentalement ils n'auraient rien contre le fait de s'en passer apparemment.
Il est donc probable qu'on aura donc toujours des pilotes propriétaires en parallèle des pilotes libres, mais on peut espérer arriver dans quelques années à une situation où les pilotes libres seront tout aussi performants que les propriétaires à fonctionnalités égales.
En effet, les pilotes libres pour les cartes Nvidia sont développés par rétro-ingénierie par la communauté du libre, contrairement à AMD qui a décidé d'embaucher des personnes à temps plein pour coder des pilotes graphiques open source.
Pour la petite histoire, AMD a recruté les développeurs (notamment Alex Deucher) qui bossaient depuis des années sur les pilotes libres des cartes AMD/ATI et qui prenaient sur leur temps libre pour cela. C'est donc admirable de la part d'AMD d'avoir recruté ces personnes et d'avoir initié un vrai changement dans leur politique de pilotes graphiques. Je me souviens qu'ils auraient aimé pouvoir le faire plus tôt, mais les clauses contractuelles de non divulgation des contrats industriels liaient fortement le matériel et le logiciel, donc AMD a dû attendre quelques années avant d'avoir le droit d'embaucher des salariés qui pouvaient accéder aux fiches techniques des puces pour coder et diffuser des pilotes graphiques libres.
En toute logique viendra un jour où les pilotes propriétaires d'AMD (les "Catalyst") seront entièrement remplacés par les pilotes libres (les "radeon"), puisque les "radeon" feront doublon avec les "Catalyst" et seront normalement (un jour…) aussi performants (sinon plus). Ca c'est moi qui le dit, mais le projet Gallium3D devrait permettre de mieux porter les pilotes entre différents OS, donc ça devrait aider.
Pour l'instant, AMD s'applique à implémenter toutes les fonctionnalités nécessaires dans les pilotes graphiques, pour l'ensemble de ses cartes graphiques depuis l'an 2000 (!!), qu'on peut suivre ici :
Lorsque toutes ces fonctionnalités seront implémentées, il est probable qu'ils s'emploieront à optimiser davantage les pilotes.
Je me souviens lorsqu'Alex Deucher a été recruté en décembre 2007, ce tableau était complètement rouge. 7 ans après quasiment toutes les fonctionnalités ont été intégrées dans les pilotes libres. On peut aisément penser qu'il faudra 3 ans de plus pour terminer le boulot, donc il aura fallut 10 ans pour implémenter les pilotes graphiques libres pour toutes les cartes d'AMD, par une équipe de 5 développeurs officiels (+ les contributeurs de la communauté et d'autres entreprises, disons une dizaine à temps plein), sachant qu'AMD ne met pas beaucoup de moyens sur ces pilotes libres car ça ne représente pas beaucoup de parts de marché. C'est vraiment pas mal quand on sait à quel point les GPU sont des machines complexes.
Je vous invite à lire cette interview très enrichissante :
Pour en revenir à Nvidia, la communauté fait un boulot remarquable. Il est déjà extrêmement compliqué de coder des pilotes graphiques quand on a accès aux schémas des cartes, alors lorsqu'on procède par rétro-ingénierie ça relève de l'exploit. Donc oui ce n'est de loin pas parfait, mais c'est le mieux que la communauté puisse faire pour l'instant.
Ce qui est déplorable, c'est l'attitude de Nvidia qui n'a aucune intention d'ouvrir ses pilotes et de travailler sur des pilotes libres. Ce fameux témoignage où Linus Torvald dit qu'Nvidia est la pire des sociétés avec laquelle il a pu collaborer jusqu'à présent résume bien la chose :
Donc si tu souhaites des pilotes graphiques libres avec des performances correctes, tu ne vas pas pouvoir compter sur Nvidia, tu n'as pas d'autre choix que de te tourner vers AMD. Ou Intel ! Intel est une entreprise exemplaire quant au support des pilotes libres de son matériel. Les pilotes sont dans le noyau plusieurs mois avant que le matériel ne soit sur le marché, ce qui fait qu'on a des pilotes Intel supers stables quand on achète du nouveau matos (carte-mère, CPU, GPU, Wi-Fi, etc. ; le pied quoi !).
Voilà voilà, j'ai limite écrit un article entier à moi tout seul, j'espère que ce sera utile à certains ^
GNU dmd reste une solution plus élégante que systemd qui lui se contrefout d'être compatible POSIX. C'est une évolution intelligente du système d'init POSIX, pas une rupture totale. Autrement dit, c'est ce que systemd aurait pu (dû ?) être.
Pour ceux que ça intéresse, voici GNU dmd, un système de démarrage universel et de gestion de services conçu pour les systèmes POSIX, qui reprend le meilleur de SysV-init et de systemd :
Maintenant qu'une solution sérieuse est en cours d'élaboration pour remplacer le (très) vieillissant SysV-init et le (très) monolithique systemd, qu'on ne vienne plus me parler des avantages/inconvénients de l'un ou de l'autre. C'est une solution propre, simple, respectueuse des principes de base des *NIX et performante.
A ce moment là pourquoi est-ce qu'on n'intègre pas l'UEFI + le bootloader + l'init + le login ? Histoire d'avoir des machines aussi fermées que les smartphones ? (sinon plus) Parce que bon, il suffit d'ajouter l'UEFI dans 'systemd' est on y est hein…
Des PC où tout serait verrouillé de l'UEFI jusqu'au bureau ? Microsoft l'a rêvé, Red Hat l'a (bientôt) fait.
Je ne suis pas fondamentalement contre le fait d'avoir un logiciel qui nous permette d'intégrer absolument toute la chaîne de démarrage de A à Z dans un logiciel monolithique (on a beau séparer les binaires, ils sont quand même tous dépendants les uns des autres). Ca peut avoir une vraie utilité pour tout un tas de personnes ou d'entreprises.
Mais mettre ce système par défaut dans quasiment toutes les distributions et donc aller à l'encontre des principes de base qui ont fait le succès des *NIX, je trouve ça aberrant. Je suis convaincu que toutes les distributions qui adoptent 'systemd' sont en train de se tirer une balle dans le pied à long terme.
Dire que systemd est pourri, c’est remettre en question les compétences de tous ceux qui ont choisi systemd, à savoir à peu près toutes les distributions sauf Slackware et Gentoo par défaut.
1) Malgré ça, on assiste à des développeurs Debian officiels qui créent un fork ;
2) "Ce n'est pas parce qu'ils sont une majorité à avoir tort qu'ils ont raison", pour reprendre Coluche. Entendre par là : je tiens à me faire ma propre opinion, même si le meilleur programmeur du monde me dit que j'ai tort, car c'est comme ça que je comprendrai pourquoi j'ai tort (ou lui éventuellement, ça arrive…).
Tout comme systemd n'a pas grand chose à voir avec une des règles de base d'UNIX malheureusement, à savoir la séparation de tâches simples en briques logicielles indépendantes.
La stagnation, c'est l'avenir !
J'ai dit "Il y a des fois où il faut savoir faire marche arrière et se dire que les vieilles recettes sont parfois les meilleures". Pas "Maintenons le statu quo". Parfois, oui, il vaut mieux refuser certaines évolutions qui en réalité amènent autant de problèmes qu'elles n'en résolvent. Ce qui ne veut pas dire qu'il ne faille rien faire pour améliorer par exemple OpenRC.
Change vite d'OS, ça fait plus de vingt ans que Linux (le *NIX majoritaire depuis 15 ans au moins) utilise un gros noyau monolithique.
C'était même tellement bien qu'on a été obligé de créer une v2 de Linux pour y ajouter des modules.
Pas vraiment. D'abord, pour avoir systemd il faut linux. Aussi, systemd aurait été plus difficile avec 16 Kio de mémoire (la taille de la mémoire vive du premier IBM PC), AMHA.
C'est bien tout le coeur du problème : pour avoir systemd, il ne faut que Linux.
Lesquelles ?
Ca fait 3 fois que je l'écris dans ce fil mais je vais le redire : séparer des tâches en briques logicielles indépendantes. C'est un des concepts de base de la programmation système sous les *NIX, j'en veux pour référence cet excellent ouvrage : http://www.oreilly.com/openbook/linuxdrive3/book/
Les vielles recettes puent. Quand on copie/colle du code shell mal fichue pendant 40 ans plutôt que d'arrêter de re-faire le même boulot des milliers de fois :
1) soit on a la foi
2) soit on est stupide
Je te rejoins totalement sur ce point. Mais si c'est remplacer un truc qui pue par un truc moisi, non merci, je préfère encore conserver l'ancien truc en bossant sur un système correct qui viendra le remplacer plus tard (je pense à OpenRC).
Et c'est parce qu'on sait quand savoir évoluer, qu'on a eu bien d'autres systemd-like avant systemd (qui ne fait que réunir le meilleur des systemd-like qui sont apparus avant lui).
Par évolution, j'entendrais quelque chose comme "contribuer à l'existant pour le rendre vraiment meilleur", plutôt que de prendre plein de fonctionnalités et de les agréger en un ensemble de briques pas indépendantes qu'on aura entièrement recodées. Plutôt que de faire un peu de vérification de système de fichiers + un peu de parefeu + un peu de ceci et un peu de cela, systemd ferait bien de ne faire que l'initialisation. Ou s'il veut tout faire, qu'il ait au moins la gentillesse de séparer les briques logicielles de façon indépendantes, qu'on puisse remplacer chaque élément par un autre si l'on préfère. Mais ce n'est pas du tout la logique adoptée ici, et c'est je crois ce qui pose problème à tant de personnes.
Pour le point 2, OpenRC peut être plus rapide au démarrage que systemd.
Pour le point 3, je suis totalement d'accord et je n'ai jamais compris pourquoi on avait conçu des trucs aussi compliqué pour lancer des choses simples.
Je parle de faire tourner les choses proprement pour qu'on puisse continuer à avoir un système fiable et performant. Linus Torvald est du genre à passer une nuit sur une fonction appelée 1 fois par jour pour gagner 5 cycles microprocesseur, son argument étant de dire que 5 cycles CPU x des millions de machines, ça fait beaucoup d'énergie économisée. C'est cette approche que j'aimerais voir dans les distributions.
Lennart Pottering est bien loin de cet état d'esprit selon moi, sinon il aurait contribué à des systèmes de démarrage existants en vue de les améliorer (je pense à OpenRC qui n'est pas parfait mais qui se rapproche de ce que 'systemd' sait faire, et pour le coup de manière propre, intelligente et compatible UNIX).
Tout comme ça serait sûrement très pratique que 'systemd' fasse le café.
Est-ce intelligent pour autant ? Non.
Ce n'est pas parce qu'on peut le faire qu'on doit le faire.
Visiblement certains semblent oublier pourquoi les *NIX ont réussi à devenir des OS de référence et à tenir la distance depuis tant d'années. Une de ces raisons, c'est qu'on a segmenté les tâches simples sous formes de briques assemblables et indépendantes, plutôt que de tout mettre dans un gros ensemble qui ferait tout et sur lequel tout reposerait.
Ca fait 40 ans qu'on aurait pu écrire un 'systemd'. Si ça n'a pas été fait c'était pour de bonnes raisons. Il y a des fois où il faut savoir faire marche arrière et se dire que les vieilles recettes sont parfois les meilleures.
Est-il possible d'exporter une animation au format SVG + CSS pour l'intégrer dans une page HTML 5 / CSS 3 ? Si c'est le cas je me jette sur ce logiciel !
Je compare quotidiennement la différence entre mon ordi au boulot sous Windows 7 (Windows XP ne s'en sortait pas mieux) et mon ordi perso sous Debian.
Et en l'occurrence je tendrais aussi à surnommer Windows "Windaube" parce que je n'ai pas eu un problème avec, mais j'ai un problème par jour avec, quand j'en ai un par an avec Debian…
J'étais sous Windows 3.1, Windows 3.11, Windows 95, Windows 98, Windows XP, Windows Vista et Windows 7. Puis j'ai testé Linux (Debian en l'occurrence) et là j'ai pleuré en repensant aux centaines d'heures passées à configurer, paramétrer, installer, réinstaller, formatter, reformatter, nettoyer les virus, renettoyer les virus, etc. etc. etc., pour finalement recommencer.
"Windaube" je trouve ça un peu enfantin comme nom c'est vrai, mais à l'usage c'est exactement ça. Je n'arrive toujours pas à lui trouver un avantage sur Linux, si ce n'est peut être qu'il est installé sur 90 % des PC et donc que c'est très pratique quand on veut péter la sécurité d'un système.
Simple exemple : désigner des lecteurs par des lettres comme "C:" au lieu de fichiers, ça rend tout le système complexe à maintenir et incompatible avec plein de trucs, ne serait-ce que pour les liens entre mes fichiers Excel au boulot. Quand un collègue bosse avec un fichier stocké sur R: et que moi il est déclaré en P: et bien c'est le bordel, il faut se taper l'actualisation des liens un par un à chaque fois (bien sûr on ne peut rien changer). C'est quand même très con et ça fait perdre des dizaines de minutes pour rien chaque semaine. Même logique avec les lettres des lecteurs réseaux qui sont remplacées automatiquement sans prévenir par quelque chose comme "//mon/emplacement/réseau". Bref, Windows me gave et ce n'est pas du fanatisme, pour moi c'est une réalité quotidienne que je dois subir.
Là je donne un exemple de quelque chose de relativement bénin, mais j'ai été confronté à des cas d'emmerdement où j'avais juste envie de brûler mon PC sur place. En toute honnêteté, je n'arrive pas à voir en quoi Windows peut être mieux que Linux. Au mieux je peut concéder l'unicité de l'environnement de travail pour une version donnée qui permet à tous les utilisateurs de s'y retrouver lorsqu'ils passent d'un poste de travail à un autre, mais ça s'arrête là.
L'écriture de ceci m'a été inspirée par les annonces récentes réclamant publiquement un fork de Debian, une idée que je trouve idiote et qui ne débouchera probablement pas sur énormément de travail technique.
Par pitié, arrêtez avec ça. Ce fork n'est pas à cause de 'systemd'. Tout comme le départ de plusieurs développeurs Debian ces dernières semaines.
Cette volonté de forker vient du fait que les leaders de Debian ont voté contre l'obligation de maintenir les paquets comme 'gnome' ou 'kde' compatibles avec 'sysvinit'. Cela implique que 'gnome' ne pourra plus être utilisé sans 'systemd', ce qui impose donc de fait un système de démarrage, au détriment de tous ceux qui ont besoin pour une raison ou pour une autre d'utiliser 'sysvinit' (utiliser un noyau UNIX par exemple, et ça me semble être une très bonne raison).
Que 'systemd' soit dans les dépôts de Debian malgré sa philosophie anti UNIX et son code discutable, c'est une chose. Et à vrai dire c'est supportable du moment qu'on nous laisse la liberté de choisir un autre système de démarrage dans les dépôts.
Or c'est précisément cette liberté qui a été refusée aux administrateurs systèmes du monde entier, en dépit de leurs (nombreux) appels de détresse, mais surtout à l'encontre du pacte social qui a fait de Debian sa réputation.
Voilà pourquoi il a été décidé de forker Debian. C'est un problème de liberté et de confiance rompue. Pas de code.
Donc ça confirme d'autant plus l'inutilité de la Testing sur un poste de travail autrement que pour débugguer la future version de Debian =)
Si la Stable avec des backports est capable de faire la même chose que la Testing pour 95 % des logiciels qu'on utilise, pourquoi vouloir utiliser une branche instable et moins sécurisée ? Je ne vois pas de raison objective à cela (si ce n'est, je me répète, pour contribuer au débuggage de la future Debian).
De même, j'ai eu affaire à une machine extrêmement récente et la Stable ne fonctionnait pas (carte mère mal supportée, notamment la partie graphique). J'ai installé le dernier kernel disponible dans les backports et plus aucun problème.
Sur une machine classique, la Testing n'apporte rien de plus que les backports d'un point de vue système (puisque les backports sont généralement alignés sur la Testing !). Pareil pour tout ce qui est bureautique.
Sur une machine plus exotique (avec des périphériques de montage vidéos spéciaux par exemple), c'est autre chose. Tout ce qui touche au multimédia a tendance à nécessiter des logiciels récents, donc dans ce cas je comprends que la Testing puisse être nécessaire.
Une autre raison d'utiliser la Testing, c'est si on a absolument besoin d'un élément mis à jour comme 'wayland' ou 'systemd'. Là on touche au coeur du système et les backports ne peuvent pas faire le boulot. C'est selon moi le seul cas où on pourrait être amené à utiliser une Testing "en production".
Tu parles de personnes qui mettent les mains dans la cambouis pour debugguer Debian là. Donc on est bien d'accord : la Testing est faite pour ceux qui sont suffisamment à l'aise pour remonter les bugs et contribuer au développement de Debian.
Ma phrase est assez radicale et volontairement provoc, je l'admets.
A part un groupe d'ubergeeks prêts à casser du bug, je ne vois pas l'intérêt d'utiliser une Testing sur un poste de travail pour faire du montage vidéo, pour surfer, pour faire de la bureautique,…
J'ai bien compris ce que tu voulais dire, c'est peut être moi qui n'ai pas réussi à exprimer mon idée.
Même si c'est effectivement beaucoup d'efforts pour un nombre restreint d'utilisateurs, je pense que ce sont précisément ces utilisateurs qui changent le monde en faisant des trucs a priori inutiles, farfelus, mais qui façonnent peu à peu nos connaissances et nous donnent envie de créer chaque jour de nouvelles choses, utiles cette fois.
Quel intérêt de porter Linux sur une TI-89 ? On peut franchement se le demander. Sauf que j'ai eu énormément de plaisir à coder en assembleur sur ma TI-83 puis ma TI-89. Et ce que j'ai fait n'a servi à rien concrètement. Mais j'ai appris énormément de choses et la valeur que j'en tire aujourd'hui en valait sacrément la peine. Je pense aux boulots que ça m'a permis d'avoir, mais bien au-delà de ça de tout ce que ça m'a apporté comme connaissances et épanouissement personnel. Pour moi c'est ça le hacking.
Porter Debian sur autant d'architectures différentes nécessite une montagne de boulot incroyable, mais si on calcul le ratio Efforts requis / Nombre d'utilisateurs, alors autant laisser Microsoft faire son boulot et se contenter de ce qu'ils nous fournissent, plutôt que de chercher à économiser 5 cycles processeur sur une interruption appelée 3 fois par jour… Le libre c'est avant tout s'amuser à développer des systèmes pour la beauté de la chose. Si on peut rendre ça rentable, alors c'est carrément mieux, on est d'accord. Mais ce n'est pas ce qui a motivé le développement de Linux ou de Debian, et c'est pour ça que ce sont de si bons systèmes. Si ça amuse des mecs dans leur garage de maintenir des paquets qui ne servent à personne (même pas à eux), et bien le fait qu'ils prennent leur pied à le faire est déjà suffisant selon moi.
C'est sûr que j'aimerais qu'ils passent plus de temps à porter Compiz sous Debian Wheezy plutôt que de faire tourner des logiciels de radioamateur pour des PowerPC, mais les besoins et les motivations de chacun sont différents. Je suis sûr que les geeks barbus qui ne jurent que par la ligne de commandes se demandent bien pourquoi j'ai besoin de Compiz. Et pourtant…
[^] # Re: Linus multifonction
Posté par cluxter . En réponse à la dépêche Sortie du noyau Linux 3.19. Évalué à 4.
Le mieux ça reste de mettre un OS comme CyanogenMod. C'est ce que j'ai fait avec mon HTC Sensation et :
1) j'ai la dernière version d'Android à jour alors que la dernière version officielle date d'il y a genre 2 ans ;
2) j'ai énormément gagné en autonomie : ma batterie tient 24h quand elle tenait moins de 10h avec l'OS d'origine ;
3) c'est infiniment plus réactif : avant il fallait parfois plus d'une minute entre le moment où j'appuyais sur un contact et le moment où il appelait ce contact… Parfois je ne voyais même pas qui m'appelait car le temps que l'OS affiche le nom du contact, la personne était tombée sur le répondeur ! En ayant installé CyanogenMod, je bénéficie des optimisations faites pour CyanogenMod, je n'ai plus toute la surcouche HTC qui me ralentissait terriblement le téléphone et qui me pompait toute la batterie, et je n'ai plus la surcouche de mon opérateur téléphonique.
J'ai un peu galéré pour le mettre, c'est vrai, mais maintenant que c'est fait qu'est-ce que je suis content !! Ca valait vraiment la peine, je vous assure. Un ami a fait de même avec un Samsung Galaxy S4 et il est ravi.
[^] # Re: Tres bon
Posté par cluxter . En réponse à la dépêche Sortie du noyau Linux 3.19. Évalué à 4.
Est-ce que tu as été confronté à des cas où en ayant un noyau + la pile graphique à jours (Mesa et compagnie), tu n'arrivais pas à lancer ces jeux en question ?
Car j'ai ce problème mais avec Debian Stable + backport pour le noyau, donc même si mon noyau est à peu près récent (v3.14), ma pile graphique remonte à il y a 2 ans et je sais qu'un certains nombre de bugs et de fonctionnalités ont été retirés et ajoutées entre temps dans les nouvelles versions de Mesa et consorts. Je n'ai plus ces problèmes en utilisant Debian Testing (= Jessie actuellement).
[^] # Re: Linus multifonction
Posté par cluxter . En réponse à la dépêche Sortie du noyau Linux 3.19. Évalué à 6.
Ce qui me fait vraiment halluciner et marrer en même temps, c'est de me dire que des milliards de machines et de personnes (oui des milliards puisque les smartphones Android s'écoulent à hauteur de presque 1 milliard par an) doivent attendre que Monsieur Torvald ait terminé sa salle de bain pour avoir droit à la mise à jour de leurs systèmes.
"- Chef ! Le noyau est en retard d'un jour et notre milliard de clients s'impatiente, chef !
- Ah, encore un coup des chinois du FBI, saperlipopette !
- Chef ! On me dit que c'est parce que M. Torvald termine sa salle de bain, chef !
- Tu t'fous d'moi, mon p'tit Baleine ?"
[^] # Re: Tres bon
Posté par cluxter . En réponse à la dépêche Sortie du noyau Linux 3.19. Évalué à 2.
Ca aurait été encore mieux avec un lien pour justifier ta remarque :
http://www.phoronix.com/scan.php?page=article&item=linux_gpus_dec1412&num=1
Je ne suis pas sûr cependant qu'on compare des cartes tout à fait égales car l'auteur dit qu'il regrette de ne pas avoir de carte AMD R9 290X sous la main.
Ceci étant dit, tout dépend des besoins. Si on a absolument besoin de performances, alors effectivement Nvidia est sûrement mieux. Mais en l'occurrence Nvidia pèche très largement sur les pilotes libres. Donc ça dépend des priorités de chacun. A titre personnel, je préfère largement privilégier AMD car je n'ai pas besoin de performances fulgurantes, une Radeon 4870 X2 me suffit amplement.
[^] # Re: Tres bon
Posté par cluxter . En réponse à la dépêche Sortie du noyau Linux 3.19. Évalué à 7.
Je précise un point, donné par cette vidéo à 6m50s :
https://www.youtube.com/watch?v=hOmNWxx4Cwo#t=6m50s
Les pilotes graphiques propriétaires sont nécessaires car certains clients d'AMD ont besoin d'OpenGL 4.x, dont l'implémentation n'est pas libre. Dans cette vidéo, Alex Deucher dit que même si AMD mettait une armée de développeurs pour implémenter OpenGL 4.x sous forme libre (c'est le projet Mesa) le plus rapidement possible, ils seraient en retard et ne pourraient pas satisfaire leurs clients qui en ont besoin immédiatement. Donc AMD continue d'utiliser les Catalyst pour satisfaire certains clients, mais fondamentalement ils n'auraient rien contre le fait de s'en passer apparemment.
Il est donc probable qu'on aura donc toujours des pilotes propriétaires en parallèle des pilotes libres, mais on peut espérer arriver dans quelques années à une situation où les pilotes libres seront tout aussi performants que les propriétaires à fonctionnalités égales.
[^] # Re: Tres bon
Posté par cluxter . En réponse à la dépêche Sortie du noyau Linux 3.19. Évalué à 10.
En effet, les pilotes libres pour les cartes Nvidia sont développés par rétro-ingénierie par la communauté du libre, contrairement à AMD qui a décidé d'embaucher des personnes à temps plein pour coder des pilotes graphiques open source.
Pour la petite histoire, AMD a recruté les développeurs (notamment Alex Deucher) qui bossaient depuis des années sur les pilotes libres des cartes AMD/ATI et qui prenaient sur leur temps libre pour cela. C'est donc admirable de la part d'AMD d'avoir recruté ces personnes et d'avoir initié un vrai changement dans leur politique de pilotes graphiques. Je me souviens qu'ils auraient aimé pouvoir le faire plus tôt, mais les clauses contractuelles de non divulgation des contrats industriels liaient fortement le matériel et le logiciel, donc AMD a dû attendre quelques années avant d'avoir le droit d'embaucher des salariés qui pouvaient accéder aux fiches techniques des puces pour coder et diffuser des pilotes graphiques libres.
En toute logique viendra un jour où les pilotes propriétaires d'AMD (les "Catalyst") seront entièrement remplacés par les pilotes libres (les "radeon"), puisque les "radeon" feront doublon avec les "Catalyst" et seront normalement (un jour…) aussi performants (sinon plus). Ca c'est moi qui le dit, mais le projet Gallium3D devrait permettre de mieux porter les pilotes entre différents OS, donc ça devrait aider.
Pour l'instant, AMD s'applique à implémenter toutes les fonctionnalités nécessaires dans les pilotes graphiques, pour l'ensemble de ses cartes graphiques depuis l'an 2000 (!!), qu'on peut suivre ici :
http://xorg.freedesktop.org/wiki/RadeonFeature/
Lorsque toutes ces fonctionnalités seront implémentées, il est probable qu'ils s'emploieront à optimiser davantage les pilotes.
Je me souviens lorsqu'Alex Deucher a été recruté en décembre 2007, ce tableau était complètement rouge. 7 ans après quasiment toutes les fonctionnalités ont été intégrées dans les pilotes libres. On peut aisément penser qu'il faudra 3 ans de plus pour terminer le boulot, donc il aura fallut 10 ans pour implémenter les pilotes graphiques libres pour toutes les cartes d'AMD, par une équipe de 5 développeurs officiels (+ les contributeurs de la communauté et d'autres entreprises, disons une dizaine à temps plein), sachant qu'AMD ne met pas beaucoup de moyens sur ces pilotes libres car ça ne représente pas beaucoup de parts de marché. C'est vraiment pas mal quand on sait à quel point les GPU sont des machines complexes.
Je vous invite à lire cette interview très enrichissante :
https://linuxfr.org/news/entretien-avec-jerome-glisse-developpeur-des-pilotes-graphiques-radeon-pour-red-hat
Pour en revenir à Nvidia, la communauté fait un boulot remarquable. Il est déjà extrêmement compliqué de coder des pilotes graphiques quand on a accès aux schémas des cartes, alors lorsqu'on procède par rétro-ingénierie ça relève de l'exploit. Donc oui ce n'est de loin pas parfait, mais c'est le mieux que la communauté puisse faire pour l'instant.
Ce qui est déplorable, c'est l'attitude de Nvidia qui n'a aucune intention d'ouvrir ses pilotes et de travailler sur des pilotes libres. Ce fameux témoignage où Linus Torvald dit qu'Nvidia est la pire des sociétés avec laquelle il a pu collaborer jusqu'à présent résume bien la chose :
https://www.youtube.com/watch?v=19jUboon5gI
Donc si tu souhaites des pilotes graphiques libres avec des performances correctes, tu ne vas pas pouvoir compter sur Nvidia, tu n'as pas d'autre choix que de te tourner vers AMD. Ou Intel ! Intel est une entreprise exemplaire quant au support des pilotes libres de son matériel. Les pilotes sont dans le noyau plusieurs mois avant que le matériel ne soit sur le marché, ce qui fait qu'on a des pilotes Intel supers stables quand on achète du nouveau matos (carte-mère, CPU, GPU, Wi-Fi, etc. ; le pied quoi !).
Voilà voilà, j'ai limite écrit un article entier à moi tout seul, j'espère que ce sera utile à certains ^
[^] # Re: GNU dmd
Posté par cluxter . En réponse à la dépêche Devuan un fork de Debian qui va (peut-être) chambouler notre petit monde. Évalué à -2.
Le projet GNU n'est pas sérieux, OK, je suis d'accord avec toi. Tu es content ?
[^] # Re: GNU dmd
Posté par cluxter . En réponse à la dépêche Devuan un fork de Debian qui va (peut-être) chambouler notre petit monde. Évalué à 3.
En l'occurrence c'est sérieux.
[^] # Re: GNU dmd
Posté par cluxter . En réponse à la dépêche Devuan un fork de Debian qui va (peut-être) chambouler notre petit monde. Évalué à 3.
GNU dmd reste une solution plus élégante que systemd qui lui se contrefout d'être compatible POSIX. C'est une évolution intelligente du système d'init POSIX, pas une rupture totale. Autrement dit, c'est ce que systemd aurait pu (dû ?) être.
# GNU dmd
Posté par cluxter . En réponse à la dépêche Devuan un fork de Debian qui va (peut-être) chambouler notre petit monde. Évalué à 4.
Pour ceux que ça intéresse, voici GNU dmd, un système de démarrage universel et de gestion de services conçu pour les systèmes POSIX, qui reprend le meilleur de SysV-init et de systemd :
http://www.gnu.org/software/dmd/
Maintenant qu'une solution sérieuse est en cours d'élaboration pour remplacer le (très) vieillissant SysV-init et le (très) monolithique systemd, qu'on ne vienne plus me parler des avantages/inconvénients de l'un ou de l'autre. C'est une solution propre, simple, respectueuse des principes de base des *NIX et performante.
[^] # Re: LibreOffice
Posté par cluxter . En réponse au journal "Gummiboot UEFI Boot Loader" sera ajouté à Systemd. Évalué à -7.
A ce moment là pourquoi est-ce qu'on n'intègre pas l'UEFI + le bootloader + l'init + le login ? Histoire d'avoir des machines aussi fermées que les smartphones ? (sinon plus) Parce que bon, il suffit d'ajouter l'UEFI dans 'systemd' est on y est hein…
Des PC où tout serait verrouillé de l'UEFI jusqu'au bureau ? Microsoft l'a rêvé, Red Hat l'a (bientôt) fait.
Je ne suis pas fondamentalement contre le fait d'avoir un logiciel qui nous permette d'intégrer absolument toute la chaîne de démarrage de A à Z dans un logiciel monolithique (on a beau séparer les binaires, ils sont quand même tous dépendants les uns des autres). Ca peut avoir une vraie utilité pour tout un tas de personnes ou d'entreprises.
Mais mettre ce système par défaut dans quasiment toutes les distributions et donc aller à l'encontre des principes de base qui ont fait le succès des *NIX, je trouve ça aberrant. Je suis convaincu que toutes les distributions qui adoptent 'systemd' sont en train de se tirer une balle dans le pied à long terme.
[^] # Re: Journal approximatif
Posté par cluxter . En réponse au journal Systemd contrôlera bientôt tout votre réseau. Évalué à 3.
1) Malgré ça, on assiste à des développeurs Debian officiels qui créent un fork ;
2) "Ce n'est pas parce qu'ils sont une majorité à avoir tort qu'ils ont raison", pour reprendre Coluche. Entendre par là : je tiens à me faire ma propre opinion, même si le meilleur programmeur du monde me dit que j'ai tort, car c'est comme ça que je comprendrai pourquoi j'ai tort (ou lui éventuellement, ça arrive…).
[^] # Re: Journal approximatif
Posté par cluxter . En réponse au journal Systemd contrôlera bientôt tout votre réseau. Évalué à 2.
Tout comme systemd n'a pas grand chose à voir avec une des règles de base d'UNIX malheureusement, à savoir la séparation de tâches simples en briques logicielles indépendantes.
J'ai dit "Il y a des fois où il faut savoir faire marche arrière et se dire que les vieilles recettes sont parfois les meilleures". Pas "Maintenons le statu quo". Parfois, oui, il vaut mieux refuser certaines évolutions qui en réalité amènent autant de problèmes qu'elles n'en résolvent. Ce qui ne veut pas dire qu'il ne faille rien faire pour améliorer par exemple OpenRC.
C'était même tellement bien qu'on a été obligé de créer une v2 de Linux pour y ajouter des modules.
C'est bien tout le coeur du problème : pour avoir systemd, il ne faut que Linux.
Ca fait 3 fois que je l'écris dans ce fil mais je vais le redire : séparer des tâches en briques logicielles indépendantes. C'est un des concepts de base de la programmation système sous les *NIX, j'en veux pour référence cet excellent ouvrage : http://www.oreilly.com/openbook/linuxdrive3/book/
Je te rejoins totalement sur ce point. Mais si c'est remplacer un truc qui pue par un truc moisi, non merci, je préfère encore conserver l'ancien truc en bossant sur un système correct qui viendra le remplacer plus tard (je pense à OpenRC).
Par évolution, j'entendrais quelque chose comme "contribuer à l'existant pour le rendre vraiment meilleur", plutôt que de prendre plein de fonctionnalités et de les agréger en un ensemble de briques pas indépendantes qu'on aura entièrement recodées. Plutôt que de faire un peu de vérification de système de fichiers + un peu de parefeu + un peu de ceci et un peu de cela, systemd ferait bien de ne faire que l'initialisation. Ou s'il veut tout faire, qu'il ait au moins la gentillesse de séparer les briques logicielles de façon indépendantes, qu'on puisse remplacer chaque élément par un autre si l'on préfère. Mais ce n'est pas du tout la logique adoptée ici, et c'est je crois ce qui pose problème à tant de personnes.
[^] # Re: Journal approximatif
Posté par cluxter . En réponse au journal Systemd contrôlera bientôt tout votre réseau. Évalué à 2.
Pour le point 2, OpenRC peut être plus rapide au démarrage que systemd.
Pour le point 3, je suis totalement d'accord et je n'ai jamais compris pourquoi on avait conçu des trucs aussi compliqué pour lancer des choses simples.
[^] # Re: Journal approximatif
Posté par cluxter . En réponse au journal Systemd contrôlera bientôt tout votre réseau. Évalué à -1.
Techniquement, évidemment que ça fonctionne.
Je parle de faire tourner les choses proprement pour qu'on puisse continuer à avoir un système fiable et performant. Linus Torvald est du genre à passer une nuit sur une fonction appelée 1 fois par jour pour gagner 5 cycles microprocesseur, son argument étant de dire que 5 cycles CPU x des millions de machines, ça fait beaucoup d'énergie économisée. C'est cette approche que j'aimerais voir dans les distributions.
Lennart Pottering est bien loin de cet état d'esprit selon moi, sinon il aurait contribué à des systèmes de démarrage existants en vue de les améliorer (je pense à OpenRC qui n'est pas parfait mais qui se rapproche de ce que 'systemd' sait faire, et pour le coup de manière propre, intelligente et compatible UNIX).
[^] # Re: Journal approximatif
Posté par cluxter . En réponse au journal Systemd contrôlera bientôt tout votre réseau. Évalué à 2.
Tout comme ça serait sûrement très pratique que 'systemd' fasse le café.
Est-ce intelligent pour autant ? Non.
Ce n'est pas parce qu'on peut le faire qu'on doit le faire.
Visiblement certains semblent oublier pourquoi les *NIX ont réussi à devenir des OS de référence et à tenir la distance depuis tant d'années. Une de ces raisons, c'est qu'on a segmenté les tâches simples sous formes de briques assemblables et indépendantes, plutôt que de tout mettre dans un gros ensemble qui ferait tout et sur lequel tout reposerait.
Ca fait 40 ans qu'on aurait pu écrire un 'systemd'. Si ça n'a pas été fait c'était pour de bonnes raisons. Il y a des fois où il faut savoir faire marche arrière et se dire que les vieilles recettes sont parfois les meilleures.
# HTML 5 ?
Posté par cluxter . En réponse à la dépêche Sortie de SynfigStudio 0.64.3 : BugFix!. Évalué à 4.
Est-il possible d'exporter une animation au format SVG + CSS pour l'intégrer dans une page HTML 5 / CSS 3 ? Si c'est le cas je me jette sur ce logiciel !
[^] # Re: Windaube
Posté par cluxter . En réponse à la dépêche Revue des nouveautés de Glances 2.2. Évalué à 1. Dernière modification le 23 décembre 2014 à 02:39.
Je compare quotidiennement la différence entre mon ordi au boulot sous Windows 7 (Windows XP ne s'en sortait pas mieux) et mon ordi perso sous Debian.
Et en l'occurrence je tendrais aussi à surnommer Windows "Windaube" parce que je n'ai pas eu un problème avec, mais j'ai un problème par jour avec, quand j'en ai un par an avec Debian…
J'étais sous Windows 3.1, Windows 3.11, Windows 95, Windows 98, Windows XP, Windows Vista et Windows 7. Puis j'ai testé Linux (Debian en l'occurrence) et là j'ai pleuré en repensant aux centaines d'heures passées à configurer, paramétrer, installer, réinstaller, formatter, reformatter, nettoyer les virus, renettoyer les virus, etc. etc. etc., pour finalement recommencer.
"Windaube" je trouve ça un peu enfantin comme nom c'est vrai, mais à l'usage c'est exactement ça. Je n'arrive toujours pas à lui trouver un avantage sur Linux, si ce n'est peut être qu'il est installé sur 90 % des PC et donc que c'est très pratique quand on veut péter la sécurité d'un système.
Simple exemple : désigner des lecteurs par des lettres comme "C:" au lieu de fichiers, ça rend tout le système complexe à maintenir et incompatible avec plein de trucs, ne serait-ce que pour les liens entre mes fichiers Excel au boulot. Quand un collègue bosse avec un fichier stocké sur R: et que moi il est déclaré en P: et bien c'est le bordel, il faut se taper l'actualisation des liens un par un à chaque fois (bien sûr on ne peut rien changer). C'est quand même très con et ça fait perdre des dizaines de minutes pour rien chaque semaine. Même logique avec les lettres des lecteurs réseaux qui sont remplacées automatiquement sans prévenir par quelque chose comme "//mon/emplacement/réseau". Bref, Windows me gave et ce n'est pas du fanatisme, pour moi c'est une réalité quotidienne que je dois subir.
Là je donne un exemple de quelque chose de relativement bénin, mais j'ai été confronté à des cas d'emmerdement où j'avais juste envie de brûler mon PC sur place. En toute honnêteté, je n'arrive pas à voir en quoi Windows peut être mieux que Linux. Au mieux je peut concéder l'unicité de l'environnement de travail pour une version donnée qui permet à tous les utilisateurs de s'y retrouver lorsqu'ils passent d'un poste de travail à un autre, mais ça s'arrête là.
[^] # Re: Les raisons du fork
Posté par cluxter . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 1.
Ce qui ne change absolument rien aux raisons du fork. Ma phrase n'est pas plus idiote que celle que j'ai citée.
# Les raisons du fork
Posté par cluxter . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à -2.
Par pitié, arrêtez avec ça. Ce fork n'est pas à cause de 'systemd'. Tout comme le départ de plusieurs développeurs Debian ces dernières semaines.
Cette volonté de forker vient du fait que les leaders de Debian ont voté contre l'obligation de maintenir les paquets comme 'gnome' ou 'kde' compatibles avec 'sysvinit'. Cela implique que 'gnome' ne pourra plus être utilisé sans 'systemd', ce qui impose donc de fait un système de démarrage, au détriment de tous ceux qui ont besoin pour une raison ou pour une autre d'utiliser 'sysvinit' (utiliser un noyau UNIX par exemple, et ça me semble être une très bonne raison).
Que 'systemd' soit dans les dépôts de Debian malgré sa philosophie anti UNIX et son code discutable, c'est une chose. Et à vrai dire c'est supportable du moment qu'on nous laisse la liberté de choisir un autre système de démarrage dans les dépôts.
Or c'est précisément cette liberté qui a été refusée aux administrateurs systèmes du monde entier, en dépit de leurs (nombreux) appels de détresse, mais surtout à l'encontre du pacte social qui a fait de Debian sa réputation.
Voilà pourquoi il a été décidé de forker Debian. C'est un problème de liberté et de confiance rompue. Pas de code.
[^] # Re: C'est dommage
Posté par cluxter . En réponse à la dépêche Gel de Debian 8.0 Jessie. Évalué à 2.
Donc ça confirme d'autant plus l'inutilité de la Testing sur un poste de travail autrement que pour débugguer la future version de Debian =)
Si la Stable avec des backports est capable de faire la même chose que la Testing pour 95 % des logiciels qu'on utilise, pourquoi vouloir utiliser une branche instable et moins sécurisée ? Je ne vois pas de raison objective à cela (si ce n'est, je me répète, pour contribuer au débuggage de la future Debian).
[^] # Re: C'est dommage
Posté par cluxter . En réponse à la dépêche Gel de Debian 8.0 Jessie. Évalué à 1.
De même, j'ai eu affaire à une machine extrêmement récente et la Stable ne fonctionnait pas (carte mère mal supportée, notamment la partie graphique). J'ai installé le dernier kernel disponible dans les backports et plus aucun problème.
Sur une machine classique, la Testing n'apporte rien de plus que les backports d'un point de vue système (puisque les backports sont généralement alignés sur la Testing !). Pareil pour tout ce qui est bureautique.
Sur une machine plus exotique (avec des périphériques de montage vidéos spéciaux par exemple), c'est autre chose. Tout ce qui touche au multimédia a tendance à nécessiter des logiciels récents, donc dans ce cas je comprends que la Testing puisse être nécessaire.
Une autre raison d'utiliser la Testing, c'est si on a absolument besoin d'un élément mis à jour comme 'wayland' ou 'systemd'. Là on touche au coeur du système et les backports ne peuvent pas faire le boulot. C'est selon moi le seul cas où on pourrait être amené à utiliser une Testing "en production".
[^] # Re: C'est dommage
Posté par cluxter . En réponse à la dépêche Gel de Debian 8.0 Jessie. Évalué à 1.
Tu parles de personnes qui mettent les mains dans la cambouis pour debugguer Debian là. Donc on est bien d'accord : la Testing est faite pour ceux qui sont suffisamment à l'aise pour remonter les bugs et contribuer au développement de Debian.
Ma phrase est assez radicale et volontairement provoc, je l'admets.
A part un groupe d'ubergeeks prêts à casser du bug, je ne vois pas l'intérêt d'utiliser une Testing sur un poste de travail pour faire du montage vidéo, pour surfer, pour faire de la bureautique,…
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par cluxter . En réponse à la dépêche Gel de Debian 8.0 Jessie. Évalué à 8.
J'ai bien compris ce que tu voulais dire, c'est peut être moi qui n'ai pas réussi à exprimer mon idée.
Même si c'est effectivement beaucoup d'efforts pour un nombre restreint d'utilisateurs, je pense que ce sont précisément ces utilisateurs qui changent le monde en faisant des trucs a priori inutiles, farfelus, mais qui façonnent peu à peu nos connaissances et nous donnent envie de créer chaque jour de nouvelles choses, utiles cette fois.
Quel intérêt de porter Linux sur une TI-89 ? On peut franchement se le demander. Sauf que j'ai eu énormément de plaisir à coder en assembleur sur ma TI-83 puis ma TI-89. Et ce que j'ai fait n'a servi à rien concrètement. Mais j'ai appris énormément de choses et la valeur que j'en tire aujourd'hui en valait sacrément la peine. Je pense aux boulots que ça m'a permis d'avoir, mais bien au-delà de ça de tout ce que ça m'a apporté comme connaissances et épanouissement personnel. Pour moi c'est ça le hacking.
Porter Debian sur autant d'architectures différentes nécessite une montagne de boulot incroyable, mais si on calcul le ratio Efforts requis / Nombre d'utilisateurs, alors autant laisser Microsoft faire son boulot et se contenter de ce qu'ils nous fournissent, plutôt que de chercher à économiser 5 cycles processeur sur une interruption appelée 3 fois par jour… Le libre c'est avant tout s'amuser à développer des systèmes pour la beauté de la chose. Si on peut rendre ça rentable, alors c'est carrément mieux, on est d'accord. Mais ce n'est pas ce qui a motivé le développement de Linux ou de Debian, et c'est pour ça que ce sont de si bons systèmes. Si ça amuse des mecs dans leur garage de maintenir des paquets qui ne servent à personne (même pas à eux), et bien le fait qu'ils prennent leur pied à le faire est déjà suffisant selon moi.
C'est sûr que j'aimerais qu'ils passent plus de temps à porter Compiz sous Debian Wheezy plutôt que de faire tourner des logiciels de radioamateur pour des PowerPC, mais les besoins et les motivations de chacun sont différents. Je suis sûr que les geeks barbus qui ne jurent que par la ligne de commandes se demandent bien pourquoi j'ai besoin de Compiz. Et pourtant…
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par cluxter . En réponse à la dépêche Gel de Debian 8.0 Jessie. Évalué à 1.
Ah oui quand même x-)