Sytoka Modon a écrit 4538 commentaires

Non, je ne pensais pas au DRM mais a un système de jeton ou d'authentification quelconque...

Sinon, j'espérais que le serveur était open source.

Vous utilisez aussi des outils Apple pour faire le 'cut' sur les films ? Diffusez vous des films a double flux vidéo (type H323 avec H329) ayant donc un flux 'vidéo' et un flux 'data' ayant une meilleure résolution mais moins d'image par seconde.

Merci

Tu utilises quoi comme serveur et comme logiciels. Vos vidéos en VOD sont sécurisés ?

Une infrastructure basé sur Linux et H264 en VOD m'intéresse beaucoup comme solution.

Et puis, si les onglets sont en haut de la page, autant avoir un gestionnaire de fenêtre qui gère les onglets ! (comme pwm et bien d'autres maintenant) Cela devient son boulot.

Pas vraiment, tous les navigateurs s'appellent mozilla en interne et cela depuis des années (le début ?). Idem, le système interne dans la 'packaging' s'appelle chrome et cela depuis aussi pas mal de temps.

C'est le nom final, public qui change. Pas les noms de code interne.

Chrome, c'est un peu un nom de code dans les applications mozilla depuis des années... Lorsque j'ai lu l'annonce, je me suis dis que ce navigateur était basé sur mozilla ! Ben non, sur WebKit.

Vis à vis de mozilla, ils auraient pu choisir un autre nom...

Je ne suis pas sur que les développeurs de gnome teste celui-ci sous autant d'architecture que debian...

Il ne faut pas croire que parce que tu sors une nouvelle version stable, celle-ci le soit rééellement sur des distributions aussi complète que debian (ou fedora...).

Ne prenons pas non plus les uns et les autres pour des manchots. Comme dis le proverbe, il n'y a que clui qui ne fait rien qui ne casse pas les oeufs. Donc bien sur, tout le monde prends des risques !

Bref, le travail des équipes est complémentaire et les deux sont nécessaires.

X a été conçu pour la transparence réseau et en cela, il est formidable. X devient de plus en plus modulaire et la transparence réseau oblige a avoir un code plus propre au niveau noyau de séparation des tâches. Bon historiquement, X a transgressé pas mal de chose mais c'était pour être multi-UNIX.

Car oui, c'est un point important dans UNIX, d'être multi version de l'esprit UNIX.

L'administration de MacOSX me rappelle parfois celle de Windows 98... Les panneaux graphiques sont simplifiés à l'extrème, on n'arrive même pas a avoir toutes les informations que l'on souhaite. Configure par exemple un imprimane réseau et essaye de retrouver ensuite tes paramêtres de configuration sans aller trifouiller dans le système.

Parfois GNOME (que je ne suit pas du tout) me semble prendre la même voie de trop simplifier l'interface utilisateur pour faire croire que c'est simple. Du coup, on finit par manquer de molette.

Contrairement aux autres UNIX, MacOSX ne s'intègrent pas bien dans ce type de parc, en tout cas, pas mieux qu'un Windows en domaine !

Ce n'est pas un vrai 'UNIX' puisqu'il n'y a pas X par défaut et pas de troisième bouton à la souris (ni de second). Tu copie colle comment ? Le clavier est à chi... en tout cas, il n'est pas fait pour la ligne de commande.

L'IHM ne peut suivre un programme fonctionnant en Follow Mouse ce qui est le mode par défaut des applications traditionnelles graphiques...

La gestion du partage de fichier est un samba mais le nombre de réglage est .... plus que minimaliste.

Il y a du /Library un peu partout... Cela ne suit pas du tout la FHS. Le Library est traduit en francais, ce qui est une abérration à mon sens. Heureusement, en ligne de commande, cela reste Library contrairement à Microsoft qui a inventer les 'special folder' histoire de compliqué inutilement la structure du système.

Bref, c'est un UNIX très très à la marge.

C'est à dire ? Les choix justement fait par Apple

Ok, je -> []

> Gni ? Tu peux développer ?

J'ai déjà vu du code Java planté lamentablement sous Firefox Linux et marcher sous Windows... Je ne citerait pas le constructeur ici.

> D'ailleurs sur les gros sites la scalabilité est de loin plus importante
> que la performance. Mais on y pense tout de même.

Je suis entièrement d'accord. A propos de compilation JIT, c'est effectivement une voie possible (par exemple en C, il y a TinyCC qui fait cela). Cependant, pour les gros codes, la voie d'un bon compilateur qui prend son temps pour optimiser un maximum me semble préférable mais peut être ai-je tord.

> Mais concrètement pour des sites web tu as le choix entre: PHP,
> Perl, Python, Ruby, Java, .Net.

Je n'ai pas dis que Java était lent. Il suffit de voir ses performances pour voir qu'il scotch maintenant tous les langages de script.

Cependant, l'énergie mis sur Java pour arriver à cela aurait pu être mis sur autre chose...

A propos du développement Web, je suis 100% d'accord avec toi. C'est incroyable qu'autant de choses soit encore faites en langage de script. Cela ne viendrait à personne de faire un serveur NFS en Perl, mais un serveur web oui.

A mon sens, il ne devrait pas y avoir de différence notable entre une application web, Qt, GTK... dans la manière de programmer. A quand un Web3 qui serait POSIX ;-)

