• 0 Posts
  • 36 Comments
Joined 2 months ago
cake
Cake day: March 10th, 2026

help-circle
  • Every discussion I have seen on the subject says that docker ipv6 is pretty busted from a security perspective and you have to implement a bunch of workarounds.

    I don’t have to time both to migrate to podman (and maybe have to run dual stacks for what isn’t available) AND migrate to ipv6. But apparently the way podman does it is also kind of a hacky way (I am far from a networking expert) so I will sit with my pretty decent, secure, and working ipv4 lol


  • One thing that people often forget is TVs / stream boxes and Alexa/google assistants.

    Smart TVs all have microphones that are recording (for “voice commands”) and the same with the remotes for stream devices (though probably not unless asked because of battery life), also google and Alexa’s are constantly always listening. They are simply spyware devices that parse everything you say and hand it to advertisers, insurance, governments, etc…

    Phones also suffer from the battery life problem, so jury is still out on whether they listen to you because constantly recording audio would degrade battery life quite a bit (though maybe it is factored in). Phones absolutely do share location data and any phones discovered on the same WiFi network or in the same location if that data was available and from there will share entire search history of devices on the same network (well, that is on the data center end, phones likely just send what devices and for how long they were together). From there it is quite easy to advertised based on search history, unencrypted text data, etc…

    For example in OP, OP had likely searched around about cars and checked out manufacturers websites and such before meeting with the parents (unless they were going in completely blind to dealerships), so it would have shared exactly the cars that they were looking at and linked it to the parents for advertising.

    Still fucked, ethically wrong and legally grey, but “listening” is a bit of an inefficient way to do it, generally.


  • Can you provide one or elaborate on it?

    Embedded developers have tried all manner or wizardry to simply track speed, not even position based just on an accelerometer/gyro, but the sample rate error drift is so large that putting a GPS module in there is 100x more accurate for deriving speed.

    I would be interested to see how a browser, which almost certainly doesn’t get the full serialized data, is able to track just based on that which the wearables industry have been trying for decades with bad results.






  • Yes, but also on the hardware level.

    I don’t know enough about OS programming to know if it is the architecture or the (closed source, as mentioned) CPU design itself that is more difficult to implement.

    Looking at the MCU space, even with a known architecture (like ARM), each processor has to be individually implemented in software and firmware which is a ton of work, and the only people who necessarily know how are the processor designers unless it is open source. But take that with a big block of salt, because I have never done it, just looking at industry practices.










  • Having done a lot of research into this, the state of things sucks right now. The current open-source options have very bad tracking (like, just a very rough estimate) and are much more focused on smart-watch interfaces, which I get because having made a smart watch development board myself, PPG AFEs are a black hole of NDA-riddled bullshit, manufacturer lies and bad documentation, and no support (looking at you Analog Devices). ZSWatch is the most promising open source project using the best openly - available sensor set with the potential to hit 80% heart rate accuracy, but that is still years away.

    Honestly for half-good tracking, your best bet js Gadgetbridge + a proprietary smart device that is entire locally supported.

    For example, the 100€ Amazfit Helio Strap (no screen) has great heart rate tracking and better than average sleep tracking (old strap style or bicep strap) and you can run it once in the official app to update firmware and extract the encryption keys, then from then on run it completely locally on gadgetbridge and uninstall the official app completely.

    Letting perfect be the enemy of good enough sadly leads to almost useless tracking data in the open source wearables world. For now at least. Making wearables is insanely expensive and to get the best sensors you need NDAs and quantities >10k per year which is unobtainable for community open source projects right now, and you need massive amounts of user data to build good algorithms to analyze the data from the sensors.



  • Cool project! Epaper is awesome and crazy microfluidic tech.

    The M5stack M5paperS3 is 60€ (56,70€ at Tinytronics in NL) and is auch more readable size, integrated battery, 4.7inches. More like an older smartphone screen and have very fast refreshing.

    Nicco loves Linux (KDE contributor and a sort of blogger) made a whole to-do app/system that runs on it so it is temporarily out of stock at Tinytronics, but I think the problem with the small screen is having to refresh >3x as much to read the same amount killing battery life on an already smaller battery.

    I think personally I would have trouble either with font size, or only being able to read a few sentences before scrolling.