Not sure what the available space on a phone or a tablet has to do with downloading ISOs.
And no, even on phones disk space isn't as premium as it has been. I had 32GB on my last phone (without expansion - n900) and 16GB on my current SGS2 with the possibility of expanding with MicroSD. Not tons but enough for 20 ISOs... I'm just wondering why you want to carry around 20 ISOs on a phone.
If you're talking about devices with less than 1GB of storage, why would you ever consider downloading an ISO to it, whatever its size? Use a real computer.
These games aren't for sale through Desura. You can buy them elsewhere and install them and add a shortcut inside Desura so all your games are in one place - that's the option it's offering you there.
Games that you can buy through Desura are managed and installed for you, just like they would be with Steam.
1. Give the user a unique repo URL (telling them to add it is the hardest thing here)
2. When their apt hits it for packages.gz, the system looks at their unique identifier and see's which packages they're allowed and sends them the results
3. When they try to download something, the system checks again to see if they're allowed it. If they are, it sends it the package.
What is hard about that? A monkey with two minutes of PHP experience could write something that did this. No, it's not the most secure thing on the planet but SSL stops people sniffing it and the owner should trust the user. There is an argument that having the package manager handle the package downloads, you're already taking the files out of the users' hands. It would be technically harder for users to pirate things using my system.
And if the developer has a raging clue for DRM, they can implement that at package level, either in the installer or in the application itself.
The only major issue here is performance. Clever caching will help subsequent hits but there's always going to be a bit of database io involved when you're looking up things. It's not going to be as fast as a non-authenticated option.
Package management is an excellent thing, but apt-get doesn't work so well with non-free (as in money) software
It can. You can easily have custom (ie locked to one user) package lists with secured downloads and pump all that through Deb. It's all HTTP after all; anything you can do on a website you could do with the current apt stack.
I'd be very surprised if they didn't provide a pure-OpenGL renderer.
D3 is a bad example of a big game because (with perhaps the exception of whatever DRM it's wrapped in) it's probably going to run pretty well on Linux under Wine.
They've already said they're setting the limit at 750MB (more than a standard CD). There might be a slight argument there but with the next limit being 800MB, then 1GB, disk space isn't as premium as it used to be.
Unless there's something they could be doing for that 20 years to help stay off the disease.
I certainly see your point, but there are clinical suggestions that some (and it is only some) patients benefit from certain mental exercises and diets.
I'm not entirely sure why they're skewing this around the desires of mobile gamers. Mobile games need to be quick to pick up, quick to put down. Length doesn't really factor into it, as long as it's enough fun to justify its costs (including abusive advertising).
I'd argue that games are too short. The annual Call of Duty saps us of £20-40 (depending on when you buy it) and takes 6-10 hours to blast through. Some people don't play the SP game and some people don't play the MP game so, naturally, people's mileage varies. The best games I've ever played have been epics (40-120 hours) with strong stories. In the case of Neverwinter Nights or KotOR, I've both bought and played them through multiple times. That, to me, is what those sorts of games should be aiming for.
Games whose format is supposed to be short-and-sweet or mobile can be as short as the market will support.
But the context of this thing is we all have a connection that allows us to transfer an hour of HD video in seconds. A reasonable buffer (eg 30 seconds) is going to take less than a second. If things are so congested that you can't download the next 30 seconds at any point in the current 30 seconds, the problem is bigger than the bandwidth or the type of streaming. That is to say, Netflix just need a better network and better hardware. Forcing people to download the entire thing would only exacerbate the problem.
And regarding the local side of things, similar answer. Increased bandwidth with burst-caching 30 second chunks of video in less than a second. You wouldn't notice ten people all watching different movies on your connection.
Test it by editing grub (which is a temporary edit that will be lost next boot) first and test out suspend, hibernate, etc.
If that works, edit your grub configuration files. For ubuntu users this means editing/etc/default/grub and editing the GRUB_CMDLINE_LINUX_DEFAULT variable. Then call sudo update-grub.
There's a reason video service stream video out in chunks: bandwidth costs money and connections are contended.
- If somebody loads your video but only play the first 15 seconds (of an hour long clip) and you've only served them 30 seconds of video, your wastage is low. If you pump it out as fast as you can, you've wasted 59 minutes, 45 seconds of video in bandwidth. Even imagining that tomorrow's bandwidth prices were near-nothing what they are today, this is the sort of overhead companies can easily cut by dripping out content in chunks.
- Servers and networks have throughput limits. Even if you get a googlbit pipe, you're still limited by the hardware. If you're pushing out a video from RAM to three users, using all your CPU and most of your network, what happens when users four through ten come along? Chunking lowers the "there and then" I/O demands.
- It's not even a good idea for users. The average user doesn't need something to stream out that fast either - there's no benefit for most people to have the end of a clip before they're through the opening credits. You can still seek with progressive chunks.
I expect more from Cerf. This is very simple network economics.
I don't have an iPhone but have spent around £50 on applications for my Android in the two months I've had it.
Perhaps my behaviour is just a side-effect of being app-starved on my Nokia N900.
http://www.exit1.org/dvdrip/
Looks a little intimidating at first but considering its immense filtering, output and batch-clustering options, it's a pretty simple interface.
Slashdot Mirror
Not sure what the available space on a phone or a tablet has to do with downloading ISOs.
And no, even on phones disk space isn't as premium as it has been. I had 32GB on my last phone (without expansion - n900) and 16GB on my current SGS2 with the possibility of expanding with MicroSD. Not tons but enough for 20 ISOs... I'm just wondering why you want to carry around 20 ISOs on a phone.
If you're talking about devices with less than 1GB of storage, why would you ever consider downloading an ISO to it, whatever its size? Use a real computer.
These games aren't for sale through Desura. You can buy them elsewhere and install them and add a shortcut inside Desura so all your games are in one place - that's the option it's offering you there.
Games that you can buy through Desura are managed and installed for you, just like they would be with Steam.
I'm not oversimplifying anything. This is simple!
Seriously.
1. Give the user a unique repo URL (telling them to add it is the hardest thing here)
2. When their apt hits it for packages.gz, the system looks at their unique identifier and see's which packages they're allowed and sends them the results
3. When they try to download something, the system checks again to see if they're allowed it. If they are, it sends it the package.
What is hard about that? A monkey with two minutes of PHP experience could write something that did this. No, it's not the most secure thing on the planet but SSL stops people sniffing it and the owner should trust the user. There is an argument that having the package manager handle the package downloads, you're already taking the files out of the users' hands. It would be technically harder for users to pirate things using my system.
And if the developer has a raging clue for DRM, they can implement that at package level, either in the installer or in the application itself.
The only major issue here is performance. Clever caching will help subsequent hits but there's always going to be a bit of database io involved when you're looking up things. It's not going to be as fast as a non-authenticated option.
Package management is an excellent thing, but apt-get doesn't work so well with non-free (as in money) software
It can. You can easily have custom (ie locked to one user) package lists with secured downloads and pump all that through Deb. It's all HTTP after all; anything you can do on a website you could do with the current apt stack.
It all depends on the price. As a customer I certainly wouldn't mind running both if it meant I got cheaper games.
Which games are these? All the games I've tried have installed and played directly from Desura.
I'd be very surprised if they didn't provide a pure-OpenGL renderer.
D3 is a bad example of a big game because (with perhaps the exception of whatever DRM it's wrapped in) it's probably going to run pretty well on Linux under Wine.
They've already said they're setting the limit at 750MB (more than a standard CD). There might be a slight argument there but with the next limit being 800MB, then 1GB, disk space isn't as premium as it used to be.
I think you're confused. The vast majority of healthcare here (in the UK - what this is talking about) is government-run and government funded.
Unless there's something they could be doing for that 20 years to help stay off the disease.
I certainly see your point, but there are clinical suggestions that some (and it is only some) patients benefit from certain mental exercises and diets.
I'm not entirely sure why they're skewing this around the desires of mobile gamers. Mobile games need to be quick to pick up, quick to put down. Length doesn't really factor into it, as long as it's enough fun to justify its costs (including abusive advertising).
I'd argue that games are too short. The annual Call of Duty saps us of £20-40 (depending on when you buy it) and takes 6-10 hours to blast through. Some people don't play the SP game and some people don't play the MP game so, naturally, people's mileage varies. The best games I've ever played have been epics (40-120 hours) with strong stories. In the case of Neverwinter Nights or KotOR, I've both bought and played them through multiple times. That, to me, is what those sorts of games should be aiming for.
Games whose format is supposed to be short-and-sweet or mobile can be as short as the market will support.
But the context of this thing is we all have a connection that allows us to transfer an hour of HD video in seconds. A reasonable buffer (eg 30 seconds) is going to take less than a second. If things are so congested that you can't download the next 30 seconds at any point in the current 30 seconds, the problem is bigger than the bandwidth or the type of streaming. That is to say, Netflix just need a better network and better hardware. Forcing people to download the entire thing would only exacerbate the problem.
And regarding the local side of things, similar answer. Increased bandwidth with burst-caching 30 second chunks of video in less than a second. You wouldn't notice ten people all watching different movies on your connection.
Add pcie_aspm=force to your boot options.
/etc/default/grub and editing the GRUB_CMDLINE_LINUX_DEFAULT variable. Then call sudo update-grub.
Test it by editing grub (which is a temporary edit that will be lost next boot) first and test out suspend, hibernate, etc.
If that works, edit your grub configuration files. For ubuntu users this means editing
There's a reason video service stream video out in chunks: bandwidth costs money and connections are contended.
- If somebody loads your video but only play the first 15 seconds (of an hour long clip) and you've only served them 30 seconds of video, your wastage is low. If you pump it out as fast as you can, you've wasted 59 minutes, 45 seconds of video in bandwidth. Even imagining that tomorrow's bandwidth prices were near-nothing what they are today, this is the sort of overhead companies can easily cut by dripping out content in chunks.
- Servers and networks have throughput limits. Even if you get a googlbit pipe, you're still limited by the hardware. If you're pushing out a video from RAM to three users, using all your CPU and most of your network, what happens when users four through ten come along? Chunking lowers the "there and then" I/O demands.
- It's not even a good idea for users. The average user doesn't need something to stream out that fast either - there's no benefit for most people to have the end of a clip before they're through the opening credits. You can still seek with progressive chunks.
I expect more from Cerf. This is very simple network economics.
I don't have an iPhone but have spent around £50 on applications for my Android in the two months I've had it. Perhaps my behaviour is just a side-effect of being app-starved on my Nokia N900.
http://www.exit1.org/dvdrip/ Looks a little intimidating at first but considering its immense filtering, output and batch-clustering options, it's a pretty simple interface.