pasBill pasGates a écrit 16291 commentaires

Sous Debian, en cas de remplacement de la glibc, tous les processus critiques (serveurs) sont relancés de manière transparente, sans rebooter. Même le processus init est relancé tranquillement sans même avoir à quitter sa session X. Pour les trucs moins importants (genre la session X en question), le gestionnaire de paquet prévient qu'il faudra se déconnecter puis se reconnecter pour prendre en compte le changement de libc.

C'est super, ca revient a redemarrer tous les processus quoi, vachement different d'un reboot...

Par contre, quand il faut rebooter, ça bricole pas mal! Ca bricole tellement que je n'arrive même pas à lancer le task manager pour tracer tout ça 2 MINUTES APRES APPARITION DU BUREAU!

C'est qu'il y a clairement qqe chose qui cloche sur ton systeme alors, parce qu'un boot de XP sur une machine a peu pres recente (moins de 4-5 ans), c'est moins d'une minute et c'est utilisable apres.

Mais je te promets que s'il suffisait d'arrêter toutes mes applis, voire même de me déconnecter/reconnecter, je crois que ce serait mieux pour mes nerfs (particulièrement quand le redémarrage se lance automatiquement le temps que tu regardes ailleurs alors que tu as un rapport à rendre dans 5min...).

Si tu resoud ton probleme de boot lent, a mon avis tu te sentiras beaucoup mieux, et tu te sentiras encore mieux si tu regle Auto Update pour qu'il t'offre les updates a installer et te laisse choisir quand rebooter plutot que le faire automatiquement.

L'amélioration du temps de boot, c'est comme tu dis pour que "arrêter toutes les applis" et "rebooter" revienne presque au même. Pour l'instant, on ne peut pas dire que ce soit vrai!

Mon temps de boot sur un Vista SP1+toutes les updates(et un nombre de softs installes genre Office 2007, VStudio 2008, ...) sur un laptop de 2006 : ~45 secondes , la plupart de mes machines au boulot ont des temps de boot plus court, avant de pester contre l'OS, il serait bon de comprendre ou se situe le probleme, j'imagines que tu n'as jamais essaye de mesurer ou se situait la lenteur de boot(soit par flemme soit parce que tu ne sais pas comment).

Quand tu mets à jour ton navigateur, pour utiliser le nouveau binaire/les nouvelles libs, tu le relances simplement...que ce soit une mise à jour mineure ou majeure d'ailleurs.
Pour l'histoire des dépendances sur les libs, déjà les libs d'un navigateur à part le navigateur lui même, je vois pas bien ce qui peut en dépendre, et surtout je vois pas pourquoi ça nécessiterait un reboot.

Demande a KDE et Gnome pourquoi ils ont besoin d'afficher du HTML alors.

Ensuite, dans les cas ou les libs mises à jour sont des dépendances de beaucoup de programmes (je pense à Qt notamment), et bien il suffit de tuer la session X et la relancer, c'est BEAUCOUP moins long qu'un reboot complet.

Tu pourrais tout a fait updater IE sans rebooter le systeme(tu fermes explorer, etc...) mais faut etre un minimum realiste hein, ca revient au meme au final: presque tous tes softs doivent etre fermes.
Tu pourrais rajouter un merdier pour gerer ca et sauver 20s chaque mois, mais ca s'appelle prendre un marteau pour tuer une souris vu la difference pour 99% des utilisateurs.

Sous Linux, j'ai besoin de rebooter uniquement si j'ai mis à jour le kernel. Le reste c'est pas nécessaire.

T'as oublie la glibc

De l'autre côté sous Windows, je viens de réinstaller un XP pour mon père, et le nombre de reboot nécessaire m'a rendu fou: chaque driver installé, certains logiciels (dont Java je crois), les mises à jour évidemment. Le pire, c'est qu'après avoir installé le driver son, j'avais directement du son, mais non il veut qu'on redémarre...

Ben la prochaine fois t'apprendras que tu peux installer presque tout en meme temps et rebooter bcp moins plutot que rebooter apres chaque truc installe.

En tout cas ce n'est pas un GNU/Linux qui demandera de redémarrer totalement la machine pour une mise à jour de navigateur ou de lecteur multimédia.

Windows non plus, tu peux mettre a jour Firefox ou MPlayer sans rebooter.

Maintenant, va essayer de mettre a jour la KPart qui fait affichage HTML sans redemarrer KDE(ce qui en gros revient a redemarrer car il faut fermer toutes tes applis), t'auras bcp plus de mal...

