[conspire] List(s) of ~SF Bay Area [Linux+-] User Groups, etc. (& SF Bay Area Open Source/Linux Events)

[Rick Moen]

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

> And, other lists, ... well, here's my "list of lists" - the very last
> of which is just a much shorter URL to the URL immediately above it:
> http://linuxmafia.com/bale/
> http://www.lugod.org/calendar/
> http://www.svlug.org/farm.php#other-local
> https://wiki.ubuntu.com/CaliforniaTeam/Projects/UserGroupContacts/Groups#SF
> https://www.google.com/calendar/embed?src=caj9iea2ol69b7n2uqdek4ocso%40group.calendar.google.com&ctz=America/Los_Angeles
> https://goo.gl/b9WY5k

Good work, there.  (FWIW, the SVLUG 'farm' page I also maintain,
manually.)

> I think Bill Ward "owns" (notwithstanding Google) that calendar,
> there may be other co-owners ... or not (or insufficient active),
> that might become a problem at some point in time.

Yes, Bill founded it, and then has shared edit access with a number of 
other people having Google Accounts.  (Me, I decline to outsource 
computing and hosting to Google, considering that abysmal policy for a
number of obvious reasons.)

IIRC, the immediate beef was that someone, perhaps Bill, had wanted BALE
to include ongoing coverage of something I thought was stupid.  (It
might have been BerkeleyTIP / BerkeleyITP / GlobalTIP of the
ever-changing name that is now defunct because its alleged organiser
suddenly walked away from it suddenly and without explanation, having,
not coincidentally, hosted absolutely everything on Google Sites and
Google Groups and never allowed anyone else administrative access to
anything.)  My response at the time was 'Gee, open source means everyone
can be a publisher, but not everyone needs to be a publisher on
linuxmafia.com.  Here's Autobale; it's GPLv2+; Have a Lot of Fun.[tm]'

(Autobale is the scripting, SQL schema, and template files that run
BALE, with documentation:  http://linuxmafia.com/pub/linux/network/ 
All thanks for it should go to Deirdre, the designer and coder.)

Bill has never been particularly technical, but I don't want to be
unfair and say he couldn't handle that, so he presumably had compelling
reasons to outsource everything to Google hosting and proprietary code;
I just happen to strongly disagree with the appropriateness of so doing,
particularly on account of the message this sends, suggesting that Linux 
enthusiasts cannot bother doing the one thing Linux is famously best at,
which is housing and managing Internet content.


As an aside, I'm a longtime admirer of the LUGOD pages.  At one point, I
asked the LUGOD officers if the underlying code, in particular the stuff
that generates iCalendar data, were available.  The answer I got was a
bit puzzling, and I cannot recall why they were unable to provide it as
a working example.

In the past, I've put a couple of days' work into an export function of
BALE data into iCalendar.  ISTR it was tantalisingly close to correct.
Fortunately, that file format (RFC 5545) is pretty darned orderly and,
FWIW, based on a similarly semi-obscure Internet standard, vCalendar.

I also seem to recall, in the middle of that work, remembering two
common structural problems of the open source community:  (1) People
deciding to move the goalposts.  (2) People deciding to play rugby 
when you'd been told the game was soccer.  Here's what I mean:

Great, I see you're offering a downloadable .ics file!  Can you please
also offer xCal?  I'm an XML nut.  Oh, and also jCal, as I'm going JSON
stuff.  Oh, and hCalendar.   (Why, you ask?  No special reason.  I'm
just collecting the whole set of obscure microformats.)

Oh, and why aren't you offering an automated subscription to that data
using RSS 2.0?  And also RSS 0.91 and 1.0, since all of those are
somewhat mutually incompatible?  And also Atom?  What do you mean,
you're not running Drupal?  Isn't everyone?  

Oh, and what aren't you offering CalDAV access?  And publishing Webcal
URIs?  Oh, and do you have tested access methods for all of my various
mutually incompatible smartphone devices?  I need everyting to sync with
everything else, and I don't want to have to install or configure
anything.  Also, I'd like a pony, please.  Prefaeably a blue one.

Those are the 'move the goalposts' examples one expects to hear (and in
fact does hear). The 'people suddenly playing rugby when you'd been lead
to expect soccer' bit is even more hilariously dysfunctional:

You deploy iCalendar data possibly with some of the above accompanying
cloud of aspiring ancillary technologies, making about two or three
people on the Internet briefly happy -- but then you hear from _most_
querents 'Well, that's nice, and I know it's what we said we wanted, but
we don't actually use any of that.  Why aren't you continuously updating
to Google Calendar?  That's what we _really_ want.'


Which is to say, you do a bit of digging among technical users:  'Hi, I
know you want better calendar data in open formats, so I'm doing a
little survey about what calendar client application(s) you're using
lately.  I know you said Mozilla Sunbird, but that was a one-time proof
of concept in 2003 that's been orphaned since 2010.  It wasa buggy but
promising XUL extension stapled onto a big honkin' Mozilla runtime
engine.  Don't tell me you're still running that?'

