Certe. J'ai moi même sur ma bécane quelques scripts avec les paths en dure.
Sûre qu'un programme d'importance a déjà fait cette connerie.
Bref, tu finis par l'admettre, il faut souvent éduquer le développeur à certains concepts (multi-utilisateur) et pratiques ($HOME), même si là c'est rapide à détecter/apprendre.
Pour le reste et les prob de sécurité avec /tmp, t'as sûrement raison, t'es plus à même de savoir de quoi tu parles.
Je penses que pour le côté multi-utilisateur, on a fait le tour.
Allez je vais en rajouter une petite couche identique pour le multi-tâche (ton 2ème exemple dans le texte du journal) :
Si l'OS est multi-tache, c'est à l'OS d'être multi-tache
Je comprend où est le problème là encore. Ta phrase est stupide au possible, tu peux remplacer multi-tâche par n'importe quoi :
Si la voiture est rouge, c'est à la voiture d'être rouge. (Ah bah ça c'est sûr :) )
Ta phrase devrait plutôt être :
Si l'OS est multi-tâche, c'est qu'il fournit un mécanisme de multi-tâche. (celà ressemble plus à une définition)
Et là, à plus forte raison que pour le côté multi-utilisteur, si le développeur ne fait rien pour que son appli soit multi-tâche, elle ne le sera pas (sauf si les libs qu'il utilise le sont à son insu bien entendu, mais là encore on remet le problème en dessous). Ce sera une appli mono-tâche qui tournera là encore bien sur un multi-tâche. Là encore il peut être fortement intéressant de "sensibiliser" les développeur à la pratique du multi-tâche, surtout avec système multi-core qui apparaîssent. J'espère que tu es convaincu que il faut pousser le cul des développeurs pour qu'ils évitent de rester sur les acquis, et parcque l'OS ne peut pas tout faire, et que l'environnement/machine évolue.
Perso, je préfère que l'OS n'en fasse pas trop (pour moi l'OS c'est le kernel, et son rôle est principalement de gérer les processus et de faire une première couche d'abstraction avec le matériel pour gérer les entrées/sorties), mais qu'il le fasse bien.
[^] # Re: 007 versus Rest Of The World
Posté par TImaniac (site web personnel) . En réponse au journal Unix : ton esprit fout le camp. Évalué à 2.
Sûre qu'un programme d'importance a déjà fait cette connerie.
Bref, tu finis par l'admettre, il faut souvent éduquer le développeur à certains concepts (multi-utilisateur) et pratiques ($HOME), même si là c'est rapide à détecter/apprendre.
Pour le reste et les prob de sécurité avec /tmp, t'as sûrement raison, t'es plus à même de savoir de quoi tu parles.
Je penses que pour le côté multi-utilisateur, on a fait le tour.
Allez je vais en rajouter une petite couche identique pour le multi-tâche (ton 2ème exemple dans le texte du journal) :
Si l'OS est multi-tache, c'est à l'OS d'être multi-tache
Je comprend où est le problème là encore. Ta phrase est stupide au possible, tu peux remplacer multi-tâche par n'importe quoi :
Si la voiture est rouge, c'est à la voiture d'être rouge. (Ah bah ça c'est sûr :) )
Ta phrase devrait plutôt être :
Si l'OS est multi-tâche, c'est qu'il fournit un mécanisme de multi-tâche. (celà ressemble plus à une définition)
Et là, à plus forte raison que pour le côté multi-utilisteur, si le développeur ne fait rien pour que son appli soit multi-tâche, elle ne le sera pas (sauf si les libs qu'il utilise le sont à son insu bien entendu, mais là encore on remet le problème en dessous). Ce sera une appli mono-tâche qui tournera là encore bien sur un multi-tâche. Là encore il peut être fortement intéressant de "sensibiliser" les développeur à la pratique du multi-tâche, surtout avec système multi-core qui apparaîssent. J'espère que tu es convaincu que il faut pousser le cul des développeurs pour qu'ils évitent de rester sur les acquis, et parcque l'OS ne peut pas tout faire, et que l'environnement/machine évolue.
Perso, je préfère que l'OS n'en fasse pas trop (pour moi l'OS c'est le kernel, et son rôle est principalement de gérer les processus et de faire une première couche d'abstraction avec le matériel pour gérer les entrées/sorties), mais qu'il le fasse bien.