wismerhill a écrit 2608 commentaires

J'avais aussi ce problème sur un portable (gel avant même que le noyau n'aie démarré), mais après avoir réinstallé une 2010.0 (parce que j'avais besoin du portable) puis retesté une mise à jour vers un snapshot plus récent de cooker ça ne le fait plus.
Tout ça pour dire que les développeurs ne se tournent pas les pouces en attendant le feu vert de la direction pour le release.

En tout cas pour maemo c'est un serveur X (pas Xorg bien sur, une alternative beaucoup plus légère)

C'est un peu tard pour ton cas, mais quand on fait à distance des opérations un peu risquées et qui peuvent durer il faut toujours le faire dans un screen.
Comme ça pas de risque que l'opération (critique dans ton cas) soit interrompue par une perte de réseau, on peut soi-même se déconnecter pour laisser tourner le truc sur le serveur ou ouvrir d'autres terminaux en parallèle (dans le même screen ou dans d'autres) pour surveiller l'état du système.

Dans ton cas, puisque tu es connecté en ssh, tu peux au moins ouvrir une nouvelle connection ssh pour surveiler la charge du système (en particulier les IO) pour voir s'il avance.

Cette carte OGD1 est une carte de développement, c'est pour ça qu'ils utilisent des FPGA.
Dans deux ou trois ans (ou peut-être plus tôt, on peut rêver!) quand le schéma sera bien développé, raisonnablement optimisé et suffisamment déboggué, ils se lanceront dans la production de puces en plus grand nombre. Donc moins cher et plus performant.
L'utilisation de FPGA n'est qu'une étape, et n'est clairement pas destinée à des utilisateurs normaux, ni même des geeks (c'est pour ça qu'ils n'en ont produit que 25).

par exemple avec okular et son UI de merde

Tiens, moi je la trouve correcte l'UI d'okular.
Bon, je ne lui demande pas grand chose de plus que de m'afficher mes documents, éventuellement en plein écran, et de passer d'une page à l'autre.
Bon, y a bien un truc qui m'ennuie, c'est que si je ferme lr programme en mode plein écran, à l'ouverture suivante il s'affiche sans menu ni barre d'outils, donc faut penser à quitter le mode plein écran avant de quitter sinon faut réactiver la barre de menu et la barre d'outil au démarrage suivant.

C'est peut-être le nouveau nom, mais du coup ils en ont profité pour gommer toute référence à d'autres DBMS.
Dommage car il semble vraiment bien.

Le problème c'est qu'il nous est déjà arrivé plus d'une fois de changer le DBMS de destination en cours de projet, donc utiliser des outils différents suivant le DBMS n'est même pas une bonne solution car ça supposera malgré tout de refaire tout le schéma (sauf si on a des logiciels différents avec un format d'échange commun).

On aurait plutôt besoin d'un outil multi-DBMS, sinon il va falloir changer de programme suivant le DBMS de destination, et si on change d'avis en cours de route (c'est déjà arrivé) on est bon pour refaire le schéma car je doute qu'il existe un format d'échange pour ce type de données.

Bah, laisse tomber, il est juste là pour dénigrer. S'il avait envie de faire avancer le débat il aurait proposé des exemples concrets de choses à améliorer.
C'est du troll de base.

Oui, enfin, moyennement utilisable.
Sur mon N810 il y a quand même plusieurs fenêtre de dialogues (configuration de graphique par exemple) qui sont à peu près inutilisables parce que la moitié des composants sortent de la zone d'affichage ou se chevauchent.

Je vais quand même le récupérer pour voir ce que ça vaut.

Bon, j'ai eu un peu de mal à trouver les libs qui lui manquaient, mais à coup de ldd j'ai fini par trouver et ça se lance.
L'interface en qt2 fait assez vieille mais ça fonctionne, je présenterai à mes collègues pour voir ce qu'ils en pensent.

Dommage que ce soit développé avec un langage obsolète, je vais voir si lazarus arrive à le compiler.

C'est intéressant, mais on aurait besoin d'un outil vraiment orienté édition de base de données, qui sache quels sont les types supportés par le DBMS choisi, comment créer les index...

Pour le moment j'utilise le plugin clay pour eclipse, qui n'était déjà pas libre mais avait une version gratuite (ce qui n'est plus le cas: http://www.azzurri.jp/ ), mais come dit au début certains collègues ne veulent plus utiliser eclipse.

Je vais quand même tester ta proposition (parce qu'avec dia on pourra au moins faire des belles mises en page), mais je doute que mes collègues apprécient la solution.

je n'ai effectivement pas beaucoup cherché, il était déjà tard et j'avais besoin de dormir.
De plus, le site de dbdesigner4 disait explicitement que son successeur est mysql workbench (cf http://www.fabforce.net/downloads.php ), donc je n'ai effectivement pas cherché plus dans cette direction.

Quant au fork, effectivement la 1.4 est dispo pour linux, mais elle date de 2007 et la 1.5 n'est disponible que pour windows, c'est mauvais signe :-(
Je vais quand même le récupérer pour voir ce que ça vaut.

et puis sur une machine x86-64 tu peux tres bien faire tourner des programmes 32bits

Je sais bien qu'on peut faire tourner du x86 sur un système x86_64, je le fais déjà, mais si on peut s'en passer ça évite de charger plein de bibliothèques en double.

Ah, ça a l'air plus intéressant, il ne parlent pas de postgresql, mais je vais tester ça.

Argh, c'est mal parti.
Il n'y a pas de version x86_64, et comme c'est du delphi je ne vais pas pouvoir le recompiler moi-même, en plus le paquet a des dépendances vers des vieilles libs, je vais devoir retrouver des vieux rpm de libexpat0.

myeclipseide n'est pas un plugin eclipse, c'est une version modifiée (et payante) d'eclipse.

sinon à une certaine epoque j'utilisais DbDesigner

Ah, ça a l'air plus intéressant, il ne parlent pas de postgresql, mais je vais tester ça.

(je reste ouvert à d'autres suggestions, si d'autres ont des choses à proposer)

Oui, et c'est pour bientôt.
cf
http://wiki.mandriva.com/en/2010.1_Development

D'un point de vue technique, seule les lunettes électroniques synchronisées sur le projecteur me semble correcte techniquement mais je crois que c'est pas pour demain dans un cinéma (mais chez soit, c'est plus envisageable).

Ben si, c'est exactement ça qu'il y a dans les cinémas, des lunettes actives.
Tu ne croyais quand même pas que les gens allaient voir des films et rouge et vert??
À la limite des lunettes polarisantes, mais c'est pas génial pour le confort visuel car le filtrage n'est pas parfait et il faut garder la tête bien droite.

Je pense que ça a été introduit dans KDE 2.0
(la première version de konqueror, qui est un gros conteneur de kpart, est arrivée avec KDE 2.0)

Si ta liste de commandes est fournie par un flux RSS, pas besoin de reprogrammer une application, des lecteurs RSS il en existe plein, y compris des plasmoïdes pour le panneau de KDE.

je n'ai pas de BDD ( je suis pro SQLite )

Hum :-)
SQLite est une base de données.
La différence avec les autres plus connu est que c'est une DB embarquée et pas un serveur.
(certains, comme mysql derby ou firebird, peuvent aussi être embarqués)

En l'occurence, la méthode getMachinById() se doit de renvoyer une MachinNotFoundException, simplement parce qu'un catch(MachinNotFoundException mnfe) {...} est mille fois plus explicite qu'un if(machin !null) {...} qui lui n'impose pas de else {log.error('oulalala');}.


Tu semble considérer que ne pas trouver ton machin est une erreur.
Moi ça me semble plutôt un comportement tout à fait normal, on cherche un certain machin, si on le trouve on en fera quelque chose sinon on fera autre chose.
C'est au code appellant de savoir si ne pas trouver de machin est une erreur (le machin aurait du être là) où une situation normale.

Seule la méthode getMachinById() doit connaitre la nomenclature d'un Id

Ça c'est un autre problème, si l'ID a une nomenclature particulière et n'accepte pas n'importe quelle valeur il faut que la méthode lance une exception (genre IllegalArgumentException) si la valeur passée est invalide.
Mais si la valeur passée est acceptable, il ne faut pas lancer d'exception simplement parce qu'on ne trouve rien.

Image la classe Map qui lancerait une exception dans son get simplement parce que la clé donnée n'est pas présente dans le Map (d'autant que certaines implémentations acceptent null en valeur, et peuvent donc retourner null même si la clé est présente).

L'argument des performances pour la gestion des exceptions est fallacieux. Les exceptions ça va vite, et bien que ce soit verbeux, c'est lisible.

Lancer une exception nécessite de construire le stacktrace de l'endroit qui a lancé l'exception (souvent quelque dizaines de StackTraceElement), ça me semble quand même significativement plus lourd que de simplement retourner null (quand c'est pertinent par rapprot à la sémentique de la méthode) qui ne va allouer aucune mémoire.

Les exceptions ne sont pas là pour indiquer que le programme va partir en sucette à partir de maintenant. Elles sont là pour rendre plus clair le déroulement d'un programme.

On n'a vraisemblablement pas la même notion de clareté d'un code.

Parce que les exceptions sont là pour indiquer des situations "exceptionnelles". Ne pas trouver un objet avec un ID donné est une situation normale, pas une exception.
D'autant qu'il est beaucoup plus efficace de retourner un null et le tester au retour plutôt que de lancer des exceptions et de jouer du try{}catch(){}.

Les exceptions ne sont pas faites pour gérer le fonctionnement normal du programme, si une exception est lancée ça indique qu'il y a un problème.

(une petite recherche sur "exception flow control" donne plein de discussions sur le sujet)

Il n'y a aucun overlay sur la carte principale, c'est uniquement un rendu d'une partie des données disponibles.
D'ailleurs, si tu clique sur la croix en haut à droite tu peux choisir d'autres rendus, et il y a d'autres sites qui proposent des cartes spécialisée, comme par exemple cloudmade ( http://maps.cloudmade.com/ ) qui propose un service de routage (qui reste un peu aléatoire dans les zones incomplètes).
Un autre exemple amusant: un rendu des vitesse maximales http://maxspeed.osm.lab.rfc822.org/

La carte de la page principale est uniquement un aperçu de ce qu'on peut faire avec les données, ça leur coute déjà cher d'avoir des serveurs qui tiennent la charge avec un recalcul en permanence des images (car les données évoluent en continu).

Pour ce qui est de la reprise de flambeau par PostgreSQL, je suis d'accord avec toi, mais ce que je voulais dire, c'est que c'est l'alternative la plus proche en OpenSource... SQLite et BerkeleyDB sont certes très pratiques pour certaines utilisations très simples, mais sont quand même loin de MySQL. Du coup, même si PostgreSQL diffère pas mal de MySQL dans la philosophie, je pense que c'est la seule alternative viable.

Il y a aussi firebird
http://www.firebirdsql.org/
qui était à l'origne un fork d'interbase 6 (pendant la période où il a été opensource) et qui est un vrai SGBDR.
Les dernières version rattrapent le retard en terme de fonctionnalité (avant la version 2.0 il y avait vraiment très peu de fonctions de base), le développement est bien actif mais il souffre un peu de sa communauté réduite par rapport aux poids-lourds que sont MySQL et PostgreSQL.

Chuck norris a vu le big bang. C'est quand il a proposé aux scientifiques de leur faire une démonstration qu'ils ont jugé plus raisonnable de construire le LHC.

mc de son petit nom, est un gestionnaire de fichier en mode texte. Inspiré du vénérable norton commander (du temps du DOS), c'est un excellent gestionnaire de fichiers même en session graphique car il se contrôle entièrement au clavier (même s'il supporte le pointeur pour activer les différents éléments d'interface).
À mon avis c'est un incontournable!