Journal Quelle distribution restera dans l'esprit UNIX?

Posté par fleny68 le 04 juin 2012 à 19:21.

Étiquettes :

juin

2012

L'esprit unix, sa simplicité basé sur un principe fort: des outils simples qui font peu de chose mais qui le font bien, qu'on fait interagir pour obtenir ce dont on a besoin avec souplesse.

Le nouvel esprit Linux: des outils inutilement complexes dont on ne peut plus obtenir sans se prendre la tête pour contourner leur limitation ce qu'on obtenait en une ligne dans un fichier de configuration précédemment.

Vous avez aimé PulseAudio, le truc qui remplaça ce qui marchait bien avant d'être au point? Vous avez aimé Policykit, le machin dont les fichiers de configurations ne sont pas sous /etc et dont il est impossible de comprendre à quel besoin ça répond? Vous aimez ConsoleKit, le truc qui gère les sessions (déjà obsolète, remplacé par un autre machin indispensable…)?

Vous allez adorer AccountService, le machin grâce auquel pour faire disparaitre un utilisateur de la fenêtre de connexion (lightdm), il est inutile de l'ajouter dans le fichier de conf à la bonne ligne. Dans AccountService ce n'est pas prévu de faire ça, alors ça ne marche plus (Il faut juste changer l'uid de l'utilisateur dans le fichier /etc/passwd, et repasser un "chown -R" sur son compte. Simple et logique, non?)

Vous l'aurez compris, j'ai enfin récupéré le clevo sous ubuntu que j'ai offert à ma douce, et je dois avouer que la simple gestion des comptes a commencé à me filer des boutons: le changement de mot de passe se bloque (heureusement qu'on peut le faire dans un terminal), mettre un compte administrateur non visible dans le fenêtre de connexion n'est pas prévu (et c'est pas un bug, c'est une fonctionnalité). Le wifi qui a besoin d'un petit coup de main pour marcher, ça me semble anecdotique à côté de l'évolution que je vois dans le système.

Vous avez pas fini de me voir râler contre cette évolution. Je suis peut-être un vieux con, mais les idiots qui pondent ces machins sont en train de supprimer le côté hackable de linux, et franchement, ça gonfle.

(ce journal aurait été parfait pour vendredi, mais chronopost n'a pas voulu).

# Vous avez dit Unix ?

Posté par Moulator le 04 juin 2012 à 19:31. Évalué à 10.

C'est un peu pour cela que je me tourne de plus en plus vers les BSD, au moins pour mes serveurs. Et je garde Linux (Debian - Insert your troll here) pour le desktop, tant que ça ne dégénère pas trop…

Reynald
- [^] # Re: Vous avez dit Unix ?
  
  Posté par MTux le 05 juin 2012 à 12:00. Évalué à 9.
  
  J'ai découvert OpenBSD récemment et je m'attendais à quelque chose d'ultra compliqué, après tout c'est pas du Linux et c'est fait par des gourous de la sécurité. Mais en fait c'est tout le contraire, c'est vraiment plus simple et plus logique que tout ce que j'ai vu sur Linux jusqu'ici. En deux mots : humainement compréhensible.
  - [^] # Re: Vous avez dit Unix ?
    
    Posté par Raoul Volfoni (site web personnel) le 05 juin 2012 à 12:14. Évalué à 6.
    
    Chuuuuut…. Ça devait rester top secret !
    - [^] # Re: Vous avez dit Unix ?
      
      Posté par tontonrico le 05 juin 2012 à 12:38. Évalué à 7.
      
      Oui, mais…
      
      *BSD est-il prêt pour le desktop ? :-)
      - [^] # Re: Vous avez dit Unix ?
        
        Posté par rakoo (site web personnel) le 05 juin 2012 à 16:42. Évalué à -1.
        
        De toute facon, *BSD est en train de mourir, donc c'est pas grave.
# Où est le problème ?

Posté par Renault (site web personnel) le 04 juin 2012 à 19:52. Évalué à 8.

Je trouve qu'il y a, parmi les adorateurs de Unix, un grand problèmes à admettre les défauts de ce modèle et la nécessité de changer un peu les basfonds du système.

La philosophie de Unix est robuste et POSIX a aidé à maintenir une certaine conférence entre les différentes interprétations de cette philosophie et de son implémentation.

Cependant, il ne faut pas perdre de vue que Unix a fêté ses 40 ans ce qui à l'échelle de l'informatique est considérablement vieux. Les rares survivants de cette époque (ou juste 30 ans en arrière) sont considérées comme des hacks affreux (x86, Windows) ou des outils de moins en moins utilisés.
Le système Unix n'était pas exempt de défauts et je pense que la volonté de ses créateurs de fonder son descendant plus moderne qu'est Plan 9 est un aboutissement de travail de recherches menés depuis la naissance de leur premier bébé.

Il est je pense néfaste de prétendre que les systèmes basés sur Unix sont parfaits et sont capables d'affronter le monde moderne sans améliorations. Il faut prendre en compte les dernières avancés et les nouveaux besoins d'aujourd'hui, c'est ce que font les outils que tu cites et qui ne sont pourtant pas gênants dans le cadre d'une utilisation serveur. De plus, cela fait longtemps que *BSD ou GNU/Linux ont changé des choses dans l'héritage de Unix car cela n'était pas top (système UTF-8 complet par exemple). Il faut savoir évoluer, tout comme admettre que le langage C peut être remplacé avantageusement par des langages plus modernes. Ce n'est pas forcément mal d'évoluer, la compatibilité ascendante peut être dangereuse (Windows et x86 en sont des exemples marquants !).

Donc oui à l'évolution même si ça casse un peu quelques trucs, mais jusqu'ici je ne trouve pas la fracture si douloureuse, administrer n'importe quelle distribution se fait globalement de la même façon et l'adaptation à *BSD n'est pas très longue non plus.
Le old school c'est cool, je le sais notamment car j'adore le langage C, mais il faut se rendre à l'évidence que ces technologies de l'époque ne sont plus adaptées totalement et ont des remplaçants (ou assistants) très intéressants dans de nombreuses situations.
- [^] # Re: Où est le problème ?
  
  Posté par Graveen le 04 juin 2012 à 20:19. Évalué à 10.
  
  Clairement, non. Là tu es a un niveau abstrait: en réthorique, c'est cool, on peut toujours faire admettre qu'il est bon d'évoluer, mais là où tu te positionnes sur des idées, il cite des faits…
  
  Le problème est que ses exemples obeissent non pas à un ensemble de règles cohérentes entre elles, mais à…. rien. C'est empirique (en tous cas ca semble), et donc ca part au casse pipe.
