Yes, for example, syncing on a kernel panic could lead to data corruption (which is why we don’t do that). For the same reason REISUB is not recommended anymore: The default advice for a locked-up system should be SysRq B.
Yes, for example, syncing on a kernel panic could lead to data corruption (which is why we don’t do that). For the same reason REISUB is not recommended anymore: The default advice for a locked-up system should be SysRq B.
https://linux-tc-notes.sourceforge.net/tc/doc/cls_u32.txt:
The base operation of the u32 filter is actually very simple. It extracts a bit field from a 32 bit word in the packet, and if it is equal to a value supplied by you it has a match. The 32 bit word must lie at a 32 bit boundary.
Try removing all the superfluous default routes.
I think glider can do this, with -strategy rr
(Round Robin mode). I have not used it in this way myself, so you might need to experiment a little. Proxychains can also do this, but it doesn’t present a socks5 interface itself (it uses LD_PRELOAD
, so it won’t work everywhere).
Argon2id (cryptsetup default) and Argon2i PBKDFs are not supported (GRUB bug #59409), only PBKDF2 is.
There is this patch, although I have not tested it myself. There is always cryptsetup luksAddKey --pbkdf pbkdf2
.
Consider the string abc
. From the end, moving backwards, when does it match \w+
, and what does it match? When it reaches c
, it matches c
. And from the front, moving forwards? When it reaches a
, it matches abc
. This is why it acts differently.
The regexp itself always looks forward, the BACKWARD argument just determines which direction the point should move after a match.
Because once it hits the ultimate character of a word, \w+
matches that (single) character, next time it matches the penultimate character, etc. You’d need \W\w+
to make it look far enough back to the beginning of the word.
This seems right and exactly the way I’ve set it up. On subvolid=5 I have subvolumes and
@home
, in /etc/fstab
I mount /
as subvol=@
, and /home
as subvol=@home
.
https://stackoverflow.com/questions/10602504/how-does-user-js-work-in-firefox-in-detail:
It just looks like a JavaScript file. Once upon a time in Netscape 3 and maybe 4 it actually was, but now it’s just a file with a .js extension and a very restricted syntax that’s parsed by a separate (non-JS) parser and not executed in any way.
Could you run sudo lshw -C network
and post the output for the wireless interface?
Funny enough I arrive at this the most when I play the Triassic and my opponent goes for a Cretaceous game structure.
We have those on I2P already, see tracker2.postman.i2p for example.
You should not torrent over the tor network, but you can torrent over the I2P network. qBittorrent even has experimental I2P support built in.
I’m not on NixOS, but I have a decent working knowledge of Tor.
Not quite clear on what you’re trying to do, are you trying to run a relay, or just connecting to the Tor network and pointing your browser to the socks proxy?
Arti (the official Tor implementation in Rust) is not a complete replacement for the Tor C implementation yet. Hidden service support is disabled by default (due to the lack of a security feature that could allow guard discovery attacks), and bridges don’t work either. If you don’t understand Tor very well stick with the old router.
I occasionally experience the same thing. When this happens, it appears the jwt token is not sent with the initial request (thus appearing to be logged out), but it is sent with api requests on the same page (unread_count
, list
, etc.), so the cookie is not lost (document.cookie
also shows it). Sometimes refreshing again fixes it, but I haven’t yet found a good workaround. I’ll experiment a bit next time it happens.
You can give chisel a try. It tunnels all traffic over http/https, and the client can then create port forwards, just as with ssh, to access other services.