Are you overlooking the fact that you'd be converting from one lossy format to another lossy format? Both use different algorithms for determining what's discardable, and you're likely going to end up with a file the sounds pretty bad in the end.
What you're suggesting, however, wouldn't be too hard if your player supported Vorbis. It's my understanding that Vorbis is designed in a manner where you can 'strip' it down to a lower bitrate without totally reencoding - I may have misunderstood, however. Anyone know for sure?
This is true, but I think that Blizzard is viewing this as a way to both reduce their bandwidth costs some and to limit the amount of bottlenecking at the single server that's common in the traditional high-demand distribution scenario.
You can still use your file server with as large a pipe as you want as an initial seed, allowing it to dole out the file as needed to clients on the network. The key here is that since all the clients on the network can hit each other for chunks of the file, you reduce the amount of saturation on the primary pipe, with clients pulling from each other rather than exclusively from the server.
The thing to keep in mind is that although the file may be distributed primarily by slower pipes, the protocol's designed in a manner where you eliminate the old problem of totally saturating the bandwidth and connections of a *single* server - after all, it doesn't matter how fast of a pipe is there if it's split so many ways that you can't even connect.
Basically, this is a long way of saying that under light load, users won't really know the difference and they'll pull from Blizzard's server just like they would have under a more traditional system. But where this system really spreads its wings is that by allwowing the clients to distribute as well, a user should always be able to get a fairly respectable transfer rate going, instead of simply having to wait a few days or find another (likely overloaded) mirror. Sorry if I was a bit wordy with that, but I was just trying to be as clear as possible. BitTorrent isn't a magic silver bullet solution for all our problems, but it does what it does extremely well, and this happens to be a scenario tailor-fit for its use.
Except that John Stossel has decided that consumer advocacy is old hat, and that his new calling is exposing the great big evil, liberal media. Kind of sad, really. I respected his consumer work, but the notion that the media really sways in any direction other than that of the all-mighty dollar is a bit much for me.
I don't really see that being the case. BT is a swarm based protocol - the more people that are grabbing a file, the faster the possible transfer rate will be because the clients aren't pulling from a single source like they would in a traditional file transfer scenario.
For applications like Blizzard's using it for, I can't think of a better distribution method than BT - it'll reduce the load on their servers, allow people to begin downloading much sooner than would have been possible in the traditional manner (think severely overloaded servers), and as a result, people may very well see higher download rates than they would from a single source because they're pulling from *many* sources at once, even if the individual sources are slower. I'm not sure you're looking at the protocol in the right light.
For what it's worth, Slackware 9.1 upgrades to 2.6 flawlessly. Untar the source, change the linux symbolic link in/usr/src to point to the new kernel source, config, compile, copy to/boot and set up your bootloader and go. I've done this on 4 different machines and have yet to hit a problem outside of forgetting to compile driver that I needed in.
Apple hardware is tied to the OS when you buy it. It's the same reason why Apple will never port OS X to x86 - Apple's a hardware company first, using the software to help sell the hardware. Either way, I'm sure Apple's selling the systems to Pixar at-cost anyway, so it's not like it's going to add to the cost, and OS X is a worthy Unix system that happens to have a rather pretty interface on top. So the question is more why wouldn't they go with OS X?
Except we're talking about a prerelease piece of software that's going to have been built with full debug hooks, which add significantly to the memory footprint of an application. For simple "Hello World" programs, debug hooks can be the difference between a 50k binary and a 150k binary. Now expand that out to a full operating system.
I'm not saying I don't expect Longhorn to have a larger footprint than XP, I just think it's kind of ridiculous to complain about the memory footprint of an alpha build that's likely been compiled with debugging rather than efficiency in mind.
Not sure how relevent this is, but Gamestop is actually owned by Barnes and Noble. I only know this because a friend of mine is a Gamestop employee and gets employee discounts at the Barnes and Noble a few stores down.
Actually, I look at it more from the perspective of comparing to the way NVidia distributes its drivers. I just installed nVidia drivers by hand for the first time in a couple of years yesterday, and I had set aside a couple of hours expecting problems, remembering the trouble I'd had with their RPM based drivers (admittedly as one fairly new to Linux at the time).
Instead, I ran a shell script, which brought up a nice menu based installer, it checks for a precompiled version of the driver, if there's not one available, it fetches what it needs, builds it, and installs it. From there I had to chenge 2 lines in my XFree86Config file (one of being uncommenting a line) and I was done. This isn't perfect, but it's by far the most user friendly way of doing a driver install under Linux that I've seen. Most importantly, it's entirely distribution agnostic.
Honestly, the open/closed source driver thing isn't something that I really care about - whether the drivers work or not and how easy it is to install them is what's critical. This is how your average user views it, and this is what's critical to adoption by the masses.
Look at what you just wrote. Service packs fix the operating system. What I see this as meaning is it will break applications that were written in an insecure manner, most likely using undocumented APIs.
In the past, when MS has updated the OS, they've often worked kludges in to make sure they don't break applications that were doing things that they weren't supposed to be doing. With the new focus on security, Microsoft has likely put an end to such kludges and things are going to break. I'm not surprised, and it doesn't really bother me.
Really, most of the posts I'm seeing are giving Microsoft a hard time about this, but how is it any different from the kernel developers refusing to freeze a driver API, which in turn occassionally causes drivers for some hardware to break? It happens, and it's really out of Microsoft's hands if they're focused on building a more secure OS than what they have now. I'm sure Microsoft's own products will be patched at the same time SP2 is released, and so long as they provide a changelist which would allow developers to fix apps that might break, what's the problem?
Is it just me, or is there a slight irony in the fact that they not only run *nix, but choose Debian, which touts itself as being one of the 'Freest' of distributions?
Well, in the Toshiba line, I was thinking more of the Portege then the Tecra. The Portege is Toshiba's "compact" line and every one I've seen has been of fairly high build quality.
Compaqs of yore weren't bad machines, but they're been junky for several years now - they have problems with the power connecter breaking in particular.
My personal take is that the best approach to this would be to use 3D rendering, but style the engine like the 2D adventure games. The reason for this is it would hugely cut down the amount of effort that'd be needed to go into much of the art.
Think of South Park - the show started life as being literal construction paper cutouts, but these days is made using Maya. It still looks the same, but the amount of time and effort needed to produce an episode has been cut tremendously. Combine this with a common engine like SCUMM from the days of old, and it opens the possibility of a new golden age of adventure gaming. Whether this will actually happen comes down to the suits, however. And the chances of them having that kind of foresight in today's bottom-line centric environment is sadly limited.
I understand what you're saying, but the part I don't understand is that Sam n'Max was VERY deep into development - it's been scheduled for a "Spring 2004" release, with most talk centering around April. All I can figure is it must have had serious problems and been clear that the game wasn't going to be ready, and extending development would have driven the cost up to unacceptable levels. It still sucks either way.
Toshiba builds some pretty nice, durable units. My understanding is that IBMs are great machines as well, but I haven't seen many as they're pretty pricey. I'd stay away from HP/Compaq, but I don't think they build anything like what you want anway.
I really wish I knew what causes the screen problems with the Vaios, because they're awesome machines otherwise.
If this is the only thing you were planning on carrying, it might be acceptable. Speaking for myself, my Inspiron 2500 weighs around 8 pounds, and adds considerably to the heft of my backpack with a couple of college text books thrown in there - to the extent that I leave books in the car half the time because carrying it all around is such a pain.
My laptop would be a compromise, this Acer weighs twice what mine does so it's nowhere near a middle ground. This is good for people who don't need to move the system around much and keep most of the power of a desktop, but for people that actually want to carry the computer with them, it's off.
I just hope you're ready for the screen problems nearly every Vaio I've seen eventually develops. After a couple of years, the bottom half of the screen tends to go dark while the top half remains as it was. I've seen this across many models and generations of Sony laptops and I've heard other techs that have noticed the same thing. Don't know what it is, but it seems to be a common thing with the Vaios.
Same thing here, but there's a reason for it - remember the big fuss over Hynix receiving MASSIVE subsidies from the South Korean Government? Somewhere around last July-August, the US and EU both slapped fairly heavy tarriffs on Hynix chips because of this, and RAM prices went up almost exactly as much as the tarriff amount (I think it was around 30%). Prices are only just now starting to get close to where they were again.
My experience has been that a C-Stick remains imprecise though, as I noted before, increasing senstivity does help the 'slowness' of the stick a good deal. This isn't a matter of trying it once and giving up - this is over a period of months playing Halo and other console shooters with friends who are console fans. I got better with it, but a mouse is still the way to go for me.
There are some things that just work better with controllers (ie: I'm an absolute circle strafing whore with the ghost in Halo, which is easy with the C-sticks, but difficult to duplicate with a mouse), it's just that I've found that the C-stick doesn't allow for the type precision I can attain with a mouse. I don't feel it's a matter of getting used to it so much as each controller has it's advantages - else, why wouldn't we be using joysticks to control our desktop environments?
It's slow and imprecise. Granted, when I play Halo with some of my friends, I've got my profile set with the sick sensitivity jacked to 10, so it's quite as bad. But even then, the problem is the fact that juggling a stick about provides nowhere near the same level of direct, hand-eye oriented feedback a mouse does. I can move my mouse and know how much it directly coresponds to movement of the reticle on screen. You can't do that with a C-Stick, simply because of the nature of the controller.
This late in development, it's unlikely the engine's going to see much improvement in performance or that any poor design choices can be reversed. DX2 has received 2 patches aimed towards improving performance, and framerate is still unacceptable low on most systems.
It may have been improved, but even the 20% improvements some people have seen with the patches don't mean much when they were only struggling to get 18fps in the first place.
It's possible that Ion Storm may redeem themselves with Thief 3, but there's no way I'm buying it until after it's been out long enough to gauge the actual fan reaction to it.
Slashdot Mirror
Are you overlooking the fact that you'd be converting from one lossy format to another lossy format? Both use different algorithms for determining what's discardable, and you're likely going to end up with a file the sounds pretty bad in the end.
What you're suggesting, however, wouldn't be too hard if your player supported Vorbis. It's my understanding that Vorbis is designed in a manner where you can 'strip' it down to a lower bitrate without totally reencoding - I may have misunderstood, however. Anyone know for sure?
This is true, but I think that Blizzard is viewing this as a way to both reduce their bandwidth costs some and to limit the amount of bottlenecking at the single server that's common in the traditional high-demand distribution scenario.
You can still use your file server with as large a pipe as you want as an initial seed, allowing it to dole out the file as needed to clients on the network. The key here is that since all the clients on the network can hit each other for chunks of the file, you reduce the amount of saturation on the primary pipe, with clients pulling from each other rather than exclusively from the server.
The thing to keep in mind is that although the file may be distributed primarily by slower pipes, the protocol's designed in a manner where you eliminate the old problem of totally saturating the bandwidth and connections of a *single* server - after all, it doesn't matter how fast of a pipe is there if it's split so many ways that you can't even connect.
Basically, this is a long way of saying that under light load, users won't really know the difference and they'll pull from Blizzard's server just like they would have under a more traditional system. But where this system really spreads its wings is that by allwowing the clients to distribute as well, a user should always be able to get a fairly respectable transfer rate going, instead of simply having to wait a few days or find another (likely overloaded) mirror. Sorry if I was a bit wordy with that, but I was just trying to be as clear as possible. BitTorrent isn't a magic silver bullet solution for all our problems, but it does what it does extremely well, and this happens to be a scenario tailor-fit for its use.
Except that John Stossel has decided that consumer advocacy is old hat, and that his new calling is exposing the great big evil, liberal media. Kind of sad, really. I respected his consumer work, but the notion that the media really sways in any direction other than that of the all-mighty dollar is a bit much for me.
I don't really see that being the case. BT is a swarm based protocol - the more people that are grabbing a file, the faster the possible transfer rate will be because the clients aren't pulling from a single source like they would in a traditional file transfer scenario.
For applications like Blizzard's using it for, I can't think of a better distribution method than BT - it'll reduce the load on their servers, allow people to begin downloading much sooner than would have been possible in the traditional manner (think severely overloaded servers), and as a result, people may very well see higher download rates than they would from a single source because they're pulling from *many* sources at once, even if the individual sources are slower. I'm not sure you're looking at the protocol in the right light.
Because the baseline isn't an Intel chip? The baseline for AMD's pro-rating scale is a 1GHz Duron. IE: A 3200+ is 3.2 times faster than a 1GHz Duron.
For what it's worth, Slackware 9.1 upgrades to 2.6 flawlessly. Untar the source, change the linux symbolic link in /usr/src to point to the new kernel source, config, compile, copy to /boot and set up your bootloader and go. I've done this on 4 different machines and have yet to hit a problem outside of forgetting to compile driver that I needed in.
Apple hardware is tied to the OS when you buy it. It's the same reason why Apple will never port OS X to x86 - Apple's a hardware company first, using the software to help sell the hardware. Either way, I'm sure Apple's selling the systems to Pixar at-cost anyway, so it's not like it's going to add to the cost, and OS X is a worthy Unix system that happens to have a rather pretty interface on top. So the question is more why wouldn't they go with OS X?
Except we're talking about a prerelease piece of software that's going to have been built with full debug hooks, which add significantly to the memory footprint of an application. For simple "Hello World" programs, debug hooks can be the difference between a 50k binary and a 150k binary. Now expand that out to a full operating system.
I'm not saying I don't expect Longhorn to have a larger footprint than XP, I just think it's kind of ridiculous to complain about the memory footprint of an alpha build that's likely been compiled with debugging rather than efficiency in mind.
Not sure how relevent this is, but Gamestop is actually owned by Barnes and Noble. I only know this because a friend of mine is a Gamestop employee and gets employee discounts at the Barnes and Noble a few stores down.
Actually, I look at it more from the perspective of comparing to the way NVidia distributes its drivers. I just installed nVidia drivers by hand for the first time in a couple of years yesterday, and I had set aside a couple of hours expecting problems, remembering the trouble I'd had with their RPM based drivers (admittedly as one fairly new to Linux at the time).
Instead, I ran a shell script, which brought up a nice menu based installer, it checks for a precompiled version of the driver, if there's not one available, it fetches what it needs, builds it, and installs it. From there I had to chenge 2 lines in my XFree86Config file (one of being uncommenting a line) and I was done. This isn't perfect, but it's by far the most user friendly way of doing a driver install under Linux that I've seen. Most importantly, it's entirely distribution agnostic.
Honestly, the open/closed source driver thing isn't something that I really care about - whether the drivers work or not and how easy it is to install them is what's critical. This is how your average user views it, and this is what's critical to adoption by the masses.
Look at what you just wrote. Service packs fix the operating system. What I see this as meaning is it will break applications that were written in an insecure manner, most likely using undocumented APIs.
In the past, when MS has updated the OS, they've often worked kludges in to make sure they don't break applications that were doing things that they weren't supposed to be doing. With the new focus on security, Microsoft has likely put an end to such kludges and things are going to break. I'm not surprised, and it doesn't really bother me.
Really, most of the posts I'm seeing are giving Microsoft a hard time about this, but how is it any different from the kernel developers refusing to freeze a driver API, which in turn occassionally causes drivers for some hardware to break? It happens, and it's really out of Microsoft's hands if they're focused on building a more secure OS than what they have now. I'm sure Microsoft's own products will be patched at the same time SP2 is released, and so long as they provide a changelist which would allow developers to fix apps that might break, what's the problem?
How is this all that different from having to install, say, DirectX to play a game?
In all honesty, the dropping of Premiere support had more to do with Final Cut Pro being a far superior product than it did Windows reliance.
Is it just me, or is there a slight irony in the fact that they not only run *nix, but choose Debian, which touts itself as being one of the 'Freest' of distributions?
Well, in the Toshiba line, I was thinking more of the Portege then the Tecra. The Portege is Toshiba's "compact" line and every one I've seen has been of fairly high build quality.
Compaqs of yore weren't bad machines, but they're been junky for several years now - they have problems with the power connecter breaking in particular.
My personal take is that the best approach to this would be to use 3D rendering, but style the engine like the 2D adventure games. The reason for this is it would hugely cut down the amount of effort that'd be needed to go into much of the art. Think of South Park - the show started life as being literal construction paper cutouts, but these days is made using Maya. It still looks the same, but the amount of time and effort needed to produce an episode has been cut tremendously. Combine this with a common engine like SCUMM from the days of old, and it opens the possibility of a new golden age of adventure gaming. Whether this will actually happen comes down to the suits, however. And the chances of them having that kind of foresight in today's bottom-line centric environment is sadly limited.
I understand what you're saying, but the part I don't understand is that Sam n'Max was VERY deep into development - it's been scheduled for a "Spring 2004" release, with most talk centering around April. All I can figure is it must have had serious problems and been clear that the game wasn't going to be ready, and extending development would have driven the cost up to unacceptable levels. It still sucks either way.
Toshiba builds some pretty nice, durable units. My understanding is that IBMs are great machines as well, but I haven't seen many as they're pretty pricey. I'd stay away from HP/Compaq, but I don't think they build anything like what you want anway.
I really wish I knew what causes the screen problems with the Vaios, because they're awesome machines otherwise.
If this is the only thing you were planning on carrying, it might be acceptable. Speaking for myself, my Inspiron 2500 weighs around 8 pounds, and adds considerably to the heft of my backpack with a couple of college text books thrown in there - to the extent that I leave books in the car half the time because carrying it all around is such a pain.
My laptop would be a compromise, this Acer weighs twice what mine does so it's nowhere near a middle ground. This is good for people who don't need to move the system around much and keep most of the power of a desktop, but for people that actually want to carry the computer with them, it's off.
I just hope you're ready for the screen problems nearly every Vaio I've seen eventually develops. After a couple of years, the bottom half of the screen tends to go dark while the top half remains as it was. I've seen this across many models and generations of Sony laptops and I've heard other techs that have noticed the same thing. Don't know what it is, but it seems to be a common thing with the Vaios.
Same thing here, but there's a reason for it - remember the big fuss over Hynix receiving MASSIVE subsidies from the South Korean Government? Somewhere around last July-August, the US and EU both slapped fairly heavy tarriffs on Hynix chips because of this, and RAM prices went up almost exactly as much as the tarriff amount (I think it was around 30%). Prices are only just now starting to get close to where they were again.
My experience has been that a C-Stick remains imprecise though, as I noted before, increasing senstivity does help the 'slowness' of the stick a good deal. This isn't a matter of trying it once and giving up - this is over a period of months playing Halo and other console shooters with friends who are console fans. I got better with it, but a mouse is still the way to go for me.
There are some things that just work better with controllers (ie: I'm an absolute circle strafing whore with the ghost in Halo, which is easy with the C-sticks, but difficult to duplicate with a mouse), it's just that I've found that the C-stick doesn't allow for the type precision I can attain with a mouse. I don't feel it's a matter of getting used to it so much as each controller has it's advantages - else, why wouldn't we be using joysticks to control our desktop environments?
It's slow and imprecise. Granted, when I play Halo with some of my friends, I've got my profile set with the sick sensitivity jacked to 10, so it's quite as bad. But even then, the problem is the fact that juggling a stick about provides nowhere near the same level of direct, hand-eye oriented feedback a mouse does. I can move my mouse and know how much it directly coresponds to movement of the reticle on screen. You can't do that with a C-Stick, simply because of the nature of the controller.
This late in development, it's unlikely the engine's going to see much improvement in performance or that any poor design choices can be reversed. DX2 has received 2 patches aimed towards improving performance, and framerate is still unacceptable low on most systems.
It may have been improved, but even the 20% improvements some people have seen with the patches don't mean much when they were only struggling to get 18fps in the first place.
It's possible that Ion Storm may redeem themselves with Thief 3, but there's no way I'm buying it until after it's been out long enough to gauge the actual fan reaction to it.
No, he probably meant X Server - ie: Keith Packard's implementation over at FreeDesktop.org.