From togo at of.net  Fri Apr  1 14:05:09 2011
From: togo at of.net (Tony Godshall)
Date: Fri, 1 Apr 2011 14:05:09 -0700
Subject: [buug] Bup creator to give presentation Apr 9 or 10
In-Reply-To: <AANLkTik6D23Ezsvz3_6ypDfakvXZESENStGt1PXoNAU_@mail.gmail.com>
References: <AANLkTik6D23Ezsvz3_6ypDfakvXZESENStGt1PXoNAU_@mail.gmail.com>
Message-ID: <AANLkTinPvcnR6POACWiRT6H-ELbamMm4ydrDa-tEnLVf@mail.gmail.com>

Hi everyone

Bup "it backs things up" does efficient sub-file deduplication and
compression suitable for disk-to-disk or disk-to-remote-host backups.

It's based git and python and the rolling-checksum concept that makes
rsync transfers so efficient.

Bup has no user-friendly graphical UI yet- this will be more about the
technology and the commandline interface.

Avery wrote his Ph.D. thesis on this idea- it's sure to be
interesting, especially if you are familiar with git and hashes and
data compression algorithms.

Avery will be in town in about a week and has agreed to give a
presentation, and I'm working on the details. ?No location has been
set yet- I thought I'd get the general word out sooner rather than
later to make sure word gets to the right people. ?Please respond
privately if you hope to attend so I can figure out whether I can host
it at my place in SF or if I'll need to look for a bigger venue...
I'll send the specific location and schedule soon as it's firm.

Best Regards.

Tony



PS1: If you websearch for "bup", you'll be disappointed. ?Searching
for "bup It Backs Things Up" gives much better results.

PS2: Feel free to forward


From khogoboom at gmail.com  Sat Apr  2 10:49:33 2011
From: khogoboom at gmail.com (Karen Hogoboom)
Date: Sat, 2 Apr 2011 10:49:33 -0700
Subject: [buug] Bup creator to give presentation Apr 9 or 10
In-Reply-To: <AANLkTinPvcnR6POACWiRT6H-ELbamMm4ydrDa-tEnLVf@mail.gmail.com>
References: <AANLkTik6D23Ezsvz3_6ypDfakvXZESENStGt1PXoNAU_@mail.gmail.com>
	<AANLkTinPvcnR6POACWiRT6H-ELbamMm4ydrDa-tEnLVf@mail.gmail.com>
Message-ID: <BANLkTi=CBLGkYPvU0D_xZMi3D+1szStSmw@mail.gmail.com>

I am interested in attending.

On Fri, Apr 1, 2011 at 2:05 PM, Tony Godshall <togo at of.net> wrote:

> Hi everyone
>
> Bup "it backs things up" does efficient sub-file deduplication and
> compression suitable for disk-to-disk or disk-to-remote-host backups.
>
> It's based git and python and the rolling-checksum concept that makes
> rsync transfers so efficient.
>
> Bup has no user-friendly graphical UI yet- this will be more about the
> technology and the commandline interface.
>
> Avery wrote his Ph.D. thesis on this idea- it's sure to be
> interesting, especially if you are familiar with git and hashes and
> data compression algorithms.
>
> Avery will be in town in about a week and has agreed to give a
> presentation, and I'm working on the details.  No location has been
> set yet- I thought I'd get the general word out sooner rather than
> later to make sure word gets to the right people.  Please respond
> privately if you hope to attend so I can figure out whether I can host
> it at my place in SF or if I'll need to look for a bigger venue...
> I'll send the specific location and schedule soon as it's firm.
>
> Best Regards.
>
> Tony
>
>
>
> PS1: If you websearch for "bup", you'll be disappointed.  Searching
> for "bup It Backs Things Up" gives much better results.
>
> PS2: Feel free to forward
> _______________________________________________
> Buug mailing list
> Buug at weak.org
> http://www.weak.org/mailman/listinfo/buug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buug.org/pipermail/buug/attachments/20110402/c2c2d122/attachment.html>

From togo at of.net  Mon Apr  4 16:20:05 2011
From: togo at of.net (Tony Godshall)
Date: Mon, 4 Apr 2011 16:20:05 -0700
Subject: [buug] Bup creator to give presentation Apr 9 or 10
In-Reply-To: <AANLkTinPvcnR6POACWiRT6H-ELbamMm4ydrDa-tEnLVf@mail.gmail.com>
References: <AANLkTik6D23Ezsvz3_6ypDfakvXZESENStGt1PXoNAU_@mail.gmail.com>
	<AANLkTinPvcnR6POACWiRT6H-ELbamMm4ydrDa-tEnLVf@mail.gmail.com>
Message-ID: <BANLkTikarOox17t49u+37EUBuTMT4B9P5Q@mail.gmail.com>

Hi again

I've scheduled Avery's presentation[1] for Saturday April 9 at 2:30pm in my
livingroom, a stone's throw from Grace Cathedral in SF.  Those who RSVP
will get the precise address and directions.  It's a mile from Embarcadero
staiton (BART/SF Muni rail), and one can take the very frequent 1-California
electric bus to the top of the hill.  There's also a cable car option
if you want
the $5 tourist experience (the California line is out of service but
the Powell.
It's 1.9 miles from Caltrain, and one can take the very frequent KT trolley to
Embarcadero Station, and as above.

If you can come at that time, please RSVP tony at godshall.org with
subject "bup SF"

Please feel free to pass the details above to anyone you think might
be interested.

Best Regards

Tony


[1] Original message:


> Hi everyone
>
> Bup "it backs things up" does efficient sub-file deduplication and
> compression suitable for disk-to-disk or disk-to-remote-host backups.
>
> It's based git and python and the rolling-checksum concept that makes
> rsync transfers so efficient.
>
> Bup has no user-friendly graphical UI yet- this will be more about the
> technology and the commandline interface.
>
> Avery wrote his Ph.D. thesis on this idea- it's sure to be
> interesting, especially if you are familiar with git and hashes and
> data compression algorithms.
>
> Avery will be in town in about a week and has agreed to give a
> presentation, and I'm working on the details. ?No location has been
> set yet- I thought I'd get the general word out sooner rather than
> later to make sure word gets to the right people. ?Please respond
> privately if you hope to attend so I can figure out whether I can host
> it at my place in SF or if I'll need to look for a bigger venue...
> I'll send the specific location and schedule soon as it's firm.
>
> Best Regards.
>
> Tony
>
>
>
> PS1: If you websearch for "bup", you'll be disappointed. ?Searching
> for "bup It Backs Things Up" gives much better results.
>
> PS2: Feel free to forward
>


From togo at of.net  Mon Apr  4 16:20:10 2011
From: togo at of.net (Tony Godshall)
Date: Mon, 4 Apr 2011 16:20:10 -0700
Subject: [buug] Bup creator to give presentation Apr 9 or 10
In-Reply-To: <AANLkTinPvcnR6POACWiRT6H-ELbamMm4ydrDa-tEnLVf@mail.gmail.com>
References: <AANLkTik6D23Ezsvz3_6ypDfakvXZESENStGt1PXoNAU_@mail.gmail.com>
	<AANLkTinPvcnR6POACWiRT6H-ELbamMm4ydrDa-tEnLVf@mail.gmail.com>
Message-ID: <BANLkTikzPDXTqmuu3Nip6oBp+akC-ntBxg@mail.gmail.com>

Hi again

I've scheduled Avery's presentation[1] for Saturday April 9 at 2:30pm in my
livingroom, a stone's throw from Grace Cathedral in SF.  Those who RSVP
will get the precise address and directions.  It's a mile from Embarcadero
staiton (BART/SF Muni rail), and one can take the very frequent 1-California
electric bus to the top of the hill.  There's also a cable car option
if you want
the $5 tourist experience (the California line is out of service but
the Powell.
It's 1.9 miles from Caltrain, and one can take the very frequent KT trolley to
Embarcadero Station, and as above.

If you can come at that time, please RSVP tony at godshall.org with
subject "bup SF"

Please feel free to pass the details above to anyone you think might
be interested.

Best Regards

Tony


[1] Original message:


> Hi everyone
>
> Bup "it backs things up" does efficient sub-file deduplication and
> compression suitable for disk-to-disk or disk-to-remote-host backups.
>
> It's based git and python and the rolling-checksum concept that makes
> rsync transfers so efficient.
>
> Bup has no user-friendly graphical UI yet- this will be more about the
> technology and the commandline interface.
>
> Avery wrote his Ph.D. thesis on this idea- it's sure to be
> interesting, especially if you are familiar with git and hashes and
> data compression algorithms.
>
> Avery will be in town in about a week and has agreed to give a
> presentation, and I'm working on the details. ?No location has been
> set yet- I thought I'd get the general word out sooner rather than
> later to make sure word gets to the right people. ?Please respond
> privately if you hope to attend so I can figure out whether I can host
> it at my place in SF or if I'll need to look for a bigger venue...
> I'll send the specific location and schedule soon as it's firm.
>
> Best Regards.
>
> Tony
>
>
>
> PS1: If you websearch for "bup", you'll be disappointed. ?Searching
> for "bup It Backs Things Up" gives much better results.
>
> PS2: Feel free to forward
>


From togo at of.net  Tue Apr  5 16:01:33 2011
From: togo at of.net (Tony Godshall)
Date: Tue, 5 Apr 2011 16:01:33 -0700
Subject: [buug] Bup creator to give present Apr 9 at 2:30 PM in SF
In-Reply-To: <BANLkTimN+49bMp5NDxYXTZYMGT-PLF-KsQ@mail.gmail.com>
References: <BANLkTimN+49bMp5NDxYXTZYMGT-PLF-KsQ@mail.gmail.com>
Message-ID: <BANLkTintpcOkjm2D3PuJGjOmX3b+k9TX2g@mail.gmail.com>

Hi again

I've scheduled Avery's presentation[1] for Saturday April 9 at 2:30pm in my
livingroom, a stone's throw from Grace Cathedral in SF. ?Those who RSVP
will get the precise address and directions. ?It's a mile from the Embarcadero
BART/SF Muni rail station and 1.9 miles from Caltrain with electric bus access
from both. ?Parking can be had, for a price, at various local garages.

If plan to come at that time, please RSVP tony at godshall.org or togo at of.net
with subject "bup SF" and you'll receive the specific address and more details
on how to get here.

Please feel free to pass the details above to anyone you think might
be interested.

Best Regards

Tony


[1] Original message:


> Hi everyone
>
> Bup "it backs things up" does efficient sub-file deduplication and
> compression suitable for disk-to-disk or disk-to-remote-host backups.
>
> It's based git and python and the rolling-checksum concept that makes
> rsync transfers so efficient.
>
> Bup has no user-friendly graphical UI yet- this will be more about the
> technology and the commandline interface.
>
> Avery wrote his Ph.D. thesis on this idea- it's sure to be
> interesting, especially if you are familiar with git and hashes and
> data compression algorithms.
>
> Avery will be in town in about a week and has agreed to give a
> presentation, and I'm working on the details. ?No location has been
> set yet- I thought I'd get the general word out sooner rather than
> later to make sure word gets to the right people. ?Please respond
> privately if you hope to attend so I can figure out whether I can host
> it at my place in SF or if I'll need to look for a bigger venue...
> I'll send the specific location and schedule soon as it's firm.
>
> Best Regards.
>
> Tony
>
>
>
> PS1: If you websearch for "bup", you'll be disappointed. ?Searching
> for "bup It Backs Things Up" gives much better results.
>
> PS2: Feel free to forward
>


From Michael.Paoli at cal.berkeley.edu  Wed Apr  6 19:01:36 2011
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Wed, 06 Apr 2011 19:01:36 -0700
Subject: [buug] CDs, etc. @ BUUG Thursday (tomorrow)
In-Reply-To: <20110303174316.14314wsrg63ezs84@webmail.rawbw.com>
References: <20110303174316.14314wsrg63ezs84@webmail.rawbw.com>
Message-ID: <20110406190136.37285r24a7g5oysk@webmail.rawbw.com>

I'm intending to be there, and with various CDs/images and other items:
http://www.wiki.balug.org/wiki/doku.php?id=balug:cds_and_images_etc



From Michael.Paoli at cal.berkeley.edu  Wed Apr  6 19:51:22 2011
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Wed, 06 Apr 2011 19:51:22 -0700
Subject: [buug] vim annoyances
Message-ID: <20110406195122.22397a9uzy5nnlc8@webmail.rawbw.com>

Yes, vim bit me again today,
:q! wouldn't quit,
and it quite repeatedly forgot the name of the file I was editing.
And all that even with its "compatible" mode.

 From my vim annoyances collection (at least what I bothered to note,
anyway):

vim never ceases to annoy me:

I edit a series of files using their full pathnames - given as command
line arguments, I use ^G to note which file I'm editing - vim displays
only a partial relative pathname - omitting the portion which allows me
to distinguish which of two files I might be editing that have the last
to parts of their pathname that are identical.  To make it worse, "Ah,
workaround; :!echo %<CR> ... no go, it still only tells me that
relative pathname tail component!  ARRRRGH!
This causes various problems, e.g. things like this don't behave as one
would expect:
:!cd / && ls -ld %<CR>
vim should never have the arrogance to presume it's smarter than those
using it or knows better what they want than they do

bloody .swp files!

When one does an operation that happens to take a long time in vim, e.g.
deleting a bunch of lines:
:1,BIGNUMd
It's darn near impossible to interrupt/stop vim!
interrupt (e.g. control-C) doesn't stop it, neither does:
quit (e.g. control-\)
and it doesn't even let one use job control to suspend (e.g. control-Z)
so that one can manually kill the sucker with some appropriate
signal(s).  One typically has to resort to killing the sucker via some
other login session on the host.

Dark blue on black?  You've got to be kidding!  If I wanted comments to
be bloody invisible I wouldn't have written them!

Colors?  Ewwww, ... yuck!  Distracting!  Makes it much harder for the
eyeballs to scan and see what I want to identify.

Oh my gosh, something went horribly wrong!  I invoked vi with no
arguments, and there's a whole lot more on the screen than just the
tildie (~) characters in the leftmost column.  Must be some
catastrophic error.  Oh, yes, it is ... vim.

~
~                              VIM - Vi IMproved
~
~                               version 7.1.314
~                           by Bram Moolenaar et al.
~                 Vim is open source and freely distributable
~
~                           Sponsor Vim development!
~                type  :help sponsor<Enter>    for information
~
~                type  :q<Enter>               to exit
~                type  :help<Enter>  or  <F1>  for on-line help
~                type  :help version7<Enter>   for version info

"Oh, you can change that in vim, just configure ..." - bloody heck, it
should do the right thing by default!  And yes, I've tried vim's :se
compatible - it's not very compatible, and it's also not the default
either.

bloody .sw[o-z] files

bloody non-FHS compliant doesn't know where to properly write temporary
files!  I did mention .sw[o-z] files, right?  I don't think I mentioned
them enough yet.

regular expressions, there's shell metasyntax, there's Basic Regular
Expressions, there's Extended Regular Expressions, there's Perl Regular
Expressions, and damn near everyone does it exactly or almost exactly
like one of those, but vim, no, you couldn't do like those with one or
two or three or so exceptions, but you add a whole bunch of stuff in
vim regular expressions that matches no one else's regular expressions
- highly incompatible.  And yes I tried vim's compatible option, and
not it's not compatible.

I've used (classic UNIX) vi and BSD vi / nvi for decades, my fingers
fly on the keyboard issuing vi commands - it works, and works damn
well.  I know what to expect and it does what I expect.  Vim does not,
and repeatedly slows me down, frustrates me, and causes significant
errors.  And yes I tried vim's compatible mode - it's not compatible.

:se all
Though shallt fit complete full output of :se all within a single 80x24
window, ... not 3 bloody screenfulls of 80x24.

vim is bloated:
$ ls -lLs /usr/bin/nvi /usr/bin/vim /usr/bin/vim.tiny | sort -bn
  372 -rwxr-xr-x 3 root root  372740 Jan 28  2010 /usr/bin/nvi
  624 -rwxr-xr-x 1 root root  632884 Jul 11  2010 /usr/bin/vim.tiny
1480 -rwxr-xr-x 1 root root 1510796 Jul 11  2010 /usr/bin/vim
$
Yes, even it's tiny version is bloated

can't recover cleanly without tracking down all the bloody .sw[o-z]  
files - oh, did I mention the bloody .sw[o-z] files?

:q! fails to quit!!!!
:se
--- Options ---
nobuflisted           shelltemp           ttyfast
   fileencoding=utf-8
   fileencodings=ucs-bom,utf-8,default,latin1
Press ENTER or type command to continue
:q!
E37: No write since last change (add ! to override)
E162: No write since last change for buffer "[No Name]"
Press ENTER or type command to continue
:q!!
E488: Trailing characters
:!kill -1 $PPID
[No write since last change]

Vim: Caught deadly signal HUP
Vim: preserving files...

Vim: Finished.
Hangup
$ rm .swp
$

vim repeatedly bloody annoyingly forgets what file I'm working on.  Yes,
I've tried it's compatible mode, it's not.  It also very annoyingly
tells me the permissions on the file have changed - duh, of course they
have, I did it - stupid annoying vim:

$ vi foo
"foo" [New File]
//i - go into insert mode
//insert a bunch of stuff
//<ESC>
:w
"foo" [New] 73L, 1254C written
:!chmod a+rx %
Press ENTER or type command to continue
//Bloody hell - and compatible doesn't shut this stupidity off:
W16: Warning: Mode of file "foo" has changed since editing st
artedSee ":help W16" for more info.
Press ENTER or type command to continue
:!ls -ld %
//Now you're really pissing me off!  You forgot what file I'm working on!
E499: Empty file name for '%' or '#', only works with ":p:h"
Press ENTER or type command to continue
:w
E32: No file name
//bloody hell!  I'll tell the damn poor excuse for an editor!:
:f foo
"foo" [Not edited] line 1 of 73 --1%-- col 1
//yeah, right, whatever ...
:w
E13: File exists (add ! to override)
:w!
"foo" 73L, 1254C written
:!chmod go=r %
Press ENTER or type command to continue
W16: Warning: Mode of file "foo" has changed since editing st
artedSee ":help W16" for more info.
:!ls -ld %
E499: Empty file name for '%' or '#', only works with ":p:h"
Press ENTER or type command to continue
:help W16
E433: No tags file
E149: Sorry, no help for W16
Press ENTER or type command to continue
//bloody tell this retarded editor again
:f foo
//make an edit change, then change permissions again:
:!chmod go=r %
[No write since last change]

Press ENTER or type command to continue
W16: Warning: Mode of file "foo" has changed since editing st
artedSee ":help W16" for more info.
:w
E32: No file name
:w!
E32: No file name
:q!
E37: No write since last change (add ! to override)
E162: No write since last change for buffer "foo"
Press ENTER or type command to continue
:!kill -1 $PPID
[No write since last change]

Vim: Caught deadly signal HUP
Vim: preserving files...

Vim: Finished.
Hangup
$ rm .swp
$



From pi at berkeley.edu  Wed Apr  6 21:20:45 2011
From: pi at berkeley.edu (Paul Ivanov)
Date: Wed, 6 Apr 2011 21:20:45 -0700
Subject: [buug] vim annoyances
In-Reply-To: <20110406195122.22397a9uzy5nnlc8@webmail.rawbw.com>
References: <20110406195122.22397a9uzy5nnlc8@webmail.rawbw.com>
Message-ID: <20110407042045.GF24166@ykcyc>


Hi Michael,

I'm sorry vim doesn't work the way you expect, but I can't sit by
and let you drag my $EDITOR through the mud ;) without responding
to at least some of your frustrations. See also the last
paragraph of the email, if you're not very interested in the
solutions provided here ;)

If you find yourself forced to use vim - I'll give you a few
entries to add to your vimrc that will hopefully make your life
better.  (NB: having a .vimrc reverts the default behavior vim
starting in "compatible" mode - so you'll want to include that as
well - since having one clearly indicates that you know what vim
is).

" Note: double quotes are the comment character in .vimrc
"

Michael Paoli, on 2011-04-06 19:51,  wrote:
> Yes, vim bit me again today,
> :q! wouldn't quit

was there a message? can you give steps on how to reproduce?
was there another buffer you edited that hadn't been saved"

from :help :quit!

:q[uit]  Quit without writing, also when visible buffers have
         changes.  Does not exit when there are changed hidden
         buffers.  Use ":qall!" to exit always.

" .vimrc solution
" have a save/ignore popup, instead of e.g. failing to quit a
" modified buffer. This will make your :q! experiences more sane
set confirm

> and it quite repeatedly forgot the name of the file I was editing.
> And all that even with its "compatible" mode.

Compatible mode never promised to be a bug-for-bug compatible
with vi. But for all its shortcomings, vim does have extensive
documentation to help you navigate through all of its
'annoyances'.
	
from :help compat

  This option has the effect of making Vim either more
  Vi-compatible, or make Vim behave in a more useful way.

see :help posix for all the documented ways in which vim does not
adhere to POSIX vi behaviour.


