Ripcord is excellent but you need to generate a new login token every few weeks. Sucks that these companies like slack and spotify et al. don't just offer the tooling themselves that a subset of their customers clearly want.
> Sucks that these companies like slack and spotify et al. don't just offer the tooling themselves that a subset of their customers clearly want
It would give up control and it's an admission of failure; a slap in the face to some project lead, some designer, some exec, showing that their brilliant ideas were not in fact the superior option for everyone forevermore.
Either of those are unacceptable enough to lock the system down. But both? Never in a million years.
"How do I prevent Ripcord from checking for updates before I'm able to open the preferences window to disable it?
As I recall, shareware never did that. It violates the spirit of leaving the user alone, user automonomy.
Shareware sometimes used to provide a way to check for updates, and sometimes allowed for this to be done automatically. But it generally did not try to make network connections without any permission from the user.
Shareware often used to provide contact information for the author so that users could show their appreciation. Authors invited voluntary feedback.
Today authors instead try to perform telemetry and control the use of the software after download through "automatic updates". They seek to gain from users' laziness to change defaults. They want to collect information about users and their usage habits. "Involuntary feedback."
Anyway, his answer is:
"Set the environment variable RIPCORD_ALLOW_UPDATES=0"
How about starting the program while offline, i.e., network interface down.
> As I recall, shareware never did that. It violates the spirit of leaving the user alone, user automonomy.
Lots of shareware did and does that. It's normal. It's just an update check. It doesn't self-update. It doesn't transmit any information. No logs are collected. It just displays a "update is available" message if it finds that an update is available, with a link to the website to download the new version.
> Today authors instead try to perform telemetry and control the use of the software after download through "automatic updates". They seek to gain from users' laziness to change defaults. They want to collect information about users and their usage habits. "Involuntary feedback."
Ripcord doesn't send any information about the client when it checks for updates. No information is logged on the server. It just fetches from this URL: https://cancel.fm/ripcord/updates/v1
Ripcord does not have any kind of telemetry or analysis system in it. It doesn't even report which OS you're using to the static file HTTP server — the update info URL returns the information for every OS at once.
> How about starting the program while offline, i.e., network interface down.
It works fine if you do that.
> "How do I prevent Ripcord from checking for updates before I'm able to open the preferences window to disable it?
This is provided as a way for users who extra paranoid to turn it off outside of using the normal preferences in Ripcord, since that requires launching Ripcord at least once. It's not the only way to do it. (It'a also useful for package managers on Linux who don't want "update is available" notifications to show up for their users.)
The normal preferences window in Ripcord has a clearly labeled checkbox on the first page for turning update checking off or on. I don't know what alternative there is. If it was off by default, most users would ask why it was off by default and why are they being tricked into being left to use outdated versions. I don't know any software that does this.
"If it was off by default, most users would ask why it was off by default and why are they being tricked into being left to use outdated versions."
What evidence do you have to support this idea? Is there somewhere we can view the feedback from this majority of users who believe they are being "tricked" into using "outdated" versions. I have observed that developers are the ones who are desperate to push "updates", to automatically install new code on the user's computer with no user interaction required. Users who bother to give feedback about software often complain about newer versions being not as good as the old ones. They often question the nature of supposed "improvements".
One of the things some shareware used to do, and software "installers" used to do in general, was to ask the user a series of questions to configure the settings before the first run of the program. I am not suggesting that I prefer that approach, but the idea that someone would purport to believe that setting automatic update checks by default and acceptance of ongoing remotely controlled software installation by default is "the norm" just shows how today's software authors make assumptions, and indeed engage in "trickery" through manipulation of defaults via "dark patterns", that software authors in the past generally did not make.
Thats why a reference to "shareware is coming back" is, IMO, quite funny. Today we have someone claiming he does not consider having an option off by default, and letting the user make the choice, as an alternative: "I do not know what alternative there is." The alternative is to let users turn things on instead of forcing them to turn things off. The "opt out" idea is an "alternative", one adopted by online advertising and the reason the web is such a mess. "Opt out" settings have a purpose and that purpose is not primarily for the users' benefit.
Ripcord is excellent but you need to generate a new login token every few weeks. Sucks that these companies like slack and spotify et al. don't just offer the tooling themselves that a subset of their customers clearly want.
I have not had to do that.
Your organization probably does not use secure sign on then.
> Sucks that these companies like slack and spotify et al. don't just offer the tooling themselves that a subset of their customers clearly want
It would give up control and it's an admission of failure; a slap in the face to some project lead, some designer, some exec, showing that their brilliant ideas were not in fact the superior option for everyone forevermore.
Either of those are unacceptable enough to lock the system down. But both? Never in a million years.
From the Ripcord page:
"Shareware is coming back, baby."
This is quite amusing. Further down:
"How do I prevent Ripcord from checking for updates before I'm able to open the preferences window to disable it?
As I recall, shareware never did that. It violates the spirit of leaving the user alone, user automonomy.
Shareware sometimes used to provide a way to check for updates, and sometimes allowed for this to be done automatically. But it generally did not try to make network connections without any permission from the user.
Shareware often used to provide contact information for the author so that users could show their appreciation. Authors invited voluntary feedback.
Today authors instead try to perform telemetry and control the use of the software after download through "automatic updates". They seek to gain from users' laziness to change defaults. They want to collect information about users and their usage habits. "Involuntary feedback."
Anyway, his answer is:
"Set the environment variable RIPCORD_ALLOW_UPDATES=0"
How about starting the program while offline, i.e., network interface down.
> As I recall, shareware never did that. It violates the spirit of leaving the user alone, user automonomy.
Lots of shareware did and does that. It's normal. It's just an update check. It doesn't self-update. It doesn't transmit any information. No logs are collected. It just displays a "update is available" message if it finds that an update is available, with a link to the website to download the new version.
> Today authors instead try to perform telemetry and control the use of the software after download through "automatic updates". They seek to gain from users' laziness to change defaults. They want to collect information about users and their usage habits. "Involuntary feedback."
Ripcord doesn't send any information about the client when it checks for updates. No information is logged on the server. It just fetches from this URL: https://cancel.fm/ripcord/updates/v1
Ripcord does not have any kind of telemetry or analysis system in it. It doesn't even report which OS you're using to the static file HTTP server — the update info URL returns the information for every OS at once.
> How about starting the program while offline, i.e., network interface down.
It works fine if you do that.
> "How do I prevent Ripcord from checking for updates before I'm able to open the preferences window to disable it?
This is provided as a way for users who extra paranoid to turn it off outside of using the normal preferences in Ripcord, since that requires launching Ripcord at least once. It's not the only way to do it. (It'a also useful for package managers on Linux who don't want "update is available" notifications to show up for their users.)
The normal preferences window in Ripcord has a clearly labeled checkbox on the first page for turning update checking off or on. I don't know what alternative there is. If it was off by default, most users would ask why it was off by default and why are they being tricked into being left to use outdated versions. I don't know any software that does this.
"If it was off by default, most users would ask why it was off by default and why are they being tricked into being left to use outdated versions."
What evidence do you have to support this idea? Is there somewhere we can view the feedback from this majority of users who believe they are being "tricked" into using "outdated" versions. I have observed that developers are the ones who are desperate to push "updates", to automatically install new code on the user's computer with no user interaction required. Users who bother to give feedback about software often complain about newer versions being not as good as the old ones. They often question the nature of supposed "improvements".
One of the things some shareware used to do, and software "installers" used to do in general, was to ask the user a series of questions to configure the settings before the first run of the program. I am not suggesting that I prefer that approach, but the idea that someone would purport to believe that setting automatic update checks by default and acceptance of ongoing remotely controlled software installation by default is "the norm" just shows how today's software authors make assumptions, and indeed engage in "trickery" through manipulation of defaults via "dark patterns", that software authors in the past generally did not make.
Thats why a reference to "shareware is coming back" is, IMO, quite funny. Today we have someone claiming he does not consider having an option off by default, and letting the user make the choice, as an alternative: "I do not know what alternative there is." The alternative is to let users turn things on instead of forcing them to turn things off. The "opt out" idea is an "alternative", one adopted by online advertising and the reason the web is such a mess. "Opt out" settings have a purpose and that purpose is not primarily for the users' benefit.
I have heard that discord is quite active in banning users of alternate clients and even slight CSS tweaks, when they can manage to detect them.