knadh

That the package is downloaded 7 million times a week exacerbates the impact significantly. The CI/CD trend of pulling everything from upstream over and over for builds (despite caching, as the absurd NPM download counts indicate) ensures that any upstream issue is distributed widely and frequently.

Continuous Integration and Continuous Deployment of vulnerabilities.

Life isn't complete until one's made their own static site generator! I had to make two directory websites earlier this year and that exercise turned into a static directory site generator - https://github.com/knadh/dirmaker

The platform looks slick. Great job!

- It would be nice to have a sample book or two featured on the homepage.

- About print-on-demand, where is it printed and shipped from? Perhaps an FAQ page can answer some of these questions.

That is very surprising to hear. listmonk is a single exe with no dependencies (except for Postgres connectivity). Running the Docker setup is as simple as `docker-compose up app db`. If you don't want Docker, you can just download the binary and do `./listmonk`.

What is the difference between downloading and running a bash script vs. downloading and running a binary or a Docker image?

Surely, when downloading a piece of software from a (quasi?) trusted source, no developer is going to read all the lines of source code before running it. And if that's the case, how is downloading and running an .sh from the same source any different?

This is correct. Our listmonk instance has ~7mn subscribers to whom we've to send updates (sometimes mandatory regulatory ones within stipulated periods) every month.

The cost of hosting listmonk and Postal SMTP servers (that we scale up momentarily when sending a campaign) on EC2 is peanuts. With proper SPF + DKIM + not sending spam, we haven't had any IP reputation issues.

Unsub has been available from day one. Bounce handling (generic webhooks, POP3, SES+Sendgrid webhooks) is already merged into the repo and will be available in the upcoming release.

listmonk has nothing to do with Zerodha's business though. It's a personal project that I built prompted by usecases at work originally. I like AGPL because it increases the odds of improvements coming back to the upstream project, something into which I invest a lot of personal time.

1. I think AGPL is a good license for web apps that can also dissuade Elastic/Mongo-like fiascos. Mastodon, Metabase, Grafana, Minio etc. are AGPL and are widely used.

2. We see ourselves as a group of hackers and not really as a corporate entity. Many projects that come out of our team are largely individual efforts. For instance, I have spend considerable personal time working on listmonk over the last couple of years just because I like it. There is no Zerodha mandate involved. Only projects that have to be branded as Zerodha or involve a lot of multi-dev effort go under the official handle (ref: https://zerodha.tech/projects)

3. listmonk offers a one-click Heroku button (a bunch of simple scripts really), so it should just be a matter of creating deployment scripts for other platforms as well. I have not looked into it personally.

Thanks. Will see how feasible a demo is. The app's website shows a few screenshots: https://listmonk.app

listmonk author here. Interesting to see it on the frontpage again. Some updates to the linked comment (which is from 2019):

- Tons of active development has happened and listmonk crossed 1.0 this year. 2.0 is on the horizon and there are quite a few listmonk instances in production.

- Our production setup at work now has ~7mn subscribers and listmonk works quite well. No issues with deliverability or IP reputation with our self-hosted EC2/Postal SMTP setup.

- listmonk now supports generic "Messenger" HTTP webhooks to which any message provider can be connected, allowing it to send arbitrary message campaigns like WhatsApp and SMS, not just e-mails.

I donate semi-regularly. Been using Thunderbird as my primary email client (almost) since its release. The installation has hundreds of thousands of mails across many folders, and yet, it is super fast and rock solid.

Curious to see sql-jobber here. I'm the author, if you have any questions.

> though it's probably not the first one would think of

Yep. The model makes sense when you have large databases (for us, it's hundreds of billions of rows in multi-DB Postgres instances) that have to directly serve complex read queries to millions of users pulling reports.

1) When you have users who access arbitrary reports over and over (for us, financial reports that don't change during the day), doing a simple `select *` from the cached report tables per user, where they can be thrown away at any time based on a TTL or other conditions, can be way faster and cheaper than creating and maintaining read replicas of slow-ish multi-TB databases to directly serve large volumes of concurrent queries.

2) Easy traffic control and queuing when you have large volumes of read requests coming through. This can be beneficial to large DBs serving reports to users irrespective of the kind of reports. In addition, when there is big, unexpected surge in user traffic, the reads just get queued and users just have to wait for longer to see the results, but the big databases never get overloaded.

I wrote listmonk[1] after running into difficulties scaling existing open source list managers including Mailtrain to millions of subscribers. It is a single binary app that can run on a potato VM instance.

[1] https://listmonk.app

It’s possible to achieve good deliverability with some effort. Proper SMTP config and a “clean” dedicated IP from a host with no history of spamming. I gave up on the Postfix/Dovecot setup when I switched hosts and figured I’d just rely on a dedicated provider. At the end of the day, with a local client, the email provider is merely a pluggable relay.

I've had a personal e-mail ID on a custom domain for a long time that I've connected to everything from self-hosted setups to several providers including GMail. The web UIs have never been an issue thanks to Thunderbird.

Last year, I switched to ProtonMail (Thunderbird on Linux with their "bridge" client). Works flawlessly, spam classification works well alongside Thunderbird's junk classification, and the mobile app is pretty slick too.

Anecdotal experience being, a local client like Thunderbird (mine still has e-mails from 18+ years ago) + whatever provider via IMAP/POP has been a rock solid setup that has withstood time. It might not be wise to trust any cloud e-mail provider in the long run.

An open source newsletter manager web app - https://listmonk.app

Mastery is difficult to quantify, especially in terms of code or engineering cleverness. I think, what comes close, is the ability to get way more tradeoffs right than wrong, to hit an optimal balance. Tradeoffs in decision making when it comes to picking technologies or languages, or a certain design pattern, or an architecture, or UI/UX or whatever, when building systems. Small tradeoffs that may not look like much immediately, but pay off in the long term. Sacrificing a seemingly good feature now to avoid the pain of technical debt in the future.

Many of these traits are fundamental, universal, and even philosophical, than is general perceived, and transcend technologies and stacks, and to a large extent, time.

And yet, I think, the above traits can be described as good, and not really mastery in its truest sense, like in other disciplines like music or painting. Software engineering is way too diverse, fragmented, chaotic, and ever changing.

Redis is an astonishingly good piece of software. I've always found its beauty to be the reflection of your philosophies, @antirez. Thank you. Here's to you finding joy in your pursuits!

We did indeed. The most critical components have been rewritten and refactored multiple times as we have grown.

We do. We have not yet documented this publicly, but will setup something like a Hackerone profile soon.

Apologies. This definitely would've been a genuine case of human error or oversight. There is no logical reason to not issue API credits that were promised. If you are still interested, please write to me and I will get the credits added.

Cheers. Not all libs need to be updated constantly either. Figuring out what is worth upgrading and rewriting is as important as rewriting itself. Also, it is okay to pause features sometimes to do an important rewrite.

Dart is alright. For being able to use Flutter, it's a fair trade-off.

React Native, it was both. Fundamentally, it uses a JS engine that acts as a bridge, and that can be a performance bottleneck depending on the usecase.

Thanks, but paying extra for reliability implies that reliability is being compromised and can be provided for a fee, which isn't the case here. As unfortunate as these incidents are, they are rooted in the legacy infrastructure a stock broker is dependent upon and we've been working hard over the years replacing those, component by component.

The first version of our web trading platform was written in Angular. It quickly got out of hand in complexity (and we felt Angular had a learning curve that was unwarranted for a frontend lib). The bundle sizes were also big. Then the Angular version fiasco happened. Vue turned out to be far easier to understand and work with, was faster in our benchmarks, and smaller in size.

With Flutter, we initially had a native Android app and a React Native iOS app. Managing two codebases was obviously painful, and React Native had significant performance issues, and we also struggled with the lack of stable libs, and the breaking changes between releases. Flutter came along and we were able to share 90% of the codebase across Android and iOS apps, and were quite happy with 60FPS rendering of native UI.

ERPNext is an amazing piece of FOSS tech that deserves a lot more visibility.

That makes it sound like the only thing involved in stock broking setup is pushing messages through a line :) Market volatility can cause several hours worth of orders to come through in a single burst. What goes on inside a stock broker is actually incredibly complex. I guess that warrants a long blog post.

Hey, you can turn on biometric 2FA on your smartphone, or use TOTP (Kite web -> My profile -> Password and security).

The static PIN is a legacy hole that has to be plugged. Coincidentally, we wrote to the regulator about this exact same matter recently. We'll hopefully see a regulatory announcement mandating "real" 2FA for everyone.

That is correct. Have to have physical racks at approved data centres to terminate exchange leased lines. System audit regulations means that exchange approved auditors walk into the data centres and look at the racks and verify compliance :)