M a écrit 2988 commentaires

Les constructeurs pourrait proposer un CD qui permet de vérifier que le hardware marche.
Si au moins il validait leur matos avec http://www.linuxfirmwarekit.org/ ...

- l'image est franchement laide, pas nette dès que ça passe par le net (alors qu'Ekiga ne travaille qu'en basse résolution, donc côté bande passante ça devrait pas consommer tant que ça)
Oui, pour des questions de brevet ekiga n'a comme codec video que le h261, alors qu'il pourrait utiliser du h263 ou h264.
Pour le h263, je crois que c'est (etait) possible avec un patch a appliquer.

Coté windows, je sais pas si ekiga est tres stable, mais SIP c'est standardisé, donc il devrait avoir d'autres clients :)

Bref, si on veux un Linux Desktop, il est peut être temps de remettre en question certaines pratiques de temps à autres...
Je n'ai rien contre les interfaces graphiques pour les utilisateurs qui le souhaitent.

Mais que ce soit une interface graphique ou une commande, il y a dans les 2 cas un apprentissage a faire de la part de l'utilisateur. Effectivement sur le court terme, l'interface graphique peut être plus rapide en terme d'apprentissage, mais sur le long terme c'est moins sur.

Tout comme je devrais relire mon script dans 20 ans (bien que je doute que ce soit réaliste car soit il sera obsolète, soit il aura évolué), dans 20 ans l'interface de k3b risque aussi d'avoir changé.


Pour conclure je dirais que j'ai fait des scripts pour répondre à mes besoins et faire des choses que les interfaces graphiques ne permettait pas à l'époque (vérification de l'intégrité des données gravée, ...) et qu'il me sont toujours utile car je sais exactement ce qu'il font (et il le font comme je le souhaite) contrairement a un frontend graphique.

C'est moi, ou je trouve que dans la plupart des cas graver en ligne de commande (avec un script qui va bien) est beaucoup plus simple (et rapide) ?


Je sais pas ce qui est attendu d'un logiciel de gravage, mais chez moi j'en attends qu'il grave des fichiers pas qu'il se transforme en ripper/machine a café/...

il risque quoi ?
Le Monde risque de l'attaquer pour reclamer des domages et interrets.

Ps heureusement que j'ai meme pas parlé du niagara pour les procs
Par contre tu as oublié de parler de ce qui serait mieux que intel (avec une config qui correspond au besoin du monsieur).

Certes tu énonces les faits, mais que la partie qui t'arrage.


Mais j'avais oublié que meme sur linuxfr il y avait des fanboys.
Je suis pourtant le premier dans certains posts sur linuxfr qu'intel ne fournie pas forcement des specs meme s'ils font des drivers libres.

Désolé mais amd n'a pas mis LaGrande dans ses procs ni de tpm dans ses cm a ce que je sache.
Et oui quand j'achete un composant, je regarde si la firme a agis pour ou contre l'enferment des utilisateurs.
Mais ils ne fournissent pas les drivers/specs de leur cartes graphiques (et oui ils ont achetés ATI).

d'un pur point de vue libriste , intel n'est pas une firme que je privilégierais.
Au lieu de denigrer intel [1], si tu nous donnais les constructeurs qui réponde à tes critères libristes ?

Au fait c'est quoi ta config ? Pas d'intel, nvidia, ati j'espère...


[1] intel n'est pas peut etre parfait, mais c'est toujours mieux que rien du tout.

Pour Ralink, les choses se présente bien.
Ha bon, j'avais cru lire quelque part que les cartes wifi ne se feront plus quand le driver sera enfin integré dans le kernel...

Ben j'ai tester, effectivement ca marche, mais c'est super lent chez moi : j'ai du frame par frame.

En plus les controlles ne marchent pas :/

Swfdec est un lecteur de flash, sous licence LGPL. Bon ça c'est pas le premier...
C'est pas si sur, swfdec est tres vieux (2003) : http://www.schleef.org/swfdec/

Swfdec lis donc maintenant les vidéos de youtube.
ffmpeg le fait aussi depuis longtemps (d'alleurq ca m'etonerait pas qu'il l'utilise).
En gros ce qu'ils apportent, c'est qu'on a acces a leur lecteur flash pour les video, pas un lecteur externe.

Bon alors déjà, les vidéos sont encodées en WMV9/VC-1, qui est aujourd'hui un standard ISO (même si c'est un peu comme OOXML, ils auraient pu prendre un truc qui existait déjà, genre MPEG-4, dont WMV9 est dérivé),
Et le son, c'est pas du wma sans aucune doc ?
Et l'asf (le conteneur), c'est pas un truc sans doc avec des brevets a la con ?

Sinon, la méthode donnée au-dessus pour récupérer l'URL de la vidéo marche avec n'importe quel player supportant un ffmpeg récent (comme mplayer sur ma etch).
Une personne (lucas) avait posté sur linuxfr un parseur en ruby qui permet de recuperer les url.

Pourtant, avec Scilab bien compilé avec les libs Altas, on est comparable.
Y a des benchs pour étayer cette affirmation ?

De mon coté, j'ai eu aussi plusieurs retours que scilab etait lent (apres peu être qu'il n'utilisaient pas cette lib).

Je sais pas si ça c'est amélioré, mais à une époque scilab était assez instable sur Windows.

