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

No, it's an affectation.


I'm sure you can find even more things to sneer at me about. Perhaps you would find my choice of programming languages flamboyant and my attire effeminate, as well.


Both of these only apply for US citizens or permanent residents so no, it's not just about paying some amount of money to avoid the theatre.


This site works fine in safari/mobile safari, it is not ‘chromium only’


WebKit and its derivatives then.


I tried it with FIrefox 127 (production) and it worked just fine for me even though there is a huge banner on the top.


> if I turn off Lock Screen notifications and turn on time sensitive notifications then will I get no marketing notifications, and only notifications about my driver turning up?

It's up to the app developer, they get to mark notifications as time sensitive or not. So if someone decides that because a coupon is expiring soon it's "time sensitive" to ping you about it, then they can mark it as such. Hypothetically Apple could frown on this in app review, but it isn't something app reviewers are likely to be able to reliably catch.


Same is true on Android. Uber lets you disable annoying notifications in App or through settings because otherwise fewer people would use it.


> Something that isn't talked much about IPv6 and I believe has subtle and indirect influence on it's adoption is that it is far far far less human-readable than IPv4

What? This comes up in like 95% of ipv6 threads on HN (see also: ‘they should have just added an extra quad to v4 addresses’)


    My grand father used the dots in the address!
    My father used the dots in the address!
    I used the dots in the address!
    Henceforth every human being should use the dots in the address till heat death of the universe!


I'm certain the issue here isn't the dots.

123.123.238.217.110.100.1.1 would still have been perfectly readable.

fdd2:1228:3372:1sdf meanwhile is pretty unreadable even at IPv4 length.


I don’t understand… why do you consider the way longer one to be more readable than the shorter one? I find the colon string a lot easier to read, a lot easier to compare at a glance, and a lot easier to memorize.


ipv6 is 16 bytes, so more like

123.123.238.217.110.100.12.255.123.123.238.217.110.100.242.176


True, but we probably don’t actually need enough bytes to address all the atoms on the surface of the earth a hundred times over.


Good! If we did then we should've made it bigger.

We don't know exactly how many address bits we're ultimately going to end up needing. Our only options are to go for "too big" or "too small". Giving how much effort it takes to deploy a new IP protocol, we should err on the side of having too many addresses rather than too few.


You can still backup iPhones to your desktop instead of iCloud. At least for now.


Unless you simply don't trust Apple's security promises (in which case why are you using Apple devices), iCloud backup is now E2EE encrypted [1]. A bit of wringing to turn it on, but totally worthwhile.

[1] https://support.apple.com/en-us/HT202303


There are differences between iCloud and local backup. For example, iCloud backup doesn’t backup your Notes or Health data but local backup can. Sync != backup — without a backup, if you sync a bad change you’ve lost the data.

https://support.apple.com/en-us/HT204136


Both of these are stored in iCloud (if you enable) and are backed up in the cloud (and E2EE). All other large repositories of data are not sourced from my Apple devices


Why would one even bother with that when you have like... a cable at hand and disk space.

Though recently simple things as copying files have been a challenge.


You still need to back up your disk somewhere right? Disks age and fail.


You backup the disk to more disks. Isn't that how it's done?


Related, but why phone disks don’t age and fail? Simply because of low r/w?


I think they do, but my guess is that most people don't keep their phones long enough for that to be the reason to stop using the phone. Usually the phones get damaged/lost/too slow to run modern apps etc.


It is only E2EE if advanced Advanced Data Protection for iCloud is enabled.


Here's exactly what it means: Someone at Facebook, when creating the listing for the Threads app on the appstore, told Apple that the app might possibly collect Health data (etc). These labels are entirely based on self reporting by the person doing the upload. That's it, that's the entirety of what these privacy label things mean: the company making the app has made these claims about what it collects.

In this case Facebook appear to have simply ticked every possible box for data collection regardless of whether the app actually does it or not. Note you can't just get health data on iOS without asking, so people would notice if they tried. My guess is that actually figuring out what they do/don't collect was too hard, so they just said yes to everything.


This link says absolutely nothing about Flutter usage.

It's about apps that are already written in native iOS code, which are currently using custom Material Design components (which are mostly/entirely in obj-c), and that going forward those custom Material components are going to be phased out and apps will use standard UIKit elements instead.

This tells you absolutely nothing about Google's commitment to flutter.


So it says nothing about using Flutter even though the entire purpose of Flutter is to write cross platform apps and Google is moving toward not writing cross platform apps and are using standard UIKit components.

They also aren’t using Dart and are using Objective C.

But that doesn’t mean they are moving away from Flutter for first party apps?


They aren't moving away because these Google apps weren't using Flutter in the first place. The only ones that were are like, Google Pay and Google Classroom.

https://flutter.dev/showcase/google-pay

https://flutter.dev/showcase/google-classroom


Is that really the argument you want to make? That Google doesn’t even dog food their own products for their most popular apps?


I'm not making any arguments, just stating facts.


i don't find it too compelling, but this test could potentially help you understand, to some degree, how important battery consumption of an app actually is to users.

so you run a test where you intentionally consume more of some cohort of users' battery power (you could have several cohorts where you consume more and more power, even). and you look to see if the rate at which your app is deleted/force-quit by the cohorts with more power usage goes up. if it does then you can assume that you're overdoing the battery drain. if it doesn't then you can assume users don't really care (or don't care enough; maybe they're unhappy but your app is too important to them to delete).

why this could be useful is when you're deciding what to prioritize - if you've got data saying that users don't care about excessive battery consumption and they'll keep using the app anyway, you can argue against optimizing for battery life in future development, presumably letting your developers do things faster/more lazily. or, it could show that battery life is super important and be a valuable argument to prioritize power optimization work in the name of keeping your users from jumping ship.

personally i'd rather just presume that battery life is important and that optimizing for efficient use of our users' batteries is the right thing to do, regardless of hard data, but i'm sure there are people out there that think differently.


hard to make that study work, it presupposes that users (a) understand that their battery life is decreasing and (b) understand that this application is responsible for it (and to what degree). Those are two big if's, it's more likely they'll chalk it up to battery aging than to a malicious application that used to be well-behaved. That doesn't however prove that users don't care - it only takes one article with a headline "Phone draining quickly? Facebook battery usage has increased by XX% the past year and responsible for majority of its users battery drain" to completely swing the pendulum to the other side where more users are deleting your app because of this new reputation, than would proportional to the actual battery drain; but without that trigger the study is not complete.


You just measure user behaviour to prove your hypothesis. If your assumptions were wrong, you’ll get null results and move on.

An article like that coming out would bias and invalidate the test.


I’ve seen arguments that dark mode is important for accessibility, which seems reasonable to me, and depending on the company might be a dealbreaker.


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

Search: