> - L'autre solution c'est d'avoir 2 groupes de telechargeurs, ceux qui commence par le debut et ceux qui commence par la fin.
Riche idée ! Une référence ?
En fait on peut diviser la population en N classes et pas eulement 2 ni de cette façon. Il suffit que N soit constant et de quelques contraintes sur la distribution.
Hmm ça me rappelle l'art de coder un tri en O(n), si vous êtes sages, un jour je vous raconterai. ;-)
> Quand le driver d'un matos bien maintenu ne l'est plus, le
> matos devient du matos mal maintenu, que le constructeur
> ait mis la main à la pate, ou pas.
Mettre la main à la pâte n'est pas un fait ponctuel : le support est une action continue. A un instant donné, il devrait être possible de dire quels drivers/préiphériques sont activement supportés.
Pour te prémunir des périphériques dont le support dure aussi longtemps que la neige en plein soleil, il n'y a que deux solutions :
1/ tu prends du matos "standard" et de marque sérieuse
2/ tu contractes avec le fabriquant une garantie de support
et une troisième pour nous, les gnous ou pour ceux qui emploient des gnous :
3/ tu assures le support toi-même
Pour le particulier non-kernel-hacker (il y en a ?) il n'y a que la solution 1.
Cette décision d'Adrian Bunk permet simplement d'identifier plus facilement les boîtes pas du tout sérieuses. Bouh les vilaines ;-)
(je sens que je devrais me relire... hum... non !)
Ca a été ma première idée car j'avais déjà gravé sans utiliser d'ISO mais j'ai l'impression que ce n'est pas possible car la problème avec l'entrée standard c'est que c'estun flux : on perd la hiérarchie et même plus si affinités.
je crois que je vais gâcher un CD (oui pas de RW) pour me faire de la place et pouvoir détarrer sur le dur avant de faire un mkisofs | cdrecord
Sur le long terme c'est à voir... Il me semble me rappeler que pour le JDK 1.5 les interfaces Swing pourrait prendre avantage de l'interface native (et plus seulement utiliser un look and feel ressemblant).
Dans ce cas, il faudra voir ce que çà donne, mais çà peut être judicieux de ne pas s'engager dans un autre toolkit... tout de suite.
D'un autre point de vu sur le long terme, en misant sur une évolution du JDK1.5 tu t'inscris encore plus dans une relation de dépendance vis-à-vis de Sun et comme c'est pas de si tôt que l'on aura un JDK1.4 ou + libre...
Sur le long terme c'est la solution faisant intervenir le plus de solutions libres|ouvertes qui gagne.
NOSQL pourrait être un projet interessant, s'il était destiné à remplacer des bases de données de type Access ou il n'y a pas besoins de deamon
puis tu critiques SQLite par : il n'est pas possible d'attaquer la base de données avec un driver ODBC, JDBC ou en PHP
Le problème c'est que d'un côté tu veux de la base de données "enfouie" (enchâssée ?) et d'un autre tu veux y accéder avec une sémantique client-serveur.
Si tu veux partager des données entre plusieurs applis tu finiras toujours par te retrouver avec un système client-serveur, c'est la solution la plus pratique et la plus fiable.
Sans compté que le joueur qui a vendu Halo a reçu de l'argent qui, d'une certaine manière (et à rebrousse temps) vient de TA poche, et lui va s'en servir pour acheter un autre jeu.
S'il achète cet autre jeu d'occasion, TON argent ira dans la poche d'un autre joueur qui a vendu etc.
Dans le lot il finira bien par en avoir un qui va acheter un jeu neuf et là...
Raah ! chut faut dire iSeries maintenant, AS/400 c'est un gros mot ! Il n'empêche que c'est une machine étonnante et bien pensée mais, des jours, la TMA sur une appli en RPG3 pensée pour le S/38 pfff... GOTO power
Rien ne prouve qu'un code compilé en natif soit plus efficace qu'un code compilé en JIT
Une fois "jitté" certes ! Mais il faut bien que le compilo JIT fasse son boulot alors qu'avec un compilo classique c'est déjà fait.
Le régime permanent est similaire dans les deux cas mais l'une des deux solutions crée un régime transitoire beaucoup plus important ce qui se traduit par un manque de réactivité.
Moralité :
Si tu as une appli qui ne s'arrête jamais le code compilé en natif n'est pas plus efficace qu'un code compilé en JIT.
Si tu as une appli utilitaire que tu n'arrêtes pas de lancer et d'arrêter, là le code natif est meilleur.
[^] # Re: Soft de peer to perr
Posté par Christophe GRAND (site web personnel) . En réponse au journal Soft de peer to perr. Évalué à 1.
Riche idée ! Une référence ?
En fait on peut diviser la population en N classes et pas eulement 2 ni de cette façon. Il suffit que N soit constant et de quelques contraintes sur la distribution.
Hmm ça me rappelle l'art de coder un tri en O(n), si vous êtes sages, un jour je vous raconterai. ;-)
[^] # Re: Soft de peer to perr
Posté par Christophe GRAND (site web personnel) . En réponse au journal Soft de peer to perr. Évalué à 9.
# Re: Les copines de Geek aux RMLL
Posté par Christophe GRAND (site web personnel) . En réponse à la dépêche Les copines de Geek aux RMLL. Évalué à 1.
[^] # Re: Pas si simple
Posté par Christophe GRAND (site web personnel) . En réponse à la dépêche Mise à l'écart de certains pilotes de périphériques dans le noyau 2.6. Évalué à 5.
> matos devient du matos mal maintenu, que le constructeur
> ait mis la main à la pate, ou pas.
Mettre la main à la pâte n'est pas un fait ponctuel : le support est une action continue. A un instant donné, il devrait être possible de dire quels drivers/préiphériques sont activement supportés.
Pour te prémunir des périphériques dont le support dure aussi longtemps que la neige en plein soleil, il n'y a que deux solutions :
1/ tu prends du matos "standard" et de marque sérieuse
2/ tu contractes avec le fabriquant une garantie de support
et une troisième pour nous, les gnous ou pour ceux qui emploient des gnous :
3/ tu assures le support toi-même
Pour le particulier non-kernel-hacker (il y en a ?) il n'y a que la solution 1.
Cette décision d'Adrian Bunk permet simplement d'identifier plus facilement les boîtes pas du tout sérieuses. Bouh les vilaines ;-)
(je sens que je devrais me relire... hum... non !)
[^] # Re: Graver quand on a plus de place
Posté par Christophe GRAND (site web personnel) . En réponse au journal Graver quand on a plus de place. Évalué à 1.
[^] # Re: Graver quand on a plus de place
Posté par Christophe GRAND (site web personnel) . En réponse au journal Graver quand on a plus de place. Évalué à 1.
je crois que je vais gâcher un CD (oui pas de RW) pour me faire de la place et pouvoir détarrer sur le dur avant de faire un mkisofs | cdrecord
[^] # Re: collecticiel: mais ça pue ce mot !
Posté par Christophe GRAND (site web personnel) . En réponse au journal collecticiel: mais ça pue ce mot !. Évalué à 1.
Pour les St Thomas : http://dictionary.reference.com/search?q=informatics(...)
[^] # Re: collecticiel: mais ça pue ce mot !
Posté par Christophe GRAND (site web personnel) . En réponse au journal collecticiel: mais ça pue ce mot !. Évalué à 1.
> Diaporiciel !
Non, non ils utilisent ça pour désigner le ware qui est composé de slides tu vois c'est-à-dire un ou plusieurs diaporamas !
Par moment à écouter ces commerciaux-là j'avais l'impression de bosser chez Jean-Claude Vandamme Software
[^] # Re: collecticiel: mais ça pue ce mot !
Posté par Christophe GRAND (site web personnel) . En réponse au journal collecticiel: mais ça pue ce mot !. Évalué à 2.
IT = Information Technology
Au fait http://www.acronymfinder.com(...) est ton ami (et le mien aussi)
Ce qui m'énerve vraiment ce sont les acronymes "maison" propres à une boîte.
[^] # Re: collecticiel: mais ça pue ce mot !
Posté par Christophe GRAND (site web personnel) . En réponse au journal collecticiel: mais ça pue ce mot !. Évalué à 3.
truc et pas truque
[^] # Re: collecticiel: mais ça pue ce mot !
Posté par Christophe GRAND (site web personnel) . En réponse au journal collecticiel: mais ça pue ce mot !. Évalué à 3.
slideshow = diaporama
par contre je connais des vicieux qui disent slideware
corporate = d'entreprise
knowledge management = gestion de la connaissance
Par contre ce que je n'aime pas ce sont les abbréviatons.
[^] # Re: Les fourmis (la suite)
Posté par Christophe GRAND (site web personnel) . En réponse au journal Les fourmis (la suite). Évalué à 1.
Et Perec aussi...
[^] # Re: Les fourmis (la suite)
Posté par Christophe GRAND (site web personnel) . En réponse au journal Les fourmis (la suite). Évalué à 1.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par Christophe GRAND (site web personnel) . En réponse à la dépêche 1ère mouture du collecticiel client de OpenOffice.org : Glow. Évalué à 4.
Dans ce cas, il faudra voir ce que çà donne, mais çà peut être judicieux de ne pas s'engager dans un autre toolkit... tout de suite.
D'un autre point de vu sur le long terme, en misant sur une évolution du JDK1.5 tu t'inscris encore plus dans une relation de dépendance vis-à-vis de Sun et comme c'est pas de si tôt que l'on aura un JDK1.4 ou + libre...
Sur le long terme c'est la solution faisant intervenir le plus de solutions libres|ouvertes qui gagne.
# Re: TV + portable
Posté par Christophe GRAND (site web personnel) . En réponse au journal TV + portable. Évalué à 2.
# Re: Dock
Posté par Christophe GRAND (site web personnel) . En réponse au journal Dock. Évalué à 2.
[^] # Re: et NOSQL, pas bon ca non plus ?
Posté par Christophe GRAND (site web personnel) . En réponse au journal et NOSQL, pas bon ca non plus ?. Évalué à 1.
puis tu critiques SQLite par :
il n'est pas possible d'attaquer la base de données avec un driver ODBC, JDBC ou en PHP
Le problème c'est que d'un côté tu veux de la base de données "enfouie" (enchâssée ?) et d'un autre tu veux y accéder avec une sémantique client-serveur.
Si tu veux partager des données entre plusieurs applis tu finiras toujours par te retrouver avec un système client-serveur, c'est la solution la plus pratique et la plus fiable.
[^] # Re: Mozilla cassé !
Posté par Christophe GRAND (site web personnel) . En réponse au journal Mozilla cassé !. Évalué à 1.
(les fontes je ne sais pas encore, j'ai plus de site qui merde en mémoire)
[^] # Re: Mozilla cassé !
Posté par Christophe GRAND (site web personnel) . En réponse au journal Mozilla cassé !. Évalué à 1.
[^] # Re: J'ai acheté une XBox...mais j'ai honte !
Posté par Christophe GRAND (site web personnel) . En réponse au journal J'ai acheté une XBox...mais j'ai honte !. Évalué à 3.
S'il achète cet autre jeu d'occasion, TON argent ira dans la poche d'un autre joueur qui a vendu etc.
Dans le lot il finira bien par en avoir un qui va acheter un jeu neuf et là...
PAF CRACK BOUM HUE => dans la poche à Microsoft.
(je sais je suis tordu)
[^] # Re: Mozilla cassé !
Posté par Christophe GRAND (site web personnel) . En réponse au journal Mozilla cassé !. Évalué à 1.
[^] # Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Christophe GRAND (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.
PA : Ch job AS400 "moderne" IdF ou Rh-Al ;-)
[^] # Re: Légende urbaine : un alligator dans le ramasse-miettes
Posté par Christophe GRAND (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.
Et les gros et moyens systèmes qui font encore beaucoup de boulot...
[^] # Re: perfs de java
Posté par Christophe GRAND (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.
Une fois "jitté" certes ! Mais il faut bien que le compilo JIT fasse son boulot alors qu'avec un compilo classique c'est déjà fait.
Le régime permanent est similaire dans les deux cas mais l'une des deux solutions crée un régime transitoire beaucoup plus important ce qui se traduit par un manque de réactivité.
Moralité :
Si tu as une appli qui ne s'arrête jamais le code compilé en natif n'est pas plus efficace qu'un code compilé en JIT.
Si tu as une appli utilitaire que tu n'arrêtes pas de lancer et d'arrêter, là le code natif est meilleur.
[^] # Camelidés (fut: Re: perfs de java)
Posté par Christophe GRAND (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 2.
Une erreur courrement faite on dirait :).
Les clopes Camel aussi ont pour emblème un dromadaire.
Les anglophones désignent par camel n'importe quel camélidé. Le dromadaire étant le dromedary et et la chameau le bactrian camel.