Most light microscopes used for any sensible purpose are illuminating a thin-slice object prepared on a glass plate from underneath, going into the lense system. This is not that easy to do in space, with robotics. Instead, we would probably just have a nice camera with good optical zoom looking at a target. That's something quite different, and I guess it's one reason why higher resolution might be harder. You also have to remember that if these microbes are as small as the smallest archeas on Earth (or as small as the ones speculated to be found in Mars rock found on Earth), a light microscope may not be enough to capture it at all, simply due to the wavelength and the simple physical limits.
You see, the project is Phoenix now, but it will change to Firebird and then Firefox within a few years due to IP issues. They've already prepared the logo for this.
If it's a direct enough mapping, I can't imagine why emacs couldn't be modded to handle it almost too easily. Run-length encoding of indentation whitespace, if there is any, back-referencing by number of previous name entities and you already have significant savings in a way that could be undone with a few regexps!
Well, I think it just shows that there is some point in continuing the performance race. Naturally applying extra compression upon JPEGs is not a killer app anyway, but compression in many forms can continue to give us significant advances if we just allow more horsepower to be thrown at the problem (combined with ingenious algorithms, of course).
Nice to see an explanation that good old V86 is not available anymore. What I begin to wonder is if vmware or other virtualization-without-emulation software will be able to run 16-bit code under these conditions? Will the only way really be a bochs-like emulation? Naturally, there are many other packages with better performance than bochs, but it's still far more than vmware or its siblings.
Regarding installers, I think the official line is that most of these installers are of a few common types, and that there will be replacement programs hooking in transparently for those. This means you don't need a patch for the specific program you want to install, "just" for the installer creator (InstallShield x.x and the like) that was used.
I'm still surprised by the move to leave 16-bit out, though. I wouldn't have thought that it was that complicated, but maybe it gets much easier somehow to leave V86 mode out.
Then I guess my parent had no point at all, there is no inherent lesser safety in code that uses a new interface unless the interface is really broken, compared to reimplementing an old and "proven" one like the great function strcpy! (Not insecure in itself, but...)
How many IE exploits can you enumerate that gives you root if it's run as a limited user? Some have been discovered, but most are not and never have been. I would say that the general IE bug is one or two levels; spoofing your site identity as a trusted site to the user or the browser itself; from that trusted site download code and run it in the user context of the user running IE. From there on, a local root explot can come in handy to give you root.
Disclaimer: I know this is not the only way, but it is quite common.
IMHO, this seems more related to the internal process management data structures/memory management. Naturally, there are interfaces that are more inherently unsafe because they are complicated to implement or synchronize, but this just seems to be a bug that would be just as likely to happen in any part initializing memory mapping data.
The fact that the functionality hasn't been there all of the history of Linux could be a reason to trust it less, but then we should probably avoid using anything above 2.2 (or 2.0, or...) at all. The fact that some function signatures mimic those of original UNIX and some don't seems quite irrelevant to me.
Is there ever a time when you can consider your systems secure against an attacker with physical access?
No, but combine any buffer overflow with arbitrary code execution exploit, running as a low privilege user and any local-only privilege elevation exploit...
As this exploit is mainly at load-time, I imagine a buffer overflow to use it would be in a few steps:
Get your code loaded through the remote exploit.
Download another file with the privilege elevation code and the real nasty stuff you want to set up.
Call system or exec with your newly created file.
?????
Profit!
The only good thing about this is that we surely could claim that this is enough of a derivative work upon the kernel that the source for the exploitation code should be published!
Of course, this requires the exploitation code to in a small space find out some place where the user is allowed to write a binary and give it execute permission. "~/" should generally work and chmodding isn't that hard...
They will truely be quite sensational if they it's cheaper to put up a new factory and manufacture one million FED displays than just cranking out another million from an existing LCD fab.
An example of that they are serious to some degree is that all the stuff in the latest releases of the DirectX SDK have both x86 and x64 binary directories. (It's not like you would find ia64 directories there by default.)
Compaq killed Windows 2000 for Alpha in something like July 1999, just as your parent wrote. Up to release candidates, the work was done in parallel. Then, Compaq dropped their support for NT on Alpha and it didn't make sense for Microsoft to carry on.
Of course, you are right in that the final kill of Alpha came later on, but even Netcraft could see the way it seemed to be going.
True, but even as x86-64 (or whatever you call it) has added more registers, which is a more important reason for the performance boon than the 64-bitness per se, there are parts of the architecture that makes it hard to optimize for the CPU. Encoding of "hints" in branches and bundles that can always be run in parallel without the processor checking seems like a good idea, to some degree. Maybe the conversion into microcode will be more complex, almost Transmeta-like, in future "x86" chips.
AFAIK, all services are listed in HKLM\System\CurrentControlSet\Services. In other words, it's admin-only. Some interaction is allowed indirectly, but if there is a hole to install a new service as limited user exploited in the wild in spyware, that's interesting.
Case-in-point is the support wires in Sony Trinitron monitors. Very, very fine horizontal lines at the 1/3 and 2/3 levels on the screen are used to hold a mesh in place which gives the Trinitron series a great display. Every Trinitron style screen I've ever sold, I got asked, immediately, what the story was with the lines. Most customers balked somewhat, but all eventually agreed to live with it.
Yeah, but I have to admit that those are quite a bit more obvious than my one true stuck-on glaring red pixel, which annoys me a bit. It's the second in a dual mon config and it was only after discovering that red pixel that I found a dead blue sub-pixel on the other monitor, which was a few months old back then. I'm still happy with them, though, despite my primary use is text editing (natural language and source).
I would naturally be willing to pay some kind of price premium if my options were ordering a display risking a really annoying set of dead pixels or inspecting the screen beforehand onsite/being promised a generous return policy.
BTW, doesn't this Korea only policy mean that we could risk being "flooded" with "bad" Samsung displays in other territories now? (In Korea, only old people have dead pixels.)
The real question is why we should judge from current Longhorn builds regarding anything at all. Important bits and pieces, especially in userland, was changed and/or added quite late in the game in both Windows 2000 and XP. They obviously didn't come out of nowhere, but they were not in the normal build tree.
Slashdot Mirror
The scary part is that a do-it-all-pseudo-OOP language has taken a great share of the market compared to 15 years ago (Java)...
Of course, the proper spelling is Sisko, at least on Terok Nor.
Most light microscopes used for any sensible purpose are illuminating a thin-slice object prepared on a glass plate from underneath, going into the lense system. This is not that easy to do in space, with robotics. Instead, we would probably just have a nice camera with good optical zoom looking at a target. That's something quite different, and I guess it's one reason why higher resolution might be harder. You also have to remember that if these microbes are as small as the smallest archeas on Earth (or as small as the ones speculated to be found in Mars rock found on Earth), a light microscope may not be enough to capture it at all, simply due to the wavelength and the simple physical limits.
You see, the project is Phoenix now, but it will change to Firebird and then Firefox within a few years due to IP issues. They've already prepared the logo for this.
If it's a direct enough mapping, I can't imagine why emacs couldn't be modded to handle it almost too easily. Run-length encoding of indentation whitespace, if there is any, back-referencing by number of previous name entities and you already have significant savings in a way that could be undone with a few regexps!
Well, I think it just shows that there is some point in continuing the performance race. Naturally applying extra compression upon JPEGs is not a killer app anyway, but compression in many forms can continue to give us significant advances if we just allow more horsepower to be thrown at the problem (combined with ingenious algorithms, of course).
Nice to see an explanation that good old V86 is not available anymore. What I begin to wonder is if vmware or other virtualization-without-emulation software will be able to run 16-bit code under these conditions? Will the only way really be a bochs-like emulation? Naturally, there are many other packages with better performance than bochs, but it's still far more than vmware or its siblings.
I'm still surprised by the move to leave 16-bit out, though. I wouldn't have thought that it was that complicated, but maybe it gets much easier somehow to leave V86 mode out.
Then I guess my parent had no point at all, there is no inherent lesser safety in code that uses a new interface unless the interface is really broken, compared to reimplementing an old and "proven" one like the great function strcpy! (Not insecure in itself, but...)
It's like (unhacked) DVD regions, you can only change them so many times, then you have to stick to what you've got.
How many IE exploits can you enumerate that gives you root if it's run as a limited user? Some have been discovered, but most are not and never have been. I would say that the general IE bug is one or two levels; spoofing your site identity as a trusted site to the user or the browser itself; from that trusted site download code and run it in the user context of the user running IE. From there on, a local root explot can come in handy to give you root.
Disclaimer: I know this is not the only way, but it is quite common.
The fact that the functionality hasn't been there all of the history of Linux could be a reason to trust it less, but then we should probably avoid using anything above 2.2 (or 2.0, or...) at all. The fact that some function signatures mimic those of original UNIX and some don't seems quite irrelevant to me.
As this exploit is mainly at load-time, I imagine a buffer overflow to use it would be in a few steps:
Get your code loaded through the remote exploit.
Download another file with the privilege elevation code and the real nasty stuff you want to set up.
Call system or exec with your newly created file.
?????
Profit!
The only good thing about this is that we surely could claim that this is enough of a derivative work upon the kernel that the source for the exploitation code should be published!
Of course, this requires the exploitation code to in a small space find out some place where the user is allowed to write a binary and give it execute permission. "~/" should generally work and chmodding isn't that hard...
Bah, just use a tachyon burst followed by a concentrated tetryon beam.
An example of that they are serious to some degree is that all the stuff in the latest releases of the DirectX SDK have both x86 and x64 binary directories. (It's not like you would find ia64 directories there by default.)
Of course, you are right in that the final kill of Alpha came later on, but even Netcraft could see the way it seemed to be going.
True, but even as x86-64 (or whatever you call it) has added more registers, which is a more important reason for the performance boon than the 64-bitness per se, there are parts of the architecture that makes it hard to optimize for the CPU. Encoding of "hints" in branches and bundles that can always be run in parallel without the processor checking seems like a good idea, to some degree. Maybe the conversion into microcode will be more complex, almost Transmeta-like, in future "x86" chips.
They could possibly mean per physical rotating disk. You can cram three or four of them in one normal "disk drive" enclosure.
Two of these would actually leave 92 MB missing to a full 1 TB.
Don't forget SpaceShipOne (but I doubt it reuses disposed rubber).
AFAIK, all services are listed in HKLM\System\CurrentControlSet\Services. In other words, it's admin-only. Some interaction is allowed indirectly, but if there is a hole to install a new service as limited user exploited in the wild in spyware, that's interesting.
I would naturally be willing to pay some kind of price premium if my options were ordering a display risking a really annoying set of dead pixels or inspecting the screen beforehand onsite/being promised a generous return policy.
BTW, doesn't this Korea only policy mean that we could risk being "flooded" with "bad" Samsung displays in other territories now? (In Korea, only old people have dead pixels.)
The real question is why we should judge from current Longhorn builds regarding anything at all. Important bits and pieces, especially in userland, was changed and/or added quite late in the game in both Windows 2000 and XP. They obviously didn't come out of nowhere, but they were not in the normal build tree.