Pas d'intégration du patch debian ajoutant la fonction de blacklist de clef ssh. Dommage, vu l'envergure du problème debian... il va rester plein de serveur au monde acceptant les mauvaises clefs.

Je n'ai rien vu aussi à propos des clefs DSA. Je n'ai pas tout compris a leur sujet mais debian conseille de ne plus faire de clef DSA.

Bref, les changements dans OpenSSH sont dans la continuité et améliore surtout les parties MATCH et SFTP.

yahoo, ebay... Des jeunes pousses ?

Je n'ai jamais dis que Java est une bouze et qu'il ne marche pas.

Je dis simplement que pour des gros codes coté serveur, comme ceux pour ebay ou yahoo, avoir un java compilé serait tout aussi bien. Ils gagneraient en performance. Ces codes là n'ont pas besoin de la compatibilité binaire inter-plateforme (qui marche d'ailleurs plus ou moins bien).

Par ailleurs, les boites que tu donnes n'ont certainement pas un serveur en frontal mais toute une ferme.

Il y a plein de logiciels qui fonctionnent à la fois sous Windows, Linux et MacOS e t qui ne sont pas programmé avec mono. Il suffit de programmer dans un environnement multiplateforme et de recompiler sur chaque.

Bref, je comprends que certaines personnes programme avec .NET parce qu'elles aiment cet environnement. Mais d'un point de vue personnel, je ne vois pas ce qu'il apporte de plus a par des inconvénients.

Java a été très mal vu à l'époque sous Linux. Il y a cependant un différence de taille entre les deux projets :

- Java s'est voulu dès le début multiplateforme et non limité aux seuls produits SUN.

- Java vient de SUN qui n'a pas la culture du nombril et du monopole comme Microsoft. Enormément de protocole réseau viennent de SUN : NFS, NIS...

Ceci dis, SUN s'est planté avec Java car celui-ci était destiné aux clients et on le retrouve surtout au niveau des serveurs. Or je ne suis pas sur que cela soit une très bonne idée d'un point de vue sécurité et performance d'avoir du code binairement portable. Pour un serveur, autant recompiler son code...

D'ailleurs l'argument de la portabilité est assez bidon, les grosses applications embarquent leur propre copie de la JVM pour ne pas avoir de problème de compatibilité (exemple Matlab). Sur un poste Windows, on est obligé d'avoir plusieurs version de .NET... A ce niveau là, Perl est bien plus portable et je n'ai jamais eu plus d'une version de Perl sur mes postes !

Bref, au final, ni Java ni .NET ne sortent du chapeau, .NET dérive de Java et Java d'OpenStep dont SUN n'avait que la moitié des parts... Finalement, tout cela pour éviter aux programmeurs de développer en ObjectiveC...

Qui développe des applications sous Wine ?

Wine est un truc que je suit depuis le début et que je n'ai jamais vu en production (sauf le machin de crossover).

Après un paquet d'année, Wine est juste en train de sortir sur quelques applications. Encore une fois, que d'énergie pour un si piètre résultat. la chance de Wine est que Microsoft veut changer son API avec Vista et donc pour les migrations des vieux logiciels, le passage par Wine peut être rentable.

A mes yeux, Wine n'est pas du tout un environnement pour innover au niveau logiciel. Si Wine est un modèle pour Mono, et j'en doute, je ne trouve pas cela très positif.

Miguel a simplement basculé du coté obscur de la force

-> []

Parce que Fedora est ouvert au non-libre ?

Je te rappelle que chez debian, il y a les parties contrib et non-free, donc on installe le java de SUN avec un simple apt-get !

Avant de sortir des grands mots d'exclusion, merci d'être un peu plus respectueux du travail des autres.

> Histoire de pouvoir offrir une alternative libre, le jour où "on en aura
> besoin

A développer mono et des logiciels sous mono, on participe à l'écosystème et on va se chopper une dépendance un jour...

On peut très bien faire un système sans base de registre... On n'a pas besoin dans UNIX d'avoir les API Windows qui ne sont pas POSIX !

L'important est d'avoir des logiciels sous UNIX qui sont utilisable par les utilisateurs. L'important est que Firefox marche sous UNIX et sous Windows, qu'importe comment il fonctionne sous Windows.

Tout ce qui peut être développé sous mono peut l'être dans un autre environnement. La question est donc de savoir si on aurait pas pu mettre l'énergie sur ces autres environnements ?

Le logiciel samba est très différent, le but est de faire communiquer des mondes différents. Mono n'a pas vraiment cet objectif : qui utilise mono sous Windows aujourd'hui ?

