binwiederhier

Go to ntfy.sh/settings and enable background notifications. Or do it like I do it an pin the tab and just leave it open.

Unless you have a pro account, notifications are only cached on the server for 12h so that's why you may miss old notifications.

If you use ntfy.sh and don't use instant delivery, ntfy uses Google's FCM for delivery, which is what everyone else does. It doesn't require a foreground service and has no battery impact.

ntfy offers you additional options with instant delivery or the selfhostable server. That requires a server connection and does impact battery a little. On my phone it doesn't show up in the list it's so low, but others have reported more consumption

I'm the maintainer of ntfy. Happy to answer questions. Sorry that I'm late to the party :-)

4 years later and I'm still working on ntfy. Trying to make push notifications easy as pie. I would have never thought that it would blow up like this. It's still a lot of fun, and I've learned a lot. Thanks everyone for your support and for your amazing ideas and contributions. Open source is awesome. HN ist awesome. https://github.com/binwiederhier/ntfy

Thanks.

I love that you love it. That's why I do it. :-)

My co-worker figured out a way to run the GitHub CLI with read-only keys restricted to specific repos. I need to do that still.

I don't want to isolate the container from the Internet :-) I understand that this is not the safest possible way (exfiltrating is still possible, but I mostly work on open source anyway, so that's not an issue), but I think the convenience wins here.

That said, if you have suggestions that are not super inconvenient, please let me know.

My main goal with this was to make sure it cannot go wild on my own system.

I love how everyone is trying to solve the same problems, and how different the solutions are.

I made this little Dockerfile and script that lets me run Claude in a Docker container. It only has access to the workspace that I'm in, as well as the GitHub and JIRA CLI tool. It can do whatever it wants in the workspace (it's in git and backed up), so I can run it with --dangerously-skip-permissions. It works well for me. I bet there are better ways, and I bet it's not as safe as it could be. I'd love to learn about other ways that people do this.

https://github.com/binwiederhier/sandclaude

Oh my bad. I misread your comment. You are doing ZFS on top of dmcrypt, not dmcrypt images/volumes on top of ZFS.

ZFS encryption is much more space efficient than dmcrypt+unencrypted ZFS when combined with zstd compression. This is because it can do compress-then-encrypt instead of encrypt-then-(not-really-)compress. It is also much much faster.

Source: I work for a backup company that uses ZFS a lot.

I love hearing that. Anything worth sharing? I love hearing how people use it. My favorite one is the guy protecting his apple tree from thieves by adding a camera and motion sensor and then sending himself a notification with the picture to catch the apple thief.

Disclaimer: I am the ntfy maintainer. Pleasantly surprised to be mentioned, hehe.

Pushover is an amazing tool and works well. In my obviously biased opinion though, I think that ntfy has a ton more features than Pushover and is fully open source. You can self host all aspects of it or you can use the hosted version on ntfy.sh for free, without signups, or pay for higher limits.

I suggest you try out ntfy;-)

Thank you to all the Debian volunteers that make Debian and all its derivatives possible. It's remarkable how many people and businesses have been enabled by your work. Thank you!

On a personal note, Trixie is very exciting for me because my side project, ntfy [1], was packaged [2] and is now included in Trixie. I only learned about the fact that it was included very late in cycle when the package maintainer asked for license clarifications. As a result the Debian-ized version of ntfy doesn't contain a web app (which is a reaaal bummer), and has a few things "patched out" (which is fine). I approached the maintainer and just recently added build tags [3] to make it easier to remove Stripe, Firebase and WebPush, so that the next Debian-ized version will not have to contain (so many) awkward patches.

As an "upstream maintainer", I must say it isn't obvious at all why the web app wasn't included. It was clearly removed on purpose [4], but I don't really know what to do to get it into the next Debian release. Doing an "apt install ntfy" is going to be quite disappointing for most if the web app doesn't work. Any help or guidance is very welcome!

[1] https://github.com/binwiederhier/ntfy

