Il n'y a pas que la fiabilité justement. Si au bout de 5 ans t'as des bruits de partout et que l'habitacle est ruiné, tu vas la lourder même si ton moteur peut faire 400.000km. Et pourtant c'est fiable.
Après moi je te donne juste le retour de roumains sur le vieillissement (qui inclus la fiabilité mais pas que) de la Logan sachant qu'ils l'ont adoptés avant nous et que la plus veille Logan en France va à peine fêter ses 7 ans.
Ne prend pas l'exemple pour l'exemple, la comparaison des deux n'a aucun sens. C'est l'idée qui est importante. Rajoute 1k à une voiture et investi le dans le temps pour la chaine de montage, t'es certain qu'elle durera plus longtemps.
Démonte des anciennes puntos pour voir ce que ca donne des montages à la va vite :p
Comme je l'ai dis, pas de photo ou de videos pour moi et les stocker sur DVD (et les distribuer) me parait à la fois économique et relativement sûr (compte tenu de la durée de vie des support, mais rien ne garanti que le service de sauvegarde soit là dans 5 ans non plus).
En gros tu parles de ce que tu ne connais pas ;)
Heu les medias optiques pour de la sauvegarde de gros volume c'est surement pas la solution:
- Durée de vie très courte (quelques années au plus)
- Taille ridicule, un DVD RW ca tient à peine 200 RAW de 5DII
- Media froid et chiant à manipuler donc tu ne vérifies jamais si tes supports sont corrompus ou non, et tu ne tests jamais la restauration. Tu ne vérifies jamais que ta tout. La misère quand tu cherches quelque chose etc.
- Sans parler de faire des backup incrementaux, de sauvegarder les fichiers liés etc.
Ca fait des années que si tu as plus de quelques GB à sauvegarder, t'as foutu les support optique à la poubelle. Si t'es pas capable de synchroniser tes sauvegarde locales à chaque fois que tu bosses, et ramener un disque externe toutes les X semaines, c'est que tu tiens pas à tes données…
Maintenant y'a les gens qui ont plein de données à sauvegarder par ce qu'ils ont plein de données à sauvegarder, et ceux qui sauvegardent plein de trucs par ce qu'ils sauvegardent plein de trucs.
Y'a des contres exemples à tout, tu enfonces des portes ouvertes…
La différence est entre l'intérêt personnel et de l'analyse automatisée. Tu peux répondre qu'on peut faire des pas sympa avec de l'analyse automatisée si tu veux en enfoncer une deuxième ;)
Mon point n'était pas celui là. C'était que tu prends l'exemple de la Logan comme simple et fiable, et si je comprends très bien ce que tu voulais dire, dans la pratique je demande confirmation sur le long terme. Actuellement on à "simple et pas cher" qui est différent de "simple et fiable". La Logan par exemple utilise de la mécanique désuette et éprouvée, mais le créneau pas cher fait aussi que l'on tire les prix vers le bas au détriment de la fiabilité de l'ensemble.
On peut discuter du reste, mais ca me semble un peu hors sujet.
La plupart du temps il suffit d'attendre un peu. Mais apparemment on est arrivé dans un monde ou la frustration de devoir attendre quelques semaines/mois pour s'acheter quelque chose de non-vital n'est plus tenable.
Il y a parfois un vrai problème comme tu le dis, c'est un fait, mais il y a aussi souvent un vrai problème de gestion et de maitrise, préférant la vision à très court terme…
une personne qui est ok pour payer 26 fois un collant à 4€ n'a pas forcément la capacité de payer un collant à 100€. Pour beaucoup de monde 100€ c'est loin d'être négligeable. Et certains sont capables de sortir quelques euros de plus par mois, mais pas forcément d'attendre pour s'acheter un collant qu'ils ne peuvent pas payer.
Comme on dit "Je n'ai pas les moyens d'acheter du pas cher". Ça ne s'applique pas à tout, mais c'est surtout pas assez appliqué…
Je n'ai jamais fait autant d'économies que depuis que j'applique ca pour tout ce qui n'est pas à usage unique, et que je paie pleins de trucs 2 à 4x plus cher que du made in China. Mais bon les gens préfère acheter de la merde à crédit, et se plaignent après de pas avoir de blé…
Tu as aussi l'effet Logan : les voitures sont devenu de plus en plus complexe pour augmenter la marge des constructeurs, alors qu'une voiture basique et fiable est possible.
A voir sur le temps. Le retour des roumains que je connais sur les Dacia (logan) c'est que ca tombe en ruine très rapidement. Assemblage à la truelle, tout l'intérieur est mort en 5 ans. Donc finalement on retombe sur du jetable.
Alors pour le côté simple et fiable de la mécanique je te suis complétement. Mais pour l'objet voiture c'est à prouver. Pas cher = montage à l'arrache avec des temps très agressifs sur les chaines = défaut à long terme. À coté de ca, tu prends un intérieur de merco/audi/bmw après 15 ans ca a pas bougé et y'a pas un bruit…
ouais, enfin ma copine s'en fout de savoir qu'un bas tient longtemps car elle en change régulièrement par effet de mode et volonté de changer.
Changer de bas par effet de mode, wahhoooooooou. T'as une idée de la durée de vie d'une paire actuelle ? Et d'ailleurs c'est bien connu, elles n'achète jamais 5x le même simplement pour survivre aux filés.
Et je pense que de nombreuses femmes font la même chose
Oui elles sont toutes contentes de foutre une paire à la poubelle après un à 5 jours d'utilisation c'est sur et certain. De toute façon ils sont déjà passé de mode…
J'ai envie de te filer des chaussettes qui dure 2 jours, voir si tu tiens le même discours.
Une grosse boite pourra analyser tes mails pour vendre de la pub et ce genre de choses mais se foutra totalement de ce qui va intéresser ton pote geek qui va lire tes mails (pour chopper tes passwords, des détails croustillants ou autre).
A toi de choisir ce que tu préfères, mais tu ne t'exposes pas vraiment aux mêmes risques dans les deux cas.
C'est exactement pour ca que tu as moins confiance dans l'admin de ta PME, que dans celui qui gère 10 000 postes et que tu n'as jamais vu.
Heu moi j'ai rien dit d'autre dans la discussion que baser un service sérieux sur un TTL DNS court pour migrer c'était pas une très bonne idée. Donc ne me classe pas dans un camp ou dans l'autre.
Maintenant si tu veux mon avis à 2 centimes sur le sujet du thread, je suis d'accord avec toi. Et c'est ce que j'utilisais quand j'auto-hébergeait mon MX il y a 10 ans. C'est fait pour, ca marche nickel, et ca répond parfaitement au besoin des auto-hébergés (et oui mon serveur est souvent tombé sans que je sois dispo pour faire quelque changement que ce soit avant des jours).
Merci de m'expliquer l'eau tiède. Maintenant bienvenue dans le monde réel ou les gens font des choses sales.
Java par exemple cache infiniment les adresses IP (cf. networkaddress.cache.ttl). Tu as aussi des dizaines d'implémentations qui ne respectent pas correctement les TTL. J'en ai encore trouvé une dans les DNS utilisés dans les clusters d'ATT qui servent à de proxy web. Il y a 3 semaines, un ingé de chez Google m'a confirmé qu'ils voyaient très régulièrement des comportements déviants, et que baser une solution sur un TTL DNS court, ca ne marche pas. Après si tu es dans un environement ou tu maitrises les services ou que tu estimes pouvoir prendre le risque c'est autre chose. Mais supposer que tout les serveurs et logiciels vont se comporter correctement c'est faux.
Mais rien ne te dis que les gens de l'internet tiendront compte de la valeur du TTL. Tu ne peux pas savoir quand ta nouvelle valeur sera propagée, les gens font des trucs sales.
Si c'est pour monter un business sur ton soft ou bosser sur ce soft dans une autre boite, je regarderais attentivement les clauses de non concurrence de mon contrat de travail.
C'est une clause assez standard de ne pas pouvoir se tirer avec la techno pour rentrer en concurrence directe avec la boite qui à financé le dev.
NdMI (Note du modérateur Inria ;-) ) : Depuis 1 an, il y a eu un changement d'identité visuelle à/chez Inria, on dit « Inria » et non « L'INRIA ». Ce journal a été corrigé.
Non seulement c'est très moche et inutilisable (bon après ce qu'ils ont pondu pour les nouveaux logos on est plus à ça près…); mais surtout de quel droit on modifie le journal de quelqu'un par ce que les termes qu'il utilise ne correspondent à ceux du parti ?
Ça ne serait pas plus convenable de faire simplement un commentaire ? Et de laisser les gens s'exprimer comme ils veulent (et garder la version prononçable si ils le souhaitent).
D'ailleurs, devrait-on dire « à Inria » ou « chez Inria » ?.
Faut pas déconner. Pour utiliser tout les jours une Fedora au travail comme à la maison depuis FC2, les upgrades et Fedora c'est à utiliser à petite dose. Tu peux upgrader 1 ou 2 fois mais vaut mieux repartir sur des bases saines régulièrement, ca pourri assez rapidement les veilles Fedora. De toute façon vu le public cible ca pause pas de problème.
Pour preupgrade je l'ai rarement vu marcher correctement. Il s'est encore vautré comme une loutre bourrée pour le passage 16 -> 17 sur une config ultra basique. Mais ca se récupère avec yum sans soucis avec un peu d'habitude.
Bref comme tu dis ne pas faire de son cas une généralité ;) Si tu veux garder un même système longtemps y'a clairement des distros qui font mieux le taff.
Cf. mon autre commentaire. Si tu fournis des binaires qui ne font que les opérations que tu veux (= chaque service gérer par policykit), et que tu tricks à mort la config de sudo tu peux arriver à quelque chose de ressemblant même si pour avoir le côté dynamique de policykit va falloir s'amuser ou patcher sudo.
Donc dans l'idée on peut le faire avec sudo. Par contre comme je le disais bon courage à celui qui va devoir gérer ce merdier par ce que ca va être exactement comme policykit, le mécanisme d'IPC propre et standard en moins.
Maintenant si on parle de l'utilisation actuelle et passée de sudo, ca se limite à lancer des GUI en root qui n'est clairement pas ce qu'on veut; ni niveau fonctionel, ni niveau sécu. Ne pas oublier qu'on ne parle pas uniquement de gérer la conf, qui n'est qu'une toute petite partie. Sur une Fedora 17 j'ai 151 services policykit déclarés. Et que le bureau à de toute facon besoin d'un bus de message pour être notifié quand quelque chose sur le système comme un nouveau périphérique qui arrive (à confirmer par un dev desktop).
Je ne doute pas que policykit apporte quelque chose de plus à cette gestion par sudo mais j'ai du mal a cerner précisément quoi …
En gros oui tu peux imaginer faire la même chose avec sudo. Il te faut un truc qui génère un sudoers dynamiquement en fonction des utilisateurs et des nouvelles opérations que tu veux obtenir. Il faut que tu fournisses un binaire par opération. Il faut que fournisses un mécanisme standard d'IPC pour communiquer avec ces processus (surement stdin/sdtout). Il faut aussi que t'arrives à wrapper tout ca simplement dans une API. Et en plus de sudo, tu voudras peut être changer tes permissions en fonction de l'état actuel de la machine.
Bref tu te retrouves à faire exactement ce que fait policykit & co en bricolant de partout.
Et surtout tu parles d'une gui qui tourne entièrement en root via consolehelper. Dans le genre taille de la surface d'attaque ca se pose là. Auditer des GUI écrites par des packageurs ou des stagiaires de Mandriva, et toute leurs deps, c'est un vrai bonheur…
Et si tu reposes sur le comportement de ifconfig Linux tout le monde va gueuler par ce que c'est pas portable. C'est sans fin.
J'ai pas regarder le côté réseau, qui à l'air bien léger, et je pense même pas que systemd implémente cette partie. Mais faut bien commencer par quelque chose non ? Si ça marche pour 90% des gens automatiquement, et que ceux qui ont besoin de plus peuvent garder l'ancienne méthode c'est un problème ? Maintenant qu'on a eu la démonstration que c'était débile on propose quoi ?
Non. Pour faire court, si tu pouvais gagner des privilèges ça n'aurait aucun intérêt, tu ne peux qu'en perdre. Or ce qui nous intéresse c'est de fournir des services à du code non privilégié.
Dans l'idée c'est très similaire à ce qu'à fait OpenSSH avec la séparation de privilège il y a 10 ans: htt://www.openbsd.org/papers/openssh-measures-asiabsdcon2007-slides.pdf Y'a du avoir un talk plus précis à un BSDCon ou USENIX à l'époque mais je retrouve pas.
La variable d’environnement TZ évidement. Et si c'était uniquement pour ca, personne n'aurait chercher une solution; les gens ne sont pas cons. Maintenant si tu veux configurer man 5 timezone ? Et toutes les autres opérations pertinentes déjà cités ? Pourquoi toujours s'arrêter sur les futilités quand on répond sur un exemple sans faire 3 paragraphes plutôt que d'avoir des discutions constructives sur le fond ?
Tu veux dire que les dev d'OpenSSH ou de Postfix sont des abrutis d'avoir fait exactement la même chose ? Ca serait vachement plus simple donc plus sûre de tout mettre dans un processus unique…
Ta variable TZ elle est toujours plus simple quand tu dois donner le mot de passe root à un utilisateur pour qu'il la change ? Comment t'écris des outils automatisés la dessus ?
Ça tombe bien, les démons dont on parle ne font absolument pas parti de systemd. Systemd n'a pas besoin d'eux, et ils n'ont pas besoin de systemd.
Les services dbus utilisent policykit pour la gestion des permissions.
Et bien entendu, le code privilégié utilise clock_settime.
En fait le seul truc qui pourraient te déranger, c'est qu'ils aient pas créer un nouveau projet pour 1000 lignes de code et qu'ils ont préféré héberger le truc quand le repo de systemd. Bon on va pas en faire un fromage.
Au vu de tes interventions, je suppose que tu as largement les capacités de lire le code. Tu devrais le faire avant de juger et d'écouter les ragots colportés.
[^] # Re: ...
Posté par ckyl . En réponse au journal Obsolescence programmé = FOUTAISE. Évalué à 3.
Il n'y a pas que la fiabilité justement. Si au bout de 5 ans t'as des bruits de partout et que l'habitacle est ruiné, tu vas la lourder même si ton moteur peut faire 400.000km. Et pourtant c'est fiable.
Après moi je te donne juste le retour de roumains sur le vieillissement (qui inclus la fiabilité mais pas que) de la Logan sachant qu'ils l'ont adoptés avant nous et que la plus veille Logan en France va à peine fêter ses 7 ans.
Ne prend pas l'exemple pour l'exemple, la comparaison des deux n'a aucun sens. C'est l'idée qui est importante. Rajoute 1k à une voiture et investi le dans le temps pour la chaine de montage, t'es certain qu'elle durera plus longtemps.
Démonte des anciennes puntos pour voir ce que ca donne des montages à la va vite :p
[^] # Re: Trop de sauvegarde?
Posté par ckyl . En réponse à la dépêche (R)évolutions dans le monde de la sauvegarde de données. Évalué à 6.
En gros tu parles de ce que tu ne connais pas ;)
Heu les medias optiques pour de la sauvegarde de gros volume c'est surement pas la solution:
- Durée de vie très courte (quelques années au plus)
- Taille ridicule, un DVD RW ca tient à peine 200 RAW de 5DII
- Media froid et chiant à manipuler donc tu ne vérifies jamais si tes supports sont corrompus ou non, et tu ne tests jamais la restauration. Tu ne vérifies jamais que ta tout. La misère quand tu cherches quelque chose etc.
- Sans parler de faire des backup incrementaux, de sauvegarder les fichiers liés etc.
Ca fait des années que si tu as plus de quelques GB à sauvegarder, t'as foutu les support optique à la poubelle. Si t'es pas capable de synchroniser tes sauvegarde locales à chaque fois que tu bosses, et ramener un disque externe toutes les X semaines, c'est que tu tiens pas à tes données…
Maintenant y'a les gens qui ont plein de données à sauvegarder par ce qu'ils ont plein de données à sauvegarder, et ceux qui sauvegardent plein de trucs par ce qu'ils sauvegardent plein de trucs.
[^] # Re: Ce que je constate
Posté par ckyl . En réponse au journal RFC 6647: Email Greylisting: An Applicability Statement for SMTP. Évalué à 2.
Y'a des contres exemples à tout, tu enfonces des portes ouvertes…
La différence est entre l'intérêt personnel et de l'analyse automatisée. Tu peux répondre qu'on peut faire des pas sympa avec de l'analyse automatisée si tu veux en enfoncer une deuxième ;)
[^] # Re: ...
Posté par ckyl . En réponse au journal Obsolescence programmé = FOUTAISE. Évalué à 2.
Mon point n'était pas celui là. C'était que tu prends l'exemple de la Logan comme simple et fiable, et si je comprends très bien ce que tu voulais dire, dans la pratique je demande confirmation sur le long terme. Actuellement on à "simple et pas cher" qui est différent de "simple et fiable". La Logan par exemple utilise de la mécanique désuette et éprouvée, mais le créneau pas cher fait aussi que l'on tire les prix vers le bas au détriment de la fiabilité de l'ensemble.
On peut discuter du reste, mais ca me semble un peu hors sujet.
[^] # Re: La vérité est tailleur
Posté par ckyl . En réponse au journal Obsolescence programmé = FOUTAISE. Évalué à 3.
La plupart du temps il suffit d'attendre un peu. Mais apparemment on est arrivé dans un monde ou la frustration de devoir attendre quelques semaines/mois pour s'acheter quelque chose de non-vital n'est plus tenable.
Il y a parfois un vrai problème comme tu le dis, c'est un fait, mais il y a aussi souvent un vrai problème de gestion et de maitrise, préférant la vision à très court terme…
[^] # Re: La vérité est tailleur
Posté par ckyl . En réponse au journal Obsolescence programmé = FOUTAISE. Évalué à 2.
Comme on dit "Je n'ai pas les moyens d'acheter du pas cher". Ça ne s'applique pas à tout, mais c'est surtout pas assez appliqué…
Je n'ai jamais fait autant d'économies que depuis que j'applique ca pour tout ce qui n'est pas à usage unique, et que je paie pleins de trucs 2 à 4x plus cher que du made in China. Mais bon les gens préfère acheter de la merde à crédit, et se plaignent après de pas avoir de blé…
[^] # Re: ...
Posté par ckyl . En réponse au journal Obsolescence programmé = FOUTAISE. Évalué à 2.
A voir sur le temps. Le retour des roumains que je connais sur les Dacia (logan) c'est que ca tombe en ruine très rapidement. Assemblage à la truelle, tout l'intérieur est mort en 5 ans. Donc finalement on retombe sur du jetable.
Alors pour le côté simple et fiable de la mécanique je te suis complétement. Mais pour l'objet voiture c'est à prouver. Pas cher = montage à l'arrache avec des temps très agressifs sur les chaines = défaut à long terme. À coté de ca, tu prends un intérieur de merco/audi/bmw après 15 ans ca a pas bougé et y'a pas un bruit…
[^] # Re: Foutaise ? Pas pour tous les produits !
Posté par ckyl . En réponse au journal Obsolescence programmé = FOUTAISE. Évalué à 3.
Changer de bas par effet de mode, wahhoooooooou. T'as une idée de la durée de vie d'une paire actuelle ? Et d'ailleurs c'est bien connu, elles n'achète jamais 5x le même simplement pour survivre aux filés.
Oui elles sont toutes contentes de foutre une paire à la poubelle après un à 5 jours d'utilisation c'est sur et certain. De toute façon ils sont déjà passé de mode…
J'ai envie de te filer des chaussettes qui dure 2 jours, voir si tu tiens le même discours.
[^] # Re: Ah ah ! Bien essayé !
Posté par ckyl . En réponse au journal Obsolescence programmé = FOUTAISE. Évalué à 5.
Et tes claviers ?
[^] # Re: Ce que je constate
Posté par ckyl . En réponse au journal RFC 6647: Email Greylisting: An Applicability Statement for SMTP. Évalué à 6.
Une grosse boite pourra analyser tes mails pour vendre de la pub et ce genre de choses mais se foutra totalement de ce qui va intéresser ton pote geek qui va lire tes mails (pour chopper tes passwords, des détails croustillants ou autre).
A toi de choisir ce que tu préfères, mais tu ne t'exposes pas vraiment aux mêmes risques dans les deux cas.
C'est exactement pour ca que tu as moins confiance dans l'admin de ta PME, que dans celui qui gère 10 000 postes et que tu n'as jamais vu.
[^] # Re: Il faut toutefois un gros travail d'information
Posté par ckyl . En réponse au journal RFC 6647: Email Greylisting: An Applicability Statement for SMTP. Évalué à 4.
Bha si, il suffit de déployer Lotus Notes ! Les gens vont très vite comprendre.
[^] # Re: Ce que je constate
Posté par ckyl . En réponse au journal RFC 6647: Email Greylisting: An Applicability Statement for SMTP. Évalué à 2.
Heu moi j'ai rien dit d'autre dans la discussion que baser un service sérieux sur un TTL DNS court pour migrer c'était pas une très bonne idée. Donc ne me classe pas dans un camp ou dans l'autre.
Maintenant si tu veux mon avis à 2 centimes sur le sujet du thread, je suis d'accord avec toi. Et c'est ce que j'utilisais quand j'auto-hébergeait mon MX il y a 10 ans. C'est fait pour, ca marche nickel, et ca répond parfaitement au besoin des auto-hébergés (et oui mon serveur est souvent tombé sans que je sois dispo pour faire quelque changement que ce soit avant des jours).
[^] # Re: Ce que je constate
Posté par ckyl . En réponse au journal RFC 6647: Email Greylisting: An Applicability Statement for SMTP. Évalué à 2.
Merci de m'expliquer l'eau tiède. Maintenant bienvenue dans le monde réel ou les gens font des choses sales.
Java par exemple cache infiniment les adresses IP (cf.
networkaddress.cache.ttl). Tu as aussi des dizaines d'implémentations qui ne respectent pas correctement les TTL. J'en ai encore trouvé une dans les DNS utilisés dans les clusters d'ATT qui servent à de proxy web. Il y a 3 semaines, un ingé de chez Google m'a confirmé qu'ils voyaient très régulièrement des comportements déviants, et que baser une solution sur un TTL DNS court, ca ne marche pas. Après si tu es dans un environement ou tu maitrises les services ou que tu estimes pouvoir prendre le risque c'est autre chose. Mais supposer que tout les serveurs et logiciels vont se comporter correctement c'est faux.[^] # Re: Ce que je constate
Posté par ckyl . En réponse au journal RFC 6647: Email Greylisting: An Applicability Statement for SMTP. Évalué à 2.
Mais rien ne te dis que les gens de l'internet tiendront compte de la valeur du TTL. Tu ne peux pas savoir quand ta nouvelle valeur sera propagée, les gens font des trucs sales.
[^] # Re: fork !
Posté par ckyl . En réponse au journal Relations entre projet libre et entreprise. Évalué à 3.
Si c'est pour monter un business sur ton soft ou bosser sur ce soft dans une autre boite, je regarderais attentivement les clauses de non concurrence de mon contrat de travail.
C'est une clause assez standard de ne pas pouvoir se tirer avec la techno pour rentrer en concurrence directe avec la boite qui à financé le dev.
# NdM...
Posté par ckyl . En réponse au journal Ma participation au concours BoostYourCode 2012. Évalué à 5.
Non seulement c'est très moche et inutilisable (bon après ce qu'ils ont pondu pour les nouveaux logos on est plus à ça près…); mais surtout de quel droit on modifie le journal de quelqu'un par ce que les termes qu'il utilise ne correspondent à ceux du parti ?
Ça ne serait pas plus convenable de faire simplement un commentaire ? Et de laisser les gens s'exprimer comme ils veulent (et garder la version prononçable si ils le souhaitent).
Ca valait le coup de changer un journal…
[^] # Re: Mandriva et Mageia
Posté par ckyl . En réponse au sondage Quelle distribution de logiciels libres installez-vous aux copains non geeks?. Évalué à 3.
Faut pas déconner. Pour utiliser tout les jours une Fedora au travail comme à la maison depuis FC2, les upgrades et Fedora c'est à utiliser à petite dose. Tu peux upgrader 1 ou 2 fois mais vaut mieux repartir sur des bases saines régulièrement, ca pourri assez rapidement les veilles Fedora. De toute façon vu le public cible ca pause pas de problème.
Pour preupgrade je l'ai rarement vu marcher correctement. Il s'est encore vautré comme une loutre bourrée pour le passage 16 -> 17 sur une config ultra basique. Mais ca se récupère avec yum sans soucis avec un peu d'habitude.
Bref comme tu dis ne pas faire de son cas une généralité ;) Si tu veux garder un même système longtemps y'a clairement des distros qui font mieux le taff.
[^] # Re: Irrémédiable
Posté par ckyl . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 4.
Cf. mon autre commentaire. Si tu fournis des binaires qui ne font que les opérations que tu veux (= chaque service gérer par policykit), et que tu tricks à mort la config de sudo tu peux arriver à quelque chose de ressemblant même si pour avoir le côté dynamique de policykit va falloir s'amuser ou patcher sudo.
Donc dans l'idée on peut le faire avec sudo. Par contre comme je le disais bon courage à celui qui va devoir gérer ce merdier par ce que ca va être exactement comme policykit, le mécanisme d'IPC propre et standard en moins.
Maintenant si on parle de l'utilisation actuelle et passée de sudo, ca se limite à lancer des GUI en root qui n'est clairement pas ce qu'on veut; ni niveau fonctionel, ni niveau sécu. Ne pas oublier qu'on ne parle pas uniquement de gérer la conf, qui n'est qu'une toute petite partie. Sur une Fedora 17 j'ai 151 services policykit déclarés. Et que le bureau à de toute facon besoin d'un bus de message pour être notifié quand quelque chose sur le système comme un nouveau périphérique qui arrive (à confirmer par un dev desktop).
[^] # Re: Irrémédiable
Posté par ckyl . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 7.
En gros oui tu peux imaginer faire la même chose avec sudo. Il te faut un truc qui génère un sudoers dynamiquement en fonction des utilisateurs et des nouvelles opérations que tu veux obtenir. Il faut que tu fournisses un binaire par opération. Il faut que fournisses un mécanisme standard d'IPC pour communiquer avec ces processus (surement stdin/sdtout). Il faut aussi que t'arrives à wrapper tout ca simplement dans une API. Et en plus de sudo, tu voudras peut être changer tes permissions en fonction de l'état actuel de la machine.
Bref tu te retrouves à faire exactement ce que fait policykit & co en bricolant de partout.
[^] # Re: Irrémédiable
Posté par ckyl . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 7. Dernière modification le 14 juin 2012 à 14:24.
Et surtout tu parles d'une gui qui tourne entièrement en root via consolehelper. Dans le genre taille de la surface d'attaque ca se pose là. Auditer des GUI écrites par des packageurs ou des stagiaires de Mandriva, et toute leurs deps, c'est un vrai bonheur…
[^] # Re: Irrémédiable
Posté par ckyl . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 0.
Et si tu reposes sur le comportement de ifconfig Linux tout le monde va gueuler par ce que c'est pas portable. C'est sans fin.
J'ai pas regarder le côté réseau, qui à l'air bien léger, et je pense même pas que systemd implémente cette partie. Mais faut bien commencer par quelque chose non ? Si ça marche pour 90% des gens automatiquement, et que ceux qui ont besoin de plus peuvent garder l'ancienne méthode c'est un problème ? Maintenant qu'on a eu la démonstration que c'était débile on propose quoi ?
[^] # Re: Irrémédiable
Posté par ckyl . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 5.
Non. Pour faire court, si tu pouvais gagner des privilèges ça n'aurait aucun intérêt, tu ne peux qu'en perdre. Or ce qui nous intéresse c'est de fournir des services à du code non privilégié.
Dans l'idée c'est très similaire à ce qu'à fait OpenSSH avec la séparation de privilège il y a 10 ans: htt://www.openbsd.org/papers/openssh-measures-asiabsdcon2007-slides.pdf Y'a du avoir un talk plus précis à un BSDCon ou USENIX à l'époque mais je retrouve pas.
[^] # Re: Irrémédiable
Posté par ckyl . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 2.
La variable d’environnement TZ évidement. Et si c'était uniquement pour ca, personne n'aurait chercher une solution; les gens ne sont pas cons. Maintenant si tu veux configurer man 5 timezone ? Et toutes les autres opérations pertinentes déjà cités ? Pourquoi toujours s'arrêter sur les futilités quand on répond sur un exemple sans faire 3 paragraphes plutôt que d'avoir des discutions constructives sur le fond ?
[^] # Re: Irrémédiable
Posté par ckyl . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 2.
Tu veux dire que les dev d'OpenSSH ou de Postfix sont des abrutis d'avoir fait exactement la même chose ? Ca serait vachement plus simple donc plus sûre de tout mettre dans un processus unique…
Ta variable TZ elle est toujours plus simple quand tu dois donner le mot de passe root à un utilisateur pour qu'il la change ? Comment t'écris des outils automatisés la dessus ?
[^] # Re: Irrémédiable
Posté par ckyl . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 8.
Ça tombe bien, les démons dont on parle ne font absolument pas parti de systemd. Systemd n'a pas besoin d'eux, et ils n'ont pas besoin de systemd.
Les services dbus utilisent policykit pour la gestion des permissions.
Et bien entendu, le code privilégié utilise clock_settime.
En fait le seul truc qui pourraient te déranger, c'est qu'ils aient pas créer un nouveau projet pour 1000 lignes de code et qu'ils ont préféré héberger le truc quand le repo de systemd. Bon on va pas en faire un fromage.
Au vu de tes interventions, je suppose que tu as largement les capacités de lire le code. Tu devrais le faire avant de juger et d'écouter les ragots colportés.