J'ai appris deux choses :
- Si à force de répéter pdt longtemps la même chose les gens finissent pas le croire, alors elle devient réalité. C'est ce que l'on appelle l'autoréalisation (en gros, ce vous avez prédit devient réalité ou se réalise par ses propres actions, inconscientes ou non)
- Lorsqu'une "vérité" ou un concept parait évident, c'est qu'il est moins évident que cela n'en a l'air (et que finalement ce n'est peut-être pas une si "vérité" que cela).
Le problème actuellement est de savoir si effectivement il y a un réel "trou" de la sécu et dans quelle mesure. Il ne faut pas oublier que la plupart des hommes politiques dites de droites ont été élevées aux mamelles du "néo-libéralisme". Pour eux, ils ne doit pas avoir de marché protégé (autrement dit tout est marché), donc pour faire accepter certaines choses au bas peuple que nous sommes, il faut leur rabacher jusqu'à ce qu'elles deviennent pour les gens réalités certaines "vérités" pré-machées.
Voir l'histoire récente de la baisse des impôts aux USA par exemple avec entre autre Bush à son premier mandat et les doctrines des conservateurs (les républicains).
Loin de moi de dire qu'il n'y a pas de "trous" de la sécu. Mais "on" nous l'a tellement rabaché que je commence a avoir des soupçons. D'autant plus que ca rabachage ne s'accompagne que de "vérités" un peu trop évidentes à mon goût.
Puisque tu as un Mac, je suppose que tu as dessus MacOS X installé.
Si c'est la cas, alors bienvenu dans un des environnements de programmation le plus avancé : Cocoa (implémentation d'OpenStep).
Pour ce faire:
- tu peux te mettre à l'ObjC qui est une couche objet au-dessus du C empruntant la syntaxe de Smalltalk. Toutefois, pour débuter, il peut paraitre rebutant,
- sinon, tu as aussi Java pour lequel un binding Cocoa existe. Il est plus facile à appréhender,
- et pour finir tu as l'extraordinaire F-script. C'est un langage de script élaboré par Apple et basé sur Smalltalk et qui te permet de faire rapidement des choses assez poussées. La syntaxe de smalltalk se distingue des autres mais, pour y avoir goûter, je la préfére aux autres car je trouve qu'elle aide à acquérir un esprit ... comment dire ... plus objet ? plus naturelle ? L'avantage de ce langage est qu'avec tu vas pouvoir optimiser ton utilisation de MacOS X ;)
Juste une petite question :
Ton routeur doit il te permette aussi un accès Internet (accès ADSL) par exemple ?
Dans le cas positif, alors il n'y a pas 36 solutions et un des routeurs ADSL qui soit doté des fonctionnalités demandées et qui soit top est un appareil de la famille des SpeedTouch de Thomson (ou d'Alcatel, je ne sais plus qui à vendu à qui). Le 530v4 et au poil mais il existe des solutions ... plus professionnelle.
Une URL : http://www.speedtouchdsl.com(...)
J'ai eu entre les main un tel appareil et je ne peux que te le conseiller.
Un régal à administrer. Il compore entre autre un firewall, un serveur DHCP intégré, du NATP, admin par telnet ou par Web, etc. De plus, je crois même que c'est un noyau Linux qui tourne dessus !
Comme yogi_thm, j'ai défini il y a quelques années une DTD pour écrire un CV. J'ai ensuite rédigé mon CV en XML conformément à la DTD puis des feuilles de style XSL pour la transformation XHTML et PDF via XSL-FO.
Ceci me permet d'avoir qu'une seule source et de pouvoir générer plusieurs sorties.
Seulement, récemment, j'ai commencer à percevoir qu'un CV pour le Web n'était pas forcément le même que celui que l'on donnerait par email (en PDF). En effet, avec un certain nombre d'années d'expérience, et sûrement selon cette expérience, si le CV sur le Web pouvait se permettre d'être plus éloquant, plus précis, celui envoyé se devait être plus concis et plus accrocheur. Ainsi, si mon CV sur le Web présente le détail de mes expériences, j'ai commencé récemment à rediger mon CV à envoyer (PDF) avec une approche orientée fonction.
Maintenant, il se trouve que j'ai deux sources différentes de CV et que comme chacun de toute façon se trouve avec un format spécifique (XHTML pour le Web, PDF pour l'envoie), j'ai perdu les avantages que me procurait la solution XML+XSLT.
Aussi, je pense qu'une solution CV écrite directement en XHTML avec support CSS pour la présentation dédiée au Web, et une autre écrite directement avec un traitement de texte pouvant générer du PDF est la solution optimale, exeptée si d'autres formats doivent être supportés comme pour par exemple les smartphones.
Sinon, quant à Latex, contrairement à ce qui est dis dans certains commentaires, il est un des outils qui te générera un CV de très bonne qualité: une présentation sobre mais professionnelle. De plus, il existe des packages Latex pour rédiger un CV. Les rendus des traitements de texte restent quand même, si on y met pas du sien, donc bcp de temps, et des fois plus que l'on ne metterait avec Latex (si on connait ce dernier), assez ... amateurs, voir limites bidouillages.
Toutes les VM ne sont pas codées en C directement.
Par exemple, la VM de Squeak a été codée directement en Smalltalk. Un traducteur, toujours en Smalltalk, se charge en ligne de le traduire en du code C mathématiquement correct. Ce qui signifie que la VM peut-être modifiée en directe dans l'environnement Squeak.
Il y a des projets intéressant de construire un OS objet au vrai sens du terme : un environnement dans lequel vivent des objets. IsaacOS en est un et j'attend qu'il soit suffisamment avancé avant de l'essayer. Il y en a d'autre, comme Unununium qui est écrit en Python.
Sinon, je suis d'accord avec toi sur le fait qu'avec une VM on ajoute juste une couche "applatie" au-dessus souvent d'un micro-noyau. C'est le cas par exemple de L4io (un OS construit avec io au-dessus de L4k)
Je ne vais pas répondre point par point à l'ensemble de ton post long.
Je crois que je ne me suis pas fait bien comprendre.
Dire que quand une variable référence un valeur d'un certain type n'implique pas que le langage est fortement typé.
De même, d'une variable qui référence une valeur d'un certain type, puis plus loin d'un autre type n'implique pas non plus que ton langage soit faiblement typé.
Si jamais ton langage te permet, par exemple, d'additionner un entier avec une chaîne de caractères (ton exemple) qui sont donc de deux types complétement différents, alors ton langage supporte le typage faible. Dans un typage fort, on ne peut utiliser une opération sur un type autre que celui attendu et il ne peut avoir de coercition mathématiquement incorrect. Par contre, le fait d'additionner un entier avec un réel ne posent pas de pb parce que l'un est sous-type de l'autre (on ne va pas entrer dans les détails du sous-typage), et dans ce cas on a souvent un transtypage implicite et qui est mathématiquement correcte.
Bien sûr cette condition n'est pas suffisante en elle même pour dire qu'un langage est typé fort.
Après, l'usage implicite ou explicite de coercition affaiblit la force du typage de ton langage ; c'est pour ça que l'on dit que tel langage à un typage plus fort qui tel autre, les deux étant de typage fort.
A côté de ceci, C est un langage à typage statique faible.
Le typage fort ou faible n'est pas une question de cuisine selon les points de vues. Des théories mathématiques ont déjà été élaborées pour décrire le typage (Hoar, Liskov, Cardelli pour ne citer que les plus connus).
PHP est un langage à typage faible (certains disent qu'il n'est pas typé même). Autrement dit, ta variable n'est pas d'un type bien définie.
Quand tu écris $a = "3 maisons" on lui a assigné une valeur de type chaîne de caractères. Mais lorsque tu fais $a + 1, si ta variable était de type fort, alors une erreur aurait été levée parce que l'on ne peut pas additionner une chaîne avec un entier. Au lieu de cela, le runtime a considéré juste la variable $a comme un entier et a donc appliqué un transtypage horrible (horrible car même le transtypage dans ce cas aurait dû aboutir à une erreur) ; c'est la raison aussi pour laquelle PHP est considéré comme non typé.
Si par contre, on avait $a = $a + 1 => "3 maisons1" alors on aurait pu dire qu'effectivement $a pourrait être de typage fort avec un transtypage implicite correcte qui est de convertir l'entier 1 en sa représentation chaîne de caractères avant de la passer à l'opération de concaténation '+' (si '+' est l'opérateur de concaténation bien sûr)
C'est une définition érronée. Il a mélangé typage fort avec statique.
En gros (avec des imprécisions) :
- le typage statique : le type des données sont connues à la compilation et sont stipulés par le codeur.
- le typage dynamique : le type des données ne sont connues qu'à l'exécution.
- typage fort : une donnée est d'un type et d'un seul bien définie.
- typage faible : une donnée n'est pas de type bien définie.
Sinon, les langages objet à VM ne sont pas tous peu performant. En fait, il n'y en a qu'un dont les perfs sont lamentables : Java.
Ceci est dû en partie à une différence de conception mais aussi d'approche. Dans Java, la VM est juste une machine à exécuter une application. Dans Smalltalk ou slate par exemple, la VM est plus un conteneur à objets ; en fait c'est bien une véritable machine dédiée à la gestion du cycle de vie des objets (c'est donc un véritable environnement d'exécution objet).
A part ceci, effectivement je n'ai pas très bien évalué les possibilités de Lisaac. Je me suis juste amusé un peu comme ça. Il y a un petit truc qui me dérange dedans, c'est son orientation "structure des objets". Avec io ou slate, le dév est orienté plus sur les objets eux-mêmes en tant que tel que sur leur structuration sous forme de prototype ; c'est une approche plus "dynamique" (ce que sont les objets, des entités avant tout dynamique).
JSF jusqu'à présent ne supporte pas MVC. Si on veut faire du MVC avec, on doit se le palucher à la main. JSF reste pour l'instant, grosso modo, une technologie qui permet de standardiser dans J2EE la gestion, de façon flexible, de l'aspect présentation. Il n'apporte aucun contrôleur et n'implémente pas de gestion de contrôle entre Vue et Modèle via le Contrôleur.
Juste une question : pourquoi Lisaac comme langage objet à prototypes. Il existe des langages à prototypes bcp plus avancés que Lisaac actuellement : io et slate pour ne citer que ces deux là par exemple.
Surtoût qu'ils ne sont pas destinés à la même chose.
- Struts est un framework MVC sur lequel peuvent se gréffer des technos différentes pour les aspects Vue et Modèle. La partie Contrôleur est fournie par Struts, mais il fournit aussi ses propres technos côté Modèle et surtoût Vue pour les développeurs qui ne veulent pas s'embêter.
- JSF est une techno de gestion de Vues.
Ce qui fait que l'on peut utiliser JSF avec Struts car ils sont complémentaires et non opposés.
Après lecture de ton journal, je me suis aussi penché sur mes log d'authentification. Et j'ai les même traces !
Pour mon serveur SSH, j'ai juste activé la connexion par clé publique (les clés des serveurs distants doivent être listés parmi ceux autorisés) + par user/challenge (pas par mot de passe).
Le root n'est pas non plus autorisé à se connecter par ssh.
Bien que cela devrait suffire, j'ai toutefois quelques inquiétudes.
La dernière tentative d'attaque date du 1er juin.
N'oublions pas tout de même que Microsoft a déposé des brevets sur les procédés de lecture et d'écriture d'un document au format XML selon la grammaire MS Office.
Donc, même si Microsoft ouvre les spécifications des différentes grammaires XML de sa suite MS Office, toute tentative de lecture d'un document XML MS Office ou toute écriture d'un document sous ce dernier format tombe sous la portée de ses brevets. Il peut ainsi donc soit interdire juridiquement ces procédés, soit demandé de bon royalities; autrement dit par ces moyens mettre de côté les logiciels libres.
De plus, je ne vois peu d'entrerprises ou communautés avec des reins assez solides pour trainer Microsoft dans de longues et difficiles procés pour invalider ses brevets.
C'est une question d'équilibre. Le compromis tends vers un équilibre bas, tandis que le concensus tend vers un équilibre haut.
Or, comme par hasard, la démocratie s'appuie sur un concensus (et pas sur une majorité comme bcp trop de monde croit), raison pour laquelle, entre autre, la démocratie peut paraitre difficile à appliquer.
A cette phrase toute faite, je pourrais aussi donner celle là :
"A ne pas être assez ambitieux, on rate trop d'occasions pour réellement avancer".
Evidemment, comme la tienne, même s'il y a un fond de vérité, elle ne signifie finalement pas grands choses.
L'intérêt du conseil n'est pas de plomber ses relations avec le parlement.
A mon opinion, fondé sur le contenu du TCE relatif aux institutions, l'intérêt du Conseil des Ministres et de faire accepter les lois et lois cadres qui répondent à la stratégie du Conseil Européen. Si ceci doit passer par un conflit avec le Parlement, je pense qu'ils n'hésiteront pas. Maintenant, bien sûr, il est possible qu'il y est peu de choses avec lesquelles ces deux institutions risquent d'entrer réellement en conflit.
Sur le papier on peut le dire. Dans la pratique c'est beaucoup moins évident. Ça doit donner un petit avantage au Conseil. Mais dans les cas où les désaccords sont profonds, je ne vois pas le conseil jouer à ce "petit jeu".
Pourtant, c'est bien à ce petit jeu que joue le Conseil des Ministres avec la directive sur les brevets logiciels. Si, et je l'espère, le Parlement Européen arrive à nouveau à bien amender la directive, nous serons alors en mesure de mieux apprécier la procédure de co-décision et l'influence (sous les traités actuels) du Conseil des Ministres. Ceci permettra alors de mieux percevoir son pouvoir une fois le TCE appliquée (étant donné que son pouvoir est renforcé par le TCE).
Je voudrais juste te dire qu'il n'y a pas lieu de comparer les institutions françaises avec celles de la futur Union Européenne. Pas plus que les institutions françaises que celle de l'UE sont démocratiques. Les institutions françaises sont avant tout républicaines. Donc, s'appuyer sur ces dernières pour montrer que celles européennes sont "mieux" est un peu tiré par les cheveux. De plus, l'UE n'est pas un Etat mais une confédération d'états (le terme confédération est certe malheureux puisque l'UE ne sera pas réellement une confédération même si le TCE laisse des portes ouvertes).
Non, c'est malheureusement vrai.
D'abord, directive européenne est un terme des traité actuels. Avec le TCE, on parle de lois et lois-cadre.
Ensuite :
- Qualifié la procédure de codécision entre le Parlement et le Conseil des Ministres de contre pouvoir est, AMHA, tiré par les cheveux. Je parlerai ici plutot d'"encadrement" des décisions avec cette procédure de codécision.
- le Parlement Européen vote le président de la Commission sur présentation du Conseil Européen, n'oublions pas cela. De plus, c'est le Conseil Européen avec consultation (ils parlent d'un commun accord) du président de la Commission qui décide de la composition de ladite Commission (sic). (Article I-27)
- Ensuite, le Parlement ne pourra demander des comptes à la Commission que par une motion de censure ... sur sa gestion (ce qui est le cas sous les traités actuels). Par contre, au travers de la sous-section 4 de la section I du Titre IV, Chapitre I de la partie III (les articles III-347 à III-352), relatives à la Commission Européenne, nous voyons bien que c'est le Conseil des Ministres qui est doté d'un véritable contrôle sur la Commission. Ce qui fait que dans certains cas (ceux où le Parlement et le Conseil ne s'accordent pas et que des intérêts du Conseil priment), la procédure de co-décision est plus ou moins biaisée (ceci est mon opinion).
- l'article III-396 parle bien de la procédure de co-décision.
Tu es donc pour une concurrence faussée, que l'Europe favorise plutot l'entreprise de tel pays par rapport à celle d'un autre? ...
Je voudrais juste remettre les choses à leur place ici.
Dire "je ne suis pas pour une concurrence libre et non faussée" ne signifie pas pour autant être pour une concurrence faussée au sens où des entreprises sont plus favorisés que d'autre par l'action, par exemple, de l'Etat.
Le discours "concurrence libre et non faussée" est une théorie économique libérale qui a été elle même battue en brêche par des libéraux ! Actuellement, ce sont surtout plus des idéologues libéraux (très présents dans les milieux politiques) que de véritables économistes qui pronent ce genre de discours.
Ce qui vient plus à l'opposé, du point de vue science économique (un bien grand mot ça), de la concurrence, c'est la coopération. La croissance endogène (une autre théorie économique) reprend le concept de coopération.
Sinon, pour apporter de l'eau au moulin, ce sont principalement les articles III-161 et III-162 qui définissent le contour de la "concurrence libre et non faussé" : les entreprises ne doivent pas se rapprocher pour fausser la concurrence et sont interdits toute entreprise en position de dominance et qui, par celle-ci, fausse la concurrence ou la libre circulation des biens et services. Toutefois, avec le paragraphe 3 de l'article III-161, la coopération entre entreprises est autorisée. Néanmoins, celle-ci reste sous contrôle de réglements adoptés par le Conseil des Ministres seul (pas de codécision avec le Parlement Européen ici) et évidemment proposés par la Commission Européenne (article III-163). Autrement dit, tout ça reste sous le regard vigilent à la fois du Conseil des Ministres et de la Commission.
L'informatique a évoluée et de nouveaux besoins sont apparus, les principaux étant la sécurité et la productivité, ...
Le langage C n'était qu'une illustration au premier point, sur les performances. Pour l'époque il répondait bien aux besoins.
Maintenant, bien sûr, il y a d'autres considérations à prendre, n'empêche que l'excuse à deux balles de faire des gros lourdaux parce que les machines dans 10 ans seront plus performantes me laissent plutot froid ... ou en colère.
Là encore l'informatique a évolué : le système de communication inter-programme d'Unix est complètement dépassé ...
Je parlais du concept : les outils qui rendent chacun 1 et 1 seul service et par la combinaison du tout on accomplissait des tâches plus complexes. Le système de communication inter-processus d'Unix répondait de façon pertinente à celui-ci et ceci était aussi une illustration dans mes propos. Mais comme tu le dis, les besoins évoluent. Or, les solutions eux n'ont pas évolués ou alors sans répondre à ce concept d'Unix.
Le système de fichier devient ainsi un espace hiérarchique de nommage d'objets de nature diverse.
Ce principe était surtout nécessaire dans le cadre de l'environnement pré-cité visant à faire communiquer les programmes. Mais là encore l'absence totale d'information sur la nature et la structuration des infos limite clairement l'utilité de simples flux binaires référencés par des fichiers.
Le système de fichier comme un espace de nommage d'objets n'est pas seulement utile pour les programmes, mais aussi pour l'utilisateur qui intéragit avec l'information. L'objet peut très être considéré comme une information ou un composé d'information. Or, c'est ce dernier que souhaite, AMHA, manipuler l'utilisateur et non telle ou telle appli. Le pb actuel est que le concept de filesystem-centric (donc j'ai donné ici aussi une illustration avec l'espace de nommage) n'est malheureusement plus apréhendé dans la conception des outils actuels. Voir même, par rapport à ce concept, on ne s'attache plus à faire évoluer de façon cohérente les systèmes de systèmes de fichiers pour répondre aux nouvelles attentes des utilisateurs.
La philosophie d'Unix n'était destinée qu'aux informaticiens, et si tu veux uniquement tenir compte de la philo alors oui, Unix est mort, ceux qui survivent sont ceux qui ont su évoluer et s'ouvrir à d'autres utilisateurs (MacOSX, Linux, etc.). Qui s'en plaindra ?
Je ne suis pas d'accord avec toi. La philosophie d'Unix était destiné avant tout à la conception d'un système qui réponde aux attentes avancées de ses utilisateurs, qu'ils soient informaticien ou simple secrétaire. Le pb est que si à l'origine ce système a répondu aux exigences de ses utilisateurs (d'où son rapide succès), les différentes sociétés qur Unix n'ont pas prises en compte ses précéptes. Et aujourd'hui il en est de même de la communauté libre.
Unix, ce n'est pas seulement un noyau. C'est plus que cela. Et je crois bien que cela fait depuis un certain temps qu'Unix est à l'agonie.
Mais personne s'en plaindra parce que très peu savent ce qu'est Unix et on continuera à s'agacer avec des systèmes bancales, lourdaux, qui simulent des réponses à tes attentes quand ils ne te convainquent pas que tes attentes c'est truc et pas machin.
Le pb vient que l'on ne dispose pas des outils adéquats et qui font correctement le boulot et jusqu'au bout, le tout de façon transparente pour l'utilisateur.
Tu classes tes documents en fonction d'une hiérarchie de répertoires, mais pas uniquement. Et ceci de la même façon que tu créés des catégories pour classer l'information que tu manipules. S'il s'avère complexe, c'est avant tout par ton fait, et tu aurais la même complexité avec d'autres techniques. Après, c'est une question de point de vue sur ton information (voir Plan 9 par exemple qui résout ce pb de façon élégante). Et non ça ne prend pas trop de temps de créer tes répertoires (catégories) et d'y classer tes docs si tu disposes des outils adéquat (c'est là où le bas blesse, j'en convient, car cela fait belle lurette que nous avons perdu l'aspect filesystem-centric dans nos applications quotidiennes).
Sinon, effectivement, les besoins évoluent. Mais les bases sous Unix (filesystem-centric) existent et permettent, AHMA, efficacement d'implémenter des solutions répondant à ces besoins. Le pb est que ces bases ne sont même pas prises en comptes. Au lieu de les faire évoluer, les améliorer, on préfère implémenter des idées venant du monde MS Windows ou MacOS qui sont avant tout application-centric.
Bien sûr, tout n'est pas noir non plus et il y a des tentatives. Par exemple, le système de fichier ReiserFS 4 qui permet d'ajouter des méta données relatives à un fichier ou groupe de fichiers.
En fait, parce que tout est fichier, tu peux très bien imaginer un fichier de fichiers, ces derniers étant des groupes d'information, et qui permettent de référencer d'autres fichiers ... dans d'autres fichiers ou dans le même fichier composé ! Je pense qu'à ce niveau là (mais peut être que je me trompe) nous sommes limité que par notre perception (qui est tiré de nos connaissances actuelles et de nos habitudes) et par notre imagination.
Tout à fait. Plan 9 est au jour d'aujourd'hui le système qui a poussé le plus loin le concept de filesystem-centric. Ce qui est dommage, c'est qu'il soit arrêté d'être développé et qu'aucun autre Unix tente de récupérer ses bonnes idées. J'ai l'impréssion déasagréable que l'on préfère reprendre les idées de MS Windows ou MacOS :(
[^] # Re: Terroriste!?
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Comment des vendeurs essaient de breveter les solutions à des failles de sécurité qui leur sont fournies. Évalué à 3.
- Si à force de répéter pdt longtemps la même chose les gens finissent pas le croire, alors elle devient réalité. C'est ce que l'on appelle l'autoréalisation (en gros, ce vous avez prédit devient réalité ou se réalise par ses propres actions, inconscientes ou non)
- Lorsqu'une "vérité" ou un concept parait évident, c'est qu'il est moins évident que cela n'en a l'air (et que finalement ce n'est peut-être pas une si "vérité" que cela).
Le problème actuellement est de savoir si effectivement il y a un réel "trou" de la sécu et dans quelle mesure. Il ne faut pas oublier que la plupart des hommes politiques dites de droites ont été élevées aux mamelles du "néo-libéralisme". Pour eux, ils ne doit pas avoir de marché protégé (autrement dit tout est marché), donc pour faire accepter certaines choses au bas peuple que nous sommes, il faut leur rabacher jusqu'à ce qu'elles deviennent pour les gens réalités certaines "vérités" pré-machées.
Voir l'histoire récente de la baisse des impôts aux USA par exemple avec entre autre Bush à son premier mandat et les doctrines des conservateurs (les républicains).
Loin de moi de dire qu'il n'y a pas de "trous" de la sécu. Mais "on" nous l'a tellement rabaché que je commence a avoir des soupçons. D'autant plus que ca rabachage ne s'accompagne que de "vérités" un peu trop évidentes à mon goût.
# Prog pour MacOS X
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Commencer à programmer ?. Évalué à 4.
Si c'est la cas, alors bienvenu dans un des environnements de programmation le plus avancé : Cocoa (implémentation d'OpenStep).
Pour ce faire:
- tu peux te mettre à l'ObjC qui est une couche objet au-dessus du C empruntant la syntaxe de Smalltalk. Toutefois, pour débuter, il peut paraitre rebutant,
- sinon, tu as aussi Java pour lequel un binding Cocoa existe. Il est plus facile à appréhender,
- et pour finir tu as l'extraordinaire F-script. C'est un langage de script élaboré par Apple et basé sur Smalltalk et qui te permet de faire rapidement des choses assez poussées. La syntaxe de smalltalk se distingue des autres mais, pour y avoir goûter, je la préfére aux autres car je trouve qu'elle aide à acquérir un esprit ... comment dire ... plus objet ? plus naturelle ? L'avantage de ce langage est qu'avec tu vas pouvoir optimiser ton utilisation de MacOS X ;)
Enfin voilà mon avis.
# Question
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Besoin d'aide pour achat de routeur. Évalué à 3.
Ton routeur doit il te permette aussi un accès Internet (accès ADSL) par exemple ?
Dans le cas positif, alors il n'y a pas 36 solutions et un des routeurs ADSL qui soit doté des fonctionnalités demandées et qui soit top est un appareil de la famille des SpeedTouch de Thomson (ou d'Alcatel, je ne sais plus qui à vendu à qui). Le 530v4 et au poil mais il existe des solutions ... plus professionnelle.
Une URL : http://www.speedtouchdsl.com(...)
J'ai eu entre les main un tel appareil et je ne peux que te le conseiller.
Un régal à administrer. Il compore entre autre un firewall, un serveur DHCP intégré, du NATP, admin par telnet ou par Web, etc. De plus, je crois même que c'est un noyau Linux qui tourne dessus !
# Idem: CV en XML
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Mon CV, comment s'y prendre.. Évalué à 5.
Ceci me permet d'avoir qu'une seule source et de pouvoir générer plusieurs sorties.
Seulement, récemment, j'ai commencer à percevoir qu'un CV pour le Web n'était pas forcément le même que celui que l'on donnerait par email (en PDF). En effet, avec un certain nombre d'années d'expérience, et sûrement selon cette expérience, si le CV sur le Web pouvait se permettre d'être plus éloquant, plus précis, celui envoyé se devait être plus concis et plus accrocheur. Ainsi, si mon CV sur le Web présente le détail de mes expériences, j'ai commencé récemment à rediger mon CV à envoyer (PDF) avec une approche orientée fonction.
Maintenant, il se trouve que j'ai deux sources différentes de CV et que comme chacun de toute façon se trouve avec un format spécifique (XHTML pour le Web, PDF pour l'envoie), j'ai perdu les avantages que me procurait la solution XML+XSLT.
Aussi, je pense qu'une solution CV écrite directement en XHTML avec support CSS pour la présentation dédiée au Web, et une autre écrite directement avec un traitement de texte pouvant générer du PDF est la solution optimale, exeptée si d'autres formats doivent être supportés comme pour par exemple les smartphones.
Sinon, quant à Latex, contrairement à ce qui est dis dans certains commentaires, il est un des outils qui te générera un CV de très bonne qualité: une présentation sobre mais professionnelle. De plus, il existe des packages Latex pour rédiger un CV. Les rendus des traitements de texte restent quand même, si on y met pas du sien, donc bcp de temps, et des fois plus que l'on ne metterait avec Latex (si on connait ce dernier), assez ... amateurs, voir limites bidouillages.
[^] # Re: Pourquoi Lisaac ?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Spécifier une nouvelle librairie graphique. Évalué à 1.
Par exemple, la VM de Squeak a été codée directement en Smalltalk. Un traducteur, toujours en Smalltalk, se charge en ligne de le traduire en du code C mathématiquement correct. Ce qui signifie que la VM peut-être modifiée en directe dans l'environnement Squeak.
Il y a des projets intéressant de construire un OS objet au vrai sens du terme : un environnement dans lequel vivent des objets. IsaacOS en est un et j'attend qu'il soit suffisamment avancé avant de l'essayer. Il y en a d'autre, comme Unununium qui est écrit en Python.
Sinon, je suis d'accord avec toi sur le fait qu'avec une VM on ajoute juste une couche "applatie" au-dessus souvent d'un micro-noyau. C'est le cas par exemple de L4io (un OS construit avec io au-dessus de L4k)
[^] # Re: Ruby On Rails
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 2.
Je crois que je ne me suis pas fait bien comprendre.
Dire que quand une variable référence un valeur d'un certain type n'implique pas que le langage est fortement typé.
De même, d'une variable qui référence une valeur d'un certain type, puis plus loin d'un autre type n'implique pas non plus que ton langage soit faiblement typé.
Si jamais ton langage te permet, par exemple, d'additionner un entier avec une chaîne de caractères (ton exemple) qui sont donc de deux types complétement différents, alors ton langage supporte le typage faible. Dans un typage fort, on ne peut utiliser une opération sur un type autre que celui attendu et il ne peut avoir de coercition mathématiquement incorrect. Par contre, le fait d'additionner un entier avec un réel ne posent pas de pb parce que l'un est sous-type de l'autre (on ne va pas entrer dans les détails du sous-typage), et dans ce cas on a souvent un transtypage implicite et qui est mathématiquement correcte.
Bien sûr cette condition n'est pas suffisante en elle même pour dire qu'un langage est typé fort.
Après, l'usage implicite ou explicite de coercition affaiblit la force du typage de ton langage ; c'est pour ça que l'on dit que tel langage à un typage plus fort qui tel autre, les deux étant de typage fort.
A côté de ceci, C est un langage à typage statique faible.
Le typage fort ou faible n'est pas une question de cuisine selon les points de vues. Des théories mathématiques ont déjà été élaborées pour décrire le typage (Hoar, Liskov, Cardelli pour ne citer que les plus connus).
[^] # Re: Ruby On Rails
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 3.
Quand tu écris $a = "3 maisons" on lui a assigné une valeur de type chaîne de caractères. Mais lorsque tu fais $a + 1, si ta variable était de type fort, alors une erreur aurait été levée parce que l'on ne peut pas additionner une chaîne avec un entier. Au lieu de cela, le runtime a considéré juste la variable $a comme un entier et a donc appliqué un transtypage horrible (horrible car même le transtypage dans ce cas aurait dû aboutir à une erreur) ; c'est la raison aussi pour laquelle PHP est considéré comme non typé.
Si par contre, on avait $a = $a + 1 => "3 maisons1" alors on aurait pu dire qu'effectivement $a pourrait être de typage fort avec un transtypage implicite correcte qui est de convertir l'entier 1 en sa représentation chaîne de caractères avant de la passer à l'opération de concaténation '+' (si '+' est l'opérateur de concaténation bien sûr)
[^] # Re: Ruby On Rails
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 3.
En gros (avec des imprécisions) :
- le typage statique : le type des données sont connues à la compilation et sont stipulés par le codeur.
- le typage dynamique : le type des données ne sont connues qu'à l'exécution.
- typage fort : une donnée est d'un type et d'un seul bien définie.
- typage faible : une donnée n'est pas de type bien définie.
[^] # Re: Pourquoi Lisaac ?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Spécifier une nouvelle librairie graphique. Évalué à 2.
Sinon, les langages objet à VM ne sont pas tous peu performant. En fait, il n'y en a qu'un dont les perfs sont lamentables : Java.
Ceci est dû en partie à une différence de conception mais aussi d'approche. Dans Java, la VM est juste une machine à exécuter une application. Dans Smalltalk ou slate par exemple, la VM est plus un conteneur à objets ; en fait c'est bien une véritable machine dédiée à la gestion du cycle de vie des objets (c'est donc un véritable environnement d'exécution objet).
A part ceci, effectivement je n'ai pas très bien évalué les possibilités de Lisaac. Je me suis juste amusé un peu comme ça. Il y a un petit truc qui me dérange dedans, c'est son orientation "structure des objets". Avec io ou slate, le dév est orienté plus sur les objets eux-mêmes en tant que tel que sur leur structuration sous forme de prototype ; c'est une approche plus "dynamique" (ce que sont les objets, des entités avant tout dynamique).
[^] # Re: Ruby On Rails
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 1.
# Pourquoi Lisaac ?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Spécifier une nouvelle librairie graphique. Évalué à 4.
Juste une question : pourquoi Lisaac comme langage objet à prototypes. Il existe des langages à prototypes bcp plus avancés que Lisaac actuellement : io et slate pour ne citer que ces deux là par exemple.
[^] # Re: Ruby On Rails
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 1.
[^] # Re: Ruby On Rails
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 2.
- Struts est un framework MVC sur lequel peuvent se gréffer des technos différentes pour les aspects Vue et Modèle. La partie Contrôleur est fournie par Struts, mais il fournit aussi ses propres technos côté Modèle et surtoût Vue pour les développeurs qui ne veulent pas s'embêter.
- JSF est une techno de gestion de Vues.
Ce qui fait que l'on peut utiliser JSF avec Struts car ils sont complémentaires et non opposés.
# Moi aussi !
Posté par Miguel Moquillon (site web personnel) . En réponse au journal une petite attaque. Évalué à 2.
Après lecture de ton journal, je me suis aussi penché sur mes log d'authentification. Et j'ai les même traces !
Pour mon serveur SSH, j'ai juste activé la connexion par clé publique (les clés des serveurs distants doivent être listés parmi ceux autorisés) + par user/challenge (pas par mot de passe).
Le root n'est pas non plus autorisé à se connecter par ssh.
Bien que cela devrait suffire, j'ai toutefois quelques inquiétudes.
La dernière tentative d'attaque date du 1er juin.
# Brevets
Posté par Miguel Moquillon (site web personnel) . En réponse à la dépêche La guerre des formats continue !. Évalué à 9.
Donc, même si Microsoft ouvre les spécifications des différentes grammaires XML de sa suite MS Office, toute tentative de lecture d'un document XML MS Office ou toute écriture d'un document sous ce dernier format tombe sous la portée de ses brevets. Il peut ainsi donc soit interdire juridiquement ces procédés, soit demandé de bon royalities; autrement dit par ces moyens mettre de côté les logiciels libres.
De plus, je ne vois peu d'entrerprises ou communautés avec des reins assez solides pour trainer Microsoft dans de longues et difficiles procés pour invalider ses brevets.
[^] # Re: il est où le vote des journaux ???
Posté par Miguel Moquillon (site web personnel) . En réponse au journal C'est fini. Évalué à 10.
Or, comme par hasard, la démocratie s'appuie sur un concensus (et pas sur une majorité comme bcp trop de monde croit), raison pour laquelle, entre autre, la démocratie peut paraitre difficile à appliquer.
A cette phrase toute faite, je pourrais aussi donner celle là :
"A ne pas être assez ambitieux, on rate trop d'occasions pour réellement avancer".
Evidemment, comme la tienne, même s'il y a un fond de vérité, elle ne signifie finalement pas grands choses.
[^] # Re: Les conséquences du non ?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Lettre ouverte aux français. Évalué à 2.
A mon opinion, fondé sur le contenu du TCE relatif aux institutions, l'intérêt du Conseil des Ministres et de faire accepter les lois et lois cadres qui répondent à la stratégie du Conseil Européen. Si ceci doit passer par un conflit avec le Parlement, je pense qu'ils n'hésiteront pas. Maintenant, bien sûr, il est possible qu'il y est peu de choses avec lesquelles ces deux institutions risquent d'entrer réellement en conflit.
Pourtant, c'est bien à ce petit jeu que joue le Conseil des Ministres avec la directive sur les brevets logiciels. Si, et je l'espère, le Parlement Européen arrive à nouveau à bien amender la directive, nous serons alors en mesure de mieux apprécier la procédure de co-décision et l'influence (sous les traités actuels) du Conseil des Ministres. Ceci permettra alors de mieux percevoir son pouvoir une fois le TCE appliquée (étant donné que son pouvoir est renforcé par le TCE).
[^] # Re: Les conséquences du non ?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Lettre ouverte aux français. Évalué à 2.
[^] # Re: Les conséquences du non ?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Lettre ouverte aux français. Évalué à 3.
D'abord, directive européenne est un terme des traité actuels. Avec le TCE, on parle de lois et lois-cadre.
Ensuite :
- Qualifié la procédure de codécision entre le Parlement et le Conseil des Ministres de contre pouvoir est, AMHA, tiré par les cheveux. Je parlerai ici plutot d'"encadrement" des décisions avec cette procédure de codécision.
- le Parlement Européen vote le président de la Commission sur présentation du Conseil Européen, n'oublions pas cela. De plus, c'est le Conseil Européen avec consultation (ils parlent d'un commun accord) du président de la Commission qui décide de la composition de ladite Commission (sic). (Article I-27)
- Ensuite, le Parlement ne pourra demander des comptes à la Commission que par une motion de censure ... sur sa gestion (ce qui est le cas sous les traités actuels). Par contre, au travers de la sous-section 4 de la section I du Titre IV, Chapitre I de la partie III (les articles III-347 à III-352), relatives à la Commission Européenne, nous voyons bien que c'est le Conseil des Ministres qui est doté d'un véritable contrôle sur la Commission. Ce qui fait que dans certains cas (ceux où le Parlement et le Conseil ne s'accordent pas et que des intérêts du Conseil priment), la procédure de co-décision est plus ou moins biaisée (ceci est mon opinion).
- l'article III-396 parle bien de la procédure de co-décision.
[^] # Re: Les conséquences du non ?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Lettre ouverte aux français. Évalué à 3.
Je voudrais juste remettre les choses à leur place ici.
Dire "je ne suis pas pour une concurrence libre et non faussée" ne signifie pas pour autant être pour une concurrence faussée au sens où des entreprises sont plus favorisés que d'autre par l'action, par exemple, de l'Etat.
Le discours "concurrence libre et non faussée" est une théorie économique libérale qui a été elle même battue en brêche par des libéraux ! Actuellement, ce sont surtout plus des idéologues libéraux (très présents dans les milieux politiques) que de véritables économistes qui pronent ce genre de discours.
Ce qui vient plus à l'opposé, du point de vue science économique (un bien grand mot ça), de la concurrence, c'est la coopération. La croissance endogène (une autre théorie économique) reprend le concept de coopération.
Sinon, pour apporter de l'eau au moulin, ce sont principalement les articles III-161 et III-162 qui définissent le contour de la "concurrence libre et non faussé" : les entreprises ne doivent pas se rapprocher pour fausser la concurrence et sont interdits toute entreprise en position de dominance et qui, par celle-ci, fausse la concurrence ou la libre circulation des biens et services. Toutefois, avec le paragraphe 3 de l'article III-161, la coopération entre entreprises est autorisée. Néanmoins, celle-ci reste sous contrôle de réglements adoptés par le Conseil des Ministres seul (pas de codécision avec le Parlement Européen ici) et évidemment proposés par la Commission Européenne (article III-163). Autrement dit, tout ça reste sous le regard vigilent à la fois du Conseil des Ministres et de la Commission.
[^] # Re: mon avis.
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Unix, que sont devenus tes concepts ?. Évalué à 6.
Le langage C n'était qu'une illustration au premier point, sur les performances. Pour l'époque il répondait bien aux besoins.
Maintenant, bien sûr, il y a d'autres considérations à prendre, n'empêche que l'excuse à deux balles de faire des gros lourdaux parce que les machines dans 10 ans seront plus performantes me laissent plutot froid ... ou en colère.
Je parlais du concept : les outils qui rendent chacun 1 et 1 seul service et par la combinaison du tout on accomplissait des tâches plus complexes. Le système de communication inter-processus d'Unix répondait de façon pertinente à celui-ci et ceci était aussi une illustration dans mes propos. Mais comme tu le dis, les besoins évoluent. Or, les solutions eux n'ont pas évolués ou alors sans répondre à ce concept d'Unix.
Le système de fichier comme un espace de nommage d'objets n'est pas seulement utile pour les programmes, mais aussi pour l'utilisateur qui intéragit avec l'information. L'objet peut très être considéré comme une information ou un composé d'information. Or, c'est ce dernier que souhaite, AMHA, manipuler l'utilisateur et non telle ou telle appli. Le pb actuel est que le concept de filesystem-centric (donc j'ai donné ici aussi une illustration avec l'espace de nommage) n'est malheureusement plus apréhendé dans la conception des outils actuels. Voir même, par rapport à ce concept, on ne s'attache plus à faire évoluer de façon cohérente les systèmes de systèmes de fichiers pour répondre aux nouvelles attentes des utilisateurs.
Je ne suis pas d'accord avec toi. La philosophie d'Unix était destiné avant tout à la conception d'un système qui réponde aux attentes avancées de ses utilisateurs, qu'ils soient informaticien ou simple secrétaire. Le pb est que si à l'origine ce système a répondu aux exigences de ses utilisateurs (d'où son rapide succès), les différentes sociétés qur Unix n'ont pas prises en compte ses précéptes. Et aujourd'hui il en est de même de la communauté libre.
Unix, ce n'est pas seulement un noyau. C'est plus que cela. Et je crois bien que cela fait depuis un certain temps qu'Unix est à l'agonie.
Mais personne s'en plaindra parce que très peu savent ce qu'est Unix et on continuera à s'agacer avec des systèmes bancales, lourdaux, qui simulent des réponses à tes attentes quand ils ne te convainquent pas que tes attentes c'est truc et pas machin.
[^] # Re: 2 cts
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Unix, que sont devenus tes concepts ?. Évalué à 2.
[^] # Re: annuaire vs. moteur
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Unix, que sont devenus tes concepts ?. Évalué à 3.
[^] # Re: mouai
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Unix, que sont devenus tes concepts ?. Évalué à 3.
Sinon, effectivement, les besoins évoluent. Mais les bases sous Unix (filesystem-centric) existent et permettent, AHMA, efficacement d'implémenter des solutions répondant à ces besoins. Le pb est que ces bases ne sont même pas prises en comptes. Au lieu de les faire évoluer, les améliorer, on préfère implémenter des idées venant du monde MS Windows ou MacOS qui sont avant tout application-centric.
Bien sûr, tout n'est pas noir non plus et il y a des tentatives. Par exemple, le système de fichier ReiserFS 4 qui permet d'ajouter des méta données relatives à un fichier ou groupe de fichiers.
En fait, parce que tout est fichier, tu peux très bien imaginer un fichier de fichiers, ces derniers étant des groupes d'information, et qui permettent de référencer d'autres fichiers ... dans d'autres fichiers ou dans le même fichier composé ! Je pense qu'à ce niveau là (mais peut être que je me trompe) nous sommes limité que par notre perception (qui est tiré de nos connaissances actuelles et de nos habitudes) et par notre imagination.
[^] # Re: Unix, que sont devenus tes concepts ?
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Unix, que sont devenus tes concepts ?. Évalué à 2.