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.
C'est une des choses qui m'agacent profondément dans le monde Windows. Les pare-feux personnels en tant qu'applications, en soi, c'est déjà une hérésie, parce qu'ils fonctionnent sur la machine qu'ils sont censés protéger. On a tous trouvé ça absurde quand c'est sorti, mais maintenant, les gens se sentent en sécurité parce qu'ils « ont fait les démarches nécessaires ».
L'application notepad.exe veut se connecter a 23.45.75.135 (vilainpirate.com), Autoriser ? Oui/Non Ce qui permet de protéger la passoire de tout ce qui est déjà rentré par l'intermédiaire de couveuses a virus style outlook, ie et compagnie de ne pas pouvoir sortir. Du coup le cheval de Troie rentré va avoir bien du mal à se rendre utile sans pouvoir téléphoner maison.
C'est hallucinant parce que :
1) Il vaut mieux empêcher le spyware de rentrer et, à tout le moins, le nettoyer plutôt que de mettre une couche par dessus quelque chose qui est percé en soi.
2) Qu'est-ce qui empêche un programme malfaisant installé en local de tripatouiller le pare-feu pour s'octroyer les droits dont il a besoin ?
Le VERP ou autre truc similaire est utile dans une mailing list par exemple. On a eu le cas, un jour, d'un type indésirable qui lisait le courrier d'un des abonnés.
D'une manière générale, dans ton cas, si ça n'a pas d'intérêt, c'est parce que le message de retour du mailer daemon contient l'adresse concernée dans le corps mais c'est loin d'être obligatoire en soi, et quand l'information est disponible, elle ne l'est jamais au même endroit.
Si c'est directement le nom de l'expéditeur que tu changes, tu peux identifier à coup sûr le message concerné avant même de recevoir le corps de la réponse ...
J'y connais pratiquement rien, mais visiblement, VERP, ce n'est qu'une manière de faire, et qui consiste à saler le return path de chaque mail avec un identifiant unique de manière à réassocier le message de retour avec l'exemplaire exact du courrier envoyé. Donc, à mon avis, ton 2) va avec ton 1).
Bravo pour avoir fait l'effort de chercher. C'est encore trop rare. Sinon, je conçois complètement que la syntaxe de sed est obscure quand on n'a pas l'habitude.
Côté format des expressions régulières sous Unix :
^ en début d'expression représente le début de la ligne. Ca permet de se référer à ce début plutôt qu'à n'importe quelle position. Juste après un crochet ouvrant, il complémente l'ensemble, sinon, c'est un caractère ordinaire. $ en fin d'expression représente la fin de la ligne. Sinon, c'est un caractère ordinaire.
La syntaxe de sed pour la commande s (substitute) est :
commande/motif à retrouver/motif de remplacement/options
Bien que n'importe quel caractère puisse servir de séparateur, le slash est le plus fréquement utilisé. Cependant, lorsqu'une expression contient elle aussi des slashes, il faut les alors échapper avec un contre-slash "\".
Ensuite, certains méta-caractères des expressions régulières doivent toujours êtres échappés aussi pour fonctionner, sinon, ils sont pris pour des caractères normaux. Pour d'autres, c'est le contraire.
Les opérateurs à échapper sont +,?,{,},(,) (ainsi que le slash si utilisé comme séparateur, et les chiffres, pour rappeler les motifs).
Les opérateurs à ne pas échapper sont *,^,[,],.
Les parenthèses, au niveau des regexps, servent à former des groupes sur lequels on peut appliquer des opérateurs (de l'algèbre classique, quoi), mais sed reconnaît également les groupes de premier niveau (ceux qui ne sont pas déjà eux-mêmes entre parenthèses), et permet de les rappeler ensuite avec \1, \2, \3, ...
De là :
^.*\/\([0-9]\{8\}\)\/.*$ correspond en fait à ^.*/([0-9]{8})/.*$, ce qui signifie "début de ligne, puis n'importe quel groupe de caractère puis un slash (échappé), puis un groupe de huit chiffrs exactement, puis un slash, puis n'importe quel groupe de caractère à nouveau, enfin une fin de ligne".
On met le groupe de huit chiffres entre parenthèses pour pouvoir le retrouver ensuite. Et on lui accole des slashes qui sont en fait ceux du chemin d'accès, de façon à retrouver nom un répertoire qui soit effectivement formés de huit chiffres, et non qui contienne huit chiffres.
Cette expression reconnaît la ligne entière, le motif de substition va donc la remplacer entièrement. Le \1 dans le deuxième champ indique que le nouveau motif est la date extraite uniquement. Tout le reste disparaît, donc.
L'option g signifie greedy. Elle sert à lever une ambigüité des expressions régulières. Quand plusieurs motifs identiques se suivent et que l'on utilise *, l'analyseur ne sait pas s'il faut s'arrêter au premier motif reconnu, ou au contraire tous les lire jusqu'à ce que ça ne corresponde plus. Par défaut, il se cantonne au premier cas, le mode greedy le fait opter pour le second.
Dans le cas de sed, c'est différent mais quand même similaire : sed stoppe l'opération une fois que la première substitution est faite. Avec g, il lira la ligne entière et substituera chaque fois que c'est possible.
[^] # 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.
[^] # Re: Moi
Posté par Obsidian . En réponse au journal Les pare-feu. Évalué à 5.
"Defense in depth". Non mais je rêve !
[^] # Re: Moi
Posté par Obsidian . En réponse au journal Les pare-feu. Évalué à 5.
Tu arrives à rediriger le port 653984 en TCP/IP ? Faudra que tu me montres comment tu fais :-)
[^] # Re: Moi
Posté par Obsidian . En réponse au journal Les pare-feu. Évalué à 5.
L'application notepad.exe veut se connecter a 23.45.75.135 (vilainpirate.com), Autoriser ? Oui/Non Ce qui permet de protéger la passoire de tout ce qui est déjà rentré par l'intermédiaire de couveuses a virus style outlook, ie et compagnie de ne pas pouvoir sortir. Du coup le cheval de Troie rentré va avoir bien du mal à se rendre utile sans pouvoir téléphoner maison.
C'est hallucinant parce que :
1) Il vaut mieux empêcher le spyware de rentrer et, à tout le moins, le nettoyer plutôt que de mettre une couche par dessus quelque chose qui est percé en soi.
2) Qu'est-ce qui empêche un programme malfaisant installé en local de tripatouiller le pare-feu pour s'octroyer les droits dont il a besoin ?
[^] # Re: Hmm ... Verp ...
Posté par Obsidian . En réponse au message Comment gérer les bounces ?. Évalué à 2.
D'une manière générale, dans ton cas, si ça n'a pas d'intérêt, c'est parce que le message de retour du mailer daemon contient l'adresse concernée dans le corps mais c'est loin d'être obligatoire en soi, et quand l'information est disponible, elle ne l'est jamais au même endroit.
Si c'est directement le nom de l'expéditeur que tu changes, tu peux identifier à coup sûr le message concerné avant même de recevoir le corps de la réponse ...
# Hmm ... Verp ...
Posté par Obsidian . En réponse au message Comment gérer les bounces ?. Évalué à 2.
[^] # Re: Regexps ...
Posté par Obsidian . En réponse au message Extraire un bout de chaîne. Évalué à 2.
Quelques autres posts marrants (pour faire notamment autre chose que de la substitution) ici :
https://linuxfr.org//forums/26/6648.html
https://linuxfr.org//forums/26/23207.html
[^] # Re: Regexps ...
Posté par Obsidian . En réponse au message Extraire un bout de chaîne. Évalué à 3.
Côté format des expressions régulières sous Unix :
^ en début d'expression représente le début de la ligne. Ca permet de se référer à ce début plutôt qu'à n'importe quelle position. Juste après un crochet ouvrant, il complémente l'ensemble, sinon, c'est un caractère ordinaire.
$ en fin d'expression représente la fin de la ligne. Sinon, c'est un caractère ordinaire.
La syntaxe de sed pour la commande s (substitute) est :
commande/motif à retrouver/motif de remplacement/options
Bien que n'importe quel caractère puisse servir de séparateur, le slash est le plus fréquement utilisé. Cependant, lorsqu'une expression contient elle aussi des slashes, il faut les alors échapper avec un contre-slash "\".
Ensuite, certains méta-caractères des expressions régulières doivent toujours êtres échappés aussi pour fonctionner, sinon, ils sont pris pour des caractères normaux. Pour d'autres, c'est le contraire.
Les opérateurs à échapper sont +,?,{,},(,) (ainsi que le slash si utilisé comme séparateur, et les chiffres, pour rappeler les motifs).
Les opérateurs à ne pas échapper sont *,^,[,],.
Les parenthèses, au niveau des regexps, servent à former des groupes sur lequels on peut appliquer des opérateurs (de l'algèbre classique, quoi), mais sed reconnaît également les groupes de premier niveau (ceux qui ne sont pas déjà eux-mêmes entre parenthèses), et permet de les rappeler ensuite avec \1, \2, \3, ...
De là :
^.*\/\([0-9]\{8\}\)\/.*$ correspond en fait à ^.*/([0-9]{8})/.*$, ce qui signifie "début de ligne, puis n'importe quel groupe de caractère puis un slash (échappé), puis un groupe de huit chiffrs exactement, puis un slash, puis n'importe quel groupe de caractère à nouveau, enfin une fin de ligne".
On met le groupe de huit chiffres entre parenthèses pour pouvoir le retrouver ensuite. Et on lui accole des slashes qui sont en fait ceux du chemin d'accès, de façon à retrouver nom un répertoire qui soit effectivement formés de huit chiffres, et non qui contienne huit chiffres.
Cette expression reconnaît la ligne entière, le motif de substition va donc la remplacer entièrement. Le \1 dans le deuxième champ indique que le nouveau motif est la date extraite uniquement. Tout le reste disparaît, donc.
L'option g signifie greedy. Elle sert à lever une ambigüité des expressions régulières. Quand plusieurs motifs identiques se suivent et que l'on utilise *, l'analyseur ne sait pas s'il faut s'arrêter au premier motif reconnu, ou au contraire tous les lire jusqu'à ce que ça ne corresponde plus. Par défaut, il se cantonne au premier cas, le mode greedy le fait opter pour le second.
Dans le cas de sed, c'est différent mais quand même similaire : sed stoppe l'opération une fois que la première substitution est faite. Avec g, il lira la ligne entière et substituera chaque fois que c'est possible.
[^] # Re: Que vont-ils faire ?
Posté par Obsidian . En réponse à la dépêche La Commission inflige à Microsoft une amende de 899 millions € pour non-respect de la décision de mars 2004. Évalué à 4.