Gof a écrit 2224 commentaires

Et si il y a une coupure de courent, ou que te femme débranche la mauvaise prise pour brancher l'aspirateur alors que tu met la dernière touche ?
Comme on est jamais à l'abri des bugs, il faut toujours gérer les crash proprement. Autosave, et modification atomiques des fichier (enregistrer une copie, et atomiquement remplacer l'original).
Et donc tu ne perds pas plus de quelque minutes de travail.

Désolé, mais c'est pas déjà le cas ?
Qu'est-ce qui se passe d'après toi, quand il n'y a plus de mémoire avec firefox ?

En tous cas, aucun programme utilisant GLib ou GTK+ http://jeffreystedfast.blogspot.be/2008/02/worse-is-better-in-form-of-autosave.html

Peut être pour un serveur ou une application critique. Mais pour un programme avec une interface graphique, ça n'en vaux pas la peine.

Ça demande énormément de travail pour aucun gain.

Ce qu'il faut faire pour voir pourquoi ton programme prends autant de mémoire:

• T'assurer que c'est bien le tas (heap) qui prends la mémoire, et pas un fichier mapper (par exemple, le code des bibliothèques, ou un fichier de polices)

• valgrind --tool=massif, et regarder le résultat avec massif-visualizer

Pour donner un autre exemple sur un serveur ou dans une bibliothèque c'est vraiment pas ce qu'il y a de mieux à faire. Il faut tester et respectivement renvoyer une erreur au client (par ex indiquant de réessayer après un temps d'attente exponentiel en fonction du nombre d'erreurs)

Pas si simple. Il faut aussi s'assurer que tout ce passe comme prévu : de ne pas garder de mutex ver ouillé par erreur, de bien libérer toutes les ressources qui ont été allouée par la fonction. De garder l'état du programme dans un état correcte, sans structure de donnée à moitié initialisées.

En plus l'utilisateur de la bibliothèque devra faire pareil et ajouter du code pour gérer cette erreur.

Et tout ça pour pas grand chose au final. Le plus simple est de terminer le programme immédiatement. Et de bien récupérer en cas de crash.

Les programmes qui ont vraiment besoin de gérer les cas d'OOM sont plutôt rares. Et il vaux mieux ne pas gaspiller de temps et de ressources à le faire.

Ne le fait pas.

Dans un programme utilisateur ça n'a aucun intérêt.

Le mieux que tu puisse faire c'est un truc du style
C
assert(src_dup);

Si tu veux éviter les éventuelles faille de sécurités. Mais pour un 'bête' programme utilisateur du style concky, il n'y a pas grands risque. Tout ce que tu fais c'est perdre des cycles à tester et rajoute du code qui prends de la place en cache.

Gérer les "OOM" (Out Of Memory) est inutile pour deux raison:

1 - C'est impossible de tester tout les cas possible d'échec de realloc. Et du code non testé à de forte chance de ne pas fonctionner

2 - Les systèmes d'exploitation moderne "overcommit" la mémoire. Ça veux dire que même si il n'y a plus de mémoire, réalloc va quand même fonctionner. Et c'est au moment ou cette mémoire va être utilisée que le noyaux va devoir récupérer de la mémoire en tuant un processus (OOM killer) (en utilisant des heuristique, mais pas forcément celui qui demande la mémoire).

Bien sûr il y a des cas ou c'est nécessaire de gérer ça correctement (en embarqué par exemple). Mais pas ici.

C'est le syndrome SDS
(Syndrome du Disque SSD)

Aussi appelé le syndrome PNS (PIN Number Syndrome)
Voir aussi RAS syndrome

C'est triste ton avis sur les running gag

Il n'y a pas vraiment de graphismes : ce sont les pièces d'échecs unicode: ♔♕♖♗♘♙♚♛♜♝♞♟
Il fallait bien que ça serve.

Sinon, il y a aussi le Chessboxing

