Aldoo a écrit 2794 commentaires

Je ne connais pas ces téléphones personnellement !
Sinon, blague à part, il est clair qu'il devient difficile de placer la frontière entre un téléphone classique, un smart phone, un PDA, un baladeur ou un PMP...

Pas sur le p990i, mais sur SE en général : je trouve que ce sont de bons téléphones.
- grande autonomie
- design sympa (je possède le W880i, et je trouve qu'il en jette !)
- interface sympa et réactive (même si proprio)
- utilisation des standards de communication (POP, IMAP, SMTP, tous les classiques autour de Bluetooth et USB : hid, pan, dun, sco, obex, SyncML, irmc, UMS, ...), et de fichiers (pas les formats libres ogg/vorbis/theora/... malheureusement).

Sur ce dernier point, il est vrai que les smartphones (et c'est ce qu'aurel recherche, apparemment) tendent de toute manière à respecter de plus en plus les standards, mais je ne crois pas que ce soit le cas de la plupart des téléphones (en particulier "idiots", non "smart").
Donc SE est un très bon choix pour les téléphones "idiots" moyenne et haute gammes (je pense aux Walkman et Cybershot en particulier).

En fait ça marche comme convention dans un petit groupe de personnes.
Effectivement, si ça devient une norme, retour à la case départ.

Mandriva le fait déjà depuis 1848.

Or l'auteur du journal ne cherche ni à utiliser, ni à contredire ces thèses, ce qui montre que une totale ignorance de ces textes, pourtant fondamentaux en la matière. Bref amateurisme complet.

Nous pourrons en reparler quand tu auras lu et cogité au moins un minimum ce corpus. En attendant, ce que tu n'as pas écrit n'est qu'un ramassis de foutaises !

Il faut aller jusqu'au bout :

Les meshsmaillages multirésolutions avec UV (kézako, NdR ?) et vertexarêtes colorées pouvaient planter dans certains cas.

Voilà, quitte à franciser !

L'obfuscation de code, ce n'est pas tellement dans l'esprit du libre non plus !

PS : mea culpa pour l'anglicisme

Bon, c'est répandu dans mon microcosme, on va dire.
Quand on fait de la logique temporelle, il y a un opérateur "eventually", qu'on traduit presque toujours par "éventuellement"... Il s'agit de paresse intellectuelle, bien sûr, puisqu'on sait que tout le monde, dans ce microcosme, comprend ce qu'on a voulu dire.

Ensuite, en dehors du jargon spécialisé, dans l'état actuel du français, il est clair que ça créerait de fâcheuses confusions !

Évidemment, le lecteur attentif aura lu "à terme", et non "éventuellement" !

(Bon, on la fait toute celle-là... au point qu'on ne peut plus tellement l'appeller une erreur de traduction, mais plutôt un nouvel anglicisme ! C'est particulièrement vrai quand on travaille dans le domaine de la vérif de programmes, d'ailleurs... )

La synchro avec kontact, ce n'est pas dans la poche !
Voir mon récent journal à ce sujet : http://linuxfr.org/~Aldoo/25323.html

La situation c'est qu'à peu près tous les téléphones aujourd'hui parlent le SyncML, mais que les logiciels permettant de synchroniser kontact via SyncML sont un peu dans les choux (enfin d'après mon expérience perso) : mal intégrés, configuration difficile, et peut-être tout simplement SyncML pas complètement implémenté (ce que suggéreraient certains messages sur la mailing list d'Opensync, du moins pour SyncML 1.2).

La synchro avec Google Calendar, avec un intermédiaire comme par exemple un serveur funambol (par ex: scheduleworld.com), ça apparemment ça marche sans trop de problèmes si ton téléphone se connecte à internet, avec un petit coup de SyncML over http.
Reste à interfacer un tel serveur avec kontact... théoriquement possible via webdav, mais le webdav est balbutiant sous kontact. Peut-être un jour possible avec un client SyncML over http, en tant que plugin pour opensync (qui pour l'instant fait client SyncML over obex, et serveur over http). Cela si ce que je dis a un sens, mais il me semble que oui, car il existe un client funambol pour se synchroniser avec outlook par exemple.

Bon nickel sous konqui 3.5.7 chez moi, alors que ça déconnait au boulot en 3.5.5.

En fait, je n'ai pas le texte de la page.
J'ai la zone de titre et le menu, ainsi que le pied de page, mais il manque l'essentiel.

NB : Je n'ai rien contre Firefox.

Tu es sûr que lesswatts.org est un site pour linuxiens ?
Enfin, je dis ça, je dis rien, mais sous konqueror, j'ai du mal...
Or puisqu'il s'agit d'économiser de précieux wattheures, je ne vais évidemment pas lancer Firefox !

Et est-ce que le problème ne viendrait pas aussi du nombre de fichiers à ouvrir ?
Les fichiers de démarrage n'étant pas a priori dans des secteurs contigus du disque dur, j'imagine que chaque ouverture provoque un accès physique au disque. Imaginons 2000 fichiers à 10ms de temps d'accès, ça fait déjà 20 secondes ! Bon ensuite, 2000, c'est peut-être exagéré ;-). N'empêche que ça correspond à peu près à la différence entre un boot sur disque dur magnétique et un boot sur mémoire flash.

Une solution à cela serait de forcer les fichiers à être écrits physiquement dans des secteurs contigus, mais ce n'est toujours pas optimal (ça dépend trop de l'implémentation du FS et des pilotes du disque !).

