C'est officiel, Ubuntu étant basé sur Debian, il passera lui aussi sous systemd :
http://www.markshuttleworth.com/archives/1316
Pour les anglophobes, Mark dit en gros qu'il a perdu son pari de miser sur Upstart, et que malgré la qualité de son code (ayant été utilisé par Ubuntu et RHEL 6), il s'incline. Upstart restera l'init par défaut sous Ubuntu 14.04, mais ensuite, le switch sous systemd se fera.
Donc voilà, une tentative de NIH de Canonical qui tombe à l'eau. Mir sera-t-il le prochain ? À vous de juger !
# fin de l'histoire ?
Posté par Adrien . Évalué à 10. Dernière modification le 14 février 2014 à 15:06.
Donc si j'ai bien compris, systemd va devenir la référence, après le dinosaure sysv-init, tous les autres vont mourir autour. Que de troll pour en arriver la :)
EDIT: comme pulseaudio pour le son sur le bureau finalement.
[^] # Re: fin de l'histoire ?
Posté par jadfa . Évalué à 1. Dernière modification le 14 février 2014 à 15:28.
Sépafo. Mais pulse, tu pouvais (peux toujours) facilement le virer (au début, hein, quand ça merdait grave; maintenant on peut le garder.).
[^] # Re: fin de l'histoire ?
Posté par Adrien . Évalué à 3.
Tout comme aujourd'hui on peut virer systemd. D'ailleurs, sous Debian on peut passer de l'un à l'autre très facilement, au démarrage.
[^] # Re: fin de l'histoire ?
Posté par cluxter . Évalué à -2.
J'avais lu que les versions récentes de Gnome nécessitaient impérativement 'systemd', les développeurs disent qu'en fait non. Du coup je ne comprends pas trop, si quelqu'un sait nous expliquer ce n'est pas de refus ;)
Toujours est-il que si des projets comme Gnome imposent la présence de 'systemd', ça risque d'être fort difficile de s'en passer. On peut encore se passer de Gnome (heureusement !!) mais j'espère que les autres projets auront le bon goût de ne pas imposer 'systemd' pour fonctionner.
Je n'ai rien pour ou contre 'systemd', je veux juste conserver ma liberté de choisir ce qui me va le mieux indépendamment des autres briques logiciels que j'ai sur ma machine.
[^] # Contrainte et liberté
Posté par Sylvain Blandel . Évalué à 2.
Pendant des années, des tas de projets (les distributions Linux) imposaient la présence de SysVinit.
Les développeurs de logiciels, eux aussi, souhaitent conserver leur liberté de choisir. Un certain nombre d'entre eux choisissent de s'appuyer sur systemd pour faire fonctionner leur logiciel.
[^] # Re: fin de l'histoire ?
Posté par Anonyme . Évalué à 2.
Tu es libre d'essaier de faire fonctionner ces differentes briques entre elles, voir que ca ne fonctionne pas et faire le travail pour que ca puisse fonctionner, mais pas d'imposer aux developpeurs de faire ce travail pour toi si ils n'en ont pas envie.
[^] # Re: fin de l'histoire ?
Posté par ariasuni . Évalué à 6.
Ça dépend pour qui… Je songe sérieusement à le faire parce qu’il finit toujours par avoir des problèmes. Pas des gros problèmes, mais suffisamment chiant pour que je finisse par le désinstaller plutôt que de passer mon temps à modifier sa conf pour qu’il marche comme il devrait dès le départ.
Et c’est pas faute de mauvaise volonté, mais il finit toujours par déconner. Par exemple, j’ai le droit à ce problème à chaque fois, et là je crois que j’ai celui-là.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: fin de l'histoire ?
Posté par freem . Évalué à 1.
Hum…
Désolé, mais le nombre de pulse machin sur mon système est inférieur à celui des modules systemd. Ou du moins, plus simple à rendre tel:
$ aptitude search ~i |grep pulse
i A libpulse-dev - PulseAudio client development headers and
i A libpulse-mainloop-glib0 - bibliothèques clients PulseAudio - gestion
i A libpulse0 - bibliothèques clientes PulseAudio
A noter que les raisons d'installation de ces paquets sont, pour les 2 1ers, la lib de dev de SDL, et pour le 3eme, mplayer.
Systemd, en revanche, c'est plus chiant:
mpd en dépend ( libsystemd-daemon0 )
dbus en dépend ( libsystemd-journal0 ainsi que libsystemd-login0 et pour virer dbus, sans perdre de fonctionnalités, bon courage! )
Bref, rien de comparable. Le 1er ( PA ) ne squatte quasiment que via certaines lib de dev, tandis que l'autre s'incruste au travers d'outils centraux du système.
[^] # Re: fin de l'histoire ?
Posté par zebra3 . Évalué à 2.
J'avoue que je ne sais pas pour dbus, mais rien ne t'empêche de recompiler mpd et mplayer sans ces dépendances.
Recompiler des paquets debian est assez simple, vois cette doc : apt télécharge lui-même les paquets sources et dépendances, il faut juste modifier le fichier control avec les bonnes options de compilation.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: fin de l'histoire ?
Posté par freem . Évalué à 1.
Si je ne m'abuse, dbus est surtout utilisé pour 2 choses:
_ récupérer une partie des droits root avec un utilisateur normal ( genre, pour contrôler le réseau: wicd par exemple dépend avec raison de dbus. Cet usage me semble normal et incontournable, malgré le fait que je n'apprécie pas du tout le fait que dbus utilise XML pour de la configuration, notamment. )
_ notifier une application que sa configuration à été modifiée par une autre ( il paraît. Sauf que personnellement, n'étant pas un utilisateur de DE pré-construit, je m'en tamponne un peu. En plus, je pense que seule une application devrait être experte de sa propre configuration, exactement comme une classe est la seule à manipuler ses données internes selon GRASP. Ce type de dépendance, je m'en passerai volontiers. )
Alors que PA, lui, peut être désactivé à peu près quand on veut sans handicaper le moins du monde les applications qui en "dépendent", en tout cas pour toutes celles que j'ai utilisées jusqu'à aujourd'hui ( ce qui ne veux pas dire que mon expérience est généralisable, je sais. Mais juste que je me permets de supposer que c'est le cas de bon nombre d' "utilisateurs audio classiques" qui ne font qu'écouter de la musique et regarder des films, avec un peu de mumble/skype au passage.).
Recompiler un paquet est simple oui, c'est certain. Mais ça signifie aussi qu'il faut le refaire à chaque nouvelle MaJ, et apt ne gère pas, à ma connaissance, le multi-tasking/threading, ce qui rend les MaJ un peu importantes déjà assez longues comme ça, sans vouloir y rajouter de la compilation.
En fait, si je voulais m'amuser a recompiler les paquets, nul doute que je ne m'orienterait pas vers Debian, qui n'est pas faite pour cet usage ( ce qui ne veut pas dire qu'on ne peut pas, juste que ça ne me semble pas être l'esprit ), mais plutôt vers sourcemage, gentoo, ou une distro dans ce style ( à noter que je me suis déjà essayé à gentoo, mais la compilation du kernel m'a stoppé net. Le mieux que j'aie réussi est un kernel lent - comparé à Debian - auquel il fallait passer des infos à la main au boot. Je réessaierai sûrement plus tard, ceci dit. ) qui ont de la doc naturellement plus poussée ainsi qu'un système de build conçu pour ça. Peut-être le jour ou linux compilera avec clang, qui sait ( histoire de passer moins de temps à la compilation ) …
[^] # Re: fin de l'histoire ?
Posté par navaati . Évalué à 1.
heu… libsystemd-truc c'est pas systemd, c'est juste des petites lib utilitaires de quelques ko…
[^] # Re: fin de l'histoire ?
Posté par freem . Évalué à 1.
En effet, ils ne sont pas la totalité de systemd, et n'impliquent pas l'installation du cœur de systemd..
Sauf que, ce sont des utilitaires qui ne servent à rien si tu n'as pas systemd installé. C'est du moins ce que me disent les description de ces paquets dans aptitude.
Après tout, systemd, ce n'est pas que le système d'init, mais aussi les outils qui gravitent autour, ainsi que des trucs qui n'ont rien à voir avec l'init. C'est même un des points forts de systemd. Ou de ses points faibles, en fonction du point de vue de l'utilisateur.
Je me souviens d'une phrase qui dit un truc de ce genre:
Un logiciel n'est pas parfait quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à enlever.
Malheureusement, je ne connais pas l'auteur, et je ne suis pas sûr d'avoir retranscrit fidèlement, mais le lien avec systemd, et les dépendances aux interfaces de systemd, me semble évident. On ajoute des choses qui n'ont pas forcément lieu d'être. Le souci est aussi que le nombre de fonctionnalités minimum d'un logiciel est différent d'une personne à l'autre :)
[^] # Re: fin de l'histoire ?
Posté par Renault (site web personnel) . Évalué à 4.
C'est une adaptation de la phrase de Saint-Exupéry qui était plus généraliste que ça (applicable à toute perfection).
[^] # Re: fin de l'histoire ?
Posté par freem . Évalué à 1.
Merci bien. Ca m'ennuyait de citer sans mettre le nom, et pire, sans mettre la citation exacte :S
[^] # Re: fin de l'histoire ?
Posté par Spyhawk . Évalué à 6.
La citation originale et l'auteur sont:
[^] # Re: fin de l'histoire ?
Posté par Maclag . Évalué à 7.
Je pense que c'est l'ancienne version. Dans la nouvelle, ils ont décidé de simplifier un peu pour ne pas que les utilisateurs soient trop confus:
"La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien"
[^] # Re: fin de l'histoire ?
Posté par ariasuni . Évalué à 1.
De-évolution!
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: fin de l'histoire ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à -8.
Sauf que systemd est bien conçu, LUI
[^] # Re: fin de l'histoire ?
Posté par kursus_hc . Évalué à 10.
Pulesaudio EST bien conçu (bon à part la partie réseau qui est à la rue), pour la millième fois c'est la principale raison pour laquelle il y a eu autant de problèmes au début : il a fait ressortir les vilains hacks empilés dans les drivers depuis des années.
[^] # Re: fin de l'histoire ?
Posté par eingousef . Évalué à 6.
Vas-y essaye de faire un screenscast sous Linux en capturant l'audio sans t'arracher les cheveux.
Quand t'auras réussi à obtenir un fichier avec le son synchro, avec le bon volume et la bonne fréquence, sans faire de manips débiles jore killer des démons entre deux captures, là tu pourras me dire que pulseaudio est bien conçu.
*splash!*
[^] # Re: fin de l'histoire ?
Posté par kursus_hc . Évalué à 3.
Quel logiciel pour la capture ? C'était bien Pulseaudio 4 ?
[^] # Re: fin de l'histoire ?
Posté par eingousef . Évalué à 2.
Oui pulseaudio 4 et ffmpeg pour la capture.
*splash!*
[^] # Re: fin de l'histoire ?
Posté par kursus_hc . Évalué à 4.
C'est peut-être la 'priorité temps réel' qui n'est pas autorisée sur ton système, beaucoup de distribution ne le font pas par défaut :
http://superuser.com/questions/40429/how-do-i-run-pulseaudio-with-realtime-priority-in-ubuntu-9-04
Au démarrage de pulseaudio tu devrais avoir ces lignes :
[^] # Re: fin de l'histoire ?
Posté par eingousef . Évalué à 5.
Il me faut un noyau rt pour faire des vidéos de jeux ? O_o
Ça risque pas d'avoir une incidence sur les perfs ?
Les gens qui font des vidéos de jeux sous windows ils utilisent un kernel Windows rt ? O_o
*splash!*
[^] # Re: fin de l'histoire ?
Posté par gouttegd . Évalué à 7.
Non. Nul besoin d’un noyau -rt pour donner à un processus une priorité « temps réel ». Mais il faut avoir le droit de le faire, et configurer le système pour obtenir ce droit n’a pas toujours été simple, surtout parce que la « bonne méthode » pour le faire a régulièrement changé.
[^] # Re: fin de l'histoire ?
Posté par kursus_hc . Évalué à 2.
Oui désolé le lien est moyen, pas besoin de noyeau RT. Pour référence, sous debian dans /etc/security/limits.conf :
En ajoutant l'utilisateur courant aux groupes audio et pulse-rt
Suffit pour faire passer pulseaudio en real-time priority.
[^] # Re: fin de l'histoire ?
Posté par eingousef . Évalué à 3.
Bon alors pour le test j'ai réinstallé pulseaudio et ffmpeg, ça marchait impeccable sans rien faire après le premier reboot, mais après le deuxième reboot, rien à faire le son est "ralenti" sur la capture. Donc je vais appliquer ta méthode, mais je veux juste savoir d'où tu sors ce groupe "pulse-rt", j'ai pas ça chez moi. Il y a "pulse", "pulse-access" mais pas "pulse-rt".
*splash!*
[^] # Re: fin de l'histoire ?
Posté par eingousef . Évalué à 10.
PS: Et ça m'enlèvera pas de l'idée qu'en 2014, faire un screencast de ses jeux sous linux est toujours une galère, quand n'importe quel petit con sous Windows avec son fraps tipiaké y arrive les doigts dans le nez. Après ça venez pas me dire que linux est raidi pour le daistoppe. :o
*splash!*
[^] # Re: fin de l'histoire ?
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 8.
En fait ça marche au poil… sans pulseaudio ;-) Perso avec juste Alsa et Dmix ça roule, rien à faire de particulier.
J'ai toujours pas pigé l'intérêt de Pulseaudio en tout cas, à part se prendre la tête pour rien. J'ai déjà essayé de l'utiliser plusieurs fois pour des domaines où il est sensé être bon comme diffuser le son local sur une machine distante ou vice-versa et ça marchait au début mais ça finissait toujours par tomber en panne tout seul, sans compter la joie immense de devoir se taper les fichiers de config de PulseAudio. Youpi. Bref.
« 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: fin de l'histoire ?
Posté par eingousef . Évalué à 2.
Bah je sais pas comment tu fais alors. Chez moi impossible de capturer l'audio avec ffmpeg en passant par alsa (et c'est pas faute d'avoir essayé tout plein d'options).
*splash!*
[^] # Re: fin de l'histoire ?
Posté par eingousef . Évalué à 6.
Bon finalement j'ai créé le groupe pulse-rt et j'ai mis l'utilisateur courant dedans.
Alors avant que j'applique ta méthode j'avais une première capture audio correcte après le reboot, et le son était ralenti sur toutes les suivantes, jusqu'au prochain reboot.
Maintenant j'ai une première capture avec le son décalé de deux secondes, et sur les suivantes le son est décalé ET ralenti.
:/
*splash!*
[^] # Re: fin de l'histoire ?
Posté par eingousef . Évalué à 3.
Bon en fait pas besoin de rebooter : un simple "killall pulseaudio && pulseaudio &" suffit.
*splash!*
[^] # Re: fin de l'histoire ?
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Ce n'est pas parcequ'il serait bien conçu qu'il fait re-sortir les problèmes de drivers. NON. C'est parcequ'il a été adopté.
[^] # Re: fin de l'histoire ?
Posté par kursus_hc . Évalué à 4.
Si il avait adopté ET mal conçu (pour accepter les bugs drivers existants), il n'aurait rien fait ressortir du tout. Donc l'adoption n'a rien à voir (bon effectivement il faut quand même quelques utilisateurs je le concède).
Je ne défend pas particulièrement pulseaudio, surtout qu'il a des défauts, sa complexité par exemple (une connaissance avancée du fonctionnement est indispensable dès lors qu'on sort des situations classiques), mais il n'est pas mal conçu.
[^] # Re: fin de l'histoire ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 10.
Beau moinssage (assez mérité il est vrai malgré le trolldi ;)
Ce que je reprocherai à Pulse audio, ce n'est pas d'avoir eu des merdes au début (même si c'était lourd…), ni même de lever les bugs de drivers. Je fais partie de ceux qui sont conscient de l'apport fonctionnel (bluetooth, volume par application, …).
Mais j'ai l'impression d'une occasion manqué pour l'instant avec Pulse sur le spaguetti mille feuille de la pile audio Linuxienne (Alsa and co, OSS, Jack, ….). La où systemd remplace avantageusement tout ce qui précède. Wayland aussi… journald aussi… avec une conception robuste, moderne et performante… le compte n'y est pas à mon avis avec Pulse (pas de nettoyage de ce bordel, pas de latence réduite, conso CPU et Ram élevé…). Sur toute la couche basse, cela manque d'intégration avec le noyau (il y a probablement des gains a trouver en virant/simplifiant la couche alsa entre le noyau et Pulse).
J'avoue avoir eu quelques frayeurs en voyant systemd venir du même Lennart, mais j'ai changé d'avis en voyant la qualité technique de systemd. Il semble avoir appris de ses erreurs, gère mieux la collaboration avec les dev du kernel, ainsi que sa communication publique sans pour autant troquer son caractère affirmé (il en faut pour changer les choses).
Si on imagine une distrib de dans 2 ans, on peut imaginer:
- Un noyau linux toujours au top (incroyable une communauté et un leader aussi efficace)
- Un linux "userland" toujours plus modernisé avec systemd, journald… Un boot ultra rapide, des outils efficace pour chaque tache, des confs simple…
- Une gestion graphique enfin modernisé avec Wayland (sécurité, maintenance simplifié, légèreté…)
- Nos bureaux KDE/Gnome toujour plus moderne mais peut-être aussi des nouveautés favorisé par wayland car on voit que cela bouge un peu plus (Hawaii, LXDE, E…)
- Et toujours un beau bordel au niveau de la pile audio…. Et j'aimerai que Lennart, fort de son expérience, nous refasse maintenant une 2eme passe pour changer tout cela…
[^] # Re: fin de l'histoire ?
Posté par ariasuni . Évalué à 2.
J’ai eu de l’espoir avec KLANG… J’ai l’impression que personne ne veut à nouveau casser l’audio sous GNU/Linux.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: fin de l'histoire ?
Posté par Misc (site web personnel) . Évalué à 0.
Il te faut pas grand chose pour avoir de l'espoir. Klang a été annoncé en juillet 2012, et le site web dit encore "on va avoir un design document dés que possible".
[^] # Re: fin de l'histoire ?
Posté par ariasuni . Évalué à 10.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: fin de l'histoire ?
Posté par gouttegd . Évalué à 10.
« Mille feuille » ?
La pile audio Linux moderne, c’est :
– les pilotes ALSA dans le noyau ;
– la partie “userspace” de ALSA (libasound) ;
– un serveur son, PulseAudio.
On est quand même loin d’un mille-feuille et d’un « beau bordel ».
La couche de compatibilité OSS que fournit ALSA n’est là que pour permettre à des programmes ne supportant que l’API OSS de fonctionner de manière transparente. On pourrait s’en passer, mais elle ne gène personne. Quant au vrai OSS, je ne le considère pas comme faisant partie de la pile audio Linux classique, on peut l’utiliser à la place d’ALSA mais ça relève d’un choix délibéré d’un utilisateur qui a ses raisons de préférer OSS.
Jack est un serveur de son spécialisé, là encore je ne le classerais pas dans la pile audio classique. Ceux qui n’en ont pas besoin peuvent ignorer jusqu’à son existence. Le fait que la pile audio Linux se divise en deux branches au niveau du serveur son (PulseAudio pour l’usage général, Jack pour l’audio pro) n’est pas particulièrement choquant, pour rappel on a quelque chose de similaire sous Windows avec la pile ASIO. Il y a de bonnes raisons à cela, sur lesquelles tant les développeurs de Jack que ceux de PulseAudio sont d’accord.
Et pitié, ne ressortez pas le schéma ignoble pondu par Adobe il y a quelques années — la flemme de le retrouver, mais je suis sûr que vous voyez de quel schéma je parle : ce schéma dans laquelle on nous présente OpenAL, SDL, Allegro, GStreamer et une dizaine d’autres bibliothèques comme faisant partie de la pile audio Linux et censé illustrer sa complexité démente. Oui, un programmeur sous Linux a le choix entre de nombreuses bibliothèques s’il ne veut pas utiliser libasound ou libpulse directement. Et alors ? Sous Windows aussi un programmeur peut utiliser la SDL pour jouer du son, qui prétendra que la SDL fait partie de la pile audio Windows et que celle-ci est trop compliquée ?
A priori, je suppose que PulseAudio pourrait effectivement se passer de libasound et communiquer directement avec la partie noyau de ALSA via
/dev/snd/. Ses développeurs n’ont peut-être pas voulu ré-implémenter dans PulseAudio ce que libasound fait déjà. Quoi qu’il en soit, un tel changement ne serait qu’un détail d’implémentation de PulseAudio, il n’y a nul besoin de réclamer une refonte complète de la pile audio pour ça.Tu devrais peut-être lui fournir un cahier des charges un peu plus précis que « changer tout cela », non ? Je n’ai pas vu de griefs précisément formulés dans ton message.
[^] # Re: fin de l'histoire ?
Posté par Maclag . Évalué à 5.
Si tu me demandes à moi, je te dirais que de ce que j'en comprends, il y a des redondances dans les fonctionnalités entre Alsa et PulseAudio, et ça c'est pas très propre, et ça porte pas mal à confusion.
Aujourd'hui, quand on a un souci sur l'affichage, on peut trouver assez simplement la couche à l'origine du problème. Pour le son, ça semble bien plus nébuleux, et on a souvent lu "pour résoudre le problème, vire PulseAudio" sans même vraiment savoir si c'est PA qui est en cause, ou son intégration.
En fait, vu l'historique de la couche, j'aurais presque préféré qu'une installation de PA intercepte les appels vers Alsa et fasse tout passer par PA, histoire d'éviter cet imbroglio entre les couches!
C'est pour ça que moi aussi, j'aurais préféré qu'on remette tout à plat plutôt que de faire juste un truc "qui marche".
[^] # Re: fin de l'histoire ?
Posté par Alex . Évalué à 3.
je ne comprends pas trop, normalement (si j'ai moi même tout compris) alsa s'occupe de restituer le son sur ton chip audio, pulse s'occupe de son traitement
ensuite tu as quelques utilitaires plus haut niveau livré avec alsa, comme dmix pour mixer plusieurs sources sonores, et en effet aujourd’hui cest à pulseaudio de traiter cela, mais à mon avis c'était plus des workarround proposés par alsa qui n'avait rien à faire là.
AMHA c'est justement beaucoup plus clair que l'affichage, qui passe par une miriade de couches (KMS, ou X-(Xlib|Xcb)-Xrender|jsaisplusquoi-Driver X-DRI-DRM… sachant que j'en ai oublié et que je ne comprends pas bien toute la stack)
[^] # Re: fin de l'histoire ?
Posté par Maclag . Évalué à 5.
Oui, donc un PA-dmix qui intercepte tout appel à dmix en attendant qu'on vire alsa-dmix, ça aurait pas été plus mal, c'est exactement ce que je veux dire! Là quand ça déconne, t'as aucune chance de savoir si c'est pas un conflit entre deux outils qui font la même chose depuis 2 couches différentes.
[^] # Re: fin de l'histoire ?
Posté par navaati . Évalué à 8.
C'est déjà le cas, faut mettre dans son asoundrc (fait automatiquement sur la plupart des distros j'imagine) :
[^] # Re: fin de l'histoire ?
Posté par gouttegd . Évalué à 6.
Et il faudrait nécessairement « remettre tout à plat » à cause de ça ?
Pourquoi ne pas simplement supprimer progressivement de ALSA les fonctionnalités qu’il convient à présent de confier à PulseAudio ? Ou, mieux encore (pour ne pas faire de la peine à ceux qui n’utilisent pas PulseAudio, comme moi par exemple), faire en sorte que les distributions qui installent PulseAudio par défaut n’installent pas les fonctionnalités redondantes de ALSA — et pour ça il n’y a quasiment rien à faire, en effet libasound est déjà modulaire, ses différents modules sont tous (dés)activables à la compilation.
Par exemple, le module dmix est désormais inutile parce que PulseAudio se charge du mixage ? Il suffit de compiler libasound sans ce module.
Je sais et c’est complètement stupide en effet. Mais que PulseAudio ait été mal intégré dans certaines distributions ne signifie pas qu’il faut refondre intégralement la pile audio, ça signifie juste qu’il faut… au hasard, mieux intégrer PulseAudio ?
[^] # Re: fin de l'histoire ?
Posté par Misc (site web personnel) . Évalué à 3.
Pour compléter ce que tu dis
http://blogs.adobe.com/penguinswf/2007/05/welcome_to_the_jungle.html
Mais le schéma a disparu du site lui même.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: fin de l'histoire ?
Posté par saltimbanque (site web personnel) . Évalué à 6.
En tout cas Mark est devenu un bien meilleur éditeur de texte
# NIH ?
Posté par zul (site web personnel) . Évalué à 10.
upstart me semble largement précédé systemd (il est intégré dans ubuntu depuis 6.10 alors que systemd est sorti vers 2010). Bref on peut arrêter le FUD, on dirait des suppôts de chez Microsoft :D
[^] # Re: NIH ?
Posté par Shuba . Évalué à 2.
Disons que upstart n'a jamais été très ouvert aux contributions extérieures, ce qui a incité à la création d'une alternative.
[^] # Re: NIH ?
Posté par Spyhawk . Évalué à 6.
Si si, justement. C'est juste que c'est à sens unique, comme mentionné dans ton premier lien:
[^] # Re: NIH ?
Posté par Zenitram (site web personnel) . Évalué à -4.
Sens unique? Un développeur qui accpete un patch dans sa branche principale s'engage à maintenir le patch totue la vie du projet.
Dire que c'est à sens uniquement est une grosse connerie de personne pensant qu'un patch vit sa vie seul ensuite, ce qui est complètement faux.
[^] # Re: NIH ?
Posté par Misc (site web personnel) . Évalué à 5.
A ce moment, suffit juste de refuser les patchs, ça se fait très bien.
[^] # Re: NIH ?
Posté par Zenitram (site web personnel) . Évalué à -2.
"vie du projet" était trop loin, et oui on peut refuser (encore heureux, et… Ca se fait pour les gens refusant de signer le CLA), vous avez loupé le point principal de ma réaction : dire que c'est à sens unique (tout comme le fait le mec sur son "blog") est se foutre de la gueule du monde, car il y a bien un échange (la personne qui reçoit le patch va le vérifier, essayer de le maintenir quand il change l'architecture… Et surtout le rendre disponible à tout le monde).
On peut ne pas être d'accord avec le contrat proposé, mais dire que c'est à sens unique est juste se faire plaisir à se conforter dans son opinion quitte à déformer la réalité.
[^] # Re: NIH ?
Posté par Moonz . Évalué à 10.
Un développeur qui supprime des fonctionnalités plus maintenues ça s’est jamais vu effectivement.
[^] # Re: NIH ?
Posté par Spyhawk . Évalué à 9.
Encore heureux! Manquerai plus qu'il s'approprie le copyright du code et oblige le contributeur à le maintenir à jamais…
[^] # Re: NIH ?
Posté par Zenitram (site web personnel) . Évalué à 1.
FUD.
Tu n'aimes peut-être pas les CLA, mais ça ne veut absolument pas dire que les contributions extérieures sont refusées. Seulement des contributions de gens voulant faire chier leur monde avec leur croisades anti-CLA.
Perso, je trouve horrible que Linus refuse les patchs sous GPLv3, le monde est tellement horrible avec la GPLv2 (TiVo ça pue), disons que Linus n'a jamais été très ouvert aux contributions extérieures. Tu trouves ça stupide? C'est exactement ce que tu dis, en prenant un truc qui n'a rien à voir (un CLA demandé) et en le confondant avec "contributions extérieures".
Je peux aussi parler de code pourri qui est refusé, la personne qui se voit refuser l'inclusion va se plaindre qu'ils refusent les contributions extérieures, en mélangeant ses principes (genre le code pourri est acceptable) et "contribution extérieures".
Je n'ai rien contre les gens gens qui refusent les CLA, mais j'en ai contre les gens qui balancent des trucs qui n'ont rien à voir sur ce sujet (genre pas très ouvert aux contributions extérieures"), parce qu'ils mélangent tout pour juste cracher sur une entité, pas grave de savoir si c'est vrai ou pas (un peu comme les gens anti-systemd d'ailleurs).
C'est d'ailleurs rigolo que ce genre d'attaque ne concerne que Canonical, jamais Digia (pour Qt) par exemple…
[^] # Re: NIH ?
Posté par Shuba . Évalué à 3.
Il existe des gens qui sont contre les CLA, c'est un fait, et le fait d'avoir un CLA ne les incite pas à contribuer. Mon avis personnel sur les CLA (je m'en fous) n'a rien à voir là dedans, ça explique juste l'apparition d'un concurrent avec une license différente.
La formulation est trollesque, certes, mais on est vendredi, non?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5. Dernière modification le 14 février 2014 à 22:06.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: NIH ?
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 14 février 2014 à 22:29.
Je pense que par "licence" il entendait "GPLv2 avec CLA pour les contributeurs" vs "LGPLv2 sans CLA".
D'ailleurs, ça m'étonne que Red Hat ne demande pas de CLA vu comme c'est chiant à gérer des juristes sans CLA.
(edit : j'ai trouvé un "Red Hat CLA" perdu sur le net, ça ne s'applique pas aux contributions systemd? c'est que "parfois"?)
[^] # Re: NIH ?
Posté par navaati . Évalué à 3.
Ça ne s'applique clairement pas à systemd, j'ai fait un petit patch une fois et je n'ai rien signé du tout.
[^] # Re: NIH ?
Posté par Misc (site web personnel) . Évalué à 7.
Globalement, non. Et vu que parmi les juristes de RH, tu as Richard Fontana qui a co-écrit la GPL v3, je pense que l'équipe comprends le libre et ce que ça fait.
Il y a aussi des gens qui comprennent ce qui fait qu'une communauté marche, et qu'un CLA de quelque nature que ça soit, ça reste un obstacle de plus à la contribution ( comme le fait de devoir ouvrir un compte spécifique ou ce genre de choses, comme expliqué par Dave Neary sur http://blogs.gnome.org/bolsh/2012/09/14/attention-speed-bump-ahead/ ( qui justement bosse dans la dite équipe OSAS de Red hat, qui justement vise à conseiller les projets upstream en matière de communauté ).
D'ailleurs, il est amusant de voir que Jono Bacon, community manager chez Canonical, le dise aussi dans son bouquin, mais visiblement, qu'il n'a pas réussi à convaincre sa hiérarchie.
[^] # Re: NIH ?
Posté par Zenitram (site web personnel) . Évalué à -1.
Cet argument marche pour toute demande de CLA, y compris Digia, FSF (pour le projet GNU, vraiment ces gars ils sont horribles avec leur CLA à mettre des bosses)… Mais bizarrement on parle surtout que de Canonical. Peut-être parce que ce n'est pas la raison?
Et il faut arrêter le délire, chez Digia par exemple c'est quelques clics dans l'interface web, si tu es capable d'écrire quelque chose tu es capable de cliquer.
L'argument de Xavier, bien que ne parlant pas de CLA mais de certains CLA alors que les gens disent toujours "les CLA ça pue" de manière générale, et déjà plus convainquant… C'est plus des questions de "principes" qu'autre chose.
[^] # Re: NIH ?
Posté par Misc (site web personnel) . Évalué à 10.
L'argument en question marche aussi pour la FSF. J'ai envoyé un patch pour grub2 et j'ai du attendre quelques semaines le temps de faire les papiers pour qu'il soit intégrer. Moi, ça me dérange pas, mais je connait des gens que ça dérange.
Et si tu parlais avec des gens du libres en dehors de linuxfr (genre sur irc, au fosdem, voir dans mon cas, au boulot) et surtout sans un filtre ou tu retiens que ce qui te permet de troller, tu verrais que les procédures de la FSF sont pas universellement acceptés. La différence est que dans le cas de la FSF, personne ne va te dire "je n'aime pas parce que je me fait flouer". Les gens sont pas d'accord, mais ils comprennent la position de la FSF pour le bien du logiciel libre.
Dans le cas de Canonical, les gens ont vachement moins confiance dans la boite. Par exemple, les annonces de "on va aider ça" ou ça se résume à "on va proposer ça dans Ubuntu", les revirements sur gnome-shell/unity, sur wayland/mir, sur bar/bzr.
Un codeur mercurial francais m'a dit qu'à un moment, il y a eu des propositions de fusionner mercurial et bzr, et que les discussions se sont arrêtés quand Mark a dit "bien sur, le résultat sera entièrement sous le copyright de canonical". Et c'est ce genre d'incidents repetés tout au long de l'histoire de la boite (le coup avec opensuse, le coup avec banshee et rhythmbox) qui font que non, même si digia a le même genre de CLA, les gens parlent pas de ce CLA.
Dans le cas de Canonical, personne ne te dit "on veut pouvoir faire du proprio parce qu'on a besoin un jour d'être à l'équilibre". Et personne chez eux ne veux rappeler le fait que pour le moment, la boite survit depuis 10 ans en tournant à perte. Et il faut dire que quand on se positionne comme champion du libre, ça fait un peu tache de dire ça.
Donc c'est même pas de le faire, c'est surtout l'hypocrisie complète, le fait qu'aux oreilles de beaucoup, tout ça sonne comme un mensonge. Et si tu rajoutes tout les faux pas (comme celui avec Mint et la trademark, avec le mec de la FSF et la trademark), tu aboutis à une situation ou la moindre chose que Shuttleworth fait ou dit part en vrille en plus de son coté polarisant habituel (parler de "losing graciously" implique d'avoir une compétition explicite, ce qui est totalement idiot)
Mais tout ces détails, je ne pense pas que tu les retiennes, vu que tu va continuer à troller sur "pourquoi les gens parlent que du CLA de Canonical et pas de Digia" à la prochaine news sur le sujet, j'ai déjà le sentiment d'avoir parler dans le vide.
[^] # Re: NIH ?
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 15 février 2014 à 10:34.
Qui veut troller?
J'ai réagit sur la notion de CLA empèche les contributions, ce qui est faux.
Et tu le démontres : c'est des choses autour du CLA qui posent problème, des choses sur des "principes". Rien à voir avec le refus de contributions, mais plutôt un désaccord (quitte à reprendre un exemple, c'est comme si une personne qui refuse un patch moisi est "contre le contributions", c'est une question d'accords entre 2 parties).
Alors, excuse-moi, mais toi tu oublies ma réaction initiale qui était une réaction contre l'amalgame entre des détails phylosophiques et "pas ouvert aux contributions".
Donc en gros, dans que je ne suis pas d'accord avec ces positions philosophiques, tu parleras dans le vide car "je n'ai pas compris"?
Désolé de ne pas dire "amen" sur ta position, je suis pas du tout d'accord et ce n'est pas parce que tu parles dans le vide, mais juste parce que tu ne m'as pas convaincu du bien fondé de ta position.
C'est quand même bizarre qu'on passe de "pas ouvert aux contributions" à "CLA" puis à "CLA avec détail x" quand une personne montre que l'argument initial est généralisable à des "gentils". Ou comment adapter la critique hyper générale du début pour arriver à la réduire de plus en plus, en connaissant la conclusion (viser que Canonical).
comme je disais au début : c'est un peu comme les anti-systemd (la même manière de précéder), la différence étant juste que les gens aiment ou pas systemd, aiment ou pas Canonical.
[^] # Re: NIH ?
Posté par freem . Évalué à 2.
Je vais sûrement t'accompagner dans le karma négatif, mais j'admets que ça ne me dérange pas.
Je voulais juste te remercier d'être aussi insistant dans l'art de foutre des coups de pieds dans les fourmilières et de casser les consensus. Le bouton "pertinent" ne le permettant pas quand on arrive à un stade de moinssage aussi important, je me permets ce commentaire inutile.
[^] # Re: NIH ?
Posté par ElChinese . Évalué à 0.
Fontana bossait pour le "Software Freedom Law Center" avant d'être embauché par Red Hat. Je suspecte, juste comme ça, parce que j'ai l'esprit mal tourné, que c'est un genre de renvoi d'ascenseur qu'il ait été embauché.
Une description de son job, telle qu'on la trouve chaque fois qu'il cause quelque part:
Je ne suis pas bien certain que tous chez Red Hat "comprennent" les mêmes choses que "comprend" Mr Fontana. Il lui reste du travail.
Exemple: https://bugzilla.redhat.com/show_bug.cgi?id=1001394
Il s'étonne, mi 2012!, que Red Hat distribue ses OS comme des compilations sous GPLv2, au pretexte qu'une distro est selon lui une "mere aggregation", et que donc c'est "either nonsensical or pointless".
[^] # Re: NIH ?
Posté par Misc (site web personnel) . Évalué à 7.
tu veux dire que c'est pas juste parce qu'il s'agit d'une personne qui a démontré sa capacité à comprendre le libre et à bosser dans la communauté dans un domaine qui manque cruellement de gens (à savoir les juristes spécialisés dans le domaine de la propriété intellectuelle et le libre) ?
Donc tu veux dire qu'un avocat qui passe plusieurs années à apprendre son métier et à l'exercer n'arrive pas à transmettre tout ce savoir en 5 minutes à un nombre arbitraire de gens, comme le montre un bug report isolé ?
Wow, tant de révélations…
[^] # Re: NIH ?
Posté par allcolor (site web personnel) . Évalué à 2.
Dans ce cas, pour GNU… il y a quelques années j'ai contribué à gnu classpath, j'ai dû signer un CLA avec la FSF… sans ça, la contribution n'est pas acceptée, et je pense que c'est ainsi pour une majorité des projets GNU… du coup GNU/la FSF est contre les contribs extérieur selon toi ?
[^] # Re: NIH ?
Posté par claudex . Évalué à 10.
Parce que ce n'est pas les mêmes conditions. Si Canonical fait du propriétaire demain avec ton code et arrête le libre, c'est tant pis pour toi, tu peux juste forker le projet, Canonical, n'a donc que des avantages et aucun inconvénient. Si Digia arrête le libre, la fondation KDE peut relicencier ce qui a été publié de Qt en BSD. Ce n'est pas grand chose mais ça montre qu'il y a certaines concessions. Comme le CLA de la FSF qui garanti que le code sera toujours diffusé sous une licence libre.
« 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: NIH ?
Posté par dave_null (site web personnel) . Évalué à 4.
Si je comprends bien le reproche est que Canonical peut faire du propriétaire grâce au CLA malgré la licence GPL.
Ça veut dire que l'on est encore une fois dans un troll BSD vs GPL ?
[^] # Re: NIH ?
Posté par claudex . Évalué à 10.
Non, avec la licence BSD, tout le monde aurait le droit de faire du proprio, ici, seule Canonical peut le faire, ça manque d'égalité pour pouvoir le comparer avec la BSD.
« 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: NIH ?
Posté par dave_null (site web personnel) . Évalué à 1.
Effectivement c'est pas vraiment bon joueur.
[^] # Re: NIH ?
Posté par Zenitram (site web personnel) . Évalué à 3.
Donc si je suit bien, moi qui demande un CLA et publie en BSD, je suis un "gentil" car tout le monde peut faire quasiment la même chose? Ca milite en faveur de la BSD ça ;-).
"juste"? C'est déjà énorme et enlève une grosse partie de la valeur finacière du code…
[^] # Re: NIH ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Gentil, mais pénible!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: NIH ?
Posté par freem . Évalué à 0. Dernière modification le 17 février 2014 à 20:29.
D'un autre côté, ne pas mettre de CLA, c'est une ""erreur"" ( double guillemets, vous avez vu? ) que divers projets ont faits, projets qui ont ensuite dû contacter les contributeurs 1 par 1 pour essayer d'unifier les licences.
Dans un univers ( impitoyable genre dallas ) tel que l'open source, ce genre de choses ( ne pas imposer de CLA ) peut tuer un projet sur le long terme, tandis qu'avec un CLA, les choses sont claires dès le début, contribue qui veut, forke qui veut, ce qui assure que l'équipe du projet sera toujours apte à faire avancer le projet dans la direction qu'elle souhaite.
Après… c'est sûr, un CLA sans conditions, c'est dangereux pour la liberté du projet, mais on sort clairement du problème généraliste du CLA pour entrer dans la spécialisation du CLA potentiellement privatif.
PS: j'ai hésité sur le terme privatif, mais à force je ne sais plus lequel entre privateur et privatif est réellement français…
[^] # Re: NIH ?
Posté par claudex . Évalué à 7.
Il me semble que le CLA sans condition est plutôt la norme.
« 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: NIH ?
Posté par Zenitram (site web personnel) . Évalué à 0.
Ben, si vous arrivez à vous mettre d'accord sur les conditions…
Râleurs contre les CLA, mettez-vous d'accord et mettez à jour http://www.harmonyagreements.org/ et on en parle plus.
Je sais, c'est chiant de se mettre d'accord car c'est plus facile 10x une personne qui critique 1 truc différent et ne sera pas d'accord avecl es 9 autres que 10 personnes qui font une critique commune.
Car bon, le principal interêt du CLA est d'éviter les merdes (non, je ne pense pas du tout à VLC avec un monde qui change… Linux s'en sort bien sans CLA, reste à savoir pour combien de temps)
[^] # Re: NIH ?
Posté par freem . Évalué à 1.
Ma foi…
Mon opinion sur le sujet est très simple.
Les auteurs d'un logiciels sont en droit de refuser aux autres le droit de le modifier. Ca ne me pose pas plus de souci que ça.
Pourquoi ça ne me pose pas plus de souci que ça?
C'est simple: si quelqu'un n'est pas d'accord, il n'a qu'a faire mieux. Tant qu'il n'y a pas de copyright stupide empêchant la compétition, et tant que les standards sont suivis alors qu'ils n'empêchent pas le progrès, il n'y a pas de mal.
Le point étant que, même si j'aime l'idée du libre et même si je lui reconnaît nombre de qualité, je lui admets surtout la qualité de choisir d'être libéré ou pas. La liberté implique la prise de risque, et tout le monde n'est pas prêt à acheter sa liberté dans ces conditions. Conditions que, personnellement, j'accepte avec des compromis, puisque j'utilise moi-même des logiciels non libres ( flash, opera et le pilote nvidia. Oui, l'un d'entre eux à une alternative """libre""" populaire et 100% fonctionnelle, et de nombreuses alternatives libres tout court. Mais justement, je l'ai choisi en toute liberté de choix et en comprenant le contrat que j'ai signé numériquement, donc je suis libre. Je suis également libre de me passer de vidéos sur le net et d'utiliser pleinement le GPU de ma tour… je l'ai déjà fait.)
[^] # Re: NIH ?
Posté par Zenitram (site web personnel) . Évalué à 1.
On ne se comprend peut-être pas : dans tous les cas (CLA ou pas), c'est libre.
Le CLA permet par exemple de ne pas s'emmerder à passer 2 ans sur le sujet (contacter les développeur, ne pas avoir de réponse, recoder) quand le monde change et qu'il faut passer un logiciel de GPL à LGPL pour être compétitif (sinon le concurrent est choisi, et toi tu meurs faute de masse d'utilisateurs suffisant), ou pour passer de GPLv2 (que t'avais pas mis un "+" car tu sais pas ce que la FSF peut faire) à GPLv3 (parce que tu n'aimes pas TiVo), ou de présenter des copyrights simples etc…
[^] # Re: NIH ?
Posté par Maclag . Évalué à 10.
C'est justement le problème: les contributeurs bénévoles voudraient certainement avoir leur mot à dire sur les changements de licence, ou alors il faut accorder sa confiance à l'autre parti.
Et c'est bien le problème de Canonical: un problème de confiance.
Les portes de sortie n'étaient pas nombreuses, mais confier le développement à une fondation "indépendante" hors du giron de Canonical, ça aurait sûrement aidé pas mal.
Ne nous voilons pas la face: presque tout le monde soupçonne Canonical de vouloir garder l'option "passer en proprio" pour leurs affaires autour des smartphones et nombre de contributeurs potentiels ne veulent pas leur laisser cette option.
Comme écrit plus haut: demander un CLA sans condition, c'est demander de bosser gratuitement pour la boite.
On accepte bien plus facilement de bosser gratuitement pour une association sans but lucratif que pour une entreprise.
[^] # Re: NIH ?
Posté par Zenitram (site web personnel) . Évalué à 1.
Comme écrit plus haut, c'est totalement faux.
Qu'on aime ou pas les conditions, OK, mais balancer ce genre de phrase est tout autant insulter le travail de la boite qui investit (et c'est sans doute la le mot qui pose problème : des gens qui ne comprennent pas que d'autres investissent beaucoup, et veulent "tous à égalité", le monde ne fonctionne pas comme ça).
C'est une façon de penser, de refuser le proprio, de refuser certains modèles économiques, on repart alors dans la gueguerre du copyleft. Mais pas la peine de dire que Canonical n'aime pas les contributions, dites plutôt que vous ne voulez pas certaines choses.
Sans doute un autre problème de compréhension : "bénévole", "gratuit"? Alors effectivement, ça montre clairement le problème, car il n'y a pas forcément de bénévoilat (franchement, tu crois que tous ceux qui committent Linux, par exemple, le font gratos?), c'est un contrat donnant-donnant dont l'une des partie demande quelque chose de "différent" d'autres (et encore, c'est de la confiance, il ne le dit pas tu "soupçonnes", donc pour le moment c'est juste de la peur) et ou une autre partie n'a aucune considération pour le travail de la première partie.
En tous cas, cette discussion me conforte dans l'analyse que j'avais avant : c'est plus de l'anti-Canonical qu'autre chose (pas d'histoire de CLA, pas d'histoire de contribution refusées, pas d'histoire de bénévolat, et j'en passe, c'est plus dans l'émotionel).
[^] # Re: NIH ?
Posté par Maclag . Évalué à 9.
Je commence par la fin:
Je n'ai jamais dit le contraire. Canonical a un rapport souvent ambigü avec le monde Linux. J'avais déjà écrit un long commentaire à ce sujet, mais je ne sais plus où.
Que la boite investisse ou pas ne change rien et n'a rien à voir avec la question: Canonical a investi, ils ont le résultat de cet investissement, c'est à eux. On ne leur prend rien, que je sache.
Et les bénévoles ou les autres boites qui étaient censées contribuer, leurs contributions ne représente aucun investissement?
Entre tous à égalité, et Canonical est un privilégié exclusif, il y avait sûrement un terrain d'entente possible. Ils n'ont pas cherché à le trouver, tant pis pour eux?
Encore une fois, tu parles à la mauvaise personne: je dis bien que c'est un problème Canonical, et que les mêmes conditions demandées par GNU ou la FSF passent toutes seules.
En ce qui concerne le refus du proprio, je le comprends tout-à-fait. Tu peux être pour ou contre, mais tu ne peux pas bouffer à tous les râteliers: demander aux contributeurs "GPListes" de contribuer, à condition qu'ils nous laissent changer la licence sans leur demander leur avis. Venant d'une boite qui a déjà un certain passif, c'est à la limite du foutage de gueule.
Qu'ils soient bénévoles ou payés, ça ne change pas grand chose: soit ils investissent leur temps personnels, soient une boite investit du pognon. Dans les deux cas, il y a investissement.
Et se méfier de Canonical ne veut pas dire que tu n'as aucune considération pour leur travail, mais bien que tu ne leur fais pas confiance.
Là je dirais que c'est toi qui a bien peu de considération pour le travail des contributeurs: "on fait tout comme si c'était Canonical qui avait tout fait, mais on mettra un petit mot de remerciement, ça vous va?".
Par les dire et actions passées de Canonical, leur capital confiance est bas. Tu ne vas quand même pas le reprocher à la "communauté"?
Enfin, je terminerais par une grosse nuance dans les propos:
Tout le monde n'est pas fondamentalement opposé à Canonical, puisque RedHat et Mandriva avaient adopté Upstart en connaissance de cause.
Chez Debian, la conclusion était loin d'être évidente, mais on pouvait déjà lire que si Upstart était choisie, le CLA pourrait entraîner un fork. On n'aura jamais de réponse: si RedHat et les autres avaient choisi de garder Upstart, l'auraient-elles forké pour éviter ce CLA?
Si Canonical n'avait pas exigé ce CLA dès le départ, Upstart serait-il mort?
Encore une fois, Canonical veut contrôler tout son environnement plutôt que de faire confiance à la communauté. Ça se comprend, c'est humain. Mais Canonical oublie qu'elle est construite sur le produit de cette communauté, et tout ceux, ou presque, qui ont essayé de la jouer solo dans le secteur ont mordu la poussière.
[^] # Re: NIH ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Avec la licence MIT, pas besoin de CLA:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: NIH ?
Posté par Zenitram (site web personnel) . Évalué à 1.
Faudrait que je regarde de plus près, de souvenir certains avaient râlés quand un header Linux était passé de BSD à GPL (même si le CLA n'a pas réellement l'effet sur la possibilité de faire ce genre de changement, ça permet déjà de filtrer les personnes chiantes à ce sujet).
Et si la MIT a ça en plus par rapport à BSD, ça va me décider à passer à MIT… (donner le plus de libertés aux gens)
[^] # Re: NIH ?
Posté par robin . Évalué à 3.
Et ce que je trouve pas mal avec la MIT, c'est qu'elle est très simple à comprendre.
L'an dernier quand je m'étais renseigner sur les différentes licences, à la recherche d'une wtfpl je l'avais choisi, car c'était à peu près la seule que je comprenais sans m'arracher les neurones.
bépo powered
[^] # Re: NIH ?
Posté par YBoy360 (site web personnel) . Évalué à 4.
Mandriva/(Mandrake?!) avait un système d'init parallèle avant Ubuntu.
[^] # Re: NIH ?
Posté par YBoy360 (site web personnel) . Évalué à 7.
pinit (2006)
http://forum.mandriva.com/fr/viewtopic.php?t=51698&p=240925
et le développement était ouvert.
[^] # Re: NIH ?
Posté par Misc (site web personnel) . Évalué à 10.
Le NIH s'applique peut être à SysVinit et pas à systemd :p
Mais je ne pense pas que ça soit la raison principale en effet de garder Upstart. Ce qu'on voit, c'est que si Debian passe à systemd (et donc fait le taf d'intégration), alors Ubuntu va suivre. Sans ça, ça aurait du être le taf d'Ubuntu, et je pense que Canonical n'avait juste pas les moyens humains de faire ça alors qu'ils ont des projets à finir.
Ça reviens à une bête question de ressource. Et le fait d'avoir des bugs non corrigés depuis longtemps dans Upstart, d'avoir finalement peu de code poussés dedans ne sont que d'autres symptômes d'une même cause.
En attendant que la QA de Debian (et de RHEL 7) fasse le taf, Ubuntu a tout à gagner.
[^] # Re: NIH ?
Posté par freem . Évalué à 3.
Mouai.
J'aurai plutôt dit qu'il n'y a pas de NIH ici, systemd tout comme upstart apportent des fonctionnalités et une architecture que n'a pas sysVinit.
Le NIH, c'est juste réimplémenter un outil ayant les mêmes fonctionnalités qu'une alternative non-contraignante ( par rapport au nouveau projet, et, oui, cela inclue les problème de licence. ) déjà existante propose.
# Impossible
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Mir est déjà tombé à l'eau (le pacifique sud pour être précis), c'est pas comme s'il/elle n'avait pas l'habitude.
[^] # Re: Impossible
Posté par saltimbanque (site web personnel) . Évalué à 4.
en parlant d'eau : source?
[^] # Re: Impossible
Posté par Tom D . Évalué à 6.
http://fr.wikipedia.org/wiki/Paco_Rabanne#Excentricit.C3.A9s
Tom
[^] # Re: Impossible
Posté par vv222 . Évalué à 2.
http://www.russianspaceweb.com/mir_2001.html
Et ne viens pas nous dire que le développement de Mir n'avait pas démarré en 2001 !
[^] # Re: Impossible
Posté par cosmocat . Évalué à 4.
c'était une blague, hein! eau<->source….
[^] # Re: Impossible
Posté par vv222 . Évalué à 3.
Tu es sûr que ce n'était pas plutôt une vraie question avec un (bon) jeu de mots glissé dedans ?
# Trolldi
Posté par Malizor . Évalué à 7.
Aller, je saute dedans à pieds joins.
Ce n'est pas vraiment comparable.
Les alternatives à Mir son Kwin, Mutter, Weston ou X+Compiz.
Mir est spécifiquement développé pour servir les besoins de l'environnement Unity, au même titre que Kwin est fait pour KDE.
N'oublions pas que Wayland n'est qu'un protocole, ça n'a pas de sens de mettre bêtement en concurrence Mir et Wayland.
[^] # Re: Trolldi
Posté par Strash . Évalué à 10.
Il y a quand même une différence notable. KWin-next, Mutter-next et Weston implémentent le même protocole (Wayland), alors que Mir en implémente un 3ème (différent de X et de Wayland). Ce qui a pour conséquence un effort supplémentaire nécessaires sur les toolkits.
[^] # Re: Trolldi
Posté par Malizor . Évalué à 7.
Certes, mais cet effort non négligeable est tout de même à relativiser.
Les toolkits ne parlent pas directement le langage Wayland ou le langage de Mir, ils utilisent la libwayland-client et la libmir-client, ce qui simplifie le travail.
L'expérience à montré qu'un toolkit déjà porté sur Wayland était assez simple à porter sur Mir.
Par exemple, quand on regarde le code du backend Mir de SDL on se rend compte qu'il est très similaire au backend de Wayland (remplacement de "wayland" par "mir" et quelques adaptations assez mineures).
De même pour Gtk (en l’occurrence, c'est un portage communautaire).
[^] # Re: Trolldi
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
Si n'y a que si peu de différence, pourquoi garder Mir ?
[^] # Re: Trolldi
Posté par Malizor . Évalué à 4.
Tu n'as pas compris.
Il y a de grosses différences entres Mir et les compositeurs Wayland, mais elles sont en grande partie abstraites par leur lib client respectives qui fournissent une interface relativement "haut niveau" (du genre "je veux un buffer pour dessiner").
Les toolkits fournissent une abstraction supplémentaire au dessus de ses lib clients et, en pratique, rajouter le support de Mir n'est pas si compliqué si le support de Wayland a déjà été implémenté (et vice-versa).
# OpenRC
Posté par Spyhawk . Évalué à 10. Dernière modification le 14 février 2014 à 16:18.
Avec Upstart qui ne sera supporté officiellement pas plus aucune distribution majeure (et mourir gentiment de sa belle mort), je pense qu'OpenRC va devenir, de facto, l'init des autres noyaux Debian en plus d'être supporté par Gentoo (l'autre alternative étant sysV que personne ne regrettera).
[^] # Re: OpenRC
Posté par patrick_g (site web personnel) . Évalué à 10.
SysV n'est pas la seule alternative. Il existe (au moins) un autre projet qui semble techniquement plus prometteur qu'OpenRC :
http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html
[^] # Re: OpenRC
Posté par freem . Évalué à 0.
Permets moi de rebondir sur ta réponse, et de demander ce qu'apporte et enlève exactement openRC à 1) sysVinit et 2) systemd.
Du peu que je suppose avoir compris du peu que j'ai lu ( ça fait beaucoup de peu, mais j'ai encore peur de surestimer l'état de mes connaissances… imagines le travail :) ) :
_ openRC conserve la complexité d'écriture de scripts de sysVinit ( j'entends par la que la syntaxe utilisée est celle de sh, ce qui est complexe du point de vue utilisateur, pas de celui du système )
_ mais openRC permets de paralléliser les tâches ( comme pour systemd ) . Chose qui d'ailleurs m'intrigue vu que j'ai lu diverses allégations laissant supposer que sysVinit en serait aussi capable ( on parle de script shell dans les 2 cas si je ne m'abuse, donc ça ne m'a pas semblé irréaliste )
_ tout en n' ( emphase sur la négation ) ayant pas les tonnes de dépendances de systemd à des modules non vitaux pour un OS minimal ( c'est à dire, pas de dépendance à dbus ou logind, par exemple ).
[^] # Re: OpenRC
Posté par barmic . Évalué à 4.
Une unité systemd c'est ça :
Un service OpenRC c'est ça :
C'est pas démesuré comme difficulté.
La parallélisation est indépendante de la façon de décrire le lancement d'un service. On pourrait très bien réécrire tous les scripts d'init en ruby ça n'empêcherait pas sysvinit (svi) de faire du parallélisme. Il lance les scripts (ou binaires d'ailleurs) en parallèle il se fout de savoir ce qu'il y a derrière (ça c'est pour OpenRC et svi).
Ensuite ce qui démarque systemd de ces deux là c'est que le modèle de parallélisme n'est pas le même.
Dans OpenRC et svi tu construit un arbre de dépendances de manière statique. Tu indique pour chaque service de quel services il dépend et l'init va se débrouiller pour lancer le services dont toutes les dépendances sont satisfaites en même temps. svi parle d'un
make stylepour décrire la manière dont il fait l'exécution.Dans systemd, tu peut décrire ce genre de dépendance, mais ce n'est pas forcément nécessaire, il est capable de détecter tout seul les dépendances. Par exemple si un service A dépend d'un autre (B) et en a besoin parce qu'il communique avec lui par une socket. systemd va lancer A puis lorsque A va avoir besoin de B, il va lancer B (c'est le socket activation). L'avantage de cette méthode c'est qu'elle est dynamique (si A n'avait pas eu besoin de B avant 10 minutes, alors B n'aurait pas était lancé trop tôt).
C'est bien une différence de paradigme, ils n'ont pas le même modèle d'exécution.
Si tu veux plus t'informer, je te conseil les dépêches Petit état de l'art des systèmes d'initialisation et Évolutions techniques de systemd.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: OpenRC
Posté par Zenitram (site web personnel) . Évalué à 6.
Pour toi peut-être. Perso j'y vois une grande différence de complexité et un gros problème de structure (l'un est humainement compréhensible, à coup de "=", l'autre est euh… ebegin? eend? pourquoi un besoin de faire une sous-fonction si c'est simple?)
Tu as compté le nombre de lignes? le nombre de caractères? Prend ça et multiplie par 1000 logiciels…
# C'est la vie...
Posté par Maclag . Évalué à 10.
Ça reste un coup dur pour les supporters d'Upstart.
Rappelons que Debian n'avait pas décidé de virer Upstart, mais simplement de préférer systemd comme choix par défaut. J'aurais pensé que certains dévs auraient continuer à maintenir Upstart autant que possible en espérant un revirement dans une prochaine version de Debian.
Avec cette décision de Canonical, le projet est tout simplement mort et enterré.
La bonne nouvelle, c'est que maintenant toutes les "grandes" distros ont décidé de migrer (excepté Slackware, mais ça ne va apparemment pas durer…), et on va enfin avoir un paysage un peu plus uniforme.
Ce sera plus simple pour beaucoup de monde!
[^] # Re: C'est la vie...
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 14 février 2014 à 17:16.
Il faut savoir mourir… Il a rempli son rôle pendant un moment, maintenant il y a mieux (être commun à des distros est un mieux), et c'est tout. Il ne faut pas voir la mort comme quelque chose de négatif, juste une étape normale d'un projet.
Et c'est tout à l'honneur de Canonical de préférer la mise en commun (pour une fois!) des ressources que des développement dupliqués inutiles.
Troll : maintenant, si Debian et Ubuntu pouvaient passer à rpm, ça serait tout aussi super, pas besoin de 2 formats pour exactement la même chose.
[^] # Re: C'est la vie...
Posté par Atem18 (site web personnel) . Évalué à 4.
Réponse au troll : Si Debian et Ubuntu pouvaient devenir CentOS et Red Hat, ce serait tout aussi super, pas besoin de 4 distributions pour exactement la même chose.
[^] # Re: C'est la vie...
Posté par Diagonale de Cantor (site web personnel) . Évalué à 8.
Juste une petite question pour toi qui fait des paquets de ton logiciel pour beaucoup de distribution, ce qui demande de plus de boulot pour passer d’une distrib à une autre c’est le format des paquets rmp/deb ou bien le fait que les bibliothèques sont réparties différemment (nom et numéro version différent, répartie sur un ou plusieurs paquet) entre distribution ?
Dit autrement, si tout le monde passait au vrai format (c’est-à-dire deb) est-ce que cela simplifierait vraiment le boulot ou de toutes façons les différences entre distributions nécessiteraient quand même de bosser ?
[^] # Re: C'est la vie...
Posté par freeze . Évalué à 1.
Justement à mon avis, s'il ne fallait qu'un seul format, RPM serait vachement plus adaptable à ce genre de problèmes. J'ai longtemps préféré les deb (et je préfère toujours les règles de nommage de Debian), mais pour avoir un peu joué à faire des paquets dans mon coin:
Avec les deb, les dépendances sont des paquets donc si tu dépend de java-truc et que sur une autre distrib, le même contenu est appelé truc-java, ben c'est foutu, tu dois modifier/forker ton paquet,, alors qu'en RPM, tu dis juste que tu as besoin de /usr/bin/java est c'est bouclé. Et en plus, pour les bibliothèques rpm passe un coup de ldd pour en déduire ce dont tu as besoin, donc t'as même pas à les lister à la main.
Et je rejoints Zenitram, 2 formats pour faire le même job (parce que fondamentalement, je ne vois pas de raison autre qu'historique à avoir 2 espèces de tar+dépendances, et c'est pénible.
[^] # Re: C'est la vie...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Alors, info exclusive : debhelper, l'outil le plus utilisé pour les règles de constructions de paquets Debian, fait la même chose.
[^] # Re: C'est la vie...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Archive, dépendances et scripts d'installation et de désinstallation. Vous pouvez blâmer RedHat, parce que ce sont eux qui ont fait un nouveau format au lieu d'utiliser celui de Debian qui existait déjà quelques années.
[^] # Re: C'est la vie...
Posté par Renault (site web personnel) . Évalué à 4.
Si tu veux troller, on peut dire que la LSB a tranché en faveur de RPM.
Alors certes, je crois que alien est une astuce suffisante pour être compatible RPM et être valide vis à vis de la LSB, mais bon.
Pour des gens qui veulent faire « The universel Operating System », ne pas écouter les directives d'un comité de normalisation ça craint.
Oui on est vendredi.
[^] # Re: C'est la vie...
Posté par claudex . Évalué à 6.
rpm est disponible dans debian (par contre, il faut faire vraiment gaffe quand on l'utilise).
« 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: C'est la vie...
Posté par Zenitram (site web personnel) . Évalué à -8.
Et surtout pas disponible par défaut pour toute installation, donc inutile dans la vraie vie.
Il y avait bien une tentative d'homogénéiser le bousin (oui : LSB), mais les linuxiens ont horreur des standards avec de gens qui se mettent d'accord sur une façon de communiquer (faut pas déconner, se mettre d'accord, c'est chiant, donc on fait son truc et on espère qu'il éclatera les autres bien fait pour leur gueule. A noter que cette remarque est valable autant pour RPM vs DEB, pour KDE vs Gnome, que pour systemd vs upstart vs OpenRC ;-) ).
[^] # Re: C'est la vie...
Posté par claudex . Évalué à 4.
apache non plus n'est pas disponible par défaut dans toute installation de Debian, le php est donc inutile dans la vraie vie ?
« 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: C'est la vie...
Posté par Zenitram (site web personnel) . Évalué à -5. Dernière modification le 14 février 2014 à 22:32.
On parle de fournir un système de package à installer… Désolé, demander à des gens d'installer y si ils veulent x, et ça à la mano, ça casse un peu la "magie" du "tout automatisé" en pub, je préfère encore un .exe…
Désolé, je pense à la vraie vie, avec des vrais gens qui ne savent pas comment installer sous Debian quand ils reçoivent un RPM. un fichier d'install doit être autonome le plus possible.
[^] # Re: C'est la vie...
Posté par claudex . Évalué à 3.
Je ne suis pas sûr que l'install par défaut de Debian ait de quoi installer un deb sans la ligne de commande. Alors, entre demander aux gens de taper
dpkg -i monprojet.debetapt-get install rpm && rpm -i monprojet.rpm, je ne vois pas ce qu'il y a de différent.« 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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: C'est la vie...
Posté par Zenitram (site web personnel) . Évalué à -7. Dernière modification le 15 février 2014 à 08:28.
C'est rigolo que tu parles de ligne de commande… Je n'en parle jamais. Les utilisateurs doublent cliquent.
Maintenant, dit-moi comment il font avec ce qu'ils connaissent.
Zut alors, les utilisateurs ne sont pas tous des geeks qui connaissent la ligne de commande (loin de la).
Toujours génial de voir que les gens qui répondent n'arrivent pas à se mettre à la place des utilisateurs, et partent de l'idée que tout le monde est au même niveau que lui. Pas étonnant qu'ensuite les utilisateurs préfèrent Windows ou Mac (et ce n'est pas une question de "monopole", non, juste que quand on répond "tape bla bla bla", la personne normale fuit en se disant qu'ils sont fous ces Linuxiens, qu'ils sont encore en 1980).
C'est triste c'est incapacité à se mettre à la place des autres, à essayer de le comprendre, à vouloir que Linux ne soit que pour une élite "tu dois en chier pour mériter d'utiliser Linux". Et après on s'étonne que Linux Desktop c'est 1% des utilisateurs?
[^] # Re: C'est la vie...
Posté par claudex . Évalué à 8.
Parce que c'est la seule solution qui marche sur l'installation de base.
Ils double clique, ça ne marche pas avec un RPM et ça ne marche pas avec un deb (la dernière fois que j'ai testé), donc debian traite bien les deux format de la même manière.
« 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: C'est la vie...
Posté par oinkoink_daotter . Évalué à 6.
Sur une debian, j'ai un doute, mais sur une ubuntu, c'est sur que ça marche. Tu double-cliques sur le deb, ca te demande si tu veux installer et pouf.
[^] # Re: C'est la vie...
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
La dernière fois que j'ai essayé, ça ne gérait pas les dépendances…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: C'est la vie...
Posté par oinkoink_daotter . Évalué à 2.
Je suis persuadé que quand j'avais essayé, ça avait marché (l'installation du virtualbox d'origine oracle avait bien tiré toutes les dépendances à QT). mais je dois concéder que ça doit bien faire un an, donc je peux me tromper.
[^] # Re: C'est la vie...
Posté par ariasuni . Évalué à 2.
Bah ça doit faire plusieurs années que t'as pas essayé alors…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: C'est la vie...
Posté par freem . Évalué à 1.
Si l'action du "double clic sur le deb" est bindée sur dpkg, c'est normal. Mais il existe un outil qui lui gère les dépendances ainsi. Voire même, il ne me semble pas hyper complexe de faire un script ( oui, je t'accorde qu'il devrait être fournit par le DE, mais bon… ) qui fasse:
dpkg -i $1 && aptitude install -y
[^] # Re: C'est la vie...
Posté par anaseto . Évalué à 10.
Ça dépend comme tu dis de ce qu'ils connaissent. Par exemple, le premier et seul OS qu'ont utilisé mes grands parents c'est une Debian (ce n'est pas eux qui l'ont installé bien sûr), et ils sont maintenant capables de lancer un terminal et de taper la commande plus haut si on le leur demande, alors qu'ils seraient incapables de s'y retrouver avec l'interface graphique synaptics pour installer eux-mêmes des paquets. Et pour ce qui est du double clic, ils ont eu beaucoup de difficultés avec : en fait, ils ont beaucoup plus vite compris le clavier (peut-être parce que ça ressemble aux machines à écrire) que la souris qui était un concept nouveau pour eux.
Bref, le problème ce n'est pas la ligne de commande, ni même le double clic, mais qu'utiliser un OS quelconque demande toujours un effort d'apprentissage quand on part de zéro, et une fois qu'on maîtrise un sous-ensemble de fonctionnalités qui nous suffit on est vite tenté (et c'est compréhensible) de dire que le reste est plus compliqué, et ça ne concerne pas que les non-geeks : il suffit de voir le nombre de personnes qui n'ont pas très envie d'apprendre systemd (sentiment que je ressens un peu moi même à vrai dire), ou qui râlent à chaque gros changement d'un logiciel quelconque.
[^] # Re: C'est la vie...
Posté par Albert_ . Évalué à 4.
On se demande qui il y avait dans le commite…
[^] # Re: C'est la vie...
Posté par freem . Évalué à 3.
Vendredi ou pas, je m'en moque. De toute façon, je passe aléatoirement donc bon…
Cependant, j'ai lu à plusieurs reprise ce point précis: deb à été créé plusieurs années avant rpm, mais rpm à été """sacré""" format universel des package linux.
Mais je n'ai jamais vu la moindre raison technique ( oui, je sais, on est lundi, pas trolldi… ) expliquant cette raison.
Donc, ma question est simple: y a t-il une seule raison objective ayant permis d'élire rpm comme format universel?
Sachant que, bien sûr, deb à ses défauts, par exemple il est impossible d'installer un deb en userspace avec les outils standard. Mais si rpm à le même problème, alors… bref.
Une raison technique derrière ce choix, ou c'est encore une question de blé?
[^] # Re: C'est la vie...
Posté par Maclag . Évalué à 9.
Supposons que nous ayons 2 options, toutes les deux pertinentes, pour un tronc commun.
Supposons que ces 2 options proviennent respectivement d'une part d'une entité commerciale, d'autre part d'une entité à but non lucratif.
Indépendamment du débat, on peut affirmer que retenir l'option proposée par les entités commerciales sera automatiquement qualifié, par un ou plusieurs commentateurs, de "décision prise à coups de pognon".
Ou alors, tu devrais répondre à ça: "y-a-t-il une seule raison objective qui aurait dû faire élire deb comme format universel?"
[^] # Re: C'est la vie...
Posté par Spyhawk . Évalué à 10.
C'est surtout pas exactement vrai, relève d'une légère déformation de la vérité et mérite un petit éclaircissement. Le .deb, dans sa forme primitive, apparaît en 1994 pour s'établir dans sa forme actuelle dès 1995 (la première Debian est délivrée l'année suivante). Le RPM quand à lui, apparaît en 1997 mais est découle directement des expériences acquises avec le système RPP (le RPM primitif) qui était en usage chez Red Hat déjà avant la sortie de RH 2.0 en 1995, ainsi que de PMS de la distribution Bogus délivrée en 1994.
Alors oui, si on regarde les formats dans leur format actuels (minus les évolutions mineures), .deb est apparut en 1995 et RPM en 1997. Mais en regardant de plus près, on peut juste dire que ce sont deux formats incomplets qui ont évolué en parallèle dès 1994 (et hop les debianneux peuvent ravaler leur légende urbaine :P)
Ben écoute, hein, .rpm et .deb sont peu être similaire à l'usage, mais t'a qu'à t'essayer au packaging pour ces 2 formats et après tu tires tes propres conclusions sur lequel des deux a le plus d'argument pour avoir la vocation d'être utilisé partout. Pour moi c'est très clair, les types de la LSB ont fait le meilleur choix.
[^] # Re: C'est la vie...
Posté par barmic . Évalué à 0.
C'est gentil, mais il y a à mon avis un paquets de cas d'usage différent et ce n'est pas en créant un ou 2 paquet qu'on peut juger. De plus un paquet, c'est bien mais il faut voir comment se passe la mise à jour de celui-ci et l'outillage qu'il y a coté utilisateur pour gérer les paquets (comme presto ajouté à yum).
Je dis ça, je ne sais pas le quel est le mieux (et je m'en fou), c'est juste qu'il ne me semble pas aussi facile que tu le dis de juger ces 2 formats. Si tu pense que la facilité de créer un paquet vite fait est la seule chose intéressante, je pense que tu devrais t'inscrire à la ML de la LSB pour leur dire d'aller voir du coté des paquets Arch qui mettent une claque autant aux .deb qu'aux .rpm du point de vu de la facilité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C'est la vie...
Posté par Spyhawk . Évalué à 4. Dernière modification le 18 février 2014 à 15:27.
J'en ai vu assez pour me rendre compte que créer un rpm pour des paquets relativement simples est bien plus compliqué dans le cas de .deb, alors j'ose pas imaginer pour les cas plus complexes. Aussi, j'ai bien spécifié "Pour moi", ce qui veut dire que c'est un avis personnel, moi qui fait du packaging une fois tous les 6 mois.
Je parle spécifiquement des formats .deb et .rpm, qui ont été créé spécifiquement pour la gestion des dépendances (et pas leur résolution). Les différents Yum, Zypper, URPMI, Apt-get et autre aptitude n'ont rien à voir ici, c'est un tout autre sujet.
Remet les choses dans le contexte avant de sauter sur tes grand chevaux: la LSB prédate les PKGBUILDs d'Arch Linux, ensuite y'a aussi une question de popularité de format à l'époque (et je suis le premier à penser que PKGBUILD est globalement supérieur à RPM/Deb).
[^] # Re: C'est la vie...
Posté par barmic . Évalué à -4.
Merci c'était juste ce que le monsieur (ou la madame ) te demandait plus haut (je présume qu'il espérait même que tu argumente un peu mais vu comme tu à l'air d'avoir les crocs, on va plutôt te classer dans la section troll et ignorer ce que tu as à dire).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C'est la vie...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Alors, ça peut se faire avec le format de paquet Debian. C'est du niveau gourou, mais ça peut se faire : il faut pour ça générer le fichier
debian/controlplutôt que de le fournir directement, en utilisantapt-file searchpour trouver les paquets fournissant tel fichier. Ça implique de build-dépendre de apt-file, c'est tordu, pas franchement élégant, mais ça doit pouvoir se faire.[^] # Re: C'est la vie...
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ah? Dans mes rpms je dois mettre une ligne du genre java > 1-1.7.0…
Avec debian, c'est effectivement une dépendance vers java7-runtime et je dois faire une bidouille pour trouver le bon chemin, car dans le java dans le PATH est en général la version 6 (obsolète).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: C'est la vie...
Posté par Spyhawk . Évalué à 10.
Utiliser une ferme de compilation comme l'OBS réduit considérablement les soucis de chemin, nom et version de lib. Le souci à mon avis, c'est plutôt d'écrire le fichier .spec (ou l'équivalent pour .deb) initial. Et là, pour m'être essayé au packaging pour différentes distributions, je peux sans appel dire que RPMs n'est pas optimal tant il y a de petites différences entre les RPM Fedora et openSUSE, mais ça reste largement moins ennuyant et moins compliqué que de créer des .deb dont la création des divers fichiers (control/rules/dsc/…, sérieusement?) me fait penser à un parcours du combattant, en pleine jungle et par 20 mètres de fond.
Mais de toute façon, on sait tous que le vrai format n'est ni .deb ni RPM, mais tar.xz :P
[^] # Re: C'est la vie...
Posté par Zenitram (site web personnel) . Évalué à 3.
Eh c'était pour troller! Pas pour des questions sérieuses.
Imagine que tu code 1000 lignes dans un language x.
Dans un cas, tu rajoutes un "if ditro titi", dans l'autre tu fais 1000 autres lignes dans un language différent. Tu préféres quoi?
Ben voila, c'est pareil avec RPM vs DEB:
- Entre Fedora et Mandriva (par exemple), j'ai 2-3 "if" spécifiques qui se baladent.
- Entre Fedora et Debian, j'ai deux fichiers complètement différents.
[^] # Re: C'est la vie...
Posté par cosmocat . Évalué à 5.
Espérons plutôt qu'ils s'aperçoivent qu'avoir un socle commun, ça facilite la vie à (presque) tous et que les développeurs des 2 systèmes de paquets rpm et deb (et les autres) se mettent à travailler ensemble pour nous pondre un nouveau standard commun à toutes les distribs…
[^] # Re: C'est la vie...
Posté par navaati . Évalué à 4.
On se marre bien avec ce xkcd, mais au final c'est exactement ce qu'a réussi à faire systemd concernant le format des scripts d'init, la manière de booter, le format de plein de fichiers de conf (hostname, locale, toussa), et j'en passe. Et avec ce passage de debian puis ubuntu, l'objectif est presque complètement atteint.
[^] # Re: C'est la vie...
Posté par claudex . Évalué à 4.
Pour le hostname, ils ont repris celui de Debian.
« 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: C'est la vie...
Posté par navaati . Évalué à 2.
C'est vrai. Mais ils ont réussi à le généraliser. (enfin ça colle moins au xkcd c'est sûr)
[^] # Re: C'est la vie...
Posté par tyoup . Évalué à 2.
On se marre bien la première fois… la deuxième on sait pertinemment qu'il y a maintenant 15 standards, du coup, ça ne marche plus… Evidemment, l'auteur ne pouvait pas deviner au moment où il l'a dessiné. Il devrait le refaire en faisant revenir le mec dans le passé avec une machine à voyager dans le temps. Qu'en pensez-vous ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: C'est la vie...
Posté par xcomcmdr . Évalué à 5.
Tu oublies que tous ces Unix étaient propriétaires et proposaient des standards propriétaires, ce qui étaient un frein majeur pour pouvoir migrer d'un Unix à l'autre.
Linux n'a pas ce frein.
De plus, l'Unix Wars était un guerre commerciale féroce (souvent via des procès, de ce que j'en comprends).
Certes, RedHat, Canonical, SUSE, et compagnie sont des concurrents. Mais ce sont surtout des entreprises qui coopèrent (standards freedesktop, Upstart utilisé dans Fedora, Canonical qui passe à systemd, …), et qui n'opèrent parfois même pas sur le même segment du marché (Canonical s'oriente vers le desktop, RedHat pas vraiment).
Bref, si on veut regarder une guerre avec des avocats et des procès, il y a bien plus d'actions du côté des patent trolls (SCO vs. IBM, par exemple). ;-)
C'était déjà incompatible avant. Même sans changer de kernel. Essaie d'utiliser un script rc pour Debian sur Fedora pour rigoler.
Euh, juste la gestion de l'alimentation dans de GNOME 3.8, et pour de bonnes raisons : ConsoleKit n'évolue plus depuis 2 ans, et est trop bogué pour être utilisable.
GNOME peut toujours être compilé et exécuté sans systemd, au pire quelques fonctionnalités ne seront pas disponibles.
Les dits services que logind fournit peuvent être réimplémentés. L'API est stable et documentée, le code est libre et hébérgé sur fd.o.
Je préfère un systemd qui a reçu un audit de sécurité, qui est maintenu par une équipe réactive, qu'un système d'init inconnu au bataillon.
La diversité c'est bien. Exécuter tel ou tel programme parce qu'il est différent sans avoir audité la sécurité du programme et de son code, savoir s'il est maintenu (ou maintenable), etc… c'est encore pire que pas de diversité.
C'est vite dit ça. Déjà, il y a toujours beaucoup d'OS libres qui n'utilisent pas Systemd.
La 14.04 de Ubuntu, une LTS soutenue pour les 5 ans à venir, utilise toujours Upstart.
La 12.04 de Ubuntu, soutenue jusqu'en avril 2017 aussi d'ailleurs.
Gentoo utilise toujours OpenRC.
Slackware utilise toujours son propre système d'init.
Les BSD se fichent royalement de systemd.
AROS aussi s'en fiche.
(j'en oublie peut-être. Tiens, ils utilisent quoi chez Mageia ? Et chez OpenIndiana ?).
Il existe aussi encore beaucoup d'autres systèmes d'init (BootScripts, runit, initng, …)
Du côté des OS proprios, lequel a adopté systemd ? ;-)
Voyons, est-ce que les mainteneurs de Debian, Ubuntu, Arch Linux, Fedora, et tant d'autres distributions sont contrôlés par RedHat ?
Ça me semble quand même hautement improbable.
Les trolls s'en remettront.
Oui, comme ConsoleKit, HAL, GTK1, SysV (d'où la naissance, au moins, de upstart, openrc, et systemd), Xorg, …
Mais on ne peut pas apprendre sans erreurs.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est la vie...
Posté par wismerhill . Évalué à 7.
Systemd exclusivement depuis la 3, pour la 2 on pouvait choisir entre systemd (choix par défaut à l'installation) et init sysV.
[^] # Re: C'est la vie...
Posté par Misc (site web personnel) . Évalué à 10.
et c'est pour ça qu'on utilise tous le même démon ssh, parce que la diversité est un atout majeur.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: C'est la vie...
Posté par Zenitram (site web personnel) . Évalué à 0.
Ok, tu évites la problématique en disant "souvent", mais alos maintenant dit-nous pourquoi tu ne trouves pas horrible le fait que l'élément le plus sensible (l'accès de l'extérieur) soit un seul logiciel partout et que ça te turluppine qu'un élément interne à la machine soit un seul logiciel partout.
Parce que la, désolé, mais je ne comprend pas du tout la logique de l'argumentation, l'argumentation dirait plutôt l'inverse (que ce qui est le plus sensible, donc l'accès exterieur, ne devrait pas reposer sur un seul logiciel, et c'est pourtant l'état actuel depuis des années, pire OpenSSH est autant sur Linux que BSD alors que systemd est que Linux).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 15 février 2014 à 12:35.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: C'est la vie...
Posté par ariasuni . Évalué à 6.
On dit «pertinent».
Écrit en Bépo selon l’orthographe de 1990
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8. Dernière modification le 16 février 2014 à 03:05.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: C'est la vie...
Posté par ariasuni . Évalué à 3.
Ah d'accord. Décidément, les variations locales du français ne cesseront de me surprendre…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: C'est la vie...
Posté par freem . Évalué à 1.
Le français…
A notre échelle simplement nationale, on discerne déjà pas mal de dialectes… que l'on peut classer entre 2 familles linguistiques ( je suis même pas sûr que le terme de famille sois bon en plus ): langue d'oil et langue d'oc.
Chacune de ces famille état elle-même subdivisée en de multiples variantes dont certaines ( potentiellement classées à l'unesco seloin une source dont je n'arrive pas à retrouver la provenance. Au moins vous êtes prévenus. La recherche que j'avais faite à l'époque portait sur le cauchois, subdivision de la langue normande. )
Bref, tout ça pour dire, tu ne devrais pas être surpris par le fait que notre langue commune soit si riche. En même temps, je trouve ça intéressant qu'on ne soit pas capable de nous comprendre les uns les autres sans efforts.
Ca nous permets, voire nous force, de réfléchir à ce que l'on dit, et parfois, on y gagne en sagesse sans même le vouloir en nous faisant reformuler des idées qui semblaient évidentes mais étaient en fait stupides.
Oui, j'avoue, je ne comprend pas à la 1ère écoute un belge qui me parle, ni un marseillais.
Par contre, ça m'aide a comprendre les choses sous un autre angle: ils utilisent des mots différents, qui me forcent à m'interroger sur le sens des mots que, moi, j'utilise ( il ne faut pas oublier le contexte ) . Et au travers de ces interrogations, j'apprends à penser par moi-même. Grâce aux autres, tout en restant maître de mes opinions.
[^] # Re: C'est la vie...
Posté par ariasuni . Évalué à 2.
Bah. J'ai découvert tellement de trucs sur le français ces deux dernières années… Je pensais pas que le français pouvait autant diverger par rapport à celui de Paris. Je remercie Internet pour cela.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: C'est la vie...
Posté par oinkoink_daotter . Évalué à 2.
Tout s'explique ! Ce sont des skyblog ou les forums doctissimo et ça n'a rien à voir avec une/des évolution(s) du français. (et ça fait saigner les nieux) /o\
[^] # Re: C'est la vie...
Posté par freem . Évalué à 1.
J'ai connu une personne sur travian, qui était incapable d'aligner plus de 3 mots sans faire de faute.
2 ans plus tard, je lui ai parlé à nouveau ( via msn de mémoire ) et son français était presque impeccable. Je me suis pas privé de lui faire la remarque ( vu que je l'avais bassiné auparavant pour qu'il se corrige ) et il m'a répondu qu'a force de se faire modérer sur le forum officiel, et corriger par les autres utilisateurs, c'était venu.
Conclusion: internet peut aider à corriger l'illettrisme ( non, pas d'autre mots pour qualifier son niveau au moment ou je l'ai connu ).
PS: skyblog et le forum dont tu parles, ne sont pas internet. Ils ne sont qu'une petite partie du web, lui-même petite partie d'internet.
[^] # Re: C'est la vie...
Posté par Zenitram (site web personnel) . Évalué à -2.
Ici, il n'y a pas de guerre : les xBSD on s'en fout un peu (quasi personne ne les utilisent), et Linux est libre ce qui rend ta comparaison caduque (tout le monde peut forker)
Clair que pour accéder aux machines à distance, tu va éviter d'utiliser le même logiciel que moi (OpenSSH). Ho, attend…
sytemd est libre. Ca permet de forker, de se baser dessus et proposer mieux. La, tu critiques Linux aussi, pas de concurrent (non, qu'on ne me fasse pas rire avec les xBSD) du coup pas de progression? Au contraire! Ca permet de ne pas perde de temps sur x OS.
Et dans quelques années ça sera oublié.
Et ils sont idiots alors : ils ont toujours le choix. Mais à eux de e bouger le cul pour maintenir.
Ah la démocratie… Clair que quand ton poulain n'est pas pris, c'est toujours injuste, grand classique. On ne peut pas faire grand chose avec ces personnes, puisque tout ce qu'on pourra faire pour leur faire plaisir est de prendre leur poulain.
La, vu le nombre de personne haut niveau qui sont sur systemd, même ne connaissant pas complètement la technique, je n'ai que peu de doutes…
[^] # Devenir d'Upstart
Posté par Sylvain Blandel . Évalué à 1.
Non, ça signifie qu'Ubuntu n'utilisera plus Upstart. Et, assurément, que Canonical ne rémunérera plus personne pour développer ce logiciel.
Y aura-t-il du monde pour reprendre le développement d'Upstart ? On verra. J'imagine plutôt les opposants à systemd
bougonner pendant quelques trimestrestravailler dur pour maintenir le traditionnel SysVinit.[^] # Re: Devenir d'Upstart
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 14 février 2014 à 22:21.
Moi je ne les imagine pas du tout travailler dur la dessus, pas crédible, vu le peu de compétences (sur comment faire ou analyser un système d'init, je précise, je ne parle pas de leur compétence en général, je préfère préciser on ne sait jamais l'incmpréhension…) qu'ont les râleurs quand ils critiquent systemd/journald/logind. Il vont vraiment juste bougonner pendant quelques trimestres et changer leur "cat" par "journalctl" (au pire il feront un alias ave un autre nom pour ne pas voir le nom de l'horrible chose) et on n'en parlera plus.
[^] # Re: Devenir d'Upstart
Posté par Philippe F (site web personnel) . Évalué à 8.
Ah ah ah.
A l'époque des
trollsdicussions sur la licence de Qt, des gens avaient envisagés de réécrire Qt en GPL au lieu de QPL. Si je me souviens bien, ils avaient même pas fais l'ensemble du tutorial Qt….La motivation pour maintenir un système qui n'a pas de futur me semble difficile à trouver…
[^] # Re: C'est la vie...
Posté par ariasuni . Évalué à 4.
J’avais oublié que Gentoo était une petite distribution.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: C'est la vie...
Posté par Spyhawk . Évalué à 4.
Gentoo supporte systemd officiellement (c'est juste pas l'init par défaut).
[^] # Re: C'est la vie...
Posté par ariasuni . Évalué à 2.
Je sais, mais comme ça n’est pas le système d’initialisation par défaut, je ne pense pas qu’on puisse dire qu’ils ont migré vers systemd.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: C'est la vie...
Posté par xcomcmdr . Évalué à 10.
Pas vraiment. Upstart est une des inspirations de systemd (notamment pour le boot en parallèle des services).
Et puis, à l'époque où Upstart état nouveau, on avait enfin quelque chose qui osait aller de l'avant, comme systemd aujourd'hui.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est la vie...
Posté par Misc (site web personnel) . Évalué à 4.
Upstart étant lui même inspiré de Launchd. Et launchd vient sans doute des idées de SMF.
Quand à aller de l'avant, PLD et Gentoo avait déjà repris l'idée de simplification des scripts d'init il y a longtemps.
[^] # Re: C'est la vie...
Posté par feth . Évalué à 8.
L'auteur initial d'Upstart a su attendre le verdict pour donner son avis : https://plus.google.com/+ScottJamesRemnant/posts/4eHMc2tvp7C -il préfère systemd.
Et aussi peut-être le fait que, finalement, Lennart Poettering, comme Linus Torvalds, a son franc parler sans être associal, et sait fédérer une équipe autour de son projet.
[^] # Re: C'est la vie...
Posté par Zenitram (site web personnel) . Évalué à 0.
Tu extrais ce qui te plait sur le CLA, car bon il y a ça aussi dans les commentaires :
(à noter que j'ai sélectionné pour contrebalancer le commentaire auquel je répond, il y a un autre commentaire contre le CLA de Canonical qui est pertinet)
[^] # Re: C'est la vie...
Posté par feth . Évalué à 6.
Oui oui, on parle spécifiquement du CLA de Canonical.
Les gens n'ont pas confiance dans Canonical (sans doute à force de promesses non tenues ou de tentatives de contrôle de l'écosystème -il faut citer launchpad à nouveau, mais il y en a d'autres ?).
# Intéressant de mesurer les forces en présence
Posté par antistress (site web personnel) . Évalué à 5. Dernière modification le 14 février 2014 à 18:15.
Quitte à être un peu réducteur, au final on a Red Hat vs Canonical, avec Debian qui fait pencher la balance. C-à-d que dans la configuration présente des forces en présence, Debian a un pouvoir phénoménal, celui de faire les
roischoix.[^] # Re: Intéressant de mesurer les forces en présence
Posté par Diagonale de Cantor (site web personnel) . Évalué à 10.
En fait Systemd c’est une conspiration de Debian pour contrer l’hégémonie d’Ubuntu ; pour cela ils ont infiltrer Red Hat ! Quand on attaque Debian, Debian contre attaque…
[^] # Re: Intéressant de mesurer les forces en présence
Posté par Sylvain Blandel . Évalué à 1.
Quelque ait été le choix de Debian, le développement de systemd aurait continué.
[^] # Re: Intéressant de mesurer les forces en présence
Posté par claudex . Évalué à 10.
Ça on n'en ai sait rien. Si Debian avait choisi Upstart ou OpenRC, peut-être que Lennart aurait dit : « Si c'est comme ça, je me tire sous Minix », Red Hat aurait annoncé la fin de Fedora, préférant se baser sur Debian sid et Opensuse aurait décidé de se baser sur Gentoo, trouvant ça le choix le plus facile pour intégrer OpenRC.
« 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: Intéressant de mesurer les forces en présence
Posté par Antoine . Évalué à 9.
Et Richard Stallman aurait annoncé qu'il a convaincu Apple de migrer les iPhone sous GNU Hurd.
[^] # Re: Intéressant de mesurer les forces en présence
Posté par Maclag . Évalué à 10.
Hmm?
Ubuntu est basée sur Debian, et ce que quelles que soient les décisions de RedHat, donc oui, forcément, Debian a énormément d'influence sur le développement d'Ubuntu… et de LinuxMint, et bien d'autres!
[^] # Re: Intéressant de mesurer les forces en présence
Posté par karteum59 . Évalué à 2.
Bon après, Debian a choisi systemd comme init par défaut. ça ne veut pas dire que c'est le seul. Canonical aurait pu choisir de continuer à supporter un autre init.
N.B. sur une LUbuntu 13.10 récemment installée au bureau, j'ai observé que le réglage "ne pas mettre en veille lors de la fermeture de l'écran" était ignoré par la machine, et qu'il fallait que j'aille trifouiller
/etc/systemd/logind.confpour paramétrer "HandleLidSwitch=ignore" pour que ça (re)marche. Il s'agit d'une installation LUbuntu 13.10 de base sur un PC Dell D410 => qqun sait me dire ce que systemd/logind fait ici alors que je n'ai rien demandé ? (ps axrenvoiesystemd-logindetsystemd-udevd)<troll>Personnellement j'aimais bien l'init de Pardus</troll>[^] # Re: Intéressant de mesurer les forces en présence
Posté par Tonton Benoit . Évalué à 4.
Canonical maintenait un fork de systemd-logind car :
1: Utilisé par toutes le versions récentes des composants Gnome qu'Ubuntu utilise.
2: logind remplace ConsoleKit qui est une merde qui n'a jamais été stable, fonctionnelle ni même finie (la gestion des multiseats locaux jamais implémenté)
Quand à systemd-udevd, c'est ce bon vieux udev qui remplace devfs depuis bientôt une bonne dizaine d'années.
[^] # Re: Intéressant de mesurer les forces en présence
Posté par karteum59 . Évalué à 2. Dernière modification le 16 février 2014 à 11:52.
Ah merci, je ne savais pas…
Mais du coup, il y a un bug d'intégration avec LXDE puisque le réglage "ne pas lancer l'hibernation quand on ferme l'écran" ne fonctionne pas et oblige à aller changer le fichier de conf.
Oui évidemment ! (pour le coup ce n'était pas là la question. J'étais juste surpris que Canonical se base sur la version mergée avec systemd)
[^] # Re: Intéressant de mesurer les forces en présence
Posté par feth . Évalué à 2.
Bah on pourrait aussi se dire que l'un des principaux intérêts d'upstart pour canonical était d'avoir une chance de mener la danse. Mais Pour Shuttleworth ça ne sert peut-être plus à rien d'avoir un upstart sous CLA si tu n'as personne qui dépend étroitement de ton logiciel et donc de ton bon vouloir.
# bah finalement, plus d'yeux et de mains pour Systemd
Posté par Le Gab . Évalué à 3.
C'est bien, non?
Il devrait être possible de régler plus rapidement les problèmes de race condition qui te jette du système et t'en exclu à tout jamais.
J'espère que Lennart ne gagnera pas la bataille du fourre-tout dans /bin.
[^] # Re: bah finalement, plus d'yeux et de mains pour Systemd
Posté par zul (site web personnel) . Évalué à 2.
Scélérat, tu ose pointer le fait que peut-être que systemd est vachement complexe et qu'il y'a peut-être même des bugs :). C'est interdit ici, c'est un délit de lèse-majesté vis à vis de Seigneur Lénart :) Amen!
[^] # Re: bah finalement, plus d'yeux et de mains pour Systemd
Posté par navaati . Évalué à 1.
Hahaha wep, il est beau celui là, bien crasseux.
Par contre pour l'histoire de /bin, en fait c'est pas un fourre-tout dans /bin mais plutôt dans /usr/bin, /bin devenant un symlink. Et c'est très bien : /bin, /lib et autre trucs à la racine « pour permettre un boot même quand seul / est monté » n'ont plus aucun sens.
Déterminer statiquement (à l'échelle de la distro) quels binaires/bibliothèques/data sont nécessaires au boot est devenu un problème sans solution. L'initrd, généré dynamiquement, assume maintenant parfaitement ce rôle.
Et qu'on ne me fasse pas dire ce que je n'ai pas dit : il reste tout à fait possible de booter sans initrd, si on a /usr sur la même partition que /.
# Wow
Posté par MTux . Évalué à 10.
Décidément tout le monde lui est passé dessus. Sacré systemd….
# Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Politique
Posté par Misc (site web personnel) . Évalué à 7.
Alors faut bien voir que d'abord, ça va pas arriver dans la stable avant 8 mois ( vu que faut d'abord sortir la 14.04, ensuite la suivante ). Ensuite, c'est en partant du principe que dans 8 mois, c'est fini, et au vue des cadences d'Ubuntu et du fait qu'il faut quand même d'une part coder ce qui manque ( genre le support de AppArmor au même niveau que dans upstart qui peut faire ça job par job ), et migrer tout les jobs customs, etc.
Faut voir par exemple que Unity utilise upstart comme gestionnaire de session utilisateur aussi.
Et je pense que Ubuntu va attendre que Debian fasse le taf, ce qui implique d'attendre la release de la stable ou au moins le gel. Et d'ici la, il va y avoir plein de changements dans le kernel et dans systemd, comme kdbus et les cgroups. KDus qui semble aussi ne pas aller dans le sens des demandes de Canonical pour la gestion fine des ACLs via apparmor, donc ça fait du taf en plus aussi.
[^] # Re: Politique
Posté par zebra3 . Évalué à 5.
Que fait de particulier upstart ? J'ai fait quelques profils customs AppArmor sous Debian et ça marche bien avec systemd, il suffit d'appeler aa-exec à la ligne ExecStart. Upstart va-t-il plus loin ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Politique
Posté par Misc (site web personnel) . Évalué à 5.
Upstart propose une option de configuration (stanza en jargon Upstart) qui permet pour un job de charger un profile et de démarrer directement le job avec ce profile :
https://code.launchpad.net/~mdeslaur/upstart/apparmor-support/%2Bmerge/164169
Par exemple, je donne le chemin direct vers le profile, upstart le charge, l'utilise et lance le processus. C'est une ligne à rajouter.
Commencer à devoir utiliser aa-exec, ça deviens vite chiant. Déja, si ton job upstart contient plusieurs lignes de commande, tu es obligé de faire un wrapper ( et donc il n'est plus "self contained" ), et tu dois charger à la main, en n'ayant pas le diagnostique de pourquoi ça ne marche pas, etc, etc.
Pareil avec systemd, qui propose dans la version git "SeLinuxcontext" pour démarrer le process dans un domaine particulier. En faisant ça dans systemd directement, tu as la capacité d'interroger systemd par dbus pour avoir l'info, tu as un retour plus haut niveau via journalctl ( ie, un vrai code d'erreur ), tu as une gestion intégré via les templates, etc, etc.
Pour le moment, tu peux pas dire "ce job est dans ce profile apparmor", mais un patch a été envoyé ( et il attends une version 3.0 avec divers modifs ).
[^] # Re: Politique
Posté par Albert_ . Évalué à 3.
\o/ Je sens que en plus de la normalisation "systemd" on va avoir la normalisation "selinux". Genial…
[^] # Re: Politique
Posté par Misc (site web personnel) . Évalué à 8.
En même temps, faut pas se voiler la face. AppArmor a failli disparaitre sans Canonical qui voulait avoir une alternative à SELinux, car Novell avait finalement décidé de lacher l'affaire. At AppArmor est en retard niveau intégration partout ailleurs, car Canonical n'a pas vraiment les ressources.
Pr exemple, dbus a d'abord supporté SELinux, puis AppArmor. Postgresql supporte la séparation par SELinux, pas par AppArmor. Des distros comme Gentoo, Debian ou Fedora ont supportés SELinux bien en premier, puis vaguement Apparmor. Les seuls à avoir AppArmor de base sont celles ou le sponsor a décidé d'en haut de pousser la techno, ie Ubuntu et Opensuse. IE, la communauté poussant AppArmor est pas très grande.
Et je peux détailler en long, en large et en travers pourquoi à mon sens AppArmor est plus primitif et moins extensible que SELinux.
Par exemple, AppArmor utilise des chemins pour les permissions et les accès la ou SELinux rajoute une couche d'indirection, ce qui le rends impropre a un usage comme "ce document est noté top secret, personne doit le lire". Apparmor ne supporte pas trop le concept de MLS ( mais sur la TODO list http://wiki.apparmor.net/index.php/AppArmorMLS ). Et c'est pas un exemple purement théorique non utilisé en pratique, car tout openshift dépend de ça pour l'isolation des gens.
Autre example, changer le repertoire racine d'un serveur web. Sous SELinux, tu changes le label du répertoire via semanage fcontext, et voila. Sous AppArmor avec le système de profile, tu doit modifier tout les profiles pour copier les permissions. Mais donc du coup, pour palier à ce cas, ils ont rajouté le concept d'alias. Donc tu va dire que /var/www/ est un alias vers /home/www et donc que les accès de l'un correspondent aux accès de l'autre. Donc la ou une solution élégante est en place, on rajoute un truc de plus.
Je pourrais dire comment les politiques de sécurité SELinux sont configurable via des booleans, etc, etc. Et comment la config de apparmor, c'est juste des variables prédéfinis. En théorie, on peut faire la même chose avec AppArmor, sauf qu'en pratique, c'est quasiment du tout ou rien.
Je pourrait rajouter comment le fait de rajouter un nouveau type d'objet ( genre les sockets réseau ) implique de rajouter une option au parser, des nouveaux types d'objet dans la lib et de tout recompiler, la ou SELinux fait ça de façon indépendante du code dans le kernel et le reste, tout dans sa policy ( et avec du code pour l'arbitrage dans le programme qui va se servir de la policy, bien sur ). Comprendre comment faire ça, c'est globalement un workshop de 2h pour quelqu'un qui sait écrire une policy.
Alors ouais, SELinux semble s'avancer pour devenir quasiment un choix "normaliser" ( mais ça reste plus que relatif, car le défaut pour la majorité des distros, ça va surtout être "rien" ). Mais c'est surtout que ç'est plus extensible, ce qui permet de faire plus de choses, ce qui fait qu'il y a un marché pour ça, et donc des investissements.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.