Tech companies are driving unmeetable (for now) demand for new office space. As a result, lease rates are about 56% higher (last time I checked) per sq ft for offices than for Peninsula-area rental housing. You can see why financiers and developers prefer to build offices rather than housing.
It's fashionable in some circles to blame the jobs/housing imbalance on zoning restrictions, but that doesn't seem to be consistent with the ground truth. There are many millions of square feet of new development going on right now, and in many cases these are mixed-use projects with the freedom to build lots more housing, but the mix is overwhelmingly dominated by offices because of the difference in rates of return.
Construction costs are also a factor. Land is expensive and in short supply, of course, but high-rise construction is also expensive. High-rise flats are about 2.8 times as expensive as row houses for equivalent units, and therefore likely to be expensive to lease and not as likely to be profitable for the developers. They're surprisingly candid about this problem; for example, see https://www.mercurynews.com/2018/05/01/construction-costs-could-limit-where-san-jose-homes-are-built-google-adobe-diridon/ "Construction expenses have pressured developers severely enough that new market-rate apartments are profitable in no more than two districts in San Jose... Even worse, downtown San Jose — seen as a cornerstone of the city’s economy — is one of the sections where development of new housing is unlikely to produce profits for developers..."
Transportation is arguably more important than housing, but it's received little attention so far. The road network is saturated now at enough times and places that additional housing wouldn't always be viable in those places. The population distribution makes rail systems unusable in much of the Peninsula.
If the occasional Marxist analysis doesn't bother you, or if you can put it aside temporarily, chapters 5 through 7 of Richard Walker's "Pictures of a Gone City" offer a tremendous amount of useful data on the situation.
Silicon Valley arose in part because of conscious decisions to distribute strategic industries geographically. (See Margaret O'Mara's "Cities of Knowledge" for a good synopsis.) Silicon Valley is hyper-expensive, earthquake-prone, water-poor, transportation-poor, and at risk from sea-level rise. Learning from past experience and distributing some of the growth elsewhere might be a smart move.
"They only need to be prepared to change state information if the context pointer changes." How do you know when the context pointer changes? Assuming a context pointer is passed on each API call, what do you compare it to in order to detect the change? Either a thread-local copy of the previous pointer (in which case you're still using thread-local storage, and you might as well keep enough thread-local state to avoid the comparison), or an identifier maintained by the hardware (in which case you've incurred the cost of a synchronous access to the hardware state). I suppose you could be assuming that there would be a single global rendering context for the entire process (as opposed to each thread), but that's a performance loss for apps that need to render from multiple points of view (think of CAD apps rendering multiple-axis views simultaneously, or games that want to render environment and shadow maps before performing a final scene rendering).
"The same thing can happen if two different threads access the GPU without any explicit calls by the API signaling a context change. The answer is the same, don't do that." You don't have any choice. Two different (unrelated) processes can access the GPU without any explicit calls signalling a context change, and you have to be prepared to handle that. In workstation and modern general-purpose (as opposed to some gaming) systems, this is common enough to need support. There are always multiple graphics processes running, and if they're maintaining interactive performance levels, un-synchronized context switch happens all the time.
Donovan is incorrect about the original reasons for use of thread-local storage (TLS) in OpenGL. The issue was performance. If you pass a context as an argument on every call, the library (and the device drivers, and ultimately the hardware) need to be prepared to validate and potentially change unbounded amounts of state information on every call. This imposes a significant cost on every call, even in the normal case where the context doesn't change. On the other hand, making the context thread-local means that the validation and state-change cost can be handled only when needed, as the result of an explicit call to change the current context.
Keep in mind that the original design for OpenGL paid a great deal of attention to fine-grained parallelism between the CPU and the graphics pipe. (Heavy use of batching in previous systems led to poor performance, because the graphics pipe would idle while the CPU built the next batch of commands, or the CPU was blocked while the graphics pipe dealt with a batch that took longer than average to render.) This meant that calls to transfer data were frequent and needed to have very low overhead. With hardware support, as on the SGI machines of the era, this was a very effective approach.
Current systems minimize data transfer as much as possible, so the design tradeoffs are different. Whether that helps make an argument for or against TLS in Go is something I've never looked into.
For "building up" to work, you need at least (1) the infrastructure (transportation, water, power, schools, public safety, waste disposal, etc.) to support the added population; (2) the incentive to build enough supply to significantly offset demand.
In theory, you can tax the existing residents and businesses enough to create (1), but they're understandably reluctant to support that when the outcome is that the physical and financial environments they bought into will be eliminated.
In theory, you can change the zoning rules to give developers (2), but they're understandably reluctant to build large quantities of affordable housing when they can get a much better financial return by building smaller amounts of more expensive housing that are sold into high demand.
So for the time being, I think it's highly unlikely that either (1) or (2) can be achieved in San Francisco or the nearby parts of the Bay Area. Geographical redistribution of jobs, better infrastructure (particularly transportation), area-wide governmental coordination, and new financing options are all needed. "Building up" is just the answer that's clear, simple, and wrong.
There's a difference between static and dynamic content. Aliasing artifacts that are perfectly acceptable at 300DPI on a non-moving line can be pretty annoying on a moving line. The same goes for other high-frequency features in images.
The behavior of floating-point arithmetic. This wasn't covered in my university curriculum, and was necessary in tasks including graphics, machine learning, and finance once I got into the industrial world.
As a manager, possibly the single most important skill for me was learning the ways to estimate the time required for complex programming tasks. Once you're tackling problems beyond the scope of a single programmer, coordination is required, and schedule estimation is essential.
In the US, the Environmental Protection Agency has stated that concentrations of up to 100% are safe for adults. The American Academy of Pediatrics has stated that concentrations of up to 30% are safe for children. In both cases the repellent must be applied properly! Consumer Reports recommends 30% to 50% for adults, and helpfully explains that higher concentrations last longer, but don't repel any more effectively than lower concentrations.
Personally, I've used 100% DEET for a week at a time, a few times a year, over several years, without any of the documented side-effects. If someone is in one of the (relatively uncommon) situations where it's appropriate, I wouldn't hesitate to recommend trying it. Otherwise, adults can use 30% to 50% DEET and reapply as needed. My kids use 10% to 30% when necessary.
All this is subject to the usual cost/benefit tradeoffs, of course. There appears to be a lot of data showing that the risk of using DEET is low, so if West Nile or some other mosquito-borne disease is threatening, the benefit probably outweighs the risk.
... what's really important is the debt-per-capita ratio...
That's possible, but what's your compelling rationale? Without one, I could just as easily argue that the really important metric is debt/GDP, debt/median-income, debt/income distribution function, or a dozen other things.
MS was involved with OpenGL years ago as well until the OpenGL group didn't want to target 3D hardware for gaming.
That's not quite what happened.
MS was originally interested in OpenGL as a way to capture professional apps for NT. The MS groups doing OpenGL were essentially distinct from the MS groups doing gaming. The MS marketing strategy to separate "professional" and "gaming" 3D was done both to carve off a piece of the 3D market for early versions of D3D (which otherwise would have had a harder time competing) and to resolve some of the internal conflict at MS.
MS didn't make any notable contributions to the OpenGL standard that I recall, and few to OpenGL implementations on Windows. The heavy lifting was done by partners, especially SGI and the PC GPU manufacturers. In particular, fast software rendering for OpenGL on Windows as well as updating implementations beyond OpenGL 1.2 were done outside MS.
There was a major difference of opinion about the hardware to target for games. Most of the OpenGL community felt that hardware TNL support was coming much more quickly than Microsoft did, and so felt that MS was targeting hardware and developing APIs that were too far behind the technology curve. Whether this was false, or whether the weight of the MS strategy actually delayed the availability of low-priced hardware TNL, would be an interesting subject for a business-school case study.
It's worth remembering that MS bought out the technology that eventually was reworked to become the early versions of D3D. The people doing that work didn't have much experience with the type of hardware that was running OpenGL at the time, and as a result made significant errors of their own. The main difference is that MS carried enough market weight to keep the effort going despite the early failures, and lock OpenGL out of most of the gaming market. Without id, OpenGL would have had essentially no presence in Windows gaming.
...and has even been instrumental in shaping the design of GPUs in NVidia and ATI cards.
This certainly was debated by some of the GPU vendors in the old days. Now that MS has largely succeeded in commoditizing the PC graphics hardware market, I suspect it's more true. There are very few other companies left in which you can do influential work in graphics.
Adding features that make up DX10 and WDDM, all the way from unified Shaders to GPU RAM virtualization to OS level GPU pre-emption and physics/math support on GPUs through a standard API.
Most of these things were shipped in rendering software and workstation hardware long before Vista and DX10, so it's hard to give MS much credit for creating them. MS does deserve credit for integration, as usual.
None of this is intended to detract from the great deal of good graphics work being done at MS today; it's just to put the history into better perspective.
Allen
Re:Greenies have had this choice for a while.
on
Store Your Own Juice
·
· Score: 1
As you said,
my solar power system included this feature five years ago. It's great to have the option.
However, I don't use it routinely, because it drastically reduces battery life. The batteries in my system need to be replaced after about 1000 fairly deep discharge/recharge cycles. That's only three years if I time-shift power consumption every day. Otherwise, I'll get somewhere between 8 and 20 years of service from the batteries (depending on temperature, how many shallow discharge cycles occur, etc.).
I see from the Gridpoint website that their batteries are only warranted for two years.
This theory was popular 40 years ago, when I was first diagnosed with myopia. I went through an extended eye exercise regimen as well as glasses for close work, but to no avail. Eventually I started wearing glasses with the ordinary correction for myopia. My prescription remained essentially stable for 30 years (until I started wearing contact lenses, which required some tweaking).
My understanding is that in myopia the lens is simply too far away from the retina for its accommodation range to bring the image into focus. So there are two variables: the lens, and the eyeball geometry. You'd expect some cases could be solved by increasing the accommodation ability of the lens, but you'd also expect some geometries to be beyond the ability of the natural lens to handle. My wife's correction is -10 diopters, for example.
So my take is, feel free to try this approach, but be aware that it won't always work.
Yeah, I have code that does this (and I'm sure lots of other folks do, too).
The plus is that it can be used to produce fairly nice antialiased text that intermixes well with other primitives, and rendering is very fast.
The minus is that a single set of geometric primitives for a character won't work for all point sizes if you need to use hinting. (Whether this is important or not depends on your application -- especially whether you need very small text, or have so little graphics memory available that you can't store more than one set of primitives.)
The interesting challenge is to see whether hinting can be implemented with a vertex program. Some preprocessing of the outline probably would be necessary, as well as some cleverness triggering the vertex program to generate the primitives for the rasterizer. If anyone already has this working, I'd be interested in hearing about it.
The OpenGL ARB hasn't approved the 2.0 spec yet, and there are still some pretty fundamental issues to be resolved before then, so there's no way to know whether the 5200 will be able to support it.
Interesting. I see the hiccups on TNT, but not on Fox; and the hiccups are associated with artifacts that are visible (but not too objectionable) on tape.
I did have to get a powered splitter to allow my 2020 to handle some channels. Conversations with the Replay tech support guys at the time convinced me that the RF design was a little weak.
Hacking my 2020 to add an 80GB disk gave it a much-increased lifetime, but I'm wondering whether it's time for an upgrade. There are features of Tivo I like, and features of the Replay 4000 series that I like; it'll be a difficult choice.
My understanding (derived from OpenGL ARB discussions with some of the Apple engineers) is that on systems with a GPU, recent versions of OS X drive the GPU through OpenGL. OpenGL isn't exposed as the GUI rendering API; that's why I was careful in my original comment to describe it as an "implementation base."
As usual, it's amusing to see MS following the lead of others -- in this case, OS X is using a 3D API (OpenGL) as the implementation base for its GUI and other 2D graphics on the desktop today.
For me, a more interesting question is whether this move indicates the slowdown of the evolution of D3D. D3D has been free to evolve without much concern for release-to-release compatibility largely because game developers change their codebase so much more rapidly than other application developers. But if the mainstream app developers begin to use D3D, the API will gain a lot more inertia.
I was working in the compiler group at Microsoft in the early '80s, so I remember some of the historical context.
I recall suggesting to my boss (who reported to Bill back then) that Apple made a mistake by choosing 128K as the initial memory size for the Mac. My argument was that they'd need 256K to eliminate code swapping in the apps that were under development. The next-generation memory chips would make 1MB machines affordable, and I thought that would be enough for the foreseeable future. (I'm not claiming I was a visionary, either.:-))
My boss replied that the consensus opinion at Microsoft was that no one would ever buy machines with a megabyte of memory. Even if it were affordable, just consider how long it would take to clear it! An app would never really *use* that much memory on a PC; it would just be too slow.
(CPU speeds and memory speeds were not only much lower than they are today, they tended to be more closely coupled. Datapaths were much narrower. And Moore's Law wasn't widely understood outside a relatively small group of hardware-savvy folks.)
So Bill may have been fully prescient, and busy paving the way for large-memory machines. But that definitely wasn't the general belief at Microsoft around 1983. If he really did understand things as well as he says, he didn't manage to communicate it successfully even to his direct reports in engineering.
If you can't measure it, it's opinion not science. (No, I can't find who said it first -- it's not original with me.)
My recollection was that Lord Kelvin was the originator. A quick search with Google turned up this Kelvin quote (among others that are more entertaining:-))
I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of Science, whatever the matter may be.
Slashdot Mirror
Tech companies are driving unmeetable (for now) demand for new office space. As a result, lease rates are about 56% higher (last time I checked) per sq ft for offices than for Peninsula-area rental housing. You can see why financiers and developers prefer to build offices rather than housing.
It's fashionable in some circles to blame the jobs/housing imbalance on zoning restrictions, but that doesn't seem to be consistent with the ground truth. There are many millions of square feet of new development going on right now, and in many cases these are mixed-use projects with the freedom to build lots more housing, but the mix is overwhelmingly dominated by offices because of the difference in rates of return.
Construction costs are also a factor. Land is expensive and in short supply, of course, but high-rise construction is also expensive. High-rise flats are about 2.8 times as expensive as row houses for equivalent units, and therefore likely to be expensive to lease and not as likely to be profitable for the developers. They're surprisingly candid about this problem; for example, see https://www.mercurynews.com/2018/05/01/construction-costs-could-limit-where-san-jose-homes-are-built-google-adobe-diridon/ "Construction expenses have pressured developers severely enough that new market-rate apartments are profitable in no more than two districts in San Jose... Even worse, downtown San Jose — seen as a cornerstone of the city’s economy — is one of the sections where development of new housing is unlikely to produce profits for developers..."
Transportation is arguably more important than housing, but it's received little attention so far. The road network is saturated now at enough times and places that additional housing wouldn't always be viable in those places. The population distribution makes rail systems unusable in much of the Peninsula.
If the occasional Marxist analysis doesn't bother you, or if you can put it aside temporarily, chapters 5 through 7 of Richard Walker's "Pictures of a Gone City" offer a tremendous amount of useful data on the situation.
Silicon Valley arose in part because of conscious decisions to distribute strategic industries geographically. (See Margaret O'Mara's "Cities of Knowledge" for a good synopsis.) Silicon Valley is hyper-expensive, earthquake-prone, water-poor, transportation-poor, and at risk from sea-level rise. Learning from past experience and distributing some of the growth elsewhere might be a smart move.
With a TV Typewriter II. 4KB SRAM. Audio tape storage. MIKBUG monitor.
Gradually upgraded to a 6809 with 16KB DRAM. Multitasking OS implemented in a homebrew Algol-68-based programming language.
Still have the thing in a box in the basement.
"They only need to be prepared to change state information if the context pointer changes." How do you know when the context pointer changes? Assuming a context pointer is passed on each API call, what do you compare it to in order to detect the change? Either a thread-local copy of the previous pointer (in which case you're still using thread-local storage, and you might as well keep enough thread-local state to avoid the comparison), or an identifier maintained by the hardware (in which case you've incurred the cost of a synchronous access to the hardware state). I suppose you could be assuming that there would be a single global rendering context for the entire process (as opposed to each thread), but that's a performance loss for apps that need to render from multiple points of view (think of CAD apps rendering multiple-axis views simultaneously, or games that want to render environment and shadow maps before performing a final scene rendering).
"The same thing can happen if two different threads access the GPU without any explicit calls by the API signaling a context change. The answer is the same, don't do that." You don't have any choice. Two different (unrelated) processes can access the GPU without any explicit calls signalling a context change, and you have to be prepared to handle that. In workstation and modern general-purpose (as opposed to some gaming) systems, this is common enough to need support. There are always multiple graphics processes running, and if they're maintaining interactive performance levels, un-synchronized context switch happens all the time.
Donovan is incorrect about the original reasons for use of thread-local storage (TLS) in OpenGL. The issue was performance. If you pass a context as an argument on every call, the library (and the device drivers, and ultimately the hardware) need to be prepared to validate and potentially change unbounded amounts of state information on every call. This imposes a significant cost on every call, even in the normal case where the context doesn't change. On the other hand, making the context thread-local means that the validation and state-change cost can be handled only when needed, as the result of an explicit call to change the current context.
Keep in mind that the original design for OpenGL paid a great deal of attention to fine-grained parallelism between the CPU and the graphics pipe. (Heavy use of batching in previous systems led to poor performance, because the graphics pipe would idle while the CPU built the next batch of commands, or the CPU was blocked while the graphics pipe dealt with a batch that took longer than average to render.) This meant that calls to transfer data were frequent and needed to have very low overhead. With hardware support, as on the SGI machines of the era, this was a very effective approach.
Current systems minimize data transfer as much as possible, so the design tradeoffs are different. Whether that helps make an argument for or against TLS in Go is something I've never looked into.
For "building up" to work, you need at least (1) the infrastructure (transportation, water, power, schools, public safety, waste disposal, etc.) to support the added population; (2) the incentive to build enough supply to significantly offset demand.
In theory, you can tax the existing residents and businesses enough to create (1), but they're understandably reluctant to support that when the outcome is that the physical and financial environments they bought into will be eliminated.
In theory, you can change the zoning rules to give developers (2), but they're understandably reluctant to build large quantities of affordable housing when they can get a much better financial return by building smaller amounts of more expensive housing that are sold into high demand.
So for the time being, I think it's highly unlikely that either (1) or (2) can be achieved in San Francisco or the nearby parts of the Bay Area. Geographical redistribution of jobs, better infrastructure (particularly transportation), area-wide governmental coordination, and new financing options are all needed. "Building up" is just the answer that's clear, simple, and wrong.
UGrokIt (ugrokit.com) just started shipping such a thing. (Disclosure: I have worked with UGrokIt.)
There's a difference between static and dynamic content. Aliasing artifacts that are perfectly acceptable at 300DPI on a non-moving line can be pretty annoying on a moving line. The same goes for other high-frequency features in images.
The behavior of floating-point arithmetic. This wasn't covered in my university curriculum, and was necessary in tasks including graphics, machine learning, and finance once I got into the industrial world.
As a manager, possibly the single most important skill for me was learning the ways to estimate the time required for complex programming tasks. Once you're tackling problems beyond the scope of a single programmer, coordination is required, and schedule estimation is essential.
In the US, the Environmental Protection Agency has stated that concentrations of up to 100% are safe for adults. The American Academy of Pediatrics has stated that concentrations of up to 30% are safe for children. In both cases the repellent must be applied properly! Consumer Reports recommends 30% to 50% for adults, and helpfully explains that higher concentrations last longer, but don't repel any more effectively than lower concentrations.
Personally, I've used 100% DEET for a week at a time, a few times a year, over several years, without any of the documented side-effects. If someone is in one of the (relatively uncommon) situations where it's appropriate, I wouldn't hesitate to recommend trying it. Otherwise, adults can use 30% to 50% DEET and reapply as needed. My kids use 10% to 30% when necessary.
All this is subject to the usual cost/benefit tradeoffs, of course. There appears to be a lot of data showing that the risk of using DEET is low, so if West Nile or some other mosquito-borne disease is threatening, the benefit probably outweighs the risk.
Allen
Try reading Vitals by Greg Bear.
... what's really important is the debt-per-capita ratio...
That's possible, but what's your compelling rationale? Without one, I could just as easily argue that the really important metric is debt/GDP, debt/median-income, debt/income distribution function, or a dozen other things.
Allen
That's not quite what happened.
MS was originally interested in OpenGL as a way to capture professional apps for NT. The MS groups doing OpenGL were essentially distinct from the MS groups doing gaming. The MS marketing strategy to separate "professional" and "gaming" 3D was done both to carve off a piece of the 3D market for early versions of D3D (which otherwise would have had a harder time competing) and to resolve some of the internal conflict at MS.
MS didn't make any notable contributions to the OpenGL standard that I recall, and few to OpenGL implementations on Windows. The heavy lifting was done by partners, especially SGI and the PC GPU manufacturers. In particular, fast software rendering for OpenGL on Windows as well as updating implementations beyond OpenGL 1.2 were done outside MS.
There was a major difference of opinion about the hardware to target for games. Most of the OpenGL community felt that hardware TNL support was coming much more quickly than Microsoft did, and so felt that MS was targeting hardware and developing APIs that were too far behind the technology curve. Whether this was false, or whether the weight of the MS strategy actually delayed the availability of low-priced hardware TNL, would be an interesting subject for a business-school case study.
It's worth remembering that MS bought out the technology that eventually was reworked to become the early versions of D3D. The people doing that work didn't have much experience with the type of hardware that was running OpenGL at the time, and as a result made significant errors of their own. The main difference is that MS carried enough market weight to keep the effort going despite the early failures, and lock OpenGL out of most of the gaming market. Without id, OpenGL would have had essentially no presence in Windows gaming.
This certainly was debated by some of the GPU vendors in the old days. Now that MS has largely succeeded in commoditizing the PC graphics hardware market, I suspect it's more true. There are very few other companies left in which you can do influential work in graphics.
Most of these things were shipped in rendering software and workstation hardware long before Vista and DX10, so it's hard to give MS much credit for creating them. MS does deserve credit for integration, as usual.
None of this is intended to detract from the great deal of good graphics work being done at MS today; it's just to put the history into better perspective.
AllenHowever, I don't use it routinely, because it drastically reduces battery life. The batteries in my system need to be replaced after about 1000 fairly deep discharge/recharge cycles. That's only three years if I time-shift power consumption every day. Otherwise, I'll get somewhere between 8 and 20 years of service from the batteries (depending on temperature, how many shallow discharge cycles occur, etc.).
I see from the Gridpoint website that their batteries are only warranted for two years.
Allen
This theory was popular 40 years ago, when I was first diagnosed with myopia. I went through an extended eye exercise regimen as well as glasses for close work, but to no avail. Eventually I started wearing glasses with the ordinary correction for myopia. My prescription remained essentially stable for 30 years (until I started wearing contact lenses, which required some tweaking).
My understanding is that in myopia the lens is simply too far away from the retina for its accommodation range to bring the image into focus. So there are two variables: the lens, and the eyeball geometry. You'd expect some cases could be solved by increasing the accommodation ability of the lens, but you'd also expect some geometries to be beyond the ability of the natural lens to handle. My wife's correction is -10 diopters, for example.
So my take is, feel free to try this approach, but be aware that it won't always work.
We've just lost the entire thirteenth century. Still, nothing much there apart from Dante and a few corrupt popes.
Yeah, I have code that does this (and I'm sure lots of other folks do, too).
The plus is that it can be used to produce fairly nice antialiased text that intermixes well with other primitives, and rendering is very fast.
The minus is that a single set of geometric primitives for a character won't work for all point sizes if you need to use hinting. (Whether this is important or not depends on your application -- especially whether you need very small text, or have so little graphics memory available that you can't store more than one set of primitives.)
The interesting challenge is to see whether hinting can be implemented with a vertex program. Some preprocessing of the outline probably would be necessary, as well as some cleverness triggering the vertex program to generate the primitives for the rasterizer. If anyone already has this working, I'd be interested in hearing about it.
Allen
The OpenGL ARB hasn't approved the 2.0 spec yet, and there are still some pretty fundamental issues to be resolved before then, so there's no way to know whether the 5200 will be able to support it.
You may remember that networks of small sensors figured prominently in The Peace War, also by Vernor Vinge.
Hmm, I sense a pattern here.
Check out Roger Clark's analysis for the details.
Interesting. I see the hiccups on TNT, but not on Fox; and the hiccups are associated with artifacts that are visible (but not too objectionable) on tape.
I did have to get a powered splitter to allow my 2020 to handle some channels. Conversations with the Replay tech support guys at the time convinced me that the RF design was a little weak.
Hacking my 2020 to add an 80GB disk gave it a much-increased lifetime, but I'm wondering whether it's time for an upgrade. There are features of Tivo I like, and features of the Replay 4000 series that I like; it'll be a difficult choice.
Allen
My understanding (derived from OpenGL ARB discussions with some of the Apple engineers) is that on systems with a GPU, recent versions of OS X drive the GPU through OpenGL. OpenGL isn't exposed as the GUI rendering API; that's why I was careful in my original comment to describe it as an "implementation base."
As usual, it's amusing to see MS following the lead of others -- in this case, OS X is using a 3D API (OpenGL) as the implementation base for its GUI and other 2D graphics on the desktop today.
For me, a more interesting question is whether this move indicates the slowdown of the evolution of D3D. D3D has been free to evolve without much concern for release-to-release compatibility largely because game developers change their codebase so much more rapidly than other application developers. But if the mainstream app developers begin to use D3D, the API will gain a lot more inertia.
You haven't worked for Bill, have you?
I was working in the compiler group at Microsoft in the early '80s, so I remember some of the historical context.
:-))
I recall suggesting to my boss (who reported to Bill back then) that Apple made a mistake by choosing 128K as the initial memory size for the Mac. My argument was that they'd need 256K to eliminate code swapping in the apps that were under development. The next-generation memory chips would make 1MB machines affordable, and I thought that would be enough for the foreseeable future. (I'm not claiming I was a visionary, either.
My boss replied that the consensus opinion at Microsoft was that no one would ever buy machines with a megabyte of memory. Even if it were affordable, just consider how long it would take to clear it! An app would never really *use* that much memory on a PC; it would just be too slow.
(CPU speeds and memory speeds were not only much lower than they are today, they tended to be more closely coupled. Datapaths were much narrower. And Moore's Law wasn't widely understood outside a relatively small group of hardware-savvy folks.)
So Bill may have been fully prescient, and busy paving the way for large-memory machines. But that definitely wasn't the general belief at Microsoft around 1983. If he really did understand things as well as he says, he didn't manage to communicate it successfully even to his direct reports in engineering.