Maybe recent events made you aware that Google can arbitrarily suspend your Google account forever depending on the things you take pictures of. Even if they’re harmless things and the activity on your account was innocent and legal. What can you do if you want to avoid this risk and stop using Google Photos, but still want somewhere to put your phone snapshots?
For me, the auto-sync features from Android devices was Google Photos’ killer feature, so that’s what I wanted to replace. Now I have the following self-hosted solution:
Nextcloud for synchronizing photos to a small staging area on cloud storage
FolderSync because Nextcloud on Android can’t do proper two-way sync for photos
PhotoView to view photos from the NAS where they’re sorted and stored long-term
I’ve experimented for some weeks before settling on this configuration, read on if you want to know what my workflow ended up being.
In some situations, you may end up with emoji displaying in color in GTK applications but not in Qt ones (such as Kate, Konsole, etc.)
If you’re sure you have a color emoji font installed (e.g. fonts-noto-color-emoji) and still get most emoji in black and white, it might be because your system default font provides black and white emoji already. The color font further down the line is never matched so you get black and white emoji instead.
The cause of this problem is very complicated but the solution is easy: Slap this into your /etc/fonts/local.conf (and maybe run fc-cache -f as root):
<?xml version='1.0'?><!DOCTYPE fontconfigSYSTEM'fonts.dtd'><fontconfig><alias><family>sans-serif</family><prefer><family>Noto Sans</family><family>Noto Color Emoji</family><family>Noto Emoji</family><family>DejaVu Sans</family></prefer></alias><alias><family>serif</family><prefer><family>Noto Serif</family><family>Noto Color Emoji</family><family>Noto Emoji</family><family>DejaVu Serif</family></prefer></alias><alias><family>monospace</family><prefer><family>Noto Mono</family><family>Noto Color Emoji</family><family>Noto Emoji</family></prefer></alias><dir>/usr/local/share/fonts</dir></fontconfig>Code language:HTML, XML(xml)
If you stream audio in various formats from MPD to music clients, you may have run into a problem. Sometimes audio might simply go silent on a track change even though your MPD client says it’s playing the next song. This might actually have something to do with your player: some players don’t deal with audio frequency or resolution changes well. If you have audio in various resolutions and bitrates, this can trigger such a silence.
There’s one way to work around this, forcing your audio output to always have the same frequency and resolution via the format option:
The always_on option may help as well with especially picky audio players. It produces a constant stream of silence so that there is always a bitstream for clients to receive.
A problem with this approach is of course that if you have a lot of audio in e.g. 48 KHz and 24-bit, the resulting stream will be downsampled. But you can try using e.g. 48000:24:2 in this case. I’m not sure if upsampling 44.1 KHz content to 48 KHz might introduce audible artifacting; I certainly can’t hear it.
Thanks to Neo-Desktop on GitHub for digging up my old gist about this issue and testing the workaround.
Since Google is the gatekeeper of the APK trust chain, it’s not easy to independently verify APKs; Google doesn’t even give you the package signatures. The article shows a nifty method for extracting them by (ab)using the εxodus privacy audit project.
Update 2011-07-19: This trick should no longer be necessary, at least not when playing Pinball FX3. Recent versions of Proton now include the anticheat support that Pinball FX3 requires. I would have preferred if Zen Studios had made anticheat optional when playing in single-player/offline mode, but OK, this is good too.
Okay, this one requires some explanation. There is one game I like that simply won’t work on Linux through Proton, and that’s Pinball FX3. The reason is probably some sort of weird anticheat mechanism the developers use; it just crashes on launch.
Now the problem isn’t the game itself: Once you crack the game, it runs perfectly fine. It must be something in the anticheat DLL that causes the crashes. The issue has been listed on Valve’s Proton issue tracker since 2018, so I’m not entirely sure there’s anything Valve can do about it. But several enterprising people in the Pinball FX3 discussion boards on Steam have discovered a solution: Just install the Windows version of Steam in WINE, then install Pinball FX3 in there. Works perfectly!
It seems WINE is good enough to offer whatever Windows syscalls the Pinball FX3 anticheat requires. The only problem I had when playing like this was that the Steam UI is flickering in and out of existence, and it’s hard to choose a game to start when you can’t see it half the time. But Redditor Lemonzest2012 has a nifty workaround:
This not only works around the flickering, it also saves on resources and fixes another problem: steamwebhelper.exe randomly taking up 100% on entire CPU cores. Which is a thing. I swear.
What have we learned from this?
Steam can be a dumpster fire.
WINE does a bangin’ job implementing ye ole Windows syscalls.
Zen Studios (the people behind Pinball FX3) should offer a native Linux port. They did sort of promise they’d look into it once Pinball FX2 (yes, two!) comes to Steam, but it’s been nothing but crickets since. That was in 2013. What’s almost a decade between friends, eh?
If you would like to support a digital pinball developer who hearts Linux instead, try Zaccaria Pinball. The newer “Deluxe” type tables are very good indeed, the thing runs smooth as butter even on moderately powerful hardware and the lighting in their engine is just delicious 👌
For several months now, my keyboard layout would reset to English (US) every time I log into Plasma. I’ve tried every possible way to force it to my preferred layout, EurKey, but nothing worked: xorg.conf snippets, localectl configurations, it seemed Plasma simply ignored these settings.
At first I blamed Plasma, but it’s innocent: The problem is Zoom! The Zoom package contains an unnecessary dependency on IBus, at least in the RPM that Zoom packages for openSUSE. IBus comes with its own keyboard handling and is useful if you want to type text in Chinese, Japanese, Korean or other languages using non-Latin characters. But it also means that if you don’t configure IBus, your Plasma session will start with English (US) no matter what XKB keyboard layout you have set in Plasma.
The solution, at least until Zoom fixes their package, is to tell IBus to use your XKB keyboard layout. Right-click the IBus widget in the system tray and go to advanced preferences:
Here, select “use system keyboard layout”. This will force IBus to use whatever is set via XKB.
Using Google Fonts on your site is a privacy problem because it allows Google to track your visitors even if you don’t use any other Google APIs or services. Why did you think Google so generously lets you use those fonts for free?
My RX 580 has been giving me trouble recently. There is now an audible clicking when its fans spin up from zero RPM, and unfortunately, this happens a lot in desktop use.
Not wanting to invest in an aftermarket fan just yet, I looked for ways to manage the fan RPM curves while overriding the GPU BIOS and I found amdgpu-fan.
I prefer this to the other solutions out there for a few reasons:
Doesn’t need (or even have) a GUI
It’s just a small Python script
The config file format uses nice human-readable numbers (percentages, not absolute values)
The file’s a simple bit of YAML
The tool seems to rather smoothly calculate curves between the stop points you configure
To prevent the clicking noise when the fan engages, I set it to run at 35% RPM even as a baseline, and not ramp up until the GPU hits 60 degrees. At this setting, I can’t hear the fans during desktop use; goal accomplished.
My config for an XFX Radeon RX 580 GTS XXX Edition looks like this:
There’s a reason for the very specific title: It seems this feature is configured a little differently on Tumbleweed than on openSUSE Leap and I haven’t found any up-to-date information on this. So I’m writing this down as a note to myself.
A default Plasma desktop will use kwallet to save passwords for various desktop services (802.11x passwords, Nextcloud/ownCloud logins, SSH key passphrases, etc.). This can get inconvenient when e.g. Nextcloud wants to access the Internet, but the wallet isn’t unlocked yet, so Plasma can’t decrypt the WLAN PSK.
One solution is to:
Make your kwallet password the same as your user password
Ensure kwallet’s default wallet is called “kwallet” and that it’s the one that contains the keys you want unlocked on login
Make sure this wallet is using Blowfish encryption (this will not work in gnupg mode)
Install the require PAM modules
The package on openSUSE Tumbleweed is “pam_kwallet”, so:
sudo zypper in pam_kwallet
Log out from your desktop session, log back in and it should immediately work. In the past, you would have had to add the pam modules to /etc/pam.d/common-session or /etc/pam.d/sddm,but this is now done automatically.
The elegance of this is that you can still store more precious passwords in a separate wallet in Wallet Manager (just call that one something other than “kwallet”). That wallet can then be set to decrypt only on demand. This should save a lot of passphrase typing on a typical day.
Update, 2020-04-29: Since upgrading to kernel 5.6.6 and Mesa 20.0.4 I haven’t had any GPU resets anymore even without this workaround. It seems the reclocking issue is fixed. Keeping the article for reference:
If you have an AMD Vega 56 or 64 you may have had some issues using the amdgpu driver, namely random GPU resets leaving you with a blank or colored screen and freezing the computer after a few minutes. It seems that too aggressive memory reclocking is the culprit, but I found a solution in the Freedesktop issue list on their GitLab instance:
Stick this in your systemd, e.g. to /etc/systemd/system/amdgpu-pp.service:
[Unit]Description=AMD PP adjust service
[Install]WantedBy=multi-user.targetCode language:TOML, also INI(ini)