- [^] # Re: Où est le problème ?
  
  Posté par Kaane le 04 juin 2012 à 22:57. Évalué à 10.
  
  Je trouve qu'il y a, parmi les adorateurs de Unix, un grand problèmes à admettre les défauts de ce modèle et la nécessité de changer un peu les basfonds du système.
  
  La philosophie Unix n'est certes pas parfaite, mais elle reste à mon sens à ce jour la meilleure philosophie OS existante. Elle n'a d'ailleurs pour ainsi dire aucun concurrent. Elle repose sur deux principes :
  1) Tout est fichier (ou ce que vous voulez d'autre, ce n'est pas le point important. Le truc important c'est que chaque élément de l'OS peut être chainé avec chaque autre élément de l'OS pour peut qu'ils tournent dans le même ring)
  2) Un programme fait une chose unique et le fait bien.
  
  L'avantage de cette philosophie c'est qu'elle est simple et applicable partout. C'est aussi la seule philosophie OS existante au niveau générique. Non parceque la philosophie générique Windows, Mac OS X ou même VMS j'attend toujours qu'on me l'explique. Le seule truc qui s'en rapproche un peu c'est la philosophie gros système IBM - qui revient généralement à "On fout tout ce qu'on peut en base de données - Et dès qu'on peut on fait des opérations atomiques". C'est pas tout à fait la philosophie Unix, mais il y a quand même une ressemblance non ?
  
  Cependant, il ne faut pas perdre de vue que Unix a fêté ses 40 ans ce qui à l'échelle de l'informatique est considérablement vieux.
  
  C'est très très vieux même à l'échelle de l'informatique même. Mais c'est quand même nettement plus jeune que d'autres principes comme la logique booléenne par exemple. Il ne faut pas confondre la philosophie Unix et les différentes implémentations. Il ne viendrait à l'idée de personne de remttre au gout du jour un scheduler Xerox des années 70, mais même en étant au top du top on peut respecter la philosophie Unix. En fait généralement les gens qui ne respectent pas la philosophie Unix se retrouvent avec des problèmes graves d'atomicité, de synchronisation, de mise à jour etc. Ca ne veut pas dire que ces problèmes n'existent pas sous Unix, juste qu'ils sont souvent nettement plus simple à résoudre. Et ca ne veut pas dir enon plus que ces problèmes sont insolubles sous un système qui ne respecte pas la philosophie Unix, juste que c'est souvent pénalisant (d'ailleurs à ce propos j'admire Microsoft qui est capable de créer un système d'exploitation qui tient sur 2,5Go amis qui nécessite 4,2Go de mises à jour et qui est capable de se mettre à jour correctement sur des milliers de machines différentes. Ce doit être un problème fascinant à résoudre, mais je suis quand même content de ne pas l'avoir.)
  
  Il est je pense néfaste de prétendre que les systèmes basés sur Unix sont parfaits et sont capables d'affronter le monde moderne sans améliorations.
  
  Si encore il s'agissait d'améliorations… Est-ce que Pulse-audio améliore Linux ? Non, il ne touche pas au système. Améliorer Linux ca serait de documenter Alsa ou de le foutre dehors une bonne fois pour toute en codant un remplaçant valable techniquement et simple à utiliser. Est-ce que systemd améliore Linux ? Non il ne touche pas au fondamentaux du système, il permet juste de disposer d'une espèce de garbage collector qui va tuer les zombis laissés par une fermeture incorrecte d'un programme, au prix tout de même d'une pléthore d'outils et de pilotes kernel qui font que la moindre faille de sécurité dans DBus va impacter l'ensemble du système de façon globale.
  Et pourtant les améliorations possibles dans les distribs c'est pas ce qui manque : Les ACL active par défaut par exemple, ca devrait être la norme et non l'exception. Si ifconfig Linux doit vraiment mourrir, ca serait bien qu'il le fasse, parceque là il agonise depuis 1999 et ca commence à être un poil ridicule. Si UTF-8 doit être le sauveur du monde, on devrait peut-être se pencher un peu plus sur un FS capable de gérer proprement les noms de fichiers qui contiennent des caractères interdits. Si IPv6 doit remplacer IPv4, il va peut être falloir pondre quelques outils qui permettent de construire une machine en ::2 proprement, parceque la machine IPv6 qui choppe son adresse en DHCP et qui sort dans un tunnel v4 après un petit coup de NAT6 sur la gueule ca fait rigoler tout le monde etc.
  
  C'est pas les axes d'améliorations qui manquent, même en respectant à la lettre la philosophie Unix.
  
  c'est ce que font les outils que tu cites et qui ne sont pourtant pas gênants dans le cadre d'une utilisation serveur.
  
  Déjà ce que font les outils cités, ca pénalise une utilisation serveur. Quand on doit se frapper du policykit sauce Red Hat sur une RHEL pour obtenir un comportement qui n'est pas prévu à 100% par la maison mère on douille. Systemd ca me fait pas rire non plus et network-manager encore moins.
  Ensuite Les outils ne font que balayer la poussière sous le tapis. On a pas amélioré Alsa qui est toujours en pseudo-beta, alors on oblige tout le monde à passer par un programme en userland. On a toujours pas viré ifconfig, alors on masque tout ça derrière une nouvelle interface qui évite sogneusement toute modification trop sensibles de certains éléments, notamment en évitant à l'utilisateur de se prendre les pieds dans des règles firewall qui commencent sérieusement à déborder de ce qu'on peut attendre d'un firewall etc.
  - [^] # Re: Où est le problème ?
    
    Posté par CrEv (site web personnel) le 05 juin 2012 à 06:41. Évalué à 0.
    Non parceque la philosophie générique Mac OS X
    
    Parce qu'il n'y a pas un beau morceau d'unix dans la philosophie Mac OS X justement ?
    
    Pour le reste, pour alsa, pour systemd, pour le truc de log, etc. Y'a quand même un truc. C'est du libre. Donc les gens corrigent améliorent et développent ce qu'ils veulent. Tu veux que alsa reviennent au centre ? Tu veux qu'il soit amélioré ? Ben fait le. Quoi, certains ont voulu améliorer en oubliant l'existant ? C'est parfois la meilleur chose à faire. La mise en oeuvre n'a pas été simple, ok. On me souffle qu'il y a eu également pas mal de problèmes venant de l'intégration dans les distribs mais bon…
    Et pour les autres sujets, c'est quand même assez marrant que les distros (et pas juste redhat) suivent quand même. C'est bien que ça apporte quelque chose, non ?
    Ha oui, parfois ça s'éloigne du principe de base d'Unix. Mais est-ce réellement un problème ou est-ce juste du saytaimieuxavent ? Quand on voit que derrière lumberjack il y a entre autre le gars derrière rsyslog et qui écrit les specs de syslog, je me demande si c'est juste un gars qui c'est réveillé en se disant "bon, si on cassait du unix" ou s'il s'est dit "si on améliorait tout ça" ?
    
    En fait ce qui est malheureusement sidérant c'est la capacité à l'immobilisme tout ça parce que ça change des choses. Et d'ailleurs, plus que des fichiers, unix c'est aussi des pipes et la gestion des entrées standards, non ? Pour les logs, une critique qui revient c'est par exemple "ouai mais mon grep il va plus fonctionner". Ok, et si un outil greplog est fourni et fait ce qu'il faut ? Hop, tu as ton outil simple qui ne fait qu'une chose, qui peut se chainer comme tu le ferais avec grep. Et donc c'est plus unix quand même ?
    Ha oui, pour l'immobilisme : dommage, je croyais pourtant qu'une des forces du libre, de l'open source et de ces méthodes était justement une plus grande capacité à faire table rase du passé lorsque le besoin se fait sentir. Et mon ressenti c'est qu'il y a quand même du monde que ça intéresse systemd, pulesaudio, lumberjack, etc. N'en déplaise aux "puristes"
    
    Au fait :
    
    Quand on doit se frapper du policykit sauce Red Hat sur une RHEL pour obtenir un comportement qui n'est pas prévu à 100% par la maison mère on douille
    
    Où est réellement le problème ?
    - policykit ?
    - policykit sauce red hat ?
    - red hat ?
    - [^] # Re: Où est le problème ?
      
      Posté par ahuillet (site web personnel) le 05 juin 2012 à 07:59. Évalué à 2.
      
      Plus ça va, plus je me dis que le problème est Red Hat. Ils se comportent un peu comme le Microsoft du monde Linux, avec une attitude "on décide de ce qui est le standard et si t'es pas d'accord tu te débrouilles pour faire fonctionner les logiciels".
      Ça ne serait pas gênant s'ils n'avaient pas une telle influence dans les projets qui leur permet de faire avancer leurs objectifs de nature "politique".
      - [^] # Re: Où est le problème ?
        
        Posté par Renault (site web personnel) le 05 juin 2012 à 08:08. Évalué à 5.
        
        Comme de nombreuses distributions passent outres les propositions de Red-Hat (Slackware au hasard), je suppose que c'est possible de le faire sans faire de lourds sacrifices.
        
        Tout n'est question que de choix, d'autant que les mainteneurs de distributions ne suivent pas Red-Hat avec des regrets en général mais le font sciemment et volontier…
    - [^] # Re: Où est le problème ?
      
      Posté par madhatter (site web personnel) le 05 juin 2012 à 08:17. Évalué à 6.
      
      c'est la capacité à l'immobilisme tout ça parce que ça change des choses.
      
      C'est marrant cet amalgame. Ce que je comprends moi, c'est pas que le gars n'aime pas le changement, mais il n'aime pas comment ça change.
      
      Pour les logs, une critique qui revient c'est par exemple "ouai mais mon grep il va plus fonctionner". Ok, et si un outil greplog est fourni et fait ce qu'il faut ? Hop, tu as ton outil simple qui ne fait qu'une chose, qui peut se chainer comme tu le ferais avec grep. Et donc c'est plus unix quand même ?
      
      Ben non, c'est très bête. Avant on avait un outil, grep, qui était applicable partout. Là, on aura toujours un outil grep applicable partout, sauf… et dans ces cas là, il faudra utiliser un autre outil (continuons à l'appeler "greplog"), dont le nom (ie: la commande) et probablement la syntaxe, ne seront pas les mêmes et dont l'usage sera spécifique (unique), contrairement au grep "universel".
      
      There is no spoon...
      - [^] # Re: Où est le problème ?
        
        Posté par ckyl le 05 juin 2012 à 08:52. Évalué à 2.
        
        Ben non, c'est très bête. Avant on avait un outil, grep, qui était applicable partout. Là, on aura toujours un outil grep applicable partout, sauf… et dans ces cas là, il faudra utiliser un autre outil (continuons à l'appeler "greplog"), dont le nom (ie: la commande) et probablement la syntaxe, ne seront pas les mêmes et dont l'usage sera spécifique (unique), contrairement au grep "universel".
        
        Heu tu fais juste un outil qui te sort une représentation texte brute et après tu process comme tu veux le flux. Faut pas être con non plus…
        
        [^] # Re: Où est le problème ?
        
        Posté par madhatter (site web personnel) le 05 juin 2012 à 08:59. Évalué à 1.
        
        Oui, si c'est possible, pourquoi pas en effet. ;)
        
        There is no spoon...
        
        [^] # Re: Où est le problème ?
        
        Posté par CrEv (site web personnel) le 05 juin 2012 à 09:01. Évalué à 3.
        
        C'est pourtant bien ce que tu avais quoté :
        
        Hop, tu as ton outil simple qui ne fait qu'une chose, qui peut se chainer comme tu le ferais avec grep
      - [^] # Re: Où est le problème ?
        
        Posté par CrEv (site web personnel) le 05 juin 2012 à 08:58. Évalué à 1.
        
        Ben non, c'est très bête.
        
        Heu… C'est pas comme si c'était déjà largement le cas cette situation. Des "simili" grep il y en a des tas. Un exemple bidon git grep Et pourtant je vois pas trop les gens s'en plaindre pour dire "oué mais non, grep c'est plus mieux et c'était là avant !"
        
        contrairement au grep "universel".
        
        Qui pour le coup a des limitations, dont celle de ne pas pouvoir lire des fichiers formatés avec des informations qui ont un réel sens.
        
        C'est marrant cet amalgame. Ce que je comprends moi, c'est pas que le gars n'aime pas le changement, mais il n'aime pas comment ça change.
        
        Ben en tout cas lorsque je lis ça résonne plutôt comme "Unix say le bien il faut rien changer et ce que certains change c'est pas bien et ça sert à rien"
      - [^] # Re: Où est le problème ?
        
        Posté par CrEv (site web personnel) le 05 juin 2012 à 09:00. Évalué à 2.
        
        Ben non, c'est très bête. Avant on avait un outil, grep, qui était applicable partout.
        
        Mais d'ailleurs, c'est pas contraire à KISS ça ?
        C'est pas contraire à ce qui est énoncé dans le journal "des outils simples qui font peu de chose mais qui le font bien, qu'on fait interagir pour obtenir ce dont on a besoin avec souplesse"
        
        En quoi faire un greplog est contraire à ça ? On aurait justement un outil simple, qui fait peu de chose mais qui le fait bien, et qu'on fait interagir pour obtenir ce dont on a besoin avec souplesse. Genre greplog --level=error | grep plop. C'est pas Unix ça ?
        
        [^] # Re: Où est le problème ?
        
        Posté par madhatter (site web personnel) le 05 juin 2012 à 09:17. Évalué à 2.
        
        Ben, ce qui me gêne (enfin toutes proportions gardées hein, ça va pas m'empêcher de dormir non plus ;)), c'est que "greplog" ne servirait qu'à sortir les logs sous format texte. Certes, ça reste simple, mais ça fait un outil de plus, et hyper spécifique.
        
        Mais à bien y réfléchir, rajouter une fonctionnalité/option à grep, serait le complexifier et de toute façon, la-dite fonctionnalité ne serait valable que pour les logs.
        
        Donc oui, au final, l'idéal reste de pouvoir sortir les logs sous une forme exploitable avec les outils existants.
        Mais ne connaissant que très peu lumberjack, je ne sais pas dans quelle direction ils souhaitent évoluer et quels choix techniques ils feront.
        
        There is no spoon...
        
        [^] # Re: Où est le problème ?
        
        Posté par ckyl le 05 juin 2012 à 09:34. Évalué à 6.
        
        Quand tu fais une des choses suivantes:
        1. ls
        2. dmesg
        3. lire dans /proc/self/maps
        4. ps
        
        Tu ne penses pas que tu utilise un outil de plus hyper spécifique pour obtenir les infos dont tu as besoin sous forme textuelle ?
        
        Avoir une représentation interne structurée avec ou sans structure de données adaptées et pouvoir l'exporter/importer en texte c'est juste un fonctionnement normal.
        
        [^] # Re: Où est le problème ?
        
        Posté par zebra3 le 05 juin 2012 à 12:13. Évalué à 0.
        
        ça fait un outil de plus, et hyper spécifique.
        
        Justement, c'est pas exactement ce que dit la phisolophie UNIX : KISS = un programme par tâche ?
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
    - [^] # Re: Où est le problème ?
      
      Posté par Kaane le 05 juin 2012 à 10:47. Évalué à 10.
      
      Parce qu'il n'y a pas un beau morceau d'unix dans la philosophie Mac OS X justement
      
      Non, il y a une base Unix, mais la philosophie Unix elle est partie aux oubliettes. J'ai rien contre Cocoa ou Quartz, mais il faut reconnaitre que ca s'éloigne quand mêmepas mal du 'un outil qui fait une chose mais qui le fait bien'.
      
      Y'a quand même un truc. C'est du libre. Donc les gens corrigent améliorent et développent ce qu'ils veulent. Tu veux que alsa reviennent au centre ? Tu veux qu'il soit amélioré ? Ben fait le.
      
      Ben voyons. Oui si je n'aime pas un truc je peux coder un remplaçant. Par exemple si je n'aime pas DBus je peux recoder à moi tout seul la quasi totalité des applis gnomes et gnome lui même pour que ca marche comme je veux. Il ne faut pas confondre un programme pris à part et si on l'aime pas on le change, et des outils "systèmes" qui sont de plus en plus intégrés au sein de Linux au mépris total de la philosophie Unix. Si systemd devient la norme et que je n'en veut pas je n'aurais qu'à créer ma propre distrib, réécrire tous les inits et probablement patcher tous les daemons qui s'appuieront un peu trop dessus, et bien entendu me frapper moi-même le support et la maintenance.
      Pour pouvoir changer un truc si il ne me plait pas, il faut que ce truc repsecte la philosophie Unix, c'est à dire qu'il fasse une chose, qu'il le fasse bien et qu'il soit chainable avec les autres simplement. Parceque sinon il faut que je me frappe tous les tests de regression, toute l'intégration OS et toute la maintenance en parallèle du truc que j'ai remplacé.
      Même si j'avais les compétences pour défaire systemd d'une distrib (ce qui honnêtement est une hypothèse optimiste) il faudrait que je sois au moins dix et à plein temps pour suivre les évolutions du macrocosme Linux et ne pas être obsolète au bout de six mois.
      Et là j'aurais rien amélioré, j'aurai juste retiré une verrue qui me gène dans mon "vrai" métier et je pourrais commencer à bosser comme je le souhaite.
      
      On me souffle qu'il y a eu également pas mal de problèmes venant de l'intégration dans les distribs mais bon…
      
      C'est le problème des Lennarteries, elles partent sur tout un tas d'hypothèses de config et de configuration qui t'obligent à fermer la porte à tout un tas de possibilités. Si tu essayes de garder les options ouvertes alors il y a des effets de bords, et si tu te plainds Lennart lui-même t'envoie ballader en te disant que ta distrib a mal intégré son truc. Mais posons nous trente secondes et réfléchissons, c'est quand même impressionnant qu'un logiciel user-land qui ne fait "que" présenter un pseudo-device Alsa aux applis (c'est sa partie interaction avec les autres programmes) soit aussi complexe à intégrer. Il a fallu plus d'un an à Suse et Ubuntu pour le faire tomber en marche (et encore avec tout un tas de limitations). Il faut le nicer ras la gueule pour que le son soit écoutable, et il vaut mieux éviter de lui envoyer des flux fréquences distinctes ou encore de l'interfacer trop fort avec une boite MIDI hardware (clavier ou autre). Tout çà pour un truc qui coté appli est supposé être une version Alsa de esd ?
      
      Et pour les autres sujets, c'est quand même assez marrant que les distros (et pas juste redhat) suivent quand même. C'est bien que ça apporte quelque chose, non ?
      
      Bien sur que ca apporte quelque chose, du point de vue d'un mainteneur de distrib tout ce qui limite l'utilisateur et l'empêche de faire des choses exotiques est un plus. Network manager par exemple rend horriblement complexe tout un tas de configs routeurs (dont le fameux ::2) donc si tu veux faire un routeur IPv6 conforme soit tu t'auto pourri la vie, soit tu gicles network manager et tu perds la maintenance.
      Idem avec Alsa/Jack - tu veux faire du son à un niveau un poil élevé sur ta distrib ? Ben faut enlever Pulse Audio, et après tu es dans un cas "hors champs" et c'est plus le mainteneur du package Jack qui te répond pour t'aider à résoudre ton problème, c'est directement le service commercial qui t'explique gentillement que les configs qui ne passent pas par Pulse Audio ne sont pas prises en charge par le support.
      Quand tu utilise Linux professionnellement et que tu as besoin d'un support de pointe, ca devient donc impossible de continuer à faire sous Linux un truc qui marchait bien avant.
      
      En fait ce qui est malheureusement sidérant c'est la capacité à l'immobilisme tout ça parce que ça change des choses.
      
      C'est exactement ça. Je fais de l'immobilisme, en fait je boude. Je préfère passer mes clients en Windows/BSD plutôt que de continuer avec Linux juste parceque ils veulent changer des trucs. Je préfère réécrire tous mes scripts de backup, mes interfaces LDAP, coder des interractions token Kerberos et revoir l'ensemble de mes politiques de sauvegarde, juste parceque Linux il veut pas faire comme j'ai envie. Je fous quinze ans de compétences spécifique à la poubelle et je recommence à 0, juste parceque je n'aime pas le changement.
      
      Pour les logs, une critique qui revient c'est par exemple "ouai mais mon grep il va plus fonctionner". Ok, et si un outil greplog est fourni et fait ce qu'il faut ?
      
      Mais je veux pas un outil greplog, un outil taillog, un outil sedlog, un outil perllog etc. Je veux une sortie standard qui je peux chainer aux outils que j'ai déjà et que je connais déjà.
      Dans le cas de lumberjack je ne veux pas non plus :
      - de base de données - parceque des fois le système ne démarre pas comme il faut et que j'ai besoin de logguer ce que je peux même si les logiciels de base de données ne démarre pas.
      - de format de log XML - parceque des fois je loggue du XML, qui lui même peut contenir des éléments XML échappé, et que j'ai pas envie de me frapper des échappements d'échappement dans mes logs, et encore moins de parser le sous-xml après avoir parsé l'XML principal
      - de format texte obligatoire, parceque des fois je loggue des trames IP, des échanges Kerberos, des négo SIP ou IPSec et que j'ai besoin de pouvoir utiliser mes outils standards (tcpdump par exemple) pour comprendre d'ou vient le bug.
      
      Et mon ressenti c'est qu'il y a quand même du monde que ça intéresse systemd, pulesaudio, lumberjack, etc. N'en déplaise aux "puristes"
      
      Oui, et il y a des gens que ca interresse d'avoir un disque dur SSD de 800Go. Le jour ou le disque dur SSD de 800Go sera obligatoire pour bouter Linux, je ralerai aussi. Et tu me traitera probablement de puriste immobiliste et passéiste. Mais ca ne me touchera pas beaucoup non plus.
      - [^] # Re: Où est le problème ?
        
        Posté par CrEv (site web personnel) le 05 juin 2012 à 11:12. Évalué à 0.
        
        C'est le problème des Lennarteries, elles partent sur tout un tas d'hypothèses de config et de configuration
        
        Mais alors comment ont fait les distrib qui ont réussi à intégrer des trucs comme pulseaudio sans vrai problème ?
        
        Bien sur que ca apporte quelque chose, du point de vue d'un mainteneur de distrib tout ce qui limite l'utilisateur et l'empêche de faire des choses exotiques est un plus.
        
        C'est quand même marrant, c'est exactement l'opposé de PulseAudio. Pire que ça, en général ceux qui se plaignent disent que les fonctionnalités apportées ne servent à rien. Tiens, un journal qui montre justement certains intérêts de pulseaudio : https://linuxfr.org/users/yellowiscool/journaux/transferer-du-son-en-reseau-avec-pulseaudio-vlc-et-un-clavier-bepo
        
        Mais je veux pas un outil greplog, un outil taillog, un outil sedlog, un outil perllog etc. Je veux une sortie standard qui je peux chainer aux outils que j'ai déjà et que je connais déjà.
        
        Mais en quoi c'est opposable ? Si greplog te balance ce qu'il convient dans la sortie standard il est où le problème ? En fait vous êtes super fort pour ne pas lire ce point. Ce qui est écrit c'est justement qu'il n'y a qu'à écrire un greplog qui utilise les entrées/sorties standard et qu'on peut chainer, comme on le ferait avec grep ou autre.
        Et dans ce cas aucun problème pour le chainer avec les outils que tu connais déjà.
        
        de base de données - parceque des fois le système ne démarre pas comme il faut et que j'ai besoin de logguer ce que je peux même si les logiciels de base de données ne démarre pas.
        
        C'est vrai que je pense qu'ils ne vont jamais se poser cette question…
        
        de format de log XML
        
        cool tu les aura en json
        
        Et tu me traitera probablement de puriste immobiliste et passéiste
        
        Ben en l’occurrence j'ai l'impression que beaucoup ferment les yeux devant les problèmes des solutions actuelles parce qu'ils ne comprennent pas / ne maîtrisent pas / n'ont pas envie des solutions apportées.
        Ok, les solutions ne sont pas exemptes de problèmes, mais au moins certains cherchent à y remédier. Et malheureusement (ou heureusement) dans le libre c'est ceux qui codent qui décident au final. Alors oui il y a des cas où ça ne me plait pas non plus. Mais là on dirait que sous pretexte que ça ne respecte pas votre vision d'Unix c'est forcément de la merde en barre. Et lorsqu'on dit qu'au contraire il est possible de continuer à respecter la philo unix (par exemple faire un outil dédié, simple et ne faisant qu'une chose comme consulter les logs plutôt que de pervertir un autre) ça plait pas non plus, parce que c'est pas le grep standard. Donc à ce moment il est où le problème réellement ?
        
        [^] # Re: Où est le problème ?
        
        Posté par Kaane le 05 juin 2012 à 12:12. Évalué à 10.
        
        Mais alors comment ont fait les distrib qui ont réussi à intégrer des trucs comme pulseaudio sans vrai problème ?
        
        Tu veux dire Red Hat et Fedora ? Ben en fait Lennart travaille pour eux, c'est pour ça.
        
        C'est quand même marrant, c'est exactement l'opposé de PulseAudio. Pire que ça, en général ceux qui se plaignent disent que les fonctionnalités apportées ne servent à rien.
        
        Non ce n'est pas l'opposé de Pulse Audio. Pour les applis (ie pour les autres programmes qui tournent) Pulse Audio est supposé simplifier la connexion audio. Après qu'il fasse autre chose en aval c'est son problème.
        
        En ce qui concerne les fonctionnalités qui ne servent à rien, c'est plus généralement des fonctionnalités qui existaient déjà avant.
        
        Tiens, un journal qui montre justement certains intérêts de pulseaudio : https://linuxfr.org/users/yellowiscool/journaux/transferer-du-son-en-reseau-avec-pulseaudio-vlc-et-un-clavier-bepo
        
        C'est fantastique comme solution \o/ Pulse Audio est encore compatible avec netcat. Je pense que ca sera corrigé dans une version ultérieure mais pour l'instant c'est le top.
        Donc si je résume je créé une interface pulse audio en local, je la streame en local, je renvois le stream dans un netcat et de là je renvoie sur une machine distante avec une autre interface pulse audio. C'est comme d'envoyer le son directement dans un netcat vers un dsp d'une machine distante sauf que l'on est limité en fréquence et en précision à 44100hz/16bits. Merci de m'ouvrir les yeux sur ce formidable outil.
        
        Mais en quoi c'est opposable ? Si greplog te balance ce qu'il convient dans la sortie standard il est où le problème ?
        
        greplog ne peut pas balancer ce qui me convient, parcequ'il n'est pas sentient. Des fois ce qui me convient c'est de passer le log dans du tcpdump, des fois c'est de grepper, des fois c'est de faire un tail -f, des fois c'est de passer par un parser XML, des fois c'est même de rediriger le log vers un tty. A la limite un catlog qui serait capable de gérer parfaitement le binaire ca se discute, mais pourquoi rajouter une étape de plus (que je paye cher en plus, vu que tous les tags XML vont partir à la poubelle à l'analyse mais seront bien présent sur mon disque dur niveau espace pris).
        
        C'est vrai que je pense qu'ils ne vont jamais se poser cette question…
        
        Oh, et je sais même comment ils vont y répondre, on aura une base de donnée linké en statique. En cas de faille la mise à jour se fera de façon assez complexe pour ne pas perdre d'info. Et bien sur pour exporter les logs pour analyse après attaque on aura pleins de petits outils très utiles (eux aussi linké en statique forcément). Bref d'un fichier texte ou binaire brut on va passer à même pas 20 outils linkés en statique et dont la mise à jour nécessitera quelques pirouettes. J'ai hate.
        
        cool tu les aura en json
        
        J'ai hate de désérialiser à la main du json issu automatiquement du XML d'un programme qui buggue.
        
        Ben en l’occurrence j'ai l'impression que beaucoup ferment les yeux devant les problèmes des solutions actuelles parce qu'ils ne comprennent pas / ne maîtrisent pas
        
        Là on est complètement d'accord. Beaucoup de gens ne comprennent pas les problèmes liés aux solutions apportées.
        
        Mais là on dirait que sous pretexte que ça ne respecte pas votre vision d'Unix
        
        C'est pas 'notre' vision d'Unix. C'est la philosophie Unix. Ca fait 40 ans qu'on la pratique elle commence à être plutôt normée et objective comme vision. Et en face on a la vision très personnelle Lennart/Red Hat qui pour le coup est complètement subjective. Donc oui je préfère largement une méthode éprouvée objective et bien comprise du reste du monde à la prolinuxitude selective de Lennart.
        
        Et lorsqu'on dit qu'au contraire il est possible de continuer à respecter la philo unix (par exemple faire un outil dédié, simple et ne faisant qu'une chose comme consulter les logs plutôt que de pervertir un autre)
        
        greplog ne serait pas un outil qui respecterait la philosophie Unix. Ce serait un outil qui ne serait pas chainable en amont vu qu'il ne pourrait traiter QUE les logs lumberjack. Donc j'en veux pas. Je veux pouvoir utiliser les outils standards, les scripts, les redirections sur mes logs, comme je l'ai toujours fait mais surtout comme j'ai besoin de le faire.
        Et de plus greper un log ce n'est pas une perversion de grep, il est même fait pour ça (prendre un fichier en entrée et le passer à la moulinette). Même si le fichier en question c'est le flux pulse audio dans netcat dont on parlait plus haut.
        
        [^] # Re: Où est le problème ?
        
        Posté par zebra3 le 05 juin 2012 à 12:16. Évalué à 2.
        
        Mais alors comment ont fait les distrib qui ont réussi à intégrer des trucs comme pulseaudio sans vrai problème ?
        
        Tu veux dire Red Hat et Fedora ? Ben en fait Lennart travaille pour eux, c'est pour ça.
        
        Non, il veut dire ce qu'il dit : les distrib qui fournissent un PA fonctionnel. S'il avait voulu dire RH et Fedora, il l'aurait dit.
        
        Parce que des distribs comme ça, il y en a : Suse, Debian, Mageia/Mandriva, Gentoo, etc.
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: Où est le problème ?
        
        Posté par CrEv (site web personnel) le 05 juin 2012 à 14:07. Évalué à -2.
        
        Tu veux dire Red Hat et Fedora ?
        
        Et non. Comme précisé plus bas je ne voulais pas dire RedHat et Fedora mais "les distrib qui ont réussi à intégrer des trucs comme pulseaudio sans vrai problème".
        
        C'est quand même marrant, c'est exactement l'opposé de PulseAudio. Pire que ça, en général ceux qui se plaignent disent que les fonctionnalités apportées ne servent à rien.
        
        Non ce n'est pas l'opposé de Pulse Audio. Pour les applis (ie pour les autres programmes qui tournent) Pulse Audio est supposé simplifier la connexion audio. Après qu'il fasse autre chose en aval c'est son problème.
        
        Heu, là tu te gaufre. Qu'il fasse quelque chose d'autre en aval c'est justement l'intérêt de PulseAudio. Et c'est bien exactement l'opposé de ce que tu disais.
        Je rappel que ce que tu as dis c'est : ce qui limite l'utilisateur et l'empêche de faire des choses exotiques On parle donc bien de l'utilisateur, pas simplement des autres programmes qui tournent. Alors après que les ajouts et améliorations ne t'intéressent pas spécialement en fait on s'en fiche un peu, le fait est que ça intéresse suffisamment de monde et que ça règle suffisamment de problèmes pour que toutes les distrib ou presque utilisent PA.
        
        Si greplog te balance ce qu'il convient dans la sortie standard il est où le problème ?
        
        greplog ne peut pas balancer ce qui me convient, parcequ'il n'est pas sentient
        
        Sentient ?
        Nan mais tu fais quand même exprès.
        
        Des fois ce qui me convient c'est […] des fois c'est […]
        
        Ok, mais dans ce cas il n'y a rien qui conviennent vraiment. Et avoir un outil unique pour faire tous ces cas différent c'est justement l'inverse d'un outil pour une action donnée le tout chainable.
        
        Oh, et je sais même comment ils vont y répondre
        
        Rien que ça. Tu as regardé pour de vrai ou tu es juste intimement persuadé que c'est le cas. Et si c'est la deuxième solution j'espère que tu es allé leur dire, non ?
        
        C'est pas 'notre' vision d'Unix. C'est la philosophie Unix. Ca fait 40 ans qu'on la pratique elle commence à être plutôt normée et objective comme vision
        
        Et ben faut croire que c'est pas si clair que ça.
        Si on prend par exemple le fait que le créateur de rsyslog bosse sur lumberjack, y'a quand même de quoi se poser des questions, non ?
        
        Je veux pouvoir utiliser […] comme je l'ai toujours fait mais surtout comme j'ai besoin de le faire.
        
        Ok, c'est donc bien exactement ce que je dis. Mais dans ce cas, si tout est déjà bien, pourquoi tu veux changer ? Ne met pas à jour, passe les correctifs de sécurité, choisi une distrib en accord avec ta philosophie.
        
        Et de plus greper un log ce n'est pas une perversion de grep, il est même fait pour ça
        
        Non non, comme tu dis, il n'est pas fait pour greper un log il est fait pour greper un contenu texte.
        Et donc si tu as un catlog qui te sort juste les messages de log alors ton grep fonctionnera toujours.
        Et si tu fais un greplog qui t'extrait des choses en fonction de données inexistantes dans tes logs, tu pourra toujours rajouter un grep derrière.
        Le truc dans l'histoire c'est que tu oublie totalement la structuration des données du log. Et ça, désolé, mais c'est une vrai fonctionnalité manquante. Le fait que chaque application ait sa propre structure de log est également un vrai problème qu'ils tente de résoudre.
        Mais non, c'est pas des vrai problèmes, c'est vrai. Et c'est pas unix. Au fait, tu confondrais pas unix avec bordel bas niveau ?
        
        [^] # Re: Où est le problème ?
        
        Posté par Batchyx le 05 juin 2012 à 23:34. Évalué à 2.
        
        Et ben faut croire que c'est pas si clair que ça.
        Si on prend par exemple le fait que le créateur de rsyslog bosse sur lumberjack, y'a quand même de quoi se poser des questions, non ?
        
        Je compterai pas la dessus. Déjà, j'ai un peu du mal à considérer rsyslog comme une référence. En 2012, un logiciel qui perd des logs, qui change l'ordre des lignes ou qui les dupliques, moi ça me fait peur (surtout pour le peu que je voulait faire !). Parce que la différence entre un bon logiciel et un mauvais logiciel, on ne la voit que quand le logiciel marche pas.
        
        Et franchement, laisser une personne décider ce que doit être un système de log, laisse moi rire. Un programmeur n'attend pas la même chose d'un système de log qu'un admin ou un utilisateur. Dire qu'on va résoudre "le problème" (et oui il n'y en à forcement qu'un) de tout le monde avec la magie des logs structurés, c'est comme dire qu'on va résoudre tout les problèmes de Linux avec une distribution unique.
        
        [^] # Re: Où est le problème ?
        
        Posté par ckyl le 06 juin 2012 à 10:42. Évalué à 5.
        
        Et franchement, laisser une personne décider ce que doit être un système de log, laisse moi rire.
        
        C'est quoi ce FUD ? Il n'y a pas une personne qui décide, c'est un processus ouvert et tu es libre de contribuer. Pour le protocole syslog, ca a pris 6 ans pour arriver à la RFC finale. Rainer en a simplement été l'auteur. Je peux te dire qu'il est compétent, pro et ouvert, c'est un bon auteur de RFC. Comme dans tout groupe de travail de l'IETF tout ce dont tu as besoin pour contribuer c'est d'une adresse mail; et corrige moi si je me trompe, mais la tienne n'est pas apparue sur la liste du WG.
        
        Maintenant pour lumberjack, on en est pas encore à ce stade, mais tu peux être sur que si tu veux contribuer et que tu as des choses constructives à dire, elles seront lues et entendues. Tu peux aussi jouer avec les protos, ou écrire une implémentation des idées & draft, ca permet d'avoir un très bon feedback.
        
        Si le sujet t'intéresse et que tu peux aller plus loin que le ranting, il faut aller défendre tes idées !
        
        Un programmeur n'attend pas la même chose d'un système de log qu'un admin ou un utilisateur. Dire qu'on va résoudre "le problème" (et oui il n'y en à forcement qu'un) de tout le monde avec la magie des logs structurés, c'est comme dire qu'on va résoudre tout les problèmes de Linux avec une distribution unique.
        
        Tu déformerais pas un peu l'histoire à ta sauce ?
        
        [^] # Re: Où est le problème ?
        
        Posté par Batchyx le 06 juin 2012 à 23:03. Évalué à 2.
        
        C'est quoi ce FUD ? Il n'y a pas une personne qui décide, c'est un processus ouvert et tu es libre de contribuer. Pour le protocole syslog, ca a pris 6 ans pour arriver à la RFC finale. Rainer en a simplement été l'auteur. Je peux te dire qu'il est compétent, pro et ouvert, c'est un bon auteur de RFC. Comme dans tout groupe de travail de l'IETF tout ce dont tu as besoin pour contribuer c'est d'une adresse mail; et corrige moi si je me trompe, mais la tienne n'est pas apparue sur la liste du WG.
        
        Sauf que je parle pas de RFC mais d'implémentations. Ça serait pas le premier à savoir faire des RFC géniales mais à ne pas savoir faire une implémentation qui tienne la route.
        
        La seule chose qui pourrai m'intéresser (et sur lequel je peut contribuer), c'est du code. Parce que faire des bonnes implémentations de standards pourris qui se contredisent, je suis presque payé pour ça. Mais pour ça il me faut un standard.
        
        Mais là, ce qui m'importe le plus, c'est comment ça va s'intégrer dans ma distrib. Si c'est encore du "il n'y a qu'une implémentation, pourquoi tu voudrai en changer ?" comme c'est trop souvent la mode en ce moment, alors là je vais commencer à râler, surtout si des patches intéressants (que ça soit les miens ou pas) sont refusés.
        
        Tu déformerais pas un peu l'histoire à ta sauce ?
        
        Il y a une part d'ironie dans cette partie. Quoi que, parfois je me demande si ça n'est pas un peu vrai.
        
        [^] # Re: Où est le problème ?
        
        Posté par Kaane le 06 juin 2012 à 02:15. Évalué à 6.
        
        Et non. Comme précisé plus bas je ne voulais pas dire RedHat et Fedora mais "les distrib qui ont réussi à intégrer des trucs comme pulseaudio sans vrai problème".
        
        C'est à dire ni Ubuntu (gros gros soucis, c'est eux que Lennart donne econre comme le mauvais example), ni Debian (18 mois pour être accepté), ni mandriva (moribonde à l'époque c'est vrai), ni suse (crash en pagaille, et pourtant ce sont eux les créateurs d'alsa), ni Slackware (qui n'en veut pas). On va dire que CentOS ne compte pas et que Gentoo ne l'a pas vraiment intégré en tant que tel mais que c'est liè au format même de la distrib.
        
        Il reste qui ? Quelle distrib a intégré PulseAudio sans gros soucis ?
        
        Je rappel que ce que tu as dis c'est : ce qui limite l'utilisateur et l'empêche de faire des choses exotiques On parle donc bien de l'utilisateur, pas simplement des autres programmes qui tournent.
        
        Oui PA limite l'utilisateur et l'empêche de faire des choses exotiques. Maintenant ca lui permet à la place d'en faire d'autre. Par exemple on ne peut plus faire d emixage hard ou de mixage sources croisées ou trop différentes, mais on peut renvoyer le son sur son oreillette bluetooth. One ne peut plus faire de temps réel mou ou de synchro jack aux petits oignons, mais on peut créer un tunnel réseau qui prend même pas 50% de CPU. On ne peut plus greffer un plugin ladspa générique à tous les périphs entrant MIDI et écouter le résultat en temps réel en 5.1, mais on peut créer un filtre ladspa gstreamer sur une appli donnée avec même pas 40ms de latence.
        
        Alors après que les ajouts et améliorations ne t'intéressent pas spécialement en fait on s'en fiche un peu, le fait est que ça intéresse suffisamment de monde et que ça règle suffisamment de problèmes pour que toutes les distrib ou presque utilisent PA.
        
        Je suis entièrement d'accord, c'est d'ailleurs pour ça que je me bats tous les jours pour le retour d'IE 5.5 - Parceque ca résolvait suffisament de problème et que ca interressait suffisament de monde pour que tous les sites web ou presque soient compatibles exclusivement IE 5.5
        
        Ok, mais dans ce cas il n'y a rien qui conviennent vraiment. Et avoir un outil unique pour faire tous ces cas différent c'est justement l'inverse d'un outil pour une action donnée le tout chainable.
        
        C'est à se demander qui le fait exprès. Quand j'ai un format générique de log qui respecte la philosophie Unix je peux utiliser TOUS les outils et TOUS les devices qui respectent cette philosophie pour arriver au résultat.
        
        Par exemple je peux faire tcpdump -F /mon/fichier/log ou encore tar -cvf backup.tar log1 log2 log3 ou encore des jointures compliquées entre plusieurs fichiers avec des ID de forensic (CF mod_log_forensic apache).
        Si lumberjack ne respecte pas la philo Unix, il y aura forcément des opérations que je ne pourrais plus faire, des effets de bord, des collisions. Donc j'en veux pas.
        
        _Rien que ça. Tu as regardé pour de vrai ou tu es juste intimement persuadé que c'est le cas. _
        
        J'invente c'est plus simple. Sans rire, tu n'as pas légèrement l'impression que je me suis documenté sur Lumberjack un minimum ? Non ?
        
        Si on prend par exemple le fait que le créateur de rsyslog bosse sur lumberjack, y'a quand même de quoi se poser des questions, non ?
        
        Non. Ca serait l'inventeur du système de log, ou d'un format de log particulièrement pointu je ne dis pas. Mais rsyslog malgré toutes ses qualités est une amélioration dans la continuité, Lumberjack est une rupture.
        
        Non non, comme tu dis, il n'est pas fait pour greper un log il est fait pour greper un contenu texte.
        
        Il est fait pour grepper un fichier. Et comme tout est fichier dans Unix… Tu peux lui faire grepper un socket si tu veux, perso je le fait même assez régulièrement. grep toto /dev/urandom ca marche….
        
        Et donc si tu as un catlog qui te sort juste les messages de log alors ton grep fonctionnera toujours.
        
        Déjà cat sert à concatener, si c'est pour un seul fichier on utilise autre chose normalement et ensuite même si j'avais un
        Le truc dans l'histoire c'est que tu oublie totalement la structuration des données du log. Et ça, désolé, mais c'est une vrai fonctionnalité manquante.
        
        Je ne l'oublei pas, je le trouve ridicule. Des appli différentes qui font des choses différentes avec des informations dfférentes et des buts différents ne peuvent pas toutes avoir le même format de log. On est juste en train d'ajouter un peu d'enrobage (que personnellement j'ai déjà en ce qui concerne le timestamp et la machine émétrice) à des données qui ne sont pas réconciliables. Le même format de log pour les connexions HTTP, les dump TCP, les traitement d'images et les vectorisations GCGPU ? Même pas en rève. On va juste mettre un emballage autour de l'info qui m'interresse. Emballage qu'il me faudra défaire à chaque fois.
        
        Et c'est pas unix. Au fait, tu confondrais pas unix avec bordel bas niveau ?
        
        La liberté c'est l'esclavage, l'ordre dans les règles Unix c'est le bordel bas niveau. La réthorique à 2cents c'est ici.
        
        [^] # Re: Où est le problème ?
        
        Posté par NumOpen le 10 juin 2012 à 11:14. Évalué à -1. Dernière modification le 10 juin 2012 à 11:15.
        
        40 ms de latence!!!! Avec DirectShow de Windows, on a moins de 4 ms de latence en utilisant un casque et un micro USB, ce qui permet par exemple d'utiliser des logiciels comme http://www.speedlingua.com ou de modifier en temps réel le son du karaoké ou de ce qu'on joue à la guitare.
      - [^] # Re: Où est le problème ?
        
        Posté par Adrien le 05 juin 2012 à 11:30. Évalué à 1.
        
        Par exemple si je n'aime pas DBus je peux recoder à moi tout seul la quasi totalité des applis gnomes et gnome lui même pour que ca marche comme je veux. Il ne faut pas confondre un programme pris à part et si on l'aime pas on le change, et des outils "systèmes" qui sont de plus en plus intégrés au sein de Linux au mépris total de la philosophie Unix
        
        Si j'ai bien compris, les développeurs ont choisit d'utiliser D-Bus (sans doute parce que ça doit avoir des avantages) et tu les critiques sur ce point. On te réplique « vas-y code ton truc », et tu réponds « oui mais non il y a trop de truc, il faudrait que tous les dev suive mon idée et arrête d'utiliser D-BUS ».
        
        Tu est qui pour vouloir leur imposer TES choix de développement ? Peut-être que D-BUS leur apporte quelque chose non ?
        
        Et si tu ne veux vraiment pas voir D-Bus, n'utilise pas de logiciel basé dessus… Ma remarque vaut aussi pour la libc ou linux.
        
        [^] # Re: Où est le problème ?
        
        Posté par Batchyx le 06 juin 2012 à 00:13. Évalué à 6.
        
        Il n'y à rien de choquant à ne pas vouloir utiliser D-Bus. Il n'y à rien de choquant qu'une application ait besoin de RPC. Il n'y a rien de choquant que l'application se repose sur du code externe pour faire des RPC.
        
        C'est lorsqu'on commence à mélanger "fonctionnalité" et "logiciel" que les problèmes commencent. Moi en tant que programmeur, j'ai envie de faire des RPC entre mes applis ou d'autres applis peu importe si ça passe par D-Bus, par du socket Unix/TCP ou par du morse sur SIGUSR1. J'ai envie de faire du RPC extensible ou l'utilisateur peut choisir d'utiliser du bidule lourdingue, du TCP vers l'autre bout de la planète, du pigeon voyageur ou de l'échange de disquettes, ou alors d'utiliser le super système révolutionnaire qui n'existe pas encore.
        
        Sauf que D-Bus, c'est du genre "pourquoi tu voudrai utiliser autre chose ?", et donc c'est une interface bien compliqué pour ce que ça fait, et tu ne pourra jamais réimplementer une RPC se faisant passer pour D-Bus sans que ça soit aussi lourdingue que D-Bus.
        
        Et oui, c'est choquant, parce que à un moment donné, on se rendra peut-être compte que D-Bus c'est de la merde en barre, de la même manière qu'on s'est rendu compte que ext2 est de la merde en barre. Sauf que pour ext2, Il n'y a pas eu besoin de recoder toutes les applis pour changer de système de fichier. Alors que pour D-Bus c'est juste très loin d'être le cas.
        
        [^] # Re: Où est le problème ?
        
        Posté par ahuillet (site web personnel) le 07 juin 2012 à 10:10. Évalué à 1.
        
        Pedantic---
        Attention, SIGUSR1 n'est pas un signal temps réel, tu ne peux pas faire du morse avec. Il faut SIGRTMIN + x pour cela. (Je n'ai jamais essayé le morse cela dit, en local je préfère mkfifo).
        ---Pedantic
      - [^] # Re: Où est le problème ?
        
        Posté par Frank-N-Furter le 05 juin 2012 à 12:13. Évalué à 0.
        
        Non, il y a une base Unix, mais la philosophie Unix elle est partie aux oubliettes. J'ai rien contre Cocoa ou Quartz, mais il faut reconnaitre que ca s'éloigne quand mêmepas mal du 'un outil qui fait une chose mais qui le fait bien'.
        
        ??? En quoi?
        
        Et sinon je peux booter un mac sans lancer Quartz Compositor, et lancer X11 a la place.
        
        1 # 2 # @(#)ttys 5.2 (Berkeley) 6/10/93 3 # 4 # name getty type status comments 5 # 6 # To secure single-user mode, enable Firmware password protection. 7 # http://docs.info.apple.com/article.html?artnum=106482 8 # 9 #console "/usr/libexec/getty std.57600" vt100 on secure 10 console "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow" vt100 on secure onoption="/usr/libexec/getty std.9600" 11 #tahoe's only 12 #remote "/usr/libexec/getty std.1200" pt on # diagnostics 13 14 # The tty.serial entry initializes the serial port (if any) for use as a 15 # terminal (enabling logons over serial). If marked secure, the serial 16 # port will allow root logons. 17 # To make the serial port available for outbound 18 # communications, the tty.serial entry should be turned off 19 # (set the 4th field to off). 20 tty.serial "/usr/libexec/getty serial.57600" vt100 off secure 21 22 # Fax reception is off by default, use the /private/etc/ttys format=unix type=CONF x=2 y=1 4% 05/06/12 -12:04
        
        Depending on the time of day, the French go either way.
  - [^] # Re: Où est le problème ?
    
    Posté par Misc (site web personnel) le 05 juin 2012 à 07:02. Évalué à 5.
    
    C'est pas les axes d'améliorations qui manquent, même en respectant à la lettre la philosophie Unix.
    
    En effet, ce qui manque, c'est les gens qui codent. Hint, un rant sur Linuxfr, c'est pas du code.
  - [^] # Re: Où est le problème ?
    
    Posté par suJeSelS le 05 juin 2012 à 08:44. Évalué à 2.
    
    Tout dépend de ce qu'on définit comme OS, j'ai plus l'impression qu'avec le temps, la définition a évolué pour inclure les parties IHM "haut niveau", qui pour ma part sont une strate logicielle hors OS. Vous supprimez Gnome, pulseaudio et autres gadgets, vous vous retrouvez avec un Unix relativement conventionnel.
    - [^] # Re: Où est le problème ?
      
      Posté par briaeros007 le 05 juin 2012 à 19:40. Évalué à 4.
      
      sauf que systemd/lumberjack, ca s'amuse a mélanger les deux couches en même temps.
      
      Network manager idem, et pulse audio un peu quand même (ca touche au matis son)
      
      Moi ce qui me fait marrer, c'est tous les gens qui disent "non mais c'est trop bien vous êtes tous que des vieux c*n d'immobiliste".
      
      Formation chez redhat, sur la partie redhat, la première chose qu'il nous a dis "bon on s'occupe de serveurs donc on désactive network manager. NM c'est très bien pour les portables , mais c'est une plaie pour les serveurs.
      
      Je présume que redhat est immobiliste aussi ? (par contre j'ai toujours pas compris pourquoi l'intégrer de base sur les distrib serveurs si la best practice c'est de le virer en serveur…
      Ca doit être pour faire plaisir aux kikoolol)
      - [^] # Re: Où est le problème ?
        
        Posté par ckyl le 05 juin 2012 à 20:12. Évalué à 2.
        
        Mais où tu as vu quelqu'un dire que NM, pulseaudio ou autre c'était bien pour les serveurs ? Personne ne recommande d'utiliser ces trucs pour des serveurs, même pas la doc de redhat. Faut arrêter de fantasmer.
        
        Par contre l'utilisation d'une machine ne s'arrête pas aux serveurs et aux sysadmin du dimanche. Alors il y a d'autres technos, pour d'autres utilisation; et tu utilises ce qui est adapté.
        
        Si tu pars dans cette voie, NM c'est aussi inadapté pour un serveur, que la gestion via /etc & root pour un laptop. Pour faire des choses utilisables dans un environnement dynamiques pour des utilisateurs, on met la tête dans le sable en ce disant que tout est parfait ou on essai de faire mieux ?
        
        [^] # Re: Où est le problème ?
        
        Posté par devnewton 🍺 (site web personnel) le 05 juin 2012 à 20:55. Évalué à 2.
        
        Et quand on veut utiliser une machine pour faire bureau et serveur? On se retrouve avec un système handicapé à cause des choix de technos complexes pour le bien des besoins des utilisateurs?
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
        
        [^] # Re: Où est le problème ?
        
        Posté par ckyl le 05 juin 2012 à 21:17. Évalué à 2.
        
        La dualité n'est pas bureau ou serveur. La dualité est: Est ce que c'est à l'utilisateur local de décider de la configuration réseau ou est ce que c'est un paramètre système ?
        
        Donc si tu n'aimes pas NM, tu ne l'utilises pas et ça ne te pose aucun problème puisque la solution d'avant était parfaite pour tout les usages.
        
        Et si tu as une meilleure approche que celle utilisée pour répondre au besoin au besoin qu’adresse NM une spec ou une implémentation est la bienvenue
        
        [^] # Re: Où est le problème ?
        
        Posté par devnewton 🍺 (site web personnel) le 05 juin 2012 à 21:41. Évalué à 2.
        
        Le problème c'est qu'on se retrouve avec un choix binaire: galérer pour tout configurer à la main ou se taper une GUI pleines de bugs.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
  - [^] # Re: Où est le problème ?
    
    Posté par Sytoka Modon (site web personnel) le 05 juin 2012 à 09:02. Évalué à 5.
    
    La philosophie UNIX repose aussi sur la notion de processus père fils. Il n'y a pas de variable globale. Les variables d'environnement s'exporte du père au fils si on le demande.
    
    Comme ce concept est parfois insuffisant, on peux avoir des segments de mémoire partagé mais l'important est que par défaut, tout tourne dans ce cadre bien cloisonné.
    
    Les méta-serveurs complexe avec les bus puissant vont être un gouffre à bogue. C'est évident. L'étape suivante logique est bien sur les cgroup et au delà, de faire tourner chaque service dans un container. C'est vrai qu'on peux se poser la question du pourquoi faire aussi complexe au central ?
    
    A mon sens, un des premiers coins dans la philosophie UNIX tel que tu l'as décrit a été le langage Perl car Larry en avait marre de chaîner les commandes dans des pipes au final plus compréhensible… Je dois dire que Perl est quand même un super langage pour le système…
    
    Ce qui me gène plus est cet amas de chose binaire au coeur de l'espace utilisateur et que tout cela semble fort peu scriptable donc modifiable par un administrateur système moyen.
  - [^] # Re: Où est le problème ?
    
    Posté par totof2000 le 05 juin 2012 à 09:51. Évalué à 9.
    
    Petite question : quel est l'intéret de virer ifconfig ?
    - [^] # Re: Où est le problème ?
      
      Posté par Batchyx le 06 juin 2012 à 00:20. Évalué à 2.
      
      Ça utilise des ioctl dépréciées, et c'est extrêmement pauvre en fonctionnalités lorsque l'on compare ça à ip qui utilise principalement des interfaces netlink.
      - [^] # Re: Où est le problème ?
        
        Posté par totof2000 le 10 juin 2012 à 23:13. Évalué à 2.
        
        Et pourquoi ne pas adapter ifconfig pour qu'il utilise les ioctls non déprécis et ne pas l'enrichir avec les nouvelles fonctionnalités de ip ?
        
        [^] # Re: Où est le problème ?
        
        Posté par Batchyx le 11 juin 2012 à 22:42. Évalué à 3.
        
        Il n'y a pas d'ioctl non dépréciés, seulement des socket netlink(7).
        
        Et sinon, ifconfig sert principalement à deux choses: afficher des informations sur les interfaces, et modifier la configuration IP. Et faire l'un ou l'autre de manière tronquée n'est pas vraiment une bonne idée.
        
        Par exemple, ifconfig ne supporte pas plusieurs addresse par interface réseau sans passer par des alias moches, n'affiche pas les flags sur ces addresses et n'affiche pas d'information sur les queues utilisées. Ça veut dire que si un autre programme (ou le noyau) rajoute ou se sert de ces fonctionnalités derrière ton dos, tu n'en saura rien. C'est criant en IPv6 : l'autoconfiguration est implémentée par le noyau, donc tu à peut être envie de savoir pendant combien de temps tes addresses IPv6 sont valides pour ton interface.
        
        Ensuite, pour la modification de la configuration, ça pose aussi des problèmes, par exemple, est ce que ifconfig doit virer tout les flags si tu change une addresse IP? Certains de ces flags peuvent faire mal si on ne les voit pas.
        
        Dans ifconfig, il y a aussi des options de configuration bas-niveau (du genre IRQ, addresse io de base et autres) qui n'avaient rien à faire là et dont aujourd'hui plus personne n'en à rien à faire.
        
        Avec la commande route (remplacée aussi par ip), c'est encore pire, puisque il y a bien plus de fonctionnalités ajoutées qui peuvent faire la différence entre un réseau qui marche et un réseau qui marche pas.
        
        Enfin bref, si on veut un ifconfig amélioré qui n'utilise plus d'ioctl, on utilise ip
  - [^] # Re: Où est le problème ?
    
    Posté par reno le 05 juin 2012 à 10:51. Évalué à 4.
    
    On fout tout ce qu'on peut en base de données - Et dès qu'on peut on fait des opérations atomiques". C'est pas tout à fait la philosophie Unix, mais il y a quand même une ressemblance non ?
    
    Vu que réaliser des opérations atomiques sous Unix c'est très compliqué, la ressemblance ne me saute pas aux yeux..
  - [^] # Re: Où est le problème ?
    
    Posté par gnumdk (site web personnel) le 05 juin 2012 à 13:12. Évalué à 1.
    
    Quand on doit se frapper du policykit sauce Red Hat sur une RHEL pour obtenir un comportement
    qui n'est pas prévu à 100% par la maison mère on douille.
    
    En même temps, si tu utilises RedHat sur des serveurs, tu assumes tes choix pourris ;)
    
    Perso, les technos desktop ne me font pas chier sur mes serveurs tout simplement parce qu'elles ne sont pas installées par défaut…
  - [^] # Re: Où est le problème ?
    
    Posté par Puyb (site web personnel) le 06 juin 2012 à 16:56. Évalué à 4.
    
    La philosophie Unix n'est certes pas parfaite, mais elle reste à mon sens à ce jour la meilleure philosophie OS existante. Elle n'a d'ailleurs pour ainsi dire aucun concurrent. > Elle repose sur deux principes :
    1) Tout est fichier (ou ce que vous voulez d'autre, ce n'est pas le point important. Le truc important c'est que chaque élément de l'OS peut être chainé avec chaque autre élément de l'OS pour peut qu'ils tournent dans le même ring)
    2) Un programme fait une chose unique et le fait bien.
    
    Le problème n'est-il pas que la philosophie unix n'a plus vraiment d'application dans un environnement graphique ?
    
    Parce que le coté, fichier / programmes simple que tu pipe, dans un shell graphique, ça a pas vraiment d'équivalent… A part peut être le copier coller…
    
    C'est con, mais quand je surf sur le net, j'aime bien que firefox soit capable de télécharger mon fichier html, faire le rendu, télécharger les dépendances, executer le javascript et lancer flash tout seul…
    
    wget http://linuxfr.org/ | gecko | spidermonkey | view ?
    
    Donc, oui, si la philosophie Unix ne s'applique plus a ce que l'on attend du système (je pense que 99% des gens actuellement, même sur ce site, veulent un environnement graphique au quotidien), ça me choque pas que l'on commence (enfin) a essayer d'adapter les briques de base du système à ces nouveaux besoins…
    
    Moi, j'aime bien mon netbook sous arch-linux avec gnome-shell qui boot en 5s avec systemd, qui rentre et sort de veille en moins d'une seconde, a le wifi qui marche partout avec network manager, le son qui sort sur le hp ou en bluetooth avec pulseaudio et gère le multi écran avec kms pour m'afficher des lolcats avec flash ;-)
    - [^] # Re: Où est le problème ?
      
      Posté par rakoo (site web personnel) le 06 juin 2012 à 19:34. Évalué à 3.
      
      Le problème n'est-il pas que la philosophie unix n'a plus vraiment d'application dans un environnement graphique ?
      
      Tout à fait d'accord.
      
      ça me choque pas que l'on commence (enfin) a essayer d'adapter les briques de base du système à ces nouveaux besoins…
      
      Par contre, je suis pas d'accord du tout. Que certains veuillent afficher des lolcats à n'en plus finir, grand bien leur en fasse; mais ces modifications doivent être apportées aux couches hautes, pas dans les briques de base du système.
      
      Modifier les briques de base reviendrait (en gros, hein) à faire un nouvel OS. C'est d'ailleurs la direction que prend doucement GNOME.
