l2dy

https://github.com/tummychow/git-absorb

client.jar searches the entire filesystem for files that look like mod JARs, and infects them with Stage0. This includes entire Gradle and Maven caches, as well as tons of things mod devs would likely never think to check. The potential scale and scope of this infection has gone from “a couple weird mods” to potentially infinite.

Edit: It's even stripped on HN!

I still use calendar and reminder apps for one-off and time-sensitive tasks, but for recurring tasks, especially those with complex timing, the crontab syntax integrated into the bot is more powerful and easier to maintain.

Beware that this polyglot feature you've mentioned is not moving to OpenJDK.

Source: https://www.zhihu.com/question/66719537/answer/245270169 (in Chinese)

The Homebrew package registry is fresher but not bigger than MacPorts. 5901 packages in homebrew-core versus about 11000 ports in MacPorts (not counting subports).

Package freshness depends on contributions. A bigger collection is inherently harder to maintain, yet MacPorts has fewer active contributors than Homebrew.

> It also supports GUI apps

MacPorts doesn't have a separate cask-like feature, but there are some GUI apps in the aqua category, most of which are built from source with binary cache.

If you need to manage proprietary and/or binary GUI apps with a package manager, you could still use Homebrew casks for that and MacPorts for everything else.

For macOS on Intel, MacPorts does not play well with Homebrew because it took /usr/local, so ports built from source might use Homebrew files and break.

MacPorts uses GitHub too now. We maintain much more ports than Homebrew, and few of our committers have time to regularly go through the PR queue, so our community seems inactive. But actually, we just need more hands on PR management.

One important distinction is that most active ports in MacPorts have specific maintainers, and we usually put off merging PRs until the port maintainer approves. With more than 20,000 ports, it hard for the committers to test every change thoroughly, so we rely on our port maintainers to resolve issues and review complex PRs whenever possible.

In Homebrew, any maintainer could review and merge a PR instantly, combined with fewer ports to maintain, average time to merge would be much shorter.

BearSSL is still beta-quality, s2n has not reached 1.0 (weekly releases are likely to break things), and BoringSSL has no guarantees of API or ABI stability.

* Debranding is much more work than a single RPM. https://wiki.centos.org/About/Building_8

    No you can't just "sed s'/Red Hat/CentOS/' (someone always offers that)
    There are times when you do replace and times when you don't.

> We only ask for personal information when we truly need it to provide a service to you. We collect it by fair and lawful means, with your knowledge and consent. We also let you know why we’re collecting it and how it will be used.

Be specific on this in your privacy policy. What information do you collect?

> The MacPorts installer pkg will need to be submitted, but I don't think much else will change. Using MacPorts-built kernel extensions is already impossible because of signing requirements (we don't have a kext signing certificate and I don't think we qualify for one.)

> For general apps, Gatekeeper doesn't prevent running locally built ones due to them being unsigned, and I gather than notarization is only required in the same circumstances as signing. (It would be incredibly inconvenient for developers to test anything if this were not the case.)

https://lists.macports.org/pipermail/macports-dev/2019-Septe...

> * For 10.14 users: The pkg meets Apple's new requirements for notarization. This includes enabling the hardened runtime for all executables, which has the potential to cause new issues due to denying access to certain system resources and preventing the loading of unsigned plugins. Please let us know about any such problems.

MacPorts .pkg installers are notarized since 2.6.0.

This article convinced me about the conflict: https://people.gnome.org/~markmc/openssl-and-the-gpl.html.

The OpenSSL license imposes certain restrictions on people wishing to distribute their program using OpenSSL, while the GPL-2.0 license says you may not impose any further restrictions when you redistribute the program. There is an exception for OS components, but MacPorts is not part of macOS.

Maybe the port is not distributable, I've listed several situations in the parent comment where ports would be built from source, if none applies in your case you can ask on the macports-dev mailing list posting the output of port -v install [port].

> provided the maintainer policy allows it

We welcome any pull requests, the maintainer policy is for committers merging PRs.

> I am curious about new ports, though: what is the policy on these? Should we aim to "mirror" packages that homebrew/core adds?

Generally, any open-source software can be added to MacPorts. Feel free to add software Homebrew provides, but don't limit yourself to that :)

> Does MacPorts have any equivalent for Homebrew's Caskroom?

No, but you can use a custom ports tree (https://guide.macports.org/#development.local-repositories). In some cases (e.g. OpenJDK) we would repack binaries, but we prefer building ports from source (on our Buildbot or during install if binaries are not distributable).

We could discuss this on macports-dev. Creating a repository on GitHub and writing (un)install instructions is all we need to get started.

> https://trac.macports.org/ticket/57950

Our Trac tickets are somewhat neglected, please post on macports-dev if no one responds. If the change is simple, you can also make a pull request which is easier to review and merge.

> has there been any work done on making this migration between OS versions less jarring?

Yes, but the PR is stalled for now (lack of manpower again). https://github.com/macports/macports-base/pull/56

I haven't experienced these issues myself because I would always reinstall MacPorts after a major macOS upgrade.

> MacPorts almost always builds packages from source

Many packages in MacPorts (including LLVM) have pre-built binaries available from https://packages.macports.org/ and its mirrors for macOS releases ranging from Mac OS X 10.5 to macOS 10.14.

But if a port is considered not distributable because of its restrictive license or license conflicts with dependencies, binaries will not be uploaded to our official mirror so users have to build it from source. We don't provide official binaries for non-default variants or alternative prefix (the default is /opt/local) either, but organizations using MacPorts can set up private mirrors with custom ports and binaries.

port_binary_distributable.tcl[1] describes the license conflicts. e.g. "git" is not distributable because its license "gpl" conflicts with license "OpenSSL" of dependency "openssl".

> MacPorts seems to be a bit lacking in manpower (which makes things takes slightly longer than I would have expected)

Yes, we need more contributors and committers to maintain the large collection of ports we have. Our ports are more often outdated than Homebrew because of this and our maintainer policy. We are also seeking for ways to improve our developer experience, e.g. https://github.com/macports/macports-base/pull/120 which automates updating checksums in the Portfile.

> The lack of color, as well as somewhat more cluttered and less relevant output, makes it a bit less pleasant to work with.

We talked about this in a meeting last year, but it hasn't been implemented yet. https://trac.macports.org/wiki/Meetings/MacPortsMeeting2018/...

Development of the port command is relatively inactive (severe lack of manpower). https://github.com/macports/macports-base/commits/master

> MacPorts will set up its own tools in isolation from those provided by the system

Its own versions of libraries, to be exact. See https://trac.macports.org/wiki/FAQ#syslibs for more background on this.

> builds run in “sandboxes” under the macports user, where attempts to access files outside of the build directory–which includes system tools–are intercepted and blocked

It will block writing files outside of directories specified in portsandbox.tcl[2], but using (reading and executing) system tools is allowed. For example, most ports are built with the compiler from Xcode.

> The upside is that this approach is significantly more contained, which makes it easier to manage and more likely to continue working as macOS changes under it.

Yes, but we recommend users upgrading to a new major release of macOS reinstall MacPorts and all ports because things could still break. We have a migration guide here: https://trac.macports.org/wiki/Migration.

[1] https://github.com/macports/macports-infrastructure/blob/mas...

[2] https://github.com/macports/macports-base/blob/master/src/po...

According to https://en.wikipedia.org/wiki/Firefox, it's released under MPL. But sure it's more restrictive than most code in Chromium.