OVH Cloud OVH Cloud

capacités de Linux

120 réponses
Avatar
Dankin
Bonjour.
Je poste ici, because, je ne sais pas où posté ma question.
En ce moment, j'ai affaire avec des pseudos admin windows. Le genre de
mecs qui sont devenu admin parce qu'ils étaient doué aux clicks de souris
(la lèche a dû aussi compter pas mal). Ils ont des pérjugés sur Unix, Linux et
tous les autres OS. C'est assez flippant. Est ce que quelqu'un a une url
qui donne un récapitulatif des capacités de Linux. Les architectures
supportés, etc. Ca m'arrangerait, parce que que ce que je trouve avec
google.com/linux. C'est pas top...
Merci d'avance.



--
Olivier

10 réponses

Avatar
george
Michel Talon, dans le message <bo55j1$m6v$, a
écrit :
Entre nous aussi, des "process quasi temps réels" sous Windows, ça doit
être une espèce de process qui tient de la licorne ou du minautaure, vu
les latences de l'OS.


C'est peut-être du quasi-temps réel à l'échelle géologique.ou
astronomique : il dit où est la Terre avant qu'elle ait eu le temps de
faire un million de kilomètres.

Avatar
Richard Delorme

Michel Talon wrote:

2.0 et 2.2 étaient encore bien pires que 2.4, là tu peux dire que
c'étaient des bouses infâmes par rapport à FreeBSD, et je l'ai
vérifié sur la même machine, exactement comme tu dis. D'ailleurs, à part
toi, personne ne le conteste, juqu'au développeurs de Linux 2.6 qui
disent qu'ils ont enfin réussi à faire à peu prés aussi bien que
FreeBSD.


Je ne conteste rien, je remarque juste qu'a part ton KDE qui a des
chaleurs, tu n'as rien de precis pour prouver tes propos. Aucun code
particulier de test, aucune situation reproductible, ...

C'est plutot dogmatique tout ca.


La littérature sur la gestion de la mémoire par Linux est quand même
abondante. Il était notoire que Linux marchait mal sur les systèmes
multiprocesseurs (> 16 CPU) qui faisaient tourner des milliers de
processus, car il passait tout son temps dans le gestionnaire de VM, les
I/O,... Désormais, ce problème semble résolu avec le noyau 2.6. Cf par
exemple : http://dsoulayrol.free.fr/articles/wonderful_2.6.html, pour voir
les améliorations aportés par le noyau 2.6

--
Richard


Avatar
Sebastien Tanguy
Stephane TOUGARD writes:

Sebastien Tanguy wrote:
Bah tiens, je fais pas des serveurs d'uptime sous windows à mon boulot
comme certains en font sous Linux, Hurd ou je ne sais quoi dans leur
placard...


Je ne sais pas sous Windows, mais sous Unix, il suffit de taper ca

:~$ uptime
07:55:01 up 143 days, 16:50, 1 user, load average: 0.00, 0.00, 0.00
:~$ uname -a
Linux eagle 2.2.20 #1 Sat Apr 20 11:45:28 EST 2002 i686 unknown
:~$


Impressionnant. Pour mes windows, je dois même pouvoir le fair en une
seule commande, tiens.

[] % snmpget -c ***** -v1 tirpitz SNMPv2-MIB::sysDescr.0
SNMPv2-MIB::sysUpTime.0
SNMPv2-MIB::sysDescr.0 = STRING: Hardware: x86 Family 15 Model 2 Stepping 7
AT/AT COMPATIBLE - Software: Windows 2000 Version 5.0
(Build 2195 Uniprocessor Free)
SNMPv2-MIB::sysUpTime.0 = Timeticks: (110599359) 12 days, 19:13:13.59


Voila, je sais que cette machine est up depuis 143 jours et je sais ce
que c'est (PS: 143 jours, ca correspond a sa date d'installation, c'est
juste un exemple).


Et moi, 12 jours, ça correspond à la date de mise en place des
onduleurs sur cette machine.

D'ailleurs, on pourrait reparler de la précision des outils que tu
cites, en prenant un exemple tel que:

22:28:46 up 103 days, 4:27, 0 users, load average: 0.00, 0.00, 0.00

