A noter la nouvelle fonctionnalité de mercurial : les phases, qui permettent d'avoir des changesets "secrets" tant qu'ils ne sont pas publiés, et donc de faire du rebase dessus sans danger (si j'ai bien compris car je n'ai pas encore essayé).
il est difficile de rentrer dans le code de PyPy (touffu, très peu documenté ni commenté, y compris RPython lui-même)
le système de build peut rendre fou (traduire l'interpréteur en code natif prend 30 à 60 minutes, et il n'y a pas de traduction incrémentale)
Ce sont ces points qui mériteraient un appel au don car ils ne seront jamais faits gratuitement contrairement à des choses plus motivantes... Ca rendrait pypy plus pérenne, les boites qui l'utilisent aujourd'hui y seraient sûrement sensibles.
C'est quitte ou double. Le risque c'est qu'un langage qui n'évolue plus sera moins sujet à être maintenu qu'un langage qui évolue. C'est une histoire d'équilibre, un langage qui évolue lentement et donc facile à suivre ou un langage qui n'évolue plus et qui risque de devenir obsolète brutalement.
The goal of this project is to write an interpreter that interprets version 3 of the Python language. To be precise we would aim at having a Python 3.2 interpreter together in the same codebase as the python 2.7 one.
At the end of the project, it will be possible to decide at translation time whether to build an interpreter which supports Python 2.7 or Python 3.2 and both versions will be nightly tested and available from nightly builds.
Python en lui-même n'a aucune date de péremption, c'est un logiciel libre, tu as les sources, qu'est-ce qui pourrait t'empêcher de le faire tourner, lui et les applis développées avec, dans 50 ans ? Si quelque chose t'en empêche ce sera les composants du système, les librairies en C qu'il utilise etc. Mais pas le langage lui-même.
Pour ce qui est du courage des développeurs pour suivre les upgrades du langage, rassure toi c'est trivial dans la grande majorité des cas. Surtout, c'est ridicule par rapport aux problèmes de compatibilités extérieurs (libs, système, bdd, utilisateurs...)
Je suis tout à fait d'accord, tout ce que l'on peut vérifier automatiquement est toujours bénéfique, si j'ai bien compris dialyzer est un peu l'équivalent de pylint ?
Je n'apprécie pas quand c'est au détriment de la lisibilité du code ou que cela m'empêche de profiter du côté dynamique du langage. Pour revenir au langage idéal, qu'il devine tout seul les erreurs de type quand il le peu et ce sera très bien mais qu'il ne m'oblige pas à lui mâcher le travail. Je ne me plaint pas que python sache vérifier la syntaxe avant l'exécution (j'utilise vimflakes par ex).
Je n'ai pas d'historique de code qui me vient comme ça à montrer (je ne fais que du dev spécifique), mais j'ai regardé, honnêtement j'ai quelques cas d'erreurs de types qui reviennent, string/unicode et float/Decimal. Mais même dans ces cas bien souvent le compilateur n'aurait rien vu car les données arrivent d'un sgbd...
Pour ce qui est de projets réels, professionnellement je suis passé par C et Java avant Python, et au début je n'y croyait pas non plus, mais maintenant, sur plusieurs années, sur parfois des programmes exactement identiques (réécrits), le temps de maintenance est drastiquement réduit. Pour mon usage c'est le langage idéal.
Par contre si ce n'était pas pour le boulot et donc des contraintes de rendement, je préfèrerai le C pour son côté plus proche du système.
Un système de typage statique réaliste ne capturera pas tous les invariants de ton programme, mais ce n'est pas une raison pour les rejeter en bloc, s'il peut déjà capturer les invariants "faciles" et te laisser raisonner sans aide, ou vérifier dynamiquement, les autres, c'est déjà ça.
Sauf que les invariants "faciles", ceux qui sont détectés à notre place, sont rarement ceux qui posent problème. Du reste c'est plus pour aider le compilateur que le développeur, sinon on obligerait à nommer les arguments en appel de fonction par exemple c'est une erreur beaucoup plus commune et qui passe tranquillement la compilation.
Par ex ma_fonction(int a, int b), si on inverse a et b le compilateur n'y verra rien. Si a est censé être plus petit que b il n'y verra rien non plus. En python si on applique la règle d'être explicite on écrira ma_fonction(plus_petit, plus_grand) et on appellera toujours en nommant les paramètres ma_fonction(plus_petit=.., plus_grand=...), c'est beaucoup plus sûr et surtout ça s'adresse au développeur, pas au compilateur. Le compilateur lui il se débrouille très bien tout seul, il n'y a qu'à voir les prouesses de pypy.
C'est important les humains qui changent les api justement...
L'upgrade est un problème quand le rapport difficulté/gain n'est pas bon. Hors il dépend intimement du langage. En python par exemple, faire évoluer un programme est à a fois facile et apporte beaucoup. Les problèmes de compatibilités sont donc largement amortis. En revanche avec un langage beaucoup plus difficile à faire évoluer effectivement le ratio n'est pas toujours bon on a beaucoup plus intérêt à ne pas casser la compatibilité ascendante.
Concrètement les programmes en C que j'ai écris il y a 20 ans ils seront sûrement compilable sans rien changer, mais de toutes façons de fait je ne les compile plus et je ne les réutilise pas non plus. En revanche les programmes en python que j'ai écris il y a 8 ans ils ont évolués tous les ans, malgré les pertes de compatibilité je les utilise toujours.
Bref, il ne faut pas prendre en compte que la compatibilité d'un code avec le langage mais aussi la compatibilité d'un code avec soit-même ;-)
On parle d'auto-hébergement quand la personne (physique ou morale) gère elle-même le fonctionnement au jour le jour d'une infrastructure qui est dans le même bâtiment qu'elle
On dit quoi quand la personne gère elle-même le fonctionnement mais pas forcément dans le même bâtiment ? Parce que c'est quand même le sujet... Sauf erreur, Denis parle d'exim vs gmail, pas tant d'exim sur adsl vs gmail.
On peut facilement passer d'un hébergement adsl vers un hébergement dédié si on a des soucis de disponibilité matériel, sans pour autant remettre en cause ce qui nous concerne avant tout, la partir logiciel. Comme la partie logicielle est facilement redondante et cryptable le soucis des données est bien moindre.
On a bien compris, pour toi les mails ne sont plus ton affaire, tu les sous-traite à un prestataire de service, comme tu prendrai un taxi au lieu de ta voiture que tu répare toi-même. Et donc tu te fout pas mal de savoir si la voiture du taxi est réparable ou pas ni si le chauffeur note dans son carnet où tu te rends et à quelle heure. Mais dans ce cas ce qu'on ne voit pas c'est qu'est-ce que ça peut bien faire dans un journal qui traite de la mécanique à faire soit-même ?
Si on trouve que gérer ses mails soit-même est une perte de temps, on ne va perdre son temps à lire des journaux comme linux mag non plus. Lorsqu'on fait le choix de gérer ses mails généralement c'est qu'on a une bonne raison. Le temps et la difficulté sont secondaires dans ce cas.
On n'est pas bloqué et il n'y a pas de surprise vu que la version 2 est encore maintenue et pour pas mal de temps encore...
Du reste, dans la plupart des cas la migration sera triviale, le seul problème c'est les librairies et ça c'est valable pour tous les langages même s'ils ne changent pas eux-même...
La pérennité du code c'est valable dans une bulle, et dans ce cas peu importe si le langage évolue ou pas...
Il faut plutôt se demander pourquoi un logiciel serait non libre. Quel est l'intérêt d'un logiciel non libre ? Le projet GNU a démarré parce que Richard a demandé un bout de code à un copain et que pour la première fois il le lui a refusé.
Aujourd'hui on peut changer la roue de son vélo tout seul et on peut s'échanger des recettes de cuisine, si demain on m'empêche de le faire, je vais râler, est-ce que j'ai besoin de me justifier ? de m'appuyer sur une philosophie ? de savoir peser le pour et le contre de telle variation ?
Donc le mois prochain tu nous fais un gros titre "Comment se débarrasser de gmail" et t'es pardonné. Sinon on appelle nos potes anonymous et on t'inonde de mails 8-D
Tu veux dire que Denis, non seulement ne se serait pas aperçu qu'en comparant Exim à Gmail il comparait un moteur avec une carrosserie mais qu'en plus il ne se serait pas aperçu qu'il lançait un énorme troll ?
Vu la qualité de ce qu'il a déjà fait auparavant, il sait très bien ce qu'il fait, et c'est justement ça qui est choquant. Qu'un admin cède à la facilité au détriment de ses convictions, c'est humain, mais qu'il s'en vante et incite les autres à faire pareil c'est pitoyable.
L'abattement forfaitaire de 34% identique pour tous, faut avouer ça nous arrange particulièrement (nous informaticiens)... Pour d'autres professions les frais sont généralement énormes la première année (le matériel) sans pour autant justifier d'être au réel (surtout la première année)...
A l'époque du forfait on ne jouait pas forcément la bidouille. Le truc c'est que les impôts avaient l'habitude des professions courantes mais pas des nôtres, donc il trouvait nos frais ridicules, c'est pour ça que ce n'était pas difficile de faire baisser les bénéfices.
J'ai bien vu que le CFE était calculé d'une étrange manière. Ce que je voulais rappeler c'est qu'avant ce statut celui qui ne touchait rien c'était plus proche de 3500 € que 350 € !
En tout cas aujourd'hui, AE + logiciel libre c'est vraiment le duo gagnant pour démarrer. Profitez-en !
L'AE ne paye pas ce qu'il doit justement puisqu'il n'y a aucune prise en compte des frais, le pourcentage est encore plus arbitraire... Au forfait il y avait au moins une chance.
La CFE c'est peanuts par rapport à ce qu'était le plancher de charges.
Les ptits jeunes, peut-être n'avez-vous pas connu le régime du "forfait", "c'était mieux avant"tm, voilà comment ça se passait concrètement. Une fois par an je prenais rendez-vous avec l'inspecteur des impôts, je lui montrai combien j'avais gagné dans l'année, je lui disais si j'avais fait des dépenses particulières et ensemble on définissait un bénéfice à la louche ! Mais alors une louche, une vraie, parfois le résultat frisait avec le zéro alors que je vivais (modestement) de ça !
Mais mais mais, il n'y avait pas le statut AE, du coup un plancher s'appliquait aux charges, assez dissuasif pour démarrer.
Pour tes frais oui, c'est bien de récupérer la tva...
J'ai vu sur ton blog que tu conseillais la tva simplifiée, je ne trouve pas que ça soit si simplifié que ça, il faut verser des acomptes et c'est régularisé à la fin de l'année, si on n'a pas des revenus très réguliers d'une année sur l'autre on est en déséquilibre... En revanche à la tva réelle on paye tous les mois sur les opérations du mois, c'est beaucoup plus simple, ça se rapproche même plus du statut AE, le formulaire à remplir est vraiment simple.
D'après un ami contrôleur d'assurance. Pour les autodidactes, et je pense qu'on n'est nombreux dans ce cas autour des LL, en cas de pépin important on sera toujours considéré comme fautif d'avoir fait une prestation dont on n'a pas les compétences (pas le diplôme)... Les licences libres sont bien pour ça car elles dégagent entièrement la responsabilité du développeur. Il faut facturer la "mise à disposition" et non pas la "mise en place" par ex. Pour de l'admin sys c'est plus difficile, c'est une bonne idée de faire payer le client directement au fournisseur mais ça n'est vraiment pas pratique...
[^] # Re: Yep!
Posté par wilk . En réponse à la dépêche Fossil, une forge pour DVCS. Évalué à 3.
A noter la nouvelle fonctionnalité de mercurial : les phases, qui permettent d'avoir des changesets "secrets" tant qu'ils ne sont pas publiés, et donc de faire du rebase dessus sans danger (si j'ai bien compris car je n'ai pas encore essayé).
http://www.logilab.org/blogentry/88203
[^] # Re: Pourquoi un enième interpréteur ?
Posté par wilk . En réponse au journal Appel au dons pour PyPy. Évalué à 2.
Si on ne réinventait pas la roue de temps en temps on aurait des roues en bois sur les vélos ;-)
[^] # Re: Portage de Numpy
Posté par wilk . En réponse au journal Appel au dons pour PyPy. Évalué à 1.
Ce sont ces points qui mériteraient un appel au don car ils ne seront jamais faits gratuitement contrairement à des choses plus motivantes... Ca rendrait pypy plus pérenne, les boites qui l'utilisent aujourd'hui y seraient sûrement sensibles.
[^] # Re: NOOONNNN!!!....
Posté par wilk . En réponse au journal Prévision de gel ... pour Debian Wheezy ... et quelques détails sur le manchot au nœud papillon . Évalué à 3.
D'un autre côté, plus les releases sont fréquentes moins il y a de boulot à faire lors des upgrades...
[^] # Re: Mes idéaux
Posté par wilk . En réponse au journal Votre langage idéal ?. Évalué à 1.
C'est surtout les ABI-tudes des utilisateurs qui ne respectent pas la compatibilité ascendante !
[^] # Re: Mes idéaux
Posté par wilk . En réponse au journal Votre langage idéal ?. Évalué à 0.
C'est quitte ou double. Le risque c'est qu'un langage qui n'évolue plus sera moins sujet à être maintenu qu'un langage qui évolue. C'est une histoire d'équilibre, un langage qui évolue lentement et donc facile à suivre ou un langage qui n'évolue plus et qui risque de devenir obsolète brutalement.
[^] # Re: Mes idéaux
Posté par wilk . En réponse au journal Votre langage idéal ?. Évalué à 1.
Pour pypy, la question est posée de supporter à la fois la 2 et la 3 sur la même base de code.
http://pypy.org/py3donate.html
[^] # Re: Mes idéaux
Posté par wilk . En réponse au journal Votre langage idéal ?. Évalué à 1.
Python en lui-même n'a aucune date de péremption, c'est un logiciel libre, tu as les sources, qu'est-ce qui pourrait t'empêcher de le faire tourner, lui et les applis développées avec, dans 50 ans ? Si quelque chose t'en empêche ce sera les composants du système, les librairies en C qu'il utilise etc. Mais pas le langage lui-même.
Pour ce qui est du courage des développeurs pour suivre les upgrades du langage, rassure toi c'est trivial dans la grande majorité des cas. Surtout, c'est ridicule par rapport aux problèmes de compatibilités extérieurs (libs, système, bdd, utilisateurs...)
[^] # Re: J'aimerais
Posté par wilk . En réponse au journal Votre langage idéal ?. Évalué à 3.
Je suis tout à fait d'accord, tout ce que l'on peut vérifier automatiquement est toujours bénéfique, si j'ai bien compris dialyzer est un peu l'équivalent de pylint ?
Je n'apprécie pas quand c'est au détriment de la lisibilité du code ou que cela m'empêche de profiter du côté dynamique du langage. Pour revenir au langage idéal, qu'il devine tout seul les erreurs de type quand il le peu et ce sera très bien mais qu'il ne m'oblige pas à lui mâcher le travail. Je ne me plaint pas que python sache vérifier la syntaxe avant l'exécution (j'utilise vimflakes par ex).
Je n'ai pas d'historique de code qui me vient comme ça à montrer (je ne fais que du dev spécifique), mais j'ai regardé, honnêtement j'ai quelques cas d'erreurs de types qui reviennent, string/unicode et float/Decimal. Mais même dans ces cas bien souvent le compilateur n'aurait rien vu car les données arrivent d'un sgbd...
Pour ce qui est de projets réels, professionnellement je suis passé par C et Java avant Python, et au début je n'y croyait pas non plus, mais maintenant, sur plusieurs années, sur parfois des programmes exactement identiques (réécrits), le temps de maintenance est drastiquement réduit. Pour mon usage c'est le langage idéal.
Par contre si ce n'était pas pour le boulot et donc des contraintes de rendement, je préfèrerai le C pour son côté plus proche du système.
[^] # Re: à ce point là ?
Posté par wilk . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 3.
En l'occurrence ils se mettent à dire ce qu'ils ne font plus avec GNU/Linux !
[^] # Re: J'aimerais
Posté par wilk . En réponse au journal Votre langage idéal ?. Évalué à 4.
Tu as essayé pypy ?
Sur un algo de calcul d'itinéraires j'ai un gain d'un facteur 10 !
[^] # Re: J'aimerais
Posté par wilk . En réponse au journal Votre langage idéal ?. Évalué à 1.
Sauf que les invariants "faciles", ceux qui sont détectés à notre place, sont rarement ceux qui posent problème. Du reste c'est plus pour aider le compilateur que le développeur, sinon on obligerait à nommer les arguments en appel de fonction par exemple c'est une erreur beaucoup plus commune et qui passe tranquillement la compilation.
Par ex ma_fonction(int a, int b), si on inverse a et b le compilateur n'y verra rien. Si a est censé être plus petit que b il n'y verra rien non plus. En python si on applique la règle d'être explicite on écrira ma_fonction(plus_petit, plus_grand) et on appellera toujours en nommant les paramètres ma_fonction(plus_petit=.., plus_grand=...), c'est beaucoup plus sûr et surtout ça s'adresse au développeur, pas au compilateur. Le compilateur lui il se débrouille très bien tout seul, il n'y a qu'à voir les prouesses de pypy.
[^] # Re: Mes idéaux
Posté par wilk . En réponse au journal Votre langage idéal ?. Évalué à 3.
C'est important les humains qui changent les api justement...
L'upgrade est un problème quand le rapport difficulté/gain n'est pas bon. Hors il dépend intimement du langage. En python par exemple, faire évoluer un programme est à a fois facile et apporte beaucoup. Les problèmes de compatibilités sont donc largement amortis. En revanche avec un langage beaucoup plus difficile à faire évoluer effectivement le ratio n'est pas toujours bon on a beaucoup plus intérêt à ne pas casser la compatibilité ascendante.
Concrètement les programmes en C que j'ai écris il y a 20 ans ils seront sûrement compilable sans rien changer, mais de toutes façons de fait je ne les compile plus et je ne les réutilise pas non plus. En revanche les programmes en python que j'ai écris il y a 8 ans ils ont évolués tous les ans, malgré les pertes de compatibilité je les utilise toujours.
Bref, il ne faut pas prendre en compte que la compatibilité d'un code avec le langage mais aussi la compatibilité d'un code avec soit-même ;-)
[^] # Re: à ce point là ?
Posté par wilk . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 3.
On dit quoi quand la personne gère elle-même le fonctionnement mais pas forcément dans le même bâtiment ? Parce que c'est quand même le sujet... Sauf erreur, Denis parle d'exim vs gmail, pas tant d'exim sur adsl vs gmail.
On peut facilement passer d'un hébergement adsl vers un hébergement dédié si on a des soucis de disponibilité matériel, sans pour autant remettre en cause ce qui nous concerne avant tout, la partir logiciel. Comme la partie logicielle est facilement redondante et cryptable le soucis des données est bien moindre.
[^] # Re: Pourquoi ?
Posté par wilk . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 8. Dernière modification le 29 janvier 2012 à 10:34.
On a bien compris, pour toi les mails ne sont plus ton affaire, tu les sous-traite à un prestataire de service, comme tu prendrai un taxi au lieu de ta voiture que tu répare toi-même. Et donc tu te fout pas mal de savoir si la voiture du taxi est réparable ou pas ni si le chauffeur note dans son carnet où tu te rends et à quelle heure. Mais dans ce cas ce qu'on ne voit pas c'est qu'est-ce que ça peut bien faire dans un journal qui traite de la mécanique à faire soit-même ?
Si on trouve que gérer ses mails soit-même est une perte de temps, on ne va perdre son temps à lire des journaux comme linux mag non plus. Lorsqu'on fait le choix de gérer ses mails généralement c'est qu'on a une bonne raison. Le temps et la difficulté sont secondaires dans ce cas.
[^] # Re: Mes idéaux
Posté par wilk . En réponse au journal Votre langage idéal ?. Évalué à 3.
On n'est pas bloqué et il n'y a pas de surprise vu que la version 2 est encore maintenue et pour pas mal de temps encore...
Du reste, dans la plupart des cas la migration sera triviale, le seul problème c'est les librairies et ça c'est valable pour tous les langages même s'ils ne changent pas eux-même...
La pérennité du code c'est valable dans une bulle, et dans ce cas peu importe si le langage évolue ou pas...
[^] # Re: Pourquoi ?
Posté par wilk . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 6.
Il faut plutôt se demander pourquoi un logiciel serait non libre. Quel est l'intérêt d'un logiciel non libre ? Le projet GNU a démarré parce que Richard a demandé un bout de code à un copain et que pour la première fois il le lui a refusé.
Aujourd'hui on peut changer la roue de son vélo tout seul et on peut s'échanger des recettes de cuisine, si demain on m'empêche de le faire, je vais râler, est-ce que j'ai besoin de me justifier ? de m'appuyer sur une philosophie ? de savoir peser le pour et le contre de telle variation ?
[^] # Re: Une déception de plus...
Posté par wilk . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 3.
Donc le mois prochain tu nous fais un gros titre "Comment se débarrasser de gmail" et t'es pardonné. Sinon on appelle nos potes anonymous et on t'inonde de mails 8-D
[^] # Re: Deux combats
Posté par wilk . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 6.
Tu veux dire que Denis, non seulement ne se serait pas aperçu qu'en comparant Exim à Gmail il comparait un moteur avec une carrosserie mais qu'en plus il ne se serait pas aperçu qu'il lançait un énorme troll ?
Vu la qualité de ce qu'il a déjà fait auparavant, il sait très bien ce qu'il fait, et c'est justement ça qui est choquant. Qu'un admin cède à la facilité au détriment de ses convictions, c'est humain, mais qu'il s'en vante et incite les autres à faire pareil c'est pitoyable.
[^] # Re: En couverture ?
Posté par wilk . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 4.
Il faudrait mettre ce journal en dépêche pour faire contre-poids !
[^] # Re: Nostalgie du forfait
Posté par wilk . En réponse à la dépêche Création d'entreprise : entretien avec personneAnonymisee, admin système en auto-entreprise. Évalué à 1.
L'abattement forfaitaire de 34% identique pour tous, faut avouer ça nous arrange particulièrement (nous informaticiens)... Pour d'autres professions les frais sont généralement énormes la première année (le matériel) sans pour autant justifier d'être au réel (surtout la première année)...
A l'époque du forfait on ne jouait pas forcément la bidouille. Le truc c'est que les impôts avaient l'habitude des professions courantes mais pas des nôtres, donc il trouvait nos frais ridicules, c'est pour ça que ce n'était pas difficile de faire baisser les bénéfices.
J'ai bien vu que le CFE était calculé d'une étrange manière. Ce que je voulais rappeler c'est qu'avant ce statut celui qui ne touchait rien c'était plus proche de 3500 € que 350 € !
En tout cas aujourd'hui, AE + logiciel libre c'est vraiment le duo gagnant pour démarrer. Profitez-en !
[^] # Re: Nostalgie du forfait
Posté par wilk . En réponse à la dépêche Création d'entreprise : entretien avec personneAnonymisee, admin système en auto-entreprise. Évalué à 1.
L'AE ne paye pas ce qu'il doit justement puisqu'il n'y a aucune prise en compte des frais, le pourcentage est encore plus arbitraire... Au forfait il y avait au moins une chance.
La CFE c'est peanuts par rapport à ce qu'était le plancher de charges.
# Nostalgie du forfait
Posté par wilk . En réponse à la dépêche Création d'entreprise : entretien avec personneAnonymisee, admin système en auto-entreprise. Évalué à 2.
Les ptits jeunes, peut-être n'avez-vous pas connu le régime du "forfait", "c'était mieux avant"tm, voilà comment ça se passait concrètement. Une fois par an je prenais rendez-vous avec l'inspecteur des impôts, je lui montrai combien j'avais gagné dans l'année, je lui disais si j'avais fait des dépenses particulières et ensemble on définissait un bénéfice à la louche ! Mais alors une louche, une vraie, parfois le résultat frisait avec le zéro alors que je vivais (modestement) de ça !
Mais mais mais, il n'y avait pas le statut AE, du coup un plancher s'appliquait aux charges, assez dissuasif pour démarrer.
[^] # Re: Petites questions
Posté par wilk . En réponse à la dépêche Création d'entreprise : entretien avec personneAnonymisee, admin système en auto-entreprise. Évalué à 1.
Pour tes frais oui, c'est bien de récupérer la tva...
J'ai vu sur ton blog que tu conseillais la tva simplifiée, je ne trouve pas que ça soit si simplifié que ça, il faut verser des acomptes et c'est régularisé à la fin de l'année, si on n'a pas des revenus très réguliers d'une année sur l'autre on est en déséquilibre... En revanche à la tva réelle on paye tous les mois sur les opérations du mois, c'est beaucoup plus simple, ça se rapproche même plus du statut AE, le formulaire à remplir est vraiment simple.
[^] # Re: Question assurance professionnelle
Posté par wilk . En réponse à la dépêche Création d'entreprise : entretien avec personneAnonymisee, admin système en auto-entreprise. Évalué à 1.
D'après un ami contrôleur d'assurance. Pour les autodidactes, et je pense qu'on n'est nombreux dans ce cas autour des LL, en cas de pépin important on sera toujours considéré comme fautif d'avoir fait une prestation dont on n'a pas les compétences (pas le diplôme)... Les licences libres sont bien pour ça car elles dégagent entièrement la responsabilité du développeur. Il faut facturer la "mise à disposition" et non pas la "mise en place" par ex. Pour de l'admin sys c'est plus difficile, c'est une bonne idée de faire payer le client directement au fournisseur mais ça n'est vraiment pas pratique...