'What's that?  Oh, yes, I know they replaced it with a separate XUL
extension called Lightning, which now is usable only as part of
Thunderbird or SeaMonkey, especially now that Firefox has dropped XUL
support.  So, you're using that?  What do you mean, "not actually"?'

(Aside:  A better and modern alternative is a nice little gtk+ app
called Orage, maintained by the XFCE4 people.
https://packages.debian.org/stable/orage )

'Yes, I know a bunch of big groupware apps can deal in some form of
iCalendar.  IBM (ex-Lotus) Notes, Microsoft Outlook, Apple Calendar, and
Novell GroupWise.  Seriously?  Don't tell me you use GroupWise?'

'What's that?  You just use your Web browser?  How is that possible?
Web browsers don't have any native ability to deal with iCalendar or any
other form of calendar/event data.'

'Oh, you just point your Web browser at https://calendar.google.com/ 
and login using your Google Account.  Got it.  So, in truth, you have 
no actual interest in _any_ calendar data format, _any_
calendar/scheduling client application, or _any_ specialised access
protocol.  You just want, so to speak, everyone to be on AOL because
everyone's on AOL.'


Aside:  Deirdre informs me that RSS is now functionally dead because
the huge majority of its users silently decamped to sucking off
Facebook, and then Web browsers dropped integrated RSS support.
(I suspect that the four mutually incompatible news-syndication formats,
three of them called 'RSS', didn't help.  Also, the writing was on the
wall, early, on, when it turned out that 99.99% of RSS users didn't
bother to subscribe to individual feeds, but were totally dependent on
one of a couple of big 'news aggregator' Web sites.  It was a short and
lazy jump from there to 'Just use an HTML5 Web browser and connect to a
big corporate AJAXey Web site.'  Because most people are lazy and go
after bright shiny objects.)




> I updated NBLUG's location retroactive to meeting earlier this month.



FWIW, I tend to catch up with BALE updating in big infrquent hours-long
pushes, because it's something of a pain in the tochis.  The most recent
catchup was when David Wolfskill asked me to do so, a couple of months
ago, because Bay Area FreeBSD User Group had changed meeting locations
again.

Of course, as you mention, NBLUG just now moved from O'Reilly Media in
Sebastopol to Sonic in Santa Rosa, so I'll need to do it again.
{grumble}


Throw me a bone, if you can:  In the current BALE data set, is anything
_except_ NBLUG's meeting venue out of date, to your knowledge?  That's
all I'm aware of, without doing an actual verification run.


Back to Google Calendar for a moment:  (And, by the way, aside from being
proprietary hosted software and a monopoly of the second most nosy
company on the planet, I do like the thing.)  Because of its popularity,
a whole bunch of open source projects over many years tried in various
ways to approach feature parity with Google's site -- usually involving
or resulting in various really dreadful groupware code-hairballs, many
of which were or are scary-as-fsck PHP security-disasters-in-the-making.

I covered the resulting incrementally unfolding follies here, a year back:
http://lists.svlug.org/archives/svlug/2018-January/062504.html
http://lists.svlug.org/archives/svlug/2018-January/062505.html
http://lists.svlug.org/archives/svlug/2018-January/062506.html

It turned out -- quelle surprise! -- that feature-matching everything in
Google Calendar, particularly the AJAX-ey live-access stuff, is a big
blunder that results in stupefyingly overcomplex and horribly performing
code, and that a smarter approach is to massively reduce the feature set
by dropping _all_ the dynamic-Web-editing stuff and just hosting ultiple
users' iCalendar (*.ics) files (using CalDAV protocol) and vCard v. 3.0
(*.vcf) address books / virtual business card files (using CardDAV
protocol).  As I mentioned, the brilliant result of doing so is a small
Python Web app called Radicale -- and it's small/fast enough to
comfortably run on a Raspberry Pi Web server.

I keep being tempted to complete/test that iCalendar connection for the
BALE data and host an instance of Radicale.  My main concern is that a
lot of people will ignore anything that's not on AOL (I mean, Google).

I might add Ubuntu Hour San Francisco to BALE, and have often considered
doing so, even though it's functionally just 'Hey, let's have an
Ubuntu-centric schmooze session just before a Bay Area Debian meeting 
at a coffee shop a block away', almost exclusively.  But, wen push comes
to shove, BALE has always been 'Technical events related to Linux and
open source that Rick Moen finds interesting', and always has been.  For
people who don't like that, I've happily offered autobale-1.0.tar.gz for
ages, but no takers to my knowledge.


About BALE:  In 2016, I refactored BALE (and updated the tarball) to
cure its initial mis-design of dynamically assembling the page from a
flurry of MySQL calls on every single page load, even though the page
remains unchanged for a month at a time.  I also converted it from
pointlessly dynamic PHP5 to a static page generated by cron job on the
first of every month using local /usr/bin/php5.

Its reliance on MySQL has always been overengineering, as well.  Heck,
BALE doesn't even need concurrency.  Even SQLite would be mild overkill.
I could probably do without a database entirely, and just make it
assemble the page using an automake Makefile, some verbatim HTML
template snippets stored in a tree of small flat files, and Deirdre's
Python code for date calculations (the difficult part).