Tarnyko a écrit 438 commentaires

Tu prends celui de Firefox et tu clone dedans celui de Thunderbird. Bref c'est toujours plus ou moins la même base de code…

Intéressant.
Ça évite du coup aux 2 acteurs (firefox & thunderbird) de définir leurs APIs, ce qui est "visible" et qui ne l'est pas, ce qui est retourné… tout est partagé, et au pire surchargeable (ou hackable via patches).

Et puis là en ce moment tu as Servo qui est peu financé, alors que c'est conçu pour être le plus réutilisable

Cette ambition m'inquiète d'autant plus que dans l'état actuel, il n'arrive pas à afficher correctement la page d'accueil Google.

C'est le projet auquel il me plairait le plus de contribuer cela dit.

Je m'inquiète éventuellement de la mesure où ces "ambitions affichées", forcément conçues comme un appât à investisseurs, pourraient se mettre sur le chemin du travail réel d'un développeur. Et si la base de code peut réellement fonctionner telle qu'elle est conçue… j'y réfléchis.

Oh la vache.

Y a d'avoir matière à lecture, le genre de truc épique qu'on oublie pas… ça augure pas du meilleur pour ma question par contre !

Je viens de regarder de mon côté, mon repackaging de Chromium avait pris en gros 3 mois (entre ça et ça). Mais je le faisais en projet pilote… et je trouvais déjà ça beaucoup trop long !

un outil qui permettait de lancer un site web comme une application

Une "webview" , un peu comme avec Electron ou le QtWebEngine?

J'avoue ne jamais m'être demandé pourquoi tous ces frameworks étaient basés sur Blink et jamais sur Gecko…
Penses-tu que ça représenterait un effort insurmontable d'extraire le moteur Web ? (je connais que la tuyauterie de l'autre en face)

Toujours pas de tuple en C pour faire des retour multiple ?
Ou un type pointeur avec null interdit ?

Je n'aime pas être négatif, mais : non et non.
Le commentaire d'uso donne une bonne préconisation, mais pas sûr que ça te suffise si ton critère est vraiment l"interdit".

Est-ce que constexpr fonctionne avec des appels de fonction ? On pourrait précompiler des expressions régulières par exemple.

Pas encore, mais on y réfléchit (page 3) :

• there was not consensus to add the constexpr specifier for functions, to C23;
• there was strong consensus to add the full constexpr feature for objects, extended
operators (element access), and function definitions, in some future version of C after C23.

Je pense également que les bons arguments leur sont tellement évidents,
qu'ils leur permettent de faire passer les mauvais en loucedé.

Il serait bon de tracer les "moments-clés" de cette modif technique ; un travail important dans la gigantesque codebase de Chromium.

Il existe plusieurs forks de ce browser, mais la plupart des non-corporate sont morts à cause de l'effort que ça représente. Moi-même j'ai abandonné le mien il y a quelques années, quand les "clients" ont changé ; et je ne sais pas jusqu'à quel point la commu suffirait à en pousser un….

…ou on pourrait juste utiliser Firefox 😉 .

Qu'en pense-t-on par ici ?

Ah y a un truc prévu pour ? Je vais voir !

EDIT: effectivement, je ne connaissais pas bien ! Merci!

LinuxFR n'est effectivement pas génial pour ça.

Notamment, sauf erreur, aucun moyen d'être prévenu si quelqu'un répond à ton billet 2 semaines après ;
ça fait des sujets "éphémères" et avec peu de traction sociale.

Après comme beaucoup, je date entre Discord, Telegram et le vaste monde des blogs…

Il me reste à implémenter la possibilité de faire d'autres matchs après le premier et ça devrait le faire :)

Ce serait cool ouais 😀 !

Tu aurais plus d'info ?

Alors le dernier truc que j'aie vu c'est l'installation de "python3.10-venv" et après le téléchargement de gros paquets sans mention (dont "boost" de mémoire… du C++ ? via pip ou bien… ?) J'ai laissé le truc se dérouler 5 minutes de plus, et quand je suis revenu c''était tout noir.

