The people who want to be the first to get something always have to pay a lot more than the people who wait for someone else to buy first, and then get in once other people have paid the creator back for R&D costs.
People paid a whole lot for 486s way back when, and the price dropped quickly once these initial people had bought them.
The client is paying to have this software available to them. They should negotiate a price that reflects the value to them. If the software is mission critical, it will probably save them more money than they pay for it. The fact that their money additionally benefits others is something they should be prepared to live with, because it's an economy of scale, like everything else, and client #2 always gets a better deal than client #1.
Furthermore, if the software becomes open source, they stand a good chance of being client #2 for some features they want later; if the software is a totally custom job for them and unavailable to anyone else, it's automatically orphan code.
The transit authority isn't supposed to follow what random drivers think; random drivers are supposed to follow what the transit authority thinks. The face-egging is that this guy came up with a sign that was right, and the transit authority didn't.
What makes it art is that it appears to be a normal sign, but it is not what it appears to be. Art is when you dupe the viewer into believing that there is actually something there that isn't, whether they see a slightly-smiling woman where that is paint on canvas, an impossibly twisted world where there is ink on paper, a huge building where there is a small one (or the reverse), a sweeping landscape where there is light on a screen, a pipe where there is a line drawing, or an official CalTrans sign where there is a homemade version.
If your placard makes students think they are walking past Room 4-001, when, in fact, they're walking past a random bathroom, you have made people think something they would not have otherwise thought, which is the point of art.
Re:Official Signs that you'd think would be jokes.
on
Hacking the Highways
·
· Score: 2
So the Road To Nowhere is now the Highway Missing In Action? If someone finds it, they should put up a sign...
The problem is that selling your software to most of the computer users in the world means it's not really obscure. Security through obscurity only works if the system doesn't give feedback to attackers. Letting people run the software themselves is like playing mastermind with your passwords: it will still take people a little while to break them, but it is by no means secure.
Security through obscurity has a place in unique, locally developed systems which only grant access to trusted users. In a commercial product it is nearly useless.
I would presume that the flaw is such that, if you have a Messenger account and have MSN Chat (which is probably installed by default and which probably can't be gotten rid of entirely), you're vulnerable. Trillian users probably count as non-active users of the broken MS client for the purposes of this bug.
Bit ironic to see on slashdot, where there are frequently (maybe twice a day) unmarked minor corrections to stories due to comments which point out problems (the URL doesn't work, the title has a typo, etc). Of course, more major updates do get marked as such, presumably so that readers will reread them.
First of all, there's no reason you can't fetch yourself a copy of a story in the morning, and then read it whenever you want, refer back to it on a later date, compare it with a later edition, etc. In fact, if anything prevented this, we wouldn't have this article. It's not like you can call up a newspaper and ask them to print you yesterday's paper. If you want to see yesterday's paper, you look at a copy produced by the company yesterday, achived by you or someone else. It's not the news people's job to write history; it's their job to write current events. As things change, it's not their job to tell you about the past.
Should they mark updates? Yes, but for the same reason that slashdot marks them: it is a disservice to people who read the original or people the original was unfavorable to if the new version is not marked as such, because people won't reread the article, and will not know about the new information.
The best use I know of for affective computing is in running usability tests. You have the person use your program, and monitor their emotional state. You can then determine how they actually feel about the interface without interfering by asking them questions while they're trying to use it, or missing things by only recording after the fact.
Back in the old days, the reason that the Good Times virus was obviously a hoax was that email was data, and was never treated like code (unless the user went to the trouble of extracting something from the message and then running it, at which point it was an issue of downloading programs from the net, not a virus).
The same used to be true of spreadsheets and word processor documents: you couldn't get a virus in them because they didn't include code. If there were macros, they lived on your computer, separate from your document, and you used them to generate an inert document, which you could then distribute.
I think MicroSoft should go back to passive documents in general, with active documents (and programs) available only when you explicitly extract them from the passive document, and then run them outside of your viewer.
I'd guess that it's some sort of exploit-wrapper or tool for examining the system, rather than a program that is supposed to look like something recognizable. Otherwise, some of the things they're asking aren't interesting questions.
This process is presumably self-sustaining (once it gets started, which obviously takes energy). Waste actually has a reasonable amount of energy, which is why it will burn. The trick is extracting that energy in a more useful form without making a huge mess. They seem to have found a material that permits the hydrogen gas to be separated from the rest of the stuff.
The old process is 20% efficient, which presumably means that it gets 20% of the energy in the waste out in the form of H2. The new process is supposed to be twice as efficient. The process doesn't require more energy than it produces, but it remains to be seen whether it produces enough energy to be worth the pain of dealing with waste and hydrogen-depleted waste.
Those utilities are all do things which are not intuitive to people who aren't used to them.
But I think Cygwin is a good idea, because it allows the CD to include a bunch of stuff that's written for a Unix-like system, just because a lot of really useful things are written that way, and Cygwin is a good way to package them up and install them together.
Cygwin lets you provide scp, which is always missing from windows ssh clients (and there are a lot of cool things you can do with ssh that windows clients don't support). There are also a number of other utilities that are really helpful in a mixed Unix and Windows environment, like cvs.
Not to mention that titanium dioxide (white paint dye) is a lot bigger than carbon. I think it's a better idea to tie a lot of nanotubes together and then paint that, once it's gotten thick enough to deal with directly.
You are actually required to offer them the source code as well, since reproducing the software is not a right that you have by default. You should probably say, "No, it's not", scribble "Ask XXX for source CD" on the CD, and say, "Okay, now it is. Thanks for reminding me."
It is illegal to copy without a license. What is legal without a license is using your copy, including transferring it to new media as required to use it (e.g., from CDROM to hard drive or memory, or CD to sound waves). The GPL gives you permission to copy, provided you also offer source.
You probably doon't really need to offer the source yourself, because Red Hat will provide it directly to whoever asks, even though they only, strictly speaking, have to give source to people who have gotten binaries directly from them.
Makes me wonder how many GPL binaries out there cannot legally be copied, because the source has been lost.
Right, so you just have to paint each nontube white...
Actually, it probably just gives another reason you'd want to coat nanotube bundles with something when you're going to use them. Of course, it's always been known that it's important to coat them with something, because they're flamable, being pure carbon.
Jack mentions that one of the implementations only plays files up through beta 4. That means that something changed at that point in the file format. In part, they didn't release a full specification, most likely, because then their later versions would break compatibility with it. It makes sense to only release an official specification with your version 1.0 release, where you have worked on it enough to believe that you can avoid breaking compatibility in the future. Similarly for getting standard bodies involved; there are plenty of things where there's a "official standard" that is not quite right, because not all issues had been resolved when the standard was made.
Also, it seems like the Ogg Vorbis people will only write up a specification if they think anyone is interested in reading it. It's obviously a lot of work, and, if they didn't think their format would be implemented by other people, they would just work more on their own implementations instead. It's not particularly useful for people to complain about the lack of a specification (since they know it hasn't gotten done), although it is probably useful to hear that people still care.
The purpose of firewalls is to isolate a machine from the bad guys who might exploit security holes you want to leave open for the local good guys. That is, you have the open network, then the firewall, then a network where you're more lax about security. That way you can use insecure protocols in places where you trust the network.
If you're putting a firewall on the machine, the only area where you don't have to care about security is within your machine. But within your machine, you have other methods: IPC, shared memory, or even net 127.
But what this really does is it talks to a server which tells the NIC what to ignore, overriding what your machine wants to do (if there are any security holes on your machine, your OS will presumably configure the firewall to expose them, if it can; if it weren't going to, it would filter at the OS level). This essentially prevents your machine from listening on any ports that the central server doesn't want you listening on or making connections the central server doesn't want you to make.
There are two functional differences between this and a traditional firewall. The policy machine doesn't have to look at the packets, because it tells the machines which have to look at the packets anyway what to do; therefore, it's harder for an outsider to overwhelm the policy machine. Also, this setup will allow the firewall to stop you from talking to other machines on the network. This could stop a worm from spreading within a company over services which aren't supposed to be enabled.
So the policy server and the set of cards together make what amounts to a firewall. If you buy one of these, you don't get your own firewall.
Probably getting equipment before content
on
G4: The Pong Channel?
·
· Score: 4, Informative
This actually happens with a lot of new channels. If you're planning to show something you have to pay for, you don't want to start with real content. If your equipment gets delayed, or you have problems with it when you start, you don't want to be wasting content you paid for. On the other hand, you don't want to pay for your broadcast bandwidth if you're not going to broadcast anything.
So the usual thing to do is to broadcast something really cheap until you know it's all working correctly. Of course, you run into the danger of people actually preferring the fake content to what you actually want to show. (There was one station that broadcast a camera pointed at a fishtank until they got their studio ready, and then people called in to request the fishtank)
There's plenty of information I want to get that I don't want to look at as email.
For example, I'd like to get messages inviting me to events I'm unlikely to go to, and I'd like to have their dates get marked down so that I can see what is happening on a given day if I feel like doing something.
I'd like to get new addresses for people, but I want to have my addressbook updated instead of seeing the message.
It would be really convenient to have software that would figure out this sort of information from a human-readable message, since people are likely to want to send it in natural language (and the message probably includes more information that I might want to see if I decide I care.
It certainly seems to me that this sort of tactic, especially against government agencies, is something you can only pull is you're a monopoly, and can be certain that they've been given the right by an EULA to search every single computer.
Which means that the next line should be:
.govOkay, you owe us $15 million, plus anything we pay due to your sweeps
Of course, that would require some more time in court. But it's not good for long-term viability to base your business on illegal profits from the government, because they'll want the money back eventually.
Encrypted email will probably go through essentially the same stages as HTTPS.
First, it will get integrated into mail clients, for those users who insist on it, in a half-hearted way. Then mail clients will pop up a warning when you send something unencrypted, which most people will just click through for most messages, but people might notice when they're sending a message which they wouldn't send by plaintext HTTP. Then it will become normal for sites with HTTPS servers to have PGP keys for email. It probably won't get much beyond that any time soon, though.
As far as implementation, I anticipate PGP and similar software dying out, in favor of PGP-like crypto functionality being supported in OpenSSL. Why OpenSSL? Because it has become the standard security library implementation. OpenSSH uses OpenSSL, even though SSH competes directly with telnet-over-SSL. OpenSSL also has all the cryptographic functions, it's BSD-licensed, and a lot of security-conscious projects beat on it. Once OpenSSL has support for PGP-formatted stuff, it will be easy for email clients to integrate it. Also, since many email clients are integrated with browsers, which need SSL support (and so use OpenSSL already), it's simply a matter of calling the decrypt function when you get an encrypted message, storing public keys in the address book, and encrypting messages to anyone who has a public key in the address book.
It is no longer necessary to have a separate program for encryption. Writing crypto code is hard, but OpenSSL does or will do almost all of it, so you're left with managing the user's private keys (just like managing client certificates), managing other people's public keys (just like managing site certificates), and distributing the user's public key (just like business-card attachments). The only tricky thing is in signing other people's keys, but if you're not worried about active attacks with people who you don't talk to out-of-band and who don't aren't corporate sites, you don't need to bother.
A lot of people don't like giving their email addresses in order to get stuff. That is presumably not the problem you're having, though, because it's unlikely that people will put in a fake email address to which the information on how to get the software will be sent. If something asks for an email address to send information to, I either go away or I give a real one, because I don't get anything by giving a fake one. (I may give a fake one if it just wants an email address but I'm not expecting anything I want to be sent to it). Likewise, if I'm annoyed enough that something is asking for an email address gratuitously to not want to deal with the site, I'm not going to give an email address.
On the other hand, if I'm expecting information by email in response to a web request, I expect to get a response in a minute. It's not like sending me email is at all complicated. If it takes longer than that, I'm going to look for an alternative. If the site takes a few hours, I've probably already started using a different program, and I'm not interested in the one I found at first.
I was talking about the particular list of console games given as "the action in games". Of course there are classic console games. It's just that the flashy new console games people are playing today are mostly not destined to be classics.
The console life cycle is also such that the current games aren't going to be played much in 6 years, because the consoles will be too obscure. Some of the games people like will be released in new versions for the new consoles (Zelda, Mario, Final Fantasy, e.g.). The rest will be played, ironically, in simulation on PCs, where they will be subject to mods (such as translation of Japanese editions into English).
My personal biases: play console games that my housemate gets until I get bored of them; play text adventures and roguelikes intermittently. I haven't actually had a machine set up to play the mainstream modded games since Quake was available for modding. My experience has been that console games are a lot of fun, but easy to play out, while PC games will have new things to play with if you come back to them after a while.
Slashdot Mirror
The people who want to be the first to get something always have to pay a lot more than the people who wait for someone else to buy first, and then get in once other people have paid the creator back for R&D costs.
People paid a whole lot for 486s way back when, and the price dropped quickly once these initial people had bought them.
The client is paying to have this software available to them. They should negotiate a price that reflects the value to them. If the software is mission critical, it will probably save them more money than they pay for it. The fact that their money additionally benefits others is something they should be prepared to live with, because it's an economy of scale, like everything else, and client #2 always gets a better deal than client #1.
Furthermore, if the software becomes open source, they stand a good chance of being client #2 for some features they want later; if the software is a totally custom job for them and unavailable to anyone else, it's automatically orphan code.
The transit authority isn't supposed to follow what random drivers think; random drivers are supposed to follow what the transit authority thinks. The face-egging is that this guy came up with a sign that was right, and the transit authority didn't.
What makes it art is that it appears to be a normal sign, but it is not what it appears to be. Art is when you dupe the viewer into believing that there is actually something there that isn't, whether they see a slightly-smiling woman where that is paint on canvas, an impossibly twisted world where there is ink on paper, a huge building where there is a small one (or the reverse), a sweeping landscape where there is light on a screen, a pipe where there is a line drawing, or an official CalTrans sign where there is a homemade version.
If your placard makes students think they are walking past Room 4-001, when, in fact, they're walking past a random bathroom, you have made people think something they would not have otherwise thought, which is the point of art.
So the Road To Nowhere is now the Highway Missing In Action? If someone finds it, they should put up a sign...
The problem is that selling your software to most of the computer users in the world means it's not really obscure. Security through obscurity only works if the system doesn't give feedback to attackers. Letting people run the software themselves is like playing mastermind with your passwords: it will still take people a little while to break them, but it is by no means secure.
Security through obscurity has a place in unique, locally developed systems which only grant access to trusted users. In a commercial product it is nearly useless.
I would presume that the flaw is such that, if you have a Messenger account and have MSN Chat (which is probably installed by default and which probably can't be gotten rid of entirely), you're vulnerable. Trillian users probably count as non-active users of the broken MS client for the purposes of this bug.
Bit ironic to see on slashdot, where there are frequently (maybe twice a day) unmarked minor corrections to stories due to comments which point out problems (the URL doesn't work, the title has a typo, etc). Of course, more major updates do get marked as such, presumably so that readers will reread them.
First of all, there's no reason you can't fetch yourself a copy of a story in the morning, and then read it whenever you want, refer back to it on a later date, compare it with a later edition, etc. In fact, if anything prevented this, we wouldn't have this article. It's not like you can call up a newspaper and ask them to print you yesterday's paper. If you want to see yesterday's paper, you look at a copy produced by the company yesterday, achived by you or someone else. It's not the news people's job to write history; it's their job to write current events. As things change, it's not their job to tell you about the past.
Should they mark updates? Yes, but for the same reason that slashdot marks them: it is a disservice to people who read the original or people the original was unfavorable to if the new version is not marked as such, because people won't reread the article, and will not know about the new information.
The best use I know of for affective computing is in running usability tests. You have the person use your program, and monitor their emotional state. You can then determine how they actually feel about the interface without interfering by asking them questions while they're trying to use it, or missing things by only recording after the fact.
Back in the old days, the reason that the Good Times virus was obviously a hoax was that email was data, and was never treated like code (unless the user went to the trouble of extracting something from the message and then running it, at which point it was an issue of downloading programs from the net, not a virus).
The same used to be true of spreadsheets and word processor documents: you couldn't get a virus in them because they didn't include code. If there were macros, they lived on your computer, separate from your document, and you used them to generate an inert document, which you could then distribute.
I think MicroSoft should go back to passive documents in general, with active documents (and programs) available only when you explicitly extract them from the passive document, and then run them outside of your viewer.
MicroSoft security and all the gold in Fort Knox. Good thing they can buy it four times...
MicroSoft reliability and the entire airline industry. Good thing they can afford an extra one...
All those sports teams, but not as popular as Solitaire.
On the other hand, 23 space shuttles would be cool.
His statements were frequently contradicted by e-mails he had sent and received, and he frequently claimed no recollection of the messages.
Of course, he was using Outlook, so it's not surprising that he sent e-mails he doesn't recall...
I'd guess that it's some sort of exploit-wrapper or tool for examining the system, rather than a program that is supposed to look like something recognizable. Otherwise, some of the things they're asking aren't interesting questions.
This process is presumably self-sustaining (once it gets started, which obviously takes energy). Waste actually has a reasonable amount of energy, which is why it will burn. The trick is extracting that energy in a more useful form without making a huge mess. They seem to have found a material that permits the hydrogen gas to be separated from the rest of the stuff.
The old process is 20% efficient, which presumably means that it gets 20% of the energy in the waste out in the form of H2. The new process is supposed to be twice as efficient. The process doesn't require more energy than it produces, but it remains to be seen whether it produces enough energy to be worth the pain of dealing with waste and hydrogen-depleted waste.
Thanks; that package either didn't exist or was less complete last time I looked for windows ssh clients.
Those utilities are all do things which are not intuitive to people who aren't used to them.
But I think Cygwin is a good idea, because it allows the CD to include a bunch of stuff that's written for a Unix-like system, just because a lot of really useful things are written that way, and Cygwin is a good way to package them up and install them together.
Cygwin lets you provide scp, which is always missing from windows ssh clients (and there are a lot of cool things you can do with ssh that windows clients don't support). There are also a number of other utilities that are really helpful in a mixed Unix and Windows environment, like cvs.
Not to mention that titanium dioxide (white paint dye) is a lot bigger than carbon. I think it's a better idea to tie a lot of nanotubes together and then paint that, once it's gotten thick enough to deal with directly.
You are actually required to offer them the source code as well, since reproducing the software is not a right that you have by default. You should probably say, "No, it's not", scribble "Ask XXX for source CD" on the CD, and say, "Okay, now it is. Thanks for reminding me."
It is illegal to copy without a license. What is legal without a license is using your copy, including transferring it to new media as required to use it (e.g., from CDROM to hard drive or memory, or CD to sound waves). The GPL gives you permission to copy, provided you also offer source.
You probably doon't really need to offer the source yourself, because Red Hat will provide it directly to whoever asks, even though they only, strictly speaking, have to give source to people who have gotten binaries directly from them.
Makes me wonder how many GPL binaries out there cannot legally be copied, because the source has been lost.
Right, so you just have to paint each nontube white...
Actually, it probably just gives another reason you'd want to coat nanotube bundles with something when you're going to use them. Of course, it's always been known that it's important to coat them with something, because they're flamable, being pure carbon.
Jack mentions that one of the implementations only plays files up through beta 4. That means that something changed at that point in the file format. In part, they didn't release a full specification, most likely, because then their later versions would break compatibility with it. It makes sense to only release an official specification with your version 1.0 release, where you have worked on it enough to believe that you can avoid breaking compatibility in the future. Similarly for getting standard bodies involved; there are plenty of things where there's a "official standard" that is not quite right, because not all issues had been resolved when the standard was made.
Also, it seems like the Ogg Vorbis people will only write up a specification if they think anyone is interested in reading it. It's obviously a lot of work, and, if they didn't think their format would be implemented by other people, they would just work more on their own implementations instead. It's not particularly useful for people to complain about the lack of a specification (since they know it hasn't gotten done), although it is probably useful to hear that people still care.
The purpose of firewalls is to isolate a machine from the bad guys who might exploit security holes you want to leave open for the local good guys. That is, you have the open network, then the firewall, then a network where you're more lax about security. That way you can use insecure protocols in places where you trust the network.
If you're putting a firewall on the machine, the only area where you don't have to care about security is within your machine. But within your machine, you have other methods: IPC, shared memory, or even net 127.
But what this really does is it talks to a server which tells the NIC what to ignore, overriding what your machine wants to do (if there are any security holes on your machine, your OS will presumably configure the firewall to expose them, if it can; if it weren't going to, it would filter at the OS level). This essentially prevents your machine from listening on any ports that the central server doesn't want you listening on or making connections the central server doesn't want you to make.
There are two functional differences between this and a traditional firewall. The policy machine doesn't have to look at the packets, because it tells the machines which have to look at the packets anyway what to do; therefore, it's harder for an outsider to overwhelm the policy machine. Also, this setup will allow the firewall to stop you from talking to other machines on the network. This could stop a worm from spreading within a company over services which aren't supposed to be enabled.
So the policy server and the set of cards together make what amounts to a firewall. If you buy one of these, you don't get your own firewall.
This actually happens with a lot of new channels. If you're planning to show something you have to pay for, you don't want to start with real content. If your equipment gets delayed, or you have problems with it when you start, you don't want to be wasting content you paid for. On the other hand, you don't want to pay for your broadcast bandwidth if you're not going to broadcast anything.
So the usual thing to do is to broadcast something really cheap until you know it's all working correctly. Of course, you run into the danger of people actually preferring the fake content to what you actually want to show. (There was one station that broadcast a camera pointed at a fishtank until they got their studio ready, and then people called in to request the fishtank)
There's plenty of information I want to get that I don't want to look at as email.
For example, I'd like to get messages inviting me to events I'm unlikely to go to, and I'd like to have their dates get marked down so that I can see what is happening on a given day if I feel like doing something.
I'd like to get new addresses for people, but I want to have my addressbook updated instead of seeing the message.
It would be really convenient to have software that would figure out this sort of information from a human-readable message, since people are likely to want to send it in natural language (and the message probably includes more information that I might want to see if I decide I care.
It certainly seems to me that this sort of tactic, especially against government agencies, is something you can only pull is you're a monopoly, and can be certain that they've been given the right by an EULA to search every single computer.
.gov Okay, you owe us $15 million, plus anything we pay due to your sweeps
Which means that the next line should be:
Of course, that would require some more time in court. But it's not good for long-term viability to base your business on illegal profits from the government, because they'll want the money back eventually.
Encrypted email will probably go through essentially the same stages as HTTPS.
First, it will get integrated into mail clients, for those users who insist on it, in a half-hearted way. Then mail clients will pop up a warning when you send something unencrypted, which most people will just click through for most messages, but people might notice when they're sending a message which they wouldn't send by plaintext HTTP. Then it will become normal for sites with HTTPS servers to have PGP keys for email. It probably won't get much beyond that any time soon, though.
As far as implementation, I anticipate PGP and similar software dying out, in favor of PGP-like crypto functionality being supported in OpenSSL. Why OpenSSL? Because it has become the standard security library implementation. OpenSSH uses OpenSSL, even though SSH competes directly with telnet-over-SSL. OpenSSL also has all the cryptographic functions, it's BSD-licensed, and a lot of security-conscious projects beat on it. Once OpenSSL has support for PGP-formatted stuff, it will be easy for email clients to integrate it. Also, since many email clients are integrated with browsers, which need SSL support (and so use OpenSSL already), it's simply a matter of calling the decrypt function when you get an encrypted message, storing public keys in the address book, and encrypting messages to anyone who has a public key in the address book.
It is no longer necessary to have a separate program for encryption. Writing crypto code is hard, but OpenSSL does or will do almost all of it, so you're left with managing the user's private keys (just like managing client certificates), managing other people's public keys (just like managing site certificates), and distributing the user's public key (just like business-card attachments). The only tricky thing is in signing other people's keys, but if you're not worried about active attacks with people who you don't talk to out-of-band and who don't aren't corporate sites, you don't need to bother.
A lot of people don't like giving their email addresses in order to get stuff. That is presumably not the problem you're having, though, because it's unlikely that people will put in a fake email address to which the information on how to get the software will be sent. If something asks for an email address to send information to, I either go away or I give a real one, because I don't get anything by giving a fake one. (I may give a fake one if it just wants an email address but I'm not expecting anything I want to be sent to it). Likewise, if I'm annoyed enough that something is asking for an email address gratuitously to not want to deal with the site, I'm not going to give an email address.
On the other hand, if I'm expecting information by email in response to a web request, I expect to get a response in a minute. It's not like sending me email is at all complicated. If it takes longer than that, I'm going to look for an alternative. If the site takes a few hours, I've probably already started using a different program, and I'm not interested in the one I found at first.
I was talking about the particular list of console games given as "the action in games". Of course there are classic console games. It's just that the flashy new console games people are playing today are mostly not destined to be classics.
The console life cycle is also such that the current games aren't going to be played much in 6 years, because the consoles will be too obscure. Some of the games people like will be released in new versions for the new consoles (Zelda, Mario, Final Fantasy, e.g.). The rest will be played, ironically, in simulation on PCs, where they will be subject to mods (such as translation of Japanese editions into English).
My personal biases: play console games that my housemate gets until I get bored of them; play text adventures and roguelikes intermittently. I haven't actually had a machine set up to play the mainstream modded games since Quake was available for modding. My experience has been that console games are a lot of fun, but easy to play out, while PC games will have new things to play with if you come back to them after a while.