Re: [gentoo-dev] Mailing list moderation and community openness

[Gregory Woodbury]

John Levine, author of "The Internet For Dummies," once set up a robo-moderation
process for the Usenet newsgroup soc.religion.unitarian-univ
(Unitarian Universalists).
The group, along with most of Usenet, ultimately "died" due to lack of
attention from
the moderators, who failed to curb one of their own.

However, the robo-moderator worked quite well, and still is
technically in-place. The
first post by a person generated an email to the poster to verify the
email addres,
and required the poster to reply with a confirmation. The posts then
went through
without anyone having to approve or whilelist things.  If a poster subsequently
became a "problem" their postings could be placed in a moderation
required status,
and some human would evelute the posts and handle the quelling of off-topic or
flame generating posts. In extreme cases, posters could be banned for
varying periods
of time.

The programs where quite powerful, and amazingly simple and elegant to implent.
The source is available, and should be easily adapted for practically
any system with
bash shell hook capabilities. The infra team might want to look at
that code and try
something like it.  Some addresses can be injected at setup time requiring human
action before posts are approved (Rejected posts would be sent back to the perp
requesting re-writing or abandoning.

The moderators did not have to login anywhere to work with the bot,
all interactions
were done via email.  The system is/was quite nice, and my mangled memories
should not be the deciding factors when looking at it.

Such a system might well serve as a means of allowing fully free entry into the
list, while still providing the ability to control things if it gets
out of hand.

On Wed, Mar 21, 2018 at 1:19 PM, Rich Freeman  wrote:
> On Wed, Mar 21, 2018 at 12:55 PM, R0b0t1  wrote:
>>
>> I can't tell, and I suspect other people can't either.
>>
>
> This is the crux of the issue.  Decisions involving people issues are
> made behind closed doors, which means that others are not free to
> confirm for themselves whether those actions are correct.  This tends
> to lead to ongoing debate over whether those decisions were
> appropriate, with everybody arguing from their own knowledge, and the
> only ones who know the information used to make the decision are
> barred from talking about it.  This is basically a debate where
> participation is limited to the ignorant, at least as far as the
> particular details go (the general principles are debated by all).
>
> That said, even if the decisions were made in the open I wouldn't
> expect all to agree with them.
>
> Ultimately though there are pros and cons to making these kinds of
> decisions in the open, and there is not universal agreement regarding
> how these situations ought to be handled.  We can either fight about
> it until the end of time, or we can agree on some way to determine
> what approach we are going to take and then support it (perhaps
> begrudgingly).  Right now the mechanism that we have in place is the
> Council.  The only other mechanism I could see that would make any
> sense would be a referendum on the issue.  That gets unwieldy if we
> try to apply it to every little decision, but maybe for the big
> picture issues it would make sense.
>
> However, I think a lot of people would be surprised at the outcome.
> We all assume that we're all here for the same reasons, but as I
> commented on my blog Gentoo is a bit unique among distros and many of
> us are here for very different reasons, and have different priorities.
> Also, there is sometimes a tendency to assume that all FOSS projects
> work the same way.  When I was listening to a talk about how one of
> the BSDs dealt with these kinds of issues I was shocked to discover
> that much of their dev communications happens on completely closed
> lists (not just closed to posting, but to reading as well).  Gentoo
> has the gentoo-core list but it is very low traffic and it tends to be
> used for things like swapping cell phone numbers before conferences.
> When anything substantive comes up there are usually several people
> who chime in to rightly point out that this talk belongs on a public
> list.
>
> Bottom line is that there are a lot of different ways projects can
> run, and they all have their pros and cons.  A lot of the FOSS we
> depend on actually gets built or discussed behind closed doors.  I
> doubt many of us want Gentoo to go that far, but I suspect there is a
> lot of interest in taking smaller steps in that general direction.
>
> --
> Rich
>



-- 
G.Wolfe Woodbury
redwo...@gmail.com

Re: [gentoo-dev] Mailing list moderation and community openness

[Gregory Woodbury]

On gentoo-dev list: k_f
points out that this should have been talked about during previous
discussion periods...

It was discussed "to death" over and over, and many argued against it
till they were blue in the face.
Their concerns were ignored, and Gentoo lost a lot more of the "Free
and Open" reputation it theoretically
prides itself on.

-- 
G.Wolfe Woodbury
redwo...@gmail.com

Re: [gentoo-dev] [RFC] Restricted version of gentoo-dev mailing list

[Gregory Woodbury]

On Wed, May 24, 2017 at 9:01 AM, Dirkjan Ochtman  wrote:
>.
> I agree with the others who've said that they don't think this is the
> right solution. I've previously agreed we need moderation. I would
> advocate that infra work on better moderation tools and/or mailing
> list infrastructure that enables our use case.

As I read the lists on Gentoo, I note that there are actually
only a few topics and/or contributors that make the lists
noisy.

A minimally robo-moderated list that initially filters non-
developer posters, with an ability for any developer to
clear or maintain moderation of a poster could work fairly
easily.  All developers would be initially clear of moderation
while others would need to "earn" a clearance of being
moderated, that is: new non-dev posters have to have
some developer look at the post and pass it to the list if it
seems appropriate, or they may reject it (with or without
comment.)

The robo-moderation would post a one-liner attention
message, and any cleared list member (or any of a
fairly large number of moderators) could engage the robot
off-list to examine and approve/reject the message, and
clear/maintain the posters moderation status.

Additionally, any of the chosen type of moderators (all
devs or selected moderators) could place non-dev
posters back on moderated status as necessary. If a ban
is needed, a proposal could be posted by the bot, and
any interested devs could vote to the bot (off-list) within
a given time period, and the plurality would determine
a ban or not.

Interactions with the bot would be off-list, and anyone
would get a status report from it as desired.

A full[er] specification of the moderation robot can be
developed rather quickly if desired.
-- 
G.Wolfe Woodbury
redwo...@gmail.com

Re: [gentoo-dev] Requirements for UID/GID management

[Gregory Woodbury]

On Fri, Jan 27, 2017 at 1:52 PM, Rich Freeman  wrote:

> On Fri, Jan 27, 2017 at 12:54 PM, Michael Orlitzky  wrote:
> >
> > You don't really have to care what UID/GID is assigned, because each
> > user/group will only be created once and referenced by name (as $PN). By
> > default, we could pick the first available UID in most packages.
>
> I might be not following correctly, but due to how filesystems/etc
> work it is probably desirable to have consistent UID/GIDs as much as
> reasonably possible.  Things like NFS, chroots, containers, and so on
> can be a bit simpler if these are consistent, because they involve one
> system having visibility into a filesystem hosted on another, and
> usually in these cases the UID/GID is what is kept constant, not the
> name.  (IMO UID/GID namespace is one of those areas where
> Linux/POSIX/etc has some weaknesses.)
>
> This doesn't really seem like a problem though.  Just have a table
> somewhere (wiki?) to track who is using what UID/GID and encode those
> defaults into the ebuild that creates those users.--
>

There should be a division of the system managed UID space:
1)  constant/consistent UID/GID for major things (portage, etc.)
2)  variable space for per package groups/users that generally don't care
  about consistency

