You're still thinking of the personal organiser of old. It's a good market slice but it's not what these are aimed at.
Netbooks (and by extension a netbook with a built in phone) are more aimed at the sort of place where normally if you're doing a lot of typing you'll be using a big computer but right now you're stuck on a train for an hour or three (or in the back of a car) so you have time to convert the notes you took in the meeting into a set of minutes. But you've just been in that meeting for two hours and a normal laptop would have a flat battery...:-(
Another option is that the note taking and web browsing (aka "research" and "email") is all you need the computer for.
The keyboard is essential for the use cases of a netbook it doesn't have to be a full speed keyboard but you must be able to almost touchtype on it.
If you think about it this looks like the perfect terminal (browser or whatever you want to call it) for Google wave... enough smarts to run a wave locally but with a solid enough connection for group working.
It's been tried, that's what the function keys were originally for. If you go back to the serial terminals you have a line or three at the bottom of the screen for 'function key labels' that are linked to the Fkeys.
The problem is that unless the menu tree is very small the users have no feedback as to where they are in the menu tree and the "get lost" far too easily. With cascading menus the tree is right there. For general use you would need something to help like that.
Still it didn't stop it being very very quick for some users.
No! Stop! I'm not trying to bash Windows. It's a simple fact the Microsoft strongly recommend that you use one machine for one application and never add a second job and it's not just for license revenue. It's because problems leak between the applications. Registry "corruptions", "everything needs a reboot", DLL versions being always system wide ("DLL hell"). Some applications demanding particular OS configurations, others demanding the opposite (eg: exchange and network adaptors). Quite simply if I'm ever touching an SBS machine it feels like I'm walking on eggs or trying to sneak through a pride of sleeping lions.
However, for most users this Windows recommendation is very wasteful and a virtual machines reduce the costs associated with having lots of copies of the OS, it's even cheaper overall when you have to buy more processing power to offset all those copies of the OS that are running. Especially if you factor in system downtime and employee stress!
OTOH the only application that's normally put onto a different machine with unix is the firewall; then only maybe. With unix distinct machines tend to be used only for things like testing vs. live applications or company A vs company B where you have an actual security issue to address.
Still I expect Windows VMs are going to drop off a little now; Windows 2008 is often as wasteful of resources as Vista (despite "core" mode).
The reason that the percentage looks so biased is very simple, most historical woman inventors got a man to do the fronting for them. Or even just wrote under a pen name; a male pen name.
The intent appears to be to get a performance improvement by having the ethernet or network driver pass a specific set of packets to a special purpose program that takes those packets and in the language of the patent "converts" them directly into data of a single format (eg video or audio). The hoped for performance improvement would probably be realised because the packets don't have to be copied through all the layers of the ISO network model. (Err, right)
Obviously, for most modern user machines this is pointless. It was a useful technique back in the days of the
IMP when machines couldn't keep up with the network at all. Even today, it's sometimes useful in embedded applications or on the server side for example 'sendfile()' and kernel based file servers, web servers (IIS, kHHTPd) and so on. Linux even got user space support for this sort of thing back in '00 in terms of the QUEUE target of iptables, though you can do it with most filewall+packet capture combinations. But, AFAICS, nobody's ever really put together a generic framework for this, (unless you count iptables, or maybe the old DOS packet drivers) not much reason to.
So prior art looks far too easy to find; Microsoft will squash this flat.
Don't worry, they've still managed to keep some lovely brainfarts along the way.
My most recent annoyance. You must have the x64 live CD (winpe environment) to install windows from an x64 cd network share. It's not enough to have an x86 winpe and an x64 cd image.
All of NT/2k/XP would install from any old version of DOS; even freedos. Now it won't even install from it's cellmate.
Lookeee here, guys! Someone who understand security tradeoffs.
Firewall
Mailscanner
Safe browser.
User who isn't stupid (by nature or edict).
Yup, that pretty much covers it; except for the chance that some idiot uses your computer one day. Or maybe they forward a zero-day virus that the mailscanner doesn't know yet.
I would add an AV scanner to that in case some idiot manages to drop me in it somehow. It would have to be a "portable app" of course, eg clamav and f-prot both would work.
None of this resource hogging shit the rest of you are talking about.
I suppose it should be run about monthly, maybe weekly if you're mailed by a lot of idiots.
DBs have to serialise everything in the end, so no you don't get the easy splitting that you get with the webserver which means the really big sites have to split the database the hard way and fix any conflicts later.
That's really where facebook are now; they've had to fragment the database so right now the slow scripting language problem isn't significant they're just provisioning a few (thousand) more blades with disks.
But it's still rather rare to have to split the database as your "common configuration" shows. It's far more common to have to split the webservers as is shown by the rarity of the even simpler and more convenient "everything on one box" configuration.
You have a database engine, optimising queries and hitting the disk.
You have an SQL based scripting language
You have an Xsp scripting language
All this is on one machine.
The number of users increases; the slowest part of the system is the hard disks, they've always been slow, their access speed hasn't improved in decades, the amount of data you can put on one has grown hugely. The linear speed of the disk has increased only moderately. So their relative speed had dropped like a stone. BUT The CPU is maxed out first!
W..T..F.
You're lucky, your job already comes neatly sliced up into tiny pieces that can be happily run in parallel on a virtual supercomputer, except the stored procedures. That's another rather slow scripting language but you're stuck running that on one machine, with lots of CPUs and Oracle is charging you per CPU. Oracle charges a lot per CPU.
What's more, you're not even doing the data warehousing thing, where you keep your transactional database and your reporting database distinct.
And the database machine is still fine; most of the time.
I think it looks like you're actually my example. Sure you're being limited by the database server machine but it's the CPU every time but one. Your webserver is using lots of abstraction and lots of CPU; it's cpu bound, it gets some money thrown at it and it's now running on lots of CPUs and the incremental cost to add another CPU (web machine) is low, but it doesn't need it cause Java got more efficient over the years.
More users and now what's left on the DB machine is a problem again, PL/SQL is causing the issue this time and again it's CPU. (I here there's a compiler that translates PL/SQL into C though I doubt you've looked at it)
This time the cheapest solution is to use less PL/SQL and more Java; which is already running on a huge virtual supercomputer.
But at no point are you 'database' or 'disk' bound. You're always CPU bound, except, for those times that somebody shows you what disk bound actually means by running a data warehouse report on your transactional database.
No, based on past performance you don't have to assume the worst with Google. You should still pipe up when they are not being seen to be in "do no evil" mode but right now they have earned the privilege to be granted the benefit of the doubt.
Okay, my expectation is that Google will do this the right way, after all the original paper they're pulling this design from was called "Programming Satan's Computer". Don't you think they might just be very careful about following company policy when working with something called that?
The boot process they're looking for is easy after all.
Initial boot from "Mask ROM" (or unwriteable flash), if F-key pressed checks for 'Unbricking' boot USB stick.
Key flash is locked, only reset will unlock
Machine checks data flash, if there was a crash give option to roll back last boot. (F-key too?)
Gives user option for normal boot from other devices in normal or developer mode. Probably, using F-key to interrupt default boot.
Data flash is switched to append (copy on write?) only if not in developer mode.
Main OS is booted.
In line with the paper everything loaded which not in developer mode has signatures checked.
Plus there's a bounty on serious security bugs. (The definition of "serious" changes over time)
The ability for anyone to do an unbricking boot and change the keys means you're still in control of the hardware. With all this crypto facility around of course the flash will be encryptable, but that only makes a difference if the user enters a pass-phrase.
The rollback, is the last attempt to preserve the integrity of the existing flash before the signing starts to fix things the slow way.
Still there's enough variation in the exact process they could use (eg: they could just call my 'unbricking' mode the developer mode and only lock the keyflash) that many people will be checking, just to make sure that they haven't made a complete cockup.
The end result is the same: I think they can be trusted with "trusted computing"... so far.
The technique of shifting the CPU workload off the database server onto multiple web servers has happened because of people using slow languages not the other way round. Nearly lock free techniques have to be used if you're going to have hundreds of simultaneous users whether their code is running on the DB server or not.
So I think I'll stick with the usual implication of "cpu bound"... "on ordinary hardware" because most people need to pay for their webhosting so "DB Bound"... "on infinite hardware" doesn't really cut it.
DRM doesn't stop the people who upload RIAA stuff to PB and mininova.
In fact shouting how strong your DRM is or especially actually having 'strong DRM' (ie something interesting) tends to get your files up there even sooner.
Just look at the Blueray fiasco.
All DRM does is stop you copying, and maybe, the kid next door, but probably not the one down the street.
Your model is misleading, actually I think You are being misled by your model.
Your exponential growth model doesn't match anything in bittorrent;
You don't have to pass the data on to two people, one is enough (except for 'cheaters')
You don't have to wait for the previous person to get the whole file, they pass data on as soon as they have it
In fact the plain copy a block and pass it to the next person is the simplest reasonable model.
And finally, the file has to get from your machine to the big hosting machine. During that time the torrent would have already passed the file on to all the people who want it. In the perfect world. Torrent wins before a big host even gets started.
OTOH, if you are a big host it often doesn't make much difference to http. You have to be the 'seed box' to provide the additional bandwidth that the asymmetry of an ADSL connection takes away from your customer's upstream. If you want them to have 300K/s downstream but they only have 50K/s upstream you have to seed at 250K/s per user rather than 300K/s per user. Add on to that the bittorrent overheads too.
Only if you're satisfied with providing the data at the speed of the customer's upstream can you minimise your upstream costs and let the swarm stay in the seeder starved state. (or get to seeder rich naturally)
There are things that could change the landscape, local ISP provided seed boxes for example, but right now that's how things are.
This is why, under British law, I always say if I don't want windows up front. They, frequently, point at the EULA and state I can get a refund. Because of this I can, even if the EULA is invalid.
Verbal contracts are as solid as the tape they are recorded on. (Probably)
Except, there's this EULA, that explicitly states you get a refund. A refund that any reasonable person would expect to be the sale price of the item it covers; that's what a refund is.
Historical data shows that the sale price of just Windows XP (the item covered by the EULA) is around $50 under an OEM agreement. Current data implies that Windows 7 is around $75.
This is what I want. It's enough beer money to be 'useful'.
Torrents would be much better if they chose peers based on logical (not necessarily physical) distance.
In a perfect world perhaps, but in the real world this has been attempted and it fails badly. Even if the scheme can't be abused (somebody says "I'm the best" then pisses off once they have the file) the guesses the algorithms make are always worse than the default algorithm.
The basic for the default is "tit for tat", or "here's a block you wanted now you give me something and I'll give you more". Odd as it may seem this actually tends to favour the closer (well behaved) peers.
What Bittorrent actually needs is something that will encourage people to seed as this is the only way that a swarm will get enough overall bandwidth to fill downstream links in a world of ADSL. So called 'seed boxes' can also fill this role by adding more upstream to a swarm but they cost money.
In the prefect case where everyone has 1MB/s upload it would in theory take 100 seconds for any number of people. This is because any one peer starts sharing what it's downloaded as soon as it has one single block of the file.
Of course blocks are not infinity small, people don't have 1MByte upload speeds and it's not a 'big start'.
The best models depend on the state of the swarm. During the initial seed then there is one slow seeder first order approximation is that everybody in the swarm is at the same percentage level. Transfer rate is limited by the upstream of that first seeder.
If the many of peers disappear once they have the file then the swarm is in a seeder starved state. The download rate of any one peer will be about the same as it's upload rate because of the 'tit for tat' like sharing rules in most clients when they aren't seeding.
If the swarm has lots of seeders then in addition to the 'tit for tat' rate a peer will get a 'fair share' of the total upload bandwidth of all the seeders. This is what can fill your downstream rate.
The vast majority of swarms are in the seeder starved state but at the moment the ChromeOS VMs are seeder rich; go for it.
I can't be bothered to look at the moment but there have been reports of companies being accused because they couldn't produce an invoice for Openoffice. Messing with statistics is even easier to beleive.
Slashdot Mirror
You're still thinking of the personal organiser of old. It's a good market slice but it's not what these are aimed at.
Netbooks (and by extension a netbook with a built in phone) are more aimed at the sort of place where normally if you're doing a lot of typing you'll be using a big computer but right now you're stuck on a train for an hour or three (or in the back of a car) so you have time to convert the notes you took in the meeting into a set of minutes. But you've just been in that meeting for two hours and a normal laptop would have a flat battery ... :-(
Another option is that the note taking and web browsing (aka "research" and "email") is all you need the computer for.
The keyboard is essential for the use cases of a netbook it doesn't have to be a full speed keyboard but you must be able to almost touchtype on it.
If you think about it this looks like the perfect terminal (browser or whatever you want to call it) for Google wave ... enough smarts to run a wave locally but with a solid enough connection for group working.
It's been tried, that's what the function keys were originally for. If you go back to the serial terminals you have a line or three at the bottom of the screen for 'function key labels' that are linked to the Fkeys.
The problem is that unless the menu tree is very small the users have no feedback as to where they are in the menu tree and the "get lost" far too easily. With cascading menus the tree is right there. For general use you would need something to help like that.
Still it didn't stop it being very very quick for some users.
I can summarise the problem in one word. Windows.
No! Stop! I'm not trying to bash Windows. It's a simple fact the Microsoft strongly recommend that you use one machine for one application and never add a second job and it's not just for license revenue. It's because problems leak between the applications. Registry "corruptions", "everything needs a reboot", DLL versions being always system wide ("DLL hell"). Some applications demanding particular OS configurations, others demanding the opposite (eg: exchange and network adaptors). Quite simply if I'm ever touching an SBS machine it feels like I'm walking on eggs or trying to sneak through a pride of sleeping lions.
However, for most users this Windows recommendation is very wasteful and a virtual machines reduce the costs associated with having lots of copies of the OS, it's even cheaper overall when you have to buy more processing power to offset all those copies of the OS that are running. Especially if you factor in system downtime and employee stress!
OTOH the only application that's normally put onto a different machine with unix is the firewall; then only maybe. With unix distinct machines tend to be used only for things like testing vs. live applications or company A vs company B where you have an actual security issue to address.
Still I expect Windows VMs are going to drop off a little now; Windows 2008 is often as wasteful of resources as Vista (despite "core" mode).
The reason that the percentage looks so biased is very simple, most historical woman inventors got a man to do the fronting for them. Or even just wrote under a pen name; a male pen name.
Nothing to see here.
Or, of course, you can just ask politely!
They are perfectly within their right to say no, but for a 1000 lines there's a good chance the author will relicense that bit.
The intent appears to be to get a performance improvement by having the ethernet or network driver pass a specific set of packets to a special purpose program that takes those packets and in the language of the patent "converts" them directly into data of a single format (eg video or audio). The hoped for performance improvement would probably be realised because the packets don't have to be copied through all the layers of the ISO network model. (Err, right)
Obviously, for most modern user machines this is pointless. It was a useful technique back in the days of the IMP when machines couldn't keep up with the network at all. Even today, it's sometimes useful in embedded applications or on the server side for example 'sendfile()' and kernel based file servers, web servers (IIS, kHHTPd) and so on. Linux even got user space support for this sort of thing back in '00 in terms of the QUEUE target of iptables, though you can do it with most filewall+packet capture combinations. But, AFAICS, nobody's ever really put together a generic framework for this, (unless you count iptables, or maybe the old DOS packet drivers) not much reason to.
So prior art looks far too easy to find; Microsoft will squash this flat.
Don't worry, they've still managed to keep some lovely brainfarts along the way.
My most recent annoyance. You must have the x64 live CD (winpe environment) to install windows from an x64 cd network share. It's not enough to have an x86 winpe and an x64 cd image.
All of NT/2k/XP would install from any old version of DOS; even freedos. Now it won't even install from it's cellmate.
Lookeee here, guys! Someone who understand security tradeoffs.
Yup, that pretty much covers it; except for the chance that some idiot uses your computer one day. Or maybe they forward a zero-day virus that the mailscanner doesn't know yet.
I would add an AV scanner to that in case some idiot manages to drop me in it somehow. It would have to be a "portable app" of course, eg clamav and f-prot both would work. None of this resource hogging shit the rest of you are talking about. I suppose it should be run about monthly, maybe weekly if you're mailed by a lot of idiots.
I need to check this ... You logged onto an unpatched XP box and started up Microsoft internet explorer.
Are you a complete fucking idiot or what!
DBs have to serialise everything in the end, so no you don't get the easy splitting that you get with the webserver which means the really big sites have to split the database the hard way and fix any conflicts later.
That's really where facebook are now; they've had to fragment the database so right now the slow scripting language problem isn't significant they're just provisioning a few (thousand) more blades with disks.
But it's still rather rare to have to split the database as your "common configuration" shows. It's far more common to have to split the webservers as is shown by the rarity of the even simpler and more convenient "everything on one box" configuration.
I will start with the simplest case.
You have a database engine, optimising queries and hitting the disk.
You have an SQL based scripting language
You have an Xsp scripting language
All this is on one machine.
The number of users increases; the slowest part of the system is the hard disks, they've always been slow, their access speed hasn't improved in decades, the amount of data you can put on one has grown hugely. The linear speed of the disk has increased only moderately. So their relative speed had dropped like a stone.
BUT The CPU is maxed out first!
W..T..F.
You're lucky, your job already comes neatly sliced up into tiny pieces that can be happily run in parallel on a virtual supercomputer, except the stored procedures. That's another rather slow scripting language but you're stuck running that on one machine, with lots of CPUs and Oracle is charging you per CPU. Oracle charges a lot per CPU.
What's more, you're not even doing the data warehousing thing, where you keep your transactional database and your reporting database distinct.
And the database machine is still fine; most of the time.
I think it looks like you're actually my example. Sure you're being limited by the database server machine but it's the CPU every time but one. Your webserver is using lots of abstraction and lots of CPU; it's cpu bound, it gets some money thrown at it and it's now running on lots of CPUs and the incremental cost to add another CPU (web machine) is low, but it doesn't need it cause Java got more efficient over the years.
More users and now what's left on the DB machine is a problem again, PL/SQL is causing the issue this time and again it's CPU. (I here there's a compiler that translates PL/SQL into C though I doubt you've looked at it)
This time the cheapest solution is to use less PL/SQL and more Java; which is already running on a huge virtual supercomputer.
But at no point are you 'database' or 'disk' bound. You're always CPU bound, except, for those times that somebody shows you what disk bound actually means by running a data warehouse report on your transactional database.
No, based on past performance you don't have to assume the worst with Google. You should still pipe up when they are not being seen to be in "do no evil" mode but right now they have earned the privilege to be granted the benefit of the doubt.
Okay, my expectation is that Google will do this the right way, after all the original paper they're pulling this design from was called "Programming Satan's Computer". Don't you think they might just be very careful about following company policy when working with something called that?
The boot process they're looking for is easy after all.
In line with the paper everything loaded which not in developer mode has signatures checked.
Plus there's a bounty on serious security bugs. (The definition of "serious" changes over time)
The ability for anyone to do an unbricking boot and change the keys means you're still in control of the hardware. With all this crypto facility around of course the flash will be encryptable, but that only makes a difference if the user enters a pass-phrase.
The rollback, is the last attempt to preserve the integrity of the existing flash before the signing starts to fix things the slow way.
Still there's enough variation in the exact process they could use (eg: they could just call my 'unbricking' mode the developer mode and only lock the keyflash) that many people will be checking, just to make sure that they haven't made a complete cockup.
The end result is the same: I think they can be trusted with "trusted computing" ... so far.
I think you're confusing cause and effect here.
The technique of shifting the CPU workload off the database server onto multiple web servers has happened because of people using slow languages not the other way round. Nearly lock free techniques have to be used if you're going to have hundreds of simultaneous users whether their code is running on the DB server or not.
Saying that it's possible to add more CPUs even to the extreme levels that facebook uses to combat the slowness of PHP doesn't stop something being CPU bound.
So I think I'll stick with the usual implication of "cpu bound" ... "on ordinary hardware" because most people need to pay for their webhosting so "DB Bound" ... "on infinite hardware" doesn't really cut it.
This is stupid even for AC.
DRM doesn't stop the people who upload RIAA stuff to PB and mininova.
In fact shouting how strong your DRM is or especially actually having 'strong DRM' (ie something interesting) tends to get your files up there even sooner.
Just look at the Blueray fiasco.
All DRM does is stop you copying, and maybe, the kid next door, but probably not the one down the street.
for a sufficiently large user base,
Your model is misleading, actually I think You are being misled by your model.
Your exponential growth model doesn't match anything in bittorrent;
You don't have to pass the data on to two people, one is enough (except for 'cheaters')
You don't have to wait for the previous person to get the whole file, they pass data on as soon as they have it
In fact the plain copy a block and pass it to the next person is the simplest reasonable model.
And finally, the file has to get from your machine to the big hosting machine. During that time the torrent would have already passed the file on to all the people who want it. In the perfect world. Torrent wins before a big host even gets started.
OTOH, if you are a big host it often doesn't make much difference to http. You have to be the 'seed box' to provide the additional bandwidth that the asymmetry of an ADSL connection takes away from your customer's upstream. If you want them to have 300K/s downstream but they only have 50K/s upstream you have to seed at 250K/s per user rather than 300K/s per user. Add on to that the bittorrent overheads too.
Only if you're satisfied with providing the data at the speed of the customer's upstream can you minimise your upstream costs and let the swarm stay in the seeder starved state. (or get to seeder rich naturally)
There are things that could change the landscape, local ISP provided seed boxes for example, but right now that's how things are.
This is why, under British law, I always say if I don't want windows up front. They, frequently, point at the EULA and state I can get a refund. Because of this I can, even if the EULA is invalid.
Verbal contracts are as solid as the tape they are recorded on. (Probably)
Except, there's this EULA, that explicitly states you get a refund. A refund that any reasonable person would expect to be the sale price of the item it covers; that's what a refund is.
Historical data shows that the sale price of just Windows XP (the item covered by the EULA) is around $50 under an OEM agreement. Current data implies that Windows 7 is around $75.
This is what I want. It's enough beer money to be 'useful'.
Yes, if you can point to a legal document that says you can.
But I can't return the shovelware without returning the whole computer because it doesn't have an EULA that says I can. So your maths is meaningless.
There are still practical pocket watches around, like this one
Torrents would be much better if they chose peers based on logical (not necessarily physical) distance.
In a perfect world perhaps, but in the real world this has been attempted and it fails badly. Even if the scheme can't be abused (somebody says "I'm the best" then pisses off once they have the file) the guesses the algorithms make are always worse than the default algorithm.
The basic for the default is "tit for tat", or "here's a block you wanted now you give me something and I'll give you more". Odd as it may seem this actually tends to favour the closer (well behaved) peers.
What Bittorrent actually needs is something that will encourage people to seed as this is the only way that a swarm will get enough overall bandwidth to fill downstream links in a world of ADSL. So called 'seed boxes' can also fill this role by adding more upstream to a swarm but they cost money.
Your math is flawed.
In the prefect case where everyone has 1MB/s upload it would in theory take 100 seconds for any number of people. This is because any one peer starts sharing what it's downloaded as soon as it has one single block of the file.
Of course blocks are not infinity small, people don't have 1MByte upload speeds and it's not a 'big start'.
The best models depend on the state of the swarm. During the initial seed then there is one slow seeder first order approximation is that everybody in the swarm is at the same percentage level. Transfer rate is limited by the upstream of that first seeder.
If the many of peers disappear once they have the file then the swarm is in a seeder starved state. The download rate of any one peer will be about the same as it's upload rate because of the 'tit for tat' like sharing rules in most clients when they aren't seeding.
If the swarm has lots of seeders then in addition to the 'tit for tat' rate a peer will get a 'fair share' of the total upload bandwidth of all the seeders. This is what can fill your downstream rate.
The vast majority of swarms are in the seeder starved state but at the moment the ChromeOS VMs are seeder rich; go for it.
Damn that's fast. Over a megabyte per second. I don't think I've seen any website manage that sort of speed to me.
It just shows you what Bittorrent is capable of, and the RIAA think they can top this on the cheap!
I can't be bothered to look at the moment but there have been reports of companies being accused because they couldn't produce an invoice for Openoffice. Messing with statistics is even easier to beleive.