https://linuxfr.org/users/booga/journaux/burn-berlin-burn

On était deux.

Par contre, cette semaine ça va pas pour moi,

La Npresentation

Oui.

En particulier dans l'embarqué.
(Saviez vous par exemple que la Freebox était implémentée avec Qt ? {url} )

Pour ceux qui n'auraient pas compris: « Est mort » ça veux simplement dire qu'il est bronsonisé.

Celle de l'époque, selon les panthéon on a zoophilie, inceste, tromperie, lucre…

Mais est-ce que ces chose là étaient vraiment considérées comme immorales à l'époque ?

Quand on est en prison, c'est peut-être aussi qu'on a une morale douteuse :)

C'est quoi une morale douteuse ?
Une morale qui n'est pas compatible avec la morale de la moralité des gens ?
Personelement je pense qu'il n'y a pas de morale universelle ou absolue. Ce qui est bien pour certains est peut être mal pour d'autres, et inversément.

C'est pas Melbourne, c'est Brisbane.

En réalité, d'après l'annonce, c'est maximum 125 employés, et non l'ensemble comme le dit la dépêche.

En particulier, les ~50 employés Nokia qui bossaient a Brisbane (les développeurs de QtQuick) ce sont déjà fait officiellement virer
Il faut croire que Digia n'avais pas envie d'avoir des problèmes avec les fuseaux horaires.

Super tu réponds à l'une d'entre elle. Et les autres ?

Une seule suffit pour contredire tes propos (qui disent que QtQuick ne réponds à aucune des problématiques).
Bref, j'ai raison et tu as tort :-)

À toi maintenant de dire en quoi Qt ne réponds pas au problématiques que tu cite comparé a ses concurrents.

Ca ne répond à aucune des problématiques que j'ai cité.

Si. Ça réponds à au moins une des problématiques citées :-)

