fungos

Money doesn't vote, people vote. Democracy is about people and not amount of money. Example, because one billionaire donates $5millions and 5000 Americans put each $200. Doesn't mean that Canadians care more because $5millions is more than $1million.

I've been using SimpleMail. Seems to have all the same features as FairEmail but without banners and paid Pro-version.

I know about these two, which are made in Rust:

- https://github.com/sit-fyi/issue-tracking

- https://github.com/neithernut/git-dit

Not sure about their activity/status, but they both tried to solve this problem, they may help to widen your evaluations.

I'm impressed and I see potential on this one. I tried different ones over time but most fail at on-boarding. This was seamless and really easy. In about 2 minutes I successfully shared my project and followed known projects. This means this mvp works and it let me craving for more, I want to use this! I want issues and PR support to prove this can effectively work as a github replacement to me.

Now, the downside of this mvp is that there is no project discovery in the client itself. We need to go search for projects in a browser, in this page http://seedling.radicle.xyz/ which is a bit confusing. Considering the client itself is electron, it could at least, open this page for us somewhere. Or, we could at least have a less "noisy" seedling page focused on search and I would not even know it wasn't part of the client itself.

Overall, awesome project. I really hope it will grow and add the missing essential features. If I could vote, with priority these would be:

- project discovery integrated in the client - issues support - pr support - multiple identities

Anyway, great job!

At first I thought it was broken as I opened in mobile and it was very confusing. Otherwise, on desktop it looks funky, but fine - not awesome but not bad.

> I dont know why youre getting downvoted, the latin-rich terminology in medicine is pompous and unnecessary.

C'mon! This may seems true for english speakers and non-romance languages. But I as a non-english native speaker, can say exactly the same about CS terminology! It is just too pompous and unnecessary, as it will in almost any other non-germanic/anglic language.

Very nice, but can you enable video controls?

Nice to know, so they can happily charge 95% from your app?

Right. _they_ were not meant to be Wiki.js, but ANY open source project. And was a meant to indicate the same subject as _any_ in this reply:

> I don't think _any_ of the mainstream open-source licenses allow you to retroactively revoke or change the license.

My reply is in this context, not in the parent's parent which you mean as _relevant_ context. If I wanted to include the parent context the reply would be more specific. This was a direct reply to a specific message. This is a very normal way to reply on the internet, HN is not special.

Not sure why I'm getting downvoted, but this does not change the fact that yes, licenses can be changed. You disliking it does not make it wrong.

Read better, I'm not replying to him. I agree with him.

If they are the sole copyright owners (no external contribution) or have SLAs, they can for any future version of the software. It is not uncommon, it is just hard as most doesn't have SLA to do this.

These company make changes to Atlassian code? You're conflating internal or public use with derivative work or service offering. You clearly misunderstand licensing.

For future versions, not past versions.

Google plans to add ANGLE support for Metal backend. Once that backend is done (and even the Fuchsia support), ANGLE will continue to be an extremely viable option.

The delay of having a Metal backend may have been the reason they're deciding to ditch it, but is nonetheless sad.

Another future option will be WebGPU, once this is mainstream what Digia will do with Qt7? Drop everything again?

Since Digia put their hands on Qt, it is slowly going downhill.

Flutter: yay!

Snap: nope!

Anyway, hopefully this will cause a push for flutter support on other distros that are snap free.

This is useful.. to someone. They are just collecting a lot of passport information.

there is also kdialog

The type safety of my sample is based on the auto deduction of the types at compile time.

You can see somewhere there I do this:

  return std::move(ArgsResult Ok(options));

I could also have done:

  ArgsResult func() { ... return Ok(options); }

In this example there are two instantiations of the type Result<T, E>:

  typedef Result<ProgramOptions, Error> ArgsResult;
  typedef Result<bool, Error> ProgramResult;

(Note that the typedefs aren't needed, but I prefer to be explicit there.)

The try macro is just trying to emulate try! and it is not really needed. We may access the result by hand and the correct type will be used, but it is way uglier (see: https://github.com/fungos/sllab/blob/master/src/viewer.cpp#L...) due the access on the struct members .e (error) or .v (value). And if I try to assign .v to another type, the compiler will give a compile time error.

And probably would be better to use std::variant there as it is more like a tagged union, I just haven't tried to improve on it anymore.

Also, note that my unwrap doesn't panic, I should put a test/assert there...

Anyway, the poc is there and it should possible to have something almost as clean as Rust with some more work.

Just for fun, really, I've done a Result impl in my lab code[1]. I'm willing to improve it just to see how far I can get with it. :)

The next improvements will be custom error types (I had it done but reverted in this code) and a error_chain like feature (started testing and forgot to remove some not working code there).

[1] https://github.com/fungos/sllab/blob/master/src/viewer.cpp#L...

Even by solving safety, erros in software will still happen. The software errors cited are much more about bad engineering, something that can't be solved by safety only.

Benchmark GAME :)

You're so wrong that is laughably.

That laughably hashing functions are highly specialized implementations for a proposed problem. There is NO MORAL there.

I code C for living and if we can use "laughably hashing functions" to gain performance we WILL DO.

But people are criticizing C because the way it is implemented is not "realistic". Or that the "hash" is a hack that will never work in real life.

I don't know the background of these people, but they couldn't be more wrong. So that looks like "morals" or just they don't ever saw real C code out there.