You are seriously confused.:-) I am short SCOX and have held a part of my short position for over a year. Indeed, an advantage of taking a short position vs. buying put options is that you can generally hold your short position if the stock takes longer to tank than you anticipated, while options have a fixed expiration date. Of course, as has been mentioned, there are no options on SCOX anyway.
OS X 10.2 has been shipping with new Macs for over a week.
It feels a lot snappier. I've installed it on a blue&white G3/300, and even without the boost from Quartz Extreme (which requires AGP and Radeon/GeForce or better) the GUI has picked up speed. The Finder is MUCH faster at handling windows with a lot of files and no longer feels like it's asleep at the wheel.
Maybe OS X will be usable below the Dual GHz G4 level after all. The next thing to try will be iPhoto, which was ridiculously slow on my 500 MHz iBook.
I've been looking at LG refrigerators, since I'll need to replace my aging Liebherr sometime, but it seems they haven't caught on to the most important innovation of the last century: "Null-Grad Technik" as they call it in Germany, which provides a compartment that stays at 0.5 degrees C (without freezing), instead of the usual 4 C. This keeps many foods fresh two to five times as long, and I don't understand why the other manufacturers don't catch on.
I think you're right, and the Cringeley article is therefore, unfortunately, crap.
We looked at doing the same thing, and found that there is no way to make two AirPort base stations talk to each other. In the end, we put a Linux router on the other side of the link. We were using an earlier firmware on the AirPort (I think 1.2), but the release notes for 1.3 don't mention any new capabilities along these lines
Well, I have always used Macs because I think Windows is a terrible kludge, but I hate the short uptimes of the major desktop operating systems.
I would leave Mac OS for Linux, but: - Mac OS is still the best for ease of use if your main focus is not the computer, and - I would sorely miss CommuniGate (integrated email and fax) and FileMaker, as well as the occasional graphics application.
Currently I'm running SuSE Linux PPC on an iMac with Mac-On-Linux, as a test platform. When things mature a bit more, I hope to move my main G4 machine to Linux/MOL, but I'm still waiting for some of the wrinkles to be smoothed out of MOL (still a damn fine piece of work!), and I'm a bit scared of trying to get my dual-head setup (ATI RAGE/128 and Voodoo3) running with XFree and MOL.
1 TB isn't really so much. We have a 250 GB RAID on a Linux server and are installing another 450 GB next week. Some ideas: IDE only if money is very tight. Use a lot of controllers, one driver per channel. If a drive dies, it will often freeze the channel. We have an ICP Vortex controller, it works great. We tried an AMI MegaRAID, but the performance was a bit spotty. An external case, e.g. CI Designs, will get you 9 1,6" SCSI drives in a 4U 19" case with redundant power etc. Expect to pay $1500 and up for the case. With Seagate Cheetah 73 drives you can get about 450 GB per case at RAID 5, assuming a hot spare. (Which is a good idea.) With LVD, chaining multiple cases is not usually a problem. Good luck!
Apparently, Transmeta believe they can build processors that execute simple instructions extremely quickly. One approach mentioned in the patent is a VLIW processor, which can potentially execute many (simple) instructions simultaneously.
At the same time, they want to be able to run x86 software, so the focus is on emulation. It is easy to see how one might translate ("code morph") a simple, sequential stream of x86 instructions into RISC or VLIW instructions, which could then be reordered and optimized (as a compiler's peephole optimizer might do) to run at maximum, native speed on the target hardware or "morph host". However, real-world code never has an unbroken, linear flow of control. One problem that prevents existing software emulators from running emulated software at native speeds is the need to be able to interrupt the emulation at any instruction boundary, relative to the original x86 (target) instruction stream.
Thus, even in a linear sequence of target instructions, an exception may be triggered after each and any target instruction. Possible causes include illegal operands (divide by zero, illegal memory address) or a software or hardware interrupt that transfers control to an interrupt handler. However, the instruction being executed by the host (VLIW) architecture at the time the exception occurs may be performing some or all of the functions of one or more target instructions simultaneously. (E.g. a floating point divide and two integer multiplies.)
Yet in order to reproduce accurately the effect of the emulated target processor's instructions, the morph host must complete the emulation of the target instruction that caused the exception, and then transfer control to the exception handler, without disturbing the emulated target's state with additional, half-executed target instructions. In other words, the target execution state must be rolled back to an earlier state, and then the code must be reexecuted up to and including the exception-causing instruction, but none that follow.
Current pipelined microprocessors do things like this in hardware (e.g., speculative execution). Transmeta claims that they can greatly simplify the processor's hardware by moving these scheduling concerns into software, while providing explicit hardware checkpointing queue management instructions. For instance, writes to memory are tagged and placed in a speculative queue. When the target instruction responsible for the write finishes execution and an exception can no longer require that it be rolled back, the tagged write is explicitly committed. (For instance, if a target store instruction begins execution together with a floating point instruction that affects a target register, then the memory write of the store instruction and the register write of the fp instruction can be committed after both instructions have completed their emulated execution.) If a VLIW style instruction set is used, these commit operations can be performed in parallel with other operations.
The speculative execution of memory stores is useful in other ways as well. Thus store operations may be initially treated as though they reference memory. Accordingly, the emulation may reorder them, combine them with other operations, etc. However, during execution it may turn out that a store operation actually references memory-mapped I/O. This is determined by comparing the assumed type of access ("normal" for memory or "abnormal" for I/O) with the "A/N protection bit" associated with the target address page in the MMU's translation look-aside buffer. If a "normal" (i.e. potentially reordered) write to an "abnormal" (i.e. order-sensitive I/O) address is detected, the morph host takes an exception, returns to the last checkpoint of known target state, and restarts the execution of the target instructions, which are then recompiled to execute serially.
A similar technique is used to deal with self-modifying code. Pages of memory containing target code are marked with a "T" bit in the TLB if they have been translated (compiled to morph host instructions). If a write occurs to a memory page whose "T" bit is set, the corresponding host translations (i.e., compiled morph host instructions) are flushed from the cache, and the target code must be dynamically recompiled again the next time it is executed.
It would seem that many other optimizations will be possible in software, given that the morph host processor allows explicit software control over speculative execution, commit and rollback.
Slashdot Mirror
You are seriously confused. :-)
I am short SCOX and have held a part of my short position for over a year. Indeed, an advantage of taking a short position vs. buying put options is that you can generally hold your short position if the stock takes longer to tank than you anticipated, while options have a fixed expiration date.
Of course, as has been mentioned, there are no options on SCOX anyway.
It feels a lot snappier. I've installed it on a blue&white G3/300, and even without the boost from Quartz Extreme (which requires AGP and Radeon/GeForce or better) the GUI has picked up speed. The Finder is MUCH faster at handling windows with a lot of files and no longer feels like it's asleep at the wheel.
Maybe OS X will be usable below the Dual GHz G4 level after all. The next thing to try will be iPhoto, which was ridiculously slow on my 500 MHz iBook.
I've been looking at LG refrigerators, since I'll need to replace my aging Liebherr sometime, but it seems they haven't caught on to the most important innovation of the last century: "Null-Grad Technik" as they call it in Germany, which provides a compartment that stays at 0.5 degrees C (without freezing), instead of the usual 4 C. This keeps many foods fresh two to five times as long, and I don't understand why the other manufacturers don't catch on.
I think you're right, and the Cringeley article is therefore, unfortunately, crap.
We looked at doing the same thing, and found that there is no way to make two AirPort base stations talk to each other. In the end, we put a Linux router on the other side of the link. We were using an earlier firmware on the AirPort (I think 1.2), but the release notes for 1.3 don't mention any new capabilities along these lines
Well, I have always used Macs because I think Windows is a terrible kludge, but I hate the short uptimes of the major desktop operating systems.
I would leave Mac OS for Linux, but:
- Mac OS is still the best for ease of use if your main focus is not the computer, and
- I would sorely miss CommuniGate (integrated email and fax) and FileMaker, as well as the occasional graphics application.
Currently I'm running SuSE Linux PPC on an iMac with Mac-On-Linux, as a test platform. When things mature a bit more, I hope to move my main G4 machine to Linux/MOL, but I'm still waiting for some of the wrinkles to be smoothed out of MOL (still a damn fine piece of work!), and I'm a bit scared of trying to get my dual-head setup (ATI RAGE/128 and Voodoo3) running with XFree and MOL.
1 TB isn't really so much. We have a 250 GB RAID on a Linux server and are installing another 450 GB next week. Some ideas:
IDE only if money is very tight. Use a lot of controllers, one driver per channel. If a drive dies, it will often freeze the channel.
We have an ICP Vortex controller, it works great. We tried an AMI MegaRAID, but the performance was a bit spotty.
An external case, e.g. CI Designs, will get you 9 1,6" SCSI drives in a 4U 19" case with redundant power etc. Expect to pay $1500 and up for the case.
With Seagate Cheetah 73 drives you can get about 450 GB per case at RAID 5, assuming a hot spare. (Which is a good idea.) With LVD, chaining multiple cases is not usually a problem.
Good luck!
Apparently, Transmeta believe they can build processors that execute simple
instructions extremely quickly. One approach mentioned in the patent is a VLIW
processor, which can potentially execute many (simple) instructions
simultaneously.
At the same time, they want to be able to run x86 software, so the focus is on
emulation. It is easy to see how one might translate ("code morph") a simple,
sequential stream of x86 instructions into RISC or VLIW instructions, which
could then be reordered and optimized (as a compiler's peephole optimizer
might do) to run at maximum, native speed on the target hardware or "morph
host". However, real-world code never has an unbroken, linear flow of control.
One problem that prevents existing software emulators from running emulated
software at native speeds is the need to be able to interrupt the emulation at
any instruction boundary, relative to the original x86 (target) instruction
stream.
Thus, even in a linear sequence of target instructions, an exception
may be triggered after each and any target instruction. Possible causes include
illegal operands (divide by zero, illegal memory address) or a software or
hardware interrupt that transfers control to an interrupt handler. However,
the instruction being executed by the host (VLIW) architecture at the time the
exception occurs may be performing some or all of the functions of one or more
target instructions simultaneously. (E.g. a floating point divide and two
integer multiplies.)
Yet in order to reproduce accurately the effect of the
emulated target processor's instructions, the morph host must complete the
emulation of the target instruction that caused the exception, and then
transfer control to the exception handler, without disturbing the emulated
target's state with additional, half-executed target instructions. In other
words, the target execution state must be rolled back to an earlier state, and
then the code must be reexecuted up to and including the exception-causing
instruction, but none that follow.
Current pipelined microprocessors do things like this in hardware (e.g.,
speculative execution). Transmeta claims that they can greatly simplify the
processor's hardware by moving these scheduling concerns into software, while
providing explicit hardware checkpointing queue management instructions. For
instance, writes to memory are tagged and placed in a speculative queue. When
the target instruction responsible for the write finishes execution and an
exception can no longer require that it be rolled back, the tagged write is
explicitly committed. (For instance, if a target store instruction begins
execution together with a floating point instruction that affects a target
register, then the memory write of the store instruction and the register write
of the fp instruction can be committed after both instructions have completed
their emulated execution.) If a VLIW style instruction set is used, these
commit operations can be performed in parallel with other operations.
The speculative execution of memory stores is useful in other ways as well.
Thus store operations may be initially treated as though they reference
memory. Accordingly, the emulation may reorder them, combine them with
other operations, etc. However, during execution it may turn out that a
store operation actually references memory-mapped I/O. This is determined by
comparing the assumed type of access ("normal" for memory or
"abnormal" for I/O) with the "A/N protection bit" associated with the
target address page in the MMU's translation look-aside buffer. If a "normal"
(i.e. potentially reordered) write to an "abnormal" (i.e. order-sensitive I/O)
address is detected, the morph host takes an exception, returns to the last
checkpoint of known target state, and restarts the execution of the target
instructions, which are then recompiled to execute serially.
A similar technique is used to deal with self-modifying code. Pages of memory
containing target code are marked with a "T" bit in the TLB if they have been
translated (compiled to morph host instructions). If a write occurs to a
memory page whose "T" bit is set, the corresponding host translations
(i.e., compiled morph host instructions) are flushed from the cache, and the
target code must be dynamically recompiled again the next time it is executed.
It would seem that many other optimizations will be possible in software,
given that the morph host processor allows explicit software control over
speculative execution, commit and rollback.
Chris Ferebee