benoar a écrit 4229 commentaires

Ha oui, c'est bien ça. C'est sur quel distro qu'il configure ça comme ça ? Je n'avais encore jamais vu de conf "par défaut" (je suppose) avec deux IPs (qui dans ce cas sont bien pratique, je veux dire, la route mise par avahi permet de communiquer avec les machines qui auraient du mal avec le DHCP ... ça me fait penser à la conf IPv6 : une adresse link-local, et une adresse publique).

Comme le fait remarquer nodens, on peut tout à fait changer une route, mais en utilisant des outils modernes. ifconfig et route sont très vieux et très limités. iproute2 est vraiment le futur du réseau sous linux (depuis des années pourtant ...) si on veut faire des choses intéressantes (ip multiples, tables de routages "contextuelles" pour le bonding par exemple, IPv6, etc).

Tout est dans le titre. Je trouve bizarre cette route, elle ne devrait pas être là.
Tu peux aussi filer le contenu de ton /etc/hosts, ça nous aidera à décrypter les noms de machines.

Tcpdump t'affiche le nom car c'est lui qui fait la requête DNS. Ça ne vient pas de ping ou de la requête ARP (qui est toujours faite avec une IP et pas un nom).

Franchement, faut vraiment être masochiste pour continuer à faire ça des années. Au début c'est encore un "vieux réflex", mais après, il faut savoir s'en détacher. Je n'ai pas fait d'installation de windows depuis .... houla, 7 ans ?

Tout d'abord, merci pour les détails.

Il faut dire qu'Apple interdit de lier dynamiquement des bibliothèques, de sorte que MonoTouch doit lier statiquement Mono. Ce qui fait qu'on ne peut pas appliquer la LGPL, qui est la licence du runtime Mono. Donc il faut passer par la licence propriétaire de Novell.
Non, ce n'est pas la bonne raison : on aurait très bien pu décider de tout mettre en LGPL/GPL, même le programme qui utilise MonoTouch. Mais je suppose que ça n'aurait pas plu à certains qui veulent faire du proprio.

La "vraie" raison que je ne comprend pas très bien est "qu'on doit pouvoir remplacer la lib par leur propre version, selon la LGPL" (traduction libre) et qu'à priori c'est incompatible avec les conditions de l'AppStore (si quelqu'un avait une explication, ça m'intéresse).

Personnellement, je ne trouve pas ça choquant de commercialiser un produit pour une plate-forme complètement fermée, tout en gardant Mono complètement libre et open-source.
Je ne trouve pas ça complètement "choquant" non plus, mais l'argument du "puisque c'est fermé, autant rester dedans" ne va pas de pair avec la philosophie du logiciel libre (qui essaye en général de "libérer" les utilisateurs, même lorsuq'ils sont sur une plateforme propriétaire).

D'abord tout le monde fait ça, Sun pour MySQL / Java, Red-Hat pour JBoss, etc. C'est même un modèle plutôt familier le couple GPL/LGPL + licence propriétaire.
Encore un argument du "puisque tout le monde fait ça, c'est pas la peine de chercher à faire mieux" : c'est du nivellement par le bas. Le libre ne s'est pas développé grâce à ce genre de réflexions. Et quand tu dis "tout le monde fait ça", je pense que tu as cité les principaux exemples, mais il y en a aussi beaucoup d'autres qui ne le font pas, à commencer par le kernel.

Ensuite, pour les contributeurs de Mono, quand ils touchent au runtime, ils ont le choix de publier leur patch en signant un contributor agreement pour le copyright, ou de garder leur copyright et de publier le patch sous MIT/X11.
Pour reprendre dans un autre contexte une phrase citée plus haut : choisir entre la peste et le choléra ... "Garder" son copyright avec une MIT/X11, c'est un argument de BSDiste, pas de "GPListe". Ceux qui contribuent à des logiciels sous GPL le font pour que les dérivés ne deviennent pas proprios. Ce qui est tout le contraire de ce genre de deal.

Surtout, si ils contribuent des patchs, c'est surtout qu'ils ont un intérêt et que pour la plus part, ils utilisent Mono commercialement aussi.
Ha bon ? Je ne connais pas vraiment l'écosystème autour de Mono, mais si c'est un paquet de gens qui ne rêvent que de faire du proprio, ça ne m'attire pas vraiment.

MonoTouch est un produit de niche (pas forcément petite la niche cela dit), pour les développeurs .net expérimentés, qui souhaitent réutiliser leurs compétences et/ou du code pour faire des applications iPhone.
L'argument de la "niche", on le sort à chaque fois qu'on ne veut pas faire de libre. Le problème, c'est qu'à partir du moment où on autorise du libre dans une "niche", elle ne le reste plus longtemps, et devient commercialement beaucoup moins intéressante.

