I don't agree with the point about network connections at all. Most homes that contain a console contain a PC for web-browsing and work - the issue is whether the PC is actually used for games. Two of the three consoles in the current generation have decent network support.
Being able to purchase service for a console is different from that service being widely used (and possible for a developer to effectively rely upon it being there). I know many people that have Internet access, but nobody that has XBox Live or similar service. A monthly fee for gaming doesn't go over very well with many people.
I think console keyboards will become standard for the games that "need them". Mice probably aren't all that far behind.
Maybe. A strong benefit of consoles is that a developer can rely on hardware just "being there". In console history, games that have relied on additional nonstandard hardware have, with only a few exceptions, not done very well. They are generally forced to bundle the peripheral with their game, which drives up their cost. I do not think that any of the console providers are going to start bundling a keyboard as standard -- initial cost is a serious factor in which system people choose, and none of the vendors want to drive it up too far. Same thing for mice. People have tried playing with the idea of additional periperals since at least the NES (I remember ROBBY the robot or whatever the thing was called), and it just hasn't done well.
The vast majority of fpses are based around a several year old engine (quake 3) which was, quite frankly, over-rated from day 1.
I'm curious as to why you're saying this. I admit that I haven't done modding or seriously played around with the Q3 engine, but just from playing Q3A, I've been reasonably impressed. It's quite fast. It supports curves with dynamic polygon reduction. It provides convincing (IMHO) volumetric fogging -- the levels that vanished off into a colored fog in Q3A were quite neat, IMHO. It provides portal support. Id has a tradition of good network engines, though I confess that I haven't done a careful comparison to other modern systems. What about it do you not like?
No -- you can have many root trust providers. The leaf nodes of the trust network would be users -- each user would sign their emails, not each server signing emails sent through them. You would use transitive trust, as you've pointed out. The task of a root trust provider can be very simple -- there might be, say, one that does nothing but sign four certs -- say one for an association that signs a cert for all registered businesses in the United States, one that does so for an association that signs a cert for all registered businesses in Japan, etc. Such a root cert provider requires a minimal amount of work. Such an association would sign certs for businesses belonging to it -- it's only to such an association's benefit to do so. Each business has no reason not to sign certs for its employees (and ensure that said employees do not spam). If employees *do* start spamming, the business loses a bit of trust, the association loses a bit less, and the root cert provider a bit less.
Elements of a trust network can *always* charge for service -- even today, I can walk into a GPG key signing party and pay someone to take the trouble to verify my information and sign my key. There are, however, many people who will sign my key without requiring me to pay money -- the noncommercial providers. Such a system absolutely does not require fees per-user or per-email to work.
So, in my opinion, there's no mystery -- PC games will go down in price quicker because PC games don't sell as well as console games.
That doesn't seem quite right. There are two cases where the publisher is going to reduce the price of their product. The first is when they simply misjudge the demand for their product, and realize that they cannot sell it at their initial price (as happened recently with the N-Gage). The second is when the publisher wants to benefit from price discrimination -- first they sell the game for $50 to all the people that are willing to pay $50 for itimmediately, then for $40 for the people that are willing to pay $40 for it, and so forth. A publisher will reduce their price more quickly if there is a broad spread of users willing to buy a product at different price points.
Simply not selling as well, volume of sales, doesn't directly relate to either of these two things.
Price is one of the few areas left in which PC games can compete for a mainstream audience with the consoles.
I disagree. I think that both the PC and the console have major advantages over each other that are good for various kinds of game.
The console:
* Number of users. There are more people out there with consoles than high-end gaming computer systems.
* Identical hardware. This significantly reduces development cost and code complexity, since you don't have to deal with making your effects and graphic systems scale to various systems or work at different resolutions -- if it works on one console, it works on all consoles of that brand.
* Control over the entire machine. PC operating systems like Windows (and mainstream variants of Linux) are not real-time OSes. A console can *ensure* that a game gets the cycles it needs each frame -- on a computer system, it's a fair bet that plenty of people are running a software package in the background that occasionally grabs a chunk of CPU cycles, be it a virus scanner, mail client/notifier, weather monitor, or NTP client. It's also easier to debug problems in an isolated environment. It also means that there are fewer variables that will result in Joe User saying "this game doesn't work on my computer" and returing it to EBGames or whatever.
* Reduced piracy. Pirating games for modern consoles, from a pragmatic standpoint, requires hardware modifications. Many people are quite happy downloading a modified CD image of a game to their computer, but are less comfortable mod-chipping their console. I've seen estimates of piracy vary a lot depending upon the particular game, but I've seen claims of upwards of 80% piracy. Now, admittedly, not all those were sales that were lost, but it's also true that some were. If you can make twice the sales on a console simply due to reduced piracy, there's a pretty strong incentive to choose the console (at least as a primary target).
* Gun interfaces. Consoles are pretty much the only game in town for gun peripherals.
* Initial hardware investment. A decent, midrange gaming PC still can be expected to cost upwards of $1000 (assuming no cannibalism of hardware). A console costs below $300.
* Easy installation. PC game installation and configuration is more complex and intimidating than console game installation and configuration.
* Presence of a good general-purpose gaming controller. For most types of games, the typical console gamepad is easier to use and hold, and is better technically suited to games (in that an unlimited number of buttons can be detected as down at once).
Advantages of the PC
* A broader range of input peripherals. You can get authentic fighter jet joysticks, pedals, steering wheels, gamepads of every variety, weird 3d input devices and weird throttle devices.
* Much more memory. Consoles are incredibly RAM-starved. This is visible not only in loading times, but in texture resolution and in less visible loss of functionality. Give a clever programmer some RAM to work with to precompute something, and he can usually whip up some amazing stuff. Less RAM means less wiggle room.
* A large, fast, writeable storage device. Consoles are limited to slow and small memcards (except for the XBox -- and the hard drive is going away in the next generation of the XBox). There are a lot of nice things you can do with mroe storage space -- store temp data, write data files of unbounded size (instead of ensuring that each saved game always uses under 192KB or whatever size limit is chosen). Fast seeks mean that programmers have to hassle less with clever loading of resources on the PC.
* Higher resolutions. This is, IMHO, actually less of an issue in the 3d world, since most 3d games are still playable at lower resolutions (if less attractive). For 2d games, it can be very annoying to have a smaller visible area, with fewer sprites.
I can't figure out why so many Slashdotters seem stuck on the merits of this idea.
Here are a couple of reasons why this is a bad idea:
* Complete lack of forward-compatibility with hardware (huge -- effectively kills the idea, and the reason why this scheme works in the console world with a standard set of hardware but not in the computer world).
* Forced rebooting and no other apps running
* Poor access times
* No patches
Basically, even if you overcame all the obstacles, you'd have little more than an expensive console (abeit with a lot of RAM), but without the standardized hardware and input devices that benefit console developers.
The benefits of the PC are pretty much different from those of the console. Trying to turn a PC into a poor copy of a console is just a bad idea. Leverage the strengths of the PC -- more memory, big, fast writeable storage devices, keyboard and mouse input devices (many buttons, good text-input capabilities, rapid and precise aiming), very commonly available network access, forwards compatibility, patchability, game extensibility, good toolkits -- widget sets and the like -- for producing things like editors.
Right -- you have to "live on top of" the base Freenet, having a utility that re-inserts your data when it vanishes.
The problem is that, if you want to allow people to add data to your system, you have to solve the problem of determining who can do so. If you include everyone, then people will consume space with data that isn't of general interest, but not donate space -- and people can take down their systems at any time, so if you don't allow data to drop, you have a very tough constraint of finding users that do not remove their systems from the network.
Yes, you're right -- it isn't perfectly intutitive. I do, however, play games that use the mouse wheel to provide a third degree of freedom (quite common in 3d RTSes to control camera height, for instance), and don't have much difficulty adapting to it, so I don't think it's an unreasonable proposition.
The problem is that generally GUI kiosk systems have a large, complex Windows backend. They don't have to do so, but most do, and some of the GUI benefits I listed depend on this.
If you're going to have a Windows core, unless you want to do *serious* modification work on the system, you're going to still have Explorer and friends lying around on your system. You have a lot of complexity coming with your system that you may not want.
While the "obvious" method for building GUI consoles on Windows (and even Linux, to a much smaller degree, since it's much easier to lock down a Linux GUI -- if there's no window managers or anything running, it's awfully hard to do anything) makes a kiosk application crash dump a user to a position of control over the system, text-based systems that I can think of in common use do *not* do so. Oh, there's probably some DOS-based system somewhere that would dump someone to a DOS prompt, but it's much more feasible to build a text-based system from scratch.
I've heard the "single sign-on/single authentication token/one ring to rule them all/whatever" spiel before. However, this is not an improvement by any means - it just makes it _easier_, not harder, for someone to impersonate you.
I disagree.
In an ideal world, where people can deal with an arbitrary number of passwords, then yes, that might be good. The problem is that people have *so many* passwords today that they *don't* manage them well -- they write them down, or store them on a computer, or use the same password in multiple places. So the problem of having a single point of failure is *already here*. There is some marginal benefit to the fact that people use different methods of storing their passwords, but the poor nature of the storage tends to, IMHO, eliminate most of that advantage.
If you have a single identifying token that electronic devices everywhere can use to know you, how many things does a potential no-goodnik need to become, for all intents and purposes, you?
If your password list or single password becomes such a single token, you're no better off.
And if they choose, they can then make it so you are not.
I disagree. With such a system, it's more feasible to have stronger policy measures for authentication -- where you can deauthenticate a lost card fairly easily (if you have only one "secret" to remember, it doesn't have to be something poorly chosen, like your mother's maiden name, or even something stored in the token itself, so that a thief could not necessarily separate you from your card).
But beating the "single sign-on! universal identity!" drum is not the answer - it makes it easier to steal your identity, not to mention if you're privacy-paranoid, it makes it easy for your movements to be tracked by one or more TLOs (three-letter organizations).
Single sign-on is different from single externally-exposed identity. As I mentioned in my earlier response to another, keychains already provide a single sign-on with multiple identities.
Also, if users would get over the urge to write passwords down and leave them laying around - there's nothing wrong (IMO) with writing a password down, as long as you keep it on your person _at all times_, just like you would a driver's license, a Social Security card, or anything else that is used as an identity-affirming object.
The problem is that there is no good way to invalidate the aforementioned forms of authentication. I can't say "my wallet is lost, and I want my Social Security card to no longer work." I can do so with passwords, but there isn't a single fast way of doing so, and I have to maintain a second backup list containing all the systems I have passwords to to ensure that I deauthorize the missing passwords.
If I have a single ID card, and I say "my ID card is missing", it's much easier to put a quick hold on it.
That doesn't even mean that people have to have a single identity, though. Keychains provide the same multiple-destination functionality I'm talking about (where you have multiple authentication tokens ("keys"), but require only a single action to authorize to all of the keychain), for instance, and don't allow people to map all of your identities to one point.
I am most decidedly not interested in paying a tithe
There's no need to do so.
The fees on certs for, say, web servers are justified by reason of verifying a RL ID/key mapping. There's no need for this in simply ensuring the trustworthiness of a key owner not being a spammer.
I mean, sure, it's possible to have commercial signers (among others). If Verisign wants to endorse your ID not being that of a spammer and charge $50 to do so, that's fine. But even in such a scenerio, I wouldn't expect signers to sign each email.
We have a society that just plain didn't develop around the idea that missteps are never forgotten.
Our laws, our social conventions, and our reactions to things are just not currently able to deal well with this idea of our life being scrawled out in permanent marker.
is it at all possible to write a distributed filesystem over the internet
Yes. There are a number of problems to deal with -- malicious people, authorities censoring data ("That's child porn!" "That's political dissent!" "That shows a woman out of a burka!").
There are two production-class distributed filesystems that I can think of, both from Carnegie Mellon University -- AFS and Coda (and Coda pushes the limits of the term "production-ready").
The only major successful attempt that I know of to do this Internet-wide also had a number of other goals (like anonymous publishing and retrieval, load distribution, and intelligent caching) and is known as Freenet.
I really don't see it as all that unreasonable. Companies go under, and expecting mp3.com to be around forever wasn't all that realistic. I really hate to say it, but *no* band in the world should have the only copy of its music in MP3 form on someone else's servers. They should definitely retain at *least* lossless digital recordings of their work. I think that it is reasonable to expect people to do that. In that case, the only thing lost was a couple of minutes ramming said lossless audio data through LAME or another mp3 compressor; not hard work.
Just view this as frosting on the cake -- for the few people out there that put their MP3s out and don't want to recompress them, they can now retrieve them if they want to pay someone a fee. For everyone else -- well, they're no worse off than if mp3.com just went under. They still have to recompress.
Caller ID suffers from most of the same flaws that SPF does (and is only marginally better than the latter system).
I find it phenomenally frusterating that the single company best positioned to provide the only real long-term fix -- a worldwide PKI/trust network via Outlook and Exchange -- is bound and determined to stick with another short-term hack.
Worse, this is a short-term hack that produces pain-in-the-ass side effects that will be with us for decades.
The "I hate passwords" attitude is not merely (or even primarily, IMHO) a function of users doing something wrong. It is a function of poorly designed security, or of security designed for a different environment being reused for current systems.
Passwords came into popularity a long time ago. Things that have changed since the introduction of the password:
* Many people have accounts on many, many systems (thanks to websites with accounts).
* Users on such systems may not be primarily benevolent -- on a UNIX box used by a small bunch of researchers in the early 80s, a password may be an acceptable barrier to anyone poking around. A password on eBay, on the other hand, may be of interest to a number of less savory characters.
* The ability to attack systems has significantly increased. Internet accessability means that remote, hard-to-trace attacks are more common. A brute force attack on a computing system physically isolated in a building may be simply infeasible, and choosing "cheese" as a password may be perfectly acceptable -- such a thing is no longer reasonable.
* Computing power is much greater now. Attacks on password hashes (including those sent over the network) are much more feasible. The relative strength of passwords to CPUs has decreased logarithmically.
* Many systems require passwords frequently. If you are a defense contracting employee, you might have only needed your password once when walking in the door in the morning and once after lunch. Now, corporate intranets have passwords, Yahoo has passwords, Slashdot has passwords, eBay has passwords, etc. Many of these require passwords multiple times a day (or, if they have an option to cache a password, do not have sufficient data about the client side to know how long it is safe to continue to cache the data).
* The demographic of password users has changed. Almost everyone has many passwords now -- not just a couple of engineers or scientists, or the occasional person with an ATM PIN.
What I Suspect Needs To Be Changed
A couple of things that probably need to change:
* It needs to be standard (and have a common interface for doing so) for users to be able to delegate a subset of their authority. Few systems currently have authorization systems smart enough to allow users to delegate chunks of their power to other users for a short term (and audit any moves). This needs to be simple, *easy*, and secure. If Sharon wants to let Bob purchase something online and charge it to her credit card account, she needs a quick and easy way to say "I authorize Bob to spend up to $500 in the next week and charge it to my credit card." That could be via her cell phone or on a computer. Most systems should have at least several forms of authorized actions that can be delegated to other users that require no more than entering a limit on the degree of the actions taken. A list of actions that other users have taken with that authorization should also be easily visible.
* Where feasible, passwords should be replaced by smartcard/PIN combinations. It's easier to remember a four-digit PIN than a long, secure password, and for anyone that doesn't have physical access to a user's smartcard, the strength of the token on the card is much greater than that of a password. Currently, this is particularly disasterous in the form of credit card information. Currently, many vendors store full credit card information used in purchases in databases. If any such database is compromised, authentication data providing full access to money accounts is granted the compromiser -- this is, frankly, insane. Credit card providers have one effective line of defense against a compromised card -- they do statistical analysis against purchases, which isn't the most reliable method of dealing with such attacks, and requires intense monitoring of anything users do -- producing a strong disincentive to provide users with privacy. (I realize that there are a few attempts at improving t
"Must fit on a standard console (24x80)" and "Use of more input elements per screen". Any decent TUI will allow you create multi-page interfaces.
Right -- I may not have used correct terminology, but this is what I intended to say. I used "per screen" rather than "per page".
"Familiarity to users". Not really a big deal. TUIs tend to be very simple, and a lot of things that work in [insert your favorite GUI] work in TUIs as well - tab to move between fields, there's a standardized help key, etc.
True...but I'd still argue that Windows is a more standardized GUI environment than any TUI I can think of. In a TUI, what is the difference between BS and DEL? How, if there is any such method, do I transfer textual data from text field to text field? If the TUI supports text selection in text fields, how does it operate, and what keys control it? How do I move from the beginning to the end of the line or delete the word to the right or left of my cursor?
There are plenty of systems out there that let you work on multiple sessions through a single screen.
I use screen and XFree86 myself, but there is no guarantee of such functionality when using a typical TUI -- there are lots of terminals sitting about. I *know* that I have such functionality in a Windows-based GUI.
I can't argue about the "able to display images" part though.
After all that, I figured you were going to pull out aalib as an example.:-)
Now, keep in mind -- all this doesn't necessarily mean that I think that GUIs are the way to go. I think that for POS, for equipment-control, for data-entry, and for a lot of kiosk applications, TUIs are the way to go. Heck, I do all my file management on a CLI, as well as most of my work (well, aside from most of my web browsing). I wasn't intending to argue that GUIs were unilaterally superior to TUIs -- just to point out the advantages that I feel that GUIs have over TUIs. TUIs have their own (sizeable) set of advantages -- I just didn't list them, since they didn't seem all that germane to the thread. It certainly wasn't intended to be bashing the gurus of the amber screen.
As a matter of fact, I think that the recent debacle on Slashdot about National City's CMU ATM is a great example. It used to be an old but reliable TUI system. Apparently, it didn't look new and sexy enough (and as financial services people on Slashdot pointed out, failed to allow the pushing of multimedia ads to users). It was replaced with an WinXP-based (hey, easy to produce a GUI with) touchscreen kiosk. It crashed at some point, dumping the interface out to Windows, which gleeful students happily tinkered with with, eventually ending up playing Beethoven on loop at the maximum sound level the poor kiosk could put out. If National City had simply stuck with their simple, reliable TUI, they wouldn't have had people monkeying around with the innards of their cash-dispensing systems.
Christ, man. You may be young, but surely you've run into more advanced TUIs than "enter everything as a command"?
You'd have a screen with a field for profit and parts, and a menu for each of the choices. Look at menuconfig, one of the interfaces used to configure the Linux kernel for a build, for an example. CLI vs menu-based is different from CLI vs GUI. The problem of "displaying all the choices available so that the user doesn't need to remember the sequences necessary to invoke an action" is an issue between menu-based and non-menu-based UIs, not TUI/GUIs. It's even possible to have a GUI that isn't menu-based -- imagine a GUI that used, say, gestures for commands (as a few programs and games do today). Arx Fatalis, Black & White, Opera, etc.
The main real benefits of a GUI over a TUI that I can think of are:
* Use of images. TUIs generally need to fit on a standard console -- 24x80 -- and can generally rely on only ASCII characters, and perhaps bold and a few colors. A GUI can display full-color inline images.
* Use of more input elements per screen. A GUI can make finer-grained use of the display for things like boxes and dividing lines to more clearly mark out where input is going. Since TUIs were designed in the days when displays were quite small, the 24x80 size is really ridiculous in this day of 19" CRTs, but most GUIs allow effective use of all the screen space.
* More effective use of the mouse as an input device. The mouse is pretty good for doing things like selecting an arbitrary subset of items in a group (such as with a window full of selectable icons), or quickly inputting approximate values (such as with a slider). I think that the mouse tends to be overused in a lot of places, that for a lot of applications keyboard input to a TUI is faster and more accurate. The mouse is limited to being used in a very poor resolution, normally.
* Familiarity to users of other GUIs. The windowed GUI is a common input paradigm to almost all computer users today. There are a number of complex operations (like addition and removal of an element to a discontiguous group of selected elements via control-clicking) that have already been taught users of Windows. Software using the Windows interface can expect users to know how to do these actions already, instead of having to instruct them in what to do. TUIs never enjoyed widespread conventions of the sort.
* Windowed interfaces. The windowed interface paradigm is generally a very powerful interface mechanism, and one that can be taken advantage of in a GUI. If a computer is single-purpose and running only a single program, this may not be such a benefit, but on computers that may run many programs, having the ability for a user to do windowed work is a great benefit.
* Non-ASCII charset support. While there is support for non-ASCII characters on text terminals (I suspect there is even UTF-8 and kanji support), most modern GUI environments provide good built-in support for rendering international characters -- TUI environments may not. This is not a hard constraints on TUIs, but given the existing TUI/GUI environments around, it is a practical advantage.
SCO's license doesn't grant you a blanket indemnity -- just a guarantee that *they* won't sue you.
PJ is selling insurance that covers *any* infractions.
If a company has a choice between purchasing real insurance from PJ or "insurance" from SCO, they're almost certain to do better with PJ.
'course, I think the whole set of concerns is a lot of baloney -- open source types tend to be pretty careful about licenses -- but it's not as if you can claim that PJ has falsely inflated her product's merits -- she's been saying the same thing for quite a long time.:-)
I wonder if number portability requirements will ever extend to e-mail addresses;-).
It's easy to do that now -- use foo.bar.baz@bobsemailredirect.com. The telcos have the benefit of being large and unlikely to vanish.
If a bank or other large, "permanent" business started providing such email redirection service, it might be worthwhile -- a permanency guarantee can currently only be obtained by purchasing your own domain (and either purchasing mail server management services or running your own -- too much hassle for many people). The problem is that people also have strong privacy constraints on their email.
Bell South was one of the few telcos to provide a flat-rate ISDN option back in the day when ISDN was the best whiz-bang technology available for home Internet access.
Slashdot Mirror
I don't agree with the point about network connections at all. Most homes that contain a console contain a PC for web-browsing and work - the issue is whether the PC is actually used for games. Two of the three consoles in the current generation have decent network support.
Being able to purchase service for a console is different from that service being widely used (and possible for a developer to effectively rely upon it being there). I know many people that have Internet access, but nobody that has XBox Live or similar service. A monthly fee for gaming doesn't go over very well with many people.
I think console keyboards will become standard for the games that "need them". Mice probably aren't all that far behind.
Maybe. A strong benefit of consoles is that a developer can rely on hardware just "being there". In console history, games that have relied on additional nonstandard hardware have, with only a few exceptions, not done very well. They are generally forced to bundle the peripheral with their game, which drives up their cost. I do not think that any of the console providers are going to start bundling a keyboard as standard -- initial cost is a serious factor in which system people choose, and none of the vendors want to drive it up too far. Same thing for mice. People have tried playing with the idea of additional periperals since at least the NES (I remember ROBBY the robot or whatever the thing was called), and it just hasn't done well.
The vast majority of fpses are based around a several year old engine (quake 3) which was, quite frankly, over-rated from day 1.
I'm curious as to why you're saying this. I admit that I haven't done modding or seriously played around with the Q3 engine, but just from playing Q3A, I've been reasonably impressed. It's quite fast. It supports curves with dynamic polygon reduction. It provides convincing (IMHO) volumetric fogging -- the levels that vanished off into a colored fog in Q3A were quite neat, IMHO. It provides portal support. Id has a tradition of good network engines, though I confess that I haven't done a careful comparison to other modern systems. What about it do you not like?
No -- you can have many root trust providers. The leaf nodes of the trust network would be users -- each user would sign their emails, not each server signing emails sent through them. You would use transitive trust, as you've pointed out. The task of a root trust provider can be very simple -- there might be, say, one that does nothing but sign four certs -- say one for an association that signs a cert for all registered businesses in the United States, one that does so for an association that signs a cert for all registered businesses in Japan, etc. Such a root cert provider requires a minimal amount of work. Such an association would sign certs for businesses belonging to it -- it's only to such an association's benefit to do so. Each business has no reason not to sign certs for its employees (and ensure that said employees do not spam). If employees *do* start spamming, the business loses a bit of trust, the association loses a bit less, and the root cert provider a bit less.
Elements of a trust network can *always* charge for service -- even today, I can walk into a GPG key signing party and pay someone to take the trouble to verify my information and sign my key. There are, however, many people who will sign my key without requiring me to pay money -- the noncommercial providers. Such a system absolutely does not require fees per-user or per-email to work.
So, in my opinion, there's no mystery -- PC games will go down in price quicker because PC games don't sell as well as console games.
That doesn't seem quite right. There are two cases where the publisher is going to reduce the price of their product. The first is when they simply misjudge the demand for their product, and realize that they cannot sell it at their initial price (as happened recently with the N-Gage). The second is when the publisher wants to benefit from price discrimination -- first they sell the game for $50 to all the people that are willing to pay $50 for itimmediately, then for $40 for the people that are willing to pay $40 for it, and so forth. A publisher will reduce their price more quickly if there is a broad spread of users willing to buy a product at different price points.
Simply not selling as well, volume of sales, doesn't directly relate to either of these two things.
Price is one of the few areas left in which PC games can compete for a mainstream audience with the consoles.
I disagree. I think that both the PC and the console have major advantages over each other that are good for various kinds of game.
The console:
* Number of users. There are more people out there with consoles than high-end gaming computer systems.
* Identical hardware. This significantly reduces development cost and code complexity, since you don't have to deal with making your effects and graphic systems scale to various systems or work at different resolutions -- if it works on one console, it works on all consoles of that brand.
* Control over the entire machine. PC operating systems like Windows (and mainstream variants of Linux) are not real-time OSes. A console can *ensure* that a game gets the cycles it needs each frame -- on a computer system, it's a fair bet that plenty of people are running a software package in the background that occasionally grabs a chunk of CPU cycles, be it a virus scanner, mail client/notifier, weather monitor, or NTP client. It's also easier to debug problems in an isolated environment. It also means that there are fewer variables that will result in Joe User saying "this game doesn't work on my computer" and returing it to EBGames or whatever.
* Reduced piracy. Pirating games for modern consoles, from a pragmatic standpoint, requires hardware modifications. Many people are quite happy downloading a modified CD image of a game to their computer, but are less comfortable mod-chipping their console. I've seen estimates of piracy vary a lot depending upon the particular game, but I've seen claims of upwards of 80% piracy. Now, admittedly, not all those were sales that were lost, but it's also true that some were. If you can make twice the sales on a console simply due to reduced piracy, there's a pretty strong incentive to choose the console (at least as a primary target).
* Gun interfaces. Consoles are pretty much the only game in town for gun peripherals.
* Initial hardware investment. A decent, midrange gaming PC still can be expected to cost upwards of $1000 (assuming no cannibalism of hardware). A console costs below $300.
* Easy installation. PC game installation and configuration is more complex and intimidating than console game installation and configuration.
* Presence of a good general-purpose gaming controller. For most types of games, the typical console gamepad is easier to use and hold, and is better technically suited to games (in that an unlimited number of buttons can be detected as down at once).
Advantages of the PC
* A broader range of input peripherals. You can get authentic fighter jet joysticks, pedals, steering wheels, gamepads of every variety, weird 3d input devices and weird throttle devices.
* Much more memory. Consoles are incredibly RAM-starved. This is visible not only in loading times, but in texture resolution and in less visible loss of functionality. Give a clever programmer some RAM to work with to precompute something, and he can usually whip up some amazing stuff. Less RAM means less wiggle room.
* A large, fast, writeable storage device. Consoles are limited to slow and small memcards (except for the XBox -- and the hard drive is going away in the next generation of the XBox). There are a lot of nice things you can do with mroe storage space -- store temp data, write data files of unbounded size (instead of ensuring that each saved game always uses under 192KB or whatever size limit is chosen). Fast seeks mean that programmers have to hassle less with clever loading of resources on the PC.
* Higher resolutions. This is, IMHO, actually less of an issue in the 3d world, since most 3d games are still playable at lower resolutions (if less attractive). For 2d games, it can be very annoying to have a smaller visible area, with fewer sprites.
* Much more common network connection. It's r
I can't figure out why so many Slashdotters seem stuck on the merits of this idea.
Here are a couple of reasons why this is a bad idea:
* Complete lack of forward-compatibility with hardware (huge -- effectively kills the idea, and the reason why this scheme works in the console world with a standard set of hardware but not in the computer world).
* Forced rebooting and no other apps running
* Poor access times
* No patches
Basically, even if you overcame all the obstacles, you'd have little more than an expensive console (abeit with a lot of RAM), but without the standardized hardware and input devices that benefit console developers.
The benefits of the PC are pretty much different from those of the console. Trying to turn a PC into a poor copy of a console is just a bad idea. Leverage the strengths of the PC -- more memory, big, fast writeable storage devices, keyboard and mouse input devices (many buttons, good text-input capabilities, rapid and precise aiming), very commonly available network access, forwards compatibility, patchability, game extensibility, good toolkits -- widget sets and the like -- for producing things like editors.
For those not familiar with precompiled headers, you can basically look forward to *much* faster code compilation, especially with C++.
Precompiled headers are disabled by default in this release.
Right -- you have to "live on top of" the base Freenet, having a utility that re-inserts your data when it vanishes.
The problem is that, if you want to allow people to add data to your system, you have to solve the problem of determining who can do so. If you include everyone, then people will consume space with data that isn't of general interest, but not donate space -- and people can take down their systems at any time, so if you don't allow data to drop, you have a very tough constraint of finding users that do not remove their systems from the network.
Yes, you're right -- it isn't perfectly intutitive. I do, however, play games that use the mouse wheel to provide a third degree of freedom (quite common in 3d RTSes to control camera height, for instance), and don't have much difficulty adapting to it, so I don't think it's an unreasonable proposition.
It isn't necessarily tied to GUIs, no.
The problem is that generally GUI kiosk systems have a large, complex Windows backend. They don't have to do so, but most do, and some of the GUI benefits I listed depend on this.
If you're going to have a Windows core, unless you want to do *serious* modification work on the system, you're going to still have Explorer and friends lying around on your system. You have a lot of complexity coming with your system that you may not want.
While the "obvious" method for building GUI consoles on Windows (and even Linux, to a much smaller degree, since it's much easier to lock down a Linux GUI -- if there's no window managers or anything running, it's awfully hard to do anything) makes a kiosk application crash dump a user to a position of control over the system, text-based systems that I can think of in common use do *not* do so. Oh, there's probably some DOS-based system somewhere that would dump someone to a DOS prompt, but it's much more feasible to build a text-based system from scratch.
I've heard the "single sign-on/single authentication token/one ring to rule them all/whatever" spiel before. However, this is not an improvement by any means - it just makes it _easier_, not harder, for someone to impersonate you.
I disagree.
In an ideal world, where people can deal with an arbitrary number of passwords, then yes, that might be good. The problem is that people have *so many* passwords today that they *don't* manage them well -- they write them down, or store them on a computer, or use the same password in multiple places. So the problem of having a single point of failure is *already here*. There is some marginal benefit to the fact that people use different methods of storing their passwords, but the poor nature of the storage tends to, IMHO, eliminate most of that advantage.
If you have a single identifying token that electronic devices everywhere can use to know you, how many things does a potential no-goodnik need to become, for all intents and purposes, you?
If your password list or single password becomes such a single token, you're no better off.
And if they choose, they can then make it so you are not.
I disagree. With such a system, it's more feasible to have stronger policy measures for authentication -- where you can deauthenticate a lost card fairly easily (if you have only one "secret" to remember, it doesn't have to be something poorly chosen, like your mother's maiden name, or even something stored in the token itself, so that a thief could not necessarily separate you from your card).
But beating the "single sign-on! universal identity!" drum is not the answer - it makes it easier to steal your identity, not to mention if you're privacy-paranoid, it makes it easy for your movements to be tracked by one or more TLOs (three-letter organizations).
Single sign-on is different from single externally-exposed identity. As I mentioned in my earlier response to another, keychains already provide a single sign-on with multiple identities.
Also, if users would get over the urge to write passwords down and leave them laying around - there's nothing wrong (IMO) with writing a password down, as long as you keep it on your person _at all times_, just like you would a driver's license, a Social Security card, or anything else that is used as an identity-affirming object.
The problem is that there is no good way to invalidate the aforementioned forms of authentication. I can't say "my wallet is lost, and I want my Social Security card to no longer work." I can do so with passwords, but there isn't a single fast way of doing so, and I have to maintain a second backup list containing all the systems I have passwords to to ensure that I deauthorize the missing passwords.
If I have a single ID card, and I say "my ID card is missing", it's much easier to put a quick hold on it.
That doesn't even mean that people have to have a single identity, though. Keychains provide the same multiple-destination functionality I'm talking about (where you have multiple authentication tokens ("keys"), but require only a single action to authorize to all of the keychain), for instance, and don't allow people to map all of your identities to one point.
I am most decidedly not interested in paying a tithe
There's no need to do so.
The fees on certs for, say, web servers are justified by reason of verifying a RL ID/key mapping. There's no need for this in simply ensuring the trustworthiness of a key owner not being a spammer.
I mean, sure, it's possible to have commercial signers (among others). If Verisign wants to endorse your ID not being that of a spammer and charge $50 to do so, that's fine. But even in such a scenerio, I wouldn't expect signers to sign each email.
While that's very powerful, it can be unpleasant.
We have a society that just plain didn't develop around the idea that missteps are never forgotten.
Our laws, our social conventions, and our reactions to things are just not currently able to deal well with this idea of our life being scrawled out in permanent marker.
Or, how about Jonne Valtonen, better known (one upon a time) as Purple Motion of Future Crew?
You have to wonder why anyone with a name and reputation like Purple Motion would give it up. It just seems a collossal branding misstep.
0x0d0a has written many lines of code while listening to Purple Motion's work.
is it at all possible to write a distributed filesystem over the internet
Yes. There are a number of problems to deal with -- malicious people, authorities censoring data ("That's child porn!" "That's political dissent!" "That shows a woman out of a burka!").
There are two production-class distributed filesystems that I can think of, both from Carnegie Mellon University -- AFS and Coda (and Coda pushes the limits of the term "production-ready").
The only major successful attempt that I know of to do this Internet-wide also had a number of other goals (like anonymous publishing and retrieval, load distribution, and intelligent caching) and is known as Freenet.
Y'know...
I really don't see it as all that unreasonable. Companies go under, and expecting mp3.com to be around forever wasn't all that realistic. I really hate to say it, but *no* band in the world should have the only copy of its music in MP3 form on someone else's servers. They should definitely retain at *least* lossless digital recordings of their work. I think that it is reasonable to expect people to do that. In that case, the only thing lost was a couple of minutes ramming said lossless audio data through LAME or another mp3 compressor; not hard work.
Just view this as frosting on the cake -- for the few people out there that put their MP3s out and don't want to recompress them, they can now retrieve them if they want to pay someone a fee. For everyone else -- well, they're no worse off than if mp3.com just went under. They still have to recompress.
Caller ID suffers from most of the same flaws that SPF does (and is only marginally better than the latter system).
I find it phenomenally frusterating that the single company best positioned to provide the only real long-term fix -- a worldwide PKI/trust network via Outlook and Exchange -- is bound and determined to stick with another short-term hack.
Worse, this is a short-term hack that produces pain-in-the-ass side effects that will be with us for decades.
The "I hate passwords" attitude is not merely (or even primarily, IMHO) a function of users doing something wrong. It is a function of poorly designed security, or of security designed for a different environment being reused for current systems.
Passwords came into popularity a long time ago. Things that have changed since the introduction of the password:
* Many people have accounts on many, many systems (thanks to websites with accounts).
* Users on such systems may not be primarily benevolent -- on a UNIX box used by a small bunch of researchers in the early 80s, a password may be an acceptable barrier to anyone poking around. A password on eBay, on the other hand, may be of interest to a number of less savory characters.
* The ability to attack systems has significantly increased. Internet accessability means that remote, hard-to-trace attacks are more common. A brute force attack on a computing system physically isolated in a building may be simply infeasible, and choosing "cheese" as a password may be perfectly acceptable -- such a thing is no longer reasonable.
* Computing power is much greater now. Attacks on password hashes (including those sent over the network) are much more feasible. The relative strength of passwords to CPUs has decreased logarithmically.
* Many systems require passwords frequently. If you are a defense contracting employee, you might have only needed your password once when walking in the door in the morning and once after lunch. Now, corporate intranets have passwords, Yahoo has passwords, Slashdot has passwords, eBay has passwords, etc. Many of these require passwords multiple times a day (or, if they have an option to cache a password, do not have sufficient data about the client side to know how long it is safe to continue to cache the data).
* The demographic of password users has changed. Almost everyone has many passwords now -- not just a couple of engineers or scientists, or the occasional person with an ATM PIN.
What I Suspect Needs To Be Changed
A couple of things that probably need to change:
* It needs to be standard (and have a common interface for doing so) for users to be able to delegate a subset of their authority. Few systems currently have authorization systems smart enough to allow users to delegate chunks of their power to other users for a short term (and audit any moves). This needs to be simple, *easy*, and secure. If Sharon wants to let Bob purchase something online and charge it to her credit card account, she needs a quick and easy way to say "I authorize Bob to spend up to $500 in the next week and charge it to my credit card." That could be via her cell phone or on a computer. Most systems should have at least several forms of authorized actions that can be delegated to other users that require no more than entering a limit on the degree of the actions taken. A list of actions that other users have taken with that authorization should also be easily visible.
* Where feasible, passwords should be replaced by smartcard/PIN combinations. It's easier to remember a four-digit PIN than a long, secure password, and for anyone that doesn't have physical access to a user's smartcard, the strength of the token on the card is much greater than that of a password. Currently, this is particularly disasterous in the form of credit card information. Currently, many vendors store full credit card information used in purchases in databases. If any such database is compromised, authentication data providing full access to money accounts is granted the compromiser -- this is, frankly, insane. Credit card providers have one effective line of defense against a compromised card -- they do statistical analysis against purchases, which isn't the most reliable method of dealing with such attacks, and requires intense monitoring of anything users do -- producing a strong disincentive to provide users with privacy. (I realize that there are a few attempts at improving t
"Must fit on a standard console (24x80)" and "Use of more input elements per screen". Any decent TUI will allow you create multi-page interfaces.
:-)
Right -- I may not have used correct terminology, but this is what I intended to say. I used "per screen" rather than "per page".
"Familiarity to users". Not really a big deal. TUIs tend to be very simple, and a lot of things that work in [insert your favorite GUI] work in TUIs as well - tab to move between fields, there's a standardized help key, etc.
True...but I'd still argue that Windows is a more standardized GUI environment than any TUI I can think of. In a TUI, what is the difference between BS and DEL? How, if there is any such method, do I transfer textual data from text field to text field? If the TUI supports text selection in text fields, how does it operate, and what keys control it? How do I move from the beginning to the end of the line or delete the word to the right or left of my cursor?
There are plenty of systems out there that let you work on multiple sessions through a single screen.
I use screen and XFree86 myself, but there is no guarantee of such functionality when using a typical TUI -- there are lots of terminals sitting about. I *know* that I have such functionality in a Windows-based GUI.
I can't argue about the "able to display images" part though.
After all that, I figured you were going to pull out aalib as an example.
Now, keep in mind -- all this doesn't necessarily mean that I think that GUIs are the way to go. I think that for POS, for equipment-control, for data-entry, and for a lot of kiosk applications, TUIs are the way to go. Heck, I do all my file management on a CLI, as well as most of my work (well, aside from most of my web browsing). I wasn't intending to argue that GUIs were unilaterally superior to TUIs -- just to point out the advantages that I feel that GUIs have over TUIs. TUIs have their own (sizeable) set of advantages -- I just didn't list them, since they didn't seem all that germane to the thread. It certainly wasn't intended to be bashing the gurus of the amber screen.
As a matter of fact, I think that the recent debacle on Slashdot about National City's CMU ATM is a great example. It used to be an old but reliable TUI system. Apparently, it didn't look new and sexy enough (and as financial services people on Slashdot pointed out, failed to allow the pushing of multimedia ads to users). It was replaced with an WinXP-based (hey, easy to produce a GUI with) touchscreen kiosk. It crashed at some point, dumping the interface out to Windows, which gleeful students happily tinkered with with, eventually ending up playing Beethoven on loop at the maximum sound level the poor kiosk could put out. If National City had simply stuck with their simple, reliable TUI, they wouldn't have had people monkeying around with the innards of their cash-dispensing systems.
There are pressable and swivelable joysticks, though, either of which would give an additional degree of freedom.
Christ, man. You may be young, but surely you've run into more advanced TUIs than "enter everything as a command"?
You'd have a screen with a field for profit and parts, and a menu for each of the choices. Look at menuconfig, one of the interfaces used to configure the Linux kernel for a build, for an example. CLI vs menu-based is different from CLI vs GUI. The problem of "displaying all the choices available so that the user doesn't need to remember the sequences necessary to invoke an action" is an issue between menu-based and non-menu-based UIs, not TUI/GUIs. It's even possible to have a GUI that isn't menu-based -- imagine a GUI that used, say, gestures for commands (as a few programs and games do today). Arx Fatalis, Black & White, Opera, etc.
The main real benefits of a GUI over a TUI that I can think of are:
* Use of images. TUIs generally need to fit on a standard console -- 24x80 -- and can generally rely on only ASCII characters, and perhaps bold and a few colors. A GUI can display full-color inline images.
* Use of more input elements per screen. A GUI can make finer-grained use of the display for things like boxes and dividing lines to more clearly mark out where input is going. Since TUIs were designed in the days when displays were quite small, the 24x80 size is really ridiculous in this day of 19" CRTs, but most GUIs allow effective use of all the screen space.
* More effective use of the mouse as an input device. The mouse is pretty good for doing things like selecting an arbitrary subset of items in a group (such as with a window full of selectable icons), or quickly inputting approximate values (such as with a slider). I think that the mouse tends to be overused in a lot of places, that for a lot of applications keyboard input to a TUI is faster and more accurate. The mouse is limited to being used in a very poor resolution, normally.
* Familiarity to users of other GUIs. The windowed GUI is a common input paradigm to almost all computer users today. There are a number of complex operations (like addition and removal of an element to a discontiguous group of selected elements via control-clicking) that have already been taught users of Windows. Software using the Windows interface can expect users to know how to do these actions already, instead of having to instruct them in what to do. TUIs never enjoyed widespread conventions of the sort.
* Windowed interfaces. The windowed interface paradigm is generally a very powerful interface mechanism, and one that can be taken advantage of in a GUI. If a computer is single-purpose and running only a single program, this may not be such a benefit, but on computers that may run many programs, having the ability for a user to do windowed work is a great benefit.
* Non-ASCII charset support. While there is support for non-ASCII characters on text terminals (I suspect there is even UTF-8 and kanji support), most modern GUI environments provide good built-in support for rendering international characters -- TUI environments may not. This is not a hard constraints on TUIs, but given the existing TUI/GUI environments around, it is a practical advantage.
SCO's license doesn't grant you a blanket indemnity -- just a guarantee that *they* won't sue you.
:-)
PJ is selling insurance that covers *any* infractions.
If a company has a choice between purchasing real insurance from PJ or "insurance" from SCO, they're almost certain to do better with PJ.
'course, I think the whole set of concerns is a lot of baloney -- open source types tend to be pretty careful about licenses -- but it's not as if you can claim that PJ has falsely inflated her product's merits -- she's been saying the same thing for quite a long time.
Hell I even re-download large files I *know* are on my system somewhere, just because it's easier to find on the web.
I remember back to the days when self-restraint was considered par for the course for users of network services.
I wonder if number portability requirements will ever extend to e-mail addresses ;-).
It's easy to do that now -- use foo.bar.baz@bobsemailredirect.com. The telcos have the benefit of being large and unlikely to vanish.
If a bank or other large, "permanent" business started providing such email redirection service, it might be worthwhile -- a permanency guarantee can currently only be obtained by purchasing your own domain (and either purchasing mail server management services or running your own -- too much hassle for many people). The problem is that people also have strong privacy constraints on their email.
Bell South was one of the few telcos to provide a flat-rate ISDN option back in the day when ISDN was the best whiz-bang technology available for home Internet access.