[2] https://tracker.debian.org/pkg/ntfy

[3] https://github.com/binwiederhier/ntfy/pull/1420

[4] https://salsa.debian.org/ahmadkhalifa/ntfy/-/blob/debian/lat...

ZFS really shines here with its built-in "zpool scrub" command and checksumming.

Even though I am preaching "application consistent backups" in my original comment (because that's what's important for businesses), my home backup setup is quite simple and isn't even crash consistent :-) I do: Pull via rsync to backup box & ZFS snapshot, then rsync to Hetzner storage box (ZFS snapshotted there, weekly)

My ZFS pool consists of multiple mirrored vdevs, and I scrub the entire pool once a month. I've uncovered drive failures, and storage controller failures this way. At work, we also use ZFS and we've uncovered even failures of entire product lines of hard drives.

Ha! I did not expect a reference to `innodb_flush_log_at_trx_commit` here. I wrote a blog post a few years ago about MySQL lossless semi-sync replication [1] and I've had quite enough of innodb_flush_log_at_trx_commit for a lifetime :-)

Depending on the database you're using, and on your configuration, they may NOT recover, or require manual intervention to recover. There is a reason that MSSQL has a VSS writer in Windows, and that PostgreSQL and MySQL have their own "dump programs" that do clean backups. Pulling the plug (= file system snapshotting) without involving the database/app is risky business.

Databases these days are really resilient, so I'm not saying that $yourfavoriteapp will never recover. But unless you involve the application or a VSS writer (which does that for you), you cannot be sure that it'll come back up.

[1] https://blog.heckel.io/2021/10/19/lossless-mysql-semi-sync-r...

Databases these days are pretty resilient to restoring from crash consistent backups like that, so yes, you'll likely be fine. It's a good enough approach for many cases. But you can't be sure that it really recovers.

However, ZFS snapshots alone are not a good enough backup if you don't off-site them somewhere else. A server/backplane/storage controller could die or corrupt your entire zpool, or the place could burn down. Lots of ways to fail. You gotta at least zfs send the snapshots somewhere.

This strongly depends on your environment and on your RTO/RPO.

Sure, there are environments that have automatically deployed, largely stateless servers. Why back them up if you can recreate them in an hour or two ;-)

Even then, though, if we're talking about important production systems with an RTO of only a few minutes, then having a BCDR solution with instant virtualization is worth your weight in gold. I may be biased though, given that I professionally write BCDR software, hehe.

However, many environments are not like that: There are lots of stateful servers out there with bespoke configurations, lots of "the customer needed this to be that way and it doesn't fit our automation". Having all servers backed up the same way gives you peace of mind if you manage servers for a living. Being able to just spin up a virtual machine of a server and run things from a backup while you restore or repair the original system is truly magical.

Thank you for sharing. A curious read. I am looking forward to the next post.

I've been working on backup and disaster recovery software for 10 years. There's a common phrase in our realm that I feel obligated to share, given the nature of this article.

> "Friends don't let friends build their own Backup and Disaster Recovery (BCDR) solution"

Building BCDR is notoriously difficult and has many gotchas. The author hinted at some of them, but maybe let me try to drive some of them home.

- Backup is not disaster recovery: In case of a disaster, you want to be up and running near-instantly. If you cannot get back up and running in a few minutes/hours, your customers will lose your trust and your business will hurt. Being able to restore a system (file server, database, domain controller) with minimal data loss (<1 hr) is vital for the survival of many businesses. See Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

