I'm a very casual Pixel Dungeon player and have never played Experienced Pixel Dungeon (might give the final version a try but I suspect it's not very noob friendly), but I'd still like to say kudos to you for handling the project's end so well - so many projects end up simply abandoned or even deleted without warning. And you've brought it up to date with upstream for one last time, that's also awesome from you. Just sucks to hear that you didn't enjoy working on it.

Anyway, good luck with whatever you end up doing

This is the a model, it won't have optical zoom either way.

Yay for another boring slab with zero distinguishing features!

Even on my home server (a desktop with 64 gigs of ram) the ram check takes longer than the OS.

I was pretty sure I messed something up when I upgraded the RAM in my desktop from 16 to 64 gigs and it wouldn't output any signal for solid 10 seconds, lol. And the regular 5 second black screen on normal boots was still something I had to get used to coming from maybe a second with 16 GB

Your argument is to have 2 subtly incompatible abis and one day binaries magically break.

Whereas your argument seems to be to have a special C variant for 32bit Linux - there's no reason to have a special time64_t anywhere else.

No program with time32_t will ever work after 2038, so any compiled that way are broken from compilation.

Yeah, so what will breaking the ABI do? Break it a bit more?

If you really want to be clever, mangle the symbols for the functions that handle time so they encode time64 as appropriate

That's what MUSL libc does, and the result is two subtly incompatible ABIs - statically linked programs are fine, but if a dynamically linked library exports any function with time_t parameter or return value, it will use whatever size was configured at build time and it becomes a part of its ABI. So fixing this properly would require every library that wants to pass time_t values in its API to implement its own name mangling. That's not a reasonable request for a barely used platform (remember, this is just 32bit userland, 64bit was always unaffected).

Ah, the joys of requiring non-standard library calls for apps to function.

The problem is that this approach breaks the C standard library API, which is one of the few things that are actually pretty universal and expected to work on any platform. You don't want to force app developers to support your snowflake OS that doesn't support C.

The current way forward accepted by every other distro is to just recompile everything against the new 64-bit libraries. Unless the compiled software makes weird hardcoded assumptions about sizes of structs (hand-coded assembly might be one somewhat legitimate reason for that, but other distros have been migrating to 64-bit time_t for long enough that this should have been caught already), this fixes the problem entirely for software that can be recompiled.

That leaves just the proprietary software, for which you can either have a separate library path with 32-bit time_t dependencies, or use containers to effectively do the same.

Sneaky edit: why not add new 64-bit APIs to C? Because the C standard never said anything about how to represent time_t. If the chosen implementation is insufficient, it's purely on the platform to fix it. The C17 standard:

The range and precision of times representable in clock_t and time_t are implementation-defined.

I have a cable that shows wattage and my 7a goes all the way to 80% at pretty much stable 20W unless it's overheating. The final 20% is a bit more random, but that's true even without adaptive battery turned on - the top 10% won't go above 5 W at all for me, for example.

That quote doesn't support what you're saying.

To me "waits until you need it to fully charge" sounds closer to "waits at a safe level until it needs to fully charge" than to "charges slowly", but English is not my first language and it might sound to me like a stronger statement than it really is.

But my point was more that nowhere does it state that it will slow charge (which I agree I didn't properly communicate).

so that it can charge at the slowest possible rate to reach 100% one hour before your predicted unplug time

No, it fast charges to 80% then restarts the (fast) charging to hit 100% at the correct time. At no point does it try to slow down the charge.

I don't really know where this misconception comes from, the description in settings is pretty accurate to what it does:

To help extend battery lifespan, your phone learns your charging routine and waits until you need it to fully charge.

No, it will fast charge to 80%, then restart charming just in time to hit 100% when your alarm goes off (or when it thinks you're going to wake up). There's no automatic slow charging other than thermal throttling.

Yes, but these internal connections can be done in a variety of ways - for example the most common way to connect laptop displays (which I would definitely classify as internal) is using embedded DisplayPort.

But Wayland isn't a thing on its own, there's no "Wayland server" or anything else equivalent to the X server. The compositors like Kwin or GNOME's Mutter are Wayland implementations fully responsible for handling the display output.

You can blame Wayland for the lack of universally supported global hotkeys or for issues with apps that need to know exactly where on the screen they are - these are issues with the protocol - but not for bugs in one compositor's implementation of display management.

OK but Wayland is not responsible for arranging monitors

OK, I use GNOME on Wayland on EndeavourOS and have no problems regularly running a script in my phone's internal storage root directory. Go file a bug report to your distro, or at least provide some details.

I can't speak for these specific laptops, but unlike x86, ARM generally doesn't have a way for an OS to discover the available hardware, and most ARM platforms historically didn't do anything to help. There is a standard for UEFI on ARM where the UEFI is supposed to tell the OS about the hardware, but as far as I know this is only a thing on ARM servers and these laptops might not support it.

Without any way of probing for hardware or getting the information from UEFI, Linux has to somehow be compiled with all the info about the hardware built-in. And the build will be model-specific (there's a way to pass a file describing the hardware to Linux from the bootloader which enables a single kernel to be used on multiple models and have just a small part of the bootloader be model-specific, but somebody still needs to make that file and the manufacturers clearly don't intend to do that).

Just FYI, this seems to depend on where you get the Pixel from - if bought directly from Google, it should be offline-unlockable out of the box. The carrier-sold Pixels are a different story because the carriers demanded it.

Of course check this is true for the specific model you're buying before you actually buy it, but for me the unlock was never greyed out on my 7a.

As the other person said, what you're doing is pretty much emulating the behavior of tiling window managers. Edit while writing: I'm leaving the rest here because you might find it useful, but I've just realized that there's a tiling extension for GNOME (the desktop environment used by Ubuntu): Tiling Shell. That's definitely going to be the most painless way for you to try out tiling. There's also bound to be something similar available for KDE.

I think you will get a much better result than with virtual screens by configuring one to your taste, assuming you're willing to spend a few hours learning all the ins and outs (it's absolutely OK if you're not willing to do that).

Here's links to a few of them, you should be able to install them in whatever distro you prefer:

Hyprland - a tiling WM focused on good out of the box experience and animations (but it's still very configurable). If you want to get your feet wet with standalone tiling WMs as fast and painlessly as possible, this is IMHO the way

Sway - a more keyboard-centric tiling WM that leaves out the fancy stuff (for example I don't think there's any way to do window shadows or animations for all the window manipulation) and focuses on just being fast and efficient if you learn its concepts. This is the only one I've ever used for longer periods of time.

SwayFX - "Sway, but with eye candy!" - I don't think I can write a better description - has some graphics effects like window blurring or shadows.

Pixel - varies by manufacturer

That was the Nexus line, Pixel phones are all made by Google. Although Pixel 5 series and older use Snapdragon SoCs, while 6 onwards use Google's custom Tensor based on Samsung's Exynos. The major downside is IMHO the awful modem efficiency - if I want to keep mobile network on so that I can receive calls, my 7a is limited to 2 days of battery life if I'm lucky (and that's with barely using the phone, just a few pictures).

Edit: and I forgot to mention that all Pixels have great third party ROM support, except if you want GrapheneOS, in which case you need to go for the recent ones that are still supported by Google.

They probably fixed all the bugs they considered essential, and the rest is just nice to have fixes that can be moved to the next cycle if necessary (and they still have a week to work on them before release, although they might be careful not to introduce severe bugs now).

The general idea with this approach is that it doesn't make sense to block a release on a few bugs worked on by only a subset of available developers and having the rest idle - the project can be finished faster by moving the remaining tasks over to the next release and accepting the bugs in the meantime.

Not familiar with the API, and I'm not entirely sure if it's not just a bug in Eternity (fork of Infinity), but lemmy.one doesn't have downvotes and I don't get the option to downvote anywhere.

Stock Pixel devices cannot use other gallery apps to view their images.

TIL Piktures is not a third party gallery app. Works just fine.