Salut Journal (huhu, subtil référence anticipée),
Lennart est bien connu pour avoir cassé votre réseau (avahi) et puis, de manière plus spectaculaire votre son (pulseaudio) avant de s'attaquer au boot de votre ordi (systemd).
Que lui reste-t-il à casser ? Pas mal de choses, heureusement, Lennart n'a pas décidé de s'arrêter. Sa prochaine victime ? Vos logs:
https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs&pli=1
Lennart introduit donc "Journal".
Journal, c'est le successeur de syslog. Enfin, pas tout à fait. Mais quand même. Bref, j'ai pas compris grand chose si ce n'est que c'est mieux, plus rapide, et que ça ne remplit pas des fichiers txt juste pour le plaisir.
# ce type il devrait arrêter de bosser su GNU/Linux
Posté par totof2000 . Évalué à 9.
Il devrait recréer son propre OS basé sur Linux : L'un des objectifs de GNU Linux était de réimplémenter un système Unix : là ce type s'éloigne de plus en plus des concepts Unix : ce n'est pas mal en soi, seulment il devrait l'assumer pleinement et créer une espèce de fork pour implémenter ses idées.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par vaceletm (site web personnel) . Évalué à 10.
Marrant quand les projets forkent, c'est souvent vécu comme un échec car il n'y a pas eu d'entente possible.
Là c'est l'inverse, tu veux pousser au crime^Wfork.
Ca ne sert à rien à Lennart de révolutionner tout seul dans son coin un truc qui ne sera utilisé que par trois geek compulsifs. Il veut pouvoir utiliser son OS préferé et le faire évoluer. Bref, il suit à la lettre les principes du logiciel libre !
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par ploum (site web personnel, Mastodon) . Évalué à 10.
En même temps, Lennart affirme haut et clair qu'il bosse sur Linux, et non pas sur un UNIX, et qu'il a cassé la compatibilité avec les autres UNIX.
Moi je suis tout à fait d'accord avec sa vision.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par VictorAche . Évalué à 7.
Et moi je bosse sur Linux, en tant que système POSIX, et ça me soûle qu'on massacre un UNIX.
"The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par GeneralZod . Évalué à 8.
Euh en quoi, c'est incompatible avec POSIX ou même Unix ?
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par inico (site web personnel) . Évalué à 4.
Android est bien pire niveau cassage de POSIX.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par barmic . Évalué à 6.
Android n'a pas vocation a exporter son modèle dans toutes les distributions, Google ne dénigre pas les distributions qui font des choix différents.
Personnellement j'en est rien à faire que Lennart ajoute à Fedora/RedHat des boites noires obscures ce qui me gène c'est que ça va se retrouver dans toutes les distributions (enfin il va falloir faire attention à sa distribution).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par manawy (site web personnel) . Évalué à 2.
Comme il le dit lui-même :
http://0pointer.de/blog/projects/systemd.html#faqs
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par barmic . Évalué à 8. Dernière modification le 20 novembre 2011 à 22:29.
Quand on lis l'interview de Lennart par patrick_g :
https://linuxfr.org/news/un-entretien-avec-lennart-poettering
On ne peut que constater le dédain qu'il a pour Debian et Ubuntu qui ne passent pas de manière aussi automatique à systemd qu'il ne l'aurait voulu. Qu'il tente d'être consensuel sur une FAQ sur le site de son employeur est une chose, mais j'ai tendance à croie qu'il a une parole plus libre lors d'interview.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par GeneralZod . Évalué à 3.
citation, parce que je ne vois aucun dédain vis à vis ni de Debian, ni d'Ubuntu (tout au plus, il note que depuis le départ de JSR, le projet n'avance plus du tout) dans la dite interview.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par barmic . Évalué à 8.
Expliquer que le travail de contributeurs Debian n'est qu'un jeu, c'est se foutre de leur gueule et ne pas respecter les différence qu'il y a entre une distribution communautaire comme Debian et une distribution managée par une société et qui a pour finalité d'être un produit qui vise à vendre du service avec.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
Et que dire des autres architecture que debian supportent ... qui souvent d'ailleurs bloque la sortie de la distribution.
L'aspect multi-arch et multi-OS permet d'être plus robuste avec des API claire, stable et identifié pour la plupart. Cela donne aussi du temps au temps. C'est parfois énervant mais c'est aussi important. Ceci dis, il ne faut pas non plus s'ankyloser, il y a un temps pour tout !
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par GeneralZod . Évalué à 5.
Il dit juste que Debian doit limiter les développements "accessoires" comme le port kFreeBSD du moins, ça ne doit pas freiner les autres. Même au sein de Debian, il y a des discussions pour savoir si certains ports ne devraient pas passer au second plan ou du moins ne plus bloquer les releases. Si on re-situe ça dans le contexte, il y a une discussion sur les listes debian pour savoir si debian allait passer à systemd par défaut ou non, et un des arguments contre était la non-portabilité sur le port kFreeBSD et Lennart suggérait que rien n'empêchait d'avoir que Debian/Linux et Debian/kFreeBSD aient un init différent.
Hein, il n'a jamais dit que le projet Debian était un jouet, à la limite le port kFreeBSD (qui est loin d'être aussi fonctionnelle qu'une vraie FreeBSD ou une Debian/Linux)
Fedora est une distribution communautaire, l'ensemble des décisions techniques relève uniquement du Fesco qui est un comité entièrement élu par les contributeurs actifs. Par ailleurs, Lennart est un cas particulier au sein de RH, il est relativement libre de choisir ses projets.
Dans le cas de systemd, c'est une initiative 100% personnelle, c'est une autre personne qui est en charge du démarrage dans l'équipe Base OS, et c'est arrivé juste après l'intégration d'upstart dans RHEL6 (imagine la gueule des personnes chargés de la maintenance et de la formation qui devront après RHEL7 gérer 3 inits complétement différents pendant un bon moment).
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par barmic . Évalué à 8.
C'est pas lui qui doit se tapper la maintenance de paquets qui auront deux manières de s'inscrire comme service.
Ce n'est pas en ajoutant systemd que ça va améliorer les choses. Ces ports ont, je trouve comme grande qualité de mettre le doigts sur la portabilité ou non des solutions. Si à la moindre difficulté on recule, ça perd, il me semble beaucoup de son intérêt.
Oui mais je m'en fou du mode de gouvernance de Fedora. C'est Lennart qui dit que Debian doit être, je cite, « professionnellement pertinent ».
C'est toujours sympas à entendre pour les contributeurs qui n'ont rien demandés.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par GeneralZod . Évalué à 5.
les unités systemd sont normalisées -bcp plus que les scripts sysV- donc très peu de travail en perspective. Systemd qui sait également lancer des scripts sysV gére très bien ça, quant à upstart bah il s'en fout des unités systemd.
En revanche les admins système te diront merci pour leur filer un init plus performant et plus robuste.
La plupart des solutions sont déjà disponibles dans FreeBSD
Et ? Debian est une distro très utilisé dans le monde professionnel, en accord avec son motto de "système universel". Si systemd est une avancée pour les utilisateurs de Debian, on va pas priver 99.99% des utilisateurs pour les 0.01% qui utilisent Debian/KFreeBSD (dont la plupart ne l'utilisent pas comme système principal ou en production).
Mis à part toi, ça n'a vexé personne, il dit juste que kFreeBSD est un hobby (ce qui est le cas pour la plupart des contributeurs) sans aucun jugement de valeur.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Etienne Bagnoud (site web personnel) . Évalué à 8.
Mais systemd est-il une avancée réelle ? Sur les serveurs je crois que le système init ne nécessite pas vraiment de remplacement : il fonctionne, il est simple et il n'y a pas vraiment besoin de démarrage en parallèle. Sur les machines personnelles, on se dirige vers l'utilisation de l'hibernation, donc le système redémarre une fois par mois.
Et, pour info, systemd est dans la branche testing de Debian, même si le projet n'en fait pas son init par défaut, il sera disponible pour celui qui le souhaite.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par nud . Évalué à 6.
Parfois les services sont un peu buggés et perdent des processus suite à des événements inattendus:
systemctl restart $service tue ces processus paumés, mais ce n'est généralement pas le cas du script d'init old-school associé au service, ou en tout cas ce n'est pas faisable de façon fiable sans modifier le démon en lui-même (et encore, un bug peut toujours arriver).
Le "cacheage" de ce qui est envoyé sur les sockets des démons qui sont en train de redémarrer ça peut aussi être vachement utile sur un serveur.
Donc tu as raison, on se fout de démarrer les services en parallèle, mais pour d'autres choses systemd ça peut être vraiment sympa.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par reno . Évalué à 3.
Mais n'est ce pas une fonctionnalité des cgroup plutôt?
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par nud . Évalué à 1.
Toutafé.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Etienne Bagnoud (site web personnel) . Évalué à 5.
Justement, c'est pas une fonctionnalité unique à systemd, mais bien une nouvelle fonctionnalité de Linux. Elle peut être utilisée avec init et, là où c'est intéressant, il est plus facile pour un administrateur de modifier un init classique pour avoir de nouvelles fonctionnalités de Linux. Par contre, pour systemd, il faut attendre qu'en upstream il intègre ça.
Je vois donc toujours un avantage pour init classique sur serveur.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Sur une machine de calcul, on utilise les CPUSET et les CGROUP pour tuer tout ce qui reste d'un job après que le walltime soit terminé. La problématique ici est la même donc comme dis ci-dessus, les CGROUP permettent de faire le boulot.
Sinon, le CACHE de socket, cela ne permet pas de mettre en cache les données pour le serveur syslog en attendant qu'il se lance ;-)
J'ai pas regarder systemd de près mais si c'est bien le processus PID=1 qui fait tout cela, ça craint ! J'espère qu'il se fork ou qu'il envoie des petits...
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
sysvinit sous debian gère le lancement parallèle des services. D'ailleurs, je crois que c'est une version qui provient à la base de Suse.
Sinon, comme dis dans un autre post, il y aussi la voie très intéressante qui avait été lancé avec runit (et socklog) sur des idées d'ailleurs à la base de D. J. Bernstein (daemontools)
http://smarden.org/runit/
L'idée de base semble dans le même esprit mais découpé en plein de petit programme faisant une et une seule chose... L'idée fondamentale est d'avoir un programme initial "/sbin/init" (PID=1) le plus petit possible ce qui me semble dans la logique même...
Je ne vois pas pourquoi les programmes "modernes" s'évertuent à vouloir par défaut être en mode serveur et à tout regrouper dans une seule instance ce qui est problématique en cas de plantage (iceweasel, geany...).
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par manawy (site web personnel) . Évalué à 2.
c'est son site personnel, pas celui de Red Hat. Il n y'a aucun lien de sponsorisation de RedHat ( comme sur le site de la libvirt par exemple) ou même de Fedora.
Bon, après je suis d'accord, avec toi, il y a forcément un lien, ne serait-ce qu'affectif qui lui fait préferer certaines distributions. Mais je ne trouve pas de trace de dédain dans l'interview, as-tu des passages particuliers en tête ?
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par JGO . Évalué à 2.
En quoi ses projets sont-ils plus des boites noires que ce qu'ils remplacent ? Si tu as le niveau pour comprendre les sources d'init ou de syslog, pourquoi ne t'en sortirais-tu pas aussi bien avec systemd ou journal ?
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par barmic . Évalué à 2.
Je pensais surtout à pulseaudio que je n'ai jamais réussi à configurer malgré l'installation de toutes les interfaces graphiques faites pour ça.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Sufflope (site web personnel) . Évalué à -3.
Change de distrib' pour une qui sait intégrer un logiciel, ou alors au pire qui évite de les intégrer (en gros, quitte Ubuntu).
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par barmic . Évalué à 3.
Non, je désinstalle tout mes paquets qui concernent pulseausdio et c'est terminé (oui moi je prend une distribution qui me donne le choix).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Sufflope (site web personnel) . Évalué à -2.
Je connais pas de distribution sur laquelle tu puisses pas faire gestionnaire_de_paquet remove --force ou équivalent, donc je comprends pas l'argument.
Ensuite, concernant pulseaudio... entre
suceursopensusiens ? chezquiçamarchefinir Upstartse préoccuper de ce genre de sotes-tâchesJe vois pas trop ce qu'il y a comme réelle autre catégorie.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par barmic . Évalué à 3.
Je ne sais pas ce que c'est une installation par défaut sur Debian. Je ne sais pas comment ça se passe ailleurs (et je m'en fout elles doivent faire ça très bien), mais moi quand j'ai finis mon installation j'ai pas de serveur graphique, pas de pulse audio, pas de navigateur etc.
Après si par défaut tu entends, quand on choisi d'installer une interface graphique alors peut être que c'est le cas (si Gnome le met en dépendance).
Mis à part ça c'est quoi le travail d'intégration ? Qu'est ce que chez Debian, ils n'auraient pas fait ou mal fait concrètement ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par gnumdk (site web personnel) . Évalué à 3.
Et chez Ubuntu... Parce que j'ai pas remarqué durant mes tests que pulseaudio était plus rapide/stable sous Fedora...
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par zebra3 . Évalué à 0.
Ben t'as pas de bol. Avec Debian sur quatre PC différents, un coup d'apt-get a suffi chez moi.
Ou alors tu es sous Ubuntu, mais ne viens pas cracher sur un produit qui marche chez les autres, plutôt sur les mainteneurs qui ne sont pas capables de faire leur travail correctement.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par barmic . Évalué à 7.
J'ai dis que c'était une boite noir que je n'ai jamais réussi à configurer.
Je ne vois vraiment pas pourquoi vous parlez tous d'intégration ou pas. Peut être que c'est excellent quand on vous fait le travail pour vous, bref que vous n'avez pas à le configurer, mais ça n'en est pas moins une boite noire complexe à prendre en main quand on cherche à mettre les mins dans le cambouis.
J'ai pas le droit de me faire mes bidouilles et de tenter de comprendre certains composants de mon système sans me faire traiter à tout va d'utilisateur d'ubuntu ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par gnumdk (site web personnel) . Évalué à 6.
Surtout qu'il faudrait que ce soit une insulte...
Mais bon, l'argument numéro 1 pour dire que pulseaudio c'est pas de la merde, c'est de cracher sur Ubuntu...
C'est un peu comme KDE4, les gars de Kubuntu n'ont pas réussi à mettre la pression sur les packages de ubuntu de xorg, résultat, ca plantait dans tous les sens... Mais je peux aussi comprendre les mainteneurs de xorg qui voulait pas voir ces patchs foutre la merde coté compiz..
Bref, beaucoup de gens qui crachent sur Ubuntu mais pas beaucoup de gens qui auraient les compétences pour bosser là bas...
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par zebra3 . Évalué à -1.
Disons que lorsque :
Bah au bout d'un moment, on finit par en vouloir à Ubuntu. C'est ce qu'on appelle un retour de flamme.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par gnumdk (site web personnel) . Évalué à 4.
Ben, moi j'étais sous Debian et j'avais les même merde que les gens sous Ubuntu, t'expliques cela comment ?
Tu les connais un peu au moins les problème qu'il y'a eu avec PA sous Ubuntu? Ou c'est juste ce que tu as lu dans "Jeune et Jolie".
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Kaane . Évalué à 9.
Disons que ça marche dans les conditions suivantes
a) Pulse audio fait un lock exclusif du périph Alsa. Tous les utilitaires qui veulent faire du bruit passent par padsp ou mieux par Gstreamer.
b) HAL, ConsoleKIT et DBus sont configurés à la sauce Fedora/Red Hat. Cette sauce n'est pas mauvaise, mais elle n'est pas nécessairement la panacée pour tous les utilisateurs.
c) Les corrections de skew ou de buffer doivent être prise en charge directement par le pilote Alsa ou par pulse-Audio lui même via GStreamer. Toute tentative d'intervention par un programme tiers risque de tout faire partir en sucette.
Donc fondamentalement quand on veut au choix, du JACK, du gapless (oui parceque GStreamer et le gapless...) de la synchro pointue, utiliser les clocks HPET etc. On sort forcément de la notice d'empaquettage de Lennart. (Bon généralement quand on veut un des trucs ci dessus on prend une distrib dans laquelle on peut gicler Pulse Audio facilement.)
Après le choix d'Ubuntu de mettre Pulse Audio tout en essayant de garder la compatibilité avec les fonctionnalités avancés du son sous Linux est discutable. Mais il n'est pas idiot. Pulse Audio a été conçu pour fonctionner dans un cas précis (utilisateur bureautique qui écoute du son en mode "loisir") et son utilisation dans à peu près tous les autres cas est problématique.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par briaeros007 . Évalué à 6.
euh PA je l'ai essayé au démarrage sur plusieurs distribs (debian entre autre, mais surtout pas ubuntu, etc...) et au début désolé mais ca marchait pas des masses (ca se lancait mais aucun son qui sortait).
C'est (était) comme avec network manager, pour les kikoo lol c'est génial, mais quand tu veux un système simple à administrer en cli, ben c'est un peu la merde quand même.
(et dans le cadre de network-manager, j'adore le fait de laisser les fichiers de conf, mais de ne pas les utiliser ...)
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par barmic . Évalué à 2.
C'est utilisé comme une insulte. Moi j'ai pas de problème avec les utilisateurs Ubuntu (ni d'aucune autre distribution d'ailleurs).
C'est précisément ce que je dis. Il me semble que tout le monde est très heureux de cliquer 3 fois sur suivant pour ensuite dire Pulseaudio ça déchire ça a telle et telle fonctionnalité (dont ils n'ont pas plus besoin hier qu'aujourd'hui) et se cantonne à dire que c'est plus ou moins bien intégré pour les utilisateurs où ça ne marche pas (mais encore personne ne m'a expliqué en quoi consiste l'intégration en pratique).
A l'occasion j'irais voir si la dernière LFS parle de pulseaudio peut être qu'ils expliquent comment se truc fonctionne.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par coïn . Évalué à -2.
posix, c'est mieux la norme morte qui n'évolue plus ?
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par totof2000 . Évalué à 4.
Une norme qui évolue tout les 4 matins et qui nécessite une réimplémentation complète n'est pas une norme, c'est juste n'importe quoi.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par zebra3 . Évalué à 5.
Il doit bien y avoir un juste milieu entre une norme qui évolue tous les quarante ans et tous les quatre matin, non ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par zebra3 . Évalué à 10.
J'espère que tu n'utilises jamais de fichiers plus gros que 2 Go, parce que ce n'est pas POSIX…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par imr . Évalué à 7.
Il a été un peu clair là dessus dans sa déclaration sur le fait qu'on ne devait pas se soucier de BSD: c'est ce qu'il fait déjà mais cet OS c'est linux. Et linux is not unix.
Il faut se rendre compte que l'employeur de lennart est redhat, que redhat a de gros clients et doit répondre à leurs attentes et demandes. Ils ne sont pas là pour faire plaisir aux gardiens du temple, ils sont là pour faire du pognon en servant leurs clients, donc s'il faut créer un nouveau système pour répondre à un besoin, ils le feront.
Il faut que les clients pensent que Linux is redhat enterprise linux.
Les éventuels problèmes sont ensuite tout bénéf: le monde des distros linux reste instable par rapport à rhel, en plus on transforme les concurrents en contributeur de redhat puisqu'ils intègrent les services en mode développement, on peut les traiter de mauvais citoyens du monde linux s'ils ne contribuent pas, (Ne pas oublier de ne jamais faire l'inverse et ne jamais inclure et ne jamais contribuer à une nouveauté développée par un concurrent) et maintenant, on isole un peu plus les BSD.
C'est gagnant-gagnant.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Laurent Mouillart . Évalué à 1.
Il faut voir aussi que Gnome ne se souçis pas trop d'autre chose que Linux, idem pour X.org au FBSD, NBSD, OBSD rament derrière. Les développeurs sont quasiment tous sous Linux.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par nud . Évalué à 3.
s/Gnome/RedHat/
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Laurent Mouillart . Évalué à -1.
Gnome 3.2 ou 3.0 fonctionne sous quel bsd et pas en current ?
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par nud . Évalué à 6.
Bon, je reformule.
Certes la plupart des devs de Gnome utilisent Linux, mais tous ne se contrefichent pas des autres plateformes, et la plupart essaient de pondre du code portable et de ne pas dépendre de trucs linux-only. D'ailleurs il y avait pas mal de devs issus de Sun qui travaillaient sous Solaris, mais je crois que Oracle les a (presque) tous virés.
Après tu as la masse des employés de RedHat qui a en fait plutôt intérêt que seul Linux soit supporté, et qui semblent parfois rendre les choses difficiles à dessein. C'est de ceux-là que vient cette idée crétine de "Gnome OS".
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Bapt (site web personnel) . Évalué à 3.
sous freebsd (pour 3.2) mais ça n'est pas encore dans les ports parce que la RELEASE 9 est imminente.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par zebra3 . Évalué à 1.
Ben t'es pas obligé de rester sous GNOME.
Tu peux même forker si tu veux. Mais si personne ne te suit, c'est que GNOME a fait le bon choix, celui de ses utilisateurs.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par reno . Évalué à 6.
Hum, hum si tu vas par là, alors celui qui fait les meilleurs choix c'est Microsoft car ils ont l'avantage du nombre..
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par zebra3 . Évalué à -1.
Je pense que ce n'est pas comparable, car si tu n'es pas content des produits Microsoft, tu ne peux pas les forker.
Si tu n'es pas content de GNOME, ben tu es libre de reprendre les sources, et si d'autres sont du même avis vous pouvez soit développer soit trouver un développeur. Si ça ne se fait pas, c'est que personne ne considère que ça en vaille la peine.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par reno . Évalué à 8.
Bah, non car changer pour un autre desktop a la place de GNOME demande beaucoup moins d'effort que de forker GNOME..
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par totof2000 . Évalué à 10.
Ils ne sont pas là pour faire plaisir aux gardiens du temple, ils sont là pour faire du pognon en servant leurs clients, donc s'il faut créer un nouveau système pour répondre à un besoin, ils le feront.
Ben justement les clients en entreprise n'aiment pas trop avoir des systèmes trop divergeants.
L'un des avantages de Linux est qu'il est suffisamment proche des Unix commerciaux et des standards Unix pour pouvoir être appréhendé rapidement par un admin Unix, et qu'un spécialiste "n'importe quel OS UNIX" peut se mettre rapidement à Linux.
Aujourd'hui on s'en éloigne de plus en plus et les divergences de Linux par rapport aux conceps Unix commencent à devenir gênant, il est de plus en plus difficile pour un admmin Unix de suivre les Linuxeries.
C'est gagnant-gagnant.
Je ne crois pas.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par imr . Évalué à 1.
Tu parles d'un client redhat?
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Jux (site web personnel) . Évalué à 9.
En même temps, il me semble que Lennart a quelques bons arguments concernant l'état des logs sur les systèmes Unix. Notamment sur la sécurité (c'est juste du texte, on ne peut pas faire confiance aux pid), sur le fait que c'est le bordel à parser parce que il n'y a pas de vrai format standard, que les timezones ne sont pas forcément indiquées, qu'on a 45 fichiers de logs, etc...
Enfin voilà, à priori, avoir des logs sous une forme un peu plus structuré faciliterait grandement la tâche des admins en permettant de simplifier l'écriture d'outils de monitoring. Si l'API de journal est bien foutue, ça peut donner des choses intéressantes. Je remarque qu'ils semble aussi garder le format texte (ce qui est une bonne chose), donc un grep continuera à fonctionner.
Il met aussi en avant le fait qu'un programme qui utilise le syslog standard verra son log dupliqué : une fois dans syslog et une fois dans Journal.
Je pense que le fait de casser la compatibilité est parfois nécessaire pour faire avancer les choses.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
J'ai pas compris son problème avec la sécurité. Tu envois tes log sur un serveur central qui est blindé...
Si effectivement, toute ton architecture est une passoire, les log ne serviront à rien.
Sinon, la souplesse d'UNIX est de faire des choses simples, souples et orthogonales. A force de trop vouloir normalisé, il va finir par trop contraindre l'ensemble qui n'arrivera pas à évoluer au cours du temps et devra être remplacer un jour par autre chose car il aura oublié de traiter un cas particulier.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Thomas Douillard . Évalué à 5.
La meilleure manière de tout changer est de rien changer ?
C'est un peu paradoxal comme phrase, genre "il est urgent d'attendre".
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Jux (site web personnel) . Évalué à 9.
Pour la sécurité, il dit
Traduction :
En gros, le problème de syslog semble être que c'est assez facile de falsifier les logs (pour cacher une intrusion, etc...). Comme Journal authentifie lui-même le processus qui log, ça résoud ce problème.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Alex . Évalué à 3.
Ben justement, tu peux envoyer n'importe quoi à ton serveur syslog, sans authent ni signature. Bizarrement si tu indiques une ip dans le message que tu lui envois, il indiquera celle-ci dans les logs plutôt que celle de ma machine émettrice, j'ai vu également des cas avec des injections de caractères d'échappement forçant l'émulateur de terminal à écrire des fichiers.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Kaane . Évalué à 4.
Et tu proposes quoi au juste en solution ? Parce que sans vouloir être méchant le moins du monde, ce type de problème d'absence d'authentification on les rencontre à tous les niveaux dans le cadre d'un réseau local. Au niveau ARP (poisonning), au niveau routage (Man in the middle), au niveau IP (spoofing) et enfin au niveau logique.
Même si le programme de Lennart fournit une véritable protection au niveau logique (ce dont très honnêtement je doute, à moins de faire IPSec/Kerberos c'est très difficile d’authentifier une machine de façon non trivialement contournable) pour que ça n'explose pas en deux lignes de scripts, il faudra de toute façon que l'admin réseau mette en place une politique de surveillance assez pointue pour éviter les débordements.
Un sysloger se doit de loguer ce qu'on lui envoie, il n'est pas là pour interpréter. Rien n'empêche (en fait c'est même recommandé) de loguer aussi le trafic réseau sensible. A partir de là les recoupements sont possibles.
Comme dans tous les autres programmes, surtout les programmes exécutés par root, des failles peuvent apparaître. Généralement elles sont corrigées assez vite.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Alex . Évalué à 1.
c'est vrai, il n'empêche qu'améliorer la sécurité me parait toujours une bonne idée. Ensuite signer ses messages si n'importe qui de branché sur ton switch est capable de les intercepter et de les faire disparaitre c'est plus que balo.
Néanmoins les attaques que tu donnes impliquent déjà un haut niveau d'accès, spammer le serveur de syslog non.
Alors evidement la signature et l'authentification ne garantissent pas une protection à toute épreuve, néanmoins compliquer la vie de l'attaquant et augmenter son niveau de confiance dans ton système de log me parait important
monter une petite pki, ou un système à la ssh n'est pas très complexe à mettre en oeuvre
Interpreter c'est justement ce que je lui reproche, de remplacer l'ip de l'émetteur par celle du message
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Kaane . Évalué à 5.
A moins que ton serveur de logs soit accessible depuis l'extérieur (et là il y a un vrai problème), le niveau d'accès dans tous les cas est le même : avoir accès à une machine sur la même branche réseau. Faire un poisonning ARP c'est une ligne de script.
Le truc c'est que la solution de Lennart va pas changer grand chose. A la limite, si j'ai envie de saturer/forcer une rotation sur un serveur de log chez quelqu'un, je n'ai qu'à ouvrir des milliers de connexions ssh par seconde et à les couper brutalement, ou à réclamer des milliers de pages web inexistantes sur un site. Et là j'ai même pas besoin d'être sur la même branche réseau. Suivant la sécurité du réseau ça passera ou pas.
En externe non, en interne (ie dans le programme de syslog lui même) je vois pas l’intérêt. Ca prend effectivement 10 secondes de dire à ton serveur de log de n'écouter qu'en lo0 et de dire aux demons distants de monter un tunnel ssh avant de loguer (pour peu que le démon distant en question soit démarré suffisamment tard). Maintenant Lennart invoque une solution en interne, donc soit ca s'appuie sur des systèmes connus (Kerberos, IPSec éventuellement SASL) dont il est client, soit il va falloir coder un service complet d'auth dans le syslog. Et très honnêtement un syslog qui possède son propre service PKI à maintenir et à mettre à jour ....
Bon maintenant Lennart veut que Journal s'appuie sur HAL, ConsoleKIT, SystemD (et donc DBus), un serveur de base de données (j'espère en no-sql parce que les logs c'est pas forcément très structuré), donc rajouter un système d'auth par dessus tout ça, ça doit pas lui faire peur. Ceci dit je serais quand même curieux de voir comment il compte loguer la phase 2 du boot et le dmesg (ou même un crash DBus tient).
Non, il reçoit un message qui possède un contenu dont une section "IP" avec une adresse. Lui il enregistre le message sans y toucher. La seule chose qui intéresse syslog c'est le numéro de processus, le reste tu fais ce que tu veux.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Alex . Évalué à 1.
Pardon, je parlais de syslog en géneral, je ne parlais plus de la "Journal" qui ne résoud en effet pas vraiment les problèmes soulevés
c'est aussi avoir obtenu les accès nécessaire sur la machine
Il ne touche pas le contenu du message, mais l'interprète tout de même: si tu ne renseignes pas d'ip, il prend celle de la connection. Je lui reproche de pas toujours avoir ce comportement...
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par nud . Évalué à 1.
C'est seulement vrai pour le support legacy des messages syslog il me semble. Pas pour les messages "journald".
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par briaeros007 . Évalué à 6.
Normalement c'est l'admin qui gère la machine qui va regarder les logs.
Tu veux mettre de la sécurité en plus, mais pour quoi faire? Etre sur que le pid qui émet ce message ets bien celui qui devrait l'émettre ?
Ca veux dire que tu as déjà un gros problème : un programme qui fonctionne qui se fait passer pour un autre!
Et ça, c'est pas un serveur de log plus sécurisé, c'est une machine mieux administrer qu'il faut.
La "sécurité" qu'un système de log a besoin, c'est la non réupudiation et la non modification.
Pas l'authentification forte de chaque appli.
En même temps c'est pas toujours la même appli qui émet les logs, et elle n'a pas forcément les mêmes besoins que celle juste à coté.
Tu vas parser suivant ce qu'émets tes applis.
Si je fous des paquets IPs dans la log, je vais pas m'attendre à avoir les mêmes champs que si je regarde des demandes d'authentification.
A nouveau, Tu es censé connaitre les machines que tu loggues (et j'espère avoir un parc un tant soit peu cohérent).
Et suivant les soft de serveurs de logs que tu utilises, tu peux les avoir.
Mauvais admin, changer d'admin.
Ca c'est un pur probleme d'administration, pas d'outils.
Tu créé les fichier comme tu le souhaite (perso chez moi c'est ////(.|)
Comme dis au dessus : "mauvais admin, changer d'admin".
Avec les serveurs de logs actuel (syslogng, rsyslog, ...) tu peux strutcturer tes logs, avoir des fonctions avancées, voir rajouter des informations par rapport au "syslog habituel" quand tu peux gérer ce qui tourne sur le client (par ce que mettre rsyslog sur un firewall matériel, amha, c'est plus dur ^^).
Sans compter que l'on parle de strucutre, mais certains serveurs de logs permettent d'utiliser des bases de données (mysql, ...) et donc relativement simple à "structurer" (en dynamique par une requêtes, ou simplement par des vues).
Parfois oui. Dans ce cas, les solutions existent déjà, sont fonctionnelles, et ne cassent pas la compatibilité avec les autres.
Donc absolument pas nécessaire.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Alex . Évalué à 1.
En même temps faire un peu de défense en profondeur, ça ne fait pas de mal. Surtout pour le forensic qui suivra l'attaque.
Et l'intégrité, ce qui inclut la non modification, mais également la validité des données. Si un attaquant te rempli ton syslog de n'importe quoi (ou plutôt d'infos sous son contrôle), ton log n'est plus intègre.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Anonyme . Évalué à 4.
Si un attaquant est capable de faire ça, à mon humble avis, le fait de te faire pourrir tes logs est le dernier de tes soucis !
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Alex . Évalué à 4.
N'importe qui est capable de faire ça, c'est bien le problème.
Accessoirement, je pense aussi à l'après attaque, quand il faudra procéder à l'analyse pour connaitre le pérmiètre de l'attaque et découvrir qui est l'attaquant.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par nud . Évalué à 4.
Encore faut-il pouvoir trouver des indices sur l'attaque en question. Maintenant on peut:
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par barmic . Évalué à 3.
Les logs servent aussi à étudier une attaque post-mortem.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par briaeros007 . Évalué à 2.
Je me suis mal exprimé : je suis pour , mais pas au détriment de la compatibilité.
Que le rsyslog/... ait un champ en plus, spécifique, ou il indique par ex le pid et le chemin vers l'exe qui tourne oui, mais en plus.
Et puis, on prend quoi pour assurer la sécu, le pid ? le lwp ? le contexte selinux ? ...
On fait une liste blanche des programmes qui ont le droit d'utiliser syslog ? on fait juste une indication dans le log ?
D'où l'intérêt que ce soit des champs en plus , et configurable.
Sachant toujours que ce n'est pas du tout une sécurité absolue (si un process est exploité, tous les messages d'erreurs seront envoyé avec un pid "qui semble correcte").
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Alex . Évalué à 2.
En fait je ne pensais pas spécifiquement au pid, mais également à l'envoi de syslog sur le réseau, le filtrage des caractères d'échappement, etc...
Bien sur on peut cumuler les couches pour avoir une sécurité correcte (par ex utilisé ipsec par exemple pour authentifié les machines émettrices), mais je pense que c'est tout de même mieu si le service gère cela par lui même.
C'est en effet problématique, casser la compatibilité pose toujours des problèmes dans les périodes de transitions. Mais AMHA, c'est surtout d'avoir un consensus ou une norme. Casser la compatibilité pour un truc nouveau, mais qui serait normé et utilisé par tout les unix me gênerait pas, avoir quelque chose spécifique qui n'est géré que par un OS (soit il aussi répandu que linux) me pose plus de problème.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par patrick_g (site web personnel) . Évalué à 4.
Quand Fedora passera à btrfs par défaut est-ce que tu abandonnera ta théorie ?
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par imr . Évalué à 3.
Je pensais plutôt desktop.
Pour que les choses soient claires: je cherche du sens dans cette manière de développer à l'emporte pièce des morceaux du desktop, de les intégrer sur le desktop alors qu'elles ne sont pas prêtes puis de pourrir les utilisateurs qui se plaignent, ensemble qui repousse pas mal d'utilisateurs loin de linux.
Donc j'en suis venu à imaginer une théorie ou ce n'était pas de l'incompétence mais de la malice. Mais je mettrais rien à couper quant à sa validité.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par patrick_g (site web personnel) . Évalué à 10.
A mon avis c'est simplement que les devs Fedora prennent au pied de la lettre le fait d'être "cutting edge". Si tu regardes les buts de la distro sur leur site tu peux lire ça:
Donc ils n'ont pas peur de changer des sous-systèmes importants, et ce au risque d'une instabilité initiale. Ils est évident que ça sert les objectifs de Red Hat d'avoir un tel banc d'essai...mais c'est le jeu et c'est pour ça qu'ils financent Fedora après tout. Les utilisateurs de cette distro le savent parfaitement.
Quand au "mode de fonctionnement" de Lennart et ses éventuels problèmes relationnels je trouve qu'il s'est bien amélioré depuis l'époque PulseAudio. Le projet systemd a été, amha, remarquablement mené jusqu'à présent.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
C'est vrai que Fedora ne s'est jamais cassé de cet état de fait. Ubuntu aussi fournit des éléments instables et expérimentaux (Unity et bien d'autres), la finalité est bien moins transparente que Fedora.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par imr . Évalué à 2.
Oui, j'ai eu cette impression aussi.
Reste à voir s'ils ont écouté l'aval du projet, soit parce que c'est ce qu'il faut faire (avec pulseaudio, c'aurait été les utilisateurs desktop et donc leur matos), soit parce ce que ce sont des admins de grands comptes. J'espère sincèrement que c'est la première option, j'ai rien contre lui personnellement.
Oui, mais là, par rapport à ma théorie du complot, ça revient à se demander pourquoi c'est comme ça alors même que c'est contradictoire.
Quand tu repousses les utilisateurs par un ensemble de logiciels dont un des pans est toujours en développement, tu est pas vraiment more powerful, flexible, and useful for millions of people . Tu te fais ton petit plaisir dans ton coin et les millions d'utilisateurs passent leur chemin et retourne dans le proprio.
Reste que le syndrome NIH est très fort chez rh, et si c'est pas une stratégie, c'est encore plus triste.
Si je regarde leur attitude par rapport à ubuntu, une distro que je n'utilise pas et pour laquelle je n'ai pas d'affinité, je vois exactement le même comportement d'isolation qu'ils ont (eu) avec les autres, or canonical aussi a essayé de faire du hard work of creating new technical features makes free software more powerful, flexible, and useful for millions of people. We don't mind shaking up the status quo Donc pourquoi ne jamais reprendre quoi que ce soit qui vienne d'eux tout en toujours insistant sur le fait que rien ne vient d'eux, qu'ils ne contribuent jamais rien?
Donc stratégie ou NIH?
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par patrick_g (site web personnel) . Évalué à 5.
Hypothèse à la con de ma part (en vérité je n'en sais rien tu tout) mais est-ce que le fait qu'on doive filer le copyright à Canonical quand on contribue n'a pas refroidi les autres distros ? Après tout on est à la merci d'un changement de licence si le copyright n'est pas dilué.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par imr . Évalué à 4.
Tu veux dire que leur attitude a changé quand la politique sur les copyright de canonical est apparue?
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Sufflope (site web personnel) . Évalué à 3.
On peut aussi parler d'Upstart, la révolution de l'init par Canonical, tout juste entamé histoire de pouvoir lire les fichiers SysVInit, puis totalement abandonné une fois que les autres distros (dont Fedora) l'avaient adopté, en croyant aux promesses de Canonical.
Après on s'étonne que Mark se prenne des gros vents.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par imr . Évalué à 3.
puis totalement abandonné
ubuntu a laissé tombé upstart quand? (je demande, ça m'évitera de redire des conneries).
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par GeneralZod . Évalué à 7.
La promesse initiale d'Upstart était de proposer un framework évenementiel de gestion de services, et 3 ans plus tard, ça ne faisait pas plus que l'init sysV traditionnel en peu plus fiable.
Au moment où Lennart a commensé à s'intéresser au problème, le mainteneur (James Scott Remnant) était affecté à d'autres tâches (entre autre la LTS 10.04) depuis un bon bout de temps, et Canonical refusait (refuse encore ?) de partager la maintenance du projet (ce qui va bien au-delà de la simple problématique d'assignation de copyright).
Début 2010: tu as un Upstart qui stagne au niveau fonctionnel, un projet complétement verrouillé par Canonical (qui n'a jamais abandonné la maintenance corrective soit-dit en passant), et Lennart qui arrive avec pleins de bonnes idées (qui pour la plupart, sont bien accueilli par JSR). C'est même la raison pour laquelle systemd n'exige aucune assignation de copyright et que Lennart a cherché très tôt dans le projet à fédérer des gens d'autres distros (entre autre openSUSE).
http://netsplit.com/2010/04/30/on-systemd/
http://netsplit.com/2010/05/27/dependency-based-event-based-init-daemons-and-launchd/
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par imr . Évalué à 4.
Je viens de vérifier, upstart c'est 2007, le changement de politique quant aux copyrights, c'est 2009. On trouve des traces de gens intéressés par augmenter le boot et utiliser upstart autour de 2007, un stagiaire redhat l'intègre autour de 2008, mais pas grand chose n'est fait.
Ca semble plus un manque d'intérêt pour le problème qu'une réelle politique de boycott puisque le projet a été envisagé puis arrété sans vraiment de justifications.
Tu as surement raison, j'ai eu tort d'y voir de la malice et du machiavélisme.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par imr . Évalué à 4.
oops, j'avais mal lu la phrase Upstart is the default init system from Fedora 9 onwards. sur le wiki fedora donc i stand doublement corrected. fedora a bien intégré des technos ubuntu, et je suis un parano con-firmé.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par GeneralZod . Évalué à 2.
Si tu te réfères à la proposition de fonctionnalité, Casey Dahlin a fait son stage été 2007, il avait déjà été embauché par Red Hat à l'époque de l'intégration d'Upstart dans Fedora 9.
Par ailleurs, le changement d'init était planifié bien avant l'arrivée de Casey sous la supervision d'Harald Hoyer en charge du démarrage chez Red Hat.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Frank-N-Furter . Évalué à 3.
Cock-up before conspiracy, si tu ne veux pas à terme, te transformer en sam wang.
Depending on the time of day, the French go either way.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Misc (site web personnel) . Évalué à 10.
Ce qui est amusant, c'est que personne n'a trollé quand kde a sorti arts au lieu de esd, quand on a mis alsa au lieu de oss, quand gentoo a pris un systéme différent ( tout comme osx, solaris et ubuntu qui ont chacun un systéme de boot différent d'un bete init ) et la, proposer un systéme à part de log pour des besoins non couverts par syslog, ça choque tout le monde. Personne n'a ralé sur les distros d'avoir poussé shorewall, ufw ou d'autres alors que c'est des outils hautement linux spécifique. Personne n'a ralé quand FreeBSD a ajouté des APIs non présentes dans linux à l'époque genre kqueue. Personne n'a jamais rien dit à nvidia ou flash d'avoir oublié les BSDs.
Sauf erreur de ma part, Red Hat a quand même intégré Network Manager, qui est un projet lancé par novell à la base. Ils ont mis upstart sur RHEL, qui est un projet Canonical. Des projets comme libvirt ou deltacloud s'intégrent avec les offres de virtualisation de tous, comme vmware ou citrix. Et des efforts ont été fait pour mettre btrfs dans Fedora, sachant que le projet est poussé par Oracle. Des contres exemples d'intégration avec des projets fait par des boites concurentes, il y en a à la pelle.
Ce qui isole les BSDs, c'est bien le fait que relativement personne ne les utilise, pas le fait que d'autres travaillent sur Linux. C'est le fait qu'ils ont choisi une license ne forcant pas Apple à contribuer en retour, le fait d'avoir pris un procés dans les années 90, le fait d'avoir une communauté en france qui se déplacent vachement moins souvent ( depuis que theo a réussi à se facher , à tort ou à raison, avec le plus visible des supporters d'openbsd, on ne voit la communauté BSD quasiment plus , sauf le gcu à SL ).
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par VictorAche . Évalué à 8.
On vit pas sur la même île... Ici bas j'ai entendu des gens râler pour environ tout ce que tu cites :) .
"The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Misc (site web personnel) . Évalué à 1.
Pas pour les mêmes raisons. J'ai pas vu grand monde dire à Ubuntu "mais ufw, c'est pas portable sur les BSDs". j'ai pas vu des gens dire "faudrait reprendre iptable sur openbsd pour avoir un truc commun avec linux".
Et les gens en général étaient content d'avoir un système différent pour gentoo, car plus propre et plus aut niveau que sysv init ( genre, un truc qui gère les dépendances, et qui évite le copier coller et le boilerplate ).
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Fabien . Évalué à 4.
très mauvais exemple, l'inverse serait plus pertinent.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par gnumdk (site web personnel) . Évalué à 4.
Pour info, Nvidia supporte depuis le début FreeBSD ;)
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par FreeB5D . Évalué à 0.
Sauf pour l'amd64.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Pinaraf . Évalué à 5.
1) Les pilotes sont disponibles maintenant (et ce depuis fin 2009)
2) Ils avaient a priori des raisons techniques pour cela, et les ont listées : http://wiki.freebsd.org/NvidiaFeatureRequests
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par FreeB5D . Évalué à 1.
Donc tu réponds à côté (mais sinon je suis d'accord avec ton commentaire).
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par gnumdk (site web personnel) . Évalué à 1.
Euh, le 64 bits en 1999, ca n'existait pas, donc oui depuis le début...
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Tonton Th (Mastodon) . Évalué à 4.
Le DEC Alpha est sorti en 1992, hein...
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par gnumdk (site web personnel) . Évalué à 2.
C'est marrant, quand j'ai écrit ca, j'étais sur qu'il y allait avoir un boulet pour me répondre ca :p
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par M . Évalué à 2.
Ou alors on devrait avoir une distro qui reste dans la tradition UNIX [1].
Il y a bien slackware, mais bon il y a pas de package manager digne de ce nom...
[1] dans la liste on peux virer dbus, selinux, ...
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par Misc (site web personnel) . Évalué à 6.
En même temps, dans la tradition unix, y a pas de packages managers.
Avec la vague d'intégration d'outil si contraire aux demandes des unixiens, pourquoi est ce que slackare n'a pas un regain d'intêret ? ( ou les BSDs, d'ailleurs, qui sont plus proche d'unix que ne le sera jamais une distribution Linux )
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par reno . Évalué à 6.
Sauf que Linux n'est pas seulement GNU, c'est aussi Android, GoboLinux (qui a une hiérarchie de fichier plus claire: /Programs /Users /System /Files /Mount /Depot), NixOS (une distribution avec un gestionnaire de paquet "purement fonctionnel").
Si tu n'aimes pas les innovations apportées par Lennart, c'est simple: utilise une distribution qui ne les utilise pas..
# c'est lumineux
Posté par ashgan . Évalué à 5.
c'est vrai quoi, on peut même pas stocker un binaire à la place de bonnes vieilles lignes de texte dans les logs, c'est inadmissible!
[^] # Re: c'est lumineux
Posté par Kaane . Évalué à 1.
Euh, les syslogers que je connais peuvent tous stocker des binaires. Très pratique pour loguer des tcpdump, des tickets kerberos, des graphs rrdtools ou des emails suspects.
[^] # Re: c'est lumineux
Posté par zebra3 . Évalué à 1.
En même temps, on pouvait déjà le faire avant avec MySQL, personne ne s'est jamais plaint.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# éparpillement
Posté par Psychofox (Mastodon) . Évalué à 10.
Je n'ai rien contre trouver des solutions alternatives, mais j'ai l'impression que le père Lennart s'éparpille beaucoup.
À force de vouloir toucher à tout et révolutionner chaque brique du système, on n'obtient que des outils bâclés qui marchotent. Ne ferait-il pas mieux de se concentrer sur une seule de ces briques et de la faire bien ? Où alors ne faire que du conceptuel et ne pas s'occuper du code en lui-même ?
[^] # Re: éparpillement
Posté par claudex . Évalué à 3.
Je crois que c'est ce qu'il essaye de faire. Seulement, pour montrer ses idées, il commence le boulot (après, on dirait que pas grand monde le suit).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: éparpillement
Posté par GeneralZod . Évalué à 10.
C'est tellement plus facile de troller que de coder ...
J'attends le jour où quelqu'un décidera à clasher Lennart frontalement sur son terrain: le code. Pour le moment, personne n'a essayé de coder une alternative ou d'améliorer l'existant face à Avahi/PulseAudio/systemd, par contre des crétins qui hurlent "comprends rien à *nix/POSIX çui-là", "y fait pas du code propre bien architecturé", "c'est pourri ce qu'y fait" y en a plein. Ça n'a pas empêché les softs cités d'être très utilisés (et même appréciés).
If you don't like it, Just code.
[^] # Re: éparpillement
Posté par claudex . Évalué à 10.
On peut aussi ne pas l'utiliser. C'est ce que je fais (je n'ai ni avahi, ni pulseaudio, ni systemd d'installé) et je reproche aux distributions d'utiliser les softs de Lennart sans donner l'impression qu'elles maîtrisent ces softs.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: éparpillement
Posté par FreeB5D . Évalué à 3.
[troll inside]
[^] # Re: éparpillement
Posté par cedric . Évalué à 2.
Quand un logiciel libre demarre bien et que tu as une communaute active qui contribue, le mainteneur peut se concentrer juste sur les morceaux les plus difficiles ou meme faire que du merge de patch. A un point, il peut meme passer la main a quelqu'un d'autre. Regarde Git et Linus ! Je pense que Lennart reussi tres bien a creer une communaute autour de ces creations et que cela l'aide a ne pas trop s'epparpiller !
[^] # Re: éparpillement
Posté par zebra3 . Évalué à -1.
Bah pour l'instant, tout ce qu'il a fait semble bien marcher (sauf sur Ubuntu). Pourquoi ça serait différent ici ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: éparpillement
Posté par MrBidon . Évalué à 3.
Toi, tu n'as pas connu les début de pulse audio ?
[^] # Re: éparpillement
Posté par zebra3 . Évalué à 1.
Presque, je m'en sers depuis qu'il est empaquetté sous Debian (c'est-à-dire depuis la 0.9.4, si mes souvenirs sont bons).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: éparpillement
Posté par gnumdk (site web personnel) . Évalué à 2.
Ah ok, si t'appelle cela fonctionner, alors il a toujours fonctionné sous Ubuntu...
Quand il est arrivé dans Debian SID, j'ai testé, j'ai vu comment ca ramait, j'ai supprimé.
[^] # Re: éparpillement
Posté par zebra3 . Évalué à 2.
Ben j'ai testé, ça marchait, j'ai gardé. Et je n'ai pas testé que sur un PC.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: éparpillement
Posté par MrBidon . Évalué à 2.
Pour ma part, je me suis retrouvé sans son un bon mois pour me résigner à repasser sur Alsa (à l'époque j'utilisais Debian SID), et effectivement, j'ai été surpris de voir que la chose marchait bien lorsque je suis passé sur Ubuntu.
# Une idée inspirée par Apple ?
Posté par davandg . Évalué à 10.
Faire deux outils révolutionnaires liés entre eux, c'est lumineux !
[^] # Re: Une idée inspirée par Apple ?
Posté par feth . Évalué à 10.
# systemd
Posté par imr . Évalué à 10.
Quelqu'un a des problèmes avec systemd?
La distro que j'utilise vient de passer à systemd. Ca m'avait un peu effrayé à cause du fiasco pulseaudio et un peu énervé parce que c'est une distro plutot conservatrice qui ne change pas des sous systèmes du jour au lendemain histoire d'être en pointe, transformant ses utilisateurs en bétas testeurs (et je l'utilise notamment pour cette raison), et bien ça juste marche et la syntaxe précédente est respectée.
Donc est ce qu'on critique systemd simplement parce que c'est nouveau, simplement parce que c'est lennart, simplement à cause de ses déclarations, ou est ce qu'il y a vraiment des problèmes d'usage avec systemd?
En ce qui concerne le journald, il précise dans la FAQ que les problèmes du design et ses manques éventuels peuvent leur être rapportés:
[^] # Re: systemd
Posté par ploum (site web personnel, Mastodon) . Évalué à 10.
Perso, je suis fan de ce que fait Lennart. Y compris Pulseaudio.
On peut dire ce qu'on veut, mais Pulseaudio ça marche super bien. Avant cela, le son sous Linux était un enfer (ALSA/OSS, ESD/ARTS). Le problème c'est que, en introduisant Pulseaudio, beaucoup d'utilisateurs ont eu des problèmes à cause de drivers et de hardware mal foutus, dont les problèmes étaient contournés par de bons gros hacks bien dégueulasses dans ALSA.
Et les gens ont rendu Lennart responsables de leur déboires car il refusait de résoudre ces problèmes dans Pulseaudio (et il avait raison).
Au final, pour un ou deux ans de plaintes, l'écosystem Linux a grandement profité de Pulseaudio. Pulseaudio est vu maintenant comme un avantage majeur des systèmes Linux.
Bref, Lennart a la bonne vision, il a la capacité d'écrire le bon code et il a la capacité de motiver les contributeurs (Avahi et Pulseaudio ont leur propre communauté à laquelle Lennart ne participe presque plus. Systemd est en bonne voie de suivre le même chemin).
Mais il a le malheur d'être toujours en peu trop tôt tout en étant peu diplomate mais ne nous y trompons pas, son apport au monde Linux est gigantesque !
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: systemd
Posté par bubar🦥 (Mastodon) . Évalué à 9.
(globalement d'accord), mais :
Oui mais ça n'enlève pas les problèmes de pulseaudio lui même.
-> censé être simple (ha ouhai ? heureusement qu'il y a les gui, sinon c'est imbitable, je préfère me taper la conf de dmix à la main !)
-> censé être léger (oula, ça n'a jamais été le cas, et cela ne le sera jamais, visiblement)
-> censé être performant (des lags pas possible sans encore présents aujourd'hui, malgrès des confs par défaut aux petits ognions dans Fedora [cgroups, rtkit])
Bref qu'il y ai des problèmes avec les drivers et certains matériels que PulseAudio a permis de lever, certes. Et qu'il y ai des mélanges entre la cause réelle et l'accusation envers PA, certes aussi. Mais cela ne refait pas l'histoire : pour mixer trois pauvres flux, PA a pris longtemps beaucoup de ressources cpu. Et encore aujourd'hui je t'invite à faire le test simple de l'autonomie : deux sources simultanées, sur un laptop sans fonction veille. Autonomie avec et sans PA.
Ouhai, et c'est vraiment confortable aujourd'hui. Encore une fois grace aux gui (Gnome3 est remarquable sur ce point)
+1
Et d'accord pour dire que les critiques envers PA sont aujourd'hui souvent seulement des trolls. Un peu comme ceux à l'égard des designers de Gnome3 (qui ont fait un boulot fantastique. Bref, c'est bien, mais pas fanboïsme.
[^] # Re: systemd
Posté par imr . Évalué à 10.
Personnellement, ce n'est pas cette partie que j'avais critiquée dans pulseaudio, le coté apport important à un manque du desktop ou le fait qu'à terme ça marcherait et ça rendrait service, mais la manière dont ça a été développé et implémenté.
J'avais la chance d'utiliser à l'époque une distro dont un des contributeurs s'était pris d'amour pour pulseaudio donc le bouzin était très bien intégré. Et ça juste marchait chez moi. Mais pas mal de monde ont commencé à se plaindre que ça ne marchait pas. La réaction de Lennart a alors été de les pourrir et de raconter que:
1/ ils utilisaient des chipset obscurs qu'il ne pouvait pas tout tester, il fallait rapporter les bugs des chipsets obscurs. Donc c'ets la faute aux users.
2/ c'était la faute à leur distro qui avait mal intégré le bouzin, ubuntu c'est mal.
3/ c'est la faute aux applis qui gèrent mal le son
4/ c'est la faute à alsa qui est mal conçue
5/ je suis un génie, donc ça marche, mouhahahaha!
Le problème c'est que:
1/ une recherche de 10 mns avait montré que le chipset obscur était utilisé par 35 à 50% des desktop (source: la base hardware de steam, dispo publiquement sur le web)
2/ il y avait les meme problème chez mandriva qui intégrait bien le bouzin
3/ il répondait ça à des problèmes qui venait de 1/
4/ il répondait ça à des problèmes qui venait de 1/
5/ ça marche pas chez 50% des gens donc c'est pas un génie.
Au final, si tu ne contribuais pas à pulseaudio parce que c'était mal conçu et tu ne l'intégrais pas dans ta distro, tu étais un mauvais citoyen, mais lennart qui préfère recréer un nouveau système que contribuer à alsa parce que c'était mal conçu avait super raison.
Tellement raison qu'il n'a pas eu besoin de tester son bouzin sur le matos le plus répandu avant de le lacher dans la nature.
Et quand une distro implémentait le bouzin, si ça ne marchait pas, c'était sa faute, on n'implémente pas un système en développement sur un desktop stable.
C'est pas un manque de diplomatie, c'est un projet mal géré et de l'hypocrisie intellectuelle pour le cacher et reporter la faute sur les autres. Et c'est ça qui était reproché à pulseaudio, cette mauvaise gestion du scope du projet, pas le fait que c'était utile ou nécessaire. Ca, c'était une attaque à l'épouvantail qui était faite contre ceux qui se plaignait, et ça a participé au problème que pulseaudio a représenté.
On ne peut pas, d'un coté avoir des desktop libres où on demande aux utilisateurs d'être plus que des utilisateurs et de participer, et de l'autre les prendre pour des cons, leur raconter des craques et rejeter les problèmes sur eux dès qu'on fait une connerie comme sur certains desktops proprios où les problèmes de sécurité, par exemple, c'est la faute aux utilisateurs mais jamais à la conception du système au départ.
[^] # Re: systemd
Posté par ploum (site web personnel, Mastodon) . Évalué à -9.
Tu sais combien de personnes avaient des problèmes de son avec ALSA/ESD et tout le toutim? Presque 100%. (et jouer de la musique dans Rhythmbox en même temps qu'une vidéo Youtube était impossible)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: systemd
Posté par imr . Évalué à 6.
Tu fais la même chose, tu me réponds sur l'utilité à terme de pulseaudio alors que je ne parlais pas de ça.
[^] # Re: systemd
Posté par Adrien . Évalué à 10.
c'est un peu merdique comme argument : la situation a évolué en dehors de PulseAudio aussi.
Perso j'utilise KDE sans pulseaudio il me semble, je n'ai strictement aucun problème de son et je n'ai pas l'impression d'être à la traîne…
Une des grosses critiques aussi était de négliger les BSD, pour moi c'est un peu problématique, la politique « t'es petit, t'es différent, va chier » est vraiment minable, mais bon chacun ses idées et idéaux.
[^] # Re: systemd
Posté par patrick_g (site web personnel) . Évalué à 3. Dernière modification le 19 novembre 2011 à 18:28.
Il me semble que c'est plutôt : "Prévoir la compatibilité avec tous les OS aurait pour conséquence de trop complexifier le code car ces OS ne possèdent pas les fonctions spécifiques de Linux. Mais le projet est libre alors faites ce que vous voulez (étudiez-le, forkez-le, etc)."
Pourquoi est-ce que serait à Lennart de faire le boulot et à planter des tonnes de ifdef dans le code ? Les devs BSD, si ils sont intéressés par un truc, peuvent parfaitement écrire et maintenir une couche de compatibilité (comme par exemple dans la séparation qui existe entre le OpenSSH "pur" d'OpenBSD et la version portable d'OpenSSH).
[^] # Re: systemd
Posté par claudex . Évalué à 4.
Pourquoi a-t'il mal architecturer son code pour qu'il faille mettre des #ifdef partout plutôt que mettre ça dans des fichiers ou des fonctions différentes?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: systemd
Posté par patrick_g (site web personnel) . Évalué à 5.
Au contraire, selon Lennart il a bien architecturé son code pour exploiter à fond tous les mécanismes d'un noyau Linux moderne et ainsi avoir un code plus compact, plus fiable et plus lisible.
Son explication dans la FAQ systemd est la suivante:
Will this run on [insert non-Linux OS here]?
[^] # Re: systemd
Posté par navaati . Évalué à 3.
D'ailleurs, faut voir que systemd c'est deux choses : un soft et une "API", celle qui permet aux daemons de s'appuyer sur lui pour créer les sockets (on peut aussi inclure dans l'API les fichiers de config).
Et rien n'empêche les autres OS de faire leur implémentation d'un soft d'init "systemd compatible", non portable car utilisant les fonctionnalités spécifiques et super cool de leur noyau.
Et ça, ça serait vraiment cool je trouve.
[^] # Re: systemd
Posté par totof2000 . Évalué à 2.
Si c'est bien ça, il a bien bossé.
[^] # Re: systemd
Posté par gnumdk (site web personnel) . Évalué à 9.
Tu fais bien de le préciser, j'ai utiliser pulseaudio avec KDE pendant deux semaines, au bout du 5ieme segfault du process pulseaudio, j'ai laché l'affaire...
Ca fait bizarre en plus du coup quand ton lecteur audio préféré joue plus de son parce que tu penses que c'est lui qui fout la merde... Et au bout d'une demi heure, tu vois que ca fonctionne plus avec VLC et là tu te dis: "Je l'ai toujours dit que c'est de la merde en boite ce truc"
[^] # Re: systemd
Posté par Misc (site web personnel) . Évalué à 2.
Donc, avec 5 segfault, tu as bien du faire un rapport de bug aupré de ton distributeur de paquet ?
[^] # Re: systemd
Posté par gnumdk (site web personnel) . Évalué à 7.
Euh, pour quoi faire ?
Je serais sous GNOME, oui je l'aurais fait vu que no choice, mais sous KDE, j'ai tout simplement viré pulseaudio vu que au final, à part une impression de ramage, c'est tout ce que cela m'apportait.
[^] # PulseAudio et Gnome
Posté par Arthur Accroc . Évalué à 10.
La dépendance de Gnome à PulseAudio était un peu gênante avant Gnome 3.
La solution de rendre Gnome inutilisable à fait que ce n’est plus un soucis...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: systemd
Posté par Olivier Serve (site web personnel) . Évalué à 8.
Ou alors, simplement, tu vires pulseaudio et tout marche bien.
Franchement, je n'ai jamais vu l'intérêt ; ALSA a toujours très bien marché tout seul chez moi.
[^] # Re: systemd
Posté par nud . Évalué à 8.
Bien sûr que si, avec dmix.
[^] # Re: systemd
Posté par Hank Lords . Évalué à 5.
Je ne comprends pourquoi tu dis ça, je n'ai pas pulseaudio installé (ce n'est pas un choix, je ne l'ai juste jamais installé). Avec un pc "debase" je n'ai pas de problème se son, je peux lancer une vidéo youtube en même temps que le lecteur de musique sans tout crasher.
En fait je ne vois pas vraiment à quoi sert pulseaudio, perso je n'en ai pas besoin (ou alors je n'en suit pas conscient...).
[^] # Re: systemd
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Idem, je ne sais pas vraiment comment marche le son sur mon PC mais je ne vois aucun truc en puseaudio. Je précise qu'il y a toujours 2 sessions en // par deux utilisateurs différents. J'ai rien modifié, tout marche tout seul (Debian Squeeze).
[^] # Re: systemd
Posté par ecyrbe . Évalué à 5.
PulseAudio sert à gérer le son application par application, de partager du matériel audio, d'envoyer/recevoir du son en réseau ou Bluetooth comme un périphérique bloc, de mixer autant de flux que l'on souhaite etc...
Un truc sympa, ça permet de baisser le son de la musique quand t'as un appel en téléphonique intégré à ton desktop.
Bref, un tas de trucs impossible en hardware. Ça m'est utile tous les jours.
[^] # Re: systemd
Posté par gnumdk (site web personnel) . Évalué à 4.
Oui, sauf que ca n'importe quel soft sait le faire, il suffisait de faire un standard dbus pour gérer ce genre de chose... (genre, coucou les amis autres logiciel, je vous demande de vous taire).
La seul truc que je vois dans pulseaudio, c'est la partie bluetooth et réseau...
Après, il ne rame plus mais par contre, chez moi sous Arch et Kubuntu, ca segfault méchant...
[^] # Re: systemd
Posté par yellowiscool . Évalué à 4.
C'est tellement plus simple de patcher tout les logiciels utilisant le son, et d'ajouter une dépendance à dbus que de modifier le système de son de linux :-)
Envoyé depuis mon lapin.
[^] # Re: systemd
Posté par gnumdk (site web personnel) . Évalué à 4.
Patcher les logiciel utilisant le son ?
Euh, tu connnais beaucoup de soft toit qui attaque encore directement PCM ?
On voit que t'as pas suivi les longs débat il y'a quelques années quand les devs de soft audio ont tous arreter d'utiliser PCM pour gérer le niveau du son... Et à cette époque, pulseaudio n'existait pas...
[^] # Re: systemd
Posté par dguihal . Évalué à 2.
Bah pour ma part depuis que je suis sous arch je n'ai plus de problèmes avec pulseaudio qui de plus commence a être correctement géré sous KDE4 grâce au travail de Colin Guthrie. (Bon j'avoue j'ai longtemps vomi sur PA durant ma période MDV, mais maintenant il me va, coincidence ? Je ne sais pas)
De plus je suis passé récement sous systemd et je dois avouer que je trouve le système agréable sans compter le temps de boot vraiment réduit par rapport a l'init standard arch.
[^] # Re: systemd
Posté par pralines . Évalué à 1.
oula, très intéressé pour tester systemd sous arch :-)
tu es sous quelle version ? (testing ?)
il y a une manip simple ou bien faut mettre les mains dans le cambouis ?
un lien vers le ou les tutos SVP ?
merci
Envoyé depuis mon Archlinux
[^] # Re: systemd
Posté par Anonyme . Évalué à 1.
https://wiki.archlinux.org/index.php/Systemd
30 secondes de recherche c’est trop demandé ?
[^] # Re: systemd
Posté par pralines . Évalué à 3.
non :-)
c'est juste que la dernière fois que j'avais recherché, j'ai pris peur,
et l'expérience ma montré que le wiki, bien qu'excellent de façon générale, n'est pas toujours suffisant ou adapté à la dernière version des paquets !
alors j'ai profité d'avoir quelqu'un sous la main pour lui demander les difficultés qu'il a rencontré et surtout quelle méthode il a suivi...
faut-il déduire de ta réponse de 30s (google est ton ami, toussa...) que tu es aussi sous Arch avec systemd et que tu as suivi sans dévier le tuto que tu donnes en lien ?
sinon, je vais attendre une réponse de dguihal (si il repasse par ici :-)
no offense ;-)
Envoyé depuis mon Archlinux
[^] # Re: systemd
Posté par Ambroise . Évalué à 1.
Perso, je l'ai mis sur le portable de ma femme sans trop de souci avec le tutoriel.
Les seuls problème ont été l'absence de quelques script de démarrage pour systemd (genre pour cpufreq) mais on trouve des scripts tout fait sur le net qui permettent de ne pas trop se planter.
Par contre, je n'ai pas vu de grande différence sur le temps de lancement... Et j'aimerais bien voir si c'est lui qui m’empêche de voir mon imprimante réseau sur CUPS...
[^] # Temps
Posté par Arthur Accroc . Évalué à 2.
Moi non plus, mais avant je lançais quasiment tous les services en tâche de fond au mépris des dépendances (enfin j’intercalais d’autres services entre deux services dépendants l’un de l’autre) pour accélérer le démarrage. Du coup avec systemd, c’est plus propre.
Par contre, le temps d’arrêt est nettement plus court.
Cela dit, j’ai l’impression que le processus de démarrage de systemd est assez générique par rapport aux distributions et je le soupçonne de prendre un peu de temps à régler des trucs pas forcément indispensables et dont Arch se dispensait, ou de séparer certains petits trucs en services pour faire propre conceptuellement, alors qu’avec le script d’init type BSD, ils étaient faits directement dans le script principal...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: systemd
Posté par dguihal . Évalué à 2.
Pas de soucis réels en suivant le wiki anglophone.
De mémoire il me manquait une unit pour mysqld que j'ai été cherché ailleurs (Google a été mon ami).
sinon pour cups pas de soucis non plus (il faut par contre penser a l'activer avec systemctl enable cups.service)
[^] # Re: systemd
Posté par barmic . Évalué à 2.
C'est rare de voir quelqu'un sous arch ne pas cracher sur systemd au profit de l'init classique à la BSD (il s'appelle rc.d je crois).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Un de plus
Posté par Arthur Accroc . Évalué à 2.
J’utilise SystemD sous Arch aussi (qu’est-ce qu’on gagne ? ;-) ), donc ce n’est peut-être pas si rare que ça (ce serait une idée de sondage... sauf que ce serait limité aux utilisateur d’Arch, ce qui n’est pas (encore ?) le cas de tous les visiteurs de LinuxFr).
Je l’ai même mis en mode natif (pas pour les services, qui le sont de toute façon, mais par rapport à la configuration, que d’origine il reprend dans le fichier rc.conf).
Par contre, je me suis gardé aussi la possibilité de démarrer en BSD (en cas de doute par rapport à un service qui poserait problème).
Comparé à la Fedora 15 de ma machine du boulot, qui démarre obligatoirement sous SystemD, mais avec la grosse majorité des services en mode compatible... dans un cas, je choisis ma chaise et dans l’autre j’ai le cul entre les deux chaises.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: systemd
Posté par dguihal . Évalué à 3.
l'init standard arch est un vrai bonheur de simplicité je suis d'accord, mais l'utilisation de systemd m'a permis de gagner au temps de boot sans me prendre le chou sur le démarrage des daemons (background ou pas ?).
Sans compter le démarrage "au besoin" pour ce qui concerne les services utiles mais pas tt le temps : cups / apache / ...
[^] # Re: systemd
Posté par Albert_ . Évalué à 0.
Le truc pour le bluetotth ca c'est de l'argument "has been", les casques audio bluetooth cela n'existe plus (non une oreillette pour le telephone n'est pas un casque).
[^] # Re: systemd
Posté par Paul . Évalué à 2.
Non seulement les casques Bluetooth existent encore, mais en plus la gestion des oreillettes passe également par pulseaudio.
[^] # Re: systemd
Posté par Albert_ . Évalué à 1.
Bien sur que les casques Bluetooth existent encore. Il faut bien ecouler les stocks et refourguer les restes. Il n'empeche que dans les casques recents sans fils c'est systematiquement des casques non bluetooth. Pour les oreillettes c'est du bluetooth alors heureusement que PA gere cela sinon il serait encore plus inutile.
Je remarque que le message est a zero mais personne n'a repondu pourquoi il a fallu rajouter une couche a Alsa plutot que corriger ou remplacer ce dernier...
[^] # Re: systemd
Posté par FreeB5D . Évalué à 4.
OSSv4 il est libre et fonctionne très bien depuis juillet 2007, donc avant que PulseAudio ne devienne répandu. Même s'il n'était pas directement inclus dans le noyau, ça n'empêchait pas les distributions de l'utiliser ou de le proposer en alternative à ALSA, pour ceux qui n'ont rien à faire de pouvoir faire le suspend/resume ou pas (et d'ailleurs OSS4 est dans Debian depuis Squeeze).
[^] # Re: systemd
Posté par Sufflope (site web personnel) . Évalué à 9.
C'est vrai que prendre OSS (qui s'est retrouvé tricard partout après avoir mis tout le monde dans la purée en changeant de license comme des sales, et maintenant pleurent que les gens soient passé à autre chose) comme exemple, c'est judicieux.
Prochaine étape, faire pleurer la ménagère sur le sort de XFree.
[^] # Re: systemd
Posté par Anonyme . Évalué à 8.
Forker OSS aurait permis de continuer à partager du code entre les différents Unix.
[^] # Re: systemd
Posté par FreeB5D . Évalué à 2.
Je ne parle pas de OSSv3 l'ancien mais de OSSv4.
Et il se trouve qu'à ce moment là (la libération de OSSv4), les distributions, en majorité, ne sont pas allées proposer OSSv4 (libre et qui fonctionne bien, avec les volumes par application qui étaient sensés être une grande nouveauté de PulseAudio) en option alors qu'elles proposaient ALSA en option avant.
Même en tenant compte de l'absence de compatibilité avec le suspend/resume, je suis prêt à parier qu'à l'époque beaucoup d'utilisateurs auraient apprécié un son qui marche, avec un mixeur qui mixe les applications OSS avec les autres et qui permet le réglage de volume par application, quelques années avant d'avoir un PulseAudio réputé (ou pas?) fonctionnel.
[^] # Re: systemd
Posté par reno . Évalué à 3.
Ben voyons, faire confiance à un gars qui a fermé les sources une fois, ça motive tout de suite à utiliser OSSv4.
[^] # Re: systemd
Posté par FreeB5D . Évalué à 1.
Et t'as bien des distributions qui ont choisi d'inclure KDE3 alors qu'il n'était déjà plus maintenu (Pardus Corporate par exemple).
[^] # Re: systemd
Posté par reno . Évalué à -1.
Je ne vois pas le rapport: ils n'ont pas fermer les sources sur KDE4 eux(*), contrairement au développeur d'OSSv4 (au départ).
*: Ça ne veut pas dire que je suis d'accord avec la méthode de développement de KDE, s'ils prétendent vraiment être un desktop stable, ils auraient du porter KDE3.5 sur Qt4 (mis à part Phonon qui était nécéssaire dés le départ car le son fonctionnait mal sur KDE3.5) puis ensuite faire des modifs avec précaution (et pas activer par défaut des outils instables).
[^] # Re: systemd
Posté par barmic . Évalué à 4.
Il veut dire que tu peut toujours continuer à garder la dernière version libre d'OSSv4, même si elle n'est plus maintenu.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd
Posté par Anonyme . Évalué à 4.
Déjà, le troll sur KDE n’a rien à faire là et prouve uniquement que tu ne connais pas KDE.
Ensuite, comme dit Barret Michel, le fait que OSS soit devenu non libre à la version X n’a aucune importance, la communauté aurait pu forker la version X-1 et continuer à l’améliorer.
[^] # Re: systemd
Posté par bubar🦥 (Mastodon) . Évalué à 1.
On pourrais aussi ajouter que cela a été fait sans que les principaux logiciels audio sous linux soient prêts (et je ne sais pas si cela a été fait avec consultation de ces développeurs là). Or s'il y avait bien, au moment où PulseAudio a été fait, un domaine "desktop" dans lequel gnu/linux excellait, c'était l'audio. Il y avait (et il y a toujours) des logiciels d'une qualité incroyable en matière de son. Alros bien sûr, là on peut reprocher aux distros d'avoir intégrées pa un peu vite (ce qui a amené une grande partie des utilisateurs du son sous linux a virer pa et a en garder une certaine méfiance), mais d'un autre côté, si les distros (hors fedora) n'avaient rien fait, et pas intégré pa, que se serait il passé ?
C'est un "point de détail" pour quelqu'un utilisant son desktop avec comme principaux outils un navigateur et une console, voir ide. Mais pour ceux ayant un usage "audio" de linux se fut une réelle régression.
[^] # Re: systemd
Posté par FreeB5D . Évalué à 9.
Comme dans Slackware: rien, et tout continue de fonctionner.
[^] # Re: systemd
Posté par zebra3 . Évalué à 1.
Et sans les nouvelles fonctions, comme le son en réseau.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par jiyuu . Évalué à 4.
Nouvelle fonction ? Le son en réseau ?
Comme si ça n'existait pas déjà avant.
[^] # Re: systemd
Posté par imr . Évalué à 3.
Ou arts ou NAS avant.
[^] # Re: systemd
Posté par zebra3 . Évalué à 0.
Je sais, il y a eu aussi Esound.
La différence, c'est qu'avec PulseAudio je clique sur préférence et j'ai la liste des serveurs PulseAudio qui s'affichent tous seuls, et je n'ai qu'à choisir la sortie d'un clic.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par gnumdk (site web personnel) . Évalué à 2.
C'est avahi qui permet cela, rien à voir avec pulseaudio.
[^] # Re: systemd
Posté par zebra3 . Évalué à 0.
Et alors ? C'est pas Avahi qui devine tout seul que PulseAudio est lancé, les deux fonctionnent de concert, et ça marche direct.
(tiens, quel hasard, Avahi a été développé par le même gars)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par barmic . Évalué à 9.
A quand un LennartOS avec du matos qu'on appellerais les lTrucs et qui fonctionnerais super bien ensemble (par contre allais pas venir faire chier si vous n'utiliser pas le bon OS) ? :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd
Posté par gnumdk (site web personnel) . Évalué à 2.
Mwai, enfin c'est normal qu'il utilise avahi pour faire cela, c'est juste que c'est faisable avec n'importe quel service du coup.
[^] # Re: systemd
Posté par zebra3 . Évalué à -2.
Peut-être, mais il n'y a qu'avec PA que c'est fait. Donc PA a au moins une raison d'exister.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par barmic . Évalué à 2.
Quand ils en auront besoin ils l'intégreront.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd
Posté par Olivier Serve (site web personnel) . Évalué à 0.
Mais qui s'en sert à part trois pelés et un tondu ?
[^] # Re: systemd
Posté par imr . Évalué à 2.
Mais qui s'en sert à part trois pelés et un tondu dans un garage?
[^] # Re: systemd
Posté par zebra3 . Évalué à 2.
C'est sûr que si on ne propose pas la fonction, personne ne s'en servira…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par barmic . Évalué à 4.
Si les utilisateurs de Slack en avaient besoin ils ferraient pression pour l'avoir ou changerais de distribution. Tu t'en sers c'est cool, ce n'est pas pour ça que c'est considéré comme primordial au plus grand nombre, certains apprécie de ne pas se prendre la tête à apprendre un nouveau truc complexe pour des fonctionnalité dont ils n'ont pas besoin.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd
Posté par zebra3 . Évalué à -1.
Donc si Slackware ne le propose pas, c'est que personne n'en veut ?
Heureusement que c'est faux, sinon je ne pourrais même plus uliser GNOME…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par barmic . Évalué à 3.
Non ça montre juste que ça ne fait pas l’unanimité et que contrairement à ce qu'on peut lire ça et là, ce n'est pas une nécessite absolu. On pouvait écouter de musique avant, on peut continuer sans.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd
Posté par zebra3 . Évalué à 2.
Je peux bien comprendre que ce n'est pas d'une nécessité absolue, mais il faut arrêter de le descendre dès qu'on voit le nom de Lennart.
Déjà parce que certains en sont très contents, et aussi parce que pas grand monde n'a proposé mieux jusque-là.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par Olivier Serve (site web personnel) . Évalué à 6.
Il n'y a rien à proposer, ça existe déjà : ALSA. C'est peut-être mal codé, mal pensé, tout ce que tu veux. Il n'en reste pas moins que ça marche et surtout : c'est suffisant pour une utilisation de bureau classique.
[^] # Re: systemd
Posté par Albert_ . Évalué à 5.
Et puis surtout PA c'est juste une couche de plus a Alsa...
[^] # Re: systemd
Posté par zebra3 . Évalué à -2.
Donc, je repose la question : ALSA faisait-il du son en réseau, et de manière ergonomique (ie j'ai la liste des serveurs de son et je choisis en cliquant dessus) ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par ploum (site web personnel, Mastodon) . Évalué à -5.
Laisse tomber. Alsa ne fait pas de multiplexing (ce n'est pas son rôle), alsa ne permet pas d'utiliser plusieurs cartes sons en redirigeant dynamiquement certains flux sur une carte et d'autres sur l'autre, ALSA ne permet pas de régler le volume par flux.
ALSA n'est qu'une API pour exposer la couche hardware.
Dire que ALSA est bien suffisant c'est déjà un manque de connaissance en soi mais également un manque de réflexion: ESD, Arts et Pulseaudio aurait été créés juste parce que les gens n'ont pas pensé à utiliser Alsa ? Mmm ?
Rappelons que Pulseaudio n'est pas sorti ex-nihilo comme une idée à Lennarts. ESD et Arts existaient et Lennart a d'abord essayé d'amélioré ces deux là avant de se rendre compte des problèmes intrinsèques et de proposer une réécriture de ESD appelée Polypaudio.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: systemd
Posté par gouttegd . Évalué à 6.
Euh, il y a vraiment des gens qui utilisent plus d’une carte son simultanément ? Je conçois bien qu’un PC puisse avoir plus d’une carte son (un chipset intégré à la carte mère et une carte PCI par exemple), mais comment peut-on avoir besoin d’utiliser les deux en même temps ?
Si des utilisateurs ont ce genre de besoin et que PulseAudio y répond, tant mieux pour eux. Pour ma part, je n’ai jamais ressenti un quelconque besoin que seul PulseAudio pourrait satisfaire. ALSA me convient parfaitement pour mon utilisation quotidienne, et pour les besoins très spécifiques de la MAO à laquelle je m’adonne de temps en temps, j’ai Jack.
[^] # Re: systemd
Posté par zebra3 . Évalué à -3.
Oui, mais en réseau. Mais je conçois que comme pour toi PulseAudio est pourri, tu ne veuilles pas comprendre ce que les autres puissent faire avec.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par gouttegd . Évalué à 8.
Merci de ne pas me faire dire ce que je n’ai pas dit. Je ne me suis pas prononcé sur la qualité de PulseAudio, que je n’ai jamais utilisé (jamais eu besoin, tout comme je n’ai d’ailleurs jamais eu besoin de aRts ou de esd). Et j’ai bien explicitement écrit « tant mieux si ça répond à des besoins des utilisateurs » (même si lesdits besoins me paraissent légèrement exotiques et assez éloignée de l’utilisation classique d’un « desktop »).
Libre à toi d’en conclure que je pense que c’est pourri, mais ce n’est pas en déformant mes propos que tu me convaincras de l’essayer. J’utiliserai PulseAudio le jour où j’en aurais besoin, si ce jour arrive, et pas avant.
[^] # Re: systemd
Posté par Kaane . Évalué à 10.
Il y a 5 API de multiplexing dans ALSA. Dont trois ont fonctionné à un moment donné(dmix, Virtual Device et SoftVol) et une interface pour le multiplexing hard si la carte le supporte (et que le device est pas en lock exclusif par Pulse Audio, parce que sinon tu risques de crasher l'audio, à moins que les fréquence d’échantillonnage soient rigoureusement identiques)
Si si aussi. Enfin dans le code il y a des pages entières pour passer le flux qui rentre sur une interface alsa d'un device alsa-driver (virtuel ou non) à un autre. La seule utilisation connue (mais pas documenté pour autant) c'est le passage de HDA au device définitif suivant qu'on lise un DVD ou non.
softvol permettait de créer un device nommé par application et donc de régler le volume par flux. En fait il permettait même de créer plusieurs device par application et de faire que la seconde instance d'audacity n'avait pas le même volume que la première (par exemple)
Non ca c'est Alsa-Hcontrol qui est une sous partie de Alsa-driver, qui lui même n'est pas à proprement parler le framework Alsa, juste une interface coté hard.
C'est à dire que là, la personne qui manque de connaissance c'est pas forcément celle qui déclare qu'Alsa est suffisant. Sur le papier Alsa est largement suffisant, maintenant si on pouvait avoir la doc et des API qui ne sont pas cassées à chaque mise à jour ca ferait plaisir.
Déjà ESD c'est sorti pour OSS, Alsa n'existait pas à l'époque. Ensuite Arts a été écrit pour le projet KDE, parce que tous les systèmes sur lesquels KDE tournent ne possèdent pas Alsa et qu'il fallait une interface générique. (Mais bon au début Arts sur Linux coté kernel c'était quasiment juste une GUI pour piloter Alsa). Quand à PulseAudio il jette bébé avec l'eau du bain en bloquant les fonctionnalités realtime, resync et timer. C'est pas de sa faute, il est en pur userland donc forcément...
Ca ne change rien au fait que Pulse Audio ne résout aucun problème, il balaye la poussière sous le tapis. Madame Michu est contente parce que ca lui permet simplement d'avoir à la fois le son de sa video et les bruits de son Linux, mais pour toute personne qui souhaite faire du son de façon un peu propre ça reste une abomination.
[^] # Re: systemd
Posté par nud . Évalué à 6.
Ben si, avec dmix.
[^] # Re: systemd
Posté par Olivier Serve (site web personnel) . Évalué à 4.
J'ai des besoins simples :
- écouter de la musique / regarder des vidéos
- avoir du son dans les jeux
- pas de son en réseau
- une seule carte son
Je ne vois donc, pour mon utilisation comme pour celle de mes parents ou amis sous linux, strictement aucun intérêt à PA puisque tout ce que je demande fonctionne déjà très bien sans. C'est tout ce que je dis.
Si tu y trouves un intérêt pour tes besoins spécifiques, tant mieux ! Mais le commun des utilisateurs s'en contrefout.
PS: je n'ai rien contre Lennart. Son attitude Linux-centrée me gène un peu, mais je trouve les idées derrière systemd intéressantes.
[^] # Inversion
Posté par Arthur Accroc . Évalué à 5.
Là, tu inverses la cause et la conséquence.
Historiquement, certains utilisateurs n’aiment pas Lennart à cause de PulseAudio.
Et c’est à ses productions plus récentes (notamment SystemD) que ça cause du tort.
Moi-même, si je suis passé à SystemD, c’est parce que j’attendais une init de ce genre, mais le même auteur que PulseAudio était plutôt un élément dissuasif.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: systemd
Posté par zebra3 . Évalué à -1.
C'est vrai que taper apt-get ou yum c'est vachement se prendre la tête.
À moins que comme Slackware n'a pas de gestion de dépendances, leurs utilisateurs considèrent les packages comme de la prise de tête ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par Altor . Évalué à 6.
Les packages non, les dépendances oui. Beaucoup de gens pensent que slackware n'a pas de gestionnaire de packages, mais c'est faux et il y a une réelle différence entre les deux.
À cause de la gestion des dépendances, on ne peut pas avoir la version X du logiciel Y compilé avec les options Z facilement sans être dépendant du bon vouloir d'un packager ni se prendre la tête. Apprendre à faire un paquet slackware de zéro,ça doit prendre 1/2 journée. Changer la version 5 minutes (plus la compilation), changer les options de compilation 15 minutes.
À quoi ça sert ? Grâce à ce système, j'ai une base robuste et seul les logiciels que j'utilise de manière pro ou poussé sont dans la version que je veux. C'est par exemple très utile dans mon cas pour libreoffice, python (ipython, matplotlib…) et kde 4.7. Après, la version de X, du kernel ou autres, je m'en fous complètement.
[^] # Re: systemd
Posté par FreeB5D . Évalué à 3.
Même pas, je dirais plutôt 1 heure:
[^] # Re: systemd
Posté par zebra3 . Évalué à 0.
Ben n'oublie pas de corriger Wikipédia, parce c'est pas étonnant que tout le monde le pense en lisant ceci :
(cf Slackware)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par barmic . Évalué à 3.
Je pense qu'il a inversé et qu'il a voulu dire que Slackware a un gestionnaire de paquet mais sans gestion de dépendance. Il voulais probablement contredire ce bout de phrase :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd
Posté par zebra3 . Évalué à -2.
N'empêche qu'on ne m'a toujours pas expliqué en quoi installer PulseAudio est une prise de tête…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par barmic . Évalué à 4.
Tu as tenté de t'en servir avec autre chose que des environnement de bureau complet ?
Tu as essayé de faire un peu de support pour ceux chez qui ça ne marche pas (autre chose que leur dire qu'Ubuntu c'est de la merde et qu'ils devraient changer de distro sans même t'être renseigné sur la distribution qu'ils utilisent) ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd
Posté par zebra3 . Évalué à -2.
Oui. J'ai une tour sans interface graphique avec PulseAudio, et je transfère le son de mes portables dessus.
Non, parce justement je n'ai pas eu à chercher chez moi.
Jamais dit qu'ils devaient laisser Ubuntu, qui est très bien sur bien d'autres points. Il faut juste ne pas blâmer PulseAudio pour l'empaquettage pourri d'Ubuntu.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par gnumdk (site web personnel) . Évalué à 3.
Sources ?
[^] # Re: systemd
Posté par zebra3 . Évalué à -1.
Ici.
En particulier :
puis :
D'autant plus que Canonical a vraiment fait n'importe quoi sur ce coup-là, en intégrant pour la première fois ce logiciel dans une LTS (la 8.04). M'enfin, y'avait aussi la beta de Firefox 3 et GVFS, ils n'étaient pas à ça près…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par Littleboy . Évalué à 6.
Et donc ta seule source c'est l'auteur du logiciel, qui travaille par ailleurs pour le concurrent (dont certains employes aiment bien critiquer Ubuntu et insinuer qu'ils ne participent pas a la communaute du LL, mais c'est de bonne guerre).
T'as pas autre chose, parce que niveau credibilite et bonne fois, ca vole pas bien haut.
[^] # Re: systemd
Posté par Albert_ . Évalué à 6.
Pour une fois je suis 100% d'accord avec toi. On pourrait rajouter aussi que si PA est aussi complique que cela a inclure dans une distribution cela n'est pas normal. Une installation par defaut aurait du fonctionner "out of the box" mais bon il fallait "tuner" ca pour chaque distribution (dans ses premieres versions).
Alors Ubuntu la premiere version PA incluse fonctionnait beaucoup moins bien que celle de Fedora, que Lennart avait introduite lui meme, mais on pourra noter que ce sont eux qui ont eu le courage (stupidite?) de tenter de faire cela en premier et sans avoir l'auteur dans l'equipe.
[^] # Re: systemd
Posté par reno . Évalué à 2.
Euh pour une distribution qui se veut 'grand public', je pense que tu peux parler de stupidité sans mettre les parenthèses..
[^] # Re: systemd
Posté par Albert_ . Évalué à 2.
Oui peut etre mais bon il fallait bien que quelqu'un en dehors de RH tente le coup, comme Ubuntu se veut "bleeding edge", ils ont tente et ce fut une belle connerie car le logiciel n'etait clairement pas pret pour autre chose qu'une distrib Fedora/RH. On peut dire que ubuntu a essuyer les plates et que les autres distribs qui ont tente l'integration on eut quelques mois et l'experience de Ubuntu pour corriger et adapter le bousin.
[^] # Re: systemd
Posté par Mjules (site web personnel) . Évalué à 1.
Mandriva 2008.1 est sortie à peu près au même moment (avril 2008) avec pulseaudio par défaut et beaucoup moins de problèmes.
cela dit aujourd'hui, l'intégration de pulseaudio dans ubuntu est au niveau des autres distributions.
[^] # Re: systemd
Posté par gnumdk (site web personnel) . Évalué à 2.
C'est cela que je ne comprend pas:
"beaucoup moins de problèmes."
Je cherche des sources, pas un commentaire de lennart...
Parce que perso, j'ai toujours eu autant de problème avec pulseaudio, que ce soit sous Ubuntu, Debian ou Arch.
[^] # Re: systemd
Posté par imr . Évalué à 7.
J'aidais sur le forum mandriva à cette époque encore et c'est des conneries. Si tu avais une des cartes son qui ne marchait pas avec pulseaudio, et il y avait la carte HDA realtek qui ne marchait pas et qui était dans des tonnes de cartes mères, tu n'avais pas de son avec pulseaudio.
Ce qui faisait que les gens avaient moins de problèmes avec pulseaudio sous mandriva, c'est que dans le centre de controle tu avais un utilitaire pour gérer le son, et dans cet utilitaire il y avait un bouton "désactiver pulseaudio".
Donc quand ça merdait, on leur disait, désactive pulseaudio, on leur indiquait le chemin du bouton, et, zimzouzim! le son remarchait.
Ca me faisait tellement chier et pester, que des années après, quand j'avais un problème de son, ma femme me disait encore "tu as désactivé pulseaudio?" tellement elle m'avait entendu le dire. Mais bon, elle est espiègle.
[^] # Re: systemd
Posté par Albert_ . Évalué à 2.
beaucoup moins de problèmes.
Tu te rends compte de ce que tu ecris? Tu dis qu'il y avait moins de problemes pas qu'il n'y en avait pas... Et de tout de facon est-ce etonnant qu'une distribution Redhat/RMP based_ ait eu moins de problemes qu'une debian based?
[^] # Re: systemd
Posté par Mjules (site web personnel) . Évalué à -2.
Tu connais un soft qui n'a pas pas de problème toi ? moi non.
Tu indiques que ubuntu a intégré pulseaudio dans les premiers et a essuyé les plâtres d'où la multiplicité des problèmes. Je précise juste qu'au moins une autre distribution non fedora l'a aussi fait au même moment et avait moins de soucis. Ce qui tend à confirmer qu'à l'époque le problème était surtout avec ubuntu. Aujourd'hui, ce n'est plus le cas.
J'avoue ne pas bien voir le rapport entre rpm et pulseaudio ? Ni même avec le fait que mandriva (mandrake à l'époque) trouve ses origines dans red hat ? Depuis 1998, les choses ont un peu changé...
[^] # Re: systemd
Posté par gnumdk (site web personnel) . Évalué à 4.
Oui, mais moi sans sources, ca vaut que dalle ce que tu dis, surtout que certain mandriviens confirme que ca foirait pareil sous Mandriva.
[^] # Re: systemd
Posté par reno . Évalué à 2.
Euh, d'où tu sors ça? Fédora est censé être bleeding edge pas Ubuntu.
Leur site web indique plutôt que c'est une distribution "easy to use, to install, to maintain" ce qui est contradictoire avec "bleeding edge".
[^] # Re: systemd
Posté par bubar🦥 (Mastodon) . Évalué à 1.
Fedora prouve le contraire tout les jours, depuis la 13.
[^] # Re: systemd
Posté par zebra3 . Évalué à 0.
Tu te rends compte que c'est le contraire de ce que devrait être une LTS ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par Albert_ . Évalué à 6.
Absolument pas. LTS veut dire que les logiciels seront corrige si probleme de securite ou de stabilite pour le systeme pendant X annees.
Et je ne vois pas comment on peut dire que Ubuntu n'est pas "bleeding edge" vu que c'est toujours la derniere version de Gnome qui est fournit et donc tout sauf bien teste.
[^] # Re: systemd
Posté par gnumdk (site web personnel) . Évalué à 2.
Bah, maintenant y'a du mieux, avec GNOME3, Ubuntu et Kubuntu sortent toujours 2 sous version après une version majeur du Destkop, je trouve que ca le fait.
[^] # Re: systemd
Posté par Albert_ . Évalué à 1.
Ouhais le probleme c'est qu'il n'existe aucune distribution qui fournisse un KDE aux petits oignons sans avoir une version datant de 6 mois.
[^] # Re: systemd
Posté par imr . Évalué à 2.
Si, opensuse 12.1 vient de sortir avec le KDE en cours, aux petits oignons. Et tu peux l'installer sur les distros précédentes avec un dépot. J'ai les deux et c'est aux petits oignons.
Par contre, un KDE dernière version ça veut dire kmail2 et akonadi, ça veut donc dire que ça fout la merde niveau catastrophe industrielle. Et comme l'a dit gnumdk, la meilleure façon de faire c'est de partir d'un compte propre.
Et ce sans oublier que akonadi fout des trucs dans .local et.config et si comme moi tu as fait un test d'akonadi/kmail2 dans le passé, s'il reste des morceaux d'akonadi dans ces dossiers, ça peut ne pas démarrer.
Donc -> faire une copie puis effacer tout .kde4 ou seulement les dossiers/fichiers kmail* dans .kde4/share/apps et .kde4/share/config et effacer tout ce qui est akonadi dans .local ou .config. Lancer alors le nouveau kde 4.7 "aux petits oignons". Reconfigurer tous les comptes puis regarder la nouvelle interface toute jolie qui rame puis la configurer pour voir les expéditeurs avant de repasser à l'ancienne interface.
A terme, je me retrouve avec des arborescences de mon ancien mail mais vides, une interface qui rame et un disque dur qui mouline tellement que j'ai cru que l'indexation nepomuk s'était réactivé. Peut être qu'il remplit les dossiers en background, je le saurai un jour. Ou pas.
Alternative: considérer de dumper kmail2 et son non sens et de passer à une autre app
Alternative: considérer de dumper kde4 et son non sens et de passer à un autre desktop
Alternative: hurler sa rage parce qu'on connait les alternatives courrier et desktop et entendre sa femme vous dire "tu as essayé de désactiver pulseaudio?"
Alternative: essayer de brancher un boulier sur le moniteur
[^] # Re: systemd
Posté par Albert_ . Évalué à 1.
Kmail2 est utilisable sur la derniere ubuntu.
Je n'en dirais pas autant de nepomuk. Cela reste encore un enorme mystere pour moi ce truc. En theorie ca permet d'indexer les fichiers mais losrque je vois la base d'indexation qui fait 250 Megs pour 8 fichiers je me dit qu'il y a un probleme quelque part et ne parlons pas du panneaux de recherche dans dolphin qui est grise (non utilisable) alors que nepomuk est cense fonctionner...
[^] # Re: systemd
Posté par imr . Évalué à 2.
kmail2 marche, c'est la migration de mes anciens comptes mails qui foire quelle que soit la manière dont je la fais, interactive ou automatique.
Les dossiers restent vierges, j'ai un processus mysqld qui monte à 50% du CPU. Peut être il faudrait que j'attende plusieurs jours que ça finisse. Et dans les processus akonadi qui travaillent, il y en a un qui est nepomuk, donc l'un ne va pas sans l'autre apparemment.
Et la gestion des carnets d'adresses est vraiment compliquée et maladroite, je ne sais pas pour qui ils ont conçu tout ça, mais certainement des utilisateurs de mail de base. Il ne faut pas se plaindre s'ils passent tous sur du webmail.
[^] # Re: systemd
Posté par reno . Évalué à 4.
Moi, entre avoir une version de 6 mois bien stable et bien débuggée contre une version récente mais foireuse, je sais ce que je préfère.
6 mois c'est un problème?
Tu fais vraiment "la course à la version".. C'est ton droit mais je ne pense pas que ce soit un problème pour une majorité d'utilisateurs..
[^] # Re: systemd
Posté par Albert_ . Évalué à 2.
Avec KDE il vaut mieux etre a jour car je n'ai pas eu une seule version qui ne corrigeait pas des problemes que j'avais par ci par la. Mais il est vrai que si tu utilises Gnome c'est un peu l'inverse... Tiens derniere en date on ne peut plus effacer la liste des dernieres videos dans Totem, plus moyen de regarder un film de boules discretos :)
[^] # Re: systemd
Posté par reno . Évalué à 3.
Pas surprenant, mais c'est un problème auto-infligé non: 1) dernière version --> 2) bugs --> 3) besoin d'utiliser la nouvelle nouvelle version pour corriger la dernière version, goto (1)
PCLinuxOS ne se contente pas d'utiliser une vieille version, ils désactivent aussi les fonctionnalités immatures, après si toutes les distributions font comme ça il n'y a plus de testeurs donc les deux types de distributions sont intéressant tant qu'on ne confond pas les deux ("bleeding edge" présenté comme du "stable" ou vice versa), tout le monde est content..
[^] # Re: systemd
Posté par reno . Évalué à 3.
Bonne remarque, ça m'apprendra à faire confiance au marketing d'Ubuntu..
[^] # Re: systemd
Posté par Albert_ . Évalué à 2.
LTS cela ne veut pas dire stable mais Long Term Support.
[^] # Re: systemd
Posté par zebra3 . Évalué à 1.
Et ?
Comment tu veux faire du support à long terme avec un système pas fiable ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par Albert_ . Évalué à 2.
Heureusement le systeme etait fiable c'etait juste le bousin au dessus de la gestion audio qui l'etait pas. Le plus simple etait un simple apt-get remove pulseaudio et sinon un apt-get dist-upgrade pour recuperer la derniere version au fur et a mesure que les problemes apparaissaient et quelques annees plus tard c'est encore faisable.
[^] # Re: systemd
Posté par barmic . Évalué à 6.
Tu n'a pas quelque chose d'autre que citer quelqu'un qui dis qu'ils ont mal fait leur boulot ? Ou en tout cas qui explique en quoi ils ont mal fait leur boulot ?
Maintenant on sait que installer PA c'est beaucoup de boulot (certains diront que Lennart veut modifier les distributions pour ces logiciels plutôt que l'inverse), mais concrètement faut faire quoi ? Gstreamer a besoin d'être recompiler avec des options de compilations précises ? Faut faire des incantations les nuits de pleines lunes ? Lennart a un dépôt de 256 patches pour vlc, totem, gestreamer, le noyau, ext4 et bash pour que ça s'intègre partout où il faut ?
Qu'est ce que chez Ubuntu ils ne savent pas faire (puisque apparemment ça ne marche pas chez eux et qu’apparemment c'est les seul). D'ailleurs si Debian à fait le boulot, Ubuntu devrait l'avoir aussi (sauf si comme on entend souvent dire leur travail consiste à pourrir les intégrations).
Ce qui me gène dans tout ça c'est que le fait d'être aussi imprécis m'appuie dans l'impression que c'est une grosse boite noire dont on ne sait pas grand chose et surtout on y touche pas trop ça marche faudrait pas qu'on le casse et ne sache plus comment le remettre.
Je suis d'accord pour dire que la liste des fonctionnalités de PA est alléchante, je ne sais pas si conceptuellement il aurait du ou non remplacé ALSA (je doute que Trovald et Lennar s'entendent bien vu le caractère intrusif de ses créations^1 (dixit lui même dans le lien qu'il donne)), mais après avoir lu les documentation de différentes distribution (sur plusieurs mois), je suis incapable de gérer ce truc. Personnellement je préfère avoir quelque chose qui a un peu moins de fonctionnalité, mais que je maitrise bien qu'un truc hype dont je ne peux pas faire grand chose.
[1] : Au passage je pense que c'est l'un des plus gros problèmes de Lennart, il fait des choses très intrusives, quand on associe ça à son caractère un peu trollifique (moins que des pointure comme Torvald, Stallman ou De Raadt, mais tout de même). Ça se voit bien ici sur linuxfr à chaque fois qu'on a une nouvelle sur Lennard c'est pour nous expliquer que tout compte fait pour systemd il va falloir modifier tel ou tel truc. Il aurait probablement de bien meilleur retours en y allant tout doucement quitte à ce que systemd ne soit pas tout de suite parfait.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd
Posté par FreeB5D . Évalué à 2.
Ou le compileraient eux-mêmes.
[^] # Re: systemd
Posté par zebra3 . Évalué à 2.
Retire ce lien, malheureux !
Les slackeux n'ont pas besoin de PulseAudio !
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par gouttegd . Évalué à 3.
Les SlackBuilds sont écrits par les slackeux avant tout pour eux-mêmes, donc la seule existence d’un SlackBuild pour PulseAudio témoigne que si, au moins un slackeux avait besoin de PulseAudio. Tant pis si ça t’empêche de mettre tous les slackeux dans la même case.
Je conçois que ça puisse faire un choc à ceux qui croyaient dur comme fer que les slackeux étaient tous des ultra-conservateurs passant leurs temps dans une console (ou à la rigueur dans twm), refusant tout code postérieur à l’an 2000 et n’utilisant que des périphériques sur port parallèle…
C’est vrai qu’un slackeux moderne, c’est comme un Parisien sympathique ou un Marseillais modeste : ça ne correspond pas à l’image qu’on en a.
[^] # Re: systemd
Posté par zebra3 . Évalué à 0.
Hint : c'est pas moi qui ait commencé à mettre tous les slackeux dans le même panier.
Cf plus haut :
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par totof2000 . Évalué à 1.
Tu es slackeux ? Parce que moi, un peu (ce fut la première distrib Linux que j'ai réussi à installer, et j'en garde encore une de côté), et je ne voudrais pas que les non-slackeux en viennent à croire que les slackeux ne comprennent pas le second degré après avoir lu ton commentaire.
[^] # Re: systemd
Posté par gouttegd . Évalué à 0.
Je suis slackeux, oui (et pas qu’un peu : toutes mes machines locales sont sous Slackware, seul mon VPS est sous Debian).
Désolé que ça te cause du souci. Pour ma part, l’opinion de gens qui à partir des propos d’un slackeux tireraient des conclusions sur tous les autres ne m’importe guère.
De toute façon, j’ai déjà entendu pas mal de clichés sur Slackware et ses utilisateurs (dont l’ultra-conservatisme auquel je fais référence dans mon précédent message), alors « si y en a que ça les démange » d’en ajouter un du genre « le slackeux est imperméable au second degré », qu’ils fassent donc.
[^] # Re: systemd
Posté par Misc (site web personnel) . Évalué à 3.
Nan mais arrete la fumette. Personne de sérieux utilise linux pour le son à part une paire de libriste. Le kernel a besoin de patchs noyaux qui ont mis des années à être intégré en stable par petit bout et qui vont encore devoir attendre un bout de temps, le support des cartes sons professionnels est risible ( parce que les constructeurs collaborent pas ), et les offres logiciels sont rarement utilisés par les pros. Les radios et les différents personnes qui font de l'audio prennent de l'os x ou du windows, le reste est un fantasme au même titre que "linux sur le desktop".
[^] # Re: systemd
Posté par bubar🦥 (Mastodon) . Évalué à 10.
donc on s'en fout ?
hum.
Non mais arrêtes la branlette : s'ils sont peu nombreux, il existent. Qu'ils soient peu nombreux n'est pas une bonne raison pour leur marcher dessus. (en solutions professionnelles, il y a des indépendants, quelques studios pro, et surtout beaucoup d'appliances pour la gestion des vsti qui sont sous linux. Mais également des solutions industrielles de logs vocales, qui utilisent des drivers achetés à 4front)
Enfin, la qualité des logiciels audio sous linux est une réalité, il ne s'agit pas que de petits trucs qui font ouinouin, même s'ils ne sont pas au niveau des grosses solutions (la diff est du même accabit qu'entre LibreOffice et MSoffice, souvent...). S'ils ne sont pas utilisés ce n'est pas pour eux mais plus à cause de la plateforme. Et qu'un nouveau truc débarque et chamboule tout à certainement été un peu difficile à avaler pour les dev audio, et pour "la paire de libristes". M'enfin, bon, roulons leur dessus, on trouvera tjs un argumentaire.
[^] # Re: systemd
Posté par paulez (site web personnel) . Évalué à 4.
Tu parles de quel chipset utilisé par 30 à 50 % des pcs ? Si tu parles de Intel HDA, c'est n'est pas un chipset mais une norme, qui justement est utilisée par un très grand nombre de chipset (driver hda de alsa) mais qui ont chacun des subtilités qui forment autant de cas spécifiques pour le driver hda.
[^] # Re: systemd
Posté par Albert_ . Évalué à 6.
On peut aussi rajouter que PA utilisent Alsa donc c'est pourri mais cela ne change rien au probleme. Le truc pourrit est encore la. La veritable solution si Alsa etait aussi pourri aurait ete de remplacer Alsa pas de mettre une couche au dessus.
[^] # Re: systemd
Posté par zebra3 . Évalué à -1.
Ben vas-y, on regarde.
Là, le mec développe un truc, c'est limite si on lui crache dessus dès qu'il commence autre chose.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par Albert_ . Évalué à 6.
Non le mec dit Alsa c'est de la merde mais il refout une couche sur de la merde. Comme si mettre un tapis de rose aller donner une bonne odeur. Si vraiment Alsa c'est de la merde c'etait ca qu'il fallait corriger et pas mettre une surcouche cpuivore au dessus. Sans compter le merdier a configurer. Que tu adores ca c'est ton droit, que je trouve ce truc a peu pres superflus c'est aussi le mien.
[^] # Re: systemd
Posté par Alex . Évalué à 3.
En même temps ce n'est pas très pertinent comme remarque, alsa et PA n'étant pas au même niveau, et ne font pas du tout la même chose
dailleurs on peut mettre PA par dessus OSS, comme ça tu as ta merde au dessus d'un lit de rose ;)
[^] # Re: systemd
Posté par Albert_ . Évalué à 5.
Lennart a cree PA en disant en gros "Alsa c'est merdique donc je rajoute un truc au dessus pour faire des choses que Alsa ne peut pas faire" (D'apres un message au dessus meme cela est totalement faux). Et plus tard quand les problemes n'ont pas tarde a arriver il disait "PA c'est genial et il n'y a aucun bug c'est ALSA qui est tout pourrit". Si Alsa etait soit disant aussi pourri c'etait ce dernier qu'il fallait changer mais bon je n'ai clairement pas la meme logique que lui je sais.
[^] # Re: systemd
Posté par imr . Évalué à 3.
Il n'a pas dit qu'alsa ne le faisait pas, il a dit qu'alsa le faisait d'une manière qui ne permette pas d'atteindre certains objectifs, comme les économies d'énergie par exemple.
http://0pointer.de/blog/projects/jeffrey-stedfast.html
et voila un lien sur le résultat de cet objectif 3 ans après.
http://linux-tipps.blogspot.com/2011/04/power-performance-of-pulseaudio-alsa.html
On remarquera que les discussions sont beaucoup plus calmes à cette époque (2008) et qu'il reconnait plus volontier les problèmes propres à pa. Il passe sur la défensive autour de 2009 parce que pa est alors bien plus installé, et que les problèmes utilisateurs remontent en masse:
http://0pointer.de/blog/projects/pascal-terjan.html
[^] # Re: systemd
Posté par gnumdk (site web personnel) . Évalué à 4.
Wai, bon, en clair, il se fout de la gueule du monde...
PulseAudio moins consommateur de ressources que ALSA, on doit pas parler du même pulseaudio...
[^] # Re: systemd
Posté par zebra3 . Évalué à 1.
Que tu le trouves superflu, OK. Mais c'est pas exactement ce que je comprends que je te vois écrire « c'est pourri ».
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par zebra3 . Évalué à 0.
Au passage, oui le mec écrit qu'Alsa c'est de la merde, mais au moins il propose quelque chose, lui.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par Albert_ . Évalué à 2.
Mais je vais t'apprendre un truc: Il est paye pour ca et c'est son metier. Il n'empeche que PA c'est cense corriger des manques de Alsa et comme cela a ete demontre plus haut les manques sont imaginaires mais il faut bien justifier l'existence du bousin et de tous les problemes que cela a pu engendrer.
[^] # Re: systemd
Posté par MTux . Évalué à 10.
Désolé je n'entends rien, c'est à cause du son qui crépite, craque et grésille quand la charge du CPU monte un peu trop haut. Saleté de Pulseaudio !
[^] # Re: systemd
Posté par zebra3 . Évalué à 0.
Bah faut pas écouter du Black Eyes Peas, ça ira tout de suite mieux.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd
Posté par Anonyme . Évalué à -4.
J’ai mis en gras les deux mots qui vont ensemble et barré l’intrus !
[^] # Re: systemd
Posté par bubar🦥 (Mastodon) . Évalué à 3.
Aucun problème avec systemd, c'est robuste y compris lorsqu'on fait des conneries pour tester. Iciçamarche(tm). Et perso j'aime beaucoup la nouvelle syntaxe des fichiers de conf. Par contre on perd en simplicité pour les cgroups. J'ai pas encore tout compris de l'ordre des briques à ce niveau (je croyais que oui, et puis non...) Pour Pulseaudio, ben avec fedora 16 j'l'ai adopté (si si j'vous jure !). Bon je peux encore le coller à 100% du cpu dans un cas précis, et ça marche à chaque fois, zut. Mais globalement c'est devenu confortable pour mon usage.
Ceci n'enlève pas la remarque plus haut, à laquelle j'adhère aussi. Tout ceci est très "desktop" (y compris systemd), et je me demande si cela ne serait pas mieux d'avoir un bon gnu/linux à l'ancienne, pour les serveurs. Et toutes ces avancées mais pour une version desktop. Bref je me demande ce que Redhat va faire réellement de tout ça (si vraiment ça fait trop ch** pour un serveur, j'collerai une Debian plutôt qu'une centos. Donc "ma" question est plutôt autour de l'usage que fera Redhat de tout ça pour ses versions el es etc...). Est ce la fin de la "distribution unique et universelle" ? Ou au contraire tout ceci va réellement être pousser dans les versions serveurs ? (si ça, alors j'connais des sysadmin qui vont devoir se remettre à jour...)
[^] # Re: systemd
Posté par nud . Évalué à 3.
Ben pour administrer des serveurs assez critiques (de la téléphonie) chez pas mal de clients, y'a quand même des trucs bien intéressants au niveau de systemd, comme le fait qu'il soit capable de redémarrer un service qui se vautre tout seul comme un grand, et qu'il soit capable de ne pas perdre d'information malgré ce crash grâce à sa gestion des fd.
Par contre certains trucs me semblent plus difficiles à débugger, mais c'est peut-être dû au manque d'habitude et de connaissance de systemd.
[^] # Re: systemd
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
J'utilise monit pour relancer les services qui crash. Ca marche... On aurait pu améliorer monit !
Monit permet de dissocier le démarrage de la supervision des services eux-mêmes.
Un des principes d'UNIX, faire une chose et le faire bien. Je trouve personnellement que systemd en fait trop et j'aime pas trop son connecteur DBUS. Pour un processus aussi sensible, cela fera la joie du vers un jour...
[^] # Re: systemd
Posté par nud . Évalué à 3.
J'utilise mon, il marche très bien et il ne fait pas ce que systemd peut faire. Je peux certes vérifier toutes les 30 secondes que mon service tourne (ce qui exige l'exécution d'un script). Mais systemd peut tout simplement redémarrer le service dès qu'il disparaît car il en est notifié directement.
[^] # Re: systemd
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Qu'est ce qui empêcherait monit ou mon d'être notifier directement ?
[^] # Re: systemd
Posté par nud . Évalué à 2.
Explique-moi donc comment procéder, si c'est si facile.
Pour info, systemd réagit tout simplement à SIGCHLD.
[^] # Re: systemd
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
J'ai jamais dis que c'était facile.
Si c'est un bête SIGCHLD, pourquoi ne pas le rajouter au processus init actuel ? Il fait comment en cas de fork ?
[^] # Re: systemd
Posté par totof2000 . Évalué à 5.
Cz existe : man inittab avec respawn.
Il n'a rien inventé la dessus, Lennart.
[^] # Re: systemd
Posté par Sufflope (site web personnel) . Évalué à -1.
Ouais c'est cool on va abandonner systemd et démarrer chaque service dans un tty.
LAUL.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd
Posté par gnumdk (site web personnel) . Évalué à 3.
Mwai, sauf que si j'ai bien compris, systemd prend le relai pendant que le process est down et lui transmet tout ce qui s'est passé quand il est de nouveau opérationnel.
J'ai bien compris ?
[^] # Re: systemd
Posté par M . Évalué à 5.
De mémoire SIGCHLD est envoyé au père, qu'est ce qui empêche de lancer ton démon avec un programme ton le rôle est de te relancer si tu crash ?
Une sorte de start-stop-daemon améliorer.
C'est ca qui m'attriste avec les solutions de Lennart. On pourrait faire simple, mais il faut que ce soit des usines a gaz intrusive.
[^] # Re: systemd
Posté par manawy (site web personnel) . Évalué à 3.
ben ça fait un processus par démon au lieu d'un seul processus. C'est pas forcément beaucoup, mais vu le nombre de démon qui peut tourné ...
Puis pourquoi faire :
init -> demon de relance -> démon
Quand on peut tout simplement faire :
{init, démon de relance} -> démon
Ça paraît aussi simple et transparent pour l'utilisateur finale qui ne s'intéresse qu'aux fonctionnalités du démon. (Ça juste fait ce que je veux)
[^] # Re: systemd
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Ca parait simple mais cela met tout sur un seul processus... Via la séparation, le démon de relance pourrait être dans un cgroup différent par exemple. L'idée en soi est assez séduisante je trouve.
Et puis, depuis quand l'utilisateur final s'intéresse à la tripotée de démon qui tourne ? L'architecture du processus numéro 1 ne me semble pas avoir une quelconque interaction directe avec l'utilisateur.
[^] # Re: systemd
Posté par Sufflope (site web personnel) . Évalué à 10.
C'est sûr que le gros merdier des scripts d'init, par dessus lequel on rajoute des couches de hacks encore plus moches genre daemontools, chaque couche étant remplie de saloperies pour pallier les déficiences d'une autre couche concernant une tâche pour laquelle elle a pas été prévue (ou alors, dans le contexte d'il y a 40 ans), c'est super plus propre qu'un système d'init conçu avec en tête le millénaire dans lequel on se trouve.
[^] # Re: systemd
Posté par Misc (site web personnel) . Évalué à 9.
Ce qui m'attriste, c'est que tant de gens pourraient faire simple, mais prefere troller sur linuxfr au lieu de coder.
Faut se sortir les doigts du cul les cocos. Mont existe depuis des années, et les seuls personnes que j'ai croisé à l'utiliser en prod attendent que systemd soit dans Debian.
Donc si c'était si géniale, il y aurait des gens pour le mettre par défaut dans une distro. Curieusement, personne n'a décidé ni de le faire, ni de coder ce truc si simple dont tu parles.
[^] # Re: systemd
Posté par dr_home . Évalué à 2.
C'est pas justement l'objet de solutions comme runit ?
J'avais lu un petit papier pas mal à son sujet, par le mainteneur principal de Busybox...
Si, contrairement à moi, quelqu'un a pris le temps de tester et à des retours, ça m'intéresse d'ailleurs. :)
[^] # Re: systemd
Posté par MrLapinot (site web personnel) . Évalué à 2.
C'est exactement pour ça que runit est fait, et il fonctionne plutôt bien. Il faut juste que les services supportent le fait de ne pas se démoniser (double fork), mais rester attachés au processus qui les a lancés. Et ça ne fait tous les trucs magiques de systemd (comme les socket activation) mais le style « séparons clairement les rôles, faisons des utilitaires de moins de 400 lignes de code et construisons un système propre avec », c'est efficace.
(Après, je n'aime pas du tout le style du code, largement repompé des daemontools de Bernstein.)
[^] # Re: systemd
Posté par dr_home . Évalué à 1.
Je devrais consulter plus souvent mon tableau de bord... Merci pour le retour. :)
Oui, de ce que j'ai lu, dans le cas contraire on gère juste "à l'ancienne" avec un script shell.
[^] # Re: systemd
Posté par MrLapinot (site web personnel) . Évalué à 2.
En fait non, tu vas utiliser un script shell dans quasiment tous les cas, pour passer les options à ton démon (rarement, un lien symbolique vers l'exécutable suffira). Par contre, si un démon fait systématiquement un double-fork, il est vraiment incontrôlable pour runit et ça ne marchera pas du tout (ou alors il faudrait vraiment un script très complexe qui reste attaché et face l'interface et le "polling" du démon d'une manière ou d'une autre, un peu comme systemd il me semble).
Mais encore une fois, je ne connais pas d'exemple de démon qui ne propose pas cette option.
[^] # Re: systemd
Posté par dr_home . Évalué à 1.
À moins qu'il laisse son PID quelque part, auquel cas tu peux bricoler avec ps et kill. Enfin, de toute façon ce genre de démon poserait autant de problème à un sysvinit, donc dans une migration sysvinit -> runit, ce n'est pas une difficulté supplémentaire. Faudra vraiment que j'essaie de bricoler avec runit à l'occasion...
[^] # Re: systemd
Posté par MrLapinot (site web personnel) . Évalué à 2.
Non, justement c'est tout le contraire : dans sysvinit les démons doivent se détacher pour que le script puisse retourner après que tu appelles start.
En gros, dans sysvinit, les scripts servent juste à lancer et arrêter les démons, en espérant qu'ils continuent à s'exécuter correctement dans l'intervalle (en se détachant par double fork). Et dans runit, à l'inverse, les démons restent attaché au processus runsv qui les a lancé, et qui peut donc détecter quand ils meurent et les relancer immédiatement (enfin avec un délai d'une seconde pour éviter de surcharger ton CPU si un démon se plante à répétition). C'est évidemment l'approche de runit qui est la bonne : essayer de maintenir de l'état sans surveiller comme sysvinit, c'est voué à l'échec.
[^] # Re: systemd
Posté par dr_home . Évalué à 1.
Ah oui, j'ai pas pensé que si tu ne peux pas attacher le démon à runit, le ./run va se terminer tout de suite, si bien qu'il va immédiatement embrayer sur ton ./finish. Du coup, même s'il est possible de faire un ./finish avec la même "cuisine" que le "stop" d'un script sysvinit (en s'asseyant grandement sur le monitoring, donc), ça n'avancera quand même à rien (il va passer son temps à démarrer/tuer le démon)... Bon, faudra vraiment que j'essaie pour débrouiller tout ça par la pratique. :)
[^] # Re: systemd
Posté par Batchyx . Évalué à 9.
Et s'il y a un service dans un deadlock, il fait quoi systemd ? il le relance ? Non ?
Alors il te faut quand même un moniteur de services. Parce qu'un service ça peut planter de plein de manières différentes, sans crasher pour autant. Demande à Lennart, il nous à bien pondu un service capable de se mettre dans une boucle infinie.
[^] # Re: systemd
Posté par FreeB5D . Évalué à 5.
Pas d'inquiétude, bientôt Lennart pourra utiliser une toute nouvelle API du noyau Linux qui résout le problème de l'arrêt.
[^] # Re: systemd
Posté par claudex . Évalué à 8.
Ce qui m'inquiète avec systemd c'est son linux-centrisme. Tout est développé avec les dernières api de Linux (ce que je trouve très bien) mais sans prévoir de la généricité dans le code pour développer du code qui n'en tient pas compte. Ça ne me dérange pas le moins du monde qui ne développe pas ce code mais qu'il ne prévoit pas m'inquiète. Ça veut dire que les noyau non-linux (par exemple Debian/kFreeBSD) vont avoir des problèmes mais ça veut aussi dire que quand on aura un successeur à ces api, on devra réécrire en profondeur le système d'init (et la transition ne sera pas facile).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: systemd
Posté par Sébastien Wilmet . Évalué à 1.
Je suis pas sûr à 100% que ce soit la faute de systemd (au début je pensais à un bug du noyau), mais parfois l'ordinateur redémarre au lieu de s'éteindre avec Fedora 15, alors que Fedora 14 n'avait pas ce bug. J'ai eu ce problème sur deux machines différentes (les deux seules où j'ai installé F15…).
Il faudrait que j'essaye Fedora 16 pour voir s'il y a toujours ce bug.
[^] # Re: systemd
Posté par al-info . Évalué à 3.
Il aurait pu faire quelque chose de plus réfléchi avant de passer au système D
----->[]
# Problèmes de Syslog
Posté par nud . Évalué à 9.
Certaines limitations que Lennart mentionne dans son document sont tout à fait connues de tous et une vraie épine dans le pieds de certain.
Morceaux choisis:
Cependant, avec rsyslog:
Quand je vois son projet, certaines idées sont bonnes, mais d'autres sont assez bizarres ou floues. Le fait d'utiliser un fichier binaire est assez bizarre, et je me demande comment il fait avec un fichier append-only pour avoir un accès aléatoire.
Il faut aussi garder à l'esprit que pas mal de services externes (par exemple des téléphones IP) peuvent balancer leurs propres logs sur un serveur syslog, donc même si on remplace rsyslog il faut continuer à supporter le protocole sur le réseau. Et ça c'est mal parti d'après la FAQ.
Par ailleurs, je ne comprends pas non plus pourquoi il développe ça dans le cadre de systemd, plutôt que de faire un projet séparé. Pour minimiser la maintenance peut-être ?
[^] # Re: Problèmes de Syslog
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
Aller au 100 message -> ligne 100
Format libre = souplesse au cours du temps. Des outils comme Perl parse cela sans problème...
Date -> bordel -> timestamp
Base données mysql -> bof. Je verrais plutôt une base de taille fixe à la RRD s'il fallait changer ou plutôt donner le choix !
Non compatibilité avec syslog -> débile
Problème au démarrage -> je croyais qu'il y a avait klogd pour ca.
...
Syslogd n'est pas parfait. Plutôt que de faire des améliorations, on change tout ! Ca va être un produit conçu à la mode du moment. Red-Hat a déjà foutu des fichiers XML de config à droite et à gauche, c'est bien pour les IHM payante de gestion de parc mais c'est loin, très loin d'être parfait. Bref, j'ai pas une confiance à 100% dans tout ce que fait Red-Hat (d'ailleurs, j'ai quitter les distributions Red-Hat il y a plus de 10 ans pour justement des problèmes de conception).
[^] # Re: Problèmes de Syslog
Posté par nud . Évalué à 3.
Et quand tu ouvres un fichier dans un langage de programmation quelconque, tu ne peux pas seeker directement sur la ligne 100, tu dois lire chaque ligne une à une pour repérer les \n. Osef pour la ligne 100, mais la ligne 100000 est déjà plus longue à atteindre, par exemple (exemple assez idiot, on est d'accord) si tu veux faire une interface qui présente les messages de syslog de façon paginée.
klogd est pour le noyau, mais y'a des services qui démarrent avant rsyslog.
[^] # Re: Problèmes de Syslog
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
C'est sur que sur tous mes serveurs, je passe mon temps à accéder à la ligne 100000 des fichiers de log !
Perl est capable de trouver cette ligne très rapidement et c'est pas une action vraiment utile en temps réel sur un OS standard... Que sur un serveur central de log, cela soit utile, OK, mais on peux alors utiliser un backend SQL spécialisé...
Combien de service démarre avant rsyslogd ? C'est le problème de la poule et de l'oeuf... Ni a t'il pas un moyen de gérer cela d'une autre manière. Par exemple, ces applications enverraient leur log au noyau donc klogd tant que syslogd n'est pas actif. Tout remettre en cause et rendre les choses incompatible pour quelques secondes me semble excessif.
[^] # Re: Problèmes de Syslog
Posté par nud . Évalué à 3.
Rassure-moi, tu ne penses pas réellement qu'implémenter un proxy pour le syslog au niveau du noyau est une meilleure solution, n'est-ce pas ?
[^] # Re: Problèmes de Syslog
Posté par ckyl . Évalué à -2.
Bin si, c'est Sytoka Modon. On pourrait presque faire un générateur de commentaire assez facile: si ce n'est pas en Perl et qu'il ne l'utilise pas personellement dans son labo qui est le centre du monde c'est nul. Mais la où ca bloquerait c'est les énormités qu'il sort à chaque fois qu'il parle d'un truc qui touche au dev...
[^] # Re: Problèmes de Syslog
Posté par Sytoka Modon (site web personnel) . Évalué à 9.
Je parle de mon labo car c'est plus intéressant que chez moi, il y a un peu plus de poste à gérer... C'est pas juste un truc avec 10 machines. L'informatique personnelle, un PC = une IP = une personne ne m'intéresse pas particulièrement.
Sinon, j'aime effectivement bien le Perl (et le CPAN), plus que Python par exemple mais je déploie aussi des trucs en Python, PHP... Quand au dev, je n'en fais plus beaucoup mais je préfère poser des questions parfois candides puis changer d'avis ensuite s'il le faut.
Tiens, ca m'intéresse de savoir quelques grosses conneries que j'aurais dites car je ne doute pas d'en avoir dis quelques unes ;-) Au moins, je pourrais me faire un coup d'auto-dérision lundi à la pause café !
[^] # Re: Problèmes de Syslog
Posté par M . Évalué à 2. Dernière modification le 19 novembre 2011 à 18:48.
Solution simple : démarrer un syslogd qui conserverait les logs en RAM tant que le système n'est pas opérationnel (FS, réseau...)
[^] # Re: Problèmes de Syslog
Posté par zebra3 . Évalué à -2.
C'est sûr, faut faire des choix. On n'encule pas une poule sans casser des œufs.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Problèmes de Syslog
Posté par Misc (site web personnel) . Évalué à 6.
Parce qu'un message = 1 ligne ? C'est un chouia simpliste. Quand le kernel me colle 5 lignes pour les fréquences du wifi, tu penses qu'il voulait que j'ai 5 messages séparés, ou un seul message avec des retours chariots ?
[^] # Re: Problèmes de Syslog
Posté par Misc (site web personnel) . Évalué à -2.
Si tu as pas confiance dans ce que fait Red hat, tu utilises pas gcc ( cygnus c'est Red Hat ), les bouts de noyau maintenus par des salariés, les bouts de xorg maintenus par des salariés, les bouts de Gnome, de coreutils, de la glibc, d'udev ou de kvm ( vu que kvm, c'est , bah, Red Hat aussi ) ou les projets ou la boite contribue ?
[^] # Re: Problèmes de Syslog
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Ne pas avoir confiance totale dans une boite ne signifie que tout ce qu'elle fait est de la merde ;-) Pourquoi de suite prendre une position extrême ?
Par ailleurs, dans les exemples que tu donnes, il y a une différence entre aider à maintenir un système et développer un nouveau système... Par exemple, les débuts de network-manager ont été très difficile, l'outil était beaucoup trop lié au fait d'avoir une IHM graphique.
Avec le temps et tous les contributeurs, les outils se bonifient ou trouvent des remplaçant, c'est tant mieux ;-)
[^] # Re: Problèmes de Syslog
Posté par BFG . Évalué à 9.
On va commencer par imposer format minimal et strict, puis on se rendra compte que ce n'est pas suffisant, alors on autorisera des extensions diverses pour chaque application, et le problème sera le même qu'avant. Je propose qu'on appelle ça... "XML" !
[^] # Re: Problèmes de Syslog
Posté par ckyl . Évalué à 6.
Le boulot de clarifier un peu le merdier de syslog (le protocole) a déjà été fait il y a un peu plus de 5 ans. Le but était d'arrêter le délire des 10 implémentations existantes mais incompatibles qui donnait des trucs imparsable alors qu'il y a trois pauvres champs (cf la RFC 3164 qui dressait un état de l'art). Ca a donné la RFC 5424... qui n'a été nul part. Pourtant c'était pas ambitieux mais pratique. Au passage toutes les RFC annexes pour la secu & sont parties aussi à la poubelle. Bref ceux qui s'importe du sort de syslog ne peuvent s'en prendre qu'a eux même. C'est un bordel dégeulasse que personne n'a jamais voulu fixer.
[^] # Re: Problèmes de Syslog
Posté par bubar🦥 (Mastodon) . Évalué à 2.
loa poa kompris ce point là.
[^] # Re: Problèmes de Syslog
Posté par Misc (site web personnel) . Évalué à 2.
La FAQ dit bien que c'est pas un remplacement, mais un systéme à coté. Si quelqu'un veut garder un syslog, il peut. Syslog va sans doute rester ad vitam eternam.
[^] # Re: Problèmes de Syslog
Posté par Michaël (site web personnel) . Évalué à 9.
Ça n'a aucune importance: chaque log doit être analysé selon l'application qui l'a généré. Quelque soit le système que tu utilises, tu ne peux pas utiliser le même outil pour analyser les logs de SUDO, de ton serveur MAIL, de ton serveur HTPP, SMTP, ou FTP, tout simplement parceque ce sont des applications complètement différentes. Le fait de créer un format commun pour les parser n'a pas de gros intérêt parceque de toutes façons l'analyse des contenus doit dépendre de l'application. L'idéal serait que chaque application écrivant des LOGs fournissent aussi un parser pour ses logs. En l'absence de tel parser on survit bien en utilisant les outils UNIX habituels. Utiliser un format structuré complexe nécessiterait donc d'avoir des équivalents de SED, AWK, PERL, SORT, CUT, PASTE, JOIN etc., etc. capables de travailler directement sur ce format, sinon on se retrouve avec une perte de fonctionnalité et une plus grande complexité à l'analyse des fichiers: avantage 0, inconvénients ÉNORMES.
C'est complètement impertinent. Ce qui t'intéresse quand tu lis des logs c'est de lire tous les LOGS et de les filtrer selon certains critères (GREP ou AWK) comme la date, le programme, le client, etc., pour extraire l'information souhaitée. Le numéro de ligne est un atefact qui ne sert à rien.
Le bonne solution à ce problème est d'embaucher un vrai admin système.
La solution existante (SYSLOG) est bien dans l'esprit de UNIX: un système ultra simple que tu peux étendre comme tu veux. Par exemple, tu peux déporter les logs sur un PIPE nommé pour les faire traiter par le programme que tu veux et qui peux te remplir toutes les tables SQL que tu veux.
Sur FreeBSD avec syslogd, on peut, par configuration et avec l'aide de logrotate forcer une rotation quand un fichier dépasse une certaines taille.
À mon avis c'est plutôt parcequ'il ne comprend rien à UNIX.
[^] # Re: Problèmes de Syslog
Posté par nud . Évalué à 2.
Tu ne fais que reformuler la même chose que moi avec d'autres critères, pour lesquels l'analyse des fichiers log est tout aussi inefficace.
Oui, parce que le meilleur admin système du monde est capable de prévoir qu'un relai va déconner à un certain moment et remplir les logs à vitesse grand V, sans monitorer la taille de ses fichiers de logs en permanence ?
Par ailleurs, parfois (genre, en cas de machines hostées chez un client) on n'a pas un controle total sur tout ce qui peut se passer en dehors de sa propre sphère d'influence.
rsyslog ne fournit aucun moyen de contrôle et de limitation de la taille des fichiers, et c'est un réel problème, car remplir une partition est un bon moyen de provoquer un DoS. Peut-être que syslog ne pose pas de problème particulier en opérations courantes, mais quand un problème se présente c'est un gros problème. D'ailleurs je citais ici d'un cas qui m'est arrivé, mais il y a une autre façon très simple de faire générer à syslog des gigaoctets de logs: le flood sur le port 514.
Je peux le faire sous linux aussi avec rsyslog, mais c'est une configuration relativement compliquée qui devrait être très simple vu le risque potentiel. En fait, ce devrait être fait par défaut et être éventuellement un opt-out.
[^] # Re: Problèmes de Syslog
Posté par Jux (site web personnel) . Évalué à 3.
Ou pas... Typiquement, si on fait un outil de monitoring de sécurité, ça peut être intéressant de pouvoir faire une analyse chronologique de ce qui se passe : ah tient, y'a ssh qui me sort 5000 attempts loupés puis sudo qui m'en sort 5000 autres et ensuite y'a un redémarrage de mon serveur HTTP.
Enfin voilà, c'est le premier exemple qui me vient à l'esprit. Je suis sûr qu'il y a plein de gens qui font du monitoring qui vont trouver intéressant le fait de pouvoir potentiellement détecter des patterns en ayant des logs un peu plus structurés.
[^] # Re: Problèmes de Syslog
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Pourquoi utiliser logrotate ? Par défaut, il y a newsyslog et qui n'est pas si compliqué que ça à utiliser (voir le handbook)
# Et après ?
Posté par rewind (Mastodon) . Évalué à 9.
La bonne question, c'est : quel est le prochain morceau un peu vieillissant du système que Lennart va pourrir ?
Moi je parierais sur le shell, je le sens bien nous sortir lesh (LEnnart's SHell) qui casserait tous les scripts POSIX mais qui serait tellement plus bien mieux et qui serait par défaut sur Fedora parce qu'on s'apercevrait que pour systemd, les trucs existants ne sont pas suffisant donc il faudra un shell, et donc ça sera une dépendance obligatoire de systemd ! Dans lesh, toutes les commande usuelles (ls, mkdir, ps, etc) seront des commandes interne pour éviter d'augmenter le numéro de PID, mais bien sûr incompatibles au niveau des options avec les commandes POSIX, sinon c'est pas drôle.
Ou alors, il va s'attaquer à cron et at, pour fusionner les alarmes utilisateurs et les alarmes systèmes, avec un système de droits particuliers pour pas mélanger les deux (ben oui, il faut bien créer le problème pour le résoudre). Ce daemon gèrera en fait tout le temps sur le système et donc la mise à jour du temps via NTP pour ne pas perturber les alarmes. Et puis comme il y a des problèmes avec tzdata en ce moment, il va reproposer un autre truc pour ça, et obliger l'ISO et les gouvernements à s'aligner sur son idée (ben quoi, c'est ça le chemin vers maître du monde !), en tout cas, ça sera implémenté dans sa solution globale.
D'autres idées ?
[^] # Re: Et après ?
Posté par B16F4RV4RD1N . Évalué à 10.
le graveur CD (cd burner), comme ça on pourra dire qu'il nous casse les burns.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Et après ?
Posté par rewind (Mastodon) . Évalué à 6.
Bon, je me corrige : pour le temps, c'est déjà en cours et c'est intégré à systemd :
http://cgit.freedesktop.org/systemd/tree/src/timedated.c
Bon, je reste sur le shell alors...
[^] # Re: Et après ?
Posté par Sufflope (site web personnel) . Évalué à 2.
Bah ça c'est déjà prévu. Ceci dit c'est pas plus idiot, « il est telle heure » ou « il s'est écoulé cinq minutes » sont des « évènements » pas foncièrement différents que « on démarre » ou « tel service a été relancé ».
[^] # Re: Et après ?
Posté par bubar🦥 (Mastodon) . Évalué à 1.
Oui. Que le shell (par défaut ou pas, en possibilité) se trouve capable de prendre en charge automatiquement les signaux et politiques du shell graphique. Ainsi qu'un enregistrement via Journal plutôt que history. Bref que le shell devienne plus central encore qu'il n'est aujourd'hui. Central et à relations directes (policikit / dbus / udev / gvfs / jenpassetdesmeilleures)
troll ou pas troll ?
[^] # Re: Et après ?
Posté par MTux . Évalué à 7.
Le problème du shell par défaut (bash) c'est qu'il est compatible aussi avec FreeBSD, ce qui est intolérable. Il faut développer un nouveau shell, compatible Linux uniquement ! Et faisons-le passer par 450 API, de cette manière là on arrivera à faire crasher le système si on entre trop de commandes à la fois ou si le CPU est chargé.
[^] # Re: Et après ?
Posté par Misc (site web personnel) . Évalué à -2.
C'est déjà fait, ça s'appelle zsh, avec des extensions supplémentaires par rapport à posix ( genre ls avec 2 étoiles , les for et la gestion des espaces, etc ). Ou les extensions gnu de awk, sed, ls, etc. Ou peut être qu'on doit parler du manque d'abstraction des outils comme ip et ifconfig. Ip a été ecrit aprés les BSDs, mais personne n'a ralé pour dire "argh, une api non compatible autrechosequelinux". Et personne n'a non plus pourri openbsd pour ne pas avoir repris ipchains au lieu de pf. Faut se rendre à l'évidence, les BSDs sont depuis toujours ignorés par Linux. Y a juste que le monde tout d'un coup le découvre.
[^] # Re: Et après ?
Posté par MTux . Évalué à 2.
zsh est dispo sur Linux.
[^] # Re: Et après ?
Posté par BFG . Évalué à 4.
bash est aussi une extension au shell POSIX, on a pour preuve les scripts d'initialisation écrits pour bash mais déclarés pour sh qui ne peuvent pas s'exécuter sur un autre shell POSIX (comme "dash" chez Debian).
zsh a lui aussi des extensions, la différence est qu'il a des années d'avance sur bash, et que ses utilisateurs savent qu'écrire "!#/bin/sh" signifie "ne pas tester le script uniquement avec zsh, mais avec un shell purement POSIX", contrairement à la majorité des utilisateurs de bash.
[^] # Re: Et après ?
Posté par nud . Évalué à 0.
Tout simplement parce que leur shell par défaut (/bin/sh) reste souvent bash, et que l'utilisation de zsh reste suffisemment confidentielle pour que s'ils utilisent des zshismes dans leur script, quelqu'un va vite s'en rendre compte.
Il y a peu, bash était le shell par défaut de toutes les distributions linux majeures, mais avec Debian qui utilise dash, par exemple, ça commence à changer... C'est un peu comme les gens qui faisaient des sites web pour IE6 quand il avait 95% de PDM.
[^] # Re: Et après ?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Il est bien là le problème, bash n'est pas le shell par défaut pour tout le monde. Normalement, sh, c'est le Bourne Shell mais chacun fait ce qu'il veut.
Pour la petite histoire, le seul qui essaie vraiment d'être POSIX, c'est le Korn shell donc quand on pousse un système POSIX, on devrait dans l'absolu fournir celui-là en standard plutôt qu'autre chose.
[^] # Re: Et après ?
Posté par briaeros007 . Évalué à 3.
de plus en plus de distrib (dont ubuntu qui a lancé le truc je crois) vont utiliser dash pour sh.
Dash a une compatibilité posix accru par rapport à ksh, et est plus rapide à "démarrer", ce qui permet donc de gagner un peu de réactivité lors du démarrage (entre autre).
[^] # Re: Et après ?
Posté par nud . Évalué à 5.
le D de dash, il veut dire Debian.
[^] # Re: Et après ?
Posté par briaeros007 . Évalué à 3.
au temps pour moi.
Ubuntu semble l'avoir mis par défaut avant debian, c'est pour ça que je pensais qu'ils étaient moteur dessus.
# Bonnes questions, mais…
Posté par Hobgoblins Master (Mastodon) . Évalué à 5.
Les problèmes pointés sur syslog sont réels, mais j'ai du mal avec les réponses apportées.
Comment un sysadmin pourrait-il faire confiance en un système de logs binaires dont le format de stockage est et restera non documenté, pouvant évoluer à tout moment.
Quand je vois que pour la centralisation des logs, il ne propose que rsync, ça laisse songeur. (Le un jour peut-être on fera du réseau si on a le temps, j’y crois pas tant que c’est pas fait).
En plus, le démon de log semble choisir aléatoirement les lignes conservées en fonction de la charge système et de l’espace disque.
Qu’est-ce qui est prévu au niveau de la structure des fichiers logs en cas de crash machine ? La seule mention que je vois s'est :
> It is designed in a way that log data is only attached at the end (in order to ensure robustness and atomicity with mmap()-based access), with some meta data changes in the header to reference the new additions
Le système de fichier dessous à intérêt de bien gérer les crashs et d’être journalisé…
Comme pour syslog, chaque application devra écrire son propre parseur ayant connaissance des UUID spécifiques à l’application pour pouvoir les interpréter…
Il ne parle que de GUI pour lire les logs, donc encore une fois, après PA, et surtout NM, un système bas niveau qui devient inutilisable en console…
Je suppose que son parseur sera assez light pour pouvoir être utilisé depuis un initramfs au cas où systemd plante le démarrage de la machine ?
[^] # Re: Bonnes questions, mais…
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Un système binaire peut à mon avis être intéressant dans le cas de forte charge mais avec un nombre d'entrée pré-définit. une base de type RRD à rotation automatique permet alors un accès direct en écriture. Cela pourrait aussi être un backend à syslog et pourrait servir par exemple pour des log de firewall...
Sinon, les GUI pour lire les log sont tout sauf pratique. C'est bon pour les petits dépannage du genre un installateur d'un soft Windows qui au premier click téléphone déjà a sa hotline ;-) Jamais pu utilisé les journaux Windows tellement c'est peu pratique...
Si j'ai bien compris une partie des débats, un des problèmes majeurs est que syslog n'est pas lancé en premier donc que faire en attendant que syslog soit opérationnel ? systemd ne pourrait pas ouvrir le port le syslog, écouter et tamponner en RAM (ou ailleurs) en attenant que syslog démarre et reprenne le tout ? J'ai cru comprendre que systemd était capable de maintenir les descripteurs de fichier lors d'un redémarrage de service ?
# Point de vue rétro-actif de noob.
Posté par Grunt . Évalué à 10.
Salut,
Ça me fait un peu peur ces innovations, pour les débutants. Pour le tout débutant que j'étais y'a quelques années, Linux avait ça de bien que c'était comme du Lego. Même sans y rien comprendre, je pouvais grosso merdo bidouiller, comprendre le contenu de /var/log par exemple.
S'il faut passer par une base SQL ou je sais pas quoi, ça va poser une sacrée barrière d'entrée à l'auto-formation sur le tas. Ça va faire bientôt 10 ans que je touche à Linux, et je me rends compte qu'en 10 ans j'ai à peu près tout appris sur le tas, en RTFM, en bidouillant, en testant et en cassant.
Si on met une grosse barrière du genre "Apprends le SQL avant de lire les logs", on va accentuer le clivage entre l'utilisateur qui ne comprend rien et l'utilisateur qui commence à comprendre et aime explorer son système.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Point de vue rétro-actif de noob.
Posté par Octabrain . Évalué à 4.
Allons allons, on sait bien que tu adores regedi^Wgconf (et gconf-editor), et que tu rêves de pouvoir enfin cliquer "Menu GNOME" puis cliquer "Panneau de configuration" puis cliquer "Outils d'administration" puis cliquer "Lecteur de journaux.exe^H^H^H^H".
[^] # Re: Point de vue rétro-actif de noob.
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Ce que j'aime bien dans un système UNIX, c'est qu'il y a plein de bout en script au coeur du système, c'est donc assez facile d'intervenir dessus et de l'adapter. C'est aussi une grande force anti-virale... J'aimerais bien que PAM par exemple soit plus facilement scriptable qu'actuellement.
J'ai déjà pris l'exemple du serveur SMTP Qpsmtpd programmé en langage de script. Très facile d'aller y modifier un truc ou deux alors que c'est quasiment impossible à un admin système de base comme moi si c'était un Postfix ou un Exim.
Il est vrai qu'un coeur en script, c'est pas forcément la joie pour les GUI ;-) Sinon, il y a un outil assez sympa, Config::Model, qui pars sur l'idée que plutôt que de vouloir tout uniformiser, tout normaliser, la diversité peux avoir du bien donc c'est à la surcouche de s'adapter. Personnellement, je ne l'utilise pas car vi me suffit dans 99% des cas.
[^] # Re: Point de vue rétro-actif de noob.
Posté par Grunt . Évalué à 3.
Ben.. pourquoi donc? Je me faisais la remarque avec Network-Manager: qu'est-ce qui empêche ce logiciel de stocker sa conf sous forme de commentaires dans /etc/network/interfaces (ou équivalent selon la distro), et d'agir en décommentant/commentant les bonnes parties pour lancer un /etc/init.d/networking restart (ou équivalent selon la distro)?
Avec le même résultat pour l'utilisateur final, ET une bidouillabilité conservée, ET une facilité de "reprise en main" en cas de plantage de N-M ou de volonté de mettre les mains dans le cambouis. Au lieu de ça, il conflicte bêtement avec les réglages en dur.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Point de vue rétro-actif de noob.
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Les IHM qui écrivent les fichiers perdent souvent les commentaires, l'indentation... Je sais qu'il y en a qui y arrive mais c'est pas le plus courant. Le dernier exemple qui me passe par la tête est backuppc qui fait un dump de l'objet config et donc perds tous tes commentaires (d'ailleurs, c'est pas nickel nickel d'avoir fait un dump mais bon).
Ceci dis, l'exemple que tu prends n'est pas le plus facile. J'ai quelques fichiers /etc/network/interfaces qui définissent plus de 20 interfaces réseaux et peut être qu'un interface.d aurait été pas mal. D'ailleurs, le fichier qui me pose le plus de soucis à gérer automatiquement pour le moment est /etc/ssh/sshd_config. Dommage qu'on ne puisse inclure les fichiers d'un dossier dedans car comme c'est un fichier TRES sensible, c'est toujours délicat de faire des grosses modifications dedans !
[^] # Re: Point de vue rétro-actif de noob.
Posté par Grunt . Évalué à 3.
Oui, l'éclatement des configs en foobar.d/fichiers est généralement une très bonne idée. Ça va dans le sens d'une évolution raisonnable et rétrocompatible des systèmes. Rétrocompatible dans le sens où on peut toujours tout mettre dans foobar.conf et virer l'inclusion de foobar.d/* si on veut la jouer à l'ancienne. Et je trouve personnellement que cette rétrocompatibilité est une bonne chose.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Point de vue rétro-actif de noob.
Posté par Misc (site web personnel) . Évalué à 2.
Y augeas pour ça, ça marche très bien.
[^] # Re: Point de vue rétro-actif de noob.
Posté par Misc (site web personnel) . Évalué à 0.
Network-manager peut le faire sur les distributions RHEL et Fedora, donc le souci est plutôt "pourquoi ubuntu et debian ne le font pas".
( https://live.gnome.org/NetworkManager/SystemSettings , cherche 'ifcfg-rh' ).
Transformer les scripts shell en un format hybride ne me parait pas une idée terrible, ne serais que parce ça implique d'avoir le choix entre un parser ultra complexe, ou d'avoir un sous ensemble et donc ne pas être un script shell ( genre, comment tu géres des choses comme toto=$(foo) dans ta config du coté de n-m ). Si le but est d'avoir une configuration qu'on peut lire et écrire, il y a encore une fois déja un plugin ( keyfile ).
Ensuite, Network Manager ne va pas lancer X executables pour changer le réseau quand il peut directement parler au noyau, pour plus de finesse et un meilleur résultat. La façon principale de parler au kernel, c'est des ioctl ( ou écritures dans /proc/ et /sys/ ), pas des outils comme ifconfig ou ip. Les premières sont censé être stable, alors que les 2emes sont la pour les humains et n'ont pas de promesse de stabilité ( d'un point de vue de l'abi ). Les remontés d'erreurs sont assez difficile à faire quand tu n'a pas d'ABI ( ie, pas de standard des codes retours, pas de messages ou de précision sur ce qui ne va pas ).
Il est bien plus simple en C ou n'importe quoi d'autres de pas avoir à faire de parsing que d'avoir à en faire. Surtout quand les outils disent de pas le faire ( genre iwconfig à un moment ).
Ensuite, relancer tout le réseau pour juste un changement est inutile. Si je change le mtu de ma carte ethernet, pourquoi est ce que je devrait relancer network ? Et pourquoi lancer un processus quand on peut éviter ? Ça pose aussi des soucis d'atomicité, si je change juste un paramètre, et qu'il est faux, je dois annuler tout ce qui a été fait avant. Ce n'est pas une chose que les scripts font actuellement.
Enfin, il est plus sur d'appeler directement le noyau plutôt qu'un executable, car les interfaces de communication sont bien plus stricts ( exemple, il y a pas besoin de se casser la tête sur "est ce que le path est correct, est ce que j'ai pas oublié d'échapper un truc".
[^] # Re: Point de vue rétro-actif de noob.
Posté par Sufflope (site web personnel) . Évalué à -1.
Comment ? Tu oses insinuer ici que NM est capable de ne pas se mêler de la configuration distrib-spécifique, pour peu qu'on l'intègre correctement au lieu de l'envoyer sur les dépôts comme un gros sale (le contraire de ce que fait Debian concernant toutes les nouveautés depuis 4 ans, donc) ? Tu seras châtié.
[^] # Re: Point de vue rétro-actif de noob.
Posté par Grunt . Évalué à 2.
C'est plutôt convainquant ce que tu dis, modulo un détail:
Tu veux dire que N-M ne fait pas d'appels à "ip", à "route" ou à "dhclient"? Ça me surprend.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Point de vue rétro-actif de noob.
Posté par Misc (site web personnel) . Évalué à 1.
Mhh aprés verif, il y a appel à dhclient , donc je me suis en partie trompé. Pour le wifi, il y a par contre bien des ioctls. Et pas d'appel à route, ip dans le code. Il y a un plugin pppd pour s'intégrer directement.
[^] # Re: Point de vue rétro-actif de noob.
Posté par barmic . Évalué à 3.
T'es entrain de dire que NM (développé par RedHat) possède un plugin spécifique à RedHat pour faire ça et que Debian et Ubuntu devraient l'utiliser ? Je n'ai pas investigué de trop, mais un plugin dont le nom fais mention de RedHat ne semble pas avoir vocation à être utilisé par Debian.
Si maintenant tu demande pourquoi Debian n'a pas créé un plugin spécifique Debian pour faire ça, je ne sais pas.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Point de vue rétro-actif de noob.
Posté par gnumdk (site web personnel) . Évalué à 2.
Mwai, enfin ca fonctionne très bien sous Ubuntu...
Le problème de Misc, c'est qu'il ne connait que l'env RedHat et passe sont temps à cracher sur Debian/Ubuntu alors qu'au final, il semble qu'il ne l'utilise jamais... Et donc pratique le FUD à outrance...
[^] # Re: Point de vue rétro-actif de noob.
Posté par Misc (site web personnel) . Évalué à 3.
Si la seule chose que tu as, c'est des attaques personnelles non fondés, je pense que tu pourrais faire l'effort d'au moins être correctement renseigné. J'ai bossé 3 ans comme admin sys sur des debians, 1 an à faire une appliance basé sur Debian, donc je pense avoir suffisamment de compétence pour répondre à une question sur linuxfr.
Quelqu'un dit "ça serait bien de faire ça", je dit "ça fait déjà ça sur tel distro" et c'est du FUD ?
[^] # Re: Point de vue rétro-actif de noob.
Posté par gnumdk (site web personnel) . Évalué à 2.
Euh, être admin Debian et utiliser Debian sur le desktop, c'est pas du tout la même chose...
Après, désolé, je n'avais pas vu que tu répondais à une affirmation et que cette dernière n'était pas de toi.
[^] # Re: Point de vue rétro-actif de noob.
Posté par gnumdk (site web personnel) . Évalué à 6.
Bon, en fait, t'es un peu gonflé parce que le plugin pour Debian est documenté dans le même lien que tu as donné :D
[^] # Re: Point de vue rétro-actif de noob.
Posté par nud . Évalué à 1.
Rien n'empêcherait le développement d'un backend 'interfaces-file' similaire au backend keyfile.
[^] # Re: Point de vue rétro-actif de noob.
Posté par barmic . Évalué à 2.
D'où ma phrase :
Mais je trouve tout de même que dire que pour que ça marche il suffit de le développer c'est bien gentil, mais ça signifie que ça ne marche pas.
Alors oui il est probablement plus simple de développer ce backend qu'un pilote, mais quand une fonctionnalité n'existe pas, il vaut mieux éviter de dire qu'elle fonctionne parce qu'il suffit de la développer sinon c'est du marketing.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Point de vue rétro-actif de noob.
Posté par nud . Évalué à 2.
Petite note: je suis un heureux utilisateur de Debian et de Network Manager depuis au moins quatre ans et je n'ai jamais eu de problèmes pratiques. Tout au plus Network Manager se contrefiche de ce qu'il y a dans /etc/network/interfaces, et encore, cela ne m'a pas plus choqué que cela. Que devrait-il faire? placer un inotify sur /etc/network/interfaces?
Je n'ai aucune idée de ce que fait NM sous fedora quand on change le fichier de config réseau.
[^] # Re: Point de vue rétro-actif de noob.
Posté par Misc (site web personnel) . Évalué à 0.
Non je dit que du coté de network-manager, le travail est fait et l'infra est la, et le souci est que personne n'a écrit le plugin.
Ie, RH et Suse se sont chargé de l'intégration jusqu'au bout, Mageia/Mandriva l'ont fait ( mais d'une maniére pas super propre, et on bosse à améliorer ça ), et il manque l'intégration du coté des debian like ( entre autre ).
je dit pas que debian doit passer à la config pour les autres distros, juste qu'il y a possibilité de faire ce que grunt demande.
De la à savoir si c'est la faute des devs de pas avoir fait le taf pour Debian/ubuntu, ou d'Ubuntu/Debian, je ne sais pas. Sans doute la faute des 2, comme souvent quand il ne se passe rien.
j'avais cru voir passer des annonces pour ça dans la version 0.9, mais j'arrive pas à retrouver le post de blog à ce sujet.
[^] # Re: Point de vue rétro-actif de noob.
Posté par barmic . Évalué à 2.
Il me semble que le principale problème c'est le clivage entre RedHat et Debian. Leur différence de configuration, etc. Il est compréhensible que les développeurs créent des applications pour qu'elles marchent sur leurs machines. Je n'ai aucune idée de la raison qui fait que Debian utilise interfaces et RedHat autre chose, mais ça me semble être du même acabit que pour RPM et probablement tout un tas d'autres choses.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Point de vue rétro-actif de noob.
Posté par Batchyx . Évalué à 2.
Si c'était le cas, Network Manager pourrait déjà gérer les vlans, les classes de traffics, les tables de routages multiples, les règles iptables ou même la technologie que Windows 95 gère depuis euh ... 16 ans : les métriques sur les interfaces. Et j'ai pas encore parlé de sans-fil.
Bizarrement, il ne le fait pas. On m'aurai menti ? Lancer des exécutables qui ne font qu'une chose mais qui la font bien donnerai un résultat plus grossier et moins bien ? Remarque, venant de la part de Lennart qui considère que la philosophie Unix est un échec, ça ne m'étonne pas.
Raté. Network Manager parle principalement au noyau via du netlink, tout comme ip. Il fait encore quelques ioctl parce que Lennart est une grosse faignasse^W^W^W^W^Wil doit pas être au courant qu'on peut faire la même chose via netlink. Et ce qui est configurable via /proc/ et /sys/ est un peu risible. La preuve :
[^] # Re: Point de vue rétro-actif de noob.
Posté par Mjules (site web personnel) . Évalué à 2.
Pourquoi tu parles de Lennart ? Le seul commit de lui dans network manager, c'est pour des fichiers .service destinés à systemd.
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=c4d387efb88ab0cc4dea4ae17e60c8360b5e45a8
[^] # Re: Point de vue rétro-actif de noob.
Posté par galactikboulay . Évalué à 2.
Eh ben, ça sent le code de qualitai NetworkManager, avec tous ces chemins codés en dur...
[^] # Re: Point de vue rétro-actif de noob.
Posté par inico (site web personnel) . Évalué à 1.
Cela arrive, NetworkManager n'est pas encore à la 1.0 !
Source: (Blue sky, white sand, and NetworkManager 0.9.2
[^] # Re: Point de vue rétro-actif de noob.
Posté par Batchyx . Évalué à 3.
Et est ce qu'on aura des métriques sur les interfaces ?
[^] # Re: Point de vue rétro-actif de noob.
Posté par inico (site web personnel) . Évalué à 0.
Tu devrais chercher un peu plus, c'est implementé dans nm 0.8.5.923 :)
Filaire (Auto eth0) =[Modifier] => Paramètres IPv4 =[Routes]=> (ta route statique) Métrique
[^] # Re: Point de vue rétro-actif de noob.
Posté par Batchyx . Évalué à 3.
Moi je te parle d'une métrique qui marche dans tout les cas, peu importe comment les routes sont obtenues. Moi je veut juste une métrique (ou un offset de métrique) pour toutes les routes, qu'elles viennent de DHCP, de RA ou de mon cerveau.
[^] # Re: Point de vue rétro-actif de noob.
Posté par Kangs . Évalué à -2.
[^] # Re: Point de vue rétro-actif de noob.
Posté par JGO . Évalué à 1.
J'imagine que des outils de plus haut niveau permettront de consulter les logs, comme il existe actuellement syslogread et syslog-summary pour lire ses logs (ou, dans un autre genre, cnetworkmanager pour gérer NetworkManager en ligne de commande, chose impossible autrement pour l'être humain normalement constitué)
# NOTRE héros Lennart Poettering (parmi d'autres)
Posté par Pseudo007 . Évalué à -8.
En tant que DÉVELOPPEUR (et pas mainteneur même si les développeurs sont souvent des mainteneurs), Lennart est GÉ-NI-AL !!!
Un développeur doit créer, trouver des solutions qui règlent des problèmes, offrir de nouvelles possibilités, etc. En tant que développeur c'est sur ça que doit être évalué Lennart et il est brillant. Si ce qu'il faisait était mauvais, on ne l'aurait pas dans notre distribution, point final. Que ce qu'il développe soit intégré trop tôt dans les distributions n'est pas de sa responsabilité ! Et n'oublions pas un des (presque) principes du logiciel libre qui est : release early, release often .
J'ai lu la moitié des commentaires et c'est simplement consternant. Le logiciel LIBRE n'a pas à être coincé dans l'API UNIX à jamais. Si on peut être compatible, soyons le, si ça aide, profitons-en, etc, mais s'il faut créer du nouveau faisons le au-lieu de garder ses doigts dans le cul en brandissant une excuse bidon.
On lit des "gnagnagna, systemd n'est pas portable, gnagnagna". Si vous savez faire un systemd portable, et bien faites le ! Et ça vous sera d'autant plus facile que vous pouvez prendre le code existant de systemd. C'est ça le logiciel libre. Qui parmi ceux qui dénigrent Lennart et donnent des leçons le font ? Personne. Même l'hyper décrié Pulseaudio n'a pas vu le bout d'un début d'initiative pour faire un remplaçant, que des paroles pour dénigrer, que des donneurs leçons, que des postures. Lennart expose ses idées de logiciel, il écrit du code. Ses paires approuvent (ou pas), et participent (ou pas). En général il a le soutient des autres développeurs (seul il ne peut pas tout faire). Les distributions évaluent ce qui est proposé, en général elles adoptent. Ce sont des faits, pas du blabla.
Je vois ici principalement de la jalousie crasse.
[^] # Re: NOTRE héros Lennart Poettering (parmi d'autres)
Posté par gnumdk (site web personnel) . Évalué à 2.
Ah non pas lui...
[^] # Re: NOTRE héros Lennart Poettering (parmi d'autres)
Posté par Michaël (site web personnel) . Évalué à 5.
Il ne faillait pas que tu te concentres sur les commentaires avec un score négatif. ;)
Plus qu'une API dont on serait prisonnier ou non, UNIX est une philosophie et une méthodologie de travail éprouvée dont trois principes fondamentaux sont:
Si on crée un outil qui respecte ces trois points, alors tout utilisateur UNIX expérimenté pourra l'utiliser de façon optimale en très peu de temps, car il dispose déjà de toute la méthodologie: en clair il n'a qu'à apprendre ce qui est propre à l'application mais sait comment manipuler les données qu'elle va lui fournir. Tandis que si un outil ne respecte pas ces points, alors outre ce qui est propre à l'application, il faut apprendre de nouveaux protocoles et de nouveaux outils pour utiliser les données de l'application. Si tant est que ces outils existent…
Il y a un
ede trop dans cette phrase, qui devient fort amusante!Oui sûrement…
[^] # Re: NOTRE héros Lennart Poettering (parmi d'autres)
Posté par romrom . Évalué à 0.
Bon même si la prose de Pseudo007 est particulièrement agressive, je suis complètement d'accord avec lui en ce qui concerne systemd (je n'ai pas essayé PA) : en tant que développeur et pour avoir été obligé d'endosser plusieurs fois le rôle de sysadmin (bien malgré moi), je trouve que systemd est un
grandénorme pas en avant.Je me souviens, il y a quelques années, quand j'ai été obligé de faire mon premier script d'init sysv et que je fût confronté à start-stop-daemon, je me suis dit "Nan, c'est pas possible ! Mais comment font les autres pour rester zen ?"
J'avais déjà été soulagé avec upstart mais là je suis franchement convaincu. Alors c'est sûr, au début on s'y perd un peu. Il faut réapprendre, retrouver ses repères, etc. Il y a aussi quelques défauts de jeunesse (la plupart résolu au fur et à mesure) mais au bout du compte quel bonheur d'avoir un programme aussi fondamental débarrassé de toutes ces vieilleries.
Pour moi, toute velléité à son égard s'apparente à du luddisme pur et dur car pour l'instant, toutes les critiques que j'ai pu lire sont sans réel fondement (ce que je peux comprendre aisément car je sais que bouleverser nos vielles habitudes peut être pénible).
[^] # Re: NOTRE héros Lennart Poettering (parmi d'autres)
Posté par gouttegd . Évalué à 3.
Je suis d’accord avec le diagnostic : les scripts d’initialisation « à la System V » sont abominables. Mais je suis sceptique sur le traitement proposé : refondre tout le système d’init juste parce que certaines distributions ont complexifié les scripts à mort, ça me paraît exagéré. Pourquoi ne pas plutôt revenir (ou rester) à des scripts simples, comme on en trouve sur Slackware ou a fortiori les *BSD ?
Rien n’oblige à utiliser init avec des scripts imbitables. Tordre les scripts au point de les rendre incompréhensibles, puis dire « regardez comme c’est compliqué, vous voyez bien qu’il est temps de remplacer init », je trouve ça un peu fort.
[^] # Re: NOTRE héros Lennart Poettering (parmi d'autres)
Posté par romrom . Évalué à -3.
C'est pas faux mais il reste de-facto plein de code redondant d'un script à l'autre (ex: gestion des pids) et systemd propose de base des fonctionnalités dont ne disposent pas, de base, les scripts (ex: redémarrer automatiquement en cas de plantage)
Et puis quand on compare, par exemple, le script pour openssh sous Slackware (rc.sshd) et pour systemd (sshd.service) force est de reconnaître que le second est malgré tout plus court et plus explicite.
Après je suis aussi d'accord que la philosophie UNIX en prend pour son grade mais bon... est-ce si dramatique ?
Enfin bref, les goûts, les couleurs...
[^] # Re: NOTRE héros Lennart Poettering (parmi d'autres)
Posté par gouttegd . Évalué à 8.
Remplacer /sbin/init n’est pas, en soi, contraire aux principes d’UNIX. Utiliser une syntaxe de configuration dédiée plutôt que des scripts shell non plus (même si les scripts apportent une souplesse qu’une syntaxe de configuration à base de clefs et de valeurs ne peut à mon avis pas égaler).
Mais vouloir faire du remplaçant d’init un super programme se chargeant d’à peu près tout, depuis le (re-)démarrage des démons jusqu’à la connexion des utilisateurs, et faire que d’autres couches du système (comme la gestion des logs) en dépendent entièrement, sans même me référer à la « philosophie UNIX » et au principe du un-programme-pour-chaque-tâche j’ai du mal à voir ça comme une bonne idée.
[^] # Re: NOTRE héros Lennart Poettering (parmi d'autres)
Posté par Michaël (site web personnel) . Évalué à 4.
C'est sûr! Essentiellement la configuration des init dans FreeBSD est a base de clefs/valeurs (rc.conf) et on a la souplesse des scripts shell — puisqu'il s'agit de script shells!
Si on travaille pour entreprise qui vend du support pour les logiciels qu'on fabrique, alors l'idée deveint bien plus intére$$ante.
[^] # Re: NOTRE héros Lennart Poettering (parmi d'autres)
Posté par barmic . Évalué à 1.
Il est bien probable qu'un Domain-specific programming language soit plus pertinent tout en étant extrêmement simple à utiliser (j'ai l'impression que c'est plutôt vers ce genre de solutions que l'informatique se dirige d'une manière général).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: NOTRE héros Lennart Poettering (parmi d'autres)
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
C'est dramatique si systemd est un et un seul programme qui tourne avec le PID=1 ! Le PID=1, c'est un peu comme le compte root, c'est un programme à part qu'on ne relance jamais... Il est très important qu'il y ai le moins possible de mise à jour de sécurité sur ce programme par exemple sinon on va se retrouver dans le situation de Windows à devoir rebooter en permanence (cela s'est amélioré).
Dans mes scripts d'init, j'ai aussi une cible status qui me dis un peu plus que ca marche ou pas. Souvent, je fais un cible init a utiliser une fois la première fois... Bref, avoir un vrai langage est un plus.
Simplifier les scripts d'init est effectivement une bonne chose. Avoir un shell réduit comme dash pour Debian est une bonne voie. Enrober tout cela d'un "runit" serait mieux. Un init en petite brique permet de changer une brique par une autre, de rajouter des briques non prévu au début (gestion des cgroup qui n'était pas au programme il y a 10 ans)...
Je viens de m'amuser à faire un
( cd /etc/init.d ; wc * | sort -n )
La grande majorité des scripts sous debian fait moins de 150 lignes en comptant les commentaires. On pourrait faire quelques factorisation ici ou la mais c'est globalement propre. Ce qui est un peu crade coté programmation, ce sont les meta commande INIT INFO en commentaire dans ce même fichier. D'un autre coté, c'est aussi la technique utilisé par les gestionnaires de batch sur les machines de calcul...
Bref, simple, robuste et ouvert sur les innovations du futur
[^] # Re: NOTRE héros Lennart Poettering (parmi d'autres)
Posté par Michaël (site web personnel) . Évalué à 3.
Je préfère comparer le script pour openssh sous FreeBSD et sous systemd:
Le script sous FreeBSD est beacuoup plus long, mais il fait beraucoup plus de choses! Il s'occupe de générer la clef du serveur, lorsque ceci est nécessaire. Ce processus mis à part le script est
Le progrès introduit par
systemden termes de clarté et de briéveté n'est pas si clair…En fait le système à la BSD permet de regrouper les ordres de haut niveau pour commander un serveur dans un endroit bien défini, et a pour second avantage de fournir un cadre commun pour la configuration des serveurs. Voir les pages de man de rc.conf et rc.subr.
[^] # Re: NOTRE héros Lennart Poettering (parmi d'autres)
Posté par zebra3 . Évalué à -6.
Sauf que systemd à la base est pour Linux. Tant mieux si le système d'init FreeBSD est plus clair, mais pour l'instant Lennart se concentre sur celui de Linux.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: NOTRE héros Lennart Poettering (parmi d'autres)
Posté par FreeB5D . Évalué à 4.
Qui est proche de celui de Slackware et Arch, des distributions Linux.
[^] # Re: NOTRE héros Lennart Poettering (parmi d'autres)
Posté par romrom . Évalué à 0.
J'avoue que je suis bluffé... va falloir que je pense à jeter un coup oeil aux différents BSD un de ces quatres, moi ;)
[^] # Re: NOTRE héros Lennart Poettering (parmi d'autres)
Posté par Michaël (site web personnel) . Évalué à 4.
Oui c'est dramatique, parcequ'au delà d'une philosophie c'est une méthodologie de travail et en dévier induit une baisse temporaire de productivité (il faut apprendre des procédés complètement nouveaux) ce qui n'est rentable que sur le long terme et que si la productivité du nouveau système est supérieure à celle de l'ancien.
# MDR
Posté par Anthony Jaguenaud . Évalué à 6.
Bon, j’ai pas suivi sur d’autre action de notre cher protagoniste.
Mais aujourd’hui, un certain nombre d’entre vous préconise le développement qui casse toute compatibilité. Où sont passés nos Linuxiens qui râlaient parce que Photoshop n’était pas porté sur Linux ? En disant qu’il fallait faire des applications portables ? À l’inverse, on entend maintenant : « Ils n’ont qu’a suivre ! ».
Chez moi, les logs sont binaires, des stats sur l’histogramme des octets utilisés montre une forte prédominance entre 32 et 128. Il y a même un petit pic vers 10.
Quand à l’illisibilité, je préfère du texte. Un bon mode, highlight pour emacs, vim… suffit pour si retrouver. Alors, que sur un serveur qui a 2 ans, analyser un log sur une machine ayant une autre version du système de log risque d’être drôle.
[^] # Re: MDR
Posté par VictorAche . Évalué à 2.
Pour ce qui est des applications portables, faut quand même faire la différence entre un outil système et une application.
"The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln
# Certitudes et habitudes
Posté par Phylyppe . Évalué à -4.
Mais qu'est-ce qu'il vous a fait Lennart ?! Mis à part bouger vos habitudes et certitudes ?
Quoi que pour les certitudes, c'est pas gagné pour tous ...
Bon, si je n'ai pas au moins un commentaire avec un début comme celui là ;-)
Perso, je suis plutôt fan. Mais je prend que ce qui m’intéresse. Je suis aussi, principalement avec Fedora (pas que).
- Pulse audio ne m'a pas trop posé de problème. Si ce n'est qu'il faut que j'active ou pas le son, car il ne l'est pas systématiquement. Et j'ai eu quelque problème avec une WebCam dont le micro passait avant mes sorties audio, mais c'est maintenant réglé.
- NetworkManager, je le désactive systématiquement sur mes PC fixes et sur mes portables je lui laisse uniquement le contrôle du WiFi. J'ai pris cette habitude car à une époque NetworkManager et livirtd ça n'allait pas bien ensemble. IL semblerait que ça aille mieux.
- Avahi. Je m'en fou. Je le désactive systématiquement.
- Systemd. Ça, ça me parait une bonne chose. J'ai lu avec passion son blog sur le sujet. C'est passionnant. Que l'on soit d'accord ou pas, ça ne peut être que passionnant. Sinon, c'est vraiment dommage.
- Journal ?
Concernant Journal, j'ai d'abord lu linuxfr, puis l'indtroduction à Journal de Lennart.
J'ai noté quelques problèmatiques soulevées ici, qui me paraissaient importantes, et j'ai trouvé les réponses dans l'introduction de Lennart.
**Sécurité **
The Internet is a dangerous place. Break-ins on high-profile web sites have become very common. After a successful break-in the attacker usually attempts to hide his traces by editing the log files. Such manipulations are hard to detect with classic syslog: since the files are plain text files no cryptographic authentication is done, and changes are not tracked. Inspired by git, in the journal all entries are cryptographically hashed along with the hash of the previous entry in the file. This results in a chain of entries, where each entry authenticates all previous ones. If the top-most hash is regularly saved to a secure write-only location, the full chain is authenticated by it. Manipulations by the attacker can hence easily be detected.
Sécurité bis
So you are splitting up journal entries based on the user ID of the user sending them. But how do you make sure that the user doesn’t lie about who he is?
Thankfully, the Linux kernel supports SCM_CREDENTIALS, which provides us with information about the sender of a message he cannot fake.
Réseau
In the initial version journald’s network support will be very simple: to share journal files across the network, simply copy them to a central host with a tool like scp, rsync or via NFS. The journal browser client tool will then transparently merge these files, interleaving them as necessary. In a later version we plan to extend the journal minimally to support live remote logging, in both PUSH and PULL modes always using a local journal as buffer for a store-and-forward logic. Regardless which mode of transportation is used, the underlying journal format is designed to be scalable to large numbers of hosts and all entries are identified by both the machine ID and the host name. The goal is to implement an efficient journal monitoring tool that can browse journals from a multitude of hosts transparently and live, while leaving to the administrator the choice of transport so that he can adjust it to his own needs, i.e. whether live functionality is more important than avoiding the thundering herd, and other considerations.
Réinventer la roue
Why do you guys reinvent the wheel, again? Why not just add what you need to existing syslog? If you just clean up your log formatting, syslog should be fine!
Well, sometimes improving an existing solution is the way to go, but when the changes necessary are too major a reinvention is a good thing, if it is done for the right reasons, and provides good compatibility with previous solutions. We believe we are doing it for the right reasons, and we try hard to provide greatest possible compatibility.
And no, just fixing the log formatting won’t get you much. Not even the most basic requirements like binary blobs or sensible structured logging. Let alone stuff like indexing or proper access control.
Format binnaire
Will the journal file format be standardized? Where can I find an explanation of the on-disk data structures?
At this point we have no intention to standardize the format and we take the liberty to alter it as we see fit. We might document the on-disk format eventually, but at this point we don’t want any other software to read, write or manipulate our journal files directly. The access is granted by a shared library and a command line tool. (But then again, it’s Free Software, so you can always read the source code!)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.