> From my vim annoyances collection (at least what I bothered to note,
> anyway):
> 
> vim never ceases to annoy me:
> 
> I edit a series of files using their full pathnames - given as command
> line arguments, I use ^G to note which file I'm editing - vim displays
> only a partial relative pathname - omitting the portion which allows me
> to distinguish which of two files I might be editing that have the last
> to parts of their pathname that are identical.  To make it worse, "Ah,
> workaround; :!echo %<CR> ... no go, it still only tells me that
> relative pathname tail component!  ARRRRGH!
> This causes various problems, e.g. things like this don't behave as one
> would expect:
> :!cd / && ls -ld %<CR>
> vim should never have the arrogance to presume it's smarter than those
> using it or knows better what they want than they do

you can get the full path by appending :p to the %
:!echo %:p ... is the thing you wanted
see :help filename-modifiers for more

another way of getting around this is to :cd / first - so
everything gets a full path (your ^G will work as you expect it
to). You can cd back to the directory of a given file using 
:cd %:h

" I have a :CD command defined in my .vimrc to do just that
" CD to directory containing the current file
command! CD :cd %:h

> 
> bloody .swp files!
 

" Let's not sprinkle .swp files in every directory we go inside -  ~/tmp 
" ought to be enough, use the full path of the file (//)
set dir=~/tmp//,/var/tmp//,/tmp//


> When one does an operation that happens to take a long time in vim, e.g.
> deleting a bunch of lines:
> :1,BIGNUMd
> It's darn near impossible to interrupt/stop vim!
> interrupt (e.g. control-C) doesn't stop it, neither does:
> quit (e.g. control-\)
> and it doesn't even let one use job control to suspend (e.g. control-Z)
> so that one can manually kill the sucker with some appropriate
> signal(s).  One typically has to resort to killing the sucker via some
> other login session on the host.
> 
> Dark blue on black?  You've got to be kidding!  If I wanted comments to
> be bloody invisible I wouldn't have written them!
> 
> Colors?  Ewwww, ... yuck!  Distracting!  Makes it much harder for the
> eyeballs to scan and see what I want to identify.
 
"turn off syntax highlighting
syn off

> Oh my gosh, something went horribly wrong!  I invoked vi with no
> arguments, and there's a whole lot more on the screen than just the
> tildie (~) characters in the leftmost column.  Must be some
> catastrophic error.  Oh, yes, it is ... vim.
> 
> ~
> ~                              VIM - Vi IMproved
> ~
> ~                               version 7.1.314
> ~                           by Bram Moolenaar et al.
> ~                 Vim is open source and freely distributable
> ~
> ~                           Sponsor Vim development!
> ~                type  :help sponsor<Enter>    for information
> ~
> ~                type  :q<Enter>               to exit
> ~                type  :help<Enter>  or  <F1>  for on-line help
> ~                type  :help version7<Enter>   for version info
> 

" don't show startup message - just gimme a column of tildes, the
" way Bill Joy wanted it
set shortmess+=I

> "Oh, you can change that in vim, just configure ..." - bloody heck, it
> should do the right thing by default!  

I'd argue that this *is* the right thing - it's letting you know
that it's *NOT* vi - it's something slightly different.

> And yes, I've tried vim's :se
> compatible - it's not very compatible, and it's also not the default
> either.

it's the default if it didn't find a .vimrc or a .gvimrc

'compatible' 'cp' boolean (default on, off when a |vimrc| or |gvimrc| file is found)

> 
> bloody .sw[o-z] files
> 
> bloody non-FHS compliant doesn't know where to properly write temporary
> files!  I did mention .sw[o-z] files, right?  I don't think I mentioned
> them enough yet.

" if you really don't want swapfiles, you can stop making them
set noswapfile
 
> regular expressions, there's shell metasyntax, there's Basic Regular
> Expressions, there's Extended Regular Expressions, there's Perl Regular
> Expressions, and damn near everyone does it exactly or almost exactly
> like one of those, but vim, no, you couldn't do like those with one or
> two or three or so exceptions, but you add a whole bunch of stuff in
> vim regular expressions that matches no one else's regular expressions
> - highly incompatible.  And yes I tried vim's compatible option, and
> not it's not compatible.
> 
> I've used (classic UNIX) vi and BSD vi / nvi for decades, my fingers
> fly on the keyboard issuing vi commands - it works, and works damn
> well.  I know what to expect and it does what I expect.  Vim does not,
> and repeatedly slows me down, frustrates me, and causes significant
> errors.  And yes I tried vim's compatible mode - it's not compatible.

if vim slows you down, please do not use it. Emacs slows me down
to no end - but you won't hear me complaining about it ;)

 
> :se all
> Though shallt fit complete full output of :se all within a single 80x24
> window, ... not 3 bloody screenfulls of 80x24.
> 
> vim is bloated:
> $ ls -lLs /usr/bin/nvi /usr/bin/vim /usr/bin/vim.tiny | sort -bn
>  372 -rwxr-xr-x 3 root root  372740 Jan 28  2010 /usr/bin/nvi
>  624 -rwxr-xr-x 1 root root  632884 Jul 11  2010 /usr/bin/vim.tiny
> 1480 -rwxr-xr-x 1 root root 1510796 Jul 11  2010 /usr/bin/vim
> $
> Yes, even it's tiny version is bloated

You have to consider functionality, not just size. By that
measure, nvi is bloated, too - since it's still almost 9x larger
than ed: 
$ ls -ls /bin/ed
40 -rwxr-xr-x 1 root root 39700 2010-03-04 19:47 /bin/ed

I didn't follow all of the rest but I'd be happy to try to sort
through them with you tomorrow.

It seems like your angst is a bit misdirected - you should be
mad at whoever is forcing you to use vim, or if you're not being
forced - use your preferred editor.

best,
-- 
Paul Ivanov
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://buug.org/pipermail/buug/attachments/20110406/5c38d86d/attachment.sig>

From Michael.Paoli at cal.berkeley.edu  Thu Apr  7 01:28:17 2011
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Thu, 07 Apr 2011 01:28:17 -0700
Subject: [buug] vim (& "certain" Linux distributions) annoyances
In-Reply-To: <20110407042045.GF24166@ykcyc>
References: <20110406195122.22397a9uzy5nnlc8@webmail.rawbw.com>
	<20110407042045.GF24166@ykcyc>
Message-ID: <20110407012817.67216ci8sfxerl8o@webmail.rawbw.com>

> From: "Paul Ivanov" <pi at berkeley.edu>
> Subject: Re: [buug] vim annoyances
> Date: Wed, 6 Apr 2011 21:20:45 -0700

> I'm sorry vim doesn't work the way you expect, but I can't sit by
> and let you drag my $EDITOR through the mud ;) without responding
> to at least some of your frustrations. See also the last
> paragraph of the email, if you're not very interested in the
> solutions provided here ;)

Thanks for the useful information, but vim just isn't that [n]vi
compatible, and probably never will be.  Needing to set .vimrc files to
try and make it more compatible, especially when having to work on
hundreds or more hosts, isn't very convenient.

> It seems like your angst is a bit misdirected - you should be
> mad at whoever is forcing you to use vim, or if you're not being
> forced - use your preferred editor.

Yes, rather true that.  Linux distributions that execute vim when one
invokes the vi command, and that don't even provide [n]vi as an
available package are quite annoying.  I could mention a whole lot more
annoyances of certain such Linux distributions (e.g. like package
management commands that return an exit code of zero after having
miserably failed to install a package as requested, and other assorted
drain bamage).  Sometimes the best solution is use some other Linux
distribution, or a BSD (and that's one the BSDs got right - on the BSDs,
if one invokes vi, one gets [n]vi, not vim! :-)), or use scp or the like
and edit the file elsewhere with a sane editor like [n]vi, or use ed
:-).

Oh yeah, ... and some other serious vim annoyances ... but I'll add 'em
to my list and save 'em for another time ;-).



From itz at buug.org  Thu Apr  7 17:19:54 2011
From: itz at buug.org (Ian Zimmerman)
Date: Thu, 07 Apr 2011 17:19:54 -0700
Subject: [buug] vim (& "certain" Linux distributions) annoyances
In-Reply-To: <20110407012817.67216ci8sfxerl8o@webmail.rawbw.com> (Michael
	Paoli's message of "Thu, 07 Apr 2011 01:28:17 -0700")
References: <20110406195122.22397a9uzy5nnlc8@webmail.rawbw.com>
	<20110407042045.GF24166@ykcyc>
	<20110407012817.67216ci8sfxerl8o@webmail.rawbw.com>
Message-ID: <87oc4hfvbp.fsf@matica.localdomain>


Michael> Oh yeah, ... and some other serious vim annoyances ... but I'll
Michael> add 'em to my list and save 'em for another time ;-).

Someone should post a similar list for nvi, LOL.  I am not volunteering,
but the way it handles keypad and cursor keys (ie. it doesn't) would be
a start.

-- 
Ian Zimmerman <itz at buug.org>
gpg public key: 1024D/C6FF61AD 
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
Ham is for reading, not for eating.



From khogoboom at gmail.com  Fri Apr  8 06:59:25 2011
From: khogoboom at gmail.com (Karen Hogoboom)
Date: Fri, 8 Apr 2011 06:59:25 -0700
Subject: [buug] vim (& "certain" Linux distributions) annoyances
In-Reply-To: <87oc4hfvbp.fsf@matica.localdomain>
References: <20110406195122.22397a9uzy5nnlc8@webmail.rawbw.com>
	<20110407042045.GF24166@ykcyc>
	<20110407012817.67216ci8sfxerl8o@webmail.rawbw.com>
	<87oc4hfvbp.fsf@matica.localdomain>
Message-ID: <BANLkTi=kc+Uztjnj1Uv4xHRRDMJT8yL8Gg@mail.gmail.com>

I'm a woman and I've already volunteered and given away for free enough, so
I'm not volunteering.

On Thu, Apr 7, 2011 at 5:19 PM, Ian Zimmerman <itz at buug.org> wrote:

>
> Michael> Oh yeah, ... and some other serious vim annoyances ... but I'll
> Michael> add 'em to my list and save 'em for another time ;-).
>
> Someone should post a similar list for nvi, LOL.  I am not volunteering,
> but the way it handles keypad and cursor keys (ie. it doesn't) would be
> a start.
>
> --
> Ian Zimmerman <itz at buug.org>
> gpg public key: 1024D/C6FF61AD
> fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
> Ham is for reading, not for eating.
>
> _______________________________________________
> Buug mailing list
> Buug at weak.org
> http://www.weak.org/mailman/listinfo/buug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buug.org/pipermail/buug/attachments/20110408/aad59a7b/attachment.html>

From Michael.Paoli at cal.berkeley.edu  Fri Apr  8 15:49:54 2011
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Fri, 08 Apr 2011 15:49:54 -0700
Subject: [buug] BALUG Tu 2011-04-19: GlusterFS - Petascale Cloud Filesystem,
	Anand	Babu (AB) Periasamy & other BALUG news
Message-ID: <20110408154954.72787ja9qh09f1wc@webmail.rawbw.com>

BALUG Tu 2011-04-19: GlusterFS - Petascale Cloud Filesystem, Anand  
Babu (AB) Periasamy & other BALUG news

In this issue (details further below):

2011-04-19 Tu: BALUG meeting Tu:
     GlusterFS - Petascale Cloud Filesystem, Anand Babu (AB) Periasamy
     Also, Linux CDs and other giveaway items.

2011-05-17: Cloud.com's Mark Hinkle, VP of Community, on: Open Source
     Solutions for Building and Deploying Private and Public Clouds

"Slides" from 2011-03-15 BALUG meetnig:
Jack Deslippe on Developing for Android

Other Linux & Open Source happenings

Twitter! - follow BALUG on Twitter: BALUG_org

------------------------------

Bay Area Linux User Group (BALUG) meeting
Tuesday 6:30 P.M. 2011-04-19

Please RSVP if you're planning to come (see further below).

For our Tuesday 6:30 P.M. 2011-04-19 meeting, we're proud to present:

Anand Babu (AB) Periasamy, CTO Gluster[2] on
GlusterFS[1] - Petascale Cloud Filesystem

Title: - GlusterFS - Petascale Cloud Filesystem

Abstract: As the explosion of unstructured data continues unabated,
filesystems are under tremendous architectural strain.  Traditional and
hybrid filesystem architectures fail to meet the demanding challenges of
both public and private clouds and users in these environments struggle
with filesystem limitations.  The GlusterFS petascale filesystem
architecture is designed to easily handle massive amounts of
unstructured data and linearly scale performance and capacity in order
to efficiently manage unplanned spikes in performance and provide high
availability as a standard function of the filesystem. GlusterFS is an
Open Source filesystem.

Anand Babu (AB) Periasamy, CTO
As CTO and Co-founder, AB sets the vision and strategy for the Gluster
product platform.  Prior to Gluster, AB served as CTO at California
Digital Corporation[3] (CDC), where his work led to the scaling of the
commodity cluster computing to supercomputing class performance.  He
drove the adoption of cluster computing and GNU/Linux at enterprise data
centers and helped close strategic accounts at CDC.  In 2004, AB led the
development of the world's second fastest Supercomputer "Thunder", for
Lawrence Livermore National Laboratory[4].  AB also serves on the board
of "Free Software Foundation - India[5]".  He is the author /
contributor of various other Free Software projects like GNU FreeIPMI
(Intelligent Platform Management Interface), GNU Garp (Gratuitous ARP
Daemon), bios-config (edit/replicate CMOS parameters), librpci/hdb (RPC
interpose for GNU Hurd) and Hymn/PlayFair (iTunes ripper), GNU Freetalk
(Scheme extensible messenger for Jabber, Google talk), and Freehoo
(Scheme extensible messenger for YahooIM).  He holds a Computer Science
Engineering degree from Annamalai University, Tamil Nadu, India.

1. http://www.gluster.com/products/glusterfs/
2. http://www.gluster.com/
3. http://www.californiadigital.com/
4. http://www.llnl.gov/
5. http://www.gnu.org.in/

See also a bit further below for some additional goodies we'll have at
this meeting (CDs, etc.)

So, if you'd like to join us please RSVP to:

                       rsvp at balug.org

**Why RSVP??**

Well, don't worry we won't turn you away, but the RSVPs really help the
Four Seas Restaurant plan the meal and dining arrangements and such.
We've also tweaked our "door prize" / giveaway practices a bit - so
RSVPing and arriving sufficiently on time increases one's odds of
winning door prize(s) and/or getting first or earlier pick of giveaway
items.

Meeting Details...

                       6:30pm
                       Tuesday, April 19th, 2011 2011-04-19

                       Four Seas Restaurant http://www.fourseasr.com/
                       731 Grant Ave.
                       San Francisco, CA 94108
                       Easy PARKING:
                         Portsmouth Square Garage at 733 Kearny:
                         http://www.sfpsg.com/

Cost: The meetings are always free, but for dinner, for your gift of $13
       cash, we give you a gift of dinner - joining us for a yummy
       family-style Chinese dinner - tax and tip included (your gift
       also helps in our patronizing the restaurant venue and helping
       to defray BALUG costs such treating our speakers to dinner).

Additional goodies we'll have at this meeting (at least the following):

CDs, etc. - have a peek here:
http://www.wiki.balug.org/wiki/doku.php?id=balug:cds_and_images_etc
We do also have some additional give-away items, and may have
"door prizes".

------------------------------

For our Tuesday 6:30 P.M. 2011-05-17 meeting, we're proud to present:

Cloud.com[1]'s Mark Hinkle, VP of Community, on:
Open Source Solutions for Building and Deploying Private and Public
Clouds

As cloud computing has moved beyond hype, becoming a true
enterprise-ready tool that cuts IT costs and fits a variety of use
cases, IT is seeking new ways to efficiently and cost-effectively
build, deploy and manage clouds. Cloud.com's CloudStack Community
Edition, available under the GPLv3 license, is an open sourced
Infrastructure as a Service (IaaS) software platform that simplifies
the creation and management of public and private clouds. This platform
seamlessly integrates with existing data center infrastructure without
the need for modifications, special-purpose hardware or
reconfiguration, making it possible for users to instantly realize the
benefits of the cloud.

CloudStack Community Edition delivers several benefits including:

o Massive computing power - providing virtually unlimited CPUs
   on-demand, as required and billed by actual usage in public, private
   or hybrid deployments.
o Powerful API - Easily build, integrate and use applications based on
   common cloud APIs like Amazon's Web Services API, Citrix Cloud CenterT
   (C3) API and the vCloud API
o Secure Cloud Computing - Isolating compute, network, and storage
   resources by user, location and deployment.
o Comprehensive Service Management - Defining, metering, deploying and
   managing services to be consumed within your cloud.
o Automated resource distribution - delivering capabilities to automate
   the distribution of compute, network and storage while adhering to
   defined policies on load balancing, data security and compliance.
o Real-time visibility and reporting capabilities - ensuring compliance,
   security and comprehensive metering customer usage.
o Simplified management - empowering administrators to offset the daily
   management of services to the end users with a powerful self-service
   portal that gives the day-to-day management tasks to the user,
   enabling administrators to focus on more business critical issues
   while giving the client more control and agility over the service by
   providing a catalog of custom built and pre-defined machine images.

This session will provide best practices for building clouds, and a
technical overview and demonstration of CloudStack.

Mark Hinkle is Cloud.com's Vice President of Community where he is
responsible for driving all of the community efforts around the
Cloud.com's leading open source, cloud computing software and
ecosystem. Before that he was the force behind the Zenoss Core open
source management projects adoption and community involvement, growing
community membership to over 100,000 members.  He is a co-founder of
both the Open Source Management Consortium and the Desktop Linux
Consortium, has served as Editor-in-Chief for both LinuxWorld Magazine
and Enterprise Open Source Magazine, and authored the book, "Windows to
Linux Business Desktop Migration" (Thomson, 2006). Mark has also held
executive positions at a number of technology start-ups, including
Earthlink, (previously MindSpring)--where he was the head of the
technical support organization recognized by PC Computing and PC World
as the best in the industry--Win4Lin and Emu Software.

1. http://www.cloud.com/

------------------------------

"Slides" from the BALUG 2011-03-15 meeting:
Jack Deslippe on Developing for Android
see:
http://lists.balug.org/pipermail/balug-talk-balug.org/2011-March/004733.html

------------------------------

Other Linux & Open Source happenings

Too many to list here :-) - but one might also want to:
peek at BALUG's "talk" list/archives, if one's not subscribed:
http://lists.balug.org/listinfo.cgi/balug-talk-balug.org
check other lists of events/sites, and their respective sites/lists:
http://linuxmafia.com/bale/
https://www.google.com/calendar/embed?src=caj9iea2ol69b7n2uqdek4ocso at group.calendar.google.com

------------------------------

Twitter! - follow BALUG on Twitter: BALUG_org

You can now follow BALUG on Twitter. We're still working out exactly
how we'll use that BALUG_org account on Twitter, but follow us there,
and we'll likely include at least some announcements and updates.
Thoughts/feedback on how we use that Twitter account? - drop us a note
at: publicity-feedback at balug.org

------------------------------

Feedback on our publicity/announcements (e.g. contacts or lists where we
should get our information out that we're not presently reaching, or
things we should do differently): publicity-feedback at balug.org

------------------------------

http://www.balug.org/



From itz at buug.org  Sat Apr  9 11:01:40 2011
From: itz at buug.org (Ian Zimmerman)
Date: Sat, 09 Apr 2011 11:01:40 -0700
Subject: [buug] HOWTO strip SONAME [hardcore dev question]
Message-ID: <8739lr718b.fsf@matica.localdomain>


I'm looking for a way to strip the SONAME field from an ELF shared
object (and only that, not stripping any other information).

I've looked at strip and objcopy options in detail but don't see
anything close.

Thanx for any hints.

-- 
Ian Zimmerman <itz at buug.org>
gpg public key: 1024D/C6FF61AD 
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
Ham is for reading, not for eating.



From Michael.Paoli at cal.berkeley.edu  Sun Apr 10 10:47:44 2011
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Sun, 10 Apr 2011 10:47:44 -0700
Subject: [buug] vim (& [n]vi?) annoyances, etc.
In-Reply-To: <87oc4hfvbp.fsf@matica.localdomain>
References: <20110406195122.22397a9uzy5nnlc8@webmail.rawbw.com>
	<20110407042045.GF24166@ykcyc>
	<20110407012817.67216ci8sfxerl8o@webmail.rawbw.com>
	<87oc4hfvbp.fsf@matica.localdomain>
Message-ID: <20110410104744.16723lhmchoft1s0@webmail.rawbw.com>

[n]vi annoyances?  Far too short to bother to put together a list.  I've
only come up with two:
:[line(s)]w !command
Don't paginate or filter the above, just write it straight - stdout to
stdout, stderr to stderr.  If I wanted to paginate it I'd do something
like:
:[line(s)]w !command | $PAGER
I think the above is the only case I'm aware of that vim (yuck) gets
right, and [n]vi gets wrong.  Ye olde classic vi gets it right - but it
has some serious bugs/limitations, which were fixed in [n]vi.
And: visual mode: tput cvvis.  When going into visual mode, [n]vi should
do the equivalent of tput cvvis, and when leaving it, tput cnorm.  It
doesn't.  Classic vi got that one correct.
That's it :-).  Everything else with [n]vi is perfect ;-).
Hey, keypad and cursor (e.g. arrow) keys?  That's a feature, not a bug.
Don't need no steenkin' non-ASCII keyboard input for a text editor -
that would just cause user to become addicted to some keys that may not
be present on all keyboards - so best not to use them :-).  Really only
need some of those funky keys for, oh, like X (e.g. some kind of Meta
key), some operating systems that use them to switch virtual consoles
(like Linux - and when on the console), or that nice big operating
system called Emacs - but too bad Emacs doesn't supply a good text
editor.

