If the rack is passively cooled today, sure, go on and try it. If it's actively cooled, you can only gain in total energy efficiency if you're replacing a bad heat conductor with a better heat conductor, which is also capable of generating power. If you can do that, you should have been able to put an even better heat conductor there in the first place, and by doing so avoiding a few fan revolutions.
(Hint: an unpowered Peltier cooler will make a very bad heat sink. It might be able to power its own status LED, if the LED also happens to have reversed polarity, though.)
With this glorious speed it'll advance almost 10 meters in 668 sols (one Martian year), not including any need to power down during the winter... I really hope they get it going again. As one with some experience with stuck IBM Deathstar harddrives, I know of all the desperation!
From what I can gather, this seems anaerobic, that is, no oxygen needed. But, this has some side effects. Depending on the method used, there may be a real problem with the side products from the cell (remember, normal anaerobic processes lead to lactic acid or alcohol, I don't want to get drunk or anything by running my laptop... or my Picard-style heart).
In addition, the power leveraged gets very low compared to a process where oxygen is involved, something on the scale of 5 %. Running a heart in that way, combined with the possibility that the body may spend more energy than first developed to destroy the side products, is not a very nice scenario. For sensors and the like, this doesn't matter. For a serious power-drawing implant, or to lose weight, this is a problem. You don't want to force the liver to process those amounts continously, which may be the effect, depending on what really happens to the glucose.
It wouldn't even be to hard to implement this on top of current ACL systems. Just create the equivalent of a fake user, based on the current user and some group memberships. The group memberships would mostly implicate "deny" permissions for different sensitive resources (from most about anything up to a level of access almost equivalent to your own).
How hard is it to realize that you can write a user mode virus with no special exploit other than a user tendency to run unknown executables? You can warn the user against it. But, with the current paradigm of "every program inherits the permissions of the logged in user" (which includes most open OSes), you can't protect the user from himself.
For this reason, I think that code signing, with the user being able to sign his/her own code for full access, or disabling the signing requirement, would be a good development. Most apps shouldn't be able to do everything you can do with the computer. You can naturally keep a very limited account around and run everything under it, but that process could be automated. There is nothing making application-level security, to some degree, impossible. This is a design issue, but it's been this way since day 1 of UNIX and no mainstream system has really changed it, so far.
Java's sandbox has some of it, for example, but there is no need to emulate in byte code just to get this kind of behavior.
And I look back to Netscape, which at the same time they were actually getting another big graphic browser competitor, tried to start charging money for the browser...
Speculation would say that it's quite hard to fix in the OS. If this is some kind of general flaw allowing access to all memory the another thread is allowed to access, one would basically have to make sure that the other virtual CPU is idle before entering ring 0 at any system call. That, in turn, could maybe be accomplished by sending an interrupt somehow to the other CPU, but a system call is supposed to be cheap.
What Intel might hope for is that this is fixable in microcode. If not, well, then there's real trouble.
Is the price of hardware that highly differentiated that you get a state-of-the-art P4 desktop machine, with no Windows, for $200 in India?
Ruling out all P4s and old Athlons may be a bit excessive, but do you truly say that those CPUs ruled out by this limit would be an option in a system at this price point?
It's not like XP defaults to not showing a blue screen, but only writing a mini-dump and rebooting. And, yeah, when troubleshooting over the phone, this is a PITA. (Just telling them to look at the dump file is often not an option.)
Anyway, you can also turn off a device driver to make a Windows system completely unable to show the blue screen. I think the embedded version has a few more options.
Anyway, what you ask for exists. I would suspect that the error messages in public environments are generally less severe than a BSOD, though.
I actually want to disagree here. A static picture is quite alike, but take things like quick searching, but also "tool tips"/autocompletion. Yes, they rely on eye candy, but the point is that you can just point or write ahead and the computer will provide you with some kind of useful information while you do so.
Heck, even a toolbar may be put in this category. It's a shortcut, it was available within the GUI anyway, but it's pretty useful. And the context menu, no matter what platform, often comes in quite handily. All these are incremental things. They wouldn't have worked on the original Mac. Putting them in on the original Mac, even with the processing power of today, would have meant serious additional development work.
We're still relying on the same metaphor, but the execution is far better. The presence of the web browser as a general way of presenting jsut about every kind of material is also, IMHO, significant enough to view it as a real change in the user interface. Not in the graphical way, but in how you interact with the GUI and what you expect from it. It's the interface between you and the machine, not the display alone.
A bit like it would be better to just teleport people than going with your typical airline?
It's hard enough to grow some kinds of human cells, and growing them in an orderly fashion to get the exactness necessary for something like normal vision, is very far away right now. I think it's quite likely that an artificial implant with a good interface will be a good-enough, or even better-than-original solution.
If you use a dual monitor configuration in Windows today, it's actually possible to disable one card, update its driver and reenable it, at least in some cases. I think one of the real problems is that Windows doesn't like the prospect of temporarily having no GUI console.
It ran and was kind of usable with 4 MB on a 486 DX 33. I think the difference to a 120 MHz system may be that the memory gets to be a much more central bottleneck in that system, compared to an overall crippled machine.
And, yeah, XP runs fine with 128 MB. Just open a few apps at a time. It doesn't match my usage, but a simple "check mail, process words in plain documents" person is probably quite satisfied, at least 'til you tell them about the difference 256 will bring.
We can't even be sure that they were an advantage. Cache and memory is precious. Some code, still, gets slower on AMD64, despite new registers and all, just because we've doubled the pointer size and that means more data transfers. The CPU is faster than before and can handle loads of memory, but if you are not running out of space, whether it is virtual address space or physical memory, there are no benefits of 64-bit addressing. Every address is bigger, without any benefit.
But, I think the time might be now, after all. If more people got used to the idea of just memory mapping their data, that could really bring some benefits. And, as it happens, their data may be several hundred MBs, at least. The 32-bit memory space is crammed. Also look at Windows, which without an automatic rebasing creates quite a few relocation conflicts that needs to be resolved at load time. Without any real need for it...
A 64-bit recompile of a thirty-two bit extension...
On the other hand, it's not only a recompile. They disallowed some practices for drivers (made a few structures write-protected after boot and so on), but to fit your kind of description, I think a recompile fits quite well...
I think that you can do really clean things in.NET, especially if you don't touch GUI. That may sound like a joke, but you can write all kinds of stuff without relying on a single COM object or Win32 call on your own. The current WinForms interface, on the other hand, is a thin wrapper to how UI works in Win32.
On the other hand, the problem of a general, cross-platform interface to differing real GUI frameworks is not a simple one. I don't know if I would say that Swing has succeeded, as GUI Java is terrible (in most incarnations).
Microsoft made a choice of not reinventing their GUI in.NET. It would be somewhat surprising to do so in a 24 MB addition framework. I don't agree on the analysis that Avalon is severly dragged back by its Win32/USER/GDI heritage. True, there are HWNDs around, and you can use them if you ask to. There is, however, much less reason to do so. In WinForms, you'll have to go "out" to Win32 and do it yourself to get many things done. In Avalon, the USER32 representation of the window will not tell you much you didn't know already, and the USER32 calls won't help you much to accomplish new things. Think about it like Swing or whatever, just that you have much more work into making the drawing fast and doing away with the paradigm that a region refresh operation is something best handled by the original creator of the GUI. "Declarative UI definitions" are much nicer, most of the time...
It's actually quite interesting. Try searching for C#, K#, respectively. Then try C++, K++. Obviously, for ++, they made it into a letter-like symbol (while a single + isn't). For #, they added (at least) C# and J#, but not the general symbol as aletter. (J# is the Microsoft wrapper for compiling Java 1.1 code, plus some Swing support, into running under the.NET framework. One nice thing about it is that it's able to binary serialize into Java-compatible stuff, so if you need to fix interoperability, that's a safe bet.)
12 years ago, there was no Yahoo (and, depending on definition, no web to speak of, so an interface to web searches and categories would have been a funny thing, that's for sure). You don't start and build a user base by providing a rich API. You start by providing a web site...
Slashdot Mirror
Imagine a Beowulf cluster of those.
(Hint: an unpowered Peltier cooler will make a very bad heat sink. It might be able to power its own status LED, if the LED also happens to have reversed polarity, though.)
I don't think the batteries are designed to provide enough power for it to even transmit properly during that time, let alone powering the motors.
With this glorious speed it'll advance almost 10 meters in 668 sols (one Martian year), not including any need to power down during the winter... I really hope they get it going again. As one with some experience with stuck IBM Deathstar harddrives, I know of all the desperation!
In addition, the power leveraged gets very low compared to a process where oxygen is involved, something on the scale of 5 %. Running a heart in that way, combined with the possibility that the body may spend more energy than first developed to destroy the side products, is not a very nice scenario. For sensors and the like, this doesn't matter. For a serious power-drawing implant, or to lose weight, this is a problem. You don't want to force the liver to process those amounts continously, which may be the effect, depending on what really happens to the glucose.
It wouldn't even be to hard to implement this on top of current ACL systems. Just create the equivalent of a fake user, based on the current user and some group memberships. The group memberships would mostly implicate "deny" permissions for different sensitive resources (from most about anything up to a level of access almost equivalent to your own).
For this reason, I think that code signing, with the user being able to sign his/her own code for full access, or disabling the signing requirement, would be a good development. Most apps shouldn't be able to do everything you can do with the computer. You can naturally keep a very limited account around and run everything under it, but that process could be automated. There is nothing making application-level security, to some degree, impossible. This is a design issue, but it's been this way since day 1 of UNIX and no mainstream system has really changed it, so far.
Java's sandbox has some of it, for example, but there is no need to emulate in byte code just to get this kind of behavior.
I hope your goal was to be modded funny, not insightful...
And I look back to Netscape, which at the same time they were actually getting another big graphic browser competitor, tried to start charging money for the browser...
What Intel might hope for is that this is fixable in microcode. If not, well, then there's real trouble.
What part of postdates in the (grand)*grandparent do you need explained?
Ruling out all P4s and old Athlons may be a bit excessive, but do you truly say that those CPUs ruled out by this limit would be an option in a system at this price point?
Anyway, you can also turn off a device driver to make a Windows system completely unable to show the blue screen. I think the embedded version has a few more options.
Anyway, what you ask for exists. I would suspect that the error messages in public environments are generally less severe than a BSOD, though.
Wouldn't Pacman be the ultimate example of intelligent design?
Heck, even a toolbar may be put in this category. It's a shortcut, it was available within the GUI anyway, but it's pretty useful. And the context menu, no matter what platform, often comes in quite handily. All these are incremental things. They wouldn't have worked on the original Mac. Putting them in on the original Mac, even with the processing power of today, would have meant serious additional development work.
We're still relying on the same metaphor, but the execution is far better. The presence of the web browser as a general way of presenting jsut about every kind of material is also, IMHO, significant enough to view it as a real change in the user interface. Not in the graphical way, but in how you interact with the GUI and what you expect from it. It's the interface between you and the machine, not the display alone.
It's hard enough to grow some kinds of human cells, and growing them in an orderly fashion to get the exactness necessary for something like normal vision, is very far away right now. I think it's quite likely that an artificial implant with a good interface will be a good-enough, or even better-than-original solution.
Yeah, let's post a 3.2 MB video link directly from the blurb...
If you use a dual monitor configuration in Windows today, it's actually possible to disable one card, update its driver and reenable it, at least in some cases. I think one of the real problems is that Windows doesn't like the prospect of temporarily having no GUI console.
Yeah, MacOS X obviously lacks a kernel mode, and there are obviously no graphics drivers.
And, yeah, XP runs fine with 128 MB. Just open a few apps at a time. It doesn't match my usage, but a simple "check mail, process words in plain documents" person is probably quite satisfied, at least 'til you tell them about the difference 256 will bring.
But, I think the time might be now, after all. If more people got used to the idea of just memory mapping their data, that could really bring some benefits. And, as it happens, their data may be several hundred MBs, at least. The 32-bit memory space is crammed. Also look at Windows, which without an automatic rebasing creates quite a few relocation conflicts that needs to be resolved at load time. Without any real need for it...
On the other hand, it's not only a recompile. They disallowed some practices for drivers (made a few structures write-protected after boot and so on), but to fit your kind of description, I think a recompile fits quite well...
On the other hand, the problem of a general, cross-platform interface to differing real GUI frameworks is not a simple one. I don't know if I would say that Swing has succeeded, as GUI Java is terrible (in most incarnations).
Microsoft made a choice of not reinventing their GUI in .NET. It would be somewhat surprising to do so in a 24 MB addition framework. I don't agree on the analysis that Avalon is severly dragged back by its Win32/USER/GDI heritage. True, there are HWNDs around, and you can use them if you ask to. There is, however, much less reason to do so. In WinForms, you'll have to go "out" to Win32 and do it yourself to get many things done. In Avalon, the USER32 representation of the window will not tell you much you didn't know already, and the USER32 calls won't help you much to accomplish new things. Think about it like Swing or whatever, just that you have much more work into making the drawing fast and doing away with the paradigm that a region refresh operation is something best handled by the original creator of the GUI. "Declarative UI definitions" are much nicer, most of the time...
It's actually quite interesting. Try searching for C#, K#, respectively. Then try C++, K++. Obviously, for ++, they made it into a letter-like symbol (while a single + isn't). For #, they added (at least) C# and J#, but not the general symbol as aletter. (J# is the Microsoft wrapper for compiling Java 1.1 code, plus some Swing support, into running under the .NET framework. One nice thing about it is that it's able to binary serialize into Java-compatible stuff, so if you need to fix interoperability, that's a safe bet.)
12 years ago, there was no Yahoo (and, depending on definition, no web to speak of, so an interface to web searches and categories would have been a funny thing, that's for sure). You don't start and build a user base by providing a rich API. You start by providing a web site...