Hacker Newsnew | past | comments | ask | show | jobs | submit | jmalicki's commentslogin

You can manually stack PRs by making the merge target another branch.

The workflow just makes it a pain, since you have to manually rebase in both the branch and the UI after the original PR merges.


That doesn't work if the base and PR branch are in different repos, which is the most common way of doing things in Github.

It's relevant in that it's an example that people are doing the easy part - the coding - and skipping the hard part - the benchmarking and proving it works and provides value.

A PR without evidence it works and expectations for the benefits using the new feature would bring is kind of worthless.


The government should outsource way more of their traffic to third parties than a business should, since the government is inefficient, right?

Poe's Law strikes again. I legitimately can't tell if this is sarcasm.

It is sarcasm. I always get screwed by Poe's law, since dry sarcastic parodies of extremist views is one of my favorite methodologies for producing humor.

My first was in college on the lab computers, I was like "can I create a pthreads bomb instead to circumvent the fork bomb protections?"

Luckily the head sysadmin knew me and was in the room at the time, and I sheepishly explained by the time I realized it worked it was too late for me to stop it, he seemed understanding, understood it wasn't malicious, and luckily got that what else is a CS department for than for students to learn about this stuff?


Is the CEO responsible for a company's financial performance? Do they review every line of code the company writes?

It is more irresponsible to spend the time reviewing all of the code rather than spending that time on things with bigger levers for satisfying your customers.


yes but if a dev pushes a line of code that wipes the accounts of millions of users at a fintech, the dev will get fired but the CEO will get sued into oblivion. if the agent isn't responsible, you HAVE to be, cause angry people wont listen to "it's no ones fault your money is gone"

It just makes comparing funding rounds hard to understand, since money in the bank is money in the bank, and a lot of the "committed capital if you reach a milestone" is capital that would be easy to get if you reached that milestone, if it is sufficiently advanced, and has enough outs, etc., that you may as well have just raised another round in the future.

Note that even that "money in the bank" of traditional venture firm is not really money in the bank. VC, PE, and hedge fund managers usually don't have all the cash for the fund sitting in the bank at all times. Rather, their agreement with the LPs that fund the fund is structured as a series of capital calls: it gives the fund the right to demand that their LPs deposit cash in their bank accounts within 10-30 days, which can then be used to fund the investments that the VC firm makes. The capital calls are backed by legal documents enforceable in court, with pretty stiff penalties for failing to meet a capital call.

Such a funding structure here isn't all that different: the funding agreement gives OpenAI the right to call on their backers to make certain cash deposits, contingent upon milestones being met. Deep down inside, "money in the bank" doesn't actually exist, it's just mutual agreements backed by force of law.


When a startup raises money without contingencies, typically they do get a large amount of money in the bank all at once.

If investments are not tranched then the money is not delivered in tranches, yes.

The first rule of tautology club is...


That’s logically inconsistent. If the company was performing poorly enough that they couldn’t meet their funding milestones from a previous round, they’re not going to have an easy time raising the same money in a future round.

The milestones aren’t a hard-stop that forbids the previous funding round participants from providing the money if they still choose. It’s just an out.


sure they can. that's the whole point of the "pivot"

What I am saying is that if you do meet the milestones from your previous round, you're going to have an easy time fundraising anyway, so funding contingent on milestones isn't that different than just saying "well, if we need more money we can do another round"

Fundraising rounds are difficult, laborious, and distracting. It would be extremely different to try to multiply the number of rounds by 3-5X. There's nothing easy about that.

You're also ignoring that the market changes frequently. If you only raised as much money as you needed for the next 4-6 months with plans to re-raise all the time, you'd have to constantly be sizing your growth plans up or down based on how the market felt about startup investing that month.

Imagine the company having to either do speed hiring or large layoffs every few months to adjust to the size of the fundraising round they were able to get this time around.

Nothing about what you're suggesting would be easier, or easy at all


It seems pretty simple:

Funding Round A: VC “A” invests 200M (100M immediately and another 100M if sales grow 10% or whatever)

At 6 months the company will either get the other 100M automatically (meaning they grew sales 10%) or they don’t (meaning they grew less than 10%).

Assuming it’s the later they can then do another round during which they try to get the other 100M. In all likelihood VC “A” won’t be interested (or interested at a lesser amount). They could go ask VC “B” for an investment but it will likely be less than 100M as well because they didn’t grow as much as “the market” anticipated.

Nothing complicated at all.

I’ll give you $1 dollar for your banana today and another dollar in a week when it has ripened. If it’s rotten when I come to get my banana I won’t give you the other dollar. You have your original $1 and you can still try to sell your rotten banana to another HN reader but you probably won’t get another dollar this time.If instead you have a ripe banana I’m sure you could easily find a buyer.


But you have limited funds to take in a lawsuit realistically the worst they can do is fire you, it's not like being blameable somehow makes you more valuable.

Cool!

It's also nice that Sutton & Barto belabors a lot of old stuff that is no longer obsessed over, and this skims through that and gets to the stuff that is much more relevant today.


> Where are you seeing people being told that AI is infallible? AI is being hyped to the moon, but "infallible" is not one of the claims.

I see all kinds of people being told that AI-based AI detection software used for detecting AI in writing is infallible!

You want to make sure people aren't using fallible AI? Use our AI to detect AI? What could possibly go wrong.


Where did you see this claim about AI-based AI detection?

The funny thing is this study only looked at non-EMT ambulance drivers - i.e. those true ambulance drivers!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: