JGO a écrit 2437 commentaires

Pour ce que je connais, voir cette url, en particulier le décret et la circulaire traduits en anglais qui fixent les critères techniques pour la signature électronique des factures émises. Et la liste des logiciels certifiés contient déjà 1815 noms.

La liste de vos utilisateurs montre que, si la majorité est située en France, il y en a aussi à l'autre bout de la planète. Dans certains pays, les logiciels de caisse (émettant des tickets et/ou des factures) doivent être agréés par le ministère des finances (il s'agit d'éviter les fraudes à la TVA). Avez-vous fait des démarches en ce sens pour vous implanter sur ces marchés ?

Sam E. a jugé « pertinent » le commentaire « Nouveau camion de campagne » de xaccrocheur — service communication de linuxfr+

J'oubliais de dire que R.A.S. est une super bonne idée et merci pour le code.

C'est un système de calendrier qui émet des alertes par mail. Ça a un intérêt plus large que la randonnée, peut-être que vous pourriez fournir des personnalisations pour d'autres situations… Mais sinon, voilà une autre solution pour client léger :

sleep 86400 && mailx -s "Je me suis perdu en montagne !" maman@example.com < intinéraire.txt

Merci pour le logiciel et pour la dépêche. Cependant j'aurais bien aimé un petit exemple directement dans la dépêche. Je pourrais fouiller sur github et/ou lire le code, mais ça serait tellement plus pratique d'avoir juste au-dessous un exemple basique pour illustrer le propos, surtout que c'est la première fois que ce logiciel est présenté et donc personne n'est censé déjà connaitre.

Là on en est déjà à négocier sur comment je pourrais changer mes habitudes de travail pour m'obliger à utiliser les protocoles limitatifs de Microsoft. Donc…

si tu en es à exporter plusieurs fenêtres,

J'ouvre et je ferme des fenêtres rapidement en permanence et presque exclusivement depuis mon terminal, que ce soit sur ma machine locale ou une machine distante.

autant exporter un bureau complet, ça ne changera pas grand chose.

Comme indiqué plus haut, ça doit marcher pour plusieurs utilisateurs sous le même nom au même moment, en même temps que pour l'utilisateur physiquement devant le terminal. Il n'y a qu'un seul compte et l'utilisation est locale aussi bien que distante, le contrôle de bureau complet n'est pas possible.

Même si ça marchait, il y aurait plusieurs inconvénients.