Bugs [n]vi fixes over classic vi:
Not necessarily a comprehensive list, but at least the most obvious I've
noticed:
Classic vi: bugs/limits fixed in [n]vi:
line limit 1,022 characters ("obviously" someone limited their C strings
to 1,024 bytes - line always ending with \n and string terminated by \0,
thus 1022 character line limit).
If the line doesn't fit on the display (e.g. let's say one has a 1,022
character line of \301 A1 - that's control-A + high bit set, in vi that
displays as M-^A - taking up 4 characters on the display, well 4*1022 >
80*24, so something like that won't fit on some displays - with classic
vi, it would (I forget which) either crash and core dump, or drop to ex
mode.
Likewise classic vi would crash on files that were "too big" (for not
very large values of "too big") - I'm sure there are some practical
limits (which may depend on resources), but that's mostly not an issue
for [n]vi.
Classic vi also couldn't handle too long of a command input line (e.g.:
:!...)
Cool minimalistic features [n]vi adds over classic vi:
:se [no]leftright
A sorely needed option missing from classic vi (really needed when one
wants to see things aligned with lines longer than display width -
without such option in classic vi, there are hackish work-arounds using
things like cut(1) paste(1) or the like, vim likewise adds :se
[no]wrap).
[n]vi is really cool when one fires it up and is working in buffer, but
hasn't named a file to work on - it uses and displays the temporary
file name it uses for that, and if one does :w it writes to that file -
one can then, e.g. cat that file, or if one crashes (e.g. someone kills
power to the computer), one has consistent written out copy of file to
recover (vi -r) from from whence one wrote (:w) it out - no ambiguity
as to when [n]vi flushed buffer to disk and point from which one would
be able to recover.  This also avoids the slight annoyance of, if one
has habit of doing :w, otherwise getting an error as there's not a
(named) file to write to ... and the filename is displayed when :w is
issued, so it's also quite clear that it's the temporary file.
There's some other slight additional bits - but none that I
particularly notice.  [n]vi does pretty well document what it
adds/changes relative to classic vi - and it is quite minimal - as it
well should be, because there was little wrong with classic vi.  :-)

Oh, and another vim annoyance! (forgot to note this one earlier):
vim displays many characters - e.g. those with ASCII high bit set - in
ways that, at least by default, often totally mess up the display, and
make it exceedingly difficult to edit, as not only are things not
displayed accurately, but where one's editing in the file, and where
the cursor is displayed are inconsistent, and generally messed up - such
never was an issue with classic vi, and isn't an issue with [n]vi , so
again, another vim annoyance.

> From: "Ian Zimmerman" <itz at buug.org>
> Subject: Re: [buug] vim (& "certain" Linux distributions) annoyances
> Date: Thu, 07 Apr 2011 17:19:54 -0700

> Michael> Oh yeah, ... and some other serious vim annoyances ... but I'll
> Michael> add 'em to my list and save 'em for another time ;-).
>
> Someone should post a similar list for nvi, LOL.  I am not volunteering,
> but the way it handles keypad and cursor keys (ie. it doesn't) would be
> a start.

Remember back in college or so - when instructor would allow notes for
a test - all the notes one could fit on both sides of a standard 3x5"
card?  And of course many folks wrote very small.  I could fit all my
[n]vi annoyances on the back of a single standard sized postage stamp.
For vim, both sides of a 3x5" card may not suffice (but a 5x8" card
probably would).



From Michael.Paoli at cal.berkeley.edu  Sun Apr 10 10:49:57 2011
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Sun, 10 Apr 2011 10:49:57 -0700
Subject: [buug] Backups :-) (& CD-R[W], etc.)
Message-ID: <20110410104957.9943435mnk89yvms@webmail.rawbw.com>

At last Thursday's BUUG meeting, there was a fair discussion of backups,
among at least some of us.  A few things mentioned/discussed (now adding
the references):
backups and backups to CD-R[W] - here's something I wrote several years
ago and used to use very regularly for backing up my personal laptop to
CD-R[W]:
http://www.rawbw.com/~mp/perl/#backup
Wish list for backup software :-) - a while back, I wrote up
more-or-less a "wish list" of everything I'd like to see in some backup
software package or cohesive collection:
http://linuxmafia.com/pipermail/sf-lug/2010q2/007670.html

I did also attend the Bup presentation yesterday:
http://www.weak.org/pipermail/buug/2011-April/003749.html
... from that I might be inclined to add a wee bit more to my
"wish list" of features/capabilities for backup software :-)



From Michael.Paoli at cal.berkeley.edu  Sun Apr 10 10:51:45 2011
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Sun, 10 Apr 2011 10:51:45 -0700
Subject: [buug] BUUG meetings :-) - 11 folks at last Thursday's BUUG meeting
Message-ID: <20110410105145.36686w7xycm5y5oo@webmail.rawbw.com>

And for those that may be interested to try, and/or haven't tried a
BUUG meeting in quite a while, last BUUG meeting was generally quite
good and interesting, and also well attended - total of 11 people.  I
think that's near the largest BUUG meeting since at least sometime in
2003, when I first started going to BUUG.  Our "average" meetings in
the last year or so, are, I think typically around 6 to 8 attendees, +-
a bit, and I think that's up a fair bit from a year or two or so ago,
when I think 4 to 6 +- was a more typical "average".  Largest meeting I
ever recall us having was some fair number of years ago (200[3-5] or
so?) - I think we had 12 total ... as I seem to recall, were about 8 of
us, then a bunch of about 4 UC Berkeley students came as a bunch and
joined us.



From itz at buug.org  Sun Apr 10 12:16:44 2011
From: itz at buug.org (Ian Zimmerman)
Date: Sun, 10 Apr 2011 12:16:44 -0700
Subject: [buug] vim (& [n]vi?) annoyances, etc.
In-Reply-To: <20110410104744.16723lhmchoft1s0@webmail.rawbw.com> (Michael
	Paoli's message of "Sun, 10 Apr 2011 10:47:44 -0700")
References: <20110406195122.22397a9uzy5nnlc8@webmail.rawbw.com>
	<20110407042045.GF24166@ykcyc>
	<20110407012817.67216ci8sfxerl8o@webmail.rawbw.com>
	<87oc4hfvbp.fsf@matica.localdomain>
	<20110410104744.16723lhmchoft1s0@webmail.rawbw.com>
Message-ID: <874o65c3xf.fsf@matica.localdomain>


Michael> Hey, keypad and cursor (e.g. arrow) keys?  That's a feature,
Michael> not a bug.  Don't need no steenkin' non-ASCII keyboard input
Michael> for a text editor - that would just cause user to become
Michael> addicted to some keys that may not be present on all keyboards
Michael> - so best not to use them :-).  Really only need some of those
Michael> funky keys for, oh, like X (e.g. some kind of Meta key), some
Michael> operating systems that use them to switch virtual consoles
Michael> (like Linux - and when on the console), or that nice big
Michael> operating system called Emacs - but too bad Emacs doesn't
Michael> supply a good text editor.

Well, I'm not going to argue with the philosophy, but why oh why can't
vi just _do nothing_ when you hit one of those keys (as anyone who ever
uses another program will), instead of horribly and irreversibly messing
up your screen?  Every time this happens to me I have to do :q! and
start from scratch.  After cursing (NPI) profusely, of course.

-- 
Ian Zimmerman <itz at buug.org>
gpg public key: 1024D/C6FF61AD 
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
Ham is for reading, not for eating.



From itz at buug.org  Sun Apr 10 12:19:42 2011
From: itz at buug.org (Ian Zimmerman)
Date: Sun, 10 Apr 2011 12:19:42 -0700
Subject: [buug] Backups :-) (& CD-R[W], etc.)
In-Reply-To: <20110410104957.9943435mnk89yvms@webmail.rawbw.com> (Michael
	Paoli's message of "Sun, 10 Apr 2011 10:49:57 -0700")
References: <20110410104957.9943435mnk89yvms@webmail.rawbw.com>
Message-ID: <87zknxap81.fsf@matica.localdomain>


Michael> I did also attend the Bup presentation yesterday:
Michael> http://www.weak.org/pipermail/buug/2011-April/003749.html
Michael> ... from that I might be inclined to add a wee bit more to my
Michael> "wish list" of features/capabilities for backup software :-)

But it doesn't seem to do encryption yet.

-- 
Ian Zimmerman <itz at buug.org>
gpg public key: 1024D/C6FF61AD 
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
Ham is for reading, not for eating.



From togo at of.net  Sun Apr 10 18:16:05 2011
From: togo at of.net (Tony Godshall)
Date: Sun, 10 Apr 2011 18:16:05 -0700
Subject: [buug] Backups :-) (& CD-R[W], etc.)
In-Reply-To: <87zknxap81.fsf@matica.localdomain>
References: <20110410104957.9943435mnk89yvms@webmail.rawbw.com>
	<87zknxap81.fsf@matica.localdomain>
Message-ID: <BANLkTi=aQyOBToBzxdSdV677j8ROBeepLA@mail.gmail.com>

On Sun, Apr 10, 2011 at 12:19, Ian Zimmerman <itz at buug.org> wrote:
>
> Michael> I did also attend the Bup presentation yesterday:
> Michael> http://www.weak.org/pipermail/buug/2011-April/003749.html
> Michael> ... from that I might be inclined to add a wee bit more to my
> Michael> "wish list" of features/capabilities for backup software :-)
>
> But it doesn't seem to do encryption yet.

Well, you can certainly backup over SSH to an encrypted remote drive.

Tony


From Michael.Paoli at cal.berkeley.edu  Sun Apr 10 20:46:56 2011
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Sun, 10 Apr 2011 20:46:56 -0700
Subject: [buug] Backups :-) (& CD-R[W], etc.)
In-Reply-To: <BANLkTi=aQyOBToBzxdSdV677j8ROBeepLA@mail.gmail.com>
References: <20110410104957.9943435mnk89yvms@webmail.rawbw.com>
	<87zknxap81.fsf@matica.localdomain>
	<BANLkTi=aQyOBToBzxdSdV677j8ROBeepLA@mail.gmail.com>
Message-ID: <20110410204656.122461p5w3j6108w@webmail.rawbw.com>

Yes, rather what I was going to say.  It doesn't "do" encryption, but
it plays nice with it.  On the transport side, Bup works very nicely
with ssh(1), and on the storage side, nothing prevents one from using
some type of encrypted storage (e.g. encrypted filesystem).
If one doesn't trust the backup storage side "that much" with one's
data, the encryption layer can be at or closer to the client side, so
the backup storage side can just be storage, and the filesystem and
encryption layer(s) at or much closer to the backup client side, so
backup server/storage never need store (or have access to) clear-text
backup data.

As for my backup program
http://www.rawbw.com/~mp/perl/#backup
I mentioned in:
http://www.weak.org/pipermail/buug/2011-April/003759.html
it doesn't "do" encryption, but again, it plays nice with it.  I've
used part/much of those programs to do backup remotely (over ssh), and
- not sure if I did it with those programs or not, but also nicely
added encryption to storage of backups - and easily can with those
scripts/programs, if I didn't already.  In that particular set of
programs, doing the backup - part of the architecture generates a list
of filesystems, along with some metadata about them (e.g. filesystem
type).  Another part takes that data, and from it produces a stream of
backup data - one can easily insert encryption there (I'm pretty sure I
did so with later version of, or based upon that software), that
"older" version, from there, just takes that stream of data and handles
backing it up to the backup media - to the program, it's just a stream
of bytes, it doesn't particularly care what's in it. It just knows that
stream of bytes correlates to a particular filesystem, and when the
stream ends and it's written that data, it then adds that
meta-information to its index of which filesystems start at what offset
on what media - and writes the index out at the very end, and to the
media at the end.  Not a very detailed index, but covers to filesystem
level anyway (other data or indexes that can be added as part of the
backup may cover more detail, and in some cases, actually do - e.g.
first thing that gets backed up with that collection is a fair chunk of
metadata - if I recall correctly, including a list of all the files
targeted for backup, among other things (like filesystem types and
sizes, and partitioning and logical volume configuration information).

So ... "plays nice with" (e.g. encryption) is often as or more
important than "includes".

For quite a while now, I've been encrypting my offsite backups - at
least most or all of that data, anyway.

> From: "Tony Godshall" <togo at of.net>
> Subject: Re: [buug] Backups :-) (& CD-R[W], etc.)
> Date: Sun, 10 Apr 2011 18:16:05 -0700

> On Sun, Apr 10, 2011 at 12:19, Ian Zimmerman <itz at buug.org> wrote:
>>
>> Michael> I did also attend the Bup presentation yesterday:
>> Michael> http://www.weak.org/pipermail/buug/2011-April/003749.html
>> Michael> ... from that I might be inclined to add a wee bit more to my
>> Michael> "wish list" of features/capabilities for backup software :-)
>>
>> But it doesn't seem to do encryption yet.
>
> Well, you can certainly backup over SSH to an encrypted remote drive.



From togo at of.net  Sun Apr 10 22:03:01 2011
From: togo at of.net (Tony Godshall)
Date: Sun, 10 Apr 2011 22:03:01 -0700
Subject: [buug] Backups :-) (& CD-R[W], etc.)
In-Reply-To: <20110410204656.122461p5w3j6108w@webmail.rawbw.com>
References: <20110410104957.9943435mnk89yvms@webmail.rawbw.com>
	<87zknxap81.fsf@matica.localdomain>
	<BANLkTi=aQyOBToBzxdSdV677j8ROBeepLA@mail.gmail.com>
	<20110410204656.122461p5w3j6108w@webmail.rawbw.com>
Message-ID: <BANLkTikohpSNUFGT6dqWhwu7aQ5fjB1WYA@mail.gmail.com>

Indeed, very much the tools-you-can-string-together approach of Unix
rather than the tool-that-must-do-everyting approach of VMS or Emacs.

Michael, how would plumb near encryption for an untrusted far store-
some kind of block-device-over-ssh-tunnel scheme?

Best Regards.



On Sun, Apr 10, 2011 at 20:46, Michael Paoli
<Michael.Paoli at cal.berkeley.edu> wrote:
> Yes, rather what I was going to say. ?It doesn't "do" encryption, but
> it plays nice with it. ?On the transport side, Bup works very nicely
> with ssh(1), and on the storage side, nothing prevents one from using
> some type of encrypted storage (e.g. encrypted filesystem).
> If one doesn't trust the backup storage side "that much" with one's
> data, the encryption layer can be at or closer to the client side, so
> the backup storage side can just be storage, and the filesystem and
> encryption layer(s) at or much closer to the backup client side, so
> backup server/storage never need store (or have access to) clear-text
> backup data.
>
> As for my backup program
> http://www.rawbw.com/~mp/perl/#backup
> I mentioned in:
> http://www.weak.org/pipermail/buug/2011-April/003759.html
> it doesn't "do" encryption, but again, it plays nice with it. ?I've
> used part/much of those programs to do backup remotely (over ssh), and
> - not sure if I did it with those programs or not, but also nicely
> added encryption to storage of backups - and easily can with those
> scripts/programs, if I didn't already. ?In that particular set of
> programs, doing the backup - part of the architecture generates a list
> of filesystems, along with some metadata about them (e.g. filesystem
> type). ?Another part takes that data, and from it produces a stream of
> backup data - one can easily insert encryption there (I'm pretty sure I
> did so with later version of, or based upon that software), that
> "older" version, from there, just takes that stream of data and handles
> backing it up to the backup media - to the program, it's just a stream
> of bytes, it doesn't particularly care what's in it. It just knows that
> stream of bytes correlates to a particular filesystem, and when the
> stream ends and it's written that data, it then adds that
> meta-information to its index of which filesystems start at what offset
> on what media - and writes the index out at the very end, and to the
> media at the end. ?Not a very detailed index, but covers to filesystem
> level anyway (other data or indexes that can be added as part of the
> backup may cover more detail, and in some cases, actually do - e.g.
> first thing that gets backed up with that collection is a fair chunk of
> metadata - if I recall correctly, including a list of all the files
> targeted for backup, among other things (like filesystem types and
> sizes, and partitioning and logical volume configuration information).
>
> So ... "plays nice with" (e.g. encryption) is often as or more
> important than "includes".
>
> For quite a while now, I've been encrypting my offsite backups - at
> least most or all of that data, anyway.
>
>> From: "Tony Godshall" <togo at of.net>
>> Subject: Re: [buug] Backups :-) (& CD-R[W], etc.)
>> Date: Sun, 10 Apr 2011 18:16:05 -0700
>
>> On Sun, Apr 10, 2011 at 12:19, Ian Zimmerman <itz at buug.org> wrote:
>>>
>>> Michael> I did also attend the Bup presentation yesterday:
>>> Michael> http://www.weak.org/pipermail/buug/2011-April/003749.html
>>> Michael> ... from that I might be inclined to add a wee bit more to my
>>> Michael> "wish list" of features/capabilities for backup software :-)
>>>
>>> But it doesn't seem to do encryption yet.
>>
>> Well, you can certainly backup over SSH to an encrypted remote drive.
>
>


From itz at buug.org  Sun Apr 10 23:15:15 2011
From: itz at buug.org (Ian Zimmerman)
Date: Sun, 10 Apr 2011 23:15:15 -0700
Subject: [buug] Backups :-) (& CD-R[W], etc.)
In-Reply-To: <BANLkTikohpSNUFGT6dqWhwu7aQ5fjB1WYA@mail.gmail.com> (Tony
	Godshall's message of "Sun, 10 Apr 2011 22:03:01 -0700")
References: <20110410104957.9943435mnk89yvms@webmail.rawbw.com>
	<87zknxap81.fsf@matica.localdomain>
	<BANLkTi=aQyOBToBzxdSdV677j8ROBeepLA@mail.gmail.com>
	<20110410204656.122461p5w3j6108w@webmail.rawbw.com>
	<BANLkTikohpSNUFGT6dqWhwu7aQ5fjB1WYA@mail.gmail.com>
Message-ID: <87r599mhzg.fsf@matica.localdomain>


Tony> Indeed, very much the tools-you-can-string-together approach of
Tony> Unix rather than the tool-that-must-do-everyting approach of VMS
Tony> or Emacs.

Leave Emacs out of this :-)  It is in fact very good at leveraging
existing tools.  That's why it is an OS, LOL.

I can see your point about encryption but unfortunately encryption
on the filesystem level is a chore compared to, say, GPG.  Mostly
because of agent type features.

-- 
Ian Zimmerman <itz at buug.org>
gpg public key: 1024D/C6FF61AD 
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
Ham is for reading, not for eating.



From khogoboom at gmail.com  Fri Apr 15 19:09:31 2011
From: khogoboom at gmail.com (Karen Hogoboom)
Date: Fri, 15 Apr 2011 19:09:31 -0700
Subject: [buug] Shell book
In-Reply-To: <871v1890lc.fsf@matica.localdomain>
References: <871v1890lc.fsf@matica.localdomain>
Message-ID: <BANLkTi=LMa_3mD+BtAu2-h9Q8vXK4gj_pg@mail.gmail.com>

Thanks Ian.  I would be interested in taking a look at it.  I'm planning to
be at the next meeting.

Karen

On Mon, Apr 11, 2011 at 10:09 AM, Ian Zimmerman <itz at buug.org> wrote:

>
> Hi, this is the book I mentioned at the last meeting.  It is a bit
> similar to the Kernighan & Pike but much updated and extended.
> Again, I can loan it to you if you're interested.
>
> http://oreilly.com/catalog/9780596005955/
>
> --
> Ian Zimmerman <itz at buug.org>
> gpg public key: 1024D/C6FF61AD
> fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
> Ham is for reading, not for eating.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buug.org/pipermail/buug/attachments/20110415/27e82d02/attachment.html>

From Michael.Paoli at cal.berkeley.edu  Sat Apr 16 09:42:20 2011
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Sat, 16 Apr 2011 09:42:20 -0700
Subject: [buug] learning shell (Shell book), etc.
In-Reply-To: <BANLkTi=LMa_3mD+BtAu2-h9Q8vXK4gj_pg@mail.gmail.com>
References: <871v1890lc.fsf@matica.localdomain>
	<BANLkTi=LMa_3mD+BtAu2-h9Q8vXK4gj_pg@mail.gmail.com>
Message-ID: <20110416094220.360769l4tgmnkuo8@webmail.rawbw.com>

Oh, there are definitely books on the topic, ... many, ... even
rather/quite good ones.

The reason I often/typically start folks with Bourne sh(1) from UNIX
Seventh Edition (quoting myself[1]):
o most of what one needs to use for scripting/programming purposes
   exists in ye olde (UNIX Seventh Edition) Bourne Shell, and still
   functions essentially the same way
o Very concise reference: UNIX Seventh Edition sh(1) only 6 pages!

If one wants more concise materials on shell than an entire book, one
might also consider books on Unix, Linux or BSD or systems
administration of same.  Such books will often have a chapter on the
shell and shell programming.

footnotes/references/excerpts:
1. http://www.rawbw.com/~mp/unix/sh/#Why_start_here

> From: "Karen Hogoboom" <khogoboom at gmail.com>
> Subject: Re: [buug] Shell book
> Date: Fri, 15 Apr 2011 19:09:31 -0700

