Va pour le téléphone cellulaire, mais chez toute la jeune génération, le courriel est en train de mourir. De plus en plus de djeunz (comprendre "moins de 25 ans") donnent leur adresse @facebook.com quand on leur demande un email. Pour l'instant, ça fonctionne…
On mélange allégrement deux choses ici. XMPP (le protocole) est prévu pour échange du XML entre plusieurs clients passant par un serveur, le tout fédéré (i.e. truc@bidule.com peut échanger avec machin@chose.net). Jabber, l'application de ce protocole à la messagerie instantanée, permet donc d'échanger des messages (du texte) entre plusieurs utilisateurs de plusieurs serveurs, mais toujours en passant par ces serveurs. Dans les deux cas, on a un protocole TCP bien défini, qui s'appuie sur des numéros de ports enregistrés à l'IANA, etc.
Des règles de sortie restrictives
Sauf que ces numéros de ports (5999 et compagnie) sont parfois bloqués en sortie dans les entreprises (et autres réseaux un peu coincés du QoS). C'est le premier problème de NAT qu'on peut imputer à Jabber, et qui est globalement réglé par les clients Web. Ces derniers existent depuis la fin des années 90, et fonctionnaient alors essentiellement côté serveur : un formulaire, qui envoie à du code serveur (PHP & co) les requêtes, qui les envoie à son tour au serveur XMPP (auprès duquel il s'est auparavant authentifié), et retour.
Tout cela était bien joli, mais avec la mode de l'AJAX, c'est devenu particulièrement pas sexy comme manière de faire. On a donc commencé à réfléchir à la meilleure manière d'établir la connexion au serveur XMPP directement depuis le code Javascript du client. Ce dernier étant habitué à manipuler du DOM (éventuellement XML), manipuler des messages XMPP n'aurait pas du lui faire trop peur. Sauf que Javascript dans un navigateur, ça ne sait pas trop se connecter à un protocole TCP quelconque. On a donc produit un certain nombre de contournements techniques, les deux plus récents (et intéressants) étant :
BoSH (Binary over Streamed HTTP, de mémoire), qui encapsule le plus proprement possible le dialogue XMPP dans du HTTP.
XMPP-over-Websockets, qui est clairement l'avenir mais mal défini/supporté pour l'instant.
Concrètement un point d'entrée BoSH est une URL HTTP(S) standard, qui fait l'interface entre un serveur XMPP (la plupart permettent de servir directement cette URL, sinon il y a des proxies autonomes faciles à déployer) et le client Web. Évidemment, les problématiques de "cross origin" s'appliquent, on a donc intérêt à servir directement un point d'entrée BoSH sur le domaine qu'on héberge, si on le peut.
Les clients "lourds" ont sauté en marche de le "BoSH train", et certains peuvent effectivement se connecter via une URL BoSH, ce qui permet - mais l'intention initiale n'était pas là - de contourner les règles de sortie les plus restrictives.
Des connexions directes
Depuis qu'il est question de voix et de vidéo dans les outils de messagerie instantanée (et donc bien avant Skype), il est clair pour à peu près tout le monde que le modèle client->serveur->client n'est pas satisfaisant, pour des raisons de bande passante. On a donc depuis très longtemps (MSN le faisait déjà, de mémoire) fait en sorte que les clients soient capables de négocier (avec l'aide du serveur) un canal de communication direct. Chez XMPP, comme on n'aime pas faire les choses de manière inélégante, on a mis très (trop?) longtemps à produire une spec correcte, et c'est finalement Google qui a sorti tout le monde de l'ornière. Ils ont en effet défini une manière de faire (Jingle) pour GTalk, et ont soumis leur spec à l'organisme de standardisation d'XMPP. Je passe sur les allers-retours de la norme, sur le fait que GTalk a longtemps utilisé une version de Jingle qui n'était plus celle recommandée par XMPP… bref.
Dans les grandes lignes, Jingle permet à deux clients de :
déterminer leur capacité à communiquer malgré leurs éventuels NATs respectifs
utiliser un intermédiaire (i.e. proxy) en cas d'incapacité
choisir des codecs audio et vidéo communs
L'ennui majeur ici, c'est que le cas où l'on doit passer par un proxy est beaucoup trop fréquent, et que placer cette charge sur une seule machine n'est pas raisonnable. Une solution supplémentaire a été trouvée (et est implémentée au moins par Jitsi et OneTeam) : Jingle Nodes. Dans Nodes, on pousse la logique un peu plus loin, et on permet à un client qui a les bonnes caractéristiques (en termes de NAT) de se comporter en proxy. On répartit ainsi la charge sur un maximum de machines/connexions.
Bon, aux dernières nouvelles, la spec est un peu morte.
Pour ce que j'ai testé d'eJabberd, il permet d'utiliser une base externe pour l'authentification (perso, j'utilise plutôt LDAP, mais ce doit être possible avec Postgres). Au pire, il est capable de refiler l'authentification à un script externe (codé en n'importe quoi) : j'avais pu bricoler un script d'authentification unique avec Friendica, par ce biais.
Sauf que Jingle, son boulot c'est pas tellement de gérer le binaire (on faisait du transfert de fichiers par XMPP bien avant Jingle, voire avant que Jabber ne devienne XMPP), mais bien de gérer les connexions directes entre clients. Que les dites connexions fassent ensuite passer du texte ou du binaire est un détail.
C'est un poil plus compliqué que ça. En VNC, c'est effectivement ce qui se passe (le client demande au serveur une image, éventuellement restreinte à la zone qui a changé depuis la dernière requête, et basta). Par contre, RDP permettait - il me semble que c'était un de leurs arguments "de vente" - de mieux s'intégrer au framework graphique. Sous Windows en tous cas, il était censé encapsuler des appels aux bibliothèques graphiques (GDI?) pour éviter d'avoir à tout redessiner. En gros, l'appli dessinait un bouton côté serveur, et le côté client recevait juste les paramètres de dessin du dit bouton (et non sa représentation graphique).
Concernant le fait de mettre un PCB au four, je ne suis pas sûr que l'idée soit brillante. Chauffer tous ses vernis, colle et autre étain, est assez toxique.
Par contre, une feuille de papier d'alu sur l'ensemble du PCB, trouée pour laisser visible juste la puce défectueuse, puis un bon coup de décapeur thermique à pleine puissance… j'ai été très surpris de voir une carte graphique d'ordi portable remarcher grâce à ça ;)
Le fait que le format de fichier soit protégé (par un brevet si j'ai bonne mémoire, c'est correct?) ne pose-t'il pas un problème de fond?
Si c'est un brevet, ça ne doit pas être un souci en Europe. Si c'est autre chose, je ne vois pas quoi.
Sinon, peut-on espérer voir un jour une bibliothèque gérant les fichiers d'AutoCad? (Je veux dire: est-ce réaliste?)
Le souci, c'est que le format DWG est très touffu : plein de versions différentes, embarquent un langage de programmation, etc. Imagine de devoir réimplémenter une JVM sans avoir les specs : c'est un peu de ça qu'il s'agit. C'est pour ça que les gens qui n'ont pas besoin de publier leur source (et qui ont un peu de budget quand même) passent par OpenDWG.
Une option crédible, avant d'espérer une gestion native du DWG par des softs libres (ce que je crois très peu probable sans y mettre des moyens considérables, pour répondre à ta question), serait de construire un convertisseur DWG<->DXF correct. DXF compte au moins autant de version que DWG (chacune se déclinant en une représentation ASCII et une représentation binaire, le passage de l'une à l'autre étant théoriquement bijectif), mais il est documenté et - pour autant que je sache - n'est pas prévu pour embarquer de code. Et il est globalement censé pouvoir exprimer tout ce qu'on fichier DWG de même génération peut exprimer de manière déclarative (i.e. pas le code, donc).
Si je reviens sur LibreDWG - que j'ai suivi de près fut un temps, il avait été question de construire un très grosse suite de tests. Ce serait, à mon avis, la première étape avant d'aller plus loin : collecter (en continu) des fichiers DWG soigneusement étiquetés (version, type d'usage, etc.) et munis de rendus "intéropérables" pondus par AutoCAD et/ou un soft OpenDWG (un DXF + un PNG, par exemple).
L'usage que j'aurais pu en avoir était pourtant bien plus simple qu'un conversion : je voulais juste générer des aperçus de mes plans pour les intégrer dans un système type GED. J'eus même pu me contenter d'un aperçu textuel (i.e. un export des textes significatifs du DWG pour constitution d'un index plein-texte). Même cet usage était totalement utopique : seul un plan (issus de cabinets de géomètres divers et variés) sur 10 se laissait parser sans segfault.
Je suppose que tu n'as pas un téléphone sous ARMv6, parce que tu as beaucoup de choses qui ne tournent pas dessus. Android doit être capable (merci de {con,in}firmer) de gérer des "fat binaries", mais n'empêche qu'il faut quand même compiler pour chaque archi CPU.
Je ne comprends pas pourquoi il n'a pas eu plus de succès que ça car de très nombreuses choses sont possibles avec ce moteur tout en étant multiplateforme.
C'est bête, mais pour une utilisation non-libre (ou simplement non-compatible GPL), il faut bidouiller. Et les bidouilles ont parfois comme conséquence de rendre le .blend accessible en clair, ce qui peut gêner pour le non-libre.
Le problème n'est pas tant lié aux licences qu'à l'état de LibreDWG : bien que prometteur, le projet est au point mort, et ne gère pas grand chose à l'heure actuelle (les trois quarts des fichiers que je manipule au boulot le font tout simplement planter).
Après, si un support efficace des fichiers DWG était codé dans une licence libre très permissive, rien n'empêcherait de supporter le DWG un peu partout.
Au passage, attention à tout ce qui traite de "OpenDWG" : en dépit de son nom, il s'agit d'un consortium visant à vendre des librairies closed-source (mais néanmoins multiplateformes) de gestion des fichiers DWG. Tous les logiciels propriétaires qui gèrent le DWG et ne sont pas le fait d'Autodesk passent par ces librairies, pour ce que j'en ai vu.
Il faut dire qu'ils ont pas de chance aussi, il y a trois semaines notre train était bloqué pour cause de, je cite « Objet de forage tombé sur la voie».
N'empêche que le propriétaire de la perceuse était inconsolable. Sans cœur, va!
Quand je fais un prêt pour acheter, une fois que je suis arrivé au bout, l'objet du prêt est à moi. C'est un fait.
Oui, mais dans quel état?
Si tu loues pour un montant suffisamment inférieur à tes loyers, tu arrives à la fin avec une capacité d'achat équivalente à la maison que tu aurais pu acheter, juste avec vingt ans de vétusté en moins.
Et dans 100€ de nourriture, quelle partie n'est pas en pure perte? Le fait d'avoir un toit au dessus de ta tête pendant un mois, c'est ça que tu payes 1000€. Si tu as eu un toit au dessus de ta tête pendant un mois, tes 1000€ ne sont pas en pure perte (du tout, même, tu as eu l'intégralité de ta prestation en face).
Et mes remboursements ne vont pas augmenter pendant le temps du prêt contrairement au loyer.
Non, par contre toutes les dépenses que tu fais/vas faire sur ton acquisition (travaux, taxe foncière) vont s'accumuler dans la balance, alors qu'elles auraient été à la charge du propriétaire autrement.
[^] # Re: La guerre des écosystèmes continue
Posté par Larry Cow . En réponse au journal Google Hangouts remplace Talk: la fin de la fédération XMPP ?. Évalué à 2.
Va pour le téléphone cellulaire, mais chez toute la jeune génération, le courriel est en train de mourir. De plus en plus de djeunz (comprendre "moins de 25 ans") donnent leur adresse @facebook.com quand on leur demande un email. Pour l'instant, ça fonctionne…
[^] # Re: La guerre des écosystèmes continue
Posté par Larry Cow . En réponse au journal Google Hangouts remplace Talk: la fin de la fédération XMPP ?. Évalué à 10.
On mélange allégrement deux choses ici. XMPP (le protocole) est prévu pour échange du XML entre plusieurs clients passant par un serveur, le tout fédéré (i.e. truc@bidule.com peut échanger avec machin@chose.net). Jabber, l'application de ce protocole à la messagerie instantanée, permet donc d'échanger des messages (du texte) entre plusieurs utilisateurs de plusieurs serveurs, mais toujours en passant par ces serveurs. Dans les deux cas, on a un protocole TCP bien défini, qui s'appuie sur des numéros de ports enregistrés à l'IANA, etc.
Des règles de sortie restrictives
Sauf que ces numéros de ports (5999 et compagnie) sont parfois bloqués en sortie dans les entreprises (et autres réseaux un peu coincés du QoS). C'est le premier problème de NAT qu'on peut imputer à Jabber, et qui est globalement réglé par les clients Web. Ces derniers existent depuis la fin des années 90, et fonctionnaient alors essentiellement côté serveur : un formulaire, qui envoie à du code serveur (PHP & co) les requêtes, qui les envoie à son tour au serveur XMPP (auprès duquel il s'est auparavant authentifié), et retour.
Tout cela était bien joli, mais avec la mode de l'AJAX, c'est devenu particulièrement pas sexy comme manière de faire. On a donc commencé à réfléchir à la meilleure manière d'établir la connexion au serveur XMPP directement depuis le code Javascript du client. Ce dernier étant habitué à manipuler du DOM (éventuellement XML), manipuler des messages XMPP n'aurait pas du lui faire trop peur. Sauf que Javascript dans un navigateur, ça ne sait pas trop se connecter à un protocole TCP quelconque. On a donc produit un certain nombre de contournements techniques, les deux plus récents (et intéressants) étant :
Concrètement un point d'entrée BoSH est une URL HTTP(S) standard, qui fait l'interface entre un serveur XMPP (la plupart permettent de servir directement cette URL, sinon il y a des proxies autonomes faciles à déployer) et le client Web. Évidemment, les problématiques de "cross origin" s'appliquent, on a donc intérêt à servir directement un point d'entrée BoSH sur le domaine qu'on héberge, si on le peut.
Les clients "lourds" ont sauté en marche de le "BoSH train", et certains peuvent effectivement se connecter via une URL BoSH, ce qui permet - mais l'intention initiale n'était pas là - de contourner les règles de sortie les plus restrictives.
Des connexions directes
Depuis qu'il est question de voix et de vidéo dans les outils de messagerie instantanée (et donc bien avant Skype), il est clair pour à peu près tout le monde que le modèle client->serveur->client n'est pas satisfaisant, pour des raisons de bande passante. On a donc depuis très longtemps (MSN le faisait déjà, de mémoire) fait en sorte que les clients soient capables de négocier (avec l'aide du serveur) un canal de communication direct. Chez XMPP, comme on n'aime pas faire les choses de manière inélégante, on a mis très (trop?) longtemps à produire une spec correcte, et c'est finalement Google qui a sorti tout le monde de l'ornière. Ils ont en effet défini une manière de faire (Jingle) pour GTalk, et ont soumis leur spec à l'organisme de standardisation d'XMPP. Je passe sur les allers-retours de la norme, sur le fait que GTalk a longtemps utilisé une version de Jingle qui n'était plus celle recommandée par XMPP… bref.
Dans les grandes lignes, Jingle permet à deux clients de :
L'ennui majeur ici, c'est que le cas où l'on doit passer par un proxy est beaucoup trop fréquent, et que placer cette charge sur une seule machine n'est pas raisonnable. Une solution supplémentaire a été trouvée (et est implémentée au moins par Jitsi et OneTeam) : Jingle Nodes. Dans Nodes, on pousse la logique un peu plus loin, et on permet à un client qui a les bonnes caractéristiques (en termes de NAT) de se comporter en proxy. On répartit ainsi la charge sur un maximum de machines/connexions.
Bon, aux dernières nouvelles, la spec est un peu morte.
[^] # Re: jabberd
Posté par Larry Cow . En réponse au journal Jabber et XMPP que sont-ils ?. Évalué à 4.
Pour ce que j'ai testé d'eJabberd, il permet d'utiliser une base externe pour l'authentification (perso, j'utilise plutôt LDAP, mais ce doit être possible avec Postgres). Au pire, il est capable de refiler l'authentification à un script externe (codé en n'importe quoi) : j'avais pu bricoler un script d'authentification unique avec Friendica, par ce biais.
[^] # Re: La guerre des écosystèmes continue
Posté par Larry Cow . En réponse au journal Google Hangouts remplace Talk: la fin de la fédération XMPP ?. Évalué à 5.
Sauf que Jingle, son boulot c'est pas tellement de gérer le binaire (on faisait du transfert de fichiers par XMPP bien avant Jingle, voire avant que Jabber ne devienne XMPP), mais bien de gérer les connexions directes entre clients. Que les dites connexions fassent ensuite passer du texte ou du binaire est un détail.
[^] # Re: prise en charge du protocole RDP
Posté par Larry Cow . En réponse à la dépêche X.Org est mort, vive Wayland ! (2). Évalué à 10.
C'est un poil plus compliqué que ça. En VNC, c'est effectivement ce qui se passe (le client demande au serveur une image, éventuellement restreinte à la zone qui a changé depuis la dernière requête, et basta). Par contre, RDP permettait - il me semble que c'était un de leurs arguments "de vente" - de mieux s'intégrer au framework graphique. Sous Windows en tous cas, il était censé encapsuler des appels aux bibliothèques graphiques (GDI?) pour éviter d'avoir à tout redessiner. En gros, l'appli dessinait un bouton côté serveur, et le côté client recevait juste les paramètres de dessin du dit bouton (et non sa représentation graphique).
Mais c'est loin et je peux me tromper.
[^] # Re: Le support Dell
Posté par Larry Cow . En réponse au journal Dell, le degré zéro du service client.. Évalué à 5.
En même temps, il n'y a pas grand chose de bénin à forte dose ;)
[^] # Re: Le support Dell
Posté par Larry Cow . En réponse au journal Dell, le degré zéro du service client.. Évalué à 5.
Par contre, une feuille de papier d'alu sur l'ensemble du PCB, trouée pour laisser visible juste la puce défectueuse, puis un bon coup de décapeur thermique à pleine puissance… j'ai été très surpris de voir une carte graphique d'ordi portable remarcher grâce à ça ;)
[^] # Re: Parisiens !
Posté par Larry Cow . En réponse au journal L'immobilier, c'était mieux avant !. Évalué à 3.
Manifestement, elle ne leur interdit pas de faire des conditions préférentielles aux clients qui n'utilisent pas ce droit.
[^] # Re: DWGet AutoCad
Posté par Larry Cow . En réponse à la dépêche FreeCAD 0.13. Évalué à 3.
Petite précision : le code embarqué c'est du VBA. Histoire de simplifier…
[^] # Re: Mozilla
Posté par Larry Cow . En réponse à la dépêche Une coalition de 27 organisations demande au W3C de garder les DRM hors du Web. Évalué à 10.
Il n'y a pas de mal. Tu viens de réaliser une Invocation Majeure de Tanguy Ortolo. Du grand art ;)
[^] # Re: DWGet AutoCad
Posté par Larry Cow . En réponse à la dépêche FreeCAD 0.13. Évalué à 5.
Si c'est un brevet, ça ne doit pas être un souci en Europe. Si c'est autre chose, je ne vois pas quoi.
Le souci, c'est que le format DWG est très touffu : plein de versions différentes, embarquent un langage de programmation, etc. Imagine de devoir réimplémenter une JVM sans avoir les specs : c'est un peu de ça qu'il s'agit. C'est pour ça que les gens qui n'ont pas besoin de publier leur source (et qui ont un peu de budget quand même) passent par OpenDWG.
Une option crédible, avant d'espérer une gestion native du DWG par des softs libres (ce que je crois très peu probable sans y mettre des moyens considérables, pour répondre à ta question), serait de construire un convertisseur DWG<->DXF correct. DXF compte au moins autant de version que DWG (chacune se déclinant en une représentation ASCII et une représentation binaire, le passage de l'une à l'autre étant théoriquement bijectif), mais il est documenté et - pour autant que je sache - n'est pas prévu pour embarquer de code. Et il est globalement censé pouvoir exprimer tout ce qu'on fichier DWG de même génération peut exprimer de manière déclarative (i.e. pas le code, donc).
Si je reviens sur LibreDWG - que j'ai suivi de près fut un temps, il avait été question de construire un très grosse suite de tests. Ce serait, à mon avis, la première étape avant d'aller plus loin : collecter (en continu) des fichiers DWG soigneusement étiquetés (version, type d'usage, etc.) et munis de rendus "intéropérables" pondus par AutoCAD et/ou un soft OpenDWG (un DXF + un PNG, par exemple).
L'usage que j'aurais pu en avoir était pourtant bien plus simple qu'un conversion : je voulais juste générer des aperçus de mes plans pour les intégrer dans un système type GED. J'eus même pu me contenter d'un aperçu textuel (i.e. un export des textes significatifs du DWG pour constitution d'un index plein-texte). Même cet usage était totalement utopique : seul un plan (issus de cabinets de géomètres divers et variés) sur 10 se laissait parser sans segfault.
# Rien de neuf
Posté par Larry Cow . En réponse au journal Armes Open-Sources ???. Évalué à 2.
Il y avait déjà des initiatives de ce type - le problème du métal en moins : http://www.kickstarter.com/projects/1803756771/trebuchette-the-snap-together-desktop-trebuchet
[^] # Re:Journal— Les Geeksphone Keon et Peak sont disponibles àlavente !
Posté par Larry Cow . En réponse au journal Les Geeksphone Keon et Peak sont disponibles à la vente !. Évalué à 3.
Je suppose que tu n'as pas un téléphone sous ARMv6, parce que tu as beaucoup de choses qui ne tournent pas dessus. Android doit être capable (merci de {con,in}firmer) de gérer des "fat binaries", mais n'empêche qu'il faut quand même compiler pour chaque archi CPU.
[^] # Re: On ne dit pas propriétaire, mais pwivateur!
Posté par Larry Cow . En réponse à la dépêche État des jeux sous Linux. Évalué à 3.
Tu as un début de réponse ici : http://wiki.blender.org/index.php/Doc:2.6/Manual/Game_Engine/Licensing
C'est bête, mais pour une utilisation non-libre (ou simplement non-compatible GPL), il faut bidouiller. Et les bidouilles ont parfois comme conséquence de rendre le .blend accessible en clair, ce qui peut gêner pour le non-libre.
[^] # Re: DWGet AutoCad
Posté par Larry Cow . En réponse à la dépêche FreeCAD 0.13. Évalué à 7.
Le problème n'est pas tant lié aux licences qu'à l'état de LibreDWG : bien que prometteur, le projet est au point mort, et ne gère pas grand chose à l'heure actuelle (les trois quarts des fichiers que je manipule au boulot le font tout simplement planter).
Après, si un support efficace des fichiers DWG était codé dans une licence libre très permissive, rien n'empêcherait de supporter le DWG un peu partout.
Au passage, attention à tout ce qui traite de "OpenDWG" : en dépit de son nom, il s'agit d'un consortium visant à vendre des librairies closed-source (mais néanmoins multiplateformes) de gestion des fichiers DWG. Tous les logiciels propriétaires qui gèrent le DWG et ne sont pas le fait d'Autodesk passent par ces librairies, pour ce que j'en ai vu.
[^] # Re: auto hébergement
Posté par Larry Cow . En réponse au journal tontoncloud, tentative d'auto-hébergement #pourlesnuls.. Évalué à 2.
Que tu sois fidèle à ta définition t'honore, mais ce n'est pas sur ça que la question se pose. Si?
[^] # Re: Bahn
Posté par Larry Cow . En réponse au journal Ça faisait longtemps : SNCF mon amour. Évalué à 4.
N'empêche que le propriétaire de la perceuse était inconsolable. Sans cœur, va!
[^] # Re: Gares parisiennes
Posté par Larry Cow . En réponse au journal Ça faisait longtemps : SNCF mon amour. Évalué à 4.
Notamment en cas de trop longue indisponibilité de la ressource. Un train peut rester bloqué une nuit, lui.
[^] # Re: auto hébergement
Posté par Larry Cow . En réponse au journal tontoncloud, tentative d'auto-hébergement #pourlesnuls.. Évalué à 1.
Devnewton dixit. Je suis certain qu'en face on a un autre avis, tout aussi valide.
[^] # Re: auto hébergement
Posté par Larry Cow . En réponse au journal tontoncloud, tentative d'auto-hébergement #pourlesnuls.. Évalué à 7.
Et apparemment, Zenitram pareil. Pour vous départager, je ne vois guère qu'une baston de pouces, à ce stade.
[^] # Re: C'est dommage, l'idée était belle.
Posté par Larry Cow . En réponse au journal envolée du cours de Bitcoin. Évalué à 1.
Oui, mais dans quel état?
Si tu loues pour un montant suffisamment inférieur à tes loyers, tu arrives à la fin avec une capacité d'achat équivalente à la maison que tu aurais pu acheter, juste avec vingt ans de vétusté en moins.
[^] # Re: C'est dommage, l'idée était belle.
Posté par Larry Cow . En réponse au journal envolée du cours de Bitcoin. Évalué à 8.
Et dans 100€ de nourriture, quelle partie n'est pas en pure perte? Le fait d'avoir un toit au dessus de ta tête pendant un mois, c'est ça que tu payes 1000€. Si tu as eu un toit au dessus de ta tête pendant un mois, tes 1000€ ne sont pas en pure perte (du tout, même, tu as eu l'intégralité de ta prestation en face).
[^] # Re: C'est dommage, l'idée était belle.
Posté par Larry Cow . En réponse au journal envolée du cours de Bitcoin. Évalué à 1.
Non, mais tu n'es pas obligé non plus de rester son locataire.
Quand tu es propriétaire, si tu n'empêche pas ton logement de devenir insalubre, tu vis dans un logement insalubre.
[^] # Re: C'est dommage, l'idée était belle.
Posté par Larry Cow . En réponse au journal envolée du cours de Bitcoin. Évalué à 1.
Non, par contre toutes les dépenses que tu fais/vas faire sur ton acquisition (travaux, taxe foncière) vont s'accumuler dans la balance, alors qu'elles auraient été à la charge du propriétaire autrement.
[^] # Re: C'est dommage, l'idée était belle.
Posté par Larry Cow . En réponse au journal envolée du cours de Bitcoin. Évalué à 1.
Il n'a clairement pas écrit que ça ne servait à rien d'acheter, juste que ce n'était pas la seule option, ni une obligation.