3 ms·

The whole idea here is superlative. +1 for k8s, kubernetes, cloud native, self-hosted, edge-enabled at low cost, no cost. I ran rq and minio for years on k8s,

The whole idea here is superlative. +1 for k8s, kubernetes, cloud native, self-hosted, edge-enabled at low cost, no cost. I ran rq and minio for years on k8s, but been watching sqlite as a drop-in-replacement since most of my work has been early stage at or near the edge. Private cloud matters. This is an enabler. We've done too much already in public cloud where many things don't belong. BTLE sensors are perfectly happy talking to my Apple Watch directly with enough debugging. I'd argue the trip through cloud was not a win and should be corrected in the next generation of tools like this, where mobile is already well-primed for SQLite.

memset 2y ago
Really interesting. Question: when it comes to running these software on k8s, do you prefer to manage and host yourself, or do you use managed solutions on top of your own infra? (Do you pay for minio support?) Asking from a business perspective - I of course intend to keep developing this, but am also really trying to think through the business case as well.
- davidthewatson 2y ago
  Good question! The answer depends on funding, i.e. in my own never-leaves-my-house case it is always self-host, much like SOC work. In the case of startup or research lab work (day-job, for lack of a better descriptor). It's frequently a slice of AWS, GCP, or Azure, i.e. 6 figure/mo cloud bills. I think those two broad cases are worth considering.
- cpill 2y ago
  k3s for on premises deployments. I'm also using it for local self hosting side projects.
  - davidthewatson 2y ago
    Definitely a fan of k3s as k8s lite - complexity that your particular project may not need, particularly since every project doesn't need k8s and many are better off with less. If you look at the history from J2EE to the k8s prototype in Java to what we have now, it's a great idea to encapsulate all of these things into a single container, particularly at Google scale, but many unintended consequences arise from complexity accruing to features and functions which weren't actually requirements for your particular project being supported, i.e. the notion that YAGNI because few orgs have Google scale problems. If so, great! Carry on... If not, consider k3s or aptible or more emergent platforms I haven't actually used. The mere presence of unneeded items in source and documentation presents a "why am I here?" choice paradox. That's before we even get into keeping track of deprecations in the never-at-rest source/release evolution. Federation is a good example. I've worked at places that needed it and places that didn't.
- kmacdough 2y ago
  Managed systems make a lot of sense in small companies, where keeping head count down is the key to agility & communication. For personally funded projects it's never worth the cost and for big teams (100+) its typically worth the savings to self-host IF you can find good people. Low quality/rushed/novice self-hosting is almost never a good idea for any size company.
pfix 2y ago
rq as in Redis Queue?
- sieabahlpark 2y ago
  [dead]
- philsnow 2y ago
  I had assumed https://github.com/rqlite/rqlite https://github.com/rqlite/rqlite
  - davidthewatson 2y ago
    I linked Redis Queue on the previous reply but had not heard of rqlite so thanks for this! It looks like this may solve at least another part of my quest to replace various back-ends with sqlite.
- davidthewatson 2y ago
  That's right! https://python-rq.org/ https://python-rq.org/
raihansaputra 2y ago
can you share more about the BTLE sensors talking with Apple Watch? I'm aware that BLE heartrate sensors are detected as 'Health Devices' if I want to connect to it, but what other sensors are you working with?
- davidthewatson 2y ago
  Yes, thanks for asking. Continous Glucose Monitors (CGM). That used to be a diabetic-only problem until Abbott, Dexcom,and other vendors expanded their markets beyond diagnosed diabetics into pre-diabetes markets and exercise, health, and well-being applications like: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10635370/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10635370/ and: https://www.levelshealth.com/ https://www.levelshealth.com/ This has exploded beyond the hundred years of ketogenic research and as research on glycemic variability in mental health has grown. My current kit includes an Apple Watch series 9 and an iPhone SE. Prior to that it was Google Pixel and a Fitbit Sense, though direct BTLE->Watch was not an option in that generation. I have two complications: Abbott Freestyle Libre 3 and Dexcom G7. Continuous Glucose Monitors (CGM). The Dexcom is entirely proprietary. The Abbott is accomplished via a series of 3rd party hacks: https://www.youtube.com/watch?v=YqUZjXo5VXY https://www.youtube.com/watch?v=YqUZjXo5VXY I'd say open source, but I'm not certain that every link in the chain is open source. I've run many generations of various open source tools on Android and iPhone since no vendor ships a complete end-to-end solution that is perfect. Nightscout and watchdrip are two open source examples: https://nightscout.github.io/ https://nightscout.github.io/ https://watchdrip.org/ https://watchdrip.org/ When G7 originally shipped last year, sensor data left the sensor and used the iPhone as a proxy-to-cloud storage, as has become the default mode across many IoT devices because it was easy, obvious, despite the unintended consequences of the design choices here. At that point, because the data has already taken a long and perilous journey into cloud when BTLE->Watch was dramatically shorter, cheaper (in terms of hops and requirement for service), and arguably better. Hence, any data request pays that full routing price into and out of cloud, even the most trivial display, such as watch. After a latent Dexcom BTLE->Apple Watch update a year later, I don't even need to carry my iPhone anymore, despite the fact that I don't have service beyond WiFi on my Apple Watch, since the data exchange is entirely BTLE. The sad fact is that straightforward questions around a person's glycemia were not answerable directly without an entire belt-worn cloud ecosystem being paid for and fully functional 24x7x365. BTLE->Apple Watch is by no means perfect, but it's dramatically better than my previous 5 years of 24x7x365 routing through cloud. HTH!

