I recall a discussion about fsync not being properly implemented both in Linux Kernel 2.4 as well as 2.6. I think it was patched in 2.6.9 or so, but not in 2.4.
Unfortunately, I cannot find the thread any more. Does anybody remember?
So, this might be rather a linux kernel bug, not a mysql bug.
Secondly, why does everybody say that mysql does not support ACID-transactions? MySQL does advertise them. Are you talking about pre-4.0 MyIsam tables? Or do you suggest that 4.0/4.1 InnoDB-tables aren't ACID-compliant either?
There are bug-fixes-only patches available since 2.6.10 thanks to Andres Salomon. So if you are afraid of a 2.6.x kernel you can wait for 2.6.x.n which won't contain the most cruel bugs.
*totally* abstaining form caffeine (including coffee, tea, soft drinks)?
totally abstaining from alcohol
totally abstaining from sleeping aids(!)
doing some light to medium cardio activity in the morning or early afternoon (but not in the evening)
refraining from taking naps during the day (only one sleep interval -- at night)
getting up at 7 a.m. (or even earlier), no matter what
Have you followed the above hints together and religiously for at least four weeks?
Many insomniacs are "cured" with the above mentioned measurements.
Additionally, has a psychiatric doctor checked you whether you suffer from clinical depression? Really severe insomnia often is a symptom of clinical depression.
Which line do I have to add to/etc/apt/sources.list to get security-updates for testing? I still do not believe there are any security updates for testing.
Sure, testing gets packages which previously showed maturity in unstable. And sure, some day the current testing version will be the stable version and than get security updates. But as long as the version is testing, you will have to wait until a new software package version is approved to go from unstable into testing.
In fact, I had precisely this situation early in 2002, when I did use testing (woody) for a production web server. Apache got a new security patch. This patch was backported to stable. The new apache package went to unstable, but it lasted pretty long until it got into testing. There was a testing patch I managed to find on a private website, but you had to dig deep into mailing lists in order to find a reference to it. If you did not get the news about the apache hole, your server would have been vulnerable for quite some time.
I do think that the description you pasted from the debian site is misleading. The facts on the site are perfectly correct. But it suggests that there is a hierarchy in the maturity of the software-packages which goes unstable->testing->stable and that you could use testing for medium important production servers. This suggestion is wrong.
Many people using debian do not understand what the labels stable, testing and unstable mean.
Debian stable ist called stable, because the packages are only replaced in order to fix security flaws. The security patches are manually backported by the debian security team. This concept assures that one can configure a system and handcoded scripts will not break until a new version of debian stable is released (every 2-3 years!).
So stable has the meaning that one can install a system, do automatic daily security updates and forget about it until the next version comes.
Debian unstable gets updated packages every day. So if you would like to have current software you could chose debian unstable. Unstable does not get security fixes. This isn't too bad, because the original software mainainers patch their software and this will get into debian unstable pretty soon.
Than there is debian testing which is meant to be the testing system before the release of the next version of debian stable. It does not get security patches. It sometimes does not get timely package updates.
If you want a system which is stable in the way, that the software does not have many bugs, you should NOT use debian stable, but UNSTABLE!!! This is because non-security-bugs are not patched in debian stable, but in debian unstable, as new versions arrive there. A good example is mozilla: In debian stable, the current version is 1.0.0! It did not even get security fixes as this would have meant too much work! In debian unstable the current version of mozilla is 1.7. Mozilla 1.7 definetely crashes less often than Mozilla 1.0.0!
Do not use debian testing for other reasons than testing the next version of debian stable! Testing has sometimes outdated software AND does not get security patches. This combines the bad features of stable and unstable!
So if you want a system that almost never changes, because you do not have the time to reconfigure your system often, use debian stable. In all other cases, use debian unstable. It is not less secure. In some cases, like mozilla, it is MORE SECURE! Never use debian testing, except you want to help with testing at the debian community. Please do not suggest that debian stable has less bugs than debian testing which has less bugs than debian unstable. Almost the opposite is true!
Additionally to the arguments concerning the paper trail and the anonymity there is another factor:
Internet Banking requires a much less security level than Internet Voting. If a banking system is manipulated than either the bank or the customer loses money. The bank maybe has an insurance. The customer can choose whether to use internet voting or not.
With Internet Voting the voters cannot choose: even if they can choose whether they want to cast their ballot via the internet or conventionally, they cannot decide whether other voters cast their ballot via the internet.So it might be possible that with an internet vote 85% of the overea military personel is voting for bush, although only 60% intended to do, because the system was manipulated. For a person who does not trust the system and is not in the military it doesn't matter whether he casts his ballot in a box or via the internet: there might be hundreds of thousand or even millions of manipulated ballots (or a manipulated result), which he cannot prevent be casting his ballot in a conventional box.
So if a bank screws an internet system up it, or its clients only loses money. Both parties have agreed on accepting the risc.
If an internet voting system is screwed there might be an unelected president sitting in the white house. And if it seems to be obvious that the result was manipulated it might not end up as peacefully as the 2000 election. E.g. many voters could try to "impeach" the non-elected president by force.
So with internet voting the stability of a democracy and society is at stake. This is why you would need a 100% error free software. Not an easy task.
The NSDAP got 30 per cent or so in the last Reichstags election. Unfortunately there wasn't any candidate left to be chancelor. Everyone capable already tried and messed up. So Hindenburg, the Reichspresident (who was too old to get anything straight any more) chose Hitler as chancelor, as he thought Hitler would proof that he is not capable either and so the NSDAP would vanish.
A few weeks later, the NSDAP got the Ermächtigungsgesetz (authorization bill) through the Reichstag: The parliament decided to turn all power to Hitler and
to shut down/impeach the complete parliament.
The completely flawed constitution of the Weimar Republic allowed that. Of course the NSDAP had only a third of the seats in parliamant. But the SA marched up in front of the parliamant and did not let social democrats, communists, etc into the parliamant (some of them were already arrested by then).
So, yes, 30 per cent of the germans elected Hitler. But he only got to power because he did the trick with the Ermächtigungsgesetz. The problem with germany was that far to few germans did anything against that coup. Most of them wanted a better economy (a really lot of people where without a job) and wanted Hitler to do "something against hte jews" (not really kill them, but teach them a lesson, or so).
The Bush election is completely different. Sure,
the voting election, the Supreme Court and the whole voting system was completely flawed. But Bush did not proactively participate in a coup like Hilter. Further you cannot compare the intensions of Bush and Hitler at all. And after all - I do not think Bush will have such a huge impact on history as Hitler.
No.
You cannot recount the Florida ballots wih the same result twice, because some chad will fall of the ballots during the process.
The paper and pencil-method is indefinately recountable.
Fax machines are only used to transmit the results
for the intermediate result on the same evening.
The official end result is additionally checked. Every step of the whole process is completely transparend to every citizen.
After the extensive re-counts and press and public auditing of the result, it was found to be correct.
You are wrong. The result was not found to be correct. If all ballots would have been recounted in the whole state of Florida (which even Gore did not demand), Gore might have won. This was found by a complete manual recount of all Florida ballots by a consortium of major newspapers http://vander.hashish.com/articles/election2000/no rcnw.html
(Newsweek article) . Project site is here: http://www.norc.org/fl/
The US 2000 Presidential Election is the one and only master example of what can go wrong if you use flawed voting technology. There is probably a non-elected man sitting as president in the white house right now -- because of flawed voting technology.
It is only for political reasons why this is not
shaking the foundations of the political system of the United States. Would this election desaster have happened in Europe the elected government would be in really serious trouble.
I don't know about 0.5. The nightly build from March 20th seems to have still quite a few leaks. But not enough to affect the useability - in my opinion.
I guess I will keep using this build still after 0.6 or 0.7 is out, because it just works. After having installed Java, Flash, Acrobat PDF-Viewer, RealPlayer and MPlayer there are just no open wishes any more:-).
Unfortunately, 0.5 is very old and there are only
nightly releases since then.
Try the nightly build from March 20th. It haven't managed to crash it once in those weeks.
Slashdot Mirror
mentioned LKML thread (and it was 2.6.5)
I recall a discussion about fsync not being properly implemented both in Linux Kernel 2.4 as well as 2.6. I think it was patched in 2.6.9 or so, but not in 2.4.
Unfortunately, I cannot find the thread any more. Does anybody remember?
So, this might be rather a linux kernel bug, not a mysql bug.
Secondly, why does everybody say that mysql does not support ACID-transactions? MySQL does advertise them. Are you talking about pre-4.0 MyIsam tables? Or do you suggest that 4.0/4.1 InnoDB-tables aren't ACID-compliant either?
There are bug-fixes-only patches available since 2.6.10 thanks to Andres Salomon. So if you are afraid of a 2.6.x kernel you can wait for 2.6.x.n which won't contain the most cruel bugs.
- *totally* abstaining form caffeine (including coffee, tea, soft drinks)?
- totally abstaining from alcohol
- totally abstaining from sleeping aids(!)
- doing some light to medium cardio activity in the morning or early afternoon (but not in the evening)
- refraining from taking naps during the day (only one sleep interval -- at night)
- getting up at 7 a.m. (or even earlier), no matter what
Have you followed the above hints together and religiously for at least four weeks?Many insomniacs are "cured" with the above mentioned measurements.
Additionally, has a psychiatric doctor checked you whether you suffer from clinical depression? Really severe insomnia often is a symptom of clinical depression.
Which line do I have to add to /etc/apt/sources.list to get security-updates for testing? I still do not believe there are any security updates for testing.
Sure, testing gets packages which previously showed maturity in unstable. And sure, some day the current testing version will be the stable version and than get security updates. But as long as the version is testing, you will have to wait until a new software package version is approved to go from unstable into testing.
In fact, I had precisely this situation early in 2002, when I did use testing (woody) for a production web server. Apache got a new security patch. This patch was backported to stable. The new apache package went to unstable, but it lasted pretty long until it got into testing. There was a testing patch I managed to find on a private website, but you had to dig deep into mailing lists in order to find a reference to it. If you did not get the news about the apache hole, your server would have been vulnerable for quite some time.
I do think that the description you pasted from the debian site is misleading. The facts on the site are perfectly correct. But it suggests that there is a hierarchy in the maturity of the software-packages which goes unstable->testing->stable and that you could use testing for medium important production servers. This suggestion is wrong.
Many people using debian do not understand what the labels stable, testing and unstable mean.
Debian stable ist called stable, because the packages are only replaced in order to fix security flaws. The security patches are manually backported by the debian security team. This concept assures that one can configure a system and handcoded scripts will not break until a new version of debian stable is released (every 2-3 years!).
So stable has the meaning that one can install a system, do automatic daily security updates and forget about it until the next version comes.
Debian unstable gets updated packages every day. So if you would like to have current software you could chose debian unstable. Unstable does not get security fixes. This isn't too bad, because the original software mainainers patch their software and this will get into debian unstable pretty soon.
Than there is debian testing which is meant to be the testing system before the release of the next version of debian stable. It does not get security patches. It sometimes does not get timely package updates.
If you want a system which is stable in the way, that the software does not have many bugs, you should NOT use debian stable, but UNSTABLE!!! This is because non-security-bugs are not patched in debian stable, but in debian unstable, as new versions arrive there. A good example is mozilla: In debian stable, the current version is 1.0.0! It did not even get security fixes as this would have meant too much work! In debian unstable the current version of mozilla is 1.7. Mozilla 1.7 definetely crashes less often than Mozilla 1.0.0!
Do not use debian testing for other reasons than testing the next version of debian stable! Testing has sometimes outdated software AND does not get security patches. This combines the bad features of stable and unstable!
So if you want a system that almost never changes, because you do not have the time to reconfigure your system often, use debian stable. In all other cases, use debian unstable. It is not less secure. In some cases, like mozilla, it is MORE SECURE! Never use debian testing, except you want to help with testing at the debian community.
Please do not suggest that debian stable has less bugs than debian testing which has less bugs than debian unstable. Almost the opposite is true!
Additionally to the arguments concerning the paper trail and the anonymity there is another factor: Internet Banking requires a much less security level than Internet Voting. If a banking system is manipulated than either the bank or the customer loses money. The bank maybe has an insurance. The customer can choose whether to use internet voting or not.
With Internet Voting the voters cannot choose: even if they can choose whether they want to cast their ballot via the internet or conventionally, they cannot decide whether other voters cast their ballot via the internet.So it might be possible that with an internet vote 85% of the overea military personel is voting for bush, although only 60% intended to do, because the system was manipulated. For a person who does not trust the system and is not in the military it doesn't matter whether he casts his ballot in a box or via the internet: there might be hundreds of thousand or even millions of manipulated ballots (or a manipulated result), which he cannot prevent be casting his ballot in a conventional box.
So if a bank screws an internet system up it, or its clients only loses money. Both parties have agreed on accepting the risc.
If an internet voting system is screwed there might be an unelected president sitting in the white house. And if it seems to be obvious that the result was manipulated it might not end up as peacefully as the 2000 election. E.g. many voters could try to "impeach" the non-elected president by force.
So with internet voting the stability of a democracy and society is at stake. This is why you would need a 100% error free software. Not an easy task.
The NSDAP got 30 per cent or so in the last Reichstags election. Unfortunately there wasn't any candidate left to be chancelor. Everyone capable already tried and messed up. So Hindenburg, the Reichspresident (who was too old to get anything straight any more) chose Hitler as chancelor, as he thought Hitler would proof that he is not capable either and so the NSDAP would vanish.
A few weeks later, the NSDAP got the Ermächtigungsgesetz (authorization bill) through the Reichstag: The parliament decided to turn all power to Hitler and to shut down/impeach the complete parliament. The completely flawed constitution of the Weimar Republic allowed that. Of course the NSDAP had only a third of the seats in parliamant. But the SA marched up in front of the parliamant and did not let social democrats, communists, etc into the parliamant (some of them were already arrested by then).
So, yes, 30 per cent of the germans elected Hitler. But he only got to power because he did the trick with the Ermächtigungsgesetz. The problem with germany was that far to few germans did anything against that coup. Most of them wanted a better economy (a really lot of people where without a job) and wanted Hitler to do "something against hte jews" (not really kill them, but teach them a lesson, or so).
The Bush election is completely different. Sure, the voting election, the Supreme Court and the whole voting system was completely flawed. But Bush did not proactively participate in a coup like Hilter. Further you cannot compare the intensions of Bush and Hitler at all. And after all - I do not think Bush will have such a huge impact on history as Hitler.
No.
You cannot recount the Florida ballots wih the same result twice, because some chad will fall of the ballots during the process.
The paper and pencil-method is indefinately recountable.
Fax machines are only used to transmit the results for the intermediate result on the same evening. The official end result is additionally checked. Every step of the whole process is completely transparend to every citizen.
After the extensive re-counts and press and public auditing of the result, it was found to be correct. You are wrong. The result was not found to be correct. If all ballots would have been recounted in the whole state of Florida (which even Gore did not demand), Gore might have won. This was found by a complete manual recount of all Florida ballots by a consortium of major newspapers http://vander.hashish.com/articles/election2000/no rcnw.html
(Newsweek article) . Project site is here: http://www.norc.org/fl/
The US 2000 Presidential Election is the one and only master example of what can go wrong if you use flawed voting technology. There is probably a non-elected man sitting as president in the white house right now -- because of flawed voting technology.
It is only for political reasons why this is not
shaking the foundations of the political system of the United States. Would this election desaster have happened in Europe the elected government would be in really serious trouble.
I don't know about 0.5. The nightly build from March 20th seems to have still quite a few leaks. But not enough to affect the useability - in my opinion. I guess I will keep using this build still after 0.6 or 0.7 is out, because it just works. After having installed Java, Flash, Acrobat PDF-Viewer, RealPlayer and MPlayer there are just no open wishes any more :-).
Unfortunately, 0.5 is very old and there are only nightly releases since then. Try the nightly build from March 20th. It haven't managed to crash it once in those weeks.