J'aurais tendance à souhaiter l'inverse : mieux intégrer les logiciels multi-plateformes dans Gnome.
Ou plutot faire un truc modulaire sous forme de lib ou la partie appli et la partie graphique sont distinctes.

En effet les logiciels d'un environement graphique cherche a etre homogène, ce qui est assez difficile avec les logiciels multi-platforme.

C'est d'ailleurs plus ou moins ce qui se fait.

Après c'est pas comme si les enseignants respectaient vraiement le droit d'auteur
Ni les jeunes etudiants qui s'inspirent tres fortement des documents de la bibliotheque pour leur exposé.

En faisant valider le code par la boite ?

Au niveau du code, ça peut se traduire par :
- peu de commentaire
- utilisation de "magic number" au lieu de define qui donnent une idée de ce que la valeur/registre fait.

Tu as deja entendu parler de l'embarqué ?
Y a aussi ada qui est (etait) utiliser dans les applis embarquées critiques.

Mais bon meme si le language genere des exceptions en cas de problème (debordement, ...), si elle ne sont pas correctement gerer par le programme le resultat est le meme : ca plante. Cf ariane 5

Je ne dis pas ça parce que je n'aime pas le C. Je programme presque exclusivement en C++, mais c'est justement cette expérience-là qui me fait dire : aucun programme écrit en C n'est robuste ou sécurisé. Il y a trop de failles intrinsèques au langage lui-même.
Et pourtant y a des logiciels en C qui ne sont pas codé avec les pieds qui on tres peu de faille : par exemple http://vsftpd.beasts.org/

n'utilise aucun pointeur C. Elimine les * partout où c'est possible.
Tu passes comment les parametres dans tes fonctions ?
En copiant tout sur la stack ?
Et les valeurs de retour, en utilisant des variables globales ?


* ne gère jamais la mémoire toi-même.
* bannis toutes les fonctions d'entrée/sortie standards du C (genre printf)
* n'utilise jamais de tableaux en C.
T'as des exemples de code C avec tes regles ?
Je serais curieux de voir ce que ca donne :)
(Il est bien entendu qu'il est hors de question d'utiliser des libs qui ne respectent pas ses regles, et que tu as donc recoder ta libc...)

Notons que le testeurs n'a pas envisagé dans sa réflexion la virtualisation pour faire cohabiter Linux et Windows. Si avec un Windows en invité on peut utiliser Direct3D pour les jeux (peut-être avec deux cartes graphiques voire deux cartes sons) ça peut être un gros plus pour l'adoption de Linux en douceur.
Ou faire touner Linux sous Windows avec des trucs comme colinux.
Comme ca le mec il peut jouer sous windows (sans les pertes de perf du a la virtualisation) tout en découvrant Linux.

Jusqu'à preuve du contraire, pour écouter un flux MP3, il faut avoir le codec approprié qui est soumis à une licence non libre.
Et cette licence elle repose sur quoi ? Les brevets logiciels ....

Je trouve beaucoup plus important d'utiliser des connexions SSL que de crypter mon home.
C'est clair, j'aimerais connaitre le nombre de commerciaux qui consulte leur mails (via pop ou http) sur un wifi ouvert (aeroport, ...)...

Et si l'Ouganda passe une loi disant que si le code de Linux n'est pas réécrit alors il faut faire trois fois le tour de l'immeuble à cloche pied ? Tous les codeurs du monde vont le faire ?
Sauf que si je dis pas de connerie il y a des accords internationaux (notament sur la propriété intellectuelle) que les pays du tiers monde sont plus ou moins forcé d'accepter (sinon pas d'aide, de commerce, ...).

"Avoir la garantie que ses données ne seront pas vendues"
Ben dans ce cas on peut toujours les echanger ou les offrir pour l'achat d'un autre service....

dans la plupart des éditeurs et traitements de textes "faciles à utiliser", on coupe et colle en employant Ctrl-X et Ctrl-V.
Ainsi quand quelqu'un arrive sous Vi et constate que c'est « d » pour couper, et « p » pour coller, il ne le considère pas comme amical.
:so $VIMRUNTIME/mswin.vim


Mme Michu, la première chose qu'elle va remarquer quand elle va arriver sous Vi (si un jour elle y arrive), c'est que sa souris ne marche plus et donc qu'elle ne peut pas surligner de texte avec !
:set mouse=a


Ok je sors...

Bref, une dépêche parlant un peu plus du boulot fourni par Yinghai Lu (AMD) qui a implémenté le support du MCP55 et un peu moins de choses non vérifiables aurait été souhaitable.
ouai surtout que le journal Linuxfr etait assez complet (ca veut dire que les modos n'ont meme pas lu les liens)...

Sinon pour avoir regarder le svn de linuxbios, tout le code n'est pas encore commité (tout du moins hier).

En effet, nous apprenons dès nos début en programmation que plus un langage est "haut niveau" et plus ses performances sont dégradées (en général).
Gnome est lent, ils auraient du coder en assembleur :)
Plus serieusement, plus le langage est bas niveau, plus il est possible de faire un truc hyper performant ou un truc mega lent (si on loupe des optimisations qu'un compilo aurait vu).

De la même façon, nous apprenons (et vérifions) que les langages interprétés sont généralement plus lents que les langages compilés.
Avec la compilation JIT, les langages interprétés doivent pouvoir etre plus rapide que leur equivalent compilé dans certains cas.
Voir par exemple un scaler compilé en JIT, plus rapide que son equivalent C compilé statiquement : http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/42975