Le problème avec une ABI standardisée qu'on change
Je penses qu'il voulait dire "stabilisé" plutôt que "standardisé" : en gros faut pas qu'il change, ou rarerement.
On peut imaginer une ABI "stable" pendant 3 ans. Au bout de 3 ans une nouvelle version arrive, moyennant un coût supplémentaire le noyau peut gérer l'ancienne qui devient "deprecated" mais qui pête pas les drivers existants. Au bout de 3 nouvelles années, tu vires la vieille interface (on va pas la maintenir 107 ans) : en tout on a eu 6 ans de compatibilité binaire et 3 ans pour migrer les drivers encore maintenus/utilisés.
Ca me paraît totalement réalisable.
Euh, c'est vrai, une compil kernel ça prend 30s sur un Atom.
Tu réponds pas au problème : pour des questions d'emprunte mémoire, de sécurité, de spécificité matérielle, on a pas envie de charger tout le bouzin en mémoire. Comment en Lisaac je charge dynamiquement des modules en mémoire sans passer par une compilation/déploiement séparée ?
Faut savoir : le principal intérêt de Lisaac, c'est la compil globale qui apporte un gain de perf. Si le code est "modulable" et compilable/déployable séparrement, le compilo peut plus faire son boulot de compilation globale, on perd une bonne partie de l'intérêt de Lisaac.
Lisaac est "bydesign" conçu pour mettre en contradiction les gains de perf avec la modularité du code. Faut vous faire une raison, Lisaac se focalise sur des objectifs qui sont loins des préocupations des développeurs et packageurs.
Peut être que sur de l'embarqué où le kernel n'est pas trop complexe et qu'il y a un seul mainteneur ca peut servir à quelque chose... ou pas.
il y a toujours la possibilité de découper le C en petits bouts, et de coller un .h pour lier le tout.
\o/ J'attend de voir ça dans une équipe de développement et son environnement SVN/GIT+IDE+makefile...
J'attend aussi de voir le débuggueur...
Les langages modernes s'occupe de toutes les problématiques de la réalisation d'un soft, du dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement.
On a l'impression qe Lisaac se focalise uniquement sur le dev et l'exécution.
Je ne parle pas de modules pour les perfs, mais tout simplement de modules pour des questions de distribution, de développement en équipe séparée, etc. Exemple : le kernel Linux est capable de charger un module "à chaud". Le module en question est déployé en tant que binaire séparé et n'est pas chargé automatiquement (sauf si la configuration de la machine l'indique bien évidemment).
Il faut également pouvoir charger des modules dans des espaces mémoires différents avec des droits différents (séparation userland/kernelland). Tout ca suppose qu'on passe par une autre étape qu'une bonne grosse compilation du bouzin qui contient tout vu quon connait pas la machine cible.
Sans parler que même si ca prend "seulement" 5 minutes à compiler sur ton quadri-coeur de la mort, pour le développeur c'est attroce comme environnement de test/déboggage.
Bref autant de critère qui rend la séparation en module indispensable pour tout gros projet, et un kernel est un gros projet.
Disons qu'il y a une interface 32 bits. Après suivant l'architecture cible, c'est soit une émulation (genre sur Itanium 64), soit un switch du mode d'exécution du thread (sur x64), cf http://en.wikipedia.org/wiki/WOW64
Oué euh si Windows tourne en 32 bits sur des machines 64 bits, c'est pas à cause de Flash : une application 32 bits peut tourner sur un Windows 64 bits, à commencer par Internet Explorer qui est présent dans les 2 versions sous Vista 64 bits.
C'est bien les pilotes 32 bits (et les vieux progs 16 bits) qui posent problème sur Windows 64 bits.
Moi aussi je vais troller :
Alors quand est-ce qu'on peut développer de façon modulaire avec compilation séparée en Lisaac ?
Non parcque bon le principal soucis du kernel Linux, son côté bloatware, c'est pas tant le fait que le langage utilisé ne propose d'héritage, c'est surtout que l'architecture monolithique retenue en fait un gros bouzin là où les micro-noyaux apporte "bydesign" une plus grande modularité.
Evidemment ca suppose que le langage soit "utilisable" pour cela...
Je suis globalement d'accord avec toi, mais pour relativiser tes propos, il faut tout de même noter qu'il n'y a pas non plus beaucoup d'appli/contenu "critique" en Flash. A part les risques sociaux que tu encours parcque tu n'a pas vu la dernière vidéo kikoolol sur youtube, il est quand même pas si compliqué de vivre sans Flash, alors que tous les jours au taf tu peux avoir des problèmes plus important en refusant d'utiliser un poste Windows.
Il n'y a pas de code Microsoft dans Moonlight (si ce n'est la suite de tests de compatibilité).
Moonlight et Gnash peuvent décoder des vidéos grâce à FFmpeg.
Le plus dangereux, c'est FFmpeg qui implémente des standards archi-blindés de brevets (et dont les licences sont payantes, y'a un modèle commercial derrière).
La FSF pousse Gnash (top 10 des appli prioritaires), dénigre ce qui tourne autour de mono, et oublie de parler de FFmpeg... cherchez l'erreur.
En C# le byte-code est donc bien interprété
Je vois pas le rapport entre le premier et le 2ème paragraphe.
La présence d'une machine virtuelle ou d'un environnement d'exécution ne défini en rien le fait que C# soit interprété.
cette interprétation utilise la technologie JIT qui permet de gagner en performance
JIT est une technique de "compilation", pas d'interprétation.
C'est même dans le nom : http://en.wikipedia.org/wiki/Just-in-time_compilation
je cite : "It converts code at runtime prior to executing it natively, for example bytecode into native machine code. The performance improvement over interpreters originates from caching the results of translating blocks of code, and not simply reevaluating each line or operand each time it is met (see Interpreted language)."
Ce qui se traduit par :
"Il converti le code pendant son déroulement avant de l'exécuter nativement, par exemple il converti le bytecode en code natif. Le gain de performance par rapport aux interpréteurs vient du fait de mettre en cache le résultat de la tranduction de bloc de code plutôt que de réévaluer chaque ligne ou opérateur à chaque fois qu'il le rencontre. (voir langage interprété)."
La compilation et l'interprétation sont 2 techniques différentes pour exécuter du code. Que la compilation se fasse en 2 étapes pour ajouter un niveau d'abstraction (machine virtuelle) ne change rien.
C# est un langage conçu pour être compilé en ciblant la CLI et cette dernière est conçue pour compiler du bytecode en code natif.
Il est possible d'interpréter le bytecode intermédaire, mais l'intérêt est limité. La page de mono sur l'environnement d'exécution décrit bien les différentes techniques utilisées et précise à propos de l'interpréteur : http://www.mono-project.com/Mono:Runtime
"Mono has both an optimizing just-in-time (JIT) runtime and a interpreter runtime. The interpreter runtime is far less complex and is primarily used in the early stages before a JIT version for that architecture is constructed. The interpreter is not supported on architectures where the JIT has been ported. "
Ce qui se traduit par : Mono a un moteur d'exécution optimisé à la volée (JIT) et un interpréteur. L'interpréteur est beaucoup moins complexe et est avant tout utilisé en amont avant qu'une version du moteur JIT pour l'architecture cible soit construit. L'interpréteur n'est pas supporté sur les architectures où le moteur JIT a été porté.
"Contrairement à C# le code n'est pas interprété par une machine virtuelle, c'est un langage compilé."
C# n'a jamais été conçu pour être interprété mais pour être compilé dans un code intermédiaire qui est lui même compilé à la volée (JIT), voir en avance (AOT).
L'interprétation, c'est totalement has been, ca sert uniquement à porter "rapidement" un langage sur une nouvelle plateforme matérielle en attendant une chaîne de compilation native.
Les mauvaises langues diront que les linuxiens se rabattent sur le peu de jeu disponible et que les windowsiens ont des jeux bien plus sexy à acheter pour le même prix.
Ben comme indiqué dans le journal qui cite Nero, le principal "atout" est la gravure de disque Blu-ray. Je sais pas si un soft libre le permet, mais si Nero est bien le seul a le proposer, ca a forcement un intérêt pour les possesseur de ce type de matériel.
Ben on aimerai qu'il représente ses élus, mais concrêtement il vote en âme et conscience, enfin plus généralement il suit les consigne de son parti.
Après la démocratie permet de renouveller les mandats et d'éliminer les "menteurs", enfin quand les électeurs s'en aperçoivent et n'oublient pas.
Non, ce n'est pas la bonne raison : on aurait très bien pu décider de tout mettre en LGPL/GPL
Pas convaincu, d'après ma compréhension tu ne peux pas mettre de code sous GPL/LGPL sur iPhone du tout, puisque l'application doit obligatoirement être signé numériquement. Un soft sous (L)GPL oblige à redistribuer cette clé pour permettre d'utiliser la version modifiée, mais c'est Apple qui détient la clé en question... (sauf jailbreak m'enfin ne pas respecter une licence (Apple) pour en utiliser une autre voilà quoi :))
Donc la véritable question n'est pas de savoir si monotouch doit être libre ou non, mais de savoir si c'est acceptable de faire un produit proprio quand on fait par ailleur la promotion du libre.
Là où je suis d'accord avec Jb, c'est que le modèle de double licence est largement répendu et accepté dans le monde du libre. Là où je ne suis pas d'accord, c'est que monotouch n'est justement pas sous double licence : même si la version sous GPL/LGPL n'est pas "utilisable", elle pourrait toujours être utile pour d'autres développeurs : technique de binding Objective-C par exemple ou façon de s'interfacer avec xcode, etc.
Bref, ca fait vraiment bizzare de voir MDI faire la promotion d'un produit totalement proprio sans version "libre". Je comprends que c'est un choix qui incombe à son employeur, Novell, mais quand même, c'est contraire à tout ce qu'il nous avait habitué.
Se sont-ils contentés d'encapsuler les APIs existantes via une couche Mono/C# ?
En gros c'est ça.
Ils utilisent la compilation AOT (AheadOfTime) pour produire un exécutable natif pour l'iPhone, ce dernier interdisant toute technique de JIT (JustInTime).
A côté ils fournissent un wrapper sur les API iPhone comme ils le font pour GTK ou autre, et un plugin de dev pour l'IDE MonoDevelop.
il a juste dit que c'était destiné à windows
C'est un simple préjugé sans fondement.
Je ne suis pas utilisateur de codeplex, je ne sais pas ce qui conduit ses utilisateurs à le choisir, mais faut croire que certains le choisisse pour faire des trucs pour Linux et pas pour Windows, exemple : http://openblade.codeplex.com/
ou tout simplement multiplateforme par nature : http://pyspec.codeplex.com/
On peut poser exactement la même question avec google code : pourquoi aller sur google code alors que sourceforce et tuxfamily existe ? Il y a sans doute de bonnes raisons puisque des gens font ce choix. C'est pas parcque toi tu vois pas les raisons qu'il n'y en a pas.
c'était de l'humour
Oué mais l'humour c'est plus drôle quand elle a un fond de vérité.
Ben en même temps il parle de la forge CodePlex qui soit disant imposerait Windows, un lien sur la FAQ de la forge en question ca me paraît pertinent non ?
Je ne vois rien sur le site de la fondation qui contredise la FAQ de codeplex...
Consommation mémoire après toutes ces opérations :
PN : 187Mo
TG : 233Mo
Evidemment les applis ne sont pas identiques, TG a sans doute beaucoup plus de fonctionnalités, mais quand même, il semble possible de faire des applis réactives et fonctionnelles avec autre chose que du C.
Ca n'a tout de même rien à voir avec le fait que ce soit un logiciel propriétaire ou non.
Si le format OpenDocument engendrait la violation d'un brevet du même genre par OpenOffice & co, la situation serait identique : obligé d'utiliser un logiciel "illégal" ou avoir des documents "inutilisables".
Le problème, c'est bien les brevets logiciels, et le fait d'utiliser un logiciel libre ou un format ouvert ne protège en rien.
Donc le problème, c'est la suproduction.
Que faire pour résoudre ce problème ?
Soit on laisse le marché "classique" agir en coulant les moins bons (ce qui conduira à équilibrer de nouveau l'offre et la demande), soit on sort totalement du système de marché.
Et comment font-ils pour conserver plusieurs centaines de litres de lait produits chaque semaine pour le vendre litre par litre au particulier qui voudra bien se déplacer jusque là? Sans savoir s'ils vendraient effectivement l'équivalent d'une production journalière chaque jour?
Mais je suis bien conscient de ce qu'apporte une coop par rapport à la vente au détail... Et c'est là tout le problème : on peut pas à la fois choisir le type de client (coop/réseau de distribution) avec tous les avantages que cela apporte tout en choisissant le prix de vente...
En fait ce qu'ils voudraient, si je comprends bien, c'est choisir le client et choisir le prix auquel le client achète, c'est pas un peu fort de café ?
Crois-tu que l'état laisserait distribuer du lait sans aucun doute de «mauvaise qualité» et non traité à ces pauvre gens du peuple au risque de les rendre malades?
Je sais pas, je vais au marché, y'a du lait fermier vendu directement par le producteur, pourtant il se fait pas enmerder.
C'était tout simplement le seul moyen de vivre décemment à une certaine époque où les taux d'intérêts permettaient ces investissements.
On leur a imposé leur métier, on leur a imposé le taille de l'exploitation et on leur a imposé d'investir. Un peu plus et on dirait des machines sans cerveaux.
Les petits ont disparu et les plus grands sont devenus plus grands avec toujours plus de sophistications dans le matériel pour rester compétitif.
Ca sert à quoi d'être compétitif quand t'es pas rentable ?
Je crois que le fond du problème est ailleur : les agriculteurs sont plongés dans une économie de marché, et "subissent" naturellement la politique des prix, ce qui devrait logiquement amener les moins bons dans cette compétition à disparaître, et donc logiquement à faire baisser la production, ce qui conduirait à faire remonter les prix. Les aides faussent tout : les agriculteurs sont aidés pour survivre, la surproduction continue, les prix restent largement bas et les distributeurs peuvent imposer leurs tarifs.
Après on peut trouver cette situation innacceptable (avoir des agriculteurs qui "coulent" comme de vulgaires PME parcque le marché est vorace). Mais dans ce cas faut changer totalement de mode de fonctionnement et pas s'amuser à "aider" les agriculteurs dans le même marché : il faudrait que l'état contrôle la production en assurant un salaire fixe aux agriculteurs.
Un mode beaucoup plus "communiste" mais qui paraît (pour ce type de ressources, ne pas généraliser), la seule façon d'assurer une source de revenus stable aux agriculteurs tout en contrôlant la production.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 3.
Je penses qu'il voulait dire "stabilisé" plutôt que "standardisé" : en gros faut pas qu'il change, ou rarerement.
On peut imaginer une ABI "stable" pendant 3 ans. Au bout de 3 ans une nouvelle version arrive, moyennant un coût supplémentaire le noyau peut gérer l'ancienne qui devient "deprecated" mais qui pête pas les drivers existants. Au bout de 3 nouvelles années, tu vires la vieille interface (on va pas la maintenir 107 ans) : en tout on a eu 6 ans de compatibilité binaire et 3 ans pour migrer les drivers encore maintenus/utilisés.
Ca me paraît totalement réalisable.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Tu réponds pas au problème : pour des questions d'emprunte mémoire, de sécurité, de spécificité matérielle, on a pas envie de charger tout le bouzin en mémoire. Comment en Lisaac je charge dynamiquement des modules en mémoire sans passer par une compilation/déploiement séparée ?
Faut savoir : le principal intérêt de Lisaac, c'est la compil globale qui apporte un gain de perf. Si le code est "modulable" et compilable/déployable séparrement, le compilo peut plus faire son boulot de compilation globale, on perd une bonne partie de l'intérêt de Lisaac.
Lisaac est "bydesign" conçu pour mettre en contradiction les gains de perf avec la modularité du code. Faut vous faire une raison, Lisaac se focalise sur des objectifs qui sont loins des préocupations des développeurs et packageurs.
Peut être que sur de l'embarqué où le kernel n'est pas trop complexe et qu'il y a un seul mainteneur ca peut servir à quelque chose... ou pas.
il y a toujours la possibilité de découper le C en petits bouts, et de coller un .h pour lier le tout.
\o/ J'attend de voir ça dans une équipe de développement et son environnement SVN/GIT+IDE+makefile...
J'attend aussi de voir le débuggueur...
Les langages modernes s'occupe de toutes les problématiques de la réalisation d'un soft, du dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement.
On a l'impression qe Lisaac se focalise uniquement sur le dev et l'exécution.
[^] # Re: approche local vs. globale?v
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 1.
Il faut également pouvoir charger des modules dans des espaces mémoires différents avec des droits différents (séparation userland/kernelland). Tout ca suppose qu'on passe par une autre étape qu'une bonne grosse compilation du bouzin qui contient tout vu quon connait pas la machine cible.
Sans parler que même si ca prend "seulement" 5 minutes à compiler sur ton quadri-coeur de la mort, pour le développeur c'est attroce comme environnement de test/déboggage.
Bref autant de critère qui rend la séparation en module indispensable pour tout gros projet, et un kernel est un gros projet.
[^] # Re: Utilité ?
Posté par TImaniac (site web personnel) . En réponse au journal Gnash: décodage fluide de vidéos Flash HD (H.264). Évalué à 2.
[^] # Re: Utilité ?
Posté par TImaniac (site web personnel) . En réponse au journal Gnash: décodage fluide de vidéos Flash HD (H.264). Évalué à 2.
C'est bien les pilotes 32 bits (et les vieux progs 16 bits) qui posent problème sur Windows 64 bits.
# rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 4.
Alors quand est-ce qu'on peut développer de façon modulaire avec compilation séparée en Lisaac ?
Non parcque bon le principal soucis du kernel Linux, son côté bloatware, c'est pas tant le fait que le langage utilisé ne propose d'héritage, c'est surtout que l'architecture monolithique retenue en fait un gros bouzin là où les micro-noyaux apporte "bydesign" une plus grande modularité.
Evidemment ca suppose que le langage soit "utilisable" pour cela...
[^] # Re: Oui mais ...
Posté par TImaniac (site web personnel) . En réponse au journal HADOPI ... encore :). Évalué à 10.
[^] # Re: Utilité ?
Posté par TImaniac (site web personnel) . En réponse au journal Gnash: décodage fluide de vidéos Flash HD (H.264). Évalué à 3.
[^] # Re: Utilité ?
Posté par TImaniac (site web personnel) . En réponse au journal Gnash: décodage fluide de vidéos Flash HD (H.264). Évalué à 6.
Moonlight et Gnash peuvent décoder des vidéos grâce à FFmpeg.
Le plus dangereux, c'est FFmpeg qui implémente des standards archi-blindés de brevets (et dont les licences sont payantes, y'a un modèle commercial derrière).
La FSF pousse Gnash (top 10 des appli prioritaires), dénigre ce qui tourne autour de mono, et oublie de parler de FFmpeg... cherchez l'erreur.
[^] # Re: C# pas interprété
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Vala 0.7.6. Évalué à 4.
Je vois pas le rapport entre le premier et le 2ème paragraphe.
La présence d'une machine virtuelle ou d'un environnement d'exécution ne défini en rien le fait que C# soit interprété.
cette interprétation utilise la technologie JIT qui permet de gagner en performance
JIT est une technique de "compilation", pas d'interprétation.
C'est même dans le nom : http://en.wikipedia.org/wiki/Just-in-time_compilation
je cite : "It converts code at runtime prior to executing it natively, for example bytecode into native machine code. The performance improvement over interpreters originates from caching the results of translating blocks of code, and not simply reevaluating each line or operand each time it is met (see Interpreted language)."
Ce qui se traduit par :
"Il converti le code pendant son déroulement avant de l'exécuter nativement, par exemple il converti le bytecode en code natif. Le gain de performance par rapport aux interpréteurs vient du fait de mettre en cache le résultat de la tranduction de bloc de code plutôt que de réévaluer chaque ligne ou opérateur à chaque fois qu'il le rencontre. (voir langage interprété)."
La compilation et l'interprétation sont 2 techniques différentes pour exécuter du code. Que la compilation se fasse en 2 étapes pour ajouter un niveau d'abstraction (machine virtuelle) ne change rien.
C# est un langage conçu pour être compilé en ciblant la CLI et cette dernière est conçue pour compiler du bytecode en code natif.
Il est possible d'interpréter le bytecode intermédaire, mais l'intérêt est limité. La page de mono sur l'environnement d'exécution décrit bien les différentes techniques utilisées et précise à propos de l'interpréteur :
http://www.mono-project.com/Mono:Runtime
"Mono has both an optimizing just-in-time (JIT) runtime and a interpreter runtime. The interpreter runtime is far less complex and is primarily used in the early stages before a JIT version for that architecture is constructed. The interpreter is not supported on architectures where the JIT has been ported. "
Ce qui se traduit par :
Mono a un moteur d'exécution optimisé à la volée (JIT) et un interpréteur. L'interpréteur est beaucoup moins complexe et est avant tout utilisé en amont avant qu'une version du moteur JIT pour l'architecture cible soit construit. L'interpréteur n'est pas supporté sur les architectures où le moteur JIT a été porté.
# C# pas interprété
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Vala 0.7.6. Évalué à 7.
C# n'a jamais été conçu pour être interprété mais pour être compilé dans un code intermédiaire qui est lui même compilé à la volée (JIT), voir en avance (AOT).
L'interprétation, c'est totalement has been, ca sert uniquement à porter "rapidement" un langage sur une nouvelle plateforme matérielle en attendant une chaîne de compilation native.
# mauvaises langues
Posté par TImaniac (site web personnel) . En réponse au journal Indie game surpris par les ventes de la version Linux de son jeu. Évalué à 9.
[^] # Re: En même temps
Posté par TImaniac (site web personnel) . En réponse au journal Sortie de Nero Linux 4. Évalué à 3.
[^] # Re: mailto:cgoasguen@assemblee-nationale.fr
Posté par TImaniac (site web personnel) . En réponse au journal Hadopti II adopé. Évalué à 2.
Après la démocratie permet de renouveller les mandats et d'éliminer les "menteurs", enfin quand les électeurs s'en aperçoivent et n'oublient pas.
[^] # Re: Ce n'est pas sale de se MonoToucher
Posté par TImaniac (site web personnel) . En réponse au journal Miguel, iPhone et développement. Évalué à 4.
Pas convaincu, d'après ma compréhension tu ne peux pas mettre de code sous GPL/LGPL sur iPhone du tout, puisque l'application doit obligatoirement être signé numériquement. Un soft sous (L)GPL oblige à redistribuer cette clé pour permettre d'utiliser la version modifiée, mais c'est Apple qui détient la clé en question... (sauf jailbreak m'enfin ne pas respecter une licence (Apple) pour en utiliser une autre voilà quoi :))
Donc la véritable question n'est pas de savoir si monotouch doit être libre ou non, mais de savoir si c'est acceptable de faire un produit proprio quand on fait par ailleur la promotion du libre.
Là où je suis d'accord avec Jb, c'est que le modèle de double licence est largement répendu et accepté dans le monde du libre. Là où je ne suis pas d'accord, c'est que monotouch n'est justement pas sous double licence : même si la version sous GPL/LGPL n'est pas "utilisable", elle pourrait toujours être utile pour d'autres développeurs : technique de binding Objective-C par exemple ou façon de s'interfacer avec xcode, etc.
Bref, ca fait vraiment bizzare de voir MDI faire la promotion d'un produit totalement proprio sans version "libre". Je comprends que c'est un choix qui incombe à son employeur, Novell, mais quand même, c'est contraire à tout ce qu'il nous avait habitué.
# ouaip
Posté par TImaniac (site web personnel) . En réponse au journal Miguel, iPhone et développement. Évalué à 10.
En gros c'est ça.
Ils utilisent la compilation AOT (AheadOfTime) pour produire un exécutable natif pour l'iPhone, ce dernier interdisant toute technique de JIT (JustInTime).
A côté ils fournissent un wrapper sur les API iPhone comme ils le font pour GTK ou autre, et un plugin de dev pour l'IDE MonoDevelop.
[^] # Re: Lire entre les lignes
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft lance la fondation CodePlex. Évalué à 1.
C'est un simple préjugé sans fondement.
Je ne suis pas utilisateur de codeplex, je ne sais pas ce qui conduit ses utilisateurs à le choisir, mais faut croire que certains le choisisse pour faire des trucs pour Linux et pas pour Windows, exemple :
http://openblade.codeplex.com/
ou tout simplement multiplateforme par nature :
http://pyspec.codeplex.com/
On peut poser exactement la même question avec google code : pourquoi aller sur google code alors que sourceforce et tuxfamily existe ? Il y a sans doute de bonnes raisons puisque des gens font ce choix. C'est pas parcque toi tu vois pas les raisons qu'il n'y en a pas.
c'était de l'humour
Oué mais l'humour c'est plus drôle quand elle a un fond de vérité.
[^] # Re: Lire entre les lignes
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft lance la fondation CodePlex. Évalué à 2.
Je ne vois rien sur le site de la fondation qui contredise la FAQ de codeplex...
[^] # Re: Lire entre les lignes
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft lance la fondation CodePlex. Évalué à 1.
Il n'y a aucune contrainte sur l'OS :
http://codeplex.codeplex.com/Wiki/View.aspx?title=CodePlex%2(...)
[^] # Re: Langage plus sûr?
Posté par TImaniac (site web personnel) . En réponse au journal Un coup de gueule contre Gimp 2.6. Évalué à 7.
Lancement de l'appli :
PN : 3s
TG : 6s
Consommation mémoire après lancement :
PN : 32Mo
TG : 23Mo
Chargement de la photo (800ko, 2048x1536)
PN : 1s
TG : 2s
Retaillage en 4096x3072 (bicubique)
PN : 7s
TG : 10s
Passage en N&B :
PN : 3s
TG : 3s
Enregistrement du résultat (jpg, qualité 89) :
PN : 2s
TG : 2s
Consommation mémoire après toutes ces opérations :
PN : 187Mo
TG : 233Mo
Evidemment les applis ne sont pas identiques, TG a sans doute beaucoup plus de fonctionnalités, mais quand même, il semble possible de faire des applis réactives et fonctionnelles avec autre chose que du C.
[^] # Re: Pas d'accord
Posté par TImaniac (site web personnel) . En réponse à la dépêche Microsoft Office interdit aux USA ?. Évalué à 3.
Si le format OpenDocument engendrait la violation d'un brevet du même genre par OpenOffice & co, la situation serait identique : obligé d'utiliser un logiciel "illégal" ou avoir des documents "inutilisables".
Le problème, c'est bien les brevets logiciels, et le fait d'utiliser un logiciel libre ou un format ouvert ne protège en rien.
[^] # Re: Je déteste le lait industriel ...
Posté par TImaniac (site web personnel) . En réponse au sondage La date de péremption des produits laitiers. Évalué à 3.
[^] # Re: Je déteste le lait industriel ...
Posté par TImaniac (site web personnel) . En réponse au sondage La date de péremption des produits laitiers. Évalué à 2.
Que faire pour résoudre ce problème ?
Soit on laisse le marché "classique" agir en coulant les moins bons (ce qui conduira à équilibrer de nouveau l'offre et la demande), soit on sort totalement du système de marché.
[^] # Re: Je déteste le lait industriel ...
Posté par TImaniac (site web personnel) . En réponse au sondage La date de péremption des produits laitiers. Évalué à 3.
Mais je suis bien conscient de ce qu'apporte une coop par rapport à la vente au détail... Et c'est là tout le problème : on peut pas à la fois choisir le type de client (coop/réseau de distribution) avec tous les avantages que cela apporte tout en choisissant le prix de vente...
En fait ce qu'ils voudraient, si je comprends bien, c'est choisir le client et choisir le prix auquel le client achète, c'est pas un peu fort de café ?
Crois-tu que l'état laisserait distribuer du lait sans aucun doute de «mauvaise qualité» et non traité à ces pauvre gens du peuple au risque de les rendre malades?
Je sais pas, je vais au marché, y'a du lait fermier vendu directement par le producteur, pourtant il se fait pas enmerder.
C'était tout simplement le seul moyen de vivre décemment à une certaine époque où les taux d'intérêts permettaient ces investissements.
On leur a imposé leur métier, on leur a imposé le taille de l'exploitation et on leur a imposé d'investir. Un peu plus et on dirait des machines sans cerveaux.
Les petits ont disparu et les plus grands sont devenus plus grands avec toujours plus de sophistications dans le matériel pour rester compétitif.
Ca sert à quoi d'être compétitif quand t'es pas rentable ?
Je crois que le fond du problème est ailleur : les agriculteurs sont plongés dans une économie de marché, et "subissent" naturellement la politique des prix, ce qui devrait logiquement amener les moins bons dans cette compétition à disparaître, et donc logiquement à faire baisser la production, ce qui conduirait à faire remonter les prix. Les aides faussent tout : les agriculteurs sont aidés pour survivre, la surproduction continue, les prix restent largement bas et les distributeurs peuvent imposer leurs tarifs.
Après on peut trouver cette situation innacceptable (avoir des agriculteurs qui "coulent" comme de vulgaires PME parcque le marché est vorace). Mais dans ce cas faut changer totalement de mode de fonctionnement et pas s'amuser à "aider" les agriculteurs dans le même marché : il faudrait que l'état contrôle la production en assurant un salaire fixe aux agriculteurs.
Un mode beaucoup plus "communiste" mais qui paraît (pour ce type de ressources, ne pas généraliser), la seule façon d'assurer une source de revenus stable aux agriculteurs tout en contrôlant la production.