21 ms·

Goodbye Mac OS Forge, hello GitHub

184 points by sashk 10y ago

CraftThatBlock 10y ago
This is long overdue. Google slowly been doing the same with moving from Google Code (which was supposed to be dead? It is though?) to GitHub, but a little progression is better than no progression.
- LukeShu 10y ago
  Google Code the public service is dead. They still have internal, but publicly visible, hosting for things like Android and Chromium; which they seem to be rebranding as Google Source, or at least using the googlesource.com domain.
deleted 10y ago
[deleted]
GirlsCanCode 10y ago
Goodbye Macports then. Can't we have code hosted on a politically neutral platform?
falcolas 10y ago
With all of the - I'd call them shenanigans, but I'm sure they're justifiable features [0] to someone - with homebrew, it may be time to take a closer look at macports as a replacement. Glad to see the project not only alive, but evolving with the community. [0] Like automatically running `brew update` with every brew command run. I was literally wondering if my computer had frozen up again when I saw that it had done a full update (which involves not only patching the brew code, but updating its source repos) before installing a pre-compiled version of tmux.
- ploxiln 10y ago
  Yeah, that one surprised me too recently. But most of the junk can be disabled. My current settings: $ env | grep HOMEBREW HOMEBREW_BUILD_FROM_SOURCE=1 HOMEBREW_NO_AUTO_UPDATE=1 HOMEBREW_NO_EMOJI=1
  - jordigh 10y ago
    Can you disable all of its cutesy names? Bottles for binaries, cellar for package path, taps for 3rd party repos, recipe (or formula? I forget) for build scripts, cask for a REPL... I honestly got a bit confused at first by what all of these things meant.
    - Mister_Snuggles 10y ago
      This is why I use MacPorts.
    - CookieMon 10y ago
      This habbit of programmers to name things with puns instead of descriptively drives me batty. WiX is bad, but Homebrew is on a whole new level. Each time I use a mac I have to relearn what a tap represents vs cask vs brew vs celler etc. But hey, aren't they clever with words!
      - Washuu 10y ago
        Those clever words immediately made sense to me for their inherent meanings the first time I saw them. So they are actually quite useful in their pairings.
        rbanffy 10y ago
        I love puns just like everyone else, but when you have a word that precisely describes the thing you have, why not use it instead of using a clever metaphor?
        Terretta 10y ago
        Like programs for Pages, Numbers, Keynote, Photos, Notes...?
        sitkack 10y ago
- busterarm 10y ago
  I'd like to see pkgsrc take off as the big Homebrew alternative.
  - daenney 10y ago
    That, or nix. Unfortunately the state of Darwin/OS X on nix has declined over the last year or so.
    - ymse 10y ago
      How has it declined?
      - daenney 10y ago
        It seems less people are involved or interested in solving the Darwin related issues. I have more issues getting things built and installed on OS X compared to a year ago. This mainly because it seems people aren't really interested in maintaining the OS X part of nixpkgs and some simply lack the resources to do so. In the end it seems that this will get better if it can attract enough OS X users so that patches start rolling in but right now it's just a few people fighting that battle.
        sitkack 10y ago
        I don't like the lack of software diversity, but I see running Linux based containers on OSX as a viable solution to not having Nix support. Run nix in a container, create shimlinks so that everything is "transparent"
- aorth 10y ago
  Wow, that's almost as bad as a few months ago when they enabled the analytics feature that sends data to Google Analytics for every brew install, list, search, error, etc[0]. Thanks for pointing this out, I've disabled the auto update (HOMEBREW_NO_AUTO_UPDATE=1). Web developers gone crazy with the package manager in your shell! [0] https://github.com/Homebrew/brew/blob/master/share/doc/homebrew/Analytics.md https://github.com/Homebrew/brew/blob/master/share/doc/homeb...
- mikemcquaid 10y ago
  > automatically running `brew update` with every brew command run This is not accurate. We run a minimal version of `brew update` at most once per minute when you run `brew install` or `brew upgrade`: https://github.com/Homebrew/brew/blob/5504e2c1320d52f8a92a33c90c313a47668979c0/Library/Homebrew/brew.sh#L237 https://github.com/Homebrew/brew/blob/5504e2c1320d52f8a92a33... You can set this interval with `HOMEBREW_AUTO_UPDATE_SECS` and disable this functionality with `HOMEBREW_NO_AUTO_UPDATE`.
  - falcolas 10y ago
    > at most once per minute Well, that's a relief. I run an average of 4-5 brew commands every minute, so at least there's that. /s > when you run `brew install` or `brew upgrade` So, only the two most used `brew` commands (for me, at least) will trigger a series of git fetches and merges over the network and an in-place update of the code. > You can [...] disable this functionality with `HOMEBREW_NO_AUTO_UPDATE` Why was it enabled automatically in the first place? Why wasn't I notified when homebrew updated that this was the new default behavior. Why must I always dive into homebrew on github to identify (1) why it's not behaving the way I would expect a package manager to and (2) how to get back sane package manager behavior?
    - mikemcquaid 10y ago
      > will trigger a series of git fetches If there's been no updates there will be no `git fetch` run. We use a newish GitHub API to check for updates as its quicker. > Why was it enabled automatically in the first place? A significant numbers of our created issues are due to people having failures when they don't run `brew update`. This solves that. > Why must I always dive into homebrew on github to identify (1) why it's not behaving the way I would expect a package manager to and (2) how to get back sane package manager behavior? We're an open-source project run by volunteers for free in our spare time. We're underfunded and understaffed so our communication is lacking. The best current place to find out about such things is to follow our issue tracker. We aim to improve this in future.
hkjgkjy 10y ago
For anyone using homebrew or other package manager, and who has an afternoon free; I'd suggest checking Nix out. It's very nice to define an immutable manifest and have your system derived from it. If you love pure functions, you'll love Nix.
- stock_toaster 10y ago
  I hear pkgsrc[1] is pretty decent for osx as well. I keep wanting to try it out, but haven't yet. [1]: https://pkgsrc.joyent.com/install-on-osx/ https://pkgsrc.joyent.com/install-on-osx/
  - hkjgkjy 10y ago
    Browsed the website for a while, but couldn't find out why anyone would use Pkgsrc over any other package manager. If you know I'd love to hear!
    - justincormack 10y ago
      The big thing it has is the same packages and experience on any OS, you can install on Linux and the BSDs and it is just the same. Other than that it has pretty much everything you would expect, and lots of packages.
  - aorth 10y ago
    I've been trying to like pkgsrc on Mac OS X for a few years now. The one you link to provides binaries, and is sponsored by Joyent. The main deal breaker for me there is that they only update their packages every quarter (currently 2016Q2), so you have to wait if you want bug fixes, security updates, etc. I just had a look again and found that ffmpeg is one minor version behind behind stable, its binary is annoyingly called "ffmpeg3", and it was compiled somewhere with LLVM 6 / clang 600, versus LLVM 8 / clang 800 on my macOS 10.12 system. I tried to compile it manually (after a shallow clone of their massive, 250,000+ commit git repo), but failed. For me Homebrew does the right thing here — they basically turn my Mac into a rolling release Linux desktop like Arch Linux, which is great for the userland type packages I use: openssh, zsh, tmux, postgresql, ffmpeg, git, vim, rsync, etc.
yepperino 10y ago
It's probably been stated a million times before but it's hard to remember what coding was like before github. CVS and subversion - what's that? Github is so pervasive that when a project uses another git code sharing site you just get annoyed. Github Issues may suck, but it's so darn convenient and so well integrated. It's far worse when a project uses another ticket tracking system and just uses github for pull requests. Just give in to our new code overlords and go with the flow.
- peatfreak 10y ago
  > Just give in to our new code overlords and go with the flow. No. They are turning coding into a monopolistic monoculture. Not everybody loves pull request-based workflows, you know.
  - yepperino 10y ago
    You're right. I'm going to go back to uuencoding my tar files and posting them on usenet.
    - mwfunk 10y ago
      You clearly are far too young to have ever done this. :)
    - drauh 10y ago
      You need to split them, first. ;)
- kevin_thibedeau 10y ago
  I always cringe when I find a useful tool still clinging to Sourceforge and it's abomination of a web site.
- bdcravens 10y ago
  > Github is so pervasive that when a project uses another git code sharing site you just get annoyed Bitbucket's ability to lock down branches is pretty nice. > Github Issues may suck, but it's so darn convenient and so well integrated. It's far worse when a project uses another ticket tracking system I don't feel this is true, having worked on projects that used Jira, Unfuddle, Pivotal Tracker, Assembla, Trello, etc. Of course, none of those systems have the killer feature of turning a ticket into a giant scrollfest of "+1", emojis, and animated gifs.
rubyn00bie 10y ago
I am sincerely curious when I ask this, please don't see it as flame bait-- what/who uses Macports still instead of Homebrew (or Nix)? Is it for legacy systems? Or unusual requirements? Habit? Edit for reasoning: I'm curious because who knows-- maybe I'm missing something really cool or jumped ship to Homebrew years ago too hastily? Edit #2: Just wanted to say thanks to the folks who have replied below! I'm definitely a bit more curious about macports again.
- jordigh 10y ago
  GNU Octave packages are still well maintained on Macports (and Fink!) and we have several enthusiastic users. I wish we could get Octave to our users without any CLI shenanigans, but it's proven very difficult to build an app bundle. We finally have one, but it's not relocatable. http://wiki.octave.org/Octave_for_MacOS_X#Installing_a_Mac_OS_X_Bundle http://wiki.octave.org/Octave_for_MacOS_X#Installing_a_Mac_O...
  - wodenokoto 10y ago
    in my experience the bundle works great, and I'm very happy that I don't have to use home-brew.
