Nicolas Boulay a écrit 15824 commentaires

C'est bien pour cela que je demandais pour la GPL ...

"La première sécurité est la liberté"

Disons qu'il n'y a rien qui viole la loi de conservation de l'énergie dans le traitement de l'information.

Ce qui fait marché un transistor, c'est le potentiel. Si l'intensité est nul, il n'y a pas de consomation mais il y a tout de même traitement de l'information.

"La première sécurité est la liberté"

GPL pas lgpl à prioris.

"La première sécurité est la liberté"

C'était le discours du stand MySQL a Solution Linux. Ils ne font qu'utiliser la GPL.

"La première sécurité est la liberté"

Le link est un cas pratique mais il y en a d'autres. MySQL par exemple, est un serveur, et pourtant la GPL s'applique aussi sur les applications qui l'utilisent directement.

Il n'y a pas de link mais pourtant ton application a besoin de MySQL, c'est donc un travail dérivé.

"La première sécurité est la liberté"

Trouves dans la gpl l'endroit ou l'on parle de bibliothèque ou de notion de link, je suis curieux...

"La première sécurité est la liberté"

Cela fait un moment que je veux écrire un programme de chasse au doublon. Le problème est qu'il ne faut pas simplement les détecter car il est impossible de traiter 50 fichiers à la main. Le mieux serait d'effacer une copie et de faire un lien en dur.

Si le système détect aussi des arborescences complètes recopié, cela serait bien aussi (vous savez ce genre de sauvegarde fait avant une réinstall, sauvegarde qui contient aussi la sauvegarde précédente...)

"La première sécurité est la liberté"

Les pertes d'énergies sont lié à des pertes en ligne à des "défaults" mais dans l'absolue, les processeurs pourrait consommer aucune énergie.

Dans un procédés cmos, il y a des fuites globals d'un peut partout. Forcément, des isolants de quelques atomes d'épaisseurs, c'est pas top.

Ensuite, le principe même du cmos, entasse des charges électrique sur une grille pour faire basculer son état. Cette accumulation devient une capacité parasite dont la charge fini par être évacuer. Donc, plus elle est petite mieux c'est. (sauf pour la DRAM, puisque c'est justement le point mémoire).

Donc, si tu fais des transistors avec une capacité parasite proche de zéro, des fils sans résitance (supraconducteurs) et sans fuite, tu pourrais théoriquement faire des cpus avec une conso de zéro.

"La première sécurité est la liberté"

Il n'y a pas de notion de "link" dans la GPL. Uniquement une notion de "travaux dérivés".

Il peut y avoir des travaux dérivés de la la lib standard. Mais un compilo ne génère jamais du travail dérivé. Je ne voix d'ailleurs pas de quel exception tu parles pour libstd++. Elle n'est pas simplement sous lgpl ?

La LGPL définit une sorte de périmètre/module autour de la lib. Je pense qu'il est clair que l'utilisation d'une collection dans un code, ne contamine pas le code en question puisque l'on ne touche pas à la signification de la dite collection.

"La première sécurité est la liberté"

Par définition, du libre non commercial n'est _pas_ du libre.

Les clauses nc empèchent de faire des distributions type mandriva, red hat, suse. Ils empèchent de distribuer les binaires dans une révue. Il empèche de diffuser sur des sites web qui vivent de la pub. Bref, c'est quasi ingérable à redistribuer, ce qui est un des points majeurs du libre.

Alors, certe, tu peux me dire que l'on peut demander. Mais l'un des points fort du libre, c'est justement que l'on a pas besoin de demander ! J'imagine bien Mandriva gérer un contact avec les détenteurs des copyrights des 16000 logiciels de leur distrib...

"La première sécurité est la liberté"

Il faudrait demander à des sites comme presence-pc qui font réguilèrement des évaluations de FAI d'inclure ses FAI de résidences étudiante. Parce que un nouveau venu n'en a jamais entendu parlé. N'oubliez pas de leur faire leur pub sur les affichages publiques des résidence de se genre de problème.

"La première sécurité est la liberté"

essayes -Os pour gcc. Il faudrait voir sur des fonctions plus réaliste, ici, c'est trop court.

"La première sécurité est la liberté"

