Sébastien Le Ray a écrit 234 commentaires

Quel est l'intérêt de cette fonctionnalité qui fait qu'il faille absolument l'activer par défaut ? J'avoue que j'ai du mal à comprendre.

Le fait de ne pas laisser de ressources traîner sur un système multi-utilisateurs ?

À la base la fonctionnalité n'excluait que root, pour avoir un entre-deux ils ont rajouté les users « système » et enfin on peut la désactiver.
Oui c'est chiant que ça introduise une régression (et encore, dans un cas bien particulier d'utilisation duale d'un user daemon qui a un UID d'utilisateur normal), mais le problème des fonctionnalités désactivées par défaut c'est que personne ne les utilise :-)

Si tu regardes bien, même la personne rapportant le bug est d'accord sur le fait qu'il n'y a rien à corriger dans systemd.
Ça n'arrive que si l'utilisateur postgres (dans ton cas) n'est pas taggé comme system_user et qu'il est utilisé comme un utilisateur classique en plus de son utilisation daemon et l'option est configurable… Du coup j'ai du mal à voir le reproche (mis à part que le threshold pour les system users est défini à la compilation et non dynamiquement en fonction de login.defs).

Mais pourquoi foutre en l'air la philosophie KISS ?

Parce qu'en fait KISS quand tu essaies de gérer un système complexe comme un OS de base d'aujourd'hui ben ça fini par devenir un amoncellement de rustines infâmes… Alors c'est sûr vu que tout le bordel est caché par les gens qui font les distros on s'en rend pas bien compte, mais bon entre un système où je peux filtrer mes logs avec des requêtes naturelles et une chaîne de grep | grep -v | sed | oh-merde-c-est-encore-un-autre-format-de-timestamp, le choix est vite fait

De ce que je lis, et personne ne le contredit ici, systemd a un resolveur DNS et un outil NTP intégrés (même s'ils tournent dans des processus séparés), qui ne sont pas remplaçables par des outils existants parce qu'ils se basent sur une interface fabriquée par systemd, non standard, et donc parfaitement susceptible de changer n'importe quand.

Cadeau et cadeau

Quid de mon choix ?

Bah justement c'est ton choix, pour paraphraser Zenitram, ne demande pas aux autres de l'assumer, RedHat et Poettering ont eu le choix entre suivre ta voie et refaire les outils… bizarrement je pense qu'ils ont un tout petit peu réfléchi auparavant. Tu veux plugger les sytèmes existants ? Pas de soucis, t'as juste à rajouter le thin layer pour la compat' DBus. Vu que c'est des outils « KISS » ça doit être trivial non ?

Faut sortir du schéma de pensée où systemd est un système d'init. C'est un ensemble d'outils qui utilise les spécificités offertes par le noyau Linux. L'un de ces outils est un init. Le principal intérêt est d'avoir un système normalisé où les interactions entre les différents composants ne tournent pas au cauchemar (et pour ça il faut faire des choix: renoncer à la portabilité et ne pas chercher à prendre en charge 10 000 outils extérieurs plus ou moins bien conçus)

Je pense qu'il fallait lire « C'est quoi ? Une ROM Android ? »

Et de toute façon sans chiffrement une machine à laquelle on a un accès physique est compromise…

C'est là que c'est pas logique… Pour moi il serait plus pertinent d'avoir systématiquement du string en entrée (puisqu'il n'y a pas de typage en HTTP) et de devoir volontairement transtyper si on a besoin de quelque chose d'autre.

Il serait bien aussi que le calendrier soit intégré par défaut comme l'idée était décrite dans la roadmap.

C'est le cas depuis la v38 (et ça pose pas mal de soucis à ceux qui avaient le plugin lightning installé manuellement d'ailleurs…)

Sortie : 22/10/2009… 10 ans 1/2 de prise en charge c'est pas mal non ?

Sauf que le paramétrage par défaut d'un soft est celui utilisé par 90% des gens (chiffre certifié par l'Institut National de Pifométrie). Donc si tes valeurs par défaut sont pourries, les gens vont voir ailleurs. LibreOfffice a plein de fonctionnalités géniales et tient la comparaison sur plein de points mais plein de gens s'arrêtent à la première impression: c'est vieillot et les valeurs par défaut (styles, etc) ne permettent pas de sortir un truc sympa sans une grosse étape de personnalisation (et ne parlons pas de Draw :-p)

Je vais ptet essayer d'y aller progressivement en commençant par rediriger le bureau et voir comment ça tourne. Je sais que les premiers tests avaient été avortés pour cause de fichiers hors connexions qui devenaient dingues (sans réussir à trouver pourquoi… le serveur est là, il a un ping de qqes millisecondes mais Windows passe offline). Maintenant qu'ils sont désactivés ça vaudrait peut être le coup de réessayer. Mais j'ai un peu peur de la latence sur les gros fichiers.