- LeoPanthera 10y ago
  MacPorts is useful on multi-user systems. It installs as root, so any user of the system can access installed packages, but only admins can modify them. I'm sure Homebrew could probably be set up this way, but the defaults are a powerful thing.
  - rubyn00bie 10y ago
    That's a mighty good reason to use Macports! I'll have to keep that in mind. You said you could probably configure Homebrew in a similar way, but... can you now-a-days configure macports to install without root for user local packages?* * Pardon me for the potential ignorance of this question being unreasonable or lazy.
akubera 10y ago
I've been using macports for years and am excited by the prospects a "social" coding experience will bring with a much lower barrier to entry for contributions. They say they will stick with Trac for dealing with issues. I understand that for managing the ports collection, but are they planning on keeping "base" issues (i.e. the application code) off the github as well? I don't know how well different repos and issue trackers interop, but it seems like an open-source solution like gitlab would offer the (potential for) customization/integration more readily than github. I'm sure they just desire a turn-key solution and don't want to manage a whole new project, but maybe, one day, they'll want to unify the experience again.
- peatfreak 10y ago
  > a "social" coding experience Do people still buy into this? I feel this phrase was just a marketing ploy by GitHub.
  - akubera 10y ago
    In retrospect, "social" was the wrong word; what I really meant was "a place people already have an account and may contribute" i.e. a large, established community. I'll leave the question of "is it a social coding experience?" to the experts.
ktta 10y ago
Wait, why does https://www.macosforge.org/ https://www.macosforge.org/ have a cert that says Apple, Inc. Is Macports funded and managed by Apple?
- amake 10y ago
  MacPorts isn't; Mac OS Forge is. From your own link: Copyright © 2011 Apple Inc. All rights reserved MacPorts is hosted on Mac OS Forge, but it is not run by Apple; it merely uses Apple-provided infrastructure.
  - ktta 10y ago
    Got it, thanks!
- mwfunk 10y ago
  No, but originally there were a lot of Apple employees who participated in MacPorts in their spare time, and the project leaders included people from the open source world who were working at Apple. I think that's still the case but probably not to the same degree as it was 10-15 years ago. The dawn of OS X coincided with the tail end of what was a rather insane open source hype bubble that existed in the industry in the late-'90s. This was the same era where lots of people were convinced that everyone was going to be running desktop Linux in just a couple more years (this is the origin of "this is the year of Linux on the desktop" jokes), and ESR hadn't squandered his credibility quite yet. It was a very different time. Anyway, point being, MacOSForge is in part a historical artifact of a time when there was an open source bandwagon that a lot of SV companies had jumped on and were encouraging their employees to jump on as well. After a few years the industry restabilized and many companies weren't as publicly gung ho about open source, but for a while at least there were some surprising initiatives from unexpected companies. I don't miss the messianic/apocalyptic/mystical/tribal/just-plain-silly overtones that surrounded open source hype in the media and in the community in those days, but I do deeply miss the surge of otherwise opaque corporations publicly committing to open source and actually following through on it for a while. It's amazing what can happen when the entire tech press is drunk on excitement about open source, leading to board meetings all over SV in which every CEO was getting pestered to have an articulated open source strategy for how they will remain relevant in this brave new world that was supposedly just around the corner. So that's the era that MacOSForge was born into, and at the time it probably seemed bursting with potential. This was also the era of bootable Darwin ISO images (and OpenDarwin after that). There are many reasons a lot of that stuff faded away over the years. My theory is that many of these initiatives solved problems that people didn't have. Why put money into putting stuff out there that nobody cares about, and why would anybody care about it if the company wasn't pouring money into it? It's a chicken and egg problem unfortunately, I don't think there's anyone to blame for it. Some things just aren't going to be interesting to enough people to merit throwing money at them. I'm just glad that much of macOS continues to be open source, even if most of it is in the form of a bunch of tarballs that get put up on opensource.apple.com after every release. TL;DR as others have pointed out, MacOSForge itself is (was?) Apple. MacPorts is an independent project and will live on, but benefitted from being born in an era of unusually high industry enthusiasm for open source.
RubyMyDear 10y ago
Or you can run the Windows Subsystem for Linux and have real apt-get or yum!
- aphextron 10y ago
  I'm with you on that. This effectively ended any reason I still had left to develop on OSX.
  - RubyMyDear 10y ago
    I actually had a much easier time getting most common GNU things running under CYGWIN than under MacOS. There's really no reason for a "Unix/Linux" developer who uses a lot of GNU and FOSS tools to use Mac. Use Windows / Cygwin / Windows Services for Linux / and VM if you need the real thing.
