My personal preference is to 'ip route add blackhole ${net}' as it has the lowest CPU overhead and I can add hundreds of thousands of CIDR blocks with no noticeable impact. The only downside is that it won't stop UDP packets from getting to a UDP listener. There will not be a response but the application will still see it. For my TCP daemons it's great. grep -m1 -E ^Tot /proc/net/fib_triestat ;ip route | grep -Fc bla…
You could configure reaction to add and remove `ip route` commands in that format.
This monetization scheme benefits the botnet controller and the developer who added the SDK and not the user who likely did not realize they signed up to become an exit node.
It allows as free versions of apps to be economically viable and compete with others. It helps users because they don't need to be spied on and shown ads to fund the development of the app. The existence of an app brings users value, else they wouldn't use it.
I would not have as big of a problem with it if it was a transparent arrangement that the app is free of cost, but the Internet connection would be shared with customers of RoboVPN. The issue is that the often invisible arrangement is not obvious and likely breaks the terms of service with the Internet Service Provider. If the user was intentionally running a TOR node, I would not have a problem with it. The current reality of it is absolutely unethical and breaking the Internet as we know it.
You can, but if the exact quote in the GP is correct the claim is claiming the software is "gay, trans and anti-colonialist" and asks you not to use it. Why use a license that is designed to be politically neutral and then ask some people not to use it? What I can see is a fairly clear indication that they do not want contributions from people whose politics differ from theirs. I would also question whether governmen…
A license designed to be politically neutral? The GPL variants are the antithesis of politically neutral.
Only insofar as political neutrality is interpreted by the modern polarized political factions as a political stance.
The GPL "tolerates" conflicting political opinions, which used to be closer to the norm and thus not political.
When did this occur? I am a GNU maintainer, and have never heard such a thing from the FSF. The GNU Coding Standards and other similar texts leave the decision to support non-free platforms up to the maintainer.
It was an emoji solution for Emacs that only worked on Mac. RMS basically said: "If the point is to promote Free Software, we do ourselves a disservice by making our Free Software work better on a proprietary system than a Free system. Let's include this support when it works on the Free platforms as well." FSF is political, but only about Free Software. Their goal is to promote it, and I think RMS has shown very cle…
FSF is not political in the sense that they won't forbid you to use their software or otherwise blacklist you even if you are against free software, or if you're far left or far right. They are only political in the sense that they have a goal. If that's how you define "political" then the word is somewhat meaningless.
They won't take contributions not aligned with their goals but won't block you from sharing your contributions in the spirit of free software.
My personal preference is to 'ip route add blackhole ${net}' as it has the lowest CPU overhead and I can add hundreds of thousands of CIDR blocks with no noticeable impact. The only downside is that it won't stop UDP packets from getting to a UDP listener. There will not be a response but the application will still see it. For my TCP daemons it's great. grep -m1 -E ^Tot /proc/net/fib_triestat ;ip route | grep -Fc bla…
> The only downside is that it won't stop UDP packets from getting to a UDP listener. There will not be a response but the application will still see it.
It allows as free versions of apps to be economically viable and compete with others. It helps users because they don't need to be spied on and shown ads to fund the development of the app. The existence of an app brings users value, else they wouldn't use it.
Recruiting your users' systems into a botnet is not an acceptable way to make an app "economically viable" any more than, say, installing a rootkit on their systems.
Is Google Maps a botnet because all of the clients share location data to make navigation more optimized? Having multiple users connecting back to a central server does not make something a botnet. Users should be able to decide for themselves whether they want apps like this or not.
It allows as free versions of apps to be economically viable and compete with others. It helps users because they don't need to be spied on and shown ads to fund the development of the app. The existence of an app brings users value, else they wouldn't use it.
the fsf has never really been concerned with commercial viability. They're the worst audience for this sort of argument. and I doubt these apps are really Free versions - do they support user modifications and access to the code? If they did support the four freedoms maybe the fsf would have something positive to say to balance it out?
You are not wrong. The FSF often takes an absolute stance on these things where they don't properly support partial steps towards more free computing.
It allows as free versions of apps to be economically viable and compete with others. It helps users because they don't need to be spied on and shown ads to fund the development of the app. The existence of an app brings users value, else they wouldn't use it.
I would not have as big of a problem with it if it was a transparent arrangement that the app is free of cost, but the Internet connection would be shared with customers of RoboVPN. The issue is that the often invisible arrangement is not obvious and likely breaks the terms of service with the Internet Service Provider. If the user was intentionally running a TOR node, I would not have a problem with it. The current…
I agree that users should be informed, but if parts of the internet are breaking due to user anonymity it is hard for me to feel bad for those sites.
My personal preference is to 'ip route add blackhole ${net}' as it has the lowest CPU overhead and I can add hundreds of thousands of CIDR blocks with no noticeable impact. The only downside is that it won't stop UDP packets from getting to a UDP listener. There will not be a response but the application will still see it. For my TCP daemons it's great. grep -m1 -E ^Tot /proc/net/fib_triestat ;ip route | grep -Fc bla…
My personal preference is to 'ip route add blackhole ${net}' as it has the lowest CPU overhead and I can add hundreds of thousands of CIDR blocks with no noticeable impact. The only downside is that it won't stop UDP packets from getting to a UDP listener. There will not be a response but the application will still see it. For my TCP daemons it's great. grep -m1 -E ^Tot /proc/net/fib_triestat ;ip route | grep -Fc bla…
What does all of this give you? For a static(?) site burning a few cycles unnecessarily, saving what, 30 cents of power per year?
Peace of mind? Fair enough but I'd be more wary about blocking legitimate users. VPS providers are often used for VPNs etc.