Ben oui, CTRL+S c'est à la limite acceptable pour sauvegarder, "s" = sauvegarder.
Par contre CTRL+ALT ça fait déjà deux modifieurs, un de plus que d'ordinnaire. Et le F8 qu'on rajoute derrière n'a aucun sens, aucune relation avec l'action qui est programmée derrière. Si ça te semble naturel demandes toi pourquoi, en soit faire cette combinaison n'a rien de naturelle (si tant est qu'une combinaison de touche puisse être naturelle). Je vois même difficilement pire (sauf à lui demander de rajouter la touche SHIFT en même temps).
> ctrl+alt+suppr pour avoir le gestionnaire des tâches est plus simple ????
Non, c'est pareil. Mais ce n'est pas parce que MS fait un truc idiot que ça nous dégage d'essayer de faire mieux hein ...
Puis bon, dans l'ordre des choses partager un ordinateur famillial à deux on le fait plus souvent que d'appeler le gestionnaire des taches. Si une action d'administration peu avoir un raccourci obscur, une action courante d'utilisation ne le devrait pas.
D'ailleurs, quand j'y pense, sous win pour accéder au gestionnaire des taches il suffit de cliquer droit sur la barre des taches, pas besoin d'un raccourci inconnu.
> 1. au pire, tu laisses ta copine dans son environnement.
La copine elle tourne sous linux depuis longtemps, le seul problème c'est que du coup on partage le même login. A force ça devient gênant pour les bookmark, les préférences et les répertoires par défaut de fichier.
> ctrl+alt+Fx obscur... pas mal celle-là...
Qu'appelles tu obscur ? ça n'a aucun sens, ce n'est pas prévisible, c'est complexe (par rapport à un raccourci classique) et peu facilement retenable (F8 ça n'a rien de logique comme raccourci pour "nouvel utilisateur").
Hum, ça c'est une bonne idée ce flexiserver.
Malheureusement à l'utilisation c'est peu pratique : juste avant le switch ça fait un xlock. c'est intelligent et très bien mais pas pratique du tout.
Je m'explique :
- je me loggue en A
- ma copine arrive, elle clique sur l'icone pour déclencher le second X
- le serveur lock ma session A, lance une session B,
- ma copine se loggue sur B, travaille, se déloggue
- ça revient automatiquement sur la session A (qui est lockée)
- quand ma copine revient une heure après pour retravailler elle se retrouve devant un xlock qui demande un mot de passe, sans pouvoir cliquer sur une icone pour déclencher une demande de login en B
Bref, pas pratique du tout (il aurait fallu qu'ils gèrent une console toujours active uniquement pour les logins et que ce soit vers celle là qu'on retourne par défaut). Ceci dit ils sont partis dans la bonne direction donc maintenant que j'ai un nom autour de quoi chercher je vais pouvoir fouiller un peu pour voir si quelqu'un a fait ce que je cherche.
non, ce n'est pas que c'est "dûr", c'est que ce n'est pas simple, pas pratique.
De même je pourrai remplacer la touche "a" de mon clavier par un CRTL+ALT+Z, ça ne serait pas dûr à taper, mais ça ne serait pas pratique du tout.
Je vais juste te dire que pour les non informaticiens, taper pleins de raccourcis obscurs (et celui là l'est vraiment), c'est loin d'être pratique et simple à retenir. Pour l'instant j'en suis à faire apprendre comment on déclenche la connexion modem et avec quelle icone on l'arrête. Le simple fait d'aller gérer deux logins ça va déjà être une grosse étape et une frutrastion, si je cherche en plus à faire passer par une telle combinaison de touche je peux dors et déjà oublier la séparation des logins.
C'est peut être un caprice, mais c'est mon besoin. Si ça te semble futile ne répond pas, mais là ton intervention ne sert à rien du tout.
Oui, ça je sais faire. Mais un CTRL+ALT+F8/F7 pour switcher ce n'est pas ce que j'appelle "confortable". Cette solution me va si et seulement si je peux avoir une icone "passer sur le X n°8".
Tout d'abord n'importe qui peut créer une clé à ton nom, ce qui fait la valeur de la clé ce n'est pas le nom/email qu'il y a dessus mais par qui elle est signée. Si la tienne est signée ça suffira à quelqu'un pour vérifier que c'est bien toi. Il ne se posera des questions que s'il cherche à connaitre ta clé sans l'avoir préalablement reçue (donc s'il cherche à s'en servir pour cryptage et pas pour signature).
Ceci dit si quelqu'un a monté une clé qui n'est pas à toi, je serai toi je me demanderai pourquoi il a fait ça, et ce qu'il a bien pu essayer de faire en se faisant passer pour toi. Essaie de récupérer le finger print et faire une recherche avec sur le net, voir si quelqu'un a mis un message sur une ml public avec ton nom et cette clé.
Quand au fait d'avoir une clé à son nom non utilisée sur les serveurs de clé ... ça m'est arrivé. Bon, moi c'était ma faute, une erreur de manip avec une clé dont je n'avais plus le certificat de révocation ... Mais après quelques échanges avec un admin il y avait moyen de faire retirer la clé (ou plutot de la faire désactiver, elle est toujours là mais ne sera pas proposée dans les recherches). Je n'ai pas poursuivi car de toutes façons j'ai changé d'adresse email peu après mais c'est faisable. Si ça peut t'aider ...
C'est un choix de ta distrib pour éviter qu'un admin du dimanche utilise un shell par telnet sans en connaitre les implications. Ils virent le binaire telnet pas parce que c'est un protocole idiot, mais parce qu'il sert le plus souvent à se connecter à un shell distant en clair (et *ça* c'est mal, parce que le mot de passe est en clair).
Que tu veuilles ouvrir une connexion HTTP, SMTP ou autres à la main via le binaire telnet n'est absolument pas en cause et n'a rien à voir avec la phrase souvent répétée du "telnet c'est mal".
Que tu utilises un beau programme du nom "telnet" ou un "netcat", c'est *exactement* la même chose qui passe sur le réseau, *exactement* la même sécurité, que ce soit d'un point de vue extérieur/réseau ou d'un point de vue intérieur/système.. L'un n'est pas plus sûr que l'autre. Si tu veux m'annoncer que c'est moins bien je t'attend de pied ferme toi et ton argumentation.
Tu viens m'expliquer en quoi faire un "telnet linuxfr.org 80" est moins "secure"(*) qu'un netcat ?
Tu confond l'ouverture d'un shell disant via telnet (qui effectivement n'est pas sûre vu que le mot de passe est en clair) et l'utilisation de telnet de manière générique sur un socket (qui passe autant en clair avec mon outil que le tien).
(* c'est quoi ce mot ? "sûr" me parait bien plus adapté, pourtant je n'ai habituellement vraiment rien contre les mots anglais dans l'informatique)
Oui, enfin les problèmes de délais ce ne sont pas que des problèmes de lignes. J'ai fait mon inscription il y a un mois et demi et pendant un bon mois c'est resté sur "on va bientot demander votre ligne à FT", ou quelque chose du genre. Je ne suis pas le seul au bureau. Pourtant, tant que la ligne n'est pas active, on peut difficilement inculper la qualité de ligne.
Il se trouve que Free donne rapidement comme raison "c'est votre ligne" visiblement. Etrangement chez les autres les lignes sont presque toujours sans problèmes.
Free a un gros problème de délai et de support technque (peut être à cause d'un trop grand nombre d'inscription, je ne sais pas).
> Alors voilà c'est bien gentil de raler, mais celà m'étonnerai que tout celà te soit
> arrivé à toi, où alors tu n'as vraiment pas de po. Dans tous les cas celà ne sert
> strictement à rien de généraliser, puisqu'on rencontre les memes problèmes chez
> tous les FAIs.
En gros tu ne sais pas si il a eu un problème mais par principe tu considère que ce n'est probablement pas le cas et tu lui demandes de ne pas raler. Et quand bien même c'est son cas tu lui demandes de ne pas raler parce que c'est pas le cas de tout le monde (comprendre : le tien)
Dis, ce n'est pas toi qui généralise un peu là ?
> A noter que si tu voulais un service nickel, sans retard, avec un débit de crete en
> permanence et tout et tout, tu le paierais 60 euros ton forfait chez Wanadoo.
Ca c'est un faux argument. S'ils offrent un service à un prix, ils sont tenus de le fournir. S'ils n'en sont pas capable faudra pas se plaindre que le client paye pas assez cher. Si ce qu'il y a marqué sur le contrat n'est pas fournit ou s'il y a problème, ça ne peut être reproché qu'à celui qui fournit le service.
> PHP c'est pour faire du web dynamique, pas encore des Web Services.
D'où vient cette affirmation ?
Il y a une très bonne extension SOAP pour PHP5 que même un débutant pourrait utiliser. Il y a du SOAP et du XML-RPC depuis pas mal de temps en PHP4. Il n'y a franchement aucune raison d'exclure PHP pour faire du Web Service.
Le Web service c'est un grand nom pour la possibilité d'envoyer et recevoir des messages XML. Ce n'est pas tellement différent de ce que tu appelles "web dynamique". La seule différence réelle c'est la manière dont tu récupères la requête et lamanière dont tu formattes la réponse. A vrai dire le Web Service est un concept tellement simple que ça peut bien être codé dans n'importe quoi qui sait lire/écrire du XML.
Plein .. la connectivité c'est LE point fort de PHP. PHP est surtout fait pour gérer des frontal Web, et se connecter avec une application ou un autre composant qui gèrera le métier.
Ca donne déjà un bon panel des possibilités (j'ai ouie dire aussi d'un connecteur ruby mais il n'a pas l'air de se trouver officialisé sur PHP, PEAR ou PECL).
Dans l'optique inverse on peut intégrer PHP comme langage de script d'une plus grosse application (à la manière d'ActivePerl et autres) : http://pecl.php.net/package/PHPScript(...)
L'extension Java n'a pas été portée vers PHP5 mais Sun a décidé de faire toutes ses implémentations de référence pour son futur JSR avec PHP. Sun s'est donc engagé avec Zend pour réaliser la connectivité complète PHP/Java (dans les deux sens). C'est à priori un gage de sérieux et de pérénité pour les interractions avec Java (le temps qu'ils fassent l'implémentation PHP5).
Coté plus applicatif on a aussi des connecteurs vers pas mal de trucs. Au dernier forum PHP on avait une entreprise qui exposait ce qu'elle a fait sur son intranet : un frontal PHP qui se connecte à leur ERP SAP pour le piloter et fournir des interfaces Web pour les trucs utilisés.
L'idée est là : pas de refaire l'application Java ou de refaire un ERP, mais de faire rapidement un frontal très simple qui utilise des connecteurs pour chercher la logique métier. PHP s'occupe alors de la partie Web (et uniquement de la partie Web) en évitant de monter tout un J2EE et des concepts complexes là où ce n'est pas nécessaire.
> mais qui doit-on accabler?
Pas le langage certes, mais quand on me dit que ça ne gère pas X, Y, Z ... la question est souvent "oui, mais vous en avez vraiment besoin ? si vous repartez sur quelques petites lignes simples au lieu de faire une grosse architecture monstre, vous n'en auriez peut être pas besoin.
> Le libre ne se limite pas à des licences mais à la coopération
Cette affirmation est toute personnelle. Le libre à ma connaissance se limite au respect de 4 principes de base au niveau des droits accordés aux utilisateurs.
Tu peux tout à fait faire du libre dans ton coin, sans aucune coopération, ça restera du libre.
Quant au renommage c'est quelque chose de *bien* au contraire. A partir du moment où il ne s'agit plus du même soft à la base, il faut éviter de pourrir le projet original, de rajouter de la confusion pour les utilisateurs, etc. Il y a d'ailleur aussi quelques obligations légales car si le code est libre, le nom en général ne l'est pas. Je ne sais pas si le nom "konqueror" appartient au projet kde, mais il n'appartient certainement pas à Apple.
Je ne t'ai pas vu raler quand le projet Xorg a forké Xfree86 en changeant de nom, ce n'est pas un projet "libre" ça pourtant ?
Tu triches. Certes tu peux poser ton archives Java et exécuter direct. Il faut juste installer la JVM avant.
Pareil, en PHP tu peux poser tes fichiers PHP et utiliser direct. Il faut juste poser les binaires avant ;). Je ne dis pas que c'est pareil à la seconde près, mais en pratique c'est kifkif.
Du coté compatibilité des architectures et des systèmes, PHP n'a pas à rougir de Java tu sais. Je ne crois pas qu'on puisse vraiment faire un choix ou l'autre là dessus.
C'est un singleton au niveau d'une requête particulière, pas au niveau global commun à toutes les requêtes simultanées (tout simplement parce que ce niveau global n'existe pas).
C'est vrai que j'aurai du préciser.
Si tu veux faire un singleton global, il faudra stoquer/lire tous ses attributs en base de données (tu auras plusieurs instances mais quand tu utilises les attributs, tu utilises la bases de données (qui elle est globale).
Difficulté, difficulté .. la seule réelle difficulté était de bien penser à mettre des & partout. Le problème ne venait pas des patern mais de la gestion des objets idiote en PHP 4 (ils étaient par défaut passés et affectés par copie et non par référence).
Le problème en question est réglé (c'est grosso modo *la* plus grosse amélioration de PHP5). On a des méthodes statiques, des attributs statiques, les objets sont bien des références ... implémenter un singleton en PHP5 c'est 10 lignes de code :
class monSingleton {
static $instance ;
static function getInstance() {
if (!isset(self::$instance)) {
self::$instance = new monSingleton ;
}
return self::$instance ;
}
}
$objSingleton = monSingleton::getInstance() ;
Effectivement, en PHP tu auras généralement plein d'implémentations d'un même procédé. Tu n'as pas besoin de réinventer la roue contrairement à ce que tu dis (d'autres l'ont déjà fait), mais la roue existe en une dizaine de modèles en magasin. Charge à toi de prendre la roue adaptée. En Java il y a *la* roue et tout le monde utilise la même.
Ca a du bon et du moins bon, c'est une philosophie. Ca permet à un mauvais programmeur de faire n'importe quoi. Ca permet aussi à un bon architecte de choisir son outil ou de faire une solution simple qui correspond à ses besoins.
Après l'avantage de PHP c'est que c'est globalement simple. On n'a pas le contrecoup d'une appli en C comme tu en parles. Si PHP a justement un avantage par rapport à Java sur lequel tout le monde s'accorde c'est sa simplicité. Malgré le fait qu'il co-existe 10 roues différentes, pour un soft bien codé (je ne parle pas de la myriade de bout de code PHP qu'on trouve sur le net ni des phpnuke & co) le code PHP est facilement compréhensible. En Java des fois c'est assez lourd donc il faut explorer quelques temps.
On a les avantages (choix) sans les désavantages (relecture). Les deux seuls problèmes arrivent sur les gens comme moi qui prennent 10 ans pour faire un choix, ou les gens qui codent mal par nature (et ceux là feront effectivement n'importe quoi)
Là il faudra aller plus loin que metabase. Metabase s'arrête à définir une structure abstraite et à l'implémenter dans les SGBD. A ma connaissance (ce n'est pas l'outil que j'utilise donc je prend des gants) l'utilisateur continue à faire du SQL par dessus.
Pour utiliser des objets abstraits sans SQL tu as je crois au moins une classe dans PEAR. Dans le framework que j'utilise on commence développer ce genre d'outil. Il y en a d'autres qui ont mené cette politique depuis le début et qui sont amha assez avancé pour que tu n'ai pas trop de critiques.
Ce que tu cherches est probablement http://pear.php.net/package/DB_DataObject(...) (ce n'est certainement pas l'implémentation la plus avancée mais comme c'est du PEAR, c'est probablement celle qui sera la plus mature à terme)
Là dessus on est d'accord.
En fait des développeurs pas cher il y en a plein, le problème c'est qu'en PHP comme tu as la possibilité de faire n'importe quoi ... beaucoup le font. Si tu veux quelque chose de correct il faudra *chercher* le développeur correct.
Et ça pas de secret, le bon développeur, qu'il fasse du java ou du php, son prix n'est pas si différent. (même si ça reste probablement un peu plus faible sur PHP parce qu'il a de la concurrence)
en PHP tu as (entres autres) la librairie "metabase" qui te fait ça, et te regénère toute ta structure de bdd et tout ce qu'il faut.
Bref, ça existe aussi
Oui, mais à ton API tu lui demandes quoi ? tu lui envoies probablement des requêtes SQL. Si de toutes façons tu dois changer la requête SQL que tu envoies pour utiliser au mieux ton SGBD, changer un nom de méthode/fonction, c'est vraiment négligeable à coté. Mais quoi qu'il en soit, des abstraction qui offrent une API unifiée tu en as (peut être même trop)
Il n'empêche que tu restes là avec de beaux mots marketing. D'un point de vue pratique qu'est ce que tu n'arrives pas à faire avec PHP *et* dont tu as besoin ?
Oui PHP n'est pas fait pour une application multimédia. Mais comme tu dis on parle de frontaux Web. Développer un module PHP qui charge une lib C et en appelle les fonction, c'est l'histoire de quelques heures au plus. Je ne te dis pas de gérer ta logique métier en PHP, mais d'utiliser PHP pour ce qu'il sait faire : un frontal Web (éventuellement un peu plus loin si c'est plus simple vis à vis de l'existant mais on sort de son domaine de prédilection). Rien n'empêchera après de connecter ton PHP à des objets COM/RPC ou Java et d'en utiliser les méthodes.
Effectivement, ils auraient du rajouter dans la news "concurrents *dans le domaine Web*". Mais quand je vois le nombre de sites Web avec du J2EE de partout qui sont de véritables monstres pour faire quelque chose de super simple en PHP .. ça me fait un peu mal. Mis à part quelques exceptions, la plupart des sites Web "pourraient" tout à fait être fait en PHP. (attention, je n'ai pas dit que les autres langages sont à jeter pour autant, mais au moins il s'agit d'une alternative valable).
10000 création de commandes simultanées ? waouh, ... considérant que la création d'une commande (ou l'envoi de la commande de création) prend au maximum 1s ou 2s .... ça veut dire au mieux 5000 commandes par secondes. Tu connais un magasin en ligne qui génère ça ? je pense que même les plus gros magasins en ligne n'ont pas ça.
Maintenant il est où ton problème ?
- l'envoi du mail ? rajouter un mail dans une queue c'est très rapide, ce n'est pas un problème et c'est le boulot du serveur de mail que de gérer sa queue pour l'envoie et gérer la charge mail.
- l'insertion dans la Bdd ? en général les sgbd qui sont fait pour supporter ce genre de volumes en nombre de connexions acceptent des instructions "delayed" ou des choses du genre, ce n'est donc pas un énorme problème non plus.
- l'interface avec les fournisseurs ? c'est vague, en général ça revient à appeler un programme qui fait son propre boulot, ou faire une requête sur le SGBD. Ce n'est pas ça non plus qui pose grand problème.
Si réellement tu as un problème de ce coté là tu fais une file avec ton SGBD ou avec un programme externe qui gère la file de commande. Tu n'as peut être pas un objet qui s'appelle "asynchrone" et qui présente une méthode toute jolie mais ça ne prend pas deux heures à faire.
Et comme je le répète, quand bien même ton exemple poserait problème, vu le nombre de gens qui ont besoin de gérer 10000 commandes simultanément via une interface Web ... ça voudrait dire que Java peut tout à fait être réservé à une niche très réduite, 99.99% du Web restant avec un outil simple comme PHP, même pas capable de gérer une dizaine de millier de commande simultanées ;)
> - tu gères la montée en charge.
Grande question. Java "supporte" la charge, PHP permet une scallabilité. En PHP tu n'as pas tout ce qui est résident en mémoire, tout ce qui est commun, transactionnel et tout ça. Le propre du modèle c'est que pour monter en charge il suffit de rajouter un serveur en parralèle, et l'essentiel des problèmes de concurence ou de charge se retrouvent coté SGBD. Comme les bons SGBD savent aussi se gérer en cluster avec plusieurs frontaux ... il n'y a pas de réels problèmes de scalabilité.
Il ne dit pas la même chose que toi : il dit qu'il ne connait pas donc s'abstient de juger. Toi tu dis "c'est pas bon". Il me semble qu'il y a une nuance importante (un fossé ?).
> PHP est limité aux petites
> et moyennes applis web et ne joue pas du tout dans la même cour
> que J2EE et .NET
Je ne conteste pas encore, je demande simplement "pourquoi ?" et "où sont tes arguments ?"
Il y a effectivement des fonctionnalités très avancées en Java qui ne sont pas présentes en PHP. Maintenant le nombre d'application Web en ayant *besoin* est à ma connaissance *très* limité.
je cherche donc à comprendre un peu ton affirmation.
Ton API est indépendante de ta base de donnée. C'est bien.
Qu'en est-il de se que tu fais passer dans cette API ? le SQL n'est standard que sur le papier. En pratique il y a plein de différences suivant les serveurs, même dans les gros connus.
Et pour vous qui parlez de super appli qui ont besoin de super fonctionnalités super avancés, vous avez probablement un code SQL qui est adapté à votre SGBD pour exploiter au mieux les fonctionnalités.
Une API commune c'est très bien, d'ailleurs PHP5 est en train d'évoluer vers ça avec PDO (que j'espère voir dans PHP 5.1) ... mais ça n'est certainement pas suffisant pour disqualifier un langage vu que de toutes façons, sauf si tu te contentes de choses basiques ou de fonctionnalités non optimisées, il te faudra revoir tplus que la simple API quand tu changes de SGBD.
Ceci dit des wrappers qui offrent une API commune à plusieurs BDD, ça existe aussi en PHP (mais tu as la liberté de l'utiliser ou pas)
[^] # Re: gdm
Posté par Éric (site web personnel) . En réponse au message plusieurs logins X simultanés. Évalué à 3.
Ben oui, CTRL+S c'est à la limite acceptable pour sauvegarder, "s" = sauvegarder.
Par contre CTRL+ALT ça fait déjà deux modifieurs, un de plus que d'ordinnaire. Et le F8 qu'on rajoute derrière n'a aucun sens, aucune relation avec l'action qui est programmée derrière. Si ça te semble naturel demandes toi pourquoi, en soit faire cette combinaison n'a rien de naturelle (si tant est qu'une combinaison de touche puisse être naturelle). Je vois même difficilement pire (sauf à lui demander de rajouter la touche SHIFT en même temps).
> ctrl+alt+suppr pour avoir le gestionnaire des tâches est plus simple ????
Non, c'est pareil. Mais ce n'est pas parce que MS fait un truc idiot que ça nous dégage d'essayer de faire mieux hein ...
Puis bon, dans l'ordre des choses partager un ordinateur famillial à deux on le fait plus souvent que d'appeler le gestionnaire des taches. Si une action d'administration peu avoir un raccourci obscur, une action courante d'utilisation ne le devrait pas.
D'ailleurs, quand j'y pense, sous win pour accéder au gestionnaire des taches il suffit de cliquer droit sur la barre des taches, pas besoin d'un raccourci inconnu.
> 1. au pire, tu laisses ta copine dans son environnement.
La copine elle tourne sous linux depuis longtemps, le seul problème c'est que du coup on partage le même login. A force ça devient gênant pour les bookmark, les préférences et les répertoires par défaut de fichier.
> ctrl+alt+Fx obscur... pas mal celle-là...
Qu'appelles tu obscur ? ça n'a aucun sens, ce n'est pas prévisible, c'est complexe (par rapport à un raccourci classique) et peu facilement retenable (F8 ça n'a rien de logique comme raccourci pour "nouvel utilisateur").
[^] # Re: Gdm flexiserver
Posté par Éric (site web personnel) . En réponse au message plusieurs logins X simultanés. Évalué à 2.
Ce point là est réglé, merci
[^] # Re: Gdm flexiserver
Posté par Éric (site web personnel) . En réponse au message plusieurs logins X simultanés. Évalué à 2.
Malheureusement à l'utilisation c'est peu pratique : juste avant le switch ça fait un xlock. c'est intelligent et très bien mais pas pratique du tout.
Je m'explique :
- je me loggue en A
- ma copine arrive, elle clique sur l'icone pour déclencher le second X
- le serveur lock ma session A, lance une session B,
- ma copine se loggue sur B, travaille, se déloggue
- ça revient automatiquement sur la session A (qui est lockée)
- quand ma copine revient une heure après pour retravailler elle se retrouve devant un xlock qui demande un mot de passe, sans pouvoir cliquer sur une icone pour déclencher une demande de login en B
Bref, pas pratique du tout (il aurait fallu qu'ils gèrent une console toujours active uniquement pour les logins et que ce soit vers celle là qu'on retourne par défaut). Ceci dit ils sont partis dans la bonne direction donc maintenant que j'ai un nom autour de quoi chercher je vais pouvoir fouiller un peu pour voir si quelqu'un a fait ce que je cherche.
Merci
[^] # Re: gdm
Posté par Éric (site web personnel) . En réponse au message plusieurs logins X simultanés. Évalué à 2.
Merci
[^] # Re: gdm
Posté par Éric (site web personnel) . En réponse au message plusieurs logins X simultanés. Évalué à 1.
De même je pourrai remplacer la touche "a" de mon clavier par un CRTL+ALT+Z, ça ne serait pas dûr à taper, mais ça ne serait pas pratique du tout.
Je vais juste te dire que pour les non informaticiens, taper pleins de raccourcis obscurs (et celui là l'est vraiment), c'est loin d'être pratique et simple à retenir. Pour l'instant j'en suis à faire apprendre comment on déclenche la connexion modem et avec quelle icone on l'arrête. Le simple fait d'aller gérer deux logins ça va déjà être une grosse étape et une frutrastion, si je cherche en plus à faire passer par une telle combinaison de touche je peux dors et déjà oublier la séparation des logins.
C'est peut être un caprice, mais c'est mon besoin. Si ça te semble futile ne répond pas, mais là ton intervention ne sert à rien du tout.
[^] # Re: gdm
Posté par Éric (site web personnel) . En réponse au message plusieurs logins X simultanés. Évalué à 2.
# J'ai eu le cas
Posté par Éric (site web personnel) . En réponse au journal Usurpation de clé GPG, c'est possible ?. Évalué à 2.
Ceci dit si quelqu'un a monté une clé qui n'est pas à toi, je serai toi je me demanderai pourquoi il a fait ça, et ce qu'il a bien pu essayer de faire en se faisant passer pour toi. Essaie de récupérer le finger print et faire une recherche avec sur le net, voir si quelqu'un a mis un message sur une ml public avec ton nom et cette clé.
Quand au fait d'avoir une clé à son nom non utilisée sur les serveurs de clé ... ça m'est arrivé. Bon, moi c'était ma faute, une erreur de manip avec une clé dont je n'avais plus le certificat de révocation ... Mais après quelques échanges avec un admin il y avait moyen de faire retirer la clé (ou plutot de la faire désactiver, elle est toujours là mais ne sera pas proposée dans les recherches). Je n'ai pas poursuivi car de toutes façons j'ai changé d'adresse email peu après mais c'est faisable. Si ça peut t'aider ...
[^] # Re: resultat
Posté par Éric (site web personnel) . En réponse à la dépêche La robustesse de nombreux navigateurs web mise en cause. Évalué à 5.
Que tu veuilles ouvrir une connexion HTTP, SMTP ou autres à la main via le binaire telnet n'est absolument pas en cause et n'a rien à voir avec la phrase souvent répétée du "telnet c'est mal".
Que tu utilises un beau programme du nom "telnet" ou un "netcat", c'est *exactement* la même chose qui passe sur le réseau, *exactement* la même sécurité, que ce soit d'un point de vue extérieur/réseau ou d'un point de vue intérieur/système.. L'un n'est pas plus sûr que l'autre. Si tu veux m'annoncer que c'est moins bien je t'attend de pied ferme toi et ton argumentation.
[^] # Re: resultat
Posté par Éric (site web personnel) . En réponse à la dépêche La robustesse de nombreux navigateurs web mise en cause. Évalué à 4.
Tu confond l'ouverture d'un shell disant via telnet (qui effectivement n'est pas sûre vu que le mot de passe est en clair) et l'utilisation de telnet de manière générique sur un socket (qui passe autant en clair avec mon outil que le tien).
(* c'est quoi ce mot ? "sûr" me parait bien plus adapté, pourtant je n'ai habituellement vraiment rien contre les mots anglais dans l'informatique)
[^] # Re: Cela promet encore du plaisir.
Posté par Éric (site web personnel) . En réponse au journal Lancement d'une offre ADSL 2+. Évalué à 6.
Il se trouve que Free donne rapidement comme raison "c'est votre ligne" visiblement. Etrangement chez les autres les lignes sont presque toujours sans problèmes.
Free a un gros problème de délai et de support technque (peut être à cause d'un trop grand nombre d'inscription, je ne sais pas).
> Alors voilà c'est bien gentil de raler, mais celà m'étonnerai que tout celà te soit
> arrivé à toi, où alors tu n'as vraiment pas de po. Dans tous les cas celà ne sert
> strictement à rien de généraliser, puisqu'on rencontre les memes problèmes chez
> tous les FAIs.
En gros tu ne sais pas si il a eu un problème mais par principe tu considère que ce n'est probablement pas le cas et tu lui demandes de ne pas raler. Et quand bien même c'est son cas tu lui demandes de ne pas raler parce que c'est pas le cas de tout le monde (comprendre : le tien)
Dis, ce n'est pas toi qui généralise un peu là ?
> A noter que si tu voulais un service nickel, sans retard, avec un débit de crete en
> permanence et tout et tout, tu le paierais 60 euros ton forfait chez Wanadoo.
Ca c'est un faux argument. S'ils offrent un service à un prix, ils sont tenus de le fournir. S'ils n'en sont pas capable faudra pas se plaindre que le client paye pas assez cher. Si ce qu'il y a marqué sur le contrat n'est pas fournit ou s'il y a problème, ça ne peut être reproché qu'à celui qui fournit le service.
[^] # Re: Une question pour un non expert J2EE
Posté par Éric (site web personnel) . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 2.
D'où vient cette affirmation ?
Il y a une très bonne extension SOAP pour PHP5 que même un débutant pourrait utiliser. Il y a du SOAP et du XML-RPC depuis pas mal de temps en PHP4. Il n'y a franchement aucune raison d'exclure PHP pour faire du Web Service.
Le Web service c'est un grand nom pour la possibilité d'envoyer et recevoir des messages XML. Ce n'est pas tellement différent de ce que tu appelles "web dynamique". La seule différence réelle c'est la manière dont tu récupères la requête et lamanière dont tu formattes la réponse. A vrai dire le Web Service est un concept tellement simple que ça peut bien être codé dans n'importe quoi qui sait lire/écrire du XML.
[^] # Re: Le php
Posté par Éric (site web personnel) . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 5.
Plein .. la connectivité c'est LE point fort de PHP. PHP est surtout fait pour gérer des frontal Web, et se connecter avec une application ou un autre composant qui gèrera le métier.
- utilisations d'objets COM et composants .NET sous Windows : http://www.php.net/manual/en/ref.com.php(...)
- utilisation d'objets .NET avec Mono : http://pecl.php.net/package/mono(...)
- utilisations d'objets Java (PHP4 uniquement) : http://www.php.net/manual/en/ref.java.php(...)
- utilisation d'une librairie partagée (en C ?) arbitraire : http://pecl.php.net/package/ffi(...)
- utilisation de code et d'objets Perl : http://pecl.php.net/package/perl(...)
- utilisation de code et d'objets Python : http://pecl.php.net/package/python(...)
Plus génériques :
- par XML-RPC : http://www.php.net/manual/en/ref.xmlrpc.php(...)
- par SOAP : http://fr.php.net/soap(...)
Ca donne déjà un bon panel des possibilités (j'ai ouie dire aussi d'un connecteur ruby mais il n'a pas l'air de se trouver officialisé sur PHP, PEAR ou PECL).
Dans l'optique inverse on peut intégrer PHP comme langage de script d'une plus grosse application (à la manière d'ActivePerl et autres) : http://pecl.php.net/package/PHPScript(...)
L'extension Java n'a pas été portée vers PHP5 mais Sun a décidé de faire toutes ses implémentations de référence pour son futur JSR avec PHP. Sun s'est donc engagé avec Zend pour réaliser la connectivité complète PHP/Java (dans les deux sens). C'est à priori un gage de sérieux et de pérénité pour les interractions avec Java (le temps qu'ils fassent l'implémentation PHP5).
Coté plus applicatif on a aussi des connecteurs vers pas mal de trucs. Au dernier forum PHP on avait une entreprise qui exposait ce qu'elle a fait sur son intranet : un frontal PHP qui se connecte à leur ERP SAP pour le piloter et fournir des interfaces Web pour les trucs utilisés.
L'idée est là : pas de refaire l'application Java ou de refaire un ERP, mais de faire rapidement un frontal très simple qui utilise des connecteurs pour chercher la logique métier. PHP s'occupe alors de la partie Web (et uniquement de la partie Web) en évitant de monter tout un J2EE et des concepts complexes là où ce n'est pas nécessaire.
> mais qui doit-on accabler?
Pas le langage certes, mais quand on me dit que ça ne gère pas X, Y, Z ... la question est souvent "oui, mais vous en avez vraiment besoin ? si vous repartez sur quelques petites lignes simples au lieu de faire une grosse architecture monstre, vous n'en auriez peut être pas besoin.
[^] # Re: Safari != KHTML
Posté par Éric (site web personnel) . En réponse au journal Les patches de safari.... Évalué à 2.
Cette affirmation est toute personnelle. Le libre à ma connaissance se limite au respect de 4 principes de base au niveau des droits accordés aux utilisateurs.
Tu peux tout à fait faire du libre dans ton coin, sans aucune coopération, ça restera du libre.
Quant au renommage c'est quelque chose de *bien* au contraire. A partir du moment où il ne s'agit plus du même soft à la base, il faut éviter de pourrir le projet original, de rajouter de la confusion pour les utilisateurs, etc. Il y a d'ailleur aussi quelques obligations légales car si le code est libre, le nom en général ne l'est pas. Je ne sais pas si le nom "konqueror" appartient au projet kde, mais il n'appartient certainement pas à Apple.
Je ne t'ai pas vu raler quand le projet Xorg a forké Xfree86 en changeant de nom, ce n'est pas un projet "libre" ça pourtant ?
[^] # Re: Une question pour un non expert J2EE
Posté par Éric (site web personnel) . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 2.
Pareil, en PHP tu peux poser tes fichiers PHP et utiliser direct. Il faut juste poser les binaires avant ;). Je ne dis pas que c'est pareil à la seconde près, mais en pratique c'est kifkif.
Du coté compatibilité des architectures et des systèmes, PHP n'a pas à rougir de Java tu sais. Je ne crois pas qu'on puisse vraiment faire un choix ou l'autre là dessus.
[^] # Re: Contradiction dans les dires
Posté par Éric (site web personnel) . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 2.
C'est vrai que j'aurai du préciser.
Si tu veux faire un singleton global, il faudra stoquer/lire tous ses attributs en base de données (tu auras plusieurs instances mais quand tu utilises les attributs, tu utilises la bases de données (qui elle est globale).
[^] # Re: Contradiction dans les dires
Posté par Éric (site web personnel) . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 2.
Le problème en question est réglé (c'est grosso modo *la* plus grosse amélioration de PHP5). On a des méthodes statiques, des attributs statiques, les objets sont bien des références ... implémenter un singleton en PHP5 c'est 10 lignes de code :
class monSingleton {
static $instance ;
static function getInstance() {
if (!isset(self::$instance)) {
self::$instance = new monSingleton ;
}
return self::$instance ;
}
}
$objSingleton = monSingleton::getInstance() ;
[^] # Re: Le php
Posté par Éric (site web personnel) . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 1.
Ca a du bon et du moins bon, c'est une philosophie. Ca permet à un mauvais programmeur de faire n'importe quoi. Ca permet aussi à un bon architecte de choisir son outil ou de faire une solution simple qui correspond à ses besoins.
Après l'avantage de PHP c'est que c'est globalement simple. On n'a pas le contrecoup d'une appli en C comme tu en parles. Si PHP a justement un avantage par rapport à Java sur lequel tout le monde s'accorde c'est sa simplicité. Malgré le fait qu'il co-existe 10 roues différentes, pour un soft bien codé (je ne parle pas de la myriade de bout de code PHP qu'on trouve sur le net ni des phpnuke & co) le code PHP est facilement compréhensible. En Java des fois c'est assez lourd donc il faut explorer quelques temps.
On a les avantages (choix) sans les désavantages (relecture). Les deux seuls problèmes arrivent sur les gens comme moi qui prennent 10 ans pour faire un choix, ou les gens qui codent mal par nature (et ceux là feront effectivement n'importe quoi)
[^] # Re: PHP != J2EE
Posté par Éric (site web personnel) . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 2.
Pour utiliser des objets abstraits sans SQL tu as je crois au moins une classe dans PEAR. Dans le framework que j'utilise on commence développer ce genre d'outil. Il y en a d'autres qui ont mené cette politique depuis le début et qui sont amha assez avancé pour que tu n'ai pas trop de critiques.
Ce que tu cherches est probablement http://pear.php.net/package/DB_DataObject(...) (ce n'est certainement pas l'implémentation la plus avancée mais comme c'est du PEAR, c'est probablement celle qui sera la plus mature à terme)
[^] # Re: Contradiction dans les dires
Posté par Éric (site web personnel) . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 3.
En fait des développeurs pas cher il y en a plein, le problème c'est qu'en PHP comme tu as la possibilité de faire n'importe quoi ... beaucoup le font. Si tu veux quelque chose de correct il faudra *chercher* le développeur correct.
Et ça pas de secret, le bon développeur, qu'il fasse du java ou du php, son prix n'est pas si différent. (même si ça reste probablement un peu plus faible sur PHP parce qu'il a de la concurrence)
[^] # Re: PHP != J2EE
Posté par Éric (site web personnel) . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 2.
Bref, ça existe aussi
[^] # Re: PHP != J2EE
Posté par Éric (site web personnel) . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 2.
[^] # Re: Le php
Posté par Éric (site web personnel) . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 4.
Oui PHP n'est pas fait pour une application multimédia. Mais comme tu dis on parle de frontaux Web. Développer un module PHP qui charge une lib C et en appelle les fonction, c'est l'histoire de quelques heures au plus. Je ne te dis pas de gérer ta logique métier en PHP, mais d'utiliser PHP pour ce qu'il sait faire : un frontal Web (éventuellement un peu plus loin si c'est plus simple vis à vis de l'existant mais on sort de son domaine de prédilection). Rien n'empêchera après de connecter ton PHP à des objets COM/RPC ou Java et d'en utiliser les méthodes.
Effectivement, ils auraient du rajouter dans la news "concurrents *dans le domaine Web*". Mais quand je vois le nombre de sites Web avec du J2EE de partout qui sont de véritables monstres pour faire quelque chose de super simple en PHP .. ça me fait un peu mal. Mis à part quelques exceptions, la plupart des sites Web "pourraient" tout à fait être fait en PHP. (attention, je n'ai pas dit que les autres langages sont à jeter pour autant, mais au moins il s'agit d'une alternative valable).
[^] # Re: Le php
Posté par Éric (site web personnel) . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 5.
Maintenant il est où ton problème ?
- l'envoi du mail ? rajouter un mail dans une queue c'est très rapide, ce n'est pas un problème et c'est le boulot du serveur de mail que de gérer sa queue pour l'envoie et gérer la charge mail.
- l'insertion dans la Bdd ? en général les sgbd qui sont fait pour supporter ce genre de volumes en nombre de connexions acceptent des instructions "delayed" ou des choses du genre, ce n'est donc pas un énorme problème non plus.
- l'interface avec les fournisseurs ? c'est vague, en général ça revient à appeler un programme qui fait son propre boulot, ou faire une requête sur le SGBD. Ce n'est pas ça non plus qui pose grand problème.
Si réellement tu as un problème de ce coté là tu fais une file avec ton SGBD ou avec un programme externe qui gère la file de commande. Tu n'as peut être pas un objet qui s'appelle "asynchrone" et qui présente une méthode toute jolie mais ça ne prend pas deux heures à faire.
Et comme je le répète, quand bien même ton exemple poserait problème, vu le nombre de gens qui ont besoin de gérer 10000 commandes simultanément via une interface Web ... ça voudrait dire que Java peut tout à fait être réservé à une niche très réduite, 99.99% du Web restant avec un outil simple comme PHP, même pas capable de gérer une dizaine de millier de commande simultanées ;)
> - tu gères la montée en charge.
Grande question. Java "supporte" la charge, PHP permet une scallabilité. En PHP tu n'as pas tout ce qui est résident en mémoire, tout ce qui est commun, transactionnel et tout ça. Le propre du modèle c'est que pour monter en charge il suffit de rajouter un serveur en parralèle, et l'essentiel des problèmes de concurence ou de charge se retrouvent coté SGBD. Comme les bons SGBD savent aussi se gérer en cluster avec plusieurs frontaux ... il n'y a pas de réels problèmes de scalabilité.
[^] # Re: Le php
Posté par Éric (site web personnel) . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 4.
Il ne dit pas la même chose que toi : il dit qu'il ne connait pas donc s'abstient de juger. Toi tu dis "c'est pas bon". Il me semble qu'il y a une nuance importante (un fossé ?).
> PHP est limité aux petites
> et moyennes applis web et ne joue pas du tout dans la même cour
> que J2EE et .NET
Je ne conteste pas encore, je demande simplement "pourquoi ?" et "où sont tes arguments ?"
Il y a effectivement des fonctionnalités très avancées en Java qui ne sont pas présentes en PHP. Maintenant le nombre d'application Web en ayant *besoin* est à ma connaissance *très* limité.
je cherche donc à comprendre un peu ton affirmation.
[^] # Re: PHP != J2EE
Posté par Éric (site web personnel) . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 3.
Qu'en est-il de se que tu fais passer dans cette API ? le SQL n'est standard que sur le papier. En pratique il y a plein de différences suivant les serveurs, même dans les gros connus.
Et pour vous qui parlez de super appli qui ont besoin de super fonctionnalités super avancés, vous avez probablement un code SQL qui est adapté à votre SGBD pour exploiter au mieux les fonctionnalités.
Une API commune c'est très bien, d'ailleurs PHP5 est en train d'évoluer vers ça avec PDO (que j'espère voir dans PHP 5.1) ... mais ça n'est certainement pas suffisant pour disqualifier un langage vu que de toutes façons, sauf si tu te contentes de choses basiques ou de fonctionnalités non optimisées, il te faudra revoir tplus que la simple API quand tu changes de SGBD.
Ceci dit des wrappers qui offrent une API commune à plusieurs BDD, ça existe aussi en PHP (mais tu as la liberté de l'utiliser ou pas)