Niveau client caldav/carddav, il y a le choix. Avec SOGo, j'utilise, avec succès les clients suivant :
- Thunderbird + lightning (+connecteur SOGo) : CalDAV et CardDAV
- Evolution : CalDAV et CardDAV
- le "truc" de KDE 4 avec Kontact & co : CalDAV et CardDAV
- Mac OS X iCal et Address Book : CalDAV et CardDAV
- iOS Agenda et Contacts : CalDAV et CardDAV
- Android, CalDAV-Sync et CardDAV-Sync : CalDAV et CardDAV
Tout ça fonctionne bien à très bien avec SOGo donc j'imagine que si l'implémentation de OwnCloud est correct, ça le fait. Pour info, le moins bon est Evolution car il faut rentrer tous les agendas et carnets d'adresses à la main (par de detection auto des inscriptions).
Je ne connais pas encore les spécificités de SPDY, mais HTTPS n'impose pas une IP par site. TLS permet de contourner ça sans soucis. Il faut juste avoir un couple OpenSSL/Apache pas trop vieux (ex: les versions dans RHEL6).
Par contre, faut savoir à quel public on s'adresse. Tous les couples systèmes/navigateurs ne sont pas compatible. Firefox c'est OK depuis longtemps, pour IE il faut un Windows Vista ou plus récent, Safari c'est OK depuis Mac OS 10.6 et Chrome c'est OK. En gros, il n'y a que pour les vieux systèmes qu'il peut encore y avoir des problèmes.
N'hésite pas a appeler ton hébergeur/fournisseur télécom préféré, il pourra t'assister ;-)
L'IPv6 fonctionne plutôt bien et il y a un pare-feu. Bon, c'est basique, mais ça marche. Il y a une case à cocher : Bloquer le trafic IPv6 entrant non sollicité
HTML5, c'est le nouveau buzzword. Aujourd'hui, si on met un bout d'AJAX/Javascript et de CSS3, on dit que c'est HTML5.
J'avoue que j'ai pas regardé en détail le site, mais à première vue je ne vois rien qui requiert HTML5. Tout ce qu'il y a sur ce site pourrait être fait en HTML4/XHTML1. Surtout que la vidéo est en Flash !
Je pense surtout que c'est "over-bloated" de CSS et de Javascript et d'images bien lourde (4.5Mo la page !), et que ton navigateur n'arrive pas à suivre. En passant, chez moi ça le fait bien (Safari 5.1, qui n'est pourtant pas le navigateur le plus véloce...)
Tout d'abord, les fichiers SPECS sont parfois erronés ou incomplets. Probablement que ça compile chez RedHat parce que leurs procédures de compilation (scripts ou autre) fonctionnent malgré ces défauts.
Ensuite, les fichiers SPECS définissent les dépendances. Ils ne définissent pas l'environnement de compilation. Sur la mailing list de CentOS [1], l'exemple de kdbg est donné. D'après ce qu'on voit, les environnements de compilation de RHEL et de SL étaient différents : RHEL avait la libfam alors que SL ne l'avais pas. Si le ./configure inclus la libfam quand il la trouve, on en arrive à ce résultat.
Voilà le genre de détails auxquels CentOS fait très attention. C'est plus long, mais le résultat est normalement garanti 100% compatible avec RHEL.
Quand j'écrivais "l'équipe de CentOS envisage une sortie rapide de la 6.2", je n'imaginais pas que ça serai aussi rapide ! http://qaweb.dev.centos.org/qa/node/120
Visiblement, sous réserve de validation par la QA, dans quelques jours ça sera installable via le dépôt CR...
En gros, ScientificLinux n'est qu'une "simple recompilation" des sources de RHEL (sans vouloir dévaloriser le travail des équipes de SL). C'est plus rapide mais ça ne garantie pas une totale compatibilité binaire avec RHEL. Il y a eu des précédents où les dépendances d'un paquet de SL n'étaient pas les mêmes que le paquet de RHEL.
Au contraire, CentOS garantie ça et doit parfois faire le travail de corriger la chaine de compilation.
Si tu cherche un peu, tu verra que pendant l'attente de CentOS 6, ça a trollé un max sur le sujet.
Effectivement, ScientificLinux n'ayant pas les contraintes de CentOS, les sorties étaient plus rapide.
CentOS sort la version 6.1 dans les prochains jours (ils sont en train de pousser sur les miroirs). Avec les tests automatisés qui ont été introduit ces derniers temps, l'équipe de CentOS envisage une sortie rapide de la 6.2.
Posté par ondex2 .
En réponse au journal Qui veut entrer au MI6 ?.
Évalué à 2.
Dernière modification le 01 décembre 2011 à 18:20.
Dans les méta données PNG, il y a le commentaire :
xQkJCQjIAAACR2PFtcCA6q2eaC8SR+8dmD/zNzLQC+td3tFQ4qx8O447TDeuZw5P+0SsbEcYR
78jKLw==
Je sais pas ce que vous en pensez, mais ça me parait louche. Passé à la moulinette base64, ça donne pas grand chose. C'est peut être une clé, mais alors il faut trouver l'algorithme, et j'ai la flemme de chercher plus.
Bon courage.
EDIT: (whoua !) Ou c'est la donnée et le contenu affiché de l'image est la clé...
Faudrait définir de quoi on parle précisément car jusqu'aux récents noyaux, la situation était un peu floue... Je serait tenté de dire "noyau patché supporté".
C'était un 2.6.32 empaqueté par Debian. J'ai un peu galéré pour identifier le problème et trouver le bon patch. Mais depuis, Debian a rétro-porté le patch et le problème est résolu (bien qu'un soucis similaire me soit arrivé une fois depuis, mais les circonstances étaient vraiment particulières).
Ben moi j'aimerai bien un Linux plus stable. J'administre une plateforme d'hébergement sur laquelle on a beaucoup de Linux (Debian et CentOS). Sans dire que ça se vautre tout le temps, plusieurs fois par an on a des kernel panic. Le dernier en date : un méchant bug dans le noyau faisait que l'utilisation conjointe de Xen et iSCSI/multipath donnait un kernel panic. C'est balot...
Avis strictement personnel :
Sans remettre en cause la (grande) qualité du travail des "équipes" Debian, leur découpage en paquet, c'est quand même un peu de la pignole. C'est, selon moi, le syndrome Debian : vouloir faire des trucs techniquement au top, et au final c'est tellement compliqué que c'en est difficilement utilisable (Preseed vs Kickstart ; créer un paquet Deb vs RPM, ...)
Ils ont fait intégrer "upstream" une partie de leur travail dans Thunderbird et Lightning. Donc, ils auront plus de facilité à suivre les nouvelles versions.
Je suis curieux de connaitre des projets faisant cela. Au dessus de HTTP, ça me parait compliqué.
Sauf à passer par un logiciel ou une extension de navigateur (typiquement les logiciels de téléchargement). Mais on sort un peu du cadre généraliste/grand public.
Je cite l'article d'origine :
> Son interface est gérée avec GTK. Cet outil permet de gérer un affichage déporté en HTML 5 avec une optimisation des transits réseaux. La
> version SaaS de LibreOffice a pu être développée grâce à cette fonctionnalité récente de GTK.
Mais bon, j'ai peut être tord de faire confiance...
:-O Très fort, c'est assez impressionnant. J'ai hâte de tester ça.
Est ce qu'il y a des informations sur les prérequis réseau. Parce que sur 127.0.0.1, c'est assez facile, mais sur un vrai LAN ? Et une vraie liaison Internet (genre mon ADSL à 768Kb/s en upload) ?
[^] # Re: oudClown, une solution qu’elle est bien pour mon nuage
Posté par ondex2 . En réponse à la dépêche ownCloud 4 est sorti. Évalué à 5.
Niveau client caldav/carddav, il y a le choix. Avec SOGo, j'utilise, avec succès les clients suivant :
- Thunderbird + lightning (+connecteur SOGo) : CalDAV et CardDAV
- Evolution : CalDAV et CardDAV
- le "truc" de KDE 4 avec Kontact & co : CalDAV et CardDAV
- Mac OS X iCal et Address Book : CalDAV et CardDAV
- iOS Agenda et Contacts : CalDAV et CardDAV
- Android, CalDAV-Sync et CardDAV-Sync : CalDAV et CardDAV
Tout ça fonctionne bien à très bien avec SOGo donc j'imagine que si l'implémentation de OwnCloud est correct, ça le fait. Pour info, le moins bon est Evolution car il faut rentrer tous les agendas et carnets d'adresses à la main (par de detection auto des inscriptions).
[^] # Re: Multi-utilisateur
Posté par ondex2 . En réponse à la dépêche Nginx 1.2, des progrès sur le code et les parts de marché. Évalué à 1.
Apache + mpm_itk : http://mpm-itk.sesse.net/
(le site est en panne pour le moment)
[^] # Re: SPDY
Posté par ondex2 . En réponse à la dépêche Nginx 1.2, des progrès sur le code et les parts de marché. Évalué à 2.
Je ne connais pas encore les spécificités de SPDY, mais HTTPS n'impose pas une IP par site. TLS permet de contourner ça sans soucis. Il faut juste avoir un couple OpenSSL/Apache pas trop vieux (ex: les versions dans RHEL6).
Par contre, faut savoir à quel public on s'adresse. Tous les couples systèmes/navigateurs ne sont pas compatible. Firefox c'est OK depuis longtemps, pour IE il faut un Windows Vista ou plus récent, Safari c'est OK depuis Mac OS 10.6 et Chrome c'est OK. En gros, il n'y a que pour les vieux systèmes qu'il peut encore y avoir des problèmes.
N'hésite pas a appeler ton hébergeur/fournisseur télécom préféré, il pourra t'assister ;-)
# Anonymous builds its own Pastebin-like site
Posté par ondex2 . En réponse à la dépêche ZeroBin, un pastebin sécurisé. Évalué à 1.
Les Anonymous utilise ZeroBin : http://arstechnica.com/open-source/news/2012/04/anonymous-builds-its-own-pastebin-like-site.ars
[^] # Re: IPV6, intérêts et conséquences pour le grand public
Posté par ondex2 . En réponse à la dépêche Activation mondiale de l'IPv6 (World IPv6 Launch). Évalué à 3.
Ben, SFR avec une Neufbox 4.
L'IPv6 fonctionne plutôt bien et il y a un pare-feu. Bon, c'est basique, mais ça marche. Il y a une case à cocher : Bloquer le trafic IPv6 entrant non sollicité
Coché, t'es protégé. Décoché, t'es à oil-pé.
[^] # Re: petit exercice d'anglais
Posté par ondex2 . En réponse au journal Iptable et les listes noires. Évalué à 1.
L'anglais n'est pas mon point fort, mais je dirais ça :
How much does it cost ?
[^] # Re: Gallery
Posté par ondex2 . En réponse au journal Des galeries photo ... (et vidéo) ... (et avec des tags). Évalué à 2.
Yaka demander :
https://github.com/rledisez/gallery3-contrib/tree/master/3.0/modules/downloadalbum
http://codex.gallery2.org/Gallery3:Modules:downloadalbum
http://gallery.menalto.com/node/96880
De rien, ça me fait plaisir !
# HTML5, le nouveau buzzword
Posté par ondex2 . En réponse au journal Benchmark HTML5. Évalué à 10.
HTML5, c'est le nouveau buzzword. Aujourd'hui, si on met un bout d'AJAX/Javascript et de CSS3, on dit que c'est HTML5.
J'avoue que j'ai pas regardé en détail le site, mais à première vue je ne vois rien qui requiert HTML5. Tout ce qu'il y a sur ce site pourrait être fait en HTML4/XHTML1. Surtout que la vidéo est en Flash !
Je pense surtout que c'est "over-bloated" de CSS et de Javascript et d'images bien lourde (4.5Mo la page !), et que ton navigateur n'arrive pas à suivre. En passant, chez moi ça le fait bien (Safari 5.1, qui n'est pourtant pas le navigateur le plus véloce...)
[^] # Re: Liste de bugs corrigés o_O
Posté par ondex2 . En réponse à la dépêche Sortie de CentOS 6.1. Évalué à 2.
Hum...
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/6.1_Technical_Notes/
[^] # Re: Utilisation desktop?
Posté par ondex2 . En réponse à la dépêche Red Hat Enterprise Linux 6.2 : virtualisation, performances et anniversaire !. Évalué à 2. Dernière modification le 10 décembre 2011 à 22:54.
C'est un peu plus compliqué que ça.
Tout d'abord, les fichiers SPECS sont parfois erronés ou incomplets. Probablement que ça compile chez RedHat parce que leurs procédures de compilation (scripts ou autre) fonctionnent malgré ces défauts.
Ensuite, les fichiers SPECS définissent les dépendances. Ils ne définissent pas l'environnement de compilation. Sur la mailing list de CentOS [1], l'exemple de kdbg est donné. D'après ce qu'on voit, les environnements de compilation de RHEL et de SL étaient différents : RHEL avait la libfam alors que SL ne l'avais pas. Si le ./configure inclus la libfam quand il la trouve, on en arrive à ce résultat.
Voilà le genre de détails auxquels CentOS fait très attention. C'est plus long, mais le résultat est normalement garanti 100% compatible avec RHEL.
[1] http://lists.centos.org/pipermail/centos/2011-March/108389.html
[^] # Re: Utilisation desktop?
Posté par ondex2 . En réponse à la dépêche Red Hat Enterprise Linux 6.2 : virtualisation, performances et anniversaire !. Évalué à 1.
Quand j'écrivais "l'équipe de CentOS envisage une sortie rapide de la 6.2", je n'imaginais pas que ça serai aussi rapide !
http://qaweb.dev.centos.org/qa/node/120
Visiblement, sous réserve de validation par la QA, dans quelques jours ça sera installable via le dépôt CR...
[^] # Re: Utilisation desktop?
Posté par ondex2 . En réponse à la dépêche Red Hat Enterprise Linux 6.2 : virtualisation, performances et anniversaire !. Évalué à 4.
En gros, ScientificLinux n'est qu'une "simple recompilation" des sources de RHEL (sans vouloir dévaloriser le travail des équipes de SL). C'est plus rapide mais ça ne garantie pas une totale compatibilité binaire avec RHEL. Il y a eu des précédents où les dépendances d'un paquet de SL n'étaient pas les mêmes que le paquet de RHEL.
Au contraire, CentOS garantie ça et doit parfois faire le travail de corriger la chaine de compilation.
Si tu cherche un peu, tu verra que pendant l'attente de CentOS 6, ça a trollé un max sur le sujet.
[^] # Re: Utilisation desktop?
Posté par ondex2 . En réponse à la dépêche Red Hat Enterprise Linux 6.2 : virtualisation, performances et anniversaire !. Évalué à 4.
Effectivement, ScientificLinux n'ayant pas les contraintes de CentOS, les sorties étaient plus rapide.
CentOS sort la version 6.1 dans les prochains jours (ils sont en train de pousser sur les miroirs). Avec les tests automatisés qui ont été introduit ces derniers temps, l'équipe de CentOS envisage une sortie rapide de la 6.2.
[^] # Re: Syndrome de la compatibilité ascendante
Posté par ondex2 . En réponse au journal Que faut-il penser de Lennart qui casse tout ?. Évalué à 5.
# cat /proc/net/route# Ils voudraient pas nous lâcher...
Posté par ondex2 . En réponse au journal Les représentants du cinéma et de la télé se plaignent encore.. Évalué à 3.
Franchement, qu'est ce qu'on peut faire de plus que ça :
http://www.allocine.fr/article/fichearticle_gen_carticle=18604246.html
Ca semble être pareil pour la musique :
http://www.chartsinfrance.net/actualite/news-74164.html
# En commentaire
Posté par ondex2 . En réponse au journal Qui veut entrer au MI6 ?. Évalué à 2. Dernière modification le 01 décembre 2011 à 18:20.
Dans les méta données PNG, il y a le commentaire :
xQkJCQjIAAACR2PFtcCA6q2eaC8SR+8dmD/zNzLQC+td3tFQ4qx8O447TDeuZw5P+0SsbEcYR
78jKLw==
Je sais pas ce que vous en pensez, mais ça me parait louche. Passé à la moulinette base64, ça donne pas grand chose. C'est peut être une clé, mais alors il faut trouver l'algorithme, et j'ai la flemme de chercher plus.
Bon courage.
EDIT: (whoua !) Ou c'est la donnée et le contenu affiché de l'image est la clé...
[^] # Re: Fiabilité
Posté par ondex2 . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 2.
Faudrait définir de quoi on parle précisément car jusqu'aux récents noyaux, la situation était un peu floue... Je serait tenté de dire "noyau patché supporté".
C'était un 2.6.32 empaqueté par Debian. J'ai un peu galéré pour identifier le problème et trouver le bon patch. Mais depuis, Debian a rétro-porté le patch et le problème est résolu (bien qu'un soucis similaire me soit arrivé une fois depuis, mais les circonstances étaient vraiment particulières).
Pour plus d'info : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613634
# ...
Posté par ondex2 . En réponse au journal Grid bootstrapé. Évalué à 10.
Grid
machine virtuelle
serveur HTTP virtuel décentralisé
auto hébergement
S3
=> BINGO !
(désolé...)
[^] # Re: Fiabilité
Posté par ondex2 . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 4.
Ben moi j'aimerai bien un Linux plus stable. J'administre une plateforme d'hébergement sur laquelle on a beaucoup de Linux (Debian et CentOS). Sans dire que ça se vautre tout le temps, plusieurs fois par an on a des kernel panic. Le dernier en date : un méchant bug dans le noyau faisait que l'utilisation conjointe de Xen et iSCSI/multipath donnait un kernel panic. C'est balot...
[^] # Re: Pas assez bien
Posté par ondex2 . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 4.
N'oublie pas ".*doc", ".*common et ".*bin".
Avis strictement personnel :
Sans remettre en cause la (grande) qualité du travail des "équipes" Debian, leur découpage en paquet, c'est quand même un peu de la pignole. C'est, selon moi, le syndrome Debian : vouloir faire des trucs techniquement au top, et au final c'est tellement compliqué que c'en est difficilement utilisable (Preseed vs Kickstart ; créer un paquet Deb vs RPM, ...)
[^] # Re: CalDAV-Sync beta
Posté par ondex2 . En réponse au journal Comment remplacer son minitel 2.0 ?. Évalué à 2.
Pour Thunderbird 8 il y aura un connecteur.
Ils ont fait intégrer "upstream" une partie de leur travail dans Thunderbird et Lightning. Donc, ils auront plus de facilité à suivre les nouvelles versions.
[^] # Re: Question.
Posté par ondex2 . En réponse à la dépêche ownCloud 2 dans les bacs. Évalué à 1.
Je suis curieux de connaitre des projets faisant cela. Au dessus de HTTP, ça me parait compliqué.
Sauf à passer par un logiciel ou une extension de navigateur (typiquement les logiciels de téléchargement). Mais on sort un peu du cadre généraliste/grand public.
[^] # Re: A mon avis non
Posté par ondex2 . En réponse au journal GTK/HTML5 & LibreOffice dans le Cloud. Évalué à 6.
Je cite l'article d'origine :
> Son interface est gérée avec GTK. Cet outil permet de gérer un affichage déporté en HTML 5 avec une optimisation des transits réseaux. La
> version SaaS de LibreOffice a pu être développée grâce à cette fonctionnalité récente de GTK.
Mais bon, j'ai peut être tord de faire confiance...
[^] # Re: oulalalala
Posté par ondex2 . En réponse au journal Les freins techniques au dialogue entre amis. Évalué à 9.
Visiblement, ça ne concerne pas tout le monde...
[^] # Re: La révolution GTK
Posté par ondex2 . En réponse à la dépêche GNOME 3.2 : finitions et enrichissement. Évalué à 2.
:-O Très fort, c'est assez impressionnant. J'ai hâte de tester ça.
Est ce qu'il y a des informations sur les prérequis réseau. Parce que sur 127.0.0.1, c'est assez facile, mais sur un vrai LAN ? Et une vraie liaison Internet (genre mon ADSL à 768Kb/s en upload) ?