- NEDM64 10y ago
  A Linux emulador, that is...
  - daenney 10y ago
    It's not an emulator. It does live translation of system calls. Much like WINE (Wine is not an emulator) isn't one either.
    - RubyMyDear 10y ago
      Apple has an entire army of volunteer Astroturfers to spread lies about Windows, it seems.
- AnonymousPlanet 10y ago
  ... and work constrained to that ship in a bottle. No thanks! I do a lot of interaction between Bash and the rest of my OS X userland. That is something I found completely impossible with the Linux subsystem on Windows.
newsat13 10y ago
I never get the logic of how whole heartedly opensource projects embrace a completely closed source software. I get it that not everything can be open source but there are already good open source alternatives for hosting.
- Steltek 10y ago
  Honestly, I had the same thought years ago when many long time Linux users moved to OSX. But then, we're speaking about the same userbase here.
halis 10y ago
Good for you guys! Lol wtf is Forge?
kchoudhu 10y ago
The problems addressed by Homebrew, Macports and the like have all been solved in a cross-platform manner by the fine folks working on pkgsrc. Sane defaults, respect for system security settings, and a general lack of bullshit. As a *BSD refugee on Mac OS X, it feels like a slice of home every time I need to install software.
- athenot 10y ago
  It's my understanding MacPorts came from the same BSD Port system and keeps the same philosophy. How does pkgsrc differ?
  - kchoudhu 10y ago
    Prior discussion: https://news.ycombinator.com/item?id=9407119 https://news.ycombinator.com/item?id=9407119 Because of the cross-platform focus of the NetBSD developers, I can replicate my package installation workflow on any number (20+ at last count) of operating systems with the same command set. This saves me from the mental overhead of having to pick up Mac-isms, which is nice. Also, binary installs!
JD557 10y ago
> Over the years, several developers have asked why we're not on GitHub. The perception is that "everybody" is on GitHub, and some developers don't take your project seriously if it's not on GitHub. This is the sad truth. It doesn't matter anymore if Bitbucket/Gitlab/etc. are better than GitHub: The social pressure for open source projects to move to GitHub is so high that the alternatives don't even stand a chance. Maybe a meta-search engine for open source projects could help the competition, but if all projects are on GitHub, who would use such a search engine? P.S.: I actually like GitHub, I'm just sad that all cool changes that GitLab has made recently will end up being mostly ignored by the OSS community. Even if they fixed their speed problem (which I think is their biggest downside compared to GitHub), no project would move there because "everybody is on GitHub".
- davisonio 10y ago
  > no project would move there because "everybody is on GitHub". If they had a solid sync service between GitLab and GitHub; PRs, issues, code, everything then things could get interesting and some people might consider the switch.
  - jobvandervoort 10y ago
    Right now you can import your entire project easily in GitLab, from GitHub (incl everything) [0]. You can also sync any remote repository (two-ways) [1] in GitLab EE (which runs on GitLab.com). I made an issue for a continuous sync in GitLab [2]. Would love to get your feedback. [0]: http://docs.gitlab.com/ee/workflow/importing/import_projects_from_github.html#sts=Import http://docs.gitlab.com/ee/workflow/importing/import_projects... your project from GitHub to GitLab [1]: http://docs.gitlab.com/ee/workflow/repository_mirroring.html http://docs.gitlab.com/ee/workflow/repository_mirroring.html [2]: https://gitlab.com/gitlab-org/gitlab-ee/issues/904 https://gitlab.com/gitlab-org/gitlab-ee/issues/904
- abstractbeliefs 10y ago
  The worst thing is that eventually, github will start to want to monetise even more, and we'll see it turn into SourceForge, at which point many projects that have tied themselves into github rather than spreading out more carefully amongst other git hosts will face a bit of an existential crisis. We'll never learn.
stadeschuldt 10y ago
I hope this helps with the adoption of newer versions of packages. I have used MacPorts in the past (and Fink before) but I am supper happy with Homebrew these days. What I disliked about Macports was: 1. Ports define which compiler to use. Sometimes I had to install a small tool and first it would another version of gcc. 2. Ports were outdated a lot. I developed a project using the Grails-framework and it was a couple of versions behind the current stable release. Just checked: Grails port is at version 2.2 https://trac.macports.org/browser/trunk/dports/devel/grails/Portfile https://trac.macports.org/browser/trunk/dports/devel/grails/... while the current version being 3.1.10 With Homebrew the adoption rate seems much higher. Also you don't depend on a single maintainer.
- vorg 10y ago
  Probably doesn't matter because not many Grails 2.x projects are being upgraded to 3.x in the wild anyway.
