The two-faced practice is annoying. No way around that. At least the actions mostly stick to the positive end of the spectrum.
Not granting patents to non-CDDL code is a somewhat spurious practice too. On the other hand IBM has not pledged their patent base surrounding AIX to the GPL community (or any OSS community) either, and seems to be quite popular nonetheless (a bit of a strawman to bring up the point that Solaris is open sourced and not AIX again I admit). It does at any rate seem that Sun has gone to far greater lengths here than pretty much any other company (check out Slashdot darling Apple).
The fact that Sun bought the full SystemV rights around that time to hurt Linux on the other hand I consider to be a Slashdot conspiracy theory. SCO started out by suing IBM, Sun went out and promised their customers complete safety and bought out the full license. A very reasonable move to keep their customers calm. In addition they needed the full license for another reason entirely anyway; To open-source Solaris. So it all fits together nicely.
Ah. What I get for doing poor research, in my defense a lot of sites around the net do claim that it is a very straight MPL.
In a slightly unrelated notice I would say that the CDDL changes seem very appropriate. While software patents are in themselves a bad idea it is not reasonable to let the license encompass patent claims against arbitrary other software. It does not matter a whole lot to open source projects or companies either since they won't deal with software outside the license scope anyway.
I will admit that this is a whole lot more subjective and my original post was wrong. I personally feel that the CDDL is very reasonable anyway however.
CDDL a mess? It is just the Mozilla Public License 1.1 with the word "Mozilla" replaced by "covered software". It is old, established and is both an approved OSI license and a Free Software license approved by the FSF. Sure, it is GPL-incompatible, but so is the IBM Public License.
I have no idea how Sun ended up hated by Slashdot. They sell Linux, they open-sourced the Solaris kernel, they have cooperated with OSS operating systems to get them running on their hardware. Lets not forget a huge donation in the form of buying StarOffice and immediately open-sourcing it. The completely open and royalty-free SPARC architecture (as opposed to the far-from-open PPC). Few companies have done more.
There have been some back and forth on how they perceive Linux, but considering that Linux has been eating Sun's marketshare quickly the last decade they sure seem to have a very good relationship with Linux and related technologies.
On the other hand, if the artist has already signed away their so-called "rights" to a record company, I would say that they only have themselves to blame.
Sure, but that was not really the point of the post. Of course Google will keep on using Linux since they are already on it, no need to switch away from what works.
On the other hand it is not reasonable to speak out against Sun/Solaris at this point either, since they are open-source now (absolutely no need to put quotes around it, the CDDL is just a cleaned up Mozilla license and is OSI approved).
So no doubt the Google employee can not have been refering to Solaris when he speaks of the disadvantages with non-OSS systems.
Sun would be a bit of an odd target since Google has (maybe still do?) run some systems on Sun/Solaris machines (the web crawlers used to be the example I believe). Also there are many references to Google working to keep their internal systems portable between Linux and Solaris.
More importantly Sun is the only classic commercial vendor for which "if Google used Windows, or any other non-open source software program, to make changes to that system he would be required to essentially ask permission from that vendor" no longer is true, with the OpenSolaris project. I know that a lot of people have ideological and political problems with Sun's approach, but it quite clearly offers the same practical business advantages as other OSS while also playing off Sun's classic strengths a bit.
In addition Solaris 10 does run quite well on commodity x86 machines, not as wide hardware support as Linux sure, but if you are buying the machines for the purpose you have no trouble.
This is not to say that Google should use Sun (or that anyone should), but Sun really has positioned themselves in a place where this type of complaints don't really hold. Which is apparently the right place to be in the current climate.
On the other hand a trojan could very well do the same on Linux. It just needs to get itself started by something in your user configuration, and who keeps track of all those dot-files in ones home-directory? Throwing in the trojan in there somewhere would work just fine to make the machine a spam/DDOS-zombie. The process would not be able to hide itself as rootkits on Linux/UNIX typically does, but who really keeps track of all processes running on the machine? If it picks an inconspicuous name for itself (or simply fork's and execs itself to rename itself to match one of the currently running processes on your system).
If one keeps a special account with continuously wiped home directory one can fairly safely try programs on it, but that is another big hassle. Finally privilige escalation holes are very common, so once malicious code is running on your machine you are already in a lot of trouble.
Personally I stopped caring, being completely safe if more trouble than it is worth, my desktop machine is hardly critical at any rate.
This is a good thing for everyone since it sets more precedent. Now people with less large and competent lawyer teams than Microsoft (read: everyone) has a better chance to sue and win.
Really, for end-users Firefox is just another browser. I don't know quite what Firefox evangelists are expecting, the typical user won't use the tabs easily (hey, I am a pretty knowledgeable computer user and I still sometimes manage to lose a page in the mix between the page/window metaphors) and beyond that, what does Firefox really offer?
IE's security issues exist, but are a bit overblown for the most part, most spyware and adware finds its way onto peoples system because people click and run things they should not. On the other hand Firefox has a heavier memory footprint (slightly, heavier at startup and leaks a bit, but it is true that one can easily agitate IE to a fair bit of memory gluttony too) and may still render a few pages badly.
Overall it is not all that clear that Firefox is all that much better from an end-user perspective, at the very least not enough for many people to care. And absolutely not enough to not make a person raving about it look like a hopelessly snowed in nerd.
I think we will have to just disagree on the ease of use. I consider the OpenGL matrices very straightforward (in fact, I consider them the very model of perfect API simplicity:). I do agree that as soon as you have to drop to extensions in OpenGL things take a very sharp turn for the worse however. Talking about the initialization mess being gone because they have thrown in a wrapper is a bit dubious to me, but then again, so is any such discussion about software.
I will have to stand corrected on Direct3D performance. My personal experience came from larger batches (on the level of 1K polygons at least) where the difference is fairly slight. As this presentation from GDC nicely shows the difference is indeed notable on smaller batches.
They do memory differently, I would be hard pressed to say that either of the ways is better though.
I'd imagine that there are worse issues for the layering than that as well. That one is not that huge since the reads in OpenGL are so mind-numbingly inefficient that they are near useless anyway (somewhat pragmatic view of the issue here though:).
I think I'll shut up now, you apparently have a much better clue about the issues than I do.
Read the frontpage at OpenGL.org. The issue is that the Windows Vista desktop is composited by Direct3D, so to make a windowed OpenGL application able to fully utilize the compositor it will be able to use a wrapper provided by Microsoft, passing through OpenGL calls to Direct3D (with the listed drawbacks). The frontpage also says however that loading a full ICD (OpenGL jargon, "installable client driver", basicly a complete driver from the manufacturer rather than the OS-provided interface) the compositor will actuall switch off to allow the ICD to function correctly.
What does this mean? The compositor will indeed run more slowly (in software) when a full-blown OpenGL app is run. In most cases this does not seem like an all that huge issue, it ought to be plenty usable anyway (try tunning OSX without Quartz Extreme, it is a bit more sluggish, but not unusable). And for the typical light OpenGL app (non-games) the wrapper will probably do OK and then not interfere with the compositor.
Sure it would have been much better if the hardware compositor and an OpenGL ICD could work together, but it is on the other hand also clear that it would most likely have been a lot messier for both Microsoft and driver writes to achieve (basicly an OpenGL context is to be composited into a scene drawn by a Direct3D context). But it is hardly the end of the world for OpenGL, notably pretty much no games at all will be affected at all since one does not tend to window-manage a great deal while playing a game.
If I have misunderstood the available information I apologize, but if this is correct it is, while maybe not ideal, hardly the sky falling either.
This seems a bit odd, calling Direct3D easy to program for. Early versions of Direct3D were a true horror to work with (check out how one did state changes), granted it was cleaned up as time went on but I would still argue that OpenGL has the edge when it comes to simplicity in all cases except when one needs a lot of bleeding edge functionality (since extensions are messier than just adding things to the API with some expediency like is done in D3D).
There are no real efficiency considerations in the API as such anymore however. A rather amazingly large part of the logic functionality of modern graphics "hardware" actually live in the driver. The operations actually provided by the hardware are limited and primitive, the driver typically has a number of options how to assign a high-level operation on the hardware, and a lot of preprocessing and adjustment of the function is needed before it is ready to execute efficiently. This is also where time is spent, in code that are most likely in any sane driver common to both OpenGL and Direct3D.
One very general and simple example is when a geometry set is uploaded to the card (through a vertex array or such). The hardware will often cache a number of old transformed vertices, if two primitives with the same vertices come too far apart in the set however the cache will not be effective. Therefore the driver spends a fairly large chunk of CPU-time reordering primitives so that shared vertices occur as close to each other as possible, this will make the transform cache able to pick the already-transformed vertex instead of having to redo it. Even worse the hardware may only provide a hand-managed cache, so that the driver has to insert quick stores and loads for transformations in cache.
This type of operation is fairly expensive and the driver has to do a lot of them. Another simple example is pixel shaders, which are translated to some internal form, typically with some optimization to fit actual hardware limitations. It is however not really on the API level, it is really logic that is expected to be below the API implemented as software since having the hardware provide operations directly mapping to the API would be exceedingly complex and inefficient.
Unfortunately I feel the need to reply to peoples post, even when they are nonsensical ravings.
You talk about MS-DOS and Windows 3.1? I already called every Windows version prior to 2K worthless.
Things exploding now and then is your claim, not mine. There are better solutions security-wise than Windows, but there are also a lot worse (including among Linux distributions). Feel free to point out a platform completely without security issues.
No other platforms I know of do the end-user application sandboxing, nor do any mainstream one I can think of try to do automatic buffer checks (though there are more promise here, there have been numerous GCC patches to supply similar functionality to what is offered in MSVC, none has made it into the mainline yet however).
I would like to wrap up this pointless reply by requesting that for the sake of people everywhere you stop posting on the internet, or preferably stop interacting with people altogether (though I imagine the first would actually imply the second).
They care not about a decent product, improving the state of the art, or improving lives through technology. And for that, they should be abhorred.
I disagree here, I would say that MS is indeed improving things. That is what the blogging has convinced me of.
The security push should have started earlier, but now that it has gotten going things are looking up. One should remember that UNIX with variants (and daemons and services lets not forget, Windows gets faulted for a lot of the auxiliary functionality that would not be counted to the OS on UNIX) have had nearly 20 years worth of constant exploits and fixes, compared to this exceedingly long history of security work NT with servers and services are relatively young.
To some part I am mostly impressed by the security work since it is actually done on a quite low level rather than the classic code review over and over. The firewall is a no-brainer, but the buffer overrun checks for all default software is a great step (which should be more widely imitated than it is).
The best part however is the framework underlying low-rights IE, a nice way to add UNIX daemon style sandboxing to desktop applications without making them impossible to use. It works by delegating potentially dangerous tasks like writing to disk to subcomponents which have more privileges. That is, the kernel has an access control system where permissions like "iexplorer.exe may not write to disk but may launch subcomponent XYZ which may write to disk", then only a very small subcomponent need to be fully reviewed to make sure that no exploit in IE can change anything on disk.
Windows 9x and previous are truly archaic systems, but I don't see much reason to fault NT in the same way. How about some actual examples how Microsoft's technology and/or implementation is "crap"? Other than the current (and more notably, past) security issues I really can't find any major faults with the NT based Windows variants technology-wise.
The whole point here is that Microsoft went out of their way to create semantics that would make old programs work in a sensible way. They did not do it because the developers are stupid or did not think of that approach; they do it because they are prepared to do some hard work and sacrifice to make applications keep on working under new systems.
Now I imagine that you still consider that the "wrong" way to write an OS, but millions upon millions of people relying on legacy code every day really appreciate the approach.
With the above implementation old apps that do the copy-write-move approach to get a good copy of the file would not properly work in the new system (since it would trash all the extra data the system is there to save).
I would not consider that irrational no, a lot of Slashdot consider all Microsoft software horrible technology-wise, which is not really true.
I disagree a bit about the disregard for standards, while one can hardly count Microsoft as good at picking up and following standards they are not nearly as bad as they are sometimes made out to be around here. For example, adding specialized markup languages to IE (like their rather cool vector markup as discussed in a google maps article a while back) I would not consider a bad thing. Sure people would prefer them to just focus on more standards support, but in such a case the thing they make really is a good piece of technology. Saying that Microsoft is not allowed to create new technologies just because they haven't implemented every standard in existance (even when the standards and the new technology are not in any way related) is just a double standard.
I don't dislike Microsoft nearly as much as most of Slashdot does (as evidenced by some of my earlier posts), but this article has no meaningful content and is as such pointless.
Personally I started respecting Microsoft a whole lot more when the developers started blogging on a large scale. Few people can possibly have missed Raymond Chen's excellent blog Old New Thing which really explains a lot of the things that Slashdot would consider "cruft" and "archaic design" in Windows. For those who missed it I would recommend the post about file-system tunneling. On one hand it is a downright revolting workaround to make old apps work and behave as one would expect, but on the other hand one has to respect the obviously huge amounts of thought and effort that went into it.
To some part this also goes back to a bit of a reaction against Slashdot and similar places obsession with hating Microsoft. They are a lot better than they were in say, 97. With NT under the hood Windows is an a lot more agreeable operating system. Slashdot may scoff at Microsofts security effort, but in all honesty it seems to be going fairly well form my perspective. Updates are quicker and more plentiful (also most vulnerabilities seem to be announced because the fix showed up on WindowsUpdate than because an exploit was found). Recompiling large part of the system with automatic buffer checks (where possible, this is C/C++ we are talking about) has helped the severity of a lot of exploits. The new low-rights IE seems to be a good approach to insulate any problems further (borrowed from UNIX daemons granted, but the OS-level security infrastructure is sound, and applying it in a useful way to desktop applications really is a new thing), check out the IE teams blog for information about that work by the way: IEBlog. They may not have had the best place to start from, but it does seem to be going the right way (I mean, hey, just getting a working software firewall in place was a huge leap forward), which I would think everyone can agree is a good thing.
Another popular blog is Michael Kaplan's blog dealing with internationalization stuff like character encoding and input support.
Overall I could link blogs for quite a while, pretty much all major Microsoft products have developers blogging. It can be interesting to have a read, they are often well written, have a nice technical content and give a bit more understanding for how things work (and may help cure some of the more irrational hate for Microsoft:).
This might unfortunately be the case yeah. I would highly disagree that they are five years behind everyone else however, if they put some effort in it they could easily bring IE up to the level of Firefox over a year or two (lets not forget that Firefox does not pass ACID2 either, plus some old memory leaks and occasional spell of instability after a long day). It is not unlikely that IE still is not a great priority at Microsoft however.
I'd like not to be all that negative however, CSS fixes and full PNG support, not to mention the low-rights implementation, are all really good steps. Since we wont actually get rid of Microsoft (if people didn't flee in the horrible 9x days why would they now that pretty much all Microsofts product lines look a whole lot better?) it is good thing if they move in the right direction with things like IE.
It has historically been Microsofts C compiler as well, and has done an excellent job with it (and don't go about thinking that C89 is a subset of C++ now). It is just unfortunate that they have decided to not update the C part to C99, it is not like it would even be a major undertaking. Most of the features are already available by other means in Visual C++, but they seem to just decided not to spend the week it would take to bring in full C99 compliance.
Which is why the already expressed intention of the IE7 development team to fully support CSS2 is a good thing.
The article however is screaming about the IE team saying that they won't aim to pass the ACID2 test for this release. I don't see a problem with this, the point of my previous post was that it is not worth it to worry about getting the browser in line with standards perfectly on every front when no other browser passes the test anyway. Getting the CSS2 into a good known functioning state for baseline web development is the right priority. People going paragraph-surfing on w3c.com and making up tests that no browser passes is not something to take much notice of until then.
To reiterate; Fix what is most needed (and they are apparently bringing up a lot of broken functionality to the standard) first, and maybe worry about what the W3C is whining about some other decade.
Full support for CSS2 (which is apparently what the IE team are aiming for) seems like a fairly reasonable goal to me. In most places I am very much for keeping up with standards (where the heck is C99 in Visual C++?), but the web standards are moving much too quickly. Basicly the W3C has for the last ten years pushed out a new standard long before even the most major browsers have finished trying to set up even basic support for the last one.
It should not be so hopelessly complex to make a accessible hardware-agnostic information presentation system. Mozilla is fairly nearly caught up (to some part because it is a fresh codebase designed for the current direction in web standards), but even they fail in a myriad of ways and has tons of little inconsistencies and bugs (ACID2 highlights how easy it is to trigger a lot of problems). It would of course be best if everyone managed to keep up and make bug-free implementations of all the web standards, but in a more pragmatic sense the W3C really has to slow down a bit and let the landscape settle somewhat. Imagine a really stable browser (Firefox still has plenty of issues after a full day running for me), and it would be even nicer if writing a web-browser was a slightly more possible task. Notice how we have more very well-implemented OS kernels lying around than we have even half-way standards-compliant browsers?
I don't see particularly much reason for anyone to actually use IE7, but their goals with it seem reasonable if they instead focus their energies on making the older standards-support solid and bug-free rather than shooting for yet another level of technologies.
Now there's a clever question to ask the founder of the Gentoo distribution. I guess the other guy can give an interesting answer, but I am quite willing to bet that at least Daniel does indeed use Gentoo:)
While the concept of the low-rights IE is not really new, the implementation really is a step up from the coarse UNIX daemon practice, which is, not incidently, not really all that useful for desktop applications. The NT kernel has always had a very nice fine-grained security system -- which has never really been used by Microsoft. The departure here is that Microsoft is actually using the system for IE (which should hopefully make IE restricted in system access without impacting usability). In addition to this they are apparently providing more tools and libraries to help application developers take advantage of the security model. The security implementation has apparently also been extended, have seen no whitepaper on it yet however.
While this is of course an evolutionary move (as almost all software is, including OSX Tiger) it is still a jump ahead of competitors in the field, Microsoft appears to be going for setting up their applications on a per-application decided security level from the OS side, a flexible move that ought to help them out a bit on the security side.
One of the primary reasons why I point this out is to say this; Microsofts security push seems to have made a lot of difference in what they do and how they do it. Though Slashdot is full of naysayers they do really go out of their way to improve every aspect of their security, and it will probably also pay off. And hey, this is good news for Linux users and Windows users alike, better web standards support, better security and an effort to battle phishing are all things that will make the world a better place in general.
World of Warcraft is apparently considered extremely playable. Unfortunately as is common with the Transgaming stuff that still means that the installer crashes (but has finished when it does), the graphic glitches in places and performance is lousy in some situations without a special hack. Overall it is a way to get to play games, but it is hardly the most user-friendly solution there is.
Sure AMD is ahead in a lot of ways at the moment, the difference is far from dramatic however. People make a huge deal about 10%-20% differences in some benchmark (and the Pentium 4 still holds the crown in some areas, typically SIMD-friendly stuff).
Nothing against AMD (quite the opposite, haven't owned anything else the last decade), but their superiority was much more obvious to me with the K7 then the K8. The K7 and P4 were fairly equal in performance, the K7 won a few and the P4 won a few. The big difference was that the K7 was incredibly cheap, easily half or down to a fourth of the price of a comparative P4. The K8 does not really offer the same deal, we get slightly better performance overall but the prices are no longer the bargain-bin that AMD used to offer. It makes sense for AMD of course, but as a consumer I do feel a bit worse off than during the K7 days.
Intel on the other hand is working hard to get around their misstep with the P4 (and it is a real testament to Intels strengths that even what most people consider a failed architecture has stayed decently competitive over so many years), they have lowered their prices and are listening to market demand (making a very cheap dual core CPU and adding the 64 bit instruction set). I don't really think that Intel should be considered terribly evil, they listen to consumer demands where they could have harmed AMD greatly by making a sufficiently different 64 bit instruction set. Also; make no mistake, the P4 was not a marketing chip, it was just an attempt at a very innovative take on chip design. It did not pan out, but it deserves a lot of respect both for Intels guts to make it and the engineering that went into it. If they had wanted to make it a marketing chip they could easily have doubled the clockrate in marketing, the P4 ALU's actually run at double the advertised clockrate.
Overall things are looking good on the x86, decent competition between two companies who both really push the envelope in technology. Intels deals with OEMs should be looked into, but really, there are much much worse companies than Intel. I for one look forward to what Intel cooks up for the next generation.
I don't like coming to Intels defense over and over, but I feel that Slashdot is giving them less credit than they deserve. The P4 was an really interesting move (compared to the K7 for example which was just a solid take on very tried designs), and as a technological community I can't help but feel that Slashdot should appreciate Intel's attempt to try a somewhat different path.
Not granting patents to non-CDDL code is a somewhat spurious practice too. On the other hand IBM has not pledged their patent base surrounding AIX to the GPL community (or any OSS community) either, and seems to be quite popular nonetheless (a bit of a strawman to bring up the point that Solaris is open sourced and not AIX again I admit). It does at any rate seem that Sun has gone to far greater lengths here than pretty much any other company (check out Slashdot darling Apple).
The fact that Sun bought the full SystemV rights around that time to hurt Linux on the other hand I consider to be a Slashdot conspiracy theory. SCO started out by suing IBM, Sun went out and promised their customers complete safety and bought out the full license. A very reasonable move to keep their customers calm. In addition they needed the full license for another reason entirely anyway; To open-source Solaris. So it all fits together nicely.
In a slightly unrelated notice I would say that the CDDL changes seem very appropriate. While software patents are in themselves a bad idea it is not reasonable to let the license encompass patent claims against arbitrary other software. It does not matter a whole lot to open source projects or companies either since they won't deal with software outside the license scope anyway.
I will admit that this is a whole lot more subjective and my original post was wrong. I personally feel that the CDDL is very reasonable anyway however.
I have no idea how Sun ended up hated by Slashdot. They sell Linux, they open-sourced the Solaris kernel, they have cooperated with OSS operating systems to get them running on their hardware. Lets not forget a huge donation in the form of buying StarOffice and immediately open-sourcing it. The completely open and royalty-free SPARC architecture (as opposed to the far-from-open PPC). Few companies have done more.
There have been some back and forth on how they perceive Linux, but considering that Linux has been eating Sun's marketshare quickly the last decade they sure seem to have a very good relationship with Linux and related technologies.
On the other hand, if the artist has already signed away their so-called "rights" to a record company, I would say that they only have themselves to blame.
On the other hand it is not reasonable to speak out against Sun/Solaris at this point either, since they are open-source now (absolutely no need to put quotes around it, the CDDL is just a cleaned up Mozilla license and is OSI approved).
So no doubt the Google employee can not have been refering to Solaris when he speaks of the disadvantages with non-OSS systems.
More importantly Sun is the only classic commercial vendor for which "if Google used Windows, or any other non-open source software program, to make changes to that system he would be required to essentially ask permission from that vendor" no longer is true, with the OpenSolaris project. I know that a lot of people have ideological and political problems with Sun's approach, but it quite clearly offers the same practical business advantages as other OSS while also playing off Sun's classic strengths a bit.
In addition Solaris 10 does run quite well on commodity x86 machines, not as wide hardware support as Linux sure, but if you are buying the machines for the purpose you have no trouble.
This is not to say that Google should use Sun (or that anyone should), but Sun really has positioned themselves in a place where this type of complaints don't really hold. Which is apparently the right place to be in the current climate.If one keeps a special account with continuously wiped home directory one can fairly safely try programs on it, but that is another big hassle. Finally privilige escalation holes are very common, so once malicious code is running on your machine you are already in a lot of trouble.
Personally I stopped caring, being completely safe if more trouble than it is worth, my desktop machine is hardly critical at any rate.
This is a good thing for everyone since it sets more precedent. Now people with less large and competent lawyer teams than Microsoft (read: everyone) has a better chance to sue and win.
IE's security issues exist, but are a bit overblown for the most part, most spyware and adware finds its way onto peoples system because people click and run things they should not. On the other hand Firefox has a heavier memory footprint (slightly, heavier at startup and leaks a bit, but it is true that one can easily agitate IE to a fair bit of memory gluttony too) and may still render a few pages badly.
Overall it is not all that clear that Firefox is all that much better from an end-user perspective, at the very least not enough for many people to care. And absolutely not enough to not make a person raving about it look like a hopelessly snowed in nerd.
I will have to stand corrected on Direct3D performance. My personal experience came from larger batches (on the level of 1K polygons at least) where the difference is fairly slight. As this presentation from GDC nicely shows the difference is indeed notable on smaller batches.
They do memory differently, I would be hard pressed to say that either of the ways is better though.
I'd imagine that there are worse issues for the layering than that as well. That one is not that huge since the reads in OpenGL are so mind-numbingly inefficient that they are near useless anyway (somewhat pragmatic view of the issue here though :).
I think I'll shut up now, you apparently have a much better clue about the issues than I do.
What does this mean? The compositor will indeed run more slowly (in software) when a full-blown OpenGL app is run. In most cases this does not seem like an all that huge issue, it ought to be plenty usable anyway (try tunning OSX without Quartz Extreme, it is a bit more sluggish, but not unusable). And for the typical light OpenGL app (non-games) the wrapper will probably do OK and then not interfere with the compositor.
Sure it would have been much better if the hardware compositor and an OpenGL ICD could work together, but it is on the other hand also clear that it would most likely have been a lot messier for both Microsoft and driver writes to achieve (basicly an OpenGL context is to be composited into a scene drawn by a Direct3D context). But it is hardly the end of the world for OpenGL, notably pretty much no games at all will be affected at all since one does not tend to window-manage a great deal while playing a game.
If I have misunderstood the available information I apologize, but if this is correct it is, while maybe not ideal, hardly the sky falling either.
There are no real efficiency considerations in the API as such anymore however. A rather amazingly large part of the logic functionality of modern graphics "hardware" actually live in the driver. The operations actually provided by the hardware are limited and primitive, the driver typically has a number of options how to assign a high-level operation on the hardware, and a lot of preprocessing and adjustment of the function is needed before it is ready to execute efficiently. This is also where time is spent, in code that are most likely in any sane driver common to both OpenGL and Direct3D.
One very general and simple example is when a geometry set is uploaded to the card (through a vertex array or such). The hardware will often cache a number of old transformed vertices, if two primitives with the same vertices come too far apart in the set however the cache will not be effective. Therefore the driver spends a fairly large chunk of CPU-time reordering primitives so that shared vertices occur as close to each other as possible, this will make the transform cache able to pick the already-transformed vertex instead of having to redo it. Even worse the hardware may only provide a hand-managed cache, so that the driver has to insert quick stores and loads for transformations in cache.
This type of operation is fairly expensive and the driver has to do a lot of them. Another simple example is pixel shaders, which are translated to some internal form, typically with some optimization to fit actual hardware limitations. It is however not really on the API level, it is really logic that is expected to be below the API implemented as software since having the hardware provide operations directly mapping to the API would be exceedingly complex and inefficient.
You talk about MS-DOS and Windows 3.1? I already called every Windows version prior to 2K worthless.
Things exploding now and then is your claim, not mine. There are better solutions security-wise than Windows, but there are also a lot worse (including among Linux distributions). Feel free to point out a platform completely without security issues.
No other platforms I know of do the end-user application sandboxing, nor do any mainstream one I can think of try to do automatic buffer checks (though there are more promise here, there have been numerous GCC patches to supply similar functionality to what is offered in MSVC, none has made it into the mainline yet however).
I would like to wrap up this pointless reply by requesting that for the sake of people everywhere you stop posting on the internet, or preferably stop interacting with people altogether (though I imagine the first would actually imply the second).
I disagree here, I would say that MS is indeed improving things. That is what the blogging has convinced me of.
The security push should have started earlier, but now that it has gotten going things are looking up. One should remember that UNIX with variants (and daemons and services lets not forget, Windows gets faulted for a lot of the auxiliary functionality that would not be counted to the OS on UNIX) have had nearly 20 years worth of constant exploits and fixes, compared to this exceedingly long history of security work NT with servers and services are relatively young.
To some part I am mostly impressed by the security work since it is actually done on a quite low level rather than the classic code review over and over. The firewall is a no-brainer, but the buffer overrun checks for all default software is a great step (which should be more widely imitated than it is).
The best part however is the framework underlying low-rights IE, a nice way to add UNIX daemon style sandboxing to desktop applications without making them impossible to use. It works by delegating potentially dangerous tasks like writing to disk to subcomponents which have more privileges. That is, the kernel has an access control system where permissions like "iexplorer.exe may not write to disk but may launch subcomponent XYZ which may write to disk", then only a very small subcomponent need to be fully reviewed to make sure that no exploit in IE can change anything on disk.
Windows 9x and previous are truly archaic systems, but I don't see much reason to fault NT in the same way. How about some actual examples how Microsoft's technology and/or implementation is "crap"? Other than the current (and more notably, past) security issues I really can't find any major faults with the NT based Windows variants technology-wise.
Now I imagine that you still consider that the "wrong" way to write an OS, but millions upon millions of people relying on legacy code every day really appreciate the approach.
With the above implementation old apps that do the copy-write-move approach to get a good copy of the file would not properly work in the new system (since it would trash all the extra data the system is there to save).
I disagree a bit about the disregard for standards, while one can hardly count Microsoft as good at picking up and following standards they are not nearly as bad as they are sometimes made out to be around here. For example, adding specialized markup languages to IE (like their rather cool vector markup as discussed in a google maps article a while back) I would not consider a bad thing. Sure people would prefer them to just focus on more standards support, but in such a case the thing they make really is a good piece of technology. Saying that Microsoft is not allowed to create new technologies just because they haven't implemented every standard in existance (even when the standards and the new technology are not in any way related) is just a double standard.
Personally I started respecting Microsoft a whole lot more when the developers started blogging on a large scale. Few people can possibly have missed Raymond Chen's excellent blog Old New Thing which really explains a lot of the things that Slashdot would consider "cruft" and "archaic design" in Windows. For those who missed it I would recommend the post about file-system tunneling. On one hand it is a downright revolting workaround to make old apps work and behave as one would expect, but on the other hand one has to respect the obviously huge amounts of thought and effort that went into it.
To some part this also goes back to a bit of a reaction against Slashdot and similar places obsession with hating Microsoft. They are a lot better than they were in say, 97. With NT under the hood Windows is an a lot more agreeable operating system. Slashdot may scoff at Microsofts security effort, but in all honesty it seems to be going fairly well form my perspective. Updates are quicker and more plentiful (also most vulnerabilities seem to be announced because the fix showed up on WindowsUpdate than because an exploit was found). Recompiling large part of the system with automatic buffer checks (where possible, this is C/C++ we are talking about) has helped the severity of a lot of exploits. The new low-rights IE seems to be a good approach to insulate any problems further (borrowed from UNIX daemons granted, but the OS-level security infrastructure is sound, and applying it in a useful way to desktop applications really is a new thing), check out the IE teams blog for information about that work by the way: IEBlog. They may not have had the best place to start from, but it does seem to be going the right way (I mean, hey, just getting a working software firewall in place was a huge leap forward), which I would think everyone can agree is a good thing.
Another popular blog is Michael Kaplan's blog dealing with internationalization stuff like character encoding and input support.
Overall I could link blogs for quite a while, pretty much all major Microsoft products have developers blogging. It can be interesting to have a read, they are often well written, have a nice technical content and give a bit more understanding for how things work (and may help cure some of the more irrational hate for Microsoft :).
This might unfortunately be the case yeah. I would highly disagree that they are five years behind everyone else however, if they put some effort in it they could easily bring IE up to the level of Firefox over a year or two (lets not forget that Firefox does not pass ACID2 either, plus some old memory leaks and occasional spell of instability after a long day). It is not unlikely that IE still is not a great priority at Microsoft however.
I'd like not to be all that negative however, CSS fixes and full PNG support, not to mention the low-rights implementation, are all really good steps. Since we wont actually get rid of Microsoft (if people didn't flee in the horrible 9x days why would they now that pretty much all Microsofts product lines look a whole lot better?) it is good thing if they move in the right direction with things like IE.
It has historically been Microsofts C compiler as well, and has done an excellent job with it (and don't go about thinking that C89 is a subset of C++ now). It is just unfortunate that they have decided to not update the C part to C99, it is not like it would even be a major undertaking. Most of the features are already available by other means in Visual C++, but they seem to just decided not to spend the week it would take to bring in full C99 compliance.
The article however is screaming about the IE team saying that they won't aim to pass the ACID2 test for this release. I don't see a problem with this, the point of my previous post was that it is not worth it to worry about getting the browser in line with standards perfectly on every front when no other browser passes the test anyway. Getting the CSS2 into a good known functioning state for baseline web development is the right priority. People going paragraph-surfing on w3c.com and making up tests that no browser passes is not something to take much notice of until then.
To reiterate; Fix what is most needed (and they are apparently bringing up a lot of broken functionality to the standard) first, and maybe worry about what the W3C is whining about some other decade.
It should not be so hopelessly complex to make a accessible hardware-agnostic information presentation system. Mozilla is fairly nearly caught up (to some part because it is a fresh codebase designed for the current direction in web standards), but even they fail in a myriad of ways and has tons of little inconsistencies and bugs (ACID2 highlights how easy it is to trigger a lot of problems). It would of course be best if everyone managed to keep up and make bug-free implementations of all the web standards, but in a more pragmatic sense the W3C really has to slow down a bit and let the landscape settle somewhat. Imagine a really stable browser (Firefox still has plenty of issues after a full day running for me), and it would be even nicer if writing a web-browser was a slightly more possible task. Notice how we have more very well-implemented OS kernels lying around than we have even half-way standards-compliant browsers?
I don't see particularly much reason for anyone to actually use IE7, but their goals with it seem reasonable if they instead focus their energies on making the older standards-support solid and bug-free rather than shooting for yet another level of technologies.
Now there's a clever question to ask the founder of the Gentoo distribution. I guess the other guy can give an interesting answer, but I am quite willing to bet that at least Daniel does indeed use Gentoo :)
While this is of course an evolutionary move (as almost all software is, including OSX Tiger) it is still a jump ahead of competitors in the field, Microsoft appears to be going for setting up their applications on a per-application decided security level from the OS side, a flexible move that ought to help them out a bit on the security side.
One of the primary reasons why I point this out is to say this; Microsofts security push seems to have made a lot of difference in what they do and how they do it. Though Slashdot is full of naysayers they do really go out of their way to improve every aspect of their security, and it will probably also pay off. And hey, this is good news for Linux users and Windows users alike, better web standards support, better security and an effort to battle phishing are all things that will make the world a better place in general.
World of Warcraft is apparently considered extremely playable. Unfortunately as is common with the Transgaming stuff that still means that the installer crashes (but has finished when it does), the graphic glitches in places and performance is lousy in some situations without a special hack. Overall it is a way to get to play games, but it is hardly the most user-friendly solution there is.
Nothing against AMD (quite the opposite, haven't owned anything else the last decade), but their superiority was much more obvious to me with the K7 then the K8. The K7 and P4 were fairly equal in performance, the K7 won a few and the P4 won a few. The big difference was that the K7 was incredibly cheap, easily half or down to a fourth of the price of a comparative P4. The K8 does not really offer the same deal, we get slightly better performance overall but the prices are no longer the bargain-bin that AMD used to offer. It makes sense for AMD of course, but as a consumer I do feel a bit worse off than during the K7 days.
Intel on the other hand is working hard to get around their misstep with the P4 (and it is a real testament to Intels strengths that even what most people consider a failed architecture has stayed decently competitive over so many years), they have lowered their prices and are listening to market demand (making a very cheap dual core CPU and adding the 64 bit instruction set). I don't really think that Intel should be considered terribly evil, they listen to consumer demands where they could have harmed AMD greatly by making a sufficiently different 64 bit instruction set. Also; make no mistake, the P4 was not a marketing chip, it was just an attempt at a very innovative take on chip design. It did not pan out, but it deserves a lot of respect both for Intels guts to make it and the engineering that went into it. If they had wanted to make it a marketing chip they could easily have doubled the clockrate in marketing, the P4 ALU's actually run at double the advertised clockrate.
Overall things are looking good on the x86, decent competition between two companies who both really push the envelope in technology. Intels deals with OEMs should be looked into, but really, there are much much worse companies than Intel. I for one look forward to what Intel cooks up for the next generation.
I don't like coming to Intels defense over and over, but I feel that Slashdot is giving them less credit than they deserve. The P4 was an really interesting move (compared to the K7 for example which was just a solid take on very tried designs), and as a technological community I can't help but feel that Slashdot should appreciate Intel's attempt to try a somewhat different path.