Tarnyko a écrit 507 commentaires

Tu as raison, c'est un Proton plus récent contrairement à ce que je disais!

Juste nuance : plutôt que la branche "Dev" telle quelle, la GE (qui signifie juste "Glorious Eggroll" = l'auteur du dépôt 😁), est un fork stable qui cherry-pick de la Dev.

Je dirais qu'il faut choisir sa croix :
- installer SteamOS pour avoir Proton ; mais alors la distro est a un fork d'Arch qui est assez "technique" (et moins supportée qu'Ubuntu par le monde propro-hybride) ;
- installer Proton-GE sur Ubuntu ou Mint ; avec une émulation un peu plus datée mais une distro très bien supportée.

Effectivement,
1 paquet Fedora/RHEL = 3 paquets Debian en moyenne.

une perte de contrôle totale sur les dépendances ou mon target/ devient le nouveau node_modules/

Sur ce dernier point, il y a un contournement : forcer en assumant de gérer soi-même.
Je n'ai pas encore d'exemple sur mon GitHub (faut à chaque fois nettoyer, mettre une licence..) mais en gros ça revient à faire ça:

git clone https://github.com/.../ipc-channel --single-branch VER_201

Dans Cargo.toml:

[dependencies]
ipc-channel = { path = "./ipc-channel" }

(en "prod", vaut mieux utiliser soit build.rs, soit un folder sous-module qui sera renseigné dans .gitmodules et peuplé à l'initial "git clone … --recurse-submodules")

Sur le reste, on est d'accord. En fait ce n'est peut-être pas le meilleur langage pour le jeu vidéo ;-).

J'ai un discord sur lequel il y a quasiment personne, et j'ai aussi rejoint le discord d'un dev indépendant qui bosse sur Daisy Train

Si tu trouves mon pseudo sur le serveur "The Rust Programming Language", n'hésite pas à m'inviter ;-).

C'est vrai que Dear ImGui a toujours une apparence très élémentaire…
Par comparaison, les écrans de Clay vendent du rêve !

Ma lib "CSS" permet de créer les structures Clay_ElementDeclaration et Clay_TextElementConfig en amont, afin de pouvoir les donner aux macros CLAY(), CLAY_TEXT() etc…

Oui je trouve très bien que ta page le décrive -on en aurait eu besoin tôt ou tard.
D'ailleurs même ton exemple de base ( my_layout() ) est bien plus parlant que celui fourni par Clay AMHA. Il est plus simple et adapté à un nouvel arrivant comme moi !

En C++23 (je sais plus depuis quand), lorsque l'on initialise une structure avec des "designated initializers", ils doivent être TOUS spécifiés, et dans le BON ORDRE :

Ah sérieux? J'utilise pas mal de C23, mais en C++ on est coincés à une version antérieure… bon à savoir.
C'est aberrant du coup, quoique bien que ça ait participé à la naissance de Clay Style Sheet ! (pour nous au moins… pour toi, à voir si tu échappes au burnout 😄).

Chess meets Magic --> Wizard Arena

Ça a l'air plutôt sympa (je suis un ancien joueur MTG 😉).
Sauf erreurs, les channels sont aussi ce que font la plupart des frameworks récents en Rust.
Tiens-nous au courant, perso je me ferai un plaisir de l'essayer -et de voir enfin la fameuse interface 😜.

Hello, intéressant.

Je ne connaissais pas Clay, et ai regardé un peu l' exemple SDL3…
ça me fait beaucoup penser à ImGUI, autre lib UI très utilisée dans le monde du JV, qui ne se sert pas des widgets du système -donc souple, mais il faut la brancher manuellement avec le moteur qu'on va utiliser.

Sauf qu'ici la syntaxe à base de structs imbriquées est très différente, et me fait justement penser à une hiérarchie XML/JSON -qui est ce que tu "wrappes" donc organiquement avec ta lib CSS, c'est ça ?

PS: c'est quoi ton jeu ;-) ?

Le mieux est d'aller voir les retours sur ProtonDB.

Si ça peut aussi comparer avec du Windows ça serait pas mal pour voir ou je peux me situer sur du CP2077 par exemple.

Ah je le connais bien ce jeu :-).
Selon les retours : il marche bien, mais beaucoup ont constaté une limitation à ~50 FPS sur cartes NVIDIA.

Bon à savoir.

Ils devraient sans doute tirer parti de microG (qui fonctionne très bien sur un téléphone).

Après j'avoue préférer les versions natives des applis sur mon ordi, plutôt qu'essayer d'émuler leur version castrée Android. L'interface… Ou alors le cas d'usage serait les jeux payants (nécessitant donc le Play Store ?).

notamment pour la banque, qui peut désormais exiger la dernière version d'android (2

Qui peut, mais ne DOIT pas ; je me trompe ?

J'ai migré vers un téléphone sur Android 14 (donc pas la dernière), dont je gère les mises à jour moi-même ; et pour l'instant tout roule.
Mais la mesure est récente…
Si je rencontre un tel problème, je migrerai sans erreur vers une autre banque dont l'appli sera moins fermée… et j'encourage, dans la mesure du possible, à faire de même !

Intéressant.
Je pensais que ça passait forcément par un cloud -voir mon autre message- mais apparemment il y a une technique pour forcer le direct sur un LAN (si le téléphone et l'ordi sont sur le même Wi-Fi, plus généralement le même sous-réseau).

Vu que le syncthing originel n'est plus maintenu depuis l'année dernière, je suppose que tu utilises ce fork ? Ou alors cépagrav, l'originel marche toujours très bien aussi ?

C'est ce que j'étais sur le point de dire aussi ;-).

Je suppose que sortir le câble à chaque fois, ça peut rebuter… un rsync SSH automatique du répertoire de son téléphone vers son serveur perso, puis l'inverse sur son PC, serait une bonne solution privée.
Juste que comme un smartphone n'a pas de clavier, il faudrait un frontal applicatif par-dessus. Je me dis que ça existe déjà et qu'on va sûrement le suggérer (c'est un appel :-) ) …?

Effectivement :-D.
Ma réponse était conçue comme un clin d'oeil, que tu as visiblement saisi… il y a un peu de taf à faire, avant, après et pendant ; ce qui est le prix d'être sur un OS dit "alternatif".

Rien ne garantit qu'un truc "existant sous Linux" va facilement marcher sur une distribution donnée. Il y en a tellement…

Si tu veux faire tourner quelque chose de "commercial" (même freeware, car c'est ce qu'est PS) le mieux est d'aller voir le site du "fabricant" (ici M$). Et si c'est déjà libre, c'est normalement toujours possible mais moyennant un effort de "rien" à "compliqué"; là le mieux est d'abord la distribution, ensuite au pire la source.

Après on va t'aider bien sûr ! Tant que c'est techniquement faisable ;-).