Il y a une raison à la nécessité de redémarrer, sous Windows. Ça vient d'une conception assez particulière du noyau, à l'origine : ouvrir un fichier en lecture entraine implicitement son verrouillage exclusif (sauf si on demande explicitement le contraire).

Ca n'a rien, mais alors rien a voir avec le probleme et c'est faux, si tu ouvres un fichier en lecture, tu n'as pas un verrouillage exclusif, tout le monde peut lire le fichier

Ce que tu ne peux pas faire, c'est effacer un fichier sous les pieds d'un processus qui a un handle dessus, et la raison est que sous Unix, un fichier c'est 2 entites : une "directory entry" et un inode, le "handle" est sur l'inode, resultat tu peux effacer le fichier (directory entry) et en recreer un autre qui aura un nouvel inode, l'ancien inode disparaissant lorsque le dernier handle est ferme.

Sous Windows, un fichier c'est une seule entite, un handle est sur le fichier lui-meme, resultat tu ne peux pas remplacer un fichier tant qu'il y a un handle dessus.

Oui de nombeux projets libres n' ont jamais reçu -et ne recevront jamais- une seule contribution. Et alors ? c' est un argument pour contrecarré la phrase initiale ? marche pas, pas contridictoire, autre sujet.

Justement si, si ces contributions sont rares, cet avantage est franchement faible.
Si un debutant a de fortes chances d'avoir des contributions en rendant son code libre, c'est clairement un gros avantage, le probleme, c'est que c'est pas le cas du tout.

Alors oui, il y a une petite chance que ca arrive, qui est plus elevee que pas de chances de tout en proprio, mais au final ca n'y change pas grand-chose pour la plupart des gens: ils ne vont pas recevoir de contributions et devront ameliorer leur code par eux-meme, tout comme le proprio.

De nouveau, la theorie je m'en fiche totalement, ce qui m'importe est ce qui arrive dans la pratique, et la c'est assez clair.

Tout comme faire de la propagande disant que faire du soft libre te garantit que ton code s'ameliorera, les chances que cela arrive sont en fait plutot faibles. Pour que cela arrive il faut que ton projet atteigne une taille critique en terme d'utilisateurs, ce qui a peu de chances d'arriver si tu es un programmeur debutant ou qu'il soit extrement utile / efficace, ce qui probablement signifie que tu n'es pas un debutant.

Super, fait bien attention a ne pas mentionner les milliers d'autres projets libres qui sont plus petits / moins connus que ceux que tu as cites, ca risquerait de montrer la fragilite de ton argument.

Pour les exemples, cf. http://linuxfr.org/2004/01/24/15132.html et lit les commentaires, de nombreuses personnes disent clairement qu'elles n'ont eu aucune voire quasiment aucune contribution de code a leur projet.

99% des utilisateurs ne connaissent pas et ne sauront jamais programmer. Pourtant on se retrouve avec des systemes d'exploitation complets et entierement libre. Ca en fait donc un paquet de gens ayant demarre un projet libre et ayant eu des contributeurs. La pratique n'est plus vraiment a prouver.

Un paquet ? Tu veux compter le nombre de projets libres n'ayant eu aucune contribution compare a ceux en ayant eu ? Je te previens, ca va pas etre beau a voir.

Les gros projets libres eux ont plein de contributions, les autres, ils n'ont souvent pas grand-chose a se mettre sous la dent.

(D'autant que les pertes d'exploitation liées à l'indispo de linuxfr sont faible, même si les dommages en terme d'image existent bel et bien).

Ca depend, moi je dirais que nombre d'entreprises y trouvent un gain de productivite significatif :+)

Vraiment, tu veux que je te fasse une liste du nombre de gens ici qui ont demarre un projet libre et n'ont jamais eu de contributions de code ? Elle va etre longue la liste.

Toujours beau la theorie, dommage que la pratique ne soit pas aussi jolie.

Pas possible, la faille ne touche pas IIS7 et on sait tous que linuxfr tourne sur Windows Server 2008

Ah oui c'est vrai j'avais oublie, si tu ne fais pas du code libre, tu es automatiquement un mauvais programmeur qui ne deviendra jamais bon et ne pourra jamais ameliorer son code.

Tu en as d'autres des droles de ce genre ?

