Who cares? Here's the difference between the Air Force and all the other branches.
Army: Builds confidence course, firing range, artillery range, maintenance buildings, runs out of money before building barracks, asks for more, sets up tent camps.
Navy (and Marines): Build docks, runways, shops, beautiful commisaries, beautiful officer housing, runs out of money, builds Quanset huts.
Air Force: Builds barracks, chow hall, rec center, bowling lanes, runs out of money, sits on hands until congress gives them the money to build the runways, flightline and shops.
The Air Force is like civilians in uniform.
Lastly, my favorite joke. 99% of all women in the world are beautiful, the other 1% went into the Navy.:-)
No, you only THINK nothing has ever been damaged by it. Over 95% of all ESD damage results in either latent failure or reduced performance (can't handle high clock rates, can't handle heat, can't handle RFI.) NOT total failure.
You've damaged plenty, and so has almost everyone else who thinks that way. You just thought that hard drive or Mobo that died after a couple years wore out, when the real problem was you shortened it's life.
I used to do ESD training in the USAF a long time ago, and here are some examples I remember:
Static Voltages:
Spark big enough to just be seen with the lights out: 1000V
Spark big enough to be seen, heard, but not felt: 2000V
Spark big enough to be felt as well as seen and heard: 3000V+
Average static charge generated by simply losing contact with ground, standing still, not moving etc... ~500V
Average static charge created when you move only 2 to 3 feet after losing contact with ground: ~1000V
- - - - - - - -
In the 1960s when solid state devices were first taking off, and ESD became a serious issue, many companies that made chips started doing post-mortems on blown chips to see what went wrong. The failures of more than 90% of all the chips that they got back were due to ESD, even though most were not immediate catastrophic failures, but shortened life problems. The pictures we had in the AF that we had gotten from contractors were simply amazing. The looked like aireal (sp?) photos of WWII bombing runs on bridges and such. Huge craters that had blown out 95% or so of a run, and the last bit of the run inside the chip finally died from heat.
The secret to ESD protection is the EXACT SAME ONE as the one for making a secure computer. The Process and the training in that process. Nothing else will work.
http://www.dictionary.com/search?q=learnt says it is too. Maybe you should actually check your facts before telling someone they're wrong. Just a thought.
The sad thing is that most of the problems you see with bad user interface are easily fixable, it's just that whoever designed the object your looking at thought that whatever incemental gain you'd gotten was worth the tradeoff.
Another example from the satellite TV issues. I used to have a Dish system. I liked the programming, but in terms of picture quality digital cable and dish are both way worse than old fashioned VHS or SVHS. The blocky compression they use is terrible for things like action movies or anything with a lot of little motion all over.
The remote was slow and dodgy. Push a button, and wait to see if the sat receiver saw it or not. You couldn't just hit up three times and go up three channels. And if you held it down, it would jump 20 channels, then stop for a minute at a time on one you did NOT want to watch.
Another example is this POS Intel server I'm working on. I put in a CDROM drive, forgot to turn off the master setting (on the primary IDE interface) same as the main hard drive it boots from. So the BIOS intelligently changes the boot priority to put the other IDE drives at the top of the list. I fix the problem with the CDROM and the machine won't boot. How am I supposed to know the problem is that my non-booting storage drives are now at the top of the list?
Another example. I'm in the network center at work, and using the "village bicycle" PC that has Sonique on it. What an utter travesty. It's pretty, but absolutely non-obvious by nature. sendmail.cf is easier to edit than this thing is to use. If only had speakers on my server I could just run mpg123. It may run from the command line, but I can figure that thing out.
Another example of things getting worse. I'm using a MS natural keyboard. The 6 at the top of the keyboard is on the wrong damned side. Why??doesn't anyone at Microsoft know how to touch type? I keep hitting the blank spot next to the 7 when I go for the 6.
One of the hidden advantages people don't notice in a multi-disk array is it's ability to handle parallel reads / writes.
My single 40 Gig IDE drive has a sustained xfer rate (according to hdparm -t) of about 20 MByte/sec. My 4x2Gig SCSI 7200RPM drive software RAID-5 array has about an 11 MByte/sec xfer rate (it's pretty old Seagate Barracudas and a 2940 SCSI card).
I use postgresql's pgbench tool, and with only one or two simo connections, the 40 Gig IDE spanks the RAID-5 pretty bad. But somewhere around 10 simo connections, the RAID-5 passes the single disk IDE in performance and never loses to it as the numbers climb. So, when people say RAID-5 performance is abysmal, they often are only looking at its ability to handle one data stream. The real beauty of RAID in general is its ability to spread those accesses out across many platters.
Here are the differences I know of (not that many, I don't use SAPDB, but I have looked it over a bit.)
Postgresql uses MVCC (multi-version concurrency control.) That allows for multiple transactions to run with each viewing the database as an instance in time when the transaction began. Other than Oracle and Postgresql, I don't think any other database uses MVCC.
Row level locking is a win for a data warehouse, with little writes and many reads, but in a heavily updated transactional environment hits a brick wall pretty quick.
The other big difference which not one person has mentioned yet is the license.
Postgresql is BSD style (do what you will) while SAP was released under the GPL.
For some companies this may be an important difference, like if you're building "black box" apps that you sell (think network appliance type stuff)
Judging by how things goes, Innodb seems to become the default recommanded table handlers by MySQL and will probably replace myisam in the long run.
Well, I hope you don't mind paying 1,000 Euro's for a perpetual license to hot backup your innodb tables. And the hot backup tool for postgresql is how much? Nothing, it's included, and it's been hot backup since I started using it on version 6.5.x
That's exactly my point. And that means that you don't write it with stored procedure (especially since PL/SQL is an horrible language to use for this task)
But postgresql supports user written functions in C, as well as supporting Tcl, Perl, and Python as procedural languages. And while business rules may belong to the middle tier, data integrity (not null, primary keys, unique, references, constraint check in, etc... all belong to the database.
In fact, putting those in any layer other than the database layer is probably the worst mistake made in database driven apps today.
So, has anyone done anything like run a script that issues a "select nextval('sequence');" and then a kill -9 mysqld to see if the counter stays incremented? If it stays at the old value but the new value gets committed, then that's the same bug postgresql had but doesn't anymore.
One of the interesting things to try with postgresql is to run a couple dozen transactions and kill -9 the postmaster, or even more severe, hit the big red switch, and then reboot. With journaling file systesm and postgresql's write ahead logs, the whole system if back up in literally minutes. And the transactions that were pending are either all individually committed or none at all.
I've run it on smaller sparc boxen running linux (Sparc 20, ultra 1, 2 etc...) and it seems to be quite stable and fast. Solaris, not so fast.:-)
Just think of it. Postgresql crashes so seldomly (and even then, I've never seen it caused by anything but bad hardware ) that a problem that could show up during a crash took well over a year to show up.
But let me ask the parent of the parent I'm responding to, how does MySQL recover from crashes? Does it have a write ahead log feature? does it use some other method to guarantee data integrity in case of database crash? I'm not being facetious, I don't use MySQL so I don't know.
Actually there are two things that are likely to show up around the 7.3 to 7.4 time frame that look quite useful.
One is time travel, wherein the Write ahead logs will be kept for a pre-determined amount of time, and allow you to basically set the way back machine to last month and look at your database from an historical perspective.
The other feature would also use the WAL method for replication (master - slave to start, master - master later). Basically, by piping the output of the WAL logs to a slave database, you could have replication running in a way that the two databases were EXACTLY identical, down to OIDs and what not. That looks like it may be such an easy win it might just show up overnight so to speak, when one of the developers gets a bug inzee hiney.
But seriously, I'd like to try running it on something like a 16 way USparc with a stack-o hard drives running debian and see how that would work.
I can handle about 600 backends on a machine with 1 Gig of ram and a pair of 10k UScsi drives, but the reponse time if more than a 100 or so are active is just too slow at that point. And it's all I/O bound. The CPUs are still at 50% or more idle.
There are several replication options, by the way, but we haven't had need for them, as we generally have fewer simos that are doing heavier lifting, not many simos doing little work, which is where clustering becomes a necessity.
Actually, postgresql under cygwin is quite fast, except at creating connections, which require a fork(), which in windows means SLOOOW. Once the backend is forked it runs quite well from what I understand.
Running multiple backends can be a problem, but that's more a windows issue than a cygwin issue.
And which part of the SQL-89/SQL-92/SQL-99 standard defines and requires replication?
I'd rather have a rock solid database like postgresql running in a setup with manual failover and nightly backups than a dodgy, can't keep it up server like MSSQL server running on a cluster.
In 3 years of HEAVY postgresql usage we have NEVER had 1 data corruption issue, 1 failure, or even more than a few minutes of down time.
If it wasn't so damned reliable, I'm sure they could get more people to work on the replication packages for it (which, by the way, there is one that now supports master to master replication.)
But of course, to stay on thread here, we're talking about a database distributed with a book so people can learn about SQL, not replication, or drive management, or how to get the frosty cold beverage machine working.
The other option, of course, is to put the motherboard into these cool ass funky things called "anti-static" bags. Amazingly, almost every motherboard ships in one, and they're quite easy to pick up at most local beige box shops.
The most bothersome thing to me about the MS Natural keyboards (besides their somewhat squshy feel) is that they put the 6 on the left, when it belongs on the right side of the top row. As a touch typist it was the primary reason I bought my own keyboard to bring into work, the cheapie US Logic that ChumpUSA resells as its own brand. $35 is a pretty good price, and I've got two that are now about 2 years old and they still have nice action. I just need to disable that damned mouse button in the middle of it.:-)
Just go to Radio shack and buy a pair of hemostats. Hemostats are those tiny little pliers like things they use to hold your veins and arteries closed during surgery. They have tiny little thin jaws and a lock back at the handle. Just use those to grab the pin and gently pull it out and straighten it. They work a charm, plus can do double duty as a roach clip... I mean for holding small parts while soldering, yeah, that's it.
BSODs are an issue for Windows and not Unix / Linux primarily because in Unix video / device drivers don't run in the inner ring of the kernel, and can't bring the whole box to it's knees because of a minor bug in a driver or a hardware failure in (what should be) a seconday I/O device.
Windows NT 3.51 had the video drivers (and most other drivers as well) in the outer ring of the kernel where they couldn't down the whole machine, just certain services. I've seen Win3.51 boxes with horribly buggy video drivers just keep right on running when the video would lock up. NT 4.0 and above aren't the same.
The decision to move the drivers into the inner ring of the kernel is why BSODs are a Windows issue. Blaming the user for not setting up his box just right doesn't solve the real issue, poor OS design.
A real OS (unix/linux/OS390/VMS/even NT3.51) doesn't have these problems.
The black plague got it's start due to the witch histeria overrunning Europe at the time. Many people believed that cats were evil animals and witch's familiars etc... and they were killed by the thousands during the 1300s, especially in cities. Farm communities were generally less caught up in the whole witch craze, plus they knew that cats were useful parts of their ecosystems and kept them around.
Slashdot Mirror
Note that dd/mm/yy isn't the British way of doing things, it's the way the whole wide world EXCEPT for the USA does things.
When you compile PHP to use cracklib, you have to use the switch
:-)
--with-crack
Now my server runs real fast for a few days one end, then goes to sleep for 24 hours...
RE: No guaranteed school in the Air Force
:-)
Who cares? Here's the difference between the Air Force and all the other branches.
Army: Builds confidence course, firing range, artillery range, maintenance buildings, runs out of money before building barracks, asks for more, sets up tent camps.
Navy (and Marines): Build docks, runways, shops, beautiful commisaries, beautiful officer housing, runs out of money, builds Quanset huts.
Air Force: Builds barracks, chow hall, rec center, bowling lanes, runs out of money, sits on hands until congress gives them the money to build the runways, flightline and shops.
The Air Force is like civilians in uniform.
Lastly, my favorite joke. 99% of all women in the world are beautiful, the other 1% went into the Navy.
No, you only THINK nothing has ever been damaged by it. Over 95% of all ESD damage results in either latent failure or reduced performance (can't handle high clock rates, can't handle heat, can't handle RFI.) NOT total failure.
You've damaged plenty, and so has almost everyone else who thinks that way. You just thought that hard drive or Mobo that died after a couple years wore out, when the real problem was you shortened it's life.
I used to do ESD training in the USAF a long time ago, and here are some examples I remember:
Static Voltages:
Spark big enough to just be seen with the lights out: 1000V
Spark big enough to be seen, heard, but not felt: 2000V
Spark big enough to be felt as well as seen and heard: 3000V+
Average static charge generated by simply losing contact with ground, standing still, not moving etc... ~500V
Average static charge created when you move only 2 to 3 feet after losing contact with ground: ~1000V
- - - - - - - -
In the 1960s when solid state devices were first taking off, and ESD became a serious issue, many companies that made chips started doing post-mortems on blown chips to see what went wrong. The failures of more than 90% of all the chips that they got back were due to ESD, even though most were not immediate catastrophic failures, but shortened life problems. The pictures we had in the AF that we had gotten from contractors were simply amazing. The looked like aireal (sp?) photos of WWII bombing runs on bridges and such. Huge craters that had blown out 95% or so of a run, and the last bit of the run inside the chip finally died from heat.
The secret to ESD protection is the EXACT SAME ONE as the one for making a secure computer. The Process and the training in that process. Nothing else will work.
Really? How come my dictionary says it is?
http://www.dictionary.com/search?q=learnt says it is too. Maybe you should actually check your facts before telling someone they're wrong. Just a thought.
The sad thing is that most of the problems you see with bad user interface are easily fixable, it's just that whoever designed the object your looking at thought that whatever incemental gain you'd gotten was worth the tradeoff.
Another example from the satellite TV issues. I used to have a Dish system. I liked the programming, but in terms of picture quality digital cable and dish are both way worse than old fashioned VHS or SVHS. The blocky compression they use is terrible for things like action movies or anything with a lot of little motion all over.
The remote was slow and dodgy. Push a button, and wait to see if the sat receiver saw it or not. You couldn't just hit up three times and go up three channels. And if you held it down, it would jump 20 channels, then stop for a minute at a time on one you did NOT want to watch.
Another example is this POS Intel server I'm working on. I put in a CDROM drive, forgot to turn off the master setting (on the primary IDE interface) same as the main hard drive it boots from. So the BIOS intelligently changes the boot priority to put the other IDE drives at the top of the list. I fix the problem with the CDROM and the machine won't boot. How am I supposed to know the problem is that my non-booting storage drives are now at the top of the list?
Freeping Creaturitus...
Another example. I'm in the network center at work, and using the "village bicycle" PC that has Sonique on it. What an utter travesty. It's pretty, but absolutely non-obvious by nature. sendmail.cf is easier to edit than this thing is to use. If only had speakers on my server I could just run mpg123. It may run from the command line, but I can figure that thing out.
Another example of things getting worse. I'm using a MS natural keyboard. The 6 at the top of the keyboard is on the wrong damned side. Why??doesn't anyone at Microsoft know how to touch type? I keep hitting the blank spot next to the 7 when I go for the 6.
One of the hidden advantages people don't notice in a multi-disk array is it's ability to handle parallel reads / writes.
My single 40 Gig IDE drive has a sustained xfer rate (according to hdparm -t) of about 20 MByte/sec. My 4x2Gig SCSI 7200RPM drive software RAID-5 array has about an 11 MByte/sec xfer rate (it's pretty old Seagate Barracudas and a 2940 SCSI card).
I use postgresql's pgbench tool, and with only one or two simo connections, the 40 Gig IDE spanks the RAID-5 pretty bad. But somewhere around 10 simo connections, the RAID-5 passes the single disk IDE in performance and never loses to it as the numbers climb.
So, when people say RAID-5 performance is abysmal, they often are only looking at its ability to handle one data stream. The real beauty of RAID in general is its ability to spread those accesses out across many platters.
Here are the differences I know of (not that many, I don't use SAPDB, but I have looked it over a bit.)
Postgresql uses MVCC (multi-version concurrency control.) That allows for multiple transactions to run with each viewing the database as an instance in time when the transaction began. Other than Oracle and Postgresql, I don't think any other database uses MVCC.
Row level locking is a win for a data warehouse, with little writes and many reads, but in a heavily updated transactional environment hits a brick wall pretty quick.
The other big difference which not one person has mentioned yet is the license.
Postgresql is BSD style (do what you will) while SAP was released under the GPL.
For some companies this may be an important difference, like if you're building "black box" apps that you sell (think network appliance type stuff)
In fact, putting those in any layer other than the database layer is probably the worst mistake made in database driven apps today.
So, has anyone done anything like run a script that issues a "select nextval('sequence');" and then a kill -9 mysqld to see if the counter stays incremented? If it stays at the old value but the new value gets committed, then that's the same bug postgresql had but doesn't anymore.
:-)
One of the interesting things to try with postgresql is to run a couple dozen transactions and kill -9 the postmaster, or even more severe, hit the big red switch, and then reboot. With journaling file systesm and postgresql's write ahead logs, the whole system if back up in literally minutes. And the transactions that were pending are either all individually committed or none at all.
I've run it on smaller sparc boxen running linux (Sparc 20, ultra 1, 2 etc...) and it seems to be quite stable and fast. Solaris, not so fast.
Just think of it. Postgresql crashes so seldomly (and even then, I've never seen it caused by anything but bad hardware ) that a problem that could show up during a crash took well over a year to show up.
But let me ask the parent of the parent I'm responding to, how does MySQL recover from crashes? Does it have a write ahead log feature? does it use some other method to guarantee data integrity in case of database crash? I'm not being facetious, I don't use MySQL so I don't know.
Actually there are two things that are likely to show up around the 7.3 to 7.4 time frame that look quite useful.
One is time travel, wherein the Write ahead logs will be kept for a pre-determined amount of time, and allow you to basically set the way back machine to last month and look at your database from an historical perspective.
The other feature would also use the WAL method for replication (master - slave to start, master - master later). Basically, by piping the output of the WAL logs to a slave database, you could have replication running in a way that the two databases were EXACTLY identical, down to OIDs and what not. That looks like it may be such an easy win it might just show up overnight so to speak, when one of the developers gets a bug inzee hiney.
Like everyone else, we use oracle.
But seriously, I'd like to try running it on something like a 16 way USparc with a stack-o hard drives running debian and see how that would work.
I can handle about 600 backends on a machine with 1 Gig of ram and a pair of 10k UScsi drives, but the reponse time if more than a 100 or so are active is just too slow at that point. And it's all I/O bound. The CPUs are still at 50% or more idle.
There are several replication options, by the way, but we haven't had need for them, as we generally have fewer simos that are doing heavier lifting, not many simos doing little work, which is where clustering becomes a necessity.
Actually, postgresql under cygwin is quite fast, except at creating connections, which require a fork(), which in windows means SLOOOW. Once the backend is forked it runs quite well from what I understand.
Running multiple backends can be a problem, but that's more a windows issue than a cygwin issue.
And which part of the SQL-89/SQL-92/SQL-99 standard defines and requires replication?
I'd rather have a rock solid database like postgresql running in a setup with manual failover and nightly backups than a dodgy, can't keep it up server like MSSQL server running on a cluster.
In 3 years of HEAVY postgresql usage we have NEVER had 1 data corruption issue, 1 failure, or even more than a few minutes of down time.
If it wasn't so damned reliable, I'm sure they could get more people to work on the replication packages for it (which, by the way, there is one that now supports master to master replication.)
But of course, to stay on thread here, we're talking about a database distributed with a book so people can learn about SQL, not replication, or drive management, or how to get the frosty cold beverage machine working.
For that, Postgresql is an excellent choice.
The other option, of course, is to put the motherboard into these cool ass funky things called "anti-static" bags. Amazingly, almost every motherboard ships in one, and they're quite easy to pick up at most local beige box shops.
Actually, pussy is the shortened form of pusillanimous, a word meaning someone of weak spirit or will, lacking in courage and strength.
It comes from the French I believe.
The most bothersome thing to me about the MS Natural keyboards (besides their somewhat squshy feel) is that they put the 6 on the left, when it belongs on the right side of the top row. As a touch typist it was the primary reason I bought my own keyboard to bring into work, the cheapie US Logic that ChumpUSA resells as its own brand. $35 is a pretty good price, and I've got two that are now about 2 years old and they still have nice action. I just need to disable that damned mouse button in the middle of it. :-)
Just go to Radio shack and buy a pair of hemostats. Hemostats are those tiny little pliers like things they use to hold your veins and arteries closed during surgery. They have tiny little thin jaws and a lock back at the handle. Just use those to grab the pin and gently pull it out and straighten it. They work a charm, plus can do double duty as a roach clip... I mean for holding small parts while soldering, yeah, that's it.
Choosing between Democrat and Republican is like picking your favorite Menendez brother...
BSODs are an issue for Windows and not Unix / Linux primarily because in Unix video / device drivers don't run in the inner ring of the kernel, and can't bring the whole box to it's knees because of a minor bug in a driver or a hardware failure in (what should be) a seconday I/O device.
Windows NT 3.51 had the video drivers (and most other drivers as well) in the outer ring of the kernel where they couldn't down the whole machine, just certain services. I've seen Win3.51 boxes with horribly buggy video drivers just keep right on running when the video would lock up. NT 4.0 and above aren't the same.
The decision to move the drivers into the inner ring of the kernel is why BSODs are a Windows issue. Blaming the user for not setting up his box just right doesn't solve the real issue, poor OS design.
A real OS (unix/linux/OS390/VMS/even NT3.51) doesn't have these problems.
The black plague got it's start due to the witch histeria overrunning Europe at the time. Many people believed that cats were evil animals and witch's familiars etc... and they were killed by the thousands during the 1300s, especially in cities. Farm communities were generally less caught up in the whole witch craze, plus they knew that cats were useful parts of their ecosystems and kept them around.