reno a écrit 3886 commentaires

Pour moi, le sms, avec toutes ses limitations, est une régression technologique du fax.

Bof, au moins le SMS il ne t'écorche pas l'oreille (à répétition) quand quelqu'un s'est trompé de numéro de téléphone..
Juste pour dire que chaque technologie à ses avantages et ses inconvénients..

Maintenant, il faudrait pouvoir utiliser une messagerie type mail ou irc sur le réseau 3G sans y laisser un bras à chaque émission.

Vu la taille d'un SMS, on pourrait utiliser un "pseudo-appel" téléphonique pour transporter le SMS, ça tiendrait aussi sur un réseau 2G et ce serait plus fiable mais plus cher..

Merde, tu veux dire qu'aujourd'hui, Xorg dessine la décoration de la fenêtre ?

J'ai écris ça moi? C'est facile de contredire des écrits imaginaires..

Optimus, ça fait 1 an et cinq mois de galère pour les linuxiens qui se sont trompés de matériel.

Il y a plein de fonctionnalités des cartes graphiques qui sont sous exploitées dans Linux a l'heure actuelle,
c'est surtout un manque de développeurs, X ou Wayland ça ne devrait pas changer grand chose de ce point de vue..

Pour Optimus, il y a un prototype PRIME pour X, mais vu le manque de développeur, AMHA il n'est pas près d'arriver en prod (enfin l'embauche recente par AMD de quelques developpeurs va peut-être aider).

Dave Airlie travaille à ce qu'une carte nvidia puisse écrire dans le scanout buffer d'un IGP intel.

Travaille, travaille, il a fait un proto ce qui est déjà très bien,
mais cela ne progressera que si quelqu'un d'autre continue le boulot..

Oh, Wayland sera nettement mieux, il me semble qu'ils s'orientent vers le choix de faire dessiner la décoration de la fenêtre par l'application (plus simple à gérer pour la composition), donc à moins que le toolkit gère de manière indépendante de l'application la décoration de la fenêtre, si l'application est figée alors tu ne peux plus redimensionner, fermer la fenêtre..
C'est un net progrès: ça se rapproche de comment Windows gère les fenêtres!!

J'ai déjà vu des critiques débiles sur X, mais celle de houra totalement non argumentée (ah si X c'est pareil que fdisk?????) mérite probablement le pompon (modérée à 10? incroyable).

Bref, ceux qui croient que Wayland sera le nirvana seront probablement bien déçu..

PS: Ce que j'écris sur Wayland est 100% véridique et correspond à ce que j'ai lu sur la mailing list du développement, cependant il me semble que la décision n'est pas encore faite.

Sous fedora, il n'y a je crois plus aucun binaire setuid root, que des capabilities.

Des "POSIX capabilities" pas des capabilities, ne pas confondre SVP.
Les capabilities c'est autre chose que Linux ne supporte pas actuellement,
malheureusement..

Eviv capsicum!

Je ne suis pas un expert en Wayland, mais je pense pouvoir te répondre.

Les pilotes des cartes graphique pour X sont-ils compatible pour Wayland?

Si le pilote fait partie du kernel Linux, je dirai que la réponse est très probablement oui (Wayland n'a besoin que d'une fonctionnalité assez simple dans le pilote de carte graphique: partager des buffers entre différent processus).

Quelle est la différence d'architecture qui permet de gérer le changement de GPU à chaud contrairement à X?

En théorie, Wayland n'est pas mieux adapté au changement de GPU à chaud que X.
En pratique, comme Wayland nécessite du nouveau code et que le changement de GPU à chaud est une nouvelle fonctionnalité hardware, il est possible que Wayland intègre cette fonctionnalité plus tôt que "X":
en fait le changement de GPU à chaud nécessite des changements d'X et aussi des toolkits, et c'est là le problème.

Problème que je peux l'illustrer par une histoire: la librairie initiale pour s'interfacer avec X, Xlib avait des gros problèmes de conception(*), XCB a donc été conçu pour remplacer Xlib, mais les toolkits n'ont pas été modifié pour utiliser XCB a la place de Xlib, grrr (une couche de compatibilité a été faite Xlib au dessus de XCB, mais je pense qu'on perd les gains apportés par XCB pour le multithreading).

*: et c'était des vrais problèmes, contrairement à plein de critiques d'X qui sont souvent très, très mal informées!