Que j'avais sur une machine voici quelques mois... Sauf que ça
correspond en vrai à un uptime de 600 jours, vu qu'avec un noyau 2.2,
Linux va faire boucler son compteur et le repasser à zéro... (toujours
mieux qu'un 2.0 qui va freezer, mais bon...)

Sans rigoler, ton meilleur uptime, c'est quoi ?
Un an, deux an, dans ces eaux là, pour du NT, à un job précédent, avec

des process quasi temps réels tournant en permanence. Pour mes 2000
actuels, ils pourraient facilement tenir des mois, mais je suis un
petit gars responsable qui patche ses systèmes.


Bien sur, d'ailleurs apres avoir patche, tu rebootes pas ?


À ton avis, quelle est la signification du mot "mais" dans ma phrase ?

Entre nous, un uptime, c'est le temps entre deux reboot, qu'ils soient
volontaires ou non, dus a une panne de courant, a une operation de
maintenance ou a un plantage.


Je ne demandais qu'à recevoir des cours du maître...

Tu fais quoi avec du Linux, alors ?


Des serveurs, des firewalls, du transactionnel, de l'espace disque, bref
mon metier et rien que Windows n'a fait aussi bien que le pire des
Unices.


D'ailleurs, on remarquera que le pire des Unices est plus souvent
utilisé que du Linux pour ces mêmes tâches, dans les services
traditionnalistes et critiques... (en tout cas, j'ai plus souvent vu
du SCO ou du HP-UX que du Linux). J'en déduit donc qu'un Windows est
bien suffisant.

Tu sors des on-dit et des préjugés. Stable ? J'ai vu des Linux se
faire reformater la partition système en appuyant sur une touche à
cause de drivers foireux. Fonctionnel ? Sors moi une installation type


Tu as vu ? mais tu m'impressionnes fortement d'avoir vu un driver
foireux reformater une partition, t'es sur que tu confonds pas avec un
systeme Microsoftien ?


Non.

Par contre, argument qui pourrait être en faveur, le problème venant
sans doute du driver, on pourra toujours dire que c'est à cause du
fait que c'était du code propriétaire.

Mais sinon, c'était de la Debian testing ou unstable (pour avoir une
version de X décente), avec un noyau 2.2.19 ou 2.2.20 et de l'ext2fs.

Et je raconte pas non plus nos problèmes de mémoire dans les versions
2.4.x, le comportement des IPC qui changeait dans une release mineur
pour être incompatible avec certaines librairies que nous utilisions,
etc...

Parce que lorsque M Talon nous fait un Troll sur Linux, il a au moins
pour lui de s'appuyer sur une base (tres faible certe) de verite. Mais
la, tu dois confondre fantasme et realite.


J'ai une vie pleine de fantasmes, je ne le savais pas, tiens.

Dans ton cas, c'est tellement peu credible, qu'on depasse a peine le
stade de la blague de potache.


Disons que j'utilise les 2 systèmes dans le vrai monde et que je sais
les comparer équitablement, contrairement à certains qui se targuent
de dire que tel OS est instable et inutilisable en dehors d'une
station de travail en ayant à peine utilisé celui-ci.

Ça me fait penser à ces étudiants ou ces PHB qui affirment que les
environnements Microsoft sont standard alors qu'ils n'ont jamais eu
l'occasion de jeter un oeil ailleurs et qu'ils ne savent donc pas de
quoi ils parlent.


seb.
--
"Fear leads to anger. Anger leads to hate. Hate leads to using
Windows NT for mission-critical applications."
-- What Yoda *meant* to say



Avatar
Stephane TOUGARD
Richard Delorme wrote:

La littérature sur la gestion de la mémoire par Linux est quand même
abondante. Il était notoire que Linux marchait mal sur les systèmes
multiprocesseurs (> 16 CPU) qui faisaient tourner des milliers de
processus, car il passait tout son temps dans le gestionnaire de VM, les
I/O,... Désormais, ce problème semble résolu avec le noyau 2.6. Cf par
exemple : http://dsoulayrol.free.fr/articles/wonderful_2.6.html, pour voir
les améliorations aportés par le noyau 2.6


