True. I would imagine there are ways, though, of minimizing the loss going from AAC to MP3. A naive conversion would convert AAC back to uncompressed PCM samples, and then run that through a standard MP3 converter. That strategy would work (and is likely the one employed), but it seems like it would cause the maximum damage.
Another technique transcodes one format to the other. AAC is also a lossy format, and its psychoacoustic model has already decided to discard some information. Transcoding from AAC to MP3 could convert the sound data in the frequency domain (i.e. the MDCT coefficients--the representation that AAC and MP3 use to code the sound once it's been shaped by the psychoacoustic model), throwing away only the sound bands that MP3 doesn't support. You may have to do some additional work to handle the smaller ranges of frame sizes that MP3 supports, but it's tractable.
The main point is that you don't have to apply the full psychoacoustic model again to decide on more things to discard. Since MP3 represents a narrower band of sound than AAC does, most of the conversion can focus on removing the stuff MP3 can't represent, and then just recoding what remains with the greatest fidelity possible.
Something tells me, though, that they're not bothering to do it that way, but I'd be interested to know if they do.
(Note: I'm not an audio format expert, and I have simplified the description above. For example, AAC uses a modified DCT, so it's not as pure a frequency domain representation as, say, an FFT. MP3 apparently uses a hybrid approach that isn't pure MDCT. And so on. Still, capturing the audio data nearer to its encoded form and transcoding it, rather than going all the way back out to audio samples should retain higher fidelity.)
This is something of a chicken and egg problem isn't there? I don't recall Windows having any sort of natural advantage when I was in school. It was all Apple ][s, except in the business department where they had some PS/2s running MS-DOS. A couple people thought Windows was interesting, but nobody was in a hurry to switch.
All of this Windows software has developed through the traditional "network effect," and that was nurtured through programs such as Microsoft's that put Windows on many desktops throughout the 90s. That doesn't mean it can't be brought to Linux someday, though. There has to be some demand before it happens. Either that, or some open source efforts to replace the poorly-written software that you mention.
Our local cell tower went wonky in the early evening, around when Europe would be crossing over into 2009. Since companies like Ericsson and NSN make the vast majority of basestation equipment, I wonder if their internal time base is set to either GMT, or GMT+1 or GMT+2 to match their home country. If so, it could have been a New Year's glitch.
What do I mean by "went wonky?" Around 5:00 Central and for awhile after that, we couldn't send or receive phone calls regardless of having full-strength reception. If a call connected, it acted as if it had no reception or next to no reception. Calls dropped with a "connection error."
If you're curious, this was on AT&T, and was not a 3G connection.
I came here to make pretty much the same point. IBM has a habit of reusing the same microarchitecture with tweaks to run different variants of the POWER or PowerPC instruction set as needed to fit a particular application niche.
I suspect IBM didn't say specifically "Here's the Cell Broadband Architecture and what it can do." Rather, since the Xbox360's CPU doesn't have any SPEs, I imagine the presentation had more to do with what the PPU would be capable of, and was part of the IBM processor roadmap anyway.
Of course, in the article's case, they didn't remove anything. They screened out the embryos that had the undesirable gene. It's like the difference between buying a car with an automatic and trying to convert it to manual, versus only considering cars that come with manual transmissions when shopping.
I do think it's fascinating that so much of the "junk" DNA may actually do something useful. It'll be interesting to find out exactly what.
I'm partial to my own game, Space Patrol. I'd be happy to wrap up jzIntv + Space Patrol (full edition) for such a thing. Both jzIntv and Space Patrol are GPL, and the Windows emulator works on even fairly slow machines. (I developed it on a 300MHz machine, and it runs full speed on 200MHz ARM machines.)
Also, there's an interesting game or two at Farbs.org.
Sounds like Microsoft needlessly botched that, then.
Under Linux, I can run mixtures of 32-bit and 64-bit apps with nary a thought, as long as my library directories are set up properly. Distros have done a reasonably good job of that it seems. OS X also seems to be a similar story, seamlessly mixing architectures, not just bit-widths.
Why does a VPN client need a Win64 version? Are they installing kernel-level drivers or something? I'm pretty sure I can take my 32-bit "vpnc" binaries under Linux and run them on my 64-bit box just fine. Lemme guess, it's Cisco's client?
AMD therefore decided that, in the first implementations of the architecture, only the least significant 48 bits of a virtual address would actually be used in address translation (page table lookup). However, bits 48 through 63 of any virtual address must be copies of bit 47 (in a manner akin to sign extension), or the processor will raise an exception. Addresses complying with this rule are referred to as "canonical form." Canonical form addresses run from 0 through 00007FFF`FFFFFFFF, and from FFFF8000`00000000 through FFFFFFFF`FFFFFFFF, for a total of 256 TB of usable virtual address space.
On to your next point...
It's not uncommon to address 1TB of physical memory on very high end servers. That's 40 bits right there. Now imagine you're building a nice big cluster of these machines. You want to assign a different address to every byte of physical memory. You may not be able to afford more than 1024 machines right now, but you'd sure like to in the future.
And I'm failing to see the relevance. This thread, when it started, was about 64-bit desktops.
Now, you're right in the server and high-end compute space. I recall reading some of the Linux kernel guys (either Ingo Molnar or Andi Kleen, IIRC) saying that 48 bits will only hold us for around a decade, if that. Large Altix boxes are already pushing on the 48-bit mark. But that's for the very high-end server stuff. In the home space, I think you'll see the compute capacity level off for most things, and the devices will start to shrink. The only exception might be home media servers, and there it's more a matter of disk space, not RAM.
The alternative is to teach users that they want the 64-bit version. Everything is ported. The problems are solved. There is no point to 32-bit anymore, unless you have an old machine like the one I'm writing this on.
The only reason I could see is if you had some old crufty binary-only thing that had a hard time finding the compatibility libraries. I guess these days they've even solve thunking between 32-bit browser plugins and 64-bit browsers.
What is the point of making predictions about a 64-bit transition which already happened?
As others have pointed out, nothing's really utilizing 64 bit in the home space. A large number of Vista users are apparently still in 32 bit land (80% as of mid-year this year). So, it's a transition that hasn't really finished yet. My prediction is that 5-10 years from now, we'll look back and decide that there weren't many desktop applications that really needed 64 bits other than what I mentioned. Rather, it was general multitasking that benefited from having lots of memory for buffers and multiple apps/programs running at once.
281,474,976,710,656 bytes (256TB) will be enough for anybody.;-)
Seriously: We use up about 2 address bits every 3 years. 46 bits is 14 bits more than 32. 3 * 14 / 2 = 21. You don't think AMD or Intel will add more address pins to their packages sometime in the next 21 years?
I actually wouldn't be surprised if user space stayed 32 bit (or mostly 32 bit) for a very long time. The one thing Intel got right with the 386 is that its protected mode allowed for a mixture of 16-bit and 32-bit program contexts. AMD continued this tradition with x86-64. It's possible to have a 64-bit kernel with 32-bit user space applications. (Indeed, I've been tempted to set up a Linux machine that way in the past--put a 64-bit kernel under a 32-bit install.)
See, it seems reasonable that a 32-bit OS kernel will not handle more than a few gigabytes of RAM as efficiently as a 64-bit OS kernel. By default, 32-bit Linux puts memory over the 960MB mark into a "highmem" pool that's less efficient. It wouldn't surprise me if Windows does something similar. I'm less familiar with its VM and its limitations, although I recall hearing rumblings about XP and a 2GB limit. (Note: I haven't looked into it and could be talking out of my ass there about XP.)
So, to utilize gobs of RAM efficiently, it seems like you at least ought to have a 64-bit kernel. But what about user space?
It's the rare application that needs even a gigabyte mapped directly into its own process space. (That's different than needing a machine with 1GB installed.) Rather, a large amount of RAM goes to gobs of disk buffering, supporting parallel processes (eye candy for the display, virus scanners, the desktop GUI, etc), and so on. Unless you're doing video editing or some other sort of heavy media application, you're mostly just using the RAM to enable multitasking with lots of disk buffering. That means that apps can stay 32-bit for quite awhile, but still benefit from a 64-bit system. It's similar to how 16-bit Windows apps benefited from 386 Enhanced mode in Windows 3.x.
I suspect that'll be the key characteristic of the 32-bit to 64-bit shift. Most apps will remain 32-bit for quite some time. For many, this is the most efficient choice. Databases and media editing applications will make the jump first, once the kernel's stable. Everything else will trickle in over the next decade.
I predict that the single biggest improvement the 64-bit OS will bring to the desktop is editing one's home movies. Other than that, I don't expect much "wow." We've come a long way from an Amiga, a Video Toaster and a VCR. Or have we?:-)
Initially, the switch from 16- to 32-bit was just as un-interesting. People upgraded to a 32-bit OS (VMS, or 4BSD, or 386 Xenix, or Windows 95) and their old PDP-11 or 286 binaries ran just the same, except that more of them could fit into memory at the same time.
At least in the PC space, I characterize the "16-bit to 32-bit" transition as the transition from DOS to Windows, since it coincided with the broad transition from 286s (16-bit CPUs) to 386s (32-bit CPUs). Sure, there were 32-bit DOS extenders, and sure the Windows API was initially 16 bit, but those are technicalities. Windows could run in 386 Enhanced mode and make use of lots of memory, even with its 16-bit API, and so began the big move from text UIs to GUIs in the PC space.
The subsequent moves (Win 3.x to Win9x to WinXP) haven't been nearly so big. Each one's been a refinement of the previous one. They've gotten shinier and fancier, but the way one interacts with the WIMP paradigm hasn't changed much.
Right now, we're still using programs written for 32-bit platforms that happen to have been recompiled for 64-bit pointers. Over time, developeprs will learn to program for the large address space, and at that point, the user experience is likely to change again.
I'm not sure programmers have really figured out what to do with 4GB of RAM other than cache the bejeebus out of everything, and/or store large amounts of media files. I'm guessing if large gobs of RAM are going to change the user interface, it's because the user interface suddenly became a big interactive video. After all, 4GB is nearly the capacity of a single-layer DVD.
I don't agree w/ Eric on this one. The shift from 32-bit to 64-bit systems has been darn near seamless as compared to previous transitions. That's a far cry from the 8-to-16 jump or the 16-to-32 jump.
Honestly, most people can't tell that they've shifted from 32-bit to 64-bit. If there wasn't a dialog box or a sticker that told them they'd switched, they wouldn't know.
Now this wouldn't be/. without a bad car analogy. Going from 8-bit to 16-bit was like going from horse-drawn buggies to the early Model Ts--a big change. Going from 16-bit to 32-bit was like going from these early, slow cars to the more recognizable cars of the 30s onward. Cars that actually had starters and drove at reasonable speeds. Each step provided a noticeable difference in the travel experience and it brought with it a whole new round of infrastructure requirements.
Going from 32-bit to 64-bit is like going from a gasoline engine to a hybrid. Sure, it's a change in the underlying mechanism, but it doesn't fundamentally change the driving experience all that much.
Slashdot Mirror
Ah, so that's why they're called Sticky Keys.
True. I would imagine there are ways, though, of minimizing the loss going from AAC to MP3. A naive conversion would convert AAC back to uncompressed PCM samples, and then run that through a standard MP3 converter. That strategy would work (and is likely the one employed), but it seems like it would cause the maximum damage.
Another technique transcodes one format to the other. AAC is also a lossy format, and its psychoacoustic model has already decided to discard some information. Transcoding from AAC to MP3 could convert the sound data in the frequency domain (i.e. the MDCT coefficients--the representation that AAC and MP3 use to code the sound once it's been shaped by the psychoacoustic model), throwing away only the sound bands that MP3 doesn't support. You may have to do some additional work to handle the smaller ranges of frame sizes that MP3 supports, but it's tractable.
The main point is that you don't have to apply the full psychoacoustic model again to decide on more things to discard. Since MP3 represents a narrower band of sound than AAC does, most of the conversion can focus on removing the stuff MP3 can't represent, and then just recoding what remains with the greatest fidelity possible.
Something tells me, though, that they're not bothering to do it that way, but I'd be interested to know if they do.
(Note: I'm not an audio format expert, and I have simplified the description above. For example, AAC uses a modified DCT, so it's not as pure a frequency domain representation as, say, an FFT. MP3 apparently uses a hybrid approach that isn't pure MDCT. And so on. Still, capturing the audio data nearer to its encoded form and transcoding it, rather than going all the way back out to audio samples should retain higher fidelity.)
Indeed. I like to call Windows XP's default theme "Windows Xbox." I run the classic theme myself when forced to use Windows XP.
This is something of a chicken and egg problem isn't there? I don't recall Windows having any sort of natural advantage when I was in school. It was all Apple ][s, except in the business department where they had some PS/2s running MS-DOS. A couple people thought Windows was interesting, but nobody was in a hurry to switch.
All of this Windows software has developed through the traditional "network effect," and that was nurtured through programs such as Microsoft's that put Windows on many desktops throughout the 90s. That doesn't mean it can't be brought to Linux someday, though. There has to be some demand before it happens. Either that, or some open source efforts to replace the poorly-written software that you mention.
Our local cell tower went wonky in the early evening, around when Europe would be crossing over into 2009. Since companies like Ericsson and NSN make the vast majority of basestation equipment, I wonder if their internal time base is set to either GMT, or GMT+1 or GMT+2 to match their home country. If so, it could have been a New Year's glitch.
What do I mean by "went wonky?" Around 5:00 Central and for awhile after that, we couldn't send or receive phone calls regardless of having full-strength reception. If a call connected, it acted as if it had no reception or next to no reception. Calls dropped with a "connection error."
If you're curious, this was on AT&T, and was not a 3G connection.
I came here to make pretty much the same point. IBM has a habit of reusing the same microarchitecture with tweaks to run different variants of the POWER or PowerPC instruction set as needed to fit a particular application niche.
I suspect IBM didn't say specifically "Here's the Cell Broadband Architecture and what it can do." Rather, since the Xbox360's CPU doesn't have any SPEs, I imagine the presentation had more to do with what the PPU would be capable of, and was part of the IBM processor roadmap anyway.
Of course, in the article's case, they didn't remove anything. They screened out the embryos that had the undesirable gene. It's like the difference between buying a car with an automatic and trying to convert it to manual, versus only considering cars that come with manual transmissions when shopping.
I do think it's fascinating that so much of the "junk" DNA may actually do something useful. It'll be interesting to find out exactly what.
Yeah, no kidding. "Waiter, some ice for my Irish coffee please?"
Perhaps the sub is made of irony?
That seems odd, because usually that information is supposed to be communicated down via EDID. Got a reference?
I'm partial to my own game, Space Patrol. I'd be happy to wrap up jzIntv + Space Patrol (full edition) for such a thing. Both jzIntv and Space Patrol are GPL, and the Windows emulator works on even fairly slow machines. (I developed it on a 300MHz machine, and it runs full speed on 200MHz ARM machines.)
Also, there's an interesting game or two at Farbs.org.
Sounds like Microsoft needlessly botched that, then.
Under Linux, I can run mixtures of 32-bit and 64-bit apps with nary a thought, as long as my library directories are set up properly. Distros have done a reasonably good job of that it seems. OS X also seems to be a similar story, seamlessly mixing architectures, not just bit-widths.
Why does a VPN client need a Win64 version? Are they installing kernel-level drivers or something? I'm pretty sure I can take my 32-bit "vpnc" binaries under Linux and run them on my 64-bit box just fine. Lemme guess, it's Cisco's client?
That's why I said "large media files." Basically, movies or high DPI / many-layered Photoshop images both apply.
That said, that's more of a professional workstation sort of use than what I tend to think of as "desktop user." Maybe I need recalibrating?
Bull. The AMD64 TLB only gives you 48 bits for now, partitioned into half for the OS (0xFFFF800000000000 to 0xFFFFFFFFFFFFFFFF), and half for user (0x0000000000000000 to 0x00007FFFFFFFFFFF). And I quote:
On to your next point...
And I'm failing to see the relevance. This thread, when it started, was about 64-bit desktops.
Now, you're right in the server and high-end compute space. I recall reading some of the Linux kernel guys (either Ingo Molnar or Andi Kleen, IIRC) saying that 48 bits will only hold us for around a decade, if that. Large Altix boxes are already pushing on the 48-bit mark. But that's for the very high-end server stuff. In the home space, I think you'll see the compute capacity level off for most things, and the devices will start to shrink. The only exception might be home media servers, and there it's more a matter of disk space, not RAM.
The only reason I could see is if you had some old crufty binary-only thing that had a hard time finding the compatibility libraries. I guess these days they've even solve thunking between 32-bit browser plugins and 64-bit browsers.
As others have pointed out, nothing's really utilizing 64 bit in the home space. A large number of Vista users are apparently still in 32 bit land (80% as of mid-year this year). So, it's a transition that hasn't really finished yet. My prediction is that 5-10 years from now, we'll look back and decide that there weren't many desktop applications that really needed 64 bits other than what I mentioned. Rather, it was general multitasking that benefited from having lots of memory for buffers and multiple apps/programs running at once.
281,474,976,710,656 bytes (256TB) will be enough for anybody. ;-)
Seriously: We use up about 2 address bits every 3 years. 46 bits is 14 bits more than 32. 3 * 14 / 2 = 21. You don't think AMD or Intel will add more address pins to their packages sometime in the next 21 years?
I actually wouldn't be surprised if user space stayed 32 bit (or mostly 32 bit) for a very long time. The one thing Intel got right with the 386 is that its protected mode allowed for a mixture of 16-bit and 32-bit program contexts. AMD continued this tradition with x86-64. It's possible to have a 64-bit kernel with 32-bit user space applications. (Indeed, I've been tempted to set up a Linux machine that way in the past--put a 64-bit kernel under a 32-bit install.)
See, it seems reasonable that a 32-bit OS kernel will not handle more than a few gigabytes of RAM as efficiently as a 64-bit OS kernel. By default, 32-bit Linux puts memory over the 960MB mark into a "highmem" pool that's less efficient. It wouldn't surprise me if Windows does something similar. I'm less familiar with its VM and its limitations, although I recall hearing rumblings about XP and a 2GB limit. (Note: I haven't looked into it and could be talking out of my ass there about XP.)
So, to utilize gobs of RAM efficiently, it seems like you at least ought to have a 64-bit kernel. But what about user space?
It's the rare application that needs even a gigabyte mapped directly into its own process space. (That's different than needing a machine with 1GB installed.) Rather, a large amount of RAM goes to gobs of disk buffering, supporting parallel processes (eye candy for the display, virus scanners, the desktop GUI, etc), and so on. Unless you're doing video editing or some other sort of heavy media application, you're mostly just using the RAM to enable multitasking with lots of disk buffering. That means that apps can stay 32-bit for quite awhile, but still benefit from a 64-bit system. It's similar to how 16-bit Windows apps benefited from 386 Enhanced mode in Windows 3.x.
I suspect that'll be the key characteristic of the 32-bit to 64-bit shift. Most apps will remain 32-bit for quite some time. For many, this is the most efficient choice. Databases and media editing applications will make the jump first, once the kernel's stable. Everything else will trickle in over the next decade.
I predict that the single biggest improvement the 64-bit OS will bring to the desktop is editing one's home movies. Other than that, I don't expect much "wow." We've come a long way from an Amiga, a Video Toaster and a VCR. Or have we? :-)
You can always download and install Ubuntu yourself... You just won't have support.
Yes!
The biggest competitor to any new release from Microsoft is the previous release from Microsoft.
At least in the PC space, I characterize the "16-bit to 32-bit" transition as the transition from DOS to Windows, since it coincided with the broad transition from 286s (16-bit CPUs) to 386s (32-bit CPUs). Sure, there were 32-bit DOS extenders, and sure the Windows API was initially 16 bit, but those are technicalities. Windows could run in 386 Enhanced mode and make use of lots of memory, even with its 16-bit API, and so began the big move from text UIs to GUIs in the PC space.
The subsequent moves (Win 3.x to Win9x to WinXP) haven't been nearly so big. Each one's been a refinement of the previous one. They've gotten shinier and fancier, but the way one interacts with the WIMP paradigm hasn't changed much.
I'm not sure programmers have really figured out what to do with 4GB of RAM other than cache the bejeebus out of everything, and/or store large amounts of media files. I'm guessing if large gobs of RAM are going to change the user interface, it's because the user interface suddenly became a big interactive video. After all, 4GB is nearly the capacity of a single-layer DVD.
Of course, I'm hardcore enough I would have done that in DEBUG.EXE...
A:\> DEBUG
:1C
-a 100
xxxx:0100 MOV DX, 0109
xxxx:0103 MOV AH, 9
xxxx:0105 INT 21
xxxx:0107 INT 20
xxxx:0109 DB "Get off my lawn!", 0D, 0A, "$"
xxxx:011C [enter]
-n offlawn.com
-rcx
CX 0000
-w
Writing 0001C bytes -q
A:\> offlawn
Now that's funny.
Aren't jokes supposed to be funny?
I don't agree w/ Eric on this one. The shift from 32-bit to 64-bit systems has been darn near seamless as compared to previous transitions. That's a far cry from the 8-to-16 jump or the 16-to-32 jump.
Honestly, most people can't tell that they've shifted from 32-bit to 64-bit. If there wasn't a dialog box or a sticker that told them they'd switched, they wouldn't know.
Now this wouldn't be /. without a bad car analogy. Going from 8-bit to 16-bit was like going from horse-drawn buggies to the early Model Ts--a big change. Going from 16-bit to 32-bit was like going from these early, slow cars to the more recognizable cars of the 30s onward. Cars that actually had starters and drove at reasonable speeds. Each step provided a noticeable difference in the travel experience and it brought with it a whole new round of infrastructure requirements.
Going from 32-bit to 64-bit is like going from a gasoline engine to a hybrid. Sure, it's a change in the underlying mechanism, but it doesn't fundamentally change the driving experience all that much.
Wine Is Not an Emulator.