[guessmyname]

I switched to macOS from Linux two weeks ago and I am starting to regret that decision. Most — if not all — the commands that I thought I had mastered after years working on Linux environments stopped working because their BSD counterparts have slightly differences that completely break everything I try to do. It is even more frustrating when I realize that I have to deactivate security features built-in the new Apple computers in order to make things like "dtrace" (the strace alternative) work.

[nrclark]

You should give Macports a try if you haven't already! I run it on my macbook, and it's made a world of difference. 99% of everything I use in Linux can be found in Macports, and it "just works" for the most part.

You can't get kernel-specific things like strace, but they do have just about everything else. The big sell for me was being able to install the GNU versions of everything.

Macports keeps everything in /opt, so you also never have to worry about it clobbering anything that MacOS expects to work in a certain way.

edit: some background on Macports vs Homebrew - it's basically a vi/emacs kind of a thing. Homebrew utilizes the MacOS system stuff a fair amount, and installs everything to /usr/local. Macports tries to keep everything fully separate, and installs into /opt.

My personal experiences with Homebrew weren't great, but others will probably have the opposite opinion.

[gregmac]

One of the things that I really dislike about homebrew is its refusal to run via sudo plus the requirement that you own /usr/local.

This means:

1) It is a security hole; any application can now modify system-wide applications at any time.

2) You can't have multiple users able to use homebrew.

I was expecting homebrew to be something similar to apt/yum/etc, but this makes it pretty fundamentally different.

How does Macports handle this? Does $USER still need write access to /opt?

[DavideNL]

< plus the requirement that you own /usr/local

no, this is not required anymore... https://github.com/Homebrew/brew/commit/a2f19f0a675f7cb384b4...

> You can't have multiple users able to use homebrew

what i did is i run Homebrew as a user i called Admin and when logged in as another user i simply do a 'su - admin' to run the brew commands..

[packetslave]

There's no requirement that Homebrew be in /usr/local. Some individual (poorly-written) packages may assume that, but I've been running Homebrew in $HOME/.brew for multiple years on multiple machines with no issues at all.

[ghthor]

That's actually fucking brilliant, and aligns much better with what homebrew is. I'm setting up my new macbook from work tomorrow and this is absolutely the way I'm going to do it, and how I'll suggest any of my colleagues do as well.

[duaneb]

It's also very difficult to roll back to a previous version of a package unless the maintainers specifically opt in to tagging them. Homebrew also updates itself when you install something now, so say if you install python, it might update readline, so your postgres client will break.

It's not the worst approximation of ports, but it doesn't share the quality and care that goes into package maintenance and dependency management.

[oschrenk]

Re 2) I'm running a multi user homebrew setup for years. I have my users (personal and various work accounts) live under the "Local" Group and do

``` sudo chmod -R 770 /usr/local/ sudo chmod -R +a "group:Local allow delete,readattr,writeattr,readextattr,writeextattr,list,search,add_file,add_subdirectory,delete_child,file_inherit,directory_inherit" /usr/local/ ```

I remember sometimes running into permissions issues but nothing re-running that command didn't fix.

[SkyMarshal]

It's a bit of a smell that Homebrew doesn't do this itself.

[1amzave]

Really? If you're going to do that, it seems like you might as well just merge all those users into a single account anyway, considering how trivial it would be for any one of them to execute arbitrary code as any other.

[Watabou]

Why is 'sudo' required? Just curious.

I moved away from homebrew, to compiling my own software on macOS which I just put in ~/build. I don't use sudo make install since I own the ~/build folder.

What am I doing wrong in this case?

[superchink]

This is no longer the case, as of Homebrew 1.0.

See this change: https://github.com/Homebrew/brew/pull/896

[vsl]

This is only about /usr/local itself, not the directories under it, the one with executables - that's still owned by you, not root. Some difference in ease of initial installation, zero difference in terms of (in)security.

[module0000]

Another recommendation for macports. You'll find htop and all your other linux friends in there.

eg for htop: `sudo port install htop`

[ajacksified]

(also in brew; `brew install htop`, vim, tmux, wget, lynx, etc.)

[bootload]

"You should give Macports a try if you haven't already! I run it on my macbook, and it's made a world of difference. 99% of everything I use in Linux can be found in Macports, and it "just works" for the most part."

