Delahaye Matthieu a écrit 118 commentaires

Peut être parce que la rapidité compte ?
D'après la courte présentation de la notation, c'est plus ou moins au bon vouloir des juges.

Cependant il y eu une époque ou la rapidité permettait de départager les applications ayant les même fonctionnalités.

Tout est relatif

Effectivement, je n'ai pas dit que c'était le plus lisible.

Pour avoir visité ces pages ces dernières années, ce n'est pas seulement le cas pour l'année passée mais pour les autres aussi. J'en était arrivé à la conclusion qu'en gros c'était presque un concours de Caml mais rien ne t'empêchait d'utiliser un autre langage, histoire d'essayer de mettre en défaut Caml ou O'Caml.

C'est vrai que lorsque tu es sous pression, ici faire du ray-tracing, Caml et O'Caml sont assez prédestinés. Tu t'affranchis de la gestion des structures de base et en plus le compilo te tape sur les doigts si tu n'as pas traité tout les cas... Ca permet d'éviter pas mal d'erreurs de base.

Et puis c'est vrai que c'est très lisible. Utile quand tu programmes en équipe et que tu n'as pas le temps de passer trop de temps à comprendre ce qu'a fait l'autre.

Maintenant, je sais pas si ton "signe" s'adresse au langage lui-même ou à la license du compilo, qui sont logiquement deux choses distinctes même si dans ce cas il me semble que l'on a pas trop le choix.

s'agit de s'entendre sur une norme, et là y'a de quoi être pessimiste.

La LFS est censé gérer ce pb. Je dis bien censé car il s'agit d'un ensemble de règles précisant ou doit se positionner chacun des fichiers, en fonction de leur nature et de leur fonction. Le problème est que ces règles sont à la libre interprétation de chacun de nous (un peu comme les lois parfois).

Quoi qu'il advienne, même si d'une distrib à une autre, les fichiers ne sont pas au même endroit, il est tout de même apréciable d'avoir au sein d'une même distribution une certaine constance quand au placement des fichiers. Je peux pas affirmer que ce soit le cas dans toutes les distributions mais au moins c'est le cas sur celle que j'utilise (je tairais le nom pour éviter toute accusation de tentative de troll).

Ce qui me choque aussi est d'entendre que Linux n'a pas besoin d'argent pour survivre.

C'est vrai si l'on ne tient pas compte des donations, pas forcement monétaires. Quand je viens sur linuxfr, lit une page web sur un logiciel libre, ou tout simplement récupère un logiciel depuis un serveur FTP, j'espère que personne ne m'empêchera de penser qu'il se cache derrière tout ca au moins une machine et une connection internet. Tout cela a un coup.

Et quand bien même ce n'est pas la même personne qui paye et qui met à disposition ce logiciel, cette page web et autre, si il n'y avait pas eu ces âmes "généreuses" pour libérer des ressources matérielles ou financières, je pense que jamais je n'aurais pu envoyer ce post avec une machine 100% ll.

Ici j'argumente seulement avec les pages web, mais je pourrais aussi rajouter les machines fournies par les constructeurs pour faire tourner Linux sur ces architectures. Quel que soit l'intêret d'une telle démarche pour ce constructeur, cela a aussi un coût et la communauté en bénéficie.

clairement, debian n'est pas une distribution sur le modele "bazaar",[...]On est plutot du cote de la cathedrale

Je crois qu'on parle de la structure du projet Debian comme étant un Bazaar de petites cathédrales.

T'as oublié de préciser que la Suisse n'était pas dans l'UE, et donc encore moins à l'euro. En prévision d'un hypothétique post à propos d'une revue anglaise, ils ne sont pas passés à l'euro non plus.

Je pense qu'il n'y a pas que le format des packages (et la pluralité des rpms) qui alimentent l'opposition entre les .deb et les .rpm. Il y a aussi le soin apporté à la conception de ces packages eux mêmes.