Ha, effectivement, il y a des subtilités : les classes sont sous MIT/X11, le compilateur est sous GPL. Je me suis fait avoir par le "associated with LGPL".

Si quelqu'un a plus d'infos, je suis preneur (j'avoue que je ne connais pas énormément le projet).

Donc, ma dernière remarque est en partie fausse. Par contre, ça reste toujours "commercial" (j'aimerais bien qu'ils filent plus de détails quand même).

Tu peux mettre le message d'erreur que te met mplayer ?

J'avais déjà joué avec la MàJ dynamique de DNS avec bind en fonction du nom envoyé par le client DHCP (sur un réseau local, donc), et je viens de trouver cette page qui pourrait t'intéresser :

http://linux.yyz.us/nsupdate/

C'est chiant à trouver sur google car "dynamic dns" correspond beaucoup aux services de type dyndns, mais c'est aussi le nom d'un mécanisme dans bind qui permet de faire ça sans les "complications" de ce genre de solution.

Chez moi, ton lien RTSP marche bien avec mplayer.
Par contre, je n'ai pas compris un truc : tu dis qu'ils sont passés de RTSP à HTTP, mais tu donnes un lien RTSP ....?

un noyal Linux qui marche tout bien tout propre
J'espère que pour toi le proprio n'est pas "sale", parce qu'à mon avis il y en a un paquet (et également dans le kernel).

Extrait de l'article :
Although Mono is associated with the LGPL (GNU Lesser General Public) license used for distributing free and open source software, Novell with MonoKit is distributing Mono under commercial terms. The LGPL requires that users can replace an LGPL library with their own version of a library, a conflict with App Store requirements, according to Novell.
Donc, ce "kit" sera sous une licence "commerciale", ce qui veut dire (selon moi) qu'on aura peut-être les sources (mais c'est pas sûr) mais surtout que ce ne sera pas une licence libre.

Les contributeurs de Mono qui ont donné leur copyright à Novell peuvent dire merci.

Mon avis sur la conversation, c'est qu'Octabrain n'aime pas les tutos vidéos, le fait savoir et demande la raison à Brioche pour laquelle il les aime bien, lui. Tout ça dans la plus pure tradition des commentaires un peu HS de linuxfr (que j'aime bien).

Après, je vois du moinssage, de la non-compréhension, et finalement des insultes avec ton commentaire, ce qui m'inquiète vraiment sur la tolérence à la critique de certaines personnes. Brioche était cordial, mais à coté de la plaque (selon moi, dans le sens où il n'avait pas compris le "but" de sa question, qui était, encore selon moi, plutôt sur les raisons "profondes" de son choix plutôt que sur le cosmétique), et je trouve ça sur-réaliste que quelqu'un d'autre soit obligé de dire ce qu'il pensait à sa place.

Je commence à avoir vraiment peur dans cette société où on doit absolument tout laisser faire sans jamais critiquer. C'était un peu la raison de ma remarque, à la base.

Tiens c'est marrant, ça corrobore ma thèse à propos du N900 (cf la news) qui supporte à peu près les même codecs, sans vorbis ni théora : vu que le hard vient de chez TI (un iMX 31 comme indiqué plus bas), le décodage doit être effectué par le DSP, et TI n'a pas implémenté de codecs "libres". Donc tous ces vendeurs de solutions ne font rien d'autre que reprendre ce que fournit le SDK de chez TI, et ne se prennent pas la tête avec les chieurs de libristes.

Si tu me permets, j'aimerais juste faire une petite analyse "psychologique" de votre discussion avec Octabrain, car je trouve ça assez étrange. (pour prévenir tout de suite, ce n'est pas du tout une critique envers lui ou toi, c'est juste pour comprendre)