# pulseaudio

Posté par Troy McClure (site web personnel) le 04 juin 2012 à 19:57. Évalué à 9.

Vous avez aimé PulseAudio, le truc qui remplaça ce qui marchait bien avant d'être au point

Tu peux rappeler ce que c'était qui marchait bien selon toi ? Parce que j'ai pas souvenir que l'audio sous linux ait jamais "bien" marché, à mon avis tu es victime du syndrôme "c'etait mieux à vent"
- [^] # Re: pulseaudio
  
  Posté par fleny68 le 04 juin 2012 à 20:18. Évalué à 10.
  
  Je suis arrivé à avoir du son sous linux ans plusieurs programmes simultanément avant pulseaudio, avec oss d'abord (au début) et alsa ensuite. Avec pulseaudio, il fallait que je ferme les onglets firefox contenant du flash pour que vlc sorte du son.
  - [^] # Re: pulseaudio
    
    Posté par gnumdk (site web personnel) le 05 juin 2012 à 13:14. Évalué à 6.
    
    Et c'était de la faute de pulseaudio si on est obligé d'utiliser des grosses merdes bien propriétaire comme Flash ?
    
    Si Flash avait été libre, il aurait fonctionner avec pulseaudio dès le début…
    - [^] # Re: pulseaudio
      
      Posté par briaeros007 le 05 juin 2012 à 19:44. Évalué à 1.
      
      en tout cas il fonctionne comme il le doit avec alsa.
      Mais ca doit etre de la faute d'alsa de marcher …
      
      Tout sauf pulseaudio
