jhugg

I wish my knowledge cutoff was August 2024.

Most footage pulled from security cameras is only so-so anyway. Faces aren’t always perfect. Maybe this changes when they’re all 4kHDR.

You do, in fact, opt into this manually on an iPhone.

This is a hard problem to fix with UX, as evidenced by Apple's over-simplistic warnings.

e.g. Threads may collect your financial data! But only if you give it to them, usually to purchase ads or verifications, etc.. This scary warning is over-scary.

e.g. Mastodon collects less data about you, but there's no warning for "The backend is unencrypted and likely run by a handful of humans (who are probably nice but answer to nobody)."

There are a small handful of exceptions. Many were in the exactly the right place at the right time. That’s not a repeatable strategy. I wouldn’t start RedHat today.

Someone helps you? Or does it for you? Or you copy a solution from online?

The government can still use the JPEG though.

Ah but the government will enforce my claim on the house if I’m holding (rightfully) the title. And if someone steals the title, it doesn’t mean they own my house.

Two things that jumped out at me: 1. It’s 2021. You can get a remote job for a big company that pays 10-15% less in Akron, not 40%. If you don’t want to work remote, you can still use BA remote salaries as leverage for local negotiations. 2. What “ggregoire” said: Engineers vary in quality EVERYWHERE. Many people holding onto CTO-type jobs in Akron or in BA startups can’t always move laterally. The salaries for everyone are rising in 2021, but for the truly strong (or for those who can nail an interview) they are rising even faster.

Re VoltDB:

>In VoltDB, all replicas for a given shard are updated synchronously by the client application. This is where VoltDB pays a significant performance penalty for write operations when compared with Raft/Paxos-powered distributed SQL databases. Distributed consensus protocols like Raft and Paxos require writes to be sent to all replicas but commit as soon as a majority of replicas have acknowledged the request. Waiting for all replicas to respond is not necessary since the consensus can be established with a majority. Additionally, VoltDB does not detect network partitions by default and requires a special network-fault-protection mode to be configured. When a node of the cluster gets partitioned, the network-fault-protection mode comes into play. It negatively impacts cluster performance by increasing cluster recovery time for not only accepting writes on the shards whose replica was lost in the node partition but also for repopulating the data on the partitioned node when it joins back the cluster.

Wow. Basically none of that is true.

This is some nice work on the issue from Peter Bailis: http://www.bailis.org/blog/understanding-weak-isolation-is-a...

Well, 10km^2 is pretty tiny in a country the size of China, and I'm not sure how high up the pollution goes (higher than buildings but lower than planes).

So it's still a lot of pollution, just much less actual mass than I would have guessed.

That's really interesting. Maybe the pm2.5 is less visible than the PM10, but maybe I'm just way way off.

As for the volume of air, I'm most curious where the 15% measurement was taken and how consistent it was. How far from the tower? How many different places were measured? How many days are in the sample? What's the P-Value?

But still, thanks. Makes this interesting to think about.

So... to drop the PM2.5 amount by 15%, this tower must be removing many many tons of particulate matter every day. How is it removed from the filters they speak of? How expensive is that to do? I have some questions about the practicality.

On the other hand, I wonder if anyone's ever built a 100m placebo before. It could be a really interesting university study on the placebo effect in disguise.

You can have it both ways. Maybe you don’t get college credit for learning how to interview, but a college could offer a free seminar on interviewing well in the evening or something.

Colleges very much care how well their graduates do in the workforce, as it’s a key way they’re measured. It’s a tough balance to mix mind-expanding academia and direct preparedness though.

Worth noting that Apple’s share of high-end Intel chips is much higher. Thus, Apple’s share of Intel’s consumer revenue is probably substantially north of 10%.

Be was designed to be lightweight and parallel. It was optimized for many threads and the API pushed you to embrace threading. It also had pretty decent scheduling for media stuff. Not quite real-time OS, but closer. It was screaming fast and responsive.

