some linux distributions, such as GoboLinux (which, i think, was mentioned elsewhere in the comments, too), do this.
from gobolinux.org:
> GoboLinux is a modular Linux distribution: it organizes the programs in your system in a new, logical way. Instead of having parts of a program thrown at /usr/bin, other parts at /etc and yet more parts thrown at /usr/share/something/or/another, each program gets its own directory tree, keeping them all neatly separated and allowing you to see everything that's installed in the system and which files belong to which programs in a simple and obvious way.
(in go, "raise an exception" means "return an error.")
error values are meant to represent expected, unsuccessful conditions—internal properties of the program—during the program's execution. for example, looking up the address for a domain name is an operation that can be expected to fail at times, and an error is appropriate here.
errors in go are not meant to represent properties external to the program, such as mistakes by the package author or documented incorrect usage of the package by the package user. in go these are panics.
perhaps other languages use exceptions for both but that conflates.
There are two "kinds" of panics: those initiated by the Go runtime, and those initiated by the program author, though technically there isn't a distinction. When you access an array out of bounds, the Go runtime initiates the panic. On the other hand, for a condition that the program should hold but doesn't, the program author should initiate the panic. For example, in the exhaustive switch below, reaching the default case means that either you have somehow incorrectly allowed the construction of an invalid token value earlier in your program, or you have missed to account for a valid token value in this function.
func (t token) symbol() byte {
switch t {
case add: return '+'
case sub: return '-'
case mul: return '*'
case quo: return '/'
default: panic("unknown token")
}
}
Errors are different. For example, url.Parse returns an error if its input string is an invalidly formatted URL.
I moved from Homebrew to MacPorts on a local, personal-use Intel Mac.
I chose Homebrew some years ago when I was not as experienced a programmer, because it was more popular than MacPorts. When I revisited the choice last year, I chose MacPorts.
On Homebrew:
* It has a Frankenstein permissions model; for example "brew install" writes files into /usr/local/* with your regular user account as the owner of the files.
* The permissions model means that Homebrew-managed parts of the system become a single user system, as far as I know. Multiple user accounts on the same Mac can't easily use Homebrew, as far as I know, and I dislike software with such design choices.
* Noisy messages and undesired colors in the command line output.
These issues are absent in MacPorts. Overall, MacPorts appears more mature and more Unix-like than Homebrew.
The cons of the move are that not all the packages I want are available in MacPorts. However I have sufficient experience now to package crucial missing ones into MacPorts.
I write some paid local-only software, and I have no trouble not tracking users or usage. For example, here's the entire privacy policy for one of them:
> App does not collect any data.
> App works completely on-device. Messages do not leave your iPhone and are not shared with other apps.
> The essence of this privacy policy will not change.
--
For another software, the privacy policy includes details such as:
> App never uses the Internet, except to check for updates.
> Automatic update checks can be turned off in the application's preferences. Requests to check for and to download updates happen only through the domain domain.example. The updates server does not store or forward potentially identifying information, such as request IP addresses or user agent strings.
> License keys, obtained upon purchasing App, do not contain personal information, such as names or email addresses of license holders. License keys are validated locally; App does not use the Internet to validate license keys.
As one of the commenters in the original GitHub discussion pointed out, the package managers of most open source operating systems ultimately will/should package Go with telemetry turned off by default, regardless of the Go project’s default behavior.
Good luck getting non-operating system biased data after that.
Collecting non-operating system biased data seemed to be one of the stated goals to making the telemetry turned on by default. Otherwise it was posited that Go users on open source operating systems would disproportionately choose to keep telemetry off when prompted in an opt-in model.
No, but the go tool/package manager doesn’t necessarily, by default, have to proxy each requested module through Google run servers. It can fetch modules directly from the source.
That said, I don’t think that the go tool’s current behavior in regards to the module proxy server can be considered as phoning home.
The proposed metrics collection however absolutely would be bad phoning home behavior.
from gobolinux.org:
> GoboLinux is a modular Linux distribution: it organizes the programs in your system in a new, logical way. Instead of having parts of a program thrown at /usr/bin, other parts at /etc and yet more parts thrown at /usr/share/something/or/another, each program gets its own directory tree, keeping them all neatly separated and allowing you to see everything that's installed in the system and which files belong to which programs in a simple and obvious way.