morgante

We built on firecracker VMMs but today I'd just use a hosted provider like morph.so or e2b.dev.

The exploit is there either way.

You should treat running a code analyzer/builder/linter against a codebase as being no safer than running that codebase itself.

A pretty straightforward solution is to have an isolated service that keeps the private key and hands back the temporary per-repo tokens for other libraries to use. Only this isolated service has access to the root key, and it should have fairly strict rate limiting for how often it gives other services temporary keys.

Yikes, this is a pretty bad vulnerability. It's good that they fixed it, but damning that it was ever a problem in the first place.

Rule #1 of building any cloud platform analyzing user code is that you must run analyzers in isolated environments. Even beyond analysis tools frequently allowing direct code injection through plugins, linters/analyzers/compiler are complex software artifacts with large surface areas for bugs. You should ~never assume it's safe to run a tool against arbitrary repos in a shared environment.

I also ran a code analysis platform, where we ran our own analyzer[1] against customer repos. Even though we developed the analyzer ourself, and didn't include any access to environment variables or network requests, I still architected it so executions ran in a sandbox. It's the only safe way to analyze code.

[1] https://github.com/getgrit/gritql

This is way too broad of a statement.

The smartest person and the dumbest person I've met professionally are both investors.

They don’t elaborate on the logging details, but certainly must good systems don’t allow log tampering even for admins.

All of those battles involve battlefield tactics, and in several of them the numerically inferior force won — exactly the opposite of "death stacks."

Unfortunately nuance is dead. I too wish Musk had tried to empower USDS instead of immediately alienating many of the people best positioned to improve things.

That's not true.

Look at USAID: they canceled everything, but there was a significant outcry about PEPFAR specifically. Now PEPFAR is back, and likely to stay.

I'm not here to defend DOGE, but you're making the same mistake as the article of assuming the DOGE approach has no merit.

Deleting processes somewhat randomly, then listening for the pain, is a pretty well-known technique for understanding and cleaning up legacy systems. Of course, it should only be used on systems where (temporary) failures are tolerable.

There are parts of the government where that is true, and parts where it is dangerous. The problem on both sides is assuming the same techniques should be applied across the entire government, when some services are indeed life-and-death and others absolutely should be deleted.

The efficiency comparison is interesting, since it starts relatively evenly but quickly dismisses the value of the DOGE approach. Everyone I know who worked at USDS has been talented and well-meaning, but I can't help but feel they've been hamstrung specifically by

1. Methodical improvements mostly work to improve processes as they are. They don't delete processes that shouldn't exist.

2. Agency "empowerment" often means working with a lot of incumbent teams that are simply not suited to digital work and sinks way too much time/energy into stakeholder management.

USDS has done good work, but could have done a lot more if they were actually empowered.

[1] https://www.wethebuilders.org/posts/a-tale-of-two-effiencies...

> It will never be enough for you.

That's not a good assumption to make for everyone. There are many people who do grow income without growing expenses (see the whole financial independence movement).

I spend about as much now as I did 7 years ago when I made 4x less.

> However YC gets preferential shares; YC is not aligned with the common shareholders (founders; builders).

YC invests on a SAFE, the terms are public.[0]

For most companies, pre-seed SAFEs don't end up much above common.

[0] https://www.ycombinator.com/deal

You're right. I was bucketing the pricing/payout issues into the loan terms but they equally apply if you don't take out the loan.

Obviously there are many better ways to structure this if a sophisticated counterparty actually wanted a good investment opportunity for the community. Sadly that's not in anyone's interest.

Yeah I personally think the valuation is the least egregious part. If they get sued, they’ll have a defense for how they arrived at that number. It’s not 10x off.

The bigger problem is the terrible loan terms.

It’s Chicago. They’re likely getting kickbacks/bribes.

OP would have to speak to his experience, but between a Google IPO and the $10M Virgin acquisition I would be surprised if he didn't average >$200k lifetime.

Throughout this thread, it's clear you have an ax to grind. Startups are obviously not for you, but many enjoy them and benefit.

> Seeing tts outcome of the startups he listed, it would have been much better to work as an enterprise CRUD developer at a bank, insurance company, etc

Enterprise CRUD developers don't make that much. I'm confident OP made more over his career than them.

It's interesting how at least several of the failures were good ideas with bad timing/execution that others have replicated successfully.

iCab: Uber obviously was very successful with this ~same premise

Smart Charter: I assume you can easily book a private jet online now?

Founder's Forge: linking record-keeping and payment is what makes Ramp great; 10 years of fintech innovations made executing this much easier

Spark Innovations: this is basically the premise of Airtable

Also interesting that it seems like his relatively minor 1 year stint at pre-IPO Google was successful enough to pay for many other endeavors.

It's a great example of the power laws in startups: it's much more lucrative to have a minor role in a major success than a major role in anything minor.

You can get a much higher hit rate with more constrained agents, but unfortunately if it's too constrained it just doesn't excite people as much.

Ex. the Grit agent (my company) is designed to handle larger maintenance tasks. It has a much higher success rate, with <5% rejected tasks and 96% merged PRs (including some pretty huge repos).

It's also way less exciting. People want the flashy tool that can solve "everything."

Amazon has scale economics, branding power, and process power. It would take years to fully rebuild Amazon from scratch even given unlimited money.

Right now, OpenAI's brand is actually probably its strongest "moat" and that is probably only there because Google fumbled Bard so badly.

https://help.double.finance/en/articles/10262406-how-can-i-v... makes a big difference, since it sounds like Apex does have their own ledger of accounts, independent of Double.

Evolve not having their own ledge was exactly the problem.

I wouldn't consign it to the graveyard that quickly.

It's a lot easier/more common for Google to kill internal projects and small acquisitions.

A $16B write-down is far less likely, especially when many Googlers internally realize how much a threat Microsoft is with GitHub + VS Code.

Is the "sidecar" open source too?

Incorrectly firing a high performer is nowhere near the harm of incorrectly jailing an innocent man.

> This is such a weird request for technology workers. You want to work with low-performing coworkers?

A ton of tech workers are, in fact, socialists who think job expectations should be 0.

> If everyone receives a sufficient basic income, who will fix their toilets or clean their yachts?

Obviously in this scenario we have robots that fix toilets and clean yachts. That's not even farfetched.

> A large number of people read finance blogs because they think they themselves make money with the knowledge therein.

Do you actually read his work?

I certainly don't expect to make money from reading it. I'd be surprised if a significant number of subscribers had that reason.

It's entertaining and informative about the overall world, not something I expect to make money from.