proprietary Google-only format

Keyhole Markup Language

KML became an international standard of the Open Geospatial Consortium in 2008.

(…)

The KML 2.2 specification was submitted to the Open Geospatial Consortium to assure its status as an open standard for all geobrowsers.

If you don’t sign into a Google account, you will never arm this mechanism at all.

I know people say that you don’t NEED an SD card if you buy the most expensive version and rely heavily on cloud services but it’s definitely an intentionally worse customer experience.

Honestly, this depends entirely on the user. My previous phone had 64 GB internal storage and an SD card slot, but I never felt any reason to use it - all I need is enough storage to hold the photos I take until I get home and copy them to a hard disk (which then periodically gets backed up to another hard disk stored at a relative’s house). Then I can delete most photos and videos and keep only a few that I think I might want to share.

I’m not saying this is a workflow that everyone would find acceptable, just showing that different people can have vastly different needs. I personally definitely don’t need an SD card if I have 20 GB+ available for my photos, and that doesn’t seem to be a problem with 128 GB being the baseline for current Pixels.

Of course that doesn’t mean I’m going to stop ragging on Google for taking away features with obvious intention of creating problems for a portion of the userbase and selling the solution. There’s no reason Pixels can’t have an SD card slot at their current price.

By taking away the MicroSD slot to force users towards expensive cloud storage?

No no no, that’s what the crappy modem is for

Vista’s problem was just the terrible third party drivers and the fact that it was preinstalled on machines it had no business running on. 7 didn’t improve much on it (except fixing the UAC prompt so that it no longer made you feel like you’re using Linux with misconfigured sudo timeout), but it had the benefit of already having working drivers from Vista and proper hardware capable of running Vista/7.

Zig didn’t come to my mind when I was writing my comment and I agree that it’s probably a decent option (the only issue I can think of is its somewhat small community, but that’s not a technical issue with the language).

My argument against Go and Java is garbage collection - even if Java’s infamous GC pause can apparently be worked around with a specialized JVM, I’m pretty sure it still comes at the cost of higher memory usage and wasted CPU cycles compared to some kind of reference counting or Rust’s ownership mechanism (not sure about the proper term for that). And higher memory usage is definitely not something I want to see in my browser, they’re hungry enough as is.

Why not just say Rust? There isn’t really anything else that would provide good enough performance for a browser engine with modern heavy webpages while also fixing some major pain point of C/C++

If it doesn’t come at the expense of battery wear, then sure, lower charge time is just better. But that would make phone batteries the only batteries that don’t get excessively stressed when fast charging. Yeah, phone manufacturers generally claim that fast charging is perfectly fine for the battery, but I’m not sure I believe them too much when battery degradation is one of the main reasons people buy new phones.

I have no clue how other manufacturers do it (so for all I know they could all be doing it right and actually use slow charging), but Google has a terrible implementation of battery conservation - Pixels just fast charge to 80%, then wait until some specific time before the alarm, then fast charge the rest. Compare that to a crappy Lenovo IdeaPad laptop I have that has a battery conservation feature that sets a charge limit AND a power limit (60% with 25W charging), because it wouldn’t make sense to limit the charge and still use full 65W for charging.

It doesn’t slow charge, at least not on Pixel 7a. Well, you could argue whether 20W is slow charging, but it’s all this phone can do.

It just charges normally to 80%, stops, and then resumes charging about an hour or two before the alarm. And last time I used it, it had a cool bug where if it fails to reach 80% by the point in time when it’s supposed to resume charging, it will just stop charging no matter what the current charge level is. Since that experience, I just turned this feature off and charge it in whenever it starts running low.

Cheap Bluetooth might have connection hitches

Fair enough, but I’ve only ever seen this happen with cheap wireless cards / chipsets that do both Bluetooth and WiFi and don’t properly avoid interference between these two (for example, I can get perfectly functioning Bluetooth audio out of my laptop with shitty Realtek wireless card if I completely disable WiFi (not just disconnect)). I think this is less of an issue for dedicated Bluetooth devices.

