Complete list of secondary accounts across Lemmy, claimed here to all be the same human:
Thank you for the insight, however, I think that my question is somewhat different because I'm interested in the implementation choice rather than the language choice. To answer your question, I don't think Android should switch to C/C++. Instead, I don't understand why Android goes to such great lengths to avoid compiling whatever language is in use in advance. Naively from the outside looking in it appears this would greatly simplify the platform.
For example, I think it would be an improvement to use Java but compile the whole thing to a native image in the cloud and distribute the compiled binaries. We already have Java AOT capabilities in Android, therefore this appears to be technically feasible. Only one ISA is targeted officially. It's not a great academic leap to think apps could be built off the phone instead to avoid the complex optimization problems.
I am ignoring Chromebooks a bit. I did not know that you could run Android apps on that platform and didn't think to consider it because I didn't see x86 listed on Wikipedia as an officially supported architecture.
We do have privacy laws today (USA user), but they are so weak that near my office I regularly see ads advising businesses to treat it as a liability problem and instead buy insurance as a faster and cheaper alternative to good practices.
And it works! This approach should not be feasible to address the costs of violating user privacy. It reiterates to me that we are far too lax.
The purpose is backward and forward compatibility respectively.
The minimum version is the easiest to explain: any older, and your app just won't run. Don't even try. I (app) don't have the compatibility code to work with you if you are older than my minimum version because I didn't choose to include it, and you (Android) don't know the changes that were made in the future platform versions, so you can't help me.
Target version is a little more complex. This is the version of the API that I am designed to run with. You can use this information to set compatibility parameters for forward compatibility. For example, if I try to use API that doesn't exist in your version or that would have had different behavior, you would know what I'm expecting because I declared to you what it was designed for at the time. This allows the system to tolerate your outdatedness better.
However, that compatibility feature sometimes leads to security issues because the new API tends to be more restricted or improved in ways that enhance security and privacy, hence the argument why there should be a minimum target version to express that you cannot use the less secure API even for the sake of compatibility.
As you mentioned, that in and of itself isn't a bad thing. Sometimes it's good not to have people who are really casual users in your community. They can take their time coming over as long as the people who are here are having a good time.
I'm experiencing a bizarre glimpse of humanity in the Internet, before the bots have been written and move in, the experience of communicating with actual people without the influence of karma, business, or astroturf just yet.
They will come, but Lemmy sets the new terms of engagement.
We, the users, the community are the lifeblood. It's people that had the good times, and people that made them.
I recently experienced this while building an upgrade for my 3D printer. The upgrade kit included a touchscreen. I found out later that the touchscreen was effectively its own separate computer with more than 10x more resources than the actual computer inside the 3D printer that was doing the most important calculations.
The compute and memory resource constraints were basically nonexistent factors in the design of the printer and the upgrade kit. Merely, a simpler computer was easier to design for and characterize, so the printer itself had a very simple computer, and for the UX, a "beefy" computer was much easier to program. It's bizarre seeing how little the amount of computer resources mattered. It might as well have been free.
Another important factor to consider is that it doesn't need to be perfect to be better. Having options to continue using a platform is better than not having viable options. The fact that Lemmy is open and has some built-in resistance to being owned by a single entity is a huge step forward--even if it's not without the drawbacks of generalist instances.
I noticed that I don't have a karma or upvote counter for my account, and I felt free. Let's keep it that way. It just encourages more ego and skin in the discussion ahead of focusing on the content and further penalizes users who sometimes have an unpopular, but still civil and constructive, opinion. I don't want an echo chamber effect.
I imagine that implementing such a metric could become quite confusing if it turned out that not all instances permitted all communities in the future. If this is already the case, please excuse me. I've been on Lemmy for one hour total. Solving that consistency problem couldn't be easier than just not solving it.
Thank you; I will definitely add this to my reading list.