fuser

He said "I know you run the show down here, but give the devil his due...

I'll bet a toilet of gold against your soul that I can intimidate you"

endlessh

yep... https://nullprogram.com/blog/2019/03/22/

reminds me of this

https://www.vice.com/en/article/d3b7na/the-story-of-lenny-the-internets-favorite-telemarketing-troll

With respect to pricing, I've been using SES for maybe 10 years, possibly more - this month is the first time I think I've ever been charged. The free tier used to include a very large number - I think it was 30,000 or or more emails a day that I never exceeded. Now it's 0.10 USD per thousand messages. Which is a pretty big change from free, even though the overall costs are small - and it's still a bargain. As with everything in "the cloud" though, the big players will squeeze the competition out then increase prices. I fully expect SES prices to keep increasing now they've figured out they can extract a few extra dollars from users and how relatively cheap SES is compared to the other overpriced crap. It won't surprise me if they jack this up significantly in the coming years.

Referencing sending quotas - Amazon is very lenient - I was talking about the big providers like gmail. It might be different now that my accounts have a long reputation as trustworthy senders, but when I first started using SES way back when, gmail and yahoo would start rejecting mail if more than something like 200 or so messages were submitted in a single batch, so I had to check the recipient domains and limit the numbers for each hourly iteration to stop them rejecting. I keep the email batches pretty small since I'm only sending out about 5-10K at a time and I stagger the send over several hours.

It's a bit of a minefield but overall pretty happy with SES, mainly because the mail gets delivered. You don't need to originate sending from an EC2 hosts (the pricing is the same, even though they make a distinction in the price list:

Outbound email from EC2 $0.10/1000 emails $0.12 for each GB of attachments you send*

Outbound email from non-EC2 $0.10/1000 emails $0.12 for each GB of attachments you send

*You might incur additional data transfer charges for using EC2 (it seems very likely they will increase the non EC2 price to drive you to a place where they are getting your compute and storage $ as well).

https://aws.amazon.com/ses/pricing/

maybe not the healthiest, but these are some of my favorites https://quex.cc/c/recipes

SES is indeed the best option if you want reliable delivery for a reasonable cost. The pricing changed just last month so it's no longer effectively free for small users but it's relatively cheap (for now). I looked at the prices you quoted for other services and they seem ridiculously high, but it's fair to say that sending legitimate (non spam) bulk email is not so easy if you do everything yourself - getting your mail accepted is very challenging. For example, even using SES, if you attempt to originate too many emails to one provider in a single call, they may start rejecting everything - I had to put counters into the code to limit how many gmail addresses would be sent with each iteration. SES also rate limits so you need to manage that somehow. It sounds like you're planning to send a LOT of email. You'll also need to be mindful of the bounce rate and complaints (spam / abuse reports from recipients) because SES will shut you down if they go over a certain threshold, which you can see in the dashboard. It sounds like you've already figured a lot of this stuff out though - it's not rocket science but it can be frustrating to work with bulk email delivery for a number of reasons.

I don't blame you re the third party - I wouldn't either. I generally download a transaction file periodically and import it locally using the app. I think you're going to find it difficult to find an API that will allow little people access, even though they are obviously happy to offer that to the big companies. Some of the brokerages have checking accounts and it might be possible to pull the transaction data via the brokers API (maybe), but whichever way you look at it, I suspect the most pragmatic solution is probably going to be a download/import of some kind.

what are you looking to do? I don't know of any consumer bank APIs but most equity and exchange brokerages will let you check account balances and make trades with an API key and credentials. Probably not initiate payments or transfers though. There are too many security risks involved for allowing that via a consumer-level API. There are also tools like Mint that store your credentials and can presumably access your data because they have corporate level agreements with the Financial institutions - I haven't used that and would not normally recommend a corporate-based solution like that personally, but it might work for your needs.

Yes you understand the suggested approach. I don't know about the mariadb tool and if it looks good, by all means use it, but I would offer that the fastest, simplest way to restore a reasonably small database that I can think of is with a sql dump. Any additional complexity just seems like it's adding potential failure points. You don't want to be messing around with borg or any other tools to replay transactions when all you want to do is get your database rebuilt. Also, if you have an encrypted local copy of the dump, then restoring from borg is the last resort, because most of the time you'll just need the latest backup. I would bring the data local and back it up there if feasible. Then you only need a remote connection to grab the encrypted file and you'll always have a recent local copy if your server goes kaput. Borg will back it up incrementally.

for the database, consider a script that does a "mysqldump" of the entire database that you schedule to run on the system daily/weekly. Also consider using gpg to encrypt the plain text file and delete the original in the same script. This is so you don't leave a copy of the data unencrypted anywhere outside the database. You can then initiate either a copy of the encrypted file to a local folder that you're backing up, or if you've set this up to back up directly on the remote that's fine too - bringing it local gives you a staged copy outside the archive and not on the original host in case you need an immediately available backup of your database.

With respect to the 3 separate repos, I would say keep them separate unless you have a large amount of duplicated data. Borg does not deduplicate over different repos as far as I'm aware. The downside of using a single repo is that the repo is locked during backups and if you're running different scripts from each host, the lock files borg creates can become stale if the script doesn't complete and one day (probably the day you're trying to restore) you'll find that borg hasn't been backing your stuff up because a lock file is holding the backup archive open due to a failed backup that terminated due to an untimely reboot months ago. I don't recall now why this occurs and doesn't self-correct but do remember concluding that if deduplication isn't a major factor, it's easier and safer to keep the borg repos separate by host. Deduplication is the only reason to combine them as far as I can tell.

When it comes to backup scripts, try to keep everything foolproof and use checks where you can to make sure the script is seeing the expected data, completes successfully and so on. Setting up automatic backups isn't a trivial task, although maybe tools like rclone and borgmatic simplify it - I haven't used those, just borg command line and scp/gpg in shell scripts. Have fun!

Interesting - here's a news story about it (Guardian) ‘It was an accident’: the scientists who have turned humid air into renewable power

I suppose it depends what you're looking to do - the Juno DS88 that I have is nothing like these fancy desktop synths in terms of sound capabilities but it has good instrument sounds - mainly the keys and action feel good to me - but my only reference point is old pianos. I'm not a keyboard player so can't say much about pros/cons but in terms of value for money, but overall I am pretty happy with the Juno for a full size piano keyboard at the price. I just started playing with the software synth SurgeXT and having a lot of fun playing MIDI from the Juno.

you have the main problem in hand. You'll still need to do all the DKIM / rDNS stuff to be certain your mail is accepted, but using SES as the source gives you a significant leg up vs originating locally. I don't see why you can't run dovecot and postfix on separate systems, but a single VM isn't bad if it's properly secured. Hosting SMTP/IMAP is not that difficult but you need to make sure you don't accidentally misconfigure things and become an open relay - as with all internet facing systems, mail services are targeted constantly so you should use fail2ban to deter them.