Re: Patch for rc.conf(8) man page

2014-02-10 Thread David Walker
I prefer this ...

--- rc.conf.8   Tue Feb 11 21:24:16 2014
+++ rc.conf.new.8   Fri Jan  3 00:44:18 2014
@@ -47,11 +47,11 @@
 .Pp
 It is advisable to leave
 .Nm rc.conf
-untouched, and instead create and edit a new
+untouched. The
+.Nm rc.conf
+file includes a check for
 .Nm rc.conf.local
-file.
-Variables set in this file will override variables previously set in
-.Nm rc.conf .
+which can be used to override variables as required.
 .Pp
 Some variables are used to turn features on or off.
 For example, whether the system runs the



Re: 5.5beta wierds

2014-01-21 Thread David Walker
Rod Whitworth loki () witworx ! com
 I feel that date should spit out an error message rather than
 crash even if it only happens when some idiot plays with the numbers.

Every time you do that I get a little bit sadder.
Leave something for me.



Re: group.5

2012-12-09 Thread David Walker
Having read su and then group it struck me that this is disingenuous,
for want of a much better word:
A user is automatically in a group if that group was
 specified in their passwd(5) entry and does not need to be added to that
 group in the group file.

If this is intended on the part of su and otherwise the above
statement is strictly correct, as far as group membership goes, then
the diff is probably not warranted.
It doesn't seem necessary.
In my case being new to su I of course read su(1) and coped fine.
It seemed very clear what the deal was, certainly as far as administration.
Presumably anyone who's forgotten or whatever and su doesn't work will
go read it also.

At install, are users that are added to wheel listed in group?
If the FAQ is correct then that must be what happens right?

Are there any other cases like this, where users must be explicitly
added to a group?



group.5

2012-12-08 Thread David Walker
Hey.

I noticed adding a user to wheel doesn't provide su capability
automatically. This is described in su(1).
I though it might be useful to mention it in group(5) also.

--- group.5 Sun Dec  9 14:14:58 2012
+++ group_change.5  Sun Dec  9 15:07:29 2012
@@ -81,7 +81,13 @@
 .Xr passwd 5
 entry and does not need to be added to that group in the
 .Nm
-file.
+file. Members of the
+.Dq wheel
+group, who wish to run commands as
+.Dq root ,
+using
+.Xr su 1 ,
+must be explicitly listed.
 .\ .Pp
 .\ When the system reads the file
 .\ .Pa /etc/group

Best wishes.



Re: mixerctl(1) diff: sort output

2011-05-14 Thread David Walker
Hi.

Sviatoslav Chagaev 0x1392 () gmail ! com
 I have absolutely no idea. I'm not an audio equipment manufacturer.

I have used many consoles ... digital and analogue ones ... live and
in studios.
I also have an electronics background - digital and analogue ... and
repaired many consoles.
I've also used software mixing facilities.

The model is always the same.
As someone said in the aucat thread the principle of least surprise
and this applies extremely in the professional audio world where it's
expected that I can go to a venue and be able to work immediately with
equipment I may have never seen before.

As far as bussing goes there's an accepted way of doing things.
In the analogue world this is limited by the layout of the circuits
whereas in the digital there's a lot more flexibility but ... it's
only in the most simple cases that a pure hierarchy is at work.

I've never defined this before but this is from wikipedia and pretty
much sums it up:
In a group of related items, heterarchy is a state wherein any pair
of items is likely to be related in two or more differing ways.
Whereas hierarchies sort groups into progressively smaller categories
and subcategories, heterarchies divide and unite groups variously,
according to multiple concerns that emerge or recede from view
according to perspective.

http://en.wikipedia.org/wiki/Heterarchy

A most pertinent point there to ordering output:
... heterarchies divide and unite groups variously, according to
multiple concerns that emerge or recede from view according to
perspective.

