So let's review... Running Windows 2000 on a machine from 2003, and it runs well? Sounds about right. How well does it run on a machine from 2000? 1997?
Actually, considering there's huge deployments of BSD out there (Yahoo, for instance), and BSD doesn't show up on the Open Group's UNIX Certification page or as a separate item in TFA, I imagine the division is simply:
UNIX® or UNIX®-like and not Linux? Put it under UNIX®
Well, yes and no... Various Linux distros have angled for POSIX certification and certification against the Single UNIX Specification, and so on, and I believe some have actually made it, though I don't see anything over at the Open Group's site.
Barring a huge merge between Linux and a "real UNIX," Linux will never be a "real UNIX" based on source code descendency. But, Linux may be considered a "real UNIX" at points due to SUS certification of particular distro releases that care enough to bother.
And, as far as BSD is concerned, while it may have removed certain proprietary AT&T code as part of the lawsuit, enough code and structure crossed both ways between BSD and AT&T that it'd be silly to argue that BSD is not "real UNIX." That said, it appears none of the BSDs have registered for UNIX certification.
How many servers do the $17.5b (UNIX) and $5.3b (Linux) numbers represent? Linux tends to run on much cheaper hardware than UNIX traditionally does.
How much new server capacity is associated with UNIX and Linux? With Linux boxes being as cheap as they are, do we see more per-task servers than we might in the UNIX world?
It could be that surveys such as this just highlight the higher sunk-cost upfront for a non-Linux solution, rather than actual market share. In terms of market share, I am more interested in newly deployed server capacity than in how many dollars were spent doing it. The dollar amounts are interesting mainly for comparing relative costs for purchasing different platforms.
In terms of this particular data point, if we assume Linux primarily cannibalized UNIX market share, simply adding the numbers puts UNIX $5b ahead of Windows. BUT, suppose we assume moving that server capacity back to UNIX triples the cost (a conservative estimate). In terms of dollars, that puts the UNIX market share at nearly double Windows'. See how worthless the $ numbers can be?
No, you've been using the Internet too long. When I first set up my Linux box, I didn't have a net connection for it much of the time, and yet I still had plenty of reasons to use it.
Of course, that was 1993, and I was spending most of my time coding stupid little hacks that I look back on and think to myself "I wrote *that* ugly piece of crap? Well... it was kinda cool, but man!" But, then, that's the sort of experience your kids should be having.
If everything still worked properly, I'd give my kids some older tech to play on. You know, computers that boot instantly and have a programming language built in. Because today's computers *can* do so much, they insist on doing quite a lot of it all the time for no good reason. That's too much distraction for focusing on the task at hand I'd say.
For the record, I don't currently have kids and I'm still on the fence. But, I have a niece (23 months old) and nephew (6 months old), so if nothing else, Uncle Joe will have neat toys for them.:-)
Bad News dude, I run XP with the 'Classic' look and its still a dog.
I think you miss the point. Vista's new default theme requires a rather stout CPU + GPU combo to operate well. Its "Classic" theme is probably one of WinXP's themes. (I wouldn't be surprised if they offered both WinXP default themes.)
I don't think anyone was claiming that WinXP's "classic" theme was supposed to be much faster than its default "Windowx Xbox Wannabe" theme.
A couple minor, minor corrrections. First off, so called "single-pulse PWM" digital LCoS displays running at 120Hz actually pulse the mirrors only 240 times a second. (One pulse to switch to "reflect", one pulse to switch to "absorb", repeated 120 times a second gives 240 pulses.) Older PWM schemes would pulse the mirrors multiple times per refresh, sending out each bit plane one at a time.
Second, "reflect" and "absorb" aren't quite exactly what's going on. The material underlying the crystal is inherently reflective. Liquid crystal works by rotating the light that passes through it, based on how "twisted" the crystal is. An electric field applies force to the crystal to twist it. Pass in polarized light, and you can rotate the light's polarization with the liquid crystal. So basically, the way you switch between "reflect" and "absorb" is by varying the electrostatic charge that exerts force on a given pixel's crystal. You can get states between "reflect" and "absorb" by applying varying amounts of charge. The amount of light transmitted through a polarizer is given roughly by k * cos(theta) where theta is the difference angle between the planes of polarization. It's a tricky proposition, though, since the material itself has all sorts of fun properties, such as hysteresis and whatnot. Plus, in the case of LCoS, the light passes through the crystal twice (in contrast to transmissive LCD), so you're operating over a much narrower range of crystal twist to begin with.
This article has some pretty pictures, as long as you ignore the "Silicone" typo.:-)
I wonder how these LCoS screens look if you have polarizing sun glasses on. Also, does it make a difference if you tilt your head? A fun experiment to try: Put on polarizing glasses, and then look at an LCD display. Now tilt your head 90 degrees. Notice any differences?
This was one detail GM missed when they developed the head-up display for their cars. Because the light reflects off of the tilted windshield, it picks up some horizontal polarization. Polarized sun glassesd have vertical polarization, because most glare has horizontal polarization after reflecting off of a flat surface. Thus, the head-up display information almost completely disappears when I have polarized glasses on. *doh*
Liquid Crystal on Silicon. It's a reflective (as opposedt to transmissive) LCD technology. You basically get all these liquid crystal mirrors to play with, where the rest of the logic on the silicon switches the mirrors rapidly between "reflect" and "absorb" thousands of times a second. (Similar to how DLP works, but instead of actual mirrors rocking back and forth, it's just LCD switching on and off, playing with light polarization.)
The TI-99/4A was the first computer I owned (got it for my 8th birthday, just as TI was pulling out of the market), but not the first I programmed. I had programmed many a PET, VIC-20 and Commodore 64 before that. The TI *was* the first machine I programmed assembly code on, using the Mini-Memory cart. Fun times!
Hmm.... Most flash I've seen is rated for 10,000 - 1,000,000 rewrites per sector (NOR flash). Newer flash (NAND flash) tends towards higher rewrite counts--about 10x what NOR flash offers.
So, let's say you erase/reprogram the entire thing every day, and that that constitutes 2 rewrites. (One for the erase and one for the write, although that's unlikely to be the case.) If the flash is good for 10,000 rewrites, that still gives you 13 years worth of daily updates. Chances are, though, all the flash-based iPods use NAND flash, in which case you're good for 130 years of daily updates.
Granted, the filesystem control structures get written more often than the file store, so perhaps 130 years overstates it somewhat. Still, flash-oriented file systems do try to "level out" the writes that happen to the filesystem's control structures, based on the premise that reads are cheap and seeks are free. Thus, I imagine the unit itself (or its owner) wears out before its flash does.
This page on that site goes on and on about Quirks Mode, Almost Strict Mode (a unique-to-Mozilla beast), and Strict Mode. This page goes further and delineates how different browsers pick among those three modes.
If you always code Strict and never have to support a quirks-only browser, then lucky you!
Personally, there's a reason I never became a web developer and I keep my HTML simple.:-)
The problem is that we're using increasing chip complexity to leverage Moore's Law (which only governs rate of increase of number of transistors) into corresponding increases in performance.
So, while going from a 32-bit architecture to a 64-bit architecture mostly involves making the units wider (which isn't entirely true, but keep your pants on), that's not the primary source of complexity leading to errors. Deeper pipelines mean more transactions in flight, more register renaming, more state to track, more intermediate states for the chip to be in when something goes wrong.
Notice that nearly all of these bugs have something to do with exception processing, context switching or some abuse of the virtual memory system. These are corner cases that arise from all the complex scheduling, tracking and virtualization that allow these chips to keep instructions moving despite cache stalls, dependencies, etc.
If the bugs had been like the Pentium divide bug, that's one thing. You actually stand a very, very good chance of building a family of test cases that cover all the seed entries in the divide seed ROM. But in these bugs, for some of them you could have upwards of 100 instructions in flight in arbitrary mixes and various stages of completion, and one of them faults and the chip does the wrong thing. (And it's not even clear whether it's as show-stopper as the linked site says.)
Each of the different stages of computation are unique--it's not like all 20-odd stages of the CPU's pipeline are identical, and many stages can hold multiple instructions each with its own unique dependences--and so your argument doesn't hold. The search space for this type of verification problem virtually guarantees that some corner cases will slip by. Fixing one of these bugs runs the gigantic risk that it opens up many others.
If we were just making SSE-style vector instructions get longer and longer and longer vectors, your argument holds. We're not. We're adding scheduling and tracking and all sorts of stuff that could put the most serpentine government bureaucracy to shame.:-)
If you look at the bug list, just about all of these are weird corner cases involving exceptions, double-exceptions and so on. The search space here is practically infinite. You'll also notice that the vast majority involve bizarre uses of the hardware, and have so far only been observed by Intel.
Slashdot Mirror
So let's review... Running Windows 2000 on a machine from 2003, and it runs well? Sounds about right. How well does it run on a machine from 2000? 1997?
Actually, considering there's huge deployments of BSD out there (Yahoo, for instance), and BSD doesn't show up on the Open Group's UNIX Certification page or as a separate item in TFA, I imagine the division is simply:
That's my guess, at least.
--JoeWell, yes and no... Various Linux distros have angled for POSIX certification and certification against the Single UNIX Specification, and so on, and I believe some have actually made it, though I don't see anything over at the Open Group's site.
Barring a huge merge between Linux and a "real UNIX," Linux will never be a "real UNIX" based on source code descendency. But, Linux may be considered a "real UNIX" at points due to SUS certification of particular distro releases that care enough to bother.
And, as far as BSD is concerned, while it may have removed certain proprietary AT&T code as part of the lawsuit, enough code and structure crossed both ways between BSD and AT&T that it'd be silly to argue that BSD is not "real UNIX." That said, it appears none of the BSDs have registered for UNIX certification.
--JoeI wonder about two things from the numbers:
It could be that surveys such as this just highlight the higher sunk-cost upfront for a non-Linux solution, rather than actual market share. In terms of market share, I am more interested in newly deployed server capacity than in how many dollars were spent doing it. The dollar amounts are interesting mainly for comparing relative costs for purchasing different platforms.
In terms of this particular data point, if we assume Linux primarily cannibalized UNIX market share, simply adding the numbers puts UNIX $5b ahead of Windows. BUT, suppose we assume moving that server capacity back to UNIX triples the cost (a conservative estimate). In terms of dollars, that puts the UNIX market share at nearly double Windows'. See how worthless the $ numbers can be?
--JoeNo, you've been using the Internet too long. When I first set up my Linux box, I didn't have a net connection for it much of the time, and yet I still had plenty of reasons to use it.
Of course, that was 1993, and I was spending most of my time coding stupid little hacks that I look back on and think to myself "I wrote *that* ugly piece of crap? Well... it was kinda cool, but man!" But, then, that's the sort of experience your kids should be having.
If everything still worked properly, I'd give my kids some older tech to play on. You know, computers that boot instantly and have a programming language built in. Because today's computers *can* do so much, they insist on doing quite a lot of it all the time for no good reason. That's too much distraction for focusing on the task at hand I'd say.
For the record, I don't currently have kids and I'm still on the fence. But, I have a niece (23 months old) and nephew (6 months old), so if nothing else, Uncle Joe will have neat toys for them. :-)
--Joe
I think you miss the point. Vista's new default theme requires a rather stout CPU + GPU combo to operate well. Its "Classic" theme is probably one of WinXP's themes. (I wouldn't be surprised if they offered both WinXP default themes.)
I don't think anyone was claiming that WinXP's "classic" theme was supposed to be much faster than its default "Windowx Xbox Wannabe" theme.
--Joe
It's the next version of Windows.
A couple minor, minor corrrections. First off, so called "single-pulse PWM" digital LCoS displays running at 120Hz actually pulse the mirrors only 240 times a second. (One pulse to switch to "reflect", one pulse to switch to "absorb", repeated 120 times a second gives 240 pulses.) Older PWM schemes would pulse the mirrors multiple times per refresh, sending out each bit plane one at a time.
Second, "reflect" and "absorb" aren't quite exactly what's going on. The material underlying the crystal is inherently reflective. Liquid crystal works by rotating the light that passes through it, based on how "twisted" the crystal is. An electric field applies force to the crystal to twist it. Pass in polarized light, and you can rotate the light's polarization with the liquid crystal. So basically, the way you switch between "reflect" and "absorb" is by varying the electrostatic charge that exerts force on a given pixel's crystal. You can get states between "reflect" and "absorb" by applying varying amounts of charge. The amount of light transmitted through a polarizer is given roughly by k * cos(theta) where theta is the difference angle between the planes of polarization. It's a tricky proposition, though, since the material itself has all sorts of fun properties, such as hysteresis and whatnot. Plus, in the case of LCoS, the light passes through the crystal twice (in contrast to transmissive LCD), so you're operating over a much narrower range of crystal twist to begin with.
This article has some pretty pictures, as long as you ignore the "Silicone" typo. :-)
I wonder how these LCoS screens look if you have polarizing sun glasses on. Also, does it make a difference if you tilt your head? A fun experiment to try: Put on polarizing glasses, and then look at an LCD display. Now tilt your head 90 degrees. Notice any differences?
This was one detail GM missed when they developed the head-up display for their cars. Because the light reflects off of the tilted windshield, it picks up some horizontal polarization. Polarized sun glassesd have vertical polarization, because most glare has horizontal polarization after reflecting off of a flat surface. Thus, the head-up display information almost completely disappears when I have polarized glasses on. *doh*
--JoeLiquid Crystal on Silicon. It's a reflective (as opposedt to transmissive) LCD technology. You basically get all these liquid crystal mirrors to play with, where the rest of the logic on the silicon switches the mirrors rapidly between "reflect" and "absorb" thousands of times a second. (Similar to how DLP works, but instead of actual mirrors rocking back and forth, it's just LCD switching on and off, playing with light polarization.)
Yes. ;-)
LOAD? LOAD? Hardly! Try OLD "CS1:".
And, to send you back to the good old days, check out this track laid down over Pirate Adventure.
The TI-99/4A was the first computer I owned (got it for my 8th birthday, just as TI was pulling out of the market), but not the first I programmed. I had programmed many a PET, VIC-20 and Commodore 64 before that. The TI *was* the first machine I programmed assembly code on, using the Mini-Memory cart. Fun times!
--Joe
Heck, I travel forward in time for free. So far I seem to be averaging around 60 minutes and hour... a pretty respectible clip!
Uhm, they make special flash-aware filesystems that prevent exactly that. And, with modern NAND flash, you get oodles and oodles of rewrites anyway.
Hmm.... Most flash I've seen is rated for 10,000 - 1,000,000 rewrites per sector (NOR flash). Newer flash (NAND flash) tends towards higher rewrite counts--about 10x what NOR flash offers.
So, let's say you erase/reprogram the entire thing every day, and that that constitutes 2 rewrites. (One for the erase and one for the write, although that's unlikely to be the case.) If the flash is good for 10,000 rewrites, that still gives you 13 years worth of daily updates. Chances are, though, all the flash-based iPods use NAND flash, in which case you're good for 130 years of daily updates.
Granted, the filesystem control structures get written more often than the file store, so perhaps 130 years overstates it somewhat. Still, flash-oriented file systems do try to "level out" the writes that happen to the filesystem's control structures, based on the premise that reads are cheap and seeks are free. Thus, I imagine the unit itself (or its owner) wears out before its flash does.
--Joe
Add one tiny little word and it maybe works:
After all, this is Slashdot...
--Joe
This page on that site goes on and on about Quirks Mode, Almost Strict Mode (a unique-to-Mozilla beast), and Strict Mode. This page goes further and delineates how different browsers pick among those three modes.
:-)
If you always code Strict and never have to support a quirks-only browser, then lucky you!
Personally, there's a reason I never became a web developer and I keep my HTML simple.
Where you see "Mozilla," think "Mozilla Firefox," as they're based around the same rendering core (Gecko) and exhibit rather similar behavior.
Well, we're Intrepid posters, with an Eagle eye for bad puns, in Concorde-ance with Slashdot's humor norms. :-)
The problem is that we're using increasing chip complexity to leverage Moore's Law (which only governs rate of increase of number of transistors) into corresponding increases in performance.
:-)
So, while going from a 32-bit architecture to a 64-bit architecture mostly involves making the units wider (which isn't entirely true, but keep your pants on), that's not the primary source of complexity leading to errors. Deeper pipelines mean more transactions in flight, more register renaming, more state to track, more intermediate states for the chip to be in when something goes wrong.
Notice that nearly all of these bugs have something to do with exception processing, context switching or some abuse of the virtual memory system. These are corner cases that arise from all the complex scheduling, tracking and virtualization that allow these chips to keep instructions moving despite cache stalls, dependencies, etc.
If the bugs had been like the Pentium divide bug, that's one thing. You actually stand a very, very good chance of building a family of test cases that cover all the seed entries in the divide seed ROM. But in these bugs, for some of them you could have upwards of 100 instructions in flight in arbitrary mixes and various stages of completion, and one of them faults and the chip does the wrong thing. (And it's not even clear whether it's as show-stopper as the linked site says.)
Each of the different stages of computation are unique--it's not like all 20-odd stages of the CPU's pipeline are identical, and many stages can hold multiple instructions each with its own unique dependences--and so your argument doesn't hold. The search space for this type of verification problem virtually guarantees that some corner cases will slip by. Fixing one of these bugs runs the gigantic risk that it opens up many others.
If we were just making SSE-style vector instructions get longer and longer and longer vectors, your argument holds. We're not. We're adding scheduling and tracking and all sorts of stuff that could put the most serpentine government bureaucracy to shame.
--Joe
If you look at the bug list, just about all of these are weird corner cases involving exceptions, double-exceptions and so on. The search space here is practically infinite. You'll also notice that the vast majority involve bizarre uses of the hardware, and have so far only been observed by Intel.
Shhh... He's trying to look smart to the people who didn't read the article. :-)
Oh Chrysler, that was a bad pun.
OS X users too.
Not only is ZEN a prime number in base-36, but so is DOH.
How about an airplane? I see plenty of laptops open on airplanes.