Cela fait plusieurs fois que je lis ces derniers jours que les .deb permettraient d'avoir une distrib plus facile à maintenir que les autres. Je pense aussi que c'est du aux personnes qui préparent les packages et qui se cassent la tête parfois pour les faire correctement.

En soit un package ne vaut rien. C'est la façon dont le contenu va s'intégrer dans la distrib qui compte réellement.

Je pense pas que le rpm soit mauvais, mais qu'il bénéficie d'une mauvaise publicité suite à de malheureux packages mal fait...

Je crois que c'est la première fois qu'un logiciel sera ainsi libéré (et sauvé)

Y a pas eu une histoire avec le navigateur Netscape il y a quelques années. Mais là fallait pas payer. Bon d'accord c'était pas du GPL, mais je pense que la "première" s'attribue plus à Netscape qu'à blender...

Quelqu'un sait si il y avait eu des antécédents à Netscape. Un peu d'histoire de LL?

Puffin est régi par une licence (très) libre.
C'est une license BSD (dixit sourceforge, n'ai pas trouvé de fichier de license et pas d'info dans les quelques sources parcourues), pourquoi ne pas le dire directement...

Donc en cas d'OS different, java se justifie.
Ok pour l'interfacage avec le noyau, pas pour le compilateur. gcc/g++ n'est pas une exclusivité Linux. J'arrive a faire fonctionner gcc/g++ sous HP-UX.

Ton source C/C++ écrit pour être compilé avec gcc/g++ sera portable si il est "compatible" avec l'environnement GNU (glibc...) et si il existe un environnement GNU sur l'OS cible. L'environnement GNU se retrouve aussi bien sous Linux, HURD, d'autres OS libres et d'autres OS propriétaires.

Donc, la stratégie de Mandrake ne se fait pas au fil du vent mais est mûrement réfléchie.

On peut aussi parler de la version 12 avec Gnome 4, Kde 5 et le kernel 2.8.0, ca n'en fait pas une stratégie réflechie.

Elle a bénéficié de beaucoup plus de versions beta et RC que les précédentes.Espérons que la 9.0 aura encore plus de versions de test de façon [...]

Signe de doute quand à la stratégie réflechie ?

Désolé, je peux pas mettre -10 d'office.

Pour les machines à base d'Itanium:
RedHat,Mandrake,MSC,Suse,Debian,HP-UX et Windows 64bits
Y en a vraiment pour tous les goûts.

Si les releases sont moins fréquentes c'est surtout du au fait que théoriquement, dans le meilleur des mondes, une fois la release stable sortie, il n'y a plus de release à faire.

Si il n'y avait pas eu de problème sur le 2.4.0, il n'y aurait pas eu de 2.4.1 et ainsi de suite. La série 2.4 comme se fut le cas pour la 2.2 et surement aussi pour la 2.6, sont des releases "stables" qui n'ont pas pour vocation de jouer à la course des nouvelles fonctionalitées, mais plutôt à la stabilitée.


Il arrive de temps en temps que l'on rajoute une nouvelle fonctionalité en milieu d'une release stable car on estime qu'elle apporte suffisement de fonctionalité (ou rapidité) pour coût d'intégration faible (fonctionalité ultra-localisée).

Je trouve pour ma part plutot rassurant que le 2.4.19 ne soit toujours pas sorti. Ca signifie que le kernel 2.4.18 que j'utilise n'est pas trop buggé.

Juste une info:
Pour parentis, je sais pas mais pour Lacq, j'étais en primaire que l'on me disait que les réserves de Lacq étaient épuisées. Je suis repassé devant il y a quelques semaines, ça tourne toujours.
On dit qu'une réserve est épuisée lorsqu'il n'y a plus assez de pression pour que le pétrole/gaz remonte à la surface. Il y a 10 ans, on atteignait ce stade après avoir puisé 30-40% du contenu, soit moins de la moitié... Ca a un peu progressé depuis.

