Sinon Akonadi plus PostgreSQL intégré à tendance pas trop marcher. Il me semble que Host: n'est pas réglé comme il faut.. à creuser.
Aussi, avec Akonadi, quand $HOME est dans un truc assez long, genre /usr/local/pouet/bidule/user/ et que le hostname est trop grand, la socket de la DB (pgsql ou mysql) dépasse les 107 char, et ça pète. Utiliser /var/run/${USER} à la place pourrais être cool.
L'avantage de frameworks comme Django, c'est qu'ils abstraient un grand nombre de ces soucis, et la pluspart du temps ça juste-marche. Perso, je n'ai eu des problèmes que lorsque j'ai voulu utiliser les types spatiaux avec GeoDjango, saptialite et postgis.
Il y'a même des classes Qt pour écrire son compositeur tout en Qt ! le gros bonus c'est que du coups le compositeur peut ensuite tourner sous X si besoin.
Pourquoi "Non !" ? Oui, si t'a une méthode accélérée et zero copy, c'est mieux, mais il se trouve que toutes les cartes ne sont pas supportées pour l'instant, et donc la mémoire partagée au moins ça marche toujours, surtout si en plus tu fais le rendu en software avec uniquement le CPU :).
Les "client side decoration" font en effet partit du plan, mais c'est censé être uniformisé/standardisé par les toolkits, reste à voir ce que ça va donner.
Non pas du tout. Le protocole wayland est utilisé en (2) et (3), le compositeur est en fait un "serveur wayland". (1) et (4) sont les API Linux/Unix "normales". Ce qu'il manque par contre ici c'est l'API utilisée pour partager les buffers entre client et compositeur (OpenGL, shared memory, ou autre...)
Bah, tu peux avoir un compositeur qui ne supporte que les tampons en mémoire partagée et qui tourne lui même sous X. Donc non, rien de strictement obligatoire. Par contre oui, KMS c'est l'idéal.
C'est le kernel qui fait tout, et t'as pas un driver Xorg qui essaye de tout contrôler lui aussi (y compris l'input). Bon c'était déjà mieux avec kms, mais là c'est encore plus radical.
Très difficile de répondre sachant que wayland n'est clairement pas finit et ça dépendra de toute façon beaucoup des compositeurs, wayland n'étant que le protocole de communication. Mais l'architecture devrait permettre de meilleures performances, un démarrage plus rapide, reste à voir ce que ça va donner.
Histoire de pas tout casser, une couche de compatibilité X11/Wayland devrait être disponible: xwayland.
xwayland c'est en gros un X11 un peu modifié (style XVfb) qui se comporte comme un client wayland plutôt que faire le rendu lui même. Ce qui est cool c'est que xwayland peut utiliser des pilotes accélérés (intel) ou un pilote "software" (wlshm).
PS: ça fait 6 mois que j'ai pas touché au code de wlshm, c'est fortement possible que ça ne compile plus, mais ça devrait pas être impossible à réparer.
Je viens d'y penser, il est possible qu'il veulent faire des versions android et iOS se basant sur la version HTML5, ce qui paraîtrait plus fesable/logique, si on part du principe que LibreOffice HTML5 fonctionne.
Ils parlent aussi de version Android et iOS. Bha honnêtement bonne chance !
Ils auraient beaucoup moins de mal à prendre Koffice qui doit déjà plus ou moins tourner dessus avec (avec le fork de Qt pour android, ou la 4.8 qui a un suport officiel/caché d'iOS).
Concernant l'article en question, il raconte comme si tout était déjà finit, mais a mon avis des types ont lancé l'idée sans plus creuser (qui à la limite se finira avec un plugin qui installe libreoffice sur le poste :D).
Après, je suis peut être seulement mauvaise langue... :)
Observium peut surveiller quelques services (http, ssh etc..) et envoyer des alertes dans certains cas (température, host down ou reboot, etc...). C'est assez limité, mais ça reste bien utile.
Il y'a ausi observium (http://observium.org) qui est bien sympa. Bon niveau alertes c'est pas vraiment fait pour, mais ça permet de jeter un coups d'oeil rapide à l'état de ses machines.
Observium utilise principalement snmp pour récupérer l'état des machines et sa grande force est de ne nécessiter aucune configuration autre que "comment se connecter à la machine x en snmp".
Si quelqu'un ici s'en achète un, est que ça serait possible de me faire un retour sur l'état de fonctionement de eeepc-wmi sur cette machine ? (une autre solution est de faire une donation de 200€ au projet acpi4asus ! :D)
C'est surtout que de leur côté, ils veulent des application "qui vont bien" pour MeeGo, donc forcément c'est ce qu'ils poussent.
Mais du côté du développeur, si il fait une appplication "qui va bien" pour MeeGo, il ne sera absolument pas bloqué sur cette plateforme si il choisis Qt[/QML].
D'ailleurs, pour ce Hackaton, c'est MeeGo et win32, donc ça peut être l'occaz de faire en plus une application pour les deux ;).
Bah ça dépend, pour MeeGo netbook c'est juste une question de repacking, et c'est déjà une bonne première étape. Après quand je dit "portable" ça veut dire que c'est "fesable" sans tout réécrire, parce que oui, forcément, en fonction de la machine concernée, ça demandera plus ou moins de modifications.
Mais par exemple, j'ai une appli que j'ai créé pour Maemo, puis pour la quelle j'ai fait une UI adaptée au desktop, et bah en fonction du périphérique j'ai plus qu'a choisir l'UI qui correspond, plus quelques adapations spécifiques, et c'est bon.
Concernant iOS, je n'utilise le port que pour faire marcher tout ce qui n'est pas UI, parce que je préfère utiliser CocoaTouch directement. Ca m'a quand même évité de recoder une grande partie de l'appli.
Concernant Android, j'ai eu quelques problèmes avec QtMobility et j'ai eu la flemme d'avancer plus loin vu que de toute façon je n'ai pas de machine sous android.
Enfin tout ça pour dire que de toute façon, il faudra adapter l'experience utilisateur en fonction de la machine, quelque soit le toolkit, mais c'est déjà une très bonne étape d'avoir du code facilement portable.
Pour exemple, j'ai deux "UX" dans Lugdulo'V, et ça me permet d'avoir un truc convenable pour: Win32, OS-X, X11 desktop, Maemo, Symbian, MeeGo Netbook, MeeGo Tablet, c'est déjà pas mal non ? :p
Un téléphonne c'est une chose, mais y'a aussi un certain nombre de tablettes / netbook qui ont été annoncés au computex.
Et puis de toute façon, MeeGo reste une distribution Linux assez "normale". Donc faire une appli Qt/QML pour MeeGo n'empêche pas de la rendre disponible pour d'autre platformes. Surtout que les ports iOS et Android de Qt sont en bonne voie (le support iOS est présent dans la 4.8 ! même si pas forcément finit).
# Si t'as du temps, j'en ai des idées pour KDE !
Posté par Corentin Chary (site web personnel) . En réponse au journal Pourquoi je n’arrive pas à contribuer au logiciel libre.. Évalué à 9.
https://bugs.kde.org/show_bug.cgi?id=288179
https://bugs.kde.org/show_bug.cgi?id=295982
Sinon Akonadi plus PostgreSQL intégré à tendance pas trop marcher. Il me semble que Host: n'est pas réglé comme il faut.. à creuser.
Aussi, avec Akonadi, quand $HOME est dans un truc assez long, genre /usr/local/pouet/bidule/user/ et que le hostname est trop grand, la socket de la DB (pgsql ou mysql) dépasse les 107 char, et ça pète. Utiliser /var/run/${USER} à la place pourrais être cool.
Hop, au boulot !
[^] # Re: Problème de compilation
Posté par Corentin Chary (site web personnel) . En réponse à la dépêche dfc 3.0.0 : nouvelle version majeure pour cette alternative haute en couleurs à l'utilitaire df(1). Évalué à 3.
Trouvée, rajoutée dans l'arbre gentoo officiel :).
[^] # Re: Problème de compilation
Posté par Corentin Chary (site web personnel) . En réponse à la dépêche dfc 3.0.0 : nouvelle version majeure pour cette alternative haute en couleurs à l'utilitaire df(1). Évalué à 2.
Elle est où l'ebuild de la 3.0.0 ? Que je mette ça dans gentoo-x86 (avec les metadata.xml si possible) :).
# Django !
Posté par Corentin Chary (site web personnel) . En réponse au journal MySQL est une bouse immonde. Évalué à 3.
L'avantage de frameworks comme Django, c'est qu'ils abstraient un grand nombre de ces soucis, et la pluspart du temps ça juste-marche. Perso, je n'ai eu des problèmes que lorsque j'ai voulu utiliser les types spatiaux avec GeoDjango, saptialite et postgis.
[^] # Re: Gestionnaire de fenêtres
Posté par Corentin Chary (site web personnel) . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 5.
Il y'a même des classes Qt pour écrire son compositeur tout en Qt ! le gros bonus c'est que du coups le compositeur peut ensuite tourner sous X si besoin.
[^] # Re: Vous pouvez m'éclairer ?
Posté par Corentin Chary (site web personnel) . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 3.
Pourquoi "Non !" ? Oui, si t'a une méthode accélérée et zero copy, c'est mieux, mais il se trouve que toutes les cartes ne sont pas supportées pour l'instant, et donc la mémoire partagée au moins ça marche toujours, surtout si en plus tu fais le rendu en software avec uniquement le CPU :).
[^] # Re: Fenêtre
Posté par Corentin Chary (site web personnel) . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 7.
Les "client side decoration" font en effet partit du plan, mais c'est censé être uniformisé/standardisé par les toolkits, reste à voir ce que ça va donner.
[^] # Re: Vous pouvez m'éclairer ?
Posté par Corentin Chary (site web personnel) . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 3.
Non pas du tout. Le protocole wayland est utilisé en (2) et (3), le compositeur est en fait un "serveur wayland". (1) et (4) sont les API Linux/Unix "normales". Ce qu'il manque par contre ici c'est l'API utilisée pour partager les buffers entre client et compositeur (OpenGL, shared memory, ou autre...)
[^] # Re: Pour une transition douce depuis wayland
Posté par Corentin Chary (site web personnel) . En réponse à la dépêche Quatre actualités concernant la pile graphique de Linux. Évalué à 2.
Bah, tu peux avoir un compositeur qui ne supporte que les tampons en mémoire partagée et qui tourne lui même sous X. Donc non, rien de strictement obligatoire. Par contre oui, KMS c'est l'idéal.
[^] # Re: Pour une transition douce depuis wayland
Posté par Corentin Chary (site web personnel) . En réponse à la dépêche Quatre actualités concernant la pile graphique de Linux. Évalué à 3.
C'est le kernel qui fait tout, et t'as pas un driver Xorg qui essaye de tout contrôler lui aussi (y compris l'input). Bon c'était déjà mieux avec kms, mais là c'est encore plus radical.
[^] # Re: Pour une transition douce depuis wayland
Posté par Corentin Chary (site web personnel) . En réponse à la dépêche Quatre actualités concernant la pile graphique de Linux. Évalué à 3.
Très difficile de répondre sachant que wayland n'est clairement pas finit et ça dépendra de toute façon beaucoup des compositeurs, wayland n'étant que le protocole de communication. Mais l'architecture devrait permettre de meilleures performances, un démarrage plus rapide, reste à voir ce que ça va donner.
# Pour une transition douce depuis wayland
Posté par Corentin Chary (site web personnel) . En réponse à la dépêche Quatre actualités concernant la pile graphique de Linux. Évalué à 10.
Histoire de pas tout casser, une couche de compatibilité X11/Wayland devrait être disponible: xwayland.
xwayland c'est en gros un X11 un peu modifié (style XVfb) qui se comporte comme un client wayland plutôt que faire le rendu lui même. Ce qui est cool c'est que xwayland peut utiliser des pilotes accélérés (intel) ou un pilote "software" (wlshm).
Plus d'infos sur:
- http://cgit.freedesktop.org/~krh/xserver/log/?h=xwayland-1.10
- http://cgit.freedesktop.org/~iksaif/xf86-video-wlshm/
- http://xf.iksaif.net/dev/wayland/xwayland-flash.png (Xorg + compositeur wayland en qt + xwayland + firefox + flash)
- http://xf.iksaif.net/dev/wayland/xwayland-xeyes.png (xwayland + dwm + xterm + xeyes)
- http://xf.iksaif.net/dev/wayland/xhosted-mdi-3.png (Xorg + compositeur wayland en qt + client natif wayland + xterm avec xwayland)
PS: ça fait 6 mois que j'ai pas touché au code de wlshm, c'est fortement possible que ça ne compile plus, mais ça devrait pas être impossible à réparer.
[^] # Re: toolbox
Posté par Corentin Chary (site web personnel) . En réponse à la dépêche Sony : Ma propriété intellectuelle vaut plus que la vôtre. Évalué à 4.
Parce que les outils BSD sont à la trainne (partiellement justement parce qu'il sont pas sou GPL ?) :p
[^] # Re: SSL ?
Posté par Corentin Chary (site web personnel) . En réponse au journal Epitech: de la passion à l'expertise. Évalué à 3.
Identification
[^] # Re: Ah, ce bon viel intra !
Posté par Corentin Chary (site web personnel) . En réponse au journal Epitech: de la passion à l'expertise. Évalué à 1.
Honnêtement, entre les mauvaix de l'INSA et les mauvaix d'Epitech...
[^] # Re: Android et iOS
Posté par Corentin Chary (site web personnel) . En réponse au journal GTK/HTML5 & LibreOffice dans le Cloud. Évalué à 0.
Je viens d'y penser, il est possible qu'il veulent faire des versions android et iOS se basant sur la version HTML5, ce qui paraîtrait plus fesable/logique, si on part du principe que LibreOffice HTML5 fonctionne.
# Android et iOS
Posté par Corentin Chary (site web personnel) . En réponse au journal GTK/HTML5 & LibreOffice dans le Cloud. Évalué à 1.
Ils parlent aussi de version Android et iOS. Bha honnêtement bonne chance !
Ils auraient beaucoup moins de mal à prendre Koffice qui doit déjà plus ou moins tourner dessus avec (avec le fork de Qt pour android, ou la 4.8 qui a un suport officiel/caché d'iOS).
Concernant l'article en question, il raconte comme si tout était déjà finit, mais a mon avis des types ont lancé l'idée sans plus creuser (qui à la limite se finira avec un plugin qui installe libreoffice sur le poste :D).
Après, je suis peut être seulement mauvaise langue... :)
# msysgit
Posté par Corentin Chary (site web personnel) . En réponse au journal Survivre en milieu hostile. Évalué à 1.
Perso, j'installe msysgit: ça fournit un shell et tout les outils qui vont avec, y compris vi, ssh et git !
[^] # Re: Observium
Posté par Corentin Chary (site web personnel) . En réponse à la dépêche Quelques brèves sur la supervision. Évalué à 5.
Observium peut surveiller quelques services (http, ssh etc..) et envoyer des alertes dans certains cas (température, host down ou reboot, etc...). C'est assez limité, mais ça reste bien utile.
# Observium
Posté par Corentin Chary (site web personnel) . En réponse à la dépêche Quelques brèves sur la supervision. Évalué à 7.
Il y'a ausi observium (http://observium.org) qui est bien sympa. Bon niveau alertes c'est pas vraiment fait pour, mais ça permet de jeter un coups d'oeil rapide à l'état de ses machines.
Observium utilise principalement snmp pour récupérer l'état des machines et sa grande force est de ne nécessiter aucune configuration autre que "comment se connecter à la machine x en snmp".
# acpi4asus
Posté par Corentin Chary (site web personnel) . En réponse au journal asus et linux. Évalué à 7.
Si quelqu'un ici s'en achète un, est que ça serait possible de me faire un retour sur l'état de fonctionement de eeepc-wmi sur cette machine ? (une autre solution est de faire une donation de 200€ au projet acpi4asus ! :D)
[^] # Re: N900
Posté par Corentin Chary (site web personnel) . En réponse au journal Le N9 ou comment flinguer son produit phare. Évalué à 1.
Non, le N900 sera trop lent à mon avis. Tu peux toujours essayer de choper un N950 sur ebay :).
[^] # Re: Arnaque
Posté par Corentin Chary (site web personnel) . En réponse à la dépêche Intel Music Hackathon, les 18 et 19 juin. Évalué à 2.
C'est surtout que de leur côté, ils veulent des application "qui vont bien" pour MeeGo, donc forcément c'est ce qu'ils poussent.
Mais du côté du développeur, si il fait une appplication "qui va bien" pour MeeGo, il ne sera absolument pas bloqué sur cette plateforme si il choisis Qt[/QML].
D'ailleurs, pour ce Hackaton, c'est MeeGo et win32, donc ça peut être l'occaz de faire en plus une application pour les deux ;).
[^] # Re: Arnaque
Posté par Corentin Chary (site web personnel) . En réponse à la dépêche Intel Music Hackathon, les 18 et 19 juin. Évalué à 3.
Bah ça dépend, pour MeeGo netbook c'est juste une question de repacking, et c'est déjà une bonne première étape. Après quand je dit "portable" ça veut dire que c'est "fesable" sans tout réécrire, parce que oui, forcément, en fonction de la machine concernée, ça demandera plus ou moins de modifications.
Mais par exemple, j'ai une appli que j'ai créé pour Maemo, puis pour la quelle j'ai fait une UI adaptée au desktop, et bah en fonction du périphérique j'ai plus qu'a choisir l'UI qui correspond, plus quelques adapations spécifiques, et c'est bon.
Concernant iOS, je n'utilise le port que pour faire marcher tout ce qui n'est pas UI, parce que je préfère utiliser CocoaTouch directement. Ca m'a quand même évité de recoder une grande partie de l'appli.
Concernant Android, j'ai eu quelques problèmes avec QtMobility et j'ai eu la flemme d'avancer plus loin vu que de toute façon je n'ai pas de machine sous android.
Enfin tout ça pour dire que de toute façon, il faudra adapter l'experience utilisateur en fonction de la machine, quelque soit le toolkit, mais c'est déjà une très bonne étape d'avoir du code facilement portable.
Pour exemple, j'ai deux "UX" dans Lugdulo'V, et ça me permet d'avoir un truc convenable pour: Win32, OS-X, X11 desktop, Maemo, Symbian, MeeGo Netbook, MeeGo Tablet, c'est déjà pas mal non ? :p
[^] # Re: Arnaque
Posté par Corentin Chary (site web personnel) . En réponse à la dépêche Intel Music Hackathon, les 18 et 19 juin. Évalué à 4.
Un téléphonne c'est une chose, mais y'a aussi un certain nombre de tablettes / netbook qui ont été annoncés au computex.
Et puis de toute façon, MeeGo reste une distribution Linux assez "normale". Donc faire une appli Qt/QML pour MeeGo n'empêche pas de la rendre disponible pour d'autre platformes. Surtout que les ports iOS et Android de Qt sont en bonne voie (le support iOS est présent dans la 4.8 ! même si pas forcément finit).