- [^] # Re: pulseaudio
  
  Posté par Olivier Serve (site web personnel) le 04 juin 2012 à 20:45. Évalué à 9.
  
  Je fonctionne avec ALSA depuis très longtemps et ça marche tout seul sans rien faire. C'est peut-être mal foutu, pourri jusqu'à la moelle. Peut être.
  
  En attendant, ça marche. Sans me bouffer de CPU. Sans bloquer le son avec certaines applications.
  Je n'ai pas de besoin complexe, et ça fonctionne sans rien faire. C'est tout ce qui compte en tant qu'utilisateur.
- [^] # Re: pulseaudio
  
  Posté par yellowiscool le 04 juin 2012 à 21:53. Évalué à 2.
  
  Moi j'aime bien faire plein de trucs bizarres en réseau, et pouvoir régler le volume application par application.
  
  Envoyé depuis mon lapin.
  - [^] # Re: pulseaudio
    
    Posté par warwick le 05 juin 2012 à 03:21. Évalué à 3.
    
    Jack est ton ami.
    Il n'est pas ton ami parce qu'il est plus performant que Pulse Audio, mais parce qu'il est plus modulaire. Il permet de faire nombre de choses que PA promet mais en laissant une infra propre pour les gens qui ont des besoins plus précis tant en termes de performances qu'en terme de fonctionnalités, et plus encore.
    
    Si les efforts de développements des distribs et desktops (ou shells) avaient été faits sur une meilleur intégration de Jack en parallèle d'Alsa, avec des améliorations sur les fondations des deux outils (pour faire de manière commune des choses que PA fait en surcouche d'Alsa, comme le ré-echantillonage), je pense que Linux aurait une couche Audio telle qu'il la mérite.
    
    Disclaimer : J'ai fini par trouver une raison d'utiliser PA. J'ai un serveur MPD sur mon NAS qui stream vers mes 2 PCs en passant par pulse-audio. Je n'ai pas encore essaye de le faire via jack faute de temps.
    PA, au final, ça marchouille pas trop mal, mais c'est quand même une sacrée usine a gaz, et c'est pas du protoxyde d'azote, mais plutôt du méthane.
    
    P.S.: Ce commentaire est potentiellement sujet a erreurs sur le plan technique. Je suis au boulot, donc je ne peux pas trop vérifier certaines de mes affirmations.
    - [^] # Re: pulseaudio
      
      Posté par briaeros007 le 05 juin 2012 à 19:45. Évalué à 4.
      
      euh… mpd streamer en réseau bien avant PA …
      - [^] # Re: pulseaudio
        
        Posté par warwick le 06 juin 2012 à 06:12. Évalué à 1.
        
        Absolument, mais la latence entre une action sur l'interface et la réalisation de la dite action me rends juste complétement encore plus dingue que je ne le suis en temps normal. Alors si en plus j’écoute du Ludwig von 88, je te laisse imaginer le drame.
