pixel_tracing

How is this secure? Can the agent run `rm -rf /` and destroy my machine by chance?

As someone who used to work on that team, it’s so interesting hearing thoughts from external public on the team.

How can you predict a supernova will occur in months when these processes take thousands of years?

How is your explanation simple and where is the data to back that? This theory isn’t crackpot, global sperm rates are declining, the average testosterone of men is lower than it was during your grand-fathers time. Certain plastics have been shown to be endocrine disrupters.

Your theory might work in westernized countries but this trend is global according to the article, certain countries enforce more traditional values for men and women and those countries are also seeing a decline.

I never understand this argument, we have lots of space on this planet for humans, it’s the industrialization that’s harming the planet not more people

This is pure speculation, but I wonder if endocrine disrupters present in plastics are leading to a decline in testosterone and therefore decline in fertility (I also wonder how those disrupters affect women)

Projections and forecasts for entire sectors use the data to make decisions, for example China built so many homes in projections of population / census estimates, their source data turned out to be incorrect that’s why you see a situation like Evergrande.

Incorrect, as common sense would dictate lots of people who work at Apple live close by the office (homes aren’t the only option, there is a thing called renting)

No data tables in library? Other than that nice work!

A well known very large successful trillion dollar company emphasizes this heavily and it’s called identifying Cause By, regressions are categorized before a build is submitted, in the current build, or in previous builds. It’s extremely important to identify cause by (commit) in order to either revert or fix.

Can we please get array support and aggregates like collect_set

Also fellow ex-Apple here :wave:

I actually quite liked Radar, the focus on Radar hygiene, finding cause-bys, diagnosis, discussion comments and attached sysdiagnose reports were quite helpful compared to previous companies I worked at.

But you are right there were moments in my time there where just by looking at the build configuration I could rule out an issue immediately

I don’t suggest this.

Your application may crash due to:

- hangs / spins - memory corruption - programmer error / faulty logic (think loooping infinitely) - thermals / memory usage

Let launchd handle restarting your application by allowing the user a “Relaunch” button

It _is_ literally increasing complexity. Because now the call stack has added layers of indirection:

[0] abort() [1] curry call site [2] partial closure 1 [3] partial closure 2 [4] partial closure 3 [5] partial closure 4 [6] <actual place of issue> [7] partial closure 5 [8] partial closure 6

Compare this to something isn’t using currying:

[0] abort() [1] call-site 1 [2] call-site 2 <actual place of issue> [3] call-site 3

Dealt with this enough at a previous company I’m glad on my team at FAANG people are reasonable and don’t just shoehorn functional paradigms unnecessarily

While I find these topics esoteric and very interesting in normal day to day code during a code review I’d probably say make it less complex, because majority of the time spent is reading code this makes code harder to read