The Firebird embedded DLL sounds really interesting. I looked at sqlite but was put off by its almost total lack of data validation (for example, you can't even declare a column to hold integers). Which is claimed as a feature, not a bug, but for me it defeats one of the main reasons for using an RDBMS (foreign key constraints and check constraints are also not supported). Embedded Firebird might be a saner if slightly more heavyweight alternative. I wonder if there is a similar thing for Postgres?
What more did you expect out of a db engine running on this class of processors?
Oracle, DB2, Postgres, Sybase and so on used to run quite happily on machines with far less processing power. The SQL92 standard dates from 1992; I'd be surprised if today's handheld is not at least comparable in processor speed and RAM size to a 1992-vintage Unix box.
Yes, Word 6 is the best version of MS Word IMHO. Even the old Windows 3.1 appearance has a certain retro charm nowadays, while older Win95 applications just look tacky. (Compare styling changes in cars to make last year's model seem undesirable.) The 32-bit version of Word 6 is best. I have that running on NT 3.51 and it never goes wrong. A shame that neither product is still sold by Microsoft.
Why do you think that relational database vendors are not offering a true RDBMS in the sense of Codd's works? You mentioned null values before, but I explained that this is definitely part of the relational model and not a deviation from it. What else doyou think is missing?
Null may be abused, however it is much the less bad option compared to most other ways of modelling unknown or not applicable values. Sometimes you have a genuine need to model data where some things are really not known. This is not the same as a kludge because you don't know what value to put. When designing your relational database you make a conscious decision that it makes sense to have rows where 'height' is not known.
Of course the correct eye colour for someone without eyes is 'none', or 'not applicable' as it is sometimes called. But you may decide as part of your data model to represent 'none' using null. This might not be ideal but it is certainly no worse than representing it using a magic string. Of course, you are now confusing unknown eye colour with not-applicable eye colour, and this was one of Codd's criticisms of SQL, that it has only a single null value but needs two. However, I don't think this single failing is enough to disqualify a system as a relational database. And if you are using a particular RDBMS that supports a single null value it usually makes more sense to go with what the database supports natively rather than try to reinvent it with special 'none' strings. Even if you wish that the native support could be a bit different, you'd be silly not to use what is there. As I mentioned earlier, aggregate functions such as avg(height) are aware of null but not aware of any special value you might choose.
If you don't condone using such a value in production, but only as a kludge during development, then fair enough. If you've never needed to model unknown values or not applicable ones, you've been lucky. (By good design and normalization it's possible to reduce the number of not-applicable values you have to store, but they can't always be avoided entirely.)
You're right that Oracle comes with a lot of non-relational crud like 'XML databases'. However, don't let that distract you from the fact that Oracle, the core product, is a pretty good implementation of a relational database system. The same goes for most other RDBMSes. I believe you can choose simply not to install the XML / object-relational stuff.
I'd say Access probably is a relational database because it stores all data in relations and you use a query language based on relational algebra (even though it may have a GUI front end) to retrieve and update the data. It might not meet all 12 of Codd's rules, but in my opinion it's close enough. You might sound a bit unreasonable if you insist that a database storing relational data is not a relational database.
Semantically, I don't see the difference between using 'unknown' as a placeholder and using an explicit null value. Except that using the placeholder is more awkward and it isn't clear how to store 'unknown' in a field that contains integers, for example. Further, databases have support for using null values, for example in outer joins and in aggregate functions. Perhaps you could modify an RDBMS to recognize the string 'unknown' so it could be used cleanly in these cases, but what would be the point?
If you object to the very idea of storing 'a value which is not known' then I don't see why this is any better when represented as the magic string 'unknown' or the magic value null. I pointed out in my post above that nulls have been part of the relational model since the beginning.
E.F. Codd: In a relational database all data should be represented explicitly and in only one way, as values in tables.
You've just quoted the first of Codd's rules to define a relational database system. But it seems you're not aware of the others, in particular rule 3: there should be separate handling of null values, where the null value in a column is different from any of the normal values for that column's datatype.
In fact, Codd argued for two different kinds of null: one to mean 'unknown', as when entering a person into the database without knowing their date of birth, and one to mean 'not applicable', as when storing the engine size of a bicycle. One of the reasons he disliked SQL was because it combined these two into a single null value. SQL deviates from the relational model not because it supports some null values, but because it doesn't support enough of them.
BTW, please take Fabian Pascal's writings with a pinch of salt, at least until you have checked against other writings on relational theory and database management.
I think it's unfair to count only the perl core; count the core and CPAN. Yes, even though most CPAN modules are not included with the perl core I think this is a fairer comparison. After all the point of programming in a higher-level language like Perl is that you don't have to make patches to the core in order to develop new features; you can write them as Perl libraries.
But we know that people _do_ contribute patches and improvements to the code. Many developers have first-hand experience of this (from both sides, contributing and receiving). So it's hardly a myth.
Unless the author of the article has done some measurements to see what proportion of users send back improvements - and there's nothing in the article to say that he has measured anything or that he maintains any free software himself - then there's no reason to believe him rather than the 'myth'.
Can you give some examples of where SQL deviates from the relational model (I know there are a few, but I'd be interested to know which ones you consider important in practice), and suggest what features a replacement query language would have?
(Not just 'it follows the Relational Model' but particular examples, because otherwise it isn't clear what you mean, even to those who have studied a little relational theory.)
The poster didn't state what country he is in, although it is probably one where Tivo is marketed. Doesn't the hardware to get depend strongly on how you receive TV listings? For analogue listings, both demodulation (VHF / UHF) and decoding the picture (NTSC / PAL / SECAM) will require different hardware, though I hope it would be comparable in price.
Or what if digital television is available where you live? Do you want to record the digital signals directly to disk? This is the classiest way to do it but it might just make the hardware _cheaper_, since no real-time video encoding is needed (only decoding).
'investment in SCO is passive, made to hedge an economic exposure resulting from client transactions.'
So RBC does business with Red Hat, and needs to hedge against them going bust when SCO wins? Or they are hedging short positions they already had in SCO because of selling call options or the like to clients?
It would make some sense if they said 'we have lots of Linux boxes, and we want to get cash if SCO wins to cover the licence fees'...
Time for checking the suspicious 'GEEKLOG_DIR' variable in the User.php file:
require_once($GEEKLOG_DIR . '/lib-common.php');
So there it is. The php script doesn't properly set the variable and it can be set from the HTTP GET.
Who the fuck designed a programming language where variables can be set (without explicitly asking for it) from the HTTP request? (Duh... this web thing doesn't need any security measures, right?)
In addition, the 'require_once' sentence includes and evaluates the specified file during the execution of the script.
Which is also rather stupid in that require_once() will happily take a URL instead of a filename. Downloading code from some website without any signature checking or other security measures is bad enough when a human does it (though most of us do); terrible for a program to do automatically.
Still, PHP is a popular web scripting language just as Internet Explorer is a popular web browser, so maybe security misfeatures don't matter as much as we'd like to think.
But maybe what Debian should really be doing is copying from Knoppix. That has the easiest installation, i.e., no installation at all, and it's Debian-based. The conventional 'install it first and then run it' routine isn't nearly as easy or as much fun as 'run from CD and optionally install to your fixed disk later'. I'm surprised distros aren't making bigger moves towards a Knoppix-like installer, now it has been demonstrated that it can be done.
(Now Knoppix itself is i386-specific I think, but that's mostly hardware detection. On other architectures detection might be a bit less complex, I don't know.)
My point is that since everyone has a phone anyway, the cost of such a system is very small (per customer). So if it reduces fraud it would be profitable for the banks. Sure, people would prefer to just type in a PIN, but they'd also prefer to have a real branch where a real person can hand out cash. The banks have switched people towards ATMs because it saves money for them.
The normal problem of ignoring security and doing whatever is most convenient doesn't apply so much when people feel their own money is directly involved. You may find it difficult to explain why running the dancing elephants screensaver is a bad idea, but if people have it explained to them that keying in a PIN means more potential for their money to be stolen (even if this is a simplification of the real issues) they may be happy to switch to a more secure method.
0.1s or whatever is fine for web browsing, not so great for remote filesystems (eg grepping a directory full of small files - you'd rather not have a 0.1s delay between each one).
The problem is that the information you give to authorize one transaction - your card number and PIN - is the same as needed to authorize _any_ transaction.
You could have a different PIN for small amounts and large amounts, being limited to one 'small' withdrawal per day, and that would slightly reduce the potential for fraud. But people would tend to forget the numbers. You could have a booklet printed with a list of one-use-only identification numbers; then someone would have to steal the booklet rather than just copy one number you typed in.
But with mobile phones being so common, can't we use those for security? You type into your phone the amount to withdraw and a PIN (which is held only in the phone itself), and it generates an authorization code signed with your private key (again held only in the phone). You type this code into the ATM, it checks the code using your public key and takes it as an authorization to withdraw *one* particular amount at *one* date and time. Rekeying the same authorization code later will not work since it includes the date and time (with say a five minute window between generating the number on your phone and it expiring), and as an additional safeguard the bank records previously-seen codes and won't accept them again.
Then even if you use a completely bogus ATM that records everything you type in, the worst that could happen is for someone to rush over to a real ATM and type in the same code to get the money - and it would be obvious something was wrong if the fake ATM didn't dispense exactly the same amount.
That's exactly what I'm saying. You can send huge amounts of data in a given time, but the round-trip time for requesting and getting a particular piece of data has a lower bound set by the speed of light.
Slashdot Mirror
The Firebird embedded DLL sounds really interesting. I looked at sqlite but was put off by its almost total lack of data validation (for example, you can't even declare a column to hold integers). Which is claimed as a feature, not a bug, but for me it defeats one of the main reasons for using an RDBMS (foreign key constraints and check constraints are also not supported). Embedded Firebird might be a saner if slightly more heavyweight alternative. I wonder if there is a similar thing for Postgres?
Yes, Word 6 is the best version of MS Word IMHO. Even the old Windows 3.1 appearance has a certain retro charm nowadays, while older Win95 applications just look tacky. (Compare styling changes in cars to make last year's model seem undesirable.) The 32-bit version of Word 6 is best. I have that running on NT 3.51 and it never goes wrong. A shame that neither product is still sold by Microsoft.
Am I the only one who thought of Avril Lavigne when reading that?
Writing them as web pages works fairly well.
Why do you think that relational database vendors are not offering a true RDBMS in the sense of Codd's works? You mentioned null values before, but I explained that this is definitely part of the relational model and not a deviation from it. What else doyou think is missing?
Null may be abused, however it is much the less bad option compared to most other ways of modelling unknown or not applicable values. Sometimes you have a genuine need to model data where some things are really not known. This is not the same as a kludge because you don't know what value to put. When designing your relational database you make a conscious decision that it makes sense to have rows where 'height' is not known.
Of course the correct eye colour for someone without eyes is 'none', or 'not applicable' as it is sometimes called. But you may decide as part of your data model to represent 'none' using null. This might not be ideal but it is certainly no worse than representing it using a magic string.
Of course, you are now confusing unknown eye colour with not-applicable eye colour, and this was one of Codd's criticisms of SQL, that it has only a single null value but needs two. However, I don't think this single failing is enough to disqualify a system as a relational database. And if you are using a particular RDBMS that supports a single null value it usually makes more sense to go with what the database supports natively rather than try to reinvent it with special 'none' strings. Even if you wish that the native support could be a bit different, you'd be silly not to use what is there. As I mentioned earlier, aggregate functions such as avg(height) are aware of null but not aware of any special value you might choose.
If you don't condone using such a value in production, but only as a kludge during development, then fair enough. If you've never needed to model unknown values or not applicable ones, you've been lucky. (By good design and normalization it's possible to reduce the number of not-applicable values you have to store, but they can't always be avoided entirely.)
You're right that Oracle comes with a lot of non-relational crud like 'XML databases'. However, don't let that distract you from the fact that Oracle, the core product, is a pretty good implementation of a relational database system. The same goes for most other RDBMSes. I believe you can choose simply not to install the XML / object-relational stuff.
I'd say Access probably is a relational database because it stores all data in relations and you use a query language based on relational algebra (even though it may have a GUI front end) to retrieve and update the data. It might not meet all 12 of Codd's rules, but in my opinion it's close enough. You might sound a bit unreasonable if you insist that a database storing relational data is not a relational database.
Just a note - I do speak from current experience when saying that a magic 'unknown' string or similar is painful to deal with and a source of bugs.
Semantically, I don't see the difference between using 'unknown' as a placeholder and using an explicit null value. Except that using the placeholder is more awkward and it isn't clear how to store 'unknown' in a field that contains integers, for example. Further, databases have support for using null values, for example in outer joins and in aggregate functions. Perhaps you could modify an RDBMS to recognize the string 'unknown' so it could be used cleanly in these cases, but what would be the point?
If you object to the very idea of storing 'a value which is not known' then I don't see why this is any better when represented as the magic string 'unknown' or the magic value null. I pointed out in my post above that nulls have been part of the relational model since the beginning.
You've just quoted the first of Codd's rules to define a relational database system. But it seems you're not aware of the others, in particular rule 3: there should be separate handling of null values, where the null value in a column is different from any of the normal values for that column's datatype.
In fact, Codd argued for two different kinds of null: one to mean 'unknown', as when entering a person into the database without knowing their date of birth, and one to mean 'not applicable', as when storing the engine size of a bicycle. One of the reasons he disliked SQL was because it combined these two into a single null value. SQL deviates from the relational model not because it supports some null values, but because it doesn't support enough of them.
BTW, please take Fabian Pascal's writings with a pinch of salt, at least until you have checked against other writings on relational theory and database management.
I think it's unfair to count only the perl core; count the core and CPAN. Yes, even though most CPAN modules are not included with the perl core I think this is a fairer comparison. After all the point of programming in a higher-level language like Perl is that you don't have to make patches to the core in order to develop new features; you can write them as Perl libraries.
But we know that people _do_ contribute patches and improvements to the code. Many developers have first-hand experience of this (from both sides, contributing and receiving). So it's hardly a myth.
Unless the author of the article has done some measurements to see what proportion of users send back improvements - and there's nothing in the article to say that he has measured anything or that he maintains any free software himself - then there's no reason to believe him rather than the 'myth'.
Can you give some examples of where SQL deviates from the relational model (I know there are a few, but I'd be interested to know which ones you consider important in practice), and suggest what features a replacement query language would have?
(Not just 'it follows the Relational Model' but particular examples, because otherwise it isn't clear what you mean, even to those who have studied a little relational theory.)
What has OpenOffice startup speed got to do with KDE?
It could have been worse - he could have landed in the Norwegian zone of Antartica and been prosecuted again for writing DeCSS.
You clearly never heard of Pigs In Space.
The poster didn't state what country he is in, although it is probably one where Tivo is marketed. Doesn't the hardware to get depend strongly on how you receive TV listings? For analogue listings, both demodulation (VHF / UHF) and decoding the picture (NTSC / PAL / SECAM) will require different hardware, though I hope it would be comparable in price.
Or what if digital television is available where you live? Do you want to record the digital signals directly to disk? This is the classiest way to do it but it might just make the hardware _cheaper_, since no real-time video encoding is needed (only decoding).
So RBC does business with Red Hat, and needs to hedge against them going bust when SCO wins? Or they are hedging short positions they already had in SCO because of selling call options or the like to clients?
It would make some sense if they said 'we have lots of Linux boxes, and we want to get cash if SCO wins to cover the licence fees'...
But what free choices are there if you already own a Tivo box? Do any of the free PVR applications run well on the Tivo hardware?
Which is also rather stupid in that require_once() will happily take a URL instead of a filename. Downloading code from some website without any signature checking or other security measures is bad enough when a human does it (though most of us do); terrible for a program to do automatically.
Still, PHP is a popular web scripting language just as Internet Explorer is a popular web browser, so maybe security misfeatures don't matter as much as we'd like to think.
But maybe what Debian should really be doing is copying from Knoppix. That has the easiest installation, i.e., no installation at all, and it's Debian-based. The conventional 'install it first and then run it' routine isn't nearly as easy or as much fun as 'run from CD and optionally install to your fixed disk later'. I'm surprised distros aren't making bigger moves towards a Knoppix-like installer, now it has been demonstrated that it can be done.
(Now Knoppix itself is i386-specific I think, but that's mostly hardware detection. On other architectures detection might be a bit less complex, I don't know.)
My point is that since everyone has a phone anyway, the cost of such a system is very small (per customer). So if it reduces fraud it would be profitable for the banks. Sure, people would prefer to just type in a PIN, but they'd also prefer to have a real branch where a real person can hand out cash. The banks have switched people towards ATMs because it saves money for them.
The normal problem of ignoring security and doing whatever is most convenient doesn't apply so much when people feel their own money is directly involved. You may find it difficult to explain why running the dancing elephants screensaver is a bad idea, but if people have it explained to them that keying in a PIN means more potential for their money to be stolen (even if this is a simplification of the real issues) they may be happy to switch to a more secure method.
0.1s or whatever is fine for web browsing, not so great for remote filesystems (eg grepping a directory full of small files - you'd rather not have a 0.1s delay between each one).
The problem is that the information you give to authorize one transaction - your card number and PIN - is the same as needed to authorize _any_ transaction.
You could have a different PIN for small amounts and large amounts, being limited to one 'small' withdrawal per day, and that would slightly reduce the potential for fraud. But people would tend to forget the numbers. You could have a booklet printed with a list of one-use-only identification numbers; then someone would have to steal the booklet rather than just copy one number you typed in.
But with mobile phones being so common, can't we use those for security? You type into your phone the amount to withdraw and a PIN (which is held only in the phone itself), and it generates an authorization code signed with your private key (again held only in the phone). You type this code into the ATM, it checks the code using your public key and takes it as an authorization to withdraw *one* particular amount at *one* date and time. Rekeying the same authorization code later will not work since it includes the date and time (with say a five minute window between generating the number on your phone and it expiring), and as an additional safeguard the bank records previously-seen codes and won't accept them again.
Then even if you use a completely bogus ATM that records everything you type in, the worst that could happen is for someone to rush over to a real ATM and type in the same code to get the money - and it would be obvious something was wrong if the fake ATM didn't dispense exactly the same amount.
That's exactly what I'm saying. You can send huge amounts of data in a given time, but the round-trip time for requesting and getting a particular piece of data has a lower bound set by the speed of light.