"Is it wrong?" I concluded. "Well, student's, that's a moral decision you'll have to make on your own..."
Unless you have the artist's permission, I think it's clear that it's wrong. The fact that the music industry is engaged in a greater wrong is not even that much of a mitigating factor. It's up to the artist to choose to involve themselves in civil disobedience against the label system, to accept the consequences of sharing their songs on P2P, whether good or bad. It's not up to you to make that decision for them.
It's like software piracy. There is no doubt that some companies have benefited tremendously from secondary effects of having their software widely pirated. Microsoft is a perfect example... piracy of Office has been a big part of what destroyed the market for office suites that might compete against Office on the basis of price. It's hard to even give them away now, and there's no doubt that without that piracy Office would have a lower market share. But that doesn't justify trading copies of Office, it would be Microsoft's responsibility to allow additional people to use your copy of Office. If anything, it makes pirating Office even more reprehensible, given what the long term results have been.
Similarly, trading music that artists have chosen not to share has reduced the value of independant artists, to the point that it's hard for them to get attention even by giving their music (some of which is tremendously good) away. If you don't like the label system, it's far more moral and effective to promote sites like 3hive that hilight independant artists, many of whom are more than happy to let you download complete songs (not just 30 second samples) if there's a chance that'll convince you to buy their CDs. And, heck, it even works.
It'd work better if epople would quit thinking they need the latest music by some label artist, and take a flyer on someone they've never heard of, and pass the samples around if they like them. They don't even need P2P to do it, they can just email a URL... and it's completely legal AND moral and does a MUCH better job of disempowering the RIAA and the label system.
And, freedom of speech is not synonymous with "freedom from consequences."
Well, um, actually, it is. It is a very specific subset of the possible consequences that the US "Freedom of Speech" guarantees, but it does guarantee that. The whole point to "civil disobedience" is that one is free to engage in a variety of actions for which one consequence IS arrest, if one is willing to accept that consequence. The people who wrote the First Amendment had engaged in civil disobedience, and some had died for it, for as little as speaking out, accepting the consequences of their actions.
So don't for one minute think that they imagined that Freedom of Speech meant anything less than the freedom to speak out without the risk of consequences... because they absolutely knew that they already had the freedom to speak if they were willing to accept those consequences.
That's why the term "chilling effect" is used. Laws that not only prohibit speech but that might have the effect of discouraging speech are not permitted by the first amendment, and using non-judicial punishment and non-governmental organizations as a cutout shoudn't be considered any less an egregious violation of the constitution than directly passing a law banning speech.
You might be called a traitor for speaking out against the war, but you will not be prosecuted as one.
You might be fired from your job, denied permits and licenses, and be harassed short of prosecution, and otherwise persecuted for it. No, you can't be prosecuted, but so long as the non-judicial punishment is under the radar that's just fne.
I guess I just don't know exactly how the licensing works.
There are very few open source projects that limit commercial redistribution of the software. Oh, there's a broad range of licenses, from the "you can do it as long as you don't sue us if it breaks" modified BSD license, through to "you can do it as long as you make the result open source" GPL, but products like the dual-licensed Ghostscript or the no-commercial-use Kermit have become fairly rare.
That's a pretty important thing to understand about Open Source. Even a lot of Open Source developers don't "get" it, and ask the CSRG folks why they hadn't sued Microsoft for using BSD code in Windows NT... and are utterly befuddled when the response is "they did exactly what they're supposed to do".
If they are openly admiting that their code is nearly an exact duplicate of Firefox, it might limit them in the future.
Actually, hiding the use of Open Source has often turned out to be a bigger problem for companies. That's how USL/USG ended up having to settle with CSRG over the BSD-Lite software releases, and that's why CherryOS imploded.
it seems like it'd be a lot easier just to switch rendering engines when you hit a bad page than to copy the link, open another application, paste the link into it, etc.
It seems like it would have been a lot easier to add an "open in internet explorer" menu/contextual menu/accelerator key, and a lot less likely to lead to people getting confused about whether they're in a "safe" (relatively) browser or not.
The big deal with Netscape 8 is that it offers the choice of using the IE or Firefox/Gecko rendering engine on different pages.
The fundamental security flaws that are inherent in the Microsoft HTML Control can't be fixed by a wrapper, because they're in the HTML control itself, not the IE "shell". So you're no safer using the "IE Engine" inside Netscape than just using IE.
So this is no different than just using IE for the pages that need IE, except that people who think they're being safer using Netscape instead of IE are likely to let their guard down when using this feature.
I don't recall which one I finally got to work, lo these many years ago, I just remember how sluggish it was. It's really more of an office conversation piece these days.
Generally, on a Mac, you only get a dialog if there is an immediate need for user input.
That used to be true. And generally on the Mac you didn't get supposedly sandboxed environments doing dangerous things, either. These used to be among the reasons Mac OS X was inherently resistant to the kind of scattershot exploits that Windows was famous for.
Now Apple is starting to change both of these things, in a kind of codependent hobble down the same "road... paved with good intentions" that Microsoft pranced boldly down in the '90s.
But shouldn't VOIP users if they are technically savvy to use VOIP also be responsible and be sure that they can dial (ie have phone number handy) an emergency service?
I'm sorry, but I can't parse that sentence. No matter how I try, it seems to be saying something about users being technically savvy. I know that can't be right, so there MUST be something wrong with the way I'm reading it.
"Not yet, Joe Consumer. You want to keep your land line in case of an emergency!"
Hell yes. Or at least a cellphone. I could see getting VOIP as a second or third line but I wouldn't dream of getting it as my only phone service.
Even if they DID provide 911 I sure wouldn't want to depend on my ISP to be able to call anyone, let alone emergency services. For a while my honme Internet service would go down on Fridays regular as clockwork. No thanks, a VOIP-only house isn't in my plans.
It's not possible for VOIP to provide the service guarantees of wired phone lines, if nothing else because they don't come with a dedicated pair of wires going back to an exchange with its own power supply. I am simply amazed that VOIP has spread as quickly as it has. I mean, who the hell expects their internet service to stay up 24/7?
If you get VOIP service, you have to know that the low price comes with lower reliability and few if any of the traditional safeguards of wired or even cellular phones.
No dail-up means that it wouldnt work very well for users just wanting an internet connection over 56k.
With no applications but IE and some office viewers?
Terminal Server over 56k wouldn't be much fun but it should be possible, and I've done X11 over links as slow as 1200 (old athena widget apps like xman and xterm only, mind you).
I could see using a Windows box like this as thin client for a UNIX server running X11, because X11 uses the user's computer for the actual drawing... it doesn't maintain and render a local copy of the screen, it just sends drawing commands to the client. A Windows Terminal Server doesn't do this, every session has to maintain its own *unaccelerated* screen image, locally, and send bitmaps containing changed areas. Much higher load on the server, so if you have a room with 10 low end PCs in it, buying a server that could support 10 concurrent terminal server sessions would set you back WAY more than 10 new PCs.
We ran into this. When we got our first WinDD servers (Tektronix' version of the Citrix software that became Windows Terminal Server) I sized them based on our experience with UNIX servers... and thought doubling the per-user RAM and CPU was pretty conservative. Boy was that a shock... and the requirements have only gone UP since then.
I've tried running Win2k on my PentiumII 350 w/128MB RAM, pretty damn slow
Depends on what you expect it to do. If the application you're running on it requires more oomph than your PII350 can deliver, it doesn't matter what the OS is.
I've got a NeXTstation here, with 16M RAM and a 68030 at 30 MHz. The OS is amazingly fast and responsive... better than Mac OS on the similarly equipped Performa 475 (and it did a lot more), but the processor is too slow to decode and play an MP3 file in real time or render any but the simplest web pages at anything like acceptable speed. I wouldn't say "NeXTSTeP is too slow", I'd say "these applications need a faster computer".
I find it hard to believe that Microsoft can strip Windows XP down to the point where it runs comfortably on that platform. We have stacks of x86-based Multias here, and even running NT4 they needed at least 32M to be usable.
Windows 2000 runs fine on a Pentium-133 with 64M, though. So does FreeBSD using Windowmaker as the window manager. I'm sure they could strip XP down to that point, since XP isn't much more than 2000 with an uglier color scheme.
This makes sense for sites that care more about consistenty mapping a user to an ID, but don't really care who the user is
Since sites like that have a real problem with identifying people so they can sanction spammers without making it too hard for regular joes to participate, this is a valuable tool. If it can be used more widely that's a bonus... and you have already suggested one way it COULD be used more widely:
sites that perform any type of regulated or high-risk activity will have the responsibility of identifying their own users or federating with other entities that they trust backed with legal/liability agreements.
So right now $33B is 1/3 of total "potential sales" of $100M, and total sales of $67B.
As a result of the Internet, over 5 years they expect to see "potential sales" of $300B (if $200B is 2/3), and actual sales of $100B... even assuming their worst case estimate (could boom to 2/3) of piracy levels are accurate. So, the worst case is a 50% increase in the market over 5 years.
This doesn't seem to me to be a problem. I'm certainly not expecting to get that kind of a raise over the next few years.
Oh, I'm far beyond that now. I have even started to post angry rebuttals to my own messages pointing out minor typos, so that those with lesser slash-fu don't have to waste their Qi on such trivia.
Yeh, I hate how Microsoft just decided to grab 192.168.55.100 for the IP address for the Activesync connection, instead of using link-local addresses (a concept, I might add, that they invented). But I really like how it actually uses MAPI properly so I could Activesync mail through Netscape Communicator so I didn't have to use Outlook (AKA the "Typhoid Mary" of mail software).
You and I can both tell the difference between a 'do shell script' and running a plugin and is this: It's trivial to open up the bundle and looking at the script for system calls (plain text and all) vs. trying to determine what a widget or web plugin does before running it (arguments of decompiling, etc aside).
It's REALLY AMAZING how close the kind of Javascript that some virus writers write is to binary. Really. I've seen whole applications encrypted and wrapped up with an obfuscated decryption routine that feeds it finally to a disguised eval. Heck, I've written code with similar goals and attributes in Postscript for the Obfuscated Postscript Programming Contest.
From a security point of view, any privilege that can be used to get the effect of any other privilege has to be treated as the same privilege, and the two should not be distinguished as separate "rights".
Windows 32bit (NT in fact since 1993) has supported a 17 terabyte partion address space.
You still can't map more than a couple of gigabytes of the file into your program's address space at a time.
Only the OS changed for the performance increase.
Um, going from x86 emulation to native x86-64 code does require OS support, yes, but that doesn't mean the performance increase is due to a change in the OS. In fact, it's due to a change in the chip. Switching from Windows-32 to Windows-64 on an Opteron means you're switching from the Opteron's legacy x86-support to its native instruction set. That's as big a change as swapping out the CPU.
It would be nice for the developers to be able to have an application that didn't have to perform a bit of 'magic' to run the 64bit code.
I don't see where there's any magic involved. Most existing large-address-space applications are written for UNIX and run under the command line or, occasionally, using X11. And they'll work just fine under OS X.
64bit platforms are the NEXT generation in both SPEED and ADDRESS SPACE that will be needed for the next generation of applications.
64 bit platforms are not the "next generation" in anything. They've been "this generation" since 1994. I had a 64-bit desktop before even Mac OS 9 and Windows 98 were "this generation".
And unless address space is an issue, "64 bit platforms" are no faster than "32 bit platforms", all other things being equal.
If 64bits is in fact 'often slower' as one person quoted, then why are the GPUs on EVERY high speed video card now running with 64,128 and higher bits to 'get the performance' that was NOT possible on 32bit GPUs.
Because they're doing 64-bit integer operations, but Windows 64-bit model uses 32-bit integer operations, so there's no performance advantage to 64-bit code just from the 64-bit instruction set... you have to redesign your application to operate on 64-bit integers to get that. And doing a "simple search and replace" doesn't cut it... if your code is really pushing the limits of performance it's got all kinds of word-size dependencies all the way down to hardcoded bitmasks.
We've been doing this kind of thing on the Alpha longer than Windows NT has been a product.
Most windows applications port to the 64bit version with little more than a simple recompile
Any Windows application that ports with a simple recompile is not a 64-bit application. It's like an application compiled with "-taso" on the Alpha under Tru64, and we call those "32-bit applications". Yes, you will get a performance boost from using the improved instruction set in 64-bit mode, but that's not because you're using 64-bit pointers, it's because the IA32 instruction set is really really hard to make go fast. Every Power PC out there, all the way back to the 601 in the original Powermac 7100, is already using an instruction set that's at least as good.
you assert this is because of the need for 64bit applications to reference 32bit DLLs/libraries.
If a library is using 32-bit integers internally, which is what the Windows-64 API specifies, it's like a library compiled with "-taso" in Tru64. Again, on the Alpha we call those "32-bit" libraries.
are you splitting hairs of comparing RDP to the X-Windows Protocol?
No, RDP is not part of the Windows GUI, it runs on top of it and does "screen scraping" to transfer bitmaps back and forth. I'm talking about the design of the GUI itself.
The Windows GUI is not a client-server protocol, it's a library based design that involves very tight coupling between GDI and the application, with callbacks to the application happening synchronously with display updates. This (as I already made mention of when I talked about games on Linux using SDL in a way that bypasses X11) gives it much higher performance than X11, but it means that you have a much closer relationship between the applications and the GUI.
There IS a reason why OSX's Quartz does NOT sit on top of XWindows
Um, yeh, I also already mentioned that 64-bit applications can't use Quartz directly. That's because Quartz is a toolkit-based system that's more Windows-like. So, obviously I already know this. The point is, though, that 64-bit applications that people are already using are not Windows-based, in general. They're UNIX-based, and use X11 and OpenGL... both of which already use client-server user interface designs. So they're MUCH easier to port to OS X.
The only applications that are easier to port to 64-bit Windows are applications that will need to be rewritten
OK, it's cute to fit it inside the case, but if you could get a UPS that'd stack under the Mini with a compatible power connector you could get almost all the convenience (and, let's face it, "mini chic") with a lot less complexity.
They'd probably need to coordinate with Apple on the power, but it'd make the standby a lot more efficient than if they did the usual DC->AC->DC thing, and they already do DC UPSes for racks.
Slashdot Mirror
"Is it wrong?" I concluded. "Well, student's, that's a moral decision you'll have to make on your own..."
Unless you have the artist's permission, I think it's clear that it's wrong. The fact that the music industry is engaged in a greater wrong is not even that much of a mitigating factor. It's up to the artist to choose to involve themselves in civil disobedience against the label system, to accept the consequences of sharing their songs on P2P, whether good or bad. It's not up to you to make that decision for them.
It's like software piracy. There is no doubt that some companies have benefited tremendously from secondary effects of having their software widely pirated. Microsoft is a perfect example... piracy of Office has been a big part of what destroyed the market for office suites that might compete against Office on the basis of price. It's hard to even give them away now, and there's no doubt that without that piracy Office would have a lower market share. But that doesn't justify trading copies of Office, it would be Microsoft's responsibility to allow additional people to use your copy of Office. If anything, it makes pirating Office even more reprehensible, given what the long term results have been.
Similarly, trading music that artists have chosen not to share has reduced the value of independant artists, to the point that it's hard for them to get attention even by giving their music (some of which is tremendously good) away. If you don't like the label system, it's far more moral and effective to promote sites like 3hive that hilight independant artists, many of whom are more than happy to let you download complete songs (not just 30 second samples) if there's a chance that'll convince you to buy their CDs. And, heck, it even works.
It'd work better if epople would quit thinking they need the latest music by some label artist, and take a flyer on someone they've never heard of, and pass the samples around if they like them. They don't even need P2P to do it, they can just email a URL... and it's completely legal AND moral and does a MUCH better job of disempowering the RIAA and the label system.
And, freedom of speech is not synonymous with "freedom from consequences."
Well, um, actually, it is. It is a very specific subset of the possible consequences that the US "Freedom of Speech" guarantees, but it does guarantee that. The whole point to "civil disobedience" is that one is free to engage in a variety of actions for which one consequence IS arrest, if one is willing to accept that consequence. The people who wrote the First Amendment had engaged in civil disobedience, and some had died for it, for as little as speaking out, accepting the consequences of their actions.
So don't for one minute think that they imagined that Freedom of Speech meant anything less than the freedom to speak out without the risk of consequences... because they absolutely knew that they already had the freedom to speak if they were willing to accept those consequences.
That's why the term "chilling effect" is used. Laws that not only prohibit speech but that might have the effect of discouraging speech are not permitted by the first amendment, and using non-judicial punishment and non-governmental organizations as a cutout shoudn't be considered any less an egregious violation of the constitution than directly passing a law banning speech.
You might be called a traitor for speaking out against the war, but you will not be prosecuted as one.
You might be fired from your job, denied permits and licenses, and be harassed short of prosecution, and otherwise persecuted for it. No, you can't be prosecuted, but so long as the non-judicial punishment is under the radar that's just fne.
I guess I just don't know exactly how the licensing works.
There are very few open source projects that limit commercial redistribution of the software. Oh, there's a broad range of licenses, from the "you can do it as long as you don't sue us if it breaks" modified BSD license, through to "you can do it as long as you make the result open source" GPL, but products like the dual-licensed Ghostscript or the no-commercial-use Kermit have become fairly rare.
That's a pretty important thing to understand about Open Source. Even a lot of Open Source developers don't "get" it, and ask the CSRG folks why they hadn't sued Microsoft for using BSD code in Windows NT... and are utterly befuddled when the response is "they did exactly what they're supposed to do".
If they are openly admiting that their code is nearly an exact duplicate of Firefox, it might limit them in the future.
Actually, hiding the use of Open Source has often turned out to be a bigger problem for companies. That's how USL/USG ended up having to settle with CSRG over the BSD-Lite software releases, and that's why CherryOS imploded.
it seems like it'd be a lot easier just to switch rendering engines when you hit a bad page than to copy the link, open another application, paste the link into it, etc.
It seems like it would have been a lot easier to add an "open in internet explorer" menu/contextual menu/accelerator key, and a lot less likely to lead to people getting confused about whether they're in a "safe" (relatively) browser or not.
The big deal with Netscape 8 is that it offers the choice of using the IE or Firefox/Gecko rendering engine on different pages.
The fundamental security flaws that are inherent in the Microsoft HTML Control can't be fixed by a wrapper, because they're in the HTML control itself, not the IE "shell". So you're no safer using the "IE Engine" inside Netscape than just using IE.
So this is no different than just using IE for the pages that need IE, except that people who think they're being safer using Netscape instead of IE are likely to let their guard down when using this feature.
First, why isn't Firefox going after Netscape
You don't get the whole "Open Source" thing, do you?
What web browser are you running on that NeXT?
I don't recall which one I finally got to work, lo these many years ago, I just remember how sluggish it was. It's really more of an office conversation piece these days.
Generally, on a Mac, you only get a dialog if there is an immediate need for user input.
... paved with good intentions" that Microsoft pranced boldly down in the '90s.
That used to be true. And generally on the Mac you didn't get supposedly sandboxed environments doing dangerous things, either. These used to be among the reasons Mac OS X was inherently resistant to the kind of scattershot exploits that Windows was famous for.
Now Apple is starting to change both of these things, in a kind of codependent hobble down the same "road
Which is where we came in, no?
But shouldn't VOIP users if they are technically savvy to use VOIP also be responsible and be sure that they can dial (ie have phone number handy) an emergency service?
I'm sorry, but I can't parse that sentence. No matter how I try, it seems to be saying something about users being technically savvy. I know that can't be right, so there MUST be something wrong with the way I'm reading it.
"Not yet, Joe Consumer. You want to keep your land line in case of an emergency!"
Hell yes. Or at least a cellphone. I could see getting VOIP as a second or third line but I wouldn't dream of getting it as my only phone service.
Even if they DID provide 911 I sure wouldn't want to depend on my ISP to be able to call anyone, let alone emergency services. For a while my honme Internet service would go down on Fridays regular as clockwork. No thanks, a VOIP-only house isn't in my plans.
It's not possible for VOIP to provide the service guarantees of wired phone lines, if nothing else because they don't come with a dedicated pair of wires going back to an exchange with its own power supply. I am simply amazed that VOIP has spread as quickly as it has. I mean, who the hell expects their internet service to stay up 24/7?
If you get VOIP service, you have to know that the low price comes with lower reliability and few if any of the traditional safeguards of wired or even cellular phones.
No dail-up means that it wouldnt work very well for users just wanting an internet connection over 56k.
With no applications but IE and some office viewers?
Terminal Server over 56k wouldn't be much fun but it should be possible, and I've done X11 over links as slow as 1200 (old athena widget apps like xman and xterm only, mind you).
So don't think to use this to turn old laptops into portable terminals, according to this spec:
Windows XP "Eiger":
[...]
Not supported
Windows image acquisition (WIA)
Telephony, VPN & Dial-up
Wireless networking (802.11)
I could see using a Windows box like this as thin client for a UNIX server running X11, because X11 uses the user's computer for the actual drawing... it doesn't maintain and render a local copy of the screen, it just sends drawing commands to the client. A Windows Terminal Server doesn't do this, every session has to maintain its own *unaccelerated* screen image, locally, and send bitmaps containing changed areas. Much higher load on the server, so if you have a room with 10 low end PCs in it, buying a server that could support 10 concurrent terminal server sessions would set you back WAY more than 10 new PCs.
We ran into this. When we got our first WinDD servers (Tektronix' version of the Citrix software that became Windows Terminal Server) I sized them based on our experience with UNIX servers... and thought doubling the per-user RAM and CPU was pretty conservative. Boy was that a shock... and the requirements have only gone UP since then.
I've tried running Win2k on my PentiumII 350 w/128MB RAM, pretty damn slow
Depends on what you expect it to do. If the application you're running on it requires more oomph than your PII350 can deliver, it doesn't matter what the OS is.
I've got a NeXTstation here, with 16M RAM and a 68030 at 30 MHz. The OS is amazingly fast and responsive... better than Mac OS on the similarly equipped Performa 475 (and it did a lot more), but the processor is too slow to decode and play an MP3 file in real time or render any but the simplest web pages at anything like acceptable speed. I wouldn't say "NeXTSTeP is too slow", I'd say "these applications need a faster computer".
I mean a 100MHz pentium here with 16M of RAM.
I find it hard to believe that Microsoft can strip Windows XP down to the point where it runs comfortably on that platform. We have stacks of x86-based Multias here, and even running NT4 they needed at least 32M to be usable.
Windows 2000 runs fine on a Pentium-133 with 64M, though. So does FreeBSD using Windowmaker as the window manager. I'm sure they could strip XP down to that point, since XP isn't much more than 2000 with an uglier color scheme.
This makes sense for sites that care more about consistenty mapping a user to an ID, but don't really care who the user is
Since sites like that have a real problem with identifying people so they can sanction spammers without making it too hard for regular joes to participate, this is a valuable tool. If it can be used more widely that's a bonus... and you have already suggested one way it COULD be used more widely:
sites that perform any type of regulated or high-risk activity will have the responsibility of identifying their own users or federating with other entities that they trust backed with legal/liability agreements.
Let's grant them their figures.
So right now $33B is 1/3 of total "potential sales" of $100M, and total sales of $67B.
As a result of the Internet, over 5 years they expect to see "potential sales" of $300B (if $200B is 2/3), and actual sales of $100B... even assuming their worst case estimate (could boom to 2/3) of piracy levels are accurate. So, the worst case is a 50% increase in the market over 5 years.
This doesn't seem to me to be a problem. I'm certainly not expecting to get that kind of a raise over the next few years.
i anxiously await your first triple post!
Oh, I'm far beyond that now. I have even started to post angry rebuttals to my own messages pointing out minor typos, so that those with lesser slash-fu don't have to waste their Qi on such trivia.
Have you ever used MS Activesync?
Yeh, I hate how Microsoft just decided to grab 192.168.55.100 for the IP address for the Activesync connection, instead of using link-local addresses (a concept, I might add, that they invented). But I really like how it actually uses MAPI properly so I could Activesync mail through Netscape Communicator so I didn't have to use Outlook (AKA the "Typhoid Mary" of mail software).
You and I can both tell the difference between a 'do shell script' and running a plugin and is this: It's trivial to open up the bundle and looking at the script for system calls (plain text and all) vs. trying to determine what a widget or web plugin does before running it (arguments of decompiling, etc aside).
It's REALLY AMAZING how close the kind of Javascript that some virus writers write is to binary. Really. I've seen whole applications encrypted and wrapped up with an obfuscated decryption routine that feeds it finally to a disguised eval. Heck, I've written code with similar goals and attributes in Postscript for the Obfuscated Postscript Programming Contest.
From a security point of view, any privilege that can be used to get the effect of any other privilege has to be treated as the same privilege, and the two should not be distinguished as separate "rights".
Windows 32bit (NT in fact since 1993) has supported a 17 terabyte partion address space.
You still can't map more than a couple of gigabytes of the file into your program's address space at a time.
Only the OS changed for the performance increase.
Um, going from x86 emulation to native x86-64 code does require OS support, yes, but that doesn't mean the performance increase is due to a change in the OS. In fact, it's due to a change in the chip. Switching from Windows-32 to Windows-64 on an Opteron means you're switching from the Opteron's legacy x86-support to its native instruction set. That's as big a change as swapping out the CPU.
It would be nice for the developers to be able to have an application that didn't have to perform a bit of 'magic' to run the 64bit code.
I don't see where there's any magic involved. Most existing large-address-space applications are written for UNIX and run under the command line or, occasionally, using X11. And they'll work just fine under OS X.
64bit platforms are the NEXT generation in both SPEED and ADDRESS SPACE that will be needed for the next generation of applications.
64 bit platforms are not the "next generation" in anything. They've been "this generation" since 1994. I had a 64-bit desktop before even Mac OS 9 and Windows 98 were "this generation".
And unless address space is an issue, "64 bit platforms" are no faster than "32 bit platforms", all other things being equal.
If 64bits is in fact 'often slower' as one person quoted, then why are the GPUs on EVERY high speed video card now running with 64,128 and higher bits to 'get the performance' that was NOT possible on 32bit GPUs.
Because they're doing 64-bit integer operations, but Windows 64-bit model uses 32-bit integer operations, so there's no performance advantage to 64-bit code just from the 64-bit instruction set... you have to redesign your application to operate on 64-bit integers to get that. And doing a "simple search and replace" doesn't cut it... if your code is really pushing the limits of performance it's got all kinds of word-size dependencies all the way down to hardcoded bitmasks.
We've been doing this kind of thing on the Alpha longer than Windows NT has been a product.
Most windows applications port to the 64bit version with little more than a simple recompile
Any Windows application that ports with a simple recompile is not a 64-bit application. It's like an application compiled with "-taso" on the Alpha under Tru64, and we call those "32-bit applications". Yes, you will get a performance boost from using the improved instruction set in 64-bit mode, but that's not because you're using 64-bit pointers, it's because the IA32 instruction set is really really hard to make go fast. Every Power PC out there, all the way back to the 601 in the original Powermac 7100, is already using an instruction set that's at least as good.
you assert this is because of the need for 64bit applications to reference 32bit DLLs/libraries.
If a library is using 32-bit integers internally, which is what the Windows-64 API specifies, it's like a library compiled with "-taso" in Tru64. Again, on the Alpha we call those "32-bit" libraries.
are you splitting hairs of comparing RDP to the X-Windows Protocol?
No, RDP is not part of the Windows GUI, it runs on top of it and does "screen scraping" to transfer bitmaps back and forth. I'm talking about the design of the GUI itself.
The Windows GUI is not a client-server protocol, it's a library based design that involves very tight coupling between GDI and the application, with callbacks to the application happening synchronously with display updates. This (as I already made mention of when I talked about games on Linux using SDL in a way that bypasses X11) gives it much higher performance than X11, but it means that you have a much closer relationship between the applications and the GUI.
There IS a reason why OSX's Quartz does NOT sit on top of XWindows
Um, yeh, I also already mentioned that 64-bit applications can't use Quartz directly. That's because Quartz is a toolkit-based system that's more Windows-like. So, obviously I already know this. The point is, though, that 64-bit applications that people are already using are not Windows-based, in general. They're UNIX-based, and use X11 and OpenGL... both of which already use client-server user interface designs. So they're MUCH easier to port to OS X.
The only applications that are easier to port to 64-bit Windows are applications that will need to be rewritten
OK, it's cute to fit it inside the case, but if you could get a UPS that'd stack under the Mini with a compatible power connector you could get almost all the convenience (and, let's face it, "mini chic") with a lot less complexity.
They'd probably need to coordinate with Apple on the power, but it'd make the standby a lot more efficient than if they did the usual DC->AC->DC thing, and they already do DC UPSes for racks.