OK, donc explique-moi ce que tu pourrais faire de plus qu'un _exit() en cas de OOM sur ce programme précis (parce qu'on parle de celui-là, toute la question est de la pertinence d'une telle gestion en fonction de la criticité). Si ton programme ne peut plus fonctionner correctement, autant le terminer pour remonter l'erreur que de continuer et faire n'importe quoi, non (encore une fois, je parle de programmes non critiques) ?
Mais qui t'a dit qu'il ne peut plus fonctionner correctement ? Ce soft peut liberer des buffers qu'il detient et re-essayer, simplement abandoner le chargement du fichier qu'il etait en train de lire et continuer de travailler avec les autres documents qu'il a charge, etc…
on en arrive à une 15aine de lignes de code et une complexité de 4.
Sur un soft d'une complexité standard, je te laisse imaginer ce que ça donne…
La realite est que cette methode est utilisee dans certains des plus gros projets software existants (Windows et Office au hasard ainsi que le kernel Linux) et que ca marche tres bien.
Idem en maintenance/évolution, alors que sur le pseudo-code on n'aurait qu'à ajouter une ligne entre foo() et bar(), en C on va devoir toucher aussi à toute la partie nettoyage/gestion d'erreur, aussi bien dans notre code que dans le code appelant. Idéal pour semer des régressions aux 4 coins de l'appli…
Et pourquoi tu aurais besoin de changer le code appelant ? Tout ce que le code appelant a besoin de savoir est que ca a rate, il peut aller de maniere plus granulaire pour peut-etre re-essayer, logger un message plus precis, … mais le simple fait de savoir que la fonction a echoue est suffisant, bref, un switch-case avec un 'default' fait le boulot ou un if (ret==success) else {} aussi.
Au niveau développement, l'utilisateur d'une API n'a aussi aucune garantie de gérer toutes les erreurs possibles et imaginables que peut lui retourner une fonction, sauf à aller lire la doc (généralement fausse et/ou incomplète) voire pire, carrément le code source…
La beaute est justement que c'est totalement optionel. Le minimum a faire est voir que la fonction a reussie (tu compares au code de reussite), ensuite si tu veux gerer specifiquement qqe erreurs ou toutes les traiter de la meme maniere, c'est ton choix, mais tu sauras que la fonction a echoue:
DWORD dwResult=MyFunction();
switch(dwResult)
{
case ERROR_SUCCESS:
break;
case ERROR_BROKEN_PIPE:
delete[] FrameBuffer;
if (CheckConnection())
return Retry();
else return dwResult;
case ERROR_NOT_ENOUGH_MEMORY:
log("pas assez de memoire\n");
default: //toutes les erreurs non gerees specifiquement finissent ici
delete[] FrameBuffer;
return dwResult;
};
Sinon, ta phrase "l'utilisateur d'une API n'a aussi aucune garantie de gérer toutes les erreurs possibles et imaginables que peut lui retourner une fonction, sauf à aller lire la doc (généralement fausse et/ou incomplète)" est franchement horrible, oh mon dieu, l'utilisateur doit lire la doc ? Grande nouvelle, si il ne l'a lit pas, mieux vaut qu'il n'ecrive pas de code !
Mais pour faire les choses proprement, par exemple prévenir l'utilisateur, ou sauvegarder le fichier, et bien il faut de la mémoire.
Bah oui, créer un popup, ça demande de la mémoire. fprintf() utilise malloc(), tout comme fwrite() (oui je connais setvbuf()), etc. Quand tu y penses, sans malloc(), il ne te reste plus grand chose de disponible.
Ca depend des cas, comme tout. Si ton soft voit son alloc echouer alors que tu es en train de charger un 14eme document, ben il abandonne et vide tout ce qu'il a alloue pour le 14eme, et il evite de tout crasher et forcer l'utilisateur a rouvrire les 13 premiers documents, c'est un avantage indeniable.
Bref, gerer les mallocs qui ratent, ca ne coute quasiment rien, et ca peut rapporter gros.
La plupart des APIs ont la possibilite d'echouer, pour diverses raisons (mauvais parametres, rates reseau, etc…)
Faire :
buffer=malloc(X)
if (!buffer)
{
return ERROR_NOT_ENOUGH_MEMORY; // ou
dwResult=ERROR_NOT_ENOUGH_MEMORY;
goto cleanup;
}
ca prend quoi ? 5-10 secondes de plus, bref, rien de serieux niveau effort, et ca a l'avantage de permettre une gestion propre, avec un utilisateur qui ne voit pas ses softs exploser sans savoir pourquoi.
Ta page est un amas de conneries non-fondees, et l'a toujours ete.
Exemple simple: l'affirmation que MS detient la plupart des anti-virus, il faut vraiment etre sacrement incompetent ou de sacrement mauvaise foi pour sortir une anerie pareille.
Tu attaches un debugger, tu mets un breakpoint sur msvcrt!malloc, quand le breakpoint est touche, tu regardes l'assembleur juste apres l'appel, et tu verras une comparaison sur le registre eax, qui est le registre contenant la valeur de retour…
malloc te retourne null si l'espace memoire de Firefox est fragmente et si il tente un gros alloc, meme si il reste plein de RAM. OOM-killer ne levera pas un doigt dans ce cas.
Ils sont tres nombreux oui, a peu pres tous les softs serveurs, et chez nous tous les autres softs aussi(du moins tout ce qui est dans Windows et Office). Si on voit ca en code review c'est immediatement marque comme "a corriger" (et evidemment on en rate quelque uns qui atterissent dans le produit, on est pas parfait)
Alors vu qu'il y a une possibilite qui existe que ca merde et corrompe le fichier (prise de courant), autant ne jamais gerer les problemes d'allocation et laisser le fichier etre corrompu dans tous les cas ?
On va aller loin avec une approche pareille, et tu en fais quoi du fait que l'utilisateur n'a aucun moyen de comprendre ce qui s'est passe ?
Qu'il doit se retaper ce qu'il a perdu avec les softs qui n'ont pas d'auto-save ? (et le soft pourrait planter au milieu de l'auto-save hein…)
Que cette approche a la porc ouvre la porte a plein de failles de securite ?
Que cette approche peut corrompre la configuration du soft et l'empecher de redemarrer plus tard ?
etc…
Tu es en train de mettre la derniere touche a ton livre de 400 pages, et tu as Firefox en arriere plan qui bouffe toute la RAM, alors que OpenOffice essaie de sauver, il se retrouve avec un malloc qui rate, tu penses qu'il devrait exploser en vol et corrompre le document ou s'en sortir proprement ?
Ben t'as un chemin d'erreur normalement, si ton allocation rate, tu defais ce que tu avais fais et tu retournes une erreur.
Il y a forcement de tres rares cas ou il faut fermer l'application/tuer le systeme, mais dans ces cas-la, faut le faire le plus proprement possible (tu fermes les fichiers que tu ecris, tu logges un msg d'erreur, tu informes l'utilisateur, etc…)
Pour C++ normalement tu peux faire ton new avec std::nothrow qui forcera l'allocateur sans exception (tu recevras un NULL a la place), mais le defaut est de lancer une exception.
Quand a l'exception, ca va quitter le programme oui, mais c'est de nouveau pas forcement le bon resultat a avoir…
Le BABA du programmer correct est la gestion d'erreur. Une allocation de ressource qui flanche ca arrive, et ca doit etre gere. Ton utilisateur quand il voit ton soft lui exploser dans les doigts, c'est vraiment pas ce qu'il attend et il ne comprendra meme pas pourquoi, sans parler du fait qu'il y a risque de faille de securite (selon les operations faites apres l'alloc) si tu ne le geres pas.
Euh non desole, c'est une question d'hygiene de base de mon point de vue.
Le dev qui laisse aller des trucs aussi basique, c'est vraiment qu'il se fiche de son code, qu'il ne pense pas loin et qu'il a certainement plein d'autres problemes dans son code.
Ton bete outil, il va un jour etre utilise a travers Apache par exemple, avec parametres passes par l'utilisateur parce qu'apres tout, ton outil est juste genre un convertisseur ou autre.
Et le jour ou ton malloc il va rater et tout le monde s'en fiche, ben tu te retrouves avec une faille de securite potentiellement exploitable selon les operations faites apres le malloc.
Le mieux que tu puisse faire c'est un truc du style
C
assert(src_dup);
Euh non, parce que si tu fais ca, en cas d'echec d'allocation, ton programme il meurt. Tuer un soft parce qu'une allocation a echoue c'est franchement crade, tu avortes la requete ou l'operation, tu logges une erreur si besoin est, mais tu continues de tourner.
Ben ce sont justement celles que l'on retrouve dans Unix dès les années 70 et qui ont fait grandement son succès : modularité de l'espace utilisateur avec communication inter module, tout est fichier (de nos jours : objets, fonctions, ressources WEB, bref il y en a pour tous les goûts), etc. Marrant non ?
Ah oui, tres marrant.
Combien de softs importants sont composes de petits executables communiquant par pipe avec du texte comme mode de transport ? FireFox ? OpenOffice ? Apache ? Eclipse ? KDE ? Gnome ? Ah ouais, on voit combien cette architecture est suivie de nos jours…
Les softs d'aujourd'hui sont modulaires, mais en tant que dll charges(= plugins) plutot que differents executables, les configurations sont de moins en moins shell / texte pour etre plus structurees, etc…
Le web tu trouves que c'est KISS ? Avec SVG, la 3D, javascript, XML, CSS, SSL etc… dedans ? On dirait un mini-OS a la Emacs.
Plus généralement, l'essence d'UNIX c'est - KISS, - "Tout est fichier", - "Tout est éditable" (pas de binaires hormis les exécutables/librairies/images…), - Un outil s’acquitte d'une tâche et d'une seule etc …
Voila ce que je pense des dogmes :
Non pas que la philosophie est totalement stupide hein, mais faudrait penser a evoluer un peu, l'informatique des annees 60 n'a plus rien a voir avec celle du 21eme siecle.
systemd ressemble de plus en plus à un cheval de Troie. Il touche aux scripts de démarrage, il touche à Gnome, il touche à udev. Je te parie que d'ici 2 ans, vouloir se passer de systemd sera quasiment impossible.
Ben si ce sera possible, il te suffira de creer quelque chose de meilleur et les gens l'adopteront. Il n'y a rien qui empeche les gens de modifier le code ou bien ?
Je ne demande pas à démontrer que ma solution est meilleure. J'aimerais juste que ma vision des choses puisse continuer de cohabiter avec la sienne. Actuellement, je peux encore me passer de systemd, techniquement, mais ça ne va pas durer.
Fais un fork, ou convainc les gens que ta solution vaut la peine d'etre supportee. Simplement dire "je veux pas changer" n'est pas une raison suffisante pour se taper la maintenance de ton truc, sinon fais le toi-meme.
Je dois te dire que dans ma tête, quand j'évalue un logiciel, j'ai une cinquième liberté fondamentale en tête. Celle de se dire « est-ce que ce logiciel n'empêchera pas le développement d'alternatives ? ». Dans ce sens-là, des composants tels que xf86-video-nv ou systemd n'ont pas l'éthique libre, pour moi. Car ils m'enlèvent une liberté de façon tout à fait intentionnelle.
Tu peux toujours forker et avoir ton propre truc, rien ne l'empeche. Et au final si ta solution est meilleure, alors les gens l'adopteront, si non, ben c'est probablement une bonne chose qu'ils ne se tapent pas le support de ton truc.
C'est Groklaw, je me permettrai donc d'ignorer totalement ce qui y est ecrit etant donne l'habitude prise sur ce site de choisir les extraits soigneusement et eviter les parties qui ne vont pas dans le sens du site, c'est a dire pro-OSS/Libre.
Maintenant, je me doutes bien que ce gars n'etait pas un expert en brevets, et il a surement fait des erreurs, c'est plus que sur. Mais de nouveau, ca ne le rend pas moins competent que n'importe qui ici et ce qu'il a appris en deposant son brevet en fait certainement qq'un qui en sait un peu plus que le pekin moyen.
Sinon, je vois mal ce que les avocats auraient pu faire contre un gars qui a depose un brevet. Le proces n'a jamais ete sur le fait que les brevets etaient Mal(TM), mais si Samsung/Apple avaient viole des brevets, donc le gars n'avait rien de disqualifiant.
Le libre n'est pas une religion comme les autres, la motivation n'est pas de regrouper un maximum de gens autours d'une idée délirante mais faire en sorte que tout le monde ait un maximum de droits et donc un maximum de liberté. Comment ose-tu mettre ça sur le même plan que "craint le père noël ou tu connaîtra des souffrances éternelles quand tu sera mort" ?
Ca c'est ton interpretation a toi et rien d'autre, arretes de l'eriger en verite absolue.
C'est la différence qu'il y a entre une petite secte et une religion prosélyte.
C'est assez rigolo que tu te plaignes de proselytisme tout en postant un journal qui defend ton proselytisme…
Par ailleurs, je pense qu'il est dommage de présenter le logiciel libre comme un concurrent au logiciel privateur, et de n'avoir que des considérations techniques et pratiques lors des comparaisons. Le problème est complexe et dépasse très largement le cadre de l'informatique, mais les principes, l'éthique, la morale, ça compte !
Ca serait bien que tu evites d'eriger TES principes/references morales et ethiques en references absolues. C'est du proselytisme ca aussi, a tendance dictatoriale.
Je fais partie des gens qui ne comprend pas pourquoi les femmes de ménage sont moins payées que les médecins.
Entre autres parce que les medecins ont du etudier pendant des annees, annees ou ils n'ont eu aucun revenu.
Mais sinon, lis quelque bouquins d'histoire, notamment sur l'URSS, et tu comprendras pourquoi ta vision n'a absolument aucune chance de fonctionner dans le monde reel.
Alors oui, tu peux nous sortir ta theorie, qui sur le papier est super belle, mais vu qu'elle est totalement irrealiste, elle ne vaut rien.
Petit indice : si tu peux gagner autant en etant vendeur de jus d'orange qu'en etant medecin, combien de gens vont se faire ch*** a faire les etudes necessaires pour etre medecin ? Et qui va te soigner une fois qu'il n'y aura plus de medecins ?
Je n'ai jamais, j'ai bien dit jamais eu le moindre matos Apple.
Et pourtant quand je lis ton commentaire la, tout ce qu'il me dit c'est que tu es totalement borne avec des oeilleres de la taille d'un immeuble.
Tu aimes parler des softs proprios comme etant des prisons, mais tu devrais regarder ou se trouve ton cerveau : dans une sacre prison et il n'arrive pas a voir le monde de dehors.
[^] # Re: criticité
Posté par pasBill pasGates . En réponse au journal Genèse d'un journal. Évalué à 1.
OK, donc explique-moi ce que tu pourrais faire de plus qu'un _exit() en cas de OOM sur ce programme précis (parce qu'on parle de celui-là, toute la question est de la pertinence d'une telle gestion en fonction de la criticité). Si ton programme ne peut plus fonctionner correctement, autant le terminer pour remonter l'erreur que de continuer et faire n'importe quoi, non (encore une fois, je parle de programmes non critiques) ?
Mais qui t'a dit qu'il ne peut plus fonctionner correctement ? Ce soft peut liberer des buffers qu'il detient et re-essayer, simplement abandoner le chargement du fichier qu'il etait en train de lire et continuer de travailler avec les autres documents qu'il a charge, etc…
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par pasBill pasGates . En réponse au journal Genèse d'un journal. Évalué à 9.
on en arrive à une 15aine de lignes de code et une complexité de 4.
Sur un soft d'une complexité standard, je te laisse imaginer ce que ça donne…
La realite est que cette methode est utilisee dans certains des plus gros projets software existants (Windows et Office au hasard ainsi que le kernel Linux) et que ca marche tres bien.
Idem en maintenance/évolution, alors que sur le pseudo-code on n'aurait qu'à ajouter une ligne entre foo() et bar(), en C on va devoir toucher aussi à toute la partie nettoyage/gestion d'erreur, aussi bien dans notre code que dans le code appelant. Idéal pour semer des régressions aux 4 coins de l'appli…
Et pourquoi tu aurais besoin de changer le code appelant ? Tout ce que le code appelant a besoin de savoir est que ca a rate, il peut aller de maniere plus granulaire pour peut-etre re-essayer, logger un message plus precis, … mais le simple fait de savoir que la fonction a echoue est suffisant, bref, un switch-case avec un 'default' fait le boulot ou un if (ret==success) else {} aussi.
Au niveau développement, l'utilisateur d'une API n'a aussi aucune garantie de gérer toutes les erreurs possibles et imaginables que peut lui retourner une fonction, sauf à aller lire la doc (généralement fausse et/ou incomplète) voire pire, carrément le code source…
La beaute est justement que c'est totalement optionel. Le minimum a faire est voir que la fonction a reussie (tu compares au code de reussite), ensuite si tu veux gerer specifiquement qqe erreurs ou toutes les traiter de la meme maniere, c'est ton choix, mais tu sauras que la fonction a echoue:
Sinon, ta phrase "l'utilisateur d'une API n'a aussi aucune garantie de gérer toutes les erreurs possibles et imaginables que peut lui retourner une fonction, sauf à aller lire la doc (généralement fausse et/ou incomplète)" est franchement horrible, oh mon dieu, l'utilisateur doit lire la doc ? Grande nouvelle, si il ne l'a lit pas, mieux vaut qu'il n'ecrive pas de code !
[^] # Re: criticité
Posté par pasBill pasGates . En réponse au journal Genèse d'un journal. Évalué à 8.
Mais pour faire les choses proprement, par exemple prévenir l'utilisateur, ou sauvegarder le fichier, et bien il faut de la mémoire.
Bah oui, créer un popup, ça demande de la mémoire. fprintf() utilise malloc(), tout comme fwrite() (oui je connais setvbuf()), etc. Quand tu y penses, sans malloc(), il ne te reste plus grand chose de disponible.
Ca depend des cas, comme tout. Si ton soft voit son alloc echouer alors que tu es en train de charger un 14eme document, ben il abandonne et vide tout ce qu'il a alloue pour le 14eme, et il evite de tout crasher et forcer l'utilisateur a rouvrire les 13 premiers documents, c'est un avantage indeniable.
Bref, gerer les mallocs qui ratent, ca ne coute quasiment rien, et ca peut rapporter gros.
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par pasBill pasGates . En réponse au journal Genèse d'un journal. Évalué à 10.
La plupart des APIs ont la possibilite d'echouer, pour diverses raisons (mauvais parametres, rates reseau, etc…)
Faire :
ca prend quoi ? 5-10 secondes de plus, bref, rien de serieux niveau effort, et ca a l'avantage de permettre une gestion propre, avec un utilisateur qui ne voit pas ses softs exploser sans savoir pourquoi.
[^] # Re: Bien, mais l'obligation....
Posté par pasBill pasGates . En réponse à la dépêche Modification du code des marchés publics italien imposant l’usage du logiciel libre. Évalué à 4.
Ta page est un amas de conneries non-fondees, et l'a toujours ete.
Exemple simple: l'affirmation que MS detient la plupart des anti-virus, il faut vraiment etre sacrement incompetent ou de sacrement mauvaise foi pour sortir une anerie pareille.
[^] # Re: Ne le fait pas.
Posté par pasBill pasGates . En réponse au journal realloc. Évalué à 0.
Tu attaches un debugger, tu mets un breakpoint sur msvcrt!malloc, quand le breakpoint est touche, tu regardes l'assembleur juste apres l'appel, et tu verras une comparaison sur le registre eax, qui est le registre contenant la valeur de retour…
[^] # Re: Ne le fait pas.
Posté par pasBill pasGates . En réponse au journal realloc. Évalué à 0.
De nouveau, rien a voir.
malloc te retourne null si l'espace memoire de Firefox est fragmente et si il tente un gros alloc, meme si il reste plein de RAM. OOM-killer ne levera pas un doigt dans ce cas.
[^] # Re: Ne le fait pas.
Posté par pasBill pasGates . En réponse au journal realloc. Évalué à 0.
Ils sont tres nombreux oui, a peu pres tous les softs serveurs, et chez nous tous les autres softs aussi(du moins tout ce qui est dans Windows et Office). Si on voit ca en code review c'est immediatement marque comme "a corriger" (et evidemment on en rate quelque uns qui atterissent dans le produit, on est pas parfait)
[^] # Re: Ne le fait pas.
Posté par pasBill pasGates . En réponse au journal realloc. Évalué à 3.
Alors vu qu'il y a une possibilite qui existe que ca merde et corrompe le fichier (prise de courant), autant ne jamais gerer les problemes d'allocation et laisser le fichier etre corrompu dans tous les cas ?
On va aller loin avec une approche pareille, et tu en fais quoi du fait que l'utilisateur n'a aucun moyen de comprendre ce qui s'est passe ?
Qu'il doit se retaper ce qu'il a perdu avec les softs qui n'ont pas d'auto-save ? (et le soft pourrait planter au milieu de l'auto-save hein…)
Que cette approche a la porc ouvre la porte a plein de failles de securite ?
Que cette approche peut corrompre la configuration du soft et l'empecher de redemarrer plus tard ?
etc…
[^] # Re: Ne le fait pas.
Posté par pasBill pasGates . En réponse au journal realloc. Évalué à 0.
Tu penses ?
Tu es en train de mettre la derniere touche a ton livre de 400 pages, et tu as Firefox en arriere plan qui bouffe toute la RAM, alors que OpenOffice essaie de sauver, il se retrouve avec un malloc qui rate, tu penses qu'il devrait exploser en vol et corrompre le document ou s'en sortir proprement ?
[^] # Re: Ne le fait pas.
Posté par pasBill pasGates . En réponse au journal realloc. Évalué à 3.
Arreter le programme peut-etre oui, selon ce que le soft fait, mais il faut le faire proprement , pas avec un SEGFAULT ou un assert.
[^] # Re: Ne le fait pas.
Posté par pasBill pasGates . En réponse au journal realloc. Évalué à 4.
Ben t'as un chemin d'erreur normalement, si ton allocation rate, tu defais ce que tu avais fais et tu retournes une erreur.
Il y a forcement de tres rares cas ou il faut fermer l'application/tuer le systeme, mais dans ces cas-la, faut le faire le plus proprement possible (tu fermes les fichiers que tu ecris, tu logges un msg d'erreur, tu informes l'utilisateur, etc…)
Pour C++ normalement tu peux faire ton new avec std::nothrow qui forcera l'allocateur sans exception (tu recevras un NULL a la place), mais le defaut est de lancer une exception.
Quand a l'exception, ca va quitter le programme oui, mais c'est de nouveau pas forcement le bon resultat a avoir…
[^] # Re: Ne le fait pas.
Posté par pasBill pasGates . En réponse au journal realloc. Évalué à 10.
Non franchement non, pas d'accord.
Le BABA du programmer correct est la gestion d'erreur. Une allocation de ressource qui flanche ca arrive, et ca doit etre gere. Ton utilisateur quand il voit ton soft lui exploser dans les doigts, c'est vraiment pas ce qu'il attend et il ne comprendra meme pas pourquoi, sans parler du fait qu'il y a risque de faille de securite (selon les operations faites apres l'alloc) si tu ne le geres pas.
[^] # Re: Ne le fait pas.
Posté par pasBill pasGates . En réponse au journal realloc. Évalué à 10.
Euh non desole, c'est une question d'hygiene de base de mon point de vue.
Le dev qui laisse aller des trucs aussi basique, c'est vraiment qu'il se fiche de son code, qu'il ne pense pas loin et qu'il a certainement plein d'autres problemes dans son code.
Ton bete outil, il va un jour etre utilise a travers Apache par exemple, avec parametres passes par l'utilisateur parce qu'apres tout, ton outil est juste genre un convertisseur ou autre.
Et le jour ou ton malloc il va rater et tout le monde s'en fiche, ben tu te retrouves avec une faille de securite potentiellement exploitable selon les operations faites apres le malloc.
[^] # Re: Ne le fait pas.
Posté par pasBill pasGates . En réponse au journal realloc. Évalué à 2.
Le mieux que tu puisse faire c'est un truc du style
C
assert(src_dup);
Euh non, parce que si tu fais ca, en cas d'echec d'allocation, ton programme il meurt. Tuer un soft parce qu'une allocation a echoue c'est franchement crade, tu avortes la requete ou l'operation, tu logges une erreur si besoin est, mais tu continues de tourner.
[^] # Re: Tant que ça reste coté Desktop...
Posté par pasBill pasGates . En réponse à la dépêche Le point sur udev et systemd. Évalué à 2.
Ben ce sont justement celles que l'on retrouve dans Unix dès les années 70 et qui ont fait grandement son succès : modularité de l'espace utilisateur avec communication inter module, tout est fichier (de nos jours : objets, fonctions, ressources WEB, bref il y en a pour tous les goûts), etc. Marrant non ?
Ah oui, tres marrant.
Combien de softs importants sont composes de petits executables communiquant par pipe avec du texte comme mode de transport ? FireFox ? OpenOffice ? Apache ? Eclipse ? KDE ? Gnome ? Ah ouais, on voit combien cette architecture est suivie de nos jours…
Les softs d'aujourd'hui sont modulaires, mais en tant que dll charges(= plugins) plutot que differents executables, les configurations sont de moins en moins shell / texte pour etre plus structurees, etc…
Le web tu trouves que c'est KISS ? Avec SVG, la 3D, javascript, XML, CSS, SSL etc… dedans ? On dirait un mini-OS a la Emacs.
etc…
[^] # Re: Tant que ça reste coté Desktop...
Posté par pasBill pasGates . En réponse à la dépêche Le point sur udev et systemd. Évalué à 3.
Plus généralement, l'essence d'UNIX c'est
- KISS,
- "Tout est fichier",
- "Tout est éditable" (pas de binaires hormis les exécutables/librairies/images…),
- Un outil s’acquitte d'une tâche et d'une seule etc …
Voila ce que je pense des dogmes :
Non pas que la philosophie est totalement stupide hein, mais faudrait penser a evoluer un peu, l'informatique des annees 60 n'a plus rien a voir avec celle du 21eme siecle.
[^] # Re: « On ne vous met pas le couteau sous la gorge »
Posté par pasBill pasGates . En réponse au journal udev forké. Évalué à 3.
systemd ressemble de plus en plus à un cheval de Troie. Il touche aux scripts de démarrage, il touche à Gnome, il touche à udev. Je te parie que d'ici 2 ans, vouloir se passer de systemd sera quasiment impossible.
Ben si ce sera possible, il te suffira de creer quelque chose de meilleur et les gens l'adopteront. Il n'y a rien qui empeche les gens de modifier le code ou bien ?
Je ne demande pas à démontrer que ma solution est meilleure. J'aimerais juste que ma vision des choses puisse continuer de cohabiter avec la sienne. Actuellement, je peux encore me passer de systemd, techniquement, mais ça ne va pas durer.
Fais un fork, ou convainc les gens que ta solution vaut la peine d'etre supportee. Simplement dire "je veux pas changer" n'est pas une raison suffisante pour se taper la maintenance de ton truc, sinon fais le toi-meme.
Je dois te dire que dans ma tête, quand j'évalue un logiciel, j'ai une cinquième liberté fondamentale en tête. Celle de se dire « est-ce que ce logiciel n'empêchera pas le développement d'alternatives ? ». Dans ce sens-là, des composants tels que xf86-video-nv ou systemd n'ont pas l'éthique libre, pour moi. Car ils m'enlèvent une liberté de façon tout à fait intentionnelle.
Tu peux toujours forker et avoir ton propre truc, rien ne l'empeche. Et au final si ta solution est meilleure, alors les gens l'adopteront, si non, ben c'est probablement une bonne chose qu'ils ne se tapent pas le support de ton truc.
[^] # Re: A l'inverse
Posté par pasBill pasGates . En réponse au journal Apple vs Samsung: le verdict. Évalué à -3.
C'est Groklaw, je me permettrai donc d'ignorer totalement ce qui y est ecrit etant donne l'habitude prise sur ce site de choisir les extraits soigneusement et eviter les parties qui ne vont pas dans le sens du site, c'est a dire pro-OSS/Libre.
Maintenant, je me doutes bien que ce gars n'etait pas un expert en brevets, et il a surement fait des erreurs, c'est plus que sur. Mais de nouveau, ca ne le rend pas moins competent que n'importe qui ici et ce qu'il a appris en deposant son brevet en fait certainement qq'un qui en sait un peu plus que le pekin moyen.
Sinon, je vois mal ce que les avocats auraient pu faire contre un gars qui a depose un brevet. Le proces n'a jamais ete sur le fait que les brevets etaient Mal(TM), mais si Samsung/Apple avaient viole des brevets, donc le gars n'avait rien de disqualifiant.
[^] # Re: T'es gentil
Posté par pasBill pasGates . En réponse au journal Pourquoi je suis libriste intégriste.. Évalué à -9.
Et la BSD ? Et les 4235 autres licences open source ?
Faut arreter de croire que le monde informatique se limite a Microsoft et la GPL hein.
[^] # Re: Et vous pas…
Posté par pasBill pasGates . En réponse au journal Pourquoi je suis libriste intégriste.. Évalué à 0.
Il est totalement libre d'exposer son point de vue, et je suis libre de lui signaler qu'il se contredit ouvertement.
[^] # Re: T'es gentil
Posté par pasBill pasGates . En réponse au journal Pourquoi je suis libriste intégriste.. Évalué à -5.
Le libre n'est pas une religion comme les autres, la motivation n'est pas de regrouper un maximum de gens autours d'une idée délirante mais faire en sorte que tout le monde ait un maximum de droits et donc un maximum de liberté. Comment ose-tu mettre ça sur le même plan que "craint le père noël ou tu connaîtra des souffrances éternelles quand tu sera mort" ?
Ca c'est ton interpretation a toi et rien d'autre, arretes de l'eriger en verite absolue.
# T'es gentil
Posté par pasBill pasGates . En réponse au journal Pourquoi je suis libriste intégriste.. Évalué à 3.
C'est la différence qu'il y a entre une petite secte et une religion prosélyte.
C'est assez rigolo que tu te plaignes de proselytisme tout en postant un journal qui defend ton proselytisme…
Par ailleurs, je pense qu'il est dommage de présenter le logiciel libre comme un concurrent au logiciel privateur, et de n'avoir que des considérations techniques et pratiques lors des comparaisons. Le problème est complexe et dépasse très largement le cadre de l'informatique, mais les principes, l'éthique, la morale, ça compte !
Ca serait bien que tu evites d'eriger TES principes/references morales et ethiques en references absolues. C'est du proselytisme ca aussi, a tendance dictatoriale.
[^] # Re: troll de bas étage
Posté par pasBill pasGates . En réponse au journal Est-ce que la popularité d'Android permettra à Linux de progresser en adoption ?. Évalué à -2.
Je fais partie des gens qui ne comprend pas pourquoi les femmes de ménage sont moins payées que les médecins.
Entre autres parce que les medecins ont du etudier pendant des annees, annees ou ils n'ont eu aucun revenu.
Mais sinon, lis quelque bouquins d'histoire, notamment sur l'URSS, et tu comprendras pourquoi ta vision n'a absolument aucune chance de fonctionner dans le monde reel.
Alors oui, tu peux nous sortir ta theorie, qui sur le papier est super belle, mais vu qu'elle est totalement irrealiste, elle ne vaut rien.
Petit indice : si tu peux gagner autant en etant vendeur de jus d'orange qu'en etant medecin, combien de gens vont se faire ch*** a faire les etudes necessaires pour etre medecin ? Et qui va te soigner une fois qu'il n'y aura plus de medecins ?
[^] # Re: [HS] Aujourd'hui, l'innovation est morte. RIP
Posté par pasBill pasGates . En réponse à la dépêche Bref, MPlayerX quitte le Mac App Store. Évalué à -1.
Je n'ai jamais, j'ai bien dit jamais eu le moindre matos Apple.
Et pourtant quand je lis ton commentaire la, tout ce qu'il me dit c'est que tu es totalement borne avec des oeilleres de la taille d'un immeuble.
Tu aimes parler des softs proprios comme etant des prisons, mais tu devrais regarder ou se trouve ton cerveau : dans une sacre prison et il n'arrive pas a voir le monde de dehors.