I think the phrase down the rabbit hole is actually referring to Alice in Wonderland. But.
I would say the organism that tends to burrow the deepest into the Earth is humans. Average oil well depth appears to be around 5,964 feet (1818 meters), that’s pretty deep. The deepest hole we ever drilled is supposedly the Kola Superdeep Borehole dug by the Soviets, it was 40,230 feet (12.2km) deep.
Perhaps not answer your looking for though.
I don’t know anything specifically about KeePassXC but it’s my understanding that a transform round is some computationally expensive task that can be preformed as many times as desired, but must be preformed the same number of times to decrypt as well. The point being to slow down any attempts at brute forcing access to you database if someone gets a hold of your encrypted DB file. For example say it takes one second to derive the proper DB access key from the password you entered to unlock the app, that doesn’t really matter to you logging in as almost no one is going to notice a one second delay in logging in. But if some one else gets a hold of your encrypted password DB then they have to wait one second for every password they try, making brute forcing the DB file practically impossible given you’ve chosen an adequate password.
Ideally you’d choose something which gives a delay not too inconvenient for you when logging in, but enough to thwart the person who might try and brute force the password even if they’re using more powerful hardware.
Having recently been diagnosed with ADHD as an adult I didn’t know what RSD was and had to look it up. Oh goodie another ADHD related problem it looks like I probably have, I’ll have to mention this at my next session and see what they say. Thanks for the heads up.
I had a peek at the source code and although I don’t actually know Rust it looks like that error comes from a check for character length in the function “is_valid_body_field”. Strangely it does the same check twice against two variables “POST_BODY_MAX_LENGTH” and “BODY_MAX_LENGTH”.
The smaller of the two is BODY_MAX_LENGTH which is set at 10000, so I assume the max character limit is 10,000. There are no other checks in that function other than the character count and that’s the only place in the source code that the text “invalid_body_field” shows up so I assume it’s only sent as a response to too much text, but as I said I don’t actually know Rust so I could be wrong.
Here’s the github page for the program that’s at least partially responsible for that output.
From that page it appears detected means “Device is detected, driver is found, but not tested yet” and working means “Driver is found and operates properly (passed static or dynamic tests)”
In the case of tetracycline antibiotics the degradation products can damage the kidneys and cause Fanconi syndrome. So in that case as a medicine for people it becomes poison, as a poison for bacteria it becomes safer.
Perhaps there should be a new default feed that only features posts from communities that ‘x’ number of users have a subscription to, with ‘x’ being scalable with userbase. Also the aggregate user’s community subscription count could be used to influence the sort order for that feed and bring more popular content closer to the top. Of course there will still be diverseness amongst users in even the smallest userbase, but maintaining a blacklist of communities against a feed curated by user subscriptions would surely be easier than maintaining a blacklist against the raw feed from other instances.
One thing I worry about is finding new communities. If I understand correctly the federated feed only shows posts from communities that other users have previously searched for? If so that leaves new community discovery solely up to word of mouth or searching using external websites. Perhaps each lemmy instance could ask it’s peers for a list of their top subscribed communities from their instance by the users on that instance, and then start pulling posts from those top communities and adding them to the ‘all’ version of the federated feed. That should give existing and new users a (hopefully) mostly decent feed of the top communities from other instances to find content and communities from.
Did you try plugging it in initially after you disassembled it and reassembled it? I’ve found on chromebooks that the embedded controller doesn’t seem to wake up until the charger is plugged in after unplugging the battery. Could it be that you initially didn’t plug it in before trying it months ago, but months later you figured the battery would be low after all that time so you plugged it in finally starting the embedded controller?
With time and distance it will fade. I’m not at all like I was when younger, young me would be shocked and appalled at the worldviews I hold now.
Shucks I get all my anxiety disorders for free! HOT DAMN!