Une autre solution serait de copier tous les fichiers dans un fichier de cache (contigu dans le FS, autant que possible), qui serait chargé inconditionnellement en RAM à chaque boot en premier lieu.
Ce cache serait mis à jour plus tard pendant la session, dès qu'on a un peu de temps, par exemple en contrôlant les access time des fichiers potentiellement concernés, et tant qu'à faire en les rangeant dans l'ordre.
Une mise en ½uvre pas trop difficile serait de monter ce cache en tant que /etc ou /truc (avec un système qui irait chercher dans le vrai FS en cas de défaut de cache).
On pourrait encore optimiser en lançant le chargement du cache en parallèle de l'exécution du démarrage, en donnant la priorité aux accès demandés explicitement par l'init (dans les rares cas où le fichier n'a pas déjà été chargé : en effet, le cache est ordonné !).
Résultat : utilisation optimale du disque dur pendant le démarrage.

Est-ce que des solution similaires auraient déjà été mises en ½uvre dans d'autres OS ? Est-ce cela qui se passe sous MacOSX ? Est-ce que je réinvente la roue parce que les FS actuels réorganisent déjà les fichiers de telle sorte que ça passe bien ?

Bon, évidemment tout ce que je dis là est peut-être un peu naïf, car je ne suis pas un gourou de la programmation système. Donc n'hésitez pas à critiquer.

Machine dédiée : chez moi c'est non (aberration écologique), au boulot, ben ahem, évidemment on ne va pas me laisser ouvrir des ports vers l'extérieur comme ça juste pour le plaisir ! (et non, pas de tunnel SSH : ça ne marchera pas avec mon tél !)
Et puis ça ne synchronise toujours pas avec kdepim cette histoire (mais théoriquement ça devrait... ).

Est-ce si important que ce soit en cached IMAP ?

Pour le côté PC portable pas toujours connecté, ok, je veux bien.
Côté boulot, à quoi bon encombrer son compte avec un cache IMAP gigantesque, alors que le serveur est toujours accessible ?

Apparemment kmail n'a pas les mêmes bugs selon la méthode, mais je croyais que le cached IMAP posait plus de problèmes que le simple IMAP. Serait-ce le contraire ?

Mais alors, finalement, qu'utilises-tu ?
En gros tu as tout essayé, comme moi, et rien ne te satisfait au final ?
Ou bien la solution sur IMAP te suffit ?

M'enfin au fond, OSEF, non ?
Au final on aura bien rigolé, et on n'aura rien perdu, non ?

Oui, le coût de la pub se répercute sur le produit que nous, les consommateurs, acheterons au final. Mais ce type de marketing viral est bien moins coûteux justement que les spots, affiches et encarts publicitaires classiques.

Je ne vois pas qui se fait avoir dans l'affaire, si ce n'est les grandes villes qui ne figureront pas sur le plateau ;-).

Clairement, KDE est à fond dans la philosophie UNIX : de petits composants faisant une seule chose mais bien, qu'on peut facilement faire fonctionner en collaboration les uns avec les autres.

Ici, la technologie kparts joue le rôle du pipe.


--
Doushete korosu te ? Sore wa hidoi yo !

Yep, on peut aussi faire ça avec fish (ssh) ou tout autre protocole géré par KIO, or ça tombe bien vu que j'ai un accès ssh vers mon PC du boulot (ftp, je ne crois pas).

Il faut aussi, je pense, faire la distinction entre ressource partagée (tout le monde accède à la même, c'est ce que tu proposes) et ressources synchronisées (chacun sa copie, mais on fusionne les mises à jour régulièrement).

Personnellement, je préfèrerais la deuxième solution, car elle me permet de travailler sans être connecté (par exemple dans le train, où je ne souhaite pas exploser mon forfait téléphonique... et où de toute manière, ce n'est pas gagné pour avoir un réseau stable).

Qui plus est, mon téléphone ne sait pas se synchroniser via ftp ou ssh, mais seulement via SyncML (sur http ou obex) ou irmc (et éventuellement par google via un logiciel tiers qui bogue encore pas mal).

C'est juste, j'avais oublié d'en parler !
Cela dit, en mode cached IMAP, ça bogue un maximum (ça veut toujours recréer les dossiers de groupware alors qu'ils existent déjà... ).
De plus, ça ne va pas m'aider à synchroniser mon téléphone (qui gère IMAP, mais pas ses extensions groupware) !

Ça y est, c'est fait ! (Montcuq au sommet !)

Bref, seulement 10 pékins, c'est bien ce qui me semblait !

Ah je croyais que c'était des bronsonwares !

Quelque chose qui pourrait être fait aussi, c'est un sondage dans la rue. Si un LUG voulait organiser cela, en réfléchissant à des questions annexes pour redresser l'échantillon.
Bon évidemment, les geeks des LUGs n'aiment pas sortir dans la rue, c'est un peu le problème. Pourtant la rue est intéropérable et libre !