I feel as if this works in the other direction as well. I unplugged my television three-and-a-half years ago and now ANYTHING on a TV is evtertainment. I stayed in a hotel last week and killed some time using the TV, it was AMAZING, even late at night when the programming was craptastic. Also, I can honestly say now after doing this that I like the commercials more than the programming itself.
It would be faster to 'tar' directly to the target machine. Tar will stream the output and is probably much more efficient than Windows Explorer.
Also, booting the machine from a Linux boot CD and mounting the drive read-only and using tar to move the files is probably the fastest method. I do this all the time to recover/backup machines at work.
boot gentoo install cd... mount network share/external drive mount local drive '-o ro' cd/path/to/local/drive tar -vcf./*/path/to/remote/drive/backup.tar
I'm a conspiracy-nut, but the two richest men in the world just decided to get out of the game at the same time. I'm betting that something like a big war, pandemic, or something that history is going to want to pin on someone is going to happen. I'd hate to be one of the people 'at the wheel' when the ship hit the iceberg. These people know what's coming before most of us do, I'd keep a close eye on international affairs with China over the next two years.
Microsoft wants a safety switch in case this tool starts causing PCs around the world to explode. Thus the program checks with Microsoft once a day to see if it should shut itself off.
Good, I've been building our 2006-07 academic year image on XP and this tool has twice kicked-in and called my legit-via-volume-key XP image a fraud. I eventually figured out that I had to be less millitant about deleting miscellaneous files before syspreping the beast, but I can certainly see some malware out there deliberately hooking into this tool to exploit people.
I'm not sure how the state of video drivers affects VMWare sessions. 3D graphics under VM sessions are all software-rendered anyway, so 3D should be very close on either platform, and the 2D graphics drivers for all but the VERY latest cards are nice and accelerated under X.
I use a RADEON 9200 here at home because I use 3D in Linux and I don't want to use the binary-only driver, but at work I have an X600, which has perfectly good 2D, but only software 3D. I don't know about you, but I have no business doing anything 3D at work, so it's of no consequence that I don't have DRI there.
I'll repeat this: If you don't do 3D -outside- your VMWare sessions, you need not worry about 3D driver support. The 2D part of the driver still works swimmingly using the generic driver from xorg. If you're doing 3D -inside- VMWare sessions, you're being foolish because it's going to be rendered in software no matter what kind of video card you have.
Also, just to finish my technical pissing contest:
Video RAM has nothing to do with moving video on your PC. Having more or less VRAM will not affect how movies play. If I hear one more AV person say how they need a computer with 'lots of video memory' so they can play movies smoothly, I'll strangle them. Any card made since 1999 has PLENTY of VRAM for anything 2D, including motion video. Video RAM will not speed up Photoshop; it will not speed up Final Cut or Premiere; all of that stuff takes place on a frame buffer that fits quite nicely into even the most conservative VRAM. I will retract this statement when Apple enables Quartz 2D Extreme by default, which makes all of your 2D windows, widgets, text, and composition using GPU-accelerated OpenGL textures stored in VRAM (Quartz Extreme holds the windows in RAM and composites them in VRAM, IIRC).
Another reason to use VMWare is that I can move the images from my workstation to the server. It's really nice to prototype the next server on my desktop and iron out the bugs while it's under my control, then I upload the files to the server team and they deploy it. We COULD do the same thing with QEMU, but they aren't going to run QEMU on their IBM zSeries boxes, they have ESX and contracts, and SLAs to adhere to.
That being said, I've used QEMU and VMWare myself. I find VMWare to be faster, and even the workstation edition has great management tools (the 'wrapper' application itself is high-quality).
To answer the big question, the best environment to host VMWare sessions is a VERY stripped-down Linux on a multi-core system. You can do things with the *NIX 'everything is a file' paradigm and symlinks that you just can't do as gracefully on Windows, not to mention the lower overhead of Linux as a whole. I'm a fan of VMWare/Gentoo myself, but I have enough machines to make all the compiling and config worthwhile (I share the config between several boxes). I lower the kernel timer to 100hz, make sure SMP is properly configured, tell the VM subsystem to avoid most swapping, set a 2G/2G kernel/user memory split, and set hdparm to read ahead and buffer writes.
I completely disagree. The ISVs are not competent to develop for multiple distros, they don't have the time nor the 'inside' knowledge required to properly package the software. Hell, if Epson can't competently package printer drivers for the Mac (which they don't, they put a.pkg inside a.dmg inside a.sit inside a.hqx when they could just give the damned.dmg), how can I expect them to deliver for my flavor of *NIX?
Package managers are a great way of making sure the software people want gets properly installed and can be removed when it is no longer wanted or needed. ISVs should focus on making their product work well, and the distro maintainers should package the software in a sane manner. Letting the ISVs do it would lead to a very Windows-like desktop environment with dozens of 'helpers' running in the background and on the start menu, interfering with the proper experience.
As for binary dependency and breakage, I think most apps should be written in higher-level languages that run in portable runtime engines.
Wow, that's a really broken and limited way to think. Linux has a totally different way of handling drivers AND software packages than Windows, and the Linux way is better by far.
A single package manager controls all the software on my linux system, and it does a damned good job of it, much better than the situation on the Windows end. And all the drivers for my harware come built-in to the kernel as generic drivers with PNP IDs for the different flavors and branding of the hardware.
If hardware vendors want their drivers distributed to Linux users, they should contribute to the kernel, release the specs so others can, or package blackbox binaries according to the system outlined below.
As for software packaging and sales, it would make a LOT more sense to purchase software PACKAGES online and use your handy package manager to install them. I'd rather buy a TurboTax-2006-1.0.1.ebuild with a unique security key for my account than 'go to staples'. Ideally the distros and the software vendors would meet in the middle on a package format (or set of formats) and an API to securely distribute licensed software, the distros could make nice GUI or CLI interfaces (i.e. 'TurboTax requires you to register and pay Intuit, Inc., would you like to purchase TurboTax? Y/n).
Where I work there's no chargebacks, no SLAs, and the accounting is very loose. Because there are no chargebacks, the IT department has to pay for all new technology out of pocket. We have to make a decision either to provide equipment OR to be able to service it. When a department wants something we have to take the defensive, even if it is the right tool for the job, because it comes out of OUR operating budget. IT ends up stagnating the company just to be able to maintain existing equipment because there's absolutely zero enduser ownership or responsibility. We have departments that buy expensive inkjets on our budget, then want them serviced and consumables replaced on our budget as well. The worst thing is that the powers-that-be are unable or unwilling to change to a more 'corporate' structure of chargebacks, rigid accounting, and purchase/support policies, for reasons I'm not quite sure of. I don't know if this is common amongst academic institutions, but I'm from 'corporate' and it's driving me batty!
Sorry, but the type of exploits we really fear (remote arbitrary code execution) ARE platform specific. One of the reasons I use a PPC as my gateway instead of an X86 is because on the off chance I am running a service with a vulnerability, the attackers will most likely overflow my buffers with X86 code that won't execute on my box.
Could the hacker just as easily change to PPC and attack me just as hard? Yes, but most don't.
Whe you take advantage of a buffer overflow, you're injecting machine code or bytecode into an unchecked buffer, overwriting the next piece of executable code in memory. The payload for this type of attack IS platform specific, unless you're attacking a bytecode-interpreting machine, line the JavA VM.
I wore a suit one day and left mid-day to 'get my car inspected', which was actually the truth. When I got back to the office I got a $7,000 raise from my boss. She was frantically making phone calls while I was out, trying to get immediate authorization for the money.
Playing double-or-nothing is a great way to get a raise or get canned, but in my experience, if you're on-the-ball you'll get the raise. I know my workplace would be in a world of pain if I left, just because I know a little about how everything works.
I recently did all this research myself. SATA on Linux is going to get MUCH faster, probably as fast as SCSI, but you'll have to wait for the libATA improvements to take hold. Right now NCQ isn't implemented, and neither are 'multiple sector transfers'. I bought hardware that WILL support those features because I know that NCQ will dramatically improve speed and latency (under high-use conditions) when it is finally fully-baked.
The project has been moving along quite well. I think their goal is to completely modularize, simplify, optimize, and consolidate the ATA, ATAPI, and SATA kernel pieces into one overarching (underlying?) library. I like this kind of work. I can't see why ALL disk-like I/O isn't under one big modular kernel library, it seems like it would make adding new transport types and drivers a lot simpler and reduce maintainance all-around.
I disagree. I did some work for a medical device designer and the firmware and low-level software routines that control cooling, backlighting, and CPU sleep states is tricky stuff. The hardware might be fully-baked, but the firmware that controls all the stuff might need final tweaking, and that would have a HUGE impact on power consumption. Apple doesn't want to give you the numbers from their 'full-speed, full-fan, both-cores-on' firmware revision because they probably look really bad. The final result will hopefully be much better. Also, if the machines are shipping in a month, the hardware is almost definitely fully-baked by now. The machines might even be coming out of the factory already, but the aforementioned tweaks might go into a firmware load that happens before they're boxed up and shipped.
Whatever you do, don't forget to toss a silica-gel pack in your (hopefully) hermetically sealed storage. You wouldn't want moisture to slowly eat your drives, would you?
they could not build the next generation of laptops with IBM chips (G5's). Too much heat. And that's been going on for a while now.
Don't forget that Motorola owns the G4, so IBM can ONLY produce the non-altivec PPC750 series and the no-good-for-mobiles PPC970. Motorola wasn't making much off their semiconductor divsion, so the spinned it off as FreeScale, but FreeScale hasn't got their ducks in a row enough to release their 8641D dual-core memory-controller-on-die chip.
I would have been happy with the 8641D in the lower-end machines and the 970 in the mid to high-end desktops, but I guess Apple got sick of dealing with this recurring issue of dealing with vendors who have little interest in producing top-notch chips for them.
Nope. From my understanding, which is very abstract and rudimentary, Intel's bottom-up 64-bit platform, the IA64 has all but failed, so they took the existing P4 'netburst' core and added instructions to the microcode that let it break-down and process AMD's 64-bit instructions. The core of the CPU changed little if at all for Intel to process 64-bit instructions, but the way they do it is a stopgap measure until they can build a real 64-bit core.
Remember that the x86 series from the i686 on has been an odd RISC/CISC hybrid, there's (oversimplified) a very small fast CPU at the core, with lots of logic around it to decode and optimize x86 instructions for it. It's essentially a RISC chip emulating a CISC x86, but less of an emulation and more of a hybridized design. Intel had similar issues when they debuted the PentiumPro and Pentium II, 16-bit apps were much slower on the new chips than the original Pentium because the chip was designed to handle 32-bit instructions, 16-bit code had to be 'pulled apart' more to feed efficiently to the new core. This is the same problem but in reverse.
These machines don't have a need for more than 4GB RAM, they only fit 2GB, so why go 64-bit when it's not going to be used to address more RAM? Also, Intel's AMD64 instruction set is SLOWER than their IA32 instruction set. The machines would be slower if they were Intel 64-bit machines.
AMD's (and IBM's) chips are optimized for 64-bit operation while retaining full 32-bit support, Intel's chips are optimized for 32-bit use and provide the ability to execute 64-bit instructions.
Trust me on this, I've got a Pentium D under my desk running Linux, and it's slightly faster running 32-bit top-to-bottom than it is with 64-bit optimized builds. The story would be different if I had an Athlon64, and it doesn't matter a hill of beans anyway unless I needed that huge address space (which I don't, I'm quite content with 1.5GB RAM).
What I'm saying is that I'll bet there are some hooks in there so if the Windows ACPI-Uni HAL tries loading, it'll be able to boot. I'm wildly speculating, but I don't imagine that EFI totally breaks Windows. Also, Microsoft might release EFI support in SP3 or something, EFIs been a long-time coming.
I don't think it'll be that hard. All we have to do is get GRUB working on the thing and I bet Windows running the ACPI Uniprocessor HAL will pick up the devices. GRUB has an EFI port, IIRC.
I'd rather have some robotic squeegees scraping off the excrement and dropping it into the ocean. The balloons could stay afloat using solar power and stay put by tethers to the ocean floor.
they can't risk introducing a flawed first Intel model; it's gotta be more or less perfect, and it's gotta be so much better than a G4 in almost every regard.
As the owner of a two-and-a-half year old 15" AlBook, I can say that there's no incentive for me to purchase another unless it has a serious speed boost. I won't buy a 2GHz G4 (or a 4GHz for that matter) as long as it's sitting on top of that crufty old memory bus that IBM introduced a decade ago. Even a single-core Pentium-M with a 533MHz memory bus would be incentive enough to buy, a dual core model would be an instant sell.
I've got a 15GB iPod that's over two years old and it's as good as it ever was. I make sure not to leave it in a hot car or outside overnight in the freezing weather, I take care not to go too hard on it physically and to keep the battery charged as often as possible (good for LiIon). I don't forsee needing another one until I run out of capacity (two months until I'm out of space), and this one will resell for about $60. Not too bad when you consider that I basically paid $75/year for a best-of-breed portable music player.
You have to treat the iPod for what it is, a LiIon battery, an LCD, a hard drive, and a resitance-based touch-sensitive surface, that's a lot of sensitive technology in an itty-bitty package, but it doesn't make it any less sensitive than a laptop. Most of the damaged iPods I see were severely abused by teenagers (I work in a high school) in ways that any reasonable adult wouldn't treat a piece of technology.
Well there's HUGE changes going on in the Linux dsk-access area, libATA is abstracting virtually ALL the storage functions into an in-kernel library that will be more modular and allow drivers to be developed more rapidly.
Getting NCQ working isn't easy work, there was absolutely no functionality in the kernel for it before, and adding it the right way means waiting for libATA to be fully-baked and adding it there.
Slashdot Mirror
I feel as if this works in the other direction as well. I unplugged my television three-and-a-half years ago and now ANYTHING on a TV is evtertainment. I stayed in a hotel last week and killed some time using the TV, it was AMAZING, even late at night when the programming was craptastic. Also, I can honestly say now after doing this that I like the commercials more than the programming itself.
It would be faster to 'tar' directly to the target machine. Tar will stream the output and is probably much more efficient than Windows Explorer.
/path/to/local/drive ./* /path/to/remote/drive/backup.tar
Also, booting the machine from a Linux boot CD and mounting the drive read-only and using tar to move the files is probably the fastest method. I do this all the time to recover/backup machines at work.
boot gentoo install cd...
mount network share/external drive
mount local drive '-o ro'
cd
tar -vcf
I'm a conspiracy-nut, but the two richest men in the world just decided to get out of the game at the same time. I'm betting that something like a big war, pandemic, or something that history is going to want to pin on someone is going to happen. I'd hate to be one of the people 'at the wheel' when the ship hit the iceberg. These people know what's coming before most of us do, I'd keep a close eye on international affairs with China over the next two years.
Microsoft wants a safety switch in case this tool starts causing PCs around the world to explode. Thus the program checks with Microsoft once a day to see if it should shut itself off.
Good, I've been building our 2006-07 academic year image on XP and this tool has twice kicked-in and called my legit-via-volume-key XP image a fraud. I eventually figured out that I had to be less millitant about deleting miscellaneous files before syspreping the beast, but I can certainly see some malware out there deliberately hooking into this tool to exploit people.
I'm not sure how the state of video drivers affects VMWare sessions. 3D graphics under VM sessions are all software-rendered anyway, so 3D should be very close on either platform, and the 2D graphics drivers for all but the VERY latest cards are nice and accelerated under X.
http://ftp.x.org/pub/X11R6.8.0/doc/radeon.4.html
I use a RADEON 9200 here at home because I use 3D in Linux and I don't want to use the binary-only driver, but at work I have an X600, which has perfectly good 2D, but only software 3D. I don't know about you, but I have no business doing anything 3D at work, so it's of no consequence that I don't have DRI there.
I'll repeat this: If you don't do 3D -outside- your VMWare sessions, you need not worry about 3D driver support. The 2D part of the driver still works swimmingly using the generic driver from xorg. If you're doing 3D -inside- VMWare sessions, you're being foolish because it's going to be rendered in software no matter what kind of video card you have.
Also, just to finish my technical pissing contest:
Video RAM has nothing to do with moving video on your PC. Having more or less VRAM will not affect how movies play. If I hear one more AV person say how they need a computer with 'lots of video memory' so they can play movies smoothly, I'll strangle them. Any card made since 1999 has PLENTY of VRAM for anything 2D, including motion video. Video RAM will not speed up Photoshop; it will not speed up Final Cut or Premiere; all of that stuff takes place on a frame buffer that fits quite nicely into even the most conservative VRAM. I will retract this statement when Apple enables Quartz 2D Extreme by default, which makes all of your 2D windows, widgets, text, and composition using GPU-accelerated OpenGL textures stored in VRAM (Quartz Extreme holds the windows in RAM and composites them in VRAM, IIRC).
Another reason to use VMWare is that I can move the images from my workstation to the server. It's really nice to prototype the next server on my desktop and iron out the bugs while it's under my control, then I upload the files to the server team and they deploy it. We COULD do the same thing with QEMU, but they aren't going to run QEMU on their IBM zSeries boxes, they have ESX and contracts, and SLAs to adhere to.
That being said, I've used QEMU and VMWare myself. I find VMWare to be faster, and even the workstation edition has great management tools (the 'wrapper' application itself is high-quality).
To answer the big question, the best environment to host VMWare sessions is a VERY stripped-down Linux on a multi-core system. You can do things with the *NIX 'everything is a file' paradigm and symlinks that you just can't do as gracefully on Windows, not to mention the lower overhead of Linux as a whole. I'm a fan of VMWare/Gentoo myself, but I have enough machines to make all the compiling and config worthwhile (I share the config between several boxes). I lower the kernel timer to 100hz, make sure SMP is properly configured, tell the VM subsystem to avoid most swapping, set a 2G/2G kernel/user memory split, and set hdparm to read ahead and buffer writes.
I completely disagree. The ISVs are not competent to develop for multiple distros, they don't have the time nor the 'inside' knowledge required to properly package the software. Hell, if Epson can't competently package printer drivers for the Mac (which they don't, they put a .pkg inside a .dmg inside a .sit inside a .hqx when they could just give the damned .dmg), how can I expect them to deliver for my flavor of *NIX?
Package managers are a great way of making sure the software people want gets properly installed and can be removed when it is no longer wanted or needed. ISVs should focus on making their product work well, and the distro maintainers should package the software in a sane manner. Letting the ISVs do it would lead to a very Windows-like desktop environment with dozens of 'helpers' running in the background and on the start menu, interfering with the proper experience.
As for binary dependency and breakage, I think most apps should be written in higher-level languages that run in portable runtime engines.
Wow, that's a really broken and limited way to think. Linux has a totally different way of handling drivers AND software packages than Windows, and the Linux way is better by far.
A single package manager controls all the software on my linux system, and it does a damned good job of it, much better than the situation on the Windows end. And all the drivers for my harware come built-in to the kernel as generic drivers with PNP IDs for the different flavors and branding of the hardware.
If hardware vendors want their drivers distributed to Linux users, they should contribute to the kernel, release the specs so others can, or package blackbox binaries according to the system outlined below.
As for software packaging and sales, it would make a LOT more sense to purchase software PACKAGES online and use your handy package manager to install them. I'd rather buy a TurboTax-2006-1.0.1.ebuild with a unique security key for my account than 'go to staples'. Ideally the distros and the software vendors would meet in the middle on a package format (or set of formats) and an API to securely distribute licensed software, the distros could make nice GUI or CLI interfaces (i.e. 'TurboTax requires you to register and pay Intuit, Inc., would you like to purchase TurboTax? Y/n).
Not always so.
Where I work there's no chargebacks, no SLAs, and the accounting is very loose. Because there are no chargebacks, the IT department has to pay for all new technology out of pocket. We have to make a decision either to provide equipment OR to be able to service it. When a department wants something we have to take the defensive, even if it is the right tool for the job, because it comes out of OUR operating budget. IT ends up stagnating the company just to be able to maintain existing equipment because there's absolutely zero enduser ownership or responsibility. We have departments that buy expensive inkjets on our budget, then want them serviced and consumables replaced on our budget as well.
The worst thing is that the powers-that-be are unable or unwilling to change to a more 'corporate' structure of chargebacks, rigid accounting, and purchase/support policies, for reasons I'm not quite sure of. I don't know if this is common amongst academic institutions, but I'm from 'corporate' and it's driving me batty!
Sorry, but the type of exploits we really fear (remote arbitrary code execution) ARE platform specific. One of the reasons I use a PPC as my gateway instead of an X86 is because on the off chance I am running a service with a vulnerability, the attackers will most likely overflow my buffers with X86 code that won't execute on my box.
Could the hacker just as easily change to PPC and attack me just as hard? Yes, but most don't.
Whe you take advantage of a buffer overflow, you're injecting machine code or bytecode into an unchecked buffer, overwriting the next piece of executable code in memory. The payload for this type of attack IS platform specific, unless you're attacking a bytecode-interpreting machine, line the JavA VM.
I wore a suit one day and left mid-day to 'get my car inspected', which was actually the truth. When I got back to the office I got a $7,000 raise from my boss. She was frantically making phone calls while I was out, trying to get immediate authorization for the money.
Playing double-or-nothing is a great way to get a raise or get canned, but in my experience, if you're on-the-ball you'll get the raise. I know my workplace would be in a world of pain if I left, just because I know a little about how everything works.
Frank Poole is probably rolling in his, um, satellite.
I recently did all this research myself. SATA on Linux is going to get MUCH faster, probably as fast as SCSI, but you'll have to wait for the libATA improvements to take hold. Right now NCQ isn't implemented, and neither are 'multiple sector transfers'. I bought hardware that WILL support those features because I know that NCQ will dramatically improve speed and latency (under high-use conditions) when it is finally fully-baked.
The site to track progress on the library and driver status is here: http://linux.yyz.us/sata/
The project has been moving along quite well. I think their goal is to completely modularize, simplify, optimize, and consolidate the ATA, ATAPI, and SATA kernel pieces into one overarching (underlying?) library. I like this kind of work. I can't see why ALL disk-like I/O isn't under one big modular kernel library, it seems like it would make adding new transport types and drivers a lot simpler and reduce maintainance all-around.
I just stop by a local manufacturing place and ask if I can buy some from them. They make money and I don't pay retail rates.
I disagree. I did some work for a medical device designer and the firmware and low-level software routines that control cooling, backlighting, and CPU sleep states is tricky stuff. The hardware might be fully-baked, but the firmware that controls all the stuff might need final tweaking, and that would have a HUGE impact on power consumption. Apple doesn't want to give you the numbers from their 'full-speed, full-fan, both-cores-on' firmware revision because they probably look really bad. The final result will hopefully be much better.
Also, if the machines are shipping in a month, the hardware is almost definitely fully-baked by now. The machines might even be coming out of the factory already, but the aforementioned tweaks might go into a firmware load that happens before they're boxed up and shipped.
Whatever you do, don't forget to toss a silica-gel pack in your (hopefully) hermetically sealed storage. You wouldn't want moisture to slowly eat your drives, would you?
they could not build the next generation of laptops with IBM chips (G5's). Too much heat. And that's been going on for a while now.
Don't forget that Motorola owns the G4, so IBM can ONLY produce the non-altivec PPC750 series and the no-good-for-mobiles PPC970. Motorola wasn't making much off their semiconductor divsion, so the spinned it off as FreeScale, but FreeScale hasn't got their ducks in a row enough to release their 8641D dual-core memory-controller-on-die chip.
I would have been happy with the 8641D in the lower-end machines and the 970 in the mid to high-end desktops, but I guess Apple got sick of dealing with this recurring issue of dealing with vendors who have little interest in producing top-notch chips for them.
You're pulling our legs. Please tell us you're pulling our legs.
Nope. From my understanding, which is very abstract and rudimentary, Intel's bottom-up 64-bit platform, the IA64 has all but failed, so they took the existing P4 'netburst' core and added instructions to the microcode that let it break-down and process AMD's 64-bit instructions. The core of the CPU changed little if at all for Intel to process 64-bit instructions, but the way they do it is a stopgap measure until they can build a real 64-bit core.
Remember that the x86 series from the i686 on has been an odd RISC/CISC hybrid, there's (oversimplified) a very small fast CPU at the core, with lots of logic around it to decode and optimize x86 instructions for it. It's essentially a RISC chip emulating a CISC x86, but less of an emulation and more of a hybridized design. Intel had similar issues when they debuted the PentiumPro and Pentium II, 16-bit apps were much slower on the new chips than the original Pentium because the chip was designed to handle 32-bit instructions, 16-bit code had to be 'pulled apart' more to feed efficiently to the new core. This is the same problem but in reverse.
Alright, Lets get a few things straight:
These machines don't have a need for more than 4GB RAM, they only fit 2GB, so why go 64-bit when it's not going to be used to address more RAM? Also, Intel's AMD64 instruction set is SLOWER than their IA32 instruction set. The machines would be slower if they were Intel 64-bit machines.
AMD's (and IBM's) chips are optimized for 64-bit operation while retaining full 32-bit support, Intel's chips are optimized for 32-bit use and provide the ability to execute 64-bit instructions.
Trust me on this, I've got a Pentium D under my desk running Linux, and it's slightly faster running 32-bit top-to-bottom than it is with 64-bit optimized builds. The story would be different if I had an Athlon64, and it doesn't matter a hill of beans anyway unless I needed that huge address space (which I don't, I'm quite content with 1.5GB RAM).
What I'm saying is that I'll bet there are some hooks in there so if the Windows ACPI-Uni HAL tries loading, it'll be able to boot. I'm wildly speculating, but I don't imagine that EFI totally breaks Windows. Also, Microsoft might release EFI support in SP3 or something, EFIs been a long-time coming.
I don't think it'll be that hard. All we have to do is get GRUB working on the thing and I bet Windows running the ACPI Uniprocessor HAL will pick up the devices. GRUB has an EFI port, IIRC.
I'd rather have some robotic squeegees scraping off the excrement and dropping it into the ocean. The balloons could stay afloat using solar power and stay put by tethers to the ocean floor.
they can't risk introducing a flawed first Intel model; it's gotta be more or less perfect, and it's gotta be so much better than a G4 in almost every regard.
As the owner of a two-and-a-half year old 15" AlBook, I can say that there's no incentive for me to purchase another unless it has a serious speed boost. I won't buy a 2GHz G4 (or a 4GHz for that matter) as long as it's sitting on top of that crufty old memory bus that IBM introduced a decade ago. Even a single-core Pentium-M with a 533MHz memory bus would be incentive enough to buy, a dual core model would be an instant sell.
I've got a 15GB iPod that's over two years old and it's as good as it ever was. I make sure not to leave it in a hot car or outside overnight in the freezing weather, I take care not to go too hard on it physically and to keep the battery charged as often as possible (good for LiIon). I don't forsee needing another one until I run out of capacity (two months until I'm out of space), and this one will resell for about $60. Not too bad when you consider that I basically paid $75/year for a best-of-breed portable music player.
You have to treat the iPod for what it is, a LiIon battery, an LCD, a hard drive, and a resitance-based touch-sensitive surface, that's a lot of sensitive technology in an itty-bitty package, but it doesn't make it any less sensitive than a laptop. Most of the damaged iPods I see were severely abused by teenagers (I work in a high school) in ways that any reasonable adult wouldn't treat a piece of technology.
Well there's HUGE changes going on in the Linux dsk-access area, libATA is abstracting virtually ALL the storage functions into an in-kernel library that will be more modular and allow drivers to be developed more rapidly.
Getting NCQ working isn't easy work, there was absolutely no functionality in the kernel for it before, and adding it the right way means waiting for libATA to be fully-baked and adding it there.