draaglom

Also the "Palestine" side of the warrants are against Hamas which also feels weird (Hamas is also not a signatory nation and many suggest that Hamas != Palestine).

The ICC prosecutes individuals not states, so there's no contradiction here.

Given Palestine is a signatory does it mean they have to take action to extradite the Hamas leadership to face trial?

Yes

What consequences do they face if they fail to do that?

There's no penalties built into the statute. It tends to have diplomatic blowback. See [1] for a prior example.

[1] https://press.un.org/en/2018/sc13623.doc.htm

I'd answer this from two perspectives.

As a forecaster: It's fun! It's an interesting way to learn about the world -- rather than gathering inert facts, you're forced to integrate them into a mental model, and then your model is tested for its validity empirically. It's also difficult and competitive, if you like that sort of thing.

As a consumer of forecasts: There's good research that prediction markets and other forecast aggregators are the best technology we have as a society for quantifying uncertainty. Not everyone will listen to them, just like not everyone eats their veggies, but c'est la vie.

I don't think there's too much risk of self-defeating forecasts (where a low forecast lulls decision makers into a false sense of security) - at least not yet. They're still pretty niche.

I think the article focused on base rates because they're a relatively unusual and legible "trick" to coming up with a forecast, but really they're only one element of a forecast; typically a forecaster will think about many different ways to "attack" a question and synthesize them (somehow!). Choice of denominator for your base rate is very important also and can radically change the answer you get.

The sites which host these forecasting competitions correct for the bias against rare events through what's called "proper scoring" rules -- there's some specific maths to it, but the short version is that you're exponentially rewarded for being a correct contrarian and exponentially punished for being confidently wrong.

There are limits to that too, of course -- the folks in the article will "only" have made on the order of mid hundreds to low thousands of predictions, so roughly speaking, you can expect these people to be calibrated for 1% or 0.5% odds but probably not 0.1% odds.

Yes, serious forecasters predict on hundreds of questions & the relevant websites prominently feature "binary calibration" plots.

This is mine on Metaculus (mentioned in the article):

https://imgur.com/a/d3s67xk

There's still a bit of noise at 205 predictions but you can see a pattern emerging!

I don't have any knowledge of IFTTT's budget, but the truth value depends on the exact framing of cost.

Your framing is "the marginal cost of any given request rounds to zero" which is probably true.

Another likely true framing is "there are substantial numbers of users on legacy plans who in aggregate cost more to serve than they pay".

$26 billion (Q4 2022 through Q3 2023)

The primary goal of most large organisations' dev blog is to attract potential candidates to the top of the recruitment funnel.

This picture appears to be (presumably) the actual team doing a team building activity.

This is both a reasonable choice given the inferred instrumental goals of the blog, and a honest reflection of (one part of) the team life, assuming it's a photo of the real team.

See also the venerable "why most unit testing is waste" https://gist.github.com/ktzar/596ee5aae7c41f2e585331e4b71d1e...

and previous discussions on HN: https://news.ycombinator.com/item?id=15591190

https://news.ycombinator.com/item?id=7353767

I've just learned, the term of art for energy cost factoring in labor, infrastructure, replacement, etc is "levelized cost" or LCOE and by that metric utility solar is indeed already cheaper than fossil fuels and nuclear power:

https://www.lazard.com/media/2ozoovyg/lazards-lcoeplus-april...

It looks like utility solar is currently ~33% the LCOE price per kwh of nuclear or 85% of the price of gas (CCGT).

This is an increase relative to 2021 (20% of nuclear / 60% of gas)

(As I understand it, the cost increase between 2021 and 2023 is from cost of capital and shipping)

Naively projecting out the LCOE trajectory, it indeed does not look like it's going to get to be 'dirt cheap' soon - eyeballing, the LCOE curve over time appears to be flattening towards a 5% or smaller cost reduction year over year.

