M a écrit 2988 commentaires

Commentaire de quelqu'un qui a participé activement à openmoko :

In the end, to what good is Linux in those devices? Definitely not to any benefit of the user. It's to the benefit of the handset maker, who can skip a pretty expensive Windows Mobile licensing fee. Oh and, yes, they get better memory management than on Symbian ;)

That's the brave new world. It makes me sick.

http://laforge.gnumonks.org/weblog/2008/10/23/#20081023-andr(...)

C'est une blague ? Il y a des archi avec linux sans glibc ?
Sans support officiel oui : ils ont virer arm des sources pour les mettre a coté [1]

[1] http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/ar(...)

Les onglets si j'ai bien compris. Mais avec un bon gestionnaire de fenêtre (ou avec screen) on a pas besoin d'onglet ;)

C'est un peu tard maintenant qu'il y a un driver libre.

Mais bon ca peut etre pratique si le driver libre ne supporte pas le dernier chip (et au passage ca peut permettre de comprendre comment les supporter).

Le chip ADSL est une sorte de DSP spécialisé, qui fait tourner un firmware qui, lui, est complètement proprio, mais surtout certifié pour fonctionner avec tel ou tel DSLAM, dans tel ou tel pays.

Pour les modem sagem usn j'avais même reussit a identifié le type de dsp utilisé et trouvé un desassembleur [1].


A la rigueur on peux comprendre que ces firmwares ne soient pas open-source, car, (un peu comme pour les cartes wifi), on pourrais les modifier et donc sortir des contraintes des certification.
C'est aussi que les constructeurs veulent garder leur algo secret : d'un vendeur a l'autre ils se demarquent avec le meilleur algo qui permet d'avoir le meilleur debit dans tout les cas de figure.
C'est un peu comme le wifi ou les algos d'ajustement du bitrate à la volé sont encore pas mal proprio.


[1]http://svn.gna.org/viewcvs/ueagleatm/trunk/firmware-utils/ad(...) et un gcc arc pour les dernier chip

Il s'agit d'un developeur sur système embarqué qui se plaint de la difficulté de savoir où trouver la dernière glibc.

glibc et embarqué ne font pas bon ménage (d'autant plus que la glibc ne supporte plus officiellement les archi embarqué tel que arm ou mips).

Il vaut mieux s'orienter vers eglibc ou encore uClibc (s'ils arrivent un jour a sortir leur nouvelle version avec le support de nptl).

En gros si YouTube adopte la balise video c'est bueno.
Sauf que youtube diffuse plus que de la video (c'est d'ailleur ce qui fait ramer le flash). Et oui leur lecteur affiche en superposition des trucs au début et a la fin de la video...

Bah, c'est parceque tu crois pas à la possibilité de succès des ultra portables sous un linux MIPS. Ils seront bien content d'avoir leur firefox qui lit le vorbis quand ils verront qu'y a pas de flash (quand tu vois le temps qu'il mettent pour faire une version amd64...).
Ben les processeurs mips savent autant lire du theora que du h264. Mais on me souffle a l'oreille que les optimisations multimédia mips sont quasi inexistante, car ce cpu est surtout utilisé dans les routeurs....

• • Librairies écrite en C++ au dessus du noyau :
Au dessus de la libc++/libc tu veux dire ?

Bionic une libc maison sous licence BSD: ils expliquent qu'ils ne veulent pas de GPL en user-space !!
La glibc n'est pas GPL mais lgpl...
Et bien évidemment des raisons de taille et de performances.
La uclibc convient tres bien pour la taille et aurait eu besoin de main d'oeuvre