cm3 10y ago
This seems to have coincided with a practical cause to look for a new place: But now that we have to leave Mac OS Forge anyway, it makes sense to convert to git and take the opportunity to do some much needed and overdue restructuring[...]

184 points by sashk 10y ago

This is long overdue. Google slowly been doing the same with moving from Google Code (which was supposed to be dead? It is though?) to GitHub, but a little progression is better than no progression.

LukeShu 10y ago
Google Code the public service is dead. They still have internal, but publicly visible, hosting for things like Android and Chromium; which they seem to be rebranding as Google Source, or at least using the googlesource.com domain.

deleted 10y ago

[deleted]

GirlsCanCode 10y ago

Goodbye Macports then. Can't we have code hosted on a politically neutral platform?

falcolas 10y ago

With all of the - I'd call them shenanigans, but I'm sure they're justifiable features [0] to someone - with homebrew, it may be time to take a closer look at macports as a replacement. Glad to see the project not only alive, but evolving with the community. [0] Like automatically running `brew update` with every brew command run. I was literally wondering if my computer had frozen up again when I saw that it had done a full update (which involves not only patching the brew code, but updating its source repos) before installing a pre-compiled version of tmux.

ploxiln 10y ago
Yeah, that one surprised me too recently. But most of the junk can be disabled. My current settings: $ env | grep HOMEBREW HOMEBREW_BUILD_FROM_SOURCE=1 HOMEBREW_NO_AUTO_UPDATE=1 HOMEBREW_NO_EMOJI=1
- jordigh 10y ago
  Can you disable all of its cutesy names? Bottles for binaries, cellar for package path, taps for 3rd party repos, recipe (or formula? I forget) for build scripts, cask for a REPL... I honestly got a bit confused at first by what all of these things meant.
  - Mister_Snuggles 10y ago
    This is why I use MacPorts.
  - CookieMon 10y ago
    This habbit of programmers to name things with puns instead of descriptively drives me batty. WiX is bad, but Homebrew is on a whole new level. Each time I use a mac I have to relearn what a tap represents vs cask vs brew vs celler etc. But hey, aren't they clever with words!
    - Washuu 10y ago
      Those clever words immediately made sense to me for their inherent meanings the first time I saw them. So they are actually quite useful in their pairings.
      - rbanffy 10y ago
        I love puns just like everyone else, but when you have a word that precisely describes the thing you have, why not use it instead of using a clever metaphor?
        Terretta 10y ago
        Like programs for Pages, Numbers, Keynote, Photos, Notes...?
        sitkack 10y ago
busterarm 10y ago
I'd like to see pkgsrc take off as the big Homebrew alternative.
- daenney 10y ago
  That, or nix. Unfortunately the state of Darwin/OS X on nix has declined over the last year or so.
  - ymse 10y ago
    How has it declined?
    - daenney 10y ago
      It seems less people are involved or interested in solving the Darwin related issues. I have more issues getting things built and installed on OS X compared to a year ago. This mainly because it seems people aren't really interested in maintaining the OS X part of nixpkgs and some simply lack the resources to do so. In the end it seems that this will get better if it can attract enough OS X users so that patches start rolling in but right now it's just a few people fighting that battle.
      - sitkack 10y ago
        I don't like the lack of software diversity, but I see running Linux based containers on OSX as a viable solution to not having Nix support. Run nix in a container, create shimlinks so that everything is "transparent"
aorth 10y ago
Wow, that's almost as bad as a few months ago when they enabled the analytics feature that sends data to Google Analytics for every brew install, list, search, error, etc[0]. Thanks for pointing this out, I've disabled the auto update (HOMEBREW_NO_AUTO_UPDATE=1). Web developers gone crazy with the package manager in your shell! [0] https://github.com/Homebrew/brew/blob/master/share/doc/homebrew/Analytics.md https://github.com/Homebrew/brew/blob/master/share/doc/homeb...
mikemcquaid 10y ago
> automatically running `brew update` with every brew command run This is not accurate. We run a minimal version of `brew update` at most once per minute when you run `brew install` or `brew upgrade`: https://github.com/Homebrew/brew/blob/5504e2c1320d52f8a92a33c90c313a47668979c0/Library/Homebrew/brew.sh#L237 https://github.com/Homebrew/brew/blob/5504e2c1320d52f8a92a33... You can set this interval with `HOMEBREW_AUTO_UPDATE_SECS` and disable this functionality with `HOMEBREW_NO_AUTO_UPDATE`.
- falcolas 10y ago
  > at most once per minute Well, that's a relief. I run an average of 4-5 brew commands every minute, so at least there's that. /s > when you run `brew install` or `brew upgrade` So, only the two most used `brew` commands (for me, at least) will trigger a series of git fetches and merges over the network and an in-place update of the code. > You can [...] disable this functionality with `HOMEBREW_NO_AUTO_UPDATE` Why was it enabled automatically in the first place? Why wasn't I notified when homebrew updated that this was the new default behavior. Why must I always dive into homebrew on github to identify (1) why it's not behaving the way I would expect a package manager to and (2) how to get back sane package manager behavior?
  - mikemcquaid 10y ago
    > will trigger a series of git fetches If there's been no updates there will be no `git fetch` run. We use a newish GitHub API to check for updates as its quicker. > Why was it enabled automatically in the first place? A significant numbers of our created issues are due to people having failures when they don't run `brew update`. This solves that. > Why must I always dive into homebrew on github to identify (1) why it's not behaving the way I would expect a package manager to and (2) how to get back sane package manager behavior? We're an open-source project run by volunteers for free in our spare time. We're underfunded and understaffed so our communication is lacking. The best current place to find out about such things is to follow our issue tracker. We aim to improve this in future.