À la base, je pense que ça part d'un problème de compréhension. Lui demandait la raison de la vidéo, alors que toi tu parlais de la réalisation. Le truc c'est que pour toi, la raison était évidente (comme tu le montres dans ce commentaire) mais tu ne l'a jamais expliquée, et que c'est quelqu'un d'autre qui l'a fait. Octabrain a insisté car il était à mon avis curieux de voir les arguments de personnes qui utilisent des moyens qu'il trouve moins adapté, comme la vidéo. Et je ne comprend pas pourquoi tu n'as pas tout de suite répondu afin d'éclaircir la raison, même si elle te semblait évidente. Alors après il insiste, d'une manière qui peut paraître bizarre c'est vrai, tu prends ça (et tu n'est pas le seul, vu le moinssage) comme un rejet de la vidéo et le débat coince.

Je n'ai pas d'avis fixé sur les tutos textes ou vidéos, mais j'avoue être intéressé par tous les arguments, et je trouvais que les commentaires d'Octabrain permettaient de creuser un peu les raisons. Je trouve ça dommage que cela termine en prise de tête.

Bon, j'ai mal dit ce que je pensais : on trouve un certains nombre d'ARM avec FPU, et donc on ne peut pas dire que jack est importable sur ARM ... Après, faut voir sur quel genre d'embarqué on veut avoir jack : ça vise plutôt le "haut de gamme" selon moi, et il y a plus du chances qu'il y ait une FPU à ce moment là.

Arrête ton char, quand tu veux des infos, t'as déjà réussi à en avoir. Si tu t'intéraissais un minimum au problème, je pense que tu pourrais avoir des infos. Si tu viens ici, c'est que tu t'intéresses un peu au libre, non ? Ça t'intéresses pas toute cette histoire de code MS sous GPL ?

Communications privées ... là on parle quand même de la politique de maintenance d'un module kernel pour linux dont MS a demandé l'inclusion upstream (d'après ce que GKH dit, après tu peux peut-être contredire, mais alors c'est que t'as des informations ...), un truc plutôt public. Si ce n'est pas un minimum connu dans la boîte, c'est que pour moi il y a anguille sous roche, et qu'ils préparent peut-être un plan foireux. Ou alors c'est qu'ils n'en ont rien à foutre, ce qui corroborerait ma thèse.

Oui, pour moi, faire un montage non prévu à la base pour le système, par un utilisateur, sans trop de difficulté, je trouve que FUSE est bien. Même si on peut faire "mieux" en ayant un système de hotplug bien prévu, mais bon, il y a des cas où c'est difficile (montages réseau, etc).

À noter que cette solution garde l'ancienne stack ATA. C'était juste pour info (il ne me semble pas qu'il soit possible de nommer les disques /dev/hdX avec libata, à moins de jouer avec udev).

Rho putain, l'autre qui comprend rien, qui nous fait un homme de paille, un coup de parano, la totale quoi. Tu te relis des fois ?

Pas plus que de permettre l'intégration de drivers propriétaires. Et pourtant les mécanismes existent...
Le rapport avec la choucroute ? Tu répondais à (je suppose) :
C'est quand même pas le soucis des devs du noyau de faire tourner Linux sur un hyperviseur propriétaire ?!
Ce n'est donc pas plus leur souci de maintenir un truc bâclé. Ils font avec MS comme ils font avec n'importe qui : si tu fais pas d'effort, t'es pas inclus upstream. Point.

Et propriétaire ou non, ce n'est pas trop la question à mes yeux.
Nous non plus, puisque ce dont on parle est sous GPL ...

Xen (avant Citrix, depuis j'avoue être paumé) a longtemps fait/proposé des modifications dans le noyau sans pour autant qu'elles soient intégrées à la branche officielle.
Oui très bien. MS peut très bien le faire aussi, hein, personne ne leur empêche. Mais "ils" ont demandé l'inclusion upstream, il y a quelques règles à respecter (qui sont les mêmes pour _tout le monde_, je répète).

A ce compte là, les "devs du noyau" ne sont pas là pour faire tourner quoique ce soit. Ils pourraient d'ailleurs faire des trucs dans leur coin, sans communiquer.
Là forcément tu vas commencer à énerver ton interlocuteur. Ce n'est pas en se foutant de la gueule des gens qu'on fait avancer le débat. Alors après t'étonnes pas que tu t'en prennes dans la gueule.

Ce n'est pourtant pas ainsi que ça fonctionne. A croire que ce n'est pas ce qu'"ils" veulent (en supposant que les "devs du noyau" parlent d'une seule voix) mais qu'ils souhaitent plutôt offrir le maximum de services aux applications (au sens très large). Etonnant non pour un système d'exploitation...
Oui, je suppose que c'est ce qu'ils souhaitent aussi. Mais il ne faut pas non plus les prendre pour bobonne, il y a certaines règles à respecter, qui sont édictées depuis la nuit des temps dans la doc. Le formatage du code c'est la base de la base, déjà.

Essaye de comprendre un peu les rapports de force avant de t'envoler comme ça.

OK, merci pour le support quand même, même si c'est HS ;-)
J'attend que PA revienne par une dépendance (parce qu'à mon avis ça va arriver un jour ...) avant de m'y relancer, quand même.

En tous cas je trouve que tu mérites une fortune sur celle-là, elle m'a beaucoup fait rire.

"proprement séparée en modules" ça me fait quand même beaucoup penser à linux, mais bon je ne connais pas exactement le système de MS. Les "personnalitys" je ne sais pas trop ce que c'est, mais ce serait une sorte de contrôle d'accès niveau kernel ? Effectivement linux n'a pas ça, mais si tout est dans le même espace mémoire, on pourrait imaginer pas mal de choses pour le contourner ...

Bah, il a quoi alors comme avantage d'un micro-kernel ?