ashtuchkin

Love it! Trying to use it with my nanoPAD2 and it only outputs `note_on` and `note_off` events. Can we bind on these? Example output:

22:56:38.740 note_on channel=1 note=36 velocity=89 [nanoPAD2 PAD]

Just wanted to say thank you! Very relevant to our use cases. I'll report if I find any issues.

python does this pretty elegantly:

    def my_func(a: int, b: int):
        print(a+b)

    # both of these can be used
    my_func(1, 2)
    my_func(a=1, b=2)

Haven't been able to make them consistently work on my moonlander. Too many mistypes when quickly writing code. Ultimately removed everything time-related and stateful and only kept simple layers - worked great for the last ~2 years.

Privacy. If someone owns two servers you're logging into, they can associate your logins if you use the same key. Another case is associating you with your GitHub account (as your ssh keys there are public)

It's the reverse - it can only be decrypted after a threshold timestamp, not before.

Amazing how simple it is! Kudos to the author, subscribed.

Reddit does have its own search engine, it's just bad. The premise in the author's post is that as soon as it becomes "good", the SEO optimizators will ruin it in the same way they ruined Google search.

It would be interesting to calculate the probability here. 1/32000 shutter speed is impressive!

This would heavily depend on the language. Rust IDE will need different features from Web/JS IDE.

It would be interesting to see this implemented as an experiment.

On the one hand, I'm not expecting high signal from this because it's not standardized - too many external variables you can't control. It would also be pretty hard to evaluate as "just watching the path of struggle" is very subjective.

On the other hand, potential "public good" benefit can't be ignored, plus it can be added to interviewees' public resume/github account to be shown to the future employers.

json is used only for manifests; actual layers are .tar.gz.

I'm wondering if we can use Pub/Sub to push revocation data to all servers. Presumably revocations are rare, plus we only need to store them only for the JWT validity period, so additional memory usage should be minimal.

The downside is it looks more brittle than the simpler approaches. Upside is performance plus ability to revoke tokens.

Updated, thanks!

I'm pretty sure the Russian trail in this article is a red herring.

I looked up "Валентина Сынах" Skype user and, as expected, their full phone number is +7904xxxxxxx (see full number in the article), with Russian prefix +7. Note, WHOIS records have US number +1904xxxxxxx. Not sure why the author only searched for the last 10 digits.

+7 904 code is a very busy area code in Russia shared by several major carriers, covering the majority of Russian regions, so the probability of someone having any particular 7 digits in that area is pretty high. For example there's someone else registered in Skype with number +7904xxxxxx4, just one digit apart. I haven't been able to find an English source, but you can look at the list of carriers and regions in Russian in [1].

Also, US area code +1 904 matches the address in WHOIS records (both Jacksonville, FL), so at least it doesn't look like someone just changed the first digit and used their own Russian number.

[1] https://www.kody.su/mobile/904

AFAIK write_idx < read_idx case is handled automatically by doing the unsigned subtraction.

Power of 2 requirement stands, though.

That's so cool :) let me know if I got anything wrong with the device or geometry calculation! Also I would be happy to get any feedback from Steam VR people!

That's crazy :)

I was really inspired by that too! The tracking is comparable, but not on par yet - you need multiple sensors and IMU fusion to achieve the smoothness of Vive. This is only a first step :)

I needed to make some adjustments and fix some bugs there to make it work. It has the code, but it didn't work great indoor. I'll try to send these changes upstream when I have time. Let me know if you're interested in them - I can explain further.

The geometry calculation is currently approximate, not taking into account that the laser planes have ~3cm offset from center, that's one. Timing precision is probably the next one - microseconds might not be enough and we can measure better.

Currently std dev of each position coord in rest is 1.9mm.

Fusion with IMU is the next level and is usually done later down the line because it needs to be tuned for particular model. Yes, the drone does that.

Yes you're right, only position. I'm using acc/gyro/compass on the drone.

Thanks, yeah I need to tune it more, just wanted to share sooner :) I do have a blackbox there, that should help.

The cool thing is you can probably just use Teensy and my code to convert the envelope to 3d position. I haven't thought about that :)

Thanks! I actually haven't seen those, they look pretty good, basically replace the custom schematics I needed to build.

The timing calculation still needs to be done somewhere though, I wish there was a module that would do it internally and just publish the timing numbers - that would be more scalable and then even Arduino would be able to handle several sensors.

Nice project!

There's a whole bunch of indoor positioning methods, having different precision/simplicity/cost profiles, so you might need to shop around. Probably cheapest and closest to my sensor is ultrasound sensors like http://www.marvelmind.com

Thanks, that's nice to hear!

Seamless switching is definitely doable and shouldn't be hard, just need some time to implement. I'm using PX4 autopilot and it's very friendly for adding new functionality.

Orchestration is also close - in current demo both station and drone use Wifi to coordinate, so it's a matter of adding new logic.

Currently the most limiting resource for that project is my time :) I'd be happy if other people would want to join!