hkjgkjy 10y ago

For anyone using homebrew or other package manager, and who has an afternoon free; I'd suggest checking Nix out. It's very nice to define an immutable manifest and have your system derived from it. If you love pure functions, you'll love Nix.

stock_toaster 10y ago
I hear pkgsrc[1] is pretty decent for osx as well. I keep wanting to try it out, but haven't yet. [1]: https://pkgsrc.joyent.com/install-on-osx/ https://pkgsrc.joyent.com/install-on-osx/
- hkjgkjy 10y ago
  Browsed the website for a while, but couldn't find out why anyone would use Pkgsrc over any other package manager. If you know I'd love to hear!
  - justincormack 10y ago
    The big thing it has is the same packages and experience on any OS, you can install on Linux and the BSDs and it is just the same. Other than that it has pretty much everything you would expect, and lots of packages.
- aorth 10y ago
  I've been trying to like pkgsrc on Mac OS X for a few years now. The one you link to provides binaries, and is sponsored by Joyent. The main deal breaker for me there is that they only update their packages every quarter (currently 2016Q2), so you have to wait if you want bug fixes, security updates, etc. I just had a look again and found that ffmpeg is one minor version behind behind stable, its binary is annoyingly called "ffmpeg3", and it was compiled somewhere with LLVM 6 / clang 600, versus LLVM 8 / clang 800 on my macOS 10.12 system. I tried to compile it manually (after a shallow clone of their massive, 250,000+ commit git repo), but failed. For me Homebrew does the right thing here — they basically turn my Mac into a rolling release Linux desktop like Arch Linux, which is great for the userland type packages I use: openssh, zsh, tmux, postgresql, ffmpeg, git, vim, rsync, etc.

yepperino 10y ago

It's probably been stated a million times before but it's hard to remember what coding was like before github. CVS and subversion - what's that? Github is so pervasive that when a project uses another git code sharing site you just get annoyed. Github Issues may suck, but it's so darn convenient and so well integrated. It's far worse when a project uses another ticket tracking system and just uses github for pull requests. Just give in to our new code overlords and go with the flow.

peatfreak 10y ago
> Just give in to our new code overlords and go with the flow. No. They are turning coding into a monopolistic monoculture. Not everybody loves pull request-based workflows, you know.
- yepperino 10y ago
  You're right. I'm going to go back to uuencoding my tar files and posting them on usenet.
  - mwfunk 10y ago
    You clearly are far too young to have ever done this. :)
  - drauh 10y ago
    You need to split them, first. ;)
kevin_thibedeau 10y ago
I always cringe when I find a useful tool still clinging to Sourceforge and it's abomination of a web site.
bdcravens 10y ago
> Github is so pervasive that when a project uses another git code sharing site you just get annoyed Bitbucket's ability to lock down branches is pretty nice. > Github Issues may suck, but it's so darn convenient and so well integrated. It's far worse when a project uses another ticket tracking system I don't feel this is true, having worked on projects that used Jira, Unfuddle, Pivotal Tracker, Assembla, Trello, etc. Of course, none of those systems have the killer feature of turning a ticket into a giant scrollfest of "+1", emojis, and animated gifs.

rubyn00bie 10y ago

I am sincerely curious when I ask this, please don't see it as flame bait-- what/who uses Macports still instead of Homebrew (or Nix)? Is it for legacy systems? Or unusual requirements? Habit? Edit for reasoning: I'm curious because who knows-- maybe I'm missing something really cool or jumped ship to Homebrew years ago too hastily? Edit #2: Just wanted to say thanks to the folks who have replied below! I'm definitely a bit more curious about macports again.

jordigh 10y ago
GNU Octave packages are still well maintained on Macports (and Fink!) and we have several enthusiastic users. I wish we could get Octave to our users without any CLI shenanigans, but it's proven very difficult to build an app bundle. We finally have one, but it's not relocatable. http://wiki.octave.org/Octave_for_MacOS_X#Installing_a_Mac_OS_X_Bundle http://wiki.octave.org/Octave_for_MacOS_X#Installing_a_Mac_O...
- wodenokoto 10y ago
  in my experience the bundle works great, and I'm very happy that I don't have to use home-brew.
