Guillaume Maillard a écrit 278 commentaires

Gnome (dont gdm fait partie) a presque 20 ans.

Il n'était déjà brillant à ses débuts, si vous avez eu la chance d'utiliser les premières versions vous vous souvenez surement de la galère juste pour le compiler et le paramétrer.
L'épisode "OpenedHand" n'a juste réussi qu'à dégrader "l'expérience" sur desktop, au profit du "mobile".
Au final, on se retrouve avec, entre autre, un gestionnaire de session qui occupe en permanence des mégas octets de mémoire vive, et on se félicite d'avoir gagné quelques centaines de mégas octets.
C'est sur que quelques mégas octets, ça ne représente plus rien, c'est juste la taille d'une page web… A réfléchir comme cela, on se retrouve avec un ordinateur qui démarre en plus d'une minute, et qui a déjà bouffé 1Go de mémoire… un milliard d'octet, rien que ça.

Difficile, impossible, on a déjà la crème de développeurs chez Gnome?

En 1999, QNX a sorti une version de son OS (v4) avec leur noyau temps-réel, les drivers (graphiques et réseau), un desktop et un navigateur internet sur une disquette de 1.4 Mo. Elle est encore téléchargeable : http://toastytech.com/guis/qnxdemo.html

En 2002, ils récidivent avec un truc beaucoup plus léché (QNX RTP), la doc complète, les outils de développements (graphiques), un player audio, un navigateur rapide, etc… une ISO de 260Mo. Voir cet article de preview de la version 6.2 pour le détail et des captures d'écran.

Bref, la transition "wayland" a bon dos.

J’apprécie toujours les news du style "xxx Mio de mémoire vive libérés", ou encore celles que l'on trouve régulièrement sur les performances "xyz est désormais 3000x plus rapide".

Le touriste pourrait se dire que c'est une super nouvelle, que les développeurs sont sacrements bons, qu'ils ont bossés dur pour arriver à ce résultat spectaculaire.

La réalité est tristement moins joyeuse, s'il est possible de faire de telle "optimisation" c'est qu'à la base toute cette "suite" logicielle est codée par dessus la jambe.
On ne peut qu'en conclure que leurs développeurs sont sacrements mauvais, qu'ils ont bossés un peu pour corriger leurs erreurs afin d'arriver à se résultat peu spectaculaire (gdm qui consomme 100Mo).

Il n'y a pas si longtemps, on avait un "desktop" fonctionnel avec des machines de 128Mo de mémoire vive et moins de 400Mhz.

Le compilateur n'est pas encore assez intelligent pour optimiser les accès, il peut réorganiser "un peu" les structures de données.

Mais pour des cas "simples" comme celui : multiplication de matrice

for (i = 0; i < N; i++) {
    for (j = 0; j < N; j++) {
        for (k = 0; k < N; k++)
            res[i][j] += mat1[i][k]*mat2[k][j];
    }
}

il faut un bon outil pour voir/comprendre le problème et écrire la version optimisée.

Maîtriser les allocations (nombres et tailles) est une chose, mais les gains importants en performance résident surtout sur les accès.
Plus ils sont "distants" les uns des autres moins les caches matériels sont efficaces.
De mémoire, il y a un facteur 200 entre la latence au niveau du cache L1 et la mémoire vive.

J'espère qu'un jour on aura un outil pour aider à optimiser les accès.

Et pour les cas où il faut diagnostiquer des lenteurs sur un serveur sans rien toucher ni perturber : https://www.youtube.com/watch?v=tYieP2s34YI . Bon courage pour faire ça en C++ :)

Pas besoin de refaire la bataille, le C++ (et le C) est gagnant de quelques pourcents.
Pour les calculs scientifiques, cela se vérifie avec scimark2 (FFT, calcul matriciel… ) http://scribblethink.org/Computer/javaCbenchmark.html

Ne connaissant pas clion, je peux te répondre sur les 3 autres que j'ai pu utiliser pour de vrais projets. Leur debuggers ne rivalisent pas avec celui d'Eclipse, la raison technique est simple : le fait de pouvoir discuter avec la JVM permet de tout contrôler et d'avoir un état complet et fiable de tous les threads, des "stacktraces" et des objets.

Pour JProfiler, c'est exactement la même chose, mais une vidéo sera plus parlante : https://www.youtube.com/watch?v=032aTGa-1XM et ce n'est qu'une toute petite partie des possibilités.
J’apprécie aussi beaucoup d'avoir une vue d'ensemble chronologique (en temps réel) sur les attentes liés aux IO et aux locks.

Pour Eclipse vs les autres, en C++ les IDE ne peuvent pas faire de miracle pour le refactoring ou la complétion à cause principalement des void** et des directives de preprocessing.

Je pense que la seule vraie façon d’appréhender les avantages du trio Java/Eclipse/JProfiler est de l'utiliser dans un projet conséquent.

Le GC est pénalisant quand il prend beaucoup temps, cad quand il y a un très grand nombre d'objets à se débarrasser. Mais la cause reste tout de même un très grand nombre de créations d'objets dans un temps très courts.

