IE 7 in Vista can supposedly run in a "self-lock-down" mode that denies itself a lot of access, even more than a normal "limited user account". It's been mentioned in ieblog, just google it.
You're not copying Windows just by running an IIS web server. Any license limitations in the number of connections or anything is not directly related to copyright, but the enforcability of the EULA.
(On the other hand, if we assume that IIS will always give root access to the machine it's running on, maybe it could be considered redistribution of Windows itself...)
What contributes more if one part of the population (one out of 10,000) gets CTS with a 75 % chance after twenty years of keyboard use, due to a certain genetic configuration, while the other 9,999 gets it with a 1 % chance. Most cases of CTS will not carry the pre-disposing gene, but it's quite easy to show that genetics seem to be able to influence the outcome to a great deal.
We may not understand very much of the total genome, but we have a pretty good view of independent versus dependent events in probability; enough that it's a gross simplification to talk about what contributes the most.
If I load any GPLed program, it will also share the address space of the kernel. All ring 0 memory is usually mapped into all user mode processes and the kernel will be able to read all the memory of its GPL caller. Does this make bundling a single GPL user mode program a forbidden practice? After all, the kernel will be able to read and interact with the user mode code at its own discretion.
What about systems without memory protection? Is any multitasking between a GPL app and a non-GPL disallowed? I think that it should be clear that it is the LKP that's running and requiring certain services from the kernel, not the other way round. The fact that this, in the specific case, is accomplished by running in ring 0 and, because of that, being able to access the full address space, both the current user mode app and kernel space, should be irrelevant.
It's probably possible to just write a TXTSETUP.OEM that tricks into loading the driver. ("Tricks" as its meant for hardware controllers, not some other driver you want to load.)
Put another way, it should be comparable to installing Windows on a device where it lacks native driver support, like installing vanilla W2K on a system with LBA48 disks.
It doesn't work that way. It's totally common to reference other patents in a new one. Then, especially in the claims, you describe what you're doing is even better, and (probably) different.
Do you have any source for this? Remember, it's the partial pressure of oxygen, not the percentage of the total air, that is the most important factor here. This would mean that you couldn't ignite in the free atmosphere a few hundred meters up in the atmosphere (or on a hill or mountain of that height, relative to the sea level). You would also not have been able to smoke within an aircraft, even during the times when that was allowed. (Hey, even the relative humidity would be enough to knock oxygen your claimed single percent off, and if you don't get outright fog or mist, things ignite and burn quite well...)
This is not to say that it wouldn't have consequences. The likelihood of natural fires after lightning strikes and other events would naturally change if the oxygen level changed, but so would anything that changed the frequency of thunderstorms themself or any other climate factor, or the type of vegetation.
The oxygen level has changed significantly enough during the history of landliving vertebrae to be reason not to worry. And as humans cope with several thousand meters with some performance degradation, but no total collapse, we wouldn't even have to worry for our own direct survival.
XAML is more about the (inherent) problems in defining UIs in HTML than how to drive those UIs to actually do stuff. Any UI done in Avalon is or could be represented in XAML, but it isn't any more sexy than a total upgrade to the old and almost-forgotten Windows resource files with their "dialog templates". It COULD be used in a browser, just like Swing in Java can be used in a browser, but it's simply a declarative way to define UIs with some similarity to the web paradigm, but some real differences, too. Think "HTML + SVG + VRML" and then throw in a Not Invented Here to change it somewhat and adapt it to the Win32 legacy. Voilà... XAML!
AFAIK, Atlas is a toolkit directed at the developer. It's server-side parts, connecting to ASP.NET and a collection of client scripts (working in Firefox...) that does the mundane stuff like hiding different ways to create a xmlhttp request and some dom differences.
I think you are wrong. If your server is exactly opposite to you on Earth, you will have to face a (very roughly) 150 ms ping for anything you do. This is only due to the theoretical speed of light in vacuum. Bandwidth might increase, but latency remains as a significant problem for static serving.
A page roundtrip will be expensive. Downloading the complete set of all data the app will ever need in one static page is also kind of expensive (even with gargantual bandwidth). Sideband data, in one form or another, seems to make a lot of sense here.
So, are you going to pipe video uncompressed over these lines? With HD we actually need the same magnitude of computing power that's provided by current CPUs, or custom chips. If we continue to desire higher quality or the same quality with lower bitrates, CPUs are still needed. And, possibly, storage.
My real reason to be weary of this is another matter -- I want to be able to control and store my own data. If all I have is a browser and any real app requires a server, which I'm not able to run, then that's not a very appealing scenario. Will enough non-geeks appreciate this?
Well, pipes are wider and CPUs faster. This enlarges the domain of "stuff you can do in really stupid ways" (that is, relatively thin client for a rich UI).
Another thing to note is that a full trend towards this, with the logical loss of not only a proprietary operating system, but a general-purpose OS of any kind on the client, could be a far more severe threat to user freedom than any "trusted computing by limiting access to ring 0" scheme...
Should they bundle the Sun JVM? After all, the were forced, as part of a verdict, to remove their own. The Sun license isn't ideal for redistribution, so you have to download it. Not a too big deal.
1. If GL renders to an off-screen buffer, we are fine. If it's some other kind of hack, it will require additional work on the compositing side. On the other hand, any card that's not able to render to arbitrary buffers won't handle Aero properly.
2. And this is more important. Most OpenGL apps expect to be able to do buffer swapping at any time, with immediate results (only, possibly, awaiting VSYNC). If application A maintains a framerate of let's say, in average, 35 fps, while the Vista engine is keeping 26 fps, and the monitor refresh is 60 Hz, we will, in the end, get suboptimal performance. Some frames will be rendered by the OpenGL app that's never used and the average latency between two frame updates will be dependent on BOTH the Vista rate and the monitor rate. This will degrade performance, unless a traditional overlay or something is allowed. That carries another problem, namely managing transparency and clipping of that surface relative to other surfaces.
Basic support only requires rendering into a texture buffer, that you can composit. But, as I said before, without some mechanism, the effective frame rate will drop. This is the case of any fullscreen back-buffering scheme (AFAIK).
Another, complicating, issue here is the fact that the complete screen is rendered through D3D in Vista. Normal Direct3D is also modified to work for in-window rendering. Full screen rendering is much simpler.
For windowed mode, the card manufacturers will have to arrange some kind of off-screen buffer rendering that is then transferred to the fullscreen back buffer. Non-matching framerates, both for in-window 3D and video is an issue for current Vista development, AFAIK.
The interesting point of a database would be to give other shops ideas about what products they should introduce, based on the success of similar introductions in shops with similar buyer patterns. In addition, one could hope that this would not be ridden by prejudice, but what actually sells well. They may not always coincide.
Well, I don't think that the main compatibility problem for 1-2-3 was command.com. cmd.exe may look like DOS, smell like DOS and crash like DOS, but it isn't DOS. NTVDM is.
If I have a blog post mentioning Acid2 as a "wishlist" and a "goal", but something they won't reach before the IE7 release, and you interpret that they don't care about passing, I think you are missing something. They could, possibly, care more. If FF still wants to pass, but not actually does so at the time of the release of IE7, then, what's the fuss? If they do, good for them. Note that it isn't enough that Gecko implements it. It has to be integrated into the actual, released, FF code, too.
In my opinion, passing Acid2 isn't a normal test you pass or not. If you pass it, you're well worth an A+ or something. If not, that doesn't have to be that you are bad. There are different ways of failing, just compare IE6 and FF, where it should be clear who is actually anywhere close.
Acid2 is a test of the CSS standard, not the standard itself. And no, Firefox doesn't pass. But the Firefox team has made it a goal TO pass, unlike the IE team which has apparently said, "screw it, we're not going to waste our time just to pass that." IE is shooting for "good enough."
From TFB (the fucking blog):
As a wish list, it is really important and useful to my team, but it isn't even intended, in my understanding, as our priority list for IE7.
We fully recognize that IE is behind the game today in CSS support. We've dug through the Acid 2 Test and analyzed IE's problems with the test in some great detail, and we've made sure the bugs and features are on our list - however, there are some fairly large and difficult features to implement, and they will not all sort to the top of the stack in IE7. I believe we are doing a much better service to web developers out there in IE7 by fixing our known bang-your-head-on-the-desk bugs and usability problems first, and prioritizing the most commonly-requested features based on all the feedback we've had.
So, they view it as a useful wishlist, they are implementing lots of stuff from it, but they don't expect full compliance for the scheduled release (which is scheduled to be long before the Vista release, possibly this year). From my perspective, this is quite a bit from "screw it, we're not going to waste our time just to pass that."
Slashdot Mirror
Yonah.
IE 7 in Vista can supposedly run in a "self-lock-down" mode that denies itself a lot of access, even more than a normal "limited user account". It's been mentioned in ieblog, just google it.
It's called free as in "no strings attached".
(On the other hand, if we assume that IIS will always give root access to the machine it's running on, maybe it could be considered redistribution of Windows itself...)
What contributes more if one part of the population (one out of 10,000) gets CTS with a 75 % chance after twenty years of keyboard use, due to a certain genetic configuration, while the other 9,999 gets it with a 1 % chance. Most cases of CTS will not carry the pre-disposing gene, but it's quite easy to show that genetics seem to be able to influence the outcome to a great deal.
We may not understand very much of the total genome, but we have a pretty good view of independent versus dependent events in probability; enough that it's a gross simplification to talk about what contributes the most.
What about systems without memory protection? Is any multitasking between a GPL app and a non-GPL disallowed? I think that it should be clear that it is the LKP that's running and requiring certain services from the kernel, not the other way round. The fact that this, in the specific case, is accomplished by running in ring 0 and, because of that, being able to access the full address space, both the current user mode app and kernel space, should be irrelevant.
Put another way, it should be comparable to installing Windows on a device where it lacks native driver support, like installing vanilla W2K on a system with LBA48 disks.
It doesn't work that way. It's totally common to reference other patents in a new one. Then, especially in the claims, you describe what you're doing is even better, and (probably) different.
98.5 could be rounded to 99, 98.5 % of 70 is exactly 68.95, so 69/70 could be rounded to 99 %... Not that I think that's exactly the case, though.
This is not to say that it wouldn't have consequences. The likelihood of natural fires after lightning strikes and other events would naturally change if the oxygen level changed, but so would anything that changed the frequency of thunderstorms themself or any other climate factor, or the type of vegetation.
The oxygen level has changed significantly enough during the history of landliving vertebrae to be reason not to worry. And as humans cope with several thousand meters with some performance degradation, but no total collapse, we wouldn't even have to worry for our own direct survival.
XAML is more about the (inherent) problems in defining UIs in HTML than how to drive those UIs to actually do stuff. Any UI done in Avalon is or could be represented in XAML, but it isn't any more sexy than a total upgrade to the old and almost-forgotten Windows resource files with their "dialog templates". It COULD be used in a browser, just like Swing in Java can be used in a browser, but it's simply a declarative way to define UIs with some similarity to the web paradigm, but some real differences, too. Think "HTML + SVG + VRML" and then throw in a Not Invented Here to change it somewhat and adapt it to the Win32 legacy. Voilà... XAML!
AFAIK, Atlas is a toolkit directed at the developer. It's server-side parts, connecting to ASP.NET and a collection of client scripts (working in Firefox...) that does the mundane stuff like hiding different ways to create a xmlhttp request and some dom differences.
A page roundtrip will be expensive. Downloading the complete set of all data the app will ever need in one static page is also kind of expensive (even with gargantual bandwidth). Sideband data, in one form or another, seems to make a lot of sense here.
My real reason to be weary of this is another matter -- I want to be able to control and store my own data. If all I have is a browser and any real app requires a server, which I'm not able to run, then that's not a very appealing scenario. Will enough non-geeks appreciate this?
Another thing to note is that a full trend towards this, with the logical loss of not only a proprietary operating system, but a general-purpose OS of any kind on the client, could be a far more severe threat to user freedom than any "trusted computing by limiting access to ring 0" scheme...
Should they bundle the Sun JVM? After all, the were forced, as part of a verdict, to remove their own. The Sun license isn't ideal for redistribution, so you have to download it. Not a too big deal.
1. If GL renders to an off-screen buffer, we are fine. If it's some other kind of hack, it will require additional work on the compositing side. On the other hand, any card that's not able to render to arbitrary buffers won't handle Aero properly.
2. And this is more important. Most OpenGL apps expect to be able to do buffer swapping at any time, with immediate results (only, possibly, awaiting VSYNC). If application A maintains a framerate of let's say, in average, 35 fps, while the Vista engine is keeping 26 fps, and the monitor refresh is 60 Hz, we will, in the end, get suboptimal performance. Some frames will be rendered by the OpenGL app that's never used and the average latency between two frame updates will be dependent on BOTH the Vista rate and the monitor rate. This will degrade performance, unless a traditional overlay or something is allowed. That carries another problem, namely managing transparency and clipping of that surface relative to other surfaces.
Basic support only requires rendering into a texture buffer, that you can composit. But, as I said before, without some mechanism, the effective frame rate will drop. This is the case of any fullscreen back-buffering scheme (AFAIK).
For windowed mode, the card manufacturers will have to arrange some kind of off-screen buffer rendering that is then transferred to the fullscreen back buffer. Non-matching framerates, both for in-window 3D and video is an issue for current Vista development, AFAIK.
It's not like there ought to have been at least a few asteroids or comets with a strange enough orbit to run into it already?
The interesting point of a database would be to give other shops ideas about what products they should introduce, based on the success of similar introductions in shops with similar buyer patterns. In addition, one could hope that this would not be ridden by prejudice, but what actually sells well. They may not always coincide.
It's called "only tested on IE". (IE will render ' ' as a non-breaking space.)
Well, I don't think that the main compatibility problem for 1-2-3 was command.com. cmd.exe may look like DOS, smell like DOS and crash like DOS, but it isn't DOS. NTVDM is.
In my opinion, passing Acid2 isn't a normal test you pass or not. If you pass it, you're well worth an A+ or something. If not, that doesn't have to be that you are bad. There are different ways of failing, just compare IE6 and FF, where it should be clear who is actually anywhere close.
Acid2 is a test of the CSS standard, not the standard itself. And no, Firefox doesn't pass. But the Firefox team has made it a goal TO pass, unlike the IE team which has apparently said, "screw it, we're not going to waste our time just to pass that." IE is shooting for "good enough."
From TFB (the fucking blog):
As a wish list, it is really important and useful to my team, but it isn't even intended, in my understanding, as our priority list for IE7.
We fully recognize that IE is behind the game today in CSS support. We've dug through the Acid 2 Test and analyzed IE's problems with the test in some great detail, and we've made sure the bugs and features are on our list - however, there are some fairly large and difficult features to implement, and they will not all sort to the top of the stack in IE7. I believe we are doing a much better service to web developers out there in IE7 by fixing our known bang-your-head-on-the-desk bugs and usability problems first, and prioritizing the most commonly-requested features based on all the feedback we've had.
So, they view it as a useful wishlist, they are implementing lots of stuff from it, but they don't expect full compliance for the scheduled release (which is scheduled to be long before the Vista release, possibly this year). From my perspective, this is quite a bit from "screw it, we're not going to waste our time just to pass that."