Lisaac c'est à 99% Ben. Mais maintenant, il faut une infra de test et écrire la lib standard. C'est du boulot moins haut niveau donc plus abordable.

"La première sécurité est la liberté"

tu as bien compris la philo de Lisaac :)

"La première sécurité est la liberté"

un trie à bulle est bon si les élements ne sont pas trop en désordre.

"La première sécurité est la liberté"

F1, 750 ko , serrer ?

J'avais eu une conf d'un vague présentation du système par un ingénieur renaut qui se faisait brider en live sur ce qu'il pouvait dire.

Mais en gros, j'en avais déduit qu'il devait avoir une dizaine de ppc. Donc 750ko me parait petit :)

"La première sécurité est la liberté"

Lisaac n'arrivera jamais à ce niveau d'optim. Il fait simplement un meilleur boulot sur un code propre que gcc. Si tu commences à optimiser à mort un code C, c'est un peu comme si tu recodais en assembleur.

"La première sécurité est la liberté"

Je ne vois pas trop le problème en fait ? Je sais que c'est une des raisons qui fait que Linus haie le c++ (de la gestion mémoire derrière son dos) mais je ne sais pas trop les détails.

Fondamentalement qu'est-ce qui gène ? Le fait que d'habitude, on ne sais pas quand toute la mémoire sera pleine, ce qui empèche de bien tout utiliser ?

"La première sécurité est la liberté"

Mais Delphi ne proposait pas tous ces services, c'est donc difficilement comparable.

Bah si. Quand tu veux un truc simple, c'est plus lent que le "vieux truc"', à cause de fonctionnalité dont tu n'as pas besoin.

"La première sécurité est la liberté"

Ok. Je pensais à la carte à puce qui gère la sécurité. Y'a pas de jvm dessus, j'ai aussi bossé dessus :)

"La première sécurité est la liberté"

Je ne connais plus les chiffres de vente des µp 16 bits et des petits 32 bits arm. Je crois que l'on est pas loin du milliards. C'est sans commune mesure avec un téléphone ou autre.

Tu annonce 30 et 170KB, cela ne fait pas beaucoup sauf que les µP 16 bits on difficilement plus de 64KB de mémoire.

pour le bytcode, certe pour mettre sur la pile, tu utilies un mot d'un octet, et minimum 2 octets pour du x86, mais si tu fais une addition entre 2 nombres ailleurs dans la pile, sur x86, cela prendra toujours 2 octets mais combien en byte code java pour manipuler la pile et mettre les valeurs au bon endroit ?

Concernant la mise à jour de code, tu peux tout à fait patcher du binaire. Il n'y a pas vraiment de différence. La difficulté sera toujours la même : comment gérer les données des classes modifiés.

"La première sécurité est la liberté"

D'ailleurs la mise à jour par sattelite, cela existe depuis toujours pour le système de protection de canalsat. Et ce n'est pas une JVM.

"La première sécurité est la liberté"

Pareil + gqiew pour visualiser rapidement les photos rangés à la main.

"La première sécurité est la liberté"

Le marché que tu décris ne représente rien en volume par rapport au reste.

Il y a beaucoup de blabla autour de java pour l'embarqué mais très peu d'application réelle. Rien que la RAM nécessaire en plus est un frein.

Sinon, je ne voix pas pourquoi le ByteCode serait plus compact, et de plus, jene voix pas l'interet surtout quand tu as une énorme JVM derrière.

"La première sécurité est la liberté"

Puisque vous dites que vous ciblez l'embarqué, certains equipements necessitent une mise-a-jour logicielle. Il y a clairement un avantage a utiliser un langage produisant du ByteCode pour effectuer ces mises-a-jour

euh... HEIN. Il est fou. On se fait chier à produire du code rapide pour avoir la plateforme moins chère possible et il veut mettre une VM ?!

Du bytecode pour l'embarqué, c'est la meilleur de l'année. Surtout pour des mises à jour, c'est encore pire. (ps:je ne vois pas bien le rapport)

Ca s'est bien amélioré mais ca ne l'a pas empéché d'avoir percé.

Java misait sur une autre approche que Lisaac : sa lib pour gagner du temps.

Lisaac vise autre chose. Plus tangible en plus.

"La première sécurité est la liberté"