Miguel Moquillon a écrit 449 commentaires

C'est que j'utilise pour protéger les mots de passe d'accès à une application Web. Le sel et le stretching sont propres à chaque utilisateur et sont renouvelés à chaque changement de mots/phrases de passe.
Le SHA-2 ici utilisé est du SHA 512 et l'algorithme de cryptage avec le salt et stretching est celui en vigueur sous Unix.

Quant à l'AES (AES-256), je l'utilise plutôt pour chiffrer du contenu sensible et la clé utilisée elle-même chiffrée avec du CAST5 (CAST-128).

En lisant ton journal, je me suis dis que la plupart de tes besoins sont déjà adressés par Silverpeas et ceci sans grand travail d'intégration ou sans nécessiter de le coupler à un autre outil.

Silverpeas est un portail collaboratif open-source destiné aux utilisateurs finaux et, à ce titre, propose bon nombre d'applications prêts à emploi qui permettent, au fil du temps, de répondre aux évolutions des besoins.
Le credo de Silverpeas n'est toutefois pas d'être un simple portail d'applications ou d'être un pur player en GED, KM, … mais tout simplement de faciliter la collaboration entre les individus, les équipes et les organisations par le biais d'outils comme des GED, des forums, des agendas, etc.

Par contre, le module pour synchroniser le contenu d'un dossier local avec un dossier d'une GED dans Silverpeas n'est pas open-source et est payant il me semble. Mais généralement les utilisateurs préfèrent, apparemment, passer directement par les GED pour travailler sur leur document (il y a une édition en ligne basée sur du webdav).

Pour plus d'info cf. http://www.silverpeas.org

Ok, merci de l'information !

Pour moi, il n'y a en fait qu'une définition de la POO : celle qu'en a donnée son auteur, Alan Kay. Maintenant, dans les faits, il ne faut pas se cacher, il y a bien plusieurs formes de POO et desquelles, historiquement, nous pouvons en dessiner deux orientations :
- la première, celle telle que définie par son auteur, Alan Kay, et qui est centrée avant tout sur le comportement,
- l'autre, telle qu'elle a été perçue et évangélisée (en particulier par Ole-Johan Dahl et Kristen Nygaard (les auteurs de Simula) et leurs enfants spirituels), et dans laquelle l'approche est avant tout centrée sur la structuration ; une approche orientée classe. C'est cette approche qui est la plus en vogue.

Ensuite, le multi-dispatching, la généricité, les éléments de syntaxe (comme objet.method()), et autres joyeusetés ne sont que des détails techniques d'un langage et ceux-ci ne sont pas l’apanage de langages dit orienté-objet. D'autres types de langages peuvent aussi les implémenter comme des langages fonctionnels ou impératifs structurés.

Dans le cas de Go, on a les mécanismes d'encapsulation, de polymorphisme, d'introspection et de fonctions attachées à des types, en pratique ça permet déjà de faire des choses.

Oui, je suis tout à fait d'accord et c'est ce qui fait, à mes yeux, avec le go-routines, tout l'intérêt de Go.

Mon blog tourne sur dotclear 2.5.3. Déjà, j'ai du installer cette nouvelle version à la main alors qu'auparavant ça se faisait au clique.
Là, pour cette nouvelle version, encore une fois, la page de mise à jour ne me l'indique pas et donc j'ai la nette impression que je vais devoir me farcir son installation à la main.
Est-ce normal ?

Go propose aussi un système de programmation orienté objet, mais réduit à sa plus simple expression […]