Bref, un beau travail. On sent une grosse réflexion sur ce qu'est devenu Linux aujourd'hui.
Oui c'est un beau travail, bien qu'un peu fou (Quasiment tout redevelopper, ca veut dire qu'on a la main d'oeuvre, les compétences, pas peur d'essuyer des bugs ).
Mais maintenant la question pour le libre, c'est que ce que ca va devenir :
- d'autres projets vont réussir a récupérer des composants pour d'autres projets (comme la libc, la machine java) ?
- comment va s'effectuer la maintenance/bug report : ca ne concerne que la platforme android ou alors ils sont ouvert a d'autres utilisations
- Accepteront ils des patchs/extensions ?
[...]

C'est vrai Matthieu, il faudra que les fabricants de SSD acceptent que l'on puisse accéder directement à la mémoire (en RAW, je crois), plutôt que de passer par le firmware du bouzin.
C'est plus compliquer que ca : comment tu accedes a la memoire flash en RAW a travers des transport fait pour des disques dur : protocole ATA (pour les ssd), scsi (pour les clef usb), commandes sd-card ?

Cela devrait alors sérieusement augmenter les performances des SSD.
Pas sur : encore faut il savoir exploiter l'architecture des mémoire flash présente : sont-elle mises en //, ...

Si tu lis le lien du mon post au dessus :

SSD drives are probably very different to eMMC, MMC/SD etc. We have not worked with SSD drives. They are expensive and they probably have powerful CPUs inside, which run complex firmware which is probably getting things righ.

Theoretically, UBIFS may do better job, because it knows much more information about the files than FTL. For example, UBIFS knows about deleted files, while FTL does not, so FTL may do unneeded work trying to preserve the sectors belonging to deleted files. However, some FTL devices support "discard" requests and may benefit from the file-system hints about unused sectors. Nevertheless, in general, UBIFS should do better job on a bare NAND, than a traditional FS on an FTL device with a similar NAND chip. On the other hand, FTL devices may include multiple NAND chips, highly parallelise things and provide fast I/O. Probably SSD is a good example. But this may affect the cost.


Ce qui m'inquiéte plus les ssd c'est la robustesse, pas les perfs. La gestion des NAND (et notament de MLC) est super complexe. En effet c'est de la flash pas chére qui arrive a avoir des capacité correcte, mais c'est de la merde : tu peux avoir des zones foireuses (bad block), avoir des zones qui deviennent mauvaises au cours de la lecture (bit flit), avoir des zones qui deviennent mauvaises après un certains nombre de cycle d'effacement, une granuralité d'effacement/écriture qui n'est pas forcement pratique, ....

Sans compter qu'a mon boulot, on a utilisé des Nand avec ftl embarqué, et on a eu plein de soucis de corruption (voir meme de destruction).

Je n'ai malheureusement pas l'impression que Btrfs utilise la bibliothèque UBI, maintenant intégrée au kernel et sur laquelle UBIFS est basée.

UBI c'est pour des flash raw, ce qui n'est pas le cas des disques ssd.

Sauf que tu peux pas dialoguer directement avec la flash sans passer par le micro controlleur avec les ssd, sd-card, clef usb, ...

Et a propos d'ubifs : http://www.linux-mtd.infradead.org/doc/ubifs.html#L_raw_vs_f(...)

Y a pas que le NAT, mais tout simplement l'administrateur réseau qui adopte une politique on ne laisse passer que ce qui est nécessaire.

Et le SIP avec ces divers ports n'aide pas.

Pour ekiga, même une conversation à deux peut être effectué sur une conf'-call qui est un n° comme sip:5012008@ekiga.net (une salle de conférence, gratuite, il suffit de l'indiquer à tes correspondants au préalable).
C'est pas tres user-friedly...
Ce que mr tout le monde veut (et que skype offre) c'est une solution clef en main.
J'installe le truc, je rentre 2 ou 3 information. Je clique sur 2 ou 3 boutons et c'est parti.


