Yellow Dog ne fait *que* du PPC.
http://www.terrasoftsolutions.com/products/ydl/

"At this point in time, only the Sony Computer Entertainment PLAYSTATION(R)3 is supported with YDL v5.0. By the close of 2006, Terra Soft intends to support the most recent Apple PowerPC product line with older models close behind."

[ Répondre ]

L'ECMA est peut-être un petit groupe de standards, mais Microsoft vise aussi l'ISO.
Ils ont réussi à faire passer le C# en standard ISO :
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetai(...)

L'Open XML devrait pouvoir devenir un standard ISO sans trop de problème.

[ Répondre ]

Quinn est une transexuelle sans le sous, donc physiquement masculine.

Dans les situations où l'on parle de "technicien de surface" ou d'un "malvoyant" ou encore "d'incivilités" et de "jeunes", j'ai un traducteur politiquement-correct/français qui vient à mon secours. Il me souffle à l'oreillette :
"Quinn est un homme dérangé."

[ Répondre ]

"
Montre moi un bout de code de beryl qui soit aussi sale que tu le dis"

Un exemple sur le chaotique développement :

I think that the informal attitude has got us in the state we are today,
patches applied all over the place without formal documentation. If I
am correct, the original xinerama changes were made with the
understanding that they would be removed once David had finished the
correct changes. Now the argument is that it is too hard to undo those
changes.

http://lists.freedesktop.org/archives/compiz/2006-October/00(...)
La réponse d'un pro-beryl est croustillante, car il reconnaît le problème mais en parle comme de rien n'était :

Yes the Xinerama changes are/should be temporary until the "right" way
has been implemented and yes it probably will be a pain to strip it out
again, but I'm sure it will get done.

[...]For me, I needed compiz-quinnstorm as I predominantly work in a dual
head evironment. I'm looking forward to when dual head is done right in
compiz, but for now I *need* patches to get a working DE and for me a
branch/fork is better.[...]

Ou encore le plugin de Blur qui est bourré d'artefacts qui ne pourront être corrigés qu'en changeant dramatiquement l'architecture du plugin. Un quick hack qui sert à faire plaisir aux gens qui tiennent à avoir une copie de WIndows Vista.

[ Répondre ]

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.

[ Répondre ]

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.

[ Répondre ]

Là où tu penses. Hum.

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

[ Répondre ]

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.

[ Répondre ]

"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.

[ Répondre ]

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 ?

[ Répondre ]

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.

[ Répondre ]

"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.

[ Répondre ]

Purée, un XULeux qui se moque de Mono. C'est charmant.

[ Répondre ]

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.

[ Répondre ]

Cette discussion n'a de toute façon aucun sens. Vous défendez les deux entreprises qui font dans les plus mauvais antivirus qui soient.

Kaspersky, qui a toujours été mon petit favoris du temps où j'avais une partoche windows, n'est justement pas du même avis que ces deux entreprises à la mords-moi-le-noeud.

http://www.infos-du-net.com/actualite/8269-kaspersky-securit(...)

Symantec et McAfee peuvent lécher mes bou-boules.

[ Répondre ]

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

[ Répondre ]

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.

[ Répondre ]

"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.

[ Répondre ]

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.

[ Répondre ]