• Ça emprisonne les fenêtres dans un morceau d'écran (tu te souviens dans les années 90 quand les logiciels pour windows 3.1 te permettaient d'ouvrir plusieurs documents dans leur fenêtre principale… ça a été abandonné depuis longtemps et je n'ai pas envie de ressusciter le concept).
• Je ne peux pas utiliser les fonctions de mon gestionnaire de fenêtres (mise en onglets, passage de la fenêtre à un autre bureau, alt-tab pour changer d'application entre les fenêtres locales et distantes) et non je ne peux pas demander à installer des gestionnaires de bureau additionnels sur ces serveurs. En résumé je ne peux pas arranger les fenêtres distantes avec les miennes pour travailler agréablement.
• Les clients de contrôle bureau ont besoin d'intercepter le clavier et les raccourcis de la machine locale ne fonctionnent donc plus.
• La vitesse de mise à jour n'est aussi pas la même si le mouvement de la fenêtre est géré de façon distante avec le fond d'écran, les effets de bureau éventuels, etc. Sur le réseau gigabit c'est jouable mais depuis chez moi c'est mort.

ça laisse le temps aux solutions d'arriver.

J'en suis réduit à espérer qu'il y aura mieux que RDP et VNC. je ne me suis pas documenté sur D'après les discussions sur cette page NX est un peu de la bidouille. Il me reste à me documenter sur x2go et SPICE.

il suffit d'ouvrir une session pour chaque connexion

Si je comprends bien, je dois ouvrir une session pour « rdp /usr/bin/xterm » pour faire des opérations en ligne de commande, puis quand je veux éditer un fichier je dois lancer une session pour « rdp /usr/bin/kwrite ». C'est chiant, je ne peux pas simplement taper mes commandes dans xterm avec des arguments en direct sur la ligne de commande. Je peux le faire sur le shell de la machine locale mais du coup il faut que je connaisse les chemins et noms de fichiers par cœur (aussi chiant que scp en ligne de commande; personnellement j'envoie toujours mes fichiers vers ~ et je les déplace ensuite, tellement c'est chiant de devoir taper les chemins distants sans la complétion).

Je précise que : j'ai regardé les pages de rdesktop et freerdp, des instructions pour Ubuntu et pour Arch mais pour l'instant les gens se focalisent sur la possibilité d'administrer un bureau windows complet, du coup pas de détails sur la connexion entre deux machines linux su point de vue de remplacer ssh. Les recherches sont polluées avec les trucs pour windows ou je n'ai pas les bons mots-clefs. Par exemple pour une recherche « rdesktop replace ssh » j'ai des résultats pour « rdesktop over ssh to replace […] » (application proprio) mais ce n'est pas ça que je veux.

C'est tout à fait possible sous Linux, je ne connais pas de protocole ayant cette limitation.

Eh bien le contrôle de bureau en général est limité à une seule personne à la fois (ou peut-être plusieurs utilisateurs s'ils lancent indépendamment une instance de bureau). Ce n'est pas très clair dans mon esprit si on peut juste contrôler une fenêtre qui doit être physiquement affichée (auquel cas ce genre de limitation peut exister) ou si on peut vraiment lancer autant d'instances que l'on veut depuis les utilisateurs que l'on veut (auquel cas c'est similaire à ce qu'on fait avec ssh -X et tout va bien).

Merci encore de cette réponse précise.

Je n'ai pas dit que ça devait accepter les requêtes de n'importe qui. Sans rien changer à ta configuration par défaut, c'est possible aujourd'hui pour un utilisateur légitimement identifié par ssh, avec DISPLAY=:0. J'aimerais pouvoir conserver cette possibilité.

Tu as lu les commentaires sur RDP?

Oui ; parmi tous les commentaires de cette page, le seul pertinent par rapport à ma question est celui de Xavier Claude auquel j'ai répondu avant-hier, et qui indique que ma condition 1) est vérifiée (possibilité de lancer une application distante dans une fenêtre locale). Aucun commentaire depuis ne m'indique clairement si mes conditions 2) et 3) sont vérifiées (lancer depuis la ligne de commande locale une application affichée sur le serveur distant, et le fait de ne pas être bloquant pour les autres utilisateur simultanés en particulier s'ils utilisent les mêmes identifiants).

(Je pourrais passer mon après-midi à apprendre sur RDP et la demi-douzaine de protocoles mentionnés sur cette page, mais c'est pas sur cela que portait ta remarque et c'est un autre problème ; j'ai choisi de poser une question avec 4 points dans un commentaire sur linuxfr, qui est justement un site tout à fait adapté en première approche pour poser ce genre de questions.)

Dans ma vraie vie, je dois utiliser VNC et SSH sur le même réseau gigabit entre les mêmes machines. Je constate que VNC rame nettement plus que SSH. Évidemment ce n'est pas magique, il doit y avoir des raisons (en particulier VNC doit mettre à jour un écran complet avec une image de fond d'écran, alors que SSH ne met à jour que sa fenêtre) mais ce qui compte dans la vraie vie, c'est mon « expérience utilisateur » et avec VNC c'est exécrable.

Plus les bugs des serveurs et clients VNC : le serveur VNC sur la machine distance fout en l'air le clavier à chaque fois qu'une connection distante est lancée ; le client a des problèmes avec le scrolling. On va dire que c'est pas la faute du pauvre petit protocole VNC si les logiciels ont des bugs. Mais en tant qu'utilisateur, je m'en fiche de savoir d'où viennent les problèmes et pourquoi personne ne les a encore corrigés. Je constate que ssh fonctionne mieux et même bien mieux pour réaliser mes tâches quotidiennes.

Si Wayland m'offre une solution au moins aussi bonne pour mes tâches, je suis preneur. Ma spécification est la suivante : 1) possibilité de lancer une application de la machine distante dans une fenêtre de la machine locale ; 2) même chose mais la fenêtre s'affiche sur la machine distante ; 3) possibilité de faire les opérations précédentes pour plusieurs utilisateurs loggués sous le même nom au même moment. 4) En plus, je voudrais que dans la version finale, les performances, la stabilité et l'utilisabilité des clients et serveurs soient au moins aussi bonnes qu'avec ssh actuellement.

