You talk like that is a bad thing. Win32 UI works, is fast, works everywhere even on ancient 640x480 server screens, safe mode and vnc in 16 colors without opengl, directx, Angle or vulkan.
Flutter is nicer to scale and maybe design but it is a massive overhead. Skia still has trouble with some drivers and causes lag or falls back to software rasterization. Hot replacement while coding is pretty neat though. It runs much better on mobile devices imho.
It works, and fast, but it is not portable. I would argue something like Qt is much more viable in $current_year for cross-platform development. Or if you're really dead-set on actual native components, then I guess wxWidgets works too.
you might want to make sure you're comparing apples to apples though. the "emacs" command most likely is going to load the GUI emacs so a lot of gui libraries (if you're running a recent emacs then even GTK libraries) whereas the nvim command isn't going to load gui libraries at all.
maybe try with a non-gui version of emacs (or maybe calling emacs -nw)
no, this is the TUI version.
X11 emacs with all the composited effects needs about 200-250ms to open (about the duration of the animation for opening and closing it). That's more like OP's timings.
No, you need to use -nw with emacs to make it apples to apples. Then it's emacs 0m0.095s vs nvim 0m0.057s:
$ time nvim -es --cmd 'vim.cmd("q")'
real 0m0.057s
user 0m0.016s
sys 0m0.017s
$ time emacs -Q -e kill-emacs
real 0m0.230s
user 0m0.165s
sys 0m0.064s
$ time emacs -nw -Q -e kill-emacs
real 0m0.095s
user 0m0.057s
sys 0m0.017s
You should be able to do that via DNS SRV entries.
_xmpp-client._tcp.domain.tld. TTL IN SRV priority weight port target
_xmpps-client._tcp.domain.tld. TTL IN SRV priority weight port target
example:
_xmpp-client._tcp.not-my-domain.com. 3599 IN SRV 5 0 5222 jabber.my-domain.com.
You could also build a reverse proxy setup. Then you wouldn't need the keys to the SSL certs. But that is probably overkill to run at your client: https://wiki.xmpp.org/web/Tech_pages/XEP-0368
I don't think I have seen a client complain about the cert being for jabber.my-domain.com
Which one is giving trouble there?
> The receiving entity SHOULD choose which certificate to present
> based on the domainpart contained in the 'to' attribute of the
> initial stream header (in essence, this domainpart is
> functionally equivalent to the Server Name Indication defined for
> TLS in [TLS-EXT]).
and 13.7.2 says
> Once the identity of the stream peer has been validated, the
> validating entity SHOULD also correlate the validated identity with
> the 'from' address (if any) of the stream header it received from the
> peer. If the two identities do not match, the validating entity
> SHOULD terminate the connection attempt (however, there might be good
> reasons why the identities do not match, as described under
> Section 4.7.1).
You can manually set a server in most clients, and I don't know how that is generally implemented. I guess that should work then.
But if you serve a certificate for jabber.example.com for a user trying to connect to an account user@example.com using SRV records then that mismatch will give you at least a certificate warning popup. And for good reason too: How would a user verify that a certificate
Flutter is nicer to scale and maybe design but it is a massive overhead. Skia still has trouble with some drivers and causes lag or falls back to software rasterization. Hot replacement while coding is pretty neat though. It runs much better on mobile devices imho.
reply