totof2000 a écrit 9656 commentaires

Tu savais que Charles Bronson est mort ?

5 ou 10 ans après sa mort, quelque chose comme ça.

Personnellement, je ne seais pas contre ce genre de prolongation (et peut-être plus) si les "ayants-droits" (famille) travaillaient avec les oeuvres de l'artiste défunt. Si ceux-ci ne font rien => domaine public.

????

Onduleur On-line

Le courant est converti en permanence en une alimentation continue en passant par la batterie de l’onduleur. Il est ensuite converti en courant alternatif par l’onduleur afin d’être délivré aux appareils. Ces derniers sont donc alimentés en permanence par la même source que ça soit en fonctionnement normal ou en cas d’incident ou de coupures.

Dans ce cas la batterie est toujours utilisée, que l'onduleur soit alimenté ou non => pas de temps de bascule

Onduleur Off-line

Un onduleur Off-Line fonctionne ainsi : lorsqu’une baisse ou surtension survient, un relais s’ouvre afin que la batterie fournisse l'énergie nécessaire. Le réseau électrique recharge les batteries en fonctionnement normal.

Le fonctionnement d'un onduleur off-line ne permet pas d'assurer une protection contre les micro-coupures. Dans ce cas, votre matériel court un risque, et un redémarrage de l'ordinateur peut survenir.

Dans ce cas il faut un temps de bascule pour passer sur batterie, le temps que l'onduleur détecte la perte d'alim.

Arch est une belle merde pour gérer des serveurs à grande échelle. Arch est une distrib pour les gens qui ont pour occupation principale la mise à jour et la réparation de problèmes.

Alors c'est seulement à ce niveau qu'on pourra raisonnablement penser que l'algo est sûr, c'est-à-dire qu'aucune porte dérobée n'a été introduite sciemment dedans.

Ce ne sont pas les algos qui ont des problèmes de portes dérobées, mais leur implémentation.

Il faut quand même faire attention au temps de bascule, surtout si on utilise un ou plusieurs disques externes : l'alim du PC peut supporter une coupure brève, mais je ne suis pas sur que les disques exernes auto-alimentés le puissent tous (tout dépend je suppose du prix). Le risque de perte de données dans ce as est non négligeable.

Non je ne pensais pas non plus faire faire ça par l'utilisateur.

Moi non plus, mais donner les droits à un client de pouvoir éteindre un serveur me parait "risqué" : une faille ou un problème de configuration pourrait permettre à un utilisateur d'élever ses privilègess et d'éteindre le serveur. Certes ce n'est pas fréquent, mais ça arrive assez souvent pour m'inciter à être prudent (et les découvertes de ces derniers temps en matière de sécurité me confortent dans cette approche).

Dans ce cas, personnellement, je suis un peu parano, et je ferais un peu différement. Je mettrais dans les taches d'extinction un script qui préviens le serveur que leclient s'éteint, puis le serveur vérifie lui-même que d'autres clients ne sont pas encore allumés avant de s'éteindre. On ajoute à ca un contrôle périodique (toute les 15 mn par exemple) pour ne pas rater les clients qui ne sont pas passés par une phase d'extinction propre (comme je ne connais pas le contexte, je suppose être en présence d'utilisateurs qui pourraient décider d'éteindre la machine en débranchant le cable d'alim).

Un dossier plus complet. Personnellement j'opterais pour un modèle de type "Line Interactive"

Ah, encore un autre lien : ça te permettra de comparer les informations.

soit à laisser le temps d'éteindre proprement les machines, soit laisser le temps à un système de secours de prendre le relai. Dans ton cas l'onduleur reste la meilleure solution. En général tu peux brancher ton onduleur sur ta machine (rs232, USB) pour que celui-ci prévienne ton système lorsqu'il se met en marche pour pouvoir éventuellement initier un arrêt propre.