Mono, cela me rappelle le projet ReactOS. Beaucoup d'énergie pour un objectif peu satisfaisant.

Je préférerais que Novell mettent ses moyens sur Parrot. Si Novell n'avait mis qu'1/10 de ce qu'elle met sur Mono aujourd'hui dessus, je suis sur que Parrot serait déjà pleinement opérationnel de nos jours.

Sauf que ton exemple est MAUVAIS, perl6 est un nouveau langage, c'est pas vraimnt la suite de perl5. D'ailleurs, je connais peu de langage qui ait autant de changement que le passage de Perl5 à Perl6. Le seul exemple qui me vient en tête est le passage du Fortran 77 au Fortran 90 et encore, cela restait compatible.

Un exemple d'application stratégique même si je n'aime pas ce a quoi il sers

-> TERA 10 -- http://fr.wikipedia.org/wiki/TERA-10

Autre exemple important pour l'avenir de l'homme (je rappelle que nous sommes mal partis en ce moment) : une grande partie du système d'information autour du LHC (CERN) tourne sous Linux.

Des exemples comme cela, il y en a plein.

La bonne nouvelle est qu'ici Linux rentre au coeur des systèmes financier.

Tu pourrais aussi rsyncé /opt.

Je vois que nous avons les mêmes méthodes.

> La sncf se vante de taux de 90% à l'heure qui ne reflète pas
> vraiment le sentiment des voyageurs. Cela serait un bon moyen de
> vérification.

Si 90% des trains sont à l'heure, cela signifie que plus de 10% des voyageurs sont en retard !

En effet, les 10% de trains en retard ont plus de chance d'être aux périodes pleines que creusent (1 retard entrainant un autre retard entrainant...). Or en période pleine, les trains sont pleins ce qui n'est pas le cas des périodes creuses.

Donc, disons au pif que 20% des voyageurs ont un retard, et bien c'est ENORME car cela signifie que 15% des passagers ne sont pas content (j'en garde 5% qui sont en retard mais ne sont pas mécontent).

Bilan : 15% est une quantité non négligeable. Mets 15% des français dans la rue et tu bloques n'importe quel réforme.

> Finalement heureusement que la SNCF n'est pas une compagnie
> aérienne, parce que vu l'état de leur matériel, si c'avait été des
> avions, ils auraient des morts sur les bras

Le matériel ferroviaire est conçu historiquement en sécurité intrinsèque. Les avions sont conçus en sécurité probabiliste.

Qu'est ce que cela veut dire : qu'avec un avion, tu as une probabilité de x pourcent de te casser la gueule... En train, en cas de panne, la train s'arrête et attend...

La conception même de la sécurité n'est pas la même et les conséquence non plus. Rarement une panne de train a liquidé tous les passagers !

Avec l'informatique, la sécurité probabiliste intègre les trains petit à petit. C'est Matra qui a grandement participé à cela notament sur la ligne A du RER avec la notion de canton déformable (on va pas rentrer dans les détails mais en gros un train peut rentrer en gare alors que le précédent n'est pas encore complèment partis).

L'informatique plus la sécurité probabiliste dans une culture ou la sécurité intrinsèque prime signifie qu'on arrête le train en pratique en cas de panne.

En avion, avec un défaut de réacteur ou d'aileron qui se révèlent après le décollage, tu continues et tu atterris à destination si tu restes sur le continent europpéen. En effet, atterir le plus vite possible et donc descendre rapidement ne diminue pas forcément la probabilité de te casser la gueule. Un avion vole sans réacteur (un temps) et je suis persuadé que dans les tests de conformité, ils les font atterrir sans réacteur et à pleine charge (sans gazoil).

Bref, la culture et le type de sécurité ne sont pas les mêmes. Par ailleurs, il n'est pas possible de prendre le modèle de l'un et de le transposer sur l'autre. Un véhicule terreste et un véhicule aériens ne sont pas soumis aux mêmes contraintes mécaniques.

Cela dis, en avion aussi, il y a des retards... et des pertes de bagages, tiens, parlons en !

> Des standards, on en a déjà et des distributions utilisée pour être
> certifiée avec du matos pro aussi (genre SLES/RHEL), alors je vois pas
> à quoi ça servirai.

C'est clair. On a en pratique trois standard de fait aujourd'hui : RHEL et SLES et à un degré moindre la debian qui si elle n'est pas officiellement supporté, à une base utilisateur qui doit obliger les constructeurs a en tenir un tant soit peu compte.

Vouloir imposer un standard, c'est vouloir donner le monopole soit à Red-Hat, soit à Novell. Non merci.

Je préfère l'approche LSB qui n'impose rien à l'utilisateur et qui ne l'installe que s'il en a l'envie.

Attention, je crois qu'une session samba se détourne... donc ce ne serait pas super sécurisé.

NFSv4 a été conçu pour être transportés sur internet. Donc il n'y a pas de soucis à ouvrir un serveur NFSv4 sur un firewall (si l'implémentation est correcte, bein sur).