Je te remerci pour tout , mais je pense que je vais finalement simplement faire afficher un message d'avertissement , afin de savoir qu'il faut éteindre ses hauts-parleurs pendant le traitement.
Dans le cas présent , ce que je trouve particulièrement dommage c'est qu'une chose que je pouvais faire simplement et rapidement (grace aux principes unix de redirection et de fichier ) , je ne peux plus le faire simplement. Ici, la complexité pour régler un problème trivial augmente de manière géométrique par rapport à son seuil inital (qui était celui qui est le plus proche de l'idéal en terme d'investissement de temps par rapport au résultat escompté).
de manière quantifié il est simple de voir qu'une ligne de commande m'aurais pris tout au plus 10 minutes (pour faire large ). Dans le cas présent , si l'on prend pour point de départ le message inital est posté à 20:56 , il est maintenant 11:39 , si l'on ne compte pas les temps non passé à essayer de trouver une solution (sommeil , repas … ), alors on a environs
20:46 à 23:10
= 2h24 minutes
23:10 à 00:03
= 47 minutes
10:59 à 11:29
= 30 minutes
Total = 3 h41 minutes (sans compter ce post ci) soit 221 minutes.
En comparant avec le temps inital idéal ( 10 minutes ) , nous avons une augmentation de ((221 minutes * 100 ) /10） 2210 % avec un résultat tout aussi négatif, dont la dernière piste emmène au delà du but original et promet une augmentation de la complexité encore plus géométrique, sans aucune garantie de résultat.
Je pense que c'est ce qu'on appel le cout de la complexité qui entraine un gaspillage énorme de temps pour un résultat ridicule ou meme sans retour du tout.
Cela nous apprends aussi que la simplicité proné par les principes Unix ont pour effet de contenir cette augmentation géométrique de la complexité pour un résultat supérieur. Ainsi suivre ceux-ci permet de garder le seuil d'investissement à son niveau le plus optimal dans une situation donnée.
L'on comprend dès lors la frustration de l'usager lorsqu'un composant important de l'ordinateur (le serveur de son ) , envoie ballader ces principes (qui ont fait leur preuve). Et lorsque ce type de comportement s'étend à d'autres partie du système (par exemple la journalisation ) tout aussi stratégique, la fustration ne peut que faire qu'augmenter. Ce n'est ici pas une querelle de chapelle , mais une question d'efficacité.
(et j'ai encore sous estimé le temps car j'ai pris pour point de départ le premier message , alors qu'en fait cela vient bien avant)
[^] # Re: /dev/null
Posté par eastwind☯ . En réponse au message redirection de la sortie audio vers /dev/null. Évalué à 2. Dernière modification le 18 août 2012 à 11:59.
Je te remerci pour tout , mais je pense que je vais finalement simplement faire afficher un message d'avertissement , afin de savoir qu'il faut éteindre ses hauts-parleurs pendant le traitement.
Dans le cas présent , ce que je trouve particulièrement dommage c'est qu'une chose que je pouvais faire simplement et rapidement (grace aux principes unix de redirection et de fichier ) , je ne peux plus le faire simplement. Ici, la complexité pour régler un problème trivial augmente de manière géométrique par rapport à son seuil inital (qui était celui qui est le plus proche de l'idéal en terme d'investissement de temps par rapport au résultat escompté).
de manière quantifié il est simple de voir qu'une ligne de commande m'aurais pris tout au plus 10 minutes (pour faire large ). Dans le cas présent , si l'on prend pour point de départ le message inital est posté à 20:56 , il est maintenant 11:39 , si l'on ne compte pas les temps non passé à essayer de trouver une solution (sommeil , repas … ), alors on a environs
Total = 3 h41 minutes (sans compter ce post ci) soit 221 minutes.
En comparant avec le temps inital idéal ( 10 minutes ) , nous avons une augmentation de ((221 minutes * 100 ) /10） 2210 % avec un résultat tout aussi négatif, dont la dernière piste emmène au delà du but original et promet une augmentation de la complexité encore plus géométrique, sans aucune garantie de résultat.
Je pense que c'est ce qu'on appel le cout de la complexité qui entraine un gaspillage énorme de temps pour un résultat ridicule ou meme sans retour du tout.
Cela nous apprends aussi que la simplicité proné par les principes Unix ont pour effet de contenir cette augmentation géométrique de la complexité pour un résultat supérieur. Ainsi suivre ceux-ci permet de garder le seuil d'investissement à son niveau le plus optimal dans une situation donnée.
L'on comprend dès lors la frustration de l'usager lorsqu'un composant important de l'ordinateur (le serveur de son ) , envoie ballader ces principes (qui ont fait leur preuve). Et lorsque ce type de comportement s'étend à d'autres partie du système (par exemple la journalisation ) tout aussi stratégique, la fustration ne peut que faire qu'augmenter. Ce n'est ici pas une querelle de chapelle , mais une question d'efficacité.
(et j'ai encore sous estimé le temps car j'ai pris pour point de départ le premier message , alors qu'en fait cela vient bien avant)