Re: [SLUG] security monitor with webcam

2009-05-21 Thread elliott-brennan
I was racking my brain trying to remember the applications name when what
should come up on lxer.com?:

ZoneMinder

http://www.zoneminder.com/

I'd read about this a while ago. It seemed quite good. I haven't used it
though.

Hope this helps. If you do use it, let me know because I'd be very
interested.

Regards,

Patrick

-- Forwarded message --
From: Morgan Storey 
To: Matthew Hannigan 
Date: Wed, 20 May 2009 18:21:43 +1000
Subject: Re: [SLUG] security monitor with webcam
I used to use motion when I had a free webcam hooked up to my desktop.
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Proprietary colour names (was GIMP was...)

2009-05-21 Thread Glen Turner

david wrote:
Excuse my ignorance, but isn't this roughly what colour management 
(http://www.argyllcms.com/?) is supposed to do?


The main purpose of colour management is that the colour you use on
one device is accurately displayed on another device.  For example,
if you scan an object and display that object on the screen, then
when holding the object against the screen you can see no differences
of colour between the object on the screen and the original object in
your hand.

The way we do that is to give each device a "colour profile" which
describes adjustments which need to be made against a theoretical colour
space for a given colour to come out "right".

A problem is that there are multiple theoretical colour spaces -- as
differing technologies can show a wider or narrower range of colours.
So a computer screen (RGB), a three-colour plus black (CMYK) and spot
printing (mixes of inks, but those mixes cannot overlap) all form
differing colour spaces.  And you can see from the mixed-ink case
that the spaces can have internal gaps too.  There are also other
colour spaces not used at all in printing, but in other fields.

Some colour management systems attempt to translate between the
differing colour spaces. This is moderately successful, but also
fails when the gamuts of the two spaces do not overlap. For example,
there is no way to accurately represent a mirrored finish as opposed
to a flat finish ink on CMYK or RGB. Even CMYK/RGB is problematic -- RGB
colour are a light box, whereas CMYK colours are printed. So at equivalent
resolutions photographs look much better on RGB screens (which goes
back to the old-time serious photographer's preference for slides over
paper). Going the other way, the black ink in CMYK allows much better
control over dark shades than with RGB.

Colour is a complicated field. I hope this gives you the flavour of it.

To answer your question, there is a PANTONE colour space. In theory
a CMS could convert between devices using PANTONE (actually a no-operation,
since all PANTONE printers are pre-calibrated to be identical).
In theory, a space-converting CMS could handle spot printing technologies
such as PANTONE. In practice, the whole point of spot printing is precise
control of printed colour and a designer isn't going to leave it to some
subsystem to convert an RGB pixel to the exact shade they have in mind.
They want to enter that exact shade into the application.

With PANTONE spot printing in particular, there's perhaps some legal
questions. Which Andrew mentioned in a previous post.

Having written all of the above, it is well worth the hassle to get
the DPI of your screen correct (so that 1inch in the application is
one inch on the display) and to colour calibrate the screen, printer
and scanner. Increasingly manufacturers are releasing nominal values
for these calibrations for each model, and in the long run the hope
is that some calibration good enough for all but the most fussy will
occur out of the box.

--
 Glen Turner
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] /proc and /sys

2009-05-21 Thread Jeff Waugh


>> They're entirely virtual filesystems and don't need to be backed up at
>> all.  In general, you should use the -x (or --one-file-system) parameter
>> with rsync when you're backing up -- saves backing up (and even reading)
>> useless crap like this.
>
> So *that's* what -x means ;-)
>
>
> I've been doing:
>
> # rsync -a --exclude=/media/backupdrive / /media/backupdrive
>
> Without --exclude I get some "interesting" results ;-)
>
> Does the -x switch solve this problem too? It might sound naive, but I
> understood the file system to be everything below /

Each mount point exposes a filesystem, so really you have many filesystems
below / ... the obviously different ones like /proc and /sys, but also the
disk you mounted for backup, /home if you have that on a different disk...

So yes, rsync -ax / /media/backupdrive/ will do the right thing unless you
have data mounted elsewhere which you want backed up. Always match slashes
with rsync source/destination by the way.

- Jeff

-- 
linux.conf.au 2010: Wellington, NZ   http://www.penguinsvisiting.org.nz/
 
  "I like your Christ, I do not like your Christians. Your Christians are
  so unlike your Christ." - Mahatma Gandhi
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] /proc and /sys

2009-05-21 Thread Andrew Cowie
On Fri, 2009-05-22 at 13:05 +1000, david wrote:
> To what extent are /proc and /sys recreated by the system as required,

They are entirely dynamic. /proc and /sys (and, for the last several
years, /dev) are virtual filesystems; the mount command that gets them
there in the first place is something like

# mount -t proc  none   /proc
# mount -t sysfs none   /sysfs

(contrast to)

# mount -t ext3  /dev/sda6  /home

> and to what extent do they need to be backed-up?
> 
Not at all.

AfC
Sydney

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London


signature.asc
Description: This is a digitally signed message part
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] /proc and /sys

2009-05-21 Thread Erik de Castro Lopo
david wrote:

> # rsync -a --exclude=/media/backupdrive / /media/backupdrive

> Does the -x switch solve this problem too?

If /media/backupdrive is a separate disk or partition, then yes.

> It might sound naive, but I 
> understood the file system to be everything below /

You have many filesystems. Run 'mount' in a terminal and you will
get a list of your separate file systems. On my machine it looks
like:

/dev/sda1 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
/sys on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type tmpfs (rw,mode=0755)
devshm on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
lrm on /lib/modules/2.6.24-23-generic/volatile type tmpfs (rw)
/dev/sda3 on /home type ext3 (rw)
securityfs on /sys/kernel/security type securityfs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc 
(rw,noexec,nosuid,nodev)
tmpfs on /lib/modules/2.6.24-24-generic/volatile type tmpfs (rw,mode=0755)

Most of those are virtual, with only /dev/sda1 and /dev/sda3 being
real filesystems. On my machine if I did rsync -x / it would not
include /home which is on /dev/sda3, but would include everything
on /dev/sda1.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] /proc and /sys

2009-05-21 Thread david



Jeff Waugh wrote:




I'm doing a back up exercise, and google is not helping me.

I've done a copy of the entire root drive using <# rsync -a>  onto a back
up drive (small because all data is on seperate drives).

To what extent are /proc and /sys recreated by the system as required, and
to what extent do they need to be backed-up? I hope that question makes
sense.


They're entirely virtual filesystems and don't need to be backed up at all.
In general, you should use the -x (or --one-file-system) parameter with
rsync when you're backing up -- saves backing up (and even reading) useless
crap like this.



So *that's* what -x means ;-)


I've been doing:

# rsync -a --exclude=/media/backupdrive / /media/backupdrive

Without --exclude I get some "interesting" results ;-)

Does the -x switch solve this problem too? It might sound naive, but I 
understood the file system to be everything below /

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Proprietary colour names (was GIMP was...)

2009-05-21 Thread david



Glen Turner wrote:

Andrew Cowie wrote:

On Mon, 2009-05-18 at 15:53 +0100, Richard Ibbotson wrote:
... much better than it was but some sort of Pantone colour 
integration would be good (eventually).  An open source version of 
that would need to be implemented.


Which is what the hold up is, at least as I understand it.

The Pantone colour palate (specifically their name-to-ink-colour
mappings) is Pantone's proprietary intellectual property and they have
chosen not to let them be used in libre ways.


Hi Andrew,

The PANTONE CMS gamut is wider than CMYK or RGB. Since there's no
way of accurately displaying PANTONE colours on a RGB screen or
CMYK page PANTONE will still sell their swatch cards.

I can understand that PANTONE can trademark their mixed ink names.
I can understand that PANTONE may patent the inks themselves.
But I don't understand how using that trademarked name to identify
the ink mix product breaches trademark law.  Otherwise I'd better
start asking sales assistants for their "Kola nut carbonated drink"
rather than "Cola-Cola(TM)".

I'd be more than happy if PANTONE support consisted of a box asking
for the text of the PANTONE colour, the RGB I'd like to use to
display that on the screen and the CMYK I'd like to use when printing
drafts.

In practice, that would work by choosing a colour from the swatch,
and entering it's name. Then hold the swatch to the screen until a
good RGB match is found. Press a button to test print a gamut
surrounding that RGB match, hold the test print to the swatch,
enter the corresponding CMYK digits against the best match. Remember
that only one or two spot colours are usually used. And this
procedure automatically calibrates the screen and printer for
the spot colour.

Then the software need not carry the trademarked names, nor name-to-RGB,
nor name-to-CMYK mappings.  In fact, such software wouldn't be specific
to the PANTONE CMS at all.  Which, it seems, would serve PANTONE right.



Excuse my ignorance, but isn't this roughly what colour management 
(http://www.argyllcms.com/?) is supposed to do?

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] Proprietary colour names (was GIMP was...)

2009-05-21 Thread Glen Turner

Andrew Cowie wrote:

On Mon, 2009-05-18 at 15:53 +0100, Richard Ibbotson wrote:
... much better than it was but some sort of Pantone colour 
integration would be good (eventually).  An open source version of 
that would need to be implemented.


Which is what the hold up is, at least as I understand it.

The Pantone colour palate (specifically their name-to-ink-colour
mappings) is Pantone's proprietary intellectual property and they have
chosen not to let them be used in libre ways.


Hi Andrew,

