devraza @ devraza @lemmy.ml

Programming, cybersecurity, privacy, self-hosting, and some other stuff.

---

Read more

Posts

6

Comments

50

Joined

2 yr. ago

Very nice, this comes with a lot of advantages for Hyprland, and I wholeheartedly congratulate Vaxry on separating from the rubbish that is FDO's management.

Wouldn't just using a temporary phone number service work? From what I remember, you just need to recieve a text message and put it into Signal during registration. From skimming through the post, there's no mention of this option.

I would agree somewhat, except I think Bitwarden verifiably doesn't store unencrypted password data. Of course, I think that a self-hosted solution is pretty much always more secure than one that isn't, but the convenience Bitwarden provides is real.

You could host on Gitea and mirror to GitHub. Obviously, users may be less inclined to sign up to your Gitea instance, but I hope people being unwilling to register becomes less of an issue once Forgejo (Gitea fork) implements forge federation.

I hope this changes (even if a little bit) once Forgejo (FLOSS Gitea fork) adds forge federation.

I'm not sure - conduwuit does seem to have more active development but it's not as though conduit is dead either...I also can't find any other reasons to use conduwuit mentioned on its repository, so I'm just going to stick to conduit.

I’ve been using Conduit within a docker container for a while now, and it’s worked pretty well aside from the mautrix-signal bridge (this was fixed in version v7.0.0, I think). Other than conduit, I tried out dendrite, but the latency in sending messages was unbearable.

I’ve previously had issues with Matrix being incredibly slow and unreliable with federation (I’m self-hosting). However, that’s pretty much in the past now and I seem to have somehow resolved that issue.

I’d just like to add that you can use a temporary phone number service to sign up to Signal as you only need a phone number to register, not to actually use Signal.

I don't get i-

...

Or you can use a doas implementation like OpenDoas, or maybe sudo-rs...

But the US can control US based companies, and create laws regarding how that data is used

Does that matter if they don't create said laws - since they're equally interested in their citizens data as facebook, google, etc. are?

This is a pretty good option, though I also think something like what aseprite has done is pretty good too (compile it yourself for free, or pay for a precompiled binary available through e.g. Steam) - from what I can tell this setup is fairly profitable.

KVM runs VMs pretty much like they are native

Well, it is a type 1 hypervisor…

Well, I’m not sure how many lines of C rm is written in but I think that rm being only around 4kb (iirc) is something to consider.

But still, storage probably matters least in this day and age. Oh, and…

something I used to completely nuke my home server

If I’m reading this right, then I hope you had backups ready :)

Absolutely.

Well, in all seriousness, I don’t think so. But I do think that Rust rewrites are generally good since they usually end up producing a higher-quality program which is significantly faster (this is pretty important to me).

Of course, there’s no point rewriting everything in Rust, since Rust’s benefits obviously don’t apply to anything.

I think one of the best things about Rust is that it can be used to write basically anything (at least, this is what the extent of the Rust ecosystem leads me to believe), from web apps and CLI tools to, I don’t know, kernels. That’s probably why there are so many Rust rewrites. People actually do write a variety of programs in Rust, and from what I can tell said variety is way bigger than in most other languages.

Nah, no way. :)

This probably isn't the answer you're looking for, but vpr being memory-safe isn't a benefit that it has over rm, since rm apparently doesn't allocate any memory (as @radiant_bloom@lemm.ee wrote).

the first thing you mentioned as a benefit was memory safety.

Looks like I worded my project description poorly. As I wrote in another comment, I meant that this alternative is memory-safe (being written in safe Rust), but not that rm isn't.

edit: I've updated the post's title to clear things up

I guess vpr -x would be memory-safe that way then. ;)

I don't know whether rm is memory-safe or not, but vpr is. By 'memory-safe alternative' I meant that this alternative is memory-safe, but not that rm isn't.