Any RF technician or audiophile can tell you that if you want to focus in on a specific frequency or range, you need good/better AC filters.
For AM transmissions, theoretically a single, exact frequency can suffice. Assuming the transmitter is truly on the expected frequency, all you need is a very narrow bandpass filter.
For FM transmissions, it's a little bit trickier. Simply put, the voltage being applied to your speakers (if one ignores all the fancy equilizer circuitry in a radio) is dependent on the exact frequency being transmitted at a given time. The transmitter sends a constant-amplitude signal whose frequency changes with the amplitude of the audio sample.
With FM transmissions, you need bandwidth. You have to be able to discern between the high and low point in the signal, so your radio technology has to at least be capable of discerning between the frequency at the high point, and the frequency at the low point. The broader the bandwidth, and/or the more precise your transmitter and receiver, the more accurate the signal will be on the receiving end.
The point behind all of this is that we're much better at discerning between frequencies than we were fifty years ago, when the FM spectrum allocated. We should be able to fit a passable transmission in a much smaller bandwidth than we do now.
This has interesting possibilities. If you have stations with a high bandwidth (for audiophiles), mixed with low-bandwidth stations (for simple voice broadcasts, you can allocate your bandwidth much more efficiently.
The same concept can apply for digital technologies, too.
On another note, it should be possible for them to implement hyperthreading in their code morphing engine. That'd be interesting. I wonder if Intel has a patent on it.
Can't be. I learn more science and technology from anecdotes and references on Slashdot than I ever learned from a textbook. (Well, maybe not so much chemistry as biology and physics.)
VLIW improves performance when the instruction stream can be split up over multiple processing units.
Exhibit A:
LOAD A LOAD B LOAD C LOAD D ADD A, B MOD A, C ADD A, D STORE A
LOAD E LOAD F LOAD G LOAD H ADD E, F MOD E, G ADD E, H STORE E
Exhibit B:
LOAD A LOAD B LOAD C LOAD D LOAD E LOAD F LOAD G LOAD H ADD A, B ADD E, F MOD A, C MOD E, G ADD A, D ADD E, H STORE A STORE E
Exhibit A is more difficult to make parallel than exhibit B, since the potentially parallelable code is separated, and, from a CPU's short-range perspective, each operation in exhibit A depends on the previous, which makes executing the instructions in parallel impossible.
In exhibit B, instructions independent of each other are right next to each other. This makes it easy for the CPU to separate the code into parallel units.
(As an aside...they have an article that may change your views about x86(ala P4) vs PPC(ala G4e). It doesn't take one side or another, it just points out the different approaches used by each architecture.)
If the OS could optimize for it, that would let you run up to 8 threads simultaneously, correct? Kindof like HyperThreading, except one virtual CPU wouldn't get hung up if the other was using some vital module.
It seems too good to be true, so I'm probably wrong.
If you have a lot of ram, one way to improve compile time is to move all the code off the (slow) harddrive and onto the (fast) ramdisk. (Debian defines/tmp as a ramfs drive...dunno about other distributions.)
Works for me.:) (But then, I just placed my second order for 768MB of PC133 SDRAM...So I'm a bit behind the times.)
I work at GRCC in the ATC open computer lab. We have 7-digit student ID numbers, and typing those into our sign-in software with a numeric keypad is a heck of a lot faster (and easier) than typing in their name and address. And this really matters when you have eight people lined up to sign out computers.
But then, their student number is on their student ID card. A physical ID+unique integer is a godsend.
They're probably having a real bitch of a time with Apple. I can't imagine Apple will make it easy for OSX to run on hardware not normally found in Macs.
Transmeta probably already has the PPC emulation down pat...It's just that it would be unwise to release it if OSX (Its most prominent potential use) won't run on it. Bad publicity.
The details article mentions that a lot of the load the hardware normally does is being shunted back on the software. According to ArsTechnia, that's where it should be. (1, 2)
My question is, will compilers be able to bypass the code morphing software, and directly work with the Transmeta's underlying instruction set?
I agree with you, though I don't think those statistics are readily available.
Heck...under Windows, even video game installations tend to demand a reboot. (Though you can usually get away with saying No and running the game anyway.)
This is because most software applications include DLLs that get added to system directories, and, technically, you're supposed to reboot in order for those DLLs to be recognized and harbored by the OS.
Under UNIX (NOT just Linux), You only have to type ld as root, and you should be just fine. Special integration with things like Mozilla or Emacs may require you to restart the program, though.
I suspect UNIX's resiliency is partially the result of IEEE's efforts in developing POSIX, etc.
Considering that 1 THz is 1000 MHz, I'd say we've got several years to go. Especially considering that Intel is backing down from their clock speed marketing frenzy.
I think we can expect a good three or four years before we break 10 GHz. I'm not sure how much farther we can go, considering trace crosstalk increases proportionally to frequency. They'll probably find a way to make crosstalk moot, though.
The problem doesn't lie in my dislike of reading licenses, it lies in risking not having the option to read them in the first place.
I have nothing against software licenses...Sometimes their implementation is questionable, and more often than not taken for granted by the majority of users, but I see them as a valid way for the writer of the software to place restrictions on its use.
I can, and do, license my stuff under the GPL, LGPL, or BSD license, as the case warrents.
However, if your computer is comprimised, well, you've got bigger things to worry about than somebody trying to time how long it takes to encrypt a message.;-)
I beg to differ. While a rooted box can be fixed, along with the administrative policies around it, a PGP private key is a much more serious thing to have leak.
Any and all material previously encrypted with that material is now vulnerable, whether it be stored on the rooted box itself, or on a webserver for my easy access. (I've got a physically secured slip of paper with my private key that I carry around with me.)
So, a compromised private key is a much more severe issue than a rooted box, no matter how that box got rooted.
It may depend a great deal on how their traces are layed out on the die. If the traces are two close together, then signals, thanks to electric fields, start jumping from trace to trace, causing interference.
If the traces are too far apart, then the whole circuit occupies more space than it needs to, which means the traces are too long. The longer the traces, the more like an antenna the trace becomes, possiby causing noise by RF interference.
They have to find the right size, and even then, their block layout for their different CPU portions may be the problem. A reorganization or the layout may be what's called for.
The problem is that there's not enough memory to hold anything sophisticated. So I don't think it's what comes to mind when people think of a web server.
According to the product's home page, the component is designed for embedded applications, not for being a standalone web server. It's intended as a means of remotely serving up diagnostics information over TCP/IP. It's not sophisticated enough to be an http server.
Slashdot Mirror
Any RF technician or audiophile can tell you that if you want to focus in on a specific frequency or range, you need good/better AC filters.
For AM transmissions, theoretically a single, exact frequency can suffice. Assuming the transmitter is truly on the expected frequency, all you need is a very narrow bandpass filter.
For FM transmissions, it's a little bit trickier. Simply put, the voltage being applied to your speakers (if one ignores all the fancy equilizer circuitry in a radio) is dependent on the exact frequency being transmitted at a given time. The transmitter sends a constant-amplitude signal whose frequency changes with the amplitude of the audio sample.
With FM transmissions, you need bandwidth. You have to be able to discern between the high and low point in the signal, so your radio technology has to at least be capable of discerning between the frequency at the high point, and the frequency at the low point. The broader the bandwidth, and/or the more precise your transmitter and receiver, the more accurate the signal will be on the receiving end.
The point behind all of this is that we're much better at discerning between frequencies than we were fifty years ago, when the FM spectrum allocated. We should be able to fit a passable transmission in a much smaller bandwidth than we do now.
This has interesting possibilities. If you have stations with a high bandwidth (for audiophiles), mixed with low-bandwidth stations (for simple voice broadcasts, you can allocate your bandwidth much more efficiently.
The same concept can apply for digital technologies, too.
Ah...
On another note, it should be possible for them to implement hyperthreading in their code morphing engine. That'd be interesting. I wonder if Intel has a patent on it.
Can't be. I learn more science and technology from anecdotes and references on Slashdot than I ever learned from a textbook. (Well, maybe not so much chemistry as biology and physics.)
PPC vs x86 IA has nothing to do with VLIW.
VLIW improves performance when the instruction stream can be split up over multiple processing units.
Exhibit A:
LOAD A
LOAD B
LOAD C
LOAD D
ADD A, B
MOD A, C
ADD A, D
STORE A
LOAD E
LOAD F
LOAD G
LOAD H
ADD E, F
MOD E, G
ADD E, H
STORE E
Exhibit B:
LOAD A
LOAD B
LOAD C
LOAD D
LOAD E
LOAD F
LOAD G
LOAD H
ADD A, B
ADD E, F
MOD A, C
MOD E, G
ADD A, D
ADD E, H
STORE A
STORE E
Exhibit A is more difficult to make parallel than exhibit B, since the potentially parallelable code is separated, and, from a CPU's short-range perspective, each operation in exhibit A depends on the previous, which makes executing the instructions in parallel impossible.
In exhibit B, instructions independent of each other are right next to each other. This makes it easy for the CPU to separate the code into parallel units.
I'm no expert, I just read a lot of Ars Technica.
(As an aside...they have an article that may change your views about x86(ala P4) vs PPC(ala G4e). It doesn't take one side or another, it just points out the different approaches used by each architecture.)
If the OS could optimize for it, that would let you run up to 8 threads simultaneously, correct? Kindof like HyperThreading, except one virtual CPU wouldn't get hung up if the other was using some vital module.
It seems too good to be true, so I'm probably wrong.
If you have a lot of ram, one way to improve compile time is to move all the code off the (slow) harddrive and onto the (fast) ramdisk. (Debian defines /tmp as a ramfs drive...dunno about other distributions.)
:) (But then, I just placed my second order for 768MB of PC133 SDRAM...So I'm a bit behind the times.)
Works for me.
I work at GRCC in the ATC open computer lab. We have 7-digit student ID numbers, and typing those into our sign-in software with a numeric keypad is a heck of a lot faster (and easier) than typing in their name and address. And this really matters when you have eight people lined up to sign out computers.
But then, their student number is on their student ID card. A physical ID+unique integer is a godsend.
They're probably having a real bitch of a time with Apple. I can't imagine Apple will make it easy for OSX to run on hardware not normally found in Macs.
Transmeta probably already has the PPC emulation down pat...It's just that it would be unwise to release it if OSX (Its most prominent potential use) won't run on it. Bad publicity.
The details article mentions that a lot of the load the hardware normally does is being shunted back on the software. According to ArsTechnia, that's where it should be. (1, 2)
My question is, will compilers be able to bypass the code morphing software, and directly work with the Transmeta's underlying instruction set?
I agree with you, though I don't think those statistics are readily available.
Heck...under Windows, even video game installations tend to demand a reboot. (Though you can usually get away with saying No and running the game anyway.)
This is because most software applications include DLLs that get added to system directories, and, technically, you're supposed to reboot in order for those DLLs to be recognized and harbored by the OS.
Under UNIX (NOT just Linux), You only have to type ld as root, and you should be just fine. Special integration with things like Mozilla or Emacs may require you to restart the program, though.
I suspect UNIX's resiliency is partially the result of IEEE's efforts in developing POSIX, etc.
VRML could have done that...I'd like to see some web-based games ala VRML. That might be interesting...
The difference in this case is it's a kernel exploit. Unless the problem lies in a module, you'll still have to reboot. :/
Like EverCrack with puzzles? What are you trying to do to the world?!
Does anyone have a link to the Linux Game Project's homepage? I googled for it, but didn't find it. (?!)
Considering that 1 THz is 1000 MHz, I'd say we've got several years to go. Especially considering that Intel is backing down from their clock speed marketing frenzy.
I think we can expect a good three or four years before we break 10 GHz. I'm not sure how much farther we can go, considering trace crosstalk increases proportionally to frequency. They'll probably find a way to make crosstalk moot, though.
The problem doesn't lie in my dislike of reading licenses, it lies in risking not having the option to read them in the first place.
I have nothing against software licenses...Sometimes their implementation is questionable, and more often than not taken for granted by the majority of users, but I see them as a valid way for the writer of the software to place restrictions on its use.
I can, and do, license my stuff under the GPL, LGPL, or BSD license, as the case warrents.
Between getting rooted and being automatically subject to license agreements, I'd rather get rooted.
With a slashdot poll? :)
...
...
A series of polls,
"I use Debian for a..."
* Server
* Desktop
* Both
* Raytracer of a CowboyNeal model
"I use Red Hat for a..."
* Server
* Desktop
* Both
* Cowboyowulf cluster
"I use Slackware for a..."
* Server
* Desktop
* Both
* CowboyNeal Dissection Model
(And if someone mods me "Interesting", I'll shoot myself.)
Wouldn't the private key then change, during the next SSL connection?
I can see how it would be a real problem for SSL-based VPNs, though.
However, if your computer is comprimised, well, you've got bigger things to worry about than somebody trying to time how long it takes to encrypt a message. ;-)
I beg to differ. While a rooted box can be fixed, along with the administrative policies around it, a PGP private key is a much more serious thing to have leak.
Any and all material previously encrypted with that material is now vulnerable, whether it be stored on the rooted box itself, or on a webserver for my easy access. (I've got a physically secured slip of paper with my private key that I carry around with me.)
So, a compromised private key is a much more severe issue than a rooted box, no matter how that box got rooted.
It may depend a great deal on how their traces are layed out on the die. If the traces are two close together, then signals, thanks to electric fields, start jumping from trace to trace, causing interference.
If the traces are too far apart, then the whole circuit occupies more space than it needs to, which means the traces are too long. The longer the traces, the more like an antenna the trace becomes, possiby causing noise by RF interference.
They have to find the right size, and even then, their block layout for their different CPU portions may be the problem. A reorganization or the layout may be what's called for.
The problem is that there's not enough memory to hold anything sophisticated. So I don't think it's what comes to mind when people think of a web server.
And I didn't notice it was an HTTP server. srry.
According to the product's home page, the component is designed for embedded applications, not for being a standalone web server. It's intended as a means of remotely serving up diagnostics information over TCP/IP. It's not sophisticated enough to be an http server.
It's mounted on a PC-board, so it probably gets its power from the device it's mounted in.
If you have to worry about Microsoft dropping support for your bra, then I think you've got a bit too personal of a relationship with them...