Non: windows n'a pas une API mais toute une flopée d'API,
c'est un succès commercial ok mais d'un point de vue 'responsiveness'(je ne sais pas trop
comment traduire ça en Français) il n'arrive pas a la cheville de BeOS (Linux non plus d'ailleurs).

Que je traduirais volontiers par : Un kernel, une plateforme, une API.

Note que dans certains cas (BeOS) ça peut donner des résultats vraiment bluffant..

Oui moi aussi à l'époque j'étais vraiment impressionné par BeOS par rapport à Windows ou Linux, mais je me demande si à l'heure actuelle acheter un SSD et un quadcore n'est pas un moyen plus rapide d'avoir un bureau réactif plutôt que d'attendre qu'Haiku soit prêt..

J'ai toujours du mal à comprendre le besoin de réécrire des choses de zéro au lieu de modifier celles qui existent déjà.

C'est sûr, mais si tu n'as jamais vu tourner BeOs...

Hum, j'ai utilisé BeOS mais je ne suis pas convaincu pour autant qu'il était nécessaire d'utiliser un obscur noyau avec très peu de support matériel plutôt que de se baser sur Linux ou FreeBSD pour recreer BeOS.

Je pense que la raison principale pour laquelle BeOS était très "rapide", c'est qu'ils ont écris des nouvelles applications utilisant "bien" le multi-threading, qu'ils ont conçus un système de fichier adapté au desktop, etc.
Tout cela étant portable sans trop de problème sur un noyau existant, mais bon le syndrome de réinvention de la roue est si séduisant..

Un bon exemple de tout ça est Android un OS très différent des distributions Linux classiques et pourtant basé sur Linux.
Il y a eu Blue Eyed OS une tentative de recréer BeOS sur Linux, mais ça n'est allé nulle part: c'était mal parti dés le départ avec des problèmes de choix de licence si ma mémoire est bonne et puis Haiku avait commencé avant et le nombre de développeurs ayant la motivation de recréer BeOS est assez limité..

La BSD donne totalement la liberté d'utilisation du code (tu peux en faire vraiment ce que tu veux y compris le "propriétariser", personne ne peut te demander quoi que ce soit), si tu veux vendre du hardware en restreignant la possibilité aux utilisateurs de changer le code qui tourne dessus par signature numérique (tivoïsation), la BSD et GPLv2 t'autorise à utiliser le code pour cette utilisation, pas la GPLv3.
Ce n'est donc pas étonnant que les BSD-iste "préfèrent" la GPLv2 à la GPLv3: elle est moins contraignante et elle est aussi beaucoup plus lisible..

et de toute façon si tu codes comme un pied en Ada, t'auras des "raised ADA.UNEERREURblablabla" à la place d'un "segfault"

Euh non justement quand il y a segfault c'est bien (un DOS est un trou de sécurité mineur AMHA), les vrais vulnérabilités c'est quand il n'y a pas de segfault alors qu'il devrait y en avoir un, et ça reste trop fréquent en C malheureusement..

Et concernant les débordements de tableau j'ai envie de te dire que t'as aller apprendre à coder correctement ;)

Mettre la tête dans le sable n’empêche pas les vulnérabilités de s'empiler, les programmeurs ne sont pas parfait..

La bonne nouvelle est que je n'ai pas de ventilo sur ma carte graphique :)

Moi non plus, mais bof car le ventilo de mon CPU est loin d'être silencieux quand il fait chaud..
Ce qui me rend perplexe d'ailleurs: comment fais-tu pour être déranger par le bruit de ton alim, tu utilise un refroidissement liquide pour le CPU?

Mais je me demande ce qu'ils pensent des capabilities et des langages qui ont des sémantiques plus "sécurisée" comme détecter les débordements entiers, de tableaux..

Probablement pas grand chose de bien car si je ne me trompe une majorité d'OpenBSD est codé en C, ce qui est curieux car dans un projet focalisé sur la sécurité j'aurais cru qu'il y aurait pas mal d'utilisateurs d'Ada, Joe-E..

Uhm, je considère que les BSD sont aussi du logiciel libre, mais je n'ai pas non plus envie d'appeler les distributions GNU/BSD/Linux,
donc si je veux parler des distributions qui partagent le noyau Linux, je parle des distributions Linux..
En plus ça n'écorche pas les oreilles.

Pas vraiment: tu considere vraiment que kFreeBSD or Hurd font partie des distributions "GNU/Linux"?
Pas moi.

