GeneralZod a écrit 2316 commentaires

C'est sûr que si t'as les sources ou la documentation technique, ça aide.
Ce que tu peux faire, c'est utiliser un sniffer usb pour tracer les trames, après selon la complexité du gadget, ça te prendra plus ou moins de temps. Snoopy Pro est pas trop mauvais mais il tourne sous Win-beurk
http://sourceforge.net/projects/usbsnoop/


Quelques ressources:
http://www.linux-usb.org/
http://www.lrr.in.tum.de/Par/arch/usb/usbdoc/

Il n'y a pas vraiment de méthodes génériques. Si tu as les sources, étudie-les, fais les tourner, modifie-les (notamment en rajoutants des logs). Si tu ne les as pas, établis des cas d'utilisations simples et trace les communications de façon à retrouver les spécifications. Si tes spécifications sont bonnes, au bout d'un moment, tu dois avoir un comportement déterministe.
Comme c'est de l'usb, tu pourras écrire un "brouillon" de pilote avec libusb, l'avantage c'est que c'est en espace utilisateur, ça te permettra de tester rapidement les choses sans faire planter ta machine. Ben oui, pas de débogueur en espace noyau !
Bien sûr, tu peux faire les choses en parrallèle, si tu as compris comment initialiser ton gadget, tu commencer à écrire ton pilote et continuer le sniffage à côté etc ...

http://libusb.sourceforge.net/doc/

> OSS 3.8 marche *nickel* avec FreeBSD .
FreeBSD n'utilise pas OSS, il n'a qu'une compatibilité OSS qu'au niveau de l'API.
$ man 4 pcm # sur une machine FreeBSD

> Au hasard : la GPL ?
T'oublie un truc mon coco, OSS est accompagné d'une tripotée de pilotes propriétaires. 4Front Technologies peut très bien fermer les prochaines versions et bye bye les pilotes propriétaires si on utilise pas leur version commerciale.

> C'est ce qui s'est passé pour OSS 3.8, mais des développeurs se sont amusé à faire "mieux" et incompatible .
Ils se sont pas amusés, OSS n'a pas bougé pendant plus de 10 ans du moins sa version libre ! Entre temps, le matériel évolue, le noyau aussi avec une meilleure prise en charge du matériel notamment etc ...
Quant à l'incompatibilité OSS4 l'est également avec OSS 3.8, d'ailleurs ils ont même reconnu qu'OSS 3.8 n'était qu'une merde sans avenir.

Il te faudra probablement une pile usb temps-réel
http://developer.berlios.de/projects/usb4rt

Je sais, Elie Semoun en crooner est aussi crédible que Serge Dassault en rat de l'Opéra.

> Camaro
> Elie Seimoun
> Gérard Darmon
> M Pokora
> Patrick Bruel
j'ai pas compris pourquoi des humoristes et un jouer de poker s'étaient incrustés dans la liste.

