J'aime bien ce côté "rien a foutre des standards" de nos institutions.
Vive les langages SAS et M, ouvrons nos esprits à ces langages, voyons!
Une réécriture en BF financée par nos impôts s'impose…
Evidemment nous certifierons le logiciel, les modifications techniques ne sont pas énormes.
Nous communiquerons dessus plus tard, car les échéances sont lointaines et avons bien d'autres choses à développer pour l'instant.
Super logiciel, bravo. NanoKontrol2 opérationnel en moins de 2 minutes!
Ni connaissant rien en DJ'ing, je peux juste dire que l'ensemble est vraiment bien fini, intuitif et amusant à prendre en main.
Qu'est ce que c'est que cette interface graphique?
Elle piétine les standards dans les grandes largeurs!
Difficile de trouver icônes plus moche,
les layouts sont plus qu'étranges,
et le look and feel natif même pas activé ( Tips: UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); )
Merci d'utiliser des SwingWorker pour ne pas bloquer la thread principale de Swing.
Oui, exact. Ajout et suppression doivent être interdit par le logiciel.
Mon propos est justement lié au logiciel, on ne peut à mon sens n'imposer à l'éditeur d'un logiciel que des choses relatives au logiciel, pas relatives à l'utilisateur.
Petit parallèle avec les armes pour changer d'optique:
Est ce que l'on met en prison les fabricants de couteaux quand certains font de la boucherie humaine?
Non, évidement.
Dans la même logique, on ne doit pas impliquer l'éditeur à l'utilisation frauduleuse de son logiciel.
Et tout comme il est interdit de créer des bombes atomiques, un éditeur de logiciel doit être lourdement sanctionné s'il intègre des fonctionnalités de fraude.
Bon allez… il est temps pour moi d’arrêter de commenter à tout va, c'est bien sympathique d'échanger ici, mais ça n'aura aucun effet sur le vote du projet de loi, ni sur la fraude.
Ce ne fait que du temps en moins à consacrer à des sujets plus constructifs, passionnants et loin de la bêtises législative qui au fil du temps déresponsabilise la majorité, démoralise les créateurs et grignote les libertés.
Oui.
Le seul "hic" vient du fait que la première transaction n'a pas de transaction précédente ;)
Plus généralement, pour modifier" ni vu ni connu" la n-eme transaction, il suffit d’effacer toutes les suivantes au passage et de les recréer.
Le problème n'est pas tant au niveau des coût pour "nous" les éditeurs, mais surtout pour les entreprises en général… Le coût de la certification n'est rien par rapport aux centaines de millions d'euros que va coûter en temps/prestations/licences, une mesure inefficace et facilement contournable (cf mes autres posts).
Pour ceux qui n'aurez pas vu passé l'info, au sujet de la norme NF 525, rien que l'obtention des règles de certification est payant (500€)… mais peut être doit on déjà se réjouir que la consultation du projet de loi est gratuite. J'ai personnellement du mal à me faire à cette société qui pense régler les problèmes de fond par des taxes, des normes, des interdictions…
L'administration détruit déjà assez d'entreprises comme cela, si l'on peut éviter de plomber encore un peu plus l'économie, faisons le. Je reste persuadé, que l'état ne récupérera que des miettes de ce qu'il pense récupérer sur les ventes "masquées", tout comme Hadopi a freiné le piratage.
Il y a d'autres moyens de faire "ce que vous pensez que l'administration fiscale veut", si tenté que votre interprétation soit celle des auteurs de la chose.
Pour ce qui est du module autonome, la loi n'en parle pas, elle parle de logiciel (donc l'ensemble).
Si c'était le cas, la loi ressemblerait plutôt à cela:
"Tout logiciel de gestion, de comptabilité, de caisse ou d'encaissement a l'obligation légale d'empêcher toute suppression d'écritures comptable par l'utilisateur. L'administration fiscale s'autorise en cas de doute avéré de procéder à un audit du code source fournit par l'éditeur."
Le raisonnement est valable pour une voiture, pas pour un logiciel de gestion / ERP.
On impose pas à une voiture de 2010 de respecter les normes de 2015.
La législation fiscale évolue sans cesse, récemment il a fallut ajouter l'export FEC, pour bientôt la DSN…
En gros, pour avoir un logiciel dans les clous, il faut le mettre à jour chaque année.
Dans un ERP, vu que tout est unifié et adapté à l'entreprise, il y a quasiment un logiciel par entreprise.
Bref, pour nous (OpenConcerto), il va falloir "faire certifier" ou "auto certifier" de nombreuses versions, même si la partie qui traite les encaissements est commune. Il nous faudra aussi mettre en place des systèmes pour garantir que le logiciel installé correspond au code source associé.
Cela prendra du temps, comprendre de l'argent, l'argent provenant des clients, mécaniquement ça va coûter aux utilisateurs.
Juste en temps, mettre à jour 3 millions de logiciels (dans l’hypothèse ou les 3 millions d'entreprises française vont utiliser un logiciel de gestion à jour…), cela prendre 3 millions d'heures de travail inutile MINIMUM (soit 342 années de vie).
De plus, l’efficacité contre la fraude sera nulle.
Qui voudra frauder, trouvera comment. Il ne faut pas être très calé pour comprendre qu'utiliser un autre logiciel en parallèle suffira ou encore, tout simplement, ne pas comptabiliser ce que l'on ne veut pas déclarer…
Niveau fraude côté éditeur, les cas avérés sont des logiciels propriétaires. Avec un logiciel libre, c'est plus difficile de cacher une fonctionnalité "de bricolage" car le code est accessible.
Obliger tout éditeur à donner accès au code source de son logiciel pour contrôle, cela serait une loi plus pertinente.
```
Depuis quand il faut des accords pour générer des fichiers SEPA ????
Pour l'interface avec les banques, il y a EBICS, pas besoin d'accord non plus… le client paye son accès.
3 millions d'entreprises…
Valorisez le temps à passer, les licences, les prestations… on dépasse le milliard d'euros pour un résultat sur la fraude qui sera à la hauteur d'Hadopi ;)
Avec OpenConcerto, on a plus de 200 000 entrepreneurs qui seraient potentiellement ravis d'envoyer un petit email ou appeler nos chers responsables…
Il manque un point important, c'est l'impact économique de cette loi sur l'ensemble des entreprises, logiciels libres ou pas.
En effet, tout le monde devra passer à des nouvelles versions de logiciels "inaltérables", c'est-à-dire passer à la caisse d'une façon ou d'une autre. Même avec des logiciels libres, cela ne se fera pas à coût zéro (temps, prestations diverses…).
Les amateurs d'Excel ou Libre/OpenOffice devront apprendre à s'en séparer.
Il serait de bon ton de partager numéro de téléphone ou email de ces chers "responsables" à la tête du projet.
Il y a des centaines d'entrepreneurs qui seraient heureux de leur envoyer leur avis et quelques éditeurs comme nous (OpenConcerto) de leur expliquer l'inefficacité de leur projet et l'impact sur nous et les entreprises en général.
La valeur ajoutée tourne autours du travail des personnes qui ont réalisé ce système prêt à l'emploi.
Cela devient usant de voir le manque de respect de certains vis à vis du travail fait dans le milieu du logiciel libre.
J'aime beaucoup la façon que tu as de prêter aux autres des propos qu'ils n'ont pas, le tout pour dénigrer des stéréotypes.
Où as tu vu que je revendique que personne ne veut m'écouter?
Est ce que ce projet de loi s'attaque aux causes? Non.
Est ce que ce projet de loi va empêcher la fraude? Non.
Est ce qu'il faut lutter contre la fraude? Oui.
Tu considères que ce projet de loi est une bonne chose et qu'il va remettre dans le droit de chemin les fraudeurs, très bien. Je respecte ce point de vu, même si à part dire qu'il ne faut pas se poser de questions, tu refuses toute discussion argumentée.
SI l'on considère qu'un fraudeur trouvera toujours un moyen de frauder, je ne sais pas comment on peut conclure que ce projet loi va être utile (hormis imposer des coûts supplémentaires aux honnêtes gens et balancer des amendes aux non fraudeurs qui n'auraient pas acquis un logiciel certifié).
Pour nos voitures, on y vient doucement : traceurs, système eCall, firmware des composants cryptés… on parle même de pouvoir arrêter les véhicules à distance…
Je ne peux que souhaiter que tu ais raison et que tout cela se limite par une liste de fournisseurs certifiés. Certification non pas basée sur leur "cotisations" mais basée sur la réalité du fonctionnement.
C'est un début de solution mais techniquement, il reste des difficultés :
- la base de données : comment empêcher toute manipulation de la base par un logiciel tier?
La crypter? Dans ce cas, le logiciel certifié contient la clef. Avec un peu de persévérance, on la récupère et le tour est joué.
- la couche graphique : si la couche graphique est modifiée pour ne pas se servir de l'API certifiée, tout est falsifiable par détournement.
Certifier la couche graphique? Dans ce cas, il y a nécessité de re-certifier le tout à chaque modification, optimisation, correction de bugs…
Bref, il n'y a aucune incompatibilité dedans, si ce n'est des fantasmes. Surtout que la problématique existe depuis longtemps, pourquoi se focaliser sur ce projet de loi en particulier ?
Il n'y a rien de particulier à cette loi, elle est dans la logique actuelle qui est de ne jamais adresser aux causes mais utiliser tout ce que l'on peut pour minimiser les conséquences.
Dans ce cas de figure, il ne s'agit pas de pollution, de sécurité, de compatibilité,… sujets sur lesquels personne ne pourra contester l’intérêt des réglementations.
Il s'agit ici de contraintes, de coûts supplémentaires et d'amendes qui vont tomber sur ceux qui ne fraudent pas mais qui vont être en défaut de conformité.
Les fraudeurs trouveront toujours de quoi frauder, les seuls perdants de l'histoire seront les non-fraudeurs.
Quand tout le monde aura fait le constat que la certification n'aura rien changé, on va aller vers l'utilisation de système d'exploitation certifié? De puces DRM obligatoires? De systèmes de télésurveillances dans chaque entreprise? Faut il un permis pour utiliser un compilateur?
Bref, à trop croire à ce genre de solution, on se retrouve à financer des Hadopi, des systèmes de surveillance globaux et légaux, mais surtout un système législatif de plus en plus complexe et coûteux.
Je pense que la question de fond est de savoir si l'on est toujours libre de modifier/utiliser le logiciel dans le cadre où :
- dès que l'on veut l'utiliser, il faut en avoir l'autorisation (moyennant finance pour la certification).
En tout cas, logiciel libre ou pas, ça va être un sacré farwest pour les entreprises.
Vu qu'un logiciel change en permanence (nouvelle fonctionnalités, améliorations, correctifs de bugs, adaptations à des cas particuliers…), cela va entraîner des temps de mise à jour dépendants des temps de certification, des coûts en temps et en argent pour l'éditeur, et au final pour l'utilisateur (car c'est au final lui qui financera tout cela).
Il est en panne Google? :) Allez un petit copier-coller du premier lien trouvé pour contrebalancer ta vision angélique de la France.
Dixit maître Google :
L’inadaptation du système fiscal.
Les mentalités : absence de culture fiscale.
La pression fiscale : certains fraudeurs considèrent comme légitime l’incivisme fiscal devant un impôt lourd et contraignant.
La conjoncture économique.
L’appât du gain facile.
L’inégalité entre les impôts payés et les avantages perçus.
Merci d'avance de stopper ce tir à boulet rouge (et injustifié) sur moi, je ne fraude pas et je ne décide de rien.
Je dis juste que nos députés et sénateurs sont absents quand il faut se poser la question des causes qui amènent à un n-eme projet de loi.
La position d'OpenConcerto (qui propose un module de caisse) vis à vis de ce projet de loi :
- aucun impact sur l'aspect libre du logiciel : ils continuera à évoluer et à être sous licence GPL
- terminé la gratuité du module caisse : le coût de la certification sera répercuté aux utilisateurs
Est ce que ça luttera contre les fraudes, je ne pense pas, l'histoire montre que les tricheurs ont toujours un coup d'avance sur l'état répresseur. Aucun député ou sénateur pour se poser la question des causes de fraude ?
générant ainsi plusieurs centaines de milliers de lignes d'écritures comptable , je ne connais pas de programme de comptabilité [NDLR: libre] pouvant le faire
Et comment vous croyez qu'OpenConcerto est utilisé par des sociétés qui atteignent les 300 factures/jour?
Odoo avec quelques patchs en fait tout autant… bref…
Je pense que ce qu'il faut retenir de tout cela est que la gestion par entité doit se limiter au modèles et surtout ne pas s'appliquer aux vues et contrôleurs (pour une architecture MVC j'entend).
à retenir : c'est d'abord un "vrai" 64 bits, pas un bricolage
Humm… "Allo Intel, arrêtez vos bricolages avec vos Core i7 à 3 GHz, soyez un peu pro et flashez des softcores dans des FPGAs…"
Ce n'est pas parce que Yasep est réalisé en mode "pour le fun" qu'il faut se ridiculiser en tirant à boulets rouges sur ceux qui font (beaucoup) mieux que soit.
Je suis le premier à dire que ce que vous faites avec un FPGA est du super boulot, mais faut pas s'y croire pour autant.
Sinon, faut aller bosser chez AMD, ils doivent être preneur de technos qui ont le potentiel de leur donner un fort avantage concurrentiel.
Concernant les hypothétiques performances, j'attends avec impatience de voir le résultat du décodage H264.
Je n'ose même pas imaginer un benchmark entre un node.js sur processeur Intel "Brico" vs Yasep/FCPU !
Pour fun, un processeur Very-VLIW taillé pour digérer du code provenant d'un bytecode Java,
ca me parle beaucoup plus. Question de goûts.
La GT970 n'a pas besoin de 3 To de mémoire car elle mouline presque toujours les mêmes données (celle de la scene 3D)
pour l'afficher à diverses positions, angles, etc…
Un hypothétique signal HDMI (plusieurs paires torsadées avec un encodage totalement dingue à ultra-haute fréquence) arrivera à un endroit, pas forcément au milieu de la surface (les architectes et artistes n'ont que faire des contingences électroniques).
Ce n'est pas à quoi je pensais. J'envisageais plutôt de considérer la "grille" de led comme un écran standard.
Cad pouvoir utiliser le plein potentiel d'un ordinateur pour générer les animations, lire de la vidéo plutôt que de tout coder en dur dans un automate à état sur un processeur atypique.
# Yes
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche L'Insee et la Drees ouvrent le code source du modèle Ines. Évalué à -2.
J'aime bien ce côté "rien a foutre des standards" de nos institutions.
Vive les langages SAS et M, ouvrons nos esprits à ces langages, voyons!
Une réécriture en BF financée par nos impôts s'impose…
Je vous laisse admirer le beau HTML 'Microsoft Word 12' de cette page https://ines-libre.adullact.net/
Misérable.
[^] # Re: Loi finances 2016
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche L’ERP OpenConcerto passe en version 1.4. Évalué à 2.
Evidemment nous certifierons le logiciel, les modifications techniques ne sont pas énormes.
Nous communiquerons dessus plus tard, car les échéances sont lointaines et avons bien d'autres choses à développer pour l'instant.
# Bravo
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Sortie de Mixxx 2.0. Évalué à 3.
Super logiciel, bravo. NanoKontrol2 opérationnel en moins de 2 minutes!
Ni connaissant rien en DJ'ing, je peux juste dire que l'ensemble est vraiment bien fini, intuitif et amusant à prendre en main.
[^] # Re: Compte-rendu analytique de la séance d'hier, 16 décembre
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 1.
Bonjour,
Nous serions interessé de faire sa lecture.
Par email à ilm-informatique.fr sur l'email de "contact@…"
Merci d'avance.
# Peut mieux faire.
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Algem, logiciel de gestion d'activités culturelles. Évalué à 5.
Au secours!
Qu'est ce que c'est que cette interface graphique?
Elle piétine les standards dans les grandes largeurs!
Difficile de trouver icônes plus moche,
les layouts sont plus qu'étranges,
et le look and feel natif même pas activé ( Tips: UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); )
Merci d'utiliser des SwingWorker pour ne pas bloquer la thread principale de Swing.
[^] # Re: Dura lex, sed lex ou le problème des logiciels à plusieurs utilisateurs
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 3.
Oui, exact. Ajout et suppression doivent être interdit par le logiciel.
Mon propos est justement lié au logiciel, on ne peut à mon sens n'imposer à l'éditeur d'un logiciel que des choses relatives au logiciel, pas relatives à l'utilisateur.
Petit parallèle avec les armes pour changer d'optique:
Est ce que l'on met en prison les fabricants de couteaux quand certains font de la boucherie humaine?
Non, évidement.
Dans la même logique, on ne doit pas impliquer l'éditeur à l'utilisation frauduleuse de son logiciel.
Et tout comme il est interdit de créer des bombes atomiques, un éditeur de logiciel doit être lourdement sanctionné s'il intègre des fonctionnalités de fraude.
Bon allez… il est temps pour moi d’arrêter de commenter à tout va, c'est bien sympathique d'échanger ici, mais ça n'aura aucun effet sur le vote du projet de loi, ni sur la fraude.
Ce ne fait que du temps en moins à consacrer à des sujets plus constructifs, passionnants et loin de la bêtises législative qui au fil du temps déresponsabilise la majorité, démoralise les créateurs et grignote les libertés.
[^] # Re: inaltérabilité
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 3.
Oui.
Le seul "hic" vient du fait que la première transaction n'a pas de transaction précédente ;)
Plus généralement, pour modifier" ni vu ni connu" la n-eme transaction, il suffit d’effacer toutes les suivantes au passage et de les recréer.
[^] # Re: Je ne vois pas bien l'interdiction du logiciel libre
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 7.
Bonjour,
Le problème n'est pas tant au niveau des coût pour "nous" les éditeurs, mais surtout pour les entreprises en général… Le coût de la certification n'est rien par rapport aux centaines de millions d'euros que va coûter en temps/prestations/licences, une mesure inefficace et facilement contournable (cf mes autres posts).
Pour ceux qui n'aurez pas vu passé l'info, au sujet de la norme NF 525, rien que l'obtention des règles de certification est payant (500€)… mais peut être doit on déjà se réjouir que la consultation du projet de loi est gratuite. J'ai personnellement du mal à me faire à cette société qui pense régler les problèmes de fond par des taxes, des normes, des interdictions…
L'administration détruit déjà assez d'entreprises comme cela, si l'on peut éviter de plomber encore un peu plus l'économie, faisons le. Je reste persuadé, que l'état ne récupérera que des miettes de ce qu'il pense récupérer sur les ventes "masquées", tout comme Hadopi a freiné le piratage.
Il y a d'autres moyens de faire "ce que vous pensez que l'administration fiscale veut", si tenté que votre interprétation soit celle des auteurs de la chose.
Pour ce qui est du module autonome, la loi n'en parle pas, elle parle de logiciel (donc l'ensemble).
[^] # Re: Dura lex, sed lex ou le problème des logiciels à plusieurs utilisateurs
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 2.
Si c'était le cas, la loi ressemblerait plutôt à cela:
"Tout logiciel de gestion, de comptabilité, de caisse ou d'encaissement a l'obligation légale d'empêcher toute suppression d'écritures comptable par l'utilisateur. L'administration fiscale s'autorise en cas de doute avéré de procéder à un audit du code source fournit par l'éditeur."
[^] # Re: Je ne vois pas bien l'interdiction du logiciel libre
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 5.
Bonjour,
Le raisonnement est valable pour une voiture, pas pour un logiciel de gestion / ERP.
On impose pas à une voiture de 2010 de respecter les normes de 2015.
La législation fiscale évolue sans cesse, récemment il a fallut ajouter l'export FEC, pour bientôt la DSN…
En gros, pour avoir un logiciel dans les clous, il faut le mettre à jour chaque année.
Dans un ERP, vu que tout est unifié et adapté à l'entreprise, il y a quasiment un logiciel par entreprise.
Bref, pour nous (OpenConcerto), il va falloir "faire certifier" ou "auto certifier" de nombreuses versions, même si la partie qui traite les encaissements est commune. Il nous faudra aussi mettre en place des systèmes pour garantir que le logiciel installé correspond au code source associé.
Cela prendra du temps, comprendre de l'argent, l'argent provenant des clients, mécaniquement ça va coûter aux utilisateurs.
Juste en temps, mettre à jour 3 millions de logiciels (dans l’hypothèse ou les 3 millions d'entreprises française vont utiliser un logiciel de gestion à jour…), cela prendre 3 millions d'heures de travail inutile MINIMUM (soit 342 années de vie).
De plus, l’efficacité contre la fraude sera nulle.
Qui voudra frauder, trouvera comment. Il ne faut pas être très calé pour comprendre qu'utiliser un autre logiciel en parallèle suffira ou encore, tout simplement, ne pas comptabiliser ce que l'on ne veut pas déclarer…
Niveau fraude côté éditeur, les cas avérés sont des logiciels propriétaires. Avec un logiciel libre, c'est plus difficile de cacher une fonctionnalité "de bricolage" car le code est accessible.
Obliger tout éditeur à donner accès au code source de son logiciel pour contrôle, cela serait une loi plus pertinente.
```
[^] # Re: Il faut relativiser
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 6.
Depuis quand il faut des accords pour générer des fichiers SEPA ????
Pour l'interface avec les banques, il y a EBICS, pas besoin d'accord non plus… le client paye son accès.
La preuve en image : OpenConcerto.
[^] # Re: Liberté, Égalité, Fraternité
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 9.
3 millions d'entreprises…
Valorisez le temps à passer, les licences, les prestations… on dépasse le milliard d'euros pour un résultat sur la fraude qui sera à la hauteur d'Hadopi ;)
Avec OpenConcerto, on a plus de 200 000 entrepreneurs qui seraient potentiellement ravis d'envoyer un petit email ou appeler nos chers responsables…
# Liberté, Égalité, Fraternité
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 10.
Merci pour ce récapitulatif.
Il manque un point important, c'est l'impact économique de cette loi sur l'ensemble des entreprises, logiciels libres ou pas.
En effet, tout le monde devra passer à des nouvelles versions de logiciels "inaltérables", c'est-à-dire passer à la caisse d'une façon ou d'une autre. Même avec des logiciels libres, cela ne se fera pas à coût zéro (temps, prestations diverses…).
Les amateurs d'Excel ou Libre/OpenOffice devront apprendre à s'en séparer.
Il serait de bon ton de partager numéro de téléphone ou email de ces chers "responsables" à la tête du projet.
Il y a des centaines d'entrepreneurs qui seraient heureux de leur envoyer leur avis et quelques éditeurs comme nous (OpenConcerto) de leur expliquer l'inefficacité de leur projet et l'impact sur nous et les entreprises en général.
[^] # Re: valeur ajoutée ?
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Linutop OS XS disponible pour tous les Raspberry PI (Zéro, A, A+, B, B+ et 2) :. Évalué à -1.
Et face à une orange, c'est cher?
La valeur ajoutée tourne autours du travail des personnes qui ont réalisé ce système prêt à l'emploi.
Cela devient usant de voir le manque de respect de certains vis à vis du travail fait dans le milieu du logiciel libre.
# Design orthogonal
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Kakoune, un éditeur de texte qui a du caractère. Évalué à 9.
Je ne sais pas vous, mais moi que je lis du "design orthogonal", je me pose des questions sur le taux de pipoware associé.
[^] # Re: Modification de législation française et logiciel libre de caisse/compta
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Présentation Odoo à Paris, le 6 octobre 2015. Évalué à 1.
J'aime beaucoup la façon que tu as de prêter aux autres des propos qu'ils n'ont pas, le tout pour dénigrer des stéréotypes.
Où as tu vu que je revendique que personne ne veut m'écouter?
Est ce que ce projet de loi s'attaque aux causes? Non.
Est ce que ce projet de loi va empêcher la fraude? Non.
Est ce qu'il faut lutter contre la fraude? Oui.
Tu considères que ce projet de loi est une bonne chose et qu'il va remettre dans le droit de chemin les fraudeurs, très bien. Je respecte ce point de vu, même si à part dire qu'il ne faut pas se poser de questions, tu refuses toute discussion argumentée.
Bonne soirée.
[^] # Re: Modification de législation française et logiciel libre de caisse/compta
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Présentation Odoo à Paris, le 6 octobre 2015. Évalué à 0.
SI l'on considère qu'un fraudeur trouvera toujours un moyen de frauder, je ne sais pas comment on peut conclure que ce projet loi va être utile (hormis imposer des coûts supplémentaires aux honnêtes gens et balancer des amendes aux non fraudeurs qui n'auraient pas acquis un logiciel certifié).
Pour nos voitures, on y vient doucement : traceurs, système eCall, firmware des composants cryptés… on parle même de pouvoir arrêter les véhicules à distance…
Je ne peux que souhaiter que tu ais raison et que tout cela se limite par une liste de fournisseurs certifiés. Certification non pas basée sur leur "cotisations" mais basée sur la réalité du fonctionnement.
[^] # Re: limiter la casse
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Présentation Odoo à Paris, le 6 octobre 2015. Évalué à 1.
C'est un début de solution mais techniquement, il reste des difficultés :
- la base de données : comment empêcher toute manipulation de la base par un logiciel tier?
La crypter? Dans ce cas, le logiciel certifié contient la clef. Avec un peu de persévérance, on la récupère et le tour est joué.
- la couche graphique : si la couche graphique est modifiée pour ne pas se servir de l'API certifiée, tout est falsifiable par détournement.
Certifier la couche graphique? Dans ce cas, il y a nécessité de re-certifier le tout à chaque modification, optimisation, correction de bugs…
[^] # Re: Modification de législation française et logiciel libre de caisse/compta
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Présentation Odoo à Paris, le 6 octobre 2015. Évalué à 2. Dernière modification le 07 octobre 2015 à 14:34.
Il n'y a rien de particulier à cette loi, elle est dans la logique actuelle qui est de ne jamais adresser aux causes mais utiliser tout ce que l'on peut pour minimiser les conséquences.
Dans ce cas de figure, il ne s'agit pas de pollution, de sécurité, de compatibilité,… sujets sur lesquels personne ne pourra contester l’intérêt des réglementations.
Il s'agit ici de contraintes, de coûts supplémentaires et d'amendes qui vont tomber sur ceux qui ne fraudent pas mais qui vont être en défaut de conformité.
Les fraudeurs trouveront toujours de quoi frauder, les seuls perdants de l'histoire seront les non-fraudeurs.
Quand tout le monde aura fait le constat que la certification n'aura rien changé, on va aller vers l'utilisation de système d'exploitation certifié? De puces DRM obligatoires? De systèmes de télésurveillances dans chaque entreprise? Faut il un permis pour utiliser un compilateur?
Bref, à trop croire à ce genre de solution, on se retrouve à financer des Hadopi, des systèmes de surveillance globaux et légaux, mais surtout un système législatif de plus en plus complexe et coûteux.
[^] # Re: Modification de législation française et logiciel libre de caisse/compta
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Présentation Odoo à Paris, le 6 octobre 2015. Évalué à 0.
Je pense que la question de fond est de savoir si l'on est toujours libre de modifier/utiliser le logiciel dans le cadre où :
- dès que l'on veut l'utiliser, il faut en avoir l'autorisation (moyennant finance pour la certification).
En tout cas, logiciel libre ou pas, ça va être un sacré farwest pour les entreprises.
Vu qu'un logiciel change en permanence (nouvelle fonctionnalités, améliorations, correctifs de bugs, adaptations à des cas particuliers…), cela va entraîner des temps de mise à jour dépendants des temps de certification, des coûts en temps et en argent pour l'éditeur, et au final pour l'utilisateur (car c'est au final lui qui financera tout cela).
[^] # Re: HS le coupable de la fraude c'est l'Etat, évidement!
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Présentation Odoo à Paris, le 6 octobre 2015. Évalué à -1.
Il est en panne Google? :) Allez un petit copier-coller du premier lien trouvé pour contrebalancer ta vision angélique de la France.
Dixit maître Google :
Je tiens à préciser que je n'approuve aucunement la fraude
(ni l'attitude répressive de ceux qui viennent de nous acheter 2 beaux tableaux à 80 millions d'euros http://www.huffingtonpost.fr/2015/09/30/vente-tableaux-rembrandt-france-pays-bas-160-millions-euros_n_8219654.html "Un prix considéré comme très au dessus du marché par plusieurs experts")
Merci d'avance de stopper ce tir à boulet rouge (et injustifié) sur moi, je ne fraude pas et je ne décide de rien.
Je dis juste que nos députés et sénateurs sont absents quand il faut se poser la question des causes qui amènent à un n-eme projet de loi.
[^] # Re: Modification de législation française et logiciel libre de caisse/compta
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Présentation Odoo à Paris, le 6 octobre 2015. Évalué à 1.
La position d'OpenConcerto (qui propose un module de caisse) vis à vis de ce projet de loi :
- aucun impact sur l'aspect libre du logiciel : ils continuera à évoluer et à être sous licence GPL
- terminé la gratuité du module caisse : le coût de la certification sera répercuté aux utilisateurs
Est ce que ça luttera contre les fraudes, je ne pense pas, l'histoire montre que les tricheurs ont toujours un coup d'avance sur l'état répresseur. Aucun député ou sénateur pour se poser la question des causes de fraude ?
[^] # Re: ERP complet
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Sortie de l'ERP Noalyss 6.9. Évalué à -1.
Et comment vous croyez qu'OpenConcerto est utilisé par des sociétés qui atteignent les 300 factures/jour?
Odoo avec quelques patchs en fait tout autant… bref…
# Hors limites
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E15 : J'arrête.... Évalué à 5.
Je pense que ce qu'il faut retenir de tout cela est que la gestion par entité doit se limiter au modèles et surtout ne pas s'appliquer aux vues et contrôleurs (pour une architecture MVC j'entend).
Merci pour ce nouvel épisode.
[^] # Re: Court circuit
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 0.
Humm… "Allo Intel, arrêtez vos bricolages avec vos Core i7 à 3 GHz, soyez un peu pro et flashez des softcores dans des FPGAs…"
Ce n'est pas parce que Yasep est réalisé en mode "pour le fun" qu'il faut se ridiculiser en tirant à boulets rouges sur ceux qui font (beaucoup) mieux que soit.
Je suis le premier à dire que ce que vous faites avec un FPGA est du super boulot, mais faut pas s'y croire pour autant.
Sinon, faut aller bosser chez AMD, ils doivent être preneur de technos qui ont le potentiel de leur donner un fort avantage concurrentiel.
Concernant les hypothétiques performances, j'attends avec impatience de voir le résultat du décodage H264.
Je n'ose même pas imaginer un benchmark entre un node.js sur processeur Intel "Brico" vs Yasep/FCPU !
Pour fun, un processeur Very-VLIW taillé pour digérer du code provenant d'un bytecode Java,
ca me parle beaucoup plus. Question de goûts.
La GT970 n'a pas besoin de 3 To de mémoire car elle mouline presque toujours les mêmes données (celle de la scene 3D)
pour l'afficher à diverses positions, angles, etc…
Ce n'est pas à quoi je pensais. J'envisageais plutôt de considérer la "grille" de led comme un écran standard.
Cad pouvoir utiliser le plein potentiel d'un ordinateur pour générer les animations, lire de la vidéo plutôt que de tout coder en dur dans un automate à état sur un processeur atypique.