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.

1. https://en.wikipedia.org/wiki/Orexin_antagonist

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.

1. https://en.wikipedia.org/wiki/Melatonin_receptor_agonist

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].

1. https://www.youtube.com/watch?v=oXhNVj80Z8A

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.

Been increasingly using LSP style JSON-RPC 2.0, sure it's got it's quirks and is far from the most wire/marshaling efficient approach but JSON codecs are ubiquitous and JSON-RPC is trivial to implement. In-fact I recently even wrote a stack allocated, server implementation for microcontrollers in Rust https://github.com/OpenPSG/embedded-jsonrpc.

Varlink (https://varlink.org/) is another interesting approach, there's reasons why they didn't implement the full JSON-RPC spec but their IDL is pretty interesting.

Probably explains a good chunk of Germany's and the EUs anemic growth. Simply put, that's 127B EUR that can't be spent investing in the future and growing the economy.

Folks here expect and trust the state to provide for the future, private provisions are easily dismissed as unnecessary. As a result of this the median household wealth of the area I live in is 5x lower than my home country of Australia, despite incomes (adjusted for purchasing power) not being drastically different.

Whether that trust is wisely placed we'll have to wait and see[1]. However I do need to narrow that down a bit, it's not the whole EU, mostly France/Germany. There are other nations moving ahead with private pension schemes etc and much higher household wealth (Denmark, Sweden, Netherlands).

1. My main concern is government investment is inherently slow, politically charged, and pathologically risk averse vs the private sector. This means in the aggregate, over the long term, private household investments will out perform.

Breath of fresh air in the modern cloud era tbh.

I'm guessing somehow the traffic usage patterns of their USA customers was very different to their EU counterparts, or the cost of expanding network capacity was a lot higher than anticipated.

It's a bit of a shock for sure but it seems this model is a big part of how they can maintain their slim margins.

I'm an Aussie living in a relatively low cost region in the EU, I moved here for career and networking/ecosystem reasons. That aspect of the move have definitely paid off in multiples but there's no doubt that QoL is significantly lower here and the tax rates on income are double what you are used to (a lot goes to social programs that as an immigrant you have limited entitlement to).