Snark_Boojum a écrit 579 commentaires

Le lien est mort

Quand on valide une contribution, il y a un texte: "Merci de bien vouloir suivre le lien suivant pour éviter que ça apparaisse en double"...

Personnellement, j'aurais trouvé logique:
* un clic gauche, on ouvre la nouvelle fenêtre, on ferme la courante;
* un clic milieu, on ouvre la nouvelle fenêtre, on conserve la courante.

Ce serait quand même plus pratique...

Une idée comme ça: on va imaginer les régions stockées sous la forme (x_min, x_max, y_min, y_max). Alors si on les range par ordre x_min croissant, on peut traverser la liste pour chercher celles qui contiennent un point (x, y) de la façon suivante:
* tant que x_max < x, on peut continuer, aucune chance que le point soit dedans (un seul test par zone, donc);
* dès que x_max >= x, on regarde la condition x_min <= x ; tant qu'elle est vraie, on fait la vérification y >= y_min et y <= y_max (ie: on regarde complètement ces zones: quatre tests par zone);
* dès que x_min > x, on s'arrête de parcourir la liste, il n'est plus possible que le point soit dans les zones (zéro test par zone).

Ca doit accélérer un peu les choses ; sachant qu'on peut encore améliorer les points suivants:
1) s'assurer que le compilo fait une évaluation paresseuse des conditions sur y (ie: pas de test de la seconde si la première est déjà fausse);
2) pour les zones qui ont le même x_min, les ranger par x_max croissant;
3) et pour les zones qui ont les mêmes x_min et x_max, les ranger par y_min croissant;
4) et pour les zones qui ont les mêmes x_min, x_max et y_min, les ranger par y_max croissant.

Le 1) coûte pas cher. Par contre 2), 3) et 4), suivant les configurations qui apparaissent dans le problème, on n'a rien à gagner. En fait, elles ne coûtent pas si cher à l'insertion, mais l'algo de parcours devient un peu lourd à écrire.

Et naturellement, si le problème fait qu'il vaut mieux ranger par y_min que par x_min, il ne faut pas se gêner!

Bon courage

Lyx est un peu lourd à installer, et je ne suis pas sûr qu'il gère bien les documents éclatés en plusieurs fichiers (je peux me tromper sur ce dernier point).

Sinon, je confirme: esd n'est pas bon du tout, c'est pour ça que gnomemeeting ne l'utilise pas ; on attend de voir émerger un bon démon de son (et/ou multimédia) commun à gnome et kde pour changer ça...

Puisque je parle de gnomemeeting: on aimerait bien l'intégrer avec les clients jabber, parce que ce serait un plus. Mais en ce moment, on essaie de voir si on peut le faire tourner sous win32...

*lol*

Mon lecteur merde, j'en achète un autre, il faut tout racheter?

Je ne suis pas intéressé!

Je crois que la xlib n'est pas sous la même licence que le serveur, justement pour que les gens puissent l'utiliser plus librement... à vérifier, sans doute, mais il me semble bien ;-)

Néanmoins:
1) chaque utilisateur fait tourner plus de programmes (les os modernes sont multitâches) ; et chaque machine peut recevoir plusieurs utilisateurs (penser à des TX dans une salle de TP, par exemple), donc il faut multiplier les dizaines de kilo-octets par le nombre de programmes et le nombre d'utilisateurs: ça va commencer à faire beaucoup, même si les .so aident à mutualiser;
2) ce n'est pas parce que les ressources sont moins rares qu'il faut les gaspiller, entre acheter une machine deux fois plus puissantes pour faire la même chose, et une machine deux fois plus puissantes pour faire le double, je choisis le second choix!

Il y a plus rapide que fluxbox: golem!

Ben en première page ou en seconde, je vois juste une caméra qui en filme une autre... c'est quoi l'intérêt?

Si au moins on avait une explication, genre:
* j'ai écrit un nouveau pilote!
* j'ai modifié le logiciel pour qu'il accepte des entrées de plusieurs sources en même temps!

Alors, qu'est-ce qui est beau?

J'ai déjà le module dans l'arborescence, et toute l'arborescence appartient déjà à l'utilisateur qui va bien... je vais essayer de changer de version de j2re... passer de 1.4 à 1.3...

Ca avait très bien marché l'an dernier...

