4 ms·

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

by mwfunk 8y ago

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.

fabiomaia 8y ago
Specifically how does macOS break by replacing ls with GNU's?
- mwfunk 8y ago
  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).
predakanga 8y ago
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-utilities https://docs.brew.sh/FAQ#my-mac-apps-dont-find-usrlocalbin-u...
- mwfunk 8y ago
  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.

by mwfunk 8y ago

fabiomaia 8y ago

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

mwfunk 8y ago
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).

predakanga 8y ago

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-utilities https://docs.brew.sh/FAQ#my-mac-apps-dont-find-usrlocalbin-u...

mwfunk 8y ago
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.