There are some. One of my favourites is Terminal.Gui[0], but you have to be in the .NET world in order to use it.
3,822 karma · joined July 24, 2013
One of the things that impresses me the most is exemplified by these two examples:
> [...] including for example the issue of my elementary school magazine from Easter 1971.
> [...] school geography notes from when I was 11 years old, together with the text of a speech I gave
When he was 11 he had the foresight to realize that he might want to refer back to this stuff and decided to keep it and store it somewhere that it could be found again. When I was 11 I'd have likely thrown it out during the end-of-year desk/locker clean out and not given it a second thought.
While I don't necessarily aspire to his level of productivity, I'm very envious of how meticulous his record keeping is. Whenever I try to get organized like this I quickly get overwhelmed and give up.
On the official client I can specify DNS servers for a particular connection, so one "easy" solution would be to specify domains that need to go to that set of DNS servers. e.g., when connected to home use 192.168.x.y to resolve *.blah, otherwise use the system resolvers.
Right now the thing that's stopping me is the lack of Split-DNS. I'd even be happy if I could configure this in the official client, I've only got a handful of devices so distributing the configuration by hand is fine. My IKEv2/IPSec set up does this perfectly, and using MDM profiles lets me set up connect-on-demand. WireGuard already does connect-on-demand and my limited testing suggests that it works well enough.
I don't want to use Tailscale since I'd like to keep everything self-hosted. It sounds like Headscale is almost there - it just needs the iOS client to be able to point to an arbitrary endpoint.
That doesn't tell me anything about how the actual protocol works though. I still need to buy an IR receiver and start decoding the protocol.
The Comfee was very easy to automate. I just grabbed an ESP32 board that I had handy, some parts out of my bins, and soldered up a working IR blaster. ESPHome provided all of the hard parts, Home Assistant provided the UI. It works brilliantly. I have the air conditioner on a smart outlet which gives me real-time power consumption information, from here it's easy to determine what the machine is doing. I also have a Xiaomi temperature/humidity/pressure sensor, which I can use to feed into automations to control the unit if I want to.
So far I've been unsuccessful at using an IR blaster to control the LG - ESPHome, out of the box, can't seem to control this unit. I haven't gone down the rabbit hole of capturing IR codes, but that's the next step once I get the appropriate parts.
Apart from being a 3rd-party service, which isn't really what I want, it seems to check all of the boxes. The documentation is very thin on the iOS side, but it seems likely that the iOS app can do everything that can be configured in the admin console. That configuration does seem to meet my requirements.
Is there a self-hosted Tailscale-like option?
The only other thing is automatic connection. In my IKEv2/IPSec setup, I've build configuration profiles for the iOS devices so that they'll establish a connection on-demand (triggered by a DNS lookup for my internal domain), but only when they're not on my home Wifi network. It's perfectly seamless since it's all built-in to iOS. The Wireguard app seems to deal with the "connect when not on home Wifi" part, but doesn't do the on-demand side. Wireguard is light enough that this may not actually matter though.
Getting it set up was really easy. I think it took about an hour, which included standing up a new OpenBSD VM to run the server. Configuring clients (iOS) was pretty straight-forward and reasonable. I don't have a feeling that there's some security hole lurking in the configuration simply because there's not a lot to get wrong.
In comparison, IKEv2/IPSec was incredibly painful, especially when you also create configuration profiles for iOS and have to issue and distribute certificates. Once I understood how it worked it made some sense, but there's always that nagging feeling that I've screwed up the configuration because there's just so many options to get wrong. I've probably spent six hours, not all at once of course, getting it working and set up "just so."
In spite of all of this, I'm continuing to use my IKEv2/IPSec setup. I have not figured out how to get WireGuard to do split DNS, whereas this was a fairly simple part of the IKEv2/IPSec setup. The other requirement I have is split tunnels, but I think WireGuard can do that fairly easily.
My debit card and its PIN are used for a few different things - in-store payments, using the ATM, and authenticating when in-person at a bank. The last one is interesting - each desk at the bank, both the tellers and the offices where you talk to someone, has a terminal and every interaction starts with putting in your debit card and entering your PIN.
Extending this to credit card is no big deal - my main bank syncs the PIN between the debit and credit cards. I only have a credit card with the other bank that I use and I haven't set foot in one of their branches in 20 years, so I have no idea whether they sync the PINs or use their cards for in-person authentication.
Maybe it's because the prevalence of Interac already trained us to deal with PINs.
Here in Alberta, it's the law that you need to pay before you pump[0]. If you're at a modern pump you insert your card, it does a preauth for some amount (you can select common amounts, like $20 of fuel, or "fill up" which is like $125 or $250 depending on the station), then when you're done it does a purchase for the exact amount.
If you're not at a modern pump, or you're paying cash, you have to go into the store, prepay for something that you think will fill your tank, fill your car, then go back into the store and get your change.
[0] https://calgary.ctvnews.ca/station-owners-and-gas-and-dash-v...
Merchants started getting chip terminals as part of the regular replacement cycle, consumers started getting chip cards as part of that regular replacement cycle, and eventually the terminals started telling users to insert their card.
Interac was the first mover because most people were already familiar with swipe and pin, so the move to chip and pin was a virtual non-event. When the credit card companies moved the issuing banks had to issue PINs, but everyone already knew the mechanics of using it.
The most interesting part is that the US already has the infrastructure to support this. I went to a Walmart in the US and paying with my Canadian credit card worked EXACTLY like it does in Canada - insert card, confirm amount, enter PIN, done. The cashier was a little confused that I didn't need to sign for it, but ultimately they just went with it.
The introduction of NFC was a similar non-event.
I'd like to go this route as well. I've got a domain and Fastmail checks all the boxes for me, but inertia is a powerful thing.
I like think of each entry as the complete journal entry - a set of debits (abbreviated DR) and credits (abbreviated CR) that describe an event. Debits and credits are, as many accounting instructors have taught many students, names that effectively mean "Left Side" and "Right Side". Some accounting systems represent debits as positive numbers and credits as negative numbers - this is perfectly valid too.
Say somebody purchases a product for $60 and a service for $40 from me. The product that I sold cost me $40 to purchase, and both the product and service have a 5% sales tax applied. This is a very common transaction - car repairs, for example, are usually a combination of products (e.g., oil, oil filter) and services (e.g., oil change and inspection).
Account DR CR
Cash in bank 105
Tax Payable 5
Sales Revenue 60
Services Revenue 40
Cost of Goods Sold 40
Inventory 40
This is, in my mind, one "entry" which has six detail lines to recognize all of the different things that need to be recorded for this event. The important point is that everything balances, credits always equal debits.
Some businesses might not do the Cost of Goods Sold / Inventory entries with each transaction, instead they might count their inventory once a month and calculate out how much they sold (inventory at start + inventory purchased - inventory at end = cost of goods sold) and just do one entry a month to get the books in sync with reality.
* There's no reasonable way to do cross-batch dependencies (e.g., if process X in batch A fails, don't run process Y in batch B). I've got a few ideas on how I could add this in, but nothing has been implemented yet.
* There's no easy way to visualize what's going on. Airflow has a Gantt view that looks very useful for this purpose, our business users would absolutely LOVE the task duration graph, and the visualization of the DAG looks really helpful too.
* Continuing a failed batch is a very manual process.
None of these are showstoppers because, as you said, this has been running fine for over a decade. These are mostly quality-of-life improvements.
I didn't pursue this very far as there were other problems with doing this, but I'd like to pursue it again. The problems are all with the target system, `make` does the parallel execution work perfectly.
https://web.archive.org/web/20110606144530/http://www.ibm.co...
There’s a reference to some sample Makefiles to start and stop some Linux services in parallel. It’s obviously not complete, but this (or something similar) was what inspired my system.
> Airflow was started in October 2014 by Maxime Beauchemin at Airbnb. It was open source from the very first commit and officially brought under the Airbnb GitHub and announced in June 2015.
I believe I starting building my tool somewhere around 2010, possibly 2011. The core mechanism has been completely unchanged in that time. If Airflow was a thing at the time, I'd have hopefully looked into it. I looked at a handful of similar products and didn't find anything that was a good fit.
Based on a really quick skim of the Airflow docs it seems like it checks all of the boxes. Off the top of my head:
* LocalExecutor (with some degree of parallelism, assuming the dependencies are all declared properly) seems to do exactly what I want.
* I could write an Operator to handle the interaction with the system where the processes actually run. The existing Python script that does this interaction can probably get me 90% of the way there. Due to the nature of what I'm running, any job scheduler will have to tell the target system to do a thing then poll it to wait for the thing to be done. To do this without any custom code, I could just use BashOperator to call my existing script.
* It's written in Python, so the barrier to entry (for me) is fairly low.
* Converting the existing Makefile to an Airflow DAG is likely something that can be done automatically. We deliberately keep the Makefile very consistent, so a conversion program can take advantage of that.
I think my dream of replacing this might have new life!
Most of the targets in the Makefile had a command to kick off the job and wait for it to finish (this was accomplished with a Python script since kicking off a job involved telling another application to run the job) followed by a `touch $@` so that make would know which jobs it had successfully run. If a process had dependencies these were declared as you'd expect.
The other targets in the Makefile lashed those together into groups of processes, all the way up to individual days and times. So "monday-9pm" might run "daily-batch", "daily-batch" would have "daily-batch-part-1" (etc), and each "daily-batch-part-..." would list individual jobs.
It was awful. It still is awful because it works so well that there's been no need to replace it. I keep having dreams of replacing it, but like they say there's nothing more permanent than a temporary solution.
All of this was inspired by someone who replaced the rc scripts in their init system with a Makefile in order to allow processes to start in parallel while keeping the dependencies in the right order.
I’ve got a few GOG games and they’ve done an incredible packaging job with DOSBox - if there was a way to take an old PPC Mac app and package it up to run in a similar manner, I’d have probably taken a serious look at it back when Rosetta was discontinued.
I used to use an old version of Quicken for Mac (this was back in the MacOS 10.2 days). It was "finished" in that it did absolutely everything I needed and there were no bugs that affected me. As time marched on, Apple switched from PowerPC to Intel which was fine because they had technology (Rosetta) which allowed me to run PowerPC applications. Then they dropped Rosetta, so now I had to choose whether to upgrade MacOS or continue to use Quicken.
I now use software called Banktivity to replace Quicken. Much like Quicken, Banktivity is "finished" as far as my requirements go. The version I have is Intel-only and Apple is switching to Arm processors. How long will Rosetta 2 last before it's pulled and I'm forced to choose between upgrading my OS and using this software?
I think there are similar things in the mobile world too. I think Google requires apps to use a minimum API version to maintain a listing in Google Play. I believe Apple does something similar with the App Store too. So short of regularly recompiling, testing, and publishing your app, everything in the stores has a finite lifetime.
At the time I started, Home Assistant's automation capabilities (scripts, automations) were very clunky to deal with, so anything but the simplest things were done in Node-RED. Home Assistant has gotten a lot better in this respect, so I'm doing less in Node-RED these days.
One really neat thing about Node-RED (with the appropriate addons) is that you can create entities in Home Assistant that are populated by Node-RED flows. I use this to fetch the garbage collection schedule and expose the next pickup times for each collection (garbage, organics, recycling) as entities. I've also got a garbage pickup notification that tells me which things will be picked up the next day so I don't have to think about the collection schedule at all.
Some additional recommendations that fit the general theme:
* Cameras: I use Blue Iris, so anything that does ONVIF is suitable. There's no need to limit yourself to one brand, though sticking with stuff you know is good is sensible - I've got a couple of ReoLink cameras that are good, and I've got some Amcrest cameras that are also good. Keep your cameras, regardless of brand, on a separate VLAN/Wifi network.
* Switches and Lights: Ikea's TRÅDFRI outlets, and bulbs are pretty decent and very affordable. I also recently got a bunch of Sengled Zigbee outlets and am very impressed with them - great form factor (small enough to not block the other outlet), and the power consumption monitoring helps me understand my electricity usage better.
* Sensors: Ikea's motion sensor is decent and I've never experienced the extreme battery drain that other people have reported - I only have one of these though, so maybe I got lucky. Also, Aqara water detectors have likely saved me thousands of dollars thanks to alerting me to issues in places I don't normally look.
* Other stuff: Ikea's STÅRKVIND air cleaner is pretty nifty, and Zigbee-enabled. I've got a handful of Ikea Zigbee buttons (the shortcut button and the five-button 'puck' remote) that work very well.
Also, check out ESPHome[0] - if you can't find a sensor or device that does exactly what you need, this makes it shockingly easy to build one. I've got a water level sensor (ESPHome, ESP32, HC-SR04) on my sump pit that has alerted me to pump failures before damage occurred.
I'm using a ConBee II with deCONZ for my Zigbee gear, but that's more of an implementation detail than anything.
Finally, my one exception to no cloud stuff - the Rainforest EAGLE-200[1]. Being able to monitor and track my home's energy consumption has been very valuable for saving money. You have to use the cloud to set it up, but Home Assistant can do local polling to retrieve the data. You can also, via the cloud, configure it to POST data in real time to a URL, that POST happens directly from the device.
[1] https://www.rainforestautomation.com/rfa-z114-eagle-200-util...
What you're asking for is 100% reasonable and easily achievable.
The STARKVIND is a LOT bigger than the FORNUFTIG. Assuming you're getting the standalone model, it's probably the depth of two or three FORNUFTIGs. This really surprised me. The table version is very interesting because it eliminates that problem by being a functional piece of furniture.
The STARKVIND filters are different than the FORNUFTIG, so no filter sharing. Conceptually they're the same - a paper particle filter plus an optional carbon filter. At its highest setting it's louder than the FORNUFTIG's highest setting, but at its lowest it's virtually inaudible. If you leave it in Auto mode you'll hear it ramp up when it detects particulates in the air and ramp down when the air quality returns to normal.
The main reason I bought the STARKVIND was the Zigbee interface. The IKEA Home Smart app is functional, but after the initial setup I only use Home Assistant to control it. In Home Assistant there are sensors for particulates and filter life, and controls for fan speed and mode (auto/manual). I'm using the IKEA gateway for my STARKVIND since deCONZ support wasn't completely ready at the time. Overall, it lives up to expectations as far as control goes.