Je trouve ironique le fait qu'un personnage comme Jean-Philippe Smet qui s'est récemment enfui en Suisse pour ne plus payer ses impôts (dans un pays d'où provient la quasi-totalité de ses revenus) puisse demander après à l'Etat de traquer ceux qui téléchargerait illégalement ses "oeuvres".

Arrêtez de comparer RPM à APT, l'équivalent de RPM c'est DPKG.
apt-get est une surcouche à DPKG, il y a même un port RPM d'apt-get (apt4rpm).
L'équivalent de apt-get c'est yum, urpmi, ZYpp ou apt-get !


> Le DEB c'est LA référence en gestion des paquets
Que dalle, les formats dpkg et rpm se valent à peu de choses près.
Le problème comme tu l'as souligné c'est la multiplication des sources, d'un côté tu as plusieurs fournisseurs de paquets RPM pas forcément compatible entre eux et de l'autre une seule source: Debian. Le format de paquet n'a rien à voir.

D'ailleurs, ces derniers temps, chez Fedora la tendance est à la centralisation des dépôts donc le RPM Hell tends à disparaitre. par contre, la multiplication des dépôts chez Ubuntu est en train de générer le même problème.

> Pourquoi LSB n'a pas plutôt choisi le DEB ?
Parce que techniquement, les 2 formats se valent.

> Pourquoi les développeurs de Linux continuent d'utiliser ALSA alors que ça fait presque 1 an que OSS 4.0 est libre et meilleur (et maintenant il est même par défaut dans Draco) ? Pour emmerder FreeBSD

Mais oui, les développeurs de Linux n'ont que ça à foutre d'emmerder FreeBSD et de fournir une autre couche son pour te faire chier.
Si OSS a été abandonné, c'est à cause d'un changement de licence et qu'OSS 3.8 était moins bon qu'Alsa.
Ok, OSS 4 est libre depuis un an, mais qui garantit que les prochaines versions le seront après le précédent coup fourré de 4Front Technologies ?

> c'est même pas foutu de supporter l'émulation OSS dans dmix
T'es marrant, mais OSS est un merdier à émuler.
Alsa implémente le minimum au niveau noyau, le reste étant dans une bibliothèque sauf qu'OSS vient foutre le boxon et impose de réimplémenter les fonctionnalités de la bibliothèque dans l'espace noyau.

Comme toujours, tu as l'oeil mais ça a le mérite de pouvoir éclaircir les zones d'ombres.

C'est clair qu'il faut remercier l'ensemble de la communauté du logiciel libre pour cet incroyable cadeau mais sans se voiler la face, le gros du boulot a été fait par les ingénieurs de Sun et l'équipe d'IcedTea (et c'est un peu mon boulot d'ambassadeur de mettre en avant le boulot de la communauté Fedora dont IcedTea fait partie).

> Il me semble que c'est déjà disponible "en option" (preview) pour RHEL 5.2.
Exact, mais normalement OpenJDK deviendra l'implémentation par défaut dans RHEL 5.3, j'aurais du le préciser.

Quant à l'utilisation du nom "OpenJDK 7", seul Java 7 devait être entièrement libéré au départ, la libération du JDK 6 fait que rétroactivement on a appelé IcedTea openJDK 7 pour le différencier d'OpenJDK 6.
C'est probablement un abus de langage comme tu le précises, mais c'est repris par la communauté y compris dans les releases notes.
http://docs.fedoraproject.org/release-notes/f9/en_US/sn-Java(...)

Sun a accordé une licence spéciale du TCK pour la communauté afin de pouvoir tester la conformité des builds basé sur OpenJDK sous licence GPL.
C'est ce qu'affirme du moins la FAQ.
http://www.sun.com/software/opensource/java/faq.jsp#k4
OpenJDK devrait inclure une option de compilation permettant de valider la conformité du build, c'est peut-être même déjà fait.

Quant aux marques Java, JDK et OpenJDK, le premier n'est utilisable qu'avec l'accord de Sun, les JDK et OpenJDK sont soumis aux règles du "fair use".
L'accord RedHat-Sun permet à Fedora d'utiliser la marque "OpenJDK", c'est même dans les releases notes de Fedora 9: "Sun has licensed the OpenJDK trademark for use in Fedora."
Quant à Ubuntu, je suppose que c'est de même.


C'est vrai, il y a encore beaucoup de boulot, améliorer le plugin web, nettoyer le code pour le rendre plus portable, plus performant, etc ... C'est une étape importante pour faire de Java un citoyen de première zone dans la communauté du logiciel libre.
ça va redonner du courage à la communauté et donner du crédit au pro-libre au sein de Sun.

Je savais pas que le roi Henook était présent sur DLFP.

J'aimerais bien qu'on argumente sur la non pertinence du lien posté ci-dessus ?
Dag Wiers est une figure importante de la communauté RHEL/CentOS -je dirais même historique-, il maintient un des dépôts tiers les plus achalandés. La proposition de Mark Shuttleworth concernant RHEL et par ricochet CentOS, son avis sur la question n'est pas sans intérêt (après, je laisse le lecteur seul juge du contenu).

PS: Quant au titre, c'est une allusion au surnom de Dag (Field Commander).

> Shuttleworth a beaucoup fait pour le libre
beaucoup est de trop ...

> Est-ce les composants de crypto sont toujours fermés?
Non, depuis un bon moment déjà.
http://mail.openjdk.java.net/pipermail/security-dev/2007-Sep(...)

> Est-ce qu'on peut le compiler *sans* une version fermée de java (aka juste avec un compilateur C++)?

Oui, GCC/GCJ suffit à compiler OpenJDK, d'ailleurs, OpenJDK 6/IcedTea n'aurait jamais pu être distribué dans Fedora si ce n'était pas le cas.

> Est-ce que je peux télédéclarer mes revenus avec ce JDK sans me faire envoyer bouler par le site de la DGI (Direction Générale des Impôts)? (Sachant qu'un canal SSL est largement suffisant).

Il ne manque plus qu'un plugin web fonctionnel à 100% au lieu de 95%
Le TCK garantit quant à lui que le JDK/JRE est 100% conforme aux spécifications de Sun donc à ce niveau-là aucun souci.

> mouaif, elle se cache sous une couche "open source" mais elle est toujours là.
La java trap concernait l'environnement d'éxécution non libre, aujourd'hui ce n'est plus le cas.
Au passage, OpenJDK deviendra l'implémentation de référence dès Java 7 et remplacera définitivement l'implémentation propriétaire de Sun, c'est objectif de la release.

> Qui sont les fous qui vont maintenir la pile logicielle suivante pour une application java:
C'est le cas de la totalité des langages de haut niveau.
Je suis ingénieur en système embarqué et j'apprécie au moins tout autant que toi le C, mais il faut reconnaitre que Java et autres langages de haut niveau ont leur utilité.
De plus, la communauté libriste est largement capable de maintenir une pile logicielle comme Java, ce n'est pas les développeurs de Python, Mono, Perl, Ruby qui me contrediront.

Justement en pasant le TCK, OpenJDK6 devient une implémentation certifiée par SUN. La licence du TCK a été modifié spécialement pour OpenJDK
En revanche pour les impôts, reste le problème du plugin web, gcjwebplugin a encore quelques lacunes mais il est loin de ne pas être fonctionnel.

Sun a libéré le code dont il avait la propriété intellectuelle et a négocié avec ses partenaires pour qu'ils fassent de même. Mais il y a des réfractaires comme Kodak qui a refusé de libérer le code relatif à la gestion des fontes.

Le JDK inclut le JRE, la machine virtuelle Hotspot a été un des premiers composants libérés.
Au passage, ce n'est pas tant le classpath que les machines virtuelles qui faisaient défaut au logiciel libre.

http://dag.wieers.com/blog/ubuntus-need-to-catch-a-wave

Sinon, pour revenir au sujet du journal, je trouve l'analyse pertinente même si je ne suis pas d'accord sur certains points.

Pour la mesure de temps de précision, tu as:
* clock_gettime qui renvoit une structure timespec avec une granularité à la nanoseconde.
* times qui te permet de mesurer plus finement le temps cpu occupé par ton processus et les processus fils (système et utilisateur). Le seul bémol, c'est que c'est en nombre de tics d'horloges, donc il faudra récupérer le nombre de tics/seconde avec un appel sysconf(_SC_CLK_TCK)

Ce sera plus clair avec un exemple simplifié:
double clockticks, cticks;
clock_t tcstart, tcend;
struct tms tmstar, tmendt;

clockticks = (double) sysconf(_SC_CLK_TCK);
printf("Nombre de tics d'horloge par seconde: %f\n", clockticks);

tcstart = times(&tmstart)
ma_fonction_a_mesurer();
tcend = times(&tmend)

cticks = tmend.tms_utime + tmend.tms_stime - tmstart.tms_utime - tmstart.tms_stime;
printf("Temps CPU utile %f secondes\n", tcicks/clockticks);
Tu peux même calculer la fraction de temps CPU utilisé par ton programme: cticks/(tcend -tcstart)


Personnellement, j'utiliserais plutôt un outil de profilage (gprof) comme on te l'a conseillé ailleurs, si c'est pour améliorer les performances de ton soft.

L'url est pas passé: https://bugzilla.redhat.com/show_bug.cgi?id=446224

ça existe plus, ça. L'équivalent de /etc/gdm/custom.conf devrait ressembler à ça:

[xdmcp]
Enable=true

[security]
DisallowTCP=true


Mais il est fort probable que ça ne marche pas.

Chronologiquement, le gars il a été embauché sur .Mac et non pas MobileMe, donc c'est plus logique de mentionner .Mac.

Si tu veux inverser .Mac et MobileMe dans la phrase, il faut remplacer futur par ex.
On dit bien "Vivendi (ex Compagnie Générale des Eaux)" et non pas "Vivendi (future Compagnie Générale des Eaux)". Sinon, ça reviendrait à dire que futur == ex.

> C'est surtout ça que Fedora devrait mettre en avant.
C'est un des sujets sur lequel planche le groupe Marketing de FedoraProject.
Si tu vas sur la page d'accueil ou que tu discutes avec un ambassadeur, on met principalement en avant la philosophie du projet: éthique, collaborer en upstream, faire avancer les choses etc ... La pomme de discorde porte sur les annonces.
D'un côté, tu as les communicants à l'ancienne qui aiment les beaux listings bien bling bling, de l'autre côté des personnes (notamment David Nielsen) qui aimeraient plus axé la communication sur qu'apporte Fedora au libre et le travail accompli.

Tout le monde se fout d'avoir XServer 1.5 ou 1.4, le kernel 2.6.25 ou 2.6.24 que ce soit les simples utilisateurs ou les geeks mais de savoir qu'est ce que ça apporte concrètement.

Ta maman ne t'a jamais appris qu'il fallait finir tes "Brussels sprouts" ? ;-)

> Ormis ces version beta je n'ai rien vu chez Fedora qui soit en avance sur Mandriva.

Fedora n'inclut pas que des "bétas", le plus souvent, c'est un problème de synchronisation avec upstream. Ce sont des versions "stabilisés" qui ont connu un cycle de développement/tests de 6 mois.
Ce que tu vois dans Fedora, tu le retrouves généralement 6 mois ou 1 an plus tard dans d'autres distributions. C'est un peu gros de dire que Fedora n'est pas en avance sur Mandriva, ubuntu ou debian :o). Y a guère que Gentoo qui suive réellement le rythme.
Ce n'est pas une tare ni pour Fedora, ni pour Mandriva, les buts sont différents.
Fedora vise un public technophile voire proactif, Mandriva est plus orienté grand public. Comme disait le générique d'une série à succès dans les années 80: "il faut de tout pour faire un monde" !

> C'est Mobileme le futur .mac, et non pas l'inverse.
J'ai dit le contraire ?

Il me semble avoir dit pour bosser sur .Mac (futur mobileme). et non pas pour bosser sur .Mac (ex mobileme).
Il fallait comprendre ".Mac" dont le nom futur sera "MobileMe" mais je ne vois pas comment on peut se tromper.

1. qui développe SproutCore ?
SpoutCore a été créé par la société SproutIt. Par la suite, Apple a embauché un des fondateurs de SproutIt et principal développeur Charles Jolley pour bosser sur .Mac (futur mobileme).
Au final, Apple a décidé de sponsoriser le développement de SproutCore.

http://www.roughlydrafted.com/2008/06/14/cocoa-for-windows-f(...)

2. Sprout n'est pas une simple bibliothèque javascript ou un RoR-like mais un GWT-like qui permet de créer des applications javascript qui peut communiquer avec n'importe quel backend tant qu'il cause JSON.

http://www.sproutcore.com/2008/06/17/dispelling-some-confusi(...)

3. ça ne concurrence nullement Flash, Silverlight, XUL ou JavaFX.

4. . On a un peu trop rapidement présenté sur la toile SproutCore comme étant LA réponse d'Apple à Silverlight & cie alors qu'Apple ne fait que participer à un projet open-source. Après faut pas s'étonner si le site d'une petite PME croule sous la charge après s'être fait slashdotté