I think that’s a good thing. Different topics have different moderation needs and I think specialized instances will be better equipped to deal with those special needs. Communities being on separate instances is by design and we shouldn’t have an expectation for instances to do everything.
Just a warning about community grabbing because there was a post somewhere which I can’t recall about them grabbing up communities that existed on reddit for the sole purpose of power tripping
I and others don’t want to have the same power mod issue where mods control a bunch of subreddits
As in the post we mention corruption of bad mods/power mods. Members of the C3 community do not share mods always either.
Those who do not maintain these rules within their community will be removed from the collaboration.
Fortunately with Lemmy, seeing bad mod behaviour is easy as the modlog is very transparent. You can see when action has been taken against a post within this collective. Then also notice when it doesn’t fall under our guidelines.
We are only removing posts which break the rules as seen in the sidebar
I tried all the Reddit apps back in the day and I don’t remember exactly how Infinity was but just wait a few weeks for Sync for Lemmy and I promise you won’t be disappointed.
Dunno honestly, I think I just want the feel of Infinity back. The customizability, the fluidity. I’ve been back and forth between Jerboa and Liftoff for about an hour now and can safely say that they both actually hit pretty close. Now I just need the easy of finding what I’m looking for in the app whether it be searching for a community or a specific post.
Something odd I’ve noticed is that Liftoff doesn’t seem to have a notification center? Quite strange seeing how that’s an integral part of the social experience. Early days I suppose.
Lemmy.ml basically shut up shop, redirecting people to other instances, because they were struggling, and the developers never really intended it to be as big as an instance as it has become.
Their registrations are still closed, so even if you wanted to join, that is not possible at the moment.
Welcome brother, sad state that Reddit is in nowadays. Glad to see you’ve found another comfortable nook. Been using Liftoff for a bit now and it’s actually quite nice. Reminiscent of Infinity in many ways.
I heard of Beehaw first but I got rejected twice when trying to make an account, so I tried World next and here I am.
Also don’t understand how things work, so wasn’t really sure what lemmy.ml was but I read it didn’t matter where you created an account so I just stuck with World 🤷
First of all, since the very early days Android has always allowed apps to make use of native code using the “NDK”, and in fact most games and most apps that do any sort of AI, image processing, or anything else complex like that make heavy use of native code already, for performance reasons.
Keep in mind that the decision to base Android apps around Java was made back in 2003 when Android was founded. Some of the reasons they picked Java were:
It’s one of the most widely known languages by developers
It’s hard to write code in languages like C and C++ without introducing memory bugs and security bugs. Using a higher-level language makes those bugs far less common.
It’s portable - you note that Android only supports arm64 now, but at the time it was arm32, and Android has actually always had some level of support for x86 - you can run the emulator for x86, and some x86 Android devices exist. Using a bytecode language means Android is future-proof
It’s not limited to just Java - the JVM has a rich ecosystem of languages that developers can use
Now 20 years later I think it’s worked out pretty well. It’s hard to imagine picking a different language would have worked out better. Java is still just as popular as ever, and Android developers can take advantage of all of the Java tools from any other platform or application.
Apple’s original option for iOS apps was just Objective-C, which is higher-performance, but overall it’s a more obscure, difficult to use language. Developers adopted it despite Obj-C, not because of it. Apple had to invent Swift to provide a more modern alternative, because Obj-C is basically not used anywhere else and it felt very ancient. While Swift is a pretty great language, it’s still somewhat obscure, only used for iOS and Mac apps - while Java and JVM languages are used everywhere.
Anyway, let’s say that Android really did want to switch, for some reason. I’m not sure why you think switching to compiled code would be less complex. How would all of the millions of existing Android apps migrate? What native languages would be supported? It’d be a huge transition for dubious benefits.
As it is, Android is extremely flexible. While the official APIs require a JVM language, because of the NDK you can basically write Android apps in whatever language you want. People have built frameworks enabling you to build Android apps in nearly every language under the sun.
Yeah but at the same time if you support c++ for example its still extremely relevant language(i like c better tho…) and you could build support onto that stable base instead of using the $hitstorm called java. Well thats my opinion anyways. Maybe ease of use is more important and making phones that are powerfull enough to be used as a laptop is the right path forward. But making android more efficient would take a lot of other things and im not nearly qualified enough for this discussion.
Java performance has rarely been an issue in any environment, Android or otherwise. Recall that one of the most successful mobile OSes running on much slower chips than even the first Android was written entirely in Java - BlackBerry OS. C++ is great too but it requires a lot more competent engineers to do well. Modern C++ is spectacular. Yet often people we interview for C++ positions write C with cout in place of printf.
I would also add that today JVM environments support more languages such as Scala, Kotlin, and Clojure (to name a few). So more variety and more modern paradigms are available.
As for native languages, we are more or less left with C, C++, Go and Rust. Also some of them are really awesome, none seem like a good choice for general-purpose app development.
And a counter-intuitive thing is that modern run times are so well optimized that sometimes they can outperform native applications (I’m not talking about very tight calculations such image processing and AI), because JIT has much more information about both the specific hardware and run time introspection that is unavailable at compile time.
I would also add that today JVM environments support more languages such as Scala, Kotlin, and Clojure (to name a few). So more variety and more modern paradigms are available.
As for native languages, we are more or less left with C, C++, Go and Rust. Also some of them are really awesome, none seem like a good choice for general-purpose app development.
And a counter-intuitive thing is that modern run times are so well optimized that sometimes they can outperform native applications (I’m not talking about very tight calculations such image processing and AI), because JIT has much more information about both the specific hardware and run time introspection that is unavailable at compile time.
I would also add that today JVM environments support more languages such as Scala, Kotlin, and Clojure (to name a few). So more variety and more modern paradigms are available.
As for native languages, we are more or less left with C, C++, Go and Rust. Also some of them are really awesome, none seem like a good choice for general-purpose app development.
And a counter-intuitive thing is that modern run times are so well optimized that sometimes they can outperform native applications (I’m not talking about very tight calculations such image processing and AI), because JIT has much more information about both the specific hardware and run time introspection that is unavailable at compile time.
I would also add that today JVM environments support more languages such as Scala, Kotlin, and Clojure (to name a few). So more variety and more modern paradigms are available.
As for native languages, we are more or less left with C, C++, Go and Rust. Also some of them are really awesome, none seem like a good choice for general-purpose app development.
And a counter-intuitive thing is that modern run times are so well optimized that sometimes they can outperform native applications (I’m not talking about very tight calculations such image processing and AI), because JIT has much more information about both the specific hardware and run time introspection that is unavailable at compile time.
JVM environments support more languages such as Scala, Kotlin, and Clojure
Are you aware of a currently supported way to run JVM Clojure on Android? The build tools I’m aware of have been abandoned for years and aren’t really usable anymore due to bit rot.
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.
I think the main issue is who it’d be simpler for. Let’s say that they switched to AOT compiling. That enables them to “simplify” the way Android works internally.
Who does that actually make things simpler for?
Literally ONE subteam of the Android team at Google. Nobody else.
It wouldn’t make things any simpler for developers. In fact, it’d make things worse because AOT compilation is slower and doesn’t allow things like hot-swapping code while your app is running - something you can do now with Java.
It wouldn’t make things any simpler for OEMs. They don’t have to worry about the Java runtime at all, they just worry about drivers.
It wouldn’t make things any simpler for the other 99% of the Android team that builds new APIs, new drivers, etc.
Basically you’re proposing a radical change that would make the platform worse for almost everyone, just so that one pretty small team at Google that builds the Java runtime portion of Android could make it a little simpler???
You say the current system seems “too complicated”. I agree it’s complex, but for a reason. Actually just about everything in tech is complex if you peek behind the curtain and learn how it works inside. The only difference here is that the code is open so anyone can see how it works. But for the most part these are just hidden details.
I guarantee that if you looked into how video frame compositing on Android works, or how low-latency audio works, or any of a hundred other things, you’d realize they’re incredibly complex too - probably “too complicated” at first. But that complexity is for a reason.
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!
I suspect that they’re a very slow-moving corporate culture and likely mostly interested in value extraction over a long term. It’s a general opposite of move-fast-and-break-stuff.
You don’t expect IBM to provide paradigm-breaking sexy new things, you expect them to build boring corporate stuff that you support for decades and gradually crystallizes because you can’t break specific use cases.
It takes a specific kind to get excited about that.
The whole MCA and PS/2 fiasco is probably at its heart them overplaying their hand on a business level. The PS/2s were cleverly designed machines and MCA was impressive for a 1987 design, but they fell flat because the business guys wanted to use it to rebottle the genie that Compaq released.
I’ve heard that OS/2 got hamstrung by IBM promising too much business-wise. They sold 286s with the promise it would run OS/2, but the 286 was a pretty bad platform to juggle DOS software and more modern multitasking on, so it was jankier and more incomplete than it needed to be. Even before the era of direct competition, OS/2 had a rep of being expensive and aekward.
I wonder if it would have fared better if the MS-IBM partnership had started 3 yesrs later and targeted the 386 from day 1.
The whole PS/2 & OS/2 fiasco is probably what pushed the once great IBM away from hardware and software production into managed services and consulting which is where they make their money now. They are a contract sales driven company. Quarterly sales targets & bonuses is a good way to motivate the sales team. The problem is that IBM concider everything other than sales an expense to be minimized. They do not invest. They market. “Watson” did not represent AI innovation. It was just a marketing tool.
Anecdotally, every interaction I or many friends had with IBM left a “is this the 90s” taste.
It feels super disorganized but it’s still a big corp, “simple” dev position hard require a degree (like, their system just wouldn’t let a friend submit their application because they didn’t press the checkmark lol) - usually it’s not a hard requirement in our local market. I’m still waiting 5 years later for the VP of the BU I was interviewing at to return from his vacation to “approve my hire” LOL (for all concerned I found work at a different company… But still amusing to think about that guy spending 5 years in vacation…).
Just examples, but feels like there’s some internal process/management failures higher up the food chain. Their devs create pretty innovative things, then nothing is actually done with that lol.
kbin.life
Active