Yep, I modded my switch, dumped the keys and my games and went “Now what?” and after playing via Yuzu on my PC I realized this was the only way I really wanted to play the few Switch games I enjoy.
Every now and then I’ll boot into the stock firmware to play Mario Kart with some friends when they want to play, and that’s it.
I imagine that is the case, however they could refund it given the situation.
I get the feeling they won’t allow refunds.
Ah I see, that’s unfortunate then. For what its worth, I still think the bot is a great idea for discoverability and bridging the two services together! I hadn’t seen it before since I usually have bot users muted and happened to see this comment chain while logged out.
I’ve given it a follow from my Mastodon account since I do tend to miss quite a few cool Lemmy posts it seems, and I think it’ll help me find some communities in general that I’ll want to subscribe to from over here.
I wonder if perhaps wrapping the majority of the text in a spoiler would work. Though I don’t know if that translates over to Mastodon (if not, it might look a bit funky on that side).
Correct, it just makes a link to the video itself!
Precisely, yep! It follows the same rules as subscribing to communities on Lemmy however - if you’re the first on an instance to subscribe, it may not pull the full backlog of videos - and at least one person needs to be subscribed for the instance to continue getting updates from the channel.
Try heading to !thelinuxexperiment_channel@tilvids.com for example, and you’ll see Nick’s channel come up as a community and each video that they upload will be its own “post”.
Note that when you lookup stuff on PeerTube, you have to use the channel name - not the uploader’s username. So the one I linked would work, but if you replaced the start with thelinuxexperiment it wouldn’t work, since that is a user and not a channel.
I hope you get to move over to Company B as soon as possible, and I’m sorry that things have been an absolute shitshow (from what I can gather) at A/C.
Google Chat was originally only for businesses/teams (think like a very condensed version of Slack) through Google Workspace - at some point it seems they lifted that restriction, but I get the feeling the actual target market hasn’t really changed.
And if you really want even more barebones, you can just do git init --bare into a directory on your VPS, and then git clone user@your.ip.here:path/to/the/directory and use git as you would normally!
Interesting, I will have a look at them - thanks!
Have you found any other decent online-centric banks to switch to? I’ve been wanting to switch away from ONE for pretty much the reasons you listed, but through a basic search I didn’t see anything else to was too appealing to me.
And the 2FA thing is ridiculous, at one point they didn’t actually have the email option (or it was very well hidden) - had a bit of a rough month at some point and wasn’t able to pay my phone bill which got it suspended, I also happened to have my card locked and got kicked out of the app so… I couldn’t unblock my card to pay the phone bill, which I needed to get the 2FA code to login in… Ended up having to reach out to support and they were able to show me how to request a 2FA code over email.
This wouldn’t even be a problem with most sites because I always use TOTP/Webauthn via my Yubikey when I have the option, and for something as critical as my bank account I really do not want SMS/Email to be an option for 2FA (I get why they have it, but I’d like to be able to turn it off for my account).
Ugh, I miss Simple so much. I was alright with ONE until they stripped the virtual card function from pockets… What is the actual point of Pockets now if I have to transfer the money directly back to my main checking area??
Yep, my desktop PC may or may not have one of its SSDs not mounted…
Interesting, sounds like they’re killing the wakelock that Caffeinate acquires then (which is what actually keeps the screen active), rather than killing the whole app itself.
That’s another one of those issues that I don’t think there’s too many workarounds for. Theoretically I might be able to have the app check to see if the wakelock is still active and if not, re-acquire it… but if there’s no way for the app to “know” that the wakelock has been killed in the first place, the only way around it would be to constantly ask Android “Is the wakelock still active? Is the wakelock still active? Is the wakelock still active?” over and over again, which would definitely lead to battery issues.
I do know it works on some Samsung devices, as I bought an old A2… something to test it on, and couldn’t find any signs of a problem there.
I mean hell, I’d love for there to be a way to not even require a wakelock for Caffeinate, but the only other way is a “soft” wakelock, in which you tell Android “Never turn the screen off while my app’s window is open”, but of course that would mean you’d need to keep the actual app window in the foreground and would defeat the whole purpose (such as my favorite usecase, keeping the screen on while I’m reading a recipe - or keeping the screen on while I’m tracking a delivery from a food delivery application).
Dark theming is definitely a fair point, I’ll definitely need to have a look into that.
Material You support is probably going to be out of scope though, as I feel that would be making it complex for the sake of being complex.
I do want to learn more about the Material You API that being said.
Well I definitely am glad to hear that! Yeah the situation is just unfortunate, as there’s really nothing I can do for the users who are getting the issue - since as you’ve seen, Caffeinate is already really light on RAM usage (which would normally be one of the only ways to try to remedy the issue as a developer, from what I can tell).
In the end I just decided to keep it compatible for all mobile devices, though I did consider adding a “compatibility warning” type of banner to the app or a one-time notification for devices that had a small amount of RAM. Eventually the emails stopped coming in about it though so I figured either the problem ended up resolving itself as updates to the platform occurred, or everyone who was going to run into the issue already ran into the issue. I’ve pretty much considered the app to be feature complete now, short of any Android changes that break it (such as when notification channels was introduced, followed by full-on notification runtime permission requirements).
It’s called “Caffeinate” (I’m avoiding posting the direct link just so I don’t break any self promotion rules), I made it in the Android 7 days when the quick settings Tile API came out to replicate the similar tile that was available in CyanogenMod. It ended up getting way more downloads than I ever expected honestly - I just wanted to try the new API haha.
I know that Caffeinate itself doesn’t use up a lot of RAM (the only thing it does when its active is create a persistent notification and creates a wakelock in order to keep the screen active), but perhaps the lower end Samsung device models just have less RAM available, so opening a browser or such kills it.
At the current moment, filtering is an app feature and isn’t built into Lemmy itself unfortunately. Lemmy natively lets you block communities and users, but that’s about it (with instance filtering coming up in the next version).
I published an app on the play store that purely relies on a persistent notification + wakelocks to keep the screen active (since the whole point of the app is to keep the screen awake) - Samsung was definitely the worst when it comes to this for my app, as I would receive endless support emails about people with Samsung devices where it would get killed, even when disabling battery optimization for my app. The other manufacturers listed there came up every now and then, but disabling battery optimization generally did the trick for them.
With there being nothing that I could do for my app, I tried disabling compatibility in the play store for a ton of Samsung models, but then I got even more emails about people wondering why it wasn’t available anymore so I re-enabled it, but to this day there’s still (AFAIK) zero things I can do to prevent the app from getting killed on those devices.
This doesn’t read as a global Blocklist for all Android phones in the world. It reads more as a local database/API for blocked numbers on your phone.
So blocked numbers would theoretically be applied to your messages apps and other “telephony” based apps that use phone numbers such as WhatsApp (should said apps implement the API).
Google already seems to have a spammer database for numbers, though I’m not sure if that applies to just Fi users, Pixel users, or anyone who uses the Google Phone app. If I have call screen disabled, I’ll see numbers on an incoming call have a red background with a “likely spam” description.
But based on the comments on this post, I feel as if I’ve overlooked something in the article here (I’ve just woken up so it wouldn’t surprise me) - is there a mention of it being a worldwide list?