Les solutions proposées par Wayland (rdp si j'ai compris) permettent-elles cela ?

Même VNC fonctionne mieux.

Là je dirais que c'est tout le contraire, VNC est inutilisable (il parait que RDP c'est mieux que VNC mais j'ai pas testé). Je travaille de façon très fluide, sans latence et sans bug graphique en me connectant (gentoo) à une machine distante (RHEL 5) avec ssh, alors qu'avec vnc (krfb/krdc) entre les deux mêmes machines c'est inutilisable : bugs de clavier, actualisation des fenêtres lent, etc. Même en connectant un portable (Mageia 3) sur la prise réseau à côté de la mienne, l'affichage vnc est plutôt lent et graphiquement buggué, alors qu'avec ssh je n'ai pas ce problème.

Je ne milite pas pour la transparence réseau à tout prix, mais j'ai besoin d'une solution effectivement utilisable pour lancer des applications graphiques à distance, et pour plusieurs utilisateurs connectés au même moment sous le même nom d'utilisateur. Si leur réponse c'est vnc j'ai plus qu'à garder X11 sur ma machine (heureusement avec gentoo ça sera possible, comme d'habitude).

ce sont plutôt les autres compositeurs qui devront les intégrer.

C'est plutôt ça qui m'inquiète. C'est sûr que les poids lourds comme kwin ou mutter vont intégrer les protocoles nécessaires, mais les plus petits projets qui naitront n'en auront pas forcément les moyens humains. Ce qui veut dire, si je fais tourner wayland avec les compositeurs futurs qui rempliront la niche actuelle d'openbox ou xmonad, je ne pourrai pas forcément me connecter à une machine distante.

Ou alors il faudra que je tape startkde dans une console avant de pouvoir lancer ssh -Y, ça va être super. MODIF : non ça ne marchera même pas, kde fonctionnera avec le compositeur actif et kwin ne se lancera pas.

vouloir, aujourd'hui, faire un protocole qui fonctionne à la fois en local et en distant, ça n'est pas efficace.

Tu parles d'efficacité du point de vue management du projet et de ses évolutions futures, ou de l'efficacité en termes de rapidité d'affichage ? (En quoi la rapidité de l'affichage dépend-elle de savoir si la fonctionnalité est intégrée dans Wayland ou dans Weston ?)

C'est possible de n'afficher qu'une applications avec RDP

J'espère qu'ils gèreront d'autres protocoles ayant cette capacité. S'appuyer sur les protocoles de MS pour une fonctionnalité aussi utile, ça me parait peu avisé. MS pourrait décider de fermer la prochaine version du protocole et les auteurs de compositeurs devraient alors gaspiller leurs ressources à jouer au chat et à la souris pour accompagner les changements du protocole d'année en année sans aucune documentation, ou bien forker le protocole dans leur coin pour l'améliorer selon les besoins futurs, et fragmenter la compatibilité. Et là je me demande, pourquoi ne pas forker dès maintenant le protocole. Pérenniser le protocole de connection entre machines Wayland est un but plus important que de d'accompagner les changements d'une cible propriétaire en mouvement.

Il y a aussi « noyau sécurisé ».

J'ai utilisé le Grand dictionnaire terminologique de l'OQLF (www.granddictionnaire.com), la banque de terminologie technique franco-anglaise (et latine) de référence. Dans ce dictionnaire, « hardened » est donné avec son sens en métallurgie et un sens médical (recuit d'alliages de dentisterie sous la flamme). Maintenant si tu étends ta recherche à « hardening » (le terme décrivant le procédé et non pas l'adjectif décrivant l'état final), tu trouves des traductions en industrie sucrière (« prise en masse »), tabac (« endurcissement du plant »), photographie (« réduction du tannage de la gélatine »), etc. En ce qui concerne l'informatique, « security hardening » est traduit par « renforcement de la sécurité ».

« hardened » est un terme de métallurgie : :en:hardened steel == acier hypereutectoïde trempé à l'eau salée et recuit (en plus court « acier trempé »). Pour les techniques non basées sur une trempe (p.ex. cémentation), on dit « durci » (définition Wikipédia : l'acier cémenté est un acier durci en surface […]). Puisque le noyau n'est pas trempé, « durci » est la meilleure traduction.

Comme vendeur, tu peux aussi accepter les transferts. Ça marche sans frais supplémentaires pour l'acheteur pour la zone SEPA {UE28 + principautés, Suisse, Norvège et Islande} et c'est le moyen de paiement normal que les gens veulent en Allemagne et dans d'autres pays de même culture. Ça marche aussi pour les pays hors de l'Europe géographique si le client accepte de payer le taux de change de sa banque, tout comme il le ferait pour les intermédiaires que tu cites.

Comme acheteur, si tu payes avec un compte domicilié au Royaume-Uni, tu es protégé par la loi anglaise. Non seulement tu seras remboursé en cas de fraude du vendeur, mais la banque considèrera que le vendeur lui doit cet argent, avec toutes les conséquences légales et embarrassantes que cela peut avoir pour lui.

Et donc, en quoi était-ce une perle ? Perle : « Mot, phrase, écrit dont la cocasserie et le ridicule, souvent involontaires, suscitent la moquerie. » (TLFi). Bref, quel était le sens de ton commentaire ?

Le tire étant « Perle », la critique doit porter sur la grammaire. Il y a une manière de lire la phrase qu'il cite où on comprend que les membres du public viennent tous pour se disputer l'achat une seule et unique machine (comme dans une vente aux enchères).

est-ce qu'il y aurait des marques de SSD à éviter ou au contraire d'autres réputées efficaces ?

Point de vue fiabilité tu peux consulter les données de retour en garantie de ldlc. Taux de retour des composants (page 8 - SSD), hardware.fr, mai 2013.

Après, toute la question est : pourquoi démarrer souvent un PC?

Ma réponse particulière : le suspend-to-ram (pm-suspend) me donne des problèmes au réveil avec le driver proprio de la carte graphique. Jamais essayé de mettre en place de suspend to disk; d'après le manuel « Most modern systems require 15 to 45 seconds to enter and leave hibernate, and entering and leaving hibernate takes longer when you have more memory. » J'ai beaucoup de RAM sur ma station de travail, et si ça prend 45 secondes il n'y a pas d'avantage par rapport à redémarrer.

Tu peux lire sur Wikipédia OpenGraphics et sur linuxfr Open Graphics lance la production de l'OGD1 (2009). On n'en a plus trop entendu parler depuis, remarque. Le liste www.opengraphics.org répond mais donne juste une page par défaut comme quoi ils ont fermé le site.

Personnnellement j'utilise l'extension PrefBar qui permet d'activer ou de désactiver javascript, flash, le chargement des images, etc. (Tu peux choisir parmi deux douzaines de cases à cocher.)