Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Feb 2006 23:32:31 +0100
From:      "Daniel A." <ldrada@gmail.com>
To:        lars@gmx.at
Cc:        freebsd-questions@freebsd.org
Subject:   Re: [Total OT] Trying to improve some numbers ...
Message-ID:  <5ceb5d550602161432r18ac6b1bgaa57d315e01ea564@mail.gmail.com>
In-Reply-To: <43F4F43D.2090304@gmx.at>
References:  <20060216005036.L60635@ganymede.hub.org> <20060216053725.GB15586@parts-unknown.org> <20060216085304.GA52806@storage.mine.nu> <43F4CAA3.1020501@schultznet.ca> <43F4F43D.2090304@gmx.at>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2/16/06, lars <lars@gmx.at> wrote:
> Eric Schultz wrote:
> > lars wrote:
> >> A long uptime means that the machine hasn't been rebooted for a long
> >> time. If that time's longer than the time to the last patch that
> >> required a kernel recompilation and a reboot, it means the server is n=
ot
> >> patched. Where's the point in advertising an unpatched machine?
> >
> > Good afternoon...
> >
> > Perhaps it means the OS doesn't need to be patched that frequently
> Possibly. But patch frequency means what exactly?
>
> > or has a patch mechanism that avoids reboots?
> Exactly, that doesn't exist (yet).
>
> Although there was something in a Usenix proceeding or somewhere else,
> about "micro-reboots" where, to use FreeBSD wordage,
> Base and Ports' programs where so modularised to allow this.
> Thus making only, say, a driver or some kernel component reboot,
> but the majority of the system stays up.
> Of course a reboot of the NIC's driver kills that component's "uptime".
>
> > That's certainly worth advertising (if only were true).
> Actually it (this website) means advertising an unpatched machine
> running unpatched services not available to the outside.
>
> > The top machine has been running for almost 6 years on FreeBSD 3.3 whic=
h
> > means the admin probably believes that "if it ain't broke, don't fix
> > it."
> Which is not necessarily the best strategy.
> But may be right in this case.
>
> > I would also want to advertise the longevity of an OS.
> You mean the ability of that OS to run so long without requiring a reboot=
?
> I'm not sure that's that relevant nowadays.
> How many OS aren't capable of staying up long?
> Even Windows doesn't need too much Viagra to keep it up.
>
> > (You might not like that last one if you're a hardware vendor :)
> >
> > Also, a lot of work-arounds for security patches amount to "lock the
> > front door."
> What do you mean by that?
>
> > So perhaps some systems don't need to be patched because
> > they're administered so as not to require immediate patching/upgrading.
> If your machine only runs an NFS daemon and is behind a firewall,
> ok, you don't need to patch it asap when an NFS SA and patch is issued,
> if all clients connecting to the machine are benign.
>
> I could also run a machine in some private net protected by firewalls
> and whatnot running only this uptime program.
> Unless I lose power or some hardware failure occurs I'll have a long
> uptime. A bit useless though.
>
>
>
> I think that 'uptime' and this website fail to define precisely enough
> what the point of the exercise is to be able to make useful conclusions
> about something about some OS.
>
> What exactly do you want to measure to make what decision?
>
>         Do you want to find out how much [%] your OS is available
>         whithout load just patching it with the latest SA recommended    =
               patches?
>
>         Do you want to find out how much [%] your OS is available
>         [can serve 100 FTP users simultaneously at wire speed
>         with this NIC]
>         just patching it with the latest SA recommended patches?
>
>         Do you want see how long an unpatched OS version can keep it up
>         without any patches or interaction whatsoever?
>
>         etc.

None of the above.
It measures your internet-penis.
The guy who has had his FreeBSD 3.3 box up running since the dawn of
times, has the longest internet-penis in the world.

> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.o=
rg"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5ceb5d550602161432r18ac6b1bgaa57d315e01ea564>