Oui je comprends. C'est juste que j'aime bien les pipe ( no joke here). Une question d'habitude j'imagine ( goto no joke here).
Mais dans le cas présent effectivement le logiciel se voulant complet doit intégrer la couche sécurité en interne. Le but étant de proposer à l'utilisateur une solution simple à utiliser se limitant quasiment à "clic-droit partager ce dossier avec ce groupe".
Enfin "bash script" -> websocketd -> stunnel c'est quand même résoudre tellement, tellement de problèmes en seulement deux pipes…
Les netcateux adeptes du nc|ossplay me comprendront ;-D
Oui oui, on sait : c'est toujours lui qui a la plus grosse… heu… technique… ;-D
Je retiens l'idée d'être aussi efficace en proxy qu'en reverse. Pour les websockets c'est à tester. Mais vu que je les fais généralement passer dans un stunnel ça ne devrait pas poser trop de problèmes.
L'autre avantage de Nginx c'est qu'il a un module de proxy mail. Quelque chose d'assez rare qu'on ne trouve que sur Perdition il me semble.
le tunning pour avoir des perfs correctes étant un peu pointu
Pas vraiment. Le tout est de respecter le concept clé/valeurs dans la modélisation de la base. Le reste est une histoire de views - guère plus complexe qu'une requête SQL 92…
L'intérêt de passer par une base orienté document hors la performance est de ne pas réimplémenter du code déjà écrit et testé à grande échelle. En particulier le versionning.
Je préfère PouchDB à CouchDB parce qu'il implémente le GQL - XPath/Xquery étant selon moi les grands responsables de l'échec des BDD XML…
Sinon Pod part vraiment sur de bonnes bases. Je vais le suivre de près. Je rejoins les comms plus haut sur le module LDAP : indispensable pour un passage à l'échelle.
L'esprit du REST est d'être en mode non connecté si je me souviens bien de la thèse de Roy Fielding. C'est même l'un des principes de base. Pas de contexte, une demande, une reponse.
Pour moi la supervision suppose exactement tout l'inverse : mode connecté, temps réel, push du serveur vers la console de supervision, etc… - tout cela correspond à ce que les websockets apportent. Pas le REST.
Donc je persiste et signe : autant une API REST n'a pas vraiment de sens, autant l'utilisation de Websocket en a.
Je me demande d'ailleurs s'il est possible de basculer Glances en websocket. Je crois me souvenir que j'ai eu des problèmes avec les affichages multilignes :-/
Je ne sais pas ce qu'en pense l'auteur mais ça me semble plus utile de faire du websocket qu'une "API Rest" qui ne me paraît pas vraiment correspondre au besoin.
Dans le même esprit j'ai tendance à préférer web-vmstats.
1) c'est du web socket donc moins de bande passante consommée par l'overhead http
2) Pas d'actualisation de page nécessaire ( c'est du web socket, on vient de le dire :-D )
3) Pas de nécessité d'installer/sécuriser un serveur web ou d'utiliser celui de php5.
Certes les informations sont plus basiques, mais je trouve que les pour sont supérieurs aux contre. En particulier le point 3…
C'est pire pour un non habitué qu'un message du type "l'application nécessite la librairie libprout5.99.1123.34424234.a qui n'est pas compatible avec 3 autres applications. Garder la libprout5.99.1123.34424234.a, passer en libprout6.4234.3242342alphatango ou garder les deux (déconseillé)".
Sachant que la libprout en question fait 42 ko…
Le binaire on va forcément y venir. C'est juste une question de temps…
En plus on a un bel exemple du pourquoi les librairies dynamiques ne peuvent être la solution à partir d'un certain niveau de complexité : WINXPSPS sous Vista ça vous dit quelque chose ? Le dossier qui grossit grossit GROSSIT sans jamais s'arrêter de GROSSIR :-(
Et bien c'est sans doute une question de point de vue. Et ma vision de cette distinction remonte sans doute à l'époque de l'interface GEM pour Amstrad PC 1512. Mais oui, je considère que le gestionnaire d'alimentation est une application, alors que je place le WM a un niveau inférieur.
Si un WM est défaillant, je perds la possibilité de lancer des applications ( fenêtre ne s'ouvre pas), c'est la classique "croix noire sur écran vide" des systèmes X. Je dois passer en mode console et redémarrer l'ordi, sauf si j'ai envie de m'entraîner à l'utilisation de la ligne de commande. Si le gestionnaire d'alimentation est défaillant je vais avoir le ventilo qui va se déclencher et ma batterie va se vider. Mais mon PC restera utilisable. Idem pour le wifi, le screen locker, et le gestionnaire de session graphique.
Alors oui, je considère qu'un Environnement de Bureau est un gestionnaire de fenêtres+un menu accompagné d'applications, même si certaines sont essentielles pour contrôler les composants de mon PC : gestionnaire de volume, d'alimentation, d'interface réseau etc…
Un DE ce n'est jamais rien d'autre un qu'un WM avec quelques applications en plus. Par exemple un gestionnaire de fichiers et une barre des tâches.
C'est juste que l'aspect graphique du bureau entre LXQT et ICEWM est terriblement proche. Un fonctionnement "à la windows" avec menu démarrer. Ce qui n'est pas le cas de tous les WM *box avec leur menu clic-droit. C'était surtout l'ergonomie identique que je voulais souligner.
Sinon pour ceux qui ne souhaitent pas de QT il y a toujours Icewm.
Je serais curieux d'avoir l'empreinte mémoire des deux d'ailleurs. Vu que l'aspect général du bureau (hors applis rajoutées) est assez strictement le même.
Oui, avec un système proche du TS-O-Matic que j'avais traduit vite fait en fr. Mals on ne peut pas descendre jusqu'à l'inclusion ou l'exclusion de modules dans le noyau il me semble, contrairement à Thinstation.
Globalement il y a plein de bonnes idées dans Slitaz, la première étant d'être fr, mais comme je le disais plus haut c'est entre Thinstation et Tiny Core Linux tout en visant Lxbuntu. Et finalement parce qu'elle est un peu au carrefour de tout on ne la choisit pas spontanément pour réaliser un projet.
Tiens, amusant j'ai appris la sortie de cette version de SliTaz sur les forums de Tiny Core Linux hier. Quelqu'un souhaitait une comparaison des deux distribution. Et comme le lui ont répondu les devs - qui sont les anciens de "Damn Small Linux" - la philosophie des deux distributions n'est pas la même.
SliTaz impose une bonne majorité des outils (desktop, gestionnaire de fichiers, etc…). Même si l'on peut en changer par la suite. Elle est loin d'être aussi modulaire que Tiny Core Linux où l'on part de rien et on choisit réellement un par un ses éléments.
Bref pour moi elle a rejoint Thinstation au paradis des distributions qui sont de bonnes idées à la base mais qui ont pris une mauvaise direction, ou plutôt n'ont pas pris de direction suffisamment radicale pour se démarquer des distributions généralistes.
Ceci dit elle a été ma première distribution linux "pro". Que des bons souvenirs avec les i-bays et le serveur d'accès distant facile à mettre en oeuvre. Si on compare au Windows SBS de l'époque (1998), son serveur Exchange catastrophique, son ASP et son IIS abominablement lents c'était le jour et la nuit.
# un 9mm
Posté par Loïc Ibanez . En réponse au sondage mon dispositif de pointage habituel est…. Évalué à 5.
Mais c'est un peu lourd.
[^] # Re: Alternatives
Posté par Loïc Ibanez . En réponse à la dépêche Facette, outil de visualisation de séries numériques. Évalué à 0.
Je suis d'accord. Il me semble également que c'est la bonne direction.
[^] # Re: Alternatives
Posté par Loïc Ibanez . En réponse à la dépêche Facette, outil de visualisation de séries numériques. Évalué à 1. Dernière modification le 30 juillet 2014 à 09:06.
Stunnel est ma réponse. Je n'aime pas les logiciels qui implémentent LEUR solution de sécurité qui sera forcément incomplète.
# Troll ?
Posté par Loïc Ibanez . En réponse à la dépêche Facette, outil de visualisation de séries numériques. Évalué à 10.
C'est pas gentil de se moquer de Java…
# Tails 3 = QubeOS
Posté par Loïc Ibanez . En réponse à la dépêche Tails 1.1 est disponible. Évalué à 1.
Lorsque je vois la roadmap de Tails 3 je me dis que ce n'est guère nouveau comme idée : https://wiki.qubes-os.org/wiki
C'est sûr que réalisé avec Docker ce sera certainement plus performant et moins gourmand en ressources machine, mais le principe reste le même
# Du moment que le résultat est disponible dans un websocket...
Posté par Loïc Ibanez . En réponse au sondage Quel langage utilisez-vous sur vos serveurs pour vos applications web ?. Évalué à 0.
… le serveur peut bien avoir des algos programmés en assembleur, ce n'est pas mon problème ;-p
[^] # Re: Merci
Posté par Loïc Ibanez . En réponse à la dépêche Rakoshare, un outil de synchronisation de dossiers pour tout le monde. Évalué à 1.
Oui je comprends. C'est juste que j'aime bien les pipe ( no joke here). Une question d'habitude j'imagine ( goto no joke here).
Mais dans le cas présent effectivement le logiciel se voulant complet doit intégrer la couche sécurité en interne. Le but étant de proposer à l'utilisateur une solution simple à utiliser se limitant quasiment à "clic-droit partager ce dossier avec ce groupe".
Enfin "bash script" -> websocketd -> stunnel c'est quand même résoudre tellement, tellement de problèmes en seulement deux pipes…
Les netcateux adeptes du nc|ossplay me comprendront ;-D
[^] # Re: Ouvert, libre et contribution
Posté par Loïc Ibanez . En réponse à la dépêche Proxy HTTP(s) gatejs. Évalué à 2.
Oui oui, on sait : c'est toujours lui qui a la plus grosse… heu… technique… ;-D
Je retiens l'idée d'être aussi efficace en proxy qu'en reverse. Pour les websockets c'est à tester. Mais vu que je les fais généralement passer dans un stunnel ça ne devrait pas poser trop de problèmes.
L'autre avantage de Nginx c'est qu'il a un module de proxy mail. Quelque chose d'assez rare qu'on ne trouve que sur Perdition il me semble.
# Toujours aussi impressionnant
Posté par Loïc Ibanez . En réponse à la dépêche G'MIC 1.5.9.3 : Poisson Blending, Seamcarving, OpenMP, et autres joyeusetés !. Évalué à 4.
A chaque nouvel article sur G'MIC on en prend plein la vue.
Quel travail formidable - et effectivement côté math ça doit piquer les yeux :-)
[^] # Re: Merci
Posté par Loïc Ibanez . En réponse à la dépêche Rakoshare, un outil de synchronisation de dossiers pour tout le monde. Évalué à 1.
Sinon pour faire plus simple stunnel ne conviendrait-il pas ?
[^] # Re: Implémenter un modèle de données générique donc personnalisable.
Posté par Loïc Ibanez . En réponse à la dépêche pod : un outil de travail collaboratif pour suivre et gérer tâches, documents et autres. Évalué à 2.
Pas vraiment. Le tout est de respecter le concept clé/valeurs dans la modélisation de la base. Le reste est une histoire de views - guère plus complexe qu'une requête SQL 92…
L'intérêt de passer par une base orienté document hors la performance est de ne pas réimplémenter du code déjà écrit et testé à grande échelle. En particulier le versionning.
Je préfère PouchDB à CouchDB parce qu'il implémente le GQL - XPath/Xquery étant selon moi les grands responsables de l'échec des BDD XML…
Sinon Pod part vraiment sur de bonnes bases. Je vais le suivre de près. Je rejoins les comms plus haut sur le module LDAP : indispensable pour un passage à l'échelle.
Bon courage ! Continuez !
[^] # Re: web-vmstats
Posté par Loïc Ibanez . En réponse à la dépêche eZ Server Monitor : un tableau de bord simple et léger en deux versions. Évalué à 2.
Les websockets n'aiment pas vraiment les reverse proxys / proxys. Ca se règle par configuration. Il y a plein de doc sur le net.
[^] # Re: Pas CLI
Posté par Loïc Ibanez . En réponse à la dépêche Sortie de Glances version 2.0. Évalué à 1.
L'esprit du REST est d'être en mode non connecté si je me souviens bien de la thèse de Roy Fielding. C'est même l'un des principes de base. Pas de contexte, une demande, une reponse.
Pour moi la supervision suppose exactement tout l'inverse : mode connecté, temps réel, push du serveur vers la console de supervision, etc… - tout cela correspond à ce que les websockets apportent. Pas le REST.
Donc je persiste et signe : autant une API REST n'a pas vraiment de sens, autant l'utilisation de Websocket en a.
[^] # Re: Pas CLI
Posté par Loïc Ibanez . En réponse à la dépêche Sortie de Glances version 2.0. Évalué à 1.
Justement, pour ce qui est de l'interface web j'aurais préféré une solution websocket du type : https://github.com/joewalnes/websocketd
Je me demande d'ailleurs s'il est possible de basculer Glances en websocket. Je crois me souvenir que j'ai eu des problèmes avec les affichages multilignes :-/
Je ne sais pas ce qu'en pense l'auteur mais ça me semble plus utile de faire du websocket qu'une "API Rest" qui ne me paraît pas vraiment correspondre au besoin.
# web-vmstats
Posté par Loïc Ibanez . En réponse à la dépêche eZ Server Monitor : un tableau de bord simple et léger en deux versions. Évalué à 2.
Dans le même esprit j'ai tendance à préférer web-vmstats.
1) c'est du web socket donc moins de bande passante consommée par l'overhead http
2) Pas d'actualisation de page nécessaire ( c'est du web socket, on vient de le dire :-D )
3) Pas de nécessité d'installer/sécuriser un serveur web ou d'utiliser celui de php5.
Certes les informations sont plus basiques, mais je trouve que les pour sont supérieurs aux contre. En particulier le point 3…
[^] # Re: Bravo pour ansible et docker
Posté par Loïc Ibanez . En réponse à la dépêche Newebe fait peau neuve et passe en version 0.7 !. Évalué à 1. Dernière modification le 11 juin 2014 à 10:04.
C'est pire pour un non habitué qu'un message du type "l'application nécessite la librairie libprout5.99.1123.34424234.a qui n'est pas compatible avec 3 autres applications. Garder la libprout5.99.1123.34424234.a, passer en libprout6.4234.3242342alphatango ou garder les deux (déconseillé)".
Sachant que la libprout en question fait 42 ko…
Le binaire on va forcément y venir. C'est juste une question de temps…
En plus on a un bel exemple du pourquoi les librairies dynamiques ne peuvent être la solution à partir d'un certain niveau de complexité : WINXPSPS sous Vista ça vous dit quelque chose ? Le dossier qui grossit grossit GROSSIT sans jamais s'arrêter de GROSSIR :-(
[^] # Re: A propos du hardware
Posté par Loïc Ibanez . En réponse à la dépêche Neo900 UG reprend le projet Neo900. Évalué à 6.
Ben oui, à Taïwan :-)
[^] # Re: Icewm ?
Posté par Loïc Ibanez . En réponse à la dépêche Du nouveau du côté de LXQt. Évalué à -1.
Et bien c'est sans doute une question de point de vue. Et ma vision de cette distinction remonte sans doute à l'époque de l'interface GEM pour Amstrad PC 1512. Mais oui, je considère que le gestionnaire d'alimentation est une application, alors que je place le WM a un niveau inférieur.
Si un WM est défaillant, je perds la possibilité de lancer des applications ( fenêtre ne s'ouvre pas), c'est la classique "croix noire sur écran vide" des systèmes X. Je dois passer en mode console et redémarrer l'ordi, sauf si j'ai envie de m'entraîner à l'utilisation de la ligne de commande. Si le gestionnaire d'alimentation est défaillant je vais avoir le ventilo qui va se déclencher et ma batterie va se vider. Mais mon PC restera utilisable. Idem pour le wifi, le screen locker, et le gestionnaire de session graphique.
Alors oui, je considère qu'un Environnement de Bureau est un gestionnaire de fenêtres+un menu accompagné d'applications, même si certaines sont essentielles pour contrôler les composants de mon PC : gestionnaire de volume, d'alimentation, d'interface réseau etc…
[^] # Re: Icewm ?
Posté par Loïc Ibanez . En réponse à la dépêche Du nouveau du côté de LXQt. Évalué à -8.
Un DE ce n'est jamais rien d'autre un qu'un WM avec quelques applications en plus. Par exemple un gestionnaire de fichiers et une barre des tâches.
C'est juste que l'aspect graphique du bureau entre LXQT et ICEWM est terriblement proche. Un fonctionnement "à la windows" avec menu démarrer. Ce qui n'est pas le cas de tous les WM *box avec leur menu clic-droit. C'était surtout l'ergonomie identique que je voulais souligner.
# Icewm ?
Posté par Loïc Ibanez . En réponse à la dépêche Du nouveau du côté de LXQt. Évalué à -1.
Sinon pour ceux qui ne souhaitent pas de QT il y a toujours Icewm.
Je serais curieux d'avoir l'empreinte mémoire des deux d'ailleurs. Vu que l'aspect général du bureau (hors applis rajoutées) est assez strictement le même.
[^] # Re: Tiny Core Linux / SliTaz
Posté par Loïc Ibanez . En réponse à la dépêche SliTaz GNU/Linux 5.0 RC1. Évalué à 1.
Oui, avec un système proche du TS-O-Matic que j'avais traduit vite fait en fr. Mals on ne peut pas descendre jusqu'à l'inclusion ou l'exclusion de modules dans le noyau il me semble, contrairement à Thinstation.
Globalement il y a plein de bonnes idées dans Slitaz, la première étant d'être fr, mais comme je le disais plus haut c'est entre Thinstation et Tiny Core Linux tout en visant Lxbuntu. Et finalement parce qu'elle est un peu au carrefour de tout on ne la choisit pas spontanément pour réaliser un projet.
# Tiny Core Linux / SliTaz
Posté par Loïc Ibanez . En réponse à la dépêche SliTaz GNU/Linux 5.0 RC1. Évalué à 2.
Tiens, amusant j'ai appris la sortie de cette version de SliTaz sur les forums de Tiny Core Linux hier. Quelqu'un souhaitait une comparaison des deux distribution. Et comme le lui ont répondu les devs - qui sont les anciens de "Damn Small Linux" - la philosophie des deux distributions n'est pas la même.
SliTaz impose une bonne majorité des outils (desktop, gestionnaire de fichiers, etc…). Même si l'on peut en changer par la suite. Elle est loin d'être aussi modulaire que Tiny Core Linux où l'on part de rien et on choisit réellement un par un ses éléments.
Bref pour moi elle a rejoint Thinstation au paradis des distributions qui sont de bonnes idées à la base mais qui ont pris une mauvaise direction, ou plutôt n'ont pas pris de direction suffisamment radicale pour se démarquer des distributions généralistes.
# Avisynth... je t'aime.
Posté par Loïc Ibanez . En réponse à la dépêche GStreamer 1.x mûrit et Pitivi 1.0 bêta déboule. Évalué à 1.
Quand je pense que le montage vidéo avec avisynth se résume à :
film1 = avisource "film1.avi"
film2 = avisource "film2.avi"
return (film1+film2)
Et que je lis le tutoriel Pitivi ( très bien fait du reste ) je me demande où est le progrès…
[^] # Re: Étymologie
Posté par Loïc Ibanez . En réponse à la dépêche Première version de NOALYSS. Évalué à 3.
Il faudrait demander à Alice ^
# e-smith-server-and-gateway reborn
Posté par Loïc Ibanez . En réponse à la dépêche Sortie de Zentyal Server 3.4. Évalué à 1.
Jusque dans le logo je vois la similitude ;-D
Ceci dit elle a été ma première distribution linux "pro". Que des bons souvenirs avec les i-bays et le serveur d'accès distant facile à mettre en oeuvre. Si on compare au Windows SBS de l'époque (1998), son serveur Exchange catastrophique, son ASP et son IIS abominablement lents c'était le jour et la nuit.
Bon courage.