Ici effectivement le cas est plus complexe: ces interfaces des drivers NVIDIA sont une cible mouvante. On a besoin d'une version récente du système graphique (modules noyau compris) sans sacrifier à la stabilité sur le reste de l'OS…
Les mecs qui bossent dessus ont typiquement une install sur mesure. Là c'est déjà pas mal que ça marchotte.
Et ça, ça ressemble à un problème avec libinput.
Dans le temps Weston utilisait udev comme Xorg; par contre le réactiver c'est pas trivial, c'est un flag à la compil' (si tant est que le code existe encore).
Tu peux encore switcher vers une console fullscreen (avec [Ctrl]-[Alt]-[F4] p.ex.) quand ça se produit ?
Si oui, que se passe-t-il en retournant à Weston (qui lui doit être mappé sur [F1] ou [F7] de mémoire) ?
Aujourd'hui, les 2 drivers ont normalement le nécessaire pour faire tourner Wayland.
Plutôt que Sway (je crois basé sur wlroots), pourrais-tu essayer le compositeur de référence Weston -en général plus à jour sur le support des derniers drivers?
sudo apt install weston
weston --backend=drm --renderer=gl
# en cas d'échec:
# weston --backend=drm --renderer=pixman
Il contient une icône pour lancer un terminal; tu peux ensuite lancer ce que tu veux à partir de là.
Et aussi, je suppose que tu utilises un navigateur… si c'est une base Chrome, il faut savoir qu'il abuse d'extensions Wayland/GL vraiment spécifiques et pas bien gérées partout.
Pourrais-tu voir si ça se produit davantage avec lui; et si oui, éventuellement essayer Firefox par comparaison?
C'est le taux de compression qui ne va pas. Il ne faut pas mettre le même taux vu que la qualité de compression est supérieure avec jpegli.
Effectivement 😲 !
Je viens de tester en double-aveugle avec Joritro (un camarade de code !) et ces paramètres/ résultats :
- JPEG : 80% (23,5 Ko)
- JPEG-LI : 60% (21,0 Ko)
Et là 2,5 Ko de moins pour la version JPEG-LI -c'était prévisible- mais oui elle est également plus jolie "à l'oeil" avec notamment moins de pâtés irréguliers dans l'espace central.
Je te remercie beaucoup, et vais du coup considérer cette lib pour mes traitements !
More recently, the JPEG-XL team at Google has built yet another JPEG encoder, jpegli, which is both faster and better than even mozjpeg. It is based on lessons learned from guetzli and libjxl, and offers a very attractive trade-off: it is very fast, compresses better than WebP and even high-speed AVIF, while still producing good old JPEG files that are supported everywhere.
Une note là-dessus.
Je viens d'essayer. Plus précisément:
- j'ai pris l'exemple C de JPEG-Turbo;
- j'ai appliqué ce patch(qui rend l'exemple "standard" en retirant le format 12-bits qui n'existe pas partout) et compilé ;
- j'ai executé 2 fois,
1x avec JPEG-Turbo, 1x avec JXL-jpegli:
Il en ressort que la 2ème image produite par jpegli est entre 3-5 Ko plus grosse.
C'est peut-être effectivement plus rapide sur des traitements de grosses images (ou des lots de grosses images) ; mais comme la taille était mon critère, je juge bon de l'indiquer.
Salut,
De mémoire, ce qu'il se passe est qu'Android n'a pas réussi à initialiser son système graphique.
C'est probablement dû au fait que le noyau démarre en mode graphique KMS, bien pour les distros "bureau" mais dont Android, faute de driver dédié, ne sait pas forcément quoi faire.
La solution était de s'inspirer de ce tuto,
çàd interrompre le boot avec la touche Tab, ajouter ce genre de paramètre à la ligne "kernel" :
nomodeset vga=91
et reprendre avec la touche Entrée.
Une fois que ça marche, on peut l'inscrire définitivement en modifiant le fichier Grub ; mais ça je te laisse chercher ;-).
En gros le texte de LWN, c'est un (r)appel à la civilité.
Qui n'aboutira sans doute pas à la fermeture des commentaires, car sans commentaires ni polémiques, qui viendra encore ?
LWN et autres ont beau produire de beaux résumés, sans les réactions parfois très opinionnées de profils impliqués dans l'OSS, ça sonnerait rapidement creux… Imaginez LinuxFR comme ça !
Le "max X commentaire PAR utilisateur PAR jour" par contre, c'est une option intéressante.
Car un gars qui passe sa journée à spammer le site, c'est sûrement pas un profil sérieux…
… et un profil sérieux est de son côté bien trop occupé pour même s'apercevoir de la présence du quota !
plus rapide de mettre un peu de Rust dans le C pour améliorer les choses.
Je suis dans l'embarqué aussi, où C++ est quand même assez toléré de mon côté (d'où ma mention) et a l'avantage de l'écosystème installé.
Rust je pousse pour à mort ; c'est quasi le cas d'usage idéal ! Juste pour les projets déjà installés, il est parfois considéré "trop récent" ou trop peu riche en devs par les décideurs…
(après si tu réfères à un mélange que je ne connais pas, je suis intéressé !)
Quand tu parles de tuple, je suppose que ça irait aussi avec ce pattern:
typedef struct
{ bool x; int y; } MyStruct;
MyStruct fn() { return (MyStruct){true, 42}; }
auto [a, b] = fn(); // C++
On y est presque, mais pas tout à fait.
C est un langage très conservateur ; pour ce sucre-là en bas niveau, il ne faut pas s'interdire de regarder vers C++ (ou Rust).
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.
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 !
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.
• 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.
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….
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…)
[^] # Re: forcement
Posté par Tarnyko (site web personnel) . En réponse au message Wayland & Nvidia. Évalué à 2.
Ici effectivement le cas est plus complexe: ces interfaces des drivers NVIDIA sont une cible mouvante. On a besoin d'une version récente du système graphique (modules noyau compris) sans sacrifier à la stabilité sur le reste de l'OS…
Les mecs qui bossent dessus ont typiquement une install sur mesure. Là c'est déjà pas mal que ça marchotte.
[^] # Re: Weston, souci avec Chrome?
Posté par Tarnyko (site web personnel) . En réponse au message Wayland & Nvidia. Évalué à 2. Dernière modification le 06 septembre 2024 à 10:20.
Ah OK. Dommage… ça a l'air à la fois plus grave et pas lié au GPU; mais tout est possible avec des drivers :).
Après on peut demander à Weston de logger extensivement :
peut-être y aura-t-il des lignes intéressantes à partir du moment où on perd l'input?
[^] # Re: Weston, souci avec Chrome?
Posté par Tarnyko (site web personnel) . En réponse au message Wayland & Nvidia. Évalué à 2. Dernière modification le 05 septembre 2024 à 18:38.
Intéressant.
Et ça, ça ressemble à un problème avec libinput.
Dans le temps Weston utilisait udev comme Xorg; par contre le réactiver c'est pas trivial, c'est un flag à la compil' (si tant est que le code existe encore).
Tu peux encore switcher vers une console fullscreen (avec [Ctrl]-[Alt]-[F4] p.ex.) quand ça se produit ?
Si oui, que se passe-t-il en retournant à Weston (qui lui doit être mappé sur [F1] ou [F7] de mémoire) ?
# Weston, souci avec Chrome?
Posté par Tarnyko (site web personnel) . En réponse au message Wayland & Nvidia. Évalué à 5. Dernière modification le 05 septembre 2024 à 07:22.
Aujourd'hui, les 2 drivers ont normalement le nécessaire pour faire tourner Wayland.
Plutôt que Sway (je crois basé sur wlroots), pourrais-tu essayer le compositeur de référence Weston -en général plus à jour sur le support des derniers drivers?
Il contient une icône pour lancer un terminal; tu peux ensuite lancer ce que tu veux à partir de là.
Et aussi, je suppose que tu utilises un navigateur… si c'est une base Chrome, il faut savoir qu'il abuse d'extensions Wayland/GL vraiment spécifiques et pas bien gérées partout.
Pourrais-tu voir si ça se produit davantage avec lui; et si oui, éventuellement essayer Firefox par comparaison?
# wcurl à la conquête du monde
Posté par Tarnyko (site web personnel) . En réponse à la dépêche 24 ans de libcurl. Évalué à 3. Dernière modification le 04 septembre 2024 à 06:44.
En tant qu'homme engagé..
…je viens d'installer wcurl sur toutes mes distributions.
Un petit coup pour l'homme, un grand coup pour le progrès social !
[^] # Re: question importante
Posté par Tarnyko (site web personnel) . En réponse au journal 8th wonderland : un flim à revoir. Évalué à 2.
Ça dépend si c'est un flim de voleur ou d'homme qui a la classe.
[^] # Re: Plus rapide (?), mais pas plus light
Posté par Tarnyko (site web personnel) . En réponse à la dépêche XL-Converter 1.0, billet d'humeur et plaidoyer. Évalué à 2.
Un tel batch est à faire oui !
Perso je ne saurai m'engager sur aucun délai ; sauf que je posterai le résultat ici pour sûr :-).
[^] # Re: Plus rapide (?), mais pas plus light
Posté par Tarnyko (site web personnel) . En réponse à la dépêche XL-Converter 1.0, billet d'humeur et plaidoyer. Évalué à 4.
Effectivement 😲 !
Je viens de tester en double-aveugle avec Joritro (un camarade de code !) et ces paramètres/ résultats :
- JPEG : 80% (23,5 Ko)
- JPEG-LI : 60% (21,0 Ko)
Et là 2,5 Ko de moins pour la version JPEG-LI -c'était prévisible- mais oui elle est également plus jolie "à l'oeil" avec notamment moins de pâtés irréguliers dans l'espace central.
Je te remercie beaucoup, et vais du coup considérer cette lib pour mes traitements !
# Plus rapide (?), mais pas plus light
Posté par Tarnyko (site web personnel) . En réponse à la dépêche XL-Converter 1.0, billet d'humeur et plaidoyer. Évalué à 2. Dernière modification le 17 juin 2024 à 11:14.
Une note là-dessus.
Je viens d'essayer. Plus précisément:
- j'ai pris l'exemple C de JPEG-Turbo;
- j'ai appliqué ce patch (qui rend l'exemple "standard" en retirant le format 12-bits qui n'existe pas partout) et compilé ;
- j'ai executé 2 fois,
1x avec JPEG-Turbo, 1x avec JXL-jpegli:
Il en ressort que la 2ème image produite par jpegli est entre 3-5 Ko plus grosse.
C'est peut-être effectivement plus rapide sur des traitements de grosses images (ou des lots de grosses images) ; mais comme la taille était mon critère, je juge bon de l'indiquer.
# Compte d'ordinateur
Posté par Tarnyko (site web personnel) . En réponse au message Relation d'approbation. Évalué à 3.
Si ça peut aider,
Ce message signifie que la machine n'a pas réussi à se connecter avec son compte d'ordinateur nommé :
NOM_MACHINE$
dans la section "Ordinateurs" d'AD.
Ça se produit en général quand l'ordi esr resté déconnecté trop longtemps et que le contrôleur a changé son mot de passe sans qu'il en soit informé.
Ici le problème serait plutôt sur le protocole d'échange des clés Kerberos ou dudit mot de passe.
# Démarre en mode VESA/VGA ?
Posté par Tarnyko (site web personnel) . En réponse au message androïd-x86 sur VirtualBox : la vm ne fonctionne pas !. Évalué à 3.
Salut,
De mémoire, ce qu'il se passe est qu'Android n'a pas réussi à initialiser son système graphique.
C'est probablement dû au fait que le noyau démarre en mode graphique KMS, bien pour les distros "bureau" mais dont Android, faute de driver dédié, ne sait pas forcément quoi faire.
La solution était de s'inspirer de ce tuto,
çàd interrompre le boot avec la touche Tab, ajouter ce genre de paramètre à la ligne "kernel" :
et reprendre avec la touche Entrée.
Une fois que ça marche, on peut l'inscrire définitivement en modifiant le fichier Grub ; mais ça je te laisse chercher ;-).
# Vrai et compliqué à la fois... quota ?
Posté par Tarnyko (site web personnel) . En réponse au journal LWN : A plea for more thoughtful comments. Évalué à 6. Dernière modification le 04 juin 2024 à 20:14.
En gros le texte de LWN, c'est un (r)appel à la civilité.
Qui n'aboutira sans doute pas à la fermeture des commentaires, car sans commentaires ni polémiques, qui viendra encore ?
LWN et autres ont beau produire de beaux résumés, sans les réactions parfois très opinionnées de profils impliqués dans l'OSS, ça sonnerait rapidement creux… Imaginez LinuxFR comme ça !
Le "max X commentaire PAR utilisateur PAR jour" par contre, c'est une option intéressante.
Car un gars qui passe sa journée à spammer le site, c'est sûrement pas un profil sérieux…
… et un profil sérieux est de son côté bien trop occupé pour même s'apercevoir de la présence du quota !
[^] # Re: siite
Posté par Tarnyko (site web personnel) . En réponse au journal C23, listes variantes et le turfu. Évalué à 2.
Je suppose que tu fais référence à ce genre d'usage ?
Je suis dans l'embarqué aussi, où C++ est quand même assez toléré de mon côté (d'où ma mention) et a l'avantage de l'écosystème installé.
Rust je pousse pour à mort ; c'est quasi le cas d'usage idéal ! Juste pour les projets déjà installés, il est parfois considéré "trop récent" ou trop peu riche en devs par les décideurs…
(après si tu réfères à un mélange que je ne connais pas, je suis intéressé !)
[^] # Re: siite
Posté par Tarnyko (site web personnel) . En réponse au journal C23, listes variantes et le turfu. Évalué à 2.
Quand tu parles de tuple, je suppose que ça irait aussi avec ce pattern:
On y est presque, mais pas tout à fait.
C est un langage très conservateur ; pour ce sucre-là en bas niveau, il ne faut pas s'interdire de regarder vers C++ (ou Rust).
# Thx
Posté par Tarnyko (site web personnel) . En réponse au journal Transférer sa licence Windows dans une VM. Évalué à 4.
Procédure incroyable qui se révèlera utile dans peu de temps ; merci bien !
[^] # Re: Propulsera les forks ?
Posté par Tarnyko (site web personnel) . En réponse au journal Google continue son chemin sur la fin des extensions Manifest V2. Évalué à 2.
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).
[^] # Re: Propulsera les forks ?
Posté par Tarnyko (site web personnel) . En réponse au journal Google continue son chemin sur la fin des extensions Manifest V2. Évalué à 5.
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.
[^] # Re: Propulsera les forks ?
Posté par Tarnyko (site web personnel) . En réponse au journal Google continue son chemin sur la fin des extensions Manifest V2. Évalué à 3. Dernière modification le 31 mai 2024 à 15:53.
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 !
[^] # Re: Propulsera les forks ?
Posté par Tarnyko (site web personnel) . En réponse au journal Google continue son chemin sur la fin des extensions Manifest V2. Évalué à 2.
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)
[^] # Re: siite
Posté par Tarnyko (site web personnel) . En réponse au journal C23, listes variantes et le turfu. Évalué à 3.
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".
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.
[^] # Re: Bons arguments... pour Google
Posté par Tarnyko (site web personnel) . En réponse au journal Google continue son chemin sur la fin des extensions Manifest V2. Évalué à 3.
Je pense également que les bons arguments leur sont tellement évidents,
qu'ils leur permettent de faire passer les mauvais en loucedé.
# Propulsera les forks ?
Posté par Tarnyko (site web personnel) . En réponse au journal Google continue son chemin sur la fin des extensions Manifest V2. Évalué à 5.
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 ?
[^] # Re: IRC
Posté par Tarnyko (site web personnel) . En réponse au journal ICQ sera bronsonisé fin juin. Évalué à 4. Dernière modification le 29 mai 2024 à 16:33.
Ah y a un truc prévu pour ? Je vais voir !
EDIT: effectivement, je ne connaissais pas bien ! Merci!
[^] # Re: IRC
Posté par Tarnyko (site web personnel) . En réponse au journal ICQ sera bronsonisé fin juin. Évalué à 3.
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…
[^] # Re: Intéressant, cependant...
Posté par Tarnyko (site web personnel) . En réponse au journal Dev update du jeu Bim!. Évalué à 3.
Ce serait cool ouais 😀 !
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…)