> Thanks Ian.  I would be interested in taking a look at it.  I'm planning to
> be at the next meeting.
>
> On Mon, Apr 11, 2011 at 10:09 AM, Ian Zimmerman <itz at buug.org> wrote:
>
>> Hi, this is the book I mentioned at the last meeting.  It is a bit
>> similar to the Kernighan & Pike but much updated and extended.
>> Again, I can loan it to you if you're interested.
>>
>> http://oreilly.com/catalog/9780596005955/



From rick at linuxmafia.com  Tue Apr 19 13:15:46 2011
From: rick at linuxmafia.com (Rick Moen)
Date: Tue, 19 Apr 2011 13:15:46 -0700
Subject: [buug] (forw) List owner needed for
	callug_discuss@lists.berkeley.edu
Message-ID: <20110419201546.GF26669@linuxmafia.com>

Any current UCB student or faculty or staff member interested in keeping
alive the last remnant of CalLUG?  (I can help advise any such person
about mailing list manager duties, which are extremely minimal.)

It would be nice if CalLUG could be revived, but first things first.


----- Forwarded message from Consult <consult at berkeley.edu> -----

Date: Tue, 19 Apr 2011 17:19:09 -0000
From: Consult <consult at berkeley.edu>
To: callug_discuss at lists.berkeley.edu
Subject: List owner needed for callug_discuss at lists.berkeley.edu

We are sending you this message because your email account is currently
subscribed to callug_discuss at lists.berkeley.edu.  Please disregard this message if you are not
a current member of the University of California, Berkeley.

It has come to our attention that the callug_discuss at lists.berkeley.edu mailing
list no longer has a current owner. If anyone on the list with a valid
affiliation with the campus would like to take over as owner, please
write to consult at berkeley.edu

If we do not hear from anyone within one month, the list will be deleted.

Thank you.

-CalMail Staff



----- End forwarded message -----


From rick at linuxmafia.com  Tue Apr 19 13:16:20 2011
From: rick at linuxmafia.com (Rick Moen)
Date: Tue, 19 Apr 2011 13:16:20 -0700
Subject: [buug] (forw) List owner needed for
	callug_announce@lists.berkeley.edu
Message-ID: <20110419201620.GG26669@linuxmafia.com>

Same concern applies.

----- Forwarded message from Consult <consult at berkeley.edu> -----

Date: Tue, 19 Apr 2011 17:18:46 -0000
From: Consult <consult at berkeley.edu>
To: callug_announce at lists.berkeley.edu
Subject: List owner needed for callug_announce at lists.berkeley.edu

We are sending you this message because your email account is currently
subscribed to callug_announce at lists.berkeley.edu.  Please disregard this message if you are not
a current member of the University of California, Berkeley.

It has come to our attention that the callug_announce at lists.berkeley.edu mailing
list no longer has a current owner. If anyone on the list with a valid
affiliation with the campus would like to take over as owner, please
write to consult at berkeley.edu

If we do not hear from anyone within one month, the list will be deleted.

Thank you.

-CalMail Staff



----- End forwarded message -----


From pi at berkeley.edu  Tue Apr 19 13:28:24 2011
From: pi at berkeley.edu (Paul Ivanov)
Date: Tue, 19 Apr 2011 13:28:24 -0700
Subject: [buug] (forw) List owner needed for
 callug_discuss@lists.berkeley.edu
In-Reply-To: <20110419201546.GF26669@linuxmafia.com>
References: <20110419201546.GF26669@linuxmafia.com>
Message-ID: <20110419202824.GA23917@ykcyc>

Hi Rick,

Rick Moen, on 2011-04-19 13:15,  wrote:
> Any current UCB student or faculty or staff member interested in keeping
> alive the last remnant of CalLUG?  (I can help advise any such person
> about mailing list manager duties, which are extremely minimal.)

I'm game. Should I contact CalMail directly, or go through you?

ditto for the -announce list.
 
> It would be nice if CalLUG could be revived, but first things first.

I'd be up for this, as well.

best,
-- 
Paul Ivanov
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://buug.org/pipermail/buug/attachments/20110419/c86df627/attachment.sig>

From rick at linuxmafia.com  Tue Apr 19 14:00:59 2011
From: rick at linuxmafia.com (Rick Moen)
Date: Tue, 19 Apr 2011 14:00:59 -0700
Subject: [buug] (forw) List owner needed for
 callug_discuss@lists.berkeley.edu
In-Reply-To: <20110419202824.GA23917@ykcyc>
References: <20110419201546.GF26669@linuxmafia.com>
	<20110419202824.GA23917@ykcyc>
Message-ID: <20110419210059.GI26669@linuxmafia.com>

Quoting Paul Ivanov (pi at berkeley.edu):

> I'm game. Should I contact CalMail directly, or go through you?
> 
> ditto for the -announce list.
>  
> > It would be nice if CalLUG could be revived, but first things first.
> 
> I'd be up for this, as well.

Good to hear.  To clarify, I'm just a subscriber and former attendee of
CalLUG's on-campus meetings.  (Gosh, it's been a while:  Their brief
revival ended in 2007.)

I gather from the announcement that you would write to CalMail Staff
<consult at berkeley.edu>, to step up and take over as listadmin.


We can and should talk about what's required to revive CalLUG.  I
watched the LUG die, get revived, and die a second time, so I think I
know the major pitfalls and can help you avoid them.  I've been thinking
of adding a section to the Linux User Group HOWTO[1] about the
particular problems of college LUGs.  Here's the short version:

1.  Maintaining accreditation.  In CalLUG's case, that would be through 
ASUC.  Accredited groups get access to Internet server resources, 
publicity, use of rooms, right to post flyers, sometimes modest funding, 
etc.  But you have to file timely paperwork.  Failure to do those
filings killed CCSF LUG.

2.  Continuity, especially over the summer break.  By that, I mean two
things:  CalLUG kept having a syndrome where the officers would get too
busy in May/June preparing for finals, nobody would have time to make
arrangements to ensure out-of-band means of communication in case the
CalLUG server went down, and nobody would have time to ensure
replacements for officers being graduated.  Some combination of those
two problems seems to have killed CalLUG, both times.

[1] http://tldp.org/HOWTO/User-Group-HOWTO.html
Also by the same author:  http://linuxmafia.com/faq/Linux_PR/newlug.html




From grantbow at ubuntu.com  Tue Apr 19 15:13:18 2011
From: grantbow at ubuntu.com (Grant Bowman)
Date: Tue, 19 Apr 2011 15:13:18 -0700
Subject: [buug] (forw) List owner needed for
	callug_discuss@lists.berkeley.edu
In-Reply-To: <20110419210059.GI26669@linuxmafia.com>
References: <20110419201546.GF26669@linuxmafia.com>
	<20110419202824.GA23917@ykcyc>
	<20110419210059.GI26669@linuxmafia.com>
Message-ID: <BANLkTimBbk-6hTQWjJf1JCKiEx1-bibRMg@mail.gmail.com>

Rick, thank you for bringing this to the BUUG list. If there are
annual things that a campus group must do, perhaps a checklist would
help busy students maintain continuity during the frequent group
transitions.

Paul, I'm sure some people from the buug.org, berkeleylug.com and/or
ubuntu-california.org groups would be interested in helping out. Let
us know what we can do and when you are planning meetings and events.

Cheers,

Grant Bowman


On Tue, Apr 19, 2011 at 2:00 PM, Rick Moen <rick at linuxmafia.com> wrote:
> Quoting Paul Ivanov (pi at berkeley.edu):
>
>> I'm game. Should I contact CalMail directly, or go through you?
>>
>> ditto for the -announce list.
>>
>> > It would be nice if CalLUG could be revived, but first things first.
>>
>> I'd be up for this, as well.
>
> Good to hear. ?To clarify, I'm just a subscriber and former attendee of
> CalLUG's on-campus meetings. ?(Gosh, it's been a while: ?Their brief
> revival ended in 2007.)
>
> I gather from the announcement that you would write to CalMail Staff
> <consult at berkeley.edu>, to step up and take over as listadmin.
>
>
> We can and should talk about what's required to revive CalLUG. ?I
> watched the LUG die, get revived, and die a second time, so I think I
> know the major pitfalls and can help you avoid them. ?I've been thinking
> of adding a section to the Linux User Group HOWTO[1] about the
> particular problems of college LUGs. ?Here's the short version:
>
> 1. ?Maintaining accreditation. ?In CalLUG's case, that would be through
> ASUC. ?Accredited groups get access to Internet server resources,
> publicity, use of rooms, right to post flyers, sometimes modest funding,
> etc. ?But you have to file timely paperwork. ?Failure to do those
> filings killed CCSF LUG.
>
> 2. ?Continuity, especially over the summer break. ?By that, I mean two
> things: ?CalLUG kept having a syndrome where the officers would get too
> busy in May/June preparing for finals, nobody would have time to make
> arrangements to ensure out-of-band means of communication in case the
> CalLUG server went down, and nobody would have time to ensure
> replacements for officers being graduated. ?Some combination of those
> two problems seems to have killed CalLUG, both times.
>
> [1] http://tldp.org/HOWTO/User-Group-HOWTO.html
> Also by the same author: ?http://linuxmafia.com/faq/Linux_PR/newlug.html
>
>
> _______________________________________________
> Buug mailing list
> Buug at weak.org
> http://www.weak.org/mailman/listinfo/buug
>


From pi at berkeley.edu  Tue Apr 19 15:13:36 2011
From: pi at berkeley.edu (Paul Ivanov)
Date: Tue, 19 Apr 2011 15:13:36 -0700
Subject: [buug] Reviving CalLUG
In-Reply-To: <20110419210059.GI26669@linuxmafia.com>
References: <20110419201546.GF26669@linuxmafia.com>
	<20110419202824.GA23917@ykcyc>
	<20110419210059.GI26669@linuxmafia.com>
Message-ID: <20110419221336.GE23917@ykcyc>

Rick Moen, on 2011-04-19 14:00,  wrote:
> I gather from the announcement that you would write to CalMail Staff
> <consult at berkeley.edu>, to step up and take over as listadmin.

done.
 
> We can and should talk about what's required to revive CalLUG.  I
> watched the LUG die, get revived, and die a second time, so I think I
> know the major pitfalls and can help you avoid them.  I've been thinking
> of adding a section to the Linux User Group HOWTO[1] about the
> particular problems of college LUGs.  Here's the short version:
> 
> 1.  Maintaining accreditation.  In CalLUG's case, that would be through 
> ASUC.  Accredited groups get access to Internet server resources, 
> publicity, use of rooms, right to post flyers, sometimes modest funding, 
> etc.  But you have to file timely paperwork.  Failure to do those
> filings killed CCSF LUG.

I'm familiar with these procedures, having helped run student
clubs at UC Berkeley in the past. There's a threshold of
needing four people to be Student Signatories, which are
currently enrolled students who take and pass an online
orientation quiz about rules and policies related to running a
club on campus.

Also, looking at the website for starting a club - it looks like it
may have to be renamed, due to an apparently *ridiculous* policy:

------
    Organization names must be in compliance with the Berkeley Campus
    Regulations and the Office of Marketing and Business Outreach
    policies.
    
    The following names and corresponding variations may not be used
    in your student group name:
    
        * UC Berkeley
        * California
        * Cal
        * UC
        * UCB
    
    ?Berkeley? can be used in your student group name only if it is
    used as a reference to geographic location, such as:
    
        * at Berkeley
        * of Berkeley
------

Though they do mention that groups which started before this
policy was in place are allowed to keep their name.  Any students
out there can click on "Become A Signatory" here:
http://campuslife.berkeley.edu/orgs/manage

select these two groups:
* Cal Linux User Group 
    - The name of the group has not yet been approved.
    - The constitution for the group has not yet been approved. 
* GNU/Linux User Group at Cal 
    - The constitution for the group has not yet been approved.

Seems like the second name, since it's been approved, might be
the path of least resistance.

I haven't been to one of their Sunday meetings, but I think there are
some UCB students active on the BerkeleyLUG, so maybe I'll shoot
an email that way (unless they're also on this list, please do
chime in).

The hosting resources available to official student organizations
(clubs) is itself provided by a student org: the Open Computing
Facillity (OCF). There's a good chance that some OCF members
would also be interested in reviving CalLUG. Same goes for the
Computer Science undergraduate and graduate associations.
 
> 2.  Continuity, especially over the summer break.  By that, I mean two
> things:  CalLUG kept having a syndrome where the officers would get too
> busy in May/June preparing for finals, nobody would have time to make
> arrangements to ensure out-of-band means of communication in case the
> CalLUG server went down, and nobody would have time to ensure
> replacements for officers being graduated.  Some combination of those
> two problems seems to have killed CalLUG, both times.

As a grad student, I'm still around during the summers, so that
should help. But also, as a grad student, I hope to not stay here
indefinitely, and would only want to invest time in a club that
remains active beyond my time here, so year-to-year continuity
would be a particularly important for me.

best,
-- 
Paul Ivanov
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://buug.org/pipermail/buug/attachments/20110419/13b86b57/attachment.sig>

From jim at well.com  Tue Apr 19 16:07:02 2011
From: jim at well.com (jim)
Date: Tue, 19 Apr 2011 16:07:02 -0700
Subject: [buug] (forw) List owner needed for
 callug_discuss@lists.berkeley.edu
In-Reply-To: <BANLkTimBbk-6hTQWjJf1JCKiEx1-bibRMg@mail.gmail.com>
References: <20110419201546.GF26669@linuxmafia.com>
	<20110419202824.GA23917@ykcyc> <20110419210059.GI26669@linuxmafia.com>
	<BANLkTimBbk-6hTQWjJf1JCKiEx1-bibRMg@mail.gmail.com>
Message-ID: <1303254422.2023.0.camel@jim-LAPTOP>



    larry cafiero might be interested in knowing about 
this, given his flirting involvement in college-based 
lugs. 


On Tue, 2011-04-19 at 15:13 -0700, Grant Bowman wrote:
> Rick, thank you for bringing this to the BUUG list. If there are
> annual things that a campus group must do, perhaps a checklist would
> help busy students maintain continuity during the frequent group
> transitions.
> 
> Paul, I'm sure some people from the buug.org, berkeleylug.com and/or
> ubuntu-california.org groups would be interested in helping out. Let
> us know what we can do and when you are planning meetings and events.
> 
> Cheers,
> 
> Grant Bowman
> 
> 
> On Tue, Apr 19, 2011 at 2:00 PM, Rick Moen <rick at linuxmafia.com> wrote:
> > Quoting Paul Ivanov (pi at berkeley.edu):
> >
> >> I'm game. Should I contact CalMail directly, or go through you?
> >>
> >> ditto for the -announce list.
> >>
> >> > It would be nice if CalLUG could be revived, but first things first.
> >>
> >> I'd be up for this, as well.
> >
> > Good to hear.  To clarify, I'm just a subscriber and former attendee of
> > CalLUG's on-campus meetings.  (Gosh, it's been a while:  Their brief
> > revival ended in 2007.)
> >
> > I gather from the announcement that you would write to CalMail Staff
> > <consult at berkeley.edu>, to step up and take over as listadmin.
> >
> >
> > We can and should talk about what's required to revive CalLUG.  I
> > watched the LUG die, get revived, and die a second time, so I think I
> > know the major pitfalls and can help you avoid them.  I've been thinking
> > of adding a section to the Linux User Group HOWTO[1] about the
> > particular problems of college LUGs.  Here's the short version:
> >
> > 1.  Maintaining accreditation.  In CalLUG's case, that would be through
> > ASUC.  Accredited groups get access to Internet server resources,
> > publicity, use of rooms, right to post flyers, sometimes modest funding,
> > etc.  But you have to file timely paperwork.  Failure to do those
> > filings killed CCSF LUG.
> >
> > 2.  Continuity, especially over the summer break.  By that, I mean two
> > things:  CalLUG kept having a syndrome where the officers would get too
> > busy in May/June preparing for finals, nobody would have time to make
> > arrangements to ensure out-of-band means of communication in case the
> > CalLUG server went down, and nobody would have time to ensure
> > replacements for officers being graduated.  Some combination of those
> > two problems seems to have killed CalLUG, both times.
> >
> > [1] http://tldp.org/HOWTO/User-Group-HOWTO.html
> > Also by the same author:  http://linuxmafia.com/faq/Linux_PR/newlug.html
> >
> >
> > _______________________________________________
> > Buug mailing list
> > Buug at weak.org
> > http://www.weak.org/mailman/listinfo/buug
> >
> _______________________________________________
> Buug mailing list
> Buug at weak.org
> http://www.weak.org/mailman/listinfo/buug
> 




From grantbow at ubuntu.com  Tue Apr 19 17:09:15 2011
From: grantbow at ubuntu.com (Grant Bowman)
Date: Tue, 19 Apr 2011 17:09:15 -0700
Subject: [buug] (forw) List owner needed for
	callug_discuss@lists.berkeley.edu
In-Reply-To: <1303254422.2023.0.camel@jim-LAPTOP>
References: <20110419201546.GF26669@linuxmafia.com>
	<20110419202824.GA23917@ykcyc>
	<20110419210059.GI26669@linuxmafia.com>
	<BANLkTimBbk-6hTQWjJf1JCKiEx1-bibRMg@mail.gmail.com>
	<1303254422.2023.0.camel@jim-LAPTOP>
Message-ID: <BANLkTik_DNB7s8Udsiv-Xi9i+TfSz=qvog@mail.gmail.com>

Hi Jim, good point. I don't know if Larry has subscribed to the
BUUG.org mail list or how much time he has to contribute. Perhaps I
should have mentioned fedoraproject.org [1] and olpcsf.org in my
previous email. [2] There are many resources, people and groups that
might play a role but we have to start somewhere. While other groups
may be able to provide resources to help, unfortunately the Felton LUG
http://feltonlug.sturdywebs.com and http://olpcsf.org are further away
and I suspect have a statistically lower chance [3] of finding people
who are most likely willing and able to help a Berkeley user group on
a regular basis.

I suspect the interests of the Cal group's regulars will dictate the
direction it takes. Of course all the resources that can help
reestablish itself should be brought to (the golden) bear, the
traditional locus of activity of BSD [4] and birth place of many open
source projects including (but not limited to) CentOS, GIMP and
others.

Regards,

Grant


[1] Larry and I have had discussions about this. I think we agree that
Ubuntu with it's community groups, state by state local community
structure, focus on the desktop experience and existing user
population (especially in Berkeley from what I can tell) act as
"training wheels" into the Linux world for newcomers to begin using
Linux. No other distribution has been as successful reaching out to
"simple end users" as the Ubuntu community project. As a Fedora
Ambassador I try to talk about Fedora with people who might be ready,
willing and able to try Fedora however I have learned a few things. In
my experience the number of people with that level of interest is
relatively small and quite often those people already know about
Fedora and/or many other distributions, some of which I have had
exposure to myself.

[2] The OLPC project has put over two million Fedora laptops in kids
hands all over the world and the SF conference in October had people
attend from all over the world.

[3] I also factored in my knowledge of the active members of the
original groups I mentioned.

[4] http://en.wikipedia.org/wiki/Berkeley_Software_Distribution


On Tue, Apr 19, 2011 at 4:07 PM, jim <jim at well.com> wrote:
> ? ?larry cafiero might be interested in knowing about
> this, given his flirting involvement in college-based
> lugs.
>
>
> On Tue, 2011-04-19 at 15:13 -0700, Grant Bowman wrote:
>> Rick, thank you for bringing this to the BUUG list. If there are
>> annual things that a campus group must do, perhaps a checklist would
>> help busy students maintain continuity during the frequent group
>> transitions.
>>
>> Paul, I'm sure some people from the buug.org, berkeleylug.com and/or
>> ubuntu-california.org groups would be interested in helping out. Let
>> us know what we can do and when you are planning meetings and events.
>>
>> Cheers,
>>
>> Grant Bowman
>>
>>
>> On Tue, Apr 19, 2011 at 2:00 PM, Rick Moen <rick at linuxmafia.com> wrote:
>> > Quoting Paul Ivanov (pi at berkeley.edu):
>> >
>> >> I'm game. Should I contact CalMail directly, or go through you?
>> >>
>> >> ditto for the -announce list.
>> >>
>> >> > It would be nice if CalLUG could be revived, but first things first.
>> >>
>> >> I'd be up for this, as well.
>> >
>> > Good to hear. ?To clarify, I'm just a subscriber and former attendee of
>> > CalLUG's on-campus meetings. ?(Gosh, it's been a while: ?Their brief
>> > revival ended in 2007.)
>> >
>> > I gather from the announcement that you would write to CalMail Staff
>> > <consult at berkeley.edu>, to step up and take over as listadmin.
>> >
>> >
>> > We can and should talk about what's required to revive CalLUG. ?I
>> > watched the LUG die, get revived, and die a second time, so I think I
>> > know the major pitfalls and can help you avoid them. ?I've been thinking
>> > of adding a section to the Linux User Group HOWTO[1] about the
>> > particular problems of college LUGs. ?Here's the short version:
>> >
>> > 1. ?Maintaining accreditation. ?In CalLUG's case, that would be through
>> > ASUC. ?Accredited groups get access to Internet server resources,
>> > publicity, use of rooms, right to post flyers, sometimes modest funding,
>> > etc. ?But you have to file timely paperwork. ?Failure to do those
>> > filings killed CCSF LUG.
>> >
>> > 2. ?Continuity, especially over the summer break. ?By that, I mean two
>> > things: ?CalLUG kept having a syndrome where the officers would get too
>> > busy in May/June preparing for finals, nobody would have time to make
>> > arrangements to ensure out-of-band means of communication in case the
>> > CalLUG server went down, and nobody would have time to ensure
>> > replacements for officers being graduated. ?Some combination of those
>> > two problems seems to have killed CalLUG, both times.
>> >
>> > [1] http://tldp.org/HOWTO/User-Group-HOWTO.html
>> > Also by the same author: ?http://linuxmafia.com/faq/Linux_PR/newlug.html