The PANTONE CMS gamut is wider than CMYK or RGB. Since there's no
way of accurately displaying PANTONE colours on a RGB screen or
CMYK page PANTONE will still sell their swatch cards.

I can understand that PANTONE can trademark their mixed ink names.
I can understand that PANTONE may patent the inks themselves.
But I don't understand how using that trademarked name to identify
the ink mix product breaches trademark law.  Otherwise I'd better
start asking sales assistants for their "Kola nut carbonated drink"
rather than "Cola-Cola(TM)".

I'd be more than happy if PANTONE support consisted of a box asking
for the text of the PANTONE colour, the RGB I'd like to use to
display that on the screen and the CMYK I'd like to use when printing
drafts.

In practice, that would work by choosing a colour from the swatch,
and entering it's name. Then hold the swatch to the screen until a
good RGB match is found. Press a button to test print a gamut
surrounding that RGB match, hold the test print to the swatch,
enter the corresponding CMYK digits against the best match. Remember
that only one or two spot colours are usually used. And this
procedure automatically calibrates the screen and printer for
the spot colour.

Then the software need not carry the trademarked names, nor name-to-RGB,
nor name-to-CMYK mappings.  In fact, such software wouldn't be specific
to the PANTONE CMS at all.  Which, it seems, would serve PANTONE right.

Cheers, Glen

--
 Glen Turner
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] /proc and /sys

2009-05-21 Thread Jeff Waugh


> I'm doing a back up exercise, and google is not helping me.
>
> I've done a copy of the entire root drive using <# rsync -a>  onto a back
> up drive (small because all data is on seperate drives).
>
> To what extent are /proc and /sys recreated by the system as required, and
> to what extent do they need to be backed-up? I hope that question makes
> sense.

They're entirely virtual filesystems and don't need to be backed up at all.
In general, you should use the -x (or --one-file-system) parameter with
rsync when you're backing up -- saves backing up (and even reading) useless
crap like this.

- Jeff

-- 
linux.conf.au 2010: Wellington, NZ   http://www.penguinsvisiting.org.nz/
 
  "There's always a new bogeyman - every two months, there's a new axe to
 add to the axis of evil." - Michael Moore
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


[SLUG] /proc and /sys

2009-05-21 Thread david

I'm doing a back up exercise, and google is not helping me.


I've done a copy of the entire root drive using <# rsync -a>  onto a back up 
drive (small because all data is on seperate drives).


To what extent are /proc and /sys recreated by the system as required, and to 
what extent do they need to be backed-up? I hope that question makes sense.


Thanks...

David.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] webcam woes Jaunty

2009-05-21 Thread Daniel Pittman
Ken Foskey  writes:

> There is a problem with Jaunty and webcams that I have:
> https://bugs.launchpad.net/ubuntu/+source/libv4l/+bug/359045
>
> Webcams will occasionally work.
> There is also a Kernel bug that crops up because of something with
> cheese:
>
> cheese: page allocation failure. order:5, mode:0x8004

Wow.  Whatever that driver is, it asked for 2^5, or 32 physically
contiguous pages from the kernel.  /That/ isn't going to work well.

> Googling led me to this:
> http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.30-rc4
> Which I am not running:

No, but that change is just to suppress the warning; apparently the
uvcvideo driver /should/ retry with a smaller request, so that
*probably* isn't an actual problem.

Regards,
Daniel
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


[SLUG] webcam woes Jaunty

2009-05-21 Thread Ken Foskey

There is a problem with Jaunty and webcams that I have:

https://bugs.launchpad.net/ubuntu/+source/libv4l/+bug/359045


Webcams will occasionally work.

There is also a Kernel bug that crops up because of something with
cheese:

cheese: page allocation failure. order:5, mode:0x8004

Googling led me to this:

http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.30-rc4

Which I am not running:

Ubuntu SMP Fri May 1 19:31:32 UTC 2009 (Ubuntu 2.6.28-12.43-generic)


So all in all this is not very successful :-(



-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] Skype on Mythbuntu

2009-05-21 Thread elliott-brennan
Hi All,

I have Mythbuntu 8.04 installed on a box with two
PVR-150 tuners.

I'd like to use Skype as well (I use a cordless
mini keyboard to control the box so can easily
access the other applications).

The problem is I cannot get Skype to see the
webcam. When I run:

ls /dev/video*

I get:

/dev/video0  /dev/video2   /dev/video25  /dev/video33
/dev/video1  /dev/video24  /dev/video32

Which is a bit weird given I only have two tuners.

The Skype set up only sees the two tuners video0
and video1

I've tested the webcam on the same machine with
Cheese - which is great fun - and which can find
the webcam, but when I install effectv - which is
also great fun - it gives me a the following message

v4lgetmbuf:VIDIOCGMBUF: Invalid argument
video_init: mmap interface is not supported by
this driver.

