I’d just point out, for running an executable, wine isn’t JITting anything at least as far as I’m aware. They’ve implemented the code necessary to read .exe files and link them, and written replacements libraries for typical windows DLLs, that are implemented using typical Linux/POSIX functions. But since, in most cases, Linux and windows runs on the same target CPU instructions set most of the windows code is runnable mostly as is, with some minor shim code when jumping between Linux calling conventions to windows calling conventions and back again.
Of course, this may be different when wine isn’t running on the same target CPU as the windows executable. Then there might be JITing involved. But I’ve never tested wine in such a situation, thoughI’d expect wine to just not work in that case.
I mean for most Linux derivatives, getting SSH setup for outgoing connections is usually install the
openssh
package from your distros repos, though I imagine many preinstall it, no reboot should be necessary, and you just typessh user@hostname
into a terminal to connect to the remote ssh server to access stuff on that computer. There shouldn’t be a need to reboot for installing app that’s not a service.Wanting to enable ssh access to the computer you are using so a remote client can connect to it? Well the same
openssh
package should have come withsshd
which acts as the server to allow remote ssh client to connect. It’d probably need enabling (so it’s run automatically on boot) and starting (so you don’t have to reboot to have it going), on distributions using systemd that’s usually justsystemctl enable sshd.service
(which makes sure the sshd daemon will be started on next boot) followed bysystemctl start sshd.service
to start it immediately so it’s running straight away, (orsystemctl enable sshd.service --now
to roll both steps into one).