Can shadowsocks-libev come back to ports?

[fmc000]

Thanks, I use Firefox, which drags in Rust. I'll give Librewolf a try.

Nah, same problem with librewolf, I just noticed.

 

[kpedersen]

So you mean, reinvent the wheel so that we don't have to bring a xyz dependency?

What was reinvented by shadowsocks-libev exactly?

Poor argument. Some developers manage to use libraries whilst also being responsible with technical debt. I am assuming you can discern the difference between two dependencies and two hundered dependencies, including to achieve trivial tasks?

I never said it was not a dependency.

Indeed. It was diizzy who stated it multiple times (causing this whole debate).

 

[Phishfry]

When I looked at freshports for "robotics" long desc all the ports were maintained by one person. yuri@ God Bless Him.
I thought to myself how sustainable is it that so many ports are maintained by one person. Quick burnout possible.
So as a maintainer how much time would yuri have to strip out rust and find alternative ways....
He is power producer and don't have time for that nitpicking. Easier to just go with the upstream.(This is just theoretical on my part)
And I understand that's what this argument is about. I am not a programmer but I dislike extra things. Give me bare bones.
But I have not stepped up to the responsibility of port maintainership. I cannot say a word. I take what I can get. I am out of my ballpark or I would be working on it.

But I really want to say thank you to anybody that maintains a port. It is appreciated. I am willing to give rockchip Arm64 boards to any ports developers out there. Just PM me for menu.

Have you done anything special for a ports maintainer? They would probably appreciate some loving.

 

[kpedersen]

to strip out rust and find alternative ways....

Ports for Rust projects are obviously good. I think its just worth keeping an eye on what the cargo cult crusaders artificially "deprecate" and actually remove in favor for their Rust alternative. That is less fine, potentially including when upstream does it.

As mentioned we do have alternatives for shadowsocks currently. But otherwise a good (and easy) alternative would be to reinstate the original port for the (bug-fixed) shadowsocks-libev. If its only for bug-fixes rather than feature changes, then it will be dead easy to maintain the port too.

 

[baaz]

Well this simple thread exploded, so let's go over some points .

First thanks kpedersen net/dante is nice but it is a SOCKS proxy program, ShadowSOCKS is a protocol used to get through firewalls and that is what I currently need .
Sadly there are no ports providing client functionality except for shadowsocks-rust .

Interesting. The deprecation notice says "Abandonware, no active development", but the link they provide in that notice says " Bug-fix-only libev port of shadowsocks", and has a commit this January. I'm no English scholar, but doesn't bug fixing count as active development?

This is exactly my point shadowsocks-libev is still getting bug-fixes, it is not "abandoned" .
Abandoned software brings the concept of "a software without maintainers that has bugs and possibly some discovered security flaws that won't get fixed" to mind .
Also shodowsocks-libev is still used in a ton of clients a predominant example being Outline .

​

On the issue of dependencies:​

I don't think any one with an straight face can tell that everything is all-OK with this ports Makefile, 454 crates for a program with such simple functionality ?
And yes they are absolutely dependencies look at the crates.io page they are listed under the Dependencies section .
Looking at the crates.io page also reveals that most of these dependencies are optional (if not already obvious from the windows_* crates getting dragged in) .
Again somethings like 454 dependencies for a program doing such a simple task are not just a matter of taste and opinion there is something objectively wrong here .

The interesting pattern I recognized in this discussion which is shared among many discussions on the internet that mention Rust is that any sort of criticism of any part of this language's ecosystem, follows an almost religious backlash and defence from the Rust devs .

anti rust propaganda

You are an anti-xyz [optional noun]
You say anti-xyz stuff ...

This is also one of the familiar patterns that comes up when you criticise or point out problems in anything nowdays .

Labeling does not help, kpedersen 's criticism is absolutely valid and I totally agree with him on it.
These types of responses don't establish anything, instead if we see a criticism which we feel is wrong, let's just point the mistakes out .

Also God bless the port maintainers, they are carrying the weight of all the 3rd party packages which is by no means is small, Linux projects with a much bigger community have much worse package quality and availability than FreeBSD .
All I'm requesting is that if possible please bring back the shadowsocks-libev port .

Also as I said in my previous post the 2024 Makefile works perfectly fine, and I managed to install it by just coping the net/shadowsocks-libev folder form the old tree to the new tree, so all I think that is needed is to patch the old files in .

OK just one tiny rant,
Why can't Rust coexist with C, C++ and etc ? Why is there such big push to replace everything under the sun no matter if it is fine in it's current state or not with Rust rewrites ? This all feels backwards to me .

 

[Jose]

This is exactly my point shadowsocks-libev is still getting bug-fixes, it is not "abandoned" .
Abandoned software brings the concept of "a software without maintainers that has bugs and possibly some discovered security flaws that won't get fixed" to mind .
Also shodowsocks-libev is still used in a ton of clients a predominant example being Outline .

