Roger,
Many thanks for your reply post.
I've re-posted my query on the AUSPUG list. I wasn't aware of AUSPUG
until you mentioned it.
As to a recalibration following reset, unfortunately, I've tried that,
both with the built-in digitiser and with a 3rd party app (digifix?)
said to be better
should be an interesting project. good luck with it.
Dean
[EMAIL PROTECTED] wrote:
Thanks Dean.
Yep, it does seem that it's possible. It also seems to allow a custom script
for checking which servers are up, which is probably going to be more reliable
than round-robin DNS.
That diagram is e
Thanks Dean.
Yep, it does seem that it's possible. It also seems to allow a custom script
for checking which servers are up, which is probably going to be more reliable
than round-robin DNS.
That diagram is exactly what we want, there is a DB backend, so there's no real
drama with shared data
looking through the lvs website it seems the project is more oriented
around the load balancer. which would mean the server OS and software
would be irrelevant. this sort of arrangement can be acommplished with
lots of various hardware slash applicance type devices. however the
price difference is
> I finally got my Palm handheld synchronising nicely in Linux
> and then its touchscreen stopped working properly. What I've
> heard about Palm Australia's service makes me want to avoid
> it for repairs if possible.
> Does anyone know of a reputable Palm repairer in the Sydney area?
I swappe
I finally got my Palm handheld synchronising nicely in Linux and then
its touchscreen stopped working properly. What I've heard about Palm
Australia's service makes me want to avoid it for repairs if possible.
Does anyone know of a reputable Palm repairer in the Sydney area?
--
SLUG - Sydney Li
depends what you want to achieve then
round robin dns can be very effective in many circumstances.
Dean
Felix Sheldon wrote:
Well, yes, but unless you pay through the nose for the 'Advanced' or
'Data-center' editions I think it's fairly limited. I'd prefer something
OSS that can be tweaked
On Tue, Dec 20, 2005 at 02:06:11AM +, Dave Airlie wrote:
> I've heard chat on lkml about using alternatives (the kernel ones) to do
> this.. basically at build time you construct a table of every spinlock
> call and patch them all up at CPU hotplug or kernel boot time...
>
> Sounds like magic
On Tue Dec 20, 2005 at 02:06:11 +, Dave Airlie wrote:
>>
>> Right. Which is what I've found too. Which led me to wondering: Jeff:
>> how do you plan to do this UP/SMP kernel efficiently? The kernel
>> implements spin_lock as a macro that gets compiled out when building for
>> UP:
>
>I've heard
> Right. Which is what I've found too. Which led me to wondering: Jeff: how
> do you plan to do this UP/SMP kernel efficiently?
Ben Collins (our kernel maintainer) forward ported an old 2.4 patch and put
it in our git repository - maintained on kernel.org -> WE ROCK! It switches
locks to noops a
Well, yes, but unless you pay through the nose for the 'Advanced' or
'Data-center' editions I think it's fairly limited. I'd prefer something
OSS that can be tweaked to do exactly what we want, without arbitrary
limits designed to sell more licenses.
--
Felix
Dean Hamstead wrote:
i belie
i believe 2003 has its own clustering solution?
Dean
Felix Sheldon wrote:
Hi Sluggers,
I'm just wondering if LVS is worth trying out as something to manage
requests for a cluster of identical Windows-based web servers.
http://www.linuxvirtualserver.org/index.html
Thanks,
Felix
--
WWW
Hi Sluggers,
I'm just wondering if LVS is worth trying out as something to manage
requests for a cluster of identical Windows-based web servers.
http://www.linuxvirtualserver.org/index.html
Thanks,
Felix
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription inf
>
> Right. Which is what I've found too. Which led me to wondering: Jeff:
> how do you plan to do this UP/SMP kernel efficiently? The kernel
> implements spin_lock as a macro that gets compiled out when building for
> UP:
I've heard chat on lkml about using alternatives (the kernel ones) to do
thi
On Mon, 2005-12-19 at 14:40 +1100, Ian Wienand wrote:
> Mostly I think the sub-architecture is passed via different flags to
> gcc, which can try to optimise the code. Talking with people from SGI
> who look into that sort of thing, the benefits of even a much better
> compiler fall into noise com
Hal Ashburner wrote:
On Mon, 2005-12-19 at 23:40 +1100, Crossfire wrote:
The 'correct' method to test for MMX (and later extensions) is to
check the output of the CPUID instruction. (Introduced in the late
486 families - guaranteed to be available on all Pentium class or
newer systems howev
AFAIK, there have been mixed results which depend on which version of gcc
you're running. While reading on the topic a few months back, the general
consensus seemed to be that in general i686 (which is what I'm compiling
with) actually resulted in slightly slower performance in some areas but th
On Mon, 2005-12-19 at 23:40 +1100, Crossfire wrote:
> The 'correct' method to test for MMX (and later extensions) is to
> check the output of the CPUID instruction. (Introduced in the late
> 486 families - guaranteed to be available on all Pentium class or
> newer systems however.) It is the CPUI
O Plameras was once rumoured to have said:
> Architecture wise, some changes from i386 to i586:
> 1. Native floating point in i586 (present in i486 but disabled, option
> to install co-processor in i386)
Actually, the FPU in the i486 is enabled on the 486DX series, but not
on the 486SX series.
Jan Schmidt was once rumoured to have said:
> On Mon, 2005-12-19 at 13:54 +1100, Jeff Waugh wrote:
> >
> >
> > > Architecture wise, some changes from i386 to i586:
> >
> > But crucially, few of these things are interesting at the kernel
> > level. Apps can take advantage of CPU features like the
Anand Kumria wrote :-
>The site-local prefix (fe80) has been deprecated (rfc3879), instead you
want IPv6 local addresses (rfc4193) which you
>can self-generate with tools such as:
>
http://www.hznet.de/tools/generate-uniq-local-ipv6-unicast-addr.sh
Hmm, I dropped off the IETF announce lists a
On Mon, 2005-12-19 at 13:54 +1100, Jeff Waugh wrote:
>
>
> > Architecture wise, some changes from i386 to i586:
>
> But crucially, few of these things are interesting at the kernel level. Apps
> can take advantage of CPU features like these regardless of the architecture
> the kernel was built f
22 matches
Mail list logo
