Re: I need to get a Russian keyboard

[Constantine Aleksandrovich Murenin]

On 27 May 2016 at 06:36, Joseph Fierro  wrote:
> On 05/27/2016 12:27 AM, Chris Bennett wrote:
>> Any advice on what to be sure to find or not find on a keyboard?

I'm quite surprised it hasn't been mentioned yet in this rather long
thread -- why do you actually need labels on your keys?

Do you actually look at your keyboard whilst you type?!  /Ain't nobody
got time for that?/

My advice is to use a quality keyboard without Cyrillic letters on it!
 Because, sadly, we haven't actually reached a stage in globalisation
yet where products aren't localised only to the particular markets in
which they are sold, and aren't available for sale (over the internet,
no less!) in the other non-native markets.  Ironically, this applies
even if they're all custom-order made in China (if you ever ordered
any laptop directly from Apple or IBM/Lenovo), and are drop-shipped to
the U.S. consumers directly from Shenzhen!

Cheers,
Constantine.SU.

Re: sensorsd, upd, and state changes

[Constantine Aleksandrovich Murenin]

On 26 February 2016 at 08:40, lilit-aibolit  wrote:
> I've tried to change low=1:high=2 to low=0:high=0
> but I haven't got *Off* current state for this sensor from sensord:
>
> - hw.sensors.upd0.indicator2=On (ACPresent), OK
>
> Even for AC disconnected sensord repors that ACPresent is *On*,
> however when I look for
>
> - sysctl hw.sensors.upd0.indicator2
>
> it repororts that ACPresent is *Off*, so I decided don't rely
> on sensord logic and place own script to cron and execute it
> every minute.

The `indicator` changes between On/Off with a user limit of
`low=0:high=0`  should definitely be triggered as reported by the
prior users (http://marc.info/?l=openbsd-misc=144526769005460=2).

http://BXR.SU/OpenBSD/usr.sbin/sensorsd/sensorsd.c#check_sdlim

370if (sensor.flags & SENSOR_FINVALID)
371newustatus = SENSORSD_S_INVALID;
372else if (sensor.value > limit->upper)
373newustatus = SENSORSD_S_ABOVE;
374else if (sensor.value < limit->lower)
375newustatus = SENSORSD_S_BELOW;
376else
377newustatus = SENSORSD_S_WITHIN;

However, notice that all status changes are subject to dampening --
the default check period is 20 seconds
(http://BXR.SU/OpenBSD/usr.sbin/sensorsd/sensorsd.c#check_period,
e.g., `sensorsd` is equivalent to `sensorsd -c20`), and it takes 3
cycles for the value to stuck in.  E.g., if the status does not
consistently stay the same for about a minute by default, then it is
simply discarded and not taken seriously.

Most Hardware Monitor drivers in OpenBSD update their sensors every 5
seconds (regardless of whether anyone's reading them or not), so, you
might as well check them more often as well, yet still have the
dampening:

% fgrep sensorsd /etc/rc.conf.local
sensorsd_flags=-c5

As for upd(4), the updates are done every 6 seconds, for whichever reason:

http://BXR.SU/OpenBSD/sys/dev/usb/upd.c#upd_attach,

210sc->sc_sensortask = sensor_task_register(sc, upd_refresh, 6);

So, if you want a faster notice, but without giving up the dampening,
you might want to run your sensorsd with `-c6`, for example.

Cheers,
Constantine.

Re: sensorsd, upd, and state changes

[Constantine Aleksandrovich Murenin]

On 19 October 2015 at 11:31, David Higgs  wrote:
> On Mon, Oct 19, 2015 at 11:11 AM, Maxim Khitrov  wrote:
>> Also, upd always sets sensor status to "OK," so sensorsd never
>> triggers commands for status changes; we have to use low/high limits
>> until this is fixed. One proposed hack was to use "low=1:high=2" in
>> sensorsd.conf, but this doesn't seem to work for everybody.
[...]
> This is still all just a hack; I ran out of free time to keep working on
> upd(4).  I made the driver less terrible and added a few sensors, but
> didn't get as far as changing sensor statuses which could make reporting
> much easier.

Yes, it looks like http://bxr.su/o/sys/dev/usb/upd.c follows the
NetBSD paradigm where ksensor.status is simply tied to SENSOR_FINVALID
from ksensor.flags, which is a redundant approach in the OpenBSD
ksensor API, and ksensor.status should instead not be set to anything
at all in such scenarios where it wouldn't alert one of a WARN or CRIT
condition as per http://bxr.su/o/sys/sys/sensors.h#sensor_status.

Cns:OpenBSD {8224} fgrep -n -e .status -e .flags sys/dev/usb/upd.c
254:sensor->ksensor.flags |= SENSOR_FINVALID;
255:sensor->ksensor.status = SENSOR_S_UNKNOWN;
398:sensor->ksensor.status = SENSOR_S_UNKNOWN;
399:sensor->ksensor.flags |= SENSOR_FINVALID;
432:sensor->ksensor.status = SENSOR_S_OK;
433:sensor->ksensor.flags &= ~SENSOR_FINVALID;
Cns:OpenBSD {8225}

All the three lines with `.status` should probably be removed to avoid
the extra confusion and not give the impression that ksensor.status is
actually supported by the driver.

Cheers,
Constantine.SU.

BXR.SU, Super User's BSD Cross Reference w/ OpenGrok, publicly private beta

[Constantine Aleksandrovich Murenin]

Dear misc@,

It is my great pleasure to announce the immediate availability of a 
publicly private IPv6-only beta test of BXR.SU -- Super User's BSD Cross 
Reference.


BXR.SU is based on an OpenGrok fork, but it's more than just OpenGrok. 
We've fixed a number of annoyances, eliminated features that just never 
worked right from the outright, and provided integration with tools like 
CVSweb (including awesome mirrors like allbsd.org), FreeBSD's ViewVC 
(SVN), as well as Gitweb from git.freebsd.your.org, plus a tad of other 
improvements, including a complete rewrite of an mdoc parser.  Last, but 
definitely not least, is an extensive set of nginx rewrite rules that 
makes it a breeze to use BXR.SU as a deterministic URL compactor for 
referencing BSD source code.



  What's up with the publicly private beta test?

We're launching today in a publicly private beta.  Participation in the 
beta is invitation-only; everyone with IPv6 is invited.


We're cooperating with ISPs around the world, and in order to be able to 
access BXR.SU during this beta phase, you must have a special token, 
also known as a publicly routable IPv6-address, with proper 
IPv6-connectivity and upstream peering.  If you don't have IPv6 yet, but 
want to participate in this beta test ASAP, then ask your ISP for IPv6 
ASAP!  Else, if your ISP is not part of our beta rollout, you could try 
something like tunnelbroker.net from he.net.



  What's the release schedule?

BXR.SU is available through IPv6 today, 2013-04-01.  It is currently an 
IPv6-only site, with an IPv6-only glue, too.


As an IPv6-only site, we hereby declare that 2013-04-04 is an IPv4 day.

On April 4, we will temporarily enable IPv4 connectivity, for one day, 
to test the water.  (We've heard that IPv4 has some connectivity issues 
related to NAT, double-NAT, carrier-grade NAT and NAT64, and some small 
percentage of users (but significant in absolute terms) might not be 
able to access the site if an A record is published, due to the 
plentiful of misconfigurations out there; so, we want to take things 
slow, and ensure our users don't suffer from any inferior connectivity.)


If things do go well (we expect IPv6/IPv4-related improvements as time 
goes by), we will permanently publish an A record for BXR.SU on 2013-04-14.


IPv4 glue records will be published shortly thereafter, on 2013-04-24 
(we don't do this today, because we're afraid that the nameservers of 
some ISPs are not configured correctly, and our IPv6 users won't be able 
to access our site otherwise, so, we think it's a good idea to take 
things slow and in steps).



  But why another OpenGrok?

Over the years, there have been a number of OpenGrok installations that 
have made it possible to study and grok BSD code, for which we are very 
thankful to their maintainers.  However, as a general rule, none of them 
have been inclusive of all BSD flavours, all of them have had rather 
long and hard-to-remember URLs, which also didn't really look permanent 
at all, and, unfortunately, many of them no longer exist today, or some 
new uber-inclusive services like code.metager.de have recently 
flourished, with an astounding 8 second (yes, eight second) delay for 
satisfying any single search query (hot queries are returned in as 
little as just under 4 seconds by metager, yet everything is nonetheless 
buffered, so, you get no rendering at all for those whole 4 or 8 
seconds).  So, we thought this had to change.



  So, what's the deal?

It's simple.

Say, someone doesn't know who PHK is.  You can point them to:

  http://bxr.su/s?q=phk

Want to see if DragonFly keeps queue.h in sync?  Take a look at:

  http://bxr.su/d/sys/sys/queue.h

Want to look at FreeBSD's queue.h, to manually compare?  Just change the 
d from /d/ (or select and replace the whole world DragonFly from 
/DragonFly/) to f, and you're in FreeBSD:


  http://bxr.su/f/sys/sys/queue.h

Too many /sys/sys/?  We've still got you covered, thanks to nginx:

  http://bxr.su/o/queue.h

Anyone uses TAILQ_SWAP?  Is that a new thing?  Check it out:

  http://bxr.su/search?q=TAILQ_SWAP

Any mentions of OpenBSD or NetBSD in FreeBSD and DragonFly?

  http://bxr.su/f,d/s?q=OpenBSD+OR+NetBSD

Who's this guy writing this email anyway?  Is he BXR'able?

  http://bxr.su/s?q=%22Constantine%20A.%20Murenin%22%20OR%20cnst

Etc.


  Just how fast is BXR.SU?

We expect that most search requests should be fulfilled (search page 
results generated) in well under 100ms.  In my tests, and according to 
OpenGrok metrics at the bottom of each search page, most search pages 
are generated in about 30 to 50ms, so, it does seem like there's some 
room to spare.  In addition, of course we use nginx, so, once generated 
at 40ms, a page should be available immediately in no time should a 
subsequent identical request come along within a couple of seconds or so.



  How does it compare with fxr.watson.org?

+ we're based on OpenGrok, instead of LXR
+ we also index userland of