From excelblue at gmail.com  Tue Apr 19 17:42:48 2011
From: excelblue at gmail.com (Mark Lu)
Date: Tue, 19 Apr 2011 17:42:48 -0700
Subject: [buug] Reviving CalLUG
In-Reply-To: <20110419221336.GE23917@ykcyc>
References: <20110419201546.GF26669@linuxmafia.com>	<20110419202824.GA23917@ykcyc>	<20110419210059.GI26669@linuxmafia.com>
	<20110419221336.GE23917@ykcyc>
Message-ID: <4DAE2C08.60505@gmail.com>

As a current Cal undergrad and signatory for one student group, I'd be 
interested in assisting in this process.

The results are strict due to trademark issues, but the name should 
simply be registered as "Linux Users Group".

Let me know if you'd like to follow up or have any questions or concerns.

Mark Lu
UC Berkeley '12

On 04/19/2011 03:13 PM, Paul Ivanov wrote:
> Rick Moen, on 2011-04-19 14:00,  wrote:
>> I gather from the announcement that you would write to CalMail Staff
>> <consult at berkeley.edu>, to step up and take over as listadmin.
> done.
>
>> We can and should talk about what's required to revive CalLUG.  I
>> watched the LUG die, get revived, and die a second time, so I think I
>> know the major pitfalls and can help you avoid them.  I've been thinking
>> of adding a section to the Linux User Group HOWTO[1] about the
>> particular problems of college LUGs.  Here's the short version:
>>
>> 1.  Maintaining accreditation.  In CalLUG's case, that would be through
>> ASUC.  Accredited groups get access to Internet server resources,
>> publicity, use of rooms, right to post flyers, sometimes modest funding,
>> etc.  But you have to file timely paperwork.  Failure to do those
>> filings killed CCSF LUG.
> I'm familiar with these procedures, having helped run student
> clubs at UC Berkeley in the past. There's a threshold of
> needing four people to be Student Signatories, which are
> currently enrolled students who take and pass an online
> orientation quiz about rules and policies related to running a
> club on campus.
>
> Also, looking at the website for starting a club - it looks like it
> may have to be renamed, due to an apparently *ridiculous* policy:
>
> ------
>      Organization names must be in compliance with the Berkeley Campus
>      Regulations and the Office of Marketing and Business Outreach
>      policies.
>
>      The following names and corresponding variations may not be used
>      in your student group name:
>
>          * UC Berkeley
>          * California
>          * Cal
>          * UC
>          * UCB
>
>      'Berkeley' can be used in your student group name only if it is
>      used as a reference to geographic location, such as:
>
>          * at Berkeley
>          * of Berkeley
> ------
>
> Though they do mention that groups which started before this
> policy was in place are allowed to keep their name.  Any students
> out there can click on "Become A Signatory" here:
> http://campuslife.berkeley.edu/orgs/manage
>
> select these two groups:
> * Cal Linux User Group
>      - The name of the group has not yet been approved.
>      - The constitution for the group has not yet been approved.
> * GNU/Linux User Group at Cal
>      - The constitution for the group has not yet been approved.
>
> Seems like the second name, since it's been approved, might be
> the path of least resistance.
>
> I haven't been to one of their Sunday meetings, but I think there are
> some UCB students active on the BerkeleyLUG, so maybe I'll shoot
> an email that way (unless they're also on this list, please do
> chime in).
>
> The hosting resources available to official student organizations
> (clubs) is itself provided by a student org: the Open Computing
> Facillity (OCF). There's a good chance that some OCF members
> would also be interested in reviving CalLUG. Same goes for the
> Computer Science undergraduate and graduate associations.
>
>> 2.  Continuity, especially over the summer break.  By that, I mean two
>> things:  CalLUG kept having a syndrome where the officers would get too
>> busy in May/June preparing for finals, nobody would have time to make
>> arrangements to ensure out-of-band means of communication in case the
>> CalLUG server went down, and nobody would have time to ensure
>> replacements for officers being graduated.  Some combination of those
>> two problems seems to have killed CalLUG, both times.
> As a grad student, I'm still around during the summers, so that
> should help. But also, as a grad student, I hope to not stay here
> indefinitely, and would only want to invest time in a club that
> remains active beyond my time here, so year-to-year continuity
> would be a particularly important for me.
>
> best,
>
>
> _______________________________________________
> Buug mailing list
> Buug at weak.org
> http://www.weak.org/mailman/listinfo/buug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buug.org/pipermail/buug/attachments/20110419/38795fdf/attachment.html>

From Michael.Paoli at cal.berkeley.edu  Tue Apr 19 17:44:01 2011
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Tue, 19 Apr 2011 17:44:01 -0700
Subject: [buug] Reviving CalLUG
In-Reply-To: <20110419221336.GE23917@ykcyc>
References: <20110419201546.GF26669@linuxmafia.com>
	<20110419202824.GA23917@ykcyc> <20110419210059.GI26669@linuxmafia.com>
	<20110419221336.GE23917@ykcyc>
Message-ID: <20110419174401.16166m9jl2uwr8kk@webmail.rawbw.com>

[trying to not be too redundant :-)][1]

Thanks Paul, et. al.[1]

Sounds like keeping CalLUG alive / reviving it is generally a good idea.
If feasible, keeping the same name may also be good - but having a
"Plan B" for an alternate name, in case the original can't still be used,
sounds like a good idea.  (At least that's short version of my opinion
on the name bits).

As both BUUG and the
Berkeley Linux Users Group http://www.berkeleylug.com/
both meet again within the week (Th and Su respectively),
perhaps it may also be useful to discuss it there, and then
follow-up on list(s) to see if there's consensus (or approximation
thereof).

In the meantime, also taking any necessary steps to keep CalLUG from
totally disappearing (e.g. the mail list), sounds good.

Anyway, sounds like there are definitely some good possibilities and
opportunities for synergy, etc.

footnotes/references/excerpts:
1. see "thread" on:
http://www.weak.org/pipermail/buug/2011-April/date.html

> From: "Paul Ivanov" <pi at berkeley.edu>
> Subject: [buug] Reviving CalLUG
> Date: Tue, 19 Apr 2011 15:13:36 -0700

> Rick Moen, on 2011-04-19 14:00,  wrote:
>> I gather from the announcement that you would write to CalMail Staff
>> <consult at berkeley.edu>, to step up and take over as listadmin.
>
> done.
>
>> We can and should talk about what's required to revive CalLUG.  I
>> watched the LUG die, get revived, and die a second time, so I think I
>> know the major pitfalls and can help you avoid them.  I've been thinking
>> of adding a section to the Linux User Group HOWTO[1] about the
>> particular problems of college LUGs.  Here's the short version:
>>
>> 1.  Maintaining accreditation.  In CalLUG's case, that would be through
>> ASUC.  Accredited groups get access to Internet server resources,
>> publicity, use of rooms, right to post flyers, sometimes modest funding,
>> etc.  But you have to file timely paperwork.  Failure to do those
>> filings killed CCSF LUG.
>
> I'm familiar with these procedures, having helped run student
> clubs at UC Berkeley in the past. There's a threshold of
> needing four people to be Student Signatories, which are
> currently enrolled students who take and pass an online
> orientation quiz about rules and policies related to running a
> club on campus.
>
> Also, looking at the website for starting a club - it looks like it
> may have to be renamed, due to an apparently *ridiculous* policy:
>
> ------
>     Organization names must be in compliance with the Berkeley Campus
>     Regulations and the Office of Marketing and Business Outreach
>     policies.
>
>     The following names and corresponding variations may not be used
>     in your student group name:
>
>         * UC Berkeley
>         * California
>         * Cal
>         * UC
>         * UCB
>
>     ?Berkeley? can be used in your student group name only if it is
>     used as a reference to geographic location, such as:
>
>         * at Berkeley
>         * of Berkeley
> ------
>
> Though they do mention that groups which started before this
> policy was in place are allowed to keep their name.  Any students
> out there can click on "Become A Signatory" here:
> http://campuslife.berkeley.edu/orgs/manage
>
> select these two groups:
> * Cal Linux User Group
>     - The name of the group has not yet been approved.
>     - The constitution for the group has not yet been approved.
> * GNU/Linux User Group at Cal
>     - The constitution for the group has not yet been approved.
>
> Seems like the second name, since it's been approved, might be
> the path of least resistance.
>
> I haven't been to one of their Sunday meetings, but I think there are
> some UCB students active on the BerkeleyLUG, so maybe I'll shoot
> an email that way (unless they're also on this list, please do
> chime in).
>
> The hosting resources available to official student organizations
> (clubs) is itself provided by a student org: the Open Computing
> Facillity (OCF). There's a good chance that some OCF members
> would also be interested in reviving CalLUG. Same goes for the
> Computer Science undergraduate and graduate associations.
>
>> 2.  Continuity, especially over the summer break.  By that, I mean two
>> things:  CalLUG kept having a syndrome where the officers would get too
>> busy in May/June preparing for finals, nobody would have time to make
>> arrangements to ensure out-of-band means of communication in case the
>> CalLUG server went down, and nobody would have time to ensure
>> replacements for officers being graduated.  Some combination of those
>> two problems seems to have killed CalLUG, both times.
>
> As a grad student, I'm still around during the summers, so that
> should help. But also, as a grad student, I hope to not stay here
> indefinitely, and would only want to invest time in a club that
> remains active beyond my time here, so year-to-year continuity
> would be a particularly important for me.
>
> best,
> --
> Paul Ivanov
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7



From pi at berkeley.edu  Tue Apr 19 18:33:06 2011
From: pi at berkeley.edu (Paul Ivanov)
Date: Tue, 19 Apr 2011 18:33:06 -0700
Subject: [buug] Reviving CalLUG
In-Reply-To: <20110419174401.16166m9jl2uwr8kk@webmail.rawbw.com>
	<4DAE2C08.60505@gmail.com>
Message-ID: <20110420013306.GD26776@ykcyc>


Mark Lu, on 2011-04-19 17:42,  wrote:
> As a current Cal undergrad and signatory for one student group, I'd
> be interested in assisting in this process.

Great - I already made myself a signatory on both groups, so once
you become one, we're half way to the required number of
signatories. You can do that over here:
http://campuslife.berkeley.edu/orgs/manage

select these two groups:
* Cal Linux User Group 
* GNU/Linux User Group at Cal 
 
> The results are strict due to trademark issues, but the name should
> simply be registered as "Linux Users Group".

well, the policy just makes no sense - it prevents student
organizations from signifying any kind of affiliation with the
university.

Here are some allowed, and disallowed student group names,
according to http://campuslife.berkeley.edu/orgs/new-group

    EXAMPLES:

    * Public Speaking Group at Berkeley ? APPROVED
    * Public Speaking Group of Berkeley ? APPROVED
    * Public Speaking Group at UC Berkeley ? NOT APPROVED
    * Public Speaking at Cal ? NOT APPROVED
    * Berkeley Public Speaking Group ? NOT APPROVED
    * Cal Public Speaking Group ? NOT APPROVED
    * California Public Speaking Group ? NOT APPROVED
    * Public Speaking Group at California ? NOT APPROVED
    * Public Speaking Group, Berkeley ? NOT APPROVED
    * Berkeley Campus Public Speaking ? NOT APPROVED

so if at most we're allowed to call the group "Linux User Group
at/of Berkeley" - there's already a BerkeleyLUG - it meets on
Sundays and has no affiliation with the university.

Anyway, the fact that "GNU/Linux User Group at Cal" group name
has already been approved - we can just continue to use that,
but like Michael (see below), this is the short version of my
opinion on this matter.


> Let me know if you'd like to follow up or have any questions or concerns.

Would you be able to make it to either the BUUG or BerkeleyLUG
meetings on Thursday and Sunday, respectively (see Michael's
notes on the matter below).

Michael Paoli, on 2011-04-19 17:44,  wrote:
> [trying to not be too redundant :-)][1]
> 
> Thanks Paul, et. al.[1]
> 
> Sounds like keeping CalLUG alive / reviving it is generally a good idea.
> If feasible, keeping the same name may also be good - but having a
> "Plan B" for an alternate name, in case the original can't still be used,
> sounds like a good idea.  (At least that's short version of my opinion
> on the name bits).
> 
> As both BUUG and the
> Berkeley Linux Users Group http://www.berkeleylug.com/
> both meet again within the week (Th and Su respectively),
> perhaps it may also be useful to discuss it there, and then
> follow-up on list(s) to see if there's consensus (or approximation
> thereof).
 
Sounds like a plan, see you Thursday.

> In the meantime, also taking any necessary steps to keep CalLUG from
> totally disappearing (e.g. the mail list), sounds good.

The fine folks over at UC Berkeley IST already made me the list
admin for both lists, here's some more information about them.

There are 116 addresses subscribed to callug_announce at lists.berkeley.edu
There are 17 addresses subscribed to callug_discuss at lists.berkeley.edu. 

> Anyway, sounds like there are definitely some good possibilities and
> opportunities for synergy, etc.
> 
> footnotes/references/excerpts:
> 1. see "thread" on:
> http://www.weak.org/pipermail/buug/2011-April/date.html


best,
-- 
Paul Ivanov
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://buug.org/pipermail/buug/attachments/20110419/901cfae7/attachment.sig>

From grantbow at ubuntu.com  Tue Apr 19 21:07:25 2011
From: grantbow at ubuntu.com (Grant Bowman)
Date: Tue, 19 Apr 2011 21:07:25 -0700
Subject: [buug] Berkeley LUG relationship (was: Reviving CalLUG)
Message-ID: <BANLkTimSMtxNmL4W9BudizMq3T0_h5o3QA@mail.gmail.com>

Just a quick clarification.

On Tue, Apr 19, 2011 at 6:33 PM, Paul Ivanov <pi at berkeley.edu> wrote:
> ...
> so if at most we're allowed to call the group "Linux User Group
> at/of Berkeley" - there's already a BerkeleyLUG - it meets on
> Sundays and has no affiliation with the university.
> ...

That statement actually isn't quite true. The
berkeleylug.com/berkeleylug.org founder Jack Deslippe is a grad
student in Physics. I am not sure if we have ever filed any paperwork
with the campus.  We have had several current students and alumni
attend meetings. Last year we scheduled a table to hand out Linux CDs
on Sproul Plaza but this turned out to be the same day student
protests were taking place over fee hikes so we canceled our event.
Several other student outreach plans have been discussed including an
informal, monthly co-sponsored Ubuntu Hour [1] at Caffe Strada
(College @ Bancroft) that only needs a regular day of the month and
time to begin meeting.

Cheers,

Grant


[1] https://wiki.ubuntu.com/CaliforniaTeam/Projects/UbuntuHours


From grantbow at ubuntu.com  Tue Apr 19 21:09:32 2011
From: grantbow at ubuntu.com (Grant Bowman)
Date: Tue, 19 Apr 2011 21:09:32 -0700
Subject: [buug] Reviving CalLUG
In-Reply-To: <20110420013306.GD26776@ykcyc>
References: <20110419174401.16166m9jl2uwr8kk@webmail.rawbw.com>
	<4DAE2C08.60505@gmail.com> <20110420013306.GD26776@ykcyc>
Message-ID: <BANLkTind1fn7dPPCoLeuDuOy3T3_Dx_s1A@mail.gmail.com>

Bravo, Paul and Mark! Great work taking care of these matters!

Grant


On Tue, Apr 19, 2011 at 6:33 PM, Paul Ivanov <pi at berkeley.edu> wrote:
>
> Mark Lu, on 2011-04-19 17:42, ?wrote:
>> As a current Cal undergrad and signatory for one student group, I'd
>> be interested in assisting in this process.
>
> Great - I already made myself a signatory on both groups, so once
> you become one, we're half way to the required number of
> signatories. You can do that over here:
> http://campuslife.berkeley.edu/orgs/manage
>
> select these two groups:
> * Cal Linux User Group
> * GNU/Linux User Group at Cal
>
>> The results are strict due to trademark issues, but the name should
>> simply be registered as "Linux Users Group".
>
> well, the policy just makes no sense - it prevents student
> organizations from signifying any kind of affiliation with the
> university.
>
> Here are some allowed, and disallowed student group names,
> according to http://campuslife.berkeley.edu/orgs/new-group
>
> ? ?EXAMPLES:
>
> ? ?* Public Speaking Group at Berkeley ? APPROVED
> ? ?* Public Speaking Group of Berkeley ? APPROVED
> ? ?* Public Speaking Group at UC Berkeley ? NOT APPROVED
> ? ?* Public Speaking at Cal ? NOT APPROVED
> ? ?* Berkeley Public Speaking Group ? NOT APPROVED
> ? ?* Cal Public Speaking Group ? NOT APPROVED
> ? ?* California Public Speaking Group ? NOT APPROVED
> ? ?* Public Speaking Group at California ? NOT APPROVED
> ? ?* Public Speaking Group, Berkeley ? NOT APPROVED
> ? ?* Berkeley Campus Public Speaking ? NOT APPROVED
>
> so if at most we're allowed to call the group "Linux User Group
> at/of Berkeley" - there's already a BerkeleyLUG - it meets on
> Sundays and has no affiliation with the university.
>
> Anyway, the fact that "GNU/Linux User Group at Cal" group name
> has already been approved - we can just continue to use that,
> but like Michael (see below), this is the short version of my
> opinion on this matter.
>
>
>> Let me know if you'd like to follow up or have any questions or concerns.
>
> Would you be able to make it to either the BUUG or BerkeleyLUG
> meetings on Thursday and Sunday, respectively (see Michael's
> notes on the matter below).
>
> Michael Paoli, on 2011-04-19 17:44, ?wrote:
>> [trying to not be too redundant :-)][1]
>>
>> Thanks Paul, et. al.[1]
>>
>> Sounds like keeping CalLUG alive / reviving it is generally a good idea.
>> If feasible, keeping the same name may also be good - but having a
>> "Plan B" for an alternate name, in case the original can't still be used,
>> sounds like a good idea. ?(At least that's short version of my opinion
>> on the name bits).
>>
>> As both BUUG and the
>> Berkeley Linux Users Group http://www.berkeleylug.com/
>> both meet again within the week (Th and Su respectively),
>> perhaps it may also be useful to discuss it there, and then
>> follow-up on list(s) to see if there's consensus (or approximation
>> thereof).
>
> Sounds like a plan, see you Thursday.
>
>> In the meantime, also taking any necessary steps to keep CalLUG from
>> totally disappearing (e.g. the mail list), sounds good.
>
> The fine folks over at UC Berkeley IST already made me the list
> admin for both lists, here's some more information about them.
>
> There are 116 addresses subscribed to callug_announce at lists.berkeley.edu
> There are 17 addresses subscribed to callug_discuss at lists.berkeley.edu.
>
>> Anyway, sounds like there are definitely some good possibilities and
>> opportunities for synergy, etc.
>>
>> footnotes/references/excerpts:
>> 1. see "thread" on:
>> http://www.weak.org/pipermail/buug/2011-April/date.html
>
>
> best,
> --
> Paul Ivanov
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk2uN8YACgkQe+cmRQ8+KPdnwwCfYyKe/BZvWitZP+jOaHu6HOKh
> 6DUAn3pTgV1XR3wc2pl+/PB0Ctn38Fbs
> =0Jbr
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Buug mailing list
> Buug at weak.org
> http://www.weak.org/mailman/listinfo/buug
>
>


From excelblue at gmail.com  Wed Apr 20 03:09:32 2011
From: excelblue at gmail.com (Mark Lu)
Date: Wed, 20 Apr 2011 03:09:32 -0700
Subject: [buug] Reviving CalLUG
In-Reply-To: <20110420013306.GD26776@ykcyc>
References: <20110420013306.GD26776@ykcyc>
Message-ID: <4DAEB0DC.7060807@gmail.com>

I just added myself as a signatory for both groups.

You're right -- the policy prevents signifying any affiliation with Cal, 
but that's actually their main goal. Truth is, student organizations are 
run by students, but they're not officially endorsed by Cal. It's some 
legal ramifications that they have to protect themselves against -- 
namely, the possible loss of their trademark.

I might not be able to make the meeting this Thursday, but the Sundays 
and Thursdays are usually good for me. I will hopefully see you all then.

