j'ai 8 Go et un OS 32-bit, qu'elle est le problème? Je les utilise pleinement, ET c'est sans doute ce qu'il y a de plus efficace pour ce que je fais qu'un OS 64-bit (des appli 64-bit consommeraient trop).
Ca se discute.... Le plus efficace à de bonnes chances d'etre un OS 64 avec des applis en mode compat 32 bits.
Tu peux faire tourner tes applis en 64 si tu as besoin (gros espace d'adressage pour le process, nombre de registres, registres 64 bits etc.). Et tu peux faire tourner tes applis en 32 bits si besoin (taille des pointeurs & données, moins de pollution de cache). Avoir un OS en 32 ne t'apporte rien. Au contraire tu t'ajoutes des contraintes bien pourries. Sans parler des limites que tu vois (espace d'adressage des process < 3Go), un système en 32 bits implique quelques petits détails comme l'HIGHMEM... Ton noyau n'est pas capable d'adresser toute ta RAM donc il s'amuse à passer son temps à mapper/demapper les pages entre les zones HIGHMEM et NORMAL. Ca peut impliquer que tu n'arrives pas à utiliser ta RAM ou que les caches vont être purgés beaucoup plus tôt.
Un OS 32 bits cela impose de bosser avec les limitations du x86. Un OS 64 bits ca permet au noyau de pas de tapper des limitations d'il y a 15 ans. Libre aux applis de choisir si elles préfèrent les avantages de l'x86 ou de x86-64 vu que y'a un subtile compromis perf/memoire entre ces deux archis. Et le meilleur sera clairement l'ABI x32 qui permettra de tirer parti de l'archi x86-64 sans exploser le footprint et polluer le cache quand ce n'est pas nécessaire.
Ca dépend. Ca peut avoir un interet dans ton archi (des IO bloquantes avec un client par thread sont une option parmi d'autres) mais ca peut aussi être un exercice imposé. Par exemple vouloir monitorer stdout/stderr d'un paquet de processus, Java te retournant un stream qui n'est pas un selectable channel tu dois avoir 2 ou 3 threads par processus monitorés ca monte très vite... De même un pauvre service RMI qui se prend un pic de charge ponctuel, ca arrive vite.
Dans tout les cas vouloir tirer des généralités sur des performances d'une application non définie sur une architecture non définie avec une workload non définie me laissera toujours dubitatif. Y'a des avantages et des inconvénients à beaucoup de choses...
Ca ne donne aucune idée du ton lien. Y'a zero info dans la page et ca date de la préhistoire. Si tu veux donner une petite idée voici les empreintes mémoires des différents objets en Java; respectivement en 32 bits; 64 bits avec compressed pointer (par défaut), et 64 bits sans compressed pointer
Bon de toute facon, un set avec un boxing de type primitif t'ammène facilement à des overhead de 20x par rapport à du code optimisé pour l'empreinte mémoire.
Par contre ta VM en 32 bits elle va exploser en vol dès que tu vas avoir un tout petit millier de threads. Tout dépend des usages...
C'est surtout espérer tirer des recettes d'une taxation à 100% qui est complétement débile. Tu crois vraiment que y'a des gens suffisamment cons pour bruler de l'argent comme ca ? Je crois que ce n'est plus à prouver qu'à partir d'un certain revenu on sait utiliser correctement son argent (ou on sait se faire conseiller).
On peut voir ca comme une technique pour limiter les salaires, mais revenu pour l'état = 0 euros.
Effectivement après verification ils balancent les sources avec les licenses commerciales. Les rats ils les balancent pas avec les licenses open sources.
Le reste de mon commentaire reste vrai. Atlassian est très clair sur le fait qu'ils ne font pas de l'open source. Après si les clients sont mongols...
T'as les sources des produits atlassians toi ? Tu serais bien le seul vu qu'ils n'ont jamais laissé planner le moindre doute sur le fait qu'ils ne font pas de l'open source. C'est proprio, et leurs tarifs sont simples et affichés.
Les produits atlassians et jazz ca joue pas dans la même cours et ca repond pas aux memes problemes.
Cette technique de compression de la RAM existe depuis la nuit des temps avec linuxcompressed sur les 2.4 et compcache sur les 2.6. Je me souviens de pas mal de benchs à l'époque, et tu devrais pouvoir les retrouver facilement via kerneltrap. De mémoire le résultat varie grandement en fonction de ta machine, de ta config et de ta workload. Au pire c'est équivalent à utiliser du swap, et avec de la chance t'as un joli speed up.
C'est vrai que décrire ce que l'on fait c'est hasbeen. Toi tu préfère parler Scrum et agile pour faire du web 2.0 avec de l'AJAX ?
Non. Par contre pour scrum et agile t'as encore 3 ou 4 ans de retard pour essayer d'être hype.
Je vois pas en quoi parler de patron de conception c'est has been
On est en 2011 entre gens intelligents voir éduqués. Balancer un lien sur la définition du pattern singleton en disant grosso modo "Tiens apprend à coder propre" je trouve ça marrant. Et encore plus vu que le singleton c'est justement le plus mauvais pattern, il devrait mourir dans la douleur en enfer.
Justement avant que tu fasse ton malin, il disait que quand c'était mal utilisé
Trouver une utilisation justifiée du singleton est assez rare. En général ça te permet juste de faire un design moisi, avec beaucoup de couplage, un état global et un résultat impossible à tester.
Il y a énormément de documentation disponible sur pourquoi utiliser un singleton est le plus souvent une très mauvaise idée voir un anti-pattern.
Après si tu préfère continuer à coder avec les pieds c'est ton choix.
En même temps un singleton ça rentre souvent dans la catégorie coder avec ses pieds non ?
Fais attention, tu arrives quelques années en retard pour essayer d'être hype avec la locution patron de conception. Reviens 5 à 10 ans en arrière et t'es dans le coup.
Le boulot effectué par Richard Hughes autours de la gestion de la colorimétrie est remarquable. On finira peut être enfin par pouvoir avoir une chaine colorimétrique correcte et humainement utilisable sous linux. Le boulot déjà abattu est déjà notable.
Ton commentaire est assez méprisable. Avec gnome-color-manager il s'est bougé le cul pour permettre aux utilisateurs de calibrer simplement leurs différents périphériques. Avec colord il essaye enfin de proposer de répondre à un gros manque sous linux: pouvoir associer un profile avec un périphérique. Ce qui est ultra relou puisque ca force à devoir spécifier le profile du périphérique dans chaque application et de devoir changer ce paramètre à chaque fois que tu changes ta fenêtre d'écran (sympa en dual screen...). Pour ca il propose un démon, une API dbus et un binding pour gtk/gnome. Tu peux te retaper un binding si tu as envie.
Dans tout les cas, c'est le seul à s'être bouger depuis 20 ans pour faire progresser ce domaine. Et il essaie de le faire proprement. Ne va pas lui reprocher de coder en gtk et de faire le boulot d'intégration dans gnome. Quand c'est faisable à un niveau plus haut, il le fait.
Si c'était pour ça le cadre serait effectivement sombre et pas noir. Un cadre noir ca te donne l'impression que les noirs de ta télé sont gris.
C'est comme les cadres pour photo avec un passe partout blanc que tu trouves partout. C'est clairement fait pour la déco de la pièce et pas pour le bien de la photo qui va paraitre bien fade dans les tons clairs...
Non il a raison. Le patch 4/4 n'a pas besoin de PAE. La ruse c'est de garder uniquement 16MB dans l'espace d'adressage du processus pour le noyau et de flusher le TLB quand tu passes en code système. Sur un noyau classique au dessus de PAGE_OFFSET tu as tout ce qu'il faut (même mapping pour tout les processus). Du coup le patch est très couteux pour les processus qui font beaucoup d'aller retour entre code utilisateur et noyau. Après 4/4 est souvent couplé à PAE par ce qu'il est généralement utilisé sur les systèmes avec plus de 4G de RAM. Mais on pourrait très bien avoir 4G de RAM et vouloir donner cet 4G à un unique processus et donc justifié un noyau 4/4 sans PAE.
Je crois que j'avais écrit une petite doc sur le fonctionnement de tout les patchs de cette époque là (vers 2004). Faudrait que je cherche si ca intéresse quelqu'un. Autrement tout doit toujours être dispo dans les archives de kerneltrap.
Autre point très chiant: pas de compatibilité entre les releases. Du coup dès que tu utilises plusieurs OS /version d'OS/release d'OS ça peut devenir assez chiant.
C'est de l'OFX direct connect tout ce qu'il y a de plus standard. C'est juste le message qui est pourri. Il trahi d'ailleurs que le service est disponible depuis presque 10 ans...
Et au passage la poste propose justement un vrai service ofx (en plus de pouvoir les télécharger depuis le site web) ce qui correspond justement à ce que cherche notre ami... https://ofx.videoposte.com/ . AFAIK au CIC ou toute autre "banque dynamique" tu peux te brosser pour un tel service.
PS: jamais testé, homebank ne propose pas de se synchroniser, mais d'après les retours ca marche depuis des années
Ce qu'il veut c'est automatiser le téléchargement. Même les boulets (la poste) proposent le téléchargement des historiques dans des formats plus ou moins standard...
Posté par ckyl .
En réponse au journal Dédibox : ++.
Évalué à 2.
Bien sur que tu as la RC, c'est obligatoire. Relis le message auquel je répondais et ce que j' ai dit. Je parlais évidement du matériel.
Pour ta deuxieme remarque souvent ils ne sont pas proprio des voitures, même s'ils s'occupent de la revente finale. Ca peut être du leasing auprès des constructeurs avec prix achat/vente négocié des le départ (la différence pour leur pomme). Ou elles peuvent être financées par les banques. Dans tout les cas le différentiel achat/revente est ridicule.
C'est assez différent comme mécanisme mais c'est le principe de la location de véhicules de luxe. Une super car se loue 1500 a 5000 euros la journée alors qu'elle ne perd pratiquement pas de valeur par rapport a son prix d'acquisition. Sur les gros parcs ils négocient au volume pour arriver au même résultat.
Posté par ckyl .
En réponse au journal Dédibox : ++.
Évalué à 0.
Les loueurs n'assurent pas leurs voitures. Étant donné la taille de leur parc ça leur coûterait plus cher que de jeter/réparer les caisses. Ca semble d'ailleurs rationnel; pour qu'une assurance marche il faut qu'elle dégage du benef sur la somme des contrats. Donc si tu as vraiment beaucoup de contrats...
Posté par ckyl .
En réponse au journal Dédibox : ++.
Évalué à 10.
Et excuse moi, je vais peut être te choquer, mais je suis persuadé d'être capable de trouver des activités hautement plus intéressantes que d'aller dans un bureau de poste, c'est pas vraiment ma passion à moi.
C'est vrai que vu l'énergie que tu emplois à pleurer pour un pauvre recommandé qui aurait pu être envoyé en 15 minutes chrono c'est clair que tu dois avoir beaucoup d'activités hautement plus intéressantes à faire! Ca comprend passer 5h sur IRC, pondre un journal livre et 50 commentaires pour expliquer qu'on en est arrivé à avoir la flemme de bouger son cul jusqu'à une poste ?
Si c'était simplement le principe de du recommandé qui était honteux, tu n'aurais même pas signalé qu'aller à la poste ca à l'air très compliqué pour toi...
Il faut apprendre à freiner. À choisir entre uniquement un frein avant et un frein arrière, l'avant s'impose. Tu es beaucoup plus en danger avec uniquement un frein arrière qui ne permet pas d'assurer un freinage important.
La personne en face lui dira à juste titre : "mais comment je sais que le premier hash que vous me fournissez est le hash du document original et pas celui du document modifié ?".
Version courte: On s'en tape le coquillard.
Version longue: Il veut prouver qu'il possédait déjà un document à un instant T. Cet instant T correspond au moment où il transmet la preuve de possession à bob. Chercher à faire correspondre T à un autre événement n'a aucun sens. Ce qu'il s'est passé avant T on s'en fou, il peut avoir modifié 500x son fichier c'est pas le problème. Par contre une fois T passé, il a transmis son hash et devra fournir un document qui correspond au hash; et donc sauf faille de crypto le document dont il voulait prouver possession à l'instant T.
Quand tu utilises un tiers de confiance ou que tu fais dater&signer une enveloppe scellée, on s'en tape complétement de ce qu'il s'est passé avant que tu scelles l'enveloppe.
Le plus important pour résoudre un problème c'est de savoir lire l’énoncé. Il ne cherche pas à "prouver qu'il n'a pas modifié un document avec ses hashs MD5".
[^] # Re: En clair
Posté par ckyl . En réponse au journal Vente liée : comment se tirer soi-même une balle dans le pied. Évalué à 4.
Ca se discute.... Le plus efficace à de bonnes chances d'etre un OS 64 avec des applis en mode compat 32 bits.
Tu peux faire tourner tes applis en 64 si tu as besoin (gros espace d'adressage pour le process, nombre de registres, registres 64 bits etc.). Et tu peux faire tourner tes applis en 32 bits si besoin (taille des pointeurs & données, moins de pollution de cache). Avoir un OS en 32 ne t'apporte rien. Au contraire tu t'ajoutes des contraintes bien pourries. Sans parler des limites que tu vois (espace d'adressage des process < 3Go), un système en 32 bits implique quelques petits détails comme l'HIGHMEM... Ton noyau n'est pas capable d'adresser toute ta RAM donc il s'amuse à passer son temps à mapper/demapper les pages entre les zones HIGHMEM et NORMAL. Ca peut impliquer que tu n'arrives pas à utiliser ta RAM ou que les caches vont être purgés beaucoup plus tôt.
Un OS 32 bits cela impose de bosser avec les limitations du x86. Un OS 64 bits ca permet au noyau de pas de tapper des limitations d'il y a 15 ans. Libre aux applis de choisir si elles préfèrent les avantages de l'x86 ou de x86-64 vu que y'a un subtile compromis perf/memoire entre ces deux archis. Et le meilleur sera clairement l'ABI x32 qui permettra de tirer parti de l'archi x86-64 sans exploser le footprint et polluer le cache quand ce n'est pas nécessaire.
[^] # Re: En clair
Posté par ckyl . En réponse au journal Vente liée : comment se tirer soi-même une balle dans le pied. Évalué à 6.
Ca dépend. Ca peut avoir un interet dans ton archi (des IO bloquantes avec un client par thread sont une option parmi d'autres) mais ca peut aussi être un exercice imposé. Par exemple vouloir monitorer stdout/stderr d'un paquet de processus, Java te retournant un stream qui n'est pas un selectable channel tu dois avoir 2 ou 3 threads par processus monitorés ca monte très vite... De même un pauvre service RMI qui se prend un pic de charge ponctuel, ca arrive vite.
Dans tout les cas vouloir tirer des généralités sur des performances d'une application non définie sur une architecture non définie avec une workload non définie me laissera toujours dubitatif. Y'a des avantages et des inconvénients à beaucoup de choses...
[^] # Re: En clair
Posté par ckyl . En réponse au journal Vente liée : comment se tirer soi-même une balle dans le pied. Évalué à 2.
Ca ne donne aucune idée du ton lien. Y'a zero info dans la page et ca date de la préhistoire. Si tu veux donner une petite idée voici les empreintes mémoires des différents objets en Java; respectivement en 32 bits; 64 bits avec compressed pointer (par défaut), et 64 bits sans compressed pointer
Pointeur: 4 / 4 / 8
En-tete objet: 8 / 12 / 16
En-tete tableau 12 / 16 / 24
Superclass pad: 4 / 4 / 8
Bon de toute facon, un set avec un boxing de type primitif t'ammène facilement à des overhead de 20x par rapport à du code optimisé pour l'empreinte mémoire.
Par contre ta VM en 32 bits elle va exploser en vol dès que tu vas avoir un tout petit millier de threads. Tout dépend des usages...
[^] # Re: >Et oui impôt, impôt direct et impôt indirect, impôt foncier, etc...
Posté par ckyl . En réponse au journal [HS] où trouver 10 milliards ?. Évalué à 3.
C'est surtout espérer tirer des recettes d'une taxation à 100% qui est complétement débile. Tu crois vraiment que y'a des gens suffisamment cons pour bruler de l'argent comme ca ? Je crois que ce n'est plus à prouver qu'à partir d'un certain revenu on sait utiliser correctement son argent (ou on sait se faire conseiller).
On peut voir ca comme une technique pour limiter les salaires, mais revenu pour l'état = 0 euros.
[^] # Re: Atlassian open source ?
Posté par ckyl . En réponse au journal [Coup de gueule] Après le web illimité à 500Mo l'open-source en partie ouvert. Évalué à 0.
Effectivement après verification ils balancent les sources avec les licenses commerciales. Les rats ils les balancent pas avec les licenses open sources.
Le reste de mon commentaire reste vrai. Atlassian est très clair sur le fait qu'ils ne font pas de l'open source. Après si les clients sont mongols...
# Atlassian open source ?
Posté par ckyl . En réponse au journal [Coup de gueule] Après le web illimité à 500Mo l'open-source en partie ouvert. Évalué à 2.
T'as les sources des produits atlassians toi ? Tu serais bien le seul vu qu'ils n'ont jamais laissé planner le moindre doute sur le fait qu'ils ne font pas de l'open source. C'est proprio, et leurs tarifs sont simples et affichés.
Les produits atlassians et jazz ca joue pas dans la même cours et ca repond pas aux memes problemes.
[^] # Re: skoistruc ?
Posté par ckyl . En réponse au journal Pour les développeurs qui en ont dans le slip. Évalué à 3.
http://www.weecod.com
[^] # Re: Pas d'effets inverses ?
Posté par ckyl . En réponse au journal Améliorer vos ordinateurs avec zRam !. Évalué à 8.
Cette technique de compression de la RAM existe depuis la nuit des temps avec linuxcompressed sur les 2.4 et compcache sur les 2.6. Je me souviens de pas mal de benchs à l'époque, et tu devrais pouvoir les retrouver facilement via kerneltrap. De mémoire le résultat varie grandement en fonction de ta machine, de ta config et de ta workload. Au pire c'est équivalent à utiliser du swap, et avec de la chance t'as un joli speed up.
[^] # Re: Postgresql
Posté par ckyl . En réponse au journal Mysql, je t'aime un peu, à la folie, mais pas trop libre. Évalué à 0.
Non. Par contre pour scrum et agile t'as encore 3 ou 4 ans de retard pour essayer d'être hype.
On est en 2011 entre gens intelligents voir éduqués. Balancer un lien sur la définition du pattern singleton en disant grosso modo "Tiens apprend à coder propre" je trouve ça marrant. Et encore plus vu que le singleton c'est justement le plus mauvais pattern, il devrait mourir dans la douleur en enfer.
Tu sembles avoir du mal à lire les timestamps.
[^] # Re: Postgresql
Posté par ckyl . En réponse au journal Mysql, je t'aime un peu, à la folie, mais pas trop libre. Évalué à 1.
Comment tu testes ton code ?
Trouver une utilisation justifiée du singleton est assez rare. En général ça te permet juste de faire un design moisi, avec beaucoup de couplage, un état global et un résultat impossible à tester.
Il y a énormément de documentation disponible sur pourquoi utiliser un singleton est le plus souvent une très mauvaise idée voir un anti-pattern.
[^] # Re: Postgresql
Posté par ckyl . En réponse au journal Mysql, je t'aime un peu, à la folie, mais pas trop libre. Évalué à 6.
En même temps un singleton ça rentre souvent dans la catégorie coder avec ses pieds non ?
Fais attention, tu arrives quelques années en retard pour essayer d'être hype avec la locution patron de conception. Reviens 5 à 10 ans en arrière et t'es dans le coup.
[^] # Re: quel cloud ?
Posté par ckyl . En réponse au journal Il sont pas mignons les concepteurs de GNOME 3 ?. Évalué à 8.
Le boulot effectué par Richard Hughes autours de la gestion de la colorimétrie est remarquable. On finira peut être enfin par pouvoir avoir une chaine colorimétrique correcte et humainement utilisable sous linux. Le boulot déjà abattu est déjà notable.
Ton commentaire est assez méprisable. Avec gnome-color-manager il s'est bougé le cul pour permettre aux utilisateurs de calibrer simplement leurs différents périphériques. Avec colord il essaye enfin de proposer de répondre à un gros manque sous linux: pouvoir associer un profile avec un périphérique. Ce qui est ultra relou puisque ca force à devoir spécifier le profile du périphérique dans chaque application et de devoir changer ce paramètre à chaque fois que tu changes ta fenêtre d'écran (sympa en dual screen...). Pour ca il propose un démon, une API dbus et un binding pour gtk/gnome. Tu peux te retaper un binding si tu as envie.
Dans tout les cas, c'est le seul à s'être bouger depuis 20 ans pour faire progresser ce domaine. Et il essaie de le faire proprement. Ne va pas lui reprocher de coder en gtk et de faire le boulot d'intégration dans gnome. Quand c'est faisable à un niveau plus haut, il le fait.
[^] # Re: quel cloud ?
Posté par ckyl . En réponse au journal Il sont pas mignons les concepteurs de GNOME 3 ?. Évalué à 1.
Si c'était pour ça le cadre serait effectivement sombre et pas noir. Un cadre noir ca te donne l'impression que les noirs de ta télé sont gris.
C'est comme les cadres pour photo avec un passe partout blanc que tu trouves partout. C'est clairement fait pour la déco de la pièce et pas pour le bien de la photo qui va paraitre bien fade dans les tons clairs...
[^] # Re: attendre le krash
Posté par ckyl . En réponse au journal Et vous, vos collectivités territoriales ont-elles des emprunts toxiques ?. Évalué à 3.
Ça serait triste. C'est les seuls à faire des études un peu marrantes: http://blogs.reuters.com/felix-salmon/files/2011/09/09-06-11-EOTM-European-Minifigure-Union.pdf
[^] # Re: ABI 16 bits?
Posté par ckyl . En réponse au journal x32: Une nouvelle ABI Linux '32 bits' pour les CPU x86-64. Évalué à 4.
D'après la doc, le 286 n'a pas un bus d'adresse de 16 bits mais de 24 bits et de la segmentation.
[^] # Re: 0xc0000000
Posté par ckyl . En réponse au journal x32: Une nouvelle ABI Linux '32 bits' pour les CPU x86-64. Évalué à 4.
Non il a raison. Le patch 4/4 n'a pas besoin de PAE. La ruse c'est de garder uniquement 16MB dans l'espace d'adressage du processus pour le noyau et de flusher le TLB quand tu passes en code système. Sur un noyau classique au dessus de PAGE_OFFSET tu as tout ce qu'il faut (même mapping pour tout les processus). Du coup le patch est très couteux pour les processus qui font beaucoup d'aller retour entre code utilisateur et noyau. Après 4/4 est souvent couplé à PAE par ce qu'il est généralement utilisé sur les systèmes avec plus de 4G de RAM. Mais on pourrait très bien avoir 4G de RAM et vouloir donner cet 4G à un unique processus et donc justifié un noyau 4/4 sans PAE.
Je crois que j'avais écrit une petite doc sur le fonctionnement de tout les patchs de cette époque là (vers 2004). Faudrait que je cherche si ca intéresse quelqu'un. Autrement tout doit toujours être dispo dans les archives de kerneltrap.
[^] # Re: Lennart a une idée!
Posté par ckyl . En réponse au journal Je voudrais mettre un nuage chez moi !. Évalué à 3.
Autre point très chiant: pas de compatibilité entre les releases. Du coup dès que tu utilises plusieurs OS /version d'OS/release d'OS ça peut devenir assez chiant.
[^] # Re: Dépend des banques
Posté par ckyl . En réponse au journal Les banques, et le téléchargement des données. Évalué à 4.
C'est de l'OFX direct connect tout ce qu'il y a de plus standard. C'est juste le message qui est pourri. Il trahi d'ailleurs que le service est disponible depuis presque 10 ans...
http://en.wikipedia.org/wiki/Open_Financial_Exchange
[^] # Re: Dépend des banques
Posté par ckyl . En réponse au journal Les banques, et le téléchargement des données. Évalué à 10.
Et au passage la poste propose justement un vrai service ofx (en plus de pouvoir les télécharger depuis le site web) ce qui correspond justement à ce que cherche notre ami... https://ofx.videoposte.com/ . AFAIK au CIC ou toute autre "banque dynamique" tu peux te brosser pour un tel service.
PS: jamais testé, homebank ne propose pas de se synchroniser, mais d'après les retours ca marche depuis des années
[^] # Re: Dépend des banques
Posté par ckyl . En réponse au journal Les banques, et le téléchargement des données. Évalué à 10.
Ce qu'il veut c'est automatiser le téléchargement. Même les boulets (la poste) proposent le téléchargement des historiques dans des formats plus ou moins standard...
[^] # Re: Avis sur OVH
Posté par ckyl . En réponse au journal Dédibox : ++. Évalué à 2.
Bien sur que tu as la RC, c'est obligatoire. Relis le message auquel je répondais et ce que j' ai dit. Je parlais évidement du matériel.
Pour ta deuxieme remarque souvent ils ne sont pas proprio des voitures, même s'ils s'occupent de la revente finale. Ca peut être du leasing auprès des constructeurs avec prix achat/vente négocié des le départ (la différence pour leur pomme). Ou elles peuvent être financées par les banques. Dans tout les cas le différentiel achat/revente est ridicule.
C'est assez différent comme mécanisme mais c'est le principe de la location de véhicules de luxe. Une super car se loue 1500 a 5000 euros la journée alors qu'elle ne perd pratiquement pas de valeur par rapport a son prix d'acquisition. Sur les gros parcs ils négocient au volume pour arriver au même résultat.
[^] # Re: Avis sur OVH
Posté par ckyl . En réponse au journal Dédibox : ++. Évalué à 0.
Les loueurs n'assurent pas leurs voitures. Étant donné la taille de leur parc ça leur coûterait plus cher que de jeter/réparer les caisses. Ca semble d'ailleurs rationnel; pour qu'une assurance marche il faut qu'elle dégage du benef sur la somme des contrats. Donc si tu as vraiment beaucoup de contrats...
[^] # Re: Ça te protège
Posté par ckyl . En réponse au journal Dédibox : ++. Évalué à 10.
C'est vrai que vu l'énergie que tu emplois à pleurer pour un pauvre recommandé qui aurait pu être envoyé en 15 minutes chrono c'est clair que tu dois avoir beaucoup d'activités hautement plus intéressantes à faire! Ca comprend passer 5h sur IRC, pondre un journal livre et 50 commentaires pour expliquer qu'on en est arrivé à avoir la flemme de bouger son cul jusqu'à une poste ?
Si c'était simplement le principe de du recommandé qui était honteux, tu n'aurais même pas signalé qu'aller à la poste ca à l'air très compliqué pour toi...
[^] # Re: Ceux qui ont du mal à cohabiter...
Posté par ckyl . En réponse au journal Les cyclistes cette engeance du d.... ..... qui puent des pieds en plus!. Évalué à 2.
Il faut apprendre à freiner. À choisir entre uniquement un frein avant et un frein arrière, l'avant s'impose. Tu es beaucoup plus en danger avec uniquement un frein arrière qui ne permet pas d'assurer un freinage important.
[^] # Re: Oui ça fonctionne
Posté par ckyl . En réponse au journal MD5 et garantie de non-modification. Évalué à 3.
Version courte: On s'en tape le coquillard.
Version longue: Il veut prouver qu'il possédait déjà un document à un instant T. Cet instant T correspond au moment où il transmet la preuve de possession à bob. Chercher à faire correspondre T à un autre événement n'a aucun sens. Ce qu'il s'est passé avant T on s'en fou, il peut avoir modifié 500x son fichier c'est pas le problème. Par contre une fois T passé, il a transmis son hash et devra fournir un document qui correspond au hash; et donc sauf faille de crypto le document dont il voulait prouver possession à l'instant T.
Quand tu utilises un tiers de confiance ou que tu fais dater&signer une enveloppe scellée, on s'en tape complétement de ce qu'il s'est passé avant que tu scelles l'enveloppe.
Le plus important pour résoudre un problème c'est de savoir lire l’énoncé. Il ne cherche pas à "prouver qu'il n'a pas modifié un document avec ses hashs MD5".