Bon, le titre trollesque, c'est juste pour attirer le chaland. En fait, c'est plus subtil.
Daniel Kahn Gillmor (alias dkg) a testé systemd sur Debian. Il y trouve des points positifs : la gestion des daemons, la gestion saine des états des processus, l'élimination de la redondance dans les scripts init, le démarrage des services réseaux. Bref, tout ce qui convient à un serveur robuste se trouve dans systemd.
Mais il est aussi inquiet. Principalement par deux choses :
- d'une part, systemd a besoin d'autres briques qui sont plutôt destinées aux desktops, comme dbus, et dont on aimerait se passer sur un serveur (d'où le bloat). Les commentaires apprennent que dbus n'est qu'un outil pour éviter de réimplémenter un n-ième système d'IPC.
- d'autre part, il critique l'aspect linuxocentré de systemd. À l'heure où Debian permet d'utiliser le noyau de FreeBSD, il serait dommage de s'enfermer dans un système mono-culture, pense-t-il.
Pour lui, la solution consisterait à séparer les fonctionnalités serveur utiles du reste. Malheureusement, la manière de faire de Lennart Poettering fait qu'il est difficile à l'heure actuelle d'avoir cette séparation.
Enfin, la cerise sur le gâteau, au début de son test, il a eu droit à un beau coredump dû à un assert dans systemd. Il pense que, même si ce bug a été résolu rapidement et trivialement, le logiciel qui prétend devenir un jour le PID 1 devrait peut-être être un peu plus tolérant aux assertions loupées.
# gn
Posté par Guillaume Knispel . Évalué à 10.
Cette phrase me laisse songeur.
[^] # Re: gn
Posté par rewind (Mastodon) . Évalué à 10.
C'est simple : il ne s'agit pas d'écrire un logiciel aussi sensible comme un goret en mettant plein d'assertions partout qui font que dès qu'il y a le moindre petit truc qui ne va pas, ça plante. C'est le premier processus, s'il plante, rien ne peut se lancer, c'est quand même très gênant. Un petit exemple : si j'ouvre un fichier avec
fopen, je peux très bien mettre unassert(f != NULL)juste après, parce que la plupart du temps, ça va marcher. Mais dans le cas deinit, il vaudrait mieux savoir quoi faire au cas où on ne puisse pas ouvrir le fichier et continuer autant que faire se peut, parce que sinon, tout est bloqué.[^] # Re: gn
Posté par Sébastien Koechlin . Évalué à 10.
Je doute que systemd soit écrit comme un goret, ta vision de l'usage des assertions est loin d'être universelle, et beaucoup de monde considère que la présence d'assertions est justement la marque d'un logiciel réfléchis. Tout le fonctionnement d'ADA beaucoup utilisé dans les systèmes critiques est justement basé sur des assertions.
Dans le cas du logiciel en général, et tout particulièrement dans le cas d'init, on souhaite premièrement avoir un logiciel sans bug. C'est cette qualité entre autre qui fait le succès du kernel Linux (dans lequel il y a des assertions). Et la chasse aux bugs se fait bien plus facilement en remontant les anomalies au plus tôt et en validant les données par des contraintes plutôt que de les utiliser naïvement en espérant que ça passera. Une anomalie non traitée va très certainement provoquer d'autres problèmes un peu plus loin, qui vont être plus compliqués à diagnostiquer et à traiter.
La tolérance aux bugs est un autre point qui concerne tout particulièrement init comme tu l'indiques. Comme il est a mon avis impossible de traiter tous les cas tordus qui risquent de se produire, et qui ne sont pas forcément liés à des bugs de l'exécutable, il serait préférable d'avoir un mécanisme capable de reprendre en cas d'erreur, par exemple en re-lançant le programme a son point de départ ou à un point connu. Ces mécanismes sont déjà utilisés dans un certain nombre de logiciels tel que bind, apache, syslog-ng... Ils ne corrigent pas magiquement tous les bugs et les erreurs, mais permettent juste d'assurer la continuité de service.
[^] # Re: gn
Posté par M . Évalué à 6.
Dans le cas du logiciel en général, et tout particulièrement dans le cas d'init, on souhaite premièrement avoir un logiciel sans bug.
Dans ce cas on fait un truc minimaliste et simple, pas un truc qui essaye de tout faire, qui a des interaction avec l'extérieur via IPC [1].
[1] Surtout dbus, je n'arrive pas a comprendre comment un truc qui ce voulait simple est arrivé à une telle API. "D-Bus is a message bus, used for sending messages between applications.
Conceptually, it fits somewhere in between raw sockets and CORBA in
terms of complexity.". C'est bien plus proche du corba que des sockets...
[^] # Re: gn
Posté par Albert_ . Évalué à 6.
Surtout dbus, je n'arrive pas a comprendre comment un truc qui ce voulait simple est arrivé à une telle API. "D-Bus is a message bus, used for sending messages between applications.
Conceptually, it fits somewhere in between raw sockets and CORBA in
terms of complexity.". C'est bien plus proche du corba que des sockets.
Si j'etais mechant je dirais qu'une bonne techno, DCOP, pondu par KDE a ete pervertie par Gnome pour produire DBUS et curieusement cela ressemble, d'apres ce que tu dis, a du CORBA l'ancien dada de ce projet.
[^] # Re: gn
Posté par Antoine . Évalué à 5.
Oui, et puis afficher un message d'erreur compréhensible aussi.
Notons de plus que les
assertsont désactivés en mode non-debug, c'est-à-dire sur l'immense majorité des configurations.[^] # Re: gn
Posté par Guillaume Knispel . Évalué à 2.
Désactiver les assert d'un logiciel buggé -- dans lequel elles mettent justement ces bugs bien en évidence au lieu de se contenter que les bugs générent des plantages potentiellement encore plus catastrophiques, trous de sécu et autres joyeusetés -- n'est sans doute pas une idée qui fera l'unanimité. Pour jouer dans son garage, pourquoi pas, pour une utilisation plus sérieuse, ça persiste à augmenter mon niveau de perplexité.
# Un systéme d'ipc sur un seveur OMG
Posté par Misc (site web personnel) . Évalué à 8.
Quoi, des IPCs sur un serveur. Mais aucune boite n'oserait proposé ça. Ah si, Sun l'a fait avec rpc. Et aussi Microsoft avec Samba, dans une moindre mesure. Et puis, des IPCs dans unix, ben y a que ça. Et puis, des interfaces RESTs aussi. Et puis des appels à distances erlang pour ejabberd.
Soit on fait un systeme sans meta data ( genre signaux, /dev/initctl ), soit on fait un truc plus riche car on a des trucs plus riche à gérer. À partir de la, reprendre l'existant est semble t'il meilleur que repartir de 0.
Concernant l'assertion, il s'agit d'un vrai bug corrigé :
http://cgit.freedesktop.org/systemd/commit/?id=a133bf10d09f788079b82f63faa7058a27ba310b
Le fait de compiler en désactivant les assertions est aussi possible, IIRC. Donc ( si je me trompe pas ) c'est charge aux distros de rendre systemd plus tolérant.
[^] # Re: Un systéme d'ipc sur un seveur OMG
Posté par Littleboy . Évalué à 6.
Et lorsque le code continue a s'executer avec une condition non satisfaite et plante ou corrompt des donnees, on considere que c'est plus tolerant?
La demande, c'est d'avoir une gestion des erreurs plus complete, pas de virer les assertions et laisser systemd planter miserablement plus loin dans le code.
J'ai deja vu du code qui faisait ca, et ben ca fait peur:
[^] # Re: Un systéme d'ipc sur un seveur OMG
Posté par gst . Évalué à 7.
hmm, ça peut faire peur mais pas nécessairement, par exemple si la fonction dans laquelle se trouve ce code est du genre:
ici le assert est totalement légitime, voire souhaité. amha.
[^] # Re: Un systéme d'ipc sur un seveur OMG
Posté par dcp . Évalué à 3.
tout à fait. Cf programmation contractuelle.
[^] # Re: Un systéme d'ipc sur un seveur OMG
Posté par nicolas . Évalué à 6.
0:)
J’appelle ça la programmation par contrat-ou-ça-te-pêtera-à-la-gueule, ou encore : t’avais qu’à lire la documentation couillon !
[^] # Re: Un systéme d'ipc sur un seveur OMG
Posté par Gof (site web personnel) . Évalué à 6.
Mais, si par malheur il y a un bug à un endroit ou un autre dans le code qui appelle cette fonction, dans un cas tu aura
ASSERT "data != null" in monfichier.c:42et dans l'autre
segmentation faultEt pas plus d'info sans sortir un débuggeur.
[^] # Re: Un systéme d'ipc sur un seveur OMG
Posté par gst . Évalué à 5.
bah oui c'est sûr, la doc c'est pas fait juste pour faire beau, normalement.
bon après, le risque inhérent à ce type d'usage, ça dépend surtout de l'audience de la fonction :
si c'est une fonction librairie destinée à être utilisée par tout un chacun (donc des couillons) alors cette obligation se DOIT d'être clairement documentée/définie/autre. Si par malheur le couillon donne quand même un NULL à la fonction dans un cas très particulier de son code et que ça pête une centrale nucléaire dû à un équipement de refroidissement qui est sur son cul dû fait que le soft le controllant est simplement planté alors Fukushima^² quoi !
[^] # Re: Un systéme d'ipc sur un seveur OMG
Posté par nicolas . Évalué à -1.
« t’avais qu’à lire la documentation couillon ! »
« ça dépend surtout de l'audience de la fonction »
Aurais-je oublié de préciser que la majorité de mes codes sont pour mon usage personnel ? :) Plus sérieusement je n’aime pas trop multiplier les tests de validité, sauf entrées de l’utilisateur. Je préfère largement bien préciser ce qu’attend la fonction en entrée (le Python est un régal pour ça…) et m’y tenir.
[^] # Re: Un systéme d'ipc sur un seveur OMG
Posté par Dr BG . Évalué à 3.
Oui enfin, souvent l'erreur n'est pas faite à l'appel direct de la fonction, mais bien avant. L'erreur se propage sans causer d'erreur apparente, puis vient l'appel de ta fonction où ça explose. Faire des vérifications un peu partout aide à trouver plus facilement où ça a merdé, mais aussi à avertir qu'une erreur a été détectée. Sans ça, le code pourrait très bien continuer à tourner, mais avec un fonctionnement qui n'est plus garanti.
[^] # Re: Un systéme d'ipc sur un seveur OMG
Posté par nicolas . Évalué à 0.
Faire des vérifications de ce style au petit bonheur la chance n’a jamais garanti le bon fonctionnement d’un programme.
Par contre bien définir les ensembles d’entrée/sortie, minimiser les effets de bord, si. (/Me commence à être tenté par la programmation fonctionnelle:).
[^] # Re: Un systéme d'ipc sur un seveur OMG
Posté par Guillaume Knispel . Évalué à 1.
euh avec l'assert ça te pête aussi à la gueule hein. Mais plus poliment, plus utilement, et parfois avec moins de trous de sécurité. Par contre vouloir dans une biblio userspace (ou plus généralement dans le même espace d'adressage et du même niveau de privilège) faire du EINVAL absolument partout en essayant de couvrir 100% des codes paths de mauvaise utilisation, et le tout sans jamais d'effet de bord néfaste, relèverait du fantasme et nécessiterait des soins psychiatriques d'urgence.
[^] # Re: Un systéme d'ipc sur un seveur OMG
Posté par pasScott pasForstall . Évalué à 8.
Moi ce qui me fait peur, c'est pas le assert, pourquoi pas, mais plutot le:
sizeof(data->buffer[0]) sans verifications d'indice et le memcpy de boeuf sur une technique de "a-zy, ca rentrera, pis si ca rentre pas, tu pousses un peu et tu bourres..."
c'est bien cool de checker que data est non nul, mais si c'est pour dereferencer un tableau juste apres en decidant qu'il fera telle taille sans en avoir la moindre idee, honnetement pourquoi se faire chier avec le premier assert?
Et note que je ne parle meme pas du memcpy de cowboy
J'allais dire "il manque peut etre des lignes qui viennent avant pour etre sur que ca a pas ete verifie", mais acceder a data->buffer avant assert(data != nil) c'est un peu couillon quand meme :)
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Un systéme d'ipc sur un seveur OMG
Posté par Alex . Évalué à 2.
Pourquoi il est moinsé ?
Perso c'est aussi ce qui me choquait dans ce code
[^] # Re: Un systéme d'ipc sur un seveur OMG
Posté par pasScott pasForstall . Évalué à 3.
Ma nature de dissident linuxfaitrien qui a l'outrecuidance ne pas dire du mal d'apple me fait poster a -2 par defaut.
La derniere fois j'ai prit -10 pour avoir dit qu'ios est gratuit.
D'apres baud123 j'ai un karma proche du zero absolu, ceci explique cela.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Un systéme d'ipc sur un seveur OMG
Posté par shbrol . Évalué à 3.
Pourquoi veux tu faire une vérification d'indice ici ?
[^] # Re: Un systéme d'ipc sur un seveur OMG
Posté par pasScott pasForstall . Évalué à 0.
Si le mec verifie son pointeur initial, c'est qu'il sait pas trop d'ou il vient.
S'il sait pas trop d'ou il vient, buffer peut etre null ou vide.
Si c'est le cas, ca va faire paf pasteque.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Un systéme d'ipc sur un seveur OMG
Posté par shbrol . Évalué à 8.
sizeof est évalué à la compilation, buffer peut etre null ou vide à l'exécution, ca n'a aucune importance.
[^] # Re: Un systéme d'ipc sur un seveur OMG
Posté par reno . Évalué à 3.
Je ne comprends pas trop les histoires d'IPC, un processus sans IPC ça n'est pas très utile!
Alors OK sous *nix, il y a beaucoup d'IPC, bah il y a aussi beaucoup de shells (ksh, zsh, bash, sh,..),
ou est le problème exactement?
# Même si le liens est dispo en fin de l'article pointé...
Posté par cosmocat . Évalué à 8.
il serait peut-être bon, avant, de lire le post de présentation de Lennart avant (car il me semble que c'est somme toute un réponse à ce post) :
http://0pointer.de/blog/projects/
[^] # Re: Même si le liens est dispo en fin de l'article pointé...
Posté par bubar🦥 (Mastodon) . Évalué à 4.
C'est lumineux.
Bien que forcément positif (donc pincettes) ce résumé met en lumière cela, entre autre :
Malgré son aspect bloatware, et malgré son linuxcentrisme. Et malgré que la présentation pose forcément pas mal de question au péquin de base (telle que : respawning on services crash without loosing connection... [goût de marketting] heu il fait le café aussi ?. Ou ck/pk integration : à ce niveau c'est utile ???
... bref ça a tout l'air d'une très belle avancée.
/avide_de_vos_lectures
[^] # Re: Même si le liens est dispo en fin de l'article pointé...
Posté par Gui13 (site web personnel) . Évalué à 9.
Je kiffe le gros troll sur Git, Subversion et Bazaar, dans la section "Miscellaneous" :-)
[^] # Re: Même si le liens est dispo en fin de l'article pointé...
Posté par jean . Évalué à 8.
J'ai rien contre systemd ou Lennart (je suis sous FreeBSD) mais l'article que tu donnes en référence a quelques traits franchement ridicules. Par exemple il y est écrit:
Sympa la victoire à plate couture auto-proclamée ... Mais jetons donc un œil à ces catégories. Vers le début:
Première information: shell-free bootup est un aspect positif. Deuxième information: c'est tellement positif que je le compte deux fois: vu que les deux autres utilisent le shell pour la procédure d'amorçage, c'est clair qu'on ne peut pas y coller des modules en C.
De plus en y regardant de plus près, le deuxième point est plutôt mauvais pour systemd, puisque les fonctions sont rendues par des modules, qui peuvent être écrits dans n'importe quel langage puisque le SHELL est utilisé pour coordonner l'éxécution de ces programmes.
Et maintenant
Qu-est-ce que c'est que ces
no? À la fin de la procédure d'amorçage à la systemv les systèmes de fichiers ne sont pas montés peut-être? À moins qu'il veuille dire que le démon puisse s'occuper de monter et démonter les disques à la demande de l'utilisateur? C'est bien mais il y a déjà les commademountetumountpour ça, non?Il y a beacuoup de features saugrenues et son as the tables above hopefully show in all clarity est loin de me convaincre: elle ressemble plutôt à une tentative piteuse de rationnaliser une préférence personnelle.
Pourtant son initial announcement de systemd est plus persuasif mais son
systemda quand-même un gros côté fourre-tout: en gros tout ce qui est susceptible de démarrer un programme se retrouve danssystemd: ainsi les dæmons classiquesinetdse retrouve dupliqué par le modulesocket, etc. L'intérêt de ces modules n'est pas motivé, vu quesystemdest présenté comme un outil d'amorce qui permet de booter la machine plus rapidement, il me semble qu'il fallait plutôt modifier un peuinetd' pour qu'il signale les services qu'il lance àsystemd` (d'ailleurs cela ferait moins de roues réinventées).Si j'ai bien compris sa présentation les deux aspects intéressants de
systemdsont:Comme de plus en plus de démons utilisent dbus pour se synchroniser au démarrage et bien on a intérêt à démarrer dbus le plus rapidement possible: OK, ce n'était certainement pas la peine de réecrire toute la séquence d'amorçage pour faire ça.
Every executed process gets its own cgroup
Cela devrait permettre d'améliorer la gestion des services sur la machine. C'est bien.
Et le reste des features c'est franchement du remplissage et de la duplication de fonctions existant déjà.
[^] # Re: Même si le liens est dispo en fin de l'article pointé...
Posté par Michaël (site web personnel) . Évalué à 3.
Je suis plutôt d'accord avec toi, mais tu as eu un problème de citation apparemment. Les premiers ce doit être:
et les autres autour de
Mount handling
c'est ça?
En la regardant de près, cette liste semble plutôt être celle des features de systemd qu'une comparaison! Tu as raison, il y a plein d'aspect étranges, comme la feature
Built-in kexec support
qui n'a rien à faire dans un comparatif, si?
En plus en le lisant, je trouve qu'il est vraiment léger sur certaines argumentations, par exemple dans son pissage sur les fichiers de configuration qui ne sont pas tous aux mêmes endroits. Systemd ne résout rien puisque des fois au lieu de lire les fichiers, on les écrit, et systemd n'apporte rien! Si on veut s'y retrouver, au lieu de faire des _
#ifdeforgies_ comme il le suggère (d'ailleurs en lisant ça on prend peur), il suffit de (alternative):1. demander aux gens d'ad{a,o}pter les standards;
2. définir une correspondance entre noms symboliques de fichiers et noms réels qui dépendent des distributions;
3. créer un standard genre fhs-1.0 qui impose d'avoire des links aux fichiers de configuration dans un dossier bien défini (comme
/etc/fhs/1.0/)D'ailleurs, si ça l'amuse un admin peut monter la solution 3 en très peu de temps, en toute indépendance, et ne plus se perdre dans les arborescences ...
# Lennart est un troll
Posté par Jacquot Raphael . Évalué à 8.
Lennart est bien gentil, mais c'est le spécialiste du bloatware...
rappelons qu'il est coupable de..
* avahi
* pulseaudio
et maintenant
* systemd
bref... a l'écouter, toute machine est avant tout un desktop, les serveurs avec des configs statiques, pour être sur que ça fonctionne, ça n'existe pas
[^] # Re: Lennart est un troll
Posté par JGO . Évalué à 3.
Tu peux pas lui reprocher de développe des techniques pour le desktop. Si tu es du genre à avoir besoin d'une config statique, tu as certainement les compétences pour l'écrire toi-même, voire utiliser d'autres logiciels libres plus à ton gout.
[^] # Re: Lennart est un troll
Posté par bubar🦥 (Mastodon) . Évalué à 1.
A priori, il n'y aura pas besoin de "l'écrire toi-même", la compatibilité sysV étant totale, une distribution serveur prendra certainement soin de conserver bien propre un paquet sysv, ainsi que les scripts d'init. Donc à charge du sysadmin d'install cekivabien (et pas de faire "clique->suivant"), que ça soit avec debian-fai ou cobbler ou un truc maison, ou simplement par choix (dans l'installeur, ou bien alamano pour une préparation préalable). Non ? Pour ceux ne faisant que "clique->suivant" et ayant besoin d'un serveur, ça m'étonnerait que systemd les gêne vraiment...
A priori, donc, la maintenance simultanée d'un sysv historique et de systemd ne pose pas de problème ni ne prendra de temps (au vue des features annoncées de systemd)
[^] # Re: Lennart est un troll
Posté par bubar🦥 (Mastodon) . Évalué à 2.
J'ai peut être rêvé à voix haute un peu trop vite, là :p ça n'a pas l'air si simple que ça de maintenir les deux.
[^] # Re: Lennart est un troll
Posté par monde_de_merde . Évalué à 9.
A l'écouter il ne force surtout personne à utiliser ses trucs.
Il a mis le couteau sous la gorge de Ubuntu pour intégrer Pulseaudio ?
Quand j'installe Archlinux chez moi, j'ai pas un Lennart Pottering qui sonne à la porte pour taper un "pacman -S avahi-daemon" en furtif.
Et quand Fedora décide de passer sous systemd le haut conseil local le fait en toute connaissance de cause.
Alors bon, si certains trouve que X est un bloat, qu'ils reprennent leur SysV init et sa collection de scripts mitonnés aux petit oignons et qu'on nous laisse bloater nos machine tranquillement.
[^] # Re: Lennart est un troll
Posté par claudex . Évalué à 10.
Tu as bien de la chance, ça m'arrive à chaque fois que je laisse mon ordi non verrouillé.
« 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: Lennart est un troll
Posté par barmic . Évalué à 6.
Pareil pour n'importe quel logiciel propriétaire ou protocole propriétaire ou format propriétaire. Personne ne t'oblige à faire quoi que ce soit de ton ordinateur.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Lennart est un troll
Posté par Michaël (site web personnel) . Évalué à 3.
Pourtant il écrit ça:
[^] # Re: Lennart est un troll
Posté par alberthier (site web personnel) . Évalué à 3.
Ben moi j'aime bien les technos développé par ce mec:
A la maison, j'ai un PC de salon avec de bonnes enceintes et un portable, Eh ben grâce à avahi+pulseaudio, je vois les enceintes du PC de salon dans la liste des sorties disponibles sur le portable et je peux écouter la musique du portable sur les enceintes du salon, comme ça en wifi, juste en un clic.
Et ça c'est quand même super user-friendly. Ok, je parle d'une utilisation desktop, mais comme dit: il ne force aucun serveur à utiliser ses technos.
[^] # Re: Lennart est un troll
Posté par bubar🦥 (Mastodon) . Évalué à 8.
Les enceinte de ton salon on un système+du wifi ?? Sacrées enceintes !!!
Moi, avec ALSA et BLUEZ, j'envoie du gros son sur ma chaîne hifi, seule, grâce à un module bluethoot branché sur une entrée jack. Chaîne seule, économie pc juste pour "envoyer du son sur les enceintes du salon". OK je parle d'une utilisation desktop, mais ALSA et BLUEZ ne force personne à utiliser leurs logiciels.
[^] # Re: Lennart est un troll
Posté par shbrol . Évalué à 3.
Oula, ca me semble très intéressant ça.
Pourrais tu donner des détails sur le module bluetooth en question (références, origine) ?
Est-ce que la configuration se fait sans trop s'arracher les cheveux avec la doc ALSA/BLUEZ, ou bien tu as quelques liens utiles ?
[^] # Re: Lennart est un troll
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Ben en fait je ne fais qu'utiliser bluez-alsa ( voir ici ) Et comme pour faire cela, il n'y a besoin que de l'A2DP (un truc simple : pas de contrôle distants, les contrôles sont ceux du client sur le laptop, donc pas besoin de AVRCP, ni de hidp ou autres joyeusetés :p). Lien hommage à slackware :)
Pour le tit module bluetooth, au départ était parti du "le faire moi même" et puis ça reviens drôlement plus cher que les trucs bas de gamme. Donc... fais ton marché :-)
[^] # Re: Lennart est un troll
Posté par Albert_ . Évalué à 4.
Comme shbrol je suis TRES interesse par ta methode. Car je n'en peux plus de PA.
[^] # Re: Lennart est un troll
Posté par PlOp3 . Évalué à 3.
Ben, moi, pulseaudio me permet d'écouter Deezer sur ma chaine qui est relié au NAS (Synology). Le syno n'ayant pas de client Deezer, il récupère le flux rtp généré par une carte virtuelle de PA.
Une fois qu'on a pigé le truc, je trouve que PA est carrément génial.
[^] # Re: Lennart est un troll
Posté par Albert_ . Évalué à 2.
Sauf que exemple que j'ai tous les jours:
J'ai une webcam avec un micro integre. Je choisi avec les controls gnome que le micro qui doit etre utilise soit celui la, je test (je vois bien que le micro fonctionne par le fait que en desous du control de volume les petits piquots se colorisent), et que se passe t'il? Naturellement mes correspondants ne m'entendent pas.
LA solution: killall -9 pulseaudio
Je pense que cela ne merite pas plus de commentaire! Donc PA est un probleme (pour moi) et non pas la solution!
[^] # Re: Lennart est un troll
Posté par claudex . Évalué à 5.
Tu utilise quoi comme système pour communiquer avec tes correspondants, c'est peut-être celui qui ne regarde pas quel micro est choisi.
« 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: Lennart est un troll
Posté par Albert_ . Évalué à -1.
De quoi?
Tu veux dire que le fait de tuer PA sur mon ordi fait un changement sur l'ordi d'en face? Si c'est le cas cela fait peur.
Mode soyons serieux:
Le probleme existe avec TOUTES les applications sons. Le probleme existe aussi avec gnome-record ou cheese, la SEULE facon de faire marcher ce putain de micro (je m'en moque qu'il existe une prise micro sur la carte son vu qu'elle est pas branchee) c'est de tuer PA.
Probleme rencontre sur Opensuse et ubuntu et comme deja dit lors d'un troll. Un systeme tel que PA qui est, semble t'il pas simple du tout a integrer dans le systeme s'eloigne passablement de la philosophie KISS de UNIX et que j'apprecie. Si je veux avoir des merdes de ce style j'utilise windows. Heureusement il existe, encore, des solutions de rechange pour Linux!
[^] # Re: Lennart est un troll
Posté par Laurent A. . Évalué à 4.
Essayé à l'instant sur un Dell XPS 15 (L502x) avec une Fedora 15 64 bits dessus : pas de problème dans gnome-recorder en revanche Cheese produit une vidéo figée (clairement un bug) tout en enregistrant correctement le son.
Un problème spécifique à ta machine ?
Quant au concept KISS, on dirait qu'il est souvent synonyme ici d'une vision idyllique du monde où tout est simple... bisounours land pour le logiciel, surtout celui du son qui comme chacun le sait ne recouvre pas l'utilisation de cartes sons aux possibilités techniques ultra-différentes, et ne demande jamais d'optimisations tordues pour tout effectuer en «temps-réel».
[^] # Re: Lennart est un troll
Posté par bubar🦥 (Mastodon) . Évalué à 10.
C'est justement the question : pourquoi avoir besoin de pulseaudio pour juste "du son qui comme chacun le sait ne recouvre pas l'utilisation de cartes sons aux possibilités techniques ultra-différentes, et ne demande jamais d'optimisations tordues pour tout effectuer en «temps-réel»." ????
pulseaudio, le truc :
Non, y a un moment, faut savoir dire stop. Ok ça a été testé, ok ça a des avantages. Mais objectivement ça ne bouge que par hacks des distros, presque. Chacun dans son coin, et pour un truc réellement bancal. Alsa ça fonctionne, et voilà. Pour un usage poussé (genre bluetooth) tu fais la config une fois, ensuite c'est une histoire réglé. Et pour les usages encore plus avancés y a jack. Mais ALSA seul c'est parfait, très bien et suffisant du moins.
[^] # Re: Lennart est un troll
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Ha vi.. le tit dernier :
Bref que cela soit pour la définition que tu emploi, soit "du son, simplement" il ne convient (tjs) pas. Et pour un usage par les pros, ben c'est marrant le site de référnce audio (linux-audio.org, en fr) ben les vrais pros du son ils n'en causent pas trop... ceci incluant autant les utlisateurs avancés que les développeurs, ces derniers ne sont pas précipité pour remplacer jack ou tout faire par défaut sur pa. C'est toujours ALSA (et jack) les références. Là encore, pa à tout fait.
Vraiment y a un moment où faut se dire "pa : dehors, fini"
[^] # Re: Lennart est un troll
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Est il besoin de causer de la conso cpu de pa ? qui, si, là, objectivement, la situation s'est améliorée, reste quant même toujours bien plus élevée pour mixer un son flash + un son musique + un son sip, que ALSA seul. Sans commune mesure, pour rendre le même service. Il est le gain ? ça suce mieux la batterie du portable ?
[^] # Re: Lennart est un troll
Posté par Laurent A. . Évalué à 1.
Normalement, PA est justement fait pour consommer moins, sauf avec des cartes qui ne supportent pas certaines de ses fonctionnalités (enfin, il s'agit d'un problème ALSA -- même si «il fonctionne»).
[^] # Re: Lennart est un troll
Posté par Laurent A. . Évalué à 0.
Je n'ai rien compris à ton paragraphe sur le RT...
Pour l'usage pro, PA n'a jamais été présenté comme la solution mais comme une possibilité en parallèle à Jack. Clairement PA et Jack évoluent avec deux objectifs précédents alors pourquoi les comparer ?
Donc, PA pas dehors sauf pour des besoins spécifiques (et encore, il peut être mis en pause il me semble).
[^] # Re: Lennart est un troll
Posté par claudex . Évalué à 2.
PA peut tout a fait utilisé Jack au lieu de ALSA.
« 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: Lennart est un troll
Posté par Laurent A. . Évalué à -1.
Un démon système tu veux dire parce qu'actuellement c'est un démon utilisateur. Euh... Qu'est-ce que ça peut te foutre ?
Pas de problème avec le Flash à première vue. Ou alors il faudra que tu m'expliques comment tu le diagnostiques parmi tous les plantages de Flash.
Les boutons, c'est ALSA... Mais tu seras heureux d'apprendre qu'alsamixer sur Fedora 15 ne m'affiche pas 50 boutons.
Pas stop donc. Et je ne sais pas si «ALSA fonctionne» est aussi vrai que tu le dis.
[^] # Re: Lennart est un troll
Posté par Albert_ . Évalué à 3.
Non pas un probleme machine car present sur un DELL et sur un thinkpad et deux distributions differentes. Je vais me repeter mais le SEUL point commun ou plutot la SEULE facon de tout faire fonctionner comme il faut etant de tuer PulseAudio, je suis persuade que le probleme est dans ce logiciel. Si c'etait un probleme hardware, tuer un process n'aurait aucun effet.
[^] # Re: Lennart est un troll
Posté par Juke (site web personnel) . Évalué à 3.
Le mercredi 04 mai 2011 à 07:42 +0200, Albert_ a écrit :
> la SEULE facon de tout faire fonctionner comme il faut etant de tuer
> PulseAudio
alors pourquoi l'installer ?
[^] # Re: Lennart est un troll
Posté par Albert_ . Évalué à 2.
Parceque je n'ai plus le temps de m'amuser avec LFS et autre Gentoo. Donc par defaut il est installe!
[^] # Re: Lennart est un troll
Posté par Juke (site web personnel) . Évalué à 2.
Le mercredi 04 mai 2011 à 20:09 +0200, Albert_ a écrit :
> Donc
> par defaut il est installe!
killall -9 pulseaudio
plusieurs fois par jour
VS
aptitude purge pulseaudio 1
une bonne fois pour toute...
[^] # Re: Lennart est un troll
Posté par Albert_ . Évalué à 2.
Parceque je ne suis pas le seul sur ce pc et que l'autre personne a un casque bluetooth. D'ou ma question pour pouvoir utiliser cela sans PA. (Bon maintenant il va falloir le convaincre...)
[^] # Re: Lennart est un troll
Posté par Xavier Teyssier (site web personnel) . Évalué à 3.
Et dire que j'hésitais.
Des plombes que pulseaudio pourrissait ma machine.
J'ai lu ton commentaire, et hier soir, j'ai viré pulseaudio.
Miracle ! Plus besoin de "killall -9 pulseaudio" dès que je change d'appli voulant produire du son. Encore mieux, deux applis différentes peuvent utiliser la carte son en même temps ! Grâce à toi, ma machine revit !
N.B. : je suis en Debian Sid, mise à jour régulièrement depuis des années. Toutes les conditions pour qu'il y ait un max de bogues. Je ne suis donc pas en train de dire que pulseaudio est pourri, juste qu'il pose problème sur une configuration comme la mienne...
# linuxo-centré.
Posté par JGO . Évalué à 7.
Soit on essaie de faire plaisir à tout le monde, soit on essaie de faire un truc utilement optimisé. Le libre a beaucoup gagné grâce à l'innovation rapide de Linux. De l'autre côté, le libre gagne aussi avec le polissage méthodique des projets BSD. Essayer de supporter les deux approches avec le même userland (comme le fait debian) est voué à créer des problèmes☆.
☆ Lire aussi ce post de blog Debian, Gentoo, FreeBSD, GNU/kFreeBSD
[^] # Re: linuxo-centré.
Posté par Zenitram (site web personnel) . Évalué à 9.
C'est vrai ça... On se demande pourquoi il y a des emmerdeurs à vouloir une LSB, une FHS, du freedstop, sans ces emmerdeurs à vouloir des normes communes, ça serait tellement plus rapide d'innover...
Au fait, cet argument tient très bien aussi pour Microsoft et Apple qui n'ouvrent pas les specs de plein de choses (c'est plus rapide d'innover quand on n'a pas à discuter de tout ça, tant pis pour les autres si c'est pas compatible, ça nous ralentirai de faire attention aux autres).
[^] # Re: linuxo-centré.
Posté par JGO . Évalué à 8.
1) justement, l'auteur de systemd a impliqué les projets et distros dans son idée, de façon à ce que les étapes nécessaires soient faites de façon cohérente.
2) mauvaise foi. Les specs de systemd sont ouvertes, le code aussi, les discussions avec toutes les distributions ont lieu. C'est le processus d'intégration de code dans le noyau ou des distros linux et celui des BSD qui est irréconciliable.
Le noyau linux offre une API qui des fonctionnalités différentes par rapport aux noyaux BSD [notamment parce que les gens de chez BSD n'acceptent pas aussi rapidement des changements radicaux comme il y en a eu dans la branche 2.6]. On doit s'interdire d'écrire des programmes qui tirent parti de l'API du noyau linux, parce que les gens de chez BSD n'en ont pas voulu ? De toute façon, chez BSD, ils ont leur système d'init et en sont contents. On doit donc s'interdire d'écrire des programmes pour l'API linux parce que Debian a décidé que deux noyaux totalement différents devaient booter avec le même système d'init ?
[^] # Re: linuxo-centré.
Posté par patrick_g (site web personnel) . Évalué à 5.
Pour rajouter de l'huile sur le feu j'aimerais bien savoir combien de gens utilisent vraiment Debian GNU/kFreeBSD.
Je n'ai aucune donnée mais je suis prêt à parier ma chemise que ce nombre est infinitésimal. Refuser une belle avancée technologique comme systemd juste parce que ce n'est pas compatible avec Debian GNU/kFreeBSD ce serait, amha, une monumentale connerie.
[^] # Re: linuxo-centré.
Posté par Bapt (site web personnel) . Évalué à 8.
Un truc qui pète FHS, qui éloigne encore un peu plus linux de la beauté des unix. qui n'est pas portable, qui va la migraine aux administrateurs systèmes, qui réinvente la roue dans tous les sens...
Hum on ne doit pas avoir la même définition de "belle avancée technologique".
[^] # Re: linuxo-centré.
Posté par inico (site web personnel) . Évalué à 9.
«beauté des unix» ?
Entre SMF chez Solaris et les scripts d'init hardcoded pour une machine specifique, l'init chez les unix est très loin d'être beau ou portable ...
[^] # Re: linuxo-centré.
Posté par Guillaume Knispel . Évalué à 1.
Le logiciel, ça se modifie, surtout les scripts. C'est un peu l'avantage du logiciel par rapport au matériel d'ailleurs (enfin bon le matériel aussi, ça se modifie, mais c'est quand même moins facile et moins pratique). Ne pas vouloir modifier quoique ce soit dans sa configuration est illusoire, car au final la configuration sera tout de même modifiée, mais à un endroit moins accessible, découvrable, pratique, clair. Cf Windows. Les systèmes libres qui n'incitent pas à modifier son système en cas de besoin (ou pire, qui freine de telles tentatives) sont de mon point de vue inférieurs à ceux qui le font. Quand au mythe de la personne lambda pouvant administrer toute seule son ordinateur personnel sans apprendre l'informatique ni même lire ce qu'il y a écrit sur son écran, ahahah.
[^] # Re: linuxo-centré.
Posté par cosmocat . Évalué à 2.
Un truc [...] qui va donner la migraine aux administrateurs systèmes, qui réinvente la roue dans tous les sens
J'ai surement pas les connaissances pour juger mais d'après ce qu'avance Lennart ( http://0pointer.de/blog/projects/ ), c'est mieux pour les admins systèmes car il a travaillé avec les différentes distribs et ils ont "standardisé" (ou normaliser) pas mal de trucs (qui vont donc être identique maintenant sur toutes les distribs utilisant systemd). De plus, systemd n'est pas portable justement parce qu'ils ont veillé à ne pas réinventer la roue (utilisation de dbus à la place d'un truc propre à systemd)
[^] # Re: linuxo-centré.
Posté par gaston . Évalué à 5.
Donc, tu veux dire que dbus n'est pas portable ? joli.
S'il n'est pas portable, c'est parce qu'il utilise plein d'APIs linuxo-centriques, c'est tout.
[^] # Re: linuxo-centré.
Posté par cosmocat . Évalué à -1.
:) Pour cette remarque, je dirais que soit tu es de mauvaise foi, soit tu as fait un beau sophisme, soit tu as perverti délibérément l'argumentation pour t'en servir pour exprimer ton idée...
L'idée était de savoir si systemd réinventait la roue ou pas (pas de savoir s'il était portable). Et à çà, j'ai répondu.
Maintenant, je vais te répondre à toi ;)
Oui, systemd (on parlait bien de systemd, hein!?! pas de dbus) n'est pas portable A L'HEURE ACTUELLE car dbus (entre autre) n'est pas ENCORE porté. Et non pas importable... mais je crois pas que les BSD soit interressé par porter cette techno donc ça risque d'être difficile pour un portage de systemd sous BSD. Les autres dépendances problématique sont policykit, cgroups et surement d'autres que j'ignore.
[^] # Re: linuxo-centré.
Posté par gaston . Évalué à 4.
Tu feras gaffe, tu t'enfonce dans ton erreur la..
[^] # Re: linuxo-centré.
Posté par Zenitram (site web personnel) . Évalué à 9.
Pour rajouter de l'huile sur le feu j'aimerais bien savoir combien de gens utilisent vraiment Linux.
Je n'ai aucune donnée mais je suis prêt à parier ma chemise que ce nombre est infinitésimal (note: la, je triche un peu, c'était infinitésimal avant 2000, mais c'est pour montrer que le noyau Linux a bien commencé un jour avec Debian). Refuser une belle avancée technologique comme (mettre ici n'importe quelle techno Apple ou Microsoft) juste parce que ce n'est pas compatible avec Linux ce serait, amha, une monumentale connerie.
Ah oui, ça marche aussi ;-). C'est rigolo quand même : quand les windowsiens disent "pfff... Vous êtes pas nombreux à utiliser votre truc Linux la, on va pas prendre en compte votre cas", ça hurle qu'il faut prendre en compte les OS minoritaire, quand les linuxiens disent "pfff... Vous êtes pas nombreux à utiliser votre truc Debian GNU/kFreeBSD la, on va pas prendre en compte votre cas", ça n'a pas l'air de gêner (moi, ça me gène). Finalement, il y a assez peu de différence entre linuxien et un windowsien vis à vis des minorités... Et après ça va aller faire la morale aux windowsiens! Poutre, paille...
[^] # Re: linuxo-centré.
Posté par JGO . Évalué à 2.
La critique ne porte pas sur les mêmes choses (ou alors cite ton exemple).
On critique un auteur windowsien qui n'a juste pas envie de cross-compiler pour linux, alors que son programme n'a rien de spécifique à windows et pourrait facilement être rendu portable. On ne critique pas un auteur qui a décidé (p.ex.) que DirectX11 était sans nul doute possible plus simple pour son projet que OpenGL. C'est à linux de supporter DirectX s'il le veut (et ça vient petit à petit).
[^] # Re: linuxo-centré.
Posté par Antoine . Évalué à 7.
Tu crois que ça se fait en deux secondes de "cross-compiler sous Linux" (en utilisant, j'imagine, la bouse nommée autotools) quand ton soft est développé sous MSVC ?
[^] # Re: linuxo-centré.
Posté par jean . Évalué à 2.
cross-compilerça veut dire compiler pour un système différent de celui faisant tourner le compilateur, je pense que tu voulais dire un programme portable.[^] # Re: linuxo-centré.
Posté par JGO . Évalué à 2.
Je voulais vraiment dire cross-compiler. Je suppose que l'auteur d'un programme, par exemple développé sous linux, peut 1) faire l'effort de rendre son programme portable et 2) suivre un tuto pour produire un binaire pour windows à partir de sa machine linux☆, sans rien toucher à sa chaine de compilation, sans redémarrer. Pour suivre des mailing-lists où ce genre de choses se produit, il peut y avoir des problèmes (le glisser-déposer ou les binding python qui arrêtent de marcher d'une version sur l'autre), mais c'est mieux que rien et on peut produire automatiquement un binaire pour un autre système sans grand effort, sans avoir à redémarrer sur ce système.
☆ http://www.dumbbell.fr/howto/win32-cross-compilation.fr.html
Pour répondre à la question de la personne juste au-dessus, je ne sais pas comment passer d'un projet MSVC aux autotools, mais le contraire n'est pas trop difficile (ok pas avec les autotools mais avec un truc plus moderne genre scons ou cmake). Je n'ai pas cherché la direction msvc → autre chose, vu qu'elle ne m'intéresse pas le moins du monde, mais j'imagine qu'il y a des outils pour ça.
[^] # Re: linuxo-centré.
Posté par gnumdk (site web personnel) . Évalué à 1.
Euh, patrick_g, c'est la voix des Linuxiens ?
[^] # Re: linuxo-centré.
Posté par brendel . Évalué à 1.
Je suis d'accord avec ça, ne pas progresser pour rester compatible c'est une connerie.
Non, ça hurle (et encore la on met tout le monde dans le même panier) qu'il faut que ce soit libre (dans le cas d'un logiciel) ou (plus important selon moi) que les les specs soient publique (dans le cas d'un protocole ou du matos) de façon à ce qu'il soit possible de l'implémenter sur des OS minoritaires (soit même ou en payant quelqu'un si on en a besoin).
[^] # Re: linuxo-centré.
Posté par zebra3 . Évalué à 5.
Si on compte les smartphones sous Android, PalmOS, les routeurs, les *box, les TV Samsung ou Sony, les GPS TomTom, bref, tout plein d'équipements réseau, multimédia ou mobile, il y a peut-être plus de gens qui utilisent Linux sans le savoir que de gens sous Windows + Mac réunis.
Et pour ces gens, un boot plus rapide sera forcément un plus.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: linuxo-centré.
Posté par jean . Évalué à 2.
C'est plutôt Windows qui a besoin d'un boot rapide, avec les autres OS on ne passe pas son temps à redémarrer la machine. Un boot rapide, c'est la dernière de mes préoccupations, qu'il dure 2 minutes ou 8 secondes, cela ne représente pas grand chose sur une session de travail de plusieurs heures voire plusieurs jours ou semaines.
[^] # Re: linuxo-centré.
Posté par zebra3 . Évalué à 5.
Ça dépend.
Quand j'allume ma TV Samsung, je dois attendre quinze bonnes secondes avant qu'elle soit utilisable.
Auparavant, ma vieille TV cathodique s'allumait quasi instantanément.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: linuxo-centré.
Posté par Alex . Évalué à 2.
Et pour ces gens, un boot plus rapide sera forcément un plus.
C'est évident, ceci dit je ne suis pas dur que systemd s'adresse aux systèmes embarqués, où dbus est plutôt rare (même si utilisé par android et meego).
De plus init est souvent réécrit pour chaque système.
[^] # Re: linuxo-centré.
Posté par zebra3 . Évalué à 2.
Justement, peut-être que la réécriture ne sera plus nécessaire.
Après tout, le bon est déjà conséquent pour un PC, pourquoi ne le serait-il pas pour un téléphone ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: linuxo-centré.
Posté par Etienne Bagnoud (site web personnel) . Évalué à 5.
En même temps Debian GNU/kFreeBSD est sorti en février 2011 ... On est en mai 2011, donc il faut pas non plus s'attendre à une adoption massive en 3 mois d'un projet aussi "particulier". Il faut aussi laisser le temps au temps, mais si je regarde un peu autour de moi, je vois Mac OS X qui s'appuie sur un noyau issu en partie du monde BSD et le succès de ce système est là.
Il est donc possible que Debian GNU/kFreeBSD devienne la distribution qui atteint 5% de part de marché des OS de bureau (OS X est autour des 8%) ou alors ça peut-être le fiasco complet, mais dans tous les cas c'est une expérience formidable et ce que le projet Debian en retira ne sera que bénéfique pour toutes les distributions; et je crois que Debian a fait ses preuves en tant que distribution de référence (et pouvant être à l'origine d'un succès sur le bureau -> Ubuntu).
En tout cas je suis de ceux qui vont essayer de mettre un serveur sur Debian GNU/kFreeBSD, étant utilisateur Debian GNU/Linux et FreeBSD.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: linuxo-centré.
Posté par Maclag . Évalué à 4.
On bascule dans le hors-sujet, mais tu serais peut-être une des personnes les plus qualifiées pour répondre à LA question: qu'attends-tu d'une Debian GNU/kFreeBSD par rapport à une Debian GNU/Linux et un pur FreeBSD?
Je me suis toujours dit que l'intérêt majeur de ce projet c'était surtout dans la beauté du geste, qui permet de mettre en valeur le titre de système d'exploitation universel et le très grand souci de portabilité chez Debian (oui, c'est un peu grandiloquent, mais je ne vous cacherai pas que j'aime vraiment beaucoup Debian!).
Donc concrètement, si on isole le noyau, que trouve-t-on chez FreeBSD qui manque chez Linux et vice-versa?
[^] # Re: linuxo-centré.
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
Un exemple, tu as une application web qui sert des données sensibles et tu souhaites te protéger au maximum. Tu vas monter un serveur /nginx/Linux et un serveur */Apache/FreeBSD, si un des couples serveur Web/noyau est victime d'une faille de sécurité, tu peux facilement le déconnecter du réseau, attendre la mise à jour de sécurité, mettre à jour et reconnecter sans interrompre ton service Web.
Bien entendu la partie application () sera victime des mêmes failles (à moins que tu aies un psychopathe qui décide, par exemple, de faire une version Perl et un version PHP de l'application ... ça reste possible), mais ta partie serveur Web et noyau est suffisamment hétérogène pour avoir une sécurité "supplémentaire".
Ensuite il y'a débat pour savoir lequel de FreeBSD ou de Linux est plus performant pour le réseau/accès disque/nombre de processus/..., on pourrait imaginer avoir deux serveurs concurrents identiques derrière un proxy. Chaque requête est transmise aux deux serveurs et la requête la plus rapide est servie au client, la plus lente est supprimée. À la fin d'un période de test, on peut aisément déterminer lequel des deux systèmes est le plus adéquat pour le travail en question.
On peut aussi imaginer le cas où tu te retrouves avec du matériel supporté que par l'un (genre tu as plusieurs machines différentes et un de ces machines à du matériel uniquement supporté (ou mieux supporté) par FreeBSD).
Mais sinon si on isole les noyaux, il ne reste plus de différence entre les deux, c'est bien le but du projet.
Comme pour l'administration ça reste une Debian, tu peux beaucoup plus facilement mettre en place ce genre de solutions. Ça reste encore une hypothèse, mais c'est le genre de choses que j'ai imaginé quand j'ai appris le naissance du projet kFreeBSD, mais je n'ai pas encore eu le temps de mettre en pratique mes délires :)
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: linuxo-centré.
Posté par jean . Évalué à 2.
C'est un point intéresssant.
[^] # Re: linuxo-centré.
Posté par Michaël (site web personnel) . Évalué à 2.
Oui on avait déjà parlé de l'hétérogénéité comme facteur améliorant la résilience d'un groupe il y a quelques temps: c'est exactement la même idée.
[^] # Re: linuxo-centré.
Posté par Zenitram (site web personnel) . Évalué à 2.
Ou pas.
Dans son exemple, si le but est de filer des données sensibles suivant des autorisations, le mal sera fait avant qu'il éteigne le serveur troué. Et en face, l'attaquant a deux fois plus de possibilités pour trouver une faille (deux OS et deux serveurs avec des failles possibles).
C'est une fausse meilleur sécurité qu'il présente, avec comme conséquence une plus mauvaise sécurité.
La où il est intéressant d'avoir de l'hétérogène, c'est pour des données différentes : si l'un est attaqué, l'autre est encore pas attaquable, moitié de "perte". Si il faut les deux serveurs pour accéder à la donnée sensible cryptée, c'est toujours sécurisé dans ce cas.
En gros faire la différence entre ET logique et un OU logique.
[^] # Re: linuxo-centré.
Posté par Michaël (site web personnel) . Évalué à 2.
Ce n'est pas juste une plus mauvaise sécurité: d'un côté il y a un nombre plus grand de failles potentiellement exploitables, de l'autre une meilleure disponibilité du service lorsque une faille est repérée. Il y a donc un vrai choix à faire.
[^] # Re: linuxo-centré.
Posté par Zenitram (site web personnel) . Évalué à 2.
Je cite:
Avec deux OS différent qui peuvent fournir le même contenu et son indépendants ("tu peux facilement le déconnecter du réseau,") : sécurité, Fail.
Ou alors j'attend l'argumentation, car je n'ai pas compris comment ça améliore la sécurité.
Par contre, oui, c'est sécurité contre disponibilité, juste que la on parle de sécurité.
[^] # Re: linuxo-centré.
Posté par Michaël (site web personnel) . Évalué à 2.
Au temps pour moi, je n'avais pas lu tout le fil précédent, tu as raison.
[^] # Re: linuxo-centré.
Posté par Etienne Bagnoud (site web personnel) . Évalué à 1.
... en même temps je pensais pas qu'il était nécessaire de préciser qu'un service réseau vise 100% de disponibilité. Dans ton raisonnement, autant débrancher la machine du réseau (électrique compris).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: linuxo-centré.
Posté par barmic . Évalué à 4.
Il n'est pas interdit d'organiser son code pour simplifier un éventuel portage.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: linuxo-centré.
Posté par claudex . Évalué à 2.
Ce serait même assez intéressant en fait.
« 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: linuxo-centré.
Posté par Grunt . Évalué à 1.
Avec cette très légère différence que les éditeurs propriétaires ont la fâcheuse tendance à ne proposer ni code source, ni vague brouillon rassemblant les spécifications.
Autrement dit, il n'existe absolument aucun moyen de savoir comment un format ou un protocole est foutu, dans ces conditions.
Il ne s'agit pas de discuter, juste de permettre aux autres de se démerder pour être compatibles. Ce que le libre fait même dans le pire des cas, vu qu'il y a le code source (ce n'est pas idéal, certes, mais c'est beaucoup mieux que rien).
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: linuxo-centré.
Posté par Tsomi . Évalué à 10.
Mouais, ça change pas grand-chose d'avoir le code source, ici...
Ce n'est pas en ayant le code source des fonctionnalités du noyau Linux abondamment utilisées par systemd que l'on va facilement pouvoir les implémenter dans les noyaux BSD, par exemple (rien que pour des raisons de licence). Alors, on dit plus haut que Lennart ne met pas de couteau sous la gorge, OK, mais il y a aussi la question de pouvoir faire autrement, à long terme.
Le problème, selon moi, c'est qu'un composant utilisé par les distributions les plus populaires (Fedora, Ubuntu...) devient rapidement un standard de fait. Par exemple, Slackware fait quand même quelques choix très marqués (pas de Gnome, pas de PAM, pas de PulseAudio, un init BSD-like), et, de l'aveu même de Pat, les choses deviennent de plus en plus compliquées à maintenir comme ça.
Par exemple, Policykit est dépendant de PAM, à la base. Il a fallu qu'un contributeur développe une solution (basée sur shadow) pour que ça puisse marcher avec Slackware. Solution qui a été en partie reprise par OpenBSD, qui ne veut pas non plus de PAM. Un autre exemple : Chrome, qui veut aussi des bouts de PAM et de Gnome. Encore un autre exemple : Xfce 4.8, pour lequel certaines fonctionnalités ont en partie disparu pour les BSD.
Un autre exemple encore : bash. C'est est le shell par défaut sur la majorité des distributions Linux, donc beaucoup de gens, inconsciemment, partent du principe que tous les shells se comportent comme bash. Cela est surtout intensifié par le fait que, même lancé en tant que /bin/sh, bash accepte encore des fonctionnalités qui lui sont propres. Du coup, le nombre de scripts (avec le shebang #!/bin/sh) remplis de bashismes est monstrueux.
Moi, je suis bien content de l'init BSD-like de ma Slackware. Je le trouve tout simple (y a pas whatmille niveaux de liens symboliques, c'est du bourne shell, les scripts ne font pas des kilomètres, bref : c'est humainement utilisable). En plus, pour peu qu'on le fasse utiliser dash et awk plutôt que des cut | rev | tr | rev | sed, ça me fait un temps de démarrage d'environ 15 secondes, ce que je trouve tout à fait acceptable (malheureusement, Pat est plutôt frileux à accepter ces changements).
Mais je n'aimerais pas que l'on parte dans une homogénéité totale des différents Linux et *BSD. La diversité, c'est bien, et pour moi, la liberté de choisir devrait être une des libertés fondamentales.
A force de vouloir faire de Linux un Windows gratuit, j'ai bien peur de finir par avoir un truc aussi frustrant à utiliser. De toutes façons, je pense que vouloir rendre Linux prêt pour le desktop est voué à l'échec de par le fait du modèle du bazar (qui fait qu'il y aura toujours quelqu'un pour être insatisfait et lancer son propre truc) : échec soit par le fait que ça n'arrivera jamais (parce que c'est difficile de concilier tout ce bazar, justement, avec tout le monde qui fait son truc à sa façon dans son coin), ou alors parce que le résultat aura largement perdu en qualité. Je pense que si on veut avoir un système un minimum "prêt pour le desktop", il faut quand même avoir un ensemble assez homogène, et donc il y a un moment où il faut imposer ses choix à l'utilisateur qui perd alors une bonne partie de sa liberté de faire ce qu'il veut sur sa machine, ce que je ne souhaite pas, personnellement (par contre je trouve que ça décrit bien Mac OS — mais ça ne pose pas de problème aux fanboys puisqu'ils trouveront toujours parfait ce qu'Apple les autorise à faire... pas bête le Steve).
Ce qui ne veut pas dire qu'il n'y a pas d'efforts d'uniformisation à faire (c'est vrai qu'il ne s'est pas passé grand-chose ces 10 dernières années à ce niveau-là, comparé aux changements qui sont survenus), mais il ne faut pas partir dans l'excès "UNIX = GNU/Linux Fedora/Ubuntu".
Je ne critique pas tout ce qu'à pu faire Lennart ; ça sert à rien et puis il y a certaines de ses idées qui me plaisent (ce qu'il propose sur l'uniformisation des fichiers de configuration de base, par exemple — surtout qu'il propose des noms de fichiers très UNIX : courts, logiques et simples), mais bon, généralement je me porte mieux en n'installant pas ses projets sur ma machine, et j'aimerais pouvoir continuer à le faire pendant encore un bon moment.
a systems programmer has seen the terrors of the world and understood the intrinsic horror of existence
[^] # Re: linuxo-centré.
Posté par feth . Évalué à 1.
Ça serait pas plus simple une bonne fois que quelqu'un qui veut avancer forke un BSD et place son fork sous licence GPL, de façon à pouvoir bénéficier de ce qu'il considère comme le meilleur des deux mondes ?
[^] # Re: linuxo-centré.
Posté par Larry Cow . Évalué à 4.
Le problème, c'est qu'il faut aussi forker Théo, pour que ça soit efficace. Et quelque-chose me dit qu'il ne se laissera pas faire si facilement ;)
[^] # Re: linuxo-centré.
Posté par Maclag . Évalué à 2.
Mais si, il saura entendre raison.
Il suffit d'un bon débat contradictoire!
[^] # Re: linuxo-centré.
Posté par Larry Cow . Évalué à 1.
Le problème, c'est qu'il faut aussi forker Théo, pour que ça soit efficace. Et quelque-chose me dit qu'il ne se laissera pas faire si facilement ;)
[^] # Re: linuxo-centré.
Posté par claudex . Évalué à 9.
Attention, tu as forké ton commentaire.
« 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: linuxo-centré.
Posté par Thomas Douillard . Évalué à 2.
Il y a recrudescence de double posts en ce moment. Si je savais quoi mettre en dehors de ça je ferai une entrée dans le suivi /o\
[^] # Re: linuxo-centré.
Posté par claudex . Évalué à 3.
Moi aussi
« 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
[^] # double post
Posté par Zenitram (site web personnel) . Évalué à 6.
Clic sur "envoyer". vu que le serveur met un peu de temps (Ruby? ;-) ), j'ai le temps de malencontreusement ré-appuyer sur "envoyer" (je suis pas doué, double-clic sans faire exprès), et vu qu'il n'y a pas de code Javascript qui désactive le bouton avant d'envoyer le post, et vu qu'il n'y a pas de test de post en double pour ne pas le prendre en compte, ben post en double au final.
[^] # Re: double post
Posté par jean . Évalué à 1.
On peut aussi tripleposter :)
[^] # Re: linuxo-centré.
Posté par jean . Évalué à 1.
Moi aussi.
[^] # Re: linuxo-centré.
Posté par jean . Évalué à 1.
Moi aussi.
[^] # Re: linuxo-centré.
Posté par jean . Évalué à 1.
Moi aussi.
[^] # Re: linuxo-centré.
Posté par Maclag . Évalué à 3.
Je suis moi-même convaincu que c'est sans espoir.
Je suggère un débat contradictoire, juste pour la forme.
[^] # Re: linuxo-centré.
Posté par JGO . Évalué à 2.
Tu peux utiliser/contribuer à debian/kfreebsd, gentoo/freebsd ou freebsd-arch, en choisissant celle qui a le mélange bsd/gpl qui te convient le mieux.
[^] # Re: linuxo-centré.
Posté par GeneralZod . Évalué à 9.
Justement, pour la partie desktop, le coeur du problème est que les gens de BSD ne s'investissent pas assez dans les efforts de standardisations formelles (freedesktop) ou informelles (fournir du code, tester les projets communs).
Quant à la partie système, c'est bien de respecter les normes mais les seules évolutions qu'a connu POSIX cette décennie passée ont été: fusion avec SUS, toilettage de l'API, prise en compte d'IPv6 etc ... On peut ânonner POSIX jusqu'à la fin des temps ou bien se sortir les doigts du cul et utiliser des alternatives plus avancées.
Là ou Lennart marque un point, c'est que les normes se basent sur les innovations proposées par les différents participants, or la plupart des innovations se font dans Linux (ou GNU dans un contexte plus large) qui est devenu le standard de FAIT. Le problème c'est que POSIX n'évolue plus, donc soit on le sort de l'ornière, soit on crée un nouveau groupe de standardisation sur le modèle fd.o (j'ose pas imaginer le niveau trollesque d'une liste réunissant quotidiennement de Raadt, Trollvalds, RMS etc ...) pour collaborer plus étroitement.
Sinon pour revenir au sujet principal:
* systemd n'est pas un bloatware: la portabilité à tout prix a un coût, le choix du linux-o-centrisme a été fait pour éviter justement que systemd devienne un bloatware.
* le choix de D-Bus: D-Bus est un protocole qui s'appuie sur un IPC plus que standard: les sockets BSD. En plus, systemd s'appuie sur une toute petite lib, rien n'interdit de la réimplémenter, si elle est trop bloated.
* Lennart n'a rien contre la portabilité et les standards, au cours du développement de systemd, il a rapporté plus de bogues au FHS à lui seul que la majorité des distros ces dernières années. Le but n'est pas de péter FHS mais de corriger ces lacunes et de standardiser ça au lieu que chaque distro fasse son hack dans son coin comme c'est le cas actuellement. Au final, systemd contribuera a simplifier le boulot de ces feignasses de sysadmins sous GNU/Linux (quant aux BSD, ils utilisaient déjà leurs propres init donc ça change pas grand chose de ce côté là)
[^] # Re: linuxo-centré.
Posté par Antoine . Évalué à 3.
Je ne vois pas ce que RMS viendrait faire là-dedans, sauf si on veut aussi standardiser les éditeurs de texte.
[^] # Re: linuxo-centré.
Posté par rewind (Mastodon) . Évalué à 10.
Zenitram, ça me fait peur, je suis encore d'accord avec toi.
Et je trouve que ceux qui mettent dans la balance l'innovation devraient relire un peu l'histoire de UNIX (oui, GNU/Linux est toujours un Unix et essaie au maximum de respecter les standards, c'est marqué dans toutes les manpages) et notamment la partie sur la balkanisation : aucun de ces super UNIX qui innovaient à fond comparé au voisin n'a survécu. Non par manque d'innovation (certains ont eu de très bonnes idées), mais par manque de compatibilité les uns avec les autres.
Alors, oui, c'est chiant de standardiser et les organismes genre opengroup sont un peu long à la détente. Mais si le problème vient des organismes, il ne faut pas jeter le standard, mais bien l'organisme (ou le réformer). Parce que ce n'est pas en marginalisant les BSD qu'on arrivera à imposer Linux, ne nous trompons pas d'ennemis. Les BSD sont des alliés, et standardiser un protocole ou une API permet toujours d'en voir tous les défauts (par la multiplicité des points de vue).
[^] # Re: linuxo-centré.
Posté par claudex . Évalué à 4.
Sauf que les BSD ont déjà un système d'init différent de celui des Linux et que systemd est déjà compatible avec le système d'init actuel des distributions. Pour l'instant, on ne fait rien de différent de l'actuel.
« 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: linuxo-centré.
Posté par gnumdk (site web personnel) . Évalué à 5.
Comme ArchLinux et Slackware ?
[^] # Re: linuxo-centré.
Posté par Laurent A. . Évalué à 2.
Et puis Ubuntu avec Upstart... Sans compter que les scripts de démarrage s'appuient tous sur les spécificités de chaque distribution avec, par exemple, des fichiers de configuration dans /etc/sysconfig chez Redhat mais pas chez Debian.
La vérité, c'est que le démarrage des systèmes Linux n'est pas normalisé et n'a pas même réussi à se standardiser alors pourquoi ne pas tenter autre chose ?
Il y a quand même une fonctionnalité qui a l'air de rester invisible ici alors qu'elle me paraît être la killer-feature de systemd. Systemd peut faire redémarrer des services sans avoir à redémarrer la machine : les sockets stockent les données qui leur arrivent pendant que le service concerné redémarre, puis ce service peut traiter ce qui était en attente dans les sockets qu'il utilise. Ce n'est pas une fonctionnalité utile pour un serveur ou même pour une simple machine ?
[^] # Re: linuxo-centré.
Posté par Albert_ . Évalué à 5.
Comme dit auparavant systemd c'est peut etre bien, en theorie. Le probleme c'est que la personne ayant pondu ca a la sale habitude de laisser en plan un truc a moitie fait. Du coup on se retrouve avec Avahi et PA. Les deux a la base ont de bonnes idees et au final pour l'utilisateur lambda c'est bien souvent inutilisable ou tellement complique que ca ou rien c'est presque pareil (voir pire dans certains cas).
[^] # Re: linuxo-centré.
Posté par jypaigue . Évalué à 2.
Dans ce cas, ce que tu reproches, ce n'est pas le fait que PA ne soit pas fini, mais le fait que ta distribution te l'impose comme choix par défaut.
[^] # Re: linuxo-centré.
Posté par Albert_ . Évalué à 2.
Ma distribution? Comme je ne suis mono-distribution ni ethocentrique je dirais que toutes les grosses distributions t'imposent ce truc et que a cause de cela, les alternatives n'existent pas vraiment.
[^] # Re: linuxo-centré.
Posté par Laurent A. . Évalué à 1.
Pour Avahi, je n'en sais rien (ça a toujours tourné tout seul sur toutes mes machines sans problème). Pour PA, les problèmes ont généralement trait à des interactions avec Jack. De cela, en déduire que tout ce que fait ce gars est mauvais est honteux. Juste une attaque gratuite. Par ailleurs, j'imagine mal Redhat, Suse et Debian laisser systemd devenir un machin inutilisable alors que ce programme est de la première importance.
[^] # Re: linuxo-centré.
Posté par Albert_ . Évalué à 2.
je n'ai pas dit que ce que fais LP etait mauvais ou honteux je dis que cela n'est pas fini.
Note: compare avahi avec ce que propose bonjour sous mac et tu verras a quel point c'est pas encore "in working state".
[^] # Re: linuxo-centré.
Posté par JGO . Évalué à 2.
J'y connais pas grand chose, alors je lis wikipédia : Avahi vs. Bonjour. Je ne vois que des éloges pour Avahi. Peux-tu expliquer les problèmes ?
[^] # Re: linuxo-centré.
Posté par Albert_ . Évalué à 2.
je ne sais plus cela c'est passe il y a quelques mois. Mais sous son mac il a reussi a faire un truc que j'ai jamais reussi avec avahi. Alors c'est peut etre faisable mais la ou je considere que c'est pas fini c'est que pour un utilisateur lambda c'est pas utilisable. Si il veut ameliorer les trucs pour le desktop comme il le dit, le fait de rendre les technos qu'il met facilement utilisable est fondamental. De ce point de vue la, au minimum, avahi (et PA) ne sont pas fini.
[^] # Re: linuxo-centré.
Posté par inico (site web personnel) . Évalué à 2.
Quel truc ?
Merci d'argumenter avant d'attaquer gratuitement un logiciel.
[^] # Re:linuxo-centré.
Posté par Juke (site web personnel) . Évalué à 2.
Le mercredi 04 mai 2011 à 20:36 +0200, Albert_ a écrit :
> je ne sais plus cela c'est passe il y a quelques mois.
à 20h06 tu dis qu'un soft ne tiens pas la comparaison avec un
concurrent.
à 20h36 tu ne sais plus pourquoi
...
[^] # Re:linuxo-centré.
Posté par Albert_ . Évalué à 2.
Se connecter sur le pc voisin. C'etais fait en deux clics avec les macs et avec avahi cela aurait du etre pareil et bien cela ne l'etait pas mais bon OpenSuse doit faire une integration de merde ou bien l'utilisateur devrait aller tripatouiller a la mano dans /etc/avahi c'est super friendly ca.
Le truc c'est regle utilisant kio ssh sur l'adresse ip c'etait plus rapide et cela fonctionnait sans se prendre la tete.
[^] # Re:Re:linuxo-centré.
Posté par Juke (site web personnel) . Évalué à 1.
Le jeudi 05 mai 2011 à 14:13 +0200, Albert_ a écrit :
> Se connecter sur le pc voisin. C'etais fait en deux clics avec les
> macs et
> avec avahi cela aurait du etre pareil
c'est fait en un clic, avahi annonce les services (chez moi ssh, sftp)
et nautilus y accède facilement.
[^] # Re:Re:linuxo-centré.
Posté par Albert_ . Évalué à 0.
c'est bien cela marche chez toi, clap clap clap.
[^] # Re: linuxo-centré.
Posté par ahuillet (site web personnel) . Évalué à -1.
Pulseaudio, un programme de la première importance ? Y a un truc pas clair dans ta tête...
[^] # Re: linuxo-centré.
Posté par Enoch (site web personnel) . Évalué à 4.
Sa tête a l'air d'aller bien, par contre il te faut peut être faire vérifier ta vue ...
[^] # Re: linuxo-centré.
Posté par Zenitram (site web personnel) . Évalué à 6.
Fait gaffe, à force tu es capable de finir par m'apprécier ;-).
Exactement. Et en ne faisant pas attention à BSD, c'est ce qui peut revenir, si jamais un jour BSD prend de l'importance. Aujourd'hui, la chance est que Linux a une part de marché des *nix importante, mais le jour où un autre *nix viendra titiller, ben même problème que les UNIX, l'histoire est un éternel recommencement, l'être humain a du mal avec l'histoire
Par définition, décider à plusieurs sera toujours plus long que tout seul. Tout comme la démocratie est longue à décider par rapport à un dictateur. Mais c'est un mal nécessaire.
On va être trop souvent en phase ;-).
[^] # Re: linuxo-centré.
Posté par jbbourgoin (site web personnel) . Évalué à 2.
Je suis bien d'accord.
Pourquoi vouloir à tout prix assurrer une compatibilité quasi totale entre BSD et Linux (voire entre les distros Linux), si c'est pour, au final, ne connaître quasiment aucune différences entre les systèmes et stagner sur des fonctionnalités utiles ? Autant en finir avec l'un ou l'autre.
# Quand même... pourquoi ?
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 7.
Déjà que j'ai toujours pas compris l'utilité de avahi à part bouffer de la RAM sans jamais servir à rien (et que j'ai toujours pas pigé à quoi servent les bloats type consolekit non plus), là ça ressemble bien à un bloat quand même, déjà par l'utilisation de DBUS (dans le process de démarrage WTF ?!), et rien qu'en voyant la liste monstrueuse des fonctionnalités et ceci : 2688 ko occupés, contre 244 ko pour sysv (paquets debian). 10 fois plus ! Quand on travaille comme moi sur une étendue de machines allant du quad core 8 Go de ram au celeron 64Mo en passant par des trucs à base d'ARM avec quelques Mo de RAM seulement, on ne peut que flipper en voyant une telle taille pour une tâche aussi simple normalement.
Quand au problème de la rapidité, je dirais : vaut-il vraiment tous ces efforts, tout ce bordel ? Depuis debian squeeze mon laptop démarre en quelques secondes seulement, mon desktop un peu plus mais bon ça dépasse pas une minute. Pour une utilisation desktop justement, on s'en fout pas mal d'attendre 20 secondes de moins, on ne démarre sa machine qu'une fois par jour en général... Là où ça serait utile ça serait sur les équipements embarqués, par exemple sur mon e-reader oui 20 secondes de boot c'est naze, mais c'est le genre de matos ou de toutes façons un tel soft n'a aucune chance d'avoir sa place vu le bloat que ça semble être, sans compter les dépendances délirantes...
Bref franchement : quel est l'intérêt de ce truc ?
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Quand même... pourquoi ?
Posté par boq . Évalué à 3.
Ne t'inquiète pas les features de ConsoleKit vont être intégrée à systemd et tu pourra enlever CK de ta machine. \o/
A quoi ça sert? A "amener systemd jusqu'au sessions utilisateur".
http://lwn.net/Articles/441328/
[^] # Re: Quand même... pourquoi ?
Posté par gouttegd . Évalué à 10.
Tu ne dois pas être le seul, l’auteur de la doc de ConsoleKit ne semble pas le savoir non plus :
ConsoleKit sert donc à résoudre un problème que l’on ne savait manifestement pas résoudre avant sans lui, mais on ne sait pas exactement lequel.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.