Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
willseth
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
19 ms
·
241.
▲
by
willseth
5y ago
Thank you for reinforcing my point
242.
▲
by
willseth
5y ago
Great, maybe OP shouldn’t post and people shouldn’t upvote outdated blog posts with bad advice
243.
▲
by
willseth
5y ago
I know what attrs is, thanks. “Everyone should use X library” is always bad advice, and it’s especially bad when there is language native functionality that covers common use cases for the library. Python has a dependency problem, maybe we
244.
▲
by
willseth
5y ago
Someone should tell this person about dataclasses
245.
▲
by
willseth
5y ago
I appreciate all your hard work and I like Homebrew, but I think updating high-level packages when a descendent dependency is updated is the wrong behavior - at least in this example. If Postgres has an unversioned dependency to PackageX, t
246.
▲
by
willseth
5y ago
Clickbait
247.
▲
by
willseth
5y ago
This is the only reasonable suggestion I've heard, but it's still very messy because it would not only require even more careful policing of app code, but mostly because Apple would have to invent an entirely new fee structure for
248.
▲
by
willseth
5y ago
> The problem is them preventing you (the developer) from allowing the user to use other forms of payment processing within the app itself. One major kink in this idea is that it breaks the free tier model, since paid apps are essentiall
249.
▲
by
willseth
5y ago
This is true, but it's not worst case by far. Most video is 24 or 30 fps, so about half the typical 60 hz refresh rate. Still a nice optimization path for video. I'm not sure what effect typing in an editor will have on screen ref
250.
▲
by
willseth
5y ago
Video playback is accelerated by essentially custom ASIC processing built into the CPU, so it's one of the most efficient things you can do now. Most development workloads are far more compute intensive.
251.
▲
by
willseth
5y ago
> This just feels fighting the seemingly inevitable fate of Python. Which is what, exactly? If you’re suggesting that devs will lose interest in Python then you’re simply not paying attention. Python is _gaining_ in popularity, over Java
252.
▲
by
willseth
5y ago
Making it easy to hide comments == making it easy to forget to update comments.
253.
▲
by
willseth
5y ago
The Protobuf documentation made me cringe. Every character of its "personality" adds a cognitive burden for the reader and a maintenance burden for anyone who has to update it. If a developer wants to be cute with the same brevity
254.
▲
by
willseth
5y ago
The author of that article was way off. First, his evidence is that an email attachment triggered a report, and we already know email is the only data stored unencrypted in iCloud. Email scanning is the most plausible explanation for the To
255.
▲
by
willseth
5y ago
> 1. Photos (and other documents) are currently uploaded to iCloud un-encrypted Incorrect. Photos and documents are encrypted both in transit and at rest. They are not E2EE, however - i.e. Apple has decryption keys. > 2. These photos
256.
▲
by
willseth
5y ago
Ugh. Feel free to expound any of your vague replies in this thread with actual explanations that make sense under any reasonable interpretation of "on device."
257.
▲
by
willseth
5y ago
It's too late to edit my post, but you're right. iCloud Photos are not E2E encrypted, my misunderstanding.
258.
▲
by
willseth
5y ago
This is a confusing paragraph, but the "final step" is not matching per se. The final step reveals whether a match occurred - but it's clear that the database exists on-device and the database lookup occurs on-device. Not
259.
▲
by
willseth
5y ago
Wrong.
260.
▲
by
willseth
5y ago
No, he's not. Read the documentation. The hash database your photos are compared to will live on your device, and scanning happens entirely on-device. "Apple further transforms this database into an unreadable set of hashes, which
261.
▲
by
willseth
5y ago
> scanning your entire Photos library and sending hashes to an unaccountable, no oversight nonprofit (NCMEC) to be compared with CSAM hashes - with no way to contest what you send. This is simply incorrect. It's clearly documented h
262.
▲
by
willseth
5y ago
OK so let's all lose our shit over things that haven't happened.
263.
▲
by
willseth
5y ago
This boils down to two separate arguments against Apple: 1) what Apple has already implemented, and 2) what Apple might implement in the future. It's fine to be worried about the second one, but it's wrong to conflate the two.
264.
▲
by
willseth
5y ago
Not sure why this got downvoted. This is correct and very thoroughly documented.
265.
▲
by
willseth
5y ago
Apple doesn't "scan" iCloud. Not sure what you're talking about. Generally everything in iCloud is E2E encrypted, with the exception of iCloud Backups, where Apple holds onto a decryption key and will use it to comply wi
266.
▲
by
willseth
5y ago
It's baffling. It seems like nearly everyone losing their shit over this doesn't understand how it works. Most of the commentary I see here and elsewhere is based on a misunderstanding of the implementation that blends the CSAM sc
267.
▲
by
willseth
5y ago
What is hostility to you is customer service to me.
268.
▲
by
willseth
5y ago
It has nothing to do with GitHub being exempt from anything. It's that users are bound by the terms they agreed to in a ToS. If there is a conflict between a user-created license and a site's ToS, the burden is on the user to reso
269.
▲
by
willseth
5y ago
It's not binding because the other party hasn't agreed. You agree to terms when you use the site. One party can't unilaterally change the agreement without consent of the other party.
270.
▲
by
willseth
5y ago
One of the nice things about being at a restaurant is that you get to be away from your digital bullshit and be around other humans who are also not focused on digital bullshit.
More ›