(je vais voir pour reproduire vendredi ; si j'oublie pas entre-temps…)

Très intéressant…. Ça paraît s'inspirer d'un certain Dynablaster 😉 .

Après on juge souvent une appli sur pièces…
… et le problème des applis mobiles, c'est fréquemment l'absence d'APK tout prêt, avec une chaîne de compilation capillotractée en pas-vraiment-un-backup…

Car là j'ai voulu essayer le fameux ./setup.sh (pour rire un peu), et il est bel et bien perfectible : sur une Ubuntu 22.04 LTS, ça m'a désinstallé GNOME. Je n'ai plus de desktop, juste le terminal au boot. 😁
(je ne suis pas dérangé, car je le sentais venir et fais toujours ce genre de trucs sur une VM… mais voilà !)

Le coût, rédhibitoire en apparence sur une niche comme ça, devient acceptable avec notre petit code 😉.

Après les conférences en juin-juillet… dommage, ça tombe pile à des dates réservées depuis plombasse, je ne pourrais personnellement pas en être !

Merci pour ça ! Je l'ai commencé et, ça a beau être épais, il y a une belle qualité d'écriture : juste ce qu'il faut entre la proximité avec le lecteur et le professoral.

En gros oui, tant que la régression n'est pas résolue sur les noyaux plus récents…

C'est pour ça que je suggérais de rapporter le problème côté noyau ; il n'est pas dit qu'il y ait un suivi très actif pour un laptop de cette génération !

(PS: d'après ce sujet, le problème aurait commencé à apparaître avec les BIOS Dell > 1.7.4 ; le noyau d'époque était plus ancien).

Une juste répartition des tâches.

Je n'ai aucune connaissance sur le sujet : est-ce « compliqué » ?

Alors de ce que je sais, pas très :
- voici la meilleure procédure sur le sujet ;
- pour maintenir ses utilisateurs à jour à la manière des stores, il existe une app nommée AppImageUpdate (qui est elle-même un .AppImage 😉).

On peut maintenant faire « vérifier » l'application, ce qui permet à l'utilisateur de savoir si c'est le développeur qui publie l'application ou un tiers non reconnu officiellement

Ça faut dire, ça change la donne!
As-tu envisagé une version AppImage aussi ?

Sur ton logiciel lui-même : serait-il aussi adapté pour faire de "simples" galeries d'images ?
(je demande car actuellement je génère des pages web de galeries avec un soft du genre)

"kworker" c'est un problème du noyau ou d'un de ses drivers (ce qui revient au même). Critique, et ultra-chaud à déboguer.

Vu l'âge des modèles Latitude 5400, et le plutôt bon support de Linux par Dell, on peut supposer que cela ne le fait pas sur un distro plus "conservatrice" que Fedora…

Peux-tu envisager de 1) rapporter le problème upstream 2) rétrograder vers le kernel LTS 6.1 3) rétrograder vers une distro ayant un kernel LTS 6.1 (une clé USB "live" permettant de tester sans s'engager) ?

On peut en général recréer un paquet disparu : juste il faut une Fedora/RHEL sous la main, et dans mon cas ce sera pas avant quelques jours.

En attendant, il a l'air dispo via Snap (oui je sais…).
Après avoir installé le nécessaire pour Snap, peux-tu essayer :

sudo snap install gnome-schedule --edge


Très bon 😁.

Sans sarcasme, mais quand même: pour avoir déjà pratiqué le serpent, l'"environnement Python stable et reproducible" est effectivement un challenge en soi.
Immpensable de faire des déploiements sans maîtriser les préfixes, les venvs, au pire les dockers qui vont bien.

Ah ça arrive bien… bon finalement, je vais pas lui taper dessus tout de suite 😁.

Mise à jour comme promis :

• license passée en LGPL-3.0 ou plus récente;
• le hack avec _Bool() est en fait requis jusqu'à C23 exclu. #ifdeffé ;
• j'avais un oubli dans les headers (c'est GCC en C23 qui me l'a signalé ;) ) ;
• avant d'en arriver au Makefile, j'ai rendu les flags des scripts surchargeables à partir du shell.

Par ailleurs pour tester tout ça, j'avais besoin d'une version méga-récente du compilo.
J'avais peur de galérer, mais en fait j'ai trouvé ça facilement :
- ici pour Debian/Ubuntu;
- ici pour RHEL/Fedora.

D'accord, si le critère n°1 est le temps, pourquoi pas.

former des cracks qui se vendront 70k en sorti d'étude

J'ai presque envie de troller en disant que pour ça, ce n'est pas du Java qu'il faut faire,
mais du Rust/C++/Swift 😁.

Je pense qu'on ne va pas être d'accord là-dessus.
Notamment quand tu dis:

pour ce qui est de compiler du java, c'est un sujet résolu (en bytecode tout du moins).

Résolu en pratique, d'accord.
Mais il y a bien un truc qui le fait, qui doit le faire, à un moment donné; et comment le fait-il ?
Ne pas répondre à cette question au moins une fois ; à mon sens, c'est un manquement majeur.

L'équivalent en TypeScript serait de ne pas expliquer qu'il existe un transpileur nommé "tsc" qui transforme les .ts (que le développeur écrit) en .js (que le navigateur charge).
On peut vivre sans, juste écrire le bousin, cliquer sur le bouton, et recharger la page ; mais ça ne permet pas de qualifier au titre d'expert AMHA.

En fait ça limite le développeur à la tâche d'écriture du code, sans notion de l'environnement en-dessous.
Et je dis bien "limite", sans doute parce que je considère ça insuffisant.

Ah OK, le paquet RPM c'est pareil. Je croyais que c'était une bizarrerie du build, maintenant je sais que c'est de la source.