First thing I installed in the mac store. Just like on linux, it just works and I get all my favourite tools.

[garblegarble]

For general dev use in macOS I find that installing the GNU userland (through MacPorts) keeps me sane, "sudo port install coreutils moreutils htop gnutar" and then put /opt/local/libexec/gnubin/:/opt/local/bin at the start of your PATH.

Doesn't help much with dtrace though!

[nrclark]

yep! Macports is awesome.

[takeda]

A little nitpick, dtrace is not an alternative to strace. DTrace is far more powerful.

Alternative to strace would be dtruss, which is implemented through dtrace.

[1amzave]

Until I can, as an unprivileged user, watch my own process's syscalls with dtruss, it's not an alternative to strace. Requiring root is a major hindrance.

[hprotagonist]

`brew install coreurils && brew install htop`

[rrdharan]

You probably also want to chmod +s htop, or it won't actually show you CPU/memory stats.

[hprotagonist]

and if you want to use `sed` not `gsed`, do `brew install --default-names coreutils` to supercede the OS provided utilities.

[lobster_johnson]

Or you can add it to your PATH:

    PATH=/usr/local/opt/coreutils/libexec/gnubin:$PATH

"gnubin" contains the all utilities with the original names.

[sirodoht]

You can install the GNU coreutils: http://apple.stackexchange.com/questions/69223/how-to-replac...

[jzelinskie]

Homebrew has packages prefixed with `g`, standing for GNU, that you can install to avoid some of the BSDisms on macOS.

Example: `gsed` actually parses whitespace the way I think it will; the builtin `sed` does not.

[pilif]

> to avoid some of the BSDisms on macOS

to be fair, you should probably call the GNU behaviour "GNUisms". The BSD behaviour is the historical POSIX behaviour. The GNU behaviour is, in a twisted sense, the result of embrace, extend and extinguish by the GNU people :-)

[LukeShu]

With a couple of small exceptions[1], the GNU behavior is also the historical POSIX behavior; the differences that will be jarring are where both BSD and GNU implement things that aren't in POSIX. Yes, the GNU behavior is GNUisms, but the BSD behavior is also BSDisms.

[1]: The most notable thing is that GNU generally allows flags to come before or after non-flag arguments, where POSIX requires them to come before.

[agumonkey]

Isn't dtrace a completely different (and broader) tool than strace ?

[gbrown_]

Yes, dtruss would be a closer equivalent but it is using dtrace under the covers.

[shmerl]

What made you switch to MacOS?

[renaudg]

Not the OP, but the reason I switched to the Mac 12 years ago (and never looked back) was to bring together my nerdy, creative, and "end user" sides under a single OS.

I'd been using mostly Linux on the desktop since 1996, I manage servers for a living and couldn't live without a terminal. That's the nerdy side.

On the other hand, I was serious enough with photography and electronic music production to need best of breed tools, which are still largely Windows and Mac-only to this day.

There's also a time for everything, and there are days when regardless of your computing skills, you need your creative person/end user hat on and apps that "just work" to keep your right brain fully focused on the end result (e.g. "No thanks, I'm not going to get distracted compiling some Gimp plugin to get red-eye removal", which may or may not have changed since I last tried)

MacOS, in spite of its recent slight drop in quality, is still second to none in satisfying all these requirements at once.

[sambe]

You normally do not have to disable security features to run programming/debugging tools, contrary to most of the advice you'll see in forums (and sometimes even Stack Exchange). I haven't used dtrace but non-bundled debuggers were a bit of a pain. You can self-sign these using the procedure described by a quick Google.

[jpitz]

Normally, no, but if you want to dtruss uptime, or any other bog standard system utility, then, yes you do.

[chucksmash]

Very much this. Sometimes the differences are very subtle which makes them more annoying IMO (can you omit the target directory when using `find` if you want to use `pwd`?). For extra points, since you probably aren't deploying on a non-Linux *nix, the PITA will continue in perpetuity.

[johnhenry]

I posted a link to a instructions on getting the GNU equivalent of commonly used BSD programs on OSX yesterday: https://news.ycombinator.com/item?id=13084969

[GFK_of_xmaspast]

> Most — if not all — the commands that I thought I had mastered after years working on Linux environments stopped working because their BSD counterparts have slightly differences that completely break everything I try to do.

This is the true 'unix philosophy.'