David a écrit 58 commentaires

readelf ou objdump pour analyser le contenu d'un programme compilé.

Vous savez qu'il est extrêmement facile pour un opérateur de capturer le traffic d'un abonné ? Que ce soit ADSL, fibre ou même 4G ? Donc si vous pensez que la loi ne sera pas suivi d'effet, vous vivez dans un monde de Bisounours.

Faite comme moi, mettez votre pc à la cave (mon bureau est au sous-sol ;)). Pas de soucis de lumière parasite!

PS:

Pour les imprimantes HP, je regarde ICI:
http://hplipopensource.com/hplip-web/models/color_laserjet/h(...)

Je ne suis pas d'accord avec l'aspect sans fin du débat.

Si le driver n'est pas maintenu depuis 2 ans, c'est un autre pb. Le kernel évolue et heureusement. Les drivers qui sont fournis avec, évolues avec lui. Pas de pb de compatibilité avec les drivers intégrés au sources du kernel.

De plus, l'api V4L2 existe depuis des années, mais les devs de drivers externes au kernel et d'applications "trainent les pieds". Perso, j'ai choisit une webcam qui utilise le driver UVCVIDEO, avant que celui-ci soit intégré au source du kernel. Et ça m'a aussi posé plein de pb, mais c'était l'avenir. Aujourd'hui ma webcam fonctionne avec toutes les applis (V4L2).

En tout cas, l'avantage des sources ouvertes, Seven ne l'aura jamais. Et mon scanner ne marchera jamais plus sous windows. Alors que ta webcam, elle pourrait bien re-fonctionner sous linux. C'est juste une question de temps.

A+

Bah si justement, je trouve ça simple. Si c'est utilisable au moment de l'achat dans TES conditions, alors c'est bon. Tu as fait en fonction de tes besoins et du support que tu trouvais sur les différents modèles.

Effectivement, c'est encore loin d'être parfait actuellement, mais ma comparaison concernait plus les cadors (HP, Canon et Epson) du marché sur le segment des jets d'encre, et ça, il y a plus de 3 ans! A cette époque, aucun constructeurs ne parlait de Linux, sauf HP.

Le pb, c'est ceux qui savent qu'ils vont utiliser un Linux et qui achêtent malgré tout un périphérique clairement non supporté.

Quand on a pas le choix du matos, alors là c'est le vrai pb.

Le cas des imprimantes est très représentatif de l'état d'esprit des fabricants.

D'un coté, il y a HP, qui fournit les docs et participe activement au développement des drivers pour Linux. Ça nous donne HPLIP et autre projets qui permettent d'utiliser pleinement leurs imprimantes et autres multifonctions.

De l'autre, il y a Espon et Canon, qui n'ont rien à faire de Linux. Alors la qualité d'impression est bonne mais UNIQUEMENT sous Windows. Question drivers pour Linux, c'est la cata!

Pour moi, le choix à été très rapidement fait, j'ai pris une HP (Photosmart). Et je n'ai jamais eu de soucis, ni d'impression, ni d'accès au lecteur de cartes mémoires, etc.

Pour la webcam, j'en ai pris une compatible avec la norme UVC. Et pas (trop) de soucis. Je suis juste tombé sur une série buggé, mais ça change en rien mon choix. Je referais le même quand j'en changerais.

J'estime qu'aujourd'hui il y a suffisamment de sources d'information pour choisir du matériel pour ne pas aller s'emmerder avec du matos non supporté, et ensuite se plaindre que son imprimante ne fonctionne pas sous Linux.

Linux a des défauts, je le conçois, mais faut pas abuser non plus. Soyez plus sélectif dans vos choix et vous n'aurez pas de pb.

Cordialement,
David

Juste pour relativiser un peu ton expérience, voici la mienne.

Pour scanner un document avec mon AGFA Snapscan pleinement fonctionnel sur mon ancien pc (sous XP et Linux):

- brancher le scanner USB sur mon portable tout neuf sous VISTA (parce que mon pc de bureau etait indisponible, hélas)
- mettre le CD de driver fourni == impossible, le driver XP n'est plus compatible avec Vista.
- cherche un driver pour mon scanner pour vista == introuvable, AGFA ne maintient pas.
- temps perdu 1h