how: ice cores (I don't know the answer re: 1600s)

As long as you believe you can acquire customers for some margin less than (you project) they will pay you across their lifetime as a customer, the rational choice to to maximise your money is to spend all the money you have (and more!) on acquiring more customers.

As a result, the majority of SaaS businesses aren't profitable, and people talk mostly about MRR.

The decision likely got made before performance was a major constraint.

As I understand it, Instagram is a python codebase and (guessing) may be the primary motivator here.

Probably the first, say, 100 person-years of effort poured into the Instagram codebase were done at a time when product development velocity, not performance, was the main priority.

It's not that bizarre. It's path dependence. They have an existing codebase with hundreds (thousands? tens of thousands?) of person-years of effort contributed in python already, so a complete rewrite would be too expensive to consider.

someone takes what you said to an employment tribunal and makes the case they were fired without the proper dismissal process ('unfair dismissal')

I'm no financier and I don't know anything about a 999 limit, but apparently SpaceX has been doing something to make it possible:

https://twitter.com/TechEmails/status/1518408959022968833

I've seen two options floated:

- replace RSUs with cash payments on same vesting schedule @ equivalent of final sale price

- keep RSUs despite being private (apparently SpaceX issues RSUs just fine & has regular liquidity events)

I'm not sure if this is the _main_ reason, but one thing that makes node_modules size more than an aesthetic concern is serverless.

Booting a serverless function with 100s of mbs of modules takes an appreciable time - to the point where some folks webpack bundle their serverless code

this is excellent and I will definitely be using it in the future - thankyou!

The relevant terms of art are SAML, SCIM, SSO.

There are several providers - Okta, AWS, and more.

Fair warning: expect to pay enterprise tax on all your SaaS plans for the pleasure of allowing you to do SSO!

It seems to mostly be a me problem, on reviews of other coworkers PRs her comment seem reasonable. That could just be not fully understanding scope or task at hand.

What do you think explains the difference?

* Are there ways you can explain yourself better that others are doing?

* Could the problem honestly be with your code being hard to understand? Could you simplify?

* Could you deliver in smaller chunks, that are each easier to understand?

* Is it about working on a tech or product area that they aren't so familiar with? Perhaps you can help bridge that gap with a lightning talk or some new documentation?

I have not had a direct conversation as I'm not sure how to go about it or phrase it. We seem to have a good relationship and I don't want to potentially ruin it going about this in the wrong way.

You've got to place trust in your colleagues that you can have adult conversations about what's working well and what's not. It doesn't have to be a big deal!

It could be as simple as:

"Hey <name>, I feel like a few times lately PR reviews hasn't been smooth. Have you noticed that too? Is there anything you think I could do differently?"

We have basic standards

One thing that could help here is improving your team standards for a PR author! E.g. at my company, we have a PR template which encourages you to add a screenshot/screencast of your feature working.

We also encourage adding test steps to our PR template, to make it easy for reviewers to try the thing themselves. Good test steps might look like:

* Run the app as normal

* Turn on feature flag XYZ

* Head to localhost:3000/new-page and click all the widgets

* You should see the widgets created in your db with this query:

It sounds like work, but it's probably the steps you did anyway before you put the PR up! so it's more of a mindset thing

I don't have answers but some questions that might help:

* Are their code reviews _of you_ poor in particular, or are they poor in general when reviewing anyone's code?

* Are they reviewing your code in good faith (and are just finding it challenging) or in bad faith (and can't be arsed or don't like you / the project / etc)?

* Have you had a direct conversation with them about it? (Is your relationship with them strong enough to enable that?)

* Do your team have standards for a code review? Expectations for an author and for a reviewer?

I can't speak for others, but as a hiring manager I prefer the latter because:

* It suggests the person understands the bigger picture behind what they're doing (rather than just "punching tickets")

* If your code sits in a 'financial critical path', this usually implies stricter requirements in your engineering in some respects -- you'll probably have had to think harder about reliability, cover more edge cases & co-ordinate with others more around requirements

The headline figure of "3.8% of global carbon emissions" is currently un-sourced - so I'm very curious to see what it includes.

IEA claims datacenters account for 1% of electricity demand and data networks are another 1%:

IEA (2020), Data Centres and Data Transmission Networks, IEA, Paris https://www.iea.org/reports/data-centres-and-data-transmissi...

Now, those figures are _electricity_ not _carbon emissions_ - so perhaps the 3.8% figure includes e.g. datacenter construction emissions, or emissions related to producing servers and networking equipment?

See also the google results for:

"when was running invented"

"how many terashits does the ps5 have"

Top line: work out how much value it's giving your clients and then aim to price to capture a fraction of that.

Without your app, it'd cost your clients $X in hours worked doing the book keeping, organisation and confirmations plus $Y in lost business due to mixups / confusion / etc from the alternatives.

What units you charge in to capture this fraction (billing for usage, per seat, whatever) is your second question, but you want to keep it as simple as possible while aligning to the value that the client is getting. Per successful booking probably makes sense here (I would imagine...)

But what do I do with the cancelled bookings [...] I still pay for the sent SMS notifications :(

I'd suggest accepting these as a cost of doing business and pricing high enough that it doesn't matter.

_people_ may believe that but I don't think the IRS does. Spending crypto that has appreciated in value on goods and services is still a taxable event for CGT purposes.

The 30 day figure is likely derived from the legal limit under GDPR for a Subject Access Request (one calendar month).

Why commit to a tighter SLA than you legally have to?

the 6% is electricity consumption within the home; the second link puts datacenter usage at 1% of global electricity consumption.

See also: Bret Victor's excellent "What can a technologist do about Climate Change": http://worrydream.com/ClimateChange/

Domestic computer use simply isn't a big fraction of a person's total energy consumption:

e.g. this study[1] in the UK puts "IT" as <6% of household electricity use, which is itself a fraction of a person's total energy use.

edit: and this[2] indicates that datacenter usage is also not very significant.

Therefore, no amount of optimising web pages will make a meaningful difference to carbon output.

As web professionals, it's better if we direct our focus towards more productive areas around this goal -- by e.g. donating to relevant campaign groups, or using our tech skills to produce media on the topic.

[1] https://assets.publishing.service.gov.uk/government/uploads/...

[2] https://www.iea.org/reports/data-centres-and-data-transmissi...