M a écrit 2996 commentaires

Ainsi donc, on vient tous d'apprendre que Windows n'est pas piratable !!
Ben oui c'est connu, tout les bugs de Windows sont du a une " inversion spontanée et aléatoire d'une position binaire" :)
Cf http://www.lemonde.fr/web/article/0,1-0@2-823448,36-884860@5(...)

Un exemple fameux est l'incident de Schaerbeek (Belgique), le 18 mai 2003. Le décompte des voix exprimées avait excédé de plus de 4 000 le nombre d'inscrits
[...]
les autorités fédérales belges a conclu que "l'erreur (avait) très probablement été occasionnée par une inversion spontanée et aléatoire d'une position binaire".
[...]
"Ce phénomène, ajoutaient les experts, est abondamment décrit dans la littérature spécialisée."

Ban non, un ticket de 5x9cm imprimé à coté de douze bulletins par votant, ça reste assez avantageux !
Si y a vraiement que le cout du papier qui compte, il y a une methode simple :
y cas faire des bulletins avec imprimé candidat 1, candidat 2, ..., candidat N et dans chaque isoloire un tableau avec la correspondance canditat X <-> nom.

Comme ca tu peux reutiliser les bulletins inutilisés (et meme ceux qui sont dans urne).

Le problème étant que le JPEG est un format de compression avec perte et que donc plus je fais de retouches, de modifications, plus je dégrade mon image de base.
Pour sauvegarder les modifs intermediaires pourquoi t'utilises pas le format de ton logiciel de retouche.
En plus ca te permetras de converser d'autres paramétres (calques, ...).

Mais de quoi tu parles ? C'est pas une boite locale qui a remporté le contrat ? Les sous ne vont pas dans la poche de Canonical à ce que je sâche.
Ha bon, je croyais que c'etait les boites francaise Lynagora et unilog qui avait le contrat.

D'ailleur Francois le dit lui meme :

L’offre présentée par Mandriva et ses partenaires a l’avantage d’associer directement éditeur et intégrateur, au contraire de l’offre choisie par les services informatiques de l’assemblée, ce qui présente par là même un risque important.
Ubuntu fournie juste la distrib, mais n'assure aucun support.


Au lieu de geuler chez mandriva, il ferait mieux de donner envie au personne qui decouvre Linux d'essayer leur distrib (c'est facile de dire ubuntu est financé par un milliardaire et on peut pas lutter).

A la rigeur on peut imaginer un truc comme SIP et STUN, ou on arrive a traverser les parfeu de par et d'autre.

D'apres http://en.wikipedia.org/wiki/Comparison_of_VoIP_software , je vois quelque client SIP qui font de la visio sous Windows.
Par exemple x-lite

Tu veux dire que dans la tonte des logiciels SIP donné par wikipedia ( http://en.wikipedia.org/wiki/List_of_SIP_software#SIP_client(...) ), seul 2 supporte la visio ?

Et le tout est incompatible pour les drivers (source et binaire).
Mais bien sur ...
On se demande comment certains drivers externes arrivent a le faire si on t'écoutait.

Certes il y a quelques différences, mais elle reste somme toute minime et on peut assurer une compatibilité source assez facilement.

Ce qui est important, c'est qu'ils valident avec une version de Linux pas trop recente (3 ou 4 versions de retard) por eviter de dependre de fonctionnalité trop récente.

D'ou l'importance d'une distrib pre-installé : le matos est certifié fonctionner avec cette distrib (et donc la version du noyau qui est dedans).

Si tu veux utiliser une autre distrib, à toi de t'assurer que ça fonctionne ou de compiler les drivers qui vont bien.

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...)