Voila, voila. Une petite contribution qui n'a rien à voir avec Linux. Paf -1

Pour le problème 2, ce qu'il décrit est chiant en serveur

Je vais peut-être me faire traiter d'intégriste, mais théoriquement un serveur n'est jamais censé redemarrer. Si c'est le cas, il est bon d'être à coté pour voir ce qu'il s'est passé.

Certes, un système de fichier journalisé est un moyen de palier à ce problème, mais juste palier. Si t'as un crash, ok ton système de fichier n'est pas corrompu, mais t'as aucune certitude quand à l'intégrité du contenu de tes fichiers. Ca dépend du moment où ton application a été arrêté. L'unique solution c'est un onduleur avec une liaison série et un shutdown propre.

Tout ça pour dire que devoir taper son mot de passe, relancer fsck, c'est rien comparé à ce que tu risques à coté. Le plus simple étant de tout faire pour que le fsck ne se reveille pas au démarrage.

OSS est limité, et ALSA souffre clairement du fait qu'il n'est pas l'API standard sous Linux (car le module de compatibilité OSS est loin d'être parfait et pose problème parfois).

Pour l'API standard, c'est en train de changer. Je dois réecrire un driver son qui était en API OSS sous 2.4.x et qui doit être en API alsa sous 2.5
Information à vérifier, j'ai été averti du besoin de réécriture indirectement.

En alternative, il y a printtool. C'est un outils avec un interface Tk. C'est vraiment simple à utiliser (meme pour les drivers).

Il existe sous Debian, mais vu que le titre de la fenêtre est "Red Hat Linux Print System Manager", pas besoin de réflechir longtemps pour se dire qu'il doit être disponible sur d'autres distribs.

Si une seule signature suffit, on peut tous se la partager pour les logiciels libres.

Au pire, on signe le kernel et perl, et ça nous fait dèjà pas mal de fonctionalités. Les applications perl ne sont pas en binaires... et on a déjà le Window Manager ;-)

Si il faut que tous les binaires soient signés, comment faire pour déveloper ses applications? Je ne parle pas que du libre, mais aussi des logiciels non libres... Genre je suis dans une boite et je développe une appli pour eux (ou un client).

Je compile, je signe (comment?), et je me rend compte qu'il y a un problème. Qui a déjà écrit une grosse application qui marche du premier coup? Faut-il refaire tout le process de signature? Vu les délais que l'on peut avoir avec une autorité extérieure (ne serait-ce que 10 minutes), on est pas rendu dans nos dévelopements.

EDF a montré l'exemple il y a quelques mois avec un gros soft dont je ne souviens pas le nom

Tu dois surement parler de Code_Aster:
http://www.code-aster.org/(...)

il s'agit d'un outils de simulation numérique en mécanique des structures.

Théoriquement aux US non plus.Et puis de toute façon les brevets logiciels en France, c'est encore en discussion il me semble, ou alors il faut que je me réveille.

Euh? Finalement, le problème il est où? Ton collègue a peut-être mal apprécié les moyens (dans le sens peut-on se permettre de faire une séparation production/dévelopment). Mais je vois plus trop le lien avec Debian.

Je me demande si finalement ton problème avec lui est lié au fait qu'il utilise Debian ou tout simplement parce qu'il est comme ça...

Financement industriel n'est pas forcément incompatible avec liberté. Si l'université décide de suivre une politique "libre", il est de son ressort de selectionner ses partenaires industriels. Quelques universités (non françaises) y arrivent, pourquoi pas en France?
http://www.gelato.org/(...)

En fait après une viste sur la liste du matos supporté,http://www.azaka.org/,la nvidia n'est pas la seule carte graphique (on retrouve ATI, matrox...), en gros tout ce qui était supporté par AtheOS (rien d'étonnant pour un fork). Finalement, c'est l'annonce en elle-même qui est criticable. Par contre truc drôle: y a personne qui gère le kernel...