Bluetooth doesn’t work with airplane mode although I think most airplanes these days aren’t actually affected or we’d have planes dropping out if the sky daily.

Yeah, that’s true. As for the second part, AFAIK there was never an issue with 2.4 GHz radios (which is the frequency band Bluetooth uses) interfering with planes, it was more of a liability / laws thing - the plane manufacturer never explicitly said that these radios are safe (so the airline just banned them to be safe) and/or laws didn’t allow non-certified radios to operate on planes.

Also, does Bluetooth get saturated the way WiFi does?

Eventually yes, but it’s much more resilient than WiFi - 2.4 GHz WiFi only has three non-overlapping channels to work with (and there’s a whole thing with the in-between channels being even worse for everyone involved than everyone just using the same correct three channels that I won’t get into), while Bluetooth slices the same spectrum into 79 fully usable channels. It also uses much lower transmission power, so signal travels a shorter distance. And unlike WiFi, it can dynamically migrate from channel to channel (in fact, it does this even without any interference). 100 people actually seeing each other’s devices might be a problem, but I don’t think that’s a realistic scenario - Bluetooth will use the lowest transmit power at which it can get a reliable link, so if everyone’s devices are only transmitting over a meter or so, there shouldn’t be any noticeable interference on the other side of the plane.

I don’t really see the big problem here? Like sure, it’s silly that it’s cheaper to make wireless headphones than wired ones (I assume - the manufacturers are clearly not too bothered by trademarks and stuff if they put the Lightning logo on it so they wouldn’t avoid wired solution just due to licensing fees), but what business does Apple have in cracking down on this? Other than the obvious issues with trademarks, but those would be present even if it were true wired earphones. It’s just a knockoff manufacturer.

Cheapest possible wired earphones won’t sound much better than the cheapest possible wireless ones, so sound quality probably isn’t a factor. And on the plus side, you don’t have multiple batteries to worry about, or you could do something funny, like plugging the earphones into a powerbank in your pocket and have a freak “hybrid” earphones with multi-day battery (they’re not wireless, but also not tethered to your phone). On the other side, you do waste some power on the wireless link, which is not good for the environment in the long run (the batteries involved will see marginally more wear)

Honestly the biggest issue in my mind is forcing people to turn on Bluetooth, but I don’t think this will change anyone’s habits - people who don’t know what Bluetooth is will definitely just leave it on anyway (it’s the default state), and people technical enough to want to turn it off will recognize that there’s something fishy about these earphones.

GadgetBridge is not really against supporting online-only functions, it just can’t be part of the main app. Weather Providers is what you’re looking for.

Yeah, it’s not practical right now, but in 10 years? Who knows, we might finally have some built-in AI accelerator capable of running big neural networks on consumer CPUs by then (we do have AI accelerators in a large chunk of current CPUs, but they’re not up to the task yet). The system memory should also go up now that memory-hungry AI is inching closer to mainstream use.

Sure, Internet bandwidth will also increase, meaning this compression will be less important, but on the other hand, it’s not like we’ve stopped improving video codecs after h.264 because it was good enough - there are better codecs now even though we have the resources to handle bigger h.264 videos.

The technology doesn’t have to be useful right now - for example, neural networks capable of learning have been studied since the 1940s, even though there would be no way to run them for many decades, and it would take even longer to run them in a useful capacity. But now that we have the technology to do so, they enjoy rapid progress building on top of that original foundation.

The astrophotography mode on Pixels (the only way to get 4 min exposure in the default camera app) works by taking quite a few photos with shorter exposures and then matching them up in post processing.

You even get a short animation at the end where every captured photo gets processed using the rest, so you can see stars moving around during the capture.

Letting you disable or limit internet access to apps would go pretty strongly against Google’s interests - how would they get their ad money if half the users were running most apps offline?

Some vendors provide a way to do this (Xiaomi has an internet access toggle per app, or at least it did in the KitKat era), but it’s never making its way into stock Android until Google integrates AdMob into the system.

Cool, so it’s like two years ago

Oh…

Oh no