kixik @ kixik @lemmy.ml

Posts

72

Comments

281

Joined

4 yr. ago

The audit is true, but at least Jami didn't make up its own crypto lib, it uses standard already in use crypto stuff. To there's a huge difference there.

BTW, they are actually re-writing stuff... But yes, they need more recent audits...

Have you read it's github front page?

This is an experimental cryptographic network library. It has not been formally audited by an independent third party that specializes in cryptography or cryptanalysis. Use this library at your own risk.

BTW, if you look at its issues (including closed ones, which most probably aren't really closed) you'll find pretty interesting discussions about its crypto not being right. That said, I'm not sure what irungentoo brings to the picture...

At any rate, if you're looking for distributed messaging, I'd look into Jami. It also uses DHT and something similar to torrents mechanism. Jami is my only option so far for distributed messaging. There's also Briar, but I don't like it for regular messaging, particularly on phones (too much battery usage), neither its underlying technology, but if it's to your liking, then that's another option for distributing messaging.

IT might be, but librelinux for example really removes all binary blobs, although there's some tooling around doing that, so new cases might be missed without human inspection, but they are careful about binary blobs... So from the whole spectrum of open source stuff, if you care about binary blobs, chances are better on the libre/free SW side.

Probably Guix, and GNU endorsed distributions. Binary blobs are not allowed on free/libre distributions, or not on their official repos. That said, most gnu + linux distributions don't care about those. Most will take care, if they get to realize it, about distribution licenses, so if something has some sort of legal issue to be distributed, that will get purged from its repos most probably...

:)

BTW, moved to iosevka myself, now my current preferred font for both, the console, and fixed fonts...

Many thanks for the suggestion @toastal@lemmy.ml

I'm not systemd user, and I generally see this absorbing as much as possible as a terrible practice. I don't usually comment on systemd stuff, since I'm happy just not being forced to use it.

However, even though I don't use it, the decision of people managing systemd really affects non systemd users. See by succeeding in getting all major distros into become systemd distros (somehow now governed by RH, if anyone cares), everything systemd absorbs tend to leave alternatives sooner or later deprecated, or abandoned.

Even autofs is no longer part of some official repos, given systemd has its own auto mount/unmount functionality... And there are several other examples...

At any rate, hopefully the more bloated systemd, doesn't make it the more vulnerable. And also hopefully, doesn't make life worse and worse to non systemd distros and users...

BTW, before sudo there was su, so a life without sudo is possible, :)

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