Tarnyko a écrit 478 commentaires

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.

C’est probablement techniquement possible de compiler la plupart des projets Java à la main, mais je suis franchement pas convaincu de l’intérêt.

En fait, c'est moins une question d'utilité (car moi aussi je me sers de l'IDE 24H/24) que de pédagogie.

Quand c'est ton 1er cours de Java, que tu demandes à ton prof comment compiler ton projet constitué d'un seul .java ; et qu'il te répond qu'il sait pas, que de toute façon on va utiliser Eclipse… Précision supplémentaire : il n'a pas non plus cité maven, ni gradle, ni aucun outil du genre.

Notre taf (qui est aussi pour certains notre passion) est basé sur des couches qui s'empilent.
Ne pas évoquer les couches de base, au moins durant la phase d'apprentissage, c'est rendre l'élève captif d'un empilement ad hoc qu'il sera incapable de reconstruire à sa façon si on le change de terrain. À mon humble avis.

Alors ça… alors ça !!!

Pour qu'il y ait suppression, il faut faire full-upgrade avec apt et dist-upgrade avec apt-get.

OK. Donc en gros : il m'a dit n'importe quoi pour se justifier 😀.
(PS : merci pour l'astuce !)

Je pense qu'il voulait dire, cette version de la librairie n’est entrée dans debian

Ah d'accord, ça sous Debian Stable c'est effectivement plus courant. Pas grand-chose à faire part downgrade son code ou installer la nouvelle lib dans un coin…

(Je me sens vieux, depuis quand faut-il des pilotes dédiés pour une manette USB ? :D :D)

Protip : en se restreignant à des pads XBox pas trop récents, on peut utiliser ça .

Cette librairie n’est entrée dans debian que depuis dix jours environs

Ah oui quand même.
wlroots, c'est la lib de base de 90% des compositeurs Wayland tiers (les autres ont leur propre truc, et moi j'utilise libweston). Tu en aurais eu besoin tôt ou tard.

Par contre : j'ai une connaissance qui a viré Debian Stable après plusieurs occurences de l'apt-get install qui dégage des paquets de base (GNOME, etc). En contre : il auto-validait les apt-get sans lire le détail des paquets ajoutés et supprimés…
Ton avis ? On peut s'en prémunir en marquant des paquets comme "à dégager jamais" ?

Hello David,
Merci pour ton comm, je prends ça dans l'ordre !

Sous licence GPL, pour une bibliothèque c'est la plaie. Personne ne va l'utiliser, au pire LGPL.

Très bonne remarque ! J'avais oublié ça en générant la version "library" de la chose.
Je regarde pour changer les headers et mettre un COPYING approprié dans le répertoire.

En C23 tout cela devient des keywords, donc à éviter.

Excellente remarque également. Je vais les #ifdef-garder.
(NB: j'ai prévu une version C23 pour quand j'aurai accès à un compilo capable. Ça me permettra de tester toussa)

Bof, les C11 threads sont extrêmement limités. En vrai personne ne les utilise et on préfère pthread la plupart du temps

Je suis d'accord sur le fait que c'est une version appauvrie des pthreads (sur lesquels ils sont en réalité basés au runtime).
Perso je ne me sers pas de toutes leurs fonctions, sauf celle-là… dont l'absence me paraît absurde:

while (pthread_mutex_destroy(&mtx) == EBUSY) {
  // mutex encore verrouillé ailleurs, on attend pour détruire 
}

La version C11 "mtx_destroy()" ne renvoie rien… dans ces conditions, le seul contournement c'est de se discipliner ou -super lourd- rajouter une variable de synchro. J'ai choisi l'option 1 pour pas gonfler, mais dommage quand même…

(après mon opinion est que c'est bien de les avoir, même si le draft final est pauvre de fou)

Il y a aucune fonction pour afficher les erreurs en chaine de caractère donc on peut pas faire un convivial perror ni strerror(errno).

Assez d'accord ; c'est là que j'ai réalisé que les messages "perror()" étaient figés dans le runtime. J'avais toujours cru qu'on pouvait les surchager… tu me recommandes quoi, fournir ma propre fonction ?

pourquoi des script shell pour compiler du code et pas un Makefile/ CMake

Etant une pure démo, CMake (que j'utilise couramment) était trop lourd, hors de question.
Un Makefile ça pourrait se faire, juste j'en ai pas écrit à la main depuis des plombes ! Je vais regarder…

(au pire j'ajouterai des $CPPFLAGS/$CFLAGS dans le script -pour que l'utilisateur puisse facilement surcharger les commandes)

Tout ce mal qu'ils se donnent quand même,
et RMS qui va toujours pas installer Debian sur son laptop pour autant ("Not free enough !")…

Pourtant, on a tous du bien à dire de 42 😉.
Car le bien étant le juste milieu, il s'applique bien à la proportion de 50% des profils qui en sortent !

Oh là là, tu utilises des // pour commenter du code C, à la place des /* */ ? C'est un peu cavalier quand même, ça ne passera pas sur tous les systèmes.

On me disait déjà ça dans mes cours, quand 1999 était pourtant trèèès passé 😄.

Je pense que c'est un conservatisme "de fait" qui s'appuie sur la transmission informelle plutôt que sur la normalisation formelle :
très peu fréquente et mal suivie en C, une tous les 10 ans ; en C++ c'est important et tous les 3 ans maxi.

Les profs de C reproduisent le code du Grand Schtroumpf ; pour les innovations ils considèrent que c'est pas chez eux et t'envoient vers leurs collègues Java qui savent pas compiler sans IDE ("t'en auras jamais besoin").
(au fait, on t'a dit que j'aimais pousser des [gueule] au fil de l'eau ?)

Très impressionnant.
Et je dis en sachant bien que tu utilises un SDK (mais faire du 100% ASM en 2024, c'est exclu…).
Car là c'est déjà fonctionnel et jouable, j'ai eu envie de le terminer -et l'ai fait !

P.S.: J'aime bien la petite spécificité du jeu, déjà dévoilée plus haut :

if (world.wrap_x) {

et j'ai pas besoin de demander pourquoi les structures sont "packed" avec des membres quasi-tous 16-bits 😉.

2 trucs que j'ai remarqués, et peut-être liés à l'émulateur que j'utilise (Snes9x) :
- si je mappe les boutons de cette façon : ["B"(=tirer) / "A"(=sauter)] ; mon perso saute forcément vers la gauche… ?
- parfois en tirant une flèche avec l'autre bouton ["A"], un mouvement -vers la gauche, mais pas sûr- a lieu à la place.

et je concours que mapper ["Start"]"=["B"] dans les menus serait une très très bonne idée !

l’écrasante majorité des participants au FOSDEM paient leurs consommations avec leur téléphone. Cela vous surprend-il ?

J'ai constaté ça aussi.
Je pense que c'est plutôt une question de génération que de librisme ou même de technologisme : les djeunz utilisent rarement le liquide.

Perso si je paie avec le tél, c'est forcément avec une cryptocoin ; pourquoi faire les choses à moitié ;-) ?