• 2 Posts
  • 17 Comments
Joined 1 year ago
cake
Cake day: June 6th, 2023

help-circle


  • To be fair, giving a company that’s been failing to get themed icons to work on Android for almost four years now less than a month to make a significant change to a core part of their software is… quite weird?

    Like, the EU usually gives companies at least half a year to comply with smaller demands than this, because companies with such a huge bureaucracy load wouldn’t even be able to change an app logo in such a short amount of time.


  • I do not know of any such dongle, but I’d like to ask you a question if you don’t mind: are you looking for a dongle with open-source firmware, or would a dongle that has its (proprietary) firmware stored in some onboard memory be acceptable?

    The second option wouldn’t require you to install any proprietary firmware on your computer, but you’d still rely on the proprietary firmware for the device to run. And it might also exist, unlike a dongle with FOSS firmware.


  • new Pixel

    Pixel 6 Pro, Pixel 7 Pro, Pixel 8 Pro, Pixel 9 Pro, Pixel 9 Pro XL and both Folds. Not the base variants, and especially not the a series. Just in case anyone actually wondered.

    The bigger issue is that you can only cast from the tablet to the phone, not the other way around, at least if the Feature Drop page is to be believed

    Soon, you can easily transfer media from your Pixel Tablet to your Pixel phone with the new casting feature coming in the next few weeks. All you have to do is bring your phone close to your tablet and what you’re playing on Spotify or YouTube music will seamlessly move over without the extra steps of tapping the cast icon.




  • 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.


  • 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.


  • Wow, first time I feel strongly about a quick settings update. It looks awful, taking the worst parts of the Android 12+ redesign and combining them with the worst ideas from the older design, like unlabeled icons.

    It looks like there are unlabeled icons in the expanded state? Wtf? If I’m expanding the quick settings, that means I’m fishing for the less used settings, so there’s no way I’m going to remember that for example the weird circle with a small segment cut out means “Data saver”. It will just be a mystery icon that does some mystery action - that has nothing to do in a modern OS.

    It looks like this design is heavily sacrificing usability for people who don’t spend hours every day mucking around with quick settings in order to please some hypothetical user who feels more slowed down by swiping over one or two screens than by having to find the one setting they currently need in a big matrix of poorly designed icons.

    Edit: also it looks like the home screen is visible under the quick settings - I’m not a big fan of that, I really like the current design where the notifications are pretty much their own separate screen without distracting app content, but that’s just my subjective taste. Unlabeled icons are objectively bad.





  • manufacturers can put it where your hand naturally rests, meaning that you can unlock the phone BEFORE you have even taken it out of your pocket.

    Idk, my “unlock” finger naturally rests wherever the fingerprint scanner is on my phone. When I had a rear fingerprint scanner, I used to have my phone’s bottom right corner planted into my palm near the thumb and used the index finger to support its back near the scanner, so I was always ready to unlock it.

    Now that I have an under-screen scanner, I use my pinky as a “shelf” for the phone’s bottom side, ring finger to hold it on the far side and index finger along the near side (which makes me suspect this grip would work for in-power-button scanners too), and that makes my thumb naturally rest exactly on the spot where the scanner is. With (one) tap to wake, I have no problem unlocking the phone while taking it out of my pocket - literally just a quick double tap. Although it’s true that you can’t unlock the phone directly in the pocket like this, because the proximity sensor should prevent the tap to wake from working.

    I used to have a phone with a scanner in the power button too, but I can’t remember how I held it - I don’t think it was the same way as now, because I’m pretty sure I never used to rest my thumb on screen like this.


  • So now I’m looking at that kind of parasitic situation with this FRP bypass lock. It’s almost as if the manufacturer wants phones to be thrown in the garbage so users are forced to buy from them rather than aftermarket. Noooooo. /s

    It’s a theft deterrent, so it would be kind of pointless if there was an intentional way to disable it other than to log in with the owner’s account. The people providing the tools to bypass FRP want their cut of the stolen goods, that’s all.

    I’m not saying that your specific phone is stolen (although if you got it in this state… yeah, it most likely is, FRP triggers when you do a factory reset from the recovery instead of going through settings), but you have to understand that what you want is exactly what a thief would want, and the proce of the tools reflects that.