"Asked whether Microsoft is considering integrating the virtual technology into the core Windows kernel, Huffman skirted the issue, saying Microsoft is committed to developing virtualization solutions for the Windows platform. "It's too early to say how we will deliver these solutions going forward," Huffman said."
Consider two different "embrace and extend" compatible strategies: A) add a virtualized sandbox for Linux/BSD/etc. or B) add a Linux compatibility layer to the Windows XP/2000 kernel.
Strategy A also provides them with some added benefits - it solves a whole bunch of security embarassments in one fell swoop and re-opens some markets that are currently starting to close down on them. They could also argue that the virtualization is generic, and therefore they are not directly competing in the Unix market ("we treat Linux as any other third-party app.")
Strategy B boils down to a pissing-match over kernels - I still lock up XP on a several-times-a-week basis, but if they _could_ get a stable and secure kernel (yeah, I know, not holding my breath either), they could effectively co-opt everything in the OSS world for their own benefit without having to worry about "viral" licenses, while still providing a platform for their own proprietary software product line. Of course, they would have to get out of (if they haven't already - did SCO really inherit the Xenix contract?) that pesky committment not to compete in the Unix market.
The best attack for Windows to embrace and extend Linux is to first confuse the two and assimilate what people think of as "Linux" into Windows (or...shudder...vice-versa.)
Projects like WINE have us thinking in one direction - what if Microsoft were to pull the same trick going the other direction? If they can't sell a Microsoft-branded web server, at least they can sell the operating system that you run Apache on top of.
Strategy C scares me the most: Microsoft would have to decide how important their kernel is to their OS sales - THEY could just as easily create a 100% working WINE and sell the Windows "Look & Feel" running on top of Linux or BSD kernel just as MacOS did (except under x86), and re-brand it as a security-solution with cross-platform compatibility benefits (that will cost just about the same price as their own-kerneled OS's, methinks.) You can see how they are pissed-off at the GPL - that's how they get around it and get the open-source volunteers working for them.
I have to hurry and finish this because the Microsoft Death-Beam satellite is due over my home in just a few moments, and I'm running low on tin-foil and........gahhhhhhhhhhhhhhhh!!!
Anyone who knows the recent history of how Interbase became Firebird appreciates just how wretched and bloody and ugly the final months were before it became open source. There were folks fighting tooth and nail to give this incredible product a fighting chance, and I have nothing but respect for what they have achieved. If you spend a couple of hours really, seriously researching what this product offers, you'll not only wonder how Borland could mismanage it as badly as they did, but also wonder why MySQL and PostgreSQL get so much press without being mentioned as an afterthought. If only a tenth of the resources were placed into Firebird as are placed into PostgreSQL, I seriously wonder if PostgreSQL wouldn't be largely abandoned within the next two years.
This is a story about a beat up and exhausted small group of core supporters coming up with a name, and then, a year and some months later, just as they're really starting to get the code base they inherited under control and figured out, a much bigger and well known crew picks that same name. It isn't that the Mozilla team couldn't keep the Firebird name - it's that they shouldn't. It isn't that anyone will confuse a web browser with a RDBMS, it's that it's a completely unnecessary risk that anyone could.
It's about essential respect in the open source community. The Mozilla crew could win this argument, partly based on sheer inertia, partly based on beleaguered opponents mounting an ineffectual fight, and partly based on the relative resources.
But they shouldn't. And to anyone who spends any time at all researching the issue, the Mozilla group is clearly engaging in "friendly fire."
I deeply respect both of these projects. It's time for both sides to raise the bar on what it means to fight for a common cause.
This sub uses a conventional ballast system below what it calls its "stall speed," but what you say isn't necessarily so for other subs that use a "no ballast" design. Think of the inverse of moveable props like those used on VTOL aircraft. You can use propellers pointing up to counter the bouyancy.
One really good reason for not having ballast - if you lose all electrical power, you float to the surface. Think about it.
Baudtender
Ummm... these folks better get legal advice pronto
on
Linux-Based Bar-Monkey
·
· Score: 1
Gee, hate to spoil these folks good time, and a darned impressive hack, but...
Now that they've posted it publicly, I bet they'll soon wish they'd spent a little less time calibrating their windshield wiper pumps and a little more time researching their state liquor and health laws.
They accentuated the phrase "at cost" probably because they think that by being a nonprofit enterprise, (or an "everybody chips in and no one's in charge" entity) they fall outside of liquor laws and civil negligence standards.
Dead wrong on both counts, and a lot of people don't believe it and will swear that they "know" differently until someone is up to their ass in lawsuits and criminal charges.
Whether or not it's for-profit, they're dispensing liquor in exchange for money. At the very least this means they'd better have a liquor license to do so. By accepting money, they probably fall under a lot of other laws and regulations that they haven't considered, such as operating hours and record keeping. Having just completed a ServSafe course myself, I suspect a Department Of Health inspector would nearly have a heart attack to find out they're running a foodstuff through windshield wiper pumps and other tubing and parts that are neither food-grade nor NSF certified.
Since California has a Dram Shop law, the people who put alcohol into the machine assume lots of liability if someone drinks from their machine to a point of intoxication and then goes out and injures themself or someone else. Putting a robot in charge does not excuse them from negligence. I'll bet they think that if a "customer" gets drunk using their machine, or supplies booze from their machine to a minor, it's the "customer's" fault and responsibility. Boy, are they in for an awakening. One or more people are putting booze into the machine, and they'd better wise up to the fact that they are responsible for what happens to the people who consume that booze. I'm wondering if the university is also liable, but I'm sure they'd be interested if it's happening on their property.
But hey, not to worry. Those ABC agents, Health Department inspectors, and sue-happy lawyers are real easy to get along with (guffaw.)
The genetic keyboard layout's author says he doesn't want to go back and re-learn QWERTY.
My observation is that in his attempt to pursue personal efficiency, he has effectively isolated himself from 99+% of the keyboards/layouts in the English speaking world.
The irony is that when this guy leaves the safety of his office, his typing skills are reduced to those of a lowbrow backwoods hunt-and-pecker. That means chicks will laugh at him and won't reproduce with him, which puts him in the penalty box of natural selection. How do you feel about toying with genetics now, Brainiac?
QWERTY isn't popular because it's pretty or efficient, but because of its popularity.
Baudtender
My opinions reflect those of the company I work for, because I own the goddamn company I work for.
Margins? According to Pennsylvania Department of Labor and Industry, better than 3/4's of bars and restaurants that open will be closed within 3 years. Of those that remain, less than 10% will have a profit margin greater than 8% of gross. That markup you see gets eaten up pretty quickly. Besides the product cost, which is typically 25-33%, labor, utilies, rent, advertising, and insurance are huge expenses. Half the price of a bottle of vodka in the U.S. is tax.
Don't forget, there's nothing on that mag-stripe that isn't on the front of the license, and we could just as well do it with an optical scanner and OCR. The potential for abuse has nothing to do with mag-stripe technology, and really comes down to how much of an idiot the owner is. Unlike spammers, we do care about how many people we piss off.
We have the equivalent of a website's "Privacy Statement" - and so should every business that collects customer information for any reason.
We would never send out mailings to folks - can you imagine a wife grilling her husband over getting on a nudie-bar mailing list ("Dear Joe, as one of our frequent customers we thought you'd like this coupon for $5 off the cover charge to see 72DDD porno star Martha Mammaries live on our stage.")
And for the record, we get $2.25 for a domestic beer and $3.75 for an imperial pint (20 U.S. fluid ounces) of Guinness. Also, we sure do have hidden cameras, but they're pointed at the bartenders, booze, and cash registers. It's a tough business.
I own a bar/nightclub and I scan ID's with a magstripe reader and software I wrote. Over the top of a video picture of your face, it displays your name and date of birth and saves the details to an Interbase database as well as the video onto a vcr. If your card is demagnetized or otherwise altered, we simply don't accept it. Bye bye, go drink at home.
Why? Because you may want to be anonymous, but the bar wants to know who you are should you hurt someone else, damage their property, or later try to sue them for some behaviour that resulted from your drinking. All of the above happen quite frequently in our business, and there are no end to lawyers lining up to sue us.
We had some idiot pop off a "happy new year" pistol shot in the air a few months back in an empty parking lot after being escorted out for groping a cocktail waitress, and once the rumors got around town, it really hurt our business (the rumors are always better than the facts, and this sort of thing can happen in any parking lot.)
Now that we have this system set up and people see it coming in, they feel much safer about relaxing here because the idiots and criminals want no part of this place. I should also mention that we have a "blacklist" field in each database record, which is indexed on your drivers license ID #. I set this flag and you won't get past the doorman, no matter how much you change your appearance, how many months later you come back, or how many doormen we've gone through in the meantime.
The last thing I would care about is tracking your drinking habits - if you go to a bar more than once, a good bartender already knows what you drink, how much, and most probably a helluva lot more about you than you'd ever guess. We in this business spend a helluva lot more time worrying about the shysters, con-artists, and violent drunks. While I wish that we didn't have to do this (I'd much rather have the server being used for more net browsers on the bar) it's a helluva lot more preferable to the lengths that some clubs have chosen to go.
Trust me - a bar is a lot like a boat. Both seem like they would be a lot of fun to own, but you're a lot better off enjoying someone else's.
>How about blob fields ? If you use blobs then you obviously have some kind of large binary object to store, and then 64 KB seems kinda short for it.
Indeed it would - Interbase/Firebird only stores 32-bit Blob references in the actual record, the data itself is stored externally as a number of chained segments, the total of which can be just under 32 gigabytes in length.
First of all, this isn't an official part of
Linux, it's just some fellow doing it as a
goof to satisfy his buddy. He does some
very minimal theme support and releases it
into user-land under GPL in case someone
else might get a kick out of it. Isn't the
ability to do _that_ part of the beauty of
Linux?
Along with the "eyecandy" afficionados, I
think the main branch of folks who will
be appreciative of this would be the
embedded-Linux developers. There is quite
a push towards bringing Linux into things
like kiosks and consumer devices, and the
coders would very much need to customize
and "prettyfy" the boot process in order
to sell Linux to the suits (well, that and
fast-boot journaling filesystems like
reiserfs.)
I wasn't talking about mirroring in the RAID
sense, nor do I think that RAID is a good
backup solution due to the physical catastrophes
that can happen to a site - fire, flood, theft,
etc. When you take a mirrored RAID drive offline,
you lose synch and destroy the whole driving
principal behind it.
Just use the second hard drive just as you would
a tape drive, and then take it offline and into
safe storage at the conclusion of each backup.
Most backup software will talk to an IDE drive
just fine and treat it just as if it were a
(really really fast) tape drive.
My point of using a third or fourth drive for
incremental backups directly addresses your
"oops" concern. Or, if you're using a 10GB
hard drive and your backup drive is 40GB, you
can simply partitiion the 40GB and do rotation
backups to the same physical drive.
It really is no trouble at all transporting an
IDE drive once it's protected in a mobile tray.
Heavier and more fragile than a tape cartridge,
I'll grant you, but it's a small price to pay
for the relative benefits.
The real drawbacks to my scheme are that unless
you're using a special IDE controller and drive,
hot-swapping is a REAL bad idea. The system
must be shut down to insert or remove the
backup IDE drive. So perhaps a hot-swap SCSI
drive would be more appropriate for a 24X7
critical system. Secondly, doing this on a
Windows system requires extra care, due to
their goofy drive-letter reassignment methods.
I really can't think of any other drawbacks, but
I'd sure like to hear them if anyone else can.
I think that tape drives are a technology that
deserves to go the way of the punch card. While
everyone talks about the speed of backing up
on such devices, the amount of time that it takes
to restore from one is rarely mentioned.
And for good reason - on many of these devices,
doing a full restore of 5GB or more after a
drive death will have you scratching your butt
for days (yes, that's plural) waiting for the
damn thing to finish. While it's better than no
restore at all, I don't think many people
recognize just how long their critical systems
will be down.
In my book, the only mechanism worth using for
backing up a single large IDE drive is another
IDE drive!
With plenty of fast 40GB UDMA-3 drives popping
up on Price Watch for well under $140, I decided
that in the long run it is much more economical
to put in one of those removeable IDE trays and
back up to a second (or incrementally, a third or
fourth when you look at the cost of a 40GB tape
backup device) IDE drive.
>Replication, transactions, row-level locking,
> stored procedures and triggers are NOT
> requirements of a database.
That's a red herring - the whole point of the
discussion is MySQL's claim to be a _relational_
database, which it isn't.
> A few good reasons not to use triggers and
> stored procedures are:
>
> 1) Performance
> 2) Portability
Them ain't a few, them's a couple, and half
of them are wrong. When you use triggers and
stored procedures, you aren't interested in
portability. If portability is an overriding
concern, you'd use ODBC and never use the
server's native API at all. Of course, you'd
do that at the expense of performance, which
brings up the (dead wrong) second point.
Performance is exactly why you use triggers
and stored procedures. When used appropriately,
there isn't any way to gain the performance
enhancements they offer without using them,
unless you like the idea of making all of your
clients also behave as multi-threaded servers.
It doesn't make a bit of difference where the
code is stored, it's where it is executed that
makes a difference in performance. If you
don't grok that, you're missing one of the
main benefits of client/server architecture
versus client file-sharing.
Your column flag work-around for row-level
locking provides a textbook example of how to
slow a database to a crawl. You need to read
a good book on concurrency and deadlocks to
know why you're scheme is disaster bound, e.g.
(one of many) what happens when one of your
clients crash after setting and before
resetting your flag?
Well, the funny thing is that they have
pre-announced these features, and say they
will achieve them by using Berkeley DB as
a sort of wrapper. I believe there's a
version in beta now.
Slashdot Mirror
Pronunciation is the key, you see..
You say 15Mbps
I say TURGID
That must be the least satisfying naked picture I've ever seen.
Don't gloss over this part of the article:
"Asked whether Microsoft is considering integrating the virtual technology into the core Windows kernel, Huffman skirted the issue, saying Microsoft is committed to developing virtualization solutions for the Windows platform. "It's too early to say how we will deliver these solutions going forward," Huffman said."
Consider two different "embrace and extend" compatible strategies: A) add a virtualized sandbox for Linux/BSD/etc. or B) add a Linux compatibility layer to the Windows XP/2000 kernel.
Strategy A also provides them with some added benefits - it solves a whole bunch of security embarassments in one fell swoop and re-opens some markets that are currently starting to close down on them. They could also argue that the virtualization is generic, and therefore they are not directly competing in the Unix market ("we treat Linux as any other third-party app.")
Strategy B boils down to a pissing-match over kernels - I still lock up XP on a several-times-a-week basis, but if they _could_ get a stable and secure kernel (yeah, I know, not holding my breath either), they could effectively co-opt everything in the OSS world for their own benefit without having to worry about "viral" licenses, while still providing a platform for their own proprietary software product line. Of course, they would have to get out of (if they haven't already - did SCO really inherit the Xenix contract?) that pesky committment not to compete in the Unix market.
The best attack for Windows to embrace and extend Linux is to first confuse the two and assimilate what people think of as "Linux" into Windows (or...shudder...vice-versa.)
Projects like WINE have us thinking in one direction - what if Microsoft were to pull the same trick going the other direction? If they can't sell a Microsoft-branded web server, at least they can sell the operating system that you run Apache on top of.
Strategy C scares me the most: Microsoft would have to decide how important their kernel is to their OS sales - THEY could just as easily create a 100% working WINE and sell the Windows "Look & Feel" running on top of Linux or BSD kernel just as MacOS did (except under x86), and re-brand it as a security-solution with cross-platform compatibility benefits (that will cost just about the same price as their own-kerneled OS's, methinks.) You can see how they are pissed-off at the GPL - that's how they get around it and get the open-source volunteers working for them.
I have to hurry and finish this because the Microsoft Death-Beam satellite is due over my home in just a few moments, and I'm running low on tin-foil and........gahhhhhhhhhhhhhhhh!!!
They want $99NZ (approx $42US) for each machine
running Athene in a commercial environment.
Baudtender
Guns don't kill people, Britney Spears music kills people.
Anyone who knows the recent history of how
Interbase became Firebird appreciates just how
wretched and bloody and ugly the final months
were before it became open source. There were
folks fighting tooth and nail to give this
incredible product a fighting chance, and I have
nothing but respect for what they have achieved.
If you spend a couple of hours really, seriously
researching what this product offers, you'll
not only wonder how Borland could mismanage it
as badly as they did, but also wonder why MySQL
and PostgreSQL get so much press without being
mentioned as an afterthought. If only a tenth
of the resources were placed into Firebird as
are placed into PostgreSQL, I seriously wonder
if PostgreSQL wouldn't be largely abandoned
within the next two years.
This is a story about a beat up and exhausted
small group of core supporters coming up with a
name, and then, a year and some months later,
just as they're really starting to get the code
base they inherited under control and figured
out, a much bigger and well known crew picks
that same name. It isn't that the Mozilla team
couldn't keep the Firebird name - it's that they
shouldn't. It isn't that anyone will confuse
a web browser with a RDBMS, it's that it's a
completely unnecessary risk that anyone could.
It's about essential respect in the open source
community. The Mozilla crew could win this
argument, partly based on sheer inertia, partly
based on beleaguered opponents mounting an
ineffectual fight, and partly based on the
relative resources.
But they shouldn't. And to anyone who spends any
time at all researching the issue, the Mozilla
group is clearly engaging in "friendly fire."
I deeply respect both of these projects. It's
time for both sides to raise the bar on what it
means to fight for a common cause.
Baudtender
This sub uses a conventional ballast system below
what it calls its "stall speed," but what you
say isn't necessarily so for other subs that use
a "no ballast" design. Think of the inverse of
moveable props like those used on VTOL aircraft.
You can use propellers pointing up to counter the
bouyancy.
One really good reason for not having ballast -
if you lose all electrical power, you float to
the surface. Think about it.
Baudtender
Gee, hate to spoil these folks good time, and
a darned impressive hack, but...
Now that they've posted it publicly, I bet they'll
soon wish they'd spent a little less time
calibrating their windshield wiper pumps and a
little more time researching their state liquor
and health laws.
They accentuated the phrase "at cost" probably
because they think that by being a nonprofit
enterprise, (or an "everybody chips in and no
one's in charge" entity) they fall outside of
liquor laws and civil negligence standards.
Dead wrong on both counts, and a lot of people
don't believe it and will swear that they "know"
differently until someone is up to their ass in
lawsuits and criminal charges.
Whether or not it's for-profit, they're dispensing
liquor in exchange for money. At the very least
this means they'd better have a liquor license
to do so. By accepting money, they probably fall
under a lot of other laws and regulations that
they haven't considered, such as operating hours
and record keeping. Having just completed a
ServSafe course myself, I suspect a Department Of
Health inspector would nearly have a heart attack
to find out they're running a foodstuff through
windshield wiper pumps and other tubing and
parts that are neither food-grade nor NSF
certified.
Since California has a Dram Shop law, the people
who put alcohol into the machine assume lots of
liability if someone drinks from their machine
to a point of intoxication and then goes out and
injures themself or someone else. Putting a robot
in charge does not excuse them from negligence.
I'll bet they think that if a "customer" gets
drunk using their machine, or supplies booze from
their machine to a minor, it's the "customer's"
fault and responsibility. Boy, are they in for an
awakening. One or more people are putting booze
into the machine, and they'd better wise up to
the fact that they are responsible for what
happens to the people who consume that booze.
I'm wondering if the university is also liable,
but I'm sure they'd be interested if it's
happening on their property.
But hey, not to worry. Those ABC agents, Health
Department inspectors, and sue-happy lawyers are
real easy to get along with (guffaw.)
Baudtender
I looked over the episode guide and there is
clearly no reference to when the Harlem
Globetrotters arrive.
What gives?
No no... he said _scientists_.
Not _Scientologists_.
Until you can type "sardonic" 100 times error free
without using any fingers, you don't get to procreate either.
I mean it, I'm taking names.
Baudtender
The genetic keyboard layout's author says he doesn't want to go back and re-learn QWERTY.
My observation is that in his attempt to pursue personal efficiency, he has effectively isolated himself from 99+% of the keyboards/layouts in the English speaking world.
The irony is that when this guy leaves the safety of his office, his typing skills are reduced to those of a lowbrow backwoods hunt-and-pecker. That means chicks will laugh at him and won't reproduce with him, which puts him in the penalty box of natural selection. How do you feel about toying with genetics now, Brainiac?
QWERTY isn't popular because it's pretty or efficient, but because of its popularity.
Baudtender
My opinions reflect those of the company I work for,
because I own the goddamn company I work for.
Margins? According to Pennsylvania Department of Labor and Industry, better than 3/4's of bars and restaurants that open will be closed within 3 years. Of those that remain, less than 10% will have a profit margin greater than 8% of gross. That markup you see gets eaten up pretty quickly. Besides the product cost, which is typically 25-33%, labor, utilies, rent, advertising, and insurance are huge expenses. Half the price of a bottle of vodka in the U.S. is tax.
Don't forget, there's nothing on that mag-stripe that isn't on the front of the license, and we could just as well do it with an optical scanner and OCR. The potential for abuse has nothing to do with mag-stripe technology, and really comes down to how much of an idiot the owner is. Unlike spammers, we do care about how many people we piss off.
We have the equivalent of a website's "Privacy Statement" - and so should every business that collects customer information for any reason.
We would never send out mailings to folks - can you imagine a wife grilling her husband over getting on a nudie-bar mailing list ("Dear Joe, as one of our frequent customers we thought you'd like this coupon for $5 off the cover charge to see 72DDD porno star Martha Mammaries live on our stage.")
And for the record, we get $2.25 for a domestic beer and $3.75 for an imperial pint (20 U.S. fluid ounces) of Guinness. Also, we sure do have hidden cameras, but they're pointed at the bartenders, booze, and cash registers. It's a tough business.
I own a bar/nightclub and I scan ID's with a magstripe reader and software I wrote. Over the top of a video picture of your face, it displays your name and date of birth and saves the details to an Interbase database as well as the video onto a vcr. If your card is demagnetized or otherwise altered, we simply don't accept it. Bye bye, go drink at home.
Why? Because you may want to be anonymous, but the bar wants to know who you are should you hurt someone else, damage their property, or later try to sue them for some behaviour that resulted from your drinking. All of the above happen quite frequently in our business, and there are no end to lawyers lining up to sue us.
We had some idiot pop off a "happy new year" pistol shot in the air a few months back in an empty parking lot after being escorted out for groping a cocktail waitress, and once the rumors got around town, it really hurt our business (the rumors are always better than the facts, and this sort of thing can happen in any parking lot.)
Now that we have this system set up and people see it coming in, they feel much safer about relaxing here because the idiots and criminals want no part of this place. I should also mention that we have a "blacklist" field in each database record, which is indexed on your drivers license ID #. I set this flag and you won't get past the doorman, no matter how much you change your appearance, how many months later you come back, or how many doormen we've gone through in the meantime.
The last thing I would care about is tracking your drinking habits - if you go to a bar more than once, a good bartender already knows what you drink, how much, and most probably a helluva lot more about you than you'd ever guess. We in this business spend a helluva lot more time worrying about the shysters, con-artists, and violent drunks. While I wish that we didn't have to do this (I'd much rather have the server being used for more net browsers on the bar) it's a helluva lot more preferable to the lengths that some clubs have chosen to go.
Trust me - a bar is a lot like a boat. Both seem like they would be a lot of fun to own, but you're a lot better off enjoying someone else's.
Baudtender
> Good thing it's open... Someone email me the source for it and I'll increase the ridiculous 64K row size limit. ;-)
Have at it!
Firebird:
http://sourceforge.net/projects/firebird/
Interbase:
http://www.borland.com/interbase/
>How about blob fields ? If you use blobs then you obviously have some kind of large binary object to store, and then 64 KB seems kinda short for it.
Indeed it would - Interbase/Firebird only stores 32-bit Blob references in the actual record, the data itself is stored externally as a number of chained segments, the total of which can be just under 32 gigabytes in length.
VARCHAR's have a limit of 32,767 bytes each.
Maximum size of database: 32TB using multiple files; largest recorded InterBase database in production is over 200GB
Maximum size of one file: 4GB on most platforms; 2GB on some platforms
Maximum number of tables: 64K Tables
Maximum size of one table: 32TB
Maximum number of rows per table: 4GB Rows
Maximum row size: 64K
Maximum number of columns per table: Depends on the datatypes you use. (Example: 16,384 INTEGER (4 byte) values per row.)
Maximum number of indexes per table: 64KB indexes
Maximum number of indexes per database: 4G indexes
And don't forget, Interbase/Firebird is absolutely free and open source!
First of all, this isn't an official part of
Linux, it's just some fellow doing it as a
goof to satisfy his buddy. He does some
very minimal theme support and releases it
into user-land under GPL in case someone
else might get a kick out of it. Isn't the
ability to do _that_ part of the beauty of
Linux?
Along with the "eyecandy" afficionados, I
think the main branch of folks who will
be appreciative of this would be the
embedded-Linux developers. There is quite
a push towards bringing Linux into things
like kiosks and consumer devices, and the
coders would very much need to customize
and "prettyfy" the boot process in order
to sell Linux to the suits (well, that and
fast-boot journaling filesystems like
reiserfs.)
It's tiff.
The original Atari Pong used a regular TV sitting
on a shelf behind a bezel.
I wasn't talking about mirroring in the RAID
sense, nor do I think that RAID is a good
backup solution due to the physical catastrophes
that can happen to a site - fire, flood, theft,
etc. When you take a mirrored RAID drive offline,
you lose synch and destroy the whole driving
principal behind it.
Just use the second hard drive just as you would
a tape drive, and then take it offline and into
safe storage at the conclusion of each backup.
Most backup software will talk to an IDE drive
just fine and treat it just as if it were a
(really really fast) tape drive.
My point of using a third or fourth drive for
incremental backups directly addresses your
"oops" concern. Or, if you're using a 10GB
hard drive and your backup drive is 40GB, you
can simply partitiion the 40GB and do rotation
backups to the same physical drive.
It really is no trouble at all transporting an
IDE drive once it's protected in a mobile tray.
Heavier and more fragile than a tape cartridge,
I'll grant you, but it's a small price to pay
for the relative benefits.
The real drawbacks to my scheme are that unless
you're using a special IDE controller and drive,
hot-swapping is a REAL bad idea. The system
must be shut down to insert or remove the
backup IDE drive. So perhaps a hot-swap SCSI
drive would be more appropriate for a 24X7
critical system. Secondly, doing this on a
Windows system requires extra care, due to
their goofy drive-letter reassignment methods.
I really can't think of any other drawbacks, but
I'd sure like to hear them if anyone else can.
I think that tape drives are a technology that deserves to go the way of the punch card. While everyone talks about the speed of backing up on such devices, the amount of time that it takes to restore from one is rarely mentioned. And for good reason - on many of these devices, doing a full restore of 5GB or more after a drive death will have you scratching your butt for days (yes, that's plural) waiting for the damn thing to finish. While it's better than no restore at all, I don't think many people recognize just how long their critical systems will be down. In my book, the only mechanism worth using for backing up a single large IDE drive is another IDE drive! With plenty of fast 40GB UDMA-3 drives popping up on Price Watch for well under $140, I decided that in the long run it is much more economical to put in one of those removeable IDE trays and back up to a second (or incrementally, a third or fourth when you look at the cost of a 40GB tape backup device) IDE drive.
>Replication, transactions, row-level locking,
> stored procedures and triggers are NOT
> requirements of a database.
That's a red herring - the whole point of the
discussion is MySQL's claim to be a _relational_
database, which it isn't.
> A few good reasons not to use triggers and
> stored procedures are:
>
> 1) Performance
> 2) Portability
Them ain't a few, them's a couple, and half
of them are wrong. When you use triggers and
stored procedures, you aren't interested in
portability. If portability is an overriding
concern, you'd use ODBC and never use the
server's native API at all. Of course, you'd
do that at the expense of performance, which
brings up the (dead wrong) second point.
Performance is exactly why you use triggers
and stored procedures. When used appropriately,
there isn't any way to gain the performance
enhancements they offer without using them,
unless you like the idea of making all of your
clients also behave as multi-threaded servers.
It doesn't make a bit of difference where the
code is stored, it's where it is executed that
makes a difference in performance. If you
don't grok that, you're missing one of the
main benefits of client/server architecture
versus client file-sharing.
Your column flag work-around for row-level
locking provides a textbook example of how to
slow a database to a crawl. You need to read
a good book on concurrency and deadlocks to
know why you're scheme is disaster bound, e.g.
(one of many) what happens when one of your
clients crash after setting and before
resetting your flag?
Well, the funny thing is that they have
pre-announced these features, and say they
will achieve them by using Berkeley DB as
a sort of wrapper. I believe there's a
version in beta now.
And we liked it!