La sauvegarde de mots de passe, oui, ça existe déjà. Le partage de mot de passe entre utilisateurs différents ? Pas à cette échelle, je crois.
C'est un point essentiel: Microsoft doit être capable, à partir seulement d'un identifiant et d'un nom de wifi, de fournir le mot de passe en clair. Lorsque ça ne concerne qu'un utilisateur unique, on peut rechiffrer le mot de passe avec un mot de passe maître connu de l'utilisateur seul. Cela permet de stocker des mots de passe chez un tiers sans que le tiers sache le déchiffrer. Mais le principe même de Wifi Sense ne permet pas cela.
Ne pas avoir à retaper son mot de passe wifi pour chaque appareil dans la maison semble être sympa (même si, vu que le mot de passe est mémorisé sur la machine, ça n'est pénible qu'une fois). Mais pour un besoin géographiquement local, il est décevant de voir que la réponse de MS est d'envoyer ça sur un serveur tiers.
C'est probablement le raisonnement de MS: si les gens ne font pas attention à leur vie privée, ou ne comprennent pas les implications de ces options, autant en profiter !
Grâce à WiFi Sense activé par défaut, MS se concocte une base de données de tous les mots de passe wifi des Mme Michu de la planète. MS saura également à quels réseaux wifi on aura essayé de se connecter. Une mine d'or, où le moindre bug sera épié.
De plus ça a un comportement viral: si l'un de tes amis a laissé cette option et se connecte chez toi à ton wifi, ton choix à toi n'aura servi à rien.
Si "c'est déjà le cas de toutes façons", c'est peut-être à cause d'options cochées par défaut, sur des logiciels les plus répandus de la planète (Android, Windows) ? On ne parle pas ici d'un logiciel optionnel, on parle du rouleau compresseur qui va toucher 95% des utilisateurs d'appareils dans les prochaines années.
Je trouve que laisser cette option activée par défaut est surtout très sournois sur un tel logiciel, du même niveau que les "barres d'outils" proposées par défaut dans certains installeurs.
est défini par ses mainteneurs comme une plateforme modulaire qui fait la glu entre les applications et le noyau Linux.
Si c'est modulaire mais que tout est essentiel, on n'a pas la même définition de "plateforme modulaire".
Ne peut-on pas mettre dans des paquets "addons" les "modules" correspondant à logind, networkd, autrechosed ? Personnellement je trouverais ça plus sain: c'est une façon d'évaluer les dépendances entre les différents éléments du projet.
Je parle du projet systemd, pas du binaire. En dehors de systemd et journald, bien peu de modules systemd sont absolument indispensables, et sont surtout des versions simplifiées d'outils déjà existants.
D'ailleurs, je trouve que tu as plutôt bien listé ce qui est indispensable dans systemd et qui fait sa force. Maintenant, quid du reste ?
Les efforts pour satisfaire le besoin des 1% est énorme et il est tout à fait compréhensible que les distributions et autres ont envie d'utiliser le temps gagné pour faire autre chose qui sera plus utile à la majorité. Pour les autres, il y a LFS xD
Mais c'est bien de ce 1% dont on parle là. Les 99% sont couverts depuis bien longtemps par systemd. Et j'ai l'impression que justement, ce qui embête, c'est que systemd court après ces 1%, et cette hiérarchisation de l'importance des fonctionnalités est peu visible, que ce soit dans systemd ou dans les distributions.
Séparer un peu plus clairement les choses, ou proposer un "systemd-light" permettrait aux utilisateurs d'avoir enfin un gestionnaire de démarrage à l'étendue un peu plus stable, sans sacrifier les atouts offerts par systemd.
La "dépendance" sur dbus en est une, actuellement en cours de résolution avec kdbus.
Le lien fort avec la glibc est quand même réductrice, à mon avis.
Les frontières floues du projet n'aident pas à rassurer (certes ce n'est pas un point technique).
Une complexification de l'outil d'init toujours grandissante: à chaque option rajoutée dans un .conf, c'est un potentiel bug dans l'outil gérant cette option. Ce problème a son pendant dans les autres inits bien sûr, mais le bug était dans les scripts (donc décentralisé, donc potentiellement moins fatal à l'init).
Ce sont des remarques techniquement sensées, pointant des choix conscients faits par le projet systemd. Pour certains, ce sont des inconvénients, pour d'autres des atouts. Il n'y a pas grand chose à dire là-dessus: soit on l'accepte, soit on revient 4 ans en arrière…
Donc perso, je pige pas le fait de se focaliser sur systemd et d'idéaliser complétement le reste en occultant les pétages réguliers de la compatibilité par divers upstreams.
Parce qu'au bout de trente répétitions, il y a quelque chose que je n'arrive pas à faire rentrer dans la tête de ceux qui me répondent: jusqu'à preuve du contraire, l'auteur du journal n'a pas besoin de systemd. C'est tout ! point.
C'est bien gentil de défendre systemd bec et ongles, sauf que ce n'est pas systemd que je critique, c'est le fait de vouloir absolument que quelqu'un l'installe alors qu'il n'en a pas le besoin. systemd, c'est un init qu'il ne connaît peut-être pas encore, et manifestement il souhaite maîtriser son init. Il faudrait arrêter de faire semblant de ne pas voir la différence entre le passage d'une version à une autre d'un logiciel qu'on connaît déjà, et le passage d'un logiciel à un autre qui n'a pas du tout la même logique.
Le problème est que tu es en train d'utiliser une fonctionnalité obsolète de systemd, qui n'est là que pour assurer la transition et qui est vouée à disparaître. Effectivement, ça marche pour la version 217. C'est tout ce qu'on peut en déduire.
L.P. a toujours dit que systemd serait fortement lié au noyau, et utiliserait le plus possible ses fonctionnalités. Donc, comme il le dit lui-même, ça marchera avec des noyaux un peu plus vieux, mais faudra pas pousser trop loin.
C'est un choix qui apporte des avantages au niveau technique, mais qui peut apporter aussi des pièges niveau maintenance.
Mais quand tu parle de « risque », je ne suis pas convaincu : à mon avis il y a bien plus de risque à rester sur un truc obsolète plutôt que de suivre le choix par défaut de la distribution, qui s'inscrit dans une tendance générale.
Merci, enfin un argument qui cherche élever le débat. Oui, ok, il y a un risque à rester sur un vieil init qui va disparaître. Mais pour l'instant, c'est là, c'est supporté par Debian et ça marche pour lui.
Lorsqu'il voudra un jour installer un .deb extérieur qui ne sera prévu que pour systemd, il aura alors un problème. Donc un besoin. Donc une raison d'installer et apprendre systemd. Mais pour l'instant, le besoin, il n'existe pas.
L'auteur a sûrement ses raisons, je ne critique pas.
Et dans ce fil de commentaires, tu es bien le seul… Les autres lui reprochent de ne pas installer systemd !
Ça vire à la mauvaise foi, là. J'ai dit: un changement de logiciel. Tu es la première personne que je rencontre à comprendre ça comme un changement de version d'un même logiciel.
Passer de linux 3.14 à linux 3.15, c'est une mise à jour.
Passer de linux 3.14 à hurd 0.008, c'est un changement de logiciel.
Si tu ne vois pas la différence, on peut arrêter là la discussion.
Sinon, continuons. Systemd c'est mieux, la mise à jour c'est automagique, génial. Je suis d'ailleurs assez d'accord sur ces points, de toute façon.
Par contre:
- les commandes se ressemblent, certes… se ressemblent. Donc lorsqu'il fera /etc/init.d/network restart, ça va marcher ? non. Ou à moitié. En tout cas, ce n'est pas la bonne méthode.
- l'utilisateur lambda ne saurait même pas que le système d'init a changé lors de l'upgrade. Hors-sujet: on n'est pas face à l'utilisateur lambda, on est face à quelqu'un qui a bidouillé son init et souhaite en garder la maîtrise.
Bref, on en revient toujours au même point, inlassablement: systemd c'est super, mais ce n'est pas une raison suffisante pour le forcer à changer son init.
Je vais arrêter là, parce que ça fait déjà 4 quatre fois que je me répète, et j'ai l'impression de parler à un mur.
Parce que pour systemd ce n'est pas une mise à jour, c'est un changement de logiciel. Il va, magiquement, savoir utiliser systemd juste après la mise à jour ?
C'est très cohérent: vu qu'il a le choix (enfin en vous lisant, j'ai des doutes…), il choisit la mise à jour la moins impactante, et donc de rester sur SysV.
Bizarrement, personne ne conteste l'élément essentiel de mes commentaires: il n'a pas besoin de passer à systemd.
Tu as vraiment tendance à prêter aux autres des propos qu'ils n'ont pas dits. Il a "peur que les scripts d'init cassent" ? Où as-tu lu ça ?
Le risque existe, même infime. Par ailleurs, il y a deux possibilités:
* la mise à jour installe un sous-morceau de systemd, sans le reste --> ça n'apporte rien fonctionnellement et ton système est moins simple. Autant l'éviter, donc
* la mise à jour installe systemd en complet, à la place de l'init SysV --> même si tout se passe bien, il faudra passer du temps à apprendre systemd. Son système d'init SysV le satisfait aujourd'hui, il n'y a donc aucun besoin en face. Ce n'est donc pas une priorité.
Je vais finir par une conclusion à la Zenitram:
C'est marrant les gens qui pensent que ce qui est mieux pour eux est forcément mieux pour la Terre entière. TOI tu as envie que LUI mette à jour son init vers systemd. Sauf que lui, il n'a pas envie, peut-être pas le temps, et apparemment pas besoin. Il a le droit de respirer ?
C'est différent car il a déjà un système d'init. On parle ici de remplacer une brique de base par une autre très différente. Il n'a peut-être pas envie / pas le temps de modifier son GRUB fait maison. Il n'a peut-être pas envie, ou pas le temps, d'apprendre à utiliser un nouveau système d'init alors que celui qu'il a en ce moment fonctionne.
Le vieil init est encore officiellement supporté par la distro, pour rappel.
Je te retourne la question: concrètement, pourquoi passer à systemd là-tout-de-suite-maintenant, pour lui ? Je ne vois aucune urgence, et s'il n'a pas le temps de regarder ce que ça change pour lui, il va juste se retrouver avec un init qu'il ne maîtrise pas.
Tout ça me fait penser à quelqu'un qui va installer Linux sur la machine d'un pote "parce que c'est mieux que Windows", sans se demander si ça lui est d'une quelconque utilité.
Ce sont juste des doutes et des interrogations. Je ne suis pas devin, donc effectivement nous verrons bien. Mais il est essentiel de garder un œil critique sur ce composant qui est aujourd'hui au cœur de notre OS.
Hé bien tous ces trucs viennent avec systemd mais ne font pas partie du binaire systemd, tout comme Linux est livré avec tout en tas de pilotes qui ne sont que des modules.
Et si Linux incluait un module remplaçant mail ? un client ftp ? (minimaliste, bien sûr, enfin, au début…)
On parle bien ici d'un projet systemd, qui faute de limite claire dans son rôle (démarrer un système et le gérer, c'est quand même très flou), est en train de tout refaire à sa sauce. Ce projet est-il donc incapable d'interagir avec une brique de l'espace utilisateur sans créer un module dédié ? Le daemon DHCP, au départ tout simple, ambitionne déjà de gérer un cache DNS et DNSSEC…
Alors, bien sûr, on peut ne pas activer ces modules. Mais il n'empêche que ces modules seront intégrés de plus en plus fortement au démarrage du système, et la possibilité qu'ils deviennent irremplaçables est bien là.
Le problème, tel que je le vois, est double: 1. on a un projet qui se disperse, ne trouve pas son rôle, et 2. on a un risque de rigidifier fortement le système GNU/Linux en faisant tout passer par un composant central.
Récemment il m'est arrivé d'avoir cassé mon DBus à la suite d'une bidouille malheureuse: j'ai dû corriger le problème à l'intuition, car journalctl et systemctl ne fonctionnaient plus… Très pratique.
Je comprends mieux. Pour moi, le sujet du journal n'est pas Linux, mais une migration vers Linux. Le prestataire qui aide à le faire est pour moi une information importante, car elle explique le "pourquoi" et le "comment" de la migration (support et conseil pour la migration du client, etc).
C'est un peu comme faire un journal "j'ai pas réussi à installer Linux, c'était trop difficile". On n'est pas très avancés si on ne sait même pas quels choix ont été faits pour arriver à cet échec.
[^] # Re: C'est faux
Posté par Christophe . En réponse au journal Combien de victimes avec M$ Machin 10?. Évalué à 1.
La sauvegarde de mots de passe, oui, ça existe déjà. Le partage de mot de passe entre utilisateurs différents ? Pas à cette échelle, je crois.
C'est un point essentiel: Microsoft doit être capable, à partir seulement d'un identifiant et d'un nom de wifi, de fournir le mot de passe en clair. Lorsque ça ne concerne qu'un utilisateur unique, on peut rechiffrer le mot de passe avec un mot de passe maître connu de l'utilisateur seul. Cela permet de stocker des mots de passe chez un tiers sans que le tiers sache le déchiffrer. Mais le principe même de Wifi Sense ne permet pas cela.
Ne pas avoir à retaper son mot de passe wifi pour chaque appareil dans la maison semble être sympa (même si, vu que le mot de passe est mémorisé sur la machine, ça n'est pénible qu'une fois). Mais pour un besoin géographiquement local, il est décevant de voir que la réponse de MS est d'envoyer ça sur un serveur tiers.
[^] # Re: C'est faux
Posté par Christophe . En réponse au journal Combien de victimes avec M$ Machin 10?. Évalué à 3.
C'est probablement le raisonnement de MS: si les gens ne font pas attention à leur vie privée, ou ne comprennent pas les implications de ces options, autant en profiter !
Grâce à WiFi Sense activé par défaut, MS se concocte une base de données de tous les mots de passe wifi des Mme Michu de la planète. MS saura également à quels réseaux wifi on aura essayé de se connecter. Une mine d'or, où le moindre bug sera épié.
De plus ça a un comportement viral: si l'un de tes amis a laissé cette option et se connecte chez toi à ton wifi, ton choix à toi n'aura servi à rien.
Si "c'est déjà le cas de toutes façons", c'est peut-être à cause d'options cochées par défaut, sur des logiciels les plus répandus de la planète (Android, Windows) ? On ne parle pas ici d'un logiciel optionnel, on parle du rouleau compresseur qui va toucher 95% des utilisateurs d'appareils dans les prochaines années.
Je trouve que laisser cette option activée par défaut est surtout très sournois sur un tel logiciel, du même niveau que les "barres d'outils" proposées par défaut dans certains installeurs.
[^] # Re: résultats étranges
Posté par Christophe . En réponse au sondage En quelle année êtes-vous passé(e) à GNU/Linux (ou autre système libre) ?. Évalué à 3.
Preuve que l'élite n'est pas si regardante que ça, finalement ;)
[^] # Re: Pas totalement
Posté par Christophe . En réponse au journal Sailfish OS 2 sera libre!. Évalué à 1.
La table à jour, par licence, est ici: https://wiki.merproject.org/wiki/SailfishOSS
[^] # Re: Non
Posté par Christophe . En réponse au journal Tablette de chocolat. Évalué à 0.
C'est tellement bien soigneusement gardé que la brique de base ayant permis le développement du téléphone est libre (libhybris), et qu'il est possible de remplacer toute l'UI par celle de nemo-mobile.
Quand le moment sera venu, on installera Glacier, c'est tout.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Christophe . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 3.
Si c'est modulaire mais que tout est essentiel, on n'a pas la même définition de "plateforme modulaire".
Ne peut-on pas mettre dans des paquets "addons" les "modules" correspondant à logind, networkd, autrechosed ? Personnellement je trouverais ça plus sain: c'est une façon d'évaluer les dépendances entre les différents éléments du projet.
[^] # Re: Cela confirme mon avis sur cette brique système: sympa sur les dekstop , incensée sur un serveur
Posté par Christophe . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 10.
Mais c'est quoi cette rumeur qu'il y a une rumeur ?
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Christophe . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 2.
Je parle du projet systemd, pas du binaire. En dehors de systemd et journald, bien peu de modules systemd sont absolument indispensables, et sont surtout des versions simplifiées d'outils déjà existants.
D'ailleurs, je trouve que tu as plutôt bien listé ce qui est indispensable dans systemd et qui fait sa force. Maintenant, quid du reste ?
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Christophe . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à -1.
Mais c'est bien de ce 1% dont on parle là. Les 99% sont couverts depuis bien longtemps par systemd. Et j'ai l'impression que justement, ce qui embête, c'est que systemd court après ces 1%, et cette hiérarchisation de l'importance des fonctionnalités est peu visible, que ce soit dans systemd ou dans les distributions.
Séparer un peu plus clairement les choses, ou proposer un "systemd-light" permettrait aux utilisateurs d'avoir enfin un gestionnaire de démarrage à l'étendue un peu plus stable, sans sacrifier les atouts offerts par systemd.
[^] # Re: Ou bien ?
Posté par Christophe . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 3.
La "dépendance" sur dbus en est une, actuellement en cours de résolution avec kdbus.
Le lien fort avec la glibc est quand même réductrice, à mon avis.
Les frontières floues du projet n'aident pas à rassurer (certes ce n'est pas un point technique).
Une complexification de l'outil d'init toujours grandissante: à chaque option rajoutée dans un .conf, c'est un potentiel bug dans l'outil gérant cette option. Ce problème a son pendant dans les autres inits bien sûr, mais le bug était dans les scripts (donc décentralisé, donc potentiellement moins fatal à l'init).
Ce sont des remarques techniquement sensées, pointant des choix conscients faits par le projet systemd. Pour certains, ce sont des inconvénients, pour d'autres des atouts. Il n'y a pas grand chose à dire là-dessus: soit on l'accepte, soit on revient 4 ans en arrière…
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 3.
Parce qu'au bout de trente répétitions, il y a quelque chose que je n'arrive pas à faire rentrer dans la tête de ceux qui me répondent: jusqu'à preuve du contraire, l'auteur du journal n'a pas besoin de systemd. C'est tout ! point.
C'est bien gentil de défendre systemd bec et ongles, sauf que ce n'est pas systemd que je critique, c'est le fait de vouloir absolument que quelqu'un l'installe alors qu'il n'en a pas le besoin. systemd, c'est un init qu'il ne connaît peut-être pas encore, et manifestement il souhaite maîtriser son init. Il faudrait arrêter de faire semblant de ne pas voir la différence entre le passage d'une version à une autre d'un logiciel qu'on connaît déjà, et le passage d'un logiciel à un autre qui n'a pas du tout la même logique.
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à -1.
Le problème est que tu es en train d'utiliser une fonctionnalité obsolète de systemd, qui n'est là que pour assurer la transition et qui est vouée à disparaître. Effectivement, ça marche pour la version 217. C'est tout ce qu'on peut en déduire.
L.P. a toujours dit que systemd serait fortement lié au noyau, et utiliserait le plus possible ses fonctionnalités. Donc, comme il le dit lui-même, ça marchera avec des noyaux un peu plus vieux, mais faudra pas pousser trop loin.
C'est un choix qui apporte des avantages au niveau technique, mais qui peut apporter aussi des pièges niveau maintenance.
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 6.
Merci, enfin un argument qui cherche élever le débat. Oui, ok, il y a un risque à rester sur un vieil init qui va disparaître. Mais pour l'instant, c'est là, c'est supporté par Debian et ça marche pour lui.
Lorsqu'il voudra un jour installer un .deb extérieur qui ne sera prévu que pour systemd, il aura alors un problème. Donc un besoin. Donc une raison d'installer et apprendre systemd. Mais pour l'instant, le besoin, il n'existe pas.
Et dans ce fil de commentaires, tu es bien le seul… Les autres lui reprochent de ne pas installer systemd !
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 10. Dernière modification le 27 novembre 2014 à 15:53.
Ça vire à la mauvaise foi, là. J'ai dit: un changement de logiciel. Tu es la première personne que je rencontre à comprendre ça comme un changement de version d'un même logiciel.
Passer de linux 3.14 à linux 3.15, c'est une mise à jour.
Passer de linux 3.14 à hurd 0.008, c'est un changement de logiciel.
Si tu ne vois pas la différence, on peut arrêter là la discussion.
Sinon, continuons. Systemd c'est mieux, la mise à jour c'est automagique, génial. Je suis d'ailleurs assez d'accord sur ces points, de toute façon.
Par contre:
- les commandes se ressemblent, certes… se ressemblent. Donc lorsqu'il fera /etc/init.d/network restart, ça va marcher ? non. Ou à moitié. En tout cas, ce n'est pas la bonne méthode.
- l'utilisateur lambda ne saurait même pas que le système d'init a changé lors de l'upgrade. Hors-sujet: on n'est pas face à l'utilisateur lambda, on est face à quelqu'un qui a bidouillé son init et souhaite en garder la maîtrise.
Bref, on en revient toujours au même point, inlassablement: systemd c'est super, mais ce n'est pas une raison suffisante pour le forcer à changer son init.
Je vais arrêter là, parce que ça fait déjà 4 quatre fois que je me répète, et j'ai l'impression de parler à un mur.
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 6.
Parce que pour systemd ce n'est pas une mise à jour, c'est un changement de logiciel. Il va, magiquement, savoir utiliser systemd juste après la mise à jour ?
C'est très cohérent: vu qu'il a le choix (enfin en vous lisant, j'ai des doutes…), il choisit la mise à jour la moins impactante, et donc de rester sur SysV.
Bizarrement, personne ne conteste l'élément essentiel de mes commentaires: il n'a pas besoin de passer à systemd.
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 2.
Oh allons, pitié, disons, un bug ? Un script particulièrement pourri qu'il aurait conçu ? Le risque zéro n'existe pas en informatique.
Mais sinon, j'en déduis que tu es d'accord avec le reste ?
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à -1.
Je savais que je n'aurais pas dû parler de ce détail: tu n'as retenu que ça de mon commentaire. C'est le reste qui est important.
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 7.
Tu as vraiment tendance à prêter aux autres des propos qu'ils n'ont pas dits. Il a "peur que les scripts d'init cassent" ? Où as-tu lu ça ?
Le risque existe, même infime. Par ailleurs, il y a deux possibilités:
* la mise à jour installe un sous-morceau de systemd, sans le reste --> ça n'apporte rien fonctionnellement et ton système est moins simple. Autant l'éviter, donc
* la mise à jour installe systemd en complet, à la place de l'init SysV --> même si tout se passe bien, il faudra passer du temps à apprendre systemd. Son système d'init SysV le satisfait aujourd'hui, il n'y a donc aucun besoin en face. Ce n'est donc pas une priorité.
Je vais finir par une conclusion à la Zenitram:
C'est marrant les gens qui pensent que ce qui est mieux pour eux est forcément mieux pour la Terre entière. TOI tu as envie que LUI mette à jour son init vers systemd. Sauf que lui, il n'a pas envie, peut-être pas le temps, et apparemment pas besoin. Il a le droit de respirer ?
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 9.
C'est différent car il a déjà un système d'init. On parle ici de remplacer une brique de base par une autre très différente. Il n'a peut-être pas envie / pas le temps de modifier son GRUB fait maison. Il n'a peut-être pas envie, ou pas le temps, d'apprendre à utiliser un nouveau système d'init alors que celui qu'il a en ce moment fonctionne.
Le vieil init est encore officiellement supporté par la distro, pour rappel.
Je te retourne la question: concrètement, pourquoi passer à systemd là-tout-de-suite-maintenant, pour lui ? Je ne vois aucune urgence, et s'il n'a pas le temps de regarder ce que ça change pour lui, il va juste se retrouver avec un init qu'il ne maîtrise pas.
Tout ça me fait penser à quelqu'un qui va installer Linux sur la machine d'un pote "parce que c'est mieux que Windows", sans se demander si ça lui est d'une quelconque utilité.
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 10.
Entre installer un système d'init et mettre à jour des logiciels et bibliothèques, le risque n'est pas le même… Je pensais que c'était évident.
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 6. Dernière modification le 27 novembre 2014 à 09:59.
Si son système marche bien actuellement, pourquoi prendre le moindre risque ? L'init SysV est encore maintenu par Debian, après tout.
[^] # Re: A noter: la release a été faite par Pekka Paalanen.
Posté par Christophe . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 2.
C'est Lipstick, en effet. Par contre, la base de code utilisée est sur Github:
https://github.com/nemomobile/lipstick
https://github.com/nemomobile/lipstick-colorful-home
[^] # Re: Description de systemd ?
Posté par Christophe . En réponse à la dépêche systemd versions 212 à 215. Évalué à 4.
Ce sont juste des doutes et des interrogations. Je ne suis pas devin, donc effectivement nous verrons bien. Mais il est essentiel de garder un œil critique sur ce composant qui est aujourd'hui au cœur de notre OS.
[^] # Re: Description de systemd ?
Posté par Christophe . En réponse à la dépêche systemd versions 212 à 215. Évalué à 5.
Et si Linux incluait un module remplaçant mail ? un client ftp ? (minimaliste, bien sûr, enfin, au début…)
On parle bien ici d'un projet systemd, qui faute de limite claire dans son rôle (démarrer un système et le gérer, c'est quand même très flou), est en train de tout refaire à sa sauce. Ce projet est-il donc incapable d'interagir avec une brique de l'espace utilisateur sans créer un module dédié ? Le daemon DHCP, au départ tout simple, ambitionne déjà de gérer un cache DNS et DNSSEC…
Alors, bien sûr, on peut ne pas activer ces modules. Mais il n'empêche que ces modules seront intégrés de plus en plus fortement au démarrage du système, et la possibilité qu'ils deviennent irremplaçables est bien là.
Le problème, tel que je le vois, est double: 1. on a un projet qui se disperse, ne trouve pas son rôle, et 2. on a un risque de rigidifier fortement le système GNU/Linux en faisant tout passer par un composant central.
Récemment il m'est arrivé d'avoir cassé mon DBus à la suite d'une bidouille malheureuse: j'ai dû corriger le problème à l'intuition, car journalctl et systemctl ne fonctionnaient plus… Très pratique.
(et merde, on est seulement lundi…)
[^] # Re: SLES
Posté par Christophe . En réponse au journal Swiss Re migre de Solaris vers Linux, et bientôt Windows vers Linux. Évalué à 4.
Je comprends mieux. Pour moi, le sujet du journal n'est pas Linux, mais une migration vers Linux. Le prestataire qui aide à le faire est pour moi une information importante, car elle explique le "pourquoi" et le "comment" de la migration (support et conseil pour la migration du client, etc).
C'est un peu comme faire un journal "j'ai pas réussi à installer Linux, c'était trop difficile". On n'est pas très avancés si on ne sait même pas quels choix ont été faits pour arriver à cet échec.