regardless of the /dev/video option I use.

I've googled it but couldn't find anything
particularly helpful or specific to this problem.

Anyone with any ideas?

Many thanks in advance.

Regards,

Patrick




-- 
Registered GNU/Linux User 368634
www.youcantdothatinlinux.com
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] system restore from boot menu

2009-05-21 Thread Jeremy Visser
On Thu, 2009-05-21 at 12:25 +1000, Jake Anderson wrote:
> I can see how it can be done, but I don't imagine I'm the first person 
> to want to do something like this and I was wondering if anybody had 
> some experience with a similar solution?

It can easily be done with a specially crafted initramfs and a partition
to hold an image on. It's the fastest solution from a reimaging
perspective, but actually building the system may take some time.

Basically build a statically-compiled dd, statically-compile a simple
little C program (as /init) to exec the dd, and have a minimal udev
system (don't know if there's anything simpler).

Basically, you use cpio to archive those couple of files and tell grub
to boot the initramfs with an existing kernel. The tiny /init will exec
dd with the appropriate parameters (e.g. dd if=/dev/sda3 of=/dev/sda2).

Easiest way to play around with that stuff is with QEMU. QEMU can boot a
kernel and initrd without even needing to set up a virtual disk with
bootloaders and stuff: qemu -kernel /boot/vmlinuz -initrd=/your/initrd

I've got some scripts and makefiles around for doing this exact stuff.
Most important thing is to statically compile stuff. Tracking down
shared libraries is a pain, even with the use of ldd. With only two or
three executables, your initrd will not even grow beyond a megabyte or
two.

The system hinges on GRUB working, and having the kernel and initrd not
die. For best results, keep them in /boot and on a separate partition,
preferably sda1 (or mmcblk0p1 if it's embedded).


signature.asc
Description: This is a digitally signed message part
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] system restore from boot menu

2009-05-21 Thread R.G.Salisbury

Grub is very smart but not as smart as you want  believe.
It has 38 commands (see below)

You can easily achieve you goal *without  reinstalling,   swapping out disks 
or  entering rescue mode  to fix things.


"DD"  is nearly always available!

However no matter how badly a system gets hosed,  there is nearly always 
/sbin that stays intact.
Also /etc/fstab & a few other files of paramount importance are often intact 
to allow a minimal system to be run.

.  then you have "dd"   to copy partions here & there.

The 3 Run levels of : emergency , 1 , S   often are available  when you 
can't boot the system to higher run levels.

If ALL the above fails .
appending" init=/bin/bash "
to the kernel grub line will often work. (albeit in read only)  you can fix 
that by "/sbin/mount -o remount,rw /"

note the full path is probably required.

Then DD will be available  " /sbin/dd"

If you have an exact image of a partiton  elswhere just clobber the partion 
you have booted to.


Of course you must be certain of what partition you are on. ( having an 
erronous entry in fstab may fool you at this point... in which case 
"/sbin/df" will tell you lies.


The gotcha points are that /boot/grub/grub.conf entries must coincide 
with /etc/fstab.


Three variations work with these files
1  "device" names   as  a naming convention
2  "label"  names   as  a naming convention
3  "UUID"  strings   as  a naming convention
... again  grub.conf  &fstab must coincide

Hope this helps

Roger

Grub commands ..  no dd  or cp etc

1  blocklist FILE
2  boot
3  cat FILE
4  chainloader [--force] FILE
5  clear
6  color NORMAL [HIGHLIGHT]
7  configfile FILE
8  device DRIVE DEVICE
9  displayapm
   10  displaymem
   11  find FILENAME
   12  geometry DRIVE [CYLINDER HEAD SECTOR [
   13  halt [--no-apm]
   14  help [--all] [PATTERN ...]
   15  hide PARTITION
   16  initrd FILE [ARG ...]
   17  kernel [--no-mem-option] [--type=TYPE]
   18  makeactive
   19  map TO_DRIVE FROM_DRIVE
   20  md5crypt
   21  module FILE [ARG ...]
   22  modulenounzip FILE [ARG ...]
   23  pager [FLAG]
   24  partnew PART TYPE START LEN
   25  parttype PART TYPE
   26  quit
   27  reboot
   28  root [DEVICE [HDBIAS]]
   29  rootnoverify [DEVICE [HDBIAS]]
   30  serial [--unit=UNIT] [--port=PORT] [--
   31  setkey [TO_KEY FROM_KEY]
   32  setup [--prefix=DIR] [--stage2=STAGE2_
   33  terminal [--dumb] [--no-echo] [--no-ed
   34  terminfo [--name=NAME --cursor-address
   35  testvbe MODE
   36  unhide PARTITION
   37  uppermem KBYTES
   38  vbeprobe [MODE] 


--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html