10 ms·

Some Differences Between macOS and Common Unix Systems

173 points by dongyx 6y ago

tomcam 6y ago
Thank you! Helps me in general, but in particular as I write documentation for some cross-platform software.
yjftsjthsd-h 6y ago
> Some Differences between macOS and Common Unix Systems ...by which is meant, "Some differences between macOS, a certified Unix™, and systemd/Linux". Which is fine and valuable! But macOS is the most common Unix™, so the title as written is... entertaining.
- masklinn 6y ago
  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.
  - kergonath 6y ago
    Particularly as the reference UNIX seems to be a Linux with systemd, which isn’t UNIX.
    - mhh__ 6y ago
      De facto or de jure? Linux isn't technically one, sure, but given that Linux is where the OS hot-shit is now (e.g. eBPF, although I think FreeBSD has the basics - no idea whether it got merged but I saw a student project) is it not fair to say it's where Unix would've been had things been different?
      - kergonath 6y ago
        Both, I would say, particularly with the GNU’s Not UNIX userland. I don’t think it matters much, though, as you can have a great non-UNIX OS, which Linux definitely is. Also, we might forget it now, but in the past there were a lot of UNIX that were quite different in small and large ways. The differences between Linux and Darwin might be as great as the differences between SunOS and Xenix, or indeed NeXTSTEP, back in the day. Or maybe not, that was before my time, but my point is that UNIX was not a monolith and there were incompatibilities and different ways of doing things. So I guess yeah, Linux might be what one of these might have become. I just find it ironic that so many people are keen to compare macOS to UNIX and just assume that macOS has to be the weird outsider, even though the reverse is actually true. The same people also often assume Linux-isms are the way UNIX works, like the now-dead comment about macOS’ commands not supporting GNU options.
        icedchai 6y ago
        Outside of macOS, commercial Unix is basically dead. In the old days I used to see all sorts of systems. One company had Solaris 2.x, SunOS 4.x, Digital Unix, HPUX, AIX. Now you rarely see anything other than Linux, though I still know a couple of AIX shops that went all in on IBM hardware and still swear by it. Like it or not, right or wrong, when people say "Unix" today, they mean Linux with GNU userland.
        skissane 6y ago
        The IBM mainframe operating system z/OS (formerly known as MVS) is a certified UNIX 95. (That's an older UNIX standard, but still valid.) There are still a lot of IBM mainframes out there. Far less than there used to be, but IBM mainframes remain (even in 2020) a sector with many billions of dollars of annual revenue (if you add up hardware and software and services across both IBM and the ISV ecosystem). And the vast majority of those mainframes run z/OS. (They also run other operating systems – z/Linux, z/VM, z/VSE and z/TPF – but many of the sites running one of those other operating systems run z/OS as well.) The UNIX component of z/OS is not merely a compatibility layer, a lot of operating system components and applications now rely on it. For example, the REST-based z/OS management console Zowe that IBM is now promoting runs under z/OS UNIX. My understanding is that IBM prefers (where possible) to develop new OS components and applications to run under z/OS UNIX rather than the traditional z/OS APIs. Anything written in Java (or other newer languages, such as node.js) is running on z/OS UNIX. So even if a z/OS site isn't doing anything directly on UNIX, they are almost certainly using OS components and applications which directly rely on it to function. Obviously z/OS is absolutely dwarfed by Linux and macOS, but it is probably the healthiest of all the commercial Unixes – Oracle has put Solaris in maintenance mode, same for HPE and HP/UX, HPE killed Digital Unix years ago; AIX is healthier than Solaris or HP/UX, but I think z/OS is even healthier than AIX. z/OS licensing fees are a lot higher than AIX licensing fees, and the non-UNIX parts of z/OS (JCL, VSAM, CICS, IMS, etc) make it far harder to migrate off than AIX is.
    - deleted 6y ago
      [deleted]
    - zamalek 6y ago
      > 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.
      - yjftsjthsd-h 6y ago
        > 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.
        jcelerier 6y ago
        > Please no; a standard defined by one implementation isn't a standard Linux has another implementation: WSL 1
        saagarjha 6y ago
        Linux has many implementations; some are more complete than others.
      - kergonath 6y ago
        There is some value in standards such as UNIX and POSIX compared to whatever the maintainers of a GNU project decided this morning. As for your second point, it just means that package management is irrelevant to UNIX (or POSIX) compliance. It did not prevent different package managers to appear over the years, because all the expected infrastructure was in place.
        zamalek 6y ago
        > It did not prevent different package managers But did these UNIX package managers actually materialize? I guess my point is: is UNIX at all relevant? It had some really good ideas that were worth copying, but the world has moved on to greater ideas.
- deleted 6y ago
  [deleted]
- Someone 6y ago
  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/ https://www.opengroup.org/openbrand/register/ lists only 13 products) (Nitpick: it isn’t Unix™, it’s UNIX®)
  - beezle 6y ago
    I don't think the 'certified unix' moniker counts for very much at all. It is uncertain that any non-corporately maintained Linux distro could qualify (per the opengroup page) as the kernel is developed outside of the distro. The BSD's on the other hand could probably apply as they are one system (kernel and userland) with one governing body. But I doubt they really care to play the corporate standard mark game. They are UNIX and have always been so.
  - loeg 6y ago
    Certified Unix just means you've paid SCO enough money. There are Linux-based Certified UNIX products: EulerOS and Inspur K-UX.
    - Someone 6y ago
      Thanks. Google gave me https://www.opengroup.org/openbrand/register/brand3596.htm https://www.opengroup.org/openbrand/register/brand3596.htm, which links to both http://www.opengroup.org/csq/search/t=XY1.html 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 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?
      - skissane 6y ago
        > Apparently, “conformance statements” are different from “registered products”. I guess one is self-reported and the other is externally verified? Products get dropped from the register if the vendor fails to pay renewal fees. The product no longer appears on the register page, but the page on the product is not taken down and can still be directly accessed. This is what has happened to both Inspur K-UX and Oracle Solaris (and I'm pretty sure a few more over the years).
- shawnz 6y ago
  It's true mac OS is the most common Unix, but that doesn't mean it's the only Unix which could be considered common.
- deleted 6y ago
  [deleted]
- konjin 6y ago
  I worked at a Telco that ran over 100k Linux VMs in one department. Not sure about unix certified os's, but mac os has a much smaller install base than linux.
  - rualca 6y ago
    > Not sure about unix certified os's, but mac os has a much smaller install base than linux. No, not really. macos's market share is about 4 times the aggregate market share of all Linux-based distributions.
- 1vuio0pswjnm7 6y ago
  macOS claims to be UNIX yet "XNU", the macOS kernel, is an abbreviation for "X is not UNIX". "Linux" refers to a kernel, inspired by Minix, which is an abbreviation for "mini-UNIX".
  - ahartmetz 6y ago
    Linux is not based on Minix. What Linux does do is that it supports most everything required for POSIX compatibility.
    - cyberdelica 6y ago
      He wrote inspired by, not based on - which is true. Linus Torvalds was inspired by Minix, to write Linux.
      - ahartmetz 6y ago
        I think the comment I replied to was edited.
hegzploit 6y ago
Some commands have different arguments. ex: I can't do rm -rfd as i do usually in gnu/linux
- branzo 6y ago
  small differences between BSDs' userland and GNU's.
- loeg 6y ago
  I've never seen `-d` before. Isn't it redundant with `-r`?
  - hegzploit 6y ago
    yeah probably, i just always stick them together whether i'm deleting or copying with a wildcard.
kergonath 6y ago
Interesting post; not sure I agree with all of it, though. For example, I would not say /Library is equivalent to /usr/lib. /Library has lots of things that are not libraries as in .a or .so (actually .dylib) files and that would be in various different subdirectories somewhere on Linux. Also, it’s a bit deceptive to show how you need 10 commands to add a user before saying you can do it all at once with a tool that was introduced 6 years ago. And I’ve never had to use -isysroot with GCC from MacPorts, though I can believe that it is necessary in some special cases. I think the post articulates well the issues with Homebrew, though.
deleted 6y ago
[deleted]
aborsy 6y ago
Not 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.
- curt15 6y ago
  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.
- smoldesu 6y ago
  MacOS is it's own security nightmare, it's just mangled and unrecognizable through so many layers of abstraction. Apple's understanding of security and privacy is fundamentally broken: they protect you against a boogyman, the idea of someone who wants to take your data for exploitative gain. In reality, the paradigm of computer security has completely changed. Apple had been leaking unencrypted user data to third party firms for years, and refused to yield when researchers warned them of the implications. Thunderbolt is rife with security vulnerabilities, some exploits being so advanced that they can give the attacker a raw dump of whatever was in memory (which is ironically even more dangerous thanks to MacOS' lackluster memory management). At the end of the day, securing MacOS is a losing game. Big Sur introduced new, untraceable telemetry at the lowest levels of the system, basically forcing me out of the Mac game. Linux it a breath of fresh air by comparison: not only does my system never phone home, it gets security updates as a first-class citizen in the software world (one of the many perks of being the backbone of most computer infrastructure). Security on Linux is entirely dependent on the user. One of the core Unix philosophies is that a true Unix system won't stop a dumb user from doing something dumb, because that impedes clever people trying to do something clever. The weakest link in the security chain is always the end user, which is why most "hacks" these days are just massive phishing campaigns: it's just an easier attack vector. It doesn't matter if you're on Windows, MacOS, Linux or TempleOS - if you put your credentials into a browser, someone's gonna pwn it. P.S. - If sandboxing is your interest, you should check out Flatpak. I think it should clear up your repo concerns too ;)
Hackbraten 6y ago
I 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.
- Brian_K_White 6y ago
  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 them, and the reason it's wrong won't bite many people because their macbooks only have one user account, and so you have a zillion people who didn't know they were getting bad advice and doing a broken thing, and if you tell them now, they don't see it because they've been doing it wrong for years and their house didn't burn down, and they vastly outnumber the people who unserstand the problem and would never have designed something so broken in the first place, and so it just stays both incorrect and the standard.
  - bigbubba 6y ago
    Can you spoonfeed me here? If ~/bin is in my PATH and is writable to my user, what is the problem with /usr/local/bin being the same on my personal computer with a single human user?
    - theamk 6y ago
      Base case (those are true AFAIK): - /usr/local/bin is in a "system-wide" default PATH, (and it is even in front of /bin !) - There is an important service, like Time Machine, which needs root access for important actions -- for example, to erase previous backups - There could be a vulnerability in an application which gets data from the internet -- for the sake of example, let's say it is "foo file viewer". This can be exploited for code execution. --- Case 1: Packages in ~/bin, /usr/local/bin is read-only: A user wants to look at a "foo file" from the internet. The file is malicious, it exploits "foo viewer" and gets local execution. It is a cryptolocker, so it encrypts all the user documents. The malware has installed trojaned "~/bin/sudo" wrapper, but since the user does not use "sudo" that often, it did not have a change to get executed. And none of the system services look into user's "~/bin". A week later, user notices that a document is encrypted. But the time machine backups are still OK. They reformat their machine, and then use time machine backup to restore the documents. Day is saved! --- Case 2: Packages in usr/local/bin: A user wants to look at a "foo file" from the internet. The file is malicious, it exploits "foo viewer" and gets local execution. It is a cryptolocker, so it encrypts all the user documents. The malware has installed a bunch of trojaned binaries, including "/usr/local/bin/touch" binary. Unfortunately, there is a LaunchDaemon which runs the script periodically which contains the line "touch /some/file". That is run as root, so in a short time, the malware gets root access. And it immediately used this access to disable time machine and delete all the backups. A week later, user notices that a document is encrypted. And the time machine backups are gone, too. Oh no! the documents are lost unless they pay the ransom! --- You might notice that some people may consider the scenario unrealistic: What if the user uses command line a lot, and is used to running "sudo"? What if a malware social engineers user by popping up a fake dialog asking for user password? Are there other privilege escalation methods? How often does this happen anyway? You should make your own decisions, but hopefully you at least see what the people are concerned about.
Brian_K_White 6y ago
Been saying the same thing about homebrew for years. It's ridiculous. No one should use homebrew, and macports is far more correct, but it's pointless to say it.
jeffbee 6y ago
Is there any particular reason people would go out of their way to use gcc on macOS? It comes with clang/llvm, which seem adequate.
- tyingq 6y ago
  Some specific pieces of C++ support that Clang is missing: Edit: newer link: https://clang.llvm.org/cxx_status.html https://clang.llvm.org/cxx_status.html (older link, not applicable, was here) Cross compiling for some embedded architectures. Things like FORTRAN or Ada, calling routines built there from C (or vice versa), etc.
  - jeffbee 6y ago
    I don't know where you dug that up. That doc must be at least 10 years old. The clang that you get on an actual mac these days fully supports everything through C++17.
    - tyingq 6y ago
      Thanks. Updated with a current link.
- 1over137 6y ago
  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.
  - jeffbee 6y ago
    You can install the toolchain with `xcode-select` which does not require an Apple ID.
    - kitsunesoba 6y ago
      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.
Technically 6y ago
This completely neglects all the non-gnu unixes.
lookdangerous 6y ago
Directory services seems more Unix than /etc/group because ‘everything is a file’.
forgotmypw17 6y ago
I don't see any top-level comments mentioning POSIX, so I'm here to right that wrong: POSIX.
woleium 6y ago
Consider using nix over homebrew / macports, it's pretty good on mac now. This is a reasonable intro doc https://wickedchicken.github.io/post/macos-nix-setup/ https://wickedchicken.github.io/post/macos-nix-setup/

173 points by dongyx 6y ago

Thank you! Helps me in general, but in particular as I write documentation for some cross-platform software.

> Some Differences between macOS and Common Unix Systems ...by which is meant, "Some differences between macOS, a certified Unix™, and systemd/Linux". Which is fine and valuable! But macOS is the most common Unix™, so the title as written is... entertaining.

masklinn 6y ago
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.
- kergonath 6y ago
  Particularly as the reference UNIX seems to be a Linux with systemd, which isn’t UNIX.
  - mhh__ 6y ago
    De facto or de jure? Linux isn't technically one, sure, but given that Linux is where the OS hot-shit is now (e.g. eBPF, although I think FreeBSD has the basics - no idea whether it got merged but I saw a student project) is it not fair to say it's where Unix would've been had things been different?
    - kergonath 6y ago
      Both, I would say, particularly with the GNU’s Not UNIX userland. I don’t think it matters much, though, as you can have a great non-UNIX OS, which Linux definitely is. Also, we might forget it now, but in the past there were a lot of UNIX that were quite different in small and large ways. The differences between Linux and Darwin might be as great as the differences between SunOS and Xenix, or indeed NeXTSTEP, back in the day. Or maybe not, that was before my time, but my point is that UNIX was not a monolith and there were incompatibilities and different ways of doing things. So I guess yeah, Linux might be what one of these might have become. I just find it ironic that so many people are keen to compare macOS to UNIX and just assume that macOS has to be the weird outsider, even though the reverse is actually true. The same people also often assume Linux-isms are the way UNIX works, like the now-dead comment about macOS’ commands not supporting GNU options.
      - icedchai 6y ago
        Outside of macOS, commercial Unix is basically dead. In the old days I used to see all sorts of systems. One company had Solaris 2.x, SunOS 4.x, Digital Unix, HPUX, AIX. Now you rarely see anything other than Linux, though I still know a couple of AIX shops that went all in on IBM hardware and still swear by it. Like it or not, right or wrong, when people say "Unix" today, they mean Linux with GNU userland.
        skissane 6y ago
        The IBM mainframe operating system z/OS (formerly known as MVS) is a certified UNIX 95. (That's an older UNIX standard, but still valid.) There are still a lot of IBM mainframes out there. Far less than there used to be, but IBM mainframes remain (even in 2020) a sector with many billions of dollars of annual revenue (if you add up hardware and software and services across both IBM and the ISV ecosystem). And the vast majority of those mainframes run z/OS. (They also run other operating systems – z/Linux, z/VM, z/VSE and z/TPF – but many of the sites running one of those other operating systems run z/OS as well.) The UNIX component of z/OS is not merely a compatibility layer, a lot of operating system components and applications now rely on it. For example, the REST-based z/OS management console Zowe that IBM is now promoting runs under z/OS UNIX. My understanding is that IBM prefers (where possible) to develop new OS components and applications to run under z/OS UNIX rather than the traditional z/OS APIs. Anything written in Java (or other newer languages, such as node.js) is running on z/OS UNIX. So even if a z/OS site isn't doing anything directly on UNIX, they are almost certainly using OS components and applications which directly rely on it to function. Obviously z/OS is absolutely dwarfed by Linux and macOS, but it is probably the healthiest of all the commercial Unixes – Oracle has put Solaris in maintenance mode, same for HPE and HP/UX, HPE killed Digital Unix years ago; AIX is healthier than Solaris or HP/UX, but I think z/OS is even healthier than AIX. z/OS licensing fees are a lot higher than AIX licensing fees, and the non-UNIX parts of z/OS (JCL, VSAM, CICS, IMS, etc) make it far harder to migrate off than AIX is.
  - deleted 6y ago
    [deleted]
  - zamalek 6y ago
    > 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.
    - yjftsjthsd-h 6y ago
      > 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.
      - jcelerier 6y ago
        > Please no; a standard defined by one implementation isn't a standard Linux has another implementation: WSL 1
        saagarjha 6y ago
        Linux has many implementations; some are more complete than others.
    - kergonath 6y ago
      There is some value in standards such as UNIX and POSIX compared to whatever the maintainers of a GNU project decided this morning. As for your second point, it just means that package management is irrelevant to UNIX (or POSIX) compliance. It did not prevent different package managers to appear over the years, because all the expected infrastructure was in place.
      - zamalek 6y ago
        > It did not prevent different package managers But did these UNIX package managers actually materialize? I guess my point is: is UNIX at all relevant? It had some really good ideas that were worth copying, but the world has moved on to greater ideas.
deleted 6y ago
[deleted]
Someone 6y ago
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/ https://www.opengroup.org/openbrand/register/ lists only 13 products) (Nitpick: it isn’t Unix™, it’s UNIX®)
- beezle 6y ago
  I don't think the 'certified unix' moniker counts for very much at all. It is uncertain that any non-corporately maintained Linux distro could qualify (per the opengroup page) as the kernel is developed outside of the distro. The BSD's on the other hand could probably apply as they are one system (kernel and userland) with one governing body. But I doubt they really care to play the corporate standard mark game. They are UNIX and have always been so.
- loeg 6y ago
  Certified Unix just means you've paid SCO enough money. There are Linux-based Certified UNIX products: EulerOS and Inspur K-UX.
  - Someone 6y ago
    Thanks. Google gave me https://www.opengroup.org/openbrand/register/brand3596.htm https://www.opengroup.org/openbrand/register/brand3596.htm, which links to both http://www.opengroup.org/csq/search/t=XY1.html 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 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?
    - skissane 6y ago
      > Apparently, “conformance statements” are different from “registered products”. I guess one is self-reported and the other is externally verified? Products get dropped from the register if the vendor fails to pay renewal fees. The product no longer appears on the register page, but the page on the product is not taken down and can still be directly accessed. This is what has happened to both Inspur K-UX and Oracle Solaris (and I'm pretty sure a few more over the years).
shawnz 6y ago
It's true mac OS is the most common Unix, but that doesn't mean it's the only Unix which could be considered common.
deleted 6y ago
[deleted]
konjin 6y ago
I worked at a Telco that ran over 100k Linux VMs in one department. Not sure about unix certified os's, but mac os has a much smaller install base than linux.
- rualca 6y ago
  > Not sure about unix certified os's, but mac os has a much smaller install base than linux. No, not really. macos's market share is about 4 times the aggregate market share of all Linux-based distributions.
1vuio0pswjnm7 6y ago
macOS claims to be UNIX yet "XNU", the macOS kernel, is an abbreviation for "X is not UNIX". "Linux" refers to a kernel, inspired by Minix, which is an abbreviation for "mini-UNIX".
- ahartmetz 6y ago
  Linux is not based on Minix. What Linux does do is that it supports most everything required for POSIX compatibility.
  - cyberdelica 6y ago
    He wrote inspired by, not based on - which is true. Linus Torvalds was inspired by Minix, to write Linux.
    - ahartmetz 6y ago
      I think the comment I replied to was edited.

hegzploit 6y ago

Some commands have different arguments. ex: I can't do rm -rfd as i do usually in gnu/linux

branzo 6y ago
small differences between BSDs' userland and GNU's.
loeg 6y ago
I've never seen `-d` before. Isn't it redundant with `-r`?
- hegzploit 6y ago
  yeah probably, i just always stick them together whether i'm deleting or copying with a wildcard.

kergonath 6y ago

Interesting post; not sure I agree with all of it, though. For example, I would not say /Library is equivalent to /usr/lib. /Library has lots of things that are not libraries as in .a or .so (actually .dylib) files and that would be in various different subdirectories somewhere on Linux. Also, it’s a bit deceptive to show how you need 10 commands to add a user before saying you can do it all at once with a tool that was introduced 6 years ago. And I’ve never had to use -isysroot with GCC from MacPorts, though I can believe that it is necessary in some special cases. I think the post articulates well the issues with Homebrew, though.

deleted 6y ago

[deleted]

aborsy 6y ago

Not 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.

curt15 6y ago
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.
smoldesu 6y ago
MacOS is it's own security nightmare, it's just mangled and unrecognizable through so many layers of abstraction. Apple's understanding of security and privacy is fundamentally broken: they protect you against a boogyman, the idea of someone who wants to take your data for exploitative gain. In reality, the paradigm of computer security has completely changed. Apple had been leaking unencrypted user data to third party firms for years, and refused to yield when researchers warned them of the implications. Thunderbolt is rife with security vulnerabilities, some exploits being so advanced that they can give the attacker a raw dump of whatever was in memory (which is ironically even more dangerous thanks to MacOS' lackluster memory management). At the end of the day, securing MacOS is a losing game. Big Sur introduced new, untraceable telemetry at the lowest levels of the system, basically forcing me out of the Mac game. Linux it a breath of fresh air by comparison: not only does my system never phone home, it gets security updates as a first-class citizen in the software world (one of the many perks of being the backbone of most computer infrastructure). Security on Linux is entirely dependent on the user. One of the core Unix philosophies is that a true Unix system won't stop a dumb user from doing something dumb, because that impedes clever people trying to do something clever. The weakest link in the security chain is always the end user, which is why most "hacks" these days are just massive phishing campaigns: it's just an easier attack vector. It doesn't matter if you're on Windows, MacOS, Linux or TempleOS - if you put your credentials into a browser, someone's gonna pwn it. P.S. - If sandboxing is your interest, you should check out Flatpak. I think it should clear up your repo concerns too ;)

Hackbraten 6y ago

I 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.

Brian_K_White 6y ago
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 them, and the reason it's wrong won't bite many people because their macbooks only have one user account, and so you have a zillion people who didn't know they were getting bad advice and doing a broken thing, and if you tell them now, they don't see it because they've been doing it wrong for years and their house didn't burn down, and they vastly outnumber the people who unserstand the problem and would never have designed something so broken in the first place, and so it just stays both incorrect and the standard.
- bigbubba 6y ago
  Can you spoonfeed me here? If ~/bin is in my PATH and is writable to my user, what is the problem with /usr/local/bin being the same on my personal computer with a single human user?
  - theamk 6y ago
    Base case (those are true AFAIK): - /usr/local/bin is in a "system-wide" default PATH, (and it is even in front of /bin !) - There is an important service, like Time Machine, which needs root access for important actions -- for example, to erase previous backups - There could be a vulnerability in an application which gets data from the internet -- for the sake of example, let's say it is "foo file viewer". This can be exploited for code execution. --- Case 1: Packages in ~/bin, /usr/local/bin is read-only: A user wants to look at a "foo file" from the internet. The file is malicious, it exploits "foo viewer" and gets local execution. It is a cryptolocker, so it encrypts all the user documents. The malware has installed trojaned "~/bin/sudo" wrapper, but since the user does not use "sudo" that often, it did not have a change to get executed. And none of the system services look into user's "~/bin". A week later, user notices that a document is encrypted. But the time machine backups are still OK. They reformat their machine, and then use time machine backup to restore the documents. Day is saved! --- Case 2: Packages in usr/local/bin: A user wants to look at a "foo file" from the internet. The file is malicious, it exploits "foo viewer" and gets local execution. It is a cryptolocker, so it encrypts all the user documents. The malware has installed a bunch of trojaned binaries, including "/usr/local/bin/touch" binary. Unfortunately, there is a LaunchDaemon which runs the script periodically which contains the line "touch /some/file". That is run as root, so in a short time, the malware gets root access. And it immediately used this access to disable time machine and delete all the backups. A week later, user notices that a document is encrypted. And the time machine backups are gone, too. Oh no! the documents are lost unless they pay the ransom! --- You might notice that some people may consider the scenario unrealistic: What if the user uses command line a lot, and is used to running "sudo"? What if a malware social engineers user by popping up a fake dialog asking for user password? Are there other privilege escalation methods? How often does this happen anyway? You should make your own decisions, but hopefully you at least see what the people are concerned about.

Brian_K_White 6y ago

Been saying the same thing about homebrew for years. It's ridiculous. No one should use homebrew, and macports is far more correct, but it's pointless to say it.

jeffbee 6y ago

Is there any particular reason people would go out of their way to use gcc on macOS? It comes with clang/llvm, which seem adequate.

tyingq 6y ago
Some specific pieces of C++ support that Clang is missing: Edit: newer link: https://clang.llvm.org/cxx_status.html https://clang.llvm.org/cxx_status.html (older link, not applicable, was here) Cross compiling for some embedded architectures. Things like FORTRAN or Ada, calling routines built there from C (or vice versa), etc.
- jeffbee 6y ago
  I don't know where you dug that up. That doc must be at least 10 years old. The clang that you get on an actual mac these days fully supports everything through C++17.
  - tyingq 6y ago
    Thanks. Updated with a current link.
1over137 6y ago
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.
- jeffbee 6y ago
  You can install the toolchain with `xcode-select` which does not require an Apple ID.
  - kitsunesoba 6y ago
    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.

Technically 6y ago

This completely neglects all the non-gnu unixes.

lookdangerous 6y ago

Directory services seems more Unix than /etc/group because ‘everything is a file’.

forgotmypw17 6y ago

I don't see any top-level comments mentioning POSIX, so I'm here to right that wrong: POSIX.

woleium 6y ago

Consider using nix over homebrew / macports, it's pretty good on mac now. This is a reasonable intro doc https://wickedchicken.github.io/post/macos-nix-setup/ https://wickedchicken.github.io/post/macos-nix-setup/