Thus said Shane Hathaway on Wed, 18 Nov 2009 11:01:55 MST:
> I can't resolve folklore.org either. The problem is unrelated to BYU.
The domain is poorly delegated and seriously misconfigured. I'm amazed
that a DNS resolver is able to resolve it at all. RFC 1035 and RFC 1034
clearly define an N
http://www.folklore.org/StoryView.py?project=Macintosh&story=Saving_Lives.txt
Maybe it's just because I'm on BYU's network, but I'm getting this:
amcn...@maggie:~% host www.folklore.org
Host www.folklore.org not found: 3(NXDOMAIN)
Tragic.
I can't resolve folklor
On Nov 18, 2009, at 11:01 AM, Shane Hathaway wrote:
> Stuart Jansen wrote:
>> On Wed, 2009-11-18 at 10:23 -0700, Andrew McNabb wrote:
>>> On Wed, Nov 18, 2009 at 10:15:45AM -0700, Stuart Jansen wrote:
http://www.folklore.org/StoryView.py?project=Macintosh&story=Saving_Lives.txt
>>> Maybe it's
Stuart Jansen wrote:
> On Wed, 2009-11-18 at 10:23 -0700, Andrew McNabb wrote:
>> On Wed, Nov 18, 2009 at 10:15:45AM -0700, Stuart Jansen wrote:
>>> http://www.folklore.org/StoryView.py?project=Macintosh&story=Saving_Lives.txt
>> Maybe it's just because I'm on BYU's network, but I'm getting this:
>
y for
them. Are they optimal? No, they kind of suck in a lot of ways. But
that's not because people are lazy, it's because they're not in it for
elegance, they're in it to use these things to make money.
>> Maybe they're just driven by some metric other than ridicu
On Wed, 2009-11-18 at 10:23 -0700, Andrew McNabb wrote:
> On Wed, Nov 18, 2009 at 10:15:45AM -0700, Stuart Jansen wrote:
> >
> > http://www.folklore.org/StoryView.py?project=Macintosh&story=Saving_Lives.txt
>
> Maybe it's just because I'm on BYU's network, but I'm getting this:
>
> amcn...@maggi
On Wed, Nov 18, 2009 at 10:15:45AM -0700, Stuart Jansen wrote:
>
> http://www.folklore.org/StoryView.py?project=Macintosh&story=Saving_Lives.txt
Maybe it's just because I'm on BYU's network, but I'm getting this:
amcn...@maggie:~% host www.folklore.org
Host www.folklore.org not found: 3(NXDOMAIN
On Wed, 2009-11-18 at 10:13 -0700, Michael Torrie wrote:
> Levi Pearson wrote:
> > So, bascially what you're saying is that anyone who chooses to implement
> > a different set of features than you'd like is inherently lazy? I'm
> > sorry the world hasn't arranged itself to suit your needs. :)
>
>
that at one time
software maintenance was the focus, but not anymore.
> Maybe they're just driven by some metric other than ridiculously long
> uptimes. It would make sense, since to do so would be... ridiculous.
Yes I was afraid I'd be misconstrued as saying that ridiculously lo
Brian Simons wrote:
> I haven't used this personally, but I hear it works well and is
> supported at least by Ubuntu:
>
> http://en.wikipedia.org/wiki/Ksplice
> http://www.ksplice.com/
I forgot about this little project. Of course it has the fatal flaw
that it takes a bit of work on the part of
On Wed, 2009-11-18 at 09:46 -0700, Michael Torrie wrote:
> But even on linux, a kernel update requires a reboot. Often the kernel
> update is critical because of a local exploit that it fixes. Why do we
> have to reboot just to patch a kernel? Sure it sounds complicated to
> patch a running kern
architecture newer than
sometime in the 90s, and some of which go back to the 70s... wouldn't
you say that their development is focused on software maintenance?
Maybe they're just driven by some metric other than ridiculously long
uptimes. It would make sense, since to do so would be.
On Wed, 2009-11-18 at 09:46 -0700, Michael Torrie wrote:
> Steven Alligood wrote:
> But even on linux, a kernel update requires a reboot. Often the kernel
> update is critical because of a local exploit that it fixes. Why do we
> have to reboot just to patch a kernel? Sure it sounds complicated
Steven Alligood wrote:
> My guess is that the windows servers listed at the above url are
> actually clusters, that allow upgrades, reboots and testing of one at a
> time offline. Not true uptime at all.
This reminds me of an article I read recently about software maintenance:
http://cacm.acm.o
On 11/17/2009 08:20 PM, Aaron Toponce wrote:
Derek Davis wrote:
Ha, that's nothing. I once had a Windows machine up for 2 weeks _straight_.
http://uptime.netcraft.com/up/today/top.avg.html
wow. that is significant in that their either
1) only gather windows statistics (with
On Tue, Nov 17, 2009 at 5:37 PM, Ryan Simpkins wrote:
> Found two gems:
>
> 16:00:59 up 1621 days, 9:22, 1 user, load average: 0.48, 0.46, 0.45
> 16:27:24 up 1618 days, 8:15, 1 user, load average: 0.75, 0.65, 0.57
>
Found this on a switch I was working on the other day:
The system uptime
On Tue, Nov 17, 2009 at 11:52 PM, Ryan Simpkins wrote:
> a NetWare server, or that a windows box ran for 2 weeks without a reboot. How
> many times did you have to hit "remind me later" on the reboot dialog box?
Ah, you haven't learned the secret-to-multi-week-Windows-uptimes. When
the reboot dia
On Tue, 17 Nov 2009 21:52:57 -0700 (MST)
"Ryan Simpkins" wrote:
>
> I once ran a BSOD for 4 weeks. Does that count as "running windows?"
I'm sure that was almost as fascinating as watching the
defragmenter. :-)
--
Charles Curley /"\ASCII Ribbon Campaign
Looking for fine
On Tue, November 17, 2009 18:24, Derek Davis wrote:
> On Tue, Nov 17, 2009 at 8:02 PM, Bart Whiteley wrote:
>> On Tue, Nov 17, 2009 at 5:37 PM, Ryan Simpkins
>> wrote:
>>> Found two gems:
>>>
>>> 16:00:59 up 1621 days, 9:22, 1 user, load average: 0.48, 0.46, 0.45
>>> 16:27:24 up 1618 days, 8:
Derek Davis wrote:
> Ha, that's nothing. I once had a Windows machine up for 2 weeks _straight_.
http://uptime.netcraft.com/up/today/top.avg.html
--
. O . O . O . . O O . . . O .
. . O . O O O . O . O O . . O
O O O . O . . O O O O . O O O
signature.asc
Description: Op
On Tue, Nov 17, 2009 at 8:02 PM, Bart Whiteley wrote:
> On Tue, Nov 17, 2009 at 5:37 PM, Ryan Simpkins wrote:
>> Found two gems:
>>
>> 16:00:59 up 1621 days, 9:22, 1 user, load average: 0.48, 0.46, 0.45
>> 16:27:24 up 1618 days, 8:15, 1 user, load average: 0.75, 0.65, 0.57
>
> File Server U
On Tue, Nov 17, 2009 at 5:37 PM, Ryan Simpkins wrote:
> Found two gems:
>
> 16:00:59 up 1621 days, 9:22, 1 user, load average: 0.48, 0.46, 0.45
> 16:27:24 up 1618 days, 8:15, 1 user, load average: 0.75, 0.65, 0.57
File Server Up Time: 2249 Days 0 Hours 48 Minutes 54 Seconds
NetWare v3.
Michael Torrie wrote:
> Ryan Simpkins wrote:
>> 16:00:59 up 1621 days, 9:22, 1 user, load average: 0.48, 0.46, 0.45
>> 16:27:24 up 1618 days, 8:15, 1 user, load average: 0.75, 0.65, 0.57
>>
>> These are ProLiant DL360 G4s with 2GB of RAM running RHEL. Standard server
>> gear in a co-lo facili
Ryan Simpkins wrote:
> 16:00:59 up 1621 days, 9:22, 1 user, load average: 0.48, 0.46, 0.45
> 16:27:24 up 1618 days, 8:15, 1 user, load average: 0.75, 0.65, 0.57
>
> These are ProLiant DL360 G4s with 2GB of RAM running RHEL. Standard server
> gear in a co-lo facility, nothing fancy.
Cool. T
Found two gems:
16:00:59 up 1621 days, 9:22, 1 user, load average: 0.48, 0.46, 0.45
16:27:24 up 1618 days, 8:15, 1 user, load average: 0.75, 0.65, 0.57
These are ProLiant DL360 G4s with 2GB of RAM running RHEL. Standard server
gear in a co-lo facility, nothing fancy.
-Ryan
/*
PLUG: http:/
25 matches
Mail list logo
