Le problème à mon sens étant que ça demanderait de faire spécifiquement appel à du boilerplate dans chaque script d'init pour en profiter, alors qu'avec systemd c'est garanti par le système.
Je pense que ça demanderait une mise à jour d'init-functions avec probablement une mise à jour de l'API qui va avec. Ça ne me paraît pas plus moche que ce qu'il y aujourd'hui.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
C'est pas parce que les distributions utilisent des scripts qui ne se servent pas des cgroups que c'est impossible. Tu peut le faire avec cgexec par exemple et donc avec sysv ou rc.d sans problème notable.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Non. Les API Windows changent aussi souvent, depuis bien plus longtemps que Linux n'existe. Et pourtant, Windows est toujours largement dominant sur le desktop.
Leur qualité c'est de gérer proprement la compatibilité avec l'existant. Ça ça a de la valeur pour le bureau.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Parce qu'ayant gouté à un OS (en fait deux : Windows et Mac OS X) qui bootent très rapidement, en tant qu'utilisateur desktop il est hors de question d'imaginer utiliser un OS qui prend son temp à booter, on n'est plus au 20è siècle.
Tu ne peux pas nier qu'il y a un vrai problème d'intégration des nouveautés. L'évolution pourrait très bien prendre en compte l'existant. C'est sur ce genre de petite chose que MacOS fait son beurre.
Les bugs sont un problème, mais ça ne cautionne pas de geler un OS, ce sont les bugs qu'il faut chasser.
Pff sérieusement tu crois que personne le vois venir ton homme de paille. Il n'y a pas d'autres choix possible ?
De la mème manière, si il faut attendre x (combien pour que ça te va? OK, le W3C dit 2 par exemple) implémentations, déjà que Linux est à la ramasse sur le desktop (Windows et Mac OS X bootent rapidement depuis quelques années maintenant), ça va être encore pire…
L'intérêt de systemd n'est pas la vitesse de boot. Si on voulais juste faire quelque chose de rapide, on peut le faire de pleins de façons. Le problème est plus dans les dépendances entre le bureau et le système d'init. L'intérêt n'est pas notable (en tout cas pour moi).
mais ça n'empêche pas de donner son avis.
Et les autres non plus ;-).
Si je ne l'avais pas dis tu aurais était le premier à me répondre que je n'ai qu'à implémenter l'API en question et que si ce n'est pas fait c'est que tout le monde s'en fout (ça fait partie des tes arguments récurrent que tu sort à loisir).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Posté par barmic .
En réponse au journal Debian à l'heure du choix.
Évalué à 8.
Dernière modification le 01 février 2014 à 00:49.
Répétons, GNOME n'a pas besoin de systemd mais d'une implémentation de l'API de DBus que notamment systemd propose mais que tout autre programme pourrait fournir.
C'est un peu fumeux ce que tu dis. Il ne s'agit pas de l'« API DBus », mais d'une API faite sur dbus et qui est proposée par systemd. Si tu veux parler en terme de couche il est bon d'être un peu plus précis et oui c'est une API c'est un ensemble de fonctions, donc ça peut se réimplémenter (comme Qt même si ça choque certains de le dire).
Personnellement tu te fourvoie, je n'ai rien contre systemd (je l'utilise sur ma Debian stable), j'ai l'impression qu'il écrase n'importe quel autre init linux, je vois juste d'un mauvais œil cette API. Oui elle est réimplémentable, oui elle l'a déjà était pour ubuntu. Mais logind a ou va en présenter une nouvelle et celle de systemd peut très bien changer ou s’agrandir (c'est un logiciel en développement actif). Ça n'est pas un standard, ça tente de se présenter comme un standard de fait, mais aujourd'hui ça n'est pas le cas.
Mais c'est pas une bonne chose de changer aussi régulièrement les API linux, c'est peut être l'un des gros problèmes de linux sur desktop. C'est les API du bureau linux. Le problème n'est pas fonctionnel. Avoir une vitesse de boot ou une gestion des sessions utilisateurs dans l'absolu c'est joli, mais ça apporte plus de bug d'intégration que de fonctionnalité pour l'utilisateur final.
Bien sûr Lennart comme tout autre vis dans le monde du logiciel libre, un monde où chacun fait bien ce qu'il veut et qui est régis par une méritocratie celui qui fait a le dernier mot, mais ça n'empêche pas de donner son avis.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Tu marronne parce que t'a pas compris une phrase ?
Tu es entrain de définir une langue qui n'est pas le français. Le français n'a jamais eu pour objectif d'être sans ambiguïté et tu te sert beaucoup du contexte pour le comprendre, c'est d'ailleurs qui permet à beaucoup de développeurs spécialistes des langages naturels de vivre.
Si ça t’intéresse, je crois qu'il existe une langue qui a était conçu pour être humaine et réduire au maximum les ambiguïtés et la rendre facile à comprendre pour une machine (mais ça n'est ni du français, ni de l'anglais, ni aucune langue nationale d'aucun pays).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
GNOME n'est pas dépendant à systemd. Il est dépendant d'une API dbus qui pour l'instant n'est fournie que par systemd, aux systèmes concurrents de l'implémenter.
C'est un peu comme si tu disais que KDE n'est pas dépendant de Qt mais d'une API fournie uniquement par Qt…
On sait tous que c'est Gnome et GDM qui sont directement en ligne de mire là dessus notamment à cause d'un potentiel (je sais pas si ça a était fait finalement) couplage fort entre systemd, logind et gdm. La crainte que Gnome se dirige vers une dépendance forte avec logind/systemd n'est pas sans raison.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
C'était ironique… C'est à mon avis improbable qu'ils choisissent cette option, elle est fonctionnellement faible et n'apporte pas grand chose face à l'existant. Ce serait beaucoup de bruit pour presque rien. Vu le débat il n'y a pas grand monde pour défendre OpenRC (c'est un peu le truc qui est re sortie pour avoir quelque chose à répondre aux fan de systemd/upstart).
AMHA il est important de choisir une option qui ne soit pas ?L, mais de la part de Debian ça m'étonnerait. Pour le reste c'est pas très gênant. Ils vont choisir DT, UT ou GR et ce sera bien. Ça permettra au packagers de commencer le boulot pour Jessie.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Tu introduit un biais. Enron ou n'importe quoi d'autre, le problème est le même, l'investissement peut ne plus avoir de valeur du jour au lendemain (une situation politique mauvaise, un choix qui finalement n'est pas gagnant,…). Le moins pire c'est probablement de diversifier, mais ça ne garantie rien et un crash reste un crash.
C'est quoi ça ?
C'est déclenché par quoi ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
De mon point de vue, une grosse amende aux entreprises qui font ce genre de connerie devrait les motiver à faire attention. Et clé sous la porte si tu fais pas attention.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[…] un style coopération où chaque joueur à une zone de combat qui lui est propre. Cela donnerait un niveau avec deux types de décors et des vagues différentes.
Quel est l'intérêt par rapport à 2 joueurs qui lancent chacun le je de leur coté ?
En mode multijoueur (2 joueurs), il y a du choix :
un joueur qui fait les déplacements et un qui tire (je n'ai jamais joué à ton jeu je sais pas si la partie tire se contente d'être un appuie continue sur une touche ou s'il faut aussi viser/choisir son arme)
taguer les ennemis pour que ce soit l'un ou l'autre des joueurs qui doit le tuer (pas de collision entre les vaisseaux des 2 joueurs pour utiliser tout l'écran)
les 2 joueurs tires sur n'importe quel ennemis, mais les bosse doivent être gérés à 2 et tu peut imaginer des combinaisons (si les 2 joueurs ont la même armes elle est plus puissante, ils peuvent se réparer entre eux, etc)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
J'aime beaucoup quand quelqu'un qui se dit ne rien comprendre à l'intérêt et au principe des tablettes, affirme ça. C'est quoi tes arguments pour affirmer qu'ils travaillent pour les tablettes ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Non, zsh + coreutils + quelques autres trucs, mais là dedans l'important pour moi c'est zsh le reste j'en change quand je le souhaite au grès de ce que je trouve de sympas :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
D'après Shift ça peut être totalement dépend de l'environnement d'exécution, tu ne peux donc pas être certains de ce qui s'est passé avant (si ça se trouve jQuery ou une autre lib crée une variable de ce nom là, voir mieux si c'est possible (ça ne m'étonnerais même pas que ça le soit) interfère avec le comportement de l'interpréteur pour récupérer toutes les ReferenceError).
Va aller vomir…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Précisions ?
Posté par barmic . En réponse au journal L'apocalypse arrive. Évalué à 4.
64 pour conversion d'adresse IPv6 en IPv4.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dépendance à un système d'init
Posté par barmic . En réponse au journal Debian à l'heure du choix. Évalué à 1.
Je pense que ça demanderait une mise à jour d'init-functions avec probablement une mise à jour de l'API qui va avec. Ça ne me paraît pas plus moche que ce qu'il y aujourd'hui.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dépendance à un système d'init
Posté par barmic . En réponse au journal Debian à l'heure du choix. Évalué à 3.
C'est pas parce que les distributions utilisent des scripts qui ne se servent pas des cgroups que c'est impossible. Tu peut le faire avec
cgexecpar exemple et donc avecsysvourc.dsans problème notable.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dépendance à un système d'init
Posté par barmic . En réponse au journal Debian à l'heure du choix. Évalué à 1.
Bof si. Tu peut très bien gérer des groupes de contrôle dans uns script shell, rien ne t'en empêche.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dépendance à un système d'init
Posté par barmic . En réponse au journal Debian à l'heure du choix. Évalué à 3.
Leur qualité c'est de gérer proprement la compatibilité avec l'existant. Ça ça a de la valeur pour le bureau.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dépendance à un système d'init
Posté par barmic . En réponse au journal Debian à l'heure du choix. Évalué à 5.
Tu ne peux pas nier qu'il y a un vrai problème d'intégration des nouveautés. L'évolution pourrait très bien prendre en compte l'existant. C'est sur ce genre de petite chose que MacOS fait son beurre.
Pff sérieusement tu crois que personne le vois venir ton homme de paille. Il n'y a pas d'autres choix possible ?
L'intérêt de systemd n'est pas la vitesse de boot. Si on voulais juste faire quelque chose de rapide, on peut le faire de pleins de façons. Le problème est plus dans les dépendances entre le bureau et le système d'init. L'intérêt n'est pas notable (en tout cas pour moi).
Si je ne l'avais pas dis tu aurais était le premier à me répondre que je n'ai qu'à implémenter l'API en question et que si ce n'est pas fait c'est que tout le monde s'en fout (ça fait partie des tes arguments récurrent que tu sort à loisir).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dépendance à un système d'init
Posté par barmic . En réponse au journal Debian à l'heure du choix. Évalué à 8. Dernière modification le 01 février 2014 à 00:49.
C'est un peu fumeux ce que tu dis. Il ne s'agit pas de l'« API DBus », mais d'une API faite sur dbus et qui est proposée par systemd. Si tu veux parler en terme de couche il est bon d'être un peu plus précis et oui c'est une API c'est un ensemble de fonctions, donc ça peut se réimplémenter (comme Qt même si ça choque certains de le dire).
Personnellement tu te fourvoie, je n'ai rien contre systemd (je l'utilise sur ma Debian stable), j'ai l'impression qu'il écrase n'importe quel autre init linux, je vois juste d'un mauvais œil cette API. Oui elle est réimplémentable, oui elle l'a déjà était pour ubuntu. Mais logind a ou va en présenter une nouvelle et celle de systemd peut très bien changer ou s’agrandir (c'est un logiciel en développement actif). Ça n'est pas un standard, ça tente de se présenter comme un standard de fait, mais aujourd'hui ça n'est pas le cas.
Mais c'est pas une bonne chose de changer aussi régulièrement les API linux, c'est peut être l'un des gros problèmes de linux sur desktop. C'est les API du bureau linux. Le problème n'est pas fonctionnel. Avoir une vitesse de boot ou une gestion des sessions utilisateurs dans l'absolu c'est joli, mais ça apporte plus de bug d'intégration que de fonctionnalité pour l'utilisateur final.
Bien sûr Lennart comme tout autre vis dans le monde du logiciel libre, un monde où chacun fait bien ce qu'il veut et qui est régis par une méritocratie celui qui fait a le dernier mot, mais ça n'empêche pas de donner son avis.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pari
Posté par barmic . En réponse au journal Debian à l'heure du choix. Évalué à 3.
En l'occurrence si, j'ai pas relu la constitution Debian, mais je parle des membres du ctte, ceux qui vont voter.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et la plus grosse faille est ... AMAZON
Posté par barmic . En réponse au journal Mots de passe et ingénierie sociale. Évalué à 0.
Tu marronne parce que t'a pas compris une phrase ?
Tu es entrain de définir une langue qui n'est pas le français. Le français n'a jamais eu pour objectif d'être sans ambiguïté et tu te sert beaucoup du contexte pour le comprendre, c'est d'ailleurs qui permet à beaucoup de développeurs spécialistes des langages naturels de vivre.
Si ça t’intéresse, je crois qu'il existe une langue qui a était conçu pour être humaine et réduire au maximum les ambiguïtés et la rendre facile à comprendre pour une machine (mais ça n'est ni du français, ni de l'anglais, ni aucune langue nationale d'aucun pays).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dépendance à un système d'init
Posté par barmic . En réponse au journal Debian à l'heure du choix. Évalué à 0.
C'est un peu comme si tu disais que KDE n'est pas dépendant de Qt mais d'une API fournie uniquement par Qt…
On sait tous que c'est Gnome et GDM qui sont directement en ligne de mire là dessus notamment à cause d'un potentiel (je sais pas si ça a était fait finalement) couplage fort entre systemd, logind et gdm. La crainte que Gnome se dirige vers une dépendance forte avec logind/systemd n'est pas sans raison.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pari
Posté par barmic . En réponse au journal Debian à l'heure du choix. Évalué à 3.
Tu as raison j'ai inversé les lignes…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pari
Posté par barmic . En réponse au journal Debian à l'heure du choix. Évalué à 2.
Tant que ce n'est pas une
?Lça me va :)Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pari
Posté par barmic . En réponse au journal Debian à l'heure du choix. Évalué à 1.
C'était ironique… C'est à mon avis improbable qu'ils choisissent cette option, elle est fonctionnellement faible et n'apporte pas grand chose face à l'existant. Ce serait beaucoup de bruit pour presque rien. Vu le débat il n'y a pas grand monde pour défendre OpenRC (c'est un peu le truc qui est re sortie pour avoir quelque chose à répondre aux fan de systemd/upstart).
AMHA il est important de choisir une option qui ne soit pas
?L, mais de la part de Debian ça m'étonnerait. Pour le reste c'est pas très gênant. Ils vont choisir DT, UT ou GR et ce sera bien. Ça permettra au packagers de commencer le boulot pour Jessie.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dépendance à un système d'init
Posté par barmic . En réponse au journal Debian à l'heure du choix. Évalué à 4.
Ce sera considéré comme un bug et :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pari
Posté par barmic . En réponse au journal Debian à l'heure du choix. Évalué à 5.
OL :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: bof ?
Posté par barmic . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 1.
Je me réponds pour dire que cette image apparaît pour les grands fils de discussion (long en temps ou en profondeur ou un peu des deux ?).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: bof ?
Posté par barmic . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 1.
Tu introduit un biais. Enron ou n'importe quoi d'autre, le problème est le même, l'investissement peut ne plus avoir de valeur du jour au lendemain (une situation politique mauvaise, un choix qui finalement n'est pas gagnant,…). Le moins pire c'est probablement de diversifier, mais ça ne garantie rien et un crash reste un crash.
C'est quoi ça ?
C'est déclenché par quoi ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rien de nouveau, mais...
Posté par barmic . En réponse au journal Mots de passe et ingénierie sociale. Évalué à 1.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bravo
Posté par barmic . En réponse au journal Mots de passe et ingénierie sociale. Évalué à 10.
Humff, tu répond complètement à coté. La question c'est :
Il semble que le fait qu'il t'ai parlé d'entreprise et d'argent t'ai rendu idiot.
Ta réponse c'est un peu comme hadopi qui veut que l'on « sécurise nos connexions », mais qui est incapable de répondre à la question au « comment ? ».
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trop de surcouche, tue la surcouche
Posté par barmic . En réponse au journal apti 0.5 : frontend à aptitude. Évalué à 2.
Ça ne pose pas de problème en effet.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bien joué!
Posté par barmic . En réponse au journal Code source d'X-Blaster Dominator disponible. Évalué à 4.
Quel est l'intérêt par rapport à 2 joueurs qui lancent chacun le je de leur coté ?
En mode multijoueur (2 joueurs), il y a du choix :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: apt-get remove gnome
Posté par barmic . En réponse au journal Quand le vaisseau tombe à l'eau, il faut trouver le poisson. Évalué à 1.
J'aime beaucoup quand quelqu'un qui se dit ne rien comprendre à l'intérêt et au principe des tablettes, affirme ça. C'est quoi tes arguments pour affirmer qu'ils travaillent pour les tablettes ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: zsh
Posté par barmic . En réponse au journal Quand le vaisseau tombe à l'eau, il faut trouver le poisson. Évalué à 2.
Non, zsh + coreutils + quelques autres trucs, mais là dedans l'important pour moi c'est zsh le reste j'en change quand je le souhaite au grès de ce que je trouve de sympas :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Exception ReferenceError
Posté par barmic . En réponse au message Quand javascript se vautre silencieusement sous Firefox. Évalué à 3.
D'après Shift ça peut être totalement dépend de l'environnement d'exécution, tu ne peux donc pas être certains de ce qui s'est passé avant (si ça se trouve jQuery ou une autre lib crée une variable de ce nom là, voir mieux si c'est possible (ça ne m'étonnerais même pas que ça le soit) interfère avec le comportement de l'interpréteur pour récupérer toutes les
ReferenceError).Va aller vomir…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# zsh
Posté par barmic . En réponse au journal Quand le vaisseau tombe à l'eau, il faut trouver le poisson. Évalué à 4.
zsh fait tout ce dont j'ai besoin :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)