Les deux vont souvent ensemble, ont les mêmes objectifs finaux, les mêmes contraintes pour l'utilisateur et les mêmes effets pervers. Je les associe pour résumer : d'autres ont déjà fait des thèses là dessus.

Les deux n'ont rien a voir du tout, les associer ne fait que montrer ton ignorance du sujet.

Oui et ont les mêmes effets de bord non souhaitables et les mêmes dangers que le "proprio payant" ou les Sharewares (les pires selon moi).

Le but du libre n'est pas la gratuité, même si elle va de pair.

Tout a fait, et le but du freeware n'est pas d'entuber les gens, c'est de se faire plaisir et d'aider les gens en meme temps.

Le but du freeware non libre n'est pas le partage : c'est une manière de se faire connaître, un coup de pub, uniquement, et les auteurs de freewares non libres répondent bien souvent aux demandes de fonctionnalités par des devis...

La tu ne fais rien d'autre que demontrer que tu n'y connais _absolument_ rien, c'est absolument faux sur toute la ligne.

Le but du libre va bien au delà de la gratuité : le partage, l'entraide et le respect de l'autre sont des éléments importants de la démarche d'ouverture du code.

Oui bien sur, comme si vous etiez les seuls anges dans un monde demons, un peu de serieux stp.

La mon cher tu fais un amalgame entre proprio et payant qui n'a pas lieu d'etre.

Il y a une quantite enorme de freewares et autres qui bien que n'etant pas libres, n'ayant pas de sources accessibles, ne coutent pas un sou a l'utilisateur.

Toutes les specificites que tu as citees dans ton 2eme post, elles s'appliquent au freeware, au domaine publique, etc... c'est bien pour ca que je te demandais en quoi c'est specifique au libre.

La 2eme partie de ton 2eme post ne fait que reprendre les sempiternels avantages theoriques du libre, ils n'ont rien a voir avec ta prose concernant les retours positifs, l'interet d'entreprises, etc...

Je comprends tout a fait que c'est gratifiant, mais qu'y a t'il dans ton experience qui soit specifique au libre ?

Tu parles de retours positifs/negatifs, questions, demandes de fonctionnalites, ... bref rien qui soit different d'un soft domaine publique ou proprio.

Pour moi ta prose revient simplement a dire: ecrivez des softs, il seront utile a certains, et peut-etre bcp apprecie.

Les IPC, du moins la mémoire partagée, ne demande pas de context-switch.
Il ne faut pas oublier que les thread demandent des context-switch (sauf si multi-cpu).

La memoire partagee oui, le probleme est que tres peu de softs utilisent cela comme methode d'IPC, car c'est un sacre merdier de synchroniser la chose, surtout quand t'as plusieurs parties et pas que 2.

Les applis sons vont "plus vite que la musique" et donc passe en sommeil. C'est systématiquement un context switch. Ce "problème", tu l'as avec un serveur de son en userland ou en noyau.

Si l'appli fait que du son oui, maintenant tu prends un truc genre Flash sur un netbook, ca devient plus serre...

Si lors de l'écriture dans le serveur de son au niveau noyau la carte son n'est pas disponible, c'est aussi un context switch.
Bref, ça change pratiquement rien.

Euh si, il y a des buffers

Bref, ça change pratiquement rien.

Au contraire, ca change pas mal. C'est certainement pas la seule chose qui compte, mais ca a un impact non negligeable.

