>Apple has essentially zero exposure to anything like the "metaverse"
holy revisionism batman. It's literally right in https://www.apple.com/apple-vision-pro/. Half the page is "you can watch movies in 3D", the other half is "you can be next to people". They rewrote the visual appearance of all their OSes to match liquid glass on the Vision Pro. Their goggles display your eyes because they expected you to wear them so long it would make it feel more natural to the plebs around you not wearing them and not joining you enjoying spatial sound. Half their ad copy is about "making it feel like you're working next to people".
Apple went all in onto the whole Metaverse crap. They paid off just about every major tech reviewer, tech influencer and even tech bros with following on Twitter (and here, too) with "early access programs" to the Vision Pro. At least can give them kind of the benefit of the doubt because they somewhat quickly saw that it was a dead end.
For the vast majority of people, using capital letters and saying please doesn't consume energy, it just is. There's a thousand things in your day that consume more energy like a shitty 9AM daily.
no, I truly do not want to read IHeartHitler88's opinion on jews, or donttreadonme09's bright opinions about how the economy would be better if we listened to Ayn Rand. I'll be very happy when they're out of my sight. If I want to have a miserable day, sure, I'll turn it off.
Fact of the matter is, most posts on the internet are already dogshit. Now they're also populated by AI, but the point stands. Most of what you will say online is at best useless.
I know, it hurts. Most of what I say in this website doesn't matter. Even if it did, it's about the same thing as screaming into the void. And it applies to you too.
The vast majority of what we post is vapid, useless bullshit.
If and when the asian community decides to reappropriate "yellow" as a way of self identification, then given a few decades, it will not be seen as racist anymore.
In the mean time, "yellow" is a racist adjective for asians, "black" is not a racist adjective for black people.
> In several Gallup measurements over the next three decades, including the most recent in 2019, the large majority of Black Americans have said the use of Black vs. African American doesn't matter to them.
Not caring is not acceptance. The term is literally racist both and origin. Unfortunately they were denied being called simply Americans due to historical reasons. African American is sadly also a misnomer given that there’s barely any connection to Africa for the people generally referred to as “black”.
Notice how everyone else is called by nationality or origin.
Black is absolutely accepted as an accepted adjective. Especially with the capital-b, Black is used to refer to the unique Black culture and heritage in the United States. Black history is one where people were taken from their nations or places of origin, transported to a foreign land, and put in bondage. As you say in your own comment, many black or African-American people (whichever label you prefer) have little connection to Africa; it wouldn't make sense to them to refer to them by nationality or origin, when Black culture is its own thing.
Don't get it twisted: I agree that the history of African-Americans in the US is one marred by slavery, segregation, racism, and the constant struggle to attain and retain equality. But out of that came something unique that many black people celebrate to this day.
>You can pretty much replace "docker build" with "go build".
I'll tell that to my CI runner, how easy is it for Go to download the Android SDK and to run Gradle? Can I also `go sonarqube` and `go run-my-pullrequest-verifications` ? Or are you also going to tell me that I can replace that with a shitty set of github actions ?
I'll also tell Microsoft they should update the C# definition to mark it down as a scripting language. And to actually give up on the whole language, why would they do anything when they could tell every developer to write if err != nil instead
Just because you have an extremely narrow view of the field doesn't mean it's the only thing that matters.
The only "push" towards Metal compatibility there's been has been complaints on github issues. Not only has none of the work been done, absolutely nobody in their right mind wants to work on Metal compatibility. Replacing proprietary with proprietary is absolutely nobody's weekend project. or paid project.
Assuming the rate of progress on AI stays the same:
1/ No, you don't get Opus 4.6 level on devices with 12Gb of RAM, 7B quantised models just don't get that good. Still quite good mind you, and I believe that the biggest advance to come from mobile AI would be apps providing tools and the device providing a discovery service (see Android's AppFunctions, if it was ever documented well): output quality doesn't matter on device, really efficient and good tool calling is a game changer.
2/ Opus 4.6 is now Opus 4.6+5years and has new capabilities that make people want to keep sending everything to someone else's cloud server instead of burning their battery life
I'll eat my left nut if Tim "I'd rather die than give good amounts of RAM" Cook bumps the top end iPhone's RAM any higher than 16GB by 2035, especially with the current shortages. They already use relatively cheap LPDDR5X-9600 RAM in there, and are being slowly bumped off order lists on high end fabs to make room for AI hardware. Notwithstanding the fact that there's no hardware improvement in the upcoming years that either makes RAM ultra fast, or with higher capacities easily.
A claim like that is at best naive, and in any case ridiculous
Depending on the level of security you ask for Play Integrity, it can be:
* is this device rooted, is it an unsigned build ?
* Device is signed, but is it part of the blessed signing keys ? is play services untampered with ?
* Additional checks over the lifetime of the device.
You could fully trust the results of Play Integrity on device, but you can also send the returned token to your server, and your server then contacts play integrity to validate that token. So unless you know how to spoof those encrypted tokens, you won't go very far.
So basically an alternative OS can offer a service like Play Integrity and the only problem is that those banks hard-code a dependence on Google's Play Integrity and Google has a monopoly for that service?
This is something that could be addressed at least in the EU by mandating banks to allow alternative services or not use this service at all.
Yep. You can even run your own play integrity-like backend.
>This is something that could be addressed at least in the EU by mandating banks to allow alternative services or not use this service at all.
The EU mandates banks to be interoperable, and to guarantee the security of users. You can solve that issue by going through an alternative app that doesn't use play integrity and is PSD2 compliant so other banks let you call their APIs. It usually requires you to be a bank, and as a bank, you're really risk averse. So you use play integrity.
>Even worse, it slowing us down from leaving Android entirely.
There are zero OSes that are 1/ open source 2/ appropriate for phones 3/ with good hardware support. There's absolutely nothing. Running Ubuntu Touch isn't a viable option. Neither is postmarket, librem, tizen, they're all terrible. Security wise, for something as critically important in our lives as a smartphone, I am also not trusting any new pet project that won't be stable for 10 years.
Sure, you might be a poweruser that doesn't care about your phone burning its battery in your pocket after 1 hour because you know how to SSH on it from your watch and put it in sleep, but that's not a viable option. Leaving Android is suicide. A large part of its critical underpinnings are already into the kernel anyways, just disabled. (although a distro running binder could be a fun project). APIs are reverse engineerable generally speaking, except for the server part of play services. But then, if your issue is "my bank won't let me access their app without play services attesting me", I have great news, you won't even have an app for it on your new OS anyways, so it will not work by default. There's already not enough people working on GrapheneOS _or_ on mainstream linux OSes, what makes you think the sitation won't be ten times worse for your custom made mobile OS ?
>We should focus our efforts on truly open platforms.
Android is one, and that can never be taken away. Google pulls the plug ? cool, you're stuck on Android 17, which is centuries of work ahead of literally anything else in the open source community. Hell, for all the shit that Google is doing, they're still constrained by having to work with other vendors: the system privileged notification receiver is swappable at build time, the recent app signing/verification system also is, because Samsung wouldn't let them control it all.
I do agree, mobile OSS OSes are rough. My point is that we should help them instead of helping Google's toxic relationship. It happened with Chrome/Blink, and everyone already forgot that lesson.
About hard-forking Android, no one was brave enough (pun intended) to do that for Chrome, considering the insane complexity and engineering costs (>$1B/y). (Only Apple was able to affort it with Webkit/Safari, but they are in the ad business too.)
I kinda dont see how both of you cant be right. We need a mobile OS that google isnt involved in. Why not use pure open source android to do it. It can only be cheaper than making it from scratch, since it has alot of work already done on it
AOSP has so few of the features a full phone needs today. Google has moved too much of the Phone OS into "Google Play Services". This is already the Extend phase of the classic "embrace, extend, extinguish". Given how the next most popular AOSP implementation, Amazon's Kindle Fire isn't even trying to compete in the phone space and involves an equally large company throwing nearly as much money into an "also ran" alternative to "Google Play Services", it seems easy enough to argue Android may even already be in the extinguish phase.
(ETA: See also Microsoft's many years of trying to build its own "Google Play Services" competitor. Eventually breaking and making use of Amazon's. Then giving up entirely again on a de-Googled alternative to running Android apps.)
There's not actually much in Play Services. The biggest losses are fused location providers and notification services which you would consider core to the OS. Maps are a loss, but these are very clearly Google branded.
Huawei provides HMS for example, a somewhat close feature wise set of APIs for their phones that are still on Android. They can even shim play services API, the same way microg does. If anything, what would be needed would be a common abstraction library with different backends to not depend directly on play services
The reason amazon and Microsoft gave up is because they had no commitment, and that operating these services is just pure loss.
Yes, the default apps in AOSP suck. Making a proper dialer is a two day job, so is a contacts app. Android's core APIs are good enough, and privileged permissions are only privileged by the manufacturer, and its IPC mechanisms are very well documented. Noone does it because it sucks, it's a thankless job and nobody's going to install your dialer. The very fact that each manufacturer has their own custom software is demonstration of how easy it is.
Windows phone died because of its lack of apps. Same thing with several other mobile OS's. Ubuntu has a really great OS and UI, but no apps for just basic things renders it useless to even the most basic of users like myself. I don't have games, no banking apps, a few email and Microsoft apps and yet I still couldn't find a way to make it work.
One of the other technical limitations is network. Ubuntu has yet to solve the VoLTE (Voice over LTE) riddle. This is a major sticking point for US consumers.
Yeah, it somewhat doesn't matter how "easy" it is to use alternatives to Google Play Services, because Play Services is still a moat around a huge collection of existing apps today for Android that Play Services is "good enough" for and/or the only option "worth supporting".
Building and maintainance cost are not linear, especially when you inherit legacy code. The AOSP codebase isn't great, is 4x bigger than the Linux Kernel, and full of "Ship now, patch later" mess.
But I agree that it is a significant endeavor. But the OSS community succeeded in similar projects before, and the current state of the Linux desktop makes me hopeful.
> Building and maintainance cost are not linear, especially when you inherit legacy code. The AOSP codebase isn't great, is 4x bigger than the Linux Kernel, and full of "Ship now, patch later" mess.
And yet the GrapheneOS devs seem to be managing just fine.
> But I agree that it is a significant endeavor.
Yes, in fact it is orders of magnitude more significant an endeavor that just building upon and improving the existing AOSP stack.
I still use Konqueror occasionally. It no longer uses KHTML (it uses blink now iirc through Qt webengine (which just got webextension support, someone's working on adding them to falkon so I'm sure Konqueror isn't too far behind)) but it works surprisingly well. It's still a great file manager if any of you remember how good it was
This is the sad part. I've resisted that slippery slope as much as possible. In part because of ideological reasons, and in part for usability reasons. I have large hands and poor eyesight - using a phone for non-trivial tasks is tedious. I think the only thing I encounter from time to time that requires a smartphone is paying for parking. Everything else I do from a desktop, or don't do at all (doom-scrolling etc.)
I wish society would resist the smartphonification of everything for no reason. A lot of it is marketing- and surveillance-driven.
> you're stuck on Android 17, which is centuries of work ahead of literally anything else in the open source community
Honestly if this happens, look to China to maintain Android going forward and add new parallel implementations of Android 18+.
Right now almost all of China runs on various forks of AOSP; every phone manufacturer in China has their own AOSP fork (Xiaomi: MIUI/HyperOS, Huawei, HarmonyOS, TCL: TCLUI, etc.). Apps in China are distributed both as .apk files as well as through a bunch of different domestic app stores. They are compatible with all of these Android forks. These apps are also designed to be compatible with Google Android for Chinese folks overseas.
TBH China is much, much closer to "decentralized" development of Android than the Google-centric US ecosystem.
Granted most of those AOSP forks in China also often have spyware of sorts, but at least there are multiple active forks and a healthy app ecosystem working on all the forks.
> Google pulls the plug ? cool, you're stuck on Android 17
And you're stuck on the current hardware generation. Pretty much the only reason why Android sucks less than other mobile OSes is that hardware vendors have a pressing reason to make it work. The further the Google Android kernel diverges from its last-open version, the harder it will become to backport drivers -- and that's assuming that hardware vendors even bother to comply with the GPL when Google decides not to.
It can, and has in the past, diverged from the baseline Linux kernel, but not from “the last open Android kernel” as it must remain open source per GPL.
The whole notion of smartphones is designed for intrusive user surveillance, from the regulatory side to the hardware itself to the software designed for it.
We need tablet computers that don't have hostile hardware like cameras and mics and sensor suites that can be remotely controlled, under proprietary firmware, completely out of owner control.
We need radio hardware and software that is entirely under owner control, with protocols and standards based connection controls; the notion that spectrum and cellular make network connectivity magically necessary to put under the draconian gatekeeping and surveillance of cellular carriers is flaming dumpster garbage.
The carriers are a primary threat vector. The hardware is a primary threat vector. The software is a primary threat vector.
There is absolutely no way to fix the current cellular phone security status quo, every single facet is designed to be leaky and allow "good guys" backdoored access "for the right reasons" and so on, whether it's "user experience telemetry" or "we have a warrant".
Running bog standard linux with sensible security defaults and a good softphone over an internet connection would be fine. There's nothing magical about phones or UX or wtfever this month's marketing rationalization is.
Handheld tablet computers with optional hardware, or even modular hardware, are going to be the future. The current paradigm of parasitic cellular carriers, invasive governmental regulatory bodies working on behalf of all sorts of corrupt interests, and complicit hardware manufacturers are 100% all in on milking consumers for every last unearned penny or intercepted PII they can get their grubby hands on.
> you're stuck on Android 17, which is centuries of work ahead of literally anything else in the open source community.
It's far ahead, but at the same time, I think we shouldn't over-emphasise how much. Functionality at the beginning of a project's lifetime is way more important than incremental improvements (or just changes) made later, and thus while much more effort has been invested into Android, new projects primarily need to catch up when it comes to e.g. phone call support and stability, and won't have to redo a lot of the effort of e.g. implementing Material You 3 or whatever.
Which is to say that we're still years out from a viable competitor, but at the same time, there could be one five years from now, which is also not that long.
Material 3 is mostly not part of the AOSP tree (aside from some very, very deep code like shadows) and is just UI libraries. I actually wonder if M3 has View implementations, or if everything has been migrated to Compose.
You're also underestimating the amount of fundamental work that goes in Android. The vast majority is hardware integration. It's not all fancy little bells and whistles. It would have the added benefit of not having to relearn the security mistakes like LIST_ALL_PACKAGES or READ_SMS permissions being open to all, at least.
I'm not saying it won't be a lot of work, and I'm not saying it'll be at feature parity in five years. But I'm saying that we shouldn't assume it'll take as much work/as long as it got Android to get to the current point, to get to the point where it's viable for some use. For example, when a usability baseline for some common usage patterns is achieved, it could be at the point where some external event could push a hardware vendor to start experimenting with specific support.
(I'll also note that there has been a lot of non-"fancy little bells and whistles" work that has been going on in the Linux world, specifically with lots of lessons learned from mobile. Think atomic distros, and sandboxing, for example.)
Fundamentally, not enough. Linux's default security mechanisms are simply too weak for something as potentially hostile as a mobile device. Firejail is a good start, but proper user isolation as Android does is the right solution (each app is a different user, and accessing their data/user data is only done through Providers, or IPC), and anything else is naively trusting and not enough, no matter how many layers of sandboxing and suid-ing you do. Doubly so when all of its apps are written in C++. Can't wait to deal with use-after-free on my mobile device.
In addition, its compatibility with android apps is also chains: why would I bother developing for sailfish (especially since it involves Qt / Qt Creator) when I can just develop an Android app, and say it'll run well enough (unless it needs play integrity, which is the same problem, or somehow falls behind in android/androidx compatibility)
> Linux's default security mechanisms are simply too weak for something as potentially hostile as a mobile device.
Linux has SELinux as a default option which Android makes good use of, some forks more than others, and setup correctly it is better than user isolation. You could also recreate the protection user isolation provides through policy alone.
It is _the_ 2FA device. from SMS, to authenticators, to password managers, etc. It also has access to all of your personal information, your pictures, your contacts, your email. It actively receives notifications and messages from the outside world, from potentially any sender. It's connected through WiFi, GPS, 5G, bluetooth, UWB, every possible connection system imaginable. It can listen to your phone calls, read your text messages, interact on your behalf with pretty much everything in your life, and is a single facial recognition away from automating emptying your bank account. Not to mention the fact that mobile software does tend to want to at least survive a little bit when offline, so plenty of data is stored locally.
It's a key to your life. The perfect target for any attacker.
My Linux laptop is my 2FA device (email), it holds my passwords, and personal data like photos, contacts, email. It receives notifications and messages from outside world from potentially any sender. It connects through Wi-Fi, Bluetooth, Ethernet, 5G (built in WWAN). It even has cameras, microphones and I use it for my online banking and shopping. The only reason why smartphones "need" to be ultra secure is because everyone and their mother have one and the truth is most people can hardly tell a difference between their head and their butt.
Well yes. Security measures aren't for the principled tech saavy scene who is up to date on the latest malware and exploits. That's how Apple rose to power; it put convenience first and told users it'd worry about all the privacy stuff for them.
A bit contradictory, but that's what the people want. They (as a mass) always choose convenience over both freedom and security. So that's why we always converge towards a centralized power, in tech and the larger world.
Because regular users (non-techies) install all kinds of apps on their phones, from all kinds of sources/vendors, but not on their desktop. Most people use only a handful of applications on their desktop (browser, office suite, …) but they have dozens if not hundreds of different apps on their phone.
Tbh, if all of us chipping in to pay for maintenance is the only viable way to stop enshittification, maybe it's something to ponder. I would have scoffed at paying for search a decade ago, but Kagi is more and more attractive by the day. Making a financial incentive to maintain trust seems to be the one obvious way to achieve a "principled OS".
But I guess that's all wishful thinking. Even getting a one time payment to switch to a new OS is difficult.
I don't mind paying for my OS but I just think they're not in a position to be asking for money. Putting a price tag on a product with zero market recognition and no software support sounds like a great way to turn any potential new users away. But then again they need to get money somehow.
holy revisionism batman. It's literally right in https://www.apple.com/apple-vision-pro/. Half the page is "you can watch movies in 3D", the other half is "you can be next to people". They rewrote the visual appearance of all their OSes to match liquid glass on the Vision Pro. Their goggles display your eyes because they expected you to wear them so long it would make it feel more natural to the plebs around you not wearing them and not joining you enjoying spatial sound. Half their ad copy is about "making it feel like you're working next to people".
Apple went all in onto the whole Metaverse crap. They paid off just about every major tech reviewer, tech influencer and even tech bros with following on Twitter (and here, too) with "early access programs" to the Vision Pro. At least can give them kind of the benefit of the doubt because they somewhat quickly saw that it was a dead end.
reply