In many cases engineers have been brought on stage to demonstrate products.
I believe you're confusing suits with engineers. Please name an engineer who's shared the stage with Steve at a keynote.
And, at the end every single keynote, Steve Jobs thanks all of the employees and their families for their hard work and sacrifices. Then he asks the employees in the audience to stand up and asks the audience to give them around of applause.
Maybe Apple offers a no-nonsense environment where they can work on their stuff until "it's done right" rather than "we must ship, fix it later" mentality.
Nope. Have a look at any recent OS X x.0 release if you don't believe me.
Steve Jobs trots out a half-dozen people, remarks how this person worked on this and that person lead this great team who did that, and generally gives credit to lots of other people, including people who aren't even directly part of Apple. He's done this at EVERY keynote speech pretty much since he's been giving them.
Note that he trots out the suits. Always the same suits, too.
You're not getting it. I'm not saying that Apple should market their own virtual machine hosting software, I am saying that they should provide kernel-level support for virtualization. Two entirely different propositions.
The current state of play is that VMware and Parallels have to carve off big hunks of memory and completely duplicate low-level MMU code. Bad for performance. Bad for reliability.
Where the heck is virtualization? The hardware is there, just begging to be used. No integrated kernel-level support for virtualization and no support for virtualizing OS X.
Apple has really dropped the ball badly on this one.
The world is waking up to the fact that every fiat currency in the world is a house of cards game of hot potato nobody wants to be holding when the music stops.
I've heard the same from folks that work there, so it may be true. Then again, Apple has layer upon layer of secretness in place, so it's hard for anyone but Steve to know. We do so love to speculate...
The third slide in the presentation clearly states that the Z6 is a sibling of the Power6 and that the Z6 uses many of the functional units of the Power6. Further along in the presentation, slide 14 talks about the use of multiple-passes and millicode to handle CISC ops.
Clearly the Z6 is exquisitely optimized to execute the z/Architecture instruction efficiently. It is also clear that it is part of the Power6 family.
Since the competition is designed by, sponsored by, and conducted by folks with a point to prove, the outcome is not in doubt. The hydra is gonna kick the dragon's ass.
I've been writing code professionally since 1976, and have had to endure more than my share of management-instigated nonsense, including various stabs at a "collaborative development" work environment as an attempt to end-run "Mythical Man Month." It's like trying to build a perpetual motion machine while making all of your employees suffer.
As a web developer, I routinely install browser betas so that I can catch any problems before they develop. I'm a business and that's called being proactive.
What I also do is run a zoo of Windows / Explorer combos in virtual machines. It's fun to do side by side comparisons. My summary: Vista is much slower at everything.
You're right about not much platform specific code, but dead wrong about LLVM. Apple's approach is more traditional, isolating most of the platform specific code in the OS kernel. I'd estimate that 95% of the platform specific code in the kernel is written in plain old C, with a few assembly language routines to do the MMU heavy lifting. Don't take my word for it, download Darwin's xnu component and have a look for yourself.
Hard drives have been becoming less and less reliable as densities increase. Seagate, WD, Hitachi, Maxtor, Toshiba, heck, they all die, often sooner than their warranties are up. They're mechanical devices, for crying out loud.
So here's a bit of good advice: If you really care about your data, use a RAID array with redundancy (RAID 1 or 5). It will cost a bit more, but you'll sleep better at night.
Thank you all for your kind attention. That is all.
This reminds me of the bozo bit in the early Macintosh file system. Not much protection, but it did force the attacker to take an action that might be later used to demonstrate intent. Perhaps the P_LNOATTACH serves a similar purpose?
My patent attorney warned me against researching prior art. His argument was that if during my research I found that anything my company made was covered by a patent that had not been properly licensed, then I was on the hook for damages; otherwise, I would simply be on the hook for fees.
While I'm blithering away on this topic, I'd like to point out that the x86 architecture makes no attempt to specify how I/O devices access memory. This is a huge open problem for virtualization performance and security. To be secure a virtual machine monitor must simulate all I/O; otherwise, an attacker in one virtual machine can access any memory belonging to another virtual machine through I/O direct memory access. Ignoring the security issue, the lack of a uniform architecture for I/O memory access makes virtualization difficult, leading to sub-optimal solutions such as having all I/O performed by one authorized virtual machine.
Absolutely correct. The presence of virtualization hardware, specifically how well it handles address translation, is key to virtual machine performance. Intel and AMD have just begun on this path, so I would not expect to see near-native performance out of their virtualization hardware for at least the next two or three iterations. IBM followed this path with interpretive execution in the 80's and 90's. It took several iterations of the hardware/software combination before interpretive execution and VM/XA delivered near-native performance.
Backus, et al., wrote FORTRAN for and on the IBM 704. The 704 was a 36-bit vacuum tube machine that could sustain 4902 single-precision floating point multiplies per second. His team wrote the entire compiler in 704 assembler language, writing and maintaining its roughly 50,000 lines of code using punched cards and magnetic tape. Because a complete assembly of the compiler ran several hours, programmers made changes in binary machine code, noting them on a paper listing for later inclusion in the source.
They had to invent the compiler as they went along. Working toward the goal of producing code as good as that written by a skilled assembly language programmer, his team invented key optimizations including register renaming, code hoisting, branch prediction, and strength reduction. We continue to this day to use Backus-Naur Form (BNF) to describe a computer language's syntax.
And it worked. Truly brain surgery with stone knives.
Slashdot Mirror
http://www.nature.com/nature/journal/v454/n7204/abs/nature07130.html
I believe you're confusing suits with engineers. Please name an engineer who's shared the stage with Steve at a keynote.
And, at the end every single keynote, Steve Jobs thanks all of the employees and their families for their hard work and sacrifices. Then he asks the employees in the audience to stand up and asks the audience to give them around of applause.What a truly wonderful human being he is.
Nope. Have a look at any recent OS X x.0 release if you don't believe me.
Note that he trots out the suits. Always the same suits, too.
Never, ever an engineer on the stage.
Core 2 Duo was only a few months away, and Apple had the roadmap. They even had samples.
You're not getting it. I'm not saying that Apple should market their own virtual machine hosting software, I am saying that they should provide kernel-level support for virtualization. Two entirely different propositions.
The current state of play is that VMware and Parallels have to carve off big hunks of memory and completely duplicate low-level MMU code. Bad for performance. Bad for reliability.
Not everyone internally was happy about the choices, but management got what it wanted.
Apple has really dropped the ball badly on this one.
TFA contains the same numbers as the summary, but doesn't name the respondents.
Wow. Three cliches in one!
Good point, BTW.
I've heard the same from folks that work there, so it may be true. Then again, Apple has layer upon layer of secretness in place, so it's hard for anyone but Steve to know. We do so love to speculate...
The third slide in the presentation clearly states that the Z6 is a sibling of the Power6 and that the Z6 uses many of the functional units of the Power6. Further along in the presentation, slide 14 talks about the use of multiple-passes and millicode to handle CISC ops.
Clearly the Z6 is exquisitely optimized to execute the z/Architecture instruction efficiently. It is also clear that it is part of the Power6 family.
Since the competition is designed by, sponsored by, and conducted by folks with a point to prove, the outcome is not in doubt. The hydra is gonna kick the dragon's ass.
I've been writing code professionally since 1976, and have had to endure more than my share of management-instigated nonsense, including various stabs at a "collaborative development" work environment as an attempt to end-run "Mythical Man Month." It's like trying to build a perpetual motion machine while making all of your employees suffer.
As a web developer, I routinely install browser betas so that I can catch any problems before they develop. I'm a business and that's called being proactive.
What I also do is run a zoo of Windows / Explorer combos in virtual machines. It's fun to do side by side comparisons. My summary: Vista is much slower at everything.
You're right about not much platform specific code, but dead wrong about LLVM. Apple's approach is more traditional, isolating most of the platform specific code in the OS kernel. I'd estimate that 95% of the platform specific code in the kernel is written in plain old C, with a few assembly language routines to do the MMU heavy lifting. Don't take my word for it, download Darwin's xnu component and have a look for yourself.
You betcha, alizard, both RAID and regular offsite backups are mandatory for that good, refreshing sleep.
Hard drives have been becoming less and less reliable as densities increase. Seagate, WD, Hitachi, Maxtor, Toshiba, heck, they all die, often sooner than their warranties are up. They're mechanical devices, for crying out loud. So here's a bit of good advice: If you really care about your data, use a RAID array with redundancy (RAID 1 or 5). It will cost a bit more, but you'll sleep better at night. Thank you all for your kind attention. That is all.
This reminds me of the bozo bit in the early Macintosh file system. Not much protection, but it did force the attacker to take an action that might be later used to demonstrate intent. Perhaps the P_LNOATTACH serves a similar purpose?
My patent attorney warned me against researching prior art. His argument was that if during my research I found that anything my company made was covered by a patent that had not been properly licensed, then I was on the hook for damages; otherwise, I would simply be on the hook for fees.
While I'm blithering away on this topic, I'd like to point out that the x86 architecture makes no attempt to specify how I/O devices access memory. This is a huge open problem for virtualization performance and security. To be secure a virtual machine monitor must simulate all I/O; otherwise, an attacker in one virtual machine can access any memory belonging to another virtual machine through I/O direct memory access. Ignoring the security issue, the lack of a uniform architecture for I/O memory access makes virtualization difficult, leading to sub-optimal solutions such as having all I/O performed by one authorized virtual machine.
Absolutely correct. The presence of virtualization hardware, specifically how well it handles address translation, is key to virtual machine performance. Intel and AMD have just begun on this path, so I would not expect to see near-native performance out of their virtualization hardware for at least the next two or three iterations. IBM followed this path with interpretive execution in the 80's and 90's. It took several iterations of the hardware/software combination before interpretive execution and VM/XA delivered near-native performance.
Backus, et al., wrote FORTRAN for and on the IBM 704. The 704 was a 36-bit vacuum tube machine that could sustain 4902 single-precision floating point multiplies per second. His team wrote the entire compiler in 704 assembler language, writing and maintaining its roughly 50,000 lines of code using punched cards and magnetic tape. Because a complete assembly of the compiler ran several hours, programmers made changes in binary machine code, noting them on a paper listing for later inclusion in the source.
They had to invent the compiler as they went along. Working toward the goal of producing code as good as that written by a skilled assembly language programmer, his team invented key optimizations including register renaming, code hoisting, branch prediction, and strength reduction. We continue to this day to use Backus-Naur Form (BNF) to describe a computer language's syntax.
And it worked. Truly brain surgery with stone knives.