LeoPanthera 10y ago
MacPorts is useful on multi-user systems. It installs as root, so any user of the system can access installed packages, but only admins can modify them. I'm sure Homebrew could probably be set up this way, but the defaults are a powerful thing.
- rubyn00bie 10y ago
  That's a mighty good reason to use Macports! I'll have to keep that in mind. You said you could probably configure Homebrew in a similar way, but... can you now-a-days configure macports to install without root for user local packages?* * Pardon me for the potential ignorance of this question being unreasonable or lazy.

akubera 10y ago

I've been using macports for years and am excited by the prospects a "social" coding experience will bring with a much lower barrier to entry for contributions. They say they will stick with Trac for dealing with issues. I understand that for managing the ports collection, but are they planning on keeping "base" issues (i.e. the application code) off the github as well? I don't know how well different repos and issue trackers interop, but it seems like an open-source solution like gitlab would offer the (potential for) customization/integration more readily than github. I'm sure they just desire a turn-key solution and don't want to manage a whole new project, but maybe, one day, they'll want to unify the experience again.

peatfreak 10y ago
> a "social" coding experience Do people still buy into this? I feel this phrase was just a marketing ploy by GitHub.
- akubera 10y ago
  In retrospect, "social" was the wrong word; what I really meant was "a place people already have an account and may contribute" i.e. a large, established community. I'll leave the question of "is it a social coding experience?" to the experts.

ktta 10y ago

Wait, why does https://www.macosforge.org/ https://www.macosforge.org/ have a cert that says Apple, Inc. Is Macports funded and managed by Apple?

amake 10y ago
MacPorts isn't; Mac OS Forge is. From your own link: Copyright © 2011 Apple Inc. All rights reserved MacPorts is hosted on Mac OS Forge, but it is not run by Apple; it merely uses Apple-provided infrastructure.
- ktta 10y ago
  Got it, thanks!
mwfunk 10y ago
No, but originally there were a lot of Apple employees who participated in MacPorts in their spare time, and the project leaders included people from the open source world who were working at Apple. I think that's still the case but probably not to the same degree as it was 10-15 years ago. The dawn of OS X coincided with the tail end of what was a rather insane open source hype bubble that existed in the industry in the late-'90s. This was the same era where lots of people were convinced that everyone was going to be running desktop Linux in just a couple more years (this is the origin of "this is the year of Linux on the desktop" jokes), and ESR hadn't squandered his credibility quite yet. It was a very different time. Anyway, point being, MacOSForge is in part a historical artifact of a time when there was an open source bandwagon that a lot of SV companies had jumped on and were encouraging their employees to jump on as well. After a few years the industry restabilized and many companies weren't as publicly gung ho about open source, but for a while at least there were some surprising initiatives from unexpected companies. I don't miss the messianic/apocalyptic/mystical/tribal/just-plain-silly overtones that surrounded open source hype in the media and in the community in those days, but I do deeply miss the surge of otherwise opaque corporations publicly committing to open source and actually following through on it for a while. It's amazing what can happen when the entire tech press is drunk on excitement about open source, leading to board meetings all over SV in which every CEO was getting pestered to have an articulated open source strategy for how they will remain relevant in this brave new world that was supposedly just around the corner. So that's the era that MacOSForge was born into, and at the time it probably seemed bursting with potential. This was also the era of bootable Darwin ISO images (and OpenDarwin after that). There are many reasons a lot of that stuff faded away over the years. My theory is that many of these initiatives solved problems that people didn't have. Why put money into putting stuff out there that nobody cares about, and why would anybody care about it if the company wasn't pouring money into it? It's a chicken and egg problem unfortunately, I don't think there's anyone to blame for it. Some things just aren't going to be interesting to enough people to merit throwing money at them. I'm just glad that much of macOS continues to be open source, even if most of it is in the form of a bunch of tarballs that get put up on opensource.apple.com after every release. TL;DR as others have pointed out, MacOSForge itself is (was?) Apple. MacPorts is an independent project and will live on, but benefitted from being born in an era of unusually high industry enthusiasm for open source.

RubyMyDear 10y ago

Or you can run the Windows Subsystem for Linux and have real apt-get or yum!

aphextron 10y ago
I'm with you on that. This effectively ended any reason I still had left to develop on OSX.
- RubyMyDear 10y ago
  I actually had a much easier time getting most common GNU things running under CYGWIN than under MacOS. There's really no reason for a "Unix/Linux" developer who uses a lot of GNU and FOSS tools to use Mac. Use Windows / Cygwin / Windows Services for Linux / and VM if you need the real thing.
