sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
Re: [SM-Discuss] Popularity, visibility, and level of involvement
- From: Jeremy Blosser <jblosser-smgl AT firinn.org>
- To: sm-discuss AT lists.ibiblio.org
- Subject: Re: [SM-Discuss] Popularity, visibility, and level of involvement
- Date: Thu, 8 Oct 2015 11:03:11 -0500
On Oct 08, Vlad Glagolev [stealth AT tiberian.ru] wrote:
> On Wed, 7 Oct 2015 14:28:17 -0500
> Jeremy Blosser <jblosser-smgl AT firinn.org> wrote:
>
> > On Oct 07, Vlad Glagolev [stealth AT tiberian.ru] wrote:
> > > Except now all primary distro resources are on both my and sobukus[0]
> > > servers'.
> >
> > No, the secondary resources are there. The things that hold the primary
> > scm data and that the distro tools point to are primary, the things those
> > things redirect to are secondary. This is why when we lost DBG, for
> > example, we were easily able to repoint everything to other resources.
> > And
> > if your nodes go away, we'd be able to do the same.
>
> You're saying that the hardware you pay for is primary, and along with
> that ours -- isn't, simply because it's not in your control.
This is both wrong and backwards.
The distro (not me, no matter how many times here you want to pretend I'm
acting as a lone wolf to inflame the conversation, it won't make it true)
decided many years ago it wanted to have a community approach to the server
resources. That is, we wanted to move from taking advantage of the simple
offers to run primary things off various dev's resources (which are prone
to zero access to fix problems when they go down) and instead have hosting
resources the distro as a whole controls. And then have a design for
hosting that puts the primary resources there, so it's always where we can
work with it, and takes advantage of the donated stuff by just using it to
distribute load.
And yes, distro control, not my control. We're not a 501(c) org or other
official entity to actually have it in the entity's name, or we would, but
by definition the PL and their designees at least always have as much full
access to these resources as can be accomplished without that.
Historically the CLs have had at least shell access, though with the
decline in people contributing the notion of CLs has nearly gone out the
window. And if the distro at any time adopted a policy requiring some
other access model, it *would be implemented*, regardless of what as I an
individual thought of it. The only caveat there being since it is in my
name if I had significant conerns about it opening me up to liability
(like, for example, if the distro voted to go all RMS and do away with user
passwords or something), I would likely hand the ownership keys off to
someone else and get out of the way.
I know this history pre-dates your involvement but feel to go read the
archives, it's all there.
> But without sobukus' mirror there wouldn't be any ability for our users
> to download grimoires and code.
This is flatly not true. The final contingency case if we don't have other
secondary donated resources to distribute the load has *always* been to
host it directly off the primary. We don't do this when we have other
offers because those secondary ones usually have different data cap models
that are better suited to be software mirrors, but when we have to do it,
we can.
There have been like a half dozen (at least) of these secondary distributed
resources we've moved between as the offers have come and gone over the
years. ibiblio, DBG, various developer machines (seth, andrew, david, you,
etc.).
> You call this hardware alien, but for our users this is the _only_
> hardware they get anything from us.
More inflammatory nonsense. It's not "alien", it's a resource the distro
has no visibility into or way to manage if needed. That's all I've ever
said.
> We're paying for our servers the same as you do for yours and call it
> distro's.
It's not the distro's because of how it's paid for, it's the distro's
because the distro decided to create the resource and put things there and
has never opted to change its mind. It *does* have to get paid for, like
anything, and lately I happen to do that. But that has nothing to do with
the distro's decision to put stuff somewhere. You may as well make the
claim I'm only calling the name the distro's because I also happen to pay
for the registration of it.
> We participate in distribution of the sources the same way, and have
> right to call them "distro's" as well, because they're primary nodes for
> our users to get the code;
No, you don't have a right to call them the distro's, only the distro has
the right to call something the distro's. The distro is neither me nor
you. Me calling these resources "the distro's" and yours not is not some
ego talking, it's a meaningful distinction on who by policy controls the
thing.
> not that mystic master server that is not visible to anyone.
Our primary server resources are only slightly more "mystic" than our IRC
channels. They're where they have been for years, people interact with
them daily, whomever the distro says should have access to them has it.
> We're all the same since we provide our own resources for the project.
> We do not have US visas, and instant access to that TX (or not?) datacenter
> if it's *the distro's* hardware you're calling. Do we?
As a practical matter people not in the physical area of the hardware are
going to have problems getting to it, the same as I would have problems
getting to your stuff. But see above, the distro has every bit as much
direct access as can be provided and has been requested. To deal with the
physical distribution as well as the fact often the distro people haven't
been as sysadmin savvy as needed (this obviously varies with the person),
I've also historically provided contacts to other sysadmins in the physical
area who are SMGL-friendly and have access to fill in for me, because
again, the distro wanted it that way.
Maybe you just didn't realize this is how it really is?
> If it's about some dedicated stuff, and not colocation stuff, we do not
> have access to the control panel to reboot, ask for maintenance and so
> on. There's only one key,
You as an individual may not currently have it and maybe that's a
frustration for you but I'm not the only one that does, or the only one
that could. Given the general level of involvement in the distro it's
lately been just as quick for me to get to issues as anyone else but if
that ever wasn't the case David or Dave or the other Dave would be able to
get in. At least David has that contact info available, because he's the
PL. Before him I had that info, because I was the PL, and before him Eric
had it, because he was the PL. Their various assistants have also had that
info over the years if that's what they were designated to assist with.
If the distro today wanted to vote on a policy for that access and provide
me a list, I would implement that list. That's what "distro ownership"
means.
But I'm glad you understand the need to have distributed keys so well,
because that is my entire point. Things the distro relies on as primary
sources (not things that just distribute the load) need to have the keys in
the distro's control, not one person's.
> and it doesn't seem to be very stable -- I'm
> talking about reliability: because of lack of proper mirroring our
> infrastructure is in awful state, and you say "hell no, we don't need
> to have mirrors!". I find it _very_ non-professional.
>
> But you've chosen to trash any user experience with our new website for
> such long period of time. You prefer it that way, I see.
Vent however you need to that makes you feel better, man. I won't pretend
stuff isn't in disrepair, but I also won't call rational claims it's any
worse than the state of having a current ISO, or a developed sorcery, or a
maintained and tested stable grimoire.
> First, spent several months for nothing. Now you're providing pretty
> senseless arguments to "protect" "the distro's" "future" from the
> non-controllable environment, which has been up and running and
> dedicated to *the project* for almost one year (the mirror(s) with
> some parts of codex, sorcery, isos -- for 5+ years, though).
>
> That's insane, and definitely shows what does this project mean to
> you, when in a name of invisible protection you can sink it without
> thinking how could that decision affect the future of the project.
The request you put the stuff on the distro's server or give us the data so
we can do it for you is about as simple and standard as they come. I'm not
the one throwing fits instead of just doing that, but call what names you
want. This is a heckuva drawn out discussion resuling from a simple
request to put the files where the distro can get to them if needed.
> > It's on a VM, right? Just get me the whole chroot tarball and I'll just
> > put that up on freki.
>
> I would do that myself instead, but no, it just uses resources from one
> of my servers with configuration of everything. It's not that isolated
> thing.
So not only would the distro not have ability to maintain it if you were
hit by a bus, that's not even likely to change, because it's not a
dedicated resource. And you think I'm the one insisting on individual
control?
> But if we speak of bugs.sourcemage.ru, then yes, it's on a VM as I
> mentioned in May[0].
I haven't seen as much interest in that as the www site but if the distro
(via the PL or other method) agrees they want that one as the bugtracker
then sure, send me the tarball and we'll get it up.
> > > > > So I still propose to set up temporary proxying from at least
> > > > > sourcemage.org and www.sourcemage.org hosts and/or change DNS
> > > > > records
> > > > > instead of wasting even more time.
> > > >
> > > > If you currently don't have the time to do the migration, how do you
> > > > have
> > > > the time to maintain it on your hardware?
> > >
> > > It doesn't need what you call maintenance or "maintenance" that happens
> > > to our current distro infrastructure. Once properly set up, it just
> > > works with cosmetic updates of some stuff -- so it doesn't take much
> > > time.
> >
> > This is an odd claim to make given your other complaints about the current
> > infrastructure below. Infrastructure always requires maintenance over
> > time
> > or it degrades. Our current stuff is not in disrepair because it's overly
> > complex or requires specialized knowledge, like everything else in this
> > distro it's in disrepair because of lack of people helping, and lack of
> > time from those that help. Over years your setup will show the same
> > problems without regular maintenance, let alone what happens without
> > regular security updates.
>
> And that's what I was talking about[1]. My setup is already "over
> years", in many places, up to 10 years in a very good shape.
>
> I'll tell you a secret: that's about who uses and wants to use it.
> Everything will be fine if you're involved in development and use stuff,
> and rotten (what we see now) if you're not really interested. That's not
> about lack of people, but about lack of interest from your own side.
Except that I'm never claiming to be the only one to manage the distro
server resources, or making it rely on just my time. Staying away from
that model is pretty much the point, and why I'm not willing to just point
the DNS at your thing that is on your box with other things and only you
control. Where we have things now is in disrepair but it's a shared
resource, the distro is in charge of how it's managed and anyone in the
distro can get in and help with it, whether they do or not is another
issue. That's the secret to let it go on even if the person who was doing
it has less time. Again, just like sorcery, or codex, or iso.
Attachment:
pgpIj4Nq8zuJ7.pgp
Description: PGP signature
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement
, (continued)
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Thomas Orgis, 10/05/2015
- Re: [SM-Discuss] Popularity, visibility, and level of involvement, Sukneet Basuta, 10/05/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Ismael Luceno, 10/07/2015
- Re: [SM-Discuss] Popularity, visibility, and level of involvement, Kevin Monceaux, 10/07/2015
- Re: [SM-Discuss] Popularity, visibility, and level of involvement, Jeremy Blosser, 10/07/2015
- Re: [SM-Discuss] Popularity, visibility, and level of involvement, Jeremy Blosser, 10/03/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Jeremy Blosser, 10/03/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Vlad Glagolev, 10/07/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Jeremy Blosser, 10/07/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Vlad Glagolev, 10/08/2015
- Re: [SM-Discuss] Popularity, visibility, and level of involvement, Jeremy Blosser, 10/08/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Vlad Glagolev, 10/08/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Jeremy Blosser, 10/07/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Vlad Glagolev, 10/07/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Thomas Orgis, 10/05/2015
Archive powered by MHonArc 2.6.24.