Pourquoi ? A partir du moment où il y a un dieu de la guerre, ça suffit. Mieux, dans la mythologie nordique, ce sont pour ainsi dire presque tous des dieux de la guerre, ce qui mets tout le monde d'accord ...
Posté par Obsidian .
En réponse au message mdp root.
Évalué à 6.
A priori, si la chaîne codée n'est pas valide dans /etc/shadow, ça peut suffire à l'authenficateur pour déclarer que l'utilisateur ne peut pas se loguer (voir man 5 shadow). Il aurait fallu ne retirer que le x de /etc/passwd.
Mais d'une manière générale, ce qu'il faut faire, c'est utiliser les outils normaux de ta distrib' pour être sûr de faire les choses correctement.
Pour cela, tu ouvres une console depuis ta knoppix, tu démontes la partition qu'il t'a montée automatiquement si c'est le cas, tu la remontes à l'endroit de ton choix en prenant soin de la monter en rw, tu fais un chroot dessus, et tu te retrouves sur un système en état de fonctionner (enfin seulement si le noyau linux de ton serveur et celui de ta knoppix ne sont pas trop éloignés).
Dès lors, tu appelles ta commande passwd, comme si tu étais logué en root de manière ordinaire, et tu réinitalise ton mot de passe.
Bon. Loin de moi l'idée de vouloir contourner le problème (écrire le pilote devrait même être assez intéressant), mais pourquoi veux-tu mettre un gyroscope sur ton portable ?
question : il ne pouvait pas simplement graver l'image sur un cdrw ? Mais c'est sûr que vu comme ça ça parait un peu préhistorique, mais le but d'AIX c'est peut-être pas de bidouiller avec latex et les images iso...
C'est-à-dire que 1) ce n'est pas de la bidouille et 2) c'est un peu l'excuse Windows : "si ça ne marche pas, demande-toi d'abord si tu en as vraiment besoin". Le nombre de fois que j'ai entendu cela, et pas seulement dans l'informatique. De plus en plus souvent, les gens tentent de contourner un problème plutôt que d'en rechercher l'origine et ce qui est inquiétant, c'est que c'est souvent sans même s'en rendre compte.
Un jour, un copain avait un problème récurrent sous Windows, que l'on ne parvenait pas à pallier. Un jour, il m'appelle, très fier de lui
"- Ca y est ! J'ai réussi à résoudre mon problème ! Devine comment j'ai fait.
- T'as réinstallé l'application ?
- Non ...
- T'as googlisé et t'as modifié la bonne clé dans la base de registre ?
- Non ...
- Alors, quoi ?
- Tout simplement, j'ai reformaté le disque dur !
- Ok."
Dans le cas qui nous intéresse, un CD contient beaucoup de choses, souvent des archives, et devoir garder un CD-RW sous la main + un graveur, surtout sur un AIX et devoir patienter 2 à 10 minutes qu'il soit prêt, ça me saoulerait plus que de créer un pseudo-device. Et encore, c'est acceptable que si l'on a qu'une seule ISO !
Si c'est le dépôt des CD d'install d'une Fedora que l'on veut exploiter pour aller retrouver le RPM qui manque (sans connexion à Internet établie), spécialement quand on est en train de réinstaller -ou même de réparer- un serveur, alors pouvoir faire un mount direct sur n'importe quel type d'image, ça devient très appréciable.
Alors, est-ce un effet d'optique (le barres de GNOME en haut et en bas) ou est-ce une réalité?
C'est une réalité. Le truc flagrant est généralement la barre de boutons des applications telles qu'Evolution dont il faut dérouler l'extrémité pour obtenir des fonctions même usuelles comme passer d'un message à l'autre (bon, faire ça avec les boutons de la barre d'outil, c'est tordu).
C'est dû à plein de choses à mon avis. GNOME est un projet très avancé, le jeu de classes est assez impressionnant, par contre on dirait que les développeurs travaillent tous sur des machines dernier cri, et qu'ils considèrent que si ça marche chez eux, ça marche partout. Pour la barre d'outils, elle n'apparaît en entier (et n'est exploitable) que sur les portables à format panoramique vieux de moins de 3 ans.
Dans le même esprit, les thèmes graphiques de GNOME sont très gourmands eux-aussi. Pas seulement en ressources systèmes. Si un graphiste colle des bordures de 5 pixels à chaque widget, on a vite fait d'atteindre les limites de l'affichage. En plus, on commence à voir de plus en plus de programmeurs apprécier la résolution d'un moniteur comme celle d'une imprimante, alors même que la meilleure résolution d'un moniteur restera toujours au bas mot trois fois inférieure à celle d'une imprimante d'entrée de gamme. Et puis ça ne sert pas la même chose ! On ne peut pas obtenir un gris en moirant des points noirs et blanc sur un écran, comme on le ferait sur une laser.
Dans le même genre, le gnome-terminal est sympa, il gère proprement les différents codages de caractères, mais il met 4 à 5 secondes pour démarrer sur un P4/1,7Go/256Mo et chaque instance occupe 21 Mo de mémoire. C'est intolérable !
Franchement, la politique de GNOME, ça ressemble vraiment à "nous, c'est la définition du modèle objet, l'implémentation, c'est secondaire".
$VAR= #--> le process monscript remplace le bash dans lequel il a été lancé. VAR a été déclarée dans ce bash.
Attention, grosse imprécision ! "exec" remplace le contenu d'un processus, donc l'image d'un programme exécutable en langage machine, par celle d'un autre.
Ton shell n'a donc pas été remplacé par ton script mais par un autre shell, qui lui s'est initialisé comme il l'a voulu, et qui a interprété ton programme.
Si tu veux demander à ton shell courant d'interpréter lui-même un script plutôt que d'ouvrir un sous-shell, par exemple pour relire ton .bashrc après modification, il faut "sourcer" ton script. Voir la commande source ou le point tout seul (synonymes).
Pourquoi sed m'affiche le reste? c'est-à-dire "7 root root 4096 2008-03-07 10:24 /tmp/"
Parce que tu as collé ton marqueur de début de ligne "^" à l'intérieur de l'expression régulière elle-même. Fous-le au tout début de ton motif, avant le \( et ça devrais marcher beaucoup mieux.
Pour le suid, il est sans effet sur les scripts, parce que ça pose un problème de sécurité.
C'est surtout parce que le programme qui est réellement exécuté à ce moment est l'interpréteur, qui lui va lire le script. C'est donc sur celui-ci qu'il faudrait poser les bits set[gu]id. Maintenant, execve est quand même une primitive du noyau (même si celles-ci passent désormais toutes par la glibc d'abord) et donc, la fonction pourrait être implémentée quand même, mais bon. Ce serait effectivement vachement limite ...
Le pendant de ce type de base est l'HCL (Hardware Compatibility List).
Mais en fait, la principale raison pour laquelle c'est beaucoup moins flagrant que sous Windows, par exemple, est que 99% des pilotes de périphériques (ou autre) sont proposées sous forme de modules du noyau, directement inclus dans la distribution de celui-ci. Et lorsque les spécifications sont libres, alors ces modules sont automatiquement disponibles et cela marche sans que l'on ait à se poser de questions. Du coup, on ne se focalise que sur ce qui pose problème.
Exemple concret. As-tu déjà eu à installer sous Linux le pilote de ta carte Ethernet ? :-)
Un LVM sur /opt, déjà, ça me paraît vachement douteux ! :-)
Effectivement, un suivi des mouvements du fs avec [di]notify vient naturellement à l'esprit, mais comme le suppute, outre les problèmes transactionnels, les temps de latence risquent de devenir insupportables et un engorgement de la file d'événement pourrait avoir des conséquences dramatiques.
Je pense également à du raid logiciel, plutôt en fiber channel, pour que tes NBD soient directement reconnus comme tel, mais comme cette machine distante aura de toutes façons besoin d'une connexion réseau.
C'est pour faire quoi, au fait ? Je parie que, comme d'habitude, le client est parti dès le départ sur une solution irréfléchie et veut trouver à postériori une façon de l'implémenter plutôt que de revoir le concept.
Plutôt que de faire une réplication, tu peux essayer de limiter au maximum les partitions montées en rw, de monter tout ce qui peut être ro en partageant un même bus SCSI, par exemple, entre tes deux machines et en gardant tout ce qui doit être dynamique (/var et le swap) en local, + /home en NFS si réseau d'entreprise.
Dès lors, si ta machine principale tombe en panne, la seconde aura probablement besoin d'être redémarrée pour passer en production complète, mais guère plus.
si un méchant tipiak arrives à t'executer un backdoor sur ta machine pour ouvrir un port telnet/ssh/whatever-avec-un-shell sur un port que tu n'as pas bloqué sur le firewall de ton système, et bien, pleure ...
Si c'est un méchant Tipiak, qu'il arrive à installer une backdoor sur ta machine et que ton firewall tourne sur cette même machine, alors le programme lui-même va faire ouvrir le port dont il a besoin ! C'est ridicule !
La seule chose vraie est que n'importe quel programme user sur un Unix normalement constitué peut écouter légitimement les ports au dessus de 1024 sans priviliège. Maintenant, si ce n'est pas souhaitable, il faut empêcher ton méchant pirate d'accéder à ta machine, pas bloquer des ports à postériori, sinon tu vas empêcher les programmes réguliers de fonctionner normalement.
C'est dingue, çà, d'ailleurs : on s'efforce toujours de pallier les conséquences directes d'un problème au lieu d'essayer d'en déterminer les causes. Ca semble être du pur bon sens et, pourtant, c'est encore tellement fréquent que c'est enseigné dans les cours de management.
L'ennui, c'est que l'on en parle beaucoup sur Linuxfr et que ça ne va que rarement plus loin parce que les actions à mener sont beaucoup plus difficiles qu'elles n'en ont l'air.
La génération des adolescents d'aujourd'hui est celle qui n'a non seulement connu que le PC, mais qui n'a également connu que Windows !
De fait, ils sont habitués dès le plus jeune âge à ce système et ce sont les gens qui tâchent de combattre la vente liée qui passent pour des empêcheurs de tourner en rond.
Mode coup de gueule : ça et le "vaste programme" de DeGaulle, ça circule en boucle depuis le non-événement du salon de l'agriculture. On va finir par jazer là-dessus plus longtemps que sur le TCE.
Les progrès ne seront possibles que si nous pouvons réfléchir sur les programmes sans les imaginer comme des morceaux de code exécutable.
Sans remettre tout cela en cause (je suis particulièrement d'accord avec l'analogie des téléscopes), il faut quand même se souvenir de deux choses si l'on veut rester parfaitement objectif :
- On n'est pas obligé d'être forcément d'accord avec Dijkstra. Le libre, c'est aussi cela. Edsger Dijkstra a apporté beaucoup à l'informatique, mais il abordait surtout la chose en mathématicien, et ce n'est pas forcément toujours la meilleure approche, à mon goût. Et puis, il y en a eu d'autres, notamment Donald Knuth, pour qui le goto n'était pas forcément une invention du diable.
- Dijkstra a probablement écrit cette phrase à une époque où l'on n'utilisait pratiquement que la programmation impérative, même si la plupart des grands concepts en programmation ont été développés dans les années 60 et 70. Peut-être que si l'on avait filé l'UML à Dijkstra, il en aurait été satisfait (je déteste l'UML). Aujourd'hui, le paysage a tellement évolué que cette assertion n'a plus du tout le même sens.
D'une manière générale, le formalisme tel qu'enseigné dans les universités conduit souvent à des choses du style : « pour fabriquer un avion, on part de l'existant - un autobus - on lui colle deux ailes et le motorise suffisamment jusqu'à ce qu'il vole ». Il faut bien se rendre compte que si l'on avait toujours programmé de cette manière, les logiciels n'auraient commencé à être utilisables qu'avec les machines des années 2000.
Il est de fait que la « programmation intégrée » est un art qui se perd. L'époque où une machine avait des numéros de registres suffisamment statiques pour que son programmeur les connaisse et les utilise directement sans passer par des symboles. Le temps où l'on balançait un ESC 9g pour déconnecter un Minitel, etc. sont définitivement révolus. Ce n'est pas forcément une bonne chose car je pense que si un astronome n'est pas un astronome si ses connaissances se limitent à l'utilisation de son instrument, une personne qui ne l'a jamais manipulé n'en est pas un non plus.
C'est de la même manière qu'un pilote de course ne peut pas atteindre le sommet sans connaître aussi bien sa machine que le circuit, qu'un pilote d'avion doit être capable de maîtriser la mécanique de son appareil, qu'un capitaine de navire le connaît jusque dans ses moindre recoins, et qu'un grand musicien a forcément une relation avec son instrument. Selon cette idée, le logiciel le plus efficace sera forcément celui qui a été conçu pour la machine sur laquelle il est destiné à fonctionner.
En outre, c'est une notion qui a disparu avec l'engouement pour la sacro-sainte portabilité. Qu'en est-il aujourd'hui ? 99% du parc micro-informatique est équipé de PCs, tous systèmes d'exploitation confondus. Dans ces conditions, même un programme écrit directement en assembleur pourrait fonctionner presque partout.
Pour le reste, la portabilité reste très relative. Les parcs logiciels PC et Solaris sur Spark, par exemple, restent encore très distincts et les logiciels portés le sont, la plupart du temps, qu'au dessus d'une couche d'abstraction. Généralement une JVM, ou bien le système d'exploitation lui-même.
Dans ce dernier cas, si l'on ne considère que Linux, par exemple, dont le répertoire "arch" se limite au nécessaire (ce qui en soi reste une bonne chose), et qui fonctionne de manière complètement uniforme sur toutes les plateformes, quel est l'intérêt de produire des machines différentes ?
J'aimerais donc que les jeunes vocations en programmation aient l'occasion de tripatouiller leur hardware eux-mêmes comme on le faisait il n'y a pas si longtemps, sans avoir obligatoirement besoin de 15 ans d'expérience en C et en système pour pouvoir envisager écrire le pilote d'un périphérique.
Dès lors, en associant formalisme purement abstrait (sur papier) ET, en même temps, programmation dédiée très proche de la machine, alors on obtiendra les meilleurs résultats, à mon avis.
Avant cela, tout cela ne restera qu'affaire de préférence personnelle, ce qui est respectable en soi, mais pas forcément un exemple absolu.
[^] # Re: merci ...
Posté par Obsidian . En réponse au journal Le manifeste du parti linuxien, résumé pour ceux du fond qui n'écoutent pas. Évalué à 6.
[^] # Re: Un gyro ?
Posté par Obsidian . En réponse au journal Un gyroscope USB pour Linux ?. Évalué à 2.
[^] # Re: Un gyro ?
Posté par Obsidian . En réponse au journal Un gyroscope USB pour Linux ?. Évalué à 6.
Ouille ! Il m'a fallu 4 bonnes secondes pour comprendre ... :-\
# /etc/passwd
Posté par Obsidian . En réponse au message mdp root. Évalué à 6.
Mais d'une manière générale, ce qu'il faut faire, c'est utiliser les outils normaux de ta distrib' pour être sûr de faire les choses correctement.
Pour cela, tu ouvres une console depuis ta knoppix, tu démontes la partition qu'il t'a montée automatiquement si c'est le cas, tu la remontes à l'endroit de ton choix en prenant soin de la monter en rw, tu fais un chroot dessus, et tu te retrouves sur un système en état de fonctionner (enfin seulement si le noyau linux de ton serveur et celui de ta knoppix ne sont pas trop éloignés).
Dès lors, tu appelles ta commande passwd, comme si tu étais logué en root de manière ordinaire, et tu réinitalise ton mot de passe.
[^] # Re: Zut !
Posté par Obsidian . En réponse au journal Un gyroscope USB pour Linux ?. Évalué à 2.
# Un gyro ?
Posté par Obsidian . En réponse au journal Un gyroscope USB pour Linux ?. Évalué à 4.
[^] # Re: Néant :
Posté par Obsidian . En réponse au journal Y a-t-il des lycéens (ou des profs) franciliens dans la salle ?. Évalué à 2.
M'intéresse. Lequel ?
[^] # Re: LDAP
Posté par Obsidian . En réponse au message gestion utlisateurs. Évalué à 2.
$ man pam
[^] # Re: faut pas chipoter
Posté par Obsidian . En réponse au journal AIX - Mais quel avenir ?. Évalué à 6.
C'est-à-dire que 1) ce n'est pas de la bidouille et 2) c'est un peu l'excuse Windows : "si ça ne marche pas, demande-toi d'abord si tu en as vraiment besoin". Le nombre de fois que j'ai entendu cela, et pas seulement dans l'informatique. De plus en plus souvent, les gens tentent de contourner un problème plutôt que d'en rechercher l'origine et ce qui est inquiétant, c'est que c'est souvent sans même s'en rendre compte.
Un jour, un copain avait un problème récurrent sous Windows, que l'on ne parvenait pas à pallier. Un jour, il m'appelle, très fier de lui
"- Ca y est ! J'ai réussi à résoudre mon problème ! Devine comment j'ai fait.
- T'as réinstallé l'application ?
- Non ...
- T'as googlisé et t'as modifié la bonne clé dans la base de registre ?
- Non ...
- Alors, quoi ?
- Tout simplement, j'ai reformaté le disque dur !
- Ok."
Dans le cas qui nous intéresse, un CD contient beaucoup de choses, souvent des archives, et devoir garder un CD-RW sous la main + un graveur, surtout sur un AIX et devoir patienter 2 à 10 minutes qu'il soit prêt, ça me saoulerait plus que de créer un pseudo-device. Et encore, c'est acceptable que si l'on a qu'une seule ISO !
Si c'est le dépôt des CD d'install d'une Fedora que l'on veut exploiter pour aller retrouver le RPM qui manque (sans connexion à Internet établie), spécialement quand on est en train de réinstaller -ou même de réparer- un serveur, alors pouvoir faire un mount direct sur n'importe quel type d'image, ça devient très appréciable.
# Oui.
Posté par Obsidian . En réponse au message Bonne résolution Linux vs Windows. Évalué à 6.
C'est une réalité. Le truc flagrant est généralement la barre de boutons des applications telles qu'Evolution dont il faut dérouler l'extrémité pour obtenir des fonctions même usuelles comme passer d'un message à l'autre (bon, faire ça avec les boutons de la barre d'outil, c'est tordu).
C'est dû à plein de choses à mon avis. GNOME est un projet très avancé, le jeu de classes est assez impressionnant, par contre on dirait que les développeurs travaillent tous sur des machines dernier cri, et qu'ils considèrent que si ça marche chez eux, ça marche partout. Pour la barre d'outils, elle n'apparaît en entier (et n'est exploitable) que sur les portables à format panoramique vieux de moins de 3 ans.
Dans le même esprit, les thèmes graphiques de GNOME sont très gourmands eux-aussi. Pas seulement en ressources systèmes. Si un graphiste colle des bordures de 5 pixels à chaque widget, on a vite fait d'atteindre les limites de l'affichage. En plus, on commence à voir de plus en plus de programmeurs apprécier la résolution d'un moniteur comme celle d'une imprimante, alors même que la meilleure résolution d'un moniteur restera toujours au bas mot trois fois inférieure à celle d'une imprimante d'entrée de gamme. Et puis ça ne sert pas la même chose ! On ne peut pas obtenir un gris en moirant des points noirs et blanc sur un écran, comme on le ferait sur une laser.
On en parlait déja ici :
https://linuxfr.org//comments/734074.html#734074
Dans le même genre, le gnome-terminal est sympa, il gère proprement les différents codages de caractères, mais il met 4 à 5 secondes pour démarrer sur un P4/1,7Go/256Mo et chaque instance occupe 21 Mo de mémoire. C'est intolérable !
Franchement, la politique de GNOME, ça ressemble vraiment à "nous, c'est la définition du modèle objet, l'implémentation, c'est secondaire".
# Bien lire les manpages
Posté par Obsidian . En réponse au message diverses questions : permissions, bash/exec, suid et sed. Évalué à 3.
$VAR= #--> le process monscript remplace le bash dans lequel il a été lancé. VAR a été déclarée dans ce bash.
Attention, grosse imprécision ! "exec" remplace le contenu d'un processus, donc l'image d'un programme exécutable en langage machine, par celle d'un autre.
Ton shell n'a donc pas été remplacé par ton script mais par un autre shell, qui lui s'est initialisé comme il l'a voulu, et qui a interprété ton programme.
Si tu veux demander à ton shell courant d'interpréter lui-même un script plutôt que d'ouvrir un sous-shell, par exemple pour relire ton .bashrc après modification, il faut "sourcer" ton script. Voir la commande source ou le point tout seul (synonymes).
Pourquoi sed m'affiche le reste? c'est-à-dire "7 root root 4096 2008-03-07 10:24 /tmp/"
Parce que tu as collé ton marqueur de début de ligne "^" à l'intérieur de l'expression régulière elle-même. Fous-le au tout début de ton motif, avant le \( et ça devrais marcher beaucoup mieux.
[^] # Re: Quelques réponses :
Posté par Obsidian . En réponse au message diverses questions : permissions, bash/exec, suid et sed. Évalué à 3.
C'est surtout parce que le programme qui est réellement exécuté à ce moment est l'interpréteur, qui lui va lire le script. C'est donc sur celui-ci qu'il faudrait poser les bits set[gu]id. Maintenant, execve est quand même une primitive du noyau (même si celles-ci passent désormais toutes par la glibc d'abord) et donc, la fonction pourrait être implémentée quand même, mais bon. Ce serait effectivement vachement limite ...
On en parlait déjà ici :
https://linuxfr.org/forums/10/23583.html
[^] # UPDATE
Posté par Obsidian . En réponse au message Idée bouillonnante : Une base de drivers sur la Banquise .... Évalué à 2.
Bien évidemment il existe déjà des ressources telles que linux-drivers.org.
Désolé, il est tard.
# HCL et cie.
Posté par Obsidian . En réponse au message Idée bouillonnante : Une base de drivers sur la Banquise .... Évalué à 2.
http://www.linux-drivers.org/
Le pendant de ce type de base est l'HCL (Hardware Compatibility List).
Mais en fait, la principale raison pour laquelle c'est beaucoup moins flagrant que sous Windows, par exemple, est que 99% des pilotes de périphériques (ou autre) sont proposées sous forme de modules du noyau, directement inclus dans la distribution de celui-ci. Et lorsque les spécifications sont libres, alors ces modules sont automatiquement disponibles et cela marche sans que l'on ait à se poser de questions. Du coup, on ne se focalise que sur ce qui pose problème.
Exemple concret. As-tu déjà eu à installer sous Linux le pilote de ta carte Ethernet ? :-)
[^] # Re: Partage SCSI, par exemple.
Posté par Obsidian . En réponse au message lvm + dmraid + nbd. Évalué à 2.
Effectivement, un suivi des mouvements du fs avec [di]notify vient naturellement à l'esprit, mais comme le suppute, outre les problèmes transactionnels, les temps de latence risquent de devenir insupportables et un engorgement de la file d'événement pourrait avoir des conséquences dramatiques.
Je pense également à du raid logiciel, plutôt en fiber channel, pour que tes NBD soient directement reconnus comme tel, mais comme cette machine distante aura de toutes façons besoin d'une connexion réseau.
C'est pour faire quoi, au fait ? Je parie que, comme d'habitude, le client est parti dès le départ sur une solution irréfléchie et veut trouver à postériori une façon de l'implémenter plutôt que de revoir le concept.
# Partage SCSI, par exemple.
Posté par Obsidian . En réponse au message lvm + dmraid + nbd. Évalué à 2.
Dès lors, si ta machine principale tombe en panne, la seconde aura probablement besoin d'être redémarrée pour passer en production complète, mais guère plus.
[^] # Re: faut pas chipoter
Posté par Obsidian . En réponse au journal AIX - Mais quel avenir ?. Évalué à 7.
D'autant plus que la fonction, au final, est quand même assurée, et que l'article précise bien qu'il s'agit d'un workaround.
Essayez de monter facilement une image *.iso ou autre sous Windows, pour voir ... :-)
[^] # Re: DROP!
Posté par Obsidian . En réponse au journal Les pare-feu. Évalué à 3.
Si c'est un méchant Tipiak, qu'il arrive à installer une backdoor sur ta machine et que ton firewall tourne sur cette même machine, alors le programme lui-même va faire ouvrir le port dont il a besoin ! C'est ridicule !
La seule chose vraie est que n'importe quel programme user sur un Unix normalement constitué peut écouter légitimement les ports au dessus de 1024 sans priviliège. Maintenant, si ce n'est pas souhaitable, il faut empêcher ton méchant pirate d'accéder à ta machine, pas bloquer des ports à postériori, sinon tu vas empêcher les programmes réguliers de fonctionner normalement.
C'est dingue, çà, d'ailleurs : on s'efforce toujours de pallier les conséquences directes d'un problème au lieu d'essayer d'en déterminer les causes. Ca semble être du pur bon sens et, pourtant, c'est encore tellement fréquent que c'est enseigné dans les cours de management.
[^] # Re: DROP!
Posté par Obsidian . En réponse au journal Les pare-feu. Évalué à 5.
L'orthographe correcte est « Or, ... »
Merci de votre attention.
[^] # Re: vim ou emacs
Posté par Obsidian . En réponse au message Marre des transferts ftp faits à la main. Évalué à 2.
[^] # Re: liberté
Posté par Obsidian . En réponse au journal Le logiciel libre obligatoire à l'école ?. Évalué à 3.
La génération des adolescents d'aujourd'hui est celle qui n'a non seulement connu que le PC, mais qui n'a également connu que Windows !
De fait, ils sont habitués dès le plus jeune âge à ce système et ce sont les gens qui tâchent de combattre la vente liée qui passent pour des empêcheurs de tourner en rond.
[^] # Re: liberté
Posté par Obsidian . En réponse au journal Le logiciel libre obligatoire à l'école ?. Évalué à -2.
Mode coup de gueule : ça et le "vaste programme" de DeGaulle, ça circule en boucle depuis le non-événement du salon de l'agriculture. On va finir par jazer là-dessus plus longtemps que sur le TCE.
# Le plus geek ...
Posté par Obsidian . En réponse au sondage Au petit-déjeuner je prends. Évalué à 2.
Je sors ->[]
[^] # Re: liberté
Posté par Obsidian . En réponse au journal Le logiciel libre obligatoire à l'école ?. Évalué à 4.
[^] # Re: liberté
Posté par Obsidian . En réponse au journal Le logiciel libre obligatoire à l'école ?. Évalué à 3.
Sans remettre tout cela en cause (je suis particulièrement d'accord avec l'analogie des téléscopes), il faut quand même se souvenir de deux choses si l'on veut rester parfaitement objectif :
- On n'est pas obligé d'être forcément d'accord avec Dijkstra. Le libre, c'est aussi cela. Edsger Dijkstra a apporté beaucoup à l'informatique, mais il abordait surtout la chose en mathématicien, et ce n'est pas forcément toujours la meilleure approche, à mon goût. Et puis, il y en a eu d'autres, notamment Donald Knuth, pour qui le goto n'était pas forcément une invention du diable.
- Dijkstra a probablement écrit cette phrase à une époque où l'on n'utilisait pratiquement que la programmation impérative, même si la plupart des grands concepts en programmation ont été développés dans les années 60 et 70. Peut-être que si l'on avait filé l'UML à Dijkstra, il en aurait été satisfait (je déteste l'UML). Aujourd'hui, le paysage a tellement évolué que cette assertion n'a plus du tout le même sens.
D'une manière générale, le formalisme tel qu'enseigné dans les universités conduit souvent à des choses du style : « pour fabriquer un avion, on part de l'existant - un autobus - on lui colle deux ailes et le motorise suffisamment jusqu'à ce qu'il vole ». Il faut bien se rendre compte que si l'on avait toujours programmé de cette manière, les logiciels n'auraient commencé à être utilisables qu'avec les machines des années 2000.
Il est de fait que la « programmation intégrée » est un art qui se perd. L'époque où une machine avait des numéros de registres suffisamment statiques pour que son programmeur les connaisse et les utilise directement sans passer par des symboles. Le temps où l'on balançait un ESC 9g pour déconnecter un Minitel, etc. sont définitivement révolus. Ce n'est pas forcément une bonne chose car je pense que si un astronome n'est pas un astronome si ses connaissances se limitent à l'utilisation de son instrument, une personne qui ne l'a jamais manipulé n'en est pas un non plus.
C'est de la même manière qu'un pilote de course ne peut pas atteindre le sommet sans connaître aussi bien sa machine que le circuit, qu'un pilote d'avion doit être capable de maîtriser la mécanique de son appareil, qu'un capitaine de navire le connaît jusque dans ses moindre recoins, et qu'un grand musicien a forcément une relation avec son instrument. Selon cette idée, le logiciel le plus efficace sera forcément celui qui a été conçu pour la machine sur laquelle il est destiné à fonctionner.
En outre, c'est une notion qui a disparu avec l'engouement pour la sacro-sainte portabilité. Qu'en est-il aujourd'hui ? 99% du parc micro-informatique est équipé de PCs, tous systèmes d'exploitation confondus. Dans ces conditions, même un programme écrit directement en assembleur pourrait fonctionner presque partout.
Pour le reste, la portabilité reste très relative. Les parcs logiciels PC et Solaris sur Spark, par exemple, restent encore très distincts et les logiciels portés le sont, la plupart du temps, qu'au dessus d'une couche d'abstraction. Généralement une JVM, ou bien le système d'exploitation lui-même.
Dans ce dernier cas, si l'on ne considère que Linux, par exemple, dont le répertoire "arch" se limite au nécessaire (ce qui en soi reste une bonne chose), et qui fonctionne de manière complètement uniforme sur toutes les plateformes, quel est l'intérêt de produire des machines différentes ?
J'aimerais donc que les jeunes vocations en programmation aient l'occasion de tripatouiller leur hardware eux-mêmes comme on le faisait il n'y a pas si longtemps, sans avoir obligatoirement besoin de 15 ans d'expérience en C et en système pour pouvoir envisager écrire le pilote d'un périphérique.
Dès lors, en associant formalisme purement abstrait (sur papier) ET, en même temps, programmation dédiée très proche de la machine, alors on obtiendra les meilleurs résultats, à mon avis.
Avant cela, tout cela ne restera qu'affaire de préférence personnelle, ce qui est respectable en soi, mais pas forcément un exemple absolu.