I have to say I don't understand your logic there. So you want people who struggled with the core CS material, and just barely managed to graduate by working harder than average over the people who were good enough to be able to skate through? I understand that you want someone who is willing to work hard for the company, but you want that hard work to actually produce something too. There are far too many people out there with CS degrees that can't keep up. I'd rather have the one who slacked off a bit in college because the coursework was too easy and boring to them, than five people who struggled but worked hard to get a degree. As for the original post, in my experience, both personally and from conversations with other companies' hiring managers, after you have worked for 2-3 years beyond graduation, your grades mean nothing.
As for the rest of your post, you are correct that there is often a huge difference between working for a large company versus a small company. I have worked in both, and you're right, it is nice to have the flexibility (and power) of working at a smaller company, as it keeps things interesting, but the hours and budget can be frustrating (long hours, smaller/no budget for your projects). At a large company, it is just the opposite, it is no longer *my* department (though the management is very responsive to good ideas), but I don't get wake-up calls from users at 3 AM anymore, can actually take a vacation, and the department has a much larger budget. With the small company, design decisions often came down to "What do we already have that we can use for this?" for things like which database system to use, where with the larger company I'm at now, the question is "Which product is the best for what we need?" and if we don't have it, we buy it. A purchase that would have been more than my annual budget for the entire IT department at the small company is taken care of with a 20 minute meeting. Plus, salary negotiations are easier when your salary is less than a percent of the company's income.
Exactly, as an employer looking to hire people as programmers (which would be the majority of the jobs looking for CS degrees), you now have people with a degree that means nothing. There are very few positions (professors, researchers) where theory is more important than actually being able to write code. I say we should go in the completely opposite direction, with more architecture and programming classes (using architecture to have people actually understand what they are doing, and why a certain code block is efficient/inefficient on the hardware it is running on), and only one or two survey courses on algorithms and theory, with more available as electives. CS should be an Engineering degree, as it is in my school (UCF), not a liberal arts degree. I don't see many women in Mechanical, Aerospace, Electrical, or Computer Engineering either, should we stop building cars, satellites, and circuits too? Of course, 28% seems extremely high to me, as my experience has been that there are far less than that in my classes, at least in the later stages (1 each in my senior/grad classes).
I wonder if ATM would count, as ATM networks could be considered "computer networks", and Packet-Switched voice over ATM is essentially like VoIP, just VoATM. This would probably mean that another (older) patent would protect it, one that might already have expired.
This is not a performance issue. The only "performance" difference here is that with VT, you can run Windows under Xen. Without VT, you cannot, but can still run kernels (Linux/BSD/etc.) which are built to run on the Xen hypervisor. The OP wanted to use it to run Windows and Linux/BSD/etc. under Xen. As Virtual PC and VMWare both do full virtualization, VT will not make a difference, but with Xen's (faster) paravirtualization (which requires cooperation between the VMM and the guest OS), it means that VT can keep Windows in its own domain, so that interrupts and syscalls don't interfere with the hypervisor and other guest OS(s).
Enabling VT is a huge security risk with no benefit for most of HP's customers. You probably should be able to turn it on, but having it on leaves open the possibility that a rootkit could be installed as the hypervisor/VMM/whatever, making it undetectable to the OS. Even having the option seems dangerous, as many "power users" will probably enable everything in the BIOS they can, regardless of risk/reward. On second thought, there are probably only a few hundred people that would run Xen on their laptop, so why have the "bug" available on the other few hundred thousand laptops? I suspect there may be many legal reasons why it is disabled by default, whether or not disabling the option to turn it on was intentional or not.
If that were the only concern they had, they would be using Sun's Niagara line. They wanted to compete with the brand recognition/performance reputation (accurate or not) that Intel had, and the only way they saw to do this was to use Intel's chips. Personally, I would much rather have seen them use AMD or even Sun's Niagara (which is actually made by TI), and think that would have paid off even better, as the Mac Server G5 was used in many cases where it's I/O and memory performance put it ahead of Intel products, not it's clock speed.
Doing the switch while maintaining Windows clients can be done easily by replacing the login handlers in windows with something like pGina. Posix ACLs are fairly mature, and work quite well in Linux, and of course are fully mature in Solaris, if you decided to go that route (which might be worth it for zfs, if there is a large enough set of user files). Of course, the major reason why I said the migration is not likely to be difficult is because we are talking about a small business, not a 100+ user migration. Also, the whole idea (at least my take) is to not have the headaches associated with running an AD domain, so one would hope that it would not be identical to Windows. Realistically, though, in a small business there is likely to be only two or three groups of users (managers and everyone else, maybe legal), and ACLs are probably overkill. Samba with LDAP becomes almost trivial (aside from the 20 different ways to set up Samba, according to 20 different setup guides) once you remove AD and winbind from the equation.
Look at your costs before migrating to Linux clients for RDP. Terminal Services Licenses cost nearly as much as a full XP license, so you will likely spend more to do it this way. Having said that, you might be able to run your critical apps under WINE, and use Linux X clients to run it via SSH. I would definitely focus on the servers first though. Check out the O'Reilly books for LDAP and "Linux in a Windows World" for guidance, but it really depends on how many people need to use those critical windows apps, and what apps they are. Let me know what type of apps you are talking about, as there may be replacements or documented WINE support for them. AD to LDAP isn't likely to be much trouble with only a few users, and any mail, file, and print services should be relatively simple to implement, whether you convert or use winbind to maintain AD integration. Having been on both sides, though, I would definitely prefer switching to LDAP first, as AD can give you plenty of headaches down the road. Also, regardless of which path you take, be sure to make use of NTP to maintain your clocks, since a small drift will eventually wreak havoc on anything using kerberos, and it might not be the first thing that comes to mind when something suddenly stops working.
...or just simple shared hosting, hostdime (hostdime.com) is also an excellent choice for either, and they offer horde and squirrelmail for webmail too.
The audit DB (for all application transactions [healthcare industry]) was a single Opteron 240 with a 12 drive SATA RAID and 4GB RAM. As the DB was mostly used for inserts and a few employee productivity or records research reports, the CPU load rarely topped 3%.
That was exactly my point. 16M rows is not a "large" table. Maybe 10 years ago that would be a lot for common hardware, but I would imagine that most Mid-size companies see 16M+ rows as a common thing. We only had 10 years of live data, and only about 90 employees. I'm sure there are much larger databases than ours was.
Agreed. I live in Florida, and can tell you, the Michigan drivers (that visit here) are the worst, with the Quebecois a close second. Seriously, though, the US needs to work on driver safety through education, not ticketing. Look at Germany, with no speed limits on most major roads, and with an expensive and lengthy licensing process [that never expires, but you can lose it], they have almost half the fatality rate per driver.
Definitely not impossible. Mounting a few solid-state accelerometers on these glasses could create some interesting visualization and gaming possibilities. Not exactly CREOL's area, but he could probably talk to one of the simulation guys. Drs. Workman and Hughes come to mind, and maybe Lobo with the addition of a camera for robot-vision applications (like vision enhancement). Could be some interesting applications of this, and nice to see my school on the front page.
Just to add to this, applying a hand to lower-forearm gauntlet-style cast is reimbursed by Medicare in the US at $65.20, with plaster cast supplies reimbursed at $12.61, and fiberglass at $21.29. HMO's typically pay around 80% (based on lab codes, I don't have experience with hospital and physician codes) of Medicare rates, with Medicaid rounding out the bottom at about 60%. Fiberglass pre-preg casting material costs about 2-3 times as much as plaster, so there is a small argument there, although it would typically require less material. The difference isn't likely to matter much, so you're probably right, although the OP isn't likely to make much for the time to set the cast (and arguably it is probably not worth a physician's time, nurses or assistants are much cheaper), he isn't likely to be losing money on the supplies (with the possible exception of Medicaid), unless a more substantial cast is required, in which case a more substantial procedure code might be appropriate.
Just for reference, a 3" x 4yd roll of fiberglass pre-preg is a little under $200, while a 3" x 5yd roll of plaster material is about $80, and both would use a little bit of wrap underneath (not significant). I can certainly attest that payment rates for some procedures are rediculously low (drawing blood for laboratory work being one where you are virtually guaranteed to lose money, due to safety regulations [disposable safety needles and hubs], tubes, guaze, tape, etc. and labor costs, all for a $3 reimbursment from Medicare, or NOTHING from Medicaid and most insurance companies [after all, you should just be able to get specimens magically]), these shortfalls often can be made up in other areas (like the actual tests on those specimens). It is possible to make a profit doing health care work, but you have to be selective in which clients you take, which leaves a lot of people out in the cold. If I were a doctor, I wouldn't want to service an area full of Medicaid patients, because I would probably struggle to pay my rent, let alone eat. But if you take a small percentage, and get larger payouts from other patients (which is why private pay patients get screwed), you can earn a living. The days of making a fortune in medicine are gone, though, unless you are a specialist, the reimbursment isn't the way it was 20 years ago, which is sort of a shame, since it will reach a point where people don't want to pony up the money to go to med school just so they can work hard to earn $30k/year after they pay their malpractice insurance, assistants, and rent.
Multi-master is certainly not without problems, as it inevitably involves some compromise at the application level to at least minimize the potential for conflicts (which is why I handle async replication outside the database, with each master assigned their own ranges for things like auto-increment columns [and reduce the number of auto-increment columns as much as possible], and triggers to track changes that need to be synchronized), but some applications cannot do without it. Things like banks and hospital groups, or basically anything with multiple mission-critical sites that need access to all data instantly, must have updateable databases onsite, just in case the network connection to the primary is lost.
As far as I know, the few differences between plsql and pgsql are covered by EnterpriseDB's product (which they provide support for, for a LOT less than Oracle), but other than some minor syntax or naming differences, I can't think of anything you'd actually use that is in plsql that is not in pgsql. Also, PostgreSQL 8.1 has table partitioning. The only major features that are missing are the multi-master replication systems, like RAC. MySQL's cluster is intended to be similar to RAC, but for now is in-memory only, and MySQL is a little new to the large-scale arena and doesn't act quite the same as Oracle and PostgreSQL under load (ACID/MVCC). What we need is RAC for PG, and maybe a little less complaining on forums about COUNT(*) being slow, and more explaining WHY COUNT(*) is slow (MVCC), and why everything else is faster because COUNT(*) is slow (except MIN/MAX, which is now much better for indexed columns). Of course, for the $40,000 per processor you'd spend on Oracle, I'm sure both MySQL AB and EnterpriseDB/PostgreSQL developers would be willing to fix those things. Hell, for a few Oracle processors worth, I'd be willing to add something like RAC to PostgreSQL.
No, this is common practice, because it often just makes sense. Maintaining a set of common components means that when you do reuse a piece, you can maintain it once, and release the updated component to all of the affected software. So if you have 30 different customer applications that all use the same iText based report generators, you only have to fix a bug in one place, or add a new feature (like a new type of chart) in one place, and you can release the update for all 30 applications (and satisfy your 30 maintenance contracts). I have a set of my own components and FOSS components (like iText), that I reuse for various common features, and I'm sure the big companies (CA for example) do the same.
Hypothetical bulb changes. I'm saying it would still be cheaper after "several" bulb changes. In fact, I have done 2, but the first was because I moved it without letting the bulb cool enough first. I probably lost half the life of the first bulb from moving it, but I've had it for about 3 years now, and just put the 3rd bulb (counting the original) in last week. I have no idea how long it really has lasted, but 3000 hours/bulb does seem reasonable, since we do use it quite a bit.
Or you could do what I did, avoid the whole issue completely and use a DLP projector. You have to replace the bulb every 3000 hours or so, but even after several bulb changes, I couldn't find a comparable LCD or plasma for less, since my 10' diagonal screen still isn't available with flat panels. I spent about $800 for the projector, and the cost of the bulbs ends up being around $0.05/hr to use it, a number which is perfectly acceptable to me.
No, actually it's a private lab, with a very limited budget, but buying quality components is often much cheaper than buying the cheapest parts available. Replacing a failed part costs the part plus tech time ($12-$17/hr), so for a 10 minute replacement, about $2-$3 plus the part, assuming someone more expensive doesn't have to get involved (like a tech asking me to look at it). Diagnosing a strange error could take a few hours of trial and error, and you might still have to replace the part. Considering that the most expensive component in any of my desktops is about $50, and that whatever voodoo you do will then make that desktop *special* compared to the other hundred that you have, it's not worth it. Now, the GP post is not a hardware issue, it's probably a driver issue, and regardless of whether he thinks any changes were made, I'm willing to bet that something was different with the configuration between working and not working. (Like he forgot the "SCSI Tape" driver, or the SCSI driver itself. These are both trivial, but since he didn't really isolate and fix the problem, but just replaced the kernel (with the correct drivers compiled), he'll never know. This is not what I was saying, I said replace the part that is the problem, meaning that you have to know what the problem is first, and which part causes it. In his case, I would check the SCSI adapter BIOS util to see if it sees the drive, then check in Linux to see if the adapter driver is loaded (and what devices it sees), then check for the SCSI Tape driver. The whole idea is to actually understand what you are doing, not just try stuff until it just happens to work.
By the same token, I don't want to manage 100 *special* computers, I want machines that work, and that can be reimaged from the standard image in 15 mins and work. If the hardware works, and you maintain updates on the standard image, any software problem can be fixed in 5 minutes or less (depending on how deeply they've buried the computer under their desk) with a hard drive and a screwdriver, meaning that my tech can handle far more computers in far more locations than if he spent 2-3 hours on each problem.
To make it a little more clear, I had a group of computers I bought from a vendor, where the power supplies would not work in our building, but would work in other buildings. We isolated it down to the power supplies, and had a few possibilities as to why it didn't work, but couldn't change our power feed or the amount of interference from the radio station next door. This was an easy problem to solve. Call the vendor, say "These cheap power supplies don't work, send me brand Y instead of these brand X", send back the power supplies, get the others, and done. For the next 3 orders, we didn't have a problem, since we got the parts that cost $1 more, but worked everywhere.
Really, what do you expect when you pick up a "groundbreaking" mathematical theory book? These books are all the same, some PhD spouting reasons why his solution to some trivial problem is more elegant than someone else's. Anything that requires an actual BOOK to explain probably isn't worth it, because the traditional means to solve problems are often much simpler. I actually had these types of discussions (though related to set theory, not trig/geometry) with grad assistants and professors in college, and even though my style of solution is always correct (I call it proof by construction), since it can be proven to be equivalent to other solution forms, I barely thought it was worth discussing to prove that the F I got on the assignment was actually an A, much less write a BOOK about it. I did get an A, but I had to prove that my methodology was correct [which was relatively trivial], and that it was essentially a set-oriented method combining several types of direct, indirect, and inductive proof methodologies into a simpler form (basically, that if you can show that the construction of two sets [i.e. formulae for all elements in the sets] are identical, then those sets are identical.)
As an extremely simple example, (A union B) intersect C = (A intersect C) union (B intersect C) because [skipping trival steps] (A union B) intersect C is the set of all x such that x is in C (commutative) and (definition of intersection) x is in either A or B (definition of union), and (A intersect C) union (B intersect C) is the set of all x such that x is in C (distributive) and x is in either A or B (definition of union). Since these two formulae are identical, the sets are identical. This sometimes leads to very long notations of sets, but essentially makes solving a lot of complex proofs as simple as flipping things around to take the same form and applying that to the problem. Indirect by contradiction is done when you can subtract one set from the other and show that something remains, and inductive is done by applying the defining formula (say elements n and n + 1) to the definition of the problem set to show that their inclusion in the problem set is equivalent (which is essentially the same as a traditional inductive proof, induction is not the strong point of this method, but it CAN be done).
Slashdot Mirror
I have to say I don't understand your logic there. So you want people who struggled with the core CS material, and just barely managed to graduate by working harder than average over the people who were good enough to be able to skate through? I understand that you want someone who is willing to work hard for the company, but you want that hard work to actually produce something too. There are far too many people out there with CS degrees that can't keep up. I'd rather have the one who slacked off a bit in college because the coursework was too easy and boring to them, than five people who struggled but worked hard to get a degree. As for the original post, in my experience, both personally and from conversations with other companies' hiring managers, after you have worked for 2-3 years beyond graduation, your grades mean nothing. As for the rest of your post, you are correct that there is often a huge difference between working for a large company versus a small company. I have worked in both, and you're right, it is nice to have the flexibility (and power) of working at a smaller company, as it keeps things interesting, but the hours and budget can be frustrating (long hours, smaller/no budget for your projects). At a large company, it is just the opposite, it is no longer *my* department (though the management is very responsive to good ideas), but I don't get wake-up calls from users at 3 AM anymore, can actually take a vacation, and the department has a much larger budget. With the small company, design decisions often came down to "What do we already have that we can use for this?" for things like which database system to use, where with the larger company I'm at now, the question is "Which product is the best for what we need?" and if we don't have it, we buy it. A purchase that would have been more than my annual budget for the entire IT department at the small company is taken care of with a 20 minute meeting. Plus, salary negotiations are easier when your salary is less than a percent of the company's income.
Exactly, as an employer looking to hire people as programmers (which would be the majority of the jobs looking for CS degrees), you now have people with a degree that means nothing. There are very few positions (professors, researchers) where theory is more important than actually being able to write code. I say we should go in the completely opposite direction, with more architecture and programming classes (using architecture to have people actually understand what they are doing, and why a certain code block is efficient/inefficient on the hardware it is running on), and only one or two survey courses on algorithms and theory, with more available as electives. CS should be an Engineering degree, as it is in my school (UCF), not a liberal arts degree. I don't see many women in Mechanical, Aerospace, Electrical, or Computer Engineering either, should we stop building cars, satellites, and circuits too? Of course, 28% seems extremely high to me, as my experience has been that there are far less than that in my classes, at least in the later stages (1 each in my senior/grad classes).
I wonder if ATM would count, as ATM networks could be considered "computer networks", and Packet-Switched voice over ATM is essentially like VoIP, just VoATM. This would probably mean that another (older) patent would protect it, one that might already have expired.
This is not a performance issue. The only "performance" difference here is that with VT, you can run Windows under Xen. Without VT, you cannot, but can still run kernels (Linux/BSD/etc.) which are built to run on the Xen hypervisor. The OP wanted to use it to run Windows and Linux/BSD/etc. under Xen. As Virtual PC and VMWare both do full virtualization, VT will not make a difference, but with Xen's (faster) paravirtualization (which requires cooperation between the VMM and the guest OS), it means that VT can keep Windows in its own domain, so that interrupts and syscalls don't interfere with the hypervisor and other guest OS(s).
Enabling VT is a huge security risk with no benefit for most of HP's customers. You probably should be able to turn it on, but having it on leaves open the possibility that a rootkit could be installed as the hypervisor/VMM/whatever, making it undetectable to the OS. Even having the option seems dangerous, as many "power users" will probably enable everything in the BIOS they can, regardless of risk/reward. On second thought, there are probably only a few hundred people that would run Xen on their laptop, so why have the "bug" available on the other few hundred thousand laptops? I suspect there may be many legal reasons why it is disabled by default, whether or not disabling the option to turn it on was intentional or not.
If that were the only concern they had, they would be using Sun's Niagara line. They wanted to compete with the brand recognition/performance reputation (accurate or not) that Intel had, and the only way they saw to do this was to use Intel's chips. Personally, I would much rather have seen them use AMD or even Sun's Niagara (which is actually made by TI), and think that would have paid off even better, as the Mac Server G5 was used in many cases where it's I/O and memory performance put it ahead of Intel products, not it's clock speed.
Doing the switch while maintaining Windows clients can be done easily by replacing the login handlers in windows with something like pGina. Posix ACLs are fairly mature, and work quite well in Linux, and of course are fully mature in Solaris, if you decided to go that route (which might be worth it for zfs, if there is a large enough set of user files). Of course, the major reason why I said the migration is not likely to be difficult is because we are talking about a small business, not a 100+ user migration. Also, the whole idea (at least my take) is to not have the headaches associated with running an AD domain, so one would hope that it would not be identical to Windows. Realistically, though, in a small business there is likely to be only two or three groups of users (managers and everyone else, maybe legal), and ACLs are probably overkill. Samba with LDAP becomes almost trivial (aside from the 20 different ways to set up Samba, according to 20 different setup guides) once you remove AD and winbind from the equation.
Look at your costs before migrating to Linux clients for RDP. Terminal Services Licenses cost nearly as much as a full XP license, so you will likely spend more to do it this way. Having said that, you might be able to run your critical apps under WINE, and use Linux X clients to run it via SSH. I would definitely focus on the servers first though. Check out the O'Reilly books for LDAP and "Linux in a Windows World" for guidance, but it really depends on how many people need to use those critical windows apps, and what apps they are. Let me know what type of apps you are talking about, as there may be replacements or documented WINE support for them. AD to LDAP isn't likely to be much trouble with only a few users, and any mail, file, and print services should be relatively simple to implement, whether you convert or use winbind to maintain AD integration. Having been on both sides, though, I would definitely prefer switching to LDAP first, as AD can give you plenty of headaches down the road. Also, regardless of which path you take, be sure to make use of NTP to maintain your clocks, since a small drift will eventually wreak havoc on anything using kerberos, and it might not be the first thing that comes to mind when something suddenly stops working.
...or just simple shared hosting, hostdime (hostdime.com) is also an excellent choice for either, and they offer horde and squirrelmail for webmail too.
The audit DB (for all application transactions [healthcare industry]) was a single Opteron 240 with a 12 drive SATA RAID and 4GB RAM. As the DB was mostly used for inserts and a few employee productivity or records research reports, the CPU load rarely topped 3%.
That was exactly my point. 16M rows is not a "large" table. Maybe 10 years ago that would be a lot for common hardware, but I would imagine that most Mid-size companies see 16M+ rows as a common thing. We only had 10 years of live data, and only about 90 employees. I'm sure there are much larger databases than ours was.
Again, I don't think that the number of people with MySQL tables with 16,000,000+ rows is very large, but it is still disturbing.
Are you kidding me? At my last job, we had five tables (audit records and various archives) larger than 16,000,000 rows. PostgreSQL 8.1 worked fine.
actually, they used innodb, and yes, Postgres scales much better than MySQL, but MySQL is a little more streamlined for low-volume jobs.
Agreed. I live in Florida, and can tell you, the Michigan drivers (that visit here) are the worst, with the Quebecois a close second. Seriously, though, the US needs to work on driver safety through education, not ticketing. Look at Germany, with no speed limits on most major roads, and with an expensive and lengthy licensing process [that never expires, but you can lose it], they have almost half the fatality rate per driver.
Definitely not impossible. Mounting a few solid-state accelerometers on these glasses could create some interesting visualization and gaming possibilities. Not exactly CREOL's area, but he could probably talk to one of the simulation guys. Drs. Workman and Hughes come to mind, and maybe Lobo with the addition of a camera for robot-vision applications (like vision enhancement). Could be some interesting applications of this, and nice to see my school on the front page.
Just to add to this, applying a hand to lower-forearm gauntlet-style cast is reimbursed by Medicare in the US at $65.20, with plaster cast supplies reimbursed at $12.61, and fiberglass at $21.29. HMO's typically pay around 80% (based on lab codes, I don't have experience with hospital and physician codes) of Medicare rates, with Medicaid rounding out the bottom at about 60%. Fiberglass pre-preg casting material costs about 2-3 times as much as plaster, so there is a small argument there, although it would typically require less material. The difference isn't likely to matter much, so you're probably right, although the OP isn't likely to make much for the time to set the cast (and arguably it is probably not worth a physician's time, nurses or assistants are much cheaper), he isn't likely to be losing money on the supplies (with the possible exception of Medicaid), unless a more substantial cast is required, in which case a more substantial procedure code might be appropriate.
Just for reference, a 3" x 4yd roll of fiberglass pre-preg is a little under $200, while a 3" x 5yd roll of plaster material is about $80, and both would use a little bit of wrap underneath (not significant). I can certainly attest that payment rates for some procedures are rediculously low (drawing blood for laboratory work being one where you are virtually guaranteed to lose money, due to safety regulations [disposable safety needles and hubs], tubes, guaze, tape, etc. and labor costs, all for a $3 reimbursment from Medicare, or NOTHING from Medicaid and most insurance companies [after all, you should just be able to get specimens magically]), these shortfalls often can be made up in other areas (like the actual tests on those specimens). It is possible to make a profit doing health care work, but you have to be selective in which clients you take, which leaves a lot of people out in the cold. If I were a doctor, I wouldn't want to service an area full of Medicaid patients, because I would probably struggle to pay my rent, let alone eat. But if you take a small percentage, and get larger payouts from other patients (which is why private pay patients get screwed), you can earn a living. The days of making a fortune in medicine are gone, though, unless you are a specialist, the reimbursment isn't the way it was 20 years ago, which is sort of a shame, since it will reach a point where people don't want to pony up the money to go to med school just so they can work hard to earn $30k/year after they pay their malpractice insurance, assistants, and rent.
Multi-master is certainly not without problems, as it inevitably involves some compromise at the application level to at least minimize the potential for conflicts (which is why I handle async replication outside the database, with each master assigned their own ranges for things like auto-increment columns [and reduce the number of auto-increment columns as much as possible], and triggers to track changes that need to be synchronized), but some applications cannot do without it. Things like banks and hospital groups, or basically anything with multiple mission-critical sites that need access to all data instantly, must have updateable databases onsite, just in case the network connection to the primary is lost.
As far as I know, the few differences between plsql and pgsql are covered by EnterpriseDB's product (which they provide support for, for a LOT less than Oracle), but other than some minor syntax or naming differences, I can't think of anything you'd actually use that is in plsql that is not in pgsql. Also, PostgreSQL 8.1 has table partitioning. The only major features that are missing are the multi-master replication systems, like RAC. MySQL's cluster is intended to be similar to RAC, but for now is in-memory only, and MySQL is a little new to the large-scale arena and doesn't act quite the same as Oracle and PostgreSQL under load (ACID/MVCC). What we need is RAC for PG, and maybe a little less complaining on forums about COUNT(*) being slow, and more explaining WHY COUNT(*) is slow (MVCC), and why everything else is faster because COUNT(*) is slow (except MIN/MAX, which is now much better for indexed columns). Of course, for the $40,000 per processor you'd spend on Oracle, I'm sure both MySQL AB and EnterpriseDB/PostgreSQL developers would be willing to fix those things. Hell, for a few Oracle processors worth, I'd be willing to add something like RAC to PostgreSQL.
or he's still using punchcards... [I know, but I had to say it]
No, this is common practice, because it often just makes sense. Maintaining a set of common components means that when you do reuse a piece, you can maintain it once, and release the updated component to all of the affected software. So if you have 30 different customer applications that all use the same iText based report generators, you only have to fix a bug in one place, or add a new feature (like a new type of chart) in one place, and you can release the update for all 30 applications (and satisfy your 30 maintenance contracts). I have a set of my own components and FOSS components (like iText), that I reuse for various common features, and I'm sure the big companies (CA for example) do the same.
Actually, he buys houses. See http://www.ugbuysuglyhouses.com and note the mascot.
Hypothetical bulb changes. I'm saying it would still be cheaper after "several" bulb changes. In fact, I have done 2, but the first was because I moved it without letting the bulb cool enough first. I probably lost half the life of the first bulb from moving it, but I've had it for about 3 years now, and just put the 3rd bulb (counting the original) in last week. I have no idea how long it really has lasted, but 3000 hours/bulb does seem reasonable, since we do use it quite a bit.
Or you could do what I did, avoid the whole issue completely and use a DLP projector. You have to replace the bulb every 3000 hours or so, but even after several bulb changes, I couldn't find a comparable LCD or plasma for less, since my 10' diagonal screen still isn't available with flat panels. I spent about $800 for the projector, and the cost of the bulbs ends up being around $0.05/hr to use it, a number which is perfectly acceptable to me.
No, actually it's a private lab, with a very limited budget, but buying quality components is often much cheaper than buying the cheapest parts available. Replacing a failed part costs the part plus tech time ($12-$17/hr), so for a 10 minute replacement, about $2-$3 plus the part, assuming someone more expensive doesn't have to get involved (like a tech asking me to look at it). Diagnosing a strange error could take a few hours of trial and error, and you might still have to replace the part. Considering that the most expensive component in any of my desktops is about $50, and that whatever voodoo you do will then make that desktop *special* compared to the other hundred that you have, it's not worth it. Now, the GP post is not a hardware issue, it's probably a driver issue, and regardless of whether he thinks any changes were made, I'm willing to bet that something was different with the configuration between working and not working. (Like he forgot the "SCSI Tape" driver, or the SCSI driver itself. These are both trivial, but since he didn't really isolate and fix the problem, but just replaced the kernel (with the correct drivers compiled), he'll never know. This is not what I was saying, I said replace the part that is the problem, meaning that you have to know what the problem is first, and which part causes it. In his case, I would check the SCSI adapter BIOS util to see if it sees the drive, then check in Linux to see if the adapter driver is loaded (and what devices it sees), then check for the SCSI Tape driver. The whole idea is to actually understand what you are doing, not just try stuff until it just happens to work.
By the same token, I don't want to manage 100 *special* computers, I want machines that work, and that can be reimaged from the standard image in 15 mins and work. If the hardware works, and you maintain updates on the standard image, any software problem can be fixed in 5 minutes or less (depending on how deeply they've buried the computer under their desk) with a hard drive and a screwdriver, meaning that my tech can handle far more computers in far more locations than if he spent 2-3 hours on each problem.
To make it a little more clear, I had a group of computers I bought from a vendor, where the power supplies would not work in our building, but would work in other buildings. We isolated it down to the power supplies, and had a few possibilities as to why it didn't work, but couldn't change our power feed or the amount of interference from the radio station next door. This was an easy problem to solve. Call the vendor, say "These cheap power supplies don't work, send me brand Y instead of these brand X", send back the power supplies, get the others, and done. For the next 3 orders, we didn't have a problem, since we got the parts that cost $1 more, but worked everywhere.
Really, what do you expect when you pick up a "groundbreaking" mathematical theory book? These books are all the same, some PhD spouting reasons why his solution to some trivial problem is more elegant than someone else's. Anything that requires an actual BOOK to explain probably isn't worth it, because the traditional means to solve problems are often much simpler. I actually had these types of discussions (though related to set theory, not trig/geometry) with grad assistants and professors in college, and even though my style of solution is always correct (I call it proof by construction), since it can be proven to be equivalent to other solution forms, I barely thought it was worth discussing to prove that the F I got on the assignment was actually an A, much less write a BOOK about it. I did get an A, but I had to prove that my methodology was correct [which was relatively trivial], and that it was essentially a set-oriented method combining several types of direct, indirect, and inductive proof methodologies into a simpler form (basically, that if you can show that the construction of two sets [i.e. formulae for all elements in the sets] are identical, then those sets are identical.)
As an extremely simple example, (A union B) intersect C = (A intersect C) union (B intersect C) because [skipping trival steps] (A union B) intersect C is the set of all x such that x is in C (commutative) and (definition of intersection) x is in either A or B (definition of union), and (A intersect C) union (B intersect C) is the set of all x such that x is in C (distributive) and x is in either A or B (definition of union). Since these two formulae are identical, the sets are identical. This sometimes leads to very long notations of sets, but essentially makes solving a lot of complex proofs as simple as flipping things around to take the same form and applying that to the problem. Indirect by contradiction is done when you can subtract one set from the other and show that something remains, and inductive is done by applying the defining formula (say elements n and n + 1) to the definition of the problem set to show that their inclusion in the problem set is equivalent (which is essentially the same as a traditional inductive proof, induction is not the strong point of this method, but it CAN be done).