taratatatata a écrit 182 commentaires

Là tu parles des images qui sont utilisées dans les machines.

Mais avec quels outils ces systèmes sont compilés ? administrés ? avec quels outils sont faits les petits scripts ?

Dans beaucoup de systèmes dénudés et sans programmes GNU se cache derrière un développement ou un environnement GNU.

On s'en branle qu'on "peut" le faire tourner sans rien de GNU. Ce qui est intéressant, c'est de savoir si on le fait vraiment, real world, utilisé quotidiennement. La réponse est non.

On parle de Linux quand on parle du kernel. On ne parle de GNU/Linux que quand on utilise l'os à base d'userland GNU. Si la seule bécanne au monde qui fait tourner un Linux sans GNU c'est un mini serveur web bidon qui héberge du html ne contenant que du texte ça ne change rien au fait que ce qu'utilisent les gens, IRL, c'est du GNU/Linux.

Faut aussi ajouter le fait que la première version du site d'ulteo était une copie du squelette du site mozilla. Ce genre de comportement de lamer ça attire forcément l'étiquette Vaporware.

Là où tu penses. Hum.

Dans ton entre jambe, centre de ta pensée masculine ?

Que les outils graphiques actuels aient des manques ne veut pas dire que qu'on ne peut pas faire des GUI sans ces manques.

Je ne sais pas ce qu'il en est de YaST mais tu peux scripter bon nombre d'applications KDE via DCOP par exemple. Une bonne GUI c'est aussi une GUI qui peut communiquer via la command line.

"As a result, users have to perform tasks that should be reserved to computer specialists, while we think that users should just spend time using the applications they need. Ulteo tries to provide answers to these issues.

The first answer we have is to consider the OS + applications as a whole system that we could call an "Application System". This system should:
1- always provide the most up to date stable features and self-upgrade automatically
2- require no, or very little, administration by the user
3- open users horizon to potentially every application which exists, the simple way

[...]
For this release of Ulteo Sirius Alpha1, we have focused on the first point. This means that after the first installation, Ulteo will try to check for any new versions available if a network connection is available, and self-upgrade by using an incremental upgrade mechanism.
"

Ca inspire confiance. Vraiment. Le système qui se mets à jour tout seul même lors de passages à de nouvelles versions (et pas juste des bugfix). Le monsieur qui lave plus blanc que blanc et qui, c'est promis, nous livrera un linux avec zéro pourcent administration, plus fort qu'OSX et Vista.

Smells fishy.

Propriétaire ?!?
Si les programmes sont sous licence libre, alors ce n'est pas du propriétaire. Point final.
Parles de développement fermé mais pas propriétaire. Merci.


Ce dont tu souffres porte un nom. Reality Distortion Field. Tout le monde, sauf toi, auront juste pensé à YaST et les bricoles pourries et proprio qu'il y avait dans la version boite.

Pendant longtemps le troll susecapuecestpaslibre a sévit sur toutes les news de DLFP et je ne t'ai jamais vu contester ces trolls. Pour quelle raison tu t'excites aujourd'hui ?

Ce n'est pas tant les logiciels libres que notre liberté d'échange de l'information. Plus on nous brimera des libertés (LEN, DADVSI..) plus il sera difficile de les récupérer.

L'utilisation des logiciels libres dans le gouvernement en soit je m'en tape un peu. Par contre, la position des politiques sur mes libertés..

Ce qu'on perds, on ne le récuperera pas.

"Le gouvernement semble avoir compris les enjeux considérables que représente le Logiciel Libre pour la France !".

Le gouvernement Chirac, qui n'en a plus pour longtemps. Je serais bien curieux de connaître la position de Bayrou, Sarkozy et Royal sur le sujet.

De toute façon les drivers Creative c'était tellement de la merde plantogène, leurs cartes sons ne me manquent franchement pas. Ceux qui ont eu à la fois une Live et XP peuvent témoigner, c'est le même niveau de qualité que les vieux drivers ATi avant qu'ils ne fassent les Catalyst. Je garde un goût amer de l'interface qui servait à leurs nomad jukebox 3 aussi, un véritable miracle d'Inutilisabilité.

Pour ceux qui ont besoin d'utiliser du hardware pro, ça ne passe de toute façon pas par les API DirectX-DirectSound. Les cartes sons pro ne sont pas touchées par ce changement dans Vista.

