nishs

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.

is lack of privacy your issue with the "your stars" page? consider a bookmarks manager.

what specifically do you find interesting in these technologies?

go package: https://pkg.go.dev/golang.org/x/tools/txtar

swift: https://github.com/littleroot/Txtar

by namespace do you roughly mean package?

complementary openbsd resource:

https://man.openbsd.org/hier

some differences:

* openbsd does not use a /boot/ partition. instead it uses the bsd.* files in root.

* no /proc/ in its entirety in openbsd. use sysctl(3) instead.

* current openbsd does not have a separate /var/tmp/; it is a symbolic link to /tmp/.

(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.

  package url
  func Parse(rawURL string) (*URL, error)

(2017)

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.

fuck every idiot who made those comments or memes without any understanding of the incredible work done by the mantainer.

reading release notes for upgrades is the only correct way.

regardless i think we should hold open source projects to higher standards, such that telemetry isn’t introduced by default.

That's an overarching claim.

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.

If you wish, you can ensure that the compilation step in particular doesn't need/use the network, by first manually fetching the dependencies:

  someproject% go get ./...     # or 'go mod download'

Next disable network access for the go command, or for the whole system.

Then compile:

  someproject% go build

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.

Thank you for explaining. I see the issues.

don't know why. but it's publicly viewable from a private browser window for me.

No need to disparage Reddit, either. :)

What other modes of distribution are there that are neither source nor binary? I can't think of any. But I see the overall issue.

Thank you.

vetting, and dependency locking, addresses nearly all the issues. there's one other issue: the ability to easily adjust the code as you see fit, so it is vital that you are able to precisely control the code.

related reply: https://news.ycombinator.com/item?id=34740666

A negative for the ISC license: there has been controversy about "and/or" vs. "and" wording in the ISC license text. [1]

The OpenBSD project uses the "and" wording, whereas the license text on the OSI website uses the "and/or" wording.

Given all this, it seems to me that recommending the 2-clause BSD is the most straightforward option, because its only (and innocuous) issue is that it contains some no-longer-necessary language after the Berne convention agreements.

[1] From Wikipedia: When initially released, the license did not include the term "and/or", which was changed from "and" by ISC in 2007. Paul Vixie stated on the BIND mailing list that the ISC license started using the term "and/or" to avoid controversy similar to the events surrounding the University of Washington's refusal to allow distribution of the Pine email software.

> copy a function with its closure

By closure, do you mean the values of free variables at the time of the copy?

If so, the inability to do a perfect copy is applicable to regular functions at the top level, too. (For such functions, other global variables are free variables.)

Considering this, I think this is why copying a function is generally defined as just having a reference to the function that can later be used to invoke it. It does not include each copy of the function having its own copy of the function's free variables from the instant of the copy. Separate invocations of the multiple copies (i.e. references) of the function may affect the shared closure environment/free variables.

s/React/Redux? (for example)

With setState in React, you don't necessarily have to copy to update the state. setState merges the partial object you provide with the current state.

https://reactjs.org/docs/state-and-lifecycle.html#state-upda...

In Redux reducers, however, you need a full copy.

Could you expand on this, please?

I've also seen the Dhall configuration language (https://dhall-lang.org/) mentioned.

Does anyone know which parts in the 2-clause BSD license were made unnecessary by the Berne convention?

Also worth noting that the page says:

> The above observations regarding moral rights imply that putting code under an ISC or two-clause BSD license essentially makes the code as free as it can possibly get.

Emphasis on: or two-clause BSD license.

That said, the ultimate recommendation on the page is ISC, but only because:

> The ISC copyright is functionally equivalent to a two-term BSD copyright with language removed that is made unnecessary by the Berne convention.

Yes, sorry, I realized this only later.

And it doesn't make sense to me either.