dpeckett

Absolutely, loss of deep sleep is associated with a ton of aging related cognitive decline. There's a number of startups experimenting with techniques to enhance deep sleep in the elderly atm (timed audio clicks, electrical stimulation etc).

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

Melatonin has a short half life (~1h), that's why melatonin receptor agonists [1] are a thing. So just mechanistically it's unlikely to help with sleep maintenance.

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

I'm pretty sure at this point I have familial advanced sleep phase syndrome of an unknown genetic etiology [1].

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

FWIW QUIC enforces TLS 1.3 and modern crypto. A lot smaller surface area and far fewer foot-guns. Combined with memory safe TLS implementations in Go and Rust I think it's fair to say things have changed since the heartbleed days.

How did you work around WireGuard's encryption and multiqueue bottlenecks? Jumbo frames?

25G is a lot for WireGuard [1].

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

Now that's an interesting, and wild, idea.

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.

I've recently spent a bunch of time working on a mesh networking project that employs CONNECT-IP over QUIC [1].

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

For TCP streams syscall overhead isn't a big issue really, you can easily transfer large chunks of data in each write(). If you have TCP segmentation offload available you'll have no serious issues pushing 100gbit/s. Also if you are sending static content don't forget sendfile().

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

Amen to that.

It's a different company paying each time ;)

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.

It's mind-blowing to think XDR / ONC RPC V2 were products of the 1980s, and that sitting here nearly forty years later we are discussing the same problem space.

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.

Now that's an interesting thought, I wonder if you could use a modified subset of TypeScript to create a IDL/DDL for JSON-RPC. Then compile that schema into implementations for various target languages.

I'd say the success of REST kind of proves that's something that for the most part can be worked around. Often comes down to the JSON codec itself, many codecs will allow unmarshalling/marshalling fields straight into long int types.

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.

To be honest I kind of find myself drifting away from gRPC/protobuf in my recent projects. I love the idea of an IDL for describing APIs and a great compiler/codegen (protoc) but there's just soo many idiosyncrasies baked into gRPC at this point that it often doesn't feel worth it IMO.

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.

The German pension system is completely insane. There is no fund backing it, and disbursements already exceed contributions to the tune of 127B EUR per year (which is subsidized from the general budget) and the gap is only growing.

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.

I think this is the fundamental cultural difference between countries like the USA (and Australia) vs most of the EU.

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.

Yep they're the technology equivalent of a discount supermarket. Everything is commoditized to the extreme.

Breath of fresh air in the modern cloud era tbh.

This is typical of Hetzner, if a product SKU is losing money they very quickly make changes, even going as far as to discontinue the product entirely (eg. GPU servers). They definitely don't seem to be a fan of loss leaders.

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.

That probably runs on Kubernetes (or Borg) under the hood.

Yeh nah mate, I'd recommend moving to the middle of nowhere in Aus over a low cost region in the EU. You really want to be in a long term growth environment (even if you're starting off at the bottom) than some decaying, economically deprived region. There's no free lunch in the western world.

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

velcro straps on the plate?

You can already do this trivially with Linux vcan[1] so I don't buy this argument.

I think the bigger factor is that innovation in the CAN ecosystem has been lagging behind Ethernet for decades now. Only reason it's had such staying power is industry inertia.

1. https://netmodule-linux.readthedocs.io/en/latest/howto/can.h...

It's a good thing we invented video compression and hardware codecs/encoders a long time ago.

What you'll actually be sending is a high bitrate mpeg stream, probably 54Mbps or thereabouts, you could probably fit 50x camera streams on a shared 10Gbps bus.

Doesn't matter what you want to call it but competition / research in the reusable launch sector is a good thing for all of us.

I think we very well could be in the kindling phase of another space race, https://www.youtube.com/watch?v=84KP_qPIgIw

Lord almighty, at-least the ATM machines here don't have opening hour restrictions.

Though ... https://www.ft.com/content/2778b6c4-4be7-4f38-acee-78f38feca...

Measuring at a single point in time is so inaccurate due to things as simple as circadian variation of blood pressure (morning surge, night time dipping, etc). Not to mention acute stressors, arm positions etc. It's hard to put any weight on a single reading, and tbh doctors already know this.

After some hypertension issues last year I bought an inexpensive ambulatory monitor (Contec ABPM50) for experimenting. Turns out the biggest contributor was likely undiagnosed sleep apnea, infact research suggests up-to 50% of essential hypertension cases are probably apnea related [1].

Sleep apnea is ridiculously common and significant apnea in young/middle aged individuals (particularly women) is associated with an up-to 5x increase in all causes mortality [2].

If have poor sleep, mental health issues (PTSD/anxiety/depression) and borderline/hypertension you should absolutely order something like a WatchPAT test. The odds of it coming back positive are probably 80%+. The STOP-BANG questionnaire is also pretty good: https://www.mdcalc.com/calc/3992/stop-bang-score-obstructive...

1. Chaudhary SC, Gupta P, Sawlani KK, Gupta KK, Singh A, Usman K, et al. Obstructive sleep apnea in hypertension. Cureus [Internet]. 2023 Apr 27; Available from: https://doi.org/10.7759/cureus.38229

2. Lavie P, Lavie L, Herer P. All-cause mortality in males with sleep apnoea syndrome: declining mortality rates with age. European Respiratory Journal [Internet]. 2005 Feb 28;25(3):514–20. Available from: https://doi.org/10.1183/09031936.05.00051504

Dietary fiber is well established to reduce the risk of Colorectal cancer [1]. If there's one thing that's seriously missing from an ultra-processed diet it's fiber.

Almost certainly multifactorial though.

1. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3926973/

Similar experience here, was WGS and running the results against ClinVar came up empty[1] for known disease causing variants. Was not expecting that at all.

But I totally think this is more an absence of information than anything else. We all have a ton of de novo variation and that stuff is not going to be found in the databases.

1. Am carrying two recessive variants linked to a couple extremely rare developmental disorders (prevalence in live births of less than 1 in 10,000,000)

Not to mention being self-employed here is a lot more complicated and expensive than in most jurisdictions. Things like having to meet strict professional definitions before being allowed to freelance (not usually an issue for engineers, but I know folks who've got into trouble because of the lack of a bachelors degree).