WhiteCat a écrit 699 commentaires

  • [^] # Re: Se tenir au courant ?

    Posté par  . En réponse au journal x86 ou x86_64 ?. Évalué à 3.

    Ha ha! Dis-moi, tu te mets au niveau rédac-sensationnel de ta source là ?

    J'ai pas compris où tu voulais en venir.

  • [^] # Re: Se tenir au courant ?

    Posté par  . En réponse au journal x86 ou x86_64 ?. Évalué à 3.

    Alors que quand il lâche : « le 32bits c'est pour les débiles », ça n'apporte rien (il exprime son avis).

    C'est juste la conclusion de sa tirade contenant les explications techniques.

  • [^] # Re: Se tenir au courant ?

    Posté par  . En réponse au journal x86 ou x86_64 ?. Évalué à 6.

    Comme par hasard tu pointes vers la page des résultats qui conforte ton argumentaire.

    Hé oui j'ai voulu montrer la généralité. Regardes les benchmarks 32 vs 64 depuis 10 ans, la majorité montre des gains de performances plus ou moins significatifs en 64 bits.

    Je ne vois pas pourquoi je devrais croire le contraire juste parce qu'effectivement il y a des rares contre-exemples… Dans l'article pointé, il y'a 14 graphiques. 12 d'entre eux montrent un gain en 64 bits (parfois très important). Dans les rares cas de baisses de perf, la baisse est de toute façon infime.

    Il est fort probable qu'un binaire 32 bits compilé pour utiliser ces même instructions sera aussi voire plus performant.

    Oui mais on s'en fou. Quand tu télécharges une Ubuntu, Fedora ou ce que tu veux en 32 bits, t'auras des performances moindre que la même distrib' en 64 bits. Un point c'est tout. L'utilisateur final il s'en fou de savoir qu'il aurait des meilleures performances si un expert venait lui compiler sa distrib 32 bits avec du SSE2…

    De plus, à mon avis, ce n'est pas tant le SSE2 qui améliore les performances, mais le doublement du nombre de registres. Et là en 32 bits tu ne peux pas les utiliser quoi qu'il en soit.

  • [^] # Re: Se tenir au courant ?

    Posté par  . En réponse au journal x86 ou x86_64 ?. Évalué à 3.

    Ça te choque ?
    Donc si l'OMS, l'ANSES et ton médecin t'affirme qu'en buvant son urine on peut soigner la maria tu vas pouvoir les croire.
    Par contre si BFM TV rediffuse cette même information à une grande audience, dans ce cas les affirmations de l'OMS, l'ANSES et ton médecin ne valent plus rien et sont décrédibilisées ?!

  • [^] # Re: Se tenir au courant ?

    Posté par  . En réponse au journal x86 ou x86_64 ?. Évalué à 3.

    Il faut croire que je suis d'accord avec https://linuxfr.org/nodes/109592/comments/1666632 :-P

    Sans être un expert en zététique, il me semble qu'un argument d'autorité c'est quand on utilise une "figure" (genre Linus Torvalds) pour appuyer une opinion dans un domaine totalement différent (genre la médecine et la malaria par exemple). Je n'ai pas fais ça. Moi je cite Linus qui parle dans son domaine d'expertise.

    Pour reprendre votre analogie

    C'était pas la mienne à la base.

  • [^] # Re: Se tenir au courant ?

    Posté par  . En réponse au journal x86 ou x86_64 ?. Évalué à 8. Dernière modification le 29 juillet 2016 à 02:09.

    Les citations présentes ne constituent pas un argument, autre que « regardez, il y a des gens qui disent qu'il faut passer à x86-64 »

    Euh non, l’argument c'est plutôt « regardez, il y a un des meilleurs expert en "memory management" qui dit qu'il faut passer à x86-64, et il donne des détails techniques pour le prouver »

    Quant à boire son urine pour soigner la malaria, si c'est mon médecin du coin, l'OMS, l'ANSES, la Croix Rouge et BFM TV qui le disent, certainement que j'y croirais.

  • # Se tenir au courant ?

    Posté par  . En réponse au journal x86 ou x86_64 ?. Évalué à 10.

    Tous les CPU de PC Desktop depuis 2004-2005 sont 64 bits. Pour les portables il a fallu peut-être attendre 1 ou 2 ans de plus, ce qui nous porte à 2006-2007 peut-être.

    Certes on a rencontré pendant longtemps quelques portables ou mini-PC bas de gamme avec des Atom en 32 bits, mais bon c'est rare maintenant surtout qu'ils ne feraient même pas tourner une distribution actuelle (quand bien même en 32 bits). Je parle en connaissance de cause, je vois régulièrement tourner une CentOS 6 Desktop sur un Asus eeePC (Atom 32 bits, 1 Go de RAM), hé bien ça rame comme pas possible.

    Bref, le 64 bits (x86-64) aujourd'hui c'est la norme, c'est plus performant, les grosses distributions songent depuis des mois (voire années) à l’abandonner, le 64 bits est plus fiable (car mieux testé), d'ailleurs il y a eu une polémique à la sortie de Fedora 23 car la compil 32 bits ne fonctionnait pas.

    Pour finir quelques citations bien choisies de Linux Torvalds (et qui datent déjà de 2007…) source :

    when you hit 1GB of RAM, 32-bit virtual memory is no longer acceptable.

    .

    anybody who still thinks that "not that many people need 64-bits" is simply not aware of what he's speaking of.

    .

    PAE was a total and utter disaster. […] Yes, Linux supported it, and probably did so better than anybody else. But "better than anybody else" still wasn't very good. […] I'm not at all surprised that Windows didn't push PAE either. It was a total braindamage.

    .

    PAE didn't ever really fix anything. It was a mistake. It was just a total failure, and the result of hw engineers not understanding software.

  • [^] # Re: Bug ferme chez tmux

    Posté par  . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1.

    Non mais sérieusement, tu as lu le cas d'usage de Lennart ?

    Il est certes tiré par les cheveux, mais la conclusion de LP n'en reste pas moins logique :
    "when the user is logged out, he's really logged out. And it's completely OK if certain users get excludeded from that, but if so, then the admin needs to sign off on that, and thus a privilege check needs to be enforced."

    Effectivement je trouve normal que par défaut sur un système, quand on se déconnecte, plus aucun de mes programmes tournent. C'est juste propre et plus sécurisant pour moi et l'admin.

  • [^] # Re: Bug ferme chez tmux

    Posté par  . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 4.

    Donc ce n'est pas un problème de sécurité.

    Potentiellement si.
    Lennart Poettering explique déjà très bien ça : http://lwn.net/Articles/689509/

  • [^] # Re: Bug ferme chez tmux

    Posté par  . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 4.

    C'est un problème si powerdns-recursor écoute sur l'interface locale? Houla la… dangereux…
    Si c'est ton cas, tu filtres le port 53 avant.

    Pour powerdns-recursor j'en sais rien, je n'ai jamais utilisé, mais si j'installe un serveur httpd ou pire dhcpd, j'ai vraiment pas envie qu'il me le lance tout seul.

    Il est probable que chez Redhat, habitués à devoir utiliser chkconfig à chaque fois, ils se soient dit que Systemd allait tout résoudre…

    Je ne vois pas ce que systemd vient faire là-dedans.
    Avec RHEL6 : yum install httpd ; chkconfig httpd on
    Avec RHEL7 : yum install httpd ; systemctl enable httpd

  • [^] # Re: Bug ferme chez tmux

    Posté par  . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 3.

    Si la sécurité est un poil importante pour toi, tu as un firewall activé sur ta machine et lancer des services qui écoutent le réseau ne te posera aucun problème.

    J'arrive pas à comprendre le raisonnement, ou bien je n'ai pas compris ce que tu as voulu dire. Tu préconises de bloquer des ports pour des services qui écoutent le réseau ? Quel intérêt de faire fonctionner ces services alors ?

  • [^] # Re: Bug ferme chez tmux

    Posté par  . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 6.

    J'aime pas Redhat depuis des années, c'est pas pour rien.
    Avec Debian, on installe pdns-recursor, par exemple, il va être activé par défaut au boot, et sera lancé à la fin de l'installation.

    C'est marrant moi c'est justement une des raisons pour lesquelles je n'aime pas Debian. Je ne vois pas en quoi le fait d'installer un service signifie l'activation de ce service (qui n'aura même pas été configuré !) derrière… C’est dangereux. Moi j'active un service seulement une fois que je l'ai configuré et que je suis prêt à le mettre en route.

    Les Debianeux (-nistes?) anti-systemd sont certainement des ayatollah de la méthode KISS, mais pourtant leur gestionnaire de paquets ne l'ai pas. Pourquoi un gestionnaire de paquets active et lance des services ? C'est un gestionnaire de services alors aussi ?

  • [^] # Re: Bug ferme chez tmux

    Posté par  . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1. Dernière modification le 04 juin 2016 à 13:12.

    Systemd est un système d'initialisation/de démarrage.

    Comme son nom l'indique, systemd est bien plus qu'un système d'init. Il harmonise, améliore, simplifie et par conséquent fiabilise un gros pan du système Linux.

    Considérer que c'est normal, et même intéressant, qu'il kill les process que l'utilisateur a lancé de son propre chef, car il considère que la session est finie et donc il sait mieux que l'utilisateur ce qui doit être fait est une pente savonneuse.

    Étant donné que son rôle est de gérer les services et tout un tas d'autres choses, je ne trouve pas anormal qu'il puisse effectuer des actions sur des processus et service, tout comme le kernel peut le faire.

    Après le problème ici c'est qu'un paramètre par défaut est modifié et casse des programmes. En général un paramètre par défaut est un paramètre qui est le plus sécurisé, utile et fiable pour la majorité des utilisateurs. Est-ce que l'usage de tmux/screen est un cas d'usage de la majorité des utilisateurs ? Je ne pense pas.

    Personnellement j'ai utilisé plusieurs fois screen qui était indispensable (Mining Ethereum ou serveur Minecraft par exemple). Mais pour le reste des serveurs que je peux être amené à administrer (dans le cadre de mon taf), j'aime autant que le paramètre par défaut soit le meilleur, et que pour mes cas spécifiques d'utilisation je change le paramètre KillUserProcess à no.

  • [^] # Re: Bug ferme chez tmux

    Posté par  . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 1.

    Le kernel aussi peut se mêler du fonctionnement des programmes en les killant s'il le faut. Vraiment honteux de la part du kernel : qu'il se mèle de ses affaires à la fin !!

  • [^] # Re: lire les logs

    Posté par  . En réponse au message mod_alias redirect impossible. Évalué à 3. Dernière modification le 24 mai 2016 à 10:47.

    parce que, bon, c'est quand meme le module ALIAS que tu charges,
    pas le module REDIRECT

    La fonction "Redirect" fait partie du module "mod_alias".

    du coup ca donnerait un truc comme ca :

    Alias /testdebug.html http://www.mondomain.com/2redirige.html
    Alias /testdebug2.html http://www.mondomain.com/redirige2.html

    Ça ne peut pas fonctionner, le 2ème argument d'Alias est un chemin local, pas une URL.

  • # Plus d'infos

    Posté par  . En réponse au message Problème pour agrandir la taille de mon disque dur sur vmware.. Évalué à 2. Dernière modification le 08 mai 2016 à 03:00.

    Salut,
    Tu peux nous donner plus d'infos ?

    $ parted -l
    $ pvdisplay
    $ vgdisplay
    $ lvdisplay

  • # Buzz

    Posté par  . En réponse au message Linux Ubuntu 16.04 touché par une sérieuse faille de confidentialité. Évalué à 5. Dernière modification le 02 mai 2016 à 20:15.

    Ce genre de site n'est là que pour faire du buzz et des clics.
    Ils n'ont absolument pas compris le message de Matthew Garret. Pourtant son post de blog est très court et très clair. Mais détourner le message pour faire du buzz en disant qu'Ubuntu a une sérieuse faille de sécurité est bien plus "vendeur".

    Le message initial de Matthew Garret est le suivant :
    Canonical affirme qu'Ubuntu 16.04 est plus sécurisé grâce à snap, mais en réalité c'est trompeur et malhonnête d'affirmer cela tel quel car la sécurisation n'est effective que quand Mir est le gestionnaire graphique. Or Xorg est le gestionnaire graphique par défaut sur Ubuntu Desktop.

    Voilà.

  • [^] # Re: Pense au backup ...

    Posté par  . En réponse au message Soft RAID (mdadm) sur HP SmartArray cciss ?. Évalué à 2.

    Oui j'en suis bien conscient, c'est entre autre pour ça que je voulais privilégier le softraid :)

  • [^] # Re: Raid via hpacucli

    Posté par  . En réponse au message Soft RAID (mdadm) sur HP SmartArray cciss ?. Évalué à 2.

    Oui j'avais vu cette solution, mais au vu des commentaires que j'ai pu lire ici, ça me semble être une très mauvaise idée au final.

  • [^] # Re: Raid via hpacucli

    Posté par  . En réponse au message Soft RAID (mdadm) sur HP SmartArray cciss ?. Évalué à 2.

    Bonjour,

    Merci pour l'aide, j'ai effectivement déjà bien regardé la doc.
    Mais la commande que tu indiques va créer un RAID 5 matériel, c'est pas ce que je voulais. Dans la doc je n'ai rien trouvé pour passer le contrôleur en mode passthrough ou un truc comme ça.

    Bref comme je viens de répondre dans mon précédent commentaire, je vais effectivement devoir faire du RAID matériel de toute façon.

  • [^] # Re: le raid materiel...

    Posté par  . En réponse au message Soft RAID (mdadm) sur HP SmartArray cciss ?. Évalué à 2.

    Merci pour la piste du passthrough, ça m'a permis de constater que ce contrôleur ne permets pas d'être configuré de cette manière. Donc je vais devoir faire du RAID matériel.

  • # Le minimum

    Posté par  . En réponse au journal Quelles extensions pour votre Firefox?. Évalué à 4.

    Perso je me contente du minimum :
    - Adblock Plus
    - Clear Search 2, qui permet d'effacer automatiquement le texte dans la barre de recherche intégrée de Firefox après avoir appuyé sur "Entrée". Je suis un grand utilisateur du copie/colle "sélection/clic central molette" donc si y'a encore du texte dans la barre de recherche ça plombe tout…

  • # supprimer

    Posté par  . En réponse au message aide CUDA linux. Évalué à 1. Dernière modification le 26 février 2016 à 09:48.

    À supprimer

  • [^] # Re: Salaire

    Posté par  . En réponse au message [recrutement] L'université de Nantes recrute en CDD un administrateur système. Évalué à 1. Dernière modification le 23 février 2016 à 20:47.

    C'est un grade certes, mais y'a une 15aine d'échelons de salaire sur ce grade.

  • # Salaire

    Posté par  . En réponse au message [recrutement] L'université de Nantes recrute en CDD un administrateur système. Évalué à 4.

    Bonsoir,
    Le salaire est plutôt déjà fixé ou c'est en fonction de l'expérience du candidat ?
    Y'a une perspective d’embauche éventuelle après le CDD ?