Is the project still being maintained?

[marek22k]

Is the project still being maintained?

[gsliepen]

Rumors of my demise have been greatly exaggerated. I currently have very little time to work on it. However, nothing prevents people from sending patches, pull requests and/or forking the project. I think that would be more helpful than archiving the repository.

[gsliepen]

I know there are lots of people liking tinc, and indeed it still has unique features that I don't see in other VPN solutions. But development is very slow, and not just because I myself have little time to spend on it; the last year and a half no other developers have spent much time on it either. And while I do get the occasional pull request, it usually it is just to fix an issue, or to add a feature that one particular person wants, there is no one doing general development anymore. In 2022, @hg did a lot of work, and the project needs someone like them to move forward.

I'll keep looking at pull requests, but I do have some standards, and I also am a bit wary about new features that sound great to the person creating them, but might break other people's setups. If anyone feels that this is too restrictive, and wants to have more control over where tinc is heading, then by all means maintain your own fork, and if that goes demonstrably well we can discuss merging that back into the official repository and/or hand over project ownership.

[josch700]

I think besides the invite feature and maybe performance improvements (if possible) no new features are really necessary.
Maybe work together with a bigger org that would benefit from something like tinc? Proxmox comes to mind, they are working on SDN features as far as I know

[FisHlaBsoMAN]

@gsliepen, if you are still alive, archive the repository or write in readme.txt that you can no longer develop it! If you are captured, blink twice.

[FisHlaBsoMAN]

Is the developer still living?

[FisHlaBsoMAN]

This developer is being forcibly kept by Google. Need a fork!

[ROBERT-MCDOWELL]

I just hope he was not swallowed by the corpofascists!

[lancethepants]

A ton has changed since pre18, including moving to meson. Enough I would think worthy of pre19.

[ROBERT-MCDOWELL]

@gsliepen glad to seen you again! but what about the pull requests waiting since a year?

[fangfufu]

Perhaps I could start maintaining a staging fork with all the patches that people think that are worth merging? Once I collect enough stuff and done sufficient amount of testing, we could consider merging in the main repository?

I don't have the time or skills to do proper development on this project. I definitely love this project though.

If this is something people think might be worthwhile, do let me know. I don't promise anything.

[ROBERT-MCDOWELL]

@fangfufu better to wait @gsliepen answer about the waiting PR and the future of how to continue to maintain tinc.

[rzr]

Or may you consider community cooperative maintenance in @abandonware org ?

https://purl.org/rzr/abandonware

[ROBERT-MCDOWELL]

@rzr abandonware is a good idea, but maybe the name makes confusion since if the software is alive again so it's not considered as abandoned anymore ;). the biggest issue would be where to host and how. IPFS with IPNS (like archive.org) could be a good alternative in case of the source code is abandoned multiple time and if github disappears too or change their rules. the most complex would be to who admin permissions will be given and how long.

[rzr]

ok good to know that project is not abandoned anymore (btw there is also @adoptware for maintained @abandonware projects)

regarding preservation purpose may this project answer to the need:

https://www.softwareheritage.org/

it's not decentralized though

[josch700]

I really think tinc would have a place in the current state of the industry though.
There is a lot of craze about SD-WAN but all those solutions have one Problem, they have a central controller. tinc is pretty alone in this regard and I think it is much easier to use than plain wireshark. So I would love to somehow reignite the spark in tinc because it has great potential IMHO.
Just a quick disclaimer though, I'm not a dev just a admin who really loves tinc and would like to see it being continued. So I can't help with the coding stuff but I would be glad to help with other aspects.

[splitice]

tinc is still great, just really lacking in time from leadership.

If someone wants to step up I'd be happy to send my PRs in your direction.

[fangfufu]

no one doing general development anymore

I guess Tinc works well enough so people aren't too worried?

[Musixal]

Tinc is a good project with unique features, but in my experience it is an unpleasant experience in a network with about 200 active users. High CPU consumption and very low bandwidth compared to similar projects. Tinc performance seems to be the Achilles heel of the project. If I could help, I would definitely do so. Thank You

[st31ny]

Tinc is a good project with unique features, but in my experience it is an unpleasant experience in a network with about 200 active users. High CPU consumption and very low bandwidth compared to similar projects. Tinc performance seems to be the Achilles heel of the project. If I could help, I would definitely do so. Thank You

I can second the performance issues. Indeed, I am running a network with 750 peers and sometimes the network slows down to the point where many connections drop. Maybe #179 could be a huge speedup?

[splitice]

It is possible to make tinc faster without changing the protocol.

I don't have benchmarks to back this, but I have done quite alot of work in this space for other closed source projects.

What can be done to help:

1.1. Multithreading / rxtx scaling (read from tun/tap with multiple threads)
1.2. Multithreading / rxtx scaling (allocate threads to each peer connection)
2. recvmmsg
3. Improved performance of tun/tap through io_uring or similar
4. Merging the AES encryption support

Of course this is largely to optimise the PPS, which in my experience is where Tinc mostly suffers.

Unfortunately the architecture of tinc would need to change to do 1-3 and thats pretty big ask for anyone outside of the project.

I've actually thought about a golang fork of tinc to take advantage of channels and some of the ecosystem. Just really don't have time, or enough need considering the application we currently use tinc for (tinc does not get new responsibilities due to its performance constraints).

Tincs key feature over most of its competition is it's relaying. Even limited as it is in low data rate setups where reliability is important & setups with complex environments this can be really handy.