The Uptime Project à la française

Posté par  . Modéré par Nÿco.
Étiquettes :
3
13
mai
2009
Communauté
En ces temps sombres de l'HADOPI, il va devenir difficile de rester connecté à l'Internet. Les plus malins (ou les plus chanceux ?) pourront arborer un bel uptime sur cette toute nouvelle mouture du Tugs Uptime Project (TUP). Souvenez vous de l'Uptime Project, concours du plus gros uptime, cette aventure allemande qui a pris fin en mars 2007. Deux ans après voici la version 2.1 de son remplaçant français !

Quelles nouveautés ? Dans ce contexte actuel où les machines sont de plus en plus stables, quel pouvait être l'intérêt de réaliser un nouvel uptime project ? La première chose, c'est le fun, le « moi j'ai la plus grosse ». Ensuite, le côté libre du projet. Tous les clients sont des logiciels libres sous licence GPL. Tout le monde peut fabriquer son client à partir des spécifications disponibles sur le forum. Ce qui implique que bon nombre de clients ont déjà vu le jour (Linux, Windows, Solaris, FreeBSD, Mac OS X), et notamment des clients pour vos routeurs. Bientôt peut-être y aura-t-il des clients pour vos téléphones ! Seule l'imagination nous limite.

J'en vois déjà qui en sont à la moitié de leur client overclocké. Pourquoi tricher ? Oui tout est ouvert. Mais vous vous doutez bien que vous serez repéré rapidement et que cela ne présente que peu d'intérêt au final. Il n'y a rien a gagner. C'est juste là pour être là. Comme l'uptime de votre machine au final. Rejoignez-nous sans plus attendre pour tester cette nouvelle version du site web. Vous pouvez même nous aidez à la déboguer. À bientôt sur le TUP !

