This is a popular saying, but in my experience (and I've built many successful tech teams) you're better off hiring generalists than specialists. Certainly you want to cover your required skillsets somewhere in the team, but in the long run you're better off with people with broad experience who like learning new things.
I've been astoundingly lucky with my latest team -- I have people who are fantastic at each of the specific areas that we need to cover, and they're all interested in pretty much everything. This means that if the "specialist" is unavailable, I have plenty of other sharp people who can dive in and do a good job. And aside from that, it means that everybody has other people to bounce ideas off of that understand the whole system. This is way more fun (and produces a much better overall system) that if I defined the architecture and everyone coded their layers and ignored everything else. And because anyone can challenge any aspect of the system, while there's a little stress, the end result is that (1) everyone respects everyone else's work because they understand it, and (2) the system as a whole is much better because it's the product of more people's contributions.
So after watching disasters repeatedly take place because the people at each layer didn't understand the whole system, you bet I'd rather have generalists running my UNIX clusters. Here's an example: would you rather have a cluster running a database managed by a great sysadmin who understood the OS level but not hardware, a networking guy who didn't understand the applications, and a DBA who didn't understand the OS? Or would you rather have it run by people who understand running clustered hardware and OS, database and application? Sure, those people are much harder to find (which is why big companies hire specialized drones) but smart decisions are valuable, and people can make better informed decisions because they have a broader perspective are worth more than they cost.
While it's certainly true that HR people only know keywords and not substance, there's a good reason to hire people with cross-platform experience -- it's much better for the company.
First, it gives the company more flexibility. If you need more NT or UNIX work done right now, you can shift people fluidly rather than having one team idle while the other is idle.
Second, it leads to more mature and coherent decision making. If you have separate UNIX and NT teams, they'll each come up with a completely different set of answers for everything (and usually compete, which is crazy for morale), so you'll end up running two separate environments, and thus two of everything, so IIS and Apache, Active Directory and LDAP, etc., with little to no integration. But if you hire people who understand both platforms, you can come up with a a unified strategy for the entire company, and make decisions based on technical issues rather than religion.
"Apple puts a lot more engineering into their boxes than the typical PC vendor does// I have no idea what you're talking about here. Are you saying nVidia doesn't put a lot of engineering into their latest 7800 GTX cards or their more mainstream 6600 GT cards?"
By PC vendor, I think that the original poster was referring to companies like Dell, HP, Sony, IBM, Gateway, etc., that make the complete systems. Like Apple, they all use video chipsets from nVidia, etc., but that's not the PC vendor's R&D, that's nVidia's R&D. An open secret in the PC industry is the fact that none of the WinTel PC vendors do any real R&D -- Intel and MS do all of the R&D, and everyone else just does packaging, marketing, fulfillment, customer support, etc. I don't mean to downplay the importance of those services, but they're not R&D.
Apple does less R&D then they used to, but far more than any PC manufacturer. (Exception: there are large companies, like IBM and Sony, that make PC's and also do R&D, but that R&D isn't in the PC division, so IMO it doesn't count). The most obvious R&D investment is that Apple writes its own OS, which no WinTel vendor does. And, of course, Apple invests far more in industrial design than any PC vendor, which is why their machines are the highest rated in terms of reliability, support, etc., as well as the more obvious design appeal and ease of use. And Apple invests heavily in creating new technologies and standards (e.g. ZeroConf, FireWire, MPEG4) that advance the state of the art, and of course they also push adoptions of new technology into the marketplace (e.g. CD-ROM, DVD-R, USB, FireWire, WiFi) far more effectively than any other computer manufacturer. So while Apple didn't invent WiFi, they certainly did the hard work of packaging it and making it work reliably for mainstream users well before, the WinTel market -- Dell, etc., all waited passively until MS and Intel got WiFi somewhat working, then shipped it, which meant that Apple's customers not only got it a year earlier (as a mainstream technology) but it worked better. There are dozens of such examples.
You could argue that MS and Intel spend more on R&D than Apple. But now that Apple is shipping Intel, they benefit from Intel's R&D, which is smart. And Apple has demonstrated time and again that they're far more focused and effective in their R&D efforts. So while MS is pushing ahead on hundreds of fronts, Apple creates a small number of best-of-breed applications (best OS, best music, best DVD creation, etc.).
"I was with you until "Since MacOS X runs on SPARC". NeXTSTEP and OPENSTEP ran on SPARC, but no version of Mac OS X ever has."
OK, I shortened a longer and more complex discussion. Most of the parts of MacOS X run on SPARC. NeXTSTEP and OPENSTEP ran on SPARC, as does WebObjects. Most people don't realize it, but WebObjects includes the Cocoa runtime, which means that Mac Cocoa app's can run on SPARC (over the Cocoa runtime) though Apple doesn't allow developers to license the Cocoa runtime for that purpose. And of course both Mach and BSD run on SPARC, and there are mentions of SPARC in Darwin (for example, http://www.opensource.apple.com/darwinsource/10.3. 7/gas-495.8/include/mach/sparc/). Finally, I've also been told by several Apple engineers over the years that Apple maintains NeXTSTEP's portability across more than PPC and x86, specifically mentioning SPARC. So given all of that, it's highly likely that that Apple could easily ship MacOS X for SPARC if they wanted to, but I can't prove it.:-)
I'd still love to see MacOS X Server ship on the high-end SPARC's. Not that there's anything wrong with Solaris 10, of course, but it'd be great for Apple and for its customers for Apple to prove the point that the OS matters more than the CPU, and that they have the best, most portable OS.
OK, I have no idea how well MacOS X would run on an 8-core SPARC with 4x "hyperthreading" to have a virtual 32 processors. But it'd be a blast to try.
"the poster I was responding to was talking about building a single source file (the one just modified, usually) and linking it. "make -j" doesn't do anything useful if there aren't multiple source files out of date."
You're right, of course. In theory you could parallelize the compilation process, but that would be very hard to do since any piece of code could be dependent on any other (at least until you parse it enough to understand what it does). At least, with multiple files, the makefile makes the dependencies explicit.
Personally, I'd rather see Apple retain a mix of CPU's in the marketplace, and just make sure that developers keep shipping "universal binaries". That gives both Apple and its customers the most flexibility. Want the cheapest possible consumer machine? Use an embedded PPC. Want the fastest server? Use an 8-way UltraSPARC. Want to run on a cheap PC? Run Intel. It's a winning strategy because it defines the applications and the OS as the important thing, and the CPU has just a part to be swapped in based on target requirements.
And if Apple _really_ wants to confuse people, they could (finally) release the Cocoa runtime for NT. Most people don't realize it, but Web Objects (which ships for PPC, NT and SPARC) contains the Cocoa runtime, so it could (if Apple allowed it to be licensed) to run Cocoa app's everywhere. Wouldn't that be fun! Write a Cocoa app, and ship for every OS. Who needs Win32!:-)
Perhaps I'm biased (I used to work at Thinking Machines) but pany more problems are parallel than you'd think at first, if you have a sufficiently fine-grained parallelism.
"even a compiler can benefit from multiple threads, though current compilers don't do it"
Beyond that, any time that you're rendering graphics, or sorting data, or in fact using any large volume of data, or doing more than one thing at a time, multiple processors could help. This is why most graphics cards are highly parallel, and why all high-end databases run well on many processors. Heck, even booting a computer benefits from parallel execution. Of course, it may be hard work expressing the dependencies between processes properly (e.g. parallel makes can break makefiles that have implicit dependencies in instruction order that work serially, but which break when parallelized), but if the problem is worth thinking harder about, it can probably be parallelized.
"when the work done by each thread is examined, it is performing serial tasks; e.g. it is internally single-threaded, so we haven't *really* got away from the single-threaded paradym."
That's true, but it doesn't matter. The point isn't whether programmers write multi-threaded code, but whether software runs faster.
Keep in mind that Sun's market is servers, where you have big expensive boxes processing hundreds or thousands of transactions a second. Each transaction can (and usually is) written as serial code, because that's easier to write and debug. However, it doesn't matter that each transaction is single-threaded, because there are many different transactions, and becauase the web servers, application servers, and databases _do_ understand threading. So if a CPU can handle 32 different transactions at once, and your OS/web server/app server can distribute and manage those threads properly, your server performance is just as good as if you had one processor running 32x as fast. Of course, you can't make a CPU 32x as fast (ask Cray), so this is a very clever way to make computers faster.
Of course, if you're running desktop applications it's a whole different ball of wax, because users aren't doing hundreds or thousands of different things at once -- they're probably doing 1-2 things at a time. So if you're playing a game and that game is single-threaded, then 31 of those virtual CPU's will go naerly unused. But Sun doesn't sell desktop computers.
Hmm. Since MacOS X runs on SPARC (OK, it used to until recently, and we can assume that Apple has probably kept at it), I wonder if Apple would be interested in selling Xserves running on these nifty new SPARC's -- they're probly better CPU's for servers than Intel, and would make the point that the OS is more important than the CPU.
Not to say that your Mac didn't somehow crash and corrupt the OS, but I've done pretty much the same thing that you did several times recently (I just set up a testing lab full of Mac Mini's) and none of them had any trouble, I've never even heard of Terminal conflicting with anything, and there's only been one update released to Tiger (to update it to 10.4.1). So I have no idea what the actual problem is that you had...
"Mac OS X (by virtue of the fact that it's largely compiled with gcc) is quite easy to port"
This claim is just silly; anyone who's ported code between UNIX machines knows that simply being compiled with GCC doesn't give portability. MacOS X is extremely portable because it was originally written very carefully to be portable (NeXTSTEP ran on 680x0, x86, HP-PA/RISC, SPARC) and Apple has carefully maintained that portability.
That being said, I agree with your main point -- MacOS X is highly portable, and anything written using Cocoa or Carbon should be easily or trivially portable to any OS.
So one interesting side-effect of the x86 migration is that once app's are compiled with universal binaries, it's very easy for Apple to add additional CPU's and have everything just work. So Apple could use those amazing next-generation SPARC's on serves, x86 on high-end desktops, and PPC's in low-end machines, and everything would "just work".
"Apple has now just become another Microsoft by the looks of it."
Why do you say that? Apple's releasing a version of their OS that runs on Intel chips doesn't make them Microsoft any more than Microsoft's releasing a version of their OS that runs on PPC's.
"why cant they just run the normal Max OS X binaries on X86 if they're universal binaries like they speak of?"
Because they didn't ship "universal binaries" out to consumers. So while they were compiling and testing the OS and iLife app's on x86 as well as PPC, they only shipped the PPC binaries externally.
And, of course, because they've compiled the iLife applications for x86, and want to prove that MacOS X on x86 runs real native applications. It's hard to argue that video editing, music playback, and photo organizing aren't "real".:-)
"If your Mac Tiger app is 64 bits, you're screwed. Won't even run in the emulator."
Two points.
First, there aren't any Mac app's that I know of that _require_ 64-bit CPU's, because they won't run on G3's and G4's, which means most Mac's, all laptops, etc. So app's that take advantage of 64-bit instructions also have a 32-bit version of the code.
Second, while the Universal Binary Programming Guidelines do only talk about the IA-32 instruction set, but it clearly supports 64-bit data types, and MMX/SSE/SSE2/SSE3, and I'd be stunned if it weren't possible to run 64-bit code on 64-bit x86's. Admittedly the 64-bit picture on Intel is a bit more complicated than on PPC (since the various x86 chip companies had different 64-bit stragies), but Apple's got a year to work it out. And, for what it's worth, rumor has it that Apple got MacOS X to compile on the Alpha at one point, which should have cleared up the dependencies on 32-bit code.
Ah, it's nice to meet another former NeXT developer.
Say what you will about NeXT, but they created some fantastic software. I used to write on NeXTSTEP on x86, and deploy on HP/PA-RISC, x86 and 680x0's. It was amazingly painless.
Wouldn't it be nice if Apple let developers ship the Cocoa runtime? Then we could write app's once, and run them on as native binary app's on Win2K, MacOS X, Solaris, etc.
This wasn't the transition from 680x0 to PPC -- a/v people loved the PPC's. The reason that the transition from MacOS X to MacOS X was hard for a/v people that that under MacOS X an app could take over the machine, giving it complete control over everything, and allowing for very smooth performance (if you didn't want to do anything else at the same time). The early versions of MacOS X didn't have good a/v support (fine for consumers, not good enough for pro's), but the later versions of MacOS X turned this around.
Of course, in the a/v world, if a machine is working fine and getting your work done, you don't mess with it -- there's a lot of weird voodoo that affects you when you're doing realtime transitions between multiple video streams, and if it works you just keep your fingers crossed and work it. So there's no reason to upgrade a production MacOS 9 machine to MacOS X.
"I had to deal with a painful and extremely nasty transition, when Apple switched from the 680x0 to the PowerPC architecture"
It wasn't that bad. When the PPC first came out, In a fit of lunacy, I swapped a hard drive from a 68030 Mac to a PPC 601 PowerMac, and IT BOOTED AND RAN PERFECTLY. And all 680x0 app's worked fine; you only had to upgrade to get better performance. It was by a wide margin the smoothest platform migration I've ever seen or even heard of.
I may be biased -- I was a NeXTSTEP developer, and I got used to being able to build fat binaries that ran natively on all platforms, with zero effort.
All Apple has to do to make this migration painless for users is: - Make sure that the Rosetta emulator works well enough to run legacy app's. There are some significant limitations, but it should work on generic legacy applications. - Make it so trivial to build and ship "universal binaries" that everything runs on both PPC and x86 long before the machines are released, so everything just works. - Push to get the major software vendors (e.g. MS, Adobe) to commit early to the x86, to encourage other developers to ship universal binaries.
The part of this that still amazes me is that there's enough reason there make this migration. All I can think of is that Intel has much cooler secret stuff in their labs than IBM and Motorola did.
Really? The tiny, and completely unsupported wires broke that run between the board and the firewire jack. If I could find a jack that was physically identical, perhaps I could swap it in, but it looks pretty unique. Is there hope?
WebObjects is written in Cocoa, and includes the Cocoa runtime. So while WebObjects has lots more stuff in it in addition to that (including Java support), the fact that it runs on many OS's shows that the original NeXSTEP/OPENSTEP portability is not lost.
"One advantage Apple has this time: The open-source FreeBSD operating system, of which Mac OS X is a variant, already runs on x86 chips such as Intel's Pentium."
Actually, it's a lot easier than that for Apple -- MacOS X runs just fine on x86. For background, NeXTSTEP and Rhapsody (the pre-release name for MacOS X) ran just fine on x86, and word has it (I don't want to get anyone in trouble...) that Apple's made sure that MacOS X still runs on all of the CPU's that NeXTSTEP ran on -- x86, SPARC, PA-RISC, etc., in order to make sure that they keep their options open. to make it even more obvious, keep in mind that Web Objects is the _same_ as the Cocoa runtime, and it runs on all sorts of processors. The only reason that Mac developers can't ship applications that run natively across all major OS's and hardware platforms is that Apple won't license the Web Objects runtime for that purpose, because they'd rather control and sell the entire platform.
"developers will need to rewrite their programs to run on intel" (paraphrased) is just wrong. For Cocoa app's, all of the development tools support building "fat binaries" that can contain the executable versions for numerous processors. Back when I was a NeXT developer, I used to build app's that ran natively on 680x0, x86, SPARC and PA-RISC all the time. Admitedly Apple has hidden this capability, but it's obviously still an option for Apple to allow developers to build fat binaries again.
For non-Cocoa applications, it's theoretically possible to get developers to recompile their applications, if all of the frameworks, etc., are ported, but I wouldn't be surprised if, just like the PPC migration, the answer was to use emulation to run legacy code.
"every time Apple migrates they lose customers and developers" Actually, the PPC migration was good for Apple. Without it, they would have dead-ended with the 680x0 chip line. Instead, while migrating did lose some developers who didn't want to port, the PPC's power triggered the arrival of plenty of new, exciting applications and developers. Similarly, Apple's migration from MacOS 9 to X weeded out some developers, but attracted many new ones, to the point where is far more popular with developers than any time in the last decade.
Of course, there's the basic issue that the PPC is a faster (per clock) and lower cost processor than the x86. Look at all of the next-generation videogame consoles -- all based on PPC. The main reason to run x86 is legacy code compatibility (i.e. Windows app's) and that's no more an issue for Apple than it is for the videogame companies. So there's not much reason for Apple to migrate to x86.
So aside from there being no reason that Apple would want to move from PPC to x86, there are some strong reasons not to.
First, it's logistically impossible to support the infinite range of PC hardware. They tried, under NeXTSTEP and Rhapsody, and it simply wasn't possible for them to generate enough device drivers to support even a tiny fraction of the cards and motherboards out there. So Apple can't sell MacOS X to run on generic PC's, only on Mac's with x86 processors in them.
But even if they could ship an infinite number of drivers in order to run on generic PC's, I doubt they'd ship it, because MS would immediately kill MS Office for MacOS X in retaliation. This would wipe out Apple in the corporate market, and hurt everywhere else. So just as when MS got Apple to kill MacBasic, etc., MS will be able to keep Apple from competing with them head-on unless Apple has nothing to lose.
Another reason not to sell MacOS X for generic PC's: As much as Apple is limited by being tied to hardware, they're also protected by it. That is, if 5m people use Mac's, they can count on those people continuing to use Mac's unless Apple really, really screws up, because they'd have to replace their hardware, applications, etc. But if a user is only committed to MacOS because he can dual boot his PC into it, not only is it easier for him to "migrate" to MacOS X,
I'd go a bit further with this. My observation from attending various conferences is that since Mac OS X, most technology industry leaders (CTO's, CEO's, writers) are using Mac's, even if they might be making their employees use PC's. For example, at PC Forum two years ago, every single attendee's laptop was a Mac Powerbook, except for one lonely gentleman with a Sony Vaio, who ended up taping an Apple logo to his laptop in order to 'fit in'.
So while Apple's mass market share may not be skyrocketing (though I hear that the Mac Mini is selling quite well), but pretty much every deeply technical person that I know of either works on a Mac, or plans to buy one as their next machine.
Finally, it looks like Windows software development is beginning to die out. My company ships a Windows application (as well as Mac and Linux) and when we went recruiting engineers it was shocking. Every CS major that we interviewed was programming in Python or Ruby, lots of Java, a little.Net. No C or C++. No Windows-specific programming, lots of linux and Mac, mainly using completely portable languages and frameworks.
I have a first generation iPod, and while the battery capacity was dropping, the real killer was that the contacts broke on the firewire jack. It's surface mounted, so it's impossible to repair, rendering the iPod useless, since it both charges and loads music through that jack.
- Radio Shack Model 100 (http://www.club100.org/), was a great very simple computer that was completely indestructible. Sure, it used cassettes for storage, but who needs storage when you have a serial port and a modem? They're on eBay for $25-50. - Atari and HP both made stripped down DOS handhelds with decent, if small, keyboards. They were great for taking notes in class/meetings. - Apple's eMate was wonderful for this. It ran the Newton OS, so it was fast and simple to use, and had a real keyboard, so it was pleasant to type on. - I often wondered why Apple never sold a stripped down Apple II with AppleWorks in ROM as the perfect word processor. You could make a PDA with a 6502 and 128 KB of RAM for under a dollar (my watch and cell phone both have better tech), stick in a B&W display and a keyboard, and perhaps a CF or CD slot for storage, and have a perfect "workstation" for trivial cost. Sure, no web browsing, but for text editing, spreadsheet, and simple database work, it's just great. I still think that someone could crank out tons of these things and sell them in the third world...
"We will see Windows on PowerPC long before we ever see the full OS X on x86."
Ironically enough, we've already seen Windows on PowerPC and OS X on x86. Specifically, Microsoft shipped Windows NT (3.x and 4.0) and Windows CE for PowerPC, and Apple shipped (to developers) Rhapsody for x86, and currently ships WebObjects for many processors, including x86. WebObjects includes the Cocoa runtime, which means that (except for Apple's license prohibiting it) developers could ship their Cocoa applications as a single binary installer for all WebObjects platforms (MacOS X, Windows 2000+, Solaris). I've been told by friends at Apple that they still make sure that MacOS X runs on a wide range of processors (x86, PPC, etc.) in order to make sure that they don't accidentally break the portability that NeXTSTEP gave them. Of course, this doesn't mean that they'll ship it to consumers, but it's important that they keep the option open.
Slashdot Mirror
"Jack of all trades, master of none."
This is a popular saying, but in my experience (and I've built many successful tech teams) you're better off hiring generalists than specialists. Certainly you want to cover your required skillsets somewhere in the team, but in the long run you're better off with people with broad experience who like learning new things.
I've been astoundingly lucky with my latest team -- I have people who are fantastic at each of the specific areas that we need to cover, and they're all interested in pretty much everything. This means that if the "specialist" is unavailable, I have plenty of other sharp people who can dive in and do a good job. And aside from that, it means that everybody has other people to bounce ideas off of that understand the whole system. This is way more fun (and produces a much better overall system) that if I defined the architecture and everyone coded their layers and ignored everything else. And because anyone can challenge any aspect of the system, while there's a little stress, the end result is that (1) everyone respects everyone else's work because they understand it, and (2) the system as a whole is much better because it's the product of more people's contributions.
So after watching disasters repeatedly take place because the people at each layer didn't understand the whole system, you bet I'd rather have generalists running my UNIX clusters. Here's an example: would you rather have a cluster running a database managed by a great sysadmin who understood the OS level but not hardware, a networking guy who didn't understand the applications, and a DBA who didn't understand the OS? Or would you rather have it run by people who understand running clustered hardware and OS, database and application? Sure, those people are much harder to find (which is why big companies hire specialized drones) but smart decisions are valuable, and people can make better informed decisions because they have a broader perspective are worth more than they cost.
While it's certainly true that HR people only know keywords and not substance, there's a good reason to hire people with cross-platform experience -- it's much better for the company.
First, it gives the company more flexibility. If you need more NT or UNIX work done right now, you can shift people fluidly rather than having one team idle while the other is idle.
Second, it leads to more mature and coherent decision making. If you have separate UNIX and NT teams, they'll each come up with a completely different set of answers for everything (and usually compete, which is crazy for morale), so you'll end up running two separate environments, and thus two of everything, so IIS and Apache, Active Directory and LDAP, etc., with little to no integration. But if you hire people who understand both platforms, you can come up with a a unified strategy for the entire company, and make decisions based on technical issues rather than religion.
"Apple puts a lot more engineering into their boxes than the typical PC vendor does // I have no idea what you're talking about here. Are you saying nVidia doesn't put a lot of engineering into their latest 7800 GTX cards or their more mainstream 6600 GT cards?"
By PC vendor, I think that the original poster was referring to companies like Dell, HP, Sony, IBM, Gateway, etc., that make the complete systems. Like Apple, they all use video chipsets from nVidia, etc., but that's not the PC vendor's R&D, that's nVidia's R&D. An open secret in the PC industry is the fact that none of the WinTel PC vendors do any real R&D -- Intel and MS do all of the R&D, and everyone else just does packaging, marketing, fulfillment, customer support, etc. I don't mean to downplay the importance of those services, but they're not R&D.
Apple does less R&D then they used to, but far more than any PC manufacturer. (Exception: there are large companies, like IBM and Sony, that make PC's and also do R&D, but that R&D isn't in the PC division, so IMO it doesn't count). The most obvious R&D investment is that Apple writes its own OS, which no WinTel vendor does. And, of course, Apple invests far more in industrial design than any PC vendor, which is why their machines are the highest rated in terms of reliability, support, etc., as well as the more obvious design appeal and ease of use. And Apple invests heavily in creating new technologies and standards (e.g. ZeroConf, FireWire, MPEG4) that advance the state of the art, and of course they also push adoptions of new technology into the marketplace (e.g. CD-ROM, DVD-R, USB, FireWire, WiFi) far more effectively than any other computer manufacturer. So while Apple didn't invent WiFi, they certainly did the hard work of packaging it and making it work reliably for mainstream users well before, the WinTel market -- Dell, etc., all waited passively until MS and Intel got WiFi somewhat working, then shipped it, which meant that Apple's customers not only got it a year earlier (as a mainstream technology) but it worked better. There are dozens of such examples.
You could argue that MS and Intel spend more on R&D than Apple. But now that Apple is shipping Intel, they benefit from Intel's R&D, which is smart. And Apple has demonstrated time and again that they're far more focused and effective in their R&D efforts. So while MS is pushing ahead on hundreds of fronts, Apple creates a small number of best-of-breed applications (best OS, best music, best DVD creation, etc.).
"I was with you until "Since MacOS X runs on SPARC". NeXTSTEP and OPENSTEP ran on SPARC, but no version of Mac OS X ever has."
. 7/gas-495.8/include/mach/sparc/). Finally, I've also been told by several Apple engineers over the years that Apple maintains NeXTSTEP's portability across more than PPC and x86, specifically mentioning SPARC. So given all of that, it's highly likely that that Apple could easily ship MacOS X for SPARC if they wanted to, but I can't prove it. :-)
OK, I shortened a longer and more complex discussion. Most of the parts of MacOS X run on SPARC. NeXTSTEP and OPENSTEP ran on SPARC, as does WebObjects. Most people don't realize it, but WebObjects includes the Cocoa runtime, which means that Mac Cocoa app's can run on SPARC (over the Cocoa runtime) though Apple doesn't allow developers to license the Cocoa runtime for that purpose. And of course both Mach and BSD run on SPARC, and there are mentions of SPARC in Darwin (for example, http://www.opensource.apple.com/darwinsource/10.3
I'd still love to see MacOS X Server ship on the high-end SPARC's. Not that there's anything wrong with Solaris 10, of course, but it'd be great for Apple and for its customers for Apple to prove the point that the OS matters more than the CPU, and that they have the best, most portable OS.
OK, I have no idea how well MacOS X would run on an 8-core SPARC with 4x "hyperthreading" to have a virtual 32 processors. But it'd be a blast to try.
"the poster I was responding to was talking about building a single source file (the one just modified, usually) and linking it. "make -j" doesn't do anything useful if there aren't multiple source files out of date."
You're right, of course. In theory you could parallelize the compilation process, but that would be very hard to do since any piece of code could be dependent on any other (at least until you parse it enough to understand what it does). At least, with multiple files, the makefile makes the dependencies explicit.
"I agree with the rest of your comments."
Rock on!
Personally, I'd rather see Apple retain a mix of CPU's in the marketplace, and just make sure that developers keep shipping "universal binaries". That gives both Apple and its customers the most flexibility. Want the cheapest possible consumer machine? Use an embedded PPC. Want the fastest server? Use an 8-way UltraSPARC. Want to run on a cheap PC? Run Intel. It's a winning strategy because it defines the applications and the OS as the important thing, and the CPU has just a part to be swapped in based on target requirements.
:-)
And if Apple _really_ wants to confuse people, they could (finally) release the Cocoa runtime for NT. Most people don't realize it, but Web Objects (which ships for PPC, NT and SPARC) contains the Cocoa runtime, so it could (if Apple allowed it to be licensed) to run Cocoa app's everywhere. Wouldn't that be fun! Write a Cocoa app, and ship for every OS. Who needs Win32!
Perhaps I'm biased (I used to work at Thinking Machines) but pany more problems are parallel than you'd think at first, if you have a sufficiently fine-grained parallelism.
e l_make.html, or pmake, http://www.llnl.gov/icc/lc/DEG/pmake/pmake.html) can make project builds significantly faster.
"even a compiler can benefit from multiple threads, though current compilers don't do it"
Actually, Parallel Make (i.e. gmake -j, http://developers.sun.com/solaris/articles/parall
Beyond that, any time that you're rendering graphics, or sorting data, or in fact using any large volume of data, or doing more than one thing at a time, multiple processors could help. This is why most graphics cards are highly parallel, and why all high-end databases run well on many processors. Heck, even booting a computer benefits from parallel execution. Of course, it may be hard work expressing the dependencies between processes properly (e.g. parallel makes can break makefiles that have implicit dependencies in instruction order that work serially, but which break when parallelized), but if the problem is worth thinking harder about, it can probably be parallelized.
"when the work done by each thread is examined, it is performing serial tasks; e.g. it is internally single-threaded, so we haven't *really* got away from the single-threaded paradym."
That's true, but it doesn't matter. The point isn't whether programmers write multi-threaded code, but whether software runs faster.
Keep in mind that Sun's market is servers, where you have big expensive boxes processing hundreds or thousands of transactions a second. Each transaction can (and usually is) written as serial code, because that's easier to write and debug. However, it doesn't matter that each transaction is single-threaded, because there are many different transactions, and becauase the web servers, application servers, and databases _do_ understand threading. So if a CPU can handle 32 different transactions at once, and your OS/web server/app server can distribute and manage those threads properly, your server performance is just as good as if you had one processor running 32x as fast. Of course, you can't make a CPU 32x as fast (ask Cray), so this is a very clever way to make computers faster.
Of course, if you're running desktop applications it's a whole different ball of wax, because users aren't doing hundreds or thousands of different things at once -- they're probably doing 1-2 things at a time. So if you're playing a game and that game is single-threaded, then 31 of those virtual CPU's will go naerly unused. But Sun doesn't sell desktop computers.
Hmm. Since MacOS X runs on SPARC (OK, it used to until recently, and we can assume that Apple has probably kept at it), I wonder if Apple would be interested in selling Xserves running on these nifty new SPARC's -- they're probly better CPU's for servers than Intel, and would make the point that the OS is more important than the CPU.
"I go do the updates, 11 at number"
Not to say that your Mac didn't somehow crash and corrupt the OS, but I've done pretty much the same thing that you did several times recently (I just set up a testing lab full of Mac Mini's) and none of them had any trouble, I've never even heard of Terminal conflicting with anything, and there's only been one update released to Tiger (to update it to 10.4.1). So I have no idea what the actual problem is that you had...
"Mac OS X (by virtue of the fact that it's largely compiled with gcc) is quite easy to port"
This claim is just silly; anyone who's ported code between UNIX machines knows that simply being compiled with GCC doesn't give portability. MacOS X is extremely portable because it was originally written very carefully to be portable (NeXTSTEP ran on 680x0, x86, HP-PA/RISC, SPARC) and Apple has carefully maintained that portability.
That being said, I agree with your main point -- MacOS X is highly portable, and anything written using Cocoa or Carbon should be easily or trivially portable to any OS.
So one interesting side-effect of the x86 migration is that once app's are compiled with universal binaries, it's very easy for Apple to add additional CPU's and have everything just work. So Apple could use those amazing next-generation SPARC's on serves, x86 on high-end desktops, and PPC's in low-end machines, and everything would "just work".
"Apple has now just become another Microsoft by the looks of it."
Why do you say that? Apple's releasing a version of their OS that runs on Intel chips doesn't make them Microsoft any more than Microsoft's releasing a version of their OS that runs on PPC's.
"why cant they just run the normal Max OS X binaries on X86 if they're universal binaries like they speak of?"
Because they didn't ship "universal binaries" out to consumers. So while they were compiling and testing the OS and iLife app's on x86 as well as PPC, they only shipped the PPC binaries externally.
"I wondered why they threw iLife in there."
:-)
And, of course, because they've compiled the iLife applications for x86, and want to prove that MacOS X on x86 runs real native applications. It's hard to argue that video editing, music playback, and photo organizing aren't "real".
"Take a look at gnustep. It is quite advanced, now."
Yep. We're hoping that we can use GnuStep to ship a MacOS X application on Linux, etc. ( http://www.gnustep.org/resources/documentation/Us er/GNUstep/machines_toc.html .
"If your Mac Tiger app is 64 bits, you're screwed. Won't even run in the emulator."
Two points.
First, there aren't any Mac app's that I know of that _require_ 64-bit CPU's, because they won't run on G3's and G4's, which means most Mac's, all laptops, etc. So app's that take advantage of 64-bit instructions also have a 32-bit version of the code.
Second, while the Universal Binary Programming Guidelines do only talk about the IA-32 instruction set, but it clearly supports 64-bit data types, and MMX/SSE/SSE2/SSE3, and I'd be stunned if it weren't possible to run 64-bit code on 64-bit x86's. Admittedly the 64-bit picture on Intel is a bit more complicated than on PPC (since the various x86 chip companies had different 64-bit stragies), but Apple's got a year to work it out. And, for what it's worth, rumor has it that Apple got MacOS X to compile on the Alpha at one point, which should have cleared up the dependencies on 32-bit code.
Ah, it's nice to meet another former NeXT developer.
Say what you will about NeXT, but they created some fantastic software. I used to write on NeXTSTEP on x86, and deploy on HP/PA-RISC, x86 and 680x0's. It was amazingly painless.
Wouldn't it be nice if Apple let developers ship the Cocoa runtime? Then we could write app's once, and run them on as native binary app's on Win2K, MacOS X, Solaris, etc.
This wasn't the transition from 680x0 to PPC -- a/v people loved the PPC's. The reason that the transition from MacOS X to MacOS X was hard for a/v people that that under MacOS X an app could take over the machine, giving it complete control over everything, and allowing for very smooth performance (if you didn't want to do anything else at the same time). The early versions of MacOS X didn't have good a/v support (fine for consumers, not good enough for pro's), but the later versions of MacOS X turned this around.
Of course, in the a/v world, if a machine is working fine and getting your work done, you don't mess with it -- there's a lot of weird voodoo that affects you when you're doing realtime transitions between multiple video streams, and if it works you just keep your fingers crossed and work it. So there's no reason to upgrade a production MacOS 9 machine to MacOS X.
"I had to deal with a painful and extremely nasty transition, when Apple switched from the 680x0 to the PowerPC architecture"
o nceptual/universal_binary/universal_binary.pdf and it doesn't look too bad. If you build in Xcode or PowerPlant, the tools should take care of you. If you wrote AltiVec code, you have work to do porting to MMS/SSE/SSE2. If you use binary data files, instead of XML, you've got some work to do (big/little endian...).
It wasn't that bad. When the PPC first came out, In a fit of lunacy, I swapped a hard drive from a 68030 Mac to a PPC 601 PowerMac, and IT BOOTED AND RAN PERFECTLY. And all 680x0 app's worked fine; you only had to upgrade to get better performance. It was by a wide margin the smoothest platform migration I've ever seen or even heard of.
I may be biased -- I was a NeXTSTEP developer, and I got used to being able to build fat binaries that ran natively on all platforms, with zero effort.
Anyway, I just read http://developer.apple.com/documentation/MacOSX/C
All Apple has to do to make this migration painless for users is:
- Make sure that the Rosetta emulator works well enough to run legacy app's. There are some significant limitations, but it should work on generic legacy applications.
- Make it so trivial to build and ship "universal binaries" that everything runs on both PPC and x86 long before the machines are released, so everything just works.
- Push to get the major software vendors (e.g. MS, Adobe) to commit early to the x86, to encourage other developers to ship universal binaries.
The part of this that still amazes me is that there's enough reason there make this migration. All I can think of is that Intel has much cooler secret stuff in their labs than IBM and Motorola did.
Really? The tiny, and completely unsupported wires broke that run between the board and the firewire jack. If I could find a jack that was physically identical, perhaps I could swap it in, but it looks pretty unique. Is there hope?
WebObjects is written in Cocoa, and includes the Cocoa runtime. So while WebObjects has lots more stuff in it in addition to that (including Java support), the fact that it runs on many OS's shows that the original NeXSTEP/OPENSTEP portability is not lost.
"One advantage Apple has this time: The open-source FreeBSD operating system, of which Mac OS X is a variant, already runs on x86 chips such as Intel's Pentium."
Actually, it's a lot easier than that for Apple -- MacOS X runs just fine on x86. For background, NeXTSTEP and Rhapsody (the pre-release name for MacOS X) ran just fine on x86, and word has it (I don't want to get anyone in trouble...) that Apple's made sure that MacOS X still runs on all of the CPU's that NeXTSTEP ran on -- x86, SPARC, PA-RISC, etc., in order to make sure that they keep their options open. to make it even more obvious, keep in mind that Web Objects is the _same_ as the Cocoa runtime, and it runs on all sorts of processors. The only reason that Mac developers can't ship applications that run natively across all major OS's and hardware platforms is that Apple won't license the Web Objects runtime for that purpose, because they'd rather control and sell the entire platform.
"developers will need to rewrite their programs to run on intel" (paraphrased) is just wrong. For Cocoa app's, all of the development tools support building "fat binaries" that can contain the executable versions for numerous processors. Back when I was a NeXT developer, I used to build app's that ran natively on 680x0, x86, SPARC and PA-RISC all the time. Admitedly Apple has hidden this capability, but it's obviously still an option for Apple to allow developers to build fat binaries again.
For non-Cocoa applications, it's theoretically possible to get developers to recompile their applications, if all of the frameworks, etc., are ported, but I wouldn't be surprised if, just like the PPC migration, the answer was to use emulation to run legacy code.
"every time Apple migrates they lose customers and developers" Actually, the PPC migration was good for Apple. Without it, they would have dead-ended with the 680x0 chip line. Instead, while migrating did lose some developers who didn't want to port, the PPC's power triggered the arrival of plenty of new, exciting applications and developers. Similarly, Apple's migration from MacOS 9 to X weeded out some developers, but attracted many new ones, to the point where is far more popular with developers than any time in the last decade.
Of course, there's the basic issue that the PPC is a faster (per clock) and lower cost processor than the x86. Look at all of the next-generation videogame consoles -- all based on PPC. The main reason to run x86 is legacy code compatibility (i.e. Windows app's) and that's no more an issue for Apple than it is for the videogame companies. So there's not much reason for Apple to migrate to x86.
So aside from there being no reason that Apple would want to move from PPC to x86, there are some strong reasons not to.
First, it's logistically impossible to support the infinite range of PC hardware. They tried, under NeXTSTEP and Rhapsody, and it simply wasn't possible for them to generate enough device drivers to support even a tiny fraction of the cards and motherboards out there. So Apple can't sell MacOS X to run on generic PC's, only on Mac's with x86 processors in them.
But even if they could ship an infinite number of drivers in order to run on generic PC's, I doubt they'd ship it, because MS would immediately kill MS Office for MacOS X in retaliation. This would wipe out Apple in the corporate market, and hurt everywhere else. So just as when MS got Apple to kill MacBasic, etc., MS will be able to keep Apple from competing with them head-on unless Apple has nothing to lose.
Another reason not to sell MacOS X for generic PC's: As much as Apple is limited by being tied to hardware, they're also protected by it. That is, if 5m people use Mac's, they can count on those people continuing to use Mac's unless Apple really, really screws up, because they'd have to replace their hardware, applications, etc. But if a user is only committed to MacOS because he can dual boot his PC into it, not only is it easier for him to "migrate" to MacOS X,
I'd go a bit further with this. My observation from attending various conferences is that since Mac OS X, most technology industry leaders (CTO's, CEO's, writers) are using Mac's, even if they might be making their employees use PC's. For example, at PC Forum two years ago, every single attendee's laptop was a Mac Powerbook, except for one lonely gentleman with a Sony Vaio, who ended up taping an Apple logo to his laptop in order to 'fit in'.
.Net. No C or C++. No Windows-specific programming, lots of linux and Mac, mainly using completely portable languages and frameworks.
So while Apple's mass market share may not be skyrocketing (though I hear that the Mac Mini is selling quite well), but pretty much every deeply technical person that I know of either works on a Mac, or plans to buy one as their next machine.
Finally, it looks like Windows software development is beginning to die out. My company ships a Windows application (as well as Mac and Linux) and when we went recruiting engineers it was shocking. Every CS major that we interviewed was programming in Python or Ruby, lots of Java, a little
I have a first generation iPod, and while the battery capacity was dropping, the real killer was that the contacts broke on the firewire jack. It's surface mounted, so it's impossible to repair, rendering the iPod useless, since it both charges and loads music through that jack.
I have owned a few devices that would qualify:
- Radio Shack Model 100 (http://www.club100.org/), was a great very simple computer that was completely indestructible. Sure, it used cassettes for storage, but who needs storage when you have a serial port and a modem? They're on eBay for $25-50.
- Atari and HP both made stripped down DOS handhelds with decent, if small, keyboards. They were great for taking notes in class/meetings.
- Apple's eMate was wonderful for this. It ran the Newton OS, so it was fast and simple to use, and had a real keyboard, so it was pleasant to type on.
- I often wondered why Apple never sold a stripped down Apple II with AppleWorks in ROM as the perfect word processor. You could make a PDA with a 6502 and 128 KB of RAM for under a dollar (my watch and cell phone both have better tech), stick in a B&W display and a keyboard, and perhaps a CF or CD slot for storage, and have a perfect "workstation" for trivial cost. Sure, no web browsing, but for text editing, spreadsheet, and simple database work, it's just great. I still think that someone could crank out tons of these things and sell them in the third world...
"We will see Windows on PowerPC long before we ever see the full OS X on x86."
Ironically enough, we've already seen Windows on PowerPC and OS X on x86. Specifically, Microsoft shipped Windows NT (3.x and 4.0) and Windows CE for PowerPC, and Apple shipped (to developers) Rhapsody for x86, and currently ships WebObjects for many processors, including x86. WebObjects includes the Cocoa runtime, which means that (except for Apple's license prohibiting it) developers could ship their Cocoa applications as a single binary installer for all WebObjects platforms (MacOS X, Windows 2000+, Solaris). I've been told by friends at Apple that they still make sure that MacOS X runs on a wide range of processors (x86, PPC, etc.) in order to make sure that they don't accidentally break the portability that NeXTSTEP gave them. Of course, this doesn't mean that they'll ship it to consumers, but it's important that they keep the option open.