ff9097 a écrit 655 commentaires

…l'engouement de JPEG-XL. On a déjà pas mal de formats d'images modernes. Qu'apporte-t-il ?

D'ailleurs comment ça fonctionne ? Une liste arbitraire de nom de paramètres d'URL lié au pistage ? Ça paraît un peu bancale

J'ai eu à travailler avec un scanner Zebra sous Android et en gros il faut fuir comme la peste le SDK Zebra. Il est possible de configurer Datawedge pour simplement recevoir un "broadcast intent" dans son application (en gros la chaine de caractère contenant le scan).

Pardon? D'aucuns et pas des manches trouvent le C++ (pour en rester aux langages objet) bien plus simple que Python qui est tout sauf un langage simple. Sauf à confondre simple et lisible (même pour le néophyte s'il est anglophone, mais de là à lui faire prendre le clavier…), à la limite!

Faut pas exagérer non plus

Quel est le rapport ?

Mais si vous avez mieux, je suis preneur

Docker

Aucune grosse organisation n'utilise Github comme dépôt principal

Google ?

La garantie réparation sur site n'est pas très cher ils n'ont donc pas intérêt à ce que ça soit trop fragile

Je pense qu'un ThinkPad T ou X ça reste du très robuste

Pas mal de tenir 10 ans avec un truc infâme qu'est un ThinkPad E

ou juste utiliser Kotlin

monObj?.call()

https://docs.ponyorm.org/integration_with_fastapi.html?highlight=async#async-and-db-session

Pony was not developed for async usage, and it may be tricky to use it correctly in an async environment. However, if only part of your application is async, you will be fine if you stick to these two rules:

Je viens de voir qu'il n'y a pas de support de l'async IO ce qui fait un peu tâche

Une comparaison avec SQLAlchemy ? Qui a plutôt bonne réputation dans le domaine

Les mainteneurs Debian dépassent les limites

Xorg va rester dans les dépôts pendant un moment. Installé uniquement en tant que dépendance de gestionnaires de fenêtres qui n'ont pas fait la transition. Ça ne devrait pas représenter beaucoup de travail vu qu'il n'évolue plus

Xorg a pourtant continué à fonctionner comme avant. Ça a mis plusieurs années avant d'avoir Wayland utilisable quotidiennement et encore plus pour voir une distribution (Fedora ?) l'adopter par défaut. Et encore je pense qu'au départ c'était Intel only.

Cela ne m'empêche pas de regarder le passé et le présent avec un regard critique pour en tirer des leçons.

Et les leçons c'est quoi ? Parce que pour moi Wayland c'est une très bonne décision de long terme. Certes ce fut long et compliqué mais indispensable

Ça ne réponds pas à la question

Qu'apporte Qt 6 ? Encore une longue migration technique qui demande probablement pas mal de ressources qui pourraient être utilisés pour autre chose.

Suffit de forker le projet ? Ça réglera le problème du développeur par la même occasion

Mais sur le fond je suis complètement d'accord, je déteste les ORM, je ne comprends pas l'intérêt de réécrire une requête SQL, mais en Java, en PHP, ou autre, avec une surcouche qu'on ne maîtrise pas et dont on ne sait pas s'il ne va pas créer des requêtes toutes pourries

N'importe quel ORM te permet de logger les requêtes SQL générés

Même si c'est multi-plateforme il y a forcément du code spécifique Linux quelque part pour écrire dans le $HOME/.eclipse
Personnellement je suis étonné de lire plus haut que ce n'est pas trivial. Ça me semble relativement simple quand même et accessible par un contributeur externe (au lieu de poster ici par exemple)

C'est rarement le choix d'une entreprise

Pour moi le gros intérêt de chromeOS c'est surtout (si je ne me trompe pas) qu'aucune donnée ne peut être stocké en local et que donc il n'y a jamais de perte de données lors d'un reset