Yes I read the article. The post I'm replying asked what the advantage was over a p90 with a hard disk and sound card. The advantage is no fans. With this device and a network connection, your fans and hard disks can be in another room, building, or nation.
The problem with a P90 and a few hard disks is that you can hear all those fans and platter spinning around. Kinda spoils the listening experience, I think. Well, MP3 ruins the listening experience so maybe it's a wash.
A P90 barely has enough power to decode MP3 anyway.
For powermacs and especially powerbooks, you'd better go with benh. For other powerpc you might want to use paulus. I don't think the stock kernel is the best choice for any ppc.
If you want the emu10k1 to work properly you'd better just go try ALSA. In my ideal world ALSA will merge with the 2.5 kernel, but I wouldn't put money on it.
MQ and JMS are way, way heavier than what I'm talking about. The kernel is just delivering a message to a program, and there are a finite number of messages to be deliveres, for example:
The mouse has moved
Async read on FD n is complete
Async write on FD n is complete
FD n is ready for more data
FD n has closed
There kernel only delivers "The mouse has moved" once between times that the program pays attention to it. The program sees "The mouse has moved" and calls some code to get the mouse position.
So, we're talking about something really tiny like struct event of a few bytes at most, delivered not all that often.
No genius. The kernel handles the interrupts from the hardware delivers I/O events to user space via a queue. The program can come along and deal with the I/O events whenever it gets around to it.
The kernel is the RIGHT place for asynchronicity, because we definitely know what is happening when we get an interrupt on platform X. When programming in user space, who needs to deal with your program suddenly and unexpectedly jumping to a signal handler? You have NO idea where you are in the control flow. It's a stupid design, exacerbated by the non-uniform way different platforms deal with signals during system calls.
Two points 2 billion light years from each other could be moving apart very rapidly. Light leaving point A will need to cover more than 2 billion light years before reaching point B.
The entire concept of signals sucks. No wonder signals and threads do not mix.
Just say no to asynchronous delivery. Your program should be notified of events only when it calls dequeue_event() or whatever. For something that is really async like segmentation violation, your program should just get whacked without any opportunity to do anything else.
Getting rid of signals would solve most of the problems I perceive with programming in Unix.
The 15K has 106 CPUs, but they are the slowest CPUs on the market in SPEC benchmarks. The UltraSPARC III are slower than the 1300 MHz Power4, slower than the 833 MHz 21264B, slower than the 2000 MHz Pentium 4, slower than the 800 MHz Itanium in FP but faster in integer, and not any faster than the 1200 MHz Athlon MP. The only CPU that is slower is the 552 MHz PA-8600, and the UltraSPARC III barely beats it. The PA-8600 will be replaced imminently by the 750 MHz PA-8700, while the 833 MHz 21264B will soon be replaced by the astonishingly fast 1000 MHz 21264B.
But wait! you say, SPEC numbers aren't everything. Yes the 15K has some seriously inter CPU bandwidth and big-time scalability. Problem for the 15K is that the Power4's inter-CPU bandwidth makes the 15K look like a beowulf cluster running over appletalk. The Power4 has a two cores sitting right next to each other on the same die and can/does have four or more of these double cores wired together in the same package with 128 MB L3 memory bank. The Power4's system bandwidth is 92 GB/s, or 38 times higer than the UltraSPARC III.
It's time to euthanize the poor old UltraSPARC CPU line.
I'll bet dollars-to-donuts that we never, ever see EV7 machines. Compaq killed it, they are just trying to be weasels by stringing us along on the EV7 boat. But, I don't think they have any intentions of actually producing it.
I dislike the "bigger + louder is better" notion in the do-it-yourself computer hardware community. I think this idea has been planted by the same people who drive Camaros and Mustangs:) Seriously, there is NO reason to get a huge brick of a heatsink for these new Athlons. What is needed is a heatsink and fan combination designed by actual engineers from an actual engineering company, like, for example, Hewlett Packard. Look, here's one:
The Agilent cooler is small so it presents no mounting problems. It is very light, so it won't shear the socket off your mainboard. It is quiet, so it won't drive your wife/husband/parents/kids/dog/cat/neighbors berserk. Best of all, it cools the 1.4 GHz Athlon better than any other cooler around, including those enormous bricks with 8500 RPM fans.
Thanks for the info I wasn't thinking when I compared compile times. When I get my OS X 10.1 system installed this Saturday, I intend to benchmark some things between that system and the same machine running Debian. For example, filter through a 10MB tcpdump capture, some other things like that.
Ooh, good point! I'd be pretty bent out of shape if i was paying for radio service and it started to get all out of shape because of solar activity. As it is, FM reception in my city is pretty nearly perfect. Artifacts in a digital satellite service would be really disappointing.
BTW, I'd definitely buy this service if the receiver has a digital output. And if they carry NPR.
Is there some particular reason why you couldn't just grab this radio feed out of the air? Sure, you might have to reverse-engineer/hack the top secret elite XOR key out of an existing radio, but after that, what's stopping you?
I use Debian PPC on a PowerBook G4, and it's a little slow. For everyday interactive use like email and web browsing, it is the equal of all my other systems. For anything that taxes the CPU, it's a pig. For example, compiling ethereal takes over 7 minutes. On my desktop (1.4 GHz athlon) it takes a little under 1 minute. That's not really proportionate. People claim that GCC doesn't produce efficient code on the PPC, but I don't know the technical details of that. I do know that OS X takes advantage of the AltiVec unit on the G4, while almost no Linux software (only mpeg2dec to my knowledge) does so.
The PGP signature at the end of this article is unverifiable. Can you please link to a version of the article with proper begin/end borders and whitespace preserved?
I know about the/proc setting, but the kernel overcommits regardless of your preference. It just does it more or less aggressively. Either way, the kernel will deliver SIGBUS to your process just because you tried to use some memory that was sucessfully allocated. How is any programmer supposed to deal with that?
I hope I'm wrong too, but I'm right. The 2.4.9 VM didn't understand pages that were only read once, as by a DVD player. Hence all of the read-once patches floating around on l-k lately. Most of them are questionable hacks, but the idea, as you note, has been around for a long time and should be implemented.
Simple test: dd if=/dev/dfd of=/dev/null, then see if your other programs got swapped out.
This is rubbish. The reason that Linux 2.4.x systems get into swap when running XMMS is because they read from the disk a lot, and they only need the page they read once. Consider an XMMS process that reads 4GB of MP3 from the disk over the course of a day. Well, Rik's VM is going to push *all* other processes out of memory in order to cache all of those disk pages that nobody ever wants to see again. Obviously this is the wrong policy. But, Rik the megalomaniac is never going to fix it because he's convinced that his system is the best thing that can be acheived by human beings. He should get together and have a beer with Hans Reiser.
Slashdot Mirror
Yes I read the article. The post I'm replying asked what the advantage was over a p90 with a hard disk and sound card. The advantage is no fans. With this device and a network connection, your fans and hard disks can be in another room, building, or nation.
A P90 barely has enough power to decode MP3 anyway.
He can't afford it because that 3 bucks goes into the prosecution fund for people like Dmitry Sklyarov and 2600.
For powermacs and especially powerbooks, you'd better go with benh. For other powerpc you might want to use paulus. I don't think the stock kernel is the best choice for any ppc.
Rik's VM is not any more stable nor faster than AA's. Incumbency is no reason to keep it.
If you want the emu10k1 to work properly you'd better just go try ALSA. In my ideal world ALSA will merge with the 2.5 kernel, but I wouldn't put money on it.
MQ and JMS are way, way heavier than what I'm talking about. The kernel is just delivering a message to a program, and there are a finite number of messages to be deliveres, for example:
The mouse has moved
Async read on FD n is complete
Async write on FD n is complete
FD n is ready for more data
FD n has closed
There kernel only delivers "The mouse has moved" once between times that the program pays attention to it. The program sees "The mouse has moved" and calls some code to get the mouse position.
So, we're talking about something really tiny like struct event of a few bytes at most, delivered not all that often.
No genius. The kernel handles the interrupts from the hardware delivers I/O events to user space via a queue. The program can come along and deal with the I/O events whenever it gets around to it.
The kernel is the RIGHT place for asynchronicity, because we definitely know what is happening when we get an interrupt on platform X. When programming in user space, who needs to deal with your program suddenly and unexpectedly jumping to a signal handler? You have NO idea where you are in the control flow. It's a stupid design, exacerbated by the non-uniform way different platforms deal with signals during system calls.
Two points 2 billion light years from each other could be moving apart very rapidly. Light leaving point A will need to cover more than 2 billion light years before reaching point B.
A train leaves new york at 3:00 heading north...
Just say no to asynchronous delivery. Your program should be notified of events only when it calls dequeue_event() or whatever. For something that is really async like segmentation violation, your program should just get whacked without any opportunity to do anything else.
Getting rid of signals would solve most of the problems I perceive with programming in Unix.
But wait! you say, SPEC numbers aren't everything. Yes the 15K has some seriously inter CPU bandwidth and big-time scalability. Problem for the 15K is that the Power4's inter-CPU bandwidth makes the 15K look like a beowulf cluster running over appletalk. The Power4 has a two cores sitting right next to each other on the same die and can/does have four or more of these double cores wired together in the same package with 128 MB L3 memory bank. The Power4's system bandwidth is 92 GB/s, or 38 times higer than the UltraSPARC III.
It's time to euthanize the poor old UltraSPARC CPU line.
I'll bet dollars-to-donuts that we never, ever see EV7 machines. Compaq killed it, they are just trying to be weasels by stringing us along on the EV7 boat. But, I don't think they have any intentions of actually producing it.
The power4 is kicking everybody's ass on SPEC 2000. 783 SPECint2000 base and 1098 SPECfp2000 base. Check out the comparisons on Ace's Hardware.
Bob's Quick Guide to the Apostrophe, You Idiots
OMG that thing is enormous. I wonder what kind of moment it exerts on the CPU socket!
Agilent ArctiCooler HACA-0002
The Agilent cooler is small so it presents no mounting problems. It is very light, so it won't shear the socket off your mainboard. It is quiet, so it won't drive your wife/husband/parents/kids/dog/cat/neighbors berserk. Best of all, it cools the 1.4 GHz Athlon better than any other cooler around, including those enormous bricks with 8500 RPM fans.
Thanks for the info I wasn't thinking when I compared compile times. When I get my OS X 10.1 system installed this Saturday, I intend to benchmark some things between that system and the same machine running Debian. For example, filter through a 10MB tcpdump capture, some other things like that.
BTW, I'd definitely buy this service if the receiver has a digital output. And if they carry NPR.
Right. "Encrypted". And every XM receiver in the field knows how to decrypt it. So it's probably pretty simple like CSS.
Is there some particular reason why you couldn't just grab this radio feed out of the air? Sure, you might have to reverse-engineer/hack the top secret elite XOR key out of an existing radio, but after that, what's stopping you?
I use Debian PPC on a PowerBook G4, and it's a little slow. For everyday interactive use like email and web browsing, it is the equal of all my other systems. For anything that taxes the CPU, it's a pig. For example, compiling ethereal takes over 7 minutes. On my desktop (1.4 GHz athlon) it takes a little under 1 minute. That's not really proportionate. People claim that GCC doesn't produce efficient code on the PPC, but I don't know the technical details of that. I do know that OS X takes advantage of the AltiVec unit on the G4, while almost no Linux software (only mpeg2dec to my knowledge) does so.
The PGP signature at the end of this article is unverifiable. Can you please link to a version of the article with proper begin/end borders and whitespace preserved?
I know about the /proc setting, but the kernel overcommits regardless of your preference. It just does it more or less aggressively. Either way, the kernel will deliver SIGBUS to your process just because you tried to use some memory that was sucessfully allocated. How is any programmer supposed to deal with that?
Simple test: dd if=/dev/dfd of=/dev/null, then see if your other programs got swapped out.
This is rubbish. The reason that Linux 2.4.x systems get into swap when running XMMS is because they read from the disk a lot, and they only need the page they read once. Consider an XMMS process that reads 4GB of MP3 from the disk over the course of a day. Well, Rik's VM is going to push *all* other processes out of memory in order to cache all of those disk pages that nobody ever wants to see again. Obviously this is the wrong policy. But, Rik the megalomaniac is never going to fix it because he's convinced that his system is the best thing that can be acheived by human beings. He should get together and have a beer with Hans Reiser.