Sommaire
Salutations !
À mon travail, nous utilisons actuellement pour la plupart de nos besoins des serveurs dédiés loués à une petite PME roubaisienne (connue pour son étroite collaboration avec le SDIS). Nous devons avoir à la louche une vingtaine de serveurs chez cet hébergeur. Globalement, on peut le dire, tout va bien. Son réseau est en carton, pirouette cacahouete, ses escaliers non-ignifugés… mais on a des redondances entre centres de données, tout devrait bien se passer.
Mais il y a une chose qui est difficile à supporter : le célèbre "Manager", l'espace client. Quiconque l'a déjà utilisé sera d'accord avec ces chiffres, mais pour d'autres ce sera peut-être une surprise.
- Temps requis pour se connecter : 7 secondes.
- Temps requis pour lister les serveurs après connexion : 3 secondes.
- Temps requis pour afficher les informations d'un serveur : 5 secondes.
Je ne plaisante pas, et il était en forme lors de mon test, j'ai déjà eu des temps à plus de 15 secondes pour afficher les informations d'un serveur par exemple.
Quand une urgence demande qu'on se connecte au KVM d'un serveur, ces temps s'ajoutent aux 15 secondes nécessaires pour que le KVM soit accessible et fait donc plus que le doubler (et encore, dans le manager c'est plus long que 15 secondes). Insupportable. Sans oublier tous les problèmes d'ergonomie inhérents aux applications web modernes (notamment parce qu'il faut 'aérer' les interfaces, quitte à ce que rien ne soit faisable sans devoir défiler ou aller dans différents onglets, mais aussi parce que les applications web ont leur limites ou juste parce que les concepteurs vivent sur leur nuage). Or, la logique chez OVH −au diable la subtilité− est simple : si les clients veulent une interface plus pratique, plus adaptée à leurs besoins, on donne des APIs donc ils peuvent la coder eux-même. C'est d'ailleurs sur cette logique que les applications mobiles et desktop (MoM et Momi) ont disparu. Du coup… ça m'emmerde, je déteste faire le travail d'une entreprise que je paie déjà pour ce service en théorie, mais pas le choix, il va falloir que je code un outil pour automatiser l'accès au KVM.
Choix des armes
Comme je le dis souvent (et j'ai toujours raison), on ne choisit pas vraiment son langage de programmation. Si on a, par chance, à l'intersection de toutes les contraintes plusieurs langages, alors on a un choix, mais voilà, ça ne sera pas un choix pleinement libre.
Mes principales contraintes :
- avoir des bibliothèques pour faire des applications graphiques (et pas du web, non merci),
- avoir dans les composants disponibles un moteur de rendu HTML complet (parce que le KVM est en «HTML5»),
- pouvoir intégrer des appels HTTP sans que ça ne soit la mort (pas de callbacks ou autre fonctionnement à l'ancienne, il va y avoir trop d'appels pour que ça ne finisse pas vite en code spaghetti),
- j'ai envie d'apprendre des nouveaux trucs, mais il faut quand même que je puisse avancer assez vite, la courbe d'apprentissage ne doit pas ressembler à un mur de parpaings.
À la base je voulais utiliser FreePascal et Lazarus, mais je n'ai pas trouvé de solution acceptable pour intégrer le KVM HTML5 (petits regrets sur l'absence d'un équivalent de COM sur nos environnements de bureau, il y a le KParts de KDE éventuellement mais quitte à utiliser Qt autant prendre QtWebEngine dans ce cas ).
Java, même combat pour le rendu HTML. C# avec WebkitGtkSharp par contre, ça pourrait le faire.
J'ai regardé Rust, mais rebelote sur le HTML, et le développement d'applications graphiques c'est pas encore trop ça.
Et il y a les traditionnels GTK/Qt en C/C++, et éventuellement les bindings Python (ou autre langage) pour ces derniers, à condition qu'ils intègrent QtWebEngine, QtWebKit ou GtkWebKit.
Pour que les appels HTTP soient «jolis», le plus simple reste les coroutines. Chance, c'est possible en C++20 avec les coroutines et qcoro pour l'intégration Qt (mais je n'ai rien trouvé pour gtkmm). Ou avec Python3 et qasync/asyncqt pour l'intégration avec Qt. Ça semble plus facile sur Python / GTK, mais je ne trouve pas de solution simple pour intégrer GtkWebKit dans ce cadre.
Étant donné ma contrainte sur la « quantité » d'apprentissage, j'ai préféré me rabattre sur C++20/Qt, pour me concentrer sur la découverte et l'apprentissage de cette implémentation des coroutines. C#/GTK m'intrigue, mais je reste inquiet par rapport aux outils de développement (MonoDevelop est mort, VSCode est propriétaire et ses plugins C# sont de mémoire propriétaires également)
Le développement
Je n'aimerais pas lire un journal «tuto - écrire une application C++/Qt». Par contre je pense que vous apprécierez peut-être d'avoir des informations sur les coroutines en C++ avec Qt, parce que franchement, c'est une bouffée d'air frais pour ce genre d'application.
Tout d'abord, si vous n'avez jamais utilisé QNetworkAccessManager et ses APIs pour faire des appels HTTP, petit rappel des faits. Vous instanciez cette classe et vous appelez dessus des méthodes get, post, put ou deleteResource (delete étant un mot clé du C++, le nom change, forcément…). Vous obtenez alors en retour un pointeur vers un QNetworkReply. Une fois que ce dernier émet le signal finished(), vous pouvez récupérer ce que le serveur vous a répondu.
Le problème, concrêtement, c'est si vous devez enchaîner deux, trois, quatre appels. Vous aurez alors un code ressemblant à :
auto reply1 = nam->get(QUrl("http://www.example.com/1"));
QObject::connect(reply1, &QNetworkReply::finished, [reply1, ui, nam] () {
ui->label1->setText("Request finished, yay");
auto target = QUrl(QString::fromUtf8(reply1->readAll()));
auto reply2 = nam->get(target);
QObject::connect(reply2, &QNetworkReply::finished, [reply2, ui, nam] () {
ui->label1->setText("Finished request 2, yay again");
reply2->deleteLater();
});
reply1->deleteLater();
});Et là, c'est pour deux appels. Lancer le KVM avec l'API d'OVH prend 3 appels, puis une boucle d'attente avec un appel répété, puis un dernier appel pour avoir l'URL… Bonjour l'armée de callbacks !
Écrivons avec QCoro l'équivalent du code qui précède :
auto reply1 = co_await nam->get(QUrl("http://www.example.com/1"));
ui->label1->setText("Request finished, yay");
auto target = QUrl(QString::fromUtf8(reply1->readAll()));
auto reply2 = co_await nam->get(target);
ui->label1->setText("Finished request 2, yay again");
delete reply2;
delete reply1;C'est beaucoup plus clair et lisible. On attend le résultat du premier get, on exécute du code, on attend le deuxième get, on exécute du code. En procédant ainsi, on se simplifie tellement la vie.
Et c'est pour ainsi dire «gratuit». Les coroutines sont des fonctions interruptibles, donc on n'a pas lancé des threads ou des processus en parallèle. Tout au plus utilise-t-on une quantité négligeable de RAM pour stocker l'état d'une fonction interrompue, pas beaucoup plus gros que ce que l'on utilisait (sans le voir) précédemment pour le contexte de nos fonctions lambdas.
Et du coup, pour les gens que ça intéresse, mon mini projet a une encapsulation basique de l'API d'OVH avec Qt et QCoro.
L'utilisation est simple :
auto ovh = new OvhApi{"https://eu.api.ovh.com/1.0", this};
ovh->setConsumerKey(key);
auto meInfo = (co_await ovh->get("/me/")).object();
qDebug() << meInfo;Sont cachés l'authentification avec la signature des requêtes, la construction de JSON, les concaténations d'URLs… On pourrait aller plus loin, mais à court terme, ce sera amplement suffisant.
Par ailleurs, si une base de données est instanciée (avec QtSql), on peut passer à get un paramètre pour préciser une durée de mise en cache de la réponse. Cela accélère d'une façon phénoménale l'application, l'API OVH restant désespérément lente…
auto ovh = new OvhApi{"https://eu.api.ovh.com/1.0", this};
ovh->setConsumerKey(key);
auto meInfo = (co_await ovh->get("/me/", 1h)).object();
qDebug() << meInfo;Certaines informations ne changeant que rarement (les spécifications d'un serveur, le détail d'une facture…), on peut mettre un cache très aggressif pour certaines données et avoir alors des appels instantanés.
Le résultat
C'est une application graphique, donc capture d'écran obligatoire.
Avec un KVM ouvert…
Les temps de chargement sont sans commune mesure avec les temps du manager d'OVH, surtout quand les caches sont chargés.
Et en prime, les pires pièges de facturation d'OVH que je connaisse (notamment l'engagement tacitement reconduit) sont clairement indiqués dans l'interface, pour aider à s'y retrouver.
Il y a plein de choses qu'on pourrait y ajouter. Mais ça fait le taf pour moi et mes collègues.
Pour ceux que ça intéresse, le code est là, sous licence GPL3 : https://git.entrouvert.org/entrouvert/OvhKvm
Forkez à votre guise, faites-en ce que vous voulez, comme je l'ai dit ça a fait son taf pour nous.
La bise, bon week-end à vous
PS…
«Tu devrais diffuser cette application aux autres clients d'OVH, je suis sûr que ça pourrait plaire.»
À cela, j'ai répondu, un peu en troll mais beaucoup parce que je refuse d'avoir à payer Apple pour diffuser mon appli «Peut-être, mais je refuse de diffuser une version sous forme de binaire pour MacOS de l'application, par contre une version Haiku pourquoi pas…»
C'est vrai ça, pourquoi pas… Pourquoi pas…
Hop, une VM avec Haiku, et c'est parti ! Qt a été porté sur Haiku, il y a un G++ récent, «ça va bien se passer» comme dit l'autre.
Surprise, dans les ports, QCoro est disponible !
Bon ben maintenant il faut que je soumette sur haikuports une mise à jour de QCoro, peut-être deux/trois autres petits trucs…
PPS…
Alors moi je bosse en DBA et admin sys, mais on recrute des devs python, pour ceux que ça intéresse… https://www.entrouvert.com/actualites/2023/embauche-developpeuse-eur-python-django/
# Incroyable !
Posté par Julien.D . Évalué à 10.
Superbe annonce de recrutement, on aimerait en voir plus souvent des comme ça !
C'est vrai que l'ihm et les api OVH sont bien lentes malheureusement.
Top ce projet, mais il faudrait en faire une version web, les clients lourds et efficaces ne sont plus dans l'air du temps ;)
[^] # Re: Incroyable !
Posté par Pinaraf . Évalué à 9.
L'annonce de recrutement est réellement un post scriptum, je voulais détailler mon travail pour porter sur Haiku, expliquer ce que j'ai compris de Haikuports… mais j'ai pas eu le temps de rédiger en 3 mois, et j'en avais marre d'avoir le brouillon qui trainait… alors j'ai écrit la conclusion, et j'ai ajouté cette phrase pour rendre service à la boite (enfin on est en coopérative, donc… pour me rendre service en fait)
Alors il y a le plugin qwebgl pour afficher des interfaces Qt en web…
[^] # Re: Incroyable !
Posté par Tarnyko (site web personnel) . Évalué à 2.
Je suis supris de voir autant d'intérêt pour Haiku dernièrement (comme cette dépêche) ; quelle motivation pour toi ? Parce que c'est léger et donc facile à partager en VM comme tu l'évoques ?
[^] # Re: Incroyable !
Posté par Pinaraf . Évalué à 4.
Parce que j'adore Haiku, ça fait des années que je passe au fosdem déposer mon billet à leur stand, j'ai déjà donné une machine sous Haiku à une personne de ma famille…
Je regrette terriblement que l'on n'ait plus vraiment d'OS libre pensé pour le desktop. Linux marche bien, évidemment, mais quand on regarde ce qui est fait sur Haiku pour, par exemple, la gestion des paquets, on a quand même quelque chose d'hyper séduisant. J'ai des souvenirs de Syllable et de SkyOS aussi (qui étaient non libres de mémoire)… Proposer une alternative qui ne soit pas juste un clone de l'existant, c'est indispensable si on veut voir une évolution.
[^] # Re: Incroyable !
Posté par barmic 🦦 . Évalué à 3.
Je ne vois pas bien en quoi un OS complet serait nécessaire. La partie bas niveau ne fais que de gérer le matériel. Je peux imaginer qu'il y a des tweaks différent pour serveur, bureau, smartphone, IoT,… Mais en soit ça ne me paraît qu'être de la configuration.
Par contre oui en terme d’expérience il y a beaucoup à revoir. Je ne connais pas le gestionnaire de paquet d'Haiku, mais les gestionnaires de paquets linux classiques sont très bien d'un point de vu technique, mail y manque une abstraction "Application" pour pouvoir naviguer plus simplement pour la personne moyenne. Ça aiderait aussi à la découvrabilité. Je sais que des systèmes de tags existent et c'est très bien, mais il leur faudrait une interface, un index plain text sur les descriptions, pour rendre tout ça un peu plus user friendly.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Incroyable !
Posté par Tarnyko (site web personnel) . Évalué à 1. Dernière modification le 24 octobre 2023 à 14:37.
Selon les chapelles, certains vendront Snap, d'autres FlatPak.
Moi je suis les pas de notre maître à tous : AppImage avec le système de mises à jour automatiques qui va bien.
Le fait que rien se détache encore montre ce qu'il reste à faire.
[^] # Re: Incroyable !
Posté par barmic 🦦 . Évalué à 4.
Ils ne capitalisent rien sur ce qui existe déjà. Il me semble que Gnome avait une tentative avec Gnome Application ou quelque chose comme ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Incroyable !
Posté par Sandburg . Évalué à 0.
AppImage, c'est ce qu'ils utilisent chez Ankama. Même s'ils disent ne pas "supporter" Linux.
[^] # Re: Incroyable !
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Alors, en principe oui. Mais ça a en fait des impacts assez profonds sur pas mal de choses. Par exemple, l'ordonnanceur du noyau. Sur un système de bureau, Haiku fait le choix de privilégier les threads qui sont liés à tout ce qui est sortie son et affichage. Pour ce faire, toutes les APIs natives de Haiku pour créer un thread obligent à donner un niveau de priorité, et les niveaux sont nommés ("display priority", "realtime priority", "background priority", etc). Sous Linux, la plupart des logiciels existants n'ont pas ce type d'info, et donc, l'ordonnanceur doit se débrouiller tout seul pour identifier les choses à prioriser, ou bien il faut le configurer à la main avec des fonctions comme nice, et, les valeurs choisies étant arbitraires, chaque application risque de toujours essayer de mettre "plus que les autres" pour passer devant.
On pourrait se dire que pourtant, Linux a plein d'APIs pour configurer des priorités, mais:
Donc on oublie, ça ne concerne que les algorithmes d'ordonnancement "realtime". Cela dit, Linux est plutôt bien équipé au niveau de l'ordonnancement realtime, par exemple avec SCHED_DEADLINE, mais ça demande de développer les applications d'une façon bien précise et plus complexe que ce qu'on a l'habitude de faire.
L'ordonnanceur de Linux est très bon pour des sysèmes serveurs ou il faut surtout gérer des connexions réseau et des I/O disque. Pour ce type de tâche, il vaut mieux exécuter les choses pendant plutôt longtemps et faire peu de changements de contexte. Au contraire, Haiku va plutôt changer de tâche plus souvent, pour donner l'occasion à toutes les fenêtres affichées à l'écran de se rafraîchir en une ou deux dizaines de millisecondes par exemple. Dans l'absolu, cela a un coût sur les performances, mais le ressenti est que c'est beaucoup plus réactif.
Est-ce que ce serait faisable sur une base de noyau Linux? Oui, sans doute. Il existe déjà quelques options de configuration du noyau (PREEMPT et PREEMPT_VOLUNTARY) qui vont changer le comportement pour être plus approprié pour un PC de bureau. Mais, comme toutes les distributions Linux actuelles ciblent à la fois le bureau et le serveur, c'est rare de voir ces options activées dans les noyaux proposés.
Voilà, c'était juste un petit exemple en regardant le cas de l'ordonnanceur, il se trouve que je connaît un peu le sujet à la fois dans Haiku et dans Linux. On a le même genre de questionnements avec l'allocation de la mémoire (s¡il n'y a plus de mémoire, sur un PC de bureau on peut afficher un message d'erreur demandant quoi faire, sur un serveur, il n'y aura personne pour répondre, il faut donc se débrouiller tout seul), la sécurité (les problématiques sur une machine de bureau et sur un serveur hébergeant des douzaines de machines virtuelles ne sont pas du tout les mêmes), etc.
Donc, oui, tout est possible, ça serait peut être un peu moins de travail.
Les autres aspects qui ont poussé Haiku à faire ce choix sont:
Il existe également plusieurs tentatives de réimplémenter quelque chose de proche de BeOS sur une base d'un noyau existant (Linux, BSD, ou même Windows). Aucun de ces projets n'est vraiment actif aujourd'hui. Peut-être simplement parce que ledéfi d'implémenter un nouveau noyau a attiré plus de développeurs, ou peut-être parce que c'était vraiment le meilleur choix technique à l'époque, même si aujourd'hui la décision serait peut-être différente. Cela dit, on entend plus parler de RedOX OS ou de Serenity que de la trente huit millième distribution Linux (même si certaines comme Hello System méritent probablement qu'on y jette un oeuil si on s'intéresse aux systèmes de bureau).
[^] # Re: Incroyable !
Posté par barmic 🦦 . Évalué à 2.
Linux a même déjà eu plusieurs ordonnanceurs "en même temps" (à choisir à la compilation).
Je me demande si la logique avec cfs pour gérer ce niveau de précision, ne devrait pas être que l'application crée des cgroups et dispatche ses threads en fonction. C'est plus souple car tu peu créer des groupes plus adaptés que les niveaux de priorité prédéfini (et tu peux configurer finement leur groupe), par contre c'est à chaque développeur de faire ces choix et effectivement aujourd'hui ça n'est pas pratiqué.
C'est bien sûr faux, ubuntu a une version dédiée bureau et un paquet de ses dérivées ne sont faites que pour le bureau. De même pour RedHat qui a des versions spécifiques pour bureaux, mais je suis d'accord que je n'ai pas l'impression que les distributions bossent véritablement dans ce sens. Sans aller jusqu'à avoir des logiciels réécris pour se comporter comme il faut avec cfs, il est possible déjà de lancer le gestionnaire de fenêtre dans son propre groupe. Ça avait était une super démo technique il y a pas mal d'année maintenant de comment on peut lancer une compilation du noyau en lui donnant beaucoup de thread tout en gardant une interface fluide.
Je suis pas certains que ce soit très pratique d'avoir une demande comme ça. C'est pas forcément simple de savoir quoi faire. Mais rendre le gestionnaire de fenêtre non ciblable par l'OOM-killer ce serait vraiment quelque chose de bien.
Je ne remet pas en cause Haiku. Ça n'était vraiment pas mon but. C'est très bien que d'autres chose que linux existent et tenter de faire autrement c'est toujours pertinent, même "en soit".
Mais j'ai l'impression qu'on pourrait déjà faire bien plus avec linux avec un vrai travail plus important pour les distributions orientées desktop (sur la manière de configuré et de compiler linux, systemd, la gestion des sessions, etc) et potentiellement des guidelines sur comment faire correctement des applications graphiques linux.
Je ne sais pas ce qui est plus simple entre faire évoluer un écosystème tel que linux ou créer un écosystème à partir de pas grand chose (pardon pour BeOS, mais leur écosystème me semble relativement petit, non ?).
Je pense aussi que certaines décisions au sein de la LKML ont pu refroidir ceux qui se lanceraient. Il me semble qu'à l'époque où cfs a était incorporé il y avait un concurrent techniquement très sérieux mais qui s'est fait sortir pour des raisons qui avait était très discutées à l'époque.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Incroyable !
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
Elles ont toutes les deux des images téléchargeables "bureau", mais dedans, c'est le même noyau que sur la version serveur, et de façon générale, le dépôt de paquets est le même.
On trouve bien chez Ubuntu un noyau "low latency" (https://packages.ubuntu.com/search?keywords=linux-image) (au milieu d'un tas de noyau optimisés pour différentes plateformes cloud) mais ce n'est pas celui installé par défaut. On ne le trouvera que dans les distributions dédiées à la musique assistée par ordinateur, où la latence est également très importante. C'est d'ailleurs probablement grace au travail des utilisateurs de Linux en MAO que ce noyau a fini par arriver dans les dépôts.
C'est donc bien ce que je disais: Ubuntu et RedHat ciblent à la fois les serveurs et les machines de bureau. Et c'est compliqué de faire les deux à la fois. Même si je comprend très bien qu'elles fassent ce choix: sur mon PC de bureau, je suis sous Debian, et je suis bien content que ma machine aie la même configuration que les serveurs de builds et autres machines de notre plateforme de test. Dans ce contexte, le gain en uniformité est tout à fait appréciable face à la perte en latence et en fluidité. Même si ça me fait râler quand je lance une grosse compilation Yocto avec trop de jobs en parallèle et que je peux plus bouger mon curseur de souris pendant 20 minutes à cause d'une combinaison de forte utilisation CPU, forte utilisation RAM, qui passe pas mal de temps à envoyer des trucs en swap, avant de finalement décider de lancer un OOM killer. Alors, oui, je pourrais passer du temps à essayer de mieux configurer tout ça, mais c'est le job que j'attendrais d'une distribution Linux dédiée au desktop, que ça vienne déjà réglé comme il faut.
[^] # Re: Incroyable !
Posté par Pinaraf . Évalué à 6.
Au début du 2.4 tu veux dire ? Je me souviens avoir commencé sur un 2.2.17 puis un 2.4.3. Wikipedia confirme que le 2.6 est sorti en 2003…
Pour du desktop, le 2.6 a introduit pas mal de choses, dont udev qui a quand même simplifié les hotplug/coldplug qui dépendaient des distributions et pouvaient «laisser à désirer».
[^] # Re: Incroyable !
Posté par Tarnyko (site web personnel) . Évalué à 2.
Tu vends du rêve, il faut que j'essaie !
(j'ai pourtant déjà des VM pour des OS aussi "niche" que NeXTSTEP ou IRIX, mais la différence est que je n'ai pas connu BeOS… pas de nostalgie personnelle. Ça se fera donc uniquement sur les mérites du "produit" !)
La faute, probablement, à dans l'ordre :
1) l'éparpillement des distributions Linux (Haiku, ReactOS… ont des "fournisseurs" uniques)
2) l'absence d'ABI stable (je vois que Haiku maintient GCC2 pour les vieilles libs BeOS, c'est défrisant pour certains… mais bien ce qu'il faut faire !)
3) rebelote des 2 points ci-dessus pour les environnements de bureau (GNOME ou Plasma ? Et même en restant sous GNOME : 2 releases mineures pètent les extensions… on se croirait dans le monde des mods de JV !)
[^] # Re: Incroyable !
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
SkyOS est non libre, mais Syllable est libre.
Malheureusement pour Syllable, le projet s'est quelque peut égaré avec le développement de "Syllable Server" (une distribution Linux), et une reprise en main du projet par le développeur du langage Rebol, qui essaie d'intégrer son langage à tout prix dans le système et a fait fuir les développeurs C++ qui maintenaient le projet.
Il a récemment relancé un site internet qui semble être surtout fait pour faire de la publicité (mal) dissimulée pour son nouveau langage de programmation appelé Meta (vous noterez par exemple la roadmap qui n'a aucun plan pour le développement de l'OS).
[^] # Re: Incroyable !
Posté par Tarnyko (site web personnel) . Évalué à 5.
Faut relativiser : le journal "vend" du C++, mais il recrute du Python ;-).
[^] # Re: Incroyable !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
C++ à défaut d’avoir trouvé chaussure à son pied non ? Je remets in-extenso : «
» Ceci n’empêche pas de chercher 1 pythoniste qui aurait su faire la même aussi vite et simplement pour ce cas de figure (y compris le KVM en HTML5)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Très prometteur
Posté par kolter (site web personnel, Mastodon) . Évalué à 7.
Bonjour,
Merci pour cet outil que je n'ai pas encore testé mais qui va m'être très utile.
J'envisage de le packager mais 2 questions me viennent à l'esprit :
Merci pour le boulot en tout cas.
[^] # Re: Très prometteur
Posté par ted (site web personnel) . Évalué à 3. Dernière modification le 21 octobre 2023 à 20:54.
Pour le nom, ce serait sympa de trouver un mot contenant les lettres O, V et H. En français je n'ai rien trouvé de pertinent, mais en anglais il y a pas mal de mot commençant par "overh" par exemple, j'ai aussi trouvé "overarch".
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Très prometteur
Posté par orfenor . Évalué à 6.
OVH est aussi une racine fréquente en Klingon.
[^] # Re: Très prometteur
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
via https://www.dcode.fr/mots-contenant par exemple, on a un millier que je doute de trouver dans le dico des noms communs.
via https://www.listesdemots.net/c/h/2/motscontenanthv.htm par exemple, c’est bien mieux ; mais rien qui commence par O et rien avec ces trois lettres dans l’ordre voulu.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Très prometteur
Posté par arnaudus . Évalué à 10.
OhlaVacHe?
[^] # Re: Très prometteur
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 23 octobre 2023 à 14:56.
OnVaHisserleMom ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Très prometteur
Posté par Pinaraf . Évalué à 4.
De rien, merci pour les commentaires.
Houla les questions pièges !
Le nom est constitué de l'usuel «quoi que ça bidouille» + «quoi que ça fait». Mais oui si c'est pour une vraie diffusion, le «quoi que ça bidouille» étant une marque ici, c'est pas forcément gagné, d'autant plus que je me suis amusé à reprendre l'antique logo d'OVH en icône de l'application… Je ne suis en tout cas absolument pas attaché au fruit de mon absence d'imagination.
Après je note que j'ai dans les paquets disponibles des aws-machin ou aws-bidule qui ne sont pas codés par amazon… Donc je m'inquièterais plus pour l'icône que pour le nom.
Quant à la seconde question, la première release… J'avoue que je ne me posais pas de question, si ça peut servir à des gens, je peux voir pour en faire une très prochainement. Jusqu'à maintenant 100% des utilisateurs faisaient git pull + make ou ninja selon l'humeur, et 100% des utilisateurs se satisfaisaient de ça…
[^] # Re: Très prometteur
Posté par Pol' uX (site web personnel) . Évalué à 5.
On Va Huiler/Hoqueter/Huer/Honnir/Homogénéiser/Heurter/Hisser/Hâter/Harasser/Habiller.
Adhérer à l'April, ça vous tente ?
[^] # Re: Très prometteur
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 5.
Octave étant déjà pris, on pourrait aussi penser à Tatave.
[^] # Re: Très prometteur
Posté par Pinaraf . Évalué à 5.
Du coup, vu que c'est de votre faute d'abord, je demande "l'avis de la commu" (je crois qu'on dit ça de nos jours, pas sûr)… Est-ce-que "Momoq" ça irait comme nom, inspiré des anciens Mom, Momi et Moma pour ceux qui ont connu OVH y'a 10/15 ans…
[^] # Re: Très prometteur
Posté par kolter (site web personnel, Mastodon) . Évalué à 3.
Ou Momok.
Au début j'avais pas pensé à KVH (Contraction de KVM over OVH).
# vscodium
Posté par seraf1 . Évalué à 4.
Pour les IDE, as-tu regardé vscodium, la version openSource de vscode ?
[^] # Re: vscodium
Posté par Pinaraf . Évalué à 10.
vscodium est open source oui. Mais le «market place» est limité à vscode. De plus plusieurs de leurs extensions sont avec des licences fermées.
La licence pour l'extension C# officielle est par exemple :
https://marketplace.visualstudio.com/items/ms-dotnettools.csdevkit/license
Mais qui va le voir dans un environnement qui fait allègrement (oserais-je dire volontairement ?) la confusion entre free et free, la confusion entre vscode fermé et vscodium open source…
Du coup je suis heureux avec Qt Creator, Kate et KDevelop.
[^] # Re: vscodium
Posté par Pinaraf . Évalué à 6.
Heureuse coïncidence, cet excellent article sur le problème qu'est Visual Studio Code vient de passer dans mon radar, je n'en avais pas souvenir…
https://ghuntley.com/fracture/
[^] # Re: vscodium
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
On en avait parlé sur ce site… https://linuxfr.org/users/bfg/liens/visual-studio-code-is-designed-to-fracture
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# captures d'écran
Posté par Gof (site web personnel) . Évalué à 4.
C'est peut être juste moi, mais je ne vois aucune image ou lien vers des images. (Firefox Android)
[^] # Re: captures d'écran
Posté par gUI (Mastodon) . Évalué à 4.
Sous FF Android je vois bien les captures d'écran, juste sous cette phrase.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: captures d'écran
Posté par Pinaraf . Évalué à 5.
Nan mais vous faîtes tout pour m'embêter de toute façon.
L'autohébergement, c'est bien, mais quand y'a une coupure de courant et que derrière il faut s'en rendre compte, aller rallumer le serveur et saisir la phrase de déchiffrement des disques, ben ça fait des coupures. Le serveur était éteint de ~21H à ~22H50. Et forcément c'est le moment où tu as essayé. C'est vraiment trop injuste.
Mais j'envisage une redondance électrique, promis, ça serait pas difficile à mettre en place vu l'installation.
# Les coroutines c'est bien, mais c'est pas la panacée
Posté par xryl669 . Évalué à 5. Dernière modification le 10 novembre 2023 à 10:45.
Typiquement, les coroutines (et le async/await en général) résolvent un problème que l'on aurait jamais eu si on avait pris le bon design dès le départ.
Le problème initial, c'est de vouloir faire un code avec des callbacks, parce que, asynchrone tout ça… Et de réfléchir à chaque ressource comme si on devait y accéder avec un chemin complet: "s'authentifier, demander X, puis Y, enfin Z".
Du coup, on trouve du bon vieux
QNetworkReplyavec ses callbacks/signaux Qt imbitables.En réalité, le fonctionnement de ce type d'API (authentication/authorization/actions) est typiquement une machine à état. Ton client doit prouver un état (il est authentifié, et autorisé à accéder à une ressource) mais après les requêtes sont assez simple en 1:1.
Dans l'exemple précédent, X, Y c'est juste un état. Une fois demandé, le client est X ou Y, tu peux demander Z directement, voire W si W dépends de X uniquement.
Et donc, typiquement, le bon design, sans forcément faire appel aux coroutines, c'est de maintenir une variable d'état et une boucle principale qui agit sur cet état. En pseudo code c'est aussi simple que:
Ici, tout est replié sur un seul niveau d'asynchronisme, et plus des asynchronismes imbriqués. Tu enregistres la fonction que tu veux voir exécutée dans le client, et lorsque tu déclenche l'action d'accéder à la ressource, le client te retourne le résultat, de manière asynchrone, sans que tu n'aies à implémenter toute la logique d'accès à chaque objet qui t'intéresse.
Le
mainLoopci-dessus, c'est en gros le scheduler caché dans les coroutines, sauf que c'est un code qui ne cache rien du coup sans utiliser les trucs comme la sauvegarde de la pile et les pseudo tâches.Surtout, tu peux exécuter des requêtes en parallèle (tu peux avoir plusieurs threads qui gèrent un mainLoop avec le client partagé), ce qui est très difficile à faire correctement avec les coroutines, car justement lorsqu'une coroutine est en "await", elle est ininterruptible (vu que techniquement, elle n'existe même plus sur la pile d'appel).
[^] # Re: Les coroutines c'est bien, mais c'est pas la panacée
Posté par Pinaraf . Évalué à 4.
J'ai jamais pensé à répondre à ce commentaire, toutes mes excuses.
Je trouve affreusement verbeuse et lourde cette façon d'exécuter les requêtes justement. Pour un gros programme je peux comprendre l'investissement, mais là pour ce besoin c'est impossible.
Et je ne suis pas d'accord avec ce point. Alors certes je ne lance pas plusieurs threads, mais parce que ça ne sert à rien pour du code qui passe son temps à le perdre dans des appels externes. Mais sur l'un des écrans de l'utilitaire, je viens à l'instant de paralléliser la récupération des données. Le changement a ajouté une dizaine de lignes de code.
Le (pseudo-)code précédent était :
Le changement a été super simple : isoler le contenu de la boucle for dans une fonction, et passer par les signaux/slots plutôt que par un appel direct ou une coroutine.
ie
et fetchServerInfo est une coroutine reprenant à l'identique le code qui était dans la boucle for.
L'interruption des coroutines fait un retour à la boucle d'événements, qui va alors lancer la coroutine suivante. Ce qui permet donc de paralléliser les appels web derrière.
# Pour ceux qui se demandent...
Posté par lym . Évalué à 2. Dernière modification le 10 novembre 2023 à 21:11.
… ce que sont les coroutines, une implémentation en C avec explications:
https://github.com/Rachid-Koucha/crtn
# Bon diagnostic, mauvais remède
Posté par Tortilla . Évalué à 1.
Tout d'abord bravo pour le boulot et cette transmission écrite, c'est brillant de l'avoir mené à bien. Rien de ce que je vais dire ne voudrait remettre en doute ce fait.
Je partage le même constat sur le manager d'OVH, c'est une abomination. Mais il ne faut pas se tromper de cible: il est lent à ch… (non mais vraiment, c'est une honte!) mais ce n'est pas la faute des technologies (web) employées. C'est la faute que c'est un logiciel horriblement mauvais, fait par des gens horriblement nuls! Comment on peut foirer à ce point les performances d'un truc pareil? Incompréhensible, et d'autant plus quand on a leurs moyens (ça laisse présager le pire pour cette entreprise cotée)! N'importe quel programmeur venant du bas niveau, donc peut être plus sensible à la performance et à l'architecture logicielle (comme OP) pourrait faire une version web qui serait en tout point équivalente aux performances ressenties d'un logiciel compilé. Avec en prime les avantages énormes du web, diffusion à portée de clic, mise à jour centralisée, multi plateforme de facto, facilité de développement dans la problématique présente (tout est inclus, les requêtes, le KVM web). Aussi la possibilité d'une très grande mutualisation du code pour une version lourde en Electron (est-ce pire que QtWebEngine?).
Je ne souhaite pas me faire le chantre de la programmation web, ce n'est pas spécialement mon truc. Mais on dirait que par amour du code compilé (qui a quand même son lot de désagréments), ou par détestation des nullités du web (et il y en a!), on se refuse les avantages d'une programmation web efficace.
[^] # Re: Bon diagnostic, mauvais remède
Posté par Pinaraf . Évalué à 3.
Excuse-moi cette question, mais : où as-tu lu ça dans mon journal ?
Ma critique quant au côté web du manager OVH se limite à "Sans oublier tous les problèmes d'ergonomie inhérents aux applications web modernes", je n'ai pas parlé de la techno elle-même. Et plus loin j'ai dit "avoir des bibliothèques pour faire des applications graphiques (et pas du web, non merci)", sans détailler mes raisons.
Et pourquoi devrais-je les détailler ? N'a-t-on plus le droit en presque 2024 de juste préférer l'ergonomie d'une application qui respecte le thème de mon bureau, qui consomme uniquement les ressources nécessaires (étant sous KDE, Qt est déjà en RAM, et le WebEngine n'est chargé que quand on ouvre un KVM, ce qui n'est plus le seul usage de cet inutilitaire maintenant) ? N'a-t-on pas le droit de préférer la beauté d'une application native, et les outils de développement qui vont avec ? Si tu souhaites développer l'équivalent en techno web, n'hésite pas un instant, tu feras de nombreux heureux, et je lirais avec plaisir un journal similaire portant sur d'autres technologies.
Au passage, quitte à taper sur OVH, petite anecdote : le développement de cet outil m'a fait découvrir plus de 2000€ sur le compte "fidélité" de l'entreprise, mais qu'il n'est plus possible d'utiliser facilement avec les derniers développements du "tunnel de commande" ou du renouvellement des services d'OVH.
[^] # Re: Bon diagnostic, mauvais remède
Posté par Tortilla . Évalué à 1.
Les critiques (certes succinctes) envers le "web" que tu cites confirment bien une certaine aversion que j'avais perçue à la lecture de ton journal. J'ai l'impression de la croiser souvent chez les programmeurs bas-niveau. Et si je pense savoir d'où elle vient, je la comprends de moins en moins, d'où ma réaction.
La programmation web offre aujourd'hui un tel socle éprouvé de développement, avec comme premier avantage l'interopérabilité, que c'est pour moi incompréhensible de revenir à des solutions plus "segmentantes", surtout pour un cas d'utilisation si adapté.
Merci en tout cas d'avoir explicité les raisons qui te font choisir Qt. Tu as bien sur le droit de préférer tel ou tel environnement de développement, en particulier pour un "inutilitaire" sans trop d'enjeu.
[^] # Re: Bon diagnostic, mauvais remède
Posté par Pinaraf . Évalué à 2.
Allez, pour le fun…
Pour diverses raisons non précisées (RGPD je suppose) OVH ne permet plus de télécharger directement le PDF d'une facture, il faut obligatoirement avoir une session web authentifiée pour ouvrir le lien qui est exposé dans l'API.
Donc dans mon inutilitaire, j'instancie un WebEngine que je contrôle pour accéder à l'authentification puis lui piquer ses cookies et faire le téléchargement.
Comment tu implémentes ça dans un navigateur web sans que ça ne puisse pourrir une autre session en cours ?
Le code C++ sale est là : https://git.entrouvert.org/entrouvert/OvhKvm/src/branch/main/ovhwebauthentication.cpp
(en le relisant à l'instant je me dis que j'aurais du ne mettre que des coroutines alors que là je mélange callbacks et coroutines, c'est pas beau)
[^] # Re: Bon diagnostic, mauvais remède
Posté par Tortilla . Évalué à 1.
Si tu tiens à cette fonctionnalité et qu'elle n'est pas exposée par l'API, tu n'as effectivement pas le choix que de bricoler une solution hors navigateur.
Ce qui veut aussi dire que ta solution pour te passer d'un outil dépend de ce même outil… On touche au problème métaphysique là ;)
[^] # Re: Bon diagnostic, mauvais remède
Posté par Pinaraf . Évalué à 3.
Pas du tout, ça dépend juste d'une session sur le site qui affiche les factures, et de l'auth qui va avec. Pas de l'odieux manager.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.