The chart he's using goes from SCSI, to fiberchannel, to SAS... to SATA. When you go from professional/server interfaces to hobby/desktop ones, of course the rebuild time skyrockets. If you did this article a few years ago and slid ATA in as the last data point instead of fiberchannel, you'd be seeing the knee showing up then instead of now. How about looking at 2010 and doing the calculations with 6 Gb SAS interconnect and 3 Gb drives, instead of 1.5 Gb SATA and 1 Gb drives?
Your link sends me to a placeholder (1x1 "void.gif").
To me the Palm[sized] PC shell appeared vaguely similar to the Handheld PC shell, but it was stripped down with all the root windows stuck at full screen and no widgets to detach or minimize them. That was the distinction I was getting at. Anyway, if there's still a viable Handheld PC code base in active development at Microsoft it seems really strange that they're not pushing it on linux-friendly netbook makers.
Ah. There is conflicting information about the CNMbook CPU. Some say ARM, some say MIPS.
Their web page says the Windows CE version is ARM, and the older Linux one is MIPS. Good guess, confirmed by Google.
We may possibly be talking cross-purposes, but these manufacturers aren't using a per-vendor custom shell because they're all the same.
OK, it was hard to see that from the pictures... some of them have the bar hidden. I'll take your word for it.
a stock CE build (branded as CE.Net since v4) ships with a default shell based on the old Handheld PC one and only slightly updated.
It sure looks like the Palm-PC/Palm-sized PC/Pocket PC shell, not the Handheld-PC one.
FWIW, you might want to look up the CNMbook, since that actually is a CE5.NET netbook (based on a MIPS core, I think).
Interesting. I really thought Microsoft had killed the Windows-CE-based Handheld PC. I've seen devices described that way since, but they've all been NT-based. It's an ARM, BTW. Does anyone still use MIPS in handhelds?
Those devices have a PDA form factor, they're all using either a custom shell or something based on the Pocket PC shell. They're not using the Handheld PC shell that was used in things like the Thinkpad z50 or Jornada 720.
They still do, the problem is it's shit and it won't run any off-the-shelf applications. It's used in a number of industrial PDAs, particularly ruggedized, intrinsically-safe ones.
Is it? I haven't seen any devices using the Handheld PC user interface since around 2001. I'm not talking about the Pocket PC fork that Windows Mobile is based on and Symbol and others use in their PDA-form-factor devices. The Handheld PC fork required a larger screen and a keyboard, and disappeared when Microsoft decided that the way to beat Palm was to copy Palm OS (of course, with 20-20 hindsight, we know they didn't have to do anything... Palm disintegrated on their own due to corporate ADHD).
How are you going to detect a 15g to 100g logging circuit that's more than likely (if there was malicious espionage intent) designed to fit or mount into current hardware and not be detected on a scale that's accurate down to 0.5 pounds.
Here's a long shot... how about using a postal scale that's accurate down to a gramme? Do you think there might be one in the mailroom?
Microsoft used to have a laptop/netbook-friendly Windows CE version back in the late '90s, but dumped it in favor of the "Tablet PC" build of Windows NT around 2000-2001. It would be interesting to see them bring that back.
I was arguing that OpenGL was NOT the basis of Quartz from the beginning, which was your assertion
That was a secondary point. I was apparently wrong about the implementation, but the implementation details don't change the fundamental point I was trying to make: backing store, especially for subwindows, requires much more memory.
you claimed that rendering was to an offscreen texture as a result, and that there was overhead from OpenGL.
I was arguing that there was overhead due to the extra memory required for the backing store, not that there was any inherent overhead imposed by OpenGL itself. Whether rendering is implemented via OpenGL, Quickdraw, or a completely independent API and code base, there is a significant difference in the memory requirements of an implementation where virtually all applications implement the redraw using damage list and where virtually all applications use backing store.
It seems I was wrong about this backing store being implemented as an OpenGL texture, but that doesn't change the basic point: retaining a full backing store for all windows was responsible for much higher memory requirements on OS X.
Update: A bit more is revealed in a Seattle Times Q&A with Brian Seitz, Microsoft's Zune marketing manager. At the moment, the strategy is to keep all the apps and games free and developed in-house or in close collaboration with third parties -- no third-party SDK for devs to freely crank out apps just yet. Seitz is clear that games will be the primary focus of the "sometimes-connected" Zune HD and the Windows Marketplace is Microsoft's priority for handheld app development:
"So what we didn't want to do was build two parallel app store experiences that didn't work together. Right now our product roadmaps didn't line up perfectly for us to snap to what they're doing or vice versa... Down the road if there's a way we can work with Windows Mobile or another group inside the company that's building an app store and take advantage of that, that's something we'll look into."
Man, Windows Mobile 7 and the rumored OneApp app store can't get here soon enough.
This is false; it is possible that the default was to enable Backing Store, but that is not the only behavior available to a Quartz application.
This is irrelevant; it may have been possible for Quartz applications to disable backing store, but if the majority of applications didn't (and in particular Apple's own applicatons didn't) the result is the same... IN PRACTICE you will ALWAYS have MASSIVELY higher memory requirements on OS X than on NeXTstep/OpenStep/Rhapsody. Which you did. I had to treble the RAM in my old PowerMac just install OS X.
Which, going back several messages to the original point I was making about why OS X was such a hog compared to BeOS *and* its contemporaries, IS the point.
Apple confused things terribly when they started talking about using compositing on the GPU instead of the CPU. Quartz was integrated with OpenGL from the start... even on Puma (I didn't switch early enough to see Cheetah) OpenGL and Quartz applications worked together, and multiple OpenGL applications could run concurrently, including having them overlaid by other windows, and this worked whether OpenGL was handled by software or hardware.
It's possible I'm confused about the details of the integration between OpenGL and Quartz, but in terms of the performance impact it doesn't matter: every window, from the start, was completely buffered and hidden sections of windows were always completely rendered. This applied to scrolling subwindows as well. This meant applications didn't need to deal with damage lists unless they chose to... ports of older apps like Photoshop would have retained their own rendering code, but new Cocoa applications sisn't have to handle damage events and re-render hidden portions of windows.
This is the key point: this massive increase in memory use from the Window system, and all the extra overhead of maintaining these bitmaps, was the biggest performance penalty OS X had. I used NeXTStep, OpenStep on Intel, Rhapsody DR1, and OS X from Puma on... and NeXTStep, OpenStep, and Rhapsody were all much faster, much more lightweight, much more responsive, than OS X.
And they were comparable to BeOS, and had lower memory requirements than BeOS. BeOS was impressive, but it wasn't so completely beyond its contemporaries as people keep trying to make out.
Quartz was not always based on OpenGL. Quartz Extreme, introduced with OS X 10.2, used hardware compositing, but prior to that it was all done in software.
The term "OpenGL" is not restricted to implementations based on a hardware video accelerator. There are pure software OpenGL implementations, like the one Apple still uses (for example, to implement T&L for the Intel GPUs on the first generations of Macbook (non-pro) and intel Mac Mini), which was used to run OpenGL-based software (like Quartz) on unaccelerated hardware.
Quartz itself is an evolution of Display PostScript.
Quartz was a complete from-scratch re-implementation, because Adobe's licensing for Display Postscript cost too much, and Apple took advantage of that to make it OpenGL-based.
Buffering of subwindows wasn't added until 10.5
Subwindows were implemented as separate textures in 10.1. You could see it happening just by opening up a scrollable window in just about any application that used Apple's rich text widgets and watching the memory use soar as the entire document was rendered into the scrolling area in the background.
If you had a 386 with 8MB you were doing pretty damn well. My first 486 only had 4MB, and my first laptop (Toshiba Libretto) came with 8MB and was eventually maxed out at 32MB.
First of all, Quartz was not always GPU-accelerated.
I have not said one word about a GPU here. Not one. Quartz was always based on OpenGL, when you didn't have a GPU (like my PowerMac 7600) it was using software OpenGL. Yes, right from the start, even on my completely unaccelerated PowerMac, and yes it was a hog right from the start because it used dedicated textures for everything.
Second of all, OSX is not a new OS, it's based on NeXTStep
Indeed. Rhapsody DR1 (which I mentioned above) was basically NeXTstep with a menu bar. It was still using Display Postscript instead of Quartz. I also had a NextStation, and it was more responsive with 16M and a 68040 than my powerMac under OS X with 112MB and a PPO 603e. Display Postscript, heavyweight as it was, was far lighter weight than Quartz.
BeOS looked like it had some actual advantages to the end user. I had a BeBox briefly and it's frankly amazing what two 66 MHz 603e chips could do with an operating system designed from the ground up for multiprocessing.
I use BeOS on my PowerMac and it naturally kicked MacOS butt (to the point where OS 8 under SheepShaver was faster than OS 8 on the raw hardware), but that's such a low hurdle to jump: the underlying operating system on pre-OSX Macs would have been considered primitive in 1969... it was nothing more than a set of common I/O libraries, no scheduling or central resource management at all... a single-tasking monitor like something from the early days of the IBM 360. The multitasking on later versions was kludged in through the window system, and programming for it was like writing a device driver... scheduling was handled by having the application call back to the OS to let other apps run "often enough".
Later I got to run it on a Wintel box and compare it head-to-head with Windows (NT4 at the time) and FreeBSD and Rhapsody DR1. It was the most resource-hungry of all four operating systems, which totally blew my mind. There was more memory contention and stalling (even for command line apps) on a PC with 16M (which sounds small now, but it was pretty high end back then).
It's not the kernel and OS design that makes OS X slow, it's the heavyweight window system. Making every window (including subwindows!) its own OpenGL texture simplifies application development somewhat, but it's a massive burden on the hardware. The API is also very MacOS/Windows like with a lot of tight cooperation required between the UI library and the display, coupling the UI to the application and creating an unnecessary bottleneck. Without that overhead it would be just as responsive as BeOS on comparable hardware.
But the most amazingly responsive OS I've used was the one shipped with the Amiga. A very lightweight and efficient kernel, a lightweight window system that ALSO avoided coupling the UI and the application (the input handler for most standard widgets ran completely asynchronously from the app, only passing completed selection and menu events down the input chain). You were impressed by what it could do on two 66 MHz CPUs? Luxury, mate. Try it with a single 7.14 MHz 68000 and tell me how fast it is.
This might be a little over the top, but pretty much all phones, except for hardcore smartphones running "outsider" software platforms like Palm and Windows Mobile (yes, it sounds odd to put Windows anything in that category, but fair's fair) are heavily restricted and locked down in one way or another. That includes the iPhone, and even Android: one of the advantages of Android over OpenMoko to the cellphone companies and carriers was that it let them maintain some of that lock-in.
So, your cellphone company and mobile provider are already pulling that kind of crap, albeit in areas you apparently don't notice or care about.
I have been finding it harder and harder to avoid being thrown willy-nilly into the new Slashdot beta interface. For a while I was getting half-beta half-vanilla, until I complained on another forum and it got to a slashdot developer that way.
Now I'm finding that links to articles from comment pages take you to a different URL which always shows a "rich" interface whether you have it enabled or not.
Slashdot... dump the beta, and drop the fancy user interface. You're better off without it.
Think of how often we've seen someone ask a question about how to do "this" or "that" with some linux distro and the resulting answer is very complex and requires an above-average level of computer comfort?
More often than asking the same question about Windows and you get told something starting with "edit this registry key...", I will admit.
Less often than asking the same question about Windows and you get told "You used to be able to do that, but..." or "You need to try this shareware program that edits the registry for you...", or "Why would anyone want to do that?", or "You must be a pirate/virus writer/other scum for wanting to bypass X, Y, and Z...".
I just upgraded to Vista at work, so I could use more than 4G of RAM for VMs, and I'm just about ready to hunt down an XP 64 disc and see if I can make it work... because the new "security features" (air-quoting to denote that that's an insult, not that the features actually provide any security) break software I have come to depend on, like Synergy, in unpleasant ways.
It's really scary when Linux, the epitome of Open Source instability and weird interactions, is more stable and has fewer unpleasant surprises than proprietary software.
Slashdot Mirror
The chart he's using goes from SCSI, to fiberchannel, to SAS... to SATA. When you go from professional/server interfaces to hobby/desktop ones, of course the rebuild time skyrockets. If you did this article a few years ago and slid ATA in as the last data point instead of fiberchannel, you'd be seeing the knee showing up then instead of now. How about looking at 2010 and doing the calculations with 6 Gb SAS interconnect and 3 Gb drives, instead of 1.5 Gb SATA and 1 Gb drives?
Your link sends me to a placeholder (1x1 "void.gif").
To me the Palm[sized] PC shell appeared vaguely similar to the Handheld PC shell, but it was stripped down with all the root windows stuck at full screen and no widgets to detach or minimize them. That was the distinction I was getting at. Anyway, if there's still a viable Handheld PC code base in active development at Microsoft it seems really strange that they're not pushing it on linux-friendly netbook makers.
Ah. There is conflicting information about the CNMbook CPU. Some say ARM, some say MIPS.
Their web page says the Windows CE version is ARM, and the older Linux one is MIPS. Good guess, confirmed by Google.
We may possibly be talking cross-purposes, but these manufacturers aren't using a per-vendor custom shell because they're all the same.
OK, it was hard to see that from the pictures... some of them have the bar hidden. I'll take your word for it.
a stock CE build (branded as CE.Net since v4) ships with a default shell based on the old Handheld PC one and only slightly updated.
It sure looks like the Palm-PC/Palm-sized PC/Pocket PC shell, not the Handheld-PC one.
FWIW, you might want to look up the CNMbook, since that actually is a CE5.NET netbook (based on a MIPS core, I think).
Interesting. I really thought Microsoft had killed the Windows-CE-based Handheld PC. I've seen devices described that way since, but they've all been NT-based. It's an ARM, BTW. Does anyone still use MIPS in handhelds?
I think we're talking at cross purposes.
Those devices have a PDA form factor, they're all using either a custom shell or something based on the Pocket PC shell. They're not using the Handheld PC shell that was used in things like the Thinkpad z50 or Jornada 720.
WinCE is designed to allow for fully custom shells.
Indeed, and this particular shell hasn't been used on a new product in about 8 years. Which is all I was sayin', eh?
I would love to see a device like the old Vadem Clio that had wifi (or even 3G GPRS) and could RDP into my home PC.
Me too, though I'd probably load something other than WinCE on it.
I did flash my iPaq with Familiar, but it just wasn't the same without a keyboard.
1. What part of "weigh their laptops before and after visiting China" did you fail to notice? Oh, right, the "before and after" part.
2. Leaving that aside, I am sure that every post office, hotel, and convention center in China has a postal scale.
They still do, the problem is it's shit and it won't run any off-the-shelf applications. It's used in a number of industrial PDAs, particularly ruggedized, intrinsically-safe ones.
Is it? I haven't seen any devices using the Handheld PC user interface since around 2001. I'm not talking about the Pocket PC fork that Windows Mobile is based on and Symbol and others use in their PDA-form-factor devices. The Handheld PC fork required a larger screen and a keyboard, and disappeared when Microsoft decided that the way to beat Palm was to copy Palm OS (of course, with 20-20 hindsight, we know they didn't have to do anything... Palm disintegrated on their own due to corporate ADHD).
How are you going to detect a 15g to 100g logging circuit that's more than likely (if there was malicious espionage intent) designed to fit or mount into current hardware and not be detected on a scale that's accurate down to 0.5 pounds.
Here's a long shot... how about using a postal scale that's accurate down to a gramme? Do you think there might be one in the mailroom?
That's like saying "Linux or even Ubuntu". :)
Microsoft used to have a laptop/netbook-friendly Windows CE version back in the late '90s, but dumped it in favor of the "Tablet PC" build of Windows NT around 2000-2001. It would be interesting to see them bring that back.
I was arguing that OpenGL was NOT the basis of Quartz from the beginning, which was your assertion
That was a secondary point. I was apparently wrong about the implementation, but the implementation details don't change the fundamental point I was trying to make: backing store, especially for subwindows, requires much more memory.
you claimed that rendering was to an offscreen texture as a result, and that there was overhead from OpenGL.
I was arguing that there was overhead due to the extra memory required for the backing store, not that there was any inherent overhead imposed by OpenGL itself. Whether rendering is implemented via OpenGL, Quickdraw, or a completely independent API and code base, there is a significant difference in the memory requirements of an implementation where virtually all applications implement the redraw using damage list and where virtually all applications use backing store.
It seems I was wrong about this backing store being implemented as an OpenGL texture, but that doesn't change the basic point: retaining a full backing store for all windows was responsible for much higher memory requirements on OS X.
Update: A bit more is revealed in a Seattle Times Q&A with Brian Seitz, Microsoft's Zune marketing manager. At the moment, the strategy is to keep all the apps and games free and developed in-house or in close collaboration with third parties -- no third-party SDK for devs to freely crank out apps just yet. Seitz is clear that games will be the primary focus of the "sometimes-connected" Zune HD and the Windows Marketplace is Microsoft's priority for handheld app development:
Man, Windows Mobile 7 and the rumored OneApp app store can't get here soon enough.
This is false; it is possible that the default was to enable Backing Store, but that is not the only behavior available to a Quartz application.
This is irrelevant; it may have been possible for Quartz applications to disable backing store, but if the majority of applications didn't (and in particular Apple's own applicatons didn't) the result is the same... IN PRACTICE you will ALWAYS have MASSIVELY higher memory requirements on OS X than on NeXTstep/OpenStep/Rhapsody. Which you did. I had to treble the RAM in my old PowerMac just install OS X.
Which, going back several messages to the original point I was making about why OS X was such a hog compared to BeOS *and* its contemporaries, IS the point.
Apple confused things terribly when they started talking about using compositing on the GPU instead of the CPU. Quartz was integrated with OpenGL from the start... even on Puma (I didn't switch early enough to see Cheetah) OpenGL and Quartz applications worked together, and multiple OpenGL applications could run concurrently, including having them overlaid by other windows, and this worked whether OpenGL was handled by software or hardware.
It's possible I'm confused about the details of the integration between OpenGL and Quartz, but in terms of the performance impact it doesn't matter: every window, from the start, was completely buffered and hidden sections of windows were always completely rendered. This applied to scrolling subwindows as well. This meant applications didn't need to deal with damage lists unless they chose to... ports of older apps like Photoshop would have retained their own rendering code, but new Cocoa applications sisn't have to handle damage events and re-render hidden portions of windows.
This is the key point: this massive increase in memory use from the Window system, and all the extra overhead of maintaining these bitmaps, was the biggest performance penalty OS X had. I used NeXTStep, OpenStep on Intel, Rhapsody DR1, and OS X from Puma on... and NeXTStep, OpenStep, and Rhapsody were all much faster, much more lightweight, much more responsive, than OS X.
And they were comparable to BeOS, and had lower memory requirements than BeOS. BeOS was impressive, but it wasn't so completely beyond its contemporaries as people keep trying to make out.
I thought the "Jupiter Shield" myth was pretty much busted.
Either a gravitational slingshot effect from Jupiter's moons, or they're defining "orbit" pretty loosely.
Quartz was not always based on OpenGL. Quartz Extreme, introduced with OS X 10.2, used hardware compositing, but prior to that it was all done in software.
The term "OpenGL" is not restricted to implementations based on a hardware video accelerator. There are pure software OpenGL implementations, like the one Apple still uses (for example, to implement T&L for the Intel GPUs on the first generations of Macbook (non-pro) and intel Mac Mini), which was used to run OpenGL-based software (like Quartz) on unaccelerated hardware.
Quartz itself is an evolution of Display PostScript.
Quartz was a complete from-scratch re-implementation, because Adobe's licensing for Display Postscript cost too much, and Apple took advantage of that to make it OpenGL-based.
Buffering of subwindows wasn't added until 10.5
Subwindows were implemented as separate textures in 10.1. You could see it happening just by opening up a scrollable window in just about any application that used Apple's rich text widgets and watching the memory use soar as the entire document was rendered into the scrolling area in the background.
If you had a 386 with 8MB you were doing pretty damn well. My first 486 only had 4MB, and my first laptop (Toshiba Libretto) came with 8MB and was eventually maxed out at 32MB.
First of all, Quartz was not always GPU-accelerated.
I have not said one word about a GPU here. Not one. Quartz was always based on OpenGL, when you didn't have a GPU (like my PowerMac 7600) it was using software OpenGL. Yes, right from the start, even on my completely unaccelerated PowerMac, and yes it was a hog right from the start because it used dedicated textures for everything.
Second of all, OSX is not a new OS, it's based on NeXTStep
Indeed. Rhapsody DR1 (which I mentioned above) was basically NeXTstep with a menu bar. It was still using Display Postscript instead of Quartz. I also had a NextStation, and it was more responsive with 16M and a 68040 than my powerMac under OS X with 112MB and a PPO 603e. Display Postscript, heavyweight as it was, was far lighter weight than Quartz.
BeOS looked like it had some actual advantages to the end user. I had a BeBox briefly and it's frankly amazing what two 66 MHz 603e chips could do with an operating system designed from the ground up for multiprocessing.
I use BeOS on my PowerMac and it naturally kicked MacOS butt (to the point where OS 8 under SheepShaver was faster than OS 8 on the raw hardware), but that's such a low hurdle to jump: the underlying operating system on pre-OSX Macs would have been considered primitive in 1969... it was nothing more than a set of common I/O libraries, no scheduling or central resource management at all... a single-tasking monitor like something from the early days of the IBM 360. The multitasking on later versions was kludged in through the window system, and programming for it was like writing a device driver... scheduling was handled by having the application call back to the OS to let other apps run "often enough".
Later I got to run it on a Wintel box and compare it head-to-head with Windows (NT4 at the time) and FreeBSD and Rhapsody DR1. It was the most resource-hungry of all four operating systems, which totally blew my mind. There was more memory contention and stalling (even for command line apps) on a PC with 16M (which sounds small now, but it was pretty high end back then).
It's not the kernel and OS design that makes OS X slow, it's the heavyweight window system. Making every window (including subwindows!) its own OpenGL texture simplifies application development somewhat, but it's a massive burden on the hardware. The API is also very MacOS/Windows like with a lot of tight cooperation required between the UI library and the display, coupling the UI to the application and creating an unnecessary bottleneck. Without that overhead it would be just as responsive as BeOS on comparable hardware.
But the most amazingly responsive OS I've used was the one shipped with the Amiga. A very lightweight and efficient kernel, a lightweight window system that ALSO avoided coupling the UI and the application (the input handler for most standard widgets ran completely asynchronously from the app, only passing completed selection and menu events down the input chain). You were impressed by what it could do on two 66 MHz CPUs? Luxury, mate. Try it with a single 7.14 MHz 68000 and tell me how fast it is.
This might be a little over the top, but pretty much all phones, except for hardcore smartphones running "outsider" software platforms like Palm and Windows Mobile (yes, it sounds odd to put Windows anything in that category, but fair's fair) are heavily restricted and locked down in one way or another. That includes the iPhone, and even Android: one of the advantages of Android over OpenMoko to the cellphone companies and carriers was that it let them maintain some of that lock-in.
So, your cellphone company and mobile provider are already pulling that kind of crap, albeit in areas you apparently don't notice or care about.
... at least until someone manages to pull a cross-zone exploit on your copy of IE8 and it starts relaying viagra ads for a botnet.
Better, put your money into having a rich text editor that works like stackoverflow's
No, please, no, those things are huge, nasty, bloated, and unnecessary.
It didn't work last time, but we know just the tweak to throw in to fix it! Honest! We're gonna get it right this time!
I have been finding it harder and harder to avoid being thrown willy-nilly into the new Slashdot beta interface. For a while I was getting half-beta half-vanilla, until I complained on another forum and it got to a slashdot developer that way.
Now I'm finding that links to articles from comment pages take you to a different URL which always shows a "rich" interface whether you have it enabled or not.
Slashdot... dump the beta, and drop the fancy user interface. You're better off without it.
Think of how often we've seen someone ask a question about how to do "this" or "that" with some linux distro and the resulting answer is very complex and requires an above-average level of computer comfort?
More often than asking the same question about Windows and you get told something starting with "edit this registry key...", I will admit.
Less often than asking the same question about Windows and you get told "You used to be able to do that, but..." or "You need to try this shareware program that edits the registry for you...", or "Why would anyone want to do that?", or "You must be a pirate/virus writer/other scum for wanting to bypass X, Y, and Z...".
I just upgraded to Vista at work, so I could use more than 4G of RAM for VMs, and I'm just about ready to hunt down an XP 64 disc and see if I can make it work... because the new "security features" (air-quoting to denote that that's an insult, not that the features actually provide any security) break software I have come to depend on, like Synergy, in unpleasant ways.
It's really scary when Linux, the epitome of Open Source instability and weird interactions, is more stable and has fewer unpleasant surprises than proprietary software.
That's because of entanglement?