Tarnyko a écrit 610 commentaires

Adélie Linux.

Il a sans doute fait trop confiance au dit individu ; péché de jeunesse ;-).

Bien dit, on peut la soutenir aussi ! (en retenant que le vrai upstream c'est Red Hat)

Très bonne nouvelle !
Faute de pouvoir le dégager ou s'en passer, il faut bien faire avec…

Je plusse, ça a largement suffi pour moi.
À noter cependant qu'il lui faudra au moins Kdenlive 20.12 pour avoir la fonctionnalité. Sur CentOS, c'est supporté depuis la mineure 8.4 seulement.

Un laptop moyennement récent avec un port VGA ? Ah oui effectivement, noté !

Sinon, et je sais que ma réponse n'est pas géniale : étant donné que ce modèle est connu pour supporter 2 à 3 écrans selon les cas (et à moins que tu sois dans ce cas très particulier des 3 écrans), essaie de changer de convertisseur.

Ils sont de qualité variable, avec des incompatibilités variées. J'ai le cas inverse actuellement, un convertisseur HDMI/VGA qui ne donne rien sur un écran précis -écran noir, mais le système voit bien le branchement. Un problème de matrice de synchronisation sur vieux écrans à ce que j'ai compris. Bref, essaie de changer.

Il est clair que si l'on se base sur le travail upstream de l'équipe RHEL, il est moralement juste de le soutenir un minimum. Une licence par profil d'installation serait une bonne métrique.

Rocky ne supporte ni secureboot ni la migration mais supporte par contre l'architecture aarch64

Ça a été l'élément décisif pour moi : le support aarch64.
Le confort de pouvoir utiliser la même distro sur un desktop/serveur et de l'embarqué (majoritairement des Raspberry Pi 4), avec CentOS 8 actuellement, est tel que je ne reviendrai pas en arrière.

Puis il faut quand même prendre en compte l'historique du chef de projet et les garanties morales qu'il apporte.

Quelle réactivité ! (pas comme moi).
C'est bien ce que je pensais. Je te remercie ; on espère tous que cette version majeure nous soufflera !

Boulettes (mais j'en ai qu'une !) :
- C++1 devrait être C++11.

La dépêche sur la 2.10.28 est encore collée au sommet, et voilà qu'on nous en sert une sur la version de dév ??? Indécent :-p !

Blague à part, excellent boulot de l'équipe, et je comprends qu'on se rapproche de GIMP 3, d'où la dépêche préparante ; ainsi que le gros travail de peaufinage sur l'UI et le cross-platform. À ce propos, tu mentionnes plusieurs fois GTK3 mais que je sache GIMP est encore sur la 2 ; qu'en sera-t-il de GIMP 3 ?

C'est malheureusement la seule réponse valide -et qui ait un impact significatif.

Une appli qui refuse de s'exécuter sur un téléphone rooté, c'est la sécurité par l'obscurité : la pire qui soit. Un mauvais choix technique -et dans notre cas, antisocial.

"Voter" en déplaçant ton argent est tout ce qui reste. Nous sommes plusieurs à pouvoir te conseiller si tu le fais.

J'en apprends tous les jours, c'est pour ça que je viens ici.

Salut,
Je sais que tu as demandé une réponse détaillée ; je n'aurais pas le temps de la faire avant demain soir, mais d'ici là tu peux regarder ce que j'ai utilisé par le passé : ZoneMinder (qui avait, de mémoire, des paquets pour la plupart des distributions).

Et +1 pour m'avoir rappelé l'existence de cette offre qui, comme sa concurrente, a un gros potentiel casse-gueule. Mais qui ne tente rien n'a rien.

(je suis perso plus client d'un Shadow que d'un Luna, question de souplesse)

Déployer le moteur 3D dans le cloud, carrément ? C'est bien, tu anticipes des usages disruptifs genre Stadia :-).

Les jeux les plus récents utilisant Lumberyard ("origine" d'O3DE) sont Star Citizen et New World.

(quelques vidéos en français: Star Citizen - New World)

Je testais justement : je confirme, et la différence n'est pas non plus énorme en terme de temps passé.
La présence de gros BLOBs, nécessitant l'utilisation de git-lfs en prérequis (et qui télécharge ses fichiers ailleurs sur des CDNs de GitHub), joue peut-être ? Pas impossible que ça force une partie de l'abre à itérer en totalité.

(je pose la question sans chercher forcément à y répondre, comme tous les nantis-fibrés la problématique m'effleure à peine -troll- ; je conserve par ailleurs mon arbre dans une archive sauvegardée).

Effectivement, bonne remarque. C'est dans les tuyaux !

Excellente news, merci ! J'ai beau participer à l'OSE, l'existence du concours -qu'ils n'ont pas relayé par liste de diffusion- m'avait entièrement échappé.
D'ailleurs, d'autres OSE-ards ici même ? Qui y sera en novembre ?

Le problème d'une telle dépêche, impeccable sur la forme mais dépourvue de contexte, c'est qu'on a vraiment du mal à comprendre de quoi il retourne. Là par exemple, OW2 Quick App, concrètement je ne sais pas ce que c'est.

Et l'absence de suivi, de réaction aux commentaires, ne donne pas plus envie que ça de creuser. Dommage.

Je suppose que la majorité utilise un outil de diff graphique et non pas le diff de base ! ? !

Perso, Windows ou pas, j'utilise le diff de base ; j'ai appris à m'en servir il y a longtemps et je trouve ça assez simple si on est méthodique. Je dirais aussi que l'avantage est qu'il marche partout (comme vi ;) ).

C'est peut-être 100x plus simple avec un outil, hein, c'est juste que j'ai jamais appris à faire.

Effectivement, faut devenir un pro du [Ctrl]+[R] sur des onglets ouverts depuis des années ;).

Sinon je te remercie yinqi : je suis souvent obligé de bosser avec vi à l'os dans des contextes "debug", et je ne connaissais pas cette commande.

Ignore ces messages ;).

Sans déc', tu ne pourras rien faire à moins de corriger et recompiler le code source de Meld/GTK+/GLib et ça fait un gros paquet de taf.

Sinon, tu utilises Git via Bash ? (je suis sûr qu'il installe Bash en même temps). Si oui, tente voir :

alias meld="meld --gtk-no-debug --gdk-no-debug"

Sans Bash, tu peux aussi modifier le difftool dans le fichier .gitconfig (je te laisse trouver) et rajouter ces mêmes paramètres derrière la commande meld.

J'ai finalement posté une version pré-finale des paquets (archis: pmmx/x86_64) sur la mailing list.

Ils sont plus complets que ce que je t'ai envoyé : il y a notamment le partage du presse-papiers et le glisser-déposer sous X11.
L'accel 3D ne marche pas (y a juste du swrast, concrètement ça bloque surtout Chromium), mais ça a l'air d'être le box général entre le noyau Linux, Wayland et le code VirtualBox.
J'attends un peu pour savoir si je dois améliorer !