- [^] # Re: pulseaudio
  
  Posté par lezardbreton le 05 juin 2012 à 07:45. Évalué à 7.
  
  Je ne comprends pas : ça marchait très bien sous OSS et Alsa avant PulseAudio. Pour mon usage, PulseAudio n'a rien apporté.
  - [^] # Re: pulseaudio
    
    Posté par gnumdk (site web personnel) le 05 juin 2012 à 13:17. Évalué à -1.
    
    Parce que tu n'as pas du matériel hifi "high tech" mais je peux te dire que les gens que je vois sous Ubuntu autour de moi et qui ont des trucs bluetooth pour faire passer le son sur leur ampli, je suis bien content que cela fonctionne tout seul sous Ubuntu grace à PulseAudio et qu'on viennent pas me gonfler avec ce genre de problème… (Parce que, si ca fonctionne sans pulseaudio, ca doit être un bordel à configurer!)
    - [^] # Re: pulseaudio
      
      Posté par briaeros007 le 05 juin 2012 à 19:46. Évalué à 6.
      
      dans le genre de commentaire "j'en sais rien mais je la ramène quand même pour dire que c'est grace à PA" ,il est pas mal
    - [^] # Re: pulseaudio
      
      Posté par Psychofox (Mastodon) le 05 juin 2012 à 21:47. Évalué à 8.
      
      hum
      
      Les gens qui ont du matériel "high fidelity" n'utilisent pas bluetooth pour transporter le son.
