dpeckett
Joined 11 years ago
Joined 11 years ago
There's not a lot of evidence that most common sleep medications are associated with long term improvements in health outcomes. Most have substantial detrimental effects on sleep architecture, can exacerbate underlying issues like apnea etc. Interesting the gabapentanoids (chronic pain) and Xyrem (narcolepsy) are associated with increased slow wave sleep. More research is needed (eg the DORA drugs [1]).
Thankfully circadian issues (in the absence of sleep loss) aren't associated with negative health outcomes. Just a case of finding a way to modify ones life to accommodate them.
Do you wake up after 5.5h at a consistent time of the day and the first half of the night is peaceful? If you fall back asleep do you then wake again shortly after?
I mean waking in the night can be many things (apnea, etc), but you could very well have a rather advanced sleep phase.
Wake up stupid early in the morning, get drowsy very early in the evenings etc. For a long time due to social pressure/habit I'd just power through the evening drowsiness. That lead to me only being able to sleep six hours or so (due to waking up stupid early), which over time lead to a substantial sleep debt.
Going to bed early helps a lot, but over time it seems like I easily start drifting earlier and earlier. I've recently had some success stabilizing my rhythm using sublingual melatonin when I first waken at 2-3am. Let's me get a couple extra hours of additional quality sleep which is a lifesaver. Wears off quick enough that by 9am or so it's basically out of my system.
I've actually been tinkering/hacking the last year or so on sleep tracking wearables. Initially focused on EEG/HRV monitoring but I'm taking a very modular approach and ultimately want to build a full set of sensors/effectors/etc.
I've recently been experimenting a lot with skin temperature gradients, turns out in the lead up to sleep it's not just blood flow in the brain that is altered [2].
1. https://en.wikipedia.org/wiki/Advanced_sleep_phase_disorder#...
2. https://journals.physiology.org/doi/pdf/10.1152/ajpregu.2000...
25G is a lot for WireGuard [1].
I don't believe you could implement RFC 9484 directly in the browser (missing capsule apis would make upgrading the connection not possible). Though WebTransport does support datagrams so you could very well implement something custom.
There's a lot of benefits for sure, mTLS being a huge one (particularly when combined with ACME). For general purpose, spoke and hub VPN's tunneling over QUIC is a no-brainer. Trivial to combine with JWT bearer tokens etc. It's a neat solution that should be used more widely.
However there are downsides, and those downsides are primarily performance related. For a bunch of reasons, some just including poorly optimized library code, others involving relatively high message parsing/framing/coalescing/fragmenting costs, and userspace UDP overheads. On fat pipes today you'll struggle to get more than a few gbits of throughput @ 1500 MTU (which is plenty for internet browsing for sure).
For fat pipes and hardware/FPGA acceleration use cases, google probably has the most mature approach here with their datacenter transport PSP [2]. Basically a stripped down per flow IPsec. In-kernel IPsec has gotten a lot faster and more scalable in recent years with multicore/multiqueue support [3]. Internal benchmarking still shows IPsec on linux absolutely dominating performance benchmarks (throughput and latency).
For the mesh project we ended up pivoting to a custom offload friendly, kernel bypass (AF_XDP) dataplane inspired by IPsec/PSP/Geneve.
I'm available for hire btw, if you've got an interesting networking project and need a remote Go/Rust developer (contract/freelance) feel free to reach out!
1. https://www.rfc-editor.org/rfc/rfc9484.html
2. https://cloud.google.com/blog/products/identity-security/ann...
3. https://netdevconf.info/0x17/docs/netdev-0x17-paper54-talk-s...
UDP is a whole another kettle of fish, get's very complicated to go above 10gbit/s or so. This is a big part of why QUIC really struggles to scale well for fat pipes [1]. sendmmsg/recvmmsg + UDP GRO/GSO will probably get you to ~30gbit/s but beyond that is a real headache. The issue is that UDP is not stream focused so you're making a ton of little writes and the kernel networking stack as of today does a pretty bad job with these workloads.
FWIW even the fastest QUIC implementations cap out at <10gbit/s today [2].
Had a good fight writing a ~20gbit userspace UDP VPN recently. Ended up having to bypass the kernels networking stack using AF_XDP [3].
I'm available for hire btw, if you've got an interesting networking project feel free to reach out.
1. https://arxiv.org/abs/2310.09423
2. https://microsoft.github.io/msquic/
3. https://github.com/apoxy-dev/icx/blob/main/tunnel/tunnel.go
I'm actually super excited to see how https://www.sovereign.tech turns out long-term. Germany has a lot of issues with missing the boat on tech, but the sovereign tech fund is such a fantastic idea.
Probably the biggest challenge with something like XDR is it's very hard to maintain tooling around it long-term. Nobody wants to pay for forty years of continuous incremental improvement, maintenance, and modernization.
Long term this churn will hopefully slow down, it's inevitable as we collectively develop a solid set of "engineering principles" for the industry.
Also JS now has BigInt types and the JSON decoder can be told to use them. So I'd argue it's kind of a moot point at this stage.
Recent Projects: https://github.com/apoxy-dev/icx