excerpts:
With layoffs striking everywhere from high-flying Internet companies like Amazon.com to brand-name corporations like Xerox and Motorola, engineers are so far thanking their lucky stars for that EE degree. The engineering ranks appear, for the most part, to have escaped the ax -- at least for now.
"Unemployment [among engineers] is still tenaciously low."
Though engineering departments have largely been spared, they don't always avoid the hatchet. "Our job reductions are worldwide, pervasive around the country except for the sales force. It's likely that some engineers will be included," said a Xerox spokeswoman.
Nevertheless, Hoover said that as a job hunter, he has seen that corporate cutbacks can go hand in hand with engineering hiring.
"[T]he dual-processor test was performed with not just two, but, in fact, three make processes. The difference here is that a processor will not be completely idle while waiting on IO in the second test, as there are two additional build processes running concurrently. This is why the use of the -j parameter is often recommended even for uniprocessor systems, as a parallel make will often yield much higher CPU utilization and thus faster compiles."
Also, see reader comments saying that AMD demonstrated a 4-way SMP Athlon system at LinuxWorld.
Fairfax has more money coursing through it than any other locality on the planet, without exageration, and it has been this way for around a decade.
About two months ago I was munching a sandwhich at a Subway in Fairfax and idly staring out the window. After a few minutes I realized that I was looking at two Magnum P.I. Ferraris, one red, one blue, behind an AMG Mercedes. Parked on the street.
And it took 5 minutes for that to seem weird to me, because it does take a while to understand that just because something has become routine to you it hasn't stopped being weird.
Yeah, they have (or at least had) rules that even approved tempest gear (hooray for Wang) had to be operated a minimum distance away from phones, for just these types of reasons.
Just earlier today I was wondering to myself if tempest shielding equipment will also harden it against EMP. I would guess that shielding against outgoing RF would also shield against incoming RF.
1) VGA Passthrough (I'm allergic to these)
2) Occupies 2 PCI slots
3) No encoding... but in way this is a benefit, too, 'cuz it damn well gaurantees that you are recording the virgin signal.
Intel's contract with Rambus forces them to ship motherboards supporting Rambus DRAM... but it doesn't say HOW it has to support them.
Intel's chipset plans call for the inclusion of a separate memory bank that will make it possible to increase the performance of the chipset-embedded graphics core by adding graphics-only RAM to this special bank. The special bank will be Rambus, the main memory will be double data rate RAM.
The kicker is that NO ONE will EVER use the special slot. The embedded graphics core is dog slow, and only marginally less so with the dedicated RAM added.
Any one wanting more performance will mearly bypass the embedded core instead of actually using Rambus, but Intel will have shipped a motherboard with a Rambus interface, fulfilling their contractual obligation.
The article is very strong, but it would have been enhanced if it also touched on AMD's upcoming 64-bit offerings, the Hammer family of chips.
Hammer does not have a track record in the marketplace, but neither does Itanium, and it's odd to ignore an architecture that in all likelihood will sell in much greater volume than several of the chips profiled here. Even if AMD's 64-bit implementation turns out less than ideal, it will probably outsell the Power, Alpha and Sparc offerings by virtue of the vastly larger market it targets.
A simulator for a Hammer chip has been released. A comparison, or at least an acknowledgement, would have made the article more valuable.
Check out http://www.eet.com/story/OEG20001009S0026
"German startup Pact GmbH will attempt to leapfrog the growing field of highly parallel processors targeting communications when it rolls out a complex 30-million-transistor CPU that integrates 128 thirty-two-bit processors at this week's Microprocessor Forum."
My company, eTantrum, ships a free player for Linux (and Windows) that (right now) does song identification as well as audio visualization, and it ships with a variety of killer skins.
http://www.etantrum.com/index.php?section=downlo ad
Also check out our GPL'ed Songprint song identification SDK at:
There is a pertinent clue amongst the marketing speak: "Note, however, that only Media ID-compatible disk drives can read the information stored using Media ID."
What this says to me is that it will be a fairly standard encryption system using the unique Media ID burned onto the disk as the seed value for the encryption applied to the contents of the disc.
This requires the cooperation of a few components:
1) The drive has to be able to read the unique ID (and their own PR says that not all drives will)
2) The OS probably has to keep track of which unique ID's it wrote to
As I wrote this it occured to me that the data could end up encrypted on the disk without the OS even requesting the use of encryption when writing to a Media ID'ed disk in a Media ID aware drive. The drive could easily encrypt the data using the ID as a seed with no outside intervention. If that is the case, then you can't read your own disks unless the OS plays along and keeps track of which ID's it wrote to.
This would mean reading would go like this:
In a non-aware drive the disk would flawless read a stream of useless encrypted data.
In an aware drive the drive would poll the OS for the list of media ID's it wrote to. If the (undivulged to the OS) media ID on the disk is not on the list, then it refuses to decrypt the contents.
Sucks, eh?
It gets better: because of the limited ways data would flow in such a system, you might not even know if the disk you were writing to was burned with a unique ID until you tried to do something the system didn't like, because the os never needs to see the ID, or even know if it exists. The drive could encrypt the disk without ever informing the OS so long as it has a secret set of bogus "no encryption" ID's to pass to the OS for storage in it's table of written to ID's. The falseness of these ID's need only be known to the drive makers.
There is more to bin sorting (determining CPU speed grades) than stability or other technical considerations.
Currently AMD is marking chips at LOWER than they are capable of running in nearly all cases due to marketing strategies, not technical limitations. AMD's K7 class chips (Athlons and Durons) are known to run stably at higher speeds, but AMD is biding it's time and keeping this headroom available for the coming mindshare fights with Intel's Pentium IV.
This is smart for AMD. The top chip, whatever speed it is, will sell for about the same price. So they can sell the lower clocked chip until Intel is able to counter with something with a faster clock speed. When that happens, AMD just changes the speed marking on the the chips they are already producing.
Yes, technical concerns are a limiting factor on chip speed ratings, but they are not the operative one for AMD right now.
There never was any cease and desist order, period. Ask Shawn, ask Dexter. Get'em both on a conference call; they get along great, guys. This article is an unresearched, totally biased hatchet job by somebody representing a media conglomerate with an ax to grind.
Warning: Resierfs is incompatible with software RAID 5. From Namesys's own FAQ at http://devlinux.com/projects/reiserfs/faq.html "Can I use ReiserFS with software RAID. Not with raid5, our journaling and their raid code step on each other in the buffering code. Also, you must use the mirror syncing tools with the FS unounted. Otherwise, yes, you may do striping and concatenating and mirroring." I found that nasty little surprise while trying to setup a honking big but low cost raid 5 box (currently 4 60 GB IDE drives, each on a separate channel, maybe going to 6 drives) and hoping to find something safer than ext2fs. Email to the JFS guy that writes for Byte went unreturned, so for now I'm sticking with ext2fs and a ginormus UPS.
Slashdot Mirror
Broad layoffs barely touch EEs
excerpts:
With layoffs striking everywhere from high-flying Internet companies like Amazon.com to brand-name corporations like Xerox and Motorola, engineers are so far thanking their lucky stars for that EE degree. The engineering ranks appear, for the most part, to have escaped the ax -- at least for now.
"Unemployment [among engineers] is still tenaciously low."
Though engineering departments have largely been spared, they don't always avoid the hatchet. "Our job reductions are worldwide, pervasive around the country except for the sales force. It's likely that some engineers will be included," said a Xerox spokeswoman.
Nevertheless, Hoover said that as a job hunter, he has seen that corporate cutbacks can go hand in hand with engineering hiring.
That's not true. Set your client to always respond with pure text AND set your client not to execute Javascript.
No mail sent to you will trigger this vulnerability and no mail sent from (or through) you will trigger this vulnerability.
Outlook Express supports these settings.
The "-j3" switch with the make is why it got a greater-than-linear improvement.
See Ace's Hardware for a discussion of exactly this:
"[T]he dual-processor test was performed with not just two, but, in fact, three make processes. The difference here is that a processor will not be completely idle while waiting on IO in the second test, as there are two additional build processes running concurrently. This is why the use of the -j parameter is often recommended even for uniprocessor systems, as a parallel make will often yield much higher CPU utilization and thus faster compiles."
Also, see reader comments saying that AMD demonstrated a 4-way SMP Athlon system at LinuxWorld.
Fairfax has more money coursing through it than any other locality on the planet, without exageration, and it has been this way for around a decade.
About two months ago I was munching a sandwhich at a Subway in Fairfax and idly staring out the window. After a few minutes I realized that I was looking at two Magnum P.I. Ferraris, one red, one blue, behind an AMG Mercedes. Parked on the street.
And it took 5 minutes for that to seem weird to me, because it does take a while to understand that just because something has become routine to you it hasn't stopped being weird.
But maybe Fairfax needs the dough to enforce the new immigrant-friendly laws they're whipping up to make it a crime to sleep in your own living room.
Yeah, they have (or at least had) rules that even approved tempest gear (hooray for Wang) had to be operated a minimum distance away from phones, for just these types of reasons.
No, I don't miss that job.
Just earlier today I was wondering to myself if tempest shielding equipment will also harden it against EMP. I would guess that shielding against outgoing RF would also shield against incoming RF.
Anyone really know?
And thought it was cheeky when I ran the Windows version of Williams's Arcade Classics (a set of arcade ROM's with an emulator) under OS/2!
:)
OS/2
"diagonally" running Windows
running an arcade emulator
on a non-Intel X86 chip!
So, does Mame32 run under Wine or Plex86? How about WABI?
1) VGA Passthrough (I'm allergic to these)
2) Occupies 2 PCI slots
3) No encoding... but in way this is a benefit, too, 'cuz it damn well gaurantees that you are recording the virgin signal.
Intel's contract with Rambus forces them to ship motherboards supporting Rambus DRAM... but it doesn't say HOW it has to support them.
Intel's chipset plans call for the inclusion of a separate memory bank that will make it possible to increase the performance of the chipset-embedded graphics core by adding graphics-only RAM to this special bank. The special bank will be Rambus, the main memory will be double data rate RAM.
The kicker is that NO ONE will EVER use the special slot. The embedded graphics core is dog slow, and only marginally less so with the dedicated RAM added.
Any one wanting more performance will mearly bypass the embedded core instead of actually using Rambus, but Intel will have shipped a motherboard with a Rambus interface, fulfilling their contractual obligation.
The article is very strong, but it would have been enhanced if it also touched on AMD's upcoming 64-bit offerings, the Hammer family of chips.
Hammer does not have a track record in the marketplace, but neither does Itanium, and it's odd to ignore an architecture that in all likelihood will sell in much greater volume than several of the chips profiled here. Even if AMD's 64-bit implementation turns out less than ideal, it will probably outsell the Power, Alpha and Sparc offerings by virtue of the vastly larger market it targets.
A simulator for a Hammer chip has been released. A comparison, or at least an acknowledgement, would have made the article more valuable.
Check out http://www.eet.com/story/OEG20001009S0026
"German startup Pact GmbH will attempt to leapfrog the growing field of highly parallel processors targeting communications when it rolls out a complex 30-million-transistor CPU that integrates 128 thirty-two-bit processors at this week's Microprocessor Forum."
My company, eTantrum, ships a free player for Linux (and Windows) that (right now) does song identification as well as audio visualization, and it ships with a variety of killer skins.
o ad
http://www.etantrum.com/index.php?section=downl
Also check out our GPL'ed Songprint song identification SDK at:
http://sourceforge.net/projects/freetantrum/
There is a pertinent clue amongst the marketing speak: "Note, however, that only Media ID-compatible disk drives can read the information stored using Media ID."
What this says to me is that it will be a fairly standard encryption system using the unique Media ID burned onto the disk as the seed value for the encryption applied to the contents of the disc.
This requires the cooperation of a few components:
1) The drive has to be able to read the unique ID (and their own PR says that not all drives will)
2) The OS probably has to keep track of which unique ID's it wrote to
As I wrote this it occured to me that the data could end up encrypted on the disk without the OS even requesting the use of encryption when writing to a Media ID'ed disk in a Media ID aware drive. The drive could easily encrypt the data using the ID as a seed with no outside intervention. If that is the case, then you can't read your own disks unless the OS plays along and keeps track of which ID's it wrote to.
This would mean reading would go like this:
In a non-aware drive the disk would flawless read a stream of useless encrypted data.
In an aware drive the drive would poll the OS for the list of media ID's it wrote to. If the (undivulged to the OS) media ID on the disk is not on the list, then it refuses to decrypt the contents.
Sucks, eh?
It gets better: because of the limited ways data would flow in such a system, you might not even know if the disk you were writing to was burned with a unique ID until you tried to do something the system didn't like, because the os never needs to see the ID, or even know if it exists. The drive could encrypt the disk without ever informing the OS so long as it has a secret set of bogus "no encryption" ID's to pass to the OS for storage in it's table of written to ID's. The falseness of these ID's need only be known to the drive makers.
Don't you love modern customer service?
There is more to bin sorting (determining CPU speed grades) than stability or other technical considerations.
Currently AMD is marking chips at LOWER than they are capable of running in nearly all cases due to marketing strategies, not technical limitations. AMD's K7 class chips (Athlons and Durons) are known to run stably at higher speeds, but AMD is biding it's time and keeping this headroom available for the coming mindshare fights with Intel's Pentium IV.
This is smart for AMD. The top chip, whatever speed it is, will sell for about the same price. So they can sell the lower clocked chip until Intel is able to counter with something with a faster clock speed. When that happens, AMD just changes the speed marking on the the chips they are already producing.
Yes, technical concerns are a limiting factor on chip speed ratings, but they are not the operative one for AMD right now.
There never was any cease and desist order, period. Ask Shawn, ask Dexter. Get'em both on a conference call; they get along great, guys. This article is an unresearched, totally biased hatchet job by somebody representing a media conglomerate with an ax to grind.
Warning: Resierfs is incompatible with software RAID 5. From Namesys's own FAQ at http://devlinux.com/projects/reiserfs/faq.html "Can I use ReiserFS with software RAID. Not with raid5, our journaling and their raid code step on each other in the buffering code. Also, you must use the mirror syncing tools with the FS unounted. Otherwise, yes, you may do striping and concatenating and mirroring." I found that nasty little surprise while trying to setup a honking big but low cost raid 5 box (currently 4 60 GB IDE drives, each on a separate channel, maybe going to 6 drives) and hoping to find something safer than ext2fs. Email to the JFS guy that writes for Byte went unreturned, so for now I'm sticking with ext2fs and a ginormus UPS.