maiky a écrit 16 commentaires

Et pourtant...
Dans le domaine du temps-réel dans l'automobile, il existe un norme ISO: OSEK-VDX (il y a un article sur Wikipedia).
Il me semble que toutes les voitures européennes (en tout cas j'en suis sûr pour les françaises et les allemandes) utilisent un OS compatible OSEK.... et ce n'est pas un OSEK maison généralement.
Pour la suite des événements, dans l'automobile, AUTOSAR est en cours de finalisation (specs+revendeurs). Et c'est basé sur du OSEK.

Après, OSEK, c'est du temps réel dur, sur des cibles légères (embarqué profondément enfoui)... et l'OS tient sur 4Ko ;-)

Je comprends pas trop un truc ici.
Normalement, l'extension composite doit offrir des services pour gérer la transparence. Mettre ce service au niveau de X est logique, car il doit pouvoir utiliser les ressources de la carte graphique.
Par contre, mettre de la transparence dans E17 ne doit (a priori) pas utiliser le matériel ou alors à quoi sert le serveur graphique s'il ne fait pas sa fonction de couche d'abstration entre le matériel et le soft. Du coup, si la transparence est uniquement faite en soft, ça pompe des ressources (beaucoup pour quelque chose qui devrait être fait sur la carte graphique).
(il y avait bien QT qui avait fait un truc de "fausse transparence" avec ses menus. Mais c'était du soft uniquement (et donc à mon avis d'un intérêt très minime).

Ce filtrage est assuré bénévolement par les scientifiques. L'éditeur se contente de trouver les relecteurs et faire le lien entre ces relecteurs et le/les auteurs.

Dans le cas des conférences par exemple,ce travail est assuré par les "comités de programmes". Les personnes des comités de programme sont aussi des scientifiques qui ne touche pas une prime pour ce travail.

Il doit être possible de pouvoir redonner les résultats scientifiques aux chercheurs de manière libre et gratuite. Il est bien évident que ces résultats DOIVENT être relus pour avoir une légitimité.

Sur Mac OS X aujourd'hui, des librairies (QT, GTK...) existent et favorisent le portage de Linux->Mac OSX, mais l'inverse est tout aussi vrai.

Je suis d'accord sur le fait qu'une appli GTK ou QT peut être portée sous OSX, bien que ce soit en mode X pour GTK, et que le mode natif est encore pas top pour QT.

Par contre, pour ce qui est du portage d'applis OSX vers Linux, ça devient plus compliqué. Si on prend une appli conçue pour OSX, elle le sera probablement avec Cocoa ou au moins sera intégrée correctement à l'OS, et son portage vers GnuStep est encore hasardeux, notamment si on utilise des spécifités de OSX 10.3 comme par exemple les bindings. Je vois mal comment une appli comme OmniGraffle par exemple pourrait être portée sous Linux (même si on avait les sources).

Evidemment, pour les applis portées de Win vers OSX (comme les jeux), ça peut être une bonne idée.

Les notions de "temps réel" et de "vitesse" sont différentes!!!
Si ton système fait du contrôle commande sur une grosse chaudière, avec une constante de temps importante, les contraintes de temps se compterons en minutes!!

Après dans la pratique, lorsqu'on parle d'exécutif temps réel, on veut qu'il puisse réagir vite. Pour des applis vraiment rapides, il faudra surement un exécutif spécialisé.

On distingue généralement le temps réel "mou" où des échéances peuvent être loupées (pour xmms par exemple) du temps réel "dur" où il n'est pas possible de dépasser des échéances (le logiciel d'un ABS par ex). C'est dans ce dernier cas qu'il faut un OS très réactif.

oups tu as raison. Ca, c'est les nouveautés de QT4.
Mais elle n'étaient pas précisées dans la news.

A partir du moment où c'est une boucle, c'est un for(..) déquisé!! A ce compte là, un while est un for déguisé de même qu'un do... while().

