As well as providing decent tools for people to create content, there also needs to be a mechanism to promote the good content.
Most people won't want to create, only consume. Most people don't have the time or desier to trawl through the dross made my talentless or inexperienced people - they just want the good stuff.
Other people enjoy the hunt of looking through arbitrary stuff and rating. They need to be utilised.
Google always comes up with good ideas and has the hardware and the sheer number of users to make it into a somewhat useful beta product, but the user interface and the finish almost always is so bad that the software actually sucks.
Do you have an example?
My opinion:
- Google search - a usability joy, introduced at a time when other search companies were ruining their interface with clutter.
- GMail - webmail was all but unusable before GMail. Others have caught up now, but GMail still stands up well
- Google Maps - again, revolutionary when it was introduced
- Google Docs - fettered by the lack of right-click, but definitely more than adequate for its purpose.
The problem is that the human mind's fundamental structure has not changed significantly in thousands of years, because evolution is a slow process and adding new features takes aeons.
Fortunately one of the features our brain evolved is rapid adaptability. It's turned out to be a very useful survival strategy.
The complaints about Wave aren't due to being unfamiliar with the concept--real-time chatting is hardly a paradigm-shifting or even a new technology
The funny thing is that after I'd watched the video all those weeks ago, if you'd asked me to summarise, the IM aspect would probably be the last thing I mentioned.
What's new is the way your "conversation" is a kind of shared, structured document, with a revision history. It's almost like having a conversation through the medium of Subversion commits.
The fact that you happen to be able to do it in "real time" is almost incidental. Bear in mind, if you're not logged in and looking at the wave as other people contribute, their posts will still be there when you do look.
I imagine that a lot of the time, we won't be having real-time conversations in Wave. We'll be doing something closer to email, except with a better approach to threading and collaboration.
Their "I'm having a barbeque, please edit this list to add your name if you're coming" from the demo is great example.
After watching the demo, a lot of people were commenting that the major problem is that it runs counter to how the brain operates...we aren't designed to heavily multitask.
The absolute best way to get real collaboration done is to get everyone into the same room together.
If you do that, it's possible for everyone to talk at once, and of course, if they do that, it doesn't work. You have to take it in turns to talk and listen. Sometimes one person takes the floor. Sometimes you formally break out into smaller groups. Sometimes you get something agreed during an informal chat with a couple of people during a coffee break.
The Wave demo showed that the *technology* allows everyone to talk at once. That's useful, but users are going to have to learn when it's appropriate to stop typing and start reading.
It looks like you could achieve something similar to break-away groups in Wave, by having subgroups spread each other to different parts of a wave, where they can have an isolated chat.
It seems to me, and again I didn't RTFA, that Wave will only be useful when people start writing decent robots and applications to sit on top of it.
This was the purpose of the Developer Preview. We should expect there to be lots of robots and gadgets available already, build by developers who were on the preview rollout.
Does one user need to talk to twelve different people at once? Hell no.
Have you never been to a meeting with twelve attendees? (I'm happy for you).
Those can work because there are social conventions in place as to who can talk when. I imagine Wave users will need to establish similar conventions.
From what I read, it displays data as you're typing it out, rather than after you "post"
I could see a lot of problems around this.
Because I work with a geographically diverse team, I spend a lot of time on IM. Seeing what they type as they type would really increase the fluency of those conversations.
You get long period when you don't know whether someone is typing, thinking or have wondered off.
You get conversations that go out of sync -- e.g. person A changes the topic, then person B hits enter on their long response to the previous topic.
I think the see-as-they-type feature has more benefits than problems.
Why run 2 machines? Its going to suck if you buy 1000 machines for peggle and 1000 machines for crysis and 1500 people want to play crysis and 20 want to play peggle level games.
Since they're not going to ghost a machine to prep it for every player, i think their only logical choice is to install every game on every machine.
Clearly, you wouldn't "install" a game on any individual server.
You'd have the game files on a big fileserver (SAN, whatever). You'd have the same software on every single game server, and the supervisor node that assigns players to hardware would know the hardware specs of each server.
Then you'd use a best-fit algorithm to decide which is the most appropriate place to host the requested game. One server could host one game of Crysis, or 5 games of Bioshock, or 20 games of Peggle. Or 2 games of Bioshock and 12 games of Peggle.
Just an example.
If they expect me to pay $5/month to play only crysis, forget it.
Yet it's common to pay $60 to play a game for less than a month (people who buy a console game, finish it quickly, and don't bother trading it).
I've often paid over $5 for XBLA games that I've finished in a few days and will never return to.
Do they need to buy 1 machine for every person? Absolutely. If they don't, they run a risk.
If all their users play the big games simultaneously, they're doomed. I personally don't think they'll get that kind of peak. Some people like to play at weekends, some before dinner, some after their SO has gone to bed.
Likely they're going to charge $19.99 or $29.99/month for this.
Source? I'm guessing you have no idea what they're going to charge. We don't know whether they'll charge by the hour or by the month, whether you'll buy a package or an individual game, any of that. My guess is it'll be a combination of these.
Which leads me to another thought. With pricing, you can manage demand. Not enough capacity for everyone to play Crysis? Well, Wolfenstein costs $2/month and Crysis costs $5/month. Watch the usage patterns change.
No , that would be app/OS + VM + OS + hardware. The host OS doesn't just conveniently vanish, its still using up CPU cycles.
While you can run VMs on a desktop OS (or indeed on a server), the real fun comes when you run it on a platform that's been custom designed for the purpose. For example, VMWare ESX. This is effectively a kernel with VMWare built into it. Sure it's an OS, but it's a very, very light OS.
"If the hardware fails all you have to do is move the VM "image" to new hardware."
How many apps are hardware dependent these days? All OS's have hardware abstractions , eg unix/dev directory. So whats different between doing that and just moving the app over to another server?
The difference is that you can do it without stopping the application.
Imagine you're paying me to host a Linux system for you. I could be running that as a VM on box a. While you're logged in and actively using the system, I could move the VM to box b, without you noticing. You might spot a momentary pause, but nothing more.
*That's* how it's different from moving the app over to another server.
What you have might not be a cloud, but what Amazon offers probably is.
You provision an EC2 instance, and it's there. You don't know where it is, and you don't care. There's just a cloud of VMs, yours is in there somewhere, and you can connect to it to use it.
Dynamically, Amazon might choose to move your VM to another physical host for all kinds of reasons -- an unplanned physical failure, a planned power-down, some algorithm that decides they could meet your needs more cheaply at a different location, etc. And you wouldn't notice.
When did installing multiple apps on 1 server go out of fashion?
When it became clear it's a management headache.
"Hi it's ops. You know your foo server sits on the same box as the bar server? Yeah, well the bar guys have found out they need a kernel with a higher filehandle limit, so we're going to be rebooting that box. You'll need to tell your users about the outage. Oh, and you'd better have QA test the foo server with the new kernel too."
So use 1 server and have 10 client logins on it FFS.
1 client wants RHEL 4. 1 client wants RHEL 5. 2 clients want Windows Server, both want a weekly reboot, but during different maintenance slots. 2 clients want stable Debian, but one wants a weekly 'apt-get dist-upgrade', the other wants it monthly... etc.
Give each one a VM, and you can deliver all this on one physical machine very, very easily.
I didn't know that an IRC message was a persistent object that would be around forever.
I didn't know that IRC users could retrospectively edit messages that had already been sent. Nor that IRC allowed you to navigate through the history of changes to a message.
I didn't know that IRC messages were arranged in a hierarchical thread structure.
With no market for PC graphics cards or even for cards in new consoles then who pays ATI / Nvidia to continue developing new technology?
Firstly, the servers for cloud gaming services will need loads of GPUs, so demand for new graphics chips would not diminish.
Secondly, this isn't going to obsolete locally hosted gaming. Many people will still want to run ninja gaming rigs; many people will want to play on traditional consoles. Cloud gaming may poach some customers away from local gaming, and it may attract people who could never be bothered with the hassles of local gaming. But it won't kill local gaming.
There are plenty of reasons why you might choose to host two services on two different machines, even if one machine would have enought power. Things like being able to take one down without affecting the other.
VMs let you keep some of that model, while consolidating down to less hardware.
Plus it makes deployment easy: get your system how you want it, then save it as an image. Now you can clone it as much as you like. Now that there are OSS VM hosts, the commercial virtualisation companies are concentrating their efforts on providing more and more powerful tools for creating, managing and deploying images.
Especially cool, is VMs with high availability. Two physical machines, in separate datacentres, each running the same VM in lockstep. Pull the power cord on one, and the user will notice nothing but a momentary pause as the secondary VM takes over.
Slashdot Mirror
As well as providing decent tools for people to create content, there also needs to be a mechanism to promote the good content.
Most people won't want to create, only consume. Most people don't have the time or desier to trawl through the dross made my talentless or inexperienced people - they just want the good stuff.
Other people enjoy the hunt of looking through arbitrary stuff and rating. They need to be utilised.
Google always comes up with good ideas and has the hardware and the sheer number of users to make it into a somewhat useful beta product, but the user interface and the finish almost always is so bad that the software actually sucks.
Do you have an example?
My opinion:
- Google search - a usability joy, introduced at a time when other search companies were ruining their interface with clutter.
- GMail - webmail was all but unusable before GMail. Others have caught up now, but GMail still stands up well
- Google Maps - again, revolutionary when it was introduced
- Google Docs - fettered by the lack of right-click, but definitely more than adequate for its purpose.
The straw men: all those dozens of people typing at me all at once! Who are these dozens of people and why would I be watching their typing?
Exactly. I don't anticipate taking part in waves with dozens of strangers all online at once.
I anticipate waves with up to 20 friends or colleagues, only a couple of whom would be online at any one time.
The problem is that the human mind's fundamental structure has not changed significantly in thousands of years, because evolution is a slow process and adding new features takes aeons.
Fortunately one of the features our brain evolved is rapid adaptability. It's turned out to be a very useful survival strategy.
No idea what I would do without it.
rsh over stunnel?
The complaints about Wave aren't due to being unfamiliar with the concept--real-time chatting is hardly a paradigm-shifting or even a new technology
The funny thing is that after I'd watched the video all those weeks ago, if you'd asked me to summarise, the IM aspect would probably be the last thing I mentioned.
What's new is the way your "conversation" is a kind of shared, structured document, with a revision history. It's almost like having a conversation through the medium of Subversion commits.
The fact that you happen to be able to do it in "real time" is almost incidental. Bear in mind, if you're not logged in and looking at the wave as other people contribute, their posts will still be there when you do look.
I imagine that a lot of the time, we won't be having real-time conversations in Wave. We'll be doing something closer to email, except with a better approach to threading and collaboration.
Their "I'm having a barbeque, please edit this list to add your name if you're coming" from the demo is great example.
After watching the demo, a lot of people were commenting that the major problem is that it runs counter to how the brain operates...we aren't designed to heavily multitask.
The absolute best way to get real collaboration done is to get everyone into the same room together.
If you do that, it's possible for everyone to talk at once, and of course, if they do that, it doesn't work. You have to take it in turns to talk and listen. Sometimes one person takes the floor. Sometimes you formally break out into smaller groups. Sometimes you get something agreed during an informal chat with a couple of people during a coffee break.
The Wave demo showed that the *technology* allows everyone to talk at once. That's useful, but users are going to have to learn when it's appropriate to stop typing and start reading.
It looks like you could achieve something similar to break-away groups in Wave, by having subgroups spread each other to different parts of a wave, where they can have an isolated chat.
It seems to me, and again I didn't RTFA, that Wave will only be useful when people start writing decent robots and applications to sit on top of it.
This was the purpose of the Developer Preview. We should expect there to be lots of robots and gadgets available already, build by developers who were on the preview rollout.
Does one user need to talk to twelve different people at once? Hell no.
Have you never been to a meeting with twelve attendees? (I'm happy for you).
Those can work because there are social conventions in place as to who can talk when. I imagine Wave users will need to establish similar conventions.
From what I read, it displays data as you're typing it out, rather than after you "post"
I could see a lot of problems around this.
Because I work with a geographically diverse team, I spend a lot of time on IM. Seeing what they type as they type would really increase the fluency of those conversations.
You get long period when you don't know whether someone is typing, thinking or have wondered off.
You get conversations that go out of sync -- e.g. person A changes the topic, then person B hits enter on their long response to the previous topic.
I think the see-as-they-type feature has more benefits than problems.
Why run 2 machines? Its going to suck if you buy 1000 machines for peggle and 1000 machines for crysis and 1500 people want to play crysis and 20 want to play peggle level games.
Since they're not going to ghost a machine to prep it for every player, i think their only logical choice is to install every game on every machine.
Clearly, you wouldn't "install" a game on any individual server.
You'd have the game files on a big fileserver (SAN, whatever). You'd have the same software on every single game server, and the supervisor node that assigns players to hardware would know the hardware specs of each server.
Then you'd use a best-fit algorithm to decide which is the most appropriate place to host the requested game. One server could host one game of Crysis, or 5 games of Bioshock, or 20 games of Peggle. Or 2 games of Bioshock and 12 games of Peggle.
Just an example.
If they expect me to pay $5/month to play only crysis, forget it.
Yet it's common to pay $60 to play a game for less than a month (people who buy a console game, finish it quickly, and don't bother trading it).
I've often paid over $5 for XBLA games that I've finished in a few days and will never return to.
Do they need to buy 1 machine for every person? Absolutely. If they don't, they run a risk.
If all their users play the big games simultaneously, they're doomed. I personally don't think they'll get that kind of peak. Some people like to play at weekends, some before dinner, some after their SO has gone to bed.
Likely they're going to charge $19.99 or $29.99/month for this.
Source? I'm guessing you have no idea what they're going to charge. We don't know whether they'll charge by the hour or by the month, whether you'll buy a package or an individual game, any of that. My guess is it'll be a combination of these.
Which leads me to another thought. With pricing, you can manage demand. Not enough capacity for everyone to play Crysis? Well, Wolfenstein costs $2/month and Crysis costs $5/month. Watch the usage patterns change.
No , that would be app/OS + VM + OS + hardware. The host OS doesn't just conveniently vanish, its still using up CPU cycles.
While you can run VMs on a desktop OS (or indeed on a server), the real fun comes when you run it on a platform that's been custom designed for the purpose. For example, VMWare ESX. This is effectively a kernel with VMWare built into it. Sure it's an OS, but it's a very, very light OS.
"If the hardware fails all you have to do is move the VM "image" to new hardware."
How many apps are hardware dependent these days? All OS's have hardware abstractions , eg unix /dev directory. So whats different between doing that and just moving the app over to another server?
The difference is that you can do it without stopping the application.
Imagine you're paying me to host a Linux system for you. I could be running that as a VM on box a. While you're logged in and actively using the system, I could move the VM to box b, without you noticing. You might spot a momentary pause, but nothing more.
*That's* how it's different from moving the app over to another server.
Just wish people would stop calling it a cloud.
What you have might not be a cloud, but what Amazon offers probably is.
You provision an EC2 instance, and it's there. You don't know where it is, and you don't care. There's just a cloud of VMs, yours is in there somewhere, and you can connect to it to use it.
Dynamically, Amazon might choose to move your VM to another physical host for all kinds of reasons -- an unplanned physical failure, a planned power-down, some algorithm that decides they could meet your needs more cheaply at a different location, etc. And you wouldn't notice.
When did installing multiple apps on 1 server go out of fashion?
When it became clear it's a management headache.
"Hi it's ops. You know your foo server sits on the same box as the bar server? Yeah, well the bar guys have found out they need a kernel with a higher filehandle limit, so we're going to be rebooting that box. You'll need to tell your users about the outage. Oh, and you'd better have QA test the foo server with the new kernel too."
So use 1 server and have 10 client logins on it FFS.
1 client wants RHEL 4. ... etc.
1 client wants RHEL 5.
2 clients want Windows Server, both want a weekly reboot, but during different maintenance slots.
2 clients want stable Debian, but one wants a weekly 'apt-get dist-upgrade', the other wants it monthly
Give each one a VM, and you can deliver all this on one physical machine very, very easily.
Managers love this kind of terminology, because from their point of view Internet just 'happens' somehow.
And cloud computing makes them right. You pay some money, and the entity you're paying the money to, makes it happen.
Just like when I buy a tin of soup from a supermarket, I don't need to understand anything about the supply chain that got it there.
The difference is that with a mobile phone, they have some gaurentee of income because of the contract.
We don't yet know whether OnLive intends to give away microconsoles without a contract.
My first guess is that it will come free with a contract. Just as with a cable box or a satellite receiver.
There will be PC/Mac clients? Browser plugins even? Why didn't you say so, all of a sudden I give a shit.
They did say so, right from their first announcement.
Google Wave == IRC with a GUI!
I'm learning a lot about IRC today.
I didn't know that an IRC message was a persistent object that would be around forever.
I didn't know that IRC users could retrospectively edit messages that had already been sent. Nor that IRC allowed you to navigate through the history of changes to a message.
I didn't know that IRC messages were arranged in a hierarchical thread structure.
So it's been a good day for learning.
(Score:-1, Sarcastic)
With no market for PC graphics cards or even for cards in new consoles then who pays ATI / Nvidia to continue developing new technology?
Firstly, the servers for cloud gaming services will need loads of GPUs, so demand for new graphics chips would not diminish.
Secondly, this isn't going to obsolete locally hosted gaming. Many people will still want to run ninja gaming rigs; many people will want to play on traditional consoles. Cloud gaming may poach some customers away from local gaming, and it may attract people who could never be bothered with the hassles of local gaming. But it won't kill local gaming.
How does this work in broadband starved countries (Africa, Oceania) where we get chucked on 64kbps when we go over the limit?
It doesn't. It's not even offered. Next question?
That's what the beta's for.
There are plenty of reasons why you might choose to host two services on two different machines, even if one machine would have enought power. Things like being able to take one down without affecting the other.
VMs let you keep some of that model, while consolidating down to less hardware.
Plus it makes deployment easy: get your system how you want it, then save it as an image. Now you can clone it as much as you like. Now that there are OSS VM hosts, the commercial virtualisation companies are concentrating their efforts on providing more and more powerful tools for creating, managing and deploying images.
But why should I be saying all this. Read it from a marketeer:
http://www.vmware.com/technology/why.html
Especially cool, is VMs with high availability. Two physical machines, in separate datacentres, each running the same VM in lockstep. Pull the power cord on one, and the user will notice nothing but a momentary pause as the secondary VM takes over.
Using hardware decoders is non-trivial.
It's pretty trivial if you have control over the hardware. This particular thread is about the 'free' hardware they intend to distribute.
The microconsole is bound to contain a cheap, low powered CPU, and a mass market decoder chip.
Newsflash: most people would consider your 8800GT, Athlon X2 3800 with 4GB RAM a very high level machine.
Then there's all the people with laptops that have lots of CPU, lots of RAM, and a crummy graphics card.