The catch is that it was much less mature. It was single user and had very little real security. It had basic Posix support, but NeXT has much more rich BSD-ishness.

Bought and scalped 4 Hamilton tickets.

One reason might be that it seems easier to mix languages with Rust vs. Go. The C interop is pretty sane and Go has a few more gotchas in that department.

The rest of the Rust v Go debate may be similar to the 1000 times people have had it before.

So Windows has this problem more than other platforms because of OEMs and drivers and such are 3rd party by default, rather than as the exception.

Still, there isn't really sufficient protection to avoid telemetry and data collection on most of the platforms I use.

Mac App Store apps are somewhat sandboxed, but many common apps aren't. And running "little snitch" is great, but it's not for typical users.

IANAL, but fair use doesn’t cover commercial art used to sell something, like this DVD packaging. If it did, the stock photography business might crumble overnight.

As the unfortunately named grabcocque pointed out, you’re only really replacing the simple button press with one gesture. Beyond that you’re replacing complex uses of the button with gestures. And most of the complex stuff is non-essential to using the phone.

You didn’t need to buy “horse insurance.”

The real change happens when it doesn’t make buisness sense to insure you.

As I mentioned in a previous comment, you can fix some of the problems; caching metadata is a great example.

The real issue is not whether abstractions are good, but at what layer and how pure/leaky they should be.

If I build a SQL engine on top of RocksDB, I still need a way to scan a bunch of tuples and apply a predicate. It's probably faster if RocksDB lets me hand over a predicate and returns an iterator of matching tuples than if I have to iterate on top of rocks DB. Maybe this difference is large -- maybe not. It depends on a lot of details. Certainly a custom storage layer turned to apply predicates fast is substantially faster.

If I build a SQL engine on top of a distributed KV store, then I really want to push the predicate scan down to the individual nodes, and I probably still want to push the predicate down even lower. For most queries, I also want to have understanding of how data is partitioned.

You can do all of this, but the abstraction gets leakier and leakier as you start to get reasonable performance. At the time, the FDB SQL layer didn't seem to do any of this. Maybe not at Apple it is much smarter and more intertwined.

The planner issue you mention is real, but I'm slightly more optimistic that engineers are willing to identify slow queries and figure out how to adapt them to the new system if the rewards are clear.

N.B. If you're using SQL for KV gets/puts, or if you're joining one row to a handful of others by primary key (e.g. lookup order items in order), then this stuff doesn't matter much. But if you give someone a SQL layer, odds are they'll want to run a query sooner or later, even an OLTP-ish one.

To address the "completely speculative "post-mortem" by someone who knew nothing about the technology" bit: I was only talking about the FDB SQL layer performance and design, much of which was public at the time of the acquisition.

To be pedantic, I don't think I agreed that any of my claims were hasty, just that some of them could be addressed more easily than others. Caching metadata, for example.

To be clear, I have a lot of respect for FDB and what their team did; it was only the SQL layer put on top that seemed poorly thought through.

All of these rules seem to make sense. They probably made sense 5 years ago?

But seriously, why the grace period? If I condone violence to promote a cause in October, is that ok? Just not next month? Is revenge porn ok for another 6 days?

Sigh... yes, but the difference between systems that do E2E encryption and WeChat is pretty dramatic.

It's not clear the government of any country can freely read your Signal or iMessage messages they way China can read your WeChat messages.

That’s why he said “most” and not “all”.

Gruber says what I said: https://daringfireball.net/linked/2017/09/20/goode-apple-wat...

JIT translation has come a long way and MS plans to do exactly this with x86 software runnning on ARM in the near future. It’s not impossible that A12s with custom silicon working in concert with software JITing could provide a decent experience.

I would be a lot of work though. You don’t just have to translate the compiled user apps, you need to make things like AirPlay work, and that's an example of a feature that uses specific hardware acceleration. And some things like Thunderbolt might not work at all without Intel’s help.

They don’t sell hundreds of millions of macs. It might not be worth it. Why not just wait a year? It’s not like Windows laptops have access to better chips than they do.