NEDM64 10y ago
A Linux emulador, that is...
- daenney 10y ago
  It's not an emulator. It does live translation of system calls. Much like WINE (Wine is not an emulator) isn't one either.
  - RubyMyDear 10y ago
    Apple has an entire army of volunteer Astroturfers to spread lies about Windows, it seems.
AnonymousPlanet 10y ago
... and work constrained to that ship in a bottle. No thanks! I do a lot of interaction between Bash and the rest of my OS X userland. That is something I found completely impossible with the Linux subsystem on Windows.

newsat13 10y ago

I never get the logic of how whole heartedly opensource projects embrace a completely closed source software. I get it that not everything can be open source but there are already good open source alternatives for hosting.

Steltek 10y ago
Honestly, I had the same thought years ago when many long time Linux users moved to OSX. But then, we're speaking about the same userbase here.

halis 10y ago

Good for you guys! Lol wtf is Forge?

kchoudhu 10y ago

The problems addressed by Homebrew, Macports and the like have all been solved in a cross-platform manner by the fine folks working on pkgsrc. Sane defaults, respect for system security settings, and a general lack of bullshit. As a *BSD refugee on Mac OS X, it feels like a slice of home every time I need to install software.

athenot 10y ago
It's my understanding MacPorts came from the same BSD Port system and keeps the same philosophy. How does pkgsrc differ?
- kchoudhu 10y ago
  Prior discussion: https://news.ycombinator.com/item?id=9407119 https://news.ycombinator.com/item?id=9407119 Because of the cross-platform focus of the NetBSD developers, I can replicate my package installation workflow on any number (20+ at last count) of operating systems with the same command set. This saves me from the mental overhead of having to pick up Mac-isms, which is nice. Also, binary installs!

JD557 10y ago

> Over the years, several developers have asked why we're not on GitHub. The perception is that "everybody" is on GitHub, and some developers don't take your project seriously if it's not on GitHub. This is the sad truth. It doesn't matter anymore if Bitbucket/Gitlab/etc. are better than GitHub: The social pressure for open source projects to move to GitHub is so high that the alternatives don't even stand a chance. Maybe a meta-search engine for open source projects could help the competition, but if all projects are on GitHub, who would use such a search engine? P.S.: I actually like GitHub, I'm just sad that all cool changes that GitLab has made recently will end up being mostly ignored by the OSS community. Even if they fixed their speed problem (which I think is their biggest downside compared to GitHub), no project would move there because "everybody is on GitHub".

davisonio 10y ago
> no project would move there because "everybody is on GitHub". If they had a solid sync service between GitLab and GitHub; PRs, issues, code, everything then things could get interesting and some people might consider the switch.
- jobvandervoort 10y ago
  Right now you can import your entire project easily in GitLab, from GitHub (incl everything) [0]. You can also sync any remote repository (two-ways) [1] in GitLab EE (which runs on GitLab.com). I made an issue for a continuous sync in GitLab [2]. Would love to get your feedback. [0]: http://docs.gitlab.com/ee/workflow/importing/import_projects_from_github.html#sts=Import http://docs.gitlab.com/ee/workflow/importing/import_projects... your project from GitHub to GitLab [1]: http://docs.gitlab.com/ee/workflow/repository_mirroring.html http://docs.gitlab.com/ee/workflow/repository_mirroring.html [2]: https://gitlab.com/gitlab-org/gitlab-ee/issues/904 https://gitlab.com/gitlab-org/gitlab-ee/issues/904
abstractbeliefs 10y ago
The worst thing is that eventually, github will start to want to monetise even more, and we'll see it turn into SourceForge, at which point many projects that have tied themselves into github rather than spreading out more carefully amongst other git hosts will face a bit of an existential crisis. We'll never learn.

stadeschuldt 10y ago

I hope this helps with the adoption of newer versions of packages. I have used MacPorts in the past (and Fink before) but I am supper happy with Homebrew these days. What I disliked about Macports was: 1. Ports define which compiler to use. Sometimes I had to install a small tool and first it would another version of gcc. 2. Ports were outdated a lot. I developed a project using the Grails-framework and it was a couple of versions behind the current stable release. Just checked: Grails port is at version 2.2 https://trac.macports.org/browser/trunk/dports/devel/grails/Portfile https://trac.macports.org/browser/trunk/dports/devel/grails/... while the current version being 3.1.10 With Homebrew the adoption rate seems much higher. Also you don't depend on a single maintainer.

vorg 10y ago
Probably doesn't matter because not many Grails 2.x projects are being upgraded to 3.x in the wild anyway.

cm3 10y ago

This seems to have coincided with a practical cause to look for a new place: But now that we have to leave Mac OS Forge anyway, it makes sense to convert to git and take the opportunity to do some much needed and overdue restructuring[...]