Re: cwm on wayland
On Sat, 2023-12-16 at 00:22 +0100, Anders Andersson wrote: > On Fri, Dec 15, 2023 at 7:01 PM David Coppa wrote: > > > > On Fri, Dec 15, 2023 at 6:29 PM wrote: > > > > > > So they're putting a Wayland in our BSD. > > > > > > I've never used that before. > > > > > > Is a port of cwm planned? > > > > I really don't think so. > > > > But there's hikari, a stacking Wayland compositor heavily inspired > > by > > cwm: https://hikari.acmelabs.space/ > > > > We might probably have a port of it in our ports tree in the > > future. > > > > Ciao, > > David > > > > I'm not sure their "Geekfeminism Code of Conduct" > (https://hikari.acmelabs.space/coc.html) works well with OpenBSD. > You put "Geekfeminism" in the same quotes as "Code of Conduct".. I suspect you did so for a reason. "Geekfeminism" does not exist on the Hikari page at all. It is the reason that I don't understand. To be fair, I find it unfortuante that any projet needs to have a Code of Conduct, but for whatever reason that is the way the world is going. People are rude against others because of their identity or other reasons not related to the goals of the project. I don't thnk I have ever seen anyone from OpenBSD be rude against anyone because of their idenity. They will be rude with people who expect things and don't contribute, but that is unrelated. There is a non-subtle and significant difference. The license of the Hikari project looks (at a quick glance) seems to to be a 2-clause BSD license. So why would OpenBSD have issues with this? You are not a dev, but considering you posted this publicly I am interested in your response. What was the reason? Justin
Re: What could cause high CPU load averages (no actual CPU usage)?
On Fri, 2023-10-27 at 10:49 +0200, Claudio Jeker wrote: > On Fri, Oct 27, 2023 at 01:54:28AM +0200, Justin Yates Fletcher > wrote: > > On Wed, 2023-10-25 at 20:25 -0400, Raul Miller wrote: > > > On Wed, Oct 25, 2023 at 8:16 PM Justin Yates Fletcher > > > wrote: > > > > On Wed, 2023-10-25 at 21:12 +0200, Mike Fischer wrote: > > > > > > > > > > > Am 25.10.2023 um 17:57 schrieb Theo de Raadt > > > > > > : > > > > > > Mike Fischer wrote: > > > > > > > > Am 25.10.2023 um 17:29 schrieb Theo de Raadt > > > > > > We changed a lot of kernel scheduling code *without giving > > > > > > a > > > > > > damn > > > > > > about the stability of this number* > > > > > > > > > > Fine, but you are not changing my running Kernel, are you? > > > > > > > > I don't understand your point with this. Are you making an > > > > accusation? > > > > If not, then why even write this? > > > > > > I think Mike Fischer's point was that the change did not > > > correspond > > > to > > > a kernel upgrade. > > > > > > > It is hyperbole or accusational... or somewhere on that spectrum. > > Either way, it serves no valuable purpose, so why even write that? > > > > Also, there was a kernel change: 7.4. Pretty sure that was > > mentioned. > > > > > > > (And I think Theo de Raadt's point was that there's not enough > > > rigor > > > on load average to diagnose this issue.) > > > > > > > Theo's point, as I read it, was just that the load average is > > calculated in the same way as before, even though there have been > > changes in other parts of the system that could affect it. > > Just to be clear. There was a change in how the load avarage is > calculated. So it may cause differences in numbers. Do we care about > that? > No because it was done to be able to work on more important projects. > Thanks for the clarification. Maybe I misread. > > > It has nothing to do with rigor. The OS could just always report > > 0.0. > > If you start artifically changing a metric, for the sake of rigor, > > then > > that metric is no longer valuable: > > > > https://en.wikipedia.org/wiki/Goodhart%27s_law > > > > Changing how a mertic is calculated to meet a target certainly > > reduces > > the value of the metric, right? > > I do not agree. The load avarage has some value but most people do > not > understand how it is calculated and what a significant change is. > Also systems change, so metrics change all the time. They still offer > a > good value. > I'm not wanting to get too pedantic, but I'm not quite understanding what you disagree with? My point with this part is just to address the usage of the word "rigor" in regards to calculating the load average. The OP was stating that he would remove load average from his metric collection. I don't think that is a good idea and tried to convey that to him. It is a valuable metric and, like many others, context matters (as you wrote). In response, it was said that Theo implied not enough rigor was applied on load average to diagnose the perceived issue. What I wrote above is in response to specifically that. Goodhart's law popped into my head because it sounded like turning a metric into a target, and the problems of doing so... but maybe I shouldn't have posted that. It might have just confused the point. Anyway, Theo posted a diff on misc@ many years ago (close to 20 maybe?) where the load average would just return 0, in reply to someone complaining about it. So, saying that not enough "rigor" is applied to load average calculation kinda triggered that memory and the response. Justin
Re: What could cause high CPU load averages (no actual CPU usage)?
On Wed, 2023-10-25 at 20:25 -0400, Raul Miller wrote: > On Wed, Oct 25, 2023 at 8:16 PM Justin Yates Fletcher > wrote: > > On Wed, 2023-10-25 at 21:12 +0200, Mike Fischer wrote: > > > > > > > Am 25.10.2023 um 17:57 schrieb Theo de Raadt > > > > : > > > > Mike Fischer wrote: > > > > > > Am 25.10.2023 um 17:29 schrieb Theo de Raadt > > > > We changed a lot of kernel scheduling code *without giving a > > > > damn > > > > about the stability of this number* > > > > > > Fine, but you are not changing my running Kernel, are you? > > > > I don't understand your point with this. Are you making an > > accusation? > > If not, then why even write this? > > I think Mike Fischer's point was that the change did not correspond > to > a kernel upgrade. > It is hyperbole or accusational... or somewhere on that spectrum. Either way, it serves no valuable purpose, so why even write that? Also, there was a kernel change: 7.4. Pretty sure that was mentioned. > (And I think Theo de Raadt's point was that there's not enough rigor > on load average to diagnose this issue.) > Theo's point, as I read it, was just that the load average is calculated in the same way as before, even though there have been changes in other parts of the system that could affect it. It has nothing to do with rigor. The OS could just always report 0.0. If you start artifically changing a metric, for the sake of rigor, then that metric is no longer valuable: https://en.wikipedia.org/wiki/Goodhart%27s_law Changing how a mertic is calculated to meet a target certainly reduces the value of the metric, right? Justin
Re: What could cause high CPU load averages (no actual CPU usage)?
On Wed, 2023-10-25 at 21:12 +0200, Mike Fischer wrote: > > > Am 25.10.2023 um 17:57 schrieb Theo de Raadt : > > > > Mike Fischer wrote: > > > > > > Am 25.10.2023 um 17:29 schrieb Theo de Raadt > > > > : > > > > > > > > Mike Fischer wrote: > > > > > > > > > True. But like I said, this was noticed because of the sudden > > > > > increase on the same (OpenBSD) machine without any obvious > > > > > reason. > > > > > > > > The reason is obvious. > > > > > > > > You installed a completely different system. > > > > > > No, there is a misunderstanding here. I have not been comparing > > > OpenBSD load averages to those on any other OS. > > > > No, it is *your misunderstanding* > > > > We put no effort into maintaining stability of this damn number. > > Ok, I realise that load average may too irrelevant a measurement to > take seriously. I admit that I thought this value was somewhat > consistent in the context of a single running machine, but maybe I > was wrong. > Load average is fine to measure, but I think the point you are misunderstanding is that you went from 0.0 to 0.7 (iirc). > > > We changed a lot of kernel scheduling code *without giving a damn > > about the > > stability of this number* > > Fine, but you are not changing my running Kernel, are you? > I don't understand your point with this. Are you making an accusation? If not, then why even write this? > Or are you saying that the load average does not carry *any* inherent > information and is utterly useless? That would almost imply that this > is a (poor) sort of random number generator. > Nope. That is not the case and nobody has said that. You saw a load average change from 0.0 to some other number greater than 0.0 but less than 1. You are trying to imply that this delta means something. You have been told that it does not, many times. It *can* mean something but that is only within the context of understanding other things. > OTOH years of monitoring this value (amongst many other measurements) > on OpenBSD seems to indicate some correlation to what the machine is > doing. But I get what you are saying: no guarantees. > Nope. You still have misunderstood what is being said. Especially highlighted by your saying this is a 7.4 machine and having monitored it for years... the best you could say for 7.4 is you have monitored it for almost 2 weeks. And you have said it is a VM on VMware. You have a *huge* variable you have only lightly taken into consideration. Monitoring system performance on a VM is an exercise in futility without the underlying host information. And in my experience, still an exercise in futility even given the underlying host information... It is many opaque layers of abstraction. > > > It is a different system. > > To reiterate: I am measuring load averages on OpenBSD 7.4. On a > running system I notice a sudden jump in the value which persists for > several hours. That gets my attention because I can see no reason for > this jump. So I’m trying to figure out the cause. > Your jump was less than 1. On a graph with a scale of 0 and 1, that is "huge"! Ignore that and pay attention to the value. And understand that in context. > Please note that I am not going on the assumption that there is a bug > or that something needs to be changed/fixed in OpenBSD. The jump may > have had perfectly valid reasons. Or it may have been random with a > low probability. The "jump" you mention doesn't mean anything. Without context it means less than nothing. As has already been metioned. It *might* mean that your rrd graph metric gathering is affecting your graphs in a way that you have not seen before... Monitoring uses resources! The goal is if the system is performing what it needs to be at a rate that meets the needs, then the problem is solved. Simple as that. > But given all of the feedback from this thread I’ll deprecate this > part of my monitoring and switch to monitoring actual CPU activity > (as reported by e.g. vmstat) in the hopes that these values are more > accurate/consistent and that they better reflect the workload of the > machine. > > > No! That would be a bad option, IMHO. It is a metric that can be valuable, but good system admin. is taking all the values and understanding them in context. > Thanks everyone! > Mike > Hope that helps, Justin
Re: OpenBSD Hackathons
On Fri, 2023-05-12 at 20:18 +, Katherine Mcmillan wrote: > Hi all, > > Thank you for the helpful responses, this definitely explains some > things! > > I'm looking at organizing an OpenBSD Hackathon in the National > Capital Region in Canada (could potentially be on the Gatineau, > Quebec side) but having never been to an OpenBSD Hackathon, my > interpretation might be quite different from the other Hackathons! > That's fine, and I'm going to seek inspiration from attending a > FreeBSD Hackathon, as that project makes their upcoming Hackathons > public: https://wiki.freebsd.org/Hackathon/202305 > > Thank you very much for the help and please feel free to contact me > privately if you're interested in attending (either as a volunteer or > developer) or otherwise supporting an OpenBSD Hackathon in the > National Capital Region in Canada. > > Sincerely, > Katie Hi Katie, I'll make an assumption based upon what you have written and reply to that. I have no experience with hackathons except when working for a globally recognized company that had no idea what a hackathon meant but tried to do a few. When I learned that leadership set up a process to accept what could be hacked on, and a process to determine the winning team of the hackathons, I decided to skip the events. :-( Anyway, the official OpenBSD hackathons are limited to a select group. There is no minimum size, I assume, because if these people want to meet up then they do. If you want to set up your own community OpenBSD hackathon then you will need to do the advertising, signup process, and management of the location/capacity vs signups, etc. yourself. I do hope it goes well! Justin
Re: 0.0.0.0/32 in pf's tables
God abhors a naked singularity. On Tue, 2022-11-08 at 22:47 +0300, 3 wrote: > what religion forbids using 0.0.0.0/32 in tables? 0_0 but 0/0 can be > used.. what's going on?! is the world going mad? >
