Slashdot Mirror
Hacking Mac OS X
Bill Hamm writes "DB is carrying a deep interview with Jonathan Rentzsch, who created an open source technology to allow other developers to inject their code into any running process to alter its functions and written papers for IBM to program the PowerPC correctly. The interview is huge and technical, and all over the place in terms of content. Some of the things discussed are the reasons for corporate America's resistance to buying from Apple, software optimization, the importance and history of 10.4's Core Data, why WebObjects is no longer relevant, the status of PowerPC compilers, and why Mac OS X's Finder should be killed off."
...that the "hacking" in "Hacking Mac OS X" is referring to "hacking" in the traditional sense, not "cracking".
And for more on mach_inject, referred to in the summary, see Jonathan Rentzsch's website...and an interesting list of mach_inject and mach_override users.
As for the Finder, it may be true it was a "compromise" of sorts between the NeXT world and the Mac OS world. But it wasn't necessarily the social compromise between "personalities" within Apple it's pained to be; it was likely more of a technical one. It's not perfect, and it's woefully inadequate for some tasks that involve managing thousands (or hundreds of thousands) of files. But it's still more than sufficient, and there's no reason to completely junk it: it can continue to evolve and be improved upon.
The interviewee argues that WebObjects is still relevant, and the fastest way of coding Web Applications, but is in danger of becoming irrevelevant if Apple do not update it soon!
Get a free iPod Nano 4GB!
To understand the basic complaint about the OS X Finder look at this ArsTechnica article.
Get a free iPod Nano 4GB!
Those compaints are from before 10.3 came out, which is when the OS X Finder took several leaps forward.
Also, most of the article seems to be about pimping an alternative design ideas (mainly credited to Tog) which don't sound better than the current design in any way whatsoever (IMHO, YMMV, uh... IANAL.)
Information wants to be anthropomorphized.
John Siracusa of Ars Technica has written up a very fine article about the problems with the OS X finder. I'd give my opinions on the matter, but I have to get back to work.
No it didn't.
What is amazing me most is the fact the someone has moded this up
People this is a trol and a very old one that has been posted a great deal.
from wikipedia http://en.wikipedia.org/wiki/Slashdot_troll
The only things certain in war are Propaganda and Death. You can never be sure which is which though
If you want to add it, there's a "Path" button that can be applied to the Finder toolbar. Use the "Customize Toolbar..." menu item and drag the "Path" button to the Finder toolbar.
A better choice in my opinion, though, is to command-click on the window title. That's been a feature of the Mac Finder since System 7.
That's not what Automator does. It's understandable why you'd get this wrong, but please check out "Working with Automator."
Short version: Automator lets you chain together very small bits of code called Actions to create Workflows.
Think of Actions as being like UNIX tools, and Workflows as being like command pipelines, and you'll have the idea.
Automator is not a general-purpose AppleScript tool. You can write Actions in AppleScript if you want -- though Objective-C is better, in my opinion -- but you can't use Automator to just talk to any application with an AppleScript dictionary. That's not its job.
XLC only writes code that's compatible with the G4+ processors, Apple can't use it as long as they need to support G3's too. There are also issues with the fact that it doesn't behave exactly like GCC, so Apple would have to deal with this when building apps that are based on OSS software(i.e. most of the BSDness of the OS), and they'd need to pay to include a copy with every copy of OS X or be stuck in an odd situation of users using GCC while Apple uses XLC.
You can make it stop the nagging if you turn the date to some amount of years in the future (say, 2030), open quicktime and say "ask me later", then quit quicktime & turn the date back to normal. It'll ask you again in 2030. I'm not saying that it's not annoying, but thankfully there's an easy way to stop it.
For years Mac's windowing/subwindowing functions required multiple open windows on a screen to explore subdirectories.
... um ... WRONG.
This has been untrue since System 5, circa 1989. Certainly pre Windows 3.0.
Mac designers were so proud of multitasking that windows didn't maximize automatically -- hardly making efficient use of screen real-estate.
This is a bizarre remark... drug induced?
1) Macs had overlapping Windows before they had threading.
2) The first multi-tasking implementation (beyond desk accessories) involved multiple virtual screens (no overlapping applications).
Many applications remember the state you set them in when you last used them and reinstate it when launched. Some don't. The same applies in Windows, with the exception that (a) it's easy to force maximization if you know a bit, and (b) Windows maximizes windows to fill the screen whereas the Mac maximizes windows to show as much as possible, but no more than required. I don't see how the latter is a less efficient use of screen real estate than filling the screen with a largely empty window.
So
Mac never attempted to price their machines competitively for corporate America
I assume by "Mac" the writer means "Apple". In fact, Apple has offered many price-competitive computers, e.g. the Classic, the SE, the IIcx, the IIsi (the Mac mini being the most extreme example). It's not like the IBM XT was priced under the Apple II.
In any study of TCO I've read (e.g. from Gartner) you'll see Macs have a lower TCO than Wintel boxes. I would assume TCO matters to corporate America -- but only when comparing non-Apple options.
Going into terminal and killing the Finder would not help it recover from a fucked up network volume anyway. What's going on is that the Finder is halted and waiting for a response from the network file system driver in the kernel, and *that* is halted waiting for a response from a remote server that is probably never going to arrive. In order to keep everything in synch (I assume it's trying to avoid the driver returning data to internal process accounting structures that no longer exist, or trying to kill the driver within the kernel itself), NOTHING can kill the frozen Finder, up to and including kill -9.
>I would like to know more about it.
www.python.org
>What is it good for?
It's good for general-purpose programming, particularly if you need the end result to be cross-platform.
It's extensible with all kinds of 3rd party libraries available. It's a much better fit for many types of work than is Perl, and arguments have been made that it is more efficient and easier to learn than Java.
>Any drawbacks?
Like Java, it's a bytecode-interpreted language, so to-the-metal programming isn't really possible.
>How to learn it?
It's quite easy to learn, even as a first programming language. It's extremely easy to do certain kinds of complex things (you name it) because there are so many modules available. This is something that Python shares with Perl and Java, of course, but python programmers argue that it's altogether easier to work with.
I was on the fence, until some production code rolled in my company that was written in Python. It's a success story for the folks involved, and the quality of their work and the speed at which it was completed, really speaks for itself.
-fb Everything not expressly forbidden is now mandatory.
They don't, for the most part, stock replacement parts. They don't do anything but the most basic repairs.
I have to chime in here. I have a refurbished dual G5 in which one of the processors stopped showing up. The guy at the Genius bar told me it could be anything from an improperly seated processor to a bad CPU or logic board -- both of which were parts that they had in stock and could fix within a day or two. Luckily, it the processor wasn't firmly "in place" and it just took a bit of reassembly.
They had it diagnosed and back to me in less than 24 hours, no charge. And I don't have Applecare on the machine. My opinion is that Apple hardware is great, but regardless, I've had few occasions to have to get repairs over the years. And when I have, it's been a relatively painless experience. I never had to ship anything in or wait for some obscure supply-chain hopscotch to get a part.
A number of other comments in this post give me pause, but I'm not qualified to respond so I'll just say "hmmm...OK, whatever" to the rest, and admit people's experiences vary.
For their business machines, i.e. the G5 XServes, this isn't a problem at all. I bought 16, and the 3yr extended warranty, and with the machines came two extra packages. One had extra HD modules for the main server, and the other the entire guts of an XServe G5. If I have one drop out, my downtime is how long it takes to open a box and swap the guts. If you're buying consumer hardware, they do tend to the control-freakish, but most of the internals are commodity, so easy to replace yourself, and probably cheaper than shipping it. With the others, you can get parts, but quite frequently, you can't really afford them.
My account rep has been helpful and responsive, including ordering custom parts for my cluster set up. Maybe they're hungrier in upstate NY, but I don't find them any different to deal with than HP or IBM. (though I've never been asked about my AIX needs by the Apple rep)
As for the facilities to back up 60GB, a couple of 80GB USB/Firewire external HD's are ~ $100 each, and you can install them to make them bootable as well. A stray Linux/BSD server running Software RAID with a terabyte shouldn't set you back much over 2K, depending on what you build it out of, or you could buy the 80GB MacMini for $600, and partition the disk into a 20GB OS and 60GB backup partition.
They aren't perfect, and they do tend to the secretive, but in my experience they're pretty much the same as any other major vendor to deal with.
the more accurate the calculations became, the more the concepts tended to vanish into thin air. R. S. Mulliken
If you've not used a declarative language, try playing around with Prolog. It's not always fast, but sometimes you can do things in two or three lines of Prolog code that would take tens or hundreds of lines of imperative code.
I am TheRaven on Soylent News
The Mac OS Finder has an internal database which stores meta information on files. It mostly handles what creator types and file types map to certain applications, but it performs other duties as well. The idea is that each file has a 4 byte creator type which says what application created it and a 4 byte file type which classifies what type of data is contained within the file. When you open a file the Finder does a lookup to find out how the file should be treated and what application should be notified of the action.
Occasionally this database would get out of date, would require compacting, or would be come corrupted. To rebuild it all you needed to do was to get the Finder to restart and then hold down the option and command keys. The Finder would then take a few seconds to recreate the database and clear up any issues.
Rebuilding the desktop fixed most of the problems that Mac OS was prone to. The rest of the problems were either bad preferences, a bad system extension, or bad hardware. Typically the first step in diagnosing a Mac OS problem was to first rebuild the desktop database, then reset the PRAM (a set of preferences retained between reboots), then test to see if there was corrupt preferences, then system extensions, then hardware. Overall you usually caught problems quickly and they were easy to correct.
You can read a bit more about rebuilding the desktop here
Currently under Mac OS X the desktop database is much more advanced. It uses different methods to keep track of files and auto-corrects problems that used to hang up the Finder. Thus you do not have to worry about rebuilding the desktop database under Mac OS X. In fact the entire Mac OS X operating system is much more stable than the pre-Mac OS X systems.
Sapere aude!