Now we get dupes right into the comments too!!
Best of all, no/. editors involved!
And modded +5, Informative???
now this is getting scary... I thought the editors were the only ones who didn't read the stories...
I tend to (dis)like anything onboard as much as the next slashdotter, but I've tried many soundcards, on and offboard (PC only, dunno about Macs), and the sound difference I feel is tiny enough to say that 90% of all regular PC users wouldn't even know the difference.
I would say that the big difference to sound quality lies on the amplifiers, and of course, on the speakers.
Myself, I use a Delta44 into an Alesis RA-100 which provides very low noise, and JBL speakers. Sound is as close to perfect as I would wish, meaning that it would only get better if I built new walls around here.
That is what I think makes the difference. There is no way a decent amplifier and good speakers can compare to the crappy $5 PC "amplified speakers".
There is one last difference: Impedance. But then again the crappy speakers wouldn't work with good cards.
But for Joe 16bit, onboard sound and SBLive! are just the same. (and yes, I own both of those too).
It's always like this with Open Source: Defendants claim it fits all the needs of today's proprietary solutions users and attackers come with the "immature and ugly" argument.
Of course Ardour is far away from being "pro" as in ProTools or Solid State Logic, but hey, might be a good solution for home recordings, demos and stuff.
Thing is, to make it real, Ardour should get at least better than Sonar, and better means not only having the same or more features (which it is already close to, as I've had my eye on this project for a while) but also being extremely easy to setup and use.
If I want to get Sonar working on my PC I only need to hit the "Next" button a couple of times. And this is usually the hard part when it comes to Linux projects, always suffering from (lack of) standardization.
Plus, and that is the big point to make me not migrate my little home studio to Ardour, software price is not a big deal. I still need a good sound card (mine is a Delta44, cost me $300 a couple of years ago), guitars (acoustic, electric, bass), drums and microphones (I use a Zoom RT-123 for drum sequencing, but if you use a real drum kit you'll find yourself spending a lot more on microphones), amplifier (mine is an Alesis - 100W) and good speakers (JBL Monitor1 for instance).
This ends all up costing $3k or so, making the price tag on the software not significant compared to ease of use.
For an IPv6 network to work, all hosts need to be aware of IPv6. That would be "native IPv6" (not sure about the term, but you get the picture!). That is, you need your ISP/OS/Routers/whatever is in the middle to know IPv6.
You could also tunnel IPv6 over IPv4, so two ends could communicate using IPv6 in a v4 network.
Or, you could use a gateway, like sixxs.org. There is some info in the link supplied in the article, but if you want the big stuff, please RTFRFC 2460!
Sorry, but there are some things to be taken into account here.
First of all, some of today's controllers (such as the HSGs or HP Smart Arrays) are running on pretty good RISC chips. Moreover, they have good amounts of memory to use as read ahead or writeback cache, which do speed up I/O instead of sharing memory with the OS.
About the speed of the controller's processor as compared to the main processor, just remember that, in today's standards, one SCSI channel could only work at 160MB/s, and, even if we needed one processor cycle for each byte to be read/written (we don't), we would only need a 160MHz processor to do the job.
Well, come think about it, processors embedded in today's modern RAID controllers usually have a 64-bit data bus. This means that any transaction is 8 bytes long. Being the worst case in performance a RAID-5 write (which involves 4 I/O operations) we still get an average of 2 bytes per processor cycle.
That's why RAID controllers don't come with fantastic processors -- there's simply no need to.
We could also think of availability, but that would be another long issue, and hardware RAID wins almost in all cases (except for controller multiplexing), but the best reason you would have to think about software raid would be the cost.
Slashdot Mirror
Now we get dupes right into the comments too!! /. editors involved!
Best of all, no
And modded +5, Informative???
now this is getting scary... I thought the editors were the only ones who didn't read the stories...
I tend to (dis)like anything onboard as much as the next slashdotter, but I've tried many soundcards, on and offboard (PC only, dunno about Macs), and the sound difference I feel is tiny enough to say that 90% of all regular PC users wouldn't even know the difference.
I would say that the big difference to sound quality lies on the amplifiers, and of course, on the speakers.
Myself, I use a Delta44 into an Alesis RA-100 which provides very low noise, and JBL speakers. Sound is as close to perfect as I would wish, meaning that it would only get better if I built new walls around here.
That is what I think makes the difference. There is no way a decent amplifier and good speakers can compare to the crappy $5 PC "amplified speakers".
There is one last difference: Impedance. But then again the crappy speakers wouldn't work with good cards.
But for Joe 16bit, onboard sound and SBLive! are just the same. (and yes, I own both of those too).
It's always like this with Open Source: Defendants claim it fits all the needs of today's proprietary solutions users and attackers come with the "immature and ugly" argument.
Of course Ardour is far away from being "pro" as in ProTools or Solid State Logic, but hey, might be a good solution for home recordings, demos and stuff.
Thing is, to make it real, Ardour should get at least better than Sonar, and better means not only having the same or more features (which it is already close to, as I've had my eye on this project for a while) but also being extremely easy to setup and use.
If I want to get Sonar working on my PC I only need to hit the "Next" button a couple of times. And this is usually the hard part when it comes to Linux projects, always suffering from (lack of) standardization.
Plus, and that is the big point to make me not migrate my little home studio to Ardour, software price is not a big deal. I still need a good sound card (mine is a Delta44, cost me $300 a couple of years ago), guitars (acoustic, electric, bass), drums and microphones (I use a Zoom RT-123 for drum sequencing, but if you use a real drum kit you'll find yourself spending a lot more on microphones), amplifier (mine is an Alesis - 100W) and good speakers (JBL Monitor1 for instance).
This ends all up costing $3k or so, making the price tag on the software not significant compared to ease of use.
Just my 2 cents.
Might be the 6th initiative. But don't worry, they're goin to get back to the source, and Zion will be destroyed again.
For an IPv6 network to work, all hosts need to be aware of IPv6. That would be "native IPv6" (not sure about the term, but you get the picture!). That is, you need your ISP/OS/Routers/whatever is in the middle to know IPv6.
You could also tunnel IPv6 over IPv4, so two ends could communicate using IPv6 in a v4 network.
Or, you could use a gateway, like sixxs.org. There is some info in the link supplied in the article, but if you want the big stuff, please RTFRFC 2460!
HTH!
Sorry, but there are some things to be taken into account here.
:)
First of all, some of today's controllers (such as the HSGs or HP Smart Arrays) are running on pretty good RISC chips. Moreover, they have good amounts of memory to use as read ahead or writeback cache, which do speed up I/O instead of sharing memory with the OS.
About the speed of the controller's processor as compared to the main processor, just remember that, in today's standards, one SCSI channel could only work at 160MB/s, and, even if we needed one processor cycle for each byte to be read/written (we don't), we would only need a 160MHz processor to do the job.
Well, come think about it, processors embedded in today's modern RAID controllers usually have a 64-bit data bus. This means that any transaction is 8 bytes long. Being the worst case in performance a RAID-5 write (which involves 4 I/O operations) we still get an average of 2 bytes per processor cycle.
That's why RAID controllers don't come with fantastic processors -- there's simply no need to.
We could also think of availability, but that would be another long issue, and hardware RAID wins almost in all cases (except for controller multiplexing), but the best reason you would have to think about software raid would be the cost.
I could be wrong, though
Damn... imagine a Metropolitan Beowulf Cluster with those...
Just FYI, what comes after tera is petabyte (PB), or 10^15 bytes.
I just can't wait until the googlebyte HD comes out!