Dans la finalité, probablement, d'un point de vue technique et sur la manière d'y parvenir, c'est un peu différent. ITER veut maîtriser la fusion atomique, et pas la fission. D'après ce que j'ai entendu, cela a beaucoup d'avantages, comme celui de ne pas produire de déchets nucléaires (seule l'enceinte est radioactive) et d'utiliser le deutérium et le tritium, isotopes de l'hydrogène, que l'on extraierait de l'eau de mer, ce qui en fait une source quasi-inépuisable. Arpès réaction, on libère de l'hélium.
Des concurrents pour ceux dont c'est réellement la vocation, surtout. Aujourd'hui, on travaille dans un secteur victime d'une mini-crise boursière, et complètement obstrué par une population entière de techniciens à l'expérience minimum, parce que soit formés en urgence, soit atterris ici parce qu'ils ont vu de la lumière.
Moralité, la supériorité de l'offre a fait dramatiquement chuter les salaires, et la proportion de débutants l'a fait tomber de plus belle. Impossible aujourd'hui de vendre une expérience ou d'imposer un développement de qualité car le recruteur va être submergé dès le départ d'offres à très bas prix. Et derrière, la qualité du logiciel produit ou de la prestation apportée est à la hauteur de cette situation et s'impose en standard.
On va surtout dire que 1998-99 était la période d'euphorie. En 2000, on sentait déjà les branches craquer, et en 2001 ce fût le crash complet.
Ce qui est malheureux, c'est que tous les gens qui avaient un minimum d'expérience en informatique voyaient cela venir. 20M$ de levée de fonds pour une simple dot.com, avec tous les investisseurs qui se précipitaient à qui mieux mieux pour être sûrs d'en avoir une part, on allait bien le payer un jour. Non seulement, je pense que l'on a pas fini de s'en remettre, mais qu'en plus, même à l'avenir, toutes les compagnies vont rester méfiantes maintenant.
Parce que http et https sont deux protocoles différents (enfin le second est le premier au dessus de la couche de codage) ! Et qu'en l'occurence c'est le serveur web normal qui répond au port 80 et au 443. Ton connection refused n'est pas dù à un port fermé mais à une transaction SSL qui ne peut être négociée.
C'est un module, mod-ssl, qui s'occupe de cela, et c'est donc lui qu'il faut charger, configurer et initialiser correctement. Avant tout, quelle version d'Apache utilises-tu ?
Dans tous les cas tut trouveras la doc sur le site officiel :
Tu peux essayer dmesg qui t'affichera les messsage du noyau, généralement utile en cas de freeze plutôt que de crash de l'application.
Ensuite, tu peux faire un cat /var/log/Xorg.0.log en remplaçant éventuellement Xorg par XFree86 si c'est ton serveur. Peux-être y a-t-il des messages particuliers, mais il est possible que le pilote de ta carte vidéo plante.
Mais à mon avis, 9 fois sur 10, c'est soit l'ACPI, soit le frame buffer qui posent problème. Donc essaie de démarrer ta machine en passant des options au noyau (lors du menu de démarrage, lilo ou grub),
Hmm. Il semble que tu aie obtenu l'effet inverse de celui recherché, au lieu de monter le SSL sur son port par défaut, tu as mis le layer normal du serveur web en ecoute forcée sur le port 443, en principe dédié au SSL.
Ben c'est écrit. Si ni champ clé ni option ne sont précisés, "s" est sans effet. Cela veut juste dire que si tu utilises un champ pour faire un tri, et que deux entrées ont la même valeur, il va comparer les deux lignes litéralement pour les classer (en fonction de leur contenu, leur longueur, etc.). Ce qui te garantit que ton fichier sera toujours trié en fonction d'au moins un critère, et que les lignes ne seront pas redéposées dans l'ordre où il apparaissent.
Il est normal que ce soit le comportement par défaut.
J'ajouterais qu'après une brève recherche, je n'ai pas été capable de retrouver par Google le ou les algorithmes utilisés par sort. Un logiciel dédié à cette opération effectuera je crois un rapide contrôle du contenu du fichier et choisira l'algo le plus adapté en conséquence.
Il se peut très bien que GNU sort ait été écrit simplement pour faire ce qu'il a besoin de faire et que personne n'ait jamais eu le besoin de mettre la pression aux développeurs pour en faire une voiture de course. Cela ne me dérange pas plus que cela ...
Mais surtout, synsort c'est un logiciel propriétaire ? Code source fermé, etc ? Si c'est le cas, il y a eu une équipe de développement spécialement affectée à ce projet en particulier, ce qui favorise les efforts d'optimisation. Le logiciel a été conçu pour çà. Ensuite, si ton logiciel est livré déjà compilé, sans les sources, etc. et n'est pas spécialement un projet GNU, ou de philosophie Unix, il y a fort à parier qu'ils fassent un usage poussé de fonctions assembleur propre à la machine sur laquelle tu tournes (99% du temps un PC, même si Windows ou Linux) et tirent avantage des jeux d'instructions étendu style MMX etc. Et en ce sens, ils ont parfaitement raison. Une opération de tri est pratiquement un cas d'école dans ce domaine.
A cela, on peut ajouter la façon dont les différents outils acquièrent leurs données, et gèrent les fichiers. Je suppose que sort est capable d'utiliser mmap depuis longtemps, mais il doit rester un programme tout-terrain, gérant les ressources avec des appels les plus conventionnels possibles.
Avec tout cela, j'ai presque envie de dire que 3x la vitesse de sort, c'est honorable mais sans plus. Je suis persuadé qu'un algo de tueur optimisé par un démomaker (ou pire, un programmeur de 8 bits :-) devrait pouvoir monter jusqu'à 10 fois la vitesse de base (à vue de nez bien sûr).
Ce qui m'amenait l'autre jour à une petite réflexion. Y a-t-il une compagnie au monde capable de racheter Microsoft ? Les émirats arabes réunis peut-être ?
Je vais donc bloquer le port 80 pour le web, le 25 et le 110 pour la messagerie, le 21 pour le FTP et le 22 pour le SSH. La sécurité n'a pas de prix, mais je me demande à quoi servira ma connexion internet après ?!?
Ben, le SMB (ports 135 à 139), BackOrifice (31337) et Kazaa (1214). Une vraie petite machine Windows, quoi ! :-)
Hmm, la mac-adress est l'identifiant constructeur d'une carte réseau. Es-tu sûr qu'elle ait vraiment pris naissance dans les spécification d'Ethernet ? Rien n'empêche techniquement une carte réseau d'avoir un identifiant, quelque soit la couche de transport utilisée.
De plus, en TCP/IP il existe les protocoles ARP et RARP pour résoudre une adresse IP en adresse physique et réciproquement. Le seul problème, c'est que les serveurs qui implémentent ce protocole par défaut sont rare.
En plus, il va sans dire que cela n'est censé fonctionner en principe que sur un réseau local, sinon tu accéderais à des données confidentielles à l'utilisateur.
Lis la norme IEE-754-1985 qui définit les nombres à virgule flottante. Il précise que les valeurs INF et Nan sont définies, et gcc/g++ sait les gérer. C'est Nan que j'utiliserais (puisque c'est vrai).
En C++, tu peux définir une classe dérivant immédiatement de double pour éviter les transtypages et autres.
class ElaboratedDouble : public double
{
public:
bool defined;
}
Tu peux également redéfinir l'opérateur de casting (double) (même si redéfinir les opérateurs de casting pose toujours plus de problème que cela n'en résoud) et tenter de lancer une exception si la valeur n'est pas définie.
Posté par Obsidian .
En réponse au message POST.
Évalué à 5.
Par exemple, pour un CGI c'est pas compliqué, on balances tout sur son stdin en modifiant quelques variables d'environnement, et on renvoie au client le stdout, mais pour une banale page web, comment ça se gère ?
Ben pour une banale page web, en principe c'est ton serveur qui gère tout cela. Ce que je tire de ton message, c'est qu'apparement, ton plugin, c'est un mini serveur web. Donc dans ce cas (POST), tu dois refaire le travail exactement comme tu le ferais avec une application CGI, qui n'est que la définition de l'interface entre le serveur WEB et ton application, ce qui n'a pas lieu d'être ici puisque tu écoutes directement les connexions.
Dans le cas de POST, les données pouvant être très longues et/ou confidentielles, il est hors de question de les coder dans l'URL ni même dans les entêtes ! Elles font partie du document. Ce document est ensuite présenté à la discrétion du client (le navigateur), mais en général c'est :
Content-Type: application/x-www-form-urlencoded
... qui est un type mime défini et donc (probablement) décrit clairement par une RFC. La mauvaise nouvelle, c'est que si tu ne peux pas utiliser un module tout fait (style CGI en perl), il faudra te recoltiner l'implémentation des différents protocoles si tu veux être parfaitement compatible avec tes clients, à moins d'utiliser une entête du style "Accept-xxxx" pour informer le client des langues que tu connais vraiment.
En pratique, les arguments passés par un formulaire POST au moment où tu cliques sur un bouton sont encodés exactement de la même façon qu'un GET mais sur la première ligne des données, après les entêtes.
Fais par exemple un "nc -l -p 5678" pour te mettre à l'écoute du port 5678 (par exemple), puis écris une petite page web qui contiendra juste un formulaire de type POST et dont l'action sera "http://127.0.0.1:5678(...)". Tu obtiendras un exemple parlant de ce qu'un navigateur web envoie à un serveur dans ta situation.
Pour tes codes de retour, c'est le protocole HTTP qu'il faut respecter. Cela n'a rien à voir avec le POST en particulier, si ce n'est que c'est la plupart du temps avec un formulaire que l'on fait des opérations coté serveur autre que la simple consultation de page. Donc tu écris simplement sur la sortie standard :
[^] # Re: mouais
Posté par Obsidian . En réponse au journal Petite et grandes erreurs informatiques. Évalué à 6.
(... Quoi ?)
[^] # Re: motivation..
Posté par Obsidian . En réponse au journal La fin des études, le début du chomage. Évalué à 2.
[^] # Re: mouais
Posté par Obsidian . En réponse au journal Petite et grandes erreurs informatiques. Évalué à 1.
[^] # Re: avantage
Posté par Obsidian . En réponse au journal ITER à Cadarache... Évalué à 3.
Ce sera pour nos enfants ! :-)
[^] # Re: avantage
Posté par Obsidian . En réponse au journal ITER à Cadarache... Évalué à 7.
http://www.iter.gouv.fr/(...)
[^] # Re: oui
Posté par Obsidian . En réponse à la dépêche ERP5 produit une liasse fiscale certifiée conforme aux normes françaises. Évalué à 4.
Si c'est pour une utilisation en entreprise, PySol remplit déjà sa mission avec brio.
[^] # Re: motivation..
Posté par Obsidian . En réponse au journal La fin des études, le début du chomage. Évalué à 5.
Moralité, la supériorité de l'offre a fait dramatiquement chuter les salaires, et la proportion de débutants l'a fait tomber de plus belle. Impossible aujourd'hui de vendre une expérience ou d'imposer un développement de qualité car le recruteur va être submergé dès le départ d'offres à très bas prix. Et derrière, la qualité du logiciel produit ou de la prestation apportée est à la hauteur de cette situation et s'impose en standard.
[^] # Re: motivation..
Posté par Obsidian . En réponse au journal La fin des études, le début du chomage. Évalué à 5.
Ce qui est malheureux, c'est que tous les gens qui avaient un minimum d'expérience en informatique voyaient cela venir. 20M$ de levée de fonds pour une simple dot.com, avec tous les investisseurs qui se précipitaient à qui mieux mieux pour être sûrs d'en avoir une part, on allait bien le payer un jour. Non seulement, je pense que l'on a pas fini de s'en remettre, mais qu'en plus, même à l'avenir, toutes les compagnies vont rester méfiantes maintenant.
[^] # Re: Backward
Posté par Obsidian . En réponse au message problème https. Évalué à 2.
C'est un module, mod-ssl, qui s'occupe de cela, et c'est donc lui qu'il faut charger, configurer et initialiser correctement. Avant tout, quelle version d'Apache utilises-tu ?
Dans tous les cas tut trouveras la doc sur le site officiel :
http://httpd.apache.org/(...)
http://httpd.apache.org/docs/(...)
http://httpd.apache.org/docs-2.0/(...)
Sous la version 2.0, la partie qui correspond au SSL est ici :
http://httpd.apache.org/docs-2.0/ssl/(...)
[^] # Re: retourner en mode texte
Posté par Obsidian . En réponse au message Bouh... Premier démarage = Plantage. Évalué à 2.
Ensuite, tu peux faire un cat /var/log/Xorg.0.log en remplaçant éventuellement Xorg par XFree86 si c'est ton serveur. Peux-être y a-t-il des messages particuliers, mais il est possible que le pilote de ta carte vidéo plante.
Mais à mon avis, 9 fois sur 10, c'est soit l'ACPI, soit le frame buffer qui posent problème. Donc essaie de démarrer ta machine en passant des options au noyau (lors du menu de démarrage, lilo ou grub),
linux acpi=off noapic vga=1
Tu devrais aller un peu plus loin.
# Backward
Posté par Obsidian . En réponse au message problème https. Évalué à 2.
Au fait, tu utilises bien Apache ?
[^] # Re: Pour sort, ca depend des options
Posté par Obsidian . En réponse au journal M'enfin ?? .... Évalué à 2.
Il est normal que ce soit le comportement par défaut.
[^] # Re: Plusieurs raisons possibles.
Posté par Obsidian . En réponse au journal M'enfin ?? .... Évalué à 4.
# Plusieurs raisons possibles.
Posté par Obsidian . En réponse au journal M'enfin ?? .... Évalué à 8.
Il se peut très bien que GNU sort ait été écrit simplement pour faire ce qu'il a besoin de faire et que personne n'ait jamais eu le besoin de mettre la pression aux développeurs pour en faire une voiture de course. Cela ne me dérange pas plus que cela ...
Mais surtout, synsort c'est un logiciel propriétaire ? Code source fermé, etc ? Si c'est le cas, il y a eu une équipe de développement spécialement affectée à ce projet en particulier, ce qui favorise les efforts d'optimisation. Le logiciel a été conçu pour çà. Ensuite, si ton logiciel est livré déjà compilé, sans les sources, etc. et n'est pas spécialement un projet GNU, ou de philosophie Unix, il y a fort à parier qu'ils fassent un usage poussé de fonctions assembleur propre à la machine sur laquelle tu tournes (99% du temps un PC, même si Windows ou Linux) et tirent avantage des jeux d'instructions étendu style MMX etc. Et en ce sens, ils ont parfaitement raison. Une opération de tri est pratiquement un cas d'école dans ce domaine.
A cela, on peut ajouter la façon dont les différents outils acquièrent leurs données, et gèrent les fichiers. Je suppose que sort est capable d'utiliser mmap depuis longtemps, mais il doit rester un programme tout-terrain, gérant les ressources avec des appels les plus conventionnels possibles.
Avec tout cela, j'ai presque envie de dire que 3x la vitesse de sort, c'est honorable mais sans plus. Je suis persuadé qu'un algo de tueur optimisé par un démomaker (ou pire, un programmeur de 8 bits :-) devrait pouvoir monter jusqu'à 10 fois la vitesse de base (à vue de nez bien sûr).
[^] # Re: Eh beh!
Posté par Obsidian . En réponse au sondage Que conseiller à Mandriva de racheter ?. Évalué à 7.
[^] # Re: Eh beh!
Posté par Obsidian . En réponse au sondage Que conseiller à Mandriva de racheter ?. Évalué à 2.
[^] # Re: Haha
Posté par Obsidian . En réponse au journal La fin de Gandi?. Évalué à 1.
[^] # Re: remarque c'est pas con...
Posté par Obsidian . En réponse au journal ils ont de l'humour.... Évalué à 9.
[^] # Re: remarque c'est pas con...
Posté par Obsidian . En réponse au journal ils ont de l'humour.... Évalué à 4.
Ben, le SMB (ports 135 à 139), BackOrifice (31337) et Kazaa (1214). Une vraie petite machine Windows, quoi ! :-)
[^] # Re: normalement non
Posté par Obsidian . En réponse au message Adresse Mac. Évalué à 2.
De plus, en TCP/IP il existe les protocoles ARP et RARP pour résoudre une adresse IP en adresse physique et réciproquement. Le seul problème, c'est que les serveurs qui implémentent ce protocole par défaut sont rare.
En plus, il va sans dire que cela n'est censé fonctionner en principe que sur un réseau local, sinon tu accéderais à des données confidentielles à l'utilisateur.
[^] # Re: Le texte
Posté par Obsidian . En réponse au journal ils ont de l'humour.... Évalué à 2.
# Double et C++
Posté par Obsidian . En réponse au message Marquer un double comme étant non élaboré.. Évalué à 3.
En C++, tu peux définir une classe dérivant immédiatement de double pour éviter les transtypages et autres.
class ElaboratedDouble : public double
{
public:
bool defined;
}
Tu peux également redéfinir l'opérateur de casting (double) (même si redéfinir les opérateurs de casting pose toujours plus de problème que cela n'en résoud) et tenter de lancer une exception si la valeur n'est pas définie.
[^] # Re: suite : evolution
Posté par Obsidian . En réponse au message problèmes de link C++. Évalué à 2.
[^] # Re: ESR et la religion
Posté par Obsidian . En réponse au journal L'importance du choix du pseudo. Évalué à 3.
# CGIs et serveurs Web, même combat.
Posté par Obsidian . En réponse au message POST. Évalué à 5.
Ben pour une banale page web, en principe c'est ton serveur qui gère tout cela. Ce que je tire de ton message, c'est qu'apparement, ton plugin, c'est un mini serveur web. Donc dans ce cas (POST), tu dois refaire le travail exactement comme tu le ferais avec une application CGI, qui n'est que la définition de l'interface entre le serveur WEB et ton application, ce qui n'a pas lieu d'être ici puisque tu écoutes directement les connexions.
Dans le cas de POST, les données pouvant être très longues et/ou confidentielles, il est hors de question de les coder dans l'URL ni même dans les entêtes ! Elles font partie du document. Ce document est ensuite présenté à la discrétion du client (le navigateur), mais en général c'est :
Content-Type: application/x-www-form-urlencoded
... qui est un type mime défini et donc (probablement) décrit clairement par une RFC. La mauvaise nouvelle, c'est que si tu ne peux pas utiliser un module tout fait (style CGI en perl), il faudra te recoltiner l'implémentation des différents protocoles si tu veux être parfaitement compatible avec tes clients, à moins d'utiliser une entête du style "Accept-xxxx" pour informer le client des langues que tu connais vraiment.
En pratique, les arguments passés par un formulaire POST au moment où tu cliques sur un bouton sont encodés exactement de la même façon qu'un GET mais sur la première ligne des données, après les entêtes.
Fais par exemple un "nc -l -p 5678" pour te mettre à l'écoute du port 5678 (par exemple), puis écris une petite page web qui contiendra juste un formulaire de type POST et dont l'action sera "http://127.0.0.1:5678(...)". Tu obtiendras un exemple parlant de ce qu'un navigateur web envoie à un serveur dans ta situation.
Pour tes codes de retour, c'est le protocole HTTP qu'il faut respecter. Cela n'a rien à voir avec le POST en particulier, si ce n'est que c'est la plupart du temps avec un formulaire que l'on fait des opérations coté serveur autre que la simple consultation de page. Donc tu écris simplement sur la sortie standard :
HTTP/1.0 200 OK
Content-Type: text/html
Début de ton document ...
et tout devrait marcher comme sur des roulettes.