Software Engineer, Linux Enthusiast, OpenRGB Developer, and Gamer
Lemmy.today Profile: https://lemmy.today/u/CalcProgrammer1
AOSP and even factory kernel source tends to be only mildly useful for proper Linux phone use. Android phones tend to ship with old kernel revisions that the chip maker forked a long time ago and developed their chip drovers on without following accepted kernel conventions or submitting any code to the actual kernel maintainers for proper review and integration into the most up to date "mainline" kernel. Due to this, and the fact that phone makers need to constantly ship new products out the door, the quality of this code added into the old kernel is often garbage, poorly commented and with no documentation. Usually no git history either.
There are other teams of people trying to clean up and/or rewrite these drivers from scratch in a way that is reviewable and acceptable in mainline. Only a small handful of the vast number of phone chips have such support, so proper Linux phone is limited to a small selection of hardware. The designed-for-Linux librem and PinePhone models intentionally chose old chipsets because these chipsets had good mainline support and thus could receive actual kernel updates rather than being stuck forever on an ancient kernel release from the manufacturer that has long since been abandoned.
Lately the Qualcomm Snapdragon SDM845 chip is seeing growing mainline Linux support and quickly becoming one of the most viable chips for mobile Linux that isn't a complete dinosaur in terms of performance and power draw. The OnePlus 6 and 6T, which both use the SDM845 chip, have become quite popular as Linux phones now despite not yet having VoLTE and thus being useless for calls. I carry a OnePlus 6T as a secondary non-phone pocket PC because the Linux experience is very good other than the lack of phone and camera functionality. It's fast and can do all my terminal and coding stuff as well as run full fledged web browsers well.
Nice review. I agree with others here that this phone is borderline scam for the price and with all the delays people had in receiving them. Performance seems on par with the $200 original PinePhone which I had a similar experience with.
The one good thing that came out of Purism/Librem 5 is Phosh. It's a pretty good phone shell/UI for other more capable Linux phones to use. I particularly like Phosh for its on-screen keyboard Squeekboard which allows for custom keymaps.
We have Waydroid which is close enough. It needs some quality of life improvements for better integration with the native Linux ecosystem but it runs Android apps just fine on Linux phones.
I have Waydroid set up on my postmarketOS OnePlus 6T mainly so I can use the Discord app. Waydroid still needs some integration issues worked out (access to location, access to Bluetooth, access to calls/texts, ability to forward notifications to the Linux side) but otherwise it runs quite well. Performance feels pretty similar to native. I also have a OnePlus 6 running stock OS for my main phone tasks as pmOS doesn't have VoLTE support for the 6T so is kinda useless as a phone right now.
I've had an A770 Limited Edition since its release in late 2022. Overall, I'm happy with it. The drivers were a mess at launch but now everything works as expected. Performance is decent in the games I play, though I have a 144Hz 4K monitor and it's not really capable of that resolution and refresh rate except on the lightest esports games so I use FSR on most games. My most played game is Overwatch and it hits 144Hz with dynamic resolution scaling on and medium settings. I want to buy a higher end GPU eventually to really push this monitor but waiting to see what happens with the next generation of Intel and AMD cards (NVIDIA is not even in the running unless NVK suddenly gets performance parity with the proprietary drivers).
GitLab used to be awesome when it was the place to go after MS bought out GitHub. They had premium access for all public projects under a FOSS license and top-tier CI. Then as time went on, they began pulling support for various functions in a very Microsoftian EEE sort of way. First requiring credit cards fir new users to access the CI, then taking away the CI almost entirely except for a practically useless monthly allotment, then taking away the premium access for public FOSS licensed projects. If I were migrating today I would not have chosen GitLab, but it is where I settled after leaving GitHub and my projects have grown to depend on GitLab CI even if I'm now forced to run my own runners due to the extreme nerfs they've done to the hosted CI. I mirrored OpenRGB to Codeberg, but since the CI pipelines depend on GitLab I don't see Codeberg becoming the main hub anytime soon unless they can execute GL CI configs. Sad to see how far GitLab has fallen though, it is unrecognizable from what it used to be as far as support for FOSS prohects goes, especially given how GitLab itself started as a FOSS project.
Plug in hybrid usually refers to a car that has some amount of purely electric range, charges like an EV, but after depleting its battery falls back into conventional hybrid mode where the battery is maintained to some level of reserve power using a gas engine. The Chevy Volt is probably the best example. I drive a Volt and all my daily commute is purely electric unless it's super cold outside.
I love my 2014 Gen 1 Volt and would love to see the technology continue to improve. If they made a Gen 3 Volt with at least 100 miles all electric range and a heat pump system that didn't halve the battery when it's cold outside I would absolutely consider it over a pure EV for my next car.
AMD's integrated GPUs have been getting really good lately. I'm impressed at what they are capable of with gaming handhelds and it only makes sense to put the same extra GPU power into desktop APUs. This hopefully will lead to true gaming laptops that don't require power hungry discrete GPUs and workarounds/render offloading for hybrid graphics. That said, to truly be a gaming laptop replacement I want to see a solid 60fps minimum at at least 1080p, but the fact that we're seeing numbers close to this is impressive nonetheless.
Pretty much all the alternative SBCs are either Rockchip or Allwinner if you want ARM. There are a few RISC-V SBCs now but software support isn't as solid and many of these lack GPUs. There are also a few x86/64 SBCs based on either older Intel Atom or newer mobile parts too.
There are plenty of alternative SBCs out there, many mimicking the RPi form factor as well. Look into Radxa, Banana Pi, Orange Pi, Pine64, ODROID, etc. I picked up an Indiedroid Nova board last year that is RPi form factor but has the more powerful RK3588 processor. Drivers are still WIP but it is quite fast. I also run my home server on a Radxa Rock Pi 4, which has an RK3399 processor and is very comparable to the RPi 4. Drivers for it are pretty solid these days and it doesn't require extra work to set up. Just download an Armbian image and go.
I'm fine with Apple retaining interoperability between their first party software products, they just need a way to bypass the walled garden. If they have sideloading (everywhere and without restrictions) and ideally also bootloader unlocking, they provide a sanctioned path around the walls of their ecosystem and now it's up to the user to choose to leave that garden. If the user is comfortable there, they can stay. Trying to fuck over sideloading is the issue here. I'm fine with the App Store being restrictive if there's a way around it, and simply sideloading an app shouldn't break the rest of the OS's capabilities.
I thought their reputation was tarnished explicitly due to uploading footage to the cloud despite claims otherwise. How can you be sure it isn't uploading when their words mean nothing?
Hacker's Keyboard is the only keyboard app I'll accept on Android.
Drastically nerfed the quotas. FOSS projects with a valid license used to have GitLab Premium access to shared runners and now even FOSS projects with a valid license get a rather useless 400 minutes. They also require new accounts to add CC info just to use that paltry sum which means FOSS projects can't rely on CI passing on forks to ensure a merge request passes the checks before merging, as even if you have project specific runners set up forks don't use them and neither to MRs.
I wish companies didn't offer what they can't support from the beginning rather than this embrace, extend, extinguish shit. I guess in GitLab's case there was no extend, it was just embrace FOSS projects and let them set up CI pipelines and get projects depending on the shared CI runners as part of merge request workflow for a few years and then extinguish by yoinking that access away and fucking over everyone's workflow, leaving us scrambling to set up project side runners and ruining checks on MRs.
I still left my old and unmaintained projects on GitHub but I moved all my active projects to GitLab and any new projects go there too. I have them auto mirrored back to GitHub though as the more mirrors the better. I also recently set up a Codeberg mirror for some of my projects, though GitLab's CI is what is keeping me on GitLab even though they nerfed the shit out of it and made it basically a requirement to host your own runners even for FOSS projects a year or two back. Still hate them for that and if Codeberg gets a solid CI option, leaving GitLab would make me happy. They too have seen quite a lot of enshittification in the years since Microsoft bought GitHub.
I'm in the middle and I don't always like it. 100% coverage is mandatory for the industry I work in though. I get that module testing is important but it can be such a chore to work on. I got pulled in to help write tests for another project this month and that is somewhere between watching grass grow and watching paint dry in terms of level of excitement.
Also fork the repos. Git makes duplicating a repository simple, and preserving history with a fork is way better than uploading a zip snapshot. For best results fork to GitLab, Bitbucket, Codeberg, etc. as well.
Does this change run the 32-bit .exe using x86_64 instructions? From the description it just sounds like it allows 64-bit Linux libraries to be used in place of 32-bit ones, but that the Windows layer still operates in native 32-bit mode. This means there is still a need to emulate 32-bit x86 instructions which I don't think box64 can do at this time (x86_32 translates to arm32 with box86, x86_64 translates to arm64 with box64). If box86 could translate x86_32 to arm64 then this might work as Wine would handle the conversion between 32 and 64 bit addressing and argument passing into the libraries but I'm not familiar with the inner workings there.
I am not in love with the idea of pure hydrogen cars due to the inefficiencies involved, but I can see a hydrogen/BEV plug in hybrid being a good option if hydrogen infrastructure gets built out. As is, I drive a Chevy Volt, and while its battery range is low it is enough for the majority of my daily driving. The biggest downside of pure EVs is charging time when you're driving on long trips, and in my Volt I don't have to worry about that as I can just fill up with gas. Well, do the same thing but with hydrogen rather than gasoline and you have a car that can refill quickly like a gas car but can be powered entirely from renewable energy sources like a pure BEV. You need some lithium but less than you would for a full size battery. You still have the capability to charge at home and assuming the battery can do a reliable 50 miles or so you would only need hydrogen for longer trips. You could leave the hydrogen tank empty to avoid leakage and safety issues when you aren't doing a road trip. Also, hydrogen cars are EVs anyways so the drivetrain doesn't need the extra complexity of a conventional hybrid, just switch power between the battery and hydrogeb fuel cell.