(Par exemple QtQuick2 utilise mieux le GPU. Et pour les autres, soit Qt y réponds, soit les concurrents n'y répondent pas)

QtQuick/QML c'est quelque chose de neuf qui est sensé répondre aux problématique actuelles.
Oui, ça garde les bases solides de Qt derrière. Au final c'est un nouveau langage et un nouveau paradigme.
Ça remplace toute la partie Widget de Qt en quelque sorte.

Si j'ai bien compris l'interview du CEO de Digia, les contributions de Digia sont minimes parce que Nokia ne voulait pas les intégrer.

Ce n'est pas Nokia qui veux ou ne veux pas intégrer les modifications, ce sont les « reviewer » (composé principalement de dev Nokia, mais pas que)
Et si les contributions ne sont pas acceptés c'est peut être car elle ne sont pas de bonne qualité.

PErsonnellement, je trouve que le dialogue d'enregistrement de fichier de qt est suffisamment meilleure pour qu'on se plaigne quand on enregistre des fichiers dans un logiciel gtk.

Quelle boite de dialogue de Qt ?
Celle par défaut basé sur celle de Windows 95 ? http://qt-project.org/doc/qt-5.0/images/filedialogurls.png

Le truc c'est que Qt s'intègre dans l'environnement dans lequel le programme est lancé. Si on ouvre un programme Qt dans Gnome, on aura la boite de dialogue GTK, si on ouvre dans KDE on aura celle de KDE, sous mac on a celle de mac, …
Celle "builtin" Qt n'est visible que pour les système sans boite de dialogues (embarqué) ou si le développeur customize la boite de dialogue avec des widget additionnels.

Petit rappel historique:

Qt était à l'origine développé par Trolltech. Au début proprio, il est très rapidement devenu libre, et n'a pas cessé d'être de plus en plus ouvert. Qt était à l'époque sous double licence: GPL et commerciale. Ce qui signifie que les gens qui veulent faire du proprio avec Qt doivent payer une licence qui sert a financer le développement.
Qt était principalement utilisé sur le desktop, mais aussi embarqué. Trolltech a aussi investit beaucoup d'argent dans un autre produit: Qtopia qui était sensé être une platforme pour téléphone mobile (comme Android). Qtopia fut un échec commercial)

En 2008, Nokia rachète Qt. Leur but est d'unifier et faciliter le développent pour leurs platformes. Il prétende que les client de Trolltech sont encore important. Mais en vérité, tout ce qu'il veulent c'est que les gens utilisent Qt dans le but de développer leur écosystème. C'est pour ça que la licence de Qt est changée vers LGPL. Pratiquement tout le développement de Qt est maintenant concentré sur le mobile. Il y a beaucoup de travail pour porter Qt vers les platformes Nokia. Pendent ce temps, les client qui payent une licence commerciale sont un peu négligés. C'est pourquoi Nokia décide de externaliser la revente des licences et le support à Digia.

En parallèle, Elop, le nouveau CEO de Nokia essaye de faire quelque chose pour "sauver" Nokia.
Pour rappel, le problème était que Nokia perdait des parts de marché sur les smartphone comparé à Apple et Android. La raison invoquée est l'absence d'un écosystème d' « Apps ». Problème de poule et d'œuf: les smartphone Nokia n'ont pas beaucoup de succès, donc les développeurs ne développent pas d'« Apps », donc les platformes ne décolle pas. La stratégie précédente était que Qt allait aider les développeur car c'était beaucoup plus attrayant que le développement Symbian. Mais alors que les téléphone Nokia avec Qt arrivaient à peine sur le marché, Elop annonce début 2011 que Nokia va tout miser sur Microsoft avec de l'espoir que l'écosystème de Windows se développe plus facilement. Avec cette annonce il tue les platforme actuelle de Nokia alors que les téléphone avec Windows Phone sont prévu un an plus tard.

Il est aussi annoncé que Qt ne sera pas porté sur Windows Phone. Quel avenir pour Qt dans Nokia alors ?
Les rumeurs disent que Nokia développe une nouvelle platforme basée sur Linux pour les téléphone bas de gamme. Mais en pratique Nokia mets de moins en moins de ressources dans le développement de Qt, et cela ce limite à ce qui intéresse Nokia, c'est à dire de l'embarqué avec Wayland. Toutes les autres platformes (Mac, Windows, X11) sont totalement négligées.

Heureusement que le développement de Qt est bel et bien ouvert maintenant. Tout le monde peux facilement envoyer des patches et même les intégrer sans que un employé de Nokia intervienne.

Mais voilà, Nokia est dans la merde car il n'a pas vendu beaucoup de téléphone ces dernier temps. Donc ils annoncent il y a un peu plus d'un mois une grosse réduction d'effectif. Ils ont apparemment décider d'abandonner entre autres leur nouvelle platforme pour le bas de gamme, et de ce séparer définitivement de Qt. Tous les devs qui bossaient sur Qt vont probablement être viré. (Sauf si il y a un accord avec une autre boite qui les reprendrais)

La situation actuelle est:

• Qt est libre et utilisé par pas mal de grosses boites. Il y a déjà beaucoup de développeurs externes. Il restera maintenu.
• Nokia est propriétaire de l'infrastructure de test. C'est un énorme serveur avec beaucoup de machine virtuelle qui exécute les tests de Qt avant chaque intégration sur plein de platforme et configuration (+ une ferme de mac mini car la licence ne permet pas de virtualisation).
• Digia a pour le moment le monopole de revente de licences de Qt. Mais les contribution de Digia sont minimes.

Autre possibilité à quoi ?

Le framebuffer n'est que la partie affichage de bas niveau, il ne gère pas tout ce qui est input ou possibilité d'avoir plusieurs clients (plusieurs fenêtres de processus différents).
Par ailleurs, Il existe des implémentations de wayland (partie serveur) qui tournent sur le framebuffer.