Puis c'est vrai qu'avec plus de 16 processeurs, FreeBSD est the best of
the world depuis sa version 2.2 STABLE. C'est bien connu. Franchement
les gars, si vos griefs contre la VM de Linux se situent a ce niveau, je
suis plus mort de rire qu'inquiet tant il est vrai qu'on est sur le
creneau de Solaris ou de HP-UX plutot que celui de FreeBSD (et je ne
parle meme pas des autres BSD qui ne depassent meme pas le mono-proc).

Avatar
Stephane TOUGARD
Sebastien Tanguy wrote:

[] % snmpget -c ***** -v1 tirpitz SNMPv2-MIB::sysDescr.0
SNMPv2-MIB::sysUpTime.0
SNMPv2-MIB::sysDescr.0 = STRING: Hardware: x86 Family 15 Model 2 Stepping 7
AT/AT COMPATIBLE - Software: Windows 2000 Version 5.0
(Build 2195 Uniprocessor Free)
SNMPv2-MIB::sysUpTime.0 = Timeticks: (110599359) 12 days, 19:13:13.59


T'es a douze jours quand meme, c'est a dire la moitie du record d'uptime
pour un W2000 installe en tant que serveur et en prod. C'est pas mal.

J'exagere, j'ai vu des NT tenir 60 jours.

Un an, deux an, dans ces eaux là, pour du NT, à un job précédent, avec
des process quasi temps réels tournant en permanence. Pour mes 2000
actuels, ils pourraient facilement tenir des mois, mais je suis un
petit gars responsable qui patche ses systèmes.
Bien sur, d'ailleurs apres avoir patche, tu rebootes pas ?

À ton avis, quelle est la signification du mot "mais" dans ma phrase ?



Attends, je te demande ton meilleur uptime et tu me reponds un an, deux
ans, ensuite tu me confirmes malgre tout que tu rebootes a cause d'un
"mais" dans ta phrase.

Je repose ma question : ton meilleur uptime avec un W2K, c'est combien
de jours (on va pas parler en mois, je comprends le cote desagreable a
parler en fractions) ?

Mais sinon, c'était de la Debian testing ou unstable (pour avoir une
version de X décente), avec un noyau 2.2.19 ou 2.2.20 et de l'ext2fs.


Et un driver proprietaire dont le code source se resume a :

#!/bin/sh

mke2fs /dev/hda1

Bien sur, je comprends.



Avatar
Sebastien Tanguy
Stephane TOUGARD writes:

T'es a douze jours quand meme, c'est a dire la moitie du record d'uptime
pour un W2000 installe en tant que serveur et en prod. C'est pas mal.


Il faudrait un peu lire ce que j'écris et pas juste ce qui te fait
plaisir, pris hors contexte.

J'exagere, j'ai vu des NT tenir 60 jours.


Et tu es parti de dépit ?

Un an, deux an, dans ces eaux là, pour du NT, à un job précédent, avec
des process quasi temps réels tournant en permanence. Pour mes 2000
actuels, ils pourraient facilement tenir des mois, mais je suis un
petit gars responsable qui patche ses systèmes.
Bien sur, d'ailleurs apres avoir patche, tu rebootes pas ?

À ton avis, quelle est la signification du mot "mais" dans ma phrase ?



Attends, je te demande ton meilleur uptime et tu me reponds un an, deux
ans, ensuite tu me confirmes malgre tout que tu rebootes a cause d'un
"mais" dans ta phrase.


Décidément tes troubles de la lecture te posent des problèmes pour
suivre des échanges dans leur intégralité, ça doit pas être facile
tous les jours.

J'ai dit avoir eu des NT (sous entendu du 4.0) avec un à deux ans
d'uptime. Comme ceux-ci étaient dans un environnement particulier, il
n'y avait pas besoin de les patcher spécialement hormis les besoins
spécifiques à la prod et à aux éléments validés.

Mes Windows 2000 actuels, plus exposés sont mis à jour régulièrement,
donc il arrive qu'il y ait besoin de les rebooter.

Je repose ma question : ton meilleur uptime avec un W2K, c'est combien
de jours (on va pas parler en mois, je comprends le cote desagreable a
parler en fractions) ?


