[volunteers] [svlug] Linux to Politics ratio
daniel at gimpelevich.san-francisco.ca.us
Sun Dec 2 01:22:02 PST 2007
On Sun, 02 Dec 2007 00:21:01 -0800, Rick Moen wrote:
> Quoting Daniel Gimpelevich (daniel at gimpelevich.san-francisco.ca.us):
>> On Sat, 01 Dec 2007 18:58:54 -0800, Lisa wrote:
>> > I disagree. My opinion is that, if the mail and the webserver
>> > are on two different machines we are *better* off because if the
>> > most unreliable machine we have dies, we still have the
>> > webserver running (where we can explain why the mailing list is
>> > down) and, if linnode crashes (doubtful that that would happen
>> > for long), we'd have the mailing list to explain why the website
>> > is down. Whereas, as it is now, if the most unreliable machine
>> > we have dies, we lose BOTH.
>> No, because while the new website would not be a souped-up reinstallation
>> of the old website setup, the mailing list stuff would be pretty much that
>> at first and is in more immediate need of migration than the website. Once
>> the Linode host takes over in exactly the capacity in which the current
>> host is serving, the current host may be repurposed for a time as the new
>> home of the website, and the multiple-basket scenario you're preferring
>> could still happen. Would this still be consistent with the agreement you
> The moves of (1) all mail including Mailman and (2) non-Mailman webstuff
> off the old svlug.svlug.org host are entirely _orthogonal_ issues. The
Yes, as I agreed in my message.
> Phase Two: Use the VA Linux 2230 box at Via.net to create a Mailman and
> SMTP host, copy over the Mailman and Exim mbox files and the Mailman
> list definitions and subscriber lists, regenerate the archives
> (preferably incorporating for the first time the pre-Mailman majordomo
> archive that has been preserved but never webified), and cut over the
> DNS for "lists.svlug.org" and "svlug.org" to it, shorting TTL in advance
> to reduce caching problems.
Yes, I also agreed to this immediately after it was decided. At the time,
it would have been the most efficient use of LUG resources. I didn't need
convincing then that this was true, but I would now.
> For Phase Two to be possible, we'll need to regain access to the VA
> Linux box, which reportedly got diverted for Paul's secret project at
I predict that this sub-issue may trigger yet more acrimony...
> Heather's house, resulting in our being startled to find that it no
> longer responded to ping at its Via.net IP address, and in the need to
> track down where it had gone without informing anyone.
>> > That would be nice, but I think 1/2 is better than nothing. Wouldn't
>> > it make sense to get some other opinions on this?
>> And two halves are better than one.
> Daniel, you are new to this conversation, and completely missed the
> precding analysis -- the analysis Paul discarded when he threw away what
> we agreed to at Black Angus. But you are fundamentally mistaken in your
> apparent belief that there is any reason to tie one project to the
To repeat myself from a message of just hours ago: All-or-nothing is not
justified at all. This may be paraphrased as "there is no reason to tie
one project to the other."
>> AIUI, its flakiness is almost exclusively a function of the way it's
>> being used and the way it was set up. I was one of the people who
>> chanted the wiki mantra, but always in the context of hearing "there's
>> nothing the Linode host can do beyond DNS."
> I have no idea who was saying that, but whoever that was, was
> In January, Lisa got Linode to pump up the allocated resources from 80MB
> RAM to 256 MB, and disk from 3072 MB to (IIRC) 8 GB (or maybe 5 GB,
I repeat, I was unaware of this until today, and I doubt I was alone.
> OTOH, the newer Linode resources are actually feasible for all SVLUG
> services, if barely. (I still recommend migrating Mailman + SMTP to a
> different box.)
Ditto there. Using Linode for all SVLUG services in the short-term interim
would be more than ideal. To address Lisa's very valid concern, the
current svlug.svlug.org, once decommissioned and reconstituted (which I
could help with), could serve as a failover, but only for the website.
>>>> We want to replace the existing static,
>>>> log-in-to-edit-files-from-the-command-line website solution with a
>>>> wiki for obvious reasons.
> This is the J. Paul Reed assertion, and it's _still_ nonsense. Argh!
>> Of course moving the website alone is not worth not doing....
> It _is_ worth doing as Phase One. See above.
Yes, reread the line of mine that you just quoted.
> Daniel, I hope I'm not coming across as impatient, but this really is
> something we've already gone through an extremely large number of times.
> It's all over the earlier archives of this mailing list, for example.
>> I don't know exactly who rejected that, but remember: Ideas never die.
> Ideas (and plans, and agreements) that get ignored might as well be
Hmm, nice mass grave you've prepared for them, there...
More information about the volunteers