Avec ekiga 3, tu peux utiliser freephonie (le bug chez free est contourné si j'ai bien compris), cela te permet d'appeler de n'importe où tu as du wifi (ou du wire-full aussi) comme si tu étais chez. toi avec ton combiné téléphonique, c'est déjà pas mal comme passerelle (bon avec la contrainte d'être chez free, neuf a peut-être le même genre d'offre il me semble, pour orange je ne sais pas).
Sauf que free bride les connections : on peut appeler que les n° gratuit...


Tout ça rejoind parfaitement le post suivant : https://linuxfr.org/comments/973017.html#973017 . La technologie c'est bien, mais l'utilisateur il s'en fout. Lui ce qu'il voit c'est l'exterieur (interface, qualité, facilité d'utilisation, ....)



PS : d'ailleurs il me semble que SIP n'est pas chiffré pour le moment. Sympa sur le réseau wifi ouvert...

Un service SIP public, tu peux en monter un, comme un service Jabber ou web ou e-mail, par exemple.
Super je vais dire a ma grand mère qu'il faut quel installe sont propre serveur parce qu'elle a un firewall pourri. Ha oui il faut prendre aussi un hébergement dedié pour mettre le serveur.
Vraiment tres user-friedly....


Sur un service SIP public, tu n'es pas obligé du tout de relier tes users aux réseaux télécom publics que sont les GSM ou RTC : tu peux rester sur internet.
Cool, je dois joindre quelqu'un a l'etranger qui n'a pas internet mais un telephonne fixe. Et ben ca marche pas....


Alors qu'en utilisant skype, ca semble beaucoup plus simple non ?

Un pas de plus vers la priorité numéro 3 de la FSF, le remplacement de l'ultra-propriétaire Skype.
Sauf qu'il font tous du SIP qui pose des pbs avec les pare-feu.

A ma connaissance aucun n'a mis en place des "proxy" sip gratuit, pour faire relai dans le cas ou les connections entrantes/sortantes sont bloqués.

Aucun logiciel n'a tenté de faire comme Skype une architecture p2p.

Peu de logiciel SIP sont associés avec des passerelles vers le réseau téléphonique.

On a déjà suffisamment de logiciels propriétaires chiants dans le monde du libre (flash, pilotes nvidia, ...) et dont on se bat depuis des siècles pour les libriser (ou les éradiquer à jamais, comme flash), alors en voir de nouveaux débarquer... sans façon, merci.

Oui mais bon, les logiciels libres ne couvrent pas toutes les demandes et je me sent pas tout développer moi même.

Je pense par exemple a tout les cd éducatif et documentaire qui sont dispo a ma bibliothèque. Oui il pourrait être implémenté sous forme de logiciel libre (modulo les data), mais bon ca serait deja un grand pas qu'il y ai une version Linux, au lieu de devoir passer par un windows...

Et puis les freewares, sharewares, spywares, crapware ca existe deja sous Linux. D'autant plus que ce n'est pas incompatible avec le libre :
- xchat avait un portage win32 sous forme de sharewares
- des clients bitorrent comme bittornado avait une version sur des sites comme download.com légèrement modifié. En plus aujourd'hui c'est la mode des tutoriaux qui ajoute des repositories dans les "packages manageurs", pour avoir la dernière version a jour ou un truc pas packager. Rien de plus facile d'ajouter dans ces repositories quelques bonnus

Sous debian, tu peux utiliser
$debtags search game::board
$debtags search game::card
[...]
$debtags search game::*

pour en avoir certains...

Ha c'est un truc php, moi je croyais que c'était le shell http://packages.debian.org/fr/sid/posh

A noter qu'e17 est disponible dans les paquets debian experimental [1]. Sympa pour faire un test rapide sans compilation.


[1] par exemple deb http://ftp.fr.debian.org/debian ../project/experimental main contrib non-fre
e

mais ffmpeg ne permet pas de le lire sans passer par des codecs binaires
Non, le codec audio (wma9) n'est pas supporté

Ça écrase l'EEPROM, et si tu n'as pas de sauvegarde c'est très difficile à rétablir (et si le rétablissement foire, la carte n'est même plus visible sur le bus PCI d'après certaines personnes qui commentent sur le bug).
Oui, mais il y a souvent des moyen de les récuperer en by passant les stack pci des os et en utilisant des outils du constructeur.


Le problème c'est que ces données ne dépendent pas que du périphérique mais de tout le matos (le BIOS, etc), du coup Intel ne peut pas fournir une sauvegarde qui marcherait pour tout le monde (d'ailleurs leur conseil est pour les personnes possédant une carte concernée de sauvegarder tout de suite le contenu de l'EEPROM).

Bon après il suffit de prendre une copie d'une eeprom de quelqu'un qui a une config similaire a toi et eventuel de modifier un peu le contenu si le format est connu.

PS : t'es sur que l'eeprom de la carte réseau et le BIOS sont liée ?

Pareil ...

Hum, j'ai 2 Go de mémoire. Un boot en cinq secondes voudrait dire que le disque dur lit à une vitesse de 400 Mo/sec.
Oui mais tu sauve pas forcement toute la ram (par exemple du peux jetter tout les cache temporaires des disques) et puis un compression est appliquée (ce qui compresse pas mal les zones ou les données sont constantes).
On pourrait aussi imaginé une sorte de prefetch qui sauve certains bout de la ram qui sont peu modifié quand le kernel n'a rien a faire.

Suspend-to-ram est quand même plus pratique.
Oui, mais s'il y a une coupure de courant ou que tu n'as pu de batterie tu perds tes données, ca consomme, et c'est encore plus chiant a faire marcher que le suspend to disk. Le suspend to ram a besoin de acpi pour s'endormir, ce réveiller. En suspend to disk il suffit "juste" d'avoir des drivers qui sache sauver/restorer l'état des périphériques.

Non l'eeprom ne contient pas un firmware mais des paramètres de la carte (adresse MAC, constructeur, id a présenté sur le bus usb, ...)

Et du coup si certains de ces paramètres sont foireux la carte n'est plus fonctionnelle, jusqu'a qu'on ai remis dans l'eeprom des valeur correcte (souvent avec un logiciel du constructeur).

Ca met déja arriver plusieurs fois : sous windows sur une carte TV et un driver foireux (j'ai pu la réparer grace a linux qui exportait l'eeprom)
sous linux avec une carte réseau 3c905C et AIRONET (la réparation c'est fait en utilisant des logiciel du constructeur (DOS/windows)).