gregsadetsky

as the sibling comment notes, the Canadian version also has it:

https://www.jeancoutu.com/en/shop/categories/personal-care/o...

https://www.walmart.ca/en/ip/Sensodyne-Repair-Protect-Sensit...

`brew install dillo` on Macs (and see [0] for other platforms)

and then `dillo` starts up a 1.1Mb executable that is so freaking, shockingly fast.

TIL I also learned that although the Google homepage renders beautifully, I need to "Turn on JavaScript to keep searching" [1]

Wow, Google Maps is even snarky-ish about it: "When you have eliminated the JavaScript, whatever remains must be an empty page." (that's what appears! for real)

I mean, what was I expecting. U+1F643.

[0] https://github.com/dillo-browser/dillo/blob/master/doc/insta...

[1] https://www.reddit.com/r/google/comments/1i3njv0/google_begi...

I am, by most accounts and measures, a pretty delightful debugging rubberduck!, I will admit to that freely, of my own accord. not humble, just brag.

I am also available to do this for anyone, email in bio!

I was lucky enough to spend some time at Radar last year. An extraordinarily talented and hard working crew (both on the dev and the market/sales sides). A billion API requests per day is not not nothing... It might even be the opposite. It's quite quite something! Hah

I know that Tim (the CTO) often posts in Who's Hiring threads here - ie https://news.ycombinator.com/item?id=45803442

If you're considering joining a NYC-based startup that works in Rust and TS on hard and fun problems, you should more than consider them. And I am 100% not getting a referral fee to say this haha

P.S. Also may this serve as my public record of appreciation for Binh (the blog author of this piece), a friend and now ex-colleague who I (#humblebrag) originally invited to come to Radar. We originally met at the Recurse Center, another fine NYC-based institution! Binh's a superb and deeply smart fellow who fit right in at Radar. Binh, you rock!!! x

Free digital book by Hans Camenzind [0], the designer behind the famed 555 chip.

https://en.wikipedia.org/wiki/Hans_Camenzind

This is very random, but as a teenager, I participated in monthly C programming contests that were run by the MacTech magazine.

One of the contests was specifically to program an algorithm to play a game called "Dots and Boxes".

My own entry was actually a port of ... the JavaScript code on this very page (that I'm posting here)..!

http://preserve.mactech.com/articles/mactech/Vol.17/17.09/Se...

I also remember playing this game a lot in high school with pen and paper. It's super fun. Cheers

The microscopic screenshot on the homepage of https://disco.cloud is almost everything we have - I really really need to update the docs

Oh, there’s actually this tutorial that shows a tiny preview of it:

https://disco.cloud/docs/deployment-guides/meilisearch

Thanks for the reminder!

See these past submissions - https://hn.algolia.com/?q=bytebeat

And these longer explanations on what bytebeat is:

- http://canonical.org/~kragen/bytebeat/

- https://countercomplex.blogspot.com/2011/10/algorithmic-symp...

- https://stellartux.github.io/websynth/guide.html

Never say never - this smart oven runs Android and has 2Gb of RAM and 16Gb of SSD https://juneoven.com/pages/smart-oven (scroll down to the specs)

Almost VPS-sized! haha

(I really wish we could support phones as the ultimate self-hosting device)

No, all good, this is super useful - if you're thinking about this, then it matters to us!

Our philosophy is built on the "cattle, not pets" [0] and 12-factor [1] app methodologies. To some extent, the Disco server itself should be treated as disposable.

Disco runs your applications, which are just deployments of your code (ie git pulls). There's nothing on the server itself to back up. If a server were to die, you'd spin up a new one, run the install.sh script, and redeploy your apps in about 15 minutes.

For application data, our stance is that we believe you should use a dedicated, managed database provider for prod workloads. While we can run a "good enough" postgres as noted, we treat that as a dev/staging tool. Disco handles the stateless application layer, you should entrust your critical stateful data to a service that specializes in that.

Finally, re: security, we recommend a fresh Ubuntu 24.04 LTS server, which handles its own OS security updates. Disco only exposes the necessary web and SSH ports, so the attack surface is minimal by default.

[0] https://cloudscaling.com/blog/cloud-computing/the-history-of...

[1] https://12factor.net/

It's a good point. I'd say that generally, there are answers to most of these points that either get you 80% of the way there, or are functionally equivalent.

Re Load balancing for example, Disco is built on top of Docker Swarm, so you can add nodes (ie machines) to scale horizontally - `disco nodes:add root@<ip>`

For monitoring/alerting, we offer some real time cpu/memory metrics (ie `docker stats`) and integrate with external syslog services.

Do you have specific use cases in mind which current PaaS providers satisfy? Would you say that these kinds of concerns are what's holding you back from leaving Heroku or others (and are you considering leaving because of price, support, etc.)? Cheers

Correct! Re: latency, as I just noted elsewhere, if you run your prod database using Crunchy Bridge or Supabase or another big provider (which you absolutely should for prod), that typically means that your db will be running within an AWS region. You would, in most cases, need to run your compute in the same region. So yeah, at that point, Hetzner would be out.

Backups are only advanced in the context of our Postgres being "Good" enough (maybe our built-in Posgres could be called "Barely enough" but that sounds a bit lame) :-)

I fully agree with you though, it's table stakes (unintended pun!) for any prod deployment, just as read-only followers, etc. Our biggest, most important point, is that folks should be using real dbs hosted by people who know what they're doing. The risk/reward ratio is out of whack in terms of doing it yourself.

And finally, re Hetzner and cross-DC latency, that's unfortunately a very good issue that we had to plan for in another case - specifically, a customer using Supabase (which is AWS-based). The solution was to simply use an EC2 machine in the same region. Thankfully, some db providers end up being explicit about which AWS region they run in - and obviously, using AWS RDS is also an option! It's definitely a consideration.

Super interesting, and truly unfortunate when that happens! Just thinking about having to wait for SSL certificates like in the old days (versus Let's Encrypt) would frustrate me to no end.

Forge seems like a great integrated solution (I subscribe to their newsletter and their product updates seem quite frequent and useful). What's been your experience with them? Any particular things you like, or dislike about them?

I'm also curious when you talk about scaling up Forge - is that something you've done, and is that generally easy to do?

Thanks a lot!

We do have a UI, we're just so behind on the documentation, it's not even funny ha.

If you setup a server with the curl|sh install script on the homepage, you'll get a url at the end that directs you there. And you can use the CLI too of course.

But yeah, thanks for the reminder!

Small correction - the blog article talks about a CCX33 (go to "Dedicated General Purpose" [0]) with 32 Gb of RAM, not a "Shared" CX33.

[0 ]https://www.hetzner.com/cloud

I think that https://lowendbox.com/ might be a good place to start looking for that

Although LLM generated, https://deepwiki.com/letsdiscodev/disco-daemon is pretty impressive and has some arch diagrams. But I fully agree, we should have that on the site.

Once everything is installed/running, a very tldr diagram would be:

GitHub (webhook on git push) -> Docker swarm running Caddy -> Disco Daemon REST API which will ask Docker to build the image, and then does a blue-green zero-time deployment swap

But yeah, a clearer/better diagram would be great. Thanks for the push!

You have your range of options - it depends on the size of your team, the kind of apps you're running, etc. The answer can be anything from an "ssh script" to AWS (or K8S), etc.

If you're running something that's too expensive for your taste and can share more information, happy to brainstorm some options.

Fully agreed - our recommendation is to /not/ run your prod Postgres db yourself, but use one of the many great dedicated options out there - Crunchy Data, Neon, Supabase, or AWS RDS..!

I answered elsewhere with the list of dynos, but the short version is that between the list of services that each deployment required, and the size of the database, it truly (and unfortunately) did end up costing $500 per staging.

I don't know! I do see a Docker image for Elixir, so I'm pretty sure that would work. But the distributed aspect is harder to answer right now.

How do you typically deploy this?

Our library is open source, the price is 0!! :-) Haha

We're actually mostly talking to people (that "schedule a meeting") to see how we can help them migrate their stuff away (from Heroku, Vercel, etc.)

But we're not sure of the pricing model yet - probably Entreprise features like Gitlab does, while remaining open source. It's a tough(er) balance than running a hosted service where you can "just" (over)charge people.

Correct, GitHub is necessary at this point to deploy code.

However, yes, you can ask Disco to fetch an existing Docker image (we use that to self-host RabbitMQ). An example of deploying Meilisearch's image is here [0] with the tutorial here [1].

Do you typically build your Docker images and push them to a registry? Curious to learn more about your deployment process.

[0] https://github.com/letsdiscodev/sample-meilisearch/blob/main...

[1] https://disco.cloud/docs/deployment-guides/meilisearch

From having talked to many folks, migrations are psychologically very, very, very very hard.

At least, the "fear" factor (will the new system work? what bugs will it introduce? how much time will I spend, etc.) pushes a lot of folks to accept a very big price differential aka known knowns versus unknowns...

It's understandable really. It's just that once you've migrated, you almost definitely never want to go back :-)

Cheers, let me know if you do / hop onto our Discord for any questions.

We know of two similar cases: a bootcamp/dev school in Puerto Rico that lets its students deploy all of their final projects to a single VPS, and a Raspberry Pi that we've set up at the Recurse Center [0] which is used to host (double checking now) ~75 web projects. On a single Pi!

[0] https://www.recurse.com/

The longest is to adapt your app to a Dockerfile-based deployment, if it isn't already containerized. We have examples for most languages - for Flask, for example, the whole file is 10 lines long [0]

But to provision a new server, as these are "stateless" (per 12 Factor) servers, it's just 1) get a VPS 2) install Docker+Disco using our curl|sh install script 3) authorize github 4) deploy a "project" (what we call an app), setting the env vars.

All in all ~10 minutes for a new machine.

[0] https://github.com/gregsadetsky/example-flask-site/blob/main...

Sharp eye! Thanks. Fixed

You're absolutely right! Here are some three points why:

- ...

I'm kidding :-)

Our library is open source, and we're very happy and proud that Idealist is using us to save a bit of cash. Is it marketing if you're proud of your work? :-) Cheers

6 staging servers: main, dev, and any branches that you want to let other (non tech people) QA.

As for the staging servers, for each deployment, it was a mix of Performance-M dynos, multiple Standard dynos, RabbitMQ, a database large enough, etc. - it adds up quickly.

Finally, Idealist serves ~100k users per day - behind the product is a lot of boring tech that makes it reliable & fast. :-)