On 04/19/2011 06:33 PM, Paul Ivanov wrote:
> Mark Lu, on 2011-04-19 17:42,  wrote:
>> As a current Cal undergrad and signatory for one student group, I'd
>> be interested in assisting in this process.
> Great - I already made myself a signatory on both groups, so once
> you become one, we're half way to the required number of
> signatories. You can do that over here:
> http://campuslife.berkeley.edu/orgs/manage
>
> select these two groups:
> * Cal Linux User Group
> * GNU/Linux User Group at Cal
>
>> The results are strict due to trademark issues, but the name should
>> simply be registered as "Linux Users Group".
> well, the policy just makes no sense - it prevents student
> organizations from signifying any kind of affiliation with the
> university.
>
> Here are some allowed, and disallowed student group names,
> according to http://campuslife.berkeley.edu/orgs/new-group
>
>      EXAMPLES:
>
>      * Public Speaking Group at Berkeley ? APPROVED
>      * Public Speaking Group of Berkeley ? APPROVED
>      * Public Speaking Group at UC Berkeley ? NOT APPROVED
>      * Public Speaking at Cal ? NOT APPROVED
>      * Berkeley Public Speaking Group ? NOT APPROVED
>      * Cal Public Speaking Group ? NOT APPROVED
>      * California Public Speaking Group ? NOT APPROVED
>      * Public Speaking Group at California ? NOT APPROVED
>      * Public Speaking Group, Berkeley ? NOT APPROVED
>      * Berkeley Campus Public Speaking ? NOT APPROVED
>
> so if at most we're allowed to call the group "Linux User Group
> at/of Berkeley" - there's already a BerkeleyLUG - it meets on
> Sundays and has no affiliation with the university.
>
> Anyway, the fact that "GNU/Linux User Group at Cal" group name
> has already been approved - we can just continue to use that,
> but like Michael (see below), this is the short version of my
> opinion on this matter.
>
>
>> Let me know if you'd like to follow up or have any questions or concerns.
> Would you be able to make it to either the BUUG or BerkeleyLUG
> meetings on Thursday and Sunday, respectively (see Michael's
> notes on the matter below).
>
> Michael Paoli, on 2011-04-19 17:44,  wrote:
>> [trying to not be too redundant :-)][1]
>>
>> Thanks Paul, et. al.[1]
>>
>> Sounds like keeping CalLUG alive / reviving it is generally a good idea.
>> If feasible, keeping the same name may also be good - but having a
>> "Plan B" for an alternate name, in case the original can't still be used,
>> sounds like a good idea.  (At least that's short version of my opinion
>> on the name bits).
>>
>> As both BUUG and the
>> Berkeley Linux Users Group http://www.berkeleylug.com/
>> both meet again within the week (Th and Su respectively),
>> perhaps it may also be useful to discuss it there, and then
>> follow-up on list(s) to see if there's consensus (or approximation
>> thereof).
>
> Sounds like a plan, see you Thursday.
>
>> In the meantime, also taking any necessary steps to keep CalLUG from
>> totally disappearing (e.g. the mail list), sounds good.
> The fine folks over at UC Berkeley IST already made me the list
> admin for both lists, here's some more information about them.
>
> There are 116 addresses subscribed to callug_announce at lists.berkeley.edu
> There are 17 addresses subscribed to callug_discuss at lists.berkeley.edu.
>
>> Anyway, sounds like there are definitely some good possibilities and
>> opportunities for synergy, etc.
>>
>> footnotes/references/excerpts:
>> 1. see "thread" on:
>> http://www.weak.org/pipermail/buug/2011-April/date.html
>
> best,
>
>
> _______________________________________________
> Buug mailing list
> Buug at weak.org
> http://www.weak.org/mailman/listinfo/buug



From rick at linuxmafia.com  Wed Apr 20 06:02:53 2011
From: rick at linuxmafia.com (Rick Moen)
Date: Wed, 20 Apr 2011 06:02:53 -0700
Subject: [buug] Reviving CalLUG
In-Reply-To: <20110419221336.GE23917@ykcyc>
References: <20110419201546.GF26669@linuxmafia.com>
	<20110419202824.GA23917@ykcyc>
	<20110419210059.GI26669@linuxmafia.com>
	<20110419221336.GE23917@ykcyc>
Message-ID: <20110420130253.GL26669@linuxmafia.com>

Quoting Paul Ivanov (pi at berkeley.edu):

> Rick Moen, on 2011-04-19 14:00,  wrote:
> > I gather from the announcement that you would write to CalMail Staff
> > <consult at berkeley.edu>, to step up and take over as listadmin.
> 
> done.

Coolness.

> Also, looking at the website for starting a club - it looks like it
> may have to be renamed, due to an apparently *ridiculous* policy:

And Mark Lu commented:

> It's some legal ramifications that they have to protect themselves
> against -- namely, the possible loss of their trademark.

...though the usage described poses no real threat to those trademarks,
especially if accompanied by small-print acknowledgements like 'Cal is a
trademark of the Regents of the University of California'.  (This
assumes such a Federal or common-law trademark actually exists, which is
a separate matter.)  Anyway, the short version is that that the
realities of trademark law make companies and institutions a little
crazy, and we just have to deal with the fallout.  If interested in more
about why this happens, Cory Doctorow has written one of the best short
explanations, here:

http://openp2p.com/pub/a/p2p/2003/08/14/trademarks.html

Longer compendia of explanations (mine), for the obsessed:
http://linuxmafia.com/faq/Licensing_and_Law/trademark-law.html
http://linuxmafia.com/faq/Licensing_and_Law/trademark-law.add

Paul Ivanov went on:


> Seems like the second name, since it's been approved, might be
> the path of least resistance.

Here's something that sometimes gets lost in these discussions, and it
might be obvious (no condescension intended), but I'll say it anyway:
You're the bloke doing (the lion's share of) the actual work, so you get
to decide how best to proceed.

Intending _not_ to make any exception to that general guideline, but
just as an idea to ponder, I'll add:  You might wish to look into
whether it's workable to have the club _officially_ be something
tailored to UCB's trademark policy (e.g., GNU/Linux User Group at Cal)
but retaining an unofficial identity as 'CalLUG'.  

The policy blatt at http://campuslife.berkeley.edu/orgs/new-group
doesn't specifically discourage such measures.  If they harrumph and
object, you can always rename things.

Reasons why:  

1. 'CalLUG' is much less a mouthful than all of the painful
circumlocutions required to placate crazed staff attorneys.

2.  The two mailing lists already exist with 'CalLUG' in their names,
and _also_ existing prior Web site contents exist that can be unearthed
and repurposed (again, _if the active volunteers so wish_):

The Web site existed at at bewildering chain of URLs that at one time or
another existed as HTTP 302 redirects:

http://linux.berkeley.edu/
http://linux.berkeley.edu:80 
http://www.ocf.berkeley.edu/~linux/
http://www.ocf.berkeley.edu:80/~linux/
http://callug.cs.berkeley.edu/apache2-default/

(The last of those never had anything but a stub.)

When the site was last active, it was a Drupal thing:
http://replay.web.archive.org/20060706064503/http://www.ocf.berkeley.edu/~linux/
I personally have some aesthetic and functional qualms with Drupal, but
to each his own.[1]

Here's Internet Archive's final snapshot of the pre-Drupal site:
http://replay.web.archive.org/20050404113823/http://www.ocf.berkeley.edu/~linux/mirror/
Snapshots at that URL go back to Oct. 2, 2002, FYI.  Rummaging around in
the directory-parent of that URL tree may also unearth useful things:
http://replay.web.archive.org/20050404113823/http://www.ocf.berkeley.edu/~linux/

3.  'CalLUG' still has substantial, and thus possibly useful name recognition.
See for example http://en.wikipedia.org/wiki/CalLUG.


Reasons why not:

1.  A group that mostly died in the mid-2000s and completely died in
2007 can't have _that_ much name recognition except among doddering
geezers like me.  That's a long time in dog^W Internet years.

2.  Mailing lists can be renamed (with admin help).  Web site contents 
can be used with a name change.  'sed' continues to work.  ;->






> The hosting resources available to official student organizations
> (clubs) is itself provided by a student org: the Open Computing
> Facillity (OCF). There's a good chance that some OCF members
> would also be interested in reviving CalLUG.

I'm glad you mentioned that.  As you'll see from the above-cited URL 
chain, CalLUG was indeed an OCF production.  


[1] Long and contentious topic best indulged elsewhere, and 
<facetious>you don't want the CMS mafia mad at you, or you might wake up
with a dead copy of Plone next to you in your bed.</facetious>  
Drupal is one arguable way of pursuing Rule One of system
administration, which is 'Automate the hell out of everything you
possibly can.'



From rick at linuxmafia.com  Wed Apr 20 07:47:51 2011
From: rick at linuxmafia.com (Rick Moen)
Date: Wed, 20 Apr 2011 07:47:51 -0700
Subject: [buug] Reviving CalLUG
In-Reply-To: <20110420013306.GD26776@ykcyc>
Message-ID: <20110420144751.GM26669@linuxmafia.com>