This is exactly how mixing consoles (even simple analogue ones) and
mixing software work and exactly how people who use them think -
having more than one visual model in their head at a given time,
usually assembling heterarchies into multiple hierarchies and often
matrixing them as well.

This also applies very strongly (I've omitted some of the flexibility
which doesn't apply to the rigidity of bussing):
A heterarchy may be ... subsumed to a hierarchy ...; the two kinds of
structure are not mutually exclusive. In fact, each level in a
hierarchical system is composed of a ... heterarchical group ...

Even in consoles with very flexible bussing there's always a number of
levels in a somewhat hierarchical structure - almost invariably more
than one hierarchy is available and even in simple analogue consoles
it's possible to move items so that they span different levels of a
hierachy (or move into another hierarchy).

Where we originally might have ...

___a___
|   |
  _a_   _b_
 | |  | |
 ab c   d

It's pretty trivial to do ...

 _a
 |   | |
 | _a_  |
 | | | |
 abc   d

... or permutations thereof.

Labelling of mixing consoles have been designed this way since day dot
as a direct result of electronic bussing and continued right into
software mixing on the principle of least surprise.

Something else that's extremely relevant is that mixers (people who
do mixing) label in this manner also - whether mentally or with a
texta ...
Usually likeness trumps everything.

For instance I will bus all the violins into a violins group and bus
all the cellos into the cello group and then bus them together into
the strings group.

On an analogue console (and a digital one in a simple layout) I will see this:

  S
V  C
| |
 _ | __ | _
 |  |  ||  |  |
 v v vc c c

On a digital console I might see this:

S
__V   C__
 _ | _  _ | _
 |  |  |  |  |  |
 v v v  c c c

That's how layout works from left to right but ...
LIKE THINGS WILL ALWAYS BE GROUPED both on the console/software and in
the models.
Not in alphanumeric order - that's only useful when I have three
trombones and I label them T1, T2, T3 ...

One thing that is invariable though ... is that the input and the
output of a particular channel are always grouped together unless
they are specifically supposed to work as a team.
For instance this ...

channela -
channelb -
groupA (ab) -
channelc -
channeld -
groupB (cd) -
mainA (AB) -

... is always understood to mean ...

- input channela output -
- input channelb output -
- input groupA (ab) output -
- input channelc output -
- input channeld output -
- input groupB (cd) output -
- input mainA (AB) output -

... it doesn't matter at all if you want to do this though ...

- input channela output -
- input channelb output -
- input channelc output -
- input channeld output -
- input groupA (ab) output -
- input groupB (cd) output -
- input mainA (AB) output -

... but never this ...

- input channela
- input channelb
- input channelc
- input channeld
- input groupA (ab)
- input groupB (cd)
- input mainA (AB)
channela output -
channelb output -
channelc output -
channeld 

Re: mixerctl(1) diff: sort output

2011-05-14 Thread David Walker
At the sake of running out of internet here's a little clarification ...

... this ...

- input channela
channela output -
- input channelb
channelb output -
- input channelc
channelc output -
- input channeld
channeld output -
- input groupA (ab)
groupA (ab) output -
- input groupB (cd)
groupB (cd) output -
- input mainA (AB)
mainA (AB) output -

... or this ...

- input channela
- input channelb
- input channelc
- input channeld
channela output -
channelb output -
channelc output -
channeld output -
- input groupA (ab)
- input groupB (cd)
groupA (ab) output -
groupB (cd) output -
- input mainA (AB)
mainA (AB) output -

... but never this ...

- input channela
- input channelb
- input channelc
- input channeld
- input groupA (ab)
- input groupB (cd)
- input mainA (AB)
channela output -
channelb output -
channelc output -
channeld output -
groupA (ab) output -
groupB (cd) output -
mainA (AB) output -

... and AFAICT mixerctl does it correctly.
FYI it's not as amibiguous as it might appear and AFAICT the reasons
that have been given are the correct ones.

Best wishes.