Faut connaitre quel compilo a genere le code (histoire de savoir quel type d'optimisations il fait, quels choix il fait, ...) et ensuite tu prends le code binaire avec les symbols de debogguage et tu en gros regenere ce que le compilo a fait et compare. Il y aura qqe differences ici ou la dues au fait que l'emulation du compilo d'origine n'est pas parfaite, faut normaliser l'usage des registres, mais une deviation non-minime par rapport au code sera tres vite detectee.

le thread noyau associé à un thread processeur tournent sur le même processeur, donc commutations de ring et compagnie, alors qu'avec de la mémoire partagée, on passe le noyau juste pour accéder au périph.

J'ai comment dire rien compris a ton explication, c'est quoi l'avantage du multi-coeur pour les IPC ?

Avec serveur de son (en user space) : ces 5 applis seront peut-être (en fait probablement) des changements de contexte (l'écriture en IPC ne demande pas de changement de contexte) mais il n'y a pas de raison qu'il y en est plus.

Euuh... Tu as vu ou qu'il peut y avoir des IPC sans context-switch ?

Les IPC coutent un context-switch a chaque fois, c'est inevitable.

Quand au probleme kernel<->serveur de son c'est assez simple :

Chaque app doit envoyer le son au serveur (1 IPC pour envoyer+1 IPC pour le serveur de son pour lire) qui lui doit l'envoyer au kernel (1 IPC)

Avec le mixer dans le kernel, l'app l'envoie directement au kernel (1 IPC)

Sachant qu'il y a rarement plus d'un ou deux softs faisant du son en meme temps, ca fait en comparaison :

pour 2 softs emettant du son :
user-space : 2*2+1 = 5
kernel : 2

pour 1 soft emettant du son :
user-space : 2+1 =3
kernel : 1

Bref, une sacree reduction...

C'est vrai ca, d'ailleurs il y a des lois contre le vol, pourquoi tu fermes ta porte a cle ?

Tiens je te divulge une faille dans ton système; "Une 0 day ça se vend 50.000$. Alors faut pas trop compter sur les soumissions gratos."

Chacun son truc, plein de gens nous rapportent les failles gratuitement.

M'enfin! on te l'a déjà dit: Le code source sert à rien si c'est pas le binaire issu de sa propre compilation qu'on utilise...

Non ca c'est une belle connerie et rien d'autre. Il n'est pas tres complique de prendre un binaire et de verifier qu'il correspond a un code source donne de maniere automatique.

Dis-mois, sont vachement disciplinés ces gens ! Avec tout ce qu'on trouve en warez...
Si des gars de tf1 sont capable de balancer des films à diffusion très restreinte, je conçois mal comment un code diffusé à des milliers d'étudiants ne pointe pas le bout de son nez.

Ca s'appelle la menace de se prendre un gros proces en pleine figure.

Non, car tu ne peux pas divulguer le code et avec tout les NDA ça m'étonnerais que tu puisse divulguer (publiquement) l'existence d'une faille que tu as vu dans le code.

Si tu trouves une faille, tu la divulges, a nous. Si on ne fait rien, divulger une faille de maniere anonyme il n'y a rien de plus simple hein.

Il me semble (mais je peux me tromper) que pour éviter des fuites, tu n'as pas accès, en tant qu'employé, à tout le code source, seulement ce que tu as besoin pour travailler

Perdu, tu as acces a tout(cad t'es chez Windows t'as acces a Windows, pas Office). Les gens a l'exterieur idem.

Pour vérifier que pbpg ne dit pas des conneries.

Prends un job dans une des nombreuses universites ayant acces aux sources, dans un gouvernement ou dans n'importe quelle societe ayant >=1500 postes Windows et tu pourras verifier.

Le commentaire de pbpg est bourré de fuds, comme sa remarque sur les failles, ceci a été débattu plein de fois, mais on a toujours le droit aux mêmes remarques. Que les distribs aient plus/autant/moins de failles n'est même pas la question et ne change rien au fud qu'une distribution n'est absolument pas le même produit qu'un windows vendu quasi nu.

Oh mais rassures-toi, je compares pas une distrib entiere a Windows, je compares OS a OS en prenant les briques comprises dans un Windows uniquement. Suffit de prendre Firefox vs. IE pour voir ou se trouve le probleme. Tu remarqueras que le torchon de la FSF ne parle absolument pas de temps d'exposition hein, il dit specifiquement que Windows est rempli de vulnerabilites et insinue qu'on ne les patch pas ce qui est absolument faux et qu'une install Linux comparable a tout autant voire plus de vulnerabilities que nous.

La comparaison est plutôt difficile voir absolument pas représentative de la réalité. Sans parler qu'on ne connaît de windows que les failles publiées. Ce genre de concours de qui en a la plus grosse ne veut concrètement rien dire. Bref, j'ai connu un pbpg un peu plus inspiré qu'aujourd'hui.

Tu prends 1 patch de chez Redhat pour le kernel, il couvrira regulierement plus d'une faille, tout comme chez nous. Quand on compare le nombre de patchs sortis, ce probleme n'entre pas en compte vu qu'on s'amuse pas a sortir des patchs non-securite qui contiennent des patchs de securite en catimini.

Si j'en crois http://windowsitpro.com/article/articleid/40481/os-market-sh(...) Linux avait 22% du marche serveur en 2002, c'est loin d'etre insignifiant.

Avec une telle part de marche, il y a certainement des enterprises qui auraient voulu avoir ce support.