Je passe définitivement à Linux - Page 8

./201 Ça serait plus beau avec une barre des tâches sur chaque écran et un wallpaper continu entre les deux
J'utilise ultramon pour ça

Chez moi il y a 230 Mo occupés au démarrage. Pourtant KDE est réputé pour être lourd (je pense que c'est équivalent à ta barre de lancement transparente). C'est marrant que Windows prenne à peine moins de mémoire qu'un OS qui pue (d'après tes dires).

A propos, aujourd'hui j'ai installé KDevelop, Eclipse et NetBeans (une grosse usine à gaz pour développer en Java, du même genre que ton Visual Studio), et aucun des 3 n'a demandé de rebooter. Ca marche tout de suite.

Tiens, tu vas pouvoir te faire de nouveaux amis :

linux pue pas o_O
il manque juste des choses

au niveau des reboots là l'avantage va à linux c'est clair et net ...

non en fait ce que tu comprends pas c'est que tout le monde ne peut pas passer à linux, c'est tout. et que windows marche très bien.


Twindruff: il gere le fait d'avoir 2 résolutions différentes ?

Peio (./213) :
non en fait ce que tu comprends pas c'est que tout le monde ne peut pas passer à linux, c'est tout. et que windows marche très bien.

Bien sûr que je comprends Je fais juste mon trolleur fanatique. Je suis comme un gosse avec son nouveau jouet à Noël. Ou comme le mec qui est fier d'avoir arrêté de fumer et qui compte les jours sans rechute.
Ca va me passer (enfin j'espère, quand je vois Kevin je me dis que Linux est un jouet qui peut rendre gaga à vie).

Peio (./213) :
au niveau des reboots là l'avantage va à linux c'est clair et net ...

ouais d'ailleurs l'install de Visual Studio est ultra chiante, d'après ce que j'ai entendu dire ils devraient améliorer ça dans la prochaine version de vs2008.

Peio (./213) :
Twindruff: il gere le fait d'avoir 2 résolutions différentes ?

ouais j'ai longtemps eu deux résolutions différentes

je viens de l'installler et c'est bien sympa la smarttaskbar et les wallpapers différents, miam

le problème de windows c'est dès que tu commences a faire des choses vraiment gourmante et que tu veux continuer a faire du multitask (ie switcher entre tes applications sans perdre de temps etc.). Et bien là c'est le carnage...

Il me semble qu'il faut aussi rebooter pour visual studio si tu veux avoir les acces debug etc (qui ne sont pas accessible par defaut sur les reseaux pour des raisons de sécurtié évidentes).

Le switching est aggravé par un swapping pas optimal, ça va certainement mieux quand on a assez de RAM et que le swap est désactivé.
Windows n'est pas connu pour être temps réel, que ce soit le task switch, le réseau, etc.

Ultramon est vraiment chouette, en particulier parce qu'il permet de gérer du multi-écran en soft (une carte graphique en PCI, une en AGP, et on peut faire de la duplication d'écran, ce qui n'est pas possible normalement).

ultramon, ça a l'air sympa, mais c'est gratos 100% ou payant pour passer la limite des 30 jours/pubalacon/autre connerie?

(C'est "payant")

(ahwé ok, donc sapuçaypalibre )

(libre != gratuit)

(jesais)

Lionel Debroux (./218) :
Windows n'est pas connu pour être temps réel, que ce soit le task switch, le réseau, etc.

Heu Linux non plus en fait, Le reseau est 100% en kernel et quasi non préemptible, le task switch à la limite, mais il a de grosses lacunes qui font qu'il ne peut etre concidéré comme fiable pour du RT

(t'es chiant de faire l'avocat du diable quand tu sais très bien de quoi on parle )

et mach il est temps réel?

Mach l'est en théorie. Dans Mac OS X/NeXT STEP certaines parties le sont encore, mais la partie *BSD qui est posé avec lui fait que sur certain points ça casse une partie du RT.

(et je fait pas l'avocat du diable, laisser de tel quel des posts qui semble dire que linux est parfait. Lionel "attaque" windows en laissant croire que linux fait bcp mieux, mais je pense franchement que coté reseau Linux fait pas bcp mieux que Windows, (enfin en tout cas pour ce qui est la pile IP en elle meme, les outils de bases c'est une autre histoire)

surtout je vois pas comment l'argument tu temps réel qui est un truc vachement spécifique vient faire ici. Parler de réactivité OK, mais de temps réel, on s'en tape.

c'est ./218 qui parle de RT

(même, je vois pas trop le lien entre swapping qui lagge et "temps réalité")

(ben pour finir le HS sur le RT, si tu utilise du RealTime, tu as tout interet a ne pas avoir de swap)

je pense franchement que coté reseau Linux fait pas bcp mieux que Windows, (enfin en tout cas pour ce qui est la pile IP en elle meme

Je pense le contraire, même si je ne sais pas jusqu'à quel point Linux fait mieux
Lors d'un stage en binôme, j'ai fait un programme simple de stress test réseau. Le but était de faire des requêtes en boucle sur un port d'un device embarqué, et essayer de vérifier automatiquement qu'il répondait en moins de 10 ms - du temps réel très mou, donc.
C'était du Java, ce qui ajoutait une source de complexité / potentielle pessimization supplémentaire... mais sous Linux, où j'ai fait le programme, je pouvais mettre un timeout de 10 ms (c'est à dire respecter la spec qui nous avait été fixée...). Sous Windows, le test merdait de façon non reproductible (au bout de quelques essais comme au bout de quelques centaines), et ce comportement n'a disparu que quand on a augmenté le timeout (il me semble qu'on l'a mis à 15 ms).

Je sais, Java n'était pas le choix le plus adapté pour du test réseau. Mais:
* la contrainte de portabilité était plus forte;
* on n'avait pas besoin d'ultra-performance;
* l'autre informaticien ne connaissait pas Perl/Python/Ruby, bien qu'il connaisse C et PHP;
Et Perl/Python/Ruby sous Windows, c'est plutôt le bazar.

normal sur les vieux linux la timeslice est de 10 ms

mais ça n'a tjs rien à voir avec le temps réel.

On peut avoir un système temps réel avec des slices de 10 ms et un système NON temps réel avec des slices de 1 ms. Encore une fois, tu t'enduis d'erreur

Godzil (./227) :
Mach l'est en théorie. Dans Mac OS X/NeXT STEP certaines parties le sont encore, mais la partie *BSD qui est posé avec lui fait que sur certain points ça casse une partie du RT.

(et je fait pas l'avocat du diable, laisser de tel quel des posts qui semble dire que linux est parfait. Lionel "attaque" windows en laissant croire que linux fait bcp mieux, mais je pense franchement que coté reseau Linux fait pas bcp mieux que Windows, (enfin en tout cas pour ce qui est la pile IP en elle meme, les outils de bases c'est une autre histoire)

Non mais c'est bon je pense que tout le monde sait qu'on parle pas de temps reel dur.
Et puis quand bien meme un os est temps reel dur il faudrait voir comment il definit ses contraintes etc... en gros c'est du HS parfait pour sortir un troll monstrueux.

Lionel Debroux (./233) :

je pense franchement que coté reseau Linux fait pas bcp mieux que Windows, (enfin en tout cas pour ce qui est la pile IP en elle meme

Je pense le contraire, même si je ne sais pas jusqu'à quel point Linux fait mieux
Lors d'un stage en binôme, j'ai fait un programme simple de stress test réseau. Le but était de faire des requêtes en boucle sur un port d'un device embarqué, et essayer de vérifier automatiquement qu'il répondait en moins de 10 ms - du temps réel très mou, donc.
C'était du Java, ce qui ajoutait une source de complexité / potentielle pessimization supplémentaire... mais sous Linux, où j'ai fait le programme, je pouvais mettre un timeout de 10 ms (c'est à dire respecter la spec qui nous avait été fixée...). Sous Windows, le test merdait de façon non reproductible (au bout de quelques essais comme au bout de quelques centaines), et ce comportement n'a disparu que quand on a augmenté le timeout (il me semble qu'on l'a mis à 15 ms).

Je sais, Java n'était pas le choix le plus adapté pour du test réseau. Mais:
* la contrainte de portabilité était plus forte;
* on n'avait pas besoin d'ultra-performance;
* l'autre informaticien ne connaissait pas Perl/Python/Ruby, bien qu'il connaisse C et PHP;
Et Perl/Python/Ruby sous Windows, c'est plutôt le bazar.

Le problème peut venir aussi de Java, qui est globalement mieux supporté sous Linux que sous Windows (je n'en connais pas les raisons, mais elle doivent être multiples, enfin si j'en connais une, à la base, Java est du monde Unix et non Windows)

Essaye plutot avec des API native ça sera deja mieux

edit: en plus je ne sais pas a combien est le time slice sous windows (ça doit pouvoir ce trouver)
edit2: en fait il n'est pas fixe...

edit3: phrase mal tournée

ça doit venir de l'implémentation des threads aussi.

Java à la base du monde Unix??? Tu as fumé quoi?

Et sous linux comme sous windows, tu as des {extensions|versions} du noyau pour tenir des contraintes RT : RTX pour windows par exemple Avec ça, pas de problème (autre que Java lui-même, mauvaise idée s'il en est pour tenir un timing) de latence ou de préhemption.

J'ai fumé que Java viens de Sun et que la premiere JVM etait sous Solaris