I would bet that the access time (basically none compared to a spinning disk) would help many common applications where disk access matteres, like application start.
Opening the box, reconfiguring drivers, etc. Depending on the performance curve, you can also end up with better performance for the most part of those 3 years, while saving that labor.
(And, yeah, it may be fun to poke inside a machine...)
This is not any project. Well, there have been some security issues in OpenSSH, that's true. The OpenBSD software altogether is very well known for its security. It would be hard for any new maintainer to get the needed credibility, and to actually maintain and develop the code in a safe and efficient manner. It's not like a new maintainer for some uncommon piece of hardware.
If you want slave-like labor, it could just as well (possibly easier) be realized through suitable enhancement and control over biological organisms, at least in some cases. I hope for fusion as much as anyone, but on the other hand modified photosynthesis (that is, properly modified to harness the H+ transport into proper electricity, without waste into growing elaborate structures that we don't really need) could provide loads of energy.
But, if we view this as the century of biology, imagine what kind of data analysis will be possible on that material when IT develops further. Imagine the transformation of society if genetic modification of humans got commonplace in the 2040's. Imagine what combined organic/electronic implants could do.
What's this "hard drive" you're speaking of, when you have access to that kind of bandwidth? (Oh, and I'm clearly in the "I want to own my own data" camp, just not in the "streaming is impossible" camp...)
If they were elaborate, they would ask the firmware to pump every single bit back out of it. It would be quite a feat to compress it enough to fit in the code to give a fake image of itself, not just a fake version number, and do the real hack. Especially if MS decides to release an update where any non-used zero bytes are replaced by uncompressable noise.
Well, it doesn't help that much, as it's the signature that determines how a valid image may be started (and no commercial game will say "burned booting OK"). Now, all software written by MS really "sees" the disc as a real DVD, completely independent of whether booting from burned DVDs is supported or not. The only way to block this would be to block flashing DVD firmware (wise) or blocking reading burned discs in hardware. The latter would of course make it less usable for playing CDs or video in more or less legitimate ways that MS still wants to support.
The not-so-obvious thing here is if the player itself signs data making it different each time it's read. The irony of DVD was that it was a piece of cake (more or less) to rip a copy and burn it on another DVD, it was just transcoding or playing the DVD with an unauthorized player that could be tricky.
General purpose as in "other massively parallel computations, sometimes with somewhat sloppy precision requirements", not as in "massive databases". Scientific computing, yes, sometimes with precision problems. Helping your server to survive/.ing, no.
I hacked away at Bochs a few weeks ago to just try loading a user-mode process, attaching Bochs (in Windows) through a DLL and then continue to run all threads, now emulated. All syscalls were handed off to the real kernel. That was not hard to do. Of course, a full kernel takes more job (the interrupts while making the move are tricky), but it's far from impossible. Just don't try to virtualize some other hardware than what's really there, just mask off the little area of memory where you live as something innocent.
But usermode systems doing a lot of work and then handing over to what's more or less a miniport, is. If you call it a driver or not is a matter of background and taste.
Hey, just as many people think that XP is still DOS-based as those who think it really is OS/2, when the truth is that it's VMS targeted at running OS/2 and DOS apps!
Well, it IS interesting. I remember reading in textbooks that the genetic evidence of divergence between the groups of mammals (with some assumptions on mutation rate and so on) indicate a far earlier divergence, than the fossilic evidence does. From what I remember of those, a mammal this "original" that far back fits better with the genetic data. (which shouldn't surprise anyone, really, but a confirmation is certainly nice)
I was under the impression that it, anyway, is usually more efficient to use a quickly oscillating crystal and then gate that to on and off. A capacitor construction after that will "smooth out" the square-wavish original signal. This is, for example, how you can set the DC voltage to your CPU. In contrast, getting a good efficiency in a simple transformer is actually kind of hard, if you want it to handle any impedance/DC load. If it's good at full load, it will waste energy if nothing is plugged in. If you have noticed, new transformers/chargers generally stay cool when plugged in, if they are not connected to the DC device, while older ones don't.
Well, the actual transition between power states is controlled by both the OS and the BIOS. We also have the interesting fact that the actual time spent in C3 is reported incorrectly by the common way to do it in Windows. This is highly hypothetical, but it would be possible that some code checks "am I running in C3 now, if so, poll less extensively" and that the BIOS is responsible for reporting the C3 state incorrectly.
One could argue that keeping USB2 devices plugged for long in a laptop running on battery is a kind of new scenario. The issue is also aggrevated on a dual core machine, as the need for "deep sleep" on one of the cores is actually a quite common scenario there, whereas the effects on a single-core older Pentium M is less pronounced (especially if you're using the system for anything, like playing a MP3, which will prevent your system from going to that level of power saving most of the time anyway).
OS/2 shares a few design decisions with the NT kernel. The NT kernel used to have a "personality" (just like the Posix and the more famous, Win32, one) to run a small subset of OS/2 console applications in Windows NT. At one point, of course, NT was supposed to be primarly an OS/2 successor, instead of a Windows 3(.1) one. This means that a lot of data structures and so on are similar, where it really doesn't matter, just to make it familiar to user application developers.
The fact that the current Linux hack doesn't successfully run a GUI yet makes me wonder if it won't be that easy. They seem to be doing PCI enumeration correctly, but they still are not talking to the video card.
Or maybe the Intel Macs use non-VGA video card BIOS. (That would mean that the current console display is done completely through some kind of EFI API.)
I think it's reasonable to assume that it's too dim to just point-and-shoot a picture. That can still be plenty enough if you can get a really dark room.
Slashdot Mirror
I would bet that the access time (basically none compared to a spinning disk) would help many common applications where disk access matteres, like application start.
(And, yeah, it may be fun to poke inside a machine...)
This is not any project. Well, there have been some security issues in OpenSSH, that's true. The OpenBSD software altogether is very well known for its security. It would be hard for any new maintainer to get the needed credibility, and to actually maintain and develop the code in a safe and efficient manner. It's not like a new maintainer for some uncommon piece of hardware.
But, if we view this as the century of biology, imagine what kind of data analysis will be possible on that material when IT develops further. Imagine the transformation of society if genetic modification of humans got commonplace in the 2040's. Imagine what combined organic/electronic implants could do.
What's this "hard drive" you're speaking of, when you have access to that kind of bandwidth? (Oh, and I'm clearly in the "I want to own my own data" camp, just not in the "streaming is impossible" camp...)
If they were elaborate, they would ask the firmware to pump every single bit back out of it. It would be quite a feat to compress it enough to fit in the code to give a fake image of itself, not just a fake version number, and do the real hack. Especially if MS decides to release an update where any non-used zero bytes are replaced by uncompressable noise.
Well, it doesn't help that much, as it's the signature that determines how a valid image may be started (and no commercial game will say "burned booting OK"). Now, all software written by MS really "sees" the disc as a real DVD, completely independent of whether booting from burned DVDs is supported or not. The only way to block this would be to block flashing DVD firmware (wise) or blocking reading burned discs in hardware. The latter would of course make it less usable for playing CDs or video in more or less legitimate ways that MS still wants to support.
The not-so-obvious thing here is if the player itself signs data making it different each time it's read. The irony of DVD was that it was a piece of cake (more or less) to rip a copy and burn it on another DVD, it was just transcoding or playing the DVD with an unauthorized player that could be tricky.
General purpose as in "other massively parallel computations, sometimes with somewhat sloppy precision requirements", not as in "massive databases". Scientific computing, yes, sometimes with precision problems. Helping your server to survive /.ing, no.
I hacked away at Bochs a few weeks ago to just try loading a user-mode process, attaching Bochs (in Windows) through a DLL and then continue to run all threads, now emulated. All syscalls were handed off to the real kernel. That was not hard to do. Of course, a full kernel takes more job (the interrupts while making the move are tricky), but it's far from impossible. Just don't try to virtualize some other hardware than what's really there, just mask off the little area of memory where you live as something innocent.
But usermode systems doing a lot of work and then handing over to what's more or less a miniport, is. If you call it a driver or not is a matter of background and taste.
Hey, just as many people think that XP is still DOS-based as those who think it really is OS/2, when the truth is that it's VMS targeted at running OS/2 and DOS apps!
Sure, because you would thrive in a more energy-rich temperature, say 900 K.
Well, it IS interesting. I remember reading in textbooks that the genetic evidence of divergence between the groups of mammals (with some assumptions on mutation rate and so on) indicate a far earlier divergence, than the fossilic evidence does. From what I remember of those, a mammal this "original" that far back fits better with the genetic data. (which shouldn't surprise anyone, really, but a confirmation is certainly nice)
So what? Just because it's a protocol/interface doesn't mean it will allow unauthorized DMA.
How is the fact that Sony has already paid the research relevant for the fact that they want/need return on that investment?
I, for one, await Space Race 3.1, with TrueType support.
I was under the impression that it, anyway, is usually more efficient to use a quickly oscillating crystal and then gate that to on and off. A capacitor construction after that will "smooth out" the square-wavish original signal. This is, for example, how you can set the DC voltage to your CPU. In contrast, getting a good efficiency in a simple transformer is actually kind of hard, if you want it to handle any impedance/DC load. If it's good at full load, it will waste energy if nothing is plugged in. If you have noticed, new transformers/chargers generally stay cool when plugged in, if they are not connected to the DC device, while older ones don't.
Well, the actual transition between power states is controlled by both the OS and the BIOS. We also have the interesting fact that the actual time spent in C3 is reported incorrectly by the common way to do it in Windows. This is highly hypothetical, but it would be possible that some code checks "am I running in C3 now, if so, poll less extensively" and that the BIOS is responsible for reporting the C3 state incorrectly.
One could argue that keeping USB2 devices plugged for long in a laptop running on battery is a kind of new scenario. The issue is also aggrevated on a dual core machine, as the need for "deep sleep" on one of the cores is actually a quite common scenario there, whereas the effects on a single-core older Pentium M is less pronounced (especially if you're using the system for anything, like playing a MP3, which will prevent your system from going to that level of power saving most of the time anyway).
BTW, what's "unsolid" about the NT kernel itself?
Or maybe the Intel Macs use non-VGA video card BIOS. (That would mean that the current console display is done completely through some kind of EFI API.)
I think it's reasonable to assume that it's too dim to just point-and-shoot a picture. That can still be plenty enough if you can get a really dark room.