I inadvertently ignored some of what Paul said.  (Apologies: 
I'm jet-lagged.)

Quoting Paul Ivanov (pi at berkeley.edu):

> Would you be able to make it to either the BUUG or BerkeleyLUG
> meetings on Thursday and Sunday, respectively (see Michael's
> notes on the matter below).

Sorry to report, I have some conflicting commitments, and also need to
do a whole lot of catch on matters have have waited while my wife and I
were on holiday in Europe for a couple of weeks.


> The fine folks over at UC Berkeley IST already made me the list
> admin for both lists, here's some more information about them.
> 
> There are 116 addresses subscribed to callug_announce at lists.berkeley.edu
> There are 17 addresses subscribed to callug_discuss at lists.berkeley.edu. 

That's actually a little astonishing for a long-dormant mailing list to
have that many vetted addresses.

I say 'vetted' because lists.berkeley.edu appears to (nowadays) run GNU
Mailman (with which I'm intimately familiar), replacing the antique
majordomo setup originally present.  Unless configured not to do so,
Mailman checks the deliverability (using VERP) of all subscribed addresses 
periodically.

FYI, the original mailing list host was brain.cs.berkeley.edu.  Then, it
was callug.cs.berkeley.edu, and finally the current lists.berkeley.edu
(which is of course no longer CalLUG-specific).

Originally, there were three mailing lists:

callug-announce
callug-general
callug-help

These were later pruned to the current two.  Which is just as well.
(A common error in new LUGs is to go hog-wild with creation of too
many channels of communication, most of which then languish for lack of
critical mass.)



Anyway, reverting to a prior subtopic_  I could write a book about
characteristic psychopathologies of LUGs (and some of that is already in
the Linux User Group HOWTO), which is a minor variation on the
psychopathologies of geekdom generally.  One of the many things I notice
-- which I mention because I'm sure it will come up -- is that LUG
social circles tend to freeze collective action through endless
debate.[1]  In particular, there's a strong tendency for the leadership
to sit on their hands as long as anyone has any objection whatsoever to
something that has been proposed or announced.

For example, suppose you set about reviving a LUG at Cal, look over
which nights nearby groups of interest meet to spot conflicts
(http://linuxmafia.com/bale/ might help -- yr. welcome), and announce
'OK, looks like 3rd Wednesday nights are good.  I've talked to
administration, and we'll be reserving a room in Soda Hall, formal
announcement to come.'

Nine times out of ten, a Pavlovian response will kick in, impelling
several people to say '3rd Wednesdays don't work for me', as if that
were a deal-breaker.  Morever, it's common for this to get taken
seriously, i.e., for people to tacitly act as if 3rd Wednesdays were
thereby rendered unacceptable -- even if there's no special reason to
think the speaker would ever meaningfully contribute.

Thus, the point:  Don't even try to make every featherless biped with an
opinion happy.  You shouldn't (IMO) try to run a democracy among
everyone capable of typing into an MUA.  You should (IMO) arrange
matters to the maximum convenience and satisfaction of the small
minority who do the group's work.


You mentioned that UCB's rules require four UCB-qualified signatories.
By a no doubt Deeply Meaningless Coincidence[TM], I wrote on 
http://linuxmafia.com/faq/Linux_PR/newlug.html :

   7. You need a core of several Linux enthusiasts.

   LUGs have succeeded wonderfully on the strength of ongoing efforts
   from as few as four energetic and inquisitive people. That's really
   all you need, but one or two are not enough. E-mail is terrific for
   coordination.

   Your core enthusiasts don't need any Linux knowledge initially, but
   must be "self-starters", and must have Internet access and know how to
   use it well.

Silicon Valley Linux User Group is currently limping along with the work
of about -- ta-da -- four active volunteers, for example.  It works well
enough.

That's about all for now.  As Pascal said, 'I am sorry for the length of
my letter, but I had not the time to write a short one.'



[1] The Irony Fairy may strike me dead for saying this, but you will
find that most useful input and participation, with a minimum of bizarre
interference, gratuitous ideology, and impractical notions, comes from
in-person interaction rather than from strangers talking at you over the
Internet (says the stranger talking at you over the Internet).  



From rick at linuxmafia.com  Wed Apr 20 10:01:38 2011
From: rick at linuxmafia.com (Rick Moen)
Date: Wed, 20 Apr 2011 10:01:38 -0700
Subject: [buug] (forw) List owner needed for
 callug_discuss@lists.berkeley.edu
In-Reply-To: <BANLkTimBbk-6hTQWjJf1JCKiEx1-bibRMg@mail.gmail.com>
References: <20110419201546.GF26669@linuxmafia.com>
	<20110419202824.GA23917@ykcyc>
	<20110419210059.GI26669@linuxmafia.com>
	<BANLkTimBbk-6hTQWjJf1JCKiEx1-bibRMg@mail.gmail.com>
Message-ID: <20110420170138.GR26669@linuxmafia.com>

My friend Grant wrote:

> No other distribution has been as successful reaching out to
> "simple end users" as the Ubuntu community project.

Aren't you forgetting TiVos?  ;->


Just because I have a seriously evil sense of humour, and in hopes of 
giving bored BUUG members something else to talk about, here's some
gasoline for that fire.  (Disagreement is expected and cheerfully
invited.  Despite this being California and even -- gasp! -- Berkeley,
it is _not_ in fact obligatory that everyone hold identical opinions.)

And if people would prefer IT-press bait to chew on, instead, here:
http://itknowledgeexchange.techtarget.com/enterprise-linux/ubuntu-1104-beta-testers-divided-over-unity/



 Date: Wed, 20 Apr 2011 09:19:03 -0700
 From: Rick Moen <rick at linuxmafia.com>
 To: skeptic at lists.johnshopkins.edu
 Subject: Re: Ubuntu 11.04 with Gnome 3
 Organization: If you lived here, you'd be $HOME already.
 X-Mas: Bah humbug.
 User-Agent: Mutt/1.5.20 (2009-06-14)

Quoting Dean A. Batha (dean at deanbatha.com):

> Yesterday, on a whim, I downloaded the Beta of the upcoming Ubuntu
> 11.04 and installed it. So far, it's stable and fast. It's a radical
> departure from the traditional "desktop" GUI model. It looks more like
> a giant Android tablet -- large icons and no menus. Ok, applications
> still have menus, but they're hidden. You reveal the menus by mousing
> over the title bar. It creates a very clean looking environment, but
> it took me a while to figure out what they were trying to do.

Personally, I'd stay away from upcoming Ubuntu.  I have extremely little
faith in their recent direction in several areas, including the 'Unity'
desktop environment.  In a nutshell:  They've not only fallen under the
spell of the GNOME/freedesktop.org recipe of 'Do everything possible to
deprive the user of capabilities and configuration options, which will
only confuse the poor dears, and we know what's best for them', but have
started to outpace them in that department.

On the other hand, anyone whose idea of a proper computing environment
is an extremely simplified, minimal options, graphical appliance may
love it -- and who am I to judge?  Except, the stuff's probably buggy as
hell, for now.

(Ubuntistas would dismiss me as a Unix reactionary, which is probably a
fair cop.)


> Hardware set-up on my laptop was about as simple as possible.

In a sense, they borrowed from my team's 1999 work on the Linuxcare
Bootable Business Card, whose hardware autodetection in turn directly
inspired Klaus Knopper's 'Knoppix' live CD, which lead directly to the
current crop of what we facetiously call 'forehead installers' (OS
installation routines where you basically need only hit the spacebar
with your forehead until it terminates).  

Most likely problem area for hardware support is WiFi chipsets featuring
the usual swear words (Broadcom, Marvell).  Sometimes also low-end
aDSL adapters, some others.  Broadcom and Marvell refuse to allow anyone
else to redistribute their 'firmware' BLOB files to initialise the
chips.  Linux distros have workarounds using 'fwcutter' (firmware
cutter -- exact name differs) utilities that autodownload the MS-Windows
driver .exe or .zip or whatever archive, extract the firmware BLOB, and
dunk it into /lib/firmware/ where the kernel can thenceforth use it.  If
you're lucky, the OS installer might have run the fwcutter utility
automagically.  If not, it's there and a little Web-searching tells you
its name.

The hardware companies could solve this problem with a single sheet of
corporate stationary and a first-class postage stamp, but they just
don't care.



From rick at linuxmafia.com  Wed Apr 20 11:25:38 2011
From: rick at linuxmafia.com (Rick Moen)
Date: Wed, 20 Apr 2011 11:25:38 -0700
Subject: [buug] Reviving CalLUG
In-Reply-To: <20110420144751.GM26669@linuxmafia.com>
References: <20110420013306.GD26776@ykcyc>
	<20110420144751.GM26669@linuxmafia.com>
Message-ID: <20110420182538.GA937@linuxmafia.com>

I was just poking around a little more, and notice something possibly
worth mentioning:

> I say 'vetted' because lists.berkeley.edu appears to (nowadays) run GNU
> Mailman (with which I'm intimately familiar), replacing the antique
> majordomo setup originally present.  Unless configured not to do so,
> Mailman checks the deliverability (using VERP) of all subscribed addresses 
> periodically.
> 
> FYI, the original mailing list host was brain.cs.berkeley.edu.  Then, it
> was callug.cs.berkeley.edu, and finally the current lists.berkeley.edu
> (which is of course no longer CalLUG-specific).

One of GNU Mailman's built-in features -- and one of the reasons for
mass-migration to it away from majordomo in the '90s -- is its
automatic maintenance of Web archives of back postings, which by default
are public.

For example, the Menlo Park LUG 'CABAL' operates general discussion
mailing list 'conspire' (silly joke, I know), which has this Mailman
'listinfo' page automatically generated by a Mailman CGI:

http://linuxmafia.com/mailman/listinfo/conspire
...and that, in turn, gives direct access to the mailing list's public
archives of all postings going back to December 2000, when I converted
all my mailing lists from majordomo to Mailman.
http://linuxmafia.com/pipermail/conspire/

In the process of being moded from CalLUG's own server (brain, callug)
to UCB's Campuswide IT Services's 'CalMail' site (lists.berkeley.edu),
_apparently_ the feature of public archiving has been lost.  I cannot
find any entry point to archives -- although it's possible that one is 
available NONpublicly to persons after CalNet login.

I also cannot find Mailman-type listinfo pages.  Instead, we see
something seemingly generated by Campuswide IT Services' bespoke
software:

https://calmail.berkeley.edu/manage/list/listinfo/callug_discuss at lists.berkeley.edu
https://calmail.berkeley.edu/manage/list/listinfo/callug_announce at lists.berkeley.edu

In short, it seems like they've used the SMTP functionality from
GNU Mailman, but gone out of their way to disable its CGI Web interface
completely.  That's a shame, I guess, but on the bright side it's
preserved the two mailing lists to the present day.

Paul and Mark:  If you ever get to the point of wanting to do so, I 
can show you how to migrate the full mailing lists (including
full back-postings archives) away from CalMail to a real Mailman
installation under your control.  OTOH, you might decide that letting
Campuswide IT Services be the sysadmins is kinda nice despite the
feature disabling.




From excelblue at gmail.com  Wed Apr 20 12:01:52 2011
From: excelblue at gmail.com (Mark Lu)
Date: Wed, 20 Apr 2011 12:01:52 -0700
Subject: [buug] Reviving CalLUG
In-Reply-To: <20110420182538.GA937@linuxmafia.com>
References: <20110420013306.GD26776@ykcyc>
	<20110420144751.GM26669@linuxmafia.com>
	<20110420182538.GA937@linuxmafia.com>
Message-ID: <BANLkTi=dCxvq-nPjeufYAoFbj2N_ApVQ_Q@mail.gmail.com>

To be honest, the CalMail mailing lists are an absolute nightmare to
use. The only real advantage is that you get an @lists.berkeley.edu
mailing list address, but in terms of transitioning (at least with the
less-technical people I've worked with), it's near impossible to do
successfully. I've seen several groups create multiple new mailing
lists because they failed to transition the old ones.

The real advantage to brining back CalLUG is the ability to reserve
rooms on-campus for free. It'll also help the less adventurous
students get started with Linux as it'll consist of lots of
(hopefully) helpful peers.

I have experience with running my own Mailman, though, to be honest, I
think we should just look at registering a domain name and leeching
off Google Groups if we just want a list that works, is easily (and
publicly) searchable, and is reliable.

On Wed, Apr 20, 2011 at 11:25 AM, Rick Moen <rick at linuxmafia.com> wrote:
> I was just poking around a little more, and notice something possibly
> worth mentioning:
>
>> I say 'vetted' because lists.berkeley.edu appears to (nowadays) run GNU
>> Mailman (with which I'm intimately familiar), replacing the antique
>> majordomo setup originally present. ?Unless configured not to do so,
>> Mailman checks the deliverability (using VERP) of all subscribed addresses
>> periodically.
>>
>> FYI, the original mailing list host was brain.cs.berkeley.edu. ?Then, it
>> was callug.cs.berkeley.edu, and finally the current lists.berkeley.edu
>> (which is of course no longer CalLUG-specific).
>
> One of GNU Mailman's built-in features -- and one of the reasons for
> mass-migration to it away from majordomo in the '90s -- is its
> automatic maintenance of Web archives of back postings, which by default
> are public.
>
> For example, the Menlo Park LUG 'CABAL' operates general discussion
> mailing list 'conspire' (silly joke, I know), which has this Mailman
> 'listinfo' page automatically generated by a Mailman CGI:
>
> http://linuxmafia.com/mailman/listinfo/conspire
> ...and that, in turn, gives direct access to the mailing list's public
> archives of all postings going back to December 2000, when I converted
> all my mailing lists from majordomo to Mailman.
> http://linuxmafia.com/pipermail/conspire/
>
> In the process of being moded from CalLUG's own server (brain, callug)
> to UCB's Campuswide IT Services's 'CalMail' site (lists.berkeley.edu),
> _apparently_ the feature of public archiving has been lost. ?I cannot
> find any entry point to archives -- although it's possible that one is
> available NONpublicly to persons after CalNet login.
>
> I also cannot find Mailman-type listinfo pages. ?Instead, we see
> something seemingly generated by Campuswide IT Services' bespoke
> software:
>
> https://calmail.berkeley.edu/manage/list/listinfo/callug_discuss at lists.berkeley.edu
> https://calmail.berkeley.edu/manage/list/listinfo/callug_announce at lists.berkeley.edu
>
> In short, it seems like they've used the SMTP functionality from
> GNU Mailman, but gone out of their way to disable its CGI Web interface
> completely. ?That's a shame, I guess, but on the bright side it's
> preserved the two mailing lists to the present day.
>
> Paul and Mark: ?If you ever get to the point of wanting to do so, I
> can show you how to migrate the full mailing lists (including
> full back-postings archives) away from CalMail to a real Mailman
> installation under your control. ?OTOH, you might decide that letting
> Campuswide IT Services be the sysadmins is kinda nice despite the
> feature disabling.
>
>
> _______________________________________________
> Buug mailing list
> Buug at weak.org
> http://www.weak.org/mailman/listinfo/buug
>



-- 
Mark Lu


From rick at linuxmafia.com  Wed Apr 20 12:15:35 2011
From: rick at linuxmafia.com (Rick Moen)
Date: Wed, 20 Apr 2011 12:15:35 -0700
Subject: [buug] Reviving CalLUG
In-Reply-To: <BANLkTi=dCxvq-nPjeufYAoFbj2N_ApVQ_Q@mail.gmail.com>
References: <20110420013306.GD26776@ykcyc>
	<20110420144751.GM26669@linuxmafia.com>
	<20110420182538.GA937@linuxmafia.com>
	<BANLkTi=dCxvq-nPjeufYAoFbj2N_ApVQ_Q@mail.gmail.com>
Message-ID: <20110420191535.GV26669@linuxmafia.com>

Quoting Mark Lu (excelblue at gmail.com):

> The real advantage to bringing back CalLUG is the ability to reserve
> rooms on-campus for free.

Yes, indeed.

CalLUG got a lot of mileage out of that, tending to use Soda Hall for
that.  There was a minor problem that access into the building was
restricted after a certain hour.

> I have experience with running my own Mailman, though, to be honest, I
> think we should just look at registering a domain name and leeching
> off Google Groups if we just want a list that works, is easily (and
> publicly) searchable, and is reliable.

I notice without objection your GMail address.  ;->  FWIW, some of us
decline to turn over our computing lives to Google, Inc., and enjoy 
the functional advantages of being able to enforce our own policies,
implement the sort of antispam _we_ want, not be subject to 
Google, Inc.'s takedown policies, not have to deal with yet more 
of Google, Inc.'s advertising and tracking[1], and so on.

Also FWIW, http://linuxmafia.com/faq/Linux_PR/newlug.html points out
another consideration:

  23. Walk the walk.

  It's painfully grotesque to see so-called Linux user groups mailing out
  announcements using MS-Outlook, Eudora, or Netscape Messenger for
  MS-Windows (or MacOS), or other proprietary mailers for legacy operating
  systems -- and visibly maintaining their Web sites using MS Front Page,
  Adobe Page Mill, or other junkware -- and hosting their LUG mailing
  lists on Yahoo Groups (formerly eGroups and Onelist, formerly MakeList)
  or Google Groups. Fortunately, these LUGs are in the minority, but they
  convey the message of Linux being suitable in neither desktop nor server
  roles.

  If you are going to promote and explore Linux, you need to _use it_.

Google Groups is not only proprietary software, but also _hosted_
proprietary software, i.e., you don't even have a copy of it in the
first place, nor do you host your data.


As a third FWIW, in the recent past, I helped Peter Knagg overcome the
obstacles to migrating PenLUG to an Exim4/SA-Exim/Mailman setup, and I
believe he's mighty pleased so far.

Anyway, as Dennis Miller used to say, 'But that's just my opinion.  I
could be wrong.'


[1] http://wendy.seltzer.org/blog/archives/2009/12/08/personalized-search-opacity.html
http://kitenet.net/~joey/blog/entry/adieu_google/




From excelblue at gmail.com  Wed Apr 20 13:56:42 2011
From: excelblue at gmail.com (Mark Lu)
Date: Wed, 20 Apr 2011 13:56:42 -0700
Subject: [buug] Reviving CalLUG
In-Reply-To: <20110420191535.GV26669@linuxmafia.com>
References: <20110420013306.GD26776@ykcyc>	<20110420144751.GM26669@linuxmafia.com>	<20110420182538.GA937@linuxmafia.com>	<BANLkTi=dCxvq-nPjeufYAoFbj2N_ApVQ_Q@mail.gmail.com>
	<20110420191535.GV26669@linuxmafia.com>
Message-ID: <4DAF488A.3020109@gmail.com>

Good point. I tend to be quite far on the practical end of things when 
it comes to the idealistic/practical spectrum, and the main thing on my 
mind was only how to get the mailing list accomplished in the simplest 
(but not necessarily best) way. Thanks for the reminder of something 
that may be very important for a huge portion of our target members.

In terms of access, I'd actually argue that there's no real disadvantage 
in running sessions in Dwinelle or Barrows, which are open until 
midnight and 11pm respectively, unlike Soda Hall, which is restricted by 
keycard after 6:30pm. They're accessible and provide for greater 
exposure to the general population.

On 04/20/2011 12:15 PM, Rick Moen wrote:
> Quoting Mark Lu (excelblue at gmail.com):
>
>> The real advantage to bringing back CalLUG is the ability to reserve
>> rooms on-campus for free.
> Yes, indeed.
>
> CalLUG got a lot of mileage out of that, tending to use Soda Hall for
> that.  There was a minor problem that access into the building was
> restricted after a certain hour.
>
>> I have experience with running my own Mailman, though, to be honest, I
>> think we should just look at registering a domain name and leeching
>> off Google Groups if we just want a list that works, is easily (and
>> publicly) searchable, and is reliable.
> I notice without objection your GMail address.  ;->   FWIW, some of us
> decline to turn over our computing lives to Google, Inc., and enjoy
> the functional advantages of being able to enforce our own policies,
> implement the sort of antispam _we_ want, not be subject to
> Google, Inc.'s takedown policies, not have to deal with yet more
> of Google, Inc.'s advertising and tracking[1], and so on.
>
> Also FWIW, http://linuxmafia.com/faq/Linux_PR/newlug.html points out
> another consideration:
>
>    23. Walk the walk.
>
>    It's painfully grotesque to see so-called Linux user groups mailing out
>    announcements using MS-Outlook, Eudora, or Netscape Messenger for
>    MS-Windows (or MacOS), or other proprietary mailers for legacy operating
>    systems -- and visibly maintaining their Web sites using MS Front Page,
>    Adobe Page Mill, or other junkware -- and hosting their LUG mailing
>    lists on Yahoo Groups (formerly eGroups and Onelist, formerly MakeList)
>    or Google Groups. Fortunately, these LUGs are in the minority, but they
>    convey the message of Linux being suitable in neither desktop nor server
>    roles.
>
>    If you are going to promote and explore Linux, you need to _use it_.
>
> Google Groups is not only proprietary software, but also _hosted_
> proprietary software, i.e., you don't even have a copy of it in the
> first place, nor do you host your data.
>
>
> As a third FWIW, in the recent past, I helped Peter Knagg overcome the
> obstacles to migrating PenLUG to an Exim4/SA-Exim/Mailman setup, and I
> believe he's mighty pleased so far.
>
> Anyway, as Dennis Miller used to say, 'But that's just my opinion.  I
> could be wrong.'
>
>
> [1] http://wendy.seltzer.org/blog/archives/2009/12/08/personalized-search-opacity.html
> http://kitenet.net/~joey/blog/entry/adieu_google/
>
>
> _______________________________________________
> Buug mailing list
> Buug at weak.org
> http://www.weak.org/mailman/listinfo/buug



From rick at linuxmafia.com  Wed Apr 20 14:10:53 2011
From: rick at linuxmafia.com (Rick Moen)
Date: Wed, 20 Apr 2011 14:10:53 -0700
Subject: [buug] Reviving CalLUG
In-Reply-To: <4DAF488A.3020109@gmail.com>
References: <20110420013306.GD26776@ykcyc>
	<20110420144751.GM26669@linuxmafia.com>
	<20110420182538.GA937@linuxmafia.com>
	<BANLkTi=dCxvq-nPjeufYAoFbj2N_ApVQ_Q@mail.gmail.com>
	<20110420191535.GV26669@linuxmafia.com>
	<4DAF488A.3020109@gmail.com>
Message-ID: <20110420211053.GA26669@linuxmafia.com>

Quoting Mark Lu (excelblue at gmail.com):

> Good point. I tend to be quite far on the practical end of things
> when it comes to the idealistic/practical spectrum....

Ahem.  It's vexing to see what I said shoehorned into an ideology box,
when that is the very opposite of what I thought I said.  Was I that
unclear?  If so, my apologies, and I'll fix that now:

Speaking for myself, I eschew hosted Internet services where I can,
instead, without significant problems, control and run them using
resources I control, for -=pragmatic=- reasons.  I consider surrendering
control of data and code to people I don't know and have no reason to
trust to be a very risky thing to do.  In business, to quote something
the guy I shave wrote on the subject for IDG back in 2001:

  An executive who allows his company to becomes dependent on software
  he is not allowed to see inside, let alone change, has lost control of
  his business, and is on the wrong side of a monopoly relationship with a
  vendor who can thereby control his business. With open source, the
  executive is in control, and nobody can take that away. The opportunity
  to reduce and control business risk is a key concern of any CEO. 

http://www.itworld.com/print/36449


> ...and the main thing on my mind was only how to get the mailing list
> accomplished in the simplest (but not necessarily best) way.

Then, I'm a bit confused, now.  Isn't the _simplest_ way to do nothing
and leave everyting on CalMail?  Why would a migration to Google Groups
(what you were just discussing) be simpler than doing nothing?

If, in the alternative, you _were_ proposing something that requires
more work than doing nothing at all, alternatives indeed include Google
Groups, but also include simple GNU Mailman installations such as I just
helped Peter Knagg migrate PenLUG's mailing list presence to (and helped
him migrate PenLUG's Apache/TWiki instance to Apache/FosWiki).  Which
has some seriously significant advantages over outsourcing to proprietary
(and hosted) software.

And that was really what I was saying.



> Thanks for the reminder of something that may be very important for a
> huge portion of our target members.

Yr. welcome.  Again, if it's ever desired to move the entire mailing
list with history included to a fully functioning Mailman instance, I 
can help.

> In terms of access, I'd actually argue that there's no real
> disadvantage in running sessions in Dwinelle or Barrows, which are
> open until midnight and 11pm respectively, unlike Soda Hall, which
> is restricted by keycard after 6:30pm. They're accessible and
> provide for greater exposure to the general population.

Good point.



From excelblue at gmail.com  Wed Apr 20 17:24:15 2011
From: excelblue at gmail.com (Mark Lu)
Date: Wed, 20 Apr 2011 17:24:15 -0700
Subject: [buug] Reviving CalLUG
In-Reply-To: <BANLkTim22m2ZKnniuCGbZQV9UFW01T1JBw@mail.gmail.com>
References: <20110420013306.GD26776@ykcyc>
	<20110420144751.GM26669@linuxmafia.com>
	<20110420182538.GA937@linuxmafia.com>
	<BANLkTi=dCxvq-nPjeufYAoFbj2N_ApVQ_Q@mail.gmail.com>
	<20110420191535.GV26669@linuxmafia.com>
	<4DAF488A.3020109@gmail.com>
	<20110420211053.GA26669@linuxmafia.com>
	<BANLkTim22m2ZKnniuCGbZQV9UFW01T1JBw@mail.gmail.com>
Message-ID: <BANLkTi=vvdn09rYS943vAnWRR7pB7aE3aw@mail.gmail.com>

On Wed, Apr 20, 2011 at 2:10 PM, Rick Moen <rick at linuxmafia.com> wrote:

> Ahem. ?It's vexing to see what I said shoehorned into an ideology box,
> when that is the very opposite of what I thought I said. ?Was I that
> unclear? ?If so, my apologies, and I'll fix that now:
>
> Speaking for myself, I eschew hosted Internet services where I can,
> instead, without significant problems, control and run them using
> resources I control, for -=pragmatic=- reasons. ?I consider surrendering
> control of data and code to people I don't know and have no reason to
> trust to be a very risky thing to do. ?In business, to quote something
> the guy I shave wrote on the subject for IDG back in 2001:
>
> ?An executive who allows his company to becomes dependent on software
> ?he is not allowed to see inside, let alone change, has lost control of
> ?his business, and is on the wrong side of a monopoly relationship with a
> ?vendor who can thereby control his business. With open source, the
> ?executive is in control, and nobody can take that away. The opportunity
> ?to reduce and control business risk is a key concern of any CEO.
>
> http://www.itworld.com/print/36449
>

I'd agree, it is a huge risk and leap of faith to use such hosted services,
but from my perspective, there's risks on both sides. The risks of running
your own resources include losing control if you were to get into a major
accident (eg. run over by a bus), having inadequate resources to maintain
the resources (eg. power surge at 2am), or in the case of an organization,
a member seizing control (eg. centos.org domain name incident).

While the consequences of the risks of losing control of data to an untrusted
corporation is much greater, I personally feel that the actual risks are much
less than the simple issues of running your own resources. My experience
shows that it just happens less often with untrusted corporations.

In short, it's just balancing something very risky with something more risky.
The bigger question is where to draw the line. One of the reasons why I
considered Google Groups is because the data on the mailing lists is
public anyways, and we have no monetary interest.

> Then, I'm a bit confused, now. ?Isn't the _simplest_ way to do nothing
> and leave everyting on CalMail? ?Why would a migration to Google Groups
> (what you were just discussing) be simpler than doing nothing?
>
> If, in the alternative, you _were_ proposing something that requires
> more work than doing nothing at all, alternatives indeed include Google
> Groups, but also include simple GNU Mailman installations such as I just
> helped Peter Knagg migrate PenLUG's mailing list presence to (and helped
> him migrate PenLUG's Apache/TWiki instance to Apache/FosWiki). ?Which
> has some seriously significant advantages over outsourcing to proprietary
> (and hosted) software.
>
> And that was really what I was saying.

As was mentioned earlier, the lack of public archiving in CalMail means that
it isn't fulfilling the requirements. Hence, it's thrown out of the
equation when
comparing simplest solutions that do fulfill the requirements.

Balancing out the advantages and disadvantages is a difficult topic. This
conversation has really gotten me thinking about the relative importance of
certain aspects as it pertains to a LUG.


-- 
Mark Lu


From pi at berkeley.edu  Wed Apr 20 18:24:47 2011
From: pi at berkeley.edu (Paul Ivanov)
Date: Wed, 20 Apr 2011 18:24:47 -0700
Subject: [buug] Reviving CalLUG
In-Reply-To: <BANLkTi=vvdn09rYS943vAnWRR7pB7aE3aw@mail.gmail.com>
References: <20110420013306.GD26776@ykcyc>
	<20110420144751.GM26669@linuxmafia.com>
	<20110420182538.GA937@linuxmafia.com>
	<BANLkTi=dCxvq-nPjeufYAoFbj2N_ApVQ_Q@mail.gmail.com>
	<20110420191535.GV26669@linuxmafia.com>
	<4DAF488A.3020109@gmail.com>
	<20110420211053.GA26669@linuxmafia.com>
	<BANLkTim22m2ZKnniuCGbZQV9UFW01T1JBw@mail.gmail.com>
	<BANLkTi=vvdn09rYS943vAnWRR7pB7aE3aw@mail.gmail.com>
Message-ID: <20110421012447.GB9018@ykcyc>


Some quick points - 

Mark Lu, on 2011-04-20 17:24,  wrote:
> On Wed, Apr 20, 2011 at 2:10 PM, Rick Moen <rick at linuxmafia.com> wrote:
> In short, it's just balancing something very risky with something more risky.
> The bigger question is where to draw the line. One of the reasons why I
> considered Google Groups is because the data on the mailing lists is
> public anyways, and we have no monetary interest.

We do not - but Google does - and to me this is one good reason
to use CalMail.

Another is that its an interface familiar to Berkeley affiliated
persons, and requires no additional steps on the side of the
user. (as far as I understand, there is no way to subscribe to a
google news group without a google account - this is not true of
a calmail mailing list - which anyone with an email address can
subscribe to).

> On Wed, Apr 20, 2011 at 2:10 PM, Rick Moen <rick at linuxmafia.com> wrote:
> > Then, I'm a bit confused, now. ?Isn't the _simplest_ way to do nothing
> > and leave everyting on CalMail? ?Why would a migration to Google Groups
> > (what you were just discussing) be simpler than doing nothing?

this is the plan. see the note about W6BB below.

Back to Mark, who wrote:
> As was mentioned earlier, the lack of public archiving in
> CalMail means that it isn't fulfilling the requirements. Hence,
> it's thrown out of the equation when comparing simplest
> solutions that do fulfill the requirements.

Let's not throw out the baby with the bath water - all we need is
to subscribe an additional address to the CalMail lists and have
the mail that account receives archived in a publicly accessible
place.

I think the biggest thing we gain from staying with calmail is
guaranteed continuity regardless of who's around as interest in
the group waxes and wanes over time.

Here's a concrete example: I'm part of W6BB - the Amateur Radio
club on campus, which is not currently a student organization,
but like CalLUG, has seen its ups and downs in terms of interest
and continuity over the years. 

In its most recent incarnation - it has been run using a non-UCB
server mailman installation for club communications - but
yesterday I discovered there WAS mailing list for the club which
is still operating thanks to UCB IST folks - it just looks like
the information for it has not been updated in 13 years! So I
subscribed to it, and sent an email out to both lists - and we've
already heard back from folks on that *ancient* list that didn't
know the latest incarnation of the club had moved on to a
different list - see "[W6BB] old club list
(circa 1998)" thread on [1].

Also, should we move over to the callug_discuss list, I worry we
might be dropping one of the vowels in this list's acronym, as
far as other folks are concerned ;)

1. http://w6bb.org/pipermail/w6bb_w6bb.org/2011-April/thread.html

-- 
Paul Ivanov
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://buug.org/pipermail/buug/attachments/20110420/0d08ba97/attachment.sig>

From rick at linuxmafia.com  Wed Apr 20 18:36:28 2011
From: rick at linuxmafia.com (Rick Moen)
Date: Wed, 20 Apr 2011 18:36:28 -0700
Subject: [buug] Reviving CalLUG
In-Reply-To: <BANLkTi=vvdn09rYS943vAnWRR7pB7aE3aw@mail.gmail.com>
References: <20110420013306.GD26776@ykcyc>
	<20110420144751.GM26669@linuxmafia.com>
	<20110420182538.GA937@linuxmafia.com>
	<BANLkTi=dCxvq-nPjeufYAoFbj2N_ApVQ_Q@mail.gmail.com>
	<20110420191535.GV26669@linuxmafia.com>
	<4DAF488A.3020109@gmail.com>
	<20110420211053.GA26669@linuxmafia.com>
	<BANLkTim22m2ZKnniuCGbZQV9UFW01T1JBw@mail.gmail.com>
	<BANLkTi=vvdn09rYS943vAnWRR7pB7aE3aw@mail.gmail.com>
Message-ID: <20110421013628.GI26669@linuxmafia.com>

Quoting Mark Lu (excelblue at gmail.com):

> I'd agree, it is a huge risk and leap of faith to use such hosted services,
> but from my perspective, there's risks on both sides. The risks of running
> your own resources include losing control if you were to get into a major
> accident (eg. run over by a bus)

Category of risk exists for both alternatives.

> having inadequate resources to maintain the resources (eg. power surge
> at 2am)

Category of risk exists for both alternatives.

> or in the case of an organization, a member seizing control (eg.
> centos.org domain name incident).

Category of risk exists for both alternatives.  (Except you're more than
reaching, anyway, as the continuity of the CentOS Project does not
depend on ownership of a particular DNS domain -- obviously.)

So, you've just made a handwave where you've asserted that these risks
are distinctive to controlling your own data and code as opposed to
outsourcing it to strangers you have no reason to trust, _but_ it turns
out that this is not true, as those threat models aren't distinct to one
mode of operation.

I hope this doesn't sound irritable, but I hope you're aware that I've
been doing analysis on these problems for some decades.  It'd be really,
really cool if I learned something new about it from a GMail-using
undergrad.  I'd really enjoy that.  But I'm not holding my breath.


> While the consequences of the risks of losing control of data to an
> untrusted corporation is much greater, I personally feel that the
> actual risks are much less than the simple issues of running your own
> resources. 

Yeah?  Tell that to Geocities
(http://www.pcworld.com/article/163765/so_long_geocities_we_forgot_you_still_existed.html),
TypePad (http://www.theregister.co.uk/2005/12/16/typepad_titsup/),
MySpace
(http://www.theregister.co.uk/2005/10/17/web20_worm_knocks_out_myspaces/),
Flickr
(http://www.theregister.co.uk/2005/04/14/flakey_flickr_fckd_again/),
weblogs.com
(http://www.theregister.co.uk/2004/06/15/winer_weblog_wipeout/),
Facebook
(http://www.cbsnews.com/stories/2010/05/08/earlyshow/saturday/main6469373.shtml),
Plaxo (http://www.rogerclarke.com/DV/ContactPITs.html), Blackberry
(http://ask.slashdot.org/story/06/01/26/1949243/Blackberry-Blackout-Threat-to-Software-as-Service),
and Google Maps
(http://www.oreillynet.com/mac/blog/2005/10/web_20_and_the_driveby_upgrade.html)
users.


> My experience shows that it just happens less often with untrusted
> corporations.

In _your_ experience?  Hmm.

I don't want to wave my figurative cane at you and tell you to get a
haircut, get off my lawn, and get a job, but... let me put it this way:
While attending high school I was in a computer user group that met at
the Stanford Linear Accelerator Center Auditorium.  A couple'a guys
named Steve showed off breadboarded computers there that they were
starting to sell under a goofy 1970s corporate name borrowed from a
fruit with a rainbow logo.  And I've basically been doing software,
first on an all-consuming amateur basis and then for a living, since
before you were born, I'll reckon.

To set the period:  My freshman-year entertainment in high school, where
I was the only liberal Democrat in a sea of rich, spoiled Republican
future fratboys, was Watergate.  Nixon got re-elected in the fall and I
said 'You'll be sorry.'  The man's campaign slogan 'Nixon's the one!'
soon came back to haunt him.

At said SLAC-located user group, we got a letter, sent by a pushy little
partnership in Albuquerque called 'Micro-Soft', complaining about abuse
of their crappy proprietary BASIC interpreter, passed along to us by
David Bunnell.  I said 'You know what?  Why don't we consign this Gates
person and his dodgy BASIC interpreter to the obscurity he deserves.  We
have other BASIC toolchains.  _Don't_ copy his.  Deliberately ignore
it.'  If they'd listened to me, maybe we'd have gotten the open source
renaissance 20 years earlier.  

But I was just a kid.  In 1976.
http://linuxmafia.com/faq/Legacy_Microsoft/altair-basic.html

And like that.  You get the picture.  Old.  Been around the block of the
software industry a bunch of times.

No offence intended or taken.



> In short, it's just balancing something very risky with something more
> risky.

Except you really didn't show that.

> The bigger question is where to draw the line.

Here you go.  Enjoy.  (My view; yours for a small royalty fee, as the
old joke goes.)

http://linuxmafia.com/faq/Essays/winolj.html  (Make sure you read the
'And Yet...' section before commenting, please.)

> One of the reasons why I considered Google Groups is because the data
> on the mailing lists is public anyways, and we have no monetary
> interest.

Yeah, so-called 'free' hosted / SaaS / Web 2.0 services are always
defended in terms of 'monetary interest' only, as if control of your
data and code, your privacy, your ability to enforce your own policy,
your autonomy, had no value.


> As was mentioned earlier, the lack of public archiving in CalMail
> means that it isn't fulfilling the requirements. Hence, it's thrown
> out of the equation when comparing simplest solutions that do fulfill
> the requirements.

True, Google Groups does give you public archiving.

So, by the way (in addition to obvious direct implementation of standard
Linux software, already mentioned), does asking a nearby LUG with a
Mailman instance to add your mailing list to the ones they already run.
E.g., Smaug of Santa Cruz has its mailing list hosted on SVLUG's Mailman
instance.  SF-LUG has its mailing list hosted on CABAL's Mailman
instance.

Both of those are actually easier than migrating to Google Groups.  And
you don't have to submit to the privacy (um...) cavity search and
arbitrary corporate policies of being a Google product.  (I say Google
'product' to remind people that, if you're using a 'free' service such
as GMail or Google Groups, you are not their customer:  You are product,
i.e., a personal targeted-marketing data source and captive advertising
target, that Google sells to its _actual_ customers.)



> Balancing out the advantages and disadvantages is a difficult topic.

Indeed.



From rick at linuxmafia.com  Wed Apr 20 18:38:45 2011
From: rick at linuxmafia.com (Rick Moen)
Date: Wed, 20 Apr 2011 18:38:45 -0700
Subject: [buug] Reviving CalLUG
In-Reply-To: <20110421012447.GB9018@ykcyc>
References: <20110420013306.GD26776@ykcyc>
	<20110420144751.GM26669@linuxmafia.com>
	<20110420182538.GA937@linuxmafia.com>
	<BANLkTi=dCxvq-nPjeufYAoFbj2N_ApVQ_Q@mail.gmail.com>
	<20110420191535.GV26669@linuxmafia.com>
	<4DAF488A.3020109@gmail.com>
	<20110420211053.GA26669@linuxmafia.com>
	<BANLkTim22m2ZKnniuCGbZQV9UFW01T1JBw@mail.gmail.com>
	<BANLkTi=vvdn09rYS943vAnWRR7pB7aE3aw@mail.gmail.com>
	<20110421012447.GB9018@ykcyc>
Message-ID: <20110421013845.GJ26669@linuxmafia.com>

Paul Ivanov wrote:

> Let's not throw out the baby with the bath water - all we need is
> to subscribe an additional address to the CalMail lists and have
> the mail that account receives archived in a publicly accessible
> place.

Suggestion: http://gmane.org/
http://gmane.org/subscribe.php



From khogoboom at gmail.com  Wed Apr 20 20:29:03 2011
From: khogoboom at gmail.com (Karen Hogoboom)
Date: Wed, 20 Apr 2011 20:29:03 -0700
Subject: [buug] politeness
Message-ID: <BANLkTikEB6H5ZhcN+77TNV+8CvpxE6gK9g@mail.gmail.com>

I notice that people who smoke pot a lot are very rude--they talk too long
and they interrup and they think it's funny.  A polite woman does not like
to be interrupted.  This is especially true of a polite, professional
computer programmer.   I notice that I am interruped a lot when I am talking
at buug.  I also notice that the men at buug ask me a lot of questions, but
don't wait for me to give a complete answer.  Instead, they interrupt and
talk to other men about something else instead or they force me to listen to
them, which is doubly rude.

I find the current people at buug to be rude.   Would you please educate
yourselves on how not to be rude to a polite woman?

Thanks.

Karen

----
Karen Lee Hogoboom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buug.org/pipermail/buug/attachments/20110420/99d5dff6/attachment.html>

From Michael.Paoli at cal.berkeley.edu  Wed Apr 20 22:23:14 2011
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Wed, 20 Apr 2011 22:23:14 -0700
Subject: [buug] CalLUG discussion at BUUG & Berkeley Linux Users Group
	meetings	(?) ...
In-Reply-To: <20110420144751.GM26669@linuxmafia.com>
References: <20110420144751.GM26669@linuxmafia.com>
Message-ID: <20110420222314.10805e8con2j2twc@webmail.rawbw.com>

CalLUG discussion at BUUG & Berkeley Linux Users Group meetings (?) ...

Anyway, I will be at this Thursday's BUUG meeting, and am interested in
discussing CalLUG with anyone that cares to ... but I may be departing
the meeting rather/quite early (about 7:45pm or so) - I've a conflicting
engagement later that evening that I'd also like to attend.

As for the next Berkeley Linux Users Group meeting, at the moment there
seems a slight implied ambiguity as to date.  I've not seen it mentioned
on that list ... *yet* (there's typically reminder sent by someone hours
to a few days before the meeting, that the meeting will be taking place,
etc.) ... but I think it quite likely that a bit (like a day or two or
so) before Sunday, that ambiguity will be rather quickly resolved.  The
present ambiguity being:
o those meetings are generally 2nd and 4th Sunday, such is practice and
   what the web site says
o this coming Sunday happens to be Easter Sunday
o nothing's been explicitly said about that on the list:
   http://groups.google.com/group/berkeleylug
   - yet - as far as I'm aware
o http://www.berkeleylug.com/?page_id=67 is semi-regularly updated, and
   presently indicates both:
   "We have meetings the 2nd and 4th Sundays of every month*" (asterisk
   apparently not referenced on that page), and:
   "Our Next Regular Meetings
   Dates: May 8, 22"
   and doesn't mention anything about skipping this Sunday.
Anyway, likely fairly soon, clarification(s) will appear on that LUGs
list and/or the URL noted above.  (Appears Bobby G's will be open
regular hours this Easter Sunday ... at least that's what the person
answering the phone I called there earlier this evening seemed to think
was the case).

references/excerpts:
http://www.weak.org/pipermail/buug/2011-April/003784.html
http://www.weak.org/pipermail/buug/2011-April/date.html

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [buug] Reviving CalLUG
> Date: Wed, 20 Apr 2011 07:47:51 -0700

> Quoting Paul Ivanov (pi at berkeley.edu):
>
>> Would you be able to make it to either the BUUG or BerkeleyLUG
>> meetings on Thursday and Sunday, respectively (see Michael's
>> notes on the matter below).
>
> Sorry to report, I have some conflicting commitments, and also need to
> do a whole lot of catch on matters have have waited while my wife and I
> were on holiday in Europe for a couple of weeks.
>
> Anyway, reverting to a prior subtopic_  I could write a book about
> characteristic psychopathologies of LUGs (and some of that is already in
> the Linux User Group HOWTO), which is a minor variation on the
> psychopathologies of geekdom generally.  One of the many things I notice
> -- which I mention because I'm sure it will come up -- is that LUG
> social circles tend to freeze collective action through endless
> debate.[1]  In particular, there's a strong tendency for the leadership
> to sit on their hands as long as anyone has any objection whatsoever to
> something that has been proposed or announced.
>
> [1] The Irony Fairy may strike me dead for saying this, but you will
> find that most useful input and participation, with a minimum of bizarre
> interference, gratuitous ideology, and impractical notions, comes from
> in-person interaction rather than from strangers talking at you over the
> Internet (says the stranger talking at you over the Internet).



From Michael.Paoli at cal.berkeley.edu  Thu Apr 21 18:01:19 2011
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Thu, 21 Apr 2011 18:01:19 -0700
Subject: [buug] CDs @ BUUG Thursday (tonight) (CDs until about 7:45 PM
	or so	anyway - I'll likely be departing the meeting early)
In-Reply-To: <20110303174316.14314wsrg63ezs84@webmail.rawbw.com>
References: <20110303174316.14314wsrg63ezs84@webmail.rawbw.com>
Message-ID: <20110421180119.12376gkpw3zgl0so@webmail.rawbw.com>

I'll be bringing CDs again.
For a list of what I've currently got, peek here:
http://www.wiki.balug.org/wiki/doku.php?id=balug:cds_and_images_etc
... but don't wait 'till too late tonight - I'm planning to leave the
meeting early this evening:
http://www.weak.org/pipermail/buug/2011-April/003796.html




From khogoboom at gmail.com  Fri Apr 22 08:37:12 2011
From: khogoboom at gmail.com (Karen Hogoboom)
Date: Fri, 22 Apr 2011 08:37:12 -0700
Subject: [buug] CalLUG discussion at BUUG & Berkeley Linux Users Group
 meetings (?) ...
In-Reply-To: <20110420222314.10805e8con2j2twc@webmail.rawbw.com>
References: <20110420144751.GM26669@linuxmafia.com>
	<20110420222314.10805e8con2j2twc@webmail.rawbw.com>
Message-ID: <BANLkTimMx5_cFvHGOq=7k_2B8Sjnnrgmow@mail.gmail.com>

> debate.[1]  In particular, there's a strong tendency for the leadership
>> to sit on their hands as long as anyone has any objection whatsoever to
>> something that has been proposed or announced.
>>
>>
Interesting.  Thanks for that observation and for all who managed to send it
to me.


> [1] The Irony Fairy may strike me dead for saying this, but you will
>> find that most useful input and participation, with a minimum of bizarre
>> interference, gratuitous ideology, and impractical notions, comes from
>> in-person interaction rather than from strangers talking at you over the
>> Internet (says the stranger talking at you over the Internet).
>>
>
Thanks for letting me know that there's an Irony Fairy.

Also, thanks for listening to me stand up and rant VERY LOUDLY rather than
take a leadership position the other night.

Also, shouldn't that be The Leadership, like The Government, like Big Agro,
like, The Administration, like The Management, and so on?

Karen


> _______________________________________________
> Buug mailing list
> Buug at weak.org
> http://www.weak.org/mailman/listinfo/buug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buug.org/pipermail/buug/attachments/20110422/e8e8d9f3/attachment.html>

From rick at linuxmafia.com  Fri Apr 22 09:44:22 2011
From: rick at linuxmafia.com (Rick Moen)
Date: Fri, 22 Apr 2011 09:44:22 -0700
Subject: [buug] CalLUG discussion at BUUG & Berkeley Linux Users Group
 meetings (?) ...
In-Reply-To: <BANLkTimMx5_cFvHGOq=7k_2B8Sjnnrgmow@mail.gmail.com>
References: <20110420144751.GM26669@linuxmafia.com>
	<20110420222314.10805e8con2j2twc@webmail.rawbw.com>
	<BANLkTimMx5_cFvHGOq=7k_2B8Sjnnrgmow@mail.gmail.com>
Message-ID: <20110422164422.GD26669@linuxmafia.com>

Quoting Karen Hogoboom (khogoboom at gmail.com):

> Also, thanks for listening to me stand up and rant VERY LOUDLY rather than
> take a leadership position the other night.

Hi, Karen.  I believe you must be thinking of someone else.
Unfortunately, I haven't been able to make it to a BUUG gathering in a
few years, and I'm reasonably certain we've never met.

I'm sorry to hear that someone stood up and ranted very loudly at the
meeting -- but it wasn't me.  And I'm extremely sympathetic to what you
were saying the other day about women attending technology events (not
just BUUG) getting interrupted and ignored.  I've seen it, and tried to
fix it.  It's a real, longtime problem, and I take it seriously.



From rick at linuxmafia.com  Mon Apr 25 11:10:13 2011
From: rick at linuxmafia.com (Rick Moen)
Date: Mon, 25 Apr 2011 11:10:13 -0700
Subject: [buug] vim (& "certain" Linux distributions) annoyances
In-Reply-To: <20110407012817.67216ci8sfxerl8o@webmail.rawbw.com>
References: <20110406195122.22397a9uzy5nnlc8@webmail.rawbw.com>
	<20110407042045.GF24166@ykcyc>
	<20110407012817.67216ci8sfxerl8o@webmail.rawbw.com>
Message-ID: <20110425181013.GP31278@linuxmafia.com>

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> Yes, rather true that.  Linux distributions that execute vim when one
> invokes the vi command, and that don't even provide [n]vi as an
> available package are quite annoying.

You know what's _really_ annoying in a text editor?  Only one level of
undo, and modal operation without any visual indication of what mode
you're in.

I also have to wonder about the notion of absolute compatibility with
Bill Joy's original vi in every obscure corner of text processing being de
rigeur, when any complex processing would go to awk / sed / perl / etc.



From togo at of.net  Mon Apr 25 11:16:17 2011
From: togo at of.net (Tony Godshall)
Date: Mon, 25 Apr 2011 11:16:17 -0700
Subject: [buug] vim (& "certain" Linux distributions) annoyances
In-Reply-To: <BANLkTi=kc+Uztjnj1Uv4xHRRDMJT8yL8Gg@mail.gmail.com>
References: <20110406195122.22397a9uzy5nnlc8@webmail.rawbw.com>
	<20110407042045.GF24166@ykcyc>
	<20110407012817.67216ci8sfxerl8o@webmail.rawbw.com>
	<87oc4hfvbp.fsf@matica.localdomain>
	<BANLkTi=kc+Uztjnj1Uv4xHRRDMJT8yL8Gg@mail.gmail.com>
Message-ID: <BANLkTin3_q51zg8rw=voLz2TfbEGfj-Bug@mail.gmail.com>

And now we know a little more about you than we did before.

Best Regards.


On Fri, Apr 8, 2011 at 06:59, Karen Hogoboom <khogoboom at gmail.com> wrote:
> I'm a woman and I've already volunteered and given away for free enough, so
> I'm not volunteering.
>
> On Thu, Apr 7, 2011 at 5:19 PM, Ian Zimmerman <itz at buug.org> wrote:
>>
>> Michael> Oh yeah, ... and some other serious vim annoyances ... but I'll
>> Michael> add 'em to my list and save 'em for another time ;-).
>>
>> Someone should post a similar list for nvi, LOL. ?I am not volunteering,
>> but the way it handles keypad and cursor keys (ie. it doesn't) would be
>> a start.
>>
>> --
>> Ian Zimmerman <itz at buug.org>
>> gpg public key: 1024D/C6FF61AD
>> fingerprint: 66DC D68F 5C1B 4D71 2EE5 ?BD03 8A00 786C C6FF 61AD
>> Ham is for reading, not for eating.
>>
>> _______________________________________________
>> Buug mailing list
>> Buug at weak.org
>> http://www.weak.org/mailman/listinfo/buug
>
>
> _______________________________________________
> Buug mailing list
> Buug at weak.org
> http://www.weak.org/mailman/listinfo/buug
>
>


From rick at linuxmafia.com  Mon Apr 25 11:18:52 2011
From: rick at linuxmafia.com (Rick Moen)
Date: Mon, 25 Apr 2011 11:18:52 -0700
Subject: [buug] vim annoyances
In-Reply-To: <20110406195122.22397a9uzy5nnlc8@webmail.rawbw.com>
References: <20110406195122.22397a9uzy5nnlc8@webmail.rawbw.com>
Message-ID: <20110425181852.GQ31278@linuxmafia.com>

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> vim never ceases to annoy me:

Here, let me fix that for you.

$ mkdir ~/bin
$ cd
$ wget https://sites.google.com/a/bostic.com/keithbostic/files/nvi-1.79.tar.gz
$ tar xzf nvi-1.79.tar.gz
$ cd nvi-1.79
$ ./configure
$ make
$ cp bin/vi ~/bin
$ echo "alias ls='~/bin/vi'" >> ~.bashrc
$ . ~/.bashrc


From togo at of.net  Mon Apr 25 11:27:51 2011
From: togo at of.net (Tony Godshall)
Date: Mon, 25 Apr 2011 11:27:51 -0700
Subject: [buug] vim annoyances
In-Reply-To: <20110425181852.GQ31278@linuxmafia.com>
References: <20110406195122.22397a9uzy5nnlc8@webmail.rawbw.com>
	<20110425181852.GQ31278@linuxmafia.com>
Message-ID: <BANLkTimuqydobP84ZQEiBKoYryQwpgvGQg@mail.gmail.com>

>> vim never ceases to annoy me:
>
> Here, let me fix that for you.
...
> $ echo "alias ls='~/bin/vi'" >> ~.bashrc

Did you mean "alias vi=" in the above?

Or were you playing a joke on Michael?

Good defense of vim, BTW in the other
thread, BTW.  Haven't used nvi since I found
vim didn't put me into a wierd mode that I
used to get stuck in all the time with nvi.
Something like escape up-arrow in insert
mode but not something I've ever been
able to replicate on purpose.

Best Regards.



On Mon, Apr 25, 2011 at 11:18, Rick Moen <rick at linuxmafia.com> wrote:
> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
>> vim never ceases to annoy me:
>
> Here, let me fix that for you.
>
> $ mkdir ~/bin
> $ cd
> $ wget https://sites.google.com/a/bostic.com/keithbostic/files/nvi-1.79.tar.gz
> $ tar xzf nvi-1.79.tar.gz
> $ cd nvi-1.79
> $ ./configure
> $ make
> $ cp bin/vi ~/bin
> $ echo "alias ls='~/bin/vi'" >> ~.bashrc
> $ . ~/.bashrc
> _______________________________________________
> Buug mailing list
> Buug at weak.org
> http://www.weak.org/mailman/listinfo/buug
>


From rick at linuxmafia.com  Mon Apr 25 11:33:03 2011
From: rick at linuxmafia.com (Rick Moen)
Date: Mon, 25 Apr 2011 11:33:03 -0700
Subject: [buug] vim annoyances
In-Reply-To: <BANLkTimuqydobP84ZQEiBKoYryQwpgvGQg@mail.gmail.com>
References: <20110406195122.22397a9uzy5nnlc8@webmail.rawbw.com>
	<20110425181852.GQ31278@linuxmafia.com>
	<BANLkTimuqydobP84ZQEiBKoYryQwpgvGQg@mail.gmail.com>
Message-ID: <20110425183303.GS31278@linuxmafia.com>

Quoting Tony Godshall (togo at of.net):

> Did you mean "alias vi=" in the above?

Yeah, sorry, copied and pasted from an old .bashrc, and didn't edit that
out.

And no, I didn't download Bostic's tarball to make sure the rest of it
was achingly correct, either.  That was rhetoric, not a recipe.