blubliblo a écrit 71 commentaires

En effet, elle se fait étape par étape. On devrait avoir tout modulo la gestion d'énergie (horloges,tension d'alimentation,sonde thermique, contrôleur du ventilateur). En effet, cette gestion aurait été déléguée à des contrôleurs I2C pour les pré-r7xx dont les constructeurs ne voudraient pas qu'on publie leur manuel de programmation... m'a-t-on dit sur la channel #radeon du serveur IRC freenode. Sur les r7xx et plus, cela serait maintenant fait entièrement via le fameux ATOM bios.
Quelqu'un aurait mis du code reverse engineeré pour ça dans un des drivers pour radeon.
Dans tous les cas, le manuel de programmation 3D a été publié il y a juste quelques petits mois, et pourtant la 3D arriverait à grand pas (troll:glxgear marcherait).
Dans tout ça, on ne parle pas beaucoup de la nouvelle API d'accélération de décodage vidéo de xorg VAAPI qui saurait profiter du silicium que les GPUs embarques pour cette tâche. Et là, toujours pas de manuel et référence.

... en effet la "licence" est basée sur ces horribles "brevets logiciels", non valides en Europe. Donc cela ne nous concerne pas. Par contre pour les pays barbares où ces ignominies ont été démocratiquement adoptée, bin... doh!

Bin j'ai un 2.6.30 mais j'ai pas tun de monté... en fait même pas compilé.
D'ailleurs pour le monter, il faut un programme SUID root genre pulseaudio (d'ailleurs à quand un mixer en C pour lui, qui ne descent pas tout gnome?)
Et puis il faut rappeler qu'aucun système n'est sûr. Certains sont justes de notoriété plus sûrs, c tout. Donc à partir de là autant privilégier des systèmes (A)GPL pour favoriser la publication de code correctifs de failles.

Moué... dans le traité de Lisbonne y a certainement pas mal de cadeaux bonux indésirables sous couvert de jolies choses.

Pour la communauté GPLienne, je tiens à mettre en lumière gnutls, alternative à openssl.

Rien de plus

Je me demande quelle libc ils vont utiliser... et surtout si on aura pour sûr tout le code.
Il faut voir aussi comment ça se passe au niveau dev communautaire, j'espère qu'il ne faudra pas "partager" ses droits GPL avec Google pour qu'une version fermée nous arrive dans la tronche.
Bref... une annonce qui amène un sacré paquet de questions.

