reno a écrit 3881 commentaires

>C'est pour ça que j'ai choisi d'acheter un portable avec carte NVIDIA. Pour l'instant c'est ce qu'il y a de mieux question compatibilité.

Tiens? Moi j'aurais dit Intel..

OK, je comprends mieux, merci pour la clarification.

Si c'est le même port, alors il n'y a pas de probleme de patente: Sun met a disposition les patentes correspondant (je sais plus si c'est intégré dans la CDDL ou si c'est un accord indépendant).

Ce que je ne comprends pas trop, c'est que la dernière l'explication de l'arret du dev était un probleme de license, je ne vois pas comment continuer a faire du dev peut résoudre un probleme de license, bah on verra bien..

Merci pour l'information, mais je me demande bien pourquoi il fait ça:
-si je comprends bien c'est une réimplementation en BSD et plus un port du code CDDL, c'est donc une forme de 'reverse engineering' et comme c'est le même gars qui avait fait le port, il prend un risque: ce n'est clairement pas du 'clean room' reverse engineering puisqu'il avait fait le port..

-il reste alors le problème des patentes: Sun en a sur ZFS, j'imagines que Sun en a aussi sur Dtrace et en tant que réimplementation, ce n'est plus couvert par l'accord de licence de Sun..

Je me demande si FreeBSD va intégré la nouvelle version.

La seule chose qui limite le risque d'attaque de Sun, c'est que du point de vue 'image', ce serait désastreux pour Sun, s'ils attaquaient le developpeur ou FreeBSD..

>le projet FreeBSD a décidé de porter Dtrace vers son propre environnement

Le projet FreeBSD a effectivement porté Dtrace, mais par contre ils ne l'ont pas intégré dans leur dernière version car ils ne veulent pas intégré de code non BSD dans leur noyau et les header de Dtrace sont en CDDL (ils ont demandé a Sun de changer la licence des header, sans résultat).

Après il y a eu un 'débat' avec les dev de Sun qui considèrent eux que la license de fichier header n'a pas d'importance, je ne suis pas juriste donc j'ignore qui a raison mais en tout cas FreeBSD n'a pas intégré Dtrace dans leur dernière version..

Un autre point gênant de Dtrace est que pour profiter au maximum de Dtrace, il faut rajouter une instrumentation des interpréteurs(VM), GC, etc.
Quand Linux aura son propre mécanisme, j'imagine que ça veut dire qu'il faudra dupliquer ce code pour avoir la même chose, <soupir/>..

Tout d'abord, bravo pour la grande qualité de cette dépeche.

Juste une petite correction mineure, il faudrait traduire 'scatter/gather' par Dispersion/Rassemblement et pas Rassemblement/Dispersion.

>Faut pas voir le mal partout. C'est la GPL qui interdit d'intégrer du code sous CDDL, pas l'inverse.

Hein, la chronologie tu connais??

La GPL était écrite bien avant que la CDDL soit écrite, c'est donc en toute connaissance de cause que les gars de chez Sun ont crée une license incompatible avec la GPLv2 (déjà utilisée par la *majorité* des projets libres).

En faisant cela, ils divisent la communauté existante, pour aucune raison valable a ma connaissance, juste limiter les échanges avec d'autres logiciels afin de ne pas risquer pas d'être submerger par eux..


Les licenses BSD, GPLv2, GPLv3 divisent aussi les communautés des developpeur libres mais c'est pour des raisons philosophique, pas pour 'défendre son beurre' (enfin pas uniquement).

Pas forcement en GPL, mais dans une license compatible avec la GPL, oui.

>En 4 ans de dev Java, j'ai jamais vu un GC se planter et liberer quand il ne fallait pas ou ne pas liberer quand il fallait.

Il ne fait jamais dire jamais :-) :
en 99, j'ai eu un bug du GC de la JVM Sun qui libérait des objets quand il ne le fallait pas (il ne prenait pas en compte les references statiques).