Depuis 5 ans que je suis dans le quartier, les seules coupures sont soit des micro coupures (donc pas besoin que l’onduleur dure plus de 5 min, et même 30s suffirait dans 90% des cas), soit des coupures de plus d’une heure, ce qui fait que même si je me ruine pour acheter un onduleur qui tient 30min, ça ne servirait à rien.

De toute façon, pour les coupures longues, ce n'est pas un onduleur qu'il faut mais un groupe électrogène.

Pour en revenir à ta question initiale, j'ai trouvé ça

Tu supposes que le client passera automatiquement par le script pour éteindre le serveur ? Moi non.

peut être source de conflits pour KDE (avec le passage à QT 5 notamment).

Je crois que j'ai bien fait de laisser tomber KDE.

Un arrêt intempestif n'arrêtera pas le serveur puisque le script ne sera pas exécuté. Donc forcément après un plantage le client va relancer sa machine pour continuer à bosser.

Oui, mais dans le cas ou le client se plante et n'est pas démarré, le serveur n'est pas arrêté.

Même si un utilisateur est mal intentionné, il ne pourra pas nuire aux autres. Puisque si un autre utilisateur bosse sur sa machine le serveur ne sera pas éteint par la machine de l'utilisateur mal intentionné…

Et comment empêches-tu ça ?

Mauvaise idée pour au moins 2 raisons :
- tu ne prends pas en compte les arrêts intempestifs (oui, même sous Linux, une machine peut se vautrer)
- tu donnes aux clients le droit d'éteindre le serveur, ce qui pourrrait donner des idées à des petits malins.

Je ne fais pas confiance qux compagnies aériennes donc je ne prends pas l'avion :)

… et on aura droit à un gestionnaire de version pour la rédaction des lois : on évitera ainsi les affreux truc du genre "article machin ligne truc, le mot bidule remplace truc2". Et pour ceux qui le désirent sous cette forme, je suis sur q'une moulinette bien faite pourrait le sortir.

C'est le but de systemd : tout mélanger.

man je lis de haut en bas donc j'ai pas vu le commentaire déjà écrit avant d'écrire le mien.

man inittab : respawn.

Pas besoin de systemd.

C'est ça le rôle de systemd ? Créer des bugs pour ouvrir des rapports ?

C'est bien ce que je pensais : tu ne sais pas lire : j'ai fourni un exemple, que j'ai pu reproduire, et que d'autres ont pu reproduire. Même si ça ne constitue pas une preuve infaillible, je vois ça comme au moins "l'ombre du commencement d'un exemple concret".

Perso, j'ai eu cette impression depuis 2000-2001, jusqu'à 2011-2012, quasi jamais dans le cambouis par défaut, jamais dans la moindre config. pour un usage desktop. Et puis, cela a changé, pulseaudio (décalage du son et de la vidéo, mixer foireux, gestion des volumes cauchemardesque, intuitivité zéro et doc de merde …)/udev (ouais lui aussi)/systemd (Yeah boot impossible \o/) ont été raisons principales pour lesquelles j'ai du aller dans le bas niveau et cela a été galère : doc de merde (autant ne pas en faire), forum qui te disent d'installer tel app. graphique (qui ne résout rien), info dans les logs incompréhensible, …

Ce sont les raisons principales qui m'ont fait quitter Windows. Aujourd'hui j'ai l'impression que tu me décris Windows avec ses problèmes, les forums Windozeux etc …

pulseaudio qui ne marche pas et qui consomme beaucoup de CPU quand il arrive à faire sortir du son

T'inquiètes, bientôt tu auras systemd qui prendra 75% de puissance CPU d'un quad core pour ne rien faire.

… Devinez. :)

Ca dépend surtout ce que tu veux faire : le support du décodage vidéo hardware est semble-t-il meilleur sur la RPi. Par contre pour la bidouille électronique, la Beaglebone est bien mieux fournie. Personnellement j'ai les deux :)