- [^] # Re: pulseaudio
  
  Posté par briaeros007 le 05 juin 2012 à 19:43. Évalué à 3.
  
  ah ?
  En 2001 j'avais du son sans problème, de plusieur périphérique.
  En 2003, un oncle (qui c'est mis tout seul sous linux) me demande un peu d'aide pour pouvoir diriger le flux sur l'une ou l'autre des deux cartes son du pc. En 2h30 sous mandriva j'ai réussi a faire ce qu'il voulait. Il n'a jamais réussi a faire ce qu'il voulait sous windows …
  
  Tu peux me rappeler pulseaudio date de quand ?
  - [^] # Re: pulseaudio
    
    Posté par Troy McClure (site web personnel) le 05 juin 2012 à 21:59. Évalué à 2.
    
    En 2001 j'avais du son sans problème, de plusieur périphérique.
    
    je ne sais pas trop ce qu'il faut comprendre de ta phrase. Pareil pour ceux au-dessus qui disent "avec alsa ça marche". ALSA c'est tout et n'importe quoi, c'est l'acces direct à la carte son (exclusif) , c'est l'acces partagé un peu moisi avec dmix, ou bien c'est pulseaudio puisque la façon recommandée d'utiliser pulseaudio pour une application est de passer par le plugin alsa.
    - [^] # Re: pulseaudio
      
      Posté par Moonz le 06 juin 2012 à 09:47. Évalué à 2.
      
      En quoi dmix est pourri ?
      - [^] # Re: pulseaudio
        
        Posté par Troy McClure (site web personnel) le 06 juin 2012 à 11:58. Évalué à 3.
        
        J'ai pas dit que c'était pourri, note. Mais avec dmix il faut fixer la taille du buffer audio (donc la latence) dans la conf, et donc toutes les applis partagent cette meme latence.
# Le point sous gentoo

Posté par Damien Thébault le 04 juin 2012 à 20:10. Évalué à 10.
Sous Gentoo :
- Il y a pulseaudio. Perso j'ai toujours trouvé pulseaudio bien, il sait faire du mixing software alors que c'était vraiment pas terrible avec alsa, et qui est indispensable car il n'y a quasiment plus aucune carte son qui fait du hardware mixing (j'ai toujours ma SB Live! 5.1 PCI d'il y a 10 ans dans un coin, et déjà à l'époque je l'avait achetée pour avoir un son multi-process correct sous linux). En plus pulseaudio sait faire du bluetooth et sait envoyer dynamiquement le son vers ma TV HDMI. Le fin mot c'est qu'il faut l'activer si on veut l'avoir, donc c'est l'utilisateur qui choisit.
- Il n'y a pas systemd, mais ça pourrait être une bonne chose à mon avis, le système d'init de Gentoo, OpenRC, est vraiment pas mal (moins basique que le système de debian par exemple), mais il y a vraiment plein de bonnes idées dans systemd (déjà le système d'activation de sockets et la gestion des cgroups pour les services). Il y a des instructions pour le faire fonctionner si on veut expérimenter.
- PolicyKit et ConsoleKit semblent installés avec Gnome et/ou KDE, mais je n'y ai jamais touché et mon système a toujours correctement fonctionné, donc j'imagine que la configuration par défaut est bonne, ou bien que c'est suffisamment transparent pour ne pas poser de problème (j'ai toujours créé mes utilisateurs avec useradd et modifié ses groupes avec gpasswd).
Au final, le grand avantage de Gentoo par rapport aux distributions précompilées c'est bien le fait de pouvoir tout configurer comme on veut, et par exemple de désactiver le support de pulseaudio/systemd/policykit/consolekit si on en a envie. (Et bien sûr de les masquer pour être bien sûr qu'ils ne puissent jamais s'installer !)

(Inversement, si on veut les dernières technos hype du moment, on y arrive en cherchant un peu également, donc tout le monde est content)
- [^] # Re: Le point sous gentoo
  
  Posté par Panda Voyageur (site web personnel, Mastodon) le 05 juin 2012 à 14:42. Évalué à 1.
  
  C'est l'avantage des meta-distributions pour des râleurs comme nous! (non pour mon utilisation personnelle je n'ai pas beseoin de pulseaudio pour faire sortir du son des 2 haut-parleurs, merci)
  
  D'ailleurs sous Gentoo, il y a un support expérimental de systemd pour ceux qui sont joueurs!
  
  Autre exemple: pour les allergiques à udev, il est possible d'utiliser mdev et faire disparaître entièrement udev (populaire chez les personnes ayant /usr sur une partition séparée et n'utilisant pas d'initramfs)
  
  Après, est-ce que le choix sera toujours possible dans les années à venir (entre GnomeOS et un unix-like), à voir…
- [^] # Re: Le point sous gentoo
  
  Posté par briaeros007 le 05 juin 2012 à 19:55. Évalué à 1.
  
  Au final, le grand avantage de Gentoo par rapport aux distributions précompilées c'est bien le fait de pouvoir tout configurer comme on veut, et par exemple de désactiver le support de pulseaudio/systemd/policykit/consolekit si on en a envie. (Et bien sûr de les masquer pour être bien sûr qu'ils ne puissent jamais s'installer !)
  
  La dernière fois que j'ai essayé gentoo j'ai arrpeté rapidement.
  
  Après une install bateau et la compil de deux/trois soft, je veux mettre, je crois un kerberos ldap.
  
  Donc je met mes use qui m'interesse et je lui dis d'installer lesdits paquets.
  
  Et paf, référence circulaire!
  ldap atteint kerberos pour être compilé avec le support de krb5, et vice et versa …
  
  Après un peu de recherche pour voir comment enlever une ref circulaire de façon propre chez gentoo, n'ayant rien trouvé, je suis parti vers des cieux plus cléments.
# Mauvaise distro, changer de distro

Posté par gouttegd le 04 juin 2012 à 20:10. Évalué à 6.

Vous avez aimé Policykit, le machin dont les fichiers de configurations ne sont pas sous /etc

Je ne sais pas quelle distro tu utilises, mais chez moi la configuration de PolicyKit se fait bien dans /etc/polkit-1.

Quant à PulseAudio et AccountService, il n’y a rien de tel chez moi (je ne les ai pas désinstallés, ils n’ont jamais été là, pas fournis par Slackware), et le système ne fonctionne pas plus mal. Comme quoi on peut avoir un GNU/Linux sans ces bêtes-là.
- [^] # Re: Mauvaise distro, changer de distro
  
  Posté par fleny68 le 04 juin 2012 à 20:29. Évalué à 4.
  
  Là je parle de la dernière ubuntu que j'ai fait mettre par le vendeur sur le portable que j'ai acheté pour ma douce et tendre.
  
  Il y a un problème technique (wifi) assez facile à régler, mais c'est l'aspect gestion des utilisateurs dans lightdm qui me gonfle. Oui je sais, je peux virer lightdm, mais là je voulais le laisser le plus près possible de l'installation standard cUbuntu (interface cinamon).
  
  Mon hypothèse c'est que peut-être chez Ubuntu ou chez Redhat, on se jette sur n'importe quelle idée qui rend compliqué un truc qui était simple, parce que ça doit leur permettre de vendre du support plus cher et plus souvent.
  - [^] # Re: Mauvaise distro, changer de distro
    
    Posté par Renault (site web personnel) le 04 juin 2012 à 20:35. Évalué à 1.
    
    Mon hypothèse c'est que peut-être chez Ubuntu ou chez Redhat, on se jette sur n'importe quelle idée qui rend compliqué un truc qui était simple, parce que ça doit leur permettre de vendre du support plus cher et plus souvent.
    
    Bien sûr, c'est un complot !
    
    Non c'est logique, l'informatique évolue et ce n'est pas parce que les bases viennent d'Unix que c'est gravé dans le marbre et inébranlable. Il n'y a pas que Windows et mac OS X qui doivent retailler le bas niveau du système, tout le monde doit suivre la tendance suivant la technologie actuelle et les nouvelles possibilités et besoins.
    
    Par exemple PulseAudio répond au besoin du son à travers le réseau de manière bien plus efficace que ce qui était disponible avant, PolicyKit (et autres trucs dans le genre) répondent aux nouveaux besoins de la sécurité qui n'existaient pas comme problématique dans les années 70. Etc.
    Même les fondateurs de Unix ont crée Plan 9 pour aller plus loin et refaire des parties du système qui n'étaient pas adaptées aux besoins modernes comme le réseau. Ce n'est pas pour faire joli, c'est pour évoluer et s'adapter à de nouveaux problèmes qui n'existaient pas à l'époque.
    - [^] # Re: Mauvaise distro, changer de distro
      
      Posté par gouttegd le 04 juin 2012 à 20:55. Évalué à 10.
      
      PolicyKit (et autres trucs dans le genre) répondent aux nouveaux besoins
      
      Genre, des besoins que personne n’a jamais été capable de formuler correctement ? Quand on lit, dans la dernière documentation en date de ConsoleKit, que la définition du problème reste à écrire, ça ne m’inspire pas très confiance.
      
      Le truc marrant, c’est que maintenant que ConsoleKit est obsolète et en passe d’être remplacé par systemd-loginctl (dont la documentation n’est pas plus fournie concernant le problème à résoudre ou le besoin à satisfaire), personne ne mettra à jour ce document, autrement dit ConsoleKit aura passé sans que jamais quelqu’un ne prenne le temps d’expliquer quel était le problème justifiant son existence.
      
      Bien sûr, c'est un complot !
      
      Je ne crois pas une seconde que RedHat ou qui que ce soit introduise de nouveaux composants juste pour accroître la demande de support. En revanche, j’ai effectivement l’impression que certaines distros se jettent bel et bien sur n’importe quelle idée nouvelle, « on intègre d’abord et on verra bien ensuite à quoi ça peut bien servir ».
      - [^] # Re: Mauvaise distro, changer de distro
        
        Posté par Misc (site web personnel) le 05 juin 2012 à 07:31. Évalué à 5.
        
        Consolekit permet d'ajuster dynamiquement les permissions des devices, ( de maniére concrete ) et de gérer le concept de session utilisateur ( ie, qui est connecté, à distance, pas à distance ). Un des problèmes de l'approche traditionnel, c'est de filer les droits sur la carte son de façon indiscriminé, que je sois en ssh ou pas. Peut être que je suis le seul à avoir l'esprit taquin, mais sous solaris, via telnet, on pouvait lancer des commandes pour jouer de la musique sur la station du voisin. Bien sur, ça veut aussi dire qu'à distance, je peux activer le micro, et ça, c'est moins cool. Conséquence direct du "je suis loggué et dans le bon groupe donc j'ai accés sur la carte son".
        
        Pareil sur les cdroms ( eject ? ) ou la webcam, etc.
        
        [^] # Re: Mauvaise distro, changer de distro
        
        Posté par Frank-N-Furter le 05 juin 2012 à 07:48. Évalué à 6.
        
        Windows le fait aussi avec sub7 :D
        
        Plus sérieusement, je suis toujours un peu mal à l'aise quand je vois des gens venir réclamer des choses en invoquant l’esprit de ceci, ou de cela. Que ça soit l’esprit de la GPL, d’UNIX ou de De Gaulle.
        
        Depending on the time of day, the French go either way.
        
        [^] # Re: Mauvaise distro, changer de distro
        
        Posté par Sytoka Modon (site web personnel) le 05 juin 2012 à 08:51. Évalué à 4.
        
        Avec pam_group, tu donnes (donnait) les droits qui vont bien en mettant la personne dans un groupe. Pas ssh, tu ne donnait pas le groupe audio et c'était tout.
        
        Bref, une bête gestion par groupe… simple à comprendre et qui marchait plutôt bien.
        
        [^] # Re: Mauvaise distro, changer de distro
        
        Posté par ckyl le 05 juin 2012 à 08:57. Évalué à 3.
        
        Et quand tu fais du multi-utilisateurs comme sur un desktop à la maison ?
        
        [^] # Re: Mauvaise distro, changer de distro
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 05 juin 2012 à 11:11. Évalué à 1.
        
        Eh bien, pam_group justement, c'est impeccable pour ça.
        
        [^] # Re: Mauvaise distro, changer de distro
        
        Posté par Misc (site web personnel) le 05 juin 2012 à 12:01. Évalué à 3.
        
        Mais est ce que ça gère le fast-user switching de façon propre ( http://fedoraproject.org/wiki/Desktop/FastUserSwitching ) ? ( car consolekit permet aussi ça, vu que tu as une vue plus haut niveau du concept de session )
        
        De plus, pam_group requiert de monter le fs avec une option spécial pour être sur ( d'après sa page de man ), ce qui exclue du coup l'usage d'une partition /home non séparé de / ( ou ce qui justement interdit des usages légitimes du setgid par les utilisateurs. Bien que ça soit une solution pour pas mal de gens ( et que je pense qu'avoir un /home séparé devrait être forcé et que personne n'utilise le setgid ), je pense pas que ça soit super pour une distro de forcer ça.
        
        [^] # Re: Mauvaise distro, changer de distro
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 05 juin 2012 à 13:01. Évalué à 1.
        
        Mais est ce que ça gère le fast-user switching de façon propre ?
        
        Qu'est-ce que c'est que ce changement rapide d'utilisateur ? S'il s'agit de verrouiller l'écran de l'utilisateur existant puis lancer un nouvel écran de connexion sur tty8 et de laisse le nouvel utilisateur se connecter, c'est indépendant. Si c'est autre chose, ça sert à quoi au juste ?
        
        [^] # Re: Mauvaise distro, changer de distro
        
        Posté par ckyl le 05 juin 2012 à 13:59. Évalué à 4.
        
        Si c'est autre chose, ça sert à quoi au juste ?
        
        D'avoir un service qui est capable de connaitre les sièges et de suivre les sessions afin de permettre de faire des environnements pas trop cons, ce qui inclus de manière non exhaustives:
        1. Pour les applis de bureau, de connaitre l'état de sa session. Si on est plus la session active, on peut passer idle, désactivé le son etc.
        2. Pour la gestion des périphériques, adapté les permissions, changer les paramètres etc.
        3. Pour les démons systèmes, savoir l'état global du système. Par exemple j'ai eu a écrire un service, qui devait détecter quand il n'y pas d'utilisateur actif pour lancer des calculs en tâche de fond. Sans un comportement commun type console kit t'es un peu dans la merde.
        
        Ca ne sert à rien pour un serveur. Ca ne sert à rien si tu ne veux pas un comportement simili-intelligent. Ça ne sert pas à grand chose si tu as un seul utilisateur local par machine. Mais, ca sert à faire un système qui se comporte comme un tout. Histoire de sortir un peu de l'état pouilleux des bureaux Linux pour les particuliers.
        
        Alors console-kit en tant que tel n'était peut être pas la solution la plus heureuse, mais ca répond à un besoin et personne n'a proposé mieux avec les briques qui existaient.
        
        [^] # Re: Mauvaise distro, changer de distro
        
        Posté par briaeros007 le 05 juin 2012 à 20:02. Évalué à 3.
        
        Pour les applis de bureau, de connaitre l'état de sa session. Si on est plus la session active, on peut passer idle, désactivé le son etc.
        
        passer idle et désactiver le son, je vois pas pourquoi une appli de bureau le déciderais. Ce sont des décision système. Que l'appli bureau dise au systeme "quand il y a personne de connecté, fais ci" pas de souci, mais que ce soit l'appli qui détecte l'evenement et agisse en conséquence …
        Et qu'est ce que la gestion des évenement viens foutre avec la gestion des droits ????
        
        Pour les démons systèmes, savoir l'état global du système. Par exemple j'ai eu a écrire un service, qui devait détecter quand il n'y pas d'utilisateur actif pour lancer des calculs en tâche de fond. Sans un comportement commun type console kit t'es un peu dans la merde.
        
        De mon temps on lançait en nice -n 20 et crois le ou pas, sur des machines mutualisé avec ~30 personnes par machine (c'était des bi proc 3Ghz) ben ça marchait niquel et jamais personne n'est venu se plaindre (alors que mon job il a tourné pendant plus d'une semaine au taquet ^{^).}
        
        C'est comme en marketing "on invente un besoin et on vous propose de le satisfaire".
        
        [^] # Re: Mauvaise distro, changer de distro
        
        Posté par ckyl le 05 juin 2012 à 20:28. Évalué à 3.
        
        ConsoleKit fait uniquement ce pour quoi il est conçu, tracer les sessions. On peut l’interroger, et il émet les événements relatif à ca sur le bus session et le bus system. Le reste c'est le choix des clients de ConsoleKit. Si un IM veut passer le status en idle et desactiver les notifications sonores quand la session n'est plus active, c'est son choix il va pas demander au système. Si le système décide de supprimer temporairement certains droits aux applications d'une session inactive c'est son choix.
        
        Pour le nice -n 20 j'aime quand tu insultes mon intelligence. Tu ne peux pas imaginer 30s que ça ne répond pas forcément à tout les besoins et qu'on peut avoir besoin de faire autrement ?
  - [^] # Re: Mauvaise distro, changer de distro
    
    Posté par CrEv (site web personnel) le 04 juin 2012 à 20:52. Évalué à 4.
    
    Oui je sais, je peux virer lightdm, mais là je voulais le laisser le plus près possible de l'installation standard cUbuntu (interface cinamon).
    
    Cool, je viens d'apprendre que cubuntu existait… Donc c'est encore un autre fork d'ubuntu de derrière les fagots, c'est encore pas tout à fait pareil que les autres, faut ptetre pas s'étonner s'il y a des problèmes.
    Question conne, ton problème de login il existe avec une ubuntu "standard" ou pas ? Si oui, ok j'ai rien dit. Si non, fallait ptetre pas prendre ça comme distro, non ?
    
    Parce que bon, le truc, c'est que ça respire surtout le fait que tu prends une distrib avec un certain type d'usage et que tu veux en faire autre chose. Non que ce ne soit pas possible (d'ailleurs tu donne même des pistes pour le faire) mais forcément c'est plus complexe.
    Par exemple une ubuntu c'est surtout fait pour avoir un compte sudo. Donc que ce soit pas forcément prévu de base pour avoir un compte admin qui en plus n'apparaît pas dans la liste ça ne me choque pas le moins du monde.
    
    Donc si tu veux du "unix-like-saytaimieuavent" pourquoi ne pas s'orienter vers une slackware par exemple ? Je pense que c'est plus proche de l'esprit non ? Ou peut-être même simplement une debian non ? Et si tu es près à quitter linux pourquoi pas un bsd ? Tout dépend ce que tu cherches, du linux ou plus généralement du unix ?
    Ha oui, et mac c'est aussi un unix par exemple, mais là tu risques de bondir…
    
    Mon hypothèse c'est que peut-être chez Ubuntu ou chez Redhat, on se jette sur n'importe quelle idée qui rend compliqué un truc qui était simple, parce que ça doit leur permettre de vendre du support plus cher et plus souvent.
    
    Ou alors ils cherchent à faire des choses utilisable par une personne normale, sans ligne de commande, sans compétences spécifiques (je dit pas que ce soit le cas par contre, qu'ils y arrivent) (deuxième parenthèse, ubuntu et redhat c'est pas tout à fait le même publique non plus hein…)
    - [^] # Re: Mauvaise distro, changer de distro
      
      Posté par fleny68 le 04 juin 2012 à 21:11. Évalué à 3.
      Question conne, ton problème de login il existe avec une ubuntu "standard" ou pas ? Si oui, ok j'ai rien dit. Si non, fallait ptetre pas prendre ça comme distro, non ?
      
      On dirait: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/857651
      
      Je ne connaissais pas cUbuntu non plus. J'ai pris ça pour voir, avec cinnamon en alternative à gnome-shell (qui est présent aussi) en me disant que si ça marchait pas je mettrai autre chose. C'est marqué "ubuntu 12.04" dedans.
      
      Je n'ai jamais gardé ubuntu très longtemps mais là c'est pas pour moi la machine.
      - [^] # Re: Mauvaise distro, changer de distro
        
        Posté par gnumdk (site web personnel) le 05 juin 2012 à 13:26. Évalué à 3.
        
        Je n'ai jamais gardé ubuntu très longtemps mais là c'est pas pour moi la machine.
        
        Alors laisse la tranquille la machine! C'est dingue cette manie de vouloir tout transformer comme sur sa propre machine… T'inquietes que les gens, ca fonctionne très bien chez eux Ubuntu parce qu'ils ont autre chose à faire que de vouloir tout changer…
    - [^] # Re: Mauvaise distro, changer de distro
      
      Posté par Frank-N-Furter le 04 juin 2012 à 23:19. Évalué à 3. Dernière modification le 04 juin 2012 à 23:20.
      
      Ha oui, et mac c'est aussi un unix par exemple, mais là tu risques de bondir
      
      Paceque ça fait ce qu'il veut? :)
      sudo defaults write /Library/Preferences/com.apple.loginwindow HiddenUsersList -array-add flenny68
      
      Depending on the time of day, the French go either way.
  - [^] # Re: Mauvaise distro, changer de distro
    
    Posté par be_root le 04 juin 2012 à 21:34. Évalué à 5.
    
    ~~j'ai~~ je me suis fait mettre par le vendeur
    
    Il se prend pour Napoléon, son état empire.
  - [^] # Re: Mauvaise distro, changer de distro
    
    Posté par GeneralZod le 05 juin 2012 à 08:55. Évalué à 4.
    
    Mon hypothèse c'est que peut-être chez Ubuntu ou chez Redhat, on se jette sur n'importe quelle idée qui rend compliqué un truc qui était simple, parce que ça doit leur permettre de vendre du support plus cher et plus souvent.
    
    Perso, je préfère PolicyKit qui oblige les développeurs à découpler les composants logiciels nécessitant des privilèges aux autres que le bouzin gksudo qui fait tout tourner en mode privilégié. Pour les utilisateurs de base, ça convient parfaitement, pour les power users, ça demande un peu plus d'efforts, mais les man pages sont extrêmement bien faites.
    - [^] # Re: Mauvaise distro, changer de distro
      
      Posté par gnumdk (site web personnel) le 05 juin 2012 à 13:27. Évalué à 2.
      
      Merci de le préciser…
      
      Je fais encore des bons quand je vois des applis qui passent root dès le début de leur exécution… VIVE POLICYKIT!
  - [^] # Re: Mauvaise distro, changer de distro
    
    Posté par devnewton 🍺 (site web personnel) le 05 juin 2012 à 11:59. Évalué à 3.
    
    la dernière ubuntu
    
    Il ne faut jamais installer la dernière Ubuntu, seules les versions LTS après une première fournée de patch correctifs sont de qualité.
    
    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Il est déjà neuf heures, là ?

Posté par Effraie (site web personnel) le 05 juin 2012 à 00:06. Évalué à 3.

s/neuf heures/vendredi/g

\Ö<
- [^] # Re: Il est déjà neuf heures, là ?
  
  Posté par zerkman (site web personnel) le 05 juin 2012 à 09:15. Évalué à 3.
  
  sur mon front y'a pas marqué radio réveil
# L'embarras du choix

Posté par jbbourgoin (site web personnel) le 05 juin 2012 à 08:55. Évalué à 4.

En gros on a le choix et c'est grave ? C'est ça ?

Il me semble quand même que si on veut du "pur" Unix (ou du vieil Unix selon le point de vue), on peut toujours :

1) Installer un BSD

2) Configurer sa Debian / Ubuntu / Arch aux petits oignons. grep, useradd, mount et alsa existent toujours.

3) Installer Slackware

C'est pas la fin du monde.

Ce que je vois de mon côté :

1) Pulseaudio chez moi ça fonctionne très bien. Y compris le couple pulseaudio/jack.

2) Je ne m'enquiquine plus avec mount, umount.

3) useradd fonctionne toujours

4) Configurer PolicyKit est une plaie (mais heureusement dans 99% des cas, ça va).