Assez pénible ce bug d'ailleurs car il induisait un plantage aléatoire de mon prog..

783 sur combien?

Je me souviens que dans la news, il y avait au moins un developpeur qui était contre le passage a la GPLv3.

L'article est plutôt curieux: pour autant que je sache il n'y a aucun rapport entre jack et LatencyTop..

Non: en D "par défaut" tu utilise un GC, mais en cas de besoin tu peux faire de l'allocation manuelle et utiliser des pointeurs..

Les GC ne sont pas forcément le bon outil dans toutes les situations (même si par défaut c'est plus raisonnable d'utiliser un GC que de gerer soi-meme la mémoire).

Et alors?
La GPL non plus n'est *pas* libre pour tous usage: fermer les sources et revendre, c'est aussi un usage, non autorisé par la GPL ou la license de MySQL, de Berkeley DB, etc.

Je suis tout a fait d'accord avec la philosophie de la GPL, mais il ne faut pas pour autant dire qu'elle est "libre pour tous usage": c'est incorrecte..

Tu peux dire 'libre pour tous usage respectant la liberté du code et de ses dérivés' si tu veux mais pas juste 'libre pour tous usage'..

>usr signifie Unix System Ressource (j'admets c'est pas completement evident)

Je me demande si ce n'est un acronyme qui a été fait 'après coup': certains Unix avaient leur /home dans /usr (users) et depuis que ça a été changé, le sens de /usr a été changé mais bof.

>sbin signifie System Binary (qui pour le coup dit bien ce qu'il fait).
Uniquement quand on sait!
Un truc du genre /System/Binary tout le monde comprend par contre, pas besoin de mode d'emploi..

>Je pense au contraire que la hiérarchie de système unix correspond à des choix réfléchis et intelligent.

Ah? Moi, j'ai plutôt l'impression qu'elle a évolué beaucoup de manière assez anarchique avec pour contrainte principale la compatibilité entre les divers Unix et les applications, sans tenir compte d'une quelconque cohérence pour l'utilisateur et que le résultat est assez bordélique..

>sbin devrait contenir des utilitaires permettant la configuration du système.

Bof, pas très intuitif comme nom, tellement que tu est obligé de l'expliquer! Pareil pour /usr, c'est evidemment l'endroit ou on stockes les programmes \o/..

Sinon je suis d'accord avec toi que le 'rm -rf' pour effacer un package n'est pas une bonne idée a cause des librairies en dépendance et ce quelque soit la hierarchie.

>Notons au passage qu'une de vos critiques du FHS c'est de retrouver nos fichiers. Il est vrai qu'il est facile de deviner que ping est caché dans Netkit ou que ls va se trouver cacher dans CoreUtils ...

Très bonne remarque, je me demande si toute hiérarchie n'est pas fondamentalement défectueuse et si on ne devrait pas passer par un système de gestion par "étiquette", au départ je pensais que ce n'était utile que pour gérer les photos, mais par exemple ping serait marqué 'exécutable' et 'package: Netkit' donc dans la vue 'exécutable' tu verrais ping et dans la vue package tu verrais netkit/ping..

En fait avec les divers systèmes de liens, on 'simule' ce comportement mais forcément de manière rudimentaire.

Mouai, il faut se méfier avec les arguments de popularité, autrement logiquement t'arrive au 'ya qu'a utiliser Windows'!

La vrai question est plutot REBOL est-il un meilleur langage de script que zsh ou Ruby?

>L'utilisateur voit sa petite maison et c'est tout ce qu'il devrait avoir à voir.

1) Tu présuppose que tout marche parfaitement, et quand ce n'est pas le cas?
Ce n'est pas si rare malheureusement, pour se débrouiller il vaut mieux avoir un environnement cohérent, facile a decouvrir.

2) Il y a certains cas ou la ligne de commande est plus utile que l'interface graphique, dans ce cas la il est bien agréable d'avoir une hiérarchie de fichier qui est logique!

