• 1 Post
  • 10 Comments
Joined 3 years ago
cake
Cake day: June 15th, 2023

help-circle
  • Idk the model but can check later. Removing/modifying it isn’t an issue, but my household wants to use it since it’s there.

    I’m not personally opposed to a camera but would need to be in full control of the feed. My main goal is keeping it simple and cheap for now, so not replacing a functional camera is very tempting. Later on I can look into real alternatives but an afternoon project will do for now.




  • Couple of reasons of varying importance:

    • Security. Even when you limit operations or table access it’s very easy to mess something up. Some new employee starts storing sensitive data in the wrong place or a db admin accidentally turns off the wrong permissions, etc…
    • It’s secretly more overengineered than a standard api despite looking simpler. If your app needs extremely robust query capabilities then you probably have a use case for an entire analytics stack and could use an open source option. Otherwise your users probably just need basic search, filtering, sorting, etc…
    • Ungodly, Flex Tape tier tight coupling. Part of the purpose of an api is to abstract away implementation details and present a stable contract. Now if you want to migrate/upgrade the database or add a new data source, everyone has to know about it and it’s potentially a major breaking change.
    • Familiarity. If someone else steps in to maintain it it’s much easier to get up to speed with a more standard stack. You don’t need a seven layer salad of enterprise abstraction bullshit, but it’s useful to see a familiar separation of auth, queries, security, etc…
    • Having the option to do business logic outside of the database can save countless headaches. Instead of inventing views or kludging sprocs to do some standard transformation, you can pull in a mature library. Some things, such as scrubbing PII, are probably damn near impossible without a higher tier layer to work in.
    • Client support. Your browser/device probably has a few billion options for consuming a REST/HATEOAS/graphql/whatever api. I doubt there’s many direct sql options with wide support.

    I probably wouldn’t do it outside of a tiny solo project. There are plenty of frameworks which do similar things (such as db driven apis) without compromising on flexibility, security or features.



  • Cool cool, now just need to wire it up to every common command and make a custom best-effort fallback so I never have to think about it (except for when it inexplicably breaks in 6 months and I need to fix it again).

    Gonna get down voted to hell for this, but it’s my main gripe with daily driving Linux: to get a semblance of QoL you either monkey patch a brittle solution or dedicate your finite time and memory to learning the song and dance of each tool.

    I know it’s not fair to gripe about freely supported open source software, but dev tooling has advanced an incredible amount since the old hackathon days. We need better efforts around modular integration and UX to really get widespread adoption.



  • You keep saying this like it’s a gotcha when even the barest level of research shows that it’s still better.

    Emissions from battery production can vary wildly depending on the process used and manufacturing energy grid. According to this study, manufacturing an 80kWh battery will release between 2400kg and 16,000kg of CO2. A commercial lawnmower will have a ~20kWh battery, so in a lifetime with two batteries we’ll guess about 1200-8000kg CO2.

    EPA says the average gas mower produces 88lbs of CO2 per hour of use. Over a 2000 hour commercial lifespan that’s 80,000kg of CO2. And that’s putting aside all the other pollutants and secondary emissions from maintaining a combustion engine.

    Do a little research before you start your rants next time.