Je n'ai pas eu de windows 2000 suffisement sous la main récemment pour
donner des chiffres exacts. Mais j'avoue que ça doit être désagréable
pour toi d'entendre que la vraie vie, des gens arrivent à faire
fonctionner des machines windows 2000 mieux que tu ne le ferais avec
tes propres Linux.

Mais sinon, c'était de la Debian testing ou unstable (pour avoir une
version de X décente), avec un noyau 2.2.19 ou 2.2.20 et de l'ext2fs.


Et un driver proprietaire dont le code source se resume a :

#!/bin/sh
mke2fs /dev/hda1

Bien sur, je comprends.


Non, ça aurait plutôt été de l'ordre du dd if=/dev/random of=/dev/hda,
mais en l'occurrence, pour faire de l'OpenGL, cela aurait été un peu
léger.


seb.
--
``This god is a geek who wears socks with his sandals. His name is
Linus Torvalds.'' (From 'Time')




Avatar
Stephane TOUGARD
Sebastien Tanguy wrote:
J'exagere, j'ai vu des NT tenir 60 jours.
Et tu es parti de dépit ?



Non, ils ont plante et on s'est fait engueule par l'admin qui avait bien
dit qu'il fallait les rebooter une fois par semaine.

J'ai dit avoir eu des NT (sous entendu du 4.0) avec un à deux ans
d'uptime. Comme ceux-ci étaient dans un environnement particulier, il
n'y avait pas besoin de les patcher spécialement hormis les besoins
spécifiques à la prod et à aux éléments validés.


Donc des NT avec un uptime (absolument aucun reboot) de deux ans, ca
existe.

Felicitation, je ne sais pas si beaucoup de gens vont te croire, mais
felicitation quand meme, dans un cas c'est un troll baveux, dans l'autre
c'est un record du monde.

fonctionner des machines windows 2000 mieux que tu ne le ferais avec
tes propres Linux.


C'est marrant, mais j'ai des doutes.

Non, ça aurait plutôt été de l'ordre du dd if=/dev/random of=/dev/hda,
mais en l'occurrence, pour faire de l'OpenGL, cela aurait été un peu
léger.


Ben, commend dire, ...


Avatar
Sam Hocevar
On Mon, 3 Nov 2003 09:02:25 +0000 (UTC), Michel Talon wrote:

Entre nous aussi, des "process quasi temps réels" sous Windows, ça doit
être une espèce de process qui tient de la licorne ou du minautaure, vu
les latences de l'OS.


Les latences de NT sont d'expérience moins ridicules que sous Linux
2.2 ou antérieur (n'importe qui ayant codé un émulateur pour un hardware
quelconque sous Linux et sous NT pourra confirmer). Et les trucs comme
HyperKernel ça marche très bien aussi.

--
Sam.

Avatar
Vincent Bernat
OoO En cette nuit nuageuse du lundi 03 novembre 2003, vers 00:00,
Sebastien Tanguy <seb+ disait:

Tu devrais aller prévenir Microsoft, ils seraient vraiment intéressés
par voir tes systèmes parce que, eux, ils n'y arrivent pas.


Je pense qu'ils y arrivent, même s'ils ont fait des déclarations sur
des systèmes en développement qui vont dans le sens contraire...


Oui, oui, bien sûr.
--
die_if_kernel("Kernel gets FloatingPenguinUnit disabled trap", regs);
2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c


Avatar
Vincent Bernat
OoO En cette nuit nuageuse du lundi 03 novembre 2003, vers 00:04,
Sebastien Tanguy <seb+ disait:

Sinon, ssh, hein, y'a pas besoin d'une interface graphique pour
utiliser un Linux à distance.


Le sujet des échanges était "de l'utilisation de X Window en réseau,
par rapport à windows", pas "utiliser Linux à distance".


Dans ce cas, ton exemple n'est pas valable puisqu'on est obligé de se
taper le bureau entier pour chacune des machines, il s'agit juste d'un
contrôle à distance pas d'une utilisation réseau (cf exemple
d'Emmanuel).
--
printk(KERN_WARNING "Multi-volume CD somehow got mounted.n");
2.2.16 /usr/src/linux/fs/isofs/inode.c