However, I rarely see apps where truncating numbers to fit is considered a good thing. COBOL does that and it has been the source of many bad bugs, such as wrong paychecks.
Wrong paychecks as opposed to no paychecks for anybody. Those are really the choices that you have with any constraints on the storage and manipulation of values. You get to choose where you make the errors. You do not get to choose to not make any errors.
For any storage mechanism, there exists at least one x for which x+1=x or x+1 is very wrong or the systems halts or creates an exception. Creating an exception is not a solution, unless you consider nobody gets a paycheck a solution.
A good design principle is: either do what you're told to do or tell us you didn't do it and why, but don't do something completely different.
As applied to taking a two hour final. If you can't finish it accurately, then don't turn in your test paper. A zero score is preferable to something not quite perfect.
And a man with three clocks has a pretty good idea which one is wrong.
As for data integrity, having NONE of the intended data is not exactly my idea of integrity.
and I honestly do not understand what is so damned scary about MySQL. Send query, get answer. Life good. Carry on.
I've had this rattling around in my head last couple days. Maybe this sheds some light on the matter.
You have some hundred thousand records of raw data and an hour in which to process it. MySQL: "Send query, get answer. Life good. Carry on." Pedants: will still be working on it a week later. Now, if you have "enterprise" class requirements, which do you use if you are responsible for the complete results.
MySQL is atomic at the statement or query level. This is a different granularity than something which is atomic at the transaction level. I suspect that the paradigm of the transactions, triggers, cascading deletes, etc. is that one expects to start a transaction, delete something at a high level, have the delete cascade until it runs into something which must be deleted and must not be deleted and causes a roll-back of the transaction. Dunno about you but to me that looks like an accident looking for a place to happen.
MySQL is extremely predictable and conservative in use of resources and if you're brave and daring enough, can be pushed beyond reason. I haven't done it but I'm sure than someone has managed to process at the "same time" raw data which amounts to about 250% of total disk space. Run it out of disk space and MySQL patiently waits for space to be freed without any other sign of a problem. There are surprises, but there are good and sound reasons for those surprises.
Referential Integrity: from http://databases.about.com/cs/administration/g/ref integrity.htm
Consider the situation where we have two tables: Employees and Managers. The Employees table has a foreign key attribute entitled ManagedBy which points to the record for that employee's manager in the Managers table. Referential integrity enforces the following three rules:
1. We may not add a record to the Employees table unless the ManagedBy attribute points to a valid record in the Managers table.
2. If the primary key for a record in the Managers table changes, all corresponding records in the Employees table must be modified using a cascading update.
3. If a record in the Managers table is deleted, all corresponding records in the Employees table must be deleted using a cascading delete.
Rule 1 states that the President cannot be an employee, unless he's managed by, say, the janitor.
Rule 2 means that when your manager moves to a different position, you got moved.
Rule 3 means that when your manager is fired, you never existed.
Irreversibly executing a request that didn't even make sense is stunningly reckless.
There is a difference between your inability to make sense of something and the thing itself not making sense.
INSERT INTO foo SELECT * FROM bar LEFT JOIN baz ON whatever. You are saying which? That defining columns in foo as NON NULL is stunningly reckless? That inserting rows from a join is stunningly reckless?
make the developer decide what should happen. Which developer. Seems the developers of MySQL did in fact decide what should happen.
By selling it off they are opening themselves up to being at the mercy of whoever is building hardware and those people are told every two years by Microsoft what a standard PC will look like.
Razor thin margins and being told by Microsoft what your product will look like does not sound like a good business to be in.
Are you saying the problems they list don't exist? Oh, I'm sure problems exist. They are in the nature of What is the value of something that does not exist? Different choices can be made and it is unreasonable to expect the choices that MySQL has made will exactly match the choices that you would make. What is the "value" of 0/0? A value does exist, it's just not numeric. Calling it undefined does not prevent it from happening.
What is completely missing is any indication of practical use of the distinctions he is making that would side with him on how those distinctions should be made. Having a formal system that is paradox-free is not particularly easy. It is possible to work productively in a system with paradoxes. You just don't push too hard on things like NULLs and thingees that have a mind of their own like TIMESTAMPs and AUTO_INCREMENT.
Insert NULL into a non-null column. 1. The end of the world. Kill the computer. 2. Kill (segfault) the program. 3. Kill the INSERT statement with error message. 4. Perform the non-error parts (rows) of the INSERT statement. 5. Assign the default non-null value to the column without comment. If you want to preserve the NULL/NOT NULL distinction, you define the columns NULL. Personally I take the extra trouble to define columns NOT NULL precisely to obtain this "erroneous" behavior.
TIMESTAMP very useful if non-standard.
AUTO_INCREMENT primarily a mechanism to allow rows to co-exist which would otherwise collide. Giving explicit values to an AUTO_INCREMENT column is a good way to shoot yourself in the foot.
ENUM of numbers ??? Bad as FORTRAN FOUR = 3 If there is a vital distinction between 1 as an integer and 1 as a string, the design is just asking for trouble.
VARCHAR strips trailing blanks. Design decision. Different world than fixed rigid columns, as in COBOL or dBASE.
The WHERE clause of a SELECT statement. If you control all the SQL statements, pretty easy. if the suppliers control (actually any of any of) the SQL statements, difficult.
"the supplier's database account" means that each supplier has his own database?
they were in competition with each other, and we had no doubt that they would do whatever necessary to win the business You have some very legitimate concerns about SQL injection, like somebody deleteing or messing with competitors' quotes.
Possible, if the security is already pretty damned good. Cheap shot to maybe ferret out a few unk-unks (unknown unknowns) that you are in a position to jump on once you know what they are.
My old man use to program back in the mid 70's and early 80's.
Yep, he's a youngster;)
I support a non drm pallidium like architecture which demands an encryption key for each set of data that needs to be executed. It sounds insane but its the only way to stop unathorized code from executing. Cpu level bound checking would also be nice.
That's like a lock that's so good you lock yourself out. Permanently. Actually the Burroughs computers a bit before your old man's time, did precisely that, the bounds checking. Problem is, a number of programs that were aparently running ok would fail because they were actually doing something illegal.
but it will never be 100% secure. Right. The question is how much effort is worthwhile and how good a security do you really need anyway? Elaborate security setups and junking old computers with hard drives intact
really the resulting assembly level code from the compiler which really leaves the door open for hackers. This is the level at which code is exploited. The exploits do not use the source, they use the machine language. You need source to fix the exploit, not to exploit the code. In particular, any differences between what the machine code does and what the source code plus comments implies is probably capable of aloowing something undesirable.
The whole reason to migrate to NT back in the 90's was to avoid the security problems of Unix oddly enough. Unix security is poor, but extremely effective considering the effort.
Anyway my old man was shocked when I told him that is the problem today with worms infecting computers. Remember Melissa? Melissa was nice. Everything since has been pretty much predictable. The assumption or attitude that computers are nice and trustworthy paints a large target that can and does draw fire. It's a bad idea to claim that you are more secure than you are.
Reasons to overwrite the user's file: Probably a bit faster. Doesn't run out of space if the new file will fit.
Those are minor compared to losing the file completely because of a minor glitch. I agree with you completely.
Disk operations are never completely atomic, but they can and should be done so that it is almost impossible for the user to lose the file. With a rotating backup, it's probably possible to make it impossible to lose both the file and its backup.
Microsoft can't help it if you force an XP update onto a Win2K machine using an automated tool. Trying to manually install a patch onto the wrong operating system WILL fail as it should.
Seems like Microsoft and/or the automated tool makers have something very backwards. If trying to manually install a patch will fail, anything automated should certainly fail. Most likely both at fault. Microsoft for not clearly labeling and identifying the patches. The automated tool for subverting the sanity logic that would be used if the patch were manually installed.
if you overwrite your Linux kernel with a botched version, your system's hosed. If you didn't keep a backup, it's damned near impossible to back it out. Rubbish. Boot from the install disks. Aways in, Alt-F2, look around a bit and put the original kernel on top op the botched one. Newbie-level skill are adequate.
Nobody can protect an incompetent admin from him / herself. True, but there seem to be plenty of ways to make competent admins behave incompetently.
and most Microsoft ITs don't even know that you can use a linux system to diagnose Windows problems
Some of us do. I'm sure I'm far from being the only one. For some of us,/. is really the one essential news source, particularly for anything that has to do with Windows problems. This seems to hold true from Melissa on.
I don't think Microsoft will be endorsing this any time soon Microsoft is unlikely to endorse anything that doesn't further its vendor lock-in.
what do you consider highly specialized? We have a computer we save all our CAD files on at work via windows networking, and it uploads a backup of itself to another server every week, but only uploads the changes. I believe it's one of Novell's nice little setups.
Highly specialized. With the backups and nothing else restore all programs, configurations, registry setting, registrations, etc to a completely bare system. Like if a hard disk crashed.
Managing 60,000 computers. With almost no admin or unix skills, dd from the network or a USB disk should cover a lot of ground. A few scripts and some skill should make it quite manageable.
Managing 60,000 computers smoothly. No idea exactly what or how, but this should be very much in Novell's turf. Small minor details of just what is tweaked just which way will in total make a large difference. This is why corporations will gladly pay Novell for something that is not much worse that what they can get for free.
Call it, TCCR (total cost of catastrophic recovery).
Windows. Closed. Impossible to backup completely a running system without highly specialized software. Few effective recovery mechanisms.
Linux. Open. Almost trivial to backup completely a running system. Many effective recovery mechanisms. Live/Recovery disk of your own distro should work, although any other distro's may work even better.
Dunno about assigning costs, but it looks pretty lopsided to me.
My guess is that they all found an opportunity to have said it, likely on more than one occasion. The line is enough of a classic that, given a quick mind and the right opportunity, it would be repeated, whether or not they had even heard of it before.
Can anyone think of one good example where this clock serves any real purpose
Predicting earthquakes and volcanos. Finding oil, gas, mineral deposits. Hardly automatic, but attaining extreme accuracy cheaply can only help.
With a few high precision clocks broadcasting, it is possible to triangulate position precisely and hence the delay time. Precision in timing translates into precision in distance. If stuff is moving inches per decade or century, it would be interesting to know exactly how that movement is accomplished.
Basic machine code will have something like BNE or JNE for BRANCH or JUMP NOT EQUAL.
I think the coding style would tend towards ( (EQ... (EQ..., but if anyone felt the need of a NEQ they would simply make one without any sense of being clever or inventive.
Within any population, there will be some few who are more adventurous than most. Finding traces of their existence will be difficult, a few orders of magnitude more difficult than finding traces of mass migrations which in turn is a few orders of magnitude more difficult than finding traces of where the descendants flourished. It's like finding traces of mountain men and trappers from a couple of hundred years ago.
There are a few bits of evidence, like traces of tobacco in Egyptian mummies.
Saying that there were no people in North America before this, is akin to claiming a mathematical proof by absense of a counter example is valid. It isn't a proof, it is a lack of a counter example.
I'd say it's closer to claiming the odds that with 35 people in a room, the odds are about 1:10 of two having the same birthday. The Americas have probably been "discovered" many times in the past. The thing is, without very good evidence that will be very hard to find, we have no idea who went from where to where and what happened to to them.
Im protected mode you can set memory as executable,readable or both.
Not exactly. When CS DS and SS all refer to exactly the same memory, then memory which is written as DS or SS is executable by referring to those same bytes via CS. The 386 can be extremely secure, by having different segments refer to different memory, but that is all lost when all the segments refer to all of the memory. You can do the same thing in FORTRAN with a few arrays which just happen to cover all of memory.
Slashdot Mirror
However, I rarely see apps where truncating numbers to fit is considered a good thing. COBOL does that and it has been the source of many bad bugs, such as wrong paychecks.
Wrong paychecks as opposed to no paychecks for anybody.
Those are really the choices that you have with any constraints on the storage and manipulation of values.
You get to choose where you make the errors.
You do not get to choose to not make any errors.
For any storage mechanism, there exists at least one x for which x+1=x or x+1 is very wrong or the systems halts or creates an exception. Creating an exception is not a solution, unless you consider nobody gets a paycheck a solution.
A good design principle is: either do what you're told to do or tell us you didn't do it and why, but don't do something completely different.
As applied to taking a two hour final.
If you can't finish it accurately, then don't turn in your test paper.
A zero score is preferable to something not quite perfect.
And a man with three clocks has a pretty good idea which one is wrong.
As for data integrity, having NONE of the intended data is not exactly my idea of integrity.
and I honestly do not understand what is so damned scary about MySQL.
Send query, get answer. Life good. Carry on.
I've had this rattling around in my head last couple days. Maybe this sheds some light on the matter.
You have some hundred thousand records of raw data and an hour in which to process it.
MySQL: "Send query, get answer. Life good. Carry on."
Pedants: will still be working on it a week later.
Now, if you have "enterprise" class requirements, which do you use if you are responsible for the complete results.
MySQL is atomic at the statement or query level. This is a different granularity than something which is atomic at the transaction level. I suspect that the paradigm of the transactions, triggers, cascading deletes, etc. is that one expects to start a transaction, delete something at a high level, have the delete cascade until it runs into something which must be deleted and must not be deleted and causes a roll-back of the transaction. Dunno about you but to me that looks like an accident looking for a place to happen.
MySQL is extremely predictable and conservative in use of resources and if you're brave and daring enough, can be pushed beyond reason. I haven't done it but I'm sure than someone has managed to process at the "same time" raw data which amounts to about 250% of total disk space. Run it out of disk space and MySQL patiently waits for space to be freed without any other sign of a problem. There are surprises, but there are good and sound reasons for those surprises.
Referential Integrity:f integrity.htm
from http://databases.about.com/cs/administration/g/re
Consider the situation where we have two tables: Employees and Managers. The Employees table has a foreign key attribute entitled ManagedBy which points to the record for that employee's manager in the Managers table. Referential integrity enforces the following three rules:
1. We may not add a record to the Employees table unless the ManagedBy attribute points to a valid record in the Managers table.
2. If the primary key for a record in the Managers table changes, all corresponding records in the Employees table must be modified using a cascading update.
3. If a record in the Managers table is deleted, all corresponding records in the Employees table must be deleted using a cascading delete.
Rule 1 states that the President cannot be an employee, unless he's managed by, say, the janitor.
Rule 2 means that when your manager moves to a different position, you got moved.
Rule 3 means that when your manager is fired, you never existed.
Irreversibly executing a request that didn't even make sense is stunningly reckless.
There is a difference between your inability to make sense of something and the thing itself not making sense.
INSERT INTO foo SELECT * FROM bar LEFT JOIN baz ON whatever.
You are saying which?
That defining columns in foo as NON NULL is stunningly reckless?
That inserting rows from a join is stunningly reckless?
make the developer decide what should happen.
Which developer.
Seems the developers of MySQL did in fact decide what should happen.
Won't anyone give them a break?
No.
By selling it off they are opening themselves up to being at the mercy of whoever is building hardware and those people are told every two years by Microsoft what a standard PC will look like.
Razor thin margins and being told by Microsoft what your product will look like does not sound like a good business to be in.
Amerocentricity cause
Amerocentrocity result
Are you saying the problems they list don't exist?
Oh, I'm sure problems exist. They are in the nature of What is the value of something that does not exist? Different choices can be made and it is unreasonable to expect the choices that MySQL has made will exactly match the choices that you would make. What is the "value" of 0/0? A value does exist, it's just not numeric. Calling it undefined does not prevent it from happening.
What is completely missing is any indication of practical use of the distinctions he is making that would side with him on how those distinctions should be made. Having a formal system that is paradox-free is not particularly easy. It is possible to work productively in a system with paradoxes. You just don't push too hard on things like NULLs and thingees that have a mind of their own like TIMESTAMPs and AUTO_INCREMENT.
Insert NULL into a non-null column.
1. The end of the world. Kill the computer.
2. Kill (segfault) the program.
3. Kill the INSERT statement with error message.
4. Perform the non-error parts (rows) of the INSERT statement.
5. Assign the default non-null value to the column without comment.
If you want to preserve the NULL/NOT NULL distinction, you define the columns NULL. Personally I take the extra trouble to define columns NOT NULL precisely to obtain this "erroneous" behavior.
TIMESTAMP very useful if non-standard.
AUTO_INCREMENT primarily a mechanism to allow rows to co-exist which would otherwise collide. Giving explicit values to an AUTO_INCREMENT column is a good way to shoot yourself in the foot.
ENUM of numbers ??? Bad as FORTRAN FOUR = 3
If there is a vital distinction between 1 as an integer and 1 as a string, the design is just asking for trouble.
VARCHAR strips trailing blanks. Design decision. Different world than fixed rigid columns, as in COBOL or dBASE.
What database feature provides this capability?
The WHERE clause of a SELECT statement.
If you control all the SQL statements, pretty easy.
if the suppliers control (actually any of any of) the SQL statements, difficult.
"the supplier's database account" means that each supplier has his own database?
they were in competition with each other, and we had no doubt that they would do whatever necessary to win the business
You have some very legitimate concerns about SQL injection, like somebody deleteing or messing with competitors' quotes.
Security through ... pride? ... bragging? ... machismo?
Possible, if the security is already pretty damned good.
Cheap shot to maybe ferret out a few unk-unks (unknown unknowns) that you are in a position to jump on once you know what they are.
My old man use to program back in the mid 70's and early 80's.
;)
Yep, he's a youngster
I support a non drm pallidium like architecture which demands an encryption key for each set of data that needs to be executed. It sounds insane but its the only way to stop unathorized code from executing. Cpu level bound checking would also be nice.
That's like a lock that's so good you lock yourself out. Permanently.
Actually the Burroughs computers a bit before your old man's time, did precisely that, the bounds checking. Problem is, a number of programs that were aparently running ok would fail because they were actually doing something illegal.
but it will never be 100% secure.
Right. The question is how much effort is worthwhile and how good a security do you really need anyway? Elaborate security setups and junking old computers with hard drives intact
really the resulting assembly level code from the compiler which really leaves the door open for hackers.
This is the level at which code is exploited. The exploits do not use the source, they use the machine language. You need source to fix the exploit, not to exploit the code. In particular, any differences between what the machine code does and what the source code plus comments implies is probably capable of aloowing something undesirable.
The whole reason to migrate to NT back in the 90's was to avoid the security problems of Unix oddly enough.
Unix security is poor, but extremely effective considering the effort.
Anyway my old man was shocked when I told him that is the problem today with worms infecting computers.
Remember Melissa? Melissa was nice. Everything since has been pretty much predictable. The assumption or attitude that computers are nice and trustworthy paints a large target that can and does draw fire. It's a bad idea to claim that you are more secure than you are.
Reasons to overwrite the user's file:
Probably a bit faster.
Doesn't run out of space if the new file will fit.
Those are minor compared to losing the file completely because of a minor glitch.
I agree with you completely.
Disk operations are never completely atomic, but they can and should be done so that it is almost impossible for the user to lose the file. With a rotating backup, it's probably possible to make it impossible to lose both the file and its backup.
Microsoft can't help it if you force an XP update onto a Win2K machine using an automated tool. Trying to manually install a patch onto the wrong operating system WILL fail as it should.
Seems like Microsoft and/or the automated tool makers have something very backwards. If trying to manually install a patch will fail, anything automated should certainly fail.
Most likely both at fault.
Microsoft for not clearly labeling and identifying the patches.
The automated tool for subverting the sanity logic that would be used if the patch were manually installed.
if you overwrite your Linux kernel with a botched version, your system's hosed. If you didn't keep a backup, it's damned near impossible to back it out.
Rubbish. Boot from the install disks. Aways in, Alt-F2, look around a bit and put the original kernel on top op the botched one. Newbie-level skill are adequate.
Nobody can protect an incompetent admin from him / herself.
True, but there seem to be plenty of ways to make competent admins behave incompetently.
The fact that a fully patched XP machine is not vulnerable -- this is the basic truth that I'm arguing
Oh I'm sure it's vulnerable. It's just that nobody know what the vulnerabilities are yet. At least nobody but the bad guys.
and most Microsoft ITs don't even know that you can use a linux system to diagnose Windows problems
/. is really the one essential news source, particularly for anything that has to do with Windows problems. This seems to hold true from Melissa on.
Some of us do. I'm sure I'm far from being the only one.
For some of us,
I don't think Microsoft will be endorsing this any time soon
Microsoft is unlikely to endorse anything that doesn't further its vendor lock-in.
what do you consider highly specialized?
We have a computer we save all our CAD files on at work via windows networking, and it uploads a backup of itself to another server every week, but only uploads the changes. I believe it's one of Novell's nice little setups.
Highly specialized.
With the backups and nothing else restore all programs, configurations, registry setting, registrations, etc to a completely bare system. Like if a hard disk crashed.
Managing 60,000 computers.
With almost no admin or unix skills, dd from the network or a USB disk should cover a lot of ground. A few scripts and some skill should make it quite manageable.
Managing 60,000 computers smoothly.
No idea exactly what or how, but this should be very much in Novell's turf. Small minor details of just what is tweaked just which way will in total make a large difference. This is why corporations will gladly pay Novell for something that is not much worse that what they can get for free.
Call it, TCCR (total cost of catastrophic recovery).
Windows. Closed. Impossible to backup completely a running system without highly specialized software. Few effective recovery mechanisms.
Linux. Open. Almost trivial to backup completely a running system. Many effective recovery mechanisms. Live/Recovery disk of your own distro should work, although any other distro's may work even better.
Dunno about assigning costs, but it looks pretty lopsided to me.
My guess is that they all found an opportunity to have said it, likely on more than one occasion.
The line is enough of a classic that, given a quick mind and the right opportunity, it would be repeated, whether or not they had even heard of it before.
Can anyone think of one good example where this clock serves any real purpose
Predicting earthquakes and volcanos.
Finding oil, gas, mineral deposits.
Hardly automatic, but attaining extreme accuracy cheaply can only help.
With a few high precision clocks broadcasting, it is possible to triangulate position precisely and hence the delay time. Precision in timing translates into precision in distance. If stuff is moving inches per decade or century, it would be interesting to know exactly how that movement is accomplished.
Basic machine code will have something like BNE or JNE for BRANCH or JUMP NOT EQUAL.
... (EQ ..., but if anyone felt the need of a NEQ they would simply make one without any sense of being clever or inventive.
...
I think the coding style would tend towards ( (EQ
(NOT (EQ
1. A system for determining if two operands point to different locations in memory
Sounds like eq in Lisp.
(eq 2 2) may evaluate to false if they are different 2's.
Isnot is a pretty obvious spelling of isn't if you're not allowed to use the apostrophe.
Within any population, there will be some few who are more adventurous than most. Finding traces of their existence will be difficult, a few orders of magnitude more difficult than finding traces of mass migrations which in turn is a few orders of magnitude more difficult than finding traces of where the descendants flourished. It's like finding traces of mountain men and trappers from a couple of hundred years ago.
There are a few bits of evidence, like traces of tobacco in Egyptian mummies.
Saying that there were no people in North America before this, is akin to claiming a mathematical proof by absense of a counter example is valid. It isn't a proof, it is a lack of a counter example.
I'd say it's closer to claiming the odds that with 35 people in a room, the odds are about 1:10 of two having the same birthday. The Americas have probably been "discovered" many times in the past. The thing is, without very good evidence that will be very hard to find, we have no idea who went from where to where and what happened to to them.
Im protected mode you can set memory as executable,readable or both.
Not exactly.
When CS DS and SS all refer to exactly the same memory, then memory which is written as DS or SS is executable by referring to those same bytes via CS.
The 386 can be extremely secure, by having different segments refer to different memory, but that is all lost when all the segments refer to all of the memory. You can do the same thing in FORTRAN with a few arrays which just happen to cover all of memory.
"The entry page to Microsoft's Web site."
That's the first usable result I've seen from MSN search.
Usually it complains because it fails to find an numeric IP or a name on the LAN.