[plug] Is the message below a bodgy email

Thu Jun 19 16:48:29 WST 2008

It's not bodgy. Karmen put me in the job I am in now - Hi Karmen.

Not sure why she replied to the below message though?
A new message would have made more sense :)

Cheers
Blake Munro

2008/6/19 Bret Busby <bret at busby.net>:

>
> If the organisation from which the email message below, appears to have ben
> sent, is in fact a professional organisation, one person should not be
> sending an email using another person's name, and, the email message, if it
> is sincere, should be an email with an appropriate email message subject,
> rather than an email injected (yes, like SQL code
> injection) into an unrelated subject thread on a mailing list, so as to
> conceal the purpose of the message.
>
> Therefore, the question has to be asked; is the message below, bodgy?
>
> --
> Bret Busby
> Armadale
> West Australia
> ..............
>
> "So once you do know what the question actually is,
>  you'll know what the answer means."
> - Deep Thought,
>  Chapter 28 of Book 1 of
>  "The Hitchhiker's Guide to the Galaxy:
>  A Trilogy In Four Parts",
>  written by Douglas Adams,
>  published by Pan Books, 1992
>
> ....................................................
>
>
> On Thu, 19 Jun 2008, Gary Robertson wrote:
>
>  Date: Thu, 19 Jun 2008 16:37:13 +1000
>> From: Gary Robertson <Gary.Robertson at hays.com.au>
>> Reply-To: plug at plug.org.au
>> To: plug at plug.org.au
>> Subject: RE: [plug] Ubuntu woes
>>
>>
>> Hi There,
>>
>> Is anyone seeking or knows of someone who might be interested in a Linux
>> Systems Administrator position. It is to support a web environment. The
>> role will be working in a team to support about 14 servers. This is a
>> fairly entry level role and is paying $45 - $55k plus super.
>>
>> If you wish to discuss further please contact myself on the number
>> below.
>>
>>
>> Kind Regards,
>>
>> Karmen Bakovic
>>
>> Senior Recruitment Consultant
>>
>> HAYS Information Technology
>>
>>
>>
>> Hays - Australia and New Zealand's leading specialist recruitment group
>>
>>
>>
>> T 08 9226 0899  |  F  08 9322 5386 |  E karmen.bakovic at hays.com.au
>>
>> Level 12, 172 St Georges Terrace, Perth WA 6000
>>
>> To search for the best jobs and candidates visit our website
>> www.hays.com.au
>>
>>
>>
>> SARA Award winners for "Best Candidate Care by a Recruitment Firm" 2005
>> and 2006
>>
>>
>>
>> -----Original Message-----
>> From: plug-bounces at plug.org.au [mailto:plug-bounces at plug.org.au] On
>> Behalf Of Daniel Pittman
>> Sent: Thursday, 19 June 2008 12:44 PM
>> To: plug at plug.org.au
>> Subject: Re: [plug] Ubuntu woes
>>
>> Steve Baker <steve at iinet.net.au> writes:
>>
>>> Daniel Pittman wrote:
>>>
>>>> Steve Baker <steve at iinet.net.au> writes:
>>>>
>>>>  Nothing out of the ordinary in the kern.log, messages, syslog,
>>>>> daemon.log, or the usual suspects in /var/log.
>>>>>
>>>>> All disks are in a hardware RAID - 8-port adaptec SATA-II raid card,
>>>>>
>>>>
>>  2 discs in RAID-1 and 6 in RAID-5.  The two RAID-1 drives are 12
>>>>> months or so old, the other 6 are all new.  My next plan is to find
>>>>> the afatools kit from Adaptec and run the afacli command to check
>>>>> the SMART status of the discs and then scrub (check) the arrays.
>>>>>
>>>>> What is confusing is some tasks are quite quick and others really
>>>>> slow.  Unpacking a tgz archive was quick, aptitude safe-upgrade
>>>>> takes a long time to do steps like read state information, build the
>>>>>
>>>>
>>  tag database, etc. but the download was quick, then it took even
>>>>> longer to do the post-installation steps.
>>>>>
>>>>
>>>> It sounds, to me, very much like your system is delivering good write
>>>>
>>>
>>  bandwidth[1] but terrible read bandwidth or latency.
>>>>
>>>> Unpacking the tar is fast iff the content is in memory, but the
>>>> update is slow when it reads databases or faults in code from disk.
>>>> Network runs at full speed, and the post-install was slow only where
>>>> it had to fault in code, etc...
>>>>
>>>
>>> Sounds like a good theory - I am not sure of the best way to test this
>>>
>>
>>  though.
>>>
>>
>> Well, the easy way would be to time reading a file that had not been
>> read before, then time re-reading it.  That should show up as slow the
>> first time around, fast the second.
>>
>> You should also be able to echo ... 3, IIRC, to /proc/sys/vm/drop_caches
>> in order to have the kernel flush all the caching.  Ah, there we go:
>>
>> http://linux-mm.org/Drop_Caches
>>
>>  I know of hdparm/sdparm but I don't know if they are appropriate for
>>> RAID volumes.  I can time large file copies and such (eg dd
>>> if=/dev/urandom of=/some/file bs=1048576 count=1024 or whatever) but I
>>>
>>
>>  have nothing to compare results to.  And how do I stop caching from
>>> upsetting the results?
>>>
>>
>> Well, my expectation would be that y'all could stop other activity and
>> time the commands 'dd if=/dev/zero of=whatever bs=1M count=100; sync'
>> together, which should give you a view of the time to write data out.
>>
>>  At a guess.  Oh, are you running a vendor driver for the Adaptec
>>>> card, or is it all open source drivers?
>>>>
>>>
>>> I'm running the default Ubuntu aacraid driver.  When I ran the
>>> installer it found that driver automatically, so I just used that.
>>>
>>
>> That seems reasonable, and if the driver picks it up then it is real
>> hardware RAID and all.
>>
>>  In my experience the aacraid drivers have been pretty stable and
>>> reliable, and I believe that Adaptec have always been quite open about
>>>
>>
>>  providing specs for their hardware.
>>>
>>
>> Sadly, these days they sell a pile of "fakeRAID" cards, for which only
>> binary drivers exist.  Great, isn't it?  Anyhow, that is why I ask.
>>
>> [...]
>>
>>  Something I forgot to mention is that it's also very slow to boot,
>>> which could indicate a hardware level issue with the RAID card (or
>>> maybe it slows down after the kernel loads the raid driver).  I think
>>> it's the most recent firmware revision but I'll check on that too.
>>>
>>
>> I would almost guess that your RAID array was degraded, and that is
>> killing performance.
>>
>> Actually, a question: you have a RAID1 and a RAID5, right?
>>
>> Is the terrible performance the same on both?
>>
>> Regards,
>>       Daniel
>> _______________________________________________
>> PLUG discussion list: plug at plug.org.au
>> http://www.plug.org.au/mailman/listinfo/plug
>> Committee e-mail: committee at plug.linux.org.au
>>
>>
>> For the latest recruitment news and career opportunities visit
>> www.hays.com.au
>>
>>
>> *********************************************************************************************
>> This message (including any attachments) is confidential and may be
>> legally privileged.  If you are not the intended recipient, you should
>> not disclose, copy or use any part of it - please delete all copies
>> immediately and notify the Hays Helpdesk at helpdesk at hays.com.au
>>
>> Any information, statements or opinions contained in this message
>> (including any attachments) are given by the author.  They are not
>> given on behalf of Hays unless subsequently confirmed by an individual
>> other than the author who is duly authorised to represent Hays.
>>
>> All sent and received email from/to Hays is automatically scanned for the
>> presence of computer viruses, security issues and inappropriate content.
>>
>> For further information on the services which Hays provide visit our web
>> site at www.hays.com.au
>>
>> *********************************************************************************************
>>
>> _______________________________________________
>> PLUG discussion list: plug at plug.org.au
>> http://www.plug.org.au/mailman/listinfo/plug
>> Committee e-mail: committee at plug.linux.org.au
>>
>>
> _______________________________________________
> PLUG discussion list: plug at plug.org.au
> http://www.plug.org.au/mailman/listinfo/plug
> Committee e-mail: committee at plug.linux.org.au
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plug.org.au/pipermail/plug/attachments/20080619/97ce06c2/attachment.html>