Donc, globalement, la situation actuelle me satisfait.
# Logiciel libre, tout ca

Posté par cedric le 05 juin 2012 à 08:55. Évalué à 2.
Juste pour t'informer que le principe du logiciel libre, c'est d'avoir le choix et que c'est la technologie la plus utile pour tous qui finit par prendre la plus grosse part du marche. De plus tu peux toi meme l'influer, donc si une solution de ta distrib ne te plait pas, tu peux :
- Changer de distrib
- Faire un rapport de bug
- Proposer un patch
Si le comportement d'un logiciel ne te plait pas, tu peux :
- Changer de logiciel
- Faire un rapport de bug
- Proposer un patch
Je veux pas etre mesquin, mais bon, c'est celui qui fait qui decide, apres vous avez le loisir de choisir qui suivre, si vous ne voulez rien faire…
- [^] # Re: Logiciel libre, tout ca
  
  Posté par zerkman (site web personnel) le 05 juin 2012 à 09:17. Évalué à 4.
  
  y'a aussi des gens qui font leur propre distrib, mais faut vraiment avoir du temps à perdre.
  - [^] # Re: Logiciel libre, tout ca
    
    Posté par myou (site web personnel) le 05 juin 2012 à 09:40. Évalué à 2.
    
    y'a aussi des gens qui font leur propre distrib, mais faut vraiment avoir du temps à perdre.
    
    ou alors simplement avoir envie de comprendre comment une distrib fonctionne, comment on peut faire, ce que ca implique comme choix etc…. Et ensuite on voit les distrib existantes d'une autre manière ;o)
- [^] # Re: Logiciel libre, tout ca
  
  Posté par fleny68 le 05 juin 2012 à 10:02. Évalué à 10.
  
  Certes, mais le problème est que les solutions adoptées par les grandes distributions ont tendance à phagocyter beaucoup de logiciels tiers. Que fais tu lorsque vlc ne supportera plus que PulseAudio? Lorsque gnome ne supportera rien d'autre que accountservice? Tu devras soit céder, soit te passer de gnome et de vlc.
  
  C'est pour cela que cette évolution m'inquiète. Si on ajoute l'injonction de Lenhart à tourner le dos à la compatibilité unix, je trouve que la direction n'est pas bonne.
  
  Alsa est resté un bon moment en -staging avant de rentrer dans le noyau officiel. Linus exige une certaine maturité, un certain recul et une certaine stabilité avant d'adopter un changement radical. Personnellement j'aimerais que les distributions fassent de même.
  - [^] # Re: Logiciel libre, tout ca
    
    Posté par cedric le 05 juin 2012 à 11:41. Évalué à 2.
    Et bien tu fairas un patch ! Surtout que le code existe deja, donc c'est plutot une question de mainteneur. Et les logiciels libres (a part GNOME) sont plutot sur le plus de fonctionnalite que sur leur suppression, donc c'est plus du FUD qu'autre chose.
    
    Et je suis desole, mais il y a plein de chose qui ne sont pas bonne dans l'approche UNIX et qu'il faut corriger pour :
    - Avoir un desktop reactif
    - Consommer peu de ressource
    - Assurer la securite de ses utilisateurs
    Et corriger, c'est souvent redesigner et donc etre incompatible.
    
    Bon apres, je vais pas faire semblant de pas comprendre ta reference a Lenhart, c'est pas le fait qu'il tourne le dos a la compatibilite unix qui te pose souci, mais le fait qu'il n'en ait rien a faire de porter son dev sur tous les OS de la planete. Franchement, si les devs de ces OS ou leurs utilisateurs veulent cette fonctionnalite, et bien, c'est a eux de faire le boulot. Et Lenhart a clairement dis qu'il accepterait les patchs pour assurer la portabilite, donc le probleme, il est dans l'absence de volonte ou de capacite d'un cote et pas de celui que tu penses.
    
    Pour ce qui est des distrib, si tu veux un truc qui bouge pas, prend une bonne vieille debian. Si tu veux des soft recent et moderne, et bien, soit tu fais des patchs dans tous les sens pour utiliser toutes les technologies qui te font plaisir, soit tu prends d'autres soft.
    Mais a un moment donner, il faut comprendre qu'un dev, il n'a pas envit de s'amuser a supporter 25000 vieilleries juste pour rassurer des vieux barbus qui ont peur du monde qui change ! Utiliser des bibliotheques, des services modernes facilitent la vie du developpeur et lui permettent de developper et d'ameliorer son code plus rapidement. D'ailleur les developpeurs sont rarement force de faire un choix dans leur dependences, ils prennent juste ce qu'il leur convient le mieux.
    Encore une fois, si un truc te plait pas, propose quelque chose de mieux que les developpeurs adopteront. C'est pas plus compliquer que ca ! Certe c'est du pire Darwinism, certe ca bouge vite, certe il faut etre competitif…
    - [^] # Re: Logiciel libre, tout ca
      
      Posté par briaeros007 le 05 juin 2012 à 22:56. Évalué à 3.
      
      Et je suis desole, mais il y a plein de chose qui ne sont pas bonne dans l'approche UNIX et qu'il faut corriger pour :
      Avoir un desktop reactif
      Consommer peu de ressource
      Assurer la securite de ses utilisateurs
      
      Tu peux dvp, parce que j'ai beau regardé, je vois pas, mais alors pas du tout le lien entre tes différentes affirmations.
      
      Quant à parler de desktop "réactif" et de sécurité dans la même phrase, d'expérience ça me fait sourire, surtout quand je vois la direction prise pour assurer la "sécurité".
      - [^] # Re: Logiciel libre, tout ca
        
        Posté par cedric le 06 juin 2012 à 07:01. Évalué à 3.
        
        Le probleme du desktop reactif :
        Un desktop reactif, c'est quand tu click sur quelque chose, tu as instantanement ton resultat. Il n'est pas normal en 2012 d'attendre qu'une application se lance. Prend un iPad, tu n'attends pas pour la majorite des applications.
        Le probleme vient entre autre a mon sens :
        - plein de process donc duplication de donnees et de calculs entre eux.
        - la lenteur demente de l'editeur de lien (qui impacte plus les applications C++ que C)
        - les fichiers de configuration en texte repartie un peu partout sur le disque
        - les donnees de maniere general qui sont reparti un peu partout sur le disque
        
        Le probleme pour la consomation de ressource est finalement tres lie a la problematique du desktop reactif, si on consomme moins de ressource, et bien on de maniere mecanique un systeme plus reactif. Normal, moins on en fait, plus on peut le faire vite.
        
        Pour ces deux problemes, j'y travaille via le projet auquel je contribue, Enlightenment, pour obtenir un bureau plus rapide, plus leger, plus souple. Mais il y a encore du boulot pour arriver au resultat voulu.
        
        Enfin le probleme de la securite des utilisateurs est nettement plus complexe. On duplique les donnees de l'utilisateur dans beaucoup d'endroit et on n'en assure jamais la securite. Le focus est donnees sur le fait qu'on ne devienne pas root et que la securite de chaque utilisateur est finalement laisse a l'utilisateur. On a de la chance de ne pas avoir beaucoup de desktop Linux dans la nature. La securite pour un utilisateur Linux vient du faite que le nombre d'installation identique est faible et que la cible a peu d'interet economique. Donc la securite est fait pour un serveur, pas pour une utilisation desktop. Et la je n'ai pas de solution pour l'instant, mais c'est aussi parce que ce n'est plus vraiment mon domaine.
      - [^] # Re: Logiciel libre, tout ca
        
        Posté par Moonz le 06 juin 2012 à 09:49. Évalué à 3.
        
        C’est pas en ajoutant des couches qui n’existaient pas avant (ConsoleKit, PulseAudio, NM) qu’on va résoudre le moindre problème de réactivité et de consommation de ressources.
        
        [^] # Re: Logiciel libre, tout ca
        
        Posté par cedric le 06 juin 2012 à 11:15. Évalué à 2.
        
        Des fois ci. La couche superieur peut etre plus simple a ecrire ou utilise plus d'outil. Par exemple, prenons l'exemple de pulse-audio. Avec et vu qu'il est a un niveau suffisament haut dans la stack logiciel, il lui est possible d'utiliser directement l'acceleration materiel d'un casque quand tu ecoute un film. PulseAudio est certe plutot complexe et peu de monde se rend bien compte de toutes les fonctionnalites qu'il offre.
        
        Pour les deux autres n'ayant jamais joue avec, je n'ai pas d'idee a leur propos.
