I’m all for Jami, and XMPP.

Jami is the GNU alternative, if you’re wondering

Uff, somehow missed your post. See mine. That’s the FS I’m hoping to use next. I’m waiting for it to support swapfile, or alternatively read from official sources they won’t ever support it, :). But yes, that’s the one I’m looking forward to use.

How about bcachefs. I’m waiting for it to support swapfiles, which seems to be in the TODO list, but so far doesn’t work. If you use swap partition[s], or prefer not to have swap at all (I never fell for this, and besides swap is required for hibernation if that’s a thing for you), then bcachefs is ready for you. It’s already part of linux since 6.7, and on Artix, current linux is 6.8.9…

To me is the FS to use. I’m still on luks + ext4 (no LVM) and do entire home backups with plain rsync to an external device. I’d have to learn new stuff, since ext4 is really basic and easy to configure if in need, but I think bcachefs is worth it, and as mentioned, just waiting for it to support swapfiles, :)

https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-23h2 https://www.bleepingcomputer.com/news/microsoft/microsoft-says-april-windows-updates-break-vpn-connections

Perhaps click bait, but based on MS’ own list of issues with April’s upgrade patchset.

Also FYI: https://lemmy.ml/c/xmpp@slrpnk.net

and Guix

yes

They don’t run by themselves, they need a terminal emulator, or a console, underneath, so they can work. You can actually call screen on a console without graphical environment, and it’ll provide the console all benefits of multiplexing. That doesn’t make the multiplexer a terminal emulator by itself.

So, in my mind no, screen is not a terminal emulator, alacritty is, like xterm is, and so on. The multiplexor just adds extra capabilities to the terminal emulator.

At any rate, it’s not worth going any further. What I meant is that neofetch was able to find out and show I’m using alacritty, whereas fastfetch doesn’t show alacritty. And we can argue about the virtue of one or the other, but it’ll boil down to taste. I prefer how neofetch shows alacritty, hehe. Some might prefer fastfetch showing screen. And most importantly, this is not critical at all.

There’s an issue on fastfetch filed about it, and one of the devs indicated when using the screen multiplexer, they could find out the terminal emulator underneath, however they couldn’t do the same with tmux. And to be consistent among multiplexers, they decided not to expose the terminal emulator underneath when using multiplexers, just show the multiplexer. I don’t agree with that argument, but it’s the dev right to choose to do that.

Greetings !

No, screen is a terminal multiplexer, like tmux. The terminal emulator I use is alacritty.

But neofetch tells you if wayland already:

WM: Wayfire (Wayland)

Actually while neofetch detects pretty well I’m using alacritty:

Terminal: alacritty

Probably they learned $TERM is really meaningless if using screen or tmux, but fastfetch totally misses this and mistakenly shows screen as the terminal:

Terminal: screen

The only thing I like of fastfetch over neofetch is that it’s faster, :) And yes the display missing, but I’ve never considered that something of much interest for such output… To me neofetch is just fine, and on terminal it gives you a more accurate answer… In the end is a matter of taste… But what it does is well done, :)

https://pine64.org/devices/pinetab2

https://pine64.org/devices/pinetab-v

For the tinkerers of course

I would recommend using apkupdater for closed source apks, in particular enabling apkpure repo, rather than insisting on using google repo with aurora store or any other mechanism.

Also looking for FLOSS alternatives if possile (granted things like whatsapp and waze won’t have alternatives for example).

Some metioned apkmirror as the more trusted repo for closed source apps, however it’s currently formatting apks on multiple apks, and supposedly requesting for the apkmirror own instaler, so I recommend apkpure instead, which is also pretty well regarded, and they also in theory offer the same packages as the ones on google play…

For FLOSS apps, the different f-droid repos (official ones and non official ones such as izzy-on-droid) offer a good amount of them.

I see. And I do like CSD over SSD, :)

The alacritty decorations are just plain simple GTK bar, so you’ll see the simple regular GTK bar for applications not embedding CSDs withing the apps same one on electron apps (signal-desktop, slack-electron, and so on) get. In the case of a terminal emulator that’s understandable, it needs the space… I was trying to paste a snapshot, or attach a simple image here, but didn’t find how to, and I won’t do any sort of patebin right now. So I don’t consider that simple bar, nice decorations, but they do what they’re meant to, so that’s fine for me. I guess it look better on gnome though. I use wayfire + waybar + …, and GTK apps work pretty well there, and I have installed and currently use materia dark theme, and the look is good in general for me. As I don’t like kitty, I really don’t remember how worse it is in comparison, but I still consider alacritty bar not so impressive, hehe.

I use it, but on wayfire, because I like it more than kitty, though I have to use alacritty with screen, since it doesn’t support tabs, which is the only thing I wish alacritty would add, but I can deal with screen OK. What do you mean with window decorations? They look pretty normal to me, like the ones on electron apps now a days…

deleted by creator

XMPP, 🙂

The phone doesn’t poll, instead it goes to sleep, and gets awakened by the push notifications. Just like GCM/FCM ones. Part of the key thing, because not any one can self host, is that it requires very little information in comparison, and some providers are open source and even free SW. The one I use is ntfy, there’s the next cloud (next push), and not long ago you can use the conversation push service (up.conversation.im) through the Convesations xmpp client. I was aware of Conversations capable of becoming a unified push distributor, but actually was looking for it to use a unified push distributor instead.

But I was informed already it’s not necessary, and doesn’t make much sense, by being very low power consumer, even though it requires to keep unrestricted battery consumption on the background. So no issues by Conversations not supporting using a unified push notifications distributor.

I see. Thanks for clarifying.

ohhh, I see. Many thanks !