Non. Décidément, on affuble de POO ou de langage orienté objet tout et n'importe quoi.
D'abord, ce n'est pas parce que tu rassembles des fonctions et des champs dans une structure que ça en fait de la POO. (Ni le fait d'associer une fonction à une structure ou à un type comme en Go.)
Et les auteurs n'ont jamais jusqu'à présent qualifié leur langage d'orienté objet ni de l'avoir conçu pour pouvoir faire de la POO. Ils restent dans la programmation structurée mais empruntent des techniques actuelles tout en restant pragmatique ; je prendrais pour exemple les interfaces dans Go.

Je me suis mal exprime, je voulais dire que "Administrateur" sonne un peu Français, je m'attendais plutôt a "Administrator" en utilisant la langue anglaise.

Ha ok. Ben en fait, non. Comme c'est le nom de l'utilisateur, il n'y a pas de traduction associé. C'est un vrai compte utilisateur et non virtuel. Après, le nom peut être modifié.

J'ai crée un compte sur votre Redmine, seulement je n'ai pas les permission d’accéder a la page "issues": https://tracker.silverpeas.org/projects/silverpeas/issues

Je t'ai affecté à un groupe qui te permet normalement de pouvoir consulter et poster des demandes.

A la fin de l'installation, il faut savoir être patient après le lancement de JBoss

Oui, effectivement. Silverpeas utilise actuellement JBoss 6.0 qui est lourd au démarrage dès qu'il y a une application un peu conséquente.

Dans le menu en haut a gauche, mon login est "Administrateur", bien que m’étant connecte avec "SilverAdmin".

En fait "SilverAdmin" est l'identifiant de connexion tandis que "Administrateur" est le nom de l'utilisateur et c'est ce dernier qui s'affiche en haut à gauche.

Si il y a un endroit plus indique pour faire part de ces remarques, je m'en ferai une joie :)

Oui, effectivement :
- il y a un issue tracker :
https://tracker.silverpeas.org/projects/silverpeas
- il y a aussi une mailing-list pour les utilisateurs :
https://groups.google.com/forum/#!forum/silverpeas-users

Désole pour le manque d'accent (et surement quelques fautes).

Je ne me permettrait aucune remarque là dessus, étant bien mal placé

En tout cas, merci pour ces retours.

Si je ne dis pas de bêtises il me semble que DragonFly est légèrement en avance sur FreeBSD de ce point de vue.

Oui il semblerait. En fait, si je ne me trompe pas, le Giant Lock dans DragonFlyBSD n'est plus qu'au niveau du VFS et il y a toujours un effort de réduire son usage. Après, l'architecture multi-threading de DragonFlyBSD diffère des autres BSD ; celle-ci s'appuie sur une approche de synchronisation par tokens qui peuvent transiter d'un CPU à l'autre.

Un des gros points faibles de FreeBSD est le « Giant Lock », autrement dit le mutex global intégré au kernel.

Heu, je suis surpris là. Je croyais que depuis les versions 7, FreeBSD avait fini par remplacé le Giant Lock au profit de locks plus fins ou d'une approche lockless. Est ce à dire que, finalement, ils seraient en retard là dessus vis à vis de DragonFlyBSD ?

Je répond à ton post mais aussi aux autres.
En fait, on peut distinguer deux approches orientés-objets :
- celle telle que définie par Alan Kay (le père de la POO) et au travers de laquelle l'accent est mis avant tout sur le comportement : à mes yeux, Smalltalk et Ruby s'inscrivent dans cette approche.
- celle, beaucoup plus pratiquée, initiée par les enfants de Simula (C++, Java, …), dans laquelle l'accent est mis avant tout sur la structuration au travers du concept de classe qui fusionne celui de de module et de type. Pour distinguer les deux, on peux désigner cette approche comme étant orienté-classe.

Ainsi, pour prendre l'exemple de GObject, c'est une tentative d'apporter au langage C cette couche de structuration issue de l'approche orienté-classe.
Et c'est aussi la raison pour laquelle la manière de programmer en Ruby diffère de celle en C++. Après, ce ne sont que des langages qui facilitent une certaine approche, mais n'empêchent pas les programmeurs de garder leurs habitudes.

Certains langages permettent l'héritage multiple, mais comme tout le monde le sait, ça pose des problèmes. Que faire ?

En fait, ce pb ne vient pas de la POO mais plus des limites des langages orientés-objet. Ce problème a été une des raisons pour laquelle les traits ont été introduits dans des langages orientés-objets (même dans Smalltalk avec Pharo). Un trait est, grosso-modo, un ensemble de propriétés que peuvent se partager les objets (les propriétés d'un trait sont décrites par des messages, associés ou non avec une méthode par défaut, que doivent comprendre les objets qui satisfont ce trait).

Mais, effectivement, contrairement au système à entités présenté ici, de par l'essence de la POO, l'accent est toujours mis sur le comportement (les messages), alors que, apparemment, d'après ton article, la programmation des jeux nécessiteraient plus une approche centrée sur les données.

Les paroles ont leur importance. Elles donnent une image, une orientation aux actes présentes et futures.
Mais ce sont les actes qui comptent et c'est à leur lumière que l'on peut juger des paroles. Alors oui, le monde n'est pas fait que de 0 et de 1, mais ce sont les actes qui le construisent. Les paroles, quant à elles, peuvent servir aussi à endormir. Donc, elle peut toujours nous sortir de grandes paroles grandiloquentes, mais si à côté les actes de ses congénères contredisent celles-ci, elles ne servent au final à rien si ce n'est nous donner du baume au cœur.

Ma machine perso est sous Arch et, depuis que systemd a remplacé le vieillissant init/confd/…, elle met légèrement plus de temps à démarrer. Par contre, l'arrêt est bien bcp plus rapide … heu sauf des fois quand il a du mal à démonter le montage NFS (avec autofs) pour je ne sais quelle raison. ça c'est de l'évolution.

Daniel Kurka a annulé sa tournée en France cette semaine pour des raisons familiales. Les présentations qui devaient avoir lieu à Lille, Nice et à Grenoble sont donc annulées.

Et justement, sauf erreur de ma part, GCC supporte l'optimisation tail-call (ou tail-recursion).

Systemd marche bien aussi sous Arch sur mon vieux portable (un Toshiba Satellite A40 Pro). Par contre, si je gagne en temps à l'arrêt de la machine, je ne gagne rien au démarrage comparé à l'init classique (dans lequel j'avais déjà parallélisé le lancement des daemons dans rc.conf).

A côté de ça, si le démarrage et l'arrêt des services via des fichiers de propriétés à-la-ini est sympa, ça devient vite abscons dès qu'il s'agit de jouer avec des .target et des dépendances dans les .service (par exemple dépend de truc mais peut démarrer en même temps mais doit attendre que truc ait fini pour finir lui aussi (ouf), etc.) -> bref une complexité qui me laisse perplexe comparé aux besoins (ici le démarrage des services).

Si j'ai bien compris avec xmonad, tu compile ta propre version configuré alors qu'avec awesome tu as un fichier exterieur au programme principal qui exécute ta configuration.

En fait,ton fichier de configuration est le programme principal qui est compilé puis lancé par XMonad. Il comporte donc l'instruction principale main :

main = xmonad defaults

Où xmonad est la fonction qui lance le gestionnaire de fenêtre avec les paramètres par défaut defaults ici.
Par exemple, sur le PC du boulot où j'utilise XMonad avec KDE4 :

defaults = kde4Config {
  -- simple stuff
    terminal           = myTerminal,
    focusFollowsMouse  = myFocusFollowsMouse,
    borderWidth        = myBorderWidth,
    modMask            = myModMask,
    workspaces         = myWorkspaces,
    normalBorderColor  = myNormalBorderColor,
    focusedBorderColor = myFocusedBorderColor,

  -- key bindings
    keys               = myKeys,
    mouseBindings      = myMouseBindings,

  -- hooks, layouts
    layoutHook         = myLayout,
    manageHook         = myManageHook,
    logHook            = (myLogHook >> setWMName "LG3D"),
    startupHook        = myStartupHook
}

où kde4Config est fourni par l'API de contribution de XMonad et les myquelquechose sont des paramètres de config qui me sont propre. Par exemple :

myTerminal = "urxvt -pe tabbed"

C'est à dire ?

Sous XMonad, tu as un support par défaut des workspaces virtuels et à côté, en contribution, un support de tags des fenêtres mais que je ne trouve pas très utilisable. En tout cas pas comme dans Awesome. Ce dernier, du moins dans la version que j'avais utilisé à l'époque, tu n'as pas de worspaces virtuels mais des regroupements de fenêtres sous des étiquettes (tag) et que tu peux afficher ou non sous l'action de raccourcis clavier.

Dans la même veine qu'Awesome, il y a XMonad, un autre tiling window manager. La différence entre les deux est que XMonad est écrit en Haskell et que la configuration se fait en Haskell ; c'est en fait une surcharge des paramètres ou du comportement par défaut de XMonad et qui est compilé puis chargé au démarrage du gestionnaire de fenêtre. Aussi, face à une erreur dans la configuration, XMonad s'exécute avec la configuration précédente (s'il n'y en avait pas, celle par défaut). De même, on peut charger à chaud la configuration que l'on a modifié sans avoir à quitter son environnement (en fait, c'est un redémarrage transparent de XMonad).

Par contre, il n'y pas le support des tags que l'on a dans Awesome et que j'aime bien.

Je ne sais pas si c'est vraiment par économie ou parce qu'il était bien plus compliqué de disposer un grand nombre de pixels sur une si grande surface. Il est fort probable que ce soit les deux à la fois.

Je me souviens que lors du passage du 4M au 5M, les capteurs des bridges/compacts étaient de même dimension et pourtant c'est plus chère de disposer plus de pixels par points ! D'ailleurs, certains s'en sont mordu les doigts parce que disposer plus de pixels sur une même surface est plus compliqué à faire : l'Olympus de l'époque (le C-5050 si ma mémoire est bonne) présentait, entre autre, des aberrations chromatiques et aussi des pixels morts. Néanmoins, pour un meilleur rendu de la photo, vaut mieux un capteur plus grand avec l'augmentation des pixels (bref, bien équilibrer les deux) et ceci, à la même époque, Nikon l'avait bien compris parce qu'il fut le premier à présenter des appareils doté d'un capteur de dimension adaptée au 5M.

pour le prix d’une optique on a deux focales différentes (un facteur 1.5 entre l’APS-C et le 35mm)

Oui et non, enfin bon, c'est un abus de langage. une focale de 35mm sur un APS-C ou sur un full-frame restera toujours une focale de 35mm : la focale est fixée par les optiques de l'objectif, pas par le capteur du boîtier. La différence est le cadrage : le cadrage d'un 35mm sur un APS-C est équivalent à peu chose près à celui d'un 50mm sur un full-frame (d'où le rapport de 1.4 à 1.6 entre les deux selon les boîtiers) : on cadre plus serré avec un même objectif monté sur un APS-C.

Néanmoins, effectivement, il est plus sympa de disposer de cailloux pour full-frame sur des APS-C … que l'inverse.

Tres grand innovation technique de Wayland d'ailleur :-D Non, franchement, c'est juste pour avoir raison que tu dis une telle generalite ou tu avais une vrai idee derriere la tete ?

De nos jours, on rencontre encore bon nombre de projets au code spaghetti correctement structuré, voir strucuté tout court ; ce n'est pas parce que tu utilises un langage modulaire, à classes, fonctionnel, … que le code est nécessairement (bien) structuré, il te le facilite, c'est tout. Et ce n'est pas la panacée des projets privatifs, on en rencontre aussi dans les projets Open Source aussi : je prend l'exemple de l'implémentation des portlets de java.net (Open Portal), une grosse bouze ce truc que j'ai du me tapper !

Donc, quand je dis que le code sera structuré, c'est en ayant ça à l'esprit : c'est déjà pas mal parce que même si le resultat soit monolithique, le fait que le code le soit (s'il est correctement c'est encore mieux), c'est déjà un grand pas pour son évolution. Alors, bien sûr, on est loin là de l'esprit d'Unix.

Avec le temps, avec l'évolution des machines, nos techniques de programmation ont évolué vers une meilleur modularité et ceci se reporte aussi sur les architectures logicielles. Malgré tout, la modularité effective du code ou de l'architecture dépend grandement des développeurs.

Comme apparemment beaucoup de monde, tu confonds principes et architectures avec implémentation.
J'ai écris modularité avec communication inter-module. Je n'ai pas parlé de processus et de pipe ou autre IPC qui a été l'implémentation d'Unix a son époque et qui a évolué avec le temps. Et à son époque, Unix était l'un des rares systèmes dans lequel l'espace utilisateur (et non le noyau comme beaucoup semble croire ici) reposait sur ces principes qui sont en vigueur de nos jours.

Donc oui aujourd'hui de très nombreux outils libres sont construits sur ce modèle avec leur propre implémentation de la modularité et de la communication inter-module.

Quant aux technologies dédiés au WEB, il y a à boire et à manger comme dans tout environnement de dév et d'exécution distribué. Et là on peut en discuter à l'infini …

Non, l'architecture de Wayland ne permet absolument pas de separer le tout. C'est juste impossible

Ben si justement. Quand tu regardes l'architecture de Wayland, tu peux justement séparer les différentes briques : Window Manager, Display Manager, Composite Manager, Events Manager, etc. (Bon en fait je ne vois pas trop l'intérêt de séparer le Display Manager et le Composite Manager et ne suis même pas sûr que c'est faisable dans Wayland). En fait, la pièce centrale est le Composite Manager et le protocole définie dans Wayland est pour justement la communication avec le compositeur ; tout le reste peut être réalisé sous forme de clients Wayland.

Toutes les implementations sures, efficaces et fonctionnelle de Wayland seront monolytique.

Oui probablement. C'est pourquoi, malgré son architecture qui permet le découplage l'implémentation qui sera faite, au-dessus de Wayland, sera monolithique ; seul le code sera structuré.

Amusant que tu ne reconnaisse pas ça, toi qui semble défendre les principes d'Unix.

Non, j'aurais écris tout simplement : "tu oublis ça".
Effectivement, mais il ne faut pas oublier qu'à l'origine, Weston était là pour valider le concept. Après maintenant …
L'architecture de wayland permet de séparer le tout et avec Weston on a un code de référence de l'implémentation d'un composite manager.

Sinon, pour avoir un bousin qui respecte les principes Unix, il aurait fallu avoir une archi semblable mappée sur le système de fichier qui aurait alors servi peut être de moyen de communication entre les différents agents graphiques. (Mais de nos jours, on préfère apparemment s'éloigner le plus du système de fichiers).