Shuba a écrit 439 commentaires

  • [^] # Re: Conflicts=sleep.target

    Posté par  . En réponse au journal Où systemd résout des problèmes de cifs. Évalué à 2.

    Ça sent le workaround fragile.
    Conflicts est utilisé ici pour une chose dont il n'est pas fait à la base.

    J'ai eu cette impression également en écrivant mes unit, mais je n'ai pas l'impression que ça va poser des problèmes.

    Ne pas avoir prévu la gestion de la mise en veille/hibernation pour les points de montage, ça fait fausse note.

    Je trouve que ça laisse le choix. Certains points de montage n'ont pas de raison de bouger lors d'une mise en veille (disques locaux), d'autres si.

  • [^] # Re: Whaou

    Posté par  . En réponse au journal Où systemd résout des problèmes de cifs. Évalué à 6.

    J'ai surtout fait avec l'outil que j'avais sous la main, sur la plupart des distros on trouve systemd, autant apprendre à s'en servir.

    Par contre je ne connaissais pas /etc/pm/sleep.d, ça devrait me permettre de résoudre ce problème sur mon ubuntu, merci.

  • [^] # Re: btrfs

    Posté par  . En réponse au journal Marque page sur l'unification possible des systèmes Linux. Évalué à 2.

    La déduplication interne ne marche que pour le texte ou ça s'applique aussi aux données binaires?

  • [^] # Re: Premier langage? Javascript! Première plate-forme,

    Posté par  . En réponse au journal Python comme premier langage de programmation ?. Évalué à 2.

    Les réels peuvent se définir comme le plus petit espace complet comprenant les rationnels. Un espace complet c'est un espace où les suites de Cauchy convergent. Une suite de Cauchy c'est une suite dont l'écart entre deux termes d'indice supérieur à N tend vers 0 quand N tends vers l'infini.

    On peut montre que certaines suites de Cauchy n'ont pas de limite dans les rationnels, et on peut alors introduire les réels comme limite de ces suites. On peut alors redéfinir les opérations usuelles sur les réels, montrer que c'est un ensemble indénombrable, etc.

    Après ce n'est qu'une construction possible, il en existe d'autres. Pour les transcendants tu peux montrer qu'ils existent par la suite (et même que quasiment tous les réels sont transcendants).

  • [^] # Re: Foutaises !

    Posté par  . En réponse au journal La France ridiculisée par Amazon. Évalué à 5.

    Ce n'est pas parce que le coût de la main d’œuvre par vélo est négligeable devant le coût total qu'il en est de même dans tous les secteurs.
    (Au passage: tu ne regardes que le salaire, là ; si ton salaire c'est 1500€, ça ne veut pas dire que 1500€ sortent du compte en banque de la boite, c'est bien plus que ça hein! les employeurs aussi paient une bonne partie de tes cotisations)

    En ce qui concerne le SMIC il y a des allègements de charges très fort, qui font que le brut n'est pas très différent du superbrut. Selon ce site de comptabilité, le coût total d'un SMIC est de 1633€, pas très loin des 1500€ annoncés.

  • [^] # Re: Encore des pleurnichards ....

    Posté par  . En réponse au journal Que pensez-vous de cette citation de Axelle LEMAIRE ?. Évalué à 0.

    Par exemple?

  • [^] # Re: suckless !! More is less !

    Posté par  . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.

    C'est vrai, on envisage son utilisation mais on n'a pas encore tenté.

  • [^] # Re: suckless !! More is less !

    Posté par  . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 5.

    Numpy rend le calcul numérique en python acceptable, mais il ne faut pas se leurrer, dès que la boucle critique du code fait autre chose qu'une simple multiplication de matrices on sent très vite la différence. Ça peut être qu'une des matrices n'est pas constante et change à chaque itération, ce peut t'obliger à boucler sur une partie de ses valeurs en python, et ça fait tout de suite mal.

    À mon boulot on prototype en python, et ensuite on réimplémente les parties critiques en C++, et le gain est souvent un x20 voire un x100. (Les gros gains viennent souvent du fait qu'on ne passe pas non plus notre temps à optimiser le python).

  • [^] # Re: Austérité

    Posté par  . En réponse au journal Boutons les DRM hors des niches fiscales !. Évalué à 4.

    Si tu veux un impôt qui rapporte en taxant "les riches", je pense qu'il faut aller chercher du côté des impôts sur le patrimoine, avec une assiette la plus large possible (immobilier + épargne + actions + autres produits financiers - emprunts).

    Mais c'est un type d'impôt que tu ne peux pas mettre en place au niveau national car la plus grande partie de sa base imposable peut aller se faire dorer sous des cieux plus cléments.

  • [^] # Re: Hmm

    Posté par  . En réponse au journal Mozilla fait avancer le web et ajoute les DRM à Firefox. Évalué à 4.

    Surtout que je ne vois pas comment in plugin sandboxé pourrait aller contrôler le code de la sandbox. Ou alors c'est pas vraiment une sandbox qui est faite.

  • [^] # Re: Python 3.4

    Posté par  . En réponse à la dépêche Sortie d’Ubuntu 14.04 LTS. Évalué à 4.

    J'avais un peu surinterprété, je me demandais un peu où en était la transition, mais grâce à ta réponse je sais, merci :)

  • # Python 3.4

    Posté par  . En réponse à la dépêche Sortie d’Ubuntu 14.04 LTS. Évalué à 2.

    Donc, si j'ai bien compris la dépêche, c'est python 3.4 par défaut?

  • [^] # Re: fastforward

    Posté par  . En réponse au journal Lucas Nussbaum rempile comme DPL. Évalué à 6.

    J'ai pas eu le temps de

  • [^] # Re: Rust vs Go

    Posté par  . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 8.

    auto l = std::make_shared<Lapin>();

    Je trouve pas ça trop long à écrire.

  • [^] # Re: Réponse de Lennart

    Posté par  . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 0.

    Et leur dire de mettre "debug systemd.debug", c'est trop compliqué ?

    Non effectivement c'est possible, mais il faut alors que ce genre d'information se propage pour que ça devienne utile.

    Certains voulait désactiver par défaut la possibilité pour l'userspace de pourrir le buffer de log du noyau.

    Tu penses au patch qui voulait ne plus exposer "debug" sur la commandline, ou au patch sur le rate-limiting, ou à autre chose que j'ai loupé?

  • [^] # Re: Kay Sievers qu'est si vert à pourtant raison

    Posté par  . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 3.

    En l'occurence la le problème apparait avant même que syslogd ne soit lancé. Ça fait partie des grosses avancées de systemd d'ailleurs, il y a une gestion des logs dès les tout premiers instants du démarrage.

    Par contre du coup il faut être prudent et éviter de bourriner /dev/kmsg, mais le bug en question a été résolu côté systemd. Que le kernel se protège contre ce genre de problème est une bonne chose en soit, le kernel ne devant pas faire confiance à l'userspace.

  • [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

    Posté par  . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 3.

    L'option pourrait être présent uniquement dans un mode avancé par exemple, est-ce que ça serait si effrayant que ça?

    Après oui MS n'y trouverait pas de bénéfice immédiat, donc j'imagine bien qu'il ne le feront pas, mais c'est pas parce qu'il n'est pas possible de le faire sans effrayer les gens (on pourrait même imaginer une combinaison clavier précise à effectuer à un moment donné pour montrer cette option, ça ne dérangerait probablement pas les 1% qui veulent mettre un linux).

  • [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

    Posté par  . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 5.

    La plupart des installeurs de logiciels sous windows sont remplis d'options cochées par défaut, et 99% des gens n'en ont rien à faire et cliquent sans regarder. Ça pourrait être raisonnable présenté comme celà non?

  • [^] # Re: Réponse de Lennart

    Posté par  . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 1.

    Effectivement en relisant le rapport de bug le rapporteur n'est pas des plus polis, il tend à vouloir donner des ordres plutôt que des suggestions. My bad.

  • [^] # Re: Réponse de Lennart

    Posté par  . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 3.

    Et le même Greg Kroah Hartmann de tenter de calmer les ardeurs (toujours le même fil google+, mais il semblerait qu'on ne puisse pas faire de lien vers un commentaire..):

    So we have 1 bug that was already fixed, and 2 patches created out of all of this. A rather productive result in my opinion in the end. We've had worse outcomes for much crazier arguments in the past. We're growing up!

    Traduction:

    Donc nous avons un bug qui était déjà réparé, et deux patchs qui ressortent de cette discussion. A résultat plutôt productif finalement. Nous avons eu de moins bonnes conséquences sur des disputes autrement plus musclées. Nous grandissons!

  • [^] # Re: Réponse de Lennart

    Posté par  . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 2.

    À mon avis il va y avoir deux catégories de personnes voulant débugger: les gens qui effectivement s'y connaissent et ont déjà une idée de l'origine de leur problème, et là je suis d'accord avec toi ils vont ne vouloir avoir qu'un seul debug à la fois (ce qui est possible). Mais par contre d'autres seront moins versés dans la technique, auront un problème et demanderont de l'aide. On leur conseillera alors sans doute de mettre debug dans la kernel command line, et ça peut être utile d'obtenir des infos non uniquement du kernel.

    D'ailleurs si on en croit les commentaires de Linus sur le fil google+ de GKH, ça ne constitue pas vraiment le cœur du problème à la base:

    What I mind is people closing bugs and not admitting mistakes. If Kay had even said "sorry, the excessive output was a bug in systemd, it's already fixed in current -git", that would have been a valid reason to close the bug.

    Par contre le passif entre Kay et Linus (ce n'est pas la première fois que Kay ferme abruptement un bug sans plus d'explications) pousse Linus à vouloir un autre comportement par défaut afin d'éviter la récurrence de ce genre de problème:

    Side explanatory note: and it's because of that known history of abusive behavior that I would prefer systemd now use "systemd.debug".

  • # Réponse de Lennart

    Posté par  . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 5.

    Lennart Poettering a répondu sur Google+, expliquant que le flood de /dev/kmesg était corrigé côté systemd, mais qu'il pense qu'avoir du rate limiting dans le kernel serait une bonne chose.

    Cependant il insiste sur le fait que l'option debug de la ligne de commande du noyau doit être interprétée par systemd, car elle indique potentiellement l'intention d'un utilisateur de débugger son démarrage, le problème pouvant se situer au niveau du noyau ou de systemd.

    Le message a été partagé par Greg Kroah-Hartmann, ce qui a attiré une réaction énervée de Linus (il faut dire que Lennart n'est pas toujours poli dans son message), qui voit là un signe de non coopération des développeurs de systemd avec les autres projets.

    Personnelement je suis plutôt de l'avis de Lennart sur le fait que l'option debug doit permettre de débugger systemd également, mais je trouve que la situation aurait pu ne pas être problématique si un dialogue constructif s'était ouvert dès le début, en lieu et place de l'agressivité de Kay Sievers.

  • [^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd

    Posté par  . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 3.

    Pour ce genre de fonctionnalité tu peux utiliser un environnement de bureau moderne.

  • # Enregistrement vidéo en RAW et buffer

    Posté par  . En réponse au journal Magic Lantern : un projet open-source (trop?) discret. Évalué à 7.

    Hello,

    Merci pour l'info sur ce projet très intéressant. J'ai une petite question: comment l'appareil tient-il la cadence en termes de flux de données lors de l'enregistrement vidéo en RAW? J'avais lu que pour les photographies en rafale, le facteur limitant pour la longueur de la séquence était le buffer de l'appareil qui ne peux pas encaisser plus d'un quinzaine d'images en RAW à la suite. Est-ce que cette limitation n'impacte pas la vidéo également?

  • # Et donc ce prestigieux prix...

    Posté par  . En réponse au journal Et le prix Turing revient à .... Évalué à 10.

    … c'est Leslie qui Lamport.