You'll have to find someone who is using it, has the time to maintain it, and is willing to do battle with the Rust partisans who will probably fight tooth and nail to prevent the return of this port.

OK just one tiny rant,
Why can't Rust coexist with C, C++ and etc ? Why is there such big push to replace everything under the sun no matter if it is fine in it's current state or not with Rust rewrites ? This all feels backwards to me .

Well the fight is certainly not coming from the C/C++ side.

 

[kpedersen]

ShadowSOCKS is a protocol used to get through firewalls and that is what I currently need .
Sadly there are no ports providing client functionality except for shadowsocks-rust .

Thats a fair point. Some suggestions:

1. Keep using the old FreeBSD port (you can grab it from the repo history). I am fairly certain by the time this fully breaks, someone will have properly forked shadowsocks-libev and then a new port can be made. One disadvantage is you will need to build it yourself for now.
   
   
2. Consider the Go implementation*. Traditionally Go-lang programs tend to have less dependencies than equivalent Rust projects. That seems to be the case here too. Though I do notice that the deprecated -libev implementation seems oddly more maintained than the Golang version looking at the activity.

(* Note: Not to be confused with the much older and abandoned Go implementation)

 

[jbo@]

I had a quick look and in my opinion upstream is not abandonware as already pointed out by kpedersen. I do not understand how "bug-fix-only" equals abandonware.
diizzy Could you elaborate why you deprecated the port?

While new users might be inclined to use the new rust version, I don't see a reason to deprecate and remove a port for a working piece of software that receives bug fixes and doesn't impact the ports tree negatively (i.e. breaks when updating libs/deps).

You'll have to find someone who is using it, has the time to maintain it, and is willing to do battle with the Rust partisans who will probably fight tooth and nail to prevent the return of this port.

OP could pick up the port and maintain it themselves. You don't need to be a ports committer to maintain a port.
Port committers go through the bugzilla PRs and commit the maintainer patches changes accordingly.

 

[diizzy]

How about reading the full commit message and the associated PR? We don't need more stuff that's not maintained upstream and bug fixes does not including keeping it up to date with dependencies.
It for example depends on deprecated libraries such as pcre(1) which is going away for obvious reasons

shadowsocks-libev/configure.ac at v3.3.5 · shadowsocks/shadowsocks-libev

Bug-fix-only libev port of shadowsocks. Future development moved to shadowsocks-rust - shadowsocks/shadowsocks-libev

github.com

 

[Jose]

How about reading the full commit message and the associated PR? We don't need more stuff that's not maintained upstream and bug fixes does not including keeping it up to date with dependencies.
It for example depends on deprecated libraries such as pcre(1) which is going away for obvious reasons

shadowsocks-libev/configure.ac at v3.3.5 · shadowsocks/shadowsocks-libev

Bug-fix-only libev port of shadowsocks. Future development moved to shadowsocks-rust - shadowsocks/shadowsocks-libev

github.com

I did read the bug report and the commit message. Neither mention pcre(3) at all. They say "abandonware" and "hasn't been touched in years" and point at the Github repo as the source for these claims. That repo clearly says "bug fixes only", which is hardly abandonware. There has been a single commit since the port was removed, too.

TL;DR: Jose was wrong and agrees with diizzy.

Unfortunately the PCRE issue looks hairy. There was a pull request for upgrading net/shadowsocks-libev to PCRE2 way back in 2017, but it was never merged or tested. I don't think it's reasonable to include it as a patch to a Freebsd port. The devel/pcre deprecation already looks hairy as Hell, as there are ~800 ports that depend on it. I agree with diizzy, deprecating this port is sadly the right thing to do.

 

[kpedersen]

The devel/pcre deprecation already looks hairy as Hell, as there are ~800 ports that depend on it.

Hmm, as per the pcre site:

new projects should use PCRE2 instead. However, it's still found in various legacy systems and some platforms, including certain services that continue to use the original PCRE for compatibility reasons.

PCRE has no dependencies outside of base, its written in C (the architecture specific code is only for the optional JIT) and in many ways supporting legacy systems is very much a use-case that FreeBSD is going to be doing in the enterprise.

