Rules and laws
will regulate the internet.
We do not get to choose whether the regulations are applied. We do, however, get to choose what those regulations will be.
We get to choose what those regulations will be to the same degree that we got to choose whether or not the DMCA would become law.
In short, there isn't nearly as much choice about this as you seem to think.
In summary: the court found that intent is everything.
And yet, Elcomsoft no longer offers their product for sale in the U.S.
So the real result of this is: you are not guilty only if you didn't intend to violate the DMCA and you take subsequent action to avoid violating it.
In other words, this doesn't do anything to curtail the damaging effects of the DMCA, because it doesn't measure guilt based on the purpose of your product. If it did, then Elcomsoft could continue to sell their product in the U.S.
The reason you think work has to begin on porting massively popular games seems to be because of a common, but incorrect line of thinking: That Linux has to become a major desktop success right now. It doesn't.
Yes, it does. Or, rather, it has to in the near future. The reason? Palladium and TCPA.
If Microsoft retains its current dominance, then the combination of Palladium in their OS and TCPA in the hardware will eventually lead to a hardware platform that will not boot anything but a "trusted" operating system, and we all know that "trusted" is measured by the large corporations, not by the end user.
Only if Linux on the desktop becomes popular enough quickly enough will we avoid the situation where we're forced to pay massively inflated prices for "server" hardware (because the only reason you would want to run an "untrusted" operating system is if you're running a "server", right?).
You could argue that I should be using something else for versioning, like a CVS repository, but that's too painful in a large multi-user environment.
Too painful? What are you talking about? It's really easy to set up a cron job that goes through all of the users' directories and checks in those files that are either newer than their RCS version or which don't have an RCS version.
Set it up to run once per night and periodically back up the RCS files and you're done.
That is the danger of having someone without any tact representing the company or a group in a "delicate" situation.
No, it's the danger of having someone who is willing to pass judgement on the state of something without going to the trouble to find out what's really going on.
If I'm running a company, I'd much rather have someone who is willing to tell me what they think rather than a sheep who will tell me only what they think I want to hear. The latter is what most people think of as "tact", and frankly it amazes me that people who make decisions care about that.
Decision making depends on having solid information, not on "feel good" pronouncements.
It would be bad for the company reputation. Imagine, your support is so worthless that the few good technicians have to give advice to people while not at work because they can't on the job?
If your support is that worthless, then forbidding your employees from helping others in their spare time won't help. The only way to fix that problem is to fix your official support.
It also a liability issue. What if a less-than-stellar tech goes online and starts spewing bad information - then people are angry at your company, and you've done nothing wrong.
What makes you think this isn't going to happen while the tech is on the job? If a tech does that then they deserve to be reprimanded. While reprimanding an employee for what they say while not on the job treads dangerously on First Amendment rights, employers can probably get away with it these days.
Regardless, techs should be reprimanded for doing things that are bad for the company, not things that merely could be.
"Liability" has become the ubiquitous excuse for far too many of the evils in the world today.
I'm aware of the difference between RAID 0+1 and RAID 1+0. I don't know why we didn't think of setting up RAID 1+0 at the time, but we didn't. Oh, well...
Veritas Volume Manager is what gave us the ability to set up RAID on top of JBOD to begin with. So consider it to be the equivalent of Linux's MD in this case (though Veritas is really more like the combination of LVM and MD).
I saw the LVM stuff, and was going to use it on a new install with two 80GB drives (and a separate boot/OS drive). But I wasn't sure about redundancy. How does it handle that?
I did some looking into this myself. It appears that LVM doesn't deal with redundancy at all: its entire purpose is to provide virtual volumes composed of other virtual or physical volumes. Redundancy has to be provided for at the lower levels, it seems. That means you have to construct one or more RAID 0+1 or RAID 5 devices and use them as the basis of one ore more LVM volumes.
That's why I didn't bother with LVM. It's nice, but it wouldn't have given me enough of an advantage to be worth going to the trouble. As it is, I'm quite happy with my 3-disk RAID 5 setup.
However, if you had a heavily loaded server machine, where the processors were loaded down doing other things (say SSL-encrypting for an secure web server), the machine with the Adaptec would trounce the others, as the RAID processing speed will not decrease while your applications are using most of the CPU (or depending on the device driver's pre-emptability, it could be the other way around, that the CPU simply wouldn't be as available to your CPU-hungy SSL server as it's busy with the RAID).
This isn't necessarily true at all.
A few years ago I did a lot of RAID testing for the company I was working for. In my case we were testing a RAID 0+1 set of 12 Seagate Barracuda 10K drives (9G each) being driven by Sun machines (we tested a couple of different Ultra 2 configurations) running Veritas Volume Manager. I think we had 4 SCSI controllers driving 3 disks each (don't remember exactly).
Know what we found? RAID speed depended enormously on CPU horsepower. Read and write speed increased almost linearly with processor speed. The bus and drives were apparently more than even the fastest CPUs (300 MHz Ultrasparc) we could stuff into the machines were able to handle.
You may think the Adaptec hardware RAID will outperform software RAID on a P4 under heavy CPU load, but that depends entirely on just how much demand there is on the CPU itself, how much CPU the software RAID requires, and (most importantly) how fast the CPU on the Adaptec's RAID controller is.
At the time I did the testing I describe above, all but the most expensive hardware RAID solutions were using CPUs that were far slower than the CPUs we could put into the system itself. And as a result, the performance we got out of them wasn't even close to the performance we got out of software RAID.
As for the performance and CPU utilization characteristics of the Adaptec card, you should look at the Winbench CPU utilization graph supplied in the article: the fact that the Adaptec is a hardware RAID solution didn't help (it helped a little in the IOMeter tests but its CPU utilization wasn't that much lower than most of the other cards except the Promise card).
Even if the hardware RAID itself were to use no CPU at all, the CPU will still be used for managing the filesystem, the buffer cache, the DMA transfers, the kernel-to-application communications, etc. Those things don't go away no matter what.
If you have to choose between putting your money into a RAID controller or putting into a faster CPU, you'll almost certainly be better off with the faster CPU. The $323 you'll pay for the Adaptec 2400A will almost (but not quite) pay for the difference between a single CPU motherboard and a dual CPU motherboard plus an additional 2 GHz Xeon CPU. Not only is that more than enough CPU to drive a software RAID device faster than the Adaptec, the extra CPU can be utilized for other things when it isn't driving the RAID.
Conclusion: choose hardware RAID for reasons other than performance over software RAID.
Yep. Just the other day I watched a sysadmin talk down a user who was freaking out over his computer not being safe for the internet. It was quite sad.
If the computer was running Internet Explorer under Windows, then the user was right...
I confirmed this with our production manager who once worked for a national retailer that did Black Friday inserts - she also suspected people inside the companies were responsible for the initial leaks. She knows from firsthand experience that people rushing to prepare holiday ads are often disgruntled and/or overworked and more likely to make mistakes or blatent confidentiality breaches.
And you know what I say to this? If the employees in question are overworked and disgruntled, then their employers got exactly what they deserved here.
Listen up, you people who run these large corporations: You and your employees are one. You may think you have a responsibility only to your shareholders, but you'd be wrong if you believe that. You also have a responsibility to your employees. They work for you, and just like you have certain needs that must be met, your employees also have certain needs that must be met. You are just as responsible for the well-being of your employees as they are for the well-being of your company. Your employees are the company. The better off they are, the better off you are. Overworking and underpaying your employees is like working your body too hard and not feeding it enough. Your body will eventually collapse and, if you push it, die. Just like your company.
It is not so much collusion as it is everyone knows what the other guy is doing. They all know what the costs are, what kind of profit margins are acceptable, which items are 'loss leaders' etc etc.
No, it's almost certainly collusion. It almost has to be.
Because for you to claim otherwise means that the stores in question have to have essentially identical operating costs. That's highly unlikely: the stores have different management, different suppliers, pay differing amounts of rent, etc. Some of these things will cancel each other out, but not so much that the stores will somehow independently offer the exact same products for the exact same prices.
Marketing monkeys have money to throw around using MRIs for product targeting while HMO members have to fight tooth and nail to get HMOs to cough up money to use MRIs for life-and-death situations.
Probably because the MRIs the marketing guys can use will cost orders of magnitude less than the MRIs the medical guys can use, thanks to the FDA's super-strict certification process.
I have no problem with the idea of certification of medical devices. It makes sense to want to make them as safe as possible. But there should be a tradeoff involved: certification should make one immune from litigation. It seems to me that manufacturers should be able to choose between certification and lawsuit exposure. But what we have right now is the worst of both: expensive certification and exposure to lawsuits.
The medical field isn't the only one facing these issues: the aviation field has the same problem. And it's why personal aviation is all but dead.
The only reason the medical field isn't all but dead is that the demand for medical services is natually much higher: when your life is on the line, you aren't going to think too hard about whether or not the asking price is too high.
Still running NT3.51 and 4.0 over here and I have yet to see the gun pointed at me forcing me to upgrade. I still get support from my vendor, and the machines are (surprisingly) running so well that we rarely touch them.
But that will eventually change: your hardware will not last forever, and eventually you'll be forced to upgrade if only because hardware that is a drop-in replacement for what you have will be very difficult (thus expensive) to find.
And at the point you are forced to change hardware, you may well be forced to upgrade, because there's no guarantee you'll be able to get NT3.51 drivers for things like the new RAID controller (or networking card, or... you get the idea).
That means upgrading your OS to something that does support your (new) hardware.
These cases never come to light because those who are challenged can't even begin to mount a legal defense, and therefore, fold like Superman on laundry day.
Felten may be a special case, though. Basically, I think Felten was an idiot. He presented his material at Usenix despite the uncertainty that any reasonable person would have felt if they had received the same letters that Felten had (one saying they were going to sue under the DMCA, the other saying otherwise).
Felten could easily have persuaded the judge in his case that the uncertainty generated by those two letters was reason enough to require the preemptive ruling he was requesting. But as it was, he was an idiot and presented his findings. And so the judge as a result essentially said "Prior restraint on free speech? Where??".
I think you're right about the reasons many of these cases don't come to light, but Felten illustrates one of the reasons that you don't cover: that the good guys are sometimes morons when it comes to working the legal system.
So, does PG+PHP match the speed of My+PHP? Is it as thoroughly tested? As I'm moving away from using Perl, I'd be really interested in seeing some benchmarks with this new version of PG...
The question shouldn't be whether PG+PHP matches teh speed of MySQL+PHP, but rather whether the speed of PG+PHP is good enough for your application and, more importantly, whether it will scale reasonably well under load.
This
seems to indicate that PG+PHP will scale better than MySQL+PHP, but that will certainly depend on the configuration of MySQL (in particular, which table type you use).
You should be a lot more concerned about the features of the database that you will require, instead of the speed, because once you select a database engine you'll have a lot of trouble migrating to a different one. Speed can always be gained by throwing more hardware at the problem if necessary. Database features can't.
And you can rename tables and colums on the fly too!
Oh, it's even better than that. You can do these things within transactions. If you rename a table within a transaction and abort the transaction, it's as if the rename never took place.
This is very cool stuff. I suspect that dropping columns works the same way. It means that you can do things like exchange table names atomically.
Cue all the people telling us why it's better than MySQL.
Well, if you insist...:-)
It's better for certain things (most things, actually). PostgreSQL is a bit more feature-complete as a SQL database than MySQL is. MySQL is improving, certainly: it now has transactions and such. But PostgreSQL has quite a bit more: triggers, rules, stored procedures, and views, for instance.
In terms of speed, MySQL is faster for certain specific operations but that speed comes at the price of database integrity: the lack of rules and triggers means that it is not possible for the database to enforce consistency between tables. One must thus trust applications to do the right thing, which is generally not wise.
It's like the difference between an OS with memory protection and one without. The one without may be faster for certain things, since the OS doesn't have to worry about messing with page tables and dealing with page faults of various kinds, but the price is that you now have to trust the applications running under the OS to do the right thing and not touch memory that doesn't belong to them.
As I said, MySQL is faster for certain things. But PostgreSQL is reportedly
better at handling lots of concurrent transactions than MySQL. It's not clear, then, that MySQL is much better than PostgreSQL, if at all, under high load situations. And if it isn't, then there's really little reason to go with it over PostgreSQL.
Finally, even if MySQL is faster, it's not likely to be so much faster that it is the difference between success and failure. And I can tell you this: experience shows that the initial requirements of a project are often vastly different, and usually much less demanding, than the final requirements for the same project. So it makes more sense to go with the most capable database backend you can lay your hands on, as long as it remains within your budget (your real budget: remember that you're likely to spend a lot more money than you expected, if only because the requirements will change over time). That means going with PostgreSQL over MySQL, if given the choice. You have to make the decision early because changing your database engine mid-project is extremely difficult, especially if your code was written to work around the limitations of the database engine, as it almost certainly will if you're using MySQL.
These days I don't think the question should be whether you should go with PostgreSQL instead of MySQL. It should be whether you should go with MySQL instead of PostgreSQL. PostgreSQL should be the default choice these days, because it is so much more capable at the same price.
I don't think there's anything wrong with the fact that MS is 'asking' companies to remove Windows from their product names.
Microsoft (in Godfather-like tone): We noticed you're using "windows" in the name of your business. Your business is very important to you. I'm a businessman, so I understand these things. I also know that there are many... uncertainties... in running a business. I like you. I don't want to see anything happen to you. And it would be very... unfortunate... if something were to happen to you or your business because you continued using "windows" in the name.
Two names is about all most customers can keep track of.
Yep. That's why people only know about Ford and Chevrolet. They've never heard of Toyota, or Honda, or Nissan, or Mazda, or Hyundai, or Mercedes, Porsche, BMW, Lexus, etc.
Yep, customers are dumb as dirt, and have trouble enough keeping up with the names of their kids.
Slashdot Mirror
We get to choose what those regulations will be to the same degree that we got to choose whether or not the DMCA would become law.
In short, there isn't nearly as much choice about this as you seem to think.
And yet, Elcomsoft no longer offers their product for sale in the U.S.
So the real result of this is: you are not guilty only if you didn't intend to violate the DMCA and you take subsequent action to avoid violating it.
In other words, this doesn't do anything to curtail the damaging effects of the DMCA, because it doesn't measure guilt based on the purpose of your product. If it did, then Elcomsoft could continue to sell their product in the U.S.
Yes, it does. Or, rather, it has to in the near future. The reason? Palladium and TCPA.
If Microsoft retains its current dominance, then the combination of Palladium in their OS and TCPA in the hardware will eventually lead to a hardware platform that will not boot anything but a "trusted" operating system, and we all know that "trusted" is measured by the large corporations, not by the end user.
Only if Linux on the desktop becomes popular enough quickly enough will we avoid the situation where we're forced to pay massively inflated prices for "server" hardware (because the only reason you would want to run an "untrusted" operating system is if you're running a "server", right?).
Sounds like they're using Emacs (ESC-A in Emacs does the same thing as the HOME key does: beginning of line).
Too painful? What are you talking about? It's really easy to set up a cron job that goes through all of the users' directories and checks in those files that are either newer than their RCS version or which don't have an RCS version.
Set it up to run once per night and periodically back up the RCS files and you're done.
No, it's the danger of having someone who is willing to pass judgement on the state of something without going to the trouble to find out what's really going on.
If I'm running a company, I'd much rather have someone who is willing to tell me what they think rather than a sheep who will tell me only what they think I want to hear. The latter is what most people think of as "tact", and frankly it amazes me that people who make decisions care about that.
Decision making depends on having solid information, not on "feel good" pronouncements.
If your support is that worthless, then forbidding your employees from helping others in their spare time won't help. The only way to fix that problem is to fix your official support.
What makes you think this isn't going to happen while the tech is on the job? If a tech does that then they deserve to be reprimanded. While reprimanding an employee for what they say while not on the job treads dangerously on First Amendment rights, employers can probably get away with it these days.
Regardless, techs should be reprimanded for doing things that are bad for the company, not things that merely could be.
"Liability" has become the ubiquitous excuse for far too many of the evils in the world today.
"It's just business. Nothing personal. You understand, don't you?"
Since that phrase has been used to justify everything up to and including murder, it has no meaning.
Got news for you: if it affects me, it's personal. PERIOD.
Veritas Volume Manager is what gave us the ability to set up RAID on top of JBOD to begin with. So consider it to be the equivalent of Linux's MD in this case (though Veritas is really more like the combination of LVM and MD).
I did some looking into this myself. It appears that LVM doesn't deal with redundancy at all: its entire purpose is to provide virtual volumes composed of other virtual or physical volumes. Redundancy has to be provided for at the lower levels, it seems. That means you have to construct one or more RAID 0+1 or RAID 5 devices and use them as the basis of one ore more LVM volumes.
That's why I didn't bother with LVM. It's nice, but it wouldn't have given me enough of an advantage to be worth going to the trouble. As it is, I'm quite happy with my 3-disk RAID 5 setup.
Corrections to any of this welcome, of course.
This isn't necessarily true at all.
A few years ago I did a lot of RAID testing for the company I was working for. In my case we were testing a RAID 0+1 set of 12 Seagate Barracuda 10K drives (9G each) being driven by Sun machines (we tested a couple of different Ultra 2 configurations) running Veritas Volume Manager. I think we had 4 SCSI controllers driving 3 disks each (don't remember exactly).
Know what we found? RAID speed depended enormously on CPU horsepower. Read and write speed increased almost linearly with processor speed. The bus and drives were apparently more than even the fastest CPUs (300 MHz Ultrasparc) we could stuff into the machines were able to handle.
You may think the Adaptec hardware RAID will outperform software RAID on a P4 under heavy CPU load, but that depends entirely on just how much demand there is on the CPU itself, how much CPU the software RAID requires, and (most importantly) how fast the CPU on the Adaptec's RAID controller is.
At the time I did the testing I describe above, all but the most expensive hardware RAID solutions were using CPUs that were far slower than the CPUs we could put into the system itself. And as a result, the performance we got out of them wasn't even close to the performance we got out of software RAID.
As for the performance and CPU utilization characteristics of the Adaptec card, you should look at the Winbench CPU utilization graph supplied in the article: the fact that the Adaptec is a hardware RAID solution didn't help (it helped a little in the IOMeter tests but its CPU utilization wasn't that much lower than most of the other cards except the Promise card).
Even if the hardware RAID itself were to use no CPU at all, the CPU will still be used for managing the filesystem, the buffer cache, the DMA transfers, the kernel-to-application communications, etc. Those things don't go away no matter what.
If you have to choose between putting your money into a RAID controller or putting into a faster CPU, you'll almost certainly be better off with the faster CPU. The $323 you'll pay for the Adaptec 2400A will almost (but not quite) pay for the difference between a single CPU motherboard and a dual CPU motherboard plus an additional 2 GHz Xeon CPU. Not only is that more than enough CPU to drive a software RAID device faster than the Adaptec, the extra CPU can be utilized for other things when it isn't driving the RAID.
Conclusion: choose hardware RAID for reasons other than performance over software RAID.
Today I think the music companies (RIAA, et al) are organized crime. They certainly look, sound, and smell like it...
If the computer was running Internet Explorer under Windows, then the user was right...
And you know what I say to this? If the employees in question are overworked and disgruntled, then their employers got exactly what they deserved here.
Listen up, you people who run these large corporations: You and your employees are one. You may think you have a responsibility only to your shareholders, but you'd be wrong if you believe that. You also have a responsibility to your employees. They work for you, and just like you have certain needs that must be met, your employees also have certain needs that must be met. You are just as responsible for the well-being of your employees as they are for the well-being of your company. Your employees are the company. The better off they are, the better off you are. Overworking and underpaying your employees is like working your body too hard and not feeding it enough. Your body will eventually collapse and, if you push it, die. Just like your company.
No, it's almost certainly collusion. It almost has to be.
Because for you to claim otherwise means that the stores in question have to have essentially identical operating costs. That's highly unlikely: the stores have different management, different suppliers, pay differing amounts of rent, etc. Some of these things will cancel each other out, but not so much that the stores will somehow independently offer the exact same products for the exact same prices.
No, Occam's Razor says "collusion" here.
Probably because the MRIs the marketing guys can use will cost orders of magnitude less than the MRIs the medical guys can use, thanks to the FDA's super-strict certification process.
I have no problem with the idea of certification of medical devices. It makes sense to want to make them as safe as possible. But there should be a tradeoff involved: certification should make one immune from litigation. It seems to me that manufacturers should be able to choose between certification and lawsuit exposure. But what we have right now is the worst of both: expensive certification and exposure to lawsuits.
The medical field isn't the only one facing these issues: the aviation field has the same problem. And it's why personal aviation is all but dead. The only reason the medical field isn't all but dead is that the demand for medical services is natually much higher: when your life is on the line, you aren't going to think too hard about whether or not the asking price is too high.
But that will eventually change: your hardware will not last forever, and eventually you'll be forced to upgrade if only because hardware that is a drop-in replacement for what you have will be very difficult (thus expensive) to find.
And at the point you are forced to change hardware, you may well be forced to upgrade, because there's no guarantee you'll be able to get NT3.51 drivers for things like the new RAID controller (or networking card, or ... you get the idea).
That means upgrading your OS to something that does support your (new) hardware.
Felten may be a special case, though. Basically, I think Felten was an idiot. He presented his material at Usenix despite the uncertainty that any reasonable person would have felt if they had received the same letters that Felten had (one saying they were going to sue under the DMCA, the other saying otherwise).
Felten could easily have persuaded the judge in his case that the uncertainty generated by those two letters was reason enough to require the preemptive ruling he was requesting. But as it was, he was an idiot and presented his findings. And so the judge as a result essentially said "Prior restraint on free speech? Where??".
I think you're right about the reasons many of these cases don't come to light, but Felten illustrates one of the reasons that you don't cover: that the good guys are sometimes morons when it comes to working the legal system.
The question shouldn't be whether PG+PHP matches teh speed of MySQL+PHP, but rather whether the speed of PG+PHP is good enough for your application and, more importantly, whether it will scale reasonably well under load.
This seems to indicate that PG+PHP will scale better than MySQL+PHP, but that will certainly depend on the configuration of MySQL (in particular, which table type you use).
You should be a lot more concerned about the features of the database that you will require, instead of the speed, because once you select a database engine you'll have a lot of trouble migrating to a different one. Speed can always be gained by throwing more hardware at the problem if necessary. Database features can't.
Oh, it's even better than that. You can do these things within transactions. If you rename a table within a transaction and abort the transaction, it's as if the rename never took place.
This is very cool stuff. I suspect that dropping columns works the same way. It means that you can do things like exchange table names atomically.
Well, if you insist... :-)
It's better for certain things (most things, actually). PostgreSQL is a bit more feature-complete as a SQL database than MySQL is. MySQL is improving, certainly: it now has transactions and such. But PostgreSQL has quite a bit more: triggers, rules, stored procedures, and views, for instance.
In terms of speed, MySQL is faster for certain specific operations but that speed comes at the price of database integrity: the lack of rules and triggers means that it is not possible for the database to enforce consistency between tables. One must thus trust applications to do the right thing, which is generally not wise.
It's like the difference between an OS with memory protection and one without. The one without may be faster for certain things, since the OS doesn't have to worry about messing with page tables and dealing with page faults of various kinds, but the price is that you now have to trust the applications running under the OS to do the right thing and not touch memory that doesn't belong to them.
As I said, MySQL is faster for certain things. But PostgreSQL is reportedly better at handling lots of concurrent transactions than MySQL. It's not clear, then, that MySQL is much better than PostgreSQL, if at all, under high load situations. And if it isn't, then there's really little reason to go with it over PostgreSQL.
Finally, even if MySQL is faster, it's not likely to be so much faster that it is the difference between success and failure. And I can tell you this: experience shows that the initial requirements of a project are often vastly different, and usually much less demanding, than the final requirements for the same project. So it makes more sense to go with the most capable database backend you can lay your hands on, as long as it remains within your budget (your real budget: remember that you're likely to spend a lot more money than you expected, if only because the requirements will change over time). That means going with PostgreSQL over MySQL, if given the choice. You have to make the decision early because changing your database engine mid-project is extremely difficult, especially if your code was written to work around the limitations of the database engine, as it almost certainly will if you're using MySQL.
These days I don't think the question should be whether you should go with PostgreSQL instead of MySQL. It should be whether you should go with MySQL instead of PostgreSQL. PostgreSQL should be the default choice these days, because it is so much more capable at the same price.
Microsoft (in Godfather-like tone): We noticed you're using "windows" in the name of your business. Your business is very important to you. I'm a businessman, so I understand these things. I also know that there are many ... uncertainties ... in running a business. I like you. I don't want to see anything happen to you. And it would be very ... unfortunate ... if something were to happen to you or your business because you continued using "windows" in the name.
No, they handle it by stepping down the speed as necessary to keep the core temperature below some maximum -- which is exactly the right thing to do.
Yep. That's why people only know about Ford and Chevrolet. They've never heard of Toyota, or Honda, or Nissan, or Mazda, or Hyundai, or Mercedes, Porsche, BMW, Lexus, etc.
Yep, customers are dumb as dirt, and have trouble enough keeping up with the names of their kids.
I'm so confused, I just don't know who to believe anymore!