datastore and tape entries are very similar but differ in some points
in such a way that a nice unification is not really that helpful, but
making similar key parts the same is still nice when reading the code
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
should not be a hard dependency, as one can use the file-restore tool
for pxar archives without it too
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
I made some comparision with bombardier[0], the one listed here are
30s looped requests with two concurrent clients:
[ static download of ext-all.js ]:
lvl avg / stdev / max
none 1.98 MiB 100 % 5.17ms / 1.30ms / 32.38ms
fastest 813.14 KiB 42 % 20.53ms / 2.85ms / 58.71ms
default 626.35 KiB 30 % 39.70ms / 3.98ms / 85.47ms
[ deterministic (pre-defined data), but real API call ]:
lvl avg / stdev / max
none 129.09 KiB 100 % 2.70ms / 471.58us / 26.93ms
fastest 42.12 KiB 33 % 3.47ms / 606.46us / 32.42ms
default 34.82 KiB 27 % 4.28ms / 737.99us / 33.75ms
The reduction is quite better with default, but it's also slower, but
only when testing over unconstrained network. For real world
scenarios where compression actually matters, e.g., when using a
spotty train connection, we will be faster again with better
compression.
A GPRS limited connection (Firefox developer console) requires the
following load (until the DOMContentLoaded event triggered) times:
lvl t x faster
none 9m 18.6s x 1.0
fastest 3m 20.0s x 2.8
default 2m 30.0s x 3.7
So for worst case using sligthly more CPU time on the server has a
tremendous effect on the client load time.
Using a more realistical example and limiting for "Good 2G" gives:
none 1m 1.8s x 1.0
fastest 22.6s x 2.7
default 16.6s x 3.7
16s is somewhat OK, >1m just isn't...
So, use default level to ensure we get bearable load times on
clients, and if we want to improve transmission size AND speed then
we could always use a in-memory cache, only a few MiB would be
required for the compressable static files we server.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Else it does not gets picked up on release builds...
Also the mathjax path option affects HTML not EPUB so move it to the
correct section in conf.py
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
To let users find the good explanation about allocation and retention
policies from the docs easier.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
I mean the whole distro uses quite some C and the like as base, so
avoid being overly strict here.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
It does not help users if that is spelled out, and its not a common
use of GCM, and especially in the AES 256 context its clear what is
meant. The link to Wikipedia stays, so interested people can still
read up on it and others get a better overview due to the text being
more concise.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The main feature list should provide a short overview of the, well,
main features. While enterprise support *is* a main and important
feature, it's not the place here to describe things like personal
volume/ngo/... offers and the like.
Move parts of it to getting help, which lacked mentioning the
enterprise support too and is a good place to describe the customer
portal.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Else one has quite a terrible UX when installing from 1.0 ISO and
then upgrading to latest release..
commit 0ec79339f7 for the fix and some other details
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
found and semi-manually replaced by using:
codespell -L mut -L crate -i 3 -w
Mostly in comments, but also email notification and two occurrences
of misspelled 'reserved' struct member, which where not used and
cargo build did not complain about the change, soo ...
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Less anti-aliasing to do, so it looks better when small.
Note, I use a mask as else we could not cut out something
transparent, but only over paint it filled with white, which is not
the same and not how font awesome does it.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The old value just was way to heavy, and notes/warnings/...
admonitions did not stick out anymore.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
1. Use same height as width
2. drop the top/bottom "frame" lines
3. instead of two "bearings" side by side, like VHS or music-compact
tapes have, use a single bearing and an outer circle to denote the
magnetic tape edge
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we test for the config key in the API so it makes sense to have as
test here too. Actually it would be better if we'd have a expect
Value defined here and enforce that it matches, but better than
nothing.
Fix the input for test 1, where tabs got replaced by spaces, as else
it fails
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Americans seem to sometimes use Avery 6577 which has 5/8" x 3"
labels, equaling 15.875 mm x 76.2 mm, so do not set the lower bound
to 17mm (which even breaks our used Avery 3240 sheets which have an
label height of 16.9 mm
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
marketing noted that it looked quite heavy weight, to the point where
it was hard to read to the full black squares, bold monospace text
and bottom borders with rather distinctive darkness.
Address those by:
* change color for list points from black to mid-dark grey
* use empty circles for second heading level
* ensure monospaced text has a normal font weight in the TOC headings
* some lighter color for the bottom border
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
As 20s is really not that high, especially for loaded setups one is
connected to through a spotty network (looking at you ÖBB railnet)
and gets latency spikes of 5 - 10s for some minutes at a time..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Rund `codespell` tool, but it picked up not as much as I hoped.
Rest was found with vim + (hun)spell
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
and fix some issues from referenced named the same as their heading
they anchor too.
This should be fixed for real in our python plugin to scan for such
references, its probably a bug there, but as most of the problematic
ones where wrong (missing chapter prefix) anyway changing them is OK
too.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
"we" should be avoided, it's never quite clear who is "we" in the
context here and it leads to some technical wrong meanings, e.g., we
(here assumed to be "we developers") do not read any backup data, the
Proxmox Backup client does.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Fix two things:
* do not reject the login promise when we get the abort DOMException
error
* safely save the original challenge string as we work on a reference
here and avoid to convert to a UInt8 array twice to avoid an
exception.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
simple heuristic for those people who always prefer a specific TFA
method and have the others only as backup.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Improve UX by avoiding the need to click some buttons twice, or
calling TOTP and Recovery codes both "OTP" codes and showing multiple
buttons, with all having the same goal "submit a TFA token" at the
same time.
Instead use a tab panel with a single submit button.
WebAuthn can and should be still improved, but that can be OK as
followup.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This is wrong most of the time, when not loading the web interface
with valid credentials, and thus some checks or defaults did not
evaluated correctly when the underlying value was only set later.
Needs to be set on component creation only, this can be done through
initComponent, even listeners, view controllers or cbind closures.
Use the latter, as all affected components already use cbind.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
present all relevant information about the TFA token to be removed,
so that a user can make a better decision.
Rework layout to match our commonly used style.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht