Work uses Slack, which is quite entrenched in the organization, so trying to move all of my contacts over to something else would be nontrivial. Colleagues use it to send moderately urgent messages every now and then, so notifications on my phone would be a nice-to-have.

I haven't had much luck finding well-maintained open-source clients for Slack. I could sandbox Play Services alongside the official app or a browser, but I'd rather not make my phone run the whole Google Play stack just for those notifications. Did I miss any low-hanging fruit or is hosting a Matrix bridge the only alternative?

It's not worth shipping and handling, it's beaten up, and I don't know anybody who wants it. Nothing is upgradeable, unless you count inserting a microSD card.

Of course I could use it as a janky media server or a dumb SSH terminal, but I've already got other machines for those jobs. Or I could recycle it, but what's the fun in that? Suggest me your wackiest programs to try, dangerous distros, or most unorthodox setups to make use of it.

Got Ollama set up with an 8GB AMD graphics card at my disposal. Any recommendations for the most unhinged model I can run on this? i.e. I can ask it how to annoy my neighbors and it won't go on a rant about morals or its supposed purpose as an LLM?

Summary: nothing seems to have changed on my phone except for an initial notification that my device is no longer supported.

The Pixel 4a with GrapheneOS is my secondary phone where I test out apps before committing to them on my main phone and sequester less desirable apps like Whatsapp. GrapheneOS support for it ended over a year ago, so the update notification today was quite the surprise.

With Google recently rolling out an update to the 4a that cripples its battery and charging, I was very wary, knowing that at least one of the GrapheneOS maintainers intends to discourage use of older, unsupported models.

My Pixel had been on the 2024092100 release of GOS, which oddly enough is not tagged in the repo. Comparing the closest release, 2024080800, with 2025012100 yielded no differences in the code (https://github.com/GrapheneOS-Archive/device_google_sunfish/compare/2024080800-sunfish...2025012100-sunfish). So I went ahead with it.

Upon booting, I found a notification saying that my device is no longer supported with a brief explanation. I dismissed it before I could type it up here since I was worried it was a sticky nag banner. It seems that this is acting upon what was mentioned on their Mastodon some time ago:

https://grapheneos.social/@GrapheneOS/111170300209864856

I'll come back to update this post if it does become a nag notification.

However, the lack of code changes might just point to me having dismissed the warning last update and then forgetting about it. But why else would they put out an update at this point?

Regardless, I can happily say that there is no impact on my Pixel 4a's battery life and fast charging is still allowed. I have no evidence that anything should have changed, but I'm not knowledgeable enough about the GrapheneOS code to make any promises.

Update: The notification does come back upon reboot, which was not the case before the update. It reads:

This device is no longer supported

This device stopped receiving full security updates in September 2023 and isn't safe to use anymore regardless of OS choice. It's strongly recommended to replace it as soon as possible. Tap to see more info.

Tapping opens up the GOS FAQ section on device support. I'll come back in a couple days if it recurs without reboot.

I was recently intrigued to learn that only half of the respondents to a survey said that they used disk encryption. Android, iOS, macOS, and Windows have been increasingly using encryption by default. On the other hand, while most Linux installers I've encountered include the option to encrypt, it is not selected by default.

Whether it's a test bench, beater laptop, NAS, or daily driver, I encrypt for peace of mind. Whatever I end up doing on my machines, I can be pretty confident my data won't end up in the wrong hands if the drive is stolen or lost and can be erased by simply overwriting the LUKS header. Recovering from an unbootable state or copying files out from an encrypted boot drive only takes a couple more commands compared to an unencrypted setup.

But that's just me and I'm curious to hear what other reasons to encrypt or not to encrypt are out there.

My laptop has a display resolution of 1366x768. Every now and then, I'll encounter a window whose default height is over 768 and thus won't fit entirely within my screen. The GTK file picker comes to mind, though it is resizable without much fuss. But then there are those that cannot be resized and being unable to move the titlebar further up, I am forced to use Alt+F7 to see what's at the bottom.

I suspect that many programs today are designed to work comfortably on higher resolution displays, but not really tested on smaller ones. Understandably, developers only have so much time and 1366x768 is getting long in the tooth. Just wanted to put this out there since nobody seems to be talking about it.

Decided to uninstall my display manager and use startx instead. But now when I resume from suspend, the brightness keys cease to work until I log out and back in. Backlight does still respond when echoing into /sys/class/backlight/intel_backlight/brightness. But what kind of magic does a display manager do to keep brightness controls working after suspend and resume?

Using xfce on tty1 on an X230 if it matters.

I like my Linux installs heavily customized and security hardened, to the extent that copying over /home won't cut it, but not so much that it breaks when updating Debian. Whenever someone mentions reinstalling Linux, I am instinctively nervous thinking about the work it would take for me to get from a vanilla install to my current configuration.

It started a couple of years ago, when dreading the work of configuring Debian to my taste on a new laptop, I decided to instead just shrink my existing install to match the new laptop's drive and dd it over. I later made a VM from my install, stripped out personal files and obvious junk, and condensed it to a 30 GB raw disk image, which I then deployed on the rest of my machines.

That was still a bit too janky, so once my configuration and installed packages stabilized, I bit the bullet, spun up a new VM, and painstakingly replicated my configuration from a fresh copy of Debian. I finished with a 24 GB raw disk image, which I can now deploy as a "fresh" yet pre-configured install, whether to prepare new machines, make new VMs, fix broken installs, or just because I want to.

All that needs to be done after dd'ing the image to a new disk is:

• Some machines: boot grubx64.efi/shimx64.efi from Ventoy and "bless" the new install with grub-install and update-grub
• Reencrypt LUKS root partition with new password
• Configure user and GRUB passwords
• Set hostname
• Install updates and drivers as needed
• Configure for high DPI if needed

I'm interested to hear if any of you have a similar workflow or any feedback on mine.

Been using searx.be for a bit now and they had many results in Dutch and German, which can be expected for a site based in Belgium. But does anyone notice an influx of results in Russian? Did they change the server location or are users in Russia catching on to it? Yandex isn't toggled on in the settings either.

Not trying to judge security by language. I just kinda liked having results in a mix of languages I could read.

Banking apps seem to be a motif among things that don't play well with privacy ROMs. My bank's website does everything I could want out of it. I think I might be ignorant to something.

• What about banking apps is especially compelling?
• How often do banks put must-have features behind an app?
• And should I be concerned that banks might move away from offering services through browsers?

I'm about to degoogle my stock Android phone. For the past few years, I've used it to handle the non-open source apps that I don't want running on my main phone. As I've finally weaned off GApps, I realize that I might as well go degoogle the rom as well.

edit: to be clear, I'll be using sandboxed Play services on GOS

But since that phone is my compatibility guinea pig, is it likely I'll still run into an app that demands unmodded Android with no alternatives? In your experience, has any bank or other service required the app on regular Android, with no alternative for the desktop, browser, etc?

As I understand it, X11 has many inherent security concerns, including programs being able to read the contents of other windows and intercept keystrokes. Wayland addresses these concerns but at the moment breaks certain functions like screen readers, cursor warping, and the ability of a program to resize its own window.

I am curious as to how the display protocols of MacOS and Windows handle these situations differently. How does a program in those operating systems gain permission to read the contents of other windows, if at all? What is to be done in Wayland for these functions to be more seamless or are there inherent obstacles?