agentx3r

In Canada we have these refillable prepaid VISA cards https://www.koho.ca/. Not a plug, but it's honestly solved money management for us.

Every week, my wife and I load some amount into the 'joint' card, and a smaller onto the personal cards. The joint card is for necessities, the personal cards are for fun. It's much more convenient than the cash envelopes we were doing before.

Credit cards don't work for us because it's too easy to cheat, and you only have to feel guilty when you square up the tracking. With the prepaid cards, you get a much harsher signal when you're over budget.

I've been using AWS Route53 DNS for my domain for many years, very cheap and easy to automate a DDNS setup if desired (e.g. https://crazymax.dev/ddns-route53/)

Yes, making me migrate manually means I'm very likely to migrate to Outlook365

If you want to try some modern-er noir, American Tabloid by James Ellroy is a wild ride.

Someone donating large amounts of money to charity just to write it off on their taxes isn’t doing so altruistically

I mean, it's still altruistic because they're going to 'lose wealth' by donating. You're never going to earn back in tax write-offs as much as you spent by donating.

most accessible device these days is probably the realsense

Disclaimer, I like the snap packaging format, and I'm not familiar with the history of launchpad.

Operationally:

- I can trivially host and control my own apt repository, either as a mirror of some upstream repository, or with bespoke packages.

- I can't do the same with snaps.

So launchpad and snap store isn't quite apples-to-apples. It would help of course if a snap store could be statically hosted or re-implemented, but the full API is quite complex.

Hear hear. I imagine for dogfooding, LXD is only packaged in snap, so we can't use apt as the source anymore. After migrating, an upstream push to a 'stable' LXD snap channel introduced a regression that borked our environments, and there was no way to:

1. prevent machines in the fleet from pulling the broken LXD update

2. rollback broken machines to the previously working LXD version on the same channel, since it no longer existed in the Snap Store™.

What a joke! Now we're burnt on snap _and_ LXD.

Foundational seems like a strong word here - this is a thin wrapper on top of two popular components from ROS (Navigation and MoveIt), and bringup for a specific robot (LoCoBot).

I appreciate the effort here though - ROS feels like it's become harder to use due to stale documentation, and there's value in providing a simple python API that abstracts the underlying bringup.

However looking through the wrapper and its documentation, it doesn't feel like it's making it much simpler by hiding away standard ROS tools.

I really love the ideas/architecture behind Concourse, but there's a few things that disqualified it in favour of Jenkins for a new CI pipeline during prototyping:

- no hooks to manage worker scaling (https://github.com/concourse/concourse/issues/993). Our builds are _heavy_ and we'd run up an enormous AWS bill without something like (https://wiki.jenkins.io/display/JENKINS/Amazon+EC2+Plugin)

- no way to restart a build, resorting to 'empty commits', which is a huge red flag for useability (https://github.com/concourse/concourse/issues/413)

- limited documentation/examples (network effect)

Trump is a symptom, not the disease.

I imagine it's more practical to try to 'get out the vote' without all the marketing in the middle, than try to bribe a person to vote against their interest.

For n=1, sure, not necessarily.

If you have two systems generating UUIDs, and their probability distributions are non uniform and overlap in any significant fashion, then your odds of collision are no longer on the order of 'heat death of the universe'.

TIL only version 4 is generated using a random source.

If you used UUID() for data that is supposed to be secret (like passwords), you have a serious problem, as these secrets can now be easily guessed.

I've never used UUIDs for secrets, but I've often dependended on UUIDs to be uniform - as the primary identifier when passing data around inside distributed systems. If the chance of collision is implementation dependent, that could end really badly.

Ubiquiti makes great prosumer stuff, if you're willing to pay ~$120 for the 'router', and then another ~$100 for the wireless access point. That's not 'cheap', but it's about on par what you'd pay for a fancy consumer router that looks like a spaceship.

You'll get a great interface, frequent firmware updates with new features and security fixes, and you'll have a good strong signal at your neighbour's house if you're going for a visit.

I've been using Lineage on my oneplus 3 for some time, and it's very stable. https://wiki.lineageos.org/devices/cheeseburger

Likely refers to sensor fusion (https://en.wikipedia.org/wiki/Sensor_fusion), which is an algorithmic process.

A 4-hour MTBF window (even for a subsystem) is terrifying considering modern vehicles like this are likely all fly-by-wire.

At the point when the system is unable to analyze the static environment (e.g. lane markers) due to poor visibility, it's probably unable to analyze and deal with dynamic situations safely.

Traffic lights will often have sensors to prevent switching when no cross traffic is waiting. There are also centrally controlled systems that incorporate adaptive control methods. (http://en.wikipedia.org/wiki/Traffic_light_control_and_coord...).

I think key infrastructure would probably be best left unexposed to the Internet, firewalled or not.