how the fuck does that kludge beat a simple bind reload?
But you don't get it! djbdns is simpler than BIND! Well, except when you have to make your own ad-hoc workaround for its lack of features, and your workaround is non-standard and won't interoperate with any of your partners' systems, and you're the only person in the world testing it so there's no peer review. But it's simpler! Really!
How long/how much data would 100,000 records transmitted via AXFR take? Like 1 minute? Big deal.
Now imagine it's the zonefile for Dynamic DNS for a large organization, so it's not only the fact that there are 100,000 records, but that there are continual updates. AXFR, etc.: you wouldn't be finished with the transfer before the next needs to start. IXFR: you keep the 10 slave servers updated with changes no more than a second or two old.
IXFR, not AXFR. IXFR is sort of like a journal playback. Suppose you have 100,000 records in a zone. With AXFR, if you change one record, you have to retransmit all 100,000 records. With IXFR, you transmit the change alone. The suggested workaround is to use rsync or some other synching mechanism, but with djbdns that'd mean that rsync has to sync a directory with 100,000 files. Again, with IXFR you'd just replay the journal.
I did. That isn't the official version of djbdns; it's a fork. Furthermore, note that even the "enhanced" fork fails to support such fundamental necessities as IXFR. You can hobble together some hackish workalike with rsync - assuming you have control over both servers. Good luck getting a registrar or any other free/cheap DNS hosting service to go along with that arrangement.
As always, djbdns is probably OK as long as you don't need any of the (common) features it doesn't support. If you do, it stops looking so clever.
Too bad it does support AAAA records and SRV records.
No it doesn't. The official release, version 1.05 on his site, doesn't support serving AAAA records and contains no mention of SRV at all. Go ahead: download and grep for it. There are patch unofficial versions that do all sorts of things, but by that standard any software supports just about anything.
This Bernstein guy is pushing a new crypto algorithm. Why is it necessary to use a new one when old ones have been demonstrated to be effective and secure?
Because Dan is Dan and won't be happy unless he writes libdancurve and makes you install it in/crypto/strong/etc/librarees for the next decade because it's under a non-FOSS license. Who know why he does anything he does?
You alluded to health code and food service code violations and yet you don't see the concept that because they passed those and are in business still, they are at least clean enough to meet the law's idea of clean.
This means the owner already has a basis to ground the cleanliness of the store on.
Not even close. The health inspection states that the place met the minimum government standard of non-deadliness, but that's entirely different from saying that it's clean by another person's standards.
Any database can experience data loss. That includes Oracle, SQL Server, and even your beloved PostgreSQL. This can happen for any number of reasons, including (but not limited to) hardware failure, power failure, user error, etc. Postgres isn't going to help you if you forget a WHERE clause. Oracle isn't going to help you if your RAID is corrupted.
But none of those are failures of the databases themselves. I won't blame MySQL if a meteor takes out the data center. I'll blame the heck out of it when I get "Table 'FOO' is marked as crashed and should be repaired" for no apparent reason.
FWIW, I have never had a MySQL database lose data
I don't doubt you at all, but my point is that it's happening to some people often enough that people are talking about it. That's wholly unacceptable.
Also FWIW, it is possible to experience data loss with Postgres, where it is Postgres's fault (as opposed to the RDBMS not being able to recover from some external fault). Example 1 [juniper.net]. Example 2 [postgresql.org].
Example one was fixed in 2002. Example two only crops up when you've inserted more than 4Gigarows without the (once a minute) autovacuum daemon cleaning up a table. Furthermore, "If for some reason autovacuum fails to clear old XIDs from a table, the system will begin to emit warning messages like this when the database's oldest XIDs reach ten million transactions from the wraparound point [...] If these warnings are ignored, the system will shut down and refuse to execute any new transactions once there are fewer than 1 million transactions left until wraparound". Even in the worst case, PostgreSQL avoids data loss.
When I lived in SoCal it was the fashion to take goofy license pictures, like while taking a bite from a sandwich or howling. Your idea would let such people get it out of their system while still being usable. Nice!
I've not once had it "blow a table." No doubt that's been your experience.
Here's my problem: the fact that it's even a debating point indicates that it happens way more often than should be tolerated in a database of all things. When people talk about PostgreSQL, they gripe about the (supposed?) lack of replication, but no one complains that they've lost data to it. Same with Oracle: no one loves the price, but it works. SQL Server: hate the lockin, but it works. Even SQLite: not very concurrent, but it works.
That is the reason why I don't recommend MySQL. A database should work 100% of the time, for everyone, and discussion should revolve around features or price or support. It should go without saying that it never loses data. That's just not something you should ever even have in the back of your mind.
I've run MySQL datase servers on my websites for nearly 10 years without one problem.
I think the discriminator is the ratio of reads to writes. If it's read-mostly with just a few updates here and there, MySQL can (probably) go a long time without serious data corruption. I would absolutely not recommend it on a site with many update. Slashdot, for example, is in the former category. At say 20 stories per day with maybe 200 posts per story, that's only 4,000 insertions to the comments tables. Since it doesn't allow editing, there are no updates involved. I'll throw in another 10,000 moderation events. Now, compared to Slashdot's huge viewing traffic, that's practically read-only.
Tens of thousands of hits per day.
On a site that slow, you (probably) won't see corruption any time soon.
Use that money to give cash payouts to the teachers (not the schools) whose kids have the greatest degree of improvement in their region, with "improvement" defined as a conrete metric.
So to heck with the teachers doing a good job today, because they won't have as much room for improvement.
Did you completely prevent your daughter from watching TV -- where she would encounter a steady stream of images of little girls dressed in pink and playing with dolls?
<anecdote>My 8-year-old daughter thinks dolls are OK, but is just as likely to play with my son's pirate ship. My 5-year-old daughter told me that she wants to be a princess when she grows up. I assert that my youngest daughter has not been exposed to more outside influences than my oldest. If anything, I'd say she's seen more of her big sister's preferences, where the oldest didn't have any big sister to act as a role model.</anecdote>
That solution is "total debt amnesty". That is, there is a declaration that every person and every business no longer owes what they owed as of a specified date (when it passes).
I owe the bank a large amount of money for my mortgage. When I fail to pay it back, I imagine they'd reciprocate by forgetting about my savings account (and yours). Yeah, that's a well thought out plan that can't possibly go wrong!
Slashdot Mirror
how the fuck does that kludge beat a simple bind reload?
But you don't get it! djbdns is simpler than BIND! Well, except when you have to make your own ad-hoc workaround for its lack of features, and your workaround is non-standard and won't interoperate with any of your partners' systems, and you're the only person in the world testing it so there's no peer review. But it's simpler! Really!
How long/how much data would 100,000 records transmitted via AXFR take? Like 1 minute? Big deal.
Now imagine it's the zonefile for Dynamic DNS for a large organization, so it's not only the fact that there are 100,000 records, but that there are continual updates. AXFR, etc.: you wouldn't be finished with the transfer before the next needs to start. IXFR: you keep the 10 slave servers updated with changes no more than a second or two old.
He may be excentric, but I don't think he insists on spelling things wwong.
I've never seen anyone else spell "/opt" as "/service".
IXFR, not AXFR. IXFR is sort of like a journal playback. Suppose you have 100,000 records in a zone. With AXFR, if you change one record, you have to retransmit all 100,000 records. With IXFR, you transmit the change alone. The suggested workaround is to use rsync or some other synching mechanism, but with djbdns that'd mean that rsync has to sync a directory with 100,000 files. Again, with IXFR you'd just replay the journal.
There's a ton of dns traffic.. that adds up. Not to mention system overhead in the connection establishment on the higher usage(think root) servers.
In fairness, you could mitigate that two ways:
You are mistaken. Go to tinydns.org and read
I did. That isn't the official version of djbdns; it's a fork. Furthermore, note that even the "enhanced" fork fails to support such fundamental necessities as IXFR. You can hobble together some hackish workalike with rsync - assuming you have control over both servers. Good luck getting a registrar or any other free/cheap DNS hosting service to go along with that arrangement.
As always, djbdns is probably OK as long as you don't need any of the (common) features it doesn't support. If you do, it stops looking so clever.
Too bad it does support AAAA records and SRV records.
No it doesn't. The official release, version 1.05 on his site, doesn't support serving AAAA records and contains no mention of SRV at all. Go ahead: download and grep for it. There are patch unofficial versions that do all sorts of things, but by that standard any software supports just about anything.
That would be the "after a decade" I was alluding to.
This Bernstein guy is pushing a new crypto algorithm. Why is it necessary to use a new one when old ones have been demonstrated to be effective and secure?
Because Dan is Dan and won't be happy unless he writes libdancurve and makes you install it in /crypto/strong/etc/librarees for the next decade because it's under a non-FOSS license. Who know why he does anything he does?
.... seriously why use the mouse? Ratpoison offers the user a GUI without being slowed down by reaching for the mouse.
Because we're 1337 enough to not have to prove how 1337 we are?
You alluded to health code and food service code violations and yet you don't see the concept that because they passed those and are in business still, they are at least clean enough to meet the law's idea of clean.
This means the owner already has a basis to ground the cleanliness of the store on.
Not even close. The health inspection states that the place met the minimum government standard of non-deadliness, but that's entirely different from saying that it's clean by another person's standards.
So if you want to say some shop is dirty, bad, etc - then you better offer up some proof.
Yep. When you say you found dog poop in the halls of the Ramada Inn in Kearney, Nebraska, it's nice to have pictures to prove it. There's not a lot they can do about that.
Any database can experience data loss. That includes Oracle, SQL Server, and even your beloved PostgreSQL. This can happen for any number of reasons, including (but not limited to) hardware failure, power failure, user error, etc. Postgres isn't going to help you if you forget a WHERE clause. Oracle isn't going to help you if your RAID is corrupted.
But none of those are failures of the databases themselves. I won't blame MySQL if a meteor takes out the data center. I'll blame the heck out of it when I get "Table 'FOO' is marked as crashed and should be repaired" for no apparent reason.
FWIW, I have never had a MySQL database lose data
I don't doubt you at all, but my point is that it's happening to some people often enough that people are talking about it. That's wholly unacceptable.
Also FWIW, it is possible to experience data loss with Postgres, where it is Postgres's fault (as opposed to the RDBMS not being able to recover from some external fault). Example 1 [juniper.net]. Example 2 [postgresql.org].
Example one was fixed in 2002. Example two only crops up when you've inserted more than 4Gigarows without the (once a minute) autovacuum daemon cleaning up a table. Furthermore, "If for some reason autovacuum fails to clear old XIDs from a table, the system will begin to emit warning messages like this when the database's oldest XIDs reach ten million transactions from the wraparound point [...] If these warnings are ignored, the system will shut down and refuse to execute any new transactions once there are fewer than 1 million transactions left until wraparound". Even in the worst case, PostgreSQL avoids data loss.
I think you might want better examples next time.
PS, that's really old data but I knew where to find it quickly :-).
MySQL doesn't support transactions. I know that's a really old complaint but I knew where to find it quickly :-).
When I lived in SoCal it was the fashion to take goofy license pictures, like while taking a bite from a sandwich or howling. Your idea would let such people get it out of their system while still being usable. Nice!
Perhaps he's a Bart fan in Australia.
I've not once had it "blow a table." No doubt that's been your experience.
Here's my problem: the fact that it's even a debating point indicates that it happens way more often than should be tolerated in a database of all things. When people talk about PostgreSQL, they gripe about the (supposed?) lack of replication, but no one complains that they've lost data to it. Same with Oracle: no one loves the price, but it works. SQL Server: hate the lockin, but it works. Even SQLite: not very concurrent, but it works.
That is the reason why I don't recommend MySQL. A database should work 100% of the time, for everyone, and discussion should revolve around features or price or support. It should go without saying that it never loses data. That's just not something you should ever even have in the back of your mind.
I've run MySQL datase servers on my websites for nearly 10 years without one problem.
I think the discriminator is the ratio of reads to writes. If it's read-mostly with just a few updates here and there, MySQL can (probably) go a long time without serious data corruption. I would absolutely not recommend it on a site with many update. Slashdot, for example, is in the former category. At say 20 stories per day with maybe 200 posts per story, that's only 4,000 insertions to the comments tables. Since it doesn't allow editing, there are no updates involved. I'll throw in another 10,000 moderation events. Now, compared to Slashdot's huge viewing traffic, that's practically read-only.
Tens of thousands of hits per day.
On a site that slow, you (probably) won't see corruption any time soon.
Here I am the most right wing guy on slashdot
Don't be so sure, Eleanor.
Use that money to give cash payouts to the teachers (not the schools) whose kids have the greatest degree of improvement in their region, with "improvement" defined as a conrete metric.
So to heck with the teachers doing a good job today, because they won't have as much room for improvement.
Did you completely prevent your daughter from watching TV -- where she would encounter a steady stream of images of little girls dressed in pink and playing with dolls?
<anecdote>My 8-year-old daughter thinks dolls are OK, but is just as likely to play with my son's pirate ship. My 5-year-old daughter told me that she wants to be a princess when she grows up. I assert that my youngest daughter has not been exposed to more outside influences than my oldest. If anything, I'd say she's seen more of her big sister's preferences, where the oldest didn't have any big sister to act as a role model.</anecdote>
Ah, this would explain why most of my ex-girlfriends are now lesbians.
Because they were really un-masculine men to start with?
Imagine your pain on that one weekend off when you get home to find 5 wives and nobody to screw.
That would be horrible, because married men are usually famous for being able to have sex any time they want to.
a couple years ago I read a story about kids in the midwest getting high by strangling themselves.
I remember watching third graders do this at recess as early as 1979.
That solution is "total debt amnesty". That is, there is a declaration that every person and every business no longer owes what they owed as of a specified date (when it passes).
I owe the bank a large amount of money for my mortgage. When I fail to pay it back, I imagine they'd reciprocate by forgetting about my savings account (and yours). Yeah, that's a well thought out plan that can't possibly go wrong!