gaaaaaAab a écrit 1401 commentaires

  • [^] # Re: Bonsoir

    Posté par  . En réponse au message [Coup de gueule] La soi-disant “offre” de NVidia. Évalué à 3.

    la faute des gros studios qui n'ont pas porté leurs jeux pour SteamOS et qui ont pas mal coupé l'élan des indés.

    C'est vrai que beaucoup de gros studios ne portent pas. Il y a quand même quelques double ou triple A dispos sous Linux (Middle-Earth: Shadow of Mordor, Mad Max, Total War: Warhammer, Alien Isolation, Civilisation V, VI et Beyond Earth, les Borderlands, stellaris). A mon avis, ceux qui ont fait le travail pour faire du code portable n'ont pas vraiment de raison d'arrêter de cibler Linux, mais c'est à surveiller.

    Côté indé, je n'ai pas l'impression que ça se tarisse vraiment. Juste pour des titres récents, Pyre, Cryptark, Hollow knight, flinthook. Bon, je m'arrête là, mais ma liste steam contient plus de 50% de jeux qui tournent sous Linux, ce qui était très loin d'être le cas il y a quelques années. Ok, il y en a quelques uns qui sont des portages foireux, et vu qu'il y a quelques clefs qui viennent de humblebundle, ils sont pas forcément tous très bons. Mais je peux faire une liste de quelques dizaines de très bons jeux sous Linux sans forcer.

    Même si Vulkan est utilisé, beaucoup ne vont pas considérer le portage comme intéressant financièrement

    Quand tous les moteurs 3D du marché utiliseront Vulkan et seront portés sous Linux (si ce n'est pas déjà le cas pour les plus répandu), ça réduira très sensiblement le coût du portage. A voir si les éditeurs et si le marché suivront.

  • [^] # Re: forum/journaux

    Posté par  . En réponse au message [Coup de gueule] La soi-disant “offre” de NVidia. Évalué à 2.

    oui, le "m'est avis que" était très bien ! C'est les deux phrases suivantes au présent de l'indicatif qui m'ont fait tiquer ;-)

  • # questions ?

    Posté par  . En réponse au message Offre d'emploi CDI - Analyste Programmeur Chef de Projet - Narbonne. Évalué à 10.

    les visiteurs réguliers de linuxfr apprécient que les offres d'emploi précisent le salaire proposé (ou au moins une fourchette). Une façon probablement plus juste de le formuler, c'est que les offres qui n'incluent pas le salaire ont tendance à se faire défoncer. À bon entendeur !

    A la lecture de l'annonce, j'ai l'impression de voir la description de profil et de mission ultra standards, calibré SSII … pas très excitant. Et aussi, on est sur linuxfr, alors bon, comme la seule mention d'OS dans l'annonce, c'est Windows, c'est un peu mal barré.

  • # pétition pour l'ouverture de la techno par Adobe

    Posté par  . En réponse au journal Bookmark: mort de flash officiellement planifiée?. Évalué à 5.

  • [^] # Re: forum/journaux

    Posté par  . En réponse au message [Coup de gueule] La soi-disant “offre” de NVidia. Évalué à 3.

    Pour montrer que ça leur coûte pas trop cher, il suffit de poser une limite haute pas très élevée. Il n'est pas nécessaire de connaître le prix exact. Ça pourrait être zéro, mais je n'en sais rien.

    Petite remarque formelle, tu présentes ça comme si c'était quasi une certitude que ça ne leur coûte rien, et comme si le principe de l'accord gagnant/gagnant allait de soi. Ça ne me paraît pas si certain que ça. Est-ce qu'un jeu qui a été un immense succès commercial a vraiment besoin de pub deux ans après sa sortie ? L'auteur de l'entrée dans le forum indique que l'activation de la clef est soumise à installation d'un soft proprio de Nvidia. Du coup, est-ce qu'appâter le poisson est vraiment la motivation première de Nvidia ? Questions non rhétoriques, je n'ai pas la réponse. Mais, à moins que tu ne puisses apporter des éléments supplémentaires, je présume que toi non plus.

    ps: je prends la peine de relever parce que j'ai souvent été coupable de présumer des trucs qui me paraissaient logique sans vraiment me poser de questions sur la réalité factuelle. Je précise que l'hypothèse que tu proposes me parait tout à fait plausible, et je suis tout à fait prêt à l'accepter. Il faut juste des éléments qui soient plus que de la simple supposition.

    pps: à l'oral, je le dirais plus détendu. Pour être clair, l'écrit nécessite d'être un peu formel pour être compris, et donc mon commentaire paraît probablement beaucoup plus sévère que ce que je pense vraiment :-)

  • # forum/journaux

    Posté par  . En réponse au message [Coup de gueule] La soi-disant “offre” de NVidia. Évalué à 4.

    Déjà, bienvenu !

    le forum général.général ne parait pas contre indiqué. Après, ça aurait aussi pu être un journal (les journaux ont plus de visibilité je crois).

    Je ne sais pas si vous avez eu des expériences de ce genre,

    Oh ben oui. En informatique, ça ne m'arrive plus tellement, parce que je vérifie avant d'acheter que le truc me va. Le problème dans ton cas, c'est surtout l'absence de présentation claire des conditions pour profiter de l'offre. A ta place, j'aurais retourné la carte et exigé le remboursement. Ça ne t'a pas tenté ?

    Les "gestes commerciaux" de NVidia ne valent pas grand' chose.

    ah ça, c'est sûr. Rocket league, c'est 20€ (p-e 12 ou 15 en solde) TTC, et nvidia, en dehors du fait qu'ils récupèrent la TVA, ne le paye probablement pas au prix public.

  • # ls et/ou #, et les yeux

    Posté par  . En réponse au message Comment éviter d'effacer des fichiers avec rm *. Évalué à 3.

    Quand je fais des rm un peu longs avec plusieurs cibles, j'ai tendance à commencer par faire un ls, et rappeler la ligne et l'éditer pour remplacer ls par rm quand je suis sûr que c'est bon. Quand j'ai moins de cibles ou que c'est moins risqué, ça m'arrive aussi de taper #rm …, ça permet de se protéger contre les appuis intempestifs sur la touche Entrée en cours d'écriture de la ligne.
    Dans tous les cas, une fois que j'ai tapé ma ligne, je relis systématiquement une commande rm avant de la valider.

  • [^] # Re: 3 ans ?

    Posté par  . En réponse au journal Devuan Jessie 1.0. Évalué à 4.

    je pointais juste le fait qu'en jugeant la pertinence d'une solution technique sur le fait de savoir si ça correspond plus ou moins à ton usage, tu reproduis le type de critique qui pouvait porter sur le logiciel libre à ses débuts (et c'est toujours d'actualité dans certains domaines). Pourquoi s'emmerder avec une logiciel de retouche de photos moins bien que Photoshop ? ben parce que c'est libre. Si tu n'es pas sensibilisé au libre, tu t'en fous. Je pense que c'est une bonne leçon à retenir, et qu'il faut essayer d'éviter de reproduire les attitudes auxquelles la communauté a eu à faire face il y a quelques années.

    Je ne dis pas que ce n'est pas vrai que sysv est "moins bon" que systemd. Y a du pour et du contre pour chaque solution, et chacun à sa grille d'évaluation de ce qui compte.

    Dans une optique de démocratisation de Linux pour le desktop,

    il y a effectivement d'autres optiques. Tu vois qu'en fait, tu arrives peut-être à entrevoir une justification que pourrait avoir une distribution comme devuan ;)

  • [^] # Re: 3 ans ?

    Posté par  . En réponse au journal Devuan Jessie 1.0. Évalué à -1.

    Je suis pour avoir le choix, mais donner des choix techniquement "moins bons" que ce qu'on nous propose, c'est quand même un comble non ?

    On pourrait transposer cette phrase en changeant un peu le contexte. Par exemple Open Office serait sysv, et MS Office serait systemd, ou alors FreeBSD serait sysv et MacOs serait systemd, ou autre. Cherchez pas trop derrière les exemples, y a pas d'intention de troller de ma part. Ce sont des exemples qui, je pense, lèvent un léger doute sur la pertinence de ta question, ou donnent un élément de réponse :-)

  • [^] # Re: Confidentiel => pas de GMail, Dropbox et consort

    Posté par  . En réponse au message Confidentialité des communications professionnelles et utilisation de Gmail. Évalué à 5.

    0ui. Et pendant ce temps, pleins de boites migrent tout leur SI dans le Claude …

  • [^] # Re: je dirais que non

    Posté par  . En réponse au message Confidentialité des communications professionnelles et utilisation de Gmail. Évalué à 2. Dernière modification le 16 mai 2017 à 14:55.

    c'est vrai que tu vas accéder à tes e-mails en clair sur gmail dans une connexion sécurisée en HTTPS, mais il y a aussi le transfert en SMTP entre l'expéditeur et la boite mail. Et c'est à ça que je pensais en parlant d'envoi en clair. J'aurais pu être plus précis.
    Du coup, je me rend compte qu'il y a SMTPS, mais je n'ai pas l'impression que ça soit très répandu. Et puis une fois que tu t'es connecté à ton serveur SMTP en ssl, tu n'as pas la garantie que l'échange entre le serveur SMTP que tu a joins et le serveur d'email de destination sera aussi encapsulé dans une canal sécurisé.

    Donc oui, dans un contexte pro, dès qu'il y a une tierce partie, perso, je ferais du GPG.

  • [^] # Re: je dirais que non

    Posté par  . En réponse au message Confidentialité des communications professionnelles et utilisation de Gmail. Évalué à 4.

    Je ne l'ai pas précisé dans mon premier commentaire, mais c'est sûr que limiter le nombre d'intermédiaires réduit la surface d'attaque, dont il faudrait éviter autant que possible. Après, il faut trouver le compromis entre sécurité et utilisabilité.

    A titre personnel, dans un cas similaire, je n'utiliserais qu'une boite pro sans redirection, sous réserve d'avoir un accès à distance au serveur de mail (que ça soit en imaps depuis une ip public ou sur un VPN). Ou alors, si le serveur e-mail est opéré par le client et est difficilement accessible, sur un serveur de mail opéré par ta boite avec imaps/vpn. Je ne ferais pas le compromis d'utilisabilité que tu décris avec un fournisseur d'e-mail tierce à la gmail, mais je veux bien admettre que je suis un peu plus parano que la moyenne :-)

    d'un point de vue légal/contractuel, je ne sais pas - et c'est ce que je cherche à identifier.

    alors demande à un juriste, parce que demander çà à linuxfr, c'est l'équivalent de demander un avis médical à doctissimo :-)

  • # je dirais que non

    Posté par  . En réponse au message Confidentialité des communications professionnelles et utilisation de Gmail. Évalué à 4.

    Je suis preneur de vos retours par rapport à cette problématique, en particulier des retours d'expériences réelles.

    je suis un peu à côté, vu que ceci n'est pas un retour d'expérience réelle, ni l'avis d'un juriste.

    est-ce que le fait d'utiliser un service externe pour gérer des données confidentielles peut être problématique ?

    si les informations transitent en clair par e-mail, la question du prestataire fournissant la boite e-mail parait assez accessoire. Et si les infos sont chiffrées, le fait que ça soit gmail ou un autre est sans incidence.

    Pour le dire autrement, dans une situation analogue, je ne m'autoriserais une redirection de ce type que si elle n'est pas strictement inférieure à tous les chaînons intermédiaires en terme de confidentialité.

  • [^] # Re: petit complément

    Posté par  . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 5.

    Ta remarque n'est pas sans mérite, mais je ne pense pas qu'elle se tranche aussi définitivement que ce que tu sembles penser.

    C'est une grande question de l'éducation. Enseigner des outils directement utilisables professionnellement, ou utiliser des outils moins directement utilisables, mais plus pédagogiques, pour aboutir à une meilleure compréhension de la matière.

    En prépa et école d'ingé d'info (au passage, programmeur et ingénieur, c'est pas incompatible), j'ai fait un peu de programmation fonctionnel (ocaml et lisp). Jusqu'à présent, je ne m'en suis pas servi professionnellement, mais je suis content d'y avoir été exposé pendant mes études.

    En enseignant le python, en ne gardant que le paradigme procédural, si vous voulez.

    J'imagine que c'était un exemple vite fait d'une piste que t'as pas trop creusé. Je relève juste parce que ça me parait être une mauvaise idée d'enseigner le Python en se restreignant au paradigme procédural. Ça ferait des très mauvais développeurs Python.

  • [^] # Re: Légendaires?

    Posté par  . En réponse au journal Jouer sous GNU/Linux : la série des Shadowrun. Évalué à 8.

    et des trolls sur linuxfr ;-)

  • [^] # Re: léger HS: coquille sur C++ (et C++!=C)

    Posté par  . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 2.

    je suis allé regarder le man de g++. Effectivement, -permissive permet de compiler du code non conforme. Donc, un point pour toi, et je suis surpris :-) Je ne dirais donc plus que C est un sous-ensemble de C++.

  • [^] # Re: léger HS: coquille sur C++ (et C++!=C)

    Posté par  . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 2.

    Ça peut avoir du sens de regrouper C et C++ dans certains contextes.

    Ça m'étonnerait un peu si c'était pas du C++ valide, parce que il me semble que la compatibilité avec le C était un principe très significatif lors de la conception du C++.
    Mais comme je pratique pas beaucoup le C++, je ne sais pas trop. En tout cas, avec le drapeau -fpermissive, g++ considère que c'est un warning, et accepte de compiler.

  • [^] # Re: léger HS: coquille sur C++ (et C++!=C)

    Posté par  . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 2.

    bien vu !
    Je me suis arrêté à "le compilo donne le même warning pour les deux", mais c'est vrai que ça ne suffit pas.
    Cela dit, même entre deux versions d'un seul compilateur sur un seul langage, on pourrait aussi avoir des comportements différents (surtout sur des comportements non définis).
    Dans l'absolu, il faudrait en fait préciser le couple (langage, compilo) pour chaque exemple, mais ça devient vite vachement moins facile à appréhender.

  • # léger HS: coquille sur C++ (et C++!=C)

    Posté par  . En réponse au journal Un décalage de 64 bits, ça vous inspire comment ?. Évalué à 7.

    Sur le fond du journal, c'est un détail, mais si le C est du C++ valide, le contraire n'est pas vrai. Pour avoir un exemple en C/C++, il aurait fallu préférer une version en C avec du bon vieux stdio.h et du printf :-)

    Avec la suite gcc/g++ 6.3, le warning est identique en C (ce qui n'est pas du tout surprenant).

    sinon, dans cette exemple, tu as écrit un décalage à gauche au lieu d'un décalage à droite (j'imagine que tu t'es laissé embarquer par l'opérateur du cout)

  • [^] # Re: Hum, ça donne envie

    Posté par  . En réponse au journal Jeu sous GNU/Linux : The Talos Principle. Évalué à 2.

    J'avais vu passer SEUM, mais je n'ai pas pris le temps de regarder de près. Pour moi, c'est vraiment la qualité du level design qui fait la richesse de Deadcore. Mais, trop se renseigner avant sur ce que ce genre de jeu propose en la matière, ça peut casser un peu le plaisir de la découverte des niveaux. Cela-dit, tu fais bien de me remettre SEUM en tête, je vais creuser un peu, ça peut effectivement me plaire !

    Oui. Je n'ai pas retenu shadowrun. D'une part parce que je ne voulais faire une liste de plusieurs dizaines de titre. Et aussi parce qu'au delà des aspects RPG (progression, quêtes) et du thème (cyberpunk) qui contribuent à rendre ces jeux sympas, je trouve les mécaniques de combat moins riches et moins profondes que les deux que j'ai cité.
    Je n'avais pas fini shadowrun returns, mais dragonfall était incontestablement meilleur, et j'ai bien apprécié hong-kong aussi.

    Après, les goûts et les couleurs toussa ;-)

  • [^] # Re: Hum, ça donne envie

    Posté par  . En réponse au journal Jeu sous GNU/Linux : The Talos Principle. Évalué à 3.

    j'ai aussi bien aimé the Talos principle.

    il y a aussi d'autres bons jeux indés. Je me restreins volontairement à une poignée. Liste évidemment subjective, et contenant des titres vraiment de niche. Si ça vous fait de l'oeil, renseignez vous un peu pour voir si ça peut vous plaire (en dehors du fait qu'un seul de cette liste soit libre). Je met des "genre" pour donner une idée, mais ça correspond objectivement pas à grand chose.

    • tactique tour par tour : darkest dungeon et invisible Inc (y'en a deux, c'est mon genre de prédilection)
    • super hexagon : open hexagon : clone libre de super hexagon
    • platforme FPS : deadcore (assez orienté speedrun, par un studio français)
    • twin stick shooter : the binding of isaac
    • shmup : steredenn (parce que j'aime la bande son, la direction artistique, le gameplay, et par un studio français aussi)
    • WTF: The Stanley Parable

    et j'ai envie de citer sunless sea pour l'ambiance lovecraftienne. mais je pense que les mécaniques de jeu ne plairont pas à tout le monde. En tout cas, la première fois, je n'ai pas trop accroché. Et c'est seulement en lui redonnant sa chance un an plus tard que je me suis vraiment plongé dedans.

  • [^] # Re: port salut, c'est marqué dessus.

    Posté par  . En réponse au message Déployer une application Django avec apache et mod_wsgi. Évalué à 3.

    en gros apache n'attend pas assez longtemps que ton process wsgi.py renvoie ses reponses
    soit faut que ton python tourne plus vite, soit qu'apache soit plus patient

    pas forcément. apache attend des données sur la sortie standard du process fils. Si apache n'a pas de réponse, ça peut aussi être parce que le fils s'est vautré, ou ne produit pas une sortie au format attendu par apache (manque de saut de ligne après les en-tête http, lignes de log du process redirigées vers la sortie standard, …). Et bien sûr, ça peut être que le traitement est trop long comme tu le mentionnes.

    Le fait qu'il y ait des messages d'erreur différents selon les cas, ça pourrait aussi être que le process fils renvoie du junk, mais que de temps en temps, ça ressemble suffisamment à ce qu'apache attend pour qu'il lise une taille random (et du coup, ça marche pas).

    Ça serait intéressant de voir le détail de ce que le process wsgi produit comme sortie.

  • # Python(s)

    Posté par  . En réponse au journal Cohérence des fonctions d'arrondi. Évalué à 10.

    En passant, Python2 renvoie -1, mais Python3 renvoie 0

  • [^] # Re: sort tout seul

    Posté par  . En réponse au message Ne garder qu'une seule occurrence de chaque ligne d'un fichier. Évalué à 6.

    Histoire de pinailler un peu, les deux commandes sont fonctionnellement équivalentes, mais à choisir, je prendrais toujours le "sort -u". Il me parait préférable d'utiliser une seule commande au lieu de deux : un fork en moins, et une gestion d'erreur plus facile si on décide d'en faire. Sur un script utiliser une fois, on s'en fout un peu, mais si ça doit atterrir dans un truc lancé régulièrement, c'est bien d'avoir ces considérations en tête.

  • # tail -f fichier_de_log ? non ! less +F fichier_de_log

    Posté par  . En réponse au journal Back to basics : avoir un excellent pager avec less. Évalué à 10.

    J'étais tombé sur un post d'un blog qui présentait less +F, et c'est de la grosse balle. Ça permet de se mettre en attente sur un fichier (comme tail -f), mais on peut aussi interrompre l'attente pour se balader dans le fichier, puis se remettre en attente sur le fichier. Ça remplace très avantageusement tail -f /var/log/messages par exemple.

    $ while [ 1 ]; do date >> log_file; sleep 1 ; done &
    [1] 12294
    # je coupe des lignes, la commande suivante affiche en fait less sur tout le terminal
    $ less +F ./log_file
    Tue Oct 11 13:31:37 CEST 2016
    Tue Oct 11 13:31:38 CEST 2016
    Waiting for data... (interrupt to abort)
    # sur pression de Ctrl-C
    Tue Oct 11 13:32:15 CEST 2016
    Tue Oct 11 13:32:16 CEST 2016
    Tue Oct 11 13:32:17 CEST 2016
    Tue Oct 11 13:32:18 CEST 2016
    Tue Oct 11 13:32:19 CEST 2016
    ./log_file (END)
    # on peut naviguer dans le fichier de log comme on fait habituellement dans less.
    # pour reprendre la mise à jour du fichier, il suffit de se déplacer en fin de fichier (touche F)
    Tue Oct 11 13:33:34 CEST 2016
    Tue Oct 11 13:33:35 CEST 2016
    Tue Oct 11 13:33:36 CEST 2016
    Tue Oct 11 13:33:37 CEST 2016
    Waiting for data... (interrupt to abort)
    # et hop, de retour sur le lecture des nouvelles entrées dans le fichier