Un vieux logiciel sous DOS ça peut tourner sous DOSEMU (maintenant la mode est plus à VMWare et autres), ou si on a vraiment besoin de faire des trucs exotiques sur la machine en elle même il y a freedos.
Sinon les exemples sont très bons et sauf à haïr Microsoft plus que tout au monde, je ne pense pas que ça soit trop un problème. Enfin tout dépend du degré de la dépendance...
---
HS : je viens de jeter un oeil sur le site de FreeDOS et y a des gens qui font des trucs complètement cinglés sous DOS en 2008, genre compiler Linux en tant que programme DOS - ce qui est en plus potentiellement utile pour débugguer très très tôt dans le processus de boot.
Nan mais sérieusement faut arrêter de psycoter là.
Les extensions de GCC (comme celles de la majorité des compilateurs C, y compris visual C) sont bien documentées, bien identifiées en tant qu'extension et facile à repérer.
Alors si vous chercher juste un pretexte pour taper sur la FSF, cherchez ailleurs.
HFS+ est injustement haï par des faux "pragmatiques" pour on ne sait quelle raison, alors qu'il est tout à fait honorable (et qu'en plus effectivement Apple est parvenu à l'implémenter suffisamment bien pour ne pas trop avoir de leçon à recevoir sur les perfs). Concernant les features, il n'a pas non plus à rougir.
Certes certains parties sont "bizarres" par rapport à ce qui se fait dans le monde Unix / Linux mais Apple s'en est bien sorti pour le faire évoluer depuis HFS (conçu en 1985) jusqu'aux version récentes HFS+ / HFSX journalisées et dottées de features d'optimisation du démarrage de la machine.
Quand à l'age du FS, ben, je vous laisse regarder quand Unix a été créé... HFS+ a toujours été correct et il restera correct, une structure de filesystem ne se dégrade pas avec le temps. (mais de meilleures peuvent apparaître).
Y a des gens qui veulent faire des trucs de oufs compliqués en 30s sur 30000 systèmes différents et ils y arrivent pas ?
Oh mon dieu c'est un scandale !
Je comprends fort bien qu'ils y a des éditeurs qui n'ont pas assez d'argent pour intégrer leur logiciels propriétaires sur des tonnes de distro différentes. Et alors ? Chacun fait ce qu'il veut.
Quand aux éditeurs de logiciels proprio ou "semi" proprio qui veulent VRAIMENT éditer quelquechose qui fonctionnera à peu près sur tous les système Linux "classiques" (parce qu'ils n'ont pas le choix ou un intérêt suffisant à le faire pour... le faire), il le font en mode "pragmatique je te colle la libc et tout ce qui va bien dans /opt et ça roule" et ils y arrivent très bien. Et ça marche très bien. Bon, ça reste un peu de la merde, mais honnêtement, je m'en fous, ils s'en foutent, tout le monde s'en fout, ça marche très bien et tout le monde est content.
Le plus gros problème avec ceux qui voient des pb techniques dans les systèmes Linux là où il n'y en a PAS (alors que y'en a déjà bien assez des vrai pour pas se mettre à en chercher des faux....), c'est qu'ils s'imaginent que quand il y a le mot Linux quelque part dans un système, ben forcement, ça devrait être compatible de partout magiquementet dans tous les sens (et te filer 100$ à la fin de chaque compilation). Ben non. Sinon ça serait le même système. C'est bizarre hein ?
(dans les cas les plus extrême ça donne Android, tu veux que tout marche comme "d'habitude" avec Android aussi - pareil que sur une Debian ? tu vas avoir du mal ! beaucoup de mal...)
En fait ils veulent ONE LINUX TO RULE THEM ALL. Comme ils ont déjà leur Windows magique qui est compatible avec tout tout le temps et qui ne casse jamais les vieux programmes (NOOOOON, jamais!!!!!) et qui supporte tellement bien le matériel qu'il faut changer tout le parc quand on passe de XP à Vista, j'ai du mal à comprendre pourquoi ils veulent en plus un "Linux homogène", puisque ça serait hétérogène par rapport à leur Windows chéri. Bref à ceux qui veulent de l'homogénéité pure et parfaite, des API pures et parfaite, adaptez vous à Windows.
Laissez les hétérogènes s'occuper de leur système hétérogènes aux API mouvantes.
Quand à moi, je continue à adapter mon Linux à mes besoins (et à ceux de mes clients). Tranquillement.
Ahah ! Oui alors il y a ceux qui sont effectivement capable de le faire (pcq'ils ont plein de tunes et que oh! surprise! ils ont embauché des kernel hackers compétents, qui avaient déjà de l'expérience de kernel hacking Linux, et là oh surprise, ils intègrent plus volontiers leur truc upstream puisque les kernel hackeurs en question savent qu'il FAUT faire ça) et puis les autres, qui ne sont pas forcement mauvais mais n'ont pas tout compris à la philosophie du noyau et codent donc pour "autre chose".
Et quand on code pour "autre chose" tout en devant pondre un binaire kernel space Linux on se retrouve à niquer les performances pour ce qui est pas en rapport avec ton petit matos pcq'on cadre pas du tout avec le modèle d'exécution de Linux. Voir pire, on se retrouve à interdire certaines options du noyau (pcq'on cadre pas du tout avec le modèle d'exécution de Linux...)
Quand au côté "diriger ses produits", certains constructeur ont en effet tendance à vouloir forcer l'obsolescence de leur daubes.
On se passe volontiers de leur matos (de merde). Et tant pis si à cause de ça des utilisateurs de matos de merde ne peuvent pas migrer sous Linux, on s'en remettra -- et s'ils sont vraiment motivé ils achèteront du meilleur matos (c'est pas comme si Linux n'était pas le noyau qui supporte le plus de matériel au monde), voilà tout.
mais cessons de nous mettre des batons techniques dans les roues sous prétexte que ca en fou aux éditeurs de logiciels proprio : c'est contre-productif pour tout le monde et ca n'atteind même pas le but recherché (puisqu'il y a toujours aussi peu de specs diffusés par les constructeurs et toujours aussi peu de constructeurs engagés envers le libre).
T'as cas devenir un contributeur majeur de Linux, après tu pourras plus facilement prendre plein de (mauvaises) décisions.
Eh, peut être que ca contenterait aussi des constructeurs susceptibles de mettre leurs pilotes sous licence libre mais qui sont freinés à l'heure d'aujourd'hui par la piètre qualité technique de l'API des drivers du kernel (oui la stabilité est une qualité technique) ?
Parler de "piètre qualité technique" à cause d'une (légère) instabilité d'API qui est géré à ta place par les mainteneurs du noyau... Sans commentaire.
Tu as déjà codé en kernel space sous Linux ? (autrement qu'une fois tous les 3 ans en t'énervant pcq OH MON DIEU des choses ont changé depuis 3 ans)
- les constructeurs de matos sont des utilisateurs : ben rien n'est fait pour leur faciliter la tâche d'intégration de leurs composants : on leur file une API pas stable qui bouge sans cesse : on fait rien pour ces utilisateurs.
Les constructeurs de matos n'ont qu'à lever le petit doigt et des kernel hackers fous furieux leur codent un driver for free. Tu veux que les constructeurs se fasse payer aussi (tient c'est ptet ça que fait MS en fait) ?
Et tu expliques comment le fait que les editeurs commerciaux rechignent autant a porter leurs softs sous Linux, le fait que les editeurs de softs serveurs limitent leur support a des versions tres tres specifiques de distributions plutot qu'a "Linux" ?
Soit ils sont mauvais et dans un écosystème de développeurs neuneus (pas tous mais la plupart) incapable de chercher quoique ce soit dès qu'ils sortent de leur IDE habituelle, soit c'est juste politique.
On peut faire triviallement des binaires statiques pour un système Linux. Ça revient au même que de distribuer l'ensemble des DLL de l'univers avec chaque programme. On peut même faire du dynamique et distribuer l'ensemble des .so de l'univers, si on veut vraiment pas builder un binaire statique. Bref on a le choix :
1) on peut aussi faire de la merde qui fonctionne (cad ce que j'ai décris au dessus), comme tous les soft windows sont obligés de faire.
ou 2) on peut faire des trucs propres et intégrés au système, mais dans ce cas on intègre AU système, c'est du cas par cas, on intègre pas à TOUS les systèmes de l'univers et de la création.
Donc quand les gens donne des arguments techniques en faveur de MS ils sont, ... faux ?
Une compatibilité binaire. Je peux toujours exécuter la plupart des binaires faits pour Win95, il y a 13 ans! Va essayer avec Linux... Je développe une DLL pour Windows, dans un même binaire j'ai une compatibilité de Windows 95 à Vista. Sous Linux, faut faire suivant la distrib, la version de la distrib et j'en passe!
Quelle est la manière conseillée (et parfois même utilisée!) par MS vis à vis de la libc ?
Une libc par programme, celle avec laquelle il a été linké. Ça c'est de la compatibilité binaire :P
Sous quel OS on peut avoir (courrament) des problèmes pcq qu'une biblio à fait un malloc en utilisant une libc et que le free d'une autre libc (toutes les deux de MS) utilisée par une appli n'est pas compatible ? WINDOWS :P Quel est l'éditeur qui édite des libc différentes (et subtilement incompatibles) avec le même numéro de version ? MS !
Pour info l'ABI kernel <-> user de Linux est très stable. (encore plus que l'ABI de la glibc, qui elle aussi est très stable... avec moultes features de ouf de choix de symboles versionnés pour être encore plus stable, + le magnifique soname des système Unix qui permet néanmoins d'avoir plusieurs libc pour faire tourner les programmes vraiment vieux, genre d'il y a 15 ans :p )
Sans même parler des programmes proprio compilés en statique. L'équivalent de ce que les vendeurs de soft tiers livrent sous Windows quoi. => tu compares des pommes et des carottes. (en plus de raconter n'importe quoi sur Windows)
Ouai ben va dire ça à MS et aux vendeurs informatiques, parce que je crois bien qu'ils s'en fichent un peu que leur ententes illégales soient... illégales.
Mais j'ai du mal à comprendre pourquoi tu t'inquiètes de la porte de ta voiture, vu que la porte de ton appart ne te laissera plus sortir de chez toi, vu que tu es un méchant terroriste (et que les prisons sont surchargées).
Sincèrement, je suis en train de regarder les objets qui m'entoure, et j'ai très peu envie de connecter à Internet ceux qui ne le sont pas déjà (en tout cas sans changer d'ordre de grandeur)
Je veux bien que les abstractions aient dans certains cas tendance à fuir, et que dans certains cas ça puisse porter à conséquence, mais tout de même, on ne peut pas prétendre que pour comprendre le niveau fonctionnel il faille impérativement comprendre l'implémentation, dans tous les cas ! En appliquant le concept à l'extrême autant arrêter de faire de l'informatique, ou alors maîtriser parfaitement la physique, l'électronique, la logique, les ALU, MMU, etc, le code binaire, le langage d'assemblage, etc. jusqu'au niveau abstrait où tu programmes.
En passant faudrait aussi arrêter d'utiliser des serrures pour la majeure partie d'entre nous. (et des vélos, etc.)
Je trouve que la définition donnée du "culte du cargo pour la programmation" est assez mauvaise en VF. Elle n'est pas strictement fausse mais pourrait-être mal comprise. Le cargo culte programming relève de l'incantation, où on balance des trucs en général assez brefs assez souvent dans un quasi réflexe car cette "incantation" (qu'effectivement on ne comprend pas du tout, où alors de travers) permet de résoudre un problème ayant une vague ressemblance (ou carrément pas :p ) voire permettait dans le passé de résoudre un problème. On ne sait pas vraiment ce que fait _fonctionnellement_ l'incantation (et encore moins techniquement, mais c'est le fonctionnel qui est important) et on fait l'hypothèse que l'incantation produira un certain résultat par fausse inférence de causalité, observé dans un contexte totalement différent (ou juste entendu parlé)
Exemples :
- balancer des "sync" dans un shell avant de rebooter (ou avant de démonter...)
- rajouter des memory barriers un peu partout dans un driver sans avoir compris en détail le concept des memory barriers, en espérant débugguer quelque chose sans pour autant savoir pourquoi ça pourrait effectivement debugguer quelque chose (et bien que dans certains cas ça pourrait effectivement marcher suite à un gros coup de chance, ça relève néanmoins d'un comportement de type culte du cargo).
[^] # Re: tellement vrai !
Posté par Guillaume Knispel . En réponse à la dépêche Une année sans (MS) Windows : achever la conversion d'un utilisateur de Windows. Évalué à 4.
Sinon les exemples sont très bons et sauf à haïr Microsoft plus que tout au monde, je ne pense pas que ça soit trop un problème. Enfin tout dépend du degré de la dépendance...
---
HS : je viens de jeter un oeil sur le site de FreeDOS et y a des gens qui font des trucs complètement cinglés sous DOS en 2008, genre compiler Linux en tant que programme DOS - ce qui est en plus potentiellement utile pour débugguer très très tôt dans le processus de boot.
# hs
Posté par Guillaume Knispel . En réponse au journal Votre avis sur le nouveau module de Seconde "Informatique et société numérique". Évalué à 9.
[^] # Re: Encore une critique gratuite...
Posté par Guillaume Knispel . En réponse au journal Rions un peu avec les antivirus. Évalué à 2.
[^] # Re: Environnement informatique exact
Posté par Guillaume Knispel . En réponse au journal Parador, le livre à faire lire à votre DSI.... Évalué à 2.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par Guillaume Knispel . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 1.
Arrête de raconter n'importe quoi.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par Guillaume Knispel . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 1.
C'est ton interprétation.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par Guillaume Knispel . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 3.
Les extensions de GCC (comme celles de la majorité des compilateurs C, y compris visual C) sont bien documentées, bien identifiées en tant qu'extension et facile à repérer.
Alors si vous chercher juste un pretexte pour taper sur la FSF, cherchez ailleurs.
[^] # Re: PCinpact !?!
Posté par Guillaume Knispel . En réponse au journal Retour d'experience sur Ubuntu 64.. Évalué à 5.
Certes certains parties sont "bizarres" par rapport à ce qui se fait dans le monde Unix / Linux mais Apple s'en est bien sorti pour le faire évoluer depuis HFS (conçu en 1985) jusqu'aux version récentes HFS+ / HFSX journalisées et dottées de features d'optimisation du démarrage de la machine.
Quand à l'age du FS, ben, je vous laisse regarder quand Unix a été créé... HFS+ a toujours été correct et il restera correct, une structure de filesystem ne se dégrade pas avec le temps. (mais de meilleures peuvent apparaître).
[^] # Re: Quelle différence? :)
Posté par Guillaume Knispel . En réponse au journal Dell Mini 9 et ses offres hilarantes. Évalué à 3.
Oh mon dieu c'est un scandale !
Je comprends fort bien qu'ils y a des éditeurs qui n'ont pas assez d'argent pour intégrer leur logiciels propriétaires sur des tonnes de distro différentes. Et alors ? Chacun fait ce qu'il veut.
Quand aux éditeurs de logiciels proprio ou "semi" proprio qui veulent VRAIMENT éditer quelquechose qui fonctionnera à peu près sur tous les système Linux "classiques" (parce qu'ils n'ont pas le choix ou un intérêt suffisant à le faire pour... le faire), il le font en mode "pragmatique je te colle la libc et tout ce qui va bien dans /opt et ça roule" et ils y arrivent très bien. Et ça marche très bien. Bon, ça reste un peu de la merde, mais honnêtement, je m'en fous, ils s'en foutent, tout le monde s'en fout, ça marche très bien et tout le monde est content.
Le plus gros problème avec ceux qui voient des pb techniques dans les systèmes Linux là où il n'y en a PAS (alors que y'en a déjà bien assez des vrai pour pas se mettre à en chercher des faux....), c'est qu'ils s'imaginent que quand il y a le mot Linux quelque part dans un système, ben forcement, ça devrait être compatible de partout magiquementet dans tous les sens (et te filer 100$ à la fin de chaque compilation). Ben non. Sinon ça serait le même système. C'est bizarre hein ?
(dans les cas les plus extrême ça donne Android, tu veux que tout marche comme "d'habitude" avec Android aussi - pareil que sur une Debian ? tu vas avoir du mal ! beaucoup de mal...)
En fait ils veulent ONE LINUX TO RULE THEM ALL. Comme ils ont déjà leur Windows magique qui est compatible avec tout tout le temps et qui ne casse jamais les vieux programmes (NOOOOON, jamais!!!!!) et qui supporte tellement bien le matériel qu'il faut changer tout le parc quand on passe de XP à Vista, j'ai du mal à comprendre pourquoi ils veulent en plus un "Linux homogène", puisque ça serait hétérogène par rapport à leur Windows chéri. Bref à ceux qui veulent de l'homogénéité pure et parfaite, des API pures et parfaite, adaptez vous à Windows.
Laissez les hétérogènes s'occuper de leur système hétérogènes aux API mouvantes.
Quand à moi, je continue à adapter mon Linux à mes besoins (et à ceux de mes clients). Tranquillement.
[^] # Re: Faire payer... Ou proposer ce que les gens demandent.
Posté par Guillaume Knispel . En réponse au journal Linux et le grand public il faut en finir avec la gratuité.. Évalué à 5.
Et quand on code pour "autre chose" tout en devant pondre un binaire kernel space Linux on se retrouve à niquer les performances pour ce qui est pas en rapport avec ton petit matos pcq'on cadre pas du tout avec le modèle d'exécution de Linux. Voir pire, on se retrouve à interdire certaines options du noyau (pcq'on cadre pas du tout avec le modèle d'exécution de Linux...)
Quand au côté "diriger ses produits", certains constructeur ont en effet tendance à vouloir forcer l'obsolescence de leur daubes.
On se passe volontiers de leur matos (de merde). Et tant pis si à cause de ça des utilisateurs de matos de merde ne peuvent pas migrer sous Linux, on s'en remettra -- et s'ils sont vraiment motivé ils achèteront du meilleur matos (c'est pas comme si Linux n'était pas le noyau qui supporte le plus de matériel au monde), voilà tout.
[^] # Re: Faire payer... Ou proposer ce que les gens demandent.
Posté par Guillaume Knispel . En réponse au journal Linux et le grand public il faut en finir avec la gratuité.. Évalué à 2.
T'as cas devenir un contributeur majeur de Linux, après tu pourras plus facilement prendre plein de (mauvaises) décisions.
[^] # Re: Faire payer... Ou proposer ce que les gens demandent.
Posté par Guillaume Knispel . En réponse au journal Linux et le grand public il faut en finir avec la gratuité.. Évalué à 5.
Parler de "piètre qualité technique" à cause d'une (légère) instabilité d'API qui est géré à ta place par les mainteneurs du noyau... Sans commentaire.
Tu as déjà codé en kernel space sous Linux ? (autrement qu'une fois tous les 3 ans en t'énervant pcq OH MON DIEU des choses ont changé depuis 3 ans)
[^] # Re: Faire payer... Ou proposer ce que les gens demandent.
Posté par Guillaume Knispel . En réponse au journal Linux et le grand public il faut en finir avec la gratuité.. Évalué à 3.
Les constructeurs de matos n'ont qu'à lever le petit doigt et des kernel hackers fous furieux leur codent un driver for free. Tu veux que les constructeurs se fasse payer aussi (tient c'est ptet ça que fait MS en fait) ?
[^] # Re: Diffusion
Posté par Guillaume Knispel . En réponse au journal Linux et le grand public il faut en finir avec la gratuité.. Évalué à 2.
[^] # Re: Quelle différence? :)
Posté par Guillaume Knispel . En réponse au journal Dell Mini 9 et ses offres hilarantes. Évalué à 3.
AH enfin là je suis d'accord.
[^] # Re: Quelle différence? :)
Posté par Guillaume Knispel . En réponse au journal Dell Mini 9 et ses offres hilarantes. Évalué à 3.
-- Greg K-H
(note: MS est d'accord)
de plus :
N'importe quel constructeur peut se faire faire coder un driver gratuitement qui sera intégré à Linux et maintenu.
http://www.kroah.com/log/linux/free_drivers.html
http://www.linuxdriverproject.org/twiki/bin/view
J'ai du mal à voir ce qui peut-être fait de mieux ?
Quand à la compatibilité des interfaces dans le noyau, cf Documentation/stable_api_nonsense.txt
[^] # Re: Quelle différence? :)
Posté par Guillaume Knispel . En réponse au journal Dell Mini 9 et ses offres hilarantes. Évalué à 2.
Si le but c'est 80% de "desktop", 1) je vois mal l'intérêt, 2) je comprend TRÈS bien que certains puissent préferer Windows.
[^] # Re: Quelle différence? :)
Posté par Guillaume Knispel . En réponse au journal Dell Mini 9 et ses offres hilarantes. Évalué à 3.
Soit ils sont mauvais et dans un écosystème de développeurs neuneus (pas tous mais la plupart) incapable de chercher quoique ce soit dès qu'ils sortent de leur IDE habituelle, soit c'est juste politique.
On peut faire triviallement des binaires statiques pour un système Linux. Ça revient au même que de distribuer l'ensemble des DLL de l'univers avec chaque programme. On peut même faire du dynamique et distribuer l'ensemble des .so de l'univers, si on veut vraiment pas builder un binaire statique. Bref on a le choix :
1) on peut aussi faire de la merde qui fonctionne (cad ce que j'ai décris au dessus), comme tous les soft windows sont obligés de faire.
ou 2) on peut faire des trucs propres et intégrés au système, mais dans ce cas on intègre AU système, c'est du cas par cas, on intègre pas à TOUS les systèmes de l'univers et de la création.
[^] # Re: Quelle différence? :)
Posté par Guillaume Knispel . En réponse au journal Dell Mini 9 et ses offres hilarantes. Évalué à 2.
Une compatibilité binaire. Je peux toujours exécuter la plupart des binaires faits pour Win95, il y a 13 ans! Va essayer avec Linux... Je développe une DLL pour Windows, dans un même binaire j'ai une compatibilité de Windows 95 à Vista. Sous Linux, faut faire suivant la distrib, la version de la distrib et j'en passe!
Quelle est la manière conseillée (et parfois même utilisée!) par MS vis à vis de la libc ?
Une libc par programme, celle avec laquelle il a été linké. Ça c'est de la compatibilité binaire :P
Sous quel OS on peut avoir (courrament) des problèmes pcq qu'une biblio à fait un malloc en utilisant une libc et que le free d'une autre libc (toutes les deux de MS) utilisée par une appli n'est pas compatible ? WINDOWS :P Quel est l'éditeur qui édite des libc différentes (et subtilement incompatibles) avec le même numéro de version ? MS !
Pour info l'ABI kernel <-> user de Linux est très stable. (encore plus que l'ABI de la glibc, qui elle aussi est très stable... avec moultes features de ouf de choix de symboles versionnés pour être encore plus stable, + le magnifique soname des système Unix qui permet néanmoins d'avoir plusieurs libc pour faire tourner les programmes vraiment vieux, genre d'il y a 15 ans :p )
Sans même parler des programmes proprio compilés en statique. L'équivalent de ce que les vendeurs de soft tiers livrent sous Windows quoi. => tu compares des pommes et des carottes. (en plus de raconter n'importe quoi sur Windows)
[^] # Re: Quelle différence? :)
Posté par Guillaume Knispel . En réponse au journal Dell Mini 9 et ses offres hilarantes. Évalué à 2.
Vous avez vu la taille des disques ? (et puis moi je m'en fiche encore plus vu que je n'utilise pas XP... :p gniarf)
De toute manière j'ai l'impression que le bloatware c'est plus une culture du monde "desktop" en général que quelque chose de spécifique à MS.
[^] # Re: Quelle différence? :)
Posté par Guillaume Knispel . En réponse au journal Dell Mini 9 et ses offres hilarantes. Évalué à 4.
[^] # Re: Et pourquoi pas un objectif plus générique ?
Posté par Guillaume Knispel . En réponse à la dépêche OGD1 fonctionne comme carte vidéo. Évalué à 3.
Tu n'as pas besoin de 300kE pour compiler un soft...
[^] # Re: loi hadopi et internet des objets
Posté par Guillaume Knispel . En réponse au journal Consultation Européenne sur l'internet des objets (encore). Évalué à 7.
Mais j'ai du mal à comprendre pourquoi tu t'inquiètes de la porte de ta voiture, vu que la porte de ton appart ne te laissera plus sortir de chez toi, vu que tu es un méchant terroriste (et que les prisons sont surchargées).
Sincèrement, je suis en train de regarder les objets qui m'entoure, et j'ai très peu envie de connecter à Internet ceux qui ne le sont pas déjà (en tout cas sans changer d'ordre de grandeur)
[^] # Re: Ô My God !
Posté par Guillaume Knispel . En réponse au journal La méthode du culte du cargo. Évalué à 2.
En passant faudrait aussi arrêter d'utiliser des serrures pour la majeure partie d'entre nous. (et des vélos, etc.)
# allez plutôt lire la version en.
Posté par Guillaume Knispel . En réponse au journal La méthode du culte du cargo. Évalué à 4.
Exemples :
- balancer des "sync" dans un shell avant de rebooter (ou avant de démonter...)
- rajouter des memory barriers un peu partout dans un driver sans avoir compris en détail le concept des memory barriers, en espérant débugguer quelque chose sans pour autant savoir pourquoi ça pourrait effectivement debugguer quelque chose (et bien que dans certains cas ça pourrait effectivement marcher suite à un gros coup de chance, ça relève néanmoins d'un comportement de type culte du cargo).