Either way, indeed, updating the upstream shadowsocks-libev project itself *is* out of scope for a port maintainer (didn't spot anything about libpcre in the commit log) though I still feel removing it is premature. I doubt pcre is going away any time soon (as you mentioned 800 dependents) or at least before shadowsocks-libev gets updated.

Besides, the shadowsocks-rust port pulls in dependencies that "hasn't been touched in years" too (byte_string as an example). Sometimes software can just be feature complete.

 

[baaz]

updating the upstream shadowsocks-libev project itself *is* out of scope for a port maintainer

I've forked it

The hard part was the build system, the use of pcre itself was very small in the source .
I've done 0 testing to check if the rule matching still works after the changes, so further tests are needed .

I've attached the diff to the ports tree .

 

[baaz]

Here is the diff, I didn't know .patch files are not allowed !

 

[kpedersen]

Nice! Was considering doing this earlier when Jose pointed towards the earlier (trivial) PCRE2 patch. But you beat me to it!

You could have named your fork "shadowsocks-modern" to ensure good engagement. People tend to like that word and will almost certainly help getting it into various package collections

Good luck, if you do encounter any issues with it, I am happy to try take a look. I honestly can see lots of people preferring this implementation of shadowsocks (less dependencies, more mature, standard build system, etc).

 

[Jose]

I'd worry about the git submodule dependencies it has:

GitHub - shadowsocks/libcork: A simple, easily embeddable cross-platform C library

A simple, easily embeddable cross-platform C library - shadowsocks/libcork

github.com

GitHub - shadowsocks/libbloom: A simple and small bloom filter implementation in plain C.

A simple and small bloom filter implementation in plain C. - shadowsocks/libbloom

github.com

GitHub - shadowsocks/ipset: A small C helper library for storing sets of IPv4 and IPv6 addresses

A small C helper library for storing sets of IPv4 and IPv6 addresses - shadowsocks/ipset

github.com

The first two are stale forks. Getting ports for them accepted into the tree might be a challenge because they haven't had a commit in years, and therefore must be "abandonware"

The last one has diverged somewhat from the repo it was forked from. It's even more likely to get smeared with the abandonware tag 'cause it hasn't had commits in many years.

 

[kpedersen]

The first two are stale forks. Getting ports for them accepted into the tree might be a challenge because they haven't had a commit in years, and therefore must be "abandonware"

The last one has diverged somewhat from the repo it was forked from. It's even more likely to get smeared with the abandonware tag 'cause it hasn't had commits in many years.

If they are 100% portable and aren't used for other software these days, then we could just bring them into the shadowsocks codebase and trivially maintain them. That way people can't whine that they are old. Otherwise it would be like complaining that libregex in nvi is "abandoned".

Its all a mind game. Ultimately twiddling bits can never really be deprecated if someone still needs those specific bits twiddled in a specific way

libbloom is tiny (a single .c/.h file). So is ipset if you strip out all the crap.

libcork is potentially more problematic. It kind of reminds me of that apr, or even that boost cruft. Big "framework" dependencies that cause mass extinction when they fail to port.

1. I'm sure if it was merged with the codebase, unless it is too tangled, we might get lucky and find that only a single function is used from it (developers are so strange like that).
2. shadowsocks-libev isn't massive. How much sodding libcork can it use? It can be refactored.

Perhaps we can look into it if it gets blocked, there are a bunch of solutions basically. Still way less to maintain than an ever mutating shedload of Rust crates.io cruft.

 

[Jose]

Yeah, I'm hoping libcork can be dropped or easily replaced. Looks like its upstream has moved on to other things, and I can't find anything else that depends on it.

 

[baaz]

Yeah, I'm hoping libcork can be dropped or easily replaced. Looks like its upstream has moved on to other things, and I can't find anything else that depends on it.

libcork is used relatively widely in the source,
grep -R "cork" | wc -l
returns 140 .
Most used functions are the doubly linked list functions used throughout the program used for dynamic list purposes .
Maybe making the build system compatible with the original libcork is a better idea .
Sometimes some software just reaches the point where it does its job well enough; than it does not need much more tinkering with ...

 

[Jose]

For the doubly-linked lists you could look at queue(3). I also saw hash tables from Cork in use in manager.c. There's devel/uthash. I know, another external dependency, but OBS Studio depends on it, so it's likely to live a while.

 

[kpedersen]

Not bad ideas. Also, perhaps just the doubly-linked lists part from libcork could be extracted, merged and the rest of the dependency dumped? (If it was untangling stuff from boost, I would give up on that idea right away )

 

[fff2024g]

you can use shadowsocks-rust version. it's good .

 

[kpedersen]

you can use shadowsocks-rust version. it's good .

baaz has made a fork and is looking to refresh the C implementation.
We are currently discussing ways to reduce further some of the remaining dependencies to help make it very maintainable going forward.

The earlier part of the thread is a little tedious but if you read through it, you will see that some of us aren't happy with the large number of dependencies that the Rust implementation pulls in.

 

[Jose]

Not bad ideas. Also, perhaps just the doubly-linked lists part from libcork could be extracted, merged and the rest of the dependency dumped? (If it was untangling stuff from boost, I would give up on that idea right away )

Replacing it doesn't look like a whole lot of work, to be honest. I'll try to find the time to do it and send Baaz a pull request.