J'ai jamais autant rit quand lisant la nouvelle sur pulseaudio ! Et comme cela n'est pas le 1er avril, on dirait même que c'est vrai !
Un remède radical, ALSA + JACK +
cat ~/.asoundrc
pcm.rawjack {
type jack
playback_ports {
0 system:playback_1
1 system:playback_2
}
capture_ports {
0 system:capture_1
1 system:capture_2
}
}
pcm.jack {
type plug
slave { pcm "rawjack" }
hint {
description "JACK Audio Connection Kit"
}
}
pcm.!default {
type plug
slave { pcm "rawjack" }
}
pcm.dsp pcm.!default
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Autrement dit l'événement qui aurait du se produire à 17 heure ne s'est pas produit, ce qui explique pourquoi Tchernobil à pété ! Super systemd.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Oui il existe un doc complète. Le problème n'est pas là. Le problème pour comprendre systemd est que ce logiciel évolue à toute vitesse et que pour le comprendre et suivre cette évolution, il faut être un développeur payé à plein temps pour ça.
Une autre conséquence de cette évolution rapide est que ce logiciel est tous sauf stable et bien testé. Il s'agit au mieux d'un soft de qualité béta.
De plus, systemd n'a pas fini d'évoluer à toute vitesse car il est intimement lié aux cgroups du kernel, lesquels sont en train d'être ré-écrits complètement. Ce qui va prendre facilement encore au moins une année. Donc systemd de meme que sa doc n'ont pas finis d'évoluer, l'avalanche de bugs n'est pas prête d'être résorbée, et il n'est pas prêt d'être stabilisé, ce qui me semble la moindre des choses pour un soi-disant système d'init qui ressemble de plus en plus à une usine à gaz.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Il faut pas inverser les choses. Si certains utilisateurs d'ordinateurs sont allergiques à la console, ce n'est pas la faute des programmeurs, mais de ces utilisateurs qui ainsi ne comprendront jamais comment fonctionnent leur ordinateur et ne seront jamais capable de le maîtriser.
Ceci dit je ne suis pas non plus un inconditionnel de la console, mais simplement pour bien des tâches répétitives, la console est bien mieux car tu peux faire des scripts. Bash/sh/… proposent de véritables langages de programmation facilement accessibles, Mon premier script ne faisait qu'une ligne, et aujourd'hui mon plus gros en fait plus de 1000. Pour moi, avoir un ordi et ne pas utiliser la console, c'est comme acheter une ferrari pour rouler dans les bouchons.
Pour l'administration système aussi la console c'est mieux car tu es en contact directement avec le système, ce qui te permet de l'apprendre au lieu d'apprendre des surcouches, et te permet aussi de faire ce que les surcouches des fois ne savent pas faire ou rajoutent des bogues.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Une autre source potentielle d'économie d'énergie et de gain d'efficacité serait de faire des processeurs hybrides. Aujourd'hui, la tendance est aux multicoeurs où tous les coeurs sont identiques, mais je verrais très bien un multicoeur avec 1 coeur basse consommation et basse fréquence pour le standby, un coeur dédicacé pour le hardware, un coeur générique pour le GUI, et un coeur DSP pour les calculs.
Il faudrait recompiler les programmes pour que leurs différentes parties aillent sur le bon coeur, mais rien d'impossible. Et beaucoup d'économies d'énergies car si un centre de calcul consomme des MW, tous les ordinateurs d'un pays consomment bien d'avantage. De plus, les algorithmes DSP ont prouvé leur supériorité en terme d'efficacité pour tout ce qui est calcul depuis plusieurs décennies maintenant. Avec l'arrivée de ces processeurs hautement parallèles qui arrivent, c'est certainement une nouvelle page de l'informatique qui commence.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Il ne faut pas oublier que la miniaturisation a commencé avec les tubes.
Le premier ordinateur de l'histoire fut réalisé avec des tubes, et même s'il occupait tout un immeuble ricain, c'était déjà de la miniaturisation.
Pour le comprendre, il suffit de comparer un orgue Hammond à tubes, lequel ne prend pas plus de place dans un salon qu'un piano, avec son ancêtre, le telharmonium et ses 200 tonnes : https://fr.wikipedia.org/wiki/Telharmonium
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Posté par Domi .
En réponse au journal Linux facile.
Évalué à 0.
Dernière modification le 26 janvier 2014 à 23:24.
Le monde des distributions est vaste, donc il est difficile de généraliser. Il existe cependant deux familles principales de distros, les binaires et les sources. Le problème des distributions binaires est le même que celui de windows, mais comme nous avons la chance d'avoir une gestion centralisée du système il est moins pire. Dans le cas d'un update mineur du système et si l'on a pas rajouté de dépôts distants, cela passe sans problème. Avec des dépôts distants, apt ou yast, etc. refusent de faire la mise à jour s'il y a un conflit de dépendances, ce qui est bien mieux que la gestion à la windows où la mise à jour est effectuée sans contrôle aucun des dépendances.
En cas d'update majeur du système, comme de passer d'OpenSuSE 8 à 9, cela se complique. Il y a généralement deux solutions: comme sous windows formater et tout réinstaller, ou passer des heures à régater sur les forums.
Avec les distributions sources, l'évolution est continue. Donc il n'y a jamais de saut de version. De plus, les dépendances sont ce qui est installé dans la machine, et en cas de problèmes de dépendances, le programme de gestion des logiciels les repère et il recompile ce qui doit l'être. Ce qui implique que ceux qui sont vraiment intéressé par une maintenance fluide sur le long terme devraient passer à une distribution source.
Il existe aussi des distributions comme Arch qui proposent une gestion des programmes à la FreeBSD. Il est alors possible d'installer le même programme depuis une archive binaire ou depuis ses sources.
Le problème de la maintenance à long terme d'une installation Linux est donc aussi lié au niveau de son administrateur. Si ce n'est pas impossible, il est difficile d'imaginer un mécanicien ou une employée de commerce ne connaissant pas Linux allez acheter un pc et commencer à installer gentoo. Donc il ou elle va installer Ubuntu ou Debian ou OpenSuSE, et au lieu de se plaindre devrait déjà s'estimer heureuse qu'avec la dizaine de dépôts distants rajouté en une semaine, apt ou yast refusent de lui casser son système.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
En tant que manager de deux projets open source, j'ai changé, après discussion avec les développeurs, la licence d'un des deux projets de GPL2 à GPL3. La raison pour moi de préférer la GPL à la BSD, et la GPL3 à la GPL2, est très simple: ces logiciels ont été fait bénévolement pendant leur temps libre par des développeurs, et si des sociétés privées veulent les utiliser dans leurs propres projets commerciaux, la moindre des choses qu'ils doivent faire est de contacter au préalable les développeurs concernés pour trouver un terrain d'entente.
De plus, ils peuvent dire ce qu'ils veulent chez BSD, la base d'utilisateurs de GNU/Linux est beaucoup plus importante que celle de BSD. Donc la licence est secondaire de ce point de vue. Si je connais des développeurs Linux qui sont en train de migrer sous d'autre systèmes, à commencer par FreeBSD, ce n'est pas en raison de
De plus, si des sociétés privées adoptent BSD, beaucoup d'administration préfère migrer de windows à Linux que de windows à BSD.
la licence mais parce qu'ils en ont marre de l'usine à gaz qu'est en train de devenir Linux. Et je partage leur avis.
Par contre je n'ai pas le choix. Beaucoup des softs qui m'intéressent (audio pro) n'existent pas sous FreeBSD, et j'ai essayé une fois d'en compiler un sous FreeBSD, échec total car si de nombreuses bibliothèques ont été portées sous FreeBSD, d'autres n'existent pas et leurs équivalences proposent d'autres API. Donc nécessiter de patcher les programmes pour que la compilation réussisse.
Et c'est bien ceci qui fait le succès de GNU/Linux: le grand choix de programmes disponibles. Et là, BSD ne peut pas régater. On en reparlera peut-être dans 5 ou 10 ans si suffisamment de développeurs Linux passent sous BSD, mais pour le moment, il y a beaucoup plus de programmes disponibles sous Linux que sous BSD, et donc beaucoup plus d'utilisateurs de Linux.
Pour moi, le problème de la licence est plus liée au type de société que nous voulons promouvoir qu'à des considérations techniques de savoir si tel ou tel programme à été porté sur telle ou telle licence. Si nous voulons continuer avec le capitalisme, la licence BSD est la voie à suivre. Si nous voulons nous diriger vers une société post capitaliste, la license GPL est la voie à suivre. Et vu les problèmes actuels liés au capitalisme comme la transformation systématique des ressources naturelles en sources de pollution et l'épuisement des ressources non renouvelables que ce mode de vie engendre, problèmes qui ne pourront être résolus que dans une société post capitaliste, je pense que la GPL est la voie à suivre. Ce qui fait que je préfère de toutes façons continuer avec GNU/Linux.
EDIT: Je rajouterais même que le modèle de développement du logiciel libre est la meilleure preuve qui sot qu'une alternative au capitalisme est possible, et qu'il n'est pas nécessaire d'attendre la fin du capitalisme pour la construire.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Il semble qu'il y ait encore un autre problème lié à systemd, c'est Gnome. La dernière version de Gnome a besoin de systemd pour que toutes ses fonctions soient disponibles. http://wiki.gentoo.org/wiki/GNOME/3.8-upgrade-guide#Systemd Ce qui laisse peu de choix pour une distribution binaire:
Soit elle ne supporte pas Gnome
Soit elle supporte Gnome et systemd
Soit elle supporte Gnome sans systemd et doit faire du travail supplémentaire pour intégrer Gnome autant que faire se peut.
De toute façon, l'avenir nous dira si systemd va vraiment s'imposer ou s'il va finir comme Hal.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Et je rajouterais même que je connaît de nombreux développeurs, et pas des moindres pour certains, qui entre autre à cause de ce genre de problèmes, ont pris la décision de migrer sur d'autres systèmes, à commencer par FreeBSD, quand ce n'est pas déjà fait.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Tout ce que je sais est que sans systemd, la même configuration des cgroups fonctionne parfaitement dans mon installation actuelle ainsi que dans la précédente, et que dans celle du milieu avec systemd, je me retrouvais avec des trucs que je n'ai pas configuré dans mon groupe temps réel. Et que comme ils n'étaient pas configurés, ce ne peut pas être cgroup-bin/libcgroup qui les y a mis.
De plus, comme ce groupe temps réel utilise le cgroup cpu et que systemd utilise aussi le groupe cpu, je ne vois pas quel programme autre que systemd pouvait mettre ces trucs dans mon groupe temps réel.
Maintenant, que j'ai vu passer un message d'apt-get me demandant d'activer systemd est une possibilité. Quand j'ai vu que systemd était installé, je ne le connaissais pas, et je n'avais à priori rien contre. Au début tout allait bien, c'est quand, après avoir installé mon kernel dans lequel j'ai viré toutes les options des cgroups sauf le groupe cpu et son séquenceur temps réel, j'ai installé et configuré cgroup-bin, que les problèmes ont commencé et que je me suis retrouvé avec un système qui passait son temps à se bloquer sans rémission possible.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Avec JACK, les deux solutions me permettent d'obtenir une latence audio dans JACK aussi faible qu'une milliseconde, ce qui me permet d'avoir un système fiable dans tous les cas avec une latence comprise entre 10 et 20 ms. Un kernel standard ne permet de faire ça qu'avec RT_GROUP_SCHED.
Il montre pourquoi l'audio est un gros bordel sous GNU/Linux. Il montre aussi deux choses sur Lennart. D'abord c'est un mec plein de bonne volonté et qui s'investit beaucoup. Ensuite il a un ego disproportionné et quand sa solution n'est pas adoptée ou est critiquée, plutôt que d'accepter la critique et discuter de ce qui peut être changé, il se braque et traite ses interlocuteurs de "desktop haters". Ce qui clos la discussion.
Avec JACK, et une dizaine de lignes dans mon .asoundrc, j'interface JACK et les applications ALSA, ceci sans latence supplémentaire, et chaque application ALSA apparaît dans le graphe de connexion de qjackctl, j'obtiens à peu près la même chose qu'avec pulseaudio, mais avec une latence constance au lieu d'avoir une latence qui augmente au premier xrun dans pulseaudio, avec comme seule possibilité pour la faire redescendre de devoir stopper et redémarrer pulse. http://www.linuxmao.org/ALSA+Router+un+flux+ALSA+vers+JACK Quand je vois ça, je suis sur et certain que si la communauté audio pro avait été écoutée, au lieu de développer un système non professionnel comme pulseauedio, il aurait été possible, en construisant uniquement sur ALSA et JACK, d'obtenir la même chose, mais mieux car professionnel, et ceci vraisemblablement avec bien moins d'efforts que ceux qui ont été mis en oeuvre pour développer pulse, car toutes les briques de base existent.
Quand à systemd, selon plusieurs développeurs de la LAD (liste Linux Audio Development), même si certains d'entre eux l'utilisent, il est en train de devenir un plus grand problème que celui qu'il est censé résoudre, ceci pour la raison que systemd fourni des politiques de gestion du système au lieu de fournir les moyens de créer des politiques de gestion. Ce qui limite la liberté du choix des utilisateurs de créer leurs propres politiques de gestion du système. Et quand je parle de ce problème avec eux, les développeurs de systemd me répondent que Linux n'a jamais été une question de choix, ce qui clos toute discussion.
Je comprends très bien, étant moi-même manager de plusieurs projets, que la liberté de choix d'un développeur peut venir en conflit avec la liberté de choix des utilisateurs, mais j'estime aussi que cela fait partie du devoir d'un développeur, s'il casse quelque chose offert à ses utilisateurs, de proposer une nouvelle façon de le faire. Pour cela, je suis toujours très clair avec les nouveaux développeurs qui joignent mes projets: ils peuvent faire ce qu'ils veulent tant qu'ils ne cassent pas les fonctions existantes des programmes. Ils peuvent les modifier, mais les fonctionnalités présentes avant leurs modifications doivent continuer à exister.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Tu as raison, il n'est pour rien dans ce coup là. En fait c'est même lui qui avait signalé ce bug. Je vais éditer le premier message si c'est possible pour qu'il reflète ça.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Posté par Domi .
En réponse au message Les cgroups et systemd.
Évalué à 1.
Dernière modification le 13 janvier 2014 à 21:04.
Mon cgroup temps réel fournit cpu.rt_runtime_us, ce qui est comparable au temps réel fourni par un kernel -rt, et qui n'est pas fourni avec le kernel standard de Debian. Pour l'avoir, j'ai du compilé mon propre kernel à partir des sources de celui de Debian. Donc nous ne devons pas parler du même temps réel. Je parle de CONFIG_RT_GROUP_SCHED, pas de SCHED_FIFO.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Merci pour le lien. Voilà qui me donne une raison de plus d'aller discuter avec les devs des cgroups du kernel.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Aucune, j'ai formaté et contrôlé le disque avant d'installer gentoo. Donc je n'ai aucun moyen de savoir pourquoi systemd avait été installé. Et de nouveau, je n'ai rien contre Debian qui est une excellente distribution, ce sujet est sur systemd et les cgroups.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
J'ai certainement du la lire à l'époque où j'ai installé ce Debian. Je me rappelle avoir tout essayé, ce qui ne veut pas dire que j'ai forcément fait tout juste, mais comme mon système passait son temps à se bloquer, et que personne n'a pu m'aider sur le forum de Debian, même pas avec un pointeur sur de la doc ou en me disant que je pouvais virer systemd et le remplacer par init, je suis rapidement passé à autre chose et j'ai reformaté et contrôlé le disque avant d'installer gentoo.
Ce n'est que hier en lisant le mail de Lennart que j'ai commencé à comprendre qu'une configuration des cgroups comme la mienne ne peut simplement pas fonctionner avec systemd dans l'état actuel des cgroups et de systemd. Je n'ai qu'un seul cgroup, un groupe cpu temps réel, et comme c'est le seul cgroup cpu, systemd voit que c'est un groupe cpu et il le pollue, ce qui tôt ou tard résulte en un blocage total du système.
De plus, en parallèle à cette discussion, j'en ai une avec les développeurs de systemd, et un d'entre eux m'a conseillé, comme j'ai une config custom des cgroups, de ne pas utiliser systemd. Ce qui me donne raison. Le stade suivant pour moi est d'aller voir les devs des cgroups du kernel car il m'a dit qu'ils sont en train de tout changer.
Quand aux choix de Debian, j'ai été surpris de la facilité pour virer *kit. Je ne dénigre absolument pas Debian, c'est une distribution qui a fait ses preuves et que j'avais déjà utilisée dans le passé avant gentoo. Il y a aussi eu Suse que j'ai utilisé pendant de nombreuses années avant Debian, plus un intermède gentoo au milieu de Debian. Donc pas mal d'années sous GNU/Linux (depuis mon 386) et sous différentes distributions. Il y en a eu encore d'autres comme Agnula et Demundi, basées sur Debian, pour ne citer que celles que j'ai réellement utilisées.
Autrement, j'ai aussi essayé AROS. Excellent système dont le bureau, même en tant qu'hôte linux, est beaucoup plus rapide que ceux de GNU/Linux. Malheureusement, il y a encore peu de logiciels disponibles.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Posté par Domi .
En réponse au message Les cgroups et systemd.
Évalué à 1.
Dernière modification le 13 janvier 2014 à 01:53.
Quoi qu'il en soit, quand j'ai installé Debian, systemd à été installé. De plus, j'ai installé gentoo ce qui a résolu mon problème (voir plus bas).
Le problème de systèmed avec les cgroups est qu'il installe, comme je l'ai compris en lisant ce qui dit Lennart dans l'article de linux.fr, j'ai aussi lu l'entier de ce qu'il dit sur gmane (le lien est dans l'article), le problème est que systemd implémente seulement un subset des cgroups qui correspond à l'option automatique du kernel, qu'il prend le contrôle des cgroups, et que contrairement au kernel associé avec libcgroup/cgroup-bin, systemd ne met aucune réelle possibilité de setup à disposition de l'utilisateur.
Ceci implique que n'importe quel utilisateur qui utilise autre chose que la configuration automatique des cgroups dans le kernel ne peut pas utiliser systemd. Donc, la communauté audio pro n'est sûrement pas la seule concernée par ce problème avec systemd.
La cause de ce problème est pour moi une fausse conception de ce que fait un utilisateur avec son pc. Pour moi, un pc ça sert à travailler. Pour le développeur en chef de systemd, comme il le dit très bien dans son mail sur gmane, un pc sert à faire tourner un GUI et toutes les autres utilisations ne sont pas relevantes.
Ce qui implique que pour résoudre ce problème, il faudrait revoir l'API de systemd pour qu'il supporte toutes les fonctions cgroups du kernel, ceci même en mode non automatique, et pour qu'un plus systemd soit capable de proposer un interface de configuration des cgroups à l'utilisateur.
Quand à mon gentoo, une partie de mes USE flags sont "-systemd -consolekit -policykit -pulseaudio -udisks -udisks2", donc un système léger sans tous ses machins superflus qui apportent plus de problèmes que de solutions. Je ne remet pas en cause l'idée de systemd, mais je constate simplement que son implémentation actuelle est contraire à l'esprit de GNU/Linux qui est d'offrir le choix aux utilisateurs. LEs cgroups du kernel, en conjonction avec libcgroup/cgroup-bin, permettent d'optimiser une machine donnée pour n'importe quelle sorte de charge de travail. Avec systemd, seule une configuration par défaut est proposée, et il n'y a aucune possibilité de sortir de cette configuration par défaut. De plus la documentation est quasi inexistante, ce qui est normal vu le peu de possibilités de configuration.
Lennart le dit lui même:
"In fact, I just prepped a patch to systemd to move every service and every user session into its own cgroup in the 'cpu' hierarchy (in addition to the group it already creates in the 'systemd' hierarchy). On a system that runs systemd for both managing users and sessions this means you are already half-way at what you want.">
Ce qui implique que son implémentation des cgroups dans systemd est à moitié incomplète.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Pour moi, il y a une petite inconsistance. Le nom du fichier de ton script se termine en .sh, ce qui laisse supposer que le shebang de ton script est #!/bin/sh, alors qu'il est en réalité #!/bin/bash. Sous linux, le système utilise le shebang pour déterminer comment il va exécuter un script, donc le .sh est superflu, et dans ton cas, il peut porter à confusion.
Il faut aussi voir que bash et sh n'ont pas la même syntaxe. Par exemple, sh ne comprend ni "if [[…]]", ni les variables tableaux. Avec Debian, c'est pas grave car sh est un lien symbolique sur dash, lequel est compatible avec sh, mais dans de nombreuses autres distributions, sh est un lien symbolique vers bash. Avec ces dernières distributions, un script sh avec une syntaxe bash fonctionnera, mais le jour où tu le mettra sous Debian, il ne marchera pas.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Il est simple à utiliser. Ces dépendances sont mplayer, mencoder et xdialog.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Tu parles pour toi et tu généralises ton cas. J'aime pas ce genre de démarche. Pour preuve, je connait un musicien, David Rovics, c'est un gars très sympa, un auteur-compositeur-interprète qui vent sa musique. Mais il l'a aussi mise en téléchargement libre sur internet, ainsi que des vidéos et même les textes et les partitions. Lors d'une discussion, il m'a dit qu'il n'avait jamais autant vendu de disques que depuis qu'il a mit toute sa musique en téléchargement libre.
Tu pourras objecter que, vu le contenu des textes de ces chansons, pas beaucoup de radio doivent le passer. Et tu auras parfaitement raison. Mais il a su trouver, grâce à internet et aux nombreuses manifestations auxquelles il participe, le moyen de se faire de la pub. Et comme il a quelque chose à dire, ses textes et sa musique sont sa meilleure pub.
Nous parlons du libre ici. Les médias commerciaux ne parlent pas plus du libre qqu'ils ne parlent de David Rovics, ou alors ils nous parlent toujours des 2 mêmes programmes, généralement de linux (souvent sans même dire qu'il ne s'agit que du kernel) et parfois d'open office. Le libre a aussi su créer ses propres canaux pour se faire connaitre comme par exemple ce site. De plus, si ton code et tes graphismes sont bien, cela fera toujours bien sur ton cv.
Je suis aussi musicien, donc je sais que c'est beaucoup de travail. Cependant je ne suis pas pour autant dupe de la propagande des majors et des éditeurs. Avec l'informatique, la structure même de l'industrie de l'édition a changé. Avant, l'important était de posséder les moyens d'enregistrement et de duplication. Avec l'informatique, l'important est de posséder les droits sur les enregistrements et les oeuvres. Les moyens de production sont à la portée de n'importe qui a les moyens de se payer un bon instrument de musique.
C'est en fait une chance, les artistes peuvent ainsi s'émanciper des majors et des éditeurs pour devenir indépendants. Et ça, les majors l'ont bien compris mais, à part essayer de nous voler nos droits en faisant du lobbying pour changer la législation, elles ne peuvent rien faire contre cette évolution. Et même les nouvelles législations venues des States ne peuvent rien contre un artiste indépendant, bien au contraire, comme les anciennes lois, elles protègent ses droits sur ses oeuvres. Les musiciens ont été le premier à le comprendre, la preuve en est la multiplication des petits labels indépendants.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Si tu lis la FAQ, le gestionnaire de fenêtre existe toujours, simplement, comme dans l'AmigaOS, il est incorporé dans le serveur d'affichage et le compositeur.
Si wayland est bien fait, il doit être possible de gagner beaucoup pour tout ce qui touche à l'affichage. Si je compare aeros (une version libre de l'AmigaOS qui peut être installée comme hôte linux ou en natif), le Gimp se lance 4 ou 5 fois plus rapidement sous aeros installé comme hôte sous linux que Gimp en natif linux dans la même machine. Ce qui ne change pas par contre sont les temps de traitement des filtres sur les images. Mais au niveau du lancement des applications et de la fluidité de X, la différence est impressionnante.
Donc, affaire à suivre. Je pense cependant que pour les applications wayland, cela devrait être rapide. Pour les applications X lancées sous wayland, c'est à voir. Quand à lancer X sous wayland, ce sera (d’après la FAQ) un petit peu plus lent.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Mon premier pc décent était un Amiga. Dans l'AmigaOS, il n'y a qu'un seul toolkit qui est intégré dans le serveur graphique. Le toolkit de l'Amiga est l'équivalent de Xlib + toolkit xyz. De plus, une partie était intégré dans le kernel. Ce qui avait l'avantage de la simplicité et d'être rapide même sur un processeur qui ne tournait qu'à 8MHz et disposait que de quelques MB de ram. Le tout en couleur et sonorisé, basé sur un kernel préemptible multitâche. Le meilleur de mes ordis.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
# Ils ont de l'avance, c'est pourtant pas le premier avril !
Posté par Domi . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à -10.
J'ai jamais autant rit quand lisant la nouvelle sur pulseaudio ! Et comme cela n'est pas le 1er avril, on dirait même que c'est vrai !
Un remède radical, ALSA + JACK +
cat ~/.asoundrc
pcm.rawjack {
type jack
playback_ports {
0 system:playback_1
1 system:playback_2
}
capture_ports {
0 system:capture_1
1 system:capture_2
}
}
pcm.jack {
type plug
slave { pcm "rawjack" }
hint {
description "JACK Audio Connection Kit"
}
}
pcm.!default {
type plug
slave { pcm "rawjack" }
}
pcm.dsp pcm.!default
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: Timers
Posté par Domi . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à -9.
Autrement dit l'événement qui aurait du se produire à 17 heure ne s'est pas produit, ce qui explique pourquoi Tchernobil à pété ! Super systemd.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Domi . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 8.
Oui il existe un doc complète. Le problème n'est pas là. Le problème pour comprendre systemd est que ce logiciel évolue à toute vitesse et que pour le comprendre et suivre cette évolution, il faut être un développeur payé à plein temps pour ça.
Une autre conséquence de cette évolution rapide est que ce logiciel est tous sauf stable et bien testé. Il s'agit au mieux d'un soft de qualité béta.
De plus, systemd n'a pas fini d'évoluer à toute vitesse car il est intimement lié aux cgroups du kernel, lesquels sont en train d'être ré-écrits complètement. Ce qui va prendre facilement encore au moins une année. Donc systemd de meme que sa doc n'ont pas finis d'évoluer, l'avalanche de bugs n'est pas prête d'être résorbée, et il n'est pas prêt d'être stabilisé, ce qui me semble la moindre des choses pour un soi-disant système d'init qui ressemble de plus en plus à une usine à gaz.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: TrueCrypt
Posté par Domi . En réponse à la dépêche Chiffrement, vie privée et logiciel libre. Évalué à -1.
Il faut pas inverser les choses. Si certains utilisateurs d'ordinateurs sont allergiques à la console, ce n'est pas la faute des programmeurs, mais de ces utilisateurs qui ainsi ne comprendront jamais comment fonctionnent leur ordinateur et ne seront jamais capable de le maîtriser.
Ceci dit je ne suis pas non plus un inconditionnel de la console, mais simplement pour bien des tâches répétitives, la console est bien mieux car tu peux faire des scripts. Bash/sh/… proposent de véritables langages de programmation facilement accessibles, Mon premier script ne faisait qu'une ligne, et aujourd'hui mon plus gros en fait plus de 1000. Pour moi, avoir un ordi et ne pas utiliser la console, c'est comme acheter une ferrari pour rouler dans les bouchons.
Pour l'administration système aussi la console c'est mieux car tu es en contact directement avec le système, ce qui te permet de l'apprendre au lieu d'apprendre des surcouches, et te permet aussi de faire ce que les surcouches des fois ne savent pas faire ou rajoutent des bogues.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
# processesurs hybrides
Posté par Domi . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 0.
Une autre source potentielle d'économie d'énergie et de gain d'efficacité serait de faire des processeurs hybrides. Aujourd'hui, la tendance est aux multicoeurs où tous les coeurs sont identiques, mais je verrais très bien un multicoeur avec 1 coeur basse consommation et basse fréquence pour le standby, un coeur dédicacé pour le hardware, un coeur générique pour le GUI, et un coeur DSP pour les calculs.
Il faudrait recompiler les programmes pour que leurs différentes parties aillent sur le bon coeur, mais rien d'impossible. Et beaucoup d'économies d'énergies car si un centre de calcul consomme des MW, tous les ordinateurs d'un pays consomment bien d'avantage. De plus, les algorithmes DSP ont prouvé leur supériorité en terme d'efficacité pour tout ce qui est calcul depuis plusieurs décennies maintenant. Avec l'arrivée de ces processeurs hautement parallèles qui arrivent, c'est certainement une nouvelle page de l'informatique qui commence.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
# Et les tubes !
Posté par Domi . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 0.
Il ne faut pas oublier que la miniaturisation a commencé avec les tubes.
Le premier ordinateur de l'histoire fut réalisé avec des tubes, et même s'il occupait tout un immeuble ricain, c'était déjà de la miniaturisation.
Pour le comprendre, il suffit de comparer un orgue Hammond à tubes, lequel ne prend pas plus de place dans un salon qu'un piano, avec son ancêtre, le telharmonium et ses 200 tonnes : https://fr.wikipedia.org/wiki/Telharmonium
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
# maintenance à long terme
Posté par Domi . En réponse au journal Linux facile. Évalué à 0. Dernière modification le 26 janvier 2014 à 23:24.
Le monde des distributions est vaste, donc il est difficile de généraliser. Il existe cependant deux familles principales de distros, les binaires et les sources. Le problème des distributions binaires est le même que celui de windows, mais comme nous avons la chance d'avoir une gestion centralisée du système il est moins pire. Dans le cas d'un update mineur du système et si l'on a pas rajouté de dépôts distants, cela passe sans problème. Avec des dépôts distants, apt ou yast, etc. refusent de faire la mise à jour s'il y a un conflit de dépendances, ce qui est bien mieux que la gestion à la windows où la mise à jour est effectuée sans contrôle aucun des dépendances.
En cas d'update majeur du système, comme de passer d'OpenSuSE 8 à 9, cela se complique. Il y a généralement deux solutions: comme sous windows formater et tout réinstaller, ou passer des heures à régater sur les forums.
Avec les distributions sources, l'évolution est continue. Donc il n'y a jamais de saut de version. De plus, les dépendances sont ce qui est installé dans la machine, et en cas de problèmes de dépendances, le programme de gestion des logiciels les repère et il recompile ce qui doit l'être. Ce qui implique que ceux qui sont vraiment intéressé par une maintenance fluide sur le long terme devraient passer à une distribution source.
Il existe aussi des distributions comme Arch qui proposent une gestion des programmes à la FreeBSD. Il est alors possible d'installer le même programme depuis une archive binaire ou depuis ses sources.
Le problème de la maintenance à long terme d'une installation Linux est donc aussi lié au niveau de son administrateur. Si ce n'est pas impossible, il est difficile d'imaginer un mécanicien ou une employée de commerce ne connaissant pas Linux allez acheter un pc et commencer à installer gentoo. Donc il ou elle va installer Ubuntu ou Debian ou OpenSuSE, et au lieu de se plaindre devrait déjà s'estimer heureuse qu'avec la dizaine de dépôts distants rajouté en une semaine, apt ou yast refusent de lui casser son système.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
# licence et société
Posté par Domi . En réponse au journal La GPL est un échec (FreeBSD 10 est sorti). Évalué à 0. Dernière modification le 26 janvier 2014 à 21:44.
En tant que manager de deux projets open source, j'ai changé, après discussion avec les développeurs, la licence d'un des deux projets de GPL2 à GPL3. La raison pour moi de préférer la GPL à la BSD, et la GPL3 à la GPL2, est très simple: ces logiciels ont été fait bénévolement pendant leur temps libre par des développeurs, et si des sociétés privées veulent les utiliser dans leurs propres projets commerciaux, la moindre des choses qu'ils doivent faire est de contacter au préalable les développeurs concernés pour trouver un terrain d'entente.
De plus, ils peuvent dire ce qu'ils veulent chez BSD, la base d'utilisateurs de GNU/Linux est beaucoup plus importante que celle de BSD. Donc la licence est secondaire de ce point de vue. Si je connais des développeurs Linux qui sont en train de migrer sous d'autre systèmes, à commencer par FreeBSD, ce n'est pas en raison de
De plus, si des sociétés privées adoptent BSD, beaucoup d'administration préfère migrer de windows à Linux que de windows à BSD.
la licence mais parce qu'ils en ont marre de l'usine à gaz qu'est en train de devenir Linux. Et je partage leur avis.
Par contre je n'ai pas le choix. Beaucoup des softs qui m'intéressent (audio pro) n'existent pas sous FreeBSD, et j'ai essayé une fois d'en compiler un sous FreeBSD, échec total car si de nombreuses bibliothèques ont été portées sous FreeBSD, d'autres n'existent pas et leurs équivalences proposent d'autres API. Donc nécessiter de patcher les programmes pour que la compilation réussisse.
Et c'est bien ceci qui fait le succès de GNU/Linux: le grand choix de programmes disponibles. Et là, BSD ne peut pas régater. On en reparlera peut-être dans 5 ou 10 ans si suffisamment de développeurs Linux passent sous BSD, mais pour le moment, il y a beaucoup plus de programmes disponibles sous Linux que sous BSD, et donc beaucoup plus d'utilisateurs de Linux.
Pour moi, le problème de la licence est plus liée au type de société que nous voulons promouvoir qu'à des considérations techniques de savoir si tel ou tel programme à été porté sur telle ou telle licence. Si nous voulons continuer avec le capitalisme, la licence BSD est la voie à suivre. Si nous voulons nous diriger vers une société post capitaliste, la license GPL est la voie à suivre. Et vu les problèmes actuels liés au capitalisme comme la transformation systématique des ressources naturelles en sources de pollution et l'épuisement des ressources non renouvelables que ce mode de vie engendre, problèmes qui ne pourront être résolus que dans une société post capitaliste, je pense que la GPL est la voie à suivre. Ce qui fait que je préfère de toutes façons continuer avec GNU/Linux.
EDIT: Je rajouterais même que le modèle de développement du logiciel libre est la meilleure preuve qui sot qu'une alternative au capitalisme est possible, et qu'il n'est pas nécessaire d'attendre la fin du capitalisme pour la construire.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
# distribution
Posté par Domi . En réponse au message guide d'installation linux pour un débutant. Évalué à -1.
Les distributions que j'ai utilisée sont Suse, Debian, et Gentoo, plus quelques autres spécifiques à l'audio pro.
Dans les distributions génériques, je ne peux que te conseiller SuSE, ou openSuSE dans sa version gratuite, ainsi que Debian. Ubuntu, j'attends pour essayer que leur spyware soit débranché par défaut: http://www.zdnet.fr/actualites/ubuntu-contient-un-spyware-denonce-richard-stallman-39785246.htm Si je veux des spyware, j'utilise windows.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
# Et gnome dans tout ça
Posté par Domi . En réponse au message Les cgroups et systemd. Évalué à 1.
Il semble qu'il y ait encore un autre problème lié à systemd, c'est Gnome. La dernière version de Gnome a besoin de systemd pour que toutes ses fonctions soient disponibles. http://wiki.gentoo.org/wiki/GNOME/3.8-upgrade-guide#Systemd Ce qui laisse peu de choix pour une distribution binaire:
De toute façon, l'avenir nous dira si systemd va vraiment s'imposer ou s'il va finir comme Hal.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: Scheduler Temps reel
Posté par Domi . En réponse au message Les cgroups et systemd. Évalué à 1.
Et je rajouterais même que je connaît de nombreux développeurs, et pas des moindres pour certains, qui entre autre à cause de ce genre de problèmes, ont pris la décision de migrer sur d'autres systèmes, à commencer par FreeBSD, quand ce n'est pas déjà fait.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re:
Posté par Domi . En réponse au message Les cgroups et systemd. Évalué à 1.
Tout ce que je sais est que sans systemd, la même configuration des cgroups fonctionne parfaitement dans mon installation actuelle ainsi que dans la précédente, et que dans celle du milieu avec systemd, je me retrouvais avec des trucs que je n'ai pas configuré dans mon groupe temps réel. Et que comme ils n'étaient pas configurés, ce ne peut pas être cgroup-bin/libcgroup qui les y a mis.
De plus, comme ce groupe temps réel utilise le cgroup cpu et que systemd utilise aussi le groupe cpu, je ne vois pas quel programme autre que systemd pouvait mettre ces trucs dans mon groupe temps réel.
Maintenant, que j'ai vu passer un message d'apt-get me demandant d'activer systemd est une possibilité. Quand j'ai vu que systemd était installé, je ne le connaissais pas, et je n'avais à priori rien contre. Au début tout allait bien, c'est quand, après avoir installé mon kernel dans lequel j'ai viré toutes les options des cgroups sauf le groupe cpu et son séquenceur temps réel, j'ai installé et configuré cgroup-bin, que les problèmes ont commencé et que je me suis retrouvé avec un système qui passait son temps à se bloquer sans rémission possible.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: Scheduler Temps reel
Posté par Domi . En réponse au message Les cgroups et systemd. Évalué à 1. Dernière modification le 14 janvier 2014 à 15:16.
Le patch -rt, comme RT_GROUP_SCHED, apportent quelque chose en plus. Voir http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler?page=0
Avec JACK, les deux solutions me permettent d'obtenir une latence audio dans JACK aussi faible qu'une milliseconde, ce qui me permet d'avoir un système fiable dans tous les cas avec une latence comprise entre 10 et 20 ms. Un kernel standard ne permet de faire ça qu'avec RT_GROUP_SCHED.
Un autre article intéressant sur l'audio est celui-ci: http://lwn.net/Articles/339316/
Il montre pourquoi l'audio est un gros bordel sous GNU/Linux. Il montre aussi deux choses sur Lennart. D'abord c'est un mec plein de bonne volonté et qui s'investit beaucoup. Ensuite il a un ego disproportionné et quand sa solution n'est pas adoptée ou est critiquée, plutôt que d'accepter la critique et discuter de ce qui peut être changé, il se braque et traite ses interlocuteurs de "desktop haters". Ce qui clos la discussion.
Avec JACK, et une dizaine de lignes dans mon .asoundrc, j'interface JACK et les applications ALSA, ceci sans latence supplémentaire, et chaque application ALSA apparaît dans le graphe de connexion de qjackctl, j'obtiens à peu près la même chose qu'avec pulseaudio, mais avec une latence constance au lieu d'avoir une latence qui augmente au premier xrun dans pulseaudio, avec comme seule possibilité pour la faire redescendre de devoir stopper et redémarrer pulse. http://www.linuxmao.org/ALSA+Router+un+flux+ALSA+vers+JACK Quand je vois ça, je suis sur et certain que si la communauté audio pro avait été écoutée, au lieu de développer un système non professionnel comme pulseauedio, il aurait été possible, en construisant uniquement sur ALSA et JACK, d'obtenir la même chose, mais mieux car professionnel, et ceci vraisemblablement avec bien moins d'efforts que ceux qui ont été mis en oeuvre pour développer pulse, car toutes les briques de base existent.
Quand à systemd, selon plusieurs développeurs de la LAD (liste Linux Audio Development), même si certains d'entre eux l'utilisent, il est en train de devenir un plus grand problème que celui qu'il est censé résoudre, ceci pour la raison que systemd fourni des politiques de gestion du système au lieu de fournir les moyens de créer des politiques de gestion. Ce qui limite la liberté du choix des utilisateurs de créer leurs propres politiques de gestion du système. Et quand je parle de ce problème avec eux, les développeurs de systemd me répondent que Linux n'a jamais été une question de choix, ce qui clos toute discussion.
Je comprends très bien, étant moi-même manager de plusieurs projets, que la liberté de choix d'un développeur peut venir en conflit avec la liberté de choix des utilisateurs, mais j'estime aussi que cela fait partie du devoir d'un développeur, s'il casse quelque chose offert à ses utilisateurs, de proposer une nouvelle façon de le faire. Pour cela, je suis toujours très clair avec les nouveaux développeurs qui joignent mes projets: ils peuvent faire ce qu'ils veulent tant qu'ils ne cassent pas les fonctions existantes des programmes. Ils peuvent les modifier, mais les fonctionnalités présentes avant leurs modifications doivent continuer à exister.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: bullshit
Posté par Domi . En réponse au message Les cgroups et systemd. Évalué à 1.
Tu as raison, il n'est pour rien dans ce coup là. En fait c'est même lui qui avait signalé ce bug. Je vais éditer le premier message si c'est possible pour qu'il reflète ça.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: Scheduler Temps reel
Posté par Domi . En réponse au message Les cgroups et systemd. Évalué à 1. Dernière modification le 13 janvier 2014 à 21:04.
Mon cgroup temps réel fournit cpu.rt_runtime_us, ce qui est comparable au temps réel fourni par un kernel -rt, et qui n'est pas fourni avec le kernel standard de Debian. Pour l'avoir, j'ai du compilé mon propre kernel à partir des sources de celui de Debian. Donc nous ne devons pas parler du même temps réel. Je parle de CONFIG_RT_GROUP_SCHED, pas de SCHED_FIFO.
http://trac.jackaudio.org/wiki/Cgroups
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re:
Posté par Domi . En réponse au message Les cgroups et systemd. Évalué à 1.
Merci pour le lien. Voilà qui me donne une raison de plus d'aller discuter avec les devs des cgroups du kernel.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re:
Posté par Domi . En réponse au message Les cgroups et systemd. Évalué à 1.
Aucune, j'ai formaté et contrôlé le disque avant d'installer gentoo. Donc je n'ai aucun moyen de savoir pourquoi systemd avait été installé. Et de nouveau, je n'ai rien contre Debian qui est une excellente distribution, ce sujet est sur systemd et les cgroups.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re:
Posté par Domi . En réponse au message Les cgroups et systemd. Évalué à 1.
J'ai certainement du la lire à l'époque où j'ai installé ce Debian. Je me rappelle avoir tout essayé, ce qui ne veut pas dire que j'ai forcément fait tout juste, mais comme mon système passait son temps à se bloquer, et que personne n'a pu m'aider sur le forum de Debian, même pas avec un pointeur sur de la doc ou en me disant que je pouvais virer systemd et le remplacer par init, je suis rapidement passé à autre chose et j'ai reformaté et contrôlé le disque avant d'installer gentoo.
Ce n'est que hier en lisant le mail de Lennart que j'ai commencé à comprendre qu'une configuration des cgroups comme la mienne ne peut simplement pas fonctionner avec systemd dans l'état actuel des cgroups et de systemd. Je n'ai qu'un seul cgroup, un groupe cpu temps réel, et comme c'est le seul cgroup cpu, systemd voit que c'est un groupe cpu et il le pollue, ce qui tôt ou tard résulte en un blocage total du système.
De plus, en parallèle à cette discussion, j'en ai une avec les développeurs de systemd, et un d'entre eux m'a conseillé, comme j'ai une config custom des cgroups, de ne pas utiliser systemd. Ce qui me donne raison. Le stade suivant pour moi est d'aller voir les devs des cgroups du kernel car il m'a dit qu'ils sont en train de tout changer.
Quand aux choix de Debian, j'ai été surpris de la facilité pour virer *kit. Je ne dénigre absolument pas Debian, c'est une distribution qui a fait ses preuves et que j'avais déjà utilisée dans le passé avant gentoo. Il y a aussi eu Suse que j'ai utilisé pendant de nombreuses années avant Debian, plus un intermède gentoo au milieu de Debian. Donc pas mal d'années sous GNU/Linux (depuis mon 386) et sous différentes distributions. Il y en a eu encore d'autres comme Agnula et Demundi, basées sur Debian, pour ne citer que celles que j'ai réellement utilisées.
Autrement, j'ai aussi essayé AROS. Excellent système dont le bureau, même en tant qu'hôte linux, est beaucoup plus rapide que ceux de GNU/Linux. Malheureusement, il y a encore peu de logiciels disponibles.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re:
Posté par Domi . En réponse au message Les cgroups et systemd. Évalué à 1. Dernière modification le 13 janvier 2014 à 01:53.
Quoi qu'il en soit, quand j'ai installé Debian, systemd à été installé. De plus, j'ai installé gentoo ce qui a résolu mon problème (voir plus bas).
Le problème de systèmed avec les cgroups est qu'il installe, comme je l'ai compris en lisant ce qui dit Lennart dans l'article de linux.fr, j'ai aussi lu l'entier de ce qu'il dit sur gmane (le lien est dans l'article), le problème est que systemd implémente seulement un subset des cgroups qui correspond à l'option automatique du kernel, qu'il prend le contrôle des cgroups, et que contrairement au kernel associé avec libcgroup/cgroup-bin, systemd ne met aucune réelle possibilité de setup à disposition de l'utilisateur.
Ceci implique que n'importe quel utilisateur qui utilise autre chose que la configuration automatique des cgroups dans le kernel ne peut pas utiliser systemd. Donc, la communauté audio pro n'est sûrement pas la seule concernée par ce problème avec systemd.
La cause de ce problème est pour moi une fausse conception de ce que fait un utilisateur avec son pc. Pour moi, un pc ça sert à travailler. Pour le développeur en chef de systemd, comme il le dit très bien dans son mail sur gmane, un pc sert à faire tourner un GUI et toutes les autres utilisations ne sont pas relevantes.
Ce qui implique que pour résoudre ce problème, il faudrait revoir l'API de systemd pour qu'il supporte toutes les fonctions cgroups du kernel, ceci même en mode non automatique, et pour qu'un plus systemd soit capable de proposer un interface de configuration des cgroups à l'utilisateur.
Quand à mon gentoo, une partie de mes USE flags sont "-systemd -consolekit -policykit -pulseaudio -udisks -udisks2", donc un système léger sans tous ses machins superflus qui apportent plus de problèmes que de solutions. Je ne remet pas en cause l'idée de systemd, mais je constate simplement que son implémentation actuelle est contraire à l'esprit de GNU/Linux qui est d'offrir le choix aux utilisateurs. LEs cgroups du kernel, en conjonction avec libcgroup/cgroup-bin, permettent d'optimiser une machine donnée pour n'importe quelle sorte de charge de travail. Avec systemd, seule une configuration par défaut est proposée, et il n'y a aucune possibilité de sortir de cette configuration par défaut. De plus la documentation est quasi inexistante, ce qui est normal vu le peu de possibilités de configuration.
Lennart le dit lui même:
Ce qui implique que son implémentation des cgroups dans systemd est à moitié incomplète.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
# .sh et shebang
Posté par Domi . En réponse au message Problème d’exécution d'un script. Évalué à 1.
Pour moi, il y a une petite inconsistance. Le nom du fichier de ton script se termine en .sh, ce qui laisse supposer que le shebang de ton script est #!/bin/sh, alors qu'il est en réalité #!/bin/bash. Sous linux, le système utilise le shebang pour déterminer comment il va exécuter un script, donc le .sh est superflu, et dans ton cas, il peut porter à confusion.
Il faut aussi voir que bash et sh n'ont pas la même syntaxe. Par exemple, sh ne comprend ni "if [[…]]", ni les variables tableaux. Avec Debian, c'est pas grave car sh est un lien symbolique sur dash, lequel est compatible avec sh, mais dans de nombreuses autres distributions, sh est un lien symbolique vers bash. Avec ces dernières distributions, un script sh avec une syntaxe bash fonctionnera, mais le jour où tu le mettra sous Debian, il ne marchera pas.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: Yeap
Posté par Domi . En réponse au message Reconversion professionnelle vers le libre. Évalué à 1.
Je ne saurais mieux dire.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
# xdradio
Posté par Domi . En réponse au message Pas de son avec XdtV sur mon portable.. Évalué à 0.
J'utilise xdradio pour ça.
Il est simple à utiliser. Ces dépendances sont mplayer, mencoder et xdialog.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: Graphistes, musiciens et autres artistes
Posté par Domi . En réponse au sondage Achèteriez-vous un jeu libre ?. Évalué à -4.
Tu parles pour toi et tu généralises ton cas. J'aime pas ce genre de démarche. Pour preuve, je connait un musicien, David Rovics, c'est un gars très sympa, un auteur-compositeur-interprète qui vent sa musique. Mais il l'a aussi mise en téléchargement libre sur internet, ainsi que des vidéos et même les textes et les partitions. Lors d'une discussion, il m'a dit qu'il n'avait jamais autant vendu de disques que depuis qu'il a mit toute sa musique en téléchargement libre.
Tu pourras objecter que, vu le contenu des textes de ces chansons, pas beaucoup de radio doivent le passer. Et tu auras parfaitement raison. Mais il a su trouver, grâce à internet et aux nombreuses manifestations auxquelles il participe, le moyen de se faire de la pub. Et comme il a quelque chose à dire, ses textes et sa musique sont sa meilleure pub.
Nous parlons du libre ici. Les médias commerciaux ne parlent pas plus du libre qqu'ils ne parlent de David Rovics, ou alors ils nous parlent toujours des 2 mêmes programmes, généralement de linux (souvent sans même dire qu'il ne s'agit que du kernel) et parfois d'open office. Le libre a aussi su créer ses propres canaux pour se faire connaitre comme par exemple ce site. De plus, si ton code et tes graphismes sont bien, cela fera toujours bien sur ton cv.
Je suis aussi musicien, donc je sais que c'est beaucoup de travail. Cependant je ne suis pas pour autant dupe de la propagande des majors et des éditeurs. Avec l'informatique, la structure même de l'industrie de l'édition a changé. Avant, l'important était de posséder les moyens d'enregistrement et de duplication. Avec l'informatique, l'important est de posséder les droits sur les enregistrements et les oeuvres. Les moyens de production sont à la portée de n'importe qui a les moyens de se payer un bon instrument de musique.
C'est en fait une chance, les artistes peuvent ainsi s'émanciper des majors et des éditeurs pour devenir indépendants. Et ça, les majors l'ont bien compris mais, à part essayer de nous voler nos droits en faisant du lobbying pour changer la législation, elles ne peuvent rien faire contre cette évolution. Et même les nouvelles législations venues des States ne peuvent rien contre un artiste indépendant, bien au contraire, comme les anciennes lois, elles protègent ses droits sur ses oeuvres. Les musiciens ont été le premier à le comprendre, la preuve en est la multiplication des petits labels indépendants.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: Gestionnaire de fenêtre et toolkit
Posté par Domi . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 0.
Si tu lis la FAQ, le gestionnaire de fenêtre existe toujours, simplement, comme dans l'AmigaOS, il est incorporé dans le serveur d'affichage et le compositeur.
Si wayland est bien fait, il doit être possible de gagner beaucoup pour tout ce qui touche à l'affichage. Si je compare aeros (une version libre de l'AmigaOS qui peut être installée comme hôte linux ou en natif), le Gimp se lance 4 ou 5 fois plus rapidement sous aeros installé comme hôte sous linux que Gimp en natif linux dans la même machine. Ce qui ne change pas par contre sont les temps de traitement des filtres sur les images. Mais au niveau du lancement des applications et de la fluidité de X, la différence est impressionnante.
Donc, affaire à suivre. Je pense cependant que pour les applications wayland, cela devrait être rapide. Pour les applications X lancées sous wayland, c'est à voir. Quand à lancer X sous wayland, ce sera (d’après la FAQ) un petit peu plus lent.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: Gestionnaire de fenêtre et toolkit
Posté par Domi . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 0.
Mon premier pc décent était un Amiga. Dans l'AmigaOS, il n'y a qu'un seul toolkit qui est intégré dans le serveur graphique. Le toolkit de l'Amiga est l'équivalent de Xlib + toolkit xyz. De plus, une partie était intégré dans le kernel. Ce qui avait l'avantage de la simplicité et d'être rapide même sur un processeur qui ne tournait qu'à 8MHz et disposait que de quelques MB de ram. Le tout en couleur et sonorisé, basé sur un kernel préemptible multitâche. Le meilleur de mes ordis.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.