Some commands have different arguments. ex: I can't do rm -rfd as i do usually in gnu/linux
I've never seen `-d` before. Isn't it redundant with `-r`?
Some Differences Between macOS and Common Unix Systems
31–40 of 82 posts
Re: Some Differences Between macOS and Common Unix Systems
#32I keep hearing that `sudo` insecurity argument everywhere. I think that argument is fundamentally wrong. In practice, a package manager that eschews `sudo` does not protect you any less than a package manager that works with `sudo`. If malware has obtained file system access, it’s already game over. The malicious code can now mess with your shell profile and fake the `sudo` command.
The main problem isn't really that it doesn't require sudo. If it installed as a user into your home dir, that would be fine. Changing a shared system-wide path or installing shared system-wide files owned by a user is so fundamentally borked that you should immediately reject anything offered by anyone who suggested to do that. But the masses of users who made it popular didn't know that and there were/are a lot of…
Since Unix doesn't (traditionally at least) offer any access control mechanism more granular than a User, it was only natural that you'd get a lot of "system users" that are required for all sorts of operations but are not in any way associated with human users.
And now, since you have so many system users and almost always a single human user, you start wanting to install programs that will be used by both yourself and those system users, and it would be extremely problematic to go writing into 10 different bin/ and lib/ folders to install the same thing for 10 users.
Not to mention, a lot of software you want to install also runs some daemons or manages some system settings, and obviously requires root access to do so, but mag run into problems if it is not installed for root.
Re: Some Differences Between macOS and Common Unix Systems
#33Directory services seems more Unix than /etc/group because ‘everything is a file’.
Re: Some Differences Between macOS and Common Unix Systems
#34Is there any particular reason people would go out of their way to use gcc on macOS? It comes with clang/llvm, which seem adequate.
gcc usually produces slightly faster O3 binaries
Re: Some Differences Between macOS and Common Unix Systems
#35Earlier quoted context omitted.
Also > macOS is a great system. It’s based on Unix but if you use it as just another Unix it will be a huge waste. I mean, I guess it's at least true that it's "based on Unix" through its BSD lineage, but still an odd turn of phrase as, as you note, macOS has been an actual, registered, UNIX 03 system since 10.5.
Particularly as the reference UNIX seems to be a Linux with systemd, which isn’t UNIX.
> UNIX
I don't understand why UNIX is such a big deal in 2020. Linux has won, and at least one BSD has binary compatability with Linux. If anything, we should be taking about Linux compliance.
Having no strong package manager story, yet being UNIX compliant, seems like an extremely bizarre priority choice.
Re: Some Differences Between macOS and Common Unix Systems
#36Earlier quoted context omitted.
Particularly as the reference UNIX seems to be a Linux with systemd, which isn’t UNIX.
> UNIX I don't understand why UNIX is such a big deal in 2020. Linux has won, and at least one BSD has binary compatability with Linux. If anything, we should be taking about Linux compliance. Having no strong package manager story, yet being UNIX compliant, seems like an extremely bizarre priority choice.
> at least one BSD has binary compatability with Linux.
Two BSDs (NetBSD and FreeBSD, no OpenBSD, don't know about Dragonfly), and a handful of Illumos distros (who call the feature LX-branded zones).
> If anything, we should be taking about Linux compliance.
Please no; a standard defined by one implementation isn't a standard.
Re: Some Differences Between macOS and Common Unix Systems
#37Not quite on this topic, but I have always felt Linux security seems lagging behind macOS. Linux seems lacking on sufficient sandboxing. I am also increasingly uncomfortable with so many repositories, FOOS on GitHub and users sudoing left and right. I am not sure if I am correct though.
Linux security is technically quite advanced. Namespaces and seccomp-bpf have no parallels in Mac OS land that I'm aware of. It is true that most programs are installed systemwide with no form of sandboxing beyond the usual Unix access controls, but that is starting to change with projects like Flatpak and Snap, which attempt to build a general purpose app sandboxing framework using said security primitives.
Re: Some Differences Between macOS and Common Unix Systems
#38Earlier quoted context omitted.
It’s a no-brainer Mac OS has more Unix heritage than Linux, but I don’t think using certification by the company that happens to own the name is the way to show that. I would think the BSDs have at least as much Unix heritage as macOS, but they aren’t certified (“Certified Unix” is a rare breed. https://www.opengroup.org/openbrand/register/ lists only 13 products) (Nitpick: it isn’t Unix™ , it’s UNIX® )
Certified Unix just means you've paid SCO enough money. There are Linux-based Certified UNIX products: EulerOS and Inspur K-UX.
Thanks. Google gave me https://www.opengroup.org/openbrand/register/brand3596.htm, which links to both http://www.opengroup.org/csq/search/t=XY1.html (Nice layout, BTW. Reminds me of the ‘90) and https://www.opengroup.org/openbrand/register/xy.htm.
Apparently, “conformance statements” are different from “registered products”. I guess one is self-reported and the other is externally verified?
Re: Some Differences Between macOS and Common Unix Systems
#39I keep hearing that `sudo` insecurity argument everywhere. I think that argument is fundamentally wrong. In practice, a package manager that eschews `sudo` does not protect you any less than a package manager that works with `sudo`. If malware has obtained file system access, it’s already game over. The malicious code can now mess with your shell profile and fake the `sudo` command.
The main problem isn't really that it doesn't require sudo. If it installed as a user into your home dir, that would be fine. Changing a shared system-wide path or installing shared system-wide files owned by a user is so fundamentally borked that you should immediately reject anything offered by anyone who suggested to do that. But the masses of users who made it popular didn't know that and there were/are a lot of…
>Changing a shared system-wide path or installing shared system-wide files owned by a user is so fundamentally borked that you should immediately reject anything offered by anyone who suggested to do that.
I don't think that's fair to the homebrew developers. They chose a justifiable tradeoff - as you said most mac systems are single user systems and their design offers better protection to a far larger group of users. When you run `brew install ffmpeg` you are running an arbitrary ruby script from Homebrew git repo and it's probably better that it doesn't run as root. I can't see how that is bad advice; I'd argue that the opposite - sticking to "tradition" despite the changing the landscape of how personal devices have changed security is the broken mindset.
I'm sure most macOS users are far more concerned about an arbitrary script exfiltrating their keychain than some contrived multi-user setup where another user installs a keylogger in the system path.
Re: Some Differences Between macOS and Common Unix Systems
#40Earlier quoted context omitted.
macOS does not come with llvm/clang, you have to download Xcode, which you can't do anonymously, you need to create an account with Apple. Ages ago, macOS did actually come with gcc.
You can install the toolchain with `xcode-select` which does not require an Apple ID.
And if I'm not mistaken, until clang is installed commands like "clang" and "gcc" redirect to xcode-select, so if the user tries to compile something the system will offer to install the toolchain for you.