Complete list of secondary accounts across Lemmy, claimed here to all be the same human:
henfredemars@lemdro.id
henfredemars@infosec.pub
henfredemars@hexbear.net
Racism! Many, many racists in this country.
I feel quite confident in saying that we have no justice in this country.
I see this upcoming election will be the final one. Nice work.
Oh cool, thanks. I have friends in Texas and they make it sound like it could never happen.
Snowballs chance unfortunately. I understand getting a Democrat to win in Texas is effectively impossible.
Very cute! The grooming must be a task.
How do we know this post isn't fake? Perhaps it's all part of the ruse.
Is there a problem upvoting on other instances? I've never noticed it not working.
Even more, make it more like a backup feature that's opt out not opt in. Thus, when a server goes away, the user still has their community list to import somewhere else.
This sounds like a bug to me. At a minimum, it should be renamed to local subscribers rather than imply that it's the total count.
This is definitely a sink-or-swim moment for Lemmy. If this is going to work, this is the chance. Twitter and Reddit are imploding. Users have a reason to try something new and are willing to deal with young, buggy platforms because it's better than the alternative and they needed an Internet home. My upvote taking ten seconds to register is itself the knife's edge of creation, a new birth.
I love that a service that isn't making a buck off of us gets levels of engagement that for-profit social networks would kill for.
This is happening because:
- Novelty, because new is fun. This will go down over time.
- The most passionate users are more likely to be early adopters. More casual users are coming.
- Smaller network means your content is less likely to be covered before. This factor will go down over time.
- Fediverse encourages multiple related communities, which means your specific contributions are more likely to be seen by other users.
- Lack of bots/astroturfing leads to more positive interactions. Bots will likely increase over time.
Therefore, I expect engagement will go down over time, but I am hopeful it will reach a higher point of stability because the fediverse design seems better at getting more varied content seen by its users, and it makes it harder for a small group of people or posts to dominate the discussion space.
PS: Anybody know how to add a space after the last bullet in a list?
Somewhat, but it's just the "how's the weather?" of this community because most everyone is here from Reddit, so it's a starting point to me. I don't think Lemmy exists just to spite Reddit, and I participate in discussions having nothing to do with the subject.
QED, I think this response completely addresses my concerns. I often miss the social aspect of systems that involve people. I can't think of any further questions.
I reverse native binaries across a few different platforms for a living, but I'm just getting into Android. I will definitely take a look at those systems!
Underrated comment. I picked it because I had no idea what I was doing and it sounded all-encompassing and I wanted access to everything. I didn't even know what an instance was. I just picked it because it sounded like a good guess to get access to all of Lemmy.
Hello, and thank you for taking the time to compose this response.
I think that I may have conflated the choice of language with the choice of distribution. I believe the choice of language is independent of the choice to distribute apps as native or not, for at least Java because Java has solutions for AOT compilation not the least of which was actually used before in Android 5 according to another response, and it was used prior to Android 7 according to this resource.
For the sake of discussion, I propose that this existing AOT compiler for Android Java applications (used today in the hybrid solution) be run in its entirety on a server instead of on the user devices. I don't see a motivating reason to have the compiler on every user device to include a complex profile-guided optimization framework and hybrid JIT compiler (described in my third link in the original post) when we could ship the finished code and be done with it.
The benefit would be lower maintenance of the Android platform through a simpler design. (This benefit might shake out, but I get to that later.)
The migration process would consist of doing nothing for the typical app developer making this change quite cheap. The same languages would be supported as they are now. Indeed, this transition has already happened before and shows that this approach works, except with the build process happening on the device in earlier Android versions. I don't understand why Google did not go a step further and ship the binaries, instead choosing to take a step back and ship a JIT compiler with the AOT compiler. Why ship the intermediate bytecode representation and insist on a complex on-device build and optimization runtime?
From the responses that I have received so far, I think the true answer as to why distribution isn't native is likely composed of a combination of the following factors:
- Android's heritage and if it ain't broke, don't fix it mindset (very respectable IMHO).
- Android practically supports more platforms than arm64 even if not officially stated, such as Chromebooks and some x86 tablets. Shipping native would make this cross-arch support a lot more complicated.
- Loose coupling between hardware and software platforms as a good design decision.
- JIT performance can actually exceed AOT because more information is available at runtime.
- Backwards compatibility is very important to Android, and the impacts of not shipping bytecode to these old versions could be profound or practically impossible depending on how far back we wish to consider.
I'm sure that I'm making further assumptions, and surely there are oddball apps out there that really depend on having dynamic optimization to be performant, but I suspect these apps are in the minority. At a glance, the current solution seems too complicated, but I think understanding the history of the platform and the selection of devices that are supported today mostly answers my original question. Briefly, arm64 is absolutely not the end of the story even if it's listed as the supported CPU architecture, and officially committing to just one now and forever could come home to roost.
Thank you; I will definitely add this to my reading list.
Why does Android bother with Java?
More concretely, I'm asking this: why aren't applications compiled fully to native code before distribution rather than bytecode that runs on some virtual machine or runtime environment?
Implementation details aside, fundamentally, an Android application consists of bytecode, static resources, etc. In the Java world, I understand that the main appeal of having the JVM is to allow for enhanced portability and maybe also improved security. I know Android uses ART, but it remains that the applications are composed of processor-independent bytecode that leads to all this complex design to convert it into runnable code in some efficient manner. See: ART optimizing profiles, JIT compilation, [JIT/AOT Hybrid Compilation](https://www.intel.com/content/dam/develop/external/us/en/documents/android-the-road-to-jit-aot-hybrid-compilation-based-