Et ils ont juste saisi la carte réseau ? pourquoi faire ?

Evidemment, cela pose le problème qu'une même personne doit maîtriser tous les tenants et aboutissants du compilateur LISP. L'intérêt d'utiliser directement LISP, c'est de gagner du temps à ne pas réinventer la roue à chaque fois (ou beaucoup moins) et d'avoir un code plus lisible à la fin.
Le combat du "je suis plus rapide" ne s'applique pas aux langages de haut niveau : leur intérêt réside dans le gain de temps, de maintenance, ....

Un programme bien conçu qui ferait 100000 lignes de Lisp ou de Prolog ou de Caml ou autre n'est en fait pas possible à écrire en C. Il faudrait des dizaines de millions de lignes de code, le code ne serait pas maintenable,...
Tu as lu le contraire où dans mes reply ? je dis juste que ces langages ne sont pas comparables sur un même terrain.

Le pire c'est que l'un des textes que j'ai cité dit exactement la même chose que ce que tu dis. Je le re-cite, parce que ça a l'air de passer mal dans les oreilles.

> So what have we learned? We confirmed what we pretty much knew: you
> can write a C program in CL, at which point the relative speed of your
> C and CL versions will depend on the relative quality of the code
> generation. It's worthwhile to know the specifics of your
> implementation (for instance, it seems that a substantial amount of
> the last-mile speed up for this benchmark on CMUCL came from figuring
> out ftruncate could be fast inside a macro, but not inside an inline
> function).
> What would be even more interesting to me would be an example more
> like what I feel I experience anecdotally --- that I write programs
> that are a bit slower than C (maybe 25% to 50%), but they're much more
> flexible, more abstract, cleaner, easily modifiable, and so on. I
> don't really feel like the CL version of almabench we currently have
> shows any of the benefits of CL.

"Je me répete aussi, je ne vois _rien_ dans les _langages_ qui interdisent les mêmes performances pour des programmes C et Lisp."

Mais on s'en fout ça que sur le papier le langage lui même ne l'interdise pas. On parle de la pratique. C'est comme dire que Ruby n'interdit pas non plus la performance. C'est la vérité, mais la vérité c'est aussi que Ruby n'a pas d'implémentation performante.

Avec de la théorie on pourrait refaire le monde.

Je me répète :
http://bc.tech.coop/blog/040308.html

C'est les lispers eux même qui le disent. Et ils utilisent une version de SBCL de 2004, pas si vieille.
Pour faire du code aussi rapide que du C, il faut optimiser comme un codeur C le ferait, dans la majorité des cas. Ce n'est pas *toujours* le cas mais c'est une généralité bien réelle.

Bref, on ne peut pas comparer les langages directement quand ils ne sont pas du même niveau. Le C ne se compare pas au Lisp. Tu peux comparer le Pascal au C, ça va pas plus loin.

Je rajoute un lien sur le sujet :
http://bc.tech.coop/blog/040308.html

Le code vainqueur d'un benchmark n'utilise pas le lisp comme un lisper l'utilise.


> So what have we learned? We confirmed what we pretty much knew: you
> can write a C program in CL, at which point the relative speed of your
> C and CL versions will depend on the relative quality of the code
> generation. It's worthwhile to know the specifics of your
> implementation (for instance, it seems that a substantial amount of
> the last-mile speed up for this benchmark on CMUCL came from figuring
> out ftruncate could be fast inside a macro, but not inside an inline
> function).
> What would be even more interesting to me would be an example more
> like what I feel I experience anecdotally --- that I write programs
> that are a bit slower than C (maybe 25% to 50%), but they're much more
> flexible, more abstract, cleaner, easily modifiable, and so on. I
> don't really feel like the CL version of almabench we currently have
> shows any of the benefits of CL.

Tu ne comprends pas le raisonnement. On ne compare pas des langages qui ne s'utilisent pas de la même façon.

Si tu utilises la partie "primitive" du lisp, que tu fais du code comme un programmeur C, ça sera aussi rapide que du C.
Si tu utilises toutes les abstractions et la puissance du langage Lisp, non, on ne peut rien comparer.

On ne peut comparer des langages qui ne sont pas utilisés dans un même contexte. Tu peux coder des trucs aussi performants que du C en Lisp mais ce n'est pas le but. Un lisper quand il code en lisp il ne se retient pas d'utiliser les puissants outils de son langage. Le codeur C n'a pas le choix et fait avec les limitations du C.