Allouer des objets par millions, c'est contre productif en C++ tout comme avec les langages avec GC (Java, C#, etc…) l'allocation mémoire est très pénalisante en C++ (moins rapide qu'en Java par exemple). De plus, la fragmentation mémoire augmente et l'utilisation de la mémoire vive aussi inutilement.

Avoir un programme performant en C++ c'est surtout s'assurer de minimiser les allocations et d'avoir le plus possible un "layout" mémoire optimal (localité des données).

En Java, il y a tout un tas de GC différents à utiliser en fonction des besoins.
Je pense que les programmeurs utilisant Unity se définissent plus comme programmeurs C#, le moteur Unity étant manipulé en C# à la manière d'une librairie quelconque. Bref, à moins de vouloir recoder un moteur 3D, on peut très bien se passer du C++ ;)

La guerre du "c'est qui le plus rapide" entre C++ et Java est terminée depuis un bout de temps.

Un code bien écrit en Java est en moyenne plus lent (de l'ordre de 10 %) car la JVM doit interpréter les instructions et compiler à la volée les méthodes les plus pénalisantes pour les performances.
Je parle de moyenne ici, il y a des cas (rares) ou Java sera beaucoup plus lent qu'un code ultra optimisé en C++ mais il sait être plus rapide dans certains cas (car la JVM est capable de générer du code machine mieux optimisé car elle a plus de contexte à l'exécution qu'un compilateur), ce n'est pas un mythe.
Les allocations mémoires en Java sont aussi beaucoup plus rapides qu'en C/C++.
Des centaines de benchmarks sont disponibles sur internet pour qui chercherait des chiffres précis.

Concernant le fait qu'il n'y ait pas de 'unsigned' en Java, c'est effectivement embêtant pour l'écriture du code mais en runtime cela n'a pas d'impact. Quand on pense que la gestion des 'unsigned' était prévue en Java 1.0 mais viré à la dernière minute car "pas le temps"…

Et si on parlait aussi du nombre de crash sans stacktrace et du temps de développement lors de la création de votre programme C++ ?

Avec 10 ans d’expérience en C++ et 20 en Java, de mon point de vue, le plus gros "gap" entre les 2 n'est pas tant le langage que les outils autours. Rien dans le monde C++ n'égale le trio Java/Eclipse/JProfiler.

Faut-il apprendre C++ de nos jours : OUI. Cela permet d'apprécier Java ;)

900 000 lignes de code, je trouve cela juste gigantesque (c'est des années de travail à temps plein).

Faut-il comprendre de vos explications qu'il a eu 911825 (921630-905) lignes de code supprimées? modifiées?

De ce que je comprend sur https://www.openhub.net/p/gimp , le code actuel de Gimp représente :
- 817267 lignes de code
- 125212 lignes de commentaires
- 190860 lignes vides

D'où une certaine incompréhension (toujours présente).

921 630 lignes supprimées

Juste pour pour la migration de vers GTK3 ?

Euh.. comment dire…
https://informationisbeautiful.net/visualizations/million-lines-of-code/

Ce qui est critiquable c'est le fait de prendre un standard "internationnal" (et pas le meilleur…) et d'en faire sous-truc, cad un standard "franco-allemand", documenté avec des fichiers XLSX. Tout cela sous couvert de la "Norme Sémantique Européenne EN 16931" (380,81 €HT chez Afnor).

Bref, c'était bien trop demandé à notre élite informatique de JUSTE permettre de transférer à l'administration française soit des métadonnées sous forme XML UBL avec la facture soit d'intégrer le XML en fichier intégré (PDF/A). On leur demandait même pas l'effort sur-humain de supporter UBL et CII ;)

J'en profite pour informer les lecteurs que le même développement a été réalisé dans notre ERP OpenConcerto (en natif sans librairie externe). Il sera disponible en standard dans la prochaine version (1.6).

Cela permet d'importer des factures fournisseurs et d'intégrer le xml 'Factur-X' dans le PDF des factures clients.

Notez qu'il existe bien d'autres standards tels que UBL (https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl) et GS1. Félicitation donc à notre élite informatique nationale pour avoir créé un nouveau standard.

Des oursins dans les poches? Pas de problèmes, on a pensé à vous :
http://code.openconcerto.org
Fichier:
/trunk/OpenConcerto/src/org/openconcerto/erp/config/mappingCompta_fr.xml

Les modules, c'est simple, on les copie dans le dossier "Modules" :)
Ils se gèrent ensuite via Fichiers / Modules.

Java, 6 Go de mémoire vive?!? Ouch.
OpenConcerto fonctionne pourtant parfaitement avec 512Mo avec de grosses bases de données…

A l'heure où je vous lirez ces lignes, mon OpenConcerto avec 11 fenêtres ouvertes depuis 8 heures sur notre base interne avec des milliers de facture, clients, etc… et chargé de 10 ans d'historique : 80Mo de mémoire vive sont utilisés.

Par contre côté navigateur internet, effectivement quelques gigas sont utilisés pour 30 onglets… ;)

https est maintenant activé pour https://code.openconcerto.org/
Merci pour votre retour!

Tout fonctionne bien avec les derniers OpenJDK. On a pu voir quelques bugs sur Swing sur la version 7 d'OpenJDK sur Linux, réglés depuis en version 8 d'OpenJDK.

Pas de vidéo à vous fournir, mais une réponse : vous pouvez mettre des droits par utilisateur et ainsi masquer des menus/fonctionnalités.

Pour les utilisateurs récalcitrants, je conseille de commander de manuel et de frapper l'utilisateur avec jusqu'à ce qu'il arrête de se plaindre de ne pas trouver le bon bouton (un annuaire peut convenir à cette tâche).

Merci c'est corrigé.

Pour la liaison sur un serveur "externe", OpenConcerto sait faire un tunnel SSL/TLS tout seul.

Devait arriver en 2017, mais arrivera en 2018 : client léger et interface web.

Merci! C'est corrigé.

C'est une base de données dédiée, des performances à gogo, les sauvegardes et la maintenance technique.

Je pense qu'on a un problème de lien depuis qu'on est passé full https :)
Le lien pour le code source est http://code.openconcerto.org/

