Do you know how many players the game has? I doubt Blizzard could keep up if they had to have technical people individually verify and respond to every cheating case.
What you're proposing is like a judicial system for a company. That's not likely to happen. Judicial systems take a lot of people and a lot of work. They even require "volunteer" (ish) labor for juries. They're expensive. Governments have them because in real life justice is worth the cost. To Blizzard, it's only worth the cost if it gets enough additional people buying the game to cover the costs. And I really doubt that would happen.
I guess the moral of the story is, "Never expect justice from a for-profit corporation."
Actually if you link some of the more pesky libraries statically and don't use any kernel functionality that's too new you can get very wide binary compatibility. This is more or less how things work on Windows and Mac, right? You certainly can't claim that GNU/Linux systems have the kind of backwards (or sideways, for that matter) compatibility that Windows does, but it's possible to make statically-linked binaries that run across a wide range of kernels.
I don't know if this is worthy of man-love, but it is one way to do it.
That's one way to look at things. Inalienable rights. It is cool that so many of you dudes know your important documents.
Another way to look at it is that at this time (and even at the time of the Declaration of Independence) government is a foregone conclusion; given a large enough group of people that is not governed, they will tend to either form some kind of government or be conquored. And government, not otherwise limited, can do basically anything that it's physically able to enforce. When a government consciously limits itself (in true action, not just on paper, as you surely know of at least some of the freedoms guaranteed by the constitutions of many corrupt regimes) it defines the people's rights under that government (though other social organizations may take away some rights in their own way).
Rights aren't inalienable just because Thomas Jefferson said they are. Ask fifty people that have never read the Declaration of Independence what their inalienable rights are and you could get fifty different answers. The dudes that wrote the Declaration probably argued about the rights they'd claim as inalienable, and some probably walked away from that debate unhappy. Inalienable rights makes a great battle call. But we're not going into battle today. We'd be better off if, instead of taking Jefferson as gospel, we looked at the rights that he's talked about and affirmed first that we as a society do indeed value those rights, and second the reasons that we value them. And then look at all the other rights that we value and protect today, as well.
O'Reilly wasn't talking about any particular kind of technology. He was talking about the way people use and rely on the technology.
Now there's plenty of other technology he relies upon that fuddy-duddies 30 years older than him probably scoff at. But the point I'm making is that it's not a question of how advanced the technology is, it's a question of what it does and how it's used, for and by people.
XMPP (Jabber) allows for that. The messages are delivered next time you log in. I don't know whether all servers are required to implement that feature... whatever. Jabber actually looks kind of like email in terms of namespace and in the open exchange of messages between servers.
Jabber is clearly an IM protocol and not email based on its other features, its typical model of use, the UIs of most of its clients, etc. You can't just take one feature and claim that it's the distinction between IM and email. That one feature might make Jabber more email-like than other IM systems. But it wouldn't make it email.
There are many differences between email and IM. Tying this back to the real topic at hand, I don't think that any of those differences are relavent in this case.
People haven't "always" been able to carry a music collection with them to listen to, say, while walking down the street. At least, they haven't always been able to do it very easily. They gained this ability with walkman-like devices a few decades ago. This might seem like "always" to you, but O'Reilly is probably a lot older than you are. In fact, recorded music isn't really all that old itself. One might argue that recorded music has diminished the significance of live music performance; after all, how often do you hear a piece of music performed for the first time live? At the same time, it's also lowered the threshold for enjoying music in terms of cost, social class and location (you don't have to live near Chicago to hear the CSO, and if your favorite band won't come to your town you can still buy their CD). And the iPod, after all, is just another way for people to pipe recorded music into their heads, sans-performer. It's just an improved phonograph.
Maybe it never registered with O'Reilly that an iPod is an improved Walkman. I'd say it probably did, because to a non-user of such devices they all look the same: a set of headphones connected into a little piece of plastic. The connection would be hard to miss. But iPods and other modern portables have done something distinctive (that is, in addition to their technical distinctions such as increased storage space, ease of putting together custom playlists, and the single-oriented online music stores): they've made portable music popular to the point of ubiquity among young people. And they have, more than any previous portable player, become a status symbol among the young hip crowd. People have been able to walk down the street, disengaged from their immediate reality, with headphones in, for several years now. But the coming of the iPod has made it not only much more common, but also made it the cool thing to do.
No, no, no, no, no. That's completely ridiculous. Even within the ntfs-3g website they list some cases where Microsoft's chkdsk reports bogus errors, and say, "This is a bug in chkdsk and we're not fixing it." You write a filesystem driver to perform to the specification (even if you have to reverse-engineer the specification first). If you figure out the specification by looking only at one particular implementation of it, any place that you deviate from that implementation at all you risk being incompatible with future implementations. On the other hand, if there's a clear specification within which all implementations operate this is less of a risk.
Have you ever heard of people writing software, particularly drivers, and then with a change in the operating system or some libraries the software stops working? Even if the API wasn't supposed to change? It often happens that there was some incorrect assumption made that happened not to matter with the old implementation and does matter with the new one. The assumption was always incorrect. If you want software to age gracefully you don't just code to the binary status quo, you code to the spec.
It looks like the ntfs-3g dudes have done a fine job with the information they have. But I'm sure they'd find the real specification very useful if it was legally made available to them.
Just because the sum of all NTFS data sitting on people's Windows boxes is more data than a technical specification doesn't mean it's more complete and correct than a good technical specification.
You won't be able to carry the "Genuine" data (in the Microsoftian sense) around on your flash stick. Or, perhaps you will, but you won't be able to play it anywhere but your own computer. Most of the files we get from mainstream media (such as TV series) will be encrypted with DRM. Unless they start selling us special flash sticks that somehow implement copy protection, perhaps by an HDCP-like scheme (whereby the drive will refuse to give up its data without the entire playback stack authenticating with it).
It's an impressive technical acheivement, sure, but does it actually make the operating system better?
Some people would argue that insisting on backwards compatibility is the cause of many of the problems involved with practical Windows usage today. One of the major examples of this is how inconvenient it is to run as a non-admin class user. If Microsoft had laid down the law in NT from the beginning and made it very abnormal to run with admin powers day-to-day some (not all) of the security problems would not be an issue today. Even in Vista today lots of people still want to run with full powers. If Apple can break compatibility as often as they do and get away with it Microsoft can, too. People will rewrite useful and necessary programs, and make them better. A foolish consistency is the hobgoblin of little minds (Emerson)! Unixes generally have a tradition of source compatibility rather than binary compatibility, which has its own problems; insert Plan 9 rallying cry here.
Certainly most of Windows' security problems, especially recently, come from it being the majority computing platform among the human race, a notoriously easy-to-exploit class of security vulnerabilities. But all their work towards binary compatibility certainly hasn't helped.
He can sell the physical CDs, sure. He can't copy the contents and distribute those copies because that's a violation of copyright law. I think the latter is what OP was getting at.
I don't see anything necessarily wrong with this in principle; the consoles are a commodity that is sold for less than it's worth, people can and do buy 'em and sell 'em for a profit. And anyone that desperately wants the console to play games will shell out the dough, because they're suckers. And people that can't afford that are probably better off anyway, because they shouldn't need overpriced crap to make them happy. Mod me redundant, because I'm sure I'm repeating myself here.
What surprises me is that businessmen are getting into it. Even though they can probably quickly double or triple their investment selling the PS3s, there's a limited supply and lots of competition to get the units. Even if they make $1000 per unit they're spending a considerable amount of time to turn over a limited number of units. It seems to me they could make more money in the same amount of time trading stocks/bonds/commodities because the process is more streamlined and the volumes are higher. So for some kid looking for quick money it would surely be a good investment, I'm just surprised that it's worth the time of rich dudes.
Even if there's a drive that plays all (which as my elder sibling points out hasn't really happened yet), I think that only one of the two formats will win in the end. I don't think there's room on store shelves for two the-same-but-different copies of every movie. The Internet, where shelf space isn't a problem, will lessen that , but if one of the two formats gets critical mass the other will be marginalized. Controlling the format is not a means to the end of making The Big Bucks (tm) by selling hardware; Sony made plenty of money selling VHS players post-Beta failure. Controlling the format is an end of its own, with potentially even Bigger Bucks (tm) to be made.
As a freshman in college I was called by someone through a relay operator to try to get me to join some kind of "secret society". Or it was probably just a silly prank either by one of my friends or some older folk in ECE. But I never heard of anyone else getting the call, and none of my friends ever admitted to doing it. Which is odd, for sure.
I hung up after a while, and they called back, this repeated a few times. Then my (drunk) roommate picked up the phone and started hitting on the operator. I felt bad for the operator, if she was really an operator, but it was still hilarious. It was especially funny to imagine because this woman had the most cold, strange, monotone voice I'd ever heard.
Being a relay operator would be a hell of a job. I should try doing it for a while.
Well, look on the bright side: unless your VM has a bug in it there's nothing they can do to stop you, and the EULA may well be invalid anyway. The former, of course, will be wiped out by TPC. The latter, I've heard, is at risk because of laws in some US states that validate EULAs.
For things like BlueRay that use HDCP you need real video/audio hardware anyway. And I always thought VMs weren't that good for media anyway. What with their typical timing issues, lack of direct hardware access, high latency...
It's unreasonable because virtual machines are designed to simulate computers exactly. If they can't run Windows DRM it would be a bug in the VM.
Best guess I have is the reason they don't want people doing it is that it would allow people to hack the DRM more easily. And it would. You can trace the execution of a program and directly read out memory contents very easily using a virtual machine or debugger. I've heard Vista won't allow the use of debuggers on DRM-related programs, but if you're running in a virtual machine they can't stop you from looking at memory and register state. With a virtual machine you could in theory, for example, have virtual video and sound hardware that would allow you to crack HDCP. You could step through Windows DRM code instruction-by-instruction to figure out where they keep decryption keys for their music files. This isn't exactly easy, and I'm sure they put lots of hurdles in your way, but a determined and smart hacker could probably figure it out.
At least until TPC is turned against us. Once that happens the ability of a virtual machine to fake-out an OS is constrained.
A knoppix CD has good hardware detection and lots of drivers installed for the devices it supports. I'm sure it gets most of the common ones, but I'm just as sure there's a lot it misses. Knoppix can't legally distribute Nvidia's or ATI's drivers, for example, so the game companies would have to work out a deal for them. There are also devices that might come out in the future. The user, in the general case, would have to burn their own game CD upon installation to get all their drivers. Users would balk at this because it's complicated and time-consuming, game companies would balk because it would complicate copy-protection. And what about the program that aggregates the drivers for the LiveCD? Where does it run? On the normal OS? So you're right back to square one.
I still think the vulnerability issue is a problem. A vulnerability in Linux firewall code or in the services run by the game could leave the system open. To patch it you'd need to burn the CD over again (which takes two reboots). Think about the user experience for this: user reboots, sticks in CD for Game OS. Game OS says, "I need updates!" User reboots back to normal OS, runs update utility, burns CD, reboots onto new CD, plays game. Three reboots vs. the current status-quo, which is "wait a few minutes for patch to download, then go on playing".
The diversity of PC and Mactel systems is just too much; PC operating systems have spent a lot of effort providing an abstraction between hardware and software, and to replace the OS the user already has working with a new one that has to support all that diversity would be a nightmare. None of the problems I listed have been solved well enough for a game designed to work this way to work nearly as well a game distributed just as a single-platform binary for the user's existing OS. It's not just that it's not the best idea. It's that it's a complete waste of time trying to turn PCs into consoles.
People buy things and sell them for more money all the time. It's called a market economy. They're not doing it on a "free ride", they had to have either the foresight to pre-order or the patience to wait out in front of the store before opening time. They also had to somehow obtain the money to buy it in the first place. That's how you make investments.
In the sense that console resellers are getting a "free ride" all investors get a "free ride". It's just how the economy goes. Some people trade stocks, some people trade commodities and some people that are in for small potatoes trade consoles.
Along those lines they say that in Canada they hand-count ballots. But they don't have nearly as many items to vote on in each election in Canada. The voter guide I got here in California is a frickin' tome.
By "sharpies" do you mean permanent markers? How reliable are the scanning machines?
Sometimes it's actually easier to make a clean break than to modify an existing codebase. Sometimes an existing design is tied to assumptions and that you don't want to make, design decisions that you want to make differently. And for people that are familiar with coding KDE programs writing a pure KDE app will be easier, and they'll produce better code that integrates better with KDE.
I'm not familiar with this case specifically, but these could be among the reasons that they chose to write their own.
I'm sure most of the developers have used the GIMP and are familiar with its strengths and weaknesses, and many of them have probably looked at GIMP code and perhaps borrowed ideas from it.
I know this is just a silly mod-parent-up post, but parent is dead right. It would be cheaper, more reliable and more intuitive than touchscreens because touchscreens lack tactile feedback. It also means that you don't have your display screen getting smudged.
The tactile feedback thing is important. I operate ATMs much more quickly and confidently when the buttons have a nice keyboard-like "click" feeling to them. The ones with those cheap non-reliefed buttons that barely push in suck, and often make loud beeping noises to compensate for the poor tactile feedback. Touchscreens are the worst; during the delay before the action happens there's always a moment of unsureness.
You'd just have to make sure to build it right, of course. Definitely an LCD flat panel, and make sure it's not set back from the plane of the buttons, or else risk a butterfly-ballot style problem, where the user's position relative to the machine could affect the way the choices line up (that can be a problem with ATMs, both of the touchscreen and non-touchscreen variety, because they have cheap, tiny CRT screens that are set back from the buttons/touch sensors). And probably some other design considerations for legibility; I personally don't think it's too much to ask to have voters read a number next to a candidate's name and push the button corresponding with that number (numbers not directly on the buttons where they could wear off), but some people would probably complain. And you'd still have to test the machines for sticky, non-debounced or simply broken buttons. Nothing that an arcade manager couldn't handle.
Re:So where does all of this leave Linux gamers?
on
Why Gaming Sucks On Linux
·
· Score: 3, Insightful
We see this type of comment all the time. A few problems:
1. Drivers. You have to include drivers for all the hardware that your game needs (graphics, sound, network, input devices), including future devices in these categories. I've heard some interesting ideas for ways around this. They're interesting, but lead to a complicated and lengthy install process. You need to get your OS to boot on everyone's crazy hardware configurations.
2. Networking and patching. If you're making a network enabled game you're asking people to put their computers on a network (likely even the Internet) with an OS that can't be updated without spinning another DVD. There will be security holes found in the OS. Lots of people running the exact same unpatched OS version will be playing these games. Just because the OS installation on the CD/DVD can't be modified, it leaves open an attack vector to data on the hard drive. Game manufacturers like the ability to easily patch their games for bugs, anti-hacking techniques, and other random things. Argue all you want that they should get it right the first time, they wouldn't want to give that up.
3. Rebooting. People don't like rebooting. It takes a long time. They have to disconnect from IM programs, they have to turn off their music players, etc. They lose their software stack and configuration info (think configurable input devices that require userland apps for configuration). Configuration that would be shared between multiple games must be redone for every game you buy. It's more difficult for people to minimize the game and post the video of their latest frag to their website.
4. Licensing. What OS would game developers use for this? Windows or some similar variant. The driver support and developer tools are there for Windows, and most PCs sold today have undergone QA on Windows. Paying the licensing costs would drive up the price of the game.
And what is gained? The day-to-day experience (that is, the experience outside of patching and installation) for Linux/Mac users would be the same as now: a reboot into an OS they use mostly for gaming; in fact, since a real Windows installation would be more useful than the game OS the experience would really be slightly worse. The day-to-day experience for Windows users would be much worse: two reboots to go from regular use to game and back. Reboots between different games.
He's right and it is applicable here. I R'd TFA and it said that the Windows mixer component is used to instruct the sound card to loop output back to input. I did that once on my computer as an attempt to get a sample of a MIDI file. You don't have to be an audiophile (I'm not) to hear that the quality of playback is much worse than the original playback of the MIDI file. It would be exactly the same if the program manipulated audio streams like JACK. You can, in fact, hear noise in the recordings corresponding to activity on other parts of the motherboard (I have an onboard sound card, and a poor one at that).
Linux apps that can use JACK need to be written to support JACK's API. I think JACK has a kernel component as well, but I may be wrong. At any rate, the most straightforward way I can think of for a program to simply store a *digital* stream from any program directly to a file would be to write a "fake" audio driver that writes to disk. For programs with output plugin support (Winamp and similar programs come to mind) you could create a "disk writer" plugin (and this has been done), but in the general case you'd have to write a general audio driver (I'm pretty sure that's been done as well).
If some level of DRM decoding is done at the OS (including kernel or libraries) or hardware level, and if the OS does not allow unsigned drivers, this approach is thwarted.
Wikipedia says that Diffie and Hellman published their work in 1976, and that the earlier secret work was going on in the early 70s. So it looks like they're talking about the public discovery, assuming both that Wikipedia is correct and that I can add small numbers in my head accurately.
Slashdot Mirror
Do you know how many players the game has? I doubt Blizzard could keep up if they had to have technical people individually verify and respond to every cheating case.
What you're proposing is like a judicial system for a company. That's not likely to happen. Judicial systems take a lot of people and a lot of work. They even require "volunteer" (ish) labor for juries. They're expensive. Governments have them because in real life justice is worth the cost. To Blizzard, it's only worth the cost if it gets enough additional people buying the game to cover the costs. And I really doubt that would happen.
I guess the moral of the story is, "Never expect justice from a for-profit corporation."
Actually if you link some of the more pesky libraries statically and don't use any kernel functionality that's too new you can get very wide binary compatibility. This is more or less how things work on Windows and Mac, right? You certainly can't claim that GNU/Linux systems have the kind of backwards (or sideways, for that matter) compatibility that Windows does, but it's possible to make statically-linked binaries that run across a wide range of kernels.
I don't know if this is worthy of man-love, but it is one way to do it.
That's one way to look at things. Inalienable rights. It is cool that so many of you dudes know your important documents.
Another way to look at it is that at this time (and even at the time of the Declaration of Independence) government is a foregone conclusion; given a large enough group of people that is not governed, they will tend to either form some kind of government or be conquored. And government, not otherwise limited, can do basically anything that it's physically able to enforce. When a government consciously limits itself (in true action, not just on paper, as you surely know of at least some of the freedoms guaranteed by the constitutions of many corrupt regimes) it defines the people's rights under that government (though other social organizations may take away some rights in their own way).
Rights aren't inalienable just because Thomas Jefferson said they are. Ask fifty people that have never read the Declaration of Independence what their inalienable rights are and you could get fifty different answers. The dudes that wrote the Declaration probably argued about the rights they'd claim as inalienable, and some probably walked away from that debate unhappy. Inalienable rights makes a great battle call. But we're not going into battle today. We'd be better off if, instead of taking Jefferson as gospel, we looked at the rights that he's talked about and affirmed first that we as a society do indeed value those rights, and second the reasons that we value them. And then look at all the other rights that we value and protect today, as well.
O'Reilly wasn't talking about any particular kind of technology. He was talking about the way people use and rely on the technology.
Now there's plenty of other technology he relies upon that fuddy-duddies 30 years older than him probably scoff at. But the point I'm making is that it's not a question of how advanced the technology is, it's a question of what it does and how it's used, for and by people.
XMPP (Jabber) allows for that. The messages are delivered next time you log in. I don't know whether all servers are required to implement that feature... whatever. Jabber actually looks kind of like email in terms of namespace and in the open exchange of messages between servers.
Jabber is clearly an IM protocol and not email based on its other features, its typical model of use, the UIs of most of its clients, etc. You can't just take one feature and claim that it's the distinction between IM and email. That one feature might make Jabber more email-like than other IM systems. But it wouldn't make it email.
There are many differences between email and IM. Tying this back to the real topic at hand, I don't think that any of those differences are relavent in this case.
People haven't "always" been able to carry a music collection with them to listen to, say, while walking down the street. At least, they haven't always been able to do it very easily. They gained this ability with walkman-like devices a few decades ago. This might seem like "always" to you, but O'Reilly is probably a lot older than you are. In fact, recorded music isn't really all that old itself. One might argue that recorded music has diminished the significance of live music performance; after all, how often do you hear a piece of music performed for the first time live? At the same time, it's also lowered the threshold for enjoying music in terms of cost, social class and location (you don't have to live near Chicago to hear the CSO, and if your favorite band won't come to your town you can still buy their CD). And the iPod, after all, is just another way for people to pipe recorded music into their heads, sans-performer. It's just an improved phonograph.
Maybe it never registered with O'Reilly that an iPod is an improved Walkman. I'd say it probably did, because to a non-user of such devices they all look the same: a set of headphones connected into a little piece of plastic. The connection would be hard to miss. But iPods and other modern portables have done something distinctive (that is, in addition to their technical distinctions such as increased storage space, ease of putting together custom playlists, and the single-oriented online music stores): they've made portable music popular to the point of ubiquity among young people. And they have, more than any previous portable player, become a status symbol among the young hip crowd. People have been able to walk down the street, disengaged from their immediate reality, with headphones in, for several years now. But the coming of the iPod has made it not only much more common, but also made it the cool thing to do.
No, no, no, no, no. That's completely ridiculous. Even within the ntfs-3g website they list some cases where Microsoft's chkdsk reports bogus errors, and say, "This is a bug in chkdsk and we're not fixing it." You write a filesystem driver to perform to the specification (even if you have to reverse-engineer the specification first). If you figure out the specification by looking only at one particular implementation of it, any place that you deviate from that implementation at all you risk being incompatible with future implementations. On the other hand, if there's a clear specification within which all implementations operate this is less of a risk.
Have you ever heard of people writing software, particularly drivers, and then with a change in the operating system or some libraries the software stops working? Even if the API wasn't supposed to change? It often happens that there was some incorrect assumption made that happened not to matter with the old implementation and does matter with the new one. The assumption was always incorrect. If you want software to age gracefully you don't just code to the binary status quo, you code to the spec.
It looks like the ntfs-3g dudes have done a fine job with the information they have. But I'm sure they'd find the real specification very useful if it was legally made available to them.
Just because the sum of all NTFS data sitting on people's Windows boxes is more data than a technical specification doesn't mean it's more complete and correct than a good technical specification.
You won't be able to carry the "Genuine" data (in the Microsoftian sense) around on your flash stick. Or, perhaps you will, but you won't be able to play it anywhere but your own computer. Most of the files we get from mainstream media (such as TV series) will be encrypted with DRM. Unless they start selling us special flash sticks that somehow implement copy protection, perhaps by an HDCP-like scheme (whereby the drive will refuse to give up its data without the entire playback stack authenticating with it).
It's an impressive technical acheivement, sure, but does it actually make the operating system better?
Some people would argue that insisting on backwards compatibility is the cause of many of the problems involved with practical Windows usage today. One of the major examples of this is how inconvenient it is to run as a non-admin class user. If Microsoft had laid down the law in NT from the beginning and made it very abnormal to run with admin powers day-to-day some (not all) of the security problems would not be an issue today. Even in Vista today lots of people still want to run with full powers. If Apple can break compatibility as often as they do and get away with it Microsoft can, too. People will rewrite useful and necessary programs, and make them better. A foolish consistency is the hobgoblin of little minds (Emerson)! Unixes generally have a tradition of source compatibility rather than binary compatibility, which has its own problems; insert Plan 9 rallying cry here.
Certainly most of Windows' security problems, especially recently, come from it being the majority computing platform among the human race, a notoriously easy-to-exploit class of security vulnerabilities. But all their work towards binary compatibility certainly hasn't helped.
He can sell the physical CDs, sure. He can't copy the contents and distribute those copies because that's a violation of copyright law. I think the latter is what OP was getting at.
I don't see anything necessarily wrong with this in principle; the consoles are a commodity that is sold for less than it's worth, people can and do buy 'em and sell 'em for a profit. And anyone that desperately wants the console to play games will shell out the dough, because they're suckers. And people that can't afford that are probably better off anyway, because they shouldn't need overpriced crap to make them happy. Mod me redundant, because I'm sure I'm repeating myself here.
What surprises me is that businessmen are getting into it. Even though they can probably quickly double or triple their investment selling the PS3s, there's a limited supply and lots of competition to get the units. Even if they make $1000 per unit they're spending a considerable amount of time to turn over a limited number of units. It seems to me they could make more money in the same amount of time trading stocks/bonds/commodities because the process is more streamlined and the volumes are higher. So for some kid looking for quick money it would surely be a good investment, I'm just surprised that it's worth the time of rich dudes.
Even if there's a drive that plays all (which as my elder sibling points out hasn't really happened yet), I think that only one of the two formats will win in the end. I don't think there's room on store shelves for two the-same-but-different copies of every movie. The Internet, where shelf space isn't a problem, will lessen that , but if one of the two formats gets critical mass the other will be marginalized. Controlling the format is not a means to the end of making The Big Bucks (tm) by selling hardware; Sony made plenty of money selling VHS players post-Beta failure. Controlling the format is an end of its own, with potentially even Bigger Bucks (tm) to be made.
As a freshman in college I was called by someone through a relay operator to try to get me to join some kind of "secret society". Or it was probably just a silly prank either by one of my friends or some older folk in ECE. But I never heard of anyone else getting the call, and none of my friends ever admitted to doing it. Which is odd, for sure.
I hung up after a while, and they called back, this repeated a few times. Then my (drunk) roommate picked up the phone and started hitting on the operator. I felt bad for the operator, if she was really an operator, but it was still hilarious. It was especially funny to imagine because this woman had the most cold, strange, monotone voice I'd ever heard.
Being a relay operator would be a hell of a job. I should try doing it for a while.
Well, look on the bright side: unless your VM has a bug in it there's nothing they can do to stop you, and the EULA may well be invalid anyway. The former, of course, will be wiped out by TPC. The latter, I've heard, is at risk because of laws in some US states that validate EULAs.
For things like BlueRay that use HDCP you need real video/audio hardware anyway. And I always thought VMs weren't that good for media anyway. What with their typical timing issues, lack of direct hardware access, high latency...
It's unreasonable because virtual machines are designed to simulate computers exactly. If they can't run Windows DRM it would be a bug in the VM.
Best guess I have is the reason they don't want people doing it is that it would allow people to hack the DRM more easily. And it would. You can trace the execution of a program and directly read out memory contents very easily using a virtual machine or debugger. I've heard Vista won't allow the use of debuggers on DRM-related programs, but if you're running in a virtual machine they can't stop you from looking at memory and register state. With a virtual machine you could in theory, for example, have virtual video and sound hardware that would allow you to crack HDCP. You could step through Windows DRM code instruction-by-instruction to figure out where they keep decryption keys for their music files. This isn't exactly easy, and I'm sure they put lots of hurdles in your way, but a determined and smart hacker could probably figure it out.
At least until TPC is turned against us. Once that happens the ability of a virtual machine to fake-out an OS is constrained.
A knoppix CD has good hardware detection and lots of drivers installed for the devices it supports. I'm sure it gets most of the common ones, but I'm just as sure there's a lot it misses. Knoppix can't legally distribute Nvidia's or ATI's drivers, for example, so the game companies would have to work out a deal for them. There are also devices that might come out in the future. The user, in the general case, would have to burn their own game CD upon installation to get all their drivers. Users would balk at this because it's complicated and time-consuming, game companies would balk because it would complicate copy-protection. And what about the program that aggregates the drivers for the LiveCD? Where does it run? On the normal OS? So you're right back to square one.
I still think the vulnerability issue is a problem. A vulnerability in Linux firewall code or in the services run by the game could leave the system open. To patch it you'd need to burn the CD over again (which takes two reboots). Think about the user experience for this: user reboots, sticks in CD for Game OS. Game OS says, "I need updates!" User reboots back to normal OS, runs update utility, burns CD, reboots onto new CD, plays game. Three reboots vs. the current status-quo, which is "wait a few minutes for patch to download, then go on playing".
The diversity of PC and Mactel systems is just too much; PC operating systems have spent a lot of effort providing an abstraction between hardware and software, and to replace the OS the user already has working with a new one that has to support all that diversity would be a nightmare. None of the problems I listed have been solved well enough for a game designed to work this way to work nearly as well a game distributed just as a single-platform binary for the user's existing OS. It's not just that it's not the best idea. It's that it's a complete waste of time trying to turn PCs into consoles.
People buy things and sell them for more money all the time. It's called a market economy. They're not doing it on a "free ride", they had to have either the foresight to pre-order or the patience to wait out in front of the store before opening time. They also had to somehow obtain the money to buy it in the first place. That's how you make investments.
In the sense that console resellers are getting a "free ride" all investors get a "free ride". It's just how the economy goes. Some people trade stocks, some people trade commodities and some people that are in for small potatoes trade consoles.
Along those lines they say that in Canada they hand-count ballots. But they don't have nearly as many items to vote on in each election in Canada. The voter guide I got here in California is a frickin' tome.
By "sharpies" do you mean permanent markers? How reliable are the scanning machines?
Sometimes it's actually easier to make a clean break than to modify an existing codebase. Sometimes an existing design is tied to assumptions and that you don't want to make, design decisions that you want to make differently. And for people that are familiar with coding KDE programs writing a pure KDE app will be easier, and they'll produce better code that integrates better with KDE.
I'm not familiar with this case specifically, but these could be among the reasons that they chose to write their own.
I'm sure most of the developers have used the GIMP and are familiar with its strengths and weaknesses, and many of them have probably looked at GIMP code and perhaps borrowed ideas from it.
I know this is just a silly mod-parent-up post, but parent is dead right. It would be cheaper, more reliable and more intuitive than touchscreens because touchscreens lack tactile feedback. It also means that you don't have your display screen getting smudged.
The tactile feedback thing is important. I operate ATMs much more quickly and confidently when the buttons have a nice keyboard-like "click" feeling to them. The ones with those cheap non-reliefed buttons that barely push in suck, and often make loud beeping noises to compensate for the poor tactile feedback. Touchscreens are the worst; during the delay before the action happens there's always a moment of unsureness.
You'd just have to make sure to build it right, of course. Definitely an LCD flat panel, and make sure it's not set back from the plane of the buttons, or else risk a butterfly-ballot style problem, where the user's position relative to the machine could affect the way the choices line up (that can be a problem with ATMs, both of the touchscreen and non-touchscreen variety, because they have cheap, tiny CRT screens that are set back from the buttons/touch sensors). And probably some other design considerations for legibility; I personally don't think it's too much to ask to have voters read a number next to a candidate's name and push the button corresponding with that number (numbers not directly on the buttons where they could wear off), but some people would probably complain. And you'd still have to test the machines for sticky, non-debounced or simply broken buttons. Nothing that an arcade manager couldn't handle.
We see this type of comment all the time. A few problems:
1. Drivers. You have to include drivers for all the hardware that your game needs (graphics, sound, network, input devices), including future devices in these categories. I've heard some interesting ideas for ways around this. They're interesting, but lead to a complicated and lengthy install process. You need to get your OS to boot on everyone's crazy hardware configurations.
2. Networking and patching. If you're making a network enabled game you're asking people to put their computers on a network (likely even the Internet) with an OS that can't be updated without spinning another DVD. There will be security holes found in the OS. Lots of people running the exact same unpatched OS version will be playing these games. Just because the OS installation on the CD/DVD can't be modified, it leaves open an attack vector to data on the hard drive. Game manufacturers like the ability to easily patch their games for bugs, anti-hacking techniques, and other random things. Argue all you want that they should get it right the first time, they wouldn't want to give that up.
3. Rebooting. People don't like rebooting. It takes a long time. They have to disconnect from IM programs, they have to turn off their music players, etc. They lose their software stack and configuration info (think configurable input devices that require userland apps for configuration). Configuration that would be shared between multiple games must be redone for every game you buy. It's more difficult for people to minimize the game and post the video of their latest frag to their website.
4. Licensing. What OS would game developers use for this? Windows or some similar variant. The driver support and developer tools are there for Windows, and most PCs sold today have undergone QA on Windows. Paying the licensing costs would drive up the price of the game.
And what is gained? The day-to-day experience (that is, the experience outside of patching and installation) for Linux/Mac users would be the same as now: a reboot into an OS they use mostly for gaming; in fact, since a real Windows installation would be more useful than the game OS the experience would really be slightly worse. The day-to-day experience for Windows users would be much worse: two reboots to go from regular use to game and back. Reboots between different games.
All of them? Dude, you only need one.
He's right and it is applicable here. I R'd TFA and it said that the Windows mixer component is used to instruct the sound card to loop output back to input. I did that once on my computer as an attempt to get a sample of a MIDI file. You don't have to be an audiophile (I'm not) to hear that the quality of playback is much worse than the original playback of the MIDI file. It would be exactly the same if the program manipulated audio streams like JACK. You can, in fact, hear noise in the recordings corresponding to activity on other parts of the motherboard (I have an onboard sound card, and a poor one at that).
Linux apps that can use JACK need to be written to support JACK's API. I think JACK has a kernel component as well, but I may be wrong. At any rate, the most straightforward way I can think of for a program to simply store a *digital* stream from any program directly to a file would be to write a "fake" audio driver that writes to disk. For programs with output plugin support (Winamp and similar programs come to mind) you could create a "disk writer" plugin (and this has been done), but in the general case you'd have to write a general audio driver (I'm pretty sure that's been done as well).
If some level of DRM decoding is done at the OS (including kernel or libraries) or hardware level, and if the OS does not allow unsigned drivers, this approach is thwarted.
Wikipedia says that Diffie and Hellman published their work in 1976, and that the earlier secret work was going on in the early 70s. So it looks like they're talking about the public discovery, assuming both that Wikipedia is correct and that I can add small numbers in my head accurately.