En général tu fait ton implémentation, tu montre ça au client, et tu va standardiser le truc.
Ensuite tu as soit le bon client qui n'attend pas que se soit vraiment standard et qui utilise ton implémentation, et ensuite, comme le standard c'est des compromis tu le garde et tu le fait payer.
Si tu as un mauvais client, qui suit en général les standard, et qui veut que se soit standard avant de le déployer : ça prend plus de temps, mais ça rend les négociations avec les vendeurs, le changement de vendeurs, ou avoir plusieurs vendeurs et les test d'acceptance beaucoup plus simple. Au final ça coute moins cher. Toute l'astuce est ensuite un bon mix entre les petits identifiant opaque, le protocole et l’implémentation (quand on est un vendeur, et de comprendre ca quand on est un client)
Pour le cas du logging ou de l'init, je ne savait pas qu'il y avait une urgence a tout changer et j'ai l'impression qu'un vendeur et son évangeliste ramasse tout. Et quand j'ai l'impression qu'il y a pas mal de bon client.
c'est pas rapide, c'est encore moins rapide si certains considèrent l'existant comme un truc de vieux con qui ont tord. Ensuite il y a un intérêt a faire des trucs non standard et des truc standard/améliorer les standard. C'est en général une question de donner du poids a la rapidité immediate ou a écosystème a long terme. De plus il est possible de faire des choses rapidement et être standard-friendly.
c'est assez général comme sujet
Ensuite certain essayent de jouer le jeu, font des propositions pour des standards, ajoute des nouvelles fonctionalité de maniere modulaire, histoire que ca rentre par couche. Ca marche en general bien et ca c'est utilisable et adopté, pas assez rapidement pour certains.
De l'autre coté il y a les intégrateurs logiciel, dont microsoft fournit de bon examples, qui n'essaye pas de suivre ces standard et font leurs solution indépendante et surtout évite de rester compatible.
je pense qu'une attitude de la sorte est peu bénéfique pour avoir des systèmes ouvert et des standard ouvert, d'autre que moi l'on répété mainte fois.
Pour revenir au sujet particulier des log, faire la liste des problemes avec l'existant, aider les gens qui poussent pour améliorer ça, proposer des API qui s’intègre avec l'existant, et qui peut etre une base pour les extensions de POSIX, aurais été assez bien pour tout le monde. Je n'est pas l'impression que se soit passé comme ça, mais d'un autre coté je n'ai pas personnellement participé au bon fils de discussions, et d’après les gens qui pourrais me citer les références, il y a bien eu des discussions de la sorte avec la communauté large des systeme de log.
Ce n'est après tout que ce que j'ai vus et lus, Chacun est libre de faire ses choix a partir de chose bien documenté. Comme mes pointeurs.
Ok, merci pour la discussion intéréssante, donc pour résumer l'argument que je ne connais pas le sujet, c'est que les gens qui font un nouveau système de logging le font.
je demande (honte a moi) d’être corrigé/informé sur les discussion de design et la relation avec l'existant de journald, Google a essaye de m'aider mais bof pour l'instant, mais comme apparemment toi tu connais, tu pourrais donner les liens.
Je suis vraiment désolé de rien connaitre a syslog, unix et me réferer bêtement au post de gens qui maintiennent ça pour me faire un avis. Merci de m 'éduquer par cette suite d'argument construit.
Interessant, on peut aussi dire "Décider un truc qui est en accord avec toi == discuter.".
Maintenant, vu que tu est au courant, tu peut fournir les pointeurs vers les discussions, j'ai cherché sur google et ce n'est pas immédiat.
Sans discussion, vue ce qu'écrit un dev d'un démon syslog, et que j'ai pas trouvé grand chose via google (mais j'aimerais bien voir ou sont les discussions sur le besoin de journald)
Je parle de POSIX, parceque cela comporte aussi les API système et les commands de base,
alors quand quelqu'un veut enlever syslog de linux pour le remplacer par une autre API https://fedoraproject.org/wiki/Changes/NoDefaultSyslog
systemd-journald lit (encore) l'interface POSIX, mais ce qui est poussé sont les API et le format structuré, sinon ce qui est proposé par journald peut être fait avec d'autre implémentation.
En regardant la liste des feature de journald, a l'exception d'un point, tout est faisable avec
l'architecture syslog et une API POSIX mise a jour pour les aspect 'information standard et structuré'.
La seul chose qui n'est pas supporté c'est "Logging is a core responsibility for a service manager, and it should be integrated with it reflecting that."
ça tombe bien, c'est un choix de design, ce n'est pas nécessaire d'avoir une integration. Qu'il y est une interface de logging, oui, que ce soit integré : non.
La lecture du lien est assez intéressante, de même que http://felipec.wordpress.com/2013/11/04/init/, on voit pas mal de chose intéressante. Ensuite les arguments cite par http://ewontfix.com/14/, sont valide (même si je ne pense pas que systemd est complètement casse. Au vue de journald, sujet que je connais mieux techniquement, et de la manière dont les choix techniques sont fait, j'ai l'impression de jeter au orties des systèmes stables et les faire évoluer pour atterrir sur un Linux/Systemd.
Si certain sont partie en mission pour ré-ecrire leur POSIX a eux, sous leurs contrôle, sans discuter ou essayer d’améliorer l'existant, et que les gens trouvent ca super, libre a eux. et libre aux autre de trouver ça dangereux.
j’espère juste que Debian autorisera les gens a ne pas utiliser systemd, et je trouverais intéressant de savoir ou l'on peut trouver le groupe des gens qui veulent avoir un systeme d'init qui est rapide qui n'est pas offert avec la barre de navigation systemd en plus de journald ;-)
J'ai essaye, et je trouve que l'autre produit de Microsoft pour le Chat et la VOIP est bien mieux fait (Skype). Je ne sait pas combien la customisation par ma boite influence Lync, mais le client qui Bug la je pense que le Pb vient de l'editeur (Les IM ne s'ouvrent pas, les meeting pas stable, le client Mac ou on ne peut pas changer sa photos, il a du mal a se logguer, …..etc ).
l'integration avec la messagerie est appreciable, mais d'autres outils le font (WebEx Connect, proprio et Jitsii open source), donc bof.
Apparement l'agrément porte sur le chiffrement des factures, donc une telle solution peut etre certifié.
Quand je veut dire que le serveur de gestion de facture est certifié, je parle exactement de ton dernier paragraphe. Ensuite je n'est jamais dit que la certification etait utile. On peut parfaitement faire ta procédure entre le serveur/serveuse et le terminal : tu as un terminal "magique" avec une fausse entreprise qui paye la TVA "ailleur".
Je dirais ca dépend de l'agrément en détail. Si l'agrément concerne la gestion des factures numérique et papier, on peut parfaitement faire un module/serveur de gestion de facture, et avoir un agrément sur ce composant seulement. Le reste n'a peut être pas besoin d'agrément et les modification peuvent être plus dynamique.
C'est assez discutable :
Adobe supporte le standard ISO 32000-1:2008 pour les formulaire en PDF. Ils l'ont développé et standardisé.
La question est plus :
1) pourquoi l'administration a décidé d'utiliser les formulaire non normé de la version PDF 1.5 plutôt que ceux de la version 1.2 (normé).
2) pourquoi le XFA n'est pas proposé par adobe comme norme (l'ISO leurs a demandé) et qu'en pense l'administration française et l’Europe (ca pourrais plus les motiver si l’administration leur demande)
A par ça je suis intéressé sur le parallèle entre XFA et RTF, il y a t il des examples d'utilisation non conforme du XFA crée par Adobe en comparaison avec les spécifications qu'ils donnent?
C'est assez hypothétique que des gens qui se sont embêté a faire une spécification de 600 pages, plusieurs fois mise a jour, fasse exprès de casser des implémentation libre.
Il est beaucoup plus probable que tout changement soit vérifié et re-vérifié pour ne rien casser, simplement parceque si une mise-a-jour mineur commence a demander a tout le monde de mettre a jour le logiciel, ça va râler sec chez le client.
Donc si vous ne trouvez pas le choix du format de fichier acceptable, je pense que la question est plus de savoir quand le RGI va considérer les formulaires administratifs et la bonne norme a utiliser, et pourquoi et comment un site a décidé d'un format, qui n'apparait pas trés aligné avec les principes du RGI (vu qu'un standard existe pour les formulaire).
Il ne faudrait utiliser que des standards ouverts pour l'état, s'ils existent.
Ensuite un petit peu de Wikipedia en plus me dit que ISO 32000-1:2008 contient un système de formulaire, mais je ne sais pas quelle est la différence de fonctionnalité entre XFA et les formulaire standard.
Utiliser du XFA peut être justifié, et vu que c'est un format ouvert, ça va quand même.
La seule chose qui pourrais être un scandale c'est si XFA est utilisé uniquement parce que c'est vendus avec adobe et que le workflow est standardisé avec Adobe (tm) et on s’arrête la. Mais la c'est un peut dure de savoir.
Pour finir le drame a l'air de venir de mupdf qui redirige vers adobe, pas du format lui même.
C'est plus une question de discipline, au fil du temps mettre une trace pour chaque branche de code avec les variables discriminantes, c'est possible et ca marche assez bien.
De plus j'utilise cppcheck patché (ou tout autre outils d'analyse de code) pour suivre la discipline des dev.
C'est en général possible de configurer d'éditeur de code pour ajouter ca tout seul.
A l'usage les traces partout dans le code est plus efficace que les autres méthodes dans mon cas.
Comme ca on ne fait que des cycles de reproduction de Problèmes :-)
En fait (et ca doit etre la meme chose chez tout les gens serieux) on a plusieurs niveaux de traces et de log, les logs sont toujours disponible sur les systèmes en production, pas les traces.
Le tout va dans des fichiers, est configurable a distance (filtres, ..etc ).
En fait le debugger est utilisé pour les segfault (une fois tout les ans).
Pour des petits projets pas mal de méthodes peuvent marcher, mais quand ca devient gros je ne connais pas de méthode qui est plus efficace que plusieurs niveaux de traces.
Comme les attentes c'est que ce soit facile a installer pour l'utilisateur et pour le developpeur, Greenstone ou NewGenLib peuvent etre une base, et les autres peuvent fournir des informations interessant sur le schema de base de donné/filtre d'import.
Une autre piste, c'est d'etendre un gestionnaire de eBook pour gerer l'aspect pret de livre et multi-utilisateurs, et de reutiliser l'aspect multi-plateforme, installateur, ..etc
Ensuite pour QT, il va tout de meme avoir une base de donnée, des imports des differents format de fichier, les système de classification dewey ou autre, et tout le process d'installation.
J'ai l'impression qu'Antony a un vieux logiciel avec des problèmes et qu'il cherche
a avoir un équivalent open source.
Ensuite je maintient que réutiliser des composants existant avec une interface spécifique fournis une architecture a considérer, car elle peut ouvrir a des solutions intéressante, tout en restant KISS (l'integration et le KISS est non trivial)
Les pistes proposé par baud123 ne sont pas incompatible avec les attentes des utilisateurs, de plus ils peuvent permettre d'avoir des solution hebergé par la bonne ame qui veut faire tourner ca sur une machine (support).
par contre un des critère a prendre en compte, c'est qu'il est possible d'avoir un export des donnés vers un version non hébergé.
Ensuite pour le KISS et le NAS, le mien c'est :
1) login,
2) Gestionnaire de module,
3) copie d'une URL,
4) cliquer sur installer,
5) cliquer sur demarrer,
Et j'ai mon serveur qui tourne.
Et le raspberry pi, Le use case que je vois c'est plutot :
a) le projet fournis une image pour carte SD pour raspberry Pi
b) C'est assemblé par magie et ca donne un boitier
c) un petit boitier fait le serveur ou est branché directement a une télé (0 maintenance)
l'instituteur fait c) , ou si il a le temps de telecharger un fichier et de le copier sur une carte SD, et de faire un boitier, il peu faire b)
Ensuite refaire un systeme de gestion de livre, avec une base de données, des sysèmes d'import, maintenir des base de livre et de classification. le tout pour peu d'utilisateur, c'est aussi possible.
Néanmoins je suis pas sur que ce soit aussi efficace dans le long terme que d'ajouter une interface 'école' a un project existant, et de faire des distributions intégré (que le projet peut aussi réutiliser)
L'architecture des premiers est a priori partiellement adapté pour le second.
L'interface des premiers a priori non, mais une architecture potentiel peut etre:
1) avoir une installation (apache+cgi+BDD) pré-configuré
2) un frontend (appli spécialisé/navigateur+pages web) qui convient au second monde
Comme ca le second monde est content, pas de base de données mal faite, plein de feature au besoin, ca peut etre migré vers des solutions en ligne ou des appliances (NAS qui permet d'installer des truc dessus, raspberry pi si ca amuse des gens).
L'ideal c'est d'integrer l'interface "école" en upstream, et le reste c'est de packager les briques et la config pour des vielles machines.
Aprés un coup de Universal Extractor sous windows, un coup d'oeil aux *.BCD:
- un header et ensuite des structure de taille fixe
- un certain nombre de fichiers (Auteurs.BCD,Editeurs.BCD,Illustrs.BCD,Period.BCD),
on l'air d'etre : 2 byte, char [45][]
- Groupes.BCD : header:1 byte,
structure : char name[40]
byte noIdea[3]
char alsoNoIdea[40]
byte remaining[26]
- Utilisat.BCD : header : 2 byte
structure (2100 byte)
char user[40]
char group43
short noIdea;
char someString[10]
byte noIdea2;
char noIdea3[11];
char date[10]
byte aLongString[1983]
Ensuite : j'ai windows 7, et pas envie d'activer le mode de compatibilité XP, d'installer une VM pour ca, donc j'ai pas pu regarder les champs et faire un reverse-engineering plus poussé, mais ca a l'air plutot simple (i.e 2h de perl pour decoder des trucs de base, en faisant la cuisine, suffit de demander)
En remplissant une base avec des données unique, ca doit etre faisable de retrouver le format de la base.
A partir de ca, et pour repondre a la question, avant de recommencer un nouveau logiciel, il y a quoi comme logiciel open source existant ou approchant, c'est mieux de modulariser un logiciel existant pour fournir une interface ad-hoc que de reinventer la roue.
Google me dit que Koha (http://www.koha.org/) est puissant, mais une installation de koha pre-configuré pourrait peut-etre etre suffisant.
a moderer, la conduite sur autoroute allemande est fatiguante:
- les distances de sécurité sont rarement respecté (et c'est dangereux)
- je me rabat dans une demis distance de sécurité, et zou ca freine franchement
- que conduire a 200km/h et plus implique de freiner tres souvent
Les méthodes de la police allemande me manque en france (radar de distance embarqué sur autoroute: tu colle, tu va discuter avec la police aprés), alors l'excité avec ses phare il l'a bien dans l'os et c'est tant mieux.
Derniere petite chose : il ne faut pas freiner sans raison valable, il est si simple de continuer en adaptant sa vitesse au danger (venant de derriere).
Reprocher a qqn de freiner sur autoroute en ayant conduit en allemagne est "rafraichissant".
avoir un format (colonnes, indentation, ...) standard, a tendance a rendre le code plus lisible.
les conventions a un moment t sont compatible avec celle de t-1, et pouf recursion j'usqu'a 80 colonnes.
et puis 80 colonne c'est trés bien sur les grand ecrans : on peut afficher 2 ou 3 code en parallele.
Pour finir la limite de niveau d'indentation est en général a suivre, en particulier pas toujours ( une bonne tripoté de parametre, une bonne tripoté de comportement pas combinaison, pas de solution universel pour rendre ca lisible.)
Les seul choses un peu borderline c'est :
- de ne pas mettre "unknown contamination".
- de dire que l'OSS c'est risqué
Le reste est vrai, sans gestion correcte des licenses (OSS ou proprio) c'est la merde.
Avec les licenses proprio tu doit verifier les requirements, la license, le prix, que ca colle aves la strategie, que le departement legal soit d'accord, que les achats soient eux aussi d'accord, <insérer une boucle de négotiation avec les chefs de project, le departement legal et les achats>
6 mois apres tu commence le developement et tout le monde est bien au courant que ca a couté cher et de la license.
Avec l'OSS, le risque qu'une perssone trouve ca plus simple, plus rapide, et que ca l'emmerde moins est pas tout a fait négligeable non plus. Un bon ingénieur doit savoir faire ca tout seul, mais meme chez les ingénieurs, la diversité est de mise (la stupidité peut se manifester sous beaucoup de formes pour tout le monde)
La différence est que plus de gens doivent participer au process des licenses, c'est pas trés compliqué mais indispensable.
avec un portable, j'ai ma souris bluetooth pour me balader (sinon docking station , c'est une tout filaire) ::
- je part en reunion avec la souris dans ma poche, les souris avec fil ne rentre pas (le fil fait vraiment chier)
- je n'ais pas une jungle de fil dans mon sac a dos
- je peut cliquer a 10 metres, la souris dans la poche, c'est classe
- je n'ais pas besoin de brancher ma souris, juste un chtit bouton
[^] # Re: Broken by design ?
Posté par ham . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à -1.
Je suis d'accord.
En général tu fait ton implémentation, tu montre ça au client, et tu va standardiser le truc.
Ensuite tu as soit le bon client qui n'attend pas que se soit vraiment standard et qui utilise ton implémentation, et ensuite, comme le standard c'est des compromis tu le garde et tu le fait payer.
Si tu as un mauvais client, qui suit en général les standard, et qui veut que se soit standard avant de le déployer : ça prend plus de temps, mais ça rend les négociations avec les vendeurs, le changement de vendeurs, ou avoir plusieurs vendeurs et les test d'acceptance beaucoup plus simple. Au final ça coute moins cher. Toute l'astuce est ensuite un bon mix entre les petits identifiant opaque, le protocole et l’implémentation (quand on est un vendeur, et de comprendre ca quand on est un client)
Pour le cas du logging ou de l'init, je ne savait pas qu'il y avait une urgence a tout changer et j'ai l'impression qu'un vendeur et son évangeliste ramasse tout. Et quand j'ai l'impression qu'il y a pas mal de bon client.
[^] # Re: Broken by design ?
Posté par ham . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à -9.
c'est pas rapide, c'est encore moins rapide si certains considèrent l'existant comme un truc de vieux con qui ont tord. Ensuite il y a un intérêt a faire des trucs non standard et des truc standard/améliorer les standard. C'est en général une question de donner du poids a la rapidité immediate ou a écosystème a long terme. De plus il est possible de faire des choses rapidement et être standard-friendly.
c'est assez général comme sujet
Ensuite certain essayent de jouer le jeu, font des propositions pour des standards, ajoute des nouvelles fonctionalité de maniere modulaire, histoire que ca rentre par couche. Ca marche en general bien et ca c'est utilisable et adopté, pas assez rapidement pour certains.
De l'autre coté il y a les intégrateurs logiciel, dont microsoft fournit de bon examples, qui n'essaye pas de suivre ces standard et font leurs solution indépendante et surtout évite de rester compatible.
je pense qu'une attitude de la sorte est peu bénéfique pour avoir des systèmes ouvert et des standard ouvert, d'autre que moi l'on répété mainte fois.
Pour revenir au sujet particulier des log, faire la liste des problemes avec l'existant, aider les gens qui poussent pour améliorer ça, proposer des API qui s’intègre avec l'existant, et qui peut etre une base pour les extensions de POSIX, aurais été assez bien pour tout le monde. Je n'est pas l'impression que se soit passé comme ça, mais d'un autre coté je n'ai pas personnellement participé au bon fils de discussions, et d’après les gens qui pourrais me citer les références, il y a bien eu des discussions de la sorte avec la communauté large des systeme de log.
Ce n'est après tout que ce que j'ai vus et lus, Chacun est libre de faire ses choix a partir de chose bien documenté. Comme mes pointeurs.
[^] # Re: Broken by design ?
Posté par ham . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à -2.
Ok, merci pour la discussion intéréssante, donc pour résumer l'argument que je ne connais pas le sujet, c'est que les gens qui font un nouveau système de logging le font.
je demande (honte a moi) d’être corrigé/informé sur les discussion de design et la relation avec l'existant de journald, Google a essaye de m'aider mais bof pour l'instant, mais comme apparemment toi tu connais, tu pourrais donner les liens.
Je suis vraiment désolé de rien connaitre a syslog, unix et me réferer bêtement au post de gens qui maintiennent ça pour me faire un avis. Merci de m 'éduquer par cette suite d'argument construit.
[^] # Re: Broken by design ?
Posté par ham . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à -4.
Interessant, on peut aussi dire "Décider un truc qui est en accord avec toi == discuter.".
Maintenant, vu que tu est au courant, tu peut fournir les pointeurs vers les discussions, j'ai cherché sur google et ce n'est pas immédiat.
[^] # Re: Broken by design ?
Posté par ham . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à -1.
Sans discussion, vue ce qu'écrit un dev d'un démon syslog, et que j'ai pas trouvé grand chose via google (mais j'aimerais bien voir ou sont les discussions sur le besoin de journald)
- http://blog.gerhards.net/2011/11/journald-and-rsyslog.html
- http://blog.gerhards.net/2011/11/what-i-dont-like-about-journald.html
- Announcing Project Lumberjack
- http://www.slideshare.net/rainergerhards1/rsyslog-vsjournal
Ensuite parceque je connaissait les solutions de logging avant journald, et au vue des possibilité disponible et de la communication de journald et de ses choix, j'ai beaucoup de mal a croire qu'avoir les possibilité décrites par les reqs. https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs&pli=1 soit dure ou compliqué
Je parle de POSIX, parceque cela comporte aussi les API système et les commands de base,
alors quand quelqu'un veut enlever syslog de linux pour le remplacer par une autre API
https://fedoraproject.org/wiki/Changes/NoDefaultSyslog
syslog fait partie du standard POSIX
http://pubs.opengroup.org/onlinepubs/9699919799/
systemd-journald lit (encore) l'interface POSIX, mais ce qui est poussé sont les API et le format structuré, sinon ce qui est proposé par journald peut être fait avec d'autre implémentation.
En regardant la liste des feature de journald, a l'exception d'un point, tout est faisable avec
l'architecture syslog et une API POSIX mise a jour pour les aspect 'information standard et structuré'.
La seul chose qui n'est pas supporté c'est "Logging is a core responsibility for a service manager, and it should be integrated with it reflecting that."
ça tombe bien, c'est un choix de design, ce n'est pas nécessaire d'avoir une integration. Qu'il y est une interface de logging, oui, que ce soit integré : non.
c'est plus clair?
[^] # Re: Broken by design ?
Posté par ham . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à -1.
La lecture du lien est assez intéressante, de même que http://felipec.wordpress.com/2013/11/04/init/, on voit pas mal de chose intéressante. Ensuite les arguments cite par http://ewontfix.com/14/, sont valide (même si je ne pense pas que systemd est complètement casse. Au vue de journald, sujet que je connais mieux techniquement, et de la manière dont les choix techniques sont fait, j'ai l'impression de jeter au orties des systèmes stables et les faire évoluer pour atterrir sur un Linux/Systemd.
Si certain sont partie en mission pour ré-ecrire leur POSIX a eux, sous leurs contrôle, sans discuter ou essayer d’améliorer l'existant, et que les gens trouvent ca super, libre a eux. et libre aux autre de trouver ça dangereux.
j’espère juste que Debian autorisera les gens a ne pas utiliser systemd, et je trouverais intéressant de savoir ou l'on peut trouver le groupe des gens qui veulent avoir un systeme d'init qui est rapide qui n'est pas offert avec la barre de navigation systemd en plus de journald ;-)
[^] # Re: bof
Posté par ham . En réponse au journal Wync, un client Lync pour Linux !. Évalué à 2.
J'ai essaye, et je trouve que l'autre produit de Microsoft pour le Chat et la VOIP est bien mieux fait (Skype). Je ne sait pas combien la customisation par ma boite influence Lync, mais le client qui Bug la je pense que le Pb vient de l'editeur (Les IM ne s'ouvrent pas, les meeting pas stable, le client Mac ou on ne peut pas changer sa photos, il a du mal a se logguer, …..etc ).
l'integration avec la messagerie est appreciable, mais d'autres outils le font (WebEx Connect, proprio et Jitsii open source), donc bof.
[^] # Re: Agrément ministériel (reste du monde)
Posté par ham . En réponse à la dépêche Logiciel de caisse Pastèque, version Datte. Évalué à -1.
Apparement l'agrément porte sur le chiffrement des factures, donc une telle solution peut etre certifié.
Quand je veut dire que le serveur de gestion de facture est certifié, je parle exactement de ton dernier paragraphe. Ensuite je n'est jamais dit que la certification etait utile. On peut parfaitement faire ta procédure entre le serveur/serveuse et le terminal : tu as un terminal "magique" avec une fausse entreprise qui paye la TVA "ailleur".
[^] # Re: Agrément ministériel (reste du monde)
Posté par ham . En réponse à la dépêche Logiciel de caisse Pastèque, version Datte. Évalué à -1.
Je dirais ca dépend de l'agrément en détail. Si l'agrément concerne la gestion des factures numérique et papier, on peut parfaitement faire un module/serveur de gestion de facture, et avoir un agrément sur ce composant seulement. Le reste n'a peut être pas besoin d'agrément et les modification peuvent être plus dynamique.
my 2 cents
[^] # Re: C'est pas standard, mais c'est pas fermé non plus
Posté par ham . En réponse au journal C'est un scandale !. Évalué à 2.
C'est assez discutable :
Adobe supporte le standard ISO 32000-1:2008 pour les formulaire en PDF. Ils l'ont développé et standardisé.
La question est plus :
1) pourquoi l'administration a décidé d'utiliser les formulaire non normé de la version PDF 1.5 plutôt que ceux de la version 1.2 (normé).
2) pourquoi le XFA n'est pas proposé par adobe comme norme (l'ISO leurs a demandé) et qu'en pense l'administration française et l’Europe (ca pourrais plus les motiver si l’administration leur demande)
A par ça je suis intéressé sur le parallèle entre XFA et RTF, il y a t il des examples d'utilisation non conforme du XFA crée par Adobe en comparaison avec les spécifications qu'ils donnent?
[^] # Re: C'est pas standard, mais c'est pas fermé non plus
Posté par ham . En réponse au journal C'est un scandale !. Évalué à 3.
C'est assez hypothétique que des gens qui se sont embêté a faire une spécification de 600 pages, plusieurs fois mise a jour, fasse exprès de casser des implémentation libre.
Il est beaucoup plus probable que tout changement soit vérifié et re-vérifié pour ne rien casser, simplement parceque si une mise-a-jour mineur commence a demander a tout le monde de mettre a jour le logiciel, ça va râler sec chez le client.
Ensuite :
- Le site indique un logiciel particulier a utiliser pour les documents, pas une norme/format spécifique, ça tend a pointer dans la mauvaise direction.
- l'Ordonnance n° 2005-1516 du 8 décembre 2005 : le lien n'est pas correct, ca devrais renseigner sur les contrainte législative imposé au service. Mais comme google est mon ami:
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000636232
--> pointe vers le RGI, fixé par decret :
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000021254225
--> point vers un site web non existant (http://www.references.modernisation.gouv.fr/)
--> http://references.modernisation.gouv.fr/ en fait
--> le RGI, qui doit servir de référence, ne contient rien sur les formulaires
Donc si vous ne trouvez pas le choix du format de fichier acceptable, je pense que la question est plus de savoir quand le RGI va considérer les formulaires administratifs et la bonne norme a utiliser, et pourquoi et comment un site a décidé d'un format, qui n'apparait pas trés aligné avec les principes du RGI (vu qu'un standard existe pour les formulaire).
# C'est pas standard, mais c'est pas fermé non plus
Posté par ham . En réponse au journal C'est un scandale !. Évalué à 2.
Parce que moi j'ai trouvé ça:
http://partners.adobe.com/public/developer/en/xml/xfa_spec_3_3.pdf
Il ne faudrait utiliser que des standards ouverts pour l'état, s'ils existent.
Ensuite un petit peu de Wikipedia en plus me dit que ISO 32000-1:2008 contient un système de formulaire, mais je ne sais pas quelle est la différence de fonctionnalité entre XFA et les formulaire standard.
Utiliser du XFA peut être justifié, et vu que c'est un format ouvert, ça va quand même.
La seule chose qui pourrais être un scandale c'est si XFA est utilisé uniquement parce que c'est vendus avec adobe et que le workflow est standardisé avec Adobe (tm) et on s’arrête la. Mais la c'est un peut dure de savoir.
Pour finir le drame a l'air de venir de mupdf qui redirige vers adobe, pas du format lui même.
[^] # Re: Question...(celui qui demande ne se trompe pas...)
Posté par ham . En réponse au journal Le mythe de la transparence réseau. Évalué à 1.
Correction :
ca fait longtemps que kwin et les autres logiciel de dessin de bord de fenetre utilise des extensions X non transparente sur le réseau.
Ensuite le "vieux" X est transparents, mon xterm et mon emacs ne voient pas de différence.
[^] # Re: Super workflow
Posté par ham . En réponse au journal Un debugger est-il indispensable ?. Évalué à 2.
C'est plus une question de discipline, au fil du temps mettre une trace pour chaque branche de code avec les variables discriminantes, c'est possible et ca marche assez bien.
De plus j'utilise cppcheck patché (ou tout autre outils d'analyse de code) pour suivre la discipline des dev.
C'est en général possible de configurer d'éditeur de code pour ajouter ca tout seul.
A l'usage les traces partout dans le code est plus efficace que les autres méthodes dans mon cas.
Comme ca on ne fait que des cycles de reproduction de Problèmes :-)
En fait (et ca doit etre la meme chose chez tout les gens serieux) on a plusieurs niveaux de traces et de log, les logs sont toujours disponible sur les systèmes en production, pas les traces.
Le tout va dans des fichiers, est configurable a distance (filtres, ..etc ).
En fait le debugger est utilisé pour les segfault (une fois tout les ans).
Pour des petits projets pas mal de méthodes peuvent marcher, mais quand ca devient gros je ne connais pas de méthode qui est plus efficace que plusieurs niveaux de traces.
# Lisibilité
Posté par ham . En réponse au journal [Attention, journal bookmark ET féministe] Tiens, prends ça, tu le mérites !. Évalué à -5.
Il y a beaucoup de chose, des bonnes pistes d'action, du fond. Mais c'est trop gros et la structure n'est pas adapté a un poste de cette taille.
Avoir des sections et des sous-sections visible dans le corps de l'article pourrais aider.
[^] # Re: Cityssimo
Posté par ham . En réponse au journal La poste by Colissimo. Évalué à 0.
Et en plus, ca marche pour pas mal de pays, mais ca peut etre payant (66 cents selon wikipedia).
Pas besoin de nouvelle case, procédure, ..etc juste utiliser un truc existant depuis plus de 150 ans (176 selon wikipedia)
[^] # Re: Merci de vos réponse
Posté par ham . En réponse au journal Problème de suivi d’un logiciel privateur. Évalué à 1.
Vu que j'ai pas vu la liste, les solutions libres existantes:
Gestionnaire complet de bibliotheque (http://en.wikipedia.org/wiki/Integrated_library_system)
Bibliotheques ###
eBook management (voir en dessous)
Comme les attentes c'est que ce soit facile a installer pour l'utilisateur et pour le developpeur, Greenstone ou NewGenLib peuvent etre une base, et les autres peuvent fournir des informations interessant sur le schema de base de donné/filtre d'import.
Une autre piste, c'est d'etendre un gestionnaire de eBook pour gerer l'aspect pret de livre et multi-utilisateurs, et de reutiliser l'aspect multi-plateforme, installateur, ..etc
Ensuite pour QT, il va tout de meme avoir une base de donnée, des imports des differents format de fichier, les système de classification dewey ou autre, et tout le process d'installation.
Dans tout les cas, bonne chance,
[^] # Re: Un autre, qui est suivi
Posté par ham . En réponse au journal Problème de suivi d’un logiciel privateur. Évalué à -2.
J'ai l'impression qu'Antony a un vieux logiciel avec des problèmes et qu'il cherche
a avoir un équivalent open source.
Ensuite je maintient que réutiliser des composants existant avec une interface spécifique fournis une architecture a considérer, car elle peut ouvrir a des solutions intéressante, tout en restant KISS (l'integration et le KISS est non trivial)
Les pistes proposé par baud123 ne sont pas incompatible avec les attentes des utilisateurs, de plus ils peuvent permettre d'avoir des solution hebergé par la bonne ame qui veut faire tourner ca sur une machine (support).
par contre un des critère a prendre en compte, c'est qu'il est possible d'avoir un export des donnés vers un version non hébergé.
Ensuite pour le KISS et le NAS, le mien c'est :
1) login,
2) Gestionnaire de module,
3) copie d'une URL,
4) cliquer sur installer,
5) cliquer sur demarrer,
Et j'ai mon serveur qui tourne.
Et le raspberry pi, Le use case que je vois c'est plutot :
a) le projet fournis une image pour carte SD pour raspberry Pi
b) C'est assemblé par magie et ca donne un boitier
c) un petit boitier fait le serveur ou est branché directement a une télé (0 maintenance)
l'instituteur fait c) , ou si il a le temps de telecharger un fichier et de le copier sur une carte SD, et de faire un boitier, il peu faire b)
Ensuite refaire un systeme de gestion de livre, avec une base de données, des sysèmes d'import, maintenir des base de livre et de classification. le tout pour peu d'utilisateur, c'est aussi possible.
Néanmoins je suis pas sur que ce soit aussi efficace dans le long terme que d'ajouter une interface 'école' a un project existant, et de faire des distributions intégré (que le projet peut aussi réutiliser)
[^] # Re: Un autre, qui est suivi
Posté par ham . En réponse au journal Problème de suivi d’un logiciel privateur. Évalué à -2.
l'un n'empeche pas l'autre
s/du tout/directement/
L'architecture des premiers est a priori partiellement adapté pour le second.
L'interface des premiers a priori non, mais une architecture potentiel peut etre:
1) avoir une installation (apache+cgi+BDD) pré-configuré
2) un frontend (appli spécialisé/navigateur+pages web) qui convient au second monde
Comme ca le second monde est content, pas de base de données mal faite, plein de feature au besoin, ca peut etre migré vers des solutions en ligne ou des appliances (NAS qui permet d'installer des truc dessus, raspberry pi si ca amuse des gens).
L'ideal c'est d'integrer l'interface "école" en upstream, et le reste c'est de packager les briques et la config pour des vielles machines.
[^] # Re: le schéma n’est pas documenté.
Posté par ham . En réponse au journal Problème de suivi d’un logiciel privateur. Évalué à 3.
Aprés un coup de Universal Extractor sous windows, un coup d'oeil aux *.BCD:
- un header et ensuite des structure de taille fixe
- un certain nombre de fichiers (Auteurs.BCD,Editeurs.BCD,Illustrs.BCD,Period.BCD),
on l'air d'etre : 2 byte, char [45][]
- Groupes.BCD : header:1 byte,
structure : char name[40]
byte noIdea[3]
char alsoNoIdea[40]
byte remaining[26]
- Utilisat.BCD : header : 2 byte
structure (2100 byte)
char user[40]
char group43
short noIdea;
char someString[10]
byte noIdea2;
char noIdea3[11];
char date[10]
byte aLongString[1983]
Ensuite : j'ai windows 7, et pas envie d'activer le mode de compatibilité XP, d'installer une VM pour ca, donc j'ai pas pu regarder les champs et faire un reverse-engineering plus poussé, mais ca a l'air plutot simple (i.e 2h de perl pour decoder des trucs de base, en faisant la cuisine, suffit de demander)
En remplissant une base avec des données unique, ca doit etre faisable de retrouver le format de la base.
A partir de ca, et pour repondre a la question, avant de recommencer un nouveau logiciel, il y a quoi comme logiciel open source existant ou approchant, c'est mieux de modulariser un logiciel existant pour fournir une interface ad-hoc que de reinventer la roue.
Google me dit que Koha (http://www.koha.org/) est puissant, mais une installation de koha pre-configuré pourrait peut-etre etre suffisant.
[^] # Re: Du XML ?
Posté par ham . En réponse à la dépêche Projet Lumberjack. Évalué à 3.
C'est une informational, pas une Standard Track. Donc pas normatif.
[^] # Re: accélérer quand on est doublé
Posté par ham . En réponse au journal De la bonne conduite sur autoroute. Évalué à 2.
a moderer, la conduite sur autoroute allemande est fatiguante:
- les distances de sécurité sont rarement respecté (et c'est dangereux)
- je me rabat dans une demis distance de sécurité, et zou ca freine franchement
- que conduire a 200km/h et plus implique de freiner tres souvent
Les méthodes de la police allemande me manque en france (radar de distance embarqué sur autoroute: tu colle, tu va discuter avec la police aprés), alors l'excité avec ses phare il l'a bien dans l'os et c'est tant mieux.
Derniere petite chose : il ne faut pas freiner sans raison valable, il est si simple de continuer en adaptant sa vitesse au danger (venant de derriere).
Reprocher a qqn de freiner sur autoroute en ayant conduit en allemagne est "rafraichissant".
[^] # Re: Problème de la taille des tabulations avec une limite de 80 colonne
Posté par ham . En réponse au sondage La taille de l'indentation de mon code source (tab ou espace). Évalué à 2.
les conventions a un moment t sont compatible avec celle de t-1, et pouf recursion j'usqu'a 80 colonnes.
et puis 80 colonne c'est trés bien sur les grand ecrans : on peut afficher 2 ou 3 code en parallele.
Pour finir la limite de niveau d'indentation est en général a suivre, en particulier pas toujours ( une bonne tripoté de parametre, une bonne tripoté de comportement pas combinaison, pas de solution universel pour rendre ca lisible.)
[^] # Re: Bienvenue chez les schizos
Posté par ham . En réponse au journal Les Logiciels Libre sont comme les microbes. Évalué à 1.
- de ne pas mettre "unknown contamination".
- de dire que l'OSS c'est risqué
Le reste est vrai, sans gestion correcte des licenses (OSS ou proprio) c'est la merde.
Avec les licenses proprio tu doit verifier les requirements, la license, le prix, que ca colle aves la strategie, que le departement legal soit d'accord, que les achats soient eux aussi d'accord, <insérer une boucle de négotiation avec les chefs de project, le departement legal et les achats>
6 mois apres tu commence le developement et tout le monde est bien au courant que ca a couté cher et de la license.
Avec l'OSS, le risque qu'une perssone trouve ca plus simple, plus rapide, et que ca l'emmerde moins est pas tout a fait négligeable non plus. Un bon ingénieur doit savoir faire ca tout seul, mais meme chez les ingénieurs, la diversité est de mise (la stupidité peut se manifester sous beaucoup de formes pour tout le monde)
La différence est que plus de gens doivent participer au process des licenses, c'est pas trés compliqué mais indispensable.
[^] # Re: Enfin de l'innovation ...
Posté par ham . En réponse au journal Microsoft invente le support de piles sans polarité. Évalué à 2.
- je part en reunion avec la souris dans ma poche, les souris avec fil ne rentre pas (le fil fait vraiment chier)
- je n'ais pas une jungle de fil dans mon sac a dos
- je peut cliquer a 10 metres, la souris dans la poche, c'est classe
- je n'ais pas besoin de brancher ma souris, juste un chtit bouton
ca depend de l'utilisation.