"With current consumer/semi-pro level audio equipment already being able to handle higher sample rates (96Khz, 192Khz etc) and higher dynamic ranges with 32bit recording, the storage capacities of these devices in the future will have to be larger anyway, so uncompressed 44.1/16bit will be absolutely no problem, even for flash drive type storage, IMHO."
It takes approximately 4 doublings to compensate for the lack of compression, or about 6+ years. An iPod 6 years from now, that would otherwise be able to hold my entire collection (since it'll still be mostly MP3s from the 90s and 00s), would be constrained to a shuffle-like level of functionality. Just because it would be able to hobble along with a level of functionality that I consider tolerable today doesn't mean it's something I want to commit myself to.
Buying CDs and ripping them gives me a) better quality, b) universal OS compatibility right now, and c) universal player compatibility right now.
Besides, I've been using Linux on the desktop since late 2003. If I had accepted your argument back when iTMS launched (and it was made back then), I would have already encountered problems as a result. AAC would not have been a problem on my Windows machine or my iBook, but my insistence on sticking with MP3 has already paid off.
"I have no problem whatsoever with the DRM on iTunes. I think it's perfectly reasonable and fair."
I want to be able to get a player other than an iPod in the future. I want to be able to use a platform other than MacOS/Windows in the future.
I realize Apple can't do anything about the conditions imposed on them by the labels, but those conditions make the entire thing untenable for me. It's not Apple's fault, but it's not my fault either. As you say, you can bypass the DRM, but only by going to a prohibitively large format. My hard drives can take it, but a flash MP3 player can't.
I can generally write a regex to do what I want, and at one point I wrote a library to merge regexen into a single pattern in order to deal with Python's large function call overhead (this was easier than getting everyone to maintain a shared regex), but I consider myself relatively weak at other stuff like performance optimization of the patterns themselves.
If you added up the mass of Pluto and all the other similar objects that cross closer to the Sun than Neptune, you only get a tiny fraction of Neptune's mass. Neptune completely dominates the mass at that distance from the Sun.
"ZFS consumes the block driver, the volume manager, and the RAID layer into one giant entity."
It does all three better than what Apple currently has. I agree about the complexity, but coming up with a good filesystem isn't as easy as it used to be.
I like my definition better. It covers all the old planets except Pluto, and actually gives planets the special status that IMO they deserve.
My definition: a planet is a body orbitting a star that contains a majority of the mass at that distance from the star. More precisely, the sum of the mass of the objects with orbits that take them closer to the star than the planet at its farthest or farther from the star than the planet at its closest must be less than the planet.
That rules out KBOs, Ceres, and Pluto. It's simple and consistent and easy to apply to other solar systems. If we found a solar system with comparably sized bodies with orbits that cross, we can give them another classification like "proto-planet" or "asteroid" or whatever.
For the better part of a century, radioactive decay is what scientists always use when they want to invoke a natural process that is "random." But is radioactive decay really random... that is, are there, say, well-established quantum-mechanical equations that predict this?
The decay of an atom is a fundementally probability-driven process. You can predict the half-life of a material on a large scale, but it is impossible to predict the decay of an individual atom. And, every signal received by your detector comes from an individual atom decaying, so it's impossible for someone to predict or duplicate.
A chaotic system would be something where the difficulty in predicting it comes from the complexity of the system, and the ability of small changes to significantly influence the outcome. Radioactive decay doesn't work like that. There's simply a particular event that either happens or doesn't.
VMWare's style of virtualization, whether it works with hardware support or not, involves trapping privileged operations performed by the guest OS. Xen's style of virtualization tweaks the guest OS to pass on requests for privileged operations by more conventional means, and that is significantly faster.
I dunno -- after the constant logic board problems with my iBook I got a Dell. I expect exactly the same amount (small downtime), but I've been much happier with the Dell.
correct me is I'm wrong...but doesn't conroe support EMT64T?... and can't it run 32bit and 64bit applications at the same time... And of course...as an AMD fan I know athlon 64s support running 32 bit and 64bit at the same time
Re-read what I said please.
-Yes, Conroe does support x86-64. -Yes, x86-64 can run 32-bit and 64-bit applications concurrently. -However, x86-64 requires that the kernel be 64-bit for 64-bit applications to run. -But, PowerPC does not. The MacOS X kernel for G5s is still 32-bit, even though they can run 64-bit applications. This allows drivers and so forth to continue working. The move to x86-64 will require a port of the kernel to 64-bit, so it will break drivers.
Darn right - Apple would never announce a major architecture change at WWDC, have beta code with developers a few weeks later and product in the shops the following year. Oh, wait...
Like I said, they might have a beta, but they won't be production ready. If they announce a beta now, that doesn't contradict my theory on the subject.
Conroe will be featured in the iMac and the new PowerMac; Quad capability may or may not be present...
I don't think it's safe to assume Conroe in PowerMacs/Mac Pros. I think it's much more likely they will use an all-Xeon lineup, using Woodcrest (the Xeon version of Core 2). I think this because I don't think they have any interest in inexpensive towers, and using Xeon chips is one of the things they'll have to do to justify towers starting at $2000.
Conroe, Merom, and Woodcrest bring x86_64 (EM64T) support, 10.5 should take advantage of it fully.
64-bit support on x86 is a lot harder than on PowerPC. PowerPC allows the kernel to remain 32-bit even with 64-bit applications, while x86 does not. They'll essentially be porting the kernel to another architechture, and as a result drivers will be broken etc. Also, they'll have to provide a translation layer for the kernel to continue to run 32-bit applications, which isn't trivial either. They have also yet to provide support for 64-bit GUI applications, which is necessary for things like Photoshop to get useful 64-bit support (a 64-bit worker process doesn't cut it for things like Photoshop, they stuff to run in the same address space).
Basically, it isn't possible for them to have a production-ready x86-64 OS without a significant period spent in beta to debug the new kernel and application support, and to allow hardware vendors to update their drivers. This would, by necessity, be too large to keep secret.
It is entirely possible that they will announce 64-bit support, and they might even pretend it's production ready, but there is very little chance of this being true. My guess is a 64-bit interim release some time after 10.5 has been released, like they did with 10.2 when G5s were released.
Now, in the many years of running desktop systems and being anal retentively monitoring them, I've noticed that CPU utilization is very often bursty. Meaning that its common for the CPU to hover around zero, and spike up with doing something like rendering a webpage, printing, compiling code, etc, etc. But most of the time (> 90% or well more if including when I sleep and stuff), the CPU is doing nothing.
So, what is my point? Give me cores out the wazoo, and let them completely power down when not needed and crank up to all 8 or more when needed.
I agree for the most part, but is it really that common for dozens of threads to become CPU-bound simultaneously? You'll only notice a problem if multiple threads want CPU time at once, and I suspect the probability of running out of cores drops off quite quickly as the number of cores increase with today's desktop applications.
One thing I've noticed is that if I'm doing something time sensitive (like watching a movie, where it's essential for the codec to get CPU time when it needs it), introducing a CPU-bound thread (like loading a web page with fancy javascript) can cause the movie to skip. Two cores would resolve this, and four wouldn't help much at all because all the non-CPU-bound stuff can generally share a single core amicably.
So, the question is, how many CPU-bound threads do you expect your system to encounter simultaneously? For most people, the answer would be 1, so 2 cores is enough. 4 might help a little, and 8 probably wouldn't help most users measurably. Someone always mentions photoshop or video production or similar when I bring this up, and yes these would benefit, but I'm addressing average desktop users.
In time, the availability of inexpensive multi-core chips will increase the average number of CPU-bound threads on average desktop systems as the software starts to take advantage, and at that time there will be a benfit to the greater number of cores, but for now I agree with Intel.
The fact that Core 2 increases the performance possible from a single thread running on a single core is much more helpful than additional cores would be, since existing applications get the automatic speed boost that we've been missing for the last few years with stagnant clock speeds.
I frequently run as many as 8 programs at a time, sometimes more, but I seriously doubt each program would know what to do with its own core.
Indeed. Even with multiple applications, there is rarely more than 1 CPU-bound thread on a desktop system.
Not that I doubt the ability of the industry to produce applications that warrant increased numbers of cores, but this will take time and in the current landscape anything more than 2 goes to waste for most people. There are some applications that need it already, and those people will no doubt be happy about increasing the core count, but I think this is going to be one of those "build it and they will come" things for the most part.
Intel has deffinitely given us better performance per core with Core 2. There probably isn't that much room left for per-core improvements, but there's deffinitely some.
Slashdot Mirror
"With current consumer/semi-pro level audio equipment already being able to handle higher sample rates (96Khz, 192Khz etc) and higher dynamic ranges with 32bit recording, the storage capacities of these devices in the future will have to be larger anyway, so uncompressed 44.1/16bit will be absolutely no problem, even for flash drive type storage, IMHO."
It takes approximately 4 doublings to compensate for the lack of compression, or about 6+ years. An iPod 6 years from now, that would otherwise be able to hold my entire collection (since it'll still be mostly MP3s from the 90s and 00s), would be constrained to a shuffle-like level of functionality. Just because it would be able to hobble along with a level of functionality that I consider tolerable today doesn't mean it's something I want to commit myself to.
Buying CDs and ripping them gives me a) better quality, b) universal OS compatibility right now, and c) universal player compatibility right now.
Besides, I've been using Linux on the desktop since late 2003. If I had accepted your argument back when iTMS launched (and it was made back then), I would have already encountered problems as a result. AAC would not have been a problem on my Windows machine or my iBook, but my insistence on sticking with MP3 has already paid off.
"I have no problem whatsoever with the DRM on iTunes. I think it's perfectly reasonable and fair."
I want to be able to get a player other than an iPod in the future. I want to be able to use a platform other than MacOS/Windows in the future.
I realize Apple can't do anything about the conditions imposed on them by the labels, but those conditions make the entire thing untenable for me. It's not Apple's fault, but it's not my fault either. As you say, you can bypass the DRM, but only by going to a prohibitively large format. My hard drives can take it, but a flash MP3 player can't.
"The average joe neither has heard of DRM (let alone knows what it is) nor gives a shit about lossless or even higher bitrate audio."
These statistics demonstrate that they do in fact care about some combination of those factors, and avoid online music purchases as a result.
I can generally write a regex to do what I want, and at one point I wrote a library to merge regexen into a single pattern in order to deal with Python's large function call overhead (this was easier than getting everyone to maintain a shared regex), but I consider myself relatively weak at other stuff like performance optimization of the patterns themselves.
I'm already quite proficient at regexen (people at work come to me for help etc). How much do I stand to gain from this book?
If you added up the mass of Pluto and all the other similar objects that cross closer to the Sun than Neptune, you only get a tiny fraction of Neptune's mass. Neptune completely dominates the mass at that distance from the Sun.
"ZFS consumes the block driver, the volume manager, and the RAID layer into one giant entity."
It does all three better than what Apple currently has. I agree about the complexity, but coming up with a good filesystem isn't as easy as it used to be.
I like my definition better. It covers all the old planets except Pluto, and actually gives planets the special status that IMO they deserve.
My definition: a planet is a body orbitting a star that contains a majority of the mass at that distance from the star. More precisely, the sum of the mass of the objects with orbits that take them closer to the star than the planet at its farthest or farther from the star than the planet at its closest must be less than the planet.
That rules out KBOs, Ceres, and Pluto. It's simple and consistent and easy to apply to other solar systems. If we found a solar system with comparably sized bodies with orbits that cross, we can give them another classification like "proto-planet" or "asteroid" or whatever.
"Let's not shoot ourself in the foot now. There are perfectly legitimate uses for torrents. Like downloading your favorite Linux distro"
Yes... the mirrors are frequently overloaded after a major release. Torrents are often the only way to get your favorite distro in a timely fashion.
Or, you know, download Firefox...
Yeah, but Voyager managed to do it without going in circles.
A chaotic system would be something where the difficulty in predicting it comes from the complexity of the system, and the ability of small changes to significantly influence the outcome. Radioactive decay doesn't work like that. There's simply a particular event that either happens or doesn't.
VMWare's style of virtualization, whether it works with hardware support or not, involves trapping privileged operations performed by the guest OS. Xen's style of virtualization tweaks the guest OS to pass on requests for privileged operations by more conventional means, and that is significantly faster.
You can get more thanm 4 gb of memory with PAE now. The advantage is that it allows you to do that in one process's address space.
You don't disagree with me, you just had better luck with your machine than me.
I dunno -- after the constant logic board problems with my iBook I got a Dell. I expect exactly the same amount (small downtime), but I've been much happier with the Dell.
Re-read what I said please.
-Yes, Conroe does support x86-64.
-Yes, x86-64 can run 32-bit and 64-bit applications concurrently.
-However, x86-64 requires that the kernel be 64-bit for 64-bit applications to run.
-But, PowerPC does not. The MacOS X kernel for G5s is still 32-bit, even though they can run 64-bit applications. This allows drivers and so forth to continue working. The move to x86-64 will require a port of the kernel to 64-bit, so it will break drivers.
Like I said, they might have a beta, but they won't be production ready. If they announce a beta now, that doesn't contradict my theory on the subject.
My theory does not preclude a 64-bit beta or something that is otherwise not production ready.
I don't think it's safe to assume Conroe in PowerMacs/Mac Pros. I think it's much more likely they will use an all-Xeon lineup, using Woodcrest (the Xeon version of Core 2). I think this because I don't think they have any interest in inexpensive towers, and using Xeon chips is one of the things they'll have to do to justify towers starting at $2000.
64-bit support on x86 is a lot harder than on PowerPC. PowerPC allows the kernel to remain 32-bit even with 64-bit applications, while x86 does not. They'll essentially be porting the kernel to another architechture, and as a result drivers will be broken etc. Also, they'll have to provide a translation layer for the kernel to continue to run 32-bit applications, which isn't trivial either. They have also yet to provide support for 64-bit GUI applications, which is necessary for things like Photoshop to get useful 64-bit support (a 64-bit worker process doesn't cut it for things like Photoshop, they stuff to run in the same address space).
Basically, it isn't possible for them to have a production-ready x86-64 OS without a significant period spent in beta to debug the new kernel and application support, and to allow hardware vendors to update their drivers. This would, by necessity, be too large to keep secret.
It is entirely possible that they will announce 64-bit support, and they might even pretend it's production ready, but there is very little chance of this being true. My guess is a 64-bit interim release some time after 10.5 has been released, like they did with 10.2 when G5s were released.
Why can't it be a magnetic field generated by the superheated matter in the process of falling in?
Oh, a generic jab at Microsoft. Bravo.
I MacOS X on a daily basis, and I use Linux with KDE at home. Neither is substantially less resource intensive than XP in my experience.
I agree for the most part, but is it really that common for dozens of threads to become CPU-bound simultaneously? You'll only notice a problem if multiple threads want CPU time at once, and I suspect the probability of running out of cores drops off quite quickly as the number of cores increase with today's desktop applications.
One thing I've noticed is that if I'm doing something time sensitive (like watching a movie, where it's essential for the codec to get CPU time when it needs it), introducing a CPU-bound thread (like loading a web page with fancy javascript) can cause the movie to skip. Two cores would resolve this, and four wouldn't help much at all because all the non-CPU-bound stuff can generally share a single core amicably.
So, the question is, how many CPU-bound threads do you expect your system to encounter simultaneously? For most people, the answer would be 1, so 2 cores is enough. 4 might help a little, and 8 probably wouldn't help most users measurably. Someone always mentions photoshop or video production or similar when I bring this up, and yes these would benefit, but I'm addressing average desktop users.
In time, the availability of inexpensive multi-core chips will increase the average number of CPU-bound threads on average desktop systems as the software starts to take advantage, and at that time there will be a benfit to the greater number of cores, but for now I agree with Intel.
The fact that Core 2 increases the performance possible from a single thread running on a single core is much more helpful than additional cores would be, since existing applications get the automatic speed boost that we've been missing for the last few years with stagnant clock speeds.
Indeed. Even with multiple applications, there is rarely more than 1 CPU-bound thread on a desktop system.
Not that I doubt the ability of the industry to produce applications that warrant increased numbers of cores, but this will take time and in the current landscape anything more than 2 goes to waste for most people. There are some applications that need it already, and those people will no doubt be happy about increasing the core count, but I think this is going to be one of those "build it and they will come" things for the most part.
Intel has deffinitely given us better performance per core with Core 2. There probably isn't that much room left for per-core improvements, but there's deffinitely some.