L'intérêt, c'est juste que c'est plus commode à utiliser (au sens plus facile à comprendre) et qu'on se plante pas sur une bète erreur d'index :-)

D'après dot.kde.org, les nouveautés concernent:

Arthur: The new painting framework
Scribe: The Unicode text renderer with a public API for performing low-level text layout
Interview: A model/view architecture for item views
Tulip: A new set of template container classes
Mainwindow: A modern action-based mainwindow/toolbar/menu and docking architecture

(http://dot.kde.org/1089303565/(...))
Hop

Si, il le permet....mais sous Mac seulement!! Et tout à déjà été fait par Apple depuis plusieurs années. C'est l'équipe de gcc qui était pas trop pressé de rajouté Objective-C++ à leur compilo....mais je retrouve plus de liens là dessus :-(

- en acceptant des brevets, même ridicules, le bureau des brevets gagne du pognon.
C'est vrai.
accessoirement, ça permet de mettre tous ces éléments technologiques dans le girond américain (principe: amasser un maximum de propriété intellectuelle afin de ramasser (eventuellement) un maximum de pognon par la suite, ou faire pression à l'extérieur des USA).
Ca par contre, c'est totalement faux. Si un brevet est déposé aux USA, il n'est valable que la-bas, et heureusement :-)
En Europe, et en France en particulier, il y a une recherche d'antériorité beaucoup plus poussée. C'est une approche différente: c'est plus difficile d'avoir un brevet, et ça empèche de devoir aller directement au tribunal.

Sinon, il y a toujours la solution radio. On trouve dans le supermarché emetteur/récepteur pour un peu plus de 500F.
Ca marche ma fois très bien... tant qu'il n'y a pas quelqu'un qui utilise le micro-onde :-)
L'intérêt, c'est aussi que ca passe les murs et ca fait pas pleins de fils qui bouchent le passage..

cet anti américanisme primaire est lamentable. l'affaire "executive life" et MS n'ont absolument rien à voir. Tu mélanges tout
Si MS était français, tu applaudirais des 2 mains?

Si hustement. Et je pense que KMail n'est pas à l'abris de ce genre d'attaque, tout comme Evolution ou Mozilla Mail. On s'attaque à MSOutlook parceque c'est le plus utilisé... parce qu'il y a aussi des grosses failles de sécurité, mais mis à part le classique "Hello World", je ne pense pas qu'un programme puisse se targuer d'être sans faille.

Et mm sans véroler KMail directement, si quelqu'un trouve un accès à ta machine (en mode utilisateur), il pourra avoir accès à ton KMail et à ton carnet d'adresse facilement... A toi de voir se qu'il peut bien faire de cet accès...

Le fait d'avoir d'un côté root et de l'autre l'utilisateur fera que le virus n'affectera que les données utilisateurs... C'est à dire TOUT se qui est important. Le système, on s'en fout, on peut très facilement faire une restauration (mm si ca peut prendre un peu de tps quoiqu'un ghost sous win soit rapide).
On a bien de la chance de ne pas avoir de virus et ca peut être un argument... Mais ca ne sera pas éternel. Le jour où votre KMail sera verolé et se renverra à tout votre carnet d'adresse avant de supprimer votre compte, on ne pourra pas en dire autant...
En attendant, mm MacOS X n'a as atteint la masse critique pour être la cible des virus. (je crois...)

Comment définis tu vente à perte? Le cout de revient en fabrication d'un M$Win+office est ridicule, c'est juste le CD et la boîte...
C'est très difficile de déterminer le réel cout, vu que l'essentiel de la dépense est la recherche/développement, cad faite une fois pour toutes les copies...
Je pense mm qu'il pourrait le vendre à 15€ en france sans enfreindre aucun loi... et ce serait normal!

Bien sûr! Il me semble bien que l'encodage mp3 est soumis à licence.. (mais pas la lecture.). Lame n'est d'ailleurs pas inclus directement dans les distribs (c'est en tout cas vrai pour Debian).