Loin de moi l'envie de me mêler de vos affaires, mais que vient faire ce journal -factuellement vrai, mais pas non plus indispensable - sur LinuxFR ?
C'est pas plutôt sur les forums et MLs de Mageia directement qu'il faudrait en discuter ?
Que donne Clang en termes de performances et compatibilité sous Windows ?
J'aimerais bien le supporter à côté de GCC/MinGW et MSVC pour mes projets cross-platform ; il y a quelques années quand j'avais regardé, c'était très bogué, limite expérimental.
On trouve aujourd'hui des instructions pour le compiler soi-même dessus, mais peu d'indications sur son état fonctionnel. Des retours ?
Voilà, c'est exactement ça.
Quant on parle de "rétrocompatibilité" avec Windows, on parle de la capacité de déposer et lancer un exécutable précompilé pour Windows 95 (1995) directement sous Windows 10 (2015).
Le problème avec Linux, c'est que si la rétrocompatibilité binaire de son noyau est correcte, ce n'est pas le cas de son userland, qui comprend lui le système graphique, audio… c'est-à-dire la plupart des choses dont un logiciel "desktop" a besoin.
Résultat : on se retrouve à recompiler un logiciel vieux de 20 ans, ainsi que ses dépendances (Qt 3, GTK+ 1.x, OSS…).
On sort donc ici largement des compétences du pékin moyen… et de la plupart des entreprises.
Alors merci pour ton travail, c'est pas mal du tout !
J'ai constaté les petits soucis suivants avec la version 0.6 packagée en RPM :
- les demandes interactives (clé, mot de passe…) se font dans le terminal d'où xsshfs a été lancé, c'est peu intuitif et surtout on ne voit rien si le raccourci .desktop a été utilisé pour le lancer… Y aurait-il moyen d'afficher ça en GUI ?
- ce serait bien d'avoir une confirmation de type "Succès !" si le montage s'est bien effectué ;
- le bouton "Fermer" de la fenêtre "A propos" est inactif ; on peut fermer avec la croix, mais après la fenêtre ne réapparaît plus.
"swrast" est le driver swrast_dri.so ; il s'agit d'un driver DRI, c'est-à-dire correspondant à utilisation locale de la carte graphique pour un rendu "accéléré". Alors qu'effectivement, et au contraire, tu désires un rendu pur software. Essaie de forcer ce comportement en faisant :
$ export LIBGL_ALWAYS_INDIRECT=1
Si l'appli est ancienne et utilise ce bon vieux GLX, et qu'Ubuntu compile Mesa de la bonne façon, ça devrait marcher.
Si ton application est plus moderne et utilise EGL, il y a une autre et meilleure solution. Installe le paquet libegl1-mesa-drivers et force l'utilisation de Gallium avec :
$ export EGL_DRIVER=egl_gallium
(ce driver est capable de transporter du rendu GL software, tout en bénéficiant partiellement de l'accéleration locale)
Alors en fait, Mozilla elle-même ne soutient pas l'initiative, mais il existe Fresh Player Plugin qui est un add-on PPAPI pour Firefox (dont le but avoué est de faire tourner Flash ;) )
Je l'ai essayé très récemment, et ça marche pas mal du tout.
La méthode de migration proposée plus haut est valide ; cependant, si changer les outils dérange davantage que changer d'OS (et c'est souvent le cas, un bon OS est transparent), voici comment prendre le problème dans l'autre sens :
1) Installer une distro Linux avec MATE ; la plupart l'ont, voir Linux Mint ou Ubuntu MATE pour l'avoir préinstallé ;
2) Mettre en place le thème NotXP. Après quelques clics dans le gestionnaire de configuration, le bureau ressemblera à s'y méprendre à un WinXP ;
3) Remplacer les logiciels "faciles" par leur équivalent libre (Internet Explorer par Firefox, etc…). Pour les logiciels délicats (Office p.ex.), utiliser Wine pour lancer les exécutables de la partition Windows survivante. PS : les version récentes les font très bien tourner.
4) Se laisser du temps et de la pédagogie pour les migrer 1 par 1 vers leur équivalent libre (Office -> LibreOffice…)
C'est techniquement possible, mais nécessite du travail dans le compositeur RDP. En gros, il faut y tracker les fenêtres. Je vois comment faire, mais doute avoir le temps durant les prochains semaines.
En attendant, une solution de contournement est d'utiliser ce hack. La mise en place est plus lourde, mais le résultat visuel proche.
Je viens de discuter avec les gens de FreeRDS, cela devrait. Cependant j'avoue n'avoir testé que le compositeur RDP de Weston pour l'instant (je ne sais pas builder ni utiliser FreeRDS). Un retour là-dessus serait donc utile.
Y a pas de problème :-), de toute façon on n'y peut pas grand-chose car le nom était plus ou moins "forcé" (xfreerdp pour X11, wfreerdp pour Windows…). Mais je peut garantir que je maintiendrai ce code et qu'il ne partira pas en roue libre !
L'implémentation actuelle du compositeur RDP ne peut pas faire de "vrai" seamless car elle n'interagit pas avec le shell/window manager pour cibler la fenêtre qui nous intéresse. Je suis cependant certain qu'on peut le modifier pour ça devienne possible.
Fullscreen-shell est un shell alternatif poussé par Jason Ekstrand, qui se builde avec --enable-fullscreen-shell et s'utilise avec --shell=fullscreen-shell.so. Il a la particularité de n'avoir aucune interface et de n'afficher qu'une surface à la fois, sur fond noir, comme quand on passe en mode "fullscreen" (F11) dans weston-terminal p.ex. Les applications doivent le gérer, mais toutes celles intégrées à Weston ont déjà été adaptées.
Je suis incapable de t'en faire une vidéo maintenant car mes installs sont custom, mais je vais voir.
Oui le backend RDP marche bien, voilà une vidéo sous Tizen et voilà comment l'utiliser. Tu remarques que les applis GL marchent, car j'ai ajouté le support Gallium qui "pipe" le calcul en mode software.
Pour l'instant le hack consiste à faire ainsi :
compiler fullscreen-shell et le compositeur RDP ;
lancer le compositeur RDP avec fullscreen-shell ;
lancer une application dans ce compositeur, elle sera fullscreen ;
se connecter à partir de xfreerdp.
Cela revient à dire : 1 compositeur = 1 appli. On pourrait bien sûr automatiser ces étapes avec des scripts et hacks.
Pour l'instant, tout le bureau ; mais en utilisant fullscreen-shell (qui met une seule appli en plein écran à la fois) on obtient plus ou moins l'effet souhaité.
Weston fournit une interface non-standardisée pour les captures d'écran ; les développeurs déconseillent de l'utiliser jusqu'à ce qu'une décision soit prise sur une éventuelle standardisation liée à l'aspect sécurité (une appli capable de faire des screenshots pourrait voler des numéros de carte bancaire, etc…).
Il faudra simplement m'expliquer comment créer les paquets pour chaque librairie.
Les paquets sont "assemblés", un peu de manière manuelle, via des scripts disposés sur la machine de build chez GNOME. Je vais essayer de te les récupérer, mais avec le temps libre dont je "dispose" je m'engage pas sur le timing.
Par contre, fournir une aide pour corriger les très nombreux (si, si !!!) bugs (mineurs) sous Windows est une autre affaire.
Bien d'accord. Perso mon principal problème était que l'entretien du build system devenant de plus en plus compliqué, et que par ailleurs les bugs s'accumulant, mon temps libre devenant plus réduit, le jeu n'en valait plus la chandelle.
Généralement, trouver comment corriger un de ces bugs me prend au minimum une demi-journée
Pareil ici, et même pire parfois (les bugs de police -Cairo- notamment).
Par contre, je n'ai pas réessayé depuis si la librairie compile sous Win64 depuis MinGW.
GTK+ ne marche pas bien dans ReactOS, car le support des polices via Cairo y est cassé. J'ai identifié le problème la semaine dernière et commencé un patch, mais ça m'a pris des heures, et au final j'ai pas pu terminer avant que mon travail me "remange" mon cerveau. Mes découvertes sont dispo pour qui pense avancer avec.
Il faudrait surtout que GTK de façon générale recommence à envoyer du rêve
Moi ce qui à l'époque m'avait fait tripper, c'était Broadway. Et effectivement, ça y est ça marche, on pourrait faire fonctionner GIMP-LibreOffice-etc en cloud avec ça. Il fait juste le polir, notamment pour supporter l'authentification et le multi-session.
Qt à la bouche, qui pourtant a l'énorme inconvénient d'être écrit en c++, ce qui rend les bindings vers les autres langages nettement plus compliqués.
Point important, merci de le souligner ! On peut très facilement faire du Python, Vala, PHP… avec GTK.
J'imagine que des sponsors de GNOME comme Red Hat ou Canonical ne désirent pas employer quelqu'un pour maintenir la version Windows.
Effectivement, ils n'y ont pas d'intérêt direct.
rétrocéder une partie, même faible, de leur donations au toolkit
Ce serait effectivement bien ; dans la pratique ça marche plutôt à sens unique, l'application utilise GTK+ et quand ce dernier ne fonctionne plus assez bien à son goût, elle migre vers un autre framework (Qt p.ex.) plutôt que de contribuer. Et une application de moins, ça signifie moins d'intérêt de la part des devs coeur, donc la qualité baisse encore… c'est un cercle vicieux.
# Pourquoi ici ?
Posté par Tarnyko (site web personnel) . En réponse au journal Pas de mises à jour de sécurité depuis 5 ans sur l’infrastructure Mageia. Est‐ce bien raisonnable ?. Évalué à -3.
Loin de moi l'envie de me mêler de vos affaires, mais que vient faire ce journal -factuellement vrai, mais pas non plus indispensable - sur LinuxFR ?
C'est pas plutôt sur les forums et MLs de Mageia directement qu'il faudrait en discuter ?
# Clang sous Windows ?
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Outils utiles pour développeur. Évalué à 4.
Que donne Clang en termes de performances et compatibilité sous Windows ?
J'aimerais bien le supporter à côté de GCC/MinGW et MSVC pour mes projets cross-platform ; il y a quelques années quand j'avais regardé, c'était très bogué, limite expérimental.
On trouve aujourd'hui des instructions pour le compiler soi-même dessus, mais peu d'indications sur son état fonctionnel. Des retours ?
[^] # Re: Il oublie LES 2 raisons principales
Posté par Tarnyko (site web personnel) . En réponse au journal Pourquoi Windows. Évalué à 4.
Voilà, c'est exactement ça.
Quant on parle de "rétrocompatibilité" avec Windows, on parle de la capacité de déposer et lancer un exécutable précompilé pour Windows 95 (1995) directement sous Windows 10 (2015).
Le problème avec Linux, c'est que si la rétrocompatibilité binaire de son noyau est correcte, ce n'est pas le cas de son userland, qui comprend lui le système graphique, audio… c'est-à-dire la plupart des choses dont un logiciel "desktop" a besoin.
Résultat : on se retrouve à recompiler un logiciel vieux de 20 ans, ainsi que ses dépendances (Qt 3, GTK+ 1.x, OSS…).
On sort donc ici largement des compétences du pékin moyen… et de la plupart des entreprises.
[^] # Re: Et si vous êtes fainéant : Xsshfs
Posté par Tarnyko (site web personnel) . En réponse au journal SSHFS est un vrai système de fichiers en réseau. Évalué à 1.
Alors merci pour ton travail, c'est pas mal du tout !
J'ai constaté les petits soucis suivants avec la version 0.6 packagée en RPM :
- les demandes interactives (clé, mot de passe…) se font dans le terminal d'où xsshfs a été lancé, c'est peu intuitif et surtout on ne voit rien si le raccourci .desktop a été utilisé pour le lancer… Y aurait-il moyen d'afficher ça en GUI ?
- ce serait bien d'avoir une confirmation de type "Succès !" si le montage s'est bien effectué ;
- le bouton "Fermer" de la fenêtre "A propos" est inactif ; on peut fermer avec la croix, mais après la fenêtre ne réapparaît plus.
# Software Rasterizer
Posté par Tarnyko (site web personnel) . En réponse au message X forwarding d'un hôte Intel/rien du tout vers un client ARM/Nvidia. Évalué à 4.
"swrast" est le driver swrast_dri.so ; il s'agit d'un driver DRI, c'est-à-dire correspondant à utilisation locale de la carte graphique pour un rendu "accéléré". Alors qu'effectivement, et au contraire, tu désires un rendu pur software. Essaie de forcer ce comportement en faisant :
$ export LIBGL_ALWAYS_INDIRECT=1
Si l'appli est ancienne et utilise ce bon vieux GLX, et qu'Ubuntu compile Mesa de la bonne façon, ça devrait marcher.
Si ton application est plus moderne et utilise EGL, il y a une autre et meilleure solution. Installe le paquet libegl1-mesa-drivers et force l'utilisation de Gallium avec :
$ export EGL_DRIVER=egl_gallium
(ce driver est capable de transporter du rendu GL software, tout en bénéficiant partiellement de l'accéleration locale)
[^] # Re: Inacceptable ?
Posté par Tarnyko (site web personnel) . En réponse au journal FreeGLUT : premier port Wayland disponible !. Évalué à 2.
Hello MsK,
Possible de développer ce point ?
# Lien vidéo
Posté par Tarnyko (site web personnel) . En réponse au journal FreeGLUT : premier port Wayland disponible !. Évalué à 3.
Argh, lien vidéo cassé, c'est ça de se relire trop vite…
https://www.youtube.com/watch?v=FQvRIoALQyg
[^] # Re: Flash PPAPI support
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Firefox 37 vient de sortir !. Évalué à 2.
Alors en fait, Mozilla elle-même ne soutient pas l'initiative, mais il existe Fresh Player Plugin qui est un add-on PPAPI pour Firefox (dont le but avoué est de faire tourner Flash ;) )
Je l'ai essayé très récemment, et ça marche pas mal du tout.
# Autre technique
Posté par Tarnyko (site web personnel) . En réponse au message Quelle distribution pour convaincre une personne réticente d'abandonner windows XP ?. Évalué à 2.
La méthode de migration proposée plus haut est valide ; cependant, si changer les outils dérange davantage que changer d'OS (et c'est souvent le cas, un bon OS est transparent), voici comment prendre le problème dans l'autre sens :
1) Installer une distro Linux avec MATE ; la plupart l'ont, voir Linux Mint ou Ubuntu MATE pour l'avoir préinstallé ;
2) Mettre en place le thème NotXP. Après quelques clics dans le gestionnaire de configuration, le bureau ressemblera à s'y méprendre à un WinXP ;
3) Remplacer les logiciels "faciles" par leur équivalent libre (Internet Explorer par Firefox, etc…). Pour les logiciels délicats (Office p.ex.), utiliser Wine pour lancer les exécutables de la partition Windows survivante. PS : les version récentes les font très bien tourner.
4) Se laisser du temps et de la pédagogie pour les migrer 1 par 1 vers leur équivalent libre (Office -> LibreOffice…)
# Alternative (uselessd, ...)
Posté par Tarnyko (site web personnel) . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 1.
Bloquer systemd "en attendant que" est intéressant à savoir faire, mais un pis-aller.
Comme l'a dit benoar, il y a uselessd, qui peut constituer une alternative intéressante, techniquement et philosophiquement.
(à titre personnel, j'ai réussi à lui faire booter un des mes systèmes jusqu'à la GUI, mais attends de peaufiner un peu avant d'en faire un journal)
# Merci
Posté par Tarnyko (site web personnel) . En réponse au journal Les vidéos de la X.Org Developer Conference 2014 sont disponibles. Évalué à 2.
Très utile ; bravo, et merci Martin !
[^] # Re: Plus clairement ?
Posté par Tarnyko (site web personnel) . En réponse au journal wlfreerdp: un client Wayland pour FreeRDP. Évalué à 4.
C'est disponible depuis longtemps. Cette page et cette vidéo pourront te renseigner.
Le journal parle de la création d'un client Wayland ; c'est-à-dire, un "visualiseur" qui lui tourne sur Wayland à l'instar des versions X11, Android…
Oui. Il faut démarrer un compositeur par utilisateur.
Avec le compositeur RDP de Weston, non. Avec FreeRDS, peut⁻être, mais cela nécessite des informations (voir ci-dessus).
[^] # Re: un troll de moins ?
Posté par Tarnyko (site web personnel) . En réponse au journal wlfreerdp: un client Wayland pour FreeRDP. Évalué à 4.
C'est techniquement possible, mais nécessite du travail dans le compositeur RDP. En gros, il faut y tracker les fenêtres. Je vois comment faire, mais doute avoir le temps durant les prochains semaines.
En attendant, une solution de contournement est d'utiliser ce hack. La mise en place est plus lourde, mais le résultat visuel proche.
[^] # Re: FreeRDS
Posté par Tarnyko (site web personnel) . En réponse au journal wlfreerdp: un client Wayland pour FreeRDP. Évalué à 4. Dernière modification le 13 octobre 2014 à 15:14.
Je viens de discuter avec les gens de FreeRDS, cela devrait. Cependant j'avoue n'avoir testé que le compositeur RDP de Weston pour l'instant (je ne sais pas builder ni utiliser FreeRDS). Un retour là-dessus serait donc utile.
[^] # Re: Roue libre
Posté par Tarnyko (site web personnel) . En réponse au journal wlfreerdp: un client Wayland pour FreeRDP. Évalué à 7.
Y a pas de problème :-), de toute façon on n'y peut pas grand-chose car le nom était plus ou moins "forcé" (xfreerdp pour X11, wfreerdp pour Windows…). Mais je peut garantir que je maintiendrai ce code et qu'il ne partira pas en roue libre !
[^] # Re: triste
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 2.
Oui, dans l'état actuel, c'est ça.
L'implémentation actuelle du compositeur RDP ne peut pas faire de "vrai" seamless car elle n'interagit pas avec le shell/window manager pour cibler la fenêtre qui nous intéresse. Je suis cependant certain qu'on peut le modifier pour ça devienne possible.
[^] # Re: triste
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 4. Dernière modification le 09 octobre 2014 à 16:19.
Fullscreen-shell est un shell alternatif poussé par Jason Ekstrand, qui se builde avec --enable-fullscreen-shell et s'utilise avec --shell=fullscreen-shell.so. Il a la particularité de n'avoir aucune interface et de n'afficher qu'une surface à la fois, sur fond noir, comme quand on passe en mode "fullscreen" (F11) dans weston-terminal p.ex. Les applications doivent le gérer, mais toutes celles intégrées à Weston ont déjà été adaptées.
Je suis incapable de t'en faire une vidéo maintenant car mes installs sont custom, mais je vais voir.
Oui le backend RDP marche bien, voilà une vidéo sous Tizen et voilà comment l'utiliser. Tu remarques que les applis GL marchent, car j'ai ajouté le support Gallium qui "pipe" le calcul en mode software.
Pour l'instant le hack consiste à faire ainsi :
Cela revient à dire : 1 compositeur = 1 appli. On pourrait bien sûr automatiser ces étapes avec des scripts et hacks.
[^] # Re: triste
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 2.
Pour l'instant, tout le bureau ; mais en utilisant fullscreen-shell (qui met une seule appli en plein écran à la fois) on obtient plus ou moins l'effet souhaité.
[^] # Re: A noter: la release a été faite par Pekka Paalanen.
Posté par Tarnyko (site web personnel) . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 3.
Weston fournit une interface non-standardisée pour les captures d'écran ; les développeurs déconseillent de l'utiliser jusqu'à ce qu'une décision soit prise sur une éventuelle standardisation liée à l'aspect sécurité (une appli capable de faire des screenshots pourrait voler des numéros de carte bancaire, etc…).
Il devrait y avoir une discussion là-dessus cette semaine ;-).
[^] # Re: Enregistrements
Posté par Tarnyko (site web personnel) . En réponse à la dépêche La X.Org Developer Conference 2014 à Bordeaux. Évalué à 2.
Impeccable, bon à savoir :-).
En attendant de s'y retrouver ; bons préparatifs !
[^] # Re: Une bouteille à la mer
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+3/Win32 : cherche aide/mainteneur. Évalué à 1.
Hello Bansan,
Je te remets !
Les paquets sont "assemblés", un peu de manière manuelle, via des scripts disposés sur la machine de build chez GNOME. Je vais essayer de te les récupérer, mais avec le temps libre dont je "dispose" je m'engage pas sur le timing.
Bien d'accord. Perso mon principal problème était que l'entretien du build system devenant de plus en plus compliqué, et que par ailleurs les bugs s'accumulant, mon temps libre devenant plus réduit, le jeu n'en valait plus la chandelle.
Pareil ici, et même pire parfois (les bugs de police -Cairo- notamment).
Ca fonctionne. Il faut utiliser MinGW64.
[^] # Re: conditions de travail
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+3/Win32 : cherche aide/mainteneur. Évalué à 5.
Re vincent, j'ai du nouveau,
Suite à ton comm, j'ai mis grand un coup ; je viens de finir le patch ReactOS qui y fait fonctionner GTK+ (2 et 3) :
https://jira.reactos.org/browse/CORE-8306
Je regarde si on peut builder avec aussi ; ce qui nous permettrait de ne plus dépendre du "Win32" commercial pour au moins le workflow basique .
[^] # Re: conditions de travail
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+3/Win32 : cherche aide/mainteneur. Évalué à 2.
Hello Vincent,
GTK+ ne marche pas bien dans ReactOS, car le support des polices via Cairo y est cassé. J'ai identifié le problème la semaine dernière et commencé un patch, mais ça m'a pris des heures, et au final j'ai pas pu terminer avant que mon travail me "remange" mon cerveau. Mes découvertes sont dispo pour qui pense avancer avec.
Sinon au pire, il y a Wine.
[^] # Re: job
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+3/Win32 : cherche aide/mainteneur. Évalué à 6.
Moi ce qui à l'époque m'avait fait tripper, c'était Broadway. Et effectivement, ça y est ça marche, on pourrait faire fonctionner GIMP-LibreOffice-etc en cloud avec ça. Il fait juste le polir, notamment pour supporter l'authentification et le multi-session.
Point important, merci de le souligner ! On peut très facilement faire du Python, Vala, PHP… avec GTK.
[^] # Re: job
Posté par Tarnyko (site web personnel) . En réponse au journal GTK+3/Win32 : cherche aide/mainteneur. Évalué à 1.
Effectivement, ils n'y ont pas d'intérêt direct.
Ce serait effectivement bien ; dans la pratique ça marche plutôt à sens unique, l'application utilise GTK+ et quand ce dernier ne fonctionne plus assez bien à son goût, elle migre vers un autre framework (Qt p.ex.) plutôt que de contribuer. Et une application de moins, ça signifie moins d'intérêt de la part des devs coeur, donc la qualité baisse encore… c'est un cercle vicieux.