| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
| |
warnings 'Failed to set locale'
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When installing packages, an extra line break is added by the "\r" ... echo "\r{$status}";
The $status string typically contain a trailing "\n" as required. This allows to print a message in two steps.
Writing configuration... done.
1) print "Writing configuration..."
2) print "done" after the command completes.
|
|/ |
|
|\ |
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | | |
better clarity and more concise section description.
|
| | | |
|
| | | |
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Remove duplicate BODY
Tidy up BR tag correctly
Add COLPSAN statement to "interface" row
Wrap BGCOLOR in a STYLE statement (should really be defined as a CLASS
statement)
Remove FONT tag
Remove NAME statement in DIV tag
Use double quotes for consistency
|
| | | | |
|
| | | | |
|
| |_|/
|/| | |
|
| | | |
|
| | | |
|
| |/
|/| |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Include table header titles in raw mode (time and message).
In raw mode give all horizontal space not being consumed by the time field to the message filed. Provides more space so fewer entires to consume multiple vertical line space.
Change table message field header title form "Log Message" to "Message"
Include a write_config description.
|
| |
| |
| |
| |
| | |
s/formated/formatted/
Thanks Phil
|
| |
| |
| |
| |
| |
| |
| | |
Build up th manage log section with options to override the "General Logging Options" settings on an individual log basis.
Remove over exuberant gettext's.
Set/adjust filter form field widths to be better fitting for the field types.
Open/Close filter form based on filtering state.
|
|/ |
|
|
|
|
| |
user. Reported by grandrivers at https://forum.pfsense.org/index.php?topic=103818.msg579069#msg579069
|
|
|
|
| |
conf
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This does what I can think of so far:
1) Make sure low latency < high latency, low loss < high loss
2) Loss interval must be at least latencyhigh otherwise every packet that was high latency would be counted as lost before it came back. (see note below)
3) averaging time period must be at least 2 times probe interval - it is not much of an "average" if it averages less than 2 probes :)
4) alert interval must be at least probe interval - there is no point recalculating the average latency and loss more often than once every probe interval.
5) Criteria for showing or hiding the advanced options on page load fixed up to account for all the fields now in the advanced section.
6) Additional information - I have written some stuff that I think is now helpful.
Note: Currently the default loss interval is 500 and latencyhigh is also 500. This makes no sense to me. If a probe comes back in > 500ms then the thread that is waiting for the reply will have given up (loss interval has expired). So any packets with an RTT > 500ms will be considered lost. Therefore there will be no packets recorded with an RTT > 500ms. Therefore the average latency can never exceed latencyhigh.
It seems to me that "loss interval" needs to be reasonably higher than "latencyhigh" in any sensible configuration.
Thoughts?
|
|
|
|
| |
we don't break current database. Ticket #5624
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On nanoBSD there is a "Proceed with upgrade?" question warning about the duplicate slice. After answering "y" to that, the system does the duplicate slice, which takes some minutes. Then it asks again "Proceed with upgrade?" after displaying all the packages it will install.
That is a bit annoying at the console - I answer "y" and go off to make a cup of tea, only to come back and find that it is waiting asking again.
On nanoBSD a reboot is known to be required anyway, because even if it is some little package that gets upgraded, and not the core OS, the partition is always switched. So we can say that in the first warning and then skip asking "Proceed with upgrade?" a second time.
What do you think? Should it ask a 2nd time after displaying the packages to be installed? Or is it OK to skip that confirmation prompt?
Also, I moved the call to setup_nanobsd_env inside the "if nanobsd" - it worked like it was because setup_nanobsd_env returns without doing anything if the system is not nanobsd, but it just looked odd and there seems no point calling it when not nanobsd.
|
|\ \ |
|