> augmenter d'un niveau d'indirection tous les chemins

Moi je vois ça comme une étape vers une organisation plus cohérente, a terme on pourrait evoluer vers une installation directe dans les bon repertoire avec moins de liens..

>En quoi cette hiérarchie à t-elle plus de sens ? Et pour qui ?

Pour tout le monde!

Prend quelqu'un qui ne connait pas Unix ou Windows, montre lui les deux arborescence celle d'un Linux normal et celle de GoboLinux, demande lui laquelle est plus simple, plus intuitive?
La réponse sera celle de GoboLinux.

J'aime bien l'idée de laisser tomber des complications inutiles qui existent juste pour des raisons de compatibilité avec l'existant..

>C'est une philosophie différente d'organisation, d'accord, mais qu'elle ait plus de sens me dépasse.

Bah, c'est juste que tu es tellement habitué a l'arborescence Unix que tu ne vois pas a quelle point elle est ridicule: etc pour la configuration, usr pour les programmes..

Euh, on n'est pas aux US! Je n'ai eu aucun probleme a trouver mon Asus P526 sans countrat..

Soit dit en passant Windows Mobile6, c'est de la m..., mais TomTom est pas mal: est-ce que ça existe des bons logiciels de navigation GPS avec carte, radar pour Linux?

Dans ce cas la, Scala == 2!

Acces a la plateforme Java ET une syntaxe propre (et pas trop verbeuse comme celle de Java).

Tu as tord, j'aime bien le parachutisme aussi!

>>Un bon développeur fera toujours du bon code quelque soit le langage.<<

Certes mais il n'apprécie pas pour autant forcément le langage..

Je me considère comme un bon programmeur, je connais suffisamment de Perl pour faire des programmes propres (c'est à dire qui fonctionnent et qui soient compréhensibles*), mais je peux te dire que quand je dois programmer en Perl, qu'est-ce que je peut le maudire ce langage!

Le coup des tableaux qu'il faut passer par référence a une fonction pour qu'on puisse récupérer leur contenu sans les mélanger et bien d'autres trucs me dégoute..


(*) enfin autant que possible avec ce langage..

Pourquoi il faut ajouter les __ dans la deuxième version en Python?

>>- Pas de support de l'Unicode, qui est pour moi _le_ plus gros problème de Ruby.<<

Bin d'après la nouvelle c'est aussi dans la 1.9 (cf la partie sur m17n) mais je n'ai pas réussi a trouver l'info dans le changelog..
Ceci dit tant que ce n'est pas dans une version stable, ça ne fait pas trop avancer le schmilblick..

Sinon le @ de Ruby n'a rien a voir avec le @ de Perl, donc je ne vois pas pourquoi tu les compare.

Je fais partie de ceux qui trouve que les self partout c'est laid: le concept "explicit is better than implicit", si tu l'applique jusqu'au bout tu programmes sans GC, voire en assembleur(!), ce qui montre bien, qu'il faut être sélectif dans son application..

Pour ta question, oui Ruby avait du mal a décoller avant RoR, mais ce qui fait la force de RoR c'est Ruby..

Il y a principalement deux choses que je n'aimais pas avec OCaml:
- l'accent mis sur le coté fonctionnel: pour un langage soi-disant multi-paradigme, le manuel (soit dit en passant le manuel était en Français, c'est rare) mettait bien trop l'accent sur le coté fonctionnel a mon gout..

- la syntaxe, et apparemment je ne suis pas le seul a ne pas l'aimer car il y en a une autre qui existe et Microsoft pour faire F# en a pris encore une autre (qui a l'air pas mal du tout celle la)..


Donc ces obstacles m'ont rebuté pour apprendre le langage, mais je ne considère pas pour autant qu'OCaml soit un mauvais langage, juste pas interressant pour moi (par contre je considère Perl5 comme un mauvais langage)..