pasBill pasGates a écrit 16044 commentaires

  • [^] # Re: Approche hybride

    Posté par  . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 10. Dernière modification le 27 octobre 2016 à 20:17.

    Mais imaginons un autre cas. Ta technique se répand, tous les softs s'y mettent.

    Tu as bien raison !

    Maintenant, la réalité en pratique est que ce n'est pas le cas et ne le sera jamais.

    Mais au cas oû je deviendrais soudainement un exemple à suivre par toute l'industrie, je me contenterais de rajouter un compteur incrémenté à chaque tentative d'allocation ratée, et remis à zero en cas de succes. Si le compteur atteint un certain nombre, le soft sort proprement avec un exit().

  • [^] # Re: Approche hybride

    Posté par  . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 3.

    Tout à fait, mais j'utilises cet allocateur en sachant évidemment comment mon soft alloue et gère sa mémoire.

  • [^] # Re: containers

    Posté par  . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 1.

    Non, si tu épuises ta mémoire, tu dois au moins avoir la possibilité de décider si tu veux essayer de faire de la place et continuer plutôt que t'écraser.

  • [^] # Re: containers

    Posté par  . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 1.

    Même la STL ne le fait pas que je sache (tu as un std::string dont tu consomme tout la capacité, il alloue 2 fois sa taille et va planter si ça marche pas, pas réessayer avec juste ce qu'il faut).

    Non il ne va pas planter, il va lancer une exception. Ce n'est pas la même chose, et de loin.

  • [^] # Re: undefined behaviour

    Posté par  . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 6.

    ben en fait si. Tu peux marquer ton soft comme "prioritaire" histoire que OOM killer aille massacrer quelqu'un d'autre. Mais faut être admin.

  • [^] # Re: undefined behaviour

    Posté par  . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 8.

    • tu utilises tout ton espace d'addresse sous Linux, et ton malloc se ramasse à cause de cela. Tu ne check pas le NULL, te choppes un segfault immédiatement à l'accès. Tu regardes le core dump, et tu vois que tu faisais des mappings de fichier et oubliais de les libèrer, ou que tu ne faisais pas gaffe qu'un des fichiers que tu essaies de mapper est énorme et bouffe tout l'espace…

    • sous Windows, ton malloc se ramasse car le processus d'à côté a décidé temporairement de tout allouer mais libère la plus grande partie 3 secondes après. Ton soft fait son malloc au milieu, se ramasse, tu regardes le crash dump et te rend compte que tu as oublié de gèrer le fait que malloc peut retourner NULL pour des raisons tout à fait valides sur une des plateformes que tu supportes.

  • [^] # Re: Approche hybride

    Posté par  . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 8.

    vu qu'aucun soft n'est capable d'allouer (rappel: je ne fais cela que pour des allocations plutôt petites, si elles échouent systématiquement sur le long terme, c'est que plus grand chose ne fonctionne sur le système), ben l'utilisateur ne fera rien car le système sera gelé de toute facon… ssh / bash / RDP ne pourra rien allouer pour permettre à l'utilisateur de se connecter ou lancer des commandes, etc… donc bref, ca ne changera rien.

  • [^] # Re: undefined behaviour

    Posté par  . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 6.

    Au contraire.

    Sous Linux, si tu chopes un segfault en accédant a un NULL malloc sous Linux, tu as soit :

    • bouffé tout ton espace d'addresse, et c'est clairement un problème à corriger
    • TON soft bouffe trop de RAM (car Linux utilise OOM killer et ne te fera pas un segfault pour une petite alloc ici ou la)

    Sous Windows, si tu chopes un sefault en accédant à un NULL malloc :

    Même situation, et aussi cela pourrait être un autre soft ayant bouffé la RAM pendant quelque secondes, et ton code n'est pas assez solide pour le gèrer

    Bref, dans tous les cas, c'est super important de le savoir.

  • # Approche hybride

    Posté par  . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 10. Dernière modification le 26 octobre 2016 à 21:48.

    Perso c'est simple, je considère que ne pas gèrer un NULL retourné par malloc est une faute grave si malloc peut retourner NULL.

    Pourquoi ? Parce que le comportement de malloc entre Linux et d'autres OS est diffèrent, et que si tu ne gères pas le cas, alors ton soft va exploser en vol sur d'autres plateformes.

    Exemple tout simple : code qui est sensé être multiplateforme entre Windows et Linux, et le code fait une allocation de 256Kb.

    256Kb c'est petit hein, c'est genre rien du tout.

    Pourtant sur Windows, si ton soft tourne alors qu'un soft super vorace tourne en background, il pourrait tout à fait se retrouver dans la situation ou il n'y a effectivement pas 256Kb de mémoire dispo, car Windows ne tue pas les processus au hasard pour faire de la place. Ce pourrait être juste quelque secondes parce qu'un soft a décidé de faire une énorme allocation qu'il libère tout de suite après hein… et là malloc retournera NULL sous Windows, là ou Linux serait allé trouver un processus à tuer pour faire de la place.

    Est-ce que laisser le soft exploser en vol parce qu'il n'y avait pas 256Kb de RAM dispo pendant qqe secondes est une bonne chose ? A mon avis non, c'est très mauvais.

    Donc perso l'approche que j'utilises est la suivante :

    J'ai un allocateur custom, qui ne retourne JAMAIS NULL pour les allocations plus petites qu'une certaine limite (genre 1Mb ou 4Mb, selon les besoins). Il se contente de ré-essayer avec une petite pause car le mode de pensée est que si le système n'a pas 1-4Mb de dispo, ce ne sera pas indéfiniment sinon le système entier est à plat.

    Résultat, dans tout mon code, je n'ai des checks pour NULL que lorsque je sais que la taille allouée peut potentiellement être plus élevée. Dans les autres cas, mon allocateur prendra peut-être 30 secondes à retourner (mais c'est pas grave car si le système est à genoux niveau RAM, il ne ferait rien de toute facon), mais il ne retournera pas NULL.

    L'avantage est que je n'ai pas besoin de me soucier de mettre des exception handlers pour la plupart de mes utilisations de STL, ou des NULL checks pour la plupart de mes allocations. Il n'y a qu'un très faible nombre de cas ou j'ai besoin de le faire, et l'approche permet au code de rester lisible et supporter plusieurs OS proprement.

  • [^] # Re: De meilleurs liens ( font de meilleurs amis )

    Posté par  . En réponse au journal CVE-2016-5195 Dirty COW. Évalué à 6.

    La raison est problablement que ce n'est pas exploitable à distance.

    Et important-critical n'a probablement aucune incidence sur la vitesse à laquelle le patch sort.

  • [^] # Re: Eeeuuuuuh

    Posté par  . En réponse au journal Dans la peau d’un entrepreneur du Libre – Épisode 2. Évalué à 4.

    Il parle de développer du code, clairement ce n'est pas que déployer des softs libres.

    Quelles étaient les conditions et problèmes quand il a expliqué que le code écrit serait libre ? aucun ? certains clients ont dit non ? enthousiastes ?

    Il a eu des offres de collaboration sur du code ? Fait des patchs pour d'autres projets ?

    etc…

  • [^] # Re: Eeeuuuuuh

    Posté par  . En réponse au journal Dans la peau d’un entrepreneur du Libre – Épisode 2. Évalué à 5.

    Tu souhaites m’expliquer que je peux distribuer Navision et assurer le support de celui-ci sans passer un contrat avec Microsoft ?

    N'importe qui peut devenir un distributeur : https://partner.microsoft.com/en-us/licensing/become-a-licensing-reseller

    Faut un contrat ? Oui certainement, mais c'est vraiment pas compliqué, et cela explique pourquoi il y en a autant d'ailleurs.

    Cela-dit, je continue de penser qu’il est nécessaire de passer un contrat avec MS et un contrat ça implique des droits et des obligations. Ça lie quand même un peu la SSII en question à Microsoft…

    Et tu crois que c'est diffèrent avec Redhat ou Ubuntu par exemple ?

    Non c'est la même chose.

    Tu peux revendre des licences sans contrat hein, tu les achètes et tu les revends. Idem pour le support, tu peux vendre tes compètences sans contrat.

    Mais si tu veux le logo, si tu veux avoir un contact chez MS à qui poser des questions, recevoir un support avancé, avoir des rabais sur les licences pour y mettre ta marge, ben oui, faut parler à MS.

  • [^] # Re: Eeeuuuuuh

    Posté par  . En réponse au journal Dans la peau d’un entrepreneur du Libre – Épisode 2. Évalué à -3.

    À part l’absence de gestion des licences dans une entreprise qui ne fait que du libre et des choses qu’on doit faire ou faire faire soi-même parce que l’on a pas un éditeur sur lequel se reposer… je vois pas trop

    Pourtant si, comment convaincre le client d'utiliser tel produit libre plutot qu'un autre, etc… Il y a des diffèrences.

    Bien sûr qu’on peut avoir une certaine latitude si on fait du non-libre, ya plus d’une SSII qui est estampillé distributeur officiel des d’une partie des produits Microsoft, mais elles sont contrôlées par MS, qui accorde ce privilège à qui il veut…

    J'ai connu tes posts plus intelligents on dira…

  • [^] # Re: Eeeuuuuuh

    Posté par  . En réponse au journal Dans la peau d’un entrepreneur du Libre – Épisode 2. Évalué à 8.

    C'est pourtant simple bon dieu.

    Je m'attendais à lire quelque chose sur les aspects de son entreprise qui sont influencé par son choix de faire du libre.

    Une liste de 4 softs libres utilisés c'est super mais c'est rien. Il y 2000 sociétés de services informatiques qui font de même sans être des boites libres.

    Genre qu'il parle de la réaction de ses clients au fait que tout est libre, de la manière dont cela dicte certains choix…

  • # Eeeuuuuuh

    Posté par  . En réponse au journal Dans la peau d’un entrepreneur du Libre – Épisode 2. Évalué à -10.

    Quel rapport avec le libre ?!

    Rien dans ta (longue) prose ne parle du libre. Tu mentionnés que ta boite faisait du libre et… c'est tout, le reste de la prose est sans rapport. T'aurais pu écrire la même chose pour une boite non libre et personne n'aurait vu la différence

  • [^] # Re: Si on savait déja...

    Posté par  . En réponse au journal "Logiciels préchargés : la CJUE se décrédibilise.". Évalué à -1.

    Ah oui bien sur…

    Excepté que ces institutions ont eu la main lourde sur Google, Apple, Microsoft, etc…

    On va dire que les faits ne montrent absolument rien de ce côté là, bien au contraire.

  • [^] # Re: Si on savait déja...

    Posté par  . En réponse au journal "Logiciels préchargés : la CJUE se décrédibilise.". Évalué à -3.

    La CJUE est une cour de justice, avec des experts sur le sujet, et a décidé que ce n'est pas illégal.

    Alors, qui on croit ?

    Les pseudo avocats de linuxfr qui sont prêt à déclarer illégal tout ce qui n'aide pas Linux à gagner son année sur le desktop ?

    Ou des juges dont le boulot est d'intèrpèter les lois et qui n'ont pas de parti pris à première vue ?

    On va dire que le choix est simple.

  • # Aucune perte de crédibilité

    Posté par  . En réponse au journal "Logiciels préchargés : la CJUE se décrédibilise.". Évalué à -5.

    Je dirais plutôt que c'est l'auteur du journal qui se décrédibilise en refusant d'accepter plusieurs décisions de justice qui vont à l'encontre de sa préférence personnelle.

    Les juges ont tranché, et plus d'une fois. Vous avez perdu, ayez un minimum d'humilité et arrêtez d'accuser les juges d'incompétence ou de corruption quand ca vous arrange alors que vous leur jetez des fleurs quand ils suivent votre préférence.

  • [^] # Re: Si on savait déja...

    Posté par  . En réponse au journal "Logiciels préchargés : la CJUE se décrédibilise.". Évalué à -10.

    Ben désolé de te décevoir hein mais la justice a tranché clairement : Ce n'est pas illégal

    Point barre. Fini. C'est légal.

    Inutile de nous les rabâcher avec 42 comparaisons différentes ou autres hypothèses. La justice a décidé de manière claire.

  • [^] # Re: Pas vraiment pour rien

    Posté par  . En réponse au journal [Bookmark] 8 ans de procédure pour... rien. Évalué à -1.

    Avances de vrais arguments et faits plutôt que lancer des attaques sans fondements.

    Tu n'as clairement aucune idée du pourquoi et comment et te rabats simplement sur ton explication préférée sans même vouloir imaginer que tu pourrais ne pas connaître tous les aboutissants de l'histoire.

  • [^] # Re: Pas vraiment pour rien

    Posté par  . En réponse au journal [Bookmark] 8 ans de procédure pour... rien. Évalué à 1.

    Non on se dit que tu fais des raccourcis énormes sans prendre le temps d'approfondir car ca arrange ta vision des choses :

    http://mjg59.dreamwidth.org/44694.html

    Une fois de plus ton idée que MS est derrière un coup fumant se trouve être totalement fausse.

    Et de plus, Garrett explique bien une des raisons causant des problèmes aux constructeurs pour supporter Linux.

  • [^] # Re: Fais tes devoirs !

    Posté par  . En réponse au journal Appel à idées pour prof(s) de lycée. Évalué à -6.

    Non c'est juste un fait, tu as un problème virant à l'obsession. Il y a pas de honte hein, mais faudra penser à trouver un traitement.

  • [^] # Re: Fais tes devoirs !

    Posté par  . En réponse au journal Appel à idées pour prof(s) de lycée. Évalué à -4.

    C'est quand même pathétique cette obsession que tu as vis a vis du logiciel non libre qui te pousse à essayer de le blâmer pour tous les maux de la planète.

    A un moment va falloir penser à consulter un psychologue tu sais.

  • [^] # Re: Fais tes devoirs !

    Posté par  . En réponse au journal Appel à idées pour prof(s) de lycée. Évalué à 10.

    Il y a une règle qui dit que les profs doivent absolument tout créer par eux même plutôt que collaborer et apprendre des autres ?

    Non, on dira plutôt que tu as des idées sacrèment farfelues sur l'éducation et le rôle des profs.

  • [^] # Re: Il faut lire

    Posté par  . En réponse au journal [Bookmark] 8 ans de procédure pour... rien. Évalué à 1.

    Du tout non. Quand ton PC Dell tombe en rade tu appelles Dell, tu n'appelles ni MS ni Nvidia.

    Dell teste les systèmes qu'il vend pour s'assurer que le tout fonctionne proprement, a de la maintenance à faire sur ses drivers, etc…