"Practical PostgreSQL" is from 2002. There are so many things in PostgreSQL that have changed since then, you'd be better off reading a generic database introduction instead of that one now.
I didn't say anything about power; that's your anonymous troll brain making up bullshit so you feel smart. I made a simple observation based on a) ohm's law, and b) what design parameters off the shelf components for audio use target. The chart I referenced shows that dropping impedance and increasing current also increases power in watts. But that only happens if the associated circuit stays within its voltage/current limits.
Oracle is not guaranteed to work. Nothing can be guaranteed to work in software land; that's hard to do. What Oracle can do is say that they'll give you a refund of their high license fee if it doesn't work. And a company offering MySQL or PostgreSQL services can give you that same "guarantee". Want a 1 hour SLA for if you do hit a problem, and a team of developers available to resolve it? My company will sell you that for less than any Oracle license costs.
This is really a trust issue. Your PHB trusts Oracle to continue supporting something if they receive a lot of money. If he doesn't trust any company working with open source databases, that's his right. But saying Oracle provides guarantees in some unique way is FUD talking.
As impedance drops, you have to raise the amount of current delivered to reach the same voltage to the speaker. Referencing this table, getting an 8 ohm speaker to 28V takes 3.5A of current, while it takes 28A at 1 ohm. Since the wall current available is typically 15A, you can't just adjust an 8 ohm amplifier design to work at 1 ohm. There are transistor related reasons that favor lower current designs too. If you want to tap into the cheap audio amplifier designs, which are available in large quantities at low prices, they are much more likely to run into the limitations of the wall current and transistor current handling limits at low impedance.
Most car speakers aim at 2 to 4 ohms instead because that power supply can deliver a lot of current, but the base power supply voltage you're running from is lower: ~12V instead of ~120V.
The most innovative part of Bose's R&D is actually in avoiding warranty returns. Their bandpass woofer design is the best example. That got a lot of bass out of a box in a way that eliminated really low bass from playing. Do that, and now your woofer won't get burned out if you try and play the system too loud. The mechanical structure of the venting is fighting against overload for you.
They do a similar trick on more expensive systems like the 901 models. Those also carefully limit deep bass so that they can build the speaker with lots of small drivers. Since many people don't really want true low bass out of their systems--they just want a ~100Hz thump--the marketplace loves this too. Nobody takes crappy inexpensive drivers and builds a bulletproof system out of them quite as well as Bose.
CAT5 is reasonable as things that are very cheap go. It doesn't sound very good in systems that need to deliver a lot of current. The problem is that the total wire gauge isn't that high. You have 8 conductors, but they're only 24 AWG each. You're better off picking up a 14AWG extension cord from a hardware store and cutting off the connectors. There was even a brief period in audiophile land where this one very thick appliance extension cord from Home Depot was being recommended as better than many expensive commercial speaker cables.
You can use CAT5 for building crossovers on a smaller system. I wouldn't want the wire connecting a large woofer going through it though.
My employer has been using AIX for stability reasons for a long time (since the very early 90s). At the moment neither MySQL nor Postgres guarantee AIX ODBC driver support. Only DB2 (obviously), Oracle and Sybase (IIRC) do that so there you are, another reason on to keep dealing with these companies
If you took any reasonable fraction of your database budget and pushed it toward a PostgreSQL support company, one of us would be happy to support an AIX ODBC driver. The options aren't just free and fully commercial. Smart companies help fund the features they need in order to enable a migration from the commercial databases to a free one.
Oracle has to do a complicated implementation in all cases because of how their rollback logs are structured, which makes certain types of things impossible to reverse without dipping into a record of earlier database states. But Postgres has fully transactional DDL in a way that's even a bit better than how Oracle approaches the problem. When you can rollback from DROP TABLE already, small jobs returning to an earlier state are possible without even dipping into the history.
We would have to dump a lot of disk space into the obvious ways to implement deeper rollback targets in Postgres, and Oracle has surely put a lot of engineering work into making that efficient. The design for Postgres I have in mind would be a disk pig. I know it would work though, because I'm already hacking together business SLA level rollback targets for people--things like "we must be able to recover from any fat finger error made in the last 2 hours in less than 10 minutes". All of the hard pieces needed are already inside of the replication and rollback code, they just need to be reassembled for this goal. There's even a generic background worker infrastructure in Postgres now, which makes it easy to create more schedule driven daemons like the existing background writer or autovacuum worker. Two years ago, even an inefficient Flashback clone would have been impossible for PostgreSQL to reach. Now enough of the internal components needed are there that it's just waiting for someone to pick an initial business goal target and build a UI to reach that one.
I recently benchmarked postgres 9.2.4 on a Dell PowerEdge at Rackspace with a four disk raid 10, a two disk raid 1 for the WAL logs, and 48GB of RAM. It's good up to around 14000 transactions per second until you exceed what fits into RAM. Then it drops off to around 2000. That was the select benchmark with no writes involved.
Note that much of this is tracing the physical limits of the hardware moving pages around memory and/or disk, not usually Postgres itself anymore. I've been tracing this shape of curve for years now. If you don't want the fall-off against larger than RAM workloads to happen so fast, you can use faster storage like SSD to pull that upwards a lot. Just have to make sure the storage supports reliable writes, which means only a few models of SSD--Intel's 320, 710, and DC S3700 models are popular.
In older versions there were a few places where the database would obviously bottleneck internally. As of 9.2, the main one that's left is that trivial statements run by a single client aren't as fast as, say, MySQL. A lot of that is that things like being able to replace operators has some penalty against a naive, unpluggable data type implementation.
Of course you would optimize as much as possible for that workload. But you shouldn't then use those numbers as representative of the database's performance on other tasks. What I'm saying is that the TPC numbers are gamed so hard by commercial vendors that it's not clear they are useful as measures of anything except "how fast does the TPC workload run". And the restrictions on publishing results means no one else can publish anything but those gamed results.
Or you could install Postgres, and if there's a problem you have resources all over the world to help fix them. At all times the quality of the outcome is in your hands. The risk with Oracle that people ignore is what happens when you have a serious problem, and they don't give a fuck. What do you do then? With commercial software, the vendor is an essential part of non-trivial issues. They have you by the short hairs if your server is down. I don't know why people think that situation involves them having any leverage on Oracle.
People who worry more about CYA than getting work done may not like Postgres, because it assumes an active, competent administrator is thinking and making decisions. If you don't have one of them involved, maybe you do need vendor hand-holding.
It doesn't have a slick UI, but you can do the same thing as Flashback on Postgres. You take a base backup of the database and regularly save write-ahead log files. When you need old data, you have to spin up a new database instance, ask it to replay to that point, and then get the data into the original instance. It won't win any design awards, but I recover lost data with this technique all the time.
There are a some ways to force a query plan onto Postgres that works effectively as hints. See my Hinting At PostgreSQL. It's also possible to overide how Postgres runs selectivity functions to get different results. That mechanism is powerful enough that you can do almost everything possible with hints and then some. The problem is that it's too difficult for most to develop their own statistics model just to fix a broken query. When the alternative is sucking on everything Oracle makes hard, I can't understand why people aren't willing to do this the right way sometimes.
Oracle doesn't allow people to publish benchmarks, period. Some trickle out via the audited TPC results. Those are all systems tuned to an extreme degree, including code optimizations for that specific workload that border on cheating
Customers demand backdoors, period. And as long as there are backdoors, there are going to be exploits for them.
Backdoors for service accounts don't have to be trivial to exploit. If you ship a secret backdoor with the sort of simple password protection this one has, you deserve to go out of business over the resulting negligence lawsuits.
There are so many more places that confidential info can leak to that I'm not optimistic about redirecting them all with mount points./tmp and swap are tough, and who knows what your applications might be saving to your home directory as well. I find it hard to trust anything besides full-disk encryption solutions because of all that.
A lot of Linux systems leave the/boot partition unencrypted. That is reasonable enough, since user data is never going there. Even that is still vulnerable to evil maid attacks, but that's a different issue than the laptop being stolen.
GPS signals require line of site to multiple satellites, making it ineffective a lot of the time for an indoor computer. LoJack uses their own radio signals to operate, and that signal only goes a few miles. The only reason that works is because they've gotten receivers into a large number of police cars. Even there, it doesn't work in many areas of the US, their Wikipedia page has an unreferenced claim of only 27 states. Presumably rural ones where the police density drops won't work.
If your Linux laptop is stolen, odds are good at some point the system will be reformatted with Windows to try and make it "work" again. That's the premise behind why Computrace might be useful even there.
If you encrypt the boot drive properly, it won't boot to anywhere useful without a password. That means you can't use any of the OS-level tracking solutions, because the thief won't be able to boot into the regular OS. If you've let a criminal boot far enough to track them properly, you've really let them get too close to your data.
It sucks in a way that a locked down system can't also phone home easily to find the thief, but realistically that's the trade-off here. I'm willing to write off the cost of a laptop if it's stolen, as long as the thief doesn't also get access to any personal data I have on the drive. Recovering from a case of identity theft costs a lot more than any single device.
Altering BerkleyDB has nothing to do with this. The existing Sleepycat license has always said that compiling against their libraries and distributing the result requires that you either release your application as open source, or buy a commercial license. You can't assume it acts like a GPL or BSD license, it's really aggressive in its own unique way. This is not Oracle taking a regular open-source product and giving it a restrictive commercial license. BerkleyDB always had such a commercial license clause. The change Oracle is making is mainly about closing the loophole where you could avoid even compiling against the database by building a SAAS interface to it.
Slashdot Mirror
"Practical PostgreSQL" is from 2002. There are so many things in PostgreSQL that have changed since then, you'd be better off reading a generic database introduction instead of that one now.
I didn't say anything about power; that's your anonymous troll brain making up bullshit so you feel smart. I made a simple observation based on a) ohm's law, and b) what design parameters off the shelf components for audio use target. The chart I referenced shows that dropping impedance and increasing current also increases power in watts. But that only happens if the associated circuit stays within its voltage/current limits.
Oracle is not guaranteed to work. Nothing can be guaranteed to work in software land; that's hard to do. What Oracle can do is say that they'll give you a refund of their high license fee if it doesn't work. And a company offering MySQL or PostgreSQL services can give you that same "guarantee". Want a 1 hour SLA for if you do hit a problem, and a team of developers available to resolve it? My company will sell you that for less than any Oracle license costs.
This is really a trust issue. Your PHB trusts Oracle to continue supporting something if they receive a lot of money. If he doesn't trust any company working with open source databases, that's his right. But saying Oracle provides guarantees in some unique way is FUD talking.
I don't know how they can feel so cheap yet cost so much.
That, my friend, is what Bose R&D is all about.
As impedance drops, you have to raise the amount of current delivered to reach the same voltage to the speaker. Referencing this table, getting an 8 ohm speaker to 28V takes 3.5A of current, while it takes 28A at 1 ohm. Since the wall current available is typically 15A, you can't just adjust an 8 ohm amplifier design to work at 1 ohm. There are transistor related reasons that favor lower current designs too. If you want to tap into the cheap audio amplifier designs, which are available in large quantities at low prices, they are much more likely to run into the limitations of the wall current and transistor current handling limits at low impedance.
Most car speakers aim at 2 to 4 ohms instead because that power supply can deliver a lot of current, but the base power supply voltage you're running from is lower: ~12V instead of ~120V.
The most innovative part of Bose's R&D is actually in avoiding warranty returns. Their bandpass woofer design is the best example. That got a lot of bass out of a box in a way that eliminated really low bass from playing. Do that, and now your woofer won't get burned out if you try and play the system too loud. The mechanical structure of the venting is fighting against overload for you.
They do a similar trick on more expensive systems like the 901 models. Those also carefully limit deep bass so that they can build the speaker with lots of small drivers. Since many people don't really want true low bass out of their systems--they just want a ~100Hz thump--the marketplace loves this too. Nobody takes crappy inexpensive drivers and builds a bulletproof system out of them quite as well as Bose.
CAT5 is reasonable as things that are very cheap go. It doesn't sound very good in systems that need to deliver a lot of current. The problem is that the total wire gauge isn't that high. You have 8 conductors, but they're only 24 AWG each. You're better off picking up a 14AWG extension cord from a hardware store and cutting off the connectors. There was even a brief period in audiophile land where this one very thick appliance extension cord from Home Depot was being recommended as better than many expensive commercial speaker cables.
You can use CAT5 for building crossovers on a smaller system. I wouldn't want the wire connecting a large woofer going through it though.
My employer has been using AIX for stability reasons for a long time (since the very early 90s). At the moment neither MySQL nor Postgres guarantee AIX ODBC driver support. Only DB2 (obviously), Oracle and Sybase (IIRC) do that so there you are, another reason on to keep dealing with these companies
If you took any reasonable fraction of your database budget and pushed it toward a PostgreSQL support company, one of us would be happy to support an AIX ODBC driver. The options aren't just free and fully commercial. Smart companies help fund the features they need in order to enable a migration from the commercial databases to a free one.
Oracle has to do a complicated implementation in all cases because of how their rollback logs are structured, which makes certain types of things impossible to reverse without dipping into a record of earlier database states. But Postgres has fully transactional DDL in a way that's even a bit better than how Oracle approaches the problem. When you can rollback from DROP TABLE already, small jobs returning to an earlier state are possible without even dipping into the history.
We would have to dump a lot of disk space into the obvious ways to implement deeper rollback targets in Postgres, and Oracle has surely put a lot of engineering work into making that efficient. The design for Postgres I have in mind would be a disk pig. I know it would work though, because I'm already hacking together business SLA level rollback targets for people--things like "we must be able to recover from any fat finger error made in the last 2 hours in less than 10 minutes". All of the hard pieces needed are already inside of the replication and rollback code, they just need to be reassembled for this goal. There's even a generic background worker infrastructure in Postgres now, which makes it easy to create more schedule driven daemons like the existing background writer or autovacuum worker. Two years ago, even an inefficient Flashback clone would have been impossible for PostgreSQL to reach. Now enough of the internal components needed are there that it's just waiting for someone to pick an initial business goal target and build a UI to reach that one.
I recently benchmarked postgres 9.2.4 on a Dell PowerEdge at Rackspace with a four disk raid 10, a two disk raid 1 for the WAL logs, and 48GB of RAM. It's good up to around 14000 transactions per second until you exceed what fits into RAM. Then it drops off to around 2000. That was the select benchmark with no writes involved.
Note that much of this is tracing the physical limits of the hardware moving pages around memory and/or disk, not usually Postgres itself anymore. I've been tracing this shape of curve for years now. If you don't want the fall-off against larger than RAM workloads to happen so fast, you can use faster storage like SSD to pull that upwards a lot. Just have to make sure the storage supports reliable writes, which means only a few models of SSD--Intel's 320, 710, and DC S3700 models are popular.
In older versions there were a few places where the database would obviously bottleneck internally. As of 9.2, the main one that's left is that trivial statements run by a single client aren't as fast as, say, MySQL. A lot of that is that things like being able to replace operators has some penalty against a naive, unpluggable data type implementation.
Whatever. If you paid me as much as an Oracle license costs, I could wrap the Postgres one with a service guarantee too.
Of course you would optimize as much as possible for that workload. But you shouldn't then use those numbers as representative of the database's performance on other tasks. What I'm saying is that the TPC numbers are gamed so hard by commercial vendors that it's not clear they are useful as measures of anything except "how fast does the TPC workload run". And the restrictions on publishing results means no one else can publish anything but those gamed results.
Or you could install Postgres, and if there's a problem you have resources all over the world to help fix them. At all times the quality of the outcome is in your hands. The risk with Oracle that people ignore is what happens when you have a serious problem, and they don't give a fuck. What do you do then? With commercial software, the vendor is an essential part of non-trivial issues. They have you by the short hairs if your server is down. I don't know why people think that situation involves them having any leverage on Oracle.
People who worry more about CYA than getting work done may not like Postgres, because it assumes an active, competent administrator is thinking and making decisions. If you don't have one of them involved, maybe you do need vendor hand-holding.
It doesn't have a slick UI, but you can do the same thing as Flashback on Postgres. You take a base backup of the database and regularly save write-ahead log files. When you need old data, you have to spin up a new database instance, ask it to replay to that point, and then get the data into the original instance. It won't win any design awards, but I recover lost data with this technique all the time.
There are a some ways to force a query plan onto Postgres that works effectively as hints. See my Hinting At PostgreSQL. It's also possible to overide how Postgres runs selectivity functions to get different results. That mechanism is powerful enough that you can do almost everything possible with hints and then some. The problem is that it's too difficult for most to develop their own statistics model just to fix a broken query. When the alternative is sucking on everything Oracle makes hard, I can't understand why people aren't willing to do this the right way sometimes.
Oracle doesn't allow people to publish benchmarks, period. Some trickle out via the audited TPC results. Those are all systems tuned to an extreme degree, including code optimizations for that specific workload that border on cheating
Customers demand backdoors, period. And as long as there are backdoors, there are going to be exploits for them.
Backdoors for service accounts don't have to be trivial to exploit. If you ship a secret backdoor with the sort of simple password protection this one has, you deserve to go out of business over the resulting negligence lawsuits.
You've got it backwards. The computer abuse laws are for jailing the evil hackers who published the information.
There are so many more places that confidential info can leak to that I'm not optimistic about redirecting them all with mount points. /tmp and swap are tough, and who knows what your applications might be saving to your home directory as well. I find it hard to trust anything besides full-disk encryption solutions because of all that.
A lot of Linux systems leave the /boot partition unencrypted. That is reasonable enough, since user data is never going there. Even that is still vulnerable to evil maid attacks, but that's a different issue than the laptop being stolen.
GPS signals require line of site to multiple satellites, making it ineffective a lot of the time for an indoor computer. LoJack uses their own radio signals to operate, and that signal only goes a few miles. The only reason that works is because they've gotten receivers into a large number of police cars. Even there, it doesn't work in many areas of the US, their Wikipedia page has an unreferenced claim of only 27 states. Presumably rural ones where the police density drops won't work.
If your Linux laptop is stolen, odds are good at some point the system will be reformatted with Windows to try and make it "work" again. That's the premise behind why Computrace might be useful even there.
There's a list of where BIOS level Computrace is available on their BIOS compatibility page.
If you encrypt the boot drive properly, it won't boot to anywhere useful without a password. That means you can't use any of the OS-level tracking solutions, because the thief won't be able to boot into the regular OS. If you've let a criminal boot far enough to track them properly, you've really let them get too close to your data.
It sucks in a way that a locked down system can't also phone home easily to find the thief, but realistically that's the trade-off here. I'm willing to write off the cost of a laptop if it's stolen, as long as the thief doesn't also get access to any personal data I have on the drive. Recovering from a case of identity theft costs a lot more than any single device.
I'm reminded of the old joke about Clinton wishing for peace in the middle east.
Altering BerkleyDB has nothing to do with this. The existing Sleepycat license has always said that compiling against their libraries and distributing the result requires that you either release your application as open source, or buy a commercial license. You can't assume it acts like a GPL or BSD license, it's really aggressive in its own unique way. This is not Oracle taking a regular open-source product and giving it a restrictive commercial license. BerkleyDB always had such a commercial license clause. The change Oracle is making is mainly about closing the loophole where you could avoid even compiling against the database by building a SAAS interface to it.