# Est-ce au moins possible en théorie ?

Posté par Alek_Lyon le 05 juin 2012 à 14:03. Évalué à 10.

J'ai d'excellents souvenirs de galères épanouissantes avec Linux il y a environ dix ans : tout ce qu'il fallait comprendre et apprendre pour installer et faire fonctionner au poil mon système !

Aujourd'hui, tout fonctionne comme sur des roulettes : le son, le multi-écran, l'ajout d'utilisateurs et de services, les diverses possibilités de mise en veille, le branchement de n'importe quel périphérique ou presque, etc. Au passage, mes cas d'utilisation ont explosé : téléchargements, photos, réseaux NATés (et oui, avant, c'était un simple modem), réseaux Wifis, Cloud, nombreux périphériques…

Hélas, quand un petit grain de sable vient compromettre cette belle mécanique, je me rends compte que je ne connais plus rien ("mais à quoi sert donc ce BloatKit ?" "où se trouve quelle configuration et quel est son format ?" : aucune idée) ; je me dépanne en cherchant sur google et puis j'oublie.

C'est pourquoi parfois, j'en viens à regretter la disparition de cette philosophie unix, qui me permettait de comprendre et d'apprendre durablement le fonctionnement de mon système et même en fait, d'aller au delà puisqu'il est si simple de combiner des outils qui n'ont pas été prévus pour.

Mais en parallèle, je me demande toujours s'il serait vraiment possible de la conserver tout en maintenant la même simplicité d'utilisation et les nombreux usages que je fais de mon Desktop. Je n'ai pas de réponse sur ce point, franchement. J'aimerais que ce soit oui - mais je sais que ce n'est pas moi qui le ferai ; du coup je ne peux ni reprocher aux autres devs du libre de ne pas le faire ni nier que ce qu'ils font me facilite énormément la vie.
- [^] # Re: Est-ce au moins possible en théorie ?
  
  Posté par ckyl le 05 juin 2012 à 14:17. Évalué à -2. Dernière modification le 05 juin 2012 à 14:20.
  
  Tu t'es formé il y a dix ans, et tu étais obligé de te taper des kilo de documentation. Maintenant ca marche presque toujours tout seul, donc tes connaissances sont obsolètes et tu n'as rien appris des nouvelles technos. Maintenant si tu fournissais le même effort qu'à l'époque peut être que tu serais compétent aujourd'hui. Modulo le fait qu'un desktop moderne fait beaucoup plus de chose qu'il y a dix ans et qu'il y a donc forcément plus de choses à savoir.
  
  Bref tu reproches aux autres ta fainéantise d'aujourd'hui tout en crachant sur leur boulot. Si tu veux revenir à l'état d'il y a dix ans, ce n'est pas très difficile mais tu vas couiner que rien ne marche…
  
  Maintenant sur quoi tu te bases pour dire que ConsoleKit est un BloatKit ? En quoi est il plus mal conçu que les outils d'avant ? En quoi ne peut il pas être combiné avec d'autres outils ?
  - [^] # Re: Est-ce au moins possible en théorie ?
    
    Posté par gnumdk (site web personnel) le 05 juin 2012 à 15:17. Évalué à 1.
    
    Voilà, bien d'accord avec toi…
    
    C'est surtout une question de mise à niveau, un peu comme les admins Windows qui ne savent pas se servir de powershell…
  - [^] # Re: Est-ce au moins possible en théorie ?
    
    Posté par Alek_Lyon le 05 juin 2012 à 15:37. Évalué à 8.
    
    Tu t'es formé il y a dix ans, et tu étais obligé de te taper des kilo de documentation. Maintenant ca marche presque toujours tout seul, donc tes connaissances sont obsolètes et tu n'as rien appris des nouvelles technos. Maintenant si tu fournissais le même effort qu'à l'époque peut être que tu serais compétent aujourd'hui. Modulo le fait qu'un desktop moderne fait beaucoup plus de chose qu'il y a dix ans et qu'il y a donc forcément plus de choses à savoir.
    
    Oui, avec en plus la question suivante :
    Serait-il, au moins en théorie, possible d'avoir quelque chose de simple, d'automatique et de complet comme aujourd'hui ET qui se maitrise, se bidouille et se configure comme il y a dix ans ? Je n'en sais rien et je n'en jurerai pas.
    
    Bref tu reproches aux autres ta fainéantise d'aujourd'hui tout en crachant sur leur boulot. Si tu veux revenir à l'état d'il y a dix ans, ce n'est pas très difficile mais tu vas couiner que rien ne marche…
    
    Si je puis me permettre de citer mon message original :
    
    du coup je ne peux ni reprocher aux autres devs du libre de ne pas le faire [du KISS et de l'UNIX] ni nier que ce qu'ils font me facilite énormément la vie.
    
    Je ne crois donc pas avoir reproché quoi que ce soit à quiconque, ni m'être plaint. J'avais même la prétention d'être nuancé c'est pour dire ;-)
    
    Quant au terme "BloatKit", c'était de l'autodérision (selon le principe que tout ce que m'est nouveau et inconnu est un Bloat) ; mea culpa, après 15 ans d'internet, il m'arrive encore d'oublier que personne ne perçoit l'ironie quand il ne reste plus que le texte du message et qu'ont disparu les sourires et mimiques que je faisais en l'écrivant.
    
    Bref, je ne sais toujours ce que fait PolicyKit, je sais juste qu'aujourd'hui j'en fous pas une, que tout fonctionne à merveille ou presque et que c'est entre autre grâce à PolicyKit. J'espère que c'est plus clair.
  - [^] # Re: Est-ce au moins possible en théorie ?
    
    Posté par fleny68 le 05 juin 2012 à 15:43. Évalué à 3.
    
    ConsoleKit est un très bon exemple. Tellement indispensable qu'à peine arrivé il est déjà remplacé par autre chose.
    J'aurais pu ne pas m'apercevoir qu'il avait existé. Mais il s'est retrouvé installé dans les distributions tellement vite qu'il a réussi à me compliquer la vie, et puis hop, il disparait…
    
    PolicyKit est arrivé, et lui aussi il n'a pas réussi à être discret: je me suis retrouvé avec ddes utilisateurs qui ne pouvaient plus éteindre la machine: https://linuxfr.org/users/fleny68/journaux/ma-simple-session-avec-compiz-et-cairo-dock#toc_4 Pour quel progrès? Je cherche encore.
    
    Contrairement à ce que tu semble dire, j'arrive à faire marcher ces trucs. Mais c'est à coup de "démerde-toi la doc n'est pas encore écrite" (alors que les trucs en questions sont déjà généralisés dans les distributions) et autres bidouilles qui fleurent bon le retour à l'époque où, pour se connecter à internet sous linux, il fallait mettre un raccourci vers un script pour lancer la numérotation sur le modem parce que le noyau ne supportait pas encore le dial-on-demand. Je pensais que cette époque était révolue, elle revient. On a eu les configurations de mieux en mieux automatisées des outils standards et bien documentés, on a maintenant les configurations minimalistes d'outils prévus pour un seul type d'usage (celui de la mamie d'un développeur gnome je parie) généralisés avant d'être au point parce que c'est quand même mieux si ce sont les utilisateurs finaux qui déboguent. Quand c'est juste l'interface j'en prend une autre, quand c'est le coeur du système je râle quand même un peu plus.
    - [^] # Re: Est-ce au moins possible en théorie ?
      
      Posté par ckyl le 05 juin 2012 à 16:10. Évalué à 1.
      
      ConsoleKit est un très bon exemple. Tellement indispensable qu'à peine arrivé il est déjà remplacé par autre chose
      
      Premièrement ConsoleKit aura été livré dans Fedora pendant 6 ans…
      
      Deuxièment peut être que ConsoleKit était nécessaire avec un init SysV mais passer à systemd permet de faire la chose plus proprement ? Moi en général avant de dire que les autres font des choix de merdes et sont incompétents, je lis le code et j'explique pourquoi ils sont cons, ou alors je suis plus modéré… J'attends donc ton argumentation. Pourquoi c'était mal fait, quelle était la meilleur solution ?
      - [^] # Re: Est-ce au moins possible en théorie ?
        
        Posté par gouttegd le 05 juin 2012 à 17:18. Évalué à 5.
        
        Deuxièment peut être que ConsoleKit était nécessaire avec un init SysV mais passer à systemd permet de faire la chose plus proprement ?
        
        Peut-être… On n’en sait rien justement, vu que les développeurs n’ont pas cru utile d’expliquer quel était l’intérêt de ConsoleKit au juste. Que permet de faire ConsoleKit qu’on ne pouvait pas faire sans ? Ou que permet-il de faire de façon élégante ce qui nécessait d’affreux hacks auparavant ?
        
        Les sources de ConsoleKit ne contiennent pas le moindre renseignement utile de ce point de vue. On y trouve une description des notions manipulées (qu’est-ce qu’un « siège » ou une « session ») et la référence des objets DBus (probablement très utile sinon indispensable aux développeurs souhaitant utiliser ConsoleKit), mais pas le moindre indice sur ce que ConsoleKit fait concrètement (ou ce qu’il permet de faire). Il n’y a même pas une page de manuel (donc même si j’avais besoin de ConsoleKit, je ne saurai pas lui faire faire ce que je veux). Faut pas s’étonner après si certains ne voient pas l’intérêt du machin…
        
        PolicyKit au moins vient avec de la documentation, ce qui fait que j’en ai une opinion sensiblement meilleure.
        
        [^] # Re: Est-ce au moins possible en théorie ?
        
        Posté par gnumdk (site web personnel) le 05 juin 2012 à 18:06. Évalué à 4.
        
        https://wiki.archlinux.org/index.php/ConsoleKit
        
        Je sais c'est pas la doc officiel mais les gens de Arch just rocks ;)
        
        [^] # Re: Est-ce au moins possible en théorie ?
        
        Posté par ckyl le 05 juin 2012 à 20:44. Évalué à 2.
        
        Sérieusement… Quand j'ai eu besoin de fonctionnalités offertes par ConsoleKit:
        1. J'ai découvert que ça existait
        2. Que ça répondait à mon besoin, et que je sais pas comment faire aussi bien sans
        3. Que la doc est poucrave, mais que le fonctionnement général est facile à saisir et semble rationnel même si c'est un peu hackesque de reposer sur une variable d’environnement.
        4. Que l'API DBUS c'est ce qui t’intéresse, qu'elle est triviale et documenté et que tu peux faire ton job.
        
        Je suis pas fan de ConsoleKit. Je suis dev, j'ai pu utiliser leur truc, la doc est pourrie mais j'en fait de la pire qu'eux, ça répond à un besoin, ca fonctionne, j'ai pas de meilleure solution. Donc je me la ferme, plutôt que de passer mon temps à cracher sur tout. J'espère que vous êtes dev et que vos utilisateurs sont aussi méprisant envers vous.
        
        [^] # Re: Est-ce au moins possible en théorie ?
        
        Posté par Moonz le 06 juin 2012 à 09:52. Évalué à 3. Dernière modification le 06 juin 2012 à 09:55.
        
        J'espère que vous êtes dev et que vos utilisateurs sont aussi méprisant envers vous.
        
        Le problème de consolekit c’est qu’il vient m’embêter même si je ne veux pas de lui, pas qu’il ait des problèmes quand j’ai besoin de lui. Pour ça que même si je me moque un peu de PA, au final je n’ai pas grand chose contre lui : il est optionnel. Par contre, le ConsoleKit qui vient comme dépendance de base du successeur de HAL (dont j’ai oublié le nom), qui n’est pas désactivable sans péter des trucs de base, qui change de comportement d’une version à l’autre et qui vient m’interdire des trucs que je faisais très bien avant, merci mais je m’en serai bien passé.
      - [^] # Re: Est-ce au moins possible en théorie ?
        
        Posté par fleny68 le 05 juin 2012 à 20:34. Évalué à 5.
        
        ConsoleKit est un très bon exemple. Tellement indispensable qu'à peine arrivé il est déjà remplacé par autre chose Premièrement ConsoleKit aura été livré dans Fedora pendant 6 ans…
        
        Dans debian depuis 2007. L'ITP explique à quoi ça sert et surtout pourquoi c'est là:
        
        ConsoleKit is a system daemon for tracking what users are logged into the system and how they interact with the computer (e.g. which keyboard and mouse they use). It provides asynchronous notification via the system message bus. NOTE: this software will be packaged within the pkg-utopia team and is a requirement of hal-0.5.9
        
        Autrement dit, dans le monde merveilleux qui semble être à l'origine de tous ces trucs douteux, pour faire marcher HAL, le hardware abstraction Layer, il est indispensable d'avoir un daemon de gestion des utilisateurs connectés qui tourne. Les utilisateurs doivent faire partie du hardware, ça doit être ça.

Suivre le flux des commentaires

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