(exemple : Proton GE s'installe au pire par le market Flatpak. Comme ça marche tout seul sous Ubuntu, et que Flatpak est développé sur Fedora/RHEL ; on peut en déduire que ça marche le mieux sous Ubuntu et Fedora/RHEL)

• exécuter des EXE et des scripts PowerShell que j'ai développé

Tiens c'est rigolo (et plutôt rare) ça comme exigence.
Tu as forcément été sur le site de Microsoft ; et tu sais donc déjà sur quelles distributions PS est garanti de fonctionner -et lesquelles non 😉.
Tu réalises aussi sûrement que Linux a une autre structure de répertoires etc… et que tu devras en adapter certains.

Concernant les exécutables Windows, Wine à l'os marche assez bien, mais la meilleure solution est d'utiliser la surcouche Proton GE.
Installer le 2nd permet de se passer de la configuration du 1er, mais n'est pas non plus une affaire de débutant.
Une lecture détaillée te fera constater que les distributions conseillées sont en gros les mêmes…

Et pour finir, tu anticipes que quoiqu'il arrive, la compatibilité ne sera pas à 100%. Au mieux tu auras du 85%.

J'avoue : c'est inquiétant.
Migrer de banque pourrait être une solution (moi et mes amis sommes devenus volages ; les banques online sont devenues une solution prisée, avec au moins 1 changement par an selon ce qu'offre ou pas la banque "cible"). En tout cas pour moi, c'est un critère valide vu que ce sont les décisions de son équipe de dév.

la plupart des dites applis exigeront de passer par les "google services", dont finalement le projet d'amenuise pas mal

C'est pour cette raison qu'/e/OS (entre autres) pré-installe un émulateur nommé microG.
Ça permet de donner l'impression à l'appli que les services Google sont dispo; parfois ça marche réellement en simple "passe-plat" (ex. Maps), parfois ça remplace réellement (ex. l'API des comptes/paiements).

Il se trouve ça marche très bien ! Juste si jamais je sors un compte-rendu, j'insisterai pas dessus ; à cause du débat philosophique que ça engendre 😉

(Mon opinion : l'usage de ces APIs est si répandu, que c'est pragmatiquement requis AMHA)
(Mon opinion 2 : un OS concurrent a 0 chance d'être suivi par les développeurs d'applis à succès. Ca restera une niche à geeks. C'est comme "Linux sur le desktop" : la base installée en face est déjà trop forte)

seule solution, zéro appli

C'est sûr que vu comme ça 😄.
C'est un choix de vie valide… mais alors on glisse plus vers l'abstrait AMHA!

Hahaha pari tenu alors !
Il me faut plus de matière sur le fond du projet, les choix techniques, toussa… je verrai pour fin du mois.

Ces 2 initiatives (dont la française est présentée ici), consistent à reprendre AOSP (la version full-open source d'Android) et d'ajouter les briques manquantes soi-même.

J'ai à titre perso un téléphone Pixel 6 sous /e/OS, et ça fonctionne très bien !

Je n'en ai pas encore parlé sur LinuxFR car mon objectif est majoritairement de faire tourner les applis Android, dont bon nombre sont propriétaires, et beaucoup de mon analyse consiste à vérifier cet aspect.
Mais j'ai une partie plus centrée sur les applis fournies, les téls Murena, .. en cours.

Qu'en penses-tu ?

….Mouais 😉.
'tation hein, j'ai bien compris que ton but était de faire de "point" sur l'usage de Flatpak (et peut-être des stores en général) !

Mais c'est juste que là, avec un navigateur (à savoir, sans doute l'application la plus complexe qui tourne sur ton OS -juste moins complexe que l'OS lui-même !), on tient facilement le pire exemple.

• On utilisait au départ plutôt Flatpak, Snap… pour les applis non-packagées sur sa distro.
  Chaque navigateur a plusieurs binaires officiels ET un paquet de distro ;

• On évitait de les utiliser pour des applis trop intensives, à cause du ralentissement lié à la sandbox.
  A part un jeu vidéo 3D, le navigateur est l'appli la plus intensive qui soit ! Il héberge lui-même des moteurs d'exécution 3D, VR, JavaScript, WASM… on peut aujourd'hui faire tourner Linux dans QEMU dans un navigateur ;

• Eventuellement oui, on peut viser la sécurité par sandboxing… sauf qu'ici :
  Chaque navigateur a sa technologie très avancée de sandbox par thread/onglet, qui fait partie de sa "patte". Je connais bien celle de Chrome-ium, moins celle de Firefox; mais c'est du sérieux, l'état de l'art pour déjouer les CVEs connus et à venir.

Bref, bref… j'interviendrai pas beaucoup plus sur le sujet. Sauf pour dire que je préfère la simplicité des .AppImage 😉.

Salut, c'est moi qui t'avais rapporté un problème de dépendance sur le paquet 0.2 (peut-être ton premier journal sur Bim!).
Juste que tu saches que c'est très intéressant, et que je garde un oeil dessus; pas tant pour jouer que pour "faire du réseau" plus tard sous Android :).

Pourquoi tu l'installes par Flatpak alors que :
- il y a un binaire officiel du projet ;
- sauf erreur, ce binaire officiel fournit son propre système de mise à jour automatique ;
- les navigateurs sont très impactés, en termes de performances et sécurité, par des systèmes de sandboxing "autres" ?

Pourquoi est-ce toujours la nostalgie qui prédomine quand on parle de Pascal alors qu'il semble encore très utilisé au vu de son classement ?

Sans rentrer dans la critique du TIOBE… c'est trompeur.
COBOL aussi a un bon classement, mais c'est qu'il est encore très présent (à l'état de "brique") et que des gens sont embauchés chaque année pour le maintenir. Il n'y a pas de nouveau développement fait avec.

De mon côté, quand en entreprise j'ai proposé de faire évaluer le code Pascal vers du moderne (par exemple : portabilité Linux, gestion du HiDPI…) on m'a toujours opposé une fin de non-recevoir. La raison en était double :

• les managers présents le traitaient comme un passif plutôt que comme un actif ; un centre de coût qui allait disparaître naturellement le jour où un achèterait ou ferait développer un nouveau soft en Java/ReactJS/…

• les développeurs historiques étaient à 75% trop vieux ou trop pépères pour être moteurs (eux aussi, faire du neuf les aurait défrisés, ils auraient dû recommencer à apprendre). Les 25% restants était tenus en respect par eux, et les managers.

Dit autrement, s'il y a un avenir pour Pascal, c'est dans la commu du libre… même s'il a déjà des langages mieux installés dans sa propre niche (C/C++, Rust). Ca se fera dans ce sens et pas dans l'autre.

Ah Turbo Pascal…

j'ai fait du Visual Basic, mais je n'ai pas touché à Delphi.

Delphi était souvent jugé supérieur, car il générait de plus petits exécutables sans dépendances (pas besoin de fournir un fichier VB40.DLL).
Après les deux étaient quand même hyper-proches, avec le même public aussi bien à la maison qu'en entreprise, et ont pris la même trajectoire (vers le grenier !).

j'ai plein de petits programmes genre fractales avec des uses crt,graph3;

Alors crt, devrait y avoir aucun souci.

graph a été porté aussi, mais il faut bien se rappeler que l'implémentation d'époque utilisait le mode plein écran de DOS.
Celle d'aujourd'hui a l'air de l'émuler en fenêtré (dans le terminal avec termio sous Linux, et dans un canvas libre sous l'autre OS). Je ne l'ai jamais utilisée, mais tu peux me faire un retour si tu veux 😉.

FPC Atomic - Un remake en Free Pascal d'Atomic Bomberman>

Làààà… merci beaucoup pour ça !
Je suis un fan de la 1ère heure d'Atomic Bomberman 😉
(seule version à la fois occidentale ET quali de la franchise)

Alors, oui et non.

Historiquement, les GUIs de l'immense majorité des applications Delphi utilisent une bibliothèque nommée Visual Component Library (VCL).

La VCL de Delphi n'a jamais été portée sous autre chose que l'OS propriétaire que tu penses ; ce qui est cross-platform avec Delphi, c'est d'autres frameworks plus récents et moins utilisés comme FireMonkey.
Concrètement une appli Delphi typique, ça tourne donc sur un client lourd Zindozs©.

Par contre, Lazarus lui fournit une réimplémentation partielle et cross-platform de la VCL !
Dit autrement, la manière de faire une application cross-platform "Delphi", c'est… de la porter sous Lazarus 😁.

Les grands esprit se rencontrent tellement. Tu me réponds un certain temps après, et moi je pense à checker juste par hasard dans la foulée… le destin, ça.

quand je suis chargé de psychtropes (pour raisons de douleurs malheureusement et pas par récréation)

Désolé.

Nan sérieux, je veux pas faire la morale, mais, il y a des trucs comme la doc […] c'est juste les coutures du travail.

Nan mais… j'entends bien !
On a tous nos critères pour ce qu'on appelle vite fait les "bonnes pratiques" qui nous permettent de sortir des softs qu'on est fier de montrer.
C'est juste l'écart avec les stricts besoin du hobby du dimanche qui me paraissait démesuré au départ.

Mais j'ai relu ton com' et ta psycodoc de scam, les descriptions de ce qui se passe au dedans et autour de toi… et je pense avoir mis le doigt dessus: ça te permet/force à garder l'emprise sur l'avancement de la chose malgré les (psycho)tropes et les interruptions constantes ? Discipline requise pour arriver à quelque chose.
(désolé, pour comprendre un truc j'ai besoin d'essayer de le résumer. C'est pas super glamour, mais c'est ma manière de m'intéresser aussi).

Comme l'ouvrier qui range son établi

J'aime bien le parallèle ; perso, je parle souvent d'artisan (craftsman en anglais) avec tout le soin que ça implique.

En plus comme je suis flemmard

Non, moi je suis flemmard, ou plutôt dispersé. Beaucoup de trucs commencés jusqu'au moment où un autre commence 😉.