On Wed, Jun 09, 2004 at 09:10:46AM +0100, Richard P. Williamson wrote:
> Theory: Windoze installations are unreliable.
> Proof:
> I turned it on.
> It was hacked into an open proxy.
> It contracted several hundred worms.
> It crashed.
> QED.
W^5
(Which was what we wanted)
--
John Birre
Jos De Laender wrote:
Bill Campbell wrote:
The original Latin is ``Quod Erat Demonstrandum'', translates to that was
demonstrated (about as much as I remember from five years of Latin).
Quod erat demonstrandum is correct. The translation is rather : what
needed to be proven, what needed to be
At 21:04 08/06/2004. Jos De Laender had this to say:
>Quod erat demonstrandum is correct. The translation is rather : what needed to be
>proven, what needed to be demonstrated ...
>(although this is probably very poor English :-) )
That which was to be demonstrated, is the closest conceptually.
HI Luke,
Thanks for your advice.
> > Is there a way updating all installed ports
> > automatically wheneven the server/workstation is
> > booted and connected to Internet, similar to ntp
> > synchronizing the clock.
> >
> in theory it should be possible to write a script
> that runs portupgrade
Bill Campbell wrote:
The original Latin is ``Quod Erat Demonstrandum'', translates to that was
demonstrated (about as much as I remember from five years of Latin).
Quod erat demonstrandum is correct. The translation is rather : what
needed to be proven, what needed to be demonstrated ...
(alt
Bill Campbell writes:
> The original Latin is ``Quod Erat Demonstrandum'', translates to
> that was demonstrated (about as much as I remember from five
> years of Latin).
Perfect passive periphrastic, if I've got it right.
Robert Huff
__
On Tue, Jun 08, 2004, Kent Stewart wrote:
>On Tuesday 08 June 2004 09:36 am, Bill Moran wrote:
>> Peter Risdon <[EMAIL PROTECTED]> wrote:
>> > Robert Huff wrote:
>> > >Peter Risdon writes:
>> > >> I suppose what I'm driving at is whether the RELENG_4 branch
>> > >> sees many commits that are likely
On Tuesday 08 June 2004 09:36 am, Bill Moran wrote:
> Peter Risdon <[EMAIL PROTECTED]> wrote:
> > Robert Huff wrote:
> > >Peter Risdon writes:
> > >> I suppose what I'm driving at is whether the RELENG_4 branch
> > >> sees many commits that are likely to be problematic.
> > >
> > > In general, no
On Tue, 8 Jun 2004 12:36:47 -0400
Bill Moran <[EMAIL PROTECTED]> wrote:
> Peter Risdon <[EMAIL PROTECTED]> wrote:
>
> > Robert Huff wrote:
> >
> > >Peter Risdon writes:
> > >
> > >> I suppose what I'm driving at is whether the RELENG_4 branch sees
> > >> many commits that are likely to be proble
Peter Risdon <[EMAIL PROTECTED]> wrote:
> Robert Huff wrote:
>
> >Peter Risdon writes:
> >
> >> I suppose what I'm driving at is whether the RELENG_4 branch sees
> >> many commits that are likely to be problematic.
> >>
> > In general, no.
> > On the other hand ... think of this as a
Peter Risdon <[EMAIL PROTECTED]> wrote:
> Bill Moran wrote:
>
> >Peter Risdon <[EMAIL PROTECTED]> wrote:
> >
> >>cvsup'ing overnight is routine and fine.
> >>
> >>The make build/install stuff seems a bit more delicate. I'm happy that I
> >>have figured out how to automate this, but not _whethe
Robert Huff wrote:
Peter Risdon writes:
I suppose what I'm driving at is whether the RELENG_4 branch sees
many commits that are likely to be problematic.
In general, no.
On the other hand ... think of this as a Murphy's Law scenario:
if you automate, it _will_ break horribly two days befo
Bill Moran wrote:
Peter Risdon <[EMAIL PROTECTED]> wrote:
cvsup'ing overnight is routine and fine.
The make build/install stuff seems a bit more delicate. I'm happy that I
have figured out how to automate this, but not _whether_ I should do so.
I am of course only considering tracking RELENG_4
Peter Risdon writes:
> I suppose what I'm driving at is whether the RELENG_4 branch sees
> many commits that are likely to be problematic.
In general, no.
On the other hand ... think of this as a Murphy's Law scenario:
if you automate, it _will_ break horribly two days before s
Peter Ulrich Kruppa wrote:
On Tue, 8 Jun 2004, Peter Risdon wrote:
The main cost of having computers for most companies lies not in
software or hardware, but in support. I have been pondering the
wisdom of automating the upgrade process, so that sources are
cvsup'ed nightly and make buildworld b
Vince Hoffman wrote:
On Tue, 8 Jun 2004, Peter Risdon wrote:
I have been pondering the wisdom
of automating the upgrade process,
You may want to have a look at freebsd-update. Its a binary updater,
Client/Server config, the server code and info on what it is, is available
from http://www.d
On Tue, 8 Jun 2004, Peter Risdon wrote:
The main cost of having computers for most companies lies not in software or
hardware, but in support. I have been pondering the wisdom of automating the
upgrade process, so that sources are cvsup'ed nightly and make buildworld
buildkernel etc and portupgr
On Tue, 8 Jun 2004 23:02:31 +0800 (CST)
Stephen Liu <[EMAIL PROTECTED]> spake thus:
> Hi folks,
>
> This is an interesting topic.
>
> > On Tue, 8 Jun 2004, Peter Risdon wrote:
> >
> > > The main cost of having computers for most
> > companies lies not in
> > > software or hardware, but in supp
Hi folks,
This is an interesting topic.
> On Tue, 8 Jun 2004, Peter Risdon wrote:
>
> > The main cost of having computers for most
> companies lies not in
> > software or hardware, but in support. I have been
> pondering the wisdom
> > of automating the upgrade process, so that sources
> are cvs
Peter Risdon <[EMAIL PROTECTED]> wrote:
> The main cost of having computers for most companies lies not in
> software or hardware, but in support. I have been pondering the wisdom
> of automating the upgrade process, so that sources are cvsup'ed nightly
> and make buildworld buildkernel etc and
On Tue, 8 Jun 2004, Peter Risdon wrote:
> The main cost of having computers for most companies lies not in
> software or hardware, but in support. I have been pondering the wisdom
> of automating the upgrade process, so that sources are cvsup'ed nightly
> and make buildworld buildkernel etc and
The main cost of having computers for most companies lies not in
software or hardware, but in support. I have been pondering the wisdom
of automating the upgrade process, so that sources are cvsup'ed nightly
and make buildworld buildkernel etc and portupgrade happen overnight
maybe once a week
22 matches
Mail list logo
