Can shadowsocks-libev come back to ports?

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).
 
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.
 
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.
 
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 .
 
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.
 
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)
 
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.
 
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
 
Back
Top