A quick look at /etc/passwd shows that many of the system UIDs are
under 250 (portage) and a few scattered above 400. GIDs are similar,
though some are "fixed" and some are assigned going down from 999.

Some eclasses may need to be scrutinized for what behavior they are using.

-- 
G.Wolfe Woodbury
redwo...@gmail.com

Re: [gentoo-dev] newsitem: important fstab update

[Gregory Woodbury]

On Thu, Oct 27, 2016 at 11:37 AM, Mike Gilbert  wrote:

>
> Seriously though, it makes more sense to have a conservative default
> (udev-settle). Especially since OpenRC is not well-equipped to deal
> with event-based device management.
>
>
It seems to me that the problem is one of somebody not caring that the
solution chosen can break an already functioning and stable system.

This is not unlike the kerfufle that occurred when systemD was introduced
not so long ago. To use it folks had to make major changes to their systems
that took several months to iron out the kinks.  Additionally, some of the
folks
pusing the change seemed to have a bad attitude about not caring that what
they did had unintended consequences. (Enough so that Linus had some bad
words for them!)

It isn't that progress or systemD is "bad", (it did solve some problems) but
that the manner in which it was introduced and pushed was poorly handled.

To select a "solution" that breaks functioning systems is not (to me) an
acceptable course of action.  It is no justification to remove udev-settle
to say that it "will speed thing up" as the only real advantage.

Out of curiosity, why do folks say that the use of LABEL= is not
good?  I realize that s are not required when doing a mkfs, but if the
admin does so reliably and wants to use LABEL= thereafter, why should it be
"deprecated"?


-- 
G.Wolfe Woodbury
redwo...@gmail.com

Re: [gentoo-dev] The Beauty of Unix

[Gregory Woodbury]

I agree with Paul Varner's comment.

There are places where a tight-coupling makes sense (the kernel) and places
where it doesn't (system admin and userspace development.)

My objections to the systemd plans is philosophical. There are some
folks who want to make Linux
into a Desktop System environment that works out of the box in the
manner of Windows. There are reasons to do this,
and there are reasons not to do this.  On the one hand, to compete
with MS Windows one must become MS Windows;
on the other hand. doing that cuts deeply into the things that make
Linux (and all the *NIX's) powerful and adaptable.

When SysVInit was developed (circa 1981) there were serious
limitations on the hardware it ran on in terms of speed
and memory. Additionally, there were missing software algorithms and
methods to solve some of the problems it
had to deal with.  A decision was made to punt some of the problems to
a capable human mind rather than to spend
precious time and resources trying to solve them computationally. This
is, of course, the need for the admins to look at
the services dependency graph and let them adjust the startup
sequencing by hand.

Hardware capabilities and software methods advanced quite fast and Sys
V Init (being standardized) did not keep
up with the times.  Various extensions and replacements for the
Init/startup methods were developed, and most
added dependency descriptions and automatic solving to the mix, while
trying to preserve the ease of using shell scripts
for getting things done.  OpenRC is one of the contenders and it is
highly adaptable as new technologies are
introduced (such as automatic device configuration a la eudev.)

Systemd's method, though, rips out huge chunks of many different
system components and replaced them with a
monolithic structure that takes control of everything between the
kernel's construction of the first process and the
startup of the selected desktop environment. It also imposes strict
interface requirements on the API of service
daemon startup and which desktop environments it wants to support.

The monolithic structure and resource requirements severely limit the
hardware that can be used (to fairly recent
amounts of memory and processor speed.)  This, like Microsoft's
methods, leaves a lot of not-so-old hardware
out in the cold in a forced obsolescence.

Additioinally, the development methods used, and the future plans for
systemd, make it clear that its objective
is to make a tighly integrated system that can compete with Microsoft
in its own arena. [And don't get me started
on the personalities involved!]

I use systemd when required, and I can even tweak the internals when
necessary. But for my own use, I much
prefer the freedom to customize and construct things on my own.
Perhaps I am and "old fogey" living in the past,
but I think some other folks would object to that characterization. I
have been involved in computing since 1958,
and have made (and continue to make) some significant contributions to
the field (even if my name is not publicly
associated with them.) I have been in the trenches of (F)OSS for a
long time and would love to see Linux+GNU
in a significant number of non-technical users' hand and homes.
However, I do not think that the only way to
accomplish that is by becoming another Microsoft.

This discussion should not be about which system is better or worse.
There should be room in the concept space
that preserves to ability to choose what a person wants on their
machine, rather than having the environment
dictated by some corporate entity looking to achieve market dominance.
The "average users" these days have
no concept of the magic behind the buttons on the screen and the
keyboard, and most are just willing to consider
the devices unrepairable when they fail and just go get another one.
The advertising driven consumer culture
really doesn't want the consumers' to know what is going on behind the
scenes. but it still requires that some
do know and can keep the infrastructure running and advancing.

That is enough ranting for now. Carry on.

-- 
G.Wolfe Woodbury
redwo...@gmail.com

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Gregory Woodbury]

