According to the EULA you can. Microsoft promises it right there on the first screen when you start the machine for the first time. Windows XP Home OEM is about 85-90 GBP here in blighty, so you can expect at 85 quid back when you return your XP license documents (about $140 or so).
> I really don't understand why graphics manufacturers don't simply include an OpenGL driver in the firmware
OpenGL may not be optimal for a hardware interface. You may want more light sources available from OpenGL than the card can do on its own. The interface to the hardware needs to support compositing of several renders to implement many more light sources than the hardware can do.
Furthermore, textures may use a sophisticated compression technique that must be done on the host CPU, the hardware will have to have registers programmed, and they may have a clever video RAM page mapping technique that gives them a large performance or temperature boost. they may not use IEEE floating point numbers in the same format as the host CPU and don't want to give away the format they use, or include extra silicon to decode them.
Lots of very good reasons for a business with interests in money rather than quality of service.
> If nVidia and ATi collaborated on the interface specification then they could even use the same drivers (driver initialises, driver checks for supported OpenGL version and extensions, driver loads emulated code paths for everything else), cutting their own driver development costs without having to expose any of the internal workings of their hardware.
They specifically want to avoid using the same drivers since driver performance is a *major* factor in performance in general, and they want to maintain any advantage they have in whatever areas they have. The first one to open up is the first one to lose the advantage.
The only solution is to design an open 3D video interface that supports the implementation of the very highest performance hardware, and write the drivers for it to the very highest quality. Then the first hardware manufacturer to port their core to the new interface (which could be a lot of work) might be the first to *gain* the advantage. Only then will you see any movement.
And I make no pretense that anything would happen even then.
You do realise that if you could just install any arbitrary peice of software as a non-privileged user, then any client app bug could be exploited to install anything.
And you don't normally have to download firefox, since it tends to be included on installation disks now.
> but what about the people who wanted to actually get some work done in that time frame
Easy, they just used Linux, so where's the problem? Now you could use Linux and get your work done, meanwhile they've been creating the next generation of OS technology that much Linux kernel code will probably be ported to so you can make an evolutionary step to a system with very, very high reliability features. Plus extreme flexibility.:) How good is that?
The GPL applies if one does anything normally prohibited by copyright law. If linking means creating a derivative work, then yes. In the case of static linking certainly, in the case of dynamic linking, perhaps not. When dynamic linking, you could still have art from one work included via C preprocessor macro or something (or a C++ template instantiation), but otherwise, all you have will be reference numbers and lists of required symbols, and I don't think either can be covered by copyright. The UK patent and trademark office lists a right called database right where the effort to build a database of information and relations is protected, but I don't think that is protected since the effort to collate the required symbols is not undertaken by the producer of the linked to library.
If a software producer distributes the GPLd library along with their own work that uses the symbols, that *could* constitute a derived work, but mere use of those symbols from a library with that name does not mean that the application is derived from *that* library, since the same interface could also be implemented under a different license, and even by themselves. That is what you get for defining interfaces - exchangeable implementations, so apps using the interface are separate things not both a part of one work.
There's little difference between some guy in some small town in China and some guy in some small town in Sweden. If it is morally unacceptable treatment to apply to the guy in Sweden, then it is morally unacceptable treatment to apply to the guy in China. After all, I'm sure it's not the Chinese guy's fault that he is subject to the whims of an authoritarian power centre.
You can't just say it is okay because it is the authoritarian power centre's geographic area to do whatever they wish to the people it is beneath. The reason for that is that it is not the authoritarian power centre's geographic area, it belongs to the people that need the land to survive (especially since the power centre itself claims to be communist).
To take your alternative situation as an example. If somebody believes the US security measures to be fundamentally immoral, then they should feel free to *try* to circumvent them. If they get caught and killed for no gain, then they are obviously stupid, but they should still feel free to *try* to circumvent them. I beleive that nobody should tell them that they should not do it simply because the law in that area says it shouldn't be done. That is unless you are arguing that the mere existence of such a law changes the nature of the proscribed action to be immoral, though I don't pretend to say that you shouldn't tell him he'd be bloody dumb to try;) or that he shouldn't do it because his actions would result in a grossly immoral consequence.
The goal of good people should be to try to educate through example and unguided discussion on moral issues. Forced imprinting onto infants should be left to the parents, who should be educated in the manner above to encourage them to imprint whatever moral values you hold dear by convincing them that they are moral values that their children should hold dear too.
Nobody who holds strong liberal moral convictions should be complacent. So I encourage the poster to follow whatever course of action I deem not to be immoral:) Accessing material (where the accessing of which doesn't unreasonably encourage the breach of important moral values) is, in general, absolutely fine. Even if somebody with no right to stop you tells you that you are not allowed and tries to stop you. But don't be dumb, do think about the consequences.
I'm planning a "twister" input device. You spin the board, and depending on what it says, you have to put your limbs in different places. 'e' requires three people and a small plucked chicken.
> Maybe they'll show the futuristic sharpening of rocks to form crude weapons!
They already did that in Star Trek original series. Kirk versus a lizard, Kirk demonstrated the amazing sorcery that is gun powder, the lizard threw rocks and stuff.
These pads probably don't generate a field anywhere near as strong. since the currents for charging are probably on the order of a couple of amps at most. A domestic property can have anything up to a 100A main fuse, and with something like 4/5 circuits throughout the property, that's 20-25A per circuit. I'm not familiar with wiring regulations here in the UK (16th Edition, I think its called), but those numbers don't sound too wild.
I want this on my coffee table like their picture. I want a pad over my whole floor, with receivers in the feet of my tables and stuff, then another pad on tabletop.
I want to be able to move the table around and it'll just work with no cables trailing and my mobile devices in the middle of the room, where I can get at them
As an example there is a patent on using pointer exchange to swap two large data structures instead of swapping each member of the two structures. The patent applies to any software that is implementing a CPU emulation. So a very old technique is patented because nobody has documented that it has been used in a CPU emulator, even though it is just the same as any other case.
This is the problem, software is easy. It is trivially easy such that a teenager can master the most advanced of techniques. The only difficult thing is not making mistakes and missing bits out when you translate the logic into source code. That just takes discipline to write down each and every step in full and knowing how the language you are using actually works. It is thus certainly not patentable. However, I beleive that things like the psycological model that an mp3 encoder uses to select information to throw away might be reasonable to patent.
But many devices are just the sampling of a signal, then transformation, followed by the application of the result through an output device. The input device should be patentable if it is inventive and difficult, and so should the output device. The transformation used to be difficult when it consisted of cogs and cables and things. With software, when you know how the transformation should go, it is trivially easy, and thus should not be patentable.
I think this "Computer implemented invention" thing is supposed to cover the cost of discovering the necessary transformation. That could be reasonable if the transformation is a truly new and difficult thing to grasp. But I think a patent is still wrong for that. The effort has gone into mathematical calculations of the relationship between the input and output and the acceptable margins, and that effort should be protected enough to allow people to produce without cheap duplicates running the original producer out of business.
I think that the discovery of scientific knowledge for business purposes should be protected. That is what patents are supposed to do, but that has nothing to do with software, and no software technique should be patentable. Only the application of a specific transformation to convert a particular defined input to a particular defined output to complete a given physical (*not* logical) task should be covered. How you make the software do that is always trivial and should be always unpatentable. Making levers and cogs do it is hard and could be intrinsically patentable but not software.
The term used in C is the "Translation Unit". When you compile a.c file you are compiling a translation unit. If the C source file #includes the contents of another file, then those contents replace the #include line in what the compiler considers to be the code to be translated.
It doesn't matter what the file name is from the point of view of C, but a given compiler may use the last dot of the filename and the characters after it to determine which language it is, and whether it is a source file to be compiled or an object file to be linked.
That's a terrible conversion rate, I've been seriously looking for a new job for two years (only the last two months of which was I unemployed). I sent about 10x 2 page CVs roughly customised for the jobs, and mostly with cover letters. I have had 3 interviews (one of which was over the telephone) and am currently waiting to hear about the others. For the ones I have expected to hear something, I have converted 5 applications into 3 interviews, and 3 interviews into 0 jobs. That's a 60% application -> interview conversion. I am not counting my temping work in that at all, only serious applications for software engineer posts.
I have moved into the area that I want to work in now (hence being temporarily unemployed), and so I expect to convert my interviews more effectively now - as my increased availability and personal stability makes a job offer more valuable to an employer. I have also started aiming higher as I am more confident in my value now that I have left my previous job.
2600 applications -> 15 interviews is piss poor. You are either applying to low, or too high. Or your CV is crap.
PS, before this period of change, I have always converted applications to interviews at 100%, and interviews to offers also at 100%. It is not hard, you just have to be friendly, honest, and happen to have the skills and personality that they want. So your best hope for converting applications is to pick the right jobs to apply for. I believe that the reason it has become harder is that I have greater qualifications now, and many employers don't trust you to stay, ie, I have *had* to aim higher to make employers take me seriously to keep up the number of interviews.
From The Concise Oxford Dictionary of Current English (Ninth Edition - I believe there is now a Tenth Edition):
Programmen. & v. (US & Austral.program)
n.... 5 (usu. program) a series of coded instructions to control the operation of a computer or other machine.
v.tr. (programmed, programming)... 2 (usu. program) a provide (a computer etc.) with coded instructions for the automatic peformance of a particular task. b train to behave in a predetermined way.
Reread my post. An open source option that is new and not yet popular is frequently insecure (yes, there are exceptions, and the quality of the code can be seen and used to justify early adoption). Indeed, an *extreme* lack of popularity of a peice of Open Source software leaves its risk low just like closed source, but there you miss out on the benefits of rapid improvement without having to provide a large amount of development effort yourself.
I stand by my belief that the only option for Closed Source software developers as security becomes important to people is to create a product then migrate customers to an open alternative (or even open source their product), and then move on.
Furthermore, my analysis of security in general and clarification of the term "Security through obscurity" is, I believe, quite useful (enough to show the important principles) and a more effective way to close the neverending debate over the issue. In fact, I hold the same beliefs as you describe, I'm just a bit more liberal in principle. And if you look at my philosophical description of a key, then you will see that I unify both forms of obscurity and explain why a key is vastly superior to many other forms of access control (such as "you don't know my IP address", which is far too commonly used)
That's because they (are supposed to) get over 100UKP (approx 87USD at the moment - was around 92 a week or so ago) for every property with at least one sighted person under 75 in the UK with one or more colour televisions. And that is a lower bound - there are categories I haven't mentioned that pay less than the 100UKP or who have to pay more than once per property.
> the big advantage is in its five-fold efficiency gains
The article mentions that current polymer cells are six percent efficient, and that a combination of this polymer cell with the current best is 30%. But the current best is very close to 30% anyway. It is interesting as it has no aesthetic effect.
All security is by obscurity, that is a fundamental truth of any system whose state can be altered. You have to know how to get its state to change and if you know how then you can change its state.
The issue is how much knowledge do you need to be able to change the state of a part of the system, and how much effort do you have to put in to get that information. Also how likely are you to be caught attempting to learn how, and how much of the system can you break into with that information before you have to learn more information (essentially the value of that information).
Strong cryptographic authentication uses a mathematical formula to produce a *different* method of access for each key, and the key is a description of the method. Thus, cracking one key gives you access only to the systems that use the method that that key describes. For a weak cypher, it is relatively easy to determine the correct method to access a system.
Similarly for *all* communication with a computer. If you know what software is used, and you know how to get it to respond, then you have access. So, since you are *always* relying on attackers not knowing the method to access your systems, you must ensure there is a different method for each system to limit damage when the method is no longer obscure.
"Security Through Obscurity" refers to the technique where many system use the same method and depend on none of the other systems being cracked. This is risky: ie, chances of cracking are small, but cost of cracking is extremely expensive as all systems become vulnerable. Though chances are not so small as one may think as the value of the knowledge needed to access the systems is extremely high, and thus more effort tends to be dedicated to its discovery.
This is why open source software will tend to become more secure over time (provided that there is a sufficient interest in its security - ie popularity). While it is less costly to discover the information necessary to crack a system, it is also less costly for the organisations that use it to discover that information, thus the systems tend to be fixed. That also devalues the knowledge from the perspective of the cracker. How many organisations will send their disks to MS for analysis vs how many can do the analysis with reference to the source code.
All those little factors cause the initial risk of open source software to be much higher, but the risk of a mature and popular system to be lower. Compare with closed source, which for new and unpopular software the risk is low, and for mature and popular software, the risk is high.
The best opportunity (as the world begins to realise the value of security) for closed source producers is to be cheap to market, quick to help mature an open source competitor, and quick to help your customers migrate to the open source alternative, siphoning a lucrative support and development contract as you move onto new product as restart the cycle.
This is different from bittorrent for several reasons.
Streaming media requires data to arrive from the start to the end. bittorrent doesn't guarantee that the start arrives before the rest of the data. Actually bittorrent acts like it buffers for the duration of the stream - then the stream can play. This system sends the data in order so you only have to buffer for a short time - like any normal streaming protocol.
The second difference (as it appears from the documentation) is that this is just an icecast client and an icecast server rolled up together; basically a normal icecast relay but with a local display. Add in to that the ability to find relays using some sort of tracker and the clients can switch away from bad relays.
This is problematic if you end up having to keep hopping. What is needed is multiresolution codecs with low resolution data being sent by many peers (mirrored), and higher resolution data being interlaced among them (striped). That way you would be connected to several peers and a failure in any of them leaves the stream working at a slightly reduced quality until another peer can be connected. This doesn't necessarily mean using a multiresolution transform for audio and video, because the data is often separable into broad data and fine data anyway.
Slashdot Mirror
According to the EULA you can. Microsoft promises it right there on the first screen when you start the machine for the first time. Windows XP Home OEM is about 85-90 GBP here in blighty, so you can expect at 85 quid back when you return your XP license documents (about $140 or so).
> I really don't understand why graphics manufacturers don't simply include an OpenGL driver in the firmware
OpenGL may not be optimal for a hardware interface. You may want more light sources available from OpenGL than the card can do on its own. The interface to the hardware needs to support compositing of several renders to implement many more light sources than the hardware can do.
Furthermore, textures may use a sophisticated compression technique that must be done on the host CPU, the hardware will have to have registers programmed, and they may have a clever video RAM page mapping technique that gives them a large performance or temperature boost. they may not use IEEE floating point numbers in the same format as the host CPU and don't want to give away the format they use, or include extra silicon to decode them.
Lots of very good reasons for a business with interests in money rather than quality of service.
> If nVidia and ATi collaborated on the interface specification then they could even use the same drivers (driver initialises, driver checks for supported OpenGL version and extensions, driver loads emulated code paths for everything else), cutting their own driver development costs without having to expose any of the internal workings of their hardware.
They specifically want to avoid using the same drivers since driver performance is a *major* factor in performance in general, and they want to maintain any advantage they have in whatever areas they have. The first one to open up is the first one to lose the advantage.
The only solution is to design an open 3D video interface that supports the implementation of the very highest performance hardware, and write the drivers for it to the very highest quality. Then the first hardware manufacturer to port their core to the new interface (which could be a lot of work) might be the first to *gain* the advantage. Only then will you see any movement.
And I make no pretense that anything would happen even then.
You do realise that if you could just install any arbitrary peice of software as a non-privileged user, then any client app bug could be exploited to install anything.
And you don't normally have to download firefox, since it tends to be included on installation disks now.
> but what about the people who wanted to actually get some work done in that time frame
:) How good is that?
Easy, they just used Linux, so where's the problem? Now you could use Linux and get your work done, meanwhile they've been creating the next generation of OS technology that much Linux kernel code will probably be ported to so you can make an evolutionary step to a system with very, very high reliability features. Plus extreme flexibility.
The GPL applies if one does anything normally prohibited by copyright law. If linking means creating a derivative work, then yes. In the case of static linking certainly, in the case of dynamic linking, perhaps not. When dynamic linking, you could still have art from one work included via C preprocessor macro or something (or a C++ template instantiation), but otherwise, all you have will be reference numbers and lists of required symbols, and I don't think either can be covered by copyright. The UK patent and trademark office lists a right called database right where the effort to build a database of information and relations is protected, but I don't think that is protected since the effort to collate the required symbols is not undertaken by the producer of the linked to library.
If a software producer distributes the GPLd library along with their own work that uses the symbols, that *could* constitute a derived work, but mere use of those symbols from a library with that name does not mean that the application is derived from *that* library, since the same interface could also be implemented under a different license, and even by themselves. That is what you get for defining interfaces - exchangeable implementations, so apps using the interface are separate things not both a part of one work.
There's a little script I found that I use on my web page, though I know it doesn't all quite work, but then Windows users can all go install Firefox.
Haha, Q and his little jokes :) I bet those crew members had sore heads in the morning.
There's little difference between some guy in some small town in China and some guy in some small town in Sweden. If it is morally unacceptable treatment to apply to the guy in Sweden, then it is morally unacceptable treatment to apply to the guy in China. After all, I'm sure it's not the Chinese guy's fault that he is subject to the whims of an authoritarian power centre.
;) or that he shouldn't do it because his actions would result in a grossly immoral consequence.
:) Accessing material (where the accessing of which doesn't unreasonably encourage the breach of important moral values) is, in general, absolutely fine. Even if somebody with no right to stop you tells you that you are not allowed and tries to stop you. But don't be dumb, do think about the consequences.
You can't just say it is okay because it is the authoritarian power centre's geographic area to do whatever they wish to the people it is beneath. The reason for that is that it is not the authoritarian power centre's geographic area, it belongs to the people that need the land to survive (especially since the power centre itself claims to be communist).
To take your alternative situation as an example. If somebody believes the US security measures to be fundamentally immoral, then they should feel free to *try* to circumvent them. If they get caught and killed for no gain, then they are obviously stupid, but they should still feel free to *try* to circumvent them. I beleive that nobody should tell them that they should not do it simply because the law in that area says it shouldn't be done. That is unless you are arguing that the mere existence of such a law changes the nature of the proscribed action to be immoral, though I don't pretend to say that you shouldn't tell him he'd be bloody dumb to try
The goal of good people should be to try to educate through example and unguided discussion on moral issues. Forced imprinting onto infants should be left to the parents, who should be educated in the manner above to encourage them to imprint whatever moral values you hold dear by convincing them that they are moral values that their children should hold dear too.
Nobody who holds strong liberal moral convictions should be complacent. So I encourage the poster to follow whatever course of action I deem not to be immoral
And with the new "citizenship lessons" planned in schools, we're going to look like the USSR *60* years ago. All thanks to Comrade Blair.
Bloody authoritarian commies.
What'll be next? Blair's Youth?
I'm planning a "twister" input device. You spin the board, and depending on what it says, you have to put your limbs in different places. 'e' requires three people and a small plucked chicken.
> Maybe they'll show the futuristic sharpening of rocks to form crude weapons!
They already did that in Star Trek original series. Kirk versus a lizard, Kirk demonstrated the amazing sorcery that is gun powder, the lizard threw rocks and stuff.
These pads probably don't generate a field anywhere near as strong. since the currents for charging are probably on the order of a couple of amps at most. A domestic property can have anything up to a 100A main fuse, and with something like 4/5 circuits throughout the property, that's 20-25A per circuit. I'm not familiar with wiring regulations here in the UK (16th Edition, I think its called), but those numbers don't sound too wild.
I want this on my coffee table like their picture. I want a pad over my whole floor, with receivers in the feet of my tables and stuff, then another pad on tabletop.
I want to be able to move the table around and it'll just work with no cables trailing and my mobile devices in the middle of the room, where I can get at them
As an example there is a patent on using pointer exchange to swap two large data structures instead of swapping each member of the two structures. The patent applies to any software that is implementing a CPU emulation. So a very old technique is patented because nobody has documented that it has been used in a CPU emulator, even though it is just the same as any other case.
This is the problem, software is easy. It is trivially easy such that a teenager can master the most advanced of techniques. The only difficult thing is not making mistakes and missing bits out when you translate the logic into source code. That just takes discipline to write down each and every step in full and knowing how the language you are using actually works. It is thus certainly not patentable. However, I beleive that things like the psycological model that an mp3 encoder uses to select information to throw away might be reasonable to patent.
But many devices are just the sampling of a signal, then transformation, followed by the application of the result through an output device. The input device should be patentable if it is inventive and difficult, and so should the output device. The transformation used to be difficult when it consisted of cogs and cables and things. With software, when you know how the transformation should go, it is trivially easy, and thus should not be patentable.
I think this "Computer implemented invention" thing is supposed to cover the cost of discovering the necessary transformation. That could be reasonable if the transformation is a truly new and difficult thing to grasp. But I think a patent is still wrong for that. The effort has gone into mathematical calculations of the relationship between the input and output and the acceptable margins, and that effort should be protected enough to allow people to produce without cheap duplicates running the original producer out of business.
I think that the discovery of scientific knowledge for business purposes should be protected. That is what patents are supposed to do, but that has nothing to do with software, and no software technique should be patentable. Only the application of a specific transformation to convert a particular defined input to a particular defined output to complete a given physical (*not* logical) task should be covered. How you make the software do that is always trivial and should be always unpatentable. Making levers and cogs do it is hard and could be intrinsically patentable but not software.
The term used in C is the "Translation Unit". When you compile a .c file you are compiling a translation unit. If the C source file #includes the contents of another file, then those contents replace the #include line in what the compiler considers to be the code to be translated.
It doesn't matter what the file name is from the point of view of C, but a given compiler may use the last dot of the filename and the characters after it to determine which language it is, and whether it is a source file to be compiled or an object file to be linked.
That's a terrible conversion rate, I've been seriously looking for a new job for two years (only the last two months of which was I unemployed). I sent about 10x 2 page CVs roughly customised for the jobs, and mostly with cover letters. I have had 3 interviews (one of which was over the telephone) and am currently waiting to hear about the others. For the ones I have expected to hear something, I have converted 5 applications into 3 interviews, and 3 interviews into 0 jobs. That's a 60% application -> interview conversion. I am not counting my temping work in that at all, only serious applications for software engineer posts.
I have moved into the area that I want to work in now (hence being temporarily unemployed), and so I expect to convert my interviews more effectively now - as my increased availability and personal stability makes a job offer more valuable to an employer. I have also started aiming higher as I am more confident in my value now that I have left my previous job.
2600 applications -> 15 interviews is piss poor. You are either applying to low, or too high. Or your CV is crap.
PS, before this period of change, I have always converted applications to interviews at 100%, and interviews to offers also at 100%. It is not hard, you just have to be friendly, honest, and happen to have the skills and personality that they want. So your best hope for converting applications is to pick the right jobs to apply for. I believe that the reason it has become harder is that I have greater qualifications now, and many employers don't trust you to stay, ie, I have *had* to aim higher to make employers take me seriously to keep up the number of interviews.
Reread my post. An open source option that is new and not yet popular is frequently insecure (yes, there are exceptions, and the quality of the code can be seen and used to justify early adoption). Indeed, an *extreme* lack of popularity of a peice of Open Source software leaves its risk low just like closed source, but there you miss out on the benefits of rapid improvement without having to provide a large amount of development effort yourself.
I stand by my belief that the only option for Closed Source software developers as security becomes important to people is to create a product then migrate customers to an open alternative (or even open source their product), and then move on.
Furthermore, my analysis of security in general and clarification of the term "Security through obscurity" is, I believe, quite useful (enough to show the important principles) and a more effective way to close the neverending debate over the issue. In fact, I hold the same beliefs as you describe, I'm just a bit more liberal in principle. And if you look at my philosophical description of a key, then you will see that I unify both forms of obscurity and explain why a key is vastly superior to many other forms of access control (such as "you don't know my IP address", which is far too commonly used)
However you wouldn't say "I hate Microsoft, it is a bastard," would you?
Ah, the same response policy as they have for "ran out of spam", and "the parrot died".
That's because they (are supposed to) get over 100UKP (approx 87USD at the moment - was around 92 a week or so ago) for every property with at least one sighted person under 75 in the UK with one or more colour televisions. And that is a lower bound - there are categories I haven't mentioned that pay less than the 100UKP or who have to pay more than once per property.
I heard it was actually located in some old cottage in the countryside.
> the big advantage is in its five-fold efficiency gains
The article mentions that current polymer cells are six percent efficient, and that a combination of this polymer cell with the current best is 30%. But the current best is very close to 30% anyway. It is interesting as it has no aesthetic effect.
> Just remember, security by obscurity is bad! ;)
All security is by obscurity, that is a fundamental truth of any system whose state can be altered. You have to know how to get its state to change and if you know how then you can change its state.
The issue is how much knowledge do you need to be able to change the state of a part of the system, and how much effort do you have to put in to get that information. Also how likely are you to be caught attempting to learn how, and how much of the system can you break into with that information before you have to learn more information (essentially the value of that information).
Strong cryptographic authentication uses a mathematical formula to produce a *different* method of access for each key, and the key is a description of the method. Thus, cracking one key gives you access only to the systems that use the method that that key describes. For a weak cypher, it is relatively easy to determine the correct method to access a system.
Similarly for *all* communication with a computer. If you know what software is used, and you know how to get it to respond, then you have access. So, since you are *always* relying on attackers not knowing the method to access your systems, you must ensure there is a different method for each system to limit damage when the method is no longer obscure.
"Security Through Obscurity" refers to the technique where many system use the same method and depend on none of the other systems being cracked. This is risky: ie, chances of cracking are small, but cost of cracking is extremely expensive as all systems become vulnerable. Though chances are not so small as one may think as the value of the knowledge needed to access the systems is extremely high, and thus more effort tends to be dedicated to its discovery.
This is why open source software will tend to become more secure over time (provided that there is a sufficient interest in its security - ie popularity). While it is less costly to discover the information necessary to crack a system, it is also less costly for the organisations that use it to discover that information, thus the systems tend to be fixed. That also devalues the knowledge from the perspective of the cracker. How many organisations will send their disks to MS for analysis vs how many can do the analysis with reference to the source code.
All those little factors cause the initial risk of open source software to be much higher, but the risk of a mature and popular system to be lower. Compare with closed source, which for new and unpopular software the risk is low, and for mature and popular software, the risk is high.
The best opportunity (as the world begins to realise the value of security) for closed source producers is to be cheap to market, quick to help mature an open source competitor, and quick to help your customers migrate to the open source alternative, siphoning a lucrative support and development contract as you move onto new product as restart the cycle.
I can't imagine anybody using this for long.
This is different from bittorrent for several reasons.
Streaming media requires data to arrive from the start to the end. bittorrent doesn't guarantee that the start arrives before the rest of the data. Actually bittorrent acts like it buffers for the duration of the stream - then the stream can play. This system sends the data in order so you only have to buffer for a short time - like any normal streaming protocol.
The second difference (as it appears from the documentation) is that this is just an icecast client and an icecast server rolled up together; basically a normal icecast relay but with a local display. Add in to that the ability to find relays using some sort of tracker and the clients can switch away from bad relays.
This is problematic if you end up having to keep hopping. What is needed is multiresolution codecs with low resolution data being sent by many peers (mirrored), and higher resolution data being interlaced among them (striped). That way you would be connected to several peers and a failure in any of them leaves the stream working at a slightly reduced quality until another peer can be connected. This doesn't necessarily mean using a multiresolution transform for audio and video, because the data is often separable into broad data and fine data anyway.