I don't agree. I couldn't care less about sending spam. The thing that bothers me is receiving it. If I can reliably ensure that I receive no spam (but receive any and all ham) then the problem is solved.
And as far as I can tell, the only way to stop it being sent is to stop it being lucrative. And the only viable mechanism to achieve that is to stop people from receiving it.
"So once that function was ported over from the 95 family to the NT4 family"
That almost certainly never happened.
The function was written once for Windows 3.x. 16-bit, probably asm, probably almost identical to the Win9x code. Somewhere down the line the Win9x GDI team made some change that mitigated this issue (by not processing SetAbortProc in certain situations). I'm not sure if that means 9x is completely unexploitable (I don't know what happens if a WMF is printed, for example), but it means that merely viewing an WMF can't cause code execution.
The function was written once for NT 3.1. 32-bit, C, probably almost identical to the XP/2003 code, independent of the Windows 3.x code. Same purpose, but different code. And because it's different and independent, the change made to 9x was never propagated.
I haven't seen any evidence thus far that a change was introduced in 2000/XP. So far, everything suggests that it's always been in the NT 3.1 line.
What "saved" windows 9x is that it was a completely different code-base from NT (derived from Win3.x); it was likely altered independently by the 9x product team. But because of the separate code-bases there was no cross-pollination of this change to the NT line. Presumably the recent patch implements an equivalent fix (so that SetAbortProc is only handled when actually printing). Or perhaps it removes the functionality altogether, as even when printing, the behaviour seems risky.
It may well be that this "defer until the next record is read" behaviour exists in 9x (even if when actually printing) and Win3.x too.
Rather, the issue that arose in XP and 2003 is that they bundled a COM control that could handle WMF files, and which assumed them to be trustworthy.
IE was deliberately neutered because in IE it's obvious that any WMF file/isn't/ trustworthy. But in the Fax Viewer thingy, such an assumption can't be made. The WMF files it views could come from anywhere; some sources friendly, others hostile. So it is not altogether surprising that it did not have an equivalent change made to it.
Probably because it was never there to remove. Windows 2000/XP/2003 are not derivatives of Windows 9x, so the 9x code change was never visible; different source tree, different developers, different managers.
Now, you might ask why they didn't/port/ the change to the NT family. I would not be surprised to find that whoever was responsible for the 9x change just never thought about it; the products were developed quite independently, because they were completely separate. It's one of the many reasons MS wanted to move to a single code-base....
It is not a trivial programming task to spawn a new thread and then start that threads execution at the byte following a single invalid wmf record descriptor
Yeah, it's real hard alright.
void parseWMFrecord(char* record)// or however else the parser looks like. Who careS? The "backdoor" author doesn't have to do it { switch(recordDescriptor) { case SET_ABORT: if(record[0] == 1) { VirtualProtect(payload, blah blah, PAGE_EXECUTE_READ, blah blah); CreateThread(blah blah, (ThreadProc)(record + 1), blah blah) } } }
Given that if MS don't do this kind of thing they will inevitably face a complete ban (forcing the use of proxy servers and so on), one can hardly fault them for doing so. A complete ban doesn't serve those other users of MSN Spaces, after all. It would have the effect of blocking every blogger on the site no matter what they said, which is surely worse than blocking just one.
Go look at how Apple stores and searches METADATA and the DATA (when it's accessable). When you save a PDF, JPG, MP3 or whatever OS-X extracts the metadata, stores it and indexes it.
Oooh, just like Windows has been doing since the NT 4 Option Pack. How exciting!
MS is trying desparately to implement the same thing.
MS has been there and done that, and did it many years before Apple.
Xen is not virtualization technology. It's paravirtualization. Not the same thing and quite innovative.
It is the same thing. And it isn't "innovative". IBM have been doing it for years.
There is a profound difference between a UDF (which even mysql has) and a user defined aggregate functions and operators.
No there isn't.
It's wonderful to make your own data types and write the operators to make comparisons and define functions like max and min for them.
It may be syntactically convenient. But it is not offering any capability that functions do not.
Just to give you one example you can then run a query like select point from points where point is fartest away from circle. Postgres allows you to code your stored procs in TCL, PL-SQL, PERL, Python and Java due it's flexable architecture. If you are happy with the lame T-SQL then more power to ya.
But I don't have to use T-SQL to write sprocs in SQL Server. You do understand that, right?
Yes, that's why MS is working like a dog on winfs to try and copy of the features of reiser3.
They're not working "like a dog". They've put it on the back burner.
Ok I should have said it makes ASP.NET look like yesterdays turd. Apparently I am talking to a nitpicker here.
ASP and ASP.NET have next to nothing in common, and Ruby on Rails doesn't even begin to make ASP.NET look like "yesterdays turd".
Can be? How come they haven't yet then?
Er... they have.
Aah yes the typical MS FUD. If we don't support it it's beause it sucks and will give you cooties.
What the hell are you talking about? There is no single way to resolve multiple dispatch ambiguities; CLOS and Dylan, for example, both use different and incompatible schemes. Neither is clearly better than the other. And this is a big problem with multiple dispatch. Single dispatch has behaviour that's obviously and intuitively correct. Multiple dispatch doesn't. MI has issues of its own, but the solutions are better understood and (I believe) statically detectable.
But, of course, you just spout typical ABM FUD. If MS doesn't do something it must be great. Doesn't matter what people's objections to it are, if MS doesn't have it it's the best thing since sliced bread, and anyone who says otherwise is spewing FUD.
edit.com is a DOS (16-bit) program. Prior to invoking such programs the shell effectively does a chdir to the SFN so that the DOS program doesn't shit a brick (because, like you say, it inherits its environment from its parent; it needs to inherit an environment that won't confuse it). Sure, they could make it so that the chdir didn't occur in cmd itself but instead in some intermediate level, but what would be the benefit of the extra complexity? There's no good reason to use DOS programs, so why spend any time on this?
And, no, they couldn't make the DOS programs LFN aware, because if they did they wouldn't be DOS programs any more. And the SFNs are not because the FS has different ideas of what's legal and what's not (NTFS doesn't need SFNs, after all), it's because there's software that needs SFNs. A dual naming hack is essential to resolve this problem.
If meta-data isn't worth a damn, why are Microsoft investing so much effort in WinFS?
It's not even obvious that they are. It's not going to be a part of Longhorn, and no-one really knows when it'll emerge. I would wager that this is in no small part due to the relative lack of metadata--designing an FS that can store and metadata efficiently is only a small part of the problem (one that's arguably already solved, as many FSes allow that kind of extensibility, such as HFS+, NTFS, and of course reiser). The problem is making it usable and useful.
People don't want to have to tag all their documents and data files with extra out-of-band information. The only files which routinely have useful, accurate metadata are things like MP3s--and they don't need WinFS (or reiser, or anything else) to store their metadata as they prepend (ID3v2) or append (ID3v1) the information to the data itself. At a pinch digital pictures might get some useful metadata, but again, it's already in EXIF tags. But beyond that? It's far from clear that there'll be any kind of "metadata revolution" that'll make these things important.
And, even if there is such a revolution, it's not clear that these things will be better off in the filesystem itself (and not in, say, a separate database a la google desktop search).
What's the big fuss over integrated desktop search tools if meta-data is worthless?
As far as I can tell, high performance full-text search. i.e. searching data, not metadata.
You don't have the slightest clue what your argument is, do you?
I don't know about Novell, but IBM have been doing virtualization similar to that of Xen for probably decades. And Xen's initial development was part sponsored by MS....
User definable operators, user definable aggregate functions, user loadable stored procedure languages, user definable types. That's just for starters.
I don't know about user definable "operators" (though I must concede I can't really see the need), but UDTs and UDFs are commonplace, and the need for "user loadable stored procedure languages" seems to be largely obsoleted by such things as compiled stored procedures (e.g. "extended stored procedures" in MSSQL). So I'm not particularly overwhelmed by your list of features....
Really? How do their file systems deal with metadata compared to reiser3?
This might be an interesting question if metadata mattered worth a damn.
Why no I don't jest. Makes ASP look like yesterdays turd.
Well gee, ya think? You haven't noticed how ASP isn't being developed any more? And hasn't been for about five years? Duh?
Even in it's alpha stage it has multiple dispatch and multiple inheritance. When will.NET have that?
Neither of those need bytecode support; both of those can be effectively implemented on.NET. So, uh.... And you assume that they're even desirable; though multiple inheritance is clearly good, the desire multiple dispatch is much less obvious. Multiple dispatch has a number of issues; in particular, it has non-obvious semantics (specifically, there's no one way of resolving ambiguities that stands out as the "right thing" to do) and is considerably harder to implement efficiently.
Yes, that's the definition of innovation.
In which case it's not really something to aim for, is it....
It's obvious you have no idea what open source products are really like.
It's obvious that you have no idea what proprietary software actually offers.
The code for Quartz 2D Extreme *is* in Tiger and you can enable it if you want. Problem is, it's a bit buggy. But it does work (the Quartz Debug application can enable it), and it accelerates things like drawing lines and text considerably. Quartz Extreme accelerates the Quartz compositor and has been enabled and available since Jaguar (10.2).
Yes, and X11 has had accelerated drawing and hardware specifically built to support it since before GDI even existed.
Are you sure about that? X11 was released in September '87. The first iteration of GDI was in Windows 1, in November '85.
Except that Quartz doesn't really do that:
Quartz may not. Quartz Extreme does, albeit only to a limited extent. Each window is rasterized to a OpenGL texture and these are then transformed in ("3D") hardware. Longhorn will likely be rather more advanced than this (at least, when operating in its full Tier 2 DCE mode).
But there are X11 servers out already that accelerate many common drawing operations with 3D hardware, and there are fully vectorized themes and desktops for X11.
That work by telling the X server to draw a load of triangles? I mean, using SVG icons and things that just get rendered and rasterized in software, and then bitblited in hardware aren't particularly pertinent to this discussion.
Graphic improvements don't mean anything to me, unless they make it easier to program against, and even than it takes some time for any benefits to be felt.
They will be; the new Avalon/WinFX APIs are somewhat better than the current GDI ones.
I also have an issue with Microsft releasing one major update to the API (.Net), and then releasing another API in relatively short succession. What is more they haven't pushed.Net enough, so you are pretty much limited to running.Net based apps on machines you own. So with the release of avalong and indigo we will have, wait for it 3 APIs. Win32,.Net and Avalon/Indigo.
.NET is not an API update. It's a runtime with a class library. The overlap between.NET and Avalon is limited to WinForms (which will be deprecated in favour of Avalon); WinForms are not a core part of.NET; rather, they're just another.NET library. Avalon looks set to be the same..NET will provide the runtime environment and the base classes (things like strings and collections and sockets and all that kind of thing) and an additional Avalon library will provide an API for making windows and drawing shapes on screen and so on and so forth. It's true that migrating from one to the other will be non-trivial; they're completely different APIs with completely different programming models.
Indigo is in a similar boat; it will subsume functionality currently implemented by a number of systems (Web Services in ASP.NET and WSE,.NET remoting (a core.NET feature), Transaction processing from COM+, reliable asychronous messaging from MSMQ). These things are all currently available to.NET but, in spite of their considerable overlap, no particularly unified label or interfaces. This is what Indigo will provide. Indeed, Indigo will still leverage some of these existing mechanisms; Indigo messaging will still use MSMQ, and the Indigo messaging classes will still be in a System.Messaging namespace. Consequentially, porting from the current family of APIs to Indigo should be considerably easier than going from WinForms to Avalon.
Avalon and Indigo will both be ".NET". That is, their APIs will be exposed natively (or solely) to applications within the.NET environment; they'll extend (or replace) existing.NET classes and namespaces.
Offloading is nothing new. GDI has been hardware accelerated for many years (remember the whole "Windows accelerator" phenomenon of the early 1990s?).
What *is* somewhat novel is accelerating normal "2D" APIs with traditionally "3D" hardware; Quartz Extreme does this right now (using OpenGL) and Longhorn will do this (using what will essentially be DirectX 10).
Great. You've just told us how to spin off three or four I/O-bound minimally computational threads, which will do exactly fuck all for scaling on machines such as the next generation of consoles. This is PRECISELY why multithreading is deemed "hard". Doing what you've described is trivial... and pointless.
But carte blanche exists nowhere anyway. The scenarios listed are there to permit secrecy agreements made between citizens and government (they exist in the US), trials perfomed behind closed doors (those exist in the US), prosectuion for shouting "fire" in a crowded theatre and hence endangering those within the building (that exists in the US), and slander and libel laws (those exist in the US).
In this case, "for the prevention of disorder or crime" seems applicable, since someone apparently boasted about their own violent criminal behaviour on the site.
I don't think so, no. You can't prevent an event that's in the past, after all....
(Technically you can do this in Unix today with named pipes, which the Windows world sadly lacks, but it's not as nice and transparent as it could be.)
Too bad the "security issue" was a problem not with hyperthreading but with the use of table-based lookups in encryption algorithms. The same issue can be demonstrated on single core Athlon systems, and they don't got no hyperthreading.
Windows is complex, trying to be everything to everyone. This complexity comes at a terrible price: downtime, help desks, upgrades, patches and the inevitable failures.
'cos OS X has no downtime, patches, upgrades, or failures, as all the users of 10.4 will testify.
When a new operating system or service pack is released, there are tons of changes to the functionality.
Right. Because vendors should be releasing new OSes which don't add any functionality. Just as 10.4 offered nothing over its predecessors.
WinTel machines use different versions of BIOS. They are not all equal, nor do they all have the same level of compatibility.
Right, right. What? BIOS? Clutch at straws much?
Some Windows software applications are well written; others take shortcuts. Shortcuts may work in some environments, but not all, and ultimately the consumer pays in lost time, availability and productivity.
Right, right, and no OS app ever does something it shouldn't. No OS X app ever breaks when you upgrade the OS. Just as the 10.4 users will tell us.
Hardware. There are hundreds of "WinTel-compatible" motherboards, each claiming to be better than the next. Whatever.
Indeed. What the fuck ever. Who gives a shit? Just buy your computer from Dell. They'll pick a motherboard (and a BIOS) for you, so you don't have to. Or is this schmuck disingenuously comparing self-builds (which you, you know, can't do with Macs) to off-the-shelf machines?
Memory. Not all RAM is equal. Some works well. Cheap stuff doesn't.
Right, right, because Macs are compatible with all memory, and Apple don't go round disabling cheap/incompatible memory with OS updates. Right.
Hard disks. Same problem: cheap or reliable. Your call.
And since Apple makes their own hard disks, the problem doesn't arise.
Slashdot Mirror
I don't agree. I couldn't care less about sending spam. The thing that bothers me is receiving it. If I can reliably ensure that I receive no spam (but receive any and all ham) then the problem is solved.
And as far as I can tell, the only way to stop it being sent is to stop it being lucrative. And the only viable mechanism to achieve that is to stop people from receiving it.
"So once that function was ported over from the 95 family to the NT4 family"
That almost certainly never happened.
The function was written once for Windows 3.x. 16-bit, probably asm, probably almost identical to the Win9x code. Somewhere down the line the Win9x GDI team made some change that mitigated this issue (by not processing SetAbortProc in certain situations). I'm not sure if that means 9x is completely unexploitable (I don't know what happens if a WMF is printed, for example), but it means that merely viewing an WMF can't cause code execution.
The function was written once for NT 3.1. 32-bit, C, probably almost identical to the XP/2003 code, independent of the Windows 3.x code. Same purpose, but different code. And because it's different and independent, the change made to 9x was never propagated.
I'm not sure that it would be a little harder. Given that WINE appears to have the same issue an' all....
I haven't seen any evidence thus far that a change was introduced in 2000/XP. So far, everything suggests that it's always been in the NT 3.1 line.
/isn't/ trustworthy. But in the Fax Viewer thingy, such an assumption can't be made. The WMF files it views could come from anywhere; some sources friendly, others hostile. So it is not altogether surprising that it did not have an equivalent change made to it.
What "saved" windows 9x is that it was a completely different code-base from NT (derived from Win3.x); it was likely altered independently by the 9x product team. But because of the separate code-bases there was no cross-pollination of this change to the NT line. Presumably the recent patch implements an equivalent fix (so that SetAbortProc is only handled when actually printing). Or perhaps it removes the functionality altogether, as even when printing, the behaviour seems risky.
It may well be that this "defer until the next record is read" behaviour exists in 9x (even if when actually printing) and Win3.x too.
Rather, the issue that arose in XP and 2003 is that they bundled a COM control that could handle WMF files, and which assumed them to be trustworthy.
IE was deliberately neutered because in IE it's obvious that any WMF file
Probably because it was never there to remove. Windows 2000/XP/2003 are not derivatives of Windows 9x, so the 9x code change was never visible; different source tree, different developers, different managers.
/port/ the change to the NT family. I would not be surprised to find that whoever was responsible for the 9x change just never thought about it; the products were developed quite independently, because they were completely separate. It's one of the many reasons MS wanted to move to a single code-base....
Now, you might ask why they didn't
Yeah, it's real hard alright.
Yeah-uh-huh.Given that if MS don't do this kind of thing they will inevitably face a complete ban (forcing the use of proxy servers and so on), one can hardly fault them for doing so. A complete ban doesn't serve those other users of MSN Spaces, after all. It would have the effect of blocking every blogger on the site no matter what they said, which is surely worse than blocking just one.
So it's not just me who's noticed that. It's completely fucked up.
But Windows' IPSec supports 56-bit DES, and 3DES.
You can't tell very far can you.
Further than you.
Go look at how Apple stores and searches METADATA and the DATA (when it's accessable). When you save a PDF, JPG, MP3 or whatever OS-X extracts the metadata, stores it and indexes it.
Oooh, just like Windows has been doing since the NT 4 Option Pack. How exciting!
MS is trying desparately to implement the same thing.
MS has been there and done that, and did it many years before Apple.
Xen is not virtualization technology. It's paravirtualization. Not the same thing and quite innovative.
It is the same thing. And it isn't "innovative". IBM have been doing it for years.
There is a profound difference between a UDF (which even mysql has) and a user defined aggregate functions and operators.
No there isn't.
It's wonderful to make your own data types and write the operators to make comparisons and define functions like max and min for them.
It may be syntactically convenient. But it is not offering any capability that functions do not.
Just to give you one example you can then run a query like select point from points where point is fartest away from circle. Postgres allows you to code your stored procs in TCL, PL-SQL, PERL, Python and Java due it's flexable architecture. If you are happy with the lame T-SQL then more power to ya.
But I don't have to use T-SQL to write sprocs in SQL Server. You do understand that, right?
Yes, that's why MS is working like a dog on winfs to try and copy of the features of reiser3.
They're not working "like a dog". They've put it on the back burner.
Ok I should have said it makes ASP.NET look like yesterdays turd. Apparently I am talking to a nitpicker here.
ASP and ASP.NET have next to nothing in common, and Ruby on Rails doesn't even begin to make ASP.NET look like "yesterdays turd".
Can be? How come they haven't yet then?
Er... they have.
Aah yes the typical MS FUD. If we don't support it it's beause it sucks and will give you cooties.
What the hell are you talking about? There is no single way to resolve multiple dispatch ambiguities; CLOS and Dylan, for example, both use different and incompatible schemes. Neither is clearly better than the other. And this is a big problem with multiple dispatch. Single dispatch has behaviour that's obviously and intuitively correct. Multiple dispatch doesn't. MI has issues of its own, but the solutions are better understood and (I believe) statically detectable.
But, of course, you just spout typical ABM FUD. If MS doesn't do something it must be great. Doesn't matter what people's objections to it are, if MS doesn't have it it's the best thing since sliced bread, and anyone who says otherwise is spewing FUD.
edit.com is a DOS (16-bit) program. Prior to invoking such programs the shell effectively does a chdir to the SFN so that the DOS program doesn't shit a brick (because, like you say, it inherits its environment from its parent; it needs to inherit an environment that won't confuse it). Sure, they could make it so that the chdir didn't occur in cmd itself but instead in some intermediate level, but what would be the benefit of the extra complexity? There's no good reason to use DOS programs, so why spend any time on this?
And, no, they couldn't make the DOS programs LFN aware, because if they did they wouldn't be DOS programs any more. And the SFNs are not because the FS has different ideas of what's legal and what's not (NTFS doesn't need SFNs, after all), it's because there's software that needs SFNs. A dual naming hack is essential to resolve this problem.
If meta-data isn't worth a damn, why are Microsoft investing so much effort in WinFS?
It's not even obvious that they are. It's not going to be a part of Longhorn, and no-one really knows when it'll emerge. I would wager that this is in no small part due to the relative lack of metadata--designing an FS that can store and metadata efficiently is only a small part of the problem (one that's arguably already solved, as many FSes allow that kind of extensibility, such as HFS+, NTFS, and of course reiser). The problem is making it usable and useful.
People don't want to have to tag all their documents and data files with extra out-of-band information. The only files which routinely have useful, accurate metadata are things like MP3s--and they don't need WinFS (or reiser, or anything else) to store their metadata as they prepend (ID3v2) or append (ID3v1) the information to the data itself. At a pinch digital pictures might get some useful metadata, but again, it's already in EXIF tags. But beyond that? It's far from clear that there'll be any kind of "metadata revolution" that'll make these things important.
And, even if there is such a revolution, it's not clear that these things will be better off in the filesystem itself (and not in, say, a separate database a la google desktop search).
What's the big fuss over integrated desktop search tools if meta-data is worthless?
As far as I can tell, high performance full-text search. i.e. searching data, not metadata.
You don't have the slightest clue what your argument is, do you?
More than you, clearly.
They do? You don't even know what xen is do you?
I don't know about Novell, but IBM have been doing virtualization similar to that of Xen for probably decades. And Xen's initial development was part sponsored by MS....
User definable operators, user definable aggregate functions, user loadable stored procedure languages, user definable types. That's just for starters.
I don't know about user definable "operators" (though I must concede I can't really see the need), but UDTs and UDFs are commonplace, and the need for "user loadable stored procedure languages" seems to be largely obsoleted by such things as compiled stored procedures (e.g. "extended stored procedures" in MSSQL). So I'm not particularly overwhelmed by your list of features....
Really? How do their file systems deal with metadata compared to reiser3?
This might be an interesting question if metadata mattered worth a damn.
Why no I don't jest. Makes ASP look like yesterdays turd.
Well gee, ya think? You haven't noticed how ASP isn't being developed any more? And hasn't been for about five years? Duh?
Even in it's alpha stage it has multiple dispatch and multiple inheritance. When will .NET have that?
Neither of those need bytecode support; both of those can be effectively implemented on .NET. So, uh.... And you assume that they're even desirable; though multiple inheritance is clearly good, the desire multiple dispatch is much less obvious. Multiple dispatch has a number of issues; in particular, it has non-obvious semantics (specifically, there's no one way of resolving ambiguities that stands out as the "right thing" to do) and is considerably harder to implement efficiently.
Yes, that's the definition of innovation.
In which case it's not really something to aim for, is it....
It's obvious you have no idea what open source products are really like.
It's obvious that you have no idea what proprietary software actually offers.
The code for Quartz 2D Extreme *is* in Tiger and you can enable it if you want. Problem is, it's a bit buggy. But it does work (the Quartz Debug application can enable it), and it accelerates things like drawing lines and text considerably. Quartz Extreme accelerates the Quartz compositor and has been enabled and available since Jaguar (10.2).
Yes, and X11 has had accelerated drawing and hardware specifically built to support it since before GDI even existed.
Are you sure about that? X11 was released in September '87. The first iteration of GDI was in Windows 1, in November '85.
Except that Quartz doesn't really do that:
Quartz may not. Quartz Extreme does, albeit only to a limited extent. Each window is rasterized to a OpenGL texture and these are then transformed in ("3D") hardware. Longhorn will likely be rather more advanced than this (at least, when operating in its full Tier 2 DCE mode).
But there are X11 servers out already that accelerate many common drawing operations with 3D hardware, and there are fully vectorized themes and desktops for X11.
That work by telling the X server to draw a load of triangles? I mean, using SVG icons and things that just get rendered and rasterized in software, and then bitblited in hardware aren't particularly pertinent to this discussion.
Graphic improvements don't mean anything to me, unless they make it easier to program against, and even than it takes some time for any benefits to be felt.
They will be; the new Avalon/WinFX APIs are somewhat better than the current GDI ones.
I also have an issue with Microsft releasing one major update to the API (.Net), and then releasing another API in relatively short succession. What is more they haven't pushed .Net enough, so you are pretty much limited to running .Net based apps on machines you own. So with the release of avalong and indigo we will have, wait for it 3 APIs. Win32, .Net and Avalon/Indigo.
.NET is not an API update. It's a runtime with a class library. The overlap between .NET and Avalon is limited to WinForms (which will be deprecated in favour of Avalon); WinForms are not a core part of .NET; rather, they're just another .NET library. Avalon looks set to be the same. .NET will provide the runtime environment and the base classes (things like strings and collections and sockets and all that kind of thing) and an additional Avalon library will provide an API for making windows and drawing shapes on screen and so on and so forth. It's true that migrating from one to the other will be non-trivial; they're completely different APIs with completely different programming models.
Indigo is in a similar boat; it will subsume functionality currently implemented by a number of systems (Web Services in ASP.NET and WSE, .NET remoting (a core .NET feature), Transaction processing from COM+, reliable asychronous messaging from MSMQ). These things are all currently available to .NET but, in spite of their considerable overlap, no particularly unified label or interfaces. This is what Indigo will provide. Indeed, Indigo will still leverage some of these existing mechanisms; Indigo messaging will still use MSMQ, and the Indigo messaging classes will still be in a System.Messaging namespace. Consequentially, porting from the current family of APIs to Indigo should be considerably easier than going from WinForms to Avalon.
Avalon and Indigo will both be ".NET". That is, their APIs will be exposed natively (or solely) to applications within the .NET environment; they'll extend (or replace) existing .NET classes and namespaces.
Offloading is nothing new. GDI has been hardware accelerated for many years (remember the whole "Windows accelerator" phenomenon of the early 1990s?).
What *is* somewhat novel is accelerating normal "2D" APIs with traditionally "3D" hardware; Quartz Extreme does this right now (using OpenGL) and Longhorn will do this (using what will essentially be DirectX 10).
Great. You've just told us how to spin off three or four I/O-bound minimally computational threads, which will do exactly fuck all for scaling on machines such as the next generation of consoles. This is PRECISELY why multithreading is deemed "hard". Doing what you've described is trivial... and pointless.
But carte blanche exists nowhere anyway. The scenarios listed are there to permit secrecy agreements made between citizens and government (they exist in the US), trials perfomed behind closed doors (those exist in the US), prosectuion for shouting "fire" in a crowded theatre and hence endangering those within the building (that exists in the US), and slander and libel laws (those exist in the US).
I don't think so, no. You can't prevent an event that's in the past, after all....
It only gives you very little fallout because the bomb was deliberately crippled to give very little fallout.
With a fissile tamper and a ground burst there'd be lots of fission products and lots of irradiated dirt thrown into the atmosphere.
Huh?
How could a .NET OS be "vaporware" when such a thing has never been even suggested by, well, anyone?
Too bad the "security issue" was a problem not with hyperthreading but with the use of table-based lookups in encryption algorithms. The same issue can be demonstrated on single core Athlon systems, and they don't got no hyperthreading.
Windows is complex, trying to be everything to everyone. This complexity comes at a terrible price: downtime, help desks, upgrades, patches and the inevitable failures.
'cos OS X has no downtime, patches, upgrades, or failures, as all the users of 10.4 will testify.
When a new operating system or service pack is released, there are tons of changes to the functionality.
Right. Because vendors should be releasing new OSes which don't add any functionality. Just as 10.4 offered nothing over its predecessors.
WinTel machines use different versions of BIOS. They are not all equal, nor do they all have the same level of compatibility.
Right, right. What? BIOS? Clutch at straws much?
Some Windows software applications are well written; others take shortcuts. Shortcuts may work in some environments, but not all, and ultimately the consumer pays in lost time, availability and productivity.
Right, right, and no OS app ever does something it shouldn't. No OS X app ever breaks when you upgrade the OS. Just as the 10.4 users will tell us.
Hardware. There are hundreds of "WinTel-compatible" motherboards, each claiming to be better than the next. Whatever.
Indeed. What the fuck ever. Who gives a shit? Just buy your computer from Dell. They'll pick a motherboard (and a BIOS) for you, so you don't have to. Or is this schmuck disingenuously comparing self-builds (which you, you know, can't do with Macs) to off-the-shelf machines?
Memory. Not all RAM is equal. Some works well. Cheap stuff doesn't.
Right, right, because Macs are compatible with all memory, and Apple don't go round disabling cheap/incompatible memory with OS updates. Right.
Hard disks. Same problem: cheap or reliable. Your call.
And since Apple makes their own hard disks, the problem doesn't arise.