Aller plus loin

  • # Parfaitement inutile...

    Posté par  (site web personnel) . Évalué à 10.

    et surtout anti-écologique au possible. Franchement, quel intérêt ?
    • [^] # Re: Parfaitement inutile...

      Posté par  (site web personnel) . Évalué à 3.

      j'allais faire la même remarque, pensez plutôt à éteindre votre/vos machines si vous ne vous en servez pas, économique et écologique c'est pas si courant (sans mauvais jeu de mot) que demande le peuple...

      https://damien.pobel.fr

    • [^] # Re: Parfaitement inutile...

      Posté par  . Évalué à 8.

      Oui on a déjà eu cette remarque souvent. Etant le gestionnaire du site, je me permet de répondre :)

      Ce qui nous intéresse (même si nous n'empêchons absolument pas des utilisateurs avec des portables ou des PCs domestiques de s'inscrirent et de participer), ce sont les machines de type "serveurs" .

      Par définition, un serveur est, souvent, une machine qui rend un service continu. de ce fait, elle reste allumée, qu'elle soit sur le Tugs Uptime Project, ou pas. En ce sens, cela n'a rien de "moins" écologique (on rentre ensuite dans une discussion beaucoup plus globale qui n'est en rien liée au TUP) .

      Voila pour l'aspect anti-écologique . Cela étant précisé, pour ma part, je recycle mes déchets (plastiques et verres séparés), j'ai un économiseur d'eau sur mon circuit domestique et je dois avoir 80 % des ampoules en basse conso chez moi. et toi ? :p
      • [^] # Re: Parfaitement inutile...

        Posté par  (site web personnel) . Évalué à 7.

        Un uptime trop gros sur un serveur c'est signe d'un mauvais admin.
        Vive les failles dans le noyau !

        Qui utilise vraiment ksplice ?
        • [^] # Re: Parfaitement inutile...

          Posté par  . Évalué à 10.

          C'est toujours rigolo de lire ça :) . En quoi patcher et rebooter un serveur dns en lan de prod (loin, bien loin des DMZ) pour une faille dans la sous routine de création d'un tunnel ipsec (c'est n'importe quoi, c'est un exemple ;) est intéressant ? :p

          A mon humble avis, entre un admin qui patche avec le dernier noyau sortie, sans savoir ce qu'il patche , et un autre qui laisse parce que le patch ne concerne aucune fonctionnalité du serveur, j'embauche le deuxième ^^ (d'autant qu'un changement de kernel peut emmener des effets de bord, surtout si on ne teste pas l'upgrade dans des environnements d'intégration d'abord)

          et puis, certains système n'ont pas besoin de rebooter pour certaines familles de patch (Solaris hors des combo kernel patch)


          que d'idées reçues ^^
          • [^] # Re: Parfaitement inutile...

            Posté par  (site web personnel) . Évalué à 3.

            Je suis tout à fait d'accord avec toi, on ne patch/reboote pas un serveur pour une faille exploitable uniquement en local alors que les accès sont restreint uniquement aux administrateurs. On attend la prochaine opération de maintenance électrique (private jok ;) ).

            Pour certains serveurs (je pense aux serveurs web), cela peut sembler délicat. en effet les exploitations des applications web sont très courantes. Tout cela est affaire de logique ! Évaluer les risques etc.

            Dans tout les cas, on patche pas à la vas-vite, sans tests etc. Surtout dans des environnements exotiques qui demandent des modules bizarroïdes (on peut pas se permettre que le serveur reste en rade pendant des lustres parfois...).

            Donc oui l'uptime serveur a un sens mais n'est pas une fin en soit bien sur, ni un objectif !

            Après c'est sur qu'un serveur avec plusieurs années d'uptime ca fait long :)
            • [^] # Re: Parfaitement inutile...

              Posté par  . Évalué à 2.

              Certes :) . cela dit, certains systèmes ne sont pas fait pour rebooter ou sont même fait pour ne jamais rebooter. Je pense en particulier aux clusters OpenVMS .

              Il n'est pas rare de voir du Solaris ou du z/os avec plusieurs années d'uptime.

              Quoi qu'il en soit, il s'agit bien d'un site "fun", bien sur, l'uptime n'est pas une fin en soit et nous restons heureux d'accueillir tout à chacun, qu'il soit petit ou gros uptimeurs .

              Dans tous les cas, merci à linuxfr d'avoir relayé cette information (merci à notre développeur Windows thargos de l'avoir posté :) et au plaisir de vous voir sur notre forum .
            • [^] # Re: Parfaitement inutile...

              Posté par  . Évalué à 2.

              Pour certains serveurs (je pense aux serveurs web), cela peut sembler délicat. en effet les exploitations des applications web sont très courantes. Tout cela est affaire de logique ! Évaluer les risques etc.

              Surtout qu'en plus patcher un serveur Web - ou tout autre application - n'est pas synonyme de reboot systématique... du moins sous Un*x ;-)
          • [^] # Re: Parfaitement inutile...

            Posté par  . Évalué à 5.

            "loin, bien loin des DMZ"

            comment tu lui autorises à communiquer son uptime alors à ton serveur ?
            ceux qui gèrent sérieusement leurs machines ne se risqueront jamais à ajouter une fonctionnalité et à ouvrir des flux réseaux pour qqch qui ne sert pas la production.
            les autres n'auront jamais des uptimes très importants.
            je partage l'avis de celui qui a initié le sujet: sans vouloir blesser les auteurs de ce projet, concentrons nos efforts sur qqch de plus util.
            • [^] # Re: Parfaitement inutile...

              Posté par  . Évalué à 1.

              Sans souci, on ne se vexe pas :) .

              Concernant la communication, je pense que tu confonds flux sortant avec flux entrant, et à l'époque pour la plupart des firewall sont statefull, ca a son importance ;)
              • [^] # Re: Parfaitement inutile...

                Posté par  . Évalué à 2.

                Etant parfaitement inculte en firewalls, si tu pouvais détailler ton propos je t'en serais reconnaissant.
                • [^] # Re: Parfaitement inutile...

                  Posté par  . Évalué à 4.

                  Je pense qu'il veut dire par la que, logiquement, le flux peut soit sortir de la machine (connection initiee par la machine), soit y rentrer (connexion initiee par l'exterieur).

                  En gros: la reponse d'un serveur web a un client est considere comme flux sortant par le parefeu du client car c'est la reponse a connexion initiee depuis l'interieur du reseau.
                  En gros, si tu fermes le port 5142 en sortie, et que par hasard du navigateur web a utilise ce port la pour faire sortir sa requete, la reponse arrivera quand meme.

                  Et du cote du serveur, c'est l'inverse.

                  Le fait que le routeur soit statefull, c'est qu'il a un contexte, qui lui permet de savoir si le paquet qui arrive est une reponse a un demande d'une des machines qu'il parefeu.
                  • [^] # Re: Parfaitement inutile...

                    Posté par  . Évalué à 4.

                    Une anecdote : on pense surtout à protéger la DMZ des flux entrants en filtrant un max. Mais en général, on filtre très peu les flux sortants, vu que tout vient de "l'intérieur" (tout ça en statefull bien sûr).

                    Mais ça peut être utile des fois : un serveur s'étant fait compromettre (mdp ssh temporaire non changé par un admin ...) voulait se connecter sur IRC pour aller discuter avec ses amis du botnet, mais comme les flux sortant étaient aussi filtrés pour ne laisser passer que le ssh et le http(s), ça n'a pas eu d'impact. Même si ça fait une belle frayeur au début.
            • [^] # Re: Parfaitement inutile...

              Posté par  . Évalué à 4.

              je partage l'avis de celui qui a initié le sujet: sans vouloir blesser les auteurs de ce projet, concentrons nos efforts sur qqch de plus util.

              Si tu n'as pas envie de participer, ne participe pas mais laisse les gens faire ce qu'ils veulent.

              « 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: Parfaitement inutile...

                Posté par  . Évalué à 6.

                Personne n'empêche qui que ce soit de faire ce qu'il veut ; il s'agit juste d'exprimer une opinion. Su tu n'as pas envie de la lire, ne la lis pas, mais laisse les gens s'exprimer ;-)
                • [^] # Re: Parfaitement inutile...

                  Posté par  . Évalué à -1.

                  Alors pourquoi parler à la première personne du pluriel, l'auteur a-t'il un tel ego? Et si non, pourquoi nous dit-il ce qu'il faut faire?

                  Si ça ne l'intéresse pas, il peut simplement dire: "Je vois vraiment pas l'intérêt de la chose mais vous faites ce que vous voulez". Si quelqu'un a envie de patcher le noyau pour que ça freeze après 30 minutes d'utilisation parce qu'il trouve ça trop cool de redémarrer en débranchant la prise et qu'il veut pas travailler trop longtemps, je ne vais pas l'en empêcher, c'est son temps, il en fait ce qu'il veut (je ne le testerais pas non plus pour lui dire qu'il y a une faille et que j'ai pu tenir 35 minutes).


                  PS: le projet ne m'intéresse pas vu que j'ai un portable et que mon record d'uptime doit être de grand max 5 jours.

                  « 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: Parfaitement inutile...

                    Posté par  . Évalué à 1.

                    > Je vois vraiment pas l'intérêt de la chose mais vous faites ce que vous voulez
                    C'est à peu près ce qu'il a dit mais en plus argumenté. Il n'a pas besoin de préciser "vous faites ce que vous voulez", on s'en doute bien qu'il va pas aller les assassiner s'ils persistent.
                    • [^] # Re: Parfaitement inutile...

                      Posté par  . Évalué à 2.

                      Alors pourquoi parle-t'il au pluriel:

                      concentrons nos efforts sur qqch de plus util.

                      Ce n'est même pas atténuer. De quel droit décide-t'il pour tout le monde?

                      « 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: Parfaitement inutile...

            Posté par  (site web personnel) . Évalué à 4.

            Parfaitement, des idées recues, combien de serveur NFS avec des failles distantes ?
            Combien de linux font encore routeur avec des faille distantes oui, il y a des failles distantes sur les noyau.
            Bien sur qu'il ne faut pas patcher pour tout et n'importe quoi, mais je considère qu'à partir du moment ou on découvre une faille ouverte au réseau sur le noyau c'est qu'il est temps de mettre à jour.
            Et ca arrive, disons tous les 2 ans. Ce qui n'est pas négligeable quand on se retrouve à travailler avec des machines qui ont 10 ans.
      • [^] # Re: Parfaitement inutile...

        Posté par  (site web personnel) . Évalué à 5.

        Le mot "serveur" n'est ni dans cette news, ni sur la page d'accueil de votre site (sauf pour parler de votre serveur à vous). Comprends que dans ces conditions, surtout quand on parle dans la news d'aller jusqu'à mesurer l'uptime des téléphones (!), et sur un ton "déployez sur tout ce que vous pouvez", ça choque un peu.

        Pour ce qui est des économies d'énergie, ne t'en fais pas pour moi. Ah si, ta remarque me rappelle juste que je dois mettre une ampoule basse conso dans le salon (j'ai emménagé il y a un peu plus de 2 mois). Mais j'ai fait des travaux d'isolation dans mon appartement, avec des murs isolés en liège et idem sous le parquet. Je trie aussi mes déchets, j'utilise un verre à dent pour ne pas faire couler l'eau, je coupe l'eau quand je me savonne... C'est une passion de vouloir jouer à la plus grosse, ou juste un hobbie ;-) ?
        • [^] # Re: Parfaitement inutile...

          Posté par  (site web personnel) . Évalué à 2.

          Un GSM peut potentiellement avoir un uptime de plusieurs mois si son utilisateur le recharge avant que la batterie soit vide.
          J'ai un GSM qui a booté en Janvier 2009.
          Il risque de rebooté si Opera Mobile crash encore une fois :(
          • [^] # Re: Parfaitement inutile...

            Posté par  . Évalué à 1.

            Dans le même ordre d'idée, j'utilise un visor (handspring, ~2001)(palmOS 3.5) dont je change régulièrement les piles depuis des années, qui ne comporte que les quelques logiciels utiles, qui ne plante jamais et qui est synchonisé avec jpilot plusieurs fois par semaine, lequel visor doit maintenant avoir un uptime de plusieurs années (mais je n'ai
            pas installé de quoi mesurer la chose.... dommage pour l'inutile !).
    • [^] # Re: Parfaitement inutile...

      Posté par  . Évalué à 4.

      Je crois que personne ne va s'acheter un ordi à 2000€ avec un processeur de ouf et des néons partout consommant 500W juste pour faire tourner le client de Tugs.
    • [^] # Re: Parfaitement inutile...

      Posté par  (site web personnel) . Évalué à 2.

      Les bébés phoques vous remercie!
      • [^] # Re: Parfaitement inutile...

        Posté par  . Évalué à 2.

        Bonjour,

        Ce qui pourrait être sympa' si vous faites tourner les machines 24H/24, ça serait de les faires tourner en calcul partagé.
        Par exemple avec "World Community Grid", qui propose d'aider dans divers domaines dont la science et la santé.
        • [^] # Re: Parfaitement inutile...

          Posté par  (site web personnel) . Évalué à 3.

          Le truc, c'est que les logiciels de calcul partagé (type distributed.net, SETI@Home, etc.) sont les meilleurs moyens de faire exploser ta consommation d'électricité. Faut pas croire que lorsque le CPU est inutilisé, c'est de l'électricité "perdue" : la consommation d'un CPU en charge est beaucoup plus grande qu'un CPU au repos, surtout sur les plus récents (par exemple les Core 2).

          Donc répondre à quelqu'un qui se soucie de sa consommation d'électricité en lui disant de faire bosser en permanence sa machine, c'est tout simplement contre-productif.
  • # Dommage ...

    Posté par  (site web personnel) . Évalué à 2.

    J'aurais bien aimé un client pour OpenBSD sous licence BSD. Ca aurait été largement plus classe ...
    • [^] # Re: Dommage ...

      Posté par  . Évalué à 5.

      J'imagine que si les specs sont disponibles, un client sous licence BSD pourra voir le jour (si quelqu'un se donne la peine de le coder).
  • # OpenOffice

    Posté par  (Mastodon) . Évalué à 2.

    J'ai un OpenOffice sur un serveur qui tourne depuis 2007.
    La machine a 730 jours d'uptime.
    On le croirait pas hein ?

    Yth.
  • # Site moyennement accueillant.

    Posté par  . Évalué à 6.

    1) Le rendu est assez crade avec Konqueror, ça se chevauche de partout.
    D'un autre côté, on peut trouver un "/* IE hack */" dans le style.. C'est un sens des priorités que je ne partage pas.

    2) Pas moyen de trouver la licence (ou alors elle est cachée sous quelque chose) sur le site. Obligé de télécharger le .tar et de le décompresser pour lire enfin la GPL. Une petite mention "logiciel libre" sur la page de téléchargement ne ferait pas de mal ;)

    Allez, j'arrête de râler et je l'installe sur mon serveur@home.

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # Uptime d'IUT

    Posté par  . Évalué à 3.

    Ça me rappel que les admins à l'IUT qui ne redémarraient les serveurs que pendant l'été ... donc en général un peut plus de 300 jours d'uptime avant chaque reboot :-D
    C'était leur bébé, les obliger à redémarrer la machine (en faisant une boucle infinie avec un fork a l'intérieur par exemple) nous donnait droit a une éradication du compte coupable sur le serveur ... pas facile pour suivre les TP au final :-s
  • # Triche?

    Posté par  . Évalué à 2.

    Je sais, c'est assez désolant d'y penser: Vu que le client est libre, on peut modifier le code source afin de tricher sur son uptime.

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.