How Mac OS X, 10 Today, Changed Apple's World
CWmike writes "Ten years ago today, Apple's first full public version of Mac OS X went on sale worldwide to a gleeful reception as thousands of Mac users attended special events at their local computer shops all across the planet. What we didn't know then was that Apple was preparing to open up its own chain of retail outlets, nor had we heard Steve Jobs use the phrase, 'iPod.' Windows was still a competitor, and Google was still a search engine. These were halcyon days, when being a Mac user meant belonging to the second team, writes Jonny Evans. We're looking at the eighth significant OS X release in the next few months, Lion, which should offer some elements of unification between the iOS and OS X. There's still some bugs to iron out though, particularly the problem with ACL's (Access Control Lists) inside the Finder. Hopefully departing ex-NeXT Mac OS chief, Bertrand Serlet, will be able to fix this before he leaves."
Interesting use of the past tense there, considering Windows usage still dwarfs Mac OS usage.
"16MB (fuck off, MiB fascists)" - The Mighty Buzzard
Windows was still a competitor, and Google was still a search engine. These were halcyon days, when being a Mac user meant belonging to the second team
So mac users fancy themselves as belonging to the winning team now? And how exactly were the days when Microsoft propped up Apple to prevent Microsoft from becoming a noticeable monopoly halcyon? Apple's fire almost died, and they had to make heavy use of BSD licensed (free, wee!) software to rekindle the embers.
Nothing is perfect, but moving to OS X from the previous MacOS/System versions was a smart move for Apple, and was one of the reasons Apple is still around today.
Before OS X, if a program did not hand control back go the OS via WaitNextEvent(), the Mac essentially need to be restarted. In fact, Macs became so unstable, people ended up just rebooting them every two hours just to be safe.
It is an ironic contrast to these days where the only time Macs go down is a reboot to install a security patch, or a Safari update (why Safari patches require a reboot is beyond me, but that is Apple for you.)
Apple did the right thing. People yelled at Apple to get an OS that did actual, preemptive multitasking for years. Multiuser security? You had to use a utility that would do tricks to create the illusion of multiple users, such as Kent Marsh's FileGuard, Empower, Casady & Greene's [1] AME, or another utility.
Of course, there was the virus issue. OS 9 and previous did have a good number of viruses on the platform. OS X has not had a single one in the wild.
All and all, OS X has withstood this decade quite well. No major breaches in the wild (except for Trojans like the one bundled with a pirated version of iWork '09). No OS is completely secure (and it often was the first to fall in hacking contests), but it has proven to have a well deserved security reputation in the real world.
Is there room for improvement? Yes. OS X needs a modern filesystem to compete with ZFS, btrfs, and possible changed to NTFS. OS X also needs full disk encryption and not just FileVault. Hopefully Apple will address these, preferably before they run out of big cat names for OS versions.
[1]: Yep, the same Casady & Greene who made the software that was renamed into iTunes.
But a lot of Mac's growth has been due to Windows running on it. We see that on campus all the time. People want a Mac for whatever reason. However they need software that is Windows only (this is particularly common in Engineering, where I work) or they are a gamer and want to play games that aren't on the Mac (see that with students a lot). Previously that might have turned them off from a Mac. However now they get one and then get Windows for it and maybe Fusion or Parallels. Our bookstore does a ton of business in Windows licenses and VMs.
So sure, more people are using Macs and OS-X but often it is in addition to, not at the expense of, Windows. Fine for Apple, they make money on hardware, but also fine for MS, they make money on software. MS doesn't care what you run Windows on, just that you run Windows.
Most my computers are Linux machines, including my desktop.
My laptop is a Macbook Pro. Before that it was a Macbook, and before that it was a Powerbook.
I would not have TOUCHED a Mac if not for OS X, which is, essentially, UNIX.
I'm typing thins on my laptop right now. I currently have Firefox open, and an IM program, a VNC, and several terminals. One terminal is running Alpine on my desktop, one is doing an apt-get dist-upgrade on my media center, and one is setting up the new kernel/boot parameters for the network boot on my media server.
So, yes, people DO use the CLI in OS X, I'd say ESPECIALLY people who live in UNIX-land, but do also occasionally need to edit some video or process some photographs or record some audio.
In the land of the blind, the one-eyed man is kinky.
The relevant visible parts of MacOS are pretty anti-unix actually.
Erm, no, Mac OS X is quite definitely 100% certified Unix. This has nothing to do with the "visible parts" (you mean the GUI I assume), this is all about the underlying kernel and other subsystems of the OS, as well as some of the userland tools.
Sapere aude!
Well, maybe he's an engineer. Comparing the 55 exploits in the list you linked to--which go back SEVEN YEARS (last entry: June 2010)--to the nearly uncountable number of exploits against Windows is effectively "nonexistent." (Note: Vista and 7 have been doing very well. But DAMN that was a long, painful stretch we had to endure under XP.)
Is Mac OS X perfect? No. BUT: Has there ever been a widespread virus for it? No. Has there ever been a self-replicating, self-spreading virus in the wild for it? No. Have drive-by downloads ever been a problem? No.
A few years ago, my teenaged son turned a Windows box from a smoothly-running specimen into an unbootable heap of molten slag (note: exaggerating, but not by much) in a single afternoon of unsupervised web surfing. I switched my wife (it was her computer) and, eventually, him, to a Mac mini, and have not had a problem since.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
I don't know whether to laugh or cry... I used to maintain the ACL code in the Mac OS X kernel. This is a user-space bug in the DesktopServices framework.
Although this is not usually a problem, since only foolish/untrained administrators use Finder copies on systems being used as servers, I tried several times to get the Desktop Services folks to fix this. Mac OS X has multiple "copy engines", and the one in libc gets this right, while the one in the DesktopServices framework gets this wrong.
The problem is that the finder "copy engine" code sets an ACL in the openx_np() system call, rather than using the chmodx_np() system call after the fact to set an explicit ACL. The ACL it passes to openx_np() is obtained from the source file system object via getattrlist() (but could as easily have come from statx_np()). So the ACL being set is the combination of the ACL set explicitly by the openx_np(), and the ACL being set as a result of the inheritance bit on the container directory in which the new file or directory is being created.
This is in fact necessary, since the only way to make image backups of a subtree such that the copied subtree has exactly the same permissions in the target subtree as it had in the source subtree is to set *all* of the ACLs that were on the source object onto the target. Anything else loses permissions grants or denials on the copy of the object which were present on the original. This is either inconvenient, in the case of grants, or a critical security bug, in the case of denials.
You can also see where this would be a necessary step for a backup/restore operation, where the date is serialized into an archive format on the backup, and deserialized back into the file system on a restore, which could be a partial archive restore.
Things can get even more complicated when Time Machine and Spotlight are thrown into the mix, since Spotlight adds inherited ACEs to permit it to index directory contents that would otherwise be denied it by ACL, as does Time Machine (for some reason, they do not share a common group ID and utilize a single shared system functionality ACE, but I digress...). Likewise Time Machine sets an inherited ACE on its backup volume, for similar reasons.
The correct fix is to do ACE deduplication in the case that the target directory container has inherited ACE entries which match the ACE entries on the source object, and remove duplicates from those explicitly listed in the openx_np() call. The alternative approach is to explicitly set exactly the desired ACL on the target after the target is created -- this has the drawback that you would need to explicitly know the container ACLs inherited ACE list in order to aggregate it yourself, but has the advantage that you won't be denied access to the object during creation if your openx_np() ACL contains explicit rights grants for the group or user that the creating entity runs under (this should be coupled with a subsequent "deny everyone" ACE to avoid a security race, which makes this the less desirable workable solution).
Note that the above should make it obvious why a depth-first post-application of ACLs on copied objects wouldn't work; apart from the security problems in the order of operation window, network protocols such as AFP and NFSv$ and SMB all use connection credentials rather than request credentials (NFSv3 uses request credentials), and even privileged users do not have access to other users keychains or session passwords in effect for a given copy operation.
-- Terry