Correlation, not causation..... you mean like how eating ice cream increases your probability of drowning, yes? {More ice cream is eaten on hot days, when people tend to gather near water. While you are thinking about how to make code look good, you are more likely to think at the same time about how to make it work well.}
While I agree with the idea that you can write insecure but pretty code, I would question that prettiness is the only criterion people use to judge the code they look at. If something is insecure, it will stand out when someone with the right mindset looks at it. And the greater the probability of it being looked at in the first place, so the greater the probability of it being looked at by a person with the right mindset.
And, of course, if you find a flaw in an open source project and the maintainer does not want to know, you can always fork it. If you find a flaw in a closed source project and the vendor doesn't want to know, they will use the force of the law to silence you.....
OSS is inherently more secure than proprietary software.
Proprietary software authors do not have to do things "properly", they just kludge things together that may or may not work in every possible weirdy case, and rely on nobody ever seeing what an awful job they made of it in the first place. Witness any open source project that used to be closed-source {Mozilla; OpenOffice.org; Solaris}. Open Source developers have to write code that they would not be ashamed to show to anybody, because they do not know who is going to be looking at it. To quote Larry Wall, "Hubris is the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer." They also have to write code in such a way that it won't be obvious from inspecting it how to misuse it.
Morbid curiosity is what makes people look at source code; and there are significantly more good guys than bad, so if anyone is looking at your source code, the chances are that their intentions are honourable.
What's wrong with single-clicking a program on a CD, and having it compile and install itself? That's entirely possible with GNU/Linux. And you have the benefit of knowing that it was cooked in your own oven; if it gives you the Dire Rear, you can analyse the traces of leftover ingredients to see what was responsible.
Most meds last a lot longer than the so-called "expiry dates" on them. {I remember seeing a study on the subject somewhere -- might even have been linked from Slashdot -- but you're old enough to know how to search for stuff for yourselves now.} I'm convinced that the expiry dates are only there so the manufacturers have a reason to keep making more of them. It's the same story with food: I have a fairly ordinary fridge, but I have known stuff keep at least two days and sometimes up to a fortnight beyond the date stamp. Maybe if you were really careless and stored open packets on a radiator or something, then maybe something might go "on the turn" on the date shown. However, I find the dates are conservative to pessimistic.
The most amusing "expiry date" story I have is a tub of talcum powder which carries a warning to use within 9 months of opening. For crying out loud, it's a crushed-up rock! It's been in the ground for millions of years, as if nine piddling months is going to make a difference?!
If civilisation as we know it really does break down, none of that information will be important to you anyway. If anybody comes to rescue you, their immediate concerns won't be with proving you are who you say you are. If nobody comes to rescue you, it won't matter. As for storing the data on a solid state flash memory device..... that's just plain dumb. Can you really be sure that it will work if and when the time comes? Can you even be sure there will be any equipment capable of reading it? On the other hand, if civilisation as we know it doesn't break down, that information -- amounting to a full impersonation kit -- could too easily be used against you.
Given the balance of probabilities, I'd say that storing details of your life on an unreliable solid-state memory device is asking for trouble. Just memorise your name, address and identity number, and remember it's three more pieces of information than many people will be able to remember in an emergency.
How the muddy mildred do they expect this thing to work in real life?
It's a memory card, for crying out loud. I give it a bunch of zeros and ones and tell it where to put them. At some later date, I ask it what is in that particular location and it spits out those same zeros and ones. That is what memory cards do. The key point is that, once I have retrieved those zeros and ones from the memory card, the card then has no way to know what I plan to do with them. And there will have to be general purpose slot-readers that work with these things and treat them as disc drives.
Now, unlike a traditional memory device such as an EPROM, where you present an address on one group of pins, assert an "output enable" and the data appears on another group of pins, these little beggars use some kind of serial protocol. You send it a command such as "Read 0x0100 bytes starting at address 0x1234" and it returns a response. Well, by cunning use of an oscilloscope on the transmit and receive lines, we can observe the data flowing in each direction. And by interposing some simple circuitry of our own design between the reading device and the card, we can modify bits at will.
It sounds to me as though this is some kind of destructive read-out {DRO} thing. Any variant on DRO is absolutely not viable as a copy prevention mechanism. I invented a variant of DRO protection for audio cassettes myself, over 25 years ago -- and I had already found a way to crack it, even before I got together all the bits to build a prototype. Ho hum.
Furthermore, any encryption scheme where the key is shorter than the plaintext is crackable -- and especially so where one has {even indirect} access to both the encryption and decryption engines and can generate known plaintexts to encrypt and known ciphertexts to attempt to decrypt. We know that the brute force approach is next to unworkable {and more so when you don't know the algorithm, let alone the key}, but this isn't a case for brute force: we have plenty of purchase already.
<tangent>I was watching CSI on ch.5 {does that side ever show anything not police-related?} with a friend last night. This show seems to be a propaganda exercise, in which the message is drummed into the viewing public that the police (1) are infallible and (2) have access to sophisticated techniques for extracting information which one would ordinarily expect to be forgotten {in this case, a reflection from someone's eye in a photograph; though I would not have been surprised to see them reconstruct the text of a burned letter from analysis of the smoke}.</tangent> I seriously suspect that this announcement is similarly a propaganda exercise, aimed at convincing the recording industry fatcats that they have achieved the physically impossible.
Prediction for the short-term future of file sharing: Copies will be made using analogue techniques if necessary, and distributed using on-the-fly public key encryption {client sends public key to server, server encrypts against this key, man in middle is frustrated by not having appropriate decryption key}. Used keys will be published for reasons of plausible deniability. Key only needs to last as long as required to transfer one chunk of data {smaller than amount permitted under fair use doctrine} before replacement.
Ah, but on a Sony-Ericsson phone, such as the k750i with built-in 2Mpx camera and radio receiver, not only can you use any of your own photographs as wallpaper; you can even record your own ringtones, using the phone's built-in mic. And then nothing is stopping you from infra-red beaming your homebrew multimedia across to any other phone. I don't think they're going to be making phones without mics any time soon..... though if they did, I'd definitely buy one for my mother!
As to the question of ownership vs licencing..... I don't think anybody is really sure whether or not you own a mobile phone {until it comes to time to get rid of them -- businesses aren't allowed to dispose of them in landfill, but individuals are}. But the phone companies might be within their rights to deem certain things as unfit for connection to their networks, if they thought there was a danger that you could be placing other subscribers' usage in jeopardy.
Anyway, phone companies will be shooting themselves in the foot if they try to clamp down on "unauthorised" ringtone / wallpaper installations. The choice is not "pay through the arsehole for it or get it for nothing". The choice is between "pay through the arsehole for it, get it for nothing or go without", and the third option is the one people will use if denied the second.
No, because most of life-saving medications we need already exist. Most of what the big pharmaceutical companies are doing is just re-inventing the wheel, using different colour hub caps. {And littering the way with animal corpses to boot}. What is required is for people to adopt genuinely -- as opposed to apparently -- healthier lifestyles. And a naturally healthier lifestyle is almost invariably cheaper than an unhealthy one. For instance, walking or cycling not only save you petrol, they give you natural exercise {as opposed to the sort you would pay to get from a gym, which is unnaturally repetitive and does you little good in the long term}. Growing your own vegetables in a garden or allotment means you get to choose exactly what you're eating, you know what chemicals were used on it {if any}; and you get more natural exercise weeding, digging and carrying them home. Home cooked food doesn't have artificial additives like store-bought, processed crap. Going barefoot protects you from the damage done by shoes. And so on, and so forth.
Unfortunately, there's no money in that for big business; and the interests of big business are increasingly squeezing out the interests of the small guy, to the point where we're heading for unchecked corporatism. Which, fortunately, won't last long when it happens; but neither will it be especially pretty, and recovery will be a painfully slow business {potentially requiring IR1 to be done again from scratch, depending on the level of damage done by a worldwide corporatist state}.
Allowing malformed or errnoenous data to be inserted into a table which has been expressly defined to disallow data in that size, shape or form is totally broken behavior. For a database to accept such data is neither graceful nor is it degredation.
Perhaps you were looking in the wrong places. It's degradation whenever a piece of software doesn't do what you expected it to do {i.e. store something you'd already said you didn't want it to store}. Under those circumstances there are two possible behaviours:
Die horribly with an exception
Alter the data to fit the pre-existing constraints
Either one is acceptable, as long as you make it quite clear in your documentation which one you chose and are absolutely consistent about it. {There is sometimes a third option, which is to modify the constraints to make the presented data valid. That option, however, often is simply not available and one of the other two must be chosen.}
I suppose you'd also argue that it's a bad idea for the Diesel and Petrol gas pump nozzles to be different sizes, because it should be possible to accidently pump diesel into your petrol-burning car. After all, isn't it better to get/something/ into the tank, even if it's the wrong fuel?
Well, in some countries, the diesel and petrol nozzles are the same size {but different denomination banknotes are different sizes and colours, go figure}. And the people in those countries don't have a problem with it. They look twice before they pull the trigger. {Although they probably hand over their money at the till without looking too closely at it, and would likely fall prey to any scam involving visually-similar-but-different-value banknotes}.
Similarly, being able to enforce data integrity at the most logical layer -- the database -- is also a wise and necessary component of any database system which expects to be taken seriously.
I disagree that the database is the most logical layer at which to enforce constraints. I think the most logical layer at which to enforce constraints is at the application layer. You threw generality of purpose to the four winds the moment you gave the database a schema and imposed constraints. Your application already has to handle out-of-range values somehow or other; by making a noise, displaying a message or shooting a steel spike up the careless user's backside. So you might as well check that the data is valid before you present it to the server; particularly given as you often already have to do some sanitisation anyway with data supplied by a user, just to make sure it isn't being used for some kind of code injection attack.
there are MySQL developers that thought that this was a reasonable thing to do
I have to admit, it seems to me like a totally reasonable thing to do.
So far, they haven't shown any indication that they even realise how fucked up that is
Maybe because it's not fucked up at all? Look up "graceful degradation" sometime.
If you have a web browser running on hardware that, for some reason or another, cannot display bold text, what should it do?
Ignore the <strong> and </strong> tags altogether, and display the text anyway, although not bold;
Crash horribly with an error?
You're accessing the database server from a scripting language. You know what the constraints are. If you're that bothered, you'll check before you try to insert the data. If you haven't bothered to check, you deserve what you get.
And I believe their licensing agreement prohibits the disclosure of benchmarking data.
EULAs are legally unenforcible in most jurisdictions, so the worst offence you could be accused of would be libel. And the fact that whatever you said is true is an absolute defence to libel. I say go ahead, publish and be damned!
Easy. Tax private healthcare twice: a tax on the insurance premia, and a tax on the treatment costs. Use this money to fund the NHS. Withdraw the licences of any practitioner who will not accept patients on the NHS. Give each country's NHS the authority to override intellectual property privileges {they aren't "rights" by any stretch of the imagination} in respect of any potentially life-saving device or drug.
What the public doesn't realise, and nobody in big pharma is keen to let on, is that most illnesses can be treated with about 50-100 common drugs, and most drug development is done simply to keep monopolies in existence {for example, NeoClarityn was only invented because the patent on Clarityn was about to expire}.
And my point is that people probably didn't need to pay for it, they may have already paid for it. A TV licence is exactly what it says: a licence to watch TV programmes. And not just when the TV companies say so: by your own admission, TV recorders with removable media {e.g. cassette and DVD} are legal to use, and home-recorded media is legal to lend out. All means to the same end are equally valid. So, if it would be perfectly legal for me to lend someone {whose TV licence is paid up} a DVD I paid for the licence to allow me to record off the air, why not just miss out the clunky bit, and just send a legally-made recording to its legal recipient over the internet?
What Peru is doing is giving preferential treatment to software which supports open standards. As a matter of definition, Open Source / Free Software / Logiciel Lisible Libre can only support open standards: the source code, which anyone is allowed to look at and anyone is allowed to use in their own software iff they play by the rules, is the specification.
The reason for this is to guarantee that
The people -- all the people, not a subset of the people who have bought a particular company's product -- will always have access to the data which concerns them.
The government -- whose wages the people pay -- will always have the option to change their supplier in the event that this would be beneficial.
Microsoft, or any other software company, are welcome to implement open standards in their software. But they probably aren't going to, because proprietary data formats are how they lock-in users to their products. If, say, Excel incorporated full read and write support for the Gnumeric data format {hint: if you've ever done tables in HTML, you'll pick it up} then it would be easy for the Peruvian government to switch from Excel to Gnumeric anytime Microsoft disappointed them.
And frankly, I find it supremely hypocritical for the likes of Microsoft to suggest in one breath that they are being excluded from the process {by a decision that Microsoft made and that Microsoft are free to renounce at anytime} while also complaining about rampant "piracy" in the third world. FCOL, it was Microsoft turning a blind eye to "piracy" of their products that ultimately crushed all their competition. Given the choice between MS Office Professional for £500; a reasonably-well-featured office suite by an independent publisher for £50, saving £450; a "pirated" copy of Office for £0, saving £500 {and probably retaining a familiar UI if they use MS Office at work}; or a "pirated" copy of the other suite for £0 saving £50, almost everyone is going to plump for the pirated MS Office. Microsoft stood by and let them get away with it; if they had prosecuted "pirates" more aggressively, then maybe more people would have decided to be honest, paid the £50 for the alternative office suite, and they still would have saved themselves £450. But then Microsoft might not have attained such a dominant position.
The mail client PINE is a good example of software where you can examine the source code, but you are restricted in the way you can distribute modified versions {as source code, or as binaries but outside the original version numbering scheme}. It was meant to preserve the integrity of the original code and divert questions regarding modified versions away from the original authors, but it has a nasty side effect of not quite qualifying as Free Software. Some Unix implementations had, for operational reasons, to be supplied with kernel sources which you were allowed to compile, but not distribute {"Warning! The mouse has been moved. You will need to recompile your kernel for this change to take effect" -- well, it wasn't quite that bad, but you had to compile a kernel to match your hardware exactly}. And I believe that the original PGP licence similarly allowed you to inspect and compile the source code, but not distribute it.
"Open Source" is really just a euphemism, which was coined to downplay the association between freedom and troublemaking and so make it more acceptable to suits. {What do people usually do when they feel someone is constraining their freedom? They protest, in various ways that generally make business types uncomfortable.} It also neatly sidesteps the whole homonym issue {which is not an issue at all in countries where different words are used to mean "at no cost" and "without constraints"}.
Shame that weather is the only thing that gets full coverage these days
That's because as of the present moment, the weather is the last bastion of there being no vested intellectual property rights. But sooner or later, you can bet your ass that somebody is going to try to claim IP rights in the weather. Consider the following:
Weather forecast data will be copyrighted and released under a strict end user licence agreement. The use of circumvention devices such as barometers, hygrometers, min-max thermometers &c. will be outlawed.
Somebody will try to patent the act of getting rained on, and you'll have to pay them a fee every time you get wet.
Someone else will patent the act of staying in when it rains, and you'll have to pay them a fee every time you don't get wet.
Broadcasters will be deemed legally responsible for the accuracy of their weather forecasts; a nationwide TV network will be bankrupted by a class action lawsuit when the promised "thirty-degree sunshine" turns out to be just 29-point-five-degree sunshine, and local radio stations ultimately will not dare give out anyting more than vague suggestions for fear of infringing copyright or making an unfulfillable claim.
So are you saying that if I record a TV programme, does that mean I'm only allowed to watch it once? Or that I'm not allowed to show the recording to anyone else?
The BBC already paid the actors' royalties out of my licence fee when they first broadcast the show, irrespective of whether or not I watched it. Therefore, as I see it, I might as well watch it just to get my full money's worth.
What exactly is wrong with sharing TV shows? After all, most people have explicit written authorisation to receive TV broadcasts.....
If your TV licence is paid up, and the recipient's TV licence is paid up, what's the problem? Of course, I can see it being a problem if you have no TV licence but watch downloaded programmes anyway. On the other hand, if I invited someone who didn't have a TV licence of their own into my home to watch my TV, my licence would cover them..... wouldn't it? So the uploader's TV reception licence ought to cover them for the initial reception and uploading. They would not need a broadcasting licence because they are not using the public parts of the RF spectrum, or if they are {e.g. wireless internet} then they already have a licence to do so {usually included in the initial purchase cost of the appliance}.
Basically what we have going on here is a game of cat and mouse. Creative programmers are trying to share material; an industry that makes its money selling overpriced and overrated shite is trying to stop people sharing it. Each side is just responding to what the other side is doing.
Think of the evolution of weapons and armour: at any point in the development cycle, there must have been either a piece of armour that no weapon can penetrate, or a weapon that no piece of armour can stop. You cannot have both. The existence of impenetrable armour inspires the creation of better weapons just as surely as the existence of unstoppable weapons inspires the creation of better armour.
And my money is on the file sharers to win in the long term. We're human; and ever since we invented language, we have had the urge to tell one another stories. File sharing is just the modern manifestation of the same instinct.
I thought LimeWire was Open Source?..... I know there is at least one Open Source client out there. So all it will take, will be for just one person to insert a few comment marks in the appropriate places. Then you have a LimeWire client that doesn't impose arbitrary checks.
What I think would be really good would be if someone could get a new law slipped in under the radar, whereby you could quite legally make your own CD, as long as you paid the appropriate fee to the copyright holder {in effect, Non-Discriminatory Licencing: if you give one person a licence to copy a work, you have to licence it to everyone on the same terms}. Even if this only applied to one region, there would still definitely be an obvious, legitimate application for P2P..... according to the principle of "innocent until proven guilty", nobody could be charged with infringement unless it could be proved that they had no intention to pay. And the idea might catch on elsewhere.
Yes, I've installed third party software. Some of it good, a lot of it bad -- and what it almost always boils down to is misuse of the autoconf and automake tools. {I used to have issues with pre-compiled stuff; but ever since I adopted a strict "Open Source or not at all" policy, no more. I don't really miss the likes of Acrobat Reader or Flash anyway.} Compiling from source is the preferred method; processors are fast enough now so downloading, and not compilation, is the rate-determining step. If you want to install on several machines {and they're all running the same distro}, the easiest way is to get as far as make; then you can just copy the whole directory {which now contains the code you just compiled} onto each target machine and make install there.
In theory, the configure script should check for all dependencies and bottle out with a sane error message if something vital is missing. In practice, autoconf scripts tend to be badly set-up, but with a good reason: whoever wrote the software must already have had all its dependencies, and it's simple human nature just to forget what you have got. {Don't believe me? How many electric motors are there, in total, in your home? Now go and count them all. Every single one. I'll be very surprised if you didn't discover at least one whole appliance you never even thought of the first time around.}
But almost nobody {except maybe some package maintainers} does a clean from-scratch install of their operating system just so they can test the dependencies of a new package they just created. They prefer to take a good guess, and hope that someone will spot anything they missed and put them straight. At the same time, it's the ones who know how to resolve dependencies by hand who probably are the least likely to bother doing so: they have got so used to doing it, that they don't think there's anything wrong with it; and anyway, surely somebody else would already have pointed out the problem if there really was a problem?
Of course, the times I've had an immediate success {in which I include being given a useful message which allowed me to fix the missing dependencies straight away} with a tarball might simply have been down to me just having the correct libraries installed already.
Autoconf itself probably needs to be further automated. Not that I'm suggesting for one second that it doesn't already do a supremely difficult job and do it bloody well; just that end users nowadays probably are fussier about what they will accept. And that really can only be a good thing in the long term, because it must mean that adoption is growing.
The only way you can ever be really sure that a piece of security software really is secure, is to read the source code.
Imagine some complete stranger comes up to you, and says he will deliver a secret message for you: if you dictate the message to him, he will write it down in a code so secret only he and his brother understand it, then send it to his brother, who will decode it and read it out to your correspondent.
Skype might be secure; it might just as probably be horrendously insecure. Without an independent audit of the source code, or a successful attempt to crack its security, we have no way to know.
{Does anyone else think it might be worth campaigning for our elected representatives to pass a law, requiring access to the source code of any software claimed as "cryptographic" or "secure" in nature?}
If the MD5sums for two files don't match, then you can still say the files definitely are not the same. So it's not entirely useless. You can still use it to check for non-deliberate file corruption {such as you might see if you have a faulty drive or motherboard}, since the example was so contrived as it could almost never happen by accident.
Also, I don't see how you could apply the scheme through the usual layers of archiving and compression. If I have a file "tldpsk.tar.gz" which contains "photoindex", "camprobe", "photograb", "install", "copying", "readme" and "manifest" -- all of which are human-readable text files, and the manifest, which is also reproduced on the download page, contains the original MD5sums of all the other files -- and I take its MD5sum, sure I might be able to produce another file with the same MD5sum as "tldpsk.tar.gz". But the new "tldpsk_altered.tar.gz" probably won't uncompress cleanly {first alarm bell} because the extra data you added probably won't be a valid file within the tar archive. And even if it is a valid file, then the manifest will be wrong {second alarm bell}. If you added extra data to one or more of the inner files -- let's say you put something nasty into "camprobe" and something else into "install" -- then the chances are that these files now won't be perfectly human-readable {third alarm bell}, even if their MD5sums match the ones in the manifest and on the download page.
PGP signatures can help, of course; but all a PGP signature really proves at the end of the day is that the file was signed by someone who knew the purported author's secret key. In an ideal world, of course, that means nobody but the author; but if the author of the package was unlucky enough to trust an MD5sum on a compromised file, that might not necessarily be the case.....
Once upon a time, my mother bought me two sweatshirts for Christmas. I put one of them on -- and when she saw me wearing it, she asked me what was wrong with the other one?
If you give a database server garbage data, it has two choices. Either it can degrade gracefully {try to store as much as possible of what you gave it, even though it won't all fit}; or it can degrade non-gracefully {die horribly with an error}.
Since most people talk to a database server from a scripting language {Perl, PHP, Python, Ruby, &c.}, and know in advance what the constraints are, they can make any necessary checks before passing the data to the database server, and then the mode of degradation is irrelevant.
No, I just used plain old regular expressions; and I only defined one my for the subroutine {I always use strict and -w}. So it's not surprising Slashdot barfed, really..... perl has a kind of implicit Zip compression built in, where the most-often-used functions have the briefest notation. Anyway, the gist of my CSV parsing, in more or less plain English with a little bit of PCRE for clarity, was as follows;
Initialise an array
Get the CSV line
Replace all \r and \n characters with null strings
As long as there is anything left on the line:
Strip off any leading whitespace
If the line starts with a speech mark (['"]), and has (a section that ends with something other than a backslash) followed by another matching speech mark \1 and a comma, add (what was between the speech marks) to the array and truncate the line to whatever, if anything, was after the comma.
Elsif the line starts with a comma, add an empty string to the array and truncate the line to whatever, if anything, was after the comma.
Elsif the line starts with anything other than a speech mark [^'"], and has (a section with no commas in it) followed by a comma, add everything before the comma to the array and truncate the line to whatever was after the comma.
Else
If the line starts with a speech mark (['"]), and has (a section that ends with something other than a backslash) followed by another matching speech mark \1, then set the line to be just the bit between the speech marks.
Add the entire remainder of the line to the array, and truncate the line to the empty string.
Return the array
This is actually the third iteration. Of course, just because I haven't found a case that will break this one, doesn't mean that there isn't one..... but it handles the usual special cases {commas between quotes, surely the biggest killer of homebrew CSV parsers; backslash-escaped quotes between quotes, probably the second-biggest killer; and empty values anywhere on the line} correctly.
Slashdot Mirror
Correlation, not causation ..... you mean like how eating ice cream increases your probability of drowning, yes? {More ice cream is eaten on hot days, when people tend to gather near water. While you are thinking about how to make code look good, you are more likely to think at the same time about how to make it work well.}
.....
While I agree with the idea that you can write insecure but pretty code, I would question that prettiness is the only criterion people use to judge the code they look at. If something is insecure, it will stand out when someone with the right mindset looks at it. And the greater the probability of it being looked at in the first place, so the greater the probability of it being looked at by a person with the right mindset.
And, of course, if you find a flaw in an open source project and the maintainer does not want to know, you can always fork it. If you find a flaw in a closed source project and the vendor doesn't want to know, they will use the force of the law to silence you
OSS is inherently more secure than proprietary software.
Proprietary software authors do not have to do things "properly", they just kludge things together that may or may not work in every possible weirdy case, and rely on nobody ever seeing what an awful job they made of it in the first place. Witness any open source project that used to be closed-source {Mozilla; OpenOffice.org; Solaris}. Open Source developers have to write code that they would not be ashamed to show to anybody, because they do not know who is going to be looking at it. To quote Larry Wall, "Hubris is the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer." They also have to write code in such a way that it won't be obvious from inspecting it how to misuse it.
Morbid curiosity is what makes people look at source code; and there are significantly more good guys than bad, so if anyone is looking at your source code, the chances are that their intentions are honourable.
What's wrong with single-clicking a program on a CD, and having it compile and install itself? That's entirely possible with GNU/Linux. And you have the benefit of knowing that it was cooked in your own oven; if it gives you the Dire Rear, you can analyse the traces of leftover ingredients to see what was responsible.
Most meds last a lot longer than the so-called "expiry dates" on them. {I remember seeing a study on the subject somewhere -- might even have been linked from Slashdot -- but you're old enough to know how to search for stuff for yourselves now.} I'm convinced that the expiry dates are only there so the manufacturers have a reason to keep making more of them. It's the same story with food: I have a fairly ordinary fridge, but I have known stuff keep at least two days and sometimes up to a fortnight beyond the date stamp. Maybe if you were really careless and stored open packets on a radiator or something, then maybe something might go "on the turn" on the date shown. However, I find the dates are conservative to pessimistic.
The most amusing "expiry date" story I have is a tub of talcum powder which carries a warning to use within 9 months of opening. For crying out loud, it's a crushed-up rock! It's been in the ground for millions of years, as if nine piddling months is going to make a difference?!
If civilisation as we know it really does break down, none of that information will be important to you anyway. If anybody comes to rescue you, their immediate concerns won't be with proving you are who you say you are. If nobody comes to rescue you, it won't matter. As for storing the data on a solid state flash memory device ..... that's just plain dumb. Can you really be sure that it will work if and when the time comes? Can you even be sure there will be any equipment capable of reading it? On the other hand, if civilisation as we know it doesn't break down, that information -- amounting to a full impersonation kit -- could too easily be used against you.
Given the balance of probabilities, I'd say that storing details of your life on an unreliable solid-state memory device is asking for trouble. Just memorise your name, address and identity number, and remember it's three more pieces of information than many people will be able to remember in an emergency.
How the muddy mildred do they expect this thing to work in real life?
It's a memory card, for crying out loud. I give it a bunch of zeros and ones and tell it where to put them. At some later date, I ask it what is in that particular location and it spits out those same zeros and ones. That is what memory cards do. The key point is that, once I have retrieved those zeros and ones from the memory card, the card then has no way to know what I plan to do with them. And there will have to be general purpose slot-readers that work with these things and treat them as disc drives.
Now, unlike a traditional memory device such as an EPROM, where you present an address on one group of pins, assert an "output enable" and the data appears on another group of pins, these little beggars use some kind of serial protocol. You send it a command such as "Read 0x0100 bytes starting at address 0x1234" and it returns a response. Well, by cunning use of an oscilloscope on the transmit and receive lines, we can observe the data flowing in each direction. And by interposing some simple circuitry of our own design between the reading device and the card, we can modify bits at will.
It sounds to me as though this is some kind of destructive read-out {DRO} thing. Any variant on DRO is absolutely not viable as a copy prevention mechanism. I invented a variant of DRO protection for audio cassettes myself, over 25 years ago -- and I had already found a way to crack it, even before I got together all the bits to build a prototype. Ho hum.
Furthermore, any encryption scheme where the key is shorter than the plaintext is crackable -- and especially so where one has {even indirect} access to both the encryption and decryption engines and can generate known plaintexts to encrypt and known ciphertexts to attempt to decrypt. We know that the brute force approach is next to unworkable {and more so when you don't know the algorithm, let alone the key}, but this isn't a case for brute force: we have plenty of purchase already.
<tangent>I was watching CSI on ch.5 {does that side ever show anything not police-related?} with a friend last night. This show seems to be a propaganda exercise, in which the message is drummed into the viewing public that the police (1) are infallible and (2) have access to sophisticated techniques for extracting information which one would ordinarily expect to be forgotten {in this case, a reflection from someone's eye in a photograph; though I would not have been surprised to see them reconstruct the text of a burned letter from analysis of the smoke}.</tangent> I seriously suspect that this announcement is similarly a propaganda exercise, aimed at convincing the recording industry fatcats that they have achieved the physically impossible.
Prediction for the short-term future of file sharing: Copies will be made using analogue techniques if necessary, and distributed using on-the-fly public key encryption {client sends public key to server, server encrypts against this key, man in middle is frustrated by not having appropriate decryption key}. Used keys will be published for reasons of plausible deniability. Key only needs to last as long as required to transfer one chunk of data {smaller than amount permitted under fair use doctrine} before replacement.
Ah, but on a Sony-Ericsson phone, such as the k750i with built-in 2Mpx camera and radio receiver, not only can you use any of your own photographs as wallpaper; you can even record your own ringtones, using the phone's built-in mic. And then nothing is stopping you from infra-red beaming your homebrew multimedia across to any other phone. I don't think they're going to be making phones without mics any time soon ..... though if they did, I'd definitely buy one for my mother!
..... I don't think anybody is really sure whether or not you own a mobile phone {until it comes to time to get rid of them -- businesses aren't allowed to dispose of them in landfill, but individuals are}. But the phone companies might be within their rights to deem certain things as unfit for connection to their networks, if they thought there was a danger that you could be placing other subscribers' usage in jeopardy.
As to the question of ownership vs licencing
Anyway, phone companies will be shooting themselves in the foot if they try to clamp down on "unauthorised" ringtone / wallpaper installations. The choice is not "pay through the arsehole for it or get it for nothing". The choice is between "pay through the arsehole for it, get it for nothing or go without", and the third option is the one people will use if denied the second.
No, because most of life-saving medications we need already exist. Most of what the big pharmaceutical companies are doing is just re-inventing the wheel, using different colour hub caps. {And littering the way with animal corpses to boot}. What is required is for people to adopt genuinely -- as opposed to apparently -- healthier lifestyles. And a naturally healthier lifestyle is almost invariably cheaper than an unhealthy one. For instance, walking or cycling not only save you petrol, they give you natural exercise {as opposed to the sort you would pay to get from a gym, which is unnaturally repetitive and does you little good in the long term}. Growing your own vegetables in a garden or allotment means you get to choose exactly what you're eating, you know what chemicals were used on it {if any}; and you get more natural exercise weeding, digging and carrying them home. Home cooked food doesn't have artificial additives like store-bought, processed crap. Going barefoot protects you from the damage done by shoes. And so on, and so forth.
Unfortunately, there's no money in that for big business; and the interests of big business are increasingly squeezing out the interests of the small guy, to the point where we're heading for unchecked corporatism. Which, fortunately, won't last long when it happens; but neither will it be especially pretty, and recovery will be a painfully slow business {potentially requiring IR1 to be done again from scratch, depending on the level of damage done by a worldwide corporatist state}.
- Die horribly with an exception
- Alter the data to fit the pre-existing constraints
Either one is acceptable, as long as you make it quite clear in your documentation which one you chose and are absolutely consistent about it. {There is sometimes a third option, which is to modify the constraints to make the presented data valid. That option, however, often is simply not available and one of the other two must be chosen.} Well, in some countries, the diesel and petrol nozzles are the same size {but different denomination banknotes are different sizes and colours, go figure}. And the people in those countries don't have a problem with it. They look twice before they pull the trigger. {Although they probably hand over their money at the till without looking too closely at it, and would likely fall prey to any scam involving visually-similar-but-different-value banknotes}. I disagree that the database is the most logical layer at which to enforce constraints. I think the most logical layer at which to enforce constraints is at the application layer. You threw generality of purpose to the four winds the moment you gave the database a schema and imposed constraints. Your application already has to handle out-of-range values somehow or other; by making a noise, displaying a message or shooting a steel spike up the careless user's backside. So you might as well check that the data is valid before you present it to the server; particularly given as you often already have to do some sanitisation anyway with data supplied by a user, just to make sure it isn't being used for some kind of code injection attack.If you have a web browser running on hardware that, for some reason or another, cannot display bold text, what should it do?
- Ignore the <strong> and </strong> tags altogether, and display the text anyway, although not bold;
- Crash horribly with an error?
You're accessing the database server from a scripting language. You know what the constraints are. If you're that bothered, you'll check before you try to insert the data. If you haven't bothered to check, you deserve what you get.Easy. Tax private healthcare twice: a tax on the insurance premia, and a tax on the treatment costs. Use this money to fund the NHS. Withdraw the licences of any practitioner who will not accept patients on the NHS. Give each country's NHS the authority to override intellectual property privileges {they aren't "rights" by any stretch of the imagination} in respect of any potentially life-saving device or drug.
What the public doesn't realise, and nobody in big pharma is keen to let on, is that most illnesses can be treated with about 50-100 common drugs, and most drug development is done simply to keep monopolies in existence {for example, NeoClarityn was only invented because the patent on Clarityn was about to expire}.
And my point is that people probably didn't need to pay for it, they may have already paid for it. A TV licence is exactly what it says: a licence to watch TV programmes. And not just when the TV companies say so: by your own admission, TV recorders with removable media {e.g. cassette and DVD} are legal to use, and home-recorded media is legal to lend out. All means to the same end are equally valid. So, if it would be perfectly legal for me to lend someone {whose TV licence is paid up} a DVD I paid for the licence to allow me to record off the air, why not just miss out the clunky bit, and just send a legally-made recording to its legal recipient over the internet?
The reason for this is to guarantee that
- The people -- all the people, not a subset of the people who have bought a particular company's product -- will always have access to the data which concerns them.
- The government -- whose wages the people pay -- will always have the option to change their supplier in the event that this would be beneficial.
Microsoft, or any other software company, are welcome to implement open standards in their software. But they probably aren't going to, because proprietary data formats are how they lock-in users to their products. If, say, Excel incorporated full read and write support for the Gnumeric data format {hint: if you've ever done tables in HTML, you'll pick it up} then it would be easy for the Peruvian government to switch from Excel to Gnumeric anytime Microsoft disappointed them.And frankly, I find it supremely hypocritical for the likes of Microsoft to suggest in one breath that they are being excluded from the process {by a decision that Microsoft made and that Microsoft are free to renounce at anytime} while also complaining about rampant "piracy" in the third world. FCOL, it was Microsoft turning a blind eye to "piracy" of their products that ultimately crushed all their competition. Given the choice between MS Office Professional for £500; a reasonably-well-featured office suite by an independent publisher for £50, saving £450; a "pirated" copy of Office for £0, saving £500 {and probably retaining a familiar UI if they use MS Office at work}; or a "pirated" copy of the other suite for £0 saving £50, almost everyone is going to plump for the pirated MS Office. Microsoft stood by and let them get away with it; if they had prosecuted "pirates" more aggressively, then maybe more people would have decided to be honest, paid the £50 for the alternative office suite, and they still would have saved themselves £450. But then Microsoft might not have attained such a dominant position.
The mail client PINE is a good example of software where you can examine the source code, but you are restricted in the way you can distribute modified versions {as source code, or as binaries but outside the original version numbering scheme}. It was meant to preserve the integrity of the original code and divert questions regarding modified versions away from the original authors, but it has a nasty side effect of not quite qualifying as Free Software. Some Unix implementations had, for operational reasons, to be supplied with kernel sources which you were allowed to compile, but not distribute {"Warning! The mouse has been moved. You will need to recompile your kernel for this change to take effect" -- well, it wasn't quite that bad, but you had to compile a kernel to match your hardware exactly}. And I believe that the original PGP licence similarly allowed you to inspect and compile the source code, but not distribute it.
"Open Source" is really just a euphemism, which was coined to downplay the association between freedom and troublemaking and so make it more acceptable to suits. {What do people usually do when they feel someone is constraining their freedom? They protest, in various ways that generally make business types uncomfortable.} It also neatly sidesteps the whole homonym issue {which is not an issue at all in countries where different words are used to mean "at no cost" and "without constraints"}.
So are you saying that if I record a TV programme, does that mean I'm only allowed to watch it once? Or that I'm not allowed to show the recording to anyone else?
The BBC already paid the actors' royalties out of my licence fee when they first broadcast the show, irrespective of whether or not I watched it. Therefore, as I see it, I might as well watch it just to get my full money's worth.
What exactly is wrong with sharing TV shows? After all, most people have explicit written authorisation to receive TV broadcasts .....
..... wouldn't it? So the uploader's TV reception licence ought to cover them for the initial reception and uploading. They would not need a broadcasting licence because they are not using the public parts of the RF spectrum, or if they are {e.g. wireless internet} then they already have a licence to do so {usually included in the initial purchase cost of the appliance}.
If your TV licence is paid up, and the recipient's TV licence is paid up, what's the problem? Of course, I can see it being a problem if you have no TV licence but watch downloaded programmes anyway. On the other hand, if I invited someone who didn't have a TV licence of their own into my home to watch my TV, my licence would cover them
Basically what we have going on here is a game of cat and mouse. Creative programmers are trying to share material; an industry that makes its money selling overpriced and overrated shite is trying to stop people sharing it. Each side is just responding to what the other side is doing.
Think of the evolution of weapons and armour: at any point in the development cycle, there must have been either a piece of armour that no weapon can penetrate, or a weapon that no piece of armour can stop. You cannot have both. The existence of impenetrable armour inspires the creation of better weapons just as surely as the existence of unstoppable weapons inspires the creation of better armour.
And my money is on the file sharers to win in the long term. We're human; and ever since we invented language, we have had the urge to tell one another stories. File sharing is just the modern manifestation of the same instinct.
I thought LimeWire was Open Source? ..... I know there is at least one Open Source client out there. So all it will take, will be for just one person to insert a few comment marks in the appropriate places. Then you have a LimeWire client that doesn't impose arbitrary checks.
..... according to the principle of "innocent until proven guilty", nobody could be charged with infringement unless it could be proved that they had no intention to pay. And the idea might catch on elsewhere.
What I think would be really good would be if someone could get a new law slipped in under the radar, whereby you could quite legally make your own CD, as long as you paid the appropriate fee to the copyright holder {in effect, Non-Discriminatory Licencing: if you give one person a licence to copy a work, you have to licence it to everyone on the same terms}. Even if this only applied to one region, there would still definitely be an obvious, legitimate application for P2P
Yes, I've installed third party software. Some of it good, a lot of it bad -- and what it almost always boils down to is misuse of the autoconf and automake tools. {I used to have issues with pre-compiled stuff; but ever since I adopted a strict "Open Source or not at all" policy, no more. I don't really miss the likes of Acrobat Reader or Flash anyway.} Compiling from source is the preferred method; processors are fast enough now so downloading, and not compilation, is the rate-determining step. If you want to install on several machines {and they're all running the same distro}, the easiest way is to get as far as make; then you can just copy the whole directory {which now contains the code you just compiled} onto each target machine and make install there.
In theory, the configure script should check for all dependencies and bottle out with a sane error message if something vital is missing. In practice, autoconf scripts tend to be badly set-up, but with a good reason: whoever wrote the software must already have had all its dependencies, and it's simple human nature just to forget what you have got. {Don't believe me? How many electric motors are there, in total, in your home? Now go and count them all. Every single one. I'll be very surprised if you didn't discover at least one whole appliance you never even thought of the first time around.}
But almost nobody {except maybe some package maintainers} does a clean from-scratch install of their operating system just so they can test the dependencies of a new package they just created. They prefer to take a good guess, and hope that someone will spot anything they missed and put them straight. At the same time, it's the ones who know how to resolve dependencies by hand who probably are the least likely to bother doing so: they have got so used to doing it, that they don't think there's anything wrong with it; and anyway, surely somebody else would already have pointed out the problem if there really was a problem?
Of course, the times I've had an immediate success {in which I include being given a useful message which allowed me to fix the missing dependencies straight away} with a tarball might simply have been down to me just having the correct libraries installed already.
Autoconf itself probably needs to be further automated. Not that I'm suggesting for one second that it doesn't already do a supremely difficult job and do it bloody well; just that end users nowadays probably are fussier about what they will accept. And that really can only be a good thing in the long term, because it must mean that adoption is growing.
The only way you can ever be really sure that a piece of security software really is secure, is to read the source code.
Imagine some complete stranger comes up to you, and says he will deliver a secret message for you: if you dictate the message to him, he will write it down in a code so secret only he and his brother understand it, then send it to his brother, who will decode it and read it out to your correspondent.
Skype might be secure; it might just as probably be horrendously insecure. Without an independent audit of the source code, or a successful attempt to crack its security, we have no way to know.
{Does anyone else think it might be worth campaigning for our elected representatives to pass a law, requiring access to the source code of any software claimed as "cryptographic" or "secure" in nature?}
If the MD5sums for two files don't match, then you can still say the files definitely are not the same. So it's not entirely useless. You can still use it to check for non-deliberate file corruption {such as you might see if you have a faulty drive or motherboard}, since the example was so contrived as it could almost never happen by accident.
.....
Also, I don't see how you could apply the scheme through the usual layers of archiving and compression. If I have a file "tldpsk.tar.gz" which contains "photoindex", "camprobe", "photograb", "install", "copying", "readme" and "manifest" -- all of which are human-readable text files, and the manifest, which is also reproduced on the download page, contains the original MD5sums of all the other files -- and I take its MD5sum, sure I might be able to produce another file with the same MD5sum as "tldpsk.tar.gz". But the new "tldpsk_altered.tar.gz" probably won't uncompress cleanly {first alarm bell} because the extra data you added probably won't be a valid file within the tar archive. And even if it is a valid file, then the manifest will be wrong {second alarm bell}. If you added extra data to one or more of the inner files -- let's say you put something nasty into "camprobe" and something else into "install" -- then the chances are that these files now won't be perfectly human-readable {third alarm bell}, even if their MD5sums match the ones in the manifest and on the download page.
PGP signatures can help, of course; but all a PGP signature really proves at the end of the day is that the file was signed by someone who knew the purported author's secret key. In an ideal world, of course, that means nobody but the author; but if the author of the package was unlucky enough to trust an MD5sum on a compromised file, that might not necessarily be the case
Once upon a time, my mother bought me two sweatshirts for Christmas. I put one of them on -- and when she saw me wearing it, she asked me what was wrong with the other one?
If you give a database server garbage data, it has two choices. Either it can degrade gracefully {try to store as much as possible of what you gave it, even though it won't all fit}; or it can degrade non-gracefully {die horribly with an error}.
Since most people talk to a database server from a scripting language {Perl, PHP, Python, Ruby, &c.}, and know in advance what the constraints are, they can make any necessary checks before passing the data to the database server, and then the mode of degradation is irrelevant.
- Initialise an array
- Get the CSV line
- Replace all \r and \n characters with null strings
- As long as there is anything left on the line:
- Strip off any leading whitespace
- If the line starts with a speech mark (['"]), and has (a section that ends with something other than a backslash) followed by another matching speech mark \1 and a comma, add (what was between the speech marks) to the array and truncate the line to whatever, if anything, was after the comma.
- Elsif the line starts with a comma, add an empty string to the array and truncate the line to whatever, if anything, was after the comma.
- Elsif the line starts with anything other than a speech mark [^'"], and has (a section with no commas in it) followed by a comma, add everything before the comma to the array and truncate the line to whatever was after the comma.
- Else
- If the line starts with a speech mark (['"]), and has (a section that ends with something other than a backslash) followed by another matching speech mark \1, then set the line to be just the bit between the speech marks.
- Add the entire remainder of the line to the array, and truncate the line to the empty string.
- Return the array
This is actually the third iteration. Of course, just because I haven't found a case that will break this one, doesn't mean that there isn't one