BitRot on Mac OS XThis page was just pointed out to me by Matt on macosx-talk. In theory, it discusses Mac OS X from the perspective of a Linux user. It may be well-intentioned, but there some major gaps and errors in the explanations.
When switching operating systems, there is a strong tendency to whine about all the things missing in the new OS, or that are done differently and require a change of habits. The advantages become obvious only after some time. I'll do my best to take that into account and present a balanced review.
Keep this in mind as you read the following. It's a noble goal that I think wasn't followed through on.
MacOS demands that you click a window to work with it. [...] I can offer no suggestion when a click on a button in an unselected window will work, and when it will be ignored.
You can interact with background window by holding down command. As far as buttons activating in the background, it is a bit unpredictable. I think the original idea was to only allow buttons linked to non-destructive actions to activate without focus, but I'm not sure how well this principal has held up. In any case, I think you can force background activation in many cases by holding down the Command key.
From the right side of the Finder to another Finder on the same disk: move. On a different disk: copy.
This is and always has been by design. It's the least destructive default behavior. You can override it with the option key.
From the right side of a Finder on the system disk to the desktop, or vice versa: move. Otherwise, copy. [...] Vice versa: destroy the icon. From the title bar of a Finder: copy. I could go on. Are you confused? No wonder, this is a total mess.
Moving a window can be done only from the title bar. A window can be moved partially off-screen to the left, right, or bottom, but not the top; it sticks to the desktop title bar. Modern amenities like edge snapping are missing.
Windows which have the metal look can be moved via any open space, not just the title bar. There is a bit of debate about the inconsistency of this, though I think it's moving closer to the metal behavior.
Keeping windows below the menu bar is certainly the correct behavior. I suppose edge snapping would be nice for every window, but I'm not sure I see the immediate value unless you have a palette of some sort.
The Mac trusts the filename extension instead. If your JPEG file is named "file.png", you cannot double-click it, the preview app will refuse to load it or crash.
This makes no sense at all. Preview opens jpeg files just fine, regardless of the extension. In addition, file extensions are not the only factor. Both file extensions and the creator code are taken into consideration, providing for better-than-Window functionality while still being compatible with the real world.
You cannot edit a file named "account statements" because there is no extension so MacOS is helpless. f your movie file is named file.mpeg instead of file.mpg, you cannot view it.
Completely false in every respect.
Basically, you have multiple virtual desktops, perhaps one for browsing, another for mail, another for editing; all filled with windows, and you can switch between them at the touch of a button. MacOS lacks this.
I'd like to see this as well.
The Quicktime player ships as a giant billboard full of features that are disabled until you pay another 30 Euros for the Pro update.
iMovie is probably more capable in most respects, and is included.
KDE is not as pretty, not as consistent, probably not designed by HI professionals, but it is a lot more modern than the Mac GUI
No discussion about the Mac GUI can avoid the isue of the Mac mouse. It looks cool, but it had only has a single button
With my Mac, I learned about shareware. That's software designed to work poorly or not at all, or just for a short time, until you pay money. No thanks, especially since most of the stuff ought to have been part of the system in the first place.
This is balanced? Perhaps there's a bit of a cultural divide here. My experience is that the Linux community would rather have something slightly broken and free. For the most part, Mac users will pay for something if it works correctly. This is why they use a Mac in the first place.
In particular, they tore out some of the lower layers and replaced them with a Mach-like microkernel. Microkernels were all the rage fifteen years ago, but the idea totally crashed and burned because performance and resource usage was pitiful.
These are just buzzwords. I really don't think he understands kernel environment at all.
And that's not the only error they repeated: much of the MacOS APIs are in a language called Objective C, a forerunner of C++. In many ways it's cleaner than C++, even though it's just some object-oriented features grafted on C with very peculiar syntax, but it's now a failed language that nobody uses. [...]The upshot is that Apple is now stuck with a defacto proprietary language, [...]The fact that Objective C is GPLed and there are alternate C++ bindings don't change the fact that Apple is making it as difficult as possible to write MacOS software.
A horribly distorted characterization. To see how effective Objective-C is at rapid development, just look at the rate at which Apple churns out top-quality software. They were initially concerned about how well the language would be received, which why Cocoa was offered via Java as well. It turns out Objective-C became wildly popular in the Mac community, to the point that Apple is no longer going to maintain Java support for Cocoa.
If Objective-C truly made it difficult to write Mac OS X software, we'd see a landscape where it takes more Mac developers per-project to achieve equal quality to Windows and Linux apps. Instead, it's quite normal to see 1-3 person teams of Cocoa programmers put out software that blows away products written by 12-20 person teams on Windows or Linux.
Speaking of wedging the Finder: the worst thing you can do to it is accessing a network (NFS) server that doesn't respond. The Finder will freeze for very long periods of time. [...] Version 10.4.2 is no less broken than any previous 10.4, it seems they are incapable of fixing this.
This is a long-standing an well-documented problem -- perhaps one of the few true major issues with Mac OS X. Apple is completely capable of fixing this, it's just that it requires a more serious look at the architectural issues of the Carbon-based Finder. I'm completely with him on this one.
And it doesn't stop there. FreeBSD comes with a perfectly functional set of configuration files in /etc that anyone who knows Unix or Linux is instantly familiar with. They all exist on MacOS X too. And they are all ignored![...]a weird and proprietary configuration system called Netinfo[...]It's less powerful than the system it replaces because everything got forced into a key=value system.
Not all of these files are ignored, but a very small minority of the world's computer users understand or want to deal with unix/linux at this level. In any case, the storage format is somewhat irrelevant. All that really matters is how you configure things.
Apparently Apple saw Microsoft's idiotic Registry blunder and felt that they must make a similar and equivalent idiotic blunder. You guessed it, Netinfo originated at NeXT[...]Completely undocumented of course, the simplest jobs take forever to figure out.
Oh, the irony. NetInfo, of course, predates Windows 95. It's not used in nearly the same capacity as the Windows registry, though. It would be really helpful to know what he was trying to use NetInfo for. I think I've had to dig into it maybe twice in four years.
Linux is open in all directions, everything is possible, you'll find recipes for just about anything on the web, including some to shoot yourself in the foot. MacOS X, on the other hand, has all the maintenance access panels nailed shut. If Apple made a mistake or doesn't feel like letting you look under the hood, tough luck.
This seems like hyperbole to me. There's no question Mac OS X is a commercial, store-bought product which is not completely open source. In Mac culture, the idea is that the software should basically work intuitively and take care of itself. In the Linux world, you get the software free so the business model is based on post-purchase support contracts and hiring experts to run the thing.
Given the Mac model, you can't just blindly give away the product. There would be no money to invest in development and we wouldn't have a Mac OS X.
I also have serious problems with Apple's proprietary graphics engine. They should have used X11. [...]I am talking about interoperability on a network, based on open standards. The system should not care on which computer a program runs and on which display the windows show
Apple Remote Desktop? To throw away all of Quartz just for this seems crazy to me.
They think that each workstation is an island, connected by tenuous bridges intended for the sole purpose of pushing data around. You are supposed to start all your programs on the workstation in front of you.
This is just the X11 model, and there's more than one that works. I'd be interested in seeing the practical problems that he's trying to solve, rather than trying to wedge everything into an X11 mindset.
While there are some legitimate issues raised here in terms of consistency, the author made some egregious technical errors in a number of different places. There are also some opinions which I find incredibly misleading, particularly in terms of the kernel and core API. These would have benefited from real, hand-on research instead of first impressions.
Finally, there's an issue of culture. The Linux community prizes the ideal of free and open above all else -- even if the end product itself isn't very good. The idea is that any usability or functionality issues can eventually be fixed. This may be true, but Mac users would rather pay for something that works today.
The Mac community doesn't get militant over for-pay software because there's an understanding that even developers have to eat. More importantly, there's an expectation that you pay for the software itself and it should work as advertised without having to bring in costly consultants or spend hours searching the web for solutions. I think this is where the industry as a whole is ultimately heading.
BitRot on Mac OS X
Posted Nov 28, 2005 — 17 comments below
Posted Nov 28, 2005 — 17 comments below