Agreed, especially for "serious" project, where LLMs are a good approximation of an average dev that could easily increase your bus factor.
On the other hand, this could be the same slippery slope that starts at "choose a boring project because it has mature tooling" but ends at "IDE's are a language smell". If the language is so boring that you can't focus on it without an LLM doing the menial work, that could be because there is too much menial work to start with.
> Finally, cryptographic warnings are being eliminated. Historically, as end-to-end encryption was rolled out throughout Matrix, not all apps verified the identity of their users, triggering confusing and unactionable warnings to users. We are now shifting towards only letting devices whose ownership has been verified by their owner participate in conversations, killing those warnings - as well as other underlying protocol changes to eliminate warnings.
As the operator of a small instance for family and friends, that's an important topic. The very frequent use case is : "I lost/replaced my phone and didn't save my passphrase". Does that mean that the account would be lost ?
First of all, we're shifting to generating a recovery key (like FileVault or similar) rather than forcing users to pick a recovery passphrase which they promptly get confused with their account password and/or lose.
Secondly, we're making it much less likely to actually need to ever enter a recovery key - with QR login meaning you just scan a QR code to launch your account, complete with all e2ee state (assuming you're already logged in somewhere; same as WA or Discord etc).
In the end, though, if you lose all your devices, you have no choice but have some kind of recovery key to get back in. We could use your account password, but (particularly in an OIDC world) it's then challenging to avoid exposing the account password to your server admin (thus breaking E2EE).
So instead, we're hoping that users will either save their recovery key, or worst case, if they do, they can reset it... but that will inevitably mean they won't be able to access their old messages from backup any more.
as always, the result of more security without taking into account real-life human behaviour, only leads to less security overall as people will just use services that don't have this behaviour and always allow getting back your account
But the version on F-Droid hasn't been updated since 3 months, and won't work with this new Synapse API endpoint (I just realized this, because it didn't work, after I switched from the proxy to the Synapse API).
oh nice, I was actually wondering what was the quickest way to build a meteor.js app (which is mostly a single threaded process).
My 2 cents: I had to scroll down all the way to find out where the "CPU speed" comes from... And I'd still like to know about the "avg" part, so you may want have a more detailed "Method" section (before the results) ;)
Newbie question: how do we know we can trust the microphone?
It sounds like a chicken-and-egg problem to equalize speakers with an equalized microphone, but maybe microphones are simpler and can be assumed to be equalized ?
MiniDSP makes some calibration mics that run about 60 bucks. I used them as a cheap instrument for some lab work where I needed a calibrated mic a while back and was very impressed with their performance for the price. They ship with a little code that you can use to retrieve the calibration curve from the factory, and I know a lot of people use them for hifi calibration with REW.
Anyone interested in this area should also know that above ~2 kHz it doesn't matter what you do for magnitude equalization because you'll be dominated by sub mm variations in position and direction. The only way to get any amount of repeatability above 2 kHz is with IEMs.
This is dealt with by smoothing the spectrum in a way to preserves the power density. The constructive and destructive interference then cancel each other out.
A microphone’s ability to reliably identify a frequency is excellent, even if the microphone is cheap, crappy and uncalibrated. It’s almost entirely a function of whatever clock is used to digitize it, and oscillator chips that are just fine are ubiquitous.
The issue is calibrating the amplitude response at a given frequency, and a tuning fork won’t help.
edit: those quartz oscillator chips have a lot in common with tuning forks.
N. K. Jemisin wrote a triple Hugo winning trilogy[1] about what could happen to humanity with a sliiightly less stable crust, if you want some more unnerving ;)
linuxserver.io made an rdesktop-web based docker image of DigiKam[0], so I guess it could be "upgraded" to self-hosted.
I'd be tempted by the potential of setting up various digikams as a service for my various users (the member of my family), where each instance could share some but not all photo folders with others.
[Zen of Reticulum](https://reticulum.network/manual/zen.html)
[Understanding Reticulum](https://reticulum.network/manual/understanding.html)