L'objectif premier est de pouvoir compiler tout le système de base d'OpenBSD, ce changement ne concerne donc pas l'intégralité des ports mais seulement ceux du système de base, et ceci bien sûr pour toutes les architectures gérées par OpenBSD. Ce qui veut dire qu'il faut que ce compilateur :
Si l'objectif est de compiler le système de base, alors pourquoi s'embêter a ajouter une compatibilité gcc [1]. Je pense pas que le code de base soit du code GNU venant de Linux...
Surtout que ca va pas trop dans le sens de la simplicité.
[1]
Amélioration de la compatibilité avec GCC
Le compilateur GCC a introduit des extensions au langage C qui sont utilisées parfois dans certains programmes. Afin que ces programmes puissent être compilés sans modifications, une partie des ces extensions doit être mise en œuvre dans PCC
Pour fournir des binaires de qualité, OpenBSD décide de compiler les sources directement sur une machine de l'architecture cible (pas de cross-compilation).
Heu peux tu me citer les différences au niveau du binaire entre celui qui a été cross compiler et celui qui a été compiler nativement par la même version du compilo ?
e rêve où tu fais exprès de volontairement couper la réponse de ragge qui contient les vrais chiffres ?
oui, je parle du bench des 10% plus lent que gcc.
Celui avec gcc-3.3.5 (qui au passage n'est pas très récent non plus....) a plus de 10 % d'écart.
PS : je ne parle même pas du fait que -O2 est utilisé au lieu de -O3.
Je rêve ou on se fout de nous :
> Under which conditions? Which level of optimization are you using for the gcc benchmarks? Which version? 90% of gcc's performance with a register allocator alone is quite a claim.
Yes, it is. I haven't tested it since I wrote the register allocator some years ago, so it may have been against 2.95.
Comment ça peut fonctionner ?
On peut imaginer un truc avec WPA-EAP et une sorte d'echange de clef unique par client avec le radius.
PS : même si les différents clients utilisent des clefs différentes avec le WPA pour crypter le traffic, ca ne veut pas dire qu'on ne peut pas accéder au trafique : ces clefs dérivent d'une master key. Si tu la connais en analysant les échanges lors de l'authentification, tu peux trouver les clefs qui serve a crypter le trafic. D'ailleurs je crois que wireshark sait le faire.
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 ;)
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.
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).
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
[^] # Re: propriétaire ?
Posté par M . En réponse à la dépêche Sortie de Theora 1.0. Évalué à 3.
PS : http://wiki.multimedia.cx/ a souvent les liens vers les specs...
[^] # Re: Besoins d'OpenBSD
Posté par M . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à -1.
Si l'objectif est de compiler le système de base, alors pourquoi s'embêter a ajouter une compatibilité gcc [1]. Je pense pas que le code de base soit du code GNU venant de Linux...
Surtout que ca va pas trop dans le sens de la simplicité.
[1]
Amélioration de la compatibilité avec GCC
Le compilateur GCC a introduit des extensions au langage C qui sont utilisées parfois dans certains programmes. Afin que ces programmes puissent être compilés sans modifications, une partie des ces extensions doit être mise en œuvre dans PCC
[^] # Re: Besoins d'OpenBSD
Posté par M . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 3.
Heu peux tu me citer les différences au niveau du binaire entre celui qui a été cross compiler et celui qui a été compiler nativement par la même version du compilo ?
[^] # Re: Alternative ?
Posté par M . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 2.
oui, je parle du bench des 10% plus lent que gcc.
Celui avec gcc-3.3.5 (qui au passage n'est pas très récent non plus....) a plus de 10 % d'écart.
PS : je ne parle même pas du fait que -O2 est utilisé au lieu de -O3.
[^] # Re: Alternative ?
Posté par M . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 2.
> Under which conditions? Which level of optimization are you using for the gcc benchmarks? Which version? 90% of gcc's performance with a register allocator alone is quite a claim.
Yes, it is. I haven't tested it since I wrote the register allocator some years ago, so it may have been against 2.95.
[^] # Re: wifi ouvert
Posté par M . En réponse au journal De l'intérêt d'avoir un wifi ouvert. Évalué à 3.
On peut imaginer un truc avec WPA-EAP et une sorte d'echange de clef unique par client avec le radius.
PS : même si les différents clients utilisent des clefs différentes avec le WPA pour crypter le traffic, ca ne veut pas dire qu'on ne peut pas accéder au trafique : ces clefs dérivent d'une master key. Si tu la connais en analysant les échanges lors de l'authentification, tu peux trouver les clefs qui serve a crypter le trafic. D'ailleurs je crois que wireshark sait le faire.
[^] # Re: Battered, but not broken: understanding the WPA crack
Posté par M . En réponse au journal De l'intérêt d'avoir un wifi ouvert. Évalué à 2.
[^] # Re: Battered, but not broken: understanding the WPA crack
Posté par M . En réponse au journal De l'intérêt d'avoir un wifi ouvert. Évalué à 2.
Oui si tu met un mot de passe faible (je peux faire la même chose avec ssh)...
# ...
Posté par M . En réponse au journal Le deuxième téléphone portable sous Android pourrait être .... Évalué à 2.
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(...)
[^] # Re: embarqué
Posté par M . En réponse au journal glibc m'a tuer. Évalué à 3.
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(...)
[^] # Re: M vs U
Posté par M . En réponse au journal Alpha test de mrxvt avec support tout-encodage. Évalué à 5.
[^] # Re: Drivers broacom
Posté par M . En réponse à la dépêche Gestion des puces Broadcom 63xx dans OpenWrt. Évalué à 2.
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).
[^] # Re: C'est super positif...
Posté par M . En réponse à la dépêche Gestion des puces Broadcom 63xx dans OpenWrt. Évalué à 3.
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
# embarqué
Posté par M . En réponse au journal glibc m'a tuer. Évalué à 5.
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).
[^] # Re: bisounours
Posté par M . En réponse au journal Firefox 3.1et le support natif de Theroa/Vorbis. Évalué à 2.
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...
[^] # Re: bisounours
Posté par M . En réponse au journal Firefox 3.1et le support natif de Theroa/Vorbis. Évalué à 2.
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....
[^] # Re: En bref
Posté par M . En réponse au journal Sources d'android disponibles.. Évalué à 6.
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 ?
[...]
[^] # Re: File systems et supports physiques
Posté par M . En réponse au journal Ext4 va sortir !!!. Évalué à 3.
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).
[^] # Re: File systems et supports physiques
Posté par M . En réponse au journal Ext4 va sortir !!!. Évalué à 3.
UBI c'est pour des flash raw, ce qui n'est pas le cas des disques ssd.
[^] # Re: File systems et supports physiques
Posté par M . En réponse au journal Ext4 va sortir !!!. Évalué à 4.
Et a propos d'ubifs : http://www.linux-mtd.infradead.org/doc/ubifs.html#L_raw_vs_f(...)
[^] # Re: Un petit pas alors...
Posté par M . En réponse à la dépêche Le Linphone nouveau est arrivé, en version 3.0.0. Évalué à 2.
Et le SIP avec ces divers ports n'aide pas.
[^] # Re: ...
Posté par M . En réponse à la dépêche Le Linphone nouveau est arrivé, en version 3.0.0. Évalué à 3.
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...
[^] # Re: ...
Posté par M . En réponse à la dépêche Le Linphone nouveau est arrivé, en version 3.0.0. Évalué à 0.
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 ?
# ...
Posté par M . En réponse à la dépêche Le Linphone nouveau est arrivé, en version 3.0.0. Évalué à 10.
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.
[^] # Re: concurrence
Posté par M . En réponse à la dépêche PowerDVD & PowerDVD Cinema bientôt disponible sous GNU/Linux. Évalué à 3.
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