Hacker News Reader

Comment by otherflavors | Hacker News Reader

They lost me at " replacing pre-installed BSD programs..."

Not too bad and pretty clear description, actually:

linuxify_formulas=( # GNU programs non-existing in macOS "watch" "wget" "wdiff --with-gettext" "gdb"

    # GNU programs whose BSD counterpart is installed in macOS
    "coreutils"
    "binutils"
    "diffutils"
    "ed --with-default-names"
    "findutils --with-default-names"
    "gawk"
    "gnu-indent --with-default-names"
    "gnu-sed --with-default-names"
    "gnu-tar --with-default-names"
    "gnu-which --with-default-names"
    "grep --with-default-names"
    "gzip"
    "screen"

    # GNU programs existing in macOS which are outdated
    "bash"
    "emacs"
    "gpatch"
    "less"
    "m4"
    "make --with-default-names"
    "nano"
    "bison"

    # BSD programs existing in macOS which are outdated
    "flex"

    # Other common/preferred programs in GNU/Linux distributions
    "libressl"
    "file-formula"
    "git"
    "openssh"
    "perl"
    "python"
    "rsync"
    "unzip"
    "vim --override-system-vi"
)

I guess things can technically break. I have not seen it happen yet though. The binaries have not been replaced, it's basically all just a bunch of $PATH overrides which you can easily and conveniently undo.

I switch between macOS and Linux on a daily basis. For me the benefit is in maintaining consistent dotfiles, scripts and workflow across macOS and Linux.

I was fully expecting comments on things breaking, and hopefully get something out of that discussion to improve the script (or maybe even deprecate it if it's demonstrably such a shitty idea).

Very bad idea, and one that will cause a lot of breakage. There’s a reason every package management system on Mac uses its own prefix.

What are you talking about? I've been using a similar homegrown setup for many years and never had any issues. In fact, I've come to appreciate being able to write directly on my Mac shell scripts destined to run on Linux boxen in production.

I had a similar goal I guess: make my dotfiles, scripts and workflow the same across macOS and Linux. :)

I understand things can break, but I have yet to run into such issues. Specifically, what exactly can break by replacing e.g. coreutils with GNU's?

I haven't ever broken macOS doing stuff like that, and I've been doing it for years, with both Macports and Homebrew.

I use the default prefix and make sure the Homebrew stuff is in my $PATH before the built-in stuff and it works fine.

Why? Many times I've encountered problems with BSD utilities in mac. Sometimes the options are under different switches, sometimes they simply don't exist.

I wouldn't use this script because I dislike installing so many packages that I don't need.

The BSD system tools aren’t always 100% compatible with the equivalent GNU tools, and vice versa. If you replace something built into the system with something else, then anything that’s properly written to deal with macOS might break. It might make some other immediate issue easier to deal with in some way, but it becomes a time bomb that will almost certainly break something else in the future.

I’m specifically talking about (for example) overwriting /bin/ls with GNU ls. If someone simply prefers a GNU equivalent, they can trivially install GNU ls somewhere else on the system and use it all they want without blowing away part of the OS.

Specifically how does macOS break by replacing ls with GNU's?

It’s less that any one particular thing breaks instantly, and more that it destabilizes the system in general. Mac installers often contain shell scripts, for example, and those scripts are going to assume that the core OS tools being invoked by those scripts are the ones that shipped with the OS. Software updates and all sorts of other under-the-hood things contain shell scripts or make assumptions about those tools, their behaviors, and how to invoke them.

Imagine taking an Ubuntu box and overwriting every single core utility with a recompiled version of the utility of the same name from OpenBSD. You might think that’s a bad idea- same reasons, same risks. Sure, everything might work (and probably will), but it’s fundamentally destabilizing a working system.

And for what benefit? Just so some developer doesn’t have to be bothered with learning the differences between GNU and BSD runtimes? That just seems like a terrible tradeoff, and I wouldn’t want to work with someone who both didn’t know the difference and couldn’t be bothered to learn.

Like, if someone can’t be bothered to learn the OS that they’re working on, then there’s a simple solution: don’t use that OS. But if getting something done on that platform is a requirement, then they should take the time to do it properly, and beyond entry-level people I would simply expect any developer worth their salt to get their job done on the platform they’re developing for or deploying to. It’s not a lot to ask, it’s not a high bar, it’s a pretty reasonable expectation for a professional. People shouldn’t half-ass something like that just because they think they are too special or precious to spend time learning how to do their job.

EDIT: if it’s not obvious, I’m specifically talking about developing for a given platform in a professional capacity. I don’t care what people do for fun or education or hacking around- not unlike using a Hackintosh or jailbreaking a device. I don’t mean to sound judgy or anything (outside of a > entry level professional context).

If someone simply prefers a GNU equivalent, they can trivially install GNU ls somewhere else on the system and use it all they want without blowing away part of the OS.

That's exactly what this does. The script uses Homebrew, which installs all software into /usr/local - this is empty on a standard macOS install, and is not in PATH for regular Mac apps[1].

Homebrew also prefixes GNU tools by default so that you can use "ls" for BSD and "gls" for GNU, but this script disables that.

[1]: https://docs.brew.sh/FAQ#my-mac-apps-dont-find-usrlocalbin-u...

That’s totally reasonable, although my personal paranoia about such things would want to keep it aliased as gls. :) Too many bad experiences bouncing between Unices.

Also I would strongly disagree with “some switches are different” being a problem, any more than FreeBSD not being Ubuntu is a problem. It’s a different OS so it should be treated as one. See also people going onto Linux forums and complaining about how there’s no Start button. Like, I get it, but that’s a problem with user expectations, not a problem with Linux.

It's not a problem! But I am constantly switching between macOS and Linux, so being able to share dotfiles and scripts and not have to learn the differences and inconsistencies between CLI tools is nice. That was my main motivation, and I think other people feel the same way.

I get it, it can be super handy to share dotfiles, etc. I’ve just learned to be super paranoid about crossing the BSD and GNU streams. As long as it’s not literally blowing away files installed by the OS, then there are nonintrusive and convenient ways to keep both runtimes installed (which is mostly what this project does).

I also have dotfiles that I keep synced between Linux and Mac systems. I don’t have anything super fancy, but in the cases where the platforms differ I’ve conditionalized those parts of the scripts/dotfiles/etc. on a per-platform basis.

My likely bias here is that I am fascinated by all of the little differences between platforms and rarely want to paper over them. Similarly, I can never bring myself to use a universal remote because there’s always something lost in translation vs. the remotes it replaces (also I may have a remote control collection problem).

I'm sure that's some kind of elitism. Do it the right (my) way, or don't do it at all.

I'm not interested nor have time to learn how all the differences between osx and linux, specially since installing the GNU utilities is good enough for 95% of tasks.

Not at all, just offering a professional opinion. If you’re going to develop on or for a different platform, it’s worth it to learn about that platform. Nobody ever fucked anything up by being too knowledgeable or competent. It’s the path of least risk and improves the developer as well.

Reply on news.ycombinator.com