(performances équivalentes à celles de gcc).

En fait, c'est vrai et c'est faux à la fois. C'est comme quand on dit que le C++ est aussi rapide que le C. C'est vrai si tu codes le C++ comme tu coderais du C mais ça ne l'est pas si tu codes avec les abstractions fournies.

Les performances de langages fondamentalement différents ne peuvent être comparées honnêtement. C'est possible de faire des comparaisons du type "Python - Ruby", "C - Pascal", mais "C - Lisp" ou "C - C++" non.

Tu as lu mon message ? Java tourne aussi sous une machine virtuelle, et a eu un succès, comment dire, qui dépasse les limites de l'imagination. On fait tourner ces machines virtuelles sur presque tous les téléphones portables modernes.

Smalltalk est la preuve qu'il ne suffit pas d'être un langage puissant pour gagner le coeur des développeurs. Il faut avoir un minimum de familiarité avec ce qu'ils utilisent déjà, ce qui n'est pas le cas du Lisp.

Java est un petit peu devenu le smalltalk du commun des mortels. Il n'en a pas toute l'essence, mais il en a assez, et il est assez familier, pour être devenu l'un des langages les plus utilisés en ce monde. Good Enough Prevail.

La familiarité avec le développeur prime au point qu'IBM a arrêté de pousser Smalltalk et sa syntaxe bizarre au profit de Java, et ce, malgré le fait que Smalltalk en tant que langage était bien plus évolué. Smalltalk n'aura pas réussi à bénéficier du dixième du succès qu'a eu Java. On retrouve Java partout, jusqu'à nos téléphones portables.

Le C++ et son paradigme objet borderline est devenu un succès énorme rien que parce qu'il ressemblait à un super-set du C.

Faut croire que la syntaxe, c'est important. Parce qu'à part la familiarité avec le développeur, bon nombre de langages employés actuellement auraient dû mourir au profit de précurseurs mieux développés.

Ce qui est top avec les lispers c'est que dans 20 ans on aura encore les mêmes exemples de grandes réussites, les mêmes gourous (Paul Graham, Philip Greenspun)..

Après Viaweb, un grand classique c'est Naughty Dog, la seule boite qui ai conçu un jeu moderne avec un peu de lisp dedans, forcément, ce nom est devenu un Culte. Quand quelqu'un demande dans un newsgroup des conseils pour coder un jeu vidéo il y aura toujours un gogo qui va dire que le Lisp est LE langage pour coder des jeux vidéo, qu'il faut absolument utiliser lisp et pas autre chose, que Jak&Daxter a été une réussite grace au Lisp, et vive Naughty Dog.

Ils avaient dit que le 2.6.16 serait un kernel stable et maintenu le plus longtemps possible. Les distro stables sur le long terme étaient censées l'utiliser.
MAIS AUCUNE DISTRO NE L'UTILISE, OLOLOL.

Ubuntu Long Term Support utilise le 2.6.15.
Red Hat Enterprise Linux 5 utilisera le 2.6.17.
La debian etch utilisera le 2.6.17 ou peut-être 2.6.18.
Mandriva utilise le 2.6.17.

Il n'y a que Novell qui est tout seul avec son 2.6.16 pour les SLED/SLES.

"In December of 2005, Adrian Bunk announced his intention to maintain the 2.6.16 kernel indefinitely, maintaining it much the same as the 2.4 kernel is maintained for as long as it is used and patches are contributed."

Pauvre gars. Huhu.

Il remets toujours ça lui et son Ubuntu. Tu ne voudrais pas te mettre la distro là où le soleil ne brille pas ?

1/Microsoft vends sous son label MSN de la musique avec DRM PlaysForSure
2/Microsoft se mets à faire un baladeur mp3 qui ne marche pas avec la musique qu'ils ont vendu. MSN = Microsoft Network.
3/Les clients réalisent qu'ils ont acheté de la musique à un fournisseur et que ce même fournisseur leur dit d'aller se faire voir quand il décide de créer du hardware.

Tu trouves ça normal ? pends-toi.

$LANG=ru /bin/cp /media/usbkey/britney.wmv /data/
cp: In Soviet Russia, Britney cp YOU !

Malgré le fait que le code soit neuf, Firefox est autant vieux, usé et fatigué que ce bon vieux Netscape.