Good news; a true necessity if eSIM is to be consumer friendly.

A smartphone is the ultimate, single-user personal computer. Choosing a device is too intimate for me to use any sort of tabular comparison tool. The device needs to be right for me qualitatively also.

I strongly recommend picking a handful of devices and getting a variety of opinions from reviewers. Then, weigh those opinions against what features are most important to you.

If this is your main computer which most likely it is for most people, it’s worthwhile to spend some time on selection.

People get so hostile over such things. I have an iPhone for business. I have a Pixel for my personal use. They’re alright. It depends on what you need. Still a smartphone enthusiast.

There’s a lot of inertia to overcome here. There’s advice online everywhere that Android may not the best platform for tablets. As someone who loved the Nexus 7, until you have a large user base that’s using the tablets, it’s a tougher sell to developers and to users especially that iPads are cheaper now than they have been in the past.

It’s an uphill battle. Google has to pay those taxes for doing such a terrible job of getting into the tablet as its own related but different market from mobile.

The baseband firmware is not so privileged anymore. Most new phones, like the Google Pixel 7, have IOMMU to force the baseband to communicate through a very restricted interface to the kernel. Certainly, you can interfere with texts and calls, but a baseband RCE doesn’t yet compromise the data stored on the phone by itself–not to diminish the seriousness or to suggest that we shouldn’t patch such an exploit immediately.

RCE, the “remote” aspect, in the operating system? So directly in the kernel and accessible remotely, such as through the networking code? I’m curious now. Most of the ones I’ve seen are in some other component that is sandboxed. True system-level privilege RCEs seem to be relatively rare. Usually, you get RCE, then you need privilege escalation to do something especially interesting.

Indeed; I’m sometimes able to leverage even a few bits of memory corruption into execution in many cases, though the hardened allocator in Android makes this a serious PITA to arrange to overwrite something useful.

True that many potential RCEs are found, but I think there are a few points to keep in mind.

• RCE classification is often conservatively assumed when it is theoretically possible even if it is not been demonstrated. Android bulletins appear to assume any memory corruption could be an RCE.
• Remote code is no longer sufficient for privileged control. Next, you have to use it to break out of a restrictive sandbox for whatever service or application you have compromised.

To expand on this, most vulnerabilities that require the vendor to actually participate by providing security updates are specific to your hardware configuration. These kinds of vulnerabilities are less attractive to most attackers because of their specificity. Attackers would much prefer to have a vulnerability that applies to many different victims, not just a specific kind. Android has gone to great lengths to update these commonly targeted components regardless of your vendor support status. Unless you believe you would be specifically targeted, the risk is fairly low.

I’m not sure it’s fair to put iPhone down. They do take security very seriously, especially physical security with their formally verified bootloader. Not seeking a flame war. I just didn’t think it was accurate. Are we so sure they don’t have individuals focused on iPhone security at Apple? Compromised devices impact their brand image while the same bugs can be used for jailbreaking. I’m sure it’s very important. I interviewed with a team up there that I believe specialized in just that. Just recently Apple implemented an emergency security patching system for their devices to get security updates out even faster.

Full disclaimer: I use both devices for software development. I have no special preference.

Oh, my heart. I remember messaging my now wife with one on Skype. It was so laggy because my phone was super budget but I was amazed what I could do nonetheless.

I can still feel the plastic texture and the delayed vibration following a half second later.

You might be surprised. My father uses a device about that age, but it’s a Facebook machine and phone call device. It’s fine for the use case if you’re not the type to place valuable information on your phone anyways.

I think this is because now the consumer knows what he or she wants. It’s hard to build a mobile UI without expectations of consistency.

Back then, Android was more marching to the beat of its own drummer as it were and more dramatically crafting its design language, its visual identify.

I’m curious to see if this will be merely a packaged version of the web page or something more.

One wonders if dropping Play Services support is enough to motivate a user who is already sufficiently determined to use a phone this outdated.

Perhaps you were being sarcastic, but I’m very excited about this feature. I often visit rural areas, and if I got a flat I would love my phone to be useful for letting family know what’s going on.

If it helps, I only have a high refresh phone display. I don’t notice the difference when I’m using my slower displays because I’m not used to seeing those applications at a higher refresh rate. It doesn’t seem to bother my mind.

I only notice it when I’m using another phone at a lower refresh rate.

Precisely this. I didn’t notice it much when I started using it, but I switch between phones frequently for software development, and I definitely feel the difference. It’s nice, but it’s not a life-changing difference. It’s just a difference.

Wow! It was hardly worth it to begin with.

If an instance is just being slow I’ll hop on to one of my other accounts, let alone down. My client makes that easy to do.

User-driven load balancing!

All refers to everything that your instance knows about. Your instance only retrieves data for which users are actually subscribed.

All can be weird on small instances if the user subscriptions don’t have a nice distribution.

This is a good point for not choosing too small. I’ve made a couple of accounts, and it looks like when a servers crosses that 1,000 or 2,000 user mark you start getting much better consistency than the micro instances with only a few hundred users.

I usually find that I have to reload a few times if I’m the first person to try to subscribe to a community. That happens uncomfortably too often if the instance is small. Even then, it can take a days or possibly never to properly federate.

I’m sure these issues will be fixed, but for now, I’d like myself a small instance but not too small so as to avoid issues with consistency.

It’s a pretty picture but oh do I hate spider webs.