zupo

"The capability based approach is interesting, but trusting developers to declare all their needed capabilities seems brittle. Modern OS level sandboxing or containerisation provides strong isolation without relying on each library to opt in, which may be a more robust alternative."

This is a good reminder that ‘AI pair programmers’ can create subtle bugs that are hard to spot.

Fascinating vulnerability. It shows how browser integrations can create unexpected attack surfaces. I’d love to see more discussion around hardening these kinds of local browser modules.

IIUC Magic Nix Cache uses Github Actions Cache, which means there is waiting for the cache contents to be loaded onto the runner instance. This can in no way be as fast as what namespace.so does, which is mounting a disk image with /nix/store.

What worked great for me for speeding up CI was using Cachix + namespace.so. This works so well I moved all my personal and our company CI to GitHub Actions.

With "it works so well", I mean:

* CI is cheap because namespace.so runners are faster & cheaper than GitHub Actions

* the UX is exactly the same as using vanilla GitHub Actions, namespace.so's runner is a drop-in replacement

* the CI starts up very fast because `/nix/store` is stored on namespace.so's "Cached Volumes" which are like virtual disks attached to the CI runner, so there is nothing to download to prime the cache, Nix can just start running immediately

* https://github.com/cachix/cachix-action uploads whatever Nix builds to Cachix in the background so from this point on if any of our devs pulls the latest code, they don't have to build any derivations locally, and lose time waiting, everything is pulled automatically from Cachix to their machines, they can get right to work. Or if I have to purge the Cache Volume for some reason, nothing needs to be rebuilt, just pulled from Cachix.

It's taken a few years to get this dialed in, but now that it works, it's sooo good!

I've seen the following multiple times in the past: 1. something changed in test layer setup that made all tests slower 2. something changed in application code that made all tests slower (!!)

And most of the times, they were avoidable, and fixed after we realized what happened.

Not quite 2019 levels, but here they have mostly rebounded.

Unit tests tend to get slower with time, wasting a lot of developer hours. BlueRacer helps you keep them fast by posting a unit test performance summary on every Pull Request.

That's great feedback, thanks!

Which is exactly what the device on the link does. It's using a real SIM card to receive 2FA codes and then forwards it to wherever you configure it to.

Slack is mostly used as a placeholder in the name. It's trivial to change the code to send the webhook anywhere: https://github.com/teamniteo/sms2slack/blob/master/src/esp32...

Yep, completely agree. We had a project before when it "clicked" and we could tell.

Additionally, there is a huge difference in getting free users and getting paid users.

We tried with a very low-price plan and got a lot of interest & signups. The moment we raised the prices a bit to cover hosting costs, the interest went away.

The trick is in knowing where to draw the line. We definitely felt we had "some" tracking. We had hundreds of people sign up to our newsletter. We had a couple of users that absolutely raved about the product (or as it turned out later, not about the product specifically, but the support we were providing).

We asked ourselves many times: is this "too slow" or are we just being impatient?

It's "zero trust". I.e. no-one from Pareto Security, nor anyone from your company can access or track any of your Macs.

The only thing that the local agent running on a Mac does, is sending a list of failing checks every now and then. It does not allow any centralized pushing of configuration, no tracking, no remote access, nada.

OP's coworker here, thanks for taking the time for writing this, I'm definitely cheering for us to give Render another try!

As much as I hate to say it as a developer: code is trivial. Finding users is the hard part.

Additionally, our long-term vision is to make the bulk of revenue from Teams subscriptions, where most value comes from a web-based dashboard (https://paretosecurity.com/teams), which is closed sourced.

TL;DR: Quick & easy process, do it. Minor part of revenue on long term, though.

They reached out to us. We integrated their SDK (trivial), provided sales copy and screenshot, then waited about two weeks for the review.

For the first few months, we got the most revenue from SetApp, it quickly jumped to ~$800, but these days, we earn more from selling single-user licenses. I expect the SetApp part to become smaller and smaller as we grow our Teams subscriptions.

Generally, I think it was good. It got us a few hundred users very early on, which helped us focus on the features and fixes that mattered. It also helps with brand trust, i.e. if you are in SetApp, there is less chance of you being a scammer.

I'll report back in a year or three if it does in fact work in real life hehe

Thanks! And it's open source: https://github.com/paretoSecurity/pareto-mac/

After 15 years of SaaS-ing, myself and two collegues, everyone part-time, are trying to see if we can make a profitable macOS app: https://paretosecurity.com/. Revenue in last 30 days is $3000+, we started working on it back in July. So, it's something?

That said, long-term, we expect to earn more from subscriptions for businesses, than we do from single-user lifetime licenses. But again, ATM, it's the single user licenses that sell well.

Agree with SSH connection. If you know what you are doing, they are fine, feel free to go to app preferences and disable the SSH check.

Hey can you please write to support@paretosecurity.app so we can look into this?