Pas de chiffres dans mon mot de passe ; et comme par ailleurs j'arrive à me faire reconnaître pour remplir la déclaration, et que l'os c'est seulement à la signature...

mozilla tourne sur le serveur: pas de problème de NAT...

Moi je vois très bien l'intérêt du ./, parce qu'il ne me viendrait pas à l'idée de mettre . dans mon $PATH...

Hum! Le partage des carnets d'adresse est très facile avec windows: un de mes beaufs a choppé un virus, donc je me suis mis à recevoir des courriers de tous ses copains (forgés par le virus, évidemment), et finalement, un mail de cette andouille pour expliquer de pas cliquer sur ces mails, parce que c'était un virus, avec, au cas où je n'aurais pas déjà noté les noms&adresses, tout son carnet en CC...

Je confirme: quand le virus infecte une machine, il va dans le carnet d'adresses, et s'envoie à ceux qui sont dedans _sous l'identité des personnes qui sont dedans_ (pas uniquement de la personne infectée, donc!).

L'idée, c'est que les amis de mes amis sont mes amis, donc si je reçois un courrier de l'un d'eux, j'ouvre. En l'occurrence, mon plus jeune beauf s'est fait infecté, et je l'ai su en voyant l'afflux de mails vérolés de ses copains... Naturellement, sous GNU/Linux avec evolution: même pas mal. Sauf que ça sature un peu ma boîte, et ça fait chier quand même.

Je lui ai écrit pour lui signaler que sur www.mozilla.org, il trouverait des outils très adaptés aux neuneus, et pas écrits par et pour des pieds.

La notion de "monopole", c'est justement quand quelqu'un a suffisamment de poids pour que des adversaires meilleurs n'aient aucune chance, et parce qu'il n'y a plus de libre concurrence.

J'appelle ça monopole parce que la justice en a décidé ainsi dans les deux super-puissances économiques: États-Unis et Europe! Que ce monopole soit mérité ou pas, il faut:
1) Faire en sorte que des concurrents qui proposent un produit sérieux, bâti avec la sueur et les larmes, puissent concurrencer sans se faire écraser;
2) Faire en sorte que ce monopole ne serve pas à en acquérir d'autres.

Il faut noter que le but des sanctions ne sera pas de tuer MS, ou l'empêcher de faire de bons produits. C'est de l'empêcher d'être une nuisance.

La chose importante à noter, c'est "monopole". Ca veut dire qu'ils ont les moyens d'attenter à la liberté des autres. Ce qui dans une société bien foutue autorise l'Etat à prendre des mesures coercitives.

Un peu comme quand on met les gens en prison pour racket, quoi...

Suivant la complexité des données, glib est capable de faire des choses...

J'ajouterais même: je préfère avoir plein de bonnes bactéries tout autour de moi, parce qu'il suffit d'avoir des notions élémentaires d'écologie, pour savoir que la nature s'arrange pour boucher les trous: s'il y a des nutriments et rien pour les consommer, quelque chose va se pointer pour occuper la niche, et il n'y a aucune raison pour que cette chose soit gentille avec moi.

Donc avoir un certain nombre de bactéries qui font coupe-feu, c'est pas forcément une mauvaise idée! (évidemment, ça ne veut pas dire qu'il faut être complètement crado sans la moindre hygiène, ça veut dire qu'il faut être raisonnable).

Illusoire. Il y avait /toujours/ une partie qui dépendait du système hôte. Ce qu'ils proposent, pour ce que j'ai compris, c'est que quitte à ce que cette partie dépende du noyau, autant la mettre dedans, _pour peu qu'on dispose des sources du noyau en question_.

Ce n'est pas forcément un mauvais choix, sachant que de toutes façons, ça fait un certain temps que des choses relatvies à l'affichage se greffent sur/dans les noyaux (DRI, AGP, NVidia...).

L'important est que tous ces pilotes exportent une api commune, car alors, porter X (ou Y) sur une nouvelle plateforme, consistera essentiellement à écrire un pilote qui exporte cette interface. Cela rendra très nettement plus simple le portage vers un OS jeune ou un peu particulier (il y en a un certain nombre, plus ou moins obscurs!).

Oui, mais il se trouve que dans ce cas, enlever le module, le remettre, relancer X, etc... Ca marche, mais on ne retrouve pas l'affichage: un peu comme si la carte vidéo était plantée.