Oui, enfin à priori s'il a fait une grosse donation plutôt que plusieurs petites c'est pour profiter de la publicité engendrée pour encourager d'autre a donner pas pour 'raconter sa vie'.
mais pas si facile à recevoir.
La fondation FreeBSD a déjà l'habitude de recevoir des donations donc elle a déjà les structures pour, après effectivement un don comme ça est probablement plus compliqué a gérer que les contributions 'habituelles'.
Plutôt d'accord avec toi, note quand même que tu liste que des choses que Rust ne sait pas faire par rapport à Ada, mais il y a l'inverse aussi: Ada n'a pas le typage incluant la durée de vie comme Rust (enfin je crois).
Il y a un ramasse miettes dans la base mais j'ai lu plusieurs fois que les devs de jeux contournaient en fait le GC faisant des trucs plutôt sale comme réutiliser les objets existants plutôt que de les effacer.
A partir de là, le GC est un ami ou un ennemi pour un dev de jeux?
Ça se discute..
Ah? Des petits jeux pas très interactif alors..
Quand je vois les articles sur les problèmes de GC dans Minecraft, ça me conforte dans l'idée que Java n'est pas très adapté pour faire des jeux..
Merci je sais. Mais pour qu'un serveur X soit un serveur X il doit supporter tout le protocole même si les toolkit modernes ne s'en servent plus.
Dessiner une ligne a peu d'intérêt mais avec X tu peux cacher les lettres côté serveur d'affichage ce qui permet d'afficher du texte avec une utilisation de bande passante réduite (la plupart du temps, ça peut dépendre du rendu).
Donc en théorie X peut avoir des avantages en efficacité sur Wayland en distant pour comparer en pratique il va falloir attendre que Wayland devienne mature..
PS: je sais bien que tout nouveau tout beau, mais je ne comprends pas pourquoi le poste précédent a été moinsser..
Pas vraiment non: à l'heure actuelle pour avoir le déport d'écran avec Wayland il faut que le compositeur le supporte ce qui est loin d'être toujours le cas! Avec X, dans la majorité des cas ça fonctionnait sans problème, avec Wayland c'est optionnel (et immature).
En plus, par conception le déport d'écran Wayland est en théorie moins efficace qu'avec X (puisqu'avec X on peut envoyer des buffers comme Wayland mais pas l'inverse: on ne peut pas dire affiche moi une ligne avec Wayland), là c'est effectivement plus discutable car la qualité de l'implémentation l'emporte souvent sur des avantages "théoriques".
Plutôt d'accord sur le problème du wrapping en cas d'overflow, mais ça reste quand même mieux que le C/C++ avec son comportement indéfini (bon c'est pas dûr).
C'est de la faute des concepteurs de CPUs!! Ils auraient du suivre le MIPS ou toutes les instructions entière ont un mode 'trap sur overflow' ça permet de détecter le dépassement entier avec un cout quasi-nul.
Le seul CPU qui prévoit de fournir l'équivalent de ce que fournissait le MIPS, c'est le Mill un CPU même pas implémenté en FPGA à l'heure actuel..
Si je comprends bien pour obtenir l'équivalent d'un export DISPLAY avec RDP il faudrait ajouter un démon qui va faire la connexion car avec RDP se fait de la partie qui a l'écran receveur a la partie qui émet l'image de l'application au contraire d'X.
Weston a une backend RDP mais j'ignore si elle permet d'exporter juste une fenetre ou si c'est nécessairement tout le bureau.
Ce que tu propose me parait possible en tout cas.
Parce que Wayland peut être utilisé dans des contextes différents.
Donc tu as un protocole 'de base' (wayland) pour l'envoi de buffers graphiques plus d'autre protocole qui eux sont utiles ou pas selon le contexte.
xdg-shell c'est le protocole pour les environnements de bureaux (gestion des fenêtres, des titres, du copier/coller(pas sûr là)), protocole dont tu n'as rien a faire si tu est dans l'embarqué par exemple.
Je crois qu'il y a un consortium automobile qui travaille sur un protocole par exemple.
Ouaip, avec Wayland l'export DISPLAY devient optionnel.. Si le compositeur le supporte c'est possible, sinon..
Sailfish utilise quel compositeur? Parce que si c'est Weston, il a une backend RDP donc tu devrais pouvoir l'utiliser mais bon je n'ai jamais lu aucun retour sur cette backend alors je ne sais pas si elle est fonctionnelle!
Hum, cet article a provoqué pas mal de réaction sur ceux qui utilisent leur touchpad de manière "non-standard": soit c'est l'article soit libinput va faire grincer des dents pas mal de monde..
Pour moi, Rust c'est Ada++: un langage très strictement typé dont les types incluent même la durée de vie des variables, hors je vois que pas mal de gens tapent sur Ada car ils trouvent le compilateur 'trop strict', donc c'est comment Rust en pratique?
Pas trop dur de satisfaire le compilateur pour la gestion des 'durée de vie'?
Ah? Je ne trouve pas moi.
Note que ce diagramme est une simplification de ce qui se passe en réalité: les compositeurs peuvent être empilé par exemple.
Encore?
Ça a été un sujet de discussion sur LWN, bien longue la discussion et finalement la raison pour laquelle ils ont fait ça est que xdg-shell est encore considéré comme étant expérimental donc casser la compatibilité sur un protocole expérimental n'implique pas de mettre à jour le numéro de version majeur du projet ce qui me parait normal: http://lwn.net/Articles/612653/
[^] # Re: Tu t'es avancé un peu trop vite
Posté par reno . En réponse au journal Sécurité de l'open source Vs closed source: MS14-066. Évalué à 2.
1 semaine (MS14-066) vs 24h(Heartbleed), ça change beaucoup de choses!!
[^] # Re: Quelle classe
Posté par reno . En réponse au journal Freebsd reçoit une peu de thunes.. Évalué à 6.
Oui, enfin à priori s'il a fait une grosse donation plutôt que plusieurs petites c'est pour profiter de la publicité engendrée pour encourager d'autre a donner pas pour 'raconter sa vie'.
La fondation FreeBSD a déjà l'habitude de recevoir des donations donc elle a déjà les structures pour, après effectivement un don comme ça est probablement plus compliqué a gérer que les contributions 'habituelles'.
[^] # Re: Rust vs Go
Posté par reno . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 4.
Plutôt d'accord avec toi, note quand même que tu liste que des choses que Rust ne sait pas faire par rapport à Ada, mais il y a l'inverse aussi: Ada n'a pas le typage incluant la durée de vie comme Rust (enfin je crois).
[^] # Re: What? What ? In the hassle!
Posté par reno . En réponse au journal Des nouvelles sur la version 1.0 de Rust. Évalué à 4.
Il y a un ramasse miettes dans la base mais j'ai lu plusieurs fois que les devs de jeux contournaient en fait le GC faisant des trucs plutôt sale comme réutiliser les objets existants plutôt que de les effacer.
A partir de là, le GC est un ami ou un ennemi pour un dev de jeux?
Ça se discute..
[^] # Re: What? What ? In the hassle!
Posté par reno . En réponse au journal Des nouvelles sur la version 1.0 de Rust. Évalué à -2.
Ah? Des petits jeux pas très interactif alors..
Quand je vois les articles sur les problèmes de GC dans Minecraft, ça me conforte dans l'idée que Java n'est pas très adapté pour faire des jeux..
[^] # Re: What? What ? In the hassle!
Posté par reno . En réponse au journal Des nouvelles sur la version 1.0 de Rust. Évalué à 2.
Ton Java?
Ton C++ plutôt, Rust n'est pas un concurrent de Java..
# Une petite question
Posté par reno . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 3.
Tiens? Je croyais que ces licences étaient équivalentes, quelqu'un sait il pourquoi il y a ces 2 licences?
Bon ça n'a pas une grande importance..
En tout cas merci pour la dépêche.
# Le gestionnaire de fenêtre pavant fonctionne t'il avec Wayland?
Posté par reno . En réponse à la dépêche Enlightenment DR 0.19 et autres nouveautés éclairées. Évalué à 3.
Si oui, ça permettra d'en finir avec la sempiternelle discussion sur ce sujet..
Par contre j'imagine que contrairement à Weston le compositeur Wayland d'E19 n'a pas de sortie RDP..
[^] # Re: un troll de moins ?
Posté par reno . En réponse au journal wlfreerdp: un client Wayland pour FreeRDP. Évalué à 1.
Merci je sais. Mais pour qu'un serveur X soit un serveur X il doit supporter tout le protocole même si les toolkit modernes ne s'en servent plus.
Dessiner une ligne a peu d'intérêt mais avec X tu peux cacher les lettres côté serveur d'affichage ce qui permet d'afficher du texte avec une utilisation de bande passante réduite (la plupart du temps, ça peut dépendre du rendu).
Donc en théorie X peut avoir des avantages en efficacité sur Wayland en distant pour comparer en pratique il va falloir attendre que Wayland devienne mature..
PS: je sais bien que tout nouveau tout beau, mais je ne comprends pas pourquoi le poste précédent a été moinsser..
[^] # Re: un troll de moins ?
Posté par reno . En réponse au journal wlfreerdp: un client Wayland pour FreeRDP. Évalué à 2.
Un troll?
Pas vraiment non: à l'heure actuelle pour avoir le déport d'écran avec Wayland il faut que le compositeur le supporte ce qui est loin d'être toujours le cas! Avec X, dans la majorité des cas ça fonctionnait sans problème, avec Wayland c'est optionnel (et immature).
En plus, par conception le déport d'écran Wayland est en théorie moins efficace qu'avec X (puisqu'avec X on peut envoyer des buffers comme Wayland mais pas l'inverse: on ne peut pas dire affiche moi une ligne avec Wayland), là c'est effectivement plus discutable car la qualité de l'implémentation l'emporte souvent sur des avantages "théoriques".
[^] # Re: simple ?
Posté par reno . En réponse au journal Rust en version 0.12. Évalué à 3.
Hum, avec une syntaxe pareil 99% des gens utiliseront les cast classique au lieu de la version safe :-(
[^] # Re: simple ?
Posté par reno . En réponse au journal Rust en version 0.12. Évalué à 2.
Plutôt d'accord sur le problème du wrapping en cas d'overflow, mais ça reste quand même mieux que le C/C++ avec son comportement indéfini (bon c'est pas dûr).
C'est de la faute des concepteurs de CPUs!! Ils auraient du suivre le MIPS ou toutes les instructions entière ont un mode 'trap sur overflow' ça permet de détecter le dépassement entier avec un cout quasi-nul.
Le seul CPU qui prévoit de fournir l'équivalent de ce que fournissait le MIPS, c'est le Mill un CPU même pas implémenté en FPGA à l'heure actuel..
[^] # Re: triste
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 3.
Merci pour ta réponse.
Si je comprends bien pour obtenir l'équivalent d'un export DISPLAY avec RDP il faudrait ajouter un démon qui va faire la connexion car avec RDP se fait de la partie qui a l'écran receveur a la partie qui émet l'image de l'application au contraire d'X.
[^] # Re: triste
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 4.
Tu peux développer? C'est la première fois que j'entends parler de fullscreen-shell..
Ça marche bien la backend RDP de Weston?
[^] # Re: A noter: la release a été faite par Pekka Paalanen.
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 4.
Effectivement d'après Wikipedia c'est Lipstick (qui est propriétaire) qui est le compositeur.
Pas de bras, pas de chocolat.
[^] # Re: triste
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 5.
Weston a une backend RDP mais j'ignore si elle permet d'exporter juste une fenetre ou si c'est nécessairement tout le bureau.
Ce que tu propose me parait possible en tout cas.
[^] # Re: triste
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 5.
Parce que Wayland peut être utilisé dans des contextes différents.
Donc tu as un protocole 'de base' (wayland) pour l'envoi de buffers graphiques plus d'autre protocole qui eux sont utiles ou pas selon le contexte.
xdg-shell c'est le protocole pour les environnements de bureaux (gestion des fenêtres, des titres, du copier/coller(pas sûr là)), protocole dont tu n'as rien a faire si tu est dans l'embarqué par exemple.
Je crois qu'il y a un consortium automobile qui travaille sur un protocole par exemple.
[^] # Re: triste
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 4.
C'est xdg-shell qui est expérimental pas Wayland.
Xdg-shell c'est spécifique aux environnements de bureaux genre KDE/Gnome.
[^] # Re: A noter: la release a été faite par Pekka Paalanen.
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 2.
Ouaip, avec Wayland l'export DISPLAY devient optionnel.. Si le compositeur le supporte c'est possible, sinon..
Sailfish utilise quel compositeur? Parce que si c'est Weston, il a une backend RDP donc tu devrais pouvoir l'utiliser mais bon je n'ai jamais lu aucun retour sur cette backend alors je ne sais pas si elle est fonctionnelle!
[^] # Re: libinput
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 2.
Hum, cet article a provoqué pas mal de réaction sur ceux qui utilisent leur touchpad de manière "non-standard": soit c'est l'article soit libinput va faire grincer des dents pas mal de monde..
[^] # Re: Touffu de chez touffu
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 1.
Là je suis d'accord, une vue avec un axe des temps serait beaucoup plus lisible pour comprendre ce qui se passe.
Après c'est quand même super pénible/difficile de faire des bons graphiques..
# Une question
Posté par reno . En réponse au journal Bref j'ai créé une bibliothèque Rust et un moteur ibus (et je cherche comment les packager). Évalué à 5.
Pour moi, Rust c'est Ada++: un langage très strictement typé dont les types incluent même la durée de vie des variables, hors je vois que pas mal de gens tapent sur Ada car ils trouvent le compilateur 'trop strict', donc c'est comment Rust en pratique?
Pas trop dur de satisfaire le compilateur pour la gestion des 'durée de vie'?
[^] # Re: Touffu de chez touffu
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 3.
Ah? Je ne trouve pas moi.
Note que ce diagramme est une simplification de ce qui se passe en réalité: les compositeurs peuvent être empilé par exemple.
[^] # Re: triste
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 10.
Tout le monde devrait lire LWN :)
[^] # Re: triste
Posté par reno . En réponse à la dépêche Sortie de Wayland et Weston 1.6. Évalué à 10.
Encore?
Ça a été un sujet de discussion sur LWN, bien longue la discussion et finalement la raison pour laquelle ils ont fait ça est que xdg-shell est encore considéré comme étant expérimental donc casser la compatibilité sur un protocole expérimental n'implique pas de mettre à jour le numéro de version majeur du projet ce qui me parait normal: http://lwn.net/Articles/612653/