"Good guys" outnumber "bad guys". There is always a greater probability that any bug in Open Source software will be discovered first by a "good guy" than by a "bad guy".
One question that ought to be asked is: Does Ubuntu actually expose any services to the outside world by default? I know Debian doesn't. If you actually need physical access to the box in order to exploit a security threat, it's not that serious anyway: with physical access to a machine, most security measures can be defeated.
Only two bytes? That's a limitation of 65536 chars -- not that much really when you think about it. For crying out loud, we have 64-bit processors now. Please, let's think of the future, and reserve eight bytes for string length -- just in case somebody ever wants to put the entire addressable space into a scalar.
If you live in the EU or the UK, and certain other countries, a software MP3 player licence costs nothing; the patents in question are not valid in those countries.
A bootstrap loader sits in the Master Boot Record -- the first 512 bytes on the disc. The BIOS knows how to position the reading heads at any cylinder and sector on the disc's surface and select the signal from any head. It knows precious little else. What it does when first switched on is go to head 0, cylinder 0, sector 0 {which is the only sector you can be absolutely cast-iron certain will definitely always exist, no matter what size drive it is}; read that sector, which is 512 bytes big, into memory; and begin executing it as instructions.
Within the space of those 512 bytes, you have to have a program which loads the operating system proper. It can use BIOS calls to find any place on the disc {or just within the first 1024 cylinders, if it's a really ancient BIOS} in order to do this. Once the operating system itself has loaded, it no longer needs to rely on the BIOS's own methods of accessing the disk; it can talk to devices directly.
Windows has a bootstrap loader of its own, which goes in the MBR. Grub also goes in the MBR. Even Lilo, the original bootstrap loader which had nothing wrong with it in the first place before Grub became all trendy, goes in the MBR. When you installed Grub, you overwrote Windows' own bootstrap loader. It is now lost for all time.
The solution is to replace the MBR. Either boot up with a Windows CD and do
C:\> fdisk/mbr to install the MBR from Windows; or boot up with the kernel from a Linux boot CD, using a cheatcode to specify your usual root file system:
boot: linux root=/dev/hda1 {or whatever partition it's on}, and then re-configure Grub. Or preferably just install Lilo instead.
I hope this explains why you can't have a fallback when the bootstrap loader fails. In the Olden Days, with no bootstrap loader you would have been given a simple memory editor which would allow you to display the contents of memory, enter instructions and data in hexadecimal, and begin executing instructions from memory. Things like this would be useful to programmers {you could type in a bootstrap loader by hand if you needed to}, but they stopped being popular about the time more non-programmers started buying computers. More sophisticated display devices began needing more sophisticated BIOSes, and the hex editor {which most users would not know how to use anyway} was squozen out to make room.
Not really. I'm just pointing out that the UK has just passed a law which is going to enable fraud on a massive scale, despite what commentators in other countries are saying.
Some UK banks tried charging customers who withdrew their cash from other banks' HITW machines {e.g. a NatWest customer would be charged by NatWest for using a Midland Bank [as they used to be called in those days] machine; Midland Bank meanwile could truly proclaim "Midland Bank will not charge you for use of this machine"}. When they lost customers as a result of this policy, they had a rethink. There will be roughly as many of your customers using other banks' machines as there are other banks' customers using yours, so it all sort of evens itself out. Otherwise you're spending a shilling to chase a penny.
I still don't see how charging people to withdraw money from their bank accounts {into which your wages or benefits are paid by law -- you can no longer be paid in cash} is anything but a protection racket.
I don't know the name of the Act of Parliament nor the SI number, but it became law on 14 February that retailers could refuse signature-backed transactions for credit and debit cards.
Are you sure you are thinking of the same government as my e-mail address suggests?
You get these machines in pubs, newsagents and bankless corners of shopping centres in the UK too. They do carry a prominent warning, "DO NOT USE THIS MACHINE" {although it's actually spelt "£1.50 CHARGE PER TRANSACTION"}.
They're a scammer's wet dream. Everyone who uses them is financially inept {otherwise they'd walk a few hundred metres further to a bank and withdraw their cash for free}. If you were so motivated, it would be worth building a "convincing fake" cash dispenser and stumping up some money just to obtain a few cards {either to clone, or by having the machine eat them} and PINs.
How charging people a fee to withdraw their own money from a bank account is not illegal under the same laws that ban protection rackets, is a mystery to me.
The problem with so-called "one way" hash functions, is that they aren't.
Trying to work back through the published algorithm from output to input leaves you with a set of simultaneous equations for which you have more variables than equations. But that's OK. You just pick any old values for the variables you can't get. Now it may not match the original PIN; but it'll certainly give the same output value when you run it through the hashing algorithm.
"Security is tight at the ATM, but point-of-sale is a whole other story," said Litan. "Look at your [debit card] account on a regular basis, and don't use a PIN-based debit card at point-of-sale," she recommended. "I never do."
Tell that to our government, who have made retailers change over from signature-backed debit cards to Chip and PIN in the false pretence that this is "more secure" and will "cut fraud".
It takes an hour at best to learn to forge a signature convincingly -- that's an hour in which you can notice that your card is not about your person, and call the missing card hotline {number conveniently printed on your card.....} On the other hand, discovering a four-digit PIN takes a matter of seconds, when you have a knife to your victim's throat [*]. You'll be photographed and caught for certain if you try using a HITW. You might be caught on a store's private CCTV if you use someone else's Chip and PIN card to pay for your shopping, but there's a good chance that the victim's bank won't be able to get hold of the recording in time, or some other technicality may get in the way.
Chip and PIN is liked by Big Business because it removes the need for a human being {the checkout operator} to make a decision as to the validity of a signature. It "reduces fraud" by virtue of the simple fact that every transaction with a correct PIN is presumed to be valid. The cards are harder to clone right now; but where there's a will, there's always a way, and one would have to be extremely naïve to imagine that criminals are not working on the problem right now. When that happens, expect total and utter chaos; PINs will be obtained by shoulder-surfing [+], and cards will go missing only for as long as it takes to clone them. Even if the card is constructed so as to change state after each transaction, this is not perfect because it creates a classic race condition; if the clone card is used first, it will be the original card which is in the wrong state. If the cloning emulates the state machine logic perfectly, the clone card will even be good for more transactions.
[*] Having stolen your debit card and phone, and learned your PIN, the robber hands them to an accomplice who makes the purchase; all the while the robber stands guard over you, just in case you *ahem* mis-remembered your PIN and the accomplice has to phone the robber to prompt you.
[+] Chip-and-PIN keypads as I have seen so far use a static arrangement and usually are positioned at the best height and angle for reading the user's keystrokes from behind. It would be more secure, though highly counter-intuitive and error-prone, for the keypads to use a touch screen with a variable layout.
Asterisk can do plenty to keep Skype from creating closed-source modules. They can change the API in various subtle ways. It won't matter much to Asterisk users -- you pretty much have to compile it from source everytime anyway. But it will slow Skype down considerably if users have to patch their Asterisk to match the API version against which the Skype plugin was compiled.
Asterisk is militantly Open Source. Skype is closed source. The only way Asterisk will ever support Skype is indirectly; if someone creates a compatible alternative to Skype, and releases it under the GPL.
It's going to take a lot of French Café work, or possibly even an inside job, to hack Skype's protocols open; and it's more likely that Skype will go out of business before that happens.
ajs318@marijuana $ whois di.eu %.eu Whois Server 1.0 % % (c) 2005 (http://www.eurid.eu/ % % The WHOIS service offered by EURid and the access to the records % in the EURid WHOIS database are provided for information purposes % only. It allows persons to check whether a specific domain name % is still available or not and to obtain information related to % the registration records of existing domain names. % % EURid cannot, under any circumstances, be held liable in case the % stored information would prove to be wrong, incomplete or not % accurate in any sense. % % By submitting a query you agree not to use the information made % available to: % % - allow, enable or otherwise support the transmission of unsolicited, % commercial advertising or other solicitations whether via email or % otherwise; % - target advertising in any possible way; % % - to cause nuisance in any possible way to the registrants by sending % (whether by automated, electronic processes capable of enabling % high volumes or other possible means) messages to them. % % Without prejudice to the above, it is explicitly forbidden to extract, % copy and/or use or re-utilise in any form and by any means % (electronically or not) the whole or a quantitatively or qualitatively % substantial part of the contents of the WHOIS database without prior % and explicit permission by EURid, nor in any attempt hereof, to apply % automated, electronic processes to EURid (or its systems). % % You agree that any reproduction and/or transmission of data for % commercial purposes will always be considered as the extraction of a % substantial part of the content of the WHOIS database. % % By submitting the query you agree to abide by this policy and accept % that EURid can take measures to limit the use of its WHOIS services % in order to protect the privacy of its registrants or the integrity % of the database. % % WHOIS di Domain: di Status: APPLICATION PENDING
Looks like that one's probably going to be taken, then.
If we're expecting a straightforward repeat of VHS vs. Beta, then it will go something like this: The first round of Early Adopters will buy both systems in quantities roughly proportional to manufacturers' established market shares {Sony and Sanyo made Beta kit; JVC supplied cheap VHS machines, built under licence in sewing-machine factories, to rental companies for badge-engineering}. One system will eventually come to dominate, for a reason ultimately determined by neither the consumers nor the manufacturers {VHS recorders, which were mainly supplied on a rental basis, were more easily field-maintained than the technically-superior Beta system}.
However, this time around there will be a crucial difference. When Beta died out, and customers renting Beta machines had to be supplied with VHS replacements, the rental companies took it upon themselves to copy users' accumulated tape libraries onto the new format {Macrovision had not been invented then}. This time, owners of the "failed" format will simply be expected to purchase their favourite films again, to the benefit of the movie studios.
So you bought a film once on VHS, again on VHS because the first one wore out, then on DVD, then once {if you picked the winner of the new format wars from day one} or twice {if you didn't} on the new, high-definition discs.
The crucial deciding factor with cassettes turned out to be field-maintenance. I'm guessing that this time, with new high-definition discs, the crucial deciding factor will be how easily any intended consumer-shafting measures {under the colour of copy-prevention} can be defeated. The important company to watch here is Sony, because they make the discs and the players; so they are unlikely to make copying easy on their players, since they would be shooting themselves in the foot. Player manufacturers who are not involved in the content industry have less to worry about {and the people working in their labs, who are ideally-placed to introduce backdoors, enjoy a movie as much as the next person.....}
Encrypted VOIP will be damn nigh impossible to tax or regulate. Encrypted traffic is just encrypted data; and there is no way to know what it is without decrypting it. Which, depending on the encryption algorithm, may well take a long, long time and is not even certain to produce anything useful {since any given cyphertext could be the result of any one of a large number of plaintext/key pairs}.
Skype is reckoned to be encrypted, but this claim cannot be verified, as the source code is not available for perusal; it must be assumed that at least Skype themselves, and possibly The Authorities, have the power to listen to Skype calls.
SIP or IAX over SSL/TLS would be much more secure, since these are open protocols and the only secret is the encryption key.
If GPG had been a closed-source product, almost nobody would ever have known about the flaw. People would just have carried on using it [*], believing it safe, and the exploit would have stayed underground. It's precisely because it's Open Source that anybody discovered the problem at all. At least now, it can be fixed -- in fact, it already has been fixed.
[*] Well, actually, they wouldn't, because using closed-source crypto is up there in the top ten Bloody Stupid Ideas, along with using a scythe to cut your toenails. And I hope I do not have to explain why.
I think you are misunderstanding what is meant by "the fruits of all human endeavour".
I'm not referring to actual physical objects. I'm referring to the abstract concepts which underlie those objects; for instance, not loaves of bread, but knowing how to bake a loaf of bread. Think like the pure mathematician, who considers their work done when they have reduced a problem to a set of equations that they know they can solve {rather than when those equations themselves are solved, which would be mechanical work}.
I'm not missing the distinction at all, it's just completely beside the point. Some software I write I won't give to anyone unless they first agree to certain terms, and if they violate those terms, then they're committing fraud against me.
By the very act of choosing who you do and do not wish to give the software to, you are committing violence against those to whom you choose not to give the software. You may have written the software, but it belongs to everyone. Those to whom you choose not to give it, are justified in using reasonable force to obtain it.
And if that GNazi Richard Stallman ever gets his way, and succeeds in taking away the right of free contract from myself and many other software developers, trust me, you'll see a lot less software being produced, and that will be a form of artificial scarcity.
Software which is written for the sole purpose of making money is software we can do without. We did not need it before it was written, and we will not need it afterward. We may see a drop in the quantity of software written, but that will be offset by an improvement in the quality of software being written -- since it will be written with the purest motives in mind, and there will be no onus on the supplier to cut corners.
At the moment, it is possible using Reasonable Force to ENJOY and SHARE all software; but to STUDY or ADAPT software requires access to the Source Code. The question then becomes, can we devise a technique for forcibly obtaining access to the source code? If so, then we have all the prerequisites to take what is ours, without needing anyone else's say-so: all software will effectively be Open Source.
Now, suppose there was some software tool that would accept a compiled program as its input; and output a file containing some source code that, when compiled, would be exactly equivalent to the original input. Such a program would be the functional opposite of a compiler -- in other words, a decompiler.
The decompiler output would not necessarily be identical to the original Source Code -- indeed, it need not even be in the same programming language. In particular, variable and function names might well be lost {there is little need for them to be retained in the object code, and historically there have been good reasons for them to be discarded}. However, this step already gives a hacker a great deal of leverage; it re-creates the abstraction that exists between choosing what high-level language statements to use to solve the problem {analogous to poetry}, and how to tell the computer what machine-language instructions to use to carry out those steps {analogous to calligraphy}. Now our hacker need no longer think in terms of "the floating-point number stored in locations $ce08-$ce0C" but in terms of "float1". One whose experience is in pure mathematics might recognise an expression of the form
and deduce more meaningful names for the variables from the context in which they are used. Additional clues may well exist in the text of messages and prompts.
Mathematically, the problems of decompilation are identical to the problems of shape recognition: consider machine language instructions as vertices, and high-level language structures {such as statements, loops and functions} as more or less complex shapes. Now, which vertices are most likely to belong to what shapes? Which sequences of machine-language instructions correspond to what high-level instructions?
A decompiler would have value for other applications beside reverse-engineering closed source software, even if we discount the possibility that the author of a program might ever need to recover it after some catastrophe has befallen the original. Subject to the ability of compilers to preserve variable and function names {a standard debugging aid, which could easily be added to an Open Source compiler which lacked it} and decompilers to retrieve and make use of this information, it ought to be possible to decompile a program written in one language into a different language. This would allow an exciting new form of collaboration, since it would remove the need for programmers working together on a project to know the same programming language.
You are still missing the important distinction. Certain things -- such as a car -- will be diminished by the act of sharing, and so can be considered subject to ownership. Other things are not diminished by sharing. The canonical example being that if you light a candle from my already-lit candle and then take it away, my room does not get any darker than it was before. Such things are, once a prototype exists, infinitely plentiful and cannot be considered subject to ownership.
If I copy a piece of software from you, you still have the original. You lose exclusivity over that software -- but that would be a form of artificial scarcity, which is absolutely not welcome in the Age of Plenty.
Please cite the paragraph in GPL3 {2006-01-16 draft as shown here} which you believe would oblige you to provide the source code as you state.
It is my understanding that the source code for those parts of a web application which run only the server end, need not be made accessible to users accessing the application via the web. Of course, the source code for those parts of a web application which run on the client end -- assuming that it be written in an interpreted language such as JavaScript-- is already accessible to users.
In any case, your complaint about having to insert source download links if you set up a web application is rather like complaining that if you invite members of the public into your private property, you have to provide fire exit signs.
My car is a fruit of my endeavors. Come to my house sometime and try to drive it away and see what happens to you.
I am not asking to drive away your car -- then you would no longer have it. However, I believe that I would be perfectly within my rights to run my own measuring instruments over your car some time while you were not using it, taking all reasonable care not to damage your car, and take notes on my own pad with my own pencil; then build another car, exactly like yours or with certain differences of my own choosing, using my own materials, my own tools and my own labour.
That is the fundamental difference. As the manifesto says, "Software can be shared without being diminished by the act of sharing".
Slashdot Mirror
"Good guys" outnumber "bad guys". There is always a greater probability that any bug in Open Source software will be discovered first by a "good guy" than by a "bad guy".
One question that ought to be asked is: Does Ubuntu actually expose any services to the outside world by default? I know Debian doesn't. If you actually need physical access to the box in order to exploit a security threat, it's not that serious anyway: with physical access to a machine, most security measures can be defeated.
Only two bytes? That's a limitation of 65536 chars -- not that much really when you think about it. For crying out loud, we have 64-bit processors now. Please, let's think of the future, and reserve eight bytes for string length -- just in case somebody ever wants to put the entire addressable space into a scalar.
Already happened. Debian took three years to get Sarge declared "stable"!
If you live in the EU or the UK, and certain other countries, a software MP3 player licence costs nothing; the patents in question are not valid in those countries.
A bootstrap loader sits in the Master Boot Record -- the first 512 bytes on the disc. The BIOS knows how to position the reading heads at any cylinder and sector on the disc's surface and select the signal from any head. It knows precious little else. What it does when first switched on is go to head 0, cylinder 0, sector 0 {which is the only sector you can be absolutely cast-iron certain will definitely always exist, no matter what size drive it is}; read that sector, which is 512 bytes big, into memory; and begin executing it as instructions.
/mbr
Within the space of those 512 bytes, you have to have a program which loads the operating system proper. It can use BIOS calls to find any place on the disc {or just within the first 1024 cylinders, if it's a really ancient BIOS} in order to do this. Once the operating system itself has loaded, it no longer needs to rely on the BIOS's own methods of accessing the disk; it can talk to devices directly.
Windows has a bootstrap loader of its own, which goes in the MBR. Grub also goes in the MBR. Even Lilo, the original bootstrap loader which had nothing wrong with it in the first place before Grub became all trendy, goes in the MBR. When you installed Grub, you overwrote Windows' own bootstrap loader. It is now lost for all time.
The solution is to replace the MBR. Either boot up with a Windows CD and do
C:\> fdisk
to install the MBR from Windows; or boot up with the kernel from a Linux boot CD, using a cheatcode to specify your usual root file system:
boot: linux root=/dev/hda1
{or whatever partition it's on}, and then re-configure Grub. Or preferably just install Lilo instead.
I hope this explains why you can't have a fallback when the bootstrap loader fails. In the Olden Days, with no bootstrap loader you would have been given a simple memory editor which would allow you to display the contents of memory, enter instructions and data in hexadecimal, and begin executing instructions from memory. Things like this would be useful to programmers {you could type in a bootstrap loader by hand if you needed to}, but they stopped being popular about the time more non-programmers started buying computers. More sophisticated display devices began needing more sophisticated BIOSes, and the hex editor {which most users would not know how to use anyway} was squozen out to make room.
Not really. I'm just pointing out that the UK has just passed a law which is going to enable fraud on a massive scale, despite what commentators in other countries are saying.
Some UK banks tried charging customers who withdrew their cash from other banks' HITW machines {e.g. a NatWest customer would be charged by NatWest for using a Midland Bank [as they used to be called in those days] machine; Midland Bank meanwile could truly proclaim "Midland Bank will not charge you for use of this machine"}. When they lost customers as a result of this policy, they had a rethink. There will be roughly as many of your customers using other banks' machines as there are other banks' customers using yours, so it all sort of evens itself out. Otherwise you're spending a shilling to chase a penny.
I still don't see how charging people to withdraw money from their bank accounts {into which your wages or benefits are paid by law -- you can no longer be paid in cash} is anything but a protection racket.
I don't know the name of the Act of Parliament nor the SI number, but it became law on 14 February that retailers could refuse signature-backed transactions for credit and debit cards.
Are you sure you are thinking of the same government as my e-mail address suggests?
You get these machines in pubs, newsagents and bankless corners of shopping centres in the UK too. They do carry a prominent warning, "DO NOT USE THIS MACHINE" {although it's actually spelt "£1.50 CHARGE PER TRANSACTION"}.
They're a scammer's wet dream. Everyone who uses them is financially inept {otherwise they'd walk a few hundred metres further to a bank and withdraw their cash for free}. If you were so motivated, it would be worth building a "convincing fake" cash dispenser and stumping up some money just to obtain a few cards {either to clone, or by having the machine eat them} and PINs.
How charging people a fee to withdraw their own money from a bank account is not illegal under the same laws that ban protection rackets, is a mystery to me.
The problem with so-called "one way" hash functions, is that they aren't.
Trying to work back through the published algorithm from output to input leaves you with a set of simultaneous equations for which you have more variables than equations. But that's OK. You just pick any old values for the variables you can't get. Now it may not match the original PIN; but it'll certainly give the same output value when you run it through the hashing algorithm.
It takes an hour at best to learn to forge a signature convincingly -- that's an hour in which you can notice that your card is not about your person, and call the missing card hotline {number conveniently printed on your card
Chip and PIN is liked by Big Business because it removes the need for a human being {the checkout operator} to make a decision as to the validity of a signature. It "reduces fraud" by virtue of the simple fact that every transaction with a correct PIN is presumed to be valid. The cards are harder to clone right now; but where there's a will, there's always a way, and one would have to be extremely naïve to imagine that criminals are not working on the problem right now. When that happens, expect total and utter chaos; PINs will be obtained by shoulder-surfing [+], and cards will go missing only for as long as it takes to clone them. Even if the card is constructed so as to change state after each transaction, this is not perfect because it creates a classic race condition; if the clone card is used first, it will be the original card which is in the wrong state. If the cloning emulates the state machine logic perfectly, the clone card will even be good for more transactions.
[*] Having stolen your debit card and phone, and learned your PIN, the robber hands them to an accomplice who makes the purchase; all the while the robber stands guard over you, just in case you *ahem* mis-remembered your PIN and the accomplice has to phone the robber to prompt you.
[+] Chip-and-PIN keypads as I have seen so far use a static arrangement and usually are positioned at the best height and angle for reading the user's keystrokes from behind. It would be more secure, though highly counter-intuitive and error-prone, for the keypads to use a touch screen with a variable layout.
Asterisk can do plenty to keep Skype from creating closed-source modules. They can change the API in various subtle ways. It won't matter much to Asterisk users -- you pretty much have to compile it from source everytime anyway. But it will slow Skype down considerably if users have to patch their Asterisk to match the API version against which the Skype plugin was compiled.
Asterisk is militantly Open Source. Skype is closed source. The only way Asterisk will ever support Skype is indirectly; if someone creates a compatible alternative to Skype, and releases it under the GPL.
It's going to take a lot of French Café work, or possibly even an inside job, to hack Skype's protocols open; and it's more likely that Skype will go out of business before that happens.
DVD frames still only contain 576 lines of 720 pixels each. All you are doing by "upsampling" is making the pixels bigger.
The format war benefits the Hollywood studios.
.....}
If we're expecting a straightforward repeat of VHS vs. Beta, then it will go something like this: The first round of Early Adopters will buy both systems in quantities roughly proportional to manufacturers' established market shares {Sony and Sanyo made Beta kit; JVC supplied cheap VHS machines, built under licence in sewing-machine factories, to rental companies for badge-engineering}. One system will eventually come to dominate, for a reason ultimately determined by neither the consumers nor the manufacturers {VHS recorders, which were mainly supplied on a rental basis, were more easily field-maintained than the technically-superior Beta system}.
However, this time around there will be a crucial difference. When Beta died out, and customers renting Beta machines had to be supplied with VHS replacements, the rental companies took it upon themselves to copy users' accumulated tape libraries onto the new format {Macrovision had not been invented then}. This time, owners of the "failed" format will simply be expected to purchase their favourite films again, to the benefit of the movie studios.
So you bought a film once on VHS, again on VHS because the first one wore out, then on DVD, then once {if you picked the winner of the new format wars from day one} or twice {if you didn't} on the new, high-definition discs.
The crucial deciding factor with cassettes turned out to be field-maintenance. I'm guessing that this time, with new high-definition discs, the crucial deciding factor will be how easily any intended consumer-shafting measures {under the colour of copy-prevention} can be defeated. The important company to watch here is Sony, because they make the discs and the players; so they are unlikely to make copying easy on their players, since they would be shooting themselves in the foot. Player manufacturers who are not involved in the content industry have less to worry about {and the people working in their labs, who are ideally-placed to introduce backdoors, enjoy a movie as much as the next person
Oops. My bad. I meant, the only secret is the decryption key. Now I'm going to bash my head against the desk for an hour.
Encrypted VOIP will be damn nigh impossible to tax or regulate. Encrypted traffic is just encrypted data; and there is no way to know what it is without decrypting it. Which, depending on the encryption algorithm, may well take a long, long time and is not even certain to produce anything useful {since any given cyphertext could be the result of any one of a large number of plaintext/key pairs}.
Skype is reckoned to be encrypted, but this claim cannot be verified, as the source code is not available for perusal; it must be assumed that at least Skype themselves, and possibly The Authorities, have the power to listen to Skype calls.
SIP or IAX over SSL/TLS would be much more secure, since these are open protocols and the only secret is the encryption key.
And while we're at it, the source code would be nice.
Failing that, just use a commonly-available hardware SIP phone which will work with the Asterisk software PABX.
Way to miss the point!
If GPG had been a closed-source product, almost nobody would ever have known about the flaw. People would just have carried on using it [*], believing it safe, and the exploit would have stayed underground. It's precisely because it's Open Source that anybody discovered the problem at all. At least now, it can be fixed -- in fact, it already has been fixed.
[*] Well, actually, they wouldn't, because using closed-source crypto is up there in the top ten Bloody Stupid Ideas, along with using a scythe to cut your toenails. And I hope I do not have to explain why.
I'm not referring to actual physical objects. I'm referring to the abstract concepts which underlie those objects; for instance, not loaves of bread, but knowing how to bake a loaf of bread. Think like the pure mathematician, who considers their work done when they have reduced a problem to a set of equations that they know they can solve {rather than when those equations themselves are solved, which would be mechanical work}. By the very act of choosing who you do and do not wish to give the software to, you are committing violence against those to whom you choose not to give the software. You may have written the software, but it belongs to everyone. Those to whom you choose not to give it, are justified in using reasonable force to obtain it. Software which is written for the sole purpose of making money is software we can do without. We did not need it before it was written, and we will not need it afterward. We may see a drop in the quantity of software written, but that will be offset by an improvement in the quality of software being written -- since it will be written with the purest motives in mind, and there will be no onus on the supplier to cut corners.
Now, suppose there was some software tool that would accept a compiled program as its input; and output a file containing some source code that, when compiled, would be exactly equivalent to the original input. Such a program would be the functional opposite of a compiler -- in other words, a decompiler.
The decompiler output would not necessarily be identical to the original Source Code -- indeed, it need not even be in the same programming language. In particular, variable and function names might well be lost {there is little need for them to be retained in the object code, and historically there have been good reasons for them to be discarded}. However, this step already gives a hacker a great deal of leverage; it re-creates the abstraction that exists between choosing what high-level language statements to use to solve the problem {analogous to poetry}, and how to tell the computer what machine-language instructions to use to carry out those steps {analogous to calligraphy}. Now our hacker need no longer think in terms of "the floating-point number stored in locations $ce08-$ce0C" but in terms of "float1". One whose experience is in pure mathematics might recognise an expression of the form and deduce more meaningful names for the variables from the context in which they are used. Additional clues may well exist in the text of messages and prompts.
Mathematically, the problems of decompilation are identical to the problems of shape recognition: consider machine language instructions as vertices, and high-level language structures {such as statements, loops and functions} as more or less complex shapes. Now, which vertices are most likely to belong to what shapes? Which sequences of machine-language instructions correspond to what high-level instructions?
A decompiler would have value for other applications beside reverse-engineering closed source software, even if we discount the possibility that the author of a program might ever need to recover it after some catastrophe has befallen the original. Subject to the ability of compilers to preserve variable and function names {a standard debugging aid, which could easily be added to an Open Source compiler which lacked it} and decompilers to retrieve and make use of this information, it ought to be possible to decompile a program written in one language into a different language. This would allow an exciting new form of collaboration, since it would remove the need for programmers working together on a project to know the same programming language.
You are still missing the important distinction. Certain things -- such as a car -- will be diminished by the act of sharing, and so can be considered subject to ownership. Other things are not diminished by sharing. The canonical example being that if you light a candle from my already-lit candle and then take it away, my room does not get any darker than it was before. Such things are, once a prototype exists, infinitely plentiful and cannot be considered subject to ownership.
If I copy a piece of software from you, you still have the original. You lose exclusivity over that software -- but that would be a form of artificial scarcity, which is absolutely not welcome in the Age of Plenty.
Please cite the paragraph in GPL3 {2006-01-16 draft as shown here} which you believe would oblige you to provide the source code as you state.
It is my understanding that the source code for those parts of a web application which run only the server end, need not be made accessible to users accessing the application via the web. Of course, the source code for those parts of a web application which run on the client end -- assuming that it be written in an interpreted language such as JavaScript-- is already accessible to users.
In any case, your complaint about having to insert source download links if you set up a web application is rather like complaining that if you invite members of the public into your private property, you have to provide fire exit signs.
That is the fundamental difference. As the manifesto says, "Software can be shared without being diminished by the act of sharing".