Alors:

- Rebooter sur Ubuntu (j'aurais du commencer par ça, étourdi que je suis)
- Brancher le scanner == reconnu immédiatement
- Lancer XSane et
- Scanner....

C'est pour ça que je reste sous Linux maintenant. J'ai pas besoin de racheter des périphériques qui fonctionne, juste parce que Microsoft à décider de tout changer.

Avec Microsoft, il n'y a aucune pérennité du matériel. C'est au bon vouloir de MS et des fabricants.

Avec Linux, j'ai le code source, je fait ce que je veux.

A+
David

PS: Installer un Netbook récent avec une Debian, je trouve ça suicidaire. Comment s'attendre à ce que tous les drivers soient présents avec un Kernel qui date de plus d'un an!

Full linux pour moi, enfin 99.999% de mon temps.

Au boulot, un PC avec Core i7 920 sour ubuntu et des serveurs de tests avec 2 Xeon X5550 (un puissance de calcul de folie, dommage que les disques soient si lent!) sous debian

A la maison, un serveur mail/web/... sous gentoo (car il sert aussi de machine de dev, lol), un pc sous gentoo exclusivement, un portable sous ubuntu (et un partoche Vista, pour mme, juste au cas ou).

Ailleurs, un HTC Hero sous android!

Comme indiqué dans le titre, il me reste juste une petite install de windows 7 béta sous Kvm que je ne lance quasiment jamais.

J'espère aussi, j'avais l'intention de changer d'opérateur.

Les webcams "UVC" sont depuis pas mal de temps très bien supportées. J'utilise depuis très longtemps ce driver pour mes 2 webcams. Le seul problème, c'est les applications qui continuent d'utiliser l'API V4L1 qui est dépréciée depuis TRES longtemps.

Contacter les devs de camorama et demander leur le portage sur V4L2, ou bien, portez-le.

Depuis pas mal de temps déjà, Ekiga, GStreamer, aMsn, et bien d'autres supporte les API V4L2. Il ne faut pas incriminer le matériel, quand c'est un problème d'application (obsolète).

Pas forcement le plus abordable, exact, mais permet de facilement faire de belles choses après une rapide prise en main (1 à 2jours).

Après le montage complet des chapitres avec Cinelerra, je crée les vignettes en utilisant les vidéos générées.

Pour un menu de chapitrage avec 2 vignettes en 16/9:
# ffmpeg -i chap1.vob -vcodec mjpeg -qscale 1 -an -t 10 -s 320x256 -aspect 16:9 chap1_vign.mov

Ensuite, j'utilise cinelerra pour mettre mes deux vignettes sur le fond, fait avec the gimp.

Ci-dessous, un extrait de mon prochain article sur mon site:

Créez un nouveau projet dans Cinelerra et veillez à bien spécifier le ratio du menu, 16/9 ou 4/3 (le même que votre film).

Ensuite, charger l'image de fond faite avec the gimp en l'ajoutant au pistes existantes. Dans le timeline, etirer cette image de fond pour qu'elle dure 10 secondes.

Ajouter la première vignette via 'charger fichier' en spécifiant 'concatener dans nouvelle piste'. Une nouvelle piste contenant la vignette est crée, mais sa taille est 720x576 par défaut. Redimensionnez la piste à la taille de la vignette (clic droit sur la piste, puis redimensionner).

Déplacer cette nouvelle piste au dessus de la piste contenant le fond puis dans le compositeur, ajuster la position du projecteur pour que la vignette vienne se placer correctement dans sa zone réservée sur le fond.

Répéter l'opération pour les N vignettes supplementaire du menu.

Ajouter éventuellement un effet de fondu au debut et à la fin du menu sur toutes les vignettes.
Ajouter éventuellement de la musique dans la piste audio.

Lancer les rendus pour créer le fichier MP2 (video) puis le fichier AC3 (son).
Générer le fichier VOB avec mplex -f 8 menu.mp2 menu.ac3 -o menu.vob

Et voilà!! Vous avec un menu de chapitrage animé, à ajouter à votre projet DVDauthor.

Pas con! C'est typiquement le genre de détails qu'on oublie de vérifier!

uboot sur uart1
kernel sur uart2
et hop galères...

Oui, j'ai vu ça aussi. Le kernel est bien configurer pour booter à l'adresse que tu donnes?
Le bootloader décompresse le kernel à la bonne adresse?

Salut,

Pour le montage pur, j'utilise cinelerra.
Pour les menu animés des DVD (chapitrage par exemple) , j'utilise FFMPEG pour faire les vignettes animée à partir des rush et ensuite The Gimp pour le fond du menu et Cinelerra pour générer les 10 à 20s du menu animé.

Et DVDauthor pour le formattage final du DVD (les menus, les chapitres, etc..).

Bon, c'est dommage mais netstat ne nous apprend pas grand chose. Mais si c'est du traffic UDP, c'est normal.

J'espère en apprendre plus avec les traces wireshark ou tcpdump (en root):
# tcpdump -n -s 0 -i eth0 -w capture.pcap "udp"
Les paquets UDP capturés sont placé dans le fichier capture.pcap, à mettre qq part sur le web pour qu'on puisse le consulter.

Pour les sommes de controle incorrecte, si c'est en emission, c'est normal si c'est la carte qui calcul les chksum en hardware.
Pour avoir des traces correctes, il faut forcer la stack TCP/IP à calculer elle-même les chksum avant d'envoyer les paquets à l'interface réseau (Si qq'un à des infos à ce sujet, je suis prenneur).

A+

Et si tu mettais les traces wireshark histoire qu'on voit à quoi ressemble ces paquets?
On pourrait peut-être t'en dire plus!
Et aussi le résultat de "netstat -anp" en root.

C'est quoi exactement que tu n'as pas compris?

Car pour moi, PSP (Playstation Portable de Sony) c'est clair.
Normalisation audio, c'est peu être moins clair!?

Le pb de la PSP, c'est le faible volume. Donc si les pistes audio ne sont pas "normalisées", on entend rien. En gros, la normalisation, c'est l'amplification pour atteindre le volume (amplitude du signal) maximum possible sans distortions (donc sans dépasser la valeur max possible).

Donc, le journal est un lien vers mon article sur mon site où mon patch FFMPEG est diffusé.

Je voyais pas pourquoi plus détailler le journal.

David

Comme indiqué dans l'article, le patch de normalisation à été refusé quand je l'ai posté sur la mailing list "dev" de FFMPEG.

J'en est conclu que les modifications sur FFMPEG était moins prioritaires que celle sur le coeur de l'appli, les librairies libav*.

Donc, je n'ai pas proposer de patch pour la target PSP.

C'est pour ça que j'ai fait cette article et journal. Pour essayer de faire profiter aux personnes intéressées.

Lol

Si, il s'agit bien d'une modification. Le patch est disponnible en téléchargement dans l'article sur mon site.
Le script, c'est pour un usage encore plus simple.

http://www.dfg.homedns.org/article21.html

Mes autres articles ici:
http://www.dfg.homedns.org/rubrique1.html

Mon site web est aussi en SPIP. J'aime bien. La courbe d'apprentissage est plus longue que d'autre CMS mais les possibilités de rendu sont énormes avec la vraie séparation moteur/squelette.

Bon, j'ai du développer un petitte extension qui me permets de mieux gérer les "floats" dans les articles car je n'arrivais pas à faire correctement mes articles avec photos.

http://www.dfg.homedns.org

> Ce n'est pas tout à fait pareil.
C'est justement l'intérêt de la chose. Le micro-noyau Adeos permet de créer un domaine plus prioritaire que Linux pour le traitement des IT et/ou threads RT. On n'est même pas obligé d'y mettre un OS/scheduler. La partie non temps-réel Linux reste simple le code temps-réel aussi.

Attention, depuis que RTAI est passé à Adeos, il n'est plus vraiment issu de RTlinux. L'architecture n'est plus la même.

Mes 2 cents aussi.

Les liens:
http://home.gna.org/adeos/
http://www.xenomai.org/
http://www.rtai.org/

J'aimerais souligné l'existance de RTAI et Xenomai, utilisant tous les 2 Adeos, dans ce monde du "temps-réel dur" et libre.

J'ai eu l'occasion d'utiliser Adeos et j'ai adoré le concept.

A+