HNHacker News
TopNewBestAskShowJobs

_pob

44 karma · joined July 2, 2018

submissionscomments
_pob··on Ask HN: My family business runs on a 1993-era text-based-UI (TUI). Anybody else?
My grandfather purchased a niche customer management DOS application in 1986 or so and used that Software up until the day he died in 2012.

When he was finally forced to upgrade to a computer without a parallel port, he was a bit stuck for a bit because the software would only print to a printer connected via parallel port. I couldn’t find a card for this at the time, for whatever reason, but I eventually was able to trick the software into printing to a modern printer and I had never seen him more happy since it saved him the $3000 software upgrade fee.

Miss you, Grandpa!

_pob··on Touching the back wall of the Apple store
As someone that works with large AWS, GCP, AliCloud, and Azure footprints I can assure you that Azure is god awful in every single aspect.

Especially, but not limited to, support.

_pob··on Vector: A high-performance observability data pipeline
No offense meant to the contributors or authors, but I don’t know if I trust Datadog (the company) to steward what looks to be an OTEL competitor.
_pob··on Why Fix Kubernetes and Systemd?
I call it RDD - Resume Driven Development.
_pob··on Ruffle: WebAssembly Flash Player Emulator
Ruffle is fantastic.

For the first time in ~8 years I was able to watch old flash content I had lying around and all I needed to do was link to the ruffle JS library. Worked flawlessly.

Thanks for letting those videos live again, Ruffle team!

_pob··on Show HN: Burn After Clicking – One Time Use URL for Secrets
I made this because I got sick of seeing passwords copied around in emails and on slack. Normally I would say "we should use GPG," but that's not always super user friendly for non-technical folks.

It encrypt's the body of the "secret" using a default passphrase, and you can optionally set your own to encrypt and "lock" the secret.

I opted to not add in any support for creating users at this point since my intention was to have a company run this internally on a private WAN, although I am sure my position on that will change.

_pob··on Twilio to Acquire Sendgrid
At a previous company I worked at we used to manage our own email infrastructure before finally switching over to a dedicated service. There are a few problems if you are sending over bulk email that is customized per user when running your own SMTP service.

1. IP address reputation - Keeping your IP addresses reputable is not a simple task. It requires balancing your emails for popular destination domains (gmail.com, aol.com, yahoo.com, etc.) across multiple external IP address. It requires you to deal with many different conflict resolution departments, who don't care about email, when a dispute comes up. It's practically a requirement to use a service like ReturnPath to maintain your reputation.

2. Throttling - When doing it yourself you need to throttle yourself. This is problematic on "big" days, especially when your marketing department wants to send many millions of emails for a big product push, promotion, or on days like black friday/cyber monday.

3. Hiring - A lot of people think sending email is easy. When you get up to the multiple million per day mark things start to fall apart. Do you have someone(s) on staff who really know sendmail/postfix/qmail inside and out?

4. Monitoring - sendmail/postfix/qmail are often times hard to monitor. You have to put together all of your stats. You have to put together all of your alerts. If you aren't really experienced with bulk email, you won't know what to look for and that can impact your reputation. Also consider your logging infrastructure. sendmail/postfix/qmail are noisy.

5. Cost - All of the points above play into the cost aspect of it. Is it cheaper to run it yourself, pay for all of the services and salaries, etc. Or is it actually cheaper to just use sendgrid/mailgun/etc. IP address reputation services are not cheap. Infrastructure cost is also something to consider. AWS IPs all have pretty terrible reputations so running this in AWS (and maybe other cloud providers) is a non-starter since no one will accept your email.

If you've got the expertise and you are sending a massive amount of emails then it might be worth it to run your own infrastructure, but at the end of the day, a single developer consuming an API is often easier and less problematic.