If this device can override the driver to slow down the car, then the next step in control is clear to me.
Once these devices are in place "for your protection", then it would be a simple matter for the police to key in your license plate and issue a "disable engine" command. After all, this will avoid high-speed chases, and make the streets even safer, right?
Wrong. Think of the abuses. It won't be long before criminals could bribe/crack their way into the system and use it to their own advantages. Want to steal that car? No problem, just disable the engine. Want to hurt your enemy? Disable a couple of innocent people's cars right in front of the target to create an accident. And hey, the police could do that too to create an instant roadblock to stop someone driving with stolen plates.
You don't even need a fancy modchip--how about this as a lower-tech solution.
Find a doctor willing to earn some extra income, and have your chip transfered to your pet dog. When you're being "legit", you take the dog with you everywhere you go. (And some people always seem to have their pets with them, don't they?) When you need an alibi, just leave the dog at home.
Well put! The only downside is that your well reasoned analysis will probably fall on deaf ears. Or, put another way (and I wish I could remember whom to credit):
It is exceedingly difficult to win an argument, when one's opponent is unencumbered with the facts.
I think Bob Dole is another example of a good man who had bad handlers. My respect for Mr. Dole went up after he lost the election, when he quit trying so hard, kicked back and was himself.
Politicians remind me of nervous kids getting bad advice about how to impress a girl on a first date.
Sounds right to me. And of course, there are the mergers happening in the long distance and cellular markets as well.
My own speculation is that when any one RBOC finally gets permission from the FCC to go into long distance, we will begin to see more mergers between long distance and RBOC companies.
I don't think there will be a return to the AT&T monopoly days, but like the US auto industry, we may wind up with 3 or 4 mega telecommunications companies, each offering a full spectrum of services from local and long distance POTS (plain old telephone service) to cellular, cable, Internet access, etc.
Early in this century, there were over 100 US automobile companies in business. Separate companies, some with still familiar names, like Crysler, Plymouth, Dodge, Ford, Cadillac, Buick, Packard, Nash, Rambler, Studibaker, Humpmobile (gotta love that one), Kaiser, Pontiac, Stanley.
Ten years from now, maybe we should start a contest to see how many defunct long distance companys we can name.:-)
After the AT&T breakup, the Southern Bell and South Central Bell BOC's (Bell Operating Company) were merged into BellSouth, which covers nine states in the southeast.
BellSouth has not yet merged with any other former BOC, nor with any long distance carrier. However, this is not from lack of trying. The price of merging, I assume, simply hasn't been right.
--Disclaimer-- I'm a BellSouth employee. Anything I post here and elsewhere are my own opinions and do not necessarily reflect the policies, positions, etc. of BellSouth. I am not a spokesman for BellSouth. If you have any questions about BellSouth, you will most likely be referred to the PR dept.
In other words, I'm a grunt. There! Now, isn't that better than certain AC's posting from Redmond?
From the description, this sounds like the same monitor set up at the IBM display at the Atlanta Linux Showcase. Boy, was it nice! IBM had Q3test running, and it looked good. And yes, you could see the action from an angle.
Nah. I think what you really want is a common, universal document standard. With a document standard in place, import and export filters become a thing of the past. A document created by one office suite could then be read/written by any other office suite without filter errors.
Just like, if you follow SMTP standard, it doesn't matter if you and I use different e-mail products -- we can still exchange mail.
About 2 years back, my son and I went through that wing of the American History museum. The scary part was, I spotted a TI Silent 700 terminal behind the glass display. It was a newer model than the ones we used in college....
This trend started well before the PC. If you really want to trace back the whistles and bells, I'd say the non-improvement in office productivity started with the photocopier.
How many people today can tell you what "cc:" means in e-mail? Answer: Carbon Copy. Before photocopiers, you had to stack paper with sheets of carbon paper between them, and run that through your typewriter. At best, a secretary could create 3 simultaneous copies at a time (1 original + 2 carbons) before the quality got really bad.
When photocopiers first came out in the 1960's (I was just a kid then, honest), I can remember hearing ads on the radio like, "Mrs. Smith, I have a meeting in an hour. Please make 20 copies of this letter." "But Mr. Jones, that will take the rest of the day!" "Not any more, Mrs. Smith. We now have a Xerox blah blah...."
Sure, making the actual copies is faster. But now, instead of only the essential people receiving correspondence, EVERYONE can be copied, and sucked into meetings. More paperwork crap (or e-mail, same thing) to wade through.
As someone else pointed out, the secretaries have all but disappeared, leaving documents to be created by higher paid, but otherwise mostly computer illiterate users. The users aren't really to blame. A salesman used to have professional clerial staff (like typing pools) to back him up. Now that salesman has a PC and no training on how to use it effectively.
Is it suprising this has resulted in a zero-sum gain?
Your comment is correct for bits. But, all during my career in the computer field (22 years and counting), BYTES -- not bits -- has ALWAYS been defined in terms of base-2 values, e.g.:
First off, I hope you have a backup server where you can test migrating your database from 7 to 8. For example, all of our pro*C applications have blown up on recompile under O8, because the developers didn't stick to the Oracle recommendations for the make files.
8 days, I hope, includes precautionary backups and/or exports. Otherwise, there is no reason your database needs to be down for 8 days. But your DBA will need stand-alone time to: 1. Run the MIG utility under O7. (MIG wants to startup/shutdown the database.) 2. Modify $ORACLE_HOME 3. Modify init.ora 4. Restart as O8. startup nomount alter database convert; alter database open resetlogs; ...etc....
We've also had the MIG utility core dump with one of our database instances--the others have converted OK. Hince, the reason you need to do your own testing.
The only way I can think of for you to convert a running database without interruption is if you have implemented Advanced Replication. If so, you will definately need $$$ Oracle consultation on migrating a replicated database.
Also, if your DBA plans to upgrade via export/import instead of using MIG, there are bugs in 8.0.5 related to export/import. Be sure you're running at least 8.0.5.1 or later.
(MIG however REQUIRES that you start with 8.0.5 base, then migrate, then apply the patch update after all instances are migrated.)
One small nit about Oracle/Linux and raw partitions. Have you tried it, and does it work?
Yes, Oracle supports raw datafiles. My concern is with the partition device names in Linux. I believe you can only use raw if you're writing to a raw (character) device name, not a block device name. Does Linux support character device names for SCSI partitions?
My only Linux experience is with IDE drives:(, and IDE drives only have block device name definitions.
Religion alert! Religion alert! You have struck the filesystem vs. raw partition nerve.:)
Basicly, Oracle stays out of this one. Well, mostly. Oracle has from time to time put out tuning guidelines and white papers that sometimes contradict each other on the benefits of filesystem vs. raw. In it's simplest form, it breaks down to:
Filesystem: K.I.S.S. Raw: Fully optimized I/O
The benefits of raw can vary from platform to platform. For example, Solaris allows async I/O for both filesystems and raw partitions. HP/UX only allows async I/O on raw partitions.
If I/O is not a bottleneck on your system, then going raw will not improve database performance.
If you plan to use Oracle Parallel Server, then you must build a raw database.
Mathew> You have to think about what drives Larry Ellison. First and foremost, he wants a successfull company/product/life. Secondly, and not too far behind, he wants to see Microsoft weakened. I think Linux / Oracle are here to stay.
Don't get me wrong, I WANT to see Oracle on Linux grow. But I do sometimes wonder if Larry Ellison isn't a bit too obsessed with Microsoft (like many of us). Then again, the same might be said of Scott McNealy.
Mathew> Not true. Oracle Enterprise Edition, with all included apps, is now available on Linux. This includes failover, ConText, and everything else bundled with Solaris OEE.
What version of Oracle on Linux are you running today?
Are you talking about the Oracle 8i developer release, or an official general release of Oracle8 EE? All I've seen so far is developer releases, but I'll be perfectly happy to be wrong on this point.
Mathew> I don't know what Veritas is, but Oracle on Linux supports Raw partitions.
Veritas is 3rd party JFS and LVM on Solaris, and it's a damn sight easier to use than the Solaris default.
Oracle supports raw partitions, but Linux doesn't. Even if you define a datafile as '/dev/sda1', you are pointing to a block device name.
Finally, Oracle on Linux is only on the x86 platform to date. I'm talking what's usable today, not what may be available tomorrow.
>Is Oracle-4-Linux immune to the file size barrier?
Nope, it's not immune. However, that's not a real problem. Just combine several 2-gig datafiles in one tablespace. On HP/UX 10.20, I have a DB with an 80-gig tablespace, made of 40 2-gig datafiles spread over several volume groups. Solaris goes beyond 2-gig, and so does HP/UX 11.0 64-bit with 64-bit Oracle8.
>I saw you CAN use raw partitions to use as databases, but I wasn't sure that the option was available for the Linux port..
Right again. Linux/dev/hdXX or/dev/sdXX refer to block (non-raw) device names.
Assuming you have to make a choice Real Soon Now (like by the end of this month), and company's budget isn't tight, Solaris is the better choice today.
Why, you ask?
1. Oracle on Linux doesn't have a long enough track record yet. It was ported just 6 months ago. As quickly as Oracle jumped on the Linux bandwagon, Larry Ellison could change his mind and jump off again.
2. Oracle is developed on Solaris, then ported to other OS's. Any bugs get fixed in Solaris first.
3. Right now, only Oracle Standard Edition is available for Linux. If you need Oracle Enterprise Edition features (table partitioning, object support, advanced replication, parallel server), then you need Solaris.
4. Scalability. If you expect rapid growth in you database application, Sun will scale better than any current Pentium system (E10000 anyone?). Beowulf clustering is not a viable option for Oracle.
5. Solaris has journaled file system and logical volume manager (Veritas), and it will suport raw logical volumes for datafiles.
6. If you plan to use an Oracle application, like Oracle Financials, you can't use Linux, because no Oracle application is certified for Linux yet. Oracle Financials is a BIG pain. It is extremely sensitive to the particular Oracle rdbms release, patch level, application patches, OS release, and OS patches.
Note that these considerations have more to do with the current state of Oracle on Linux, and current Pentium hardware limits, than with Linux per se. Ask this question again a year from now, and I hope to give you a different answer than today's.
Meanwhile, you might still get the Linux foot in the door by starting off using Oracle on Linux for test and development. The good news is, if you do use Oracle on Linux and you find you've outgrown that Pentium, you can easily port your entire database to another Oracle system (Sun, HP, IBM, etc.)
Perhaps I'm just lucky. I printed off the Redhat directions linked by/. on Friday (2/19/99), downloaded the required RPM updates, downloaded the latest kernel.org source tar ball, spent a LOT of time tweaking the config parameters and reading the config parameter help messages, built my kernel, and it WORKED the first time.
Indeed, I'm running 2.2.1 on Redhat 5.2 as I type this. This system is a generic Pentium 133 (no MMX) with 48MB ram.
My next step will be to upgrade my other system--a Pentium II/450 running S.u.S.E 5.3. Has anyone spotted upgrade instructions for S.u.S.E.?
Slashdot Mirror
As in Konrad Zuse, the German computer pioneer?
Hey, I was going to suggest Suzilla.
If this device can override the driver to slow down the car, then the next step in control is clear to me.
Once these devices are in place "for your protection", then it would be a simple matter for the police to key in your license plate and issue a "disable engine" command. After all, this will avoid high-speed chases, and make the streets even safer, right?
Wrong. Think of the abuses. It won't be long before criminals could bribe/crack their way into the system and use it to their own advantages. Want to steal that car? No problem, just disable the engine. Want to hurt your enemy? Disable a couple of innocent people's cars right in front of the target to create an accident. And hey, the police could do that too to create an instant roadblock to stop someone driving with stolen plates.
You don't even need a fancy modchip--how about this as a lower-tech solution.
Find a doctor willing to earn some extra income, and have your chip transfered to your pet dog. When you're being "legit", you take the dog with you everywhere you go. (And some people always seem to have their pets with them, don't they?) When you need an alibi, just leave the dog at home.
Yes! When I first saw the title, I too thought it said, "Vulture Ventures."
I guess the pickings are good for Paul Allen.
I think Bob Dole is another example of a good man who had bad handlers. My respect for Mr. Dole went up after he lost the election, when he quit trying so hard, kicked back and was himself.
Politicians remind me of nervous kids getting bad advice about how to impress a girl on a first date.
Sounds right to me. And of course, there are the mergers happening in the long distance and cellular markets as well.
:-)
My own speculation is that when any one RBOC finally gets permission from the FCC to go into long distance, we will begin to see more mergers between long distance and RBOC companies.
I don't think there will be a return to the AT&T monopoly days, but like the US auto industry, we may wind up with 3 or 4 mega telecommunications companies, each offering a full spectrum of services from local and long distance POTS (plain old telephone service) to cellular, cable, Internet access, etc.
Early in this century, there were over 100 US automobile companies in business. Separate companies, some with still familiar names, like Crysler, Plymouth, Dodge, Ford, Cadillac, Buick, Packard, Nash, Rambler, Studibaker, Humpmobile (gotta love that one), Kaiser, Pontiac, Stanley.
Ten years from now, maybe we should start a contest to see how many defunct long distance companys we can name.
After the AT&T breakup, the Southern Bell and South Central Bell BOC's (Bell Operating Company) were merged into BellSouth, which covers nine states in the southeast.
BellSouth has not yet merged with any other former BOC, nor with any long distance carrier. However, this is not from lack of trying. The price of merging, I assume, simply hasn't been right.
--Disclaimer--
I'm a BellSouth employee. Anything I post here and elsewhere are my own opinions and do not necessarily reflect the policies, positions, etc. of BellSouth. I am not a spokesman for BellSouth. If you have any questions about BellSouth, you will most likely be referred to the PR dept.
In other words, I'm a grunt. There! Now, isn't that better than certain AC's posting from Redmond?
From the description, this sounds like the same monitor set up at the IBM display at the Atlanta Linux Showcase. Boy, was it nice! IBM had Q3test running, and it looked good. And yes, you could see the action from an angle.
Nah. I think what you really want is a common, universal document standard. With a document standard in place, import and export filters become a thing of the past. A document created by one office suite could then be read/written by any other office suite without filter errors.
Just like, if you follow SMTP standard, it doesn't matter if you and I use different e-mail products -- we can still exchange mail.
About 2 years back, my son and I went through that wing of the American History museum. The scary part was, I spotted a TI Silent 700 terminal behind the glass display. It was a newer model than the ones we used in college....
This trend started well before the PC. If you really want to trace back the whistles and bells, I'd say the non-improvement in office productivity started with the photocopier.
How many people today can tell you what "cc:" means in e-mail? Answer: Carbon Copy. Before photocopiers, you had to stack paper with sheets of carbon paper between them, and run that through your typewriter. At best, a secretary could create 3 simultaneous copies at a time (1 original + 2 carbons) before the quality got really bad.
When photocopiers first came out in the 1960's (I was just a kid then, honest), I can remember hearing ads on the radio like, "Mrs. Smith, I have a meeting in an hour. Please make 20 copies of this letter." "But Mr. Jones, that will take the rest of the day!" "Not any more, Mrs. Smith. We now have a Xerox blah blah...."
Sure, making the actual copies is faster. But now, instead of only the essential people receiving correspondence, EVERYONE can be copied, and sucked into meetings. More paperwork crap (or e-mail, same thing) to wade through.
As someone else pointed out, the secretaries have all but disappeared, leaving documents to be created by higher paid, but otherwise mostly computer illiterate users. The users aren't really to blame. A salesman used to have professional clerial staff (like typing pools) to back him up. Now that salesman has a PC and no training on how to use it effectively.
Is it suprising this has resulted in a zero-sum gain?
I swear it wasn't me! The laptop wet my pants!
Your comment is correct for bits. But, all during my career in the computer field (22 years and counting), BYTES -- not bits -- has ALWAYS been defined in terms of base-2 values, e.g.:
...and so on...
1 * 2^10 = 1 Kilobyte
1 * 2^20 = 1 Megabyte
1 * 2^30 = 1 Gigabyte
1 * 2^40 = 1 Terabyte
1 * 2^50 = 1 Petabyte
1 * 2^60 = 1 Exabyte
It's only the hard drive makers, starting with the IBM PC/XT, that screwed with the definition to inflate their X-byte capacity claims.
I think the confusion here is whether one is talking about bits or bytes. The engineers are talking bits; the programmers bytes.
Hey, I'm gonna run out and buy two of them thangs.
One to monitor the bug zapper, and the other to watch for any varmits tryin' to steal the wheels off my house.
First off, I hope you have a backup server where you can test migrating your database from 7 to 8. For example, all of our pro*C applications have blown up on recompile under O8, because the developers didn't stick to the Oracle recommendations for the make files.
...etc....
8 days, I hope, includes precautionary backups and/or exports. Otherwise, there is no reason your database needs to be down for 8 days. But your DBA will need stand-alone time to:
1. Run the MIG utility under O7. (MIG wants to startup/shutdown the database.)
2. Modify $ORACLE_HOME
3. Modify init.ora
4. Restart as O8.
startup nomount
alter database convert;
alter database open resetlogs;
We've also had the MIG utility core dump with one of our database instances--the others have converted OK. Hince, the reason you need to do your own testing.
The only way I can think of for you to convert a running database without interruption is if you have implemented Advanced Replication. If so, you will definately need $$$ Oracle consultation on migrating a replicated database.
Also, if your DBA plans to upgrade via export/import instead of using MIG, there are bugs in 8.0.5 related to export/import. Be sure you're running at least 8.0.5.1 or later.
(MIG however REQUIRES that you start with 8.0.5 base, then migrate, then apply the patch update after all instances are migrated.)
...For Win 98/NT/2000?
Excellent summary. Well put.
:(, and IDE drives only have block device name definitions.
One small nit about Oracle/Linux and raw partitions. Have you tried it, and does it work?
Yes, Oracle supports raw datafiles. My concern is with the partition device names in Linux. I believe you can only use raw if you're writing to a raw (character) device name, not a block device name. Does Linux support character device names for SCSI partitions?
My only Linux experience is with IDE drives
Religion alert! Religion alert! You have struck the filesystem vs. raw partition nerve. :)
Basicly, Oracle stays out of this one. Well, mostly. Oracle has from time to time put out tuning guidelines and white papers that sometimes contradict each other on the benefits of filesystem vs. raw. In it's simplest form, it breaks down to:
Filesystem: K.I.S.S.
Raw: Fully optimized I/O
The benefits of raw can vary from platform to platform. For example, Solaris allows async I/O for both filesystems and raw partitions. HP/UX only allows async I/O on raw partitions.
If I/O is not a bottleneck on your system, then going raw will not improve database performance.
If you plan to use Oracle Parallel Server, then you must build a raw database.
Ok, here are my counterpoints. :)
Mathew> You have to think about what drives Larry Ellison. First and foremost, he wants a successfull company/product/life. Secondly, and not too far behind, he wants to see Microsoft weakened. I think Linux / Oracle are here to stay.
Don't get me wrong, I WANT to see Oracle on Linux grow. But I do sometimes wonder if Larry Ellison isn't a bit too obsessed with Microsoft (like many of us). Then again, the same might be said of Scott McNealy.
Mathew> Not true. Oracle Enterprise Edition, with all included apps, is now available on Linux. This includes failover, ConText, and everything else bundled with Solaris OEE.
What version of Oracle on Linux are you running today?
Are you talking about the Oracle 8i developer release, or an official general release of Oracle8 EE? All I've seen so far is developer releases, but I'll be perfectly happy to be wrong on this point.
Mathew> I don't know what Veritas is, but Oracle on Linux supports Raw partitions.
Veritas is 3rd party JFS and LVM on Solaris, and it's a damn sight easier to use than the Solaris default.
Oracle supports raw partitions, but Linux doesn't. Even if you define a datafile as '/dev/sda1', you are pointing to a block device name.
Finally, Oracle on Linux is only on the x86 platform to date. I'm talking what's usable today, not what may be available tomorrow.
>Is Oracle-4-Linux immune to the file size barrier?
/dev/hdXX or /dev/sdXX refer to block (non-raw) device names.
Nope, it's not immune. However, that's not a real problem. Just combine several 2-gig datafiles in one tablespace. On HP/UX 10.20, I have a DB with an 80-gig tablespace, made of 40 2-gig datafiles spread over several volume groups. Solaris goes beyond 2-gig, and so does HP/UX 11.0 64-bit with 64-bit Oracle8.
>I saw you CAN use raw partitions to use as databases, but I wasn't sure that the option was available for the Linux port..
Right again. Linux
Assuming you have to make a choice Real Soon Now (like by the end of this month), and company's budget isn't tight, Solaris is the better choice today.
Why, you ask?
1. Oracle on Linux doesn't have a long enough track record yet. It was ported just 6 months ago. As quickly as Oracle jumped on the Linux bandwagon, Larry Ellison could change his mind and jump off again.
2. Oracle is developed on Solaris, then ported to other OS's. Any bugs get fixed in Solaris first.
3. Right now, only Oracle Standard Edition is available for Linux. If you need Oracle Enterprise Edition features (table partitioning, object support, advanced replication, parallel server), then you need Solaris.
4. Scalability. If you expect rapid growth in you database application, Sun will scale better than any current Pentium system (E10000 anyone?). Beowulf clustering is not a viable option for Oracle.
5. Solaris has journaled file system and logical volume manager (Veritas), and it will suport raw logical volumes for datafiles.
6. If you plan to use an Oracle application, like Oracle Financials, you can't use Linux, because no Oracle application is certified for Linux yet. Oracle Financials is a BIG pain. It is extremely sensitive to the particular Oracle rdbms release, patch level, application patches, OS release, and OS patches.
Note that these considerations have more to do with the current state of Oracle on Linux, and current Pentium hardware limits, than with Linux per se. Ask this question again a year from now, and I hope to give you a different answer than today's.
Meanwhile, you might still get the Linux foot in the door by starting off using Oracle on Linux for test and development. The good news is, if you do use Oracle on Linux and you find you've outgrown that Pentium, you can easily port your entire database to another Oracle system (Sun, HP, IBM, etc.)
Perhaps I'm just lucky. I printed off the Redhat directions linked by /. on Friday (2/19/99), downloaded the required RPM updates, downloaded the latest kernel.org source tar ball, spent a LOT of time tweaking the config parameters and reading the config parameter help messages, built my kernel, and it WORKED the first time.
Indeed, I'm running 2.2.1 on Redhat 5.2 as I type this. This system is a generic Pentium 133 (no MMX) with 48MB ram.
My next step will be to upgrade my other system--a Pentium II/450 running S.u.S.E 5.3. Has anyone spotted upgrade instructions for S.u.S.E.?
Or, to quote the toaster from *Red Dwarf*, "I toast, therefore I am."