On va corrigé ça rapidement.

Pour l'API, oui c'est prévu.

D'après https://www.ocsinventory-ng.org/fr/#ocs-pro l'accès à la roadmap est payante (offre pro), le lien sur la feuille de route n'est donc pas d'une grande utilité pour le lecteur "lambda".

Le problème que vous chercher à résoudre n'a pas de solution réalisable au cas ou vous l'auriez pas encore compris.

Vous aurez beau avoir un service distant (horodatage, blockchain, Chuck Norris etc…),
il suffit que le logiciel en amont soit modifié pour ne pas envoyer les informations (ou pas les bonnes) pour frauder.
Les plus érudits feront du "man in the middle" pour intercepter les messages.

Dans la pratique, la fraude va être beaucoup plus simple, les fraudeurs utiliseront 2 logiciels, un pour rire et imprimer un ticket de caisse au client, l'autre pour la caisse officielle.

Et pendant ce temps la… d'autres détourneront des milliards légalement :)

donc souvent 2% de ses utilisateurs.

Peut être que pour Photoshop, il y 98% de versions piratées, mais dans le monde de la gestion, le piratage est marginal. Une recherche sur "cegid compta torrent" donne le ton :)

Ça fait un peu tâche lors d'un contrôle fiscal, une réflexion de l'inspecteur du type "je ne trouve pas la facture de votre logiciel de comptabilité dans votre grand livre, pourriez vous me fournir la facture?"
La tendance des gros du marché est de migrer vers des logiciels en ligne à abonnement, cf Sage.

tu as bizarrement mis des critères différents ("utilisateurs" contre "utilisateurs légaux") entre chaque ligne.
On peut conclure par "utilisateurs acceptant de payer", et je ne vois pas où tu veux alors en venir : le problème reste de réussir à faire payer dans les 2 cas.

Pirater un logiciel GPL (dans le sens l'utiliser sans payer), c'est déjà plus dur à faire car par définition… gratuit.

Chose également importante dans le monde des entreprises : il est quasi impossible de se passer d'un logiciel de compta/gestion commerciale.

3 choix :
- utiliser un logiciel propriétaire, licence payante (ou pseudo gratuite pour certains mais avec d'autres contreparties)
- pirater un logiciel propriétaire
- utiliser logiciel libre, licence gratuite par définition

Pour 100 utilisateurs d'OpenConcerto, en gros on a 2% x 890 € soit : 1 780 €
Pour 100 utilisateurs de Sage (imaginons un produit à 890 €, 2% de piratage) : 98% x 890 € : 87 220 €

Le delta de revenu est assez important et explique en grande partie (de mon point de vue) pourquoi des logiciels comme Odoo ont besoin de cash pour pouvoir concurrencer les gros ERPs. Ce qui était la question d'origine :)

Assez simplement :
- pour les clients ayant un contrat de maintenance : 0 €
C'est le deal du contrat de maintenance, on assure le client d'avoir un logiciel opérationnel.
- pour les "je vais quand même pas payer un contrat de maintenance pour un logiciel gratuit" : 96 €
Soit 4 de nos jetons de maintenances (ceux bien chers à 24 € le 1/4 d'heure), parce que d'expérience on sait très bien qu'en moyenne on devra y passer une heure dans les abysses du "comment je peux payer?" "ma carte est refusée", "je viens de commander il y a 1 minute et j'ai pas encore reçu mon attestation", "est ce que l'attestation est valable sur Mac", "est ce que je peux revendre mon attestation", etc… :)
En gros, nous misons sur la quantité pour rentrer dans nos frais de développement. Le système de caisse actuel étant sans prétentions, on met plutôt en avant le reste : gestion commerciale, compta, paye…