Bonjour,
Init-ng est un remplacement du vieillissant System V init utilisé entre autre par les ordinateurs sous Linux pour démarrer.
La particularité d'init-ng, comme les autres remplaçants de SysVinit est de lancer les processus et démons non pas dans un ordre bien défini et les uns à la suite des autres, mais en parallèle et en fonction de dépendances.
Un autre avantage d'init-ng est qu'il n'utilise pas de scripts shell, mais des fichiers .i bien à lui. Bien sûr, il faut réécrire les scripts de démarrage pour les porter vers init-ng, mais une fois réécrits, ils sont bien plus rapides ! En effet, charger, pour chaque démon, un shell bash et un peu lourd. Debian avait avancé dans ce domaine en remplaçant Bash par Dash, ce qui amène déjà une grosse amélioration.
Les présentations étant faites, venons-en au fait. Il y a quelques semaines, j'ai fait quelques recherches sur un remplaçant du vieux init. Je suis tombé sur pas mal de résultats, dont beaucoup parlaient d'init-ng. J'essaie de trouver son site, mais pas moyen d'y arriver, il est down.
Les dernières activités d'init-ng (paquets Debian, trolls en sa faveur, etc) remontaient aux environs de 2005, comme souvent (c'est la sortie d'Ubuntu qui a tué le Libre de cette sorte ou quoi ? Plus de 50% des projets moyens s'arrêtent aux environs de sa sortie, comme sawfish, initng, Mandriva (qui a eu des problèmes mais qui se redresse), et même linuxfr qui était plus actif). Je pensais donc que le projet devait être mort et enterré depuis longtemps, avec tristesse (upstart, bon voilà quoi).
Et bien, j'avais faux ! Il y a deux ou trois jours, je retente d'accéder au site, en désespoir de cause. Et là, il marche, et même bien !
J'apprends que le développement a toujours continué, très fortement au ralenti. On peut même observer que le forum est couvert de spams, mais néanmoins, ce qui reste de la communauté (donc juste le mainteneur) a entamé ... une migration vers Git !
Ça, c'est bien commencer une semaine. Voir init-ng renaître de la sorte fut un grand plaisir, surtout que j'avais eu l'occasion de le tester (et effectivement, c'est bluffant de démarrer en 5 secondes (sans compter le kernel)). Je vois qu'il prépare même une version 0.7.0, mais sans avoir fixé de date.
Voilà, c'est tout ce que j'ai à dire. Testez init-ng, c'est intéressant. Pas mal de scripts sont fournis pour démarrer tous les services que vous voulez, et c'est assez stable. Aussi, plus du monde s'intéressera à init-ng, moins son mainteneur risque de partir.
Montrez tous que vous voulez un vrai système d'init, autre-chose que de simples scripts shell, quelque-chose d'intelligent, et plus léger qu'upstart !
PS: Oui il existe l'init des BSD, mais c'est aussi un script shell.
Journal Init-ng est encore vivant !
3
sept.
2009
# Pinit
Posté par liberforce (site web personnel) . Évalué à 7.
http://wiki.mandriva.com/en/Development/Howto/Pinit
[^] # Re: Pinit
Posté par liberforce (site web personnel) . Évalué à 5.
http://blog.crozat.net/2009/02/speedboot-explained.html
[^] # Re: Pinit
Posté par steckdenis (site web personnel) . Évalué à 4.
D'ailleurs, j'ai Mandriva sur un stick USB, et c'est vrai que ça décoiffe niveau démarrage !
[^] # Re: Pinit
Posté par karteum59 . Évalué à 3.
http://svn.uludag.org.tr/viewcvs/trunk/promotion/development(...)
# bsd
Posté par zecrazytux (site web personnel) . Évalué à 7.
ça ne me pose pas de problème de booter ma netbsd en 15s, kernel compris
[^] # Re: bsd
Posté par claudex . Évalué à 10.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: bsd
Posté par bibitte . Évalué à 0.
Bref le sujet c'était pas qui démarre le plus vite c'était juste de montrer qu'il existe des alternatives prometteuses qui pourrons surement encore accélérer le démarrage de nos pc.
[^] # Re: bsd
Posté par zecrazytux (site web personnel) . Évalué à 1.
Bref le sujet c'est que la description d'initng sur la page du projet c'est que c'est pour acceler le boot, donc on parle bien de "démarrer plus vite", ne t'en déplaise, et bien que je trouve important d'avoir des alternatives, je n'ai pas envie, ne trouve pas d'interet, à changer d'init actuellement.
remarque que c'est à peut pres pareil sur ma Debian avec dash, modulo que tous les services installés sont quasi toujours lancés par défaut à chaque boot (et que sur une machine de boulot t'es tenté de tester etc, donc beaucoup de services) alors que sous NetBSD faut le vouloir.
[^] # Re: bsd
Posté par bibitte . Évalué à 1.
Sinon c'est juste histoire de placer une boutade.
mais encore un truc me turlupine : Es-tu barbu ?
[^] # Re: bsd
Posté par zecrazytux (site web personnel) . Évalué à 3.
et pour répondre à ta question: non, je ne suis pas barbu. Du tout :)
[^] # Re: bsd
Posté par bibitte . Évalué à 4.
Sinon pour la barbe je suis déçu!! les valeurs se perdent de nos jour!!
ca devient n'importe quoi ce commentaire (ca doit etre le vendredi)...
[^] # Re: bsd
Posté par zecrazytux (site web personnel) . Évalué à 3.
# Script shell
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
Pour moi, une grande force d'UNIX est justement d'avoir encore plein de bout de sa config qui se font en script (BASH pour la plupart). Je ne suis pas sur que mettre de la syntaxe avec du méta langage permettent à terme une telle souplesse et une telle durée de vie.
On peu avoir un init en script qui soit parallèle...
[^] # Re: Script shell
Posté par steckdenis (site web personnel) . Évalué à 7.
Et puis, qu'est-ce qu'il y a de mal là-dedans ?
service system/usplash {
exec start = /bin/true;
exec stop = /sbin/initng-usplash-shutdown;
}
C'est simple, rapide à parser, et ça évite de réinventer la roue (pas mal de scripts init standards commencent par une définition de $PATH, contiennent le fameux swtich pour start, stop, reload, etc).
[^] # Re: Script shell
Posté par fearan . Évalué à 9.
si dans un service, je ne sais pas moi, timidity, par exemple, je souhaite ajouter une commande en plus de start/stop/status/restart, que pour le plaisir de l'exemple j'appellerai balsa qui me redémarrerai le service avec un backend alsa ( ou pulseaudio si il est déjà en alsa), il va falloir que le système remplaçant les script me le permette (et ce n'est qu'une subtilité parmi tant d'autre...).
Alors oui y a moyen de faire accélérer le schmilblik, y a même pleins de piste explorée (remplacer bash par dash, supprimer au maximum les appels aux fonctions externes (remplacer les basename et dirname par leur équivalent en bash), ne pas recharger 50 fois le même PATH
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Script shell
Posté par vincent_k (site web personnel) . Évalué à 10.
[^] # Re: Script shell
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Moi je suis pour rester simple, orthogonal, indépendant... Cela permet la robustesse mais aussi l'évolution.
[^] # Re: Script shell
Posté par Octabrain . Évalué à 5.
[^] # Re: Script shell
Posté par nodens . Évalué à 5.
Dans le cas contraire, t'es pas prêt de voir ça par défaut dans les distributions (ou alors, pas dans une distrib que j'installerais dans un cadre pro).
Quand c'est un script shell, même si c'est pas compatible LSB au moins c'est facile de rajouter la compatibilité. Là tout le travail est dans les mains de la distribution (les mainteneurs upstream se donne rarement la peine de faire des scripts d'init pour d'autres distributions que celle qu'ils utilisent ou qu'on leur a contribués, alors des scripts pour des système alternatifs)...
[^] # Re: Script shell
Posté par beagf (site web personnel) . Évalué à 2.
Tu te retrouve à dépendre d'un logiciel compatible avec les scripts init-ng au lieu de dépendre d'un système ayant un shell compatible bourne.
Bien sûr, pour l'instant il y a plus de réimplémentations du bourne shell que de init-ng, mais est-ce une preuve que techniquement c'est mieux ?
[^] # Re: Script shell
Posté par Octabrain . Évalué à 2.
Puis pour le troll du vendredi, les formats style xml/yaml diminuent le problème de la syntaxe de la conf qui peut changer tout le temps, mais il reste le problème de la sémantique du contenu de la conf.
[^] # Re: Script shell
Posté par totof2000 . Évalué à -4.
[^] # Re: Script shell
Posté par thedude . Évalué à 1.
C'est marrant, sous windows ou macos, tout le monde s'en cogne du temps de boot parce que la mise en veille/hibernation marche et que les boots sont donc generalement limites aux updates necessitant un reboot (soit une fois par mois sous windows et je sais pas trop quand sous macos).
La ou sous linux, tout le monde a tellement la petoche de voir sa sessions exploser en plein vol qu'on est oblige d'eteindre sa machine tous les jours, d'ou l'importance d'un boot rapide.
[^] # Re: Script shell
Posté par suJeSelS . Évalué à 7.
Et au passage, j'ai une machine avec macos et l'hibernation bug souvent (sympa le portable qui se réveille tout seul dans un sac et plutôt pratique pour se cuire un steak en arrivant), alors que la même machine avec une debian hiberne sans problème.
[^] # Re: Script shell
Posté par thedude . Évalué à -4.
ben voyons.
Ca a deja ete discute ici longuement.
Deja ca ne concerne que les updates de secu, faut etre precis, hein ;-)
De source sur, ni windows ni macos ne requiert un redemarrage apres une update non critique.
Le probleme est que le navigateur/lecteur (ou plutot ses libs) ont ete mises a jour sur le disque, mais en ram tu as toujours l'ancienne version ('fin si elle est chargee, evidemment).
Si tu veux faire les choses proprement, tu as deux choix:
- quitter ta session ou redemarrer (ca revient au meme en pratique)
- traquer tous les process qui pourraient avoir une dependance sur les libs updates, les fermer proprement et les redemarrer.
Le premier choix est simple, 100% fiable et (relativement) rapide.
Le deuxieme est tres complexe a mettre en oeuvre, long et tu risques d'oublier qq chose.
Conclusion: si ton gnu/linux ne te demande pas de rebooter apres une update de navigateur, c'est que soit l'update etait mineure, soit ta distrib n'inspire pas confiance.
Quand a ton probleme avec macos, je suis pour le moins dubitatif.
apres 3 laptops chez eux, le seul qui deconne, c'est mon ibook vieux de 5 ans, qui a un probleme de contact physique ecran ferme (en clair: le capteur qui determine si l'ecran est ferme croit qu'il est ouvert et lance donc la sortie de veille).
Enquete peut etre de ce cote la...
Et pour finir, je suis tres content pour toi que l'hibernation fonctionne sur ta debian, mais mon point etait plutot de dire que dans le cas general, c'est plutot casse gueule comme operation, et surtout, on verra si elle marche encore a la prochaine update du kernel, l'hibernation.
[^] # Re: Script shell
Posté par Sphax . Évalué à 6.
Une mise à jour d'un navigateur devrait demander un reboot ?
C'est une blague ?
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.
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.
Sous Linux, j'ai besoin de rebooter uniquement si j'ai mis à jour le kernel. Le reste c'est pas nécessaire.
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...
[^] # Re: Script shell
Posté par thedude . Évalué à 0.
Et non, c'est pas une blague du tout.
Pour faire court.
Pour le navigateur: mon petit doigt me dit que les applications de ton bureau qui affichent du html sous quelque forme que ce soit (aide, composant UI ou que sais je encore) ne vont pas reimplementer un moteur html mais plutot se baser sur celui du systeme.
Si ton navigateur est un tant soit peu bien fait, le navigateur en lui meme n'est qu'un front end se basant sur un moteur de rendu.
Et les applications tierces vont se baser sur ce moteur pour rendre le html quand elles en ont besoin.
Sur une update non triviale, ya de grandes chances pour que le moteur de rendu soit mit a jour.
Et pas de bol, la probabilite pour que ton moteur de rendu soit loade par une quelconque appli dans un bureau en utilisation est non negligeable (pour ne pas dire egale a 1).
Je sais pas trop comment fonctionne gnome, mais je met ma main a couper qu'une update un tant soit peu consequent a konqueror implique de redemarrer la plupart des applis kde (si ce n'est le bureau entier) pour etre reellement appliquee.
et bien il suffit de tuer la session X et la relancer, c'est BEAUCOUP moins long qu'un reboot complet.
Ben ca depend ce que tu prend en compte.
C'est sur que juste relancer le bureau, c'est assez rapide.
Sauver tout mon travail en cours, verifier que tout va bien, quitter, me relogger, relancer le tout, ca va etre vachement plus long par contre, et meme si toujours plus rapide qu'un reboot, ca me demande d'arreter de bosser, context switch tout ca, et au final, redemarrer le bureau ou la machine, je vois pas la difference fondamentale.
Sous Linux, j'ai besoin de rebooter uniquement si j'ai mis à jour le kernel. Le reste c'est pas nécessaire.
Ah, bien.
Et si t'as libssl qui est mit a jour? libxml? libpng? synaptic te patches a chaud la version en ram aussi?
[^] # Re: Script shell
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Déjà, si tu ne sauvegardes pas régulièrement, tu es mal barré. Coupure de courant, bogue, crac, travail perdu.
Quant au temps gagné à éviter de redémarrer, il suffit de voir la différence, déjà sensible, entre un redémarrage matériel et un rechargement du noyau par kexec pour s'en rendre compte.
[^] # Re: Script shell
Posté par thedude . Évalué à 1.
Qu'est ce qu'on ferait pas comme pirouette pour proteger son os cheri d'une remarque pourtant fondee.
Bon, si tu veux.
Dire a mes contacts sur IM que je doit rebooter, verifier que je suis pas en train de transferer/downloader un fichier qq part, que j'ai pas un collegue connecte sur mon serveur en train de faire qq chose, que j'ai pas un calcul en cours que si je l'interrompt, je repart pour 2h00 de calcul, que j'ai pas un post sur linuxfr non envoye dans un onglet chrome, que j'ai pas des journeaux/depeches ouverts dans linuxfr que si je ferme je vais perdre les nouveaux commentairs, bref, la liste peut etre longue...
[^] # Re: Script shell
Posté par suJeSelS . Évalué à 3.
À priori ton gestionnaire de packets connait les applications dépendantes de la librairie, donc il est assez simple d'identifier les processus associés. S'il n'est pas capable de lister correctement les applis dépendantes de la mise à jour, tu risques d'avoir pas mal de choses cassées et des problèmes plus sérieux à court terme que la compromission de la sécurité.
[^] # Re: Script shell
Posté par thedude . Évalué à 2.
- meme si le gestionnaire de paquet a la liste des applis, il ne te la communique pas,
- et il ne fait rien pour s'assurer que les applis ont bien ete relancees
Et si en plus dans les dependances, t'as un systeme service bas niveau, ben les chances pour devoir redemarrer vont etre tres grandes de toutes facons...
note au moinsseurs: je ne fait pas une critique contre linux, j'explique juste pourquoi "je ne doit rebooter que quand le kernel est patche" est faux et dangereux comme raisonnement.
[^] # Re: Script shell
Posté par geb . Évalué à 7.
[^] # Re: Script shell
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: Script shell
Posté par thedude . Évalué à -3.
merci pour cette tranche de rire.
[^] # Re: Script shell
Posté par pasBill pasGates . Évalué à 7.
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.
[^] # Re: Script shell
Posté par benja . Évalué à 4.
Pas besoin d'enfoncer le clou comme cela hein. Tu dis sensiblement la même chose que lui, pinaillage offert...
(Dans le contexte, celui d'une mise à jour ou remplacement de fichiers systèmes, cela nous fait une belle jambe de savoir que 2 process peuvent lire le même fichier; "le verrou exclusif" se comprend bien sûr "empêcher le remplacement" ).
[^] # Re: Script shell
Posté par pasBill pasGates . Évalué à -1.
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.
[^] # Re: Script shell
Posté par rewind (Mastodon) . Évalué à 7.
Faux !
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.
Conclusion : il n'y a bien qu'une mise à jour du noyau qui oblige à un reboot sous Linux.
[^] # Re: Script shell
Posté par pasBill pasGates . Évalué à -5.
C'est super, ca revient a redemarrer tous les processus quoi, vachement different d'un reboot...
[^] # Re: Script shell
Posté par suJeSelS . Évalué à 7.
[^] # Re: Script shell
Posté par zebra3 . Évalué à 3.
Même le processus init est relancé tranquillement sans même avoir à quitter sa session X.
Après, je ne sais pas comment c'est possible, mais je comprends sa phrase comme : tout se relance en arrière-plan.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Script shell
Posté par pasBill pasGates . Évalué à -1.
Sur un desktop : les softs clients + services doivent etre relances, car se sont les vecteurs d'attaque --> equivalent a un reboot du point de vue du systeme
Alors oui, tu peux te retrouver sur ton desktop avec tes softs clients non-patches et tes services d'arriere plan patches, super, t'es a moitie-protege...
[^] # Re: Script shell
Posté par meh (site web personnel) . Évalué à 8.
[^] # Re: Script shell
Posté par thedude . Évalué à -3.
Que ca soit 45 ou 60 ou 90 secondes, c'est pas ca qui compte vraiment...
Du point de vue experience utilisateur (ou pour utiliser un terme moins pompeux: la gene occasionnee pour l'utilisateur), ca revient au meme: l'utilisateur doit arreter tout ce qu'il fait, casser sa concentration, pour relancer toutes ses applis et remettre son bureau dans l'etat dans lequel il etait.
Tu pourrais booter en 2 secondes, l'utilisateur serait tout aussi emmerde.
Du point de vue utilisateur, quitter son bureau puis se relogger, c'est la meme gene que redemarrer la machine.
Qu'il ait le bootsplash de windows pendant 30 secondes en plus ne fait pas une difference fondamentale.
C'est un peu une des regles de base en termes d'IHM: dans le fond, on se fout de savoir combien de temps ca prend techniquement, ce qui est important, c'est le temps/gene percu par l'utilisateur.
En fonction de comment l'interface est designe, une UI techniquement moins performante pourra etre percue comme plus performante en fonction du feedback et de ce genre de chose.
J'ai eu un exemple frappant au boulot, le simple fait de rajouter un wait cursor a droite a gauche dans l'appli a fait que les testeurs ont trouve l'appli plus reactive.
Et pourtant, les temps de reponses sont *strictement* les memes (on a simplement passe un flag de false a true quand on envoie les requetes au serveur).
A l'inverse, sur des parties ou les temps de reponses etaient suffisament rapides pour donner l'impression de travailler en local, le wait cursor leur a donne l'impression que ces parties avaient ralenti.
Bref, bottom line: l'UI etant un domaine tres subjectif, le caracteristiques techniques pures sont moins importantes que le ressenti de l'utilisateur.
[^] # Re: Script shell
Posté par briaeros007 . Évalué à 10.
Donc une interruption de services de 5 à 10 minutes (temps que toutes les cartes raid boot, que le système vérifie les trucs etc...) c'est la même chose qu'une interruption de service de 3sec.
Rapelle moi la boite où tu travailles ...
[^] # Re: Script shell
Posté par thedude . Évalué à -4.
Nan parce que la on parle de desktop et des temps de boots < 120 secondes, ton serveur de prod avec carte raid qui boote en 15 minutes, je vois pas trop ce qu'il vient faire dans la discussion...
Rappelle moi ou t'as appris a lire, que j'y envoie pas mes gosses...
[^] # Re: Script shell
Posté par briaeros007 . Évalué à 8.
Non. on parle des mises à jours et du besoin qu'a windows de redemarrer pour des mise à jour.
Allez je t'aide, tu remonte de 2 commentaires (pas trop dur, tu arrives encore à compter ?)
Sur un serveur: les services doivent etre relances, car ce sont les vecteurs d'attaque--> equivalent a un reboot du point de vue du service rendu par le systeme
Donc pour toi un desktop c'est un serveur...
tu disais quoi à propos de la lecture en fait ?
[^] # Re: Script shell
Posté par thedude . Évalué à -4.
T'es toujours aussi con toi...
T'en es reduit a attaquer sur des points de details pour (tenter) de prouver que ce que je n'ai pas dit est faux.
Va donc falloir m'expliquer pourquoi est ce qu'on n'arrete pas de parler de kde, gnome, relancer X et tout ce genre de choses.
Je sais bien compter effectivement, et quand je remonte de un (1) commentaire (sans s du coup) a compter du message auquel tu as repondu, je vois que ca parle de relancer X, c'est clair qu'on est en contexte serveur dis donc.
Mais bon, j'aimerais savoir ou tu bosses toi aussi sinon, histoire de savoir quelle bande de clampins fait des reboots de maintenance sans avoir un spare pour assurer la continuite du service.
[^] # Re: Script shell
Posté par briaeros007 . Évalué à 4.
parce que pour réussir à partir sur un delierium tremens aussi corsé, et une telle poutre dans tes yeux, excuse moi de te dire que tu es un vrai champion.
sisi, parce que me dire que je sais pas lire parce "qu'on" parlais de desktop, alors que 2 post avant le tien c'était de serveur, et quand je te le fais remarquer dire que c'est "un point de détail" (alors que ca ne semblait pas du tout un point de détail quant tu as voulu me reprendre).
bref, toujours aussi puant, toujours aussi de mauvaise fois, toujours aussi aggressif, et tes commentaires, excuse moi, toujours aussi nul et inutiles.
[^] # Re: Script shell
Posté par thedude . Évalué à -1.
Note que je m'attendais pas a te voir reconnaitre ton erreur, le jour ou tu feras ca... Meme le nez dans la merde tu continueras a affirmer que ca sent bon.
Bref, bref, bref...
Marrant quand meme, tout le fil parle de X, de gnome, de kde, d'installer un navigateur ou un lecteur multimedia, de relancer le bureau, de visual studio, de bureau qui met 5 minutes a etre utilisable.
Mais il suffit que pbpg ait mentionne une fois le mot serveur pour que ta distortion de la realite prenne le relais et hop la, on parlait de serveur sur tout le fil.
[^] # Re: Script shell
Posté par thedude . Évalué à 1.
On parle pas de windows, mais de la problematique de s'emboucanner a relancer toutes les applis dependant d'un bout de soft mit a jour contre celle de faire simple et de rebooter la machine.
C'est valable pour Linux ou windows (ou macos ou sunos ou gnu/hurd meme si tu veux, Multidesk OS n'etant pas concerne), c'est pas le probleme.
Mais faut croire que la simple presence de pbpg et de moi meme dans la discussion te font passer en mode "mais t'avec eux ou contre moi?" et que ca en devient donc necessairement un windows contre linux.
Marrant quand meme ta mentalite bipolaire.
[^] # Re: Script shell
Posté par briaeros007 . Évalué à 5.
Non non pas du tout. On parle de l'emboucannement des choux et du replantage complet des carottes pour les arroser.
[^] # Re: Script shell
Posté par suJeSelS . Évalué à 2.
[^] # Re: Script shell
Posté par phoenix (site web personnel) . Évalué à 1.
Merci Linux (RAID soft)
[^] # Re: Script shell
Posté par thedude . Évalué à 1.
Je parle pas du raid soft hein...
[^] # Re: Script shell
Posté par suJeSelS . Évalué à 4.
[^] # Re: Script shell
Posté par zebra3 . Évalué à 1.
Mais je ne suis pas développeur, je pars peut-être dans quelque chose d'aberrant, et puis ça doit dépendre de l'OS.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Script shell
Posté par pasBill pasGates . Évalué à 7.
La technique tu hotpatching permet de modifier des bouts de code a chaud tant qu'ils ne touchent pas aux structures de donnees, mais decharger/recharger une librairie a chaud de maniere generale c'est complique.
[^] # Re: Script shell
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
C'est intéressant comme concept et je pense que cela va se propager petit à petit comme philosophie. Déjà avec le noyau et ksplice, on peut recharger un module à chaud...
Pour les serveurs, on pourrait laisser le serveur traiter les requêtes en cours et utiliser la nouvelle version pour les requêtes suivantes... C'est un peu ce que fait ssh lorsqu'on le relance. J'utilise comme QPSMTP comme serveur de mail qui fork pas mal d'instance pour répondre à la charge et régulièrement, il fork son processus principal... Une mise à jour se fera donc automatique au fork suivant (c'est pas un fork au sens UNIX du terme...). Parfois, on n'est pas à 10mn pour une mise à jour de sécurité si on peut éviter un interruption de service.
[^] # Re: Script shell
Posté par Sphax . Évalué à 4.
Gnome aucune idée, mais sous KDE l'affichage du HTML se fait avec khtml. Donc quand je met à jour les kdelibs, ben je relance ma session X.
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.
Certes, beaucoup de gens en ont peut-être rien à faire..mais moi j'aime pas redémarrer, déjà parce que lors du boot pas mal de temps est passé dans le bios, alors j'évite.
T'as oublie la glibc
Yep. Apparemment sous Debian c'est géré, sous Arch linux non.
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.
Ouais, mais ça me dit pas pourquoi ils ont besoin d'un reboot si tout marche directement après l'installation.
[^] # Re: Script shell
Posté par bubar🦥 (Mastodon) . Évalué à 4.
[^] # Re: Script shell
Posté par kowalsky . Évalué à 2.
Tu installes tout et tu reboot après.
[^] # Re: Script shell
Posté par Batchyx . Évalué à 3.
[^] # Re: Script shell
Posté par briaeros007 . Évalué à 3.
Pour toi changer le nom de la machine c'est une update "critique" ?
Parce que j'ai testé
windows 200
2003
2003 R2
et 2008
ils demandent TOUS de rebooter après avoir changer le nom de la machine
et crois pas que tu puisse dire "je redemarrerais plus tard", parce que tu peux plus ajouter de roles à ton serveur tant que tu as pas rebooter.
Alors ta source sur, je crois que tu verrais bien de la revoir
[^] # Re: Script shell
Posté par thedude . Évalué à -2.
C'est moi ou on parlait de mettre a jour les programmes/libs sur la machine et tu debarques avec tes gros sabots en nous parlant de la configuration de la machine?
A moi que t'aies encore lu en diagonale, facon: "thedude, windows, reboot, il a tord, j'ai raison, linux est mieux de toutes facons" et que tu soit (encore) completement passe a cote de la discussion?
[^] # Re: Script shell
Posté par Batchyx . Évalué à 4.
[^] # Re: Script shell
Posté par volia . Évalué à 7.
C'est faux.
Je viens d'installer Visual Studio (version beta 1 de 2010) sur une machine Windows 2003, eh bien il m'a fallu 4, oui quatre, redémarrages pour que l'installation se fasse jusqu'au bout.
Pourtant, ce n'est pas une mise à jour de sécurité...
[^] # Re: Script shell
Posté par boulde . Évalué à 3.
[^] # Re: Script shell
Posté par pasBill pasGates . Évalué à 0.
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...
[^] # Re: Script shell
Posté par Maclag . Évalué à 2.
Je me permets de te dire que je ne suis pas d'accord:
La veille marche bien sur mon portable sous XP (bon, j'ai galéré pour la faire remarcher après augmentation de la RAM, mais c'est une toute autre question...).
Donc, en sortant de veille, ça démarre vite, quelques secondes à peine. Cool.
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!
(Je n'installe jamais de freeware/shareware/jeu débile/appli benchmark pour avoir la plus grosse et autre connerie sur mon ordi. C'est l'ordi du bureau, j'essaie de le garder aussi propre que possible).
Alors c'est sûr, j'installe pas de nouveau driver tous les jours, je ne change pas le nom de ma machine tous les jours. Seules les mises-à-jour demandent de redémarrer. 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...).
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!
[^] # Re: Script shell
Posté par pasBill pasGates . Évalué à 0.
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).
[^] # Re: Script shell
Posté par gemegik . Évalué à 3.
Même raisonnement pour le bios, qui prend énormément de temps.
[^] # Re: Script shell
Posté par Etienne Bagnoud (site web personnel) . Évalué à 5.
Mais Debian n'est pas représentative des distributions Linux, c'est la seule qui fonctionne vraiment.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Script shell
Posté par Yannick . Évalué à 1.
Sous Linux, la mise en veille en RAM fonctionne très bien. Sous Vista, elle fonctionne aussi très bien. Le problème sous Vista, c'est que dès que je bouge la souris, ça réveille l'ordinateur ce qui est plutôt gênant dans le cas d'un portable que l'on veut déplacer ou mettre de côté.
Donc, si je devais me servir de Vista, j'éteindrais beaucoup plus souvent mon portable que sous Linux. ;-)
[^] # Re: Script shell
Posté par bubar🦥 (Mastodon) . Évalué à 4.
[^] # Re: Script shell
Posté par steph1978 . Évalué à 6.
il est inutile, en effet, de révolutionner un OS pour ganger 10s de boot quand on reboot très rarement; pour un serveur par exemple.
or, pour un portable, on a besoin d'un boot très rapide. d'abord parce que la veille coute en batterie et que l'hibernation ne marche pas si bien que ça.
j'en viens à mon idée.
qu'est ce qui empêche d'avoir un init basé sur un shell pour les distributions serveurs, stable, standard et facile à adapter à ses besoins.
et un init basé sur qqch de plus rapide, de moins flixible mais simple.
je pense qu'un boot rapide (<10s) peut repositionner linux sur le marché des laptops (je le souhaite); c'est d'ailleurs ce que tente certaines distribs, moblin en tête.
[^] # Re: Script shell
Posté par bubar🦥 (Mastodon) . Évalué à 0.
c'est quoi, exactement, en fait ?
d'après wikipédia, ReBoot est une série télévisée, rien d'autre.
d'après nous, qui employons si mal notre belle langue ;) il s'agit de re-démarrer un ordinateur.
mais en fait rebooter est ce re-démarrer un ordinateur ou re-démarrer un O.S.
Par exemple, si je change de nom de machine, il me faut, par prudence, fermer toutes les connections au système. Sur Linux cela suffit.
Si je veux re-demarrer la machine, ben je "reboot" selon le terme communément employé, jusque dans les traductions des IHM. (ils sont où nos ayathollas -bien aimés- de la langue française ?)
Mais finalement lorsque je reboot mes machines, à titre personnel, je me contente de re-démarrer le système d'exploitation, et non pas la machine elle même. Kexec est notre ami (et on ne peux que regretter l'absence de prise en compte de kexec par les nouveaux systèmes de type pinit / init-ng / upstort, ou alors l'inverse ? que sais je ? je comprends que kexec ne puisse être déployer par défaut car des matériels ne le supportent pas (ou l'inverse...) mais chez moi ça marche (c) sur toutes les machines, et donc ces machines ne revoient que très rarement leur bios. Rebooter reviens juste a re-démarrer le système, et la machine.
[^] # Re: Script shell
Posté par bubar🦥 (Mastodon) . Évalué à 2.
(chez moi) rebooter reviens juste a re-démarrer le système, et la PAS machine.
[^] # Re: Script shell
Posté par 2PetitsVerres . Évalué à 2.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Script shell
Posté par iderrick . Évalué à 1.
[^] # Re: Script shell
Posté par claudex . Évalué à 4.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Script shell
Posté par iderrick . Évalué à 2.
# eINIT & Kyuba
Posté par nonas . Évalué à 3.
[1] http://einit.jyujin.de/
[2] http://kyuba.org/kyuba
[^] # Re: eINIT & Kyuba
Posté par steckdenis (site web personnel) . Évalué à 3.
Je ne me suis pas particulièrement intéressé à ceux-là. Il faut dire que eInit est ouvertement abandonné, et Kyuba ouvertement expérimental (mais sans être développé) et noyé dans un site qui parle de tout sauf de lui.
Bref, ils ne sont pas attirants du tout (et absolument pas connus, contrairement à init-ng).
Sans compter qu'ils sont beaucoup moins documentés (il n'y a qu'à regarder la page de téléchargement de Kyuba : la page standard de téléchargement d'un site basé sur Drupal, juste du code, pas de documentation. On ne sait même pas si le machin utilise des scripts shell ou son propre format).
# Sans changer d'init
Posté par Croconux . Évalué à 6.
est apparemment basé sur insserv de Suse[2] donc je suppose que ça marche aussi sur Suse.
En gros, les scripts d'init doivent contenir des commentaires formatés indiquant de quoi ils ont besoin pour fonctionner. Un script va ensuite (si nécessaire) modifier l'ordre de démarrage des scripts (liens Sxxx/Kxxx). Tous les scripts avec le même numéro son lançables en parallèle. Au démarrage, si la parallélisation est activée, il n'est plus nécessaire que l'exécution d'un script soit terminée pour attaquer le suivant s'il n'y a pas de dépendance.
[1]http://wiki.goatpr0n.de/blog/2008/04/09.speed.up.debian.boot(...)
[2]http://susefaq.sourceforge.net/faq/services.html
[^] # Re: Sans changer d'init
Posté par grid . Évalué à 6.
# Qu'en est t'il de OpenRC ?
Posté par jujubickoille . Évalué à 1.
[^] # Re: Qu'en est t'il de OpenRC ?
Posté par bubar🦥 (Mastodon) . Évalué à 2.
http://www.gentoo.org/doc/fr/openrc-migration.xml
De là à dire que c'est similaire, je m'abstiens, me contentant de dire que le but recherché est similaire. Une différence très notable est que init-ng n'est plus compatible sysV, tandisque OpenRC (et d'autres solutions comme Pinit) conservent une compatibilité.
Compatibilité nécessaire me semble t il tant que tout les programmes dont à besoin sans en avoir la maitrise, ne seront pas passer à un autre que sysV. Typiquement en contexte professionnel.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.