Agreed, but my point is with a centralized network the lowest common denominator wins. There is no reason you can’t have QoL features on an open network, and thusly let everyone have the features that they care most about.

Can you imagine what a shithole the internet would have been if email wasn’t federated an open? There is absolutely no way that whatever centralized bullshit would have spawned instead would already be either long gone or enshittified to the point of being useless.

Good for you, you have a short list of requirements out of a chat service and discord perfectly fills your niche. But different people have different requirements for chat, and they don’t align. And network effects force people who have differing requirements to use the service with the most users which sucks.

For instance here are things that I require from any chat service that I use that discord completely falls flat at:

• Ability to run it on my linux machine without using an electron client (npm is a huge mess of supply chain attacks and I refuse to run any software that is likely to contain dependencies from it)
• Ability to run it on my AOSP phone which does not have any google play services installed
• Ability to write software to back up messages without fear of a company changing their API and breaking my backup system

While I agree that first party systems suck, as someone with neither an iOS or Android device I personally prefer something work rather than a screen that says “connect iOS/Android”.

Yeah I’ve played with git-issue and agree it’s not ideal. Have you checked out Sourcehut? It is entirely email based but with some pretty great tooling around it to make it more accessible.

I agree that in a perfect world we have a separate open protocol for all of the non-repository related workflows/data, that has all the features we need. But the nice thing about email is it’s decentralized, and everyone already has it. And in my opinion, with the right tooling built around it, it can get pretty close to the same quality of life as a github PR, but also degrade gracefully without it.

The problem isn’t the version control itself. Obviously git continues to function and I can commit things offline in a plane. What I can’t do is create/review PRs or read/open issues. That’s easy to brush off, but the most egregious thing is the fact that this used to be federated over email!

All we needed was more user-friendly tooling to make it easier for new college grads to start contributing to FLOSS, but instead of better email based tooling we got the centralized trash that github is today.

Yeah, sort of. I probably didn’t explain super well, and also probably don’t fully understand the problem so here are some code snippets that might make things more concrete and you can tell me where my asumptions of your codebase are wrong

So first off we have what I assume you were suggesting with multiple options for the individual db props. I commented where things are painful and bug prone:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2ecb08dd5d54378c693a7014599e8645

If Option is indeed the aproach you want to take we can solve a lot of these problems by moving all the fields that go optional together into a separate struct:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9eb2f896e171507acb64283d5b530673

We get even more type safety and clarity by making them separate types (and have ArmyWithDbProps wrap Army):

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c2e33aa1c09538ffdbe0cd440bbff3e1

Or we could use Into if it’s not appropriate for process_army_from_db to turn an ArmyWithDbProps into an Army:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f82043935625572cb08c240f23944f0e

Also this last example is using clone when if this is in-fact the direction you want to go we could be using pointers to avoid unnecessary clones. Let me know if this is the case and I can write a version with pointers and lifetimes.

I’m sure we’ve missed something here specific to your software (obviously the above links are all trivial examples), but I just wanted to help clarify my original point with some concrete code. If you can share some of your code we might be able to give you more specific advice.

There’s no way of knowing, which is the whole problem with their model and why a lot of us self host things in the first place. Even if they super duper promise not to use the data, they could be lying. And if they are actually true to their word today, that could change tomorrow.

I haven’t used any flatpacks, mostly because they don’t seem to have a good solution for running terminal programs. (Also I don’t like that the application developer chooses the permissions to expose rather than the user.

However, I have been using bubblewrap which is what flatpack uses under the hood to sandbox. This allows me to run both gui and non-gui programs, and I have the control of exposing the minimum required permissions that I’m comfortable giving an untrusted piece of software.

I seem to be in the minority here but I personally prefer using $ and # to denote root. I like this because not everyone uses sudo and might not even have it installed.

That being said, if you already have other commands that are using sudo -u ... to run commands as a different user then it might be best to just be consistent and prefix everything with it, but if there is only a few of those maybe a # cp foo bar && chown www-data bar is an alternative.

Rust has a strong emphasis on strongly typing constraints. So if a collection of fields are always some/none together having them listed as separate options in the struct means there is some assumptions you are making that the type system isn’t aware of which can lead to pain and bugs in the future.

I agree that separate types with Into sounds like a nice solution to me, it would be good to see the error the compiler is giving you (or if you can a minimal reproducible repo). If you absolutely can’t make it work, a single Option<Inner> at least would be more correct as all the fields on the inner struct would be optional together.

it has a nice working sync of connection profiles (even of ssh keys…encrypted!)

Sorry, but what on earth does this have to do with a terminal emulator? Something like this makes way more sense as a separate tool. It’s like if I was making a decision of what video player to use because it can sync my browser bookmarks.

The way I remember the order is that the parentheses around the link would make grammatical sense outside of markdown (the goal of markdown is to still be fully readable even when looking at the raw source).

For example if I were posting on a forum that didn’t have markdown support which one of these would make more sense:

1. You can find that on this lemmy instance (https://lemmy.world).
2. You can find that on (this lemmy instance) https://lemmy.world.

Option 2 makes no sense grammatically. Then you just need to use the square brackets (which rarely show up in non-markdown text) to denote the link range.

Alternatively, if you still have a hard time remembering the order, you can use reference-style links which make it even more readable outside of markdown rendered contexts (note that there are no parentheses in this version, nothing to get confused):

[Here is a link][1] and [here is another link][2].

[1]: http://example.org
[2]: http://example.com

Yes, it uses the Linux kernel, but usually when people are talking about running Linux on their mobile they’re talking about running GNU/Linux, which is way more free (as in freedom) than any android garbage is. For example it is impossible for me to run arbitrary POSIX compliant shell scripts on an android phone.