Je suis 100% d'accord avec toi pour sur ton analyse. Appeler une distribution complète GNU/Linux n'apas de sens, pas plus que de l'appeler Linux.

Pas d'accord, autant la composante GNU est optionelle (il y a d'autres libc, d'autres compilo), autant Linux lui n'est pas optionnel,
tu peux même dire que c'est le seul point commun au distribution Linux.

Oh pas vraiment, tu peux faire plein de chose tout en n'avançant pas réellement:
regardes Nokia, ils ont commencé à tout baser sur GTK puis ensuite ils sont passé à Qt, et il y a plein d'autre exemples:
KDE qui donne l'impression de tout casser en permanence, Gnome avec son navigateur 'spatial', etc.

Hum, regarde leur annonce de sortie
Ca fait plutôt "c'est super, essayez" qu'autre chose..

Pour connaitre l'état réel de KDE4.0, il fallait aller voir les blogs des développeurs qui eux étaient plus réalistes.
Pas terrible comme communication car ce n'est pas cohérent.

D'ailleurs pour KDE4.1, l'annonce de sortie indique "While KDE 4.1 aims at being the first release suitable for early adopting users, some features you are used to in KDE 3.5 are not implemented yet.": le retour de baton a été méchant et ils préférent prévenir cette fois-ci..

Non, le satanisme c'est déjà pris par FreeBSD comme thème..

Dans la page de Wikipedia sur la programmation réactive,
il y a "Reactive programming has principal similarities with the Observer pattern" le pattern de l'observer étant justement celui du signal/slot de Qt..
Alors dire que ça n'a rien à voir..

Cette 15 me semble être une étape majeure pour le bureau linux.
-> quel que soit le choix du bureau (kde ou gnome) c'est un bureau stable et éprouvé.

Stable et éprouvé Gnome 3? Tu as bu quoi?
Ils viennent "juste" de faire des évolutions majeures..

Pareil pour Fedora avec Systemd qui est un gros changement..

Maintenant si tu veux de la stabilité, tu t'es trompé en choisissant Fedora: je te conseille RHEL.

Appeler la programmation évènementielle un hack franchement c'est osé!

Pour moi ce terme inclue aussi Estérel, FRP et bien d'autre chose intéressante.

Tout d'abord un grand merci à patrick_g qui fait encore une fois un boulot colossal.

Sur le GMA500, cependant, je trouve que le chapitre aurait pu être amélioré, il est marqué:
Le noyau 2.6.39 intègre pour la première fois dans sa branche -staging un pilote psb_gfx dédié à la puce graphique GMA500 (plus connue sous le nom de Poulsbo). Le pilote est développé directement par Alan Cox et, même s'il ne dispose pas encore de la 3D accélérée et n'utilise pas les moteurs vidéos matériels de la puce, le code gère le framebuffer ainsi que la 2D. Comme l'explique Kristoffer Ericson le pilote est stable et, si vous n'avez pas besoin de l'accélération 3D, il constitue une alternative tout à fait réaliste à l'ignoble blob binaire d'Imagination Technologies.

En fait, si ma mémoire est bonne Imagination Technologies avait demandé aux développeurs du noyau d'inclure un pilote pour le GMA500, ce pilote gérant la 2D mais délégant la 3D a du code propriétaire en userspace, ce qui a été refusé par les développeurs.
Alan Cox a donc décidé d'inclure (en la nettoyant) la partie 2D du pilote plutôt que de jeter la totalité du code.
Dire donc "même s'il ne dispose pas encore de la 3D accélérée et n'utilise pas les moteurs vidéos matériels de la puce" me parait potentiellement trompeur pour le lecteur qui ne connait pas l'historique: il pourrait s'attendre à ce que cela arrive bientôt, ce qui est loin d'être certain quand on sait comment le code 2D a été fait: par récupération, pas par ingénierie reverse..

tab de term ?
division du term (à la terminator)

Ça, ce sont des fonctionnalités qui devraient être apportées par le gestionnaire de fenêtres. Personnellement, un émulateur de terminal qui les implémente, je n'installe pas, c'est redondant.

Amusant comme point de vue: si pour des tab tu utilise le gestionnaire de fenêtres, en fait tu utilise plus de ressources qu'avec une application gérant elle-même les tabs, puisque tu dois lancer plusieurs instances complètes de la même application..