> If you can find me credible evidence that Unihertz will support the device for 5+ years, delivering major version upgrades and timely security patches...

You don't even get that with most Pixel phones. Through to the Pixel 5 family, you only get three years of updates, period. Through to the Pixel 7 family, you get an additional two of security updates. It's not until the Pixel 8 family that you're getting what you demand.

That's a lot of "e-waste" that Google only recently stopped generating. ;)

But, honestly? I'm not sure why you consider the current five-years-of-updates policy to not be creating an unacceptable amount of e-waste. I have (and still use) nearly-twenty-year-old laptops with the latest Linux kernel and desktop environment software (& etc) versions available. They work just fine. The only maintenance required has been battery replacement and occasional thermal paste replacement. [0]

Only five years of updates? That's an absolutely absurd policy.

[0] Though, it's not clear that the thermal paste actually needed to be replaced... it was just fun to break out the screwdrivers and service manual.

▲

jcgl a day ago | parent [-]

> That's a lot of "e-waste" that Google only recently stopped generating. ;)

Yep, agreed. While my "e-waste" epithet was deliberately inflammatory, I really do have a problem with what they and others were doing before. Thankfully, with newer Pixels (and Galaxies, iirc), that's getting better on the Android side.

> I'm not sure why you consider the current five-years-of-updates policy to not be creating an unacceptable amount of e-waste. I have (and still use) nearly-twenty-year-old laptops with the latest Linux kernel and desktop environment software (& etc) versions available.

You're getting sidetracked from my original point (that Unihertz's practically nonexistent support disqualifies it for me), but I would certainly like to have higher standards! Core smartphone hardware has matured to the point where I would like to see 10+ year lifetimes.

However, you're making a false equivalence here; a smartphone is at the mercy of the vendor to provide updates, while a laptop (thanks to commoditized hardware and a lot of work in the Linux kernel) has a more stable base to work from. Again, if we could reach that place for smartphones, I would be into it. But until we're at the point where you can viably buy a 10+ year-old phone and install a supported operating system (where "supported" includes critical firmware updates), this is a bad comparison.

▲

simoncion 11 hours ago | parent [-]

> ...my original point [was] ... that Unihertz's practically nonexistent support disqualifies it for me...

You are aware that a lot of Android's security-relevant stuff is provided in one or more "apps" [0] that get regularly updated? IIRC, way back in the day Google used to ship all of the system software in one immutable blob that relied on OTA updates. However, Google found that telcos would often take way too long to approve handset updates... so Google split most of the security-relevant code out into something whose update system they fully controlled.

1) Do you know how much security-relevant stuff is contained in the base OS vs those "apps"?

2) Were you aware that Android 14 is still a supported version of Android?

3) Were you aware that Android 13 is also still supported?

4) Did you know that those split out "apps" that I was talking about support all the way back to Android 6?

> However, you're making a false equivalence here...

Nope. You're thinking much too narrowly.

> ...a smartphone is at the mercy of the vendor to provide updates, while a laptop (thanks to commoditized hardware and a lot of work in the Linux kernel) has a more stable base to work from.

You can select laptops that have components that don't work with Linux, or only work with particular kernel versions. That "lot" of work in the Linux kernel that you refer to? A fair chunk of it is "just" working with the various device manufacturers to open source and mainline their drivers.

If Google gave a shit about e-waste, they would have at minimum gotten the relevant phone manufacturers to give Google a source code license to the drivers & etc for the relevant phones and permission to adapt that software to newer kernels and ship compiled binaries in AOSP and Google Android.

But, they didn't do that. So, they clearly don't care.

> Core smartphone hardware has matured to the point where I would like to see 10+ year lifetimes.

We could have seen 10+ year software-support-lifetimes from the phones that shipped with the first commercially-released version of Android. Go take a gander at the huge array of weird-ass one-off device drivers in Linux mainline. "Phone hardware was too immature for it to be adapted to later kernel versions" is a bogus statement.

[0] ...whose name I can no longer remember...

	▲	jcgl 11 hours ago \| parent [-]
		> You are aware that a lot of Android's security-relevant stuff is provided in one or more "apps" [0] that get regularly updated. Yes, I am aware. > 1) Do you know how much security-relevant stuff is contained in the base OS vs those "apps"? No, I'm not very knowledgeable about where the lines get drawn, especially for non-Play-related components. It is a relevant point to make though, and is definitely crucial to this topic. However, from what I can infer (e.g. from blogs and mastodon threads by the GrapheneOS folks), there is plenty of security-relevant OS-level stuff that needs patching over the lifecycle of a device. And firmware-level stuff is almost equally as important. Both these OS-level and firmware-level things are out of scope for these apps that Google pushes. > 2) Were you aware that Android 14 is still a supported version of Android? > 3) Were you aware that Android 13 is also still supported? > 4) Did you know that those split out "apps" that I was talking about support all the way back to Android 6? Yes. I couldn't have told you that it was Android 6 off the top of my head, but that timeline sounds about right. > You can select laptops that have components that don't work with Linux, or only work with particular kernel versions. That "lot" of work in the Linux kernel that you refer to? A fair chunk of it is "just" working with the various device manufacturers to open source and mainline their drivers. That is a good chunk of what I'm referring to, yes. Also in-scope is working with manufactures (of both the device and its components) to provide firmware updates e.g. via fwupd. Afaiu, the baseband for mobile handsets is especially important because it's a highly-privileged component that is > If Google gave a shit about e-waste, they would have at minimum gotten the relevant phone manufacturers to give Google a source code license to the drivers & etc for the relevant phones and permission to adapt that software to newer kernels and ship compiled binaries in AOSP and Google Android. > But, they didn't do that. So, they clearly don't care. I more or less agree with you. But my point isn't that Google cares about e-waste. Rather, my point is that devices with longer lifecycles (e.g. Pixels) are superior to devices with short lifecycles (e.g. Unihertz devices). Which is a pity, because I love so much about the Unihertz design. Almost perfect for me. > We could have seen 10+ year software-support-lifetimes from the phones that shipped with the first commercially-released version of Android. Go take a gander at the huge array of weird-ass one-off device drivers in Linux mainline. "Phone hardware was too immature for it to be adapted to later kernel versions" is a bogus statement. I think you've picked out some very specific parts of my response and fixated on those. What I'm saying is that you cannot, in fact, pick up a 10 year-old handset and use it with up-to-date software and firmware[0]. My requirement/desire (which others may not share) is that I should be able to buy a new handset and use it for a bare minimum of 5+ years. As far as I can see, Unihertz's devices do not meet even that pitifully low bar. [0] Tbh, firmware update support varies greatly for laptop and desktop hardware too. I'm no expert, but seems like lots of room for improvement there.