OSX may have been certified as Unix, but it has been diverging from its ancestor so much that it no longer feels Unix-like in the least.
Some examples:
- no/dev (bye-bye Unix philosophy cornerstone "everything is a file"); - unusable "locate" that doesn't find all the stuff it should (because Apple wants you to use Spotlight, the command line is bad, you silly!); - much of the userland isn't aware of the HFS+ filesystem extensions (have fun cp'ing files, discovering months later that - oops! - the stuff had a resource fork and is now unusable -- verrry dependable!); - case insensitive filesystem by default, you could switch to case sensitive for compatibility with any other Unix in the universe (have fun reformatting and reinstalling) but - alas! - important application software won't support it (photoshop & others); - no cron! If you want to get it to do things periodically, you either gotta write freaking XML for launchd, or run Vixie Cron in addition to launchd. No thanks!
If OSX is Unix, it's the worst Unix I've ever seen. No serious command line nerd could ever like it (OTOH, it's perfect for know-nothings who like to click on pretty pictures). Using it is a totally different (as in "worse") experience than using any BSD (or Linux!), so spare me the old "OSX is BSD" hearsay!
Correction to the above: it does have/dev, come to think of it, you just don't get to use it much, since you can't choose the mountpoint because mounting is automated!
It's not that. I've updated the db (and I let update it periodically, via launchd) but it still won't find everything (not even regular user-owned stuff).
man CpMac
Yeah, I had come across that one. Then again, you first have to know it exists. Apple won't warn you nor inform you. And when you investigate and find out, it's usually because the regular Unix tools have already wrought havoc.
It's a case-preserving filesystem by default. Because it's a Mac and needs backward-compa
As of Mac OS X 10.4, the cp command preserves metadata and resource forks of files on Extended HFS volumes, so it can be used in place of CpMac. The/usr/bin/CpMac command will be deprecated in future versions of Mac OS X
Yeah, I had come across that one. Then again, you first have to know it exists. Apple won't warn you nor inform you. And when you investigate and find out, it's usually because the regular Unix tools have already wrought havoc.
All of the standard Unix tools for moving / copying files have supported resource forks for some time now. But it's really not a big deal because only Classic / Carbon MacOS apps make use of resource forks. Classic will not run on new hardware and Carbon was depreciated a while ago. If you are a Unix user, I can't imagine a situation where you would want a resource fork.
It's a case-preserving filesystem by default. Because it's a Mac and needs backward-compatibility.
Whatever. Have fun developing on a case-insensitive file system and not noticing case mismatches that will suddenly stop the show when you run your stuff on a proper Unix.
You have it wrong. The file system is not really case-insensitive as per the traditional sense. If you have a file named "SomeFile.
You have it wrong. The file system is not really case-insensitive as per the traditional sense. If you have a file named "SomeFile.pdf" and try to open "SomeFile.Pdf" it will fail. The case is sensitive just as with the other Unix based operating systems. Where it differs is that it will not allow you have files named "Readme" and "readme" in the same location.
> ls dir2 README > mv dir1/readme dir2/ > ls dir2 readme
Bye-bye README! Because of this nonstandard behaviour, I once lost a bunch of files. Tha
Okay, that is fucked up. It's clearly the wrong behavior - BUT, why are you passing the incorrect filename and depending on the OS to match it as case-insensitive?
In my example, both filenames are correct and exist. The point is that the lowercase filename will replace the uppercase filename.
Case sensitivity is the one that hit me. My Lion install is case sensitive, and a lot of programs (don't have PS to try, but can vouch for Steam, Diablo 3 and Starcraft 2) simply don't install.
- no/dev (bye-bye Unix philosophy cornerstone "everything is a file"); - unusable "locate" that doesn't find all the stuff it should (because Apple wants you to use Spotlight, the command line is bad, you silly!); - much of the userland isn't aware of the HFS+ filesystem extensions (have fun cp'ing files, discovering months later that - oops! - the stuff had a resource fork and is now unusable -- verrry dependable!); - case insensitive filesystem by default, you could switch to case sensitive for compatibility with any other Unix in the universe (have fun reformatting and reinstalling) but - alas! - important application software won't support it (photoshop & others); - no cron! If you want to get it to do things periodically, you either gotta write freaking XML for launchd, or run Vixie Cron in addition to launchd. No thanks!
If OSX is Unix, it's the worst Unix I've ever seen. No serious command line nerd could ever like it (OTOH, it's perfect for know-nothings who like to click on pretty pictures). Using it is a totally different (as in "worse") experience than using any BSD (or Linux!), so spare me the old "OSX is BSD" hearsay!
So you noticed that/dev/ still exists. Well done. Although mounting is automatic (which I hardly see as being a bad feature and something unique to Mac OS X) there's no reason why you can't manually mount stuff as you wish. man mount.
On locate, log a bug if it's not working as intended. This is what techie people do. I'd opt for mdfind unless I have a script that *absolutely must* use locate. mdfind is fast and isn't reliant upon having an up-to-date locate database.
There seem to be some uninformed posters here, so here is the OS X relationship to BSD: The OS X/iOS kernel is based on Mach, which is a microkernel mashed together with a BSD kernel. It has a lot of BSD code in it and continues to share code with the other BSDs. It has features borrowed from BSD such as DTrace, PF firewall, file system support (including ZFS before it was removed), the networking subsystem, kqueue, jails, and others. While Mach is fundamentally different in some ways, to a POSIX binary it looks and feels just like any other BSD system.
The OS X userland is also based on BSD and was originally derived from FreeBSD. It uses the BSD libc and many of the command line tools are from the BSD world (from grep to ssh). It also includes some GNU tools, such as bash. Apple is actively working on replacing many of these, and they recently dropped GCC and GDB and replaced them with Clang and LLDB.
It has a lot of BSD code in it and continues to share code with the other BSDs.
Really? I was under the impression that Apple do not distribute any source code for Darwin on ARM. Please show me where I can obtain the XNU ARM kernel source that is used in iOS.
Why would you need that? The platform-specific part of the kernel is a fairly minor part of the overall code. There's a lot more code investment in the VM, the FS, the network stack, and other major kernel subsystems, which are all generic code and distributed to the public, than the specific implementations of low level locks, interrupts, and page table map managers. The fact that we can't build and run XNU on ARM doesn't mean that we can't share code with it.
OSX is doing great (Score:0, Interesting)
Oh, he forgot that one.
Re: (Score:2)
Re:OSX is doing great (Score:5, Informative)
OSX may have been certified as Unix, but it has been diverging from its ancestor so much that it no longer feels Unix-like in the least.
Some examples:
- no /dev (bye-bye Unix philosophy cornerstone "everything is a file");
- unusable "locate" that doesn't find all the stuff it should (because Apple wants you to use Spotlight, the command line is bad, you silly!);
- much of the userland isn't aware of the HFS+ filesystem extensions (have fun cp'ing files, discovering months later that - oops! - the stuff had a resource fork and is now unusable -- verrry dependable!);
- case insensitive filesystem by default, you could switch to case sensitive for compatibility with any other Unix in the universe (have fun reformatting and reinstalling) but - alas! - important application software won't support it (photoshop & others);
- no cron! If you want to get it to do things periodically, you either gotta write freaking XML for launchd, or run Vixie Cron in addition to launchd. No thanks!
If OSX is Unix, it's the worst Unix I've ever seen. No serious command line nerd could ever like it (OTOH, it's perfect for know-nothings who like to click on pretty pictures). Using it is a totally different (as in "worse") experience than using any BSD (or Linux!), so spare me the old "OSX is BSD" hearsay!
Re: (Score:2)
Correction to the above: it does have /dev, come to think of it, you just don't get to use it much, since you can't choose the mountpoint because mounting is automated!
Re: (Score:3)
It's not that. I've updated the db (and I let update it periodically, via launchd) but it still won't find everything (not even regular user-owned stuff).
Yeah, I had come across that one. Then again, you first have to know it exists. Apple won't warn you nor inform you. And when you investigate and find out, it's usually because the regular Unix tools have already wrought havoc.
Re: (Score:2)
OK, cp is fixed. From
man CpMac
As of Mac OS X 10.4, the cp command preserves metadata and resource forks of files on Extended HFS volumes, so it can be used /usr/bin/CpMac command will be deprecated in future versions of Mac OS X
in place of CpMac. The
Re: (Score:2)
Yeah, I had come across that one. Then again, you first have to know it exists. Apple won't warn you nor inform you. And when you investigate and find out, it's usually because the regular Unix tools have already wrought havoc.
All of the standard Unix tools for moving / copying files have supported resource forks for some time now. But it's really not a big deal because only Classic / Carbon MacOS apps make use of resource forks. Classic will not run on new hardware and Carbon was depreciated a while ago. If you are a Unix user, I can't imagine a situation where you would want a resource fork.
Whatever. Have fun developing on a case-insensitive file system and not noticing case mismatches that will suddenly stop the show when you run your stuff on a proper Unix.
You have it wrong. The file system is not really case-insensitive as per the traditional sense. If you have a file named "SomeFile.
Re: (Score:3)
> ls dir2
README
> mv dir1/readme dir2/
> ls dir2
readme
Bye-bye README! Because of this nonstandard behaviour, I once lost a bunch of files. Tha
Re: (Score:2)
In my example, both filenames are correct and exist. The point is that the lowercase filename will replace the uppercase filename.
Re: (Score:2)
Eating Horseburgers?
Re: (Score:2)
Case sensitivity is the one that hit me. My Lion install is case sensitive, and a lot of programs (don't have PS to try, but can vouch for Steam, Diablo 3 and Starcraft 2) simply don't install.
Re: (Score:2)
Even things like rsync supports them. OP is just whining.
Re: (Score:2)
Have you used AIX? Where changes made to /etc/* files get reverted because you didn't do it through smit?
Is AIX UNIX then?
What about ubuntu with all the changes they've made?
I've had no problems using Terminal.app and bash, and I grew up on Solaris/OpenBSD, so no idea why you have such a bug up your ass.
Re: (Score:3)
- no /dev (bye-bye Unix philosophy cornerstone "everything is a file");
- unusable "locate" that doesn't find all the stuff it should (because Apple wants you to use Spotlight, the command line is bad, you silly!);
- much of the userland isn't aware of the HFS+ filesystem extensions (have fun cp'ing files, discovering months later that - oops! - the stuff had a resource fork and is now unusable -- verrry dependable!);
- case insensitive filesystem by default, you could switch to case sensitive for compatibility with any other Unix in the universe (have fun reformatting and reinstalling) but - alas! - important application software won't support it (photoshop & others);
- no cron! If you want to get it to do things periodically, you either gotta write freaking XML for launchd, or run Vixie Cron in addition to launchd. No thanks!
If OSX is Unix, it's the worst Unix I've ever seen. No serious command line nerd could ever like it (OTOH, it's perfect for know-nothings who like to click on pretty pictures). Using it is a totally different (as in "worse") experience than using any BSD (or Linux!), so spare me the old "OSX is BSD" hearsay!
So you noticed that /dev/ still exists. Well done. Although mounting is automatic (which I hardly see as being a bad feature and something unique to Mac OS X) there's no reason why you can't manually mount stuff as you wish. man mount.
On locate, log a bug if it's not working as intended. This is what techie people do. I'd opt for mdfind unless I have a script that *absolutely must* use locate. mdfind is fast and isn't reliant upon having an up-to-date locate database.
cp by default preserves resource forks.
Re: (Score:1)
There is a difference between sharing kernel ancestry, and actually being a BSD.
Re: (Score:2)
Re: (Score:2)
Stunningly stupid, oxymoronic comment.
Because over a decade ago a kernel was based on a decades-old "drop-in replacement" that's specifically NOT BSD, OS X is BSD.
Re: (Score:2)
Today's FreeBSD kernel is not the same as it was before Mach came along
Does this mean that FBSD based on the Mach 3 kernel? That is news to me
Re:OSX is doing great (Score:5, Informative)
iOS is doing even better.
There seem to be some uninformed posters here, so here is the OS X relationship to BSD:
The OS X/iOS kernel is based on Mach, which is a microkernel mashed together with a BSD kernel. It has a lot of BSD code in it and continues to share code with the other BSDs. It has features borrowed from BSD such as DTrace, PF firewall, file system support (including ZFS before it was removed), the networking subsystem, kqueue, jails, and others. While Mach is fundamentally different in some ways, to a POSIX binary it looks and feels just like any other BSD system.
The OS X userland is also based on BSD and was originally derived from FreeBSD. It uses the BSD libc and many of the command line tools are from the BSD world (from grep to ssh). It also includes some GNU tools, such as bash. Apple is actively working on replacing many of these, and they recently dropped GCC and GDB and replaced them with Clang and LLDB.
Re: (Score:2)
I believe dtrace was inplemented independently from Solaris by Apple. I know ZFS was.
Re: (Score:2)
It has a lot of BSD code in it and continues to share code with the other BSDs.
Really? I was under the impression that Apple do not distribute any source code for Darwin on ARM. Please show me where I can obtain the XNU ARM kernel source that is used in iOS.
Why would you need that? The platform-specific part of the kernel is a fairly minor part of the overall code. There's a lot more code investment in the VM, the FS, the network stack, and other major kernel subsystems, which are all generic code and distributed to the public, than the specific implementations of low level locks, interrupts, and page table map managers. The fact that we can't build and run XNU on ARM doesn't mean that we can't share code with it.