Pour les portables nous ils sont sur le domaine avec une GPO spécifique qui dit « pas de roaming ni de redirection de dossier », du coup on a le beurre (déploiement de soft, authentification unique) et l'argent du beurre (pas de soucis en 3G).

Merci pour les infos en tout cas :-)

Pour info ton script de démarrage se remplace très bien (si tu es en samba 4 sur un AD) avec un conf directe dans le profil utilisateur (tu définis le chemin du home et sur quel répertoire le monder) et le home.reg par une GPO… Mais je pense que t'es encore en domaine NT4 ça doit être pour ça non ?

Sur la redirection de dossier je sais que j'avais commencé à la mettre en place mais (que ce soit sous XP ou sous Seven), les fichiers hors connexion faisaient du flip flap continuel (toutes les 5 minutes connexion perdue puis retrouvée 5s plus tard avec fenêtre de synchro et tout) ça doit être ce que tu entends par "désactiver la synchro"… Mais du coup pépin réseau = freeze de la machine

Oui OK, c'est du même niveau que le script d'ouverture de session qui déplace le profil, c'est ce que je fais hein mais ça reste du gros bidouillage. Surtout que je vois aucune justification plausible à appeler un profil ezoi5r7f357re.default contre profile1, profile2, profile3, etc. alors que ça éviterait déjà pas mal de problème (suffit d'exclure du roaming les répertoires avec des noms prédictibles)

Et tu dis adieu à tout un tas de soft métier qui n'aiment pas le APPDATA redirigé…

Je veux bien un pointeur vers la doc en question…

De vrais outils de gestion et de mise à jour ?
Entre puppet et les GPO mon choix est fait.
Là la faute incombe entièrement à Mozilla qui fait n'importe quoi (le ticket pour les roaming profiles est ouvert depuis 2010)

Oui enfin ça reste de la bidouille hein…
Sans compter les gigas de mails que Thunderbird pousse dans le Roaming profil dans un répertoire nommé de façon aléatoire ou les bases SQLite qui atteignent plusieurs dizaines (voire centaines) de méga parce qu'apparemment elles sont jamais VACUUM.
Je le déploie sur le domaine que je gère mais je comprend très bien ceux qui ne veulent pas se faire chier, utiliser du Mozilla sur plus de 10 postes ça demande un investissement

J'ai pas bien compris l'intérêt de la signature du canary s'il suffit là aussi d'une réquisition pour avoir la clé de chiffrement

T'es au courant qu'apache fournit des libs java incontournables et qu'à l'époque du jdk 1.3 c'étaient eux qui rendaient le langage utilisable? Donc je pense pas qu'il y ait eu besoin d'un autre gugus pour évangéliser…

À une époque il y avait au moins un développeur (francophone) à plein temps sur libreoffice. Je ne sais pas si c'est toujours le cas.

C'est la même merde en nb6.
Et ne parlons pas de leur boitier tv minable ça va réveiller mon ulcère

Primo, le nom du jour est clairement visible

C'est aussi pris en charge par cron :)

Par contre je confirme sur la gestion des doublons en exécution sous systemd, ça marche bien

Je n'ai pas testé systemd comme scheduler. Mais pour moi, ce n'est certainement pas la syntaxe qui en fera un meilleur logiciel que cron. Par contre, s'il est possible gérer des dépendances entre les jobs, d'éviter qu'un script ne se lance tant qu'il est en cours d’exécution, de tuer une tâche qui prends trop de temps … là j'y trouverai un sérieux remplaçant.

Tu te rends compte que tu viens de décrire ce que fait le planificateur de tâches Windows depuis plus d'une décennie ?

Mmmm nan, tous les backups sont sur le même disque pour le CoW, mais tu peux très bien rsync depuis un autre disque (tu ne veux le CoW que d'une sauvegarde à l'autre, pas de la « prod » à la sauvegarde)

Évite de lire les petites lignes de la doc btrfs sur la fiabilité… ça fait peur :-) (je précise que ça ne m'empêche pas de l'utiliser, mais bon, de mémoire, les trucs à base de "oui oui on gère le RAID bon par contre si y a un disque qui s'en va et qui revient on le considère pas dirty" c'est un peu flippant).

J'ai eu aussi quelques freezes purs et simples du VFS sur des cas d'utilisation intensive (avec un mount -o compress et de gros fichiers d'image disque déjà en gzip, résolu en désactivant la compression uniquement sur ces fichiers).