memset 2y ago

Really interesting. Question: when it comes to running these software on k8s, do you prefer to manage and host yourself, or do you use managed solutions on top of your own infra? (Do you pay for minio support?) Asking from a business perspective - I of course intend to keep developing this, but am also really trying to think through the business case as well.

davidthewatson 2y ago
Good question! The answer depends on funding, i.e. in my own never-leaves-my-house case it is always self-host, much like SOC work. In the case of startup or research lab work (day-job, for lack of a better descriptor). It's frequently a slice of AWS, GCP, or Azure, i.e. 6 figure/mo cloud bills. I think those two broad cases are worth considering.
cpill 2y ago
k3s for on premises deployments. I'm also using it for local self hosting side projects.
- davidthewatson 2y ago
  Definitely a fan of k3s as k8s lite - complexity that your particular project may not need, particularly since every project doesn't need k8s and many are better off with less. If you look at the history from J2EE to the k8s prototype in Java to what we have now, it's a great idea to encapsulate all of these things into a single container, particularly at Google scale, but many unintended consequences arise from complexity accruing to features and functions which weren't actually requirements for your particular project being supported, i.e. the notion that YAGNI because few orgs have Google scale problems. If so, great! Carry on... If not, consider k3s or aptible or more emergent platforms I haven't actually used. The mere presence of unneeded items in source and documentation presents a "why am I here?" choice paradox. That's before we even get into keeping track of deprecations in the never-at-rest source/release evolution. Federation is a good example. I've worked at places that needed it and places that didn't.
kmacdough 2y ago
Managed systems make a lot of sense in small companies, where keeping head count down is the key to agility & communication. For personally funded projects it's never worth the cost and for big teams (100+) its typically worth the savings to self-host IF you can find good people. Low quality/rushed/novice self-hosting is almost never a good idea for any size company.

pfix 2y ago

rq as in Redis Queue?

sieabahlpark 2y ago
[dead]
philsnow 2y ago
I had assumed https://github.com/rqlite/rqlite https://github.com/rqlite/rqlite
- davidthewatson 2y ago
  I linked Redis Queue on the previous reply but had not heard of rqlite so thanks for this! It looks like this may solve at least another part of my quest to replace various back-ends with sqlite.
davidthewatson 2y ago
That's right! https://python-rq.org/ https://python-rq.org/

raihansaputra 2y ago

can you share more about the BTLE sensors talking with Apple Watch? I'm aware that BLE heartrate sensors are detected as 'Health Devices' if I want to connect to it, but what other sensors are you working with?

davidthewatson 2y ago
Yes, thanks for asking. Continous Glucose Monitors (CGM). That used to be a diabetic-only problem until Abbott, Dexcom,and other vendors expanded their markets beyond diagnosed diabetics into pre-diabetes markets and exercise, health, and well-being applications like: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10635370/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10635370/ and: https://www.levelshealth.com/ https://www.levelshealth.com/ This has exploded beyond the hundred years of ketogenic research and as research on glycemic variability in mental health has grown. My current kit includes an Apple Watch series 9 and an iPhone SE. Prior to that it was Google Pixel and a Fitbit Sense, though direct BTLE->Watch was not an option in that generation. I have two complications: Abbott Freestyle Libre 3 and Dexcom G7. Continuous Glucose Monitors (CGM). The Dexcom is entirely proprietary. The Abbott is accomplished via a series of 3rd party hacks: https://www.youtube.com/watch?v=YqUZjXo5VXY https://www.youtube.com/watch?v=YqUZjXo5VXY I'd say open source, but I'm not certain that every link in the chain is open source. I've run many generations of various open source tools on Android and iPhone since no vendor ships a complete end-to-end solution that is perfect. Nightscout and watchdrip are two open source examples: https://nightscout.github.io/ https://nightscout.github.io/ https://watchdrip.org/ https://watchdrip.org/ When G7 originally shipped last year, sensor data left the sensor and used the iPhone as a proxy-to-cloud storage, as has become the default mode across many IoT devices because it was easy, obvious, despite the unintended consequences of the design choices here. At that point, because the data has already taken a long and perilous journey into cloud when BTLE->Watch was dramatically shorter, cheaper (in terms of hops and requirement for service), and arguably better. Hence, any data request pays that full routing price into and out of cloud, even the most trivial display, such as watch. After a latent Dexcom BTLE->Apple Watch update a year later, I don't even need to carry my iPhone anymore, despite the fact that I don't have service beyond WiFi on my Apple Watch, since the data exchange is entirely BTLE. The sad fact is that straightforward questions around a person's glycemia were not answerable directly without an entire belt-worn cloud ecosystem being paid for and fully functional 24x7x365. BTLE->Apple Watch is by no means perfect, but it's dramatically better than my previous 5 years of 24x7x365 routing through cloud. HTH!