- Point-in-time backups (crash consistent vs application consistent): A proper backup system should support point-in-time backups. An "rsync copy" of a file system is not a point-in-time backup (unless the system is offline), because the system changes constantly. A point-in-time backup is a backup in which each block/file/.. maps to the same exact timestamp. We typically differentiate between "crash consistent backups" which are similar to pulling the plug on a running computer, and "application consistent backups", which involves asking all important applications to persist their state to disk and freeze operations while the backup is happening. Application consistent backups (which is provided by Microsoft's VSS, as mentioned by the author) significantly reduce the chances of corruption. You should never trust an "rsync copy" or even crash consistent backups.

- Murphy's law is really true for storage media: My parents put their backups on external hard drives, and all of r/DataHoarder seems to buy only 12T HDDs and put them in a RAID0. In my experience, hard drives of all kinds fail all the time (though NVMe SSD > other SSD > HDD), so having backups in multiple places (3-2-1 backup!) is important.

(I have more stuff I wanted to write down, but it's late and the kids will be up early.)

I read the beginning of the post and it looks quite interesting. I'll read the rest tomorrow when my mind is sharper.

I checked my blog and I also wrote a post about some crypto related things shortly after I purchased the book. It's a post about a bug in the JDK that I stumbled across, which I am certain I would not have understood without Bruce's book:

https://blog.heckel.io/2014/03/01/cipherinputstream-for-aead...

Btw, I was a bit of a fan boy back then and I got the signed copy of the book, haha.

I really enjoyed the book and it certainly helped me, but it's also the only cryptography book I've ever read. I appreciate you challenging my suggestion!

I just checked and it has been a whooping 12 years since I purchased/read the book, so I retract my recommendation.

I can highly recommend Cryptography Engineering by Bruce Schneier. I read it years ago and to this day it still helps me regularly.

I've used this successfully in the past for Terminator: https://github.com/GratefulTony/TerminatorHostWatch

I was thinking exactly this. I am the maintainer of ntfy.sh and my costs are $0 at the moment because DogotalOcean is paying for it 100% because it is open source. It would be around $100, though I must admit it's quite oversized. However, my volume is much much higher than what is described in the blog.

I suspect that the architecture can be improved to get the cost down.

Fascinating.

There are some other interesting repos from the same author, namely https://github.com/pijng/goinject, which lets you inject code as part of preprocessing. Feels a lot like Java’s annotation magic.

Thanks for sharing. I wasn’t even aware Go had pre-processors, or that modifying the AST like that is even possible.

I wholeheartedly disagree. I think the Stripe docs and developer experience is one of the greatest, if not the greatest, I've ever seen.

It has great user docs, API docs, developer centric UI elements like copy pastable IDs, webhook event browser, time travel features, test mode (!!), and you can even look at the exact API calls that the stripe UI itself is making. I've brought it up to many colleagues are awesome the docs and experience is...

IMHO, for most things, the data model is straight forward and well explained. Of course there are complicated topics and quirks, but that's just because payments is not easy in general..

I'm clearly a Stripe fanboy, but I am not affiliated in any way.

Relatedly, here's a 3D printed, mechanical version of it: https://youtu.be/nHqqCRVlUus?si=p_q78n_nKYZhykNt -- By Engineezy, great YouTube channel.

Well, this was a surprise to me too, but apparently Linux does this:

   $ ping 0.0.0.0
   PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
   64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.028 ms
   64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.056 ms
   64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.105 ms
   ...

   $ nc 0.0.0.0 22  
   SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.10
   ...

That reminds me of a just for fun plugin I wrote for my (long dead) Dropbox-like file sync solution Syncany that would store the shared files as PNG images on Flickr.

At the time, Flickr and Google Picasa (now Photos) gave you like 1T of image storage for free, so I thought it'd be a dope backend. It worked really really well actually... And it was nice to see your data as images. Though since the files were packed and encrypted, it just looked like static.

Here's the plugin if anyone's interested: https://github.com/syncany/syncany-plugin-flickr/tree/develo...

Wow. That's 10 years old. Time flies.

Edit: This PNG encoder is the meat: https://github.com/syncany/syncany-plugin-flickr/blob/develo...

Pēteris' model with healthchecks.io was a large inspiration for me, and it is the reason why ntfy.sh is following the same model: open source, self-hostable, fun driven development.

Thank you Pēteris for being an inspiration.