It's not only that. Porn sites were the first sites that actually tried to sell something over the internet. They were the first to try out identification (of people the shop has never seen and never will see in persona), automated user setup, online payments etc.pp. When the Dotcom bubble started to grow, porn content already had online stores, pay-per-view, pay-per-click-through and all the other really hot business bingo triggers.
Porn was also (at least here in Germany) the first that actually made the internet popular, when 'investigative journalists' discovered that students at the universities were wasting tax payer money to wank off. That was exactly when Xlink (which actually meant eXtended local inter net Karlsruhe) spun off from University of Karlsruhe and Eunet from University of Dortmund, which were the first to commercially offer Internet services to the public. Suddenly everyone knew about this Internet thingy, and about the fact that you could get GIF (Girls In Files) there.
I've grown up in a country with a law defining the legal devices to replay recorded music. In this case it wasn't for home use though, but for public play like in a club or at parties. In this case it was probably to enable the state authorities to check the music for subversive content. But the idea is the same: To control the situation, forbid any not yet controlled entity to enter it.
No. This is the perfect time for Apple to go with Intel. Intel needs to do something to save its ass in the desktop market (even with sliding market share, it's still the big revenue and profit), so they will try to keep Apple happy as long as possible. And if it doesn't work out for Apple with Intel, they can switch to the binary compatible AMD chips at any point.
Apple Inc. sells Apple computers with Apple Mac OS X. Apple doesn't sell Intel Inside computers.
It was a 'misstep' they had to take with going away from the Netburst architecture anyway. The Pentium M and successors all have much lower clock rates with still retaining comparable performance. For low power devices the high clock rates were hell.
I don't think so. And, amongst all the rights, that one is perhaps the most fundamental because it gives us a fighting chance to stop the government of absolutely alienating us from the remainder of our rights. Perhaps that is why dictatorships like to seize privately owned firearms.
Name one south american dictatorship that seized the weapons of the population to prove your point. No. They don't. They know that privately owned weapons in the hands of their supporters allow them to kill perceived enemies without governemental involvement. What do you think all the death squadrons come from? (If you should call them a 'well regulated militia' is another question.)
There were dictatorships that seized weapons (Not many in fact. Most dictatorships are based in armed societies. Look at the islamic world!). But there are democracies doing the same. The point is moot.
The Second Amendment comes from a completely different source of experience: In medieval Europe the weapon was a symbol of rank and nobility. You were what weapon you were bearing. You weren't allowed another weapon until you achieved the correct rank. On the other hand you got your weapon as soon as you got a certain rank, independently from the requirement of the job to bear one. In Prussia the headmaster of a train station was given a saber. The head of a post office got one. Not a firearm. A saber.
On the other hand: During upheavals the population was reforging their tools to be weapons. And thus the groups of fighters had very diverse weapons of often questionable quality and was far away from being 'wellregulated'.
From those two points the Founding Fathers said: Ok. Everything can be made a weapon. But to have some idea what weapons the people are bringing to a militia, we should go for stuff MADE to be a weapon. And the weapon should not be an expression of rank, nobility or penis length, it should just be a weapon. So everyone should choose the weapon according to his abilities and needs, not to some perceived level in society. The right to bear arms is at first an expression of equality.
In the mid 90ies the University of Stuttgart already had an own GPS emitter transmitting the position of the University of Stuttgart and thus enabling the local public transport companies to get ~10m (~30ft) accuracy, enough for them to coordinate the local busses.
Ok. To put it more correctly: CommonRail Diesel is a patented FIAT construction, and was developed jointly with PSA (Peugeot, Citroen) in France. Every common rail diesel injection on this world is either made directly by FIAT or licensed by FIAT. This includes BWM and Mercedes, GM and Ford, Toyota and Honda. The argument about 'are competing and thus no cooperation' doesn't hold. PSA and Fiat are competing in the small class market in Europe and are jointly developing their own line of Minivans (Peugeot 807, Citroen C8 and FIAT Ulysse). Toyota and PSA are competing in mid class and minivan markets in Europe and are jointly developing small class cars (Peugeot 1007, Citroen C2 and Toyota Aygo). Before Volvo was bought by Ford, it was using Renault engines for its cars. Ford and VW are competing in the small and mid class car market in Europe and are developing and building Minivans in cooperation (VW Sharan and Ford Galaxy). The cooperation of Ford and VW in South American Autolatina company goes much further: They even switch the brands. The VW Quantum was sold with Ford branding, and the Ford Escort was sold as VW Apollo. There are some interesting cooperations in car manufactoring anyway: Did you know that the russian 1,5l LADA engine is in fact a construction from Porsche?
Technology: BMW leads the world with their inline six-cylinder diesel engines.
Those engines are made by GM (to be more specific: by the european Opel branch), and the injection system is made by FIAT. Tells you something about the difference between brand and maker;)
FIAT also makes the injection for nearly all other car diesels (including Mercedes), with the exception of Volkswagen, whose TDI/SDI system was developed inhouse by the Audi division.
The main problem with DRM is that in current legislation with DMCA and related laws, DRM has the highest priority in computing. Basicly every computer task has to comply with DRM, or it is a "circumvention device". Security, Audition, Reliability... everything has to take second seat behind DRM. And only if something bad happens due to this priorising (like in the case of the Sony Rootkit), this rule gets questioned for that particular event.
The most convincing argument the article brought was, what would happen if the 'analog hole' gets plugged, and every analog recording device has to comply with DRM. Imagine the bad boys robbing a store just taking a portable video player first and start playing a movie in front of the surveillance camera: According to the potential law the camera has to stop recording, otherwise it would record an illicit copy of the movie! But if surveillance cameras are taken out of the law, who hinders the bad boys to buy one and take it to the cinema to record the movie?
DRM is not orthogonal to other computer tasks. It gets in the way of everything. It has to audit every piece of information moved. And it is not able to take in account the importance of the movement or the effects it has if it stops the movement of information. It can't decide from the context if it should shut down the task or let it run. It's all or nothing. If it encounters a trigger, it will shut down the task anyway, may the data stream be generated by the underage son trying to rip a CD or by the brake sensors telling the brake to stop the car immediately.
As someone who has recently being one of the technicians to review a public bid for a medium cluster, I have to agree. For the same price we got more than twice the number of Opteron processors (40x Opteron 880, 2.4 GHz) offered than Intel Xeon (18x 2.8 GHz). Even if the tasks for this cluster were running better on Xeons for some reason, the sheer number of Opertons still would make the opteron cluster the faster offering.
If Dell wants to compete in this market, they have to get a better pricing structure for their servers, because all the other components of a server (case, cooling, HD, RAM, Ethernet, Myrinet/Infiniband etc.pp.) are of-the-shelf parts and thus Dell can't gain a high enough advantage there in pricing to offset the higher Xeon costs.
It might make a difference for assemblers who try to put out machines priced under a certain limit. If they are trying to build something like a $1599 machine, they have $30 more headroom for the other components, leading maybe to the next better graphic card or a an additional 512 MByte of RAM. In a market where specs for the components are everything, the prices are made to fit unter certain arbitrary limits, and the balanced choice of components takes a backseat, such $30 may be the deciding factor for choosing the processor architecture.
Yes. That's why the application should have means to tell the operating system what to expect. Because the application might be better suited to guesstimate than a general purpose operating system.
I am pretty sure that Bob Metcalfe is actually talking about the same thing. He is a network guy, and he knows what networks are capable of delivering in terms of Quality of Service. And he is probably missing the same facilities in operating systems. To explain what he is talking about he takes the example of video streaming, which is a pretty good example because you notice every little timing error in a video streaming, as a flicker of the picture or as a bristle in the sound. And with 'video from the Internet' he doesn't mean the single guy watching a single video over a dedicated single DSL. He is talking about maybe a household which shares different lines, where different persons are watching different content from different resources at different times, sometimes overlapping, sometimes not, and he knows that from a network point of view there is a way to know if a certain stream can be started or if the bandwidth limits are too small, but there is no way to get the same answer from an operating system like UNIX or Windows.
As I said before: On the network layer all the problems are solved several times already. The problem is the operating system of the PC. So we have a pretty good idea how solutions are supposed to work, but we don't have the operating systems yet for general purpose hardware.
In operating systems there are a lot of system calls which don't even have something like best effort or packet switching. There it is all or nothing, and if the process taking 'all' is messing up, all other processes are blocked. There are some heuristics which remove locks and kill processes that are taking too long for certain syscalls, but how long 'too long' actually is, is determined by the operating system in a kind of educated guess. No process is able to actually tell the operating system how much time it will actually need the lock for a certain resource, so the operating system can't refuse this from the beginning or at least kill the process after it has taken more time than agreed on.
I remember certain MUD (Multi User Dungeons) I coded on where you could determine at installing the game driver how long a single function call could actually take, and if the execution of a function took longer, it was stopped and an error was created. It sometimes left the objects in incomplete states (so it was not really transactional), but it was up to the coder of the single objects to take care of short execution paths and recovery after errors. And for a game some people were coding in their free time it doesn't matter too much.
I was always wishing for some function I could call before telling the system to expand the time for a certain function call, even with the trade off that this function call might have been postponed until it was fitting better. Programming recursions with limited execution time was a bitch, because you had to stop the execution, save the state, return an intermediate value and later on continue at the same position with a new function call. It wasn't really easy to code;)
You just hit the nail on the head. Exactly that is the problem. Current operating systems are not deterministic enough for data stream switching. To many not controllable input devices for instance. To many unknown programs whose resource demand is not foreseable.
A program in a data stream oriented system should make a prediction how much resources it will use and have some kind of contract with the operating system about those resources. As soon as it overuses them it should be terminated (as it would be today if it tries to use resources that are allocated to other processes or tries to use resources in an inapprobriate way like misaligned adressing or writing to read only devices etc.pp.).
The issue is not, as you are all somehow seem to believe, that there are limits of bandwidth. The issue is that the operating system can't tell you what they are. A streaming capable operating system should tell you when starting a certain stream would be unwise because the bandwidth is not there to serve it, as a file system is telling you that you can't save any more data because the disk is full. Currently you either have hard limits with some PC based DVRs or similar equipment, which are found out by benchmarking and testing, or you just start the streams and hope they will run rather smoothly.
Stream aware operating systems should always KNOW where the limits are, and if certain streams with certain properties still fit into the bandwidth limits, whatever causes the limitations.
For home use today you are right. But we are not only talking of home computers streaming data from a single DSL right now. We are talking about operating systems in general. Let's say you are a Video On Demand provider reselling capacity to smaller Video On Demand providers. So you have several sources of data streams (you own library and the streams from the other VODPs) and several sinks for data streams (your and the other VODPs' customers). And the streams going across your system in a (for you) indeterministic manner, starting at unforseeable time and ending too. And there are several SLAs telling you what bandwith you have to provide to each of them. The only way for you to conform is to buy enough bandwidth to serve all of them when they are running at maximum capacity. So in the end you have a single big switch with an enourmous backplane to exceed everything you might ever be asked for.
This doesn't scale. Wouldn't it be better to have a network of smaller switches, where data streams that don't affect each other from a billing point of view (different providers to different customers), don't affect each other also in a networking kind of way? With network equipment like ATM and TENET you can fulfill this. But with Windows and UNIX there is no native way to support this. None of your nodes should be running Windows or UNIX, but a dedicated switch or router OS. But what if you want to use facilities a router or a switch doesn't provide? Recoding the data stream before forwarding it? Adapting for instance the movie resolution to fit into a pipe which is already serving other streams, but not at the limit of capacity? What if you want to resell unused capacity to other people? How do you determine which capacity is free and how do you (or your customer) adapt the service to the bandwidth that is left?
And, once the problem is solved for big data stream nodes, it will trickle down to home use. Having one room in your house listening to music streams that are stored somewhere else, while another one is sending streams to DSL via videophone, while a third one is recoding the vacation videos for storing at the house video library. Soon you have lots of data streams crossing your home network, going out and coming in at different nodes, and you should be able to warrant a certain quality of service.
Your argumentation holds very well as long as it is only one datastream we are talking about, or only one pipe it can go through. As soon as you have several of them, starting and ending at different times and going different ways, you should be able to schedule streaming resources: Postpone one that doesn't fit into the sum of all bandwith you get for instance, or reroute it through different pipes that are not fully used.
Currently we still use benchmarks to tell us, how much bandwidth we can really muster for different tasks on a computer. A streaming OS would have to have an operating system function, where you can actually ask it, how much bandwidth you get if you want to pipe a data stream from point A to point B at a predefined time, and then you should be able to reserve the bandwidth, so no other application starting later can eat into this bandwidth, the same way today it can't write into the memory an other application is using.
Currently you can separate application only in a way that they don't use the same resources at the same time, which is a very discrete schedule. For actually switching data streams (which is different from having one datastream uninterupted), you should also schedule the access continously. Imagine it like a big railway station. Today's operating systems are able to make sure that every single track and railswitch is protected and can only be used by a single train at a time. For actual operation of the railway station you need the full way from the starting rail across the station to the leaving rail protected (and freed after the train went through). With todays operating systems you just hold all trains and have only a single one moving. With actuall streaming operating systems you should be able to let several trains run at the same time as long as their ways don't cross. (The analogy doesn't hold completely, because on a railway only one train can use one rail at a time. Streaming data of different streams could use the same path through the operating system at the same time as long as they don't exceed the bandwidth limit).
The main problem is that today's mainstream operating systems are not 'stream' OSes;). They don't think of data as a stream with certain properties. They just have input and output devices, and what happens inbetween is just a matter of how to couple them together.
Networks like ATM and TENET have special layers to define the properties of a data stream independently from the source and the sink. There is no equivalence in Windows or UNIX for those. There are some tacked on QoS-parameters for certain network devices (to handle the QoS of the networks connected), but this is not a design principle for all the not networked devices.
Current OSes thus have a simple solution to QoS: Throw enough resources at the problem, and it will work for the lower bandwidths. For higher bandwidths just wait for the next generation. But in theory the hardware today should handle the higher bandwidths today fine, if the schedulers and the definitions of what has to be scheduled were better supported inside the operating systems. So you can have at maximum one data stream with QoS-warranties on your computer at any given moment.
Computers used for data stream switching often have a subsystem that runs at highest priority on the host operating system and provides those streaming facilities without the host OS getting in the way too much. Futural operating systems should be able to handle the scheduling problems of several datastreams at the same time natively.
But maybe to a small decline in MS Office sales to the people already equipped with an Office suite. I haven't used WP for a long time, so I don't know about the latest version's ability to read and save MS Office formats though, but if they are in the range of OOorg's offers, many people wouldn't need MS Office at all (ok, there are still those whose company uses very sophisticatedly programmed spreadsheets for the employees to send in invoices for business trips which are unusable on any other office suite...)
Slightly offtopic, but there are other examples where the design of a probably contradictionary experiment has lead to the advance of the theory.
Julius Robert Mayer usually gets credited for the description of the equivalence of mechanical energy and thermal energy (published in 1842, in 1847 generalized by Hermann von Helmholtz to the Law of Energy Conservation). When he talked about his ideas with a friend (usually the name of the friend is given as J.G.Nörremberg, a physicist at the Tübingen University), the friend said: "Stop! According to your theory my coffee should get hotter if I stirred it instead of getting cold." Julius Robert Mayer is said to have turned without a word and ran to his home. A few days later he met his friend again and answered: "'S isch aso!" (suabian [south west german] for: "That's how it is!")
As Mr Zeilinger's Office is just some floors below mine, I can tell you: The experiments are real, and the results are in a way that the interpretation is valid. Sorry for your intuition. But reality sometimes bites.
Quite easy. A. Einstein took the Quantum Theory and tried to get very, very strange predictions from it. Basicly he did what Science is about: To test the theory, he used it to predict the outcome of certain experiments.
Most of the predictions appeared completely absurd to him, and he wrote papers about those (like the Bose-Einstein-Condensate or the synchronous state as mentioned in the article). Because of the counterintuitive results he was getting from applying Quantum Theory he doubted its validity.
But most of the described experiments weren't feasible at the time they were thought out. Some of them are right now, and the Bose-Einstein-Condensate is a reality, and this article in the NYT describes another one of the strange predictions being proved.
So with doubting the predictions of Quantum Theory and describing experiments to falsify them A. Einstein in fact lead the way to the advancement of the same theory he had his problems with. That's a fine example of how Science is supposed to work: Always try to find contradictions to the theories and describe experiments which might falsify the theory. Advancement of Science doesn't care if you believe the theories to be correct. Every new hypothesis has its bugs and rough edges which can only be corrected if someone actually finds experiments where the bugs show up.
Slashdot Mirror
It's not only that. Porn sites were the first sites that actually tried to sell something over the internet. They were the first to try out identification (of people the shop has never seen and never will see in persona), automated user setup, online payments etc.pp. When the Dotcom bubble started to grow, porn content already had online stores, pay-per-view, pay-per-click-through and all the other really hot business bingo triggers.
Porn was also (at least here in Germany) the first that actually made the internet popular, when 'investigative journalists' discovered that students at the universities were wasting tax payer money to wank off. That was exactly when Xlink (which actually meant eXtended local inter net Karlsruhe) spun off from University of Karlsruhe and Eunet from University of Dortmund, which were the first to commercially offer Internet services to the public. Suddenly everyone knew about this Internet thingy, and about the fact that you could get GIF (Girls In Files) there.
It was East Germany. But close enough, yes.
I've grown up in a country with a law defining the legal devices to replay recorded music. In this case it wasn't for home use though, but for public play like in a club or at parties. In this case it was probably to enable the state authorities to check the music for subversive content.
But the idea is the same: To control the situation, forbid any not yet controlled entity to enter it.
No. This is the perfect time for Apple to go with Intel. Intel needs to do something to save its ass in the desktop market (even with sliding market share, it's still the big revenue and profit), so they will try to keep Apple happy as long as possible. And if it doesn't work out for Apple with Intel, they can switch to the binary compatible AMD chips at any point.
Apple Inc. sells Apple computers with Apple Mac OS X. Apple doesn't sell Intel Inside computers.
It was a 'misstep' they had to take with going away from the Netburst architecture anyway. The Pentium M and successors all have much lower clock rates with still retaining comparable performance. For low power devices the high clock rates were hell.
Name one south american dictatorship that seized the weapons of the population to prove your point. No. They don't. They know that privately owned weapons in the hands of their supporters allow them to kill perceived enemies without governemental involvement. What do you think all the death squadrons come from? (If you should call them a 'well regulated militia' is another question.)
There were dictatorships that seized weapons (Not many in fact. Most dictatorships are based in armed societies. Look at the islamic world!). But there are democracies doing the same. The point is moot.
The Second Amendment comes from a completely different source of experience: In medieval Europe the weapon was a symbol of rank and nobility. You were what weapon you were bearing. You weren't allowed another weapon until you achieved the correct rank. On the other hand you got your weapon as soon as you got a certain rank, independently from the requirement of the job to bear one. In Prussia the headmaster of a train station was given a saber. The head of a post office got one. Not a firearm. A saber.
On the other hand: During upheavals the population was reforging their tools to be weapons. And thus the groups of fighters had very diverse weapons of often questionable quality and was far away from being 'wellregulated'.
From those two points the Founding Fathers said: Ok. Everything can be made a weapon. But to have some idea what weapons the people are bringing to a militia, we should go for stuff MADE to be a weapon. And the weapon should not be an expression of rank, nobility or penis length, it should just be a weapon. So everyone should choose the weapon according to his abilities and needs, not to some perceived level in society. The right to bear arms is at first an expression of equality.
And there was me thinking that one point of democracy was to empower normal Homer Simpson people to make the rules... Silly me.
In the mid 90ies the University of Stuttgart already had an own GPS emitter transmitting the position of the University of Stuttgart and thus enabling the local public transport companies to get ~10m (~30ft) accuracy, enough for them to coordinate the local busses.
Ok. To put it more correctly: CommonRail Diesel is a patented FIAT construction, and was developed jointly with PSA (Peugeot, Citroen) in France. Every common rail diesel injection on this world is either made directly by FIAT or licensed by FIAT. This includes BWM and Mercedes, GM and Ford, Toyota and Honda.
The argument about 'are competing and thus no cooperation' doesn't hold. PSA and Fiat are competing in the small class market in Europe and are jointly developing their own line of Minivans (Peugeot 807, Citroen C8 and FIAT Ulysse). Toyota and PSA are competing in mid class and minivan markets in Europe and are jointly developing small class cars (Peugeot 1007, Citroen C2 and Toyota Aygo). Before Volvo was bought by Ford, it was using Renault engines for its cars. Ford and VW are competing in the small and mid class car market in Europe and are developing and building Minivans in cooperation (VW Sharan and Ford Galaxy). The cooperation of Ford and VW in South American Autolatina company goes much further: They even switch the brands. The VW Quantum was sold with Ford branding, and the Ford Escort was sold as VW Apollo.
There are some interesting cooperations in car manufactoring anyway: Did you know that the russian 1,5l LADA engine is in fact a construction from Porsche?
Those engines are made by GM (to be more specific: by the european Opel branch), and the injection system is made by FIAT. Tells you something about the difference between brand and maker
FIAT also makes the injection for nearly all other car diesels (including Mercedes), with the exception of Volkswagen, whose TDI/SDI system was developed inhouse by the Audi division.
The main problem with DRM is that in current legislation with DMCA and related laws, DRM has the highest priority in computing. Basicly every computer task has to comply with DRM, or it is a "circumvention device". Security, Audition, Reliability... everything has to take second seat behind DRM. And only if something bad happens due to this priorising (like in the case of the Sony Rootkit), this rule gets questioned for that particular event.
The most convincing argument the article brought was, what would happen if the 'analog hole' gets plugged, and every analog recording device has to comply with DRM. Imagine the bad boys robbing a store just taking a portable video player first and start playing a movie in front of the surveillance camera: According to the potential law the camera has to stop recording, otherwise it would record an illicit copy of the movie! But if surveillance cameras are taken out of the law, who hinders the bad boys to buy one and take it to the cinema to record the movie?
DRM is not orthogonal to other computer tasks. It gets in the way of everything. It has to audit every piece of information moved. And it is not able to take in account the importance of the movement or the effects it has if it stops the movement of information. It can't decide from the context if it should shut down the task or let it run. It's all or nothing. If it encounters a trigger, it will shut down the task anyway, may the data stream be generated by the underage son trying to rip a CD or by the brake sensors telling the brake to stop the car immediately.
As someone who has recently being one of the technicians to review a public bid for a medium cluster, I have to agree. For the same price we got more than twice the number of Opteron processors (40x Opteron 880, 2.4 GHz) offered than Intel Xeon (18x 2.8 GHz). Even if the tasks for this cluster were running better on Xeons for some reason, the sheer number of Opertons still would make the opteron cluster the faster offering.
If Dell wants to compete in this market, they have to get a better pricing structure for their servers, because all the other components of a server (case, cooling, HD, RAM, Ethernet, Myrinet/Infiniband etc.pp.) are of-the-shelf parts and thus Dell can't gain a high enough advantage there in pricing to offset the higher Xeon costs.
It might make a difference for assemblers who try to put out machines priced under a certain limit. If they are trying to build something like a $1599 machine, they have $30 more headroom for the other components, leading maybe to the next better graphic card or a an additional 512 MByte of RAM.
In a market where specs for the components are everything, the prices are made to fit unter certain arbitrary limits, and the balanced choice of components takes a backseat, such $30 may be the deciding factor for choosing the processor architecture.
Yes. That's why the application should have means to tell the operating system what to expect. Because the application might be better suited to guesstimate than a general purpose operating system.
I am pretty sure that Bob Metcalfe is actually talking about the same thing. He is a network guy, and he knows what networks are capable of delivering in terms of Quality of Service. And he is probably missing the same facilities in operating systems. To explain what he is talking about he takes the example of video streaming, which is a pretty good example because you notice every little timing error in a video streaming, as a flicker of the picture or as a bristle in the sound. And with 'video from the Internet' he doesn't mean the single guy watching a single video over a dedicated single DSL. He is talking about maybe a household which shares different lines, where different persons are watching different content from different resources at different times, sometimes overlapping, sometimes not, and he knows that from a network point of view there is a way to know if a certain stream can be started or if the bandwidth limits are too small, but there is no way to get the same answer from an operating system like UNIX or Windows.
As I said before: On the network layer all the problems are solved several times already. The problem is the operating system of the PC. So we have a pretty good idea how solutions are supposed to work, but we don't have the operating systems yet for general purpose hardware.
;)
In operating systems there are a lot of system calls which don't even have something like best effort or packet switching. There it is all or nothing, and if the process taking 'all' is messing up, all other processes are blocked. There are some heuristics which remove locks and kill processes that are taking too long for certain syscalls, but how long 'too long' actually is, is determined by the operating system in a kind of educated guess. No process is able to actually tell the operating system how much time it will actually need the lock for a certain resource, so the operating system can't refuse this from the beginning or at least kill the process after it has taken more time than agreed on.
I remember certain MUD (Multi User Dungeons) I coded on where you could determine at installing the game driver how long a single function call could actually take, and if the execution of a function took longer, it was stopped and an error was created. It sometimes left the objects in incomplete states (so it was not really transactional), but it was up to the coder of the single objects to take care of short execution paths and recovery after errors. And for a game some people were coding in their free time it doesn't matter too much.
I was always wishing for some function I could call before telling the system to expand the time for a certain function call, even with the trade off that this function call might have been postponed until it was fitting better. Programming recursions with limited execution time was a bitch, because you had to stop the execution, save the state, return an intermediate value and later on continue at the same position with a new function call. It wasn't really easy to code
You just hit the nail on the head. Exactly that is the problem. Current operating systems are not deterministic enough for data stream switching. To many not controllable input devices for instance. To many unknown programs whose resource demand is not foreseable.
A program in a data stream oriented system should make a prediction how much resources it will use and have some kind of contract with the operating system about those resources. As soon as it overuses them it should be terminated (as it would be today if it tries to use resources that are allocated to other processes or tries to use resources in an inapprobriate way like misaligned adressing or writing to read only devices etc.pp.).
The issue is not, as you are all somehow seem to believe, that there are limits of bandwidth. The issue is that the operating system can't tell you what they are. A streaming capable operating system should tell you when starting a certain stream would be unwise because the bandwidth is not there to serve it, as a file system is telling you that you can't save any more data because the disk is full. Currently you either have hard limits with some PC based DVRs or similar equipment, which are found out by benchmarking and testing, or you just start the streams and hope they will run rather smoothly.
Stream aware operating systems should always KNOW where the limits are, and if certain streams with certain properties still fit into the bandwidth limits, whatever causes the limitations.
For home use today you are right. But we are not only talking of home computers streaming data from a single DSL right now. We are talking about operating systems in general. Let's say you are a Video On Demand provider reselling capacity to smaller Video On Demand providers. So you have several sources of data streams (you own library and the streams from the other VODPs) and several sinks for data streams (your and the other VODPs' customers). And the streams going across your system in a (for you) indeterministic manner, starting at unforseeable time and ending too. And there are several SLAs telling you what bandwith you have to provide to each of them. The only way for you to conform is to buy enough bandwidth to serve all of them when they are running at maximum capacity. So in the end you have a single big switch with an enourmous backplane to exceed everything you might ever be asked for.
This doesn't scale. Wouldn't it be better to have a network of smaller switches, where data streams that don't affect each other from a billing point of view (different providers to different customers), don't affect each other also in a networking kind of way? With network equipment like ATM and TENET you can fulfill this. But with Windows and UNIX there is no native way to support this. None of your nodes should be running Windows or UNIX, but a dedicated switch or router OS. But what if you want to use facilities a router or a switch doesn't provide? Recoding the data stream before forwarding it? Adapting for instance the movie resolution to fit into a pipe which is already serving other streams, but not at the limit of capacity? What if you want to resell unused capacity to other people? How do you determine which capacity is free and how do you (or your customer) adapt the service to the bandwidth that is left?
And, once the problem is solved for big data stream nodes, it will trickle down to home use. Having one room in your house listening to music streams that are stored somewhere else, while another one is sending streams to DSL via videophone, while a third one is recoding the vacation videos for storing at the house video library. Soon you have lots of data streams crossing your home network, going out and coming in at different nodes, and you should be able to warrant a certain quality of service.
Your argumentation holds very well as long as it is only one datastream we are talking about, or only one pipe it can go through. As soon as you have several of them, starting and ending at different times and going different ways, you should be able to schedule streaming resources: Postpone one that doesn't fit into the sum of all bandwith you get for instance, or reroute it through different pipes that are not fully used.
Currently we still use benchmarks to tell us, how much bandwidth we can really muster for different tasks on a computer. A streaming OS would have to have an operating system function, where you can actually ask it, how much bandwidth you get if you want to pipe a data stream from point A to point B at a predefined time, and then you should be able to reserve the bandwidth, so no other application starting later can eat into this bandwidth, the same way today it can't write into the memory an other application is using.
Currently you can separate application only in a way that they don't use the same resources at the same time, which is a very discrete schedule. For actually switching data streams (which is different from having one datastream uninterupted), you should also schedule the access continously. Imagine it like a big railway station. Today's operating systems are able to make sure that every single track and railswitch is protected and can only be used by a single train at a time. For actual operation of the railway station you need the full way from the starting rail across the station to the leaving rail protected (and freed after the train went through). With todays operating systems you just hold all trains and have only a single one moving. With actuall streaming operating systems you should be able to let several trains run at the same time as long as their ways don't cross. (The analogy doesn't hold completely, because on a railway only one train can use one rail at a time. Streaming data of different streams could use the same path through the operating system at the same time as long as they don't exceed the bandwidth limit).
The main problem is that today's mainstream operating systems are not 'stream' OSes ;). They don't think of data as a stream with certain properties. They just have input and output devices, and what happens inbetween is just a matter of how to couple them together.
Networks like ATM and TENET have special layers to define the properties of a data stream independently from the source and the sink. There is no equivalence in Windows or UNIX for those. There are some tacked on QoS-parameters for certain network devices (to handle the QoS of the networks connected), but this is not a design principle for all the not networked devices.
Current OSes thus have a simple solution to QoS: Throw enough resources at the problem, and it will work for the lower bandwidths. For higher bandwidths just wait for the next generation. But in theory the hardware today should handle the higher bandwidths today fine, if the schedulers and the definitions of what has to be scheduled were better supported inside the operating systems. So you can have at maximum one data stream with QoS-warranties on your computer at any given moment.
Computers used for data stream switching often have a subsystem that runs at highest priority on the host operating system and provides those streaming facilities without the host OS getting in the way too much. Futural operating systems should be able to handle the scheduling problems of several datastreams at the same time natively.
But maybe to a small decline in MS Office sales to the people already equipped with an Office suite. I haven't used WP for a long time, so I don't know about the latest version's ability to read and save MS Office formats though, but if they are in the range of OOorg's offers, many people wouldn't need MS Office at all (ok, there are still those whose company uses very sophisticatedly programmed spreadsheets for the employees to send in invoices for business trips which are unusable on any other office suite...)
Slightly offtopic, but there are other examples where the design of a probably contradictionary experiment has lead to the advance of the theory.
Julius Robert Mayer usually gets credited for the description of the equivalence of mechanical energy and thermal energy (published in 1842, in 1847 generalized by Hermann von Helmholtz to the Law of Energy Conservation). When he talked about his ideas with a friend (usually the name of the friend is given as J.G.Nörremberg, a physicist at the Tübingen University), the friend said: "Stop! According to your theory my coffee should get hotter if I stirred it instead of getting cold." Julius Robert Mayer is said to have turned without a word and ran to his home. A few days later he met his friend again and answered: "'S isch aso!" (suabian [south west german] for: "That's how it is!")
As Mr Zeilinger's Office is just some floors below mine, I can tell you: The experiments are real, and the results are in a way that the interpretation is valid. Sorry for your intuition. But reality sometimes bites.
Quite easy. A. Einstein took the Quantum Theory and tried to get very, very strange predictions from it. Basicly he did what Science is about: To test the theory, he used it to predict the outcome of certain experiments.
Most of the predictions appeared completely absurd to him, and he wrote papers about those (like the Bose-Einstein-Condensate or the synchronous state as mentioned in the article). Because of the counterintuitive results he was getting from applying Quantum Theory he doubted its validity.
But most of the described experiments weren't feasible at the time they were thought out. Some of them are right now, and the Bose-Einstein-Condensate is a reality, and this article in the NYT describes another one of the strange predictions being proved.
So with doubting the predictions of Quantum Theory and describing experiments to falsify them A. Einstein in fact lead the way to the advancement of the same theory he had his problems with. That's a fine example of how Science is supposed to work: Always try to find contradictions to the theories and describe experiments which might falsify the theory. Advancement of Science doesn't care if you believe the theories to be correct. Every new hypothesis has its bugs and rough edges which can only be corrected if someone actually finds experiments where the bugs show up.