Si je me souviens bien, LDLC tourne sous des technologies non libres. D'ailleurs depuis, je conseille systématiquement des concurrents qui ont un retour "positif" avec nmap ou autre...
Si cette boutique est toujours du côté sombre de la technologie (et c'est le cas de le dire... mouarf!) c'est quand même gonflé de venir sur linuxfr... et cela même caché derrière des normes.

Oué... je m'achète un GPU d'AMD, je me refous sur le support des GPUs et je vais essayer de faire des dépêches de la même qualité sur le sujet.

... moi aussi je veux faire des dépêches comme celle-là!

J'ai bien mes typematrix et mes skins BÉPO, mais pour ma part, j'ai choisi d'aller vers le dvorak... car je tape plus d'anglais, de code et de shell qu'autre chose.
Pourtant, le dvorak semble déjà une amélioration pour la frappe du français. Alors qu'est-ce ça doit être avec le BÉPO!

Je n'ai toujours pas mis à plat comment j'allais gérer les accents sur le clavier dvorak. Probablement avec des touches mortes. Un collègue m'a mis en garde d'avoir les touches mortes directement accessibles car c'est très pénible. Je vais voir ce que je peux tirer de xkb de notre cher x11...

Le bon côté des choses: ça vient beaucoup plus vite que je n'aurais cru.

Les choses amusantes: je constate que j'ai plusieurs modes pour taper sur le clavier. Un mode dactylo, et un mode plus intuitif, plus aérien mais qui m'oblige à jeter un œil de temps en temps sur le clavier. Par contre, il faut que je me force à commuter mentalement d'un mode à l'autre. Ça fait particulièrement bizarre quand je reviens sur mon clavier azerty au boulot, qu'on peut considérer comme un troisième mode.

Personnellement je ne donne pas cher d'une liberte qui ne se defend pas... c un peu pourquoi je favorise la GPL aux autres licences.

Il me semblait que l'UI etait completement separee du modeleur pour le 2.50?
Sur le principe de MPD. En gros un processus pour le modeleur sur lequel on vient connecter/deconnecter des UIs.

Support d'autres formats/codecs dans la prochaine version, plutôt dés que l'utilisation de gstreamer est intégrée dans firefox.

L'implémentation de référence de Dirac est effectivement très gourmande.
Il faut regarder du côté de l'implémentation "schrodinger" qui est supposée nettement plus rapide.
Attention, dans l'absolu, dirac reste très gourmand de toutes les façons.

Hu?
Pour les codecs non cablés en dur dans firefox, y a pas une bascule faite sur les codecs (container/video/audio) supportés par gstreamer?

Normalement, si tu as gstreamer, ton firefox va pouvoir utiliser l'ensemble des codecs installés sur ta machine...
Simplement ogg/theora/vorbis, c'est cablé en dur dans firefox.

Raaaah!
Ça s'est de la bonne nouvelle!!!
Ça va pousser youtube aux fesses et nous permettre de donner de l'eau à notre moulin fasse aux site "video sur le web=flash".
C'est décidé je switch entièrement sur dailymotion!
:D

Le vrai gros avantage de la eglibc par rapport à glibc la dernière fois que j'ai regardé, c'était surtout qu'il était beaucoup plus facile de compiler une cross-toolchain. Les inter-dépendances entre la gcc et la glibc sont un vrai cauchemar pour mettre en œuvre une cross-toolchain (le plus facile étant les GNU binutils).
En effet, la compilation native n'est qu'un cas particulier de la compilation croisée (passons les trolls sur la compilation canadienne), pourtant énormément de paquets de sources logiciels sont codés en dur, ou de vrais cauchemars, pour la compilation croisée. C'est pour cela qu'il est bon de se forcer un peu au début d'un projet de bien utiliser les GNU autotools qui donne accès à un framework de compilation croisée pour gratuit.
U.D. est difficile, mais les derniers choix qu'il a fait (nouveau cycle de release, passage à git) et ses compétences (voir son papier sur le fait que la RAM est lente et que pour de la vraie performance il fallait gérer la mémoire cache) compensent largement le fait qu'il hurle à la mort à chaque fois qu'un patch casse la compatibilité avec le HURD (véridique).
Accessoirement, il fait parti des gens qui font POSIX...
trollS:
- automake en C... mon rêve.
- eglibc passe à git, ça c'est une bonne idée
- Je rêve d'une GNU/Linux gentoo où portage est en C et surtout pensé dés le départ pour de la compilation/déploiement croisé car pour le moment, cette fonctionnalité est monkey patché progressivement dans portage et... bof bof.

Il y a effectivement le pb de la tentation d'utiliser un maximum toutes les fonctionnalités du C++... ce fameux syndrôme qui amène vite les programmes C++ à l'usine à gaz.

L'autre aspect, que même une hygiène de code drastique en C++ ne peut éviter, est le "cout logiciel" du C++ en lui-même. Voir:
- front-end C++ de GCC
- libstdc++
- ABI C++

En général, avec des listes chaînées, j'essaye (ça veut dire pas tout le temps) d'utiliser celles de Linux qui utilisent l'extension gnu qui consiste à trouver le pointeur du début d'une structure à partir du pointeur d'un des membres. En effet, le savoir du layout mémoire d'une structure est connu du compilateur (alignement, padding etc etc...), sauf si il est utilisé l'extension "packing de structure" où là il est possible de tout calculer sans le compilo, mais attention aux pertes de performances à cause des pbs d'alignement en mémoire (Ulrich Drepper, codeur de la libc et membre de POSIX, a fait des tests y a pas si longtemps, et à titre d'exemple le performance hit était de grosso modo 4x pour des structures pas correctement alignées).
J'ai utilisé directement le header de linux avec les 2-3 modifs qui vont bien pour qu'elles marchent en user space. Bon... c'est pas les listes protéger par RCU... ça serait trop beau.

C'est une question de compromis entre ce que ça apporte, et son "cout logiciel" (taille/complexité/qualité).
Perso (et je ne suis pas le seul), le C++ n'est pas un bon compromis.

Sur ce coup là, si ce gars n'y arrive pas avec les specs alors que d'autres y arrivent sans specs et à coup de reverse engineering... je ne vais pas jeter la pierre à Novell...

Et la complexité d'implémentation?

Maintenant il faut que mono ne soit plus installé par défaut dans les distros les plus populaires...