That might be the case for some cards, but isn't it possible to render into an off-screen buffer, and then read the contents of that buffer? Doesn't a 3D video card help when rendering images that you intend to save, not just show once? (I don't have one, so I can't check on this.)
It's a tough hoop to jump through to have to do that to crunch numbers, but it might be theoretically possible. (No idea whether you could do anything that's faster than just using the CPU, though, since there would be overhead to messing with the video card.)
That would make an interesting (well, pretty crappy actually) screen-saver: The raw data flashes over your video RAM... kind of like those old calculators that used the screen-display register as part of their calculations, making the numbers dance like crazy.) #define X(x,y) x##y
I wonder if it would be possible to use any of processing power of accelerated video cards to help crunch SETI, gamma flux, or some other floating point (or integer, like OGR and RC5) number crunching thing? I've never looked at programming specs for any video cards, so I don't know which, if any, would be flexible enough to do computing tasks other than 3d rendering.
The vector nature of video card processors makes them sound nice for crunching SETI's arrays, unfortunately, this sounds like wishful thinking, but maybe worth looking into. Maybe a lighting engine could help with dcypher.net's gamma ray projections?
Anyone out there intimately familiar with any particular video hardware? How could it be used for any of these projects? #define X(x,y) x##y
Linux uses the native word size of the machine for file offsets, so on 32bit architectures, file sizes are limited to 2GB, while on 64bit archs, Linux can handle files up to 8EB (1 exabyte ~= 1 million terabyte).
Recently, large file support on 32bit archs has been developed, but it isn't in the main kernel yet, AFAIK. #define X(x,y) x##y
Using raw disk partitions is not the same thing as Linux's "raw block device" support, which lets you access block devices without going through the buffer-cache layer. Some database programs want to use this so they can do their own caching, etc. However, lots of things access block devices, e.g./dev/hda1, for example mkfs, and fdisk. The raw block device support is still very new, and was developed by Steven Tweedie. It uses kiobufs to do zero-copy IO. You would know about this if you were at the second memory management talk, given by Ben LaHaise, at the Ottawa Linux Symposium last week:)
So, unless it's the database's release notes that say not to use whole disk partitions, there should be no problem. The kernel lets you access a disk partition as a big file very easily. #define X(x,y) x##y
I think that's a brain-fart, not a typo, since "communicative" is not a very likely misspelling for "commutative". OTOH, I don't think "commutative" is the right word either. I think "reversible" is more like it.
Oh well, only a video game programmer, what can you expect...:-) (hehe, just kidding.)
Welp...It looks like the beta has a working set that fits completely into the Coppermine's 256kb L2 cache, but is still too large to fit into the Celeron's cache. What does this mean? It looks as if the client is now no longer memory bandwidth limited in *any* PIII CPU. Memory tweaks will probably show no improvement in client times...
This is foolish. SETI@HOME uses a lot of memory. It does FFTs and other matrix/array operations on large data sets. I think the reason he sees the same performance with a Katmai PIII@550MHz and a Coppermine PIII@550MHz is not that the working set fits in the Coppermine's 256kB L2 cache, but that it is much bigger than the Katmai's 512kB L2 cache. They get the same performance because they have the same memory bandwidth (100MHz FSB) and FPU performance. I don't know why the Celeron lags, but it might be because of a worse FPU. (I haven't bothered to keep all of Intel's chips straight.)
As for the author's suggestion that a K7 or Duron would have equal performance, I wouldn't be surprised if an Athlon or Duron (or especially a Thunderbird) beat the pants off of Intel, because they run a faster memory bus. (This only applies if you have RAM that can keep up with the bus, like DDR SDRAM, though.) I think RAMBUS ram is well suited to this task, since there's lots of sequential access and memory bandwidth is more important than latency here.
The author really should have tried a benchmark on a machine with a bus other than 100MHz. Silly person:) #define X(x,y) x##y
It's a _radio_ telescope. Of course it doesn't sense neutrinos. It's really hard to do that, BTW. A neutrino can go through miles of lead with only a very slight chance of interacting with the lead. Current neutrino detectors are big tanks of heavy water (D2, deuterium) with photomultipliers all around. #define X(x,y) x##y
Yet another reason to like Debian... Zero dollars are spent on marketing, so you know they're not paying anyone (directly or indirectly) to trick you.
Of course, if you're smart and knowledgeable enough to evaluate your options for yourself, do that and pick the best software, regardless of marketing. For me, Debian is the best software I've found yet, but YMMV. #define X(x,y) x##y
yeah, I've seen a guy pick up a pop bottle from under the cardboard box because he though it was leaking and wasn't going to explode. Luckily for him, he was wearing a leather glove. He got cut on the chin, and his hand was numb for days. Moral: always put the pop bottle under something to absorb the shock wave, and don't get too curious too soon.
The trick to doing it right is to fill the bottle less than a quarter of the way full, so there is lots of volume to compress. A 600ml bottle about 1/6 full takes over a minute to detonate. A 2L bottle takes longer.
Another thing that makes it go off much faster is if there is water in the bottle when you put the nitrogen in, because water conducts heat to the nitrogen much faster than plastic and air.
I was serious when I said to stand on the other side of the room:)
see http://www.faqs.org/rfcs/rfc793.html. figure 6 is a TCP state diagram, which shows that if you receive a FIN, you send an ACK, close your half of the connection, send a FIN, and wait for an ACK of your FIN. In any decent TCP stack, the ACK and FIN would be sent in the same packet, so yes, you send back an ACK+FIN packet. They could be sent separately. Other than that, an RFC conforming TCP stack doesn't have too much choice in the matter.
DMA is the thing I'm worried most about. The DMCA is nothing. Think of how bad it will be when corporations have Direct Memory Access to your brain! #define X(x,y) x##y
> 3. The General Protection Fault: One error that covers all problems. Reboot.
The GPF is a part of the IA32 architecture, AFAIK. I've seen the Linux kernel GPF at least once since I've been using it. (~3 years or so.) The message gets saved by klogd->syslogd->/var/log/... I can't remember, but I might have done something that provoked the crash:) I haven't seen Linux crash for almost a whole year now, over several computers. (had a nasty one with netscape somehow causing the whole system to lock solid... couldn't even ssh in.)
It is true that Windows triggers way too many GPFs, though. I guess it doesn't do enough error checking or have the error handlers to detect inconsistencies in its data structures and complain before something bad happens. (also, it lets too many bad things happen in the first place.) #define X(x,y) x##y
Free software holds it's own pretty well, I'd say. perl, LaTeX, Python, TCL/TK, GNU findutils (locate+updatedb), freenet, gnutella, emacs, netcat, ghostscript, readline, sendmail, mozilla (wrt. it's XUL programmability, not just that it's a web browser), the Debian package system, and many more. Also, ever look at netlib.org? happy now?
Simon Tatham who wrote PuTTY also wrote pscp, an SCP client for Win32. It's command line, but works great. BTW, PuTTY has great terminal emulation and speed, unlike MS Telnet and QVT/net (which Dal installs in their PC computer labs.) (BTW, I think MS fixed their telnet client in win2k, so it doesn't suck nearly so much now.)
For MacOS, there's NiftyTelnetSSH, which includes SCP support. (and decent, fast terminal emulation, unlike NCSA telnet.)
All these programs are gratis, but NiftyTelnet might not be libre. (PuTTY and pscp are.)
>but a dedicated cracker will find a way in anyway if they really want to
We're talking about university residence networks. On most such networks there would be very few people who would consider making a good, well-planned attack. There are a _lot_ of people with some free time, curiosity, and knowledge who can easily sniff networks for passwords (unless the networks are fully switched.) These are the people that make telnet and ftp a Bad idea in a university network.
Think about how many people just memorize how to upload files using what to them might as well be voodoo. Teaching them scp voodoo instead of ftp voodoo makes little difference to them, since they don't understand what's going on either way, but then they will be doing their uploads in the best way possible:) #define X(x,y) x##y
If Unix ever takes over the business desktop, there will be a market for commercial software. As long as it's only home users that would want tools like this, not many people will be willing to fork over cash. This changes a lot when you can get your company to pay for tools that are supposed to do what you need out of the box, especially if you are using Unix because that's what was on your desk when you showed up, instead of because you're a good hacker and installed it yourself because you know you'd be more productive with it. (good hackers wouldn't be concerned with working right out of the box and all that, because they can fix anything that might go wrong while installing a free tool. (especially if it is a libre-free tool, so they can recompile for their system if necessary, etc.) #define X(x,y) x##y
I didn't say we shouldn't try to find out whether the nukes still work. I'm sure some models last longer than others, so maybe the US should let all but a few of them go. (i.e. dismantle them once they're no good.) It's always good to know what you do have, and that's separate from what you think you need to have.
I don't have any good solutions, but I do know that the current state of affairs sucks.
> argue all you want that we shouldn't have nukes; write your congressmen, campaign on Capitol Hill, etc.
I live in Canada, the only country in the world (AFAIK) that could build nukes, but chooses not to. (Of course, we are cheating by living under the umbrella of the US and NATO, but we do get to say we ourselves don't have any.) #define X(x,y) x##y
Good point. Last term, I did an experiment to find the band gap of some semiconductors as a function of temperature. For the silicon diode I tested, carrier depletion didn't have much of an effect even at 77K. The band forward voltage at 2mA did increase noticeably, though. OTOH, the LED I used wouldn't conduct more than a few 1/10ths of a milliamp, even at something like 10 volts once it was down to 77K. Figure 5 in the paper I did shows this quite well.
BTW, there are a lot of fun things you can do with liquid nitrogen... If you put it in a pop bottle and screw on the lid, then put the pop bottle under a cardboard box and stand on the other side of the room, it makes a big bang:) If you pour cola into a dewar of liquid nitrogen, it freezes in mid-fizz, leaving a popcorn-like substance which is fun to eat (don't eat too much at once, or your teeth and tongue won't be happy!). Also fun is pouring nitrogen on the floor and watching it roll along in beads held up by the Leidenfrost effect. (boiling at the bottom creates enough pressure to keep a layer of gas between the liquid and the solid, so thermal conductivity is low. This is the same effect that makes water drops dance on a hot stove top.) Pouring nitrogen on the floor is especially fun if you are a lab TA and there are still a bunch of first year students finishing their lab reports. They scare easily:) (of course, they were sitting on stools, so I didn't give anyone frostbite.) #define X(x,y) x##y
Currently, telecommunications WDM (wavelength-division multiplexing, i.e. sending multiple signals on multiple light frequencies) fiber-optics gear typically uses 50GHz channel spacing. New stuff that has 25GHz channel spacing is starting to get developed, and a lot of 100 and 200 GHz stuff is deployed. (These channels are defined by the ITU, and are in the range of 194 to 196 THz (~1520 - 1565 nm wavelength). This is the so-called C band. L band is longer wavelength, and S band is shorter wavelength.) #define X(x,y) x##y
> no new weapons will _have_ to be made for a while
(emphasis mine)
US (and most other) politicians sicken me. Can't they sleep at night withouth knowing that they have enough firepower to end life on earth? Do they honestly think to themselves, "our nukes are expired, so we can't blow up the world anymore. We have no choice but to make more." Why can't they just let some/all of them go?
(yes, I know about MAD, and all that.) #define X(x,y) x##y
While electromagnetic computers follow an exponential trend of increasing performance, quantumn computers double their performance each time a single atom is added to the device!
You're talking nonsense. exponential performance increase is doubling with every addition of another computing element. You just claimed that quantum and conventional computers are the same.
It would be sweet to have a quantum computer that could be scaled up enough to process such big problems, we don't. Therefore, IBM's kick-ass computer is a good start. Right now, no quantum computers can approach that size of problem! Nobody's figured out how to not disturb the quantum states for long enough. #define X(x,y) x##y
you can use PC100 RAM at 66MHZ. My home computer is doing that right now. 1 stick of 32MB PC66 SDRAM, 1 stick of 32MB PC100 SDRAM on a Shuttle Spacewalker MOBO. (Intel 430TX chipset.) #define X(x,y) x##y
> First, the Mac still lacks pre-emptive > multi-tasking, and it's future has never been >brighter, so why should RiscOS be different?
Its _future_ is bright because Apple's about to release MacOS X, which uses a BSD kernel, thus bringing modern memory management and pre-emptive multitasking. Current MacOS versions are still crap. (they are nice to use if you know and like the MacOS GUI, and you don't do anything that makes you wish you had a pre-emptive multi-tasking!)
>I just recently saw a falcon board that > was ATX with PCI support
Go Atari:) My first home computer was a 1040ST:) #define X(x,y) x##y
The StrongARM is not a gamer's CPU, since it has bad FPU performance relative to its integer performance. It might be fun to set up just for the heck of it, though:)
Slashdot Mirror
That might be the case for some cards, but isn't it possible to render into an off-screen buffer, and then read the contents of that buffer? Doesn't a 3D video card help when rendering images that you intend to save, not just show once? (I don't have one, so I can't check on this.)
It's a tough hoop to jump through to have to do that to crunch numbers, but it might be theoretically possible. (No idea whether you could do anything that's faster than just using the CPU, though, since there would be overhead to messing with the video card.)
That would make an interesting (well, pretty crappy actually) screen-saver: The raw data flashes over your video RAM... kind of like those old calculators that used the screen-display register as part of their calculations, making the numbers dance like crazy.)
#define X(x,y) x##y
> I have plenty of high-spec hardware to run SETI on anyway
:->
A geek can never have too much hardware. What's wrong with you?
#define X(x,y) x##y
I wonder if it would be possible to use any of processing power of accelerated video cards to help crunch SETI, gamma flux, or some other floating point (or integer, like OGR and RC5) number crunching thing? I've never looked at programming specs for any video cards, so I don't know which, if any, would be flexible enough to do computing tasks other than 3d rendering.
The vector nature of video card processors makes them sound nice for crunching SETI's arrays, unfortunately, this sounds like wishful thinking, but maybe worth looking into. Maybe a lighting engine could help with dcypher.net's gamma ray projections?
Anyone out there intimately familiar with any particular video hardware? How could it be used for any of these projects?
#define X(x,y) x##y
Linux uses the native word size of the machine for file offsets, so on 32bit architectures, file sizes are limited to 2GB, while on 64bit archs, Linux can handle files up to 8EB (1 exabyte ~= 1 million terabyte).
Recently, large file support on 32bit archs has been developed, but it isn't in the main kernel yet, AFAIK.
#define X(x,y) x##y
Using raw disk partitions is not the same thing as Linux's "raw block device" support, which lets you access block devices without going through the buffer-cache layer. Some database programs want to use this so they can do their own caching, etc. However, lots of things access block devices, e.g. /dev/hda1, for example mkfs, and fdisk. The raw block device support is still very new, and was developed by Steven Tweedie. It uses kiobufs to do zero-copy IO. You would know about this if you were at the second memory management talk, given by Ben LaHaise, at the Ottawa Linux Symposium last week :)
So, unless it's the database's release notes that say not to use whole disk partitions, there should be no problem. The kernel lets you access a disk partition as a big file very easily.
#define X(x,y) x##y
I think that's a brain-fart, not a typo, since "communicative" is not a very likely misspelling for "commutative". OTOH, I don't think "commutative" is the right word either. I think "reversible" is more like it.
:-) (hehe, just kidding.)
Oh well, only a video game programmer, what can you expect...
#define X(x,y) x##y
This is foolish. SETI@HOME uses a lot of memory. It does FFTs and other matrix/array operations on large data sets. I think the reason he sees the same performance with a Katmai PIII@550MHz and a Coppermine PIII@550MHz is not that the working set fits in the Coppermine's 256kB L2 cache, but that it is much bigger than the Katmai's 512kB L2 cache. They get the same performance because they have the same memory bandwidth (100MHz FSB) and FPU performance. I don't know why the Celeron lags, but it might be because of a worse FPU. (I haven't bothered to keep all of Intel's chips straight.)
As for the author's suggestion that a K7 or Duron would have equal performance, I wouldn't be surprised if an Athlon or Duron (or especially a Thunderbird) beat the pants off of Intel, because they run a faster memory bus. (This only applies if you have RAM that can keep up with the bus, like DDR SDRAM, though.) I think RAMBUS ram is well suited to this task, since there's lots of sequential access and memory bandwidth is more important than latency here.
The author really should have tried a benchmark on a machine with a bus other than 100MHz. Silly person :)
#define X(x,y) x##y
It's a _radio_ telescope. Of course it doesn't sense neutrinos. It's really hard to do that, BTW. A neutrino can go through miles of lead with only a very slight chance of interacting with the lead. Current neutrino detectors are big tanks of heavy water (D2, deuterium) with photomultipliers all around.
#define X(x,y) x##y
Yet another reason to like Debian... Zero dollars are spent on marketing, so you know they're not paying anyone (directly or indirectly) to trick you.
Of course, if you're smart and knowledgeable enough to evaluate your options for yourself, do that and pick the best software, regardless of marketing. For me, Debian is the best software I've found yet, but YMMV.
#define X(x,y) x##y
yeah, I've seen a guy pick up a pop bottle from under the cardboard box because he though it was leaking and wasn't going to explode. Luckily for him, he was wearing a leather glove. He got cut on the chin, and his hand was numb for days. Moral: always put the pop bottle under something to absorb the shock wave, and don't get too curious too soon.
:)
The trick to doing it right is to fill the bottle less than a quarter of the way full, so there is lots of volume to compress. A 600ml bottle about 1/6 full takes over a minute to detonate. A 2L bottle takes longer.
Another thing that makes it go off much faster is if there is water in the bottle when you put the nitrogen in, because water conducts heat to the nitrogen much faster than plastic and air.
I was serious when I said to stand on the other side of the room
#define X(x,y) x##y
> expert clarification welcome :)
:-)
Is Jon Postel good enough?
see http://www.faqs.org/rfcs/rfc793.html. figure 6 is a TCP state diagram, which shows that if you receive a FIN, you send an ACK, close your half of the connection, send a FIN, and wait for an ACK of your FIN. In any decent TCP stack, the ACK and FIN would be sent in the same packet, so yes, you send back an ACK+FIN packet. They could be sent separately. Other than that, an RFC conforming TCP stack doesn't have too much choice in the matter.
#define X(x,y) x##y
> And, of course, the DMA, Doubleclick,
DMA is the thing I'm worried most about. The DMCA is nothing. Think of how bad it will be when corporations have Direct Memory Access to your brain!
#define X(x,y) x##y
> 3. The General Protection Fault: One error that covers all problems. Reboot.
:) I haven't seen Linux crash for almost a whole year now, over several computers. (had a nasty one with netscape somehow causing the whole system to lock solid... couldn't even ssh in.)
The GPF is a part of the IA32 architecture, AFAIK. I've seen the Linux kernel GPF at least once since I've been using it. (~3 years or so.)
The message gets saved by klogd->syslogd->/var/log/... I can't remember, but I might have done something that provoked the crash
It is true that Windows triggers way too many GPFs, though. I guess it doesn't do enough error checking or have the error handlers to detect inconsistencies in its data structures and complain before something bad happens. (also, it lets too many bad things happen in the first place.)
#define X(x,y) x##y
Free software holds it's own pretty well, I'd say. perl, LaTeX, Python, TCL/TK, GNU findutils (locate+updatedb), freenet, gnutella, emacs, netcat, ghostscript, readline, sendmail, mozilla (wrt. it's XUL programmability, not just that it's a web browser), the Debian package system, and many more. Also, ever look at netlib.org? happy now?
#define X(x,y) x##y
For MacOS, there's NiftyTelnetSSH, which includes SCP support. (and decent, fast terminal emulation, unlike NCSA telnet.)
All these programs are gratis, but NiftyTelnet might not be libre. (PuTTY and pscp are.)
For Unix, of course, there's OpenSSH.
For VMS, there's an FAQ, which recommends a server and a client.
#define X(x,y) x##y
>but a dedicated cracker will find a way in anyway if they really want to
:)
We're talking about university residence networks. On most such networks there would be very few people who would consider making a good, well-planned attack. There are a _lot_ of people with some free time, curiosity, and knowledge who can easily sniff networks for passwords (unless the networks are fully switched.) These are the people that make telnet and ftp a Bad idea in a university network.
Think about how many people just memorize how to upload files using what to them might as well be voodoo. Teaching them scp voodoo instead of ftp voodoo makes little difference to them, since they don't understand what's going on either way, but then they will be doing their uploads in the best way possible
#define X(x,y) x##y
If Unix ever takes over the business desktop, there will be a market for commercial software. As long as it's only home users that would want tools like this, not many people will be willing to fork over cash. This changes a lot when you can get your company to pay for tools that are supposed to do what you need out of the box, especially if you are using Unix because that's what was on your desk when you showed up, instead of because you're a good hacker and installed it yourself because you know you'd be more productive with it. (good hackers wouldn't be concerned with working right out of the box and all that, because they can fix anything that might go wrong while installing a free tool. (especially if it is a libre-free tool, so they can recompile for their system if necessary, etc.)
#define X(x,y) x##y
I didn't say we shouldn't try to find out whether the nukes still work. I'm sure some models last longer than others, so maybe the US should let all but a few of them go. (i.e. dismantle them once they're no good.) It's always good to know what you do have, and that's separate from what you think you need to have.
I don't have any good solutions, but I do know that the current state of affairs sucks.
> argue all you want that we shouldn't have nukes; write your congressmen, campaign on Capitol Hill, etc.
I live in Canada, the only country in the world (AFAIK) that could build nukes, but chooses not to. (Of course, we are cheating by living under the umbrella of the US and NATO, but we do get to say we ourselves don't have any.)
#define X(x,y) x##y
BTW, there are a lot of fun things you can do with liquid nitrogen... If you put it in a pop bottle and screw on the lid, then put the pop bottle under a cardboard box and stand on the other side of the room, it makes a big bang :) If you pour cola into a dewar of liquid nitrogen, it freezes in mid-fizz, leaving a popcorn-like substance which is fun to eat (don't eat too much at once, or your teeth and tongue won't be happy!). Also fun is pouring nitrogen on the floor and watching it roll along in beads held up by the Leidenfrost effect. (boiling at the bottom creates enough pressure to keep a layer of gas between the liquid and the solid, so thermal conductivity is low. This is the same effect that makes water drops dance on a hot stove top.) Pouring nitrogen on the floor is especially fun if you are a lab TA and there are still a bunch of first year students finishing their lab reports. They scare easily :) (of course, they were sitting on stools, so I didn't give anyone frostbite.)
#define X(x,y) x##y
Currently, telecommunications WDM (wavelength-division multiplexing, i.e. sending multiple signals on multiple light frequencies) fiber-optics gear typically uses 50GHz channel spacing. New stuff that has 25GHz channel spacing is starting to get developed, and a lot of 100 and 200 GHz stuff is deployed. (These channels are defined by the ITU, and are in the range of 194 to 196 THz (~1520 - 1565 nm wavelength). This is the so-called C band. L band is longer wavelength, and S band is shorter wavelength.)
#define X(x,y) x##y
> no new weapons will _have_ to be made for a while
(emphasis mine)
US (and most other) politicians sicken me. Can't they sleep at night withouth knowing that they have enough firepower to end life on earth? Do they honestly think to themselves, "our nukes are expired, so we can't blow up the world anymore. We have no choice but to make more." Why can't they just let some/all of them go?
(yes, I know about MAD, and all that.)
#define X(x,y) x##y
You're talking nonsense. exponential performance increase is doubling with every addition of another computing element. You just claimed that quantum and conventional computers are the same.
It would be sweet to have a quantum computer that could be scaled up enough to process such big problems, we don't. Therefore, IBM's kick-ass computer is a good start. Right now, no quantum computers can approach that size of problem! Nobody's figured out how to not disturb the quantum states for long enough.
#define X(x,y) x##y
you can use PC100 RAM at 66MHZ. My home computer is doing that right now. 1 stick of 32MB PC66 SDRAM, 1 stick of 32MB PC100 SDRAM on a Shuttle Spacewalker MOBO. (Intel 430TX chipset.)
#define X(x,y) x##y
> First, the Mac still lacks pre-emptive
:) My first home computer was a 1040ST :)
> multi-tasking, and it's future has never been
>brighter, so why should RiscOS be different?
Its _future_ is bright because Apple's about to release MacOS X, which uses a BSD kernel, thus bringing modern memory management and pre-emptive multitasking. Current MacOS versions are still crap. (they are nice to use if you know and like the MacOS GUI, and you don't do anything that makes you wish you had a pre-emptive multi-tasking!)
>I just recently saw a falcon board that
> was ATX with PCI support
Go Atari
#define X(x,y) x##y
> I'd like to try one sometime.
:)
The StrongARM is not a gamer's CPU, since it has bad FPU performance relative to its integer performance. It might be fun to set up just for the heck of it, though
#define X(x,y) x##y