Uhm, whatever.
First of all, the numbers I've seen suggest
that computers have slowed the growth of electricity use in California, because they increase the efficiency with which everything gets done. This article on Salon goes over the information in pretty good detail.
Once you accept that computers actually represent a small %age of California's power burden, you also need to realize that the incremental cost of cooling those computers can't be much higher.
Even if it took 2Wh of AC for every 1Wh consumed by a computer, the overall impact on the electricity budget would still be small compared to the rest of the stuff sucking up energy.
Stuff like TVs that are left on most of the time,
microwave ovens (typically 700W or higher when they're on, as compared to the ~200W a typical computer draws when its crunching away), electric stoves, electric heat, and AC for personal dwellings that would be there regardless of computers.
And don't forget, running computers in the winter cuts your heating costs, to offset the increase in AC costs in the summer...
The MAC address is hardwired in, but it's the
software layers that put the address in the
packet or program the Ethernet MAC's registers
with most cards. As I understand it, in many cases under
Linux, you can change the effective MAC address
for a card with ifconfig.
I believe this is the flag that does the magic:
hw class address
Set the hardware address of this interface, if the
device driver supports this operation. The keyword
must be followed by the name of the hardware class
and the printable ASCII equivalent of the hardware
address. Hardware classes currently supported
include ether (Ethernet), ax25 (AMPR AX.25), ARCnet
and netrom (AMPR NET/ROM).
Does that answer your question?
At any rate, I know it's possible to do this by hacking the driver in the kernel (at least for NE2K clones), as I've done this personally in a previous life...
There's a vulnerability in Linux with long directory names that's exposed by ReiserFS.
As best as they can tell, the vulnerability is
in the Linux VFS layer, and not ReiserFS itself.
See this page and this page for more details.
As for whether this makes the FS marked experimental or stable, I don't know. I'd imagine that it'll be marked experimental simply because this is the first mainline release to include it.
Hemos, when comparing things, use than, not then. For instance, this
article should've been from the "it's-better-than-the-web!" dept. The word then is used to describe a time sequence or other ordering, as in "first this, then that." The word than is used to compare things, as in "this is better than that." Got it?
If you read the FLAC site, or more importantly, the comparison page, you'll see that FLAC compresses a little more than Shorten, and is seekable and streamable. (Shorten is seekable in its most recent version only.) Also, FLAC supports meta-data within the file (ID3 / ID3v2 tags, for instance).
I don't know FLAC's algorithms, but I can say that shorten has nothing to do with bzip2 in terms of compression style. As I recall, Shorten uses a predictor equation to predict the next sample from the current sample, and then uses Huffman coding on the difference between the predicted sample and the actual sample.
And, uhm, my name is actually, uhm, Milton Wadams, and uh I was listening to my radio at a reasonable volume while I was collating, and uhm Mr. Lundberg comes in and takes my Swingline stapler, uhm I kept the Swingline stapler when they switched to the Bostich because it staples better and I have some extra Swingline staples, and uhm they moved my office again because it used to be by the w
indow, and there were these two squirrels and they were married and...
Uh, thanks Milton, but I have to go.
--Joe
(PS. Laugh. If that wasn't funny to you, you probably haven't seen Office Space yet. Rent it. Now.)
--
Re:Working in such an env., 10GB+, NT/UNIX clients
on
Clearcase vs. CVS?
·
· Score: 1
1) CVS's storage of binary files.
While it's not ideal space-wise, you can check
in binary files by adding them with the "-kb"
flag, as in cvs add -kb binary_file.
Older versions of CVS might need you to use "-ko"
instead.
If you accidentally check in a binary file w/out
"-kb", you're ok until try to check in an update
to the file. In that scenario, you can use cvs admin to fix your boo-boo. See
the Per Cedarqvist manual for details.
Hey, no problem. The whole "beg the question"
thing has gotten to me for awhile, so I'm sorry
if it seemed like I was "going off" on you.
I wasn't. It's more like I was venting in general, since many people make that mistake, both in this forum and elsewhere.:-)
HOWEVER, this still begs the question of how much is too much?
This may raise the question, but it certainly does not beg the question.
Go look up what "begging the question" means.
Or, if you're too lazy to look it up, here's
a serviceable, short definition:
To beg the question is to provide an answer to a question which merely rephrases the content of the question without providing any new information.
For example, if I ask you "Why don't you drink cold coffee?" and you answer "I never drink coffee when it's cold," that would be begging the question. The answer doesn't say why you don't drink cold coffee, just that you don't.
One problem with these high clock rates is
that you end up having to pipeline things
rather excessively all over the place. I'd
imagine at 750GHz that even a single 64-bit
ADD would be pipelined over multiple cycles,
due to transport delay!
Think about it: Light travels about 1 foot per
nanosecond (30cm). At 1GHz speeds, a signal could
travel well across a die if it were unimpeded
(eg. could travel at the speed of light). In
fact, it could theoretically travel most of the way across the motherboard in one clock period. At 750GHz, light travels 0.4mm per clock tick -- about 1/20th the way across a typical CPU die (assuming a die in the range 8mm x 8mm to 10mm x 10mm die -- not too far off what we build today).
We're talking 20 pipeline stages just to get from
one edge of the die to the other, if we can travel at the full speed of light in a vacuum.
And the bad news is that we probably can't -- just look at todays CPUs!
What'll happen is that highly parallelizable problems will speed up, and inherently serial
problems will end up staying the same. All of
your number crunching for playing video games will
rocket along since the calculations can be
pipelined and parallelized, but the twisty, turny, five-instructions-and-a-branch control code won't
speed up much.
There's no "global maxima" associated with the concept of "better". Different flavors are better at different things. I suppose that's the concept you were grasping for? If so, why invoke the concept of "winning", when you're not necessarily pitting the different flavors head to head?
When I say "X is near Y", that just means they're in the same proximity. When I say "X is nearly Y", that means that X is almost Y, but not quite. When referring to numerical quantities, this can be explained like
so:
"X is near Y": abs(Y - X) < epsilon, where epsilon is a small, positive value.
"X is nearly Y": Y - X < epsilon, where epsilon is a small, positive value.
The article above says "nearly 1 in 250", which implies that the odds are below this, but near this. The actual odds are "1 in 249", which are greater odds, not lesser odds (meaning, more likely than 1 in 250, not less likely). You could've avoided the whole thing by saying "about 1 in 250", or even "about 0.4%".
Slashdot Mirror
Uhm, whatever. First of all, the numbers I've seen suggest that computers have slowed the growth of electricity use in California, because they increase the efficiency with which everything gets done. This article on Salon goes over the information in pretty good detail.
Once you accept that computers actually represent a small %age of California's power burden, you also need to realize that the incremental cost of cooling those computers can't be much higher. Even if it took 2Wh of AC for every 1Wh consumed by a computer, the overall impact on the electricity budget would still be small compared to the rest of the stuff sucking up energy. Stuff like TVs that are left on most of the time, microwave ovens (typically 700W or higher when they're on, as compared to the ~200W a typical computer draws when its crunching away), electric stoves, electric heat, and AC for personal dwellings that would be there regardless of computers.
And don't forget, running computers in the winter cuts your heating costs, to offset the increase in AC costs in the summer...
--Joe--
The MAC address is hardwired in, but it's the software layers that put the address in the packet or program the Ethernet MAC's registers with most cards. As I understand it, in many cases under Linux, you can change the effective MAC address for a card with ifconfig.
I believe this is the flag that does the magic:
hw class addressDoes that answer your question?
At any rate, I know it's possible to do this by hacking the driver in the kernel (at least for NE2K clones), as I've done this personally in a previous life...
--Joe--
There's a vulnerability in Linux with long directory names that's exposed by ReiserFS. As best as they can tell, the vulnerability is in the Linux VFS layer, and not ReiserFS itself. See this page and this page for more details.
As for whether this makes the FS marked experimental or stable, I don't know. I'd imagine that it'll be marked experimental simply because this is the first mainline release to include it.
--Joe--
It must be too early in the morning for me. I read this as "My school's flirting system..." That must be some interesting school. Uh, yeah.
--Joe--
Uh, no. Bad grammar bothers me.
--Joe--
That reminds me of this grammar puzzler. Add punctuation to the following to make it grammatically correct:
--Joe--
Hemos, when comparing things, use than, not then. For instance, this article should've been from the "it's-better-than-the-web!" dept. The word then is used to describe a time sequence or other ordering, as in "first this, then that." The word than is used to compare things, as in "this is better than that." Got it?
*sigh*
--Joe--
Yeah, it's a bit like suing Windows, isn't it? Or maybe NTKRNL.EXE?
--Joe--
I said: predict the next sample from the current sample... Brain fart. More correctly, it predicts the next sample from several recent samples.
--Joe--
I don't know FLAC's algorithms, but I can say that shorten has nothing to do with bzip2 in terms of compression style. As I recall, Shorten uses a predictor equation to predict the next sample from the current sample, and then uses Huffman coding on the difference between the predicted sample and the actual sample.
--Joe--
And, uhm, my name is actually, uhm, Milton Wadams, and uh I was listening to my radio at a reasonable volume while I was collating, and uhm Mr. Lundberg comes in and takes my Swingline stapler, uhm I kept the Swingline stapler when they switched to the Bostich because it staples better and I have some extra Swingline staples, and uhm they moved my office again because it used to be by the w indow, and there were these two squirrels and they were married and...
Uh, thanks Milton, but I have to go.
--Joe(PS. Laugh. If that wasn't funny to you, you probably haven't seen Office Space yet. Rent it. Now.)
--
While it's not ideal space-wise, you can check in binary files by adding them with the "-kb" flag, as in cvs add -kb binary_file. Older versions of CVS might need you to use "-ko" instead.
If you accidentally check in a binary file w/out "-kb", you're ok until try to check in an update to the file. In that scenario, you can use cvs admin to fix your boo-boo. See the Per Cedarqvist manual for details.
--Joe--
Hey, no problem. The whole "beg the question" thing has gotten to me for awhile, so I'm sorry if it seemed like I was "going off" on you. I wasn't. It's more like I was venting in general, since many people make that mistake, both in this forum and elsewhere. :-)
--Joe--
This may raise the question, but it certainly does not beg the question. Go look up what "begging the question" means. Or, if you're too lazy to look it up, here's a serviceable, short definition: To beg the question is to provide an answer to a question which merely rephrases the content of the question without providing any new information.
For example, if I ask you "Why don't you drink cold coffee?" and you answer "I never drink coffee when it's cold," that would be begging the question. The answer doesn't say why you don't drink cold coffee, just that you don't.
--Joe--
But what about recoil?
Oh, it's self-coiling.
Take your buzzword bullshit elsewhere, troll.
--Joe--
Program Intellivision!
Or another.
--
Program Intellivision!
Information can travel no faster than the speed of light. Period.
--Joe--
Program Intellivision!
One problem with these high clock rates is that you end up having to pipeline things rather excessively all over the place. I'd imagine at 750GHz that even a single 64-bit ADD would be pipelined over multiple cycles, due to transport delay!
Think about it: Light travels about 1 foot per nanosecond (30cm). At 1GHz speeds, a signal could travel well across a die if it were unimpeded (eg. could travel at the speed of light). In fact, it could theoretically travel most of the way across the motherboard in one clock period. At 750GHz, light travels 0.4mm per clock tick -- about 1/20th the way across a typical CPU die (assuming a die in the range 8mm x 8mm to 10mm x 10mm die -- not too far off what we build today). We're talking 20 pipeline stages just to get from one edge of the die to the other, if we can travel at the full speed of light in a vacuum. And the bad news is that we probably can't -- just look at todays CPUs!
What'll happen is that highly parallelizable problems will speed up, and inherently serial problems will end up staying the same. All of your number crunching for playing video games will rocket along since the calculations can be pipelined and parallelized, but the twisty, turny, five-instructions-and-a-branch control code won't speed up much.
--Joe--
Program Intellivision!
Because the Pong game on Keen's wristwatch is K-rad!
--Joe--
Program Intellivision!
What shell are they using?
--Joe--
Program Intellivision!
And just how many copies of this hypervisor could you run at once on the same machine? Hmmm? What was that, only one? Thought so.
Multitasking VM86 sessions does not mean you've fully virtualized the CPU.
--
Program Intellivision!
And in other news, Water is Wet, Gravity Sucks, and Nader Still Lost.
--Joe--
Program Intellivision!
There's no "global maxima" associated with the concept of "better". Different flavors are better at different things. I suppose that's the concept you were grasping for? If so, why invoke the concept of "winning", when you're not necessarily pitting the different flavors head to head?
--Joe--
Program Intellivision!
When I say "X is near Y", that just means they're in the same proximity. When I say "X is nearly Y", that means that X is almost Y, but not quite. When referring to numerical quantities, this can be explained like so:
See the difference?
--Joe--
Program Intellivision!
The article above says "nearly 1 in 250", which implies that the odds are below this, but near this. The actual odds are "1 in 249", which are greater odds, not lesser odds (meaning, more likely than 1 in 250, not less likely). You could've avoided the whole thing by saying "about 1 in 250", or even "about 0.4%".
*sigh
--Joe--
Program Intellivision!