Grammar and style police are everywhere!
This week are they shooting themselves in the foot over some totally
trivial and meaningless extra characters somewhere on a line?
Is it a case of "#TriviaDoesntMatter"?

AFAICT the limitations on line lengths are are ANCIENT holdovers
from days of fixed lenght cards and glass-teletypes. Totally meaningless
in today's terminal emulator in GUIs world.

It is certainly laudable to keep text block widths reasonable. It is fact that
it is easier to read text at 6 or 7 inches wide versus more than 8 inches.
BUT, it is also clear that a *consistent* style is easier to read instead of
needlessly varying styles in one document.

As for "being hesitant to touch anything anymore"...
Practically all of the FOSS projects have adopted rather stringent and
ridiculuous requirements that programmers and other have to jump
through hoops (of flame?) to prove their qualifications to do anything.
Gentoo is maybe one of the more conservative about having to go
through the motions in oder to qualify as a "developer" and, personally,
I no longer have the time or inclination (at my age of 62) to do so, just so
that my 50+ years of programming and typing can be subject to the
arbitrary rules.  I don't expect to be granted free access to the
code base without some oversight, but a code review by one or
more others before a commit would/should be more than adequate
to exclude bugs and blunders from being introduced.

Over the years I have done much for the FOSS movement, and I
have posted some small tools and scripts that some may find usefull, and
where possible I contribute via bugzilla. I much prefer Gentoo as a platform
since it is still committed to allowing the users to make significant
choices about the environment instead of imposing "one way" policies
as some other projects have done.

But seeing this little tempest merely convinces me that some folks
still don't get the point that some things of a substative nature
(such as correctness and choice) are of more importance than
other things (like "style" or options.)  Also, avoiding idiosyncratic
changes that have unforseen or un-intended consequences should
be coordinated with others before introduction to a stable system.

-- 
G.Wolfe Woodbury
redwo...@gmail.com

Re: [gentoo-dev] Re: Excessive rsync time after git migration

[Gregory Woodbury]

I am still getting the Manifest files completely reloaded when I sync
portage. (emerge --sync)

-- 
G.Wolfe Woodbury
redwo...@gmail.com

Re: [gentoo-dev] Re: Excessive rsync time after git migration

[Gregory Woodbury]

I'll sync soon and see.  Thanks.

-- 
G.Wolfe Woodbury
redwo...@gmail.com

Re: [gentoo-dev] Re: useflag policies

[Gregory Woodbury]

Is a possible solution something like an eselect module to indicate
the preferred
interface kit? It could default to any package that is available with
a sequential
set of preferred order.
Then ebuild would consult the eselect module, and users who care can
select the kit they want, and users who don't care/know get the default.


Just a nickel's worth opinion. Due to inflation it isn't 2 cents any more.
-- 
G.Wolfe Woodbury
redwo...@gmail.com

Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC

[Gregory Woodbury]

On Wed, Aug 5, 2015 at 8:09 PM, James Cloos cl...@jhcloos.com wrote:
 WH == William Hubbs willi...@gentoo.org writes:
 WH What do folks think of these changes?

 For local filesystems, mount -a is exactly right and should remain.  At
 least for those of us who prefer only ever halving to edit fstab(5).
 --
 James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6

+1
Having yet another place to have to edit to mount local disks is just not
a viable option.

-- 
G.Wolfe Woodbury
redwo...@gmail.com