Another SAAS embedded within Car which cannot be opted out. Is there a way to get FOSS Tesla? IMO the Government must intervene to make this opt-in rather than compulsory?
Will it work without Tesla.com account? Or no internet access at all? I just want to drive the Tesla car without internet without any smart features. Is that possible?
Yes, you can drive the car without a Tesla.com account. You miss out on important features such as software updates, remote monitoring/alerting, and the ability to SuperCharge. However you can charge at home or at other Level 2 chargers. And once the NACS plug becomes more widespread you should be able to DC fast charge at non-SuperCharger locations.
You might be interested in https://en.wikipedia.org/wiki/Open-source_car - otherwise, I mean, if you're not into Teslas, no one is making you buy one.. Not sure what your angle is.
I love linux and FOSS myself, not putting your angle down I just don't see your point exactly.
You can vote with your wallets, and everyone else can too.
This is an API for developers to build opt-in apps on top of. The user (the Tesla owner) has to explicitly grant access to an app for it to do anything.
Nowadays, I see many articles titled "Beyond 12 factor Apps" which proposes even more factors for App prominent among them being one from IBM. What's your opinion on that?
This is a small but real trend. My experience at a company that went deep into expanding beyond/removing some of the 12 Factors is that it breaks portability of containerized software built with those assumptions. There were a few times I needed to install a vendor product or open source project that was built to the 12 factors but spent a month or more just building a shim to make it conform to our particular bend on it. I’m sure there are good reasons to deviate but I wasn’t particularly impressed with our decisions and more importantly why we made them.
Apple -> Moltenvk (Have to blame Apple for not supporting Vulkan). Moltenvk is used by games such as Dota2. If moltenvk doesn't work fine for your game, you must not target Apple Mac devices anyway.(valve dropped mac support for cs2). For non game cases, Moltenvk works just fine.
Apple -> MoltenVK is an emulation layer and doesn't give you as much control as using Metal directly.
Nintendo and Sony prefer their own APIs, NVN and LibGNM, and AIUI Vulkan is a second-class API on those platforms which does not offer as much power, it is widely understood studios use NVN and LibGNM to get access to the real hardware on those platforms.
Windows/AMD/NVidia/Intel -> HW manufacturers tend to prototype and release new features with D3D first and then 'backport' them to Vulkan after a while. DirectX 12 for example had mesh shaders for over 2 years before Vulkan got a vendor neutral extension for them[0]
Android and Linux are the only platform where Vulkan is a first-class citizen.
You could maybe argue Nvidia treats Vulkan as a first-class citizen because they tend to have vendor-specific Vulkan extensions for the latest features available before anyone else. But otherwise, no, Vulkan is not a first-class API anywhere except Linux and Android.
On top of that, OpenGL/Vulkan advocates tend to ignore that extension spaghetti makes them also completely unportable when extensions are only available for specific vendors, and if they are lucky with multiple vendors offering similar extensions, there is an exponential set of code paths only to deal with all of them.
Making them in the end hardly better than multiple backends, when doing serious stuff across multiple GPUs and OSes.
You know that Vulkan targets vast amount of Hardwares which makes Vulkan Extensions a lucrative deal rather than thing you despise, right?
Don't get me wrong. I agree that it's less worrying to know beforehand that all the features will be available in the target environment with features made mandatory rather than extensions. But, it's not like the case of Apple/Sony/Xbox which has software tailored for the device.
Vulkan devices range from Virtual devices(Moltenvk) to Android(Low powered devices) to Desktops(Linux, Windows) to Workstations(Linux). Having ray tracing mandatory in low powered devices like low budget android phones doesn't make any sense, that's why it's made as extension.
But, you can be sure that any modern desktop with modern GPU by any vendor atleast adheres to Vulkan standard and has specified extensions available. That can't be said about experimental extensions though (Like Vulkan Video).
> Making them in the end hardly better than multiple backends, when doing serious stuff across multiple GPUs and OSes.
This "multiple backend" solution is not ideal too. Firstly, it was necessary because not all Vendors supported single Graphics API standard. Secondly, it isn't powerful as main API it gets translated to(DX,Vk,Mt). Thirdly, I don't see how it helps when target environment doesn't have an extension available.
Maybe "Multiple Backend" solutions might make few things easier like removing Verbosity and maybe they are good for Small applications but I don't think they are worthy replacements to Main APIs
A wall of text to argue in favour of extension spaghetti.
How many cross platform applications have you shipped with Khronos APIs?
I did my graduation thesis in 3D particle visualisation and marching cubes implementation, based on a framework ported from NeXT/Objective-C in Windows/C++, using OpenGL.
Contributed to SDL, Ogre3D and jMonkeyEngine.
Also contributed to some BabylonJS stuff in WebGPU.
> I did my graduation thesis in 3D particle visualisation
> Contributed to SDL, Ogre3D and jMonkeyEngine.
> What are you 3D credentials?
Appealing to Authority[1] is a fallacy/bias and a quick way to lose a debate.
Instead of saying you have all these creds and therefore your opinion matters more - explain why what you are arguing against is bad. If you are an actual expert, that will be shown through well formed arguments all on it's own.
Not all experts share your opinion, clearly, which makes this angle unhelpful.
Nah, as my experience in 30 years of industry shows, those that come up with appeal to authority argument, aren't really interested in listening anyway.
If you are that knowledgeable person in this domain, try to refute/discuss my content instead of asking my credentials.
What is the best alternative to Vulkan extensions in your opinion? Remember that Vulkan supports vast number of devices. I think that making featureset mandatory for all devices is not sensible approach here.
> Microsoft Windows -> Supports Vulkan natively first class.
Erm, no? Vulkan is completely implemented in GPU vendor driver DLLs, Microsoft has no part in this. The only first class 3D APIs on Windows are the D3D APIs.
In reality, Vulkan doesn't matter much except on Android and Linux.
I agree that Microsoft has no part in this. But, any computers which run Microsoft Windows has GPUs made by these Manufacturers: Nvidia,AMD,Intel and Qualcomm and all these Manufacturers have good Vulkan Drivers in Windows.
Thus said, even though Microsoft doesn't support Vulkan officially, you can tell that Vulkan has first class support on Microsoft Windows given that all GPU drivers have good first class Vulkan support and all Vulkan Applications run just fine on Windows.
> In reality, Vulkan doesn't matter much except on Android and Linux.
No, it matters. Vulkan is the first modern cross platform Graphics API which can run across Linux,Windows,Android,MacOS,Switch to name a few. No similar API does exist currently which offers high performance along with being portable.
> Why would Apple support something that appeared two years later than Metal?
Because Vulkan is Open Standard? It's similar to how EV car manufacturers other than Tesla are now embracing NACS even though it was born at Tesla. It's also similar to how Apple adopted USB C given Lightning was already a standard before USB C.
You can't blame community or Khoronos either. Khoronos and developers did their best with best effort Vulkan-> Metal translator with Moltenvk and you can now not worry that your Vulkan apps won't run on MacOS(exceptions are heavy games and there are still many Vulkan extensions not implemented thanks to Metal).
And note that it's not you or I who is losing because Apple didn't support Vulkan. It's Apple themselves whose Mac devices have started losing share in Gaming Market. Day by day, Developers are ignoring MacOS as target. If this isn't a warning call to Apple, i don't know what is.
Why didn't Microsoft immediately embrace it? Or Sony? Or...
> You can't blame community or Khoronos either. Khoronos and developers did their best with best effort Vulkan-> Metal translator
Yes. Yes, we can and should blame Khronos. For their mismanagement of OpenGL. For the fact that they woke up and decided they needed a new API a full year after both DirectX and Metal, and managed to release first version a full two years after those two.
> And note that it's not you or I who is losing because Apple didn't support Vulkan. It's Apple themselves whose Mac devices have started losing share in Gaming Market.
Ah yes. They are losing because of not supporting Vulkan.
Let's see:
- iPhone is Metal (before you say that more people are gaming on Android, iOS's mobile gaming revenue dwarfs Android)
- Xbox is DirectX
- Playstation is GNM and GNMX
Apple is losing, should abandon Metal and go all in on Vulkan because.
> Why didn't Microsoft immediately embrace it? Or Sony? Or...
Because they are already established platforms in Gaming Industry? Windows has much of Gaming market share. Xbox and PlayStation are popular Consoles. They probably don't loose anything by supporting Vulkan although supporting Vulkan would be awesome on their part.
> Ah yes. They are losing because of not supporting Vulkan.Xbox is DirectX. Playstation is GNM and GNMX
I was only talking about MacOS.
> before you say that more people are gaming on Android, iOS's mobile gaming revenue dwarfs Android
I didn't talk about iPhone either. I was only talking about MacOS. despite being prominent OS, game title developers often ignore MacOS. Why? Because of Graphics API. No one bothers to target Metal for Games and this is exactly what i am talking about. If MacOS allows Vulkan or DX(ik that it's not possible), i think there could be more influx of games.
If we are talking about Gaming on iPhone, you must know that gaming landscape on mobile phones is vastly different than that of mainstream gaming experience on Consoles/PC. Mobile gaming landscape is mostly filled with non graphics intensive, micro transactions filled, Ad-filled(many times freewares) games. iPhone gets targeted because it has prominent share in Mobile Market but even then, not everything gets ported to it. Not to mention, Android gaming landscape doesn't suck than iphone. Prominent Mobile games which are on iPhone are on Android too and on Android they use Vulkan which proves that Vulkan is not a bad choice.
> Xbox is DirectX. Playstation is GNM and GNMX
Vulkan probably runs on PlayStation (see latest Baldur's Gate 3 patch notes; grep for PS5 Vulkan) but I am not so sure. Like i said earlier, these platforms are already household names when it comes to gaming.
My point was not to tell you that Vulkan is the "supreme" Graphics APIs out there. But my point was to tell you that Vulkan is the only one of "supreme" APIs which is most cross platform, modern, supported by gaming and graphics forerunners(valve, rockstar, nintendo) and there are no viable alternative to Vulkan right now.
> Yes, we can and should blame Khronos. For their mismanagement of OpenGL
What should they have done? At the point, we needed modern Graphics API. Mantle by AMD was forerunner and AMD was willing to co-operate. Nvidia too joined that bandwagon. Thus, Vulkan was born out of Mantle.
Should they have copied Metal? Since it was closed API from Apple, it wasn't possible. Should they have copied Microsoft's DX12? If Microsoft actually loved Open Source and Standards and gifted Khronos DX12, it would have been possible but they didn't do it. I think Khronos did sensible thing at that time.
- you're willingly ignoring other platforms that Apple has and that are more important to Apple than Mac
- you're willingly ignoring the fact that Apple never care d about gaming on Macs
- you're pretending that gaming success is predicated on supporting Vulkan even though huge gaming platforms never supported Vulkan, and are successful
But sure. Apple absolutely must support Vulkan on Macs because they are losing out or something.
> But my point was to tell you that Vulkan is the only one of "supreme" APIs which is most cross platform, modern, supported by gaming and graphics forerunners(valve, rockstar, nintendo)
1. As if Apple (or anyone really, see Microsoft and Sony) cared about it being crossplatform and modern
2. There are thousands of game developers, and a very small number of those "forerunners" care about Vulkan.
> What should [Khronos] have done?
Not sit on their asses until it was two late. Both DirectX 12 and Metal were released in 2014. It means that Apple and Microsoft had been working on these new APIs since at least 2012.
Khronos woke up and decided to create a new API in 2015.
It's amazing you're blaming Apple and Microsoft for not doing something for Khronos out of the goodness of their hearts when the "amazing open innovative forerunners" like NVidia, AMD, Valve, Epic etc. are their members and literally did nothing until, well, it was too late.
You know that Games/Applications can still be developed with Vulkan API targetting win32 and they can be run on Proton/wine in Linux which runs it without the DXVK (dx11->vk)/VKD3D (dx12->vk) translation layer, right? Baldur's Gate 3, Red Dead Redemption 2 are some of popular games which use Vulkan exclusively running on Proton.
Ok, now enable us to let create Android Applications entirely in Rust (including the GUI). Let's get rid of Kotlin/Java monopoly in Android App development. Shall we?
Tell me you've never done any Android development, without telling me...
This is such a low-effort "take" without any effort to justify _why_ you'd want something like this. There's a high amount of impedance mismatch trying to write GUIs in a non-GC language like Rust which _has_ to run on what's essentially a Java VM (ART).
At least with a language like Go, it somewhat makes sense, and has been attempted: https://gioui.org/
All this Java/Kotlin bashing is getting really old, especially for a forum like this one.
I didn't bash Java/Kotlin. In fact, I have written few android apps in Kotlin, Java and I also have fiddled with Jetpack compose, JNI and NDK (I have also played with mpv's Opengl/Vulkan's rendering on Android if that matters to you). I don't want to share the projects of mine because i don't want to reveal my identity.
I know that tailscale's android application is written in it but i don't think gioui is great for android apps.
> Tell me you've never done any Android development, without telling me...All this Java/Kotlin bashing is getting really old, especially for a forum like this one.
Ok, this one hurts. Why are you attacking me instead of defending your stance. All are allowed to have opinions and I am allowed to have one(It's sad to explain this to someone on forum like this one). I dream of Linux-desktop kinda situation where you can program in any language you want, where you are not hindered by any platform/framework, where you have complete freedom and where you don't want to be bothered/(vendor locked-in) by Bigcorps(looking at you Google services framework).
> write GUIs in a non-GC language like Rust which _has_ to run on what's essentially a Java VM (ART).
Haha, non-GC languages power the GUIs on Android fyi. Jetpack compose is powered by Skia. Chromium is powered by Skia. Skia is C++.
Please do your own research before commenting low-effort replies.
> Haha, non-GC languages power the GUIs on Android fyi. Jetpack compose is powered by Skia. Chromium is powered by Skia. Skia is C++.
Skia is not something you use to write apps: it's a graphics engine, essentially something you use to draw polygons on the screen.
> Why are you attacking me instead of defending your stance. All are allowed to have opinions and I am allowed to have one
I apologize if any of this sounded like an attack. I was trying to be funny with that meme-like sentence formation, but I don't profess to disparage anyone's skills or opinions.
> I dream of Linux-desktop kinda situation where you can program in any language you want, where you are not hindered by any platform/framework, where you have complete freedom
Linux desktop is certainly not the dream world you describe. Practically, you _have_ to pick a toolkit: one of GTK / KDE / Qt / electron / etc. Maybe it helps to think of Android's toolkit (Views or Compose) as one of those.
> Skia is not something you use to write apps: it's a graphics engine, essentially something you use to draw polygons on the screen.
So, AOSP team can obviously create Rust framework ontop of Skia(or tinyskia,femtovg,etc.), make Android APIs available in Rust, Create proper widget framework and let us create Android Applications written entirely in Rust.
> Linux desktop is certainly not the dream world you describe. Practically, you _have_ to pick a toolkit: one of GTK / KDE / Qt / electron / etc. Maybe it helps to think of Android's toolkit (Views or Compose) as one of those.
I know what I am talking about. This is exactly the freedom that I was talking about. I am able to choose any framework/toolkit I want. If i don't want any framework, that's fine too. You don't have that freedom in Android. Everything has to be routed via Java ecosystem that AOSP constructed.
Calm down with that "Haha", all those native libraries powering Android are behind JNI walls, and even NDK code is obliged to make use of JNI to call into them.
Please do your own research on how AOSP is actually implemented.
> behind JNI walls, and even NDK code is obliged to make use of JNI to call into them.
What i originally told was "enable us to let create Android Applications entirely in Rust (including the GUI)" . Surely Google and AOSP projects can remove the restrictions that you mentioned and provide us alternative to Kotlin/Java ecosystem which is what i really want and hope them to do. Smartphones powered by Android are capable computers and freedom for App development is appreciated.
Please don't mention once again that "X is not implemented in AOSP. Y is required to make use of JNI calls into them". You know that this is superficial barrier and can be overcome/corrected if they wanted to.
There's a reason Chrome is mostly written in C++. Android's JVM system is a collection of Java wrappers around C++ libraries. There's some overhead in that translation layer, and it's unfortunate that you can't skip it. Even Google's own Flutter uses a C++ engine to run Dart applications.
Kotlin (and Java) is fast enough for many applications, but even with the recent advancements in ART, does have overhead compared to pure native code. I can't think of a reason why the API interaction overhead would pose a problem, but if Google themselves can find use cases for almost JVM-less apps, I'm sure there are reasons to give a Rust version a try.
> Android's JVM system is a collection of Java wrappers around C++ libraries.
This isn't even remotely true and it's obvious if you'd ever looked closely at Android. This take is as bizarre as saying that whole web/JS/React ecosystem is "just" wrappers on top of Skia.
> There's a reason Chrome is mostly written in C++.
And for that same reason, you don't see many apps do the same thing. Any time Chrome needs to request a permission (access files, location, etc), it _has_ to use the system-provided Java APIs.
> Even Google's own Flutter uses a C++ engine to run Dart applications.
As do most games, so you can essentially think of Flutter as a game engine that renders apps.
> Android's JVM system is a collection of Java wrappers around C++ libraries.
As others have mentioned, this is very much not the case.
At the same time, GUIs really don’t work nicely/as idiomatically without a GC. Most Rust GUIs do immediate mode only, which is a much more easier problem, and you won’t have to “argue” with the borrow checker constantly. But it would drain the battery of a phone in an hour (it would be the equivalent of running a proper 3D game as your notes app or whatever).
That doesn't change anything. Security was simply never what chrome (or webkit to be fair) was built around compared to speed of the insanely inefficient browser stack.
What does a GC have anything to do with it? You can reference count all the pointers if you want, you can expose JVM pointers in Rust where Rust doesn't manage the heap memory. There are plenty of easy solutions to work with the JVM
If you're willing to work with the JVM (i.e. through JNI), there's really nothing stopping you.
You can 100% make entire apps using nothing but C, C++, or whatever, as long as you're willing to interface with the JVM that's created for you to access Android APIs.
But the Android API is a JVM API. There's no getting around that. At this point, it's another OS (i.e. not Android) if it doesn't have Java in it.
> There's a high amount of impedance mismatch trying to write GUIs in a non-GC language like Rust
Sorry, what does the idea of a user interface have to do with garbage collection? They seem entirely unrelated at first blush, and it's not difficult to find GUI code written in rust.
You can technically create an Android app without any Java code. There are native APIs for graphics and input. However, as these are intended for games, you get a window into which you can draw... something. With OpenGL, for example. You don't get access to Android's regular UI framework. You will also have to go through the Java layer to do many things you might want to do — like requesting permissions or launching other apps' activities.
That's not really what's going on. Those "native" APIs you mention in most cases just call back to Java APIs under the hood. For better or worse, most of what Android is is written in Java. There's no hidden "C++" layer of Android to access.
In theory it is possible to write raw Binder calls to various Android services, skipping JNI in many places. However, it is basically rewriting the entire OS API and structure from scratch.
You can generate binder wrappers from aidl, that would work. This is fairly common when doing platform work (for those like me who work on the operating system rather than on apps).
However, this would be a terrible idea because usually the android api is stable at the Java wrappers (I.e. ActivityManager), not at the aidl level, which would make this very fragile for app development across a multitude of devices and platform versions.
You can call into any Android Java API from native code using JNI. It's not exactly convenient, but you are not limited to the C APIs exposed by the NDK.
Many Android APIs expect you to extend classes and implement interfaces for things like callbacks. You can't do that with JNI alone, you will have to have a .dex of your own anyway.
Does anyone have any experience creating production apps with Tauri? Seems like a sane alternative to Electron, especially if they can target all major platforms and keep the promise of smaller footprints.
Not quite production, but I was on a paid contract on a PoC. I would say back at 1.0, mobile was pretty painful and signing of any binary dependencies was up to you. It looks like they addressed signing in 1.5 and I haven't picked it back up to check out the mobile experience.
I don't think it's a good idea, mainly because android is multiplatform and rust, by it's nature, is only available for what it's built for. Unless you are giving google your rust code to compile, your app will be limited on it's reach.
All that said.
Rust doesn't have a GC so it'd (likely) have a lower memory consumption and could possibly be lighter on the CPU.
Native compilation helps mainly with startup time and memory consumption. It's not exactly great for runtime performance as it takes away some key optimizations.
Another benefit of rust assuming you are distributing binaries is you'll be able to use the latest version of Rust rather than being pinned to older versions of the SDK with partial support based on the whims of google.
> Unless you are giving google your rust code to compile, your app will be limited on it's reach.
Android has supported native code in apps for a long time via the Android NDK, mainly to enable game development. The Android team seems to hate the NDK, but the alternative is to have no games on the platform, so they can't simply kill it.
> ...[native] ... It's not exactly great for runtime performance as it takes away some key optimizations.
In theory a JIT might produce better runtime performance than AOT compiled code, but in practice that usually turns out as wishful thinking.
Not really, because not only it uses PGO, which most people using AOT languages never bother to learn, it only AOT compiles the code paths that JIT validated as being used, instead of the whole application.
JIT + AOT with PGO data shared across all Android devices on the planet, gets the best of both worlds.
VM warmup isn't consistently a thing, in fact for over a decade there has been plenty of observation of the reverse, that runtime optimization often slows performance. Systems languages (c/c++/rust) consistently outperform warmed up managed languages. And that is ok, it doesn't mean we shouldn't have managed languages, but they are slower.
>mainly because android is multiplatform and rust, by it's nature, is only available for what it's built for
Android is one platform: android. I thought rust worked across multiple operating systems.
>Rust doesn't have a GC so it'd (likely) have a lower memory consumption and could possibly be lighter on the CPU.
So what? I have never used G.C.
>Native compilation helps mainly with startup time and memory consumption. It's not exactly great for runtime performance as it takes away some key optimizations.
That is fair I suppose
I think the main benefit of rust/c++/ndk on android is that I can just port desktop programs and I don't have to learn android's java/kotlin and sdk.
> Android is one platform: android. I thought rust worked across multiple operating systems.
Operating systems, not architectures. You'd have to cross-compile your application 4 times if you want to support all arms and x86s.
> I think the main benefit of rust/c++/ndk on android is that I can just port desktop programs and I don't have to learn android's java/kotlin and sdk.
It's not "just" port desktop programs. Android doesn't even use glibc.
Godot and Unreal aren't really competing in a lot of areas. No one's going to make movies using Godot any time soon, for example. Unreal's rendering is just so far ahead of the pack.
Nobody's forgetting about it. Godot is trying to be a competitor, but realistically they don't have nearly the funding or total manpower that Unity or Unreal have, at least at the moment, but at the same time, they're still making good progress on being viable for some things (they're already very viable for most 2D games, and 3D games with simple graphics).
Unreal for VFX is hard to scale, but have some interesting iterative advantages. If Godot is the alternative, VFX will likely fall back to path tracing.
Except that's always said when something bad for Bitcoin happens. The analogue here would be to say "this is actallg good for Unreal", as it's definitely good for Godot that a competitor started charging.
I can see a little resemblance in bringing up something that didn't need to come up, but a competitor raising prices is pretty relevant.
And that meme didn't really take off until it was about all kind of bad events, arguing that actually they were good things, and that's clearly not what's happening here.
I'm not agreeing or disagreeing but you've not engaged with the "intended usecases" part of the comment you're replying to. You both disagree on what "intended usecases" really are in this context so engage with that rather than replying with a bunch of videos.
Give me 380USD phone which lasts for next 5-8 years, feels premium, is repairable, camera is decent, replaceable battery, OS is just Vanilla Android with atleast 5 years(more years of Software updates would be welcome) of Software Updates and when you can't provide it, make it hackable enough to install Custom ROMs.
No company will ever make a 5-8 year phone at that price. That's $47-76 a year.
People pay that amount or more for apps that help manage their fantasy football team...
Comparitively that would be an insane bargain for a phone and it's absurd for that to be your requirement.
I do wonder what the right price point would be for a subscription model. At the moment the average replacement time is every 2 years which would be the equivalent of $30 a month basic and $40 for pro.
Could they afford $30 a month sub but you got the yearly upgrades rather than every 2 years?
If the price of the parts is quite low compared to the R&D that could be feasible.
The current iPhone SE starts at $430 and will (probably) get at least 5 years of updates. If budget phone makers can't do something cheaper than the iPhone SE then surely their entire business model is just fucked?
Economies of scale. The SE is basically the hand me downs from the mainline iphone and couldn't exist without it. It's not surprising that no name brands can't compete with the richest company in the world.
Why would they not make a budget phone? It's not like the BOM + assembly for a touchscreen, first(!) battery, motherboard, and plastic case cost that much. Check out some of the public reports from counterpointresearch.com: the profit margin on flagships is often double the BOM cost, the profit margin on budget phones is a little tighter but still not bad. Who cares what the revenue is per year? What matters is how much it costs to make the thing. Most vendors are just tweaking reference designs anyways.
The Moto G Play is just $170 list, currently going for ~$110. It has a rather pathetic 3 years support, but that's $4.72 per month at list, or ~$3.95 at current list rates - assuming you throw it away when the support contract ends. The Samsung A14 5g is $200, and gets 4 years' support, which is $4.15/mo, again, assuming list price and discarding when security updates are over.
I'm currently typing from my Moto G6, which came out in April 2018. I bought in July of that year for $100 (it was a BOGO with a buddy's $400 Moto One Zoom, they were literally giving them away as a backup to promote their more expensive phone because the BOM cost was so cheap). I plug it in on my desk at work because the battery sucks now, but that's no great hardship. By that math, I've enjoyed the use of a smartphone for $1.62 per month (would be $3.25 at list). Yes, it's only running Android 9 and not getting "security updates" anymore, but I have my phone app, messaging app, a camera, and Firefox, and that's about all I need.
I think it would be ridiculous to spend $30 or $40 A MONTH for a smartphone. It doesn't matter what some people pay for a fantasy football team app, that has nothing to do with buying hardware. Other people are buying 3000 lbs used cars for the same price others are paying for a flagship 200g slab of glass!
I have the Moto G4, which is on its last legs after 8 years.
It barely had any non-android, non-Google apps. If there were any, I uninstalled them all except one from the Apps list without having to root my phone or anything. The last one is called Moto, which is disabled (can't be uninstalled).
> No company will ever make a 5-8 year phone at that price
But they already do? I used my Oneplus X for 6 years and that was $249. Battery is the main reason I stopped using it. That's $3.50/month, maybe an outlier, but I wouldn't pay 10x that to check my messages and get directions.
I still don't get the "premium feel" line when everyone covers their phone in a case anyway. I don't care if my phone is made of plastic when it actually makes it less prone to breaking when dropped.
I've been saying this to people for years. Tons of companies market how a phone feels, its looks/colors but then almost everybody just ends up slapping a case on it.
I literally couldn't care what a phone was made out of/how it feels since I just put a case on it before I even use it for a day in most situations.
Same here. I think it's ridiculous we make phones out of glass, then put more glass on them to protect that glass. Phone screens should be made of plastic, which doesn't break, and then let me put a piece of glass over it to prevent scratching. And then if that breaks, oh well, I don't care because i can replace it for $10.
I put one of those ridiculous military spec, carbon fiber reinforced type cases on mine, it would be in pieces otherwise. It bulks the phone up a lot but every time I drop it, I smile.
I don't know if I've just been excessively lucky, but I've never put a case on any smartphone I've owned since 2010, and I've only cracked the screen on two of them. These days (probably for the past 4 years) I do put the thin-film screen protectors on as well, and replace them if they get damaged.
I've always been of the feeling that I'm buying this lovely, well-designed piece of hardware, why would I want to cover it up in an ugly plastic case?
I don't put cases (or even screen protectors) on mine either (since 2015). I've dropped it many times, obviously, but I've only ever had the edges of the phone get the slightest nicks - which I prefer to having a case on it.
Even worse is when the premium feel is at the expense of usability as well as durability. Matte glass backs and rounded aluminium sides might as well be a bar of soap
The pixel "a" series match your requirements for the most part. An inexperience phone stripped of unnecessary features. Unfortunately I don't know any phones that are also repairable, replaceable, and hackable.
That's why I think I'm going with the Samsung A54. It's around that price (if unlocked), but has decent specs. I eventually want to phase out my 4-year-old A50, mainly for android auto reasons. Need to ask online though, there may be better spec'd phones for the price point.
No replaceable battery, sadly, but those don't really exist at this point.
I am also in the market, and replacing my small/compact Moto G4 after 7-8 years. Sansung A54 seems to be the most appropriate replacement, based on my criteria.
I just looked up the battery replacement procedure, and it is not horrible for something you want to do once after 4 years.
Samsung sells their regularly-refreshed A series into something close to this price range, and they're great devices. For some reason they don't get nearly as much attention in the US as they do in Europe and other parts of the world, though.
The battery is replaceable, just not by the user (at least not easily). I've had my Pixel battery replaced; the cost didn't seem exorbitant.
It would be nice to be able to pop batteries in and out on the fly, but I suspect that would make it a lot harder to waterproof. I've lost more phones to water damage than I have to battery death.
The Samsung Galaxy S5 from 2014 had a removable battery, headphone jack, a microSD card slot, and was IP67 dust/water resistant. We lost removable batteries because it was an easy way to make devices obsolete.
IMO smartphones peaked around that era, and we've only seen incremental improvements and enshittification ever since. I used to be excited about every new device, but these days all manufacturers are grasping at straws trying to differentiate their rectangular slabs from the competition. AI is the latest gimmick in this trend.
If you extract the (I think) data.pck file, you can run it with the normal godot engine wherever it's supported. (as long as there's no missing features the game uses on that platform.) It'd be easier for the developer to do it, but anyone can theoretically.
