Messages

I'll be euqally blunt. Who are you talking to? You asked a question. I answered. I would have expected a proper reply, not some annoyed comment that has nothing to do with what I brought up.

Get your attitude in order. This is no way to deal with people. At least not when they are as friendly as I am.

Fix your release notes, unless you want to come across as a liar. Or was this on purpose? Telling people that the issue was A, then tell people that A was fixed and react like someone killed your dog, because people tell you that it didn't fix A.

A screenshot would help explain if the issue you're seeing is relevant to the changes or not.

It's the same as in the other topic about fixed rule window size. In that topic it was explained that the reason for this was an issue with tabulator that had a bug about the height calculation or dynamic resizing.
Since the release notes mentioned exactly that I hoped this would fix the issue.

It seems that even though Tabulator was updated and the grid height is auto calculated in the 26.1.6 update, the problem still persists (without
Stylus or Tampermonkey).

Excerpt from the release notes:

ui: upgrade Tabulator to version 6.4.0
ui: automatic grid height calculation

I have fixed this for me with a Tampermonkey script.

Thank you for this. I've converted it to a Stylus User Style (I am using Stylus instead of Tampermonkey) and it works splendidly.

2000px is a good value for 50 entries. For 100 entries you have to increase the value accordingly. Since this is a max value anyway and does not change the size, if no entries are displayed, using a very large value should not matter either. e.g. setting it to 50000px. In that case one can be sure that 1000 entries can be shown as well (w/o scrolling within the tabulator). (1000 is the last selection before All.)

It looks like this topic applies to other parts of the webGUI too and at least one person found a nice workaround for it : https://forum.opnsense.org/index.php?msg=262103

Basically edit the CSS so the height is at least 2000 pixels :)

Awesome, thank you for this. I converted that Tampermonkey script into a Stylus User Style and it works nicely.

I have linked the code where there is a comment about the new library used (tabulator) having some challenges with this resizing.

Thank you. I had an appointment this afternoon and I wasn't able to read up on it. I only saw the referenced issue in the comment, but need more time to look into it, which I will do this evening.

So, why didn't someone answer with: it was a workaround for a bug or limitation. Please open a github issue for further discussions. On one side I can certainly understand this, but there might be fixes or better libraries in the future. (As I mentioned before, I have to read up on it and maybe open an issue with the tabulator project.)
I like github, so I don't have a problem with it. But questions are usually closed in gh trackers referencing a forum or some other channel.

Which is why I asked my question in this forum (as a starting point). I certainly have no problem to move it over to gh. But in that case, please state in which repo, and other info: issue, discussion, ...

The way you initially wrote with bold text and suggestive questions made it look like you were baiting for an argument.

Initially I did not write in bold. I wrote in bold to emphasize my unanswered questions. People tend not to answer questions, but rather give unrelated statements. This is not an OPNsense forum problem, but apparently how communication now works. 20 years ago, you asked a question and you got an answer to that exact question.
These days you get comments, deflection, part of an answer that could have been derived if all of it had been answered, or an answer that might not have anything to do with the question that was asked.

The answer "it was a deliberate design choice" by itself is utterly useless unless I am told why.

I was just trying to emphasize the question and I believe that is what bold is for. To emphasize text. I did not use all CAPS, btw.

But if at the top I select "show me 50 entries per page" there is absolutely no reason not to just render a table with 50 lines and let the browser and me handle it.

Thank you, this was exactly my point as well.

We are constantly working on improving the user experience with the new tabulator library.

My point is that the user experience hasn't been improved in this case. At least not for me. For me the experience got worse in this specific case. Otherwise I wouldn't have brought it up. Please check my first post again. I mentioned that I missed rules because of this. I did not use profanity, nor did I attack anyone. I voiced an opinion. That's all. And apparently I am not alone with my opinion.
I will read up on the tabulator issue, but I am not a GUI person, which means I will be most likely over my head with this one.

So maybe there are options or ways to get back the old behavior even with the new library. If not, the new libary should fix this problem to actually improve the user experience. Otherwise you could just remove the "number-of-rules" button and the pagination functionality, since those things are pretty much useless now.

Apart from all that I am very happy with OPNsense. I am not someone to complain without reason and I actually still haven't complained yet. I mentioned that the user experience is worse for me. A complaint is filed, if the other party did something wrong. But I don't think that anybody did anything wrong in this case. A combination of circumstances led to an unfavorable result and I can't complain about something like this.

If you want to complain please do so on github.

I was asking a question, and asking the people, who decided on that new design, why it is better is constructive. There must have been a thought process, which I don't understand but want to. If you think this is a complaint, it is not. Not yet, I usually don't complain, but I want to understand why things are the way they are. It is a subjective opinion. I love OPNsense, but dislike the new design with the heat of a thousand suns.
However, maybe I don't understand why the new design was deliberate. Guess what? This is why I asked the question. And then maybe I will think differently.
Also, if it is not better in the eyes of the people who are responsible for this, why was it done in the first place? So don't get me wrong, they must have thought it is better, they didn't just roll a dice, did they? So for them the new design was better, subjective or not. I still want to know what it was exactly.

[how is this supposed to be better than it was before?]

It's a deliberate design choice.

Which begs the question: how is this supposed to be better than it was before? (there must be a reason for the design choice. As mentioned before, it renders the number of rules to display pretty much useless now.)

[Is this a bug or a deliberate design decision? If it is the latter, please reconsider and also please explain how this is supposed to be better than it was before.]

At least it's a bit better than the ISC DHCP Server webGUI was were you had to scroll over the Settings to get to the Static DHCP Mappings part each time :)

This can easily be solved by adding a link (reference within the same page) at the top to jump to the static mappings.

But the fact that the current UI now has 2 scroll areas (and scrolling depends on where your mouse pointer is), is not very user friendly. Especially when I can choose the number of rules to show. This is then basically useless, if the scroll area always stays the same.

Still hoping for an answer to my question:

Is this a bug or a deliberate design decision? If it is the latter, please reconsider and also please explain how this is supposed to be better than it was before.

I've just upgraded to 26.1.x (from 25.7) and the upgrade was flawless. Thanks.

Then I checked my DNAT rules (formerly known as port forwarding) and I was shocked that rules were missing. Turns out that they were not missing, but the rules are presented in a fixed sized window (I don't know the term, maybe it's called a container or div - I am not a GUI person) and I had to scroll within that little window to see all my rules.

Previously the window (conainer or whatever) adjusted its size depending on the number of entries you wanted to see (50, 100, ..., All). Now you have 2 separate scroll areas, which is extremly inconvenient. See screenshot.

Is this a bug or a deliberate design decision? If it is the latter, please reconsider and also please explain how this is supposed to be better than it was before.

[What is the status of the ZFS issues related to sqlite in FreeBSD?]

As I feared this topic moved away from my original question. My question was not related to hostwatch and its i/o usage.

I don't want to sound ungrateful, but why is my question ignored or answered with something else I didn't ask. I am ok with answers like "I don't know", "never heard of such a thing", "check this ...", but unfortunatelety I just got unrelated answers.

But maybe my question was not specific enough, thus I'll try again:

What is the status of the ZFS issues related to sqlite in FreeBSD?

I didn't want to distract from my original question, which is why I didn't add too much info that is not BSD related, especially since this forum doesn't allow sections or to hide text. As mentioned in my original post, the sqlite/zfs issue in Linux was based on the PR I referenced. I really don't want this in this topic. I'll send a PM.

FreeBSD ZFS experts should know what I was asking. I was not talking about write amplification. The issue is that when using WAL, writes to the DB stall until they basically timeout, which brings the app using it down. The ones that were supposed to fix it, were reverted and the fix for the fix was closed w/o merging. But hey, maybe ZFS for BSD got a fix that solved it and I missed it. This is why I asked. I don't know the status. I only know that sqlite and zfs is usually a no-no.

After reading a few topics here, I have noticed that hostwatch uses sqlite. ZFS has been known for having issues with sqlite.

I have done some digging and there was a PR for FreeBSD in ZFS, which was closed (unmerged) by reverting a previous attempt to fix it.

So I don't really know what is going on. The fix for ZFS on Linux (which was based on the FreeBSD fix) was included in 2.4.0, yet the fix for FreeBSD was reverted.
Maybe the OPNsense devs have an idea what the status is, since they have deep knowledge of FreeBSD and ZFS.

will definitely hit the user regarding the final installation of the ISC plugin since it is the last operation in the upgrade, but this is is neither predictable nor prevalent.

As a weird workaround: any chance you can add a dummy package always as the last package?

I'm not aware of a static mappings issue (yet).

Great, thanks.

FWIW: I mocked around a bit with removing, changing and adding static mappings. Worked as intended.

Nice. Thanks. This makes me happy.