I think it might really be more a matter that the tarantulas whose venom activated these receptors had a far greater success in the wild; I don't think it's particularly accurate to say that things evolve based on their perception of their environment because, well, no one chooses how they evolve (though we're coming damn close to being able to).
I used to think so too, but then qmail's CRAM-MD5 patch didn't work on my machine. Among other things, while I think Linux-AMD64 treats "int" as 32 bit, it treats "long int" as 64-bit. This causes problems if people assume "long int" means 32-bit, which a lot do. This is why for size-critical stuff, I always make it explicit, with types like u_int32_t and such.
After all, OpenFirmware works quite nicely on other machines, notably PowerPC ones. There's lots of booting mechanisms that they could use without designing a new one that will, presumably, be somewhat biased towards Windows.
One that I've used recently that's worked phenomenally has been Future System Solutions' Casper XP. It let me copy my active system drive (while the system was running off it) off a 30 GB drive to an 80, resizing the partiton, all without having to stop anything. I did this to move from an older drive to a newer Serial ATA drive. It works like a charm, everything behaves exactly like it did before, it's only $45, and it's pretty easy to use. Probably not as fast as Ghost, but I found the interface to be somewhat more pleasant.
No, see, the point is that the university was contractually required to pay the 80% cancellation fee on the hotel. This is money they have *already* lost. What seems inexcusable to me is that they told the hotel to unconditionally cancel the rooms, and under no condition should the OpenBSD people be allowed to pay the other twenty percent and get the rooms. It appears they would rather waste the money they've already lost in order to twist the knife a bit further.
It was the UPENN folks who still had to pay 80% of the hotel fee for the cancellation (that's 24k canadian that they paid). It was also the UPENN folks who convinced the hotel not to let the OpenBSD folks pay the remaining 20% of the hotel bill, preferring to simply waste the 80% they had to pay anyway. Seems a little childish to me.
Well, yes. Perhaps I got carried away... I was, er, evangelizing the potential of the AVR for great things.:-)
On the other hand, Atmel does make very small scale AVRs. And the instruction set is still nicer... I have nightmares about PIC code (though it's still better than CISC).
Definitely the way to go with this. You'll probably want to go with ones with a USART (for a serial connection) and output data to some PWMs (pulse width modulators) to control the brightness. You don't need relays. My recommendation would be to start with the Atmel AVR... it has one of the nicest instruction sets I've seen in a microcontroller, it's cheap, it's fast, and you can get them with HUGE amounts of prgram memory (up to 128K).
Why use wuftpd when it's so trivial to install proftpd (which is, incidentally, also easier to configure)? wuftpd is dangerous to run because it's so patched as to be in the same state BIND 8 is in. Honestly, just because it's the "default" doesn't make it acceptable to run a patchwork server. That's about as dangerous as running a Microsoft server just because it's "industry standard" (which isn't true anyway).
And just as an aside, I respect RedHat for preemptively notifying people, H4XX0R5 included. If Apache were to have a horrible root-access-blows-up-your-site kind of hole discovered, I'd want that kind of incentive to upgrade soon. It's better than saying "There's a hole, we're working on fixing it, just wait and hope that someone doesn't figure it out from our context clues".
Umm, hey... For those of us who can't afford an Athlon of the same clock speed ($200 difference at 700 MHz), the Duron's pretty good... It even beats p3's at quake 3 in places. They're a TBird with acceptably less cache. Not a bad idea. And Tom's Hardware claims a stable 900 MHz Duron clocked from a 700. *I* would personally be happy to own a Duron 600, since a decent upgrade (the bus speed is rather important here) for just over $200 of board, sound and chip (includeing FPU increases) from my K6-2 450 isn't bad. The Duron is the first low-end chip I've ever seen (and I've seen the 68LC040, the 603 and the Celeron) that I would be happy to own.
It's really a shame... At first, AMD supported the overclocking fully. The problem was that nasty resellers (like CompUSA) would grind the original markings off the faceplates and mark it up one jump (a 600 would become a 650, etc.) and people installing the chips in their computer would set the spped at that. This was _real_ common in the Socket 7 days, when there was no protection whatsoever for this, which is why K6 series had engraved metal faceplates instead of paint (it made remarking easier to spot).
Then AMD put the copper bridges on the top of the Socket A chips to set the multiplier, a technique which made it harder (while still possible) to change the clock, and which made remarking also quite apparent. If I understand the insane hardware article, this no longer works either.
This shows the problem that poor reselling techniques (i.e. fraudulent ones) can have with the community at large.
There's plenty of Linux support for PPC. We have Debian and RedHat (Not official redhat but LinuxPPC is a legitimate company), and LinuxPPC supports SMP's. I think PPC linux has plenty of "serious" support.
A powerbook is a powermac. Unless you have one of the '040 powerbooks. Linux supports many PowerPC powerbooks, and i should imagine that Darwin does, too.
Actually, LinuxPPC is coming pretty close to booting on NuBus machines (the 5500 is semi-worknig). I'd get a LinuxPPC CD (because it includes MkLinux anyway) and wait while you run MkLinux.
The main point about PowerPC's being RISC vs. x86 processors being CISC is that even though the CISC processors run on RISC cores, the fact that each of the x86 instructions is still CISC and so it's almost impossible to pipeline it as efficiently as a PowerPC (or MIPS, or whatever). What intel, AMD, et al should have done when moving to RISC cores is something very similar to what Apple/IBM/Motorola did when moving to PowerPC: be backwards-compatible with old programs but allow access to the RISC core. It's exactly what Intel is doing with IA-64.
Besides, there hasn't been a major change in the Intel family of processors for 25 years. They still run the same instructions (with a few added, just like Motorola did with upgrades of the 68000 architecture), and it's an awful kluge to force people to run in CISC emulation. At least with PowerPC you can still use the RISC part of the processor.
Slashdot Mirror
If you have to write bootloaders and a very small number of other programs or routines. For most purposes, yes, it's rather counterproductive.
I think it might really be more a matter that the tarantulas whose venom activated these receptors had a far greater success in the wild; I don't think it's particularly accurate to say that things evolve based on their perception of their environment because, well, no one chooses how they evolve (though we're coming damn close to being able to).
I used to think so too, but then qmail's CRAM-MD5 patch didn't work on my machine. Among other things, while I think Linux-AMD64 treats "int" as 32 bit, it treats "long int" as 64-bit. This causes problems if people assume "long int" means 32-bit, which a lot do. This is why for size-critical stuff, I always make it explicit, with types like u_int32_t and such.
After all, OpenFirmware works quite nicely on other machines, notably PowerPC ones. There's lots of booting mechanisms that they could use without designing a new one that will, presumably, be somewhat biased towards Windows.
One that I've used recently that's worked phenomenally has been Future System Solutions' Casper XP. It let me copy my active system drive (while the system was running off it) off a 30 GB drive to an 80, resizing the partiton, all without having to stop anything. I did this to move from an older drive to a newer Serial ATA drive. It works like a charm, everything behaves exactly like it did before, it's only $45, and it's pretty easy to use. Probably not as fast as Ghost, but I found the interface to be somewhat more pleasant.
No, see, the point is that the university was contractually required to pay the 80% cancellation fee on the hotel. This is money they have *already* lost. What seems inexcusable to me is that they told the hotel to unconditionally cancel the rooms, and under no condition should the OpenBSD people be allowed to pay the other twenty percent and get the rooms. It appears they would rather waste the money they've already lost in order to twist the knife a bit further.
It was the UPENN folks who still had to pay 80% of the hotel fee for the cancellation (that's 24k canadian that they paid). It was also the UPENN folks who convinced the hotel not to let the OpenBSD folks pay the remaining 20% of the hotel bill, preferring to simply waste the 80% they had to pay anyway. Seems a little childish to me.
--
Well, yes. Perhaps I got carried away... I was, er, evangelizing the potential of the AVR for great things. :-)
On the other hand, Atmel does make very small scale AVRs. And the instruction set is still nicer... I have nightmares about PIC code (though it's still better than CISC).
Definitely the way to go with this. You'll probably want to go with ones with a USART (for a serial connection) and output data to some PWMs (pulse width modulators) to control the brightness. You don't need relays. My recommendation would be to start with the Atmel AVR... it has one of the nicest instruction sets I've seen in a microcontroller, it's cheap, it's fast, and you can get them with HUGE amounts of prgram memory (up to 128K).
*weeps*
For what it's worth.
Check it!
Why use wuftpd when it's so trivial to install proftpd (which is, incidentally, also easier to configure)? wuftpd is dangerous to run because it's so patched as to be in the same state BIND 8 is in. Honestly, just because it's the "default" doesn't make it acceptable to run a patchwork server. That's about as dangerous as running a Microsoft server just because it's "industry standard" (which isn't true anyway).
And just as an aside, I respect RedHat for preemptively notifying people, H4XX0R5 included. If Apache were to have a horrible root-access-blows-up-your-site kind of hole discovered, I'd want that kind of incentive to upgrade soon. It's better than saying "There's a hole, we're working on fixing it, just wait and hope that someone doesn't figure it out from our context clues".
Didn't I just see this story a few days ago with almost identical wording?
Umm, hey... For those of us who can't afford an Athlon of the same clock speed ($200 difference at 700 MHz), the Duron's pretty good... It even beats p3's at quake 3 in places. They're a TBird with acceptably less cache. Not a bad idea. And Tom's Hardware claims a stable 900 MHz Duron clocked from a 700. *I* would personally be happy to own a Duron 600, since a decent upgrade (the bus speed is rather important here) for just over $200 of board, sound and chip (includeing FPU increases) from my K6-2 450 isn't bad. The Duron is the first low-end chip I've ever seen (and I've seen the 68LC040, the 603 and the Celeron) that I would be happy to own.
It's really a shame... At first, AMD supported the overclocking fully. The problem was that nasty resellers (like CompUSA) would grind the original markings off the faceplates and mark it up one jump (a 600 would become a 650, etc.) and people installing the chips in their computer would set the spped at that. This was _real_ common in the Socket 7 days, when there was no protection whatsoever for this, which is why K6 series had engraved metal faceplates instead of paint (it made remarking easier to spot).
Then AMD put the copper bridges on the top of the Socket A chips to set the multiplier, a technique which made it harder (while still possible) to change the clock, and which made remarking also quite apparent. If I understand the insane hardware article, this no longer works either.
This shows the problem that poor reselling techniques (i.e. fraudulent ones) can have with the community at large.
There's plenty of Linux support for PPC. We have Debian and RedHat (Not official redhat but LinuxPPC is a legitimate company), and LinuxPPC supports SMP's. I think PPC linux has plenty of "serious" support.
A powerbook is a powermac. Unless you have one of the '040 powerbooks. Linux supports many PowerPC powerbooks, and i should imagine that Darwin does, too.
Actually, LinuxPPC is coming pretty close to booting on NuBus machines (the 5500 is semi-worknig). I'd get a LinuxPPC CD (because it includes MkLinux anyway) and wait while you run MkLinux.
The main point about PowerPC's being RISC vs. x86 processors being CISC is that even though the CISC processors run on RISC cores, the fact that each of the x86 instructions is still CISC and so it's almost impossible to pipeline it as efficiently as a PowerPC (or MIPS, or whatever). What intel, AMD, et al should have done when moving to RISC cores is something very similar to what Apple/IBM/Motorola did when moving to PowerPC: be backwards-compatible with old programs but allow access to the RISC core. It's exactly what Intel is doing with IA-64.
;-)
Besides, there hasn't been a major change in the Intel family of processors for 25 years. They still run the same instructions (with a few added, just like Motorola did with upgrades of the 68000 architecture), and it's an awful kluge to force people to run in CISC emulation. At least with PowerPC you can still use the RISC part of the processor.
And AltiVec beats the pants off SSE.