les distribution n'ont pas forcemment les moyens humains de le faire ou les inconvenient de systemd sont pas suffissant pour qu'il passe du temps a faire autre chose
Donc systemd c'est globalement bien, et qu'il y a peu d'inconvenients ce qui fait qu'il n'y a pas suffisement d'interet pour vouloir passer du temps à faire autre chose ?
non: au minimum, un journal nous présentant en quoi grsec est intéressant et pourquoi il n'est pas intégré d'office dans le noyau, accompagné d'un lien vers ton site, à la rigueur ça pourrait passer.
Mais là, ça ressemble trop à du lâcher le liens pour un référencement à moindre frais, d'autant plus que le contenu du billet en question est assez léger.
J'inutilise donc pour activer le no-follow sur cette entrée de forum
Cette discussion était en réponse à un message qui pretendait que udev a été rendu dépendant de systemd.
Et ce qui a été dit c'est que si c'était le cas (ce qui ne l'est pas à ma connaissance), il serait toujours possible de forker udev pour continuer à le rendre independant de systemd.
Et je vois pas ce que viennent faire ici tes histoires de "recoder linux" ou que l'API ne soit pas portable sur autre chose que linux, puisque udev a des le début été crée pour le noyau linux spécifiquement, et ca n'a rien à voir avec le merge dans le meme dépot git que systemd.
Dans ce cas, moi je dis qu'on m'impose udev d'une certaine manière.
Tout comme le noyau linux t'impose son API, Libreoffice t'impose son format de fichier, apache t'impose son format de fichiers vhost, docker t'impose son format de conteneurs, etc … Bon en fait on pourrait dire que tous les logiciels utilisés par beaucoup de gens t'imposent leur APIs, protocoles ou formats de fichiers, et tu peux pas les modifier librement sans que ca pose des problèmes.
Et pourquoi faudrait il absolument repartir d'un truc deja existant ?
Y a des cas ou repartir d'un truc existant pour l'ameliorer est le plus simple. Mais y a aussi des cas ou rien de ce qui existe deja est adapté à ce qu'on veut faire, et ou le plus simple c'est de repartir de zero. Et parfois aussi on ne peut pas dire de facon evidente laquelle des 2 solutions est la meilleure.
Et au final c'est juste un choix à faire par le developeur, y a pas de regle generale la dessus. Comme le choix du language, du type de base de données, du format de fichier, de l'environment de dev, etc …
En tout cas, il est dépendant de linux. ça c'est un fait. Et pas udev lui même, son API est dépendante de linux.
De quoi tu parles ? udev est dépendant de linux, et alors ?
Donc non chacun n'est pas "libre" de développer sa propre version d'udev.
Ben si, udev est libre et l'a toujours été, donc chacun est libre de forker et maintenir sa propre version si ce que font les mainteneurs actuels ne convient pas.
Sauf que systemd couvre tellement de choses qu'il est impossible pour des libristes bénévoles d'espérer rattraper ça.
Il y a des bénévoles qui contribuent à systemd.
Et puis personnellement, tant que c'est libre et que ca fonctionne bien, je m'en moque que ca soit fait par des bénévoles ou pas.
Bon en fait non, je m'en moque pas complement. Si en plus de déveloper des trucs libres qui fonctionnent bien, ils peuvent etre payés pour ce qu'ils font, je trouve ca encore mieux.
C'te blague ; extrait de https://github.com/systemd/systemd/tree/master/src là ou je vois des outils qui existaient déjà : ask-password, backlight, cryptsetup, fsck (sans déconner !), hostname, locale, modules-load, network (je vois qu'ils ont réimplémenté tout iproute, sans même utiliser libnl), readahead, remount-fs, resolve, sysctl, …
En passant, à chaque fois aucun commentaire en haut du fichier pour expliquer ce que ça fait exactement : il faut aller voir le main().
On appelle ca des wrappers. Un petit programme qui permet d'integrer un outil deja existant à systemd.
C'est pas par ce qu'il y a un fichier cryptsetup.c ou fsck.c que systemd réimplement cryptsetup et fsck.
Heu… Lennart ne trouvait pas ça « normal » à priori avant, vu que c'est comme ça que c'était depuis un bout de temps. Et donc maintenant, les cgroup ça doit appartenir à systemd et c'est tout point ; voilà un système coopératif…
Faudrait un jour arreter de raconter n'importe quoi pour toujours tout mettre sur le dos de Lennart. Le changement dans les cgroups n'a rien à voir avec Lennart, c'est le mainteneur kernel des cgroups qui s'est rendu compte que la facon dont c'était fait c'était le bordel, et qu'il serait mieux qu'il n'y ait qu'un seul daemon qui se charge de la gestion des cgroups, et qui est allé voir Lennart pour lui proposer de faire une implementation dans systemd de la nouvelle interface.
Mais, je ne sauterais pas aussi vite que toi sur la conclusion. Les units sont distribués par des logiciels tiers, que tu peux ne pas vouloir faire tourner en root (souvent tu lances un daemon sous un autre utilisateur par exemple). Après je dis pas que c'est une faille majeure, et évidement c'est beaucoup moins important que dans un navigateur, pour autant je trouve un peu rapide une affirmation comme :
Si tu as accès en écriture à un fichier unit, alors tu peux faire executer ce que tu veux en root. Donc si tu as pas confiance dans le logiciel tiers qui distribue le fichier unit, je pense que tu as un problème quelle que soit la facon dont est fait le parsing.
Et si le parsing de ces fichiers était fait par un processus avec des droits restreints qui transmet le resultat du parsing au pid 1, ca ne rendrait pas un bug dans le parsing moins important. Si tu peux prendre le controle du processus qui fait le parsing, alors tu peux lui faire transmettre au pid 1 n'importe quelle commande à executer en root. Donc ca n'apporterait aucune sécurité en plus, et au contraire ca complexifierait le fonctionnement, ce qui augmenterait les possibilités de bug.
certe mais une fois corrigé, il disparaît, on n'en parle plus :) cela fait du temps en plus pour faire autre choses. de mon point de vue, les decideurs attendent d'avoir un volume d'emmerde trop important pour pouvoir s'en occuper correctement.
en général ils attendent que le client exige une explication et une solution :(,il a été endormi pendant de looongue semaine par le dirco, puis PAF il faut pondre la solution impossible dans la semaine. Mais qu'est ce qui les empêchent de nous prévenir 4 semaine avant ?
J'en parle car je sais que pour début juillet on va m'avertir debut juillet que c'est urgent :) oui vous avez bien lu, le projet qui stagne depuis 1 an :( en R&D qui va me nécessiter 4 semaine de delai raccourci en 3/4 jours. en general j'arrive à travailler en douce/cachette sur le projet pour ne pas être surpris, mais j'aime pas trop.
Linux, ma bouffée oxygène a défaut de chèvre de le larzac :)
Et sans parler du fait que chacun est libre de maintenir sa propre version d'udev, c'est un mensonge que de dire que udev a été rendu dépendant de systemd. Il est développé dans le meme git que systemd, mais à ma connaissance ca ne l'empeche pas de pouvoir fonctionner sans systemd.
Quand l’affichage d’une page fait ramer tout le reste, j’appelle ça un problème de performance global, parce que je ne sais pas dire quel point ralenti tout le reste.
mon expérience, et parcours mon prouvé que tous les problemes/bug doivent etre toujours résolu, il y a le risque que cela entraîne une cascade de probleme a résoudre dans l'urgence.
genre analogie foireuse : rouler avec une roue de secours crevé dans le coffre de la voiture, pourquoi la faire remplacer ? ca marche très bien comme ca, de quoi je me mêle, etc …
actuellement je vois que personne ne veut prendre de risque, mais implicitement il prenne la décision que cela leur explose a la figure un jour ou l'autre.
citons Linus :
Parfois, vous devez seulement prendre une décision. Il n’est pas toujours évident de savoir quelle est la « bonne » décision, et parfois il peut être bon de se contenter de dire « nous n’en savons rien » et de ne pas prendre de décision du tout. Dans d’autres cas, vous devez vraiment choisir entre des alternatives techniques. La bonne nouvelle, c’est que la plupart des choix techniques peuvent être changés si, plus tard, il s’avère qu’ils étaient erronés. Cela peut être douloureux, mais parfois il vaut mieux faire un choix, même si vous ne savez pas si c’est le bon.
Bizarrement je n'ai pas de problèmes avec les plugins avec chromium. C'est pas pour troller hein, j'utilise tous les jours Firefox en espérant que la prochaine maj fournisse des améliorations sur les perfs, mais ce n'est là qu'un contournement et pas une solution. Le ralentissement existera toujours une fois que le plugin aura été autorisé à se lancer.
le processus de développement de linux, si comme moi tu aimerais le même processus dans ta boite : pouce vert
le bonne exemple : Mettre à jour la somme de contrôle tout simplement
par chez nous : Mettre à jour la somme de contrôle ? pourquoi faire ? en quoi ca te regarde ? de toute facon ca tourne depuis 2 ans comme ca ? laisse le devellopeur responsable de ça le faire. /o\ et j'imagine que je ne suis pas tous seul dans ce cas, ca me desespere encore plus.
ça donnerait presque envie d'elever des chèvres dans le Larzac
L'ensemble des démons est maintenant démarré et géré par systemd. Les administrateurs ne doivent ainsi plus se charger de redémarrer les démons directement, c'est systemd qui s'en charge.
un mariage étant plus la fête des mariés que des conviés, mon plan de table a été fait avec /dev/urandom, c'est pas trop mal :), les personnes qui n'aiment pas d'autre personnes au point de ne pas leur parler, je ne les ai tous simplement pas invité \o/
J'avais bien compris que c'était du CPU que tu parlais.
Mon i3 4130 (c'est pas équivalent à ton i7, je l'accorde) ne dépasse pas 30°C au repos et 60°C en pleine charge et il fait également 28°C ambiant. Si tu choisi bien tes composants, c'est pas difficile d'avoir une bonne aération tout en restant silencieux (des ventilateurs de 140 mm par exemple font très peu de bruit pour un volume d'air déplacé relativement élevé).
[^] # Re: Portabilité et forçage
Posté par Anonyme . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 6.
Ben udev aussi tu peux ne pas l'utiliser. Et tu peux aussi ne pas utiliser d'ordinateur du tout si tu veux.
Et alors ?
[^] # Re: Portabilité et forçage
Posté par Anonyme . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 4.
Donc systemd c'est globalement bien, et qu'il y a peu d'inconvenients ce qui fait qu'il n'y a pas suffisement d'interet pour vouloir passer du temps à faire autre chose ?
[^] # Re: Portabilité et forçage
Posté par Anonyme . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 5.
Désolé mais ta phrase ne veut rien dire.
utiliser quoi ?
libreoffice permet sans doute d'ecrire des fichiers .txt, mais je ne vois pas le rapport.
# schplorf !
Posté par Anonyme . En réponse au message Sécurisez votre Kernel avec GRSEC . Évalué à 5.
non: au minimum, un journal nous présentant en quoi grsec est intéressant et pourquoi il n'est pas intégré d'office dans le noyau, accompagné d'un lien vers ton site, à la rigueur ça pourrait passer.
Mais là, ça ressemble trop à du lâcher le liens pour un référencement à moindre frais, d'autant plus que le contenu du billet en question est assez léger.
J'inutilise donc pour activer le no-follow sur cette entrée de forum
[^] # Re: Portabilité et forçage
Posté par Anonyme . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
Cette discussion était en réponse à un message qui pretendait que udev a été rendu dépendant de systemd.
Et ce qui a été dit c'est que si c'était le cas (ce qui ne l'est pas à ma connaissance), il serait toujours possible de forker udev pour continuer à le rendre independant de systemd.
Et je vois pas ce que viennent faire ici tes histoires de "recoder linux" ou que l'API ne soit pas portable sur autre chose que linux, puisque udev a des le début été crée pour le noyau linux spécifiquement, et ca n'a rien à voir avec le merge dans le meme dépot git que systemd.
Tout comme le noyau linux t'impose son API, Libreoffice t'impose son format de fichier, apache t'impose son format de fichiers vhost, docker t'impose son format de conteneurs, etc … Bon en fait on pourrait dire que tous les logiciels utilisés par beaucoup de gens t'imposent leur APIs, protocoles ou formats de fichiers, et tu peux pas les modifier librement sans que ca pose des problèmes.
[^] # Re: Quel joli troll !
Posté par Anonyme . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 4.
Et pourquoi faudrait il absolument repartir d'un truc deja existant ?
Y a des cas ou repartir d'un truc existant pour l'ameliorer est le plus simple. Mais y a aussi des cas ou rien de ce qui existe deja est adapté à ce qu'on veut faire, et ou le plus simple c'est de repartir de zero. Et parfois aussi on ne peut pas dire de facon evidente laquelle des 2 solutions est la meilleure.
Et au final c'est juste un choix à faire par le developeur, y a pas de regle generale la dessus. Comme le choix du language, du type de base de données, du format de fichier, de l'environment de dev, etc …
[^] # Re: Portabilité et forçage
Posté par Anonyme . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
De quoi tu parles ? udev est dépendant de linux, et alors ?
Ben si, udev est libre et l'a toujours été, donc chacun est libre de forker et maintenir sa propre version si ce que font les mainteneurs actuels ne convient pas.
[^] # Re: À mon tour
Posté par Anonyme . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 10.
Il y a des bénévoles qui contribuent à systemd.
Et puis personnellement, tant que c'est libre et que ca fonctionne bien, je m'en moque que ca soit fait par des bénévoles ou pas.
Bon en fait non, je m'en moque pas complement. Si en plus de déveloper des trucs libres qui fonctionnent bien, ils peuvent etre payés pour ce qu'ils font, je trouve ca encore mieux.
[^] # Re: Petit retour d'expérience
Posté par Anonyme . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 10.
En constatant que sur une autre distro utilisant systemd, ca fonctionne très bien.
[^] # Re: À mon tour
Posté par Anonyme . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 9.
On appelle ca des wrappers. Un petit programme qui permet d'integrer un outil deja existant à systemd.
C'est pas par ce qu'il y a un fichier cryptsetup.c ou fsck.c que systemd réimplement cryptsetup et fsck.
Faudrait un jour arreter de raconter n'importe quoi pour toujours tout mettre sur le dos de Lennart. Le changement dans les cgroups n'a rien à voir avec Lennart, c'est le mainteneur kernel des cgroups qui s'est rendu compte que la facon dont c'était fait c'était le bordel, et qu'il serait mieux qu'il n'y ait qu'un seul daemon qui se charge de la gestion des cgroups, et qui est allé voir Lennart pour lui proposer de faire une implementation dans systemd de la nouvelle interface.
[^] # Re: Quel joli troll !
Posté par Anonyme . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 8.
Si tu as accès en écriture à un fichier unit, alors tu peux faire executer ce que tu veux en root. Donc si tu as pas confiance dans le logiciel tiers qui distribue le fichier unit, je pense que tu as un problème quelle que soit la facon dont est fait le parsing.
Et si le parsing de ces fichiers était fait par un processus avec des droits restreints qui transmet le resultat du parsing au pid 1, ca ne rendrait pas un bug dans le parsing moins important. Si tu peux prendre le controle du processus qui fait le parsing, alors tu peux lui faire transmettre au pid 1 n'importe quelle commande à executer en root. Donc ca n'apporterait aucune sécurité en plus, et au contraire ca complexifierait le fonctionnement, ce qui augmenterait les possibilités de bug.
[^] # Re: ça me fait toujours rêver
Posté par Anonyme . En réponse à la dépêche Sortie du noyau Linux 3.15. Évalué à 4. Dernière modification le 13 juin 2014 à 20:04.
certe mais une fois corrigé, il disparaît, on n'en parle plus :) cela fait du temps en plus pour faire autre choses. de mon point de vue, les decideurs attendent d'avoir un volume d'emmerde trop important pour pouvoir s'en occuper correctement.
en général ils attendent que le client exige une explication et une solution :(,il a été endormi pendant de looongue semaine par le dirco, puis PAF il faut pondre la solution impossible dans la semaine. Mais qu'est ce qui les empêchent de nous prévenir 4 semaine avant ?
J'en parle car je sais que pour début juillet on va m'avertir debut juillet que c'est urgent :) oui vous avez bien lu, le projet qui stagne depuis 1 an :( en R&D qui va me nécessiter 4 semaine de delai raccourci en 3/4 jours. en general j'arrive à travailler en douce/cachette sur le projet pour ne pas être surpris, mais j'aime pas trop.
Linux, ma bouffée oxygène a défaut de chèvre de le larzac :)
[^] # Re: Quel joli troll !
Posté par Anonyme . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 10.
Alors qu'il existait deja des clients dhcp. Encore du NIH, c'est scandaleux !
[^] # Re: Portabilité et forçage
Posté par Anonyme . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 3.
Et sans parler du fait que chacun est libre de maintenir sa propre version d'udev, c'est un mensonge que de dire que udev a été rendu dépendant de systemd. Il est développé dans le meme git que systemd, mais à ma connaissance ca ne l'empeche pas de pouvoir fonctionner sans systemd.
[^] # Re: Click to play ?
Posté par Anonyme . En réponse à la dépêche Firefox 30 glorieuses. Évalué à 0.
Quand l’affichage d’une page fait ramer tout le reste, j’appelle ça un problème de performance global, parce que je ne sais pas dire quel point ralenti tout le reste.
[^] # Re: ça me fait toujours rêver
Posté par Anonyme . En réponse à la dépêche Sortie du noyau Linux 3.15. Évalué à 10.
mon expérience, et parcours mon prouvé que tous les problemes/bug doivent etre toujours résolu, il y a le risque que cela entraîne une cascade de probleme a résoudre dans l'urgence.
genre analogie foireuse : rouler avec une roue de secours crevé dans le coffre de la voiture, pourquoi la faire remplacer ? ca marche très bien comme ca, de quoi je me mêle, etc …
actuellement je vois que personne ne veut prendre de risque, mais implicitement il prenne la décision que cela leur explose a la figure un jour ou l'autre.
citons Linus :
Parfois, vous devez seulement prendre une décision. Il n’est pas toujours évident de savoir quelle est la « bonne » décision, et parfois il peut être bon de se contenter de dire « nous n’en savons rien » et de ne pas prendre de décision du tout. Dans d’autres cas, vous devez vraiment choisir entre des alternatives techniques. La bonne nouvelle, c’est que la plupart des choix techniques peuvent être changés si, plus tard, il s’avère qu’ils étaient erronés. Cela peut être douloureux, mais parfois il vaut mieux faire un choix, même si vous ne savez pas si c’est le bon.
[^] # Re: Click to play ?
Posté par Anonyme . En réponse à la dépêche Firefox 30 glorieuses. Évalué à -1.
Bizarrement je n'ai pas de problèmes avec les plugins avec chromium. C'est pas pour troller hein, j'utilise tous les jours Firefox en espérant que la prochaine maj fournisse des améliorations sur les perfs, mais ce n'est là qu'un contournement et pas une solution. Le ralentissement existera toujours une fois que le plugin aura été autorisé à se lancer.
# Click to play ?
Posté par Anonyme . En réponse à la dépêche Firefox 30 glorieuses. Évalué à -2.
Il dit qu’il n’a pas vu de changement de comportement depuis cette mise à jour.
Il dit aussi que ce n’est encore qu’un contournement foireux de plus pour palier aux problèmes de performances de Firefox.
En fait, on a des informations sur les éventuels travaux sur les performances globales de Firefox ?
# ça me fait toujours rêver
Posté par Anonyme . En réponse à la dépêche Sortie du noyau Linux 3.15. Évalué à 10.
le processus de développement de linux, si comme moi tu aimerais le même processus dans ta boite : pouce vert
le bonne exemple : Mettre à jour la somme de contrôle tout simplement
par chez nous : Mettre à jour la somme de contrôle ? pourquoi faire ? en quoi ca te regarde ? de toute facon ca tourne depuis 2 ans comme ca ? laisse le devellopeur responsable de ça le faire. /o\ et j'imagine que je ne suis pas tous seul dans ce cas, ca me desespere encore plus.
ça donnerait presque envie d'elever des chèvres dans le Larzac
[^] # Re: Gnome 3
Posté par Anonyme . En réponse à la dépêche Red Hat Enterprise Linux 7. Évalué à 4.
Mais pourquoi tout le monde semble dire que Gnome 3 est axé sur le tactile ? Qu'est ce qu'il y a d'axé sur le tactile dans Gnome 3 ?
[^] # Re: Ctrl
Posté par Anonyme . En réponse au journal Défouloir, pamphlet, troll: Chromium, Bépo et NIH. Évalué à 2.
Pour ceux qui veulent une correction rapide de ce bug :
[^] # Re: Besoin de traqueur ?
Posté par Anonyme . En réponse au journal soutenez Freetorrent. Évalué à -7.
Glandu va.
# systemday
Posté par Anonyme . En réponse à la dépêche Red Hat Enterprise Linux 7. Évalué à 2.
Mais encore ?
[^] # Re: Pas de solution à te proposer
Posté par Anonyme . En réponse au message Logiciel d'assistance pour faire son plan de table . Évalué à 3.
un mariage étant plus la fête des mariés que des conviés, mon plan de table a été fait avec /dev/urandom, c'est pas trop mal :), les personnes qui n'aiment pas d'autre personnes au point de ne pas leur parler, je ne les ai tous simplement pas invité \o/
[^] # Re: Isolant ?
Posté par Anonyme . En réponse au journal Mplayer est (presque) mort, vive Mpv (et vaapi). Évalué à 4.
J'avais bien compris que c'était du CPU que tu parlais.
Mon i3 4130 (c'est pas équivalent à ton i7, je l'accorde) ne dépasse pas 30°C au repos et 60°C en pleine charge et il fait également 28°C ambiant. Si tu choisi bien tes composants, c'est pas difficile d'avoir une bonne aération tout en restant silencieux (des ventilateurs de 140 mm par exemple font très peu de bruit pour un volume d'air déplacé relativement élevé).