Hey,
thanks for the diff. I gave it a try and i really like it. On a server
with 32 cores this can be usefull to get a quick look at what is going
on. As long as this is not the default and just a toggle it is very
usefull for my usecase.
Your diff works well on my system.
Thanks and greeings
Bob Beck wrote:
> On Mon, Apr 13, 2020 at 09:23:23PM -0600, Todd C. Miller wrote:
> > On Mon, 13 Apr 2020 20:27:30 -0600, Bob Beck wrote:
> >
> > > In my hearts desire I'd love for "R" to be chosen for each line once at
> > > start
> > > up. (so in
> > > the above example the things are randoml
> On 13 Apr 2020, at 19:03, Remi Locherer wrote:
>
> Hi,
>
> I recently looked into NHRP (RFC 2332) and noticed that our tcpdump does
> not have a printer for it. So I added support for NHRP to tcpdump.
>
> Initially I was surprised: I expected a simpler protocol! But it is from
> the 90's w
On Mon, Apr 13, 2020 at 09:23:23PM -0600, Todd C. Miller wrote:
> On Mon, 13 Apr 2020 20:27:30 -0600, Bob Beck wrote:
>
> > In my hearts desire I'd love for "R" to be chosen for each line once at
> > start
> > up. (so in
> > the above example the things are randomly distributed). but not sure ho
On Mon, 13 Apr 2020 20:27:30 -0600, Bob Beck wrote:
> In my hearts desire I'd love for "R" to be chosen for each line once at start
> up. (so in
> the above example the things are randomly distributed). but not sure how har
> d that is..
>
> If it saves code and effort I really think this is only
A couple thoughts:
1) I'm not sure how useful random months or days of the week are, but for
consistency maybe?
2) if I do something like
R * * * * /usr/local/bin/thing1
R * * * * /usr/local/bin/thing2
R * * * * /usr/local/bin/thing3
...
R * * * * /usr/local/bin/thing1000
I still have the th
hi.
The following servers will likely be inaccessible at times or
completely, April 14, from 7am to 8pm Eastern Daylight Time (UTC-4)
(yes -- 13 hour window) for site network maintenance.
* man.openbsd.org
* cvsweb.openbsd.org
* obsdacvs.cs.toronto.edu
* openbsd.cs.toronto.edu
Nick.
patrick@ pointed out that the arm64 bus_space implementation was
(partly) copied from mips64. Therefore th fixes should probably be
applied there as well.
Untested so far.
Index: arch/loongson/include/bus.h
===
RCS file: /cvs/src/s
On Mon, 13 Apr 2020 10:00:52 -0600, Bob Beck wrote:
> +1000. a new random time chosen at cron start.
>
> We see this all the time, and it would be a lot better than the hacks for all
> the things
>
> "R" for random sounds good to me
How about this? If you guys like it I'll update the man page
On 2020/04/13 18:27, Edd Barrett wrote:
> On Mon, Apr 13, 2020 at 11:12:46AM -0600, Theo de Raadt wrote:
>
> > If this is going to be done, it should look the same. I'm not talking
> > about the markers above it, but about your arbitrary use of #.
>
> So you mean the first proposal is good, just
Edd Barrett wrote:
> On Mon, Apr 13, 2020 at 11:40:21AM -0600, Theo de Raadt wrote:
> > I don't like it.
> >
> > CPU00 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 18.2% intr,
> > 81.8% idle
> > CPU01 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr,
> > 100% idle
>
On Mon, Apr 13, 2020 at 11:40:21AM -0600, Theo de Raadt wrote:
> I don't like it.
>
> CPU00 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 18.2% intr,
> 81.8% idle
> CPU01 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr,
> 100% idle
>
> versus
>
> [##
Edd Barrett wrote:
> On Mon, Apr 13, 2020 at 11:12:46AM -0600, Theo de Raadt wrote:
>
> > If this is going to be done, it should look the same. I'm not talking
> > about the markers above it, but about your arbitrary use of #.
>
> So you mean the first proposal is good, just change # to >?
I
On Mon, Apr 13, 2020 at 11:15:59AM -0600, Theo de Raadt wrote:
> I think your bar-graph removes detailed information and replaces it
> with a visual which wastes screen real-estate.
I agree, that's why I made it a toggle.
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
On Mon, Apr 13, 2020 at 11:12:46AM -0600, Theo de Raadt wrote:
> If this is going to be done, it should look the same. I'm not talking
> about the markers above it, but about your arbitrary use of #.
So you mean the first proposal is good, just change # to >?
Note that systat(1) uses both chevr
Theo de Raadt wrote:
> Edd Barrett wrote:
>
> > On Mon, Apr 13, 2020 at 06:26:53PM +0200, Sebastian Benoit wrote:
> > > If you make them look like the display in systat, you still get the user,
> > > ... nice, sys information. Also i like my bikeshed green.
> >
> > So looking at the bar in `sy
Edd Barrett wrote:
> On Mon, Apr 13, 2020 at 06:26:53PM +0200, Sebastian Benoit wrote:
> > If you make them look like the display in systat, you still get the user,
> > ... nice, sys information. Also i like my bikeshed green.
>
> So looking at the bar in `systat vmstat`, we have:
> ```
>0.0
On Mon, Apr 13, 2020 at 06:26:53PM +0200, Sebastian Benoit wrote:
> If you make them look like the display in systat, you still get the user,
> ... nice, sys information. Also i like my bikeshed green.
So looking at the bar in `systat vmstat`, we have:
```
0.0%Int 0.0%Spn 0.1%Sys 25.5%Usr
Sebastian Benoit wrote:
> Edd Barrett(e...@theunixzoo.co.uk) on 2020.04.13 15:47:03 +0100:
> > Hi,
> >
> > One thing I miss from our top(1) is the ability to see overall CPU
> > utilisation at a glance (I usually scan for the idle percentage and
> > invert it in my head).
> >
> > This diff adds
Edd Barrett(e...@theunixzoo.co.uk) on 2020.04.13 15:47:03 +0100:
> Hi,
>
> One thing I miss from our top(1) is the ability to see overall CPU
> utilisation at a glance (I usually scan for the idle percentage and
> invert it in my head).
>
> This diff adds a way to toggle (using `B`) CPU utilisati
On Mon, Apr 13, 2020 at 09:56:52AM -0600, Todd C. Miller wrote:
> On Mon, 13 Apr 2020 09:37:14 -0600, "Theo de Raadt" wrote:
>
> > While I understand what RANDOM is trying to do, I am not a fan. I've
> > thought often of an improvement, where the minute marker in a crontab
> > file could be a let
On Mon, 13 Apr 2020 09:37:14 -0600, "Theo de Raadt" wrote:
> While I understand what RANDOM is trying to do, I am not a fan. I've
> thought often of an improvement, where the minute marker in a crontab
> file could be a letter 'R', which indicates the specific random value
> for this cron start.
Reason I don't like 2048 is, 34.1 minutes, why why why.
Should it not be 2047 or 2049? *cough* What's going on is here, is
it should be 3600 - the maximum plausible runtime. But I'm still not
thrilled changing the value there on it's own either.
rpki-client itself shold probably self-prote
I also don't like 2048 value.
Why 2048? Why a power of 2. A value passed on from ancestors?
I think it should be picked more carefully to look like a 'safe window'.
Claudio Jeker wrote:
> I do not use the sleep RANDOM thing because I prefer to have rpki-client
> run always at the same interval (1h) and I just selected a random minute
> in the hour.
While I understand what RANDOM is trying to do, I am not a fan. I've
thought often of an improvement, where t
On Mon, Apr 13, 2020 at 02:43:27PM +, Job Snijders wrote:
> Hi,
>
> I'm reviewing some of the timers associated with the workings of the
> end-to-end propagation from ROA to VRP. I think suggesting to run
> rpki-client only once a day can make for needless brittleness.
>
> Running rpki-client
Stuart Henderson wrote:
> > 30 5 1 * * /bin/sh /etc/monthly
> > #0 * * * * sleep $((RANDOM \% 2048)) &&
> > /usr/libexec/spamd-setup
> >
> > -#0 9 * * * -n sleep $((RANDOM \% 4096)) &&
> > rpki-client -v && bgpctl reloa
> 30 5 1 * * /bin/sh /etc/monthly
> #0 * * * * sleep $((RANDOM \% 2048)) &&
> /usr/libexec/spamd-setup
>
> -#0 9 * * * -n sleep $((RANDOM \% 4096)) &&
> rpki-client -v && bgpctl reload
> +#0 * * *
On Mon, Apr 13, 2020 at 02:43:27PM +, Job Snijders wrote:
> I'm reviewing some of the timers associated with the workings of the
> end-to-end propagation from ROA to VRP. I think suggesting to run
> rpki-client only once a day can make for needless brittleness.
>
> Running rpki-client just onc
Hi,
One thing I miss from our top(1) is the ability to see overall CPU
utilisation at a glance (I usually scan for the idle percentage and
invert it in my head).
This diff adds a way to toggle (using `B`) CPU utilisation bars, like this:
```
load averages: 0.92, 0.52, 1.26
Hi,
I'm reviewing some of the timers associated with the workings of the
end-to-end propagation from ROA to VRP. I think suggesting to run
rpki-client only once a day can make for needless brittleness.
Running rpki-client just once a day also results in only making a rsync
fetch attempt once a da
George Koehler writes:
> In emacs, if I visit /tmp/nowhere/new, but /tmp/nowhere doesn't exist,
> then C-x C-j shows an error:
> | Setting current directory: No such file or directory, /tmp/nowhere/
>
> In mg with your diff, if I do the same, then C-x C-j does nothing, and
> doesn't show an error
On Sun, Apr 05, 2020 at 03:24:30PM +0200, Marcus MERIGHI wrote:
> Hello,
>
> reading plus.html I noticed that the link to simplepanel(4) was a dead
> end.
>
> below is my attempt at a stub man page with what I could gather from
> plus.html and the commit log.
>
> Marcus
>
hi. thanks for the di
Hi,
the diff below adds a new feature that allows the use of separate rdomains
for the encrypted and unencrypted side of ipsec(4) flows.
The idea is that an edge router that controls access to a private network
via ipsec can have its uplink in one rdomain and the private network in
another. The k
Hi,
I recently looked into NHRP (RFC 2332) and noticed that our tcpdump does
not have a printer for it. So I added support for NHRP to tcpdump.
Initially I was surprised: I expected a simpler protocol! But it is from
the 90's with all the protocols from then in mind (frame relay, ATM, ...).
I te
Hi,
Would below be okay?
On Tue, Apr 07, 2020 at 04:46:38AM +, Mikolaj Kucharski wrote:
> Hi,
>
> When I'm upgrading my machines, I find it useful to have BUILDINFO
> file around. Tested on RPi3.
>
> Please carbon-copy me in any replies. Thank you.
>
> openbsd-rpi# sysupgrade -s -n
> Fetch
36 matches
Mail list logo
